💡 글의 핵심 3줄 요약

1. A2A(Agent-to-Agent)는 서로 다른 회사, 다른 프레임워크로 만든 AI 에이전트들이 표준화된 방식으로 협업하게 해주는 개방형 프로토콜입니다.
2. MCP가 에이전트와 도구를 잇는 '수직' 연결이라면 A2A는 에이전트와 에이전트를 잇는 '수평' 연결로, 두 프로토콜은 경쟁이 아니라 상호 보완 관계입니다.
3. Agent Card로 능력을 공개하고 Task 단위로 작업을 주고받는 구조 덕분에, 벤더 종속 없이 멀티 에이전트 시스템을 조립하는 시대가 열리고 있습니다.

A2A 프로토콜 완벽 가이드: AI 에이전트끼리 대화하는 표준의 등장

안녕하세요! 혹시 이런 상상 해보신 적 있으신가요? 내가 만든 일정 관리 에이전트가 항공사의 예약 에이전트와 직접 대화해서 출장 일정을 잡고, 그 결과를 회사의 경비 처리 에이전트에게 넘겨주는 그림 말입니다. 사람은 "다음 주 부산 출장 잡아줘" 한마디만 하면 끝나는 세상이죠.

그런데 이 그림이 현실이 되려면 한 가지 큰 문제를 넘어야 합니다. 각 에이전트가 서로 다른 회사에서, 서로 다른 프레임워크로, 서로 다른 모델 위에 만들어졌다는 점입니다. LangGraph로 만든 에이전트와 CrewAI로 만든 에이전트는 기본적으로 서로의 존재조차 모릅니다. 마치 카카오톡 사용자와 라인 사용자가 서로 메시지를 못 보내는 것과 비슷한 상황이죠. 오늘은 바로 이 문제를 풀기 위해 등장한 A2A 프로토콜, 즉 에이전트 상호운용성의 표준을 깊이 있게 파헤쳐 보겠습니다.

A2A 프로토콜이란 무엇인가: 에이전트 세계의 공용어

A2A(Agent-to-Agent) 프로토콜은 2025년 구글이 처음 공개하고, 이후 중립적인 거버넌스를 위해 리눅스 재단(Linux Foundation)에 기부된 개방형 프로토콜입니다. 이름 그대로 에이전트와 에이전트가 서로를 발견하고, 작업을 요청하고, 결과를 주고받는 방법을 표준화한 약속입니다. 출발부터 Salesforce, MongoDB, ServiceNow 같은 수십 개의 기술 기업이 파트너로 참여했고, 2026년 현재는 지원 조직이 150곳을 넘어서며 주요 클라우드 플랫폼에 속속 통합되고 있습니다.

기술적으로 보면 A2A는 완전히 새로운 발명품이 아닙니다. HTTP, JSON-RPC, SSE(Server-Sent Events)처럼 웹 개발자라면 이미 익숙한 기술 위에 얹혀 있습니다. 이 점이 굉장히 영리한 선택인데요, 새로운 전송 계층을 배울 필요 없이 기존 웹 인프라(인증, 로드 밸런싱, 모니터링)를 그대로 재활용할 수 있기 때문입니다. 임베디드 세계에서 새 버스 규격을 만드는 대신 검증된 I2C 위에 프로토콜을 얹는 것과 같은 실용주의라고 할까요.

A2A의 핵심 철학은 "에이전트를 불투명한(opaque) 존재로 대한다"는 것입니다. 상대 에이전트가 내부적으로 어떤 모델을 쓰는지, 어떤 메모리 구조를 갖는지 전혀 몰라도 됩니다. 오직 "무엇을 할 수 있는지"와 "어떻게 요청하는지"만 공개하면 협업이 성립합니다. 잘 설계된 API가 내부 구현을 숨기는 것과 정확히 같은 원리입니다.

A2A의 동작 원리: Agent Card와 Task 생명주기

그럼 실제로 에이전트들이 어떻게 서로를 찾고 일을 시키는지 들여다볼까요? A2A를 이해하는 열쇠는 두 가지 개념, Agent Card와 Task입니다.

Agent Card: 에이전트의 명함

모든 A2A 에이전트는 자신을 소개하는 JSON 문서, 즉 Agent Card를 공개합니다. 보통 잘 알려진 경로(/.well-known/agent.json 형태)에 놓이는데, 여기에는 에이전트의 이름, 설명, 제공하는 스킬 목록, 지원하는 입출력 형식, 인증 요구사항이 담깁니다. 사람으로 치면 명함이자 이력서인 셈이죠.

클라이언트 에이전트는 이 카드를 읽고 "아, 이 친구는 항공권 검색과 예약을 할 수 있고, OAuth 인증을 요구하는구나"를 파악한 뒤 대화를 시작합니다. 서비스 디스커버리 개념이 에이전트 세계로 넘어온 것이라고 보시면 이해가 빠릅니다.

Task: 작업의 단위이자 상태 머신

에이전트 간의 실제 협업은 Task라는 단위로 이루어집니다. 클라이언트가 Task를 생성해서 원격 에이전트에게 보내면, 그 Task는 제출됨(submitted), 작업 중(working), 입력 필요(input-required), 완료(completed) 같은 상태를 거치며 진행됩니다. 임베디드 개발자에게 익숙한 표현을 빌리면, 잘 정의된 상태 머신입니다.

여기서 눈여겨볼 부분은 A2A가 처음부터 '오래 걸리는 작업'을 염두에 두고 설계되었다는 점입니다. 에이전트가 하는 일은 몇 초 만에 끝나지 않는 경우가 많습니다. 자료를 조사하고, 외부 시스템을 호출하고, 때로는 사람의 승인을 기다려야 하죠. 그래서 A2A는 SSE 스트리밍으로 중간 진행 상황을 실시간으로 흘려보내고, 몇 시간짜리 작업은 푸시 알림 방식으로 완료를 통지하는 메커니즘까지 표준에 포함하고 있습니다. 결과물은 Artifact라는 형태로 반환되는데, 텍스트뿐 아니라 파일, 구조화된 데이터 등 다양한 형식을 담을 수 있습니다.

MCP와 A2A, 경쟁이 아니라 역할 분담입니다

여기까지 읽으신 분 중에는 "어, 이거 MCP랑 뭐가 다르지?"라는 의문이 드는 분이 분명 계실 겁니다. 좋은 질문입니다. 결론부터 말씀드리면 둘은 경쟁 관계가 아니라 서로 다른 층을 담당하는 보완 관계입니다.

MCP(Model Context Protocol)는 에이전트가 도구와 데이터에 접근하는 방법을 표준화합니다. 데이터베이스를 조회하고, 파일을 읽고, API를 호출하는 '수직적' 연결이죠. 도구는 요청을 받으면 정해진 동작을 수행하고 결과를 돌려주는 수동적인 존재입니다. 반면 A2A는 자율적인 판단 능력을 가진 에이전트끼리의 '수평적' 협업을 표준화합니다. 상대는 단순한 함수가 아니라, 스스로 계획을 세우고 되물을 수도 있는 지능적인 주체입니다.

비유하자면 이렇습니다. MCP는 목수가 망치와 톱을 쓰는 방법이고, A2A는 목수가 전기 기술자, 배관공과 협업해서 집을 짓는 방법입니다. 실제로 2026년 엔터프라이즈 멀티 에이전트 아키텍처에서는 "도구 연결은 MCP, 에이전트 협업은 A2A"라는 2계층 구조가 사실상의 기본 패턴으로 자리 잡아가고 있습니다. 오케스트레이터 에이전트가 A2A로 전문 에이전트들에게 작업을 분배하고, 각 전문 에이전트는 MCP로 자신의 도구를 다루는 구조입니다.

개발자가 지금 챙겨야 할 것들: 기회와 현실적인 한계

그렇다면 우리는 이 흐름에 어떻게 올라타야 할까요? 먼저 기회의 측면을 보겠습니다.

가장 큰 변화는 에이전트가 '제품'이자 '서비스 단위'가 된다는 점입니다. 웹 시대에 REST API를 공개하는 것이 비즈니스의 기본이 되었듯, 에이전트 시대에는 Agent Card를 공개하는 것이 그 자리를 차지할 가능성이 높습니다. 사내에서도 마찬가지입니다. 팀마다 제각각인 에이전트들을 A2A로 묶으면, 부서 간 자동화 파이프라인을 표준 인터페이스로 조립할 수 있게 됩니다. 특정 프레임워크에 묶이는 벤더 종속을 피할 수 있다는 것도 큰 장점이고요.

다만 현실적인 한계도 짚어야 공정하겠죠. 첫째, 프로토콜 생태계가 아직 정리 중입니다. A2A 외에도 ACP, ANP 같은 대안 프로토콜이 존재하고, 표준 간 수렴이 진행되는 과도기입니다. 둘째, 보안 문제가 훨씬 복잡해집니다. 에이전트가 다른 에이전트를 신뢰하고 작업을 위임하는 순간, 인증과 권한 위임, 그리고 악의적인 에이전트가 끼어드는 시나리오까지 고민해야 합니다. 프롬프트 인젝션이 에이전트 네트워크를 타고 전파되는 상황을 상상해 보면 아찔하죠. 셋째, 디버깅과 관측가능성입니다. 여러 에이전트에 걸친 작업 흐름을 추적하려면 분산 시스템 수준의 트레이싱 체계가 필요합니다.

그래서 지금 시점의 현실적인 조언은 이렇습니다. 프로덕션 전면 도입보다는, 사내 에이전트 두어 개를 A2A로 연결해 보는 파일럿부터 시작하세요. 공식 스펙과 SDK가 오픈소스로 공개되어 있으니 주말 프로젝트로 Agent Card를 만들어 보는 것만으로도 감을 잡을 수 있습니다. 표준의 승자가 누가 되든, '에이전트 간 통신'이라는 설계 감각 자체는 앞으로 몇 년간 계속 값어치를 할 테니까요.

결론: 프로토콜이 생태계를 만든다

돌이켜보면 인터넷의 역사는 프로토콜의 역사였습니다. TCP/IP가 네트워크를 연결했고, HTTP가 웹을 열었고, SMTP가 이메일을 보편화했습니다. 지금 AI 에이전트 세계에서 벌어지는 표준화 경쟁은 그 다음 장을 쓰는 과정입니다.

A2A가 최종 승자가 될지 단언할 수는 없습니다. 하지만 리눅스 재단이라는 중립 거버넌스, 150개가 넘는 참여 조직, 그리고 MCP와의 명확한 역할 분담을 보면 가장 유력한 후보인 것은 분명합니다. 단일 에이전트의 성능 경쟁에서 에이전트 '팀'의 협업 경쟁으로 무게 중심이 옮겨가는 2026년, A2A 같은 상호운용성 프로토콜을 미리 이해해 두는 것은 개발자에게 좋은 투자가 될 것입니다. 다음 글에서는 실제로 두 에이전트를 A2A로 연결하는 실습을 다뤄보겠습니다. 여러분의 에이전트는 지금 누구와 대화하고 있나요?