대부호 CPU 봇의 성적표는 처음부터 몬테카를로였고, 지금 운영 중인 봇은 상대 손패를 열여섯 번 뽑아 판 끝까지 두어 보고 수를 고릅니다. 시리즈가 검산하지 않고 남긴 장부의 위험 근사를 실제 게임의 3,479개 평가에서 몬테카를로로 다시 재고, 운영 봇의 탐색을 4,000개 표본으로 재현했습니다.

몬테카를로 시뮬레이션은 계산으로 구하기 어려운 확률을 무작위 시행을 세어서 구하는 방법입니다. 울람의 솔리테어에서 시작한 역사와 표본 평균, 1/√n 으로 줄어드는 오차를 정리하고, 몬티 홀·생일 문제·드 메레의 주사위를 Go 로 돌려 봅니다.

Pragmatic Programmers의 Dave Thomas가 쓴 뉴스레터 ‘The Build or Buy Decision Isn’t Just About Cost’의 한국어 번역. AI가 코드를 대신 써 주는 시대에도 직접 만들기보다 가져다 쓰는 쪽이 나은 이유를 실전 검증, 유지보수, 의심, AI 지원의 공백이라는 네 가지 비용으로 짚습니다.

이야기와 게임과 코드 속의 공유지를 모았습니다. 봉화를 꺼뜨린 『파리대왕』의 소년들과 실제로 1년 넘게 불을 지킨 통가의 소년들, 설득과 위협과 폭력 사이를 오가는 『더 플랫폼』의 수직 감옥, 죽은 자의 물이 부족의 것인 『듄』, 공유지에 울타리를 친 『콘크리트 유토피아』, 그리고 비극의 대명사였던 이스터섬 이야기가 최근 연구로 흔들리는 과정을 봅니다. 울티마 온라인의 양털이 바닥난 진짜 이유와 보드게임 데이브레이크, 하트블리드에서 xz 백도어와 AI 크롤러까지 오픈소스라는 공유지를 짚고, 전체 유형 분류표와 일곱 시리즈 정리로 마칩니다.

대부호 hard 봇의 최종 시험입니다. 시험 문제를 열기 전에 합격선 여섯 개를 커밋으로 못 박은 절차, 한 번도 쓰지 않은 딜 128개에서 한 번만 돌린 결과(easy 대비 −0.746, 4인 1등 비율 61%, 반칙패 0), 봇의 손패와 결정 단계를 수마다 눈으로 읽은 재생, 기본 봇으로 올리면서 남긴 뒷길, 그리고 이 결과로 말할 수 있는 것과 아직 말할 수 없는 것을 정리합니다.

대부호 hard 봇을 시뮬레이터로 잽니다. 운영 서버와 같은 결정 경로를 타면서 수 하나를 6ms 에서 30µs 로 줄인 메모리 엔진, 봇 하나를 셋 사이에 앉히는 양방향 비교가 왜 필요했는지, 같은 봇끼리 정확히 0 이 나오는 장치 검사, 그리고 hard 의 판단 항목을 하나씩 켜고 꺼 본 결과 규칙 세 개가 개선의 91% 를 차지했고 두 항은 해로워서 지웠으며 문턱 하나를 네 배로 올린 이야기입니다.

대부호 easy 봇과 hard 봇이 같은 자리에서 무엇을 다르게 보고 다르게 고르는지를 그림 하나로 비교합니다. hard 의 결정은 «즉시 끝내기 → 확정 종료 줄 → 정상 종료 가드 → 위협 차단 → 점수» 순이고, 점수는 easy 의 수를 기본으로 두고 문턱을 넘을 때만 바꿉니다. 네 가지 점수 항(계획 진척·통제·온존·8컷)과 받을 수 있어도 패스하는 이유, 조공 돌려주기까지 카드 게임 용어로 설명합니다.

대부호 hard 봇이 자기 손패를 어떻게 보는지 다룹니다. 남은 카드를 최소 몇 수에 낼 수 있는지와 그 마지막 수가 합법인지를 따로 세는 이유, 같은 숫자 4장을 내면 서열이 뒤집혀 끝내기 카드가 바뀌는 것을 부분집합 표에 홀짝 하나로 담는 방법, 그리고 상대가 아무도 받을 수 없다는 장부의 증명을 이어 붙여 만드는 확정 종료 줄을 설명합니다.

대부호 hard 봇이 무엇을 보는지 다룹니다. 사람 화면에 이미 보이는 것만 시야에 더한 이유, 54장을 내 손패·나온 카드·위치를 아는 카드·미확인 카드 넷으로 나누는 장부, 패스한 자리의 위험이 정확히 0 인 대부호만의 사정, 그리고 “이 수를 내면 누가 받을 수 있는가” 를 재는 위험 점수가 왜 확률이 아니라 근사 점수인지를 설명합니다.

대부호 easy 봇을 규칙 네 줄로 만듭니다. 리드는 가장 약한 숫자를 통째로 내되 계단이 더 털면 계단, 받기는 이기는 가장 약한 수, 반칙 끝내기는 다른 수가 있으면 피하고, 조공은 가장 약한 카드를 돌려줍니다. 시간 초과 자동 수와 같은 함수여야 하는 이유, 이 봇이 우연히 잘하는 것, 그리고 열 판에 한 판꼴로 반칙패로 끝나는 이유를 정리합니다.

대부호(大富豪)를 디지털 게임으로 만들 때 CPU 플레이어를 어떻게 설계했는지 다루는 시리즈입니다. Part 1 에서는 달무티·렉시오·훌라 봇을 만들며 얻은 교훈을 정리하고, 대부호의 규칙 열 가지가 봇에게 왜 새로운 문제인지 짚은 뒤, 봇이 볼 수 있는 것과 돌려줘야 하는 것의 계약을 Go 코드로 못 박습니다.

잘 두는 사람에게서 찾은 세 가지 습관을 hard 봇에 넣었습니다. 바꾸기 전과 후의 판단 흐름을 그림으로 나란히 놓고, 새 봇이 구버전 봇들 사이에서 얼마나 세졌는지, 그리고 아직 말할 수 없는 것이 무엇인지를 코드 없이 정리합니다.

hard 봇을 열 판 중 여섯 판 이긴 사용자의 결정 6,746개를, 같은 순간 봇이 냈을 수와 하나씩 비교했습니다. 대부분은 같았습니다. 갈라진 자리는 셋이었습니다. 강한 한두 장으로 리드를 지키고, 초반에 최상위 카드를 아끼고, 받을 때 딱 이길 만큼만 씁니다.

hard 봇 세 명을 상대로 사람이 판의 59.8% 를 1등으로 끝냈습니다. 공정하다면 25% 여야 합니다. 가장 많이 플레이한 사용자에게는 hard 와 easy 의 차이가 0.2%p 였습니다. 코드 없이, 무엇을 어떻게 쟀고 왜 봇이 사람에게 읽혔는지를 정리합니다.

DHH 의 Rails World 2026 키노트에 쏟아진 반응을 Hacker News 스레드 두 개, 참석자와 커뮤니티 구성원의 블로그, GeekNews 댓글, 그리고 이틀 뒤 Aaron Patterson 의 폐막 키노트까지 모아 비판·옹호·절충의 세 갈래로 정리합니다. 쟁점은 AI 가 아니라 「Rails 는 어디 갔나」였습니다.

2026년 9월 23일 Rails World 2026 개막 키노트에서 DHH 는 37signals 가 손으로 코드를 쓰는 일을 그만두었고, HEY 를 Rails 웹앱에서 네이티브 앱 6개와 Rust 백엔드로 다시 만들고 있다고 밝혔습니다. 한 시간짜리 연설을 챕터 순서대로 재구성하고, 그가 제시한 숫자들을 1차 출처와 대조합니다.

Rapfi 를 소스에서 빌드하고 Piskvork 프로토콜로 직접 대화해 봅니다. 탐색 로그 읽는 법, 같은 국면이 자유룰과 렌쥬에서 어떻게 달라지는지, 花月 주형의 Multi-PV 분석, STRENGTH 로 기력 낮추기, MCTS 탐색기, 파이썬으로 엔진 부리기까지 Apple M1 Max 에서 실제로 실행한 결과로 보여 줍니다.

Rapfi 의 소스 코드를 따라가며 한 수를 고르기까지의 의사결정 과정을 해부합니다. 선 패턴 16종과 네 방향 조합 14종으로 판을 읽는 법, 렌쥬 금수의 정확한 판정, 고전 평가와 NNUE(mix9svq)를 섞어 쓰는 방식, Stockfish 에서 가져온 알파-베타 탐색과 VCF 잎 탐색, 선택 사항인 MCTS, 시간 관리와 멀티스레드까지 정리합니다.

포커 같은 트럼프 게임 글의 예제를 글자가 아니라 카드 그림으로 보여 주기 위해 Hugo shortcode 두 개를 만들었습니다. As Kh 같은 포커 표준 표기를 SVG 카드로 바꾸는 cards(도해)와 card(문장 안 한 장)의 사용법, 이미지·이모지·mermaid 대신 SVG 를 고른 이유, 무늬를 이모지가 아니라 글자로 그린 이유, 그리고 실제 렌더링 예를 정리했습니다.

«A Philosophy of Software Design» 19~21장으로 8부작을 맺습니다. struct embedding 으로 흉내 낸 구현 상속에서 ‘덮어쓴’ 메서드가 부모의 호출에는 적용되지 않는 함정을 재현하고 인터페이스 합성으로 바꾸며, 저자의 TDD 비판을 공정하게 옮기고 반론을 덧붙입니다. 20장의 RAMCloud Buffer 예제를 Go 로 옮겨 ‘측정 먼저’ 를 실제로 해 본 결과는 책의 2배가 아니라 10% 였고, 그 숫자를 그대로 싣습니다. 마지막으로 시리즈 전체를 위험 신호 표 하나로 정리합니다.