Claude Code

AI 에이전트 프로토콜 완전 정리 — MCP, A2A, AG-UI 무엇을 언제 쓰나

AI 에이전트 생태계를 지탱하는 6가지 표준 프로토콜의 역할 차이와 선택 기준을 정리한다.

10 min read
MCPA2AAI AgentProtocolGoogle
AI 에이전트 프로토콜 완전 정리 — MCP, A2A, AG-UI 무엇을 언제 쓰나

MCP, A2A, UCP, AP2, A2UI, AG-UI. 용어가 쏟아지면서 AI 에이전트 개발을 시작하려는 사람들이 첫 화면에서부터 막힌다.

각각이 해결하는 문제가 다르다. 비유하면 HTTP, WebSocket, OAuth, GraphQL처럼 웹 개발에 프로토콜 레이어가 각자 역할을 분담하듯, AI 에이전트도 레이어별로 프로토콜이 나뉜다. Google Developers 블로그가 이 6종의 관계를 한 번에 정리해줬다.

한 줄 결론부터

상황별 선택 기준은 이렇다.

  • 에이전트에 외부 데이터·API 연결 → MCP
  • 에이전트끼리 통신A2A
  • 에이전트가 커머스 트랜잭션 처리 → UCP
  • 에이전트가 결제 승인AP2
  • 에이전트가 동적 UI 생성 → A2UI
  • 에이전트 ↔ 프론트엔드 스트리밍AG-UI

대부분의 프로젝트는 MCP로 시작하고, 복잡도가 올라가면 나머지를 붙인다.

왜 이 분류가 의미 있나

전통적인 API 통합과 AI 에이전트 통합의 차이를 먼저 이해해야 한다.

REST API는 사람이 설계한 엔드포인트에 사람이 정해진 형식으로 요청한다. AI 에이전트는 런타임에 스스로 어떤 도구를 어떻게 쓸지 결정한다. 이 차이 때문에 "에이전트끼리 어떻게 발견하고 대화하는가", "어떻게 신뢰하고 결제를 승인하는가" 같은 새로운 레이어가 필요해졌다.

프로토콜별 상세 정리

MCP — 데이터·도구 연결의 표준

Model Context Protocol. 에이전트가 외부 시스템에 접근하는 방식을 표준화한다.

PostgreSQL에서 재고 조회, Notion에서 문서 읽기, Mailgun으로 이메일 발송. 각각 다른 API를 써야 했던 작업을 하나의 패턴으로 통합한다.

MCP 기반 에이전트 예시
inventory_tools = ToolboxToolset(server_url=TOOLBOX_URL)
notion_tools = McpToolset(connection_params=notion_params)
mailgun_tools = McpToolset(connection_params=mailgun_params)
 
kitchen_agent = Agent(
    tools=[inventory_tools, notion_tools, mailgun_tools]
)

"수백 개의 서버에 단일 패턴으로 접근"이 핵심이다.

[💡 잠깐! 이 용어는?] MCP(Model Context Protocol): Anthropic이 제안한 오픈 표준. AI 모델과 외부 도구 사이의 공통 인터페이스 규격. USB-C처럼 "어떤 도구든 같은 방식으로 꽂는" 개념이다.

A2A — 에이전트 간 통신

Agent2Agent Protocol. 에이전트끼리 서로를 발견하고 대화하는 표준이다.

각 에이전트는 /.well-known/agent-card.json에 자신의 역량을 공개한다. 오케스트레이터 에이전트가 이 카드를 읽고 적절한 서브에이전트에게 작업을 라우팅한다.

A2A 에이전트 서비스 노출
# 가격 에이전트를 A2A 서비스로 변환
app = to_a2a(pricing_agent, port=8001)
 
# 오케스트레이터가 가격 에이전트에 연결
client = await ClientFactory.connect("http://pricing-agent:8001")

멀티에이전트 시스템에서 각 에이전트를 독립 서비스로 배포할 때 쓴다.

UCP / AP2 — 커머스와 결제

**Universal Commerce Protocol(UCP)**은 상품 카탈로그 조회부터 체크아웃까지, **Agent Payments Protocol(AP2)**은 결제 한도 설정과 승인까지 다룬다.

AP2는 에이전트가 자율적으로 결제를 집행하는 상황에서 감사 추적(audit trail)을 보장하기 위한 프로토콜이다.

AP2 프로토콜 흐름
IntentMandate (한도 설정)

PaymentMandate (서명된 승인)

PaymentReceipt (감사 추적 기록)

UCP 워크플로우 예시

UCP는 카탈로그 조회부터 체크아웃까지 다룬다. 표준화된 인터페이스로 쇼핑몰마다 다른 API를 통합한다.

UCP 기반 쇼핑 에이전트
catalog = UcpClient("https://wholesale.example.com/ucp")
 
products = await catalog.search(
    query="salmon fillet",
    filters={"grade": "A", "min_weight_lb": 10}
)
 
cart = await catalog.create_cart()
await cart.add_item(products[0].id, quantity=1)
checkout = await cart.checkout()

A2UI / AG-UI — UI와 스트리밍

A2UI는 에이전트가 동적으로 UI를 생성할 때 쓰는 18개 컴포넌트 기본요소 집합이다. Card, Column, Text, Button 등을 조합해 인터랙티브 위젯을 만든다.

AG-UI는 에이전트와 프론트엔드 사이의 실시간 스트리밍을 SSE 기반 표준 이벤트로 변환한다. TEXT_MESSAGE_CONTENT, TOOL_CALL_START 같은 이벤트가 일관된 형식으로 내려온다.

핵심 비교표

프로토콜무엇을 연결주요 기능가장 먼저 쓰는 시점
MCP에이전트 ↔ 데이터·도구API 통합 자동화프로젝트 첫 단계
A2A에이전트 ↔ 에이전트역량 발견·라우팅멀티에이전트 필요 시
UCP에이전트 ↔ 커머스 플랫폼주문·재고쇼핑 기능 필요 시
AP2에이전트 ↔ 결제 시스템승인·감사자율 결제 필요 시
A2UI에이전트 ↔ UI동적 컴포넌트복잡한 렌더링 필요 시
AG-UI에이전트 ↔ 프론트엔드실시간 스트리밍거의 모든 에이전트

실제 사용 흐름

Google 문서가 예시로 든 "주방 관리 에이전트"를 따라가 보면 전체 그림이 보인다.

"연어 재고를 확인하고, 오늘 도매가와 등급을 조회하며, 재고 부족이면 Example Wholesale에서 10파운드를 주문하고 결제를 승인해줘."

  1. MCP — 재고 DB, Notion 레시피, Mailgun 연결
  2. A2A — 가격 에이전트, 품질 에이전트와 통신
  3. UCP — 도매 플랫폼에 주문 생성
  4. AP2 — 결제 한도 확인 후 승인
  5. A2UI — 결과를 인터랙티브 위젯으로 구성
  6. AG-UI — 실시간 진행 상황 프론트엔드에 스트리밍

자주 나오는 오해

  • "MCP와 A2A는 중복이다" — 아니다. MCP는 에이전트 ↔ 도구, A2A는 에이전트 ↔ 에이전트. 레이어가 다르다.
  • "AG-UI는 그냥 SSE다" — 기술적으론 맞지만, 이벤트 스키마가 표준화돼서 프론트엔드 라이브러리 재사용성이 올라간다.
  • "AP2는 결제 대행사다" — 아니다. AP2는 승인 흐름의 표준이지 실제 결제를 처리하지 않는다. 결제는 Stripe·Toss 같은 기존 PSP가 담당한다.

도입 전략

Google은 점진적 도입을 권한다.

  • 1단계: MCP로 외부 도구 연결
  • 2단계: 서비스 규모가 커지면 A2A로 에이전트 분리
  • 3단계: 커머스/결제가 생기면 UCP·AP2 추가
  • 4단계: 실시간 UI가 필요해지면 A2UI·AG-UI 도입

한 번에 다 붙이려 하지 말고, 아키텍처 복잡도를 단계별로 올리는 것이 핵심이다.

정리

  • 6종 프로토콜은 에이전트 스택의 각 레이어를 분리해서 표준화한 것이다
  • 대부분의 프로젝트는 MCP → A2A 순으로 시작하면 충분하다
  • 각 프로토콜은 특정 문제를 해결하므로 필요한 시점에 붙인다
  • ADK(Agent Development Kit)를 쓰면 이 프로토콜들의 공식 구현체를 활용할 수 있다

AI 에이전트 개발에서 "커스텀 통합 코드"를 계속 짜야 하는 구조는 장기적으로 유지비가 커진다. 표준 프로토콜 채택이 일찍 할수록 이득이다.


참고: