요약
- 무엇인가 — Claude Code 세션 하나에 실제 게임 스튜디오의 조직(디렉터·리드·스페셜리스트 3계층, 49개 에이전트)과 절차(74개 스킬), 검수(15개 훅, 14개 경로 규칙)를 입히는 오픈소스 템플릿이다. GitHub 별 27.2k, 포크 3.9k(2026-10-23 기준).
- 핵심 설계 — "자율이 아니라 협업". 모든 에이전트가 질문 → 선택지 → 사용자 결정 → 초안 → 승인의 다섯 단계를 따르고, 파일을 쓰기 전 허락을 구한다. 규칙은 문서에만 두지 않고 훅으로 강제한다.
- 가장 흥미로운 결과 — 원작자의 자체 실험에서 문서를 30개 쓴
standard빌드가 문서 1개짜리minimal빌드보다 낮은 평가를 받았다. 그래서 기본값은 가장 가벼운minimal이며, 대신 "실행해서 눈으로 확인한 증거"는 모든 수준에서 의무다. - 썬더게임즈 제안 — 49명 전원을 쓰기보다 모바일 라이브 서비스의 병목(확률형 아이템 공시 검증, 시즌 이벤트 기획, 레거시 역문서화, 신작 빠른 검증)에 맞는 팀만 꺼내 쓴다. 2주 파일럿 → 1~2개월 운영 접목 → 분기 단위 사내 하네스 구축의 3단계를 권한다.
01개요
Claude Code Game Studios(이하 CCGS)는 Donchitos가 공개한 Claude Code용 프로젝트 템플릿이다. 레포를 복제한 폴더에서 Claude Code를 실행하면, CLAUDE.md와 .claude/ 아래의 에이전트·스킬·훅·규칙이 자동으로 로드되어 하나의 세션이 "게임 스튜디오"처럼 동작한다.
| 버전 | v1.2.0 (2026-10-19). 스토리 스킬 재구성, 대용량 설계 문서 읽기 가드, Godot 4.7·Unreal 5.8 엔진 레퍼런스 반영 |
|---|---|
| 지원 엔진 | Godot 4, Unity, Unreal Engine 5 — 엔진별 스페셜리스트 세트 제공 |
| 필요 환경 | Git, Claude Code, Python 3(project.yaml 해석), Bash(Windows는 Git for Windows), jq 권장 |
| 주 개발 환경 | Windows 10 + Git Bash. macOS(bash 3.2)·Linux에서도 훅 테스트 |
| 대상 사용자 | AI와 함께 게임을 만드는 1인~소규모 인디 개발자. 템플릿이므로 팀 맞춤 수정이 전제 |
02문제 정의
AI 한 명과 게임을 만드는 일은 빠르지만 구조가 없다. 원작자는 이 공백을 이렇게 요약한다. 하드코딩된 매직 넘버를 막는 사람도, 설계 문서를 건너뛰는 것을 지적하는 사람도, QA 패스도, "이게 게임의 비전에 맞는가?"를 묻는 사람도 없다.
이는 에이전트 설계 관점에서 보면 단일 컨텍스트의 역할 혼재 문제다. 기획 판단·코드 구현·품질 검수가 하나의 대화 흐름 안에서 섞이면, 앞선 결정이 잊히고 검토가 생략된다. CCGS의 해법은 모델을 바꾸는 것이 아니라 모델이 일하는 환경을 바꾸는 것, 즉 하네스(harness)를 설계하는 것이다.
03구성 요소
| 구성 | 수량 | 위치 | 역할 |
|---|---|---|---|
| 에이전트 | 49 | .claude/agents/ | 디자인·프로그래밍·아트·오디오·내러티브·QA·프로덕션 전문 서브에이전트. frontmatter에 도구·모델·최대 턴·메모리 범위 정의 |
| 스킬 | 74 | .claude/skills/ | /start, /design-system, /dev-story 등 단계별 슬래시 커맨드. 어떤 에이전트를 어떤 순서로 부를지 기술 |
| 훅 | 15 | .claude/hooks/ | 커밋·푸시·파일 읽기/쓰기·에셋 변경·세션 시작/종료·서브에이전트 시작/종료 시 자동 검증 |
| 규칙 | 14 | .claude/rules/ | 파일 경로에 따라 자동 적용되는 코딩 표준(게임플레이, 엔진, AI, UI, 네트워크, 셰이더, 테스트 등) |
| 템플릿 | 62 | .claude/docs/templates/ | GDD, UX 명세, ADR, 스프린트 계획, HUD 설계, 접근성 문서 등 |
| 설정 | 1 | project.yaml | 엔진·네이밍·모드 설정의 단일 출처. 개인 설정은 project.local.yaml |
| 자체 테스트 | — | studio-tests/ | 게임이 아닌 스킬·에이전트 자체의 품질을 검사하는 카탈로그와 루브릭 |
04조직 구조와 조정 규칙
3계층 조직
모델 배치도 직급을 따른다. 디렉터 3명은 Opus를 요청하고, lead-programmer와 15명의 스페셜리스트(대부분 엔진 하위 전문가와 prototyper·devops·community-manager)는 Sonnet을 지정하며, 나머지 30명은 사용자가 쓰고 있는 세션 모델을 그대로 상속한다. 원작자는 계층을 "요금제가 아니라 직급"으로 보라고 강조한다.
에이전트 정의는 권한 설계도 겸한다. 예컨대 creative-director는 disallowedTools: Bash로 셸 실행이 막혀 있다. 판단하는 자리는 직접 손대지 않는다는 조직 원칙이 도구 권한으로 구현된 것이다.
조정 규칙
| # | 규칙 | 내용 |
|---|---|---|
| 1 | 수직 위임 | 디렉터 → 리드 → 스페셜리스트. 복잡한 결정에서 계층을 건너뛰지 않는다. |
| 2 | 수평 협의 | 같은 계층끼리 상의할 수 있으나, 자기 영역 밖에서 구속력 있는 결정을 하지 않는다. |
| 3 | 충돌 해결 | 공통 상위자에게 올린다. 없으면 디자인은 creative-director, 기술은 technical-director. |
| 4 | 변경 전파 | 여러 부서에 걸친 설계 변경은 producer가 조율한다. |
| 5 | 영역 경계 | 명시적 위임 없이 자기 디렉터리 밖의 파일을 수정하지 않는다. |
| 6 | 섹션 단위 읽기 | 설계 문서는 필요한 제목 범위만 읽는다. 40KB 초과 문서의 통째 읽기는 훅이 거절한다. |
| 7 | 업스트림 금지 | 엔진·플러그인 벤더 레포에 이슈나 PR을 직접 올리지 않는다. 초안만 쓰고 제출은 사용자가 한다. |
05작동 방식
협업 프로토콜
모든 작업은 질문 → 선택지 → 결정 → 초안 → 승인의 순서를 따른다. 에이전트는 Write/Edit 전에 "이 경로에 써도 될까요?"를 반드시 묻고, 여러 파일 변경은 변경 묶음 전체에 대한 승인을 받는다. 사용자가 질문을 건너뛰거나 닫으면 그것을 답으로 간주하지 않고 다시 묻는다. 커밋은 사용자 지시 없이 하지 않는다.
자동화 수준
modes.automation으로 개입 빈도를 고른다. collaborative(기본)는 단계 전환마다 승인을 받고, guided는 막힌 단계가 아니면 자동 진행하며, autonomous는 끝까지 실행하되 모든 판단을 결정 로그에 남긴다. 어느 모드든 "항상 물어볼 범주"로 지정된 결정은 사람에게 묻는다.
세션 상태와 컨텍스트
세션의 기억은 대화가 아니라 파일이다. production/session-state/active.md가 체크포인트 역할을 하며, 컨텍스트 압축·충돌·/clear 뒤에는 이 파일부터 읽는다. 또 .claude/scripts/의 헬퍼는 "관찰만 내고 판정은 하지 않는다"는 원칙을 지킨다. 점수를 매기는 스크립트는 언젠가 자신이 모르는 설정과 충돌하기 때문이다.
서브에이전트와 팀 스킬
/team-combat, /team-live-ops 등 9개 팀 스킬은 하나의 기능에 여러 에이전트를 묶어 설계 → 구현 → 검증을 진행한다. 서로의 결과가 필요 없는 하위 작업은 병렬로 띄우고, 하나라도 막히면 조용히 건너뛰지 않고 부분 보고서를 낸다. team.size(individual·small·studio)에 따라 실제로 투입할 에이전트를 실행 전에 선언한다. 여러 세션을 공유 작업 목록으로 묶는 Agent Teams는 실험적 옵트인 기능으로 분리되어 있다.
06워크플로 파이프라인
| 단계 | 목표 | 대표 스킬 |
|---|---|---|
| 1. Concept | 아이디어를 컨셉 문서로, 아트 바이블과 시스템 지도까지 | /brainstorm /art-bible /map-systems |
| 2. Systems Design | 시스템별 GDD 작성과 교차 리뷰 | /design-system /review-all-gdds |
| 3. Technical Setup | 아키텍처, ADR, 접근성 기반, 테스트 프레임워크 | /create-architecture /test-setup |
| 4. Pre-Production | UX·에셋 명세, 코어 프로토타입, 에픽·스토리 분해, 재미 검증 | /prototype /create-stories |
| 5. Production | 스프린트 단위 구현과 완료 판정 | /sprint-plan /dev-story /story-done |
| 6. Polish | 성능, 밸런스, 플레이테스트, 버그 | /perf-profile /balance-check |
| 7. Release | 인증, 출시 준비, 패치 | /launch-checklist /patch-notes |
프로세스의 무게는 modes.rigor 하나로 조절한다. 이 값은 GDD 필수 섹션(workflow), 문서 밀도, QA 증거 수준, 스토리 크기, 디렉터 리뷰 깊이(review_mode), 팀 규모를 한꺼번에 정한다. minimal(기본)은 한 장짜리 기획서에서 바로 스토리와 구현으로 가고, standard는 GDD 5개 섹션, full은 8개 섹션과 디렉터 전원 리뷰를 요구한다. 특정 시스템만 엄격하게 다루는 system_overrides, 테스트 유형별로 증거 누락을 차단할지 경고만 할지 정하는 testing.strict도 있다.
07품질·안전장치
훅
| 훅 | 시점 | 검사 내용 |
|---|---|---|
validate-commit.sh | 커밋 전 | 하드코딩 값, TODO 형식, JSON 유효성, 설계 문서 섹션 |
validate-push.sh | 푸시·태그·배포 전 | 보호 브랜치 푸시, butler push, steamcmd 업로드 경고 |
validate-read.sh | 읽기 전 | 40KB 초과 설계 문서 통째 읽기 거절, 목차 반환 |
validate-write.sh | 쓰기 전 | 덮어쓰면 안 되는 파일, 프로토타입 경계, 현지화 동결 위반 경고 |
validate-registry.sh | 쓰기 전 | 엔티티·요구사항 ID 레지스트리 삭제·번호 변경 경고 |
validate-assets.sh | 쓰기 후 | 데이터 JSON, 에셋 네이밍 |
session-start.sh · detect-gaps.sh | 세션 시작 | 브랜치·최근 커밋 안내, 설계 문서 공백 감지 |
log-agent*.sh · validate-agent-artifact.sh | 서브에이전트 시작·종료 | 감사 로그, 약속한 산출물 미작성 경고 |
대부분의 훅은 차단보다 경고를 택한다. 예외적으로 Python이 없을 때 데이터 JSON이 포함된 커밋은 막는다. settings.json의 권한 규칙은 force push, rm -rf, .env 읽기를 Bash와 PowerShell 양쪽에서 거부한다.
경로별 규칙
src/gameplay/**에서는 데이터 주도 값과 delta time 사용, src/core/**에서는 핫패스 무할당과 스레드 안전성, src/networking/**에서는 서버 권위와 메시지 버전 관리, src/ui/**에서는 게임 상태 비소유와 현지화 대비가 자동으로 요구된다. Unity(Assets/)와 Unreal(Source/) 레이아웃에도 대응한다.
실행 증거
플레이어가 보는 것을 바꾼 스토리는 게임을 실제로 실행해 관찰하고 스크린샷을 production/qa/evidence/에 남겨야 닫힌다. v1.2.0부터 /dev-story가 증거 옆에 stamp.txt를 기록해, 이후 해당 파일이 바뀌면 /story-done이 재촬영을 권한다.
하네스 자체의 테스트
studio-tests/와 /skill-test, /skill-improve는 게임이 아니라 프레임워크를 시험한다. 구조 린트(7개 준수 항목), 카테고리별 품질 루브릭, 행동 명세 검증, 커버리지 감사를 제공하며, /skill-improve는 점수가 떨어지면 변경을 되돌리는 테스트-수정-재시험 루프를 돈다.
08실험 결과와 시사점
원작자는 "이 시스템은 게임을 만드는가, 문서를 만드는가?"라는 질문에 샘플 대신 측정으로 답했다. 같은 기획서 하나로 rigor 수준을 달리해 게임 네 개를 만들고 첫 게임 코드 이전에 쓴 문서를 셌다(README에는 두 수준의 수치가 공개됨).
| modes.rigor | 첫 코드 전 문서 | 첫 코드까지 시간 | 평가 |
|---|---|---|---|
minimal | 1 (한 장짜리 기획서) | 0분 | 동작·테스트 통과 |
standard | 30 | 58분 | 동작·테스트 통과, 블라인드 리뷰 2인과 사람 플레이테스트에서 최하위 |
시사점 1 — 프로세스는 품질의 대리 지표가 아니다. 추가 문서 29개가 산 것은 추적 가능성이었지 더 좋은 게임이 아니었다. 그래서 기본값을 가장 가벼운 수준으로 두고, 프로젝트가 커질 때 /help와 /gate-check가 상향을 제안하도록 설계했다.
시사점 2 — 생략할 수 없는 것은 따로 있다. 문서와 리뷰는 줄여도 "실행해서 눈으로 보는" 검증은 모든 수준에서 의무다. 에이전트 시스템을 설계할 때 무엇을 조절 가능한 다이얼로 두고 무엇을 고정된 게이트로 둘지 구분한 좋은 사례다.
09평가: 강점과 한계
| 강점 | 한계·리스크 |
|---|---|
|
|
10썬더게임즈 도입 제안
전제
공개된 기업 정보에 따르면 썬더게임즈는 2015년 설립된 부산 해운대 센텀 소재의 모바일 RPG·캐주얼 게임 개발사다. 이 제안은 그 정보를 바탕으로 한 가정이며, 실제 엔진(모바일 개발 특성상 Unity를 가정)·조직 규모·운영 중인 타이틀에 맞춰 조정해야 한다.
핵심 판단은 이렇다. CCGS의 가치는 "신작을 AI가 처음부터 만드는 것"보다 "반복되는 운영 업무와 검증 절차를 표준화하는 것"에서 먼저 나온다. 모바일 라이브 서비스의 병목에 맞는 에이전트와 스킬만 꺼내 쓰고, 부족한 부분(확률·과금 규제)은 사내 규칙으로 보강한다.
활용 아이디어
각 아이디어를 실제로 해 보는 명령어와 확인 지점은 실행 플레이북에, 확률 공시 게이트의 검사기·훅·규칙·검수 에이전트는 thunder-kit.zip에 담았다.
| # | 과제 | 사용 구성요소 | 기대 효과 | 난이도 |
|---|---|---|---|---|
| 1 | 확률형 아이템 공시 게이트 가챠 데이터 변경 시 확률 합계·공시 필드·변경 이력 자동 검사 | 신규 경로 규칙(assets/data/gacha/**), validate-commit.sh 확장, economy-designer, /balance-check | 2024년 3월 시행된 확률 정보 공개 의무 관련 누락·오기 사고를 배포 전에 차단 | 중 |
| 2 | 시즌 이벤트 기획 공장 콘셉트 → 보상표 → 재화 흐름 분석 → 대사·공지 → 패치노트 | /team-live-ops, live-ops-designer, economy-designer, writer, community-manager, /patch-notes | 이벤트 문서 준비 시간 단축, 재화 인플레이션 사전 점검 | 하 |
| 3 | 캐주얼 신작 2주 검증 한 장 기획서 → 프로토타입 → 플레이테스트 → 진행/전환/중단 판정 | rigor: minimal, /brainstorm, /prototype --path html, /playtest-report(판정은 /prototype 보고서의 PROCEED/PIVOT/KILL) | 아이디어 검증 회전 수 증가, 회의를 "플레이 결과" 중심으로 전환 | 하 |
| 4 | 운영 RPG 역문서화·온보딩 코드에서 GDD·ADR 복원, 신규 인원 온보딩 자료 생성 | /adopt, /project-stage-detect, /reverse-document, /onboard | 담당자 이탈 리스크 완화, 온보딩 기간 단축 | 중 |
| 5 | 저사양 기기 성능 예산·출시 QA 기기 등급별 프레임·메모리 예산과 업데이트별 회귀 검사 | Unity 스페셜리스트 세트, performance-analyst, /perf-profile, /smoke-check, /regression-suite | 패치 후 크래시·UI 깨짐 감소, 실행 증거로 품질 추적 | 중 |
| 6 | 글로벌 출시 현지화 문자열 추출·길이·폰트 점검·말투 일관성·현지화 동결 | localization-lead, writer, /localize, /launch-checklist, validate-write.sh의 동결 경고 | 다국어 출시 시 누락 문자열·텍스트 넘침 사전 발견 | 중 |
필요한 맞춤화
- 라이브옵스 윤리 정책 재작성 — 기본
live-ops-designer는 "유료 구매 + 무작위 결과" 루트박스를 약탈적 설계로 보고 creative-director에게 에스컬레이션하도록 되어 있다. 가챠가 핵심 BM인 RPG라면 매번 경고가 뜬다. 이를 국내 법규 기준의 확률 공개, 과금 한도, 미성년자 보호, 천장(보장) 시스템 기준으로 바꿔design/live-ops/ethics-policy.md에 명시한다. - 사내 전용 에이전트 추가 —
gacha-compliance(확률 공시·변경 이력 검수),mobile-perf(기기 등급별 예산),store-ops(구글 플레이·앱스토어 심사 대응) 등. - 에이전트 정리 — 콘솔 인증, 멀티플레이 넷코드처럼 당장 쓰지 않는 에이전트는 삭제해 선택지를 줄인다. 템플릿은 수정을 전제로 한다.
- 사내 규칙 이식 — 데이터 테이블 네이밍, 서버·클라이언트 경계, 로그 이벤트 규칙을
.claude/rules/로 옮긴다.
단계별 로드맵
| 단계 | 기간 | 범위 | 완료 기준 |
|---|---|---|---|
| STEP 1 · 파일럿 | 2주 | 사이드 프로젝트 1개, rigor: minimal, 아이디어 3 적용. 에이전트 10명 안팎만 유지 | 프로토타입 1개와 진행/전환/중단 판정, 팀 회고 |
| STEP 2 · 운영 접목 | 1~2개월 | 아이디어 1(확률 게이트) 개발·도입, 아이디어 2로 한 시즌 이벤트 운영, 아이디어 4로 핵심 시스템 3개 역문서화 | 게이트가 실제 커밋에서 작동, 이벤트 1건 전 과정 수행 |
| STEP 3 · 사내 하네스 | 분기 | 사내 에이전트·규칙·스킬 정비, studio-tests로 회귀 관리, 사내 교육 과정화 | 썬더게임즈 전용 템플릿 레포 확정, 신규 프로젝트 기본 적용 |
성과 지표 예시
- 이벤트 1건당 기획 문서 준비 시간(도입 전후 비교)
- 배포 전 차단된 확률·데이터 오류 건수, 배포 후 데이터 핫픽스 건수
- 신작 아이디어 검증 주기(아이디어 → 판정까지 일수)와 분기당 검증 건수
- 패치 후 크래시율, UI 관련 CS 문의 수
- 신규 입사자가 첫 기여(커밋)까지 걸린 기간
리스크와 대응
| 리스크 | 대응 |
|---|---|
| 소스·서버 키 등 민감 정보 노출 | 사내 AI 사용 정책 선확정, .env 차단 규칙 확인, 운영 레포는 STEP 2부터 단계적 적용 |
| 비용 증가(디렉터 Opus 리뷰) | review_mode: solo·lean으로 시작, 파일럿 기간 사용량 측정 후 확대 |
| 문서 과잉으로 속도 저하 | 기본 minimal 유지, 전투·경제처럼 중요한 시스템만 system_overrides로 상향 |
| AI 산출물에 대한 과신 | 승인 프로토콜 유지(collaborative), 실행 증거 없이 스토리 종료 금지 원칙 고수 |
11결론
CCGS는 "더 똑똑한 모델"이 아니라 "더 잘 짜인 환경"으로 AI 결과물의 편차를 줄이는 하네스 엔지니어링의 좋은 사례다. 규약(CLAUDE.md·규칙), 역할(에이전트), 절차(스킬), 게이트(훅·자체 테스트)의 네 기둥이 모두 갖춰져 있고, 무엇보다 자신들의 프로세스가 품질을 보장하지 않는다는 실험 결과를 정직하게 공개하고 기본값에 반영했다는 점이 인상적이다.
썬더게임즈에는 이 템플릿을 그대로 쓰기보다 모바일 라이브 서비스용으로 재단한 사내 하네스의 출발점으로 삼기를 권한다. 리스크가 가장 낮은 신작 2주 검증으로 시작해, 확률 공시 게이트와 이벤트 기획 공장처럼 반복 업무가 많은 영역으로 넓혀 가는 순서가 현실적이다.
—참고 자료
- Donchitos, Claude-Code-Game-Studios — README.md, CLAUDE.md, CHANGELOG.md(v1.2.0),
.claude/docs/coordination-rules.md,.claude/docs/workflow-catalog.yaml,.claude/agents/*.md,.claude/skills/team-combat/SKILL.md - 썬더게임즈 기업 정보 — 원티드 기업 페이지, 게임잡 기업정보
- Claude Code 공식 문서 — code.claude.com/docs