1997년에 만들어지고 30년 동안 단 한 번도 표준 사용 사례가 정의된 적이 없는 HTTP 상태코드가 있습니다. 바로 HTTP 402 Payment Required 입니다.
그런데 이게 2025년 5월 코인베이스가 x402 프로토콜을 발표하면서 갑자기 살아났습니다. 출시 약 1년 만에 누적 거래 1.65억 건을 돌파했고, 구글 AP2, Cloudflare, 스트라이프까지 줄줄이 합류 중입니다.
최근 회사에서 사업 아이디어를 제안할 일이 있었는데, 그 과정에서 이 친구를 처음 만났습니다. 처음엔 “결제 표준 하나” 정도로만 알아두고 넘어가려 했는데요.. “30년을 잠들어 있다가 왜 지금?”이라는 의문 하나에서 시작해서, 결국 AI 에이전트 결제 인프라 전반까지 한 달 넘게 파게 되었습니다.
정리해두지 않으면 휘발될 것 같아서 시리즈로 남기려 합니다!!
바로 본론으로 들어가겠습니다!!
402 상태코드?
200 OK, 404 Not Found는 웬만한 개발자면 누구나 알고 있고, 좀 더 들어가면 502 Bad Gateway 정도까지는 익숙하실 텐데요. 그런데 402라는 코드는 잘 들어보신 적 없으실 겁니다.
HTTP/1.1을 정의한 RFC 2616(1999)에는 이 코드에 대해 이렇게만 적혀 있습니다.
This code is reserved for future use.
“미래를 위해 예약됨.” 이게 다입니다. 어떤 상황에서 응답해야 하는지, 응답 본문에 뭐가 들어가야 하는지에 대한 정의도 없이, 이름만 “Payment Required”로 박혀 있는 상태로 30년간 유지됐습니다.
다른 상태코드들이 인터넷 인프라를 굴리는 핵심 부품이 되는 동안, 402만 유독 잠들어 있었던 셈입니다..
마이크로페이먼트의 실패
그렇다고 사람들이 마이크로페이먼트 자체를 안 건드린 건 아닙니다. 오히려 그 반대였습니다. 1990년대부터 마이크로페이먼트는 IT 업계의 단골 화두였고, 매 시대마다 누군가 시도했다가 실패하기를 반복했습니다.
| 연도 | 시도 | 결과 |
|---|---|---|
| 1994 | FirstVirtual | 카드 고정 수수료 벽 (1센트 결제 비전이 건당 29센트 구조에 막힘) |
| 1995 | CyberCash (1996 CyberCoin) | 채택 실패 |
| 1996 | Millicent (DEC) | 채택 실패 |
| 1999 | W3C 마이크로페이먼트 워킹그룹 | 표준화 실패 |
| 1999~2001 | Flooz | 닷컴 버블과 함께 종료 |
| 2016~2018 | Bitcoin Lightning Network | 부분 성공 |
| 2017~2019 | Brave BAT / Brave Rewards | 광고 영역만 |
| 2025.5 | Coinbase x402 V1 | 첫 폭발적 채택 |
좋은 회사들이 좋은 자본을 들고 30년간 시도했는데도 안 됐다면, 단순히 “기술이 부족했다”로는 설명이 안 됩니다. 진짜 이유가 따로 있다는 뜻이겠죠?
실패한 시도들을 분류해보면 결국 세 가지 벽에 막혀 있었습니다.
30년간 안 된 이유
1. 카드 수수료의 수학적 하한선
카드 결제 비용은 크게 두 부분으로 구성됩니다. 정률 수수료(interchange + 네트워크 수수료 + 처리사 마진을 합산하면 통상 1.8~3.5%)와 건당 고정 처리비입니다. (한국에서는 정률 수수료로만 존재합니다.) Stripe 공식 요금 기준으로 쓰면 2.9% + $0.30/건이 표준인데, 여기서 핵심은 $0.30 고정비 성분입니다.
결제 금액이 클 때는 정률 부분(2.9%)이 지배적이어서 고정비 영향이 희석됩니다. 하지만 결제 금액이 극도로 작아지는 마이크로페이먼트 영역에서는 이 $0.30 고정비가 거래 금액 대비 압도적인 비중을 차지합니다.
$1 결제에서 이미 고정비만으로 수수료 비율이 30%에 달하고, $0.10 결제는 300% 입니다. 실제 Stripe 요금(2.9% + $0.30)을 적용하면 $1 결제의 총 수수료는 $0.329로 약 33%에 달합니다. 마이크로페이먼트(건당 0.001~0.1달러 수준)는 카드망 위에서는 수학적으로 성립할 수 없는 영역이었던 것 같습니다. 1994년 FirstVirtual부터 2001년 Flooz까지, 카드망을 기반으로 한 시도들은 전부 이 벽에 부딪혔습니다.
한국은?
그러면 한국은 어떨까요?
한국 온라인카드결제에서 PG사가 가맹점에게 받는 수수료는 대다수 영세·중소 가맹점 기준 2~3% 정도이고, 신규·일반 가맹점은 3.2~3.5% 수준까지 올라갑니다(통상 2~3.5%).
한국에서도 당연히 경제적 유인도 없지만 다른 문제들도 존재했습니다.
- 최소결제금액 제한 — 카드사가 금액을 이유로 결제를 거부하는 것은 여신전문금융업법(의무수납제)상 금지되어 원칙적으로 1원도 결제가 가능합니다. 다만 PG/VAN 단에서는 건당 처리비 문제로 통상 100원(일부 PG는 기본값 1,000원, 요청 시 하향 가능)을 기술적 최소결제금액으로 설정해 두는 경우가 많아, 사실상 1~100원대 마이크로페이먼트는 이 기술적 하한 아래여서 카드 인프라 위에서 다루기 어려웠습니다.
- PG사 통합 수수료 — 온라인 결제에서 가맹점이 PG사에 내는 수수료는 통상 2~3.5% 수준입니다. 이 요율 안에는 카드사 정산 원가(영세 가맹점 우대수수료는 2026년 기준 약 0.4%)와 PG사 마진이 한 층으로 함께 들어 있습니다. 즉 카드사 원가 위에 PG 운영비가 얹혀 단일 요율로 청구되는 구조라, 마이크로페이먼트 입장에서는 이 통합 요율만으로도 건당 부담이 너무 컸습니다.
결국 한국 카드 인프라도 마이크로페이먼트에 대한 구조적 벽이 존재했던 것 같습니다. 글로벌은 “$0.30 고정비 하한선”이라는 명확한 벽이었고, 한국은 “최소결제금액 + PG 오버헤드”라는 비슷한 장벽이 있었습니다. 형태가 달랐을 뿐, 마이크로페이먼트가 성립 불가능한 영역이 존재한다는 사실은 동일했습니다.
2. 결제 마찰은 인간 심리의 한계
1999년 W3C가 마이크로페이먼트 워킹그룹을 만들었습니다. 표준화 자체는 꽤 잘 진행됐는데, 실제로 안 쓰였습니다.
“이 페이지를 보려면 50원 결제하시겠습니까?”
이 버튼의 문제점은 뭘까요?
누를 때마다 의사결정 비용이 발생하고, 그 비용이 콘텐츠 가치보다 커집니다. 결제 한 번에 0.5초만 망설여도, 마이크로페이먼트 모델은 그 자리에서 무너집니다.
3. 결제 표준의 부재
제가 생각한 가장 큰 문제입니다.
HTTP 402가 “예약됨”으로만 남아 있었던 이유와 같습니다. 서버가 “0.5원 내세요”라고 응답해도, 클라이언트가 어떻게 결제해야 하는지에 대한 약속이 없었습니다. 결제 수단도 제각각, 통화도 제각각, 검증 방식도 제각각이었습니다.
표준이 없으니 각 서비스가 자체 결제 로직을 만들어야 했고, 그 비용이 마이크로페이먼트의 단가를 훨씬 초과했습니다.
2025년에 살아난 진짜 이유 — 3가지 임계점
그런데 왜 하필 2025년에 갑자기 살아났을까요?
자료를 파보니 단순한 우연이 아니라, 3가지 인프라가 임계점을 넘었기 때문이었습니다.
1. 스테이블코인 시총 2,000억 달러 돌파
USDC와 USDT 합산 시총이 2025년 기준 2,000억 달러를 넘어섰고 2026년 현재 약 2,670억 달러까지 성장했습니다. 결제 수단으로서의 신뢰가 임계점을 넘었다는 의미입니다. 제가 생각하기에는 디지털 화폐의 신뢰성이 생긴 순간이라고 생각합니다.
2. L2 블록체인의 가스비, 한 자릿수 센트
Base, Arbitrum 같은 이더리움 L2가 안정화되면서 단순 토큰 전송 가스비가 한 자릿수 센트(USDC 전송 기준 대략 2~5센트, 단순 전송이 한산할 때는 1센트 미만)까지 떨어졌습니다. 메인넷에서 수십 센트~수 달러였던 전송이 L2에서 센트 단위로 내려오면서, 건당 수 센트 수준의 초소액 결제도 수익이 남는 환경이 처음 만들어졌습니다.
3. AI 에이전트의 등장
이게 가장 결정적이었습니다.
사람이 못 누르던 그 결제 버튼을, AI 에이전트는 망설임 없이 누릅니다. 30년간 마이크로페이먼트가 실패한 원인이 “인간의 결제 마찰”이었다면, AI는 그 마찰이 0인 첫 번째 결제 주체인 것입니다.
세 가지 장벽이 어떻게 동시에 무너졌는지 정리해보면 이렇습니다.
결국 30년을 못 넘은 건 기술이 아니라 결제 주체였습니다.
마이크로페이먼트라는 초소액, 초고빈도의 결제를 받기 위해서는 결제 주체가 중요했었던 것 같습니다.
x402 작동 방식
그럼 x402가 정확히 어떻게 30년 묵은 402의 빈자리를 채웠을까요? 실제 흐름을 한번 따라가보겠습니다!
여기서 예시는 이더리움 기반 EIP 표준을 예시로 사용합니다.
먼저 클라이언트(AI 에이전트)가 일반 요청을 보냅니다.
GET /api/weather/seoul HTTP/1.1
Host: api.example.com
서버가 402 응답을 돌려줍니다. 30년 만에 처음 진짜로 쓰이는 순간입니다. x402 표준에서는 결제 요구사항이 402 응답 본문(JSON)으로 내려옵니다(원조 V1 기준. 최신 V2에서는 Base64로 인코딩된 PAYMENT-REQUIRED 헤더로 전달됩니다).
HTTP/1.1 402 Payment Required
Content-Type: application/json
{
"x402Version": 1,
"error": "X-PAYMENT header is required",
"accepts": [
{
"scheme": "exact",
"network": "base-sepolia",
"maxAmountRequired": "10000",
"asset": "0x036CbD...F3dCF7e",
"payTo": "0x209693...312287C",
"maxTimeoutSeconds": 60,
"resource": "https://api.example.com/api/weather/seoul"
}
]
}
AI 에이전트는 이 정보를 보고 자기 지갑에서 결제 서명(EIP-3009)을 만들어서, 같은 요청에 서명 헤더만 추가해서 다시 보냅니다.
GET /api/weather/seoul HTTP/1.1
Host: api.example.com
X-Payment: 0x... (signed payment)
서버는 Facilitator라는 검증 중개자에게 서명을 검증·정산시키고, 통과하면 200 응답으로 데이터를 돌려줍니다.
전체 흐름을 시퀀스로 그려보면 이렇습니다.
전체가 1초 미만에 끝납니다!! 처음 이 흐름을 따라가봤을 때 든 생각은 하나였습니다.
“HTTP 위에 결제 레이어가 이렇게 깔끔하게 얹힐 수 있는 거였구나..”
30년을 기다린 이유가 있었던 것 같습니다.
이게 왜 중요하냐면, AI 에이전트도 결국 무엇에 서명하는지 정확히 알아야 하기 때문입니다. 피싱 공격이나 악의적인 서버가 “0.005 USDC”라고 해놓고 실제로는 “500 USDC”를 차감하는 서명을 받아내는 걸 막아주는 표준 장치입니다.
x402의 결제 서명은 기본적으로 EIP-712 + EIP-3009 조합으로 만들어집니다(USDC처럼 transferWithAuthorization을 네이티브 지원하는 토큰의 권장 경로). 하나(EIP-3009 또는 Permit2)는 가스리스 전송을 가능하게 하고, 하나(EIP-712 타입드 데이터 서명)는 그 서명이 안전하게 검증 가능하도록 만드는 역할입니다. EIP-3009를 지원하지 않는 토큰은 Permit2를 쓰는 폴백 경로도 사양에 정의돼 있습니다.
Facilitator
x402 시퀀스에 등장한 Facilitator를 좀 더 깊이 들여다보겠습니다. 지금까지는 “검증 중개자” 정도로만 설명했는데, 사실 x402가 카드망 PG사와 본질적으로 다른 지점이 여기에 있습니다.
기존 카드 결제 PG사(예: Stripe, Toss Payments)는 자금을 들고 있는 수탁 구조입니다.
비수탁(non-custodial)이라는 게 핵심입니다. Facilitator는 길목에서 서명을 받아서 블록체인에 제출하는 역할만 합니다. 자금이 Facilitator를 거치지 않아요.
만약 Facilitator가 악의적으로 행동해도 다음과 같은 안전장치들이 있습니다.
- 서명에 수신자 주소가 명시되어 있어서 다른 주소로 보낼 수 없음
- 서명에 금액이 명시되어 있어서 더 많이 송금할 수 없음
- 서명에 nonce와 만료시간이 있어서 같은 서명을 재사용할 수 없음
기존 PG사 모델에서 “PG사를 신뢰해야 한다”는 전제가 있었다면, x402는 “Facilitator를 신뢰할 필요가 없다”는 구조입니다. 길목에 서지만 자금을 못 만지는 구조 — 이게 결제 인프라 신뢰 모델의 근본적인 전환이라고 체감했습니다..
HTTP 멱등성 충돌과 nonce
기술적으로 한 가지 더 흥미로운 지점이 있습니다. HTTP는 메서드별로 멱등성(idempotent)과 안전성(safe)을 구분합니다. GET은 ‘안전한(safe)’ 메서드라 같은 요청을 100번 보내도 결과가 같고 서버 상태를 바꾸는 부수효과가 없어야 합니다. 반면 결제처럼 상태를 바꾸는 동작은 보통 POST로 보내는데, POST는 애초에 멱등하지 않은 메서드입니다.
그런데 결제는 멱등하면 안 됩니다. 한 번만 차감되어야 하니까요. 같은 결제 요청을 100번 보내면 100번 차감되어야 할까요, 1번만 차감되어야 할까요? 둘 다 답이 아닌 것 같습니다.
x402는 이 충돌을 EIP-3009의 nonce + 만료시간으로 풉니다.
- 모든 결제 서명에는 고유한 nonce가 들어감
- 같은 nonce는 블록체인이 한 번 처리하면 거부 (재사용 불가)
- 만료시간이 지나면 그 서명은 영구 무효
같은 결제 요청을 네트워크 이슈로 두 번 보내도, 두 번째는 블록체인이 자동으로 거부합니다. 이게 replay attack 방어의 핵심이기도 합니다. 누가 중간에서 서명을 가로채서 재사용하려고 해도 nonce 중복으로 막힙니다.
HTTP 위에 결제를 얹는다는 게 단순한 작업이 아닌데, x402는 이 부분을 의외로 깔끔하게 처리했다는 게 인상 깊었습니다!!
채택 속도
새 결제 표준은 보통 채택까지 10년 이상이 걸립니다. 마그네틱 스트라이프 카드는 1960년대에 발명돼 1980~90년대에 카드·단말기에 보편 탑재됐지만 일상 결제의 주류가 된 건 2000년대였고, EMV 칩카드는 1990년대 중반에 사양이 나왔지만 미국 일반 도입은 2015년(책임 전환 시점)이었습니다.
그런데 x402는 출시 1년 만에 글로벌 거인들이 줄줄이 합류했습니다.
| 시점 | 사건 |
|---|---|
| 2025.5 | Coinbase x402 V1 출시 |
| 2025.9 | Google AP2 (Agent Payments Protocol) 발표 |
| 2025.12 | x402 V2 — 사양 안정화 |
| 2026.3 | x402 ERC-20 전면 지원 |
| 2026.3 | Stripe + Tempo MPP — 스테이블코인 기반 멀티레일 결제 표준 출시 |
| 2026.4 | 누적 거래 1.65억 건 |
카드 진영도 같은 시기 잇따라 자기 표준을 내놓았습니다. Mastercard Agent Pay는 2025년 4월(x402 V1보다 오히려 이른 시점), Visa TAP(Trusted Agent Protocol)는 2025년 10월에 나왔습니다. 다만 Mastercard는 x402 등장 전부터 움직였다는 점에서, 단순한 위협 대응이라기보다 업계 전반이 같은 방향으로 수렴하고 있다는 신호에 가깝습니다.
진영별로 그려보면 지금 결제 표준 시장이 얼마나 빠르게 분화되고 있는지 보이는 것 같습니다.
이 정도 속도면 “AI 에이전트 결제”라는 시장 자체가 향후 5년 안에 자리잡는다는 의미로 읽힙니다.
1편을 마치며
30년 만에 새 결제 표준이 깔리는 걸 직접 본다는 게 흔한 일이 아닌 것 같습니다. 90년대 카드망 인프라, 2000년대 인터넷 결제, 2010년대 모바일 페이는 각각 한 세대를 만들었던 변곡점이었습니다.
x402가 그 정도 무게감인지는 좀 더 지켜봐야겠지만, 적어도 AI 에이전트가 결제 주체가 되는 첫 번째 표준이라는 점은 분명한 것 같습니다. 그리고 그 시작점이 30년 잠들어 있던 HTTP 402였다는 게.. 개인적으로 가장 인상 깊었습니다.
정리하면 이번 글에서 얻은 통찰은 이렇습니다.
- HTTP 402는 시대를 30년 기다린 표준이었다 — 카드 수수료 하한선과 인간의 결제 마찰이 진짜 장벽
- 2025년에 살아난 건 3가지 임계점이 동시에 넘어진 결과 — 스테이블코인 시총 2,000억 달러 돌파, L2 가스비 한 자릿수 센트(단순 전송 기준), AI 에이전트 등장
- EIP-3009 + EIP-712의 조합이 가스리스 결제를 가능하게 했다 — “서명 생성”과 “트랜잭션 제출”의 분리가 30년 마찰을 우회한 기술적 핵심
- Facilitator는 길목에 서지만 자금은 못 만진다 — 비수탁 구조가 결제 신뢰 모델을 근본적으로 바꿈
- 결제 주체가 바뀌면 결제 영역 전체가 바뀐다 — 30년 실패의 원인은 “기술”이 아니라 “주체”였다
다음 글에서 이어가겠습니다!!
감사합니다!!