AI가 Godot 게임을 만든다고? 개발자들의 반응은?

개발자는 LLM이 GDScript에 대한 이해도가 낮아 AI 환각(Hallucination)으로 인해 컴파일 오류가 발생하는 문제를 해결하기 위해, 맞춤형 언어 명세, API 문서, 쿼크 데이터베이스를 구축했다. 특히, 850개 이상의 클래스를 가진 Godot API를 효율적으로 사용하기 위해, 에이전트가 런타임에 필요한 API만 Lazy Loading 하도록 설계했다. 이는 LLM의 Context Window 제약을 극복하고, 정확한 코드 생성을 가능하게 하는 핵심 기술이다.

본 시스템은 빌드 타임(Build Time)과 런타임(Runtime)의 차이로 발생하는 문제를 해결하기 위해, 씬(Scene)을 헤드리스(Headless) 스크립트로 생성하고 .tscn 파일로 직렬화하는 방식을 사용한다. 이로 인해, `@onready`와 같은 런타임에만 사용 가능한 기능을 빌드 시점에 사용할 수 없다는 제약이 발생한다. 개발자는 이러한 제약을 고려하여, 각 API가 사용 가능한 시점을 정확하게 모델에게 알려주는 Prompt Engineering을 통해 문제를 해결했다.

개발자는 코딩 에이전트의 편향성을 극복하기 위해, Gemini Flash를 활용한 시각적 QA(Visual QA) 시스템을 구축했다. 이 시스템은 렌더링된 스크린샷을 분석하여, 텍스트 분석으로는 감지하기 어려운 시각적 버그(z-fighting, 텍스처 누락 등)를 찾아낸다. 이는 AI가 생성한 게임의 품질을 향상시키는 데 중요한 역할을 하며, AI 기반 게임 개발 파이프라인(AI-driven Game Development Pipeline)의 신뢰성을 높이는 핵심 요소로 작용한다.

커뮤니티에서는 데모 게임의 품질에 대한 비판과 함께, C# 사용, 에셋 파이프라인, 개발 루프에 대한 질문이 제기되었다. 특히, C#을 사용하면 LLM이 C#에 더 능숙하고, tscn 파일 처리가 용이하여 개발 효율성을 높일 수 있다는 의견이 제시되었다. 또한, 에셋 파이프라인의 복잡성과 개발 루프의 개선 필요성에 대한 논의가 이루어졌다. 멀티모달 분석(Multimodal Analysis)을 통해 에셋 품질을 개선하고, 개발 프로세스를 최적화해야 한다는 의견도 제시되었다.

개발자는 Claude Code를 사용하여 Godot 게임을 생성하는 과정에서, Godot의 복잡한 파일 형식과 API를 이해하고 처리해야 하는 어려움에 직면했다. 특히, 850개 이상의 클래스를 가진 Godot API를 LLM이 정확하게 이해하도록 하기 위해, 맞춤형 언어 명세와 API 문서를 구축하는 데 많은 노력을 기울였다. 또한, 데이터 격리 아키텍처(Data Isolation Architecture)를 통해 각 작업의 독립성을 보장하고, 오류 발생 시 전체 파이프라인에 미치는 영향을 최소화했다.