AI는 경험을 대체하지 않습니다. 오히려 경험을 증폭시킵니다.

제가 마침내 게임을 출시하기까지 의도적으로 범위를 축소한 방법.

저의 이전 프로젝트는 Godot RPG였습니다.

매달 프로젝트는 더 커졌습니다.

매달 출시와는 더 멀어졌습니다.

어느 시점에 저는 제가 더 이상 게임을 만들고 있는 것이 아니라, 끝이 없는 프로젝트를 만들고 있다는 사실을 깨달았습니다.

그래서 저는 완전히 역행하는 것처럼 느껴지는 일을 했습니다. 상업용 게임을 3일 안에 완성할 수 있을 때까지 의도적으로 범위를 축소한 것입니다.

먼저 약간의 배경 설명을 드리자면, 저는 직업이 소프트웨어 엔지니어(Software Engineer)이며, 처음 코딩을 배우는 취미 활동가가 아닙니다. 이 점은 이 이야기가 전개되는 방식에 있어 중요합니다.

Stage 0: 계획

저는 제 포트폴리오를 위해 장난감 데모가 아닌, 실제 규모를 갖춘 완성된 상업적 프로젝트를 하나 더 원했습니다. 기존의 Godot RPG는 손을 댈 때마다 계속 커졌기 때문에, 이번에는 의도적으로 다른 종류의 프로젝트를 선택했습니다.

몇 가지 장르를 검토한 끝에 카드 게임으로 결정했습니다. 이유는 실용적이었습니다:

• 규칙이 이미 존재합니다. 플레이어들이 이미 이해하고 있습니다.
• 적의 경로 탐색(Pathfinding), 레벨 에디터(Level Editor), 디버깅해야 할 절차적 생성(Procedural Generation)이 없습니다.
• 적은 양의 콘텐츠로도 충분히 완성된 느낌을 줄 수 있습니다.

'Big Two'가 명확한 선택지였습니다.

제 목표는 꿈의 게임을 만드는 것이 아니었습니다. 제 목표는 게임을 완성하는 법을 다시 배우는 것이었습니다.

꿈의 게임은 사라지지 않습니다. 추진력(Momentum)이 사라질 뿐입니다.

기술 스택(Tech Stack)의 경우, 가장 빠르게 움직일 수 있는 것을 선택했습니다: HTML5 + Phaser 3 + Vite + TypeScript. 이것이 세상에서 가장 강력한 옵션이기 때문이 아니라, 도구(Tooling)에 대해 고민하는 것을 멈추고 바로 개발을 시작할 수 있을 만큼 제가 이미 잘 알고 있는 것이었기 때문입니다.

그런 다음 실제 설계 문서(Design Doc)를 작성했습니다. 소설처럼 길게 쓰는 것이 아니라, 개발을 진행하기에 충분할 정도만 작성했습니다: 핵심 Big Two 규칙 + 아이템 시스템 규칙, 대략적인 스토리 개요, 그리고 처음 두 명의 상대방 이름과 성격 정도였습니다. 그 외의 모든 것은 개발 과정에서 진화하도록 두었습니다.

Stage 1: 뼈대 구축

최우선 순위: 핵심 루프(Core Loop)를 플레이 가능하게 만들고, 그것이 실제로 재미있는지 증명하는 것입니다.

저는 스스로에게 한 가지 규칙을 계속 되뇌었습니다:

기본 카드 게임이 재미없다면, 그 위에 구축된 그 어떤 것도 중요하지 않습니다.

Claude Code가 규칙 엔진 (rules engine)의 초기 중노동을 담당했습니다. 그 후에는 개발을 계속 진행하기 위해 Codex와 Copilot을 번갈아 사용했습니다. 이는 어떤 정교한 멀티 에이전트 (multi-agent) 전략 때문이 아니라, 에이전트 사용 제한 (usage limits)이 실제로 존재하기 때문이었으며, 하나의 도구를 다 쓰고 나서 계속 진행해야 할 때 도구를 전환하는 것은 자연스러운 일이었습니다. 또한 아키텍처 (architecture) 결정을 위해 내내 웹 채팅 창을 열어두었습니다. 이를 교대 근무 일정이라고 생각하면 됩니다. 다만 노동자는 AI 에이전트였고, 교대 시간은 시계가 아니라 속도 제한 (rate limits)에 의해 결정되었습니다.

이 단계에서는 모든 시각적 에셋 (visual asset)이 플레이스홀더 (placeholder)였습니다. 단순한 도형, 아이콘, 또는 SVG 형태였습니다. 어떤 기능도 최종 아트워크 (artwork)를 기다리며 지체되어서는 안 되었습니다. 우선순위는 시스템들이 실제로 서로 연결되어 있는지 확인하는 것이었습니다: 저장/불러오기 (save/load), 다중 엔딩 (multiple endings), 처음부터 끝까지의 전체 플레이 (full playthrough). 만약 색칠된 사각형들이 아트워크를 대신하고 있는 상태에서 게임 전체를 클릭하며 진행할 수 없다면, 나중에 아무리 다듬어도 해결할 수 없기 때문입니다.

2단계: 아트 (Art)

아트의 경우 GPT Plus로 충분했습니다. 하지만 프롬프팅 (prompting)은 의도적이어야 했습니다. 어려운 점은 단순한 출력량이 아니라 일관성 (consistency)을 유지하는 것이었습니다.

스토리 CG를 생성하기 전에, 먼저 캐릭터 디자인과 방/배경 레퍼런스 (references)를 확정했습니다. 모든 새로운 일러스트레이션은 해당 레퍼런스들을 재사용했기에, 캐릭터와 장소들이 서로 관련 없는 생성된 이미지들을 짜깁기한 것처럼 보이지 않고 동일한 시각적 정체성 (visual identity)을 유지할 수 있었습니다.

대부분의 작업은 이미지를 생성하는 것이 아니었습니다. 시각적 편차 (visual drift)를 방지하는 것이었습니다.

한 가지 구체적인 예로, 표정을 하나씩 생성하는 대신 하나의 스프라이트 시트 (sprite sheet)로 생성한 뒤 나중에 자르는 방식을 사용했습니다. 이를 통해 동일한 캐릭터, 동일한 조명, 동일한 스타일을 유지하며 프레임 간의 편차를 없앨 수 있었습니다.

이 단계는 제가 전혀 통제할 수 없는 작업, 즉 itch.io의 퍼블리셔 온보딩(publisher onboarding) — 지급 모드(payout mode), 세금 인터뷰(tax interview), PayPal 연결 — 과 병행하여 진행되었습니다. 이 과정은 더 열심히 일한다고 해서 속도를 높일 수 있는 것이 아니었기에, 아트 파이프라인(art pipeline)이 계속 진행되는 동안 가능한 한 빨리 시작하여 백그라운드에서 실행되도록 두었습니다.

게임 개발은 단순히 코드를 작성하는 것만이 아닙니다. 출시 전에 지루한 행정 업무도 마무리해야 합니다.

3단계: 오디오, 폴리싱(Polish), 그리고 디버깅의 구렁텅이

오디오는 두 가지 소스에서 가져왔습니다: Kenney (CC0 효과음)와 StockTune (구독 기반 음악, 퍼블릭 도메인 라이선스). 콘텐츠의 대부분이 갖춰진 후, 갤러리/언락(unlock) 모드를 구축했고, 그 후 제가 '디버깅 지옥'이라고밖에 설명할 수 없는 상황에 직면했습니다 — BGM 라이프사이클(lifecycle) 버그, 세이브 상태(save-state)의 예외 케이스(edge cases), 애니메이션 폴리싱(animation polish) 등을 하나씩 추적해 나갔습니다.

EXE 파일을 배포한다고 해서 디버깅이 끝나는 것은 아니었습니다. 그것은 단지 완전히 새로운 종류의 버그들을 불러올 뿐이었습니다.

3일간의 이야기

저는 이 게임을

엔지니어로서, 저는 이미 그곳에 도달하는 방법을 알고 있었습니다.

시스템을 어떻게 구조화할지.

코드를 어떻게 유지보수 가능하게(maintainable) 만들지.

기능 추가를 어떻게 멈출지.

양쪽 측면을 모두 알고 있었기에, 저는 **"다음에 무엇을 만들어야 할까?"**라고 묻느라 막히는 일이 거의 없었습니다. 설계 문서(design doc)는 작성하는 데 약 3시간 정도 걸렸습니다. 그 이후의 모든 과정은 발견(discovery)이 아닌 실행(execution)이었습니다.

도구 및 리소스 (Tools & Resources)

도구 (Tooling): VS Code, GitHub, HTML5, Phaser 3, Vite, TypeScript, Claude Code, Codex, GitHub Copilot, ChatGPT Plus, Playwright, Electron, 그리고 PNG를 WebP로 일괄 변환하기 위한 작은 커스텀 Python + Pillow 스크립트(asset_builder.py).

오디오 (Audio): Kenney (CC0 효과음) 및 StockTune (AI 생성 퍼블릭 도메인 음악).

3일이라는 시간은 불가능하게 들립니다.

Git 히스토리를 보기 전까지는 말이죠.

Git에 기록된 그 3일의 실제 모습은 다음과 같습니다:

거대한 도약은 없었습니다. 그저 수백 개의 작은 발걸음이 있었을 뿐입니다.

돌이켜보면, 이 이야기에서 흥미로운 부분은 3일이라는 시간이라고 생각하지 않습니다.

그것은 다른 무언가입니다.

플레이어로서, 저는 이미 어떤 종류의 게임을 즐기는지 배우는 데 수년을 보냈습니다.

엔지니어로서, 저는 이미 소프트웨어를 구축하는 방법을 배우는 데 수년을 보냈습니다.

AI는 저에게 그러한 경험을 준 것이 아닙니다.

AI는 단지 제가 그 경험들을 훨씬 더 빠르게 통과할 수 있게 해주었을 뿐입니다.

AI는 실행(execution)을 가속화했습니다.

경험은 의사결정(decisions)을 가속화했습니다.

범위(scope)를 줄인 것이 출시(shipping)를 가능하게 만들었습니다.

그 실험은 결국 DULAN이 되었습니다. 모든 상대방이 자신만의 방, 음악, 성격, 그리고 반응형 대화를 가지고 있으며, 플레이 방식에 따라 여러 엔딩이 결정되는 스토리 중심의 빅투(Big Two) 게임입니다.

모든 커밋(commit)은 작았습니다. 그것들을 만들고 있는 동안에는 그 어떤 것도 중요하게 느껴지지 않았습니다.

돌이켜보면, 그들은 단순히 게임을 만들고 있었던 것이 아니었습니다.

그들은 수년간의 경험을 제가 마침내 출시할 수 있는 무언가로 축적(compounding)하고 있었던 것입니다.