MCP 다음은 A2A 2026년 AI 에이전트 표준 정리
AI 에이전트가 서로 협업하는 시대의 표준 A2A 프로토콜을 MCP와 비교해 정리했습니다. 작동 방식, 기업 도입 사례, 한국 기업이 지금 표준화해야 할 것까지 짚어드립니다.
Jun 29, 2026
2026년 봄, AI 업계의 관심은 여전히 "어떤 AI 모델이 가장 고성능인가"에 머물러 있었습니다. 그런데 그 아래에서 조용히 지나간 사건이 하나 있습니다. 구글이 2025년 4월 공개한 에이전트 간 통신 표준 A2A(Agent2Agent) 프로토콜이 출범 1년 만에 150개가 넘는 조직의 지지를 받고, 운영 주체가 리눅스 재단(Linux Foundation)으로 넘어갔으며, 마이크로소프트·아마존·구글의 클라우드에 모두 기본 탑재됐다는 소식입니다.
기술에 대한 뉴스처럼 보이지만 함의는 경영 쪽에 가깝습니다. 지금까지 기업의 고민이 "쓸 만한 AI 에이전트를 어떻게 한 개 만드느냐"였다면, 이제 질문은 "여러 에이전트를 어떻게 서로 협업하게 만드느냐"로 옮겨가고 있습니다. 당신 회사의 AI 에이전트는 더 이상 혼자 일하지 않습니다.
이 글은 그 전환의 한가운데에 있는 A2A 프로토콜을 정리합니다. A2A가 무엇이고, 왜 지금 등장했으며, 이미 익숙한 MCP와는 어떻게 다른지, 그리고 한국 기업이 지금 무엇을 표준화해 두어야 하는지까지 짚어 보겠습니다.
왜 지금 'A2A'인가: 에이전트가 많아지자 생긴 병목
에이전트를 늘릴수록 병목이 되는 코디네이션의 함정
지난 2년간 기업들은 에이전트를 "하나씩" 만들어 왔습니다. 고객 문의를 처리하는 에이전트, 청구서를 분류하는 에이전트, 코드를 작성하는 에이전트. 각자 제법 쓸 만했습니다. 문제는 이들의 수가 늘어나면서 시작됐습니다.
서로 다른 팀이, 서로 다른 프레임워크로, 서로 다른 벤더의 모델 위에 만든 에이전트들은 기본적으로 서로를 알지 못합니다. 영업 에이전트가 재고 에이전트에게 "이 제품 지금 몇 개 있어?"라고 물으려면, 둘 사이를 잇는 연결을 사람이 일일이 코딩해야 했습니다. 에이전트가 2개일 때는 연결이 1개면 되지만, 10개가 되면 잠재적 연결은 수십 개로 늘어납니다. 에이전트를 늘릴수록 정작 발목을 잡는 것은 에이전트의 성능이 아니라 그들 사이를 잇는 코디네이션(coordination) 비용이었습니다.
리눅스 재단은 A2A를 소개하며 이 지점을 "코디네이션이 병목이 된다"는 한 문장으로 요약했습니다. A2A는 바로 그 병목을 풀기 위한 공통 언어입니다.
A2A 프로토콜이란 무엇인가
A2A(Agent2Agent)는 서로 다른 벤더·프레임워크로 만든 AI 에이전트가 조직 경계를 넘어 서로를 발견하고, 작업을 위임하며, 협업하게 하는 개방형 표준입니다. 2025년 4월 구글이 50여 개 기술 파트너와 함께 공개했고, 이후 리눅스 재단 산하 프로젝트로 이관되며 특정 기업의 것이 아닌 산업 공용 표준이 됐습니다.
핵심은 "어떻게 만들어졌는지 묻지 않는다"는 점입니다. 어떤 언어로 짰든, 어떤 프레임워크를 썼든, 어느 회사 모델 위에서 돌든, A2A만 구현하면 에이전트들은 서로 대화할 수 있습니다.
1년 만에 어디까지 왔나
A2A가 단순한 발표용 표준이 아니라는 점은 숫자로 드러납니다. 리눅스 재단 발표에 따르면 A2A는 2025년 4월 50개+ 파트너로 출범해, 2026년에는 150개+ 조직의 지지, 깃허브(GitHub) 2만 2,000개 이상의 스타, 그리고 Python·JavaScript·Java·Go·.NET 등 5개 프로덕션 SDK 단계에 도달했습니다.
무엇보다 무거운 신호는 클라우드 쪽입니다. 마이크로소프트는 Azure AI Foundry와 Copilot Studio에, 아마존은 Bedrock AgentCore에, 구글은 자사 클라우드 플랫폼에 A2A를 통합했습니다. AI 인프라를 사실상 양분하는 세 회사가 같은 표준을 기본값으로 채택했다는 것은, 적어도 "이 표준이 사라질 위험"은 거의 없어졌다는 의미로 읽을 수 있습니다.
MCP와 A2A는 무엇이 다른가, 그리고 왜 둘 다 필요한가
A2A를 처음 접하면 자연스럽게 떠오르는 단어가 있습니다. 바로 MCP(Model Context Protocol)입니다. 2024년 앤트로픽(Anthropic)이 공개한 뒤 2026년 현재 1만 개가 넘는 서버가 운영되는, 이미 익숙한 표준이죠. 두 프로토콜은 비슷해 보이지만 푸는 문제가 다릅니다.
MCP = 에이전트와 도구의 수직 연결
MCP는 에이전트(혹은 AI 애플리케이션)를 외부의 도구·데이터·API에 연결합니다. 에이전트가 사내 데이터베이스를 조회하거나, 깃허브에 코드를 올리거나, 캘린더를 읽으려 할 때 그 통로를 표준화하는 것이 MCP입니다. 방향으로 보면 수직 통합입니다. 위에 있는 에이전트가 아래에 있는 도구로 손을 뻗는 구조죠.
A2A = 에이전트와 에이전트의 수평 연결
A2A는 연결의 방향이 다릅니다. MCP가 에이전트를 도구에 수직으로 연결한다면, A2A는 에이전트를 에이전트에 수평으로 연결합니다. 옆에 있는 다른 에이전트에게 "이 일을 네가 더 잘하니 맡길게"라고 위임하고, 그 결과를 받아 다음 단계로 넘기는 협업의 통로입니다.
비유하자면 이렇습니다. MCP는 한 직원에게 컴퓨터·전화·문서함이라는 도구를 쥐여 주는 일이고, A2A는 그 직원이 옆 부서 동료에게 업무를 협조 요청하는 사내 규칙입니다. 둘 다 없으면 조직은 돌아가지 않습니다.
구분 | MCP (Model Context Protocol) | A2A (Agent2Agent Protocol) |
연결 대상 | 에이전트 ↔ 도구·데이터 | 에이전트 ↔ 에이전트 |
통합 방향 | 수직 (애플리케이션–도구) | 수평 (에이전트–에이전트) |
핵심 질문 | "이 도구를 어떻게 쓰지?" | "이 일을 누구에게 맡기지?" |
출범 | 2024년, 앤트로픽 | 2025년 4월, 구글 → 리눅스 재단 |
관계 | 상호 보완 (경쟁 아님) | 상호 보완 (경쟁 아님) |
MCP를 쓰면 A2A는 필요 없을까?
가장 흔한 오해입니다. 결론부터 말하면, 둘은 경쟁 관계가 아니라 보완 관계입니다. 리눅스 재단과 다수 기술 문서는 A2A와 MCP를 "대체재가 아니라 보완재"로 명시합니다.
실제로 견고하게 설계된 멀티 에이전트 시스템은 두 표준을 함께 씁니다. 각 에이전트는 MCP로 자신이 필요한 도구와 데이터를 안정적으로 끌어다 쓰고, A2A로 다른 에이전트와 협업해 더 큰 작업을 완성합니다. MCP는 에이전트 하나가 도구를 다루게 하고, A2A는 여러 에이전트가 협업하게 한다고 이해하면 정확합니다. 둘 중 하나만 갖춘 아키텍처는 반쪽입니다.
A2A는 실제로 어떻게 작동하나
기술 세부까지 파고들 필요는 없지만, 작동 원리를 큰 그림으로 알아 두면 도입 판단이 훨씬 쉬워집니다. A2A의 작동은 세 가지 키워드로 압축됩니다.
Agent Card: 에이전트가 자기 능력을 공개하는 법
A2A에서 각 에이전트는 에이전트 카드(Agent Card)라는 일종의 명함을 공개합니다. JSON 형식으로 된 이 카드에는 "나는 무엇을 할 수 있고, 어떤 입력을 받으며, 어떻게 호출하면 되는지"가 적혀 있습니다. 다른 에이전트는 이 카드를 읽고 "이 작업에는 저 에이전트가 적임"이라고 판단해 일을 맡깁니다. 사람이 일일이 연결을 코딩하지 않아도, 에이전트들이 서로의 능력을 발견(discovery)할 수 있게 하는 장치입니다.
작업 위임과 생애주기: 즉답형과 장기 실행형
A2A는 한 번의 질문에 곧바로 답하는 작업과, 몇 분에서 몇 시간씩 걸리는 장기 작업을 모두 다룹니다. 요청을 받은 에이전트는 즉시 결과를 돌려주기도 하고, "지금 처리 중"이라는 상태를 실시간으로 보고하며 중간 산출물을 흘려보내기도 합니다. 덕분에 "보고서를 작성해 줘"처럼 오래 걸리는 위임도 진행 상황을 추적하며 맡길 수 있습니다.
검증된 웹 표준 위에서
A2A가 빠르게 자리 잡은 또 다른 이유는, 완전히 새로운 기술을 발명하지 않았다는 데 있습니다. A2A는 HTTP, 서버-전송 이벤트(SSE), JSON-RPC 2.0 같은 이미 검증된 웹 표준 위에 공통 규칙을 얹는 방식을 택했습니다. 기업 입장에서는 낯선 인프라를 새로 깔 필요 없이, 이미 익숙한 웹 기술 스택 위에서 에이전트 간 통신을 구현할 수 있다는 뜻입니다. 채택의 진입장벽이 그만큼 낮습니다.
누가 이미 쓰고 있나: 기업 프로덕션 현장
표준은 실제로 쓰여야 표준입니다. A2A는 이 점에서도 발표 단계를 넘어섰습니다.
빅3 클라우드 내장과 ServiceNow 'AI Agent Fabric'
앞서 짚었듯 마이크로소프트·아마존·구글이 자사 클라우드에 A2A를 내장했습니다. 대표적인 상용 사례로는 서비스나우(ServiceNow)의 'AI Agent Fabric'이 꼽힙니다. 서비스나우는 A2A 창립 파트너로 참여해, 자사 에이전트와 고객·파트너가 만든 에이전트를 하나로 묶는 멀티 에이전트 통신 계층을 상용화했습니다. 서로 다른 곳에서 만들어진 에이전트들이 한 업무 흐름 안에서 협업하도록 엮은 것입니다.
공급망·금융·보험·IT운영의 초기 배포
리눅스 재단은 A2A가 공급망, 금융 서비스, 보험, IT 운영 등 여러 산업에서 이미 프로덕션 배포에 들어갔다고 밝혔습니다. 구체적인 배포 건수까지 공개되지는 않았지만, 실험실 데모가 아니라 실제 운영 환경에서 에이전트 협업이 돌아가기 시작했다는 신호입니다. 흥미로운 점은 이들이 대체로 규제와 정합성이 까다로운 산업이라는 것입니다. 그만큼 표준화된 통신 규칙의 가치를 먼저 체감하는 영역이라고 볼 수 있습니다.
Linux Foundation 이관이 왜 채택 리스크를 없앴나
기업이 새 표준을 망설이는 가장 큰 이유는 "이걸 채택했다가 특정 벤더에 묶이거나, 표준 자체가 사라지면 어쩌나"라는 불안입니다. A2A는 운영 주체를 구글에서 리눅스 재단으로 넘기면서 이 불안을 상당 부분 덜어 냈습니다. 벤더 중립적인 비영리 재단이 표준을 관리하면, 한 회사의 사업 방향에 표준의 운명이 좌우되지 않습니다. 빅3 클라우드의 동시 채택과 재단 이관이 겹치며, A2A는 "한 회사의 제품"이 아니라 "산업 공용 인프라"에 가까워졌습니다.
우리 기업이 지금 표준화해야 할 것
여기까지가 글로벌 좌표라면, 이제 한국 기업의 자리로 시선을 옮길 차례입니다. 우리나라에서 A2A는 아직 일부 개발자 블로그에서나 다뤄지는 주제입니다. 바꿔 말하면, 경영과 아키텍처 차원에서 미리 준비하는 기업이 앞서갈 여지가 크다는 뜻입니다. 핵심은 "A2A를 당장 도입하라"가 아니라, 단일 벤더에 묶이기 전에 무엇을 표준으로 정해 둘 것인가입니다.
조달·아키텍처 기준에 'A2A 호환성' 선반영
가장 먼저 할 수 있는 일은 의외로 단순합니다. 에이전트 솔루션이나 AI 플랫폼을 도입할 때, 평가 항목에 "A2A 호환 여부"를 한 줄 넣는 것입니다. 지금 당장 멀티 에이전트를 운영하지 않더라도, 향후 다른 에이전트와 엮일 가능성을 염두에 두면 호환성은 미리 확보해 둘 자산입니다. 표준을 따르지 않는 폐쇄형 솔루션은 나중에 통합 비용이라는 청구서로 돌아올 수 있습니다.
벤더 락인을 피하는 오케스트레이터 + 리모트 에이전트 패턴
A2A가 권장하는 기본 구조는 일을 지휘하는 오케스트레이터(orchestrator) 에이전트와, 실제 작업을 처리하는 리모트(remote) 에이전트를 나누는 것입니다. 이 구조의 장점은 분명합니다. 리모트 에이전트가 어느 벤더의 것이든, A2A만 지키면 갈아끼울 수 있다는 점입니다. 특정 벤더의 에이전트 성능이 떨어지거나 가격이 오르면, 같은 인터페이스를 지키는 다른 에이전트로 교체하면 됩니다. 벤더 종속(lock-in)을 구조적으로 피하는 설계인 셈입니다.
에이전트 간 통신의 권한·신원 거버넌스
밝은 면만 있는 것은 아닙니다. 에이전트들이 서로 일을 주고받기 시작하면, 그 사이의 통신 자체가 새로운 공격 대상이 됩니다. 한 에이전트가 다른 에이전트에게 과도한 권한을 위임하거나, 위장한 에이전트가 작업을 가로채는 위험이 생깁니다.
이 문제는 한국에서도 이미 경고등이 켜졌습니다. 삼성SDS가 IT 보안 실무자 667명을 조사한 2026년 보안 전망에서, 응답자의 81%가 AI 기반 위협을 최대 우려로 꼽았고, 특히 사람의 개입 없이 작동하는 자율 에이전트의 취약점이 무단 데이터 접근으로 이어질 위험을 지목했습니다. A2A를 도입하려는 기업이라면, 에이전트마다 신원을 발급하고 권한을 최소화하며, 에이전트 간 통신을 감사 추적하는 거버넌스를 함께 설계해야 합니다. 협업의 통로는 곧 공격의 통로이기도 합니다.
A2A로 인한 기업 AI 연결과 통합의 가능성
2026년 AI 경쟁의 무게중심은 분명하게 이동하고 있습니다. 한때는 "누가 가장 강한 모델을 가졌는가"가 전부였지만, 동급 성능의 모델이 흔해지면서 승부의 축은 그 아래로 내려왔습니다. 모델을 어떻게 연결하고, 에이전트를 어떻게 협업시키며, 그 협업을 어떻게 통제하느냐. A2A는 그 가운데 '연결'을 담당하는 표준이고, MCP와 함께 2026년 AI 에이전트 표준의 두 축을 이룹니다.
한국 기업에게 지금 필요한 것은 서두른 전면 도입이 아닙니다. 오히려 한 가지 질문을 먼저 던져 보는 일입니다. "우리 회사의 에이전트들은, 다른 에이전트와 협업해야 할 때 그럴 준비가 되어 있는가?" 이 질문에 아직 답하기 어렵다면, A2A 호환성을 조달과 아키텍처 기준에 한 줄 더해 두는 것에서 시작해 보시길 권합니다. 에이전트가 혼자 일하던 시대는 이미 지나가고 있으니까요.
참고 문헌
- Linux Foundation / PR Newswire, "A2A Protocol Surpasses 150 Organizations, Lands in Major Cloud Platforms, and Sees Enterprise Production Use in First Year" (2026-06)
- Google Developers Blog, "Announcing the Agent2Agent Protocol (A2A)" (2025-04)
- 삼성SDS, 2026년 보안 전망 (보안뉴스, 2026-02-23)
Share article