AI로 게임 만들기 — 6개월 만에 프로토타입을 접으며
Tiny Reign 프로토타입을 접었다. 6개월 가까이 작업했고, 4종 유닛 자동 전투에 깃발 시스템까지 붙인 상태에서다. 완성하지 못한 프로젝트를 공개적으로 정리하는 게 쉬운 일은 아닌데, 그래도 남긴 게 있으니 처음부터 정리해두려 한다.
AI가 짠 코드, 다 이해해야 할까
시작하기 전에 걸린 고민이 하나 있었다. Cursor로 개발을 시작하면서 제일 먼저 든 생각인데, AI가 코드를 척척 짜주는데 나는 이걸 다 읽고 이해해야 하나 하는 것이었다.
전에 게임을 만들 때는 당연히 내가 짠 코드니까 전부 알고 있었다. 근데 AI가 짜주는 코드는 양도 많고, 내가 생각하지 못한 방식으로 구현된 경우도 많았다. 읽히긴 읽히는데 온전히 내 것이라는 느낌이 없었다.
다 이해하려고 하면 개발 속도가 확 떨어진다. 그렇다고 무시하고 넘어가자니 나중에 뭔가 터졌을 때 손댈 수가 없을 것 같았다.
고민 끝에 내린 결론은 이거였다. 코드를 100% 이해하는 건 포기하자. 대신 내가 원하는 기능이 제대로 동작하는지 테스트를 훨씬 꼼꼼하게 하자. AI한테 코드를 맡기고 나는 결과물을 검증하는 역할에 집중하는 거다. 직접 개발할 때는 코드를 보면서 흐름을 파악했다면, 이제는 실제로 기능을 써보면서 엣지 케이스를 찾는 데 시간을 더 쓴다.
이게 맞는 방식인지는 지금도 모르겠다. 다만 이 결론을 내리고 나서야 프로젝트를 시작할 수 있었다.
엔진은 Godot으로
이전에 유니티로 캐주얼 게임을 하나 만들어서 출시까지 해봤다. 처음부터 끝까지 직접 코드를 짜는 방식이었는데, 이번엔 다른 방식으로 해보고 싶었다. 바이브코딩으로 게임을 어디까지 만들 수 있는지 궁금했다.
도구는 평소 쓰던 Cursor 대신 Claude Code로 바꿨고, 엔진은 유니티 대신 Godot을 골랐다. 이유가 있었다. Godot은 씬 파일(.tscn)이 텍스트 형식으로 저장된다. 덕분에 AI가 에디터를 직접 열지 않아도 씬 파일을 읽고 쓰는 게 가능하다. 유니티는 씬 파일 구조가 복잡해서 AI가 건드리기 까다로운데, Godot은 그 부분이 훨씬 자유롭다. 엔진을 크게 건드리지 않고도 대부분의 작업을 코드로 처리할 수 있다는 게 바이브코딩과 잘 맞는 이유였다.
만들 게임은 캐주얼 왕국 전략 게임으로 잡았다. 비주얼은 마음에 드는 픽셀아트 리소스를 골라 쓰고, 부족한 부분은 비슷한 스타일을 찾거나 직접 만들기로 했다.
시작 전에 폴더 구조부터 잡았다. Godot은 모든 게 씬으로 구성되고 씬마다 스크립트가 붙는 구조라 스크립트와 씬을 완전히 분리하기가 애매했다. 그래서 scenes 아래에 씬 파일과 해당 씬에서 쓰는 스크립트를 두고, shared 아래에 씬 없이 스크립트만으로 동작하는 로직을 뒀다. 새 유닛을 추가할 때 shared를 건드리지 않아도 되도록 경계를 잡아뒀다.
잘 됐던 것 — 먼저 대화하기
작업하다 보니 AI가 잘하는 것과 못하는 것이 점점 명확하게 나뉘었다.
코드를 짜기 전에 먼저 대화를 나눴다. 왕국 자원 시스템을 만들어야 할 때, 바로 이거 만들어달라고 하지 않고 어떻게 동작해야 하는지, 어떤 데이터가 필요한지, 어떤 상황에서 어떻게 처리해야 하는지를 먼저 정리했다.
이렇게 하면 실제 코드 작업에서 원하는 결과가 한 번에 나오는 경우가 많았다. 반대로 대화 없이 바로 만들어달라고 하면 뭔가 하나씩 빠져 있거나 구조가 생각한 것과 달라서 수정을 여러 번 하게 됐다. 결국 미리 대화하는 시간이 전체 작업 시간을 줄여주는 셈이었다.
이게 되는 이유는 단순한 것 같다. 코드는 어차피 논리로 이루어져 있고, 그 논리를 말로 설명할 수 있으면 AI가 그대로 구현해준다. 대화 자체가 설계 과정이 되는 거다.
잘 안 됐던 것 — 비주얼
타일 같은 비주얼 작업은 달랐다. 게임 맵에 들어갈 타일셋을 AI로 만들어보려고 MCP를 설정해서 PixelLab도 연동해봤다. 처음엔 될 것 같았는데 여러 번 시도해도 원하는 퀄리티가 안 나왔다.
색감이 게임 분위기와 안 맞거나, 타일끼리 붙였을 때 어색하거나, 뭔가 하나씩 마음에 안 드는 게 생겼다. 프롬프트를 더 자세하게 써봐도 크게 달라지지 않았다. 코드처럼 이렇게 해달라고 말로 정확하게 전달이 안 되는 영역이라 그런 것 같다.
왜 접었나
6개월을 그렇게 보내고 접기로 했다. 기술적인 이유보다는 방향성 문제였다.
프로토타입을 계속 만지다 보니 이 게임이 재미있을까에 대한 확신이 점점 흐려졌다. 자동 전투 게임에서 플레이어 개입 포인트를 어디에 둬야 하는지, 왕국 시뮬레이션과 전투를 어떻게 연결해야 하는지, 핵심 루프가 명확하지 않았다. 기술을 더 쌓는다고 이 문제가 해결되는 게 아니었다.
깃발 시스템을 넣은 것도 그 개입 포인트를 찾으려는 시도였다. 만들고 나니 동작은 잘 했는데, 그게 재미의 중심인지는 여전히 모르겠더라.
바이브코딩으로 얻은 것
이 프로젝트의 원래 목적 중 하나가 AI와 협업해서 게임을 얼마나 만들 수 있는지 실험하는 거였다. 그 답은 얻었다.
AI가 코드를 쓰는 속도는 빠르다. 비헤이비어 트리 태스크를 새로 만들거나, CSV 파서를 짜거나, 충돌 레이어 설정을 바꾸는 작업은 대화 몇 번으로 됐다.
반면 구조적인 결정은 여전히 사람이 해야 했다. Hurtbox와 Hitbox를 분리할지, 컴포넌트 패턴을 쓸지, BT 태스크를 어떻게 쪼갤지. 이런 판단을 AI에게 맡기면 코드가 나오긴 하는데 나중에 고치기 어려운 방향으로 가는 경우가 많았다.
처음에 코드를 100% 이해하지 않기로 한 결론과도 이어진다. 세부 구현은 넘겨도 되지만, 구조는 넘기면 안 됐다. 그 선을 어디에 그을지가 결국 바이브코딩의 핵심이었다.
남는 것
기술적인 패턴은 재사용할 수 있다. NavigationRegion2D 기반 이동 시스템, Hurtbox와 Hitbox 분리 구조, CSV 기반 데이터 관리와 컴포넌트 패턴, LimboAI 비헤이비어 트리 연동 방법. 이 시리즈에서 각 시스템을 글로 남긴 이유도 그거다. 다음에 비슷한 걸 만들 때 같은 삽질을 반복하지 않으려고.
접고 나서 든 생각은 이거다. 6개월 동안 만든 건 게임이 아니라 구조와 기록이었다. 게임으로 치면 실패지만, 이 방식으로 뭘 만들 수 있는지 알아보려던 목적으로는 얻은 게 있었다.
다음은 더 작은 규모로 갈 생각이다. 핵심 루프가 한 줄로 설명되는 것. 자동 전투 왕국 시뮬레이션은 그 설명이 너무 길었다. 작게 시작해서 재미 여부를 빨리 확인하는 방향으로 가려 한다. 바이브코딩은 계속한다.
답글 남기기