바이브 코딩의 진짜 어려운 점은 게임을 만드는 게 아님. 'AI가 만든 것 같은' 느낌이 안 나게 만드는 거지.
The hard part of vibe coding isn't making a game. It's making one that doesn't feel generated.
핵심 요약
AI로 게임을 만드는 바이브 코딩에서, 단순히 작동하는 것을 넘어 일관성 있고 완성도 높은 결과물을 뽑아내는 방법에 대한 고찰.
- 바이브 코딩 한계 — AI가 생성한 결과물은 종종 파편화되고 어색한 느낌을 줌.
- 상세 명세서 활용 — 세부적인 요구사항을 명시하여 AI의 결과물 품질을 높임.
- 피드백 루프 구축 — 브라우저에서 실시간으로 테스트하고 수정하는 과정을 자동화함.
- 인간의 마무리 — AI가 만든 초안을 다듬는 인간의 손길이 여전히 필수적임.
이전 FPS 실험에서 상세한 명세서로 작동하는 프로토타입을 만들 수 있는지 확인했음. 이번에는 같은 접근 방식을 더 밀어붙여서, 인간이 다듬기 전까지 AI가 생성한 결과물이 얼마나 완성도 높은 게임에 가까워질 수 있는지 테스트함.
생성된 게임을 실행하는 건 쉬움. 하지만 하나의 일관된 게임처럼 느껴지게 만드는 건 훨씬 어려움.
바이브 코딩으로 나온 결과물 중 상당수는 기술적으로는 작동하지만 여전히 '슬롭(slop)'처럼 느껴짐: 파편화된 메커니즘, 뻣뻣한 움직임, 어울리지 않는 애니메이션, 자리 채우기용 UI, 약한 피드백 등.
상세하고 테스트 가능한 명세서가 이런 한계를 얼마나 극복할 수 있는지 보고 싶었음. GPT-5.6 Sol을 Codex를 통해 PlayCanvas에서 3인칭 프리런 게임을 만들도록 시켰음. 단순히 달리기, 슬라이딩, 볼팅, 구르기, 벽 타기, 벽 점프를 구현하는 게 목표가 아니었음. 움직임, 애니메이션, 카메라, 효과, 오디오, HUD, 코스가 모두 같은 게임의 일부처럼 느껴져야 했음.
명세서에는 마무리 작업을 단순히 나중에 하는 청소 작업으로 남겨두지 않고 명시적으로 포함했음. 움직임 튜닝, 애니메이션 전환, 카메라 동작, 시각적 언어, 코스 지오메트리, UI 상태, 런타임 검증 기준을 정의했음.
덕분에 내 하네스(harness)에 피드백 루프가 생겼음: 게임을 빌드하고, 브라우저에서 실행하고, 실제 입력으로 조작하고, 플레이어, 카메라, 체크포인트 상태를 검사하고, 스크린샷을 비교한 뒤 수정함. 컴파일되는 빌드는 끝이 아니라 시작점이었음.
여전히 거친 부분은 있지만, 내가 보통 보던 생성된 프로토타입들보다 훨씬 더 일관된 게임에 가까움. GPT-5.6 Sol에서 인상 깊었던 건 특정 기능이 아니라, 공유된 시각적/기계적 목표를 향해 반복하면서 이 모든 시스템을 정렬된 상태로 유지했다는 점임.
전체 프롬프트와 더 많은 예시: https://github.com/playcanvas/prompts/tree/main/freerun-08
인간의 마무리 작업은 여전히 필수적임. 진짜 이득은 구제해야 할 거친 프로토타입이 아니라, 다듬을 수 있을 만큼 일관된 상태에서 시작한다는 점임.



