AI/Claude

Claude Code Agent Teams - Claude Code 신기능 'Agent Teams' vs 'Subagent' 차이점 살펴보기(AI 개발 팀을 내 터미널로)

안녕하세요! 갓대희 입니다.

오늘은 Claude Code의 Agent Teams 기능에 대해 알아보려고 한다.

Opus 4.6과 함께 발표된 이 기능은 여러 Claude Code 인스턴스가 팀을 이루어 병렬로 작업하는 실험적(experimental) 기능이다. 코드 리뷰, 디버깅, 대규모 리팩토링 같은 작업에서 하나의 세션으로는 한계가 있던 부분을 해결해준다.

"혼자 하면 30분 걸리는 코드 리뷰를, 3명이 나눠서 10분에 끝내자"는 개념이다.

Agent Teams란 무엇인가
- 개념과 구조
- Subagent와의 차이
- 언제 사용하면 좋은가
활성화 방법
첫 번째 팀 시작하기
- 자연어로 팀 구성
- 모델과 팀원 수 지정
디스플레이 모드
- In-process 모드
- Split pane 모드 (tmux / iTerm2)
팀 제어하기
- 태스크 관리와 할당
- 팀원과 직접 대화
- Plan Approval (계획 승인)
- Delegate 모드
아키텍처와 통신 방식
실전 활용 예제
- 병렬 코드 리뷰
- 경쟁 가설 디버깅
- 크로스레이어 기능 개발
베스트 프랙티스
Hooks로 품질 게이트 적용
트러블슈팅 및 한계점
커뮤니티 반응과 실전 팁
- 개발자 반응 하이라이트
- 한국 개발자 커뮤니티
- 엔터프라이즈 사례
- 업계 전망
경쟁 도구 비교
참고 자료

Claude Code Agent Teams
Agent Teams는 여러 Claude Code 인스턴스가 팀을 이루어 병렬로 작업하는 기능이다. 하나의 리드(lead) 세션이 작업을 분배하고, 팀원(teammate)들이 각자의 컨텍스트 윈도우에서 독립적으로 작업하며, 서로 직접 메시지를 주고받을 수 있다. 코드 리뷰, 디버깅, 새 기능 개발 등에서 병렬 탐색이 실질적 가치를 제공하는 작업에 적합하다. 이 글에서는 Agent Teams의 개념부터 설정, 실전 활용, 한계점까지 상세히 다룬다.

실험적(Experimental) 기능
Agent Teams는 기본적으로 비활성화되어 있으며, 실험적 기능이다. 세션 재개, 태스크 조율, 종료 동작 등에서 알려진 제한 사항이 있다. 프로덕션 환경보다는 개발/실험 목적으로 사용하는 것이 권장된다.
(출처: Claude Code 공식 문서 - Agent Teams)

Agent Teams란 무엇인가

Agent Teams는 여러 Claude Code 인스턴스를 하나의 팀으로 조율하는 기능이다. 하나의 세션이 팀 리드(Team Lead) 역할을 맡아 작업을 분배하고 결과를 종합(synthesize)하며, 나머지 세션들이 팀원(Teammate)으로서 각자의 영역에서 독립적으로 작업한다.

개념과 구조

Agent Teams의 핵심 아이디어는 "재능 있는 인간 팀이 일하는 것과 같다"는 것이다. 각 에이전트가 자신의 영역을 담당하고, 서로 조율하면서 더 빠르게 작업을 완료한다.

Agent Teams 구성 요소

구성 요소	역할
Team Lead	팀을 생성하고, 팀원을 스폰하며, 작업을 조율하는 메인 세션
Teammates	할당된 태스크를 처리하는 독립적인 Claude Code 인스턴스
Task List	팀원들이 claim하고 완료하는 공유 작업 목록
Mailbox	에이전트 간 직접 통신을 위한 메시지 시스템

팀과 태스크 정보는 로컬에 저장된다:

팀 설정: ~/.claude/teams/{team-name}/config.json
config.json에는 members 배열이 포함되며, 각 팀원의 이름(name), 에이전트 ID(agent ID), 에이전트 타입(agent type)이 기록된다. 팀원들은 이 파일을 읽어 다른 팀원을 발견할 수 있다.
태스크 목록: ~/.claude/tasks/{team-name}/

Subagent와의 차이

Claude Code에는 이미 Subagent라는 병렬 작업 기능이 있다. Agent Teams와 Subagent는 모두 작업을 병렬화하지만, 근본적인 차이가 있다.

비교 항목	Subagent	Agent Teams
컨텍스트	자체 컨텍스트, 결과만 호출자에게 반환	자체 컨텍스트, 독립적
통신	메인 에이전트에게만 결과 보고	팀원 간 직접 메시지 교환
조율	메인 에이전트가 모든 작업 관리	공유 태스크 목록으로 자율 조율
사용자 상호작용	메인 에이전트를 통해서만 가능	개별 팀원에게 직접 개입 가능
적합한 작업	결과만 필요한 단순 작업	토론과 협업이 필요한 복잡한 작업
토큰 비용	낮음 (결과 요약 후 반환)	높음 (각 팀원이 별도 인스턴스)

선택 기준 요약
• Subagent: 빠르고 집중된 작업자가 결과만 보고하면 될 때
• Agent Teams: 팀원들이 서로 발견한 것을 공유하고, 서로 도전하며, 자율적으로 조율해야 할 때

전환 시점(Transition Point)
병렬 Subagent를 사용하다가 컨텍스트 한계에 부딪히거나, Subagent들이 서로 통신해야 할 필요가 생긴다면 Agent Teams로 전환할 시점이다.

(출처: Claude Code - Subagent vs Agent Team 비교)

언제 사용하면 좋은가

Agent Teams가 효과적인 경우

리서치 & 리뷰: 여러 팀원이 문제의 다른 측면을 동시에 조사하고, 서로의 발견을 공유/반박
새 모듈/기능 개발: 각 팀원이 서로 충돌 없는 별도의 파일/모듈을 담당
경쟁 가설 디버깅: 팀원들이 서로 다른 가설을 병렬로 테스트하고 빠르게 원인 수렴
크로스레이어 작업: 프론트엔드, 백엔드, 테스트를 각각 다른 팀원이 담당

Agent Teams가 비효율적인 경우

순차적 작업: 앞 단계가 끝나야 다음 단계를 시작할 수 있는 작업
같은 파일 수정: 두 팀원이 같은 파일을 편집하면 덮어쓰기 충돌 발생
의존성이 많은 작업: 단일 세션이나 Subagent가 더 효과적
간단한 작업: 조율 오버헤드가 이점보다 클 수 있음

활성화 방법

Agent Teams는 기본적으로 비활성화되어 있다. 사용하려면 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS 환경 변수를 설정해야 한다.

방법 1: settings.json에 설정 (권장)

프로젝트 단위 또는 전역으로 영구 적용하려면 settings.json에 추가한다.

// .claude/settings.json (프로젝트 단위)
// 또는 ~/.claude/settings.json (전역)
{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

방법 2: 환경 변수로 설정

셸 환경에서 직접 설정할 수도 있다. 현재 터미널 세션에만 적용된다.

# 현재 셸 세션에서만 활성화
export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
claude

ex) 재시작 후 확인

첫 번째 팀 시작하기

Agent Teams를 활성화한 후, Claude에게 자연어로 팀을 구성하도록 지시하면 된다. Claude가 팀을 생성하고, 팀원을 스폰하고, 작업을 조율한다.

자연어로 팀 구성

특별한 명령어가 필요 없다. Claude에게 작업과 원하는 팀 구조를 설명하면 된다.

# 예시 1: CLI 도구 설계를 다양한 관점에서 탐색
> 개발자용 TODO 추적 CLI 도구를 설계하려고 해.
  에이전트 팀을 만들어서 3가지 관점에서 탐색해줘:
  한 명은 UX, 한 명은 기술 아키텍처, 한 명은 반대 의견 담당.

# 예시 2: PR 병렬 코드 리뷰
> PR #142를 리뷰할 에이전트 팀을 만들어줘.
  - 보안 관점 리뷰어 1명
  - 성능 영향 체크 1명
  - 테스트 커버리지 검증 1명
  각각 리뷰하고 결과를 보고해줘.

# 예시 3: 디버깅
> 사용자가 앱에서 메시지 1개 보내면 연결이 끊긴다고 보고했어.
  5명의 팀원으로 서로 다른 가설을 조사해줘.
  서로 대화하면서 상대방의 이론을 반박하는 과학적 토론처럼 진행해.

팀 시작의 두 가지 방식
• 사용자가 요청: "에이전트 팀을 만들어줘"라고 명시적으로 요청
• Claude가 제안: 작업이 병렬 처리에 적합하다고 판단하면 Claude가 팀 생성을 제안. 사용자가 승인해야 진행

어느 경우든 사용자 승인 없이 팀이 생성되지 않는다.

모델과 팀원 수 지정

Claude가 작업에 맞게 팀원 수를 자동으로 결정하지만, 직접 지정할 수도 있다.

# 팀원 수와 모델 직접 지정
> 4명의 팀원으로 이 모듈들을 병렬 리팩토링해줘.
  각 팀원은 Sonnet 모델을 사용해.

디스플레이 모드

Agent Teams는 두 가지 디스플레이 모드를 지원한다.

모드	설명	요구사항
In-process	모든 팀원이 메인 터미널 안에서 실행. `Shift+Up/Down`으로 팀원 선택	추가 설치 없음
Split panes	각 팀원이 자체 패널에서 실행. 모든 출력을 동시에 확인 가능	tmux 또는 iTerm2 필요

In-process 모드 (기본값)

추가 설정 없이 바로 사용 가능한 기본 모드다. 모든 팀원이 하나의 터미널 안에서 실행된다.

In-process 모드 조작법

키보드 단축키	동작
`Shift+Up/Down`	팀원 선택 (위/아래로 이동)
`Enter`	선택한 팀원의 세션 상세 보기
`Escape`	팀원의 현재 턴 중단(interrupt)
`Ctrl+T`	태스크 목록 토글
`Shift+Tab`	Delegate 모드 전환

Split pane 모드 (tmux / iTerm2)

각 팀원이 별도의 패널에서 실행되어, 모든 팀원의 작업을 동시에 시각적으로 모니터링할 수 있다.

# tmux 설치
brew install tmux          # macOS (Homebrew)
sudo apt install tmux      # Ubuntu/Debian
# 기타 플랫폼: https://github.com/tmux/tmux/wiki/Installing

# settings.json에 디스플레이 모드 설정 (최상위 레벨, "env" 안이 아님!)
# 유효 값: "auto" (기본값) | "in-process" | "tmux"
# ⚠️ "CLAUDE_CODE_AGENT_TEAM_MODE" 등의 환경변수는 존재하지 않음
{
  "teammateMode": "tmux"
}

# 또는 실행 시 플래그로 지정
claude --teammate-mode in-process

⚠️ Split pane 모드 제한
• VS Code 내장 터미널, Windows Terminal, Ghostty에서는 split pane 모드가 지원되지 않는다
• tmux는 macOS에서 가장 안정적으로 작동한다. iTerm2에서는 tmux -CC가 공식 권장 진입점이다
• iTerm2 사용 시 it2 CLI 설치 + Python API 활성화 필요 (iTerm2 → Settings → General → Magic → Enable Python API)
• 기본값 "auto"는 이미 tmux 세션 안에 있으면 split pane, 아니면 in-process를 자동 선택한다
• "tmux" 설정은 split pane 모드를 활성화하고, 현재 터미널에 따라 tmux와 iTerm2 중 적절한 것을 자동 감지한다

ex) 상기 내용이 있지만, 우리는 바이브 코딩의 시대에 있으니 나도, 첫 팀생성은 편하게 생성 요청 해보았다.

- 계획모드로 수행한 결과 : 1단계 팀 생성

- 2단계 태스크는 너무 많아 중략

- 3단계 팀원 스폰 전략 ( 싱글 프롬프트의 결과 이기떄문에 난 계획을 좀더 수정했지만, 데충 어떤 식으로 구성하는지 보기 좋아 초안을 캡쳐하여 올려 두었다. 난 다 opus로 할 것이다. 토큰 효율보다는 성능이 중요하고, 현시점 4.6이 맞지 않을까? 5.0 sonnet이 나왔다면 이 계획을 사용했겠지만.. )

- 4단계 : 병령 처리 전략

- 결과 요약

팀 제어하기

리드에게 자연어로 지시하면 된다. 리드가 팀 조율, 태스크 할당, 위임을 처리한다.

태스크 관리와 할당

공유 태스크 목록이 팀 전체의 작업을 조율한다. 태스크는 pending → in progress → completed의 3가지 상태를 가진다. 태스크 간 의존성도 지원되어, 선행 태스크가 완료되어야 후속 태스크를 시작할 수 있다. 의존성 해제는 자동으로 관리된다 — 팀원이 선행 태스크를 완료하면, 블록되어 있던 후속 태스크가 수동 개입 없이 자동으로 해제(unblock)된다.

태스크 할당 방식

방식	설명	예시
리드가 할당	리드에게 특정 태스크를 특정 팀원에게 할당하도록 지시	"보안 리뷰 태스크를 팀원 A에게 할당해"
Self-claim	팀원이 태스크를 완료하면 자동으로 다음 미할당 태스크를 가져감	(자동 - 파일 잠금으로 경쟁 방지)

팁: 태스크 수 관리
팀원당 5~6개의 태스크를 만들면 모두가 생산적으로 유지되고, 누군가 막히면 리드가 작업을 재할당할 수 있다. 리드가 태스크를 충분히 만들지 않으면 "작업을 더 작은 단위로 쪼개줘"라고 요청하면 된다.

팀원과 직접 대화

각 팀원은 독립 Claude Code 세션이다. 리드를 거치지 않고 팀원에게 직접 메시지를 보내 추가 지시를 하거나, 후속 질문을 하거나, 접근 방향을 변경할 수 있다.

# In-process 모드에서의 직접 대화
Shift+Down          # 팀원 2로 이동
> 이 테스트 케이스 더 자세히 분석해줘    # 직접 지시

# Split pane 모드에서는
# 팀원의 패널을 클릭해서 직접 상호작용

Plan Approval (계획 승인)

복잡하거나 위험한 작업에서는, 팀원이 실행 전에 먼저 계획을 수립하도록 요구할 수 있다. 팀원은 읽기 전용 Plan 모드에서 계획을 세우고, 리드가 승인해야만 구현을 시작한다. 리드는 자율적으로(autonomously) 승인/거부를 결정하므로, 승인 기준을 프롬프트에 명시하여 리드의 판단을 조율할 수 있다.

# Plan Approval 요구
> 인증 모듈을 리팩토링할 아키텍트 팀원을 스폰해줘.
  변경하기 전에 계획 승인을 받도록 해.

# 승인 기준 지정도 가능
> 테스트 커버리지를 포함한 계획만 승인해줘.
> 데이터베이스 스키마 변경하는 계획은 거부해.

Plan Approval 흐름

팀원이 읽기 전용 Plan 모드에서 계획 수립
리드에게 계획 승인 요청 전송
리드가 검토 후 승인 또는 거부(피드백 포함)
거부 시: 팀원이 Plan 모드에서 피드백 반영 후 재제출
승인 시: Plan 모드를 빠져나와 구현 시작

Delegate 모드

기본적으로 리드는 자신도 직접 작업을 구현할 수 있다. 하지만 때로는 리드가 팀원을 기다리지 않고 스스로 작업을 시작하는 문제가 발생한다.

Delegate 모드를 활성화하면 리드를 조율 전용으로 제한한다. 리드는 팀원 스폰, 메시지, 종료, 태스크 관리만 할 수 있고, 코드를 직접 수정할 수 없다.

Delegate 모드 활성화
팀을 먼저 시작한 후, Shift+Tab을 눌러 delegate 모드로 전환한다.

팀원 종료 및 정리

# 특정 팀원 종료
> researcher 팀원에게 종료 요청해줘
# → 팀원은 승인(graceful exit) 또는 거부(사유 설명) 가능

# 팀 전체 정리 (모든 팀원 종료 후 실행)
> 팀을 정리해줘

정리는 반드시 리드에서
팀원이 아닌 반드시 리드에서 정리(cleanup)를 실행해야 한다. 팀원의 팀 컨텍스트가 올바르게 해석되지 않아 리소스가 불완전한 상태로 남을 수 있다. 정리 전에 모든 팀원을 먼저 종료해야 하며, 아직 활성 상태인 팀원이 있으면 정리가 실패한다.

아키텍처와 통신 방식

Agent Teams의 내부 동작 방식을 이해하면 더 효과적으로 활용할 수 있다.

컨텍스트와 통신

각 팀원은 독립적인 컨텍스트 윈도우를 가진다. 스폰될 때 일반 세션과 동일한 프로젝트 컨텍스트(CLAUDE.md, MCP 서버, 스킬)와 함께 리드의 스폰 프롬프트(spawn prompt)를 전달받지만, 리드의 대화 히스토리는 이어받지 않는다.

팀원 간 정보 공유 방식

방식	설명
자동 메시지 전달	팀원이 메시지를 보내면 수신자에게 자동 전달. 리드가 폴링할 필요 없음
유휴 알림	팀원이 작업을 마치고 정지하면 자동으로 리드에게 알림
공유 태스크 목록	모든 에이전트가 태스크 상태를 확인하고 가용 작업을 claim 가능
message (1:1)	특정 팀원 한 명에게 메시지 전송
broadcast (전체)	모든 팀원에게 동시 전송. 비용이 팀 규모에 비례하므로 신중히 사용

권한(Permissions)

팀원은 리드의 권한 설정을 상속한다. 리드가 --dangerously-skip-permissions로 실행하면 모든 팀원도 동일하게 적용된다. 스폰 후에 개별 팀원의 모드를 변경할 수 있지만, 스폰 시점에 팀원별 모드를 개별 지정하는 것은 불가능하다.

활용 예제

병렬 탐색이 실질적 가치를 더하는 구체적인 시나리오들을 살펴보자.

예제 1: 병렬 코드 리뷰

한 명의 리뷰어는 한 번에 한 가지 유형의 이슈에 집중하기 쉽다. 리뷰 기준을 독립적인 도메인으로 분할하면, 보안/성능/테스트 커버리지 모두에 동시에 철저한 주의를 기울일 수 있다.

> PR #142를 리뷰할 에이전트 팀을 만들어줘.
  3명의 리뷰어를 스폰해:
  - 보안 영향 분석 담당 1명
  - 성능 영향 체크 담당 1명
  - 테스트 커버리지 검증 담당 1명
  각각 리뷰하고 결과를 보고해줘.

💡 왜 효과적인가?
각 리뷰어가 동일한 PR을 다른 필터로 분석하기 때문에, 관점이 겹치지 않고 모든 측면이 병렬로 커버된다. 리드가 마지막에 세 리뷰어의 발견 사항을 종합한다.

예제 2: 경쟁 가설 디버깅

근본 원인이 불분명한 버그에서, 단일 에이전트는 하나의 그럴듯한 설명을 찾으면 탐색을 멈추는 경향이 있다. 여러 팀원이 서로의 이론을 적극적으로 반박하게 하면, 앵커링 편향 없이 진짜 원인을 더 빠르게 찾을 수 있다.

> 사용자가 메시지 하나 보낸 후 앱이 연결을 끊는다고 보고했어.
  5명의 에이전트 팀원을 스폰해서 서로 다른 가설을 조사하게 해줘.
  서로 대화하면서 상대방의 이론을 반박하는 과학 토론처럼 진행해.
  합의가 나오면 findings 문서에 업데이트해.

토론 구조가 핵심 메커니즘
순차적 조사는 앵커링에 시달린다: 하나의 이론이 탐색되면 후속 조사가 그쪽으로 편향된다. 여러 독립 조사자가 서로를 적극적으로 반박하면, 살아남은 이론이 실제 원인일 확률이 훨씬 높다.

예제 3: 크로스레이어 기능 개발

프론트엔드, 백엔드, 테스트에 걸친 변경사항을 각 팀원이 자신의 레이어를 담당하여 병렬로 개발한다.

> 사용자 프로필 편집 기능을 추가해야 해.
  에이전트 팀을 만들어서:
  - 팀원 1: 백엔드 API (src/api/)
  - 팀원 2: 프론트엔드 UI (src/components/)
  - 팀원 3: E2E 테스트 (tests/)
  각자 담당 영역을 개발하고 서로 인터페이스를 조율해줘.

베스트 프랙티스

Agent Teams 활용 체크리스트

항목	권장사항
충분한 컨텍스트 제공	팀원은 리드의 대화 히스토리를 이어받지 않는다. 스폰 프롬프트에 태스크 관련 세부사항을 포함시켜야 한다. 좋은 스폰 프롬프트 예시: `"src/auth/의 인증 모듈을 보안 취약점 관점에서 리뷰해줘. 토큰 처리, 세션 관리, 입력 검증에 집중해. 앱은 httpOnly 쿠키에 저장된 JWT 토큰을 사용해. 이슈를 심각도 등급과 함께 보고해줘."`
적절한 태스크 크기	너무 작으면 조율 오버헤드가 이점 초과. 너무 크면 체크인 없이 너무 오래 작업해 낭비 위험. 적절: 명확한 결과물이 있는 자체 완결된 단위
파일 충돌 방지	두 팀원이 같은 파일을 편집하면 덮어쓰기가 발생한다. 각 팀원이 다른 파일 세트를 담당하도록 분할
리드 대기 요청	리드가 팀원을 기다리지 않고 직접 작업을 시작하면 "팀원들이 완료할 때까지 기다려"라고 지시
리서치부터 시작	처음이라면 코드 수정 없이 리뷰, 리서치, 버그 조사 같은 작업부터 시작하는 것을 권장
모니터링과 조정	팀원의 진행 상황을 확인하고, 효과 없는 접근을 방향 전환하며, 발견 사항을 종합한다. 무인으로 너무 오래 두면 낭비 위험 증가

⚠️ 토큰 비용 주의
Agent Teams는 단일 세션 대비 약 5~7배의 토큰을 사용한다. 각 팀원이 자체 컨텍스트 윈도우를 가지며, Plan 모드 승인 과정까지 포함하면 ~7배에 달할 수 있다.

비용 사례:

C 컴파일러 프로젝트 (10만 줄): 약 $20,000 (20억 입력/1.4억 출력 토큰, 2주간 16개 에이전트)
HN 벤치마크 (5만 줄, 4명): 단일 세션 대비 ~4배 토큰, 소요 시간 ~3배 단축

비용 최적화 전략:

팀원에 Sonnet 모델을 사용 (성능/비용 균형이 가장 좋다)
팀 규모를 최소화 (2~3명으로 시작 → 필요 시 확장)
조율이 불필요한 독립 작업은 Subagent로 대체 (더 저렴)
세션을 짧고 집중적으로 유지 (컨텍스트 압축에 의한 팀 소실 방지)

리서치, 리뷰, 새 기능 개발에서는 추가 토큰이 보통 가치가 있지만, 일상적인 작업에서는 단일 세션이 더 비용 효율적이다.

Hooks로 품질 게이트 적용

Claude Code의 Hooks 기능을 사용해 팀원의 작업 품질을 자동으로 검증할 수 있다.

Agent Teams 관련 Hooks

Hook	발동 시점	Exit Code 2의 효과
`TeammateIdle`	팀원이 유휴 상태가 되려고 할 때	피드백을 전송하고 팀원이 계속 작업하도록 함
`TaskCompleted`	태스크가 완료로 표시되려고 할 때 (Agent Teams 팀원 외에도 일반 TaskUpdate에서도 발동)	완료를 방지하고 피드백 전송

활용 예시
• TaskCompleted hook에서 린트 검사 실행 → 실패하면 exit code 2로 태스크 완료 방지
• TeammateIdle hook에서 미완료 태스크 확인 → 남은 작업이 있으면 계속하도록 지시

트러블슈팅 및 한계점

자주 발생하는 문제

문제	원인/해결
팀원이 나타나지 않음	In-process 모드에서는 이미 실행 중일 수 있다. `Shift+Down`으로 순환 확인. 작업이 팀을 필요로 할 만큼 복잡한지도 확인. Split pane 요청 시 tmux가 설치되어 있는지 `which tmux`로 확인. iTerm2의 경우 `it2` CLI 설치 및 Python API 활성화 여부 확인
권한 프롬프트가 너무 많음	팀원의 권한 요청이 리드로 올라온다. 팀원 스폰 전에 일반적인 작업을 사전 승인으로 설정하면 중단 감소
팀원이 에러에서 멈춤	`Shift+Up/Down`으로 해당 팀원 확인 후 추가 지시를 주거나, 대체 팀원을 스폰
리드가 작업 완료 전 종료	"팀원들이 끝날 때까지 기다려"라고 지시. 리드가 직접 작업을 시작하면 "위임만 해"라고 요청
tmux 세션이 남아있음	`tmux ls`로 확인하고 `tmux kill-session -t <name>`으로 정리
컨텍스트 압축 후 팀 소실	장시간 세션에서 리드의 컨텍스트가 압축되면 팀의 존재를 잊는다. 작업을 짧은 단위로 나누거나, 토큰이 차기 전에 팀을 정리하고 새로 생성한다. `PostCompact` 훅으로 팀 상태를 재주입하는 방법이 제안 중이다. (출처: GitHub Issue #23620, Open)
Delegate 모드에서 팀원 무력화	리드가 Delegate 모드일 때 스폰된 팀원이 파일 도구를 잃는 버그가 있다. 워크어라운드: Delegate 모드 진입 전에 모든 팀원을 먼저 스폰한다. (출처: GitHub Issue #24307, Open)

알려진 한계점(공식문서가 아닌 사용자 후기 기반이기 때문에 정확하지 않을 수 있습니다.)

세션 재개 불가: /resume과 /rewind는 in-process 팀원을 복원하지 않는다. 재개 후 리드가 더 이상 존재하지 않는 팀원에게 메시지를 보내려 할 수 있다. 이 경우 리드에게 새 팀원을 스폰하도록 지시해야 함
태스크 상태 지연: 팀원이 태스크 완료를 표시하지 않아 후속 태스크가 블록될 수 있음. 실제 작업이 완료되었는지 확인 후 태스크 상태를 수동으로 업데이트하거나, 리드에게 해당 팀원을 독촉하도록 지시
종료 지연: 팀원이 현재 요청이나 도구 호출을 완료한 후에야 종료됨
세션당 1팀: 리드는 한 번에 하나의 팀만 관리 가능. 새 팀을 만들려면 현재 팀을 먼저 정리해야 함
중첩 팀 불가: 팀원은 자체 팀이나 팀원을 스폰할 수 없음. 리드만 팀 관리 가능
리드 고정: 팀을 생성한 세션이 영구적으로 리드. 리더십 이전 불가
권한 스폰 시 고정: 모든 팀원이 리드의 권한 모드로 시작. 스폰 시 개별 설정 불가 (스폰 후 변경은 가능)
Split pane 터미널 제한: VS Code 내장 터미널, Windows Terminal, Ghostty에서는 split pane 모드 미지원
컨텍스트 압축 시 팀 소실: 장시간 세션에서 컨텍스트 압축이 발생하면 리드가 팀의 존재를 잊는다. PostCompact 훅으로 팀 상태를 재주입하는 해결책이 제안 중
(출처: GitHub Issue #23620, Open)
커스텀 에이전트 정의 미지원: .claude/agents/의 커스텀 에이전트를 팀원으로 사용할 수 없다. 도구 제한, 모델 선택, 전용 훅 등 세밀한 팀원 커스터마이징이 불가능
(출처: GitHub Issue #24316, 기능 요청)

CLAUDE.md는 정상 작동
팀원은 작업 디렉토리의 CLAUDE.md 파일을 정상적으로 읽는다. 이를 통해 모든 팀원에게 프로젝트별 가이드를 제공할 수 있다.

커뮤니티 반응

실제 성능 데이터

Hacker News 사용자 anupamchugh가 5만 줄 규모 코드베이스에서 공유한 벤치마크:

항목	순차 실행	Agent Teams (4명)
6개 태스크 완료 시간	~18-20분	~6분
토큰 비용	1x (기준)	~4x

(출처: Hacker News #46902368)

Anthropic이 공개한 C 컴파일러 프로젝트는 Agent Teams의 대규모 적용 사례다. 16개 에이전트가 2주에 걸쳐 약 2,000개의 Claude Code 세션을 수행하여 10만 줄 규모의 Rust 기반 C 컴파일러를 구현했다. 총 비용은 약 $20,000(20억 입력 토큰, 1.4억 출력 토큰)이었으며, 완성된 컴파일러는 GCC torture test를 포함한 대부분의 테스트 스위트에서 99% 통과율을 달성하고 Linux 6.9(x86, ARM, RISC-V), QEMU, FFmpeg, SQLite, PostgreSQL, Redis 등을 컴파일할 수 있다.

C 컴파일러 프로젝트의 기술적 세부사항

실행 환경: 각 에이전트가 독립 Docker 컨테너에서 실행되었다. 동일 Git 리포지토리를 공유하며, Git의 내장 동기화로 충돌을 방지했다
태스크 조율: 에이전트가 current_tasks/ 디렉토리에 파일을 기록하는 파일 잠금 방식으로 태스크를 claim했다. Git의 충돌 감지가 중복 할당을 자동으로 방지했다
역할 분담: 중복 감지, 성능 튜닝, 코드 생성, 설계 비평, 문서화 등 전문 역할이 에이전트별로 분배되었다
기술적 도전:
- 컨텍스트 오염: 장황한 테스트 출력이 에이전트의 집중력을 저하시켜, 최소 로깅 원칙의 테스트 하네스를 설계해야 했다
- 시간 감각 부재: Claude는 경과 시간을 인식하지 못해, --fast 플래그로 테스트 스위트의 1~10%만 에이전트별로 샘플링하는 방식을 적용했다
- 모놀리식 태스크 한계: Linux 커널 컴파일 같은 단일 거대 태스크는 병렬화가 본질적으로 어려워, GCC를 "정답 오라클"로 사용해 컴파일 유닛을 랜덤 분할하는 방식을 도입했다
알려진 한계: 16비트 x86 코드 생성기 미구현(GCC 폴백), 어셈블러/링커가 GCC 툴체인에 의존, 생성 코드 성능이 GCC 기준 이하

The Register 등 기술 미디어에서 "$20K C 컴파일러"로 주목받았으며, Hacker News에서 400건 이상의 코멘트가 달렸다.

(출처: Anthropic Engineering - Building a C Compiler)

개발자 반응 하이라이트

Addy Osmani (Google Chrome 팀): "Let the problem guide the tooling, not the other way around" — 병렬 가능한 작업에만 Agent Teams를 사용하고, 각 에이전트가 좁은 범위에 집중할수록 추론 품질이 높아진다는 핵심 인사이트를 공유했다. LLM은 컨텍스트가 확장될수록 성능이 저하되므로, 팀 분할이 곧 성능 향상이라는 논리다.
(출처: Addy Osmani 블로그, 2026-02-05)
Boris Cherny (Claude Code 창시자): X(Twitter)에서 Agent Teams를 직접 발표하며 워크플로우를 공개했다. 이 포스트가 바이럴되어 VentureBeat, Fortune 등 주요 매체에서 보도되었다.
Jaana Dogan (前 Google 엔지니어): Agent Teams 발표 직전인 2026년 1월, Claude Code가 "1년 걸린 분산 시스템 아키텍처를 1시간에 재현"했다는 포스트가 540만 뷰를 기록하며, Claude Code의 역량에 대한 개발자 인식을 급격히 높였다.
⚠️ 이 수치는 소셜 미디어 보도 기반이며, 원문 확인이 권장된다

커뮤니티가 강조하는 핵심 교훈

커뮤니티 합의: "파일 소유권이 가장 중요하다"

공식 문서에도 언급되어 있지만, 커뮤니티에서는 이것이 Agent Teams 성공의 가장 핵심적인 제약 조건이라고 강조한다.

"tasks must be file-disjoint. Two agents editing the same file means overwrites."
— Hacker News 사용자 anupamchugh

검증이 진짜 병목이다
Hacker News 사용자 CuriouslyC는 "fancy orchestration is mostly a waste, validation is the bottleneck"이라고 지적했다. 구현 속도보다 결과물 검증에 시간이 더 걸린다는 의미다. 또 다른 사용자 frde_me는 "LLMs (are) significantly better in the 'review' stage than the implementation stage"라며, 리뷰 태스크에서 Agent Teams가 특히 효과적이라고 평가했다.

(출처: Hacker News #46902368)

알려진 기술 이슈

tmux 패인 분할 버그 (미해결, 2026-02-06 보고)
Agent Teams가 기존 tmux 윈도우를 분할하면서 레이아웃이 깨지고, 4개 이상 에이전트를 동시에 스폰할 때 send-keys 명령이 충돌하여 키 입력이 깨지는(예: cd 대신 mmcd 입력) 문제가 보고되었다. 새 패인이 포커스를 가로채면서 키 입력이 잘못된 세션에 전달되는 것이 원인이다. 2026년 2월 기준 이 이슈는 아직 Open 상태이며, 새 윈도우에서 패인을 생성하는 방식으로의 수정이 제안되어 있다.

(출처: GitHub Issue #23615, Open)

Delegate 모드 + 팀원 파일 도구 상실 버그 (미해결, 2026-02-09 보고)
리드가 Delegate 모드(Shift+Tab)에서 팀원을 스폰하면, 해당 팀원이 파일 편집/생성 도구를 사용할 수 없는 문제가 보고되었다. Delegate 모드가 리드뿐 아니라 스폰되는 팀원의 도구까지 제한하는 것이 원인으로 추정된다.

워크어라운드: Delegate 모드 진입 전에 모든 팀원을 먼저 스폰한다. 팀원이 이미 실행 중인 상태에서 Delegate 모드를 켜면 팀원의 도구는 영향받지 않는다.

(출처: GitHub Issue #24307, Open)

커뮤니티 실전 팁

2명부터 시작하라: 처음부터 5명을 스폰하지 말고, 2명으로 시작해 워크플로우를 익힌 후 확장한다
구체적으로 지시하라: "이 작업을 병렬화해줘"보다 "5개의 병렬 태스크로 나눠서 실행해줘"가 훨씬 효과적이다
파일 경계를 명확히 하라: 각 팀원이 담당할 디렉토리나 파일을 프롬프트에서 명시한다
역할 이름을 활용하라: 커뮤니티에서는 architect, devils-advocate, ux-researcher 등 전문가 역할 이름을 부여하여 결과를 개선한 사례가 공유되었다
리뷰 태스크부터 시도하라: 구현보다 리뷰에서 Agent Teams가 더 안정적이라는 커뮤니티 합의가 있다. 병렬 코드 리뷰로 시작해보는 것을 권장한다

한국 개발자 커뮤니티 반응

한국은 Claude 사용 강도 기준으로 글로벌 상위권에 위치한다. Anthropic의 Economic Index(2026년 1월)에 따르면 한국은 7위에 랭크되었으며, 지난 4개월간 한국의 Claude Code 사용자 수가 6배 성장했다.

실전 활용 사례: 한국 기술 블로그에서 Agent Teams를 블로그 작성 팀(리서처+작성자+SEO)으로 테스트한 결과, 작업 시간이 50% 이상 단축되었다는 리뷰가 공유되었다
역할 변화 인식: "개발자의 역할이 '직접 코딩'에서 'AI 팀 리딩'으로 변화하고 있다"는 관찰이 여러 한국 개발자 커뮤니티에서 반복적으로 언급되었다
실전 우려: 세션 복원 불가, 토큰 비용 증가, 컨텍스트 압축 시 팀 소실 등이 주된 우려 사항이다
Anthropic 서울 오피스: 2025년 10월에 발표되어 2026년 초 개설 예정이다. 도쿄, 벵갈루루에 이은 3번째 APAC 오피스로, 한국 시장에 대한 Anthropic의 전략적 투자를 보여준다

⚠️ 커뮤니티 반응은 개별 사용자 경험 기반이며, 결과는 사용 환경에 따라 다를 수 있다

엔터프라이즈 사례

Agent Teams 자체의 엔터프라이즈 사례는 아직 제한적이지만, Claude Code 기반의 대규모 에이전트 활용 사례가 축적되고 있다. 이는 Agent Teams가 해결하려는 문제 영역과 직접 관련된다.

기업	사례
Zapier	800개 이상의 내부 Claude 기반 에이전트 운영, 89% AI 도입률
Rakuten	7시간 지속 자율 코딩 세션 수행, 시장 출시 시간 79% 개선
TELUS	13,000+ 커스텀 AI 솔루션 개발, 코드 딜리버리 30% 가속, 50만 시간 이상 절약

⚠️ 위 사례는 Claude Code 전반의 엔터프라이즈 활용이며, Agent Teams 특화 사례는 기능 출시(2026년 2월)가 최근이라 아직 제한적이다. 수치는 각 기업 발표 기반.

업계 전망

멀티에이전트 관심 폭증: Gartner에 따르면, 멀티에이전트 시스템에 대한 고객 문의가 2024년 1분기 대비 2025년 2분기에 1,445% 급증했다
엔터프라이즈 확산 전망: 2026년 말까지 엔터프라이즈 앱의 40%가 태스크별 AI 에이전트를 포함할 것으로 전망된다
Agent Teams의 위치: 이러한 멀티에이전트 트렌드의 코딩 도구 버전으로, 범용 멀티에이전트 프레임워크(CrewAI, AutoGen 등)와 달리 코딩 워크플로우에 특화되어 있다

⚠️ 시장 전망 수치는 Gartner 등 분석 기관의 추정이며, 실제 결과는 다를 수 있다

경쟁 도구 비교

Agent Teams의 포지셔닝을 이해하기 위해, 주요 AI 코딩 도구들과 비교한다.

비교 항목	Claude Agent Teams	OpenAI Codex	Cursor	Devin
멀티에이전트	네이티브 팀 협업	UI 기반 스레드 전환	단일 에이전트	위임형 실행
컨텍스트 윈도우	1M 토큰	400K 토큰	모델 기본	관리형
에이전트 간 통신	직접 메시지, 브로드캐스트	없음	없음	없음
인터페이스	터미널 네이티브	터미널/웹	IDE 통합	웹 플랫폼
핵심 강점	병렬 탐색, 팀 토론	빠른 속도	개발 플로우 보존	E2E 자동화

멀티에이전트 프레임워크와의 차이
CrewAI, AutoGen, MetaGPT, LangGraph 등 범용 멀티에이전트 프레임워크와 Agent Teams는 근본적으로 다르다:

Agent Teams: 코딩 도구 안에서 네이티브로 동작한다. 별도 프레임워크 설치나 설정 없이 Claude Code 내에서 바로 사용 가능
범용 프레임워크: 코딩 외에도 다양한 워크플로우(고객 서비스, 데이터 분석 등)를 위한 범용 도구. 더 유연하지만 설정 복잡도가 높다

⚠️ 위 비교는 2026년 2월 기준이며, 각 도구의 기능은 빠르게 변화 중이다. 최신 정보는 각 공식 문서를 참조.

참고 자료

공식 문서

Claude Code - Agent Teams 공식 문서 (이 글의 주요 출처)
Claude Code - Subagents 문서
Claude Code - Hooks 문서
Claude Code - Agent Team Token Costs
Claude Code - Git Worktrees를 이용한 병렬 세션 (Agent Teams의 수동 대안)
Claude Code - Subagent vs Agent Team 비교 (기능별 나란히 비교)

GitHub 이슈 트래커

Agent Teams 관련 주요 이슈 (2026년 2월 기준, 상태는 변경될 수 있음)

이슈	내용	상태
#23615	tmux 패인 분할 시 레이아웃 깨짐 및 키 입력 충돌	Open
#23620	컨텍스트 압축 시 팀 소실 (PostCompact 훅 해결책 제안 중)	Open
#24307	Delegate 모드에서 팀원 파일 도구 상실 (워크어라운드 있음)	Open
#24316	커스텀 에이전트 정의를 팀원으로 사용 요청 (기능 요청)	Feature Request
#24294	기존 세션을 팀에 합류시키는 기능 요청	Feature Request

업데이트 이력

2026-02-11: 커뮤니티 반응 확장 (개발자 하이라이트, 한국 커뮤니티, 엔터프라이즈 사례, 업계 전망), 경쟁 도구 비교 섹션 추가, 트러블슈팅 보강 (#23620, #24307, #24316), 토큰 비용 구체화, C 컴파일러 기술 세부사항 추가, 참고 자료 대폭 보강
2026-02-10: 공식 문서 대조 팩트체크, teammateMode 설정 오류 방지 코멘트 추가
2026-02-05: 초판 작성 (Opus 4.6 + Agent Teams 발표 기준)

저작자표시 비영리 변경금지 (새창열림)

'AI > Claude' 카테고리의 다른 글

Claude Opus 4.6 출시 리뷰 - 신규 기능, 벤치마크, 시장 반응, 개발자 후기 등 (vs GPT-5.3 Codex: AI 코딩 전쟁) (2)	2026.02.06
Claude Cowork 사용해보기 : 업무 자동화하기 - 파일 정리, 이미지 변환, 보고서 작성 등 (2)	2026.01.19
MCP 이후 또 다른 표준 - Agent Skills : Claude에서 시작해 Codex, Gemini등로 확산 (3)	2026.01.13
Auto-Claude 설치 및 기본 기능 사용해보기 - Spec-Driven Development: AI가 스펙 작성부터 코드 검증까지 (0)	2026.01.12
Claude Code 2.1 업데이트 정리 (클로드 코드 2.1 업데이트 리뷰) (3)	2026.01.12

Contents