x402

x402는 HTTP 402 응답과 EIP-3009 서명을 사용해 요청-응답 루프 안에서 직접 결제를 수행하는 오픈 프로토콜이다.

HTTP 402

HTTP 상태 코드 중 402는 특이한 존재다. 401(Unauthorized), 403(Forbidden), 404(Not Found)처럼 매일 마주치는 코드가 아니라, 스펙에는 존재하지만 아무도 구현하지 않은 코드였다.

이유는 명확하다. 1997년에는 웹에서 결제를 처리할 표준 메커니즘이 없었다. 신용카드 결제는 PG사(Payment Gateway)가 애플리케이션 레벨에서 처리했고, HTTP 프로토콜 자체에 결제를 내장할 필요가 없었다.

그러다 세 가지 변화가 겹쳤다.

• AI 에이전트가 사람 대신 API를 호출하고, 자율적으로 서비스를 소비하기 시작했다
• 마이크로페이먼트 수요가 폭발했지만, 신용카드의 최소 수수료 구조(건당 0.30달러+)로는 0.001달러짜리 API 호출에 과금할 수 없다
• 스테이블코인(USDC 등)이 프로그래머블 화폐로서 충분히 성숙했다

이 세 가지가 맞물리면서 x402가 등장했다.

x402 프로토콜 개요

x402는 HTTP 요청-응답 루프 안에서 직접 결제를 수행하는 오픈 프로토콜이다. API 키 발급, 계정 생성, 구독 설정, KYC — 이런 과정 없이 HTTP 헤더만으로 결제가 완료된다.

핵심 구성 요소는 세 가지다.

구성 요소	역할
Client	리소스를 요청하고, 결제가 필요하면 서명을 생성하여 재요청
Resource Server	유료 리소스를 제공하는 서버. 402 응답과 결제 조건을 반환
Facilitator	결제 서명을 검증하고 온체인 정산을 수행하는 중개 서비스

Facilitator는 자금을 보관하지 않는다(non-custodial). 클라이언트가 서명한 페이로드를 검증하고, 블록체인에 트랜잭션을 제출하는 역할만 한다.

결제 플로우

전체 플로우를 단계별로 살펴보자.

sequenceDiagram
    participant C as Client
    participant S as Resource Server
    participant F as Facilitator

    C->>S: GET /api/resource
    S-->>C: 402 Payment Required<br/>(X-PAYMENT-REQUIRED 헤더)

    Note over C: EIP-3009 서명 생성<br/>(transferWithAuthorization)

    C->>S: GET /api/resource<br/>(X-PAYMENT 헤더에 서명 포함)
    S->>F: POST /verify (서명 검증 요청)
    F-->>S: 검증 완료 + 정산 예약
    S-->>C: 200 OK + 리소스 응답

    Note over F: 블록체인에 트랜잭션 제출

1단계: 최초 요청과 402 응답

클라이언트가 일반 HTTP 요청을 보내면, 서버는 결제가 필요한 리소스에 대해 HTTP 402를 반환한다. 이때 X-PAYMENT-REQUIRED 헤더에 결제 조건이 Base64로 인코딩되어 포함된다.

{
  "scheme": "exact",
  "network": "base-sepolia",
  "maxAmountRequired": "1000000",
  "resource": "https://api.example.com/resource",
  "description": "API 호출 비용",
  "mimeType": "application/json",
  "payTo": "0x1234...abcd",
  "maxTimeoutSeconds": 60,
  "asset": "0x036CbD53842c5426634e7929541eC2318f3dCF7e",
  "extra": {}
}

• scheme: "exact" — 정확한 금액을 한 번에 결제하는 방식
• maxAmountRequired — USDC 기준 금액 (6 decimals, 즉 1000000 = 1.00달러)
• payTo — 결제를 수신할 지갑 주소
• asset — 결제에 사용할 토큰의 컨트랙트 주소(여기서는 USDC)

2단계: 클라이언트의 결제 서명

클라이언트는 EIP-3009(transferWithAuthorization)를 사용해 오프체인 서명을 생성한다. 이것이 x402의 기술적 핵심이다.

EIP-3009는 USDC 같은 ERC-20 토큰에 구현된 표준으로, 토큰 소유자가 직접 트랜잭션을 제출하지 않고도 서명만으로 전송을 승인할 수 있게 한다. 가스비는 서명을 제출하는 쪽(Facilitator)이 부담한다. 즉, 구매자는 가스비를 내지 않는다.

비슷한 가스리스 전송은 메타 트랜잭션(ERC-2771)이나 계정 추상화(ERC-4337)로도 구현할 수 있다. 다만 EIP-3009는 토큰 컨트랙트 자체에 기능이 내장돼 있어 별도 forwarder 컨트랙트나 스마트 컨트랙트 지갑 없이 EOA만으로 동작한다.

서명된 페이로드는 X-PAYMENT 헤더에 담겨 재요청된다.

{
  "payload": {
    "signature": "0xabc123...",
    "authorization": {
      "from": "0xBuyer...",
      "to": "0xSeller...",
      "value": "1000000",
      "validAfter": "0",
      "validBefore": "1711843200",
      "nonce": "0x..."
    }
  }
}

3단계: 검증과 정산

Resource Server는 Facilitator의 /verify 엔드포인트에 서명 검증을 위임한다. Facilitator가 서명의 유효성을 확인하면 서버는 리소스를 반환하고, Facilitator는 비동기적으로 블록체인에 트랜잭션을 제출하여 정산한다.

서버 측 구현

x402를 서버에 적용하는 코드는 실제로 매우 간결하다. Express.js 미들웨어 예시를 보자.

import { paymentMiddleware } from "@coinbase/x402-express";

const app = express();

app.use(
  paymentMiddleware({
    description: "AI 번역 API",
    payTo: "0xYourWalletAddress",
    amount: "$0.01",
    network: "base",
    facilitatorUrl: "https://x402.org/facilitator",
  })
);

app.get("/api/translate", (req, res) => {
  // 결제가 완료된 요청만 이 핸들러에 도달
  res.json({ result: translate(req.body.text) });
});

미들웨어가 402 응답, 서명 검증, Facilitator 통신을 모두 처리한다. 서버 개발자가 결제 로직을 직접 구현할 필요가 없다.

AI 에이전트와 x402

x402의 대표적인 유즈케이스는 AI 에이전트의 자율 결제다.

기존 구조에서 AI 에이전트가 유료 API를 사용하려면 다음 과정이 필요했다.

1. 사람이 API 제공자 사이트에 가입
2. 신용카드 등록 및 KYC 완료
3. API 키 발급
4. 에이전트에 API 키를 설정
5. 사용량 모니터링 및 과금 관리

x402에서는 이 과정이 다음으로 축소된다.

1. 에이전트에 지갑(서명 키)과 USDC 잔고를 부여
2. 에이전트가 402 응답을 받으면 자동으로 서명 후 재요청

flowchart LR
    A[AI 에이전트] -->|1. API 호출| B[유료 API]
    B -->|2. 402 반환| A
    A -->|3. 서명 + 재요청| B
    B -->|4. 리소스 응답| A

    style A fill:#4A90D9,color:#fff
    style B fill:#50C878,color:#fff

에이전트 입장에서는 HTTP 클라이언트에 x402 핸들링만 추가하면 어떤 유료 API든 자율적으로 소비할 수 있다. 계정도, API 키도, 사람의 개입도 필요 없다.

Cloudflare는 이 개념을 “pay per crawl”로 확장했다. 웹 크롤러(AI 포함)가 콘텐츠를 가져갈 때 자동으로 소액 결제를 수행하는 모델이다. 콘텐츠 제작자가 무료로 가치를 빼앗기지 않으면서도, 크롤러 접근을 완전히 차단하지 않는 중간 지대를 만든다.

x402 V2: 세션과 멀티체인

2025년 12월 출시된 V2에서 프로토콜의 실용성이 크게 개선되었다.

지갑 기반 세션 (Wallet Identity)

V1의 가장 큰 불편함은 매 요청마다 온체인 결제가 필요했다는 점이다. 10번의 API 호출이면 10번의 블록체인 트랜잭션. V2는 SIWx(Sign-In-With-X, CAIP-122 기반) 헤더를 도입하여 세션 개념을 추가했다.

• 최초 1회 결제로 세션을 열고, 이후 요청은 세션 토큰으로 인증
• 서버가 세션의 유효 기간과 사용량 한도를 설정 가능

동적 수신자 (Dynamic payTo)

V1에서는 결제 수신 주소가 서버 설정에 고정되어 있었다. V2에서는 요청별로 다른 주소로 라우팅할 수 있어, 마켓플레이스나 멀티테넌트 플랫폼에서 활용 가능하다.

멀티체인 지원

CAIP(Chain Agnostic Improvement Proposal) 표준을 채택하여 Base뿐 아니라 Ethereum, Solana 등 다양한 체인을 지원한다.

경쟁 프로토콜과 비교

x402만이 이 영역의 유일한 플레이어는 아니다.

	x402	Stripe MPP	L402 (Lightning)
개발사	Coinbase	Stripe	Lightning Labs
결제 모델	요청당 결제	세션 기반 스트리밍	요청당 결제
지원 화폐	USDC 중심	법정화폐 + 크립토 + 카드	Bitcoin (Lightning)
설정 복잡도	낮음 (미들웨어 한 줄)	중간 (Stripe 통합)	높음 (Lightning 노드)
규제 준수	제한적	Stripe 컴플라이언스 내장	제한적
강점	단순함, 오픈소스	하이브리드 결제, 기존 인프라	완전 탈중앙화

Stripe MPP(Merchant Payment Protocol)는 2026년 2월 출시되었다. 기존 Stripe 결제 인프라 위에 구축되어 법정화폐, 크립토, 카드를 모두 지원하며, 규제 준수가 내장되어 있다. 엔터프라이즈 환경에서는 x402보다 현실적인 선택일 수 있다.

한계와 우려

x402를 평가할 때 균형 잡힌 시각이 필요하다.

중앙화 우려

x402는 오픈 프로토콜을 표방하지만, 실질적으로 Coinbase 생태계에 대한 의존도가 높다.

• 대부분의 프로덕션 배포가 Coinbase 호스팅 Facilitator를 사용
• 결제 토큰이 USDC(Circle/Coinbase 발행)에 집중
• 주요 지원 체인이 Base(Coinbase의 L2)

Facilitator를 자체 운영하려면 블록체인 인프라를 직접 구축해야 하므로, “한 줄 코드로 결제 추가”라는 약속과 현실 사이에 괴리가 존재한다.

References

• x402 공식 사이트
• GitHub - coinbase/x402
• Coinbase - Introducing x402
• Coinbase - x402 Foundation 발표
• Cloudflare - x402 Foundation
• x402 V2 발표
• InfoQ - x402 V2: Agentic HTTP Payments
• DWF Labs - Inside x402
• WorkOS - x402 vs Stripe MPP
• Halborn - x402 Security Risks
• EIP-3009: transferWithAuthorization