최종 업데이트: 2026-06-12

대상: Claude Code v2.1.154 이후 (Pro / Max / Team / Enterprise / API / Bedrock / Vertex / Foundry)

상태: Research Preview (사양은 변경될 수 있습니다)

시작하며 — 「ultracode」라고 쓰는 것만으로 어떤 일이 일어나는가

2026년 5월 28일 (PT), Anthropic은 Claude Opus 4.8과 동시에, Claude Code v2.1.154에서 **Dynamic Workflows (동적 워크플로우)**를 Research Preview로 공개했습니다.

사용법은 허탈할 정도로 간단합니다. 프롬프트 어딘가에 ultracode라는 단어를 포함하기만 하면 됩니다. 그러면 Claude는 해당 태스크를 수행하기 위한

JavaScript 스크립트를 스스로 작성하고, 전용 런타임(runtime)이

백그라운드에서 다수의 서브 에이전트(sub-agent)를 팬아웃(fan-out) 실행합니다.

트리거 단어의 변경 (v2.1.160): Dynamic Workflows의 트리거 키워드는 v2.1.160 (2026-06-01 PT)에서 변경되었습니다 (공식 changelog). 이로 인해 workflow에서 ultracode로 개칭되었습니다 (자연스러운 말로 "워크플로우를 만들어줘"라고 부탁하는 것은 여전히 유효합니다). 트리거 단어는 입력창에서 workflow라는 단어 자체로는 워크플로우가 기동되지 않으며 보라색(violet)으로 하이라이트됩니다. 본 기사는 공개 당시에 workflow를 트리거 단어로 해설했으나, 이 변경 사항을 반영하여 ultracode로 업데이트했습니다. 동시에 최대 16개, 1회 실행으로 총계 최대 1,000개의 에이전트가 병렬로 브레인스토밍하고, 서로의 결과를 적대적으로 리뷰하며, 답이 안정될 때까지 수렴해 나갑니다 —— 이것이 Dynamic Workflows입니다.

본 기사는 단순한 기능 소개가 아니라, **"내부에서 어떤 일이 일어나고 있는가", "어떻게 제어하는가", "비용이 얼마나 드는가"**라는 구현자 관점의 의문에 답하는 것을 목적으로 합니다. 릴리스 공지 수준의 개요는 Claude Code 버전 이력 요약, Routines나 /code-review (구 /ultrareview)와의 운용은 각 전용 기사에 맡기고, 본 기사는 Dynamic Workflows 자체의 내부 구조와 제어에 집중합니다.

본 기사는 2026년 5월 시점의 공식 문서, 공식 블로그, 보도에 근거합니다. Research Preview이므로 수치 및 동작은 향후 변경될 수 있습니다.

1. Dynamic Workflows란 무엇인가

본질: 서브 에이전트를 통합하는 "자동 생성 스크립트"

Dynamic Workflow의 정체는 "서브 에이전트를 대규모로 오케스트레이션(orchestration)하는 JavaScript 스크립트"입니다. 중요한 점은 이 스크립트를 사용자가 작성하는 것이 아니라, 태스크 기술로부터 Claude가 자동으로 생성한다는 점입니다. 생성된 스크립트는 대화와 격리된 전용 런타임에서 실행되며, 그동안 세션은 응답 가능한 상태로 유지됩니다.

여기서 결정적인 것은 중간 결과의 저장 위치입니다. 일반적인 에이전트 실행에서는 각 단계의 출력이 모두 Claude의 컨텍스트 윈도우(context window)에 쌓이게 되어, 장대한 태스크에서는 컨텍스트가 고갈됩니다. Dynamic Workflows에서는 중간 결과가 스크립트 변수(script variables)에 유지되며, Claude의 컨텍스트에는 최종 답변만 반환됩니다. 이를 통해 수백 개의 파일을 마이그레이션하는 것과 같이, 하나의 컨텍스트에는 도저히 담을 수 없는 규모의 태스크가 현실적으로 가능해집니다.

서브 에이전트 스킬과의 차이점 = "플랜을 어디에 두는가"

Claude Code에는 이미 서브 에이전트나 스킬(skill)이 있지만, Dynamic Workflows와의 차이점은 한 가지로 요약됩니다 —— **"플랜(루프, 분기, 중간 결과 관리)을 누가 보유하는가"**입니다.

즉, Dynamic Workflows는 "제어 흐름(Control Flow)을 model-driven에서 code-driven으로 옮기는" 메커니즘입니다. 루프, 분기, 팬아웃이 결정론적(Deterministic)으로 코드를 통해 실행되므로, 1,000단위의 서브 에이전트를 안정적으로 처리할 수 있습니다.

2. 출시 및 대응 환경

대응 플랜 및 기본 설정

공식 문서에는 "모든 유료 플랜에서 이용 가능"하다고 명시되어 있습니다. 다만 플랜에 따라 기본 활성화/비활성화 상태가 다르다는 점에 주의하십시오.

조직 전체에서의 비활성화는 managed settings의 "disableWorkflows": true로, 개인은 /config 토글, ~/.claude/settings.json의 "disableWorkflows": true, 또는 환경 변수 CLAUDE_CODE_DISABLE_WORKFLOWS=1로 수행할 수 있습니다.

참고로, 서브 에이전트 수의 상한(후술할 동시 16개 · 총계 1,000개)은 플랜이 아니라 머신의 CPU 코어 수와 런타임 제약에 의해 결정되며, 플랜에 따른 상한 차이는 공식적으로 기재되어 있지 않습니다.

3. 3가지 실행 방법

Dynamic Workflows를 실행하는 데에는 3가지 트리거가 있습니다.

ultracode 키워드가 잘못 입력된 경우(워크플로우화하고 싶지 않은데 단어가 포함된 경우)는 alt+w(또는 트리거어 입력 직후 backspace)로 무시할 수 있으며, /config의 "Workflow keyword trigger"에서 트리거 자체를 끌 수도 있습니다. 참고로 이 트리거어는 당초 workflow였으나, v2.1.160에서 ultracode로 명칭이 변경되었습니다. /config의 토글 명칭이 여전히 "Workflow keyword trigger"인 것은 기능명(Workflow)에서 유래한 흔적입니다.

번들링된 ** /deep-research**는 Dynamic Workflows의 좋은 예시입니다. 여러 각도에서 웹 검색을 팬아웃(fan-out) → 소스 취득 → 상호 대조(cross-check) → 각 주장에 대한 투표 → 대조 과정에서 남지 않은 주장을 제외하고,

인용이 포함된 리포트를 반환한다는 다단계 파이프라인이 하나의 명령어로 통합되어 있습니다.

4. 실행 메커니즘 (아키텍처와 제약 사항)

런타임 격리와 리소스 상한

Dynamic Workflows의 런타임은 대화와는 격리된 환경에서 스크립트를 실행합니다. 병렬도에는 명확한 상한이 있습니다.

즉, '최대 1,000'은 1회 실행을 통한 누적 수이며, 동시에 1,000개가 실행되는 것은 아닙니다. 실질적인 동시 실행 수는 머신의 CPU 코어 수에 따라 달라집니다 (공칭 상한은 16이며, 코어 수가 적은 머신에서는 이보다 더 적어집니다).

v2.1.172 — 서브 에이전트의 다계층 생성 (트리형 실행으로)

초기 실행 모델은 생성 스크립트(오케스트레이터)가 다수의 서브 에이전트를 **플랫하게 팬아웃(flat fan-out)**하는 형태가 기본이었습니다. **v2.1.172 (2026-06-10 PT)**에서 서브 에이전트 스스로가 자신의 서브 에이전트를 생성할 수 있게 되었으며, 최대 5계층까지 중첩할 수 있도록 확장되었습니다 (공식 changelog: "Sub-agents can now spawn their own sub-agents (up to 5 levels deep)").

이를 통해 플랫한 팬아웃에 더해, 부모 → 자식 → 손자... 순으로 태스크를 단계적으로 분할하는 트리형(계층형) 실행을 표현할 수 있습니다. 예를 들어 "대분류별로 서브 에이전트를 세우고, 각 서브 에이전트가 다시 세부 항목별로 자식 에이전트로 분할하는" 식의 구조를 짤 수 있습니다.

단, 주의할 점은 동시 최대 16 · 총계 최대 1,000 / run이라는 리소스 상한은 여전히 전체에 적용된다는 것입니다. 계층을 깊게 하더라도 실행되는 누적 에이전트 수의 상한(1,000)은 변하지 않기 때문에, 각 계층에서 자식을 너무 많이 늘리면 총계 상한에 빠르게 도달합니다. 깊은 트리를 구성할 경우에는 계층 × 분기수의 곱셈으로 누적 수가 불어난다는 점을 고려해야 합니다.

스크립트는 "조정자", 실제 작업은 에이전트가 수행

워크플로 스크립트 자체는 파일 시스템이나 셸에 직접 접근하지 않습니다. 실제 파일 읽기/쓰기, 명령 실행, 웹 취득은 각 서브 에이전트가 담당하며, 스크립트는 조정자(오케스트레이터) 역할에 집중합니다. 이러한 분리가 결정론적인 제어 흐름과 에이전트의 유연성을 양립하게 합니다.

권한 모델 — acceptEdits와 allowlist 상속

장시간·다병렬로 동작하기 때문에 권한 처리를 숙지해야 합니다.

• 워크플로가 생성하는 서브 에이전트는 항상 acceptEdits 모드로 동작하며, 사용자의 도구 허용 목록(allowlist)을 상속합니다.
  • 파일 편집은 자동 승인됩니다.
  • 허용 목록 외의 셸 명령, Web fetch, MCP 도구는 실행 중에 프롬프트를 띄울 수 있습니다 (claude -p / Agent SDK에서는 프롬프트 없이 실행).

→ 장시간 run을 무인으로 돌릴 경우에는 필요한 명령어를 사전에 허용 목록에 추가해 두는 것이 실무적인 팁입니다.

v2.1.178 — 서브 에이전트를 모델 단위로 제어

**v2.1.178 (2026-06-15)**에서 권한 규칙에 Tool(param:value) 구문(* 와일드카드 대응)이 추가되었습니다 (공식 changelog: "Added Tool(param:value) syntax for permission rules to match a tool's input parameters ... e.g. Agent(model:opus)"). 이를 통해 예를 들어 Agent(model:opus)와 같이 모델 단위로 제어할 수 있게 되었습니다.

예를 들어 "Opus 서브 에이전트 차단(to block Opus subagents)"과 같이,

Agent(model:opus)

를 통해 워크플로가 생성하는 Opus 서브 에이전트의 기동을 차단하는 등 권한 규칙(permission rules)으로 서브 에이전트의 모델을 제어할 수 있습니다. 대량 병렬로 실행되어 비용이 급증하기 쉬운 Dynamic Workflows에서, "비싼 모델의 서브 에이전트를 금지하고 기계적인 처리는 저렴한 모델로 돌린다"라는 비용 및 폭주 방지 대책을 권한(permission) 측면에서도 적용할 수 있게 된 실무적인 추가 기능입니다.

이와 함께 v2.1.178에서는 auto 모드에서 서브 에이전트의 기동이 '기동 전'에 분류기(classifier)에 의해 평가되도록 변경되어 ("subagent spawns are now evaluated by the classifier before launch"), 서브 에이전트가 리뷰를 거치지 않고 차단 대상인 액션을 요구할 수 있었던 허점이 보완되었습니다. 다계층·다병렬로 작동하는 Dynamic Workflows의 안전성이 한 단계 강화되었습니다.

재개(resume)는 동일 세션 내에서만 가능

각 에이전트의 결과가 추적되고 있기 때문에, 동일 세션 내라면 워크플로를 재개할 수 있습니다. 완료된 에이전트는 캐시된 결과를 반환하고, 남은 부분만 라이브로 실행됩니다. 다만, Claude Code를 종료하면 다음 세션에서는 워크플로를 처음부터 다시 시작해야 한다는 점에 주의하십시오.

런타임 제약 사항 요약

5. /workflows로 모니터링 및 제어

실행 중이거나 완료된 워크플로는 /workflows 명령어로 목록을 표시하고, 선택하여 진행 상황 뷰(progress view)를 열 수 있습니다. 진행 상황 뷰는 **페이즈(phase)별로 "에이전트 수", "누적 토큰 수", "경과 시간"**을 표시하며, 특정 페이즈로 드릴인(drill-in)하면 각 에이전트의 프롬프트, 최근 도구 호출(tool call), 결과까지 확인할 수 있습니다.

입력창 하단의 task panel에도 진행 상황의 한 줄 요약이 표시됩니다. /workflows를 통해 언제든 중지할 수 있으며, 중지하더라도 완료된 작업은 사라지지 않습니다. 데스크톱 앱에서는 실행 시 승인 카드(워크플로 이름, 페이즈 목록, 토큰 사용 주의 사항, Once / Always / Deny)가 표시되며, Background tasks 사이드 페인에서 진행 상황을 추적할 수 있습니다.

특기할 만한 점은 s 키를 이용한 스크립트 저장입니다. 한 번 생성된 유용한 워크플로를 명령어로 저장하면, 이후에는 /your-workflow와 같이 호출할 수 있습니다. /deep-research와 동일한 메커니즘을 자신의 워크플로에서도 구축할 수 있는 것입니다.

6. ultracode와 effort 레벨의 정확한 관계 (혼동 주의)

이 부분은 가장 오해하기 쉬운 포인트입니다. ultracode는 effort 레벨의 한 종류가 아닙니다.

Opus 4.8의 effort 레벨은 5단계

ultracode는 「effort 레벨」이 아니라 「Claude Code의 설정」

공식 정의는 다음과 같습니다——ultracode는 xhigh를 모델에 전달하면서, 실질적인 태스크마다 Claude가 동적 워크플로 (Dynamic Workflow)를 오케스트레이션 (Orchestration)하도록 하는 설정입니다.

즉, 단발성 태스크만 워크플로화하고 싶다면 ultracode 키워드(프롬프트에 한 단어 추가), 세션 전체를 고난도 모드로 자동 오케스트레이션하고 싶다면 /effort ultracode (슬래시 커맨드)로 구분하여 사용합니다. 트리거 단어와 effort 설정이 **ultracode**라는 동일한 단어를 공유하므로 혼동하지 않도록 주의해야 합니다——프롬프트 본문에 쓰면 단발 트리거입니다.

/effort ultracode를 입력하면 세션 전체 설정이 적용됩니다.

설정 파일 보충:
effortLevel 설정 파일에 작성할 수 있는 값은 low/medium/high/xhigh뿐이며, max와 ultracode는 작성할 수 없습니다 (세션 한정이기 때문). 또한, claude.ai 등 채팅 UI상의 effort 표기(「extra」, 「max」 등)와 Claude Code/API의 토큰 명칭(xhigh 등)은 완전히 일치하지 않을 수 있습니다. Claude Code에서는 xhigh가 채팅 UI의 「extra」에 해당한다고 이해하시면 됩니다.

7. 품질을 높이는 반복 패턴

Dynamic Workflows의 진정한 가치는 「다수의 에이전트를 병렬로 실행하는 것」 그 자체에 있는 것이 아니라, 결과의 품질을 높이는 반복 패턴을 코드로 구성할 수 있다는 점에 있습니다. 공식에서 제시하는 대표적인 패턴은 다음과 같습니다.

• 적대적 리뷰 (adversarial review): 독립된 에이전트가 서로의 결과에 대해 반증하는 역할을 맡습니다. 다수결을 통해 의심스러운 결론을 기각하고, 그럴듯하지만 잘못된 발견(findings)을 배제합니다.
• 복수 안 초안 작성 및 비교: 동일한 과제에 대해 서로 다른 각도에서 여러 플랜을 병렬로 초안 작성하고, 상호 비교하여 최선의 안으로 수렴시킵니다 (하나의 안을 순차적으로 개선하는 것보다 탐색 공간을 더 넓게 확보할 수 있습니다).
• 수렴할 때까지 반복 (iterative convergence): 답이 안정될 때까지 탐색을 반복합니다. 미지의 크기를 찾아내는 태스크(버그 소탕 등)에서 단순한 「상위 N개」 방식보다 누락을 줄일 수 있습니다.

이것들은 단순히 「수를 늘리는 것」이 아니라 「다양한 관점을 대조하여 확실성을 높이는」 설계이며, /deep-research의 「투표로 남지 않은 주장을 제외」하는 방식도 이 계보에 속합니다.

8. 예상 유스케이스

상징적인 사례로, MarkTechPost는 Jarred Sumner의 워크플로우가 Bun의 코드를 Zig에서 Rust로 이식하여, 약 11일 동안 약 75만 행을 생성하고 기존 테스트 스위트(Test Suite)의 99.8%를 통과했다고 보도했습니다 (수치는 MarkTechPost 보도에 기반함). 공식 측에서도 "Claude Code는 Opus 4.8과 함께, 수십만 행 규모의 코드베이스 마이그레이션을 시작부터 머지(Merge)까지 기존 테스트 스위트를 기준으로 실행할 수 있다"라고 밝히고 있습니다.

9. 비용 및 주의사항

Research Preview 단계이기에 따른 제한 사항과, 무엇보다 **토큰 비용 (Token Cost)**을 이해하는 것이 중요합니다.

• 높은 토큰 소비: 공식 문서에는 "1회 실행(run)이 동일한 작업을 대화로 수행하는 것보다 현저히 많은 토큰을 소비할 수 있다"라고 명시되어 있습니다. 최대 1,000개의 에이전트를 기동할 수 있으므로, 비용이 급격히 증가할 수 있습니다. run은 통상적인 세션과 마찬가지로 플랜 사용량 및 레이트 리밋 (Rate Limit)에 합산됩니다.
• 폭주 방지 설계: "총합 1,000개"라는 상한선 자체가 폭주 루프를 방지하기 위한 대책입니다. 이에 더해 실행 전의 플랜 승인 프롬프트 (페이즈 목록 표시, Yes / View raw script / No), /workflows를 통한 일시 정지 · 전체 정지 · 에이전트 단위 정지 기능이 마련되어 있습니다.
• 모델 비용 제어: 각 에이전트는 세션의 모델을 사용합니다. 큰 규모의 run을 실행하기 전에 /model을 확인하고, 불필요한 단계는 소형 모델로 라우팅(Routing)하도록 요청하면 비용을 절약할 수 있습니다.
• 범위를 좁힌 테스트부터 시작: 공식 및 Anthropic 블로그 모두 "규모를 키우기 전에 범위를 좁혀 테스트하라"고 주의를 권고하고 있습니다.

Opus 4.8 / Fast mode 요금 (참고)

Fast mode는 "이전 모델의 Fast mode보다 3배 저렴"하다고 합니다 ("표준의 2배 단가"와 "이전 모델 대비 3배 저렴"은 서로 다른 측면의 이야기이므로 혼동에 주의하십시오. 금액은 The New Stack / VentureBeat 보도에 기반하며, 최종적으로는 공식 요금 페이지에서 확인하는 것을 권장합니다).

10. 기존 기능과의 역할 분담

Dynamic Workflows는 단독으로 완결되는 기능이 아니라, Claude Code의 다른 오케스트레이션 (Orchestration) 기능들과 계층을 이룹니다. 상세 내용은 각 전용 기사에 맡기고, 여기서는 위치 선정(Positioning)만 정리합니다.

→ Routines, Agent View, Monitor/Push에 대한 자세한 내용은 'Claude Code Monitor 도구 & Push 알림 완전 가이드'를, Routines 자체의 설정은 전용 기사를 참조하십시오.

11. 버전 보충 — v2.1.160에서 도입된 주변 변경 사항

트리거 단어 명칭 변경(§서론)과 동일한 v2.1.160 (2026-06-01 PT) 버전에서는, 무인 상태로 장시간 워크플로우 (Workflow)를 실행할 때와 관련된 안전 측면의 변경 사항도 도입되었습니다 (공식 changelog).

보충: 워크플로우 (Workflow)의 서브 에이전트 (Sub-agent)는

acceptEdits

로 동작하므로, 위의 acceptEdits 빌드 설정 파일 확인은 무인 실행 (run) 중에 해당 파일에 쓰려고 하면 프롬프트가 나타날 수 있음을 의미합니다. 장시간 무인 실행을 하는 경우에는 필요 시 사전에 허용 리스트 (Allowlist)에 추가해 두면 중단을 피할 수 있습니다.

요약

• Dynamic Workflows = 서브 에이전트 (Sub-agent)를 묶는 자동 생성 JavaScript 스크립트. 제어 흐름 (Control flow)을 model-driven에서 code-driven으로 옮김으로써, 하나의 컨텍스트 (Context)에 담을 수 없는 대규모 태스크를 처리함.
• 실행 방식은 3가지:
  • (단발성) /ultracode
  • 키워드 (세션 전체) /effort ultracode
  • 저장된 명령 (/deep-research