멀티 에이전트 설계에서의 A2A와 MCP: 중견기업이 두 가지 모두 필요한 시점

이 가이드는 두 번째 에이전트가 시스템뿐 아니라 첫 번째 에이전트와도 통신해야 하는지 결정해야 하는 CTO 또는 엔지니어링 리드, 그리고 추가 프로토콜이 감사 부담을 감당할 만한 가치가 있는지 검토하는 IT 거버넌스 담당자를 위한 것입니다. 저희의 MCP 서버 가이드는 이 페이지가 이미 존재한다고 가정하는 에이전트-도구 계층을 설계하며, 에이전틱 AI 아키텍처 가이드는 하나의 에이전트 자체 루프 안에 인간 체크포인트를 배치합니다. 이 페이지는 그 두 가지 위에 있는 계층, 즉 두 번째 에이전트가 등장했을 때 무엇이 달라지는지를 다룹니다.

이 가이드에서 다루는 내용

• MCP와 A2A는 같은 문제를 해결하는가?
• 두 계층 패턴
• 중견기업은 지금 A2A가 필요한가?
• 실제 사례: 멀티 에이전트 설계로서의 주문-현금화
• 두 번째 에이전트가 호출자가 될 때 달라지는 것
• 멀티 에이전트 설계에서 AI의 역할
• 존재하는 납품 기록과 존재하지 않는 것
• 대안: 두 개 이상의 에이전트를 조율하는 다른 방법
• 이 가이드의 한계
• 자주 묻는 질문
• 다음 단계

MCP와 A2A는 같은 문제를 해결하는가?

아닙니다. MCP(Model Context Protocol)는 하나의 에이전트를 작업 수행에 필요한 도구, 데이터, 시스템에 연결합니다. 예를 들어 주문 상태 조회, CRM 업데이트, 문서 검색 등입니다. A2A(Agent2Agent)는 하나의 에이전트를 다른 에이전트에 연결합니다. 에이전트가 두 번째 에이전트의 기능을 탐색하고, 작업을 전달하며, 완료까지 추적할 수 있게 해주는 두 추론 시스템 간의 프로토콜입니다. 에이전트 하나에 도구 다섯 개를 사용하는 기업은 MCP만 필요합니다. 그 설계에서는 다른 에이전트를 탐색하거나 위임하는 요소가 없습니다.

두 계층 패턴

두 프로토콜을 함께 사용하는 대부분의 기업은 A2A를 상위에 두어 어떤 전문 에이전트가 작업의 어느 부분을 담당할지 조율하고, 각 에이전트 아래에 MCP를 배치하여 해당 부분에 필요한 시스템과 연결합니다. 어느 한 계층을 제거하면 다른 부분이 망가집니다. A2A 없이는 에이전트가 구조화된 방식으로 작업을 인계할 수 없고, MCP 없이는 위임받은 작업을 수행할 관리된 수단이 없습니다.

중견기업은 지금 A2A가 필요한가?

에이전트 하나에 도구 여러 개를 사용하는 대부분의 중견기업은 아직 A2A가 필요하지 않습니다. 단일 에이전트 설계에서는 두 번째 추론 시스템에 작업을 위임하는 요소가 없으므로, 범위가 정해지고 관리된 MCP만으로도 더 단순한 답이 됩니다. 핵심 질문은 "에이전트가 몇 개의 도구를 사용하는가"가 아니라 "서로 다른 팀이 구축하거나 소유한 별도의 에이전트가 몇 개나 작업을 거치는가"입니다.

유용한 점검 기준: 모든 도구 호출이 이미 하나의 에이전트와 그것을 승인한 한 명의 담당자로 추적될 수 있는가? 단일 에이전트 설계에서는 항상 그렇습니다. 하나의 에이전트가 전체 작업을 갖고 있기 때문입니다. 작업이 두 에이전트로 분리되는 순간—요청을 분류하는 트리아지 에이전트와 그것을 처리하는 결제 에이전트—추적도 에이전트를 넘나들어야 합니다. 그렇지 않으면 승인된 작업이 어떤 에이전트가 실제로 요청했는지의 맥락을 잃게 됩니다. 바로 그 시점이 A2A가 자리를 잡는 때입니다. 두 번째 도구가 추가될 때가 아니라, 두 번째 에이전트가 등장할 때입니다.

실제 사례: 멀티 에이전트 설계로서의 주문-현금화

저희의 주문-현금화 가이드는 주문 접수, 신용 확인, 청구서 발행, 수금 후속 조치 등 주문-현금화의 세부 단계를 에이전트가 적합한 위치와 사람이 결정을 내려야 하는 위치로 매핑합니다. 전체 프로세스에 하나의 큰 에이전트를 두는 대신 세부 단계마다 하나의 에이전트를 구축하는 기업은 정확히 이 조건에 해당합니다. 수금 에이전트가 분쟁 청구서를 결제 에이전트에 인계하거나, 접수 에이전트가 신용 확인 에이전트의 답변을 먼저 필요로 하는 상황입니다. 각 에이전트는 여전히 자신의 시스템에 대한 자체 MCP 연결이 필요하며, A2A는 서로를 탐색하고 인계 감사를 위한 충분한 맥락과 함께 작업을 전달할 수 있게 합니다.

존재하는 납품 기록과 존재하지 않는 것

Netbase는 멀티 에이전트 설계의 각 에이전트가 별도의 관리된 접근이 필요한 종류의 시스템을 구축했으며, 이 페이지가 기반으로 삼는 단일 에이전트 제어 루프와 도구 노출 계층을 설계했습니다.

• 미국 고객을 위한 멀티 테넌트 클라우드 ERP (고객명 비공개). 2020년부터 SaaS로 납품된 클라우드 ERP의 오프쇼어 개발 및 관리 파트너로서, 1단계는 CRM, 지식 베이스, 업무 및 프로젝트 관리, API 연동을 포함합니다. 이는 전문 에이전트 자체의 MCP 연결이 감싸게 될 종류의 시스템입니다.
• ERP 및 CRM 컨설팅 (고객명 비공개). Odoo 컨설팅 및 커스터마이징, 카탈로그·재고·주문·고객 데이터를 API로 동기화하는 이커머스-ERP 연동, Vtiger-ERP 업그레이드 등입니다. 각각은 개별 에이전트의 MCP 도구가 호출하게 될 정의되고 경계가 명확한 작업이며, 원시 데이터베이스 연결이 아닙니다.
• 그 외 납품된 AI, 익명 처리: 여기에 명시되지 않은 고객을 위한 검색 증강 지식 어시스턴트, 문서 AI, MLOps 파이프라인 (F072).

존재하지 않는 것. A2A 프로토콜을 사용한 납품된 멀티 에이전트 시스템, 프로덕션에서 다른 에이전트에 위임하는 에이전트, 또는 A2A와 MCP를 결합한 측정된 결과를 설명하는 공개된 Netbase 기록은 없습니다. 위의 결정 규칙, 두 계층 패턴, 순서화 단계는 Netbase의 ERP/CRM 연동 및 단일 에이전트 납품 경험(F070, F072, F076, F077)과 인용된 프로토콜 소스에서 도출된 것으로, 하나의 측정된 멀티 에이전트 프로젝트에서 비롯된 것이 아닙니다. 어떤 멀티 에이전트 또는 A2A 배포에 대해서도 기간, 비용, 정확도 또는 도입 수치를 주장하지 않습니다.

대안: 두 개 이상의 에이전트를 조율하는 다른 방법

아직 A2A를 추가하지 말아야 하는 경우. 도구가 여러 개인 단일 에이전트에 두 번째 추론 시스템이 없어 작업을 인계할 대상이 없다면 위임 프로토콜이 필요하지 않습니다. 추가하는 것은 아직 조율할 것이 없는 복잡성입니다. 두 번째 전문 에이전트가 존재하거나 확실히 계획된 후에 A2A를 추가하십시오.

Netbase 커스텀 개발에서는 고객이 해당 작업을 위해 생성된 IP를 소유하며, 대부분의 프로젝트는 검토 후 합의된 고정가 계약으로 진행됩니다. 에이전트-도구 계층은 시스템 및 API 연동과 ERP 및 CRM 개발에 있으며, 에이전트 대면 설계는 AI 연동에 있고, 에이전틱 AI 자동화와 엔터프라이즈 AI 에이전트 플랫폼을 통해 납품되며, 전문 서비스 등의 분야를 대상으로 합니다.

이 가이드의 한계

• 두 프로토콜 모두 새롭고 자주 개정됩니다. 어느 쪽에 아키텍처를 확정하기 전에 최신 사양을 확인하십시오.
• 결정 규칙과 두 계층 패턴은 시작 설계일 뿐이며, 특정 멀티 에이전트 시스템이 안전하거나 올바르게 범위가 정해졌다는 보증이 아닙니다.
• 어떤 멀티 에이전트 또는 A2A 배포에 대해서도 기간, 비용, 정확도 또는 도입 수치를 주장하지 않습니다.
• A2A를 추가해도 이 클러스터의 다른 가이드가 다루는 단일 에이전트 제어(승인, 추적, 킬 스위치)의 필요성이 없어지지 않습니다. 대체가 아닌 추가 계층입니다.

다음 단계

실제 설계에 필요한 에이전트 수와 각 에이전트가 접근해야 하는 시스템을 알려주시면, 솔루션 검토를 예약하여 위임 계층, 도구 연결, 그리고 그 전반에 걸친 승인 추적 범위를 정하겠습니다. 에이전틱 AI 자동화 서비스를 확인하거나 더 많은 Netbase 인사이트를 둘러볼 수도 있습니다.

관련 서비스 및 솔루션