에이전트가 스스로 데이터를 사고, API를 호출하고, 필요한 연산을 구매하는 시대에는 기계가 직접 사용할 수 있는 결제 수단이 필요하다. 카드 정보를 입력하거나 서비스마다 API 키와 구독을 관리하는 방식만으로는 이 흐름을 매끄럽게 만들기 어렵다. 그런 점에서 x402는 에이전틱 커머스에 중요한 레일이다.
x402가 제시한 요청당 결제의 매력도 여기에 있다. 서비스를 오래 구독하거나 별도 계약을 맺기 전에, 필요한 요청 하나에 값을 매겨 바로 이용할 수 있다는 것이다. 다만 이 경험을 실제 사업으로 옮기려면 한 가지를 구분해야 한다. 요청마다 가격을 매기는 것과 요청마다 온체인에서 돈을 정산하는 것은 같은 일이 아니다.
마이크로페이먼트가 작동하는지는 결제 금액이 얼마나 작은가만으로 결정되지 않는다. 작은 금액이 얼마나 자주 오가고, 그때마다 어떤 비용과 지연이 발생하는지를 함께 봐야 한다.
작은 결제에도 비용의 하한은 있다
Coinbase의 CDP 변경로그에는 이 문제가 구체적인 숫자로 드러난다. 2025년 12월 1일 요금 공지 이후, 12월 3일에는 facilitator의 최소 결제금액 $0.001가 기록됐다. 2026년 1월 1일부터는 월 1,000건 무료 이후 건당 $0.001의 과금이 시작됐다.
여기서 현재 요금의 단위는 정확히 짚어야 한다. CDP가 부과하는 $0.001는 API 요청 수가 아니라 온체인 거래 수를 기준으로 한다. 검증 요청은 무료이며, 정산 방식을 어떻게 구성하느냐에 따라 같은 API 호출량에서도 과금되는 거래 수가 달라질 수 있다.
x402 자체가 모든 서비스에 동일한 수수료를 부과하는 것도 아니다. 프로토콜과 이를 운영하는 facilitator의 요금은 별개다. 따라서 CDP의 숫자를 생태계 전체의 고정 비용으로 일반화하기보다는, 실제 제품이 사용할 결제·정산 구조의 사례로 읽는 편이 맞다.
$0.001를 벌기 위해 $0.001를 쓴다면
무료 구간을 넘긴 뒤 매 요청이 하나의 유료 온체인 정산을 발생시키고, 판매자가 수수료를 부담한다고 가정해 보자. 요청당 가격이 $0.001라면 같은 금액의 facilitator 수수료만으로 매출의 100%가 소모된다. 가격이 $0.01여도 수수료 비중은 10%다.
이는 전체 ROI가 아니라 수수료가 매출에서 차지하는 비율이다. 서비스 제공에 필요한 연산·데이터·운영 비용까지 포함하면 남는 금액은 더 줄어든다. 단가가 낮은 API일수록 결제 한 건의 고정 비용이 제품의 수익성을 크게 좌우하는 이유다.
호출량이 늘어날 때 수수료 총액은 건수에 비례해 증가한다. 규모가 커진다는 이유만으로 건당 비용이 자동으로 줄어들지는 않는다. 사람보다 훨씬 자주 호출하는 에이전트 워크로드에서는, 요청 단위를 그대로 정산 단위로 삼는 설계를 특히 신중하게 검토해야 한다.
V2가 세션과 선불 모델을 연 이유
2025년 12월 11일 공개된 x402 V2는 일회성 결제에서 더 넓은 모델로 확장됐다. 지갑 기반의 재사용 가능한 접근, 세션, 선불과 구독형 흐름을 구성할 수 있게 했고, 반복 접근에서 매번 전체 결제 과정을 거치지 않는 방향을 제시했다.
공식 발표가 고빈도 워크로드의 비용과 지연을 직접 언급한다는 점은 중요하다. LLM 추론이나 여러 도구를 연속 호출하는 에이전트에서는, 각 호출이 독립적인 결제 절차를 기다리는 구조가 부담이 될 수 있기 때문이다.
나는 이 변화를 요청당 결제의 폐기보다는, 과금 경험과 자금 이동을 분리하는 설계로 읽는다. 요청마다 사용량을 측정하고 가격을 매기되, 접근 권한을 재사용하고 실제 정산 횟수는 줄이는 것이다. 무료 구간의 존재만으로 내부 손익 판단을 단정할 수는 없지만, 제품의 경제성을 설계할 때 무엇을 줄여야 하는지는 분명해진다.
작게 사용하고, 모아서 정산한다
현재 CDP 문서는 배치 정산을 이 문제의 한 해법으로 설명한다. 요청별 바우처는 오프체인에서 검증하고, 이를 모아 한 번의 온체인 거래로 청구할 수 있다. 많은 요청을 처리해도 매 요청마다 facilitator의 온체인 거래 수수료가 발생할 필요는 없는 셈이다.
물론 배치가 모든 비용을 없애지는 않는다. 채널에 자금을 넣거나 환불하고 출금하는 작업도 온체인 거래로 집계될 수 있다. 비교해야 할 것은 API 요청 수 자체보다, 일정한 사용량을 처리하는 동안 실제로 몇 번의 자금 이동과 정산이 필요한가다.
이렇게 보면 마이크로페이먼트의 핵심은 오히려 정산을 얼마나 덜 자주 하느냐에 있다. 사용량은 작은 단위로 기록하면서 정산은 묶어서 처리할 수 있다. 요청당 과금은 그대로 유지하면서도, 요청당 개별 정산의 비용은 피하는 방식이다.
선확보 → 사용 → 후정산
이 관점에서 더 현실적인 제품 모델은 먼저 자금을 확보하거나 일정 금액의 사용을 승인하고, 그 범위 안에서 서비스를 반복 이용한 뒤, 실제 사용량에 따라 정산하는 구조다. 필요하다면 남은 금액은 돌려준다.
선충전 잔액을 차감하는 방식도 가능하지만, 일정 금액을 잠그거나 사용 한도를 승인해 두고 나중에 정산하는 방식도 생각할 수 있다. 어떤 구조를 택하든 사용 가능 금액, 허용 대상, 유효 기간과 환불 조건이 명확해야 한다. 이런 조건은 개별 서비스가 설계할 영역이다.
이 모델은 에이전트가 매번 사람의 결제 승인을 기다리지 않게 하면서도, 호출 빈도와 온체인 정산 횟수를 분리한다. 다만 자금이 묶이는 부담과 채널을 열고 닫는 비용까지 비교해야 하므로, 모든 서비스에 같은 방식이 최선이라고 볼 수는 없다.
x402의 가능성은 여전히 크다. 다만 요청당 결제가 곧 모든 온라인 서비스의 기본 경제 모델이 된다고 기대하기보다는, 무엇을 요청 단위로 측정하고 언제 돈을 움직일지 따로 설계해야 한다. 내가 보는 현실적인 방향은 ‘선확보 → 사용 → 후정산’이다. x402는 구독을 단순히 대체하기보다, 서비스의 사용 방식에 맞춰 결제 레이어의 선택지를 넓히고 있다.