여러 AI가 서로 일을 넘겨받는 시대…A2A 표준은 에이전트 협업을 어디까지 보장하나
서로 다른 AI 에이전트가 일을 나눠 맡는 구조는 빠르게 늘고 있지만, 표준이 생겼다고 곧바로 깊은 호환성이 확보되는 것은 아니다. 2026년 10월 16일 기준 공식 문서를 종합하면 A2A는 에이전트가 상대를 발견하고, 능력을 선언하고, 메시지·작업·결과물을 주고받는 공통 절차를 정하는 데 초점이 있다. 반면 실제 업무 협업의 품질을 가르는 메모리 공유, 내부 계획, 도구 연결, 권한 정책, 평가 체계까지 통일해 주는 규격은 아니다.
이 점은 A2A와 MCP의 역할 차이에서도 드러난다. Google은 2025년 4월 A2A를 발표하며 이를 에이전트 간 통신 규격으로 설명했고, MCP는 에이전트에 도구와 컨텍스트를 연결하는 별도 규격이라고 구분했다. 이후 Anthropic은 2025년 12월 MCP를 리눅스 재단 산하 Agentic AI Foundation에 기증한다고 발표했다. 두 규격은 경쟁 관계라기보다, 하나는 도구·데이터 연결, 다른 하나는 에이전트 간 상호작용을 맡는 보완 관계에 가깝다.
A2A가 실제로 표준화한 것
A2A 공식 명세가 보장하는 핵심은 공통 언어와 절차다. 에이전트는 상대의 능력을 확인할 수 있는 Agent Card를 제공해야 하고, 클라이언트는 이를 통해 지원 기능, 인증 방식, 접속 인터페이스를 파악한다. 규격은 메시지와 작업, 결과물인 아티팩트를 분리해 정의하며, 텍스트뿐 아니라 파일 참조와 구조화 데이터도 주고받을 수 있게 했다. 장시간 작업을 위한 스트리밍과 푸시 알림, 버전 협상을 위한 헤더, 확장을 위한 메커니즘도 명세에 포함돼 있다.
이 구조 덕분에 서로 다른 벤더나 프레임워크로 만든 에이전트라도 최소한의 발견·요청·응답 흐름을 맞출 수 있다. 현재 A2A 사이트의 최신 명세는 1.0 계열이며, 표준 바인딩으로 JSON-RPC, gRPC, HTTP+JSON/REST를 제시한다. 다시 말해 A2A는 에이전트 협업을 위한 배선 규격에 가깝고, 서로 무엇을 할 수 있는지와 어떤 형식으로 말할지에 대한 공통분모를 제공한다.
보장하지 않는 호환성도 분명하다
다만 공식 문서는 A2A가 상대 에이전트의 내부 상태, 메모리, 도구 구현에 접근하지 않아도 협업할 수 있게 설계됐다고 밝힌다. 이는 장점이면서 한계다. 상대의 내부 구조를 몰라도 연결할 수 있지만, 그만큼 깊은 수준의 공동 작업은 각 서비스가 추가로 맞춰야 한다는 뜻이기 때문이다.
예를 들어 한 에이전트가 만든 중간 산출물을 다른 에이전트가 정확히 해석하는지, 장기 문맥을 얼마나 이어받는지, 회사별 권한 모델과 감사 로그를 어떻게 맞출지, 실패했을 때 누가 재시도하고 책임을 지는지는 A2A만으로 자동 해결되지 않는다. 명세에는 보안과 인증·인가 원칙이 들어 있지만, 실제 자격증명 발급과 정책 집행은 각 구현이 맡는다. 확장 기능도 가능하지만, 확장을 썼다는 사실은 오히려 기본 규격만으로는 부족한 요구가 있다는 뜻이기도 하다.
같은 업체 안에서 여러 에이전트를 묶는 경우와 업체 간 A2A 연동의 차이도 여기서 생긴다. 같은 업체 제품군은 공용 메모리, 통합 관찰성, 단일 권한 체계, 내부 전용 API를 함께 설계할 수 있어 더 깊은 협업을 만들기 쉽다. 반면 A2A는 서로를 ‘불투명한 외부 시스템’으로 취급하는 방향에 가깝기 때문에, 업체 간 상호운용성은 넓게 열어 주되 깊이는 공통 최소치에 머무르는 경우가 많다. 이는 A2A가 실패했다는 뜻이 아니라, 애초에 해결하려는 문제가 ‘완전한 통합’이 아니라 ‘이질적 시스템 사이의 안전한 연결’이라는 뜻에 가깝다.
MCP와 함께 봐야 드러나는 실제 적용 범위
MCP는 도구, 리소스, 프롬프트를 AI 애플리케이션에 연결하는 규격으로 발전해 왔다. 공식 문서와 2026년 7월 규격 발표를 보면 최근 MCP는 무상태 코어, 장기 작업용 Tasks 확장, 공식 확장 프레임워크 같은 방향으로 바뀌고 있다. 이는 에이전트가 외부 시스템과 연결되는 기반을 넓히는 변화지만, 그래도 MCP가 곧바로 에이전트 간 협업 자체를 표준화하는 것은 아니다. A2A와 MCP를 함께 쓴다는 말은 한쪽이 도구 연결을, 다른 한쪽이 에이전트 간 통신을 맡는다는 뜻으로 읽는 편이 정확하다.
결국 기업 IT 책임자나 도입 담당자가 확인해야 할 질문은 단순히 ‘A2A를 지원하느냐’가 아니다. 첫째, 상대 에이전트의 능력을 Agent Card 수준에서만 알 수 있는지, 실제 업무 스키마까지 공유하는지 봐야 한다. 둘째, 장기 작업과 실패 복구, 푸시 알림, 버전 호환, 확장 의존성이 어디까지 필요한지 따져야 한다. 셋째, 도구 연결은 MCP나 다른 내부 규격으로 별도 관리되는지 확인해야 한다. 표준 채택 사실만으로 깊은 상호운용성을 추정하면, 데모 단계에서는 보이던 협업이 운영 단계에서 끊길 수 있다.
정리하면 A2A는 에이전트 협업을 ‘가능하게 하는 표준’이지, ‘실무에서 원하는 수준의 호환성을 자동 보증하는 표준’은 아니다. 같은 업체 내부의 촘촘한 멀티에이전트 체계를 곧바로 대체하기보다는, 서로 다른 시스템 사이에 공통 접속 규칙과 작업 전달 규격을 마련하는 층위에 더 가깝다. 따라서 A2A의 가치는 과장된 만능 호환성보다, 어디까지가 공통 규격이고 어디부터가 각사 구현 책임인지 경계를 분명히 해 준다는 데 있다.
자료: A2A Protocol, Agent2Agent (A2A) Protocol Specification v1.0.1(2026); Google Developers Blog, Announcing the Agent2Agent Protocol (A2A)(2025-04-09); Model Context Protocol, Server Features Overview(확인일 2026-10-16); Model Context Protocol Blog, The 2026-07-28 Specification(2026-07-28); Anthropic, Donating the Model Context Protocol and establishing the Agentic AI Foundation(2025-12-09)