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

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

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

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

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

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

달무티를 할 줄 아는 사람은 일본의 국민 카드게임 대부호를 10분이면 배웁니다. 클라이밍·계급·조공은 그대로이고, 덱과 서열·조합·혁명의 뜻·자리의 불안정성 네 가지가 다릅니다. 일본대부호연맹 공식 룰을 기준으로 처음 배울 규칙을 카드 그림으로 정리하고, 로컬 룰의 인지도, 달무티 경험이 통하는 것과 배신하는 것, 그리고 왜 배울 만한지를 적습니다.

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

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

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

Rapfi 를 엔진으로 오목·렌쥬 서비스를 만들 때 고려할 점을 정리합니다. 서버·브라우저(WASM)·앱 배치에 따라 달라지는 GPLv3 의무, 상태를 가진 Piskvork 프로토콜을 다루는 프로세스 모델과 Go 래퍼, 판 크기와 렌쥬 오프닝 규정의 공백, 초보자용 난이도 설계의 함정, 자원·버전 관리까지 실측과 소스 근거로 짚습니다.

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

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

알파-베타 탐색과 초경량 NNUE 로 CPU 에서 초당 수십만 노드를 읽는 Rapfi 와, 큰 신경망과 MCTS 로 GPU 에서 수천 번을 읽는 KataGo(오목판 KataGomo)를 비교합니다. 탐색·평가·하드웨어·학습·프로토콜·라이선스를 나란히 놓고, ‘어느 쪽이 더 강한가’ 라는 질문에 1차 출처가 실제로 답하는 범위가 어디까지인지 정리합니다.

현재 가장 강력한 오픈소스 오목·렌쥬 엔진인 Rapfi 를 다섯 편에 걸쳐 분석합니다. 첫 편은 2026년 기준 오목·렌쥬 오픈소스 생태계(엔진·GUI·프로토콜·대회)를 훑고, Rapfi 가 2018년 Gomocup 4위에서 2022년 이후 사실상 전 리그를 제패하기까지의 역사를 1차 출처로 정리합니다.

렌쥬의 26가지 정형 오프닝(珠型) 중 백 2수가 흑 1수에 가로·세로로 붙는 직접형(直接) 13가지를 도해와 함께 소개합니다. 寒星부터 遊星까지 각 주형의 이름, 모양, 옛 RIF 룰 기준 평가를 정리하고 시리즈를 마무리합니다.

렌쥬의 26가지 정형 오프닝(珠型) 중 백 2수가 흑 1수에 대각선으로 붙는 간접형(間接) 13가지를 도해와 함께 소개합니다. 長星부터 彗星까지 각 주형의 이름, 모양, 옛 RIF 룰 기준 평가를 정리합니다.

오목과 렌쥬가 이론적으로 흑 필승임이 어떻게 증명되었는지, 일본 연주계가 흑 금수를 하나씩 더해 온 과정, 그리고 RIF 룰에서 야마구치 룰, Soosõrv-8, Taraguchi-10 까지 스왑(색 교환) 오프닝 규정이 발전해 온 이유를 정리합니다.

오목의 기본 규칙과 한국에서 흔히 두는 오목, 그리고 국제 경기 규칙인 렌쥬(連珠)의 차이를 정리합니다. 흑에게만 적용되는 삼삼·사사·장목 금수의 정확한 정의를 도해로 살피고, 렌쥬가 정말 국제 표준인지 1차 출처로 확인합니다.

훌라 초보자 전략 가이드 마지막 편. 앞의 다섯 편에서 세운 주요 원칙을 적용한 4인 한 판을 딜부터 정산까지 턴별로 복기합니다. 첫 공개 카드의 땡큐, 조각을 지킨 버리기, 좌석 순서 1순위 땡큐, 7 의 이웃을 남긴 버리기, 확정 구간을 확인한 일반 스톱, 손패를 공개해 검산한 정산까지 카드 그림으로 따라가고, 턴마다 보는 체크리스트와 흔한 실수 열 가지, 인원별 차이, 확률표를 만든 스크립트를 부록으로 붙입니다.