Part 5 는 브라우저에서 한 판 돌려 찾은 결함을 고쳤습니다. 그 방법으로는 “조금 약하다"를 찾을 수 없어 시뮬레이터를 만들었더니, 도구가 전략을 재기도 전에 구현 버그부터 잡아냈습니다. 그리고 봇이 약한 이유를 세 번 틀리고 네 번째에 찾았습니다. 평가 함수는 처음부터 옳았고, 확률이 틀렸습니다.

Part 1~4 에서 설계한 렉시오 hard 봇을 실제로 구현했더니 봇이 거의 모든 턴을 패스했습니다. 개별 항은 전부 맞았고 항을 합치는 방식이 틀렸습니다. 평가 함수가 무너지는 네 가지 자리와, 그 회귀 테스트가 엉뚱한 이유로 통과한 이야기를 다룹니다.

Part 1부터 3까지의 설계안을 실제로 구현해 시뮬레이션으로 재봤더니, hard 봇이 easy 봇보다 평균 0.6601등 나빴습니다. 무엇을 어떻게 쟀는지, 세 개의 구조 결함이 무엇이었는지, 어떤 고급 기능이 살아남았는지, 그리고 정정 후의 정식 검증 수치를 정리합니다.

렉시오 hard 봇의 목적 함수를 정산 구조에서 직접 유도합니다. 수 평가 함수의 항을 분해하고, 낼 수 있어도 참아야 하는 여섯 가지 상황을 정리하며, 이길 수 없다고 판단했을 때 봇이 손실 최소화 모드로 전환하는 기준을 다룹니다.

렉시오 hard 봇이 자기 손패를 몇 번에 털 수 있는지 정확히 계산합니다. 유효 조합으로의 최소 분할을 비트마스크 DP 로 풀고, 탐욕법이 왜 다섯 번에 한 번꼴로 최적을 놓치는지, 그리고 DP 한 번이 왜 모든 후보의 평가까지 공짜로 끝내 주는지 다룹니다.

렉시오 hard 봇이 무엇을 아는지 다룹니다. 미공개 타일을 uint64 하나로 정확히 복원하고, 이 수를 아무도 못 받는다는 판정을 확률이 필요 없는 구조적 영역과 확률이 필요한 영역으로 나누며, 패스 로그를 비트마스크 제약으로 환산합니다.

렉시오(Lexio)를 디지털 게임으로 만들 때 CPU 플레이어를 어떻게 설계할지 다룹니다. Part 1 에서는 타일 60장을 정수 하나로 압축하는 표현을 잡고, 공식 룰의 비교 규칙을 정수 키 하나로 환원한 뒤, 결정적 규칙만으로 동작하는 easy 봇을 Go 코드로 구현합니다.

달무티 hard 봇이 실제로 어떤 수를 고르는지 다룹니다. 리드권 확보 확률과 가치를 분리한 수 평가 함수, 낼 수 있어도 참는 전략적 패스, 차단 의무의 정확한 조건, 세금과 혁명의 기대값 계산, 그리고 봇이 정말 세졌는지 재는 검증 방법을 Go 코드로 정리합니다.

달무티 hard 봇이 상대 손패를 훔쳐보지 않고 무엇을 알아낼 수 있는지 다룹니다. 오차 0의 카드 카운팅, 패스를 확정 정보가 아닌 확률적 증거로 다루는 법, 광대 2장이 만드는 구조적 확실승수 판정, 그리고 손패의 최소 제출 횟수 플랜을 재현 가능한 몬테카를로 수치와 함께 정리합니다.

달무티(The Great Dalmuti)를 디지털 게임으로 만들 때 CPU 플레이어를 어떻게 설계할지 다룹니다. Part 1 에서는 공정성 경계와 정책 인터페이스를 잡고, 결정적 규칙만으로 동작하는 easy 난이도 봇의 제출·패스·혁명·세금 정책을 Go 코드로 구현합니다.

2021~22년 Go 코드의 동시성·런타임·툴체인·운영 관용구를 2026년 Go 1.26 기준으로 다시 쓰는 레시피. context 신규 API, sync.WaitGroup.Go, testing/synctest, 컨테이너 인식 GOMAXPROCS, PGO와 Green Tea GC, go.mod tool 디렉티브, os.Root를 Before/After로 정리합니다.

2021~22년 Go 코드의 표준 라이브러리 관용구를 2026년 Go 1.26 기준으로 다시 쓰는 레시피. slices/maps/cmp, log/slog 구조적 로깅, errors.Join, math/rand/v2, encoding/json omitzero·v2, net/http 라우팅 강화를 Before/After로 정리합니다.

202122년 Go(1.161.18) 관용구에 멈춰 있는 코드를 2026년 Go 1.26의 신규 언어 기능으로 다시 쓰는 레시피. 제네릭, min/max/clear, 루프 변수 시맨틱, range-over-int, 이터레이터, 제네릭 타입 별칭을 Before/After로 정리합니다.

Part 1 에서 정리한 spec 문서 지형도를 가상의 Go + Templ + HTMX To-Do 앱 gotodo 를 부트스트래핑하면서 실제로 채워 봅니다. README, AGENTS.md, ARCHITECTURE.md, ADR, DEVELOPMENT.md, 첫 feature spec 까지 발췌 형태로 살펴보고, 마지막에 Claude Code 로 검증한 뒤 가져다 쓸 수 있는 체크리스트로 마무리합니다.

Go 웹 개발의 양대 선택지인 Chi와 Gin을 설계 철학, 라우팅, 미들웨어, 데이터 바인딩, 성능, 생태계 등 다양한 관점에서 비교 분석합니다. 각각의 강점과 약점을 이해하고, 프로젝트 성격에 따라 어떤 것을 선택해야 하는지 가이드를 제공합니다.

Go로 SSR 웹 앱을 만들 때 HTMX와 함께 사용할 템플릿 기술로 html/template + 커스텀 PageRenderer와 Templ을 비교합니다.

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

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

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

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