AI 에이전트 표준 규격 'A2A'란? ~ MCP와의 차이점까지

서론

생성 AI의 보급에 따라, 단일 LLM이 도구를 호출하는 챗봇 같은 사용 방식에서 여러 AI 에이전트가 협력하여 복잡한 업무를 수행하는 '멀티 에이전트'로의 전환이 빠르게 진행되고 있습니다.

이러한 가운데, Anthropic이 제안한 MCP (Model Context Protocol)가 에이전트와 외부 도구 연결 표준으로 사실상의 표준(de facto standard)이 되어가는 한편, Google이 표준화를 주도하는 오픈 규격 'A2A (Agent2Agent) Protocol'이 큰 주목을 받고 있습니다.

• '도구를 호출하는 MCP가 있는데, 왜 A2A가 필요한가?'
• '기존 API로는 어려웠던 '전체 위임(タスク委任)'이 가능한 이유가 무엇인가?'

본 기사에서는 이러한 의문을 중심으로 A2A의 핵심 사상, 기술 기반, MCP와의 역할 분담, 그리고 실제 사용 사례를 구체적인 예시와 함께 알기 쉽게 설명합니다.

결론부터 말하자면: A2A의 요점

• MCP는 에이전트의 '손발(도구)'을 표준화하지만, A2A는 에이전트의 '동료(전문가)'를 연결한다-
  MCP는 각자의 환경에서 DB, 파일, API를 안전하게 호출하기 위한 North-South 표준입니다.

• A2A는 서로 다른 모델, 서로 다른 조직, 서로 다른 프레임워크 간에 작업을 위임하는 East-West 표준입니다.

• 실제 작동하는 표준 웹 기술(HTTP/SSE)로 바로 구동 가능-
  특수한 전용 서버가 필요 없습니다. 사내에 있는 기존의 웹 서버나 인증 기반 시설(OAuth 등)을 사용하여 안전하고 빠르게 도입할 수 있습니다.

• 장시간 자율 작업과 중간의 '인간 확인' 대응 가능-
  단순한 질의응답이 아니라, 몇 분이 걸리는 조사에서도 통신이 끊기지 않습니다. 또한, 멋대로 오작동하지 않고 '여기까지 진행해도 될까요?'라고 인간에게 승인을 요청하는 안전장치가 표준으로 갖춰져 있습니다.

왜 에이전트 간의 통신 표준이 필요한가?

지금까지도 LangChain, AutoGen, CrewAI, LangGraph 등 멀티 에이전트 프레임워크들이 등장하며 에이전트 간의 협력이 시도되어 왔습니다. 하지만 이들에는 공통적인 구조적 한계가 있었습니다.

• 프레임워크의 강한 결합(密結合): 동일 리포지토리, 동일 언어(주로 Python), 동일 SDK로 구성된 에이전트끼리만 대화할 수 있습니다. -
• 조직 및 벤더의 장벽: 사내 에이전트가 외부 기업(Salesforce, Slack, 결제 SaaS 등)의 에이전트와 안전하게 대화하고 위임하는 통일된 규격이 존재하지 않았습니다.
• '손잡고 가르치기'의 한계: 기존 API를 호출할 경우, 호출하는 쪽이 모든 파라미터나 실행 절차를 프롬프트 상에서 고려해야 하므로, 상대방에게 '일을 통째로 맡기는 것'이 불가능했습니다.

이러한 '에이전트의 사일로화(Siloization)'와 '손잡고 가르치기 한계'를 극복하고, 웹에서의 HTTP처럼 '어떤 언어/기반/벤더로 만들어진 에이전트라도 서로 안전하게 일을 위임할 수 있는 공통 언어' 로 제정된 것이 A2A Protocol입니다.

A2A (Agent2Agent) Protocol의 핵심 사상

'도구 사용법을 지시하는 것'에서 '전문가에게 목적을 맡기는 것'으로

지금까지의 AI나 API 활용은 이른바 '도구를 사용하는' 감각이었습니다.

상대방은 수동적인 도구이기 때문에, 지시하는 쪽이 사용법 전체를 알고 있어야 움직일 수 있습니다.

이에 반해 A2A가 목표로 하는 것은 '전문가(동료)에게 일을 맡기는' 세계입니다.

상대 에이전트도 자신과 마찬가지로 '생각하는 두뇌(LLM)'를 가지고 있습니다. 그렇기 때문에, 세세한 API 절차를 지시하기보다는 '목적'을 전달하여 자율적으로 움직이게 하는 것입니다. 이것이 A2A의 근본적인 사상입니다.

기본 모델

A2A는 에이전트의 역할을 Client Agent와 Remote Agent, 두 가지로 단순하게 정의합니다.

• Client Agent: 사용자로부터 거시적인 요구를 받아 전문 능력을 가진 에이전트를 찾아 '목적/골'을 통째로 위임합니다. -
• Remote Agent: 자신의 전문성(스킬)을 외부에 공개하고, 위임받은 작업을 자율적으로 수행하며 진행 상황이나 결과물을 통지합니다.

A2A의 아키텍처: '전체 위임'을 가능하게 하는 3가지 메커니즘

사람 사이에서도 단순히 '대충 해놔'라고 방치하면 문제가 생기죠. 세세한 절차를 지시하지 않는 '전체 위임(丸投げ)'이 무너지지 않고 성립하기 위해서는, 서로가 지켜야 할 업무의 방식이 필요합니다.

A2A는 그 방식을 다음 3가지 기술적 기반으로 뒷받침하고 있습니다.

Agent Card

① 상대의 전문성을 아는 명함: 처음 만나는 사람과 업무를 할 때, 먼저 명함을 교환하며 '어떤 분야의 전문가인지'를 확인합니다. A2A 표준을 준수하는 에이전트도 웹 표준인 /.well-known/ 경로에 Agent Card라고 불리는 메타데이터 사양서(매니페스트)를 공개합니다.

• 배치 위치:
  https://<agent-domain>/.well-known/agent-card.json

이것은 인간에게는 '명함', 개발자에게는 '에이전트 버전 OpenAPI 사양서'입니다. Client Agent는 이 URL에 접속하는 것만으로 상대방의 능력을 파악할 수 있습니다.

② 장시간의 자율적 사고를 안심하고 기다리기: 통신 방식 (JSON-RPC 2.0 + SSE)

에이전트에게 업무를 맡기면, 상대방이 자율적으로 조사·비교·사고하기 때문에 완료까지 수 분 이상 걸릴 수 있습니다.

일반적인 웹 API(질문-답변형)의 경우, 요청을 보내고 수십 초 동안 기다리다가 중간 네트워크나 프록시가 '타임아웃 (504 Gateway Timeout)'으로 판단하여 통신을 끊어버립니다. 이 상태로는 '업무를 맡기고 기다리는 것'이 불가능합니다.

A2A는 다음 메커니즘으로 이 문제를 해결하고 있습니다:

• SSE (Server-Sent Events)를 이용한 비동기 스트리밍:
  ChatGPT의 답변이 화면에 실시간으로 흘러나오는 것과 같은 방식입니다. 연결을 유지한 채, 원격 에이전트가 '지금 여기까지 조사했습니다', '조금만 더 남았습니다'와 같이 실시간으로 진행 상황을 푸시 알림할 수 있습니다. -
  기존 웹 인프라(Nginx / ALB / OAuth)에서 즉시 작동:
  특수한 독자 서버를 준비할 필요가 없습니다. 사내에 있는 기존 리버스 프록시(AWS ALB나 Nginx)로 부하 분산이 가능하며, 기존 SSO/OAuth 인증 기반 시설(Okta나 Google Workspace 등)을 그대로 활용하여 안전하게 운영할 수 있습니다.

주요 4가지 RPC 메서드

③ 폭주를 막고 승인만 요청하기: 태스크 라이프사이클 (상태 관리)

업무를 맡길 수 있는 이유는 '멋대로 폭주하지 않고, 판단이 어려우면

（完了）: 승인을 얻어 작업을 완료하고, 티켓 등의 결과물을 납품한 상태

이 '중요한 국면에서는 반드시 멈춰서 확인한다'는 메커니즘이 처음부터 프로토콜에 내장되어 있기 때문에, 클라이언트는 안심하고 태스크를 맡길 수 있습니다.

MCP와 A2A의 결정적인 차이점

'에이전트 표준 규격'으로 함께 언급되는 MCP와 A2A가 있지만, 두 가지는 역할 자체가 근본적으로 다릅니다. 한마디로 말하면 '손발(도구)을 사용하는ための 규격'인지 아니면 '동료(전문가)에게 의지하는ための 규격'인지의 차이입니다.

비교 매트릭스

'North-South'의 MCP vs 'East-West'의 A2A

두 프로토콜의 관계를 가장 명확하게 표현하면, 아래 그림과 같습니다.

MCP는 에이전트의 '손발'을 만든다:
에이전트가 SQL을 실행하거나, GitHub PR을 읽거나, 로컬 파일을 검색하는 등 도구를 사용하는 사양입니다. 상대방은 수동적인 툴이기 때문에, 어떻게 사용할지는 호출하는 쪽이 모두 생각해야 합니다. -
A2A는 에이전트의 '동료'를 연결한다:
혼자 힘으로는 해결할 수 없는 태스크를 다른 조직이나 다른 기반에서 구동하는 다른 자율 에이전트에게 통째로 맡기기 위한 사양입니다.

두 가지는 경쟁 관계가 아니며, '원격 에이전트가 내부적으로 MCP를 사용해 툴을 작동시키고, 그 결과를 A2A를 통해 클라이언트 에이전트에게 보고한다'라는 완벽한 보완 관계에 있습니다.

유스케이스: A2A를 통한 태스크 위임의 실례

'A2A를 도입함으로써 시스템 설계나 운영은 어떻게 달라지는가?'

기업 사용 사례에서 현실적인 '사내 장애 대응 Agent × 외부 결제 SaaS Agent (B2B 연계)'를 소재로, 기존 방식과의 차이점을 살펴보겠습니다.

【기존】 A2A가 없을 때의 과제: 조직 경계와 수작업의 벽

자사 웹 서비스에서 '결제 오류가 다발하는' 실제 장애가 발생한 경우를 가정해 보겠습니다.

• 타사의 기밀 로그에는 접근할 수 없다:
  사내 장애 대응 Agent (Slack 봇)는 자사 서버의 로그는 조사할 수 있지만, 연결된 외부 결제 SaaS의 내부 로그나 DB를 직접 검색할 수는 없습니다 (타사의 보안상 API 키를 받을 리가 없기 때문에). - 수동 로그인과 복붙(Copy & Paste)에 의한 운영 분산:
  결국 엔지니어가 결제 SaaS의 웹 관리 화면에 2단계 인증으로 로그인하고, 오류 로그를 육안으로 검색하여, Slack에 수동으로 복사 붙여넣기 하여 사내 Agent가 읽게 하는... 식의 번거로운 작업이 발생했습니다.

【A2A 도입 후】 상대 에이전트에게 태스크를 위임하고 제로 트러스트 연계

결제 SaaS 측에서 자사의 '고객 지원 Agent'를 A2A로 공개하고 있다면, 사내 Agent는 '오류 원인 조사'라는 목적(Goal)을 상대방에게 위임하는 것만으로 충분합니다.

왜 A2A라면 태스크를 안전하게 위임할 수 있는가?

이 매끄러운 상호작용을 가능하게 하는 것이 A2A의 4가지 핵심 설계입니다:

• 상대방 스스로가 '생각하는 두뇌(LLM)'를 가지고 있다:
  수동적인 API와 달리, 상대방 (결제 SaaS Agent)이 자사 내부의 로그나 설정(MCP)을 자율적으로 조회하고 판단해 줍니다. - 지시가 '절차(How)'가 아닌 '목적(Goal)'이다:
  'API A를 작동시킨 다음 B를 작동시키고...'가 아니라, '오류 원인을 조사해 줘'라고 던지는 것만으로 충분하므로, 상대방의 복잡한 내부 사양을 외울 필요가 없습니다. - 곤란할 때 자발적으로 되물어볼 안전장치 (Input-Required)가 있다:
  제한 해제와 같은 파괴적인 조치는 멋대로 하지 않고, 도중에 안전하게 인간의 승인을 거칠 수 있습니다. - 장시간의 자율 조사를 기다릴 수 있는 비동기 스트리밍(SSE)이 있다:
  상대방이 사내 DB를 깊이 조사해서 몇 분 걸려도 연결이 타임아웃되지 않고 진행 상황을 모니터링하며 대기할 수 있습니다.

기존 방식과 A2A 도입 후의 비교

'상대방의 개인적인 사내 데이터에는 건드리지 않으면서, 상대방의 전문 지능(Agent)에게 태스크를 위임하고 결과만 받는다'. 이것이 A2A가 엔터프라이즈 영역에서 주목받는 가장 큰 이유입니다.

요약

A2A Protocol의 등장으로 AI 에이전트의 세계는 '단일 에이전트 최적화'에서 '멀티 에이전트 구축'이라는 새로운 단계에 진입하고 있습니다.

MCP(손발)와 A2A(동료) 두 프로토콜 모두의 책임 경계를 정확히 이해하고, 이를 조합하여 설계하는 능력이 요구될 것입니다.

논의