Claude Code로 Godot 4 게임을 자동 생성하는 'Godogen' 프로젝트

TL;DR Highlight

Claude Code 파이프라인은 게임 설명만으로 아키텍처 설계부터 에셋 생성, GDScript 코딩, 비주얼 QA까지 자동화하여 완성된 Godot 4 프로젝트를 생성하지만, 커뮤니티는 실용성보다 기술 데모 수준이라고 평가한다.

Who Should Read

Godot 또는 다른 게임 엔진으로 AI 에이전트 기반 자동화 파이프라인을 실험해보고 싶은 개발자, 또는 Claude Code의 'skills' 기능을 활용한 멀티모달 에이전트 설계에 관심 있는 개발자.

Core Mechanics

게임 설명 텍스트를 입력하면 두 개의 Claude Code 'skill'이 파이프라인을 오케스트레이션한다. 하나는 아키텍처를 기획(plan)하고, 다른 하나는 실제로 실행(execute)한다. 각 태스크는 컨텍스트 집중도를 높이기 위해 매번 새로운 컨텍스트에서 실행된다.
에셋 생성도 자동화되어 있다. 2D 아트와 텍스처는 Gemini로 생성하고, 선택된 이미지를 3D 모델로 변환할 때는 Tripo3D API를 쓴다. '비용 대비 시각적 임팩트'를 최대화하는 방식으로 예산을 관리한다고 명시하고 있다.
GDScript는 LLM 학습 데이터가 워낙 적어서 모델이 잘 모르는 문제가 있다. 이를 해결하기 위해 커스텀 GDScript 언어 레퍼런스와 850개 이상의 Godot 클래스 API 문서를 lazy-load 방식으로 공급하는 별도 장치를 만들었다.
비주얼 QA 루프가 내장되어 있다. 실제로 Godot 엔진에서 게임을 구동하고 스크린샷을 캡처한 다음, Gemini Flash의 비전 기능으로 z-fighting(면이 겹쳐서 깜빡이는 렌더링 버그), 누락된 텍스처, 물리 오류 등을 자동으로 감지하고 수정한다.
필요 환경은 Godot 4(headless 또는 editor), Claude Code, GOOGLE_API_KEY(Gemini), TRIPO3D_API_KEY(3D 게임 한정), Python 3이다. Ubuntu/Debian에서 테스트됐고, macOS는 X11/xvfb 의존성 때문에 미지원이다.
publish.sh 스크립트를 실행하면 새 프로젝트 폴더가 세팅되고, PROJECT.md에 원하는 게임을 기술한 뒤 Claude Code를 실행하는 방식으로 동작한다. 데모 프롬프트는 demo_prompts.md에서 확인할 수 있다.
출력 결과는 씬 트리, GDScript 파일, 에셋이 정리된 실제 Godot 4 프로젝트다. 2D와 3D 모두 지원하며, 고사양 서버 없이 일반 PC에서도 돌아간다고 설명하고 있다.

Evidence

게임 개발자들의 반응은 대체로 부정적이다. '데모 영상의 물리 엔진이 엉망이고 결과물이 생기가 없다', 'Three.js 예제 스타터보다도 게임답지 않다'는 평가가 여럿 나왔다. 한 게임 개발자는 '템플릿으로 시작하는 게 낫다'고 잘라 말했다.
GDScript 대신 C#을 쓰면 어떻냐는 실용적인 제안이 있었다. 실제로 Godot + C#으로 vibecoding(AI와 함께 즉흥 코딩)을 해봤는데 LLM이 C#은 잘 알고 .tscn 포맷도 의외로 잘 처리해서 GDScript보다 훨씬 수월했다는 경험담이 공유됐다. 인터페이스 설계 에이전트와 구현 에이전트를 분리하면 토큰 비용도 절감된다는 팁도 함께 나왔다.
직접 Claude Code로 RPG 제작을 시도했다가 실패했다는 사례도 있었다. 에이전트가 에셋을 무작위로 배치하거나 기존 데모를 복붙하려 했는데 맥락 파악이 안 돼서 결국 '기능적이지만 못생긴 맵 또는 데모 복사본 중 하나만 가능하다'고 AI 스스로 인정했다고 한다. 게임 설계 개념 없이 에이전트만 믿고 시작하면 한계가 명확하다는 결론이었다.
'인간의 개입을 최소화하는 방향으로 최적화하는 게 틀린 접근'이라는 비판이 공감을 얻었다. 'LLM은 마법 상자가 아니고, 아무리 기다려도 마법 상자는 나오지 않을 것'이라며 인간의 취향과 판단이 결합될 때 진짜 유용해진다는 의견이었다. 실제로 AI 게임 개발 Discord에서 에이전트로 게임 만드는 사람들이 이미 많고, 더 짧은 경로가 있을 수 있다는 제안도 있었다.
프로젝트 README와 댓글 일부가 AI로 작성된 것 같다는 지적이 나왔다. Gemini의 특유 주석 스타일이 코드에 그대로 남아있다는 구체적 근거도 제시됐다. '완성된 게임 생성 도구보다, 아티스트나 프로그래머가 반복 작업을 자동화하거나 엔진을 배우는 보조 도구로 포지셔닝했으면 훨씬 긍정적으로 봤을 것'이라는 건설적 비판도 있었다.

How to Apply

GDScript 대신 C#을 써서 Godot 에이전트 파이프라인을 만들 계획이라면, LLM이 C#을 훨씬 잘 알고 있으므로 커스텀 언어 레퍼런스 주입 없이도 더 안정적인 코드 생성이 가능하다. 인터페이스 정의 에이전트와 구현 에이전트를 분리하면 토큰 비용도 줄일 수 있다.
게임 전체를 자동 생성하기보다는, 특정 씬이나 기능 단위로 Claude Code에 위임하는 방식이 현실적이다. 이 프로젝트의 'plan + execute' 2단계 skill 구조와 lazy-load API 문서 공급 방식은 다른 복잡한 DSL(도메인 특화 언어) 기반 프로젝트에도 그대로 응용할 수 있다.
비주얼 QA 루프 아이디어는 게임 외 다른 UI/그래픽 생성 파이프라인에도 적용 가능하다. 결과물을 실제로 렌더링하고 비전 모델로 스크린샷을 분석해 자동으로 피드백하는 방식은, 예를 들어 웹 UI 자동 생성 에이전트의 품질 검증 단계에 바로 이식할 수 있다.
이 프로젝트를 완성된 게임 생성 도구로 쓰기보다는, 프로토타입이나 게임잼(짧은 기간 게임 제작 대회)용으로 활용하는 게 적합하다. 제대로 된 결과물을 원한다면 AI가 생성한 뼈대 위에서 직접 씬과 스크립트를 수정하는 하이브리드 접근을 취하는 것이 현실적이다.

Terminology

GDScriptGodot 엔진 전용 스크립팅 언어. Python과 문법이 비슷하지만 사용자 수가 적어 LLM 학습 데이터가 부족하다는 게 이 프로젝트의 핵심 해결 과제다.

Claude Code skillClaude Code에서 특정 작업을 수행하도록 사전 정의한 에이전트 동작 단위. 이 프로젝트는 '기획(plan)'과 '실행(execute)' 두 skill로 전체 파이프라인을 구성한다.

z-fighting두 개의 3D 면이 거의 같은 위치에 겹쳐있을 때 어느 면을 앞에 그려야 할지 GPU가 판단하지 못해 깜빡이는 렌더링 버그. 이 프로젝트의 비주얼 QA가 자동으로 감지하는 대표적 오류다.

headless모니터나 디스플레이 없이 백그라운드에서 실행되는 모드. 서버 환경이나 CI 파이프라인에서 Godot를 돌릴 때 사용한다.

vibecoding구체적인 설계 없이 AI와 즉흥적으로 대화하며 코드를 생성해나가는 개발 방식. 빠른 프로토타이핑엔 유용하지만 복잡한 프로젝트에서 한계가 뚜렷하다.

lazy-load필요한 시점에 데이터를 불러오는 방식. 이 프로젝트에서는 850개 이상의 Godot API 문서를 처음부터 전부 컨텍스트에 넣지 않고, 필요한 클래스 문서만 그때그때 불러와 토큰을 절약한다.