x402 vs MPP: 에이전트 결제 프로토콜 비교

2026년 3월 18일에 게시됨5분 읽기

자율 에이전트는 비용을 지불해야 합니다. 언젠가가 아니라 지금 당장 말이죠. 에이전트가 블록체인 데이터를 조회하거나, LLM 토큰을 스트리밍하거나, 유료 API를 호출할 때마다 누군가는 청구 처리를 해야 합니다. 지금까지는 API 키, 청구 대시보드, 사람의 수동 프로비저닝이 필요했습니다. 이 문제를 해결하려는 두 프로토콜이 있습니다: x402와 MPP입니다.

2024년 말, Coinbase는 x402를 발표했습니다. 이는 AI 에이전트가 API를 호출하고, "pay first" 응답을 받고, Base에서 USDC로 결제한 뒤 재시도할 수 있게 해주는 오픈 프로토콜로, API 키나 청구 계정, 사람의 개입 없이 이 모든 과정이 이루어집니다. 이후 Tempo와 Stripe는 이 아이디어를 한 단계 더 발전시켜 Machine Payments Protocol(MPP)을 만들었습니다. IETF Internet-Draft로 정의된 MPP는 402 패턴을 결제 수단에 구애받지 않는 프레임워크로 일반화하여, 단일 프로토콜을 통해 스테이블코인, 카드, 은행 송금, 그리고 향후 등장할 모든 결제 수단을 지원합니다.

이 글에서는 두 프로토콜을 비교하고, 어디서 겹치는지, 그리고 어느 상황에서 어떤 것을 선택해야 하는지 살펴봅니다.

한눈에 보기

	x402	MPP
Payment rails	USDC on Base and other networks	Stablecoin, card, bank: pluggable
Payment models	One-shot (exact)	One-shot (charge) + sessions
Session support	No	Yes (escrow + signed vouchers)
Protocol primitives	Implementation-defined	Standardized (idempotency, expiry, receipts, replay protection)
Transport	HTTP	HTTP + MCP
Standardization	Open-source, community-adopted	IETF Internet-Draft (co-authored by Tempo and Stripe)

x402와 MPP는 핵심 결제 흐름을 어떻게 처리하나요?

두 프로토콜은 핵심적으로 동일한 흐름을 따릅니다: 에이전트가 API를 호출하면, 서버는 결제 챌린지로 응답하고, 클라이언트가 결제한 뒤 재시도하여 응답을 받습니다. 단순하고, 깔끔하며, HTTP 네이티브한 방식입니다.

차이는 범위, 유연성, 그리고 각 프로토콜이 무엇을 표준화하기로 선택했는지에 있습니다.

x402와 MPP는 결제 수단을 어떻게 처리하나요?

x402는 온체인 스테이블코인 결제를 중심으로 설계되었으며, 주로 Base와 그 외 지원되는 네트워크에서의 USDC 결제입니다. 사용 사례가 스테이블코인으로 결제하는 크립토 네이티브 에이전트라면, x402는 이를 구현하는 직접적인 경로를 제공합니다.

MPP는 다른 접근 방식을 취합니다: 프로토콜 자체가 결제 수단에 구애받지 않습니다. 코어 스펙은 서버와 클라이언트가 어떻게 협상하고, 챌린지를 주고받고, 정산하는지를 정의하지만, 실제 결제 수단은 플러그인 가능한 계층으로 존재합니다. 현재 MPP는 두 가지 프로덕션 결제 수단을 제공합니다: Tempo(스테이블코인 결제)와 Stripe(카드, 지갑, 기타 전통적인 결제 수단)이며, 서버는 두 방식을 동시에 알릴 수 있습니다. 클라이언트는 자신이 지원하는 방식을 선택하면 됩니다.

누구나 요청 스키마와 페이로드 스키마를 정의하여 새로운 결제 수단을 만들 수 있습니다. 재단이나 중개자의 승인이 필요하지 않습니다. 결제 수단은 허가가 아니라 채택 여부로 경쟁합니다.

크립토 네이티브 사용자를 위해 개발하고 있다면 x402가 가장 빠른 경로입니다. 엔터프라이즈 고객, 전통적인 결제 통합업체, 혹은 혼합된 사용자층을 위해 개발한다면 MPP의 멀티레일 지원 덕분에 하나를 선택할 필요가 없습니다. 전통적인 가맹점과 직접 거래해야 하는 에이전트를 위해, AgentCard 같은 프로젝트는 보완적인 접근 방식을 취합니다. 즉, 에이전트가 온라인에서 어떤 구매든 사용할 수 있는 신용카드를 발급하며, 지출 한도와 실시간 추적 기능을 내장하고 있습니다.

어떤 결제 모델을 지원하나요?

x402는 "exact" 결제 모델에 초점을 맞춥니다: 하나의 요청, 하나의 결제, 하나의 응답. 이는 깔끔하고 이해하기 쉬우며, 개별 API 호출에 잘 맞습니다.

MPP는 charge intent를 통해 동일한 흐름을 지원하며, 실제로 x402의 exact 흐름은 MPP의 charge에 그대로 대응되므로 두 프로토콜은 이 계층에서 호환됩니다.

하지만 MPP는 세션이라는 근본적으로 다른 결제 모델도 도입합니다. 이는 높은 처리량이 필요한 사용 사례를 위한 것입니다. 세션에서는 클라이언트가 한 번 에스크로 계약에 자금을 예치한 뒤, 서명된 바우처를 사용해 오프체인에서 여러 번 요청을 보냅니다. 서버는 누적된 바우처를 주기적으로 온체인에서 정산합니다.

각 흐름을 단순화한 예시는 다음과 같습니다:

X402: 하나의 요청, 하나의 결제

text

Copied

# Step 1: Call the API
GET /v2/eth-mainnet/getTokenBalances HTTP/1.1

# Step 2: server responds with payment challenge
HTTP/1.1 402 Payment Required
X-Payment-Challenge: {"amount": "0.001", "currency": "USDC", "address": "0x..."}

# Step 3: client pays on-chain, retries with receipt
GET /v2/eth-mainnet/getTokenBalances HTTP/1.1
X-Payment: {"txHash": "0x...", "signature": "0x..."}

# Step 4: server verifies and responds
HTTP/1.1 200 OK

MPP 세션: 한 번 예치하고 수천 번 요청하기

text

Copied

# Step 1: Open a session (deposit funds to escrow once)
POST /mpp/sessions HTTP/1.1
{"amount": "10.00", "currency": "USDC", "method": "tempo"}

HTTP/1.1 201 Created
{"sessionId": "sess_abc123", "balance": "10.00"}

# Step 2: make requests with signed vouchers (no on-chain tx per request)
GET /v2/eth-mainnet/getTokenBalances HTTP/1.1
MPP-Session: sess_abc123
MPP-Voucher: {"amount": "0.0001", "nonce": 42, "sig": "0x..."}

HTTP/1.1 200 OK  # Sub-100ms, no waiting for chain confirmation

MPP 세션은 다음을 가능하게 합니다:

요청당 $0.0001만큼 작은 결제
100ms 미만의 지연 시간: 요청마다 온체인 확인이 필요 없음
거의 0에 가까운 요청당 수수료: 순 정산만 체인에 반영됨

왜 중요한가: 토큰당 과금되는 LLM 스트리밍, 고처리량 데이터 피드, 실시간 체인 모니터링이 모두 경제적으로 실현 가능해집니다. 모든 상호작용마다 온체인으로 결제하면 데이터의 가치보다 가스비가 더 많이 들 것입니다. 세션은 이 계산을 완전히 뒤바꿔, 대규모의 마이크로결제 기반 접근을 실용적으로 만듭니다.

각 프로토콜은 어떤 프로토콜 수준의 프리미티브를 제공하나요?

MPP는 여러 프로덕션 관련 사항을 프로토콜 스펙 자체에 내장하여, 모든 구현이 이를 새로 만들지 않고도 물려받도록 합니다:

멱등성(Idempotency): 이중 청구 없이 안전하게 재시도 가능
만료(Expiration): 챌린지가 시간이 지나면 만료되어 오래된 결제를 방지
요청 본문 바인딩(Request-body binding): SHA-256 다이제스트로 챌린지와 결제 사이의 변조 방지
재생 공격 방지(Replay protection): HMAC로 바인딩된 챌린지 ID
구조화된 오류(Structured errors): 기계가 읽을 수 있는 오류 처리를 위한 RFC 9457 포맷
1급 영수증(First-class receipts): 감사(auditing)를 위한 표준화된 결제 영수증

x402는 이 중 일부를 구현 수준에서 처리하지만, 나머지는 개별 개발자에게 맡깁니다. MPP는 이를 표준화하여 모든 서버와 클라이언트가 기본적으로 동일한 언어를 사용하도록 하는데, 이는 서로 다른 벤더의 에이전트들이 신뢰성 있게 상호운용해야 할 때 중요합니다.

MPP는 HTTP 이외에서도 동작하나요?

x402는 HTTP 위에서 동작합니다. MPP도 HTTP 위에서 동작하지만, 여기에 MCP(Model Context Protocol) 전송 바인딩을 추가합니다.

이는 MCP 툴 서버가 툴 호출을 직접 수익화할 수 있다는 의미입니다. 유료 툴을 호출하는 AI 에이전트는 툴 응답에서 결제 챌린지를 받고, 결제한 뒤 재시도하며, 이 모든 과정이 MCP 메시지 흐름 안에서 이루어집니다. OAuth도, 계정 설정도, HTTP 계층도 필요하지 않습니다.

지금까지 AI 툴 호출을 수익화하려면 별도의 채널을 통한 청구나 플랫폼 계약이 필요했습니다. MPP의 MCP 전송 방식을 사용하면, 개발자는 MCP와 호환되는 모든 에이전트가 발견하고, 결제하고, 자율적으로 사용할 수 있는 유료 툴을 사람의 개입 없이 게시할 수 있습니다.

표준화 측면에서는 어떻게 비교되나요?

x402는 오픈소스 프로토콜로, 커뮤니티 채택이 계속 늘고 있습니다. Coinbase에서 프로덕션 환경에서 검증되었으며, 생태계 전반에서 지원이 점점 늘고 있습니다.

MPP의 코어인 Payment HTTP Authentication Scheme은 Tempo와 Stripe가 공동 저술하여 IETF Internet-Draft로 제출되었습니다. 결제 수단과 intent는 별도의 스펙으로, 누구든 독립적으로 작성하고 게시할 수 있습니다. 이는 웹 자체가 작동하는 방식과 유사합니다: HTTP는 표준화되어 있지만, 콘텐츠 유형과 인증 방식은 독립적으로 발전합니다.

Internet-Draft는 아직 표준 트랙 RFC가 아닌 작업 중인 문서이지만, IETF 제출은 장기적인 상호운용성과 안정성을 향한 의도를 나타냅니다.

x402와 MPP는 호환되나요?

네. MPP는 x402와 하위 호환됩니다. x402의 핵심 "exact" 결제 흐름은 MPP의 charge intent에 그대로 대응되므로, MPP 클라이언트는 기존 x402 서비스를 그대로 사용할 수 있습니다. 이미 x402 위에 구축했다면, MPP는 기존 것을 대체하는 것이 아니라 확장합니다.

Alchemy로 시작하기

Alchemy는 API 플랫폼 전반에서 x402와 MPP를 모두 지원합니다. 즉, 여러분의 에이전트는 블록체인 데이터(토큰 잔액, NFT 메타데이터, 트랜잭션 기록, 스마트 컨트랙트 읽기, 가격 피드 등)에 접근하고, 두 프로토콜 중 무엇이든 사용해 요청당 결제할 수 있습니다. API 키도, 청구 대시보드도 필요 없습니다. 지갑과 HTTP 호출만 있으면 됩니다.

x402를 사용하면 에이전트는 SIWE(Sign-In with Ethereum) 또는 SIWS(Sign-In with Solana)로 인증하고, Base에서 USDC로 결제한 뒤 Alchemy의 엔드포인트에 접근합니다. MPP를 사용하면 같은 에이전트가 여러 결제 수단(Tempo를 통한 스테이블코인, Stripe를 통한 카드)을 두고 협상할 수 있으며, 인덱싱 파이프라인이나 실시간 체인 모니터링 같은 고처리량 워크로드에 세션을 사용할 수 있습니다.

만들 수 있는 것들:

자율 블록체인 에이전트: 온체인 데이터를 조회하고 모든 호출에 대해 결제하며, 사람의 프로비저닝이 필요 없음
멀티체인 데이터 파이프라인: Ethereum, Base, Polygon, Solana 등에서 데이터를 가져오고, MPP 세션을 통해 요청당 1센트 미만의 비용으로 결제
AI 기반 지갑 및 코파일럿: 포트폴리오 데이터를 가져오고, 트랜잭션을 시뮬레이션하고, 주소를 모니터링하며, 모두 자체 자금으로 운영
MCP 툴 서버: Alchemy 엔드포인트를 유료 툴로 감싸서, MCP와 호환되는 모든 에이전트가 필요할 때 블록체인 인프라에 접근할 수 있도록 함

터미널에서 직접 사용해보기

Alchemy CLI를 설치한 다음, Alchemy Skills를 추가하고 MCP server를 연결하세요:

bashCopied
npm i -g @alchemy/cli@latest
alchemy auth
npx skills add alchemyplatform/skills --yes

# Claude Code
claude mcp add alchemy --transport http https://mcp.alchemy.com/mcp

# Codex
codex mcp add alchemy --url https://mcp.alchemy.com/mcp

alchemy --json --no-interactive balance vitalik.eth -n eth-mainnet

시작할 준비가 되셨나요? alchemy.com/agents에서 플랫폼을 살펴보고, 스스로 인프라 비용을 지불하는 에이전트를 만들어보세요.

FAQ

x402와 MPP를 함께 사용할 수 있나요?

네. MPP의 charge intent가 x402와 하위 호환되므로, 두 프로토콜을 동시에 지원할 수 있습니다. 서버는 두 프로토콜을 모두 알릴 수 있고, 클라이언트는 자신이 지원하는 것을 선택하면 됩니다.

어떤 것을 선택해야 하나요?

스테이블코인으로 결제하는 크립토 네이티브 에이전트를 만들고 있고 프로덕션까지 가장 단순한 경로를 원한다면 x402로 시작하세요. 멀티레일 결제 지원, 고처리량 워크로드를 위한 세션, MCP 전송 통합, 표준화된 프로토콜 프리미티브가 필요하다면 MPP가 더 적합합니다. 이를 위해 기존 x402 투자를 포기할 필요는 없습니다.

x402는 MPP로 대체되고 있나요?

아닙니다. MPP는 x402를 대체하기 위해서가 아니라 호환되도록 설계되었습니다. MPP는 x402가 원래 제공하려 하지 않았던 기능을 추가하는 발전형이라고 생각하면 됩니다. x402 커뮤니티는 독립적으로 계속 성장하고 있습니다.

MPP는 현재 어떤 결제 수단을 지원하나요?

MPP는 두 가지 프로덕션 결제 수단을 제공합니다: 스테이블코인 결제를 위한 Tempo와 카드, 지갑, 기타 전통적인 결제 수단을 위한 Stripe입니다. 결제 수단은 플러그인 가능하므로, 누구나 요청 스키마와 페이로드 스키마를 정의하여 새로운 결제 수단을 만들고 게시할 수 있습니다.

이 프로토콜들을 사용하려면 자체 인프라를 운영해야 하나요?

아닙니다. Alchemy는 API 플랫폼 전반에서 x402와 MPP를 모두 지원하므로, 직접 결제 인프라를 운영하지 않고도 블록체인 데이터에 대해 결제하는 에이전트를 만들기 시작할 수 있습니다. alchemy.com/agents에서 시작해보세요.