- 동적 워크플로란
- n8n과의 차이
- 서브에이전트 vs. 동적 워크플로
- 오케스트레이터를 모델에서 코드로 옮겨야 하는 이유
- 6가지 핵심 패턴
- 1. Classify-and-Act (분류 후 실행)
- 2. Fan-Out-and-Synthesize (분산 후 합성)
- 3. Adversarial Verification (적대적 검증)
- 4. Generate-and-Filter (생성 후 필터링)
- 5. Tournament (토너먼트)
- 6. Loop-Until-Done (완료까지 반복)
- 실전 예: 고객 인터뷰 100개 → 프로토타입 3개
- PM이 자주 동적 워크플로로 자동화할 수 있는 반복 작업
- 참고 자료
- 관련 문서
Claude Code 동적 워크플로(dynamic workflows)는 수십~수백 개의 서브에이전트가 코드 오케스트레이터 아래 병렬로 협력하는 실행 모델이다. 개발자만의 도구가 아니다 — 고객 인터뷰 분석, PRD 검증, 백로그 정리처럼 PM이 매주 반복하는 작업을 자동화하기에 딱 맞는 구조다.
동적 워크플로란
동적 워크플로의 핵심은 오케스트레이터가 모델 턴(model turn)이 아니라 코드라는 것이다. 일반 Claude 대화에서는 Claude 자신이 다음 단계를 결정한다. 동적 워크플로에서는 JavaScript/Python 스크립트가 에이전트를 언제, 어떻게 생성할지 결정하고, 결과를 어떻게 라우팅하고 점수 매기고 루프할지를 코드로 제어한다.
n8n과의 차이
n8n 같은 시각적 자동화 도구와 달리 Claude Code 동적 워크플로는:
- 에이전트가 판단해야 하는 단계(예: 인터뷰 내용 이해, PRD 가정 반박)에 LLM을 투입하고
- 라우팅, 점수 계산, 루프 조건 평가는 코드가 처리해 토큰 비용과 불확실성을 없앤다
서브에이전트 vs. 동적 워크플로
| 상황 | 선택 |
|---|---|
| 단일 복잡한 작업 (코드 디버깅, 긴 리서치) | 서브에이전트 |
| 동일 작업을 대량으로 반복 (인터뷰 100개 분석) | 동적 워크플로 |
| 여러 출력물을 합쳐 다음 단계로 연결 | 동적 워크플로 |
오케스트레이터를 모델에서 코드로 옮겨야 하는 이유
모델에게 오케스트레이션을 맡기면 세 가지 문제가 생긴다:
1. 에이전트적 게으름(agentic laziness) 에이전트는 태스크가 충분히 완료됐다고 느끼면 멈춘다. “80개 유저 스토리를 전부 검토해”라고 해도 50개쯤 하고 피로해진다. 코드 루프는 중단 조건이 될 때까지 멈추지 않는다.
2. 자기 편향(self-preferential bias) 에이전트는 자신이 만든 결과물을 더 긍정적으로 평가한다. 같은 에이전트가 PRD를 쓰고 검토하면 실제보다 좋아 보인다. 코드로 별도 에이전트를 생성해 검토를 분리해야 편향이 줄어든다.
3. 목표 이탈(goal drift) 긴 컨텍스트에서 에이전트는 초기 목표에서 미묘하게 벗어난다. 코드 오케스트레이터가 각 단계마다 명시적인 목표를 주입하면 이탈을 방지할 수 있다.
6가지 핵심 패턴
오케스트레이터가 코드가 되면 다음 6가지 패턴이 반복적으로 등장한다. 패턴을 알면 어떤 작업에 어떤 구조가 맞는지 즉시 인식할 수 있다.
1. Classify-and-Act (분류 후 실행)
에이전트 하나가 입력 유형을 분류하면, 스크립트가 해당 유형에 맞는 처리 경로로 라우팅한다.
PM 사용 사례: 인바운드 피드백 분류 (버그 vs 기능 요청 vs 노이즈), 지원 티켓 라우팅
2. Fan-Out-and-Synthesize (분산 후 합성)
입력을 조각내어 에이전트를 병렬 생성하고, 결과를 코드로 합친다.
PM 사용 사례: 경쟁사 분석, 고객 인터뷰 합성, 시장 지도 작성. 에이전트가 처음 20개가 아닌 전체 100개 인터뷰를 읽게 된다.
3. Adversarial Verification (적대적 검증)
별도 에이전트가 루브릭(rubric)에 따라 출력물을 검토한다.
PM 사용 사례: PRD를 원본 소스와 대조해 팩트 체크, 리스크 있는 결정에 두 번째 리뷰어 투입
4. Generate-and-Filter (생성 후 필터링)
여러 후보를 생성하고, 코드가 중복 제거 및 필터링해 살아남은 것만 남긴다.
PM 사용 사례: 제품명 후보 생성, 포지셔닝 문구 작성, 실험 아이디어 생성
5. Tournament (토너먼트)
N개의 에이전트가 각기 다른 방식으로 동일 태스크를 수행하고, 판정 에이전트가 비교해 승자를 선택한다.
PM 사용 사례: 전략 메모 작성, 정답이 하나가 아닌 복잡한 디자인 결정
6. Loop-Until-Done (완료까지 반복)
중단 조건(결과 없음, 오류 없음, 큐 비어있음)이 충족될 때까지 계속 에이전트를 생성한다.
PM 사용 사례: 작업량을 모르는 백로그 정리, 전체 코드베이스 감사
실전 예: 고객 인터뷰 100개 → 프로토타입 3개
100개의 고객 인터뷰(각 1~2페이지)를 입력으로, 6단계 파이프라인이 자동으로 처리한다:
| 단계 | 작업 | 처리 |
|---|---|---|
| 1. Extract | 인터뷰당 에이전트 1개 생성, 기회·페르소나·발화 추출 | 에이전트 (Haiku/Sonnet) |
| 2. Canonicalize | 원시 기회를 정규 집합으로 클러스터링 (동의어 병합) | 에이전트 (판단 필요) |
| 3. Opportunity Score | 빈도 × 중요도 × (5 – 만족도) 계산 | 코드 (토큰 0) |
| 4. Generate & Triage | 상위 기회에 대한 아이디어 생성, 코드로 ROI 기준 정렬 | 에이전트 + 코드 |
| 5. Build | ROI 상위 3개에 대해 클릭 가능한 HTML 프로토타입 생성 | 에이전트 |
| 6. Inspect & Rerun | 렌더링 실패 또는 저신뢰도 추출 재실행 | 루프 |
실행 결과: 113개 에이전트, 1.95M 토큰, 12.5분 → 3개 프로토타입 완성 라우팅·점수 계산·루프 처리는 모델 토큰 0개 소모.
“622개의 원시 기회가 11개의 핵심 필요(canonical needs)로 클러스터링됐다.”
PM이 자주 동적 워크플로로 자동화할 수 있는 반복 작업
- 매주 수집되는 고객 인터뷰 전체 분석 → 테마·JTBD 테이블 생성
- 80개 유저 스토리의 INVEST 기준 자동 검토
- PRD 작성 후 자동 가정 검증 (adversarial agent가 반박)
- 경쟁사 N개 발표 자료를 병렬 분석해 기회 지도 작성
코딩을 배우는 것이 아니다. 매주 반복되는 PM 업무 중 어느 것이 상시 워크플로가 될 수 있는지 인식하는 것이다. 목표를 한 번 설정하고 스킬로 저장해두면, 이후는 자동으로 처음부터 끝까지 실행된다.
참고 자료
- Claude Dynamic Workflows for PMs: The Ultimate Guide — The Product Compass (2026-06-07)
관련 문서
- claude-code-dynamic-workflows — Claude Code Dynamic Workflows 기술 소개
- claude-code-tips-dynamic-workflows — 동적 워크플로 6가지 패턴 기술 가이드
- claude-code — Claude Code 기본 소개