멀티 에이전트 오케스트레이션 패턴: 실용 가이드

멀티 에이전트 파일럿의 40%가 실패합니다. 올바른 오케스트레이션 패턴을 선택하고 실패하는 패턴을 피하는 방법을 소개합니다.

Page content

2025년은 단일 에이전트 AI 시스템이 정점에 달했던 해였습니다. 여러분은 하나의 LLM에 프롬프트, 몇 가지 도구, 그리고 목표를 부여했고, 그것은 제한된 작업에서 꽤나 잘 수행했습니다.

2026년, 다중 에이전트 시스템은 연구 데모 단계에서 실제 프로덕션 인프라로 넘어갔습니다. 가트너(Gartner)는 2024년 1분기부터 2025년 2분기까지 다중 에이전트 시스템에 대한 문의가 1,445% 증가했다고 보고했으며, Salesforce의 2026년 연결성 벤치마크 보고서에서는 조직들이 평균 12개의 에이전트를 사용하고 있으며 이는 2년 내로 67% 증가할 것으로 예측된다고 밝혔습니다. AI Systems 클러스터는 이러한 시스템이 작동하는 전체 스택을 다루고 있습니다 — 추론과 메모리부터 라우팅과 관측성(observability)에 이르기까지.

Multi-agent orchestration patterns for production AI systems

하지만 덜 논의되는 점은 다음과 같습니다. 프로덕션 배포 후 6개월 이내에 다중 에이전트 파일럿의 40%가 실패합니다. 실패의 원인은 다중 에이전트 시스템이 작동하지 않기 때문이 아닙니다. 실패는 팀이 자신의 문제에 맞지 않는 오케스트레이션 패턴을 선택했거나, 그것이 어떻게 깨지는지 이해하지 못한 채 올바른 패턴을 선택했기 때문입니다.

이 가이드는 프로덕션 환경에서 견고하게 작동하는 오케스트레이션 패턴, 각 패턴이 실패하는 구체적인 방식, 그리고 올바른 아키텍처를 선택하기 위한 결정 프레임워크를 다룹니다.

핵심 문제: 조정은 어렵습니다

단일 AI 에이전트에서 여러 에이전트가 함께 작업하는 상태로 넘어갈 때, 가장 먼저 떠오르는 엔지니어링 질문은 이것입니다. 그들은 어떻게 조율할 것인가?

조정 모델, 즉 오케스트레이션 패턴은 시스템의 레이턴시, 장애 내성, 확장성 한계, 디버깅 복잡성을 결정합니다. 이는 다중 에이전트 설계에서 지속적으로 가장 큰 영향을 미치는 아키텍처 결정이며, 이후 모든 구현 선택의 전제 조건이 됩니다.

모든 프로덕션 다중 에이전트 시스템은 여섯 가지 정형 패턴 중 하나, 또는 두 가지 이상의 하이브리드로 매핑됩니다. 이러한 패턴은 분산 시스템의 제약 — 조정 비용, 격리된 장애 처리, 처리량 요구사항, 관측성 — 에서 비롯됩니다.

패턴 1: 오케스트레이터-워커(Orchestrator-Worker)

작동 방식

오케스트레이터-워커는 다중 에이전트 조정의 중앙 집중식 허브-스포크(hub-and-spoke) 모델입니다. 단일 오케스트레이터 에이전트가 작업을 받아서 하위 작업으로 분해하고, 각 하위 작업을 전문 워커 에이전트에 위임한 후 결과를 집계합니다. 워커들은 서로 직접 통신하지 않습니다 — 모든 조정은 오케스트레이터를 통해 흐르며, 오케스트레이터가 전체 계획과 의사결정 권한을 보유합니다.

graph TD O[Orchestrator
planner] --> WA[Worker A] O --> WB[Worker B] O --> WC[Worker C]

사용 시기

  • 명확한 작업 분해가 가능한 교차 기능 워크플로우
  • 분류 및 라우팅 시나리오(고객 지원, 사건 분류)
  • 단일 책임 지점이 필요한 워크로드
  • 오케스트레이터가 강력한 모델을 사용하면서 워커들은 비용이 저렴하고 작업 특화적인 모델을 사용할 수 있는 작업

실제 사례: Salesforce Agentforce 2.0은 고객 문의를 연구, 초안 작성, 검토 단계로 분해하기 위해 오케스트레이터-워커를 사용합니다.

실패 방식

단일 장애점. 오케스트레이터는 병목 현상이자 장애점입니다. 오케스트레이터의 LLM 호출에 3초가 걸리고 20개의 워커가 할당을 기다리고 있다면, 분해 처리량 한계는 초당 약 6.7개 작업입니다. 오케스트레이터가 작업을 잘못 분류하면 잘못된 워커가 작업을 받게 되며, 오분류율은 규모에 따라 누적됩니다.

컨텍스트 오버플로. 오케스트레이터는 모든 워커로부터 컨텍스트를 축적합니다. 4개 이상의 워커가 있는 경우, 오케스트레이터는 모든 워커 상호작용에 대한 전체 대화 기록을 동시에 보유하고 있어 빈번하게 컨텍스트 한계를 초과합니다.

비용 폭주. 테스트에서는 $0.50였던 워크플로우가 10만 번 실행 시 월 $50,000에 달할 수 있습니다. 오케스트레이터는 각 워커 호출 외에도 분해 및 집계를 위해 여러 번의 LLM 호출을 수행합니다. 대규모에서 오버헤드가 워커 비용을 압도합니다.

완화 조치

  • 오케스트레이터와 워커 간 명시적인 인터페이스 계약을 설정
  • 워커에게 구조화된 출력(JSON 스키마, 타입 지정 응답)을 요구
  • runaway costs(통제不能한 비용)를 방지하기 위해 하위 작업 예산(토큰 한계, 단계 한계)을 설정
  • 워커 수가 5개를 초과할 경우 계층적 변형(패턴 4 참조) 고려

패턴 2: 시퀀셜 파이프라인(Sequential Pipeline)

작동 방식

시퀀셜 파이프라인은 공유 상태를 가진 선형 체인 — 결정론적인 순서로 정의된 에이전트들의 시퀀스로, 각 단계가 데이터를 변환하거나 풍부하게 한 후 다음 단계로 전달합니다. 런타임 분기(branching)는 없으며, 실행 순서는 설계 시점에 고정되어 있어 이 패턴은 매우 예측 가능하지만 유연하지 않습니다.

graph LR I[Input] --> A1[Agent 1
stage A] A1 --> A2[Agent 2
stage B] A2 --> A3[Agent 3
stage C] A3 --> O[Output]

사용 시기

  • 문서 처리 워크플로우(수신 → 추출 → 검증 → 출력)
  • 콘텐츠 생성 파이프라인(연구 → 초안 → 편집 → 게시)
  • 규정 준수 검증(생성 → 확인 → 수정 → 승인)
  • 데이터 증강 및 ETL 워크플로우

실제 사례: Microsoft Azure 로펌 워크플로우는 계약 생성을 위해 시퀀셜 파이프라인을 사용합니다: 초안 → 검토 → 수정 → 최종.

실패 방식

오류 전파. 1단계의 잘못된 출력은 백트래킹(backtracking) 없이 하류로 연쇄적으로 전파됩니다. 연구 단계의 환각(hallucination)은 결함 있는 초안을 생성하고, 편집자는 이를 자신감 있지만 잘못된 최종 출력으로 다듬습니다.

조정 오버헤드. 4개 에이전트 파이프라인은 처리 시간 500ms에 비해 약 950ms의 조정 오버헤드를 추가합니다. 전문화가 필요하지 않다면 동일한 결과에 대해 3배의 비용을 지불하는 셈입니다. 토큰 소비도 누적됩니다: 동일한 작업을 수행하는 단일 에이전트의 10,000 토큰에 비해 4개 에이전트 파이프라인에서는 29,000 토큰이 소모됩니다.

조건부 분기 불가. 파이프라인은 중간 결과에 따라 적응할 수 없습니다. 2단계가 입력이 잘못 형성되었음을 발견하더라도, 1단계에 재시도를 신호할 메커니즘이 없습니다 — 실패하거나 열화된 출력을 생산해야 합니다.

완화 조치

  • 단계 사이에 품질 게이트 삽입(하류로 전달하기 전에 출력을 확인하는 경량 검증 에이전트)
  • 재시도가 가능한 단계에 재처리 루프 추가 — Temporal과 같은 내구성 워크플로우 엔진은 재시맨틱을 신뢰성 있게 처리
  • 파이프라인을 최대 3-4 단계로 유지; 그 이상일 경우 조건부 분기를 위해 오케스트레이터-워커 고려

패턴 3: 팬아웃 / 팬인(Fan-Out / Fan-In)

작동 방식

팬아웃 / 팬인은 집계를 통한 병렬 실행입니다. 디스패처가 작업을 동시에 실행되는 여러 에이전트로 라우팅하고, 수집기(collector)가 투표, 가중치 병합, 또는 LLM 합성을 통해 결과를 집계합니다. 에이전트는 실행 전체 동안 독립적으로 작동하며 서로 통신하지 않습니다 — 유일한 공유 경계는 수집기입니다.

graph TD D[Dispatcher] --> AA[Agent A] D --> AB[Agent B] D --> AC[Agent C] AA --> C[Collector
merge] AB --> C AC --> C

사용 시기

  • 다양한 관점이 가치 있는 다각도 분석
  • 동시 코드 리뷰(병렬로 작동하는 여러 리뷰어)
  • 사전에 분해할 수 있는 4개 이상의 독립적 작업
  • 토큰 효율성보다 월클록 타임(wall-clock time, 실제 소요 시간)이 더 중요한 워크로드

핵심 지표: 팬아웃은 순차적 실행 대비 월클록 시간을 75% 단축합니다. 4개의 에이전트가 병렬로 실행되면 하나의 에이전트가 수행하는 시간만큼에 완료됩니다.

실패 방식

API 속도 제한. 개별 에이전트가 한계 내에 있더라도 집단 부하가 용량을 초과합니다. 분당 10개의 요청을 보내는 5개의 에이전트는 단일 에이전트가 준수하는 분당 40회(RPM) 한계를 초과할 수 있습니다.

2차적 경쟁 조건. 공유 상태 충돌은 N(N-1)/2로 증가합니다. 5개 에이전트라면 10개의 잠재적 충돌, 10개라면 45개의 충돌이 발생합니다. 상태 관리가 주요 복잡성이 됩니다.

집계 환각. LLM 합성은 합의를 만들어낼 수 있습니다. 에이전트 A가 “예"라고 하고 에이전트 B가 “아니오"라고 할 때, 집계기는 “어쩌면"이라는 환각된 중간 지점을 생성할 수 있습니다 — 이는 어느 에이전트도 제안하지 않은 것입니다. 단순한 요약이 아닌 명시적인 충돌 해결이 필요합니다.

완화 조치

  • 자유로운 합성 대신 명시적인 투표 메커니즘 사용
  • 디스패처 수준에서 속도 제한 구현
  • 워커별 별도 상태 유지; 수집기에서 병합
  • 경쟁 조건을 관리 가능한 수준으로 유지하기 위해 최대 에이전트 수(5-8개) 설정

패턴 4: 계층적(Hierarchical)

작동 방식

계층적은 다중 수준의 트리 구조 위임 — 최상위 관리자가 중간 수준 감독자에게 위임하고, 이들은 리프(leaf) 수준 워커에게 위임합니다. 각 수준은 추상화 레이어를 추가합니다: 최상위에서는 전략, 중간에서는 전술, 리프에서는 실행. 컨텍스트 윈도우는 각 수준에서 독립적으로 관리되므로, 단일 에이전트가 전체 문제를 컨텍스트에 보유할 필요가 없습니다.

graph TD TM[Top Manager] --> SA[Supervisor A] TM --> SB[Supervisor B] TM --> SC[Supervisor C] SA --> W1[Worker 1] SB --> W2[Worker 2] SC --> W3[Worker 3]

사용 시기

  • 20개 이상의 에이전트를 필요로 하는 복잡한 다중 도메인 엔터프라이즈 작업
  • 서로 다른 모듈이 다른 전문가를 필요로 하는 대규모 코드베이스 감사
  • 여러 범주에 걸쳐 수천 개의 문서를 처리하는 대규모 문서 처리
  • 단일 에이전트의 컨텍스트 윈도우가 전체 문제를 담을 수 없는 작업

핵심 장점: 계층적 시스템은 로그arithmically(로그적으로) 확장됩니다. 각 관리자가 제한된 수의 부하를 처리하므로, 워커를 추가해도 조정 오버헤드가 선형적으로 증가하지 않습니다.

실패 방식

레이턴시 누적. 각 수준이 레이턴시를 추가합니다. 3단계 계층 구조는 최소 6-12초가 필요하며, 이는 단계별로 누적됩니다. 최상위 관리자는 모든 감독자를 기다리고, 감독자는 모든 워커를 기다립니다.

정보 손실. 수준 간의 요약은 손실이 발생합니다. 감독자가 최상위 관리자를 위해 워커 출력을 요약하면, 최종 결정에 중요한 세부 사항이 손실될 수 있습니다.

분기 실패 격리. 한 분기의 실패는 다른 분기로 전파되지 않습니다 — 이는 장애 내성에는 좋지만 일관성에는 나쁩니다. 다른 분기들이 상충되는 결론에 도달할 수 있으며, 최상위 관리자가 이를 해결할 수 없습니다.

완화 조치

  • 각 수준에 명시적인 요약 요구사항 설정
  • 최상위 관리자에서 크로스-브랜치(cross-branch) 검증 구현
  • 계층 깊이를 최대 2-3단계로 유지
  • 정보 손실을 줄이기 위해 모든 수준에서 구조화된 출력 사용

패턴 5: 스웜(Swarm)

작동 방식

스웜은 중앙 권한이 없는 분산형 자생적 조정입니다. 자율 에이전트는 공유 상태(블랙보드) 또는 환경 신호를 기반으로 로컬 결정을 내리며, 흐름을 지시하는 오케스트레이터가 없습니다. 에이전트는 사용 가능한 작업을 발견하고, 이를 주장하며, 결과를 공유 공간에 게시합니다. 조정은 자생적입니다 — 시스템은 중앙 조정자 없이 새로운 벌집을 향해 이동하는 벌들처럼 사용 가능한 작업 주변에 자발적으로 조직화됩니다.

graph TB SB[Shared Blackboard
tasks · results · observations] AA[Agent A] <--> SB AB[Agent B] <--> SB AC[Agent C] <--> SB AD[Agent D] <--> SB AE[Agent E] <--> SB AF[Agent F] <--> SB

사용 시기

  • 최적의 검색 경로가 알려지지 않은 연구 흐름
  • 여러 소스에 걸친 경쟁 정보 수집
  • 동적 타겟 발견을 통한 대규모 웹 스크래핑
  • 과학적 또는 분석적 도메인에서의 병렬 가설 탐색

핵심 장점: 50개의 연구 에이전트 스웜은 중앙 조정자가 검색을 계획하지 않아도 50개의 가설을 병렬로 탐색할 수 있습니다. 시스템은 사용 가능한 작업 주변에 자발적으로 조직화됩니다.

실패 방식

디버깅 악몽. 중앙 제어 흐름이 없으므로, 실패를 추적하려면 분산 추적과 블랙보드 리플레이가 필요합니다. 단일 실행 경로를 따라갈 수 없습니다 — 로그에서 자생적 행동을 재구성해야 합니다.

트랜잭션 보장 부재. 스웜 패턴은 엄격한 순서나 트랜잭션 일관성을 강제할 수 없습니다. 에이전트 A가 에이전트 B 시작 전에 완료되어야 한다면, 스웜은 잘못된 패턴입니다.

종료 조건. 스웜은 언제 멈춰야 하는지 어떻게 알까요? 명시적인 종료 기준이 없으면, 에이전트들은 무한정 계속 작동하여 컴퓨팅을 소모하고 체감 수익이 감소할 수 있습니다.

완화 조치

  • 명시적인 종료 조건 구현(시간 기반, 결과 수 기반, 또는 수렴 기반)
  • 상태 변경을 추적하기 위해 버전 관리된 엔트리가 있는 블랙보드 사용
  • 스웜 행동을 관찰하고 개입할 수 있는 모니터링 에이전트 추가
  • runaway execution을 방지하기 위해 에이전트 수준 예산(최대 단계, 최대 토큰) 설정 — Kanban-style dispatchers는 자체 호스팅 스웜 배포에 실용적인 속도 제한 및 동시성 패턴을 제공합니다

패턴 6: 메쉬(Mesh)

작동 방식

메쉬는 지속적인 연결을 통한 직접적인 피어-투-피어 통신 — 에이전트는 중앙 허브가 아닌 명시적이고 사전 정의된 채널을 통해 서로 통신합니다. 통신 그래프는 일반적으로 배포 시점에 정의되므로, 에이전트 A는 데이터베이스 쿼리를 위해 에이전트 B가 필요하고 인증 로직을 위해 에이전트 C가 필요함을 알고 있습니다. 이러한 피어들이 별도의 서비스, 팀, 또는 벤더에 걸쳐 있을 때 전송 계층이 변경됩니다; 아래 에이전트가 경계를 교차할 때 패턴 구현을 참조하십시오.

graph LR A[Agent A] --- B[Agent B] A --- C[Agent C] B --- C

사용 시기

  • 에이전트가 중간 상태를 공유해야 하는 협력적 추론
  • 다중 에이전트 코딩 시스템(플래너 ↔ 코더 ↔ 테스터 루프)
  • 여러 전문가가 기여하는 반복적 아티팩트 정교화
  • 에이전트가 서로 다른 이해관계자를 대표하는 협상 시나리오

핵심 장점: 반복적 정교화에 이상적입니다. 에이전트는 중앙 집계기 없이 서로의 작업을 기반으로 하며 부분적인 결과를 오가며 전달할 수 있습니다.

실패 방식

조합적 폭발. 연결 수는 N(N-1)/2로 증가합니다. 3개 에이전트라면 3개의 연결, 8개라면 28개의 연결입니다. 3-8개의 긴밀하게 결합된 에이전트로 제한하는 것이 좋습니다.

순환 의존성. 에이전트 A가 에이전트 B를 호출하고, B가 C를 호출하며, C가 A를 호출합니다. 사이클 감지가 없으면 메쉬 패턴은 무한 루프에 빠질 수 있습니다.

디버깅 복잡성. 비결정론적 라우팅은 실패 추적을 거의 불가능하게 만듭니다. 출력이 잘못되었을 때, 어떤 에이전트가 어떤 에이전트와, 어떤 순서로 통신했는지 재구성해야 합니다.

완화 조치

  • 배포 시점(런타임이 아닌)에 통신 그래프 정의
  • 최대 홉(hop) 한계와 함께 사이클 감지 구현
  • 명시적인 확인을 포함한 메시지 패싱 사용
  • N 홉 후 통신 체인을 종료하는 서킷 브레이커 추가

에이전트가 경계를 교차할 때 패턴 구현

오케스트레이션 토폴로지를 선택하는 것과 에이전트가 통신하는 방식을 선택하는 것은 별개의 결정입니다. 위의 여섯 가지 패턴은 작업이 흐르는 방식 — 누가 누구에게 위임하는지, 단계가 병렬로 실행되는지, 피어가 직접 대화하는지를 설명합니다. 이는 이러한 에이전트들이 하나의 Python 프로세스, 하나의 Kubernetes 클러스터, 또는 세 개의 벤더 SaaS 제품에 있는지 여부를 규정하지 않습니다.

프로세스 내(in-process) 다중 에이전트 시스템 — 단일 저장소 내의 LangGraph 그래프, CrewAI 크루, AutoGen 그룹 채팅 — 은 조정을 하나의 런타임 내부에 유지합니다. 메시지 패싱은 함수 호출 또는 공유 상태입니다. 빠른 반복, 간단한 디버깅, 보안할 네트워크 경계 부재를 얻습니다. 이는 에이전트를 독립적으로 배포 가능한 서비스로 분할할 구체적인 이유가 있을 때까지 올바른 기본값입니다.

에이전트가 서로 다른 팀에 의해 소유되거나, 다른 프레임워크에서 실행되거나, 호출자를 재배포하지 않고 발견 가능해야 할 때 경계에서 와이어 프로토콜이 필요합니다. 이때 A2A vs MCP: AI 에이전트는 정말로 두 프로토콜 모두 필요한가?가 결정 지점이 됩니다: 메모리를 공유하지 않는 서비스 간 에이전트 카드를 통한 표준화된 발견, 작업 라이프사이클, 아티팩트 교환, 그리고 그 오버헤드가 MCP 단독으로 프로세스 내 상태를 유지하는 것과 비교했을 때 가치가 있는지 여부를 위한 프레임워크.

패턴을 배포로 매핑

에이전트가 별도의 서비스가 된 후에도 선택한 토폴로지는 여전히 중요합니다. 모든 패턴이 경계 간 A2A로 깔끔하게 매핑되는 것은 아닙니다; 일부는 본질적으로 내부에 머무릅니다.

Pattern Same runtime / framework Cross-boundary (A2A)
Orchestrator-Worker In-process delegation via graph edges Primary assistant delegates to specialist Agent Cards
Sequential Pipeline Stages wired in one runtime graph Rare — stages are usually co-located for latency
Fan-Out / Fan-In Parallel workers under one orchestrator Uncommon unless workers are already separate services
Hierarchical Nested graphs in one process Department-level agents as A2A peers under a top orchestrator
Swarm Shared blackboard, one process Unusual cross-boundary — shared state and governance are harder
Mesh Custom graph edges in-process Primary A2A use case — peers across teams, vendors, or frameworks

오케스트레이터-워커와 계층적 패턴은 프로덕션에서 가장 일반적인 경계 간 형태입니다: 사용자 친화적인 오케스트레이터가 전문가를 발견하고 위임된 작업을 추적합니다. 메쉬는 단일 허브가 라우팅을 소유해서는 안 되는 경우 자연스러운 적합이 됩니다 — 예를 들어, 서로 다른 팀이 소유하는 테스트 에이전트 및 보안 검토 에이전트와 직접 대화하는 코딩 에이전트.

소유권 경계 간 메쉬

메쉬 참여자가 소유권 경계를 가로지르는 경우, 프로세스 내 그래프 에지가 A2A 작업 전송이 됩니다. 각 피어는 기술, 인증 요구사항, 엔드포인트를 설명하는 에이전트 카드를 게시합니다. 호출자는 애플리케이션 구성에 URL을 하드코딩하는 대신 런타임 또는 큐레이션된 레지스트리에서 기능을 발견합니다.

여기서 두 가지 배포 스타일이 경쟁합니다. 배포 시점의 사전 정의된 그래프는 메쉬를 예측 가능하게 유지합니다: 에이전트 A는 에이전트 B 및 C를 호출하도록 구성되며, A2A가 와이어 포맷과 작업 상태를 처리합니다. 런타임 발견은 오케스트레이터가 기술이나 벤더가 변경될 때 레지스트리에서 전문가를 선택할 수 있게 하지만, 더 많은 움직이는 부분과 더 엄격한 거버넌스를 대가로 지불합니다. 대부분의 팀은 사전 정의된 그래프로 시작하고, 에이전트 카탈로그가 구성 파일로 관리할 수 있는 범위를 넘어서면 발견 기능을 추가합니다.

A2A는 위의 섹션에서 메쉬 실패 모드를 제거하지 않습니다. 조합적 연결 증가, 순환 핸드오프, 불투명한 디버깅은 여전히 적용됩니다 — 단지 인메모리 큐 대신 HTTP를 통해 발생한다는 차이입니다. 오케스트레이터 또는 게이트웨이에서 사이클 감지와 최대 홉 한계를 유지하십시오. 장시간 위임된 작업은 각 홉을 차단하는 대신 작업 ID와 비동기 추적을 사용해야 합니다; A2A 스트리밍 및 에이전트 워크플로우를 위한 비동기 작업은 해당 경계에서의 SSE, 푸시 웹훅, input_required 중지를 다룹니다.

동적, 범위 지정된 인증, 그리고 감사 추적은 피어가 별도의 서비스가 되면 필수적입니다. A2A 및 MCP 에이전트 보안: 정체성, 위임, 그리고 감사 추적은 게이트웨이, 위임 토큰, 그리고 각 홉에서 기록해야 할 내용을 다룹니다.

경계 간 에이전트에 특화된 실패 모드

오케스트레이션 패턴이 프로세스 경계를 벗어날 때 자주 나타나는 세 가지 문제:

서비스 간 순환 위임. 팀 1의 에이전트 A가 팀 2의 에이전트 B에게 위임하고, 이는 A로 되돌아가거나 최종적으로 A를 호출하는 세 번째 에이전트에게 위임합니다. 메쉬 섹션의 완화 조치 — 홉 한계, 사이클 감지, 서킷 브레이커 — 는 A2A가 구조화된 메시지를 제공한다고 해서 사라지는 것이 아니라, 게이트웨이 또는 오케스트레이터에서 강제되어야 합니다.

위임 체인 간 숨겨진 비용 폭주. 각 A2A 홉은 LLM, 도구, 그리고 추가 하위 위임을 호출할 수 있습니다. 프로세스 내에서는 저렴해 보였던 토폴로지가 각 전문가가 청구되는 API 호출이 될 때 토큰 지출이 증식할 수 있습니다. 작업 ID 및 홉별 비용을 추적하십시오; 비용 제어 섹션의 내용이 경계 간 체인에 직접 적용됩니다.

최종 답변의 불분명한 소유권. 두 벤더의 세 에이전트가 아티팩트에 기여할 때, 사용자와 감사자는 어떤 에이전트(및 그 뒤의 모델과 도구)가 그들이 보는 출력을 생성했는지 알아야 합니다. 부모 작업 ID를 전파하고, 위임 체인을 기록하며, 아티팩트 계보를 사후 생각이 아닌 일차적인 관측성 필드로 취급하십시오 — 문제가 발생했을 때.

다음 단계

이 섹션은 오케스트레이션 토폴로지를 프로토콜 선택으로 연결합니다. 각 레이어의 깊이 있는 내용을 위해:

결정 프레임워크

문제를 해결할 수 있는 가장 간단한 패턴으로 시작하십시오. 대부분의 팀은 단일 에이전트 접근 방식이 진정으로 고갈되기 전에 다중 에이전트 토폴로지를 향해 과도하게 설계합니다.

단계 1: 문제 특성화

문제 특성 권장 패턴
알려진 작업 분해, 명확한 전문가 오케스트레이터-워커
고정된 시퀀스, 분기 불필요 시퀀셜 파이프라인
독립적 하위 작업, 병렬성 필요 팬아웃 / 팬인
복잡, 다중 도메인, 20+ 에이전트 계층적
탐색, 알려지지 않은 검색 공간 스웜
협력적 정교화, 피어 통신 메쉬

단계 2: 제약 조건 추정

제약 조건 피해야 할 패턴
낮은 레이턴시 (< 2초) 계층적, 메쉬
엄격한 순서 필요 스웜, 팬아웃
단일 책임 지점 스웜, 메쉬
높은 장애 내성 필요 오케스트레이터-워커, 시퀀셜
예산 제약 팬아웃 (병렬 = 더 많은 토큰)
복잡한 디버깅 필요 스웜, 메쉬

단계 3: 단일 에이전트로 시작

도구, 추론, 반복을 가진 단일 에이전트의 정형 에이전트 루프는 여전히 범용 에이전트에 대한 올바른 기본값입니다. AI 어시스턴트 아키텍처는 단일 에이전트 시스템이 구축하는 5계층 기반을 다루며, 다중 에이전트 조정을 레이어링하기 전에 그 기반을 마스터하는 것이 가치가 있습니다. 다중 에이전트 시스템이 다중 모델 라우팅과 근본적으로 다르다는 점에 유의하십시오; 후자의 경우 다중 모델 시스템 설계를 참조하십시오, 이는 에이전트 조정이 아닌 모델 선택에 적용되는 시퀀셜, 병렬, 앙상블 패턴을 다룹니다.

측정이 필요하다고 말할 때만 다중 에이전트로 에스컬레이션하십시오:

  • 단일 에이전트 컨텍스트 윈도우가 불충분할 때
  • 작업이 진정한 병렬성을 필요로 할 때(월클록 타임이 중요할 때)
  • 전문화가 측정 가능한 품질 개선을 제공할 때
  • 단일 에이전트 접근 방식의 비용이 다중 에이전트 오버헤드를 초과할 때

배경 및 사전 에이전트 작업 — 스케줄링, 큐 기반 실행, 내구성 폴링 루프 — 에 대해서는 AI 어시스턴트의 폴링 에이전트: 11가지 구현 패턴을 참조하십시오, 이는 다중 에이전트 오케스트레이션 패턴을 그 아래의 스케줄링 레이어와 보완합니다.

실패 모드: MAST 분류법

NeurIPS 2025의 연구(MAST — 다중 에이전트 시스템 실패 분류법)는 7가지 인기 있는 다중 에이전트 프레임워크에 걸친 1,600개 이상의 실행 트레이스를 분석했습니다. 실패는 세 가지 근본 범주로 분포합니다:

1. 명세 모호성(실패의 33%)

에이전트는 역할 오해, 작업 중복, 또는 검증 건너뛰기를 일으키며, 이는 그들의 지시가 과소 명세되어 있기 때문입니다.

해결: 명세 스키마 사용. 각 에이전트에 대해 명시적인 역할 설명, 작업 경계, 출력 포맷을 정의하십시오. 구조화된 스키마(JSON, Pydantic 모델)가 자연어 지시보다 우월합니다.

2. 조정 붕괴(실패의 33%)

에이전트는 구조화되지 않은 프로토콜로 통신하여 메시지 손실, 경쟁 조건, 순환 핸드오프를 초래합니다.

해결: 구조화된 조정 프로토콜 구현. 타입 지정 메시지 패싱, 확인 메커니즘, 명시적인 종료 조건을 사용하십시오.

3. 검증 격차(실패의 33%)

에이전트 출력에 대한 독립적인 검증이 없습니다. 에이전트는 검증 없이 서로의 출력을 신뢰하여 오류가 전파되도록 허용합니다.

해결: 독립적인 검증 에이전트 추가. 출력을 수용하기 전에 별도의 모델 또는 검증 단계로 출력을 검증하십시오. 이는 메이커-체커(maker-checker) 패턴입니다.

비용 제어: 숨겨진 승수

다중 에이전트 시스템은 비선형적으로 확장되는 비용 구조를 가집니다:

Pattern Cost Multiplier (vs single agent)
Orchestrator-Worker 2-3x (orchestrator + workers)
Sequential Pipeline 3-4x (each stage pays full token cost)
Fan-Out / Fan-In 4-5x (all agents run fully)
Hierarchical 3-5x (depends on depth)
Swarm 2-10x (depends on convergence)
Mesh 3-6x (depends on iteration count)

비용 최적화 전략:

  1. 워커에 더 저렴한 모델 사용. 오케스트레이터는 추론 능력이 필요하지만; 워커는 더 작고 빠른 모델을 사용할 수 있습니다.
  2. 실행 예산 제한. 에이전트별 최대 토큰, 최대 단계, 최대 시간을 설정하십시오.
  3. 조기 종료 구현. 명확히 실패하거나 성공한 에이전트를 중지하십시오.
  4. 공유 컨텍스트 캐싱. 공유 시스템 프롬프트의 재계산을 피하기 위해 프리픽스 캐싱(vLLM, SGLang RadixAttention)을 사용하십시오.
  5. 에이전트별 비용 모니터링. 총 비용이 아닌 에이전트별 토큰 소비를 추적하십시오. 가장 비용이 많이 드는 에이전트를 식별하고 먼저 최적화하십시오.

토큰 최적화 전략 — 프롬프트 압축, 캐싱, 배칭, 스마트 모델 선택 — 에 대한 더 깊은 처리를 위해 LLM 비용 감소: 토큰 최적화 전략을 참조하십시오. 이러한 기술은 다중 에이전트 시스템 내 개별 에이전트 호출에도 동일하게 적용됩니다.

관측성: 블랙박스 내부 보기

다중 에이전트 시스템은 전통적인 디버깅을 불충분하게 만드는 방식으로 실패합니다. 여러 에이전트가 조정될 때, 문제는 에이전트 경계를 넘어 전파되고, 실행 경로가 예측 불가능해지며, 근본 원인을 식별하려면 분산 워크플로우에 대한 가시성이 필요합니다. LLM 시스템의 관측성은 다중 에이전트 시스템이 의존하는 전체 프로덕션 관측성 스택 — 지표, 분산 추적, 로그, SLO, 도구 비교 — 을 다룹니다. Prometheus 및 Grafana로 vLLM 및 llama.cpp 추론 엔드포인트를 계측하는 방법에 대해서는 프로덕션에서 LLM 추론 모니터링을 참조하십시오.

필수 관측성 구성 요소

1. 분산 추적

모든 에이전트 간 완전한 상호작용 그래프를 캡처하십시오. 전통적인 도구는 구성 요소가 실행 중인지 여부를 보여주지만, 다중 에이전트 디버깅은 구성 요소가 어떻게 상호작용하고 조정이 어디서 붕괴되는지 이해해야 합니다.

추적해야 할 주요 스팬:

  • 오케스트레이터 분해 단계
  • 각 워커의 실행
  • 집계 단계
  • 크로스-에이전트 통신(메쉬/스웜)

2. 블랙보드 리플레이

스웜 및 메쉬 패턴의 경우, 리플레이할 수 있는 버전 관리된 블랙보드를 유지하십시오. 이를 통해 실패로 이어진 자생적 행동을 재구성할 수 있습니다.

3. 비용 귀속

에이전트별, 단계별 토큰 소비를 추적하십시오. 과도한 리소스를 소비하는 에이전트를 식별하십시오.

4. 수렴 모니터링

스웜 및 메쉬 패턴의 경우, 시스템이 수렴하거나 발산하는지 모니터링하십시오. 다음에 대한 알림을 설정하십시오:

  • 예상 범위를 초과하는 에이전트 수
  • 임계값을 초과하는 반복 횟수
  • 시간이 지남에 따라 저하되는 출력 품질

프레임워크 지원 매트릭스

Pattern LangGraph AutoGen CrewAI OpenAI Agents SDK
Orchestrator-Worker ✅ Native ✅ Native ✅ Native ✅ Native
Sequential Pipeline ✅ Graph edges ✅ Sequential ✅ Agent chains ✅ Handoff
Fan-Out / Fan-In ✅ Superstep ✅ Group chat ✅ Crew ✅ Parallel
Hierarchical ✅ Nested graphs ✅ Hierarchical ❌ Limited ❌ Limited
Swarm ❌ Limited ✅ Swarm ❌ No ❌ No
Mesh ✅ Custom graph ✅ Group chat ❌ No ❌ No

하나로 모음: 프로덕션 예시

실제 세계의 시스템은 드물게 단일 패턴으로 깔끔하게 매핑됩니다 — 대부분의 프로덕션 배포는 워크플로우의 가장 적합한 부분을 처리하는 각 접근 방식을 결합하여 두 가지 또는 세 가지 접근 방식을 혼합합니다. AI/ML 오케스트레이션을 위한 Go 마이크로서비스과 같은 인프라 패턴은 이러한 하이브리드 아키텍처의 기초가 되는 서비스 레벨 안무 및 사가(saga) 패턴을 설명합니다.

기술적 문의를 처리하는 고객 지원 시스템을 고려하십시오:

  1. 분류(오케스트레이터-워커): incoming ticket → 오케스트레이터가 분류 → 전문가에게 라우팅
  2. 연구(팬아웃): 전문 에이전트가 병렬 쿼리 실행(지식 베이스, 티켓 히스토리, 제품 문서)
  3. 초안(시퀀셜): 연구 → 응답 초안 → 품질 검사
  4. 에스컬레이션(계층적): 품질 검사 실패 시, 시니어 에이전트로 에스컬레이션 → 인간 검토

이 하이브리드 접근 방식은 단일 패턴이 전체 워크플로우를 최적화할 수 없기 때문에 네 가지 패턴을 사용합니다. 핵심 통찰: 패턴을 구성하고, 하나의 패턴이 모든 것을 처리하도록 강제하지 마십시오.

핵심 요약

  1. 단순하게 시작하십시오. 도구와 함께한 단일 에이전트가 기본값입니다. 측정이 필요할 때만 다중 에이전트로 에스컬레이션하십시오.
  2. 문제로 패턴을 매칭하십시오. 분해를 위해 오케스트레이터-워커, 고정된 시퀀스를 위해 파이프라인, 병렬성을 위해 팬아웃, 규모를 위해 계층적, 탐색을 위해 스웜, 협력을 위해 메쉬.
  3. 실패 모드를 예상하십시오. 모든 패턴은 특정 방식으로 깨집니다. 배포 전에 완화를 설계하십시오.
  4. 비용은 비선형적으로 확장됩니다. 다중 에이전트 시스템은 토큰 소비를 증식합니다. 단일 에이전트의 2-5배 비용을 예산에 반영하십시오.
  5. 관측성은 불가결합니다. 분산 추적과 비용 귀속 없이 다중 에이전트 시스템을 디버깅하거나 최적화할 수 없습니다.
  6. 패턴을 구성하십시오. 대부분의 프로덕션 시스템은 2-3개의 패턴을 결합합니다. 하나의 패턴이 모든 것을 처리하도록 강제하지 마십시오.

다중 에이전트 풍경은 빠르게 성숙하고 있습니다. 성공하는 팀은 tradeoffs를 이해하고, 패턴을 의도적으로 선택하며, 첫날부터 관측성을 구축하는 팀입니다.

자주 묻는 질문

다중 에이전트 오케스트레이션이란 무엇인가? 다중 에이전트 오케스트레이션은 여러 AI 에이전트가 작업에 함께 작동하는 방식을 지배하는 조정 모델입니다. 선택한 패턴 — 허브-스포크, 파이프라인, 팬아웃, 계층적, 스웜, 또는 메쉬 — 는 시스템의 레이턴시, 장애 내성, 확장성 한계, 디버깅 복잡성을 결정합니다. 각 패턴은 다른 tradeoffs를 가지며 다른 방식으로 깨집니다.

프로덕션 AI 시스템에 가장 적합한 다중 에이전트 패턴은 무엇인가? 대부분의 프로덕션 시스템은 오케스트레이터-워커로 시작합니다. 이는 명확한 책임, 디버깅 가능한 제어 흐름, 예측 가능한 비용을 제공합니다. 워커 수가 5-8개를 초과하면 계층적으로, 독립적 병렬 작업이 워크로드를 지배하면 팬아웃으로 에스컬레이션하십시오. 스웜과 메쉬는 각각 탐색 워크플로우와 긴밀한 피어 협력을 위한 니치 패턴으로 남아 있습니다.

왜 다중 에이전트 파일럿의 40%가 실패하는가? NeurIPS 2025의 MAST 분류법에 따르면 세 가지 근본 원인은 명세 모호성(에이전트가 역할을 오해하거나 검증 단계를 건너뜀), 조정 붕괴(구조화되지 않은 메시징이 메시지 손실과 순환 핸드오프를 초래함), 검증 격차(에이전트 출력에 대한 독립적인 검증이 없어 오류가 통제 없이 전파됨)입니다. 각 범주는 분석된 1,600개 이상의 실행 트레이스에서 모든 실패의 약 3분의 1을 차지합니다.

다중 에이전트 시스템은 단일 에이전트보다 얼마나 더 비용이 많이 드는가? 패턴에 따라 토큰 비용의 2배에서 10배를 예상하십시오. 오케스트레이터-워커가 2-3x로 가장 저렴합니다. 팬아웃과 스웜은 에이전트가 병렬로 실행되고 각자가 독립적으로 전체 토큰 예산을 소비하기 때문에 4-10x로 가장 비쌉니다. 이러한 승수는 규모에 따라 증식합니다 — 테스트에서 $0.50였던 워크플로우가 10만 번 실행 시 월 $50,000에 달할 수 있습니다.

무언가 잘못되었을 때 다중 에이전트 시스템을 어떻게 디버깅하는가? 분산 추적부터 시작하십시오 — 실행당 하나의 추적, 각 에이전트 호출, 도구 호출, 집계 단계에 대한 스팬 포함. 스웜 및 메쉬 패턴의 경우, 블랙보드 리플레이를 구현하여 로그에서 자생적 행동을 재구성할 수 있게 하십시오. 에이전트별 비용 귀속은 프로덕션 규모에 도달하기 전에 연쇄 실패나 통제不能한 지출을 유발하는 에이전트를 식별하는 데 도움이 됩니다.

다중 에이전트 패턴이 프로세스 내 오케스트레이션 대신 A2A를 필요로 하는 시기는 언제인가? 모든 에이전트가 하나의 런타임, 저장소, 팀을 공유할 때 프로세스 내 상태를 유지하십시오. 전문가가 독립적으로 배포되거나, 서로 다른 팀 또는 벤더가 소유하거나, 호출자를 재배포하지 않고 에이전트 카드를 통해 발견되어야 할 때 경계에 A2A를 추가하십시오. 오케스트레이터-워커와 메쉬가 가장 일반적인 경계 간 형태입니다; 전체 매핑 테이블을 위해 에이전트가 경계를 교차할 때 패턴 구현을 참조하십시오.

구독하기

시스템, 인프라, AI 엔지니어링에 관한 새 글을 받아보세요.