제가 구축한 모든 멀티 에이전트 시스템(Multi-Agent System)은 하나의 에이전트, 하나의 런타임(Runtime), 하나의 도구 세트를 가진 모놀리스(Monolith)로 시작되었습니다. 데모용으로는 작동합니다. 하지만 두 번째 에이전트를 추가하고, 세 번째를 추가하면 갑자기 모든 실패가 전체 시스템을 무너뜨립니다.

본능적으로 에이전트를 수정하려 합니다. 더 나은 프롬프트(Prompt), 더 많은 컴퓨팅 자원, 더 똑똑한 모델을 찾는 식이죠. 하지만 진짜 문제는 에이전트가 아닙니다. 그 아래에 있는 아키텍처(Architecture)입니다.

실제 워크로드(Workload)를 견뎌내는 프로덕션급 멀티 에이전트 시스템을 구축한 끝에, 저는 각 구성 요소를 독립적으로 유지하고 실패를 격리할 수 있는 4계층 모델에 도달했습니다.

4가지 계층

• **에이전트 (Agents)**는 작업을 오케스트레이션(Orchestrate)합니다. 각 에이전트는 하네스(Harness, 지침 및 도구), 런타임(Runtime, 실행 환경), 소유자(Owner, 유지 관리자), 그리고 역할과 경계에 대한 명확한 정의를 가집니다.

• **모델 (Models)**은 지능을 제공합니다. 모든 에이전트가 가장 비싼 모델을 필요로 하는 것은 아닙니다. 복잡한 작업을 계획하는 코디네이터(Coordinator)는 프런티어 모델(Frontier model)을 사용할 수 있지만, 출력을 포맷팅하는 리포터(Reporter)는 그럴 필요가 없습니다. 모델 라우팅(Model routing)과 폴백 체인(Fallback chains)은 비용을 획기적으로 절감합니다.

• **도구 (Tools)**는 에이전트가 할 수 있는 일을 확장합니다. 내장된 도구는 에이전트에게 기본적인 능력을 부여합니다. MCP 서버의 외부 도구는 데이터베이스, API 및 서비스에 대한 접근 권한을 제공합니다. 도구 거버넌스(Tool governance)는 에이전트가 권한이 있는 도구만 호출하도록 보장합니다.

• **상태 (State)**는 메모리입니다. 각 에이전트는 자신만의 상태 파티션(State partition)을 소유합니다. 어떤 에이전트도 다른 에이전트의 파티션에 쓰기를 수행하지 않습니다. 공유 없는 소유권(Shared-nothing ownership) 방식은 실패가 격리된 상태로 유지되도록 합니다.

이 계층들은 에이전트 간 통신을 위한 A2A(Agent2Agent) 및 도구 발견을 위한 MCP와 같은 프로토콜을 통해 연결됩니다. Azure에서는 Foundry가 런타임, 하네스, 도구 및 오케스트레이션을 하나의 관리형 서비스로 결합하지만, 아키텍처 자체는 플랫폼에 구애받지 않습니다(Platform-agnostic).

핵심 통찰: 모든 시스템이 4개 계층을 모두 필요로 하는 것은 아닙니다. 어떤 솔루션은 2개를 사용하고, 어떤 것은 3개를 사용합니다. 패턴(Patterns)이야말로 구성 요소들을 결합하여 실제 환경에서 작동하는 무언가로 만드는 핵심입니다.

전체 아키텍처를 알고 싶으신가요? zulmehdi.blog (https://zulmehdi.blog/4-layer-multi-agent-enterprise-architecture-azure/)에서 전체 포스트를 읽어보세요.