AI 에이전트 상호운용 · 2026-10-31
A2A란? Agent2Agent 사양·보안·결제 현황(2026)

A2A는 에이전트 간 연결 형식을 표준화했지만, '상대가 누구인지, 무엇을 할 수 있는지, 문제가 생기면 누가 책임지는지'는 여전히 각 회사가 스스로 채워야 합니다. 이 글은 1차 사양, 논문, 정부 문서를 바탕으로 2026-10-31 기준 현황을 정리합니다.

A2A란? Agent2Agent 사양·보안·결제 현황(2026)

A2A(Agent2Agent)는 서로 다른 회사·서로 다른 프레임워크의 AI 에이전트가 서로의 능력을 발견하고 작업을 위임하며 결과를 교환하도록 하는 개방형 프로토콜로, 2026-10-31 기준 현행 버전은 v1.0.1(2026-05-26)입니다. 연결 형식은 표준화했지만 신원, 권한 부여, 사고 시 책임은 여전히 각 구현에 맡겨져 있으며, 현재로서는 실명이 공개되고 회사 간에 이뤄지며 성과가 측정된 프로덕션 사례도 찾을 수 없습니다.

A2A는 Google이 2025년 4월 발표했고 2025-06-23 Linux Foundation으로 이관됐으며, 2026년 8월에는 MCP와 같은 재단인 Agentic AI Foundation(AAIF)에 합류했습니다. v1.0부터 a2a.proto를 유일한 규범 소스로 삼고 JSON-RPC 2.0, gRPC, HTTP+JSON/REST 세 가지 바인딩을 동시에 지원합니다. 사양의 미해결 과제는 형식에서 신뢰로 옮겨갔습니다. v1.1의 8개 주제, 댓글이 가장 많은 에이전트 신원 이슈(약 658건), 그리고 2026년 8–10월 첫 공식 SDK CVE가 모두 신원, 위임, 권한 부여, 푸시 알림에 집중돼 있습니다. 실제로 운영 중인 것은 대부분 같은 클라우드 플랫폼 내부의 상호운용(AWS, Microsoft, Google)입니다. 일반 기업과 크로스보더 이커머스·물류 사업자에게 현 단계에서 더 안전한 방법은 웹페이지 구조화 데이터와 결정론적이고 읽기 전용인 MCP 도구부터 갖추고, 쓰기·주문·결제 계열 작업은 책임 프레임워크가 나오기 전까지 외부 에이전트에 열지 않는 것입니다.

현행 버전 v1.0.1 TSC 9석 MCP 40,675 대 A2A 622개 repo 실측 유효 카드 0장
작성자웽 칭홍 최종 업데이트 다음 검토 참고 자료 65

HowBridge AI 연구팀이 정리했으며, 1차 사양, GitHub 기록, 학술 논문, 정부 문서를 인용했습니다. 모든 사실에 출처를 달았고, 출처가 서로 어긋나는 부분은 함께 제시했으며, 추론과 업체 주장은 따로 표시했습니다. 이 글은 세 가지 진술을 구분합니다. 1차 사양, 논문, 공식 문서로 뒷받침되는 것은 사실로 쓰고 출처를 달았습니다. 보도자료와 업체 블로그 중 독립적으로 검증할 수 없는 것은 '업체 주장'으로 표시했습니다. 작성자가 증거로부터 도출한 판단은 '추론'으로 표시했습니다.

핵심 결론

  1. A2A(Agent2Agent) 현행 버전은 v1.0.1(2026-05-26)이며, v1.0부터 a2a.proto를 유일한 규범 소스로 삼아 JSON-RPC 2.0, gRPC, HTTP+JSON/REST 세 가지 바인딩을 지원합니다.
  2. A2A와 MCP의 경계는 추론 루프를 누가 쥐느냐입니다. MCP는 호출 측 LLM이 도구를 제어하고, A2A의 상대는 스스로 추론하는 불투명한 에이전트입니다. MCP의 GitHub repo 수는 A2A의 약 65배(40,675 대 622)입니다.
  3. A2A 사양은 권한 부여를 구현에 맡기고 카드 서명은 선택 사항입니다. 2026년 8–10월 첫 공식 SDK CVE가 나왔고, a2a-java는 기본적으로 읽기 권한 검사를 하지 않았습니다(CVSS 7.5).
  4. 2026-10-31 기준, 실명이 공개되고 회사 간에 이뤄지며 성과가 측정된 A2A 프로덕션 사례는 찾을 수 없습니다. 실제로 운영 중인 것은 같은 클라우드 플랫폼 내부의 상호운용입니다.
  5. AI 에이전트 결제는 체크아웃, 권한 증빙, 머신 마이크로페이먼트 세 계층으로 나뉩니다. AP2는 분쟁 책임을 배분하지 않으며, x402 거래 건수는 대부분 부풀리기용 거래입니다.
  6. 대만 「인공지능 기본법」은 시행됐지만 에이전트를 언급하지 않습니다. 디지털발전부의 위험 프레임워크는 'AI 자율 에이전트의 권한 밖 행위'를 위험 B6으로 분류했습니다.
  7. 크로스보더 이커머스·물류 사업자는 지금 웹페이지 구조화 데이터와 결정론적 MCP 도구부터 갖춰야 하며, 주문·결제 계열 작업은 당분간 외부 에이전트에 열지 않는 것이 좋습니다.

A2A 프로토콜이란 무엇이며 누가 관리하나요?

A2A(Agent2Agent) 프로토콜은 Google이 2025년 4월 발표하고 2025-06-23부터 Linux Foundation이 관리하는 에이전트 간 개방형 프로토콜로, 2026-10-31 기준 현행 버전은 v1.0.1(2026-05-26)입니다. 서로 다른 조직에 속한 AI 에이전트가 서로의 능력을 발견하고 작업을 위임하며 결과를 교환하는 데 쓰입니다.

A2A 공식 측이 설명하는 MCP와의 역할 분담은 이렇습니다. "MCP는 수직적이며 단일 에이전트를 깊게 만들고, A2A는 수평적이며 경계를 넘어 에이전트를 연결한다." A2A에서 호출받는 쪽은 '불투명한' 에이전트입니다. 스스로 추론하고 스스로 상태를 보관하며, 호출하는 쪽은 그 내부에서 어떤 모델이나 도구를 쓰는지 볼 수 없고, 양측은 작업(Task)의 생명주기를 통해서만 여러 차례 주고받습니다. 대만 공식 문서도 이미 A2A를 다루고 있습니다. 디지털발전부 「공공부문 인공지능 활용 참고 매뉴얼」 V1.0(문서상 제공일 115-01-28, 민국 연호) 14쪽에 'A2A: AI 에이전트 간 통신 프로토콜' 소절이 있으며, A2A가 '클라이언트-원격' 간 통신에 초점을 둔다고 설명합니다.

A2A의 거버넌스는 세 단계를 거쳤습니다. 2025-06-23 Linux Foundation이 인수를 발표했고 창립 멤버는 AWS, Cisco, Google, Microsoft, Salesforce, SAP, ServiceNow였습니다. 2025-08-29에는 IBM이 주도하던 ACP가 A2A에 통합되며 개발을 중단했습니다. 실질적 결정권은 9석의 기술운영위원회(TSC)에 있으며, 회사당 한 석입니다: Google, Microsoft, Cisco, AWS, Salesforce, ServiceNow, SAP, IBM, Bloomberg. 안건은 TSC Review 라벨이 붙은 GitHub issue에서 gitvote로 표결합니다. 예를 들어 #1942는 41개 이슈를 v1.1의 8개 주제로 통합했으며, 2026-06-25 찬성 5표, 반대 0표로 통과했습니다(기준 51%).

2026년 8월 A2A는 Growth Stage 프로젝트로 Agentic AI Foundation(AAIF)에 합류해 MCP와 같은 재단에 속하게 됐습니다. 합류 날짜는 출처마다 다릅니다. AAIF 블로그와 Axios는 2026-08-17, A2A 공식 블로그와 사양 페이지는 2026-08-27로 적었고, Forbes 보도 날짜는 08-19입니다. 08-17은 재단의 대외 발표, 08-27은 프로젝트 측 게시일일 가능성이 있지만 이 해석을 뒷받침하는 출처는 없으므로, 이 글은 두 날짜를 함께 표기하고 독자 대신 하나를 고르지 않습니다. Diginomica는 A2A를 AAIF의 5번째 호스팅 프로젝트로 셌으며 앞의 네 개는 MCP, goose, AGENTS.md, agentgateway입니다. 이번 일은 조직 차원의 조정일 뿐 두 사양이 합쳐진 것은 아니라고 강조하는 2차 출처도 있습니다.

A2A 거버넌스 문서에는 '설립 18개월 후 안정기 구성을 결정한다'고 명시돼 있습니다. 2025년 6월부터 계산하면 대략 2026년 12월에 만료되는데, AAIF 공지는 TSC 개편 여부를 밝히지 않았습니다. 이는 추론이지만, TSC 구성이 가까운 시일 내에 바뀔 수 있다는 뜻이므로 지켜볼 만합니다.

A2A의 6가지 핵심 용어(v1.0 사양 기준)
용어무엇인가v1.0에서 주의할 점
Agent Card에이전트의 공개 '명함'으로 스킬, 인터페이스, 인증 방식을 선언하며 관례상 /.well-known/agent-card.json에 둡니다supportedInterfaces[] 중심으로 변경; 카드 서명은 선택 사항
Task한 번의 협업 단위로, 자체 상태 머신을 가집니다taskId는 항상 서버가 생성; 종료 상태에 들어간 작업은 재시작할 수 없음
Message양측이 주고받는 메시지 한 건에이전트는 Task를 만들지 않고 Message만 반환할 수 있으므로 클라이언트는 두 경우를 모두 처리해야 함
Part메시지나 산출물 안의 콘텐츠 조각text, raw, url, data 중 하나로 평탄화되고 kind 판별 필드는 제거됨
Artifact작업의 산출물작업 진행에 따라 스트리밍으로 전송 가능
Extension코어 외부에 기능을 추가(예: 결제)URI로 식별하며, 코어 데이터 구조를 수정하거나 enum 값을 추가할 수 없음

집운·통관 AI 빠른 답변: AI와 크로스보더 물류 Q&A 더 보기

근거 출처 A2A Specification| A2A and MCP(A2A 공식 설명)| Linux Foundation: A2A 프로젝트 출범 보도자료(2025-06-23)| LF AI & Data: ACP의 A2A 통합| A2A GOVERNANCE.md| A2A Issue #1942(v1.1 주제 표결)| AAIF：A2A joins AAIF| Axios（2026-08-17）| A2A 공식 공지(2026-08-27 AAIF 합류)| Forbes（2026-08-19）| Diginomica| 디지털발전부 「공공부문 인공지능 활용 참고 매뉴얼」 V1.0

A2A v1.0은 무엇이 바뀌었나요? 작업·스트리밍·푸시는 어떻게 동작하나요?

A2A v1.0.0(CHANGELOG 기준 2026-03-12 출시)은 a2a.proto를 유일한 규범 소스로 삼아 같은 proto에서 JSON-RPC 2.0, gRPC, HTTP+JSON/REST 세 바인딩을 도출하고, 메서드 이름을 전면 변경하며 Part 데이터 구조를 평탄화했습니다. 2026-05-26의 v1.0.1은 1.0.0과 와이어 호환되는 패치 버전입니다.

A2A v1.0에서는 메서드 이름이 모두 바뀌었습니다. message/send는 SendMessage로, message/stream은 SendStreamingMessage로, tasks/resubscribe는 SubscribeToTask로 바뀌었고 ListTasks가 새로 추가됐습니다. REST 경로는 AIP 스타일(예: POST /tasks/{id}:cancel)로 바뀌고 /v1 접두사가 빠졌습니다. HTTP 오류 형식은 RFC 9457의 application/problem+json에서 google.rpc.Status로 바뀌었고, reason은 대문자+밑줄 표기(예: TASK_NOT_FOUND), domain은 "a2a-protocol.org"로 고정됩니다. 연구 노트는 이번 개정이 A2A를 Google API 설계 가이드 스타일로 바꾼 것과 같다고 보는데, 이는 추론입니다.

데이터 모델에서 가장 큰 파괴적 변경은 Part의 평탄화입니다. 기존의 TextPart, FilePart, DataPart와 kind 판별 필드가 모두 제거되고, 하나의 Part 안에 text, raw(bytes), url, data 중 하나만 넣는 방식으로 바뀌었습니다. 판별 방법도 kind를 읽는 대신 어떤 필드가 존재하는지를 보는 방식이 됐습니다. mimeType은 mediaType으로, file.fileWithUri는 url로 이름이 바뀌었습니다. 커뮤니티 보고에 따르면 많은 파서가 아직도 part.kind를 읽고 있으며, 이것이 0.3과 1.0 간 상호운용 실패의 가장 흔한 원인입니다. Agent Card는 supportedInterfaces[] 중심으로 바뀌어, 각 인터페이스가 url, protocolBinding, protocolVersion과 선택적 tenant를 각각 가집니다. 클라이언트는 배열 순서대로 선택하며 fallback을 구현해야 합니다(SHOULD).

버전 협상에는 잘 알려지지 않은 기본값이 하나 있습니다. A2A-Version 헤더가 비어 있으면 0.3으로 간주합니다. 클라이언트는 Major.Minor만 보내고, 서버가 지원하지 않으면 −32009 VersionNotSupportedError를 반환합니다. 같은 에이전트가 supportedInterfaces에 서로 다른 protocolVersion의 인터페이스를 나열해 0.3과 1.0을 공존시킬 수 있습니다. 공식 마이그레이션은 세 단계입니다. 먼저 두 형식을 모두 파싱하고, 다음으로 1.0을 출력하면서 0.3을 읽고, 마지막에 1.0만 남깁니다. Atlassian Forge와 MuleSoft가 모두 0.3→1.0 마이그레이션 가이드를 발표한 것을 보면, 파괴적 변경의 비용을 실제로 치르는 곳이 있다는 뜻입니다.

작업 의미론에는 사양을 끝까지 읽어야 알 수 있는 세부 사항이 몇 가지 있습니다. taskId는 항상 서버가 생성합니다. contextId를 클라이언트가 지정하면 에이전트는 수락하거나 거부할 수만 있고 새로 만들 수는 없으며, taskId와 contextId가 일치하지 않으면 에이전트는 반드시(MUST) 거부해야 합니다. COMPLETED, FAILED, CANCELED, REJECTED 네 가지 종료 상태의 작업에 다시 메시지를 보내면 UnsupportedOperationError가 반환되므로, 이어서 하려면 같은 context에서 새 작업을 열고 referenceTaskIds로 원래 작업에 연결해야 합니다. 상태 머신에는 두 가지 '중단' 상태, 즉 TASK_STATE_INPUT_REQUIRED와 TASK_STATE_AUTH_REQUIRED가 있으며, 블로킹 방식의 SendMessage도 중단 상태를 만나면 반환됩니다.

스트리밍과 푸시의 보장 수준은 대부분이 생각하는 것보다 약합니다. TaskStatusUpdateEvent의 final 플래그가 1.0에서 제거되고 '연결 종료'가 스트림 끝을 뜻하게 됐기 때문에, 작업 도중 연결이 끊긴 것과 작업 완료가 클라이언트에서는 똑같이 보이며 GetTask나 SubscribeToTask를 다시 호출해야 구분할 수 있습니다. 사양에는 이벤트 ID 기반 재개 메커니즘도 없어 v1.1 주제 #1986으로 올라가 있습니다. 푸시 알림은 StreamResponse를 HTTP POST로 클라이언트 webhook에 보내는 방식이며 Content-Type은 application/a2a+json입니다. 사양은 에이전트가 최소 한 번 전송을 시도하고 타임아웃은 약 10–30초로 하도록(SHOULD) 요구할 뿐이며, 수신 측은 멱등하게 처리해야 하고(SHOULD) taskId를 반드시 대조해야(MUST) 합니다. 다시 말해 푸시는 '최소 한 번, 순서 미보장, payload 서명 없음'이며, 이는 사양에서 추론한 결과입니다. 멱등성도 절반만 구현됐습니다. SendMessage는 messageId로 중복을 제거'할 수 있지만' 필수는 아닙니다.

날짜와 수량에서 출처가 서로 어긋나는 곳이 두 군데 있습니다. v1.0 출시일은 CHANGELOG가 2026-03-12, 한 서베이 논문(arXiv:2507.10644 v4)이 2026년 1월로 적었고, Linux Foundation 1주년 보도자료는 v1.0이 첫 안정 버전이라고만 할 뿐 날짜를 밝히지 않았습니다. 이 글은 1차 출처인 CHANGELOG를 따릅니다. SDK 수는 Linux Foundation이 2026-04에 'production-ready' 언어 5개라고 했고, A2A 공식 공지는 Python, Go, Java, JS, .NET, Rust 총 6개를 나열했지만, 상세히 테스트된 Rust SDK는 커뮤니티 버전입니다.

A2A 버전과 거버넌스 변천(2025-04 ~ 2026-10)
날짜버전 또는 사건요점증거 등급
2025-04Google, A2A 발표50여 개 파트너2차 출처
2025-05-270.2.1referenceTaskIds, extended card 불리언 추가1차(CHANGELOG)
2025-06-090.2.2파괴적인 JSON-RPC 정렬; gRPC/REST 정의; extensions1차(CHANGELOG)
2025-06-23Linux Foundation 인수창립 멤버 7개사1차(LF 보도자료)
2025-06-300.2.5Agent Card에 protocolVersion 필수화; 작업마다 여러 푸시 설정 가능1차(CHANGELOG)
2025-07-300.3.0agent.json을 agent-card.json으로 이름 변경(파괴적); 카드 서명; mTLS; 스킬 수준 보안1차(CHANGELOG)
2025-08-29IBM ACP의 A2A 통합ACP 개발 중단1차(LF AI & Data)
2026-03-121.0.0proto를 규범으로, Part 평탄화, 메서드 이름 변경, 버전 협상, 멀티테넌시, ListTasks1차(CHANGELOG); 별도로 2026년 1월로 적은 논문 있음
2026-05-261.0.11.0.0과 와이어 호환되는 패치; 권장 미디어 타입 application/a2a+json1차(CHANGELOG)
2026-08-17 또는 08-27AAIF 합류MCP와 같은 재단출처 간 날짜 불일치
2026-10-01공식 a2a CLI 출시명령줄 도구1차(A2A 공지)

근거 출처 A2A Specification| What's new in A2A v1| A2A CHANGELOG| A2A 공식 공지| DEV Community：A2A tech update（2026-03-20）| Atlassian Forge: A2A 0.3→1.0 마이그레이션| MuleSoft: A2A Connector 업그레이드 마이그레이션| Petrova et al., Web of Agents（arXiv:2507.10644 v4）| Linux Foundation: A2A 1주년 보도자료| philippdubach: MCP vs A2A in 2026(2025-04 발표 배경)

A2A와 MCP는 무엇이 다르고, 어느 것을 써야 하나요?

A2A와 MCP의 진짜 경계는 추론 루프를 누가 쥐느냐입니다. MCP는 호출 측 LLM이 제어하고 상대는 schema가 투명한 도구만 내놓는 반면, A2A의 상대는 스스로 추론하고 스스로 상태를 보관하는 불투명한 에이전트입니다. 두 프로토콜의 채택 규모는 한두 자릿수 차이가 나며, mcp-server topic이 붙은 GitHub repo는 40,675개, a2a-protocol이 붙은 repo는 622개입니다.

지난 1년간 'MCP에 Tasks가 추가됐으니 A2A는 필요 없다'는 말을 자주 들었지만, MCP 2026-07-28 버전의 실제 방향은 정반대입니다. MCP 2025-11-25 버전은 실험적인 Tasks(SEP-1686)를 추가했는데, 장시간 요청 추적, 폴링, 결과 지연 수령이 용도이며 그 상태(working, input_required, completed, failed, cancelled)는 A2A와 거의 일대일로 대응합니다. 그러나 2026-07-28 버전은 session과 initialize 핸드셰이크를 제거해 MCP를 무상태로 만들었고(SEP-2567, SEP-2575), Tasks를 코어에서 빼내 공식 확장 io.modelcontextprotocol/tasks로 옮겼으며(SEP-2663), 서버가 먼저 보내는 요청을 MRTR(InputRequiredResult와 재전송 시 첨부하는 inputResponses)로 대체하고(SEP-2322), Sampling, Roots, Logging을 deprecated로 지정했습니다(SEP-2577).

이 변경들은 MCP 메인테이너가 '서버가 거꾸로 호출 측 LLM의 추론을 빌리는' 에이전트화 노선을 의도적으로 포기했다는 뜻이며, 이는 추론입니다. MCP 서버가 스스로 추론하려면 자체 모델을 갖춰야 하는데, 그 시점이면 겉모습만 도구일 뿐 사실상 불투명한 에이전트입니다. MCP의 Task가 다루는 것은 '한 번의 장시간 도구 호출 결과를 나중에 받는 일'이고, A2A의 Task가 다루는 것은 '양측 모두 질문할 수 있는 다회차 협업'이며, 여기에 Agent Card 발견, 스킬 선언, artifact 스트리밍이 더해집니다. 반대 방향의 실패 시나리오도 있습니다. 가격 조회나 세율 조회 같은 결정론적 조회에 Task, Message, Artifact 생명주기를 억지로 씌우면 지연과 구현 비용이 모두 늘고, 호출 측 LLM은 세밀한 도구 schema도 얻지 못합니다. 이 역시 추론입니다. 연구 노트는 'MCP로 에이전트 간 통신을 하다 실패한' 사례나 'A2A로 도구를 감싸다 실패한' 실제 사고 기록을 찾지 못했습니다.

채택 측면에서는 GitHub topic 수 외에도, 체계적이지 않은 PyPI 비교에서 A2A SDK는 약 1,090만 회, MCP SDK는 약 2.57억 회 다운로드됐습니다. 2차 출처에 따르면 Shopify의 UCP 엔드포인트는 MCP를 전송 계층으로 사용하며, 즉 주요 커머스 에이전트가 연결할 때 쓰는 것은 MCP입니다. 클라우드 플랫폼별로 보면, AWS AgentCore Runtime은 A2A 서버를 배포할 수 있고(JSON-RPC, POST /, port 9000, OAuth 2.0 또는 SigV4), Microsoft Foundry의 A2A 지원은 2026년 6월 public preview에 들어갔으며, Google Agent Registry는 well-known 카드를 읽지만 자동 발견은 같은 프로젝트 내로 한정됩니다. 연구 노트가 확인한 주요 모델 업체 가운데 Anthropic은 현재 네이티브 A2A 지원이 없으며, Claude Code 관련 issue #104852는 2026년 10월 하순에야 열렸습니다.

실무에서 고르는 방법은 간단합니다. AI 어시스턴트가 결정론적 기능(견적, 세율 조회, 화물 추적)을 호출하게 하려면 MCP를 쓰고, 각자 추론하며 서로 다른 조직에 속한 두 에이전트가 여러 차례 협업해야 할 때에만 A2A가 필요합니다. HowBridge의 공개 MCP는 전자에 해당하며, 연결 방법은 사이트 내 배송대행 MCP 가이드를 참고하세요.

A2A와 MCP 비교 개념도: 왼쪽은 한 에이전트가 MCP로 데이터베이스, 계산기, 문서, 검색 등의 도구를 호출하는 모습이고, 오른쪽은 가정과 물류 창고라는 두 조직에 속한 에이전트가 조직 경계를 사이에 두고 A2A로 작업을 주고받는 모습입니다
AI 생성 개념도: MCP는 '에이전트-도구'를 잇는 수직 연결이고, A2A는 '에이전트-에이전트'를 잇는, 조직 경계를 넘는 수평 협업입니다.
A2A와 MCP 비교(2026-10-31 기준)
비교 항목MCPA2A
연결 대상에이전트와 도구·리소스에이전트와 에이전트
추론 루프를 누가 제어하나호출 측 LLM원격 에이전트 자신
상대의 투명성도구 schema가 투명불투명하며 Agent Card 선언만 볼 수 있음
상태2026-07-28 버전에서 무상태로 전환, Tasks는 공식 확장으로 이동상태를 가진 Task 생명주기, 다회차 지원
발견 메커니즘MCP Registry(2025-09부터 현재까지 프리뷰)/.well-known/agent-card.json; 공식 레지스트리는 제공하지 않음
적합한 시나리오가격·세율 조회 같은 결정론적 조회조직을 넘나들고, 다회차이며, 상대의 판단이 필요한 협업
GitHub repo 수40,675（mcp-server topic）622（a2a-protocol topic）
재단AAIF2025-06부터 Linux Foundation; 2026-08 AAIF 합류

배송대행 MCP 가이드: Claude 디렉터리에서 HowBridge 연결하기 ・ HowBridge 개발자 플랫폼: 공개 MCP와 회원 MCP 안내

근거 출처 A2A and MCP(A2A 공식 설명)| MCP 2025-11-25 changelog| MCP 2026-07-28 changelog| WorkOS：MCP 2025-11-25 spec update| gravity.fast：MCP adoption statistics| Hacker News 관련 토론(PyPI 다운로드 비교)| Presta: UCP와 AI 쇼핑 에이전트 가이드| AWS：AgentCore Runtime A2A protocol contract| Microsoft 365 Message Center AZ563716| Google Cloud：Agent Registry automatic registration| anthropics/claude-code Issue #104852

A2A는 안전한가요? 알려진 취약점과 CVE는 무엇인가요?

A2A 사양은 자격 증명을 '어떻게 선언하고 어떻게 전달하는지'만 규정하고, 권한 부여는 각 구현에 맡기며 Agent Card 서명도 선택 사항입니다. 2026년 8–10월 첫 공식 SDK CVE가 나왔으며, 그중 a2a-java의 CVE-2026-111764는 기본적으로 읽기 권한 검사를 하지 않아 High(CVSS 7.5)로 평가됐습니다.

A2A의 Agent Card는 securitySchemes로 다섯 가지 인증 방식 중 하나를 선언합니다: API Key, HTTP Auth, OAuth2, OIDC, mTLS. v1.0은 OAuth의 implicit와 password flow를 제거하고 Device Code를 추가했으며, 모든 클라이언트에 PKCE 사용을 권장합니다. 사양은 서버가 "MUST authenticate every incoming request"라고 요구하지만, 권한 부여는 implementation-specific이며 자격 증명은 대역 외(out-of-band) 경로로 얻어야 합니다. 작업이 AUTH_REQUIRED 상태에 들어갈 때 사양은 특별히 "Agents MUST NOT treat the state transition alone as authorization"이라고 명시합니다. 13절 '보안 고려 사항'은 prompt injection, 위임이나 token exchange, OpenTelemetry를 전혀 언급하지 않으며, 테넌트 격리에 관한 별도 요구도 없습니다. Semgrep은 v0.3 시기 논평에서 A2A가 "supports but does not enforce Agent Card signing"이며, token 수명과 scope는 프로토콜의 제약을 받지 않고, 같은 작업에 여러 병렬 스트림이 있을 수 있어 탈취된 session token으로 피해자의 스트림을 조용히 엿들을 수 있다고 지적했습니다.

Agent Card에 서명하더라도 현재로서는 SDK 간 검증이 보장되지 않습니다. 사양의 방식은 먼저 RFC 8785(JCS)에 따라 카드를 정규화(signatures 필드 제외)한 뒤 JWS를 적용하는 것이며, protected header에는 alg와 kid가 반드시(MUST) 포함돼야 합니다. Issue #2122(2026-08-10 개설, 2026-10-31 기준 미종료)는 실측 차이를 기록했습니다. a2a-python 1.1.2와 @a2a-js/sdk 1.0.1이 정규화한 바이트가 서로 다릅니다. Python은 비ASCII 문자를 \uXXXX로 이스케이프하고, UTF-16 단위가 아닌 code point 기준으로 정렬하며, 숫자를 1e-06으로 출력하는 반면 ECMAScript는 0.000001을 출력합니다. 사양은 REQUIRED 필드가 기본값이어도 나타나야 한다고 요구하지만 proto3에는 presence 개념이 없어 description: ""과 skills: []가 버려지며, typ에도 모호함이 있습니다. PR #2319가 사양 예제를 고쳤지만 a2a-go의 출력은 여전히 다릅니다. 또 다른 한계는, 서명 검증이 통과해도 카드가 변조되지 않았다는 것만 증명할 뿐 발급자의 신원은 증명하지 않는다는 점입니다. 커뮤니티는 사양에 카드를 실제로 호출을 보내는 실행 환경에 묶는 메커니즘이 전혀 없다고 지적합니다.

사양을 완전히 준수해도 성립하는 공격이 있습니다. A2ABreak(arXiv:2609.10871, v3 2026-10-24)는 LLM으로 자연어 사양에서 37개 상태, 76개 전이, 929개 형식화 진술을 추출해 11개의 새로운 취약점을 찾았으며, 모두 "구현 결함이 전혀 필요 없고 사양을 준수하는 공격자가 악용할 수 있는" 것이었습니다. 예를 들어 context identifier가 보호되지 않아 클라이언트 간 context 주입이 생기고, 위임 체인이 여러 홉을 거친 뒤 신원이 사라지며, 에이전트가 검증되지 않은 능력을 주장할 수 있습니다. 이름 충돌 연구(arXiv:2609.27624)는 사양이 name을 "human-readable metadata, not as a stable identity"로 규정하고 충돌 규칙을 정의하지 않았다고 지적했습니다. 저자가 추적한 오픈소스 구현 7개 가운데 클라이언트형 통합 6개가 공격자가 제어하는 엔드포인트로 요청을 보냈으며, 저자는 이를 보편적인 프로토콜 취약점이 아니라 반복적으로 나타나는 구현 취약점 유형으로 규정했습니다. Palo Alto Networks 산하 Unit 42가 Google ADK로 만든 session smuggling 개념 증명은 악성 에이전트가 '확인 질문'으로 시스템 지시를 빼내고, 클라이언트가 buy_stock을 호출해 승인 없이 10주를 매수하도록 유도하는 모습을 보여 줬습니다. Unit 42는 이것이 프로토콜 취약점이 아니며 상태를 가진 모든 다회차 프로토콜이 영향을 받을 수 있고, 실제 환경에서의 악용은 확인되지 않았다고 명확히 밝혔습니다. 커뮤니티는 또한 악성 서버가 Agent Card의 description이나 skills 필드에 지시를 숨겨 호스트 LLM이 이를 지시로 실행하게 만들 수 있다고 보고했습니다.

에이전트 간 공격에 대한 학계의 실증 연구도 '에이전트 사이의 신뢰를 기본값으로 둘 수 없다'는 결론을 뒷받침합니다. Triedman 등(COLM 2025)은 악성 웹 콘텐츠가 멀티 에이전트 시스템의 제어 흐름을 탈취할 수 있음을 발견했으며, GPT-4o의 경우 임의 코드 실행이 시행의 58%–90%에서 성공했습니다. Ferrag 등은 ICT Express(2026)에 실린 동료 심사 리뷰에서 prompt injection부터 프로토콜 계층 공격까지 정리했으며 MCP와 A2A를 모두 다룹니다.

아래 표의 CVE 번호는 연구 노트를 그대로 옮겼습니다. 연구 노트 자체가 이 번호들의 숫자가 이례적이며 일부 항목은 단일 데이터베이스에서만 확인된다고 주석을 달았습니다(예: CVE-2026-90790은 a2a-python repo에 대응하는 GHSA가 없고 OpenCVE에서만 확인됨). a2a-js, a2a-go, a2a-dotnet의 repo advisories 조회 결과는 비어 있었지만, 이는 권한 부족 때문일 수 있으며 취약점이 없다는 뜻은 아닙니다. 이 표에서 세 가지 교훈을 끌어낼 수 있으며, 다음은 추론입니다. 첫째, Agent Card는 공격자가 제어할 수 있는 입력이며 header 이름조차 상대가 정할 수 있습니다. 둘째, 사양에 'webhook URL을 검증해야 한다(SHOULD)'고만 적혀 있어 두 언어의 SDK 모두 SSRF가 발생했습니다. 셋째, 사양이 '권한 부여는 구현이 결정한다'고 하자 가장 인기 있는 Java SDK가 기본적으로 권한 검사를 하지 않았고, 그 패치마저 Android 플랫폼 차이로 우회됐습니다.

A2A 관련 SDK와 구현의 공개 취약점(2025–2026, 번호는 연구 노트 원문 그대로)
번호구성 요소문제심각도
GHSA-qw47-mcm5-934w／CVE-2026-111764a2a-java server-common < 1.3.0.FinalInMemoryTaskStore의 인수 없는 생성자가 authorizationProvider를 null로 설정해 기본적으로 읽기 권한 검사를 하지 않음(fail-open)High，CVSS 7.5
GHSA-9rhm-2h4x-jwmx／CVE-2026-111763a2a-java < 1.3.0.Final악성 AgentCard가 APIKeySecurityScheme로 사용자 지정 header 이름을 지정한 뒤 redirect를 반환해 API key가 제3자에게 전달됨Medium
GHSA-4fpj-g9jf-9rgg／CVE-2026-111765a2a-java（Android）Android 동기 POST가 앞 항목의 redirect 패치를 우회High
GHSA-q78c-5jjq-57g8／CVE-2026-111761a2a-java푸시 알림 SSRFMedium
GHSA-x32g-jvvm-4725／CVE-2026-111762a2a-javaprotobuf 파싱 실패 시 푸시 자격 증명을 평문으로 log에 기록Medium
CVE-2026-90790a2a-python ≤ 1.1.3_dispatch_notification에서 push_info.url을 통한 SSRF, 1.1.4에서 패치; repo에 대응 GHSA 없이 OpenCVE에서만 확인CVSS 6.3
CVE-2026-115419／GHSA-4v6f-7vjh-6x4mStrands Agents A2A 서버서로 다른 context_id의 호출자가 대화 기록을 공유; 완전한 workaround가 없어 테넌트마다 인스턴스 하나를 권장High，CVSS 8.1
CVE-2025-6167비공식 python-a2a ≤ 0.5.5경로 순회(공식 a2a-sdk와는 다른 패키지)미표기

근거 출처 A2A Specification（§4.5、§7、§8.4、§13）| Semgrep：A security engineer's guide to the A2A protocol| A2A Issue #2122(서명 정규화 차이)| A2A Discussion #1677| levelup：Signed Agent Cards prove integrity, not identity| Lotfi et al., A2ABreak（arXiv:2609.10871）| Arun Kumar, Agent Name Collision Attacks（arXiv:2609.27624）| Unit 42：Agent session smuggling| langgraph-a2a-client Issue #8(카드 필드 주입 보고)| Triedman et al., Multi-Agent Systems Execute Arbitrary Malicious Code（COLM 2025）| Ferrag et al., ICT Express 12（2026）| GitHub Advisory GHSA-qw47-mcm5-934w| GitHub Advisory GHSA-9rhm-2h4x-jwmx| a2a-java advisory GHSA-4fpj-g9jf-9rgg| a2a-java advisory GHSA-q78c-5jjq-57g8| a2a-java advisory GHSA-x32g-jvvm-4725| OpenCVE：a2a-python| GitLab Advisory：CVE-2026-115419| Vulners：python-a2a

AI 에이전트의 신원과 권한은 어떻게 검증하나요?

2026-10-31 기준 AI 에이전트의 신원과 위임에는 아직 확정된 공통 표준이 없습니다. 워크로드 신원은 IETF WIMSE 워킹그룹이 추진하고, 위임은 대부분 RFC 8693 token exchange를 적용하며, 외부에서 검증 가능한 신원은 Cloudflare Web Bot Auth와 ANS v2 초안 등이 공존합니다. A2A 자체는 선택 사항인 Agent Card 서명만 다룹니다.

에이전트 신원 문제는 A2A 바깥에서 세 계층으로 나뉘고 있습니다. 첫째는 워크로드 신원으로 '이것이 어떤 프로그램인가'에 답합니다. draft-klrc-aiagent-auth의 저자들은 Amazon, Zscaler, Ping Identity, OpenAI 등 출신이며, 이 초안은 IETF WIMSE 워킹그룹에 채택돼 draft-ietf-wimse-aims로 대체됐습니다. 노선은 기존 WIMSE와 OAuth 2.0 계열을 적용하고 '새 프로토콜을 발명하지 않는' 것입니다. 둘째는 권한 부여와 위임으로 '누구를 대리하며 무엇을 할 수 있는가'에 답합니다. Ping Identity의 예시는 RFC 8693 token exchange의 act claim으로 위임 경로 전체를 기록하고 may_act로 다음 홉을 제한합니다. 하지만 RFC 8693은 원래 '동의가 이미 이뤄진 뒤'의 서버 간 교환을 위해 설계됐으며, 특정 에이전트에 대한 사용자의 동의를 기본적으로 다루지 않습니다.

셋째는 외부에서 검증 가능한 신원으로 '낯선 상대가 어떻게 이를 신뢰하는가'에 답합니다. Cloudflare Web Bot Auth는 Ed25519와 RFC 9421로 HTTP 요청에 서명하지만, Cloudflare는 현재 nonce를 검증하지 않아 재전송 방지는 주로 약 1분의 짧은 유효기간에 의존합니다. ANS v2 초안은 ACME로 도메인을 검증하며 Bronze, Silver(DANE 추가), Gold(SCITT 투명성 로그 추가) 세 등급으로 나뉩니다. A2A는 이 계층에서 카드 서명만 다루며, 그 서명도 선택 사항입니다. 상용 제품은 이미 먼저 나왔습니다. Okta Agent SSO는 2026-08-24 정식 출시됐으며 ID-JAG를 사용합니다. Microsoft Entra Agent ID는 ID-JAG를 기본 지원하지 않으며, 정식 출시일은 출처마다 다릅니다(2026-04 또는 2026-05). 따라서 회사 간에 A2A를 할 때는 양측이 각자의 경계에서 token 변환을 해야 할 가능성이 높으며, 이는 추론입니다.

정부 차원에서도 이 공백을 메우고 있습니다. 미국 NIST의 CAISI는 2026-02-17 AI Agent Standards Initiative를 발표했으며, 세 기둥은 산업 주도 표준, 커뮤니티 주도 오픈소스 프로토콜, 에이전트 보안·신원 연구입니다. 다만 이니셔티브 페이지는 "interoperable agent protocols" 같은 포괄적 표현만 쓰고 A2A나 MCP를 지목하지 않습니다. NIST NCCoE의 'Software and AI Agent Identity and Authorization' 프로젝트는 2026-09-29 개념 문서에 대한 의견 요약을 공개했으며, 응답자는 600개 이상의 기관 또는 개인이었습니다. NIST는 2026-10-27 블로그 〈Design Tenets for Agent Identity Management Systems〉에서 10가지 설계 원칙을 제시했습니다. 에이전트에 독립된 신원을 부여하고, 개시자와 연결하며 위임할 때마다 권한을 단계적으로 축소하고, 최소 권한을 적용하며, 권한 부여는 단기적이고 취소 가능하게 하고, 위험에 따라 사람의 개입을 트리거하며, 서명된 mandate로 행동 범위를 정하고, 변조할 수 없는 기록을 남기는 것 등이 포함됩니다. 이는 블로그이며 정식 표준이 아닙니다.

학술 연구의 방향도 이와 일치합니다. South 등은 OAuth 2.0/OIDC 위에 에이전트 전용 자격 증명을 확장하고 감사 가능한 위임 체인을 구축하자고 제안했으며, 같은 연구의 입장 버전은 ICML 2025 Position Paper Track에 수록됐습니다. Chan 등은 FAccT 2024에서 에이전트 식별자, 실시간 모니터링, 활동 로그의 세 가지 조치로 에이전트의 가시성을 높이자고 주장했습니다.

AI 에이전트 신원의 3계층 구조와 현황(2026-10-31)
계층답하는 질문주요 방안현황
워크로드 신원이것이 어떤 프로그램인가IETF WIMSE（draft-ietf-wimse-aims）워킹그룹 초안, 아직 RFC가 아님
권한 부여와 위임누구를 대리하며 무엇을 할 수 있는가RFC 8693 token exchange（act、may_act）이미 RFC이지만 특정 에이전트에 대한 사용자 동의는 다루지 않음
외부에서 검증 가능한 신원낯선 상대가 어떻게 신뢰하는가Cloudflare Web Bot Auth, ANS v2 초안, A2A Agent Card 서명각자 배포 중이며 공통 표준 없음; A2A 서명은 선택 사항
상용 제품기업이 지금 살 수 있는 것Okta Agent SSO(2026-08-24 출시, ID-JAG), Microsoft Entra Agent ID상호 호환성 제한적

근거 출처 IETF Datatracker：draft-klrc-aiagent-auth| Ping Identity: Ping으로 Gemini Agent2Agent 권한 부여하기| Identra：OAuth on-behalf-of| Cloudflare Docs：Web Bot Auth| IETF：draft-narajala-courtney-ansv2-01| Forkast: 6개 업체의 에이전트 신원 제품 출시| tech-insider: AI 에이전트 신원 공급업체 비교| NIST：AI Agent Standards Initiative（2026-02-17）| NIST: Software and agentic AI identity 개념 문서 의견 요약(2026-09-29)| NIST：Design Tenets for Agent Identity Management Systems（2026-10-27）| South et al., Authenticated Delegation and Authorized AI Agents（arXiv:2501.09674）| Chan et al., Visibility into AI Agents（FAccT 2024）

AI 에이전트는 어떻게 결제하나요? AP2, x402와 A2A는 어떤 관계인가요?

AI 에이전트 결제는 현재 체크아웃, 권한 증빙, 머신 마이크로페이먼트의 세 계층 프로토콜로 나뉘며, A2A는 결제 확장을 탑재할 수 있는 통신 계층일 뿐입니다. 그중 AP2 v0.2.0(2026-04-28)은 Checkout Mandate와 Payment Mandate로 바뀌었고 2026-04-29 Google이 FIDO Alliance에 기증해 관리를 맡겼지만, 사양은 분쟁 처리를 범위 밖으로 명시해 책임을 배분하지 않습니다.

AP2는 더 이상 2025년에 사람들이 기억하던 그 버전이 아닙니다. v0.2.0은 메커니즘을 Checkout Mandate와 Payment Mandate로 바꾸고, 각각을 open과 closed 두 단계로 나누어 SD-JWT로 구현했으며, open mandate는 cnf claim에 에이전트의 공개 키를 담습니다. 새로 추가된 핵심은 Human-Not-Present 흐름입니다. 사용자가 먼저 신뢰할 수 있는 인터페이스에서 자신의 키로 open mandate에 서명하고 제한 조건을 적어 두면, 에이전트가 나중에 에이전트 키로 closed mandate에 서명하며, 두 단계는 sd_hash로 묶입니다. 판매자나 자격 증명 제공자는 unresolved_constraint를 반환해 흐름을 '사람이 있는' 상태로 되돌릴 수 있습니다. 사양은 또한 판매자가 Checkout JWT에 서명할 때 레인보우 테이블 공격을 막기 위해 Ed25519가 아닌 비결정적 서명(ECDSA)을 쓰도록 권장합니다. 가장 중요한 점은 AP2 사양이 분쟁 처리, 보관, 열람을 out of scope로 두고, 부인할 수 없는 암호학적 감사 추적만 제공하겠다고 약속한다는 것입니다. 연구 노트는 또한 AP2 사양이 권장하는 확장 방식이 UCP의 extension points이고 정작 A2A는 사양 본문에서 논의되지 않는다는 점에 주목했습니다. AP2의 위치가 'A2A 확장'에서 '커머스 프로토콜 안의 보안 계층'으로 옮겨 가고 있다는 것이며, 이는 추론입니다.

결제 확장이 A2A에 탑재되는 방식은 A2A의 extension 메커니즘 그 자체입니다. AgentCapabilities 안에서 AgentExtension(uri, description, required, params)으로 선언하고, 클라이언트는 A2A-Extensions 헤더로 활성화를 요청합니다. 확장은 코어 데이터 구조를 수정하거나 enum 값을 추가할 수 없고 metadata를 통해서만 동작하며, 파괴적 변경은 새 URI로 바꿔야 하고, 지원하지 않는 버전을 만나면 "MUST NOT fall back"입니다. a2a-x402(spec v0.1)가 바로 이런 확장입니다. 판매자가 payment-required를 보내면 클라이언트가 서명한 뒤 payment-submitted를 반환하고, 판매자가 온체인 정산 후 payment-completed를 반환합니다.

x402의 거래 건수는 주로 부풀리기용 거래에서 나옵니다. Chainalysis 집계에 따르면 Base 체인의 x402 거래는 2026년 1분기까지 누적 1억 건을 넘었지만, 2025년 4분기의 급증은 "대부분 meme coin farming이 견인"했고 주간 리텐션은 87%에서 5%로 떨어졌습니다. Coinbase는 2026년 4월 말 약 1.65억 건, 누적 약 5,000만 달러라고 주장했는데 이는 업체 주장입니다. Artemis는 95% 이상이 프로토콜 신호나 테스트라고 보며, 한 추적 사이트는 실제 상거래 금액을 하루 약 2.8만 달러로 추정합니다.

카드 네트워크와 플랫폼의 실제 방식은 '여러 프로토콜을 모두 받고, 사람이 있는 상태의 강력 인증을 안전밸브로 쓰는' 것입니다. OpenAI는 2026년 3월 ChatGPT 안의 Instant Checkout을 판매자 Apps 방식으로 되돌렸으며, 대변인은 "Instant Checkout is moving to Apps"라고 말했습니다. Visa는 2026-07-02 유럽에서 에이전트가 실제로 구매를 완료했으며 협력 카드 발급사가 30곳을 넘고, 모든 거래가 Payment Passkeys로 강력 고객 인증(SCA)을 충족했다고 발표했습니다. 책임 프레임워크는 여전히 비어 있습니다. Chargebacks911은 분쟁·책임 인프라가 "largely unaddressed"라고 경고했고, Taylor Wessing은 EU 체계에서 고객이 정한 조건을 넘어선 에이전트의 구매는 원칙적으로 미승인 거래로 인정될 것이라고 분석했습니다. Ant International, Visa, Mastercard는 2026-09-10에야 Know-Your-Agent 상호운용 프레임워크 탐색을 시작했습니다. EU PSD3/PSR은 현재 이사회가 2026-10-29 1차 독회 입장을 채택한 단계일 뿐 아직 Official Journal에 게재되지 않았으며, 이사회의 PSR 이유서에서 키워드 검색으로는 AI나 자율 에이전트 조항이 발견되지 않습니다. 미국 CFPB도 에이전트 결제 지침이 없습니다.

학술 연구는 또 다른 사각지대를 짚습니다. Debi 등(IEEE IMNS 2026)은 AP2 쇼핑 에이전트로 레드팀 테스트를 수행해 간접·직접 prompt injection으로 상품 순위를 조작하고 사용자 민감 데이터를 빼낼 수 있음을 보였으며, 이는 서명된 mandate가 서명 이전의 추론 과정까지는 보호하지 못함을 뜻합니다. Jiang 등(arXiv:2609.00060)은 Tamarin으로 x402, MPP, ACP, AP2를 형식 분석해 의도, 위임 권한, 정산이 여러 당사자에 분산돼 생기는 보안 의존성을 지적했습니다. 물류 업계의 에이전트화는 현재 MCP를 따르고 있습니다. Flexport의 MCP 서버는 고객의 AI 어시스턴트가 협상 운임으로 선복을 예약하고 booking ID를 받게 해 줍니다. 연구 노트는 AP2나 x402로 운송비를 정산한 사례를 하나도 찾지 못했습니다.

AI 에이전트 결제 프로토콜 계층(2026-10-31 기준)
계층프로토콜주도 주체현황
체크아웃 계층ACPOpenAI＋Stripe2026-03 ChatGPT Instant Checkout이 판매자 Apps로 전환, ACP는 계속 존재
체크아웃 계층UCPGoogle＋Shopify2차 출처에 따르면 Shopify의 UCP 엔드포인트는 MCP를 전송 계층으로 사용
권한 증빙 계층AP2 v0.2.0Google 주도, 2026-04-29 FIDO Alliance에 기증분쟁 처리는 사양 범위 밖
권한 증빙 계층Verifiable IntentMastercard2차 출처에 따르면 2026-03 오픈소스화
머신 마이크로페이먼트 계층x402Coinbase 주도온체인 건수는 대부분 부풀리기용; 실제 상거래 규모는 하루 약 2.8만 달러로 추정
머신 마이크로페이먼트 계층MPPStripe＋Tempo2차 출처에 따르면 2026-03 Tempo 메인넷과 함께 출시

근거 출처 AP2 v0.2 Specification| AP2 Flows| ap2-protocol.org| FIDO Alliance: Google의 AP2 기증| A2A Extensions| google-agentic-commerce/a2a-x402| Chainalysis：x402 agentic payments adoption| Forkast: x402 실제 거래량| presenc.ai: x402 채택 추적| Digital Commerce 360（2026-03-06）| Visa UK 보도자료(2026-07-02)| The Paypers: Chargebacks911 경고| Taylor Wessing：Agentic AI in payments| TechNode（2026-09-10）| The Paypers: MPP 출시| Mastercard Developers: Agentic 거래 가이드| EU 이사회 PSR 1차 독회 입장 표결 문서 ST 15154/26| Debi et al., Whispers of Wealth（IEEE IMNS 2026）| Jiang et al., A Formal Analysis of Agent Payment Protocols（arXiv:2609.00060）| SupplyChain247: Flexport AI 어시스턴트 선복 예약

지금 A2A를 쓰는 곳이 있나요? 프로덕션 사례가 있나요?

2026-10-31 기준 연구 노트는 실명이 공개되고 회사 간에 이뤄지며 측정 결과가 있는 A2A 프로덕션 사례를 하나도 찾지 못했습니다. Linux Foundation은 2026-04-09에 150개 이상의 지지 조직과 프로덕션 배포가 있다고 주장했지만 사용자를 지목하지 않았으며, 한 저자가 2026-10-27에 18개 조직에 36건의 요청을 보내 얻은 유효 Agent Card는 0장이었습니다.

Linux Foundation의 2026-04-09 1주년 보도자료는 A2A에 150개 이상의 지지 조직이 있고 공급망, 금융, 보험, IT 운영에서 프로덕션 배포가 있다고 밝혔는데, 이는 업체 주장에 해당합니다. 보도자료는 어떤 사용자도 지목하지 않았고 프로세스나 성과 지표도 제시하지 않았습니다. 가장 자주 예시로 쓰이는 Microsoft Agent Framework .NET 글과 Google 구매 concierge codelab은 모두 코드 예제이지 배포 보고서가 아닙니다. Tyson Foods는 A2A 공급망 사례로 자주 홍보되지만, apis.io가 매긴 A2A Agent Card 점수는 0/8이며 거래 파트너에게 제공하는 것은 여전히 EDI와 API입니다.

가장 직접적인 반증은 실측입니다. 한 저자가 2026년 4월 공개 레지스트리에서 A2A 지원을 주장하는 에이전트 50개를 추출했는데, well-known 경로에서 유효한 카드를 제공한 것은 약 0–2개뿐이었고 task에 올바르게 응답한 것은 0개였습니다. 같은 저자가 2026-09-09 12개 조직에 24건, 2026-10-27 18개 조직에 36건의 요청을 보냈을 때도 받은 카드는 모두 0장이었습니다. 표본은 저자가 직접 고른 것으로 전수 조사는 아니지만 방향은 일관됩니다. 실제로 운영되는 것은 같은 클라우드 플랫폼 내부의 상호운용인 AWS AgentCore, Microsoft Foundry, Google Agent Registry입니다.

멀티 에이전트 아키텍처 자체에 대한 실증도 조직 간 A2A에 불리합니다. MAST(NeurIPS 2025 Datasets & Benchmarks Track)는 1,642개의 실행 궤적을 분석해 14가지 실패 모드를 도출하고 시스템 설계, 에이전트 간 불일치, 작업 검증의 세 범주로 나눴습니다. 논문에서 최신 오픈소스 멀티 에이전트 시스템 7개의 실패율은 41%–86.7%였습니다(저자는 서로 다른 benchmark를 직접 비교할 수 없다고 당부함). Google Research와 MIT 등 저자의 「Towards a Science of Scaling Agent Systems」는 v1/v2와 Google 블로그 버전에서 180가지 구성을 테스트했습니다. 독립형 멀티 에이전트의 오류 증폭은 17.2배, 중앙 조정형은 4.4배였고, 순차 추론 작업에서는 모든 멀티 에이전트 변형이 39%–70% 퇴보했습니다. 2026-04-08의 v3는 260가지 구성, 6개 benchmark로 확장했지만 17.2배와 4.4배라는 결론은 그대로 유지했습니다. Anthropic 엔지니어링 블로그(동료 심사 논문 아님)는 자사의 멀티 에이전트 연구 시스템이 단일 에이전트 Claude Opus 4보다 90.2% 우수하지만 token 사용량은 일반 대화의 약 15배이며, '모든 에이전트가 같은 컨텍스트를 공유해야 하거나 에이전트 간 의존성이 많은' 분야에는 적합하지 않다고 명시했습니다. 조직 간 A2A는 마침 이 불리한 조건을 모두 갖추고 있습니다. 양측은 컨텍스트를 공유하지 않고, 공통 검증자가 없으며, 커머스 프로세스(가격 조회→주문→결제→출고)는 순차형이기 때문입니다. 이는 추론입니다.

엔지니어링 측면의 공백은 사양 측면보다 더 많습니다. A2A로 다음 에이전트에 위임하면 trace가 끊깁니다. Python SDK는 로컬에서만 span을 만들며, 에이전트 사이에 W3C Trace Context를 전달하는 표준 방식이 없습니다(Issue #2103). 커뮤니티 Rust SDK는 7개의 TCK 실패를 보고했는데, 대조해 보니 테스트 스위트 자체의 결함으로 판정됐습니다. 같은 보고는 JS, Go, Java SDK가 두 바인딩 모두에서 21/21 통과했다고 밝혔습니다. 소비자 측 에이전트 트래픽도 아직 작습니다. HUMAN Security 집계로 2025년 에이전트 트래픽은 전년 대비 7,851% 증가했지만 체크아웃 페이지에서 발생한 것은 2.3%뿐입니다. 2차 출처가 인용한 Cloudflare Radar 2026년 8월 데이터에 따르면 AI 봇은 HTML 요청의 약 7%를 차지하고, 그중 '사용자를 대신한 실시간 행동'은 5.8%에 불과해 두 값을 곱하면 약 0.4%입니다. 이 곱셈은 추론이며 아직 원자료로 확인하지 않았습니다. Akamai는 이커머스 사이트가 AI 봇의 90% 이상을 모니터링만 하고 있으며, 동시에 사기형 에이전트 활동이 늘고 있다고 경고했습니다. 연구 노트는 ChatGPT, Gemini, Claude 같은 개인 에이전트가 A2A로 일반 기업 에이전트를 호출한다는 증거를 찾지 못했지만, 이는 반증이 없다는 것일 뿐 공식 확인은 아닙니다.

정부와 국제기구의 인터뷰는 수요가 실재함을 보여 줍니다. OECD Artificial Intelligence Papers No. 65 16쪽에 따르면, 인터뷰에 응한 실무자들은 개방형 프로토콜을 선호하고 A2A 같은 에이전트 간 통신 프로토콜을 멀티 에이전트 조정의 중요한 동력으로 보면서도, 단일 공급업체 생태계에 묶이는 것을 우려했습니다.

A2A 도입: 주장과 증거 대조(2026-10-31 기준)
주장 또는 사례실제로 확인된 증거판단
Linux Foundation: 150개 이상 조직, 여러 산업의 프로덕션 배포보도자료에 사용자 미지목, 성과 지표 없음업체 주장
Tyson Foods 공급망 사례apis.io A2A Agent Card 점수 0/8; 파트너에게는 여전히 EDI와 API 사용증거가 뒷받침하지 않음
Microsoft Agent Framework、Google codelab코드 예제이며 배포 보고서 아님프로덕션 사례 아님
공개 레지스트리에서 지원을 주장하는 에이전트 50개(2026-04)유효 카드 약 0–2개, task에 올바르게 응답한 것 0개제3자 실측
18개 조직, 36건 요청(2026-10-27)카드 0장(표본 자체 선정)제3자 실측
같은 클라우드 플랫폼 내부 상호운용AWS AgentCore, Microsoft Foundry, Google Agent Registry가 이미 제공현재 실제로 운영되는 형태

HowBridge란? 브랜드와 서비스 빠른 답변

근거 출처 Linux Foundation: A2A 1주년 보도자료(2026-04-09)| Microsoft DevBlogs：A2A v1 in Agent Framework for .NET| Google Codelabs：A2A purchasing concierge| apis.io：Tyson Foods| heym.run: A2A vs MCP 실측| Cemri et al., Why Do Multi-Agent LLM Systems Fail?（NeurIPS 2025 D&B）| Kim et al., Towards a Science of Scaling Agent Systems（arXiv:2512.08296）| Google Research 블로그(2026-01-28)| Anthropic Engineering：How we built our multi-agent research system| A2A Issue #2103(trace 단절)| a2a-rust PR #180(TCK 결과)| HUMAN Security：2026 State of AI Traffic| PaidHosting: AI agent traffic(Cloudflare Radar 인용)| Akamai 보도자료| OECD Artificial Intelligence Papers No. 65

각국 정부는 AI 에이전트를 어떻게 규율하나요? A2A를 언급하나요?

2026-10-31 기준 대만 디지털발전부, 싱가포르 IMDA, OECD의 공식 문서가 A2A나 멀티 에이전트 위험을 직접 지목했지만, A2A를 겨냥해 입법한 국가는 없습니다. 대만 「인공지능 기본법」은 115-01-14(2026-01-14)에 공포·시행됐고 주무 기관은 국가과학기술위원회이며, 에이전트가 잘못했을 때의 책임 배분은 제17조가 위임한 후속 규범을 기다려야 합니다.

대만: 「인공지능 기본법」은 총 20개 조문입니다. 제3조는 인공지능을 '자율적으로 작동하는 능력을 갖춘 시스템'으로 정의해 AI 에이전트를 포괄할 수 있지만, 조문에 '에이전트'라는 말은 나오지 않습니다. 제4조는 인간의 자율과 감독, 투명성과 설명 가능성, 책임성 등 7대 원칙을 열거합니다. 제16조는 디지털발전부가 국제 체계와 연계되는 위험 분류 프레임워크를 추진하도록 하고, 제17조는 정부가 고위험 AI의 책임 귀속과 귀책 요건을 명확히 하고 구제, 보상 또는 보험 제도를 마련하도록 요구하며, 제18조는 각 기관이 시행 후 2년 내에 관련 법규 조정을 마치도록 요구합니다. 디지털발전부는 제16조에 따라 115-07-07에 「인공지능 위험 분류 프레임워크」 v1.0(디지털전략 문서 제1150015933호, 즉시 발효)을 공고했으며, 그중 위험 유형 B6 'AI 자율 에이전트의 권한 밖 행위'는 이렇게 명시합니다. "멀티 에이전트 시스템은 에이전트 간 상호 트리거로 인해 개발자와 사용자 모두 예상하지 못한 연쇄 반응을 일으킬 가능성이 더 높으며, 사람이 제때 개입해 바로잡기 어렵게 만든다." 위생복리부가 115-05-29에 하달한 의료기관 생성형 AI 지침은 AI 에이전트 시스템을 '아직 이 지침의 적용 대상에 포함하지 않는다'고 명시했습니다.

대만의 기존 법률도 에이전트 상황에 적용됩니다. 「개인정보보호법」 제4조는 위탁을 받아 개인정보를 수집·처리·이용하는 자를 이 법의 적용 범위에서 위탁 기관으로 간주하므로, 개인정보를 에이전트에게 맡겨 처리하게 해도 'AI가 한 일'이라는 이유로 면책되지 않습니다. 제21조는 국외 이전 제한을 규정합니다. 114-11-11에 개정된 여러 조문(제21조 개정 조문과 제20-1조 신설 포함)은 공포됐으나 아직 시행되지 않았으며, 시행일은 행정원이 정합니다. 「전자서명법」은 AI나 에이전트를 언급하지 않으며, 에이전트가 대신 서명한 것을 본인 서명으로 추정할 수 있는지는 법에 명문 규정이 없어 이 글에서 확인할 수 없습니다.

중국: 국가시장감독관리총국과 국가표준화관리위원회는 2026년 제22호 국가표준 공고로 2026-05-22 GB/Z 185.1～185.7-2026 「인공지능 에이전트 상호연결」 시리즈 총 7건의 지도성 기술 문서(총체 아키텍처, 신원 코드, 신원 관리, 에이전트 기술(description), 에이전트 발견, 에이전트 상호작용, 에이전트 도구 호출)를 승인·발표했습니다. 국가표준정보 공공서비스 플랫폼은 상태를 '현행'으로 표시하며, 전문은 2026-06-18 공개됐고 시장감독관리총국은 2026-06-26 별도의 주제 기자회견을 열었습니다. 공식 문서가 사용하는 프로토콜 이름은 AIP(에이전트 상호연결 프로토콜)이며, 확인된 공식 페이지 어디에도 A2A나 MCP 언급이 없어 양자의 호환 여부는 확인되지 않았습니다. 2026-05-08 국가인터넷정보판공실, 국가발전개혁위원회, 공업정보화부가 공동 발표한 「에이전트 규범적 활용 및 혁신 발전 실시 의견」은 AIP 보급, 에이전트 등록 플랫폼, 에이전트 디지털 신원을 하나로 묶고 '에이전트가 수행하는 작업은 사용자 권한 범위를 넘어서는 안 된다'고 요구합니다. 이 노선은 '공식 레지스트리를 제공하지 않는' A2A 커뮤니티와 다릅니다.

EU: AI Act(Regulation (EU) 2024/1689)는 2024-08-01 발효됐고, 범용 AI 모델 의무는 2025-08-02부터, 일반 적용과 투명성 의무는 2026-08-02부터 적용됩니다. 고위험 의무는 Regulation (EU) 2026/1744(2026-07-24 Official Journal 게재)로 연기돼 부속서 III은 2027-12-02, 부속서 I은 2028-08-02로 미뤄졌습니다. PSD3와 PSR은 이사회가 2026-10-29 1차 독회 입장을 채택한 상태로, 유럽의회 2차 독회를 남겨 두고 있으며 Official Journal에는 게재되지 않았습니다.

미국, 싱가포르, 영국: CISA와 NSA 등 파이브 아이즈 기관은 2026-04-30/05-01 〈Careful Adoption of Agentic AI Services〉를 발표해 접근 권한을 제한하고 저위험·비민감 사용 사례부터 시작할 것을 권고했습니다. 미국 CFPB는 에이전트 결제에 관한 지침이 없으며, 2025년의 관련 해석 규칙안은 2025-05-15 철회됐습니다. 싱가포르 IMDA 「Model AI Governance Framework for Agentic AI」 v1.5(2026-05-20 발표, 06-05 업데이트) 1.1.1절은 에이전트 간 통신에 A2A를, 에이전트와 도구 간 통신에 MCP를 쓴다고 직접 지목하고, 재귀적 위임과 조직 간 신원이 현재의 공백이라고 지적합니다. 영국 CMA가 2026-03-09 발표(10-30 업데이트)한 지침은 "if an AI agent you use does something illegal, you are responsible"이라고 명시해, 사업자가 자신이 사용하는 에이전트의 위법 행위에 책임을 진다고 밝혔습니다. 영국 ICO의 에이전트형 AI 공개 의견 수렴은 2026-11-20에 마감됩니다.

각 지역 공식 문서와 A2A/AI 에이전트의 관계(원문 확인된 것만 수록)
지역문서날짜A2A 또는 에이전트와의 관계
대만「인공지능 기본법」115-01-14 공포·시행제17조가 고위험 AI 책임 귀속 명확화를 요구; '에이전트' 언급 없음
대만디지털발전부 「인공지능 위험 분류 프레임워크」 v1.0115-07-07위험 B6 'AI 자율 에이전트의 권한 밖 행위'
대만디지털발전부 「공공부문 인공지능 활용 참고 매뉴얼」 V1.0115-01-28(문서 기재)14쪽 A2A 소절
중국GB/Z 185.1～185.7-2026 「인공지능 에이전트 상호연결」2026-05-22 승인·발표공식 프로토콜명 AIP; A2A와의 호환성 미확인
EURegulation (EU) 2026/17442026-07-24 게재AI Act 고위험 의무를 2027-12-02/2028-08-02로 연기
EUPSD3/PSR 이사회 1차 독회 입장2026-10-29Official Journal 미게재; PSR 이유서에서 에이전트 조항 미발견
미국NIST〈Design Tenets for Agent Identity Management Systems〉2026-10-27에이전트 신원 10가지 설계 원칙(블로그)
싱가포르IMDA 에이전트형 AI 거버넌스 프레임워크 v1.52026-05-20§1.1.1에서 A2A와 MCP 지목
영국CMA 소비자법과 AI 에이전트 지침2026-03-09사업자가 사용하는 에이전트의 위법 행위에 책임
국제OECD AI Papers No. 652026-0916쪽: 실무자는 A2A를 멀티 에이전트 조정의 동력으로 봄

근거 출처 전국법규데이터베이스: 인공지능 기본법| 디지털발전부 공고: 인공지능 위험 분류 프레임워크| 디지털발전부: 인공지능 위험 분류 프레임워크 v1.0(PDF)| 디지털발전부: 공공부문 인공지능 활용 참고 매뉴얼(PDF)| 위생복리부: 의료기관 생성형 인공지능 활용 지침| 전국법규데이터베이스: 개인정보보호법| 전국법규데이터베이스: 전자서명법| 국가표준화관리위원회: 2026년 제22호 국가표준 공고| 국가표준정보 공공서비스 플랫폼: GB/Z 185.1-2026| 국가표준정보 공공서비스 플랫폼: 전문 공개 통지| 국제과학기술혁신센터: 에이전트 상호연결 표준화 발표회| 국가시장감독관리총국: 전재 보도| 중국 인터넷정보 사이트: 에이전트 규범적 활용 및 혁신 발전 실시 의견| European Commission：AI Act regulatory framework| European Parliament：Digital Omnibus on AI| EU 이사회 PSD3 표결 문서 ST 15152/26| EU 이사회 PSR 표결 문서 ST 15154/26| CISA：Secure adoption of agentic AI| Federal Register 2025-08646(CFPB 철회)| IMDA：Model AI Governance Framework for Agentic AI v1.5| GOV.UK：CMA complying with consumer law when using AI agents| ICO：Agentic AI call for evidence| OECD Artificial Intelligence Papers No. 65

A2A v1.1은 무엇을 보완하나요? 아직 답이 없는 문제는 무엇인가요?

A2A v1.1의 8개 주제는 TSC가 2026-06-25 5대 0으로 의결했으며, 스트림 재개, 멱등성, 푸시 설정, 스킬 선택, 인증 발견, 작업 기록, 다회차 상호작용, 양방향 스트리밍을 포함합니다. 2026-10-31 기준 출시일은 아직 없으며, 에이전트 신원, 위임, 과금 등 가장 뜨거운 논의는 여전히 결론이 나지 않았습니다.

Issue #1942는 41개 이슈를 v1.1의 8개 주제로 통합했으며, 작업 간 에이전트 메모리(#893)는 추적 범위에 들어가지 않았습니다. 주제 목록보다 방향을 더 잘 보여 주는 것은 댓글이 가장 많은 이슈들입니다. #1672 Agent Card의 에이전트 신원 검증(댓글 약 658건), #1829 Ed25519와 RFC 9421을 이용한 메시지 서명, #2028 actor-chain 위임, #2121 비용·예산 전달, #1815 HTTP 402로 '결제 필요' 표시가 그렇습니다. 모두 신뢰와 커머스 문제입니다. 새로 마련된 extension 거버넌스 절차까지 고려하면, 연구 노트는 이들이 코어 사양 수정보다는 확장 형태로 나올 가능성이 높다고 판단하며, 이는 추론입니다.

'개인 에이전트가 회사 에이전트를 어떻게 찾는가'에는 현재 배포된 개방형 해답이 없습니다. A2A 공식 문서는 큐레이션형 레지스트리가 A2A 범위 밖이라고 명시하며, Discussion #741의 Agent Registry 제안은 오랫동안 지연됐고 검토자들은 '제공자가 직접 등록 항목을 관리한다'는 전제에 의문을 제기했습니다. 도메인으로 에이전트를 찾는 방식에 대해서는 IETF에 서로 경쟁하는 개인 초안 4건이 있습니다. DNS-AID(SVCB 레코드로 /.well-known/agent-card.json을 가리킴), AID(_agent TXT 레코드 조회), ADP, DAN이며, 모두 아직 워킹그룹에 채택되지 않았습니다. 2026년 7월의 landscape 초안도 네임스페이스 조정이 필요하다고 지적합니다. MCP 쪽의 MCP Registry는 2025년 9월부터 지금까지 여전히 프리뷰 버전입니다.

조직 간 감사와 책임에도 마찬가지로 프레임워크가 없습니다. A2A 사양에는 SHOULD 수준의 인증 실패 기록과 속도 제한 요구만 있으며, OpenTelemetry GenAI 시맨틱 컨벤션의 안정화 상태에 대해서는 출처마다 말이 엇갈립니다. 현재 도구로 남길 수 있는 최소 감사 단위는 대략 자기 쪽의 taskId와 contextId, 상대 Agent Card 서명의 지문, 상대가 제시한 token의 act 위임 체인 정도이며, 양측이 각자 보관했다가 나중에 대조하는 방식입니다. 이는 추론입니다. 연구 노트는 '상대의 LLM 예산 소진'을 노리는 denial-of-wallet에 관한 실증 연구도 찾지 못했습니다.

  • #1986 스트림 재개: 연결이 끊긴 지점부터 이어받기
  • #1987 멱등성: 요청을 재전송해도 중복 실행하지 않기
  • #1988 푸시 설정: webhook 설정과 관리
  • #1989 스킬 선택: 호출 측이 사용할 스킬을 지정하는 방법
  • #1990 인증 발견: 어떤 인증을 써야 하는지 미리 알기
  • #1991 작업 기록: 과거 작업 기록 조회
  • #1992 다회차 상호작용: 양측이 번갈아 질문하는 의미론
  • #1995 양방향 스트리밍: 양측이 동시에 데이터 스트리밍

근거 출처 A2A Issue #1942(v1.1 주제)| A2A issues(댓글 수 순 정렬)| A2A：Agent discovery| A2A Discussion #741| IETF: DNS-AID 초안| IETF: DAWN discovery landscape 초안| MCP Registry preview（2025-09-08）| A2A Specification §13.4| GreptimeDB：OpenTelemetry GenAI semantic conventions

기업은 지금 A2A를 도입해야 하나요?

2026-10-31의 증거로 보면 기업의 A2A 도입은 '읽기 전용 먼저, 같은 플랫폼 먼저, 회사 간 쓰기는 보류'가 바람직합니다. 같은 클라우드 플랫폼 내부의 에이전트 상호운용은 시도해 볼 만하지만, 회사 간 주문·결제 계열 A2A는 신원, 위임, 책임 프레임워크가 확정되기 전까지 여는 것을 권하지 않습니다. 순차형 작업에서 모든 멀티 에이전트 변형이 39%–70% 퇴보하기 때문입니다(arXiv:2512.08296 v1/v2 데이터).

A2A의 현재 상태는 초창기 HTTP와 매우 비슷합니다. 형식은 이미 표준화됐지만 신뢰 계층은 각자 채워야 합니다. 차이는 이번에는 호출받는 쪽이 스스로 추론하며 상대에게 설득당할 수도 있다는 점입니다. 따라서 병목은 엔지니어링이 아니라 '누가 에이전트의 행동에 책임지는가'에 있으며, 이 문제는 현재 IETF(신원), FIDO Alliance(결제 의도), 카드 네트워크(분쟁), 각국 규제 기관에 흩어져 있어 A2A의 TSC가 관할할 수 없습니다. 이로부터 추론하면, 향후 몇 년간 회사 간 에이전트 상호운용의 가장 유력한 형태는 'A2A 껍데기로 결정론적 도구 호출을 감싼 것'입니다. 호출받는 쪽은 겉으로는 에이전트지만 내부는 사실상 API이며, 진짜 추론은 자사 신뢰 경계 안에서만 일어납니다.

정부 지침의 방향도 이와 일치합니다. CISA와 NSA 등 파이브 아이즈 기관은 저위험·비민감 사용 사례부터 시작하고 접근 권한을 제한하라고 권고하며, 싱가포르 IMDA 프레임워크는 '사람이 실질적 책임을 지게 하는 것'과 기술적 통제를 핵심 축으로 삼습니다. 대만 디지털발전부는 멀티 에이전트의 상호 트리거로 인한 연쇄 반응을 위험 B6으로 분류했고, 영국 CMA는 사업자가 자신이 사용하는 에이전트의 위법 행위에 책임진다고 분명히 밝혔습니다.

아래 표는 일반 기업의 도입 선택지를 증거의 강도에 따라 등급별로 나눈 것입니다. 표에서 '실행'은 현재 증거로 볼 때 위험이 낮고 효과가 분명함을, '선택 실행'은 비용은 낮지만 측정된 사례가 없음을 뜻합니다. '보류'와 '하지 말 것'에는 모두 이유를 달았으며, 트리거 조건이 나타나면 다시 평가합니다.

기업 A2A 도입 권고 등급(2026-10-31)
권고행동이유
실행권한 부여를 직접 구현하고 기본값은 거부로, SDK 기본값에 의존하지 않기사양은 권한 부여를 구현에 맡김; a2a-java는 기본적으로 읽기 권한 검사를 하지 않았음(CVE-2026-111764)
실행Agent Card 필드와 푸시 URL을 모두 신뢰할 수 없는 입력으로 취급하고, 푸시 URL에서 사설 IP 거부카드가 header 이름을 지정할 수 있음; a2a-java와 a2a-python 모두 푸시 SSRF가 발생한 적 있음
실행taskId, contextId, 호출자 신원, traceparent 기록에이전트 간 trace가 끊기므로(Issue #2103) 사후에는 양측 각자의 기록으로만 대조 가능
실행SDK 버전을 고정하고 보안 공지 구독2026년 8–10월 여러 공식 SDK CVE가 나왔고, 패치가 플랫폼 차이로 우회된 적도 있음
선택 실행같은 클라우드 플랫폼 내부의 에이전트 상호운용(AWS AgentCore, Microsoft Foundry, Google Agent Registry)현재 실제로 운영되는 형태이며, 양측의 신뢰 경계가 같음
보류SDK 간 Agent Card 서명 검증에 의존Issue #2122 정규화 불일치; 서명은 무결성만 증명하고 신원은 증명하지 않음
하지 말 것외부 에이전트가 고객 대신 주문·데이터 변경·결제를 하게 하기AP2는 책임을 배분하지 않고, 카드 네트워크에 에이전트 전용 분쟁 규칙이 없으며, PSR에서 에이전트 조항이 발견되지 않음
하지 말 것A2A를 위해 조직 간 멀티 에이전트 백엔드를 자체 구축독립형 멀티 에이전트 오류 증폭 17.2배; 순차 작업 39%–70% 퇴보

AI 빠른 답변 더 보기: 배송대행, 관세 품목분류, 크로스보더 이커머스 Q&A

근거 출처 Kim et al., Towards a Science of Scaling Agent Systems（arXiv:2512.08296）| CISA：Secure adoption of agentic AI| IMDA：Model AI Governance Framework for Agentic AI v1.5| 디지털발전부: 인공지능 위험 분류 프레임워크 v1.0(PDF)| GOV.UK：CMA complying with consumer law when using AI agents| GitHub Advisory GHSA-qw47-mcm5-934w| A2A Issue #2103| A2A Issue #2122| AP2 v0.2 Specification

크로스보더 이커머스·물류 사업자는 지금 A2A를 어떻게 준비해야 하나요?

크로스보더 이커머스·물류 사업자가 2026년에 가장 투자할 가치가 있는 것은 A2A 엔드포인트가 아니라 웹페이지 구조화 데이터와 결정론적이고 읽기 전용인 MCP 도구입니다. 2차 출처가 인용한 Cloudflare Radar 2026년 8월 데이터에 따르면 AI 봇은 HTML 요청의 약 7%를 차지하고 그중 사용자를 대신한 실시간 행동은 5.8%에 불과하며, Flexport가 고객 AI 어시스턴트의 선복 예약에 쓰는 것도 MCP입니다.

크로스보더 이커머스와 물류의 핵심 질의, 즉 운송비는 얼마인지, 세금은 얼마인지, 이 상품의 관세 품목번호와 수입 규정은 무엇인지는 원래 결정론적 계산이며, 바로 외부 에이전트가 가장 필요로 하면서도 가장 오류가 적은 종류의 서비스입니다. Anthropic 엔지니어링 블로그의 경험에 따르면 도구 설명을 다시 쓰는 것만으로 이후 에이전트의 작업 완료 시간이 40% 줄었고, OpenAI가 Instant Checkout을 판매자 Apps로 되돌린 경험은 거래가 결국 판매자 자신의 흐름으로 돌아온다는 것을 보여 줍니다. 따라서 사업자의 준비 순서는 먼저 웹페이지와 구조화 데이터를 읽을 수 있게 만들고, 다음으로 결정론적 도구를 MCP로 만들고, 도구 응답에 이어가기 URL을 붙여 거래를 자사 흐름으로 되돌린 뒤, 마지막에야 A2A 자리 확보를 고려하는 것입니다.

A2A 자리 확보용 카드란 /.well-known/agent-card.json에 카드를 게시하되, skills를 기존의 견적, 세금, 절차 등 결정론적 도구에 대응시키고 뒤에서는 LLM을 돌리지 않고 프로그램을 직접 호출하는 방식입니다. 이 방법은 비용이 낮고 '옵션 가치'에 해당하지만, 현재 이를 통해 트래픽이나 매출을 얻었다는 중소기업의 측정 사례는 없으며 추론에 해당합니다. A2A 엔드포인트를 실제로 연다면 최소한 읽기 전용 스킬만 열고, 상대 카드의 어떤 필드도 신뢰하지 않으며, 푸시 URL에서 사설 IP를 거부하고, taskId, contextId, 호출자 신원, traceparent를 기록해야 합니다.

HowBridge의 현재 방식(아래 내용은 모두 HowBridge 개발자 페이지에서 확인 가능): HowBridge는 키도 OAuth도 필요 없는 공개 MCP(https://0523.tw/mcp/public)를 제공하며, 읽기 전용·멱등 도구 8개가 들어 있습니다. HowBridge 브랜드·서비스 소개, 중국→대만 배송대행 운송비 계산(해상 특송/항공), 대만 수입 세금 계산, 상품명으로 CCC 관세 품목 후보 조회, CCC 품목별 세율과 수입 규정, 대만 구간 배송 규격 초과 요금, 배송대행 절차와 간이 신고 규정을 다루며, IP당 분당 120회까지 호출할 수 있고 공식 MCP Registry에 등록돼 있습니다(이름 tw.0523/lucky-public). 운송비 계산 응답에는 이어가기 URL(continue_url)이 붙어 있어 사용자가 공식 사이트로 돌아가 계속 진행할 수 있습니다. 회원 MCP(https://0523.tw/mcp)는 OAuth 2.1로 권한을 부여하며 읽기 전용 도구 6개를 제공하고, 권한을 부여한 회원 본인의 청구서, 소포, 사전 신고, 세금 고지서, 수입 신고서만 읽을 수 있으며, 기본 한도는 분당 60회, 일 5,000회입니다. HowBridge 개발자 페이지에 현재 나열된 진입점은 회원 데이터 API, 회원 MCP, 공개 MCP이며 A2A 엔드포인트는 없습니다. 이 글은 HowBridge가 A2A를 지원한다는 뜻이 아닙니다.

AI 어시스턴트로 중국에서 대만으로 보내는 비용을 추산하고 싶다면 웹 버전의 배송대행 운송비 계산기, 수입 관세 계산기, 관세 품목 조회를 바로 이용할 수 있습니다. 이 도구들은 공개 MCP와 같은 계산 로직을 쓰며, 계산 결과는 참고용이고 운송비는 입고 후 실측 청구서, 세금은 세관 결정이 기준입니다.

크로스보더 이커머스·물류 사업자의 A2A 준비 등급(2026-10-31)
우선순위행동권고이유
1웹페이지 콘텐츠와 schema.org 구조화 데이터를 지속적으로 강화실행에이전트가 웹사이트에 접근하는 주된 방식은 여전히 탐색과 크롤링이며, 사용자를 대신한 실시간 행동의 트래픽 비중은 매우 작음
2견적, 세금, 관세 품목 등의 기능을 결정론적이고 읽기 전용인 MCP 도구로 만들고 도구 설명을 다듬기실행도구 설명을 다시 쓰자 에이전트 완료 시간이 40% 감소; 물류 업계의 에이전트 선복 예약은 MCP 사용
3도구 응답에 이어가기 URL을 붙여 거래를 자사 흐름으로 되돌리기실행Instant Checkout이 판매자 Apps로 돌아가 거래가 판매자 자신의 페이지로 돌아옴
4회원 데이터 인터페이스는 OAuth를 유지하고 클라이언트별 속도 제한과 감사 로그 추가실행사양이 권한 부여를 구현에 맡김; Akamai는 사기형 에이전트 증가를 경고
5/.well-known/agent-card.json 자리 확보용 카드를 게시하되 뒤에는 결정론적 프로그램만 연결하고 LLM은 돌리지 않기선택 실행(낮은 우선순위)비용이 낮고 옵션 가치에 해당; 아직 측정 사례 없음(추론)
6A2A 엔드포인트 개방조건부 실행읽기 전용만 개방; 카드 필드 불신; 푸시 URL에서 사설 IP 거부; 전체 기록(공개된 SSRF·fail-open CVE에 대응)
7Agent Card 서명보류 또는 단일 SDK만 사용Issue #2122 SDK 간 정규화 불일치
8외부 에이전트에 주문·주소 변경·결제 개방하지 말 것책임 프레임워크 미확정; 순차형 작업에서 멀티 에이전트 39%–70% 퇴보
9A2A를 위해 멀티 에이전트 백엔드를 자체 구축하거나 AP2/x402로 운송비 수납하지 말 것x402의 실제 상거래 규모는 매우 작음; 운송비 정산 사례 미발견

HowBridge 개발자 플랫폼: 공개 MCP와 회원 MCP ・ 배송대행 MCP 가이드: Claude, ChatGPT로 운송비와 세금 조회하기 ・ 배송대행 운송비 계산: 중국→대만 해상 특송·항공 요금 ・ 수입 관세 계산기: 관세, 영업세, 화물세 계산 ・ 관세 품목 조회: 중국어 품명으로 CCC 코드와 세율 조회

근거 출처 PaidHosting: AI agent traffic(Cloudflare Radar 인용)| HUMAN Security：2026 State of AI Traffic| SupplyChain247: Flexport AI 어시스턴트 선복 예약| Anthropic Engineering：How we built our multi-agent research system| Digital Commerce 360（2026-03-06）| Akamai 보도자료| A2A Specification| HowBridge 개발자 플랫폼(공개 MCP, 회원 MCP 안내)

크로스보더 이커머스·물류 사업자가 AI 에이전트 상호운용을 준비하는 5단계

1먼저 웹페이지를 읽을 수 있게 하기

가격, 소요 기간, 규칙 등 핵심 사실을 서버에서 바로 렌더링되는 HTML에 쓰고 schema.org 구조화 데이터를 보강합니다. 에이전트가 웹사이트에 접근하는 주된 방식은 여전히 탐색과 크롤링입니다.

2결정론적 기능을 MCP 도구로 만들기

견적, 세금, 관세 품목 등 조회를 읽기 전용·멱등 MCP 도구로 만들고, 도구 설명에 입력 단위와 제한을 명확히 쓰며, 응답에 이어가기 URL을 붙여 사용자를 자사 흐름으로 되돌립니다.

3회원 데이터는 OAuth와 속도 제한으로

개인정보와 관련된 인터페이스는 OAuth 권한 부여만 사용하고 본인 데이터만 반환하며, 클라이언트별 속도 제한과 감사 로그를 추가합니다.

4A2A 자리 확보용 카드 검토

시험해 보려면 /.well-known/agent-card.json에 결정론적 도구에만 대응하고 뒤에서 LLM을 돌리지 않는 카드를 게시하고, 출시 전에 푸시 URL과 카드 필드의 입력 검증을 점검합니다.

5분기마다 재측정하고 트리거 조건 기다리기

분기마다 동종 업체나 플랫폼 10–20곳에 well-known 요청을 보냅니다. 실명 파트너의 서면 요청, v1.1 확정, 책임 프레임워크 등장 전까지는 주문과 결제를 열지 않습니다.

용어 설명

A2A（Agent2Agent）
서로 다른 조직·프레임워크에 속한 AI 에이전트가 서로의 능력을 발견하고 작업을 위임하며 결과를 교환하도록 하는 개방형 프로토콜로, 2025-06부터 Linux Foundation이 관리합니다.
MCP（Model Context Protocol）
AI 어시스턴트가 외부 도구와 리소스를 호출하게 하는 개방형 프로토콜로, 호출 측 LLM이 추론을 제어하며 도구 schema는 호출 측에 투명합니다.
Agent Card
A2A 에이전트의 공개 기술 파일로 스킬, 인터페이스, 인증 방식을 선언하며 관례상 /.well-known/agent-card.json에 둡니다. 서명은 선택 사항입니다.
Task(작업)
A2A에서 한 번의 협업 단위로, taskId는 서버가 생성하며 제출, 처리 중, 입력 필요, 권한 필요, 완료, 실패 등의 상태가 있습니다.
Extension(확장)
A2A 코어 외부에 기능을 추가하는 메커니즘으로, URI로 식별하고 클라이언트가 A2A-Extensions 헤더로 활성화하며 코어 데이터 구조를 수정할 수 없습니다.
AP2（Agent Payments Protocol）
SD-JWT mandate로 에이전트 결제에 대한 사용자의 권한 부여를 기록하는 프로토콜로, v0.2.0은 2026-04-28 출시됐고 2026-04-29 FIDO Alliance로 이관됐습니다.
x402
HTTP 402 '결제 필요' 상태 코드를 기반으로 한 머신 간 마이크로페이먼트 프로토콜로, 주로 Base 체인에서 정산됩니다.
RFC 8693 token exchange
OAuth 2.0의 토큰 교환 표준으로, act claim으로 위임 경로를 기록하고 may_act로 다음 홉을 제한할 수 있습니다.
SSRF(서버 측 요청 위조)
서버가 공격자가 지정한 주소로 요청을 보내도록 유도하는 취약점입니다. A2A의 푸시 webhook URL이 흔한 진입점입니다.
TSC(기술운영위원회)
A2A의 의사결정 기구로 9석이며 회사당 한 석이고, 안건은 GitHub issue에서 gitvote로 표결합니다.
AIP(에이전트 상호연결 프로토콜)
중국 GB/Z 185-2026 시리즈 국가표준 문서가 사용하는 에이전트 상호연결 프로토콜 이름으로, A2A와의 호환 여부는 확인되지 않았습니다.

자주 묻는 질문

A2A 프로토콜은 누가 개발했나요?

A2A는 Google이 2025년 4월 발표했고 2025-06-23 Linux Foundation으로 이관돼 관리되고 있으며, 창립 멤버는 AWS, Cisco, Microsoft 등 7개사입니다. 현재 9석의 기술운영위원회가 의사결정을 하며, 2026년 8월에는 MCP와 같은 재단인 AAIF에 합류했습니다.

A2A 최신 버전은 무엇인가요?

2026-10-31 기준 A2A 현행 버전은 v1.0.1로 2026-05-26 출시됐으며, 2026-03-12의 v1.0.0과 와이어 호환됩니다. v1.1은 8개 주제가 의결됐지만 아직 출시일이 없습니다.

A2A와 MCP를 함께 쓸 수 있나요?

네. A2A 공식 예시는 에이전트끼리는 A2A로 협업하고 각 에이전트는 MCP로 자기 도구를 다루는 방식입니다. 둘은 각각 에이전트 간, 에이전트-도구 간 통신을 담당하며 서로 배타적이지 않습니다.

A2A에 알려진 보안 취약점은 무엇인가요?

2026년 8–10월 첫 공식 SDK CVE가 나왔습니다. a2a-java가 기본적으로 읽기 권한 검사를 하지 않은 문제(CVE-2026-111764, CVSS 7.5), a2a-python 푸시 SSRF(CVE-2026-90790)가 포함되며, 학술 연구에서는 사양을 준수해도 악용할 수 있는 프로토콜 계층 취약점 11개가 발견됐습니다.

AI 에이전트가 스스로 카드 결제를 할 수 있나요?

기술적으로는 가능합니다. Visa는 2026-07-02 유럽에서 에이전트가 구매를 완료했다고 발표했지만, 거래에는 여전히 Payment Passkeys로 카드 소지자가 강력 인증을 합니다. AP2 사양은 분쟁 책임을 배분하지 않으며, EU PSR도 아직 Official Journal에 게재되지 않았습니다.

대만에 AI 에이전트를 규율하는 법이 있나요?

대만 「인공지능 기본법」은 2026-01-14 공포·시행됐지만 '에이전트'를 언급하지 않습니다. 디지털발전부 위험 분류 프레임워크 v1.0은 'AI 자율 에이전트의 권한 밖 행위'를 위험 B6으로 분류했으며, 책임 귀속은 제17조의 후속 규범을 기다려야 합니다.

HowBridge는 A2A를 지원하나요?

HowBridge 개발자 페이지에 현재 나열된 것은 회원 데이터 API, 회원 MCP, 키가 필요 없는 공개 MCP이며 A2A 엔드포인트는 없습니다. 공개 MCP는 운송비, 수입 세금, CCC 관세 품목 등 읽기 전용 계산 도구를 제공합니다.

중국의 에이전트 상호연결 국가표준은 A2A와 같은가요?

확실하지 않습니다. GB/Z 185.1～185.7-2026 총 7건은 2026-05-22 승인·발표됐으며 공식 프로토콜 이름은 AIP입니다. 확인된 공식 페이지에는 A2A나 MCP 언급이 없어 양자의 호환 여부는 확인되지 않았습니다.

핵심 데이터

A2A 현행 버전 v1.0.1 2026-05-26 출시(A2A CHANGELOG)
TSC 의석 9석 회사당 한 석(A2A GOVERNANCE.md)
GitHub repo 수: MCP 대 A2A 40,675 대 622 mcp-server와 a2a-protocol topic(gravity.fast)
실측으로 얻은 유효 Agent Card 0장 2026-10-27 18개 조직에 36건 요청(heym.run, 표본 자체 선정)
a2a-java CVE-2026-111764 CVSS 7.5 기본적으로 읽기 권한 검사 없음(GitHub Advisory)
A2ABreak가 찾은 새 취약점 11개 사양 준수만으로 악용 가능(arXiv:2609.10871)
순차 작업에서 멀티 에이전트 퇴보 39%–70% arXiv:2512.08296 v1/v2와 Google 블로그(180가지 구성)
중국 에이전트 상호연결 국가표준 문서 7건 GB/Z 185.1～185.7-2026, 2026-05-22 승인·발표

A2A 주요 연표

  1. Google, A2A 발표, 50여 개 파트너(2차 출처)
  2. A2A 0.2.2: 파괴적 JSON-RPC 정렬, extensions 추가
  3. Linux Foundation, A2A 프로젝트 인수 발표
  4. A2A 0.3.0: agent.json을 agent-card.json으로 이름 변경, 카드 서명과 mTLS 추가
  5. IBM ACP가 A2A에 통합, ACP 개발 중단
  6. 대만 「인공지능 기본법」 공포·시행
  7. A2A v1.0.0 출시(2026년 1월로 적은 논문도 있음)
  8. AP2 v0.2.0 출시; 다음 날 Google이 AP2를 FIDO Alliance에 기증
  9. 중국 GB/Z 185.1～185.7-2026 에이전트 상호연결 시리즈 7건 승인·발표
  10. A2A v1.0.1 출시
  11. TSC, v1.1 8개 주제를 5대 0으로 의결
  12. 디지털발전부 「인공지능 위험 분류 프레임워크」 v1.0 공고, 위험 B6 포함
  13. MCP 2026-07-28 버전 무상태 전환, Tasks는 공식 확장으로 이동
  14. AAIF와 Axios가 기재한 A2A의 AAIF 합류 날짜
  15. A2A 공식 블로그가 기재한 AAIF 합류 날짜(08-17과 병기)
  16. 공식 a2a CLI 출시
  17. NIST, 에이전트 신원 관리 시스템 10가지 설계 원칙 블로그 발표
  18. EU 이사회, PSD3/PSR 1차 독회 입장 채택(아직 Official Journal 미게재)

지속적으로 추적하는 신호

  • 실명이 공개된 B2B 파트너(이커머스 플랫폼, 운송사, 창고 또는 통관 사업자)가 서면으로 A2A 연동을 요청하는 경우. 2026-10-31 기준 조직 간 A2A에는 실명 사례가 하나도 없으므로 이것이 가장 강력한 신호입니다.
  • ChatGPT, Gemini 또는 Claude가 A2A로 제3자 판매자 에이전트를 호출한다고 공식 발표하는 경우. 현재 세 곳 모두 그렇게 하지 않으며, Anthropic은 아직 네이티브 A2A 지원도 없습니다.
  • A2A v1.1이 정식 출시되고 인증 발견(#1990)과 멱등성(#1987)을 포함하거나, 에이전트 신원·위임 관련 확장이 정식 확정되는 경우.
  • Issue #2122가 종료되고 TCK 서명 테스트 벡터가 Python, JS, Go 세 SDK 모두에서 통과하는 경우.
  • 카드 네트워크가 에이전트 전용 chargeback 사유 코드를 발표하거나, EU PSD3/PSR이 유럽의회 2차 독회를 마치고 Official Journal에 게재되며 에이전트 조항이 나타나는 경우(2026-10-31 기준 이사회는 1차 독회 입장만 채택했고, PSR 이유서에서 에이전트 조항이 발견되지 않음).
  • Google Agent Registry, Microsoft Agent 365 또는 MCP Registry가 조직 간 공개 등록을 열거나, DNS-AID 등의 초안이 IETF 워킹그룹에 채택되는 경우.
  • 중국 GB/Z 185 시리즈(AIP)와 A2A의 호환성이나 구현이 공개되거나, 에이전트 등록 플랫폼이 출범해 양안 크로스보더 협력사가 채택하기 시작하는 경우.
  • 대만이 「인공지능 기본법」 제17조에 따라 고위험 AI 책임 귀속 규범을 마련하거나, 「개인정보보호법」 114-11-11 개정 조문의 시행일을 행정원이 정하는 경우.
  • A2A TSC가 거버넌스 문서에 따라 설립 18개월(약 2026년 12월) 후 구성을 조정하는 경우.
  • 분기마다 well-known 요청으로 동종 업체나 플랫폼 10–20곳을 재측정합니다. 얻은 유효 Agent Card가 여전히 0장이라면 추가 투자할 이유가 없습니다.

이 글에서 언급한 조직과 표준

참고 자료

정부·공식 문서

학술 논문

사양·산업 출처

최종 업데이트 최초 게시

이 글은 기술 연구 정리이며 법률, 보안, 투자 조언이 아닙니다. 사양과 법규는 각 기관과 프로젝트의 최신 공고를 기준으로 합니다.

배송대행을 시작할 준비가 되셨나요?

HowBridge Logistics 배송대행 회원으로 무료 가입하여 해외 배송대행 창고 주소와 14개 언어 고객센터 지원을 바로 받으세요.

무료 가입

📦 인기 경로 가이드

🛒 마켓플레이스 구매 가이드

📋 관세/규정

🏛️ 공식 기관 출처

🔎 인기 수입 관세

🚚 배송대행·운임 비교

🧮 통관 절차와 세금 계산

⚠️ 반입 금지품과 검사 규정

💳 결제·영업세·정식 통관

H
HowBridge Logistics 통관 및 배송 전문가
HowBridge(好運器資訊有限公司)(대만 사업자 통일번호 57151105, 2017년 8월 설립)는 중국 대륙에서 대만으로 보내는 국경 간 통합 배송(집운) 서비스를 제공합니다. 통관 업무는 AEO 인증을 받은 제휴 통관업체와 함께 처리됩니다. 14개 언어 고객 지원, 관세청(관무서) CCC 세번 데이터 동기화, 수취인의 EZWay 실명 인증 완료 지원도 제공합니다. 자체 통계(2026-08-01~2026-09-30): 해상 통관 신고 692건 중 97.8%가 24시간 이내에 세관 통관 승인을 받았습니다. 중국에서 발송해 대만에서 배송 수령이 확인된 해상 특송 774건의 소요 기간은 중앙값 6일, 90%가 9일 이내였습니다. 내용은 편집부가 재정부 관무서 공고와 현행 법규를 바탕으로 정리한 것입니다. 팀 소개 ->