💬 NLP

GameCraft-Bench: Can Agents Build Playable Games End-to-End in a Real Game Engine?

이 논문은 코딩 에이전트가 완전하고 실행 가능한 게임을 엔드 투 엔드로 생성하는 능력을 평가하기 위해 설계된 140개의 Godot 기반 태스크로 구성된 벤치마크인 GameCraft-Bench를 소개하며, 현재의 프런티어 모델들이 인지 가능한 메카닉을 구현함에도 불구하고 결과물의 완성도와 상호작용적 일관성을 달성하는 데 있어 상당한 어려움을 겪고 있음을 밝히고 있습니다.

원저자: Tongxu Luo, Rongsheng Wang, Jiaxi Bi, Chenming Xu, Zhengyang Tang, Jianlong Chen, Juhao Liang, Ke Ji, Shuqi Guo, Yuhao Du, Fan Bu, Wenyu Du, Xiaotong Zhang, Kyle Li, Shaobo Wang, Linfeng Zhang, Yuxuan

게시일 2026-06-17

📖 4 분 읽기☕ 가벼운 읽기

CC BY 4.0

원저자: Tongxu Luo, Rongsheng Wang, Jiaxi Bi, Chenming Xu, Zhengyang Tang, Jianlong Chen, Juhao Liang, Ke Ji, Shuqi Guo, Yuhao Du, Fan Bu, Wenyu Du, Xiaotong Zhang, Kyle Li, Shaobo Wang, Linfeng Zhang, Yuxuan Liu, Xin Lai, Chenxin Li, Yiduo Guo, Zhexin Zhang, Xinyuan Wang, Tianyi Bai, Ziniu Li, Benyou Wang

원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. ✨ 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

당신이 로봇 셰프를 고용하여 복잡하고 다채로운 코스 요리 레시피를 주었다고 상상해 보십시오. 당신은 단순히 로봇이 종이 위에 레시피를 적는 것을 원하는 것이 아니라, 실제로 요리를 하고, 플레이팅을 하고, 서빙까지 해서 당신이 한 입 먹고 맛을 볼 수 있기를 원합니다.

이것이 본질적으로 이 논문, GameCraft-Bench가 다루고 있는 내용입니다. 이것은 AI 코딩 에이전트가 단순히 게임을 위한 코드를 작성하는 것을 넘어, 실제로 처음부터 플레이 가능한 비디오 게임을 "요리"할 수 있는지 확인하기 위한 테스트입니다.

다음은 이 논문의 주요 아이디어를 쉬운 비유를 사용하여 정리한 것입니다.

1. 문제점: "레시피 vs 실제 요리"

과거에 우리가 AI의 코딩 능력을 테스트할 때는 주로 코드가 서류상으로 올바르게 보이는지(마치 레시피의 재료 목록이 제대로 적혀 있는지 확인하는 것처럼)를 체크했습니다. 하지만 비디오 게임의 경우, 코드만 보는 것으로는 충분하지 않습니다. 게임은 실제로 실행되어야 하고, 그래픽이 나타나야 하며, 플레이어가 캐릭터를 움직여 어떤 일이 일어나는지 볼 수 있어야 합니다.

저자들은 AI가 게임을 만드는 능력을 진정으로 테스트하려면 세 가지가 필요하다고 주장합니다.

실제 주방 (엔진 그라운딩/Engine Grounding): AI는 가짜나 단순화된 버전이 아닌, 실제 게임 엔진(그들은 인기 있는 무료 도구인 Godot를 사용했습니다)에서 작업해야 합니다. 이는 셰프에게 장난감 가스레인지가 아닌 진짜 가스레인지를 사용하라고 요구하는 것과 같습니다.
완성된 요리 (아티팩트 완결성/Artifact Completeness): AI는 단 하나의 재료(예: 점프하는 캐릭터를 위한 스크립트 하나)만 던져주어서는 안 됩니다. AI는 실행 준비가 된 전체 패키지 형태의 완성된 게임을 전달해야 합니다. 누락된 부분이 없어야 합니다.
맛 테스트 (상호작용 검증/Interactive Verification): 완성된 음식을 그냥 바라보기만 하는 것이 아니라, 직접 먹어봐야 합니다. 게임은 반드시 실행되어야 합니다. AI의 성공 여부는 실제로 게임을 실행하고, 버튼을 누르고, 세상이 올바르게 반응하는지 확인하는 것에 의해 판단됩니다.

2. 테스트: GameCraft-Bench

연구진은 GameCraft-Bench라는 거대한 테스트 주방을 구축했습니다.

메뉴: 그들은 15가지 유형의 게임(플랫폼 게임, 레이싱 게임, 전략 게임, 공포 게임 등)에 걸쳐 140개의 서로 다른 챌린지를 만들었습니다.
과정:
1. AI에게 자연어 설명(예: "코인을 모으고 적을 피하는 2D 플랫폼 게임을 만들어줘")을 제공합니다.
2. AI는 Godot 엔진에서 게임을 구축합니다.
3. AI는 또한 게임을 플레이하는 방법을 정확히 보여주는 "데모 트레이스(demo trace)"—즉, 영상 스크립트—를 기록해야 합니다.
4. 컴퓨터 시스템이 그 스크립트를 사용하여 게임을 "플레이"하고, 영상을 녹화한 뒤, 스마트한 AI 심판이 영상을 보고 점수를 매깁니다.

3. 결과: "글쓰기는 잘하지만, 요리는 못한다"

결과는 놀라웠고 AI 커뮤니티에 다소 겸허함을 안겨주었습니다. 가장 똑똑하고 발전된 AI 모델들(Opus-4.7 및 GPT-5.5 등)조차 고전했습니다.

점수: 가장 뛰어난 AI도 이 테스트에서 약 **41%**를 득점했습니다. 대부분은 40% 미만의 점수를 받았습니다.
잘한 점: AI들은 "핵적인 루프(core loop)"를 구축하는 데는 준수한 모습을 보였습니다. 만약 캐릭터가 점프하는 게임을 요청했다면, 캐릭터는 보통 점프할 수 있었습니다. 그들은 엔진의 부품들을 만들 수 있었습니다.
실패한 점: 그들은 이 모든 것을 하나의 완전한 경험으로 결합하는 데 어려움을 겪었습니다.
- 콘텐츠 누락: 그들은 종종 너무 짧거나 진행을 위한 레벨이 없는 게임을 만들었습니다.
- 깨진 비주얼: 그래픽은 존재할 수 있지만, 그것이 논리적으로 맞지 않았습니다(예: 플레이어가 적을 볼 수 없거나, UI가 깨져 있는 경우).
- "데모"의 간극: 많은 AI가 게임을 구축했지만, 작동함을 증명하기 위해 필요한 "데모 트레이스"를 기록하는 것을 잊었습니다. 이는 마치 셰프가 요리는 다 해놓고 정작 심판에게 내놓을 플레이팅을 잊어버린 것과 같습니다.

4. 핵심 발견 (이유)

논문은 AI가 왜 실패했는지 그 이유를 파헤쳤습니다.

보는 것이 믿는 것이다: 가장 성적이 좋았던 AI는 게임을 구축하는 동안 게임 화면을 직접 관찰한 모델들이었습니다. 그들은 시각적 출력을 디버깅 도구로 활용했습니다. 캐릭터가 이상해 보이면 코드를 수정했습니다. 화면을 보지 않고 코드만 작성한 AI들은 더 많은 실수를 저질렀습니다.
바쁜 것이 더 나은 것은 아니다: 한 AI 모델(MiMo)은 엄청나게 많은 코드를 작성하고 많은 명령을 실행했지만, 더 높은 점수를 받지는 못했습니다. 이는 마치 셰프가 채소를 미친 듯이 다지기만 할 뿐, 정작 요리는 완성하지 못하는 것과 같았습니다. 최종 단계가 빠진다면 더 많은 일을 하는 것이 반드시 더 나은 결과를 보장하지는 않습니다.
서로 다른 기술: "점프" 메커니즘을 작동시키는 것(메카닉스)은 게임을 예쁘게 만드는 것(아트)이나 충분한 레벨을 만드는 것(콘텐츠)과는 다릅니다. AI는 하나는 잘할 수 있지만 다른 것에는 서툴 수 있습니다. 이 기능들은 모두 연결되어 있지 않습니다.

5. 결론

이 논문은 AI가 코드를 작성하는 데는 매우 능숙해지고 있지만, 엔드 투 엔드(end-to-end) 게임 제작은 여전히 거대한 도전 과제라고 결론짓습니다.

현재의 AI는 게임의 "파편"이나 간단한 프로토타입은 만들 수 있지만, 인간의 창의적인 아이디어를 받아들여 스스로 세련되고 플레이 가능하며 완전한 게임 패키지로 변환하는 일은 아직 신뢰할 만한 수준에 도달하지 못했습니다. "올바르게 보이는 코드를 쓰는 것"과 "작동하는 시스템을 전달하는 것" 사이의 간극은 여전히 매우 넓습니다.

요약하자면: AI는 레시피를 쓸 수는 있지만, 아직 온전한 식사를 요리하고 고객에게 서빙하는 법을 배우는 중입니다.

기술 요약: GameCraft-Bench

문제 정의

본 논문은 자율 에이전트가 자연어 게임 명세( $s$ )를 특정 개발 및 실행 환경( $E$ ) 내에서 플레이 가능한 인터랙티브 시스템( $G$ )으로 변환하는 과정인 엔드 투 엔드(end-to-end) 게임 생성의 과제를 다룹니다. 전통적인 코딩 작업이 코드의 정확성이나 유닛 테스트로 성공 여부를 측정하는 것과 달리, 게임 생성은 실시간으로 플레이어의 입력에 반응하는 일관된 실행 가능 아티팩트를 제작하는 것을 요구합니다.

저자들은 기존의 평가 방식이 이 작업의 복잡성을 온전히 포착하지 못한다고 주장합니다. 현재의 벤치마크들은 주로 다음 사항에 집중되어 있습니다:

실제 엔진 환경의 복잡성이 결여된 웹 기반 게임.
완전한 구축보다는 기존 프로젝트에 대한 국소적 편집.
실제 게임플레이 동작을 검증하지 못하는 코드나 에셋에 대한 정적 검사.

이를 해결하기 위해, 본 논문은 엔드 투 엔드 게임 생성을 $(s, E) \mapsto G$ 매핑으로 공식화하고, 유효한 벤치마크를 위한 세 가지 핵심 **요구사항(desiderata)**을 식별합니다:

엔진 그라운딩(Engine Grounding): 개발은 고유의 문서, 에셋 및 런타임 제약 조건을 가진 실제 게임 엔진 내에서 이루어져야 합니다.
아티팩트 완결성(Artifact Completeness): 에이전트는 부분적인 코드나 프로토타입이 아니라, 메타데이터, 씬(scene), 스크립트, 에셋을 포함한 완전하고 실행 가능한 게임 프로젝트를 전달해야 합니다.
인터랙티브 검증(Interactive Verification): 평가는 정적 코드 분석이 아닌, 관찰된 게임플레이 상호작용(플레이어 행동 및 시스템 반응)을 기반으로 이루어져야 합니다.

방법론: GameCraft-Bench

저자들은 이러한 요구사항을 Godot 4 엔진을 평가하기 위해 설계된 벤치마크인 GameCraft-Bench에 구현하였습니다.

1. 태스크 스위트 (Task Suite)

규모: 15개의 서로 다른 게임 패밀리(예: 플랫포머, 전략, 로그라이크, 비주얼 노벨, 타이쿤)에 걸친 140개의 태스크.
태스크 구조: 각 태스크 $\tau = (s, E, \rho)$ $τ = (s, E, ρ)$ 는 다음으로 구성됩니다:
- $s$ : 플레이어의 판타지, 핵심 루프 및 메커니즘을 설명하는 자연어 명세.
- $E$ : 워크스페이스, 툴체인 및 공유 에셋을 제공하는 Godot 기반 환경.
- $\rho$ : 검증자가 사용하는 숨겨진 평가 루브릭(rubric).

2. 평가 파이프라인

본 벤치마크는 5단계 파이프라인(그림 5)을 채택합니다:

태스크 패키징: 에이전트는 명세와 환경을 전달받습니다.
에이전트 생성: 에이전트는 완전한 Godot 프로젝트( $G$ )와 시간 기반 키보드/마우스 이벤트가 포함된 재생 가능한 상호작용 트레이스( $\Pi$ ) 세트를 생성합니다.
빌드 게이트(Build Gate): 검증자가 프로젝트 실행을 시도합니다. 빌드에 실패하거나 트레이스를 파싱할 수 없는 경우 점수는 0점입니다.
리플레이(Replay): 검증자는 헤드리스(headless) Godot 인스턴스에서 트레이스를 재생하며, 게임플레이 영상을 기록하고 프레임을 샘플링합니다(2 FPS).
스코어링: 멀티모달 판사(judge)가 네 가지 카테고리에 대해 숨겨진 루브릭을 바탕으로 게임플레이 증거를 점수화합니다:
- 핵심 메커니즘 (M): 규칙, 상태 전이 및 목표.
- 콘텐츠 깊이 (D): 진행도, 다양성 및 런타임 범위.
- 기능적 비주얼 (V): 가독성, 피드백 및 UI 안정성.
- 아트 및 프레젠테이션 (A): 미적 일관성 및 "제작된(authored)" 느낌.
- 최종 점수 공식: $Score = BUILD \times (w_M M + w_D D + w_V V + w_A A)$ , 여기서 가중치는 콘텐츠 깊이와 프레젠테이션을 우선시합니다.

3. 엔진 선택

Godot는 오픈 소스 특성, 가벼운 설정, 네이티브 2D 워크플로우, 텍스트 기반 씬 파일, 그리고 자동화된 재현 가능한 평가에 필수적인 커맨드 라인/헤드리스 실행 능력을 갖추고 있어 선택되었습니다.

주요 결과

저자들은 7개의 프런티어 코딩 에이전트 설정(Claude Code, Codex, Kimi Code, Code Buddy 포함)을 전체 벤치마크로 평가했습니다.

전반적인 성능: 엔드 투 엔드 게임 생성은 여전히 매우 미해결된 과제로 남아 있습니다. 가장 강력한 에이전트인 **Claude Code (Opus-4.7 포함)**는 **41.46%**의 종합 점수를 기록했습니다. 다른 대부분의 에이전트는 40% 미만의 점수를 기록했으며, 일부(예: DeepSeek-V4-Pro)는 2.15%까지 낮았습니다.
카테고리별 분석:
- 메커니즘: 에이전트들은 이 영역에서 상대적으로 더 나은 성과를 보였으며(예: Opus-4.7은 55.34% 기록), 종종 인식 가능한 로컬 상호작용 루프를 생성했습니다.
- 콘텐츠 및 프레젠테이션: 콘텐츠 깊이와 아트/프레젠테이션 점수는 크게 하락했는데, 이는 에이전트가 메커니즘을 완전하고 세련되며 일관된 시스템으로 조립하는 데 어려움을 겪고 있음을 나타냅니다.
실행성 vs 플레이 가능성: 많은 에이전트가 높은 "빌드 통과율(Build Pass Rate)"(게임 실행 성공)을 달랬지만, 유효한 리플레이 트레이스를 제공하지 못하거나 트레이스 내에서 의도된 게임플레이를 구현하지 못하여 최종 점수가 낮게 나타나는 경우가 빈번했습니다.

진단적 발견

시각적 피드백의 중요성: 렌더링된 화면 검사(예: Kimi-K2.6)를 활용한 에이전트는 더 나은 디버깅 능력을 보여주었으며, 소스 코드만으로는 보이지 않는 UI 정렬 오류나 깨진 레벨 레이아웃 등의 문제를 수정했습니다.
도구 사용 $\neq$ 품질: 높은 빈도의 도구 호출(특히 셸 명령)이 더 높은 점수와 상관관계를 갖지는 않았습니다. 성공은 빌드, 데모 트레이스 제공, 그리고 플레이 가능성 확보 사이의 루프를 닫는 것에 달려 있었습니다.
부분적 인수 분해(Partial Factorization): 메커니즘, 콘텐츠, 비주얼 간의 성능 상관관계는 중간 정도였습니다. 에이전트는 콘텐츠 깊이나 시각적 세련미는 부족하더라도 메커니즘적으로는 기능적인 게임을 만들어낼 수 있었습니다.

의의 및 주장

본 논문은 GameCraft-Bench가 초점을 코드의 정확성에서 인터랙티브 시스템의 정확성으로 전환함으로써 창의적 소프트웨어 에이전트를 평가하는 새로운 표준을 세운다고 주장합니다.

벤치마크 계약: 이는 에이전트가 실제 엔진에서 작동하고, 완전한 아티팩트를 전달하며, 상호작용을 통해 판단되어야 한다는 벤치마크 계약을 정의합니다.
현재의 한계: 결과는 현재의 프런티어 에이전트들이 게임과 같은 소프트웨어의 "파편"을 생성할 수는 있지만, 아직 자연어 명세를 완전히 플레이 가능하고 일관되며 시각적으로 일치하는 게임 경험으로 신뢰성 있게 변환할 수는 없음을 보여줍니다.
평가 패러다임: 본 연구는 실행 가능한 창의적 시스템을 평가하기 위해서는 정적 코드 검사, 빌드 성공 또는 시각적 그럴듯함 이상의 상호작용에 기반한 평가(플레이 가능성)가 필요하다고 주장합니다.

저자들은 현재 벤치마크가 2D Godot 게임과 시각적 평가(오디오 제외)로 제한되어 있지만, 복잡한 인터랙티브 시스템을 구축하는 현재 에이전트들의 구체적인 격차를 진단하기 위한 엄격한 프레임워크를 제공한다고 강조합니다.