Wintersalmon | Blog

더 세게가 아니라 더 똑똑하게 — 창의성을 잃지 않는 더 빠른 self-play 루프

10 min read

AI의 연습이 느린 부분이고, 지금은 무차별 방식으로 하고 있습니다

제가 학습시키는 보드게임 AI들은 자기 자신과 수백만 판을 두며 배웁니다. 저는 그 루프를 — 실력을 떨어뜨리지 않으면서 — 더 빠르게 만드는 작업을 계속 해 왔습니다. 앞선 두 번의 개선은 “더 큰 두뇌”와 “더 세게 생각하기”(더 깊은 search)였습니다. 이번 글은 그 다음 개선, 더 세게가 아니라 더 똑똑하게 생각하기에 관한 것입니다. 여기에 두 가지 보조 변경, 그리고 이 셋 모두를 지배하는 단 하나의 규칙이 더해집니다 — AI는 더 빨라져도 되지만 덜 창의적이어서는 안 됩니다. 이 변경들은 아직 구현 전이며, 이 글은 그 설계와 근거를, AI 학습 파이프라인을 한 번도 만져본 적 없는 엔지니어를 위해 풀어 쓴 것입니다.

TL;DR

  • “연습” 단계(AI가 자기 자신과 두며 스스로 lesson을 만드는 과정)가 **매 학습 라운드의 약 65%**를 차지하는 병목입니다 — 약 120분 라운드 중 약 78분으로 측정되었습니다.
  • 변경 1 — 먼저 전부 측정한다: 현재 루프는 단계별 정보를 거의 기록하지 않고, 창의성에 대해서는 아무것도 기록하지 않습니다. 단계별 시간과 “창의성 계기판”을 추가해 다른 변경들의 효과를 증명하고 문제를 조기에 잡습니다.
  • 변경 2 — referee를 임계 경로 밖으로 옮긴다: 승급을 결정하는 gate가 GPU 머신에서 수백 판을 두는 동안 다른 모든 것이 대기합니다. 대신 유휴 상태인 16코어 PC에서 돌려 GPU가 즉시 다음 배치를 시작하게 합니다.
  • 변경 3 — 더 세게가 아니라 더 똑똑하게: 수당 약 800번의 무차별 look-ahead를, 동등하거나 더 나은 lesson을 약 50번으로 얻는 기법(Gumbel search)으로 교체합니다 — 느린 단계에서 약 16배 적은 GPU 연산입니다.
  • 규칙: 모든 변경은 손대지 않은 실력 referee 그리고 새 창의성 계기판으로 심사합니다. 더 빠른 것은 창의성이 유지되거나 올라갈 때만 가치가 있습니다.

지금 루프가 어떻게 도는지, 그리고 왜 연습이 병목인지

한 “generation”의 학습은 세 단계가 일렬로 이어집니다: AI가 자기 자신과 게임을 둡니다(연습), 새 network가 그 게임들의 최선 수를 copy하도록 학습되고(train), 엄격한 통계 referee가 새 network가 진짜로 더 강한지 판정합니다. 연습의 결과물만이 lesson이 되므로, 연습의 품질이 나머지 전부의 천장을 정합니다.

핵심은 AI가 연습 수를 어떻게 고르느냐입니다. AI는 직감을 믿지 않습니다. 매 수 전에 search를 돌립니다 — 여러 진행을 상상하고, 앞을 내다보고, 가장 잘 버티는 수를 둡니다. 지금은 이것이 수당 약 800번의 look-ahead입니다. 각 look-ahead는 GPU(수학을 담당하는 칩) 위의 연산 하나이므로, 수백 판에서 800 깊이로 search하는 것은 작은 GPU 작업의 소방호스입니다. 이것이 연습이 약 78분 걸리고 GPU가 한계 자원인 이유 전부입니다. 학습(train) 자체는 이에 비하면 사소합니다 — 약 15분. 그러니 목표는 분명합니다: lesson을 나쁘게 만들지 않으면서 연습을 더 싸게 만드는 것.

변경 1 — 볼 수 없는 것은 개선할 수 없습니다

지금 루프는 라운드당 두 숫자를 기록합니다: 총 시간과 연습 시간. AI의 플레이가 얼마나 다양한지아무것도 기록하지 않습니다. 이는 위험합니다. self-play의 고전적 실패는 조용히 하나의 반복적 스타일로 붕괴하는 것인데, 지금이라면 그 붕괴가 보이지 않을 것이기 때문입니다.

그래서 첫 변경은 순수한 계측입니다: 각 단계의 시간을 따로 기록하고, 매 라운드 창의성 계기판을 계산합니다. 미묘한 부분은 — 초기 리뷰가 잡아낸 것인데 — 무엇을 측정하느냐입니다: 오프닝이 얼마나 다양해 보이는지만이 아니라, AI가 실제로 얼마나 다른 게임과 전략 라인을 만들어내는지입니다. 순진한 “퍼짐” 숫자는 높게 유지되면서도 모든 게임이 조용히 같은 세 개의 중반 플랜으로 수렴할 수 있으므로, 계기판은 퍼짐만이 아니라 서로 다른 국면과 라인의 개수를 셉니다. 이는 서비스를 최적화하기 전에 tracing을 먼저 붙이는 소프트웨어 엔지니어링의 반사신경과 같습니다: 저렴하고, 이후의 모든 주장(“더 빨라졌다”, “창의성은 유지됐다”)을 희망이 아니라 숫자로 바꿉니다.

지금 계획
시간 총합 + 연습만 모든 단계(연습 / train / referee)
창의성 측정 안 함 서로-다른-게임과-라인 계기판, 매 라운드 기록

변경 2 — referee를 유휴 머신으로 옮깁니다

train 후, referee — “gate” — 는 도전자와 현 챔피언 사이에서 수백 판을 두어 승급을 결정합니다. 이것이 GPU 머신에서 돌고, 그동안 다른 모든 것이 대기합니다. 그런데 그 게임들은 GPU를 거의 쓰지 않습니다. 다음 라운드를 막는 바로 그 단계에서 머신은 대부분 놀고 있습니다.

한편 별도의 16코어 PC(클러스터를 돌리는 상시 서버)는 놀고 있습니다. gate의 두 선수는 고정되어 있습니다 — 대국 중 network가 바뀌지 않습니다 — 그래서 gate는 옮기기 깔끔한 자기완결적 작업입니다. 그러니 계획은 gate의 대국을 그 유휴 PC에서 돌려, GPU 머신이 즉시 다음 연습 배치를 시작하게 하는 것입니다. 이는 테스트 스위트를 개발 노트북에서 막지 않고 별도 CI runner로 옮기는 것과 같은 직감입니다: 서로 의존하지 않는 두 작업은 동시에 돌아야 합니다.

변경 3 — 무차별 800번 look-ahead냐, 영리한 50번이냐

여기가 가장 큰 부분입니다. 왜 AI는 좋은 lesson 하나를 만드는 데 약 800번의 look-ahead가 필요할까요? 표준 방식이 각 수를 lesson으로 바꿀 때 search가 각 후보를 몇 번 방문했는지를 세는데, 그 횟수는 많이 방문한 뒤에야 믿을 만하기 때문입니다. look-ahead가 적으면 대부분의 후보 수는 한 번 방문되거나 아예 방문되지 않고, “lesson”은 대부분 noise가 됩니다. 무차별로 품질을 사는 셈입니다.

Gumbel search(2022년 DeepMind 논문)는 look-ahead를 영리하게 쓰고 lesson을 다르게 만들어, 훨씬 적은 look-ahead로 같은 품질을 얻습니다. 두 아이디어가 일합니다. 첫째, 주의를 얇게 펼치는 대신, 유망한 후보 수 몇 개를 골라 그들 사이에서 미니 토너먼트를 돌립니다 — 각자에게 몇 번의 look-ahead를 주고, 하위 절반을 떨어뜨리고, 하나가 남을 때까지 반복합니다(이 기법을 sequential halving이라 합니다). 둘째, 더 중요하게는, lesson을 방문 횟수가 아니라 수에 대한 AI의 value 추정으로 만들며, 그 결과 lesson이 아주 적은 look-ahead에서도 AI의 직감보다 진짜로 개선임을 보장하는 수학적 근거를 갖습니다. 그 보장이 바로 표준 search에 없는 것이고, 약 800에서 약 50으로 낮출 수 있게 하는 것입니다.

지금 (표준 search) 계획 (Gumbel search)
수당 look-ahead 약 800 약 50
lesson의 근거 각 수의 방문 횟수 value 추정 + 미니 토너먼트
적은 횟수에서의 품질 불안정(noise) 개선 보장
수당 GPU 작업 약 800 약 50 (약 16배 적음)

예를 들어 봅시다. 약 60수 오프닝에서 표준 search는 800번의 look-ahead를 60수 전체에 펼칩니다. Gumbel은 가장 유망한 16수를 골라 약 50번으로 16 → 8 → 4 → 2 → 1을 돌리고, 승자를 두고, AI의 순간 판단을 확실히 능가하는 lesson을 기록합니다. 같은 수 품질에 GPU 작업은 일부분. 이는 연습만 건드립니다. referee는 엄밀한 완전 search를 유지하므로 잣대는 절대 움직이지 않습니다.

단 하나의 규칙: 덜 창의적이어서는 안 됩니다

Gumbel은 AI가 어떻게 탐험하는지를 바꿉니다 — 기존의 무작위성을 토너먼트에 내장된 다양성으로 교체합니다 — 그래서 정직한 위험은 AI의 스타일이 좁아지는 것입니다. 그것이 변경 1이 먼저인 이유입니다. 무엇이든 배포하는 기준은 명시적입니다: 손대지 않은 실력 referee로 재면 새 챔피언은 더 약하지 않아야 하고, 창의성 계기판으로 재면 다양성은 유지되거나 더 높아야 하며 — 한 라운드가 아니라 여러 generation에 걸쳐 추적합니다. 마지막 부분이 중요한 이유는, 이런 시스템이 진부해지는 고전적 방식이 어느 한 라운드에서는 보이지 않지만 스무 라운드에 걸쳐서는 뚜렷한 느린 표류이기 때문입니다. 더 빠르지만 더 반복적인 것은 거절이지, 제가 받아들일 트레이드오프가 아닙니다. 유지-또는-향상된 창의성이 측정하는 이유 전부입니다.

이것이 바꾸는 것

세 번의 정체, 세 개의 교훈: 처음엔 더 큰 network, 다음엔 더 깊은 search, 이제는 더 싼 search. 이것이 안착하면, 학습 라운드가 AI가 한 걸음도 잃지 않으면서 의미 있게 짧아집니다. 그리고 마찬가지로 중요하게는, 창의성을 잃지 않았음을 제가 증명할 수 있게 됩니다 — 처음으로 루프가 바로 그것을 지켜보게 될 것이기 때문입니다. 다음 글에는 숫자가 있을 것입니다.

핵심 용어

  • Self-play — AI가 자기 자신과 게임을 두어 사람 기보 없이 스스로 학습 예제를 만드는 것.
  • Search / look-ahead (MCTS) — 매 수 전에 AI가 여러 진행을 상상하고 가장 좋아 보이는 수를 두는 것; look-ahead가 많을수록 강하지만 느립니다.
  • GPU — 무거운 수학을 담당하는 칩; 바쁘게(또는 과부하 없이) 유지하는 것이 성능 싸움의 대부분입니다.
  • Gate (referee) — 도전자가 실제로 더 많이 이겨야만 챔피언으로 인정하는 엄격한 통계 검정.
  • Gumbel search — value 추정과 미니 토너먼트를 써서, 적은 횟수에서도 개선을 보장하며 아주 적은 look-ahead로 좋은 lesson을 얻는 방법.
  • Sequential halving — 미니 토너먼트 규칙: 후보에게 같은 기회를 주고, 하위 절반을 떨어뜨리고, 하나가 남을 때까지 반복합니다.
  • Entropy (창의성 계기판) — 선택들이 얼마나 다양한지에 대한 숫자; 높은 오프닝 entropy는 AI가 늘 같은 수순을 두지 않는다는 뜻입니다.
  • Pipeline overlap — 서로 독립인 단계들을 순차가 아니라 서로 다른 머신에서 동시에 돌리는 것.

참고 자료

  • docs/task-log/20260703-yinsh-ai-session-improve/01-improvement-plan.md — 이 세 변경이 나온 전체 계획, 코드 위치 포함.
  • docs/task-log/20260614-yinsh-ai-impl-plan/30-followup-designs.md — 측정된 단계별 분해(연습 약 78분 / train 약 15분 / referee 약 13–26분)와 미뤄둔 속도 백로그.
  • docs/task-log/20260630-yinsh-missed-mate-diagnosis/01-diagnosis.md — 왜 “더 많은 데이터”가 모든 약점을 고치지 못하는지; 실력과 다른 행동의 분리.
  • [[2026-06-29-thinking-harder-not-bigger]] — 이전 개선(더 깊은 search), 그리고 이 루프가 계속 마주치는 절반-유휴 GPU 함정.
  • Policy improvement by planning with Gumbel (Danihelka et al., 2022) — 변경 3의 바탕이 된 논문.
  • mctx (DeepMind) — 수학을 대조할 Gumbel search 참조 구현.
  • AlphaZero (DeepMind) — 이 파이프라인이 따라 하는 self-play + search + train 루프.

AI 작업 노트

이 글은 결과 글이 아니라 설계 글입니다 — 구현 전의 계획을 문서화하며, 이는 가이드의 “실제 데이터 인용” 기준에서 한 가지 벗어납니다: 세 변경은 제안이고, 제가 인용한 숫자들(단계 시간, sim 수, 현 챔피언)은 모두 측정된 값입니다. Claude Code 에이전트가 파이프라인 코드와 십수 개의 task-log 문서를 가로질러 조사한 뒤 계획과 이 해설을 초안했으며, 통한 패턴은 코드 이전에 “무엇이 후퇴해서는 안 되는가”(창의성) 기준을 명시적으로 못박은 것이었습니다 — 리뷰가 잣대를 갖도록. 다음 단계는 바로 그 기준으로 계획을 독립적으로 리뷰하는 것입니다.


Hungjoon

I'm Hungjoon, a software engineer based in South Korea. This is my long-form notebook — homelab, Kubernetes, AI infra, and whatever else keeps me up at night.