혼자가 아니라, 팀으로.
에이전트 하나가 버거워지는 순간 — 팀을 꾸리는 법을 배웁니다.
에이전트의 조직도
한 명의 한계
큰일을 독립된 조각으로 나눕니다. 조각마다 담당자 한 명.
담당자에게는 회사의 모든 역사가 아니라 임무 요약서만 전달합니다.
위로 올라가는 건 결과 요약뿐. 팀장은 실무자의 삽질 로그를 다 읽지 않습니다.
회사가 괜히 팀·파트·그룹으로 나뉜 게 아닙니다. 한 사람의 머리가 유한해서입니다.
왜 팀인가 — 방금 봤습니다 ✓
격리 · 위임장 쓰는 법 · 그리고 위임의 대가
역할 분담 · 병렬 fan-out · 파이프라인 · 심판 패널
작업 목록 · 파일 공유 · worktree · 검증 게이트
headless · CI · 스케줄 — 자는 동안 일하는 팀
언제 팀이고, 언제 그냥 혼자가 나은가
그래서 부모의 상자는 계획과 결론만으로 가볍게 유지됩니다.
자식이 읽은 1만 줄은 자식의 상자에서 소멸하고, 부모에게는 결론 30줄만 착륙합니다.
지역 변수 = 자식의 탐색·삽질 반환값 = 요약 보고 호출자 = 부모
컨텍스트 세미나의 "서브에이전트 = 컨텍스트 격리" 한 장, 기억하시나요 — 오늘 세미나 전체가 그 확장판입니다.
# ❌ 이렇게 위임하면 "auth 쪽 한번 봐줘" # 자식은 부모의 대화를 모릅니다 — # 무엇을? 왜? 어디까지? # 게다가 중간에 되물을 수도 없습니다
# ✅ 업무 지시서 "src/auth의 토큰 갱신 로직을 조사해줘. 목표: 간헐적 로그아웃의 원인 후보 찾기 완료 기준: 파일:줄 위치와 근거 코드 2~3곳 반환 형식: 표 — 위치 | 추정 원인 | 확신도"
"서브에이전트로 나눠서 조사해줘" "독립적인 부분은 병렬로 진행해줘" "리뷰는 별도 에이전트에게 맡겨줘"
이 한마디면 에이전트가 알아서 팀을 꾸립니다.
.claude/agents/reviewer.md --- name: reviewer description: 코드 리뷰 전문. PR·diff 검토 시 사용 tools: Read, Grep --- 너는 깐깐한 시니어 리뷰어다. …
이름·전문 분야·도구 권한을 정의해두면, 필요할 때마다 같은 전문가가 소환됩니다. tools 제한 = 읽기 전용 리뷰어처럼 권한 최소화.
탐색 → 계획 → 구현 → 리뷰. 단계마다 다른 에이전트, 각자 깨끗한 눈.
읽을 건 많고 단계가 뚜렷할 때
독립 작업 여러 개를 동시에. 벽시계 시간을 접습니다.
파일 10개 마이그레이션 · 다각도 조사
항목별로 단계를 흘려보내기 — 앞 단계 전체를 기다리지 않고.
항목 많고 단계가 고정일 때
같은 문제를 N번 독립 시도 → 채점·종합. 서로 반박도 시킵니다.
답 공간이 넓고 품질이 승부일 때
이제 한 장씩 — 각 패턴이 언제, 왜 이기는지 보겠습니다.
탐색이 읽은 파일 수십 개는 탐색 상자에서 폐기 — 계획은 정제된 보고서 위에서만 세웁니다.
리뷰어는 구현자의 변명을 모릅니다. 본인 코드는 본인 눈에 늘 옳아 보이거든요 — 사람도, 에이전트도.
❌ 혼자 순차 — 파일 5개 × 10분🕐 50분
✅ fan-out — 동시에 5명🕐 10분 + 취합
예: 파일 10개 마이그레이션 · 라이브러리 후보 3개 비교 조사 · 모듈별 문서화. 벽시계는 줄지만 토큰 총량은 그대로라는 것도 기억하세요.
과제: 문서 여러 건을 추출 → 번역 → 검수로 처리하기 (단계마다 담당 에이전트 1명)
❌ 배리어 — 단계 전체가 끝나야 다음9틱
✅ 파이프라인 — 끝난 것부터 바로 다음5틱 ✂
🙈 시도들은 서로의 답을 못 봅니다 — 독립성이 다양성을 만듭니다.
🥊 적대적 검증: 🅰에게 🅱를 반박시켜 보세요 — 스스로 매기는 점수보다 훨씬 냉정합니다.
언제? 답 공간이 넓고(설계·문안·전략) 품질이 승부일 때. 비용이 ×N이 된다는 건 각오하시고요.
[x] 1. API 명세 조사 — 완료 (보고서: notes/api.md) [>] 2. 파서 구현 — 에이전트 B 진행 중 [ ] 3. 테스트 작성 — 2번 완료 후 [ ] 4. 문서 갱신
누가 어디까지 했는지가 압축·재시작에도 살아남습니다.
PLAN.md에 설계와 결정을, NOTES.md에 중간 발견을 — 자식들이 같은 파일을 읽으며 합을 맞춥니다.
자식 A의 발견을 자식 B에게 전하는 가장 싼 방법은, 부모의 입이 아니라 파일입니다.
$ git worktree add ../feat-login feature/login
$ git worktree add ../feat-search feature/search
# 같은 저장소, 서로 다른 작업 폴더
에이전트마다 자기 사본 — 같은 파일을 동시에 고쳐도 충돌이 없습니다. 끝나면 브랜치 병합으로 합칩니다.
파이프라인 사이사이에 검사 단계를 심습니다 — 테스트 러너 · 린터 · 리뷰 에이전트. 통과 기준은 작업 목록에 명시.
믿지 말고 검사하세요 — 팀원이 로봇일 때는 더욱.
$ claude -p "어젯밤 실패한 테스트를 분석해서 원인 요약을 report.md로 저장해줘" # 대화창 없이 한 번 실행하고 종료 — 결과는 파일과 표준 출력으로
반복문·크론 작업에 끼워 넣으면 에이전트가 파이프라인의 한 단계가 됩니다. 매일 밤 로그 분석, 매주 문서 갱신.
오케스트레이터 스크립트가 headless 에이전트 여럿을 지휘 — 사람은 시작과 결과 확인만.
PR이 열리면 리뷰 에이전트가 코멘트를 달아둡니다. 사람 리뷰어는 굵은 판단만.
새 이슈에 라벨·우선순위·담당 제안을 자동으로 — 아침 분류 회의가 짧아집니다.
스케줄 트리거로 매일 밤 — 의존성 점검 · 문서 갱신 · 릴리스 노트 초안.
GitHub Actions 같은 CI에 에이전트를 심으면, 트리거(PR·이슈·스케줄)가 상사 역할을 대신합니다.
헷갈리면 혼자가 기본값입니다 — 팀은 병목이 눈에 보일 때만 부르세요.
| 패턴 | 이럴 때 | 한 줄 요령 |
|---|---|---|
| 🎭 역할 분담 | 읽을 건 많고 결론은 짧을 때 · 단계가 뚜렷할 때 | 단계 사이 인수인계는 보고서 파일로 |
| 🍴 병렬 fan-out | 독립 작업 여러 개 — 파일 10개 변환, 다각도 조사 | 같은 파일 금지 — 겹치면 worktree로 격리 |
| 🏭 파이프라인 | 항목 많고 단계 고정 — 문서 50건 처리 | 끝난 항목부터 흘려보내기 — 배리어 제거 |
| ⚖️ 심판 패널 | 답 공간 넓고 품질 승부 — 설계·문안·전략 | 독립 시도 → 교차 반박 → 채점 · 비용 ×N |
| 🧑💻 그 외 대부분 | 작고 순차적이고 맥락이 얽힌 일 | 그냥 혼자 + 검증 게이트 — 그게 최적입니다 |
위임장에는 항상 — 🎯 목표 · ✅ 완료 기준 · 📦 반환 형식
이 조직도를 기억하세요 —
질문은 지금, 또는 Q&A 위젯으로 받겠습니다.