49명의 에이전트. 73개의 워크플로우 스킬. She claude s-enterprise-timebomb/”>claude /ai-tools/glm-5-2-beats-claude-code-security-benchmark/”>Claude 00%. 지난주에 Claude Code Game Studios(CCGS)가 구조의 힘을 증명했다는 글을 썼다. 22K 스타는 그 증거였다. 오늘은 그 시스템을 만든 사람, Donchitos의 설계를 더 깊이 들여다보려고 한다. 그리고 하나 더 — 비슷한 시기에 있었던 완전히 반대 방향의 실패도 함께.

Drewgent의 Trend Harvester가 Donchitos를 7.18점으로 평가했다. 높은 점수다. 직접 분석해보니 이유가 명확했다.

Donchitos가 만든 것

CCGS는 Claude Code 하나를 게임 개발 스튜디오 전체로 확장하는 템플릿이다. 단일 채팅 세션에 다음과 같은 구조를 주입한다:

49개 에이전트 — 3계층으로 조직화 (Directors → Leads → Specialists) 73개 스킬 — /start, /design-system, /create-epics, /dev-story, /code-review 등 12개 훅 — 커밋/푸시/에셋 변경 시 자동 검증 11개 룰 — 파일 경로별 코딩 표준 강제 41개 템플릿 — GDD, UX 스펙, ADR, 스프린트 플랜 문서 템플릿

이 모든 게 마크다운 + YAML + bash 스크립트로만 되어 있다. Python 한 줄도, 커스텀 모델도 없다.

3계층 스튜디오 구조를 들여다보면

Tier 1은 Directors다. Creative Director, Technical Director, Producer. 큰 그림과 비전을 지킨다.

Tier 2는 Department Leads다. Game Designer, Lead Programmer, Art Director, Audio Director, Narrative Director, QA Lead, Release Manager, Localization Lead. 도메인을 소유하고 품질 게이트를 설정한다.

Tier 3는 Specialists다. Gameplay Programmer, Engine Programmer, AI Programmer, Network Programmer, Tools Programmer, UI Programmer, Systems Designer, Level Designer, Economy Designer, Sound Designer, QA Tester, Accessibility Specialist까지 — 33개 이상의 역할이 실제 작업을 수행한다.

여기에 더해 엔진별 Specialist 세트도 따로 있다. Godot 4, Unity, Unreal Engine 5 각각에 맞춰진 에이전트 그룹이 준비돼 있다. 게임 엔진을 바꿔도 구조가 무너지지 않는다.

진짜 인사이트: 협업 프로토콜

에이전트 수가 중요한 게 아니다. 에이전트들이 어떻게 협업하는지에 대한 규칙이 중요하다. CCGS의 에이전트 협업 프로토콜은 다음과 같다:

Vertical delegation — Director → Lead → Specialist로 위임 Horizontal consultation — 같은 계층 에이전트끼리 협의 가능하지만, 구속력 있는 결정은 내리지 못함 Conflict resolution — 충돌 시 공통 상위 디렉터에게 에스컬레이션. 디자인 충돌은 Creative Director, 기술 충돌은 Technical Director Domain boundaries — 명시적 위임 없이는 자신의 도메인 밖 파일 수정 불가

그리고 가장 중요한 원칙: Ask → Present → Decide → Draft → Approve. AI가 알아서 하는 게 아니라, 인간이 결정할 때까지 아무것도 쓰지 않는다. 구조화된 협업이지, 자율 주행이 아니다.

Drewgent와의 공통 패턴

이거 보면서 등골이 오싹했다. 내가 Drewgent에서 한 설계와 거의 같은 패턴이기 때문이다:

CCGS의 3계층 Director/Lead/Specialist ↔ Drewgent의 orchestrator/profile/worker CCGS의 conflict escalation ↔ Drewgent의 kanban_block → 사람 검토 CCGS의 “Approve 단계 없이 write 금지” ↔ Drewgent의 “office autopilot도 결국 kanban_block” CCGS의 Shell 100% ↔ Drewgent의 launchd cron + bash 스크립트 중심

49명이라는 숫자도 우연이 아닌 것 같다. CCGS는 49 에이전트, Drewgent는 15개 프로필 + kanban worker + cron job들로 비슷한 규모의 에이전트 풀을 운영한다. 에이전트 스웜에 최적 팀 크기가 있는 건 아닐까?

반대편: 구조 없이 taste도 없이

같은 시기에 완전히 반대 방향의 이야기도 있었다. AI에게 주도권을 빼앗기지 마세요에서 다룬 것처럼, 누군가는 Claude Code로 자동매매 시스템을 만들어 0승 8패, 자산 3% 손실을 봤다. 블로그 자동발행은 AI가 쓴 부정확한 글을 검수 없이 올려서 독자한테 들켰다.

두 실패의 공통 원인은 하나다: 구조도 없고, taste도 없고, 인간의 판단도 없었다. AI가 할 수 있다고 해서 다 맡겨버린 거다.

CCGS와 이 실패담은 같은 도구(Claude Code)로 완전히 다른 결과를 냈다. 차이는 단 하나: 구조를 설계했는가 아닌가.

구조는 taste 없이도 실패하고, taste는 구조 없이도 실패한다

CCGS가 증명한 건 에이전트 시스템은 모델보다 구조가 중요하다는 거다. 지난 글(주목받는 건 모델이 아니라 구조다)에서 이걸 외부 검증 사례로 다뤘다.

그런데 자동매매 8연패 사례가 보여주는 건 구조 자체가 taste를 대체할 수는 없다는 거다. 아무리 에이전트 계층을 잘 나누고, 훅을 걸고, 규칙을 명시해도, 인간이 판단을 내려야 하는 지점을 시스템이 우회하면 실패한다.

그래서 Drewgent에서는 Tiered Autonomy를 만들었다. 모든 작업에 위험도 1-4를 매기고, Tier 1-2는 AI가 자율 실행하지만 Tier 3-4는 반드시 인간 승인을 거친다. Taste는 감각이 아니라 정책이다.

내가 훔친 CCGS의 결정 하나

CCGS에서 Drewgent에 바로 적용할 가치가 있다고 느낀 건 에이전트 간 충돌 해결 에스컬레이션 규칙이다.

Drewgent도 orchestrator → GJC delegate → worker로 위임하는 구조는 있다. 하지만 두 에이전트가 같은 파일을 수정하려 하거나, 서로 모순된 결정을 내릴 때 누구에게 에스컬레이션할지가 명시돼 있지 않다. CCGS는 “디자인 충돌 → Creative Director, 기술 충돌 → Technical Director”로 명확하다.

이건 다음 Drewgent 이터레이션에 넣을 거다. Conflict resolution의 기본값을 “인간에게 물어봐라”로 두고, 특정 도메인은 특정 상위 에이전트가 중재하게 하는 구조.

마치며

Donchitos의 CCGS는 22K 스타라는 숫자보다 더 중요한 걸 보여줬다: AI 에이전트 시스템의 승부는 더 큰 모델이 아니라, 더 나은 구조에서 난다는 것. 그리고 구조만으로는 부족하고, 인간의 판단이 들어갈 지점을 명시적으로 설계해야 한다는 것.

0승 8패와 22K 스타 사이의 차이는 Claude의 버전이 아니었다. 판단을 누가 내리느냐의 차이였다.

Season 1 “Taste Engineering” — CCGS 구조 분석에 이어, AI에게 주도권을 빼앗기지 마세요의 반대편까지. 이제 패턴이 보인다.

Claude Code Game Studios: github.com/Donchitos/Claude-Code-Game-Studios

AI 자동화 실패 원본 글: GeekNews 토픽 #30855