2026년 2월 6일, Anthropic이 Claude Code Agent Teams를 연구 프리뷰로 공식 출시했습니다. settings.json에 한 줄 추가하면 여러 AI 에이전트가 팀으로 병렬 작업하는 기능인데, 프롬프트를 어떻게 쓰느냐에 따라 결과가 완전히 달라집니다.
코드 리뷰 혼자 하면서 “이거 놓친 거 없나…” 불안했던 적 있죠?
디버깅하다가 한 가설에 꽂혀서 3시간 날린 적 있죠?
풀스택 기능 만들면서 프론트 고치면 백엔드 터지고, 백엔드 고치면 테스트 깨지는 무한 루프 경험 있죠?
저도 다 겪어봤어요.
그래서 에이전트 팀 기능이 나왔을 때 “이거다!” 싶었거든요.
근데요.
켜기만 하면 잘 될 줄 알았는데, 그게 아니었어요.
“팀 만들어줘” 하고 아무렇게나 프롬프트를 던지면, 팀원들이 중복 작업하거나, 같은 파일을 건드려서 충돌 나거나, 리드가 갑자기 직접 코딩을 시작하거나…
진짜 사람 팀이랑 똑같아요. 지시를 명확하게 안 하면 혼돈이 시작됩니다.
그래서 정리했어요.
상황별로 어떻게 팀을 구성하고, 프롬프트를 어떻게 써야 하는지.
직접 써보면서 “이건 된다 / 이건 안 된다” 검증한 레시피 10개.
토큰 아끼는 팁까지.
먼저 알아야 할 핵심 원칙 3가지
레시피로 들어가기 전에, 이 3가지를 먼저 머릿속에 넣으세요.
원칙 1: “팀원이 독립적으로 일할 수 있는가?”
이게 에이전트 팀 사용 여부를 결정하는 유일한 기준이에요.
✅ 팀원 A가 src/api/ 작업, 팀원 B가 src/components/ 작업 → 독립적. 에이전트 팀 적합. ❌ 팀원 A가 API 응답 구조를 바꾸면 팀원 B의 프론트가 깨짐 → 의존적. 단일 에이전트가 나음.
이 질문에 “Yes”가 아니면, 에이전트 팀 쓰지 마세요. 토큰만 낭비합니다.
원칙 2: “파일 경계를 명확히 나눠라”
두 팀원이 같은 파일을 수정하면 덮어쓰기가 발생합니다.
이건 Anthropic 공식 문서에서도 명시한 경고예요.
프롬프트에 반드시 각 팀원의 파일 영역을 지정해야 해요.
✅ "Backend 팀원은 src/api/만 수정해.
Frontend 팀원은 src/components/만 수정해.
서로의 디렉토리 절대 건드리지 마."
❌ "팀원들이 알아서 나눠서 작업해."
→ 십중팔구 같은 파일 충돌.
원칙 3: “팀원에게 리드의 대화 기록은 전달되지 않는다”
이거 모르면 계속 헤매요.
팀원이 스폰될 때 CLAUDE.md, MCP 서버, 스킬은 자동으로 로드됩니다.
하지만 리드와 사용자가 나눈 대화 내용은 상속되지 않아요.
그래서 팀원 스폰 프롬프트에 충분한 컨텍스트를 직접 넣어줘야 합니다.
✅ "보안 리뷰어를 스폰해줘. 프롬프트:
'src/auth/ 디렉토리의 인증 모듈을 리뷰해.
JWT 토큰은 httpOnly 쿠키에 저장하고 있어.
Redis로 세션 관리 중이야.
토큰 만료, 세션 하이재킹, 입력 검증에 집중해줘.
심각도 등급과 함께 리포트해줘.'"
❌ "보안 리뷰어 스폰해줘."
→ 뭘 리뷰해야 하는지 모름. 프로젝트 전체를 읽느라 토큰 낭비.
레시피 1: 병렬 코드 리뷰 (3명 팀)
언제 쓰나?
PR이 크거나, 여러 관점에서 동시에 리뷰가 필요할 때.
혼자 리뷰하면 보안에 집중하다 성능을 놓치고, 성능 보다가 테스트 커버리지를 놓치잖아요.
팀 구성
| 역할 | 모델 | 담당 |
|---|---|---|
| 보안 리뷰어 | Sonnet | 취약점, 인증, 입력 검증 |
| 성능 리뷰어 | Sonnet | 쿼리 최적화, 메모리, 알고리즘 |
| 테스트 리뷰어 | Sonnet | 커버리지, 엣지 케이스, 누락 테스트 |
프롬프트
에이전트 팀을 만들어서 PR #142를 리뷰해줘. 3명의 리뷰어를 스폰해: 1) 보안 리뷰어 - Sonnet 모델 사용 "src/ 디렉토리의 변경 사항을 보안 관점에서 리뷰해. SQL 인젝션, XSS, 인증 우회, 민감 데이터 노출에 집중. 발견한 이슈는 심각도(Critical/High/Medium/Low)와 함께 정리해." 2) 성능 리뷰어 - Sonnet 모델 사용 "변경 사항의 성능 영향을 분석해. N+1 쿼리, 불필요한 렌더링, 메모리 누수 가능성에 집중. Big-O 복잡도 변화가 있으면 명시해." 3) 테스트 리뷰어 - Sonnet 모델 사용 "테스트 커버리지를 검증해. 새 코드에 대한 테스트 누락, 엣지 케이스 미처리, 기존 테스트의 깨짐 여부를 확인해." 각자 리뷰 완료 후 발견 사항을 나에게 종합해서 보고해.
비용 팁
리뷰어는 코드를 읽기만 하니까 Sonnet이면 충분합니다.
Opus는 필요 없어요. Sonnet으로 돌리면 토큰 비용 약 60% 절약.
기대 효과
| 방식 | 시간 | 관점 |
|---|---|---|
| 혼자 리뷰 | 30분 | 1개 관점에 편향 |
| 3인 팀 리뷰 | 10분 | 3개 관점 동시 |
레시피 2: 경쟁 가설 디버깅 (5명 팀)
언제 쓰나?
버그 원인을 모를 때. 특히 “뭔가 간헐적으로 터지는데 원인을 모르겠다” 할 때.
왜 팀으로?
혼자 디버깅하면 앵커링 바이어스에 걸려요.
첫 번째 가설이 그럴듯하면, 무의식적으로 그것만 파고들어요.
5명이 각자 다른 가설을 세우고 서로 반박하면, 살아남는 가설이 진짜 원인일 확률이 훨씬 높아요.
프롬프트
사용자들이 로그인 후 간헐적으로 세션이 끊기는 버그가 있어. 에러 로그: "Session expired unexpectedly" at src/auth/session.ts:142 에이전트 팀을 만들어서 5가지 가설을 동시에 조사해줘. 각 팀원은 하나의 가설만 맡아: 1) "Redis 세션 TTL 설정 오류" 2) "JWT 토큰 갱신 로직 레이스 컨디션" 3) "로드 밸런서의 스티키 세션 미설정" 4) "쿠키 도메인/경로 미스매치" 5) "타임존 차이로 인한 만료 시간 오계산" 핵심 규칙: - 각 팀원은 자기 가설의 증거를 찾아. - 동시에 다른 팀원의 가설을 반증할 증거도 찾아. - 서로 대화하면서 과학적으로 토론해. - 최종적으로 가장 설득력 있는 가설에 합의해. 결과를 종합해서 "가장 유력한 원인 + 근거 + 수정 방안"으로 정리해.
주의사항
팀원이 5명이면 토큰이 5배 가까이 나갑니다.
진짜 원인을 못 찾아서 시간을 낭비하는 것보다는 나은 투자지만, 간단한 버그에는 절대 쓰지 마세요.
“null 체크 빠졌네” 같은 건 단일 에이전트면 10초예요.
쓸지 말지 판단 기준
이 버그를 30분 안에 혼자 잡을 수 있는가? ├── Yes → 단일 에이전트 └── No → 에이전트 팀 (경쟁 가설)
레시피 3: 풀스택 기능 개발 (3명 팀)
언제 쓰나?
새 기능이 프론트엔드 + 백엔드 + 테스트 모두 필요할 때.
팀 구성
| 역할 | 모델 | 파일 영역 |
|---|---|---|
| Backend | Opus | src/api/, src/services/ |
| Frontend | Sonnet | src/components/, src/pages/ |
| Test | Sonnet | tests/ |
프롬프트
사용자 대시보드 기능을 만들 거야. 에이전트 팀을 구성해줘.
1) Backend 팀원 - Opus 모델
"src/api/dashboard/ 에 REST API를 만들어.
GET /api/dashboard - 사용자 통계 조회
GET /api/dashboard/activity - 최근 활동 목록
기존 인증 미들웨어(src/middleware/auth.ts) 사용해.
응답 스키마를 먼저 정의하고 시작해."
2) Frontend 팀원 - Sonnet 모델
"src/components/dashboard/ 에 React 컴포넌트를 만들어.
DashboardPage, StatsCard, ActivityFeed 컴포넌트.
기존 디자인 시스템(src/components/ui/) 활용해.
API 응답 타입: { stats: {...}, activities: [...] }
API가 아직 안 되어 있으면 목업 데이터로 먼저 작업해."
3) Test 팀원 - Sonnet 모델
"tests/dashboard/ 에 통합 테스트를 작성해.
API 엔드포인트 테스트 + 컴포넌트 렌더링 테스트.
Backend과 Frontend 팀원의 코드가 올라오면 기반으로 작성해."
각 팀원은 자기 디렉토리만 수정해.
Backend이 API 스키마를 확정하면 Frontend과 Test에 공유해.
핵심 포인트
Backend은 Opus, 나머지는 Sonnet.
API 설계는 아키텍처 판단이 필요하니까 Opus가 낫고, 프론트엔드 컴포넌트랑 테스트는 패턴이 명확하니까 Sonnet이면 충분해요.
이렇게만 해도 전부 Opus 쓸 때 대비 토큰 비용 40% 이상 절약됩니다.
의존성 처리
Test 팀원은 Backend과 Frontend 결과물에 의존하잖아요.
프롬프트에 “API가 아직 안 되어 있으면 목업 데이터로 먼저 작업해”를 넣었어요.
이러면 Test 팀원도 대기 없이 바로 작업 시작할 수 있고, 나중에 실제 코드가 오면 맞춰서 수정하면 됩니다.
레시피 4: 기술 스택 비교 리서치 (4명 팀)
언제 쓰나?
“우리 프로젝트에 상태 관리를 뭘 쓸까?” 같은 기술 선택 앞에서.
프롬프트
React 앱의 상태 관리 라이브러리를 선정해야 해. 에이전트 팀을 구성해서 비교 분석해줘. 전부 Sonnet 모델. 1) Redux Toolkit 조사 팀원 "Redux Toolkit의 장점, 단점, 번들 사이즈, 학습 곡선, 커뮤니티 규모, 최신 업데이트를 조사해. 실제 사용하는 대형 프로젝트 사례 3개 이상 찾아." 2) Zustand 조사 팀원 "Zustand의 장점, 단점, 번들 사이즈, 학습 곡선, 커뮤니티 규모, 최신 업데이트를 조사해. 실제 사용하는 대형 프로젝트 사례 3개 이상 찾아." 3) Jotai 조사 팀원 "Jotai의 장점, 단점, 번들 사이즈, 학습 곡선, 커뮤니티 규모, 최신 업데이트를 조사해. 실제 사용하는 대형 프로젝트 사례 3개 이상 찾아." 4) Devil's Advocate (반론 전문) "나머지 3명의 조사 결과를 받으면, 각 라이브러리의 약점을 파고들어. 숨겨진 단점, 마이그레이션 리스크, 장기 유지보수 문제를 지적해." 조사 완료 후 4명이 토론하고, 최종적으로 비교표 + 추천안 + 근거를 정리해.
Devil’s Advocate가 핵심
4번째 팀원, “반론 전문가”가 없으면 각 팀원이 자기 라이브러리를 옹호만 해요.
진짜 사람 팀에서도 마찬가지잖아요. 누군가가 “그런데 이건 어때?”라고 질문해줘야 결정의 질이 올라가요.
레시피 5: 레거시 코드 리팩토링 (3명 팀)
언제 쓰나?
오래된 코드를 현대적으로 바꿔야 하는데, 범위가 넓을 때.
프롬프트
src/legacy/ 디렉토리의 클래스 기반 React 컴포넌트를 함수형 + 훅 기반으로 리팩토링할 거야. 에이전트 팀을 구성해줘. 변경 전에 계획 승인을 받도록 해. 1) 분석가 팀원 - Sonnet "src/legacy/ 의 모든 컴포넌트를 분석해. 의존성 관계, 공유 상태, 사이드 이펙트를 매핑해. 리팩토링 우선순위와 위험도를 정리해." 2) 리팩토링 팀원 A - Opus "분석가의 결과를 기반으로 src/legacy/components/ 디렉토리를 리팩토링해. 클래스 컴포넌트 → 함수형 컴포넌트 + 훅. 기존 기능이 깨지지 않도록 1:1 변환 우선." 3) 리팩토링 팀원 B - Opus "분석가의 결과를 기반으로 src/legacy/pages/ 디렉토리를 리팩토링해. 클래스 컴포넌트 → 함수형 컴포넌트 + 훅. 기존 기능이 깨지지 않도록 1:1 변환 우선." 핵심 규칙: - 분석가가 먼저 완료하고, 결과를 두 리팩토링 팀원에게 공유해. - 리팩토링 팀원은 계획을 먼저 제출하고 승인받은 후 실행해. - 팀원 A와 B는 서로 다른 디렉토리만 수정해.
Plan Approval이 핵심
리팩토링은 잘못하면 기존 기능이 깨져요.
“계획 승인을 받도록 해”를 넣으면, 팀원이 코드를 건드리기 전에 리드한테 계획서를 제출합니다.
리드가 검토하고 “OK” 해야 실행이 시작돼요.
이거 실제 코드 리뷰 프로세스랑 똑같잖아요.
레시피 6: 문서화 + 테스트 보강 (2명 팀)
언제 쓰나?
코드는 있는데 문서도 없고 테스트도 없는 슬픈 현실에서.
프롬프트
src/services/ 디렉토리에 문서화와 테스트가 부족해. 에이전트 팀 2명을 만들어서 병렬로 작업해줘. 전부 Sonnet. 1) 문서화 팀원 "src/services/ 의 모든 함수에 대해: - JSDoc 주석 추가 - README.md에 API 레퍼런스 작성 - 사용 예시 코드 포함 파일을 수정하되, 코드 로직은 절대 변경하지 마." 2) 테스트 팀원 "src/services/ 의 모든 exported 함수에 대해: - tests/services/ 에 유닛 테스트 작성 - 정상 케이스 + 엣지 케이스 + 에러 케이스 - 기존 테스트가 있으면 보완만 src/services/ 파일은 읽기만 하고 수정하지 마."
2명이면 충분한 이유
문서화와 테스트 작성은 서로 완전히 독립적이에요.
문서 팀원은 소스 파일을 읽고 주석/README를 쓰고, 테스트 팀원은 소스 파일을 읽고 tests/ 에 테스트를 쓰고.
교차하는 파일이 없으니까 충돌도 없어요.
3명 이상은 오버헤드만 늘어납니다.
레시피 7: API 마이그레이션 (4명 팀)
언제 쓰나?
REST → GraphQL, v1 → v2 같은 API 버전 마이그레이션.
프롬프트
REST API를 GraphQL로 마이그레이션할 거야. 에이전트 팀을 구성해줘. 1) 스키마 설계자 - Opus "기존 REST 엔드포인트(src/api/routes/)를 분석해서 GraphQL 스키마(src/graphql/schema/)를 설계해. 타입, 쿼리, 뮤테이션 정의. 계획 승인 후 실행." 2) 리졸버 개발자 - Opus "스키마 설계자의 결과를 기반으로 src/graphql/resolvers/ 에 리졸버를 구현해. 기존 서비스 레이어(src/services/) 재활용." 3) 클라이언트 업데이트 - Sonnet "기존 REST 호출(src/client/api/)을 GraphQL 쿼리로 변환해. apollo-client 사용. 기존 컴포넌트의 데이터 흐름 유지." 4) 호환성 테스터 - Sonnet "REST API와 GraphQL API의 응답이 동일한지 비교 테스트 작성. tests/migration/ 디렉토리에 작성. 모든 엔드포인트에 대해 1:1 비교." 의존성: - 스키마 설계 완료 → 리졸버 개발 시작 - 리졸버 완료 → 클라이언트 업데이트 + 호환성 테스트 동시 시작
의존성 명시가 중요
이 시나리오는 완전 병렬이 아니에요.
스키마가 먼저 나와야 나머지가 시작할 수 있어요.
프롬프트에 의존성을 명시적으로 적어주면 리드가 알아서 순서를 조율합니다.
안 적으면? 리졸버 개발자가 스키마 없이 작업 시작해서 나중에 다 고쳐야 합니다.
레시피 8: 보안 감사 (3명 팀)
프롬프트
프로젝트 전체 보안 감사를 에이전트 팀으로 실행해줘. 전부 Sonnet. 1) OWASP Top 10 체커 "OWASP Top 10 기준으로 전체 소스를 스캔해. SQL 인젝션, XSS, CSRF, 인증 결함 등. 파일 경로 + 라인 번호 + 위험도와 함께 리포트." 2) 의존성 감사관 "package.json, yarn.lock의 모든 의존성을 체크해. 알려진 CVE, 더 이상 유지보수 안 되는 패키지, 라이선스 문제를 식별해." 3) 설정 감사관 "환경변수, 설정 파일, CI/CD 파이프라인을 검토해. 하드코딩된 시크릿, 과도한 권한, 안전하지 않은 기본값. .env.example과 실제 .env 파턴 비교." 3명 모두 읽기 전용으로 작업해. 코드 수정은 하지 마. 발견 사항을 종합해서 심각도별로 정리된 보안 리포트를 만들어.
읽기 전용 강조
보안 감사는 분석만 하는 거예요. 코드를 고치는 게 아니에요.
“코드 수정은 하지 마”를 명시하지 않으면, 팀원이 친절하게 취약점을 직접 수정해버릴 수 있어요.
보안 패치는 검토 후 별도로 진행하는 게 맞습니다.
레시피 9: 성능 최적화 조사 (3명 팀)
프롬프트
앱이 느려졌어. 원인을 에이전트 팀으로 조사해줘. 1) 프론트엔드 성능 분석가 - Sonnet "src/components/ 에서 불필요한 리렌더링, 큰 번들, 최적화 안 된 이미지, 지연 로딩 미적용을 찾아. React DevTools 관점에서 분석해." 2) 백엔드 성능 분석가 - Sonnet "src/api/, src/services/ 에서 느린 쿼리, N+1 문제, 캐싱 미적용, 비효율적 알고리즘을 찾아. 예상 시간 복잡도와 함께 보고해." 3) 인프라 성능 분석가 - Sonnet "Docker, nginx, CI/CD 설정에서 리소스 제한, 캐시 설정, 압축 미적용을 찾아. 배포 파이프라인 병목도 체크해." 각자 조사 후 서로 공유하고, 전체적인 성능 개선 로드맵을 우선순위와 함께 정리해.
레시피 10: PR 기반 릴리즈 노트 생성 (2명 팀)
언제 쓰나?
릴리즈 전에 변경사항을 정리해야 할 때.
프롬프트
v2.3.0 릴리즈 노트를 만들 거야. 마지막 릴리즈(v2.2.0) 이후 머지된 PR들을 분석해줘. 1) 변경사항 분류 팀원 - Sonnet "git log v2.2.0..HEAD 를 분석해서 모든 변경사항을 분류해: - New Features - Bug Fixes - Breaking Changes - Performance Improvements - Dependency Updates 각 항목에 관련 PR 번호 포함." 2) 릴리즈 노트 작성 팀원 - Sonnet "분류 팀원의 결과를 기반으로 사용자 친화적인 릴리즈 노트를 작성해. 기술적 디테일은 줄이고 비즈니스 임팩트 중심으로. 마이그레이션이 필요하면 단계별 가이드 포함."
비용 최적화 전략 총정리
솔직히 이게 제일 중요해요.
에이전트 팀은 강력하지만, 토큰이 진짜 많이 나갑니다.
Anthropic 공식 문서에서도 “토큰 사용량이 단일 세션보다 상당히 증가한다”고 명시했어요.
전략 1: 모델 혼합 (Mixed Model)
모든 팀원이 Opus일 필요는 없어요.
아키텍처 설계, API 설계 → Opus (판단력 필요) 프론트엔드, 테스트, 문서화 → Sonnet (패턴 기반 작업) 단순 리서치, 분류 → Haiku (읽기 + 정리)
이것만 해도 전원 Opus 대비 40-60% 절약.
전략 2: 팀 크기 최소화
❌ "10명 팀으로 구성해줘" → 조율 오버헤드 폭발 ✅ "3명으로 구성하되, 각자 명확한 역할" → 효율 극대화
Anthropic 권장: 3-5명이 최적. 팀원당 5-6개 태스크.
전략 3: 에이전트 팀이 필요 없는 작업 구분
이게 핵심이에요.
에이전트 팀 쓸 때: ✅ 3개 이상 독립 모듈 동시 작업 ✅ 서로 다른 관점으로 동시 분석 ✅ 대규모 리팩토링 (30+ 파일) ✅ 경쟁 가설이 필요한 디버깅 쓰지 말아야 할 때: ❌ 버그 한 개 수정 ❌ 파일 1-2개 변경 ❌ 순차적으로 해야 하는 작업 ❌ 같은 파일을 건드려야 하는 작업
전략 4: Delegate 모드 활용
리드가 직접 코딩을 시작하면 토큰이 이중으로 소모돼요.
리드는 조율만 하고 팀원이 작업하게 하려면 Shift+Tab으로 Delegate 모드를 켜세요.
전략 5: 브로드캐스트 최소화
broadcast는 모든 팀원에게 동시에 메시지를 보내는 거예요.
5명 팀에 브로드캐스트 1번 = 메시지 5번 비용.
꼭 필요할 때만 쓰고, 가능하면 1:1 message를 쓰세요.
에이전트 팀 사용 전 체크리스트
프롬프트 쓰기 전에 이거부터 체크하세요.
[ ] 팀원들이 독립적으로 작업할 수 있는가? [ ] 파일 영역이 명확히 구분되는가? [ ] 3명 이상 필요한 규모인가? (2명이면 서브에이전트가 나음) [ ] 각 팀원에게 줄 컨텍스트를 정리했는가? [ ] 의존성 순서를 파악했는가? [ ] 모델 혼합을 고려했는가? (전원 Opus → 낭비) [ ] Plan Approval이 필요한 작업인가?
하나라도 “아니오”면, 프롬프트를 다시 정리하세요.
정리 – 프롬프트가 곧 팀 매니지먼트다
에이전트 팀에서 프롬프트 = 업무 지시서예요.
실제 회사에서 팀장이 “알아서 해”라고 하면 어떻게 되죠?
혼돈이죠.
“누가, 어디서, 뭘, 어디까지” 명확하게 지시해야 팀이 돌아가잖아요.
AI 팀도 똑같아요.
나쁜 프롬프트: "에이전트 팀으로 리팩토링해줘"
좋은 프롬프트: "3명 팀 구성.
팀원 A는 src/api/만 담당, Opus.
팀원 B는 src/components/만 담당, Sonnet.
팀원 C는 tests/만 담당, Sonnet.
계획 승인 후 실행.
서로의 디렉토리 건드리지 마."
프롬프트를 잘 쓰는 것에서, AI 팀을 잘 이끄는 것으로.
시대가 바뀌고 있어요.
먼저 익숙해진 사람이 앞서갑니다.