2026년의 Google A2A 프로토콜: 도입, 과장, 그리고 현실

Google의 Agent2Agent 프로토콜(보통 A2A로 약칭)은 기묘한 첫 해를 보냈습니다.

Google이 2025년 4월 A2A를 발표했을 때, 그 취지는 명확했습니다. 서로 다른 벤더(vendor), 프레임워크(framework), 그리고 팀에 의해 구축된 AI 에이전트(AI agents)들이 소통할 수 있는 표준화된 방식이 필요하다는 것이었습니다. 이 프로토콜은 에이전트 발견(agent discovery), 작업 위임(task delegation), 메시지 교환(message exchange), 스트리밍 업데이트(streaming updates), 그리고 아티팩트 공유(artifact sharing)를 약속했습니다. 하지만 이에 대한 반응은 발표만큼 깔끔하지 않았습니다.

일부 개발자들은 A2A를 부상하는 에이전트 스택(agentic stack)을 위한 누락된 에이전트 간 계층(agent-to-agent layer)으로 보았습니다. 반면 다른 이들은 이를 또 다른 Google 프로토콜, 또 하나의 약어, 그리고 시장이 실제 운영상의 필요를 갖추기도 전에 시장을 정의하려는 또 다른 시도로 보았습니다. 회의적인 시각은 단 하나의 질문으로 귀결되었습니다: "우리는 이미 MCP가 있는데, 왜 A2A가 필요한가요?" 이는 2025년에는 타당한 질문이었고, 2026년에도 여전히 타당한 질문입니다. 다만 그 답변은 상당히 변화했습니다.

A2A가 사장된 것은 아니지만, 그렇다고 보편적으로 유용한 것도 아닙니다. 실질적인 현실은 A2A가 특정 맥락에서 진정으로 가치 있어지고 있다는 점입니다. 즉, 에이전트가 단순히 내부 함수나 도구 래퍼(tool wrappers)가 아니라, 자체적인 소유권, 도구, 그리고 신뢰 경계(trust boundaries)를 가진 독립적인 시스템인 경우입니다. 도구 통합(tool integration)과 에이전트 위임(agent delegation) 사이의 이러한 차이가 바로 이 프로토콜이 실제로 해결하도록 설계된 지점이며, 이를 이해하는 것이 양방향의 과장 없이 A2A를 평가하는 핵심입니다.

Google의 A2A 프로토콜이란 무엇인가?

A2A는 Agent2Agent Protocol의 약자이며, 그 이름은 목적을 정확히 담고 있습니다. 이는 독립적인 AI 에이전트 시스템 간의 통신과 상호 운용성(interoperability)을 위한 개방형 표준입니다. 구체적으로는 서로 다른 프레임워크, 언어, 또는 벤더 스택(vendor stacks)을 사용하여 구축될 수 있는 에이전트들을 대상으로 합니다.

A2A는 주로 에이전트를 데이터베이스, 파일 시스템, 캘린더, API 또는 검색 인덱스(search index)에 연결하는 것에 관한 것이 아닙니다. 그것은 MCP(Model Context Protocol)의 역할에 더 가깝습니다. A2A는 다른 무언가에 관한 것입니다. 즉, 한 에이전트가 다른 에이전트와 통신하며, 상대 시스템을 수동적인 데이터 소스가 아닌 자체적인 역량을 가진 액터(actor)로 취급하는 것입니다.

전형적인 A2A 흐름에는 다음과 같은 과정이 포함될 수 있습니다:

에이전트 카드(Agent Card)를 통한 에이전트 발견
에이전트의 기술(skills) 및 역량(capabilities) 읽기
작업(task) 전송
메시지 교환
상태 업데이트 수신
입력 필요(input-required) 상태 처리
최종 아티팩트(artifacts) 수신
완료, 실패 또는 취소 추적

이 목록에서 중요한 단어는 "작업(task)"입니다. A2A는 단순히 다른 래퍼(wrapper)를 씌운 함수 호출(function call)이 아닙니다. 이는 발견과 위임부터 실행, 상태 업데이트, 아티팩트 반환에 이르기까지 전체 아크(arc)를 처리하도록 설계된 에이전트 협업을 위한 작업 생명주기 프로토콜(task lifecycle protocol)입니다. 각 개념 — 에이전트 카드(Agent Cards), 작업 생명주기(task lifecycle), 메시지(messages), 파트(parts), 아티팩트(artifacts) — 에 대한 심층적인 기술적 설명을 보려면 What Is the A2A Protocol? Agent Cards and Tasks Explained를 참조하십시오.

A2A가 흉내 내기 쉬웠던 이유

A2A는 이미 에이전트 약어들이 넘쳐나는 시장에 등장했습니다.

2025년 무렵, 개발자들은 이미 다음과 같은 것들을 다루고 있었습니다:

LLM API
함수 호출 (Function calling)
도구 호출 (Tool calling)
에이전트 프레임워크 (Agent frameworks)
MCP 서버
RAG 파이프라인 (RAG pipelines)
워크플로 엔진 (Workflow engines)
멀티 에이전트 오케스트레이션 라이브러리 (Multi-agent orchestration libraries)
커스텀 JSON 프로토콜
내부 플러그인 시스템

따라서 Google이 A2A를 발표했을 때, 일반적인 반응은 예측 가능했습니다:

"정말로 또 다른 표준이 필요한가요?"

그러한 회의론은 비합리적인 것이 아니었으며, 여러 방향에서 동시에 터져 나왔습니다. A2A는 MCP와 중복되는 것처럼 보였습니다. 또한 Google에서 발표한 것이었기에, 일부 개발자들은 장기적인 지원 여부에 대해 우려했습니다. 대부분의 팀이 단일 에이전트 시스템 (single-agent systems)을 위한 기본적인 도구 접근 (tool access), 프롬프트 인젝션 (prompt injection), 관측 가능성 (observability), 비용 제어 (cost control), 그리고 보안 (security) 문제조차 해결하지 못한 시점에 A2A가 등장한 것이었습니다.

그러한 환경에서 "에이전트 간 상호운용성 (agent-to-agent interoperability)"은 야심 차게 들리면서도, 한편으로는 다소 시기상조처럼 느껴졌습니다.

그리고 솔직히 말해서, 2025년의 많은 AI 에이전트 데모들은 A2A가 전혀 필요하지 않았습니다.

그들에게 필요했던 것은 더 나은 프롬프트 (prompts), 더 나은 도구 (tools), 더 나은 권한 (permissions), 더 나은 재시도 로직 (retry logic), 그리고 더 나은 로그 (logs)였습니다.

2026년 업데이트: A2A는 죽지 않았다

2026년의 큰 변화는 A2A가 더 이상 단순한 Google의 발표에 그치지 않는다는 점입니다.

2026년 4월, Linux Foundation는 A2A 프로젝트가 150개 이상의 지원 조직을 확보했으며, 주요 클라우드 플랫폼 통합을 달성했고, 여러 산업 분야에서 프로덕션 배포 (production deployments) 단계에 도달했다고 보고했습니다.

그렇다고 해서 모든 주장을 의심 없이 그대로 받아들여야 한다는 뜻은 아닙니다. "지원됨 (Supported by)"이라는 말이 "대부분의 개발자에 의해 프로덕션에서 깊이 사용됨"과 같은 의미는 아닙니다. 프로토콜 생태계는 보도 자료에서 느껴지는 규모와 실제 일상적인 엔지니어링 작업에서 느껴지는 규모가 다른 경우가 많습니다.

하지만 이 신호는 무시하기 어려울 만큼 중요합니다. A2A는 중요한 선을 넘었습니다. 이제 이것은 단순한 Google의 블로그 포스트가 아닙니다. A2A는 공식 사양 (formal specification), 거버넌스 모멘텀 (governance momentum), 공개 사례, SDK 작업, 클라우드 플랫폼의 관심, 그리고 에이전트 상호운용성 (agent interoperability)을 중심으로 성장하는 생태계를 갖추고 있습니다. 이로 인해 기술적 또는 채택 (adoption) 관점에서 A2A가 "죽었다"라는 라벨을 유지하기는 어려워졌습니다.

더 방어 가능한 비판은 A2A가 살아있기는 하지만, 그 유용한 범위가 과장된 홍보만큼 넓지는 않다는 점입니다.

A2A vs MCP: 사라지지 않는 혼란

A2A에 대한 대부분의 혼란은 MCP와의 관계에서 비롯됩니다.

Anthropic이 만든 MCP는 AI 애플리케이션이 외부 도구 및 데이터 소스에 연결되는 방식을 표준화합니다. MCP 서버는 도구 (tools), 리소스 (resources), 프롬프트 (prompts)를 노출하며, AI 호스트 (hosts)와 클라이언트 (clients)가 이를 소비합니다.

간단히 말하자면:

MCP는 에이전트 (agents)를 도구 (tools)에 연결합니다.
A2A는 에이전트 (agents)를 다른 에이전트 (agents)에 연결합니다.

이론적으로는 깔끔하게 들리지만, 현실 세계는 훨씬 더 복잡합니다. MCP 서버는 매우 에이전트적인 (agentic) 무언가를 노출할 수 있습니다. 예를 들어, 내부적으로 검색, 검색 (retrieval), 요약 (summarization), 랭킹 (ranking), 보고서 작성을 수행하는 research_company라는 이름의 MCP 도구가 있다고 가정해 봅시다. MCP 호스트 (host)의 관점에서 이것은 도구입니다. 하지만 아키텍처 (architecture) 관점에서 보면, 이는 함수 호출 (function call) 경계 뒤에 에이전트와 유사한 워크플로 (workflow)를 숨기고 있는 것입니다. 이러한 모호함 때문에 일부 개발자들은 A2A가 불필요하다고 주장해 왔습니다. 에이전트를 MCP 도구로 표현할 수 있다면, 왜 별도의 프로토콜을 만들어야 하느냐는 것입니다.

그 답은 A2A가 MCP가 다소 어색하게 처리하는 요소들에 대해 일급 구조 (first-class structure)를 제공한다는 점에 있습니다:

에이전트 발견 (Agent discovery)
에이전트 역량 (Agent capabilities)
작업 생명주기 (Task lifecycle)
장기 실행 작업 (Long-running work)
멀티 턴 작업 상태 (Multi-turn task state)
에이전트 간 메시징 (Agent-to-agent messaging)
아티팩트 (Artifacts)
불투명한 에이전트 간의 협업 (Collaboration between opaque agents)
조직 경계를 넘나드는 위임 (Delegation across organizational boundaries)

MCP는 많은 것을 감쌀 수 있지만, 모든 것을 도구로 감싸는 것은 결국 나쁜 추상화 (bad abstraction)가 됩니다. 어느 시점에 이르면, 전문화된 시스템은 자체적인 상태 (state), 정책 (policy), 생명주기 (lifecycle), 그리고 의사결정 권한 (decision-making authority)을 충분히 갖게 되어, 이를 도구로 모델링하는 것이 아키텍처를 단순화하기보다는 오히려 가리는 결과를 초래합니다. 바로 이 변곡점이 동료 에이전트 (peer agent)를 도구 호출 (tool call)이 아닌 동료 에이전트로 취급하기 시작할 때 이점이 생기기 시작하는 지점입니다. 실제 경계가 어디에 위치하는지에 대한 자세한 비교는 A2A vs MCP: Do AI Agents Really Need Both Protocols?를 참조하세요.

가장 좋은 멘탈 모델: MCP는 아래에, A2A는 위에

가장 깔끔한 아키텍처는 "A2A vs MCP"가 아닙니다.

가장 깔끔한 아키텍처는 계층화된 구조입니다:

flowchart TD
    U["사용자 또는 애플리케이션"]
    O["기본 어시스턴트 / 오케스트레이터 (Orchestrator)"]
...

이 모델에서:

A2A는 에이전트 협업 계층 (Agent collaboration layer)입니다.
MCP는 도구 통합 계층 (Tool integration layer)입니다.

이것이 2026년에 가장 타당한 패턴이며, 대부분의 진지한 에이전트 아키텍트들이 수렴하고 있는 프레임워크입니다. A2A가 MCP를 대체해서는 안 되며, MCP가 모든 에이전트 경계를 나타내도록 강제되어서도 안 됩니다. 이들은 스택의 서로 다른 계층에서 서로 다른 문제를 해결합니다. "프로토콜 전쟁"이라는 프레임은 엔지니어가 더 나은 시스템을 설계하는 데 아무런 도움이 되지 않으면서, 자극적인 헤드라인을 만들기 위한 게으른 분석일 뿐입니다.

A2A가 실제로 유용한 경우

A2A는 에이전트가 더 이상 애플리케이션 내부의 단순한 라이브러리 호출 (Library call)이 아닐 때 유용해집니다.

에이전트가 다음과 같은 상황일 때 유용합니다:

독립적으로 배포됨 (Independently deployed)
서로 다른 팀에 의해 소유됨
서로 다른 프레임워크 (Framework)로 구축됨
벤더 (Vendor)에 의해 노출됨
자체적인 도구와 권한을 가지고 실행됨
장기 실행 작업 (Long-running tasks)을 담당함
단순한 값 대신 아티팩트 (Artifacts)를 반환함
더 넓은 멀티 에이전트 워크플로우 (Multi-agent workflow)의 일부임

예를 들어, 공급업체 리스크 보고서를 준비해야 하는 엔터프라이즈 어시스턴트를 상상해 보십시오.

이 어시스턴트는 다음과 같은 곳에 작업을 위임할 수 있습니다:

조달 에이전트 (Procurement agent)
법률 검토 에이전트 (Legal review agent)
재무 에이전트 (Finance agent)
컴플라이언스 에이전트 (Compliance agent)
시장 조사 에이전트 (Market research agent)
보고서 작성 에이전트 (Report writing agent)

각 에이전트는 고유한 도메인, 도구, 규칙, 권한 및 감사 요구 사항 (Audit requirements)을 가집니다.

그러한 종류의 시스템에서 A2A는 터무니없는 것이 아닙니다. 그것은 합리적인 경계입니다.

기본 어시스턴트가 모든 조달 데이터베이스, 법률 정책 저장소, 재무 스프레드시트 및 컴플라이언스 워크플로우에 직접 접근할 필요는 없습니다. 대신 해당 작업을 수행하도록 책임 있는 에이전트에게 요청해야 합니다.

그것이 핵심적인 차이점입니다. 도구 접근 (tool access)은 에이전트와 그 리소스 사이의 수직적 연결인 반면, 도메인 위임 (domain delegation)은 각각 고유한 권한과 책임의 경계를 가진 자율 에이전트들 사이의 수평적 인계입니다. 이러한 구성 요소들 — LLM, 메모리 (memory), 도구 (tooling), 라우팅 (routing), 그리고 관측성 (observability) — 이 어떻게 결합되는지에 대한 계층적 모델은 AI Assistant Architecture: LLM, Memory, Tools, Routing, Observability에서 다룹니다.

A2A가 여전히 과장된 부분

A2A는 사람들이 이를 모든 AI 프로젝트를 위한 필수 인프라로 제시할 때 과장됩니다.

대부분의 프로젝트에는 이것이 필요하지 않습니다.

만약 여러분이 로컬 코딩 어시스턴트, 문서용 챗봇, 소규모 내부 자동화 에이전트, 또는 몇 가지 도구를 호출하는 단일 워크플로우를 구축하고 있다면, A2A는 아마도 불필요할 것입니다.

여러분에게는 다음과 같은 것들이 필요할 수 있습니다:

MCP
우수한 도구 스키마 (tool schemas)
가드레일 (Guardrails)
평가 (Evaluation)
로깅 (Logging)
비용 제어 (Cost control)
재시도 로직 (Retry logic)
더 나은 프롬프트 (prompts)
더 나은 검색 (retrieval)

하지만 완전한 에이전트 간 프로토콜 (agent-to-agent protocol)은 아마도 필요하지 않을 것입니다.

A2A는 다음과 같은 경우에 실수가 될 수 있습니다:

에이전트가 단 하나뿐일 때
모든 구성 요소가 하나의 코드베이스에 존재할 때
워크플로우가 짧고 동기적(synchronous)일 때
에이전트에게 디스커버리 (discovery)가 필요 없을 때
에이전트에게 독립적인 작업 상태 (task state)가 필요 없을 때
외부 에이전트 제공자가 없을 때
API나 큐 (queue)를 사용하는 것이 더 간단할 때
팀이 추가적인 복잡성을 운영할 수 없을 때

프로토콜은 공짜가 아닙니다. 프로토콜은 개념, 실패 모드 (failure modes), 디버깅 오버헤드 (debugging overhead), 보안 문제, 그리고 운영 작업을 추가합니다.

많은 소규모 시스템에서 A2A를 채택하는 것은 아키텍처 코스프레 (architecture cosplay) — 즉, 프로토콜을 가치 있게 만드는 실제 경계 문제(boundary problems)는 전혀 겪지 않으면서 분산 에이전트 시스템의 어휘만 빌려오는 행위입니다.

A2A와 Google 문제

A2A에 대한 회의론의 일부는 Google 자체로부터 나옵니다.

개발자들의 기억력은 깁니다. Google이 플랫폼, 프로토콜, 제품 또는 생태계를 출시할 때, 많은 엔지니어들은 즉시 다음과 같이 질문합니다:

"이것이 3년 후에도 여전히 존재할까?"

그러한 반응이 A2A의 기술적 설계에 대해 전적으로 공정하다고 할 수는 없지만, 이는 실제 도입 과정에서의 중요한 요소입니다.

Linux Foundation이 호스팅한다는 사실이 여기서 도움이 됩니다. A2A가 더 넓은 오픈 거버넌스 (Open Governance) 환경의 일부가 된다는 것은 Google의 내부 우선순위에 대한 의존도를 낮춰준다는 것을 의미합니다.

그것이 성공을 보장하는 것은 아닙니다. 오픈 거버넌스가 마법처럼 개발자 도입을 만들어내는 것은 아닙니다. 하지만 가장 큰 우려 중 하나, 즉 A2A가 단지 Google이 통제하는 전략적 움직임일 뿐이라는 우려를 줄여줍니다.

2026년에 A2A는 "Google의 프로토콜"이라기보다, Google이 시작을 도운 신흥 에이전트 상호운용성 표준 (Agent Interoperability Standard)으로 평가받아야 합니다.

그것이 더 건강한 관점이며, Google과 개발자 생태계 사이의 역사적 관계라는 필터를 거치기보다 A2A의 기술적 장점을 그 자체의 조건으로 평가하기 쉽게 만드는 관점입니다.

도입 (Adoption): 강력한 신호, 그러나 전부가 아닌 이야기

보고된 150개 이상의 지원 조직은 의미가 있지만, 이를 보편적인 개발자 도입과 혼동해서는 안 됩니다. "지원됨 (Supported by)"은 이진법적인 것이 아니라 스펙트럼의 개념이며, 이러한 점을 염두에 두고 도입 관련 주장을 읽는 것이 도움이 됩니다.