A2A의 정체와 역할 경계

먼저 경계를 정해야 하는 이유

A2A를 이해할 때 가장 먼저 피해야 할 오해가 있다. A2A는 에이전트를 더 똑똑하게 만드는 모델 기술이 아니다. 에이전트 내부의 추론 방식을 정하는 프레임워크도 아니다. 사용자가 대화하는 챗봇 화면이나 업무용 메신저도 아니다.

A2A, 즉 Agent2Agent Protocol은 서로 다른 에이전트 애플리케이션이 서로를 발견하고, 일을 위임하고, 진행 상태를 주고받고, 결과를 공유하기 위한 공통 통신 규약이다. Google은 A2A를 기반 프레임워크나 벤더가 달라도 에이전트가 서로 협업할 수 있게 하는 개방형 프로토콜로 설명한다.¹

여기서 중요한 표현은 "에이전트 애플리케이션"이다. A2A가 연결하려는 대상은 단순 함수나 데이터베이스가 아니다. 자기 역할과 실행 능력을 가진 독립적인 에이전트다. 한 에이전트는 고객 문의를 분석하고, 다른 에이전트는 재고를 확인하며, 또 다른 에이전트는 환불 정책을 판단할 수 있다. A2A는 이들이 각자 따로 만들어졌더라도 하나의 업무 흐름 안에서 대화할 수 있게 해준다.

따라서 A2A를 제대로 쓰려면 "무엇을 표준화하는가"와 "무엇을 표준화하지 않는가"를 구분해야 한다. 이 경계가 흐려지면 A2A에 너무 많은 기대를 걸거나, 반대로 이미 필요한 곳에 쓰지 못한다.

AI 생성 이미지

A2A가 표준화하는 것

A2A의 핵심은 에이전트 간 협업의 바깥쪽 인터페이스를 맞추는 것이다. 내부 구현이 아니라 외부와 주고받는 약속을 정한다.

첫째, 에이전트는 자신이 누구이며 무엇을 할 수 있는지 알려야 한다. 이를 위해 A2A에서는 에이전트의 이름, 설명, 엔드포인트, 능력 같은 정보를 담은 Agent Card를 사용한다. 다른 에이전트는 이 정보를 보고 "이 요청을 누구에게 맡길 수 있는가"를 판단한다.²

둘째, 요청은 단순한 채팅 문장이 아니라 업무 단위로 전달되어야 한다. 예를 들어 "이 고객의 반품 가능 여부를 확인해줘"라는 요청에는 고객 식별자, 주문 정보, 필요한 출력 형식, 완료 시점, 추가 승인 필요 여부가 함께 붙을 수 있다. A2A는 이런 위임과 협업을 기계가 해석할 수 있는 구조로 주고받는 데 초점을 둔다.

셋째, 작업이 진행되는 동안 상태와 결과를 공유할 수 있어야 한다. 실제 업무는 즉시 끝나지 않는 경우가 많다. 재고 확인, 정책 검토, 결제 승인, 외부 시스템 조회처럼 시간이 걸리는 단계가 있다. A2A는 에이전트가 진행 상황, 중간 응답, 최종 산출물을 교환할 수 있는 통로를 제공한다.

이 세 가지를 합치면 A2A의 역할은 분명해진다. A2A는 에이전트 사이의 발견, 위임, 협업, 결과 공유를 위한 공통 언어다. 공통 언어가 있으면 각 팀이 다른 프레임워크로 에이전트를 만들더라도, 외부에서 보는 대화 방식은 일정하게 유지할 수 있다.

MCP와 A2A: 도구 연결과 에이전트 연결

A2A를 설명할 때 가장 자주 함께 등장하는 기술이 MCP다. MCP는 Model Context Protocol의 약자로, 모델이나 에이전트가 외부 도구와 데이터에 연결되는 방식을 표준화하려는 프로토콜이다. 쉽게 말해 MCP는 "에이전트가 무엇을 사용할 수 있는가"에 가깝다. 데이터베이스, 문서 저장소, 이메일, 사내 API, 분석 도구 같은 자원을 에이전트가 일관된 방식으로 호출하도록 돕는다.

반면 A2A는 "에이전트가 누구와 협업할 수 있는가"에 가깝다. 한 에이전트가 다른 전문 에이전트에게 일을 맡기고, 그 결과를 받아 다음 판단을 이어가게 한다. Google Cloud의 실무형 설명에서도 ADK 같은 프레임워크는 에이전트를 만들고, MCP는 에이전트를 도구와 데이터에 연결하며, A2A는 에이전트 간 협업 계층을 맡는 구조로 구분한다.³

간단한 예를 보자. 고객지원 에이전트가 "고객 A의 배송 지연 사유를 확인하고 보상 가능성을 판단하라"는 요청을 받았다.

• 고객지원 에이전트는 배송 전문 에이전트에게 A2A로 조사를 위임한다.

• 배송 전문 에이전트는 MCP를 통해 물류 데이터베이스와 운송사 API를 조회한다.

• 배송 전문 에이전트는 지연 원인과 예상 도착일을 A2A 응답으로 돌려준다.

• 고객지원 에이전트는 보상 정책 에이전트에게 다시 A2A로 판단을 요청할 수 있다.

이 흐름에서 MCP와 A2A는 경쟁하지 않는다. 서로 다른 층을 맡는다. MCP가 에이전트와 도구 사이의 연결을 담당한다면, A2A는 에이전트와 에이전트 사이의 연결을 담당한다. 기업 아키텍처에서는 둘을 함께 쓰는 경우가 자연스럽다.

프레임워크와 프로토콜은 다르다

LangGraph, CrewAI, Semantic Kernel, ADK 같은 도구는 에이전트 애플리케이션을 만들고 실행하는 데 쓰인다. 이들은 작업 흐름을 그래프로 구성하거나, 여러 역할을 가진 에이전트를 조율하거나, 모델 호출과 도구 호출을 관리한다. 즉 "에이전트를 어떻게 만들고 움직일 것인가"에 답한다.

A2A는 그 질문에 직접 답하지 않는다. A2A는 어떤 프레임워크를 써야 하는지 정하지 않는다. 내부 상태를 그래프로 관리할지, 역할 기반 팀으로 나눌지, 단일 루프 구조로 실행할지는 각 구현의 선택이다. A2A가 요구하는 것은 외부 에이전트가 이해할 수 있는 방식으로 자신을 소개하고, 요청을 받고, 상태와 결과를 반환하는 것이다.

이 차이는 실무에서 중요하다. 한 조직의 데이터 분석 에이전트는 LangGraph로 만들어질 수 있다. 다른 조직의 구매 에이전트는 Semantic Kernel 기반일 수 있다. 또 다른 팀은 Google의 ADK로 에이전트를 만들 수 있다. 이들이 직접 내부 구조를 맞출 필요는 없다. A2A 호환 인터페이스를 제공하면 서로 협업할 수 있다.

Google Cloud의 ADK 에이전트 변환 예시도 이 관점을 보여준다. 기존 ADK 에이전트의 내부 로직을 바꾸기보다, Agent Card와 실행 연결부를 덧붙여 A2A 호환 원격 에이전트로 노출하는 방식이다.⁴ 이는 A2A가 프레임워크의 대체물이 아니라 프레임워크 바깥의 통신 계층이라는 점을 잘 보여준다.

A2A는 메신저나 챗봇 UI가 아니다

또 하나의 오해는 A2A를 Slack 같은 메시징 앱으로 생각하는 것이다. 물론 A2A에서도 메시지라는 표현이 등장할 수 있다. 그러나 여기서 메시지는 사람이 읽기 좋은 대화창의 말풍선이 아니라, 에이전트가 처리할 수 있는 구조화된 요청과 응답에 가깝다.

Slack, Teams, 이메일 같은 도구는 주로 사람과 사람, 또는 사람과 봇 사이의 상호작용을 다룬다. 챗봇 UI도 사용자가 자연어로 질문하고 답을 받는 화면에 초점을 둔다. 반면 A2A는 자율 에이전트 간 기계 대 기계 프로토콜이다. 사람이 직접 읽는 화면을 예쁘게 구성하는 문제, 버튼과 폼을 렌더링하는 문제, 프론트엔드 이벤트를 스트리밍하는 문제는 A2A의 중심 관심사가 아니다. Google의 에이전트 프로토콜 안내에서도 A2A는 에이전트 간 발견과 통신에 초점을 두며, 사용자 인터페이스나 도구 연결과는 다른 범주의 프로토콜로 구분된다.⁵

물론 A2A 요청 안에 사용자 지시가 포함될 수는 있다. 예를 들어 "사용자가 프리미엄 고객인지 확인한 뒤, 환불 가능성을 판단하라"는 업무 지시가 전달될 수 있다. 그러나 A2A의 상대는 최종 사용자가 아니라 다른 에이전트다. 사용자가 보는 화면은 별도의 애플리케이션이나 UI 계층이 담당한다.

불투명 실행: 다 공개하지 않고도 협업하기

에이전트 협업에서 중요한 원칙 중 하나는 모든 내부를 공개하지 않아도 된다는 점이다. 이를 이 책에서는 불투명 실행이라고 부르겠다. 불투명 실행이란 한 에이전트가 자신의 내부 메모리, 프롬프트, 추론 과정, 독점 도구, 세부 정책을 상대에게 모두 보여주지 않고도 작업을 수행하고 결과를 반환하는 방식이다.

기업 환경에서는 이 원칙이 특히 중요하다. 재무 에이전트가 내부 승인 규칙을 모두 외부 에이전트에게 공개해서는 안 될 수 있다. 보안 에이전트는 위험 점수 산정 로직을 세부적으로 드러내지 않아야 할 수 있다. 구매 에이전트는 특정 공급사 평가 모델이나 가격 협상 전략을 숨겨야 할 수 있다.

A2A는 이런 상황에서 유용한 경계를 제공한다. 상대 에이전트는 "무엇을 요청할 수 있는지", "어떤 입력이 필요한지", "어떤 결과를 받을 수 있는지"를 알면 된다. 내부에서 어떤 모델을 쓰는지, 어떤 프롬프트를 거치는지, 어떤 사내 도구를 호출하는지는 반드시 알 필요가 없다.

이는 책임을 흐리는 방식이 아니다. 오히려 책임을 분명히 한다. 배송 에이전트는 배송 판단 결과에 책임지고, 보상 정책 에이전트는 보상 가능성 판단에 책임진다. 각 에이전트는 자신의 전문 영역을 캡슐화하고, A2A는 그 캡슐 사이의 협업 규칙을 맞춘다.

경계를 알면 설계가 단순해진다

A2A를 도입한다고 해서 모든 통합 문제가 사라지지는 않는다. 데이터 권한, 감사 로그, 모델 품질, 장애 처리, 사용자 승인, 비용 통제는 여전히 별도로 설계해야 한다. A2A는 이 모든 것을 대신하는 만능 플랫폼이 아니다.

그러나 A2A가 맡는 경계는 명확하고 실용적이다. 서로 다른 에이전트가 자신을 발견 가능하게 만들고, 작업을 위임받고, 진행 상태와 산출물을 교환하며, 내부 구현을 숨긴 채 협업할 수 있게 한다. MCP가 도구와 데이터의 문을 열고, 프레임워크가 에이전트의 내부 실행을 구성한다면, A2A는 에이전트들이 서로 일할 수 있는 공통 통로를 만든다.

이 경계를 이해하면 다음 질문으로 자연스럽게 넘어갈 수 있다. 좋은 에이전트 간 프로토콜은 어떤 원칙으로 설계되어야 하는가. 다음 장에서는 A2A의 설계 원칙을 통해 이 프로토콜이 왜 지금의 형태를 갖게 되었는지 살펴본다.

참고

¹Announcing the Agent2Agent Protocol (A2A)

²Developer's Guide to AI Agent Protocols

³Building Connected Agents with MCP and A2A

⁴A guide to converting ADK agents with MCP to the A2A framework

⁵Developer's Guide to AI Agent Protocols