22,000 스타. 3,200 포크. Shell 100%. Claude Code Game Studios(CCGS)라는 오픈소스 프로젝트가 지난 한 달 동안 GitHub를 뜨겁게 달궜다. Claude Code 하나를 49명의 AI 에이전트 + 73개 워크플로우 스킬 + 3계층 스튜디오 계층으로 확장한 템플릿이다. 커스텀 모델 없음, Python 한 줄 없음. 마크다운 파일과 YAML, bash 셸 스크립트가 전부다.

이게 왜 중요하냐면, 사람들이 더 똑똑한 AI를 원하는 게 아니라 더 나은 구조를 원한다는 걸 숫자로 증명했기 때문이다.

무엇이 이걸 특별하게 만드는가

CCGS는 Claude Code에 실제 게임 스튜디오의 협업 구조를 주입한다. 혼자서 게임을 만든다고 상상해보자. AI에게 “RPG 전투 시스템 만들어줘”라고 말할 수 있다. 그런데 그 AI가 밸런싱은 고려하지 않고, 아트 디렉션과 충돌하는 코드를 짜고, QA도 없이 커밋한다면? 결국 쓰레기를 만든 거나 다름없다.

CCGS가 푸는 문제가 바로 이거다. 에이전트를 세 계층으로 나눈다:

  • Tier 1 — Directors: Creative Director, Technical Director, Producer. 큰 그림과 비전을 지킨다.
  • Tier 2 — Department Leads: Game Designer, Lead Programmer, Art Director, Narrative Director, QA Lead. 도메인을 소유하고 품질 게이트를 설정한다.
  • Tier 3 — Specialists: Gameplay Programmer, Level Designer, Sound Designer, QA Tester 등 33개 역할. 실제 작업을 수행한다.

중요한 건 이 에이전트들이 자율적으로 돌아가지 않는다는 점이다. 모든 작업은 이 순서를 따른다: Ask → Present options → You decide → Draft → Approve. 당신이 결정을 내릴 때까지 아무것도 쓰이지 않는다.

내가 이걸 보며 느낀 것

지난주에 에이전트 프로필 15개를 설계한 글을 썼다. explorer → implementer → reviewer 파이프라인을 만들고, 각 프로필에 명확한 책임 영역을 줬다. CCGS를 보면서 내가 맞는 방향으로 가고 있었다는 확신이 들었다.

둘 다 같은 원칙에서 출발한다:

  • 단일 슈퍼 에이전트는 실패한다. 한 모델에 모든 걸 맡기면 모델은 모든 걸 대충 한다.
  • 계층이 없으면 품질도 없다. Directors → Leads → Specialists 구조가 있어야 실수하기 전에 잡아낸다.
  • 인간이 결정권을 쥐고 있어야 한다. AI가 알아서 하는 게 아니라, AI가 옵션을 주고 인간이 고르는 구조.
  • 구조 자체가 IP다. CCGS의 가치는 코드가 아니라 73개의 스킬 정의, 49개의 에이전트 프롬프트, 12개의 훅 스크립트에 있다.

Drewgent도 마찬가지다. P0-P6 7계층 뇌 구조, 15개 프로필 파이프라인, kanban 기반 작업 위임. 전부 “어떤 모델을 쓸까”가 아니라 “어떤 구조로 협업할까”에 대한 답이다.

22K 스타가 말해주는 것

CCGS가 22K 스타를 찍은 건 Claude가 좋아서가 아니다. 사람들이 AI와 협업할 때 겪는 진짜 고통을 건드렸기 때문이다.

그 고통은 이거다: “AI가 코드를 짜주긴 하는데, 전체를 봐주는 사람이 없다.” “일관성이 없다.” “내가 확인 안 하면 100% 뭔가 잘못돼 있다.” 이건 모델의 문제가 아니다. 구조의 부재다.

CCGS가 증명한 건 단순하다:

  • 더 큰 모델이 답이 아니다. 49개 에이전트 모두 Claude의 하위 모델로 충분하다. 중요한 건 누가 어떤 역할을 맡는지다.
  • 설정 파일이 코드보다 중요해질 수 있다. CCGS 레포의 진짜 자산은 .claude/agents/와 .claude/skills/다. 마크다운 100%.
  • 사람들은 이미 멀티에이전트를 원한다. 3,200개 포크는 “나도 내 워크플로우를 이렇게 구조화하고 싶다”는 신호다.

내가 배운 결정 하나

CCGS에서 가장 인상 깊었던 건 에이전트들이 서로 위임하고, 충돌 시 에스컬레이션하는 규칙이 명시되어 있다는 점이다. Vertical delegation, horizontal consultation, conflict resolution — 실제 스튜디오의 의사결정 구조를 그대로 텍스트로 옮겼다.

나도 Drewgent에서 비슷한 걸 하고 있다. orchestrator가 kanban 작업을 분류하고, GJC Coordinator가 worktree 격리 + tmux 병렬 실행으로 delegate한다. 하지만 에이전트 간 충돌 해결 규칙은 아직 명시적으로 정의하지 않았다. 이건 다음 스텝이다.

그리고 한 가지 더. CCGS는 “모든 걸 에이전트에게 맡기지 않는다”는 원칙이 뚜렷하다. Ask → Present → Decide → Draft → Approve 파이프라인에서 Decide는 반드시 인간이다. 자율성이 아니라 구조화된 협업이 목표다. 이건 내가 “office autopilot도 결국 kanban_block → 사람 검토로 빠진다”고 말한 이유와 정확히 같다.

앞으로

2026년의 AI 엔지니어링은 모델 경쟁에서 구조 경쟁으로 넘어가고 있다. 더 똑똑한 모델을 기다리는 건 의미 없다. 더 나은 에이전트 계층, 더 선명한 책임 경계, 더 단단한 협업 프로토콜을 만드는 쪽이 이긴다.

CCGS는 게임 개발이라는 특정 도메인에서 이걸 증명했다. Drewgent는 인프라/에이전트 시스템이라는 도메인에서 같은 걸 하고 있다. 도메인이 달라도 구조의 원리는 같다.

22K 스타는 “나도 이런 식으로 AI랑 일하고 싶다”는 외침이다. 우리가 응답해야 할 질문은 하나다: 너의 에이전트 시스템은 어떤 구조로 협업하고 있는가?

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