1편에서 살펴본 x402의 출발점은 단순했습니다. 인터넷에는 오래전부터 402 Payment Required라는 상태 코드가 있었지만, 실제로 돈을 어떻게 지불해야 하는지에 대한 공통된 방법은 만들어지지 않았습니다.

x402는 이 빈 공간에 결제 규칙을 넣습니다.

그렇다고 사용자가 웹사이트에서 결제 버튼을 한 번 더 누르게 만드는 방식은 아닙니다. x402가 목표로 하는 것은 프로그램이 서비스를 요청하고, 가격을 확인하고, 결제를 승인한 뒤 결과를 받는 과정 자체를 프로그램으로 처리하는 것입니다.

전체 구조부터 보면 생각보다 복잡하지 않습니다.

서비스 요청 → 402 결제 조건 → Wallet 결제 승인 → 결제 검증·정산 → 서비스 제공

이 흐름을 이해하면 x402에서 자주 등장하는 Client, Server, Wallet, Facilitator가 왜 필요한지도 자연스럽게 이해할 수 있습니다.

유료 날씨 API 하나를 호출한다고 생각해보자

x402 전체 결제 흐름

예를 들어 한 개발자가 실시간 날씨 정보를 제공하는 API를 운영하고 있다고 가정해보겠습니다. API를 한 번 호출할 때마다 $0.01을 받고 싶습니다.

일반적인 API 서비스라면 먼저 회원가입을 받고 API Key를 발급한 뒤 사용량을 기록합니다. 월말에는 1만 번 사용한 고객에게 100달러를 청구하는 식입니다.

x402에서는 접근 방법이 달라질 수 있습니다.

AI Agent나 애플리케이션이 날씨 API에 다음과 같이 데이터를 요청합니다.

Client → GET /weather → Server

그런데 이 API는 유료입니다. 서버는 데이터를 바로 반환하지 않고 402 Payment Required를 보내면서 얼마를, 어떤 자산으로, 어떤 네트워크를 통해, 어느 주소로 지급해야 하는지 등의 결제 조건을 전달합니다.

공식 x402 문서에서도 서버의 역할을 결제 조건을 선언하고, 지불되지 않은 요청에 HTTP 402를 반환한 뒤, 조건에 맞는 결제가 확인되면 리소스를 제공하는 것으로 설명합니다.

따라서 첫 번째 요청의 결과는 날씨 데이터가 아니라 가격표에 가깝습니다.

Client → API 요청 → Server → 402 + 결제 조건

여기까지는 아직 돈이 움직이지 않았습니다.

402 응답에는 단순히 “돈을 내라”만 들어 있지 않다

여기서 HTTP 402의 역할을 조금 더 정확하게 볼 필요가 있습니다.

서버가 단순히 402 Payment Required만 보내면 클라이언트는 무엇을 해야 할지 알 수 없습니다. 100원을 보내야 하는지, 1달러를 보내야 하는지, 어떤 네트워크를 사용할지, 누구에게 보내야 하는지도 알아야 합니다.

그래서 x402에서는 402 응답에 결제에 필요한 조건을 함께 전달합니다. 공식 프로토콜에서는 PAYMENT-REQUIRED를 통해 클라이언트가 결제를 준비하는 데 필요한 정보를 전달할 수 있습니다.

개념적으로 보면 다음과 같습니다.

가격 + 결제 자산 + 네트워크 + 받을 주소 + 결제 방식

예를 들어 서버가 $0.01 상당의 USDC를 특정 네트워크에서 받는 조건을 제시할 수 있습니다.

중요한 점은 서버가 일방적으로 결제를 실행하는 것이 아니라는 것입니다. 서버는 조건을 제시하고, 실제로 그 조건에 따라 돈을 지불할지는 Client가 결정합니다.

이 구조는 AI Agent를 생각하면 더욱 중요해집니다.

Wallet은 단순히 코인을 보관하는 지갑이 아니다

클라이언트가 결제 조건을 받았다면 이제 실제 결제를 준비해야 합니다. 여기에서 Wallet이 등장합니다.

암호화폐에서 Wallet이라고 하면 보통 코인을 보관하는 지갑을 떠올립니다. 하지만 x402에서 Wallet의 역할은 조금 더 넓습니다. 공식 문서는 Wallet을 구매자와 판매자가 결제를 보내고 받고 검증하는 데 사용하는 수단이면서, 동시에 프로토콜 안에서 식별자로 활용될 수 있는 요소로 설명합니다.

구매자 측 Wallet의 가장 중요한 역할은 결제를 승인할 수 있는 서명을 만드는 것입니다.

서버가 $0.01을 요구했다고 해서 서버가 Client의 Wallet에서 마음대로 돈을 가져갈 수는 없습니다. Client가 조건을 확인하고 Wallet을 이용해 해당 지불을 승인해야 합니다.

흐름은 다음처럼 이어집니다.

402 결제 조건 수신 → 가격·네트워크 확인 → Wallet으로 결제 승인 → Payment Payload 생성

여기서 Wallet에 사람이 반드시 붙어 있어야 하는 것은 아닙니다. 애플리케이션이나 AI Agent가 미리 설정된 정책에 따라 프로그램 방식으로 Wallet을 사용할 수도 있습니다.

예를 들어 Agent에게 한 번에 최대 $0.05, 하루 최대 $5, 승인된 서비스만 결제 같은 정책을 적용한다면 조건 안에서 자동으로 결제하도록 설계할 수 있습니다.

다만 이런 지출 한도나 승인 정책은 x402가 자동으로 정해주는 것이 아니라 Wallet이나 Agent 애플리케이션 측에서 설계해야 할 영역입니다. x402는 어떻게 결제 조건을 전달하고 지불 증명을 주고받을 것인가를 다루는 프로토콜에 가깝습니다.

결제한 뒤에는 같은 서비스를 다시 요청한다

Wallet이 지불을 승인하면 Client는 결제 정보를 포함해 원래 요청을 다시 보냅니다.

현재 x402의 Client/Server 흐름에서는 Client가 결제 Payload를 준비한 뒤 이를 PAYMENT-SIGNATURE 헤더에 포함해 요청할 수 있습니다. 서버는 이를 받아 결제가 자신이 제시한 조건에 맞는지 확인합니다.

따라서 날씨 API 예제는 이제 다음 단계까지 진행됩니다.

GET /weather → 402 Payment Required → Wallet 서명 → PAYMENT-SIGNATURE 포함 재요청

처음 요청과 두 번째 요청의 차이는 명확합니다.

첫 번째 요청은 “이 서비스를 사용하고 싶다”는 요청이고, 두 번째 요청은 “당신이 제시한 조건으로 결제를 승인했으니 서비스를 제공해달라”는 요청입니다.

여기까지 보면 결제 과정이 거의 끝난 것처럼 보입니다.

하지만 서버에는 아직 한 가지 문제가 남아 있습니다.

이 결제가 정말 유효한지 어떻게 확인할 것인가?

그래서 Facilitator가 등장한다

Wallet과 Facilitator의 역할

x402를 설명할 때 가장 낯선 단어가 Facilitator입니다.

우리말로 직역하면 ‘촉진자’나 ‘중개자’에 가깝지만, x402에서는 결제 검증과 정산을 대신 처리해주는 계층으로 이해하는 것이 쉽습니다.

API 운영자가 결제를 받으려면 Wallet의 서명이 유효한지 확인하고, 결제 금액과 자산이 자신이 제시한 조건과 맞는지 검증하고, 필요한 경우 블록체인에 거래를 제출해 실제 정산까지 처리해야 합니다.

모든 API 사업자가 이러한 블록체인 인프라를 직접 구축해야 한다면 x402를 도입하는 부담이 상당히 커집니다.

Facilitator가 이 부분을 대신할 수 있습니다.

Server → Facilitator → 결제 검증 → Blockchain 정산 → 결과 반환

공식 x402 문서에 따르면 Facilitator의 핵심 역할은 Client가 제출한 결제가 서버의 요구 조건을 충족하는지 확인하고, 유효한 결제를 블록체인에 제출해 정산한 뒤 그 결과를 서버에 반환하는 것입니다.

즉 API 개발자는 자신의 서버에서 직접 블록체인 노드를 운영하고 여러 네트워크의 정산 로직을 모두 만드는 대신 Facilitator를 활용할 수 있습니다.

여기서 중요한 점이 하나 있습니다.

Facilitator는 x402의 필수 중앙 운영자가 아닙니다.

서버가 직접 결제를 검증하고 정산할 수도 있으며, Facilitator를 사용할 경우에도 반드시 Coinbase가 운영하는 서비스만 사용할 필요는 없습니다. x402는 permissionless 구조이기 때문에 다른 사업자나 커뮤니티가 Facilitator를 운영할 수도 있습니다.

따라서 구조를 Coinbase → 모든 x402 거래 통제로 이해하면 정확하지 않습니다.

Facilitator가 결제를 검증한다고 돈을 마음대로 가져갈 수 있을까

여기에서 자연스럽게 또 하나의 질문이 생깁니다. 결제를 중간에서 검증하고 정산하는 Facilitator가 있다면 기존 결제대행사처럼 Facilitator를 완전히 신뢰해야 하는 것은 아닐까요?

x402 공식 FAQ에 따르면 Payment Payload는 구매자가 서명하며, Facilitator가 이를 임의로 변경하면 서명 검증을 통과할 수 없습니다. 실제 정산 역시 온체인에서 이루어지는 구조이기 때문에 Facilitator가 구매자가 승인하지 않은 내용으로 결제 정보를 바꿔 정산할 수 없도록 설계되어 있습니다.

물론 이것이 Facilitator와 관련된 모든 운영 위험이 사라진다는 의미는 아닙니다. 서비스 장애, 지원 네트워크, 수수료, 정책, 검증 방식 등은 Facilitator마다 달라질 수 있습니다.

다만 구조적으로 보면 Facilitator는 구매자의 돈을 자유롭게 움직이는 계좌 관리자라기보다 이미 서명된 결제 조건이 맞는지 확인하고 정산을 실행하는 서비스에 가깝습니다.

결제가 확인되면 서버는 데이터를 반환한다

Facilitator가 결제를 검증하고 필요한 정산이 완료되면 그 결과가 Server에 전달됩니다. 서버는 결제가 유효하다는 것을 확인한 뒤 처음 Client가 원했던 날씨 데이터를 반환합니다.

전체 과정은 이제 하나로 연결됩니다.

API 요청 → 402 + 결제 조건 → Wallet 결제 승인 → 결제정보와 함께 재요청 → Facilitator 검증·정산 → 200 OK + API 데이터

공식 Coinbase 문서가 설명하는 전체 흐름도 기본적으로 이 구조를 따릅니다. Facilitator를 사용하는 경우 Facilitator가 결제를 검증하고 네트워크에 정산한 뒤 서버가 최종 리소스를 반환합니다. 정산 정보는 응답과 함께 전달될 수도 있습니다.

이렇게 보면 x402의 역할이 조금 더 명확해집니다.

x402가 새로운 결제망 자체를 만드는 것은 아닙니다. 대신 HTTP에서 서비스 요청과 결제 네트워크 사이를 연결하는 공통 언어를 만드는 것에 가깝습니다.

Client, Server, Wallet, Facilitator의 역할을 정리하면

지금까지의 구조를 네 개의 주체로 나누면 훨씬 단순합니다.

구성 요소	역할
Client	API나 서비스를 요청하고 결제 조건을 확인한다
Server	가격과 결제 조건을 제시하고 결제 후 서비스를 제공한다
Wallet	결제를 승인하고 서명하며 자금을 보내거나 받는다
Facilitator	결제가 조건에 맞는지 검증하고 정산을 처리할 수 있다

이 중에서 Client가 꼭 사람이 사용하는 브라우저일 필요는 없습니다. 일반 애플리케이션이 될 수도 있고 자동화 프로그램이나 AI Agent가 될 수도 있습니다.

Server 역시 일반적인 웹사이트일 필요가 없습니다. 데이터 API, AI 모델, 이미지 생성 서비스, 검색 서비스, 클라우드 연산 등 HTTP로 제공할 수 있는 다양한 디지털 서비스가 대상이 될 수 있습니다.

결국 구조는 구매자 Client ↔ 판매자 Server이고 Wallet과 Facilitator가 그 사이의 결제를 연결합니다.

기존 PG와 비슷해 보이지만 차이가 있다

Facilitator의 역할을 보면 기존 카드 결제의 PG와 비슷해 보일 수 있습니다.

실제로 서버가 복잡한 결제 처리를 직접 하지 않도록 도와준다는 점에서는 비슷한 부분이 있습니다. 하지만 기반 구조에는 차이가 있습니다.

기존 카드 결제는 대체로 사용자 → 쇼핑몰 → PG → 카드사·은행 → 정산으로 연결되고, 결제사업자가 구축한 계정과 승인 네트워크를 이용합니다.

x402에서는 Client → Server → Wallet 서명 → Facilitator → Blockchain → Server로 연결될 수 있습니다.

특히 구매자가 Wallet을 이용해 결제를 직접 승인하고, 그 결과가 온체인에서 정산될 수 있다는 점이 기존 카드 결제와 다른 중요한 특징입니다.

그렇다고 어느 한 방식이 다른 방식을 곧바로 대체한다고 볼 필요는 없습니다. 카드 결제는 소비자 보호, 환불, 신용 제공, 사기 방지 등 오랜 기간 구축된 시스템을 갖고 있습니다. x402는 처음부터 같은 문제를 해결하기 위해 만들어진 시스템이라기보다 인터넷 프로그램 간에 결제 조건과 지급을 연결하는 새로운 방식에 가깝습니다.

API Key가 없어지는 것도 아니다

x402를 설명하면서 자주 과장되기 쉬운 부분이 있습니다.

x402가 등장하면 API Key가 사라진다는 주장입니다.

x402를 이용하면 일부 서비스에서 회원가입이나 API Key 없이 결제 자체를 접근 권한처럼 활용하는 구조를 만들 수 있습니다. 실제로 x402 공식 문서는 계정이나 세션 없이 리소스에 프로그램 방식으로 비용을 지불할 수 있다는 점을 주요 특징으로 설명합니다.

하지만 API Key에는 결제 외에도 여러 역할이 있습니다. 어떤 사용자가 API를 호출했는지 확인하고, 호출 횟수를 제한하고, 권한을 구분하고, 문제가 발생한 사용자의 접근을 차단하는 데도 사용됩니다.

따라서 현실적인 변화는 API Key가 모두 없어지는 것보다 API 서비스가 선택할 수 있는 과금 방식이 늘어나는 쪽에 가깝습니다.

기존에는 가입 → API Key → 사용량 기록 → 나중에 청구가 일반적이었다면 x402를 이용해 요청 → 즉시 결제 → 사용이라는 모델도 만들 수 있게 되는 것입니다.

한 번에 몇 원짜리 API를 팔 수 있다는 의미

이 차이는 결제 금액이 작아질수록 중요해집니다.

예를 들어 데이터 한 건의 가격이 $0.001이라고 해보겠습니다. 이런 서비스를 이용하기 위해 월 10달러 요금제에 가입하도록 요구하면 한두 번만 데이터를 원하는 사용자에게는 비효율적입니다.

반면 요청 하나에 가격을 붙일 수 있다면 서비스는 더 잘게 나뉠 수 있습니다.

검색 1회 $0.001 → 데이터 조회 1회 $0.005 → 이미지 분석 1회 $0.02 → AI 추론 1회 $0.10

이것이 x402에서 마이크로페이먼트와 Pay-per-use가 자주 언급되는 이유입니다.

다만 소액 결제가 가능하다고 해서 모든 결제를 매번 개별 온체인 거래로 처리하는 것이 항상 효율적인 것은 아닙니다. 거래량이 크게 늘어나면 네트워크 비용과 처리량, 정산 방식이 새로운 문제가 됩니다.

현재 x402는 이런 고빈도 결제를 위해 여러 요청을 개별 승인한 뒤 나중에 묶어 정산하는 Batch Settlement 같은 방식도 문서화하고 있습니다.

즉 x402 역시 단순히 요청할 때마다 블록체인 거래 한 번이라는 구조에 머물러 있는 것은 아닙니다.

x402 v2에서는 결제 한 번의 범위를 넘어가기 시작했다

x402는 처음부터 완성된 형태로 고정된 프로토콜도 아닙니다.

2025년 12월 발표된 x402 v2에서는 Wallet 기반 Identity, API Discovery, Dynamic Payment Recipient, 더 많은 네트워크를 표현하기 위한 CAIP 기반 구조와 모듈화된 SDK 등이 추가됐습니다. 단순히 API를 한 번 호출하고 한 번 결제하는 구조에서 다양한 결제 방식과 Agent 사용 사례를 지원하는 방향으로 확장된 것입니다.

특히 Wallet Identity는 중요한 변화입니다.

모든 요청마다 돈을 다시 내야 하는 서비스만 존재하는 것은 아닙니다. 한 번 결제한 사용자가 다시 접속하거나 특정 Wallet에 접근 권한을 부여하는 상황도 있기 때문입니다.

현재 x402에는 Wallet 서명을 이용해 이미 결제한 사용자를 식별하거나 Wallet 기반 인증을 구현할 수 있는 Sign-In-With-X(SIWX) 같은 확장 기능도 문서화돼 있습니다.

이 변화는 x402가 단순한 HTTP 마이크로결제 기능에서 서비스 접근, 인증, 발견과 결제를 함께 다루는 생태계로 확장되고 있다는 점을 보여줍니다.

결국 x402가 자동화하는 것은 ‘구매 과정’이다

여기까지의 기술 구조를 모두 외울 필요는 없습니다.

중요한 것은 x402가 무엇을 자동화하려는지 이해하는 것입니다.

지금까지 인터넷에서 프로그램은 다른 서버의 데이터를 자동으로 가져올 수 있었지만, 유료 서비스가 등장하면 사람이 만든 계정과 요금제, 결제 시스템을 통과해야 하는 경우가 많았습니다.

x402에서는 이 과정 자체를 프로그램이 이해할 수 있도록 만듭니다.

서비스 발견 → 가격 확인 → 결제 조건 판단 → Wallet 승인 → 결제 → 서비스 이용

이 구조가 중요한 이유는 단순히 API 개발자가 결제를 조금 편하게 붙일 수 있기 때문만은 아닙니다.

앞으로 서비스를 구매하는 주체가 사람뿐이라면 기존 결제 시스템으로도 충분한 영역이 많습니다. 하지만 AI Agent가 스스로 검색 API를 선택하고, 데이터를 구입하고, 다른 AI 모델을 호출하고, 필요한 컴퓨팅 자원을 구매한다면 이야기가 달라집니다.

Agent가 작업을 수행하는 데 필요한 서비스마다 사람이 로그인해 결제 버튼을 눌러야 한다면 완전한 자동화가 어렵습니다.

바로 여기에서 Wallet과 x402가 AI Agent와 연결되기 시작합니다.

다음 편에서는 기술 구조에서 한 단계 더 나아가겠습니다. 왜 AI Agent 시대의 결제 수단으로 스테이블코인이 계속 등장하는지, 그리고 카드나 BTC·ETH와 비교했을 때 스테이블코인이 어떤 역할을 맡을 수 있는지 살펴보겠습니다.

핵심 정리

x402의 기본 결제 구조는 요청 → 402 결제 조건 → Wallet 승인 → 결제 검증·정산 → 서비스 제공으로 이해할 수 있습니다.

Client는 서비스를 구매하고 Server는 가격을 제시합니다. Wallet은 구매자가 결제를 승인하고 서명하는 역할을 하며, Facilitator는 Server를 대신해 결제를 검증하고 블록체인 정산을 처리할 수 있습니다.

Facilitator는 반드시 Coinbase가 운영해야 하는 중앙 서버가 아니며, 서버가 직접 검증하거나 다른 Facilitator를 이용하는 것도 가능합니다.

그리고 x402가 궁극적으로 단순화하려는 것은 결제 버튼 하나가 아닙니다.

프로그램이 서비스를 발견하고 가격을 확인한 뒤 스스로 비용을 지불하고 결과를 받아가는 전체 구매 과정입니다.

이 구조가 AI Agent 시대와 만나면 x402의 의미는 훨씬 커집니다. 이제 다음 질문은 프로그램이 돈을 쓸 수 있다면, 그 돈으로 무엇을 사용해야 하는가입니다.