본문으로 건너뛰기

Claude Code의 AI 협업 패턴: Subagent vs Team

·9 min read

Claude Code에는 복잡한 작업을 처리하기 위한 두 가지 멀티 에이전트 패턴이 있다.

  • Subagent (Task tool): 독립적인 작업을 병렬로 처리하는 일회성 에이전트
  • Team (TeamCreate + SendMessage): 역할별 팀원이 소통하며 협업하는 지속성 에이전트 그룹

두 패턴은 비슷해 보이지만 적합한 상황이 완전히 다르다.


Subagent란?

한마디로 **"심부름꾼을 보내는 것"**이다.

메인 Claude → Task("파일 A 분석해줘") → 서브에이전트 생성

                                         작업 수행

메인 Claude ← 결과 텍스트 반환 ←──────── 종료 (사라짐)

특징

  • 메인 대화의 컨텍스트 윈도우를 보호하기 위해 사용
  • 독립된 컨텍스트에서 작업하고 결과만 반환
  • 작업이 끝나면 비활성화 — 기본적으로 상태를 유지하지 않지만, resume 파라미터로 이전 컨텍스트를 복원하여 재개할 수 있음
  • 서브에이전트끼리는 서로 모름 (소통 불가)
  • 여러 개를 동시에 실행 가능

실생활 비유

배달앱과 같다.

  • "떡볶이 주문" → 배달 → 받음 → 기본적으로 끝 (같은 배달원에게 추가 주문도 가능 = resume)
  • 배달원끼리 연락 안 됨
  • 3개 가게에 동시 주문 가능

Team이란?

한마디로 **"팀을 꾸려서 협업하는 것"**이다.

리더(나) ──── SendMessage ────→ API-리뷰어 (살아있음, 대기 중)
     │                                    ↕ 메시지 주고받기
     ├──── SendMessage ────→ UI-퍼블리셔 (살아있음, 대기 중)
     │                                    ↕ 메시지 주고받기
     └──── SendMessage ────→ 성능-엔지니어 (살아있음, 대기 중)

특징

  • 멤버들이 계속 살아있음 — 여러 번 대화 가능
  • 멤버끼리 메시지로 소통 가능 (A가 B에게 직접 DM)
  • 공유 태스크 리스트로 작업 분배 및 진행 추적
  • 작업이 끝나면 shutdown_request로 명시적으로 해산

실생활 비유

프로젝트 팀과 같다.

  • 팀원이 계속 같이 일함
  • "디자인 나왔어" → "그럼 프론트 시작할게" → "API 먼저 줄까?" 대화 가능
  • 팀장이 진행 상황 관리

핵심 차이 비교

SubagentTeam
생명 주기기본 1회성 (resume으로 재개 가능)지속 (해산할 때까지 유지)
소통불가 (결과만 반환)멤버 간 메시지 가능
상태 공유없음태스크 리스트 공유
비용(오버헤드)낮음높음 (멤버별 세션 유지)
적합한 작업독립적 단순 작업의존성 있는 협업

오버헤드란?

실제 작업 외에 드는 부가 비용을 말한다.

단계하는 일실제 작업인가?
팀 생성TeamCreate + config 작성X
멤버 스폰각 멤버별 세션 초기화X
프롬프트 전달멤버에게 역할/컨텍스트 설명X
메시지 라우팅멤버 간 SendMessage 주고받기X
idle 관리멤버가 멈추면 확인/재할당X
실제 코드 작업파일 읽기, 수정, 검증O

Subagent는 "Task 호출 → 바로 작업 → 결과 반환"으로 중간 단계가 거의 없다.


실제 프로젝트 적용 사례

사례 1: Subagent — 모노레포 마이그레이션

kodeflo 프로젝트를 모노레포로 마이그레이션할 때 Subagent 패턴을 활용했다.

작업 구조:

메인 Claude
  ├→ Task("apps/admin 패키지 설정 분석") → 에이전트1 → 결과
  ├→ Task("shared 패키지 의존성 정리") → 에이전트2 → 결과
  └→ Task("config 파일 통합 검증") → 에이전트3 → 결과
 
메인 Claude: 3개 결과를 종합하여 마이그레이션 계획 수립

왜 Subagent가 적합했나:

  • 각 패키지 분석은 완전히 독립적
  • 에이전트 간 소통이 필요 없음
  • 분석 결과만 받으면 메인에서 종합 가능
  • 팀을 만드는 오버헤드가 불필요

사례 2: Team — 4인 코드 리뷰 워크플로우

toktokhandev 프로젝트에서 Header/MobileMenu 컴포넌트를 4명의 전문가가 동시 리뷰했다.

팀 구성:

{
  "name": "toktokhandev",
  "members": [
    { "name": "API-리뷰어",    "관점": "Props 흐름, 상태 관리, 타입 안전성" },
    { "name": "UI-퍼블리셔",   "관점": "디자인 토큰, 접근성, 반응형" },
    { "name": "린트-타입체커", "관점": "lint 실행, any 타입, 타입 정합성" },
    { "name": "성능-엔지니어", "관점": "RSC 분리, 애니메이션, 리렌더링" }
  ]
}

왜 Team이 적합했나:

  • 같은 코드를 다른 관점으로 봐야 함
  • 각 리뷰어의 발견이 다른 리뷰어에게 영향을 줄 수 있음
  • 팀 리더가 결과를 종합하여 우선순위 판단
  • 추가 질문이 필요하면 멤버에게 바로 메시지 가능

Team이 빛나는 5가지 패턴

1. 멀티 관점 코드 리뷰

같은 코드를 API, UI, 성능, 린트 관점에서 동시에 리뷰하고 리드가 종합한다.

2. 풀스택 기능 개발

API 엔지니어가 엔드포인트를 만들면 메시지로 프론트엔드에 전달하고, 프론트엔드가 구현하는 동안 테스트 엔지니어가 테스트를 작성한다. 의존성이 있지만 부분적으로 병렬화 가능한 패턴.

3. 대규모 리팩토링 + 안전망

리팩토러가 코드를 변경할 때마다 타입체커와 테스트러너가 즉시 검증한다. 빠른 피드백 루프가 핵심.

4. 다플랫폼 동시 작업

같은 기능을 웹, 모바일, i18n 전문가가 동시에 각 플랫폼으로 구현하고 공통 인터페이스를 공유한다.

5. 문서 + 구현 동시 진행

구현자가 코드를 만들고, 문서 작성자가 바로 API 문서와 README를 업데이트한다.


판단 기준 요약

작업이 독립적인가?
  ├─ YESSubagent (빠르고 가벼움)
  └─ NO → 작업 간 소통이 필요한가?
            ├─ YESTeam (협업 가능)
            └─ NOSubagent (순차 실행으로 충분)
이런 작업이면이걸 써라
5개 파일 각각 타입 에러 확인Subagent
패키지별 의존성 독립 분석Subagent
같은 코드를 다른 관점으로 리뷰Team
API 완성 후 프론트에 전달 필요Team
코드 변경마다 즉시 검증Team

마무리

Subagent와 Team은 도구일 뿐이다. 핵심은 **"이 작업에 에이전트 간 소통이 필요한가?"**를 판단하는 것이다.

  • 소통 불필요 → Subagent로 빠르게
  • 소통 필요 → Team으로 정확하게

오버헤드를 감수할 만큼의 협업 가치가 있을 때만 Team을 쓰자.