Claude Code를 오래 쓰다 보면 단일 에이전트의 한계가 보입니다. 작은 버그 수정이나 파일 몇 개짜리 리팩터링은 잘 처리하지만, 코드베이스 전체를 훑는 감사, 수백 파일에 걸친 마이그레이션, 서로 다른 가설을 독립적으로 검증해야 하는 작업은 한 번의 긴 대화로 밀어붙이기 어렵습니다.
Dynamic Workflows ↗는 이 틈을 겨냥합니다. Claude가 작업을 동적으로 계획하고, 오케스트레이션 스크립트를 만들고, 수십~수백 개의 병렬 subagent를 실행한 뒤, 결과를 검증해 하나의 답으로 묶는 방식입니다.
이 글은 작성 시점 2026-06-17 · Anthropic 공식 발표 ↗, Claude Code subagents 문서 ↗, Claude Code Ultra Plan 문서 ↗ 스냅숏 기준으로 정리했습니다.
Dynamic Workflows가 하는 일
Dynamic Workflows는 단순히 “subagent를 많이 띄운다”가 아닙니다. 핵심은 Claude가 작업에 맞는 실행 구조를 즉석에서 만든다는 데 있습니다.
공식 발표는 workflow가 시작되면 Claude가 prompt를 바탕으로 계획을 세우고, 작업을 subtasks로 나누고, 병렬 subagents로 펼친 뒤, 결과를 합치기 전에 검증한다고 설명합니다. 어떤 agent는 문제를 독립적인 관점에서 풀고, 다른 agent는 그 결과를 반박하거나 깨뜨리려고 시도합니다.
flowchart TD
A[사용자 요청<br/>큰 마이그레이션·감사·버그 헌트] --> B[Claude가 workflow 계획]
B --> C[오케스트레이션 스크립트 생성]
C --> D[Subagents 병렬 실행]
D --> E[독립 검증·반박·재시도]
E --> F{결과 수렴?}
F -->|아니오| D
F -->|예| G[단일 보고서·패치·PR 후보]이 구조는 단일 agent가 한 번 읽고 답하는 방식과 다릅니다. 큰 작업을 여러 방향에서 동시에 시도하고, 서로의 결과를 검증하고, 수렴할 때까지 반복합니다.
왜 지금 중요한가
AI 코딩 도구의 첫 단계는 “파일 하나 고쳐줘”였습니다. 다음 단계는 “테스트가 통과할 때까지 수정해줘”였습니다. Dynamic Workflows는 그보다 더 큰 단위, 즉 작업 자체를 여러 에이전트의 실행 계획으로 바꾸는 단계에 가깝습니다.
이 변화가 중요한 이유는 세 가지입니다.
- 큰 코드베이스에서는 문제 위치가 명확하지 않습니다.
- 마이그레이션은 파일 단위 병렬성이 큽니다.
- 보안 감사나 성능 감사는 독립 검증이 필요합니다.
Anthropic은 예시로 코드베이스 전체 bug hunt, profiler 기반 최적화 감사, security audit, framework swap, API deprecation 대응, language port 같은 작업을 제시합니다. 이런 작업은 한 agent가 순차적으로 처리하기보다 여러 agent가 나눠 탐색하고, 별도 reviewer가 검증하는 구조가 더 자연스럽습니다.
Bun 포팅 사례가 보여주는 것
공식 발표에서 가장 눈에 띄는 사례는 Bun의 Zig→Rust 포팅입니다. 발표에 따르면 Jarred Sumner는 Dynamic Workflows를 사용해 Bun을 Zig에서 Rust로 포팅했고, 75만 줄 규모의 Rust 코드가 만들어졌으며, 기존 테스트 스위트의 99.8%가 통과하는 상태로 11일 만에 첫 커밋부터 merge까지 진행됐습니다.
여기서 중요한 건 “AI가 75만 줄을 썼다”는 숫자보다 workflow의 모양입니다.
- 한 workflow가 Zig 코드베이스의 각 struct field에 맞는 Rust lifetime을 매핑했습니다.
- 다음 workflow가 각
.zig파일을 동작이 동일한.rs파일로 포팅했습니다. - 파일마다 여러 agent가 병렬로 작업하고, 두 reviewer가 검토했습니다.
- fix loop가 build와 test suite를 반복 실행했습니다.
- 이후 workflow가 불필요한 data copy를 찾아 PR 단위로 정리했습니다.
이건 단일 prompt로 “Bun을 Rust로 바꿔줘”라고 던진 것이 아닙니다. 큰 목표를 탐색, 변환, 검증, 최적화 단계로 나누고, 각 단계를 다시 병렬 subtask로 펼친 구조입니다.
Agent Teams, Ultra Plan, Routines와의 차이
Claude Code에는 이미 여러 “큰 작업용” 기능이 있습니다. Dynamic Workflows는 그중에서도 실행 단계의 병렬성과 검증에 초점이 있습니다.
| 기능 | 중심 질문 | 잘 맞는 일 |
|---|---|---|
| Agent Teams | 역할을 나눈 에이전트 협업을 어떻게 구성할까 | researcher, writer, reviewer처럼 사람이 정한 역할 협업 |
| Ultra Plan | 실행 전에 계획을 더 깊게 다듬을까 | 큰 작업의 planning handoff, 브라우저 기반 검토 |
| Routines | 반복 작업을 클라우드에서 자동 실행할까 | 정기 점검, 이슈 triage, 반복 운영 작업 |
| Dynamic Workflows | 큰 작업을 동적으로 쪼개 병렬 실행·검증할까 | 코드베이스 전체 감사, 대규모 마이그레이션, 독립 검증이 필요한 작업 |
한 문장으로 나누면 이렇습니다. Agent Teams는 사람이 역할을 설계하는 방식이고, Ultra Plan은 계획을 별도 흐름에서 깊게 다듬는 방식입니다. Routines는 반복 실행 단위이고, Dynamic Workflows는 Claude가 실행 구조 자체를 동적으로 만드는 방식입니다.
어떻게 시작하나
공식 발표 기준 시작 방법은 두 가지입니다.
첫째, Claude에게 workflow를 직접 만들라고 요청합니다.
Create a dynamic workflow to audit this repository for unsafe input handling.
Start with a scoped pass over the API routes, verify findings independently,
and produce a report with file paths and minimal fix suggestions.둘째, Claude Code의 effort menu에서 ultracode 설정을 켭니다. 공식 발표는 ultracode가 effort level을 xhigh로 설정하고, Claude가 작업에 workflow가 필요할지 자동 판단하게 한다고 설명합니다.
Use ultracode for this migration. First map deprecated API usage, then
parallelize the safe replacements, and keep risky cases as review-only notes.처음부터 저장소 전체를 맡기는 것보다, 범위를 좁힌 task로 사용량과 결과 품질을 확인하는 편이 좋습니다. Anthropic도 Dynamic Workflows가 일반 Claude Code 세션보다 훨씬 많은 token을 쓸 수 있으므로 scoped task로 시작하라고 권합니다.
언제 써야 하나
Dynamic Workflows는 비싼 도구입니다. 그래서 “가능하다”보다 “필요한가”가 더 중요합니다.
잘 맞는 작업은 다음과 같습니다.
| 상황 | 이유 |
|---|---|
| 코드베이스 전체 bug hunt | 여러 영역을 병렬 탐색하고 독립 검증할 수 있음 |
| 보안·성능 감사 | finding과 refutation을 분리하기 좋음 |
| 대규모 API migration | 파일 단위 병렬성이 큼 |
| framework/language port | 매핑, 변환, 검증 단계를 나누기 좋음 |
| critical review | 여러 agent가 서로 다른 관점으로 검토 가능 |
반대로 다음 작업에는 과합니다.
- 파일 하나 수정
- 실패 테스트 하나 고치기
- 작은 UI 변경
- 이미 원인이 명확한 버그
- 사람이 먼저 의사결정해야 하는 제품 요구사항
운영 관점에서 볼 것
Dynamic Workflows는 더 많은 agent를 돌리므로, 운영 감각도 같이 필요합니다.
첫째, 범위를 좁혀야 합니다. “전체 repo를 개선해줘”보다 “API routes에서 unsafe input handling을 찾아 보고서로 정리해줘”가 낫습니다.
둘째, 검증 기준을 프롬프트에 넣어야 합니다. 테스트 명령, 빌드 명령, 변경 금지 영역, 보고서 형식, PR 분리 기준을 미리 알려주는 편이 좋습니다.
셋째, 자동 수정과 보고서 모드를 나눠야 합니다. 보안 감사, 인증 로직, 데이터 마이그레이션처럼 위험한 영역은 처음에는 patch를 만들기보다 finding report로 받는 편이 안전합니다.
넷째, 사용량을 관찰해야 합니다. Dynamic Workflows는 일반 세션보다 훨씬 많은 usage를 소모할 수 있습니다. 첫 실행에서 Claude Code가 실행 내용을 보여주고 확인을 요청한다는 점도 이 때문입니다.
블로그 대표 이미지 콘셉트
Claude Code 터미널에서 하나의 큰 작업이 workflow planner로 들어가고, 그 아래로 수십 개의 작은 subagent 노드가 병렬로 펼쳐지는 다이어그램이 잘 맞습니다. 왼쪽에는 “Large migration”, “Security audit”, “Bug hunt” 같은 입력이 있고, 중앙에는 “Dynamic workflow orchestrator”가 있습니다.
오른쪽에는 agent들이 만든 결과가 reviewer agent와 verification loop를 거쳐 하나의 report 또는 PR 후보로 수렴하는 흐름을 보여줍니다. 전체 톤은 어두운 IDE 배경 위에 청록색 병렬선과 노란색 검증 노드를 둔 기술 블로그용 아키텍처 일러스트가 좋습니다.
마무리
Dynamic Workflows는 Claude Code가 단일 에이전트 도구에서 더 큰 실행 시스템으로 넘어가고 있다는 신호입니다. 이제 중요한 질문은 “Claude가 코드를 잘 쓰는가”만이 아닙니다. Claude가 어떤 작업을 어떻게 나누고, 어떤 결과를 독립적으로 검증하고, 어디까지 자동화할 수 있는지가 중요해집니다.
다만 이 기능은 작은 수정의 기본값이 되어서는 안 됩니다. 비용도 크고, 변경 폭도 넓어질 수 있습니다. 먼저 scoped task로 시작하고, report mode와 patch mode를 분리하고, 테스트와 리뷰 기준을 분명히 두는 편이 좋습니다.
Claude Code의 자동화 흐름을 단계로 보면 /loop는 반복 확인, Routines는 정기 실행, Agent Teams는 역할 협업, Ultra Plan은 깊은 planning입니다. Dynamic Workflows는 그 다음 단계, 즉 큰 작업을 동적으로 쪼개 병렬 실행하고 검증하는 실행 엔진에 가깝습니다.