Claude Code 워크플로 공개, 1000개 에이전트 상한과 토큰 경고

AI 요약

• 무슨 일: Anthropic이 2026년 5월 28일 Claude Code dynamic workflows 연구 프리뷰를 공개했습니다.
  • Claude가 작업별 JavaScript orchestration script를 쓰고, runtime이 수십-수백 개 subagent를 병렬 실행합니다.
• 숫자: 공식 문서는 16개 동시 agent, run당 1,000개 총 agent 상한을 적었습니다.
  • Anthropic은 Bun의 Zig to Rust port 사례로 기존 test suite 99.8% 통과, 약 75만 줄 Rust, 11일 merge를 제시했습니다.
• 주의점: workflow는 plan usage와 rate limit을 쓰며, Reddit 사용자들은 ultracode의 token burn과 subagent loop를 우려합니다.

Anthropic이 2026년 5월 28일 Claude Opus 4.8 발표와 함께 Claude Code의 dynamic workflows를 연구 프리뷰로 공개했습니다. 발표의 중심 문장은 “Claude가 수십-수백 개 subagent를 병렬로 실행한다”입니다. 개발자 팀이 더 가까이 봐야 할 변화는 agent 수보다 orchestration의 위치입니다. Claude가 대화 turn 안에서 다음 도구 호출을 고르는 방식이 아니라, 작업별 JavaScript script를 만들고 별도 runtime이 그 script를 실행합니다.

공식 블로그는 dynamic workflows를 “한 agent가 한 번에 처리하기 어려운 문제”를 위한 기능으로 설명합니다. 예시는 codebase-wide bug hunt, profiler-guided optimization audit, security audit, framework migration, API deprecation 대응, language port입니다. Anthropic은 Claude Code가 작업을 쪼개고, 독립 agent가 서로 다른 각도에서 조사하고, 다른 agent가 결과를 반박하도록 만든 뒤, 수렴한 결과만 사용자에게 돌려주는 구조라고 적었습니다. 이 설명은 coding assistant가 “응답 생성기”에서 “작업 스케줄러”로 이동하는 장면에 가깝습니다.

Claude Code 문서는 이 기능을 더 기술적으로 정의합니다. Dynamic workflow는 Claude가 작성한 JavaScript script이고, runtime이 conversation과 분리된 환경에서 실행합니다. 중간 결과는 Claude의 context window가 아니라 script 변수에 남습니다. 문서는 subagent, skill, workflow를 비교하면서 subagent는 worker, skill은 instruction, workflow는 runtime이 실행하는 script라고 구분합니다. 반복 가능한 것은 agent 정의나 지침이 아니라 orchestration 자체입니다.

이 차이는 token과 context 문제를 동시에 건드립니다. 기존 subagent 방식에서는 Claude가 turn마다 무엇을 spawn할지 결정하고, 결과가 context로 들어옵니다. Dynamic workflow는 loop, branch, intermediate result를 script가 들고 갑니다. Claude의 context에는 최종 보고서만 크게 들어오도록 설계됩니다. 긴 migration이나 audit에서 context가 중간 로그로 부풀어 오르는 문제를 줄일 수 있지만, 더 많은 agent를 실행하기 때문에 전체 token 사용량은 오히려 커질 수 있습니다.

공식 문서가 적은 숫자는 꽤 구체적입니다. workflow runtime은 동시에 최대 16개 agent를 실행하고, 1회 run의 총 agent 수는 1,000개로 제한됩니다. workflow script 자체는 직접 filesystem이나 shell에 접근하지 않습니다. agent들이 파일을 읽고 쓰며 command를 실행하고, script는 그 agent들을 조율합니다. 이 설계는 “AI가 임의 shell script를 마음대로 실행한다”는 그림과 다릅니다. 그래도 실제 파일 수정과 command 실행은 subagent 권한으로 일어나므로, 프로젝트의 tool allowlist와 permission mode가 운영 경계가 됩니다.

사용 방법도 두 갈래입니다. 한 번만 workflow를 쓰려면 prompt에 workflow라는 단어를 넣습니다. Claude Code가 그 단어를 강조 표시하고, 일반 chat loop 대신 script 작성 모드로 들어갑니다. 세션 전체에서 Claude가 알아서 판단하게 하려면 /effort ultracode를 켭니다. 문서는 ultracode를 xhigh reasoning effort와 자동 workflow orchestration의 결합으로 설명합니다. 한 요청이 code 이해, 변경, 검증을 위한 여러 workflow로 이어질 수 있고, routine 작업으로 돌아가면 /effort high로 낮추라고 권합니다.

Availability는 표면별로 조금 다르게 적혀 있습니다. 발표 글은 Claude Code CLI, Desktop, VS Code extension의 Max, Team, Enterprise plan에서 사용할 수 있고 Enterprise는 admin enable이 필요하다고 설명합니다. 같은 글은 Claude API, Amazon Bedrock, Vertex AI, Microsoft Foundry도 언급합니다. 문서 페이지는 Claude Code v2.1.154 이상, paid plan 전체, Anthropic API, Bedrock, Vertex AI, Microsoft Foundry를 조건으로 적고, Pro에서는 /config의 Dynamic workflows row에서 켠다고 보완합니다. 이 차이는 launch copy와 docs가 각각 다른 audience를 향해 쓴 문장으로 보는 편이 안전합니다.

Anthropic이 제시한 가장 큰 증거는 Bun port 사례입니다. 공식 글에 따르면 Jarred Sumner는 dynamic workflows로 Bun을 Zig에서 Rust로 옮겼고, 기존 test suite의 99.8%가 통과했으며, 약 75만 줄 Rust가 만들어졌고, 첫 commit부터 merge까지 11일이 걸렸습니다. 한 workflow는 Zig codebase의 struct field마다 적절한 Rust lifetime을 mapping했고, 다음 workflow는 각 .zig 파일에 대응하는 .rs 파일을 작성했습니다. Anthropic은 수백 agent가 병렬로 작업했고 파일마다 두 명의 reviewer agent가 붙었다고 설명했습니다.

이 숫자는 강한 headline이지만, 단서도 같이 붙어 있습니다. Anthropic은 해당 Bun port가 아직 production은 아니라고 밝혔습니다. 따라서 이 사례를 “대규모 언어 port 자동화가 완성됐다”로 읽으면 과장입니다. 더 정확한 해석은 codebase-scale migration에서 agent orchestration을 제품 기능으로 포장할 수 있을 만큼 실험이 진전됐다는 쪽입니다. 실제 팀의 판단 기준은 merge 속도보다 failing test, performance regression, unsafe memory behavior, API compatibility를 사람이 어디서 어떻게 확인했는지입니다.

Opus 4.8 발표는 dynamic workflows의 모델 쪽 배경을 제공합니다. Anthropic은 Opus 4.8이 Opus 4.7 대비 coding, agentic skill, reasoning, professional work benchmark에서 개선됐고 같은 regular 가격으로 제공된다고 설명했습니다. API 가격은 regular usage 기준 입력 100만 token당 5달러, 출력 100만 token당 25달러입니다. fast mode는 입력 100만 token당 10달러, 출력 100만 token당 50달러이며, Anthropic은 이전 모델의 fast mode보다 2.5배 빠르고 3분의 1 가격이라고 적었습니다.

모델 발표에서 개발자에게 더 직접적인 항목은 honesty 평가입니다. Anthropic은 Opus 4.8이 자신이 작성한 코드의 결함을 사용자에게 말하지 않고 넘길 가능성이 이전 모델보다 약 4분의 1 수준이라고 설명했습니다. Claude Code dynamic workflows가 결과를 merge하기 전에 여러 agent를 통해 검증한다는 주장과 맞물리는 부분입니다. 긴 agent run에서는 “답을 냈다”보다 “불확실성과 실패 조건을 표시했다”가 더 가치 있는 신호가 됩니다.

Messages API 변경도 agent harness 팀이 볼 만합니다. Anthropic은 Messages API가 이제 messages 배열 안의 system entry를 받는다고 밝혔습니다. 개발자는 prompt cache를 깨거나 user turn을 우회하지 않고도 mid-task instruction을 바꿀 수 있습니다. Anthropic은 예시로 permission, token budget, environment context 업데이트를 들었습니다. dynamic workflows가 Claude Code 제품 기능이라면, 이 API 변경은 자체 agent harness가 runtime 중간에 제약 조건을 바꾸는 통로입니다.

운영 화면도 단순 progress bar가 아닙니다. /workflows view는 각 phase의 agent count, token total, elapsed time을 보여주고, 사용자는 phase와 agent detail로 들어가 prompt, 최근 tool call, result를 확인할 수 있습니다. p로 pause/resume, x로 agent 또는 전체 workflow stop, r로 running agent restart, s로 run script 저장을 할 수 있습니다. 문서는 Desktop app에서도 workflow name, phase list, token usage caution이 담긴 approval card가 나온다고 설명합니다.

권한 모델은 세밀하게 읽어야 합니다. CLI의 per-run prompt는 planned phase를 보여주고 실행, 해당 workflow 재확인 생략, raw script 보기, 취소를 제공합니다. Auto mode에서는 첫 launch만 묻고, ultracode에서는 prompt를 건너뛴다고 문서가 적습니다. Desktop app 문서에는 workflow가 spawn한 subagent가 항상 acceptEdits mode로 실행되고 session의 tool allowlist를 상속한다고 되어 있습니다. file edit는 auto-approved입니다. 긴 workflow를 켜기 전 allowlist와 branch 격리를 확인해야 하는 이유입니다.

비용 문장은 발표와 문서 양쪽에 반복됩니다. 공식 블로그는 dynamic workflows가 일반 Claude Code session보다 “substantially more tokens”를 쓸 수 있으니 작은 범위의 task로 시작하라고 권합니다. 문서는 run이 plan usage와 rate limit에 포함되고, 모든 agent가 script에서 다르게 route하지 않는 한 session model을 쓴다고 설명합니다. 큰 run 전에 /model을 확인하고, strongest model이 필요 없는 stage에는 작은 모델을 쓰라고 task description에 명시하라는 조언도 들어 있습니다.

커뮤니티 반응은 이 비용 문장을 빠르게 확대했습니다. Reddit의 Claude Code와 ClaudeAI 커뮤니티에는 ultracode가 code audit이나 research에서 체감상 큰 점프라는 반응이 있습니다. 반대로 subagent loop가 usage를 빠르게 태웠다는 사례, token black hole이라는 표현, per-agent fuse와 hard iteration cap이 필요하다는 지적도 올라왔습니다. 공식 문서의 1,000 agent cap은 runaway를 완전히 막는 장치라기보다 한 run의 최대 피해 범위를 정하는 상한입니다.

팀 단위 도입에서는 세 가지 질문이 먼저 나옵니다. 첫째, 어떤 작업이 workflow급인지 정해야 합니다. 5개 파일 수정이나 명확한 bug fix는 보통 session이 더 싸고 빠릅니다. 둘째, workflow가 건드릴 branch, test command, package install, network access를 사전에 제한해야 합니다. 셋째, phase별 token total과 agent result를 code review 기록과 연결해야 합니다. “AI가 검증했다”는 문장은 reviewer가 무엇을 봤는지 남지 않으면 감사 자료가 되기 어렵습니다.

제품 경쟁 측면에서는 Claude Code가 agent orchestration을 Claude 제품 표면 안으로 끌어들인 사건입니다. OpenAI Codex, GitHub Copilot coding agent, Google Antigravity도 agent 작업을 실제 repo와 개발 workflow에 붙이고 있습니다. Claude Code dynamic workflows의 차별점은 사용자가 agent team을 직접 설계하기 전에 Claude가 script를 만들고 저장 가능한 command로 남긴다는 점입니다. 반복 review, migration audit, dependency cleanup처럼 같은 조직에서 자주 도는 작업은 workflow script가 팀 자산이 될 수 있습니다.

그만큼 실패 형태도 바뀝니다. 단일 agent의 오답은 diff와 transcript를 보면 됩니다. 수백 agent workflow의 실패는 어느 phase가 task를 잘못 나눴는지, 어떤 reviewer agent가 잘못된 전제를 통과시켰는지, 어떤 command가 loop를 만들었는지 찾아야 합니다. 이때 /workflows의 token total, elapsed time, phase detail은 단순 UI가 아니라 incident timeline이 됩니다. 2026년 coding agent 운영에서 observability는 model log보다 orchestration log에 더 가까워지고 있습니다.

한국 개발자 팀이 지금 할 수 있는 실험은 과하지 않아야 합니다. 예를 들어 auth route 누락 검사, deprecated API inventory, dead code 후보 목록처럼 read-heavy이고 reviewer가 결과를 빠르게 샘플링할 수 있는 작업이 적합합니다. 반대로 production migration, 대규모 자동 rewrite, secret이 필요한 deploy script는 branch, permission, spend limit, rollback plan 없이는 research preview에 맡기기 어렵습니다. Anthropic도 first run에서 plan을 보여주고 token caution을 표시한다고 적었습니다.

Claude Code dynamic workflows는 “에이전트를 많이 띄운다”보다 “계획을 대화 밖 script로 빼낸다”는 변화입니다. 이 설계는 context 병목을 줄이고 반복 가능한 orchestration을 만들 수 있습니다. 동시에 token 예산, agent loop, permission inheritance, workflow script 검토라는 새 운영 항목을 만듭니다. Opus 4.8의 모델 개선보다 이 기능이 더 오래 남을 가능성이 있는 이유는, coding agent 제품의 비교 기준이 답변 품질에서 실행 계획과 검증 기록으로 이동하고 있기 때문입니다.