들어가며
claude-code-game-studios와 함께 개임 게발 찍먹을 시작해보았다.
안을 살펴보면 게임 개발용 템플릿이자 멀티 에이전트를 어떻게 조직할 것인가에 대한 잘 만들어진 사례라는 생각이 자연히 들 것 같다.
이 레포는 실제 게임 스튜디오 조직도라는 컨셉을 가지고 있다. 그래서 "게임을 어떻게 만들까"와 "에이전트를 어떻게 조직할까"를 한 번에 들여다볼 수 있었다. 하나의 Claude Code 세션을, 4n명이 일하는 스튜디오처럼 동작하게 만든다.
(살짝 밤티긴 하지만 감격스러운 유니티 첫 예제)
단일 세션을 조직도로 바꾸기
이 레포는 그 대신 4n개의 전문 에이전트를 3계층으로 나눈다.
- Tier 1 - Directors: creative-director, technical-director, producer. 비전과 전략을 정하는 결정권자. 모델은 Opus를 쓴다.
- Tier 2 - Department Leads: game-designer, lead-programmer, art-director, qa-lead 등. 도메인별 책임자. 모델은 Sonnet.
- Tier 3 - Specialists: gameplay-programmer, level-designer, sound-designer 같은 실무자 30여 명. Sonnet/Haiku.
여기서 재밌는 건 모델 티어를 역할에 맞춰 다르게 배정한다는 점이다. 판단의 무게가 큰 디렉터는 비싼 Opus, 정해진 일을 실행하는 실무자는 저렴하고 빠른 Haiku를 사용한다.
일이 흐르는 방향에 규칙이 있다
에이전트를 많이 만드는 것보다 어려운 건 그래서 누가 누구에게 말하느냐다. 이 레포는 협업 방향을 네 가지로 못박는다.
- 수직 위임은 아래로만 흐른다 (디렉터 → 리드 → 실무자)
- 같은 계층끼리는 수평으로 상의한다
- 의견이 갈리면 공통 상위로 에스컬레이션한다
- 부서를 가로지르는 변경은 반드시 producer를 거친다
이게 왜 중요하냐면, 이런 규칙이 없으면 에이전트들이 서로 무한정 호출하면서 맥락이 폭발하거나, 아무도 최종 책임을 안 지는 상태가 되기 때문이다. "cross-department 변경은 producer를 통한다" 같은 한 줄이 사실은 토큰 폭발과 책임 공백을 동시에 막는 장치다.
에이전트 정의 = 시스템 프롬프트 + 권한 + 경계
에이전트 하나가 실제로 어떻게 정의돼 있는지 보면 구조가 분명해진다. creative-director 에이전트의 frontmatter는 대략 이렇다.
name: creative-director
model: opus
tools: Read, Glob, Grep, Write, Edit, WebSearch눈여겨본 건 도구 권한을 일부러 좁혀놓은 것이다. 크리에이티브 디렉터에게는 Bash 실행 권한이 없다. 코드를 직접 돌릴 일이 없는 역할이기 때문이다. 권한을 곧 책임 범위로 쓴다.
본문에는 "이 에이전트가 할 수 없는 것"이 명시돼 있다. 코드 작성, 개별 에셋 승인, 스프린트 결정, 최종 내러티브 텍스트 작성, 기술 아키텍처 결정 - 전부 다른 디렉터에게 위임한다. 즉 에이전트 정의는 "무엇을 잘하는가"보다 "무엇을 하면 안 되는가"의 경계선으로 동작한다. 이게 잘 그어져 있어야 위임이 깨지지 않는다.
의사결정 방식도 프롬프트에 박혀 있다. 디렉터는 독재자가 아니라 컨설턴트로 행동한다. 맥락을 모으고 → 결정을 프레이밍하고 → 2~3개 옵션을 트레이드오프와 함께 제시하고 → 추천하되 최종 결정은 사용자에게 넘긴다. (You provide strategic analysis, the user provides final judgment.)
Hooks: LLM이 아니라 코드가 품질을 강제한다
이 레포에는 12개의 hook이 있는데, 품질 검사를 LLM의 판단이 아니라 결정론적인 스크립트로 처리한다.
- pre-commit 검증: 하드코딩된 값, 잘못된 형식의 TODO, 깨진 JSON, 빠진 설계 섹션 탐지
- push 보호: 보호된 브랜치에 푸시하면 경고
- 에셋 검증: 네이밍 규칙과 JSON 구조 확인
- 세션 라이프사이클: 시작 시 컨텍스트 초기화, 종료 시 진행 상황 아카이브
- 에이전트 감사 로그: 서브에이전트 호출/완료를 기록
확률적 추론(에이전트)과 결정론적 강제(hook)를 한 시스템 안에서 역할 분담시키는 게 신뢰할 수 있는 AI 파이프라인을 만드는 핵심이다.
Path-scoped Rules: 파일 위치가 기준을 정한다
코딩 표준을 전역으로 하나만 두지 않고, 파일 경로별로 다른 규칙을 자동 적용한다.
src/gameplay/** → 데이터 기반 값, delta-time 사용, UI 결합 금지
src/core/** → 핫패스에서 할당 0, 스레드 안전성
src/networking/** → 서버 권위 구조, 버전드 메시지
src/ui/** → 게임 상태 소유 금지, 다국어 대응, 접근성
design/gdd/** → 8개 필수 섹션, 공식 기반 밸런스
prototypes/** → 기준 완화, 가설만 문서화흥미로운 건 prototypes/**는 일부러 기준을 풀어준다는 점이다. 실험하는 코드에까지 프로덕션 기준을 들이대면 아무도 실험을 안 하게 되니까. 맥락에 따라 엄격함의 정도를 다르게 가져가는 것도 설계의 일부다.
패턴은 도메인을 안 탄다
분야는 다르지만, 여기서 쓰이는 컨셉은 도메인을 타지 않고 적용할 수 있겠다.
- 만능 에이전트 하나 대신, 좁은 책임을 가진 에이전트 여럿으로 쪼갠다
- 위임·에스컬레이션 경로를 명시해서 맥락 폭발과 책임 공백을 막는다
- 역할의 판단 무게에 따라 모델 티어를 배정한다
- 확률적인 에이전트 위에 결정론적인 hook으로 품질을 강제한다
- 자율 실행이 아니라, 옵션을 제시하고 사람의 승인을 기다린다
마치며
참 좋은 세상이다.