Google A2A Protocol
A2A 프로토콜, 안전하다는 말이 절반만 맞는 이유
A2A 프로토콜은 2025년 4월 구글이 50개 이상의 파트너사와 함께 발표한 에이전트 간 통신 표준입니다. 공식 발표문에는 “기본적으로 보안 보장(Secure by Default)”이라는 문구가 명시되어 있습니다. 그런데 2026년 현재 실제 운영 환경을 들여다보면 이야기가 달라집니다.
A2A 프로토콜이 뭔지, 한 문장으로 정리하면
A2A(Agent2Agent) 프로토콜은 구글이 2025년 4월 9일 Google Cloud Next 행사에서 처음 공개한 개방형 AI 에이전트 간 통신 표준입니다. 쉽게 말해, 서로 다른 회사가 만든 AI 에이전트끼리 “나 이런 일 할 수 있어”, “그럼 그 일 맡아줘”라는 말을 표준화된 방식으로 주고받을 수 있게 해주는 규격입니다.
기존에 AI를 쓸 때는 에이전트 A와 에이전트 B가 서로 대화하려면 각각의 API를 따로 연결해야 했습니다. 개발자는 두 에이전트가 어떻게 정보를 주고받을지 처음부터 다 짜야 했죠. A2A는 그 수고를 없애줍니다. HTTP, SSE, JSON-RPC처럼 이미 널리 쓰이는 웹 표준 위에 만들어져 기존 IT 스택과 통합이 수월한 게 강점입니다. (출처: Google Developers Blog, 2025.04.09)
💡 공식 발표문과 실제 도입 흐름을 같이 놓고 보니, A2A의 핵심은 기술적 표준화보다 ‘신뢰 경계를 어디에 그을 것이냐’는 설계 결정에 있었습니다.
A2A는 에이전트가 자신의 기능을 JSON 형식 ‘에이전트 카드(Agent Card)’로 공개하고, 다른 에이전트가 이 카드를 보고 작업을 위임하는 구조로 작동합니다. 클라이언트 에이전트가 원격 에이전트에게 작업을 전달하면, 원격 에이전트는 완료 상태를 실시간으로 업데이트하며 돌려줍니다. 구글은 SAP, Salesforce, Workday, PayPal, LangChain 등 50개 이상의 파트너와 함께 이 사양을 공동 설계했습니다.
MCP와 뭐가 다른가 — 경쟁인가, 짝꿍인가
A2A를 처음 접하면 Anthropic의 MCP(Model Context Protocol)와 헷갈리는 경우가 많습니다. 구글은 공식 발표에서 “A2A는 MCP를 보완하는 프로토콜”이라고 명확히 선을 그었습니다. 심지어 A2A GitHub 문서에는 ‘A2A ❤️ MCP’라는 페이지가 따로 있을 정도입니다. (출처: Google A2A GitHub, 2025.04)
| 구분 | MCP | A2A |
|---|---|---|
| 목적 | AI ↔ 외부 도구·데이터 통합 | AI 에이전트 ↔ AI 에이전트 협업 |
| 방향성 | 수직적 (에이전트 → 도구) | 수평적 (에이전트 ↔ 에이전트) |
| 개발사 | Anthropic | Google + 50개 파트너 |
| 통신 기반 | JSON-RPC 중심 | HTTP, SSE, JSON-RPC |
| 주요 키워드 | 통합(Integration) | 협업(Collaboration) |
실무에서는 MCP와 A2A를 층층이 쌓는 방식으로 씁니다. 에이전트가 외부 데이터베이스나 API에 붙을 때는 MCP를, 그 에이전트가 다른 에이전트와 협업할 때는 A2A를 씁니다. 잡코리아 LOOP팀처럼 실제 멀티에이전트 시스템을 구축한 사례를 보면, 도구 액세스엔 MCP, 에이전트 간 소통엔 A2A가 사실상 표준 구성으로 자리 잡고 있습니다. (출처: JobKorea LOOP 에이전트 개발기, 2025.12.30)
“보안 기본 보장”이라더니, 실제로는 이렇습니다
구글 공식 발표문에는 A2A 설계 5원칙 중 하나로 “기본적으로 보안 보장(Secure by Default)”이 명시되어 있습니다. OpenAPI의 인증 체계와 동등한 수준의 엔터프라이즈급 인증·승인을 지원하도록 설계했다는 설명도 함께 담겨 있습니다. (출처: Google Developers Blog, 2025.04.09)
⚠️ 그런데 2025~2026년 실제 침해 사고 분석 결과, 배치된 AI 에이전트의 90%가 작업에 필요한 수준보다 최대 10배 이상의 과도한 권한을 부여받은 상태로 운영되고 있었습니다. 설계는 보안을 고려했지만 운영에서 무너진 겁니다. (출처: Re_search_Lab, 자율형 AI 에이전트 환경의 신뢰 구축, 2026.03.15)
더 직접적인 사례가 있습니다. 2025년 6월, 업무 관리 플랫폼 아사나(Asana)의 MCP 서버가 공개된 지 한 달 만에 다른 사용자 데이터에 무단 접근할 수 있는 버그가 발견됐습니다. 권한 범위 안에서 다른 사용자의 프로젝트·팀·업무 데이터가 노출될 수 있었던 사건입니다. (출처: 이글루코퍼레이션 보안정보, MCP·A2A 프로토콜이 보안에 미치는 영향)
여기서 핵심은 MCP의 취약점이 A2A 레이어에서 증폭된다는 점입니다. Invariant Labs가 발견한 Tool Poisoning Attack(TPA)은 AI 모델에게만 보이는 악성 명령을 도구 설명에 삽입해 민감 데이터를 탈취하는 공격입니다. 이 공격이 A2A 환경에서 실행되면, 단일 에이전트가 아닌 연결된 여러 에이전트로 연쇄 전파될 수 있는 구조가 만들어집니다. 단 하나의 취약 서버가 생태계 전체를 위협하는 셈입니다.
💡 A2A 프로토콜 자체의 설계 결함이 아닙니다. MCP가 만든 신뢰 연결 구조를 A2A가 가로·세로로 확장하면서, 취약점이 파급될 수 있는 반경이 기하급수적으로 넓어지는 겁니다.
에이전트가 많아질수록 보안이 쉬워진다는 오해
A2A를 설명하는 많은 글에서 “전문 에이전트에게 역할을 분산하면 각각이 작은 권한만 갖기 때문에 더 안전하다”는 이야기가 나옵니다. 이 말이 이론적으로 맞는 방향이긴 합니다. 그런데 현실에서는 반대 방향으로 움직이는 경우가 더 많습니다.
이유는 비인간 신원(Non-Human Identities, NHI) 관리 문제에 있습니다. 2026년 현재 엔터프라이즈 환경에서 비인간 신원은 이미 인간 사용자의 50배를 초과했습니다. AI 에이전트는 그 중 가장 빠르게 늘어나는 범주입니다. 에이전트는 인간 사용자보다 약 16배 이상의 데이터를 이동시키며 다수의 클라우드·SaaS 생태계를 쉬지 않고 오갑니다. (출처: Re_search_Lab, 2026.03.15)
💡 에이전트 50개짜리 A2A 멀티에이전트 시스템을 구축하면, IAM 정책을 관리해야 할 비인간 신원 개체도 50개 이상 늘어납니다. 사람이 직접 추적하기 어려운 숫자입니다.
가장 큰 맹점은 “좀비 에이전트(Zombie Agent)”입니다. PoC나 프로젝트 종료 후 삭제되지 않은 에이전트가 여전히 권한을 가진 채 방치되는 경우입니다. 전통적인 IAM 프레임워크는 인간 계정의 수명 주기 관리를 위해 설계됐기 때문에, 비동기적으로 24시간 돌아가는 에이전트의 권한을 추적하는 데 명백한 한계를 보입니다. A2A 도입이 보안 부담을 줄이는 것이 아니라, 기존 IAM 체계의 공백을 드러내는 계기가 되는 이유입니다.
실제 침해 사고에서 드러난 공통 패턴
2025~2026년 사이에 발생한 에이전틱 AI 관련 침해 사고 세 가지를 보면, 공통 패턴이 선명하게 보입니다.
① GTG-1002 공격 (2025년 9월)
중국 국가 배후로 의심되는 위협 그룹이 Claude Code의 에이전틱 기능과 MCP를 결합해 전 세계 30여 개 기업·기관을 공격했습니다. 에이전트들이 정찰→취약점 탐지→권한 획득→데이터 유출의 80~90%를 자율 수행했습니다. (출처: Re_search_Lab, 2026.03.15)
→ 에이전트 자율성이 공격 속도와 규모를 기하급수적으로 키웁니다.
② ServiceNow ‘BodySnatcher’ (CVE-2025-12420, CVSS 9.3)
모든 인스턴스에 동일한 정적 클라이언트 시크릿이 하드코딩돼 있어, 이메일 주소 하나만으로 MFA·SSO를 완전히 우회할 수 있었습니다. 더 심각한 건 인간 승인 절차가 자연어 페이로드 “진행하라(Please proceed)” 한 마디로 무력화됐다는 점입니다. (출처: Re_search_Lab, 2026.03.15)
→ 감독 모드로 설정해도 컨텍스트 검증 없이는 쉽게 뚫립니다.
③ Langflow RCE 연쇄 취약점 (CVE-2025-34291, CVSS 9.8)
코드 검증 API에서 exec()가 샌드박싱 없이 사용자 입력을 실행한 구조가 문제였습니다. AI 에이전트 플랫폼은 다양한 SaaS·클라우드 자격 증명을 중앙에 집중시키기 때문에, 플랫폼 하나가 침해되면 연결된 전체 서비스로 피해가 번집니다. (출처: Re_search_Lab, 2026.03.15)
→ 에이전트 플랫폼은 단순 앱이 아닌 ‘통합 허브’입니다. 공격 가치가 다릅니다.
세 사건의 공통점은 하나입니다. 프로토콜 자체보다 설정과 운영 과정에서 보안이 무너졌다는 점입니다. A2A 프로토콜 설계가 나빠서가 아니라, 도입 과정에서 기존 보안 체계가 에이전트 규모를 따라가지 못했습니다.
A2A를 지금 도입할 때 반드시 챙겨야 할 것
지금까지 나온 보안 연구와 실제 사고 사례를 교차해서 보면, A2A 도입 시 놓치기 쉬운 실무 포인트가 네 가지로 정리됩니다.
에이전트마다 고유 신원(Identity)을 부여할 것
에이전트가 사람의 권한을 그대로 상속받으면 감사 추적이 불가능합니다. OAuth, mTLS 기반의 비인간 신원(NHI)을 각 에이전트에게 독립적으로 부여하고, 작업 완료 후 권한을 즉시 회수하는 JIT(Just-In-Time) 방식이 권장됩니다.
에이전트 카드(Agent Card) 무결성 검증을 빠뜨리지 말 것
A2A에서 에이전트는 자신의 기능을 JSON 카드로 공개합니다. 이 카드가 악성으로 변조되면 Tool Poisoning Attack의 시작점이 됩니다. 카드 설명에 디지털 서명 또는 무결성 체크를 적용하고, 신규 에이전트 카드는 반드시 검토 프로세스를 거쳐야 합니다.
“감독 모드”는 컨텍스트 검증까지 해야 의미가 있습니다
ServiceNow 사건에서 봤듯, 인간 승인 단계도 자연어 페이로드로 우회될 수 있습니다. 비가역적 작업(데이터 삭제, 외부 발송, 자금 이체 등)에는 Human-in-the-Loop 임계값을 설정하되, 승인 요청의 컨텍스트를 명시적으로 검증하는 로직이 있어야 합니다.
MCP 보안부터 먼저 챙길 것
A2A는 MCP 위에 올라타는 구조입니다. MCP 서버의 입력 검증, 프롬프트 인젝션 방어, 자격 증명 관리가 취약한 상태에서 A2A만 도입하면 취약점 파급 반경만 넓어집니다. MCP-Scan(uvx mcp-scan 명령어로 실행 가능)으로 기존 MCP 서버의 보안 상태를 먼저 점검하는 것을 권장합니다.
자주 나오는 질문 5가지
마치며 — 프로토콜이 아니라 설계의 문제입니다
A2A 프로토콜 자체는 잘 만들어진 규격입니다. HTTP 기반의 표준을 활용해 기존 스택과 통합이 쉽고, 장기 실행 작업과 멀티모달 지원까지 갖췄습니다. 50개 이상의 파트너사가 함께 만든 만큼 생태계 지원도 빠르게 확산하고 있습니다.
그런데 “기본적으로 보안 보장”이라는 문구가 도입 조직에게 잘못된 안도감을 줄 수 있다는 점이 걱정됩니다. 프로토콜이 인증 체계를 지원한다는 것과, 실제 운영 환경에서 권한이 적절히 관리된다는 것은 전혀 다른 이야기입니다. 90%의 에이전트가 필요 이상의 권한을 갖고 운영되고 있다는 수치가 이를 잘 보여줍니다.
A2A를 도입하기 전에 MCP 보안부터 점검하고, 에이전트 신원 관리 체계를 먼저 갖추는 순서가 필요합니다. 좋은 도구일수록 그 도구를 책임 있게 쓰는 설계가 뒤따라야 합니다.
본 포스팅 참고 자료
- Google Developers Blog — Agent2Agent(A2A) 프로토콜 발표 (2025.04.09) https://developers.googleblog.com/ko/a2a-a-new-era-of-agent-interoperability/
- Google Cloud Next 25 1일차 요약 — A2A·ADK 포함 공식 발표 (2025.05.02) https://cloud.google.com/blog/ko/topics/google-cloud-next/next25-day-1-recap
- 이글루코퍼레이션 — MCP·A2A 등의 프로토콜이 보안에 미치는 영향 igloo.co.kr
- Re_search_Lab — 자율형 AI 에이전트 환경의 신뢰 구축: 거버넌스 및 보안 아키텍처 심층 분석 (2026.03.15) research4lab.tistory.com
- Google A2A GitHub 공식 사양 https://github.com/google/A2A
※ 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. A2A 프로토콜은 2026.03.23 기준 공개된 사양을 토대로 작성되었으며, 버전 업데이트 및 정식 릴리스에 따라 내용이 달라질 수 있습니다. 보안 취약점 관련 수치는 인용 출처 발표 시점 기준이며, 실제 운영 환경에 따라 다를 수 있습니다.
댓글 남기기