Claude Managed Agents의 병렬 실행과 자기 개선 운영 구조

단일 에이전트의 병목을 운영 구조로 푼다

Anthropic이 Code with Claude 2026 컨퍼런스에서 공개한 Claude Managed Agents는 Dreaming, Outcomes, Webhooks를 중심으로 최대 20개의 서브에이전트를 병렬 오케스트레이션하는 프레임워크다. 하나의 에이전트가 모든 컨텍스트를 품고 작업을 순서대로 처리하는 대신, 목표를 나누고 독립적으로 실행한 뒤 결과를 다시 합친다.

이 구조는 병렬 처리만을 위한 것이 아니다. Dreaming은 지난 세션을 복기해 다음 실행에 활용할 기억을 만들고, Outcomes는 결과가 품질 기준을 충족하는지 판정한다. Webhooks는 외부 시스템에서 발생한 이벤트를 실행 트리거로 연결한다. Harvey AI가 프레임워크 도입 후 태스크 완료율을 6배 높인 사례는 이러한 운영 구조가 실제 업무 성과로 이어질 수 있음을 보여 준다.

목표를 DAG로 바꾸고 실행 순서를 정한다

오케스트레이션 계층은 최상위 목표를 받는 오케스트레이터와 실제 작업을 수행하는 서브에이전트 풀로 나뉜다. 오케스트레이터는 목표를 원자적 태스크로 분해하고, 태스크 사이의 의존 관계를 DAG(Directed Acyclic Graph)로 표현한다. 그다음 서로 기다릴 필요가 없는 노드를 찾아 병렬 실행 레이어를 만든다.

에이전트 레지스트리에는 각 에이전트의 역할 설명, 사용할 수 있는 도구, 권한 범위와 실행 제약 조건을 등록한다. 오케스트레이터는 태스크의 요구 사항과 레지스트리를 함께 조회해 작업을 배정한다. 필요한 도구와 권한만 부여하는 최소 권한 원칙은 보안 경계를 분명히 하고, 역할별로 추론 범위를 좁혀 기업 워크플로에 적용할 때의 통제를 가능하게 한다.

병렬 실행 가능 여부는 데이터 독립성, 도구 충돌, 예상 컨텍스트 크기를 기준으로 판단한다. 태스크 A의 결과가 태스크 B의 입력으로 쓰이지 않는다면 두 작업을 동시에 실행할 수 있다. 반대로 같은 파일 시스템, DB 테이블, API 엔드포인트에 쓰기를 수행하는 작업은 충돌을 피하기 위해 순차 실행 큐로 보낸다. 예상 입출력 토큰의 합이 단일 에이전트 컨텍스트 한도를 넘을 것으로 판단되면 작업을 강제로 더 나눈다.

서브에이전트 풀은 정적 풀과 동적 풀로 운영된다. 정적 풀에는 지연에 민감한 요청을 즉시 맡길 수 있도록 소수의 범용 에이전트가 대기한다. 동적 풀은 예상 수요에 맞춰 on-demand 방식으로 스핀업하고, 작업을 마친 뒤 일정 TTL(Time-to-Live)이 지나면 해제된다.

동시에 운용할 수 있는 서브에이전트는 최대 20개다. Anthropic의 실험에서는 이보다 많은 에이전트를 실행할 경우 오케스트레이터가 결과를 집계하는 비용이 병렬화로 얻는 이점을 상쇄하기 시작했다.

⤢✕

부분 실패를 다루는 집계 전략

병렬 파이프라인에서는 일부 서브에이전트만 실패하거나 타임아웃에 도달할 수 있다. 오케스트레이터는 작업 성격에 따라 Fan-out Best-effort, Retry-on-Failure, Critical-path Blocking 가운데 적절한 전략을 선택한다.

Fan-out Best-effort는 완료된 결과만으로 최종 응답을 만들고 실패한 서브태스크를 사용자에게 명시한다. Retry-on-Failure는 실패한 서브에이전트를 즉시 재시작하며, 정해진 재시도 횟수를 넘으면 해당 작업을 Fallback 큐로 이동시킨다. 필수 경로에 놓인 작업에는 Critical-path Blocking을 적용해 그 결과가 도착할 때까지 전체 집계를 보류한다.

실행 슬롯은 동시성 제어와 타임아웃 정책 아래 조율한다. 각 슬롯에는 최대 실행 시간과 재시도 예산을 두고, 타임아웃에 도달한 태스크는 다른 에이전트에 다시 배분할 수 있다. 재실행은 단순한 실패 처리에 그치지 않는다. Outcomes가 품질 임계값 미달을 판정하면 Grader의 평가 피드백을 다음 실행의 컨텍스트로 전달하고, 오케스트레이터가 태스크를 재실행 큐로 보낸다.

각 서브에이전트는 구조화된 출력을 반환한다. 오케스트레이터는 병합 스키마에 따라 이를 통합하고, 같은 필드에 서로 다른 값이 들어오면 신뢰도 점수를 기준으로 우선순위를 정하거나 Outcomes 품질 루프에 충돌 해소를 맡긴다. 집계가 끝나면 실행 요약을 생성해 Dreaming 파이프라인으로 전달한다. 이 기록은 이후 세션의 자기 개선 메모리를 만드는 원천이 된다.

격리된 컨텍스트와 쓰기 충돌 중재

서브에이전트가 같은 상태를 무분별하게 공유하면 한 작업의 정보가 다른 작업에 섞일 수 있다. Claude Managed Agents는 에이전트마다 격리된 컨텍스트 윈도우를 유지하고, 공유할 상태는 명시적인 메시지 패싱으로만 전달한다.

작업을 배정할 때도 전체 대화 기록을 넘기지 않는다. 오케스트레이터는 해당 태스크에 필요한 내용만 주입하는 Minimal Context Injection 원칙을 적용한다. 컨텍스트 소비를 줄여 더 긴 추론 체인을 확보하고, 불필요한 정보 때문에 발생할 수 있는 환각 가능성도 낮추는 방식이다.

공유 리소스의 쓰기 충돌은 낙관적 잠금으로 처리한다. 서브에이전트가 쓰기를 시도할 때 버전 번호를 확인하고, 버전이 달라졌다면 최신 상태를 다시 조회한 뒤 작업을 재시도한다. 충돌이 세 번 이상 반복되면 오케스트레이터가 직접 중재하는 Mediation Queue로 태스크를 옮긴다. 분산 데이터베이스의 MVCC(Multi-Version Concurrency Control) 원리를 에이전트 오케스트레이션에 적용해 데드락 없이 처리량을 유지하는 설계다.

Dreaming은 세션 기록에서 재사용할 패턴을 찾는다

Dreaming은 에이전트가 유휴 상태일 때 지난 세션 로그를 복기하고 성공과 실패 패턴을 구조화된 메모리 엔트리로 바꾸는 비동기 파이프라인이다. 이름은 인간이 수면 중 기억을 공고화하는 과정에서 가져왔다. 실시간 태스크에 사용하지 않는 컴퓨팅 자원을 자기 개선에 활용한다는 발상이다.

로그 스토어에는 오케스트레이터와 서브에이전트가 주고받은 메시지, 도구 호출과 반환값, 최종 결과, 사용자 피드백 신호가 JSON 형태로 저장된다. 표준 스키마에는 세션 ID, 타임스탬프, 에이전트 ID, 메시지 역할, 콘텐츠, 토큰 수, 소요 시간, 성공 여부가 포함된다. 기본 보존 기간은 90일이며 엔터프라이즈 환경에서는 컴플라이언스 요건에 따라 연장할 수 있다.

Dreaming 프로세서는 성공적으로 끝난 추론 경로, 반복되는 실패, 도구 사용 효율을 중심으로 로그를 분석한다. 태스크가 최소 재시도로 완료됐다면 해당 추론 체인을 템플릿으로 만든다. 같은 유형의 작업에서 세 번 이상 실패가 반복되면 실패 원인을 분류한다. 불필요하거나 지나치게 반복된 도구 호출도 찾아낸다.

추출한 경험을 기억으로 승격한다

메모리 저장소는 작동 메모리, 에피소딕 메모리, 시맨틱 메모리로 구분된다. 작동 메모리는 현재 세션에서만 유효하며 세션이 끝나면 만료된다. 에피소딕 메모리에는 특정 태스크 유형과 연결된 경험적 지식을 저장하고, 비슷한 작업이 시작될 때 다시 조회한다. 시맨틱 메모리는 도메인 지식, 선호 도구, 오류 회피 규칙처럼 일반화된 지식을 보관해 거의 모든 태스크의 컨텍스트로 제공한다.

새로운 세션 로그가 들어오면 증분 갱신으로 기존 엔트리의 신뢰도 점수를 조정하거나 항목을 추가한다. 메모리 사이의 모순이 일정 임계값 이상 쌓이거나 도메인의 패러다임이 크게 바뀌면 전체 재구성을 수행한다. 전체 로그를 다시 분석해야 하는 리소스 집약적 작업이므로 기본적으로 주간 스케줄로 실행된다.

⤢✕

다음 세션에 넣을 기억을 선별한다

메모리는 세션을 초기화할 때 에이전트 시스템 프롬프트의 일부로 주입된다. 현재 태스크와 관련성이 높은 상위 K개 엔트리를 고르며, 관련성 점수는 태스크 임베딩과 메모리 임베딩의 코사인 유사도에 신뢰도 점수와 최신성 가중치를 곱해 계산한다. 기본 설정은 K=5이고 태스크 복잡도에 따라 동적으로 조정된다.

수명 관리는 사용 기반 만료와 시간 기반 만료를 함께 적용한다. 조회 횟수가 일정 임계값에 도달한 항목은 높은 관련성을 인정받아 만료 시점이 연장된다. 오랫동안 조회되지 않은 항목은 우선순위를 낮추고 저비용 스토리지로 옮긴다.

서로 충돌하는 기억이 발견되면 더 최근 에피소드에서 나온 엔트리를 우선한다. 이전 항목은 conflict 태그를 붙여 아카이브한다.

Outcomes는 실행과 평가를 분리한다

Outcomes는 태스크 결과를 자동으로 평가하고, 기준에 미달하면 재실행을 요청하는 품질 보증 메커니즘이다. 핵심은 실행 에이전트와 독립적으로 동작하는 Grader 에이전트다. Grader는 태스크 명세와 실제 결과물을 비교해 다차원 품질 점수를 산출한다.

평가 기준은 작업 유형에 맞게 바꿀 수 있다. 기본 프레임워크는 정확성, 완전성, 일관성, 효율성, 형식 준수를 다룬다. 정확성은 결과가 요구 사항에 맞는지를 확인하며 코드 작업에서는 단위 테스트 통과율로 정량화한다. 완전성은 명세에 적힌 하위 항목이 모두 반영됐는지 검사한다. 일관성은 비슷한 입력에서 출력이 안정적으로 유지되는지를, 효율성은 품질 대비 토큰·시간·도구 호출 소비를 평가한다. 형식 준수는 출력 스키마와 포맷 요건을 검사한다.

⤢✕

품질 임계값은 Strict, Standard, Lenient 등급으로 운영된다. 의료·법률·금융과 같은 고위험 도메인에는 Strict를 적용하며 모든 평가 차원에서 0.9 이상을 요구한다. 일반 엔터프라이즈 업무에 쓰는 Standard는 가중 평균 0.75 이상을 기준으로 한다. 초안이나 브레인스토밍처럼 창의성이 필요한 작업은 Lenient로 분류해 0.6 이상이면 승인한다.

임계값은 오케스트레이터 초기화 단계에서 태스크별로 직접 지정할 수 있고, 도메인 분류 모델이 추론하도록 설정할 수도 있다. Outcomes의 판정 결과와 실행 경로를 함께 기록하면 어떤 라우팅이 어떤 품질 결과로 이어졌는지 추적할 수 있다. 이 기록은 규정 준수를 위한 감사뿐 아니라 실패한 태스크의 도구 호출, 상태, 결과를 역추적하는 장애 분석에도 쓰인다. 감사 이벤트에는 task_id, agent_id, timestamp, tool_name, input_hash, output_hash, status를 포함할 수 있으며, 개인정보 보호를 위해 실제 입출력 데이터 대신 해시값을 저장한다.

Webhooks가 외부 이벤트를 실행 큐로 옮긴다

Webhooks는 외부 시스템에서 발생한 이벤트를 에이전트 실행 트리거로 연결하는 통합 계층이다. 폴링 방식처럼 상태를 반복 조회하지 않고 이벤트가 발생했을 때 에이전트를 호출하므로 응답 지연을 크게 줄일 수 있다. 외부 시스템의 변화를 곧바로 반영하는 반응형 아키텍처를 구성하는 방식이다.

이벤트 스키마에는 event_type, payload, routing_key, priority가 필수로 들어간다. event_type은 code.push, ticket.created, data.updated와 같은 사전 정의 카테고리나 커스텀 이벤트 유형을 표현한다. payload는 에이전트가 작업 컨텍스트로 사용할 구조화된 데이터다. routing_key는 이벤트를 처리할 에이전트나 오케스트레이터 인스턴스를 지정한다. priority는 긴급도를 0~9 사이의 정수로 나타내며 태스크 큐의 우선순위를 정할 때 사용한다.

{
  "event_type": "task.trigger | task.complete | task.failed | agent.status",
  "session_id": "uuid",
  "timestamp": "ISO-8601",
  "payload": {
    "task_id": "string",
    "priority": "low | normal | high | critical",
    "context": {},
    "result": {}
  },
  "retry_policy": {
    "max_attempts": 3,
    "backoff": "exponential"
  }
}

⤢✕

이벤트 발신자는 공유 시크릿을 사용해 페이로드에 HMAC-SHA256 서명을 만든다. 에이전트 플랫폼은 수신 즉시 서명을 검증해 위조 이벤트를 차단한다.

재전송은 At-least-once Delivery 방식으로 보장한다. 처리 완료 확인인 ACK가 도착할 때까지 이벤트를 메시지 큐에 보관하고, 작업이 끝나면 결과 Webhook을 발신자에게 다시 보내 처리 결과를 알린다. 외부 이벤트와 결과 콜백이 이어지는 양방향 루프를 통해 기존 DevOps 및 비즈니스 워크플로우 툴체인에 에이전트 플랫폼을 통합할 수 있다. 이 연결은 에이전트를 독립된 실행 단위로 두는 대신 기존 시스템의 이벤트 처리 컴포넌트로 편입하고, 병렬 실행·평가·재실행·기억 갱신을 운영 플랫폼의 흐름으로 확장하는 접점이 된다.

Harvey AI 사례에서 드러난 변화

Harvey AI는 법률 업무 자동화에 특화된 AI 플랫폼이다. Claude Managed Agents 도입 전에는 단일 에이전트가 복잡한 법률 문서를 분석하는 과정에서 컨텍스트 한도와 추론 복잡도의 제약을 받아 태스크 완료율이 낮은 수준에 머물렀다. 도입 후 완료율은 6배 향상됐다.

이 변화는 태스크 분해, Outcomes, Dreaming이 결합한 결과로 분석된다. 수백 페이지의 계약서를 조항 단위로 나누어 서브에이전트에 배정하면서, 단일 에이전트가 전체 문서를 한꺼번에 처리하다 컨텍스트 한도에 걸려 불완전한 결과를 내던 문제를 해소했다.

Outcomes는 법률 업무에 맞춘 평가 기준으로 조항 분석 결과를 검사하고, 불완전한 항목을 자동으로 다시 처리했다. 이 과정에서 수동 검토 부담이 줄고 에이전트가 스스로 완성도를 높이는 품질 루프가 형성됐다.

Dreaming에는 판례 분석 패턴, 오류가 자주 발생하는 법률 용어 해석 사례, 특정 계약 유형에 효과적인 분석 전략이 쌓였다. 같은 유형의 태스크를 다시 수행할 때 이 기억을 활용하면서 초기 성공률도 점진적으로 향상됐다.

지표	도입 전	도입 후	변화율
태스크 완료율	기준치	6× 향상	+500%
컨텍스트 한도 초과 오류	높음	태스크 분해로 해소	대폭 감소
수동 재검토 비율	높음	Outcomes 자동화로 감소	대폭 감소
동일 유형 태스크 초기 성공률	낮음	Dreaming 메모리 축적 후 향상	점진적 향상

이 구조를 적용한 뒤 처리 시간은 65% 단축됐으며, Grader 루프의 품질 검증을 거치면서 오탐(false positive) 리스크 지적은 78% 감소했다.

KPMG는 Claude Managed Agents를 세무 조사와 재무 보고서 검토 워크플로에 도입해 규정 준수 확인, 이상 탐지, 보고서 초안 작성을 멀티에이전트 파이프라인으로 자동화했다.

지표	도입 전	도입 후	개선율
보고서 초안 작성 시간	8시간	45분	91% 단축
규정 준수 오류율	2.3%	0.4%	83% 감소
시니어 컨설턴트 검토 시간	3시간	40분	78% 단축
태스크 완료율	94%	99.2%	5.5%p 향상

Harvey AI 사례가 보여 주는 효과는 병렬 처리에 따른 속도 향상에만 머물지 않는다. 오케스트레이터가 작업을 나누고, Outcomes가 결과를 검증하며, Dreaming이 실행 경험을 다음 세션으로 돌려보낼 때 시스템은 반복 운용을 통해 도메인 지식을 축적한다.

평균적으로 엔터프라이즈 고객들은 초기 통합 비용을 6~~9개월 안에 회수하며, 3년 ROI는 투자 대비 340~~580% 수준을 보고하고 있다.

최대 20개 서브에이전트와 DAG 기반 분해는 복잡한 업무를 수평으로 확장할 수 있게 한다. Grader 에이전트는 결과가 품질 기준에 미달할 때 사전에 정한 최대 재시도 횟수와 재시도 예산 안에서 평가 피드백을 반영한 재실행을 연결한다. 한도를 초과한 태스크는 Fallback 큐로 보내거나 오케스트레이터의 개입·에스컬레이션 대상으로 전환하고, Webhooks는 이 내부 루프를 외부 업무 시스템의 이벤트 흐름에 편입한다. 권한 분리와 감사 가능한 실행 기록까지 갖추면, 실행 기록과 평가 결과가 다음 작업의 메모리로 이어지는 운영 인프라를 기업 워크플로에 적용할 수 있다.