AI기술

Agent2Agent(A2A) 완전 해설: AI 에이전트가 서로 거래하는 표준의 탄생

마지막 업데이트: 2026-06-05

A2A(Agent2Agent)는 서로 다른 곳에서 만든 AI 에이전트들이 표준 규약으로 협업하게 하는 개방형 프로토콜입니다. Google이 2025년 4월에 발표하고, 같은 해 6월 Linux Foundation에 기증했습니다 (Google Developers). 작동 방식은 단순합니다. 에이전트가 자신을 소개하는 명함(Agent Card)을 교환하고, 표준 주문서(Task)를 주고받습니다. MCP(Model Context Protocol, 에이전트가 도구를 쓰게 하는 또 다른 표준)가 에이전트와 도구를 잇는다면, A2A는 에이전트와 에이전트를 잇습니다.

1. 내 식당은 돌아간다, 그런데 옆집과 거래하려면?

한 식당이 혼자 돌아가는 것과, 모르는 옆집과 거래하는 것은 전혀 다른 문제입니다. 후자에는 명함이 필요합니다. 이 장에서는 왜 그 차이가 이 글 전체를 가르는 분기점이 되는지부터 풀어봅니다.

1.1. 하네스까지 오면 식당 하나는 돌아간다

이 시리즈를 따라온 분이라면 식당 하나를 세우는 과정을 이미 봤습니다. 1편 프롬프트 엔지니어링에서 셰프에게 요리를 가르치는 법을, 2편 컨텍스트 엔지니어링에서 재료와 도구를 세팅하는 법을, 3편 하네스 엔지니어링에서 식당 하나가 혼자 돌아가게 만드는 법을 다뤘습니다.

하네스까지 오면 한 가지가 완성됩니다. 주문을 받고, 재료를 조달하고, 조리하고, 검수하고, 클레임에 대응하고, 어제의 피드백으로 오늘을 개선하는 식당 하나가 혼자 돌아갑니다. 사람이 매 단계를 지시하지 않아도 됩니다. 셰프가 멈춰 서서 "다음에 뭘 하죠?"라고 묻는 일이 없어지는 순간, 비로소 식당이라고 부를 수 있습니다.

기업 분석 AI로 치면, 종목 하나를 받아 공시를 읽고, 재무를 수집하고, 밸류에이션을 계산하고, 리포트를 쓰고, 팩트를 체크하는 전 과정이 한 묶음으로 돌아가는 상태입니다. HiveWorks Invest가 매일 굴리는 시스템이 정확히 이 모습입니다.

여기까지는 "내 식당 안의 일"입니다. 내가 고용한 셰프, 내가 세운 주방장, 내가 정한 규칙. 전부 내 통제 안에 있습니다. 그래서 결과를 의심할 이유가 없습니다. 내가 만든 시스템이 내놓은 답이기 때문입니다.

1.2. 내부 분업과 외부 거래는 전혀 다른 문제다

3편에서 멀티에이전트를 다뤘습니다. 리서치 셰프, 분석 셰프, 작성 셰프, 검증 셰프가 분업하는 구조입니다. 그런데 이건 전부 "한 식당 안"의 일입니다. 내가 채용했고, 내가 시스템 프롬프트를 짰고, 누가 어떤 순서로 일하는지 내가 정했습니다.

여기서 신뢰의 근거를 한번 따져봅시다. 분석 셰프가 내놓은 숫자를 작성 셰프가 왜 의심하지 않을까요. 같은 주인이 같은 규칙으로 세팅했기 때문입니다. 신뢰의 근거가 "내가 만들었으니까"입니다. 의심할 필요가 없으니 검증의 비용도 들지 않습니다.

외부 거래는 다릅니다. 옆집은 내가 만들지 않았습니다. 옆집 셰프가 어떤 재료를 쓰는지, 위생 상태가 어떤지, 결과를 믿어도 되는지 알 수 없습니다. 신뢰의 근거가 "내가 만들었으니까"에서 "명함을 보고"로 바뀌어야 합니다. 검증의 비용이 새로 생기고, 그 검증을 누가 어떻게 할 것인가가 통째로 새 문제가 됩니다.

이 차이가 이 글 전체를 관통합니다. 내부 분업은 하네스(3편)가 풀었습니다. 외부 거래는 새로운 표준이 필요합니다. 그 표준이 바로 A2A입니다.

"신뢰의 근거"가 바뀌는 것이 핵심입니다. 내부에서는 만든 사람이 같아서 믿지만, 외부에서는 명함으로 믿어야 합니다.

1.3. 그래서 명함이 필요하다

식당 100개가 서로 거래하고 싶다고 해봅시다. 각자 자기 방식대로 주문서를 쓰면, 모든 쌍이 서로의 양식을 번역해야 합니다. 100개 식당이면 번역해야 할 조합이 수천 개로 폭발합니다. 이것이 N×M 문제입니다. 식당이 늘어날수록 연결의 부담은 제곱으로 커집니다.

해결책은 공통 양식입니다. 모두가 같은 명함 형식, 같은 주문서 형식을 쓰면, 각자 한 번만 그 형식에 맞추면 됩니다. 조합이 N×M에서 N+M으로 줄어듭니다. 식당마다 만들던 수천 개의 번역기가 하나의 공통 규약으로 대체됩니다.

AI 에이전트 세계도 같은 문제에 부딪혔습니다. 회사마다 에이전트를 만드는데, 서로 연결하려면 매번 일대일 커스텀 통합이 필요했습니다. 그래서 Google이 2025년 4월 9일 Google Cloud Next에서 A2A를 발표했습니다. 발표 시점에 이미 50개 이상의 파트너가 함께였습니다 (Google Developers).

핵심은 A2A가 새로운 기능을 발명한 게 아니라는 점입니다. 에이전트끼리 협업하는 "공통 양식"을 정했을 뿐입니다. 발명이 아니라 표준화입니다. 인터넷이 새로운 통신을 발명한 게 아니라 TCP/IP라는 공통 규약을 정했던 것과 같은 종류의 사건입니다.

1.4. agentic, 멀티에이전트, A2A는 같은 말이 아니다

용어가 자주 섞여 쓰입니다. "agentic AI", "멀티에이전트", "A2A"가 같은 뜻처럼 들리지만 사실은 점점 좁아지는 관계입니다. 큰 식당 안에 작은 주방이 있고, 그 주방 안에 거래 규약 하나가 있는 식입니다.

agentic AI가 가장 넓습니다. AI가 스스로 판단하고 도구를 쓰고 행동하는 모든 방식을 말합니다. 셰프 한 명이 스스로 루프를 도는 것도 agentic입니다.

멀티에이전트는 그 안의 한 갈래입니다. 여러 셰프가 분업하는 구조입니다. 한 식당 안의 분업도, 식당 간 협업도 모두 멀티에이전트입니다.

A2A는 다시 그 안의 한 조각입니다. 셰프들이 협업할 때 "어떤 양식으로 소통할 것인가"를 정한 거래 규약 하나입니다. 멀티에이전트를 구현하는 방법이 A2A만 있는 게 아닙니다. 대부분의 agentic 제품은 단일 벤더 프레임워크(LangGraph, CrewAI 등)로 분업을 구현하고, A2A를 쓰지 않습니다 (fka.dev).

복잡하게 외울 필요는 없습니다. 지금은 셋이 다르다는 것만 기억하시면 됩니다. 이 구분이 중요한 이유는 5장에서 드러납니다. "에이전트가 폭발적으로 늘었다"는 사실과 "A2A가 실제로 쓰인다"는 사실은 전혀 다른 이야기이기 때문입니다.

agentic이 곧 A2A가 아닙니다. 셋이 다르다는 것만 기억하면 됩니다.

2. A2A란 무엇인가

A2A는 명함을 교환하고 주문서를 주고받는 방식을 표준화했습니다. MCP가 주방 설비라면, A2A는 식당 간 거래 규약입니다. 이 장에서는 명함(Agent Card), 주문서(Task), 그리고 모르는 사이의 신뢰 문제를 차례로 봅니다.

2.1. MCP는 주방 설비, A2A는 식당 간 거래

가장 흔한 오해부터 풉니다. "A2A가 MCP를 대체하느냐"는 질문입니다. 답은 아닙니다. 둘은 다른 층을 담당합니다.

MCP(Model Context Protocol)는 에이전트가 도구와 데이터에 접근하는 방법입니다. 셰프가 오븐, 냉장고, 칼을 쓰는 것과 같습니다. 주방 설비를 표준 규격으로 연결합니다. 위에서 아래로 내려가는 수직 연결입니다.

A2A는 능력을 갖춘 에이전트끼리 협력하는 방법입니다. 우리 식당이 옆집 식당에 일을 맡기는 것과 같습니다. 대등한 사업자 간 거래입니다. 좌우로 나란히 선 수평 연결입니다.

Google 공식 문서가 명시적으로 적습니다. "A2A is an open protocol that complements Anthropic's Model Context Protocol (MCP)." 대체(replace)가 아니라 보완(complement)입니다 (Google Developers). 권장 아키텍처도 둘을 함께 씁니다. A2A로 에이전트 간 조율을 하고, 각 에이전트 내부는 MCP로 도구에 접근합니다. 하나를 고르는 문제가 아니라 층을 나누는 문제입니다.

MCP는 에이전트와 도구를 잇는 수직 연결, A2A는 에이전트와 에이전트를 잇는 수평 연결입니다. 층이 다릅니다.

2.2. 명함을 교환한다 (Agent Card)

모르는 옆집과 거래하려면 먼저 명함을 받아야 합니다. A2A에서 이 명함이 Agent Card입니다. 에이전트가 공개하는 JSON 형식의 자기소개서입니다.

명함에 담기는 것은 이렇습니다. 신원(이름, 설명, 제공자), 서비스 엔드포인트 URL(어디로 일을 보내는지), 지원 기능(스트리밍·푸시 알림 가능 여부), 인증 방식(어떻게 신원을 확인하는지), 그리고 Skills 카탈로그입니다.

Skills 카탈로그가 핵심입니다. "나는 이런 일을 할 수 있다"를 항목별로 적습니다. 각 Skill에 ID, 이름, 설명, 입출력 형식, 예시가 들어갑니다. 옆집이 이 카탈로그를 보고 "이 식당에 디저트를 맡길 수 있겠다"를 판단합니다 (A2A Spec).

명함은 어디서 찾을까요. 기본은 정해진 주소입니다. 도메인 뒤에 /.well-known/agent-card.json을 붙이면 명함이 나옵니다. 웹사이트의 표준 위치 규약(RFC 8615)을 그대로 씁니다. 중앙 레지스트리에 등록하거나, 직접 주소를 설정하는 방법도 있습니다 (A2A Core Concepts). 명함을 공개한다는 게 곧 아무나 일을 시킬 수 있다는 뜻은 아닙니다. 민감한 정보가 담긴 명함은 인증된 상대에게만 보여주는 확장 카드(Authenticated Extended Card)로 보호합니다.

📇 Agent Card는 JSON으로 된 디지털 명함입니다. 이름, 할 수 있는 일, 연락처, 인증 방식이 한 장에 담깁니다.

2.3. 주문서가 오간다 (Task)

명함을 교환했으면 이제 일을 맡깁니다. A2A에서 일의 단위가 Task입니다. 고유 번호가 붙은 주문서인데, 여기서 비전문가가 가져갈 핵심이 두 가지입니다. 첫째, 이 주문서는 상태를 가집니다. 둘째, 결과는 Artifact로 돌아옵니다. 이 둘만 기억하면 충분합니다.

먼저 상태입니다. 주문서의 생명주기는 식당 주문과 닮았습니다. 접수(submitted)에서 조리 중(working)으로, 그리고 완성(completed) 또는 실패(failed)로 흐릅니다. 중간에 추가 정보가 필요하면 일시 중단(input-required), 인증이 필요하면 멈춤(auth-required) 상태로 갑니다. 한 번 완료·실패·취소로 끝난 주문서는 다시 시작할 수 없습니다 (A2A Spec). 주방에 걸린 주문 전표가 "접수 → 조리 중 → 나감"으로 바뀌는 것과 같습니다.

다음은 결과입니다. 완성된 문서, 이미지, 구조화된 데이터가 Artifact입니다. 완성된 접시가 손님 테이블로 나가는 것과 같습니다. 큰 결과물은 한 번에 다 주지 않고 조각조각 흘려보낼 수 있습니다(점진적 스트리밍).

주문서를 채우는 세부 양식도 표준화돼 있습니다. 한 번의 대화 턴이 Message이고, 그 안에 담기는 최소 콘텐츠 단위가 Part입니다(텍스트, 바이너리, 외부 파일 링크, 구조화된 JSON 중 하나의 타입). 이 정도만 알아두면 충분합니다.

문제는 수시간에서 수일이 걸리는 장기 작업입니다. 연결을 계속 붙들고 있을 수 없습니다. 그래서 A2A는 연결이 끊겨도 결과가 나오면 약속한 주소(webhook)로 알려주는 푸시 알림을 둡니다. 연결을 유지하며 이벤트를 흘려보내는 스트리밍 방식(SSE)도 함께 지원합니다. 이 비동기 장기 작업 처리가 A2A의 고유 영역 중 하나입니다. 3장과 5장에서 다시 봅니다.

거래의 전 과정입니다. 명함을 조회하고, 주문서를 보내고, 상태가 흐르고, 결과물이 돌아옵니다.

2.4. 모르는 사이인데 어떻게 믿나

모르는 옆집에 일을 맡기는데, 그 옆집이 진짜 그 옆집인지 어떻게 압니까. A2A의 답은 의외로 보수적입니다. 새로운 신원 체계를 발명하지 않고, 이미 검증된 웹 보안 표준을 그대로 가져다 씁니다.

설계 원칙은 "에이전트를 표준 엔터프라이즈 앱으로 취급한다"입니다. 신원 확인을 주문서 내용이 아니라 통신 채널(HTTP 전송 계층)에서 처리합니다. 명함에 어떤 인증 방식을 받을지 적어두고(securitySchemes), 실제 통신할 때 그 방식으로 신원을 증명합니다 (A2A Spec).

지원하는 방식은 웹에서 이미 쓰이는 것들입니다. API 키, HTTP 기본 인증, Bearer 토큰, OAuth 2.0, OpenID Connect, mTLS. 새로 배울 게 없습니다.

여기까지가 A2A가 답한 부분입니다. "이 통신이 위조되지 않았는가"는 기존 웹 표준으로 풉니다. 그런데 더 깊은 질문이 남습니다. "이 에이전트가 진짜 위임받은 권한 안에서 행동하는가", "사고가 나면 누구 책임인가." 이건 채널 인증으로 풀리지 않습니다. 이 진짜 신뢰 문제가 4장의 본론입니다.

A2A는 신원을 새로 발명하지 않고 기존 웹 표준에 맡깁니다. 더 깊은 신뢰 문제는 4장에서 다룹니다.

3. 그런데 표준이 하나가 아니다

에이전트 통신 표준은 A2A 하나가 아닙니다. MCP·ACP·ANP·AGORA·AGNTCY가 각축했고, 지금은 전쟁이 아니라 수렴 중입니다. 그리고 MCP가 도구층을 사실상 평정했습니다.

결론부터 말씀드리면, 지금은 MCP(도구)와 A2A(에이전트) 둘로 정리됐고, 나머지는 흡수되거나 연구 단계입니다. 아래는 그 결론에 이르는 지형을 차례로 풀어가는 내용입니다.

3.1. 계약서 양식이 동네마다 다르다

A2A만 있었다면 이야기가 단순했을 겁니다. 그런데 2024년부터 2025년 사이, 에이전트끼리 소통하는 방법을 정하겠다는 표준이 줄줄이 나왔습니다. MCP(Anthropic), A2A(Google), ACP(IBM), ANP(개인 개발자), AGORA(학계), AGNTCY(Cisco)까지.

왜 이렇게 많은 곳이 표준을 만들려 했을까요. 계약서 양식을 누가 정하느냐가 곧 거래의 주도권을 누가 쥐느냐이기 때문입니다. 표준을 잡으면 그 위에서 도는 모든 거래의 길목을 쥡니다. 플랫폼 권력입니다. 그래서 거대 기업이 전부 뛰어들었습니다.

각 표준은 출신과 철학이 다릅니다. MCP는 도구 연결에서 출발했고, A2A는 대등한 에이전트 협업에서, ACP는 "에이전트 통신의 HTTP"를 표방하며, ANP는 완전 탈중앙(블록체인 신원), AGORA는 자연어 기반, AGNTCY는 "에이전트의 인터넷"을 내걸었습니다.

3.2. 두 철학: 양식이냐, 대화냐

표준이 많아 보이지만, 철학으로 묶으면 크게 두 갈래입니다.

첫째, 구조적(스키마 기반) 방식입니다. 미리 정해진 양식(JSON 스키마)에 맞춰 주고받습니다. MCP, A2A, ACP가 여기 속합니다. 양식이 고정돼 있어 빠르고 정확하지만, 양식에 없는 새 상황엔 대응이 어렵습니다.

둘째, 자연어 기반 방식입니다. 정해진 양식 없이 에이전트끼리 말로 협상합니다. 학계의 AGORA가 대표적입니다. AGORA는 "통신 트릴레마"를 풀겠다는 메타 프로토콜입니다. 트릴레마란 범용성·효율성·이식성을 동시에 만족하기 어렵다는 것, 쉽게 말해 싸고 빠르고 어디서나 되는 걸 한꺼번에 만족하긴 어렵다는 뜻입니다. AGORA는 자주 쓰는 소통은 표준 루틴으로 굳히고, 드문 소통은 자연어로 하고, 중간은 LLM이 즉석에서 루틴을 작성합니다 (arXiv 2410.11905).

AGORA는 토큰을 98% 줄이고 완전 탈중앙을 달성했다고 주장합니다. 100개 에이전트로 1,000개 쿼리를 처리하는 실험을 제시했습니다. 다만 서베이 분류상 아직 "개념(Concept)" 단계이고, 프로덕션 채택 데이터는 없습니다.

절충이 흥미롭습니다. 매번 자연어로 협상하면 비쌉니다. 그래서 자주 쓰는 패턴은 구조화된 양식으로 굳혀 비용을 낮춥니다. 구조적 방식과 자연어 방식이 양극단이 아니라 스펙트럼이라는 신호입니다.

3.3. 전쟁이 아니라 수렴 중

"표준 전쟁"이라는 표현을 자주 봅니다. 그런데 2026년 시점의 실제 흐름은 전쟁보다 수렴에 가깝습니다.

가장 상징적인 사건은 ACP의 A2A 통합입니다. IBM이 만든 ACP는 2025년 8월 29일 A2A로 합치겠다고 공식 발표했습니다. IBM의 Kate Blair는 "ACP의 자산과 전문성을 A2A로 가져가 하나의 더 강한 표준을 만들겠다"고 밝혔습니다. ACP는 독자 개발을 멈췄고, IBM은 A2A 기술 운영위원회에 합류했습니다 (LF AI & Data).

거버넌스도 모이고 있습니다. A2A는 2025년 6월 Linux Foundation 산하로, MCP는 2025년 12월 AAIF(Agentic AI Foundation, Anthropic·OpenAI·Block 공동 설립) 산하로 들어갔습니다. 같은 Linux Foundation 우산 아래 다른 프로젝트 그룹이지만, 중립적 거버넌스로 모이는 방향은 같습니다.

수직 스택도 만들어지고 있습니다. 도구 접근은 MCP, 에이전트 협업은 A2A, 그 위 결제는 AP2(Agent Payments Protocol)로 층이 쌓입니다. 경쟁이 아니라 적층입니다.

경쟁이 아니라 적층. 각 층이 다른 일을 합니다.

3.4. MCP가 A2A를 대체하나: 대체 논쟁

"그래서 MCP가 A2A를 잡아먹는 거 아니냐"는 질문이 끊이지 않습니다. 입장이 셋으로 갈립니다.

첫째, 대체론입니다. fka.dev는 2025년 9월 "A2A는 조용히 사라졌고 MCP가 사실상 표준이 됐다"고 적었습니다 (fka.dev). Credal은 "A2A가 광고한 기능 대부분을 MCP가 이미 지원한다"고 지적합니다 (Credal).

둘째, 공존론입니다. 이쪽이 주류입니다. Google, Anthropic, Cisco, 그리고 다수의 서베이 논문이 "역할이 다르니 둘 다 필요하다"고 봅니다. 핵심 논거는 구조의 차이입니다. MCP는 비대칭 관계(주인-도구)이고 클라이언트가 모든 것을 개시합니다. A2A는 대칭 관계(대등)를 지향하고 양방향입니다. 한 서베이는 이렇게 못 박습니다. "MCP의 함수 호출은 근본적으로 모델이 통제하는 클라이언트-서버 구조이고, A2A는 동등한 자율성을 요구한다. MCP는 오케스트레이션을 LLM 클라이언트에 집중시키기 때문에 이를 복제할 수 없다" (arXiv 2505.02279).

셋째, 수렴론입니다. ACP의 A2A 흡수, Linux Foundation 거버넌스 수렴처럼 기술이 한 점으로 모인다는 시각입니다.

그렇다면 우리는 어떻게 판단할까요. 레이어가 다르므로 기능적 대체는 불가능합니다. A2A에는 MCP로 못 하는 고유 영역(크로스 조직 발견, IP 보호 에이전트, 수일짜리 비동기, 대등 협상)이 분명히 있습니다. 그런데 두 가지가 겹칩니다. 첫째, 그 고유 영역을 실제로 필요로 하는 실무 수요가 아직 드뭅니다. 그래서 현실에서는 MCP가 대부분을 커버합니다. 둘째, MCP가 A2A 쪽으로 진화하고 있습니다. 2025년 11월 MCP 스펙에 비동기 장기 작업(Tasks), 서버가 클라이언트 LLM을 역호출하는 Sampling이 추가됐고, 2026년 로드맵에는 A2A의 명함과 유사한 .well-known 서버 발견이 들어갔습니다.

이 온도를 가장 정확히 보여주는 것이 Thoughtworks Technology Radar의 평가입니다. MCP는 "Trial" (Thoughtworks MCP), A2A는 한 단계 아래인 "Assess" (Thoughtworks A2A) 단계입니다. 채택하라가 아니라 살펴보라입니다.

3.5. 지금 가장 앞선 진영

지형을 한눈에 정리하면 이렇습니다.

도구층(에이전트↔도구)은 MCP가 사실상 평정했습니다. 2026년 3월 기준 레지스트리에 등록된 공개 서버만 약 2,000개, SDK 월 다운로드 9,700만 건입니다. OpenAI, Google DeepMind, Microsoft, AWS가 차례로 채택했습니다. 다만 SDK 다운로드 수치는 공식 직접 집계가 아니라 복수 블로그 인용이라는 점은 감안할 필요가 있습니다 (WorkOS).

에이전트층(에이전트↔에이전트)은 A2A가 선두입니다. 150개 이상 기관, 3대 클라우드(Google·Azure·AWS) 통합, 5개 언어 SDK. 숫자만 보면 압도적입니다.

그런데 "선두"와 "실사용"은 다릅니다. 150개 기관은 대부분 "지원하겠다"는 선언이지, "프로덕션에서 쓰고 있다"가 아닙니다. 이 간극이 5장의 핵심입니다. 나머지(ANP·AGORA·LOKA·NANDA)는 학계·연구 단계입니다. 기술적으로 흥미롭지만 생태계가 미완성입니다.

위치는 개념적 분류입니다. MCP가 도구층을, A2A가 에이전트층을 이끌고 나머지는 연구 단계라는 지형을 보여줍니다.

규모 단위가 다릅니다(서버 수 vs 기관 수). 직접 비교가 아니라 각 층의 성숙도 차이로 읽어야 합니다.

4. 아직 아무도 못 푼 난제들

A2A가 표준을 깔았어도, 모르는 에이전트를 진짜 믿는 문제, 사고 책임을 묻는 문제, 한 곳이 뚫리면 다 뚫리는 문제는 아직 풀리지 않았습니다.

여기서부터 조금 어려워집니다. 핵심만 가져가셔도 됩니다. 지금까지 식당 비유로 A2A가 어떻게 작동하는지를 봤습니다. 이 장부터는 같은 비유를 쓰되 진지한 연구의 영역으로 들어갑니다. A2A는 "옆집과 말을 트는 법"을 표준화했습니다. 그런데 "처음 보는 옆집을 진짜 믿어도 되는가"라는 질문은 말 트는 법만으로 풀리지 않습니다. 이 장에서 다루는 네 가지 난제가 바로 그 질문들입니다. 그리고 이 난제들이 풀리지 않았다는 사실이, 5장에서 "왜 아직 안 쓰이는가"의 근본 원인이 됩니다.

4.1. 모르는 에이전트를 어떻게 믿나

2.4에서 A2A가 신원 확인을 기존 웹 표준에 맡긴다고 했습니다. 문제는 그 웹 표준이 보장하는 범위입니다. OAuth·mTLS는 "이 통신이 중간에 변조되지 않았다"는 것까지만 보장합니다. "이 에이전트가 위임받은 권한 안에서만 행동하고 있다"는 보장하지 못합니다.

구체적 어려움이 여럿입니다. 이종 에이전트가 처음 대면할 때 신원을 검증할 공통 메커니즘이 없습니다. 기존 권한 관리(RBAC, API 키)는 위임 범위를 잘게 나누거나 다단계 위임 체인을 검증하지 못합니다. A가 B에게, B가 다시 C에게 권한을 넘길 때 그 체인이 정당한지 확인할 방법이 표준화돼 있지 않습니다.

더 근본적인 문제도 있습니다. 같은 LLM 위에 여러 에이전트 인스턴스가 돌고, 세션마다 신원이 새로 생성됩니다. "이 에이전트는 항상 같은 그 에이전트"라는 지속적 신원 개념 자체가 약합니다.

연구는 진행 중입니다. DID(분산 신원자)와 검증 가능한 자격증명(VC)으로 대화 시작 시 신원 소유권을 증명하자는 제안이 있습니다. 다만 저자들도 "LLM이 보안 절차를 단독으로 제어할 때의 실용적 한계"를 인정합니다 (arXiv 2511.02841). OAuth를 에이전트 위임에 맞게 확장하려는 IETF 초안도 있었으나 공식 절차로 진행되지 못하고 만료됐습니다. 신원 인식 프로토콜(LDP) 같은 새 설계는 쉬운 작업에서 지연을 크게 줄였다고 보고하지만, 아직 학술 단계입니다 (arXiv 2603.08852).

채널 인증(초록)까지는 A2A가 풀었지만, 위임 범위와 위임 체인(노랑·빨강)은 표준이 비어 있습니다.

4.2. 사고가 나면 누구 책임인가

옆집 셰프에게 일을 맡겼다가 사고가 났습니다. 잘못된 주문이 실행됐고, 손해가 발생했습니다. 누구 책임입니까. 일을 맡긴 우리 식당입니까, 일을 받은 옆집 셰프입니까, 그 셰프를 고용한 옆집 사장입니까, 처음에 위임한 손님입니까. 에이전트 세계에서 이 질문은 비유가 아니라 실제 난제입니다.

2026년 4월 한 논문이 이 질문을 수학적으로 다뤘습니다. "책임 지평선(Accountability Horizon)"이라는 불가능성 정리입니다. 책임을 제대로 물으려면 네 가지가 동시에 성립해야 합니다. 귀속 가능성(누가 그랬는지 콕 집어낼 수 있어야 함), 예견 가능성(그 결과를 미리 내다볼 수 있었어야 함), 비공허성(책임이 말뿐이 아니라 실제로 물을 수 있어야 함), 완전성(아무도 책임지지 않는 빈틈이 없어야 함). 논문은 자율성이 일정 선을 넘으면 이 네 가지를 동시에 만족하는 것이 수학적으로 불가능함을 증명했습니다. 3,000개의 합성 집합체로 검증했습니다 (arXiv 2604.07778).

함의가 무겁습니다. 흔히 "투명성을 높이고, 감사 로그를 남기고, 감독을 강화하면 책임 문제를 풀 수 있다"고 생각합니다. 이 논문은 그것만으로는 풀 수 없다고 말합니다. 책임의 빈틈을 없애려면 자율성 자체를 낮춰야 한다는 것입니다. 옆집에 모든 걸 알아서 하라고 맡길수록, 사고가 났을 때 책임을 물을 수 있는 끈이 끊어집니다.

이것이 5장에서 다시 등장하는 "어디까지 알아서 맡길 것인가"의 이론적 천장입니다. 에이전트가 완전히 알아서 거래하는 세상은, 책임을 물을 수 없는 세상과 같습니다. 그래서 현실의 선택은 "완전 자율"이 아니라 "통제된 자율"로 수렴합니다.

다만 오해하면 안 됩니다. 불가능한 것은 "완전 자율"이지 "에이전트 경제" 자체가 아닙니다. 사람이 핵심 결정을 쥐는 선에서는 충분히 가능합니다. 이 선이 5.3에서 그리는 일상의 모습을 결정합니다.

Tibebu & Shemtaga(2026)의 불가능성 정리를 개념적으로 표현했습니다.

4.3. 한 곳 뚫리면 다 뚫린다

셰프 한 명은 위생 관리를 잘해도, 식당 여러 곳이 주방을 트고 재료를 돌려쓰기 시작하면 오염원이 폭발적으로 늘어납니다. 에이전트도 똑같습니다. 하나는 잘 막아도, 여러 에이전트가 연결되면 공격면이 폭발하고, 개별 방어가 있어도 시스템 전체가 뚫립니다.

가장 강한 수치 하나만 기억하면 됩니다. 한 연구가 멀티에이전트 시스템을 하이재킹해 임의의 악성 코드를 실행시키는 웹 공격의 성공률을 측정했더니 58%에서 90%, 일부 설정에서는 100%였습니다. 연구진의 결론은 단호합니다. "광범위하게 배포하기 전에 신뢰·보안 모델을 먼저 만들어야 한다" (arXiv 2503.12188).

전파 방식도 새롭습니다. 악성 프롬프트가 바이러스처럼 자기 복제하며 에이전트 사이를 옮겨 다니는 "프롬프트 감염"이 보고됐고 (arXiv 2410.07283), OWASP는 프롬프트 인젝션을 2025년 LLM 보안 위협 1위로 올렸습니다 (OWASP).

A2A 자체의 구조적 취약점도 지적됩니다. 명함(Agent Card)에 종단간 서명이 의무가 아니어서, 위조된 명함으로 가짜 능력을 광고할 여지가 있습니다 (arXiv 2602.11327). 별도 분석에서는 인증 토큰의 수명이 강제되지 않고 기능이 바뀌어도 재인증이 의무가 아니라는 점이 지적됐습니다 (arXiv 2511.03841). 개방형 연결이 늘수록 이 빈틈이 위험해집니다.

정리하면, 보안 미성숙은 단순한 버그가 아니라 "개방형 에이전트 연결"이라는 방향 자체를 가로막는 구조적 장벽입니다.

공급망을 노려 적대적 스킬을 심는 우회 기법의 성공률 11.6~33.5% 같은 세부 수치는 위 박스에 정리했습니다 (arXiv 2604.03081).

4.4. 남은 두 벽: 능력 발견과 결제

두 가지 벽이 더 남았습니다.

첫째, 능력 발견과 협상입니다. A2A의 명함(Agent Card)은 "내가 무엇을 할 수 있다"를 광고하는 산업적 답입니다. 그런데 런타임에 에이전트가 서로의 능력을 자동으로 발견하고 매칭하는 표준은 아직 미완성입니다. 능력은 맥락에 따라 달라지고, 능력을 표현하는 공통 언어가 없어 의미 불일치가 생깁니다. 한 연구는 능력 통지, 발견, 동적 매칭, 합의를 모두 미해결 과제로 명시합니다 (arXiv 2505.07176).

둘째, 결제입니다. 에이전트가 자율적으로 돈을 지불하는 메커니즘이 없습니다. 기존 결제 인프라는 사람이 설정하고 관리하는 것을 전제합니다. 게다가 기존 결제는 확정적 실행과 법적 확정성을 전제하는데, LLM은 확률적입니다. 할루시네이션으로 잘못 결제하면 책임을 물을 프레임이 없습니다. IMF는 2026년 보고서에서 할루시네이션 결제 오류, 책임 귀속 부재, 상호운용 미표준, 분쟁 프레임 미정립을 미해결로 짚었습니다 (IMF).

결제 표준화 시도는 시작됐습니다. Google의 AP2(2025년 9월 발표, 60개 이상 기업), Coinbase의 x402(HTTP 402 기반 온체인 결제)가 대표적입니다. 이 결제 레이어가 5장의 "에이전트 경제" 비전과 직결됩니다.

5. 그래서, 세상은 정말 바뀌고 있나

표준은 깔렸습니다. 그런데 서로 다른 회사의 에이전트가 실제 프로덕션에서 협업하는, 검증된 사례는 0건입니다. 표준 채택은 빠르지만 실사용은 이제부터입니다.

각자 자기 식당을 완성하고, 그 식당들이 서로 거래하는 세상. 정말 오고 있을까요. 어디까지 사람이 정하고, 어디까지 에이전트가 알아서 할까요. 이 장에서는 마케팅 표제를 걷어내고, 지금 실제로 무엇이 돌아가는지를 직접 확인합니다.

5.1. 정말 돌아가고 있나: 검증

검증 기준을 먼저 세웠습니다. 사례를 네 단계로 나눕니다. ① 프로덕션(실제 운영), ② 파일럿, ③ 데모/PoC, ④ 지원 선언. 우리가 찾는 것은 ①, 그중에서도 "서로 다른 회사(cross-vendor)"의 에이전트가 A2A로 협업하는 사례입니다.

결과를 먼저 말합니다. 검증된 cross-vendor 프로덕션 사례는 0건입니다.

알려진 사례들을 하나씩 확인하면 이렇습니다. Google 블로그가 든 Tyson Foods와 Gordon Food Service 사례는 기술 세부와 단계가 없는 마케팅 서술이라 검증할 수 없습니다. ServiceNow와 Google ADK의 연동은 문서 자체가 "proof-of-concept"라고 명시하며, sandbox 환경에서 무료 등급으로 돌린 것입니다. Microsoft Copilot Studio의 외부 A2A 연동은 2026년 4월 정식 출시됐지만, 공개된 샘플은 로컬 데모이고 이름이 공개된 고객 사례가 0건입니다 (ServiceNow PoC, MS Copilot A2A).

Linux Foundation의 1주년 발표 제목은 "enterprise production use"였지만, 본문은 "production-ready open standard"라고 적습니다. "실제로 쓰이고 있다"가 아니라 "쓸 준비가 된 표준"이라는 뜻입니다. cross-vendor 협업도 "LangGraph나 CrewAI로 만든 에이전트가 함께 일할 수 있다(able to)"는 설계 원칙이지 실사례가 아닙니다 (LF 발표).

그렇다면 150개 기관이 참여했다는 숫자와 실사용 0건의 간극은 어떻게 이해해야 할까요. 참여 선언은 미래의 길목을 놓치지 않으려는 보험이지, 지금 쓰겠다는 약속이 아닙니다. 식당 간 표준 거래 규약이 생기면 일단 이름을 올려두는 것과 같습니다. 실제로 옆집과 거래를 트는 것은 그다음 문제입니다.

분명히 짚어야 할 것이 있습니다. ServiceNow나 Walmart 같은 곳에서 에이전트가 실제 성과를 내고 있는 사례는 존재합니다. 그러나 그 성과는 "한 식당 안에서 도는 에이전트", 즉 단일 벤더 안에서 도는 에이전트의 성과이지, "A2A로 서로 다른 회사의 에이전트가 협업한" 성과로 단정할 근거가 없습니다. A2A가 연결을 표준화하기 시작한 것은 사실이지만, A2A가 그 성과를 냈다고 말하는 것은 과장입니다.

5.2. 왜 안 쓰이나: 진짜 이유

"표준이 좋은데 왜 안 쓰이나." 답은 단순합니다. A2A가 표준화한 것(대등한 에이전트 간 거래)을 실무가 아직 필요로 하지 않기 때문입니다.

실무의 멀티에이전트는 거의 다 비대칭입니다. 한 리드 에이전트가 서브 에이전트들에게 일을 시키고 결과를 합칩니다. 서브 에이전트끼리 직접 협상하지 않습니다. Anthropic의 멀티에이전트 연구 시스템도 리드가 서브에게 위임하는 구조이고, OpenAI의 에이전트 SDK도 부모-자식 비대칭이며, LangGraph는 중앙 상태 시스템입니다. LangGraph는 대등한 P2P 방식을 "지연이 지배적이고 에이전트 간 신뢰가 성숙했을 때만" 권장합니다 (Anthropic).

비대칭 구조에서는 A2A가 필요 없습니다. 리드가 워커를 도구처럼 부르면 되고, 그건 MCP로 충분합니다. 실제로 "에이전트를 MCP 서버로 노출"하는 패턴이 이미 존재합니다.

A2A의 고유 영역이 실질적으로 필요해지는 조건은 좁습니다. (a) 서로 다른 조직의 에이전트를 발견해야 하거나, (b) 내부를 공개할 수 없는 IP 보호 상용 에이전트이거나, (c) 수시간에서 수일짜리 비동기 작업이거나, (d) 런타임에 능력을 발견해야 하는 경우입니다. 이 중 하나 이상에 해당해야 A2A가 빛납니다. 그런데 대부분의 멀티에이전트는 단일 조직, 단일 프레임워크 안에서 돌기 때문에 이 조건을 만나지 않습니다.

A2A를 만든 측도 인정합니다. A2A조차 "조직의 신뢰 경계 안"을 주 타깃으로 하고, 크로스 조직 위임은 "아직 해결 중"이라고 서베이가 적습니다 (arXiv 2505.02279). 한 엔터프라이즈 AI 분석가는 에이전트 lock-in이 모델·오케스트레이션·런타임·개발 패턴 여러 층에 동시에 쌓여 API lock-in보다 더 끈질기다고 지적합니다. 각 벤더 생태계 안에서는 매끄럽게 작동하지만, 바로 그 점이 서로 다른 회사의 에이전트를 연결하기 어렵게 만듭니다 (Kai Waehner).

에이전트를 직접 만드는 입장이라면 이렇게 정리할 수 있습니다. 지금 에이전트를 만든다면, 위의 (a)~(d) 조건에 해당하지 않는 한 단일 프레임워크나 MCP로 시작하고 A2A는 살펴보는(Assess) 단계로 두는 것이 현재로선 합리적인 선택입니다. 옆집과 거래할 일이 정말 생기는 시점에 A2A를 얹어도 늦지 않습니다.

실무는 왼쪽(비대칭)이 지배합니다. A2A가 필요한 오른쪽(대칭) 수요가 아직 드뭅니다.

5.3. 곧 올 일상과 에이전트 경제

A2A가 표준화한 세상이 오면 일상은 이렇게 바뀝니다. 미리 강조하면, 이것은 현재가 아니라 개념 시나리오입니다.

여행을 봅시다. "11월 첫째 주, 700달러 안에서 왕복 항공과 호텔"이라고 말하면, 내 에이전트가 항공사 에이전트, 호텔 에이전트, 여행사 에이전트와 A2A로 대화하며 조합을 찾고, 조건이 맞으면 예약까지 합니다.

쇼핑도 마찬가지입니다. "초록색 겨울 재킷, 예산보다 20%까지는 더 써도 좋아"라고 위임하면, 에이전트가 판매자 에이전트들과 협상하고 번들 할인을 찾아 구매합니다(AP2의 Intent Mandate 개념).

이것이 1장의 수미상관입니다. 식당 하나가 혼자 돌아가던 것에서, 식당들이 서로 거래하는 도시로 확장됩니다. Satya Nadella는 "운영체제와 앱에서 에이전트로 옮겨가고 있다. 에이전트는 다른 에이전트와 협력하는 관리된 디지털 노동자"라고 말합니다 (9to5Mac).

시장 전망도 큽니다. AI 에이전트 시장은 2025년 약 79억 달러에서 2035년 약 2,947억 달러로 성장이 예측됩니다(연평균 43.57%) (Precedence Research).

그런데 "어디까지 자율인가"의 답은 4.2가 이미 정했습니다. 완전 자율은 책임을 물을 수 없는 세상과 같습니다. 그래서 현실의 답은 통제된 자율입니다. 중요한 결정에는 사람의 승인 단계를 남기고, 에이전트의 자율 범위를 책임을 물을 수 있는 선 안에 둡니다.

단일 기관(Precedence Research) 추정입니다. 기관마다 정의·추정이 다르므로 방향(고성장)만 읽어야 합니다.

5.4. 그러나 거품일 수도 있다

같은 데이터를 신중하게 읽는 시각도 강합니다.

Gartner는 2027년 말까지 agentic AI 프로젝트의 40% 이상이 취소될 것으로 예측합니다. 비용, 불분명한 ROI, 데이터 품질이 이유입니다 (Gartner).

신뢰는 더 냉정합니다. 한 조사(n=603)에서 핵심 프로세스에 에이전트를 완전히 신뢰하는 기업은 6%, 인프라가 완전히 준비된 기업은 20%에 그쳤습니다 (Fortune).

McKinsey는 거버넌스가 배포보다 두 단계 뒤처져 있다고 진단합니다. 자율 에이전트를 배포한 기업 중 거버넌스 성숙도에 도달한 곳은 약 3분의 1입니다 (McKinsey).

파일럿에서 프로덕션으로 넘어가는 비율도 11~14%에 불과합니다(agentic 전반이며, A2A는 더 적습니다). UiPath는 파일럿 실패의 2위 원인으로 상호운용성 부재를 꼽았습니다. 역설적이게도 A2A가 풀려는 바로 그 문제입니다.

5.5. 마무리

정리합니다. A2A는 MCP로 대체할 수 없는 고유 영역(대등한 에이전트끼리의 거래)을 표준화했습니다. 명함을 교환하고 주문서를 주고받는 "말 거는 법"을 만들었습니다.

그런데 그 고유 영역을 필요로 하는 실무 수요가 아직 없습니다. 실무는 비대칭 구조가 지배하고, 그건 MCP로 충분합니다. 그래서 표준만 깔리고 실사용은 0에 가깝습니다. MCP가 이긴 게 아니라, A2A의 시간이 아직 안 온 것입니다.

그 시간은 4장의 난제가 풀리는 만큼 옵니다. 모르는 에이전트를 믿는 법, 사고 책임을 묻는 법, 한 곳이 뚫려도 전체가 안전한 법. 이 난제들이 풀려 에이전트 경제가 현실이 되는 날, A2A가 표준화한 고유 영역의 수요가 실무에 생깁니다.

표준이 "말 거는 법"을 깔았으니, 다음 10년은 "믿고 맡기는 법"을 만드는 시간입니다.

🔬MCP란 무엇인가? AI를 세상과 연결하는 오픈 표준 프로토콜

A2A의 짝, MCP. 에이전트와 도구를 잇는 표준의 작동 원리와 실전의 벽까지 완전 해설합니다.

→