![바이브 코딩으로 게임 만들기 [실무편] — 재미는 사람이 정하고, 작업장은 설계하라](https://gamecollege.com/wp-content/uploads/2026/10/image-588-1024x960.png)
AI에게 “OO 스타일의 OO 장르 게임을 만들어 줘”라고 말하면, 몇 시간 만에 실제로 구동되는 게임이 나온다. 바이브 코딩이 게임 개발의 문턱을 무너뜨린 지금, 인디 게임 개발자에게 남은 진짜 일은 코드 작성이 아니라 ‘무엇이 핵심 재미인지 정하고, 그것을 AI가 일할 수 있는 형태로 바꾸어 지시하는 것’이다.
[실무편]에서는 세 가지를 구체적으로 다룬다. 검증된 재미를 위키와 커뮤니티 자료로 분해해 기획 데이터로 만드는 방법, 검증된 소스에서 안정성을 배우는 방법, 그리고 레고 블록처럼 맞물리는 에이전트 팀과 하네스를 구성하는 방법이다.
📎 이전 글 보기: 바이브 코딩으로 게임 만들기 [입문편] — AI에게 일을 ‘맡기지’ 말고 ‘시켜라’
01 바이브 코딩의 핵심은 ‘재미’다
기획 감각 없이 막연하게 바이브 코딩을 하면, 돌아가기는 하는데 어딘가 망가진 느낌의 게임이 나온다. 더 큰 문제는 무엇이 잘못됐는지 개발자 스스로도 말로 설명하지 못한다는 것이다. 설명할 수 없으면 AI에게 고치라고 시킬 수도 없다.
02 재미는 ‘검증된 곳’에서 가져온다
자신도 잘 모르는 재미를 구성하려 하면 AI도 사람도 헤맨다. 성공한 장르 게임에는 수많은 플레이어가 이미 시간과 돈을 써서 증명한 재미, 즉 플레이와 서비스로 검증된 콘텐츠라는 확실한 출발점이 있다.
다만 분석의 기준선은 분명히 해 두자. 아이디어 · 규칙 · 장르 문법 같은 구조는 배워 와도 되지만, 아트 · 텍스트 · 사운드 · 코드 같은 표현은 반드시 새로 만든다.
03 기획 요소 학습을 고도화하는 법 — 위키 · 커뮤니티 자료 수집과 반영
검증된 소스가 있다면 그것을 학습시키는 것이 가장 빠르다. 소스가 없는 인디 개발자가 혼자 플레이하며 게임 요소를 분해하면 느리고 놓치는 것이 많다. 다행히 인기 게임에는 플레이어 커뮤니티가 이미 무기 수치, 조합표, 프레임 단위 물리 상수, 방 단위 공략까지 정리해 두었다. 이것이 가장 빠른 1차 기획 데이터다.
수집은 에이전트에게 시키되, 지시서에 표 형식 · 출처 칸 · 등급 칸을 정해 준다. 예를 들어 “이 위키 페이지들에서 무기 진화 조합을 evolution 스키마로 옮기고, 행마다 URL과 게임 버전을 적어. 페이지마다 값이 다르면 C등급과 ★를 붙여”처럼 시킨다. 사람은 핵심 수치 몇 개를 직접 플레이로 대조하고, 등급이 낮은 값부터 의심한다.
📋 위키 수집 지시서 (예시)
## 위키 수집 지시서 (예시)
목표 무기 · 패시브 · 진화 조합을 evolution 스키마로 정리
입력 sources/wiki_urls.txt (게임 버전 표기 포함)
출력 data/evolution.json + reports/evolution_sources.md
규칙 원작 고유명사는 역할 이름으로 바꿔 쓸 것 (예: aura_weapon)
문장 · 이미지는 옮기지 말고 사실과 수치만
행마다 source(URL · 날짜)와 grade(A/B/C) 필수
막히면 출처끼리 값이 다르면 둘 다 적고 ★ 표시04 기획을 시키지 말고, ‘기획서 작성’을 시켜라
기획은 사람이 한다. AI에게는 기획서 작성을 시킨다. 사람이 검증한 재미와 분석 결과, 의도를 넘기면 AI는 그것을 빠짐없이 구조화하고, 빈칸을 찾아 질문하고, 수용 기준까지 붙인 문서로 만든다.
05 AI가 개발자 역할을 할 때: 이해 → 모디파이
오픈소스 게임, 엔진 샘플, 예전에 만든 프로토타입처럼 소스가 이미 있을 때 바로 “고쳐 줘”라고 하는 것은 위험하다. 먼저 코드 구조를 설명하게 하고, 우리 기획서와 다른 점을 목록으로 뽑게 한 뒤, 한 번에 하나씩 고치고 고칠 때마다 실행해 확인한다.
사람은 코드를 쓰는 대신 AI의 설명이 맞는지 판단하고 수정 순서를 정한다. 사라진 것은 타이핑이지, 개발자의 책임이 아니다.
06 검증된 게임 소스로 안정성을 극대화하는 법
재미는 출시작에서 배우고, 안정성은 이미 수많은 기기에서 돌아간 코드에서 배운다. AI가 처음부터 짠 코드는 동작은 해도 예외 상황 · 저장 데이터 · 프레임 차이 같은 곳에서 무너지기 쉽다. 검증된 구조를 먼저 이해하고, 그 패턴을 우리 규칙으로 만들어 구현 에이전트가 따르게 하는 것이 가장 확실한 안정화 방법이다.
첫 단계인 구조 지도는 쓰기 권한이 없는 에이전트에게 맡긴다. 읽기만 하는 에이전트는 실수로 원본을 망가뜨릴 수 없고, 설명이 틀렸는지를 사람이 차분히 대조할 수 있다.
📋 구조 지도 지시서 (예시)
## 구조 지도 지시서 (읽기 전용 에이전트)
목표 samples/platformer 프로젝트의 구조를 설명 — 수정 금지
출력 reports/architecture.md
1) 게임 루프와 물리 업데이트 방식(고정/가변 타임스텝)
2) 상태 전환(플레이어 · 씬)이 어디서 어떻게 일어나는가
3) 입력 처리 경로, 저장 · 불러오기 흐름과 데이터 버전
4) 예외 처리 · 로그가 있는 곳 / 없는 곳
5) 우리 기획서(GDD.md)와 다른 점 목록
도구 Read, Grep, Glob (쓰기 도구 없음)오픈소스를 쓸 때는 라이선스를 가장 먼저 본다. MIT · BSD는 저작권 · 라이선스 고지만 지키면 재사용할 수 있지만, GPL 코드를 섞어 배포하면 내 게임 코드까지 공개 의무가 생길 수 있다. 확인 전에는 읽고 배우기만 하자.
07 레고 블록 에이전트: 규격화가 연결을 만든다
AI 하나에게 모든 일을 시키면 맥락이 뒤섞이고 품질이 흔들린다. Anthropic의 연구에서도 핵심 교훈은 큰 작업을 다룰 수 있는 크기로 쪼개고, 구조화된 산출물로 세션 사이의 맥락을 넘기는 것이었다.
모듈화를 구체적으로 — 네 겹의 구조
블록이 끼워지려면 네 가지가 정해져야 한다. 돌기(산출물의 형식 = 스키마 계약), 블록(역할 카드), 설계도(누가 무엇을 받아 넘기는지 적은 파이프라인 매니페스트), 검수(파일이 저장될 때마다 도는 자동 맞물림 검사)다.
블록을 오래 쓰려면 규칙도 필요하다. 파일 하나에 주인은 하나, 스키마는 필드를 더하기만 하고 뜻을 바꿀 때는 버전을 올린다. 에이전트끼리는 대화로 요약해 넘기지 말고 파일 경로로 넘긴다.
📄 스키마 계약 예시 — schemas/level.v2.json (일부)
{
"$id": "level@2",
"type": "object",
"required": ["id", "size", "hazard_density", "checkpoints"],
"properties": {
"id": { "type": "string" },
"size": { "type": "array", "items": { "type": "integer" }, "minItems": 2, "maxItems": 2 },
"hazard_density": { "type": "number", "minimum": 0, "maximum": 1 },
"new_gimmick": { "type": "string" },
"checkpoints": { "type": "array", "items": { "type": "integer" } }
},
"additionalProperties": false
}📄 작업 카드 — 모든 산출물의 공통 헤더
## 작업 카드 — 모든 산출물의 공통 헤더
- 목적: (이 작업이 기획서의 어떤 항목을 위한 것인가)
- 입력: (참고한 파일 목록)
- 산출물: (생성·수정한 파일 목록)
- 수용 기준: (무엇이 확인되면 완료인가)
- 남은 문제: (다음 담당자가 알아야 할 것)
- 다음 담당: (테스터 / 구현가 / 개발자)처음부터 에이전트를 많이 둘 필요는 없다. 에이전트가 늘어날수록 연결·관리 비용도 늘어난다. 기획서 · 구현 · 테스트 셋으로 시작해 병목이 보일 때 하나씩 늘리자.
08 관리 감독과 테스트 에이전트
Anthropic은 에이전트가 자기 결과물을 평가하면 평범한 작업에도 후한 점수를 준다는 점을 관찰했다. 그래서 만드는 쪽과 검사하는 쪽을 분리하고, 완료 기준을 “3분간 생존 가능”처럼 확인할 수 있는 문장으로 먼저 합의한다.
테스트 에이전트는 ‘작동하는가’를, 사람은 ‘재미있는가’를 판정한다. 둘을 섞지 않는 것이 핵심이다.
09 하네스: 에이전트가 일하는 ‘작업장’을 설계하라
하네스는 맥락을 조립하고, 도구를 열어 주고, 권한을 확인하고, 상태를 저장하고, 결과를 검증하고, 실행 기록을 남기는 층이다. 같은 모델이라도 하네스를 어떻게 짜느냐에 따라 결과가 크게 달라진다.
10 ‘무엇을 시키는가’에서 ‘어떻게 훈련시키는가’로
여기서 ‘훈련’은 모델을 다시 학습시키는 일이 아니다. 신입 팀원에게 매뉴얼을 쌓아 주듯, 에이전트가 매번 참조하는 규칙 · 템플릿 · 평가 기준을 다듬어 가는 일이다.
같은 지적을 두 번 하지 않도록 규칙 파일이나 스킬에 한 줄을 추가하고, 플레이 테스트에서 나온 문제는 테스트 기준표로 옮긴다. 에이전트가 헤맨 로그는 곧 지시서가 모호했던 곳이다.
11 시작 전 점검표
재미 · 기획 · 자료
- ☐ 출발점이 되는 ‘검증된 재미’를 한 문장으로 말할 수 있다
- ☐ 레퍼런스의 핵심 메커니즘을 규칙 · 수치로 분해했다
- ☐ 위키 · 커뮤니티 자료에 출처(URL · 게임 버전)와 신뢰도 등급을 붙였다
- ☐ 원작 고유명사를 역할 이름으로 정규화해 데이터 파일로 뺐다
- ☐ 레벨의 긴장–이완 곡선을 시간축으로 정리했다
- ☐ AI에게 기획이 아니라 ‘기획서 작성’을 시켰고, 기획서는 파일로 저장되어 있다
안정성 · 소스
- ☐ 학습할 엔진 공식 샘플 · 공개 코드의 라이선스를 확인했다
- ☐ 구조 지도(architecture.md)를 읽기 전용 에이전트로 만들었다
- ☐ 안정성 패턴(타임스텝 · 상태 머신 · 세이브 버전 등)을 패턴 카드로 저장했다
- ☐ 세이브 → 로드 왕복 테스트와 자동 플레이 봇이 매번 돈다
- ☐ 엔진 버전을 고정했다
에이전트 · 하네스
- ☐ 산출물마다 스키마와 버전, 공통 머리말(front matter)이 있다
- ☐ 파이프라인 매니페스트에 누가 무엇을 받아 넘기는지 적혀 있다
- ☐ 파일이 저장될 때마다 스키마 검증 훅이 돈다
- ☐ 만드는 에이전트와 검사하는 에이전트가 분리되어 있다
- ☐ 사람 승인이 필요한 작업(푸시 · 업로드 · 삭제) 목록이 있다
- ☐ 세션이 끊겨도 이어받을 상태 파일(진행 기록 · 기능 목록)이 있다
훈련 · 관리
- ☐ 반복된 실수를 규칙 파일이나 스킬에 반영했다
- ☐ 플레이테스트 결과를 테스트 기준표에 추가했다
- ☐ ‘재미있는가’의 판단은 사람의 플레이테스트로 남겨 두었다
12 맺으며
바이브 코딩은 누구나 게임을 ‘만들 수’ 있게 했다. 그러나 누구나 ‘재밌는’ 게임을 만들 수 있게 한 것은 아니다. 재미를 규정하는 감각, 검증된 재미를 분석하는 눈, 기획서로 정리하는 힘, 그리고 에이전트의 작업장을 설계하는 능력이 AI 시대 인디 개발자의 새로운 기본기다.
📎 처음부터 보기: 바이브 코딩으로 게임 만들기 [입문편] — 재미 · 기획서 · 게임디자인 고도화 · 관리/검수 에이전트
글(기획/감수): 정무식 교수(가천대학교 게임영상학과 교수/공학박사)
정무식 교수는?
1994년 트리거소프트 창업 멤버로 출발하여 엔씨소프트 디렉터, 나스닥 상장사인 그라비티의 사외이사 및 루노소프트의 부사장을 역임한 대한민국 1세대 게임 개발자다. 2003년 한국 최초의 인디게임공모전을 기획, 개최한 이후로 국내 인디게임 육성에 오랜 관심과 지원을 이어왔으며, 현재 문화체육관광부 산하 게임물관리위원회 위원/이사, 성남시 4차산업특별위 콘텐츠/디지털/공간 분과장 등을 맡아 국내 게임 산업의 발전과 건전한 문화 정착에 힘쓰고 있다.
참고 자료
본문 인용
- Anthropic Engineering — Harness design for long-running application development (2026.03)
- Anthropic Engineering — Effective context engineering for AI agents
- Claude Code Docs — Extend Claude Code (CLAUDE.md · Skills · Subagents · Hooks · MCP)
- Claude API Docs — Structured outputs
- AI Harness Engineering: A Runtime Substrate for Foundation-Model Software Agents (arXiv, 2026.05)
- Managed Code — What goes in an AI agent harness?
- Vampire Survivors Wiki — Weapon evolution
- Sonic Retro — Sonic Physics Guide
- The Level Design Book
- GDC Vault
- Godot Demo Projects (MIT)
- Unity — Enter the Boss Room: our new multiplayer sample game
- Epic Games — Lyra Sample Game in Unreal Engine
- NoelFB/Celeste (공개 클래스, MIT — 코드에만 적용)
- Robert Nystrom — Game Programming Patterns
- Claude-Code-Game-Studios (GitHub)
더 읽을거리