동적 워크플로우(Dynamic Workflows) 소개
Anthropic이 Claude Code에 동적 워크플로우(Dynamic Workflows) 를 도입했습니다. 핵심 아이디어는 간단합니다. 지금까지는 사람이 미리 짜둔 고정된 절차나 단일 에이전트의 한 번의 시도에 의존했다면, 이제는 Claude가 주어진 작업에 맞춰 오케스트레이션 스크립트를 그 자리에서 직접 작성하고, 그 스크립트가 수십에서 수백 개의 서브에이전트를 한 세션 안에서 병렬로 실행하는 방식입니다. 각 서브에이전트의 결과는 사용자에게 도달하기 전에 다른 에이전트가 검증합니다.
어떤 문제는 단일 에이전트가 한 번에 처리하기에는 너무 큽니다. 특히 복잡하고 오래된 레거시 코드베이스에서 서비스 전체를 훑는 버그 헌트, 수백 개 파일을 건드리는 마이그레이션, 또는 커밋 전에 모든 각도에서 스트레스 테스트하고 싶은 계획 같은 작업이 그렇습니다. 동적 워크플로우는 이런 작업을 사람의 개입 최소화하면서 처음부터 끝까지(end-to-end) 수행하는 것을 목표로 합니다. Anthropic은 "분기 단위로 계획하던 작업이 이제 며칠 만에 끝난다" 고 표현합니다.
이 글은 Anthropic이 발표한 두 편의 글, 동적 워크플로우를 소개하는 발표글과 Claude Code 팀의 Thariq Shihipar 및 Sid Bidasaria가 작성한 실전 활용 가이드 "A harness for every task" 를 함께 정리한 것입니다. 기능이 무엇인지뿐 아니라, 왜 이런 구조가 필요했는지, 그리고 어떤 패턴 으로 활용할 수 있는지까지 다룹니다. 동적 워크플로우는 현재 Max, Team, Enterprise(관리자 활성화 시) 요금제의 Claude Code CLI, 데스크톱 앱, VS Code 확장에서 리서치 프리뷰로 제공되며, Claude API, Amazon Bedrock, Vertex AI, Microsoft Foundry에서도 사용할 수 있습니다.
한 가지 유의할 점이 있습니다. 동적 워크플로우는 일반적인 Claude Code 세션보다 상당히 많은 토큰을 소비합니다. 따라서 처음에는 범위가 좁은(scoped) 작업으로 시작해 자신의 작업에서 사용량 감을 잡는 것을 권장합니다. 워크플로우가 처음 트리거될 때 Claude Code는 무엇이 실행될지 보여주고 확인을 요청하며, 조직 관리자는 관리형 설정(managed settings)으로 워크플로우를 비활성화할 수도 있습니다.
Claude가 직접 하니스를 짜는 이유: 단일 컨텍스트의 한계
이 기능을 이해하려면 먼저 하니스(harness) 라는 개념을 짚어야 합니다. 하니스란 모델을 감싸서 도구 호출, 컨텍스트 관리, 작업 흐름을 조율하는 골격을 뜻합니다. 기본 Claude Code 하니스는 코딩에 맞춰 설계되어 있고, 많은 작업이 결국 코딩 작업과 닮아 있기 때문에 폭넓게 쓸모가 있습니다. 그러나 Research, 보안 분석, 에이전트 팀(Agent Teams), 코드 리뷰(Code Review)처럼 최고 성능을 내려면 Claude Code 위에 별도의 맞춤형 하니스를 따로 구축해야 했던 작업 부류가 분명히 존재했습니다.
기본 하니스에 작업을 맡기면, Claude는 계획과 실행을 같은 컨텍스트 윈도우 안에서 동시에 처리해야 합니다. 평범한 코딩 작업에서는 이 방식이 매우 효과적이지만, 길게 이어지거나, 대규모로 병렬화해야 하거나, 고도로 구조화되었거나, 적대적 검증이 필요한 작업에서는 한계를 드러냅니다. Claude가 복잡한 작업을 하나의 컨텍스트 윈도우 안에서 오래 붙들고 있을수록 다음 세 가지 실패 양상에 취약해지기 때문입니다.
- 에이전트적 게으름(Agentic Laziness): 복잡하고 여러 부분으로 나뉜 작업에서 일부만 처리한 뒤 작업을 다 끝냈다고 선언하고 멈춰버리는 경향입니다. 예를 들어 보안 리뷰 항목 50개 중 35개만 처리하고 완료를 선언하는 식입니다.
- 자기 선호 편향(Self-preferential Bias): 자신의 결과나 발견을 다른 것보다 선호하는 경향입니다. 특히 자기 결과를 어떤 기준(rubric)에 비추어 검증하거나 판정하라고 요청받았을 때 두드러집니다.
- 목표 표류(Goal Drift): 여러 턴에 걸쳐 원래 목표에 대한 충실도가 점진적으로 흐려지는 현상입니다. 특히 컨텍스트 압축(compaction) 이후에 심해집니다. 요약 단계는 본질적으로 손실을 동반하므로, 예외 처리 요구사항이나 "X는 하지 말 것" 같은 제약이 사라지기 쉽습니다.
워크플로우를 만들면 이런 문제들을 구조적으로 완화할 수 있습니다. 각자 독립된 컨텍스트 윈도우와 좁고 고립된 목표를 가진 별개의 Claude 서브에이전트 들에게 작업을 나누어 조율하기 때문입니다. 조율(coordination) 자체가 대화 바깥에서 일어나므로, 작업이 아무리 커져도 계획이 궤도를 벗어나지 않습니다.
정적 워크플로우와 동적 워크플로우의 차이
이전에도 Claude Agent SDK나 claude -p 를 사용해 여러 Claude Code 인스턴스를 묶는 정적 워크플로우(static workflow) 를 만들 수 있었습니다. 그러나 정적 워크플로우는 모든 엣지 케이스에 대응해야 하므로 대체로 더 일반적이고 범용적으로 작성됩니다. 반면 Claude Opus 4.8과 동적 워크플로우에서는 Claude가 충분히 똑똑해져서, 사용자의 구체적인 사용 사례에 꼭 맞는 맞춤형 하니스를 직접 작성합니다.
아래 그림은 "결제 서비스를 새 공급자로 옮겨야 할까?" 라는 같은 질문을 두 방식이 어떻게 다르게 처리하는지 보여줍니다. 정적 하니스는 "웹 검색 5개로 변환 → 상위 결과 가져오기 → 검증 → 요약" 이라는 범용 절차를 거쳐 "일반적인 리서치 보고서" 를 내놓습니다. 반면 동적 워크플로우는 우리 빌링 코드를 직접 읽고, 각 기능을 새 공급자의 문서와 대조하고, 우리 거래량 기준으로 가격을 매긴 다음, "이전을 반대하는 가장 강력한 논거" 를 펼치는 악마의 변호인(devil's advocate) 에이전트까지 거쳐 "구체적인 권고안" 을 도출합니다.
동작 원리: agent, parallel, pipeline 함수
동적 워크플로우는 서브에이전트를 생성하고 조율하는 몇 가지 특수 함수를 갖춘 자바스크립트(JavaScript) 파일을 실행하는 방식으로 동작합니다. Claude는 사용자의 프롬프트를 바탕으로 즉석에서 계획을 세우고, 작업을 하위 작업으로 쪼갠 뒤, 병렬로 실행되는 서브에이전트(sub-agents)들에게 일을 펼쳐(fan-out) 보냅니다.
가장 기본이 되는 함수는 agent() 입니다. 프롬프트를 받아 서브에이전트 하나를 띄우고, 옵션으로 출력 스키마(JSON Schema), 사용할 모델, 격리(isolation) 방식, 서브에이전트 유형을 지정할 수 있습니다. 특히 동적 워크플로우가 어떤 모델을 쓸지, 서브에이전트를 자체 워크트리(worktree)에서 격리 실행할지 를 스스로 결정할 수 있다는 점이 중요합니다. Claude가 작업에 필요한 지능 수준과 격리 정도를 직접 고를 수 있다는 뜻입니다.
// A single subagent with a schema, model, isolation, and custom agent type
const bugs = await agent(
"audit auth.ts",
{
schema: BugList, // JSON Schema → validated JSON output
model: "haiku", // opus / sonnet / haiku. Omit = inherit.
isolation: "worktree", // "worktree" (checkout) or "remote"
agentType: "reviewer", // custom / built-in subagent
})
여러 작업을 한꺼번에 돌릴 때는 parallel() 과 pipeline() 을 조합합니다. parallel() 은 여러 작업을 동시에 펼치고 모두 끝날 때까지 기다리는 배리어(barrier) 역할을 합니다. 반면 pipeline() 은 각 항목이 모든 단계를 독립적으로 흘러가게 하며 배리어가 없어, 한 항목이 3단계를 지나는 동안 다른 항목은 아직 1단계에 있을 수 있습니다.
// parallel — fan out, run at once. Barrier: waits for all.
const all = await parallel(
files.map(f =>
() => agent(f)))
// pipeline — each item streams through every stage. No barrier.
await pipeline(items,
x => agent(draft(x)),
d => agent(check(d)))
동적 워크플로우는 JSON, Math, Array 같은 표준 자바스크립트 함수도 그대로 쓸 수 있어 데이터를 가공하기에 편리합니다. 또한 워크플로우가 사용자의 행동이나 터미널 종료로 중단되더라도, 세션을 재개하면 진행 상황이 저장된 지점부터 이어서 실행됩니다. 아래 진행 상황 화면은 실제로 다이어그램 도구 Excalidraw를 React에서 Solid로 포팅하는 워크플로우의 실행 모습으로, 단계별 진척도와 각 에이전트가 어떤 모델로 몇 개의 도구를 호출하며 토큰을 얼마나 썼는지를 실시간으로 보여줍니다.
자주 쓰이는 여섯 가지 워크플로우 패턴
Claude는 워크플로우를 만들 때 아래 여섯 가지 패턴을 단독으로, 또는 서로 조합해서 사용합니다. 이 패턴들을 머릿속에 그려두면 동적 워크플로우를 언제 써야 할지, 그리고 프롬프트로 Claude를 어떻게 유도할지 감을 잡는 데 도움이 됩니다.
- 분류 후 실행(Classify-and-Act): 분류기(classifier) 에이전트가 작업 유형을 판단하고, 그 유형에 따라 서로 다른 에이전트나 동작으로 라우팅합니다. 마지막 단계에서 분류기로 출력 형태를 결정할 수도 있습니다.
- 펼치고 종합(Fan-out-and-Synthesize): 작업을 여러 개의 작은 단계로 쪼개 각 단계에 에이전트를 하나씩 돌린 뒤 결과를 종합합니다. 작은 단계가 아주 많거나, 각 단계가 서로 간섭하거나 교차 오염되지 않도록 자체 컨텍스트가 필요할 때 특히 유용합니다. 종합(synthesize) 단계는 배리어로서, 펼쳐진 모든 에이전트를 기다린 뒤 구조화된 출력들을 하나의 결과로 병합합니다.
- 적대적 검증(Adversarial Verification): 생성된 각 에이전트마다 별도의 에이전트를 띄워, 그 출력을 기준이나 조건에 비추어 적대적으로 반증(refute)하게 합니다. 자기 선호 편향을 구조적으로 차단하는 장치입니다.
- 생성 후 필터링(Generate-and-Filter): 한 주제에 대해 여러 아이디어를 생성한 뒤, 기준이나 검증으로 걸러내고 중복을 제거해 가장 품질 높고 검증된 것만 반환합니다.
- 토너먼트(Tournament): 일을 나누는 대신 에이전트들이 경쟁하게 합니다. N개의 에이전트가 서로 다른 접근으로 같은 작업을 시도하고, 판정 에이전트가 그 결과들을 쌍별(pairwise)로 비교하며 승자가 나올 때까지 진행합니다.
- 완료까지 반복(Loop until Done): 작업량을 미리 알 수 없을 때, 정해진 횟수만큼 도는 대신 정지 조건(새 발견 없음, 로그에 더 이상의 오류 없음 등)이 충족될 때까지 에이전트 생성을 반복합니다.
실전 활용 사례
동적 워크플로우의 진짜 가치는 다양한 작업에 창의적으로 적용할 때 드러납니다. Anthropic은 오히려 비기술적인 작업에서 워크플로우가 더 유용한 경우도 있다고 말합니다. 실제로 얼리 액세스 단계에서 Klarna와 CyberAgent 같은 팀들이 다음과 같은 반응을 남겼습니다.
"동적 워크플로우는 대규모 코드베이스 전반의 발견 및 리뷰 작업에 특히 유용했습니다. 기존 정적 분석이 놓친 데드 코드를 식별하고 정리 기회를 찾아내는 데 강력한 결과를 보았으며, 덕분에 엔지니어들이 유지보수와 리팩토링 작업에서 더 빠르게 움직일 수 있었습니다."
"Dynamic workflows have been especially valuable for discovery and review tasks across large codebases." — Alessio Vallero, Klarna 시니어 엔지니어링 매니저
"동적 워크플로우는 단일 서브에이전트를 띄우는 것과 완전한 에이전트 팀을 구축하는 것 사이의 간극을 메웁니다. 계획에서 구현까지 자연스럽게 이어져서, 가시성을 잃지 않으면서도 더 긴 실행을 믿고 맡길 수 있습니다."
"Plan to implementation just flows, so we can trust longer runs without losing visibility." — Ken Takao, CyberAgent 리드 시스템 엔지니어
아래는 대표적인 활용 사례들입니다.
마이그레이션과 리팩토링: Bun을 Zig에서 Rust로
가장 인상적인 사례는 자바스크립트 런타임 Bun을 Zig에서 Rust로 포팅한 작업입니다. Jarred Sumner는 동적 워크플로우를 사용해 기존 테스트 스위트의 99.8%가 통과하는 상태로, 약 75만 줄의 Rust 코드 를, 첫 커밋부터 머지까지 단 11일 만에 옮겼습니다. 한 워크플로우는 Zig 코드베이스의 모든 구조체 필드에 대해 알맞은 Rust 라이프타임(lifetime)을 매핑했습니다. 그 다음 워크플로우는 모든 .rs 파일을 대응하는 .zig 파일의 동작이 동일한 포팅본으로 작성했는데, 수백 개의 에이전트가 병렬로 일하면서 각 파일마다 리뷰어 두 명이 붙었습니다. 이어 빌드와 테스트 스위트가 모두 깨끗하게 통과할 때까지 수정 루프(fix loop)가 돌았고, 포팅이 끝난 뒤에는 야간 워크플로우가 불필요한 데이터 복사를 정리하며 각 건마다 최종 리뷰용 PR을 열었습니다.
핵심은 작업을 콜사이트(callsite), 실패하는 테스트, 모듈처럼 반복 처리할 수 있는 일련의 단계로 쪼개는 것 입니다. 각 수정마다 워크트리에서 서브에이전트를 띄워 고치게 하고, 다른 에이전트가 적대적으로 리뷰한 뒤 병합합니다. 머신의 리소스를 소진하지 않으면서 최대한 병렬화하려면, 자원을 많이 쓰는 명령은 쓰지 말라고 에이전트에 일러두는 것이 좋습니다. (자세한 과정은 본문 하단의 Jarred Sumner X 스레드에서 확인할 수 있습니다.)
딥 리서치와 깊은 검증
Anthropic은 동적 워크플로우를 사용하는 딥 리서치 스킬(/deep-research)을 Claude Code 안에 공개했습니다. 이 스킬은 웹 검색을 펼치고, 소스를 가져오고, 그 주장들을 적대적으로 검증한 뒤, 인용이 달린 보고서를 종합합니다. 이런 리서치는 웹 검색에만 국한되지 않습니다. Slack의 맥락에서 상태 보고서를 만들거나, 코드베이스를 깊이 탐색해 어떤 기능이 어떻게 동작하는지 조사하는 데에도 같은 구조를 쓸 수 있습니다.
반대 방향의 활용도 있습니다. 어떤 보고서가 참조하는 모든 사실 주장(factual claim)을 점검하고 출처를 대조 하고 싶다면, 한 에이전트가 모든 사실 주장을 식별하게 한 뒤, 각 주장마다 서브에이전트를 띄워 상세히 검증하는 워크플로우를 만들 수 있습니다. 출처의 품질이 충분히 높은지 확인하는 별도의 검증 에이전트를 더 붙일 수도 있습니다.
정성적 정렬(Sorting)
Claude가 잘 평가할 수 있다고 믿는 어떤 정성적 척도로 항목들을 정렬하고 싶을 때가 있습니다. 예를 들어 버그 심각도 순으로 지원 티켓을 정렬하는 경우입니다. 그러나 1,000개가 넘는 행을 하나의 프롬프트에서 정렬하려 하면 품질이 떨어지고 컨텍스트에도 들어가지 않습니다. 대신 토너먼트, 즉 쌍별 비교 에이전트의 파이프라인을 돌립니다. (절대 점수 매기기보다 비교 판단이 더 신뢰할 만하기 때문입니다.) 또는 병렬로 버킷별 순위를 매긴 뒤 병합합니다. 각 비교가 자체 에이전트이므로, 결정론적 루프가 대진표를 붙들고 있고 컨텍스트에는 실행 순서만 남습니다.
메모리와 규칙 준수
Claude가 CLAUDE.md 에 넣어두어도 자꾸 놓치거나 어려워하는 규칙 집합이 있다면, 규칙 하나당 검증 에이전트 하나 가 점검하는 워크플로우를 만들 수 있습니다. 다만 거짓 양성(false positive)이 너무 많아지지 않도록, 규칙들이 타당한지 다시 살펴보는 회의주의자(skeptic) 페르소나 서브에이전트를 두는 것이 좋습니다. 아래 그림에서는 diff를 다섯 개의 규칙 검증 에이전트가 각자 점검해 위반 후보에 깃발을 꽂고, 회의주의자 에이전트가 각 깃발을 다시 읽어 "진짜 위반인가, 거짓 양성인가" 를 판정한 뒤 확정된 위반만 남깁니다.
반대 방향도 가능합니다. 최근 세션과 코드 리뷰 코멘트에서 자신이 반복하는 교정 사항을 캐내고, 병렬 에이전트로 군집화한 뒤, 각 후보를 적대적으로 검증하고(이 규칙이 실제 실수를 막았을까?), 살아남은 것들을 CLAUDE.md 로 정제해 넣는 식입니다.
근본 원인 조사(Root-cause Investigation)
디버깅은 여러 독립적인 가설을 세우고 각각을 검증할 때 가장 잘 풀립니다. 하지만 하나의 컨텍스트 윈도우만 쓰면 Claude는 자기 선호 편향에 빠질 수 있습니다. 워크플로우는 이를 구조적으로 막습니다. 서로 겹치지 않는(disjoint) 증거에서 가설을 세우도록 에이전트를 띄우는 것입니다. 예컨대 로그, 파일, 데이터를 각각 맡는 별도 에이전트를 두고, 각 가설은 검증자와 반증자(refuter) 패널의 심사를 받게 합니다. 이는 코드에만 국한되지 않아 영업(왜 3월에 매출이 떨어졌는가?)이나 데이터 엔지니어링(왜 이 파이프라인이 실패했는가?) 같은 모든 사후 분석(post-mortem)에 적용할 수 있습니다.
대규모 분류(Triaging at Scale)
모든 팀에는 사람이 다 처리할 수 없는 지원 큐, 버그 리포트, 백로그가 있습니다. 분류(triage) 워크플로우는 각 항목을 분류하고, 이미 추적 중인 것과 중복을 제거한 뒤, 수정을 시도하거나 사람에게 에스컬레이션하는 등의 조치를 취합니다. 분류 워크플로우에서 유용한 패턴은 격리(quarantine) 입니다. 신뢰할 수 없는 공개 콘텐츠를 읽는 에이전트가 고권한(high-privilege) 동작을 취하지 못하도록 막고, 그런 동작은 정보를 바탕으로 행동하는 별도의 에이전트가 수행하게 하는 것입니다.
이 격리 구조는 신뢰할 수 없는 입력이 에이전트를 조종해 위험한 동작을 유도하는 프롬프트 인젝션을 방어하는 데에도 직결됩니다. 
신뢰할 수 있는 에이전트 설계와 다층 방어 전략에 관해서는 다음 글을 함께 참고해주세요:
탐색과 취향, 평가(Eval)
워크플로우는 디자인이나 네이밍처럼 취향 에 기반하고 기준(rubric)으로 가다듬을 수 있는 작업을 탐색할 때도 유용합니다. Claude에게 여러 해법을 탐색하게 하고, 리뷰 에이전트에 좋은 해법의 기준을 주는 식입니다. 리뷰 에이전트가 기준을 충족했다고 판단하면 작업이 끝나며, 해법들은 토너먼트로 순서를 매기거나 선택할 수 있습니다. 비슷하게, 워크트리에서 별도 에이전트를 띄워 출력물을 만들고 비교 에이전트로 기준에 비추어 채점하면 특정 작업에 대한 가벼운 평가(eval)도 돌릴 수 있습니다. 예를 들어 직접 만든 스킬을 특정 기준에 맞춰 평가하고 다듬는 데 활용할 수 있습니다.
모델과 지능 라우팅
작업에 맞춰 어떤 모델을 쓸지 결정하는 분류기 에이전트를 만들 수도 있습니다. 많은 도구 호출과 사전 조사가 필요한 작업에서, 실행에 앞서 리서치를 수행해 적합한 모델을 고르게 하는 방식입니다. 예를 들어 "인증 모듈이 어떻게 동작하는지 설명하라" 는 작업에 최적인 모델은 인증 모듈의 파일 수와 코드베이스의 형태에 따라 달라집니다. 분류기 에이전트가 이를 조사한 뒤 예상 복잡도에 따라 Sonnet이나 Opus로 라우팅합니다.
동적 워크플로우를 쓰지 말아야 할 때
워크플로우는 강력하지만 모든 작업에 필요한 것은 아니며, 잘못 쓰면 토큰만 대폭 더 소비할 수 있습니다. Anthropic은 워크플로우를 "지금까지 시도하지 못했던 방식으로 Claude Code를 밀어붙이는" 창의적 도구로 쓰라고 권합니다. 일반적인 코딩 작업이라면 "이 작업에 정말 더 많은 연산이 필요한가?" 를 스스로 물어보는 것이 좋습니다. 예를 들어 대부분의 전통적인 코딩 작업에는 다섯 명의 리뷰어 패널이 필요하지 않습니다. 동적 워크플로우는 토큰을 의미 있게 더 쓰는 만큼, 복잡하고 가치가 높은(high value) 작업에 가장 잘 어울립니다.
워크플로우 작성 및 활용 팁
상세한 프롬프트. 앞서 설명한 구체적인 기법들을 활용한 상세한 프롬프트가 가장 좋은 결과를 만듭니다. 워크플로우는 큰 작업 전용이 아니어서, 모델에게 "빠른 워크플로우(quick workflow)" 를 쓰라고 지시할 수도 있습니다. 예를 들어 어떤 가정에 대한 빠른 적대적 리뷰를 만드는 식입니다.
/goal 및 /loop와의 조합. 분류, 리서치, 검증처럼 반복 가능한 워크플로우는 /loop 와 짝지어 정기적으로 실행하고, /goal 로 확고한 완료 요건을 설정할 수 있습니다.
토큰 사용량 예산. 동적 워크플로우에 명시적인 토큰 사용량 예산(budget)을 설정해 작업이 쓰는 토큰을 제한할 수 있습니다. "10k 토큰을 사용하라" 처럼 프롬프트로 상한을 지정하면 됩니다.
저장과 공유. 워크플로우 메뉴에서 s 키를 눌러 워크플로우를 저장할 수 있습니다. 저장한 파일은 ~/.claude/workflows 에 체크인하거나 스킬로 배포할 수 있습니다.
스킬로 공유하려면 자바스크립트 워크플로우 파일을 스킬 폴더에 넣고 SKILL.md 에서 참조합니다. 유연성을 높이려면, 스킬 안의 워크플로우를 그대로 실행해야 하는 스크립트가 아니라 템플릿 으로 여기도록 Claude에 지시하는 것이 좋습니다.
정리: 새로운 탐색의 출발점
동적 워크플로우의 시작 방법은 두 가지입니다. Claude에게 직접 "워크플로우를 만들어줘" 라고 요청하거나, Claude Code 전용 설정인 ultracode 를 켜는 것입니다. ultracode 는 노력(effort) 메뉴에서 접근할 수 있고, 노력 수준을 xhigh 로 설정하면서 작업 처리에 워크플로우를 쓸지 여부는 Claude가 자동으로 판단하게 합니다. 최상의 경험을 위해서는 동적 워크플로우 사용 시 오토 모드(auto mode)를 켜는 것이 권장됩니다.
Max 또는 Team 요금제이거나 API로 Claude Code를 쓴다면 동적 워크플로우는 기본 활성화되어 있고, Enterprise 요금제는 출시 시점에 기본 비활성화이며 관리자가 설정에서 변경할 수 있습니다. Anthropic은 동적 워크플로우를 정해진 정답이 아니라, Claude로 작업을 해내는 새로운 방법을 탐색하는 출발점 으로 여겨달라고 당부합니다. 이 기능은 아직 리서치 프리뷰 단계이며, 어떻게 가장 잘 쓸 수 있을지는 여전히 발견의 여지가 많이 남아 있습니다.
동적 워크플로우 소개 발표 블로그
A harness for every task: dynamic workflows in Claude Code
동적 워크플로우 공식 문서 및 Bun 포팅 사례
Dynamic Workflows Documentation
Jarred Sumner의 Bun(Zig→Rust) 포팅 X 스레드
더 읽어보기
-
AI 에이전트 프로토콜 개발자 가이드: MCP부터 A2A, UCP, AP2, A2UI, AG-UI까지 (feat. Google)
-
[Deep Research] Model Context Protocol(MCP) 개념 및 이해를 위한 학습 자료
이 글은 GPT 모델로 정리한 글을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 덧글로 알려주시기를 부탁드립니다. 
파이토치 한국 사용자 모임
이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일
로 보내드립니다! (기본은 Weekly지만 Daily로 변경도 가능합니다.)
아래
쪽에 좋아요
를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~ 