A2A 대 MCP: AI 에이전트가 실제로 두 프로토콜을 모두 필요로 할까?

MCP는 에이전트에 도구를 제공합니다. A2A는 에이전트에 동료(peer)를 제공합니다.

Page content

AI 에이전트 아키텍처가 두 개의 레이어로 나뉘기 시작하고 있습니다.

하나는 AI 어시스턴트에게 도구, 데이터, API, 파일, 데이터베이스, 검색 시스템, 캘린더, 티켓팅 시스템 및 기타 외부 기능에 대한 접근 권한을 부여하는 것과 관련됩니다. 바로 여기서 MCP(Model Context Protocol)가 그 역할을 합니다.

다른 하나는 하나의 AI 에이전트가 다른 팀, 프레임워크, 벤더 또는 조직에서 구축된 또 다른 AI 에이전트를 발견하고, 소통하며, 작업을 위임하고 협력하도록 하는 것과 관련됩니다. 바로 여기서 A2A(Agent-to-Agent)가 그 역할을 합니다.

짜증 나는 점은 이 두 프로토콜이 종종 동일한 문제를 해결하는 것처럼 논의된다는 것입니다. 하지만 사실 그렇지 않습니다. 가장자리에서 일부 겹치는 부분이 있지만, 대부분의 혼란은 이 겹치는 부분에서 비롯됩니다. 하지만 명확한 정신적 모델(mental model)은 간단합니다.

MCP는 주로 에이전트와 도구의 연결을 담당하고, A2A는 주로 에이전트와 에이전트의 연결을 담당합니다.

A2A and MCP protocol architecture — AI agents connected via A2A, each accessing tools via MCP

이것이 모든 AI 시스템이 둘 다 필요하다는 의미는 아닙니다. 사실, 대부분의 소규모 에이전트 프로젝트는 MCP로 시작하고 실제 다중 에이전트 경계가 생기기 전까지는 A2A를 무시하는 것이 좋습니다. 하지만 별도로 배포되는 에이전트, 전문 에이전트, 벤더 에이전트 또는 장기적으로 실행되는 위임 작업이 포함된 대규모 에이전트 시스템을 구축하고 있다면 A2A가 합리적인 선택이 됩니다.

이 글에서는 차이점, 겹치는 부분, 아키텍처적 트레이드오프 및 실제로 둘 다 필요한 시기에 대해 설명합니다.

MCP란 무엇인가?

MCP는 Model Context Protocol(모델 컨텍스트 프로토콜)의 약자입니다.

이는 AI 애플리케이션 및 에이전트를 외부 도구, 리소스 및 프롬프트에 연결하기 위한 오픈 프로토콜입니다. 실질적으로 MCP는 데스크톱 어시스턴트, IDE, 코딩 에이전트 또는 채팅 애플리케이션과 같은 AI 호스트가 하나 이상의 MCP 서버에 연결할 수 있게 합니다.

MCP 서버는 다음과 같은 기능을 노출할 수 있습니다.

  • 도구(Tools): 모델이 사용할 수 있는 호출 가능한 함수
  • 리소스(Resources): 파일, API 데이터, 문서 또는 데이터베이스 레코드와 같은 읽기 가능한 컨텍스트
  • 프롬프트(Prompts): 재사용 가능한 프롬프트 템플릿 또는 워크플로우

공식 MCP 아키텍처는 호스트, 클라이언트 및 서버 모델에 기반합니다.

MCP 호스트는 사용자가 상호작용하는 애플리케이션입니다. MCP 클라이언트는 특정 MCP 서버와의 연결을 유지하는 프로토콜 구성 요소입니다. MCP 서버는 클라이언트에게 기능을 노출합니다.

예를 들어, 코딩 어시스턴트는 다음과 같은 서버에 연결할 수 있습니다.

  • 파일시스템 MCP 서버
  • GitHub MCP 서버
  • 데이터베이스 MCP 서버
  • Sentry MCP 서버
  • Slack MCP 서버

사용자의 관점에서 어시스턴트는 더 유용해집니다. 시스템 아키텍처의 관점에서 어시스턴트는 외부 컨텍스트 및 작업에 대한 제어된 접근 권한을 얻게 됩니다.

MCP의 주요 가치는 바로 이것입니다. AI 애플리케이션이 도구와 컨텍스트에 도달하는 방식을 표준화합니다.

MCP는 도구 통합으로 이해하는 것이 가장 좋습니다

MCP는 도구뿐만 아니라, 도구를 통해 가장 쉽게 이해할 수 있습니다.

MCP가 없으면 각 AI 애플리케이션은 각 외부 시스템마다 사용자 정의 통합 코드가 필요합니다. 하나의 에이전트 프레임워크는 자체 플러그인 형식을 가지고 있고, 다른 하나는 자체 도구 스키마를 가지고 있으며, 또 다른 하나는 다른 API 래퍼 패턴을 사용합니다. 모든 통합은 매번 다시 구축됩니다.

MCP는 이러한 낭비를 줄이려 합니다.

도구 제공자가 MCP 서버를 노출하면, 많은 MCP 호환 클라이언트가 이를 사용할 수 있습니다. 개발자가 내부 시스템을 위해 MCP 서버를 구축하면, 여러 AI 애플리케이션이 이에 연결할 수 있습니다. Go 언어로 MCP 서버 구현하기 및 Python으로 MCP 서버 구현하기에 대한 실용적인 구현 가이드는 프로토콜이 중대한 역할을 수행하면 통합 레이어가 얼마나 간단해질 수 있는지를 보여줍니다.

MCP가 이렇게 빠르게 중요해진 이유입니다. 이는 지루하지만 고통스러운 통합 문제를 해결합니다.

그리고 지루한 통합 문제는 내구성 있는 표준이 탄생하는 곳입니다. 바로 누구나 어쩔 수 없이 반복해야 하는 작업을 줄여주기 때문에 살아남는 표준들입니다.

A2A란 무엇인가?

A2A는 Agent2Agent Protocol(에이전트 대 에이전트 프로토콜)의 약자입니다.

이는 독립적인 AI 에이전트 시스템 간의 통신 및 상호 운용성을 위한 오픈 표준입니다. 개별 구성 요소인 에이전트 카드(Agent Cards), 작업 수명 주기, 메시지, 부분(Parts) 및 결과물(Artifacts)에 대해 더 깊이 살펴보고 싶다면 A2A 프로토콜이란? 에이전트 카드 및 작업 설명에서 각 개념을 자세히 확인할 수 있습니다. 공식 A2A 사양은 이 프로토콜을 다른 프레임워크, 언어 또는 벤더로 구축된 에이전트가 공통 상호작용 모델을 통해 소통할 수 있는 방법으로 설명합니다.

여기서 핵심 구절은 “독립적인 에이전트 시스템"입니다.

A2A의 주된 목적은 하나의 어시스턴트에게 계산기, 데이터베이스 또는 파일 시스템에 대한 접근 권한을 부여하는 것이 아닙니다. 이는 자체 기능, 상태, 정책, 작업 모델 및 백그라운드에서 자체 도구를 가진 다른 에이전트와 하나의 에이전트가 소통하는 것과 관련됩니다.

A2A 에이전트는 에이전트 카드를 통해 자신이 수행할 수 있는 작업을 광고할 수 있습니다. 다른 에이전트 또는 클라이언트는 이 기능을 발견하고, 작업을 전송하며, 메시지를 주고받고, 결과물을 수신하여 작업 수명 주기를 추적할 수 있습니다.

A2A는 다음과 같은 개념을 도입합니다.

  • 에이전트 카드
  • 에이전트 및 클라이언트
  • 작업
  • 메시지
  • 부분
  • 결과물
  • 작업 상태
  • 스트리밍 및 비동기 작업

이러한 개념들을 종합하면, A2A는 단순한 도구 호출 프로토콜보다 에이전트 협업 프로토콜처럼 느껴집니다. 이는 에이전트가 정체성, 상태 및 다른 에이전트와의 지속적인 관계를 가진다는 아이디어를 중심으로 설계되었습니다.

A2A는 에이전트 협업으로 이해하는 것이 가장 좋습니다

사용자가 엔터프라이즈 어시스턴트에게 다음과 같이 요청한다고 상상해 보세요.

“일본 시장 진입 브리핑을 준비하세요. 법적 고려 사항, 가격 리스크 및 출시 프로젝트 계획을 포함하세요.”

간단한 어시스턴트는 모든 것을 스스로 시도할 수 있습니다. 하지만 더 큰 에이전트 시스템은 작업의 일부를 위임할 수 있습니다.

  • 연구 에이전트가 시장 정보를 수집합니다.
  • 법률 에이전트가 규제 고려 사항을 확인합니다.
  • 재무 에이전트가 가격 리스크를 추정합니다.
  • 프로젝트 계획 에이전트가 배송 계획을 생성합니다.
  • 작성 에이전트가 최종 브리핑을 조립합니다.

만약 이러한 에이전트들이 하나의 코드베이스 내부에 있는 내부 함수라면 A2A가 필요하지 않을 수 있습니다. 함수나 서비스를 직접 호출하면 됩니다.

하지만 이러한 에이전트들이 독립적인 시스템이고, 다른 팀이나 벤더가 소유하고 있다면 표준 에이전트 대 에이전트 프로토콜이 유용해집니다.

이것이 A2A의 사용 사례입니다.

A2A vs MCP: 간단한 차이점

가장 간단한 비교는 다음과 같습니다.

질문 MCP A2A
주요 관계 에이전트에서 도구로 에이전트에서 에이전트로
주요 목적 AI 앱을 도구, 데이터 및 프롬프트에 연결 독립적인 에이전트가 소통하고 협력하도록 허용
작업의 전형적 단위 도구 호출 또는 리소스 읽기 작업, 메시지, 결과물, 위임
가장 적합한 경우 도구 통합 다중 에이전트 상호 운용성
예시 에이전트가 데이터베이스 도구를 호출함 연구 에이전트가 법률 에이전트로 위임함
범위 컨텍스트 및 기능 접근 에이전트 조정 및 작업 교환

이 표는 완벽하지 않지만 초기 정신적 모델을 구축하는 데 유용합니다. 요컨대, MCP는 “이 AI 애플리케이션은 외부 기능에 어떻게 접근하는가?“라는 질문에 답하고, A2A는 “이 에이전트는 다른 에이전트와 어떻게 협력하는가?“라는 질문에 답합니다.

이 구별은 중요합니다. 도구 통합과 에이전트 협업에는 서로 다른 실패 모드가 있습니다. 잘못된 도구 호출은 잘못된 데이터를 반환하거나 잘못된 파일을 수정할 수 있지만, 잘못된 에이전트 위임은 책임 사슬을 불분명하게 만들거나, 민감한 컨텍스트를 누출하거나, 에이전트 간에 루프를 발생시키거나, 작업을 중복하거나, 아무도 감사할 수 없는 결과물을 생성할 수 있습니다. A2A는 아키텍처에서 한 단계 더 높은 곳에 위치하며, 그 실패 모드는 그에 따라 더 높은 결과를 초래합니다.

개발자들이 A2A와 MCP를 혼동하는 이유

이 혼란은 이해할 만합니다.

많은 MCP 서버가 단순한 도구가 아닙니다. 일부 MCP 서버는 다단계 작업을 수행할 수 있습니다. 일부는 에이전트처럼 보이는 고급 기능을 노출합니다. MCP 서버는 계획 서비스, 검색 시스템 또는 심지어 다른 LLM 기반 워크플로우를 감쌀 수 있습니다.

이 시점에서 경계가 모호해집니다.

research_topic이라는 이름의 MCP 도구가 복잡한 연구 워크플로우를 수행한다면, 그것은 도구인가 에이전트인가?

솔직한 답은 아키텍처적으로 상황에 따라 다르다는 것입니다.

호스트가 이를 도구 스키마를 가진 호출 가능한 기능으로 취급한다면, 그것은 도구로서 기능합니다.

자신의 정체성, 기능, 작업 수명 주기, 메시지, 결과물 및 위임 행위를 가진다면, 그것은 에이전트로 보이기 시작합니다.

이것이 “A2A vs MCP"가 종교적인 논쟁이 될 때 잘못된 프레임인 이유입니다. 더 나은 프레임은 다음과 같습니다.

  • 이 외부 기능은 도구로 모델링하는 것이 가장 좋은가?
  • 아니면 독립적인 에이전트로 모델링하는 것이 가장 좋은가?

이 결정이 프로토콜 선택을 주도해야 합니다.

MCP만 사용하는 경우

대부분의 AI 프로젝트는 MCP만으로 시작해야 합니다. 이는 다소 주관적인 입장이나 실용적인 것입니다.

코딩 어시스턴트, 내부 챗봇, 로컬 AI 워크플로우, 개인 자동화 에이전트 또는 간단한 엔터프라이즈 어시스턴트를 구축하고 있다면, 첫 번째 문제는 보통 에이전트 대 에이전트 협업이 아닙니다. 첫 번째 문제는 도구 접근입니다.

어시스턴트에게 파일을 읽고, 데이터베이스를 쿼리하고, 문서를 검색하고, API를 호출하고, 티켓을 열고, 로그를 요약하고, metriics를 검사하거나, 레코드를 업데이트하도록 해야 합니다.

MCP는 이를 매우 잘 지원합니다.

다음과 같은 경우 MCP만 사용하세요.

  • 에이전트가 주로 도구와 데이터에 접근해야 할 때
  • 호스트 애플리케이션을 제어할 때
  • 대부분의 통합을 제어할 때
  • 외부 시스템이 실제로 자율 에이전트가 아닐 때
  • 워크플로우가 대부분 동기식이거나 단시간에 실행될 때
  • 일반적인 도구 호출로 충분할 때
  • 에이전트 발견이 필요하지 않을 때
  • 에이전트 간 작업 상태가 필요하지 않을 때
  • 독립적인 에이전트로부터의 결과물이 필요하지 않을 때

많은 시스템에 대해 MCP와 좋은 애플리케이션 아키텍처면 충분합니다. 많은 팀이 실제로는 도구를 사용하는 어시스턴트일 뿐인 시스템에 A2A를 과도하게 설계하지만, 이는 프로토콜의 문제가 아닙니다. 어떤 프로토콜로도 해결할 수 없는 아키텍처 дисциплина(규율) 문제입니다.

A2A만 사용하는 경우

A2A만 사용하는 시스템은 드물지만 존재할 수 있습니다.

시스템이 주로 에이전트 간의 통신에 관한 경우, 각 에이전트가 이미 내부적으로 자체 도구를 관리한다면 MCP 없이 A2A를 사용할 수 있습니다.

예를 들어:

  • 전문 에이전트의 마켓플레이스
  • 벤더 간 에이전트 통합
  • 조직 간 워크플로우
  • 각 에이전트가 자체 개인 도구 체인을 가진 다중 에이전트 시스템
  • 클라이언트가 내부 도구 세부 사항을 알 필요가 없는 위임 네트워크

이 모델에서 A2A는 독립적으로 관리되는 에이전트 간의 공개 경계입니다. 에이전트 A는 에이전트 B가 백그라운드에서 PostgreSQL, Elasticsearch, MCP, LangChain, 사용자 정의 API 또는 셸 스크립트를 사용하는지 알 필요가 없습니다. 에이전트 A는 에이전트 B가 무엇을 할 수 있는지, 작업을 어떻게 보내야 하는지, 결과를 어떻게 받아야 하는지만 알면 됩니다.

이는 깔끔한 추상화입니다.

다음과 같은 경우 A2A만 사용하세요.

  • 에이전트를 독립적인 서비스로 노출할 때
  • 호출자가 에이전트의 내부 도구를 알 필요가 없을 때
  • 에이전트 기능 발견이 중요할 때
  • 직접 도구 접근보다 위임이 더 중요할 때
  • 작업이 장기간 실행될 수 있을 때
  • 결과에 결과물이 포함될 수 있을 때
  • 에이전트가 다른 벤더나 팀에 의해 구축되었을 때

A2A는 독립적으로 소유된 에이전트가 내부 도구 체인을 노출하지 않고 작업과 결과물을 교환해야 하는 시스템 경계에서 가장 강력합니다. 이는 각 에이전트 런타임의 모든 레이어에 연결해야 하는 프로토콜이 아닙니다.

A2A와 MCP를 모두 사용하는 경우

가장 흥미로운 아키텍처는 A2A vs MCP가 아닙니다. A2A plus MCP입니다.

이 패턴에서 에이전트는 다른 에이전트에게 A2A 인터페이스를 노출하지만, 내부적으로는 도구에 접근하기 위해 MCP를 사용합니다.

이는 두 개의 깔끔한 레이어를 제공합니다.

  • 외부의 A2A: 에이전트가 서로 소통하는 방식
  • 내부의 MCP: 각 에이전트가 도구, 데이터 및 서비스에 접근하는 방식

아마도 가장 내구성 있는 정신적 모델일 것입니다.

고객 지원 에이전트는 A2A 인터페이스를 노출할 수 있습니다. 다른 에이전트는 지원 관련 작업을 이 에이전트로 위임할 수 있습니다. 내부적으로 지원 에이전트는 Zendesk, Slack, 문서 검색, CRM 조회 및 내부 정책 검색을 위한 MCP 서버를 사용합니다.

DevOps 에이전트는 A2A 인터페이스를 노출할 수 있습니다. 다른 에이전트는 사건을 조사하도록 요청할 수 있습니다. 내부적으로 Prometheus, Grafana, GitHub, Kubernetes, 로그 및 클라우드 API를 위한 MCP 서버를 사용합니다.

재무 에이전트는 A2A 인터페이스를 노출할 수 있습니다. 다른 에이전트는 예산 분석을 요청할 수 있습니다. 내부적으로 스프레드시트, 회계 시스템, 청구서 데이터베이스 및 예측 모델을 위한 MCP 서버를 사용합니다.

이 패턴은 에이전트 간의 깔끔한 경계를 유지합니다. 다른 에이전트는 모든 도구에 직접 접근할 필요가 없습니다. 그들은 전문 에이전트와 소통하고, 해당 에이전트가 작업을 완료하는 데 필요한 도구를 내부적으로 결정합니다.

실제 조직도 대개 이렇게 작동합니다. 모든 사람에게 프로덕션 데이터베이스에 대한 직접 접근 권한을 주지 않습니다. 해당 도메인을 담당하는 팀이나 서비스에 요청합니다.

참조 아키텍처: 외부의 A2A, 내부의 MCP

실용적인 다중 에이전트 아키텍처는 다음과 같을 수 있습니다.

User
  |
  v
Primary assistant or orchestrator
  |
  |-- A2A --> Research agent
  |              |
  |              |-- MCP --> Web search
  |              |-- MCP --> Document store
  |
  |-- A2A --> Coding agent
  |              |
  |              |-- MCP --> GitHub
  |              |-- MCP --> Filesystem
  |              |-- MCP --> CI system
  |
  |-- A2A --> DevOps agent
                 |
                 |-- MCP --> Metrics
                 |-- MCP --> Logs
                 |-- MCP --> Kubernetes

이 설계에서 A2A는 에이전트 간 위임을 처리하고, MCP는 각 에이전트와 그 도구 간의 통합을 처리합니다. 오케스트레이터는 각 전문가가 사용할 수 있는 모든 도구를 알 필요가 없습니다. 오케스트레이터는 어떤 유형의 작업을 어떤 에이전트가 담당하는지만 알면 되므로, 도구 과부하를 줄이고 전체 아키텍처를 더 모듈화할 수 있습니다. 이 오케스트레이터 레이어의 내부 토폴로지(허브-스포크, 계층적 트리, 팬아웃 또는 메시 사용 여부)는 다중 에이전트 오케스트레이션 패턴에서 다루는 별도의 설계 결정입니다. 프로덕션 어시스턴트 내부에서 추론, 메모리, 라우팅 및 도구가 어떻게 결합되는지에 대한 더 깊은 설명은 AI 어시스턴트 아키텍처: LLM, 메모리, 도구, 라우팅, 관찰성에서 이러한 레이어를 자세히 다룹니다.

A2A가 과도한 경우

“다른 에이전트"가 실제로는 그냥 함수일 때 A2A는 과도합니다.

애플리케이션이 몇 가지 도구를 호출하는 하나의 LLM 워크플로우를 가지고 있다면, 최신 것처럼 들린다고 해서 A2A를 추가하지 마세요. Python 함수, HTTP 엔드포인트, 큐 또는 MCP 도구가 충분할 수 있습니다.

다음과 같은 경우 A2A가 너무 많을 수 있습니다.

  • 에이전트가 하나뿐일 때
  • 모든 구성 요소가 하나의 코드베이스에 있을 때
  • 워크플로우가 짧고 동기식일 때
  • 발견이 필요하지 않을 때
  • 독립적인 작업 상태가 필요하지 않을 때
  • 별도의 에이전트 정체성이 필요하지 않을 때
  • 서드파티 에이전트를 기대하지 않을 때
  • 벤더 또는 프레임워크 상호 운용성이 필요하지 않을 때

프로토콜은 무료가 아닙니다. 개념, 인프라, 디버깅 표면, 보안 문제 및 운영 비용을 추가합니다. 지루한 API 또는 간단한 함수 호출이 때로는 더 나은 엔지니어링 선택이며, 필요성보다는 습관적으로 A2A를 선택하는 것 자체가 일종의 과도한 설계입니다. 단순한 옵션을 선택하는 것은 A2A에 반대하는 것이 아니라, 아키텍처를 지지하는 것입니다.

MCP가 충분하지 않은 경우

MCP는 명확하게 에이전트인 것들을 나타내는 데 사용될 때 부족해지기 시작합니다.

예를 들어, MCP 서버가 다음과 같은 도구를 노출한다고 가정해 보세요.

complete_enterprise_procurement_review

이 도구는 다음과 같은 작업을 수행합니다.

  • 벤더 데이터 읽기
  • 정책 규칙 확인
  • 명확화 질문하기
  • 법적 검토 위임
  • 리스크 보고서 생성
  • 여러 결과물 반환
  • 20분간 실행
  • 작업 상태 유지
  • 감사 기록 필요

어느 시점에서 이를 “도구"라고 부르는 것은 어색해집니다. 왜냐하면 이 기능은 더 이상 단순한 호출 가능한 함수가 아니라 자체 상태, 위임 및 감사 요구사항을 가진 워크플로우 소유 전문가이기 때문입니다. 바로 여기서 도구 추상을 자연스러운 경계 너머로 늘리는 것보다 A2A가 더 적합한 곳이 됩니다.

MCP는 강력한 도구를 노출할 수 있지만, 에이전트 정체성, 피어 협업, 작업 소유권, 위임 의미론 또는 다중 에이전트 감사 추적을 마법처럼 해결하지는 않습니다.

이것이 실제 문제라면, 당신은 A2A 영역에 있습니다.

보안: 모든 사람이 과소평가하는 부분

보안 모델은 A2A와 MCP가 모두 진지해지는 곳입니다.

MCP는 에이전트에게 도구와 데이터에 대한 접근 권한을 제공합니다. 이는 AI 시스템이 파일을 읽고, 데이터베이스를 쿼리하고, API를 호출하고, 메시지를 보내고, 티켓을 업데이트하거나, 인프라 작업을 트리거할 수 있음을 의미합니다.

A2A는 에이전트가 다른 에이전트에게 작업을 위임할 수 있게 합니다. 이는 하나의 에이전트가 컨텍스트를 전달하고, 작업을 요청하며, 다른 에이전트로부터 결과물을 받을 수 있음을 의미합니다.

둘 다 강력합니다. 둘 다 위험할 수 있습니다.

주요 보안 질문은 다릅니다.

MCP의 경우:

  • 이 에이전트는 어떤 도구를 사용할 수 있는가?
  • 어떤 데이터를 읽을 수 있는가?
  • 어떤 작업을 수행할 수 있는가?
  • 사용자가 작업을 승인하는가?
  • 도구 메타데이터가 모델을 조작할 수 있는가?
  • 로컬 및 원격 서버가 신뢰할 수 있는가?

A2A의 경우:

  • 어떤 에이전트가 서로 소통할 수 있는가?
  • 각 에이전트의 정체성은 무엇인가?
  • 에이전트 A가 에이전트 B에게 권한을 위임할 수 있는가?
  • 얼마나 많은 컨텍스트를 공유할 수 있는가?
  • 최종 결과에 대해 누가 책임 있는가?
  • 작업 사슬을 감사할 수 있는가?

이것이 “모든 것을 연결하는 것"이 나쁜 전략인 이유입니다. 더 많은 프로토콜을 추가할수록 시스템을 안전하고 감사 가능하게 유지하기 위해 정책, 정체성, 로깅, 승인 흐름 및 최소 권한 권한이 더 필요합니다.

좋은 프로덕션 아키텍처에는 다음이 포함되어야 합니다.

  • 에이전트 정체성
  • 도구 정체성
  • 사용자 정체성
  • 범위가 지정된 권한
  • 위험한 작업을 위한 승인 게이트
  • 작업 수준 감사 로그
  • 도구 호출 로그
  • 위임 로그
  • 결과물 기원
  • 속도 제한
  • 타임아웃 정책
  • 나가는 트래픽 제어

A2A와 MCP를 모두 사용하여 구축한다면, 보안은 나중에 추가하는 것이 아닙니다. 아키텍처의 일부입니다. A2A 및 MCP 에이전트 보안: 정체성, 위임 및 감사 추적에서 전체 위협 모델, 정체성 레이어, 게이트웨이 패턴 및 위임 제어를 깊이 있게 다룹니다.

관찰성: 로그가 아닌 추적(trace)이 필요합니다

다중 에이전트 시스템은 디버깅이 어렵습니다.

사용자가 하나의 질문을 합니다. 오케스트레이터가 두 에이전트를 호출합니다. 하나의 에이전트가 세 도구를 호출합니다. 다른 에이전트가 부분적인 진행 상황을 스트리밍합니다. 세 번째 에이전트가 실패하고 재시도합니다. 최종 답변은 합리적으로 보이지만, 어떤 데이터 소스가 이를 영향을 주었는지 아무도 모릅니다.

이는 프로덕션에서 용납될 수 없습니다.

MCP 중심 시스템에서는 다음을 관찰해야 합니다.

  • 도구 선택
  • 도구 인자
  • 도구 결과
  • 도구 대기 시간
  • 도구 오류
  • 사용자 승인
  • 모델에 주입된 컨텍스트

A2A 중심 시스템에서는 다음을 관찰해야 합니다.

  • 에이전트 발견
  • 작업 생성
  • 작업 상태 변경
  • 에이전트 간 메시지
  • 생성된 결과물
  • 위임 사슬
  • 실패 및 재시도
  • 최종 답변 기원

시스템이 더 에이전트적으로 될수록 추적 가능성이 더 중요해집니다. 작업이 여러 에이전트, 도구 호출 및 결과물 인계를 가로지르는 경우 단순한 애플리케이션 로그는 충분하지 않습니다. 어떤 답변도 그 기원으로 추적할 수 있도록 전체 실행 경로를 따르는 작업 추적이 필요합니다. LLM 시스템 관찰성: 프로덕션에서의 메트릭, 추적, 로그 및 테스트에서 이에 대한 도구 및 계측 측면을 깊이 있게 다룹니다. 에이전트가 장기 실행 A2A 작업 전반에 걸쳐 진행 상황을 스트리밍하거나 input_required에서 일시 중지할 때, A2A 스트리밍 및 비동기 작업: 장기 실행 에이전트 워크플로우에서 각 상태 전환 및 위임 홉에서 무엇을 로그해야 하는지 다룹니다.

결정 프레임워크: A2A, MCP, 둘 다, 아니면 둘 다 필요 없는가?

이 결정 프레임워크를 사용하세요.

간단한 코드로 충분할 때 둘 다 사용하지 마세요

다음과 같은 경우 일반적인 함수, API 또는 큐를 선택하세요.

  • 모든 구성 요소를 제어할 때
  • LLM 네이티브 도구 발견이 필요하지 않을 때
  • 에이전트 상호 운용성이 필요하지 않을 때
  • 시스템이 결정론적일 때
  • 통합이 안정적이고 간단할 때

모든 통합에 AI 프로토콜이 필요한 것은 아닙니다.

에이전트가 도구가 필요할 때 MCP를 사용하세요

다음과 같은 경우 MCP를 선택하세요.

  • AI 앱이 외부 데이터가 필요할 때
  • 에이전트가 도구를 호출해야 할 때
  • 재사용 가능한 통합을 원할 때
  • 도구 발견을 원할 때
  • 표준 클라이언트-서버 통합을 원할 때
  • 코딩 에이전트, 어시스턴트, IDE 또는 내부 도구를 위해 구축할 때

이는 대부분의 빌더에게 기본 시작점입니다.

에이전트가 피어가 필요할 때 A2A를 사용하세요

다음과 같은 경우 A2A를 선택하세요.

  • 에이전트가 독립적으로 배포될 때
  • 에이전트가 서로를 발견해야 할 때
  • 에이전트가 다른 팀이나 벤더에 의해 구축되었을 때
  • 작업이 장기간 실행될 때
  • 위임이 중요할 때
  • 결과물이 중요할 때
  • 도구 경계가 아닌 에이전트 경계가 필요할 때

이는 아키텍처의 단위가 에이전트일 때 올바른 선택입니다.

전문 에이전트가 도구가 필요할 때 둘 다 사용하세요

다음과 같은 경우 둘 다 선택하세요.

  • 에이전트가 서로 협력할 때
  • 각 에이전트가 또한 도구에 접근해야 할 때
  • 위임과 실행 사이에 깔끔한 경계를 원할 때
  • 개인 내부 도구 체인을 가진 전문 에이전트를 원할 때
  • 확장 가능한 다중 에이전트 아키텍처를 원할 때

이는 가장 현실적인 엔터프라이즈 패턴입니다.

일반적인 안티패턴

안티패턴 1: 모든 도구를 에이전트로 바꾸기

모든 함수가 에이전트 래퍼를 deserving(가질 자격이 있는) 것은 아닙니다.

통화 변환 API는 아마도 도구일 것입니다. 데이터베이스 쿼리는 아마도 도구일 것입니다. 파일 리더는 아마도 도구일 것입니다.

작은 기능마다 A2A 에이전트로 감싸면 불필요한 복잡성이 생깁니다.

안티패턴 2: 하나의 MCP 도구 뒤에 전체 에이전트 숨기기

반대의 실수도 흔합니다.

MCP 도구가 내부적으로 길고, 상태가 있으며, 다중 에이전트 워크플로우를 실행한다면, MCP 추상은 너무 얇아질 수 있습니다. 작업 상태, 위임, 결과물 및 책임에 대한 가시성을 잃게 됩니다.

이 시점에서 A2A 경계가 필요할 수 있습니다.

안티패턴 3: 모든 에이전트가 모든 도구를 호출하도록 허용하기

이는 권한 혼란을 초래합니다.

전문 에이전트는 범위가 지정된 도구를 가져야 합니다. 작성 에이전트는 프로덕션 데이터베이스 접근 권한이 필요하지 않을 것입니다. 연구 에이전트는 인프라 배포 권한이 필요하지 않을 것입니다.

최소 권한을 사용하세요.

안티패턴 4: 위험한 작업에 대한 인간 승인 없음

에이전트 시스템은 고영향 작업을 조용히 수행해서는 안 됩니다.

다음과 같은 작업에는 인간 승인이 필요합니다.

  • 외부 이메일 보내기
  • 프로덕션 데이터 수정
  • 인프라 배포
  • 파일 삭제
  • 권한 변경
  • 서비스 구매
  • 민감한 데이터 공유

프로토콜은 통합을 쉽게 만듭니다. 하지만 책임은 제거하지 않습니다.

실용적인 예시

예시 1: 로컬 코딩 어시스턴트

로컬 코딩 어시스턴트는 MCP를 사용하여 다음에 접근합니다.

  • 파일시스템
  • Git 저장소
  • 테스트 러너
  • 패키지 관리자
  • 문서 검색

아마도 A2A가 필요하지 않을 것입니다.

MCP면 충분합니다.

예시 2: 엔터프라이즈 지원 어시스턴트

지원 어시스턴트는 MCP를 사용하여 다음에 접근합니다.

  • CRM
  • 티켓팅 시스템
  • 문서
  • Slack
  • 고객 데이터베이스

처음에는 MCP면 충분합니다.

나중에 회사는 전문 에이전트를 추가합니다.

  • 청구 에이전트
  • 법적 정책 에이전트
  • 제품 문제 해결 에이전트
  • 에스컬레이션 에이전트

이제 지원 어시스턴트가 다른 에이전트에게 작업을 위임해야 하므로 A2A가 합리적으로 보입니다.

둘 다 사용하세요.

예시 3: 에이전트 마켓플레이스

플랫폼은 서드파티 에이전트가 기능을 광고하고 다른 에이전트로부터 작업을 받도록 합니다.

플랫폼은 각 에이전트의 내부 구현을 알지 못합니다.

A2A가 강력한 적합성입니다.

개별 에이전트는 내부적으로 MCP를 계속 사용할 수 있지만, 공개 경계는 A2A입니다.

예시 4: 데이터 분석 에이전트

데이터 분석 에이전트는 웨어하우스를 쿼리하고, 대시보드를 읽고, 차트를 생성하며, 보고서를 작성합니다.

도구를 사용하는 단일 에이전트라면 MCP면 충분합니다.

통계적 검토를 하나의 에이전트로, 비즈니스 설명을 다른 에이전트로, 규정 준수 검토를 다른 에이전트로 위임한다면 A2A가 유용해집니다.

저의 주관적인 의견

MCP는 대부분의 빌더를 위한 실용적인 기본값이며, A2A는 실제 에이전트 대 에이전트 조정 필요가 생길 때 큰 시스템이 성장하는 아키텍처적 경계입니다.

유용한 첫 AI 에이전트를 구축하고 있다면 MCP부터 시작하세요. AI 시스템 클러스터는 자체 호스팅 어시스턴트, MCP 서버 및 에이전트 메모리를 연결된 세트로 다루어, 이러한 조각들이 실제로 어떻게 결합되는지에 대한 더 넓은 그림을 제공합니다. 에이전트에게 안전하고 범위가 잘 지정된 도구 및 데이터 접근 권한을 제공하세요. 도구 설명이 깨지는 곳을 배우세요. 권한이 복잡해지는 곳을 배우세요. 관찰성이 약한 곳을 배우세요.

다중 에이전트 환상 아키텍처로 시작하지 마세요.

하지만 시스템에 독립적으로 소유된 여러 에이전트가 있다면, A2A는 훨씬 더 흥미로워집니다. 이는 에이전트 기능, 작업 위임 및 에이전트 간 협업을 표현하는 더 깔끔한 방법을 제공합니다.

실수는 A2A와 MCP를 경쟁자로 취급하는 것입니다.

이는 서로 다른 레이어로 이해하는 것이 더 좋습니다.

  • MCP는 에이전트를 기능에 연결합니다.
  • A2A는 에이전트를 다른 에이전트에 연결합니다.

MCP만으로 유용한 시스템을 구축할 수 있습니다.

A2A만으로 에이전트 네트워크를 구축할 수 있습니다.

하지만 가장 확장 가능한 패턴은 아마도 둘 다를 사용하는 것입니다. 에이전트 협업을 위한 A2A, 도구 통합을 위한 MCP.

최종 결론: AI 에이전트는 정말 둘 다 필요한가?

때때로 그렇습니다. 하지만 항상 그런 것은 아니며, 답은 시스템에 진정한 에이전트 대 에이전트 경계가 있는지 아니면 도구 사용 함수의 컬렉션인지에 거의 전적으로 달려 있습니다.

AI 에이전트가 단지 도구만 필요하면 MCP를 사용하세요.

AI 시스템이 독립적으로 배포된 에이전트가 협력해야 하면 A2A를 사용하세요.

전문 에이전트가 도구가 필요하고 다른 에이전트와도 협력해야 하면 둘 다 사용하세요.

가장 깔끔한 아키텍처는 “A2A vs MCP"가 아닙니다. 에이전트 경계에서의 A2A와 도구 경계에서의 MCP이며, 각 프로토콜이 설계된 문제를 정확히 처리합니다. 이러한 관심사의 분리는 다중 에이전트 시스템을 이해 가능하고, 안전하며, 시간이 지남에 따라 진화하기 쉽게 유지하는 것입니다.

2026년 A2A가 어디에 위치하는지에 대한 더 넓은 시선(채용 계층, 보안 요구사항, 엔터프라이즈 사용 사례 및 도입 시기에 대한 결정 프레임워크)은 2026년 Google A2A 프로토콜: 채택, 과열 및 현실에서 확인하세요.

출처

구독하기

시스템, 인프라, AI 엔지니어링에 관한 새 글을 받아보세요.