Claude Code의 Dynamic Workflows로 수십~수백 개의 서브 에이전트를 한 번에 실행해 보자

Claude에게 서비스 전체의 버그 조사나, 수백 개의 파일에 걸친 마이그레이션 작업을 부탁했을 때, "대화 하나만으로는 감당하기 어렵네"라고 느낀 적이 없으신가요? Claude가 혼자서 순서대로 처리하는 방식에는 아무래도 "한 번에 볼 수 있는 범위"의 한계가 있습니다. 컨텍스트 윈도우에는 제한이 있고, 조사한 내용이 늘어날수록 처음에 본 내용이 밀려나게 됩니다.

여기에 새로 추가된 것이 이번에 소개해 드릴 **Dynamic Workflows(다이내믹 워크플로우)**입니다. Claude가 작업에 맞춰 오케스트레이션용 스크립트를 그 자리에서 작성하고, 그 스크립트에 따라 수십에서 수백 개의 서브 에이전트를 병렬로 실행하여 큰 업무를 분담해서 처리해 줍니다. 게다가 실행 중에도 세션은 멈추지 않아 우리는 다른 작업을 계속할 수 있습니다.

현재는 research preview(연구 프리뷰) 단계로, Claude Code v2.1.154 이후 버전에서 이용할 수 있습니다. 아직 발전 중인 기능이지만, 개념 자체가 지금까지의 서브 에이전트와는 조금 달라서 흥미로우니 구조부터 차근차근 살펴보겠습니다.

Dynamic Workflows란?

한마디로 말하면, Dynamic Workflows는 **"서브 에이전트를 대규모로 묶기 위한 JavaScript"**입니다.

지금까지도 Claude Code에는 작업을 다른 Claude(서브 에이전트)에게 넘겨서 맡기는 구조가 있었습니다. Dynamic Workflows가 새로운 점은, 그 "어떤 에이전트를, 어떤 순서로, 몇 개나 움직일 것인가"라는 절차 자체를 Claude가 코드로 작성한다는 점에 있습니다.

흐름은 다음과 같습니다.

1. 하고 싶은 일을 말로 전달한다
2. Claude가 해당 작업을 위한 오케스트레이션 스크립트를 작성한다
3. 전용 실행기(런타임)가 그 스크립트를 백그라운드에서 실행하고, 서브 에이전트를 병렬로 구동한다
4. 중간 결과를 대조하고 검증한 뒤, 최종적인 답변만 우리에게 돌아온다

포인트는 절차가 Claude의 머릿속(컨텍스트)이 아니라, 스크립트라는 눈에 보이는 형태로 떨어진다는 것입니다. 스크립트는 읽을 수 있고, 마음에 들면 저장해서 몇 번이고 같은 절차를 반복할 수 있습니다. 중간 과정은 스크립트의 변수 안에 쌓이기 때문에, Claude의 컨텍스트에는 마지막 결론만 돌아옵니다. 그렇기에 대화 하나로는 감당할 수 없는 규모의 작업에 발을 들일 수 있는 것이죠.

다음과 같은 상황에 적합합니다.

• 코드베이스 전체에 걸친 버그 조사
• 수백 개 파일에 달하는 마이그레이션(프레임워크 교체, API 폐지 대응, 언어 포팅 등)
• 여러 정보원을 서로 대조하여 교차 검증하고 싶은 리서치
• 한 번에 결정하기에는 너무 무거운 설계를 여러 각도에서 초안을 잡아 비교하고 싶을 때

서브 에이전트·Skills와의 차이

Claude Code에는 여러 단계의 작업을 수행하는 수단이 이미 몇 가지 있습니다. 서브 에이전트, Skills, 그리고 이번 Workflows입니다. 혼동하기 쉬우므로 "절차(플랜)를 누가 쥐고 있는가"라는 축으로 정리해 보겠습니다.

서브 에이전트나 Skills에서는 오케스트레이터가 Claude 자신입니다. 턴마다 "다음에 무엇을 움직일까"라고 판단하고, 결과는 모두 Claude의 컨텍스트로 돌아옵니다. 이에 반해 Workflows는 루프나 분기, 중간 결과의 유지까지 스크립트 측이 담당합니다. 절차를 코드로 옮김으로써 단순히 에이전트의 수를 늘리는 것뿐만 아니라, 반복해서 사용할 수 있는 품질 패턴을 내장할 수 있다는 것이 장점입니다.

예를 들어, 독립된 여러 에이전트에게 서로의 발견을 비판적으로 리뷰하게 한 뒤 보고하게 하거나, 혹은 하나의 설계를 여러 각도에서 초안을 잡게 하여 비교하는 방식을 사용할 수 있습니다. 일회성 처리보다 결과를 더 신뢰할 수 있게 되는 것이죠.

Agent Teams와의 차이

지금까지 서브 에이전트와 Skills를 비교해 보았는데, "여러 에이전트를 병렬로 묶는다"는 의미에서 워크플로우와 가장 유사한 구조가 하나 더 있습니다. Agent Teams(에이전트 팀)입니다. 평소에 "Agent Team을 조직해서 이 관점별로 조사해 줘"라고 요청하는 분들일수록 워크플로우와 어떻게 다른지 궁금하실 것입니다.

Agent Teams는 리드 역할을 하는 Claude 세션이 여러 "팀원"을 띄우고, 공유 작업 목록과 메시지 교환으로 협업하는 구조입니다. 팀원은 각각 독립된 컨텍스트를 가진 실제 Claude Code 세션으로, 편지함을 통해 서로 직접 메시지를 주고받을 수 있습니다. 또한, 우리가 리드를 거치지 않고 개별 팀원에게 말을 걸어 중간에 방향을 수정할 수도 있습니다. 참고로 Agent Teams는 실험적 기능으로 기본적으로는 비활성화되어 있습니다. CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS를 활성화하면 사용할 수 있습니다(Claude Code v2.1.32 이후).

둘 다 "에이전트를 병렬로 움직인다"는 점은 같지만, 성격은 꽤 다릅니다.

한마디로 말하면, **Agent Teams는 "그 자리에서 구성하는, 대화 가능한 팀", Dynamic Workflows는 "코드로 굳힌, 계속 돌려두는 파이프라인"**입니다.

팀원끼리 가설을 부딪히게 하거나, 우리가 옆에서 "그쪽 말고 이쪽을 봐"라고 참견하고 싶다면 Agent Teams가 적합합니다. 공식적으로도 PR 리뷰를 관점별로 분담하거나, 충돌하는 가설을 세워 서로 반증하며 버그의 진인을 파헤치는 등의 협업적·탐색적 작업이 장점으로 꼽힙니다. 권장되는 팀 규모도 3~5개 정도입니다.

반면, 분담해야 할 작업이 너무 많아 하나하나 지켜볼 수 없을 때, 매번 완전히 똑같은 절차로 돌리고 싶을 때, 결과를 기계적으로 크로스 체크하고 싶을 때는 워크플로우의 차례입니다. 스크립트가 제어권을 쥐기 때문에 실행 중에 말을 걸어 궤도를 수정할 수는 없지만, 그 대신 수십에서 수백 개의 에이전트를 파탄 없이 돌리고, 마음에 드는 절차는 /커맨드로 저장하여 언제든 똑같이 재현할 수 있습니다.

평소 스킬이나 프롬프트에 "Agent Team을 조직해서~"라고 적고 있는 작업을 한번 떠올려 보세요. 그중 매번 같은 순서로 돌리고 싶은 것이나 규모가 커서 계속 붙어 있을 수 없는 것은 워크플로우로 옮겨 스크립트로 저장해 두면 재현성과 확장성 면에서 다루기 쉬워집니다. 반대로 상대와 상담하며 다듬어 가고 싶은 단계의 작업은 지금까지처럼 Agent Teams가 더 편할 것입니다. 두 기능은 서로 대체하는 것이라기보다 작업의 성격에 따라 선택하는 관계라고 보시면 됩니다.

우선 /deep-research로 만져보기

이론은 이 정도로 하고, 실제로 움직여 보는 것이 가장 좋습니다. 빠르게 분위기를 파악하려면 Claude Code에 처음부터 내장된 워크플로우인 /deep-research를 사용하는 것을 추천합니다.

이것은 하나의 질문을 여러 각도에서 웹 검색으로 조사하고, 찾아낸 정보원을 서로 대조하여 교차 검증한 뒤, 출처가 포함된 리포트로 정리해 주는 워크플로우입니다.

/deep-research Node.js의 퍼미션 모델은 v20에서 v22로 무엇이 바뀌었나

실행하면 Claude Code가 "이 워크플로우를 실행해도 좋은지" 확인합니다. Yes를 선택하면 조사가 백그라운드에서 시작됩니다. 현재 세션은 비어 있는 상태이므로 그동안 다른 작업을 진행할 수 있습니다.

중간 과정을 보고 싶다면 /workflows를 실행하세요.

/workflows

실행 중이거나 완료된 워크플로우 목록이 나오므로, 화살표 키로 선택하고 Enter를 누르면 진행 상황 뷰가 열립니다. 각 단계별로 작동 중인 에이전트 수, 소비 토큰량, 경과 시간이 표시되며, 단계 안으로 들어가면 개별 에이전트가 무엇을 조사하고 있는지까지 확인할 수 있습니다.

조사가 끝나면 리포트가 세션으로 돌아옵니다. 각각의 주장이 어떤 정보원에서 왔는지 명시되며, 대조 결과 근거가 부족한 주장은 미리 제외된 상태로 전달됩니다. 참고로 /deep-research는 웹 검색(WebSearch 툴)을 사용할 수 있는 환경이어야 합니다.

자신의 작업을 워크플로우로 만들기

내장 워크플로우를 시도해 보고 감을 잡았다면, 이제 자신의 작업에 적용해 봅시다. 방법은 크게 두 가지가 있습니다.

프롬프트에 "workflow"라고 쓰기

가장 간편한 방법은 프롬프트 어딘가에 **workflow**라는 단어를 넣는 것입니다. 세션 전체 설정을 바꾸지 않고 그 한 번만 워크플로우로 실행할 수 있습니다.

src/routes/ 하위의 모든 API 엔드포인트에 인증 체크 누락이 없는지 workflow로 감사해 줘

이렇게 쓰면 Claude Code가 입력 중인 workflow라는 단어를 하이라이트하고, 턴마다 직접 처리하는 대신 작업을 위한 워크플로우 스크립트를 작성합니다.

참고로 그럴 의도가 없었는데 workflow가 반응했다면 alt+w를 눌러 해당 프롬프트에서는 무시할 수 있습니다. 예를 들어 "워크플로우를 정리하는 이야기"처럼 단어로만 썼을 때 유용합니다.

/effort ultracode로 Claude에게 맡기

또 다른 방법은 ultracode라는 새로운 effort(사고 강도) 레벨을 사용하는 것입니다.

/effort ultracode

ultracode는 xhigh의 추론 강도와 워크플로우 자동 오케스트레이션을 결합한 설정입니다. 이를 활성화하면 직접 요청하지 않아도 Claude가 "이 작업은 워크플로우로 만들 가치가 있는가"를 스스로 판단합니다. 하나의 요청이 여러 워크플로우로 나뉘기도 합니다. 예를 들어 코드를 이해하기 위한 워크플로우, 변경을 가하기 위한 워크플로우, 이를 검증하기 위한 워크플로우와 같은 식입니다.

그만큼 세션 내의 모든 작업에서 사용하는 토큰이 늘어나고 시간도 걸립니다. ultracode는 해당 세션 동안만 유효하며, 새 세션을 시작하면 리셋됩니다. 일반 작업으로 돌아갈 때는 /effort로 평소 레벨로 되돌려 둡시다. 기본값은 많은 모델에서 high이지만, 더 깊은 추론을 원한다면 xhigh를 상용해도 무방합니다(Opus 4.7에서는 아예 xhigh가 기본입니다). 참고로 ultracode는 xhigh를 지원하는 모델에서만 선택할 수 있으며, 지원하지 않는 모델에서는 /effort 메뉴에 나타나지 않습니다.

실행 전 승인과 권한

워크플로우는 많은 에이전트를 구동하기 때문에 갑자기 실행되는 것이 아니라 실행 전에 승인을 요청합니다. CLI에서는 계획된 단계 목록과 함께 다음과 같은 선택지가 표시됩니다.

• Yes, run it — 그대로 실행
• Yes, and don't ask again for <name> in <path> — 실행하고, 이 프로젝트의 이 워크플로우에 대해서는 이후 확인하지 않음
• View raw script — 스크립트 내용을 읽어보고 결정
• No — 취소

Ctrl+G로 스크립트를 에디터에서 열 수 있고, Tab을 누르면 실행 전에 프롬프트를 조정할 수 있습니다. 내용이 궁금할 때는 주저하지 말고 살펴본 뒤 판단하세요.

확인 다이얼로그가 뜨는지 여부는 권한 모드에 따라 달라집니다.

여기서 한 가지 짚고 넘어가야 할 점은 이 다이얼로그가 제어하는 것은 "기동 시의 확인"뿐이라는 점입니다. 워크플로우가 생성하는 서브 에이전트는 현재 세션의 모드와 상관없이 항상 acceptEdits 모드로 작동하며, 설정된 도구 허용 목록을 상속받습니다. 파일 편집은 자동 승인됩니다.

반면, 허용 목록에 없는 셸 커맨드나 웹 페치, MCP 도구는 실행 도중에 확인을 요청할 수 있습니다. 오래 실행되는 워크플로우에서 방해받고 싶지 않다면 에이전트가 필요로 하는 커맨드를 미리 허용 목록에 추가해 두면 원활합니다.

/workflows 뷰에서 진행 상황 보기

앞서 언급했듯이 /workflows 뷰는 워크플로우의 사령탑입니다. 백그라운드에서 진행되는 작업 모습을 여기서 자세히 지켜볼 수 있습니다. 진행 상황 뷰에서 자주 사용하는 키를 정리해 둡니다.

입력창 아래에 뜨는 작업 패널에서도 한 줄 진행 요약을 확인할 수 있습니다. 아래 화살표로 포커스를 옮기고 Enter로 펼치면 자세히 볼 수 있습니다.

워크플로우 저장하고 재사용하기

어떤 실행이 의도대로 작동했다면 그 스크립트를 커맨드로 저장할 수 있습니다. 예를 들어 "브랜치를 딸 때마다 돌리는 리뷰"와 같은 정형 작업이라면 매번 같은 오케스트레이션을 호출할 수 있는 것이죠.

/workflows에서 남겨두고 싶은 실행을 선택하고 s를 누릅니다. 저장 다이얼로그에서는 Tab으로 두 가지 저장 위치를 전환할 수 있습니다.

• .claude/workflows/ (프로젝트 내) — 저장소를 클론한 모든 사람과 공유됨
• ~/.claude/workflows/ (홈 디렉토리) — 모든 프로젝트에서 사용할 수 있지만 나에게만 보임

Enter로 저장하면 이후 세션에서 /<name>으로 호출할 수 있게 되며, / 입력 보완에도 내장 워크플로우와 함께 나타납니다. 팀이 맞추고 싶은 절차는 프로젝트에, 개인용 도구는 홈에 두면 정리하기 쉽습니다. 참고로 프로젝트 워크플로우와 개인 워크플로우의 이름이 같을 경우 프로젝트 측이 우선됩니다.

이 "저장하고 공유할 수 있다"는 성질은 Skills나 Hooks와 마찬가지로 Claude Code를 자신들의 개발 흐름에 녹여내는 데 큰 효과가 있을 것입니다.

구조와 제약

내부 이야기를 조금만 덧붙이겠습니다. 스크립트를 실제로 움직이는 것은 "런타임"이라 불리는 실행기입니다. 평소 대화하는 Claude 본체와는 별개로 뒤에서 스크립트를 진행하는 구조라고 생각하세요. 이 런타임은 우리의 대화와 격리된 환경에서 스크립트를 실행합니다. 중간 결과는 Claude의 컨텍스트가 아니라 스크립트의 변수에 유지되며, 런타임은 각 에이전트의 결과를 일일이 기록합니다. 이 기록 덕분에 멈춰도 동일 세션 내라면 재개할 수 있는 것입니다.

그와 더불어 런타임에는 몇 가지 제약이 있습니다.

멈춘 워크플로우를 재개하면 이미 완료된 에이전트는 캐시된 결과를 반환하고 나머지는 그 자리에서 다시 작동합니다. 단, 재개는 동일한 Claude Code 세션 안에서만 유효합니다. 워크플로우 실행 중에 Claude Code를 종료하면 다음 세션에서는 처음부터 다시 시작해야 한다는 점을 기억해 둡시다.

비용과 모델 이야기

워크플로우는 다수의 에이전트를 구동하기 때문에 대화 속에서 같은 작업을 처리하는 경우보다 한 번의 실행으로 눈에 띄게 많은 토큰을 소비할 수 있습니다. 공식 안내에서도 "강력하지만 비용이 많이 들 수 있다. 토큰을 빠르게 소비하므로 우선 범위를 좁힌 작업부터 감을 잡아보길 바란다"고 명시하고 있습니다.

실행은 다른 세션과 마찬가지로 플랜의 이용량이나 레이트 제한에 포함됩니다. 하지만 /workflows에서 언제든 워크플로우를 중지할 수 있으며, 그 시점까지 완료된 작업은 손실되지 않습니다. "생각보다 너무 많이 돌아가네"라고 느껴지면 중간에 멈추면 됩니다.

모델에 대해서도 한 가지. 워크플로우 내의 각 에이전트는 스크립트가 특정 단계를 다른 모델로 할당하지 않는 한 현재 세션의 모델을 그대로 사용합니다. 따라서,

• 평소 루틴 작업으로 작은 모델을 사용 중인 사람은 큰 실행 전에 /model을 확인한다
• 작업을 전달할 때 "가장 강력한 모델이 필요 없는 단계는 작은 모델을 써줘"라고 덧붙인다

이런 수고로 비용을 어느 정도 조절할 수 있습니다.

처음에는 작게, 예를 들어 디렉토리 하나 하위의 감사 정도부터 시도해서 자신의 프로젝트에서 어느 정도 토큰을 쓰는지 체감해 두는 것이 안전합니다.

워크플로우 끄기

저는 이 기능을 끄고 사용할 일이 아직 없어서 공식 문서의 내용을 바탕으로 정리하겠습니다. 필요 없을 때는 다음과 같은 방법으로 끌 수 있다고 합니다.

자신의 환경에서만 끄려면 다음 중 하나입니다.

• /config에서 Dynamic workflows를 끈다 (세션 간 지속)
• ~/.claude/settings.json에 "disableWorkflows": true를 설정한다 (지속)
• 환경 변수 CLAUDE_CODE_DISABLE_WORKFLOWS=1을 설정한다 (기동 시 로드)

조직 전체에서 비활성화하고 싶은 경우 매니지드 설정에서 "disableWorkflows": true를 지정하거나 Claude Code 관리자 설정 페이지의 토글을 사용하라고 안내되어 있습니다. 비활성화하면 내장 워크플로우 커맨드를 사용할 수 없게 되고 workflow 키워드도 반응하지 않으며 /effort 메뉴에서 ultracode도 사라진다고 합니다.

초기 사용자 사례

마지막으로 이미 Dynamic Workflows를 사용한 사람들의 사례를 공식 블로그 등에서 본 범위 내에서 소개하겠습니다. 제가 직접 테스트한 결과는 아니지만 규모감은 전달될 것입니다.

그중에서도 눈에 띄는 것이 Bun의 제작자인 Jarred Sumner 씨의 케이스입니다. Dynamic Workflows를 사용하여 Bun을 Zig에서 Rust로 이식하고, 약 750,000행의 Rust를 생성한 뒤 기존 테스트 스위트의 99.8%가 통과하는 상태를 11일 만에 만들어냈다고 보고되었습니다. 수천 개 파일에 걸친 언어 포팅 같은 작업도 처음부터 끝까지 완수할 수 있다는 것을 이 사례가 보여줍니다.

그 외에도 기존 정적 분석으로는 다 찾아내지 못했던 데드 코드나 정리할 부분을 찾아내어 유지보수 작업을 진전시켰다는 활용 사례도 공유되고 있습니다. 프레임워크 교체나 API 폐지 대응 등 "에이전트 한 명에게는 너무 크지만 수작업으로 하기에는 고된" 작업과 궁합이 좋아 보입니다.

이용 가능한 플랜에 대해서도 언급하겠습니다. Dynamic Workflows는 모든 유료 플랜에서 사용할 수 있습니다. Max와 Team 플랜에서는 기본으로 활성화되어 있고, Pro에서는 /config의 Dynamic workflows 행에서 켤 수 있습니다. Enterprise에서는 관리자가 매니지드 설정에서 활성화하는 방식입니다. 또한 Anthropic API를 통하거나 Amazon Bedrock, Google Cloud Vertex AI, Microsoft Foundry에서도 이용할 수 있습니다.

요약

Claude Code의 Dynamic Workflows에 대해 구조부터 사용법, 비용 고려 사항까지 살펴보았습니다. 요점을 정리해 보겠습니다.

• Dynamic Workflows는 Claude가 그 자리에서 작성하는 오케스트레이션 스크립트로, 런타임이 수십~수백 개의 서브 에이전트를 병렬로 묶습니다. research preview로서 v2.1.154 이후 버전에서 사용할 수 있습니다
• 서브 에이전트나 Skills가 "Claude가 절차를 쥐는 것"인 반면, Workflows는 절차를 코드로 옮기는 것이 본질입니다. 중간 결과는 스크립트 변수에 쌓이고 Claude 컨텍스트에는 결론만 돌아옵니다
• 같은 "병렬 에이전트 구동" 동료라도 대화하며 진행하는 Agent Teams와 절차를 코드로 굳혀 돌리는 Workflows는 성격이 다릅니다. 상담·탐색이라면 전자, 규모와 재현성이라면 후자가 적합합니다
• 우선 내장된 **/deep-research**로 감을 잡고, 자신의 작업은 프롬프트에 workflow라고 쓰거나 **/effort ultracode**로 Claude에게 판단을 맡기는 두 가지 방법으로 시작할 수 있습니다
• /workflows 뷰에서 진행 상황 확인·일시 정지·중지·저장을 할 수 있으며, 마음에 드는 실행은 /<name> 커맨드로 저장하여 재사용할 수 있습니다
• 다수의 에이전트를 구동하므로 토큰 소비가 늘어나는 경향이 있습니다. 작은 범위부터 시도하고 필요에 따라 모델을 구분해서 사용하는 것이 안전합니다

"대화 하나로는 감당할 수 없는 크기"의 일을 어떻게 맡길 것인가는 에이전트를 실무에 도입할 때 피할 수 없는 주제입니다. Dynamic Workflows는 거기에 "절차 자체를 코드로 만들어 읽을 수 있고, 재실행 가능하며, 병렬로 돌릴 수 있는 형태"라는 답을 제시해 주었습니다. 아직 research preview 단계이긴 하지만, 우선 범위를 좁힌 감사나 리서치부터 가볍게 시작해 보시는 건 어떨까요?

참고 링크

• Orchestrate subagents at scale with dynamic workflows - Claude Code 공식 문서
• Introducing dynamic workflows in Claude Code - Anthropic 공식 블로그