AI 코딩 어시스턴트의 패러다임이 바뀌고 있습니다. 이제 하나의 AI와 페어 프로그래밍하는 시대를 넘어, 여러 AI 에이전트가 팀을 이루어 동시에 작업하는 시대가 열렸습니다. Anthropic의 Claude Code에서 제공하는 에이전트 팀(Agent Teams) 기능이 바로 그 핵심입니다.
1. 에이전트 팀이란?
에이전트 팀은 여러 개의 Claude Code 인스턴스가 하나의 팀으로 협력하여 작업하는 실험적 기능입니다. 2026년 2월 Claude Opus 4.6과 함께 출시되었으며, 2~16개의 에이전트가 공유 코드베이스에서 동시에 작업할 수 있습니다.
핵심 구성 요소는 다음과 같습니다:
- 팀 리드(Team Lead): 메인 Claude Code 세션으로, 팀을 생성하고 작업을 할당하며 결과를 종합합니다.
- 팀메이트(Teammates): 각각 독립된 컨텍스트 윈도우를 가진 별도의 Claude Code 인스턴스입니다.
- 공유 태스크 리스트(Task List): 팀원들이 작업을 확인하고 할당받는 공유 작업 목록입니다.
- 메일박스(Mailbox): 에이전트 간 직접 커뮤니케이션을 위한 메시징 시스템입니다.
2. 서브에이전트와의 차이점
Claude Code에는 이미 서브에이전트(Subagents)라는 병렬 작업 기능이 있습니다. 에이전트 팀과의 핵심 차이를 이해하는 것이 중요합니다.
[ 서브에이전트 구조 ]
┌──────────────┐
│ 메인 에이전트 │
└──────┬───────┘
┌───────┼───────┐
▼ ▼ ▼
┌──────┐┌──────┐┌──────┐
│Sub-A ││Sub-B ││Sub-C │
└──┬───┘└──┬───┘└──┬───┘
│ │ │
▼ ▼ ▼
결과 보고 결과 보고 결과 보고
│ │ │
└───────┼───────┘
▼
┌──────────────┐
│ 메인 에이전트 │ ← 모든 조율 담당
└──────────────┘
※ 서브에이전트끼리는 대화 불가
※ 모든 정보가 메인을 경유
[ 에이전트 팀 구조 ]
┌──────────────┐
│ 팀 리드 │
└──────┬───────┘
│ 태스크 할당
┌───────┼───────┐
▼ ▼ ▼
┌──────┐┌──────┐┌──────┐
│팀원 A ││팀원 B ││팀원 C │
└──────┘└──────┘└──────┘
↕ ↕ ↕
직접 메시지 ←→ 직접 메시지
↕ ↕
공유 태스크 리스트 참조
※ 팀원끼리 직접 소통 가능
※ 자율적으로 태스크 선택
서브에이전트
- 메인 에이전트에게만 결과를 보고합니다
- 서브에이전트끼리 서로 대화할 수 없습니다
- 메인 에이전트가 모든 조율을 담당합니다
- 토큰 비용이 상대적으로 낮습니다 (단일 세션 대비 약 2~3배)
- 결과만 중요한 집중 작업에 적합합니다
에이전트 팀
- 팀원끼리 직접 메시지를 주고받습니다
- 공유 태스크 리스트를 통해 자율적으로 조율합니다
- 각 팀원이 완전히 독립적인 컨텍스트를 가집니다
- 토큰 비용이 높습니다 (단일 세션 대비 약 3~7배)
- 토론과 협업이 필요한 복잡한 작업에 적합합니다
한 마디로 정리하면: 서브에이전트는 "보고하는 부하직원"이고, 에이전트 팀은 "서로 소통하는 동료"입니다.
3. 작동 원리
팀 생성 과정
[ 에이전트 팀 작동 흐름 ]
사용자 프롬프트
│
▼
┌─────────────────────────────────┐
│ 1단계: 팀 생성 (TeamCreate) │
│ - 팀 이름/네임스페이스 설정 │
│ - ~/.claude/teams/{name}/에 저장 │
└────────────┬────────────────────┘
│
▼
┌─────────────────────────────────┐
│ 2단계: 태스크 정의 (TaskCreate) │
│ - P0(필수) / P1(핵심) / P2(엣지) │
│ - 태스크 간 의존성 설정 │
└────────────┬────────────────────┘
│
▼
┌─────────────────────────────────┐
│ 3단계: 팀원 스폰 │
│ - 각 팀원에게 역할 프롬프트 전달 │
│ - 독립 컨텍스트 윈도우 할당 │
└────────────┬────────────────────┘
│
┌───────┼───────┐
▼ ▼ ▼
┌────────────────────────────────┐
│ 4단계: 병렬 작업 수행 │
│ Wave 1: 독립 태스크 동시 실행 │
│ Wave 2: Wave 1에 의존하는 태스크 │
│ Wave 3: 최종 조립 태스크 │
└────────────┬───────────────────┘
│
▼
┌────────────────────────────────┐
│ 5단계: 결과 종합 및 정리 │
│ - 팀 리드가 결과 취합 │
│ - TeamDelete로 리소스 정리 │
└────────────────────────────────┘
7가지 핵심 조율 도구
- TeamCreate: 팀 네임스페이스 생성
- TaskCreate: 상세 설명과 함께 작업 단위 정의
- TaskUpdate: 태스크 할당 및 완료 처리
- TaskList: 사용 가능한 작업 조회
- Task (team_name 포함): 팀원 스폰
- SendMessage: 에이전트 간 직접 메시징
- TeamDelete: 팀 리소스 정리
커뮤니케이션 방식
- 자동 메시지 전달: 팀원이 메시지를 보내면 수신자에게 자동 전달됩니다
- 유휴 알림: 팀원이 작업을 마치면 자동으로 팀 리드에게 알립니다
- 태스크 의존성 관리: 선행 태스크 완료 시 의존하는 태스크가 자동으로 언블록됩니다
- 브로드캐스트: 모든 팀원에게 동시에 메시지를 보낼 수 있습니다 (토큰 비용 주의)
- 파일 락킹: 여러 팀원이 동시에 같은 태스크를 선택하는 레이스 컨디션을 방지합니다
디스플레이 모드
- 인프로세스(In-process): 모든 팀원이 하나의 터미널에서 실행됩니다. Shift+Down으로 팀원 간 전환이 가능합니다.
- 분할 패널(Split panes): tmux 또는 iTerm2를 사용하여 각 팀원이 별도 패널에서 보입니다.
4. 설정 방법
에이전트 팀은 실험적 기능이므로 기본적으로 비활성화되어 있습니다. settings.json에 다음을 추가하여 활성화합니다:
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}Claude Code v2.1.32 이상이 필요합니다. 버전 확인:
claude --version
5. 실전 활용 사례
아래에서는 실제로 에이전트 팀이 어떻게 활용되었는지, 인터넷에서 수집한 구체적인 사례들을 자세히 살펴보겠습니다.
사례 1: 9개 에이전트 병렬 코드 리뷰 시스템
출처: HAMY - 9 Parallel AI Agents That Review My Code
개발자 HAMY는 코드 리뷰의 품질을 극대화하기 위해 9개의 병렬 에이전트를 각각 전문 영역에 배치하는 시스템을 구축했습니다.
[ 9개 에이전트 병렬 코드 리뷰 구조 ]
┌────────────────┐
│ /code-review │ ← 슬래시 커맨드 실행
└───────┬────────┘
│ PR diff 분석
┌─────────┬───────┼───────┬─────────┐
▼ ▼ ▼ ▼ ▼
┌────────┐┌────────┐┌────────┐┌────────┐┌────────┐
│테스트 ││린터 & ││코드 ││보안 ││품질 & │
│러너 ││정적분석││리뷰어 ││리뷰어 ││스타일 │
└────────┘└────────┘└────────┘└────────┘└────────┘
▼ ▼ ▼ ▼ ▼
┌────────┐┌────────┐┌────────┐┌────────┐
│테스트 ││성능 ││의존성 & ││단순화 & │
│품질 ││리뷰어 ││배포안전 ││유지보수 │
└────────┘└────────┘└────────┘└────────┘
│ │ │ │ │
└─────────┴───────┴───────┴─────────┘
▼
┌────────────────┐
│ 최종 판정 │
│ ✅ Ready to Merge │
│ ⚠️ Needs Attention│
│ ❌ Needs Work │
└────────────────┘
9개 에이전트의 역할:
- 테스트 러너: 테스트 실행 및 통과/실패 상태를 상세 보고
- 린터 & 정적 분석: 린팅 도구와 IDE 진단으로 타입 에러 검출
- 코드 리뷰어: 영향도와 난이도 기준으로 최대 5개의 구체적 개선안 제시
- 보안 리뷰어: 인젝션 위험, 인증 이슈, 시크릿 노출, 민감한 에러 핸들링 점검
- 품질 & 스타일 리뷰어: 복잡도, 데드 코드, 중복, 컨벤션 준수 여부 검토
- 테스트 품질 리뷰어: 커버리지 ROI, 행동 테스트 적절성, 플레이키 리스크 평가
- 성능 리뷰어: N+1 쿼리, 블로킹 연산, 메모리 누수 식별
- 의존성 & 배포 안전 리뷰어: 의존성 변경, 브레이킹 체인지, 배포 우려사항 점검
- 단순화 & 유지보수 리뷰어: 코드 간결성과 변경 원자성 평가
실행 결과:
.claude/commands에 슬래시 커맨드로 설정하여/code-review한 번으로 실행- 브랜치 diff, 스테이징된 파일, 최근 커밋을 자동 감지하여 범위 결정
- 최종 판정: "Ready to Merge" / "Needs Attention" / "Needs Work" 중 하나
- 제안의 약 75%가 실제로 유용하다고 보고
핵심 교훈: 한 명의 리뷰어가 모든 관점을 동시에 갖기는 어렵습니다. 보안을 보면 성능을 놓치고, 성능을 보면 테스트 커버리지를 놓치기 마련입니다. 각 에이전트가 하나의 렌즈에만 집중하게 함으로써 이 문제를 구조적으로 해결합니다.
사례 2: 경쟁 가설을 통한 과학적 디버깅
출처: Claude Code 공식 문서, alexop.dev
원인이 불분명한 버그를 추적할 때, 단일 에이전트는 앵커링 편향(anchoring bias)에 빠지기 쉽습니다. 하나의 그럴듯한 가설을 찾으면 그것에 매몰되어 다른 가능성을 충분히 탐색하지 않는 것입니다.
에이전트 팀은 이를 과학적 토론 방식으로 해결합니다:
[ 경쟁 가설 디버깅 과정 ]
버그 리포트: "앱이 메시지 하나 보낸 후 종료됨"
│
▼
┌──────────────────────────────────┐
│ 팀 리드: 5개 가설별 팀원 배치 │
└──────────┬───────────────────────┘
│
┌──────────┼──────────┬──────────┐
▼ ▼ ▼ ▼
┌─────────┐┌─────────┐┌─────────┐┌─────────┐
│ 팀원 A ││ 팀원 B ││ 팀원 C ││ 팀원 D │
│WebSocket││메모리 ││인증토큰 ││이벤트 │
│연결 문제 ││누수 가설 ││만료 가설 ││루프 가설 │
└────┬────┘└────┬────┘└────┬────┘└────┬────┘
│ │ │ │
▼ ▼ ▼ ▼
독립 조사 독립 조사 독립 조사 독립 조사
│ │ │ │
└──────────┴──────┬───┴──────────┘
▼
┌─────────────────────┐
│ 상호 반증 토론 단계 │
│ │
│ A→B: "메모리 사용량 │
│ 정상인데 증거는?" │
│ │
│ C→A: "WebSocket 로그 │
│ 확인해봤어? 정상임" │
│ │
│ B→C: "토큰 만료 시점 │
│ 과 종료 시점이 불일치" │
└─────────┬───────────┘
▼
┌─────────────────────┐
│ 합의: 이벤트 루프 │
│ 블로킹이 근본 원인 │
└─────────────────────┘
프롬프트 예시:
Users report the app exits after one message instead of staying connected.
Spawn 5 agent teammates to investigate different hypotheses. Have them talk to
each other to try to disprove each other's theories, like a scientific
debate. Update the findings doc with whatever consensus emerges.왜 이 방식이 효과적인가:
- 앵커링 편향 제거: 순차적 조사에서는 첫 번째 가설이 이후 조사에 편향을 줍니다. 병렬 조사는 이를 원천 차단합니다.
- 적극적 반증: 각 팀원의 임무는 자기 가설을 증명하는 것뿐만 아니라 다른 팀원의 가설을 반증하는 것입니다.
- 생존자 편향의 활용: 여러 독립적인 조사자의 반증을 이겨낸 가설이 실제 근본 원인일 가능성이 압도적으로 높습니다.
사례 3: 풀스택 기능 개발 - API 계약 기반 협업
출처: Heeki Park - Collaborating with Agent Teams (Medium)
AWS의 Heeki Park는 에이전트 팀을 활용해 제품 관리 → 개발 → QA 테스트의 전체 제품 전달 라이프사이클을 운영한 실제 경험을 공유했습니다.
[ 풀스택 개발 에이전트 팀 워크플로우 ]
Phase 1: 제품 관리
┌──────────────────────────────┐
│ Claude로 스펙 문서 생성 │
│ - 개요, 수용 기준, 범위 외 항목 │
│ - 로컬 저장 (사람이 검토) │
└──────────────┬───────────────┘
▼
Phase 2: 개발 (에이전트 팀)
┌──────────────────────────────┐
│ "Create an agent team to │
│ work on this Github issue" │
└──────────────┬───────────────┘
│
┌───────────┼───────────┐
▼ ▼ ▼
┌────────┐ ┌────────┐ ┌────────┐
│백엔드 │ │프론트엔드│ │테스트 │
│API 구현 │ │UI 구현 │ │작성 │
└───┬────┘ └───┬────┘ └───┬────┘
│ ↕ │ │
│ API 계약 │ │
│ 공유 │ │
└───────┬──┴───────────┘
▼
Phase 3: 반복 테스트 (15-20분 후)
┌──────────────────────────────┐
│ 인터랙티브 반복 및 UX 최적화 │
│ (수 시간에 걸친 정교한 조정) │
└──────────────────────────────┘
핵심 전략 - API 계약 우선 공유:
백엔드 에이전트가 API 엔드포인트 계약(요청/응답 형식)을 프론트엔드 에이전트와 구현 시작 전에 공유하게 합니다. 이렇게 하면 서로 호환되지 않는 가정에서 발생하는 버그를 원천 차단할 수 있습니다.
실전에서 발견한 교훈들:
- 디렉토리 컨텍스트 관리: git worktree로 여러 브랜치를 동시에 사용할 때, 각각 별도의 환경 설정이 필요합니다. 메인 브랜치에서 서버를 실행하면서 피처 브랜치를 수정하면 혼란이 생깁니다.
- 머지 충돌: 3개의 병렬 에이전트 팀이 모놀리식 코드베이스에서 작업하면 "상당한 양의 머지 충돌"이 발생합니다. 순차적 리뷰와 리베이스 워크플로우로 해결했습니다.
- 스펙 품질이 병목: 에이전트의 능력이 아니라 스펙의 품질이 결과물의 품질을 결정합니다. 첫 번째 구현은 빠르게 나오지만, 진짜 원하는 UX는 반복 과정에서 드러납니다.
- 대규모 조직에 더 적합: 독립적이고 겹치지 않는 피처 요청이 많은 대규모 조직에서 에이전트 팀의 효과가 극대화됩니다.
사례 4: 16개 에이전트로 10만 줄 C 컴파일러 개발
출처: Anthropic Engineering - Building a C Compiler
Anthropic의 Nicholas Carlini가 수행한 이 프로젝트는 에이전트 팀의 한계를 시험한 가장 극단적인 실제 사례입니다.
[ C 컴파일러 프로젝트 구조 ]
┌─────────────────────────────────────┐
│ 공유 Git 저장소 (/upstream) │
│ current_tasks/ ← 태스크 락 파일 │
└───────────────────┬─────────────────┘
│
┌───┬───┬───┬───┬───┼───┬───┬───┬───┐
▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼
[1] [2] [3] [4] [5] [6] ... [14][15][16]
│ │ │ │ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼
각각 독립된 Docker 컨테이너
/workspace (로컬) ↔ /upstream (공유)
┌──────────────────────────────┐
│ 작업 흐름 (무한 루프) │
│ 1. current_tasks/에서 태스크 │
│ 락 파일로 작업 선점 │
│ 2. /workspace에서 구현 │
│ 3. upstream 변경사항 머지 │
│ 4. 충돌 해결 후 푸시 │
│ 5. 락 파일 삭제 │
│ 6. 다음 태스크 자동 선택 │
└──────────────────────────────┘
프로젝트 규모:
- 기간: 약 2주
- 세션 수: ~2,000개의 Claude Code 세션
- 토큰: 입력 20억, 출력 1억 4천만
- 비용: ~$20,000
- 결과물: 100,000줄의 Rust 컴파일러
달성 성과:
- GCC torture 테스트 스위트 99% 통과율
- x86, ARM, RISC-V에서 부팅 가능한 Linux 6.9 빌드
- QEMU, FFmpeg, SQLite, PostgreSQL, Redis, Doom 컴파일 성공
- SSA 중간 표현을 사용한 다중 최적화 패스
- 클린룸 환경 (인터넷 접근 없음, Rust 표준 라이브러리만 사용)
핵심 혁신 - GCC 오라클 기법:
16개 에이전트가 모두 동일한 버그에 막혔을 때, 혁신적인 방법을 도입했습니다. 커널 파일을 무작위로 GCC로 컴파일한 뒤, Claude의 컴파일러로는 일부만 선택적으로 재컴파일하는 바이너리 서치 접근법입니다. 이를 통해 에이전트들이 서로 다른 파일의 버그를 동시에 격리할 수 있었습니다.
주목할 만한 에피소드:
- 한 에이전트가 실수로
pkill -9 bash를 실행하여 자기 자신을 종료시키는 사건도 발생 - 16비트 x86 코드에서 에이전트가 생성한 코드가 60KB로 32KB 제한을 초과하여 해당 단계만 GCC에 위임
--fast플래그로 1~10%의 랜덤 샘플만 테스트하여 불필요한 수 시간의 테스트 방지
사례 5: 블로그 사이트 병렬 QA - 3분 만에 완전한 품질 보고서
출처: alexop.dev - From Tasks to Swarms
개발자 alexop은 localhost:4321에서 실행 중인 블로그 사이트에 대해 5개의 에이전트로 구성된 QA 스웜을 운영했습니다. 브라우저 자동화 도구 없이 curl과 HTML 파싱만으로 3분 만에 종합적인 QA 리포트를 생성한 사례입니다.
[ 블로그 QA 스웜 구조 ]
프롬프트: "블로그 사이트 전체 QA 수행"
│
▼
┌────────────────────────────────────┐
│ 팀 리드: QA 영역별 5개 팀원 배치 │
└────────────────┬───────────────────┘
│
┌────────┬───────┼───────┬────────┐
▼ ▼ ▼ ▼ ▼
┌───────┐┌───────┐┌───────┐┌───────┐┌───────┐
│팀원 A ││팀원 B ││팀원 C ││팀원 D ││팀원 E │
│ ││ ││ ││ ││ │
│핵심 ││블로그 ││링크 ││SEO ││접근성 │
│페이지 ││포스트 ││무결성 ││메타 ││검사 │
│응답 ││렌더링 ││검사 ││데이터 ││ │
└───┬───┘└───┬───┘└───┬───┘└───┬───┘└───┬───┘
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
16개 URL 83개 포스트 146개 RSS피드 헤딩 계층
HTTP 상태 h1, meta, 내부 URL robots ARIA 속성
코드 검증 이미지 검사 스크린 og:tags 테마 전환
검사 검증 기능 검사
│ │ │ │ │
└────────┴────────┴────┬───┴────────┘
▼
┌─────────────────────┐
│ 종합 QA 리포트 │
│ 총 소요 시간: 3분 │
└─────────────────────┘
각 에이전트의 상세 작업:
팀원 A - 핵심 페이지 응답 검사:
- 16개 주요 URL에 대해 HTTP 상태 코드 확인
- 응답 시간 측정 및 리다이렉트 동작 검증
- 404 페이지의 적절한 처리 확인
팀원 B - 블로그 포스트 렌더링 검사:
- 83개 전체 포스트에 대해 h1 태그 존재 여부 확인
- meta 태그(description, author) 적절성 검증
- 이미지 로딩 및 alt 속성 검사
팀원 C - 링크 무결성 검사:
- 146개 내부 URL을 크롤링하여 깨진 링크 탐지
- 앵커 링크의 대상 요소 존재 확인
- 외부 링크의 응답 상태 확인
팀원 D - SEO 메타데이터 검사:
- RSS 피드 유효성 검증
- robots.txt 설정 적절성 확인
- Open Graph 태그 (og:title, og:description, og:image) 검사
팀원 E - 접근성 검사:
- 헤딩 계층 구조 (h1→h2→h3) 올바른지 확인
- ARIA 속성 적절성 검사
- 테마 전환(다크/라이트 모드) 기능 동작 확인
발견된 10가지 이슈 (우선순위별):
심각(Major):
<html class="false">— 불리언 값이 문자열로 변환되는 버그- 헤딩 계층 구조 문제 — h1에서 바로 h3으로 건너뛰는 케이스
- 테마 토글 버튼 누락
중간(Medium):
- og:type 메타 태그 누락
- 2개의 포스트에서 OG 이미지 깨짐
경미(Minor):
- 다양한 접근성 관련 개선 사항
핵심 포인트: 브라우저 자동화 도구(Selenium, Playwright 등) 없이도 curl과 HTML 파싱만으로 이 수준의 QA가 가능했다는 점이 주목할 만합니다. 5개 에이전트가 병렬로 개발 서버에 접근하여 각자의 영역을 동시에 검사하므로, 순차적으로 수행했다면 15분 이상 걸렸을 작업을 3분 만에 완료했습니다.
사례 6: OpenObserve의 "에이전트 의회" - 380개에서 700개 이상으로 테스트 확장
출처: OpenObserve - How AI Agents Automated Our QA
관측성(Observability) 플랫폼 OpenObserve는 8개의 전문 AI 에이전트로 구성된 "Council of Sub Agents(에이전트 의회)"를 구축하여 E2E 테스트 파이프라인 전체를 자동화했습니다. 이것은 에이전트 팀의 개념을 프로덕션 QA 프로세스에 적용한 가장 체계적인 사례 중 하나입니다.
[ OpenObserve "에이전트 의회" 6단계 파이프라인 ]
새 기능 요청
│
▼
┌────────────────────────────────────────┐
│ Phase 1: The Analyst (분석가) │
│ 소스코드 분석 → data-test 셀렉터 추출 │
│ → 사용자 워크플로우 매핑 → 엣지 케이스 식별 │
│ → Feature Design Document 생성 │
└────────────────┬───────────────────────┘
▼
┌────────────────────────────────────────┐
│ Phase 2: The Architect (설계자) │
│ 우선순위별 테스트 계획 수립 │
│ P0: 크리티컬 / P1: 핵심 / P2: 엣지 │
└────────────────┬───────────────────────┘
▼
┌────────────────────────────────────────┐
│ Phase 3: The Engineer (엔지니어) │
│ Playwright 테스트 코드 생성 │
│ Page Object Model 패턴 적용 │
│ Phase 1의 셀렉터 + Phase 2의 계획 활용 │
└────────────────┬───────────────────────┘
▼
┌────────────────────────────────────────┐
│ Phase 4: The Sentinel (감시자) 🚫 │
│ 프레임워크 위반, 안티패턴, 보안 이슈 감사 │
│ ★ 크리티컬 문제 발견 시 파이프라인 차단 ★ │
└────────────────┬───────────────────────┘
▼
┌────────────────────────────────────────┐
│ Phase 5: The Healer (치유사) 🔄 │
│ 테스트 실행 → 실패 진단 → 수정 │
│ ★ 최대 5회 반복 시도 ★ │
│ (셀렉터 문제, 타이밍 버그 등 자동 수정) │
└────────────────┬───────────────────────┘
▼
┌────────────────────────────────────────┐
│ Phase 6: The Scribe (기록관) │
│ TestDino(테스트 관리 시스템)에 문서화 │
└────────────────────────────────────────┘
+ The Orchestrator: 전체 파이프라인 라우팅
+ The Test Inspector: GitHub PR 독립 리뷰
8개 에이전트의 역할 상세:
- The Orchestrator (오케스트레이터): 기능을 파이프라인에 라우팅하고, 테스트 범위(OSS vs Enterprise)를 결정하며, 워크플로우 진행을 관리합니다.
- The Analyst (분석가): 소스 코드를 분석하여 data-test 셀렉터를 추출하고, 사용자 워크플로우를 매핑하며, 엣지 케이스를 식별합니다. 이 단계의 출력이 전체 파이프라인의 기초인 Feature Design Document가 됩니다.
- The Architect (설계자): P0(크리티컬), P1(핵심 기능), P2(엣지 케이스)로 우선순위를 구분한 테스트 계획을 수립합니다.
- The Engineer (엔지니어): Playwright 테스트 코드를 생성합니다. 분석가의 Feature Design Document와 설계자의 테스트 계획을 모두 참조하여 Page Object Model 패턴을 따르는 코드를 작성합니다.
- The Sentinel (감시자): 품질 관문 역할을 합니다. 프레임워크 위반, 안티패턴, 보안 이슈를 감사하며, 크리티컬 문제 발견 시 파이프라인 전체를 차단합니다. 이 강제 차단 메커니즘이 Page Object Model 패턴의 표준화를 강제했습니다.
- The Healer (치유사): 테스트를 실행하고, 실패를 진단하며, 셀렉터 문제나 타이밍 버그 등을 자동으로 수정합니다. 최대 5회까지 반복 시도하여 시스템을 단순한 자동화가 아닌 진정한 자율 시스템으로 만듭니다.
- The Scribe (기록관): 모든 출력을 TestDino 테스트 관리 시스템에 문서화합니다.
- The Test Inspector (테스트 감사관): GitHub PR에서 E2E 테스트 변경사항을 독립적으로 리뷰하며, Sentinel과 동일한 감사 규칙을 적용합니다.
성과 지표 (Before → After):
기능 분석 시간: 45~60분 → 5~10분 (6~10배 개선)
플레이키 테스트 수: 30~35개 → 4~5개 (85% 감소)
테스트 커버리지: 380개 → 700개 이상 (84% 증가)
첫 통과 테스트까지: ~1시간 → ~5분 (~12배 개선)
실제 버그 발견 사례 - ServiceNow 통합 버그:
"Prebuilt Alert Destinations" 기능을 테스트하던 중, The Healer가 프로덕션에 존재하던 실제 버그를 발견했습니다. ServiceNow 연동 폼이 "Loading destination data..." 메시지만 무한히 표시하는 문제였습니다.
근본 원인: URL 파싱 로직의 결함
// 기존 (버그)
hostname.split('.').slice(-3, -1).join('.') === 'service-now'
// 수정
hostname.endsWith('.service-now.com')이 버그는 프로덕션에 배포되어 있었지만 고객 리포트가 아직 없던 침묵의 실패(silent failure)였습니다. 에이전트 의회의 자율 테스트 과정에서 자연스럽게 발견된 것입니다.
핵심 교훈:
- "슈퍼 에이전트"는 실패한다: 초기에 모든 것을 하는 하나의 강력한 에이전트를 시도했지만 실패. 분석만, 감사만, 디버깅만 하는 경계가 분명한 전문 에이전트가 훨씬 효과적이었습니다.
- 컨텍스트 체이닝이 핵심: 각 에이전트가 이전 단계의 산출물을 풍부한 컨텍스트로 받아서 지능적인 판단이 가능합니다.
- 반복 시도가 자율성의 열쇠: The Healer의 5회 반복 시도 메커니즘이 시스템을 자동화에서 자율 시스템으로 격상시킵니다.
- 사람의 리뷰는 여전히 가치 있음: 리뷰 시간이 수 시간에서 수 분으로 줄었지만, 산출물이 일관되고 사전 감사를 거쳤기 때문입니다.
6. 비용 대비 효과 비교
에이전트 팀은 강력하지만 토큰 비용이 상당합니다. 같은 작업에 대한 세 가지 접근법의 비용을 비교해 보겠습니다:
동일한 작업 수행 시 토큰 사용량 비교
단일 세션: ~200K 토큰 ████░░░░░░░░░░ 가장 저렴
서브에이전트 3개: ~440K 토큰 ████████░░░░░░ 중간
에이전트 팀 3명: ~800K 토큰 ██████████████ 가장 비쌈
에이전트 팀이 비용 대비 효과적인 경우:
✅ 팀원 간 실제 커뮤니케이션이 필요한 작업
✅ 다중 파일/모듈에 걸친 복잡한 기능 개발
✅ 경쟁 가설이 필요한 디버깅
✅ 다각적 관점이 필요한 코드 리뷰/QA
단일 세션이나 서브에이전트가 나은 경우:
❌ 순차적 작업
❌ 같은 파일을 편집하는 작업
❌ 의존성이 많은 작업
❌ 일상적인 루틴 작업
7. 모범 사례 (Best Practices)
적절한 팀 규모 선택
- 대부분의 워크플로우에서 3~5명의 팀원으로 시작하세요
- 팀원당 5~6개의 태스크가 적당합니다
- 독립적인 태스크 15개가 있다면 3명의 팀원이 좋은 출발점입니다
- 집중된 3명이 산만한 5명보다 나은 성과를 냅니다
충분한 컨텍스트 제공
팀원은 팀 리드의 대화 기록을 상속받지 않습니다. 스폰 프롬프트에 작업별 세부 사항을 포함시키세요.
계획 먼저, 실행은 나중에
Plan 모드로 먼저 승인 가능한 계획(~10K 토큰)을 얻은 후, 해당 계획을 의존성이 있는 팀 태스크로 실행하세요. Wave 1(독립 태스크) → Wave 2(Wave 1 의존) → Wave 3(최종 조립) 순서로 진행합니다.
파일 충돌 방지
두 팀원이 같은 파일을 편집하면 덮어쓰기가 발생합니다. 각 팀원이 서로 다른 파일 세트를 담당하도록 작업을 분배하세요.
품질 관리 훅(Hooks) 활용
- TeammateIdle: 팀원이 유휴 상태가 되려 할 때 실행 — 피드백을 보내 작업을 계속하게 할 수 있습니다
- TaskCreated: 태스크 생성 시 검증 — 부적절한 태스크 생성을 차단합니다
- TaskCompleted: 태스크 완료 시 품질 확인 — 테스트 미통과 시 완료를 차단합니다
8. 현재 제한 사항
- 세션 재개 시 인프로세스 팀원이 복원되지 않습니다
- 태스크 상태 업데이트가 지연될 수 있습니다
- 세션당 하나의 팀만 운영 가능합니다
- 중첩 팀(팀원이 또 다른 팀을 만드는 것)은 불가능합니다
- 팀 리드는 고정되며 변경할 수 없습니다
- 분할 패널 모드는 tmux 또는 iTerm2가 필요합니다
- 팀원 간 커뮤니케이션이 가끔 유실될 수 있습니다 (실험적 기능)
9. 핵심 인사이트: 생성에서 검증으로
멀티 에이전트 코딩 오케스트레이션 분야의 전문가 Addy Osmani는 이렇게 지적합니다:
"병목점이 코드 생성에서 검증으로 이동했다. 에이전트는 인상적인 결과물을 빠르게 만들어내지만, 엄격한 검토 없이 신뢰하면 복합적인 아키텍처 부채가 발생한다."
에이전트 팀은 강력한 도구이지만, 궁극적으로 아키텍처 결정, 기능 거부, 시스템 이해 유지에서 인간의 판단은 여전히 대체 불가능합니다. 뛰어난 엔지니어가 에이전트 팀을 활용할 때 더 큰 레버리지를 얻는 이유가 바로 여기에 있습니다.
마무리
클로드 에이전트 팀은 아직 실험적 기능이지만, AI 기반 소프트웨어 개발의 미래를 엿볼 수 있는 강력한 도구입니다. 단일 에이전트로는 불가능했던 병렬 탐색, 교차 검증, 다각적 분석이 가능해지며, 특히 코드 리뷰, 디버깅, 풀스택 개발, QA 자동화에서 진가를 발휘합니다.
시작하려면 3~5명의 팀원으로 리서치와 리뷰 같은 비파괴적 작업부터 시도해 보세요. 파일을 수정하지 않는 작업에서 병렬 탐색의 가치를 경험한 후, 점진적으로 구현 작업으로 확장하는 것이 권장되는 접근법입니다.
참고 자료:
- Claude Code 공식 문서 - Agent Teams
- Anthropic Engineering - Building a C Compiler with Parallel Claudes
- OpenObserve - How AI Agents Automated Our QA: 700+ Test Coverage
- alexop.dev - From Tasks to Swarms: Agent Teams in Claude Code
- Heeki Park - Collaborating with Agent Teams in Claude Code
- HAMY - 9 Parallel AI Agents That Review My Code
- Cobus Greyling - Claude Code Agent Teams (Medium)
- Addy Osmani - The Code Agent Orchestra
- paddo.dev - Agent Teams: The Switch Got Flipped
'프로그래밍 PROGRAMMING > 인공지능 AI' 카테고리의 다른 글
| Claude Code Hooks 란? - AI 코딩 워크플로우를 자동화하는 강력한 무기 (0) | 2026.04.08 |
|---|---|
| Claude Code 소스코드 51만 줄 유출 사건 — npm 설정 실수로 드러난 내부 구조 분석 (2) | 2026.04.05 |
| [AI] 프롬프트 엔지니어링: LLM의 성능을 높이는 기법 (0) | 2026.02.25 |
| [AI] AI 시대 개발자의 역할: 자동화에서 설계로의 패러다임 전환 (1) | 2026.02.24 |
| [AI] 로우코드로 개발 속도 높이기: 언제 어떻게 쓸까 (1) | 2026.02.23 |