클로드 매니지드 에이전트, 동적 워크플로 공개

앤스로픽이 기업용 에이전트 서비스 클로드 매니지드 에이전트(Claude Managed Agents)에 동적 워크플로(dynamic workflows)를 공개 베타로 열었다. 회사 개발자 계정 @ClaudeDevs는 10월 9일 X에 "가장 야심 찬 작업을 위해 만든 새로운 유형의 멀티에이전트 오케스트레이션"이라고 소개했다. 주 에이전트가 계획을 프로그램으로 쓰고, 그 계획이 여러 에이전트를 단계별로 돌린 뒤 결과를 마지막에 합치는 방식이다. 게시물은 하루가 안 돼 조회 36만 회를 넘겼다.

핵심은 누가 일을 지휘하느냐다. 앤스로픽은 플랫폼 문서에서 "워크플로는 에이전트가 여러 에이전트를 돌리고 그들이 돌려준 것을 합치기 위해 쓰는 프로그램"이라고 정의했다. 기존 서브에이전트 방식에서는 주 에이전트가 한 턴씩 일을 나눠 주고 보고서를 직접 읽었다. 동적 워크플로에서는 에이전트가 쓴 프로그램이 다음에 어떤 에이전트를 돌릴지 정하고 그 에이전트에게 줄 프롬프트까지 쓴다. 각 에이전트의 결과는 주 에이전트가 아니라 프로그램으로 돌아간다. 서버가 그 프로그램을 백그라운드에서 하나의 워크플로 런(workflow run)으로 실행하는 동안 주 에이전트는 사용자와 대화를 이어 가거나 턴을 끝낼 수 있다.

런은 단계(phase)와 에이전트 스레드로 나뉜다. 단계는 「계약서 읽기」 같은 이름이 붙은 작업 구간이고, 각 단계 안에서 프로그램이 여러 에이전트를 동시에 띄운다. 에이전트마다 자기 세션 스레드에서 일하며, 모든 스레드가 세션의 같은 샌드박스 파일을 함께 쓴다. 프로그램은 초안이 검토를 통과할 때까지 수정을 되풀이시키거나 실패한 에이전트를 따로 처리할 수도 있다. 에이전트는 워크플로가 즉석에서 정의하는 인라인 에이전트일 수도, 개발자가 미리 등록한 에이전트일 수도 있다. 인라인 에이전트는 세션 에이전트와 같은 모델을 쓰고, 도구와 MCP 서버는 세션 에이전트가 가진 것 안에서 받는다.

문서가 든 예시는 계약서 300건이다. 사용자가 경영권 변경 조항이 들어간 계약서를 찾아 달라고 하면 에이전트는 「계약서 읽기」와 「결과 대조」 두 단계짜리 런을 시작하고, 런이 끝나면 300건 중 41건에 조항이 있다고 답한다. 메탈이 확인한 58초 분량의 공식 소개 영상도 같은 장면을 보여 준다. 화면 속 에이전트는 계약서 300건을 앞에 두고 워크플로를 쓰고, 서버가 그것을 백그라운드에서 돌린 뒤 합쳐진 결과를 돌려준다.

규모에는 숫자로 된 상한이 있다. 한 런 안에서 동시에 일하는 스레드는 64개까지이고, 한 런이 생애 동안 띄울 수 있는 에이전트는 1000개다. 이를 넘기면 런은 thread_limit_error로 끝난다. 런의 수명은 기본 24시간이며 에이전트가 더 짧게 정할 수 있다. 한 세션에서 동시에 열어 둘 수 있는 런은 기본 10개다. 런을 시작할 수 있는 것은 세션의 주 스레드 에이전트뿐이어서, 런 안의 에이전트가 또 다른 런을 여는 중첩은 막혀 있다.

비용 구조도 문서에 적혀 있다. 런에는 별도 가격이 없고, 런의 에이전트가 쓴 토큰은 세션의 다른 토큰처럼 모델별 요금으로 청구된다. 세션 예산에 도달하면 열린 런이 모두 멈추고, 예산을 올리거나 없애면 다시 돈다. 다만 각 스레드가 이미 보낸 모델 요청은 끝까지 처리되므로 일하는 스레드 수만큼 요청 한 번씩 예산을 넘을 수 있다. 보도에 따르면 매니지드 에이전트의 실행 요금은 실행 상태 기준 세션 시간당 0.08달러이고 웹 검색은 1000회당 10달러다. 런이 completed로 끝났다는 신호도 작업이 통과했다는 뜻은 아니라고 문서는 밝혔다. 실패한 작업은 각 스레드의 이벤트를 읽어야 찾을 수 있다.

같은 이름의 기능은 클로드 코드에 먼저 있었다. 앤스로픽 쿡북에 따르면 클로드 코드의 동적 워크플로에서는 클로드가 자바스크립트 오케스트레이션 스크립트를 써서 Workflow 도구에 넘기고, 로컬 런타임이 최대 16개 에이전트를 동시에 돌리며 한 런을 1000개 에이전트로 제한한다. 쿡북은 투자자 보고서 초안의 주장 10개를 원자료와 대조하는 예제를 2.5분, 3.29달러에 돌렸고, 미묘한 인용 차이를 잡아낸 데 대해 "그 정밀함은 더 똑똑한 모델이 아니라 워크플로의 구조에서 나온다"고 적었다. 이번 공개 베타는 그 방식을 개발자 노트북이 아닌 앤스로픽 서버에서 돌리게 한 것이다.

개발자가 할 일은 에이전트 정의의 multiagent 블록에서 workflows 설정을 켜는 것이다. 보도에 따르면 이 기능은 managed-agents-2026-04-01 베타 헤더와 multiagent_20261001 타입으로 켜지며, 이 타입에서는 워크플로와 서브에이전트가 기본으로 켜져 있다. 런을 언제 시작할지는 여전히 에이전트가 판단하므로, 프롬프트에 어떤 상황에서 런을 쓰라고 적어 둬야 한다. 워크플로 코드 자체는 개발자에게 보이지 않고, 에이전트에게 요청해야 볼 수 있다.

메탈은 앞서 클로드 매니지드 에이전트를 쓰는 창업자 셋의 사용법을 보도한 바 있다. 이번 공개 베타는 한 세션이 부리는 단위를 에이전트 몇 명에서 수백 명으로 넓혔다. 한 대화에 다 담기지 않는 문서 수백 건의 검토를 서버의 프로그램이 나눠 맡고, 사람은 결과와 청구서를 함께 확인하는 구도다. 남는 질문은 1000개 에이전트를 돌린 답이 에이전트 하나의 답보다 그만큼 더 정확한지, 그 차이를 누가 어떻게 재는가다.