A2A, AI끼리 소통하는데 프로토콜까지 필요한가?

A2A 가 핫하다. “MCP 프로토콜이 단일 AI 에이전트의 시대를 열었다면, A2A는 멀티 에이전트 시대를 여는 새로운 프로토콜이다”라는 말도 나온다. 그런데 이런 궁금증이 든다.

 

AI 에이전트는 결국 우리가 흔히 쓰는 GPT 계열의 LLM 에 불과한데, 이런 AI끼리 소통하는데 거창하게 프로토콜까지 필요한가?

예를 한번 들어보자. 멀티 AI 에이전트의 소통은 이런 형태일 것이다. 에이전트 A 에 프롬프트를 넣으면 아웃풋이 나올 것이고, 그 아웃풋 프롬프트의 형태로 에이전트 B에 들어가서 최종 아웃풋이 나오는 형태이다. LLM 을 활용한 개발을 해 보았다면 공감할테지만, 사실 코드로 몇줄이면 구현 가능한 굉장히 간단한 로직이다. 그렇다면 이러한 단순한 프롬프트 입출력을 굳이 “A2A 라는 거창한 이름의 프로토콜”로 정의하려는 걸까?

 

혹시 비슷한 의문을 가져본 적이 있다면, 이번 기회에 같이 A2A의 진짜 의미를 짚어보자.

 

AI Agent 를 엮어서 서비스를 구축하다보면 다음과 같은 문제가 종종 발생한다.

 

🤔 AI Agent 마다 인풋/아웃풋 포맷이 제각각이다.

가장 단순한 경우, 에이전트 A가 에이전트 B에게 텍스트를 그대로 전달할 수 있다. 하지만 상황에 따라 JSON, XML, YAML, gRPC 등 다양한 형식을 사용할 수도 있다. 문제는 JSON이라 하더라도 내부의 키-값 구조가 제각각이라는 점이다. 실제로 ChatGPT, Gemini, Claude만 비교해도 입력과 응답의 JSON 포맷이 모두 다르다.

 

👉이를 위해 A2A 는 모든 인풋과 아웃풋 형식을 JSON 형태로 통일하고 (호환이 되는 gRPC도 가능), 그 스키마를 자체를 표준화했다. 또한 단순 텍스트 응답 뿐 아니라 이미지, 비디오 등 파일 입출력까지 포괄한다.

 

🤔 동시성(비동기, 스트리밍 등) 처리 방식도 제각각이다.

예를 들어, 어떤 에이전트는 ChatGPT 처럼 단어 단위의 스트리밍으로 실시간 출력되기를 기대한다. 반면 어떤 에이전트는 효율성을 위해 답변이 다 생성되고 출력되기를 기대한다. 또 다른 에이전트는 요청만 보내두고 다른 작업을 하다가, 완료 시점에 결과를 전달받는 비동기 방식을 선호한다. 문제는 이러한 처리 방식이 제각각이라 개발 과정에서 혼란을 일으킨다는 점이다.

 

👉이 문제를 해결하기 위해 A2A는 세 가지 응답 방식을 명확히 구분하고 프로토콜 차원에서 통일했다. 즉, 1) 실시간 스트리밍 (SSE 기반), 2) 단일 응답 (Synchronous Response), 3) 비동기 처리 (Webhook 기반) 의 세 가지 표준 모드를 정의하여, 에이전트 간의 동작 방식을 일관성 있게 보장한다.

 

🤔 단순 AI Agent 의 입출력 메시지 외에 더 상위 개념이 필요하다.

에이전트 A 가 에이전트 B 에게 보내는 “메시지” 만이 프로토콜로 정의됨을 넘어 더 상위 개념의 객체가 필요하다. 예를 들어, A와 B가 협력하여 달성하려는 상위 개념의 목표는 무엇인지, 그 과정에서 몇 번의 메시지가 오갔는지와 그 히스토리는 어떠한지, 현재 어떤 에이전트가 작업을 진행 중이고 어떤 작업이 끝났는지, 그리고 중간 산출물과 최종 결과는 무엇인지까지 등도 다뤄져야 한다.

 

👉이를 위해 A2A는 Message(에이전트 간 전달 단위)뿐 아니라 Task(통합 목표), Artifact(최종 산출물)과 같은 상위 개념 객체와 그에 맞는 프로토콜을 정의했다. 덕분에 멀티 에이전트 서비스를 구축할 때, 단순한 데이터 교환을 넘어 일관된 언어와 인터페이스로 전체 시스템을 설계할 수 있게 된다.

 

🤔 AI Agent 를 나만 쓰면 되는 것이 아니라 모두에게 배포하고 싶다.

huggingface 가 “AI 모델”을 공유하면서 시장의 주목을 받은 것처럼, 이제는 Agent 자체를 공유하는 시대가 다가오고 있다. 내가 만든 AI 에이전트를 누구나 사용할 수 있도록 엔드포인트를 열어 진열대에 올리고, 선택된 Agent들이 상호작용하며 멀티 에이전트 서비스를 구성하는 개념이다. 이 과정에서 반드시 필요한 것이 바로 설명서다. GitHub에 README가 있고, Hugging Face 모델에는 Model Card가 있듯, Agent에도 자신을 소개하고 설명할 수 있는 무언가가 필요하다.

 

👉A2A 는 이를 Agent Card 라는 개념으로 구성한다. JSON 형식으로 구성된 Agent Card 를 조회하여 이름, 설명, 버전, 배포 url 등 Agent 에 대한 기본 정보를 받아올 수 있다. 생태계가 확장되면, Agent Card 를 검색하고 발견하는 과정을 통해 동적으로도 Agent 들이 현결되고 협력할 수 있을 것이다.

 

🤔 AI Agent 를 배포 하고 싶은데 아무나 쓰게 하고 싶지는 않다.

LLM 이 막대한 컴퓨팅 자원을 먹고 현재 LLM provider 들이 과금 모델을 적용하고 있는 만큼 배포된 AI Agent 를 누구나 접근해서 쓰게 하는 것은 어려움이 있다. 그렇기에 인증과 권한 부여 절차가 필수적이다.

 

👉이를 위해 A2A는 Access Token 기반의 인증 절차를 프로토콜에 포함했다. 또한 인증 방식과 접근 조건은 Agent Card에 명시되어, 에이전트를 사용하는 쪽에서 사전에 확인하고 올바르게 연동할 수 있도록 한다.

 

 

정리해보자. A2A 를 보면 마치 구글이 이렇게 말 하는 것 같다.

 

“우리가 멀티 에이전트 기반의 서비스를 구축하면서 이런 어려움들을 겪었고, 그래서 이렇게 풀었어. 아마 너희도 만들다보면 비슷한 문제들이 있을거야. 그러니 우리꺼 따라해봐!”

 

A2A 기반으로 만들어진 구글의 ADK(Agent Development Kit) 도 같은 맥락이다. 에이전트 서비스를 엮어서 만들면서 겪을 문제들을 많은 부분 표준화 및 추상화를 해 둔 느낌이 든다. 굉장히 흥미로운 프레임워크다.

 

지금 시점의 A2A 기반의 멀티 에이전트 서비스 시장은 아직 태동 단계이다. 하지만 머지않은 미래에는 이런 시나리오가 펼쳐질 것이다. 마치 에이전트 허브(agent hub)처럼 다양한 AI 에이전트가 진열된 사이트에 접속해, 원하는 에이전트를 선택하고 몇 가지 설정만으로 손쉽게 멀티 에이전트 서비스를 조합하는 것이다. 마치 각 영역의 전문가를 모아 회사를 세우듯, 각 도메인의 전문 AI 에이전트를 조합해 새로운 가치를 창출하는 방식이다.

 

과거에 클래스와 모듈이라는 추상화된 블록의 조합이 현대 소프트웨어의 비약적인 발전을 이끌어낸 것처럼, 앞으로는 에이전트의 조합이 또 다른 혁신의 시대를 열어갈 것이다.

 

 

 

출처:

A2A: https://github.com/a2aproject/A2A

A2A Spec: https://a2a-protocol.org/latest/specification