안드로피크 Opus 4.8 출시, 새로운 '동적 워크플로우' 도구 포함

Anthropic이 새롭게 공개한 Opus 4.8과 함께 도입된 'Dynamic Workflows' 도구는 단일 에이전트가 다수의 서브에이전트를 결정론적으로 오케스트레이션할 수 있도록 설계된 실행 프레임워크다. 기존 멀티 에이전트 패턴은 메인 모델이 자연어로 서브에이전트를 호출하고 결과를 다시 텍스트로 받아 파싱하는 방식이라 비용·지연·일관성 측면에서 비효율이 컸다. Dynamic Workflows는 이를 JavaScript 기반 스크립트로 추상화해 `agent()`, `parallel()`, `pipeline()`, `phase()` 같은 프리미티브를 제공하며, 각 서브에이전트의 출력은 JSON Schema로 강제 검증되어 구조화된 객체로 반환된다. 특히 `pipeline()`은 단계 간 배리어(barrier) 없이 항목별로 독립적으로 진행되어 가장 느린 항목의 체인이 곧 전체 wall-clock 시간이 되며, 토큰 예산(`budget.remaining()`)에 따라 동적으로 깊이를 조정하는 루프 패턴까지 지원한다.

엔지니어 입장에서 가장 큰 변화는 'LLM 기반 비결정적 오케스트레이션'에서 '코드 기반 결정적 오케스트레이션'으로의 전환이다. 그동안 LangGraph, CrewAI 같은 외부 프레임워크로 직접 구현해야 했던 fan-out/fan-in, judge panel, adversarial verify, loop-until-dry 같은 품질 패턴이 모델 벤더 차원에서 1급 시민으로 제공된다는 점이 핵심이다. 이는 코드 리뷰 자동화, 대규모 마이그레이션, 보안 감사, 리서치 합성처럼 수십~수백 개 서브태스크로 분해되는 작업에서 실질적인 비용 절감과 품질 향상을 가져온다. 워크플로 실행 단위로 토큰 예산이 공유되고 1000 에이전트 캡, 동시성 캡(min(16, cores-2))이 강제되어 runaway 비용을 차단한 점도 운영 관점에서 중요하다.

다만 개발자들이 주의 깊게 봐야 할 함정도 분명하다. 첫째, `parallel()`은 명시적 배리어이므로 단순 flatten/map/filter를 위해 무심코 사용하면 가장 느린 에이전트가 모든 후속 작업을 가로막아 wall-clock을 낭비한다 — 기본값은 항상 `pipeline()`이어야 한다. 둘째, `Date.now()`·`Math.random()`·인자 없는 `new Date()`가 의도적으로 금지되어 있는데, 이는 워크플로 재개(resume) 기능이 캐시 히트 기반으로 동작하기 때문이다. 타임스탬프나 난수가 필요하다면 `args`로 외부 주입하거나 인덱스 기반으로 변주해야 한다. 셋째, `isolation: 'worktree'` 옵션은 200~500ms의 셋업 비용과 디스크 사용을 동반하므로 병렬 파일 수정으로 충돌이 실제로 발생하는 경우에만 켜야 한다.

실무 적용 측면에서는 기존 RAG·에이전트 파이프라인 코드를 점진적으로 Dynamic Workflows로 이식해보는 것을 권장한다. 특히 코드베이스 전반에 걸친 리뷰·리팩토링·테스트 작성처럼 "발견(discovery) → 변환(transform) → 검증(verify)" 구조를 갖는 작업은 즉시 효과를 보기 쉽다. 단, Dynamic Workflows는 사용자 명시적 동의(opt-in)가 필요한 고비용 기능으로 설계되어 있어, 자동 트리거 정책을 사내에 명확히 세우지 않으면 토큰 비용이 폭증할 수 있다. 팀 단위로는 워크플로 스크립트를 Git에 버전 관리하고, `meta.phases`로 진행 상황을 추적하며, `budget.total` 가드로 무한 루프를 방지하는 운영 가이드라인을 먼저 수립하는 것이 안전한 도입 경로다.