Claude Managed Agents 동적 워크플로우: 멀티에이전트가 백그라운드 실행 단위가 됐다

Anthropic이 10월 9일 Claude Platform 릴리스 노트에서 Managed Agents의 동적 워크플로우 베타를 공개했다. 내용만 보면 작은 API 업데이트처럼 보이지만, 에이전트 제품을 만드는 팀에게는 설계 단위가 바뀌는 신호다. 기존에는 개발자가 여러 에이전트를 미리 정의하고, 순서를 코드로 묶고, 중간 결과를 직접 저장했다. 새 기능은 에이전트가 복잡한 작업을 받았을 때 여러 단계의 워크플로우를 작성하고, 서버가 그 실행을 백그라운드 workflow run으로 관리하는 구조다.

예시는 “수백 개 문서 리뷰”처럼 조각이 많은 업무다. 하나의 대화 안에서 모든 문서를 순차 처리하면 컨텍스트가 커지고, 실패 지점을 추적하기 어렵고, 중간 결과가 날아가면 재시작 비용이 커진다. 워크플로우 실행 단위가 생기면 작업을 단계별로 나누고, 여러 에이전트가 병렬 또는 순차로 처리하고, 이벤트 스트림으로 진행 상황을 따라갈 수 있다. 이 변화는 단순 자동화보다 운영 관점에서 더 중요하다.

업데이트의 핵심

릴리스 노트에 따르면 이 기능은 managed-agents-2026-04-01 베타 헤더와 함께 사용할 수 있고, 에이전트의 multiagent 필드에서 워크플로우를 활성화한다. 이후 시스템 프롬프트에서 언제 워크플로우 실행을 시작할지 안내하고, 세션 이벤트 스트림의 workflow_run.* 이벤트로 진행 상황을 추적한다. 세부 API는 베타이므로 바뀔 수 있지만, 방향은 명확하다. 멀티에이전트가 애플리케이션 코드의 보조 로직이 아니라 플랫폼의 실행 모델로 들어가고 있다.

개발자에게 중요한 점은 “에이전트가 알아서 해준다”가 아니다. 오히려 반대다. 실행 단위가 플랫폼으로 올라갈수록 입력 스키마, 중간 산출물, 권한, 실패 정책을 더 명확하게 설계해야 한다. 문서 리뷰 에이전트가 계약서 300개를 처리한다면 어떤 문서를 어떤 기준으로 분류했는지, 어떤 하위 에이전트가 어떤 결론을 냈는지, 사람이 다시 볼 항목은 무엇인지 기록이 남아야 한다.

왜 백그라운드 실행이 중요한가

실무 에이전트는 대화형 챗봇보다 배치 작업에 더 가깝다. PR 50개 리뷰, 고객 피드백 2만 건 분류, 보안 로그 요약, 영업 콜 녹취 분석처럼 입력이 많고 시간이 오래 걸린다. 이런 작업을 웹 요청 하나에 묶으면 타임아웃, 재시도, 부분 실패 문제가 바로 생긴다. 백그라운드 workflow run은 이 문제를 작업 큐와 상태 머신의 형태로 다룰 수 있게 한다.

또한 사용자 경험도 달라진다. 사용자는 “끝날 때까지 기다리는 채팅창”이 아니라 “진행률, 중간 결과, 검토 필요 항목”을 봐야 한다. 에이전트 제품의 UI는 채팅 입력창만으로 충분하지 않다. 작업 목록, 단계별 로그, 사람 승인 대기열, 재실행 버튼이 필요하다. 이번 업데이트는 그런 제품 구조를 공식 플랫폼 기능과 맞추기 쉽게 만든다.

도입 전에 확인할 리스크

첫 번째 리스크는 관측 가능성이다. 여러 에이전트가 나뉘어 실행되면 최종 답변만 보고 품질을 판단할 수 없다. 각 단계의 입력, 출력, 모델, 토큰, 도구 호출, 실패 사유를 기록해야 한다. 특히 개인정보나 영업 비밀이 포함된 문서를 처리한다면 로그에 원문을 남길지, 해시만 남길지, 보존 기간을 어떻게 둘지 정해야 한다.

두 번째는 권한 전파다. 상위 에이전트가 모든 도구 권한을 갖고 하위 작업을 만들면, 작은 분류 작업에도 불필요하게 파일 삭제나 외부 전송 권한이 내려갈 수 있다. 워크플로우 단계마다 필요한 최소 권한을 따로 지정해야 한다. 예를 들어 문서 분류 단계는 읽기만, 요약 단계는 내부 저장만, 외부 티켓 생성 단계는 사람 승인 후 실행하도록 나누는 식이다.

세 번째는 비용 폭주다. 멀티에이전트는 병렬화가 쉬운 만큼 호출 수도 늘어난다. 문서 300개를 5단계로 처리하면 기본적으로 1,500회 이상의 모델 호출이 생길 수 있다. 여기에 재시도와 검증 에이전트까지 붙으면 비용이 급증한다. 따라서 워크플로우 시작 전 예상 호출 수와 최대 비용 한도를 계산해야 한다.

기존 오케스트레이션 코드와의 차이

LangGraph, Temporal, 자체 큐 시스템으로 이미 멀티에이전트를 운영하는 팀이라면 플랫폼 내 동적 워크플로우가 모든 것을 대체하지는 않는다. 오히려 제품 경계가 중요하다. 외부 시스템 트랜잭션, 결제, 배포, 데이터베이스 변경처럼 정확한 상태 관리가 필요한 작업은 기존 워크플로우 엔진이 더 적합할 수 있다. 반면 문서 분석, 리서치, 코드 리뷰처럼 모델 판단과 분할 작업이 중심인 영역은 Managed Agents 안에서 처리하는 편이 빠를 수 있다.

좋은 기준은 “실패했을 때 롤백이 필요한가”다. 롤백이 필요한 작업은 애플리케이션 워크플로우 엔진에 남긴다. 실패해도 중간 결과를 버리고 다시 계산할 수 있는 분석 작업은 에이전트 워크플로우로 넘길 수 있다. 이 경계를 정하지 않으면 에이전트가 데이터 변경까지 과도하게 맡아 운영 사고가 난다.

개발팀이 지금 준비할 것

가장 먼저 해야 할 일은 긴 작업을 목록화하는 것이다. 사내에서 “AI가 해주면 좋지만 너무 오래 걸려서 챗봇에 넣기 애매한 작업”을 찾는다. 문서 리뷰, 정책 비교, 대량 이슈 분류, 고객 문의 원인 분석, 레거시 코드 영향도 분석이 후보가 된다. 그다음 각 작업을 단계로 쪼갠다. 입력 수집, 분류, 상세 분석, 검증, 최종 보고처럼 나눌 수 있어야 워크플로우로 옮길 수 있다.

다음은 결과 스키마를 정한다. 자유형 텍스트만 받으면 후속 단계가 불안정해진다. 각 단계는 JSON 또는 테이블 형태로 필수 필드를 반환하게 해야 한다. 예를 들어 계약서 리뷰라면 문서ID, 조항, 리스크등급, 근거문장, 권장조치, 사람검토필요 같은 필드가 필요하다. 이렇게 해야 UI, 검색, 승인 흐름과 연결된다.

실행 체크리스트

• 긴 작업 후보를 먼저 찾고, 채팅형 답변이 아니라 백그라운드 작업으로 설계한다.
• 각 단계의 입력·출력 스키마를 정하고 자유형 텍스트 의존도를 줄인다.
• workflow_run.* 이벤트를 저장해 진행률, 실패 지점, 재실행 기준을 남긴다.
• 하위 에이전트별 최소 권한을 분리하고 외부 전송·쓰기 작업은 사람 승인 뒤 실행한다.
• 워크플로우 시작 전에 최대 문서 수, 최대 호출 수, 최대 비용을 계산한다.
• 롤백이 필요한 업무는 기존 워크플로우 엔진에 남기고, 분석·분류 중심 작업부터 적용한다.
• 베타 기능이므로 API 변경 가능성을 전제로 추상화 레이어를 하나 두고 직접 결합을 피한다.