Claude Code Agent Teams는 단일 스레드 방식의 Claude Code 경험을 독립적인 Claude 인스턴스들이 서로 통신하고, 작업을 공유하며, 코드베이스에서 병렬로 작업하는 조율된 멀티 에이전트 시스템으로 변환합니다. 2026년 2월 실험적 기능으로 출시된 Agent Teams는 개발자가 AI 코딩 어시스턴트와 상호작용하는 방식의 근본적인 변화를 의미합니다. 한 번에 하나의 대화에서 전체 개발 팀을 오케스트레이션하는 방식으로 전환되는 것입니다. 이 가이드에서는 초기 설정부터 프로덕션 수준의 패턴까지, 효과적인 에이전트 팀을 구축하는 데 필요한 모든 내용을 안내합니다.
핵심 요약
Agent Teams를 사용하면 공유 프로젝트에서 함께 작업하는 여러 Claude Code 세션을 생성할 수 있습니다. 하나의 세션이 작업을 조율하는 팀 리드 역할을 하고, 팀원(Teammate) 들은 각자의 컨텍스트 윈도우에서 독립적으로 작업을 실행합니다. 단일 세션 내에서 실행되며 부모에게만 결과를 보고할 수 있는 Subagent와 달리, Teammate는 서로 직접 메시지를 주고받고, 작업 중 발견한 내용을 공유하며, 리드의 중개 없이도 조율할 수 있습니다. 환경 변수나 settings.json에서 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=true를 설정하면 활성화되며, Claude Code v2.1.32 이상이 필요합니다. Anthropic은 16개의 병렬 에이전트를 사용하여 Linux 커널을 컴파일할 수 있는 10만 줄 규모의 C 컴파일러를 구축함으로써 이 접근 방식의 잠재력을 입증했습니다. 약 2,000개 세션에 걸쳐 약 $20,000의 비용이 소요되었습니다(Anthropic 엔지니어링 블로그, 2026년 2월 문서화).
Claude Code Agent Teams란 무엇인가? (Subagent와의 차이점)
Agent Teams가 등장하기 전에는 Claude Code에서 작업을 병렬화하는 주된 방법으로 Subagent를 제공했습니다. Subagent는 단일 세션의 컨텍스트 내에서 실행되고, 범위가 정해진 작업을 수행한 후 결과를 부모 에이전트에게 반환합니다. 주 에이전트가 아키텍처에 대해 추론을 계속하는 동안 코드베이스에서 패턴을 검색하는 등, 탐색 작업을 메인 대화와 분리하는 데 유용합니다. 하지만 Subagent에는 근본적인 한계가 있습니다. 서로 대화할 수 없다는 것입니다. 에이전트 A가 에이전트 B의 작업에 관련된 무언가를 발견하더라도, 그 정보는 부모 에이전트를 거쳐야만 전달되므로 가능한 조율의 종류가 제한되는 병목 현상이 발생합니다.
Agent Teams는 각 Teammate에게 독립적인 컨텍스트, 도구 접근 권한, 그리고 다른 Teammate나 리드에게 메시지를 보낼 수 있는 능력을 갖춘 완전한 Claude Code 세션을 제공하여 이 문제를 해결합니다. 이러한 아키텍처적 차이는 Subagent로는 불가능한 패턴을 가능하게 합니다. 프론트엔드 에이전트가 백엔드 에이전트에게 API 계약 변경 사항을 직접 알리거나, 테스트 에이전트가 리드의 중계를 기다리지 않고 코드 작성자에게 실패한 테스트를 알리거나, 여러 에이전트가 직접 토론을 통해 문제에 대한 공통된 이해에 도달할 수 있습니다.
다음 표는 각 접근 방식을 언제 사용해야 하는지를 명확히 합니다. 잘못된 선택은 불필요한 복잡성(단순 검색에 Agent Teams 사용)이나 조율 병목 현상(교차 변경에 Subagent 사용)을 초래할 수 있기 때문입니다.
| 차원 | Subagents | Agent Teams |
|---|---|---|
| 세션 | 부모 세션 내에서 실행 | 각각 독립적인 전체 세션 |
| 통신 | 단방향: 자식 -> 부모만 | 양방향: 누구나 -> 누구에게나 |
| 컨텍스트 | 부모의 컨텍스트 윈도우 공유 | 독립적인 컨텍스트 윈도우 |
| 조율 | 부모가 중개자 역할 | 직접적인 P2P 메시징 |
| 최적 용도 | 집중적이고 독립적인 작업 | 복잡한 다중 파트 프로젝트 |
| 설정 | 내장, 설정 불필요 | 실험적 플래그 필요 |
| 비용 | 낮음 (단일 세션 오버헤드) | 높음 (다중 세션 오버헤드) |
Subagent를 결과를 보고하는 전문 컨설턴트를 고용하는 것으로, Agent Teams는 모든 구성원이 서로 대화할 수 있는 프로젝트 팀을 구성하는 것으로 생각하시면 됩니다. Claude Code의 기능에 이미 익숙하고 Agent Teams가 전체 도구 세트에서 어디에 위치하는지 이해하고 싶다면, Claude Code 설치 가이드에서 기본 설정을 다루고 있습니다.
Agent Teams의 내부 작동 방식
Agent Teams 아키텍처는 세 가지 핵심 구성 요소로 이루어져 있습니다. 팀 리드 세션, 하나 이상의 Teammate 세션, 그리고 작업 파일과 에이전트 간 메시징을 기반으로 한 공유 조율 레이어입니다.
팀 리드는 여러분의 주요 Claude Code 세션입니다. 팀이 무엇을 달성해야 하는지 설명하는 초기 프롬프트를 입력하는 곳입니다. Claude가 해당 작업이 병렬 작업으로 효과적일 것이라고 판단하면, Teammate 도구를 사용하여 추가 Claude Code 프로세스를 생성합니다. 생성된 각 프로세스는 자체 컨텍스트 윈도우, 도구 권한, 대화 기록을 가진 독립적인 Claude Code 세션으로 실행됩니다. 리드는 각 Teammate에게 초기 작업을 할당하고 공유 작업 시스템을 통해 진행 상황을 모니터링합니다.
Teammate는 리드로부터 초기 프롬프트를 받은 후 독립적으로 작업하는 완전히 자율적인 Claude Code 인스턴스입니다. 파일을 읽고 쓰고, 명령을 실행하고, 코드베이스를 검색하고, 모든 표준 Claude Code 도구를 사용할 수 있습니다. 중요한 점은 SendMessage 도구를 사용하여 리드와 다른 Teammate에게 메시지를 보낼 수도 있다는 것입니다. 이것이 Agent Teams를 단순한 병렬 실행과 구별하는 실시간 조율을 가능하게 합니다.
조율 레이어는 두 가지 메커니즘이 함께 작동합니다. 첫째, 모든 팀 멤버가 읽고 업데이트할 수 있는 디스크에 저장된 공유 작업 목록입니다. 작업에는 상태(pending, in_progress, completed)가 있고, 다른 작업을 차단할 수 있으며, 누가 어떤 작업을 하고 있는지에 대한 메타데이터를 포함합니다. Teammate가 작업을 완료하면 차단되었던 하위 작업들이 자동으로 다른 Teammate가 가져갈 수 있게 됩니다. 둘째, SendMessage API는 작업 상태 변경보다 더 섬세한 처리가 필요한 상황을 위한 직접적인 에이전트 간 통신을 제공합니다. 발견 사항을 공유하거나, 명확한 설명을 요청하거나, 접근 방식의 변경을 제안하는 데 사용됩니다.
이 아키텍처는 Agent Teams가 생성될 때 병렬 활동이 폭발적으로 증가하고, 작업이 완료되고 Teammate들이 발견 사항을 공유하면서 점진적으로 수렴하며, 최종적으로 리드 세션으로 축소되어 결과를 종합하고 사용자에게 제시하는 것을 의미합니다. 전체 과정은 터미널에서 확인할 수 있습니다. 에이전트 간 메시지 흐름을 관찰하고, 작업 상태 업데이트를 확인하며, 팀이 잘못된 방향으로 가면 개입할 수 있습니다.
Agent Teams 세션의 수명 주기를 이해하면 비용과 타이밍을 예측하는 데 도움이 됩니다. 생성 단계(일반적으로 10-30초)에서 리드는 Teammate 세션을 만들고 초기 작업을 할당합니다. 병렬 실행 단계(세션의 대부분, 수 분에서 수 시간)에서 Teammate들은 간헐적인 에이전트 간 메시지와 함께 독립적으로 작업합니다. 수렴 단계는 첫 번째 Teammate들이 작업을 완료하고 남은 작업을 돕거나 다른 사람의 결과물을 검토하기 시작할 때 시작됩니다. 마지막으로 종합 단계에서 리드는 모든 결과를 수집하고 충돌을 해결한 후 통합된 응답을 제시합니다. 각 단계는 서로 다른 토큰 소비 특성을 가지고 있습니다. 생성은 저렴하고, 병렬 실행이 가장 비싸며, 종합은 리드가 수행해야 하는 조정 작업의 양에 따라 달라집니다.
각 Teammate 세션은 리드 세션의 권한과 도구 접근 권한을 상속하지만, 대화 기록은 상속하지 않는다는 점이 중요합니다. Teammate들은 할당된 작업 설명과 리드가 제공하는 초기 컨텍스트만 포함된 깨끗한 컨텍스트로 시작합니다. 이는 Teammate들이 팀이 생성되기 전에 리드와 논의한 내용을 알지 못한다는 것을 의미하지만, 이것은 사실 장점입니다. 대화 초반의 암묵적 컨텍스트에 의존하는 대신 명시적이고 자체 완결적인 지시를 제공하도록 강제하기 때문입니다.
첫 번째 Agent Team 설정하기 (단계별 가이드)
Agent Teams를 실행하려면 실험적 기능 플래그를 활성화하고 팀 동작에 영향을 미치는 몇 가지 설정 옵션을 이해해야 합니다. 설정 과정은 5분도 걸리지 않지만, 여기서 내리는 설정 선택이 팀의 운영 효율성에 영향을 미칩니다.
1단계: Claude Code 버전을 확인하세요. Agent Teams는 v2.1.32 이상이 필요합니다. 터미널에서 claude --version을 실행하여 버전을 확인하세요. 업데이트가 필요하면 npm install -g @anthropic-ai/claude-code@latest를 실행하거나 설치 방법에 맞는 패키지 관리자를 사용하세요.
2단계: 실험적 플래그를 활성화하세요. Agent Teams를 활성화하는 세 가지 옵션이 있으며, 기능을 전역으로 사용할지 프로젝트별로 사용할지에 따라 선택이 달라집니다.
json// 옵션 A: 프로젝트 수준 설정 (.claude/settings.json) { "env": { "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "true" } } // 옵션 B: 사용자 수준 설정 (~/.claude/settings.json) { "env": { "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "true" } } // 옵션 C: 환경 변수 (세션 수준) // export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=true
프로젝트 수준 설정은 같은 리포지토리에서 작업하는 모든 사람이 개인 설정을 수정하지 않아도 Agent Teams가 활성화되도록 보장하므로 팀 환경에 권장됩니다. 이 설정은 세션 간에 유지되며 프로젝트와 함께 버전 관리됩니다.
3단계: Claude Code를 시작하고 팀 작업을 설명하세요. 프로젝트 디렉터리에서 Claude Code를 실행하고 자연스럽게 병렬 작업을 제안하는 프롬프트를 제공하세요. 핵심은 Claude가 팀을 어떻게 구성해야 하는지를 세세하게 관리하는 것이 아니라, 원하는 결과와 관련된 개별 작업 흐름을 설명하는 것입니다. 예를 들어 "에이전트 3개를 만들어줘"라고 하는 대신 "이 Pull Request를 보안 문제, 성능 문제, 테스트 커버리지 부족을 검토해줘. 각 영역을 독립적으로 검토하고 결과를 하나의 보고서로 통합해줘"라고 말하세요.
Claude가 프롬프트를 분석하고, 몇 명의 Teammate가 효과적일지 결정하며, 집중된 지시와 함께 생성하고, 작업 조율 구조를 설정합니다. Teammate가 생성되고 작업을 시작하면 터미널에서 메시지를 확인할 수 있습니다.
4단계: 진행 상황을 모니터링하세요. 팀이 작업하는 동안 터미널 출력에서 공유 작업 목록과 에이전트 간 메시지를 관찰할 수 있습니다. 리드 에이전트는 주기적으로 Teammate를 확인하고, Teammate가 일찍 끝나거나 차단 요소를 만나면 작업을 재할당할 수 있습니다. 팀을 안내해야 할 경우 리드 에이전트에게 메시지를 보내면, 관련 Teammate에게 관련 지시를 전달합니다.
5단계: 결과를 수집하고 검토하세요. 모든 작업이 완료되면 리드 에이전트가 모든 Teammate의 결과를 종합하여 통합된 응답을 제시합니다. Teammate들은 SendMessage 종료 프로토콜을 통해 자동으로 종료됩니다. 리드가 shutdown_request를 보내면, 각 Teammate가 shutdown_response로 확인하고, 세션이 깔끔하게 종료됩니다.
설정 중 문제가 발생하면 가장 흔한 원인은 버전 비호환(Claude Code 업데이트), 기능 플래그 누락(세 가지 가능한 설정 위치 모두 확인), 권한 오류(API 키나 구독에 여러 동시 세션을 위한 충분한 할당량이 있는지 확인)입니다. API 사용자의 경우 각 Teammate가 자체 토큰 할당량을 소비하므로 사용량 제한 소비가 상당히 가속될 수 있다는 점에 유의하세요.
또 다른 실질적인 고려 사항은 시스템 리소스입니다. 각 Teammate는 별도의 Node.js 프로세스로 실행되므로, RAM이 제한된 머신에서 대규모 팀을 생성하면 성능 문제가 발생할 수 있습니다. 대부분의 개발 머신에서는 3~5개의 동시 Teammate가 안정적으로 작동합니다. 더 큰 팀(10개 이상)이 필요하면 최소 16GB RAM이 있는 머신에서 실행하고 프로세스 메모리 사용량을 모니터링하는 것이 좋습니다. Teammate 간 통신은 로컬 파일 시스템 작업과 API 호출을 통해 이루어지므로 네트워크 대역폭은 거의 병목이 되지 않지만, Anthropic API에 대한 지연 시간은 Teammate의 메시지 응답 속도에 영향을 미칠 수 있습니다.
무료 티어로 Claude Code를 사용하는 팀의 경우, Agent Teams에 접근할 수 있지만 여러 동시 세션으로 인해 제한된 사용량 할당이 훨씬 빠르게 소진됩니다. 실질적인 작업에 Agent Teams를 활용하기 전에 Pro나 Max로 업그레이드하거나, 중간에 좌절스러운 중단을 피하기 위해 충분한 티어 할당이 있는 API 접근을 사용하는 것을 고려하세요.
실제 프로젝트를 위한 팀 아키텍처 패턴
생산적인 Agent Team과 혼란스러운 병렬 Claude 세션의 차이는 팀의 책임과 통신 패턴을 어떻게 구조화하느냐에 달려 있습니다. 커뮤니티 경험과 Anthropic 자체 테스트에서 다양한 유형의 작업에 일관적으로 효과적인 네 가지 아키텍처 패턴이 등장했습니다.
패턴 1: 리뷰 스쿼드. 이 패턴은 동일한 산출물을 여러 검토자에게 할당하며, 각각 다른 관점에서 검토합니다. 일반적인 구성은 세 명의 Teammate를 생성합니다. 하나는 보안 취약점, 하나는 성능 병목 현상, 하나는 코드 스타일과 유지보수성에 초점을 맞춥니다. 리드는 모든 검토를 수집하고 심각도별로 우선순위가 매겨진 통합 보고서를 생성합니다. 이 패턴은 검토자들이 서로 조율할 필요가 없기 때문에 Pull Request 검토, 아키텍처 평가, 문서 감사에 매우 잘 작동합니다. 같은 콘텐츠를 독립적으로 검토하고 리드가 종합을 처리합니다. 각 검토자가 대규모 코드 변경을 생성하지 않고 동일한 파일을 읽기 때문에 토큰 비용이 비교적 낮습니다.
패턴 2: 기능 빌더. 스택의 여러 레이어에 걸친 새 기능을 구축할 때, 기능 빌더 패턴은 각 레이어에 Teammate를 하나씩 할당합니다: 프론트엔드, 백엔드, 데이터베이스, 테스트. 리드는 레이어 간 인터페이스(API 계약, 데이터 스키마)를 사전에 정의한 후 각 Teammate가 독립적으로 자신의 부분을 구현하게 합니다. 여기서 에이전트 간 메시징이 중요해집니다. 백엔드 Teammate가 API 계약 조정이 필요하다는 것을 발견하면, 리드를 거치지 않고 프론트엔드 Teammate에게 직접 메시지를 보냅니다. 기능 빌더 패턴은 기능 경계가 명확하고 구성 요소 간 인터페이스를 작업 시작 전에 정의할 수 있을 때 가장 효과적입니다.
패턴 3: 디버그 스웜. 복잡한 문제를 디버깅할 때 여러 가설을 동시에 탐색하면 큰 도움이 됩니다. 디버그 스웜은 여러 Teammate를 생성하고, 각각이 근본 원인에 대한 다른 이론을 추적합니다. 하나는 최근 코드 변경을 조사하고, 다른 하나는 로그 패턴을 검토하고, 세 번째는 환경 간 설정 차이를 확인할 수 있습니다. Teammate들이 가설을 배제하거나 뒷받침하는 증거를 발견하면서 발견 사항을 서로 공유합니다. 증거가 축적되면 스웜이 자연스럽게 수렴하고, 명확한 그림이 나타나면 리드가 진단을 종합합니다. 이 패턴은 간헐적 장애, 경합 조건, 여러 서비스에 걸친 문제를 다룰 때 특히 유용합니다.
패턴 4: 크로스 레이어 조율. 가장 정교한 패턴으로, 한 영역의 변경이 여러 다른 영역에 연쇄적으로 영향을 미치는 작업을 처리합니다. 예를 들어 API 레이어, 데이터베이스 마이그레이션, 프론트엔드 컴포넌트, 테스트 픽스처에 나타나는 핵심 데이터 모델의 이름을 변경하는 경우입니다. 리드는 변경 순서를 계획하고, 각 레이어를 Teammate에게 할당하며, Teammate들은 직접 메시징을 통해 구체적인 변경 사항을 조율합니다. 이 패턴은 가장 많은 에이전트 간 통신이 필요하며, 명확한 작업 종속성의 혜택을 받습니다. 데이터베이스 마이그레이션이 API 변경 전에 완료되어야 하고, API 변경이 프론트엔드 업데이트 전에 완료되어야 합니다.
실제 사례를 통해 이러한 패턴의 작동 방식을 설명하겠습니다. 한 문서화된 사례에서 개발자가 Claude에게 "에이전트 팀을 사용해서 localhost:4321에서 내 블로그에 대한 QA를 진행해줘"라고 프롬프트를 보냈습니다. 리드는 다섯 개의 Sonnet 기반 Teammate를 생성하고, 각각 다른 QA 관점을 할당했습니다: 핵심 페이지 응답, 블로그 포스트 렌더링, 내비게이션과 링크, RSS/사이트맵/SEO, 접근성. Teammate들은 독립적으로 작업했습니다. 페이지 응답 에이전트는 16개 페이지에서 HTTP 200 상태 코드를 확인하고, 링크 체커는 146개 내부 URL을 검증하며, 접근성 에이전트는 HTML class 속성에 문자열화된 불리언 값과 테마 토글의 누락된 ARIA 레이블 같은 문제를 발견했습니다. 리드는 모든 결과를 10개 이슈(주요 4개, 중간 2개, 경미 4개)의 우선순위 보고서로 종합했습니다. 단일 에이전트가 순차적으로 수행했다면 훨씬 더 오래 걸렸을 작업입니다.
자주 간과되지만 강력한 기능 중 하나는 계획 승인 게이트입니다. Teammate를 생성할 때 변경 사항을 적용하기 전에 구현 계획을 승인받도록 요구할 수 있습니다. Teammate는 읽기 전용 계획 모드에서 작업합니다. 파일을 읽고 코드베이스를 분석할 수 있지만, 리드(또는 사용자)가 계획을 승인할 때까지 아무것도 수정할 수 없습니다. 계획이 거부되면 Teammate는 피드백을 받고 접근 방식을 수정합니다. 코드가 수정되기 전에 사람의 확인이 필요한 고위험 변경 사항에 유용하면서도, Agent Teams가 제공하는 병렬 분석의 이점을 누릴 수 있습니다.
이러한 패턴 중 선택은 두 가지 요소에 따라 달라집니다. 작업 흐름의 상호작용 정도(낮은 상호작용은 리뷰 스쿼드, 높은 상호작용은 크로스 레이어)와 새 코드를 생성하는지 기존 코드를 수정하는지(새 코드는 기능 빌더, 기존 코드는 디버그 스웜 또는 크로스 레이어)입니다. 대부분의 프로젝트에서는 더 복잡한 조율 패턴을 시도하기 전에 리뷰 스쿼드 패턴으로 Agent Teams에 익숙해지는 것이 좋습니다.
통신 및 작업 관리 심층 분석
Agent Teams의 효과성은 Teammate들의 통신 방식과 작업 구조화 방식에 크게 좌우됩니다. Teammate에게 제공되는 통신 프리미티브를 이해하면 더 나은 조율 패턴으로 이어지는 프롬프트를 설계하는 데 도움이 됩니다.
SendMessage는 주요 통신 도구입니다. 다양한 조율 목적을 제공하는 여러 메시지 유형을 지원합니다. 표준 메시지는 한 에이전트에서 다른 에이전트로 텍스트를 전달합니다. 발신자가 수신자(이름 또는 팀 역할별)와 메시지 내용을 지정합니다. 브로드캐스트 메시지는 모든 Teammate에게 동시에 전송되며, 리드가 방향 변경을 발표하거나 모든 사람에게 관련된 발견 사항을 공유할 때 유용합니다. 종료 요청과 응답은 Teammate가 작업 중간에 중단되지 않도록 보장하는 원활한 종료 프로토콜을 형성합니다.
Anthropic이 내린 중요한 설계 결정은 SendMessage가 유일한 직접 통신 채널이라는 것입니다. 공유 메모리, 공유 클립보드, 또는 한 Teammate가 다른 Teammate의 대화 기록을 읽을 수 있는 기능은 없습니다. 이 제약은 의도적입니다. 통신이 명시적이고 구조화되도록 강제하여, 팀 동작을 예측할 수 없게 만드는 암묵적 결합을 방지합니다. Teammate A가 Teammate B의 정보가 필요하면 메시지로 요청해야 하고, Teammate B는 관련 컨텍스트를 응답해야 합니다. 이를 통해 정보 흐름을 감사하고 디버그할 수 있습니다.
작업 관리는 조율의 구조적 백본을 제공합니다. 작업은 TaskCreate로 생성하고, TaskUpdate로 업데이트하며, TaskList와 TaskGet으로 조회합니다. 각 작업에는 주제, 설명, 상태, 소유자, 선택적 종속성 링크가 있습니다. 종속성 시스템은 특히 강력합니다. 작업 B가 작업 A에 의해 차단됨을 지정할 수 있으며, 작업 A가 완료되면 작업 B가 자동으로 Teammate가 가져갈 수 있게 됩니다.
다음은 리드가 기능 빌더 팀을 위한 작업을 구조화하는 예시입니다.
pythonTaskCreate(subject="Define API contract for user profiles", description="...") TaskCreate(subject="Implement backend API endpoints", description="...", addBlockedBy=["task-1"]) # API 계약이 정의될 때까지 차단됨 TaskCreate(subject="Build frontend profile components", description="...", addBlockedBy=["task-1"]) # 마찬가지로 API 계약까지 차단 TaskCreate(subject="Write integration tests", description="...", addBlockedBy=["task-2", "task-3"]) # 두 구현 모두 완료될 때까지 차단
이 종속성 구조는 계약이 정의되기 전에 어떤 Teammate도 구현을 시작하지 않도록 보장하며, 프론트엔드와 백엔드가 모두 완료된 후에만 테스트를 시작합니다. Teammate들은 현재 작업을 마치면 다음 사용 가능한 차단 해제된 작업을 자동으로 가져가므로, 리드의 개입 없이도 팀이 자동으로 부하를 분산합니다.
흔한 실수는 작업 종속성 그래프를 과도하게 복잡하게 만드는 것입니다. 종속성은 실행 순서에 대한 선호를 표현하는 것이 아니라, 실제 순서 요구 사항을 반영해야 합니다. 종속성을 과도하게 지정하면 Teammate들이 차단된 작업의 해제를 기다리는 시간이 늘어나 병렬성이 감소합니다. 반대로 종속성을 부족하게 지정하면 두 Teammate가 겹치는 코드를 동시에 수정할 때 충돌이 발생합니다. 최적의 지점은 데이터 또는 파일 수준 종속성이 있는 곳에만 종속성을 만들고, Teammate에게 명확한 파일 소유권을 부여하는 넓은 작업 범위 정의를 사용하는 것입니다.
대규모 코드베이스를 처리하는 팀의 경우, 에이전트 간 통신량을 모니터링하면 유용한 상태 신호가 됩니다. 에이전트가 작업당 몇 개 이상의 메시지를 보내면, 보통 작업 분해가 너무 세분화되어 에이전트들이 생산 대신 조율에 과도한 토큰을 소비하고 있음을 나타냅니다. 이상적인 패턴은 생성 후 간략한 메시지 버스트(에이전트들이 작업을 이해했음을 확인), 실행 중 간헐적 메시지(발견 사항 공유 또는 설명 요청), 종합 중 최종 메시지 라운드를 보여줍니다. Claude Code의 API 기능을 사용하여 애플리케이션을 구축하는 개발자의 경우, MCP 통합 가이드에서 Model Context Protocol을 통해 Agent Teams를 맞춤형 도구로 확장하는 방법을 설명합니다.
비용 분석 - Agent Teams의 실제 비용은 얼마인가?
Agent Teams 비용을 이해하는 것은 병렬 실행에 대한 투자가 가치 있는 경우와 단일 Claude Code 세션으로 충분한 경우를 결정하는 데 필수적입니다. Agent Teams의 비용 모델은 이론적으로는 간단하지만 실제 지출에 큰 영향을 미치는 미묘한 차이가 있습니다.
기본 공식은: 총 비용 = Teammate 수 x Teammate당 평균 토큰 수 x 토큰당 가격입니다. 각 Teammate는 파일 읽기, 추론, 출력 생성, 다른 Teammate와의 통신을 위해 토큰을 소비하는 독립 세션입니다. 리드 세션도 조율 오버헤드를 위해 토큰을 소비합니다. 고정 월 예산이 있는 구독 기반 사용과 달리, API 기반 Agent Teams는 토큰당 엄격하게 과금되므로 비용이 수행된 작업량에 정비례합니다.
Anthropic의 C 컴파일러 실험은 현재 이용 가능한 가장 구체적인 비용 벤치마크를 제공합니다. 약 2,000개의 Claude Code 세션에 걸쳐 16개의 병렬 Opus 4.6 에이전트를 사용하여, x86, ARM, RISC-V 아키텍처에서 Linux 커널을 컴파일할 수 있는 10만 줄 규모의 Rust 기반 C 컴파일러를 제작했습니다. 총 비용은 API 사용료로 약 $20,000이었습니다(Anthropic 엔지니어링 블로그, 2026년 2월 검증). 이는 생성된 코드 줄당 약 $0.20, 세션당 평균 $10에 해당합니다. 이것은 가장 비싼 모델(Opus)을 매우 복잡한 작업에 사용한 고급 시나리오이며, 대부분의 개발자 워크플로우는 이보다 훨씬 적은 비용이 들 것입니다.
모델 선택이 비용에 크게 영향을 미칩니다. Opus 4.6 대신 Sonnet 4.6을 사용하면 토큰당 비용이 40% 절감됩니다(Sonnet은 MTok당 $3/$15, Opus는 $5/$25, claude.com/pricing에서 2026년 3월 검증). 코드 리뷰, 문서 생성, 테스트 작성과 같은 많은 Agent Teams 작업에서 Sonnet은 비용을 상당히 절감하면서도 Opus와 유사한 품질을 제공합니다. 실용적인 전략은 리드 에이전트에는 Opus(조율을 위해 가장 강력한 추론이 필요)를, Teammate에는 Sonnet(더 집중적이고 잘 정의된 작업을 실행)을 사용하는 것입니다.
비용 최적화 전략으로는 작업을 의미 있게 병렬화할 수 있는 최소한의 Teammate 수로 팀 크기를 제한하고(3~5개가 보통 최적), 각 Teammate에 명확한 범위 경계를 설정하여 중복 탐색을 방지하고, 작업 종속성을 사용하여 차단된 작업에 불필요한 토큰 소비를 피하며, Claude Console의 실시간 대시보드를 통해 토큰 사용량을 모니터링하는 것이 있습니다.
Agent Teams를 자주 사용하며 비용을 더 절감하고 싶은 개발자의 경우, laozhang.ai와 같은 서드파티 API 라우팅 서비스는 Anthropic과 직접 API 티어 진행을 관리하는 것보다 잠재적으로 낮은 오버헤드로 Claude 모델에 대한 토큰당 과금 접근을 제공합니다. 이 접근 방식은 사용 패턴이 변동적인 팀에 특히 비용 효율적일 수 있습니다. 어떤 주는 Agent Teams를 많이 사용하고 다른 주에는 최소한으로 활동하는 경우, 미사용 구독 용량에 대한 비용을 피할 수 있습니다.
자주 간과되는 또 다른 비용 요소는 프롬프트 캐싱입니다. 여러 Teammate가 동일한 대용량 파일을 읽을 때(리뷰 스쿼드 패턴에서 흔함) 프롬프트 캐싱이 효과적 토큰 비용을 크게 줄입니다. Anthropic의 캐시 인식 ITPM 시스템은 캐시된 입력 토큰이 사용량 제한에 포함되지 않으며 기본 입력 가격의 10%로 과금됨을 의미합니다. 공통 코드베이스 컨텍스트를 공유하는 Agent Teams의 경우, 효과적인 캐싱은 순수 구현 대비 입력 토큰 비용을 50-80% 절감할 수 있습니다. 핵심 최적화는 Teammate 프롬프트를 구성할 때 공유 컨텍스트(시스템 지시와 공통 참조 파일 등)를 각 요청의 시작 부분에 배치하여 Teammate 간 캐시 적중률을 극대화하는 것입니다. 캐싱과 사용량 제한의 상호작용에 대한 더 깊은 이해가 필요하면 Claude Code 사용량 제한 가이드를 참조하세요.
| 시나리오 | 에이전트 수 | 모델 | 예상 토큰 | 예상 비용 |
|---|---|---|---|---|
| PR 리뷰 (3개 관점) | 3 | Sonnet 4.6 | ~50만 총 | ~$2-5 |
| 새 기능 (3개 레이어) | 4 | 혼합 Opus+Sonnet | ~200만 총 | ~$15-30 |
| 디버그 스웜 (4개 가설) | 4 | Sonnet 4.6 | ~100만 총 | ~$5-12 |
| 대규모 리팩토링 (크로스 레이어) | 5 | 혼합 | ~300만 총 | ~$25-50 |
| C 컴파일러 (Anthropic 사례) | 16 | Opus 4.6 | ~수십억 | ~$20,000 |
Anthropic C 컴파일러 실험에서 얻은 교훈
대규모 Agent Teams의 가장 교훈적인 사례는 Anthropic 자체 엔지니어링 팀에서 나왔습니다. 16개의 Opus 4.6 에이전트를 사용하여 처음부터 Rust로 C 컴파일러를 구축한 것입니다. 2026년 2월 Anthropic 엔지니어링 블로그에 문서화된 이 실험은 멀티 에이전트 개발의 놀라운 잠재력과 실질적 한계를 모두 드러냈습니다. 핵심 교훈은 개발자가 자신의 Agent Teams를 구조화하는 방법에 직접 적용됩니다.
교훈 1: 병렬화는 자연스럽게 분해 가능한 문제에 가장 잘 작동합니다. C 컴파일러 프로젝트가 성공한 이유는 컴파일이 본질적으로 모듈화되기 때문입니다. 파싱, 타입 검사, 코드 생성, 최적화를 어느 정도 독립적으로 개발하고 테스트할 수 있습니다. 팀은 많은 개별 실패 테스트가 있을 때 가장 높은 병렬성을 달성할 수 있었습니다. 각 에이전트가 조율 없이 다른 실패 테스트를 선택하여 작업할 수 있었기 때문입니다. 테스트 스위트가 99% 통과율에 도달하고 나머지 실패가 서로 관련되었을 때, 에이전트들이 더 신중하게 조율해야 했기 때문에 병렬성은 자연스럽게 감소했습니다. 개발자를 위한 시사점은 Claude가 분해를 알아서 해주기를 바라는 대신, 팀을 생성하기 전에 프로젝트에서 자연스럽게 병렬 가능한 경계를 식별하는 것입니다.
교훈 2: 오라클이 있으면 모든 것이 쉬워집니다. Linux 커널 컴파일 도전에서 팀은 GCC를 신뢰할 수 있는 컴파일러 오라클로 사용했습니다. 대부분의 커널 파일을 GCC로 컴파일하고 몇 개의 파일만 새 컴파일러로 컴파일하는 테스트 하네스를 구축하여, 각 에이전트가 서로 다른 파일의 서로 다른 버그를 동시에 수정하는 데 집중할 수 있게 했습니다. 출력을 신뢰할 수 있는 참조와 비교하는 이 패턴은 컴파일러를 넘어 일반화됩니다. API를 리팩토링하는 경우 이전 구현을 새 구현과 함께 실행하고 에이전트가 동작 동등성을 검증하게 하세요. 데이터베이스를 마이그레이션하는 경우 이전 스키마와 새 스키마 간의 쿼리 결과를 비교하세요. 오라클 패턴은 개방형 품질 문제를 에이전트가 독립적으로 실행할 수 있는 폐쇄 루프 검증 사이클로 변환합니다.
교훈 3: 통신 오버헤드는 실재하지만 관리 가능합니다. 16개 에이전트가 있으면 통신 혼란의 가능성이 상당합니다. Anthropic 팀은 구조화된 작업 종속성이 불필요한 에이전트 간 잡담을 줄여준다는 것을 발견했습니다. 에이전트들이 자신이 무엇을 작업하고 있는지 끊임없이 메시지를 보내는 대신, 작업 시스템이 누가 무엇을 하고 있는지에 대한 가시성을 제공했습니다. 직접 메시징은 진정한 발견이나 충돌, 예를 들어 두 에이전트가 동일한 파일을 수정하려 할 때 등에만 사용되었습니다. 자신의 팀에서도 과도한 통신을 장려하려는 유혹을 억제하세요. 대부분의 Agent Teams 작업은 지속적인 토론보다는 "체크포인트가 있는 분할 정복" 접근 방식에서 더 많은 이점을 얻습니다.
교훈 4: 토큰 비용은 출력뿐만 아니라 탐색에 따라 확장됩니다. 10만 줄의 코드에 $20,000의 비용이 높아 보일 수 있지만, 이는 실제 C 코드의 전체 복잡성을 처리하는 컴파일러를 구축하는 데 필요한 광범위한 탐색과 디버깅을 반영합니다. 각 에이전트는 단순히 코드를 작성한 것이 아니라, 기존 코드를 읽고, 버그에 대한 가설을 세우고, 수정 사항을 테스트하고, 실패한 시도를 되돌리고, 반복했습니다. 이러한 탐색적 작업의 토큰 비용이 최종 출력 비용을 훨씬 능가합니다. 더 직관적인 작업(예: 명확한 명세가 있는 기능 구현)에 종사하는 팀은 훨씬 낮은 비용 대 출력 비율을 경험할 것입니다.
교훈 5: 핵심 의사결정 지점에서의 인간 개입이 팀 효과를 배가합니다. C 컴파일러가 대부분 자율적으로 구축되었지만, Anthropic 팀은 아키텍처 결정 시점에서의 간헐적인 인간 가이드가, 예를 들어 코드 생성에 대한 경쟁적 접근 방식 중 선택하는 것이, 에이전트가 비최적 경로를 탐색하는 데 수천 토큰을 소비하는 것을 방지했다는 것을 발견했습니다. 가장 효과적인 워크플로우는 완전 자율이 아니라 반자율적이었습니다. 에이전트들은 잘 정의된 하위 작업을 독립적으로 수행하고, 인간은 해당 하위 작업을 프레이밍하는 높은 수준의 전략적 결정을 내립니다. 이 하이브리드 접근 방식은 양측의 강점을 존중합니다. 에이전트는 잘 정의된 작업을 병렬로 실행하는 데 뛰어나고, 인간은 전략적 판단과 장기적 계획에 뛰어납니다.
교훈 6: Agent Teams의 가치는 프로젝트 복잡성에 따라 복리로 증가합니다. 단순한 기능 추가의 경우, 단일 Claude Code 세션이 팀을 생성하는 것보다 보통 더 빠르고 저렴합니다. 손익분기점, 즉 Agent Teams가 순차 작업보다 달러당 더 나은 결과를 제공하는 지점은, 작업이 진정으로 병렬적인 작업 흐름(다른 파일, 다른 관심사)을 포함하거나 작업이 여러 관점(코드 리뷰, 아키텍처 평가)에서 이점을 얻을 때 발생합니다. C 컴파일러 프로젝트는 병렬로 디버그할 수 있는 수천 개의 독립적인 테스트 케이스가 포함되어 있어 손익분기점을 훨씬 넘어섰습니다. 대부분의 개발자 워크플로우에서 손익분기점은 약 3~5개의 진정으로 독립적인 하위 작업입니다. 그보다 적으면 팀 조율 오버헤드가 병렬화 이점을 능가합니다.
자주 묻는 질문
일반적인 프로젝트에 몇 명의 Teammate를 사용해야 하나요?
대부분의 작업에서 3~5명의 Teammate로 시작하세요. 리뷰 스쿼드 패턴은 3명의 전문 리뷰어로 잘 작동하며, 기능 빌더 패턴은 일반적으로 4명이 필요합니다(레이어당 하나 더하기 테스트). 5명 이상은 조율 오버헤드가 병렬화 이점을 능가하기 시작하므로 처리량이 거의 향상되지 않습니다. 예외는 Anthropic의 컴파일러 실험처럼 고도로 분해 가능한 작업으로, 16개 에이전트가 효과적이었던 이유는 각각이 조율이 거의 필요 없는 진정으로 독립적인 테스트 케이스를 작업했기 때문입니다.
Agent Teams는 Pro나 Max 구독에서 작동하나요, 아니면 API 접근이 필요한가요?
Agent Teams는 구독 플랜과 직접 API 접근 모두에서 작동합니다. 구독(Pro $20/월 또는 Max $100-200/월)을 사용할 경우, 각 Teammate가 공유 구독 할당량에서 토큰을 소비하므로 단일 세션보다 사용량 제한에 더 빨리 도달합니다. API 접근은 Teammate당 토큰 예산에 대한 보다 세밀한 제어를 제공하고 구독 할당량 상한을 피할 수 있어, 많은 Agent Teams 사용에 더 적합합니다. 접근 방법에 관계없이 실행하려는 병렬 세션 수에 충분한 할당량이 있는지 확인하세요.
두 Teammate가 동일한 파일을 동시에 편집하려 하면 어떻게 되나요?
Claude Code는 표준 파일 잠금 및 충돌 해결 메커니즘을 통해 동시 파일 접근을 처리합니다. 실제로 잘 구조화된 작업 종속성은 한 번에 하나의 Teammate만 특정 파일을 작업하도록 하여 대부분의 충돌을 방지합니다. 충돌이 발생하면 리드 에이전트가 일반적으로 종합 중에 감지하고 한 Teammate의 변경 사항을 우선시하여 해결합니다. 겹치는 영역이 아닌 개별 파일이나 디렉터리에 대한 책임을 각 Teammate에 할당하여 파일 소유권 중심으로 작업을 구조화하면 충돌을 최소화할 수 있습니다.
팀 설정을 저장하고 재사용하는 방법이 있나요?
현재 Agent Teams에는 사전 정의된 팀 구조를 위한 내장 템플릿이나 설정 파일이 없습니다. 하지만 선호하는 팀 패턴을 설명하는 CLAUDE.md 지시사항을 만들거나 특정 팀 아키텍처를 인코딩하는 커스텀 스킬을 작성하여 재사용 가능한 설정을 구현할 수 있습니다. 커뮤니티에서도 GitHub gist와 리포지토리를 통해 공유되는 설정 패턴을 개발했습니다. 기능이 실험적 상태를 벗어나면 더 구조화된 설정 옵션이 예상됩니다.
Agent Teams는 git 브랜치 및 버전 관리와 어떻게 상호작용하나요?
각 Teammate는 리드와 동일한 작업 디렉터리와 git 상태에서 작동합니다. 즉, 모든 Teammate가 동일한 브랜치, 커밋되지 않은 변경 사항, 파일 상태를 봅니다. 복잡한 작업의 경우, 리드는 Teammate에게 git worktree를 사용하여 격리 모드로 작업하도록 지시할 수 있습니다. 이렇게 하면 각 Teammate에게 리포지토리의 별도 복사본이 제공됩니다. 병렬 작업 중 머지 충돌을 방지하지만 마지막에 통합 단계가 필요합니다. Teammate들이 서로 다른 파일을 수정하는 더 간단한 작업에서는 메인 작업 디렉터리에 직접 동시 접근하는 것이 잘 작동합니다.
Agent Teams는 프로덕션 워크플로우에 충분히 안정적인가요?
Agent Teams는 현재 실험적으로 분류되어 있어, Anthropic이 사전 공지 없이 API, 동작 또는 가용성을 변경할 수 있습니다. 프로덕션 워크플로우의 경우 이 실험적 상태에는 위험이 따릅니다. Claude Code 업데이트가 팀 조율 방식을 변경하거나 SendMessage 프로토콜에 호환성 깨지는 변경을 도입할 수 있습니다. 그러나 많은 개발자가 코드 리뷰, 기능 개발, 디버깅을 위한 일상 워크플로우에서 Agent Teams를 성공적으로 사용하고 있습니다. 신뢰성이 중요한 완전 자동화된 CI/CD 파이프라인보다는 부분적 실패가 허용되고 수동 개입이 가능한 작업에 사용하는 것이 권장됩니다. 현재 알려진 제한 사항으로는 세션 재개 불가(/resume 명령이 Teammate를 복원하지 않음), 세션당 하나의 팀만 가능, 중첩 팀 불가(Teammate가 자체 팀을 생성할 수 없음), Teammate가 가끔 작업을 완료로 표시하지 않아 종속 작업을 차단할 수 있음 등이 있습니다. 이러한 제한 사항은 기능이 실험적 상태를 벗어나면서 개선될 것으로 예상됩니다.