Executive Summary

주요 수치

아래 네 칸 가운데 앞의 세 숫자는 이 생태계가 얼마나 빨리 한 곳으로 모였는지를 보여 줍니다. 마지막 칸에는 숫자가 없습니다. 모이는 속도만큼 정해진 것이 늘지는 않았기 때문입니다.

출처: Axios(2026-08-17), AAIF 공지, 리눅스 재단 보도자료(2025-12-09)

A2A(Agent2Agent)는 구글이 2025년 4월에 내놓은 프로토콜입니다. 서로 다른 프레임워크와 벤더에서 만들어진 에이전트가 상대를 찾아내고, 일을 넘기고, 결과를 돌려받는 방법을 정합니다. 같은 해 6월 구글은 명세와 SDK, 도구 일체를 리눅스 재단에 기증했고, 이때 함께 이름을 올린 곳이 AWS, 시스코, 마이크로소프트, 세일즈포스, SAP, 서비스나우였습니다. 2025년 8월에는 IBM이 자사 규격인 ACP(Agent Communication Protocol)를 A2A에 합쳤습니다.

2026년 8월 17일 Axios가 단독으로 전한 소식은 A2A가 그 리눅스 재단 안에서도 에이전틱 AI 전담 재단인 AAIF의 프로젝트가 된다는 것이었습니다. 이튿날 TechStrong AI가, 그 다음 날 Forbes가 뒤를 이었습니다. 소유권이 넘어가는 이벤트가 아니라 이미 중립 재단에 있던 프로젝트가 더 좁고 전문화된 집으로 옮겨 앉는 이벤트입니다.

옮겨 간 곳에 이미 무엇이 있었는지가 이 소식의 무게를 정합니다. AAIF는 2025년 12월 9일 리눅스 재단이 창설을 발표한 재단으로, 창립 기여 프로젝트가 앤트로픽의 MCP, 블록의 goose, 오픈AI의 AGENTS.md 세 건이었습니다. 플래티넘 회원에는 AWS, 앤트로픽, 블록, 블룸버그, 클라우드플레어, 구글, 마이크로소프트, 오픈AI가 들어가 있습니다. 발표 시점에 MCP는 공개된 서버가 1만 개를 넘었고 클로드, 커서, 마이크로소프트 코파일럿, 제미나이, VS Code, ChatGPT가 채택한 상태였습니다.

그 사이 재단이 맡은 프로젝트는 다섯 건으로 늘었고, 재단은 이것들을 하나의 스택으로 놓고 층을 나눠 설명합니다. 에이전트에게 프로젝트의 규칙과 관례를 알려 주는 지시·맥락 층에 AGENTS.md, 에이전트가 추론하고 계획하고 작업을 수행하는 런타임 층에 goose, 도구와 데이터에 닿는 연결 층에 MCP, 에이전트 시스템과 인프라 사이 경계에서 라우팅과 정책과 관측을 맡는 트래픽 중개 층에 agentgateway, 그리고 이번에 들어온 에이전트 간 상호운용 층에 A2A가 놓입니다. 연결하고 실행하고 중개하는 조각이 한 자리에 모인 구성입니다.

구글 클라우드의 라오 수라파네니(Rao Surapaneni)는 Axios에 A2A를 처음 구상할 때의 가설이 고객사가 여러 기술 제공사와 플랫폼 제공사의 에이전트를 한꺼번에 배포하리라는 것이었고 그 에이전트들이 서로 함께 일할 수 있어야 한다는 데 있었다고 말했습니다. AAIF 사무국장 마진 길버트(Mazin Gilbert)는 열린 프로토콜과 열린 표준 사이에는 큰 차이가 있으며, 열린 프로토콜이 스택 전체와 상호운용되는 상태로 가는 것이 중요하다고 했습니다. 기업이 원하는 것은 프로토콜 하나가 아니라 스택 전체가 열려 있는 것이라는 말도 덧붙였습니다. 두 발언 모두 같은 곳을 가리킵니다. 규격이 공개돼 있다는 것과 그 규격이 남의 시스템과 실제로 맞물린다는 것은 다른 일입니다.

중립 거버넌스가 왜 필요한지에 대한 재단의 설명은 조달 담당자의 언어에 가깝습니다. 기반 부품을 한 회사가 쥐고 있으면 그 아래 모든 팀이 그 회사의 로드맵과 릴리스 주기를 그대로 떠안게 되고, 공개 거버넌스로 옮기면 무엇을 언제 만들지를 커뮤니티가 정합니다. A2A를 지지하는 150여 조직에는 서로 직접 경쟁하는 회사들이 섞여 있는데, 어느 한 참여자도 통제하지 못하는 구조가 아니면 그 폭은 유지되지 않습니다. Axios가 이 소식의 의미로 짚은 것도 결국 구매자 쪽 이야기였습니다. 여러 제공사의 에이전트와 도구를 섞어 쓰기 쉬워지면, 기업은 비용과 성능과 지연 시간을 보고 제공사를 고를 여지를 갖게 됩니다.

두 규격이 왜 경쟁하지 않는지는 Forbes의 한 문장이 가장 짧게 정리합니다. MCP는 에이전트가 데이터베이스나 API, 파일시스템에 어떻게 닿는지를 표준화하고, A2A는 한 에이전트가 다른 에이전트에게 일을 맡기고 결과를 돌려받는 방법을 표준화한다는 것입니다(MCP standardizes how an agent reaches a database, an API or a file system. A2A standardizes how one agent asks another to complete a task and return the result). 같은 층에서 겹치는 규격이 아니라 방향이 다른 규격입니다.

A2A 쪽의 작동 방식은 에이전트 카드(agent card)에서 시작합니다. 에이전트는 자기가 무엇을 할 수 있고 어디로 연락하면 되는지를 구조화한 카드를 공개합니다. 다른 에이전트가 그 카드를 읽어 능력을 파악하고 사람의 중개 없이 작업을 넘깁니다. 그 전에는 프레임워크가 다른 에이전트끼리 일을 주고받으려면 짝마다 전용 통합 코드를 따로 써야 했고, 새 벤더와 관계를 맺을 때마다 같은 작업을 처음부터 반복해야 했습니다. 비용이 든 자리는 에이전트가 아니라 에이전트 사이였습니다.

두 규격은 연결 방향과 푸는 문제가 다르고, 나온 시기와 재단에 합류한 경로도 다릅니다. 다만 마지막 줄은 둘이 같습니다. 같은 재단에 들어온 뒤에도 운영은 각자입니다.

규격이 한 곳으로 모이는 흐름 자체는 뚜렷합니다. IBM이 자사 규격을 A2A에 합친 것이 파편화를 줄인 첫 신호였고, A2A는 지금 150곳 넘는 조직의 지지를 받으며 공급망과 금융서비스, 모바일 플랫폼에서 프로덕션으로 돌아가고 있습니다. 화웨이는 하모니OS의 OS 레벨 어시스턴트 셀리아(Celia)와 앱 내 에이전트를 잇는 데 A2A를 표준으로 삼았고, 텐센트의 위챗은 화웨이를 비롯한 안드로이드 OEM 어시스턴트와 붙는 데 씁니다. 구글 클라우드와 마이크로소프트 애저 AI 파운드리, AWS 베드록 에이전트코어가 모두 A2A 엔드포인트를 열거나 호스팅합니다.

이 숫자들을 읽을 때 Forbes가 붙여 둔 단서를 같이 봐야 합니다. 지지 조직 수와 프로덕션 배포 현황은 독립적인 측정이 아니라 재단과 그 벤더들이 내놓은 수치입니다. 회원사 250곳도 재단 자신의 집계입니다. 방향을 보여 주는 데는 충분하지만 시장 점유율처럼 다룰 숫자는 아닙니다. 파편화가 완전히 정리된 것도 아닙니다. IBM의 ACP는 A2A로 흡수됐지만, 시스코의 AGNTCY는 에이전트 발견과 신원이라는 겹치는 영역을 여전히 따로 다루고 있습니다. 공교롭게도 그 영역이 이 글이 다루는 문제와 가장 가까운 자리입니다.

2026년 3월에 나온 A2A v1.0은 이 규격의 첫 안정 명세입니다. 여러 프로토콜에 얹을 수 있는 바인딩과 버전 협상, 멀티테넌시, 그리고 암호로 서명된 에이전트 카드가 이때 들어갔습니다. 기업 배포와 신원 검증을 겨냥한 항목들입니다.

Forbes가 이 대목에서 붙인 단서가 실무자에게는 더 쓸모 있습니다. 어떤 회사가 A2A 엔드포인트를 하나 띄워 두는 것과, 프로토콜 바인딩과 버전 협상, 멀티테넌시, 서명된 카드까지 실제로 지원하는 것은 전혀 다른 이야기라는 것입니다. 지지 조직 목록에 이름이 있다는 사실만으로는 상대 에이전트가 어느 리비전을 어디까지 구현했는지 알 수 없습니다. 명단은 방향을 알려 줄 뿐 상태를 알려 주지 않습니다.

세 매체가 공통으로 짚은 미해결 항목을 Forbes는 두 문장으로 적었습니다. 공동의 재단은 누가 명세를 관장하느냐를 정리하며, 기업 인가 정책을 표준화하지는 않는다는 것입니다(A shared foundation settles who stewards the specifications. It does not standardize enterprise authorization policy). 같은 기사의 다른 문장은 재단 합류 이후에도 두 프로토콜이 각자의 메인테이너와 명세 절차, 릴리스 일정을 유지한다고 못 박습니다. 재단 아래로 들어간 것은 거버넌스이지 정책이 아닙니다.

v1.0에 들어간 서명된 에이전트 카드가 이 구분을 잘 보여 줍니다. 서명은 이 카드가 정말 그 조직의 것인지를 확인해 줍니다. 신원 검증, 즉 인증(authentication)의 영역입니다. 그런데 실무에서 사고가 나는 지점은 그다음 질문입니다. 신원이 확인된 이 에이전트가 우리 고객 테이블을 읽어도 되는가. 이것은 인가(authorization)의 영역이고, 서명은 여기에 아무 답도 주지 않습니다.

A2A 명세가 이 문제를 방치한 것은 아닙니다. 명세는 클라이언트 인증이 끝나면 요청을 인가하는 책임은 A2A 서버에 있다고 적고(Once a client is authenticated, the A2A server is responsible for authorizing the request), 접근은 에이전트 카드에 표시된 스킬 단위로 통제할 수 있다고 밝힙니다. 최소 권한도 요구합니다. 에이전트는 클라이언트나 사용자가 의도한 작업을 수행하는 데 필요한 권한만 부여해야 하고, 백엔드 시스템이나 데이터베이스, 도구와 맞물리는 에이전트는 민감한 동작을 수행하거나 민감한 데이터에 접근하기 전에 적절한 인가를 집행해야 한다고 되어 있습니다.

이 구분은 설계의 결과이지 빠뜨린 자리가 아닙니다. A2A는 보안과 운영을 위한 새 규격을 따로 만드는 대신, 기업이 이미 갖춰 둔 인프라와 관행 위에 얹히는 쪽을 택했습니다. 인증은 OAuth 2.0과 OpenID Connect 같은 표준 웹 방식에 맡기고, 서버가 어떤 인증 방식을 받는지는 에이전트 카드에 적어 알립니다. 프로토콜 메시지 본문에는 사용자나 클라이언트의 신원을 싣지 않습니다. 신원은 HTTP 계층에서 확인하고, 자격 증명은 프로토콜 바깥의 절차로 받아 옵니다. 자격 증명이 없거나 틀리면 401을, 자격 증명은 맞지만 그 동작을 할 권한이 없으면 403을 돌려주라고 되어 있습니다. 인증과 인가의 경계가 응답 코드 두 개에 그대로 새겨져 있는 셈입니다.

명세가 요구하는 것은 여기까지입니다. 인가를 하라고는 하는데, 무엇을 기준으로 할지는 각 조직이 정합니다. Forbes의 표현으로는 정책 모델 자체가 의도적으로 열려 있는 자리입니다. 파트너사의 에이전트가 우리 조직 경계를 넘어와 어디까지 볼 수 있는지, 테넌트 격리를 어느 선에서 강제할지, 서명 키가 정말 그 조직 소유인지를 무엇으로 검증할지는 전부 구현 선택지로 남습니다.

인가를 실제로 정해야 했던 자리에서 업계가 어떻게 움직였는지를 보면 이 공백의 크기가 짐작됩니다. 구글 클라우드와 페이팔은 A2A를 상거래로 넓히면서 결제 인가를 A2A에 맡기지 않았습니다. 쇼핑 에이전트와 판매자 에이전트는 상품 탐색과 가격 결정, 주문 처리를 A2A로 주고받고, 결제를 승인하는 층은 그 위에 따로 세운 AP2(Agent Payments Protocol)가 맡습니다. 무엇을 해도 되는지 정해야 하는 순간에는 통신 규격 하나로 부족했고, 규격을 하나 더 세워야 했습니다.

재단 안에 집행할 자리가 없는 것도 아닙니다. 앞에서 본 agentgateway가 그 자리이고, MCP와 A2A 트래픽을 한자리에서 받아 정책을 겁니다. 다만 게이트웨이가 주는 것은 정책을 집행할 지점이지 정책의 내용이 아닙니다. 어떤 파트너의 어떤 에이전트에게 어느 데이터를 열지는 도입하는 조직이 문장으로 써서 넣어야 합니다.

그래서 Forbes는 벤더에게 물어볼 것을 세 가지로 정리했습니다. 상대가 A2A의 어느 리비전을 지원하고 어떤 바인딩과 버전 협상을 구현했는지(정합성), 서명되지 않은 카드를 거부하는지와 서명 키가 해당 조직 소유임을 어떻게 검증하며 테넌트 격리를 강제하는지(신뢰와 격리), 그리고 조직 사이의 위임에서 접근 경계를 실제로 집행하는 시스템이 무엇이고 컴플라이언스 팀이 확인할 감사 기록이 남는지(책무성)입니다.

TechStrong AI는 같은 소식에 다른 각도의 경고를 붙였습니다. 시커(Seekr)의 AI 솔루션 아키텍트 마헤시 샨무가순다람(Mahesh Shanmugasundaram)은 A2A 같은 열린 프로토콜이 에이전틱 AI를 더 상호운용 가능하게 만드는 중요한 진전이라고 인정하면서도, 상호운용성이 이미 존재하던 신뢰 격차를 넓히기만 한다고 말했습니다. 프로토콜은 배관을 표준화하고, 그 안으로 무엇이 흐를지는 조직이 정한다는 것이 그의 표현입니다.

그가 우려한 실패 방식은 구체적입니다. A2A 체인에서 각 에이전트가 앞선 에이전트의 출력을 100퍼센트 신뢰할 입력으로 다루느냐, 검증해야 할 주장으로 다루느냐에 따라 결과가 갈립니다. 앞을 무조건 믿는 쪽으로 가정이 굳으면 연쇄 실패가 팀이 예상하는 것보다 구조적으로 나빠집니다. 체인 앞머리의 작은 환각이 몇 단계를 지나 매우 권위 있어 보이는 답으로 나오는 상황을 그는 AI판 전화 놀이(AI game of telephone)라고 불렀습니다.

이 위험이 개별 구현의 부주의에서만 나오는 것은 아닙니다. A2A 명세는 에이전트가 대체로 불투명한 존재라는 점을 설계 원칙으로 적어 두었습니다. 에이전트끼리는 내부 기억도, 도구도, 자원 접근 권한도 공유하지 않습니다. 덕분에 상대 에이전트를 평범한 HTTP 기반 기업 애플리케이션처럼 취급하며 기존 보안 모델을 그대로 적용할 수 있습니다. 대신 뒤에 선 에이전트는 앞선 에이전트가 무엇을 근거로 그 답을 냈는지 들여다볼 방법이 없습니다. 건네받는 것은 결과물뿐입니다. 전화 놀이가 구조적으로 나빠지는 이유도 여기 있습니다. 근거를 함께 실어 보내지 않으면 뒤에 선 쪽은 검증하고 싶어도 검증할 재료를 갖지 못합니다.

인가 문제와 신뢰 문제는 다른 이야기처럼 보이지만 실무에서는 같은 지점에서 만납니다. 둘 다 표준이 정해 주지 않는 판단이고, 둘 다 판단의 근거를 나중에 되짚을 수 있느냐에 달려 있습니다. 어떤 에이전트가 어떤 권한으로 무엇을 읽었는지가 남아 있지 않으면 권한 사고를 재구성할 수 없고, 체인의 어느 단계에서 어떤 주장이 검증 없이 통과했는지가 남아 있지 않으면 오답의 출처를 찾을 수 없습니다. 그가 증거 기반 평가와 설명 가능한 출력이 나중에 붙이는 기능이 아니라 에이전트 사이 교환의 기본 단위여야 한다고 말한 이유입니다.

연결 방식을 두고 벌어지던 논쟁은 대체로 정리 국면에 들어갔습니다. 도구 접속은 MCP, 에이전트 간 통신은 A2A, 그리고 두 규격 모두 한 중립 재단이 관리합니다. 어느 규격에 붙을지 고민하느라 도입을 미루던 조직에게는 좋은 소식입니다.

다만 배관이 깔리면 그 배관을 타고 오는 요청이 늘어납니다. 어제까지는 우리 시스템에 붙는 상대가 사람과 우리가 만든 애플리케이션이었다면, 이제는 다른 회사가 만들고 다른 클라우드에서 돌아가는 에이전트가 표준 규격으로 문을 두드립니다. 그 문 앞에서 답해야 하는 질문은 프로토콜이 바뀌어도 그대로입니다. 이 요청은 누구의 권한으로 온 것인가, 이 데이터를 이 상대에게 보여 줘도 되는가, 나중에 문제가 되면 무엇을 근거로 설명할 것인가.

세 질문의 답은 모두 데이터 쪽에 있습니다. 어떤 데이터가 어떤 분류에 속하는지, 그 분류에 어떤 접근 정책이 붙어 있는지, 그리고 접근이 일어났을 때 무엇이 기록으로 남는지입니다. 명세가 기업 구현자에게 요구하는 것도 같은 방향입니다. 주고받는 메시지와 산출물에 담긴 데이터의 민감도를 정확히 알고 있어야 하고, 도메인에 맞춰 GDPR과 CCPA, HIPAA 같은 규정을 지켜야 하며, 필요 이상으로 민감한 정보는 애초에 요청하거나 담지 말라고 적혀 있습니다. 어느 것도 프로토콜이 대신 해 줄 수 있는 일이 아닙니다. 이 셋이 정리돼 있지 않은 조직은 표준이 아무리 깔끔해져도 조직 경계를 넘는 위임을 안전하게 열 수 없습니다. 반대로 이 셋이 정리된 조직에게 A2A는 새 위험이 아니라 이미 쓰던 정책을 적용할 창구가 하나 늘어난 일에 가깝습니다.

지금 할 수 있는 준비도 프로토콜 바깥에 있습니다. 우리 조직에서 외부 에이전트에게 열어 줄 수 있는 스킬의 목록을 먼저 정하고, 그 스킬 각각이 어느 데이터에 닿는지를 적어 두고, 위임 요청과 그 결과를 감사 기록으로 남기는 자리를 미리 만들어 두는 일입니다. 명세를 읽는 것보다 오래 걸리지만 명세가 바뀌어도 버려지지 않습니다.

공식 문서

• 1.The Linux Foundation. (2025). Linux Foundation Announces the Formation of the Agentic AI Foundation (AAIF).
• 2.Agentic AI Foundation. (2026). Agent2Agent (A2A) joins AAIF's open agentic stack.
• 3.A2A Project. Enterprise-Ready Features. A2A Protocol Specification.

보도

• 4.Fried, I. (2026). Exclusive: AI agents inch toward interoperability. Axios.
• 5.Janakiram MSV. (2026). Agent2Agent Joins The Agentic AI Foundation Alongside MCP. Forbes.
• 6.Vaughan-Nichols, S. J. (2026). Google Moves A2A Under Agentic AI Foundation. Techstrong AI.