2026년의 Google A2A 프로토콜: 채택, 과장된 기대, 그리고 현실

A2A는 사라진 것이 아닙니다. 다만 범용적으로 쓰이지 않을 뿐입니다.

Page content

구글의 에이전트 투 에이전트(Agent2Agent) 프로토콜, 즉 A2A는 첫해를 다소 혼란스럽게 보냈습니다.

2025년 4월 구글이 A2A를 발표했을 때, 그 메시지는 분명했습니다. 서로 다른 벤더, 프레임워크, 팀에 의해 구축된 AI 에이전트들이 소통할 수 있는 표준화된 방법이 필요하다는 것이었습니다. 이 프로토콜은 에이전트 발견, 작업 위임, 메시지 교환, 스트리밍 업데이트, 그리고 아티팩트(산출물) 공유를 약속했습니다. 그러나 반응은 발표만큼 매끄럽지 않았습니다.

일부 개발자들은 A2A를 부상 중인 에이전틱(에이전트 중심) 스택을 위해 누락되어 있던 에이전트 간 계층으로 보았습니다. 반면 다른 이들은 이것이 또 다른 구글 프로토콜, 또 다른 약어, 그리고 시장이 진정한 프로덕션 수요를 갖기 전에 시장을 정의하려는 또 다른 시도라고みました. 회의적인 시각은 단일 질문으로 귀결되었습니다. “우리는 이미 MCP(Model Context Protocol)를 가지고 있습니다. 왜 A2A가 필요한가요?” 2025년 당시에는 타당한 질문이었고, 2026년 현재에도 여전히 타당한 질문입니다. 다만 그 답은 상당히 달라졌습니다.

Two AI agent systems connected by the A2A protocol bridge

A2A는 죽은 것이 아닙니다. 하지만 동시에 만능 해결제도 아닙니다. 현실적인 상황은 A2A가 특정 맥락에서 진정한 가치를 얻고 있다는 것입니다. 즉, 에이전트가 단순한 내부 함수나 도구 래퍼(wrapper)가 아닌, 자체 소유권, 도구, 신뢰 경계를 가진 독립적인 시스템일 때입니다. 도구 통합과 에이전트 위임 사이의 이 구분이 바로 이 프로토콜이 해결하고자 하는 문제이며, 양극단적인 과장 없이 A2A를 평가하는 핵심은 바로 이를 이해하는 데 있습니다.

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

A2A는 Agent2Agent Protocol의 약자로, 그 이름 자체가 목적을 정확하게 포착하고 있습니다. 이는 독립적인 AI 에이전트 시스템 간의 통신과 상호 운용성을 위한 개방형 표준입니다. 구체적으로, 서로 다른 프레임워크, 언어, 벤더 스택을 사용하여 구축된 에이전트들 간의 통신을 의미합니다.

A2A의 주된 목적은 에이전트를 데이터베이스, 파일 시스템, 캘린더, API, 검색 인덱스에 연결하는 것이 아닙니다. 이는 MCP(Model Context Protocol)의 역할에 더 가깝습니다. A2A는 다른 것에 초점을 맞춥니다. 즉, 한 에이전트가 또 다른 에이전트와 통신하며, 피어(peer) 시스템을 수동적인 데이터 소스가 아닌 자체적인 기능을 가진 행위자(actor)로 취급하는 것입니다.

전형적인 A2A 흐름은 다음과 같은 단계를 포함할 수 있습니다:

에이전트 카드를 통한 에이전트 발견
에이전트의 스킬과 기능 확인
작업 전송
메시지 교환
상태 업데이트 수신
입력 필요 상태 처리
최종 아티팩트 수신
완료, 실패 또는 취소 추적

이 목록에서 중요한 단어는 “작업(task)“입니다. A2A는 단지 다른 래퍼를 단 함수 호출이 아닙니다. 이는 에이전트 협업을 위한 작업 라이프사이클 프로토콜로, 발견과 위임부터 실행, 상태 업데이트, 아티팩트 반환에 이르는 전체 과정을 처리하도록 설계되었습니다. 에이전트 카드, 작업 라이프사이클, 메시지, 파트, 아티팩트 등 각 개념에 대한 심층 기술적 안내는 A2A 프로토콜이란 무엇인가? 에이전트 카드와 작업 설명을 참조하세요. 프로덕션 환경에서 스트리밍, 푸시 알림, 인간 개입(HITL) 일시 정지가 어떻게 작동하는지에 대해서는 장기 실행 에이전트 워크플로우를 위한 A2A 스트리밍 및 비동기 작업을 확인하세요.

A2A가 조롱받는 이유

A2A는 이미 에이전트 약어로 물든 시장에 등장했습니다.

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

LLM API
함수 호출(Function calling)
도구 호출(Tool calling)
에이전트 프레임워크
MCP 서버
RAG 파이프라인
워크플로우 엔진
다중 에이전트 오케스트레이션 라이브러리
커스텀 JSON 프로토콜
내부 플러그인 시스템

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

“정말 또 다른 표준이 필요한가요?”

이 회의론은 비합리적인 것이 아니었고, 여러 방향에서 동시에 제기되었습니다. A2A는 MCP와 겹치는 것처럼 보였습니다. 또한 구글에서 나왔다는 점에서 일부 개발자들은 장기적인 커밋(commit)에 대해 우려했습니다. 대부분의 팀이 단 하나의 에이전트 시스템에 대한 기본 도구 접근, 프롬프트 인젝션, 관찰성(Observability), 비용 제어, 보안 문제를 해결하기도 전에 등장했습니다.

그런 환경에서 “에이전트 간 상호 운용성"은 야심차게 들렸지만, 동시에 다소 시기상조로 느껴졌습니다.

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

그들에게 필요한 것은 더 나은 프롬프트, 더 나은 도구, 더 나은 권한, 더 나은 재시도 로직, 그리고 더 나은 로그였습니다.

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

2026년의 가장 큰 변화는 A2A가 더 이상 구글의 발표에 불과하지 않다는 점입니다.

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

이것이 모든 주장을 맹목적으로 믿어야 한다는 의미는 아닙니다. “지원(Supported by)“하는 것과 “대부분의 개발자가 프로덕션에서 깊이 있게 사용한다"는 것은 다릅니다. 프로토콜 생태계는 일상적인 엔지니어링 작업에서 느끼는 것보다 보도자료에서 더 크게 보이는 경향이 있습니다.

그러나 이 신호는 무시하기 어렵습니다. A2A는 중요한 경계를 넘었습니다. 이제 이는 더 이상 구글의 블로그 포스트가 아닙니다. 공식 사양, 거버넌스 모멘텀, 공개된 예제, SDK 작업, 클라우드 플랫폼의 관심, 그리고 에이전트 상호 운용성 생태계가 성장하고 있습니다. 이는 “죽었다"는 라벨을 기술적이나 채택 측면에서 방어하기 어렵게 만듭니다.

더 방어력 있는 비판은 A2A가 살아있지만, 그 유용한 범위가 과장된 것보다 좁다는 점입니다.

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

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

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

간단히 말하면:

MCP는 에이전트를 도구와 연결합니다.
A2A는 에이전트를 다른 에이전트와 연결합니다.

이론적으로는 깔끔해 보이지만, 현실은 훨씬 더 혼란스럽습니다. MCP 서버는 매우 에이전트처럼 보이는 기능을 노출할 수 있습니다. 예를 들어, 내부적으로 검색, 검색, 요약, 랭킹, 보고서 작성을 실행하는 research_company라는 이름의 MCP 도구가 있을 수 있습니다. MCP 호스트의 관점에서 이것은 도구입니다. 그러나 아키텍처 관점에서 보면, 이는 함수 호출 경계 뒤에 에이전트 같은 워크플로우를 숨긴 것입니다. 이 모호함이 바로 일부 개발자들이 A2A가 불필요하다고 주장했던 이유입니다. 에이전트를 MCP 도구로 표현할 수 있다면, 왜 별도의 프로토콜을 만들 필요성이 있을까요?

답은 A2A가 MCP가 어색하게 다루는 것들에 일급(first-class) 구조를 제공한다는 점입니다:

에이전트 발견
에이전트 기능
작업 라이프사이클
장기 실행 작업
다중 턴(task) 작업 상태
에이전트 간 메시징
아티팩트
불투명한 에이전트 간의 협업
조직 경계를 넘은 위임

MCP는 많은 것을 감쌀 수 있지만, 모든 것을 도구로 감싸면 결국 나쁜 추상화가 됩니다. 어느 시점에서는 전문 시스템이 자체적인 상태, 정책, 라이프사이클, 의사 결정 권한을 충분히 갖추게 되면, 이를 도구로 모델링하는 것이 아키텍처를 단순화하기보다 오히려 흐릿하게 만듭니다. 이때가 바로 피어 에이전트를 도구 호출이 아닌 동료 에이전트로 취급하기 시작해야 하는 전환점입니다. 실제 경계가 어디에 있는지 상세한 비교는 A2A 대 MCP: AI 에이전트가 정말 두 프로토콜이 모두 필요한가?을 참조하세요.

가장 좋은 정신적 모델: 아래는 MCP, 위는 A2A

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

가장 깔끔한 아키텍처는 계층적입니다:

flowchart TD U["User or application"] O["Primary assistant / orchestrator"] S1["Specialist agent A"] S2["Specialist agent B"] T1["Tools, APIs, files, databases"] T2["More tools and data sources"] U --> O O -->|A2A| S1 O -->|A2A| S2 S1 -->|MCP| T1 S2 -->|MCP| T2

이 모델에서:

A2A는 에이전트 협업 계층입니다.
MCP는 도구 통합 계층입니다.

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

A2A가 실제로 유용한 곳

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

에이전트가 다음과 같은 경우 유용합니다:

독립적으로 배포됨
다른 팀에 의해 소유됨
다른 프레임워크로 구축됨
벤더에 의해 노출됨
자체 도구 및 권한으로 실행됨
장기 실행 작업에 대한 책임이 있음
단순한 값이 아닌 아티팩트를 반환함
광범위한 다중 에이전트 워크플로우의 일부임

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

이 작업은 다음과 같은 에이전트에게 위임할 수 있습니다:

조달 에이전트
법적 검토 에이전트
재무 에이전트
준수(Compliance) 에이전트
시장 조사 에이전트
보고서 작성 에이전트

각 에이전트는 자체 도메인, 도구, 규칙, 권한, 감사 요구사항을 가집니다.

이러한 시스템에 대해 A2A는 터무니없지 않습니다. 이는 합리적인 경계입니다.

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

이것이 본질적인 차이점입니다. 도구 접근은 에이전트와 그 리소스 간의 수직적 연결인 반면, 도메인 위임은 각자 자체적인 권한과 책임의 경계를 가진 자율 에이전트 간의 수평적 인계입니다. 이러한 구성 요소(LLM, 메모리, 도구, 라우팅, 관찰성)가 어떻게 결합되는지에 대한 계층 모델은 AI 어시스턴트 아키텍처: LLM, 메모리, 도구, 라우팅, 관찰성에서 다루고 있습니다.

A2A가 여전히 과대평가된 곳

사람들이 A2A를 모든 AI 프로젝트에 필수적인 인프라로 제시할 때 A2A는 과대평가됩니다.

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

로컬 코딩 어시스턴트, 문서용 챗봇, 작은 내부 자동화 에이전트, 또는 소수의 도구를 호출하는 단일 워크플로우를 구축 중이라면 A2A는 아마도 불필요할 것입니다.

당신에게 필요한 것은 다음과 같을 것입니다:

MCP
좋은 도구 스키마
가드레일(Guardrails)
평가(Evaluation)
로깅
비용 제어
재시도 로직
더 나은 프롬프트
더 나은 검색(Retrieval)

완전한 에이전트 투 에이전트 프로토콜은 아마도 필요하지 않을 것입니다.

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

에이전트가 하나뿐일 때
모든 구성 요소가 하나의 코드베이스에 있을 때
워크플로우가 짧고 동기적일 때
에이전트 발견이 필요하지 않을 때
에이전트가 독립적인 작업 상태를 필요로 하지 않을 때
외부 에이전트 제공자가 없을 때
API나 큐가 더 단순할 때
팀이 추가적인 복잡성을 운영할 수 없을 때

프로토콜은 gratis(무료)가 아닙니다. 이는 개념, 실패 모드, 디버깅 오버헤드, 보안 문제, 운영 작업을 추가합니다.

많은 소규모 시스템에서 A2A를 채택하는 것은 아키텍처 코스프레(architecture cosplay)와 같습니다. 프로토콜을 가치 있게 만드는 실제 경계 문제 없이 분산 에이전트 시스템의 어휘를 차용하는 것입니다.

A2A와 구글 문제

A2A 회의론의 일부는 구글 자체에서 비롯됩니다.

개발자들은 기억이 오래갑니다. 구글이 플랫폼, 프로토콜, 제품, 또는 생태계를 출시하면 많은 엔지니어는 즉시 다음과 같이 묻습니다:

“이것은 3년 후에도 존재할까요?”

이 반응은 A2A 기술 설계에 대해 완전히 공평하지는 않지만, 실제 채택 요인입니다.

리눅스 재단의 호스팅 이야기는 여기서 도움이 됩니다. A2A가 더 광범위한 개방형 거버넌스 환경의 일부가 됨으로써 구글의 내부 우선순위에 덜 의존하게 됩니다.

이것이 성공을 보장하지는 않습니다. 개방형 거버넌스가 마법처럼 개발자 채택을 만들어내는 것은 아닙니다. 그러나 이는 가장 큰 우려 사항 중 하나를 줄입니다. 즉, A2A가 구글이 통제하는 전략적 움직임에 불과하다는 우려를 줄입니다.

2026년, A2A를 “구글의 프로토콜"로서보다 구글이 시작에 기여한 부상 중인 에이전트 상호 운용성 표준으로서 판단해야 합니다.

이는 더 건강한 렌즈이며, 이를 통해 A2A의 기술적 장점을 구글의 개발자 생태계와의 역사적 관계를 거치는 필터가 아닌, 그 자체로 평가하기 더 쉬워집니다.

채택: 강력한 신호이지만 전체 이야기가 아님

보고된 150개 이상의 지원 조직 수는 의미 있지만, 이는 보편적인 개발자 채택과 혼동해서는 안 됩니다. “지원"은 이진법이 아닌 스펙트럼이며, 이를 염두에 두고 채택 주장을 읽는 것이 도움이 됩니다.

가장 약한 끝은 로고 채택입니다. 회사가 표준을 지원한다고 선언하는 것으로, 이는 진정한 구현, 전략적 포지셔닝, 프로토타입, 또는 아직 실현되지 않은 계획된 지원을 반영할 수 있습니다. 약간 더 강력한 것은 SDK 채택으로, 개발자가 이용 가능한 라이브러리, 예제, 문서로 실제로 빌드할 수 있는 것을 의미합니다. 이는 프로토콜이 슬라이드웨어에서 작동하는 구현으로 넘어갔으며, 실제 엔지니어가 시간을 투자할 가치가 있다고 판단했음을 의미합니다. 더 강력한 것은 플랫폼 채택으로, 클라우드, 에이전트 프레임워크, 엔터프라이즈 시스템이 실제 네이티브 지원을 노출하여 A2A가 팀이 직접 연결해야 하는 것이 아니라 합리적인 기본 아키텍처 선택이 되는 것입니다.

장기적인 생태계 건강에 있어 실제로 중요한 채택 계층은 프로덕션 유지(Retention)입니다. AI 에이전트 공간에서 실제 채택 곡선이 어떻게 보이는지(GitHub 스타, OpenRouter 토큰, 다운로드 추이 측정)에 대한 감을 잡기 위해 OpenClaw 대 Hermes 에이전트 인기 데이터를 참조하세요. 이는 초기 채택자 에너지가 가라앉은 후 모멘텀이 얼마나 빠르게 구축되고 평탄해지는지를 보여줍니다. 초기 90일 간의 허니문 기간을 넘어 라이브 워크플로우에 프로토콜을 의존하는 팀들. 리눅스 재단의 2026년 업데이트는 여러 산업 전반의 프로덕션 사용을 주장하며, 이는 의미 있는 증거입니다. 그러나 더 유용한 질문은 “누가 A2A를 지원하나요?“가 아니라 “첫 번째 실제 운영 사고 후 프로덕션에 A2A를 계속 유지하는 사람은 누구인가요?“입니다. 압력 하에서의 장기적인 유지가 진정한 인프라와 프로토콜 극장(protocol theater)을 구분하는 신호입니다.

진정한 시험: 프로덕션에서의 유지

개발자의 과장은 싸고, 프로덕션 유지 비용은 비쌉니다. 이 둘은 드물게 비례하기 때문에 90일 유지 질문이 출시 주의의 열정보다 더 중요합니다.

A2A는 팀이 다음을 마주친 후에도 계속 사용한다면 자신을 증명하게 될 것입니다:

인증(Authentication) 문제
인가(Authorization) 문제
에이전트 아이덴티티(Identity) 문제
디버깅 문제
작업 라이프사이클 엣지 케이스
스트리밍 실패
버전 호환성
벤더 차이
비용 놀라움
보안 검토
감사 요구사항
인간 승인 워크플로우

여기에서 많은 에이전트 프레임워크와 프로토콜이 실패합니다. 다이어그램에서는 우아해 보이지만 프로덕션에서는 고통스러워집니다.

A2A에는 존재할 좋은 이유가 있습니다. 그러나 좋은 이유는 자동으로 프로덕션 복원력으로 이어지지 않습니다. 프로토콜은 데모에서 배포로 이동하는 동안 마주치는 운영 현실을 살아남아야 합니다.

2026년 A2A에 대한 가장 좋은 신호는 사람들이 이에 대해 블로그 글을 쓰고 있다는 것이 아닙니다. 가장 좋은 신호는 기업들이 진정한 다중 에이전트 경계를 위해 이를 사용하기 시작한다는 것입니다.

가장 나쁜 신호는 개발자가 데모에서만 사용하면서 프로덕션 시스템이 커스텀 API와 큐로 후퇴하는 것입니다.

보안이 가장 해결되지 않은 문제입니다

A2A의 가장 어려운 문제는 구문이나 사양 문제가 아닙니다. 이는 조직 또는 시스템 경계를 넘어 자율 에이전트를 실제로 배포할 때 발생하는 신뢰 문제입니다.

한 에이전트가 다른 에이전트와 대화할 때, 몇 가지 질문이 시급해집니다:

이 에이전트는 누구인가요?
누가 소유했나요?
무엇을 알 수 있나요?
무엇을 할 수 있나요?
작업을 더 위임할 수 있나요?
사용자를 대신하여 도구를 호출할 수 있나요?
사용자 의도를 보존할 수 있나요?
어떤 일이 있었는지 증명할 수 있나요?
작업 완료 후 감사할 수 있나요?

이러한 질문은 엔터프라이즈 환경에서는 선택 사항이 아닙니다.

A2A는 에이전트 협업을 용이하게 합니다. 동시에 신뢰가 깨질 수 있는 새로운 장소를 만듭니다.

예를 들어:

악의적인 에이전트가 기능을 잘못 표현할 수 있습니다.
손상된 에이전트가 민감한 컨텍스트를 요청할 수 있습니다.
위임된 작업이 사용자의 권한을 초과할 수 있습니다.
에이전트가 오염된 아티팩트를 반환할 수 있습니다.
에이전트 체인이 책임 소재를 불분명하게 만들 수 있습니다.
민감한 데이터가 적절한 로깅 없이 경계를 가로질러 흐를 수 있습니다.

이것이 진지한 A2A 시스템이 프로토콜 준수 이상의 것이 필요한 이유입니다.

그들은 다음이 필요합니다:

강력한 에이전트 아이덴티티
범위 지정 인가
작업 수준 감사 로그
위임 추적
위험한 작업에 대한 인간 승인
아티팩트 계보(Provenance)
속도 제한
정책 강제
에이전트 경계를 가로지르는 관찰성

A2A는 자체적으로 보안 아키텍처가 아닙니다. 이는 통신 프로토콜이며, 이를 건너는 모든 경계에서 아이덴티티, 인가, 감사, 정책 강제에 대한 명시적인 결정이 내려진 보안 아키텍처 내부에 배포되어야 합니다. A2A 및 MCP 에이전트 보안: 아이덴티티, 위임, 감사 추적은 이러한 주변 아키텍처를 상세히 설명합니다.

A2A와 에이전트 마켓플레이스 아이디어

장기적인 A2A 사용 사례 중 더 흥미로운 하나는 에이전트 마켓플레이스입니다.

에이전트가 에이전트 카드를 통해 기능을 광고할 수 있다면, 다른 에이전트나 플랫폼은 이를 발견하고 평가하며 작업을 보낼 수 있습니다.

이는 에이전트 기능이 더 모듈화되는 가능한 미래를 만듭니다:

세금 에이전트
법률 에이전트
코드 리뷰 에이전트
여행 계획 에이전트
보안 분석 에이전트
조달 에이전트
데이터 품질 에이전트

각각은 작업 기반 협업을 위한 표준 인터페이스를 노출할 수 있습니다.

이는 들을 때 exciting하지만, 동시에 과장이 위험해질 수 있는 곳이기도 합니다.

개방형 에이전트 마켓플레이스에는 에이전트 카드 이상이 필요합니다. 아이덴티티, 평판, 청구, 준수, 샌드박싱, 책임, 버전 관리, 분쟁 해결이 필요합니다.

이러한 것들 없이 에이전트 마켓플레이스는 발생할 준비가 된 보안 사고가 됩니다.

A2A는 이러한 미래에 대한 유용한 빌딩 블록이지만, 안전한 시장으로 운영되기 위해서는 아이덴티티 시스템, 평판 메커니즘, 청구 인프라, 준수 제어, 분쟁 해결을 필요로 하는 더 큰 퍼즐의 한 조각에 불과합니다.

내부 엔터프라이즈 에이전트를 위한 A2A

더 현실적인 단기 사용 사례는 공개 에이전트 마켓플레이스가 아닙니다.

그것은 내부 엔터프라이즈 에이전트 네트워크입니다.

대규모 조직은 이미 많은 경계를 가지고 있습니다:

팀
부서
시스템
벤더
데이터 도메인
준수 존
보안 정책
승인 프로세스

A2A는 동일한 근본적인 필요, 즉 자체 소유권을 가지고 있고 코드베이스를 공유하지 않는 시스템 간의 구조화된 통신을 중심으로 설계되었기 때문에 이러한 경계에 자연스럽게 매핑됩니다. AI 시스템 클러스터는 Hermes와 OpenClaw와 같은 전문 에이전트가 실제로 이러한 계층 아키텍처에 어떻게 통합되는지를 다룹니다.

모든 것에 직접 접근 권한을 가진 거대한 어시스턴트 하나를 구축하는 대신, 기업은 제한된 책임을 가진 전문 에이전트를 구축할 수 있습니다:

HR 에이전트
재무 에이전트
지원 에이전트
DevOps 에이전트
보안 에이전트
지식 관리 에이전트
데이터 플랫폼 에이전트

각 에이전트는 내부에서 자체 도구와 정책을 소유할 수 있습니다. 다른 에이전트는 A2A를 통해 이를와 상호 작용할 수 있습니다.

이는 보안 관점과 운영 관점 모두에서 조직의 모든 시스템에 단일 범용 에이전트의 직접 접근을 허용하는 것보다 훨씬 더 나은 모델입니다. 각 전문 에이전트는 독립적으로 소유, 운영, 감사, 보안될 수 있으며, 이는 문제가 발생 시 전체 시스템을 더 쉽게 추론할 수 있게 만듭니다.

소규모 팀과 인디 해커를 위한 A2A

하나 또는 두 개의 에이전트로 제품을 구축하는 소규모 팀에게 A2A는 진정으로 덜 시급하며, 종종 더 즉각적인 문제로부터의 산만함입니다. 아직 에이전트 투 에이전트 프로토콜이 필요하지 않을 것입니다.

일반적인 코드를 사용하세요. HTTP API를 사용하세요. 큐를 사용하세요. 도구 통합이 중요한 곳에서 MCP를 사용하세요.

다음과 같은 상황이 실제로 있을 때 A2A를 추가하세요:

여러 독립적인 에이전트
제3자 에이전트 경계
장기 실행 위임 작업
에이전트 발견 요구사항
아티팩트 교환 요구사항
크로스 프레임워크 상호 운용성 필요

순서가 야망보다 중요합니다. 실제 압력 지점을 노출하는 가장 단순한 아키텍처로 시작하고, 그 압력 지점이 A2A의 복잡성에 전념하기 전에 실제로 A2A가 필요한지 알려주도록 하세요. 대부분의 소규모 빌더에게 MCP 먼저, A2A 나중이 올바른 경로입니다.

실용적인 의사결정 프레임워크

시스템에 A2A가 필요한지 결정할 때 이 프레임워크를 사용하세요.

워크플로우가 로컬일 때 A2A를 사용하지 마세요. 모든 것이 하나의 애플리케이션 내부에서 실행되고 구성 요소가 독립적으로 배포되지 않을 때 A2A를 피하세요. Python 함수, 클래스, 서비스, 큐, 또는 워크플로우 엔진이 충분할 것입니다.

에이전트가 도구를 필요로 할 때 MCP를 사용하세요. 에이전트가 파일, 데이터베이스, API, SaaS 시스템, 검색 인덱스, 리포지토리, 내부 문서, 또는 관찰성 시스템에 대한 표준화된 접근이 필요할 때 MCP를 사용하세요. MCP는 즉각적인 실용적인 가치를 제공하며, 오늘날 에이전트를 구축하는 대부분의 팀에게 올바른 시작점입니다.

에이전트가 동료(Peer)를 필요로 할 때 A2A를 사용하세요. 에이전트가 다른 독립적인 에이전트와 통신해야 할 때 A2A를 사용하세요. 특히 이러한 에이전트가 자체 기능, 정책, 상태, 도구, 소유자, 배포 라이프사이클, 보안 경계를 가지고 있을 때.

아키텍처가 계층적일 때 둘 다 사용하세요. 전문 에이전트가 서로 협업하고 각 전문 에이전트가 도구도 필요할 때 둘 다 사용하세요. 프로덕션 패턴은 에이전트 간의 A2A와 에이전트와 도구 간의 MCP입니다. 이는 2026년 에이전트 프로토콜 스택의 가장 합리적인 버전이며, 프로덕션 다중 에이전트 시스템이 실제로 구축되는 방식에 가장 깔끔하게 매핑되는 아키텍처입니다.

A2A의 일반적인 실수

전략적으로 들리니까 A2A를 사용하는 것. 이는 고전적인 엔터프라이즈 아키텍처 함정입니다. A2A는 아키텍처에 존재하는 진정한 경계 문제를 해결해야 하며, 프로토콜 선택을 정당화하기 위해 발명된 문제가 아니어야 합니다. 진정한 경계가 없다면 — 독립 배포가 없고, 별도 소유가 없고, 독특한 보안 perímetro가 없다면 — A2A가 필요하지 않을 것입니다.

MCP와 A2A를 경쟁자로 취급하는 것. MCP는 A2A가 존재한다고 해서 구식이 아니며, A2A는 MCP가 존재한다고 해서 불필요하지 않습니다. 이들은 서로 다른 구조적 문제를 다루며, 경쟁하는 대안보다 보완적인 계층으로 가장 잘 작동합니다.

모든 기능을 에이전트로 노출하는 것. 계산기는 에이전트가 될 필요가 없습니다. 날씨 API는 에이전트가 될 필요가 없습니다. 데이터베이스 쿼리는 에이전트가 될 필요가 없습니다. 많은 것들이 직관적인 도구이며, 에이전트 추상화는 자체적인 의미 있는 자율성, 상태, 라이프사이클이 없는 구성 요소에 적용될 때 명확성을 추가하지 않고 오버헤드만 추가합니다.

하나의 도구 뒤에 완전한 에이전트를 숨기는 것. 반대 실수도 흔합니다. “도구"가 자체 작업 라이프사이클, 메모리, 정책, 아티팩트, 위임 동작을 가지고 있다면, 이는 함수 호출 경계 뒤에 쏙 들어가게 하는 것보다 에이전트로 모델링될 자격이 있을 수 있습니다.

관찰성(Ignoring observability)을 무시하는 것. 추적 없는 다중 에이전트 시스템은 디버깅이 고통스럽고 감사가 불가능합니다. 어느 에이전트가 작업을 받았는지, 어떤 메시지가 교환되었는지, 어떤 도구가 호출되었는지, 어떤 아티팩트가 생성되었는지, 어떤 정책이 적용되었는지, 어느 에이전트가 최종 결정을 내렸는지 알아야 합니다. 이러한 가시성 없이 디버깅은 고고학이 됩니다 — 관찰이 아닌 추론으로 어떤 일이 있었는지 재구성하는 것. 에이전트 경계를 가로지르는 지표, 분산 추적, SLO를 포함한 AI 및 LLM 기반 시스템의 전체 관찰성 스택은 LLM 시스템 관찰성: 프로덕션에서의 지표, 추적, 로그, 테스트에서 다루고 있습니다.

그렇다면 A2A는 과대평가된 것인가?

네, 부분적으로. A2A는 모든 AI 에이전트 시스템에 대한 불가피한 기본값으로 제시될 때, 모든 개발자가 즉시 채택해야 한다는 암시가 있을 때, 에이전트 데모가 세 번의 함수 호출로 가능했을 것을 A2A로 조정할 때, 또는 프로토콜 논의가 아이덴티티, 인가, 관찰성, 프로덕션 운영을 무시할 때 과대평가됩니다. 이는 A2A를 그보다 더 보편적으로 들리게 만드는 과장의 실제 예입니다.

그러나 과대평가되었다는 것은 쓸모없다는 의미가 아닙니다. 많은 중요한 기술은 지루한 인프라가 되기 전에 과대평가되며, 과장은 종종 생태계가 이를 지원할 만큼 성숙해지기 전에 찾아옵니다. 진정한 질문은 마케팅이 과도한지 여부 — 때로는 분명히 그렇습니다 —가 아닙니다. 진정한 질문은 근본적인 추상화가 유용한지 여부이며, A2A의 경우 에이전트가 진정한 경계, 진정한 소유권, 진정한 이해관계가 있는 시스템에서 진정한 독립적인 행위자가 될 때 답은 예입니다.

그렇다면 A2A는 죽은 것인가?

아니요.

“A2A는 죽었다"는 주장은 프로토콜이 MCP 모멘텀에 대한 구글 주도 응답처럼 보였던 초기 회의론 단계에서 더 의미가 있었습니다.

2026년, 그 주장은 약해졌습니다.

A2A는 공식 사양, 생태계 지원, 리눅스 재단 모멘텀, 주요 클라우드 관심, 보고된 프로덕션 배포를 가지고 있습니다.

이 중 어느 것도 A2A를 지배적이거나, 필수적이거나, 개발자 커뮤니티에 의해 보편적으로 사랑받는다고 만들지는 않습니다 — 그러나 분명히 죽은 것이 아닙니다. 더 나은 진술은 A2A가 살아있으며, 현재 대부분의 확인된 배포가 존재하는 엔터프라이즈 및 플랫폼 생태계를 넘어 프로덕션 가치를 입증하고 있다는 것입니다.

그렇다면 2026년 A2A는 마침내 유용한 것인가?

네, 하지만 올바른 아키텍처에서만. A2A는 시스템에 진정한 에이전트 경계가 있을 때 유용합니다 — 단순히 코드가 여러 프롬프트를 가지고 있거나, 시스템이 변수 이름에 “에이전트"라는 단어를 사용해서가 아닙니다. 에이전트 협업이 실제로 표준 구조를 필요로 할 때 유용해집니다:

발견
기능
작업 라이프사이클
메시지
아티팩트
장기 실행 작업
불투명한 구현 경계
크로스 벤더 상호 운용성

여기서 A2A는 그 자리를 earned합니다. 이는 각 경계에서 커스텀 프로토콜 작업이 필요했을 것인 협업을 위한 공통 계약을 제공함으로써.

저의 의견 있는 견해

대부분의 개발자가 시작해야 할 프로토콜은 A2A가 아닙니다 — MCP입니다. MCP는 더 즉각적이고 광범위하게 적용 가능한 문제를 해결합니다: 에이전트를 유용한 도구와 컨텍스트에 연결하는 것. A2A는 후기 단계의 문제를 해결합니다: 진정한 배포 및 소유 경계를 넘어 독립적인 에이전트를 서로 연결하는 것. 이는 MCP가 오늘날 대부분의 개별 개발자와 소규모 팀에게 더 유용하다는 것을 의미합니다.

에이전트 시스템이 데모에서 엔터프라이즈 워크플로우로 성숙함에 따라 A2A는 더 중요해질 수 있습니다. 조직이 서로 다른 팀에 의해 소유된 여러 전문 에이전트를 갖게 되면, 표준 에이전트 투 에이전트 경계의 필요성이 명확해지고 프로토콜의 오버헤드가 그 가치를 치르기 시작합니다.

저의 실용적인 권장 사항은 MCP로 시작하고,从一开始부터 깔끔한 에이전트 경계를 설계하며, 이러한 경계가 진정한 배포, 소유, 또는 상호 운용성 제약이 될 때만 A2A를 추가하는 것입니다. 분위기(vibes)를 위해 A2A를 채택하지 마세요. 아키텍처가 필요로 할 때 채택하세요.

최종 판단

구글의 A2A 프로토콜은 죽지 않았습니다.

또한 모든 AI 에이전트 프로젝트의 보편적인 미래도 아닙니다.

이는 특정 문제에 대한 유용하고 여전히 성숙 중인 프로토콜입니다: 독립적인 AI 에이전트 간의 통신.

간단한 어시스턴트를 구축 중이라면 A2A는 아마도 불필요할 것입니다.

다중 에이전트 엔터프라이즈 시스템, 에이전트 마켓플레이스, 벤더 중립 에이전트 네트워크, 또는 독립적으로 배포된 전문 에이전트 세트를 구축 중이라면 A2A는 진지한 주의가 필요합니다.

2026년의 최고의 프레임은 다음과 같지 않습니다:

A2A vs MCP

다음과 같습니다:

도구를 위한 MCP.
에이전트를 위한 A2A.
진지한 다중 에이전트 시스템을 위한 둘 다.

이는 프로토콜 전쟁 서사보다 덜 극적이지만, 실제 아키텍처 결정을 내려야 하는 엔지니어에게 더 정확하고 유용합니다.