Shogi AI와의 상호작용을 통해 얻은 것: Floodgate에서 1위에 오르는 길과 Distilled Models에 대한 나의 접근법
Source: Dev.to
번역을 진행하려면 실제 텍스트(본문)를 제공해 주시겠어요? 본문을 알려주시면 요청하신 대로 한국어로 번역해 드리겠습니다.
Introduction
추론 최적화와 모델 핸들링을 검증하기 위한 실용적인 테스트 환경으로, 저는 2026년 1월에 처음으로 OSS 장기 소프트웨어를 접했습니다.
그 결과, 저는 Floodgate(컴퓨터 장기를 위한 온라인 장기 서버)에서 200판 이상을 플레이하고 레이팅이 4500점을 초과하여 1단에 올랐습니다. 제가 프로그래밍을 시작한 것이 2025년 12월이었기 때문에, OSS를 접한 후 약 두 달 만에 이룬 성과입니다.
이 글은 구현에 대한 단계별 가이드가 아니라, 장기 AI를 통해 배운 점과 이를 LLM 연구에 LLM/RAG 연구자의 관점에서 어떻게 적용할 수 있는지를 논의합니다.
왜 체스 AI?
- LLM 연구에서는 추론 최적화와 모델 선택과 같은 과제가 흔하지만, 평가가 모호할 수 있습니다—“답이 좋은가?”는 종종 주관성을 포함합니다.
- 쇼기 AI는 명확한 승패와 레이팅을 제공하여 전략 효율성을 즉시 수치적으로 검증할 수 있게 합니다.
- CUDA/TensorRT 빌드와 배치 처리 최적화와 같은 기술 세트는 LLM과 쇼기 AI 모두에서 공유되며, 이는 쇼기 AI를 엄격한 승패 피드백 루프를 갖춘 이상적인 실험 환경으로 만듭니다.
전체 아키텍처: 3‑계층 하이브리드
구축된 시스템은 3계층 아키텍처를 따릅니다:
Phase 1 – Book (Opening Database)
- Python 사전 조회를 통한 즉시 수 선택.
- C++ 엔진 시작 없이 GPU/CPU 부하 0.
Phase 2 – MCTS + DL Model
- TensorRT를 사용한 40‑블록 대형 ResNet 추론.
- RTX 5090의 32 GB VRAM에 맞게 양자화.
Phase 3 – α‑β + NNUE
- CPU 탐색을 통한 빠른 포지션 평가.
- 엔드게임에서 승리를 읽어냄.
Python 래퍼가 단계 전환과 프로토콜 통신을 관리하며, 포지션 특성에 따라 엔진을 선택합니다. 이 “단일 모델이 아닌 전체 아키텍처로 승리” 접근 방식은 RAG 시스템 구성(search → ranking → generation 다단계 파이프라인)을 반영합니다.
OSS Modification: The Value of Cutting
두 개의 OSS 엔진(DL 및 NNUE)을 포크하여 소스 레벨에서 불필요한 기능을 제거했습니다.
- DL 엔진 – RTX 5090 × TensorRT에 특화하기 위해 멀티‑GPU 지원, 다중 백엔드 분기, 다양한 매이트 서치 루틴을 제거했습니다. USI 옵션 수가 63개에서 43개로 감소했으며(‑32 %).
- NNUE 엔진 – 테스트 명령, 책 생성 명령, 학습 관련 코드를 제거하여 바이너리 크기를 916 KB에서 514 KB로 줄였습니다(44 % 감소).
이러한 “절삭” 작업은 LLM 운영에도 직접 적용됩니다. 증류 모델에 LoRA나 파인‑튜닝을 통해 기능을 추가하기보다, 불필요한 분기를 줄이고 프롬프트를 통해 동작을 제어하세요 — 이는 An Era Without LoRA or FT: How to Approach Distilled Models 기사와 정책이 일치합니다.
실시간 북 재작성: RAG 영감 접근법
- Python 측에서 약 7 백만 개의 북 포지션 데이터베이스를 관리했습니다.
- 북 로딩 속도를 가속화했습니다.
- 경기 중에 실시간으로 북을 재작성하도록 구현했습니다: 패배 후 초반 브랜칭 포인트를 식별하고, 다음 경기에서 다른 수를 선택하도록 북을 수정합니다. 경기가 누적될수록 북이 지속적으로 정제됩니다.
이 “경험으로 데이터베이스를 업데이트하고 이를 이후 추론에 반영하는” 사이클은 RAG의 피드백 루프와 유사하며, 대화 로그를 통해 검색 결과 품질을 향상시키는 것과 비슷합니다.
LLM 활용 및 제한
개발 과정에서 코딩 파트너로 Claude Opus를 사용했습니다. dlshogi와 YaneuraOu와 같은 틈새 전문 도구의 경우 LLM이 환각을 일으키는 경우가 자주 발생합니다. 자신 있게 생성된 코드를 맹목적으로 신뢰하면 잘못된 수정으로 이어져 실패할 뿐만 아니라 장기 실력도 떨어집니다.
핵심 교훈: LLM은 추론이 아니라 번역입니다. 계산에는 특화된 엔진(예: 장기 탐색 엔진, 도메인‑특화 로직)을 사용하고, 입력·출력의 자연어 변환에 LLM을 활용하십시오. 이는 “LLM에 지식을 제공하지 말고 외부 소스에서 얻은 사실을 기반으로 생성하라”는 RAG 설계 원칙과 일치합니다.
결론: 연구는 순환적이다
두 달간의 장기 AI 개발에서 얻은 통찰을 정리한 후:
- 증류된 모델에 추가 학습을 하면 비효율적이거나 과적합을 초래한다 → 프롬프트 제어가 올바른 접근법이다.
- 단일 모델이 아니라 전체 아키텍처로 승리한다 → RAG 파이프라인 설계 철학.
- 경험으로 데이터베이스를 업데이트하고 이를 이후 추론에 반영한다 → RAG 피드백 루프.
- LLM은 번역이며, 추론이 아니다 → 도메인 로직은 전문 엔진이 처리해야 한다.
이 장기 AI 경험은 LLM 연구에 피드백 되었고, LLM 연구 통찰은 장기 AI 아키텍처 설계에 적용되었다. 순환은 다양한 분야에 도전하는 가장 큰 가치이다. 현재 나는 로컬 LLM(엔비디아 Nemotron 모델을 활용한 시스템 구축) 연구로 돌아갔으며, GPU가 여유로워지면 다시 참여할 예정이다. 매우 즐거운 경험이었다.
사용된 하드웨어
- GPU: NVIDIA RTX 5090 (32 GB GDDR7)
- CPU: Intel Core Ultra 9 285K
- RAM: 64 GB
- OS: Linux (WSL2)