Claude Code Dynamic Workflows는 단순히 “에이전트를 많이 띄우는 기능”이 아닙니다. Claude Code가 JavaScript workflow script를 쓰고, 백그라운드 runtime이 여러 subagents를 조정하는 방식입니다. 계획 자체를 읽고, 저장하고, 다시 개선할 수 있는 코드로 만들어야 할 때만 사용할 가치가 있습니다. 일반 Claude Code 세션, 하나의 subagent, skill, hook, routine이 작업의 owner라면 더 작은 표면에서 시작해야 합니다.
2026년 6월 3일 기준 Anthropic 공식 docs는 Dynamic Workflows를 research preview로 설명하며 Claude Code v2.1.154 이상을 요구합니다. workflow run은 plan usage와 rate limits에 포함되고, 현재 docs의 한도는 concurrent agents 최대 16개, run당 total agents 최대 1,000개입니다. 이 숫자는 강력하지만, 첫 판단을 보수적으로 만들어야 하는 이유이기도 합니다.
| 앞에 있는 작업 | Dynamic Workflows가 맞는 경우 | 더 작은 표면이 맞는 경우 | 첫 안전 행동 |
|---|---|---|---|
| 큰 repo audit 또는 migration | 독립 slice를 병렬로 실행하고 비교해야 함 | 한 파일, 한 패키지, 한 reviewer로 충분 | 작은 slice와 verification bar 지정 |
| 반복 research 또는 validation loop | branching plan을 script로 남겨야 함 | 방법만 재사용하면 됨 | skill로 시작 |
| tool-heavy implementation | subagents가 별도 read/write/command context 필요 | deterministic event rule이면 충분 | hooks 사용 |
| scheduled 또는 unattended work | workflow가 큰 runtime의 일부 | cadence, retry, external state가 owner | routine 또는 external job system |
| ultracode exploration | Claude가 workflow 필요성을 판단하길 원함 | simple session으로 끝남 | 작게 시작하고 /workflows 관찰 |
중지 규칙은 분명합니다. 첫 run을 whole-repo migration, 넓은 research sweep, 높은 권한 workflow로 시작하지 마십시오. 작은 범위를 정하고, 필요한 tools만 승인하고, /workflows에서 상태와 usage를 본 다음 evidence로 stop, save, resume, scale을 결정합니다.
계획이 script가 되면 무엇이 바뀌나
핵심 변화는 계획이 어디에 있느냐입니다. 일반 Claude Code 세션에서는 plan, tool results, 수정 판단이 대화 context에 남습니다. Dynamic Workflow에서는 Claude가 JavaScript orchestration script를 쓰고 runtime이 이를 백그라운드에서 실행합니다. script는 subagents를 시작하고, branch를 나누고, intermediate results를 모아 synthesis를 반환합니다.
이 구조는 독립 검증이 품질을 높이는 작업에 맞습니다. security audit, multi-package migration, architecture risk review, claim verification은 여러 clean context가 evidence를 강화할 수 있습니다. agent 수가 많다는 사실은 품질의 증거가 아닙니다. 분담, 독립 검증, 최종 비교가 있어야 workflow가 의미를 갖습니다.
대신 conversational control은 줄어듭니다. workflow는 매 단계 사용자에게 다시 묻지 않습니다. permission prompt는 남지만 run은 background에서 계속됩니다. subagents는 허용된 tools에 따라 read, write, command execution을 할 수 있습니다. 그래서 첫 workflow는 작고, 관찰 가능하고, 멈출 수 있어야 합니다.
| 구성요소 | 담당 | 확인할 것 |
|---|---|---|
| Claude Code session | request, approval, final review | orchestration이 필요한가 |
| Workflow script | branching, subagent calls, synthesis | 읽을 수 있고 저장 가능하며 재사용 가능한가 |
| Subagents | 독립 slice | write, command, 중복 탐색, 누락 검증 |
| /workflows | run 관리와 usage visibility | stop, save, resume 판단 |
script가 “한 agent에게 한 파일 수정”만 한다면 workflow 문제가 아닙니다. migration, audit, validation harness를 반복 가능하게 저장할 때 workflow가 의미를 얻습니다.
subagents, skills, hooks, routines와의 차이
Dynamic Workflows는 다른 Claude Code 표면을 대체하지 않습니다. 먼저 어떤 layer가 owner인지 정해야 합니다.
| 표면 | best owner | 맞는 경우 | workflow가 아닌 이유 |
|---|---|---|---|
| 일반 세션 | 하나의 live conversation | 한 context로 해결 가능 | 복잡해 보여도 script는 불필요 |
| Subagent | specialized worker | 독립 reviewer 또는 investigator 필요 | 한 worker로 충분하면 더 저렴 |
| Skill | reusable method | 절차를 다시 쓰고 싶음 | runtime branching이 필요 없음 |
| Hook | deterministic event rule | 이벤트 전후 자동 실행 | rule은 agent fan-out이 아님 |
| Routine | unattended runtime | schedule 또는 external trigger가 owner | workflow는 scheduler가 아님 |
| Dynamic Workflow | JavaScript orchestration script | plan을 code로 남겨야 함 | agent 수만 많다고 품질이 오르지 않음 |
이 exit가 안전장치입니다. method는 skill, lifecycle guardrail은 hook, 내일 아침 자동으로 깨어나야 하는 일은 routine에 가깝습니다. Dynamic Workflows는 계획을 reviewable script로 남길 가치가 있을 때만 선택합니다.
ultracode, deep research, /workflows의 역할
진입점은 여러 개입니다. 가장 투명한 방법은 Claude에게 workflow를 직접 요청하고 plan, slice, allowed tools, verification bar를 먼저 요구하는 것입니다. /deep-research는 research-heavy synthesis에 맞습니다. /workflows는 run 상태, usage, 저장과 중지를 보는 관리 표면입니다.
ultracode는 session setting입니다. 현재 model configuration docs는 이를 일반 effort level과 구분합니다. very high effort를 쓰고 substantive task에서 Dynamic Workflows orchestration을 고려하게 합니다. saved workflow도 아니고, 고정 비용도 아니며, 모든 task를 workflow로 만들라는 신호도 아닙니다.
| 필요 | 시작점 | 이유 |
|---|---|---|
| 명시적 orchestrated run | workflow 직접 요청 | decision이 보임 |
| research synthesis | /deep-research | research 형태에 맞음 |
| 필요성 탐색 | ultracode | Claude가 workflow 가능성을 판단 |
| run 관리 | /workflows | usage와 상태가 보임 |
| 입증된 harness 재사용 | saved workflow file | plan이 artifact가 됨 |
구버전 동작을 추정하지 말고 먼저 업데이트한 뒤 같은 environment의 /config와 /workflows에서 확인합니다.
첫 workflow를 안전하게 실행하기
시작 전 세 가지를 확인합니다. 작업을 독립 slice로 나눌 수 있는가. 비교와 검증이 품질을 높이는가. orchestration script가 나중에도 재사용될 수 있는가. 하나라도 약하면 일반 session, subagent, skill로 돌아갑니다.
좋은 첫 prompt는 좁습니다. repo 전체가 아니라 auth package와 관련 tests만 대상으로 삼습니다. 목표는 migration risk 세 개를 찾고, patch 제안을 만들고, 기존 test command로 검증하는 것입니다. package 밖은 수정하지 않고, write 전 permission을 요청하며, scale 전에 usage와 unresolved risks를 보고하게 합니다.
이 prompt는 scope, tools, verification, scaling condition을 모두 고정합니다. 원하는 결과는 많은 agent activity가 아니라 판단입니다. script-owned orchestration이 일반 세션보다 더 나은 evidence를 제공했는가입니다.
run 중에는 /workflows를 열어둡니다. tokens가 독립 작업에 쓰이는지, 중복 탐색에 쓰이는지 확인합니다. permission이 너무 넓은지 확인합니다. synthesis가 각 subagent의 검증 내용을 설명하는지 봅니다. 약하면 stop하고 범위를 줄입니다.
비용, 제한, 권한, 비활성화 제어
Dynamic Workflows는 무료 병렬성이 아닙니다. 현재 docs는 workflow runs가 plan usage와 rate limits에 포함되고, 같은 task를 single conversation으로 처리할 때보다 더 많은 tokens를 쓸 수 있다고 설명합니다. /workflows는 workflow usage를 보여주고, /usage는 Claude Code 전체 사용을 확인하는 데 유용합니다.
2026년 6월 3일 기준 current limits는 concurrent agents 최대 16개, run당 total agents 최대 1,000개입니다. 충분히 강력하지만 loose prompt가 예산을 빠르게 태울 수 있습니다.
permission control은 launch 전부터 시작됩니다. subagents는 허용된 tools와 approval path에 따라 움직입니다. 첫 run은 target path, allowed commands, review checkpoint를 좁혀야 합니다. team rollout에서는 /config, disableWorkflows, CLAUDE_CODE_DISABLE_WORKFLOWS=1, managed settings, admin settings 중 어디가 stop control인지 정해야 합니다.
| 사전 질문 | 이유 | 증거 |
|---|---|---|
| version | old behavior 방지 | local version check |
| feature enabled | availability 변화 가능 | /config와 same-day docs |
| smallest slice | broad run 방지 | target path와 verification bar |
| tools | write와 commands 범위 | approval mode와 allowlist |
| usage monitoring | tokens 증가 가능 | /workflows, /usage |
| disable owner | kill switch 필요 | settings, env, admin |
이 표를 채울 수 없다면 넓은 workflow는 아직 이릅니다.
맞는 예와 맞지 않는 예
좋은 후보는 여러 clean context가 evidence를 강화하는 작업입니다. large migration은 package별 변경과 test가 가능할 때 맞습니다. security audit은 dependency risk, auth boundary, data exposure, test coverage를 나눠볼 수 있을 때 맞습니다. claim verification은 docs, code, runtime behavior를 독립 확인할 때 맞습니다.
나쁜 후보도 많습니다. single-file refactor는 중요하다고 workflow가 되지 않습니다. deterministic pre-commit behavior는 hook입니다. reusable prompt method는 skill입니다. daily repo sweep은 routine에 가깝습니다. 단순 debugging은 진짜 branch가 생길 때까지 conversation으로 충분합니다.
team risk도 있습니다. 각 subagent가 무엇을 증명해야 하는지 말할 수 없다면 workflow는 불확실성을 감춥니다. verification bar를 먼저 쓰고 agents가 필요한지 결정합니다.
성공 후 무엇을 저장할까
saved workflow는 transcript가 아니라 automation artifact여야 합니다. owner, inputs, allowed tools, stop rule, verification, reuse rule을 명시합니다.
| 항목 | 남길 내용 |
|---|---|
| Owner | repo area, team, release job |
| Intent | manual audit, migration slice, research harness |
| Inputs | paths, branch assumptions, test commands |
| Tool boundary | reads, writes, commands |
| Stop rule | 언제 멈출지 |
| Verification | tests, comparisons, review evidence |
| Reuse rule | 언제 다시 실행할지 |
run이 성공했다고 저장하지는 않습니다. 일반 prompt보다 script가 읽기 쉽고, 재사용하기 쉽고, 개선하기 쉬울 때 저장합니다.
팀 도입 전에 확인할 것
팀에서 Dynamic Workflows를 도입할 때 핵심은 agents 수가 아니라 ownership입니다. owner, allowed tools, stop rule, verification evidence, rollback path가 없으면 saved workflow는 공유 자동화가 아니라 개인 실험에 가깝습니다.
첫 run의 evidence를 남기십시오. prompt, target paths, approved tools, workflow slices, /workflows usage, subagents findings, failed branches, test commands, unresolved risks가 필요합니다. synthesis가 각 subagent의 검증을 설명하지 못하면 scope를 넓히지 않습니다.
| 확인 항목 | 통과 신호 | 약할 때 |
|---|---|---|
| Owner | repo area 또는 team이 명확 | 공유하지 않음 |
| Permission boundary | writes와 commands 제한 | scope 축소 |
| Usage evidence | /workflows와 /usage 확인 | fan-out 축소 |
| Verification | tests와 comparison 명시 | prompt 재작성 |
| Disable path | /config, settings, env, admin owner 명확 | rollout 보류 |
Dynamic Workflows는 review process를 대체하지 않습니다. migration slice, claim verification, audit harness처럼 반복 가능한 작업에서 먼저 가치를 증명하고, script, explanation, reuse rule을 함께 저장해야 합니다.
자주 묻는 질문
Dynamic Workflows는 subagents와 같은가요?
아닙니다. subagents는 worker입니다. Dynamic Workflow는 여러 worker를 script로 조정하는 orchestration layer입니다.
ultracode는 무엇을 하나요?
ultracode는 session setting입니다. very high effort와 substantive task에서 Dynamic Workflows 사용 가능성을 결합합니다. saved workflow는 아닙니다.
/deep-research는 workflow인가요?
research-heavy workflow behavior의 entry point로 볼 수 있습니다. coding migration이나 audit에서는 scope, tools, verification을 명확히 써야 합니다.
saved workflows는 어디에 있나요?
current docs는 .claude/workflows/와 ~/.claude/workflows/를 언급합니다. reviewable automation artifact로 다루어야 합니다.
나중에 resume할 수 있나요?
current docs는 resume을 같은 Claude Code session과 연결합니다. 떠나기 전에 /workflows에서 상태를 확인하십시오.
비용이 많이 드나요?
고정 가격을 말할 수 없습니다. usage와 rate limits에 포함되고 single conversation보다 더 많은 tokens를 쓸 수 있습니다. 작게 시작해 /workflows와 /usage를 봅니다.
비활성화할 수 있나요?
/config, disableWorkflows, CLAUDE_CODE_DISABLE_WORKFLOWS=1, managed settings, admin settings를 확인합니다. 팀에서는 owner를 정해야 합니다.
routines, hooks, skills를 대체하나요?
아닙니다. workflows는 script-owned orchestration, routines는 unattended runtime, hooks는 deterministic event rules, skills는 reusable method를 담당합니다.