지금 인터넷에서 뭔가를 사려면 사람이 직접 카드번호 입력하고, 계정 만들고, 구독 신청해야 합니다. 이건 철저히 "사람이 브라우저 앞에 앉아있다"는 전제로 만든 구조예요. AI 에이전트나 봇이 자동으로 API를 호출하면서 건당 0.01달러씩 내야 하는 상황에선 완전히 맞지 않습니다.
사실 HTTP 스펙에는 처음부터 402 Payment Required라는 상태코드가 예약되어 있었는데, "나중에 쓰자"고 30년 넘게 방치되어 있었습니다. x402는 이걸 드디어 실제로 작동하게 만든 겁니다.
실제 흐름을 비유로
편의점에 비유하면 이렇습니다:
손님(클라이언트)이 편의점(서버)에 들어가서 물건을 집습니다. 계산대에서 점원이 "3,000원입니다"라고 말합니다(402 응답 + 결제 조건). 손님이 정확히 3,000원짜리 수표에 서명해서 건넵니다(서명된 결제 페이로드). 점원이 수표의 서명을 확인하고, 은행(facilitator)에 전화해서 "이거 진짜 맞죠?" 확인한 뒤 물건을 줍니다.
핵심은 계정도 없고, 회원가입도 없고, 카드 등록도 없다는 겁니다. 그냥 돈(서명)을 HTTP 헤더에 담아 보내면 끝입니다.
기술적으로 단계별
1단계 — 요청과 거절
클라이언트가 GET /api/wea
ther를 호출합니다. 서버는 돈 안 낸 요청이니까 HTTP 402를 반환하면서, 헤더에 결제 조건을 담습니다. 여기에는 얼마를 내야 하는지(amount), 어디로 보내야 하는지(payTo 주소), 어떤 체인/토큰을 받는지(network, asset), 어떤 결제 방식인지(scheme)가 들어있습니다.
2단계 — 클라이언트의 서명
클라이언트는 이 조건을 보고, 자기 지갑의 프라이빗 키로 "이 주소에 이 금액을 보내겠다"는 메시지에 서명합니다. EVM의 경우 ERC-3009 표준을 사용하는데, 이게 특별한 이유는 서명만 하고 실제 전송은 안 한다는 점입니다. 가스비도 안 들고, 블록체인에 아직 아무것도 기록되지 않습니다. 그냥 "나는 이 돈을 보낼 의사가 있다"는 암호학적 증명만 만드는 거예요.
3단계 — 재요청
클라이언트가 같은 GET /api/weather를 다시 보내는데, 이번엔 X-PAYMENT 헤더에 서명된 페이로드를 붙입니다. 기존 HTTP 요청 구조를 전혀 바꾸지 않고, 헤더 하나만 추가한 겁니다.
4단계 — 검증과 정산
서버는 이 서명을 직접 검증할 수도 있고, facilitator에게 넘길 수도 있습니다. Facilitator는 서명이 유효한지, 잔액이 충분한지 확인한 뒤 실제 온체인 전송을 실행합니다. 검증 통과하면 서버가 리소스를 응답으로 돌려줍니다.
비트코인에서 왜 까다로운지
EVM에서는 ERC-3009 덕분에 "서명만 하고, 실행은 나중에 제3자가" 하는 게 가능합니다. 토큰 컨트랙트가 이 기능을 내장하고 있으니까요.
비트코인은 계정 모델이 아니라 UTXO 모델입니다. 잔고라는 개념이 없고, 소비 안 된 출력(UTXO)의 합이 잔액이에요. "내가 나중에 보내겠다"는 서명을 만들려면 특정 UTXO를 지정해야 하는데, 그 사이에 해당 UTXO가 다른 곳에 쓰이면 서명이 무효화됩니다. EVM처럼 깔끔한 "서명 → 위임 실행" 패턴을 그대로 가져올 수가 없는 거죠.
그래서 x402b 같은 프로젝트가 Lightning 채널의 invoice/preimage 구조나, PSBT(Partially Signed Bitcoin Transaction) 같은 비트코인 고유 메커니즘으로 동일한 흐름을 구현하려고 시도하고 있는 상황입니다
x402 에 대한 간단한 ai 설명