A2A 프로토콜과 MCP, 같이 써야 합니다

Published on

in

A2A 프로토콜과 MCP, 같이 써야 합니다

2026.03.22 기준
MCP 2024.11 공개 / A2A 2025.04 공개
TECH

A2A 프로토콜과 MCP,
같이 써야 합니다

두 프로토콜이 경쟁 관계라는 말이 많지만, Google이 A2A를 발표한 공식 문서에는 정반대로 적혀 있습니다.
실제로 어떤 역할이 다르고, 어디서 함께 써야 하는지를 공식 자료와 보안 사고 사례로 직접 확인했습니다.

50+
A2A 출시 참여 기술 파트너
2024.11
MCP 최초 공개 시점
1개월
MCP 서버 첫 보안 사고까지 걸린 시간

A2A와 MCP, 역할부터 다릅니다

A2A 프로토콜과 MCP는 둘 다 AI 에이전트가 외부와 소통하는 방식을 표준화하는 프로토콜이지만, 해결하려는 문제 자체가 다릅니다. MCP(Model Context Protocol)는 AI 모델이 데이터베이스, GitHub, Notion 같은 외부 도구에 연결하는 방식을 통일합니다. 쉽게 말하면 “AI와 도구 사이의 USB-C 포트” 역할입니다.
(출처: Anthropic 공식 블로그, 2024.11)

반면 A2A(Agent-to-Agent)는 AI 에이전트끼리 서로 대화하고 작업을 위임하는 방식을 표준화합니다. 채용 에이전트가 신원조회 에이전트에게 업무를 넘기는 것처럼, 에이전트 간 협업 흐름을 만드는 데 초점을 맞춥니다.
(출처: Google Developer Blog, 2025.04.09)

💡 공식 발표문과 실제 사용 흐름을 같이 놓고 보니 이런 차이가 보였습니다.
MCP = AI가 도구를 쓰는 방식 / A2A = AI가 다른 AI에게 일을 맡기는 방식.
한쪽이 다른 쪽을 대체하지 않습니다. 두 문제는 처음부터 달랐습니다.

구분 MCP A2A
개발사 Anthropic Google
최초 공개 2024년 11월 2025년 4월
핵심 역할 AI ↔ 외부 도구 연결 AI 에이전트 ↔ AI 에이전트 협업
통신 기반 JSON-RPC 2.0 HTTP, SSE, JSON-RPC
현재 상태 프로덕션 운영 중 Linux Foundation 오픈소스 관리 중

출처: Anthropic 공식 블로그(2024.11) / Google Developer Blog(2025.04) / IBM Think(2026)

▲ 목차로 돌아가기

“경쟁 관계”라는 말이 왜 틀렸는지

인터넷에 돌아다니는 글의 상당수가 A2A와 MCP를 “경쟁 프로토콜”로 다룹니다. 하지만 Google이 A2A를 발표한 공식 문서에는 이렇게 적혀 있습니다.

“A2A는 에이전트에 유용한 도구와 컨텍스트를 제공하는 Anthropic의 MCP(Model Context Protocol)를 보완하는 개방형 프로토콜입니다.”

— Google Developer Blog, 2025.04.09, 공식 원문

A2A의 GitHub 공식 저장소에는 ‘A2A ❤️ MCP’라는 제목의 페이지가 별도로 존재합니다. Google이 처음 설계 단계부터 두 프로토콜이 충돌 없이 병행 운영되도록 계층 구조를 잡았다고 밝힌 내용이 담겨 있습니다.
(출처: 이글루코퍼레이션 보안 분석 리포트, 2026)

💡 구글이 자사 프로토콜 문서에서 경쟁사 프로토콜을 보완 관계로 명시한 건 드문 일입니다.
“경쟁”이 아니라 “역할 분담”이 두 프로토콜의 관계를 더 정확하게 설명합니다.

실제로 이글루코퍼레이션의 보안 분석 자료에서도 “A2A는 협업을, MCP는 통합을 지향하는 프로토콜”이라고 정리하고 있습니다. 두 프로토콜은 다른 계층에서 작동하기 때문에, 하나를 선택하는 문제가 아닙니다. 재고 에이전트가 MCP로 DB에서 재고 데이터를 읽고, A2A로 공급업체 에이전트에게 주문을 위임하는 흐름이 그 증거입니다.

▲ 목차로 돌아가기

MCP 구조: 세 가지 계층으로 작동합니다

MCP 공식 문서에 따르면, MCP는 크게 세 가지 참여자로 구성됩니다. MCP Host(Claude Desktop, VS Code 같은 AI 애플리케이션), MCP Client(서버와 1:1 연결을 유지하는 컴포넌트), MCP Server(실제 데이터를 제공하거나 도구 기능을 실행하는 프로그램)입니다.
(출처: modelcontextprotocol.io 공식 아키텍처 문서, 원문 링크)

MCP Server가 제공할 수 있는 기본 기능은 세 가지입니다. Tools(파일 조작, API 호출 등 실행 가능한 함수), Resources(DB 레코드, 파일 내용 등 데이터 소스), Prompts(재사용 가능한 프롬프트 템플릿)입니다. 서버가 먼저 목록을 내보내면, 클라이언트가 그걸 발견해서 쓰는 구조입니다.

전송 방식은 두 가지입니다. 로컬 프로세스끼리는 STDIO 전송을 씁니다. 네트워크로 연결된 원격 서버는 Streamable HTTP 전송을 쓰고, 여기에는 OAuth 기반 인증을 권장합니다. 2024년 11월 처음 공개될 때는 로컬 STDIO만 있었지만, 이후 Streamable HTTP가 추가되면서 원격 서버 운영이 가능해졌습니다.

💡 MCP의 핵심은 “연결 방식을 통일했다”는 것입니다.
GitHub, Slack, Notion, PostgreSQL 각각에 맞는 커스텀 연결 코드를 짜던 걸 MCP 서버 하나로 표준화했습니다. 연결 수가 늘수록 이 통일 방식의 효과가 커집니다.

▲ 목차로 돌아가기

A2A 구조: 에이전트 카드에서 시작합니다

A2A의 워크플로는 3단계로 작동합니다. 탐색 → 인증 → 커뮤니케이션입니다. 클라이언트 에이전트가 원격 에이전트를 발견하는 첫 번째 수단이 에이전트 카드(Agent Card)입니다. JSON 파일 형태로 공개된 에이전트의 “명함”으로, 이름·설명·지원 기능·인증 방식 등이 담겨 있습니다.
(출처: IBM Think, Agent2Agent Protocol 공식 해설, 원문 링크)

인증은 API 키, OAuth 2.0, OpenID Connect Discovery 등 OpenAPI 표준 기반 방식을 씁니다. 인증 후 통신은 HTTPS를 통해 이루어지고, 데이터 포맷은 JSON-RPC 2.0입니다. 장기 실행 작업에는 서버-전송 이벤트(SSE)로 실시간 스트리밍을 지원하고, 연결이 끊겨도 웹훅으로 비동기 알림을 보냅니다.

A2A의 핵심 개념 중 하나가 에이전트를 “블랙박스”로 취급한다는 설계 원칙입니다. 다른 에이전트의 내부 메모리, 독점 로직, 도구 구현 방식을 공개하지 않아도 협업이 됩니다. 외부에서 보이는 건 에이전트 카드뿐입니다. 이 원칙 덕분에 Anthropic Claude와 Google Gemini 기반 에이전트가 서로 내부를 모르면서도 함께 작업하는 시나리오가 가능해집니다.

💡 기존 에이전트 프레임워크(LangChain, CrewAI)는 같은 생태계 안에서만 멀티 에이전트가 됩니다.
A2A는 서로 다른 제조사 에이전트를 연결하는 “메시징 계층”입니다. 그 차이가 꽤 큽니다.

▲ 목차로 돌아가기

MCP 보안 사고 — 공개 한 달 만에 생긴 일

“MCP는 안전하다”는 말이 많지만, 실제 기록은 다릅니다. 2025년 6월 4일, Asana의 MCP 서버가 공개된 지 한 달 만에 다른 사용자의 프로젝트·팀·업무 데이터에 접근할 수 있는 버그가 발견됐습니다. 보안 기업 UpGuard가 취약점을 발견했고, Asana는 서버 운영을 일시 중단했습니다.
(출처: 이글루코퍼레이션 보안 분석 리포트, 2026)

이 사건 외에도 MCP에서 발견된 주요 공격 유형이 있습니다. Invariant Labs 보안연구팀이 발견한 Tool Poisoning Attack(TPA)은 AI 모델에게는 보이지만 사용자에게는 보이지 않는 악의적인 명령을 도구 설명 안에 숨기는 방식입니다. 실제 테스트에서 사용자가 문서 작성을 요청했지만, 악성 서버의 개입으로 문서에 테스트 문자열이 삽입되는 것이 증명됐습니다.

⚠️ MCP의 근본적인 보안 문제는 “에이전트 신원 모델이 없다”는 것입니다.
모든 행위가 신뢰할 수 있는 서비스 계정에서 비롯된 것처럼 보여서, “누가 이 작업을 요청했는가”를 추적하기가 어렵습니다. 이글루코퍼레이션 자료에서 이 구조적 결함을 명시하고 있습니다.

A2A 역시 OpenAPI 기반 인증을 설계 원칙으로 삼았지만, IBM Think 자료에 따르면 에이전트 카드에 권한 부여 체계를 공식적으로 포함하는 방법, 예상치 못한 스킬을 동적으로 확인하는 방법 등은 “아직 개선 중”이라고 명시했습니다. 두 프로토콜 모두 보안 성숙도가 완성 단계가 아닙니다.

▲ 목차로 돌아가기

두 프로토콜을 함께 쓰는 실제 흐름

IBM Think 공식 해설에는 두 프로토콜을 함께 쓰는 사례가 직접 나옵니다. 소매점 재고 관리 시나리오입니다. 재고 에이전트가 MCP를 통해 재고 DB에서 데이터를 읽습니다. 재고 부족을 감지하면, A2A를 통해 공급업체 에이전트에게 주문을 위임합니다. MCP는 “에이전트가 데이터를 읽는 방식”, A2A는 “에이전트가 다른 에이전트와 협업하는 방식”을 각각 담당합니다.
(출처: IBM Think, 원문 링크)

Google이 A2A 공식 발표에서 든 또 다른 예는 채용 프로세스입니다. 통합 인터페이스 안에서 채용 에이전트가 구인 요건을 입력받으면, A2A로 후보 검색 전문 에이전트에게 요청을 넘기고, 해당 에이전트는 면접 일정 에이전트, 신원조회 에이전트와 순차적으로 협업합니다. 각 에이전트는 서로 다른 벤더가 만들었어도 됩니다.
(출처: Google Developer Blog, 2025.04.09)

MCP + A2A 조합 구조 예시

1
사용자 → 메인 에이전트: “3월 재고 부족 품목 전부 주문해줘”
2
메인 에이전트 → MCP → 재고 DB 조회 (데이터 읽기)
3
메인 에이전트 → A2A → 공급업체 에이전트에게 주문 위임
4
공급업체 에이전트 → SSE로 완료 상태 실시간 전달

▲ 목차로 돌아가기

A2A는 2026년 3월에도 완성되지 않았습니다

A2A를 MCP보다 “더 발전한 버전”이나 “최신 표준”으로 소개하는 글이 많습니다. 하지만 현재 상태를 짚어두는 게 중요합니다. KISA(한국인터넷진흥원) 보고서에는 2025년 5월 기준으로 “A2A 프로토콜은 현재 기본적인 사양을 담은 스펙 초안과 함께 샘플 코드가 외부에 공개된 상태, 2025년 하반기에 프로덕션 준비 완료 버전 출시를 목표로 함”이라고 명시됐습니다.
(출처: KISA 보고서, 2025.07)

2026년 3월 현재, A2A는 Linux Foundation에서 오픈소스로 관리되고 있으며 IBM, SAP, Salesforce 등 주요 파트너들이 지원을 표명한 상태입니다. 하지만 IBM Think 자료에서도 “A2A는 아직 초기 단계이므로 프로토콜이 발전함에 따라 조직은 점진적인 개선을 기대할 수 있다”고 명시했습니다. 에이전트 카드의 권한 부여 체계, UX 동적 조정, 푸시 알림 안정성 등이 아직 개선 목록에 올라 있습니다.

📌 MCP와 A2A를 고려할 때 실용적인 기준은 이렇습니다.
지금 당장 프로덕션에 써야 한다면: MCP. 이미 Claude Desktop, VS Code, Cursor 등 주요 앱이 지원하고 있습니다.
멀티 에이전트 협업 구조를 설계한다면: A2A도 함께 검토. 단, 스펙이 아직 변경될 수 있음을 감안해야 합니다.

솔직히 말하면, 2025년에 나온 “A2A vs MCP 비교” 글들 대부분은 Google이 A2A를 처음 발표했을 때의 흥분감으로 쓰인 것들입니다. 당시는 프로덕션 버전도 없었고, MCP가 이미 OpenAI까지 지원(2025년 3월)하고 있던 상황이었습니다. 현재 시점에서 다시 읽어보면 정보가 꽤 낡아 있습니다.

▲ 목차로 돌아가기

Q&A

Q1. MCP와 A2A 중 먼저 배워야 할 건 어느 쪽인가요?
MCP부터입니다. Claude Desktop이나 VS Code 같은 앱에서 바로 써볼 수 있고, 실제 도구 연결 경험을 쌓기에 더 적합합니다. A2A는 에이전트 간 협업 시나리오를 직접 설계해볼 때 의미가 생깁니다. 지금 당장 멀티 에이전트 오케스트레이션이 필요한 상황이 아니라면 MCP 먼저 익히는 게 실용적입니다.
Q2. A2A가 MCP를 대체하게 될 가능성은 없나요?
공식 문서 기준으로는 없습니다. Google이 A2A 발표 문서에서 직접 “MCP를 보완하는 프로토콜”이라고 명시했고, A2A GitHub 저장소에 ‘A2A ❤️ MCP’ 페이지를 별도로 유지하고 있습니다. 두 프로토콜은 해결하는 계층이 다릅니다. MCP가 사라지려면 “AI와 외부 도구 연결” 문제가 사라져야 하는데, 그럴 가능성은 없습니다.
Q3. MCP 서버를 직접 만들면 보안은 어떻게 관리해야 하나요?
Asana 사례처럼, MCP 서버는 출시 직후라도 다른 사용자 데이터에 접근하는 버그가 생길 수 있습니다. 최소 권한 원칙(에이전트에게 꼭 필요한 권한만 부여), OAuth 기반 인증, 입력값 검증을 기본으로 챙겨야 합니다. 특히 Tool Description 안에 숨겨진 악성 명령(Tool Poisoning Attack)을 막으려면 외부에서 가져온 MCP 서버는 코드 리뷰 없이 그냥 설치하지 않는 것이 좋습니다.
Q4. OpenAI도 MCP를 지원하나요?
네. 2025년 3월 27일에 OpenAI가 MCP 지원을 발표했습니다. GPT 모델과 관련 SDK에 MCP가 통합됐고, ChatGPT와 OpenAI API에서도 MCP 서버를 쓸 수 있습니다. Anthropic이 만든 프로토콜이지만 OpenAI, Cursor, VS Code, Zed 등 경쟁 플랫폼들이 채택하면서 사실상 업계 표준이 됐습니다.
(출처: KISA 보고서, 2025.07)
Q5. AGNTCY는 A2A, MCP와 어떤 관계인가요?
AGNTCY는 2025년 3월 Cisco와 LangChain 등이 시작한 별도 이니셔티브로, “에이전트의 인터넷(Internet of Agents)”을 목표로 합니다. 자체 통신 프로토콜인 ACP(Agent Connect Protocol)를 포함합니다. A2A와 구조적으로 유사하지만 “서로 경쟁이 아닌, 보완 관계”라는 입장입니다. 다만 현재(2026년 3월)는 A2A가 50개 이상의 기술 파트너와 Linux Foundation 지원을 받으며 더 넓은 채택률을 보이고 있습니다.

▲ 목차로 돌아가기

마치며

A2A 프로토콜과 MCP를 한 줄로 정리하면 이렇습니다. MCP는 AI가 도구를 쥐는 방식, A2A는 AI가 다른 AI에게 일을 넘기는 방식. 같은 시스템 안에서 두 역할이 동시에 필요할 수 있고, 실제로 IBM과 Google이 공식 자료에서 같이 쓰는 시나리오를 직접 제시하고 있습니다.

다만 아직 두 프로토콜 모두 완성이 아닙니다. MCP는 보안 모델에 구조적 한계가 있고, A2A는 스펙 자체가 변화 중입니다. “어느 쪽이 더 좋다”는 단순한 비교보다 현재 내 시스템에 무엇이 필요한지를 먼저 따지는 게 실제로 도움이 됩니다. 2026년 3월 기준, 당장 쓸 수 있는 건 MCP입니다.

▲ 목차로 돌아가기

본 포스팅 참고 자료

  1. Google Developer Blog — Agent2Agent(A2A) 프로토콜 공식 발표 (2025.04.09): 원문 링크
  2. Anthropic 공식 블로그 — Model Context Protocol 발표 (2024.11): 원문 링크
  3. modelcontextprotocol.io — MCP 공식 아키텍처 문서: 원문 링크
  4. IBM Think — Agent2Agent(A2A) 프로토콜 공식 해설: 원문 링크
  5. KISA(한국인터넷진흥원) — AI 에이전트 개방형 프로토콜의 기술 현황 및 시사점 보고서 (2025.07)
  6. 이글루코퍼레이션 — MCP, A2A 등의 프로토콜이 보안에 미치는 영향 (2026): 원문 링크

본 포스팅은 2026년 3월 22일 기준으로 작성됐습니다.
본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다.
MCP 및 A2A 프로토콜 스펙은 지속적으로 업데이트되고 있으므로, 최신 내용은 각 공식 문서에서 확인하시기 바랍니다.

댓글 남기기


최신 글


아이테크 어른경제에서 더 알아보기

지금 구독하여 계속 읽고 전체 아카이브에 액세스하세요.

계속 읽기