A Comparative Study of MCP and A2A for Inter-Agent Coordination in LLM-Based Systems

기술 요약: LLM 기반 시스템의 에이전트 간 협업을 위한 MCP와 A2A의 비교 연구

문제 정의
최근 산업계의 추세는 이질적인 LLM 매개 컴포넌트들이 복잡한 과업을 수행하기 위해 협업하는 에이전트 시스템 개발을 가속화하고 있습니다. 고전적인 다중 에이전트 시스템(MAS) 문헌은 에이전시를 위한 이론적 프레임워크를 제공하지만, 현대의 LLM 기반 실무에서는 에이전트를 다단계 과업을 실행하는 소프트웨어 시스템 내의 구성 요소로 실용적으로 정의합니다. 이러한 변화는 에이전트 간의 협업, 발견 가능성(discoverability), 그리고 프로토콜 설계와 관련하여 상당한 엔지니어링 과제를 야기합니다.

두 가지 프로토콜이 개발자 커뮤니티에서 지배적인 모델로 부상했습니다. 하나는 LLM과 외부 도구/데이터 간의 연결을 간소화하기 위해 설계된 **Model Context Protocol (MCP)**이며, 다른 하나는 에이전트 간의 통신과 협업을 위해 특별히 설계된 Agent2Agent (A2A) 프로토콜입니다. 기존 문헌은 이 프로토콜들이 상호 보완적인 계층(도구 접근 vs. 에이전트 통신)을 제공한다고 제안하지만, 실무자들은 점차 MCP를 협업 인프라로 전용하여 사용하고 있습니다. 현재 MCP와 A2A가 에이전트 간 협업을 어떻게 처리하는지에 대해, 특히 프로토콜 추상화와 애플리케이션 계층 로직 사이의 협업 책임 분배 측면에서 구현에 근거한 실증적 연구가 부족한 실정입니다.

연구 방법론
저자들은 특정하고 대표적인 협업 패턴인 '다중 에이전트 소프트웨어 엔지니어링 과업'을 사용하여 MCP와 A2A를 비교하는 실증적, 구현 기반 연구를 수행했습니다.

• 과업: 자연어 프롬프트가 주어지면, Emfatic 텍extual 언어(Eclipse Modeling Framework의 일부)를 사용하여 검증된 객체 지향 도메인 모델을 생성합니다.
• 워크플로우: 시스템은 다음을 포함하는 고정된 협업 패턴(Algorithm 1)을 채택합니다:
  1. 워크플로우를 조율하는 협업 에이전트(Collaboration Agent).
  2. 모델을 생성하는 (LLM 기반) 솔루션 에이전트(Solution Agent).
  3. 문법을 검증하는 (비-LLM, Java 기반) 구문 감독 에이전트(Syntactic Supervision Agent).
  4. 요구사항에 대한 의미론적 정확성을 검증하는 (LLM 기반) 의미론적 감독 에이전트(Semantic Supervision Agent).
  5. 검증 실패 시 프롬프트 정제 및 재시도를 허용하는 반복 루프.
• 구현: 두 가지 동등한 시스템을 구축했습니다:
  • MCP 기반: 각 에이전트는 자신의 동작을 캡슐화하는 루트 레벨 도구를 가진 MCP 서버로 노출됩니다. 에이전트 간 통신은 MCP 클라이언트-서버 도구 호출을 통해 이루어집니다.
  • A2A 기반: 에이전트들은 네이티브 태스크 라이프사이클 관리, 상태 유지 상호작용 및 아티팩트 업데이트를 활용하여 A2A 메시지를 통해 통신합니다.
• 평가 기준: 구현체들은 문헌 및 산업 파트너(MOSAICO 프로젝트)로부터 도출된 7가지 요구사항(R1–R7)을 기준으로 평가되었습니다. 이는 에이전트 발견 가능성, 다중 부분 메시징, 다회차 대화, 비동기 통신, 관측 가능성, 상호 운용성 및 액세스 제어를 포함합니다.

주요 기여

1. 실증적 비교: 본 논문은 이론적 분석을 넘어 실질적인 엔지니어링 트레이드오프를 제시하기 위해 동일한 협업 시나리오를 MCP와 A2A를 사용하여 구체적으로 나란히 구현하여 비교합니다.
2. 복잡도 분석: 연구는 구현 및 협업 오버헤드를 정량화하여, A2A 구현이 MCP 구현에 비해 약 51% 더 많은 코드 라인(1898행 vs. 1255행)을 필요로 하며, 훨씬 더 많은 협업 프리미티브(10개 vs. 4개)와 상호작용당 단계(6단계 vs. 2단계)를 사용함을 밝혀냈습니다.
3. 요구사항 매핑: 저자들은 각 프로토콜이 특정 엔지니어링 요구사항을 어떻게 충족하는지 체계적으로 평가하여, 프로토콜 수준의 추상화가 존재하는 지점과 애플리케이션 계층 로직이 보완해야 하는 지점을 명확히 합니다.

결과

• MCP 성능: MCP는 낮은 협업 복잡도를 가진 경량 구현 모델을 보여주었습니다. 에이전트 발견 가능성, 다중 부분 메시징, 비동기/스트리밍 통신, 상호 운용성 및 액세스 제어를 성공적으로 지원했습니다. 그러나 다회차 대화(R3) 및 태스크 라이프사이클 관리에 대한 네이티브 지원이 부족했습니다. 이러한 문제(예: 대화 상태, 재시도 로직)는 애플리케이션 계층에서 명시적으로 구현되어야 했습니다.
• A2A 성능: A2A는 태스크, 라이프사이클 상태(예: input-required, completed), 아티팩트 관리에 대한 프로토콜 수준의 추상화를 통해 상태 유지형 다회차 협업에 대한 풍부한 네이티브 지원을 제공했습니다. 이는 상태 추적을 위한 애플리케이션 계층의 오케스트레이션 로직 필요성을 줄여주었습니다. 그러나 이러한 기능은 상당히 높은 구현 및 협업 복잡성이라는 비용을 수반했습니다.
• 관측 가능성 (R5): 두 프로토콜 모두 엔드 투 엔드 관측 가능성을 위한 네이티브 프로토콜 수준의 트레이싱이나 슈퍼 태스크 ID를 제공하지 않았습니다. 두 경우 모두 콜백이나 제3자 라이브러리를 통해 외부 도구(예: Langfuse, OpenTelemetry)와 통합하는 과정이 필요했습니다.

의의 및 주장
저자들은 본 연구를 결정적인 벤치마크나 보편적인 프로토콜 우월성에 대한 주장이라기보다 하나의 실증적 경험 보고서로 규정합니다. 결과는 좁고 대표적인 협업 패턴(반복적인 과업 위임 및 검증)에 기반한 설계 관찰로 제시됩니다.

본 논문의 결론은 다음과 같습니다:

• MCP는 개발자가 협업 관련 사항(상태 관리, 태스크 라이프사이클)을 애플리케이션 계층에서 명시적으로 구현할 의사가 있다면, 경량 모델이 선호되는 제약된 LLM 기반 시스템의 에이전트 간 협업에 적합합니다.
• A2A는 복잡하고 상태를 유지하는 다회차 상호작용에 대해 우수한 네이티브 지원을 제공하지만, 상당한 구현 오버헤드를 발생시킵니다.
• 프로토콜의 선택은 근본적으로 협업 책임의 분배를 결정합니다: A2A는 이러한 책임을 프로토콜로 밀어내고, MCP는 이를 애플리케이션으로 밀어냅니다.

본 연구는 한 프로토콜이 모든 다중 에이전트 시스템에 대해 보편적으로 "더 낫다"고 주장하지 않습니다. 대신, 구현 복잡도와 프로토콜 추상화의 풍부함 사이의 트레이드오프를 강조하며, 프로토콜의 적합성은 대상 시스템의 특정 협업 패턴과 엔지니어링 제약 조건에 달려 있음을 시사합니다. 향후 연구 과제로 구조가 사전에 고정되는 것이 아니라 런타임에 합성되는 동적인 LLM 주도형 협업에 대한 조사를 꼽았습니다.