x402란? AI 에이전트 HTTP 스테이블코인 결제 구조와 위험
x402는 HTTP 402 응답으로 AI 에이전트가 USDC 같은 스테이블코인을 요청 단위로 결제하게 하는 개방형 프로토콜이에요. 결제 흐름, 퍼실리테이터 비용, 과지출·악성 402 위험을 정리했어요.

목차8개 섹션
핵심 요약
- x402는 HTTP 402 상태 코드와 PAYMENT-REQUIRED·PAYMENT-SIGNATURE·PAYMENT-RESPONSE 세 헤더로 요청 단위 결제를 처리하는 개방형 프로토콜이에요.
- 계정·구독·API 키 대신 지갑 서명으로 결제하며, 검증과 온체인 정산은 보통 퍼실리테이터가 대행해요.
- 2026년 7월 14일 리눅스 재단 산하 x402 재단이 40개 회원사로 공식 출범해 코인베이스에서 거버넌스가 옮겨졌어요.
- 명세는 클라이언트 측 예산 관리를 범위 밖으로 두므로 지출 한도·수신처 허용 목록은 에이전트 운영자가 직접 만들어야 해요.
- USENIX Security 2026 논문은 주요 퍼실리테이터 15곳 모두에서 보안 규칙 위반을 발견했다고 보고했어요.
x402는 웹 서버가 HTTP 402 Payment Required 응답으로 가격과 받는 주소를 알려 주면, AI 에이전트나 앱이 지갑으로 서명한 결제를 헤더에 담아 같은 요청을 다시 보내는 개방형 결제 프로토콜이에요. 계정을 만들거나 API 키를 발급받지 않아도 요청 한 번마다 USDC 같은 스테이블코인으로 값을 치를 수 있다는 점이 핵심이에요. 이 글은 2026년 10월 기준으로 공개된 x402 v2 명세와 코인베이스·클라우드플레어 개발 문서, 리눅스 재단 발표, 보안 연구를 읽고 구조와 비용, 위험을 정리했어요. 결제 프로토콜 설명이며 특정 토큰이나 서비스의 가격 전망을 다루지 않아요.
x402란? 결제를 HTTP 응답 안에 넣은 개방형 프로토콜
HTTP 402는 오래전부터 '결제 필요'라는 뜻으로 예약돼 있었지만 형식이 정해지지 않아 거의 쓰이지 않던 상태 코드예요. x402 공식 문서는 이 코드를 되살려 클라이언트에게 결제가 필요하다는 사실과 금액·통화·수신 주소를 알리고, 프로그램이 스스로 결제를 끝낼 수 있게 하는 것을 목표로 설명해요. 사람이 결제 화면을 거치지 않는 기계 간(M2M) 결제, API 호출 단위 과금, 계정 없는 소액 결제가 주요 용도예요.
x402는 코인베이스가 만들었고 클라우드플레어와 함께 재단 설립을 추진했어요. 리눅스 재단 발표에 따르면 2026년 4월 재단 설립 의향을 밝힌 뒤 2026년 7월 14일 x402 재단이 공식 운영을 시작했고, 코인베이스의 프로토콜 기여가 완료됐어요. 발표 시점 회원사는 40곳이며 AWS, 아메리칸 익스프레스, 서클, 구글, 마스터카드, 스트라이프, 비자 등이 프리미어 회원으로, 카카오페이 등이 일반 회원으로 이름을 올렸어요. 회원 참여가 곧 각 회사 서비스에서 x402 결제를 제공한다는 뜻은 아니라는 점은 구분해서 읽어야 해요.
x402 v2 명세는 구조를 세 층으로 나눠요. 결제 요구·결제 증명·정산 결과 같은 데이터 형식(Types), 결제 방식과 네트워크에 따라 달라지는 검증 논리(Logic), 그리고 HTTP·MCP·A2A처럼 메시지를 실어 나르는 전송 방식(Representation)이에요. 그래서 x402는 HTTP에서 시작했지만 AI 에이전트가 MCP 도구를 호출할 때 도구 단위로 과금하는 데도 쓰일 수 있어요.
x402 결제 흐름: 402 응답에서 정산 확인까지

x402에는 세 주체가 있어요. 유료 자원을 제공하는 리소스 서버(판매자), 자원을 요청하는 클라이언트(앱이나 AI 에이전트), 그리고 결제 검증과 블록체인 정산을 대행하는 퍼실리테이터예요. 클라우드플레어 Agents 문서는 퍼실리테이터를 선택 사항이지만 권장되는 제3자 서비스로 설명하며, 자금을 보관하지 않고 클라이언트가 미리 서명한 거래를 검증·전송한다고 적고 있어요.
- 1
클라이언트가 자원을 요청해요
에이전트가 평소처럼 GET 요청을 보내요. 이미 가격 조건을 알고 있다면 첫 요청부터 결제를 붙일 수도 있어요.
- 2
서버가 402와 PAYMENT-REQUIRED 헤더로 답해요
헤더에는 Base64로 인코딩한 JSON이 들어가요. 받을 수 있는 결제 방법 목록(accepts) 안에 스킴, CAIP-2 형식 네트워크 ID, 원자 단위 금액, 토큰 주소, 수신 주소(payTo), 결제 제한 시간이 담겨요.
- 3
클라이언트가 결제에 서명해 다시 요청해요
지갑이 조건 하나를 골라 결제 승인에 서명하고, 그 결과를 PAYMENT-SIGNATURE 헤더에 담아 같은 요청을 다시 보내요. EVM의 exact 방식에서는 EIP-3009 승인 형식에 32바이트 nonce와 유효 시작·만료 시각이 들어가요.
- 4
서버가 퍼실리테이터로 검증하고 자원을 처리해요
서버는 퍼실리테이터의 /verify로 서명과 잔액을 확인해요. 명세상 /verify는 읽기 전용이라 온체인 상태를 바꾸지 않아요. 검증이 실패하면 다시 402가 돌아와요.
- 5
정산 후 PAYMENT-RESPONSE와 함께 결과를 돌려줘요
서버나 퍼실리테이터가 /settle로 거래를 블록체인에 제출하고, 성공하면 200 응답과 함께 거래 해시가 든 PAYMENT-RESPONSE 헤더를 보내요.
명세의 예시 금액 10000은 원자 단위예요. USDC처럼 소수점 아래 6자리를 쓰는 토큰이라면 0.01 USDC에 해당하므로, 화면에 보이는 숫자를 그대로 달러 금액으로 읽으면 안 돼요. 또 명세는 기본 흐름을 검증 → 자원 처리 → 정산 순서의 authorization 방식으로 정의하지만, 자원 처리 전에 먼저 정산하는 upfront, 예치금을 먼저 잡는 escrow 흐름도 있어요. 같은 자원이 두 방식을 함께 제시하면 클라이언트는 authorization을 우선하라고 권고해요. 서비스가 실패해도 이미 돈이 빠져나간 상태를 줄이기 위한 장치예요.
기존 API 과금·카드 결제와 무엇이 다를까요
x402를 이해하는 가장 쉬운 방법은 지금 쓰는 유료 API와 비교하는 거예요. 기존 방식은 가입과 결제 수단 등록이 먼저 있고, 발급받은 API 키로 호출한 뒤 월말에 청구가 모이는 구조예요. x402는 신원 확인 대신 지갑 서명이 그 자리를 차지하고, 정산이 요청마다 또는 묶음 단위로 일어나요.
사전 준비
- 기존 API 키·구독 과금
- 회원 가입, 카드 등록, API 키 발급
- x402 결제
- 스테이블코인이 든 지갑
과금 단위
- 기존 API 키·구독 과금
- 월 구독 또는 사용량 후불 청구
- x402 결제
- 요청·도구 호출 단위 즉시 결제 또는 묶음 정산
결제 수단
- 기존 API 키·구독 과금
- 카드·계좌 이체 등 법정화폐
- x402 결제
- 주로 USDC 같은 스테이블코인(명세는 법정화폐 확장 여지를 둠)
분쟁·환불
- 기존 API 키·구독 과금
- 카드사 차지백 등 기존 절차
- x402 결제
- 프로토콜 차원의 표준 환불 절차 없음
지출 통제
- 기존 API 키·구독 과금
- 플랫폼의 한도·알림 설정
- x402 결제
- 클라이언트가 직접 구현해야 함
신원 노출
- 기존 API 키·구독 과금
- 계정 정보가 판매자에 남음
- x402 결제
- 지갑 주소와 거래 기록이 온체인에 남음
표의 마지막 두 줄이 이 글에서 가장 중요한 차이예요. 카드 결제는 금융 회사가 한도와 이상 거래 탐지를 대신 해 주지만, x402 명세는 '클라이언트 측 예산 관리'를 범위 밖이라고 명시해요. 에이전트가 무엇에 얼마를 쓸지 막는 장치는 운영자가 따로 붙여야 한다는 뜻이에요. 또 계정이 없다고 익명인 것은 아니에요. 같은 지갑으로 여러 서비스에 결제하면 거래 기록이 서로 연결될 수 있어요. AI 에이전트·스테이블코인 관련 시장 이야기를 빠르게 따라가고 싶다면 더따리 텔레그램 크립토 동향과 AI 동향에서 채널 화제를 모아 볼 수 있어요. 다만 채널 화제는 사실 확인 전의 신호이므로 공식 문서와 다시 맞춰 보세요.
결제 스킴·네트워크·퍼실리테이터 비용 읽는 법
x402에서 '스킴'은 결제를 어떻게 만들고 정산하는지에 대한 규칙이에요. 클라우드플레어 문서 기준으로 exact는 정해진 금액을 판매자 주소로 보내는 방식이고, upto는 최대 금액만 승인해 두고 실제 사용량에 따라 정산 시점에 금액을 정하는 방식이에요. x402 문서는 exact와 upto가 보통 같은 요청 안에서 바로 정산되고, batch-settlement는 승인만 먼저 확인한 뒤 나중에 묶어서 온체인으로 회수한다고 설명해요.
지원 네트워크는 문서마다 다르게 보일 수 있어요
클라우드플레어 문서는 upto를 EVM 전용으로 표기하지만, 코인베이스 CDP 퍼실리테이터 문서는 솔라나에서도 exact와 upto를 지원한다고 적고 있어요. CDP 문서가 나열한 네트워크는 Base, Polygon, Arbitrum, Monad, World, Solana와 일부 테스트넷이에요. 이렇게 문서 사이에 시차가 있기 때문에 CDP는 퍼실리테이터의 지원 목록 조회 API를 기준으로 삼으라고 안내해요. 명세에도 퍼실리테이터가 지원 스킴·네트워크를 알려 주는 GET /supported가 정의돼 있어요.
퍼실리테이터 요금은 판매자 비용이에요
2026년 10월 확인 기준 CDP 퍼실리테이터는 매월 온체인 정산 1,000건까지 무료이고, 그 뒤로는 건당 0.001달러를 받아요. 결제 검증은 항상 무료이고 요금은 결제 요청 수가 아니라 온체인 거래 수로 계산해요. batch-settlement는 여러 결제를 한 번의 온체인 거래로 회수할 수 있어 고빈도 판매자의 정산 비용을 줄이는 용도예요. 같은 문서는 CDP 퍼실리테이터가 Base와 솔라나에서만 1억 건이 넘는 거래와 2,800만 달러 규모의 결제를 처리했다고 밝히고, OFAC 제재·고위험 주소를 거르는 KYT 검사를 넣었다고 설명해요. 이 수치는 코인베이스가 자사 서비스에 대해 공개한 값이며 x402 전체 시장 규모가 아니에요.
AI 에이전트 결제의 위험: 과지출·악성 402·퍼실리테이터 결함

x402는 결제를 쉽게 만드는 대신, 결제를 막는 마찰도 함께 줄여요. 사람이 확인 버튼을 누르지 않는 구조에서는 작은 오류가 반복 결제로 커지기 쉬워요. 위험은 크게 구매자(에이전트) 쪽, 판매자·퍼실리테이터 쪽, 운영·규제 쪽으로 나눠 볼 수 있어요.
구매자 쪽: 과지출과 악성 402 응답
- 한도 없는 자동 결제: 명세가 예산 관리를 다루지 않으므로, 재시도 루프나 버그가 생기면 소액 결제가 계속 쌓일 수 있어요.
- 악성·조작된 402 응답: 서버가 부풀린 가격이나 다른 수신 주소를 PAYMENT-REQUIRED에 넣으면, 이를 그대로 따르는 에이전트는 그대로 서명해요. 웹 페이지의 숨은 지시문으로 에이전트가 엉뚱한 유료 주소를 호출하게 만드는 프롬프트 주입도 같은 범주예요.
- 결제 메타데이터 노출: 요청 URL과 설명 문자열이 판매자와 퍼실리테이터에 그대로 전달되므로, URL에 이메일·사용자 ID를 넣는 설계는 개인정보가 새는 통로가 될 수 있어요.
- 정산 대기 상태 오해: 명세의 settlement_pending 오류는 거래가 이미 전송됐지만 확인을 못 한 비종결 상태예요. 확인 없이 재시도하면 중복 결제가 될 수 있으니 거래 해시로 먼저 대조해야 해요.
판매자·퍼실리테이터 쪽: 공유 인프라의 결함
퍼실리테이터는 여러 판매자가 함께 쓰는 결제 인프라라서 결함 하나가 많은 서비스에 동시에 영향을 줄 수 있어요. USENIX Security 2026 논문은 6만 명이 넘는 판매자와 36만 명이 넘는 구매자가 쓰는 주요 퍼실리테이터 15곳을 점검해 모두에서 보안 규칙 위반을 찾았다고 보고했어요. 연구진은 대가 없이 자원을 가져가는 Free Shopping, 퍼실리테이터 자산 탈취, 서비스 거부, 대납 가스 남용이라는 네 가지 공격 경로를 제시했고, 책임 있는 공개 후 코인베이스를 포함한 당사자들이 완화 조치를 적용했다고 밝혔어요. 이미 고쳐진 문제도 있지만, 퍼실리테이터가 많아질수록 구현 품질 차이가 위험이 된다는 점은 여전히 유효해요.
운영·규제 쪽: 되돌리기 어려운 결제와 관할 차이
온체인으로 정산된 스테이블코인은 카드 결제처럼 표준화된 차지백 절차가 없어요. 스테이블코인 자체의 디페그·발행사 위험도 그대로 따라와요. 또 스테이블코인 결제와 세금 처리 규칙은 국가마다 달라서, 프로토콜이 개방형이라는 사실이 특정 관할에서 사용이 허용된다는 뜻은 아니에요. 한국 거주자는 해외 스테이블코인 확보 경로와 과세 기준을 별도로 확인해야 해요.
에이전트에 x402 지갑을 연결하기 전 점검 순서
x402 결제를 에이전트에 붙이는 일은 결제 버튼을 프로그램에 넘겨주는 일과 같아요. 아래 순서는 개발자와 서비스 운영자가 실제 자금을 연결하기 전에 확인할 최소한의 항목이에요.
- 1
테스트넷에서 먼저 흐름을 확인해요
Base Sepolia 같은 테스트넷과 테스트용 USDC로 402 응답, 서명, 정산, PAYMENT-RESPONSE 확인까지 한 번씩 돌려 봐요. 원자 단위 금액 변환이 맞는지 이 단계에서 꼭 검증해요.
- 2
결제 전용 지갑과 잔액 상한을 분리해요
주 자금 지갑과 에이전트 지갑을 나누고, 에이전트 지갑에는 잃어도 감당할 수 있는 금액만 넣어요. 서명 키는 에이전트가 직접 읽을 수 없는 곳에 두는 편이 안전해요.
- 3
1회·일일 한도와 수신처 허용 목록을 둬요
서명 직전 단계에서 금액 상한, 하루 누적 한도, 허용된 도메인·payTo 주소를 확인하고 벗어나면 거절해요. 같은 자원을 짧은 시간에 반복 결제하면 멈추는 규칙도 넣어요.
- 4
처음 보는 수신처는 사람이 승인해요
새 판매자나 평소보다 큰 금액은 사람 확인을 거치게 해요. 클라우드플레어 예제도 결제를 사람 확인과 함께 또는 없이 실행하도록 설계할 수 있다고 안내해요.
- 5
퍼실리테이터와 기록을 점검해요
판매자라면 어떤 퍼실리테이터를 쓰는지, 지원 목록과 보안 공지를 확인해요. 구매자라면 결제마다 거래 해시·금액·수신처를 로그로 남겨 온체인 기록과 정기적으로 맞춰 봐요.
정리하면 x402는 'HTTP 응답으로 가격을 묻고, 서명으로 값을 치르는' 단순한 구조 덕분에 AI 에이전트 결제의 공통 언어가 될 가능성이 있어요. 그러나 단순함은 통제 장치가 기본으로 들어 있지 않다는 뜻이기도 해요. 지출 한도와 수신처 검증, 사람 승인, 기록 대조를 먼저 갖춘 뒤 작은 금액부터 연결하세요. 블로그와 커뮤니티에서 x402 관련 화제가 어떻게 이어지는지는 더따리 블로그 동향 대시보드에서 함께 살펴볼 수 있어요.


