Golang on philipjkim

렉시오 CPU 플레이어 만들기 Part 6: 봇이 약한지 어떻게 아는가

Mon, 10 Aug 2026 08:51:18 +0900

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

눈으로 한 판 돌려서는 못 보는 것

Part 5 에서 고친 결함은 눈에 보이는 것이었습니다. 봇이 거의 모든 턴을 패스했고, 브라우저에서 5인 게임을 한 판 돌리자 바로 드러났습니다.

그 방법에는 한계가 분명합니다.

봇이 100% 패스한다 → 한 판이면 보입니다
봇이 라운드당 1.4점씩 잃는다 → 몇 판을 돌려도 느낄 수 없습니다

렉시오는 딜 운의 분산이 큽니다. 좋은 패를 받은 판과 나쁜 패를 받은 판의 차이가 정책의 차이보다 훨씬 크기 때문에, 사람이 몇 판 보고 “이 봇이 좀 약한 것 같다"고 말하는 것은 근거가 되지 못합니다. 측정 도구 없이 가중치를 만지면 더 나쁩니다. 고쳤다고 생각한 것이 실은 운이었는지 확인할 방법이 없습니다.

렉시오 CPU 플레이어 만들기 Part 5: 봇이 아무것도 하지 않는 이유

Fri, 07 Aug 2026 07:56:13 +0900

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

설계와 구현 사이

Part 1 부터 Part 4 까지는 설계안이었습니다. 타일을 정수로 압축하고, 미공개 집합을 복원하고, 손패 분해를 DP 로 풀고, 목적 함수를 정산식에서 유도해 평가 함수의 항을 나열했습니다. 코드 조각은 있었지만 돌려 본 적은 없었습니다.

이번 편은 그 설계를 실제로 구현해 브라우저에서 5인 게임을 돌려 본 기록입니다. 결과부터 적겠습니다. 봇이 거의 모든 턴을 패스했습니다.

원인을 추적하고 나서 든 생각은 “설계가 틀렸다"가 아니었습니다. 항을 하나씩 뜯어보면 Part 4 가 쓴 대로였고, 개별 함수는 각각 맞는 값을 돌려주고 있었습니다. 틀린 것은 항을 합치는 방식 이었고, 그중 일부는 Part 1~4 가 아예 말하지 않은 자리였습니다.

달무티 CPU 플레이어 만들기 Part 4: 만들어 보니 hard 봇이 더 약했다

Mon, 03 Aug 2026 17:57:55 +0900

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

설계안이 검증을 만나면

Part 1에서 공정성 경계와 결정적 easy 봇을 만들었고, Part 2에서 hard 봇의 정보 모델을 세웠고, Part 3에서 수 평가 함수와 전략적 패스로 실제 결정을 내렸습니다. 세 편 모두 “이 글은 설계안이고 코드는 논지를 보이기 위한 발췌"라고 밝혀 두었습니다.

그 설계안을 실제 게임에 구현하고, 시뮬레이터를 붙여 easy 봇과 같은 조건에서 붙여 봤습니다. 결과는 이랬습니다.

최초 hard 봇은 easy 봇보다 평균 종료 순위가 0.6601등 나빴습니다.

렉시오 CPU 플레이어 만들기 Part 4: 수 평가와 정산 기대값

Fri, 31 Jul 2026 09:44:26 +0900

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

재료에서 결정으로

Part 2 에서 봇이 무엇을 아는지, Part 3 에서 자기 손패를 어떻게 보는지 만들었습니다. 아직 결정은 하나도 하지 않았습니다. 이번 편에서 전부 합칩니다.

그런데 합치기 전에 답해야 할 질문이 하나 있습니다. 무엇을 최대화할 것인가.

달무티에서는 이 질문이 쉬웠습니다. 등수가 곧 다음 판의 계급이고 점수도 등수에 비례하므로, “평균 등수를 낮춘다"가 그대로 목적 함수였습니다. 렉시오는 다릅니다. 렉시오에는 등수가 없습니다. 금액만 있습니다.

렉시오 CPU 플레이어 만들기 Part 3: 손패 분해 플랜

Fri, 31 Jul 2026 09:37:44 +0900

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

좋은 손패는 센 손패가 아니다

Part 2 에서는 봇이 상대에 대해 무엇을 알 수 있는지 정리했습니다. 이번 편은 시선을 안으로 돌립니다. 내 손패는 몇 번 제출하면 비는가.

이 질문이 왜 중요한지는 클라이밍 게임 전략 글에서 이미 짚었습니다. 강한 타일이 많은 손패와 조합이 잘 짜인 손패 중 이기는 쪽은 후자입니다. 강한 타일은 한 번에 한 장씩 나가지만, 잘 짜인 손패는 다섯 장씩 나갑니다.

렉시오 CPU 플레이어 만들기 Part 2: 60비트 카운팅과 확실승수 판정

Fri, 31 Jul 2026 09:30:12 +0900

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

hard 봇이 지켜야 할 세 가지

Part 1 에서 만든 easy 봇은 이번 턴에 합법적인 가장 싼 수를 계산할 뿐이었습니다. 이번 편부터 hard 봇을 설계합니다. 다만 시작하기 전에 지켜야 할 선을 못 박아 두겠습니다.

공정성. 봇은 GameView 만 봅니다. 남의 손패는 그 구조체 어디에도 존재하지 않습니다. 봇이 강해지는 이유는 더 많이 보기 때문이 아니라, 같은 것을 보고 더 잘 세기 때문 이어야 합니다.
결정성. 같은 입력에서는 같은 출력이 나와야 합니다. 그래야 봇 로직이 테스트 가능한 코드가 됩니다. 난수를 쓴다면 시드를 게임 상태에서 유도합니다.
실시간성. 봇의 판단은 사람이 기다릴 수 있는 시간 안에 끝나야 합니다. 이 제약이 뒤에서 “몬테카를로를 런타임에 돌리지 않는다"는 설계 결정으로 이어집니다.

이번 편은 hard 봇이 무엇을 아는가 를 다룹니다. 무엇을 결정하는가는 Part 3 과 Part 4 의 몫입니다.

렉시오 CPU 플레이어 만들기 Part 1: 타일 하나를 정수 하나로

Fri, 31 Jul 2026 09:22:31 +0900

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

사촌 게임, 전혀 다른 봇

어제 글에서 달무티(The Great Dalmuti)의 CPU 플레이어를 세 편에 걸쳐 설계했습니다. 이번에는 같은 클라이밍 계열의 국산 타일 게임 렉시오(Lexio) 로 넘어갑니다.

두 게임은 클라이밍 게임을 정리한 글에서 봤듯 사촌 사이입니다. 더 센 조합으로 받아 올라가고, 손패를 먼저 비우는 쪽이 이깁니다. 그런데 봇을 짜 보면 알고리즘이 거의 겹치지 않습니다. 달무티 봇 코드를 렉시오로 옮기려 하면 재사용할 수 있는 것은 “공정성 경계를 타입으로 못 박는다” 같은 뼈대뿐이고, 판단 로직은 전부 새로 써야 합니다.

달무티 CPU 플레이어 만들기 Part 3: 수 평가와 전략적 패스

Thu, 30 Jul 2026 15:08:35 +0900

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

정정 안내 (2026-08-03): 이 글의 설계안을 실제로 구현해 시뮬레이션으로 검증한 결과, 리드 선택·세금 반환·목적 함수에 대한 일부 결론이 뒤집혔습니다. 특히 “리드 선택도 같은 계산이다” 절과 “rank 12 는 반환 카드로 나쁘다"는 주장은 철회되었습니다. 무엇이 왜 틀렸고 무엇이 살아남았는지는 Part 4: 만들어 보니 hard 봇이 더 약했다에 정리했습니다.

재료에서 결정으로

Part 1에서 공정성 경계와 결정적 easy 봇을 만들었고, Part 2에서 hard 봇의 정보 모델을 세웠습니다. 지금까지 확보한 재료는 셋입니다.

달무티 CPU 플레이어 만들기 Part 2: hard 봇의 정보 모델과 확실승수 판정

Thu, 30 Jul 2026 14:18:37 +0900

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

hard 봇이 지켜야 할 세 가지

Part 1에서는 달무티 CPU 플레이어의 뼈대를 잡고, 결정적 규칙만으로 움직이는 easy 봇을 만들었습니다. easy 봇은 합법적이고 예측 가능하지만, “낼 수 있으면 무조건 낸다"는 정책 때문에 사람에게 쉽게 집니다.

이번 편부터 hard 봇을 설계합니다. 설계 제약은 세 가지입니다.

1. 상대의 손패는 절대 볼 수 없습니다. 봇은 Part 1 에서 정의한 GameView 만 받습니다. 난이도를 올리기 위해 정보를 더 주는 것은 설계가 아니라 반칙입니다. 사람이 “저 봇 손패 보는 거 아니야?“라고 의심하는 순간 게임의 신뢰가 무너집니다.

달무티 CPU 플레이어 만들기 Part 1: 규칙 기반 easy 봇

Thu, 30 Jul 2026 14:09:37 +0900

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

후속 정정 안내 (2026-08-03): 이 시리즈의 설계안을 실제로 구현해 시뮬레이션으로 검증한 결과, 여기서 “easy 봇의 단순화"로 소개한 리드 정책과 세금 반환 규칙이 hard 봇의 복잡한 평가식보다 강했고, 지금은 hard 봇의 guardrail 로 채택돼 있습니다. 자세한 내용은 Part 4: 만들어 보니 hard 봇이 더 약했다에 정리했습니다.

왜 봇부터 만드는가

지난 글에서 대부호·달무티·렉시오를 묶어 클라이밍 게임의 전략을 정리했습니다. 이번에는 그중 달무티(The Great Dalmuti) 를 디지털 게임으로 구현한다고 가정하고, CPU 플레이어를 어떤 전략으로 움직일 것인가 를 파고들겠습니다.

2021년의 Go를 2026년의 Go로 Part 3: 동시성·런타임·운영 레시피

Wed, 24 Jun 2026 10:15:25 +0900

이 글은 Claude Opus 4.8 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며

Part 1에서 언어와 문법을, Part 2에서 표준 라이브러리를 다뤘습니다. 시리즈의 마지막인 Part 3은 동시성·런타임·툴체인·운영 입니다. 코드 한 줄의 변화라기보다, “서비스를 어떻게 돌리고 어떻게 검증하느냐"에 가까운 영역입니다.

이 영역의 변화는 특히 컨테이너/쿠버네티스 환경에서 Go 서비스를 운영하는 팀에게 의미가 큽니다. 2021년에는 서드파티 라이브러리나 수작업으로 메우던 빈틈을, 이제 표준 런타임이 채워 줍니다.

레시피 1: 수동 취소·타임아웃 관리 대신 `context` 신규 API (1.21)

context 는 1.7부터 있었지만, 실무에서 반복되던 몇 가지 패턴을 표준으로 흡수한 것은 1.21입니다.

2021년의 Go를 2026년의 Go로 Part 2: 표준 라이브러리 레시피

Wed, 24 Jun 2026 10:13:33 +0900

이 글은 Claude Opus 4.8 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며

Part 1에서는 제네릭, 이터레이터, 빌트인 등 언어와 문법 레벨의 변화를 다뤘습니다. Part 2는 일상 코드에서 가장 손이 자주 가는 표준 라이브러리 의 레시피입니다.

2021~22년의 Go 표준 라이브러리는 의외로 빈약했습니다. 슬라이스에서 원소를 찾으려면 for 루프를 직접 돌렸고, 맵의 키를 모으려면 손으로 슬라이스를 채웠으며, 정렬은 sort.Slice 에 비교 함수를 넘겼습니다. 구조적 로깅을 하려면 logrus, zap 같은 서드파티가 사실상 필수였고, HTTP 라우팅에서 메서드와 경로 파라미터를 다루려면 gorilla/mux 를 깔았습니다.

2021년의 Go를 2026년의 Go로 Part 1: 언어와 문법 레시피

Wed, 24 Jun 2026 10:11:05 +0900

이 글은 Claude Opus 4.8 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며: 5년 동안 Go에 무슨 일이 있었나

2021~22년에 Go로 서비스를 짜던 시절을 떠올려 봅니다. 그때 우리가 쓰던 버전은 대략 Go 1.16~1.18 언저리였습니다. 제네릭이 없거나(1.18 이전), 갓 도입되어 아직 손에 익지 않았고, interface{} 와 sort.Slice, for _, v := range xs { v := v; ... } 같은 관용구가 일상이었습니다.

그로부터 8개의 메이저 릴리스(1.19부터 1.26까지)가 지났습니다. 2026년 6월 현재 stable 버전은 2026년 2월에 나온 Go 1.26 입니다. 이 5년 사이에 언어 자체, 표준 라이브러리, 런타임, 툴체인이 모두 크게 달라졌습니다. 문제는 코드베이스가 그만큼 따라가지 못한다는 점입니다. 많은 프로덕션 코드가 여전히 “그때 그렇게 짜던 방식"으로 멈춰 있습니다.

Agentic Coding 시대의 Repo 부트스트래핑 가이드 Part 2: Go + Templ + HTMX To-Do 앱으로 직접 만들어 보기

Thu, 28 May 2026 19:03:00 +0900

이 글은 Claude Opus 4.7 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Part 1 에서는 2026년 5월 기준 de-facto 가 된 spec 문서들의 지형도와 best practices 를 정리했습니다. 2편에서는 가상의 Go + Templ + HTMX 기반 To-Do 앱 gotodo 를 새로 부트스트래핑한다고 가정하고, 각 문서를 실제로 어떻게 채우는지 발췌 형태로 따라갑니다.

가상 프로젝트: `gotodo`

스택은 다음과 같습니다.

Go 1.23 — 표준 라이브러리 중심
templ — Go 네이티브 SSR 템플릿 (type-safe)
HTMX 2.0 — 클라이언트 JS 최소화
SQLite + modernc.org/sqlite — CGO 없는 순수 Go 드라이버

목표는 단순합니다. 할 일 추가/완료/삭제만 되는 SSR 미니멀 앱. 1인 로컬 사용을 가정합니다.

Go 웹 프레임워크 비교: Chi vs. Gin

Sat, 07 Mar 2026 00:21:25 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Go로 웹 애플리케이션을 만들 때, 가장 많이 비교되는 두 선택지가 Chi와 Gin입니다. GitHub 스타 기준으로 Gin이 압도적인 인기를 누리고 있지만(Gin ~80k vs Chi ~19k), 실무에서의 선택은 단순한 인기도만으로 결정할 문제가 아닙니다.

이 글에서는 두 라이브러리의 설계 철학부터 시작해서, 실제 코드 레벨에서의 차이를 비교합니다.

설계 철학: 라우터 vs. 프레임워크

Chi와 Gin의 가장 근본적인 차이는 자기 자신을 어떻게 정의하는가에 있습니다.

HTMX와 함께 사용할 Go 템플릿 기술 비교: html/template vs. Templ

Sat, 07 Mar 2026 00:01:56 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Go로 SSR 웹 앱을 만들 때 HTMX와 함께 사용할 템플릿 기술로 두 가지 선택지가 있습니다.

Go 표준 html/template + 커스텀 PageRenderer (페이지별 독립 템플릿 세트)
Templ

이 글에서는 두 방식의 장단점을 실무 관점에서 비교합니다.

타입 안전성

가장 큰 갈림길입니다.

html/template은 런타임에 템플릿을 파싱하고 데이터를 바인딩합니다. {{ .Titl }}이라고 써도 빌드는 통과합니다. 런타임에 빈 문자열이 나오거나 에러가 발생하고 나서야 문제를 알 수 있습니다.

Redis를 활용한 초경량 메시징 전략: Pub-Sub과 Worker Queue 완벽 정리

Thu, 26 Feb 2026 19:38:55 +0900

Redis를 단순히 ‘캐시’로만 쓰고 계신가요? 사실 Redis는 백엔드 엔지니어의 도구 상자에서 가장 다재다능한 ‘메시지 브로커’ 이기도 합니다. 별도의 무거운 MQ(Message Queue)를 설치하기엔 부담스럽고, 속도는 포기할 수 없을 때 Redis는 최고의 선택지가 됩니다.

Go 언어를 이용해 Redis의 두 가지 핵심 메시징 패턴인 Pub-Sub과 Worker Queue를 구현하는 방법을 정리해 보았습니다.

1. 왜 Redis 메시지 큐인가?

RabbitMQ나 Kafka는 훌륭하지만, 운영 오버헤드가 큽니다. 반면 Redis는 이미 많은 프로젝트에서 캐시용으로 사용 중이며, 다음과 같은 장점이 있습니다.

GoTHIC 스택으로 JavaScript 없이 모던 웹앱 만들기

Wed, 11 Feb 2026 09:31:05 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Go 백엔드 개발자가 프론트엔드 프레임워크 없이도 인터랙티브한 웹 애플리케이션을 만들 수 있다면 어떨까요? 이 글에서는 GoTHIC 스택으로 JavaScript 로직을 최소화한 To-Do 앱을 처음부터 끝까지 만들어봅니다. 핫 리로드까지 air로 세팅하면 개발 경험도 꽤 쾌적합니다.

GoTHIC 스택이란

GoTHIC은 Go(+Gin) + T(empl) + H(TMX) + Interactive Components(Alpine.js + TailwindCSS + DaisyUI)의 축약어입니다. GoTH(Go + Templ + HTMX) 스택을 확장하여 클라이언트 인터랙션과 스타일링까지 아우르는 풀스택 조합입니다.

Java to Go: #5. 프로젝트 구조와 생태계

Wed, 21 Jan 2026 12:28:40 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

지금까지 Go의 철학, 문법, 에러 처리, 동시성을 살펴봤다. 이제 실제 프로젝트를 시작하는 데 필요한 것들을 다룬다. Maven/Gradle에서 Go Modules로, JUnit에서 testing 패키지로, Spring에서 Go 라이브러리 조합으로 전환하는 방법을 알아보자.

1. Go Modules 기초

go.mod와 go.sum

Go 1.11부터 도입된 Go Modules가 공식 의존성 관리 시스템이다.

# 새 모듈 초기화
mkdir myproject && cd myproject
go mod init github.com/username/myproject

생성된 go.mod:

module github.com/username/myproject

go 1.21

의존성을 추가하면:

Java to Go: #4. 동시성: Goroutine과 Channel

Wed, 21 Jan 2026 12:28:36 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Go의 동시성 모델은 Java와 근본적으로 다르다. Thread, synchronized, ExecutorService에 익숙한 개발자라면 처음엔 낯설겠지만, Go의 방식이 얼마나 우아한지 금방 알게 될 것이다. “공유 메모리로 통신하지 말고, 통신으로 메모리를 공유하라"는 Go의 철학을 이해해보자.

1. Goroutine: 경량 스레드

go 키워드 하나로 시작하는 동시성

Java에서 새 스레드를 만들려면:

new Thread(() -> {
 System.out.println("Hello from thread");
}).start();

// 또는 ExecutorService
ExecutorService executor = Executors.newFixedThreadPool(10);
executor.submit(() -> {
 System.out.println("Hello from thread pool");
});

Go에서는 go 키워드 하나면 된다:

Java to Go: #3. 에러 처리와 Null 안전성

Wed, 21 Jan 2026 12:28:33 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Java 개발자가 Go를 배울 때 가장 큰 패러다임 전환이 필요한 부분이 에러 처리다. try-catch에 익숙한 우리에게 if err != nil의 반복은 처음엔 원시적으로 느껴진다. 하지만 이 방식에는 명확한 철학이 있다. 이번 편에서 그 철학을 이해하고, Go 방식의 에러 처리에 익숙해져 보자.

1. Java의 Exception vs Go의 error

근본적인 차이

Java: 예외는 “특별한 상황"이다. 정상 흐름과 분리되어 throw/catch로 처리된다.

Java to Go: #2. 문법 전환 가이드: Java 코드를 Go로 옮기기

Wed, 21 Jan 2026 12:28:30 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Part 1에서 Go의 철학과 언제 Go를 선택해야 하는지 살펴봤다. 이제 실제 코드 레벨에서 Java와 Go가 어떻게 다른지 1:1로 비교해보자. Java 문법에 익숙한 개발자가 Go 코드를 읽고 쓸 수 있도록 핵심 차이점을 정리한다.

1. 변수 선언과 타입 시스템

기본 변수 선언

Java:

String name = "Alice";
int age = 30;
final double PI = 3.14159;

Go:

var name string = "Alice"
var age int = 30
const PI = 3.14159

Go에서는 타입이 변수명 뒤에 온다. 처음엔 어색하지만, 복잡한 타입 선언에서는 오히려 읽기 쉽다.

Java to Go: #1. Go 첫인상: 철학과 패러다임의 차이

Wed, 21 Jan 2026 12:28:27 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Java를 수년간 써온 개발자가 Go를 처음 접하면 당혹스럽다. “왜 이렇게 만들었지?“라는 생각이 끊이지 않는다. 이 글에서는 Go의 설계 철학을 이해하고, Java에서 Go로의 전환이 언제 적절한지 판단할 수 있는 기준을 제시한다.

1. Go의 설계 철학: “Less is more”

Go는 2009년 Google에서 Robert Griesemer, Rob Pike, Ken Thompson이 만들었다. 세 사람 모두 수십 년 경력의 시스템 프로그래머로, C++의 복잡성에 지쳐 있었다. Go의 탄생 배경 자체가 “복잡함에 대한 반발"이다.

Go to Rust: #10. 프로젝트 관리와 실전 패턴

Mon, 19 Jan 2026 16:10:08 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

이 마지막 섹션에서는 실제 Rust 프로젝트를 구성하고 관리하는 방법을 학습합니다. Cargo 심화, 모듈 시스템, 테스트, 그리고 Go 코드를 Rust로 포팅할 때 유용한 패턴들을 다룹니다.

10.1 Cargo 심화

Cargo.toml 상세 설정

[package]
name = "myapp"
version = "0.1.0"
edition = "2021"
authors = ["Your Name <you@example.com>"]
description = "A sample Rust application"
license = "MIT"
repository = "https://github.com/you/myapp"
keywords = ["cli", "tool"]
categories = ["command-line-utilities"]

[dependencies]
serde = { version = "1.0", features = ["derive"] }
tokio = { version = "1", features = ["full"] }

[dev-dependencies]
criterion = "0.5" # 벤치마크용

[build-dependencies]
cc = "1.0" # 빌드 스크립트용

[features]
default = ["json"]
json = ["serde_json"]
full = ["json", "yaml"]

[[bin]]
name = "myapp"
path = "src/main.rs"

[[bin]]
name = "mytool"
path = "src/bin/mytool.rs"

[profile.release]
opt-level = 3
lto = true

의존성 관리

[dependencies]
# 버전 지정
serde = "1.0" # ^1.0.0 (1.x.x)
serde = "=1.0.104" # 정확히 1.0.104
serde = ">=1.0, <2.0" # 범위

# Git 의존성
mylib = { git = "https://github.com/user/mylib" }
mylib = { git = "https://github.com/user/mylib", branch = "dev" }
mylib = { git = "https://github.com/user/mylib", tag = "v1.0.0" }
mylib = { git = "https://github.com/user/mylib", rev = "abc123" }

# 로컬 경로
mylib = { path = "../mylib" }

# 선택적 의존성
serde_json = { version = "1.0", optional = true }

# 피처 플래그
tokio = { version = "1", features = ["rt-multi-thread", "macros"] }

Go modules와 비교

# Go: go.mod
module github.com/user/myapp

go 1.21

require (
 github.com/gin-gonic/gin v1.9.0
 github.com/lib/pq v1.10.0
)

# Rust: Cargo.toml
[package]
name = "myapp"
version = "0.1.0"
edition = "2021"

[dependencies]
axum = "0.7"
sqlx = { version = "0.7", features = ["postgres"] }

측면	Go	Cargo
의존성 파일	go.mod	Cargo.toml
락 파일	go.sum	Cargo.lock
저장소	분산 (GitHub 등)	중앙 (crates.io)
버전 관리	Git 태그	SemVer

피처 플래그

[features]
default = ["std"]
std = []
alloc = []
json = ["serde", "serde_json"]
full = ["json", "yaml", "toml"]

// 조건부 컴파일
#[cfg(feature = "json")]
pub mod json {
 pub fn parse_json(s: &str) -> Value { /* ... */ }
}

#[cfg(feature = "std")]
use std::collections::HashMap;

#[cfg(not(feature = "std"))]
use alloc::collections::BTreeMap as HashMap;

10.2 모듈 시스템

파일 시스템과 모듈 구조

myapp/
├── Cargo.toml
└── src/
 ├── main.rs # 바이너리 루트
 ├── lib.rs # 라이브러리 루트
 ├── config.rs # config 모듈
 ├── utils/
 │ ├── mod.rs # utils 모듈
 │ ├── helpers.rs # utils::helpers
 │ └── format.rs # utils::format
 └── handlers/
 ├── mod.rs
 ├── user.rs
 └── post.rs

lib.rs:

Go to Rust: #9. 비동기 프로그래밍

Mon, 19 Jan 2026 16:09:59 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Rust의 async/await는 Go의 goroutine과 근본적으로 다른 접근 방식입니다. Go는 런타임이 모든 것을 관리하지만, Rust는 명시적인 비동기 모델을 사용합니다. 이 섹션에서는 Rust의 비동기 생태계와 Tokio 런타임을 학습합니다.

9.1 비동기의 필요성

동기 vs 비동기

동기 (Synchronous):

// 순차적 실행, 블로킹
fn fetch_data() -> Data {
 let response = http_get("https://api.example.com"); // 대기
 parse(response)
}

비동기 (Asynchronous):

// 대기 중 다른 작업 가능
async fn fetch_data() -> Data {
 let response = http_get("https://api.example.com").await; // 양보
 parse(response)
}

Go의 goroutine 모델

Go는 런타임이 내장되어 있어 동기 코드처럼 보이지만 비동기로 동작합니다:

Go to Rust: #8. 동시성 프로그래밍

Mon, 19 Jan 2026 16:09:50 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Rust의 “Fearless Concurrency"는 컴파일 타임에 데이터 레이스를 방지합니다. Go의 고루틴과 채널에 익숙하다면, Rust의 동시성 모델이 어떻게 다른지 이해하는 것이 중요합니다.

8.1 Rust의 동시성 철학

“Fearless Concurrency"란?

Go의 철학: “Don’t communicate by sharing memory; share memory by communicating.” Rust의 철학: “Fearless Concurrency through ownership.”

Go	Rust
런타임에 데이터 레이스 감지 (`-race`)	컴파일 타임에 데이터 레이스 방지
고루틴 + 채널 권장	소유권 + 타입 시스템으로 안전성 보장
공유 메모리도 가능 (주의 필요)	공유 메모리도 안전하게 사용 가능

데이터 레이스의 세 가지 조건

두 스레드가 같은 데이터에 접근
적어도 하나가 쓰기 작업
접근이 동기화되지 않음

Rust는 소유권 규칙으로 이를 컴파일 타임에 방지합니다:

Go to Rust: #7. 컬렉션과 이터레이터

Mon, 19 Jan 2026 16:09:42 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Rust의 컬렉션은 Go와 유사한 기능을 제공하지만, 소유권 시스템과 결합되어 더 안전합니다. 특히 이터레이터 시스템은 Go의 range보다 훨씬 강력하며, 함수형 프로그래밍 스타일을 지원합니다.

7.1 표준 컬렉션 개요

Go와 Rust 컬렉션 매핑

Go	Rust	설명
`[]T` (slice)	`Vec<T>`	동적 배열
`[N]T` (array)	`[T; N]`	고정 배열
`string`	`String`	소유된 문자열
`string` (리터럴)	`&str`	문자열 슬라이스
`map[K]V`	`HashMap<K, V>`	해시 맵
-	`HashSet<T>`	해시 셋
-	`BTreeMap<K, V>`	정렬된 맵
-	`BTreeSet<T>`	정렬된 셋
-	`VecDeque<T>`	양방향 큐
`container/list`	`LinkedList<T>`	이중 연결 리스트

7.2 Vec 심화

생성 방법들

// 빈 벡터
let v: Vec<i32> = Vec::new();

// vec! 매크로 (가장 흔함)
let v = vec![1, 2, 3, 4, 5];

// 같은 값으로 초기화
let v = vec![0; 10]; // [0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

// 용량 미리 할당
let mut v = Vec::with_capacity(100);

// 이터레이터에서 수집
let v: Vec<i32> = (1..=5).collect();

// from_iter
let v = Vec::from_iter([1, 2, 3]);

기본 연산

let mut v = vec![1, 2, 3];

// 추가
v.push(4); // 끝에 추가
v.insert(0, 0); // 인덱스에 삽입: [0, 1, 2, 3, 4]

// 제거
let last = v.pop(); // 끝에서 제거, Option<T>
let removed = v.remove(0); // 인덱스에서 제거, T
v.retain(|&x| x > 2); // 조건에 맞는 것만 유지

// 접근
let first = v[0]; // 패닉 가능
let first = v.get(0); // Option<&T>
let first = v.first(); // Option<&T>
let last = v.last(); // Option<&T>

// 수정
v[0] = 10;
if let Some(first) = v.first_mut() {
 *first = 20;
}

Go의 append vs Rust의 push

// Go: append는 새 슬라이스 반환 가능
slice := []int{1, 2, 3}
slice = append(slice, 4) // 재할당 가능

// 용량 확인
cap(slice)

// Rust: push는 in-place 수정
let mut v = vec![1, 2, 3];
v.push(4); // v가 mut이어야 함

// 용량
v.capacity();
v.reserve(100); // 추가 용량 확보
v.shrink_to_fit(); // 불필요한 용량 해제

소유권과 Vec

let v = vec![String::from("a"), String::from("b")];

// 인덱스 접근은 빌림
let first: &String = &v[0]; // 불변 빌림

// for 루프는 소유권 이동 또는 빌림 선택 가능
for s in v { // v의 소유권 이동, s: String
 println!("{}", s);
}
// v는 더 이상 사용 불가

let v = vec![String::from("a"), String::from("b")];
for s in &v { // v 빌림, s: &String
 println!("{}", s);
}
// v 여전히 사용 가능

for s in &mut v { // 가변 빌림, s: &mut String
 s.push_str("!");
}

슬라이싱

let v = vec![1, 2, 3, 4, 5];

// 슬라이스 참조
let slice: &[i32] = &v[1..4]; // [2, 3, 4]
let slice: &[i32] = &v[..]; // 전체

// 가변 슬라이스
let mut v = vec![1, 2, 3, 4, 5];
let slice: &mut [i32] = &mut v[1..4];
slice[0] = 20; // v는 [1, 20, 3, 4, 5]

7.3 문자열 처리

String vs &str

// String: 힙에 할당된 소유 문자열
let owned: String = String::from("hello");
let owned: String = "hello".to_string();
let owned: String = "hello".to_owned();

// &str: 문자열 슬라이스 (빌림)
let borrowed: &str = "hello"; // 정적 문자열
let borrowed: &str = &owned; // String에서 빌림
let borrowed: &str = &owned[0..3]; // 부분 슬라이스

특성	`String`	`&str`
소유권	있음	없음 (빌림)
힙 할당	예	아니오
가변	가능	불가능
크기	가변	고정 (뷰)
함수 인자	소유권 필요시	대부분

UTF-8 인코딩

Rust 문자열은 항상 유효한 UTF-8입니다:

Go to Rust: #6. 에러 처리

Mon, 19 Jan 2026 16:09:35 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Rust의 에러 처리는 Go와 철학적으로 유사합니다. 두 언어 모두 예외(exception)를 사용하지 않고 명시적인 에러 반환을 선호합니다. 하지만 Rust는 타입 시스템을 통해 에러 처리를 강제하여, Go에서 흔히 발생하는 “에러 무시” 문제를 원천 차단합니다.

6.1 Rust의 에러 처리 철학

복구 가능한 에러 vs 복구 불가능한 에러

Rust는 에러를 두 가지로 구분합니다:

복구 가능한 에러 (Recoverable): Result<T, E>

파일을 찾을 수 없음
네트워크 연결 실패
잘못된 사용자 입력

복구 불가능한 에러 (Unrecoverable): panic!

Go to Rust: #5. 트레이트와 제네릭

Mon, 19 Jan 2026 09:56:15 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

트레이트(Trait)는 Rust의 다형성 메커니즘입니다. Go의 인터페이스와 비슷한 역할을 하지만, 구현 방식과 기능에서 큰 차이가 있습니다. 이 섹션에서는 트레이트와 제네릭을 Go와 비교하며 깊이 있게 학습합니다.

5.1 트레이트 기초

트레이트란?

트레이트는 타입이 구현해야 하는 메서드 집합을 정의합니다:

// 트레이트 정의
trait Summary {
 fn summarize(&self) -> String;
}

// 타입 정의
struct Article {
 title: String,
 author: String,
 content: String,
}

// 트레이트 구현
impl Summary for Article {
 fn summarize(&self) -> String {
 format!("{} by {}", self.title, self.author)
 }
}

Go interface vs Rust trait

가장 큰 차이: 암묵적 vs 명시적

Go to Rust: #4. 구조체, 열거형, 패턴 매칭

Mon, 19 Jan 2026 09:56:10 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

이 섹션에서는 Rust에서 데이터를 구조화하는 방법을 학습합니다. Go 개발자에게 구조체는 익숙하겠지만, Rust의 열거형(enum)은 Go의 const/iota보다 훨씬 강력하며, 패턴 매칭은 switch문을 완전히 새로운 수준으로 끌어올립니다.

4.1 구조체 (Struct)

구조체 정의와 인스턴스 생성

// 구조체 정의
struct User {
 username: String,
 email: String,
 sign_in_count: u64,
 active: bool,
}

// 인스턴스 생성
fn main() {
 let user = User {
 username: String::from("alice"),
 email: String::from("alice@example.com"),
 sign_in_count: 1,
 active: true,
 };
 
 // 필드 접근
 println!("Username: {}", user.username);
}

Go struct와의 문법 비교:

Go to Rust: #3. 소유권과 빌림 (Ownership & Borrowing)

Mon, 19 Jan 2026 09:56:03 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

소유권(Ownership)은 Rust의 가장 독특하고 중요한 개념입니다. Go의 가비지 컬렉션과 완전히 다른 접근 방식으로, 컴파일 타임에 메모리 안전성을 보장합니다. 이 섹션은 Rust 학습에서 가장 중요한 부분이므로 충분한 시간을 들여 이해하시기 바랍니다.

3.1 소유권이란 무엇인가?

메모리 관리의 세 가지 방식

프로그래밍 언어들은 메모리를 관리하는 방식이 다릅니다:

1. 가비지 컬렉션 (Go, Java, Python, JavaScript)

// Go: GC가 알아서 정리
func example() {
 slice := make([]int, 1000000)
 // 함수 종료 후 GC가 언젠가 정리
}

장점: 개발자가 메모리 관리 신경 안 써도 됨
단점: GC 일시 정지, 예측 불가능한 지연, 메모리 오버헤드

2. 수동 관리 (C, C++)

Go to Rust: #2. 기본 문법과 타입 시스템

Mon, 19 Jan 2026 09:55:56 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

이 섹션에서는 Rust의 기본 문법을 Go와 비교하며 학습합니다. Go 개발자에게 익숙한 개념들이 Rust에서 어떻게 표현되는지, 그리고 Rust만의 독특한 특징은 무엇인지 알아봅니다.

2.1 변수와 가변성

let vs var: 불변이 기본인 이유

Go에서는 변수가 기본적으로 가변(mutable)입니다:

// Go: 기본이 가변
x := 10
x = 20 // OK

Rust에서는 불변(immutable)이 기본입니다:

// Rust: 기본이 불변
let x = 10;
x = 20; // 컴파일 에러!

왜 불변이 기본일까요?

Go to Rust: #1. 시작하기 - Rust 소개와 환경 설정

Mon, 19 Jan 2026 09:55:50 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Go 개발자로서 새로운 언어를 배우려면 먼저 그 언어가 왜 존재하는지, 어떤 문제를 해결하려고 하는지 이해하는 것이 중요합니다. 이 섹션에서는 Rust의 설계 철학을 Go와 비교하며 이해하고, 개발 환경을 설정한 뒤 첫 프로젝트를 생성해봅니다.

1.1 Rust는 왜 배워야 하는가?

Rust의 설계 철학

Rust는 Mozilla Research에서 시작되어 2015년에 1.0이 릴리스된 시스템 프로그래밍 언어입니다. Rust의 핵심 목표는 세 가지입니다:

안전성(Safety): 메모리 안전성을 컴파일 타임에 보장
속도(Speed): C/C++에 필적하는 성능
동시성(Concurrency): 데이터 레이스 없는 동시성 프로그래밍

Go도 비슷한 시기(2009년)에 등장했지만, 설계 목표가 다릅니다:

Go to Rust: #0. Overview

Mon, 19 Jan 2026 08:36:02 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

From Go to Rust: A Comprehensive Guide for Go Developers

Go 언어에 익숙한 개발자가 Rust를 체계적으로 학습할 수 있도록 구성된 가이드입니다. Go와의 비교를 통해 새로운 개념을 빠르게 이해하고, 실무에서 바로 적용할 수 있는 실용적인 내용을 담았습니다.

가이드의 특징

Go 개발자 관점: 모든 개념을 Go와 비교하여 설명, 익숙한 개념에서 출발
실용적 접근: 이론보다 실제 코드 예제 중심
점진적 난이도: 기초부터 고급까지 체계적 진행
실전 지향: 각 섹션에 Go ↔ Rust 코드 변환 예제 포함
함정 주의: Go 개발자가 흔히 하는 실수와 해결법 명시

섹션별 상세 목차

Section 1: 시작하기 - Rust 소개와 환경 설정

Rust의 설계 철학을 이해하고, Go와의 포지셔닝 차이를 명확히 합니다. 개발 환경을 설정하고 첫 프로젝트를 생성합니다.

Go 웹 애플리케이션에서 static contents를 서빙하는 표준 패턴

Wed, 26 Nov 2025 08:07:14 +0900

복잡한 nginx 설정 파일, CDN 연동, 그리고 정적 파일 경로 문제로 골머리를 앓으신 적 있으신가요? Go 표준 라이브러리만으로도 정적 파일(CSS, JavaScript, 이미지 등)을 우아하게 서빙할 수 있습니다. 이번 글에서는 Go 웹 애플리케이션에서 static contents를 서빙하는 표준 패턴을 알아보겠습니다. http.FileServer, http.Dir, 그리고 http.StripPrefix의 조합만으로 프로덕션 레벨의 static file serving을 구현할 수 있습니다.

이 글은 GOTH Stack 웹 애플리케이션 개발 과정에서 발견한 패턴을 Claude Sonnet 을 이용해 정리한 것입니다.

문제 상황: URL과 파일 시스템 경로의 불일치

웹 애플리케이션을 개발하다 보면 다음과 같은 구조를 자주 마주치게 됩니다:

Go 웹 개발의 새로운 파도: GOTH 스택 (Go, Templ, HTMX) 시작하기

Mon, 24 Nov 2025 18:12:06 +0900

복잡한 리액트(React) 상태 관리, 비대해진 node_modules, 그리고 끝없는 JSON 직렬화/역직렬화에 지치셨나요? 백엔드 개발자에게 가장 편안한 언어인 Go를 사용하면서도, 현대적인 SPA(Single Page Application) 같은 사용자 경험을 제공하는 GOTH 스택을 소개합니다. GOTH(Go + Templ + HTMX) 스택은 최근 Go 커뮤니티에서 “다시 재미있게 웹 개발을 하자(Make Web Dev Fun Again)” 는 흐름과 함께 큰 주목을 받고 있습니다. 복잡한 JS 프레임워크 없이 Go의 강점인 단순함과 성능을 그대로 살릴 수 있는 것이 특징입니다.

이 글은 요청에 대한 Gemini 3 Pro 의 답변입니다.

Go: `net/http` vs. `chi`

Mon, 24 Nov 2025 17:49:44 +0900

Go 언어의 웹 생태계에서 net/http (표준 라이브러리) 와 chi 는 가장 “Go스러운(Idiomatic)” 선택지로 꼽힙니다. Gin이나 Echo 같은 “웹 프레임워크"와 달리, chi는 표준 라이브러리의 인터페이스를 그대로 따르면서 부족한 라우팅 기능을 보강해주는 “라우터"이기 때문입니다.

특히 Go 1.22 버전부터 net/http의 라우팅 기능이 대폭 강화되었기 때문에, 이 둘의 차이를 명확히 이해하는 것이 중요합니다.

이 글은 요청에 대한 Gemini 3 Pro 의 답변입니다.

1. `net/http` vs `chi` 요약 비교

특징	`net/http` (Go 1.22+)	`chi`
외부 의존성	없음 (Zero dependency)	있음 (But 매우 가벼움)
인터페이스	`http.Handler`	`http.Handler` (100% 호환)
라우팅 (Path)	지원 (`/items/{id}`)	강력하게 지원 (Regex 등 포함)
메서드 매칭	지원 (`POST /items`)	지원 (`r.Post("/items", ...)`)
미들웨어 관리	직접 구현 필요 (복잡함)	매우 강력하고 간편함 (`Use`)
라우팅 그룹	직접 구현 필요	기본 지원 (`Group`)
속도	빠름	매우 빠름 (Radix Tree 기반)

2. 왜 앱이 커질수록 `chi`가 유리한가?

앱이 복잡해진다는 것은 엔드포인트가 많아지고, 공통 로직(인증, 로깅, CORS 등)이 복잡해진다는 뜻입니다. 이 지점에서 chi가 net/http보다 압도적인 강점을 가집니다.

Go 패키지 구조 컨벤션: Standard Go Project Layout

Tue, 26 Aug 2025 19:34:33 +0900

Go 언어 프로젝트의 패키지 구조는 일반적으로 몇 가지 컨벤션을 따르며, pkg와 internal 디렉토리는 그중 핵심적인 역할을 합니다. 단순히 코드를 기능별로 묶는 것을 넘어, 패키지의 가시성(visibility)과 의존성 방향을 명확히 하여 프로젝트의 유지보수성을 높이는 것이 목적입니다.

이 글은 Gemini 2.5 Pro 모델이 제 Go package convention 에 대한 질문에 답변한 내용입니다.

Go 커뮤니티에서 널리 통용되는 표준 프로젝트 레이아웃(golang-standards/project-layout)을 기반으로 각 디렉토리의 역할과 베스트 프랙티스를 자세히 설명해 드리겠습니다.

📦 `pkg` 디렉토리: 공개 라이브러리 (Public Library)

pkg 디렉토리에는 외부 프로젝트에서 가져다 쓸 수 있는(importable) 공개 라이브러리 성격의 코드를 위치시킵니다.

Go 언어의 풍부한 표준 라이브러리 (Batteries Included)

Tue, 19 Aug 2025 12:55:41 +0900

Go 언어의 특징을 소개하는 시리즈의 세 번째 글입니다. 이전 글에서는 Go의 단순성과 동시성에 대해 다루었습니다. 이번에는 Go가 ‘건전지 포함(Batteries Included)’ 철학을 어떻게 구현하고 있는지, 즉 강력하고 풍부한 표준 라이브러리에 대해 이야기하고자 합니다.

(이 글은 Gemini 2.5 Pro 모델에 의해 작성되었으며, 커버하고 있는 세부 항목들과 글의 톤/매너에 대한 요구사항들은 제가 정리해서 Gemini 에 요청했습니다. 내용에 잘못된 부분이 있을 수 있는데, 그런 경우 잘못된 정보에 대한 댓글을 남겨주시면 감사하겠습니다.)

Go 창시자들의 철학: 실용성과 안정성

Go 언어의 설계 철학은 구글의 대규모 프로덕션 환경에서 마주친 문제들을 해결하는 데서 출발했습니다. 언어의 창시자들인 로버트 그리즈머(Robert Griesemer), 롭 파이크(Rob Pike), 켄 톰슨(Ken Thompson) 은 복잡한 외부 의존성 없이도 당장 현장에서 필요한 대부분의 기능을 수행할 수 있는 언어를 원했습니다.

Go 의 동시성 (concurrency) 더 들여다보기

Mon, 11 Aug 2025 13:39:08 +0900

현대의 컴퓨터는 멀티코어 프로세서를 기반으로 작동하며, 동시성(Concurrency)은 더 이상 선택이 아닌 필수적인 프로그래밍 패러다임이 되었습니다. Go 언어는 설계 초기부터 동시성을 핵심 기능으로 채택했으며, 전통적인 스레드-락(Thread-Lock) 모델의 복잡성을 해결하기 위한 명확한 철학을 제시합니다.

이 글에서는 Go의 동시성 모델이 어떠한 철학 위에서 탄생했는지 살펴보고, 다른 주류 언어들과의 접근 방식을 비교 분석합니다. 이를 통해 Go의 동시성이 갖는 장점과 현실적인 트레이드오프를 가감 없이 설명하고자 합니다.

Go 의 단순함(simplicity) 더 들여다보기

Thu, 07 Aug 2025 08:08:20 +0900

Go 언어의 철학을 관통하는 가장 중요한 단어는 바로 ‘단순함(Simplicity)’ 입니다. 이는 단순히 기능이 적다는 의미가 아니라, 복잡한 문제를 명료하고 예측 가능하게 해결하기 위한 의도적인 설계 철학입니다. Go의 창시자 중 한 명인 롭 파이크(Rob Pike)는 “단순함은 복잡하다(Simplicity is Complicated)“고 말했습니다. 최고의 단순함을 성취하기 위해 수많은 고민과 트레이드오프가 있었음을 암시하는 말이죠.

이 글에서는 Go의 핵심 철학인 ‘단순함’이 코드 수준에서 어떻게 드러나는지, 그리고 이 철학이 왜 어떤 개발자에게는 최고의 장점이 되고 다른 개발자에게는 답답한 단점으로 여겨지는지 가감 없이 살펴보겠습니다.

Go 는 왜 LLM 기반 Vibe-Coding에 적합한 언어인가?

Thu, 31 Jul 2025 11:55:18 +0900

이 글에서는 LLM을 활용한 Vibe-Coding 시대에 Go 언어가 가지는 장점들을 알아봅니다.

(영문 글을 번역했던 블로그 대부분의 포스트와는 달리 이 글은 제가 초안을 작성하고, Gemini 의 도움을 받아 개선된 originality 가 있는 글입니다.)

1. 강력한 정적 타입 시스템과 컴파일 단계

Go는 정적 타입 언어이며 컴파일을 통해 실행 파일을 만듭니다. 이는 코드가 실행되기 전, 즉 컴파일 시점에 타입 불일치, 함수 인자 오류, 존재하지 않는 변수 참조 등 수많은 오류를 미리 잡아낼 수 있음을 의미합니다.

번역글: Go의 동시성: 심층 분석

Mon, 07 Jul 2025 13:43:14 +0900

원문: https://medium.com/hprog99/concurrency-in-go-a-deep-dive-2abbb4838984 (Translated by Google Gemini)

서론

동시성이란 무엇인가?

동시성은 독립적인 활동들의 구성으로 느슨하게 정의될 수 있습니다. 반드시 병렬 실행을 필요로 하지는 않지만, 여러 태스크가 겹치는 시간 동안 진행되도록 허용합니다. 컴퓨팅의 맥락에서 동시 프로그래밍은 여러 태스크가 실행에서 인터리브(interleave - 여러 대상을 번갈아 가며 실행하거나 배치) 될 수 있도록 보장하며, 이는 특히 I/O 바운드 태스크나 수많은 이벤트를 동시에 처리해야 하는 애플리케이션(예: 웹 서버에서 여러 클라이언트 연결 처리)에서 중요합니다.

동시성 vs. 병렬성

비공식적인 대화에서 종종 혼용되지만, 동시성과 병렬성은 다른 개념입니다.

번역글: Golang 공동 창시자 Rob Pike: Go가 잘한 것과 잘못한 것

Wed, 02 Jul 2025 10:28:40 +0900

원문: https://thenewstack.io/golang-co-creator-rob-pike-what-go-got-right-and-wrong/ (Translated by Google Gemini)

GopherCon AU 참석자들은 Go의 사양이 처음 작성된 도시인 호주 시드니에서 특별한 대접을 받았습니다. Go의 공동 설계자 중 한 명인 Rob Pike는 Go 프로그래밍 언어가 출시된 지 14주년이 되는 날을 기념하며 “무엇을 제대로 했고, 무엇을 잘못했는지” 돌아보는 강연을 했습니다.

Pike는 2009년 11월 10일 웹사이트가 처음 공개되던 순간을 기억하며 “세상이 우리가 무엇을 해왔는지 알게 되었다”고 말했습니다.

“14년이 지난 지금, 돌아볼 것이 많습니다.”라고 Pike는 청중에게 말하며 “더 큰 교훈들”을 탐구하겠다고 약속했습니다.

Golang on philipjkim

렉시오 CPU 플레이어 만들기 Part 6: 봇이 약한지 어떻게 아는가

눈으로 한 판 돌려서는 못 보는 것

렉시오 CPU 플레이어 만들기 Part 5: 봇이 아무것도 하지 않는 이유

설계와 구현 사이

달무티 CPU 플레이어 만들기 Part 4: 만들어 보니 hard 봇이 더 약했다

설계안이 검증을 만나면

렉시오 CPU 플레이어 만들기 Part 4: 수 평가와 정산 기대값

재료에서 결정으로

렉시오 CPU 플레이어 만들기 Part 3: 손패 분해 플랜

좋은 손패는 센 손패가 아니다

렉시오 CPU 플레이어 만들기 Part 2: 60비트 카운팅과 확실승수 판정

hard 봇이 지켜야 할 세 가지

렉시오 CPU 플레이어 만들기 Part 1: 타일 하나를 정수 하나로

사촌 게임, 전혀 다른 봇

달무티 CPU 플레이어 만들기 Part 3: 수 평가와 전략적 패스

재료에서 결정으로

달무티 CPU 플레이어 만들기 Part 2: hard 봇의 정보 모델과 확실승수 판정

hard 봇이 지켜야 할 세 가지

달무티 CPU 플레이어 만들기 Part 1: 규칙 기반 easy 봇

왜 봇부터 만드는가

2021년의 Go를 2026년의 Go로 Part 3: 동시성·런타임·운영 레시피

들어가며

레시피 1: 수동 취소·타임아웃 관리 대신 context 신규 API (1.21)

2021년의 Go를 2026년의 Go로 Part 2: 표준 라이브러리 레시피

들어가며

2021년의 Go를 2026년의 Go로 Part 1: 언어와 문법 레시피

들어가며: 5년 동안 Go에 무슨 일이 있었나

Agentic Coding 시대의 Repo 부트스트래핑 가이드 Part 2: Go + Templ + HTMX To-Do 앱으로 직접 만들어 보기

가상 프로젝트: gotodo

Go 웹 프레임워크 비교: Chi vs. Gin

설계 철학: 라우터 vs. 프레임워크

HTMX와 함께 사용할 Go 템플릿 기술 비교: html/template vs. Templ

타입 안전성

Redis를 활용한 초경량 메시징 전략: Pub-Sub과 Worker Queue 완벽 정리

1. 왜 Redis 메시지 큐인가?

GoTHIC 스택으로 JavaScript 없이 모던 웹앱 만들기

GoTHIC 스택이란

Java to Go: #5. 프로젝트 구조와 생태계

1. Go Modules 기초

go.mod와 go.sum

Java to Go: #4. 동시성: Goroutine과 Channel

1. Goroutine: 경량 스레드

go 키워드 하나로 시작하는 동시성

Java to Go: #3. 에러 처리와 Null 안전성

1. Java의 Exception vs Go의 error

근본적인 차이

Java to Go: #2. 문법 전환 가이드: Java 코드를 Go로 옮기기

1. 변수 선언과 타입 시스템

기본 변수 선언

Java to Go: #1. Go 첫인상: 철학과 패러다임의 차이

1. Go의 설계 철학: “Less is more”

Go to Rust: #10. 프로젝트 관리와 실전 패턴

10.1 Cargo 심화

Cargo.toml 상세 설정

의존성 관리

Go modules와 비교

피처 플래그

10.2 모듈 시스템

파일 시스템과 모듈 구조

Go to Rust: #9. 비동기 프로그래밍

9.1 비동기의 필요성

동기 vs 비동기

Go의 goroutine 모델

Go to Rust: #8. 동시성 프로그래밍

8.1 Rust의 동시성 철학

“Fearless Concurrency"란?

데이터 레이스의 세 가지 조건

Go to Rust: #7. 컬렉션과 이터레이터

7.1 표준 컬렉션 개요

Go와 Rust 컬렉션 매핑

7.2 Vec 심화

생성 방법들

기본 연산

Go의 append vs Rust의 push

소유권과 Vec

슬라이싱

7.3 문자열 처리

String vs &str

UTF-8 인코딩

레시피 1: 수동 취소·타임아웃 관리 대신 `context` 신규 API (1.21)

가상 프로젝트: `gotodo`

1. `net/http` vs `chi` 요약 비교

2. 왜 앱이 커질수록 `chi`가 유리한가?

📦 `pkg` 디렉토리: 공개 라이브러리 (Public Library)