당신의 멀티 에이전트 AI 시스템은 책임자가 없는 저녁 파티와 같습니다

이런 상황을 상상해 보세요. 한 시간 뒤에 저녁 손님들이 도착합니다. 네 명의 사람이 있고, 각자 유능하며, 각자 맡은 역할이 있습니다.

한 명은 그릴을 담당합니다. 한 명은 식탁을 차립니다. 한 명은 샐러드를 만듭니다. 한 명은 음악을 틀어줍니다.

30분이 지났습니다. 아무도 프로판 밸브를 열지 않아 그릴이 가열되지 않고 있습니다. 샐러드를 만드는 사람은 전달받지 못한 재료를 기다리고 있습니다. 재가열을 10분 전에 했어야 했는데 하지 않아서 에피타이저가 식어버렸습니다. DJ는 스피커를 잘못 연결하여 아기 방에 테크노 음악을 크게 틀어놓고 있습니다.

누구도 무능하지 않았습니다. 모두가 자신의 일을 알고 있었습니다. 모든 것이 무너진 이유는 조율(Coordination)을 위한 시스템이 없었기 때문입니다.

이것은 오늘날 프로덕션(Production) 환경에서 실행되는 대부분의 멀티 에이전트 AI 시스템을 거의 완벽하게 묘사하는 설명입니다.

각 에이전트는 코더(Coder), 연구원(Researcher), 플래너(Planner), 작가(Writer)로서 유능합니다. 하지만 공유 메모리(Shared memory), 의도적인 오케스트레이션(Orchestration), 그리고 적절한 상태 관리(State management)가 없다면, 유능한 에이전트들은 일관성 없는 결과를 만들어냅니다. 실패의 원인은 개별 에이전트의 지능에 있는 것이 아닙니다. 그들을 하나의 팀으로 만들어 주어야 할 아키텍처(Architecture)에 있습니다.

이 포스트에서는 프로덕션급 멀티 에이전트 시스템과 값비싼 데모(Demo)를 구분 짓는 5계층 아키텍처를 분석하고, 이 중 어느 하나라도 건너뛸 경우 직면하게 될 구체적인 실패 모드(Failure modes)를 명시합니다.

제품을 출시하기 전 멀티 에이전트 시스템이 실패하는 세 가지 방식

아키텍처를 살펴보기 전에, 실패의 분류 체계(Taxonomy)를 먼저 보겠습니다. 다음 세 가지 문제는 프로덕션 단계로 넘어가지 못한 거의 모든 멀티 에이전트 시스템에서 어떤 식으로든 조합되어 나타납니다.

혼돈 문제 (The Chaos Problem). 오케스트레이션(Orchestration)이 없다는 것은 에이전트들이 조율 없이 병렬적으로 행동한다는 것을 의미합니다. 한 에이전트가 데이터를 가져오는 동안 다른 에이전트는 그 데이터를 수정합니다. 한 에이전트가 응답을 작성하는 동안 다른 에이전트는 이미 해당 쿼리가 에스컬레이션(Escalation)이 필요하다고 결정해 버립니다. 출력값들이 서로 모순되거나, 더 나쁜 경우에는 공유 상태(Shared state)를 오염시킵니다.

건망증 문제 (The Amnesia Problem). 에이전트가 워크플로 (Workflow)의 이전 단계에서 발생한 컨텍스트 (Context)에 접근할 수 없습니다. 각 호출은 완전히 새로 시작됩니다. 방금 고객 이력을 조회한 에이전트가 메모리 계층 (Memory layer)을 명시적으로 구축하지 않는 한, 그 컨텍스트를 응답을 작성하는 에이전트에게 전달할 방법이 없습니다. 대부분의 팀은 너무 늦을 때까지 이를 구축하지 않습니다.

블랙박스 문제 (The Black Box Problem). 무언가 잘못됩니다. 어떤 에이전트가 어떤 결정을 내렸는지, 시스템이 어떤 상태였는지, 혹은 어떤 입력값이 실패를 유발했는지에 대한 추적 기록 (Trace)이 전혀 없습니다. 이를 재현할 수 없습니다. 수정할 수도 없습니다. 그저 다시 발생하는 것을 지켜볼 수밖에 없습니다.

만약 여러분의 실험 과정에서 이 중 하나라도 익숙하게 느껴진다면, 계속 읽어주십시오. 아래의 아키텍처 (Architecture)는 이 세 가지 격차를 모두 메우기 위해 설계되었습니다.

5계층 아키텍처 (The Five-Layer Architecture)

다음은 프레임워크 (Framework)입니다. 멀티 에이전트 시스템 (Multi-agent system)이 프로덕션 (Production) 환경에서 일관된 가치를 제공하기 위해서는 이 다섯 가지 계층이 모두 기능해야 합니다. 이를 하중을 견디는 벽 (Load-bearing walls)이라고 생각하십시오. 프로토타입 (Prototype)에서는 하나를 건너뛸 수 있지만, 프로덕션에서는 하나라도 건너뛸 수 없습니다.

┌─────────────────────────────────────────────────────┐
│          Layer 1: Orchestration                     │
│   Orchestrator · Classifier · Agent Registry       │
...

계층 1 — 오케스트레이션 계층 (Layer 1 — The Orchestration Layer): 당신의 AI 지휘자

이것은 저녁 파티의 혼란 문제를 해결하는 구성 요소입니다. 이것이 없다면 모두가 동시에 소리를 지르는 그룹 채팅과 같습니다. 이것이 있다면, 누가, 언제, 어떤 정보를 가지고 연주할지를 결정하는 지휘자가 있는 것과 같습니다.

오케스트레이터 (Orchestrator)는 다음을 담당합니다:

• 작업을 올바른 에이전트(agent)에게 라우팅 (Routing)
• 실행 순서 및 시퀀싱 (sequencing) 관리
• 중복되거나 충돌하는 작업 방지
• 여러 에이전트의 출력을 일관된 결과로 합성 (Synthesizing)

오케스트레이션 계층(orchestration layer) 내부에는 **분류기 (Classifier)**가 내장되어 있습니다. 이는 자연어 이해 (NLU) 또는 LLM 기반의 의도 탐지 (intent detection)를 사용하여 방금 어떤 종류의 요청이 도착했는지 이해하는 컴포넌트입니다. "이것은 리서치 에이전트가 필요합니다.", "이것은 리서치 에이전트와 라이팅 에이전트 모두가 순차적으로 필요합니다.", "이것은 모호하며 라우팅 전에 명확화 단계가 필요합니다."와 같은 판단을 내립니다.

**에이전트 레지스트리 (Agent Registry)**는 오케스트레이터의 전화번호부 역할을 합니다. 어떤 에이전트가 존재하는지, 각 에이전트가 어떤 기능 (capabilities)을 노출하는지, 그리고 각 에이전트가 현재 사용 가능한 상태인지를 알고 있습니다. 소규모 규모 (2~3개의 에이전트)에서는 이는 사소한 문제입니다. 하지만 수십 개의 전문화된 에이전트가 있는 프로덕션 규모에서는, 관리되는 레지스트리만이 모든 경로를 하드코딩하지 않고도 라우팅을 신뢰할 수 있게 유지하는 유일한 방법입니다.

Semantic Kernel과 AutoGen이 융합된 Microsoft의 Agent Framework (MAF)가 이 패턴을 구현합니다. 하지만 이 개념들은 프레임워크와 관계없이 적용됩니다. LangGraph의 노드 기반 라우팅 (node-based routing), CrewAI의 역할 기반 위임 (role-based delegation), 그리고 커스텀 오케스트레이터 모두 동일한 문제, 즉 **동적 기능 탐지 (dynamic capability discovery)를 동반한 결정론적 라우팅 (deterministic routing)**을 해결해야 합니다.

Layer 2 — 지식 계층 (The Knowledge Layer): 조직적 기억 (Institutional Memory)

에이전트에게는 두 가지 종류의 지식 접근이 필요합니다: **도메인 특화 콘텐츠 (domain-specific content)**와 **비정형 데이터에 대한 시맨틱 검색 (semantic search over unstructured data)**입니다.

**소스 베이스 (Source Bases)**는 범용 AI의 응답을 전문가 수준의 답변으로 변환해 주는 전문 콘텐츠를 저장하는 곳입니다. 정책 문서, 제품 FAQ, 규제 가이드라인, 내부 런북 (runbooks) 등이 이에 해당합니다. 구현 방식은 지식 그래프 (knowledge graphs), 문서 저장소 (document repositories), 미세 조정된 모델 (fine-tuned models) 등 다양하지만, 목표는 일관됩니다. 에이전트가 단순히 일반적인 관점에서 맞는 답변을 하는 것이 아니라, 귀하의 도메인에 대해 정확할 수 있도록 필요한 구체적인 정보를 제공하는 것입니다.

**벡터 데이터베이스 (Vector databases)**는 해당 콘텐츠에 대한 시맨틱 검색 (semantic search)을 가능하게 합니다. 고객 지원 에이전트가 "비밀번호 재설정 후 로그인 문제"를 검색할 때, 벡터 검색은 인증 상태 (authentication state)와 자격 증명 관리 (credential management) 사이의 시맨틱 관계를 이해합니다. 키워드 매칭 (Keyword matching)은 이를 이해하지 못합니다.

대부분의 팀이 실수하는 결정적인 검색 결정 사항: RAG 대 MCP는 스타일의 선호 문제가 아닙니다. 이는 기능적 구분입니다.

다음과 같은 경우 RAG를 사용하십시오:
  - 콘텐츠가 정적(static)이거나 준정적(semi-static)인 경우 (정책 문서, FAQ, 가이드)
  - 검색 관련성 (Search relevance)이 주요 품질 레버인 경우
...

"지금 SKU-123 재고가 몇 개 있나요?"는 검색 질문이 아닙니다. 이는 귀하의 ERP에 대한 API 호출입니다. 이를 RAG를 통해 라우팅하면 오래된(stale) 답변이 생성됩니다. 이를 MCP 도구 호출 (tool call)을 통해 라우팅하면 실시간 값을 생성합니다.

팀들이 저지르는 실수: 설정이 더 간단하다는 이유로 모든 곳에 RAG를 적용한 다음, 에이전트가 왜 계속 잘못된 재고 데이터를 제공하는지 디버깅하는 데 3개월을 소비하는 것입니다. 정답은 더 나은 임베딩 (embeddings)이 아닙니다. 정답은 잘못된 검색 패턴 (retrieval pattern)입니다.

레이어 3 — 에이전트 레이어 (The Agent Layer): 전문 작업자

시스템의 각 에이전트는 전문가입니다. 금융 에이전트, 코딩 에이전트, 리서치 에이전트, 고객 대응 지원 에이전트 등입니다. 각 에이전트는 해당 도메인에 맞춰 미세 조정 (fine-tuned)되거나 프롬프트 (prompted)되었으며, 지식 레이어 (knowledge layer)의 관련 하위 집합에 접근할 수 있습니다.

에이전트는 **MCP 클라이언트 (MCP Client)**를 통해 외부 도구와 통신합니다. 이는 대상 도구와 관계없이 인증을 처리하고, 연결을 관리하며, 요청을 일관된 형식으로 구성하는 표준화된 인터페이스입니다. 이러한 추상화 (abstraction) 덕분에 이를 사용하는 모든 에이전트를 다시 작성하지 않고도 기반 도구를 교체할 수 있습니다 (예: 한 검색 제공업체에서 다른 제공업체로 전환).

로컬 에이전트 vs. 원격 에이전트: 중요한 보안적 구분

이것은 대부분의 팀이 문제가 발생하기 전까지는 고려하지 않는 아키텍처 결정 사항입니다.

**로컬 에이전트 (Local agents)**는 오케스트레이터 (Orchestrator)와 동일한 실행 환경에서 실행됩니다. 이들은 인메모리 (in-memory) 방식으로 통신하며, 오케스트레이터의 신뢰 컨텍스트 (trust context)를 상속받습니다. 빠르고 지연 시간이 낮으며, 추론하기가 직관적입니다.

**원격 에이전트 (Remote agents)**는 네트워크 경계를 넘어 작동합니다. 이들은 서로 다른 보안 구역 (security zone)에 존재하거나, 다른 팀에 의해 소유되거나, 혹은 외부 서비스일 수 있습니다. 이는 로컬 에이전트에는 적용되지 않는 다섯 가지 보안 요구사항을 생성합니다:

1. 인증 (Authentication): 원격 에이전트의 출력을 수락하기 전에 해당 에이전트의 신원을 확인합니다.
2. 인가 (Authorization): 원격 에이전트가 어떤 데이터와 도구에 접근할 수 있는지 강제합니다.
3. 신뢰 경계 (Trust boundary): 원격 에이전트가 오케스트레이터와 동일한 권한을 가지고 있다고 절대 가정하지 마십시오.
...

로컬 에이전트를 같은 사무실을 공유하는 동료라고 생각하십시오. 암묵적인 신뢰와 빠른 협업이 가능합니다. 반면 원격 에이전트는 외부 계약업체가 전화를 거는 것과 같습니다. 민감한 정보를 넘겨주기 전에 이들에게는 신분증, 자격 증명 (credentials), 그리고 접근 권한 검토 (access review)가 필요합니다.

에이전트 간 (Agent-to-Agent, A2A) 프로토콜은 원격 에이전트를 위한 표준화된 통신 패턴을 처리합니다. Microsoft Entra Agent Identity는 Azure 상에서 신원 인프라 (identity infrastructure)를 제공합니다. 하지만 이는 단순한 기술적 문제를 넘어 조직적인 규율의 문제입니다. 오케스트레이션 (orchestration) 코드를 단 한 줄이라도 작성하기 전에, 어떤 에이전트가 어떤 다른 에이전트를 호출할 수 있는지에 대한 정책적 결정이 선행되어야 합니다.

계층 4 — 스토리지 계층 (The Storage Layer): 대부분의 시스템이 조용히 실패하는 지점

이 계층은 건망증 (amnesia) 문제를 해결하는 계층입니다. 또한, 팀들이 가장 먼저 구축을 소홀히 하는 계층이기도 합니다.

프로덕션급 멀티 에이전트 시스템은 세 가지 뚜렷한 유형의 영구 스토리지 (persistent storage)를 필요로 합니다:

대화 기록 (Conversation History) — 워크플로 (workflow) 전반에 걸친 모든 상호작용, 결정, 그리고 중간 출력값입니다. 이것이 있어야 7단계의 에이전트가 2단계의 에이전트가 무엇을 찾아냈는지 알 수 있습니다. 이것이 없다면 각 에이전트는 제로 상태에서 시작하게 됩니다. 이것이 있다면 전체 워크플로에 걸쳐 컨텍스트 (context)가 축적됩니다.

에이전트 상태 (Agent State) — 각 에이전트 인스턴스의 운영 상태 및 작업 구성입니다. 만약 에이전트가 작업 도중 충돌(crash)하더라도, 에이전트 상태가 있다면 복구가 가능하거나 교체된 에이전트가 정확히 중단된 지점부터 작업을 이어갈 수 있습니다. 이것이 없다면 일시적인 장애가 발생했을 때 전체 워크플로를 재시작해야 합니다.

레지스트리 저장소 (Registry Storage) — 어떤 에이전트가 존재하는지, 어떤 기능(capabilities)을 노출하는지, 현재 상태(health status)는 어떠한지, 그리고 최근 성능은 어떠한지에 대한 영구적인 메타데이터입니다. 이것이 레이어 1(Layer 1)의 에이전트 레지스트리(Agent Registry)를 뒷받침하는 요소입니다.

전형적인 실패 패턴: 팀들은 에이전트 상태를 메모리(in-memory)에 구축합니다. 개발 단계에서는 잘 작동합니다. 테스트 단계에서도 잘 작동합니다. 하지만 프로덕션 환경에서 에이전트가 처음으로 충돌하는 순간 무너집니다. 상태가 휘발성(ephemeral)이었기 때문에 워크플로를 재개할 수 없기 때문입니다.

첫날부터 영구 저장소(persistent storage)를 구축하십시오. 휘발성 상태를 중심으로 설계된 프로덕션 시스템에 이를 사후에 끼워 맞추는 것은 처음부터 올바르게 구축하는 것보다 훨씬 더 어렵습니다.

레이어 5 — 통합 및 관측 가능성 (Integration and Observability): 눈을 감고 비행하는 것을 멈추는 방법

이 레이어는 블랙박스(black box) 문제를 해결합니다. 또한 거의 예외 없이 사후 고려 사항으로 취급되곤 하며, 아무도 디버깅할 수 없는 첫 번째 프로덕션 장애가 발생한 후에야 필사적으로 끼워 맞추게 됩니다.

MCP 서버 (MCP Server) — 외부 도구들이 에이전트에게 노출하는 표준화된 인터페이스입니다. 데이터베이스, API, 웹 검색, 계산기, 코드 실행 환경 등이 이에 해당합니다. MCP 서버 패턴은 에이전트가 각기 다른 인증 모델과 실패 모드를 가진 수많은 맞춤형 통합 방식(custom integrations)을 통해 상호작용하는 대신, 인증 및 감사 제어(audit controls)가 내장된 일관된 인터페이스를 통해 외부 도구와 상호작용함을 의미합니다.

관측 가능성 (Observability) — 시스템 내 모든 에이전트 작업에 대한 실시간 가시성입니다:

• 현재 어떤 에이전트가 활성화되어 있는가?
• 어떤 작업이 진행 중인가?
• 지연 시간(Latency)의 병목 지점은 어디인가?
• 에이전트별 토큰 소비량과 비용은 얼마인가?
• 실패가 어디에 집중되어 있는가? 이것이 없다면 당신은 눈을 가리고 비행하는 것과 같습니다. 고객이 불만을 제기할 때가 되어서야 무언가 잘못되었다는 것을 알게 될 것입니다. 어떤 에이전트가 원인이었는지, 시스템이 어떤 상태였는지, 혹은 어떻게 재현할 수 있는지 알 수 없게 됩니다.

평가 계층 (Evals (Evaluation Layer)) — 시스템을 시간이 지남에 따라 더 나은 상태로 만드는 피드백 루프입니다. 에이전트들이 할당된 작업을 얼마나 정확하게 완료하고 있는가? 어디에서 오류를 범하고 있는가? 어떤 유형의 입력이 실패를 유발하는가? 이 데이터는 오케스트레이션 계층 (Orchestration Layer)과 지식 계층 (Knowledge Layer)으로 다시 전달되어 지속적인 개선을 가능하게 합니다.

평가가 없다면: 사용자가 말해줄 때까지 시스템이 고장 났음을 알 수 없습니다.
평가가 있다면: 사용자가 알아차리기 전에 시스템이 저하되고 있음을 알 수 있습니다.

평가 계층은 프로덕션 동작과 시스템 개선 사이의 루프를 닫는 방법입니다. 이것이 없다면 당신은 시스템을 반복 개선(Iterating)하는 것이 아니라, 불만이 접수되기를 기다리고 있는 것입니다.

이 아키텍처가 연구가 아닌 공학적 실용주의인 이유

이 5계층 모델을 매력적으로 만드는 것은 참신함이 아닙니다. 실제 프로덕션 배포 환경에서 나타나는 구체적인 문제들을 해결한다는 점입니다.

확장성 (Scalability) — 오케스트레이션 로직을 다시 작성하지 않고도 새로운 에이전트를 추가할 수 있습니다. 레지스트리 (Registry)가 새로운 기능을 자동으로 발견합니다. 라우팅 분류기 (Routing Classifier)는 하드코딩된 규칙 없이도 해당 기능으로 경로를 지정합니다.

디버깅 가능성 (Debuggability) — 적절한 관측 가능성 (Observability)과 지속적인 상태 (Persistent State)를 통해 무언가 실패했을 때 정확히 어떤 일이 일어났는지 추적할 수 있습니다. 모든 에이전트 작업은 로그로 남습니다. 모든 상태 전이 (State Transition)는 기록됩니다. 실패는 재현 가능합니다.

신뢰성 (Reliability) — 지속적인 에이전트 상태는 개별적인 실패가 연쇄적으로 확산되지 않음을 의미합니다. 충돌이 발생한 에이전트는 재시작될 수 있으며, 중단된 지점부터 다시 시작할 수 있습니다. 오케스트레이션 계층의 감독자 패턴 (Supervisor Pattern)은 실패가 전파되기 전에 국소적인 실패를 포착합니다.