▶이전글: LLM 하나로는 부족하다: 멀티 에이전트가 등장한 이유

멀티 에이전트 시스템을 설계할 때 가장 먼저 부딪히는 질문은 "에이전트들을 어떻게 연결할 것인가"입니다. 에이전트 각각의 역할을 정의하는 것만으로는 부족하고, 실행 순서와 상태 공유 방식, 전체 흐름을 제어하는 구조까지 함께 설계되어야 시스템이 안정적으로 작동합니다. 이 글에서는 에이전트 간 연결 구조를 결정하는 상호작용 패턴과 AgentContext, 그리고 실행 흐름을 통제하는 오케스트레이터와 MCP의 동작 원리를 순서대로 짚어봅니다.

• 에이전트를 어떤 순서로, 어떻게 연결할 것인가: 상호작용 패턴과 AgentContext

멀티 에이전트에서 핵심은 여러 에이전트가 어떤 방식으로 연결되어 목표를 수행하는가에 있습니다. 이 연결 구조를 상호작용 패턴(Interaction Pattern)이라고 합니다. 동일한 에이전트 집합이라도 어떤 상호작용 패턴을 적용하느냐에 따라 시스템의 안정성, 확장성, 장애 대응 방식이 달라집니다.

순차 실행 패턴(Sequential Pattern)은 하나의 에이전트가 과업을 수행한 뒤 그 결과를 다음 에이전트에 전달하는 선형 구조입니다. 이전 단계의 출력값이 곧 다음 단계의 입력값이 되므로 실행 경로가 고정되어 있고 단계별 추적이 용이합니다. 중간 단계에서 오류가 발생하면 전체 실행이 중단될 수 있으므로, 단계별 예외 처리와 재시도 정책을 함께 설계해야 합니다.

병렬 실행 패턴(Parallel Pattern)은 여러 에이전트가 동시에 실행되어 과업을 병렬로 처리하는 방식입니다. 동일한 입력을 여러 에이전트에 동시에 전달해 서로 다른 관점의 분석을 수행하거나, 상호 의존성이 낮은 여러 작업을 동시에 처리합니다. 병렬 실행 결과가 서로 상이한 경우를 대비해 우선순위 규칙이나 점수 기반 선택 로직과 같은 결과 통합 전략을 정의해야 합니다.

반복 개선 패턴(Feedback Loop Pattern)은 생성된 결과를 평가한 뒤 기준에 미달할 경우 다시 생성 단계로 되돌려 수정하는 구조입니다. 단순 재시도가 아니라 평가 결과를 근거로 다음 출력을 개선하는 순환 체계라는 점이 핵심입니다. 반복 구조는 비용과 실행 시간을 증가시킬 수 있으므로 최대 반복 횟수, 점수 개선율 임계치 등 종료 조건(Exit Condition)을 반드시 정의해야 합니다.

실무에서는 단일 패턴만 적용되는 경우가 드뭅니다. 패턴의 이름보다 중요한 것은, 각 단계가 어떤 의존 관계로 연결되고 어떤 조건에서 다음 단계가 실행되는지를 명확히 정의하는 일입니다.

이처럼 여러 에이전트가 협력하는 구조에서는 단계 간 상태를 어떻게 유지하고 공유하는지가 핵심 문제가 됩니다. 이를 해결하는 개념이 AgentContext입니다. AgentContext는 단순한 값 저장용 컨테이너가 아닙니다. 하나의 작업(Task)이 수행되는 동안 필요한 실행 상태를 체계적으로 유지하는 실행 메모리 아키텍처입니다. 과업 목표, 사용자 입력, 중간 추론 결과, 도구 실행 이력, 의사결정에 필요한 메타데이터 등을 통합해 관리합니다.

각 에이전트는 AgentContext를 참조해 현재 작업의 진행 상황과 이전 판단 근거를 확인하고, 자신의 실행 결과를 다시 컨텍스트에 반영합니다. 이는 단순한 데이터 공유가 아니라 실행 연속성을 유지하기 위한 상태 동기화 과정입니다. 컨텍스트가 분리되면 단계 간 상태 정합성이 보장되지 않아 결과가 일관되지 않을 수 있습니다. 반대로 일관된 AgentContext가 유지되면 개별 추론은 공통 상태를 기반으로 결합되어 협업적 실행 구조를 이룹니다. AgentContext는 특정 작업 범위 내에서만 유지되는 실행 상태 관리 계층으로, 장기 저장을 위한 메모리 계층과는 구분됩니다. 실무에서는 LangGraph의 State, Microsoft Semantic Kernel의 KernelContext, AutoGen의 context_variables 등 다양한 이름으로 같은 패턴이 구현되어 있습니다.

• 실행 흐름을 제어하는 방법: 오케스트레이터와 MCP

여러 에이전트의 실행 흐름을 통합 관리하는 런타임 제어 계층을 오케스트레이터(Orchestrator)라고 합니다. 오케스트레이터는 복합적인 사용자 요청을 실행 가능한 단위로 분해해 각 단계에 적합한 에이전트를 매칭하고, 순차·병렬·반복 개선 등 과업 특성에 맞는 실행 전략을 선택합니다. 또한 AgentContext에 축적된 중간 결과를 바탕으로 재시도, 분기, 대안 경로 선택을 수행하며, 네트워크 지연이나 도구 실행 실패 같은 예외 상황을 감지해 대응합니다.

오케스트레이터의 도입은 필수 조건이 아니라 아키텍처적 선택입니다. 중앙 집중형(With Orchestrator)은 하나의 제어 계층이 전체 실행 경로를 정의하고 관리하므로, 복잡한 조건 분기와 반복 구조를 체계적으로 통제할 수 있고 품질 검증과 감사 추적이 용이합니다. 분산 협력형(Without Orchestrator)은 각 에이전트가 A2A 통신이나 공유 상태 구조를 통해 직접 협업하는 방식으로, 기능 단위를 독립적으로 배포하거나 교체하기에 유리합니다. 다만 시스템 규모가 커질수록 실행 경로의 가시성과 장애 통제가 복잡해질 수 있습니다. 실무에서는 전체 흐름은 중앙에서 관리하되 전문 기능은 분산 위임하는 혼합형 구조가 일반적입니다.

오케스트레이터가 에이전트들의 실행 흐름을 제어한다면, MCP(Model Context Protocol)는 모델이 외부 도구와 상호작용하는 방식을 표준화합니다. 모델은 스스로 파일을 열거나 코드를 실행하거나 데이터베이스에 직접 접근하지 않습니다. 모델의 역할은 입력을 해석하고 어떤 도구가 필요한지 판단하는 것에 한정되며, 실제 실행은 별도의 계층에서 이루어져야 합니다. MCP는 이 역할 분리를 구조적으로 정의하는 실행 규격입니다. 모델은 판단에 집중하고, 실행은 MCP 서버가 담당하며, 도구는 실제 연산만 수행합니다.

MCP의 동작은 다섯 단계로 이루어집니다. 먼저 모델이 도구 이름과 입력 인자를 포함한 구조화된 호출 요청을 생성합니다. 이 요청은 MCP 클라이언트를 통해 MCP 서버로 전달되며, 이 과정에서 모델과 실행 환경은 물리적·논리적으로 분리됩니다. 서버는 요청을 즉시 실행하지 않고 요청 형식 검증, 도구 등록 여부 확인, 인자 유효성 검사, 실행 권한 점검의 절차를 거칩니다. 검증을 통과한 요청에 한해 도구가 호출되어 실제 연산을 수행하고, 그 결과는 서버를 거쳐 다시 모델로 전달됩니다. 모델은 이 결과를 바탕으로 최종 응답을 생성하거나 추가 도구 호출이 필요한지 다시 판단합니다.

FastMCP는 MCP 서버를 간결한 코드로 구현할 수 있는 경량 프레임워크입니다. @mcp.tool() 데코레이터가 적용된 함수는 MCP 서버에 등록되어 외부에서 호출 가능한 툴로 노출되며, 함수 이름·독스트링·타입 힌트는 툴의 메타데이터로 자동 변환됩니다. 전송 방식은 두 가지로 구분됩니다. ① stdio 방식은 표준 입출력 채널을 통해 요청과 응답을 주고받는 방식으로 추가 네트워크 구성 없이 동작해 로컬 개발 단계에서 구조를 빠르게 검증하기에 적합합니다. ② SSE(Server-Sent Events) 방식은 MCP 서버를 지속적으로 실행되는 서비스 형태로 구동하고 HTTP 기반 스트리밍 연결을 통해 통신합니다. 여러 클라이언트가 동시에 접속하거나 멀티 에이전트 환경에서 공통 MCP 서버를 공유할 때 유리한 구조입니다. 두 방식은 MCP 규격을 공유하므로 전환 시 핵심 로직을 그대로 유지할 수 있습니다.

정리하자면, 에이전트가 어떤 순서로 실행되고, 상태를 어떻게 공유하며, 외부 도구를 어떻게 호출하는지에 대한 답이 바로 상호작용 패턴, AgentContext, 그리고 MCP입니다. 이 연결 구조를 이해했다면, 다음 단계는 이 시스템을 실제 운영 환경에서 어떻게 안정적으로 유지하는가입니다.

위 컨텐츠는 서지영 저자님의
『이것이 멀티 에이전트다』의 내용을 재구성하여 제작되었습니다.