위조된 에이전트 명함이 만드는 위험, A2A는 서명으로 막는다

AI 에이전트가 단일 조직을 넘어 서로 다른 시스템과 공급자 사이에서 협력하는 시대가 왔다. Agent2Agent(A2A) 프로토콜은 이 협력을 가능하게 하는 표준 통신 레이어다. 구글이 개발하고 Linux Foundation의 Agentic AI Foundation(AAIF)으로 이관된 A2A는 150개 이상의 조직이 프로덕션에서 사용하며 에이전트 상호운용성(Interoperability)의 사실상 표준으로 자리잡고 있다. 에이전트 카드(Agent Card)에 암호화 서명을 도입하고 DID(Decentralized Identifier)로 에이전트 신원을 증명하는 v1.0 이후의 보안 아키텍처는 에이전트 신뢰 체계의 새로운 기준을 만들고 있다.

150개 조직이 한 프로토콜에 모인 이유

멀티에이전트 시스템에서 에이전트가 다른 에이전트에게 작업을 위임하려면 공통 언어가 필요하다. A2A 이전에는 각 에이전트 플랫폼이 독자적인 통신 방식을 썼다. LangGraph, AutoGen, CrewAI는 각각 호환되지 않는 에이전트 통신 방식을 가졌고, 다른 플랫폼의 에이전트와 협력하려면 맞춤형 어댑터를 매번 작성해야 했다. 구글이 A2A를 2025년 발표하고 Linux Foundation에 기증한 것은 에이전트 간 통신에서 특정 벤더 종속을 없애기 위해서다. 현재 Google, Salesforce, SAP, Workday, Box, Cohere를 포함한 150개 이상의 조직이 A2A를 프로덕션에서 사용한다.

에이전트 카드(Agent Card)는 에이전트의 디지털 명함이다. 에이전트가 무엇을 할 수 있고, 어떻게 연락하고, 어떤 인증 방식을 요구하는지를 JSON 형식으로 기술한다. 에이전트 카드는 /.well-known/agent.json 엔드포인트에서 공개적으로 제공되며, 다른 에이전트가 협력 전에 상대방 에이전트의 능력과 신원을 확인하는 기반이 된다. 핵심 필드는 에이전트 이름·설명·버전, 지원 스킬 목록, 지원 입출력 형식(텍스트·파일·구조화 데이터), 엔드포인트 URL, 인증 방식, 그리고 서명이다.

위조된 명함이 만드는 위험

서명 없는 에이전트 카드는 위조에 취약하다. 악의적 행위자가 합법적 에이전트를 사칭하는 에이전트 카드를 배포하면, 다른 에이전트가 사칭 에이전트에게 민감한 태스크를 위임할 수 있다. 암호화 서명은 에이전트 카드가 실제로 선언된 도메인 소유자가 발행했음을 수신자가 검증할 수 있게 한다.

개인키 서명부터 도메인 검증까지

A2A의 서명 에이전트 카드는 PKI(Public Key Infrastructure) 기반이다. 에이전트 카드 생성 시 도메인 소유자의 개인키로 서명하고, 공개키를 카드와 함께 배포하거나 공개 레지스트리에 등록한다. 수신 에이전트는 에이전트 카드를 받을 때 서명이 선언된 공개키로 생성됐는지(서명 무결성), 해당 공개키가 도메인 소유자의 것인지(도메인 검증), 에이전트 카드가 유효 기간 내에 있는지(시간 검증) 세 가지를 검증한다.

카드의 표준 JSON 표현에서 서명을 생성하는 정규화 과정이 중요하다. JSON 필드 순서, 공백 처리, 유니코드 정규화가 일관되지 않으면 서명 검증이 실패한다. A2A는 RFC 8785(JCS, JSON Canonicalization Scheme)를 서명 전 정규화 표준으로 채택했다.

⤢✕

중앙 기관 없이 신원을 증명하는 법

DID(Decentralized Identifier)는 중앙 집중 레지스트리 없이 에이전트 신원을 검증하는 방법이다. W3C 표준 DID는 did:method:identifier 형식으로, A2A에서는 did:web:example.com:agents:billing-agent 같은 형태로 에이전트에 고유 식별자를 부여한다.

DID의 핵심은 DID Document다. DID Document에는 에이전트의 공개키, 인증 방법, 서비스 엔드포인트가 포함된다. DID를 가진 에이전트는 상응하는 개인키로 메시지에 서명해 자신의 신원을 증명하고, 수신자는 DID Document의 공개키로 서명을 검증한다. DID는 중앙 CA(Certificate Authority) 없이 신원 검증이 가능해 단일 장애점을 제거하고, 에이전트가 여러 플랫폼에 걸쳐 일관된 신원을 유지할 수 있게 한다.

위임부터 컨텍스트 전달까지 오가는 메시지들

A2A 프로토콜은 네 가지 핵심 메시지 유형을 정의한다. 태스크 위임(Task Delegation)은 에이전트 A가 에이전트 B에게 특정 태스크를 위임하며 태스크 ID, 입력 데이터, 완료 조건, 타임아웃, 콜백 URL을 포함한다. 태스크 상태 업데이트(Task Status Update)는 실행 중인 태스크의 진행 상황을 위임 에이전트에게 알리며 SSE(Server-Sent Events) 또는 웹훅으로 스트리밍 응답을 지원한다. 에이전트 발견(Agent Discovery)은 특정 능력이나 스킬을 가진 에이전트를 검색하며 레지스트리 기반 발견과 P2P 발견 모두 지원한다. 컨텍스트 전달(Context Passing)은 에이전트 간 대화 이력, 공유 메모리, 도구 결과를 안전하게 전달한다.

gRPC와 HTTP를 함께 쓰는 이유

A2A v1.0은 REST HTTP와 gRPC 두 가지 트랜스포트를 공식 지원한다. gRPC는 낮은 지연이 필요한 에이전트 간 실시간 협력에 적합하고, HTTP REST는 표준 웹 인프라와의 호환성을 보장한다. 스트리밍 응답은 gRPC 양방향 스트리밍 또는 HTTP SSE로 구현되며, 장시간 실행 태스크에서 수신 에이전트가 진행 상황을 실시간으로 전달받는 데 필수적이다.

도구와 대화하는 프로토콜, 에이전트와 대화하는 프로토콜

⤢✕

MCP는 에이전트가 툴(도구)과 대화하는 프로토콜이고, A2A는 에이전트가 에이전트와 대화하는 프로토콜이다. 이 두 프로토콜은 경쟁 관계가 아니라 상호 보완 관계다. 프로덕션 멀티에이전트 시스템은 MCP로 외부 도구를 연결하고, A2A로 에이전트 간 조율한다. OpenAI Agent Protocol은 OpenAI 생태계 내 에이전트 통신에 특화됐다. Codex 서브에이전트 API와 연동되지만 크로스 플랫폼 표준화는 A2A가 더 앞서 있다. 업계는 MCP(툴 레이어)와 A2A(에이전트 레이어)의 조합이 표준 아키텍처로 수렴하는 방향으로 움직이고 있다.

Linux Foundation의 Agentic AI Foundation(AAIF)은 A2A와 MCP를 동시에 품고 있다. MCP는 Anthropic이 2025년 12월 AAIF에 기증했고, A2A는 구글이 기증했다. 두 핵심 에이전트 프로토콜이 중립적 재단 산하에서 표준화되는 것은 벤더 중립적 에이전트 생태계 구축의 신호다. AAIF 산하에서 두 프로토콜의 상호운용성 명세가 공동 작업되고 있으며, 이는 서로 다른 플랫폼의 에이전트가 MCP와 A2A를 기반으로 원활하게 협력하는 표준 생태계를 만들 것으로 기대된다.

신원·권한·감사로 쌓는 방어선

에이전트 시스템의 신뢰 계층은 세 단계로 설계해야 한다. 신원 계층(에이전트 카드 서명, DID), 권한 계층(RBAC, 최소 권한), 감사 계층(모든 에이전트 간 통신 로깅)이다. 신원 계층이 없으면 에이전트 스푸핑이 가능하고, 권한 계층이 없으면 과도한 권한의 에이전트가 무단 작업을 수행하며, 감사 계층이 없으면 문제 발생 시 원인 추적이 불가능하다.

Agent2Agent 프로토콜의 에이전트 카드 암호화 서명과 DID 기반 신원 체계는 에이전트 간 신뢰를 기술적으로 보장하는 핵심 메커니즘이다. MCP와 A2A의 역할 분담이 명확해지면서, 두 프로토콜을 기반으로 하는 크로스 플랫폼 에이전트 생태계가 빠르게 성숙할 것이다.