2026년 구글 A2A 프로토콜: 채택 현황, 과열, 그리고 현실

A2A가 죽은 것은 아닙니다. 그저 범용적이지 않을 뿐입니다.

Page content

구글의 에이전트 간 상호 작용 프로토콜인 A2A(Agent2Agent)는 첫 해를 다소 혼란스럽게 보냈습니다.

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

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

Two AI agent systems connected by the A2A protocol bridge

A2A는 죽은 것이 아닙니다. 하지만 보편적으로 유용하다고도 할 수 없습니다. 현실적인 상황은 다음과 같습니다. A2A는 에이전트가 내부 함수나 도구 래퍼(wrapper)가 아닌, 자체 소유권, 도구, 신뢰 경계를 가진 독립적인 시스템일 때에만 진정한 가치를 발휘하고 있습니다. 도구 통합과 에이전트 위임 사이의 이 구분이 바로 이 프로토콜이 실제로 해결하려는 문제이며, 이를 이해하는 것이 양극단적인 과장(hype) 없이 A2A를 평가하는 열쇠입니다.

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

A2A는 Agent2Agent Protocol의 약자이며, 이 이름은 그 목적을 정확히 나타냅니다. 이는 서로 다른 프레임워크, 언어, 벤더 스택으로 구축될 수 있는 독립적인 AI 에이전트 시스템 간의 통신과 상호 운용성을 위한 오픈 표준입니다.

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

일반적인 A2A 흐름은 다음과 같은 단계들을 포함할 수 있습니다:

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

이 목록에서 중요한 단어는 “작업(task)“입니다. A2A는 단순히 다른 래퍼를 둔 함수 호출이 아닙니다. 이는 발견과 위임부터 실행, 상태 업데이트, 아티팩트 반환에 이르기까지 전체 과정을 다루기 위해 설계된 에이전트 협력을 위한 작업 라이프사이클 프로토콜입니다. 에이전트 카드, 작업 라이프사이클, 메시지, 파트(parts), 아티팩트 등 각 개념에 대한 심층적인 기술적 안내는 A2A 프로토콜이란 무엇인가? 에이전트 카드와 작업 설명을 참조하세요.

A2A가 조롱받기 쉬웠던 이유

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

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

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

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

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

이러한 회의론은 비합리적이지 않았으며, 여러 방향에서 동시에 제기되었습니다. A2A는 MCP와 중복되는 것처럼 보였습니다. 또한 구글에서 나왔다는 점은 일부 개발자들에게 장기적인 커밋에 대한 우려를 낳았습니다. 대부분의 팀들이 단일 에이전트 시스템의 기본 도구 접근, 프롬프트 인젝션, 관찰성(Observability), 비용 제어, 보안 문제조차 해결하지 못한 시기에 이 프로토콜이 등장했기 때문입니다.

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

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

그들은 더 나은 프롬프트, 더 나은 도구, 더 나은 권한, 더 나은 재시도 로직, 그리고 더 나은 로그를 필요로 했을 뿐입니다.

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

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

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

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

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

더 방어 가능한 비판은 A2A가 살아있기는 하지만, 그 유용한 범위가 과장(hype)이 시사하는 것보다 더 좁다는 점입니다.

A2A 대 MCP: 죽지 않던 혼란

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

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

간단히 말하면 다음과 같습니다:

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

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

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

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

MCP는 많은 것을 감쌀 수 있지만, 모든 것을 도구로 감싸는 것은 결국 나쁜 추상화(abstraction)가 됩니다. 어느 시점에서 전문 시스템은 자체적인 상태, 정책, 라이프사이클, 의사 결정 권한을 충분히 갖게 되며, 이를 도구로 모델링하는 것은 아키텍처를 단순화하기보다 오히려 흐릿하게 만듭니다. 이것이 바로 피어 에이전트를 도구 호출이 아닌 피어 에이전트로서 취급하기 시작하면 보상이 돌아오는 변곡점입니다. 실무에서 경계가 어디에 있는지 상세한 비교는 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는 유용해집니다.

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

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

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

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

조달 에이전트
법률 검토 에이전트
재무 에이전트
규정 준수 에이전트
시장 조사 에이전트
보고서 작성 에이전트

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

이런 종류의 시스템에 대해 A2A는 터무니없는 것이 아닙니다. 이는 합리적인 경계입니다.

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

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

A2A가 여전히 과장된 곳

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

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

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

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

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

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

A2A가 실수가 되는 경우는 다음과 같습니다:

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

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

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

A2A와 구글 문제

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

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

“이것이 3년 후에도仍然存在할까요?”

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

리눅스 재단 호스팅 이야기는 여기서 도움이 됩니다. A2A가 더 광범위한 오픈 거버넌스 환경의 일부가 됨으로써 구글의 내부 우선순위에 대한 의존도가 줄어듭니다.

이는 성공을 보장하지 않습니다. 오픈 거버넌스가 마법처럼 개발자 채택을 만들지는 않습니다. 그러나 이는 가장 큰 우려 사항 중 하나, 즉 A2A가 구글이 통제하는 전략적 수단에 불과하다는 우려를 줄입니다.

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

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

채택: 강력한 신호이지만 전부는 아닙니다

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

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

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

진정한 테스트: 프로덕션에서의 유지

개발자의 과장은 저렴하고, 프로덕션 유지 비용은 비쌉니다. 두 가지는 거의 비례하지 않으며, 이것이 바로 90일 유지 질문이 출시 주의 열정보다 더 중요한 이유입니다.

A2A는 팀이 다음과 같은 문제를 만나고도 계속 사용하는 것을 통해 자신을 증명할 것입니다:

인증 문제
권한 부여 문제
에이전트 신원 문제
디버깅 문제
작업 라이프사이클 모서리 사례(Edge cases)
스트리밍 실패
버전 호환성
벤더 차이
비용 놀람
보안 검토
감사 요구 사항
인간 승인 워크플로우

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

A2A는 존재할 합당한 이유가 있지만, 합당한 이유만으로는 프로덕션 복원력이 자동으로 전환되지는 않습니다. 프로토콜은 데모에서 배포로 가는 길에서 맞닥뜨리는 운영 현실을 살아남아야 합니다.

2026년 A2A에 대한 가장 좋은 신호는 사람들이 이에 대해 블로그 포스트를 작성한다는 것이 아닙니다. 가장 좋은 신호는 기업들이 실제 다중 에이전트 경계를 위해 이를 사용하기 시작한다는 것입니다.

가장 나쁜 신호는 개발자들이 데모에서만 이를 사용하면서 프로덕션 시스템이 커스텀 API와 큐로 되돌아갈 때일 것입니다.

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

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

하나의 에이전트가 다른 에이전트와 통신할 때 몇 가지 질문이 시급해집니다:

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

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

A2A는 에이전트 협력을 더 쉽게 만듭니다. 또한 신뢰가 깨질 수 있는 새로운 장소를 생성합니다.

예를 들어:

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

이것이 바로 진지한 A2A 시스템이 프로토콜 준수보다 더 많은 것이 필요한 이유입니다.

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

강력한 에이전트 신원
범위가 지정된 권한 부여
작업 수준 감사 로그
위임 추적
위험한 작업에 대한 인간 승인
아티팩트 계보(Provenance)
속도 제한
정책 강제
에이전트 경계를 넘어선 관찰성

A2A는 자체적으로 보안 아키텍처가 아닙니다. 이는 통신 프로토콜이며, 교차하는 모든 경계에서 신원, 권한 부여, 감사, 정책 강제에 대한 명시적인 결정이 내려진 내부에 배포되어야 합니다.

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

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

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

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

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

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

이는 흥미롭게 들리지만, 동시에 과장이 위험해질 수 있는 곳이기도 합니다.

오픈 에이전트 마켓플레이스는 에이전트 카드보다 더 많은 것이 필요합니다. 신원, 평판, 청구, 규정 준수, 샌드박싱, 책임, 버전 관리, 분쟁 해결이 필요합니다.

이러한 것들 없이 에이전트 마켓플레이스는 발생할 대기 중인 보안 사고가 됩니다.

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는 즉각적인 실용적인 가치를 제공하며, 오늘날 에이전트를 구축하는 대부분의 팀에게 올바른 시작점입니다.

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

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

A2A의 일반적인 실수

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

MCP와 A2A를 경쟁자로 취급하는 것. A2A가 존재하기 때문에 MCP가 시대에 뒤떨어진 것이 아니며, MCP가 존재하기 때문에 A2A가 불필요한 것이 아닙니다. 이들은 다른 구조적 문제를 다루며, 경쟁적인 대안이 아닌 보완적인 계층으로 가장 잘 작동합니다.

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

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

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

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

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

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

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

아니요.

“A2A는 죽었다"는 논쟁은 프로토콜이 MCP 모멘텀에 대한 구글 주도 대응처럼 보였던 초기 회의 단계에서 더 타당했습니다.

2026년, 그 논쟁은 약해졌습니다.

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

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

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

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

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

A2A는 다른 경계마다 커스텀 프로토콜 작업이 필요했을 협력에 공통 계약을 제공함으로써 그 자리를 차지합니다.

나의 의견 있는 관점

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

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

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

최종 결론

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

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

이는 특정 문제, 즉 독립적인 AI 에이전트 간의 통신을 위한 유용하고 아직 성숙 중인 프로토콜입니다.

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

다중 에이전트 엔터프라이즈 시스템, 에이전트 마켓플레이스, 벤더 중립 에이전트 네트워크, 또는 독립적으로 배포된 전문 에이전트 세트를 구축하고 있다면 A2A는 진지한 관심을 받을 가치가 있습니다.

2026년의 가장 좋은 프레임은 다음과 같은 것이 아닙니다:

A2A vs MCP

이는 다음과 같습니다:

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

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