멀티 Agent 협업 아키텍처 실전：
설계 패턴에서 프로덕션까지

왜 단일 Agent로는 부족한가

「모놀리식 Agent」——하나의 LLM이 검색·코딩·리뷰를 모두 담당——는 프로토타입은 쉽지만 프로덕션 규모에서 구조적으로 실패합니다:

1. 01

   컨텍스트 윈도우 병목: 복잡 작업의 중간 결과가 컨텍스트를 채워 후속 추론 품질이 급락.

2. 02

   전문성 희석: 하나의 Agent가 검색·코드·감사를 모두 하면 어중간해짐.

3. 03

   직렬 실행 비효율: 총 시간 = 각 단계 합. 병렬화 불가.

4. 04

   단일 장애점: 한 Agent 장애로 전체 중단. 서브 Agent 독립 업그레이드로 회피.

MLflow 2026 보고서와 AdaptOrch 논문에 따르면 문제는 모델이 아니라 오케스트레이션——토폴로지를 올바르게 고르면 더 강한 모델로 바꾸는 것보다 안정적 이득.

6대 오케스트레이션 설계 패턴

아래 6패턴으로 프로덕션 멀티 Agent 시나리오 95%+를 커버합니다.

패턴 1: 순차 파이프라인(Sequential Pipeline)

Agent A 출력 → Agent B 입력, 엄격한 선형. 적용: 글 작성, 코드 리뷰, 컴플라이언스. 총 시간 = 단계 합; 한 단계 실패 시 전체 블록.

builder = StateGraph(PipelineState)
builder.add_node("retriever", retrieval_agent)
builder.add_node("analyzer", analysis_agent)
builder.add_node("writer", writer_agent)
builder.add_edge(START, "retriever")
builder.add_edge("retriever", "analyzer")
builder.add_edge("analyzer", "writer")
builder.add_edge("writer", END)
pipeline = builder.compile()

패턴 2: 병렬 팬아웃/팬인(Fan-out / Fan-in)

여러 Agent가 독립 서브태스크를 병렬 처리, 집계 노드에서 병합. 총 시간 ≈ max(T1…Tn). LangGraph Send API + Annotated[list, operator.add] Reducer로 자동 집계.

패턴 3: 계층 슈퍼바이저-워커(Supervisor-Worker)

슈퍼바이저가 의도 식별·라우팅, Worker가 전문 작업 실행.이중 라우팅 권장: 키워드 고속 경로(<1ms, LLM 불필요) + LLM 정밀 라우팅. 사례: Replit 코드 어시스턴트, 고객 지원.

패턴 4: 스웜 협업(Swarm)

P2P 전달, 중앙 조율 없음. 라운드/합의/타임아웃으로 종료. 코드 리뷰 토론에 적합하나 프로덕션은 신중히——비결정성 높음. 계층형 대체 권장. AutoGen GroupChat에 max_round엄격한 상한 필수.

패턴 5: 블랙보드(Blackboard)

공유 구조화 워크스페이스. 전제 조건 충족 시 Agent가 능동적 읽기/쓰기. 적용: 시간/일 단위 비동기, 이종 팀 협업, 사전 라우팅 어려운 복잡 WF.

패턴 6: 하이브리드(Hybrid)

전형: Intent 라우팅 → 단순 쿼리 직답 / 복잡 보고서는 Supervisor → 병렬 리서치 팬아웃 + 품질 파이프라인(리뷰 → 사람 → 게시).

통신 프로토콜 이중 구조: MCP + A2A

2026년 두 프로토콜 모두 Linux Foundation Agentic AI Foundation에 편입:

• MCP(수직): Agent ↔ 도구/DB/API——「한 번 작성, 어디서나 사용」.
• A2A(수평): Agent ↔ Agent——작업 위임, 역량 발견(Agent Card @ /.well-known/agent.json), JSON-RPC 2.0.

A2A는 Google이 2025년 4월 OSS, 2026년 초 v1.0. Atlassian, Salesforce, SAP 등 50+ 파트너. Orchestrator 흐름: Agent Card 획득 → 스킬 검증 → message/send 위임.

관련 글: MCP가 AI 시대 HTTP가 되는 이유, 처음부터 MCP Server 개발.

관측성: 블랙박스를 투명하게

MAST 연구팀이 1,642건 실행 트레이스 분석; 더 우려되는 것은 57% 조직이 Agent를 프로덕션 가동 중, LLM 관측성 구현은 8%뿐——오류가 HTTP 200으로 반환되고 대시보드는 녹색인데 출력은 틀림.

핵심 지표: E2E 성공률 >85%, P95 지연 <30s, Agent별 오류율 <5%; 품질은 LLM-as-Judge로 completeness/accuracy/relevance/hallucination 평가. 각 호출에 correlation_id, OpenTelemetry로 전체 체인.

선정 의사결정 트리

1. Q1

   작업에 명확한 선형 의존? 예 → 서브태스크 병렬 가능? 아니오→순차 파이프라인; 예→병렬 팬아웃+파이프라인 혼합.

2. Q2

   아니오 → 의사결정 Agent 있음? 예 → 서브팀 규모 필요? 아니오→Supervisor-Worker; 예→계층형.

3. Q3

   아니오 → 장시간 비동기? 예→블랙보드; 아니오→Agent ≤5 & 종료 명확? 예→Swarm(엄격한 상한); 아니오→계층형으로 재구성.