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차 출처로 정리합니다.

훌라 hard 봇의 값을 동결하고, 한 번도 쓰지 않은 딜 256개에서 최종 검증을 합니다. 실험이 고른 값을 일부러 쓰지 않은 자리와 그 이유, 시험 문제를 열기 전에 합격선을 못 박는 절차, 인원이 늘수록 두 배씩 벌어진 결과, 그리고 Part 4 의 여덟 자리 중 무엇이 메워졌고 무엇이 메운 줄 알았는데 아니었는지를 결산합니다.

훌라 hard 봇을 시뮬레이터로 잽니다. 같은 딜에서 hard 와 easy 를 바꿔 앉혀 딜 운을 지우는 방법, 도구가 만들어지자마자 잡은 “다른 봇을 재고 있었다” 는 버그, 8 seed 로는 아무 말도 못 하고 32 seed 에서야 방향이 보인 첫 성적, 그리고 손으로 정한 추 열한 개를 하나씩 빼 보니 넷은 5만 번의 결정에서 수를 하나도 바꾸지 않았다는 사실까지 다룹니다.

훌라 hard 봇의 땡큐와 스톱 판단을 다룹니다. 땡큐는 가져갔을 때와 안 가져갔을 때를 같은 자로 재야 한다는 것, 봇을 남의 차례에 깨우는 배선이 없으면 시뮬레이터에서 98% 를 가져가던 봇이 실제 서버에서는 한 번도 못 건다는 것, 일반 스톱은 기대값으로 판단하되 첫 구현에서 건 스톱의 36% 가 스톱박이 나 확률부터 고쳐야 했다는 이야기입니다.

훌라 hard 봇이 자기 차례에 무엇을 알고 어떻게 한 수를 고르는지 다룹니다. 지금까지 공개된 카드를 적어 두는 장부, 이번 턴에 할 수 있는 모든 행동 순서를 끝까지 그려 보는 계획, 남은 손패를 재는 추 일곱 개짜리 저울, 그리고 저울보다 위에 있는 규칙까지 카드 게임 용어로 설명합니다.

훌라 easy 봇의 한계를 여덟 자리로 정리합니다. 한 수 greedy 가 손패 전체를 깨뜨리는 실례, 7 을 전략적으로 쥘 줄 모르는 문제, 공개 카드를 기억하지 않는 문제까지 짚고, 이 여덟 개를 다 메우면 정말 강한 봇이 되는지를 앞선 두 시리즈의 실패 기록과 함께 따져 봅니다.

훌라 easy 봇을 규칙 다섯 줄로 구현합니다. 뽑고, 가장 많이 터는 조합을 등록하고, 가장 많이 붙이고, 가장 비싼 카드를 버립니다. 짧은 코드지만 결정론과 fallback 이라는 두 가지 운영 요건을 만족해야 하고, 이 봇이 우연히 잘하는 것과 원리적으로 못 하는 것이 무엇인지 정리합니다.

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

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

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

압축·생성·전복이라는 세 가지 돌파구가 40년 뒤에 어떻게 됐는지 정리합니다. 엘리트의 씨앗이 노 맨즈 스카이의 64비트로 이어진 계보, 제약이 사라지자 드러난 역설, 제약을 일부러 되살리는 데모신, 그리고 오늘의 개발에 그대로 쓸 수 있는 여섯 가지 원칙을 다룹니다.

1987년 MSX2 메탈기어가 하드웨어의 거부를 게임 문법으로 바꾼 과정을 주석 disassembly 로 확인합니다. SCREEN 5 비트맵과 가로 스크롤 부재, 48바이트짜리 방 165개, 스프라이트를 짝지어 색을 늘리고 순서를 섞어 깜빡이는 기법, 원뿔이 아닌 복도형 시야 판정, 그리고 방에 붙어 있는 경보 상태 머신을 다룹니다.

1984년 엘리트가 21,952바이트에 항성계 2,048개를 담은 방법을 주석 disassembly 를 근거로 확인합니다. 트리보나치 씨앗 트위스팅, 두 글자 토큰 이름 생성, 곱셈 명령 없이 도는 3D 회전(민스키 알고리듬), 그리고 타이머 인터럽트로 만든 화면 분할을 Go 재현 코드와 함께 다룹니다.

슈퍼 마리오브라더스의 disassembly 를 직접 읽고 40KB 안에 32개 스테이지가 들어간 방법을 확인합니다. 레벨 오브젝트 2바이트 인코딩, 월드 1-1 의 실제 바이트 해독, 구름과 수풀이 같은 타일이라는 사실의 바이트 단위 증명, 8프레임 컬럼 파이프라인, 그리고 4.4 및 8.8 고정소수점 물리를 다룹니다.

1980년대 8비트 게임기가 실제로 무엇을 못 했는지 데이터시트 수준에서 확인합니다. 곱셈 명령이 없는 CPU, 16x16 픽셀 단위로만 색을 고를 수 있는 화면, 한 프레임의 7.6%뿐인 VRAM 접근 시간을 숫자로 재고, 그래서 개발자에게 남은 선택지가 압축·생성·전복 셋뿐이었음을 보입니다.

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

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