AI 결제 인프라: x402에서 Bankr까지

AI 인프라를 이야기하면 먼저 GPU와 모델이 떠오른다. 하지만 모델이 일을 시작한 뒤에도 필요한 것이 있다. 데이터를 사고 API를 호출하고 다른 에이전트에게 작업을 맡기는 과정에서 누군가는 계속 돈을 내야 한다.

사람이 챗봇을 쓰는 동안에는 사람이 계정을 만들고 구독료를 내면 된다. 에이전트가 여러 서비스를 오가며 작업을 수행하면 이야기가 달라진다. 새 서비스를 찾을 때마다 사람이 가입하고 결제를 승인해야 한다면 작업 흐름은 그 자리에서 멈춘다

PoUW가 AI 연산과 채굴의 경제성을 연결한다면 이 글에서 보는 인프라는 AI가 필요한 자원을 구매하고 받은 대가를 다음 작업에 쓰는 과정을 연결한다. x402, PayAI, Virtuals ACP, Bankr는 이 문제의 서로 다른 부분을 맡는다. 이들을 이해하려면 먼저 결제 표준, 결제 처리 사업자, 에이전트 작업 시장, 운영 도구를 나눠 볼 필요가 있다

에이전트에게 지갑만 주면 해결될까

에이전트가 지갑을 갖는다고 해서 경제 활동을 할 준비가 끝나는 것은 아니다

우선 누구에게 얼마까지 쓸 수 있는지 정해야 한다. 잔액이 있는 것과 그 잔액을 모두 사용할 권한이 있는 것은 다르다. 잘못된 도구 호출이 반복되거나 악의적인 서비스가 높은 가격을 요구할 때 지출을 제한할 장치가 필요하다

가격도 에이전트가 읽을 수 있어야 한다. 사람이 결제 페이지를 보고 판단하는 대신 서비스가 가격, 결제 자산, 수취인, 승인 조건을 기계가 처리할 수 있는 형태로 제시해야 한다. 작업 도중 발견한 API를 한 번 쓰기 위해 긴 가입 절차를 거칠 필요가 줄어들수록 자동화하기 쉬워진다

돈을 냈다는 사실과 일을 제대로 받았다는 사실도 다르다. 송금이 완료됐더라도 데이터가 틀리거나 결과물이 쓸모없을 수 있다. 단순한 API 응답을 구매하는 거래와 다른 에이전트에게 복잡한 작업을 맡기는 거래에는 서로 다른 확인 절차가 필요하다

마지막으로 수입과 지출이 이어져야 한다. 일을 끝내고 돈을 받아도 그 돈으로 다음 모델 호출 비용을 지불할 수 없다면 운영은 다시 멈춘다. 지출 권한, 결제 조건, 작업 확인, 정산, 운영비 재충전이 연결돼야 에이전트가 반복해서 일할 수 있다

x402: 서비스 요청 안에 결제를 넣다

x402는 HTTP 요청에 결제를 붙이는 공개 표준이다. 서비스가 402 Payment Required 응답으로 가격과 결제 조건을 제시하면 구매자는 결제 정보를 서명해 요청을 다시 보낸다. 서버는 결제 검증과 정산을 거쳐 요청한 자원을 돌려준다. Coinbase의 일반적인 흐름은 검증, 작업 실행, 정산을 구분한다

예를 들어 리서치 에이전트가 보고서를 쓰다가 유료 온체인 데이터가 필요해졌다고 해보자. 서비스가 호출 가격과 지원하는 결제 방식을 알려주면 에이전트는 허용된 예산 안에서 이를 구매할 수 있다. 이때 사람에게 매번 결제 화면을 보여줄 필요가 줄어든다. 이 예시는 사용 방식을 설명하기 위한 가정이다

x402 자체는 하나의 체인이나 전용 토큰을 가리키지 않는다. 공식 소개는 이를 인터넷 결제 표준으로 설명한다. 표준의 확산과 특정 토큰의 수요는 별개의 경로다. 채택이 늘 때 실제로 수익을 얻는 주체는 어떤 지갑, 정산 서비스, 유료 API가 선택됐는지에 따라 달라진다

같은 섹터에서 서로 다른 일을 하는 프로젝트들

Coinbase: 표준을 실제 개발 도구로 연결하다

Coinbase CDP는 x402를 API 판매자와 구매자가 사용할 수 있는 SDK와 facilitator로 연결한다. Facilitator는 판매자를 대신해 결제를 검증하고 정산하는 역할을 맡는다. CDP 문서는 이 과정을 기존 결제 화면이나 개별 과금 연동을 줄이는 방식으로 소개한다

여기서 볼 것은 독립적인 x402 코인의 가격이 아니라 개발자가 이 도구를 얼마나 쉽게 붙이고 계속 사용하는지다. 같은 표준을 쓰더라도 어느 결제 처리 사업자를 선택할지는 비용, 지원 네트워크, 장애 대응에 달려 있다

PayAI: 결제 검증과 정산을 맡다

PayAI는 x402 facilitator를 운영한다. 공식 설명에 따르면 서명된 결제를 확인하고 온체인 정산을 제출하며 처리 결과를 서비스에 전달한다. Solana와 EVM 계열을 지원하지만 지갑 자금 마련이나 서비스 품질 평가까지 대신하는 것은 아니다

수익 구조는 API 판매자가 받는 서비스 대금과 구분해야 한다. 현재 요금 문서는 2026년 9월 21일부터 무료 한도 이후 정산 비용을 네트워크 가스비에 30%를 더해 크레딧으로 청구한다고 설명한다. PAYAI로 크레딧을 구매할 때의 10% 할인도 명시한다. 다만 USDC로 가격이 책정된 API의 고객이 PAYAI를 보유할 필요는 없다

이 구조에서 확인할 것은 처리량만이 아니다. 가스비를 제외하고 얼마가 남는지, 무료 한도를 넘겨 계속 비용을 내는 판매자가 늘어나는지, 할인 목적의 토큰 사용이 실제로 발생하는지가 더 직접적인 지표다

Virtuals ACP: 다른 에이전트에게 일을 맡기다

Virtuals의 ACP는 에이전트 사이의 작업 합의, 제공, 평가를 다룬다. 현재 EconomyOS 문서는 Client, Provider, Evaluator 역할과 서비스·자금 이체·구독 작업을 설명한다. 제안된 ERC-8183 표준의 참조 구현이며 여러 체인을 지원한다

x402가 서비스 호출에 결제 조건을 전달한다면 ACP는 “무엇을 맡겼고 누가 결과를 평가하는가”까지 다루는 쪽에 가깝다. 결제 서명이 유효하다는 사실만으로 결과물의 품질이 보장되지는 않는다. 복잡한 작업을 맡기는 시장에는 수행 주체와 평가 기준이 함께 필요하다

이곳에서는 등록된 에이전트 수보다 보조금 없이 반복되는 유료 작업과 실제 결과물이 중요하다. 또한 ACP의 사용량 전체가 같은 비율로 VIRTUAL 수요가 된다고 계산해서는 안 된다. 어떤 작업이 어떤 자산으로 결제되고 생태계 수익이 어디로 배분되는지 따로 확인해야 한다

Bankr: 지갑과 수입을 에이전트 운영비에 연결하다

토큰을 만들고 끝나는 구조에서 계속 운영하는 구조로

Bankr의 제품 소개는 에이전트의 지갑, 토큰 발행, 수수료 수입, 추론 비용을 연결하는 금융 도구를 설명한다. 관심을 둘 부분은 각각의 기능보다 들어온 돈을 다음 작업에 사용할 수 있게 연결하는 과정이다

LLM Gateway에서는 지갑 자산을 크레딧으로 충전해 모델을 사용한다. 자동 충전과 수령한 창작자 수수료를 이용한 충전도 지원한다. 모델을 호출할 때마다 사람이 결제 계정을 바꾸지 않고 지갑의 자금을 운영비로 전환하는 방식이다

x402 Cloud는 에이전트나 개발자가 유료 API를 제공하는 쪽에 해당한다. Base의 USDC 결제를 기본으로 지원하며 다른 지원 토큰으로도 가격을 설정할 수 있다. Gateway가 모델을 쓰기 위해 돈을 내는 기능이라면 Cloud는 서비스를 팔고 돈을 받는 기능이다

위 구조에서 토큰 거래 수수료와 API 판매 대금은 성격이 다르다. 전자는 런치한 토큰의 거래 활동에 의존하고 후자는 고객이 서비스에 지불한 돈이다. 토큰 거래가 활발해서 운영비를 마련했다는 사실만으로 서비스 자체에 유료 수요가 있다고 볼 수는 없다

Cloud 요금 문서는 무료 구간을 넘긴 표준 Pro 요금에서 결제액의 5%를 플랫폼 수수료로 설명한다. 무료 적용 조건과 기업별 요금은 별도다. 여기서 발생하는 플랫폼 매출이 어떤 규칙으로 BNKR에 배분되는지는 토큰 런치 수수료와 나눠 확인해야 한다

Musebook: 연결된 제품이 실제로 쓰인 초기 사례

2026년 9월 17일 Bankr가 배포한 발표는 개발자 @wyn_eth가 Muse와 함께 만든 소셜 네트워크 Musebook을 소개했다. Bankr로 발행한 토큰을 Robinhood Chain의 토큰화 META와 페어링하고 Musetown의 화폐로 사용하는 사례다

이 사례는 에이전트가 만든 서비스에 지갑과 토큰 발행 기능을 연결할 수 있음을 보여준다. 다만 발표의 범위는 개발자 구현과 Bankr 도구 사용 사례다. 이를 Meta나 Robinhood 전체가 Bankr를 독점 채택했다는 뜻으로 확대해서는 안 된다. 다음에 볼 것은 사례의 이름보다 이후에도 독립적인 사용자가 서비스를 쓰고 대가를 지불하는지다

네 프로젝트를 한 표로 보면

국내 접근성도 이 섹터를 보는 하나의 배경이다. 업비트는 VIRTUAL과 최근 신규 거래 지원으로 표시된 POD에 Base 네트워크를 안내한다. Base 자산을 접하는 경로가 늘어난 만큼 BNKR도 국내 접근성이 넓어질 가능성을 관찰할 수 있다. 다만 이는 향후 접근성에 대한 기대이며 프로젝트의 실사용 수익을 설명하는 근거는 아니다. x402와 PayAI, 현재 ACP 역시 Base 하나에만 묶인 인프라는 아니다

Bankr 수익은 어떻게 BNKR에 연결되나

제품을 많이 쓰는 것과 BNKR에 돈이 돌아오는 것은 다른 문제다. 이 연결은 실제 수수료 분배 규칙에서 확인해야 한다

Bankr의 신규 Doppler 런치 문서는 거래 수수료를 총 1.75%로 제시한다. 거래대금 대비 창작자 0.665%, 자체 토큰 LP 0.285%, 프로토콜 0.475%, BNKR 바이백 0.2375%, Doppler 약 0.0875%로 나뉜다. 기존 런치는 생성 당시 요율을 유지하므로 모든 과거 거래에 이 비율을 적용할 수는 없다

예를 들어 이 요율이 적용되는 거래대금이 $10,000이면 총 거래 수수료는 $175, BNKR 바이백 항목은 $23.75다. 이는 구조를 설명하는 계산이며 관측된 매출이 아니다. 거래량이 늘면 해당 바이백 항목도 커지지만 거래량의 질과 지속성은 여전히 따로 봐야 한다

현재 스테이킹 화면은 Bankr 런치 수익의 30%로 BNKR를 구매해 스테이커에게 지급한다고 설명한다. 이 30%는 런치 수익을 기준으로 한 비율이고 위 도표의 0.2375%는 거래대금을 기준으로 한 비율이다. 같은 수익이 이미 어느 단계에 포함돼 있는지 확인하지 않고 둘을 별개의 추가 매수로 더하면 과대 계산할 수 있다

바이백과 소각도 구분해야 한다. 구매한 토큰을 스테이커에게 지급하면 수령자가 다시 매도할 수 있다. 매수 흐름이 있다는 사실만으로 유통량이 영구적으로 줄었다고 볼 수는 없다. 2026년 10월 5일 확인 당시 스테이킹 화면에 표시된 주간 지급은 한 차례였다. 장기간의 지급 지속성을 판단하려면 이후 기록이 더 필요하다

앞으로 무엇을 확인할까

이 섹터가 성장하는지 볼 때는 거래 건수 하나로 판단하기 어렵다. 아주 적은 금액을 주고받거나 같은 주체가 반복 호출해도 건수는 늘어난다. 실제로 고객이 필요해서 비용을 내는 활동인지 확인해야 한다

• 유료 고객의 반복 사용. 한 번 체험한 지갑보다 여러 기간에 걸쳐 다시 비용을 내는 고객이 늘어나는지 본다
• 서비스를 팔고 남는 돈. 받은 대금에서 추론·데이터·정산·플랫폼 비용을 빼도 에이전트가 다음 작업을 이어갈 수 있는지 본다
• 외부에서 오는 작업. 같은 운영자끼리 만든 거래나 보조금 중심 활동을 제외해도 실제 결과물을 사는 고객이 있는지 본다
• 토큰 거래와 서비스 매출의 구성. Bankr 에이전트의 운영비가 런치 거래 수수료에서 오는지 API 고객에게서 오는지 나눠 본다
• 토큰으로 이어진 실제 배분. 발표된 비율보다 바이백 집행, 지급 내역, 해당 수익의 원천을 확인한다
• 거래가 줄어든 뒤의 운영. 토큰 거래가 식어도 유료 서비스 수입으로 모델 비용을 감당하는 사례가 남는지 본다

에이전트가 직접 결제할 수 있게 되면 사람이 매번 가입하고 승인하던 구간을 줄일 수 있다. x402는 결제 조건을 전달하고 facilitator는 이를 정산한다. ACP는 작업 관계를 다루고 Bankr는 받은 돈과 운영비를 연결한다

내가 이 섹터에서 가장 관심을 두는 변화는 토큰을 발행하는 에이전트가 많아지는 것보다 일을 팔아 다음 작업의 비용을 버는 에이전트가 늘어나는 것이다. 그 과정이 반복돼야 결제 인프라가 일시적인 거래 도구를 넘어 실제 경제 활동의 기반이 될 수 있다. 토큰의 가치는 그 이후에 어떤 수익이 어떤 규칙으로 연결되는지를 통해 평가해야 한다

공식 문서와 서비스 화면 확인 기준: 2026년 10월 5일 KST. 수수료율은 해당 문서가 설명하는 제품·런치에 한정한다. 작동 예시와 도표의 반복 경로는 설명을 위한 가정이며 향후 접근성·수익 지속성은 해석이다.