SpyBara
Go Premium

agent-teams.md 2026-06-16 21:57 UTC to 2026-06-17 17:02 UTC

149 added, 83 removed.

2026
Tue 30 06:03 Mon 29 23:02 Sat 27 01:01 Fri 26 23:00 Thu 25 23:58 Wed 24 22:02 Tue 23 22:00 Mon 22 23:59 Fri 19 22:58 Thu 18 22:00 Wed 17 17:02 Tue 16 21:57 Mon 15 23:02 Sat 13 21:59 Fri 12 22:00 Thu 11 23:01 Wed 10 23:57 Tue 9 06:34 Mon 8 06:52 Sat 6 06:24 Fri 5 06:45 Thu 4 06:52 Wed 3 06:53 Tue 2 06:51

Claude Code ì„žì…˜ 팀 조윚하Ʞ

공유 작업, 에읎전튞 간 메시징, 쀑앙 집쀑식 ꎀ늬륌 통핎 핚께 작동하는 여러 Claude Code 읞슀턎슀륌 조윚합니닀.

에읎전튞 팀을 사용하멎 핚께 작동하는 여러 Claude Code 읞슀턎슀륌 조윚할 수 있습니닀. 한 섞션읎 팀 늬더 역할을 하여 작업을 조윚하고, 작업을 할당하며, 결곌륌 종합합니닀. 팀원듀은 독늜적윌로 작동하며, 각각 자신의 컚텍슀튞 윈도우에서 작동하고, 서로 직접 통신합니닀.

닚음 ì„žì…˜ 낎에서 싀행되고 메읞 에읎전튞에게만 볎고할 수 있는 subagents와 달늬, 늬더륌 거치지 않고 개별 팀원곌 직접 상혞작용할 수도 있습니닀.

읎 페읎지에서 닀룚는 ë‚Žìš©:

에읎전튞 팀을 사용할 때

에읎전튞 팀은 병렬 탐색읎 싀질적읞 가치륌 더하는 작업에 가장 횚곌적입니닀. 전첎 시나늬였는 사용 사례 예시륌 찞조합니닀. 가장 강력한 사용 사례는 닀음곌 같습니닀:

  • 연구 및 검토: 여러 팀원읎 묞제의 닀양한 잡멎을 동시에 조사한 후 서로의 발견을 공유하고 도전할 수 있습니닀
  • 새로욎 몚듈 또는 Ʞ능: 팀원듀읎 각각 별도의 부분을 소유하멎서 서로 간섭하지 않을 수 있습니닀
  • 겜쟁하는 가섀로 디버깅하Ʞ: 팀원듀읎 닀양한 읎론을 병렬로 테슀튞하고 더 빠륎게 답에 수렎합니닀
  • 교찚 계잵 조윚: 프론튞엔드, 백엔드, 테슀튞에 걞친 변겜 사항윌로, 각각 닀륞 팀원읎 소유합니닀

에읎전튞 팀은 조윚 였버헀드륌 추가하고 닚음 섞션볎닀 훚씬 더 많은 토큰을 사용합니닀. 팀원듀읎 독늜적윌로 작동할 수 있을 때 가장 잘 작동합니닀. 순찚적 작업, 동음 파음 펞집, 또는 많은 종속성읎 있는 작업의 겜우 닚음 섞션읎나 subagents가 더 횚곌적입니닀.

subagents와 비교

에읎전튞 팀곌 subagents 몚두 작업을 병렬화할 수 있지만, 닀륎게 작동합니닀. 워컀듀읎 서로 통신핎알 하는지 여부에 따띌 선택합니닀:

Subagent와 에읎전튞 팀 아킀텍처륌 비교하는 닀읎얎귞랚입니닀. Subagents는 메읞 에읎전튞에 의핎 생성되고, 작업을 수행하며, 결곌륌 볎고합니닀. 에읎전튞 팀은 공유 작업 목록을 통핎 조윚되며, 팀원듀읎 서로 직접 통신합니닀. Subagent와 에읎전튞 팀 아킀텍처륌 비교하는 닀읎얎귞랚입니닀. Subagents는 메읞 에읎전튞에 의핎 생성되고, 작업을 수행하며, 결곌륌 볎고합니닀. 에읎전튞 팀은 공유 작업 목록을 통핎 조윚되며, 팀원듀읎 서로 직접 통신합니닀.
Subagents 에읎전튞 팀
컚텍슀튞 자신의 컚텍슀튞 윈도우; 결곌는 혞출자에게 반환됹 자신의 컚텍슀튞 윈도우; 완전히 독늜적
통신 메읞 에읎전튞에게만 결곌 볎고 팀원듀읎 서로 직접 메시지 전송
조윚 메읞 에읎전튞가 몚든 작업 ꎀ늬 자첎 조윚을 통한 공유 작업 목록
최적 용도 결곌만 쀑요한 집쀑된 작업 녌의와 협업읎 필요한 복잡한 작업
토큰 비용 낮음: 결곌가 메읞 컚텍슀튞로 요앜됚 높음: 각 팀원읎 별도의 Claude 읞슀턎슀

결곌륌 볎고하는 빠륎고 집쀑된 워컀가 필요할 때는 subagents륌 사용합니닀. 팀원듀읎 발견을 공유하고, 서로 도전하며, 자첎적윌로 조윚핎알 할 때는 에읎전튞 팀을 사용합니닀.

에읎전튞 팀 활성화

에읎전튞 팀은 Ʞ볞적윌로 비활성화되얎 있습니닀. CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS 환겜 변수륌 1로 섀정하여 활성화합니닀. ì…ž 환겜읎나 settings.json을 통핎 섀정할 수 있습니닀:

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

첫 번짞 에읎전튞 팀 시작하Ʞ

에읎전튞 팀을 활성화한 후, 자연얎로 원하는 작업곌 팀원듀을 섀명합니닀. Claude는 팀원듀을 생성하고 프롬프튞에 따띌 작업을 조윚합니닀.

읎 예시는 ì„ž 가지 역할읎 독늜적읎고 서로륌 Ʞ닀늬지 않고 묞제륌 탐색할 수 있Ʞ 때묞에 잘 작동합니닀:

I'm designing a CLI tool that helps developers track TODO comments across
their codebase. Spawn three teammates to explore this from different angles:
one on UX, one on technical architecture, one playing devil's advocate.

귞러멎 Claude는 공유 작업 목록을 채우고, 각 ꎀ점에 대한 팀원듀을 생성하며, 묞제륌 탐색하고, 완료되었을 때 발견을 종합합니닀.

늬더의 터믞널은 몚든 팀원곌 귞듀읎 작업 쀑읞 낎용을 나엎합니닀. Shift+Down을 사용하여 팀원듀을 순환하고 직접 메시지륌 볎냅니닀. 마지막 팀원 읎후, Shift+Down은 늬더로 돌아갑니닀.

각 팀원읎 자신의 분할 찜에 있Ʞ륌 원하멎 표시 몚드 선택을 찞조합니닀.

에읎전튞 팀 제얎하Ʞ

늬더에게 자연얎로 원하는 것을 말합니닀. 지시에 따띌 팀 조윚, 작업 할당, 위임을 처늬합니닀.

표시 몚드 선택

에읎전튞 팀은 두 가지 표시 몚드륌 지원합니닀:

  • In-process: 몚든 팀원읎 메읞 터믞널 낎에서 싀행됩니닀. Shift+Down을 사용하여 팀원듀을 순환하고 입력하여 직접 메시지륌 볎냅니닀. 몚든 터믞널에서 작동하며 추가 섀정읎 필요하지 않습니닀.
  • 분할 ì°œ: 각 팀원읎 자신의 찜을 가집니닀. 몚든 사람의 출력을 한 번에 볌 수 있고 찜을 큎늭하여 직접 상혞작용할 수 있습니닀. tmux 또는 iTerm2가 필요합니닀.

Ʞ볞값은 "auto"읎며, 읎믞 tmux ì„žì…˜ 낎에서 싀행 쀑읎거나 터믞널읎 iTerm2읞 겜우 분할 찜을 사용하고, 귞렇지 않윌멎 in-process륌 사용합니닀. "tmux" 섀정은 분할 ì°œ 몚드륌 활성화하고 터믞널에 따띌 tmux 또는 iTerm2륌 사용할지 자동윌로 감지합니닀. 재정의하렀멎 ~/.claude/settings.json에서 teammateMode륌 섀정합니닀:

{
  "teammateMode": "in-process"
}

닚음 섞션에 대핮 in-process 몚드륌 강제하렀멎 플래귞로 전달합니닀:

claude --teammate-mode in-process

분할 ì°œ 몚드는 tmux 또는 it2 CLI가 있는 iTerm2가 필요합니닀. 수동윌로 섀치하렀멎:

  • tmux: 시슀템의 팚킀지 ꎀ늬자륌 통핎 섀치합니닀. 플랫폌별 지칚은 tmux wiki륌 찞조합니닀.
  • iTerm2: it2 CLI륌 섀치한 후, iTerm2 → Settings → General → Magic → Enable Python API에서 Python API륌 활성화합니닀.

팀원 및 몚덞 지정

Claude는 작업에 따띌 생성할 팀원의 수륌 결정하거나, 정확히 원하는 것을 지정할 수 있습니닀:

Spawn 4 teammates to refactor these modules in parallel. Use Sonnet for
each teammate.

팀원듀은 Ʞ볞적윌로 늬더의 /model 선택을 상속하지 않습니닀. 프롬프튞가 지정하지 않을 때 사용되는 몚덞을 변겜하렀멎, /config에서 Ʞ볞 팀원 몚덞을 섀정합니닀. **Ʞ볞값(늬더의 몚덞)**을 선택하여 팀원듀읎 늬더의 현재 몚덞을 따륎도록 합니닀.

팀원을 위한 계획 승읞 요구

복잡하거나 위험한 작업의 겜우, 팀원듀읎 구현하Ʞ 전에 계획하도록 요구할 수 있습니닀. 팀원은 늬더가 ì ‘ê·Œ 방식을 승읞할 때까지 읜Ʞ 전용 계획 몚드에서 작동합니닀:

Spawn an architect teammate to refactor the authentication module.
Require plan approval before they make any changes.

팀원읎 계획을 마치멎, 늬더에게 계획 승읞 요청을 볎냅니닀. 늬더는 계획을 검토하고 승읞하거나 플드백곌 핚께 거부합니닀. 거부되멎, 팀원은 계획 몚드에 뚞묌러 플드백에 따띌 수정하고 닀시 제출합니닀. 승읞되멎, 팀원은 계획 몚드륌 종료하고 구현을 시작합니닀.

늬더는 자윚적윌로 승읞 결정을 낎늜니닀. 늬더의 판닚에 영향을 믞치렀멎, 프롬프튞에 "테슀튞 컀버늬지륌 포핚하는 계획만 승읞" 또는 "데읎터베읎슀 슀킀마륌 수정하는 계획 거부"와 같은 Ʞ쀀을 제공합니닀.

팀원곌 직접 대화하Ʞ

각 팀원은 완전하고 독늜적읞 Claude Code 섞션입니닀. 몚든 팀원에게 직접 메시지륌 볎낎 추가 지시륌 제공하고, 후속 질묞을 하거나, ì ‘ê·Œ 방식을 재지정할 수 있습니닀.

  • In-process 몚드: Shift+Down을 사용하여 팀원듀을 순환한 후 입력하여 메시지륌 볎냅니닀. Enter륌 눌러 팀원의 섞션을 볎고, Escape륌 눌러 현재 턎을 쀑닚합니닀. Ctrl+T륌 눌러 작업 목록을 전환합니닀.
  • 분할 ì°œ 몚드: 팀원의 찜을 큎늭하여 섞션곌 직접 상혞작용합니닀. 각 팀원은 자신의 터믞널의 전첎 볎Ʞ륌 가집니닀.

작업 할당 및 요청

공유 작업 목록은 팀 전첎의 작업을 조윚합니닀. 늬더는 작업을 만듀고 팀원듀읎 읎륌 처늬합니닀. 작업은 ì„ž 가지 상태륌 가집니닀: 대Ʞ 쀑, 진행 쀑, 완료됚. 작업은 닀륞 작업에 종속될 수도 있습니닀: 믞핎결 종속성읎 있는 대Ʞ 쀑읞 작업은 핎당 종속성읎 완료될 때까지 요청할 수 없습니닀.

늬더는 작업을 명시적윌로 할당하거나 팀원듀읎 자첎 요청할 수 있습니닀:

  • 늬더 할당: 늬더에게 얎느 작업을 얎느 팀원에게 쀄지 말합니닀
  • 자첎 요청: 작업을 마친 후, 팀원은 닀음 믞할당, 믞찚닚 작업을 자첎적윌로 선택합니닀

작업 요청은 파음 잠ꞈ을 사용하여 여러 팀원읎 동시에 동음한 작업을 요청하렀고 할 때 겜합 조걎을 방지합니닀.

팀원 종료하Ʞ

팀원의 섞션을 우아하게 종료하렀멎, 읎늄윌로 찞조합니닀. 예륌 듀얎, researcher띌는 팀원읎 있는 겜우:

Ask the researcher teammate to shut down

늬더는 종료 요청을 볎냅니닀. 팀원은 승읞하여 우아하게 종료하거나 섀명곌 핚께 거부할 수 있습니닀.

팀의 공유 디렉토늬는 섞션읎 끝날 때 자동윌로 정늬되므로, 별도의 정늬 닚계가 없습니닀. ì–Žë–€ 디렉토늬가 제거되고 ì–Žë–€ 디렉토늬가 재개된 섞션을 위핎 유지되는지는 아킀텍처륌 찞조합니닀.

hooks로 품질 게읎튞 적용

hooks륌 사용하여 팀원듀읎 작업을 마치거나 작업읎 생성되거나 완료될 때 규칙을 적용합니닀:

  • TeammateIdle: 팀원읎 유휎 상태가 되렀고 할 때 싀행됩니닀. 종료 윔드 2로 종료하여 플드백을 볎낎고 팀원을 계속 작동하게 합니닀.
  • TaskCreated: 작업읎 생성될 때 싀행됩니닀. 종료 윔드 2로 종료하여 생성을 방지하고 플드백을 볎냅니닀.
  • TaskCompleted: 작업읎 완료로 표시될 때 싀행됩니닀. 종료 윔드 2로 종료하여 완료륌 방지하고 플드백을 볎냅니닀.

에읎전튞 팀읎 얎떻게 작동하는지

읎 섹션은 에읎전튞 팀 뒀의 아킀텍처와 메컀니슘을 닀룹니닀. 사용을 시작하렀멎 위의 에읎전튞 팀 제얎하Ʞ륌 찞조합니닀.

Claude가 에읎전튞 팀을 시작하는 방법

에읎전튞 팀읎 첫 번짞 팀원읎 생성될 때 형성되며, 메읞 섞션읎 늬더 역할을 합니닀. 팀원읎 생성되는 두 가지 방법읎 있습니닀:

  • 팀원을 요청합니닀: 병렬 작업의 읎점읎 있는 작업을 제공하고 명시적윌로 팀원을 요청합니닀. Claude는 지시에 따띌 팀원을 생성합니닀.
  • Claude가 팀원을 제안합니닀: Claude가 작업읎 병렬 작업의 읎점읎 있닀고 판닚하멎, 팀원 생성을 제안할 수 있습니닀. 진행하Ʞ 전에 확읞합니닀.

두 겜우 몚두 제얎 권한을 유지합니닀. Claude는 승읞 없읎 팀원을 생성하지 않습니닀.

아킀텍처

에읎전튞 팀은 닀음윌로 구성됩니닀:

구성 요소 역할
팀 늬더 팀원을 생성하고 작업을 조윚하는 메읞 Claude Code ì„žì…˜
팀원듀 할당된 작업에서 각각 작동하는 별도의 Claude Code 읞슀턎슀
작업 목록 팀원듀읎 요청하고 완료하는 공유 작업 항목 목록
메음박슀 에읎전튞 간 통신을 위한 메시징 시슀템

표시 구성 옵션은 표시 몚드 선택을 찞조합니닀. 팀원 메시지는 늬더에게 자동윌로 도착합니닀.

시슀템은 작업 종속성을 자동윌로 ꎀ늬합니닀. 팀원읎 닀륞 작업읎 종속된 작업을 완료하멎, 찚닚된 작업은 수동 개입 없읎 ì°šë‹š 핎제됩니닀.

팀곌 작업은 ì„žì…˜ 파생 읎늄윌로 로컬에 저장됩니닀. 읎늄은 session- 뒀에 ì„žì…˜ ID의 처음 8자가 붙습니닀:

  • 팀 구성: ~/.claude/teams/{team-name}/config.json
  • 작업 목록: ~/.claude/tasks/{team-name}/

Claude Code는 ì„žì…˜ 시작 시 읎 둘을 자동윌로 생성하고 팀원듀읎 찞여하거나, 유휎 상태가 되거나, 떠날 때 업데읎튞합니닀. 팀 구성 디렉토늬는 섞션읎 끝날 때 제거됩니닀. 작업 목록 디렉토늬는 로컬에 유지되며 절대 업로드되지 않윌므로, 재개된 섞션은 작업을 유지합니닀. 볎졎은 ì„žì…˜ 튞랜슀크늜튞에 대핮 읎믞 제얎하는 것곌 동음한 cleanupPeriodDays에 의핎 ꎀ늬됩니닀.

팀 구성은 ì„žì…˜ ID 및 tmux ì°œ ID와 같은 런타임 상태륌 볎유하므로, 수동윌로 펞집하거나 사전 작성하지 마십시였: 닀음 상태 업데읎튞에서 변겜 사항읎 덮얎씌워집니닀.

재사용 가능한 팀원 역할을 정의하렀멎, 대신 subagent 정의 사용을 사용합니닀.

팀 구성에는 각 팀원의 읎늄, 에읎전튞 ID, 에읎전튞 유형읎 있는 members 배엎읎 포핚됩니닀. 팀원듀은 읎 파음을 읜얎 닀륞 팀 멀버륌 발견할 수 있습니닀.

프로젝튞 수쀀의 팀 구성 동등묌은 없습니닀. 프로젝튞 디렉토늬의 .claude/teams/teams.json곌 같은 파음은 구성윌로 읞식되지 않습니닀. Claude는 읎륌 음반 파음로 췚꞉합니닀.

팀원을 위핎 subagent 정의 사용

팀원을 생성할 때, 프로젝튞, 사용자, 플러귞읞, 또는 CLI 정의 등 몚든 subagent 범위의 subagent 유형을 ì°žì¡°í•  수 있습니닀. 읎륌 통핎 볎안 검토자 또는 테슀튞 싀행자와 같은 역할을 한 번 정의하고 위임된 subagent와 에읎전튞 팀 팀원 몚두로 재사용할 수 있습니닀.

subagent 정의륌 사용하렀멎, Claude에게 팀원을 생성하도록 요청할 때 읎늄윌로 얞꞉합니닀:

Spawn a teammate using the security-reviewer agent type to audit the auth module.

팀원은 핎당 정의의 tools 허용 목록곌 model을 쀀수하며, 정의의 볞묞은 팀원의 시슀템 프롬프튞에 추가 지시로 추가되며 읎륌 대첎하지 않습니닀. SendMessage와 작업 ꎀ늬 도구와 같은 팀 조윚 도구는 tools가 닀륞 도구륌 제한할 때에도 팀원읎 항상 사용할 수 있습니닀.

권한

팀원듀은 늬더의 권한 섀정윌로 시작합니닀. 늬더가 --dangerously-skip-permissions로 싀행되멎, 몚든 팀원도 귞렇게 합니닀. 생성 후, 개별 팀원 몚드륌 변겜할 수 있지만, 생성 시 팀원별 몚드륌 섀정할 수 없습니닀.

컚텍슀튞 및 통신

각 팀원은 자신의 컚텍슀튞 윈도우륌 가집니닀. 생성될 때, 팀원은 음반 섞션곌 동음한 프로젝튞 컚텍슀튞륌 로드합니닀: CLAUDE.md, MCP servers, skills. 또한 늬더의 생성 프롬프튞륌 받습니닀. 늬더의 대화 Ʞ록은 전달되지 않습니닀.

팀원듀읎 정볎륌 공유하는 방법:

  • 자동 메시지 전달: 팀원듀읎 메시지륌 볎낌 때, 자동윌로 수신자에게 전달됩니닀. 늬더가 업데읎튞륌 폮링할 필요가 없습니닀.
  • 유휎 알늌: 팀원읎 완료되고 쀑지되멎, 자동윌로 늬더에게 알늜니닀.
  • 공유 작업 목록: 몚든 에읎전튞는 작업 상태륌 볎고 사용 가능한 작업을 요청할 수 있습니닀.
  • 팀원 메시징: 읎늄윌로 특정 팀원 한 명에게 메시지륌 볎냅니닀. 몚든 사람에게 도달하렀멎, 각 수신자에게 하나의 메시지륌 볎냅니닀.

늬더는 팀원을 생성할 때 각 팀원에게 읎늄을 할당하며, 몚든 팀원은 ê·ž 읎늄윌로 닀륞 팀원에게 메시지륌 볎낌 수 있습니닀. 나쀑의 프롬프튞에서 ì°žì¡°í•  수 있는 예잡 가능한 읎늄을 얻윌렀멎, 생성 지시에서 각 팀원을 묎엇읎띌고 부륌지 늬더에게 말합니닀.

토큰 사용

에읎전튞 팀은 닚음 섞션볎닀 훚씬 더 많은 토큰을 사용합니닀. 각 팀원은 자신의 컚텍슀튞 윈도우륌 가지며, 토큰 사용은 활성 팀원의 수에 따띌 슝가합니닀. 연구, 검토, 새로욎 Ʞ능 작업의 겜우, 추가 토큰은 음반적윌로 가치가 있습니닀. 음상적읞 작업의 겜우, 닚음 섞션읎 더 비용 횚윚적입니닀. 사용 지칚은 에읎전튞 팀 토큰 비용을 찞조합니닀.

사용 사례 예시

읎 예시듀은 병렬 탐색읎 가치륌 더하는 작업을 에읎전튞 팀읎 얎떻게 처늬하는지 볎여쀍니닀.

병렬 윔드 검토 싀행

닚음 검토자는 한 번에 한 가지 유형의 묞제로 Ʞ욞얎지는 겜향읎 있습니닀. 검토 Ʞ쀀을 독늜적읞 도메읞윌로 분할하멎 볎안, 성능, 테슀튞 컀버늬지가 몚두 동시에 철저한 죌의륌 받습니닀. 프롬프튞는 각 팀원에게 고유한 렌슈륌 할당하여 겹치지 않도록 합니닀:

PR #142륌 검토하Ʞ 위핎 ì„ž 명의 팀원을 배치합니닀:
- 볎안 영향에 쀑점을 두는 팀원
- 성능 영향을 확읞하는 팀원
- 테슀튞 컀버늬지륌 검슝하는 팀원
각각 검토하고 발견 사항을 볎고하도록 합니닀.

각 검토자는 동음한 PR에서 작동하지만 닀륞 필터륌 적용합니닀. 늬더는 몚두 완료된 후 ì„ž 명 몚두의 발견을 종합합니닀.

겜쟁하는 가섀로 조사하Ʞ

귌볞 원읞읎 불명확할 때, 닚음 에읎전튞는 귞럎듯한 섀명 하나륌 ì°Ÿê³  멈추는 겜향읎 있습니닀. 프롬프튞는 팀원듀을 명시적윌로 적대적윌로 만듀얎 읎륌 방지합니닀: 각 팀원의 음은 자신의 읎론을 조사하는 것뿐만 아니띌 닀륞 팀원듀에게 도전하는 것입니닀.

사용자듀읎 앱읎 연결 상태륌 유지하는 대신 한 메시지 후에 종료된닀고 볎고합니닀.
5명의 에읎전튞 팀원을 배치하여 닀양한 가섀을 조사하도록 합니닀. 귞듀읎 서로 대화하여
곌학적 토론처럌 서로의 읎론을 반박하렀고 하도록 합니닀. 발견 사항 묞서륌
나타나는 합의로 업데읎튞합니닀.

토론 구조가 여Ʞ서 핵심 메컀니슘입니닀. 순찚적 조사는 앵컀링윌로 읞핎 고통받습니닀: 한 읎론읎 탐색되멎, 후속 조사는 귞것에 펞향됩니닀.

여러 독늜적읞 조사자가 적극적윌로 서로의 읎론을 반박하렀고 할 때, 생졎하는 읎론은 싀제 귌볞 원읞음 가능성읎 훚씬 높습니닀.

몚범 사례

팀원에게 충분한 컚텍슀튞 제공

팀원듀은 CLAUDE.md, MCP servers, skills륌 포핚한 프로젝튞 컚텍슀튞륌 자동윌로 로드하지만, 늬더의 대화 Ʞ록을 상속하지 않습니닀. 자섞한 낎용은 컚텍슀튞 및 통신을 찞조합니닀. 생성 프롬프튞에 작업별 섞부 사항을 포핚합니닀:

Spawn a security reviewer teammate with the prompt: "Review the authentication module
at src/auth/ for security vulnerabilities. Focus on token handling, session
management, and input validation. The app uses JWT tokens stored in
httpOnly cookies. Report any issues with severity ratings."

적절한 팀 크Ʞ 선택

팀원의 수에 대한 하드 제한은 없지만, 싀질적읞 제앜읎 적용됩니닀:

  • 토큰 비용읎 선형윌로 슝가: 각 팀원은 자신의 컚텍슀튞 윈도우륌 가지며 독늜적윌로 토큰을 소비합니닀. 자섞한 낎용은 에읎전튞 팀 토큰 비용을 찞조합니닀.
  • 조윚 였버헀드 슝가: 더 많은 팀원은 더 많은 통신, 작업 조윚, 충돌 가능성을 의믞합니닀
  • 수익 감소: 특정 지점을 넘윌멎, 추가 팀원은 작업 속도륌 비례적윌로 높읎지 않습니닀

대부분의 워크플로우에 대핮 3-5명의 팀원윌로 시작합니닀. 읎는 병렬 작업곌 ꎀ늬 가능한 조윚의 균형을 맞춥니닀. 읎 가읎드의 예시듀은 3-5명의 팀원을 사용합니닀. 읎 범위는 닀양한 작업 유형에서 잘 작동하Ʞ 때묞입니닀.

팀원당 5-6개의 작업을 유지하멎 곌도한 컚텍슀튞 전환 없읎 몚두륌 생산적윌로 유지합니닀. 15개의 독늜적읞 작업읎 있윌멎, 3명의 팀원읎 좋은 시작점입니닀.

작업읎 싀제로 팀원듀읎 동시에 작동하는 것의 읎점읎 있을 때만 확장합니닀. ì„ž 명의 집쀑된 팀원은 종종 닀섯 명의 산만한 팀원을 능가합니닀.

작업을 적절히 크Ʞ 조정

  • 너묎 작음: 조윚 였버헀드가 읎점을 쎈곌합니닀
  • 너묎 큌: 팀원듀읎 첎크읞 없읎 너묎 였래 작동하여 낭비된 녞력의 위험읎 슝가합니닀
  • 적절핚: 핚수, 테슀튞 파음, 검토와 같은 명확한 결곌묌을 생성하는 자첎 포핚된 닚위

팀원듀읎 완료될 때까지 Ʞ닀늬Ʞ

때때로 늬더는 팀원듀을 Ʞ닀늬지 않고 작업을 자첎적윌로 구현하Ʞ 시작합니닀. 읎륌 알아찚늬멎:

Wait for your teammates to complete their tasks before proceeding

연구 및 검토로 시작하Ʞ

에읎전튞 팀을 처음 사용하는 겜우, 명확한 겜계가 있고 윔드 작성읎 필요하지 않은 작업윌로 시작합니닀: PR 검토, 띌읎람러늬 연구, 또는 버귞 조사. 읎러한 작업은 병렬 탐색의 가치륌 볎여죌멎서 병렬 구현곌 핚께 였는 조윚 묞제 없읎 볎여쀍니닀.

파음 충돌 플하Ʞ

두 팀원읎 동음한 파음을 펞집하멎 덮얎쓰Ʞ가 발생합니닀. 각 팀원읎 닀륞 파음 집합을 소유하도록 작업을 나눕니닀.

몚니터링 및 조윚

팀원듀의 진행 상황을 확읞하고, 작동하지 않는 ì ‘ê·Œ 방식을 재지정하며, 발견읎 듀얎올 때 종합합니닀. 팀을 묎읞윌로 너묎 였래 싀행하멎 낭비된 녞력의 위험읎 슝가합니닀.

묞제 í•Žê²°

팀원읎 나타나지 않음

Claude에게 팀원을 생성하도록 요청한 후 팀원읎 나타나지 않윌멎:

  • In-process 몚드에서, 팀원듀읎 읎믞 싀행 쀑읎지만 볎읎지 않을 수 있습니닀. Shift+Down을 눌러 활성 팀원듀을 순환합니닀.
  • Claude에게 쀀 작업읎 팀원을 볎슝할 만큌 복잡한지 확읞합니닀. Claude는 작업에 따띌 팀원을 생성할지 결정합니닀.
  • 분할 찜을 명시적윌로 요청했윌멎, tmux가 섀치되얎 있고 PATH에서 사용 가능한지 확읞합니닀: 
    which tmux
  • iTerm2의 겜우, it2 CLI가 섀치되얎 있고 Python API가 iTerm2 환겜 섀정에서 활성화되얎 있는지 확읞합니닀.

너묎 많은 권한 프롬프튞

팀원 권한 요청읎 늬더로 버랔업되얎 마찰을 음윌킬 수 있습니닀. 팀원듀을 생성하Ʞ 전에 권한 섀정에서 음반적읞 작업을 사전 승읞하여 쀑닚을 쀄입니닀.

팀원듀읎 였류에서 쀑지됚

팀원듀은 였류륌 만난 후 복구하지 않고 쀑지할 수 있습니닀. In-process 몚드에서 Shift+Down을 사용하거나 분할 몚드에서 찜을 큎늭하여 출력을 확읞한 후:

  • 직접 추가 지시륌 제공합니닀
  • 작업을 계속하Ʞ 위핎 대첎 팀원을 생성합니닀

늬더가 작업 완료 전에 종료됚

늬더는 몚든 작업읎 싀제로 완료되Ʞ 전에 팀읎 완료되었닀고 결정할 수 있습니닀. 읎 겜우 계속하도록 말합니닀. 또한 늬더가 위임하지 않고 작업을 시작하멎 팀원듀읎 완료될 때까지 Ʞ닀늬도록 말할 수 있습니닀.

고아 tmux ì„žì…˜

팀읎 끝난 후 tmux 섞션읎 지속되멎, 완전히 정늬되지 않았을 수 있습니닀. 섞션을 나엎하고 팀에서 만든 섞션을 종료합니닀:

tmux ls
tmux kill-session -t <session-name>

제한 사항

에읎전튞 팀은 싀험적입니닀. 죌의할 현재 제한 사항:

  • In-process 팀원곌의 ì„žì…˜ 재개 없음: /resume곌 /rewind는 in-process 팀원을 복원하지 않습니닀. 섞션을 재개한 후, 늬더는 더 읎상 졎재하지 않는 팀원에게 메시지륌 볎낎렀고 시도할 수 있습니닀. 읎 겜우 늬더에게 새 팀원을 생성하도록 말합니닀.
  • 작업 상태가 지연될 수 있음: 팀원듀읎 때때로 작업을 완료로 표시하지 못하여 종속 작업을 찚닚합니닀. 작업읎 막혀 있는 것처럌 볎읎멎, 작업읎 싀제로 완료되었는지 확읞하고 작업 상태륌 수동윌로 업데읎튞하거나 늬더에게 팀원을 밀도록 말합니닀.
  • 종료가 느멮 수 있음: 팀원듀은 현재 요청읎나 도구 혞출을 마친 후 종료되얎 시간읎 걞늎 수 있습니닀.
  • 섞션당 한 팀: 섞션은 정확히 하나의 팀을 가지며, 핎당 섞션윌로 범위가 지정됩니닀. 추가 명명된 팀을 만듀거나 ì„žì…˜ 간에 팀을 공유할 수 없습니닀.
  • 쀑첩된 팀 없음: 팀원듀은 자신의 팀원을 생성할 수 없습니닀. 늬더만 팀을 ꎀ늬할 수 있습니닀.
  • 늬더가 고정됚: 죌 섞션은 수명 동안 늬더입니닀. 팀원을 늬더로 승격하거나 늬더십을 읎전할 수 없습니닀.
  • 생성 시 권한 섀정: 몚든 팀원은 늬더의 권한 몚드로 시작합니닀. 생성 후 개별 팀원 몚드륌 변겜할 수 있지만, 생성 시 팀원별 몚드륌 섀정할 수 없습니닀.
  • 분할 찜은 tmux 또는 iTerm2 필요: Ʞ볞 in-process 몚드는 몚든 터믞널에서 작동합니닀. 분할 ì°œ 몚드는 VS Code의 통합 터믞널, Windows Terminal, Ghostty에서 지원되지 않습니닀.

닀음 닚계

병렬 작업 및 위임을 위한 ꎀ렚 ì ‘ê·Œ 방식을 탐색합니닀:

  • 겜량 위임: subagents는 ì„žì…˜ 낎에서 연구 또는 검슝을 위핎 도우믞 에읎전튞륌 생성하며, 에읎전튞 간 조윚읎 필요하지 않은 작업에 더 좋습니닀
  • 수동 병렬 ì„žì…˜: Git worktrees륌 사용하멎 자동화된 팀 조윚 없읎 여러 Claude Code 섞션을 직접 싀행할 수 있습니닀
  • ì ‘ê·Œ 방식 비교: subagent vs 에읎전튞 팀 비교륌 찞조하여 나란히 비교합니닀