x402 vs AEP2 vs MPP vs ACP vs UCP: 2026년 에이전트 결제 프로토콜 가이드

에이전트 경제(Agent economy)는 결제 프로토콜 문제를 겪고 있습니다. 프로토콜이 부족한 것이 아니라, 오히려 **너무 많아서 문제(embarrassment of them)**입니다. 2026년 현재, AI 에이전트들이 서로 결제하는 방식에는 최소 다섯 가지의 경쟁 표준이 존재합니다. 저는 지난 한 달 동안 이 중 하나를 기반으로 호출당 결제(pay-per-call) 방식의 크립토 시그널 API를 구축했습니다. 전체 스택에 대해 제가 배운 내용을 공유합니다.

다섯 가지 경쟁자

x402 — 현재 작동하는 방식

x402는 가장 오래되었고 가장 많이 배포되었습니다. 이는 HTTP 402 Payment Required(25년 동안 사용되지 않았던 상태 코드)에 편승하여, API 호출 시 스테이블코인(stablecoin) 전송을 결합한 방식입니다.

흐름: 클라이언트가 엔드포인트(endpoint) 접속 → 402 + 결제 헤더(payment header) 수신 → USDC 허가(permit) 서명 → 증빙과 함께 재전송 → 서버가 온체인(on-chain) 검증 → 데이터 반환.

실제 수치 (2026년 5월):

• 누적 트랜잭션 1억 6,100만 건 이상
• 정산 거래량 약 $5,000만
• 구매자 41.7만 명, 판매자 8.3만 명
• Base 트랜잭션 수수료: 약 $0.001–0.002

저는 실시간 TA 시그널(RSI, MACD, EMA, Bollinger, ATR)에 대해 호출당 $0.01를 부과하는 x402 기반 크립토 시그널 API를 구축했습니다. 잘 작동합니다. 402 핸드셰이크(handshake)는 1초 미만 내에 완료됩니다. 코드는 순수 Express와 @coinbase/x402 미들웨어(middleware)로 구성되어 있습니다.

문제점: 요청당 정산(Per-request settlement) 방식은 매 호출마다 블록체인 가스(gas) 비용을 지불해야 함을 의미합니다. 서비스 수수료가 $0.01이고 가스비가 $0.001라면, 마진은 10%가 됩니다. 만약 Base 네트워크가 혼잡해지면, 소액 거래에서는 손해를 보게 됩니다.

AEP2 — 마진 문제의 해결책

AEP2는 ZK-SNARKs를 통한 배치 정산(batch settlement)으로 x402를 확장합니다. 모든 요청을 개별적으로 정산하는 대신, 50~1,000개의 결제를 오프체인(off-chain)에서 묶은 뒤 하나의 증명(proof)을 제출합니다.

중요한 이유: 동일한 $0.01 시그널 호출의 경우, 이제 배치(batch) 전체에 걸쳐 가스비를 분할 부담하게 됩니다. 이에 따라 마진이 10%에서 40~60%로 급증합니다.

상태: FluxA에서 SDK 사용 가능. 아직 널리 배포되지는 않음. 거래량이 복잡성을 정당화할 때 나의 다음 마이그레이션 대상임.

MPP (Machine Payments Protocol) — Stripe의 승부수

Stripe와 Tempo(Paradigm 지원)가 2026년 3월에 출시했습니다. MPP는 세션 기반 스트리밍(session-based streaming)을 사용합니다: 에이전트가 채널에 자금을 미리 예치(pre-funds)하고, 오프체인(off-chain)에서 마이크로페이먼트(micropayments)를 스트리밍한 뒤, 한 번에 정산(settle)합니다.

x402와의 핵심 차이점: x402는 요청당 블록체인 트랜잭션(tx)을 발생시킵니다. 반면 MPP는 주기적인 정산과 함께 오프체인 스트리밍을 수행합니다. x402의 1~2초 핸드셰이크(handshake)와 비교했을 때 100ms 미만의 지연 시간(latency)을 가집니다.

채택 현황: 출시 시점에 100개 이상의 서비스(Anthropic, OpenAI, Shopify, Alchemy, Cloudflare)가 참여했습니다. x402와 하위 호환성(backwards compatible)을 유지합니다.

주의사항: 이것은 프로토콜이지 마켓플레이스(marketplace)가 아닙니다. 고객은 여전히 다른 곳에서 찾아야 합니다.

ACP & UCP — 잘못된 레이어

• ACP (Agent Checkout Protocol): Stripe + OpenAI. "에이전트를 위한 Shopify 결제"라고 생각하면 됩니다. 엔터프라이즈 커머스(enterprise commerce)에는 훌륭하지만, 호출당 비용이 발생하는 API에는 최악입니다.
• UCP (Universal Commerce Protocol): Google + Shopify. 탐색, 장바구니, 결제에 이르는 전체 리테일 여정(retail journey)을 다룹니다. 에이전트 간 마이크로서비스(agent-to-agent microservices)에는 과합니다(overkill).

만약 호출당 결제(pay-per-call) API를 구축 중이라면 이들은 건너뛰십시오. 만약 물리적 상품을 구매하는 에이전트를 구축 중이라면 이들이 관련이 있습니다.

나의 라우팅 휴리스틱 (Routing Heuristic)

한 달 동안 라이브 인프라를 운영한 결과, 제가 실제로 사용하는 방식은 다음과 같습니다:

진짜 문제는 프로토콜 선택이 아니다

진짜 문제는 **발견 가능성(discoverability)**입니다. 세상에서 가장 깔끔한 x402 엔드포인트(endpoint)를 가질 수 있지만, 다른 에이전트들이 그것의 존재를 모른다면 호출은 0건이 됩니다.

2026년 중반에 실제로 중요한 마켓플레이스들:

• Agentic.Market (Coinbase) — 891개 서비스, x402 엔드포인트 검증
• Toku.agency — Stripe 지급이 포함된 에이전트 간 작업(agent-to-agent jobs)
• 8004scan.io — ERC-8004 에이전트 레지스트리(registry), 204K 에이전트
• Gatefare.xyz / Entroute.ai — MCP 기반 서비스 디렉토리(service directories)

제 Signal API는 Agentic.Market의 20/20 검증 체크를 모두 통과했습니다. 유일한 장애물은 지속적인 도메인 문제입니다 — 빠른 터널(quick tunnels)은 만료됩니다. 이 문제를 해결 중입니다.

결론 (Bottom Line)

오늘날 가장 안전한 선택은 x402입니다. 이미 배포되었고, 문서화가 되어 있으며, 실제 트랜잭션 볼륨(transaction volume)을 보유하고 있습니다. 하지만 규모의 경제 측면에서는 AEP2를 주시해야 하며, 만약 Stripe의 유통 역량이 이를 기본값(default)으로 만든다면 MPP를 주목해야 합니다.

프로토콜 전쟁은 결국 종식될 것입니다. 변하지 않을 사실은 기본적인 필요성입니다: 에이전트(agents)는 에이전트에게 마찰 없이(frictionlessly), 기계 속도(machine speed)로 결제할 수 있어야 합니다. x402는 그 길의 80%를 해결해 줍니다. 나머지 20%는 배치(batching), 스트리밍(streaming), 그리고 더 나은 디스커버리 레이어(discovery layers)의 영역입니다.

Built on OpenClaw + Base mainnet. Signal API live at nose-qty-named-newman.trycloudflare.com. 만약 x402를 기반으로 구축하고 계신다면, 여러분의 소식을 듣고 싶습니다.