바이브 코딩으로 게임 만들기 [입문편] – AI에게 일을 ‘맡기지’ 말고 ‘시켜라’

AI가 개발 전반에 쓰이는 시대를 맞아, 인디 게임 개발자에게도 AI를 활용한 게임 개발은 중요한 이슈가 되었다. 오늘 이야기는 ‘바이브 코딩으로 게임을 만드는 법’에 대한 핵심 강의다. 결론부터 말하면 AI에게 일을 ‘맡기는’ 사람과 ‘시키는’ 사람의 차이, 그리고 무엇보다 결과물의 큰 차이를 만드는 기획서와 게임 디자인 분해의 중요성에 대한 이야기다.

글(기획/감수): 정무식 · 가천대학교 게임영상학과 교수

📎 이어지는 글: 바이브 코딩으로 게임 만들기 [실무편] — 위키 수집 · 레고 블록 모듈화 · 검증된 소스로 안정성 높이기

INTRO · 1년 사이에 바뀐 것

카파시는 2025년 2월 ‘바이브 코딩’이라는 말을 만들었고, 1년 뒤인 2026년 2월에는 스스로 그 말이 이미 낡았다고 하며 ‘에이전틱 엔지니어링’을 제안했다. 이는 코드를 직접 쓰지 않고 에이전트를 지휘·감독하는 것이 개발의 기본이 되었다는 뜻이다.

PART 01 · 재미 — 바이브 코딩의 핵심은 재미다

AI로 누구나 빠르게 결과를 만드는 시점이지만, 현업 실무자들이 공통으로 지적하는 한계가 있다. AI로 기계적으로 동작하는 게임은 매우 빨리 만들 수 있지만, 재미있는 최종 결과물로 완성해 나가는 과정은 결코 쉽지 않다는 것이다.

가장 흔한 오해는 ‘개발이 빠르고 쉬워진 것’을 ‘게임 콘텐츠의 완성이 쉬워진 것’으로 착각하는 것이다. AI 중심 시대일수록 재미를 정의하고 판단하며 버릴 것을 고르는 일은 여전히 사람의 몫이다.

PART 02 · 기획서 — 콘텐츠의 핵심은 기획서다

AI에게 ‘게임을 제작해’라고 하면 기획의 판단까지 AI에게 넘어간다. 하지만 ‘이 분석 결과를 이 양식의 기획서로 작성해 줘’라고 시키면, 판단은 사람이 쥐고 문서화라는 작업을 AI가 담당하게 된다. 그리고 AI 업무의 핵심은 기준을 문서로 구성하는 것이다. 기준이 있으면 검증할 수 있고, 검증할 수 있으면 부분 수정이 가능하고, 결정권은 계속 사람에게 남는다.

때문에 AI에게 바로 구현을 시키지 말고, 먼저 기획서를 요약하게 하고 모호한 부분을 질문하게 한다. AI의 이해가 확인된 뒤 구현하고, 마지막으로 검증된 뼈대를 유지한 채 콘텐츠를 변형하고 확장한다. 오해는 코드가 아니라 요약 단계에서 잡는 것이 가장 싸다.

PART 03 · 게임디자인 고도화 — 분해해서, 컨트롤 가능하게

검증된 게임 기획서 혹은 소스를 가지고 있다면 AI를 통해 빠르게 학습하고 수정할 수 있다. 게임을 처음 만드는 개발자라면 장르 게임의 역기획부터 시작하자. 게임 디자인의 두 축인 핵심 메커니즘과 레벨 디자인을 바이브 코딩으로 분해하고, 수치와 데이터로 분리해서, 직접 컨트롤 가능하게 만든다.

A. 핵심 메커니즘

이렇게 이름을 붙여 분해하면 AI에게 “코요테 타임을 켜고 값을 슬라이더로 노출해”처럼 정확히 작업을 지시할 수 있다.

점프·중력·대시 관련 수치를 전부 상단 상수로 빼고,
플레이 중에 슬라이더로 바꾸는 디버그 패널을 붙여줘.
조정값은 프리셋 JSON으로 저장·불러오기.

게임을 만들기 전에 튜닝 패널부터 만들게 시키면, AI와의 대화가 ‘좀 더 쫀득하게 해 줘’가 아니라 ‘중력 슬라이더 범위를 넓혀 줘’가 된다.

B. 레벨 디자인

레벨 디자인 역기획을 혼자 처음부터 할 필요는 없다. 많은 인기 게임의 커뮤니티에는 이미 레벨을 방 단위로 분해해 둔 자료가 존재한다. AI에게 위키 내용을 표 형식으로 정리하게 시키고, 사람은 직접 플레이하며 검수한다.

기획자 전성시대를 맞아 바이브 코딩이 게임 디자이너에게 주는 가장 큰 선물은 바로 ‘툴’이다. 과거에는 기획자가 사용할 레벨 에디터를 만들기 위해 툴 프로그래머에게 작업을 요청해야 했지만, 이제는 기획서의 데이터 스키마만 있으면 AI에게 전용 에디터 제작을 시킬 수 있다. 그리고 이 툴은 곧 기획서의 시각화로 연계된다.

여기까지가 ‘무엇을 시킬지’다. 남은 문제는 이 작업들을 에이전트에게 어떻게 안정적으로 시키고 검수할지다.

PART 04 · 관리 · 검수 통합 에이전트 운영법

바이브 코딩을 활용한 게임 개발에서 초심자들이 가장 흔히 하는 실수는 관리, 검수 통합 에이전트를 별도로 구성하지 않는 것이다. 멀티에이전트 시스템의 실패 사례를 분석한 연구(MAST)는 실패 원인을 명세 문제 · 에이전트 간 불일치 · 검증 실패 세 범주로 나눈다. 셋 모두 모델의 실력보다 ‘어떻게 지시하고, 어떻게 연결하고, 누가 확인하느냐’의 문제다.

그래서 지시는 세 겹으로 나눈다. 모두가 읽는 프로젝트 헌장(AGENTS.md), 역할마다 하나씩 두는 역할 정의(agents/*.md), 그리고 작업마다 새로 쓰는 작업 지시서(briefs/)다. 역할 정의에서 가장 중요한 원칙은 만드는 에이전트, 관리하는 에이전트, 검수하는 에이전트를 나누는 것이다.

📄 관리 에이전트 정의 예시 — producer.md

---
name: producer
description: 기획서를 작업으로 쪼개 배정·추적. 새 마일스톤 시작 시 사용
tools: Read, Write, Agent
---
너는 프로듀서다. 직접 만들지 않는다.
1) 작업 지시서 6칸을 채워 배정한다
2) board.md에 상태(접수·진행·입력 필요·완료·실패)를 갱신한다
3) 같은 항목이 3회 반려되면 멈추고 디렉터에게 올린다

📄 검수 에이전트 정의 예시 — level-reviewer.md

---
name: level-reviewer
description: 레벨 JSON이 기획서와 맞는지 검수. 레벨 생성 직후 사용
tools: Read, Grep, Glob, Bash
---
너는 검수자다. 고치지 말고 판정하라.
검사 순서: 1) 스키마  2) 기획서 수치  3) 클리어 경로
출력: PASS/FAIL, 항목별 0~1점, 근거, 수정 요청 목록

관리 에이전트가 작업을 넘길 때 쓰는 것이 작업 지시서다. 목표 · 입력 · 출력 · 도구 · 경계 · 완료 여섯 칸이 모두 채워져야 넘긴다. 입력은 내용을 붙여 넣지 말고 파일 경로로, 출력은 다음 에이전트가 그대로 읽을 수 있는 스키마로 지정한다.

📋 복사해서 쓰는 작업 지시서 템플릿

# briefs/LV-03.md
목표    낙하 발판 기믹의 기·승·전·결 4개 룸 설계
입력    specs/mechanic_v2.json, docs/level_rules.md
출력    levels/lv03_1~4.json (level.schema.json 준수)
        + reports/lv03.md (룸별 의도 1줄, 가정에는 ★)
도구    레벨 툴 CLI, 읽기 전용 위키 메모
경계    메카닉 수치 수정 금지 · 아트 작업 제외
완료    스키마 검증 통과 + 4룸 모두 클리어 경로 존재
막히면  상태를 '입력 필요'로 바꾸고 질문을 남긴다

PART 05 · 1인 · 소규모 팀을 위한 4주 시작 순서

이제 어떤 팀이라도, 게임 개발을 처음 하는 초심자라고 하더라도 에이전트를 활용해 완성도 높은 게임을 개발할 수 있다. 처음부터 에이전트 다섯 개를 꾸릴 필요는 없다. 작업 에이전트 하나와 검수 에이전트 하나로 시작해도 충분하다.

• 1주 · 고르고 분해하기 — 검증된 레퍼런스 게임 하나를 고르고, 같은 구간을 반복 플레이하며 조작 수치 가설 5개를 세운다. 위키에서 레벨 구조를 모은다.
• 2주 · 튜닝 패널 — 핵심 메커니즘 프로토타입에 슬라이더 패널과 프리셋 A/B를 붙이고, 확정한 값을 기획서에 기록한다.
• 3주 · 데이터와 툴 — 레벨 스키마, 생성기, 검증기를 만들고 기믹 2개를 기승전결 4룸으로 짠다. 간단한 전용 에디터도 이때 시킨다.
• 4주 · 팀 구성 — AGENTS.md와 작업 지시서 템플릿을 확정하고 검수 에이전트를 붙인다. 플레이테스트 결과로 지시서를 고친다.

네트워크 · 저장 데이터 · 결제처럼 되돌리기 어려운 영역은 바이브 코딩이 가장 약한 곳이다. 이런 작업은 반드시 사람의 승인을 거치도록 묶어 두자.

📁 권장 프로젝트 폴더 구조 — 1층(헌장) · 2층(역할 정의) · 3층(작업 지시서)은 PART 04의 지시 3층 구조와 같다.

my-game/
├── AGENTS.md              # 1층: 프로젝트 헌장
├── .claude/agents/        # 2층: 역할 정의
│   ├── producer.md
│   └── level-reviewer.md
├── briefs/                # 3층: 작업 지시서
├── specs/                 # 기획서·메카닉 스펙
├── schemas/               # level.schema.json 등 연동 계약
├── levels/                # 레벨 데이터
├── presets/               # 튜닝 프리셋 A/B
├── reports/               # 에이전트 보고서·검수 결과
└── board.md               # 상태 보드·결정 로그

바로 써먹는 체크리스트

• ☐ 레퍼런스 게임의 ‘재미 포인트’를 한 문장으로 적었다
• ☐ 조작감을 이름 붙은 수치 5개 이상으로 분해했다
• ☐ 모든 조작 수치가 상수로 빠져 있고 슬라이더로 바꿀 수 있다
• ☐ 리소스를 레이어별로, 흐름(획득 · 보유 · 변환 · 소모)으로 정리했다
• ☐ 레벨이 코드가 아니라 데이터 파일로 존재한다
• ☐ 기믹마다 기승전결 4룸의 의도가 기록되어 있다
• ☐ 작업 지시서 6칸(목표 · 입력 · 출력 · 도구 · 경계 · 완료)이 다 채워져 있다
• ☐ 검수 에이전트는 쓰기 권한이 없다
• ☐ 반복 반려 시 사람에게 올리는 규칙이 있다
• ☐ 마지막 판정은 내가 직접 플레이해서 내린다

글(기획/감수): 정무식 교수(가천대학교 게임영상학과 부교수/공학박사)

정무식 교수는?

1994년 트리거소프트 창업 멤버로 출발하여 엔씨소프트 디렉터, 나스닥 상장사인 그라비티의 사외이사 및 루노소프트의 부사장을 역임한 대한민국 1세대 게임 개발자다. 2003년 한국 최초의 인디게임공모전을 기획, 개최한 이후로 국내 인디게임 육성에 오랜 관심과 지원을 이어왔으며, 현재 문화체육관광부 산하 게임물관리위원회 위원/이사, 성남시 4차산업특별위 콘텐츠/디지털/공간 분과장 등을 맡아 국내 게임 산업의 발전과 건전한 문화 정착에 힘쓰고 있다.

참고 자료

1. The New Stack — Vibe coding is passé. Karpathy has a new name for the future of software (2026.02)
2. AI Builder Club — Karpathy’s Agentic Engineering, Sequoia Ascent 2026
3. Cinevva — Vibe coding is the new game jam (2026.03)
4. Cinevva — Vibe Coding Games: What It Is and How to Start (2026)
5. StraySpark Studios — Vibe Coding Your Game in 2026: What Works, What Breaks
6. TrueFoundry — Spec-Driven Development for AI Agents
7. 80.lv — Celeste’s Movement Code Available on GitHub
8. 80.lv — Open-Source 2D Level Editor From the Creator of Dead Cells (LDtk)
9. DEV Community — Machinations Primer
10. 위키독스 — 8.2 경제 모델을 Machinations로
11. Celeste Wiki (Fandom) — Crossing
12. Game Developer — The Secret to Mario Level Design
13. Darius Kazemi — Spelunky Generator Lessons
14. UMBC — Data Driven Design (강의 노트)
15. Cemri 외 — Why Do Multi-Agent LLM Systems Fail? (arXiv 2503.13657)
16. Anthropic — How we built our multi-agent research system
17. Claude Code 문서 — Subagents
18. What Is the A2A Protocol? Agent Cards and Tasks Explained