Sub-agent vs Teams — 두 가지 오케스트레이션 런타임

여러 에이전트를 조합해 복잡한 업무를 자동화할 때 Claude는 두 가지 서로 다른 실행 방식을 제공합니다. 겉보기에는 비슷해 보여도 실행 환경 · 협업 구조 · 상태 관리 방식이 크게 달라서, 선택을 잘못하면 "되긴 하는데 왜 이렇게 불편하지?"라는 고통이 따릅니다.

이 글은 두 방식을 실제 업무 관점에서 나란히 세워 언제 무엇을 써야 하는지 정리합니다.

TL;DR

항목	Sub-agent	Agent Teams
실행 환경	Cowork · Claude Code 공통	Claude Code 2.1.97+ + tmux 전용
호출 방식	`Agent()` 도구로 하위 에이전트 spawn	`TeamCreate` + `SendMessage` + `TaskList`
협업 구조	fan-out / fan-in (부모 허브)	peer-to-peer (상주 teammate)
상태 저장	결과만 부모로 반환, 세션 단명	`TaskList` 공유, 장시간 연속
진입 장벽	낮음 — 기본 제공	높음 — 실험 플래그 + tmux + 버전 요구
Cowork 지원	✅	❌

한 줄 결론: 대부분의 업무는 Sub-agent로 충분합니다. Teams는 "장시간 상주하며 teammate 간 실시간 협상이 필요한 경우"에만 고민할 가치가 있습니다.

Sub-agent 방식 — 메인 세션이 지휘자

멘탈 모델: fan-out / fan-in

flowchart LR
  U["사용자 요청"] --> M["메인 세션
지휘자"]
  M -->|Agent: task1| A1[하위 에이전트 A]
  M -->|Agent: task2| A2[하위 에이전트 B]
  M -->|Agent: task3| A3[하위 에이전트 C]
  A1 -->|결과| M
  A2 -->|결과| M
  A3 -->|결과| M
  M --> O[조립된 결과]

핵심: 메인 세션이 모든 결정의 허브. 하위 에이전트는 주어진 작업만 수행하고 결과를 부모에게 반환한 뒤 소멸. 세션 종료.

어떻게 호출하나

Claude에게 이렇게 말하면 됩니다:

Agent 도구로 다음 3개 작업을 병렬 실행해줘:
1. 경쟁사 뉴스 크롤링 subagent — 지난 24시간, 핵심 3건
2. 자사 내부 메트릭 조회 subagent — 매출 · 고객수
3. 요약 작성 subagent — 위 두 결과를 3줄로 종합
결과를 한 장짜리 아침 브리핑 카드로 조립해.

Claude는 이걸 받아 Agent() 도구를 3번 호출 (가능하면 병렬), 각 하위 에이전트의 결과를 받아 최종 카드를 조립합니다.

장점

환경 제약 없음 — Claude Cowork · Claude Code 어디서나 동작
즉시 시작 — 별도 설정 없이 바로 사용 가능
직관적 — "이 일을 하위 에이전트에게 시켜줘" 자연어로 표현
디버깅 용이 — 한 세션 안에 모든 호출 기록이 남음

한계

teammate 간 직접 통신 불가 — 항상 부모 세션을 경유해야 함
세션 단명 — 트리거가 끝나면 모든 에이전트가 소멸, 다음 트리거는 백지에서 시작
병렬도 제한 — 부모가 결과를 취합하는 구조라 진정한 비동기 파이프라인은 어려움

Agent Teams 방식 — 상주 팀이 peer-to-peer 협업

멘탈 모델: peer-to-peer 파이프라인

flowchart LR
  C[트리거] --> L[리더 세션]
  L -->|TeamCreate| T1["crawler
teammate"]
  L -->|TeamCreate| T2["parser
teammate"]
  L -->|TeamCreate| T3["tagger
teammate"]
  T1 -->|SendMessage| T2
  T2 -->|SendMessage| T3
  T3 --> TL[("TaskList
공유 상태")]
  T1 --> TL
  T2 --> TL

핵심: 여러 teammate가 상주하며 서로 직접 메시지를 주고받습니다. 메인 세션은 팀을 생성하고 감독할 뿐 데이터 흐름의 허브가 아닙니다. TaskList가 전원 공유하는 단일 진실 소스 역할을 합니다.

어떻게 호출하나

TeamCreate로 "market-intel" 팀을 만들고 teammate 3명을 spawn:
- researcher (isolation: worktree) — 원천 데이터 수집
- analyst (isolation: worktree) — 숫자 검증 · 트렌드 분석
- writer — 최종 카드 작성

작업은 TaskList로 자기조율하고, 서로 필요한 정보는 SendMessage로 직접 질의해.
crawler가 새 데이터를 잡으면 analyst에게 바로 전달하고, analyst가
검증을 마치면 writer에게 전달하는 파이프라인으로 구성해줘.

실행 환경 요구사항 (엄격)

Claude Code 2.1.97 이상 — worktree CWD isolation 버그 패치가 반영된 버전
tmux 또는 iTerm2 — teammate가 각자 독립 세션 팬에서 실행됨
환경변수 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 (settings.json env 섹션)
설정 파일 .moai/config/sections/workflow.yaml의 workflow.team.enabled: true
Cowork 미지원 — Cowork 세션은 환경변수를 런타임에 주입하지 못하고 tmux UI도 노출되지 않습니다

장점

실시간 스트리밍 파이프라인 — teammate A의 산출물이 teammate B로 즉시 흘러감
장시간 상주 — 한 번 띄우면 트리거 반복에도 상태 유지
worktree 격리 — 여러 teammate가 동시에 다른 파일을 쓰더라도 충돌 없음
자기조율 — TaskList를 공유하므로 중앙 조정자 없이 작업 분배 가능

한계

Cowork 미지원 — 가장 큰 제약. Cowork 고객은 이 방식을 사용할 수 없습니다
환경 설정 복잡 — 버전 · 환경변수 · 설정 파일 · 터미널 요구가 모두 맞아야 함
리더 종료 = 팀 전체 종료 — 리더 세션이 죽으면 모든 teammate가 함께 중지
디버깅 어려움 — 여러 세션에 로그가 분산되어 추적이 어려움

언제 무엇을 쓸까

Sub-agent가 답인 경우

Cowork를 사용 중이다 — 선택의 여지가 없습니다. Sub-agent 한 가지 뿐.
트리거가 단발성이다 — 아침마다 한 번 실행되는 크롤링, 파일 드래그 한 번에 분류 등
결과가 파일로 떨어지면 충분하다 — 다음 트리거가 새 세션에서 시작해도 됨
팀원에게 교육시켜야 한다 — 복잡한 환경 설정 없이 누구나 바로 따라할 수 있음

Teams가 가치를 발휘하는 경우

장시간 상주해야 한다 — 뉴스 스트림을 몇 시간 동안 지켜보며 중요한 것만 실시간 요약
teammate 간 실시간 협상이 필요하다 — crawler가 잡은 것을 parser가 바로 검증하고 tagger가 분류하는 스트리밍 파이프라인
병렬 파일 쓰기가 많다 — 여러 teammate가 각자 독립된 worktree에서 동시에 코드를 수정 (예: 대규모 리팩토링 팀 작업)
환경 통제가 가능한 로컬 워크스테이션에서 작업한다

실제 비교 — 아침 브리핑 자동화

같은 요구사항 "매일 아침 9시에 어제 발생한 업계 뉴스 5건 + 자사 매출 변동을 한 장으로 브리핑"을 두 방식으로 구성해 보겠습니다.

Sub-agent 버전

트리거: Cowork 스케줄러가 매일 09:00 메인 세션 기동
메인 세션이 Skill "daily-briefing"을 실행
Skill이 Agent()로 3개 하위 에이전트를 병렬 spawn
- crawler — 뉴스 5건 수집
- metrics-fetcher — 내부 매출 API 조회
- summarizer — 위 두 결과를 브리핑 템플릿에 맞춰 조립
메인 세션이 결과를 받아 마크다운 파일로 저장
세션 종료. 내일 아침 9시에 새 세션 기동

소요 세팅 시간: Skill 작성 15분 + Cowork 스케줄 등록 3분. 끝.

Teams 버전

준비: Claude Code 2.1.97+ 설치, tmux 설정, 환경변수 설정
리더 세션 시작 후 TeamCreate로 briefing-team 3명 spawn
- watcher teammate — 뉴스 RSS를 상시 모니터링, 새 기사 뜨면 즉시 parser에 SendMessage
- analyst teammate — 매출 이상치를 상시 모니터링, 이상 발견 시 summarizer에 직접 전달
- summarizer teammate — watcher/analyst로부터 받은 정보를 누적, 09:00에 종합 카드 생성
리더 세션을 종일 켜놓고 브리핑을 09:00에 수확
리더가 종료되면 팀 전체가 사라짐 → 매일 아침 재시작 필요

소요 세팅 시간: 환경 세팅 1-2시간 + 팀 구성 30분. 이후 매일 리더 세션 유지 부담.

결론

이 시나리오에서는 Sub-agent 압승입니다. 왜냐하면:

트리거가 하루 1회로 단발성
실시간 스트리밍이 필요 없음
팀 상주의 복잡도에 비해 얻는 것이 적음

Teams가 빛나는 시나리오는 "오후 내내 시장을 관찰하다가 이상 시그널이 감지되면 즉시 대응 브리핑을 보내는" 같은 연속 감시형 업무입니다.

자주 묻는 질문

Q. Cowork 고객은 Teams를 영영 못 쓰는 건가요?

A. 현재로서는 맞습니다. 하지만 Cowork 플랫폼이 Agent Teams API를 주입하는 방향으로 업데이트될 가능성은 있습니다. 당장은 Sub-agent 패턴으로 구성하고, Teams가 필요한 워크로드만 Claude Code 로컬 환경에서 처리하는 하이브리드 전략이 현실적입니다.

Q. Sub-agent로 장시간 상주를 흉내낼 수는 없나요?

A. 부분적으로 가능합니다. Cowork의 스케줄러(예: 5분마다 기동)와 폴더 감시를 조합하면 "이벤트 기반 반복 기동"을 구현할 수 있습니다. 단 매 기동마다 세션이 새로 시작되므로 상태는 파일로 저장해서 다음 기동에 넘겨야 합니다. 진정한 메모리 공유는 불가능합니다.

Q. 교육이나 워크숍에서는 어느 방식을 가르쳐야 하나요?

A. Sub-agent 중심이 정답입니다. Cowork에서 바로 따라할 수 있어 참가자 설치 부담이 없고, 오케스트레이션의 핵심 개념(fan-out/fan-in, 에이전트 조합)이 모두 전달됩니다. Teams는 "이런 세계도 있다" 수준의 시연으로 충분합니다.

Q. 두 방식의 성능 차이는 얼마나 나나요?

A. 단순 병렬 처리는 Sub-agent도 매우 빠릅니다. 메인 세션이 여러 Agent() 호출을 병렬로 띄우기 때문입니다. Teams의 진짜 이점은 "속도"가 아니라 "연속성"입니다. 여러 시간에 걸친 관찰 + 반응이 필요한 워크로드에서만 차이가 납니다.

다음 읽을거리

변경 이력

v1 (2026-04-12): 최초 작성 — Claude@IGM Cohort 1 교재용, Cowork Agent Teams 미지원 검증 결과 반영