Agent Teams: 여러 Claude가 팀으로 일한다
5파일+ 사이클이 팀 환경에서 어떻게 작동하는가
📑 이 챕터에서 다룰 내용
새 22장 (성장 경로 정정렬)까지 끝났습니다. 이 장은 "여러 Claude 인스턴스가 팀으로 일하는" Agent Teams를 다룹니다. 1탄 v2의 핵심 보강 챕터 중 하나로, 5파일+ 사이클이 팀 환경에서 어떻게 작동하는지 살펴봅니다.
| 📚 사전 지식 체크 | 🎯 이 장의 목적 | ✅ 완료 후 결과물 |
|---|---|---|
| Phase 1~3 완성 / Claude Code v2.1.32+ / Pro 이상 플랜 | Agent Teams + /delegate + 3조건 + 5파일+ 사이클이 팀 환경에서 어떻게 작동하는가 | 첫 /delegate 실행 + 두 에이전트 병렬 작업 + 결과 통합 |
철학자 피에르 레비: "개별 구성원보다 올바르게 구성된 집단이 더 나은 판단을 한다."
단, 올바른 역할 분담과 소통 구조가 전제 조건입니다. 모두가 같은 일을 하면 오히려 효율이 떨어집니다.
Claude Code의 Agent Teams가 이 원리를 구현합니다. 팀 리드가 작업을 분해하고, 팀원이 병렬 처리합니다. 혼자 순서대로 진행하는 것보다 2~4배 빠릅니다.
대형 건물을 지을 때 한 사람이 모든 것을 하지 않습니다. 철근·콘크리트·전기·배관 팀이 동시에 각자 작업하고, 팀장이 진행을 조율합니다.
Agent Teams도 마찬가지입니다. "프론트엔드 팀" + "백엔드 팀" 동시 작업 = 시간 절반.
독립적인 작업 2개 이상이면 Agent Teams로 병렬 처리합니다. 의존성이 없어야 합니다.
| 도구 | 팀 협업 방식 |
|---|---|
| BMAD-METHOD | 7~8 페르소나가 자기 영역 자체로 — Mary·Preston·Winston·Sally·Devon·Quinn |
| GSD wave | 의존성 자동 분석 후 병렬 wave 그룹화 |
| Spec-Kit | agent-agnostic — 어느 모델·도구든 결합 가능 |
| Cursor / Claude Code | /delegate 명령으로 직접 위임 (이 장의 자리) |
| fabriqa | 다중 모델 (Claude + Codex + Gemini) 동시 협업 |
5파일+의 Agent Teams = Claude Code 직접 위임. 학습용 단순화. BMAD의 깊은 페르소나 협업은 Phase 1.2+ 또는 권7에서 다룹니다.
핵심 답을 먼저 드립니다. 5파일+ 사이클은 Agent Teams 환경에서도 그대로 작동합니다. 변하는 것은 "BUILD 단계의 작업 분배" 뿐입니다.
5파일은 단일 출처로 유지
| 파일 | 팀 환경에서의 자리 |
|---|---|
| SPEC.md | 단일 — 모든 에이전트가 같은 SPEC 참조 |
| PLAN.md | 단일 — 작업 분배의 출처 |
| REVIEW.md | 단일 — READY 판정 후 에이전트 위임 |
| BUILD.md | 단일 — 모든 에이전트가 매일 BUILD.md 갱신 |
| CLAUDE.md | 단일 — 모든 에이전트가 같은 규칙 따름 |
5파일은 "모든 팀의 단일 출처" 역할을 합니다. 이게 5파일+의 가장 큰 가치입니다 — 팀 환경에서 5파일이 "공유 컨텍스트"가 됩니다.
변하는 것 — BUILD 단계의 작업 분배
[기존 5파일+ BUILD]
SPEC v4 → PLAN v2.1 → REVIEW READY → BUILD Day 1 (혼자) → Day 2 (혼자) → ...
↓
[Agent Teams BUILD]
SPEC v4 → PLAN v2.1 → REVIEW READY → BUILD Day 1
├─ 에이전트 A: src/components/
├─ 에이전트 B: src/api/
└─ 에이전트 C: tests/
↓ 통합
BUILD.md Day 1 갱신 (3 트레이스)PLAN.md의 Day별 작업이 폴더 단위로 분배됩니다. 5파일은 그대로 유지됩니다.
CLAUDE.md §6 File Structure가 핵심
새 11장의 CLAUDE.md §6 (File Structure)가 에이전트 분배의 기준이 됩니다. 폴더 구조가 명확하면 "에이전트 A는 폴더 X, 에이전트 B는 폴더 Y"가 자연스럽게 도출됩니다.
## 6. File Structure src/ app/ 라우팅 components/ UI 컴포넌트 ← 에이전트 A 담당 lib/ 유틸 + SSOT 인터페이스 api/ 외부 호출 ← 에이전트 B 담당 tests/ unit/ 단위 테스트 e2e/ E2E 테스트 ← 에이전트 C 담당
CLAUDE.md가 단단하면 Agent Teams가 자연스럽게 작동합니다.
/delegate 아래 두 작업을 동시에 진행해줘:
에이전트 A (담당 폴더: src/components/):
- 줍줍 카드 컴포넌트 리팩토링 (200줄 이하)
- 신뢰지수 표시 UI 개선
에이전트 B (담당 폴더: src/api/):
- 공공데이터 API 호출 최적화 (병렬 fetch)
- LLM 분류 confidence 0.7 임계값 fallback 추가
두 에이전트가 완료하면 결과를 통합해서 보고해줘.
충돌이 생기면 즉시 멈추고 알려줘.폴더 분리 원칙 — 에이전트 충돌 방지
| 분리 종류 | 예시 |
|---|---|
| 1차 분리 — 폴더 | A: src/components/ / B: src/api/ |
| 2차 분리 — 파일 | A: components/Button.tsx / B: components/Card.tsx |
| 3차 분리 — 함수 | (권장 X — 같은 파일 동시 수정 위험) |
1차 (폴더)가 가장 안전한 분리 방식입니다. 2차 (파일)도 가능하지만 충돌 가능성이 있습니다. 3차 (함수)는 사용하지 마세요.
새 11장 CLAUDE.md §6 File Structure가 폴더 단위로 책임을 분리하고 있으면, /delegate 명령 작성이 자연스럽습니다.
이 3가지 조건을 모두 만족할 때만 서브에이전트를 사용합니다. 하나라도 빠지면 순차 실행이 더 안전합니다.
| # | 조건 | 판단 질문 |
|---|---|---|
| ① | 독립성 | 작업 A 시작에 작업 B 결과가 필요한가? → NO여야 사용 가능 |
| ② | 파일 분리 | 두 작업이 서로 다른 파일·폴더를 수정하는가? → YES여야 가능 |
| ③ | 충분한 크기 | 각 작업이 30분+ 걸리는 실질적인 작업인가? → YES여야 효율 |
- UI 컴포넌트 (src/components/) + API 로직 (src/api/) 동시 개발
- 단위 테스트 (tests/) + 실제 기능 (src/) 동시 작성
- 어드민 기능 (src/admin/) + 사용자 기능 (src/user/) 독립 개발
- 문서화 (docs/) + 리팩토링 (src/) 동시 진행
- A가 만든 함수를 B가 즉시 호출해야 할 때
- 같은 파일 (예: CLAUDE.md)을 두 에이전트가 수정해야 할 때
- 에러 디버깅 중 (원인 파악이 먼저)
- Phase 1처럼 처음 구현할 때 (전체 흐름을 먼저 이해)
Day 5 — 두 탭 동시 개발
줍줍의 핵심 구조는 소상공인 탭 + 개인 복지 탭입니다. CLAUDE.md §6에 폴더 분리가 명시되어 있습니다.
src/app/(tabs)/business/ 소상공인 탭 src/app/(tabs)/individual/ 개인 복지 탭
/delegate Phase 1 두 탭 UI를 동시에 개발해줘:
에이전트 A (담당 폴더: src/app/(tabs)/business/):
- 소상공인 탭 메인 페이지 (목록·카테고리 필터)
- 사업단계 필터 (창업준비·1년미만·3년미만·3년이상·폐업재기)
- "사장님 톤" 닉네임 페르소나 풀 적용 (E5)
에이전트 B (담당 폴더: src/app/(tabs)/individual/):
- 개인 복지 탭 메인 페이지 (목록·생애주기 필터)
- 가구 형태 필터 (1인가구·부부·한부모·다자녀·노인·장애인)
- "시민 톤" 닉네임 페르소나 풀 적용 (E5)
CLAUDE.md §5 Two-Tab Content SSOT 7 규칙 준수 필수:
- 사실 단일 출처 (benefits 테이블)
- 톤 분리 (사장님 / 시민)
- 닉네임 페르소나 풀 분리
두 에이전트 완료 후 자동 일관성 테스트:
"같은 benefit_id에 대해 두 탭 노출 시 사실 일치"결과 — 시간 절감
| 작업 | 순차 | Agent Teams (병렬) |
|---|---|---|
| 소상공인 탭 UI | 4h | 4h (병렬) |
| 개인 복지 탭 UI | 4h | (동시 진행) |
| 자동 일관성 테스트 | 1h | 1h (통합 후) |
| 합계 | 9h | 5h (-44%) |
E2 1인 페이스에 직접 기여합니다 — 4h 절감 = R4 트리거 한 단계 늦춤.
Day 8 — 두 페르소나 동시 개발
TSV의 핵심 구조는 STAT + OBSERVER 페르소나입니다. CLAUDE.md §6에 아래와 같이 명시되어 있습니다.
src/personas/stat/ STAT 페르소나 (통계학자) src/personas/observer/ OBSERVER 페르소나 (균형 관찰자) src/personas/_shared/ 공통 (system prompt 베이스, cache_control) lib/match_facts.ts SSOT 인터페이스 (단일 출처)
/delegate Phase 1.0 두 페르소나를 동시에 개발해줘:
에이전트 A (담당 폴더: src/personas/stat/):
- STAT system prompt 작성 (통계학자 톤)
- 정량·기술적 표현 강조 (xG·점유율·슈팅 수치)
- cache_control 적용 (lib/_shared/cache.ts 참조)
- SEO 키워드: "통계 분석", "xG 분석"
에이전트 B (담당 폴더: src/personas/observer/):
- OBSERVER system prompt 작성 (신중한 관찰자 톤)
- 균형 어법 강조 ("한편으로는 ..., 다만 ...")
- cache_control 적용
- SEO 키워드: "경기 미리보기", "다관점 분석"
공통 파일 (lib/match_facts.ts, lib/_shared/)은 두 에이전트 모두
읽기 전용. 수정 금지.
CLAUDE.md §5 Persona System Rules 8개 규칙 준수 필수:
[1] 활성 페르소나 2종만
[2] SSOT 의무 (MatchFacts 인터페이스)
[3] 사실 자체 변경 금지
[4] 자동 일관성 테스트 통과 의무
[5] prompt caching 적용 의무
[6] SEO 키워드 분리 (cannibalization 방지)
[7] 익명성 유지
[8] Position C 일관 노출
두 에이전트 완료 후 일관성 테스트:
tests/persona_consistency.test.ts 5개 케이스 모두 통과해야 함.
fail 시 cron/publish.ts 자동 정지.결과 — 페르소나 시스템의 자연 분배
| 작업 | 순차 | Agent Teams |
|---|---|---|
| STAT 페르소나 | 6h | 6h (병렬) |
| OBSERVER 페르소나 | 6h | (동시) |
| 자동 일관성 테스트 | 2h | 2h (통합) |
| 합계 | 14h | 8h (-43%) |
5확장 × Agent Teams — E5 콘텐츠 SSOT의 자연스러움
E5 콘텐츠 SSOT 시스템 (다중 페르소나)은 Agent Teams와 자연스럽게 결합됩니다. 이유는 세 가지입니다.
CLAUDE.md §6에서 페르소나별 폴더가 이미 분리되어 있으므로 에이전트 배분이 자연스럽게 도출됩니다.
충돌 위험이 최소화됩니다. 두 에이전트 모두 같은 SSOT에서 읽기만 합니다.
통합 후 테스트가 두 에이전트 결과를 검증합니다.
E5 콘텐츠 SSOT 적용 프로젝트 (콘텐츠 시스템)는 Agent Teams 적합도가 가장 높습니다.
통합 단계
[두 에이전트 완료 후, Claude Code] 두 에이전트 작업 완료. 통합 단계 시작: 1. 자동 일관성 테스트 실행 (tests/persona_consistency.test.ts) - 모두 통과 → 다음 단계 - fail → 어느 에이전트의 어느 결정이 원인인지 분석 2. CLAUDE.md §5 8개 규칙 검증 - 모두 준수 → PASS - 위반 → 해당 에이전트 결과 롤백 3. BUILD.md Day 8 갱신: - 두 에이전트 LogOnTable 트레이스 (각 1~3줄) - 통합 결과 1줄 4. git commit - 메시지: "Day 8: STAT + OBSERVER 페르소나 (Agent Teams)"
실패 대응
# Claude가 "에이전트 A에서 충돌 발생" 보고 시 에이전트 A 작업만 취소해줘. 에이전트 B는 완료 상태로 유지. 에이전트 A는 내가 직접 순차 진행. # 전체 실패 시 git stash /clear /model claude-sonnet-4-6 "두 작업을 순차 실행으로 전환. 새 11장 CLAUDE.md 5파일 모두 읽고 현재 상황 파악 후 진행."
Agent Teams 사용 시 비용이 약 2배입니다 (각 에이전트가 독립 토큰 소비). 30분+ 작업에만 사용하는 것이 경제적입니다.
E2 1인 페이스와의 결합:
- 비용 2배 ↔ 시간 절감 40~50% — Trade-off
- 1인 운영자 시간 가치 > 토큰 비용 (대부분의 경우)
- Phase 초반 학습 단계: 순차 권장
- Phase 중반 BUILD 단계: Agent Teams 권장
매주 일요일 회고 시 "이번 주 Agent Teams 사용량 + 시간 절감" 점검하세요.
📌 새 23장 정리
- 핵심 한 줄: Agent Teams = BUILD 단계 병렬화. 5파일+ 사이클은 그대로, 작업 분배만 폴더 단위 병렬.
- 5파일+ × Agent Teams: 5파일 = 모든 에이전트의 단일 출처 (공유 컨텍스트). 변하는 것 = BUILD 단계의 작업 분배만. CLAUDE.md §6 File Structure가 분배 기준.
- 표준 도구 매핑: BMAD (7~8 페르소나, 가장 깊음) / GSD wave (의존성 자동 분석) / Spec-Kit (agent-agnostic) / Cursor·Claude Code (/delegate 직접 위임)
- 서브에이전트 3조건: ① 독립성 ② 파일 분리 ③ 충분한 크기 (30분+). 모두 만족해야 사용.
- 두 사례: 줍줍 (두 탭 병렬) 9h → 5h (-44%) / TSV (두 페르소나 병렬) 14h → 8h (-43%)
- E5 × Agent Teams: E5 콘텐츠 SSOT 적용 프로젝트는 Agent Teams 적합도 가장 높음.
- 비용 Trade-off: 비용 2배 / 시간 40~50% 절감. 30분+ 작업에만 사용.
- 다음 장: 새 28장 — 멀티모델 오케스트레이션