A2A 프로토콜 완전정복
MCP만 알면 AI 협업 절반도 못 쓰는 이유
구글이 50개 이상의 파트너사와 함께 만든 AI 에이전트 간 협업 표준,
A2A 프로토콜. 2026년 현재 SAP·Salesforce·Workday까지 실제 도입이 시작됐습니다.
MCP와 어떻게 다르고, 지금 당장 무엇을 알아야 하는지 정리했습니다.
🤝 50+ 글로벌 파트너
🔓 오픈소스 표준
🏢 가트너: 2026년 40% 기업 도입 전망
🔥 A2A 프로토콜이 뭐길래 이렇게 난리인가?
A2A 프로토콜(Agent2Agent Protocol)은 서로 다른 회사가 만든
AI 에이전트들이 벤더나 프레임워크에 상관없이 자유롭게 소통하고 협업할 수 있도록
표준화된 통신 규약입니다. 구글이 2025년 4월 Google Cloud Next에서 처음 공개했으며,
Atlassian·Box·Cohere·Intuit·LangChain·PayPal·Salesforce·SAP·ServiceNow·Workday 등
50개 이상의 기술 파트너, Accenture·BCG·Deloitte·McKinsey·PwC 같은 글로벌 컨설팅사가
동시에 지지를 선언했습니다.
이 프로토콜이 중요한 이유는 딱 하나입니다. 지금까지 AI 에이전트는
사일로(Silo) 안에 갇혀 있었습니다. 예를 들어 인사 에이전트가
채용 플랫폼 에이전트에게 “이 후보자 신원조회 해줘”라고 요청하려면
각 벤더가 따로 API를 짜야 했고, 프레임워크가 달라지면 처음부터 다시 연결 작업을
해야 했습니다. A2A는 이 비효율을 HTTP·JSON-RPC·SSE 같은 기존 표준 위에서
단번에 해결하는 AI 에이전트 세계의 ‘공용어’로 설계됐습니다.
가트너(Gartner)는 2026년 말까지 기업 애플리케이션의 40%에 AI 에이전트가
탑재될 것이라고 전망했으며, 이는 2025년의 5%에서 폭발적으로 증가하는 수치입니다.
이 에이전트들이 서로 대화하는 표준이 바로 A2A입니다.
A2A는 AI 에이전트끼리 서로 대화하는 방법입니다. 둘 다 있어야 에이전트가 제대로 일합니다.
🆚 MCP와 A2A, 도대체 뭐가 다른가?
2024년 11월 Anthropic이 공개한 MCP(Model Context Protocol)가
순식간에 AI 개발 생태계를 흔들었습니다. 그런데 구글이 A2A를 들고 나오자
“또 나왔네” 하는 반응이 많았습니다. 하지만 둘은 경쟁 관계가 아닙니다.
구체적으로 구분하면 아래와 같습니다.
| 구분 | MCP (Anthropic) | A2A (Google) |
|---|---|---|
| 목적 | AI 에이전트 ↔ 도구·데이터 연결 | AI 에이전트 ↔ AI 에이전트 협업 |
| 방향 | 에이전트가 외부 리소스를 가져오는 방향 (수직적) | 에이전트끼리 대등하게 소통하는 방향 (수평적) |
| 메모리·컨텍스트 공유 | 필요 (에이전트가 직접 보유) | 불필요 (각 에이전트 독립적으로 운영) |
| 통신 방식 | JSON-RPC over stdio/HTTP | HTTP + SSE + JSON-RPC + Webhook |
| 장기 작업 지원 | 제한적 | 기본 지원 (비동기 + Webhook) |
| 비유 | AI에게 도구를 쥐어주는 것 | AI들이 팀을 이루어 일하는 것 |
가장 직관적인 비유는 다음과 같습니다. MCP는 “AI 직원에게 업무용 노트북과 사내 시스템 접근 권한을
주는 것”이고, A2A는 “AI 직원들이 사내 메신저로 서로 업무를 주고받는 것”입니다.
완전한 AI 팀을 만들려면 둘 다 필요합니다. 구글도 공식 문서에서
“A2A는 MCP를 보완하는 프로토콜”이라고 명시하고 있습니다.
AI 에이전트 시스템의 절반만 이해하고 있는 것입니다. 2026년 이후
엔터프라이즈 AI 시스템은 대부분 A2A + MCP 조합으로 설계될 것이기 때문입니다.
🏗️ A2A 프로토콜의 핵심 설계 원칙 5가지
구글은 파트너사들과 함께 A2A를 설계하면서 5가지 핵심 원칙을 기반으로 삼았습니다.
이 원칙들이 A2A가 단순한 기술 발표가 아니라 실용적인 산업 표준이 될 수 있는
이유를 설명해 줍니다.
-
1
에이전트의 능력을 최대한 수용
A2A는 에이전트가 메모리·도구·컨텍스트를 공유하지 않아도 자연스럽게 협업할 수 있도록
설계됐습니다. 다른 에이전트를 단순한 ‘도구(Tool)’로 보는 것이 아니라,
진짜 대등한 에이전트로 인정한다는 철학이 반영된 원칙입니다. -
2
기존 표준(HTTP·SSE·JSON-RPC) 위에 구축
완전히 새로운 기술을 배울 필요가 없습니다. 기업의 기존 IT 스택과
바로 통합할 수 있도록 이미 검증된 웹 표준 위에 구현됐습니다.
엔터프라이즈 도입 장벽이 낮은 이유가 바로 여기에 있습니다. -
3
기본적으로 보안 보장 (Enterprise-grade 인증)
OpenAPI와 동등한 수준의 엔터프라이즈급 인증·권한 관리를 출시 시점부터 지원합니다.
JWT + JWKS 기반 인증 체계로 Webhook 통신 간 위변조를 원천 차단합니다. -
4
장기 실행 작업 완벽 지원
수 초 안에 끝나는 짧은 작업부터 수 시간이 걸리는 심층 분석 작업까지,
비동기(Webhook) 방식과 실시간 SSE(Server-Sent Events) 방식을 모두 지원합니다.
진행 상황을 실시간으로 사용자에게 알려주는 기능도 기본 탑재입니다. -
5
멀티모달 지원 (텍스트·이미지·오디오·비디오)
에이전트 간 교환할 수 있는 데이터 형식이 텍스트에 국한되지 않습니다.
오디오·비디오 스트리밍까지 지원하여 미래의 다양한 에이전트 응용 분야에
대응할 수 있습니다.
⚙️ A2A 작동 방식: 클라이언트-원격 에이전트 구조
A2A 프로토콜은 크게 클라이언트 에이전트와
원격 에이전트라는 두 역할로 구성됩니다.
클라이언트 에이전트는 작업을 구성하고 전달하는 역할을, 원격 에이전트는
해당 작업을 실제로 수행하는 역할을 맡습니다.
① 기능 검색 (Capability Discovery)
각 에이전트는 JSON 형식의 ‘에이전트 카드(Agent Card)’를 통해
자신이 어떤 기능을 가지고 있는지 알립니다. 클라이언트 에이전트는 이 카드를 읽고
어떤 원격 에이전트에게 작업을 맡길지 판단합니다. 마치 회사 직원 명부처럼,
어떤 에이전트가 어떤 일을 잘하는지 자동으로 탐색할 수 있습니다.
② 작업 관리 (Task Management)
A2A의 모든 통신 단위는 ‘작업(Task)’ 객체입니다. 이 객체에는
고유 ID, 현재 상태, 생성된 결과물(아티팩트)이 포함됩니다. 작업 상태는
submitted → working → input-required / auth-required → completed / failed / canceled
순으로 전환되며, 장기 작업의 경우 Webhook을 통해 클라이언트에게 실시간 업데이트를 보냅니다.
③ 협업 및 컨텍스트 유지 (contextId)
여러 작업이 하나의 대화 흐름으로 이어질 때는 contextId를 공유합니다.
예를 들어 “보트 이미지 생성 → 같은 스타일로 수정” 같은 연속 작업에서,
두 번째 요청이 첫 번째 결과를 참조할 수 있습니다. LLM에게 이전 작업 결과를
통째로 다시 전달하지 않아도 되므로 토큰 비용이 크게 줄어드는 실용적인 장점이 있습니다.
‘에이전트를 도구처럼 쓰지 않는다’는 것입니다. 에이전트는 작업 중에 스스로 판단하고,
추가 정보를 요청하거나, 중간에 인간의 승인을 구할 수도 있습니다.
이것이 진짜 멀티 에이전트 협업의 의미입니다.
🏢 2026년 기업 도입 현황과 실제 활용 사례
A2A 프로토콜은 2025년 4월 발표 당시 이미 50개 이상의 파트너사가 동시에 지지를 선언했고,
2025년 하반기 프로덕션 버전 출시 이후 2026년 현재 실제 기업 적용 사례가 빠르게 늘고 있습니다.
Linux Foundation도 합류하면서 오픈소스 거버넌스 체계도 갖춰졌습니다.
실제 활용 사례 1: 채용 자동화
구글이 공개한 대표 사례입니다. 채용 담당자가 “시니어 소프트웨어 엔지니어 채용” 지시를 내리면,
오케스트레이터 에이전트가 ① 후보자 탐색 에이전트 → ② 면접 일정 에이전트 → ③ 신원조회 에이전트를
A2A로 순서대로 호출합니다. 각 에이전트는 서로 다른 회사의 서비스이지만,
A2A 표준 덕분에 추가 통합 작업 없이 협업할 수 있습니다.
실제 활용 사례 2: 한국 기업 SK·LG·KB의 AI 전환
오픈네트워크 보고서에 따르면, SK는 Microsoft Azure AI와 결합하여 문서 자동화·회의록 생성
에이전트를 배포했으며, LG는 ‘챗다(CHATDA)’라는 AI 에이전트 기반 생산성 도구를 운영하고 있습니다.
KB금융그룹은 Microsoft 365 기반으로 업무 자동화 에이전트를 구축했습니다.
이들 모두 에이전트 간 협업이 필수로 요구되는 구조이며, A2A가 이 협업 레이어를 담당합니다.
실제 활용 사례 3: Salesforce Agentforce × Google Cloud
Salesforce는 자사의 Agentforce 플랫폼에 A2A를 적용하여, Google Cloud 위에서 운영되는 에이전트와
Salesforce CRM 에이전트가 고객 인텐트를 공유하고 협업할 수 있도록 구현했습니다.
단절된 기업 솔루션을 하나의 오케스트레이션된 팀으로 엮는 가장 현실적인 사례입니다.
2025년 불과 5%에서 8배 성장. 이 에이전트들이 협업하는 표준이 A2A입니다.
🔗 A2A × MCP 함께 쓰는 법: 실전 조합 전략
A2A와 MCP를 함께 사용하는 것이 2026년 이후 AI 에이전트 시스템 설계의 표준이 될 것입니다.
Dify 같은 오픈소스 AI 플랫폼도 공식 로드맵에 “build with any framework, equip with MCP,
communicate with A2A”를 명시했습니다. 어떻게 조합하면 효과적인지 세 가지 전략을 정리합니다.
-
A
수직 통합: MCP로 도구 장착 → A2A로 팀 협업
개별 에이전트에게 MCP로 DB·API·파일 시스템 접근 권한을 먼저 부여하고,
그 에이전트들이 A2A를 통해 서로 작업을 주고받는 구조입니다.
가장 완전한 형태의 멀티 에이전트 시스템입니다. -
B
특화 에이전트 조합: 버티컬 AI + A2A 오케스트레이션
법률 특화 AI, 의료 특화 AI, 재무 특화 AI처럼 각 도메인의 버티컬 에이전트를
A2A로 연결하는 방식입니다. 범용 LLM보다 훨씬 높은 정확도를 기대할 수 있습니다.
Salesforce, SAP, ServiceNow가 이 방식으로 구현 중입니다. -
C
점진적 도입: 기존 API를 A2A 에이전트로 래핑
기존 REST API 서비스를 A2A 에이전트 카드로 감싸는 방식으로
A2A 생태계에 단계적으로 합류할 수 있습니다.
전체 시스템을 새로 짜지 않아도 되는 가장 현실적인 시작점입니다.
중요한 것은 A2A와 MCP 중 하나를 선택하는 것이 아니라, 두 프로토콜이 담당하는
레이어가 다르다는 것을 이해하는 것입니다. MCP 없이 A2A만 있으면 에이전트가
외부 세계와 단절되고, A2A 없이 MCP만 있으면 에이전트가 혼자 일해야 합니다.
🔐 A2A 보안과 인증: 기업이 믿어도 되는 이유
AI 에이전트 간 통신에서 가장 우려되는 것은 보안입니다. A2A는 이 부분을 처음부터
기업 수준으로 설계했습니다. 몇 가지 핵심 보안 메커니즘을 살펴보면 신뢰성을
직접 확인할 수 있습니다.
JWT + JWKS 기반 Webhook 인증
에이전트가 비동기 Webhook을 통해 상태를 전송할 때, JWT 토큰에 발급자(issuer)·
대상(audience)·고유 ID(jti)·만료 시간을 포함해 전송합니다. 수신 측은
공개 키(JWKS)로 서명을 검증하므로 위변조가 불가능합니다. 이는 OpenAPI 인증 체계와
동등한 수준이라고 구글이 공식 문서에서 명시하고 있습니다.
Bearer Token · API Key · HMAC · mTLS 지원
Webhook URL 노출 방지, HTTPS 강제 적용, 토큰 기반 인증까지 기업 보안 요구사항에
맞춰 복수의 인증 방식을 선택할 수 있습니다. Cohere는 에어 갭(Air-gapped) 환경에서도
A2A가 신뢰할 수 있는 협업을 보장한다고 파트너 의견서에서 밝혔습니다.
이글루코퍼레이션이 지적한 보안 주의사항
국내 보안 기업 이글루코퍼레이션은 A2A·MCP 프로토콜이 보안에 미치는 영향 분석 보고서에서,
“에이전트 간 권한 위임(Delegation) 범위를 명확히 통제하지 않으면
의도하지 않은 데이터 접근이 발생할 수 있다”고 지적했습니다.
A2A를 도입할 때는 각 에이전트에게 부여하는 권한 범위를 최소 권한 원칙으로 설계하고,
에이전트 카드에 기능 범위를 명확히 선언하는 것이 중요합니다.
① Webhook URL HTTPS 강제, ② JWT 만료 시간 최소화(300초 이내),
③ contextId별 접근 로그 기록 세 가지를 반드시 구현하세요.
❓ 자주 묻는 질문 (Q&A)
A2A 프로토콜은 무료로 사용할 수 있나요?
구글은 2025년 하반기 프로덕션 버전 이후 Linux Foundation 산하에서 중립적 거버넌스로
운영하고 있어, 특정 클라우드 벤더에 종속되지 않고 자유롭게 사용할 수 있습니다.
GitHub(github.com/google/A2A)에서
Python, TypeScript, Java, .NET 샘플 코드를 바로 내려받을 수 있습니다.
MCP를 이미 쓰고 있다면 A2A로 전환해야 하나요?
A2A는 ‘에이전트들이 서로 협업하는 방법’입니다. 두 프로토콜은 담당 레이어가 다르므로
함께 사용하는 것이 정답입니다. Dify의 공식 로드맵처럼
“MCP로 도구 장착 + A2A로 에이전트 간 통신”의 이중 구조가 표준이 될 것입니다.
A2A를 도입하려면 무엇부터 시작해야 하나요?
실행해봅니다. ② 기존에 운영 중인 서비스를 에이전트 카드(Agent Card) 형태로 래핑합니다.
③ LangChain·CrewAI·ADK 같은 프레임워크의 A2A 통합 모듈을 활용해
멀티 에이전트 시나리오를 테스트합니다. 비개발자라면
Dify 같은 노코드 플랫폼의 A2A 지원 버전이 출시되는 시점을 기다리는 것도 방법입니다.
A2A와 OpenAI의 에이전트 표준은 어떻게 다른가요?
아직 범용 개방형 표준을 공식 발표하지 않았습니다. 반면 A2A는
구글뿐 아니라 Salesforce·SAP·ServiceNow·Microsoft 등 150개 이상의 기업이
Linux Foundation을 통해 공동으로 운영하는 사실상의 업계 표준(De facto standard) 위치에
있습니다. 특정 벤더 종속 없이 다양한 AI 에이전트를 연결해야 한다면
A2A가 현재로서는 가장 넓은 생태계를 가지고 있습니다.
A2A가 한국 기업에게 당장 필요한 이유는 무엇인가요?
이들 기업의 시스템은 여러 벤더의 솔루션이 혼재되어 있어, 에이전트 간 연동 표준이 없으면
결국 수동 통합 작업의 반복이 불가피합니다. A2A는 이 비용을 없애주는 표준입니다.
또한 EU AI Act가 2026년부터 본격 적용되면서, 에이전트의 결정 추적 및 감사 체계가
요구되는데 A2A의 작업 로그와 contextId 기반 추적이 이 요구사항을 자연스럽게 충족합니다.
✍️ 마치며 — 총평
A2A 프로토콜은 AI 에이전트 시대의 ‘인터넷 프로토콜(HTTP)’이 될 잠재력을 가지고 있습니다.
HTTP가 없었다면 웹이 없었듯, A2A 없이는 진정한 멀티 에이전트 생태계가 불가능합니다.
2026년 현재 Salesforce·SAP·ServiceNow 같은 기업용 소프트웨어 거인들이 실제로 도입을
시작했다는 사실이, 이것이 단순한 기술 발표를 넘어선 현실이라는 것을 말해줍니다.
개인적으로 가장 주목하는 부분은 ‘비용 효율성’입니다. A2A의 contextId 기반 참조 구조와
비동기 Webhook 처리 방식은 불필요한 LLM 토큰 소모를 크게 줄여줍니다. AI 에이전트를 운영하는
기업 입장에서 인프라 비용을 통제하는 핵심 도구가 될 것입니다.
아직 일반 사용자에게는 생소한 개념이지만, 앞으로 여러분이 쓰는 SaaS 툴들이
“AI가 알아서 다른 서비스에 작업을 넘겨주는” 경험을 제공하기 시작한다면,
그 배후에 A2A 프로토콜이 있다고 보면 됩니다. 지금 이 개념을 이해하는 것이
2026년 AI 시대에서 남보다 앞서가는 가장 빠른 방법입니다.
📌 외부 참고:
구글 A2A 공식 블로그 ·
IBM A2A 개념 가이드
본 포스팅은 공개된 기술 문서 및 뉴스를 기반으로 작성된 정보 제공 목적의 콘텐츠입니다.
특정 제품·서비스의 도입을 보증하거나 권장하지 않으며, 실제 구현 시 공식 문서를 반드시 참조하시기 바랍니다.
기술 사양은 업데이트될 수 있습니다.
댓글 남기기