한 프롬프트가 한 게임 — OpenGame 논문이 도메인 특화 코딩 에이전트 SOTA

SOTA on 150 prompts

CUHK MMLab이 4월 21일 arXiv에 푼 OpenGame 논문이 보여 주는 핵심 결과는 "도메인 특화 베이스 + 다단계 워크플로 + 자동 평가 = 150 게임 프롬프트 SOTA". 흥미로운 점은 코드(leigest519/OpenGame)·모델(GameCoder-27B)·벤치(OpenGame-Bench) 세 가지를 같은 시점에 같이 풀었다는 거야. 도메인 특화 코딩 에이전트의 풀스택 오픈 reference가 처음 등장한 거지.

쉽게 말하면

"여우가 버섯을 모으는 2D 사이드 스크롤러"라고 한 줄 던지면, 끝나고 보면 진짜 플레이 가능한 HTML5 게임이 떨어져 나오는 시스템이야. 단순 코드 생성이 아니라 (1) 기획 (2) 스캐폴딩 (3) 구현 (4) 디버깅 (5) 폴리싱 5단계를 에이전트가 알아서 돌고, 각 단계마다 학습된 Skill 라이브러리를 재사용해서 시간을 줄여. 같은 프롬프트라도 100번째 실행이 첫 실행보다 빠르고 안정적이야.

연구진과 출처

CUHK MMLab 팀 (leigest519이 1저자). MMLab은 Visual ChatGPT, Vid2Seq 등으로 알려진 멀티모달 비전-언어 그룹이야. arXiv 2604.18394, CC-BY 라이선스, 2026-04-21 공개. 학회 발표는 명시되지 않았지만 ICML 2026 / NeurIPS 2026 발표가 예상됨.

기존 한계 — 게임은 SWE-Bench로 못 잰다

일반 코딩 에이전트 벤치는 SWE-Bench류처럼 함수 단위 패치 + 정답 매칭이야. 그런데 게임은 정답이 없어 — "재미있는 사이드 스크롤러"의 정답이 단일하지 않거든. 기존에는 (1) 사람 평가 (느리고 비싸다) (2) 정답 패턴 매칭 (게임에서 부정확) 둘 다 한계. OpenGame은 이 평가 자체를 자동화하면서 동시에 더 정확한 채점을 도입했어.

또 다른 한계는 도메인 코퍼스 부재였어. Llama 3.1 70B 같은 일반 코딩 모델이 Phaser/Pygame/Godot 스크립팅을 정확히 알지는 못해. 도메인 특화 베이스가 필요한 이유야.

방법 — Game Skill + GameCoder-27B + OpenGame-Bench

핵심 컴포넌트 셋. Game Skill 메모리: Template Skill(프로젝트 스켈레톤 라이브러리)이 경험 기반으로 자라고, Debug Skill(검증된 픽스 프로토콜)이 반복되는 버그를 빨리 해결. 다음 프롬프트가 들어오면 비슷한 패턴을 재사용. GameCoder-27B: 게임 코드(Phaser, Pygame, Godot 스크립팅) 코퍼스로 fine-tune된 27B 모델. 27B 사이즈는 단일 A100에 fit. OpenGame-Bench: 150개 다양한 게임 프롬프트를 (1) Build Health (빌드/실행, 콘솔 에러) (2) Visual Usability (헤드리스 브라우저 캡처를 VLM이 채점) (3) Intent Alignment (프롬프트와 결과의 시맨틱 매칭) 3축으로 평가.

결과 표

모델	Build Health	Visual Usability	Intent Alignment	평균
GPT-5.5 (general)	0.74	0.62	0.71	0.69
Claude Opus 4.7 (general)	0.72	0.65	0.69	0.69
Llama 3.1 70B + 워크플로	0.61	0.54	0.62	0.59
GameCoder-27B + Game Skill	0.83	0.78	0.81	0.81

도메인 특화 27B가 일반 70B보다 의미 있게 높고, GPT-5.5/Opus 4.7 같은 frontier 모델도 워크플로 결합 없이는 따라잡기 어려워. 흥미로운 점: GameCoder-27B 단독(워크플로 없이) 점수는 0.62 정도로, 27B와 Game Skill 워크플로의 결합이 결과의 핵심임을 보여 줌.

왜 흥미로운지

세 가지 의미가 있어. 첫째, "도메인 특화 코딩 에이전트"가 풀스택 OSS로 처음 풀렸어. 게임 다음은 데이터 분석 노트북, 의료 영상 워크플로, 산업 설비 대시보드 같은 도메인이 같은 패턴으로 갈 가능성. 둘째, VLM-as-judge 평가가 production-ready 수준으로 자리잡는 사례. 셋째, 도메인 특화 27B가 frontier 70B+를 일반 워크플로에서 이긴 게 의미 — 도메인 데이터가 모델 사이즈를 이긴다는 시그널.

반론 / 한계점

세 가지 한계 — 게임 장르가 2D 위주라 3D는 미지원, 멀티플레이어/네트워킹 코드는 거의 못 만들고, GameCoder-27B 학습 코퍼스가 비공개라 reproducibility가 일부 제한. VLM judge가 GPT-4V/Qwen-VL이라 judge 모델의 편향이 평가 결과에 누설될 가능성도 명시돼 있어.

회의적 시각으로는 일반 frontier 모델(GPT-5.5)이 SWE-Bench 75% 도달한 시점에서 "도메인 특화"의 ROI가 길게 갈지 의문이라는 의견도 나와. 즉 frontier 모델이 게임 코딩까지 자연스럽게 흡수해 버리면 GameCoder-27B의 차별이 약해질 수 있음.

한 줄 정리

도메인 특화 모델 + 다단계 워크플로 + 자동 평가의 풀스택 오픈 사례. 코딩 에이전트 산업이 "함수 패치"에서 "프로젝트 통째 빌드"로 옮겨가는 변곡점의 reference design.

참고 자료

• 논문: https://arxiv.org/abs/2604.18394
• 코드: https://github.com/leigest519/OpenGame
• Phaser: https://phaser.io/
• CUHK MMLab: https://mmlab.ie.cuhk.edu.hk/
• SWE-Bench (비교 카테고리): https://www.swebench.com/