A2A vs MCP: AI 에이전트는 정말 두 프로토콜 모두 필요한가?

MCP는 에이전트에 도구를 제공하며, A2A는 에이전트에게 동료(피어)를 제공합니다.

Page content

AI 에이전트 아키텍처는 이제 두 가지 레이어로 분화되기 시작하고 있습니다.

한 레이어는 AI 어시스턴트에게 도구, 데이터, API, 파일, 데이터베이스, 검색 시스템, 캘린더, 티켓팅 시스템 및 기타 외부 기능에 대한 접근 권한을 부여하는 것이며 — MCP가 바로 여기에 해당합니다.

다른 레이어는 하나의 AI 에이전트가 다른 AI 에이전트를 발견하고, 통신하며, 위임하고, 협업하게 하는 것입니다. 그 다른 에이전트는 아마도 다른 팀, 프레임워크, 벤더 또는 조직이 구축했을 것입니다 — 그리고 A2A가 바로 여기에 해당합니다.

짜증나는 점은 두 프로토콜 모두 동일한 문제를 해결하는 것처럼 논의된다는 것입니다. 그런데 실제로는 그렇지 않습니다. 경계면에서 일부 중복이 있고, 그 중복이 대부분의 혼란을 초래합니다. 하지만 명확한 정신적 모델은 간단합니다:

MCP는 주로 에이전트-도구 간 연결이며, A2A는 주로 에이전트-에이전트 간 연결입니다.

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

모든 AI 시스템이 둘 다 필요하다는 뜻은 아닙니다. 실제로 대부분의 작은 에이전트 프로젝트는 MCP부터 시작하고, 실제 다중 에이전트 경계가 생길 때까지 A2A를 무시하는 것이 좋습니다. 하지만 대규모 에이전트 시스템을 구축 중이거나, 특히 별도로 배포된 에이전트, 전문 에이전트, 벤더 에이전트, 또는 장기 실행 위임 작업이 있는 시스템인 경우, A2A가 합리적으로 보입니다.

이 글은 두 프로토콜의 차이점, 중복 부분, 아키텍처적 tradeoff, 그리고 실제로 둘 다 필요한 때를 설명합니다. 만약 여러분의 결정이 에이전트-에이전트 통신이 아니라 기능이 Agent Skill인지 MCP 서버인지에 관한 것이라면, Agent Skills vs MCP Servers 결정 프레임워크를 참조하세요.

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, task lifecycle, messages, parts, artifacts — 에 대한 더 깊은 이해를 원한다면 What Is the A2A Protocol? Agent Cards and Tasks Explained에서 각 개념을 상세히 다룹니다. 공식 A2A 스펙은 프로토콜을 다른 프레임워크, 언어, 벤더로 구축된 에이전트들이 공통 상호작용 모델을 통해 통신할 수 있는 방식이라고 설명합니다.

핵심 구절은 “independent agent systems"입니다.

A2A는 주로 하나의 어시스턴트에게 계산기, 데이터베이스, 파일시스템 접근 권한을 부여하는 것이 아닙니다. 자신의 기능, 상태, 정책, 작업 모델, 그리고 아마도 자체 도구를 가진 다른 에이전트와 통신하는 것입니다.

A2A 에이전트는 Agent Card를 통해 자신이 할 수 있는 것을 광고할 수 있습니다. 다른 에이전트나 클라이언트가 그 기능을 발견하고, 작업을 보내고, 메시지를 주고받고, 아티팩트를 받고, 작업 라이프사이클을 추적할 수 있습니다.

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

Agent Cards
Agents and clients
Tasks
Messages
Parts
Artifacts
Task states
Streaming and asynchronous work

이 개념들은 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를 호출하고, 티켓을 열고, 로그를 요약하고, 메트릭을 검사하고, 레코드를 업데이트해야 합니다.

MCP는 그 목적에 매우 잘 맞습니다.

다음의 경우 MCP만 사용하세요:

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

많은 시스템에 대해, MCP와 좋은 애플리케이션 아키텍처가 충분합니다. 많은 팀이 실제로는 도구 사용 어시스턴트인 시스템에 A2A를 과잉 설계하고, 그것은 프로토콜 문제가 아니라 — 어떤 프로토콜도 해결해 줄 수 없는 아키텍처 규율 문제입니다.

A2A만 사용하는 경우

A2A-only 시스템은 덜 흔하지만, 존재할 수 있습니다.

시스템이 주로 에이전트 간 통신에 관한 것이고, 각 에이전트가 이미 자체 도구를 내부적으로 관리한다면 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 outside: 에이전트가 서로 통신하는 방식
MCP inside: 각 에이전트가 도구, 데이터, 서비스에 접근하는 방식

아마도 이것은 가장 지속 가능한 정신적 모델입니다.

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

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

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

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

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

참조 아키텍처: A2A Outside, MCP Inside

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

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는 각 에이전트와 그 도구 간의 통합을 처리합니다. 오케스트레이터는 모든 전문가가 사용할 수 있는 모든 도구를 알 필요가 없습니다 — 어떤 유형의 작업에 어떤 에이전트가 책임 있는지만 알면 되며, 이는 도구 과부하를 줄이고 전체 아키텍처를 더 모듈화되게 합니다. 그 오케스트레이터 레이어의 내부 토폴로지 — 허브-스포크, 계층적 트리, 팬아웃, 또는 메쉬를 사용하는지 — 는 Multi-Agent Orchestration Patterns에서 다루는 별도의 설계 결정입니다. 프로덕션 어시스턴트 내부에서 추론, 메모리, 라우팅, 도구가 어떻게 함께 작동하는지에 대한 더 깊은 처리를 원한다면 AI Assistant Architecture: LLM, Memory, Tools, Routing, Observability에서 그 레이어들을 상세히 다룹니다.

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에게 권한을 위임할 수 있는가?
얼마나 많은 컨텍스트를 공유할 수 있는가?
최종 결과에 대해 누가 책임 있는가?
작업 체인을 감사할 수 있는가?

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

좋은 프로덕션 아키텍처는 다음을 포함해야 합니다:

에이전트 정체성
도구 정체성
사용자 정체성
범위가 제한된 권한
위험한 작업에 대한 승인 게이트
작업 수준 감사 로그
도구 호출 로그
위임 로그
아티팩트 provenance
레이트 리미트
타임아웃 정책
이그레스 제어

A2A와 MCP를 모두 사용하여 구축 중이라면, 보안은 후속 조치가 아닙니다. 그것은 아키텍처의 일부입니다. A2A and MCP Agent Security: Identity, Delegation, and Audit Trails에서 전체 위협 모델, 정체성 레이어, 게이트웨이 패턴, 위임 제어를 상세히 다룹니다.

관찰 가능성: 로그가 아닌 추적 필요

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

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

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

MCP 중심 시스템에 대해, 다음을 관찰해야 합니다:

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

A2A 중심 시스템에 대해, 다음을 관찰해야 합니다:

에이전트 발견
작업 생성
작업 상태 변경
에이전트 간 메시지
생성된 아티팩트
위임 체인
실패와 재시도
최종 답변 provenance

시스템이 더 에이전트적이 될수록, 추적 가능성이 더 중요해집니다 — 작업이 여러 에이전트, 도구 호출, 아티팩트 전달에 걸쳐 있을 때 단순한 애플리케이션 로그는 충분하지 않습니다. 어떤 답변도 그 기원으로 추적될 수 있도록 전체 실행 경로를 따르는 작업 추적이 필요합니다. Observability for LLM Systems: Metrics, Traces, Logs, and Testing in Production에서 이 부분의 도구와 계측 측면을 상세히 다룹니다. 에이전트가 장기 실행 A2A 작업에서 진행 상황을 스트리밍하거나 input_required에서 일시 중지할 때, A2A Streaming and Async Tasks for Long-Running Agent Workflows에서 각 상태 전환과 위임 단계에서 무엇을 로그해야 하는지 다룹니다.

결정 프레임워크: A2A, MCP, 둘 다, 아니면 둘 다 아닌 것이 필요한가?

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

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

다음의 경우 일반적인 함수, API, 또는 큐를 선택하세요:

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

모든 통합이 AI 프로토콜을 필요로 하는 것은 아닙니다.

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

다음의 경우 MCP를 선택하세요:

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

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

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

다음의 경우 A2A를 선택하세요:

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

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

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

다음의 경우 둘 다 선택하세요:

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

가장 현실적인 기업 패턴입니다.

일반적인 안티패턴

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

모든 함수가 에이전트 래퍼를 deserving하지 않습니다.

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

작은 기능을 A2A 에이전트로 래핑하는 것은 불필요한 복잡성을 만듭니다.

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

반대 실수도 흔합니다.

MCP 도구가 비밀스럽게 긴, 상태ful, 다중 에이전트 워크플로우를 실행한다면, MCP 추상화는 너무 얇아질 수 있습니다. 작업 상태, 위임, 아티팩트, 책임에 대한 가시성을 잃습니다.

그 지점에서, 그것은 A2A 경계를 deserving할 수 있습니다.

안티패턴 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 Systems 클러스터는 셀프 호스팅 어시스턴트, MCP 서버, 에이전트 메모리를 연결된 세트로 다루며, 그 부분들이 실제로 어떻게 함께 작동하는지에 대한 더 큰 그림을 제공합니다. 에이전트에게 안전하고 범위가 제한된 도구 및 데이터 접근을 제공하세요. 도구 설명이 실패하는 곳을 배우세요. 권한이 혼란스러워지는 곳을 배우세요. 관찰 가능성이 약한 곳을 배우세요.

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

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

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

그들은 다른 레이어로 이해해야 합니다:

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

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

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

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

최종 판정: AI 에이전트는 실제로 둘 다 필요한가?

때로는 — 하지만 항상은 아니며, 답은 거의 전적으로 시스템에 진정한 에이전트 간 경계가 있는지 아니면 단순히 도구 사용 함수의 집합인지에 달려 있습니다.

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

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

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

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

2026년에서 A2A가 어디에 위치하는지에 대한 더 넓은 시각 — 채택 단계, 보안 요구사항, 기업 사용 사례, 도입 시기에 대한 결정 프레임워크 — 를 원한다면 Google A2A Protocol in 2026: Adoption, Hype, and Reality를 참조하세요.

출처

A2A Protocol Specification: https://a2a-protocol.org/latest/specification/
A2A and MCP comparison: https://a2a-protocol.org/latest/topics/a2a-and-mcp/
MCP introduction: https://modelcontextprotocol.io/docs/getting-started/intro
MCP architecture overview: https://modelcontextprotocol.io/docs/learn/architecture
MCP server concepts: https://modelcontextprotocol.io/docs/learn/server-concepts
Linux Foundation A2A adoption update: https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year