또 한 단계 올라갔다

Skills로 명령어를 통합하고, Routines로 예약 실행을 붙이고, Auto 모드로 권한 판단까지 AI에게 넘기더니, 이번엔 Claude가 오케스트레이션 스크립트를 직접 짜서 서브에이전트 수백 개를 한 세션에서 병렬로 돌린다. 2026년 5월 28일 Opus 4.8과 함께 공개된 Dynamic Workflows다.

지금까지의 서브에이전트는 Claude가 대화 턴마다 하나씩 띄우고 결과를 자기 컨텍스트로 받아오는 방식이었다. 몇 개까지는 괜찮지만, 500개 파일을 동시에 손봐야 하는 작업에서는 컨텍스트가 먼저 터진다. Dynamic Workflows는 그 한계를 넘으려고 나온 기능이다. (Anthropic 발표, TechCrunch)

주의: 이 글의 내용은 전부 리서치 프리뷰 기준이다. 동작 방식, 한도, 요금 모두 정식 출시 전에 바뀔 수 있다. Claude Code v2.1.154 이상이 필요하다.

한 줄 정의

공식 문서의 정의는 명확하다.

“A dynamic workflow is a JavaScript script that orchestrates subagents at scale.” — Claude Code Docs

워크플로우는 Claude가 작성하는 자바스크립트 오케스트레이션 스크립트다. 사용자가 작업을 설명하면 Claude가 그 작업에 맞는 스크립트를 쓰고, 런타임이 그 스크립트를 백그라운드에서 실행한다. 스크립트가 도는 동안 대화 세션은 그대로 응답 가능한 상태로 남는다.

핵심은 누가 계획을 들고 있느냐다.

서브에이전트·스킬과 뭐가 다른가

셋 다 멀티스텝 작업을 처리할 수 있다. 차이는 계획의 주체와 중간 결과의 저장 위치다.

서브에이전트스킬워크플로우
정체Claude가 띄우는 워커Claude가 따르는 지침런타임이 실행하는 스크립트
다음 실행 결정Claude가 턴마다Claude가 프롬프트 따라스크립트가
중간 결과 위치Claude 컨텍스트Claude 컨텍스트스크립트 변수
재사용 단위워커 정의지침오케스트레이션 자체
규모턴당 몇 개서브에이전트와 동일런당 수십~수백 개
중단 시턴 재시작턴 재시작같은 세션 내 재개

서브에이전트와 스킬에서는 Claude가 오케스트레이터다. 무엇을 띄울지 턴마다 판단하고, 모든 결과가 Claude 컨텍스트로 돌아온다. 워크플로우는 그 루프와 분기, 중간 결과를 스크립트 안으로 옮긴다. 그 결과 Claude 컨텍스트에는 최종 답만 남는다. 컨텍스트가 터지지 않는 이유가 여기 있다.

어떻게 도는가

작업을 워크플로우로 넘기면 세 단계를 거친다.

flowchart TD
    A[작업 설명 프롬프트] --> B[Claude가 스크립트 작성]
    B --> C[런타임이 백그라운드 실행]
    C --> D[서브태스크로 분할]
    D --> E[수십~수백 에이전트 병렬]
    E --> F[어드버서리얼 검증]
    F --> G{답이 수렴했나}
    G -->|아니오| D
    G -->|예| H[최종 보고]

대화 세션은 이 흐름 내내 자유롭다. /workflows를 실행하면 진행 중인 런의 진행 화면이 뜨고, 단계별 에이전트 수와 토큰 사용량, 경과 시간을 볼 수 있다.

패턴 1 — Fan-Out

워크플로우가 시작되면 Claude가 프롬프트를 기준으로 계획을 세우고, 작업을 서브태스크로 쪼갠 뒤 여러 에이전트에 병렬로 펼친다. 이걸 fan-out이라 부른다. 한 런에서 수십에서 수백 개의 에이전트가 동시에 돈다.

예를 들어 라우트 디렉토리 전체에서 인증 누락을 감사하라고 하면, 엔드포인트마다 에이전트 하나씩 붙여 동시에 점검한다.

Run a workflow to audit every API endpoint
under src/routes/ for missing auth checks

프롬프트에 workflow라는 단어를 넣으면 Claude Code가 그 단어를 강조 표시하고, 턴 단위로 처리하는 대신 워크플로우 스크립트를 작성한다.

패턴 2 — 어드버서리얼 검증

여기가 단순히 에이전트를 더 많이 돌리는 것과 갈리는 지점이다. 워크플로우는 반복 가능한 품질 패턴을 적용한다.

에이전트가 발견한 내용을 그냥 보고하지 않는다. 다른 에이전트가 그 발견을 반박하는 임무를 맡는다. 한 에이전트가 “이 함수에 race condition이 있다"고 주장하면, 다른 에이전트의 일은 그 주장을 깨는 것이다. 반박 패스를 살아남은 주장만 사용자에게 도달한다.

flowchart TD
    A[에이전트 A 주장] --> B[에이전트 B 반박 시도]
    B --> C{반박 성공}
    C -->|성공| D[주장 폐기]
    C -->|실패| E[주장 채택]
    E --> F[사용자에게 보고]

번들로 제공되는 /deep-research 워크플로우가 이 패턴을 그대로 쓴다. 여러 각도로 웹 검색을 펼치고, 찾은 출처를 서로 교차검증하고, 각 주장에 투표한 뒤, 교차검증을 통과하지 못한 주장은 걸러낸 인용 리포트를 돌려준다.

패턴 3 — 수렴 반복

고정된 단계의 파이프라인이 아니다. 워크플로우는 답이 더 이상 바뀌지 않을 때까지 반복한다. 에이전트 수와 반복 횟수는 작업이 실제로 요구하는 바에 따라 실시간으로 정해진다.

이 수렴 방식 덕분에 단일 패스로는 도달할 수 없는 결과까지 간다. 한 번 훑고 끝내는 게 아니라, 발견과 반박을 답이 안정될 때까지 돌리는 구조다.

실제 사례 — Bun을 Zig에서 Rust로

가장 인상적인 사례는 Jarred Sumner가 Bun 런타임을 Zig에서 Rust로 포팅한 작업이다. 약 75만 줄 코드를 11일 만에 옮겼다. 파일마다 에이전트를 붙여 수백 개를 병렬로 돌렸고, 파일당 리뷰어를 두 명씩 뒀다. (Anthropic 발표)

Anthropic은 이 기능의 목표를 “코드베이스 규모의 마이그레이션을 킥오프부터 머지까지, 기존 테스트 스위트를 합격 기준으로 삼아 수행"하는 것으로 잡았다. (TechCrunch) 기존 테스트가 통과 여부를 판정하니, 사람이 일일이 검수하지 않아도 합격선이 정의된다.

발표의 표현을 빌리면 분기 단위로 계획하던 일이 며칠 만에 끝난다. 다만 이건 잘 풀린 사례다. 테스트 커버리지가 부실한 코드베이스라면 합격 기준 자체가 흔들린다.

한도와 제약

런타임은 다음 제약을 건다.

제약이유
런 도중 사용자 입력 불가단계 사이 승인이 필요하면 단계별로 워크플로우를 쪼갤 것
워크플로우 자체의 파일·셸 직접 접근 불가읽기·쓰기·명령 실행은 에이전트가, 스크립트는 조율만
동시 에이전트 최대 16개 (코어 적으면 더 적게)로컬 자원 사용 제한
런당 총 에이전트 1,000개폭주 루프 방지

수백 개 병렬이라는 표현과 동시 16개가 충돌하는 것처럼 보이지만, 동시 실행은 16개로 묶이고 누적 총량이 런당 최대 1,000개라는 뜻이다. (Claude Code Docs, MarkTechPost)

권한 측면도 짚어둘 만하다. 세션 권한 모드와 무관하게, 워크플로우가 띄우는 서브에이전트는 항상 acceptEdits 모드로 돌고 파일 편집은 자동 승인된다. 긴 런에서 셸 명령이나 MCP 도구로 중간에 멈추고 싶지 않다면, 시작 전에 필요한 명령을 allowlist에 넣어두는 게 낫다.

어떻게 켜고 끄는가

워크플로우를 작성하게 하는 방법은 두 가지다.

방법동작
프롬프트에 workflow 단어 포함해당 작업 하나만 워크플로우로 처리
/effort ultracode 설정세션의 모든 주요 작업을 워크플로우로 계획

ultracode는 xhigh effort(추론 강도)와 자동 워크플로우 오케스트레이션을 묶은 설정이다. 켜두면 Claude가 작업마다 워크플로우가 필요한지 알아서 판단한다. 한 요청이 여러 워크플로우로 갈라질 수도 있다. 코드 이해용 하나, 변경용 하나, 검증용 하나 식으로. 그만큼 토큰과 시간을 더 쓴다.

마음에 드는 런이 나오면 /workflows에서 그 런을 골라 s 키로 명령어로 저장할 수 있다. 프로젝트의 .claude/workflows/에 두면 저장소를 받은 모두가, 홈의 ~/.claude/workflows/에 두면 나만 쓴다.

끄는 방법도 명확하다.

  • /config에서 Dynamic workflows 토글 끄기
  • ~/.claude/settings.json에 "disableWorkflows": true
  • 환경변수 CLAUDE_CODE_DISABLE_WORKFLOWS=1
  • 조직 전체는 managed settings의 "disableWorkflows": true

요금과 가용성

  • 리서치 프리뷰. Claude Code v2.1.154 이상 필요
  • 유료 플랜 전체에서 사용 가능 (Pro는 /config에서 켜야 함). 발표 기준 Max·Team·Enterprise는 기본 활성화
  • Anthropic API, Amazon Bedrock, Google Cloud Vertex AI, Microsoft Foundry 지원
  • 토큰 소비가 일반 세션보다 크게 많다. 에이전트를 수십~수백 개 띄우니 당연하다

비용 관리 팁도 문서에 있다. 큰 런 전에 /model을 확인하고, 강한 모델이 필요 없는 단계는 작은 모델로 라우팅하도록 작업 설명에 명시하면 된다.

함께 나온 Opus 4.8은 자기 작업의 불확실성을 더 적극적으로 드러내고, 근거 없는 주장을 덜 한다는 평가다. 어드버서리얼 검증 패턴과 맞물려 보면, 모델이 스스로 의심을 표하는 성향이 강해진 게 수백 개 에이전트를 신뢰하는 데 보탬이 된다. Fast 모드는 2.5배 속도로 동작하면서 이전 모델보다 3배 저렴해졌다. (Anthropic Opus 4.8 발표)

운영자 시각에서 한마디

Dynamic Workflows의 본질은 에이전트를 더 많이 돌리는 게 아니라 계획을 코드로 옮기는 데 있다. 오케스트레이션이 읽고 다시 돌릴 수 있는 스크립트로 굳으면, 매 브랜치마다 같은 리뷰를 같은 방식으로 돌릴 수 있다. 일회성 마법이 아니라 반복 가능한 프로세스가 된다는 뜻이다.

다만 지금은 리서치 프리뷰다. 한도도 동작도 바뀔 수 있고, 토큰 비용은 만만치 않다. 처음 쓴다면 작은 작업으로 범위를 좁혀 토큰 사용 패턴부터 감을 잡으라는 게 공식 권고다.

그래도 방향은 분명하다. 75만 줄 마이그레이션을 11일에 끝냈다는 사례가 과장이 아니라면, 분기 단위 작업의 정의가 다시 쓰이는 중이다. Skills, Routines, Auto 모드에 이어 이번엔 오케스트레이션 자체가 자동화됐다. 따라가는 것만으로도 벅차지만, 한 번쯤 직접 /deep-research부터 돌려보는 게 감을 잡는 가장 빠른 길이다.

참고 자료