Claude Agent Teams: 서브에이전트와 뭐가 다른가

Claude Code는 오랫동안 하나의 세션이 프론트엔드, 백엔드, 테스트를 순서대로 처리해야 했다. Agent Teams는 이 순차 처리의 병목을 없애고, 여러 Claude Code 인스턴스가 독립적으로 협업하며 복잡한 프로젝트를 병렬로 수행하게 한다. 2026년 2월 공개된 이 실험적 기능은 16개 에이전트가 $20,000의 API 비용으로 10만 줄의 C 컴파일러를 개발하는 프로젝트에서 그 가능성을 입증했다.

순차 처리의 병목에서 나온 기능

복잡한 프로젝트에서 프론트엔드·백엔드·테스트 코드를 작성해야 할 때, 하나의 Claude 세션은 각 작업을 차례로 진행할 수밖에 없었고 이는 개발 속도의 병목이 됐다. Anthropic은 Claude Opus 4.6 출시와 함께 2026년 2월 5일 Agent Teams를 공개해 이 문제를 풀었다. 여러 Claude Code 인스턴스가 각자의 컨텍스트 윈도우를 가지고 독립적으로 작업하면서도 하나의 팀으로 협업하도록 설계된 멀티 세션 오케스트레이션 시스템이다.

팀 리드, 팀원, 공유 태스크 리스트

팀 리드(Team Lead)는 하나의 Claude Code 세션이 지정돼 작업을 조율하고 태스크를 할당하며 결과를 종합한다. 팀원(Teammates)은 각자 독립적인 Claude Code 인스턴스로 실행되며 자신만의 컨텍스트 윈도우를 보유하고, 파일을 읽고 쓰고 명령을 실행하며 다른 팀원 및 팀 리드와 직접 통신한다. 공유 태스크 리스트(Shared Task List)는 모든 팀원이 접근 가능한 중앙화된 작업 목록으로 의존성 추적 기능을 포함하며, 블로킹 태스크가 완료되면 하위 태스크가 자동으로 언블록된다. 에이전트 간 메시징(Inter-Agent Messaging)은 팀 리드-팀원, 팀원-팀원이 서로 직접 메시지를 주고받는 통신 시스템이다.

⤢✕

각 팀원이 독립적인 컨텍스트 윈도우를 가지므로 한 팀원의 컨텍스트가 가득 차더라도 다른 팀원은 영향받지 않으며, 이는 대규모 프로젝트에서 컨텍스트 관리 부담을 분산시키는 핵심 메커니즘이다. 팀원들은 중앙 집중식 할당 없이 현재 작업을 완료하면 공유 태스크 리스트에서 다음 가능한 태스크를 자동으로 클레임하고, 의존성이 있는 태스크는 블로킹 태스크가 완료될 때까지 자동으로 대기한다. 디스플레이 모드는 세 가지다. 모든 팀원이 하나의 터미널 내에서 실행되는 In-process, tmux나 iTerm2의 별도 패널에 표시되는 Split panes, 환경을 자동 감지해 tmux 환경에서는 split panes를 그 외에는 in-process를 쓰는 Auto다.

서브에이전트와는 근본적으로 다른 설계

Claude Code에는 이전부터 서브에이전트(subagent) 기능이 있었지만, Agent Teams와는 설계 철학이 다르다.

⤢✕

실행 컨텍스트에서 서브에이전트는 메인 에이전트의 세션 내에서 실행돼 컨텍스트를 공유하지만, Agent Teams 팀원은 각자 완전히 독립적인 세션과 컨텍스트 윈도우를 가진다. 통신 방식도 다르다. 서브에이전트는 오직 메인 에이전트에게만 결과를 보고할 수 있고 다른 서브에이전트와 직접 통신할 수 없지만, Agent Teams 팀원은 서로 직접 메시지를 주고받는다. 작업 방식에서 서브에이전트는 메인 에이전트가 명시적으로 호출하고 결과를 기다려야 하는 동기적 방식인 반면, Agent Teams는 팀원들이 공유 태스크 리스트에서 자율적으로 작업을 선택하는 비동기적 방식이다. 사용자 상호작용도 서브에이전트는 메인 에이전트를 거쳐야 하지만 Agent Teams는 사용자가 각 팀원과 직접 상호작용할 수 있다. 적합한 시나리오로 보면 서브에이전트는 단일 작업을 위임하고 결과를 받는 간단한 경우, Agent Teams는 여러 독립적 작업을 병렬 수행하며 상호 조율이 필요한 복잡한 프로젝트에 맞는다.

활성화 방법

2026년 2월 기준 실험적(experimental) 기능으로 기본 비활성화 상태다. 환경 변수 방식은 터미널에서 다음과 같이 설정한다(영구 적용하려면 .bashrc나 .zshrc에 추가):

export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=true

설정 파일 방식은 ~/.claude/settings.json에 다음을 추가한다.

{
  "experimental": {
    "agentTeams": true
  }
}

디스플레이 모드는 다음과 같이 추가 구성할 수 있으며 agentTeamsDisplayMode의 가능한 값은 "auto"(기본값)·"in-process"·"split"이다.

{
  "experimental": {
    "agentTeams": true,
    "agentTeamsDisplayMode": "split"
  }
}

설정 적용 후 Claude Code를 재시작하면 사용할 수 있다.

어떤 작업에서 힘을 발휘하는가

공식 문서와 실제 사용 경험에 따르면 몇 가지 시나리오에서 특히 강력하다. 연구 및 리뷰(Research and Review)에서는 새 라이브러리를 검토할 때 한 팀원이 성능을, 다른 팀원이 보안을, 세 번째가 라이선스·호환성을 동시에 조사할 수 있다. 새 모듈·기능 개발에서는 결제 시스템 추가 시 한 팀원이 프론트엔드 UI를, 다른 팀원이 백엔드 API를, 세 번째가 결제 게이트웨이 통합을 각자 담당한다. 가설 기반 디버깅에서는 메모리 누수 문제를 두고 한 팀원은 캐시 관리를, 다른 팀원은 이벤트 리스너를, 세 번째는 순환 참조를 병렬로 조사해 답을 더 빨리 찾는다. 계층 간 조율에서는 REST API를 GraphQL로 마이그레이션할 때 한 팀원이 스키마·리졸버를, 다른 팀원이 프론트엔드 쿼리를, 세 번째가 통합 테스트를 각각 작성한다.

실전에서는 동일 PR을 보안·성능·테스트 세 관점에서 동시에 리뷰하게 하거나(팀 리드가 발견 사항을 하나의 통합 리뷰로 종합), 500개 상품 카탈로그를 4명이 세그먼트별로 나눠 분류·태깅하거나, 새 마이크로서비스 개발에서 DB 스키마·비즈니스 로직·API 엔드포인트·테스트를 각 팀원이 나눠 맡는 식으로 쓰인다.

$20,000짜리 C 컴파일러

Agent Teams의 능력을 가장 극적으로 보여준 사례는 Anthropic의 보안 연구원 Nicholas Carlini가 수행한 C 컴파일러 개발 프로젝트다. 16개의 에이전트를 투입해 Rust 기반 C 컴파일러를 처음부터 개발했으며 목표는 Linux 커널을 컴파일할 수 있는 수준이었다. 약 2,000개의 Claude Code 세션이 사용됐고 API 비용은 약 $20,000에 달했다. 최종적으로 100,000줄 규모의 C 컴파일러가 완성돼 Linux 6.9 커널을 x86·ARM·RISC-V 세 아키텍처에서 빌드할 수 있는 수준에 도달했다.

이 프로젝트는 Agent Teams가 소규모 기능 개발을 넘어 파싱·AST 변환·최적화·코드 생성 등 여러 전문 분야 지식이 필요한 시스템 소프트웨어 개발에도 적용될 수 있음을 보여줬다. 여기서 얻는 교훈은 세 가지다. Agent Teams는 매우 야심찬 프로젝트에도 적용 가능하다는 것, 성공을 위해서는 상당한 리소스 투입이 필요할 수 있다는 것, 그리고 명확한 태스크 분할과 의존성 관리가 핵심이라는 것이다.

속도를 얻는 대신 치르는 비용

장점은 뚜렷하다. 5명의 팀원이 작업하면 이론적으로 5배의 속도 향상을 기대할 수 있고 조율 오버헤드를 고려해도 상당한 성능 개선이 가능하다. 각 팀원이 독립적인 컨텍스트 윈도우를 가지므로 대규모 프로젝트에서 컨텍스트 한계에 부딪히는 문제가 완화되고, 각 팀원이 보안·성능·테스트 같은 특정 영역에 집중해 더 깊이 있는 분석이 가능하며, 사용자가 개별 팀원과 직접 상호작용해 필요에 따라 추가 지시를 내릴 수 있다.

한계도 분명하다. 5명의 팀이 대략 5배의 토큰을 쓰므로 비용이 크게 늘어나고, 조율 오버헤드까지 더하면 실제로는 5배 이상이 될 수 있다. 팀원 간 작업을 조율하고 충돌을 해결하며 일관성을 유지하는 데 추가 노력이 필요하고, 세션 재개·태스크 조율·종료 동작에 관한 알려진 기술적 제약도 있다. 순차적으로 진행해야 하는 작업, 동일 파일에 대한 동시 편집이 필요한 경우, 의존성이 많은 작업은 Agent Teams보다 단일 세션이나 서브에이전트가 더 효과적이다. 2026년 2월 기준 여전히 실험적 기능이므로 프로덕션 환경에서 쓰기 전에 충분한 테스트가 필요하다.

쓸지 말지 가르는 질문들

작업이 명확히 분리 가능하고 팀원들이 독립적으로 작업할 수 있을 때, 병렬 조사·리뷰가 여러 관점·가설 검증처럼 가치를 더할 때, 프로젝트가 충분히 크고 복잡해 병렬 처리의 이점이 토큰 비용을 상쇄할 때, 프론트엔드·백엔드·테스트 같은 계층 간 조율이 필요할 때 Agent Teams를 권장할 만하다. 반대로 작업이 순차적이고 각 단계가 이전 단계의 결과에 의존할 때, 동일한 파일이나 코드 영역에 대한 동시 편집이 필요할 때, 프로젝트가 작고 단순해 단일 세션으로 충분할 때, 토큰 비용이 주요 제약일 때는 지양하는 편이 낫다. "이 작업들이 진정으로 독립적인가", "병렬 처리의 속도 향상이 토큰 비용 증가를 정당화하는가", "팀원 간 상호작용이 가치를 더하는가" 세 질문에 답해보면 판단에 도움이 된다.

독립적인 컨텍스트 윈도우, 자율적 태스크 조율, 직접 통신 채널을 통해 Agent Teams는 AI 코딩 어시스턴트를 단일 에이전트의 순차 처리에서 다중 에이전트의 병렬 협업으로 전환시켰다. 작업의 독립성, 프로젝트 규모, 비용 대비 효과를 따져 적절히 활용한다면 개발 속도와 품질을 함께 끌어올릴 수 있다.