Open Source · MIT · v1.2.0

Claude Code 세션 하나를
게임 스튜디오로.

혼자 AI와 게임을 만들면 빠르지만, 아무도 "그게 이 게임의 비전에 맞아?"라고 묻지 않습니다. Claude Code Game Studios는 AI 세션에 실제 스튜디오의 직급·결재선·품질 게이트를 입혀, 기획부터 출시까지 함께 일하는 49명의 전문 에이전트 팀을 만들어 줍니다.

조직도 둘러보기 상세 보고서 읽기 →

github.com/Donchitos/Claude-Code-Game-Studios · ★ 27.2k · fork 3.9k · 2026-10-23 기준

49전문 에이전트

74슬래시 커맨드 스킬

15자동 검수 훅

14경로별 코딩 규칙

62문서 템플릿

01 · Why

채팅창 하나에는 구조가 없다

AI 한 명에게 게임 개발을 통째로 맡기면, 매직 넘버를 코드에 박아 넣어도, 설계 문서를 건너뛰어도, QA를 생략해도 막는 사람이 없습니다. 이 프로젝트의 출발점은 단순합니다. 사람 스튜디오가 수십 년 동안 다듬어 온 역할 분담과 검수 절차를 AI 세션에 그대로 옮기자.

BEFORE

만능 사원 한 명

무엇이든 해 주지만, 누구에게도 보고하지 않습니다.

기획·코드·아트 판단이 한 머릿속에서 뒤섞임
"이게 맞나?"를 묻는 검토자가 없음
대화가 길어지면 앞의 결정을 잊음
품질 기준이 그날 컨디션에 따라 달라짐

AFTER

결재선이 있는 스튜디오

각자 자기 영역만 책임지고, 충돌은 위로 올라갑니다.

디렉터 → 리드 → 스페셜리스트로 위임
모든 산출물에 리뷰와 게이트가 걸림
결정은 파일(active.md, GDD, ADR)에 남음
커밋·푸시·에셋 변경마다 훅이 자동 검사

비유하자면 — 천재 프리랜서 한 명을 고용하는 대신, 그 사람을 사내 조직도와 결재 시스템이 갖춰진 회사에 입사시키는 것입니다. 능력은 같아도 "누구에게 물어야 하는지", "무엇을 남겨야 하는지"가 정해지면 결과물의 일관성이 달라집니다. 그리고 그 회사의 사장은 여전히 당신입니다.

02 · Studio Hierarchy

49명의 조직도

에이전트는 실제 스튜디오처럼 세 계층으로 나뉩니다. 이름을 누르면 담당 영역과 보고선을 볼 수 있습니다. 엔진 스페셜리스트는 Godot·Unity·Unreal 세트 중 프로젝트에 맞는 하나를 씁니다.

Opus 지정 (디렉터 3)Sonnet 지정 (16)세션 모델 상속 (30)

Tier 1 · 디렉터비전과 최종 판단

Tier 2 · 부서 리드각 부서의 기준과 리뷰

Tier 3 · 스페셜리스트실제 손을 움직이는 실무자

엔진 스페셜리스트엔진별 5명 × 3세트

모델 배치의 의미 — 디렉터 셋만 Opus를 요청하고, 리드 프로그래머와 반복 작업이 많은 15명은 Sonnet, 나머지 30명은 지금 쓰는 세션 모델을 그대로 물려받습니다. 원작자는 "계층은 직급이지 요금제가 아니다"라고 못 박습니다. 비싼 모델은 판단이 무거운 자리에만 둡니다.

03 · How It Works

자율 주행이 아니라, 협업 운전

이 시스템은 오토파일럿이 아닙니다. 모든 에이전트는 같은 다섯 박자로 일하고, 파일을 쓰기 전에 반드시 "이 경로에 써도 될까요?"라고 묻습니다.

질문Question

해결책을 내놓기 전에 맥락부터 묻는다.

선택지Options

2~4개 안을 장단점과 함께 제시한다.

결정Decision

결정은 언제나 사용자가 내린다.

초안Draft

확정 전에 초안이나 요약을 먼저 보여 준다.

승인Approval

승인 없이는 아무것도 쓰지 않는다.

에이전트끼리의 다섯 가지 규칙

.claude/docs/coordination-rules.md

01
수직 위임
디렉터 → 리드 → 스페셜리스트. 복잡한 결정은 계층을 건너뛰지 않는다.
02
수평 협의
같은 계층끼리 상의는 하되, 남의 영역을 확정하지 않는다.
03
상위 에스컬레이션
의견이 갈리면 공통 상사에게. 디자인은 creative-director, 기술은 technical-director.
04
변경 전파는 producer
여러 부서에 걸친 변경은 프로듀서가 조율한다.
05
영역 밖 수정 금지
명시적 위임 없이 자기 디렉터리 밖의 파일을 고치지 않는다.

얼마나 자주 물어볼지 고르기

project.yaml → modes.automation

collaborative

기본값. 단계가 바뀔 때마다 사용자 승인을 받는다.

guided

막히는(BLOCKED) 단계가 아니면 자동으로 다음 단계로 간다.

autonomous

끝까지 달리되, 모든 판단을 결정 로그에 기록한다. 단 "항상 물어볼 것"으로 지정한 범주는 예외.

세션의 기억은 대화가 아니라 파일 — production/session-state/active.md가 체크포인트입니다. 컨텍스트가 압축되거나 세션이 끊겨도 이 파일부터 읽고 이어 갑니다.

04 · Pipeline

아이디어에서 출시까지, 7단계

/start는 "지금 어디쯤 있나요?"부터 묻습니다. 아이디어가 전혀 없는지, 컨셉만 있는지, 이미 만든 게 있는지에 따라 아래 파이프라인의 다른 지점으로 안내합니다. 단계 정의는 .claude/docs/workflow-catalog.yaml에 있습니다.

Concept컨셉

아이디어를 게임 컨셉 문서로. 아트 바이블과 시스템 지도까지.

/brainstorm/art-bible/map-systems

Systems Design시스템 설계

시스템마다 GDD를 쓰고, 개별·전체 교차 리뷰로 모순을 잡는다.

/design-system/review-all-gdds/consistency-check

Technical Setup기술 기반

아키텍처 문서, ADR, 접근성 요구사항, 테스트 프레임워크.

/create-architecture/architecture-decision/test-setup

Pre-Production프리 프로덕션

UX·에셋 명세, 코어 메커닉 프로토타입, 에픽과 스토리로 쪼개기.

/ux-design/prototype/create-epics/create-stories

Production프로덕션

스프린트 단위로 스토리를 골라 구현하고 닫는다.

/sprint-plan/dev-story/story-done

Polish폴리싱

성능, 밸런스, 플레이테스트, 버그 수정.

/perf-profile/balance-check/playtest-report

Release출시

인증, 출시 체크리스트, 패치 노트, 데이원 패치.

/release-checklist/launch-checklist/patch-notes

THE DIAL

하나의 다이얼, `modes.rigor`

프로세스를 얼마나 무겁게 할지는 다이얼 하나로 정합니다. 이 다이얼이 GDD 필수 섹션, 문서 밀도, QA 증거 수준, 스토리 크기, 디렉터 리뷰 깊이, 팀 규모 6개를 한꺼번에 움직입니다.

rigor	성격	GDD
`minimal`	기본값. 게임잼 속도, 혼자 리뷰	불필요
`standard`	균형 잡힌 문서·QA, 가벼운 리뷰	5섹션
`full`	모든 스토리에 증거, 디렉터 전원 리뷰	8섹션

전투 시스템만 full로 묶는 system_overrides, 개인별 리뷰 강도를 바꾸는 project.local.yaml도 있습니다.

# minimal 경로 — 가장 짧은 길
/start → /setup-engine → /brainstorm
  → /create-stories → /dev-story ↔ /story-done

05 · Skills

74개 슬래시 커맨드

Claude Code에서 /를 치면 나오는 스킬들입니다. 각 스킬은 "어떤 에이전트를 어떤 순서로 부를지"까지 적힌 절차서입니다. 한글 키워드(예: 밸런스, 패치, 현지화)로도 찾을 수 있습니다.

전체 74개

온보딩 · 길찾기

현재 단계 진단, 엔진 설정, 기존 프로젝트 편입

/start/help/project-stage-detect/setup-engine/adopt/settings

게임 디자인

아이디어 발산부터 시스템별 GDD, 설계 변경 전파까지

/brainstorm/map-systems/design-system/quick-design/review-all-gdds/propagate-design-change

아트 · 에셋

아트 바이블, 에셋 명세, 에셋 감사

/art-bible/asset-spec/asset-audit

UX · 인터페이스

핵심 화면 UX 명세와 리뷰

/ux-design/ux-review

아키텍처

아키텍처 문서, ADR, 컨트롤 매니페스트

/create-architecture/architecture-decision/architecture-review/create-control-manifest

스토리 · 스프린트

에픽·스토리 분해, 구현, 완료 판정, 추정

/create-epics/create-stories/dev-story/sprint-plan/sprint-status/story-readiness/story-done/estimate

리뷰 · 분석

설계·코드 리뷰, 밸런스, 범위, 성능, 기술 부채, 보안

/design-review/code-review/balance-check/content-audit/scope-check/perf-profile/tech-debt/gate-check/consistency-check/security-audit

QA · 테스트

테스트 계획, 스모크·소크·회귀, 증거 검토, 스킬 자체 테스트

/qa-plan/smoke-check/soak-test/regression-suite/test-setup/test-helpers/test-evidence-review/test-flakiness/skill-test/skill-improve

프로덕션

마일스톤, 회고, 버그 보고·분류, 역문서화, 플레이테스트

/milestone-review/retrospective/bug-report/bug-triage/reverse-document/playtest-report

릴리스

출시 체크리스트, 체인지로그, 패치 노트, 핫픽스

/release-checklist/launch-checklist/changelog/patch-notes/hotfix/day-one-patch

크리에이티브 · 콘텐츠

프로토타입, 버티컬 슬라이스, 신규 인원 온보딩, 현지화

/prototype/vertical-slice/onboard/localize

팀 오케스트레이션

한 기능에 여러 에이전트를 묶어 설계→구현→검증까지 돌린다

/team-combat/team-narrative/team-ui/team-release/team-polish/team-audio/team-level/team-live-ops/team-qa

예시 — `/team-combat "패링 시스템"`

팀 스킬은 team.size에 따라 실제로 부를 에이전트를 먼저 선언합니다. 몰래 축소하지 않습니다.

team.size	실제 투입
`individual`	gameplay-programmer가 혼자 진행, AI 작업이 있으면 ai-programmer 호출
`small`	game-designer · gameplay · ai · technical-artist · sound · qa-tester 전원
`studio`	위 + 엔진 하위 스페셜리스트 + "부서지는 방법을 찾아라" 적대적 QA 패스

시작은 세 줄

Git · Claude Code · Python 3 · Bash(Windows는 Git for Windows)가 필요합니다. jq는 권장.

# 템플릿을 내 게임 폴더로 복제
git clone https://github.com/Donchitos/Claude-Code-Game-Studios.git my-game
cd my-game
# 반드시 CLAUDE.md가 있는 루트에서 실행
claude
# 세션 안에서
/start

하위 폴더(예: src/)에서 띄우면 훅·차단 규칙·승인 모드가 로드되지 않습니다.

06 · Does it produce games, or documents?

"문서만 잔뜩 만드는 거 아냐?"에 대한 실험

원작자는 같은 기획서 하나로 rigor 수준을 달리해 게임 네 개를 만들고, 첫 게임 코드가 나오기 전까지 쓴 문서 수를 셌습니다. 모두 동작하고 테스트를 통과하는 게임이 나왔습니다.

DOCS BEFORE FIRST LINE OF CODE

minimal1개 (한 장짜리 기획서)

standard30개

TIME BEFORE FIRST LINE OF CODE

minimal0분

standard58분

블라인드 리뷰어 2명과 사람 플레이테스트 모두 standard 빌드를 꼴찌로 매겼습니다. 추가 문서 29개가 산 것은 추적 가능성이지, 더 좋은 게임이 아니었습니다.

그래서 기본값은 minimal입니다.
프로세스는 규모가 커질 때 올리는 것이지, 처음부터 입는 갑옷이 아닙니다.

대신 "실행해서 눈으로 본다"는 양보하지 않는다

테스트 통과는 메뉴가 화면 밖에 그려졌는지 알려 주지 않습니다. 그래서 플레이어가 보는 것을 바꾼 스토리는 게임을 실제로 띄우고, 확인하고, 스크린샷을 production/qa/evidence/에 남겨야 닫힙니다. minimal에서도 예외가 없습니다. v1.2.0부터는 증거 옆에 stamp.txt를 남겨, 그 뒤 코드가 바뀌면 "다시 찍으세요"라고 알려 줍니다.

07 · Harness Engineering의 관점에서

네 기둥으로 해부하기

에이전트 시스템을 설계하는 입장에서 보면, 이 레포는 하네스 엔지니어링의 교과서적 사례입니다. 모델을 바꾸지 않고 모델을 둘러싼 환경(규약·역할·절차·게이트)을 설계해서 결과의 편차를 줄입니다.

PILLAR 1규약CLAUDE.md · 14 rules

모든 세션이 처음 읽는 헌법. 협업 프로토콜과 조정 규칙을 담고, src/gameplay/**를 고칠 땐 "매직 넘버 금지·delta time 사용" 같은 경로별 규칙이 자동으로 붙습니다.

PILLAR 2역할49 agents

에이전트마다 쓸 수 있는 도구, 모델, 최대 턴, 기억 범위가 frontmatter에 정의됩니다. creative-director는 Bash를 아예 쓸 수 없습니다 — 판단하는 자리는 손을 대지 않습니다.

PILLAR 3절차74 skills · 62 templates

"누구를, 어떤 순서로, 어떤 결정 지점에서" 부를지 적힌 실행 가능한 SOP. 독립적인 하위 작업은 병렬로 띄우고, 막히면 조용히 건너뛰지 않고 부분 보고합니다.

PILLAR 4게이트15 hooks · studio-tests

규칙을 문서에만 적으면 무너집니다. 커밋 전 하드코딩 검사, 40KB 넘는 설계 문서 통째 읽기 차단, 서브에이전트가 약속한 파일을 안 썼으면 경고 — 코드로 강제합니다.

자동으로 도는 안전장치 (일부)

훅	언제	무엇을
`validate-commit.sh`	git commit 직전	하드코딩 값, TODO 형식, JSON 유효성, 설계 문서 섹션 검사
`validate-push.sh`	push · tag · 스토어 업로드 직전	보호 브랜치 푸시, `butler push`·`steamcmd` 배포에 경고
`validate-read.sh`	파일 읽기 직전	40KB 넘는 설계 문서를 통째로 읽으려 하면 거절하고 목차를 돌려줌 → 필요한 섹션만 읽게 유도
`validate-assets.sh`	에셋 쓰기 직후	데이터 JSON 유효성, 에셋 네이밍 규칙
`detect-gaps.sh`	세션 시작	새 프로젝트면 `/start` 제안, 코드는 있는데 설계 문서가 없으면 알림
`log-agent.sh` / `-stop`	서브에이전트 시작·종료	누가 언제 호출됐는지 감사 로그
`validate-agent-artifact.sh`	서브에이전트 종료	지시받은 파일을 쓰지 않고 끝났으면 경고

settings.json의 권한 규칙은 force push, rm -rf, .env 읽기를 Bash·PowerShell 양쪽에서 차단합니다. 그리고 studio-tests/는 게임이 아니라 스킬과 에이전트 자체를 테스트합니다 — 하네스를 고쳤을 때 회귀를 잡는 장치입니다.

08 · Playbook for Thunder Games

썬더게임즈에서 이렇게 써 볼 수 있습니다

Mobile RPG · Casual

"49명을 다 쓰자"가 아니라,
모바일 라이브 서비스의 병목에 맞는 팀만 꺼내 쓰자.

이 템플릿은 원래 인디 개발자 한 명이 PC·콘솔 게임을 만드는 상황을 가정합니다. 모바일 RPG와 캐주얼 게임을 운영하는 스튜디오라면, 신작 0→1보다 라이브 운영의 반복 업무, 확률·경제 데이터 검증, 레거시 코드 이해, 빠른 신작 검증에서 효과가 먼저 납니다.

썬더게임즈 정보는 공개 기업 정보(부산 해운대 센텀, 2015년 설립, 모바일 RPG·캐주얼 개발)를 바탕으로 한 가정입니다. 실제 엔진·조직·파이프라인에 맞춰 조정이 필요합니다.

Idea 1 · Compliance Gate

확률형 아이템 공시 게이트

2024년 3월부터 확률형 아이템 정보 공개가 법적 의무가 됐습니다. 가챠 테이블 JSON이 바뀔 때마다 확률 합계 100%, 공시 문구 필드, 이전 버전 대비 변경 내역을 커밋 단계에서 자동 검사하는 훅과 경로 규칙을 추가합니다. 규칙을 사람 기억이 아니라 코드에 둡니다.

먼저 고칠 곳: 기본 live-ops-designer는 "유료 랜덤 박스 금지"를 윤리 원칙으로 갖고 있어, 가챠가 있는 RPG에선 매번 경고를 올립니다. 이 원칙을 국내 법규 기준의 "확률 공개·과금 한도·미성년자 보호" 정책으로 바꿔 써야 합니다.

rules/ gacha-data.md (assets/data/gacha/**)
hooks/ validate-commit.sh에 확률 합계·필드 검사 추가
agent economy-designer → /balance-check

→ 공시 누락·확률 오기 사고를 배포 전에 차단

단계별 가이드 보기 →

Idea 2 · Live-Ops Factory

시즌 이벤트 기획 공장

매달 반복되는 이벤트 기획을 팀 스킬로 묶습니다. 이벤트 콘셉트 → 보상표·재화 유입/소모 분석 → 이벤트 대사·공지문 → 패치 노트까지 한 번에 초안을 만들고, 기획자는 결정과 수정에만 시간을 씁니다.

/team-live-ops "추석 한정 이벤트"
live-ops-designer · economy-designer · analytics-engineer
narrative-director · writer · community-manager
→ /patch-notes → /changelog

→ 이벤트 1건당 문서 준비 시간 단축, 재화 인플레이션 사전 점검

단계별 가이드 보기 →

Idea 3 · 2-Week Kill or Go

캐주얼 신작 2주 검증 스프린트

캐주얼 장르는 "빨리 만들어 보고 빨리 버리는" 게 경쟁력입니다. rigor: minimal로 한 장짜리 기획서에서 바로 프로토타입을 만들고, 시제품 판정(PROCEED · PIVOT · KILL)으로 2주 안에 결론을 냅니다.

/brainstorm (한 장 기획서) → /prototype --path html
→ /playtest-report → 판정 PROCEED / PIVOT / KILL

→ 아이디어 검증 회전 수 증가, 기획 회의를 "플레이해 본 결과"로

단계별 가이드 보기 →

Idea 4 · Legacy to Docs

운영 중인 RPG 역문서화 & 온보딩

오래 운영한 게임일수록 설계 의도가 코드에만 남아 있습니다. 기존 프로젝트를 편입해 코드에서 GDD·ADR을 거꾸로 복원하고, 신규 입사자 온보딩 자료를 자동으로 만듭니다.

/adopt → /project-stage-detect
→ /reverse-document → /onboard

→ 담당자 이탈 리스크 완화, 신입 적응 기간 단축

단계별 가이드 보기 →

Idea 5 · Mobile Budget

저사양 기기 성능 예산 & 출시 QA

project.yaml에 기기 등급별 프레임·메모리 예산을 적고, 업데이트마다 프로파일링·스모크·회귀를 돌립니다. 화면이 바뀐 스토리는 실제 실행 스크린샷이 있어야 닫히는 규칙이 모바일 UI 깨짐을 막아 줍니다.

engine Unity 세트 (unity-addressables · unity-ui)
/perf-profile → /smoke-check → /regression-suite

→ 패치 후 크래시·UI 깨짐 리포트 감소

단계별 가이드 보기 →

Idea 6 · Global Launch

글로벌 출시 현지화 파이프라인

문자열 추출 → 로캘별 길이·폰트 이슈 점검 → 캐릭터 말투 일관성 검수 → 출시 체크리스트. 현지화 동결(freeze) 이후 문자열 변경은 쓰기 훅이 경고합니다.

/localize (localization-lead · writer)
→ /launch-checklist → /day-one-patch

→ 다국어 출시 시 누락 문자열·텍스트 넘침 사전 발견

단계별 가이드 보기 →

STEP 1 · 2주

파일럿

사이드 프로젝트 1개에 rigor: minimal로 적용
Idea 3(2주 검증)부터 — 리스크가 가장 낮음
에이전트는 10명 안팎만 남기고 나머지는 삭제

STEP 2 · 1~2개월

라이브 운영에 접목

Idea 1 확률 게이트 훅 개발 → 운영 레포에 도입
Idea 2 이벤트 공장으로 한 시즌 운영
Idea 4로 핵심 시스템 3개 역문서화

STEP 3 · 분기

썬더게임즈 전용 하네스

사내 규칙·장르 지식을 에이전트에 이식(예: gacha-compliance, mobile-perf)
studio-tests/로 사내 스킬 회귀 테스트
사내 교육 과정으로 패키징

도입 전에 알아 둘 것 — ① 아트·사운드 에셋을 직접 만들지 않습니다(명세서를 만듭니다). ② 디렉터 3명은 Opus를 요청하므로 리뷰가 잦을수록 비용이 늘어납니다. review_mode: solo로 조절하세요. ③ 운영 중인 서버 키·계정 정보가 있는 레포라면 .env 차단 규칙을 확인하고, 사내 AI 사용 정책을 먼저 맞추세요. ④ 결정은 끝까지 사람이 내립니다 — 그게 이 시스템의 설계 철학입니다.

더 깊이 보고 싶다면

아이디어 6개를 실제로 해 보는 단계별 플레이북(명령어·확인 지점·사람이 결정할 곳)과 바로 쓰는 확장 키트, 그리고 구조 분석·로드맵을 담은 상세 보고서를 함께 준비했습니다.

실행 플레이북 열기 상세 보고서 GitHub 레포 →

Claude Code 세션 하나를게임 스튜디오로.

채팅창 하나에는 구조가 없다

만능 사원 한 명

결재선이 있는 스튜디오

49명의 조직도

자율 주행이 아니라, 협업 운전

에이전트끼리의 다섯 가지 규칙

얼마나 자주 물어볼지 고르기

아이디어에서 출시까지, 7단계

Concept컨셉

Systems Design시스템 설계

Technical Setup기술 기반

Pre-Production프리 프로덕션

Production프로덕션

Polish폴리싱

Release출시

하나의 다이얼, modes.rigor

74개 슬래시 커맨드

온보딩 · 길찾기

게임 디자인

아트 · 에셋

UX · 인터페이스

아키텍처

스토리 · 스프린트

리뷰 · 분석

QA · 테스트

프로덕션

릴리스

크리에이티브 · 콘텐츠

팀 오케스트레이션

예시 — /team-combat "패링 시스템"

시작은 세 줄

"문서만 잔뜩 만드는 거 아냐?"에 대한 실험

대신 "실행해서 눈으로 본다"는 양보하지 않는다

네 기둥으로 해부하기

자동으로 도는 안전장치 (일부)

썬더게임즈에서 이렇게 써 볼 수 있습니다

"49명을 다 쓰자"가 아니라,모바일 라이브 서비스의 병목에 맞는 팀만 꺼내 쓰자.

확률형 아이템 공시 게이트

시즌 이벤트 기획 공장

캐주얼 신작 2주 검증 스프린트

운영 중인 RPG 역문서화 & 온보딩

저사양 기기 성능 예산 & 출시 QA

글로벌 출시 현지화 파이프라인

파일럿

라이브 운영에 접목

썬더게임즈 전용 하네스

더 깊이 보고 싶다면

Claude Code 세션 하나를
게임 스튜디오로.

하나의 다이얼, `modes.rigor`

예시 — `/team-combat "패링 시스템"`

"49명을 다 쓰자"가 아니라,
모바일 라이브 서비스의 병목에 맞는 팀만 꺼내 쓰자.