leigest519/OpenGame — 프롬프트 한 줄로 웹 게임 통째로 빌드하는 오픈 에이전트

한 줄 프롬프트로 웹 게임 한 편을 끝까지

"여우가 버섯을 모으는 2D 사이드 스크롤러"라고 한 줄 던지면, 끝나고 보면 진짜 플레이 가능한 HTML5 게임이 떨어져 나오는 OSS 에이전트가 leigest519/OpenGame이야. 프로토타이핑 데모 같은 게 아니라 빌드 헬스, 시각 사용성, 의도 정합 3축으로 직접 채점한 SOTA를 동봉해서 풀었다는 게 진짜 차별점이지.

PR #1은 4월 21일에 들어갔고, 지난주 Trending Python 코호트에 오르면서 약 1주일 만에 1,900스타 추가, 일간 280 스타 페이스로 4,200스타를 넘었어 (캐시 기준 추정 — github 직접 카운트는 환경에 따라 다름). 같은 팀이 동시에 arXiv 2604.18394 논문을 같이 풀어서 "코드만 풀고 끝"이 아니라 "벤치 + 모델 + 데이터 + 코드 = 풀스택 오픈"이라는 메시지가 명확해.

프로젝트 배경 — 누가, 왜 만들었나

OpenGame은 홍콩중문대학(CUHK) MMLab의 leigest519이 메인 커밋하는 프로젝트야. 같은 랩이 이전에도 멀티모달 비주얼 모델 쪽에서 굵직한 논문(Visual ChatGPT 계열)을 내왔는데, 이번엔 "에이전트 코딩"이라는 실용 영역으로 옮겨 온 거야. 게임 도메인을 고른 이유가 흥미로워. 일반 코딩 에이전트(SWE-Bench 류)는 정답이 있는 함수 단위 패치 위주라 평가가 깔끔한데, "재미있는 게임"은 채점이 까다로워. OpenGame은 그 채점 자체를 자동화하면서 풀었어.

배경을 한 단계 더 올려 보면, 이 프로젝트는 두 가지 큰 흐름이 만나는 자리에 있어. 첫째는 코딩 에이전트 시장 전체가 "함수 패치"에서 "프로젝트 통째 빌드"로 옮겨가고 있다는 점. Cursor 3, Claude Code, Codex가 모두 이쪽을 노려. 둘째는 LLM 평가 방법론이 정답 매칭에서 "사용 가능성" 위주의 LLM/VLM judge로 옮겨가고 있다는 점. OpenGame은 두 흐름을 한 프로젝트에 묶어서 보여 줘.

저자 노트(README + 논문)를 보면, 이 프레임워크의 진짜 자랑은 "Game Skill"이라는 메모리 구조야. 한 번 만들어 본 게임의 스켈레톤은 Template Skill에 저장되고, 디버깅 중 검증된 픽스는 Debug Skill에 적립돼. 다음 프롬프트가 들어오면 비슷한 패턴을 그대로 재사용해서 시간을 줄이는 식이야. 일반 코딩 에이전트가 매번 0부터 시작하는 것과 정반대.

핵심 기능 — Game Skill + GameCoder-27B + OpenGame-Bench

OpenGame의 코어 컴포넌트는 세 개야. 멀티 페이즈 워크플로(plan → scaffold → implement → debug → polish), 도메인 특화 GameCoder-27B 모델, 그리고 이미 풀린 OpenGame-Bench 평가 파이프라인. 워크플로는 Anthropic의 SWE-Bench 지향 에이전트와 비슷한 트리 구조지만, "polish" 단계에서 폰트·스프라이트·BGM 같은 게임 특유의 손질을 따로 떼어 둔 게 특징이야.

GameCoder-27B는 일반 코딩 모델이 아니라 게임 코드(Phaser, Pygame, Godot 스크립팅) 위주 코퍼스로 파인튜닝된 도메인 특화 베이스야. 27B 사이즈는 "단일 GPU에서 추론 가능"한 상한선으로, A100 1장에서 돌아가도록 양자화 가이드까지 동봉됐어. 도메인 특화 베이스가 어떻게 차이를 만드는지가 OpenGame-Bench에서 드러나는데, 같은 워크플로 위에서 Llama 3.1 70B 베이스보다 빌드 헬스 점수가 의미 있게 높아.

OpenGame-Bench는 150개 다양한 게임 프롬프트에 대해 (1) 빌드 헬스 — 빌드/실행 가능 여부와 콘솔 에러 (2) 시각 사용성 — 헤드리스 브라우저 캡처를 VLM이 채점 (3) 의도 정합 — 프롬프트와 결과물의 시맨틱 매칭을 평가해. 이 3축은 Game-Bench류 기존 벤치(예: ICML 2024 GameBench)가 정답 매칭 위주였던 한계를 넘어서.

# 시작 — 4단계
git clone https://github.com/leigest519/OpenGame.git
cd OpenGame && make install
make run PROMPT='a 2D side-scroller where a fox collects mushrooms'
# 결과: ./out/ 디렉토리에 HTML/JS/asset 한 세트

기술 스택 + 아키텍처

언어는 파이썬 메인이고, 게임 런타임은 Phaser 3 (HTML5)로 통일. Phaser를 고른 이유가 합리적인데, 브라우저에서 그냥 돌아가니 채점 단계에서 별도 빌드/배포 없이 헤드리스 Chrome으로 바로 실행할 수 있어. Docker 이미지로 환경 잠금이 돼 있어서 "내 PC에선 됐는데" 문제가 거의 없어.

VLM judge는 GPT-4V 또는 Qwen-VL을 갈아 끼울 수 있게 추상화돼 있어. 즉 OpenAI API 키 없어도 OSS 경로로 평가 파이프라인을 돌릴 수 있다는 거. 비용 측면에서 중요한 디테일이야.

경쟁 레포 비교

프로젝트	역할	모델	평가 자체 동봉	라이선스
leigest519/OpenGame	게임 통째 빌드 에이전트	GameCoder-27B 도메인 특화	OpenGame-Bench 150 프롬프트	Apache-2.0
microsoft/autogen	일반 멀티 에이전트 프레임워크	BYO LLM	없음	CC-BY-4.0
phaserjs/phaser-ai-templates	Phaser 템플릿 모음	외부 LLM 호출	없음	MIT
cline/cline (직전 자사 영역 비교)	VS Code IDE 에이전트	BYO	없음	Apache-2.0

OpenGame은 "도메인 특화 모델 + 평가 셋 동봉"이 차별점이고, autogen은 일반 프레임워크라 게임을 만들려면 추가 배선이 많이 필요해. Phaser 공식 템플릿은 LLM-friendly한 코드 스니펫이지 에이전트는 아니야.

왜 지금 뜨는가 — 생태계 맥락

게임 코딩이 갑자기 뜨는 데에는 세 가지 흐름이 겹쳐. 첫째, 같은 주에 Cursor가 500억 달러 평가에 시리즈 D로 협상 중이라는 보도가 나오면서 "에이전틱 코딩이 단순 자동완성을 넘어 산업 카테고리가 됐다"는 시그널이 뚜렷해졌어. 둘째, 4월에 발표된 GPT-5.5 (SWE-Bench 75% 돌파)가 "함수 단위 정확도"는 해결됐다고 보여 주면서, 다음 프런티어인 "프로젝트 통째" 영역으로 관심이 옮겨 가고 있어. OpenGame은 그 프런티어의 첫 번째 도메인 특화 OSS 사례야.

셋째, 평가 자동화가 ML 트렌드의 가장 뜨거운 코너야. 2026년 들어 LLM-as-a-judge 논문이 폭발적으로 늘었고, OpenGame은 거기에 VLM-as-a-judge라는 한 단계 더 어려운 채점을 직접 깔아 보여 줬어. 같은 주에 풀린 HuggingFace의 LightEval VLM extension PR도 같은 방향이야 — 평가 인프라가 코어 OSS로 자리 잡고 있다는 뜻.

Hacker News 토론에서 가장 많이 인용되는 코멘트는 "이 정도면 인디 게임 메이커 한 명이 한 달에 게임 30개 시제품을 만들 수 있다"는 평가야. 실제로 itch.io 같은 인디 플랫폼에서 OpenGame으로 만든 시제품이 4월 마지막 주에 12개 등록됐어. 게임 도메인 자체가 '플레이 가능' 임계만 넘으면 시장에 나갈 수 있는 영역이라 임팩트가 빠르게 가시화되는 중이야.

시작하기 + 함정

설치는 간단하지만 첫 실행 시 두 가지 함정이 있어. 첫째, GameCoder-27B 가중치 다운로드가 약 54GB로 무거워. 양자화 4-bit 버전은 14GB 정도라 Mac M2 Pro 32GB에서 돌아간다는 보고가 GitHub Issues에 올라와 있어. 둘째, OpenGame-Bench 평가는 헤드리스 Chrome + VLM 호출이 동시에 일어나서 첫 실행 5분 정도는 컨테이너 빌드에 쓰여. 이 두 가지만 알고 시작하면 막히는 곳은 거의 없어.

# 4-bit 양자화 가중치
make install QUANT=4bit
# 평가 파이프라인 단독 실행
make bench PROMPT_SET=opengame_bench_v1

한계와 전망

지금 한계는 두 가지 — 게임 장르 커버리지가 2D 위주(사이드 스크롤러, 퍼즐, 슈터)로 제한적이고, 멀티플레이어/네트워킹 코드는 거의 못 만들어. 로드맵에는 2026 H2 안에 3D(Three.js 백엔드)와 멀티 에이전트(2-agent 협업) 추가가 잡혀 있어. Pull Requests를 보면 4월 30일에 Three.js 백엔드 PR이 RFC로 올라와 있어서 H2에 도달은 가능해 보여.

장기 전망은 "도메인 특화 코딩 에이전트"의 기준이 된다는 거야. 게임 다음은 데이터 분석 노트북, 의료 영상 워크플로, 산업 설비 대시보드 같은 도메인이 같은 패턴(특화 모델 + 도메인 평가 셋 + 다단계 워크플로)으로 갈 가능성이 높아. OpenGame은 그 패턴을 처음으로 깔끔하게 보여 준 OSS 사례라서 후속 프로젝트들이 그대로 베껴 쓸 가능성이 커.

내일 아침에 할 것

개발자: git clone 후 make run PROMPT='your prompt'로 5분 안에 첫 게임을 뽑아 봐. 뽑힌 결과물을 itch.io에 올려 보면 "에이전트가 실제로 만든 게임"의 임계가 어디쯤인지 감이 와. 게임 디자이너: OpenGame-Bench 150 프롬프트를 다 읽고, 본인 회사 도메인의 50 프롬프트 짜리 vertical bench를 모방해서 만들어 봐. 이게 다음 12개월 동안 가장 가치 있는 OSS 기여 카테고리야. 투자자/창업자: 5월 말 발표 예상되는 GameCoder-70B (논문 부록에 언급)와 H2의 Three.js 확장 시점이 OpenGame 진영의 두 번째 변곡점이야. 그 시점까지 leigest519 깃허브 활동·이슈 코호트·릴리스 노트를 모니터링하면 도메인 특화 에이전트의 다음 라운드 흐름이 보여.

참고 자료

• 리포: https://github.com/leigest519/OpenGame
• 논문: https://arxiv.org/abs/2604.18394
• Phaser HTML5 엔진: https://phaser.io/
• GitHub Trending Python (주간): https://github.com/trending/python?since=weekly
• HuggingFace LightEval (관련 평가 인프라): https://github.com/huggingface/lighteval