본문으로 건너뛰기

1. [x402란 무엇인가] 인터넷에는 왜 결제 프로토콜이 없었나

인터넷에서는 데이터를 요청하고 파일을 내려받고 API를 호출하는 일이 모두 자동화됐지만, 결제는 여전히 계정 생성과 카드 등록, 결제 페이지 같은 별도의 과정을 거쳐야 합니다. x402는 오랫동안 비어 있던 HTTP `402 Payment Required`를 활용해 결제를 HTTP 요청과 응답의 흐름 안으로 가져오려는 오픈 결제 프로토콜입니다. x402가 왜 등장했는지, 기존 인터넷 결제와 무엇이 다른지부터 살펴봅니다.

인터넷에서 정보를 얻는 과정은 놀라울 정도로 단순합니다. 브라우저가 서버에 페이지를 요청하면 서버는 데이터를 보내고, 애플리케이션이 API를 호출하면 서버는 JSON 같은 형태로 결과를 돌려줍니다. 이 과정은 사람이 개입하지 않아도 수백만 번, 수천만 번 반복될 수 있습니다.

그런데 돈이 끼어들면 이야기가 달라집니다. 유료 서비스를 이용하려면 회원가입을 하고, 결제수단을 등록하고, 카드사나 결제대행사를 거쳐 승인을 받아야 합니다. API 서비스도 대부분 먼저 계정을 만들고 API Key를 발급받은 뒤 사용량을 측정해 월말에 청구하거나 미리 구매한 크레딧을 차감합니다.

정보는 인터넷 안에서 움직이는데 결제는 오랫동안 인터넷 바깥의 별도 시스템에 의존해온 셈입니다.

x402는 바로 이 지점에서 출발합니다.

인터넷에는 이미 ‘Payment Required’가 있었다

웹사이트를 이용하다 보면 404 Not Found라는 숫자를 자주 만나게 됩니다. 요청한 페이지를 찾을 수 없다는 뜻입니다. 개발자에게 익숙한 401 Unauthorized, 403 Forbidden, 500 Internal Server Error 역시 서버가 현재 요청을 어떻게 처리했는지 알려주는 HTTP 상태 코드입니다.

그런데 이 목록에는 오래전부터 꽤 흥미로운 번호가 하나 있었습니다.

402 Payment Required, 말 그대로 ‘결제가 필요하다’는 뜻입니다.

HTTP/1.1을 정의한 1997년 RFC 2068에는 이미 402 Payment Required가 포함돼 있었습니다. 하지만 구체적인 결제 방법을 정의하지 않고 미래의 사용을 위해 예약된 코드로 남겨뒀습니다. 이후 HTTP 표준이 여러 차례 개정됐지만 현재 HTTP 의미론을 정의하는 RFC 9110에서도 402는 여전히 ‘향후 사용을 위해 예약된 상태 코드’로 남아 있습니다.

이 부분이 중요합니다. 인터넷을 설계한 사람들이 결제라는 개념을 전혀 생각하지 않았던 것은 아닙니다. ‘결제가 필요하다’는 신호를 보낼 자리는 만들었지만, 그다음에 돈을 어떤 방식으로 보내고 결제 완료를 어떻게 확인할지에 대한 공통 규칙이 만들어지지 않았습니다.

결국 인터넷 상거래는 HTTP 402를 중심으로 발전하지 않았습니다. 카드, 은행, 결제대행사(PG), 계정, 구독, 청구 시스템 등이 HTTP 위에 별도의 결제 구조로 쌓였습니다.

웹에서 상품을 구매하는 과정을 단순화하면 대략 다음과 같습니다.

상품 선택 → 로그인 → 결제수단 선택 → 결제사업자 승인 → 결제 완료 → 서비스 제공

이 구조는 사람이 온라인 쇼핑을 하는 데는 큰 문제가 없습니다. 결제 버튼을 누르고 본인인증을 하는 몇 단계가 번거롭더라도 한 번에 몇 만원짜리 상품을 구매한다면 충분히 감수할 수 있기 때문입니다.

하지만 인터넷에서 거래하는 주체가 사람이 아니라 프로그램이라면 문제가 달라집니다.

API 하나를 사용하려고 회원가입부터 해야 한다면

예를 들어 어떤 프로그램이 특정 데이터를 한 번 가져오고 싶다고 가정해 보겠습니다. 필요한 데이터의 가격은 10원 정도입니다.

기술적으로는 API를 한 번 호출하면 끝나는 일입니다.

그런데 실제 상용 API에서는 회원가입 → 이메일 인증 → 결제수단 등록 → 요금제 선택 → API Key 발급 → API 호출 같은 절차가 필요할 수 있습니다. 10원짜리 데이터를 한 번 구매하기 위해서는 결제 금액보다 서비스를 사용하기 위한 준비 과정이 훨씬 커지는 셈입니다.

그래서 API 산업에서는 월 구독이나 사용량 기반 후불 청구, 선불 크레딧 같은 방식이 널리 사용됩니다. 이것은 현재 인터넷 환경에 잘 맞는 현실적인 방법이지만, API 요청 자체와 결제는 여전히 서로 다른 과정입니다.

x402가 바꾸려는 부분이 바로 이것입니다.

x402는 HTTP 안에 결제 과정을 연결한다

Coinbase는 2025년 5월 6일 x402를 공개하면서 이를 HTTP를 통해 스테이블코인 결제를 처리할 수 있도록 만든 인터넷 네이티브 결제 프로토콜로 소개했습니다. API와 애플리케이션뿐 아니라 AI Agent 같은 소프트웨어도 프로그램 방식으로 비용을 지불할 수 있도록 하는 것이 핵심입니다.

이름이 x402인 이유 역시 HTTP의 402 Payment Required에서 가져왔습니다. x402 공식 문서는 402를 기반으로 서비스가 HTTP 응답 안에서 결제가 필요하다는 사실과 필요한 결제 조건을 전달할 수 있다고 설명합니다.

구조를 최대한 단순하게 보면 다음과 같습니다.

서비스 요청 → 402 Payment Required → 결제 조건 확인 → 결제 → 요청 재전송 → 서비스 제공

예를 들어 유료 날씨 API가 있다고 생각해보겠습니다. 프로그램이 날씨 데이터를 요청했는데 무료 API가 아니라면 서버는 단순히 접근을 차단하는 대신 “이 데이터를 받으려면 얼마를 어떤 방식으로 결제해야 한다”는 조건을 돌려줄 수 있습니다. 클라이언트는 조건에 맞는 결제를 준비한 뒤 결제 정보를 포함해 다시 요청하고, 서버가 이를 확인하면 데이터를 반환합니다.

x402 공식 문서가 강조하는 것도 이 부분입니다. 서비스는 계정이나 세션을 반드시 먼저 만들지 않고도 리소스 접근에 필요한 비용을 프로그램 방식으로 요구할 수 있습니다.

기존 결제와 비교하면 차이가 조금 더 명확해집니다.

기존 방식: 계정 생성 → 결제수단 등록 → 요금제 가입 → API Key 발급 → 사용 → 청구

x402 방식: API 요청 → 결제 요구 → 결제 → API 응답

그렇다고 x402가 기존 회원가입이나 API Key를 모두 없앤다는 뜻은 아닙니다. 사용자 인증이 필요한 서비스나 정액 구독 서비스에서는 기존 방식이 계속 필요할 수 있습니다. x402가 제공하는 것은 돈을 받기 위해 반드시 계정과 월 구독 시스템부터 만들어야 했던 구조와 다른 선택지입니다.

특히 한 번 사용할 때마다 비용을 지불하는 Pay-per-use 서비스에서는 의미가 커질 수 있습니다.

이 구조가 지금 다시 주목받는 이유

HTTP 402는 수십 년 동안 존재했습니다. 그렇다면 왜 지금에서야 이런 구조가 다시 등장하는 것일까요?

여러 변화가 동시에 일어났기 때문입니다. 인터넷에는 이미 수많은 API가 존재하고 클라우드 컴퓨팅, 데이터, AI 모델, 검색, 이미지 생성처럼 프로그램이 다른 프로그램의 기능을 구매하는 환경도 커졌습니다. 여기에 블록체인 기반 디지털 결제 수단이 등장하면서 프로그램이 인터넷을 통해 직접 가치 정보를 전달하고 정산하는 방법도 만들어졌습니다.

그리고 최근에는 한 가지 변화가 더해졌습니다.

AI Agent입니다.

기존 인터넷 서비스의 고객은 대부분 사람이었습니다. 사람이 서비스를 검색하고 가격을 비교한 뒤 결제 버튼을 눌렀습니다. 그러나 AI Agent가 사용자를 대신해 여러 서비스를 선택하고 API를 호출하기 시작하면 Agent 역시 필요한 서비스를 구매할 방법이 필요해집니다.

예를 들어 여행을 계획하는 AI Agent가 항공편 데이터는 A사의 API에서 구매하고, 날씨 정보는 B사의 API를 이용하고, 지도 데이터는 C사의 서비스를 사용하는 상황을 생각할 수 있습니다. 각각의 서비스를 이용할 때마다 사람이 로그인하고 결제를 승인해야 한다면 Agent가 자동으로 작업한다는 의미가 크게 줄어듭니다.

그래서 인터넷 결제의 구조도 새로운 질문을 받기 시작합니다.

사람이 결제하는 인터넷에서 프로그램이 결제하는 인터넷으로 넘어가면 무엇이 달라져야 할까?

x402는 이 문제에 대한 하나의 접근입니다. Coinbase 역시 처음 x402를 발표하면서 API, 앱과 함께 AI Agent가 직접 거래할 수 있는 구조를 주요 사용 사례로 제시했습니다.

다만 여기서 한 가지를 구분해야 합니다. AI Agent가 있다고 해서 x402가 필요한 것도 아니고, x402가 AI Agent만을 위한 프로토콜인 것도 아닙니다. x402의 기본 대상은 HTTP를 사용하는 클라이언트와 서버이며 사람이 사용하는 애플리케이션도 클라이언트가 될 수 있습니다. AI Agent는 이 구조가 특히 유용해질 가능성이 있는 사용 사례 중 하나입니다.

x402는 새로운 코인이 아니다

암호화폐 시장에서 x402라는 단어가 등장하면 새로운 코인이나 토큰의 이름으로 오해하기 쉽습니다. 그러나 공식 x402 프로젝트를 이해할 때 가장 먼저 구분해야 하는 부분입니다.

x402는 투자용 코인의 이름이 아니라 결제 방법을 정의하는 오픈 프로토콜입니다.

공식 프로젝트 저장소는 x402를 인터넷 네이티브 결제를 위한 오픈 표준으로 정의하고 있으며, 장기적으로 특정 블록체인이나 특정 자산 하나만을 전제로 하지 않습니다. 암호화폐 네트워크뿐 아니라 다른 네트워크와 스테이블코인·토큰·법정화폐 등 다양한 형태의 가치를 지원하는 것을 목표로 하고 있습니다.

또한 공식 FAQ는 x402가 Coinbase Developer Platform의 독점 상품이 아니라 오픈소스 프로토콜이며 Coinbase 제품을 사용하지 않아도 구현할 수 있다고 명시합니다.

따라서 x402 가격, x402 코인 전망처럼 접근하면 x402의 본질을 놓칠 수 있습니다. 별도의 프로젝트가 x402라는 이름을 활용한 토큰을 만들 가능성과 공식 x402 프로토콜 자체에 투자용 토큰이 존재하는지는 완전히 다른 문제입니다.

그렇다면 스테이블코인은 왜 등장하는가

여기까지 읽으면 한 가지 의문이 남습니다.

HTTP에 결제 방법을 연결하는 것이 목적이라면 왜 x402를 설명할 때 USDC 같은 스테이블코인이 계속 등장할까요?

초기 x402 구현에서 가장 중요한 결제 수단 중 하나가 스테이블코인이기 때문입니다. Coinbase가 x402를 처음 공개했을 때도 HTTP를 통한 자동화된 스테이블코인 결제를 전면에 내세웠습니다.

이 조합에는 이유가 있습니다. API 사용료가 $0.01이라면 서비스 제공자는 가능한 한 $0.01이라는 가격을 그대로 유지하고 싶습니다. 가격 변동성이 큰 자산을 결제 단위로 사용하면 서비스 가격과 실제 지급 가치가 계속 달라질 수 있지만 달러 가치에 연동된 스테이블코인은 가격을 달러 기준으로 표현하기 상대적으로 쉽습니다.

하지만 x402 = USDC라고 이해해서도 안 됩니다. 현재 공식 프로젝트는 프로토콜과 실제 결제 네트워크·자산을 분리하는 방향으로 설계되어 있으며 여러 네트워크와 자산을 지원할 수 있도록 확장성을 두고 있습니다.

스테이블코인과 x402의 관계는 다음 편들에서 더 중요해집니다. 특히 AI Agent가 데이터를 몇 센트씩 구매하거나 다른 Agent의 서비스를 이용하는 환경에서는 결제 단위, 수수료, 정산 속도와 같은 문제가 본격적으로 등장하기 때문입니다.

인터넷에 없던 것이 아니라 완성되지 않았던 것

x402를 이해하는 가장 좋은 방법은 이를 완전히 새로운 결제 시스템으로 보는 것이 아닙니다.

인터넷에는 이미 Payment Required라는 자리가 있었습니다. 1997년 HTTP/1.1 문서에도 402가 존재했고, 지금까지도 그 이름은 남아 있습니다. 다만 “결제가 필요하다”는 신호 다음에 무엇을 해야 하는지에 대한 범용적인 결제 흐름이 없었습니다.

x402는 이 오래된 빈자리에 다시 접근합니다.

HTTP Request → 402 Payment Required → Payment → HTTP Response

여기서 중요한 변화는 결제 버튼의 디자인이 아닙니다. 프로그램이 다른 프로그램에 서비스를 요청하고, 필요한 비용을 확인하고, 비용을 지불한 뒤 결과를 받는 과정을 하나의 통신 흐름으로 연결하려는 것입니다.

지금까지 인터넷 경제가 주로 Human → Website → Payment였다면, x402가 바라보는 영역에는 Software → API → Payment, 더 나아가 AI Agent → Service → Payment가 포함됩니다.

그렇다면 실제 x402에서는 서버가 어떤 결제 조건을 보내고 클라이언트는 어떻게 결제하며, 블록체인 거래를 누가 검증하고 정산할까요?

다음 편에서는 Client, Server, Wallet, Facilitator를 중심으로 x402 결제가 실제 HTTP 요청에서 어떻게 작동하는지 구조를 하나씩 살펴보겠습니다.

핵심 정리

x402를 처음 접했다면 네 가지만 기억하면 됩니다.

첫째, HTTP 402 Payment Required는 최근 만들어진 코드가 아니라 HTTP/1.1 초기부터 존재했지만 구체적인 사용 방법 없이 예약돼 있던 상태 코드입니다.

둘째, x402는 이 HTTP 402를 활용해 서비스 요청과 결제를 하나의 프로그램 흐름으로 연결하려는 오픈 결제 프로토콜입니다.

셋째, x402는 코인이 아닙니다. 특정 자산 가격을 올리기 위한 프로젝트가 아니라 인터넷에서 결제를 처리하기 위한 프로토콜입니다.

넷째, x402가 특히 주목받는 영역은 API와 AI Agent입니다. 사람이 매번 결제 버튼을 누르는 것이 아니라 프로그램이 필요한 서비스를 찾아 비용을 지불해야 하는 환경이 만들어지고 있기 때문입니다.

인터넷은 이미 정보를 자동으로 교환하고 있습니다. x402가 던지는 질문은 그다음입니다. 돈도 같은 방식으로 움직일 수 있을까요?