AI 에이전트가 스스로 결제하는 웹: x402 프로토콜

AI 에이전트에게 일을 시키다가 이런 벽에 부딪혀 보신 적 있나요? 필요한 데이터를 가져오라고 시켰더니 “해당 API는 인증이 필요합니다”라며 멈춰 서는 상황 말이죠. 그 API를 쓰려면 사람인 제가 직접 회원가입을 하고, 신용카드를 등록하고, 요금제를 고르고, 발급받은 키를 환경 변수에 꽂아줘야 합니다. 에이전트가 자율적으로 일한다더니 결제 앞에서는 매번 저를 부르는 셈입니다. 😅

생각해보면 당연합니다. 웹의 결제는 처음부터 끝까지 사람을 전제로 설계됐거든요. 결제 양식을 채우고 약관에 동의하고 인증 문자를 받는 과정은 전부 사람의 행동입니다. 프로그램끼리 데이터를 주고받는 방식과는 애초에 결이 다르죠.

x402는 바로 이 간극을 겨냥한 개방형 표준(open standard)입니다. 결제를 HTTP 요청과 응답 안으로 끌어들여서, 클라이언트가 402 응답을 받으면 그 자리에서 값을 치르고 다시 요청하게 만드는 것이죠. 이 글에서는 x402가 어떤 헤더와 어떤 역할로 굴러가는지 실제 서버를 띄워 캡처한 응답과 함께 살펴보겠습니다.

API 키라는 낡은 관문

x402를 이해하려면 지금 API를 사고파는 방식이 얼마나 번거로운지부터 짚어야 합니다. 새로운 API 하나를 쓰려면 보통 이런 과정을 거치죠. 계정을 만들고, 결제 수단을 등록하고, 크레딧이나 구독을 미리 사고, 발급받은 키를 안전하게 보관하고, 나중에 청구서를 정산합니다.

이 절차는 사람에게도 귀찮지만 기계에게는 사실상 통과 불가능한 관문입니다. 게다가 선불 구조라서 실제로 쓰지도 않을 크레딧을 미리 사둬야 하고, 유출되면 곧바로 요금 폭탄으로 이어지는 API 키를 계속 관리해야 하죠.

x402가 그리는 그림은 훨씬 짧습니다. 에이전트가 요청을 보내고, 402 응답을 받고, 그 자리에서 값을 치르고 데이터를 받아옵니다. 계정도 키도 없고 선불 충전도 없습니다. 요청 한 건에 대해서만 값을 치르니 API 키를 관리할 일도 사라지죠.

x402는 원래 Coinbase가 공개한 프로토콜인데요. 2026년 7월 Linux Foundation 산하에 x402 Foundation이 출범하면서 중립적인 표준화 기구로 운영 주체가 옮겨갔습니다. Visa, Mastercard, American Express, Stripe, Google, AWS, Shopify, Cloudflare 같은 40여 개 회사가 창립 멤버로 참여했고요. 특정 회사의 결제 서비스가 아니라 여러 진영이 함께 쓰는 규약으로 자리를 잡아가는 중입니다.

30년 만에 출근한 402

x402라는 이름은 HTTP 상태 코드 402 Payment Required에서 왔습니다. 402는 1990년대 HTTP 초안 시절부터 “언젠가 웹에서 돈이 오갈 것”이라는 기대를 담아 자리만 잡아둔 코드인데요. 소액 결제(micropayment) 인프라가 끝내 대중화되지 않으면서 최신 명세인 RFC 9110에서도 여전히 “향후 사용을 위해 예약”된 상태로 남아 있었습니다.

x402는 이 빈자리에 구체적인 규약을 채워 넣습니다. 402를 받은 클라이언트가 무엇을 어떻게 지불해야 하는지, 지불했다는 사실을 어떻게 증명하는지, 서버는 그걸 어떻게 확인하는지를 전부 정해둡니다. 상태 코드는 “돈을 내라”는 신호까지만 담당하고, 그다음 대화는 헤더가 이어받습니다.

세 개의 헤더로 끝나는 결제

x402 버전 2는 딱 세 개의 헤더로 결제 대화를 주고받습니다. 서버가 가격표를 내미는 PAYMENT-REQUIRED, 클라이언트가 지불 증명을 담아 보내는 PAYMENT-SIGNATURE, 서버가 정산 결과를 알려주는 PAYMENT-RESPONSE입니다. 세 헤더 모두 JSON을 Base64로 인코딩해서 담는데요. 특수 문자 때문에 중간 프록시에서 깨지는 일을 막기 위한 선택입니다.

전체 흐름은 이렇게 흘러갑니다.

sequenceDiagram
    accTitle: x402 결제가 이뤄지는 요청과 응답의 흐름
    accDescr: 클라이언트가 리소스 서버에 요청하면 402 응답과 PAYMENT-REQUIRED 헤더로 가격표를 받는다. 클라이언트는 지불 증명에 서명해 PAYMENT-SIGNATURE 헤더와 함께 재요청하고, 리소스 서버는 퍼실리테이터에 검증과 정산을 맡긴 뒤 200 응답과 PAYMENT-RESPONSE 헤더를 돌려준다.

    participant C as 클라이언트
    participant S as 리소스 서버
    participant F as 퍼실리테이터

    C->>S: 요청
    S-->>C: 402 + PAYMENT-REQUIRED
    Note over C: 지불 증명 서명
    C->>S: 재요청 + PAYMENT-SIGNATURE
    S->>F: 검증 요청
    F-->>S: 검증 결과
    Note over S: 요청 처리
    S->>F: 정산 요청
    F-->>S: 정산 결과
    S-->>C: 200 + PAYMENT-RESPONSE

여기서 눈여겨볼 대목은 검증(verification)과 정산(settlement)이 갈라져 있다는 점입니다. 서버는 지불 증명이 유효한지만 먼저 확인하고 곧바로 일을 시작할 수 있는데요. 블록체인 확정을 기다리느라 응답이 늦어지는 걸 피하려는 설계입니다. 확정 전에 일을 시작하면 미확정 위험을 서버가 떠안게 되지만, 응답 속도와 지불 보장 사이에서 서버가 직접 저울질할 수 있게 열어둔 것이죠.

퍼실리테이터가 대신 짊어지는 것들

방금 다이어그램에 슬쩍 끼어든 세 번째 참가자가 궁금하셨을 텐데요. 퍼실리테이터(facilitator)는 검증과 정산을 대신 맡아주는 서비스입니다. /verify로 지불 증명이 유효한지 확인해주고, /settle로 실제 블록체인 거래를 제출하고 확정을 기다려줍니다.

이 역할이 왜 필요할까요? 퍼실리테이터가 없다면 API를 파는 모든 서버가 블록체인 노드에 연결하고, 거래를 체인에 올릴 때 내는 수수료인 가스비를 계산하고, 체인마다 다른 서명 규격을 구현해야 합니다. 날씨 데이터를 팔고 싶었을 뿐인데 블록체인 인프라 운영자가 되어야 하죠.

퍼실리테이터는 이 복잡함을 한곳으로 몰아줍니다. 서버는 HTTP 요청 두 번으로 검증과 정산을 끝내고 원래 하던 일에 집중하면 됩니다. 클라이언트도 마찬가지로 가스비나 RPC 엔드포인트를 신경 쓸 필요가 없고요. x402가 내건 원칙 중에 “암호화폐의 세부 사항을 최대한 퍼실리테이터 쪽으로 밀어 넣는다”는 항목이 있는데, 이 구조가 바로 그 원칙의 구현입니다.

그럼 실제로 누가 이 자리를 맡고 있을까요? 가장 큰 곳은 Coinbase 개발자 플랫폼(CDP)이고, 뒤이어 PayAI나 thirdweb 같은 서비스가 자리를 넓혀가고 있습니다. 퍼실리테이터는 허가가 필요한 자리가 아니라서 누구나 직접 띄울 수도 있고요. 잠시 뒤 예제에서 쓸 https://x402.org/facilitator는 테스트넷용으로 공개된 것입니다.

헷갈리기 쉬운 자리도 하나 짚고 가겠습니다. Stripe도 x402 지원을 미리보기로 내놨는데, Stripe은 퍼실리테이터가 아닙니다. Stripe 문서가 안내하는 구성을 보면 검증과 정산은 Coinbase CDP 퍼실리테이터가 맡고, Stripe은 대금을 받을 입금 주소를 발급해주고 정산이 끝난 거래를 결제 건(PaymentIntent)으로 기록하는 역할을 합니다. 카드 결제와 스테이블코인 결제를 한 대시보드에서 보게 해주는 것이죠. 퍼실리테이터가 체인 위에서 돈을 옮기는 자리라면, Stripe은 그 뒤에서 장부를 맞추는 자리에 가깝습니다.

중요한 건 퍼실리테이터가 돈을 보관하지 않는다는 점입니다. 클라이언트가 서명한 페이로드를 받아 그대로 체인에 제출할 뿐, 자기 마음대로 자금을 옮길 수 없거든요. 프로토콜 자체가 “퍼실리테이터나 리소스 서버는 클라이언트의 의도를 벗어나 자금을 움직일 수 없어야 한다”는 조건을 스킴의 승인 기준으로 못 박아 뒀습니다. 중개자를 두되 중개자를 신뢰하지 않아도 되게 만드는 것이죠.

402 응답 뜯어보기

말로만 보면 감이 잘 안 오니 직접 띄워보겠습니다. x402 서버를 로컬에 올리고 결제 없이 요청하면 이런 응답이 돌아옵니다.

HTTP/1.1 402 Payment Required
Content-Type: application/json
Cache-Control: no-store
PAYMENT-REQUIRED: eyJ4NDAyVmVyc2lvbiI6MiwiZXJyb3IiOiJQYXltZW50IHJlcXVpcmVkIiwicmVzb3VyY2Ui...

헤더 값이 Base64라서 그냥은 읽을 수 없죠. base64 명령으로 풀고 jq로 모양을 잡아보겠습니다.

curl -sD - -o /dev/null http://localhost:4021/weather \
  | grep -i '^payment-required:' | cut -d' ' -f2- | tr -d '\r' \
  | base64 -d | jq

중간에 낀 tr -d '\r'이 눈에 거슬릴 텐데요. HTTP 헤더는 줄 끝이 CRLF라서 캐리지 리턴을 떼어내지 않으면 디코딩이 깨집니다. 이렇게 돌리면 이런 JSON이 나옵니다.

{
  "x402Version": 2,
  "error": "Payment required",
  "resource": {
    "url": "http://localhost:4021/weather",
    "description": "Weather data",
    "mimeType": "application/json"
  },
  "accepts": [
    {
      "scheme": "exact",
      "network": "eip155:84532",
      "amount": "1000",
      "asset": "0x036CbD53842c5426634e7929541eC2318f3dCF7e",
      "payTo": "0x209693Bc6afc0C5328bA36FaF03C514EF312287C",
      "maxTimeoutSeconds": 300,
      "extra": {
        "name": "USDC",
        "version": "2"
      }
    }
  ]
}

가격표가 통째로 들어 있습니다. accepts는 서버가 받아주는 결제 조건의 목록인데요. 배열인 이유는 여러 네트워크와 방식을 동시에 열어두고 클라이언트가 자기 지갑에 맞는 걸 고르게 하기 위해서입니다.

각 조건을 보면 scheme은 돈이 움직이는 방식, network는 어느 체인인지(여기서는 Base Sepolia 테스트넷), amount는 금액, asset은 어떤 자산으로 낼지, payTo는 받을 주소입니다. maxTimeoutSeconds는 이 가격표의 유효 시간이고요.

여기서 extra에 찍힌 USDC가 뭔지 짚고 가겠습니다. 스테이블코인(stablecoin)은 값이 달러 같은 법정 통화에 고정되도록 설계된 암호화폐입니다. 비트코인처럼 시세가 출렁이는 자산으로는 API 한 번에 0.001달러라는 가격표 자체가 성립하지 않으니, x402가 스테이블코인을 앞세운 건 자연스러운 선택이죠. USDC는 1개가 1달러에 대응하도록 만들어진 스테이블코인이고, 위 응답에서 보듯 제가 지정하지 않아도 미들웨어가 기본으로 골라줍니다.

개발자에게 실질적으로 중요한 건 두 가지뿐입니다. 우선 금액을 소수점 없는 정수로 다룹니다. USDC는 소수점 아래 6자리까지 표현하도록 정해져 있어서 1달러가 1000000이고, 그래서 제가 $0.001이라고 적은 값이 응답에서는 1000으로 나온 것입니다. 또 토큰마다 체인 위에 배포된 컨트랙트 주소가 신분증처럼 붙습니다. asset에 들어간 0x036C로 시작하는 값이 Base Sepolia 테스트넷에 있는 USDC의 주소인데, 이것 역시 제가 적지 않았는데 미들웨어가 네트워크 ID만 보고 채워줬고요.

정리하면 개발자는 달러 표기로 가격만 정하고, 체인마다 다른 단위와 주소는 라이브러리가 번역해주는 구조입니다. 암호화폐를 잘 몰라도 API에 값을 매길 수 있게 하려는 설계인 셈이죠.

지불 증명 없이, 혹은 엉뚱한 증명을 담아 요청하면 어떻게 될까요? 서버는 다시 402를 던지면서 이유를 알려줍니다.

{
  "x402Version": 2,
  "error": "No matching payment requirements",
  "resource": { "url": "http://localhost:4021/weather" }
}

에러 메시지가 accepts와 함께 돌아오기 때문에 클라이언트는 무엇이 어긋났는지 알고 다시 시도할 수 있습니다. 사람이 오류 화면을 읽고 판단하는 대신, 기계가 구조화된 응답을 보고 스스로 고쳐 잡는 방식이죠.

서버는 한 줄, 클라이언트는 한 함수

x402가 스스로 내건 목표 중 하나는 통합 비용을 극단적으로 낮추는 것입니다. 서버에는 미들웨어 한 줄, 클라이언트에는 함수 한 번이면 충분해야 한다는 겁니다. 실제로 그런지 Bun과 Hono로 확인해보겠습니다.

bun add @x402/core @x402/evm @x402/hono hono

서버 코드는 이렇게 생겼습니다.

import { Hono } from "hono";
import { paymentMiddleware, x402ResourceServer } from "@x402/hono";
import { ExactEvmScheme } from "@x402/evm/exact/server";
import { HTTPFacilitatorClient } from "@x402/core/server";

// 검증과 정산을 대신 처리해줄 퍼실리테이터
const facilitatorClient = new HTTPFacilitatorClient({
  url: "https://x402.org/facilitator",
});

const app = new Hono();

app.use(
  paymentMiddleware(
    {
      "GET /weather": {
        accepts: [
          {
            scheme: "exact",
            price: "$0.001", // 달러 표기로 적으면 체인 단위로 환산됨
            network: "eip155:84532", // Base Sepolia 테스트넷
            payTo: "0x209693Bc6afc0C5328bA36FaF03C514EF312287C",
          },
        ],
        description: "Weather data",
        mimeType: "application/json",
      },
    },
    new x402ResourceServer(facilitatorClient).register(
      "eip155:84532",
      new ExactEvmScheme(),
    ),
  ),
);

// 결제가 확인된 요청만 이 핸들러까지 도달함
app.get("/weather", (c) => c.json({ weather: "sunny", temperature: 70 }));

export default { port: 4021, fetch: app.fetch };

핵심은 마지막 핸들러가 결제에 대해 아무것도 모른다는 점입니다. 날씨 데이터를 돌려주는 평범한 코드 그대로죠. 결제 여부를 가르는 일은 전부 미들웨어가 앞에서 처리하고, 통과한 요청만 핸들러까지 내려옵니다. 기존 API에 유료화를 얹을 때 비즈니스 로직을 건드리지 않아도 되는 이유입니다.

참고로 예제에 적은 https://x402.org/facilitator는 테스트넷 전용입니다. 실제로 돈을 받으려면 메인넷을 지원하는 퍼실리테이터로 바꿔야 하는데, 앞서 이야기한 Coinbase CDP를 쓴다면 이 부분만 갈아 끼우면 됩니다.

import { createFacilitatorConfig } from "@coinbase/x402";

const facilitatorClient = new HTTPFacilitatorClient(
  createFacilitatorConfig(process.env.CDP_API_KEY_ID, process.env.CDP_API_KEY_SECRET),
);

미들웨어 설정도 핸들러도 그대로 두고 이 몇 줄만 바뀝니다. 퍼실리테이터가 갈아 끼울 수 있는 부품으로 설계된 덕분이죠.

클라이언트 쪽은 fetch를 감싸는 방식입니다.

import { x402Client, wrapFetchWithPayment } from "@x402/fetch";
import { ExactEvmScheme } from "@x402/evm/exact/client";
import { privateKeyToAccount } from "viem/accounts";

const signer = privateKeyToAccount(process.env.EVM_PRIVATE_KEY as `0x${string}`);

const client = new x402Client();
client.register("eip155:*", new ExactEvmScheme(signer));

// 402를 만나면 알아서 결제하고 재요청하는 fetch
const fetchWithPayment = wrapFetchWithPayment(fetch, client);

const response = await fetchWithPayment("http://localhost:4021/weather");
console.log(await response.json());

wrapFetchWithPayment로 감싼 fetch는 402를 만나면 가격표를 읽고, 지갑으로 서명하고, PAYMENT-SIGNATURE를 붙여 다시 요청하는 일을 알아서 처리합니다. 호출하는 쪽 코드에는 402라는 단어조차 등장하지 않죠. 에이전트 입장에서는 그냥 데이터를 가져오는 평범한 요청인데 중간에 결제가 조용히 끼어드는 셈입니다.

여기서 짚고 넘어갈 점이 있습니다. 클라이언트가 개인 키를 직접 들고 서명한다는 것은 지갑 관리 책임이 고스란히 에이전트 쪽에 남는다는 뜻인데요. 키가 유출되면 API 키 유출과는 비교가 안 되는 피해로 이어집니다. 그래서 실제 운영에서는 에이전트에게 소액만 담긴 전용 지갑을 쥐여주는 식으로 노출 범위를 제한하는 게 일반적입니다.

스킴과 네트워크를 나눈 이유

x402를 읽다 보면 scheme과 network가 늘 짝으로 등장합니다. 굳이 두 개로 나눈 데는 이유가 있는데요.

스킴(scheme)은 돈이 움직이는 논리적인 방식입니다. 지금 표준에 들어 있는 exact는 정해진 금액을 정확히 옮기는 방식이죠. 기사 한 편을 읽는 데 1달러, API 한 번 호출에 0.001달러처럼 값이 미리 정해진 경우입니다.

반면 upto는 상한선까지 쓴 만큼만 받는 방식입니다. 왜 이런 게 필요한지는 LLM을 떠올리면 바로 이해되는데요. 토큰을 몇 개나 생성할지는 응답을 만들어봐야 알잖아요. 요청 전에는 “최대 0.05달러까지”만 약속해두고, 끝난 뒤 실제 사용량으로 정산하는 것이죠. 사용량 기반 과금이 흔한 AI 시대에 딱 맞는 방식입니다.

네트워크(network)는 그 방식이 실제로 구현되는 무대입니다. 같은 exact라도 이더리움 계열에서 구현하는 방법과 Solana에서 구현하는 방법은 완전히 다르거든요. 그래서 클라이언트와 퍼실리테이터는 (scheme, network) 쌍 단위로 지원 여부를 밝힙니다. 앞선 예제에서 register("eip155:84532", new ExactEvmScheme())라고 쓴 게 정확히 이 짝을 등록하는 코드였고요.

이렇게 나눠두면 새로운 체인이 등장해도 스킴은 그대로 두고 구현만 추가하면 됩니다. 반대로 새로운 과금 방식이 필요하면 스킴을 하나 추가해서 여러 체인에 퍼뜨릴 수 있고요. 표준이 특정 체인에 묶이지 않게 만드는 장치입니다.

Cloudflare가 합류한 자리

여기서 이야기가 흥미로워집니다. 제가 Cloudflare Pay Per Crawl을 다룰 때만 해도 그건 Cloudflare 혼자만의 실험처럼 보였는데요. 지금은 x402 표준 안에 cloudflare:402라는 네트워크 식별자와 batch-settlement 스킴이 정식으로 들어가 있습니다.

이 스킴이 재밌는 이유는 블록체인을 쓰지 않기 때문입니다. 크롤러는 요청마다 “이 금액을 내겠다”는 약속에 서명해서 보내고, 콘텐츠를 즉시 받아갑니다. 실제 정산은 나중에 Cloudflare가 모아서 처리하고요. 매번 체인 확정을 기다리면 크롤링 속도가 죽어버리니, 신용을 담보로 먼저 통과시키고 나중에 몰아서 청구하는 방식을 택한 것이죠. Cloudflare가 기록상 판매자(Merchant of Record)로서 크롤러 운영사에 청구하고 사이트 소유자에게 수익을 나눠주는 구조입니다.

그럼 이 약속에 서명한 게 정말 그 크롤러가 맞는지는 어떻게 확인할까요? 여기서 Web Bot Auth가 등장합니다. 크롤러는 자신의 공개 키를 .well-known 경로에 올려두고, 매 요청을 RFC 9421의 HTTP 메시지 서명으로 서명합니다. 서버는 Signature-Agent 헤더가 가리키는 곳에서 공개 키를 가져와 전자 서명을 검증하고요.

블록체인 지갑으로 결제하는 흐름과 봇 신원 인증으로 결제하는 흐름이 같은 프로토콜 안에서 나란히 굴러가는 셈입니다. x402가 스킴과 네트워크를 분리해둔 덕분에 가능한 일이죠. “네트워크”가 꼭 블록체인일 필요가 없다는 걸 Cloudflare 사례가 보여줍니다.

Cloudflare의 발은 여기서 더 깊이 들어갑니다. 2026년 7월에는 자사가 보호하는 웹 페이지, 데이터셋, API, MCP 도구에 값을 매길 수 있는 Monetization Gateway를 내놓으면서 정산을 x402로 처리한다고 밝혔습니다. 한 달 뒤에는 에이전트에게 지갑을 쥐여주는 Cloudflare Wallets를 공개했고요. 사람이 자금을 넣어두는 계정 지갑과 에이전트가 API 키로 쓰는 가상 지갑을 나누고, 가상 지갑에는 지출 한도를 걸 수 있게 했습니다. 파는 쪽과 사는 쪽을 한꺼번에 깔고 있는 셈이죠. 다만 둘 다 아직 대기 명단이나 예고 단계라 실제로 돈이 오가는 모습을 보려면 조금 더 기다려야 합니다.

MCP 서버에 지갑 달기

에이전트 이야기로 돌아와 보겠습니다. MCP는 LLM에게 도구를 쥐여주는 프로토콜인데요. x402와 MCP를 붙이면 “유료 도구”라는 게 성립합니다.

동작은 단순합니다. MCP 서버가 도구 호출을 받으면 대상 API에 요청을 보내는데, 그 API가 402를 돌려주면 지갑으로 결제하고 다시 요청해서 결과를 가져옵니다. 앞서 본 wrapFetchWithPayment를 MCP 서버 안에 심어두면 됩니다. LLM이 보는 건 평범한 도구 하나지만, 그 뒤에서는 요청마다 소액 결제가 일어납니다.

이 조합이 그리는 그림은 꽤 급진적입니다. 지금까지 에이전트가 쓸 수 있는 도구는 사람이 미리 계약하고 키를 꽂아둔 것뿐이었는데요. x402를 지원하는 API라면 에이전트가 처음 보는 서비스에도 바로 접근할 수 있게 됩니다. 사람의 승인 없이 예산 안에서 필요한 데이터를 사 오는 것이죠.

물론 이건 그대로 위험이기도 합니다. 에이전트가 잘못 판단해서 필요 없는 호출을 반복하면 그만큼 돈이 빠져나가니까요. 사람 손이 닿지 않는 자율성은 통제 장치와 함께 와야 한다는 점에서, 에이전트를 어떻게 감독할 것인가라는 질문이 여기서도 똑같이 반복됩니다.

아직은 이른 이야기

여기까지 읽으면 꽤 그럴듯해 보이지만, 저는 조금 거리를 두고 보는 편입니다. 실제 채택 상황은 홍보 문구만큼 화려하지 않거든요.

우선 거래량 지표를 곧이곧대로 믿기 어렵습니다. x402 위에서 수천만 건의 거래가 오갔다는 수치가 돌아다니지만, 반복 거래와 테스트성 트래픽을 걷어내고 나면 실제 상거래로 볼 만한 규모는 훨씬 작다는 분석이 여러 곳에서 나왔습니다. 숫자가 크다고 해서 그만큼의 시장이 형성됐다는 뜻은 아닙니다.

공개된 x402 엔드포인트를 운영하는 곳도 아직은 AI 인프라나 데이터 피드 같은 특정 영역에 몰려 있고, 대부분 시범 운영에 가깝습니다. 보안 측면에서도 주요 감사 기관의 정식 감사를 거치지 않은 상태고요. 실제로 앞서 살펴본 문서에도 Solana에서 같은 결제 트랜잭션을 여러 번 제출해 한 번의 결제로 여러 리소스를 받아내는 중복 정산 취약점과 그 대응책이 명시돼 있는데, 표준이 아직 이런 구멍을 하나씩 메워가는 단계라는 뜻입니다.

그럼에도 눈여겨볼 이유는 있습니다. Visa와 Mastercard가 스테이블코인 결제 표준의 창립 멤버로 들어갔고, Cloudflare는 자기 인프라를 하나의 네트워크로 등록했으며, 표준 자체는 Linux Foundation의 중립 지대로 옮겨갔거든요. 기술이 아니라 이해관계자 구성이 달라졌다는 게 이전의 소액 결제 시도들과 가장 다른 대목입니다.

같은 회사들이 화폐 쪽에서도 움직이고 있습니다. 2026년 6월 Open USD라는 스테이블코인 컨소시엄이 140여 개 회사와 함께 공개됐는데, Visa, Mastercard, American Express, Stripe, Google, Shopify, Cloudflare, Coinbase가 여기에도 나란히 이름을 올렸습니다. x402가 기계끼리 결제 대화를 나누는 규칙을 정하는 층이라면, 이쪽은 그때 오가는 돈 자체를 만드는 층인 셈이죠. 같은 진영이 위아래 두 층을 동시에 깔고 있다는 점은 기억해둘 만합니다.

마치며

지금까지 x402가 HTTP 402 위에 무엇을 얹었는지 살펴봤습니다. 세 개의 헤더로 가격표와 지불 증명과 정산 결과를 주고받고, 퍼실리테이터에게 블록체인의 복잡함을 몰아주고, 스킴과 네트워크를 분리해서 새로운 결제 방식과 새로운 체인을 각각 따로 확장할 수 있게 만든 설계였죠.

개인적으로 가장 인상적이었던 건 새 프로토콜을 만들지 않았다는 점입니다. 30년 묵은 상태 코드와 헤더, 그리고 이미 표준화된 서명 규격을 조합해서 결제라는 완전히 새로운 기능을 얹었으니까요. 웹 표준이 이렇게 오래 버티는 이유를 다시 확인한 기분입니다.

물론 이 실험이 자리를 잡을지는 아직 모릅니다. 소액 결제는 웹 역사에서 수없이 시도됐다가 매번 실패한 분야거든요. 다만 이번에는 AI 에이전트라는, 사람과 달리 결제 양식 앞에서 멈춰 설 수밖에 없는 새로운 사용자가 등장했다는 게 다릅니다. 여러분의 API에 402를 붙일 날이 올지, 아니면 이번에도 402가 다시 예약석으로 돌아갈지 지켜보는 재미가 있겠네요. 🤔

더 자세한 내용은 x402 공식 문서를 참고하세요.