AI 에이전트 팀이 프롬프트에서 플레이 가능한 2D 게임 프로젝트를 만든다

무엇인가

게임은 소프트웨어 중에서도 까다로운 축이다. 실시간으로 상호작용하는 세계를 유지해야 하고, 코드·씬·에셋·애니메이션·물리·설정이 서로 맞물려야 하며, 그 통합 동작은 실제로 플레이해 봐야만 드러난다. 기존의 LLM 게임 생성 시도는 두 갈래로 갈렸다. 월드 모델 계열(Genie 등)은 영상에서 상호작용 경험을 만들지만 편집 가능한 소스 코드를 남기지 않고, Unreal용 DreamGarden처럼 상용 엔진에 LLM을 붙인 경우는 프로젝트 상태가 GUI와 바이너리 에셋에 흩어져 에이전트가 일관되게 검사하거나 수정할 수 없다. AutoUE·OpenGame·GameDevBench·GameCraft-Bench 같은 최근 연구도 대부분 런타임 검증을 최종 평가 단계로 미루거나, 게임이 빌드·실행되는지만 확인한다. 이 논문은 이 과제를 Prompt-to-Game(P2G) 개발로 규정한다. 자연어 설명과 선택적 참조 이미지만 주어졌을 때, 문제를 스스로 발견하고 고치면서 완전한 플레이 가능 게임 프로젝트를 산출해야 한다는 것이다.

어떻게 동작하나

핵심 기반은 'AI 네이티브' 게임 엔진이다. 저자들은 AI 네이티브의 조건을 세 가지로 정의한다. 첫째 GUI 독립성으로, Phaser를 바탕으로 프로젝트 전체를 텍스트 파일로 표현한다. 각 게임은 씬들의 집합이고, 씬 설정은 타입 검사되는 JSON에 저장되며, 씬은 노드 계층으로 이루어진다. 노드는 시각 표현·충돌 형상·행동 스크립트·설정을 한 단위로 묶고 생성자 안에 숨기지 않고 JSON 필드로 명시한다. 씬 간 공유 노드는 별도 정의 파일로 두고 런타임에 인스턴스화한다. 이 씬-노드-에셋 계층 덕분에 스키마 검증이 실행 전에 누락된 에셋 같은 잘못된 참조를 잡아낸다. 둘째 런타임 접근성으로, 실행 중인 게임을 프레임 동기 방식의 프로그래매틱 인터페이스로 노출한다. 에이전트는 일시정지·재개, 지정 프레임 수 전진, 노드 위치·속도 같은 런타임 속성 조회·수정, '점프 키 누름' 같은 의미론적 행동 주입, 스크린샷 캡처를 할 수 있어 비동기 실시간 시스템을 동기적으로 검증 가능한 과정으로 바꾼다. 셋째 소스 가용성으로, 엔진의 미컴파일 소스 전체를 프로젝트 디렉터리에 복사해 두어 문서가 놓친 API와 구현 세부를 에이전트가 직접 확인하게 한다.

무엇과 다른가

이 인터페이스 위에 8개 전문 역할로 구성된 Adversarial Agent Team(AAT)이 올라간다. 오케스트레이터, 디자이너, 아티스트, 아키텍트, 프로그래머, 감사자(auditor), 플레이어, 리뷰어다. 개발은 세 단계로 진행된다. 의도 정렬 단계에서 디자이너는 '할로우 나이트풍 보스전' 같은 요청을 게임플레이 메커니즘·진행 규칙·수치 시스템을 정의한 GDD로 확장하고, 아티스트는 이미지 생성 모델로 일관된 시각 방향의 컨셉 아트를 만든다. 사용자 확인 후 이 둘이 이후 개발과 평가의 공통 기준이 된다. 병렬 개발 단계에서 오케스트레이터는 게임을 병렬 컴포넌트로 분해하고, 자기진화 저장소에서 관련 스켈레톤·모듈·계약을 사전 지식으로 가져와 각 컴포넌트의 범위와 수용 기준을 담은 PRD를 준비한다. 아키텍트가 구현 전략과 검증 절차를 계획하고 승인되면 프로그래머가 구현하며, 감사자가 엔진의 일관성 검사 도구와 설계 명세로 정적 검증하고, 플레이어가 프레임 동기 제어 아래 게임을 실행하면서 비전 모델로 렌더링 결과가 의도한 모습과 맞는지 판단한다. 정적 감사와 런타임 플레이 테스트를 모두 통과해야 하위 작업이 완료된다. 아티스트 워크플로는 GPT-Image-2와 Nano Banana Pro로 초기 아트를 만들고 배경 제거·크기 정규화를 거쳐 경로·해상도·용도를 기록해 엔진에 등록한다. 마지막 적대적 교정 단계에서는 독립 리뷰어가 기능성, 시각 품질(에셋 완전성·화풍 일관성·화면 명료성), 플레이성(조작 반응성, 전투 피드백의 명확성)을 기준으로 최종 품질 게이트 역할을 하고, 불합격 사유는 오케스트레이터가 수리 과제로 바꿔 재작업 루프를 돈다.

어떻게 쓰나

프로젝트가 수용되면 학습 없는 자기진화 메커니즘이 그 경험을 세 가지 형태로 증류한다. 스켈레톤은 특정 장르에 대응하는 실행 가능한 프로젝트 템플릿으로, 프로젝트 고유 아트는 제거하되 코드 구조·튜닝 값·시각 비율·씬 흐름·런타임 구조는 보존하고 반복 실패와 검증된 수정법을 담은 오류 노트, 에셋 생성 프롬프트와 후처리 관례를 담은 아트 팩을 함께 넣는다. 모듈은 어떤 노드에도 붙일 수 있는 자기완결적 행동 스크립트이며, 이전에 관찰된 런타임 실패를 게임 시작 전에 실행되는 정적 검증 규칙으로 바꾼 자기점검 로직을 포함할 수 있다. 계약은 일반적인 AAT 워크플로를 반복되는 기능·개발 패턴에 맞게 조정한 문서로, 역할별 입력·출력·의존성·검증 기준을 규정한다. 예컨대 맵 계약은 디자이너가 맵 요구사항을 어떻게 명세하고, 프로그래머가 프로젝트 파일에 어떻게 표현하며, 아티스트가 필요한 에셋을 어떻게 공급하고, 감사자와 플레이어가 결과를 어떻게 검증하는지를 정한다. 중요한 점은 이후 프로젝트가 이 경험을 맹목적으로 재사용하지 않고 적응시키고 재검증한다는 것이다.

전제와 한계

실험은 GameCraft-Bench의 15개 게임 유형에서 각 2개씩 무작위로 뽑은 30개 과제로 구성했다. 엔진·입력 설정·데모 녹화 관련 짧은 힌트만 Phaser에 맞게 바꾸고 게임 설명과 평가 루브릭은 그대로 두었다. 모든 하네스에 과제당 24시간, xhigh 추론 노력 예산을 주었고, P2G에서 자체 이미지 생성이 없는 하네스에는 VibeGame과 같은 이미지 생성 모델을 제공했다. GameCraft-Bench가 쓰는 GPT-5.5 판정 모델이 각종 판정 오류를 낸다며 GPT-6.1-Sol을 심판으로 대체했다. 결과적으로 GPT-5.6-Luna를 붙인 VibeGame은 네 평가 범주 모두에서 앞서며 최강 베이스라인 대비 종합 점수를 11.70점 올렸다. 프런티어 모델 GPT-6.1-Sol에서는 Codex(P2G)에 Core Mechanics와 Functional Visuals에서 1점 미만으로 뒤졌지만 Content Depth에서 4.76점, Art & Presentation에서 7.72점 앞서 종합 +4.19점을 기록했다. 저자들은 이를 프런티어 모델이 핵심 메커니즘과 무난한 비주얼은 이미 구현하지만 콘텐츠 깊이와 연출 완성도에서 약하다는 신호로 해석한다. 15개 유형 중 13개에서 각 모델의 최강 베이스라인을 이겼다.

사용자 연구도 있다. 수학·생물정보학 전공 학생, IT 실무자, 게임 애호가 등 30명이 GPT-6.1-Sol 기반 5개 베이스라인과의 30개 과제 조합 150쌍을 평가했고, 쌍마다 2회씩 총 300건의 판정을 모았다. 참가자는 게임 설명과 루브릭을 읽고 익명 처리된 두 게임을 플레이한 뒤 네 범주와 종합에서 더 나은 쪽을 골랐다. VibeGame은 모든 범주에서 모든 베이스라인을 이겼고 평균 종합 승률은 72.7%로, GPT-6.1-Sol 심판의 쌍대 결과와 대체로 일치했다. 절제 실험에서는 AI 네이티브 엔진을 빼면 종합 점수가 10.33점, AAT의 적대적 검토 역할(감사자·플레이어·리뷰어)을 빼면 4.63점 떨어졌다. Codex에 엔진만 추가해도 GPT-6.1-Sol 기준 2.69점이 올랐고, GPT-6.1-Sol로 진화시킨 경험을 GPT-5.6-Luna에 붙이자 2.92점이 올라 강한 모델의 경험이 약한 모델로 전이됨을 보였다.

개발자 관점에서 이 논문의 값은 '텍스트로 직렬화되고, 스키마로 검증되고, 프레임 단위로 멈춰 세울 수 있는 프로젝트 상태'라는 설계 패턴에 있다. 에이전트가 만든 결과물을 신뢰하려면 산출물 자체가 기계 검사 가능해야 하고, 실행 검증이 평가 단계가 아니라 개발 루프 안에 있어야 한다는 주장은 게임이 아닌 다른 복잡한 코드베이스 자동화에도 그대로 옮길 수 있다. 구현과 리뷰를 별도 역할로 분리해 다중 라운드 루프를 도는 구조, 그리고 검증을 통과한 산출물만 재사용 가능한 자산으로 승격시키는 경험 관리 방식도 참고할 만하다. 다만 공개된 수치는 특정 심판 모델(GPT-6.1-Sol)과 GameCraft-Bench 부분집합, 과제당 24시간 예산이라는 조건 위에서 읽어야 한다.

저자들이 밝힌 한계는 명확하다. 이 연구는 2D 게임에 한정되며 더 복잡한 3D 장면에서는 검증되지 않았고, 장기 플레이를 유지하는 완전한 상용 게임을 개발하는 데도 쓰이지 않았다. 또한 AI 네이티브 설계 원칙이 웹 기반 2D 엔진 위에 구현되어 있어, Godot 같은 기존 엔진에 이식해 에이전트가 이미 존재하는 게임 프로젝트를 다루게 하는 것은 남은 과제로 남겨 두었다.