Claude Code 소스 유출이 밝힌 멀티 에이전트의 비밀 — 오케스트레이션은 코드가 아니라 프롬프트다

2026년 3월 말 Claude Code 소스코드 51만 줄이 npm 소스맵 실수로 유출되었습니다. 수많은 발견 중에서 개발자 커뮤니티가 가장 놀란 것은 멀티 에이전트 오케스트레이션의 구현 방식이었습니다. DEV Community의 한 글은 이를 "모든 개발자에게 AI 에이전트 오케스트레이션 마스터클래스를 선물했다"고 표현했습니다.
이 글에서는 유출된 소스에서 드러난 멀티 에이전트 아키텍처를 심층 분석합니다.
 

핵심 발견: 코드가 아니라 프롬프트

coordinatorMode.ts에서 밝혀진 가장 충격적인 사실은, 멀티 에이전트 조율이 전통적인 코드 기반 상태 머신이 아니라 시스템 프롬프트의 자연어 지시로 구현되어 있다는 점입니다.

코디네이터 에이전트는 "Claude + 코디네이터 시스템 프롬프트"이고, 워커 에이전트들도 "Claude + 각자의 워커 프롬프트"입니다. 하위 에이전트가 특별한 프로세스가 아니라, 다른 시스템 프롬프트를 가진 동일한 Claude 인스턴스라는 뜻입니다.
시스템 프롬프트에는 구체적인 행동 규칙이 자연어로 작성되어 있습니다:

"Parallelism is your superpower. Workers are async. Launch independent workers concurrently whenever possible."
(병렬성이 당신의 초능력이다. 워커는 비동기다. 독립적인 워커는 가능할 때마다 동시에 실행하라.)

"Do not rubber-stamp weak work."
(약한 작업에 도장을 찍지 마라. 즉 부실한 결과물을 그냥 통과시키지 마라.)

"You must understand findings before directing follow-up work. Never hand off understanding to another worker."
(후속 작업을 지시하기 전에 발견 사항을 반드시 이해해야 한다. 이해를 다른 워커에게 넘기지 마라.)

이 설계의 의미는 큽니다. 에이전트의 행동 변경이 코드 배포 없이 프롬프트 수정만으로 가능하다는 것입니다. 프로덕션 AI 에이전트 시스템에서 운영 유연성을 극대화하는 패턴입니다.
 

3가지 서브에이전트 실행 모델

유출된 소스에서 3가지 서로 다른 서브에이전트 실행 모델이 발견되었습니다. 각각 다른 격리 수준과 용도를 가집니다.
Fork 모델은 부모 컨텍스트의 바이트 동일 복사본으로, 프롬프트 캐시를 그대로 활용합니다. 공유 컨텍스트 프리픽스에 대해 한 번만 비용을 지불하고, 태스크별 분기 지점부터만 추가 비용이 발생합니다. 이것이 멀티 에이전트를 경제적으로 운영 가능하게 만드는 핵심입니다. 캐시 공유 없이 5개 워커를 실행하면 입력 토큰 비용이 5배가 되지만, 캐시를 공유하면 공통 프리픽스는 1번만 처리됩니다.

Teammate 모델은 별도의 tmux/iTerm2 패널에서 실행되며, 파일 기반 메일박스로 통신합니다. 느슨하게 조율된 독립적 작업 스트림에 적합합니다. 메일박스 디렉토리는 ~/.claude/teams/{team-name}/messages/{session-id}/에 저장됩니다.

Worktree 모델은 에이전트별 독립 git 워크트리(별도 브랜치)에서 실행됩니다. 탐색적이거나 위험한 작업을 메인 컨텍스트와 완전히 격리하여 수행합니다.
세 모델 모두 공통점이 있습니다. 서브에이전트는 결과만 오케스트레이터에 반환하고, 전체 작업 컨텍스트는 반환하지 않습니다. 부모 상태의 오염을 의도적으로 방지하는 설계입니다.
 

TeammateTool — 숨겨진 팀 오케스트레이션 시스템

TeammateTool은 소스 안에 완전히 구현되어 있지만, I9()와 qFB() 두 피처 게이트 함수가 모두 true를 반환해야만 활성화됩니다. 공개 릴리스에서는 둘 다 false를 반환하여 접근이 차단됩니다.

팀 생명주기 전체를 관리하는 기능이 구현되어 있습니다. 팀원 스폰과 디스커버리, 참가 요청과 승인 게이트 워크플로우, 그레이스풀 셧다운 프로토콜이 포함됩니다. 조율 기본 요소로는 팀원 간 직접 메시징, 전체 브로드캐스트, 계획된 작업에 대한 승인 워크플로우가 있습니다.
저장소 구조도 명확히 드러났습니다:

~/.claude/teams/{team-name}/config.json     ← 팀 설정
~/.claude/teams/{team-name}/messages/       ← 메일박스
~/.claude/tasks/{team-name}/                ← 공유 태스크 리스트

추가로 tengu_scratch 피처 플래그 뒤에 공유 스크래치패드 디렉토리가 있습니다. 워커 간 내구성 있는 지식 공유를 위한 공간으로, 파일 시스템을 통한 에이전트 간 상태 공유 메커니즘입니다.

320x100

메일박스 패턴과 원자적 클레임

안전 장치의 핵심은 메일박스 패턴입니다. 워커 에이전트는 위험도 높은 작업(파일 삭제, 프로덕션 배포 등)을 독자적으로 승인할 수 없습니다. 대신 코디네이터의 메일박스로 요청을 전송하고, 코디네이터가 평가 후 승인하거나 거부합니다.
원자적 클레임 메커니즘은 병렬 워커 간의 레이스 컨디션을 방지합니다. 여러 워커가 동시에 같은 태스크를 선점하려 할 때, 파일 락킹으로 중복 할당을 차단합니다.

워커 간 통신은 <task-notification> XML 메시지로 이루어집니다. 구조화된 포맷을 사용하여 파싱이 확실하고, 자연어 메시지의 모호함을 피합니다.

 

도메인 전문가 패턴 — 모델별 역할 분담

유출된 아키텍처는 팀 구성에서 모델별 역할 분담을 지원합니다.
리드 에이전트는 Opus급 모델이 담당합니다. 계획 수립, 작업 위임, 결과 종합 등 높은 추론 능력이 필요한 작업입니다. 전문가 워커들은 Sonnet급 모델이 병렬로 실행합니다. 실제 구현, 테스트 작성, 코드 리뷰 같은 실행 중심 작업입니다. 검증 단계에서는 독립적인 에이전트가 "문제를 찾아라"라는 임무를 받고 결과물을 적대적으로 검토합니다.
이 3단계 접근법(계획 → 위임 → 검증)은 유출 전부터 오픈소스 커뮤니티에서 독립적으로 발견된 패턴과 일치합니다. 이는 이 구조가 자율 에이전트 조율의 근본적인 해법임을 시사합니다.
 

KAIROS — 항상 켜진 데몬 에이전트

코드베이스에서 150건 이상 참조되는 KAIROS는 사용자가 자리를 비운 동안에도 에이전트가 지속적으로 작동하는 자율 데몬 모드입니다.
핵심 설계 요소로 블로킹 버짓이 있습니다. 자율적 결정에 15초 윈도우, 최대 2개 메시지로 제한됩니다. 위험 기반 행동 등급은 LOW, MEDIUM, HIGH로 분류되어 고위험 작업은 사용자 확인을 기다립니다. 긴급하지 않은 자율 작업은 디퍼드 큐에 저장되어 나중에 처리됩니다. GitHub 웹훅 구독으로 저장소 이벤트를 실시간 모니터링하고, 5분 주기 크론 스케줄로 주기적 체크가 이루어집니다.
KAIROS는 현재의 "대화형 도구"에서 "항상 켜진 자율 에이전트"로의 진화를 보여주며, 멀티 에이전트 시스템이 단일 세션을 넘어 지속적 협업 체계로 발전하는 방향을 시사합니다.
 

3계층 분산 메모리 아키텍처

멀티 에이전트 환경에서 메모리 관리는 3계층으로 운영됩니다.
1계층 코어 인덱스는 가벼운 포인터로 항상 로딩됩니다. MEMORY.md에 항목당 약 150자의 한 줄 참조가 저장됩니다. 2계층 토픽 파일은 상세한 지식을 담고 있으며 필요할 때만 로딩됩니다. 3계층 원본 트랜스크립트는 검색으로만 접근하며, 특정 식별자를 grep하는 방식으로 사용됩니다.
중요한 원칙이 있습니다. 회의적 메모리 원칙(Skeptical Memory Principle)입니다. 에이전트는 저장된 정보를 권위 있는 출처가 아닌 힌트로 취급합니다. 행동하기 전에 반드시 실제 코드베이스 상태와 대조하여 검증해야 합니다. 메모리에 "이 파일에 이 함수가 있다"고 저장되어 있어도, 그 파일이 삭제되었을 수 있기 때문입니다.
 

커뮤니티 반응과 실전 적용

유출 직후 한 개발자는 소스에서 영감을 받아 5개의 모듈을 직접 구현했다고 보고했습니다. 블로킹 버짓 강제와 디퍼드 큐, 로컬 LLM을 사용한 시맨틱 메모리 통합, 21개 정규식 패턴의 좌절 감지, 프롬프트 캐시 적중률 모니터링, 독립 에이전트의 적대적 검증 단계입니다.
Reddit r/ClaudeAI에서는 "프롬프트 기반 오케스트레이션"에 대한 찬반 논쟁이 벌어졌습니다. 찬성 측은 코드 배포 없이 행동을 수정할 수 있는 운영 유연성을 강조했고, 반대 측은 자연어 지시의 비결정론적 특성(같은 프롬프트라도 매번 다르게 동작할 수 있음)에 대한 우려를 제기했습니다.
paddo.dev의 분석에 따르면, 팀 기능의 공식 출시를 막고 있는 우려 사항으로 API 비용의 배수 증가, 조율 안정성 리스크, 파일 시스템 안전성 제어, 멀티 에이전트 실패 시 서포트 부담이 지목되었습니다.
 

정리: 유출이 가르쳐준 것

이번 유출이 멀티 에이전트 분야에 남긴 핵심 교훈을 정리합니다.
첫째, 프롬프트 기반 오케스트레이션은 장난감이 아니라 프로덕션 패턴입니다. Anthropic이 자사의 핵심 제품에 이 방식을 적용하고 있다는 사실이 이를 증명합니다.
둘째, 캐시 공유가 멀티 에이전트의 경제성을 결정합니다. Fork 모델의 프롬프트 캐시 공유 없이는 에이전트 수에 비례하여 비용이 선형 증가합니다.
셋째, 계획-위임-검증 3단계는 보편적 패턴입니다. 독립적으로 발견된 커뮤니티 패턴과 Anthropic의 내부 구현이 동일한 구조로 수렴했습니다.
넷째, 메모리는 신뢰하되 검증해야 합니다. 회의적 메모리 원칙은 멀티 에이전트 환경에서 오래된 정보로 인한 오류를 방지하는 핵심 안전장치입니다.
 
참고 자료:
- DEV Community - The Claude Code Leak: A Masterclass in AI Agent Orchestration
- paddo.dev - Claude Code's Hidden Multi-Agent System
- WaveSpeedAI - Claude Code Agent Harness Architecture
- Jock.pl - Claude Code Source Leak: What's Worth Learning for AI Agents
- Alex Kim - The Claude Code Source Leak
- Marc Bara - What Claude Code's Source Leak Actually Reveals