이 문서는 GenAI 개념 섹션의 일부입니다.2025년은 AI Agent가 “데모 단계”에서 “프로덕션 단계”로 전환되는 변곡점입니다. 단일 Agent의 한계가 명확해지면서, 멀티에이전트 시스템(MAS)이 엔터프라이즈 AI의 핵심 아키텍처로 부상하고 있습니다. 이 가이드는 오케스트레이션 패턴, 프로토콜 표준화, 관측성, 메모리 아키텍처, 안전성, 시장 동향, 그리고 Vibe Coding까지 — 2025년 Agentic AI 지형의 전체 그림을 제공합니다.
참고 학습 목표
- 멀티에이전트 오케스트레이션 5대 패턴의 설계 원리와 적용 기준을 설명할 수 있다
- MCP와 A2A 프로토콜의 역할 분담과 상호보완 관계를 이해한다
- Agent 관측성(Observability)의 핵심 메트릭과 도구 생태계를 파악한다
- Agent Memory의 유형별 설계 전략을 수립할 수 있다
- 엔터프라이즈 Agent 거버넌스 프레임워크를 적용할 수 있다
- Databricks 플랫폼에서의 멀티에이전트 구현 전략을 수립할 수 있다
주의 용어 정리: 이 문서에서 “Agentic AI”는 복수의 Agent가 협업하는 시스템 전체 를, “AI Agent”는 그 시스템을 구성하는 개별 컴포넌트 를 지칭합니다. 이 구분은 Gartner, Forrester 등 주요 애널리스트 기관에서도 채택한 표준 용법입니다.
1. 멀티에이전트 오케스트레이션 패턴 — 5종 심층 비교
멀티에이전트 시스템의 성패는 “Agent를 어떻게 조율하는가”에 달려 있습니다. 2025년 현재 프로덕션에서 검증된 5가지 핵심 패턴을 비교합니다.1.1 패턴 총괄 비교
1.2 Supervisor/Router 패턴 (프로덕션 최다 채택)
원리: 하나의 Supervisor Agent가 사용자 입력의 의도(intent)를 분류 한 뒤, 해당 도메인의 전문 Agent에게 작업을 위임합니다. 전문 Agent의 결과를 수집하여 최종 응답을 생성합니다.
왜 프로덕션에서 가장 많이 쓰이는가?
- 토큰 효율성: 라우팅 단계에서 소형 모델(예: GPT-4o-mini, DBRX)을 사용하고, 전문 Agent에서만 대형 모델을 호출하면 토큰 비용을 60~80% 절감 가능
- 장애 격리: 한 전문 Agent가 실패해도 다른 Agent에 영향 없음
- 점진적 확장: 새 도메인 추가 시 전문 Agent만 추가하면 됨
- 디버깅 용이: 라우팅 로그만 보면 어떤 Agent가 호출되었는지 즉시 파악
성공 Databricks 매핑: Databricks의 Supervisor Agent(Agent Bricks)가 정확히 이 패턴입니다. Knowledge Assistant, Genie Agent 등을 하위 Agent로 등록하고, Supervisor가 라우팅합니다.
1.3 Swarm/Handoff 패턴
원리: OpenAI가 제안한 패턴으로, Agent들이 공유 블랙보드(shared context) 를 통해 상태를 공유하며, 한 Agent가 작업을 완료하면 다음 Agent에게 직접 핸드오프 합니다. 중앙 제어자 없이 Agent 간 자율적 협업이 이루어집니다. 흐름: Agent A → (handoff) → Agent B → (handoff) → Agent C- 모든 Agent가 공유 블랙보드 (Shared State) 를 통해 상태를 공유
- 탐색적 작업에 강함 (각 Agent가 자율적으로 경로 결정)
- 중앙 병목 없음
- OpenAI Agents SDK에서 네이티브 지원 (
handoff()함수)
- 무한 루프 위험 (Agent A → B → A → B…)
- 디버깅 난이도 높음 (제어 흐름이 분산)
- 토큰 소비 예측 어려움
주의 주의: Swarm 패턴은 탐색적 리서치, 브레인스토밍 등에 적합하지만, 결정론적 비즈니스 프로세스(예: 결재, 주문 처리)에는 부적합합니다. 이런 경우 Supervisor 또는 Pipeline 패턴을 사용하세요.
1.4 Hierarchical 패턴 (대규모 시스템)
원리: IBM Research에서 검증한 패턴으로, 50개 이상의 Agent 를 관리해야 하는 대규모 시스템에 적합합니다. Supervisor 패턴을 재귀적으로 중첩하여 트리 구조를 형성합니다.- Span of Control: 한 관리자 Agent가 관할하는 하위 Agent는 5~7개 이내 (인간 조직론과 동일)
- Escalation Path: 하위 Agent가 해결 못한 문제는 상위로 에스컬레이션
- Context Compression: 상위로 올릴 때 컨텍스트를 요약하여 토큰 절약
hierarchical process 모드
1.5 Collaborative/Debate 패턴
원리: Microsoft AutoGen이 대표하는 패턴으로, 2개 이상의 Agent가 다회전 대화(multi-turn conversation) 를 통해 문제를 해결합니다. “토론을 통한 합의” 메커니즘입니다. 흐름: Agent A (찬성 측) ↔ Agent B (반대 측) — 다회전 토론 → 합의 도출 / 최종 판단 적합 시나리오:- 코드 리뷰 (작성자 Agent vs 리뷰어 Agent)
- 투자 의사결정 (낙관론 Agent vs 비관론 Agent)
- 법률 검토 (규정 준수 Agent vs 비즈니스 Agent)
1.6 Pipeline 패턴 (순차 처리)
원리: 공장의 조립 라인처럼 각 Agent가 하나의 전문 단계 를 담당하고, 결과물을 다음 Agent에게 넘깁니다.- 각 단계를 독립적으로 최적화 가능 (모델, 프롬프트, 도구 각각 튜닝)
- 결정론적 실행 흐름 (디버깅 용이)
- 중간 결과물 캐싱으로 재실행 비용 절감
1.7 프레임워크별 패턴 매핑
참고 실전 권장 조합: 대부분의 엔터프라이즈 프로젝트에서는 LangGraph(오케스트레이션) + Databricks Agent Framework(거버넌스/배포/모니터링) 조합이 최적입니다. LangGraph로 복잡한 흐름을 설계하고, Databricks로 프로덕션 운영을 관리하세요.
2. 프로토콜 표준화 — MCP, A2A, 그리고 AAIF
2025년 멀티에이전트 생태계의 가장 중요한 변화는 상호운용성 프로토콜의 표준화 입니다. 더 이상 특정 프레임워크에 종속되지 않고, Agent와 도구, Agent와 Agent가 표준 프로토콜로 통신하는 시대가 열리고 있습니다.2.1 프로토콜 스택 개요
2.2 MCP (Model Context Protocol) — Agent-to-Tool 표준
MCP가 해결하는 문제:
- Agent 프레임워크마다 Tool 연결 방식이 달랐음 → N x M 통합 문제
- MCP 도입 후 → Agent는 MCP Client, Tool은 MCP Server → N + M 으로 축소
주요 MCP Server 예시: Databricks MCP Server (SQL, Unity Catalog, Vector Search), GitHub MCP Server, Slack MCP Server 등 수천 개
성공 Databricks MCP: Databricks는 공식 MCP Server를 제공합니다. SQL 실행, Unity Catalog 탐색, Vector Search 쿼리, Genie 질의 등을 MCP 프로토콜로 통합할 수 있습니다. Claude Desktop, Cursor 등에서 바로 연결 가능합니다.
2.3 A2A (Agent-to-Agent) — Agent 간 통신 표준
A2A의 핵심 개념:
MCP vs A2A — 역할이 다르다:
주의 A2A 채택이 느린 이유: A2A는 “Agent가 다른 Agent를 발견하고 협업하는” 시나리오를 전제합니다. 하지만 2025년 현재 대부분의 엔터프라이즈는 단일 벤더 스택 내에서 Agent를 운영하고 있어, 크로스 벤더 Agent 협업 수요가 아직 제한적입니다. 2026~2027년에 본격적으로 채택될 것으로 전망됩니다.
2.4 AAIF (Agentic AI Forum) — 표준화 거버넌스
2025년, Linux Foundation 산하에 AAIF (Agentic AI Forum) 가 설립되었습니다. MCP와 A2A를 포함한 Agentic AI 관련 표준을 통합 관리하는 것이 목표입니다. 참여 조직: Anthropic, Google, Microsoft, Databricks, Salesforce, SAP, AWS, Meta 등 AAIF의 표준화 스택:2.5 실전 권장사항
- 지금 당장: MCP를 적극 도입하세요. 도구 통합의 표준이 이미 확정되었습니다.
- 2025년 하반기: A2A Agent Card를 설계해두세요. 멀티벤더 Agent 협업이 시작될 때 대비할 수 있습니다.
- ACP/ANP: 아직 설계 단계이므로 관망하되, AAIF 발표를 모니터링하세요.
3. Agent Observability — 관측성과 모니터링
멀티에이전트 시스템의 가장 큰 운영 과제는 “무엇이 잘못되었는지 알기 어렵다” 는 것입니다. 단일 LLM 호출은 입력/출력만 보면 되지만, 멀티에이전트 시스템은 Agent 간 상호작용, 도구 호출 체인, 컨텍스트 전달 등 추적해야 할 대상이 기하급수적으로 늘어납니다.3.1 핵심 메트릭 체계
주의 토큰 비용의 50x 편차: 동일한 질문에 대해 Agent의 경로 선택에 따라 토큰 소비가 최대 50배 차이날 수 있습니다. 예를 들어, 단순 질문에 불필요하게 여러 Tool을 호출하거나, 대규모 컨텍스트를 반복 전달하는 경우입니다. Trajectory 분석 을 통해 이런 비효율을 탐지하고 최적화해야 합니다.
3.2 Tool Calling Accuracy — 지배적 신뢰성 이슈
2025년 프로덕션 Agent 시스템의 가장 빈번한 실패 원인 은 Tool Calling 오류입니다.3.3 Observability 도구 비교
성공 Databricks 고객 권장: MLflow Tracing 을 1차 관측 도구로 사용하세요. Databricks 환경에서 자동으로 trace가 수집되며, Unity Catalog의 거버넌스와 통합됩니다. LangGraph를 사용하는 경우 LangSmith를 보조 도구로 추가하면 개발 단계에서의 디버깅이 수월합니다.
3.4 관측성 구현 체크리스트
- 모든 Agent 호출에 trace ID 부여 (분산 추적)
- Tool Call별 성공/실패, 지연시간, 토큰 수 기록
- 태스크별 총 비용 자동 계산 및 대시보드 표시
- 이상 탐지 알림: 평균 대비 3x 이상 토큰 소비 시 알림
- 주간 Trajectory 분석 리뷰: 비용이 높은 경로 패턴 식별
- A/B 테스트: 프롬프트/모델 변경의 영향을 정량적으로 측정
4. Agent Memory 아키텍처
Agent의 “기억”은 사용자 경험과 태스크 품질을 결정하는 핵심 요소입니다. 2025년에는 단순한 대화 히스토리를 넘어, 구조화된 장기 기억과 집단 기억 이 중요해지고 있습니다.4.1 메모리 유형 분류
4.2 단기 기억 — 컨텍스트 윈도우 관리
컨텍스트 윈도우는 유한합니다. 대화가 길어지면 초기 맥락이 잘려나가면서 Agent의 성능이 저하됩니다. 최적화 전략:4.3 장기 기억 — 벡터 DB + 구조화 검색
하이브리드 검색 (Hybrid Retrieval) 이 2025년의 표준 패턴입니다.
벡터 검색만으로는 부족한 이유:
- “지난주 화요일에 논의한 예산 건” → 시간 필터링 필요
- “김 과장과의 대화에서 언급된 API 키” → 메타데이터 필터링 필요
- 의미적 유사도만으로는 정확한 사실(fact) 검색이 어려움
4.4 기술 스택 비교
참고 Databricks 고객 권장: Databricks Vector Search 를 장기 기억의 핵심 저장소로 사용하세요. Delta 테이블과 자동 동기화되므로, 기존 데이터 파이프라인에 자연스럽게 통합됩니다. 구조화 검색은 Unity Catalog의 SQL 인터페이스를 활용하여 하이브리드 검색을 구현할 수 있습니다.