MCP와 함께 설계하는 에이전트 아키텍처

문제는 하나의 프로토콜로 끝나지 않는다

실제 기업 시스템에서 에이전트는 두 종류의 관계를 동시에 맺는다. 하나는 데이터베이스, 업무 API, 파일 저장소, GitHub 저장소, 사내 검색 시스템 같은 도구와의 관계다. 다른 하나는 구매 에이전트, 재무 에이전트, 법무 검토 에이전트처럼 다른 에이전트와의 관계다.

이 둘을 같은 문제로 보면 설계가 흐려진다. 도구 호출은 대체로 "이 입력으로 이 기능을 실행하고 결과를 돌려받는 일"에 가깝다. 반면 에이전트 협업은 "상대가 어떤 역할을 할 수 있는지 확인하고, 일을 위임하고, 진행 상태를 추적하고, 필요한 경우 추가 입력을 주고받고, 최종 산출물을 공유하는 일"에 가깝다.

그래서 A2A와 MCP는 경쟁 관계가 아니다. MCP는 에이전트가 외부 도구와 데이터를 다루는 계층을 표준화하고, A2A는 독립적인 에이전트들이 서로 일을 나누고 결과를 공유하는 계층을 표준화한다. 공식 A2A 문서도 이 조합을 명확히 설명한다. 개별 에이전트는 내부적으로 MCP를 사용해 자신의 도구와 리소스에 접근하고, 에이전트 간 협업에는 A2A를 사용한다는 패턴이다.¹

AI 생성 이미지

MCP는 에이전트의 도구 접근 계층이다

MCP(Model Context Protocol)는 모델이나 에이전트가 외부 도구, 데이터, 애플리케이션에 일관된 방식으로 연결되도록 돕는 프로토콜이다. 쉽게 말하면 에이전트가 "내가 사용할 수 있는 도구가 무엇인지", "각 도구는 어떤 입력을 받는지", "실행 결과는 어떤 구조로 돌아오는지"를 표준적인 방식으로 이해하게 해 준다.

예를 들어 고객지원 에이전트가 있다고 하자. 이 에이전트는 다음과 같은 도구를 사용할 수 있다.

• 고객 정보를 조회하는 CRM API

• 주문 이력을 확인하는 데이터베이스

• 환불 정책 문서를 읽는 파일 저장소

• 버그 이슈를 확인하는 GitHub 저장소

• 배송 상태를 확인하는 물류 시스템 API

MCP가 없다면 에이전트 개발자는 각 시스템의 인증, 호출 방식, 입력 형식, 오류 형식, 결과 파싱 방식을 따로 연결해야 한다. 연결 대상이 몇 개일 때는 가능하지만, 도구가 늘어나면 에이전트 내부는 곧 통합 코드로 가득 찬다.

MCP는 이 문제를 줄인다. MCP 서버는 도구, 리소스, 프롬프트 같은 기능을 표준 방식으로 노출한다. 에이전트는 MCP 클라이언트로 연결해 사용 가능한 도구 목록을 확인하고, 필요한 도구를 호출하고, 구조화된 결과를 받는다. 여기서 중요한 점은 MCP가 주로 "도구와 리소스에 접근하는 방법"을 다룬다는 것이다. MCP는 다른 전문 에이전트에게 업무를 위임하고 그 에이전트의 작업 상태를 장기간 추적하기 위한 계층은 아니다.

A2A는 에이전트 간 역할 분담 계층이다

A2A는 다른 문제를 다룬다. A2A의 관심사는 도구 하나를 호출하는 것이 아니라, 독립적인 에이전트가 서로를 발견하고 협업하는 방식이다. 원격 에이전트는 Agent Card를 통해 자신의 기능, 엔드포인트, 인증 요구사항, 입출력 특성을 알린다. 클라이언트 에이전트는 이를 읽고 적합한 상대에게 Message를 보내거나 Task를 생성한다. 이후 진행 상태, 추가 입력 요청, 중간 산출물, 최종 Artifact를 같은 업무 맥락에서 추적한다.

예를 들어 영업 에이전트가 대형 고객의 견적 요청을 받았다고 하자. 이 에이전트가 모든 일을 직접 처리할 필요는 없다.

• 가격 정책은 가격 책정 에이전트에게 위임한다.

• 계약 위험 검토는 법무 에이전트에게 위임한다.

• 납기 가능성은 공급망 에이전트에게 위임한다.

• 최종 승인 필요 여부는 재무 에이전트에게 확인한다.

각 전문 에이전트는 내부적으로 어떤 모델을 쓰는지, 어떤 프롬프트를 쓰는지, 어떤 도구 체인을 쓰는지 공개하지 않아도 된다. 대신 A2A로 자신이 할 수 있는 일과 작업 상태, 필요한 입력, 결과 산출물을 표준 객체로 표현한다. 이것이 A2A의 핵심이다. A2A는 원격 에이전트를 단순 함수처럼 다루지 않는다. 업무를 이해하고, 상태를 보고하고, 필요한 경우 사람의 승인이나 추가 정보를 요청할 수 있는 협업 주체로 다룬다.

Google의 A2A 발표도 이 점을 강조했다. 기업 환경에서는 서로 다른 벤더와 프레임워크로 만들어진 에이전트들이 함께 일해야 하며, A2A는 MCP를 대체하는 것이 아니라 보완하는 프로토콜로 제시되었다.²

이중 계층 아키텍처

MCP와 A2A를 함께 쓰는 기본 구조는 단순하다.

사용자 또는 업무 시스템
        │
        ▼
오케스트레이터 에이전트
        │  A2A: 업무 위임, Task 추적, Artifact 수신
        ├──────────────▶ 가격 책정 에이전트
        │                         │
        │                         └─ MCP: 가격 DB, 할인 정책 API 호출
        │
        ├──────────────▶ 법무 검토 에이전트
        │                         │
        │                         └─ MCP: 계약서 저장소, 조항 검색 도구 사용
        │
        └──────────────▶ 공급망 에이전트
                                  │
                                  └─ MCP: 재고 DB, 물류 API 호출

이 구조에서 A2A는 에이전트 사이의 수평 계층이다. 누가 어떤 일을 맡을지, 작업이 어느 상태인지, 어떤 결과가 나왔는지를 다룬다. MCP는 각 에이전트 내부의 수직 계층이다. 전문 에이전트가 자신의 업무를 수행하기 위해 어떤 도구와 데이터에 접근할지를 다룬다.

이 구분은 구현 책임을 명확하게 만든다. 오케스트레이터 에이전트는 법무 데이터베이스의 세부 스키마를 몰라도 된다. 법무 에이전트에게 A2A Task를 만들고 결과 Artifact를 받으면 된다. 법무 에이전트는 내부적으로 MCP를 사용해 계약서 저장소와 조항 검색 도구에 접근한다. 반대로 법무 에이전트는 가격 책정 에이전트의 내부 도구를 몰라도 된다. 필요하면 A2A로 협업하면 된다.

이 패턴의 장점은 세 가지다.

첫째, 권한 경계가 선명해진다. 각 에이전트는 자기 업무에 필요한 도구 권한만 가진다. 모든 도구 권한을 하나의 만능 에이전트에 몰아넣지 않는다.

둘째, 교체 가능성이 높아진다. 특정 법무 에이전트를 다른 벤더의 에이전트로 바꾸더라도 A2A 인터페이스가 유지되면 상위 흐름 전체를 다시 만들 필요가 줄어든다.

셋째, 관측과 감사가 쉬워진다. A2A Task에는 누가 어떤 일을 요청했고, 어떤 상태를 거쳤고, 어떤 산출물을 남겼는지가 남는다. MCP 호출 로그는 각 전문 에이전트 내부에서 도구 사용 근거를 추적한다. 두 로그를 연결하면 "업무 위임의 흐름"과 "도구 실행의 근거"를 분리해 볼 수 있다.

주변 표준과의 위치 비교

에이전트 아키텍처에는 A2A와 MCP만 있는 것이 아니다. OpenAPI, Arazzo, 에이전트 통신 관련 프로토콜, 분산 신원 프로토콜 같은 주변 표준도 함께 등장한다. 중요한 것은 각 표준의 위치를 섞지 않는 것이다.

OpenAPI는 전통적인 서비스 API를 설명하는 데 강하다. 어떤 HTTP 경로가 있고, 어떤 파라미터를 받고, 어떤 응답을 돌려주는지 문서화한다. 그러나 OpenAPI 자체가 장기 실행 Task, 에이전트 발견, 역할 위임, 에이전트 간 협상까지 담당하지는 않는다. OpenAPI는 서비스 API 설명 계층이고, A2A는 에이전트 협업 계층이다.

Arazzo 같은 워크플로 명세는 여러 API 호출 순서를 설명하는 데 유용하다. 정해진 절차에 따라 API를 조합해야 할 때 도움이 된다. 하지만 상대가 독립적인 에이전트이고, 중간에 추가 입력을 요구하거나 작업을 거절하거나 별도 산출물을 생성하는 경우에는 A2A의 Task 모델이 더 직접적인 표현을 제공한다.

ACP처럼 에이전트 통신 영역에서 함께 언급되는 프로토콜도 있다. 다만 기업 아키텍처를 설계할 때는 이런 프로토콜을 무조건 A2A의 대체재로 놓고 비교하기보다, 어떤 문제를 중심으로 설계되었는지 먼저 봐야 한다. 새 시스템에서 에이전트 간 위임, 상태 추적, 산출물 공유가 핵심이라면 A2A를 중심으로 검토하고, 결제·상거래·규제 감사처럼 특정 도메인의 요구가 강한 영역은 별도 확장이나 도메인 표준을 함께 검토하는 편이 자연스럽다.

분산 신원 프로토콜은 또 다른 층이다. 이것은 "이 에이전트가 정말 누구인가", "중앙 등록기관 없이 신원을 어떻게 검증할 것인가"에 초점을 둔다. A2A는 신뢰할 수 있는 통신과 인증 정보를 다룰 수 있지만, 모든 신원 체계를 대체하지는 않는다. 기업 환경에서는 OAuth, mTLS, 사내 IAM, 감사 로그 정책이 함께 필요하다. 개방형 웹 환경에서는 분산 신원 방식이 추가로 검토될 수 있다.

정리하면 다음과 같다.

일부 프로토콜 비교 자료도 실무 시스템에서는 MCP와 A2A를 계층적으로 함께 쓰고, OpenAPI나 신원 표준은 각각 API 설명과 신뢰 계층으로 배치하는 접근을 제시한다.³

기업 기본 아키텍처로의 수렴

2026년 이후의 흐름은 "하나의 프로토콜이 모든 것을 이긴다"가 아니다. 오히려 역할이 다른 프로토콜들이 개방형 거버넌스 아래에서 함께 쓰이는 방향에 가깝다.

A2A는 Google이 주도해 시작했지만 Linux Foundation 프로젝트로 옮겨지며 벤더 중립적 거버넌스를 강조하게 되었다. Linux Foundation은 A2A를 플랫폼, 벤더, 프레임워크와 무관하게 에이전트들이 안전하게 상호운용되도록 하는 개방형 프로토콜로 설명한다.⁴

MCP 역시 Agentic AI Foundation(AAIF)의 주요 프로젝트로 편입되면서 Linux Foundation의 중립적 거버넌스 흐름 안에서 다뤄지고 있다. 해당 발표는 MCP를 AI 모델이 도구, 데이터, 애플리케이션에 연결되도록 하는 범용 표준 프로토콜로 소개한다.⁵

이 흐름은 기업에 실용적인 신호를 준다. 특정 클라우드나 프레임워크 하나에 모든 에이전트 전략을 묶기보다, 내부 도구 접근은 MCP로 표준화하고, 에이전트 간 협업은 A2A로 표준화하는 구조가 기본값이 될 가능성이 높다. Google Cloud에서 구현하더라도 이 원칙은 유지된다. A2A와 MCP는 특정 클라우드 전용 기능이 아니라, 여러 실행 환경을 연결하기 위한 개방형 계층으로 설계되어야 한다.

설계할 때 지켜야 할 경계

MCP와 A2A를 함께 쓸 때 가장 흔한 실수는 두 계층을 섞는 것이다. 오케스트레이터가 모든 전문 에이전트의 내부 MCP 도구까지 직접 호출하기 시작하면, 역할 분담은 금방 무너진다. 상위 에이전트는 다시 만능 통합 계층이 되고, 전문 에이전트는 이름만 남는다.

좋은 기준은 간단하다.

• 내가 직접 소유한 도구를 호출한다면 MCP를 사용한다.

• 다른 책임 주체에게 업무 판단과 실행을 맡긴다면 A2A를 사용한다.

• 기존 서비스 API를 문서화하고 직접 호출한다면 OpenAPI를 함께 사용한다.

• 신원, 권한, 감사는 별도 보안 계층으로 설계한다.

이 기준을 적용하면 에이전트 시스템은 더 단순해진다. 각 에이전트는 자신의 도구와 데이터에 책임지고, 다른 에이전트와는 표준화된 업무 인터페이스로 협업한다. A2A는 에이전트들이 서로 말하게 해 주고, MCP는 각 에이전트가 실제 일을 수행할 수 있게 해 준다. 둘을 함께 볼 때 비로소 기업형 에이전트 아키텍처의 전체 그림이 완성된다.

참고

¹A2A and MCP: Detailed Comparison

²Announcing the Agent2Agent Protocol (A2A)

³Protocol Comparison — Agent Surface

⁴Linux Foundation Launches the Agent2Agent Protocol Project to Enable Secure, Intelligent Communication Between AI Agents

⁵Linux Foundation Announces the Formation of the Agentic AI Foundation (AAIF), Anchored by New Project Contributions Including Model Context Protocol (MCP), goose and AGENTS.md