AI 에이전트가 하나일 때는 문제가 없었다. 혼자 도구를 고르고, 혼자 판단하고, 혼자 결과를 낸다. 그런데 에이전트가 여러 개가 되면 이야기가 달라진다. 서로 뭘 할 수 있는지 모르고, 작업을 넘기는 방법도 제각각이다. A2A 프로토콜은 이 문제를 풀기 위해 나온 에이전트 간 통신 표준이다.
나는 2026년 들어 컨퍼런스나 밋업에 갈 때마다 느낀다. 어디를 가든 “에이전트”가 화두다. 작년까지만 해도 RAG가 키워드였는데, 올해는 완전히 에이전트의 시대로 넘어왔다. 그런데 에이전트가 많아질수록 정작 “에이전트끼리 어떻게 소통하지?”라는 질문이 빠져 있었다. A2A 프로토콜이 바로 그 답이다.
에이전트 시대가 온 이유
2025년 RAG, 2026년 에이전트
2025년은 RAG의 해였다. 검색 증강 생성이라는 기술 덕분에 AI가 외부 문서를 참조해 답변하는 구조가 보편화됐다. 기업마다 RAG 파이프라인을 구축했고, 청킹 전략과 벡터 데이터베이스가 개발자 사이에서 필수 키워드가 됐다.
2026년에 들어서면서 분위기가 바뀌었다. 컨퍼런스 세션 제목에 “에이전트”가 빠지면 어색할 정도다. AI 서비스들도 너나없이 에이전트를 내세운다. 단순히 질문에 답하는 수준을 넘어, 스스로 도구를 선택하고 작업을 수행하는 구조로 진화하고 있다. 딜로이트 2026 State of AI 보고서에 따르면 2027년까지 응답 기업의 74%가 AI 에이전트를 본격적으로 활용할 것으로 전망된다. 출처
에이전트는 챗봇이 아니다
에이전트라는 단어가 남용되고 있어서 구분이 필요하다. 챗봇은 사용자의 질문에 답변하는 대화형 인터페이스다. 입력이 들어오면 출력을 내보내고, 거기서 끝난다.
에이전트는 다르다. 목표를 받으면 그 목표를 달성하기 위해 여러 단계를 스스로 계획하고 실행한다. 필요하면 외부 도구를 호출하고, 중간 결과를 평가해서 다음 행동을 결정한다. “내일 서울 날씨 알려줘”에 답하는 건 챗봇이고, “내일 서울 출장 일정을 잡아줘”라는 목표를 받아서 날씨 확인, 회의실 예약, 이동 경로 검색까지 알아서 처리하는 게 에이전트다.
문제는 이런 에이전트가 하나만 있을 때는 괜찮지만, 여러 개가 동시에 돌아가면 생긴다. 회의실 예약 에이전트, 항공권 검색 에이전트, 일정 관리 에이전트가 각각 따로 존재한다고 가정하자. 이 셋이 협력해서 출장 일정을 짜려면 서로의 존재를 알아야 하고, 작업을 넘기는 규칙이 있어야 한다.
A2A 프로토콜이 채운 빈자리
MCP 이후 남은 문제
2024년 11월, 엔트로픽이 MCP(Model Context Protocol)를 발표했다. MCP는 AI 모델이 외부 도구와 데이터에 접근하는 방식을 표준화한 프로토콜이다. 데이터베이스 조회, 파일 읽기, API 호출 같은 작업을 일관된 인터페이스로 처리할 수 있게 됐다.
MCP가 해결한 건 “에이전트 → 도구” 연결이다. 그런데 “에이전트 → 에이전트” 연결은 여전히 비어 있었다. 세일즈포스 에이전트가 SAP 에이전트에게 작업을 넘기고 싶으면, 둘 사이에 맞춤 API를 따로 만들어야 했다. 새로운 에이전트 조합이 생길 때마다 새로운 커넥터가 필요했다. 이 방식으로는 확장이 불가능하다.
A2A가 하는 일
2025년 4월, 구글이 Google Cloud Next에서 A2A 프로토콜을 발표했다. A2A는 Agent-to-Agent의 약자로, 서로 다른 벤더가 만든 에이전트끼리 상대를 발견하고, 작업을 위임하고, 진행 상황을 주고받는 공통 규격이다. 출처
A2A 프로토콜의 핵심은 세 가지다. 첫째, 에이전트 발견이다. 각 에이전트는 자기가 뭘 할 수 있는지를 Agent Card라는 JSON 문서로 공개한다. 둘째, 작업 위임이다. 클라이언트 에이전트가 원격 에이전트에게 작업을 보내면, Task라는 단위로 관리된다. 셋째, 상태 추적이다. 작업이 접수됐는지, 진행 중인지, 추가 입력이 필요한지, 완료됐는지를 양쪽이 실시간으로 확인할 수 있다.
기술 스택도 특별한 게 아니다. HTTP, JSON-RPC 2.0, Server-Sent Events 같은 웹 표준을 그대로 쓴다. 새로운 전송 프로토콜을 배울 필요가 없다.
오케스트레이터와 A2A는 다르다
멀티에이전트 시스템을 이야기하면 오케스트레이터라는 개념이 자주 나온다. CrewAI나 LangGraph 같은 프레임워크가 대표적이다. 오케스트레이터는 에이전트에게 일을 시키는 상위 에이전트다. “너는 검색해, 너는 요약해, 너는 결과를 정리해”라고 지시하는 역할이다.
A2A는 그 시킬 때 쓰는 공통 통신 규격이다. 오케스트레이터가 하위 에이전트에게 작업을 보낼 때도 A2A를 쓸 수 있고, 오케스트레이터 없이 에이전트끼리 직접 협업할 때도 A2A로 대화한다. 역할이 다르다. 하나는 누가 뭘 할지 결정하는 것이고, 다른 하나는 그 결정을 전달하는 방식이다.
A2A 프로토콜의 핵심 구조
Agent Card
A2A 프로토콜에서 에이전트가 가장 먼저 하는 일은 자기소개다. Agent Card라는 JSON 문서를 /.well-known/agent.json 경로에 공개한다. 이 문서에는 에이전트의 이름, 설명, 보유 능력, 접속 주소, 인증 방식이 적혀 있다.
다른 에이전트는 이 카드를 읽고 “이 에이전트가 내 작업을 처리할 수 있겠다”고 판단한다. 사람으로 치면 명함이다. 다만 명함과 다른 점이 하나 있다. Agent Card는 기계가 읽는 문서이기 때문에 능력 명세가 구조화돼 있다. 어떤 입력을 받고, 어떤 출력을 내는지가 명확하게 정의된다.
Task와 Message
에이전트 간 실제 협업은 Task 단위로 진행된다. 클라이언트 에이전트가 원격 에이전트에게 작업을 보내면, 원격 에이전트가 Task를 생성한다. 이 Task에는 생명주기가 있다. submitted에서 시작해 working, input-required, completed, failed, canceled 중 하나로 끝난다.
중간에 추가 정보가 필요하면 input-required 상태로 전환된다. 클라이언트 에이전트가 추가 정보를 보내면 다시 working으로 돌아간다. 이 과정에서 주고받는 개별 통신 단위가 Message다. 각 Message에는 텍스트, 파일, 구조화된 데이터 같은 Part가 담긴다.
작업이 끝나면 결과물은 Artifact라는 형태로 돌아온다. 예약 확인서, 분석 보고서, JSON 데이터 등 에이전트가 만들어낸 산출물이다.
지금 어디까지 왔나
A2A 프로토콜은 2025년 4월 구글이 50개 이상의 파트너사와 함께 발표했다. 두 달 뒤인 6월, 구글은 A2A를 리눅스 재단에 기증했다. 중립적인 거버넌스 아래서 표준이 발전하도록 한 것이다. 출처
2025년 8월에는 IBM이 자체 에이전트 통신 프로토콜(ACP)을 A2A에 합류시켰다. 사실상 가장 큰 경쟁자가 스스로 합류한 셈이다. 2026년 4월 기준, A2A를 지지하는 조직은 150개를 넘었다. AWS, 마이크로소프트, 세일즈포스, SAP, ServiceNow 같은 기업이 포함된다. 금융, 물류, IT 운영 분야에서 실제 프로덕션 배포도 진행 중이다.
아직 초기 단계인 건 맞다. 하지만 1년 만에 리눅스 재단 이관, 경쟁 프로토콜 합류, 150개 조직 참여라는 속도를 고려하면, A2A 프로토콜이 에이전트 간 통신의 사실상 표준으로 정착할 가능성이 높다.
프로토콜이 생태계를 만든다
HTTP가 웹을 열었다. 웹 이전에도 네트워크는 있었지만, 누구나 같은 규칙으로 문서를 주고받을 수 있게 되면서 폭발적인 생태계가 만들어졌다. A2A 프로토콜도 같은 위치에 있다. 에이전트는 이미 많다. 부족한 건 에이전트끼리 말이 통하는 공통 언어였다.
MCP가 에이전트와 도구를 연결했다면, A2A 프로토콜은 에이전트와 에이전트를 연결한다. 이 두 프로토콜이 합쳐지면 에이전트가 도구도 쓰고, 다른 에이전트와 협업도 하는 완전한 구조가 된다. 2026년이 에이전트의 해라면, A2A는 그 해를 가능하게 하는 인프라다.