PROCESS PORTFOLIO · 2026

한 사람이 9-인 게임 스튜디오를 AI 에이전트로 운영한 실험

이 포트폴리오는 "게임을 만든 기록"이 아니라 "게임 만드는 과정을 어떻게 설계했나"의 기록입니다. Game Director · Designer · Level Designer · UX · Artist · Audio · Programmer · QA 9개 역할을 Claude 멀티-에이전트로 분리·조율하면서, 의사결정의 추적성과 산출물의 일관성을 끝까지 유지하는 방법을 찾는 실험.

결과물은 게임 3개와 약 70개의 디스크 산출물(브리프 · 슬라이스 · 검증 보고서 · 아트 바이블 · 캐릭터 PIL 스크립트 등). 의사결정은 모두 변경 로그에 남아 있고, QA가 빌드 이전 단계에서 cross-doc 일관성을 검증합니다.

WHY

이 프로젝트에서 중요하게 생각한 5가지

"AI로 게임 만들기"는 표면이고, 실제로는 "한 명의 사용자가 다인 스튜디오를 조율할 때 의사결정을 어떻게 잃지 않을까"가 핵심 질문이었습니다. 각 카드는 그 질문에 답하는 구조적 선택을 하나씩 보여줍니다.

01
의사결정 추적성
모든 결정은 디스크에 기록됩니다. 브리프 → 슬라이스 → 검증 보고서 → rev2/rev3 change log. "왜 stamina 시스템을 post-MVP로 미뤘는가" 같은 질문에 항상 한 라인으로 답할 수 있어야 합니다.
02
단일 책임 원칙 (SRP)
각 에이전트는 자기 도메인만 봅니다. Artist는 디자인 슬라이스의 verb 리스트만 받지, 밸런스 숫자나 UX 그래프는 안 봅니다. 컨텍스트가 작을수록 의사결정이 빠르고 명확.
03
모델 티어링
GD는 Opus, 디자인·아트·코드는 Sonnet, QA·번역은 Haiku. 작업 난이도에 따라 모델을 차등 배치해서 풀-컨텍스트 Opus 대비 약 5~7배의 비용 효율을 달성합니다.
04
슬라이스 기반 협업
250페이지 GDD 대신 도메인별 600-word 슬라이스. DES → LVL/UX/ART/AUD 병렬 출판, PRG는 슬라이스만 받아 단일 파일 HTML로 통합. 핸드오프가 한 페이지로 끝납니다.
05
내장 검증 루프
QA 페르소나가 빌드 이전에도 cross-doc 일관성을 검증합니다. medieval-tavern 검증 1차에서 B.1 bar_counter 충돌, B.2 첫 손님 anti-climax 등 P1 4건을 발견·정정.
HOW IT WORKS

실제 프로젝트는 이렇게 흘러갑니다

6 phase 파이프라인 위에서, 사용자의 "한 줄 요청"이 어떻게 ~70개 디스크 산출물과 플레이 가능한 빌드로 펼쳐지는지. medieval-tavern 케이스로 풀어쓴 회고입니다.

PHASE 1Concept (GD)
PHASE 2Slices · DES → LVL/UX/ART/AUD
PHASE 3Prototype (PRG)
PHASE 4Validation (QA)
PHASE 5Iteration
PHASE 6Ship

Case: Medieval Tavern

림월드 + 스타듀 식 주점 운영 시뮬레이션 · 4 라운드의 회고

D 0 시작은 SPUM(SOONSOON Pixel Unit Maker) 픽셀 유닛 이미지 한 장. 사용자가 "림월드 형식, 스타듀 조작감, 중세 주점 운영, 10×10 시작, 200×200 월드, 8방향 이동"이라는 9개 요구사항을 한 줄씩 적어 보냈습니다.

D 1 GD는 먼저 팀 구성부터 손봤습니다. 시뮬레이션은 일반 Level Designer로는 부족하다고 판단, "룸 그래머·worldgen·storyteller 이벤트 스케줄"에 특화된 sim-only LVL 스킬을 새로 작성. 기존 9-인 팀이 10-인이 됐고, game-team 로스터를 v1.3으로 올렸습니다.

D 2 art_bible v1.0(32×32 캐릭터)을 작성하고 Old Garrick 샘플을 그렸습니다. 사용자는 "디테일이 부족해 보인다, 128로 키워봐"라고 피드백. v2.0(128×128)로 다시 그렸더니 이번엔 "200×200 월드에 캐릭터 너무 큼". v3.0(32×48 Stardew 스케일)로 수렴해서야 정착. 3 버전의 시행착오가 art_bible.md change log에 그대로 남아 있습니다.

D 3 사용자가 4가지 결정을 잡았습니다: 사냥은 약식 턴/오토배틀, 시간 시스템은 post-MVP, 폐허→복구→OPEN 컨셉, 자유 방향 이동(8방향 → 연속). 이 결정들을 받아 브리프(rev2)를 업데이트하고 4개 슬라이스를 출판: design / level / ux / art assets.

D 4 QA가 cross-doc 검증을 돌렸고 P1 4건 발견: (B.1) LVL과 DES의 bar_counter 필수성 충돌, (B.2) Brief("OPEN 직후 즉시 손님")와 DES("cadence 20 verb 후") 타이밍 불일치, (C.1·C.2) 미결 의사결정 2건. 사용자가 "1·2·3·5 정정, 4는 post-MVP" 결정을 내려 stamina를 제거하고 HUD를 자원 quick view로 대체했습니다.

D 5 ART가 PIL로 45개 픽셀 스프라이트를 절차 생성. PRG가 단일 파일 HTML로 빌드. 그 다음 사용자 피드백 라운드 3회를 거치며 인터랙트 반경(1.6타일), 야외 자원 10배 증가, 빌드 모드 슬림 패널, 멀티-타일 풋프린트 overlap 체크가 차례로 들어갔습니다. "손님 한 명만 옴"에서는 하루 시스템(quota 5명 → DAY N COMPLETE 전환)이 추가됐고, "벽이 어긋남"에서는 벽 sprite 9종을 풀-스톤으로 재디자인.

현재 상태: MVP 가동 중. 풀-사이클(폐허 인식 → 채집 → 복구 → OPEN → 손님 응대 → 다음 날)이 한 번에 동작합니다. 다음 라운드는 AUD 슬라이스 출판이거나 200×200 풀 월드 확장.

RAW DATA

피드백 라운드
15+
art_bible 버전
v1 → v2 → v3
슬라이스 산출물
4
검증 P1 정정
4건
WAVE 1 자산
45 PNG
총 LOC (index.html)
1648
총 디스크 산출물
~70 files

CASE TIMELINE

D 0
9개 요구사항 수신
D 1
LVL 스킬 신설
D 2
art_bible v1→v3
D 3
4 슬라이스 출판
D 4
검증 + P1 정정
D 5
빌드 + 피드백 라운드
TEAM

9 AI 에이전트가 각자 한 도메인을 책임집니다

각 카드는 그 역할의 페르소나 정의 파일(SKILL.md)을 모달로 보여줍니다. 에이전트가 어떤 원칙·출력 포맷·token discipline·common mistakes를 갖는지 그대로 확인 가능.

OPUS
Game Director
게임 디렉터 · GD
비전 수립, go/no-go 의사결정, 에이전트 조율. raw 산출물은 안 봄 — 슬라이스 요약만 받아 결정. 전체 흐름을 통제하는 단 하나의 Opus.
SONNET
Game Designer
게임 디자이너 · DES
비전을 룰로 번역. verbs · states · balance numbers · edge cases를 600 단어 슬라이스로 명세. "재미있게 만들어줘"는 안 통하고, 모든 결정은 숫자로.
SONNET
Level Designer
레벨 디자이너 · LVL · ★ 신설
RimWorld-class 시뮬레이션 전용으로 특화. 룸 그래머·worldgen·storyteller 이벤트 스케줄러·페이싱 곡선. medieval-tavern을 위해 새로 추가된 직군.
SONNET
UX Designer
UX 디자이너
screen graph(노드=화면, 엣지=입력) + 키 바인딩 표 + HUD 좌표 + 모달 레이아웃 명세. dead-end audit 통과가 출판 조건.
SONNET
Artist
아티스트 · ART
art_bible 팔레트로 PIL 절차 합성. 캐릭터당 ≤8색, 2-tone 셰이딩, 32×48 Stardew 스케일. mood board가 아니라 PNG 파일을 출판.
SONNET
Audio Designer
오디오 디자이너 · AUD
WebAudio 모듈로 SFX를 코드로 출판. wav 파일 안 씀. 사운드 = 피드백, ≤ 6 SFX/프로토타입, mute는 sacred(첫 로드 시 master gain 0.4).
SONNET
Programmer
프로그래머 · PRG
단일 파일 HTML + Canvas + vanilla JS가 디폴트. 200 라인이 돌아가면 1000 라인 아키텍처보다 낫다. npm 빌드 스텝 없음, 더블클릭하면 60초 안에 플레이.
HAIKU
QA Tester
QA · 검증
빠르고 싸고 무자비. severity-ranked 버그 리포트. 빌드 이전 단계에서도 문서 cross-check 가능 (medieval-tavern에서 P1 4건 발견 사례).
META
Game Team Orchestrator
팀 오케스트레이터
위 8개를 어떤 순서·어떤 컨텍스트 슬라이스로 호출할지를 정의하는 메타 스킬. "게임 만들어줘"가 떨어졌을 때 이 스킬이 진입점이 됩니다.
GAMES

결과물 · 3개의 플레이 가능한 빌드

이 워크플로우로 만든 게임 3개. 각각 단일 HTML 파일로 빌드돼서 더블클릭하면 즉시 플레이. [▶ PLAY]는 모달 iframe, [📋 BRIEF]는 기획서 모달로 열립니다.

RUINED TAVERN · DAY 1 · RESTORING 38%

Medieval Tavern

MVP · 진행 중

폐허가 된 중세 주점을 복구하고 운영하는 RimWorld + Stardew Valley식 시뮬레이션. 플레이어가 직접 주인장 Old Garrick을 조작해 야생에서 자원을 채집하고, 무너진 벽을 수리하고, 가구를 제작·배치하면서 주점을 OPEN 상태로 만들어 손님을 받는다.

SIMULATION PIXEL ART FREE-DIRECTION WASD CRAFTING DAY SYSTEM ~1650 LOC
▸ 왜 만들었나 사용자의 "림월드+스타듀 주점 운영" 한 줄 요청에서 시작. 시뮬레이션·시간·자유 방향·풋프린트 충돌 등 가장 복잡한 시스템 디자인 케이스로 채택.
▸ 핵심 메커닉 10 verb 시스템(이동·채집·벌목·사냥·수리·청소·제작·배치·서빙·인터랙트), 4 state machine(tavern: RUINED→RESTORING→OPEN_PENDING→OPEN), 풋프린트 기반 충돌, 액션-기반 cadence 손님 spawn, daily quota 5명 → DAY 전환.
▸ 구현 도전 15+ 라운드 사용자 피드백 반영: 인터랙트 1.6타일 반경 완화 · 야외 자원 10배 증가 · 벽 sprite 9종 풀-스톤 재디자인 · 멀티-타일 풋프린트 overlap 체크 · 하루 시스템 + 자원 리스폰. 매번 art_bible / brief / 슬라이스가 같이 갱신됨.
▸ 다음 단계 AUD 슬라이스(WebAudio SFX 통합), 200×200 풀 월드 확장(현재 60×40 축소), 마을 NPC 활성화(상인 거래), 손님 컬러 시드 3 variant 추가, 사냥 AUTO_BATTLE UI 구현.
TETRIS · v14 SHIPPED

Tetris

SHIPPED v14

팀 워크플로우의 첫 번째 본격 검증 빌드. 1989 Game Boy 클래식을 7-bag · SRS · ghost piece · DAS/ARR · T-spin 인식까지 갖춘 modern 구현으로 완성. 14번의 release_note가 출판되며 진화한 게임 — 슬라이스 기반 협업이 iteration에 얼마나 견고한지 보여주는 케이스.

ARCADE FALLING-BLOCK KEYBOARD SCORE 14 ITERATIONS ~2700 LOC
▸ 왜 만들었나 "이 9-인 에이전트 팀이 진짜 게임을 만들 수 있나"의 첫 실사 테스트. 규칙이 모두 알려진 클래식이기 때문에, 에이전트가 spec을 정확히 구현했는지 vs. 상상으로 채웠는지 검증하기 쉬움.
▸ 핵심 메커닉 7-bag random · SRS rotation system · soft/hard drop · hold piece · line clear scoring(single/double/triple/tetris/T-spin) · level-based gravity · lock delay · DAS(Delayed Auto-Shift) + ARR(Auto Repeat Rate).
▸ 구현 도전 v1.0 출하 후 v12에서 UX Designer 신설(타이틀/랭킹/커스터마이즈 화면 확장 대응), v13에서 사용자 요청 사양 추가, v14에서 audio 통합 완료. 누적 14개 release_note가 "iteration이 실제로 어떻게 일어나는가"의 산증인.
▸ 다음 단계 현재 출하 상태. 추가 작업 예정 없음. 멀티플레이어·랭킹 서버 등은 명시적 non-goal로 분류돼 별도 프로젝트 spawn 대상.
TIC-TAC-TOE · MINIMUM VIABLE TEAM

Tic-Tac-Toe

SHIPPED v1.0

팀 워크플로우의 0번째 검증. "실제로 9-인 풀 팀이 필요한가, 더 작은 팀으로 충분한가"를 확인하기 위해 minimal 5-인 코어(GD + DES + PRG + ART + QA)만 호출. 1일 만에 완성 → 풀 워크플로우가 "더 큰 게임도 핸들 가능"하다는 confidence 빌더가 됨.

CLASSIC 2-PLAYER MOUSE MINIMAL TEAM ~200 LOC
▸ 왜 만들었나 사용자가 "9-인 팀이 너무 무겁다고 느끼면 어쩌지?"라는 우려를 표명. minimum viable team(5인)이 진짜 minimum인지 검증하기 위해 가장 단순한 룰 게임으로 빠른 사이클.
▸ 핵심 메커닉 3×3 그리드, 2-player turn-based, 8 way win-line detection, tie 처리, 게임 재시작. 더할 게 없는 minimum.
▸ 구현 도전 없음 — 의도된 결과. "문제가 안 생기는 게 핵심"이었음. 5-인 팀 워크플로우가 9-인보다 가벼우면서도 빠짐없이 동작함을 확인.
▸ 다음 단계 출하 완료. AI 상대(minimax) 추가는 post-MVP 옵션이지만 우선순위 낮음. 현재는 "팀 워크플로우 baseline"으로서 reference 역할.
ARTIFACTS

디스크에 남은 모든 산출물

이 프로젝트의 가장 큰 가치는 게임이 아니라 모든 의사결정이 추적 가능한 기록으로 남았다는 점. 각 항목을 클릭하면 모달로 내용 전체 확인 가능합니다.

· 프로젝트 메타 ·

📐
게임제작팀_에이전트_설계서.md
9-에이전트 팀 구성·티어링·토큰 최적화 전략
🎨
art_bible.md (v3.0)
팔레트·비율·셰이딩 규칙·v1→v2→v3 진화 기록

· Medieval Tavern · Phase 1+2 산출물 ·

📋
01_brief.md
필러 3 · MVP 8항목 · non-goals · rev3 change log
🔧
02_design_slice.yaml — DES
10 verbs · state machines · balance · edge cases
🗺️
02b_level_slice.yaml — LVL
200×200 worldgen · 폐허 시작 상태 · 룸 그래머
🖱️
02c_ux_slice.yaml — UX
8 screens · 23 key bindings · 3 modal layouts
🖼️
02d_art_assets_required.md
245 스프라이트 인테이크 · P0/P1/P2 우선순위 · WAVE 계획
03_validation_report.md — QA
18/18 요구사항 커버 · 충돌 2건·갭 5건·리스크 10건

· Tetris · 14 iteration 누적 ·

📋
01_brief.md (v1.0)
최초 출하 버전 브리프
📋
v12_brief.md
UX Designer 신설 + 멀티 스크린 확장
📋
v14_brief_and_specs.md
최신 출하 버전 사양
📦
05_release_note.md (v1.0)
최초 출하 노트
📦
v14_release_note.md
최신 출하 노트
🔧
02_design_slice.yaml
SRS · 7-bag · scoring · DAS/ARR