Show HN에서 뜬 Godogen, Claude Code skills로 Godot 4 게임을 끝까지 생성

관심을 끈 이유는 game demo가 아니라 end-to-end pipeline이었다

2026년 3월 16일 Hacker News에서 Godogen Show HN 글은 247 points와 153 comments를 모았다. 이 프로젝트가 주목받은 이유는 AI가 게임 아이디어를 대충 스케치하는 수준이 아니라, text prompt에서 Godot 4 project, asset generation, visual QA까지 한 흐름으로 묶으려 했기 때문이다. 작성자는 약 1년 동안 네 차례 큰 rewrite를 거쳤다고 설명했다.

HN 글과 GitHub README에 따르면 Godogen은 두 개의 Claude Code skills로 구성된다. 하나는 전체 architecture를 계획하는 orchestrator이고, 다른 하나는 개별 task를 fresh context에서 실행하는 executor다. pipeline은 prompt를 바탕으로 scene과 system 구조를 설계하고, 2D 또는 3D asset을 만들고, GDScript를 작성하고, 실행 화면을 캡처해 다시 수정한다. README는 commodity hardware에서도 실행 가능하다고 설명하지만, 실제 한 번의 generation은 몇 시간이 걸릴 수 있다고 적고 있다.

핵심은 domain-specific memory와 independent evaluation loop

작성자가 강조한 첫 번째 bottleneck은 GDScript training data scarcity다. Godot에는 850개가 넘는 classes가 있고 문법도 Python과 비슷해, model이 Python idiom을 잘못 끌어오면 바로 compile되지 않는 코드가 나온다. 이를 보완하기 위해 hand-written language reference, XML에서 변환한 API docs, quirks database를 만들고, 필요한 API만 lazy-load하도록 구성했다.

두 번째는 build-time state와 runtime state의 차이다. Godogen은 .tscn text를 직접 편집하는 대신 memory에서 node graph를 만든 뒤 serialize하지만, @onready나 signal connection처럼 runtime에서만 의미가 생기는 요소는 따로 의식해야 한다. 작성자는 node owner가 올바르지 않으면 save 과정에서 object가 사라질 수 있다고 설명했다. 세 번째는 evaluation loop다. 같은 coding agent가 자기 결과를 평가하게 두지 않고, 별도의 Gemini Flash vision pass가 rendered screenshot만 보고 z-fighting, missing texture, broken physics 같은 문제를 잡는다.

• 작성자는 Godogen을 약 1년 동안 네 번 큰 폭으로 다시 썼다고 밝혔다.
• 전체 workflow는 planning용 orchestrator와 execution용 executor, 두 Claude Code skills로 나뉜다.
• GDScript 약점을 보완하기 위해 850+ Godot classes를 다루는 custom reference와 lazy-loaded docs를 사용한다.
• visual QA는 코드가 아니라 실제 screenshot을 기준으로 별도 vision model이 수행한다.

이 프로젝트가 보여주는 더 큰 신호는 game generation이 더 이상 flashy demo만으로 평가되지 않는다는 점이다. HN 반응은 agent가 실제 engine constraint, asset pipeline, runtime bug까지 다루기 시작할 때 개발자들이 더 진지하게 보기 시작한다는 것을 보여준다.

출처: Hacker News discussion, Godogen README