대부분의 Claude Code 사용자들은 여전히 워크플로우를 수동으로 작성합니다. 프롬프트를 연결하고, 출력을 복사하여 다음 프롬프트에 붙여넣고, 잘못된 부분을 수정하고, 이를 반복합니다.
10명 중 9명의 빌더는 Dynamic Workflows를 단 한 번도 사용해보지 않았습니다. 불과 2주 전에 출시되었음에도 말이죠.
그들은 하나의 워크플로우로 해결될 작업을 위해 50개의 프롬프트를 작성합니다. 이것은 마이그레이션, 리서치, 정렬, 근본 원인 분석, 트리아지, 평가를 위한 14단계 로드맵이자 Anthropic 자체 엔지니어들이 실제로 사용하는 6가지 패턴입니다.
제 Substack을 팔로우하여 최신 AI 알파 정보를 받아보세요:
Dynamic Workflows는 2026년 5월 28일 Claude Code에 출시되었습니다. 기본 Claude Code 하네스는 코딩용으로 제작되었으며, 대부분의 코딩 작업에 잘 작동합니다. 하지만 하나의 컨텍스트 윈도우로는 한계가 있는 작업 유형들이 있습니다: 장기 실행, 대규모 병렬 처리, 고도로 구조화된 작업, 또는 적대적 작업이 그렇습니다.
이러한 경우, Anthropic은 이전에 자체적으로 맞춤형 하네스를 구축했습니다 (리서치, 코드 리뷰, 에이전트 팀). Dynamic Workflows를 사용하면 Claude가 해당 작업을 위해 JavaScript로 즉석에서 맞춤형 하네스를 작성해줍니다.
14단계. 6가지 패턴. 50개의 프롬프트 대신 하나의 워크플로우.
파트 1 · 멘탈 모델
01. 워크플로우는 Claude가 작성하는 하네스입니다.
기본 Claude Code 하네스는 Claude가 동일한 컨텍스트 윈도우 내에서 계획하고 실행하도록 합니다. 대부분의 코딩 작업에는 훌륭하지만, 장기 실행, 병렬 또는 적대적 작업에서는 한계가 있습니다.
Dynamic Workflow는 Claude가 작업을 위해 자체 맞춤형 하네스를 작성하는 것입니다. 몇 가지 특수 함수를 포함하여 서브 에이전트를 생성하고 조정하는 JavaScript 파일이며, 그들 사이를 흐르는 데이터를 처리하기 위한 표준 JavaScript (Math, JSON, Array)도 포함합니다.
기본 하네스가 제공할 수 없는 세 가지 이점:
- 에이전트별 격리. 각 서브 에이전트는 하나의 집중된 목표를 가진 자체 컨텍스트 윈도우를 얻습니다. 교차 오염이 없습니다.
- 에이전트별 모델 선택. 워크플로우는 각 서브 에이전트가 사용할 모델을 선택합니다 - 어려운 추론에는 Opus, 저렴한 탐색에는 Haiku, 중간에는 Sonnet.
- 에이전트별 격리 수준. Worktree (격리된 git 체크아웃) 또는 remote (체크아웃 없음). 워크플로우가 각 에이전트에 필요한 것을 결정합니다.
Claude에게 직접 요청하거나 ("~하는 워크플로우를 만들어 줘") 트리거 단어인 ultracode를 사용하여 시작할 수 있습니다. 워크플로우가 중단되면 (사용자 작업, 터미널 종료) 세션을 재개할 때 중단된 지점부터 다시 시작됩니다.
02. 워크플로우가 해결하는 3가지 실패 모드.
워크플로우가 적절한 도구인지 알려면 그것이 무엇을 고치는지 알아야 합니다. Claude가 단일 컨텍스트 윈도우에서 복잡한 작업을 오래 수행할수록, 세 가지 특정 실패 모드에 취약해집니다 - Anthropic 출시 문서에 직접 명명된 것들입니다:
- 에이전트 게으름 - Claude가 복잡한 다중 부분 작업을 완료하기 전에 중단하고 부분적인 진행 후 완료되었다고 선언합니다. 보안 검토에서 50개 항목 중 20개를 처리하고 나머지는 "처리됨"이라고 합니다.
- 자기 선호 편향 - Claude가 루브릭에 대해 자신의 결과를 확인하거나 평가하도록 요청받을 때 자신의 결과를 선호합니다. 이해관계가 있는 검증자는 공정한 검증자가 될 수 없습니다.
- 목표 표류 - 특히 압축 후 많은 턴을 거치면서 원래 목표에 대한 충실도가 점진적으로 손실됩니다. 각 요약 단계는 손실이 있습니다. "X를 하지 마세요" 제약 조건은 47번째 턴에서 조용히 사라집니다.
워크플로우는 구조적으로 세 가지를 모두 해결합니다: 각각 고유한 컨텍스트, 집중된 목표, 격리된 상태를 가진 별도의 Claude 인스턴스. 작업이 이러한 패턴 중 하나라도 겪고 있다면, 그것이 워크플로우를 사용해야 할 신호입니다.
03. 정적 vs 동적 워크플로우.
Claude Agent SDK 또는 claude -p를 사용하여 이미 정적 워크플로우를 구축했을 수도 있습니다 - 여러 Claude Code 인스턴스를 함께 조정하는 방식입니다.
- 정적 워크플로우는 일반적입니다: 모든 엣지 케이스를 처리하기 위해 한 번 작성됩니다. 작동하지만 보수적일 수밖에 없습니다.
- Dynamic Workflows는 다릅니다: Claude가 이 작업을 위해 이 워크플로우를 작성합니다. 하네스는 맞춤 제작됩니다. 아래는 동일한 질문을 두 가지 방식으로 처리한 예시입니다:
동적 버전이 승리하는 이유는 검색 단계 때문이 아닙니다 - 둘 다 검색할 수 있습니다.
워크플로우가 컨텍스트에 맞게 스스로를 형성할 수 있기 때문입니다: 청구 코드를 읽고, 각 기능을 실제 새 공급자 문서와 비교하고, 거래량에 따라 가격을 책정하고, 자체적으로 떠오르는 답변에 대해 "마이그레이션하지 말아야 할 이유" 적대적 패스를 실행합니다.
정적 하네스는 코드의 존재를 모르기 때문에 이 작업을 수행할 수 없습니다.
04. 핵심 API. agent(), parallel(), pipeline().
세 가지 함수가 워크플로우의 대부분의 작업을 수행합니다. 이를 알면 Claude가 작성하는 모든 워크플로우를 읽고, 특정 형태를 원할 때 Claude를 유도할 수 있습니다.
parallel()은 장벽입니다: 작업을 분산시킨 후, 모든 작업이 반환될 때까지 기다립니다. pipeline()은 스트리밍입니다: 각 항목이 모든 단계를 독립적으로 통과합니다.
질문에 따라 선택하세요: 다음 작업을 수행하기 전에 모든 결과가 필요한가요? 예 → parallel. 아니요 → pipeline (더 저렴하고, 전체적으로 더 빠름).
05. 분류 후 실행. 작업을 수행하기 전에 라우팅하세요.
분류기 에이전트가 작업 유형을 결정하면, 워크플로우는 답변에 따라 다른 에이전트나 동작으로 라우팅합니다. 또는 분류기가 끝에서 실행되어, 다음에 올 작업을 위해 원시 출력을 버킷으로 정렬합니다.
이 패턴이 빛을 발하는 경우:
- 작업이 이질적입니다 - 다른 하위 유형은 다른 처리가 필요합니다.
- 복잡성이 요구되는 곳에만 비싼 모델을 사용하려고 합니다 (저렴한 모델로 분류한 다음, 필요한 경우에만 Opus로 라우팅).
- 작업의 분해 자체가 사소하지 않으며 모델이 형태를 결정하는 것이 유리합니다.
예시: "인증 모듈이 어떻게 작동하는지 설명해 줘." 분류기 서브 에이전트가 먼저 코드베이스를 읽고 복잡성을 추정한 다음, 실제 설명 작업을 10개 파일 모듈에는 Sonnet으로, 100개 파일 모듈에는 Opus로 라우팅합니다. 작업을 이해한 후 결정된, 작업에 적합한 모델입니다.
06. 분산 후 종합. 많은 작은 단계, 하나의 병합된 결과.
작업을 많은 작은 단계로 나눕니다. 각 단계에서 에이전트를 병렬로 실행합니다. 결과를 하나의 답변으로 종합합니다.
종합 단계는 장벽입니다 - 모든 분산 에이전트를 기다린 후, 구조화된 출력을 병합합니다.
이 패턴이 실제로 지배적인 이유: 단일 컨텍스트 작업의 "너무 많은 것을 한 번에" 실패를 해결합니다. 각 서브 에이전트는 자신의 부분만 봅니다. 오케스트레이터는 50개의 관련 없는 세부 사항에 주의가 산만해지지 않습니다.
각 단계는 자체적인 깨끗한 윈도우의 이점을 얻어 서로 교차 오염되지 않습니다.
다음과 같은 경우에 사용하세요:
- 명확하게 열거 가능한 작업 항목 목록이 있는 경우 (50개 파일, 200개 엔드포인트, 100개 리뷰).
- 각 항목이 독립적인 경우 - 어떤 항목도 다른 항목의 출력을 시작하기 위해 필요로 하지 않습니다.
- 끝에 부분 보고서 더미가 아닌, 하나의 통합된 답변을 원하는 경우.
1// 분산: 파일당 하나의 에이전트. 장벽: 모두 기다림.2const reviews = await parallel(3 files.map(file => () => agent(4 `보안 문제에 대해 ${file} 검토`,5 { model: "haiku", schema: IssueList }6 ))7)89// 종합: 하나의 Opus 에이전트가 모든 것을 병합.10const report = await agent(11 `다음 리뷰를 우선순위가 지정된 하나의 보고서로 병합:\n${JSON.stringify(reviews)}`,12 { model: "opus" }13)
07. 적대적 검증
이것은 자기 선호 편향에 대한 구조적 해결책입니다. 생성된 각 에이전트에 대해, 루브릭에 대해 출력을 적대적으로 검증하는 별도의 생성된 에이전트를 실행합니다. 검증자는 원래 작업을 본 적이 없으므로, 그것을 선호할 수 없습니다.
이 패턴이 가장 중요한 경우:
- 주장 확인 - 보고서의 모든 사실적 진술은 자체 검증자 서브 에이전트를 가지며, 원본 출처와 대조 확인합니다.
- 코드 리뷰 - 작성자 에이전트가 수정 사항을 작성하고, 리뷰어 에이전트 (별도 컨텍스트)가 이를 리뷰합니다. 동일한 Claude가 자신을 판단하지 않습니다.
- 품질 게이트 - 아티팩트가 출시되기 전에, 적대자가 이에 대한 가장 약한 사례를 찾으려고 시도합니다. 적대자가 찾을 수 없다면 출시합니다.
페어링 규칙: 검증자는 루브릭과 아티팩트 만 알아야 하며, 누가 생성했는지는 몰라야 합니다. 그렇지 않으면 프롬프트의 힌트를 통해 자기 선호가 다시 스며들 수 있습니다.
08. 생성 후 필터링.
주제에 대한 여러 아이디어를 생성한 다음, 루브릭 또는 검증을 통해 필터링합니다. 중복을 제거합니다. 가장 높은 품질의 검증된 아이디어만 반환합니다.
이 패턴이 빛을 발하는 곳:
- 브레인스토밍 - 30개의 제품 이름, 그런 다음 검증자가 클리셰, 상표 충돌, 약한 발음을 제거합니다. 3개만 보게 됩니다.
- 가설 생성 - 문제에 대한 5가지 다른 접근 방식, 그런 다음 각각이 제약 조건에 대해 점수가 매겨집니다. 승자는 자격을 갖췄습니다.
- 솔루션 설계 - 문제에 대한 5가지 다른 접근 방식, 그런 다음 각각이 제약 조건에 대해 점수가 매겨집니다. 승자는 자격을 갖췄습니다.
Claude에게 "최고의 답변"을 요청하는 것과 반대입니다. 최고의 답변을 요청하면 Claude가 일찍 결정을 내리게 됩니다. 생성 후 필터링은 모든 옵션이 도전을 받은 후에 Claude가 결정을 내리게 합니다.
09. 토너먼트. 쌍별 비교가 절대 점수보다 낫습니다.
작업을 나누는 대신, 에이전트가 작업에 대해 경쟁하게 합니다. 각각 다른 접근 방식을 사용하여 동일한 작업을 시도하는 N개의 에이전트를 생성한 다음, 하나가 승리할 때까지 쌍별 방식으로 결과를 판단합니다.
비교 판단은 절대 점수보다 더 신뢰할 수 있습니다 - 특히 취향 기반 작업의 경우.
점수별 정렬보다 이것이 더 나은 이유: 하나의 프롬프트에서 1,000개 항목을 정렬하려고 하면 두 가지 측면에서 실패합니다 - 품질이 저하되고 컨텍스트에 맞지 않습니다. 토너먼트는 신선한 에이전트에 걸쳐 브래킷을 분할하며, 각각은 두 개의 항목만 비교합니다.
브래킷 자체는 컨텍스트가 아닌 결정론적 루프 코드에 있습니다. 각 비교는 빠르고, 공정하며, 격리되어 있습니다. 취향 기반 순위에도 동일한 아이디어가 적용됩니다: 디자인 선택, 후보자 선정, 콘텐츠 우선순위 지정.
10. 완료될 때까지 반복.
알 수 없는 양의 작업이 있는 경우, 고정된 횟수의 패스를 실행하는 대신 중지 조건이 충족될 때까지 (새로운 발견 없음, 로그에 더 이상 오류 없음, 이론 검증됨) 에이전트를 생성하는 루프를 실행합니다.
이 패턴은 "실제로 완료될 때까지 계속 진행"에 대한 답변입니다:
- 불안정한 테스트 디버깅 - 재현, 이론 수립, 테스트, 하나의 이론이 유효할 때까지.
- 버그 사냥 - 전체 패스가 0을 반환할 때까지 버그를 계속 찾습니다.
- 패턴 마이닝 - 클러스터링, 규칙 식별, 새로운 클러스터가 나타나지 않을 때까지.
이 패턴을 /goal과 함께 사용하여 엄격한 완료 요구 사항을 설정하고 ("하나의 이론이 작동할 때까지 멈추지 마"), /loop와 함께 사용하여 전체 워크플로우 자체를 정기적인 일정으로 실행하려는 경우 사용합니다.
브래킷과 중지 조건은 코드에 있으며, 활성 반복만 컨텍스트에 유지됩니다.
11. 실제 사용 사례를 위한 패턴 구성. 하나의 워크플로우, 여러 패턴.
6가지 패턴은 거의 단독으로 나타나지 않습니다. 실제 워크플로우는 2-4개를 구성합니다. 아래 매트릭스는 Anthropic 출시 문서의 각 사용 사례와 사용하는 경향이 있는 패턴을 연결합니다:
- 마이그레이션 및 리팩터링. 분산 (워크트리에서 콜사이트/실패 테스트당 하나의 에이전트) → 적대적 검증 (별도 에이전트가 각 수정 사항 검토) → 완료될 때까지 반복. Anthropic이 Bun을 Zig에서 Rust로 다시 작성하는 데 사용한 패턴입니다.
- 심층 리서치 (/deep-research 스킬). 분산 (병렬 웹 검색) → 적대적 검증 (각 주장이 독립적으로 검증됨) → 종합 (하나의 인용된 보고서).
- 초안 심층 검증. 모든 사실적 주장 식별 (하나의 에이전트) → 분산 (주장당 하나의 검증자, 각 에이전트가 출처와 대조 확인) → 메타 검증자 (검증자의 출처가 고품질인지 확인).
- 1,000개 이상의 항목 정렬. 토너먼트 (5-9단계) - 쌍별 비교, 버킷 순위 또는 브래킷. 비교 판단, 절대 점수 절대 사용 금지.
- 메모리 및 규칙 준수. 규칙당 검증자 (분산) → 회의론자 페르소나가 규칙 자체를 검토하여 오탐지 방지.
- 근본 원인 조사. 분리된 증거로부터 이론 생성 (다른 에이전트가 로그, 파일, 데이터 읽음) → 각 이론에 대한 검증자 및 반박자 패널 → 하나가 살아남을 때까지 반복.
- 대규모 트리아지. 분류 후 실행 → 기존 티켓과 중복 제거 → 수정 시도 또는 에스컬레이션. 지속적인 트리아지를 위해 /loop와 함께 사용.
- 탐색 및 취향 (디자인, 명명, UI 선택). 생성 후 필터링 (5-20개 옵션) → 루브릭을 사용한 토너먼트 → 순위 지정 또는 선택.
- 경량 평가. 워크트리에서 후보 실행 → 비교 에이전트가 루브릭에 따라 평가 → 개선 및 재평가. 순위 지정이 아닌 평가를 위한 토너먼트와 동일한 형태.
이것들을 내재화하는 올바른 방법: 현재 작업이 어떤 실패 모드에서 실패하고 있는지 식별한 다음, 이를 구조적으로 방지하는 패턴을 선택하세요.
표류 → 분산. 자기 선호 → 적대적 검증. 개방형 → 완료될 때까지 반복. 점수 매기기 어려움 → 토너먼트.
12. /goal, /loop 및 토큰 예산과 함께 사용.
워크플로우는 비용이 많이 들 수 있습니다. 세 가지 제어 장치가 "멋지지만 비싼" 도구에서 "무인으로 실행하는 도구"로 바꿔줍니다.
- /goal은 엄격한 완료 요구 사항을 설정합니다. 루프 패턴과 함께 사용하세요: "하나의 이론이 작동할 때까지 멈추지 마." /goal이 없으면 워크플로우는 소프트 완료 지점에서 중지됩니다. /goal이 있으면 실제 종료 조건이 충족될 때까지 반복합니다.
- /loop는 전체 워크플로우를 정기적인 일정으로 실행합니다. 지속적으로 실행하려는 워크플로우에 사용하세요 - 트리아지, 주간 리서치 업데이트, 정기 검증.
- 명시적 토큰 예산. 프롬프트에서 Claude에게 알리세요: "10k 토큰을 사용해 줘." 이는 워크플로우 실행에 상한선을 설정합니다. 상한선이 없으면 야심 찬 워크플로우가 예상보다 5-10배 많은 토큰으로 부풀어 오를 수 있습니다.
1> ultracode 이 가정에 대한 빠른 적대적 검토:2 "Postgres로 전환하면 샤드 리밸런싱이 필요 없어집니다."3 5k 토큰 사용. /goal 반례를 찾거나4 세 개의 독립적인 확인을 받을 때까지 멈추지 마.
Claude Code 팀의 직접 인용: "모범 사례는 아직 개발 중입니다. Dynamic Workflows는 종종 더 많은 토큰을 사용하므로, 언제 어떻게 사용할지 신중히 생각하세요." 대부분의 전통적인 코딩 작업에는 5명의 리뷰어 패널이 필요하지 않습니다.
스스로에게 물어보세요: 이 작업이 정말 더 많은 컴퓨팅 파워를 필요로 합니까? 일반 Claude Code 세션이 5분 안에 작업을 완료할 수 있다면 워크플로우가 필요하지 않습니다.
13. 신뢰할 수 없는 입력에는 격리 패턴을 사용하세요.
신뢰할 수 없는 공개 콘텐츠 (지원 티켓, 버그 보고서, 사용자 피드백, 스크랩된 데이터)를 읽는 모든 워크플로우는 해당 콘텐츠에 프롬프트 인젝션이 포함될 수 있다고 가정해야 합니다.
해결책: 격리. 신뢰할 수 없는 콘텐츠를 읽는 에이전트가 높은 권한의 작업을 수행하지 못하도록 차단하세요. 원시 콘텐츠에 노출되지 않은 별도의 에이전트가 작업을 수행합니다.
사용자가 제출한 콘텐츠 (지원 티켓, 버그 보고서, 고객 피드백, 소셜 미디어)를 처리하거나, 공개 웹 페이지를 스크랩하거나, 타사 API의 출력에 대해 실행되는 모든 워크플로우에 적용됩니다.
입력이 귀하 또는 신뢰할 수 있는 팀원이 작성한 것이 아니라면 격리하세요. 30줄의 읽기 전용 리더 에이전트는 거의 비용이 들지 않으며 프롬프트 인젝션 위험의 전체 클래스를 제거합니다.
14. 워크플로우 저장. Skill로 배포.
워크플로우가 작동하면 저장하세요: 워크플로우 메뉴에서 s를 누릅니다. 저장된 워크플로우는 ~/.claude/workflows로 이동합니다. 여기서 두 가지 경로가 있습니다:
- 로컬로 유지 - 자신의 프로젝트에서 재사용합니다.
- Skill로 배포 - JavaScript 파일을 Skill 폴더에 번들로 묶고, SKILL.md에서 참조하면 Skill을 설치하는 모든 사람이 동일한 워크플로우를 실행합니다.
알아두면 유용한 한 가지 실용적인 뉘앙스: 워크플로우를 Skill로 패키징할 때, Claude에게 워크플로우를 그대로 실행할 스크립트가 아닌 템플릿으로 취급하도록 프롬프트하세요.
이렇게 하면 전체 구조를 유지하면서 Claude가 특정 작업에 맞게 워크플로우 형태를 조정할 여지가 생깁니다. 특히 사용 사례별로 유연하게 조정해야 하는 "심층 검증" 또는 "트리아지"와 같은 워크플로우에 유용합니다.
워크플로우에서 토큰을 낭비하는 실수들
- 일반 Claude Code 세션으로 충분할 때 워크플로우를 사용하는 경우. 대부분의 전통적인 코딩 작업에는 5명의 리뷰어 패널이 필요하지 않습니다.
- 토큰 예산이 없는 경우. 야심 찬 워크플로우는 명시적인 상한선 없이 예상보다 5-10배로 부풀어 오릅니다.
- 하나의 에이전트가 작업과 검증을 모두 수행하는 경우. 자기 선호 편향으로 인해 검증자가 작업자를 선호하게 됩니다. 반드시 분리되어야 합니다.
- parallel()과 pipeline()을 상호 교환 가능하게 취급하는 경우. 장벽이 중요합니다 - parallel은 모든 것을 기다리고, pipeline은 스트리밍합니다.
- 루프 패턴에서 /goal을 생략하는 경우. 워크플로우가 첫 번째 소프트 완료 지점에서 일찍 중지됩니다. /goal은 하드 완료를 강제합니다.
- 신뢰할 수 없는 콘텐츠가 행위자에게 도달하도록 방치하는 경우. 사용자가 제출한 것을 처리하기 시작하면 격리는 선택 사항이 아닙니다.
- 절대 점수로 정렬하는 경우. 비교 판단이 더 신뢰할 수 있습니다. 토너먼트를 사용하세요.
- 작동하는 워크플로우를 저장하지 않는 경우. 매주 동일한 형태를 다시 프롬프트합니다. s로 저장하고 Skill로 배포하세요.
