A2A Protocol v1.0 기준
Linux Foundation 공식 표준
A2A 프로토콜, “안전하다”는 말 믿으면 이 조건에서 막힙니다
“기본적으로 보안이 보장된다(Secure by Default)”—구글 공식 발표문에 그대로 나온 표현입니다. 그런데 아리엘 대학교 보안 연구팀이 실제로 프로토콜을 뜯어보니 결론이 달랐습니다. A2A 프로토콜이 뭔지, v1.0이 뭐가 달라졌는지, 그리고 어떤 조건에서 진짜 구멍이 뚫리는지—공식 자료와 학술 논문을 교차해서 확인했습니다.
A2A 프로토콜이란 — 핵심 개념 30초 정리
A2A 프로토콜(Agent2Agent Protocol)은 서로 다른 회사, 서로 다른 플랫폼에서 만들어진 AI 에이전트들이 서로 소통하고 작업을 주고받을 수 있도록 만든 개방형 표준입니다. 구글이 2025년 4월 발표했고, 같은 해 6월 리눅스 재단(Linux Foundation)에 기부해 이제는 완전한 커뮤니티 표준으로 운영됩니다. (출처: Google Cloud 공식 블로그, 2025.07.31)
쉽게 말하면 이렇습니다. 기업 A의 채용 에이전트가 기업 B의 배경조회 에이전트에게 일을 시킬 때, 둘이 서로 다른 프레임워크로 만들어졌어도 A2A 프로토콜이 “공통 언어” 역할을 합니다. 클라이언트 에이전트가 작업을 구성해서 보내면, 원격 에이전트가 수행하고 결과를 돌려주는 구조입니다.
기술 구조는 의외로 새롭지 않습니다. HTTP, SSE(Server-Sent Events), JSON-RPC — 이미 기업이 쓰고 있는 웹 표준을 그대로 씁니다. 새로운 인프라가 필요 없다는 뜻이고, 기존 로드밸런서와 보안 정책을 재사용할 수 있어 도입 비용이 낮습니다.
💡 에이전트 카드(Agent Card)는 A2A의 핵심입니다. /.well-known/agent.json 경로에 위치하는 JSON 파일로, 에이전트의 능력·엔드포인트·인증 요구사항을 기술합니다. 클라이언트 에이전트는 이 카드를 먼저 읽고 어느 에이전트에 일을 맡길지 결정합니다. (출처: A2A 공식 문서, a2a-protocol.org)
v1.0이 v0.3과 결정적으로 다른 이유
A2A Protocol v1.0이 정식 출시됐습니다. AWS·Cisco·구글·IBM Research·Microsoft·Salesforce·SAP·ServiceNow — 8개사 대표가 참여하는 기술 운영위원회(TSC)가 생겼고, 이 버전부터 “프로덕션 준비 완료(Production-Ready)” 표시가 붙었습니다. (출처: A2A Protocol 공식 발표, a2a-protocol.org/announcing-1.0/)
v1.0에서 실질적으로 달라진 것들
가장 눈에 띄는 변화는 서명된 에이전트 카드(Signed Agent Cards) 도입입니다. 이전 버전에서는 에이전트 카드를 누구든 만들 수 있었고, 카드가 진짜 해당 조직 것인지 검증할 방법이 없었습니다. v1.0부터는 암호화 서명으로 에이전트 신원과 메타데이터를 검증합니다. 조직 경계를 넘어 에이전트끼리 만날 때 신뢰 기반을 세울 수 있는 기초가 생긴 겁니다.
멀티 테넌시 지원도 추가됐습니다. 이제 하나의 엔드포인트가 여러 에이전트를 안전하게 호스팅할 수 있어, 대규모 엔터프라이즈 환경에서 운영 비용을 줄일 수 있습니다.
프로토콜 바인딩도 확장됐습니다. JSON+HTTP, gRPC, JSON-RPC를 지원하고, 클라이언트는 폴링·스트리밍·웹훅 중 상황에 맞게 선택해 결과를 받을 수 있습니다. 가장 단순한 형태라면 HTTP 요청 하나로 A2A 인터랙션을 시작할 수 있습니다.
💡 v0.3 → v1.0 마이그레이션은 단계적으로 가능합니다. 인터랙션 프로토콜에 브레이킹 체인지가 있지만, AgentCard는 하위 호환성이 유지돼 v0.3과 v1.0 동작을 동시에 지원할 수 있습니다. 발표문에서 별도 이유를 밝히지는 않았지만, 이미 구축한 기업 시스템을 한 번에 교체하지 않아도 되도록 설계한 것으로 보입니다.
MCP와 A2A, 경쟁이 아니라 역할이 다릅니다
A2A를 소개하는 글 대부분이 “MCP의 대항마” 또는 “MCP와 비교하면 어느 게 나을까”라는 시각으로 접근합니다. 공식 문서를 보면 이 전제 자체가 틀렸습니다.
A2A 공식 문서에는 딱 이렇게 나옵니다: “MCP는 에이전트 내부에서, A2A는 에이전트 사이에서.” MCP(Model Context Protocol)는 단일 에이전트가 외부 도구·API·데이터에 접근할 때 씁니다. A2A는 에이전트 여러 개가 서로 작업을 주고받을 때 씁니다. 하나는 수직 통합, 다른 하나는 수평 통합입니다. (출처: A2A 공식 문서, a2a-protocol.org)
| 구분 | MCP | A2A |
|---|---|---|
| 역할 | 에이전트 ↔ 도구·리소스 | 에이전트 ↔ 에이전트 |
| 관계 | 수직 통합 | 수평 통합 |
| 실제 적용 | 에이전트 내부에서 사용 | 에이전트 간 사용 |
| 개발사 | Anthropic | Google → Linux Foundation |
| 함께 쓰는지 | ✅ 대부분의 시스템에서 MCP와 A2A를 동시에 사용 | |
공식 발표문에서 IBM의 ACP(Agent Communication Protocol)는 A2A 프로토콜에 흡수 통합됐습니다. 이제 A2A는 구글만의 프로토콜이 아닙니다. AWS, Cisco, Microsoft가 TSC에 들어온 시점부터 사실상 업계 표준 경쟁의 우위를 점한 것으로 봐도 됩니다.
“안전하다”는 말이 성립 안 되는 4가지 조건
구글 공식 발표문은 A2A의 5대 설계 원칙 중 하나로 “기본적으로 보안 보장(Secure by Default)”을 명시합니다. 그런데 이스라엘 아리엘 대학교 연구팀이 2025년 발표한 논문에서 이 문장이 정확히 어떤 조건에서 무너지는지를 실험으로 증명했습니다. (출처: Louck et al., “Improving Google A2A Protocol”, arXiv 2505.12490v3)
💡 공식 발표문과 실제 보안 연구 결과를 나란히 놓고 봤을 때 드러나는 차이입니다. “안전하다”고 설계된 것과 “실제로 안전한 것”은 다른 얘기일 수 있습니다.
① 토큰 수명 제어가 없어서 생기는 문제
A2A는 OAuth 2.0 기반이지만, 민감한 거래에 사용하는 토큰의 만료 시간을 엄격히 강제하지 않습니다. 결제 에이전트가 사용한 토큰이 수 시간, 심지어 수 일간 유효한 채로 남을 수 있습니다. 연구팀이 N8N 플랫폼으로 실제 실험한 결과, 2번째 에이전트가 프롬프트 인젝션으로 1번째 에이전트에서 보호된 데이터를 끌어내는 데 성공했습니다. 추가적인 기술 없이도요. 제안된 해결책은 민감 거래 전용 30초~5분짜리 일회성 단기 토큰입니다.
② 강력 고객 인증(SCA)이 없습니다
결제나 신원 전환처럼 고가치 거래에서 2단계 인증이나 생체 인증을 요구하는 강제 장치가 A2A 프로토콜 레벨에서는 없습니다. 2022년 메디뱅크(Medibank) 침해 사고가 정확히 이 조건에서 발생했습니다—MFA가 없어서 9.7백만 명 개인정보가 유출됐습니다. A2A 에이전트가 결제를 중개하는 시나리오에서는 동일한 벡터로 공격이 가능합니다.
③ 토큰 범위(Scope)가 지나치게 넓습니다
항공권 예약을 위해 발급된 토큰이 사용자의 전체 캘린더에 접근하는 상황이 실제로 발생합니다. 연구팀이 제시한 시나리오에서 에이전트가 의료 예약처럼 무관한 캘린더 항목까지 읽었습니다. 흥미로운 수치가 있습니다. 웹상 OAuth 배포의 18.5%가 불필요한 범위를 요청하는 것으로 조사됐습니다. 이는 GDPR 데이터 최소화 원칙 위반이기도 합니다. (출처: Dimova et al. 연구, arXiv 2505.12490v3 인용)
④ 사용자 동의 흐름이 없습니다 — “동의 피로”도 문제
에이전트 간에 민감 데이터가 공유되기 전에 사용자에게 알리거나 동의를 구하는 메커니즘이 A2A 스펙 레벨에서는 없습니다. 동시에 반대 방향 문제도 있습니다. 항공권·호텔·택시를 한 번에 예약할 때 매 거래마다 승인 요청을 반복하면 사용자가 무감각해지는 “동의 피로(Consent Fatigue)”가 발생합니다. 연구팀은 관련 거래 묶음 동의 흐름을 해결책으로 제안했습니다. v1.0 명세에서는 아직 공식 답변을 내놓지 않은 부분입니다.
⚠️ CSA(Cloud Security Alliance)의 MAESTRO 위협 모델링 분석에서도 에이전트 위장(Agent Impersonation), 메시지 인젝션, 프로토콜 다운그레이드 공격 등이 “고위험(High Risk)”으로 분류됐습니다. 특히 에이전트 행동의 비결정성(Non-Determinism) 때문에 동일한 입력도 다른 결과를 낼 수 있어 방어가 더 어렵다는 점이 지적됩니다. (출처: Cloud Security Alliance, 2025.04.30)
실제 기업들은 어떻게 쓰고 있나
공식 사용 사례를 보면 A2A가 어떤 문제를 실제로 풀고 있는지 보입니다. 타이슨 푸드(Tyson Foods)와 고든 푸드 서비스(Gordon Food Service)는 A2A를 써서 두 회사의 에이전트가 실시간으로 제품 데이터와 리드를 주고받는 공급망 채널을 만들었습니다. 서로 다른 회사의 에이전트가 표준 프로토콜로 대화하는 실제 사례입니다. (출처: Google Cloud 공식 블로그, 2025.07.31)
Twilio의 사례는 특히 주목할 만합니다. Twilio는 A2A 프로토콜을 확장해 지연시간 인식 에이전트 선택(Latency-Aware Agent Selection)을 구현했습니다. 각 에이전트가 자신의 응답 지연시간을 브로드캐스트하면, 시스템이 가장 빠른 에이전트에게 작업을 라우팅합니다. 고지연 에이전트밖에 없을 때는 사용자에게 채팅 타이핑 효과음을 재생해 기다리는 느낌을 줄이는 방식도 포함됩니다. A2A 공식 스펙에 없는 기능을 각 기업이 확장해 쓸 수 있다는 걸 보여주는 사례입니다.
💡 Twilio와 타이슨 푸드의 사례를 같이 놓고 보면 흥미로운 패턴이 보입니다. A2A는 완성된 솔루션이 아니라 기업이 자기 방식으로 확장할 수 있는 “언어 규칙”에 가깝습니다. 구현 자율성이 높은 만큼, 확장하는 쪽에서 보안 설계를 함께 책임져야 하는 구조입니다.
ServiceNow는 AI Agent Fabric이라는 멀티에이전트 통신 레이어에 A2A를 적용했고, S&P Global Market Intelligence는 사내 에이전트 생태계 전체의 에이전트 간 통신 표준으로 채택했습니다. 150개 이상의 조직이 파트너로 참여하고 있는데, 이 숫자는 2025년 4월 발표 당시 50개에서 약 3배로 늘어난 것입니다. 반년 만에 파트너가 3배 증가했습니다.
Q&A 5가지
마치며 — 총평
A2A 프로토콜은 멀티에이전트 시대에 필요한 기반을 진지하게 만들고 있는 표준입니다. 구글 혼자 만든 게 아니라 AWS·Microsoft가 TSC에 들어왔고, 리눅스 재단이 관리하며, 150개 이상 조직이 실제로 참여하고 있다는 사실이 그냥 홍보 문구가 아님을 보여줍니다.
솔직히 말하면, “기본적으로 안전하다”는 설계 원칙과 실제 보안 연구 결과 사이에 분명한 간극이 있습니다. 토큰 수명 제어, 강력 인증, 범위 세분화, 동의 흐름 — 이 네 가지는 프로토콜 레벨에서 아직 강제되지 않습니다. 민감한 데이터를 다루는 시스템이라면 이걸 애플리케이션 레벨에서 직접 채워야 합니다. 그 부분을 모르고 “기본적으로 안전하다”는 말만 믿으면 위험합니다.
Twilio가 지연시간 인식 에이전트 선택을 A2A 위에 올린 것처럼, 이 프로토콜은 완성품이 아니라 빌딩 블록입니다. 자체 보안 레이어를 얼마나 잘 올리느냐가 도입의 성패를 가릅니다.
📎 본 포스팅 참고 자료
본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. A2A 프로토콜은 지속적으로 업데이트되는 개방형 표준이므로, 최신 명세는 a2a-protocol.org에서 확인하시기 바랍니다. 본문 내 수치 및 출처는 2026년 3월 26일 기준으로 수집된 자료입니다.
댓글 남기기