AI 직원으로 이루어진 "부서"를 한 명의 운영자가 굴린다는 구상, 즉 한 명은 조사하고 한 명은 작성하고 한 명은 분석한다는 바이럴 데모의 메시지는 강렬하다. 하지만 Claude Code의 실제 병렬화는 그런 헤드라인이 암시하는 것보다 더 정확히 구획되어 있고, 한계도 더 분명하다.
2026년에 Claude Code 병렬화 구조가 바뀐 흐름
Claude Code의 병렬화 구조는 작업을 동시에 실행하기 위한 네 가지 서로 다른 표면으로 이루어져 있으며, 단일 터미널 에이전트로 출시된 도구 위에 단계적으로 쌓여 왔다. Claude Code는 Claude Opus 4 및 Sonnet 4와 함께 2025년 5월 22일 정식 출시되었고, Anthropic은 Opus 4를 장시간 실행 에이전트 모델로 포지셔닝했다. 이후 2026년 상반기에 멀티 에이전트 계층이 추가됐다. Week 20에는 agent view가 도입됐고(2026년 5월 11~15일), Week 22에는 dynamic workflows가 들어왔으며(v2.1.154+, 2026년 5월 25~29일), Week 27 무렵에는 subagent가 기본적으로 백그라운드에서 실행되도록 바뀌었다.
Quick Answer: Claude Code는 병렬 실행을 위해 session subagents, agent view, agent teams, dynamic workflows라는 네 가지 표면을 제공한다. 각 subagent는 저마다 격리된 컨텍스트 창에서 실행된다. 널리 인용되는 "568 concurrent subagents"라는 수치는 Anthropic 문서가 아니라 YouTube 데모에서 나온 것이다.
Anthropic 문서는 이제 병렬 실행을 네 가지 표면으로 나눈다(공식 문서). session subagents는 격리된 컨텍스트 창에서 실행된 뒤 요약만 반환하는 위임형 작업자이고, agent view는 독립적인 백그라운드 세션을 보내기 위한 claude agents research preview이며, agent teams는 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1로 활성화되는 실험 기능으로 공유 작업 목록과 mailbox messaging을 통해 조율한다. dynamic workflows는 런타임이 백그라운드에서 실행하는 JavaScript fan-out 스크립트다. 기본 제공 subagent에는 Explore와 Plan이 포함되며, 둘 다 읽기 전용이다. 검색과 계획을 메인 컨텍스트 창 밖으로 빼내 오케스트레이터를 가볍게 유지하기 위한 설계다(subagent 문서).
초반부터 주의해야 할 숫자가 하나 있다. "568 concurrent subagents"라는 주장은 Anthropic의 어떤 표면에서도 나온 것이 아니라 YouTube 데모에서 비롯됐다. 제품이 검증한 운영 지점이 아니라, 지향점을 보여주는 조직도식 표현으로 보는 편이 맞다.
실제로 동시에 얼마나 돌릴 수 있나: 중첩 체인, 비용 배수, 그리고 568이라는 오해
Claude Code 내부의 실제 병렬성은 얼마나 큰 조직도를 그리느냐가 아니라 엔진의 하드 리밋으로 정해진다. dynamic-workflows 엔진은 동시 agent() 호출을 min(16, cpu_cores − 2)로 제한한다. 따라서 10코어 머신에서는 동시에 최대 8개의 subagent만 실행되며, 무한 루프를 막기 위해 한 번의 실행에서 전체 agent 수는 약 1,000개 근처에서 막힌다 . 바로 이 공식 하나 때문에 "568 concurrent subagents"는 오해다. 문서화된 어떤 표면도 그에 가까운 수를 한꺼번에 스케줄링하지 않는다.
중첩에도 상한이 있다. Week 24(v2.1.166~v2.1.176) 기준 subagent 체인은 최대 5단계까지만 내려갈 수 있다. 이후 패치에서 foreground subagents에도 같은 상한이 적용됐고, Week 27(v2.1.195~v2.1.201)에는 기본 백그라운드 실행 동작이 들어왔다 .
| 제한 | 값 | 도입 시점 |
|---|---|---|
동시 agent() 호출 | min(16, cpu_cores − 2) | Dynamic workflows (Week 22) |
| 실행당 전체 agent 수 | 약 1,000개 backstop | Dynamic workflows |
| 중첩 깊이 | 5단계 | Week 24 (v2.1.166+) |
| 토큰 사용량, subagent 중심 세션 | 단일 스레드 대비 약 7배 | — |
비용은 fan-out에 따라 커진다. subagent를 많이 쓰는 세션은 단일 스레드 실행보다 토큰을 대략 7배 더 쓰고, 10개의 subagent를 병렬로 돌리면 쿼터도 약 10배 빠르게 소진된다. 이를 흡수해 주는 별도 agent 과금 계층은 없다 . 실제로는 rate limit이 먼저 닿는다. 최상위 유료 사용자들도 동시 인스턴스가 5~6개만 되어도 "Server is temporarily limiting requests"를 보고한다 . 사용자가 조정할 수 있는 maxParallelAgents 같은 노브는 없다. 이를 요청한 GitHub 이슈 #15487 및 #63938은 2026년 7월 기준으로 열려 있었다 .
책임 나누기: 서브에이전트 컨텍스트 격리와 충돌 방지
컨텍스트 격리는 여러 에이전트로 구성된 부서를 안전하게 만드는 기본 단위다. 각 서브에이전트는 맞춤 시스템 프롬프트, 특정 도구 접근 권한, 독립 권한을 가진 자체 컨텍스트 창에서 실행되며, 전체 작업 상태가 아니라 요약만 오케스트레이터에 반환한다(Claude Code subagents docs). 서브에이전트끼리는 인메모리 상태를 공유하지 않기 때문에, 리서치 워커는 파일 50개를 읽고 관련 없는 모든 읽기 내용을 자기 창 안에만 둔 뒤 깔끔한 요약만 넘길 수 있다. 오케스트레이터의 컨텍스트는 가벼운 상태를 유지하고, 두 에이전트가 서로의 추론을 오염시킬 수도 없다.
Anthropic의 Claude Code 서브에이전트 문서에 따르면 “각 서브에이전트는 맞춤 시스템 프롬프트, 특정 도구 접근 권한, 독립 권한을 가진 자체 컨텍스트 창에서 실행된다”(source: Claude Code Docs).
아래의 최소 모델은 검증 및 실행 완료(exit 0)된 예시로, 경계를 보여준다. 각 워커는 자기에게 할당된 작업 컨텍스트만 볼 수 있고 부모의 비공개 키는 절대 보지 못하며, 명시적인 2026년 지식 한계를 함께 가진다.
from concurrent.futures import ThreadPoolExecutor
GLOBAL_CONTEXT = {"shared": "visible", "secret": "parent-only"}
def subagent(name, task_context):
# Each subagent receives only its own scoped context, not the full parent state.
isolated_view = dict(task_context)
isolated_view["scratchpad"] = f"{name} private notes"
return {
"agent": name,
"sees_secret": "secret" in isolated_view,
"scratchpad": isolated_view["scratchpad"],
"year_limit": isolated_view["knowledge_limit"],
}
if __name__ == "__main__":
# Minimal Claude Code-style model: concurrent subagents, isolated task contexts,
# and an explicit 2026 context/knowledge boundary carried per task.
tasks = [
("research", {"goal": "map parallel architecture", "knowledge_limit": 2026}),
("review", {"goal": "check isolation limits", "knowledge_limit": 2026}),
("test", {"goal": "validate concurrency", "knowledge_limit": 2026}),
]
with ThreadPoolExecutor(max_workers=len(tasks)) as pool:
results = list(pool.map(lambda item: subagent(*item), tasks))
print("parent_context_keys:", sorted(GLOBAL_CONTEXT))
for result in results:
print(result)역할은 YAML 프런트매터가 붙은 Markdown 파일일 뿐이다. 필수 항목은 name과 description뿐이며, 선택적으로 tools, disallowedTools, model, permissionMode, isolation, maxTurns, hooks, mcpServers를 둘 수 있다(subagents docs). 역할은 프로젝트(.claude/agents/), 사용자(~/.claude/agents/), 조직, CLI 세션(--agents) 수준으로 범위가 정해지고 우선순위도 문서화되어 있으므로, 팀은 자기 부서 구성을 저장소에서 버전 관리할 수 있다.
다만 격리는 조율이 아니다. 파일 수준의 안전성은 git worktree에서 나온다. 역할에 isolation: worktree를 설정하거나 claude --worktree <name>을 넘기면, Claude Code는 worktree-<value> 브랜치에 .claude/worktrees/<value>/ 아래의 격리된 체크아웃을 만든다(worktrees docs). 에이전트 뷰는 디스패치된 세션을 자동으로 worktree로 옮기고, /batch는 하나의 변경을 worktree로 격리된 서브에이전트들로 나누어 각각 풀 리퀘스트를 열게 한다(agents docs). 에이전트 팀은 팀원들이 같은 작업을 집어 가지 못하도록 파일 잠금 기반 작업 클레임을 추가하지만, 팀원들을 별도 worktree에 자동 배정하지는 않는다. 그래서 문서는 팀원이 코드를 편집할 때 운영자가 파일 소유권 기준으로 작업을 나누어야 한다고 명시한다(agent teams docs). 이 빈틈이 대규모 플릿을 안전하게 확장할 때의 현실적인 상한이다.
서브에이전트를 많이 띄울수록 역효과가 나는 순간: 종합 부채, 스로틀링, 48개 서브에이전트 사건
서브에이전트를 더 많이 띄운다고 처리량이 선형으로 늘지는 않는다. 작은 팬아웃을 넘어서면 통합 비용이 이득을 지워 버린다. 가장 분명한 사례는 Opus 4.6에서 2026년 6월 13일에 열린 GitHub 이슈 #68110이다. 단일 리서치 요청이 48개 이상의 백그라운드 서브에이전트를 생성했고 약 150만 개 이상의 토큰을 소모했다. 유용한 작업은 처음 3~4개가 끝냈고, 약 44개는 중복 검색을 실행했다. 이것이 날것 그대로의 종합 부채다. 오케스트레이터나 사람이 여전히 모든 출력을 읽고, 중복을 제거하고, 병합해야 하므로 대략 5개를 넘는 동시 서브에이전트부터는 병목이 생성이 아니라 종합 역량으로 이동한다.
메커니즘은 구조적이다. 임시 Task 도구 스폰은 동적 워크플로가 min(16, cpu−2) 동시 실행 상한을 도입하기 전까지 역사적으로 거의 무제한에 가까웠다. 비워크플로 호출에는 여전히 세션별 maxParallelAgents 설정이 없고, 유일한 안전장치는 수명 전체 기준 약 1,000개 에이전트 상한뿐이다. 공개 기능 요청 #15487과 #63938은 설정 가능한 동시 서브에이전트 제한을 명시적으로 요구한다. 이는 대부분의 스폰이 일어나는 지점에 아직 그 가드레일이 없다는 사실을 확인해 준다.
그렇다고 대규모 플릿을 의도적으로 운용하는 방식과 모순되는 것은 아니다. Claude Code의 창작자인 Boris Cherny는 2026년 5월 13일 Business Insider에, 보통 “각각 여러 에이전트를 가진 5~10개 세션”을 실행하고 /loops와 Routines를 통해 밤새 “수천 개” 에이전트를 돌린다고 말했다. 이는 부서라는 프레이밍과 잘 맞는다. 하지만 이는 지속적인 야간 자동화에 관한 일화이지, 문서화된 동시성 사양은 아니다. 이 구분이 중요하다. 시간에 따라 순차적으로 실행되는 것은 동시에 실행되는 것과 다르고, 깔끔하게 확장되는 쪽은 전자뿐이다.
먼저 시작할 지점: 플릿 규모 권장치와 진입점으로서의 /deep-research
작게 시작하고, 검토 역량이 따라올 때만 규모를 키우세요. 코드 편집 작업에서 안정적으로 안전한 범위는 worktree로 격리된 하위 에이전트 4~8개를 동시에 운용하는 것입니다. 그 이상부터는 컴퓨팅이 아니라 병합을 검토할 수 있는 능력이 제약이 되며, 실무자 보고도 이 상한을 일관되게 확인합니다 . 그보다 큰 팬아웃은 명백히 병렬 처리 가능한 작업, 읽기 전용 작업, 또는 파일이 엄격히 분리된 작업으로만 다루세요.
가장 진입 장벽이 낮은 시작점은 Claude Code v2.1.154 이후에 포함된 /deep-research입니다 . 이 기능은 검색을 여러 하위 에이전트로 분산하고, 주장들을 교차 검증하고 투표하며, 실패한 주장을 걸러낸 뒤, 인용이 포함된 보고서를 반환합니다. 직접 스크립트를 쓰지 않아도 동적 워크플로 오케스트레이션이 어떻게 작동하는지 보여주는 실제 예시입니다 .
정말 큰 작업, 예를 들어 500개 파일 마이그레이션이나 코드베이스 전체 감사라면 동적 워크플로 스크립트를 작성하세요. 명백히 병렬 처리 가능한 항목에는 pipeline()을 사용하고, 다음 단계로 넘어가기 전에 이전 단계의 모든 결과가 실제로 함께 필요할 때만 parallel()을 사용하세요. 비용은 모델 라우팅으로 줄이세요. 읽기 전용 검색이나 분류 역할에는 Haiku를 배정하고, 종합과 편집에는 Sonnet 또는 Opus를 남겨 두며, 역할 정의 YAML의 model 필드에서 하위 에이전트별로 지정합니다 .
핵심은 이렇습니다. 오늘 /deep-research를 실행해 보고, 코드 플릿은 8개 미만으로 유지하며, 확장 범위는 에이전트 수가 아니라 검토 처리량이 결정하게 하세요.
자주 묻는 질문
동적 워크플로를 실행하려면 어떤 버전의 Claude Code가 필요한가요?
2026년 5월 25~29일인 22주차에 배포된 Claude Code v2.1.154 이상이 필요합니다 . 워크플로 스크립트를 작성하기 전에 claude --version을 실행하세요. 이전 빌드에는 JavaScript 오케스트레이션을 실행하고 하위 에이전트를 팬아웃하는 런타임이 없으므로 agent() 호출이 실패하거나 무시됩니다. 버전이 낮다면 평소 설치 채널로 업데이트한 뒤 먼저 버전 문자열을 다시 확인하세요.
동시 하위 에이전트 568개라는 수치는 실제로 문서화된 운영 한도인가요?
아닙니다. 568이라는 숫자는 단일 YouTube 시연에서만 나온 것이며, Anthropic의 어떤 표면이나 독립적으로 색인된 출처에서도 검증되지 않았습니다 . 동적 워크플로에 대해 문서화된 현실은 “실행당 수십~수백 개 에이전트”이며, 한 순간에 실행되는 수에는 min(16, cpu_cores − 2)의 하드 캡이 있고, 워크플로 실행 전체 생애에는 총 에이전트 약 1,000개 부근의 안전장치가 있습니다 . 568은 검증된 동시성 상한이 아니라 조직도식 표현으로 보세요.
두 하위 에이전트가 같은 파일을 덮어쓰지 않게 하려면 어떻게 해야 하나요?
각 세션에 격리된 체크아웃을 제공하는 worktree를 사용하세요. 역할 정의 YAML에서 isolation: worktree를 설정하거나, 호출 시 --worktree <name>을 전달해 별도 브랜치와 체크아웃을 만듭니다 . 에이전트 팀은 다릅니다. 팀은 파일 잠금 기반 작업 클레임으로 팀원이 같은 작업을 가져가지 못하게 하지만 worktree를 자동 배정하지는 않습니다. 따라서 팀원이 코드를 편집할 때는 항상 파일 소유권 기준으로 작업을 수동 분할해야 합니다 .
하위 에이전트를 병렬로 실행하면 토큰 비용이 더 드나요?
네. 하위 에이전트를 많이 쓰는 실행은 단일 스레드 세션보다 대략 7배의 토큰을 소비하며, 병렬 하위 에이전트 10개를 실행하면 할당량이 약 10배 빠르게 소진됩니다 . 별도의 에이전트 과금 단계는 없습니다. 모든 하위 에이전트는 부모와 같은 할당량 풀에서 차감됩니다. 비용을 제어하려면 모델 라우팅을 사용하세요. 읽기 전용 검색이나 분류 역할에는 Haiku를 배정하고, 종합에는 Sonnet 또는 Opus를 남겨 두며, YAML의 model 필드를 통해 역할별로 설정합니다 .
하위 에이전트 체인의 최대 중첩 깊이는 얼마인가요?
5단계입니다. 이 한도는 24주차(v2.1.166~v2.1.176)에 도입되었고, 이후 변경으로 포그라운드 체인도 같은 제한에 맞춰지면서 백그라운드와 포그라운드 하위 에이전트 모두에 적용됩니다 . 5단계보다 깊은 체인은 오케스트레이션 계층에서 거부되므로, 에이전트가 에이전트를 만들고 그 에이전트가 또 에이전트를 만드는 식의 체인은 무한 재귀하지 않고 다섯 번째 계층에 도달하면 위임을 멈춥니다.
이 글이 도움이 되셨다면, 새 글이 올라올 때마다 이메일로 받아보세요.
