Sub-agent 조합 3종 — 순차 검증 · 병렬 수집 · 분기 라우팅

Sub-agent 방식은 Claude Cowork에서도 Claude Code에서도 바로 동작합니다. 하지만 "Agent 도구로 하위 에이전트 불러"라는 한 줄만 알아서는 실제 업무에 써먹기 어렵습니다. 어떤 구조로 조합할지가 성패를 가릅니다.

이 글은 실무에서 반복되는 3가지 핵심 패턴을 프롬프트 레시피와 안티패턴까지 정리해 바로 쓸 수 있도록 돕습니다.

왜 3가지인가

세상의 모든 자동화는 결국 세 가지 질문의 조합입니다.

맞게 했나? — 결과물의 품질을 누가 검증할 것인가 → 순차 검증 패턴
빨리 모았나? — 여러 곳에서 동시에 정보를 가져올 수 있나 → 병렬 수집 패턴
어디로 보내나? — 들어온 요청을 어떤 전문가가 처리해야 하나 → 분기 라우팅 패턴

나머지 복잡한 패턴(5패턴 랩의 재시도 루프 · 오케스트레이터)은 이 3가지의 조합과 확장입니다.

패턴 1 — 순차 검증 (Producer → Verifier)

구조

flowchart LR
  U[사용자] --> M[메인 세션]
  M -->|Agent: produce| P["작성자
subagent"]
  P -->|초안| M
  M -->|Agent: verify| V["검증자
subagent"]
  V -->|OK 또는 수정 요청| M
  M -->|통과| O[최종 산출물]
  M -.NG.-> P

언제 쓰나

작성 ≠ 검증이어야 할 때 — 같은 에이전트가 만들고 같은 에이전트가 검증하면 눈감아줄 확률이 높습니다
법적·규정 리스크가 있는 산출물 — 세무 메일, 계약서 초안, 공시 문구
형식 검사가 복잡한 산출물 — 특정 템플릿, 금칙어, 길이 제한

프롬프트 레시피

다음 2단계 파이프라인으로 진행해줘:

[Step 1] Agent(producer) — 이번 분기 IR 요약 초안 작성
- 입력: .moai/fixtures/q1-financials.csv
- 출력: 제목 + 핵심 수치 3개 + 전망 2줄

[Step 2] Agent(verifier) — Step 1의 초안을 검증
- 금칙어 체크 ("기회", "확실", "보장" 등 5개)
- 숫자 정확성: 원본 CSV와 교차 검증
- 길이 제한: 제목 30자 · 본문 200자 이내
- 통과 여부 판정 후, 실패 시 구체적 수정 사항 반환

[Step 3] 실패 시 Step 1에 수정 사항을 전달해 재작성. 최대 3회 재시도.
통과 시 최종 산출물을 저장.

장점

한 에이전트의 편향을 상쇄 — 작성자는 창의성, 검증자는 엄격함에 집중 가능
명시적 품질 기준 — 검증자 프롬프트에 체크리스트를 박아두면 매번 일관된 판정
재시도 가능 — 실패해도 구체 피드백이 있으니 작성자가 개선할 수 있음

안티패턴

실수	결과	개선
검증자에게 "이상한 거 있나?"	두루뭉술한 판정, 기준 불명	명시적 체크리스트를 프롬프트에 박기
작성자와 검증자를 같은 세션에서 돌림	인지 편향으로 자기검증 실패	반드시 `Agent()`로 격리
재시도 횟수 무제한	무한 루프 위험	3회 상한 + 실패 시 원인 로그
검증자에게 원본 데이터 미제공	숫자 검증 불가	원본 파일 경로를 검증자에게 함께 전달

실전 예시

세무법인 세무 메일 검증: 작성자(사례 템플릿) → 검증자(금칙어 + 납부기한 정확성)
공시문구 초안: 작성자(IR 담당 톤) → 검증자(법무 체크리스트)
이력서 리뷰: 작성자(피드백 생성) → 검증자(존중 표현 · 근거 포함)

패턴 2 — 병렬 수집 (Fan-out → Fan-in)

구조

flowchart LR
  U[사용자] --> M["메인 세션
aggregator"]
  M -->|Agent: source A| S1[수집기 A]
  M -->|Agent: source B| S2[수집기 B]
  M -->|Agent: source C| S3[수집기 C]
  S1 -->|raw A| M
  S2 -->|raw B| M
  S3 -->|raw C| M
  M --> O[통합 결과]

언제 쓰나

여러 출처의 데이터가 필요할 때 — 뉴스 사이트 3곳 · 내부 API 2개 · 외부 API 1개
독립적인 작업을 동시에 진행할 때 — 한 작업이 다른 작업의 결과를 기다리지 않아도 될 때
속도가 중요할 때 — 순차 실행 시 총 시간이 아닌, 가장 느린 하나의 시간만 지연

프롬프트 레시피

Agent 도구로 다음 3개를 병렬 실행해줘:

[병렬 1] Agent(news-scraper)
- 입력: 키워드 "전기차 보조금"
- 기간: 최근 7일
- 출력: {사이트, 제목, URL, 게시일, 요약 2줄} × 최대 5건

[병렬 2] Agent(market-data)
- 입력: 종목 코드 리스트 (다음 슬라이드 테이블 참조)
- 출력: {종목, 주가, 전일대비, 거래량}

[병렬 3] Agent(regulation-check)
- 입력: .moai/fixtures/regulation-keywords.yaml
- 출력: 최근 공표된 관련 규정 변경 사항

모두 완료되면 aggregator 로직으로:
- 뉴스 5건 중 규정 변경에 관련된 것에 🔔 마커
- 종목 변동이 뉴스와 겹치는 경우 교차 표시
- 1페이지 요약 카드로 조립

장점

시간 단축 — 순차 30초 × 3 = 90초 → 병렬은 가장 느린 30초에 끝
출처 독립성 — 하나가 실패해도 나머지는 진행 가능
aggregator의 부가가치 — 단순 모음이 아니라 교차 참조 · 우선순위 매기기 가능

안티패턴

실수	결과	개선
수집기들이 서로 의존	순차 실행으로 퇴행	진짜 독립된 작업만 병렬로 묶기
aggregator가 단순 concat	"그래서 뭐?" 소리 나는 결과	교차 참조 · 순위 · 마커 로직을 넣기
모든 수집기가 실패해도 그냥 진행	빈 카드 출력	최소 성공 수 조건 ("3개 중 2개 이상")
수집기마다 출력 스키마 다름	aggregator 혼란	각 subagent에 동일 JSON 스키마 강제

실전 예시

아침 시장 브리핑: 뉴스 · 주가 · 환율 · 규정 4개 병렬 → 교차 분석
경쟁사 스냅샷: 홈페이지 · 채용공고 · 최근 뉴스 · 리뷰사이트 병렬 → 월간 리포트
납품 현황 대시보드: ERP · 배송 API · 이메일 함 · 슬랙 채널 병렬 → 지연 감지

패턴 3 — 분기 라우팅 (Classifier → Specialist)

구조

flowchart TB
  U[사용자 요청] --> C{"분류기
subagent"}
  C -->|세무 카테고리| S1["세무 전문가
subagent"]
  C -->|HR 카테고리| S2["HR 전문가
subagent"]
  C -->|IT 카테고리| S3["IT 전문가
subagent"]
  C -->|기타| S4["일반 응답
subagent"]
  S1 --> O[답변]
  S2 --> O
  S3 --> O
  S4 --> O

언제 쓰나

요청 유형이 다양할 때 — 한 프롬프트로 모든 걸 다루면 길고 산만해짐
전문 지식이 필요할 때 — 카테고리마다 다른 스킬이나 컨텍스트가 붙어야 할 때
응답 품질 vs 비용 트레이드오프 — 쉬운 건 Haiku, 어려운 건 Sonnet/Opus로 자동 분배

프롬프트 레시피

다음 2단계로 진행해줘:

[Step 1] Agent(classifier) — 사용자 문의를 분류
- 입력: 사용자 원문 질문
- 출력: 카테고리 (tax/hr/it/general) + 신뢰도 (0~1) + 이유 한 줄
- 신뢰도 < 0.6 이면 general 로 fallback

[Step 2] 카테고리별 전문가 에이전트 호출:
- tax → Agent(tax-specialist) with skill 'tax-email-writer'
- hr → Agent(hr-specialist) with skill 'hr-policy-lookup'
- it → Agent(it-specialist) with skill 'it-troubleshoot-guide'
- general → Agent(general-assistant)

[Step 3] 전문가의 응답을 받아 사용자에게 전달.
응답 하단에 "이 답변은 {카테고리} 전문 에이전트가 처리했습니다" 메타 표시.

장점

컨텍스트 집중 — 전문가 에이전트는 자기 영역 지식만 로드 → 정확도 ↑, 토큰 ↓
비용 최적화 — 카테고리별 모델 티어 조정 가능
책임 추적 — 어느 전문가가 처리했는지 메타 정보가 남음

안티패턴

실수	결과	개선
분류기가 오분류해도 그대로 진행	엉뚱한 전문가에게 전달	신뢰도 임계값 + general fallback
분류기에게 너무 많은 카테고리	판단 불안정	5개 이내로 제한, 많으면 계층 분류
전문가 에이전트가 분류기 역할까지	책임 경계 흐림	분류기는 분류만, 전문가는 답변만
카테고리 정의가 중복	같은 요청이 매번 다른 전문가로	카테고리 경계를 프롬프트에 명시

실전 예시

고객 문의 자동 분배: 분류기 → 결제 · 배송 · 기술 · 반품 전문가
법무 문서 초기 트리아지: 분류기 → 계약서 · 사규 · 송무 · 컴플라이언스
사내 IT 헬프데스크: 분류기 → 계정 · 네트워크 · 소프트웨어 · 하드웨어

3패턴 조합하기

실제 업무는 하나의 패턴으로 끝나지 않습니다. 조합하면 강력합니다.

조합 예시: 고객 리서치 리포트 자동 생성

flowchart TB
  R[요청] --> C{"분류기"}
  C -->|제품 | M[메인 세션]
  M -->|Agent| A1[경쟁사 수집기]
  M -->|Agent| A2[리뷰 수집기]
  M -->|Agent| A3[특허 수집기]
  A1 --> V[초안 작성자]
  A2 --> V
  A3 --> V
  V -->|초안| CH[검증자]
  CH -->|OK| FIN[최종 리포트]
  CH -.NG.-> V

분기 라우팅으로 요청 유형 판별 (제품/시장/기술)
병렬 수집으로 여러 출처에서 원천 데이터 획득
순차 검증으로 초안 → 체크리스트 검증 → 통과 시 확정

이것이 바로 "오케스트레이션"의 실전 모습입니다. Sub-agent 3패턴만 잘 조합해도 대부분의 반복 업무가 풀립니다.

어느 패턴부터 익혀야 할까

수준	시작 패턴	목표
초급	순차 검증	두 에이전트의 역할 분리를 체감
중급	병렬 수집	시간 단축 + aggregator 설계 감각
고급	분기 라우팅	신뢰도 관리 + fallback 설계
실전	3패턴 조합	한 업무를 끝단까지 자동화

교육 1일 차라면 순차 검증부터. "같은 에이전트가 검증하면 안 된다"는 체감이 가장 큰 아하-모먼트입니다.

자주 묻는 질문

Q. 병렬 수집과 병렬 실행을 Claude가 정말 동시에 하나요?

A. 네. Agent() 도구를 한 메시지에 여러 번 호출하면 Claude는 가능한 한 병렬로 실행합니다. 다만 실제 병렬도는 모델의 판단과 도구 스케줄러에 달려 있어, "절대 N배 빨라진다"고 보장할 수는 없습니다. 통상 2~3배 체감 향상입니다.

Q. 검증자가 계속 거절하면 어떻게 하죠?

A. 3회 상한을 두고, 실패 시 사용자에게 "자동 처리 실패 — 사람이 검토 필요" 알림을 보내는 게 안전합니다. 검증 기준이 너무 엄격한지 · 작성자 프롬프트가 잘못됐는지 로그로 확인해야 합니다.

Q. 분류기가 오분류하는 걸 어떻게 잡나요?

A. 3가지 방법:

신뢰도 점수 — 분류기가 자기 확신도 반환, 임계값 미만이면 general fallback
샘플 라벨링 — 월 1회 과거 분류 결과를 샘플링해 정확도 측정
사용자 피드백 루프 — 답변 말미에 "이 분류가 맞나요?" 버튼 → 누적 데이터로 분류기 프롬프트 개선

Q. 이 패턴들은 Agent Teams에서도 동일하게 동작하나요?

A. 개념은 동일합니다. 다만 Teams에서는 Agent() spawn 대신 TeamCreate로 상주 teammate를 띄우고 SendMessage로 전달합니다. 단발 실행이면 Sub-agent, 상주 실행이면 Teams가 자연스럽습니다.

다음 읽을거리

변경 이력

v1 (2026-04-12): 최초 작성 — Claude@IGM Cohort 1 교재용, Sub-agent 패턴 체계화