A2A 프로토콜(Agent2Agent)이란 무엇인가요? 에이전트 상호운용성·에이전트 카드·MCP 보완으로 본 2026 기업 멀티에이전트 도입 완전 가이드

A2A 프로토콜(Agent2Agent)은 서로 다른 벤더·프레임워크로 만들어진 AI 에이전트가 상대의 내부 구조를 모른 채로도 서로를 발견하고, 일을 위임하고, 협업하게 해주는 개방형 통신 표준입니다. 2025년 구글이 공개해 리눅스 재단(Linux Foundation)으로 이관됐고, 2026년 v1.0을 거치며 150개 이상의 조직과 구글·마이크로소프트·AWS 주요 클라우드가 채택했습니다. 핵심은 에이전트 카드(Agent Card)로 능력을 광고하고, 태스크(Task) 단위로 협업하며, 도구 연동 표준인 MCP와는 다른 계층에서 서로를 보완한다는 점입니다. 이 글은 산업 배경부터 작동 원리, MCP와의 차이, 기업 도입 4단계까지를 정리한 2026 멀티에이전트 도입 가이드입니다.

현장에서 마주친 에이전트들의 단절
A2A 프로토콜이란 무엇인가요
A2A는 어떻게 작동하나요: 에이전트 카드·태스크·아티팩트
A2A와 MCP는 무엇이 다른가요
어디에 쓰이나요: 산업별 활용 사례
기업 도입 4단계 실전 가이드
FAQ
같이 읽으면 좋은 것들

현장에서 마주친 에이전트들의 단절

지난 분기에 한 제조 유통 기업의 내부 자동화 프로젝트를 들여다본 적이 있습니다. 그 회사는 영업팀이 세일즈포스 기반 에이전트를, 물류팀이 자체 파이썬으로 만든 주문 처리 에이전트를, 재무팀이 SAP 쪽 에이전트를 각각 운영하고 있었는데요. 세 에이전트 모두 자기 영역에서는 꽤 똑똑하게 일을 처리했습니다. 문제는 그 셋이 서로 대화를 못 한다는 데 있었습니다.

고객이 "주문 가능 수량과 예상 정산일을 한 번에 알려달라"고 물으면, 사람이 중간에서 세 시스템을 오가며 결과를 손으로 이어 붙여야 했습니다. 영업 에이전트가 재고 에이전트에게 직접 질문을 던지는 길이 없었기 때문입니다. 개발팀은 결국 셋 사이에 일일이 커스텀 API 연동을 깔았는데, 에이전트가 하나 늘 때마다 연결선이 기하급수로 늘어나는 구조였습니다. 네 번째 에이전트를 붙이려다 일정이 두 달 밀렸습니다.

이 광경은 사실 2010년대 초 기업들이 겪던 시스템 통합(EAI) 문제와 판박이입니다. 각 부서가 좋은 도구를 따로 도입할수록 사일로는 깊어졌고, 그 사일로를 잇는 비용이 도구 자체보다 커졌죠. AI 에이전트의 시대에도 똑같은 함정이 재현되고 있었습니다. 에이전트가 똑똑해질수록, 서로 말이 안 통하는 비용이 더 비싸지는 역설입니다. A2A 프로토콜은 바로 이 지점을 겨냥해 등장했습니다.

A2A 프로토콜이란 무엇인가요

한 줄로 요약하면, A2A(Agent2Agent)는 서로 다르게 만들어진 AI 에이전트들이 공통의 언어로 협업하도록 정한 개방형 규약입니다.

에이전트가 비즈니스 현장에 본격 투입되기 전, 시장의 통합 방식은 대체로 두 가지였습니다. 하나는 모든 에이전트를 한 벤더의 플랫폼 안에 가두는 방식이고, 다른 하나는 에이전트 쌍마다 일회성 연동을 짜는 방식이었는데요. 앞의 방식은 벤더 종속(lock-in)을 낳고, 뒤의 방식은 앞서 본 제조 유통 기업처럼 연결선 폭발을 부릅니다. 에이전트 n개를 전부 잇자면 최악의 경우 연결 관리가 n제곱으로 늘어나니, 규모가 커질수록 감당이 안 됩니다.

A2A는 이 비효율을 표준 한 겹으로 걷어냅니다. 2025년 4월 구글이 처음 공개했고, 같은 해 6월 리눅스 재단 산하의 벤더 중립 프로젝트로 기증됐습니다. 그 덕에 특정 회사의 로드맵에 휘둘리지 않는, 업계 공용 자산이 됐다는 점이 도입 결정에서 꽤 중요하게 작용합니다.

A2A의 정의에서 가장 핵심적인 단어는 불투명(opaque)입니다. 협업하는 두 에이전트는 상대의 내부 메모리·도구·프롬프트·구현 프레임워크를 들여다보지 않습니다. 서로가 무엇을 할 수 있는지(능력)와 어떻게 말을 걸면 되는지(인터페이스)만 공유하고, 나머지는 블랙박스로 둡니다. 덕분에 경쟁사 솔루션이라도, 보안 경계가 다른 조직의 에이전트라도, 내부를 노출하지 않은 채 일을 주고받을 수 있습니다. 협업과 기밀 유지를 동시에 잡으려는 설계인데요.

리눅스 재단에 따르면 2026년 1주년 시점에 A2A는 150개 이상의 조직이 참여하고 깃허브 스타 2만 2천 개를 넘겼습니다. v1.0 사양에서는 다중 프로토콜 지원, 엔터프라이즈급 멀티테넌시, 현대화된 보안 흐름, 그리고 암호학적 신원 검증을 위한 서명된 에이전트 카드가 추가됐습니다. 구글 클라우드의 라오 수라파네니 부사장은 "AI 에이전트는 협업하는 능력만큼만 유용하다"고 표현했는데, A2A가 풀려는 문제를 정확히 짚은 말입니다.

A2A는 어떻게 작동하나요: 에이전트 카드·태스크·아티팩트

A2A의 작동 원리는 다섯 가지 핵심 요소로 설명됩니다. 사람 사이의 협업에 빗대면 이해가 빠릅니다.

첫째, 에이전트 카드(Agent Card)입니다. 에이전트의 명함이자 자기소개서라고 보면 됩니다. 이름·능력·인증 요건·접속 정보를 담은 JSON 형식의 매니페스트인데요. 표준 위치인 /.well-known/agent.json 경로에 게시돼, 다른 에이전트가 이 카드를 읽고 "이 친구가 무슨 일을 할 수 있는지" 발견(discovery)합니다. v1.0부터는 이 카드에 디지털 서명을 붙여, 사칭이 아니라 진짜 그 에이전트가 맞는지 암호학적으로 검증할 수 있습니다.

둘째, 태스크(Task)입니다. 협업의 단위 작업입니다. "이 고객의 KYC를 확인해줘" 같은 요청이 하나의 태스크가 되고, 오래 걸리는 작업도 상태를 추적하며 진행됩니다. 셋째, 메시지(Message)는 한 번의 주고받는 대화이고, 넷째 파트(Part)는 그 안의 콘텐츠 조각, 다섯째 아티팩트(Artifact)는 작업의 결과물입니다. 텍스트·파일·구조화된 JSON 같은 산출물이 아티팩트로 전달되죠.

기술적으로 A2A는 HTTP(S) 위에서 JSON-RPC 2.0을 씁니다. 통신 방식은 상황에 따라 세 가지로 나뉩니다. 즉답이 필요하면 동기 요청·응답을, 진행 상황을 흘려보내야 하면 서버-전송 이벤트(SSE) 스트리밍을, 몇 시간씩 걸리는 작업이면 비동기 푸시 알림을 씁니다. 보안 측면에서는 표준 인증·인가 스킴을 따르며, 핵심 원칙대로 에이전트는 내부 상태·메모리·도구를 노출하지 않은 채 협업합니다. 파이썬·고·자바스크립트·자바·닷넷·러스트 SDK가 제공돼, 팀이 쓰던 언어로 바로 붙일 수 있습니다.

흐름을 한 번에 그려보면 이렇습니다. 영업 에이전트가 재고 에이전트의 카드를 발견하고 → 인증을 거쳐 → "이 품목 가용 수량 알려줘"라는 태스크를 보내고 → 재고 에이전트가 처리해 아티팩트로 결과를 돌려줍니다. 이 모든 과정에서 양쪽은 상대의 내부를 들여다 보지 않습니다. 앞서 본 제조 유통 기업이라면, 에이전트마다 커스텀 연동을 깔던 일을 카드 한 장 게시로 대체할 수 있었던 셈입니다.

A2A와 MCP는 무엇이 다른가요

이 질문이 도입 검토에서 가장 자주 나옵니다. 결론부터 말하면 둘은 경쟁 관계가 아니라 서로 다른 층을 맡는 보완 관계입니다.

MCP(Model Context Protocol)는 앤트로픽(Anthropic)이 주도해 표준화한, 에이전트 하나가 외부 도구·데이터에 연결되는 방식을 정한 규약입니다. 에이전트가 데이터베이스를 조회하거나 사내 API를 부를 때 쓰는 통로죠. 자주 인용되는 비유로 "MCP는 에이전트가 손을 쓰는 법, A2A는 두 에이전트가 악수하는 법"이 있습니다. MCP는 에이전트와 도구를 잇는 수직 통합(vertical)이고, A2A는 에이전트와 에이전트를 잇는 수평 협업(horizontal)이라는 표현도 같은 맥락입니다.

구분	MCP	A2A
표준화 대상	에이전트 ↔ 도구·데이터	에이전트 ↔ 에이전트
방향	수직 통합	수평 협업
구조	클라이언트-서버	피어 투 피어
비유	손을 쓰는 법	악수하는 법
주도	앤트로픽 → 리눅스 재단	구글 → 리눅스 재단

채택률을 보면 두 표준의 성숙도 차이가 드러납니다. 한 업계 집계에서 2026년 4월 기준 MCP는 기업 팀 채택률 78%, 게시된 서버 9,400개 이상으로 먼저 자리를 잡았고, A2A는 같은 시점 23%로 빠르게 뒤따르고 있습니다. 시점 차이를 감안하면 자연스러운 격차인데요. 중요한 건 진지한 에이전트 운영 환경은 둘 다 돌린다는 점입니다. 에이전트가 제 일을 하려면 MCP로 도구를 쓰고, 자기가 만들지 않은 다른 에이전트와 협력하려면 A2A로 손을 잡습니다. 실제로 많은 조직이 도구 연결은 MCP, 에이전트 조율은 A2A로 역할을 나눠 함께 씁니다.

어디에 쓰이나요: 산업별 활용 사례

A2A의 수직 채택은 공급망·금융·보험·IT 운영에서 두드러집니다. 기존 방식과 새 방식이 어떻게 갈리는지를 보면 가치가 분명해집니다.

금융 서비스가 가장 앞선 영역입니다. 한 사례에서는 거래 대사(reconciliation)·KYC·규제 보고를 담당하는 40개 이상의 A2A 에이전트가 내부 플랫폼에서 협업합니다. 기존에는 각 업무 시스템이 분리돼 야간 배치로 데이터를 넘기고 사람이 예외를 손으로 처리했다면, 이제는 대사 에이전트가 KYC 에이전트에게 직접 확인을 요청하고 결과를 받아 규제 보고 에이전트로 넘기는 식으로 흐름이 이어집니다. 결정 사이클이 짧아지고, 사람은 예외 판단에만 집중하게 되죠. A2A에는 결제를 다루는 확장 규약 AP2(Agent Payments Protocol)도 붙었는데, 60개 이상의 결제·금융 조직이 출범 파트너로 참여했습니다.

공급망에서는 수요 예측 에이전트, 재고 에이전트, 물류 에이전트가 벤더가 달라도 한 흐름으로 묶입니다. 앞서 본 제조 유통 기업이 겪던 단절이 바로 이 영역의 전형적 문제였죠. IT 운영(IT Ops)에서는 모니터링 에이전트가 이상을 감지해 진단 에이전트를 호출하고, 진단 결과를 복구 에이전트에 넘기는 자동 대응 사슬이 만들어집니다.

클라우드 차원의 지원도 활용을 뒷받침합니다. 마이크로소프트는 애저 AI 파운드리와 코파일럿 스튜디오에, AWS는 아마존 베드락 에이전트코어 런타임에 A2A를 내장했습니다. 한 시장 조사는 프로덕션급 오케스트레이션을 도입한 조직이 2026년 운영 비용 35~40% 절감과 의사결정 사이클 50% 단축을 보고했다고 전합니다. 가트너는 2026년 말까지 기업 애플리케이션의 40%가 AI 에이전트를 내장할 것으로 전망했는데, 2025년 5% 미만이던 데서 가파른 변화입니다. 다만 이 수치들은 표본과 정의에 따라 편차가 있으니, 자사 환경의 파일럿 측정값과 함께 보는 게 안전합니다.

기업 도입 4단계 실전 가이드

처음 검토하는 팀이 무리 없이 따라갈 수 있도록 네 단계로 정리했습니다.

1단계 — 협업이 필요한 경계를 찾습니다. 먼저 사내에서 에이전트(또는 자동화 시스템)가 이미 여럿 돌고 있고, 그 사이를 사람이 손으로 잇고 있는 지점을 지도로 그립니다. 앞서 본 "주문 수량 + 정산일을 한 번에" 같은 교차 업무가 첫 후보입니다. 한 곳을 골라 좁게 시작하는 것이 핵심입니다.

2단계 — 에이전트 카드부터 만듭니다. 협업시킬 에이전트 각각에 대해 능력·인증 요건·엔드포인트를 담은 에이전트 카드를 작성하고 /.well-known/agent.json에 게시합니다. 팀이 쓰는 언어의 SDK(파이썬·자바·자바스크립트 등)를 받아 서버·클라이언트 양쪽을 붙입니다. 이때 v1.0의 서명된 카드를 써서 신원 검증을 처음부터 켜두는 편이 나중에 보안 부채를 줄입니다.

3단계 — 한 쌍의 태스크 흐름을 검증합니다. 두 에이전트 사이에서 발견 → 인증 → 태스크 전송 → 아티팩트 수신까지 한 사이클을 실제로 돌려봅니다. 즉답이면 동기, 오래 걸리면 SSE나 푸시 알림으로 통신 방식을 맞춥니다. 이미 MCP로 도구를 쓰고 있다면 그대로 두고, 그 위에 A2A로 에이전트 간 연결만 얹으면 됩니다.

4단계 — 관측과 거버넌스를 붙여 확장합니다. 어떤 에이전트가 누구에게 무슨 태스크를 위임했는지 추적할 수 있도록 로깅·관측을 갖춥니다. 멀티테넌시와 인가 정책을 정한 뒤에야 에이전트 수를 늘립니다. 표준 덕분에 세 번째·네 번째 에이전트를 붙일 때 연결선이 폭발하지 않는다는 점이 이 단계에서 체감됩니다.

한 가지 덧붙이면, A2A는 만능 해법이 아닙니다. 에이전트가 한둘뿐이고 외부 협업 수요가 없다면 표준 도입은 과합니다. 여러 주체가, 여러 프레임워크로, 경계를 넘어 협업해야 할 때 비로소 값을 합니다.

FAQ

A2A 프로토콜은 도입 난이도가 높은가요?

표준 자체는 HTTP와 JSON-RPC라는 익숙한 기술 위에 서 있어 진입 장벽이 낮은 편입니다. 파이썬·자바·자바스크립트·고·닷넷·러스트 SDK가 제공되므로, 팀이 쓰던 언어로 에이전트 카드를 게시하고 태스크를 주고받는 최소 구성은 빠르게 만들 수 있습니다. 난이도는 프로토콜보다 멀티테넌시·인가·관측 같은 운영 거버넌스를 설계하는 데서 올라갑니다.

A2A를 쓰면 MCP는 필요 없나요?

아닙니다. 둘은 다른 계층을 맡습니다. MCP는 에이전트가 도구·데이터에 연결되는 통로이고, A2A는 에이전트끼리 협업하는 통로입니다. 실제 운영 환경은 보통 둘 다 씁니다. 에이전트가 제 일을 하려면 MCP를, 다른 에이전트와 손을 잡으려면 A2A를 쓰는 식으로 역할이 나뉩니다.

경쟁사가 만든 에이전트와 협업해도 내부가 노출되나요?

노출되지 않습니다. A2A의 핵심 설계 원칙이 불투명(opaque) 협업입니다. 협업하는 에이전트는 능력과 인터페이스만 공유하고, 상대의 내부 메모리·도구·프롬프트·구현은 들여다보지 않습니다. v1.0의 서명된 에이전트 카드로 상대 신원을 암호학적으로 검증할 수도 있어, 협업과 기밀 유지를 함께 가져갑니다.

상업적 프로젝트에 자유롭게 써도 되나요?

A2A는 리눅스 재단 산하의 벤더 중립 개방형 프로젝트입니다. 특정 회사 제품이 아니라 업계 공용 표준이라, 상업적 도입에 적합합니다. 구글·마이크로소프트·AWS가 자사 클라우드 서비스에 A2A를 내장했고 150개 이상 조직이 참여하고 있어, 프로덕션 채택의 토대가 비교적 탄탄합니다.

도입하면 실제로 시간이 얼마나 절감되나요?

환경에 따라 다르지만, 한 시장 조사는 프로덕션급 오케스트레이션을 갖춘 조직이 운영 비용 35~40% 절감과 의사결정 사이클 50% 단축을 보고했다고 전합니다. 다만 이 수치는 표본·정의에 따라 편차가 크므로, 도입 전후를 자사 파일럿에서 직접 측정한 값과 함께 판단하는 것을 권합니다.