Claude Code 동적 워크플로우 — 심층 분석

2026-06-05 · 2026-06-05_claude-code-dynamic-workflows.md

#ai-agents #claude-code #multi-agent #orchestration

Claude Code 동적 워크플로우 — 심층 분석

원문: PyTorchKR — Claude Code 동적 워크플로우 공식 블로그: Introducing dynamic workflows | A harness for every task 공식 문서: Orchestrate subagents at scale with dynamic workflows 작성일: 2026-06-05

---

1. 내용 분석 및 요약

기본 정보

  • 발표일: 2026년 5월 28일 (리서치 프리뷰)
  • 최소 버전: Claude Code v2.1.154+
  • 제공 플랫폼: CLI, 데스크톱, VS Code 확장, Claude API, Amazon Bedrock, Google Vertex AI, Microsoft Foundry
  • 요금제: Max, Team, Enterprise (엔터프라이즈는 관리자 활성화 필요)
  • 활성화: 프롬프트에 workflow 포함 또는 /effort ultracode 설정

동적 워크플로우가 무엇인가?

한 줄로 요약하면: Claude가 JavaScript 오케스트레이션 스크립트를 스스로 작성하고 실행하여 수십~수백 개의 서브에이전트를 병렬로 조율하는 시스템입니다.

핵심 차이는 계획이 어디에 저장되느냐입니다.

기존 방식: Claude의 컨텍스트 윈도우 안에 계획이 메모리 형태로 존재. 대화를 계속할수록 계획이 압축되고 왜곡됨.

동적 워크플로우: 계획이 JavaScript 코드로 작성되어 런타임이 실행. 컨텍스트 윈도우 외부에서 오케스트레이션이 이루어지므로 메인 세션은 반응성을 유지하면서 백그라운드에서 에이전트들이 작업함.

세 가지 비교: 서브에이전트 vs 스킬 vs 워크플로우

서브에이전트 — Claude가 턴마다 수동으로 스폰하는 작업자. 한 턴에 몇 개만 가능. 중간 결과는 Claude 컨텍스트에 쌓임. 중단 시 턴 전체 재시작.

스킬 — Claude가 따르는 지침. 서브에이전트와 동일한 스케일 한계.

워크플로우 — 런타임이 실행하는 스크립트. 수십~수백 개 에이전트. 중간 결과는 스크립트 변수에 저장. 중단 시 중단 지점부터 재개. 오케스트레이션 논리 자체가 저장/재사용 가능.

세 가지 핵심 API

agent() — 단일 서브에이전트 생성. 모델(Sonnet/Opus/Haiku), 격리 방식(worktree/remote), 출력 스키마(JSON Schema 검증), 에이전트 타입(reviewer 등)을 지정.

parallel() — 여러 에이전트를 병렬로 실행하고 모두 완료될 때까지 대기하는 배리어(Barrier).

pipeline() — 각 항목이 모든 단계를 독립적으로 통과. 배리어 없이 파이프라인 처리.

6가지 워크플로우 패턴

분류 후 실행 (Classify-and-act): 분류 에이전트가 입력을 평가한 후 적절한 전문 에이전트로 라우팅. 다양한 입력 처리 시 사용.

펼치기→종합 (Fan-out-and-synthesize): 작업을 병렬 조각으로 나누어 동시에 실행한 후 종합. 대규모 소규모 단계 처리에 적합. 컨텍스트 교차 오염 방지.

적대적 검증 (Adversarial verification): 생성 에이전트의 결과를 별도 검증 에이전트가 기준에 따라 비판적으로 검토. 자기 검증 편향(self-preferential bias) 해결.

생성→필터링 (Generate-and-filter): 다량 아이디어 생성 후 기준에 따라 필터링 및 중복 제거. 브레인스토밍 + 품질 관리.

토너먼트 (Tournament): 같은 작업에 대해 여러 에이전트가 경쟁하고, 판정 에이전트가 쌍별 비교로 승자 선정. 1,000개 이상 항목 정렬 시 단일 프롬프트 방식보다 품질 높음.

완료까지 반복 (Loop until done): 정지 조건 충족될 때까지 에이전트 반복 스폰. 범위가 불명확한 디버깅 작업에 적합.

왜 필요한가? — 단일 컨텍스트의 세 가지 실패 모드

Anthropic이 공식 문서에서 지적한 단일 에이전트의 근본적 한계:

에이전트 게으름 (Agentic laziness): 50개 중 35개만 검토하고 "완료"로 보고. 긴 세션일수록 일찍 포기하는 경향.

자기 선호 편향 (Self-preferential bias): 자신의 초기 발견을 검증하라고 하면, 자신의 결과를 선호하는 편향. 독립적인 검증 에이전트가 필요.

목표 이탈 (Goal drift): 긴 대화에서 요약/압축 단계를 거치며 원래 목표의 충실도가 떨어짐.

실행 흐름

  1. 동적 계획: Claude가 프롬프트를 서브태스크로 분해하고 병렬 서브에이전트에 분배
  2. 검증→수렴: 독립적인 에이전트들이 각기 다른 각도에서 문제를 접근하고, 다른 에이전트가 발견을 반증하려 시도. 답이 수렴할 때까지 반복
  3. 지속성: 진행 상황이 계속 저장됨. 중단 시 중단 지점부터 재개 (전체 재시작 아님)
  4. 조정: 오케스트레이션이 대화 외부에서 이루어지므로 작업 크기와 무관하게 계획 유지

실전 사례 — Bun 마이그레이션

배경: Bun은 JavaScript 런타임으로, 원래 Zig 언어로 작성됨. Jarred Sumner가 동적 워크플로우를 사용해 Rust로 포팅.

수행 과정:

  • 1단계: 한 워크플로우가 모든 구조체 필드의 Rust 라이프타임을 매핑
  • 2단계: 수백 개 에이전트가 병렬로 .zig → .rs 포팅. 각 파일마다 2명의 리뷰어 에이전트 동시 배정
  • 3단계: 수정 루프(Fix loop)가 빌드와 테스트를 반복 실행하여 통과할 때까지 자동 수정
  • 4단계: 야간 워크플로우가 불필요한 데이터 복사 정리 및 PR 생성

결과: 약 750,000줄의 Rust 코드, 11일, 기존 테스트 스위트 99.8% 통과

Anthropic 내부 성공 사례

  • Claude Code 토큰 사용량 ~15% 절감 (20+ 최적화 PR)
  • WASM/Rust 모듈(tree-sitter, yoga-layout) → TypeScript 포팅으로 CPU/메모리 2~10x 개선
  • Claude Agent SDK 시작시간 61% 단축
  • 69개 코드 단순화 PR로 10,000+ 줄 삭제
  • regex 기반 bash 정적 분석 → tree-sitter 마이그레이션으로 허위 양성 권한 프롬프트 45% 감소

"/deep-research" 빌트인 워크플로우 — 실제 실행 사례

"무료 MCP 서버" 질문에 대한 실행 결과:

  • 101개 에이전트, 13분 소요, 723회 검색/페이지 읽기
  • 5개 단계:
  1. 분해: 1개 에이전트가 질문을 5가지 관점으로 분할
  2. 병렬 검색: 5개 에이전트가 동시에 웹 검색
  3. 소스 추출: 19개 소스 가져오기, 신뢰도 판단, 검증 가능한 주장 추출
  4. 적대적 검증: 85개 주장 중 상위 25개에 대해 각각 3개 에이전트가 반증 시도. 75개 에이전트가 사실 검증에 전념
  5. 종합: 18개 주장 생존, 7개 주장 즉시 기각. 생존 주장이 7개 최종 발견으로 병합

핵심 통찰: "비용이 산출한 것은 7개의 사실이 아니라, 사용자가 볼 수 없게 된 7개의 잘못된 주장이다." —过时된 통계(2,000개 MCP 서버)가 3,000+개로 교정됨.

제한 사항

  • 동시 최대 16개 에이전트 (저사양 CPU에서는更少)
  • 한 번에 최대 1,000개 에이전트
  • 실행 중 사용자 입력 불가 (에이전트 권한 프롬프트만 일시 정지)
  • 스크립트는 직접 파일 시스템/쉘 접근 불가. 에이전트가 I/O 수행
  • 첫 실행 시 사용자 확인 필요 (Auto 모드면 첫 번째만)

설정 방법

  • settings.json에서 disableWorkflows: true로 비활성화
  • /config > Dynamic workflows로 Pro 플랜에서 활성화
  • 프롬프트에서 "workflow" 키워드 포함 시 자동 트리거
  • /effort ultracode 설정 시 Claude가 자동 판단

---

2. 커뮤니티 반응 (HN 등)

주된 비판 — "Tokenmaxxing"

HN 댓글에서 가장 큰 반응은 "더 빠르다고 더 정확한 건 아니다"라는 회의론입니다.

토큰 소모 vs 품질: 에이전트 수가 늘어난다고 코드가 더 좋아지냐는 의문. "token-maxxing은 들어봤는데 correctness-maxxing은 못 들어봤다"

Slop 부채: LLM이 긴 세션에서 쌓는 "쓰레기 코드"가 에이전트 리뷰를 거칠수록 오히려 악화될 수 있다는 우려. "LLM은 slop 부채를 쌓고, 각 에이전트 패스가 그것을 증폭시킨다"

통제 상실: 사용자가 중간에 교정을 넣을 수 없는 블랙박스 실행. "빠른 토큰 소모 방식보다, 장기 실행 세션을 제어하고 동적으로 수정을 주입할 수 있는 메커니즘이 필요하다"

비용 장벽: 개인 개발자는 priced out 될 것. "Anthropic은 인간을 위한 도구가 아니라 가상 직원을 팔려는 것"

Bun 사례에 대한 냉소 "75만 줄 포팅은 AI 추론의 테스트가 아니라 기계적 리팩토링"이라는 평가가 많았습니다. 구조체 필드 매핑 같은 규칙 기반 작업은 LLM이 비교적 잘하는 영역이지만, 이건 "진짜 복잡한 문제"를 푼 건 아니라는 지적.

긍정적 피드백

  • 컨텍스트 관리: 서브에이전트 각각이 깔끔한 컨텍스트 윈도우를 유지하므로, 큰 작업일수록 최종 결과가 더 좋음
  • 결정적 검증이 핵심: 테스트/린터 같은 "단일 정답" 도구가 있을 때만 워크플로우가 진짜 빛남. "AI 컨센서스가 아닌 테스트 통과가 품질의 척도다"
  • 계획 단계 중요: /plan에서 가정과 엣지케이스를 먼저 표면화한 후 워크플로우 돌리는 게 성공률 높음

---

3. 새로운 시각

에이전트 수 ≠ 지능

100개 에이전트를 돌리는 게 1개 에이전트보다 똑똑한 건 아닙니다. 오히려 "100명의 초보 프로그래머가 동시에 코딩하는 것"과 유사할 수 있습니다. 품질은 오케스트레이션의 검증 단계 설계에 달려 있습니다. 테스트 스위트가 확실한 프로젝트일수록 이 기능의 가치가 높아지고, 반대로 테스트 없는 코드베이스에서는 slop이 기하급수적으로 쌓입니다.

"하니스"의 진짜 의미 — 프롬프트 엔지니어링의 컴파일

동적 워크플로우는 프롬프트를 "실행 가능한 오케스트레이션 코드"로 컴파일하는 것입니다. 기존에 인간이 수동으로 하던 "이건 A 에이전트가 하고, 이건 B가 검증하고, 결과가 안 좋으면 다시"라는 워크플로우를 Claude가 스스로 JS로 작성해서 돌리는 거죠. 이건 프롬프트 엔지니어링의 다음 단계로 볼 수 있습니다 — 자연어 프롬프트 → 실행 계획 → 자동 실행.

에이전트 경제학의 전환점

이 기능이 성숙하면 "에이전트 1개 = $X"에서 "에이전트 N개 = $f(N)"으로 비용 모델이 바뀝니다. Haiku 같은 저렴한 모델을 검증 에이전트로, Opus를 오케스트레이터로 분할하면 비용 효율이 올라갈 수 있지만, 현재는 아직 "모두 Sonnet/Opus로 돌리면 폭주한다"는 보고가 많습니다.

검증의 가치 = 기각된 주장의 수

"/deep-research" 사례에서 가장 중요한 통찰은 "보고서에 나타난 7가지 사실이 아니라, 사용자가 볼 수 없게 된 7가지 잘못된 주장이 진짜 가치"라는 점입니다. 이 관점은 AI 리서치 도구를 평가하는 새로운 기준을 제시합니다 — 정확도가 아니라 오류 차단률이 핵심 지표가 되어야 합니다.

오픈소스 생태계로의 확산

OpenHands SDK에서도 같은 기능을 추가했다고 합니다. "Claude가 하던 것을 오픈소스 에이전트 프레임워크에서도" — 동적 워크플로우 패턴이 업계 표준으로 자리잡기 시작하는 신호입니다.

---

4. 자녀/미래 영향 — 실용적 조언

직업 관점

코드 리뷰어/테스터 역할의 재정의: "적대적 검증" 패턴이 보편화되면, 코드 품질 관리는 인간이 직접 읽는 것에서 "검증 파이프라인을 설계하는 것"으로 바뀝니다. 미래 개발자의 핵심 스킬은 코딩 자체보다 검증 체계 설계가 될 수 있습니다.

주니어 개발자 진입장벽: 75만 줄 마이그레이션 같은 작업이 AI로 가능해지면, "메이닝 작업"을 경력으로 쌓던 주니어 개발자의 성장 경로가 사라질 수 있습니다. 대신 AI 워크플로우를 설계하고 검증하는 역량이 새로운 기초 스킬이 됩니다.

자녀 교육에 적용할 점

비판적 사고가 더 중요해짐: AI가 100개 에이전트로 만든 결과물도 slop일 수 있습니다. "AI가 만들었으니 신뢰할 수 있다"는 사고방식은 위험합니다. 자녀가 AI 생성물을 평가할 때 "어떻게 검증했는가"를 먼저 묻는 습관을 길러주세요.

검증 리터러시: 미래에는 "코드 쓰는 능력"보다 "코드가 맞는지 판단하는 능력"이 더 가치 있습니다. 테스트 작성, 코드 리뷰, 논리적 검증 — 이런 역량을 어린 나이부터 키워야 합니다.

과도한 자동화에 대한 경계: "빠른 것 = 좋은 것"이라는 환상을 깨주세요. 11일에 75만 줄 포팅했더라도, 그 코드의 기술 부채가 얼마나 되는지는 별개 문제입니다. 속도와 품질은 항상 트레이드오프입니다.

실용적 조언

현재 Claude Max 계정이시라면, 워크플로우 기능은 작은 범위에서 먼저 테스트하세요. Anthropic도 그렇게 권고합니다. 테스트 스위트가 없는 프로젝트에서는 이 기능을 쓰기보다, 먼저 테스트를 작성하는 게 더 가치 있는 투자일 수 있습니다. "이 작업에 정말 더 많은 연산이 필요한가?"라는 질문을 먼저 던지세요. 단순 코드 수정은 일반 세션으로도 충분합니다.

관련 노트