cz-agents 구축에 관한 시리즈 중 일부 → 내부 구조(under the hood).

지난 논의 요약

지난 6월, 저는 에이전트 결제(agentic payments)의 세 가지 진영인 x402, 카드 토큰(card tokens), 그리고 은행(banks)을 비교하며, x402가 기계 간 마이크로 결제(machine-to-machine micropayments)를 담당하게 될 것이고, 카드와 은행이 나머지를 나누어 가질 것이라고 주장했습니다. 프로토콜의 기초, 402 상태 코드(status code)의 작동 방식, 또는 왜 아주 적은 금액에서는 카드가 경제적으로 맞지 않는지에 대해서는 반복하지 않겠습니다. 복습이 필요한 분들은 해당 기사에서 확인하실 수 있습니다.

이 글은 다른 것에 관한 것입니다. 몇 주가 지났고, 수치와 대형 플레이어들의 지원 모두 한 자릿수(order of magnitude)만큼 급증했습니다. 그리고 처음으로, 저는 그 수치들을 제 자신의 로그에서 실제로 보고 있는 것과 비교할 수 있게 되었습니다. 이 두 가지 사이의 격차가 다음에 이어질 내용의 핵심입니다.

눈여겨볼 수밖에 없는 수치들

더 정직한 접근 방식이기에 x402에 유리한 내용부터 시작하겠습니다. Chainalysis의 집계 데이터에 따르면, 이 프로토콜은 지금까지 약 590,000명의 구매자와 100,000명의 판매자 사이에서 1억 6,900만 건 이상의 결제를 처리했습니다. 이것은 더 이상 컨퍼런스 데모 수준이 아닙니다.

거래량보다 더 흥미로운 것은 구조적 변화입니다. 1달러 이상의 거래 비중이 2025년 초 49%에서 2026년 초 약 95%로 상승했습니다. 다시 말해, x402는 마이크로 센트(micro-cents)를 위한 장난감 단계를 벗어나 실제로 장부에 기록되는 금액을 처리하기 시작했습니다. API 쿼리당 1센트 미만의 금액을 지불하기 위한 호기심 정도로 이 프로토콜을 치부했던 사람들은 과거의 스냅샷을 보고 있는 것입니다.

무엇보다도, 암호화폐 거품 열광자(crypto-bubble enthusiasts)라고 무시하기 어려운 라인업이 구성되었습니다:

• Stripe는 2026년 2월 10일, 자사의 Machine Payments 제품(Base 네트워크 상의 USDC) 프리뷰에서 x402 지원을 시작했습니다.
• Ripple은 2026년 6월 21일, XRP Ledger에 네이티브 x402를 추가했습니다.
• AWS는 Coinbase 및 Stripe와 협력하여 Bedrock AgentCore Payments에 x402를 구축했으며, CloudFront 및 WAF에서 에이전트 트래픽을 수익화할 수 있도록 지원합니다. Amazon의 에지(edge) 뒤에 있는 사이트들은 핵심 애플리케이션을 건드리지 않고도 에지에서 즉시 에이전트에게 비용을 청구할 수 있습니다.
• Google은 x402 Foundation의 창립 참여자이며, 자사의 Agent Payments Protocol (AP2)에 이 프로토콜을 구축했습니다.
• x402 Foundation 자체는 2025년 9월 Coinbase와 Cloudflare에 의해 설립되었으며, 2026년 4월 2일 Linux Foundation 산하의 공식 거버넌스로 이전되었습니다. 이러한 이동을 통해 프로토콜은 단일 거래소의 소유가 아니게 되었습니다.

Stripe, Amazon, Google, Ripple이 모두 단일 연도 내에 동일한 표준을 채택하고, 재단이 이를 중립적인 거버넌스에 넘긴다는 것은 보통 연극을 꾸미는 것이 아니라 인프라가 구축되고 있다는 신호입니다. 적어도 외부에서 보기에는 그렇게 보입니다.

내 서버에서 보이는 것: 아무것도 없음

나는 체코 기업 등록부, 실사(due diligence), 제재 목록(sanctions lists), 파산(insolvency), 중앙은행 환율(FX rates), 부가가치세(VAT), 유럽 기업 등록부, 부동산 데이터 등 8개의 공개 MCP 서버와 1개의 유료 서버를 운영하고 있습니다. 이들은 에이전트 경제(agentic economy)의 맥락에서 논의되는 바로 그 유형의 서비스들입니다: 기계 판독 가능 데이터(machine-readable data), 작은 쿼리(query), 명확하게 제한된 답변, 그리고 인간이 이를 결제하기 위해 양식을 작성해야 할 이유가 없는 서비스들 말입니다.

이 모든 서버를 통해 처리된 총 에이전트 결제 건수: 0건.

누군가 이를 헤드라인으로 만들기 전에, 불편한 진실을 먼저 밝혀두어야겠습니다. 그렇지 않으면 여러분이 직접 알아내어 정답을 맞히게 될 테니까요. 제 서버들은 x402를 수락하지 않습니다. 서버에는 지갑(wallet)이 없고, 결제 조건이 포함된 402 상태 코드(status code)를 반환하지 않으며, 서명된 스테이블코인(stablecoin) 결제를 검증할 수도 없습니다. 저에게 들어오는 돈은 Stripe 구독과 티어 제한(tier limits)이 있는 API 키를 통해서만 전달됩니다. 단일 쿼리에 대해 저에게 비용을 지불하려는 에이전트(agent)는 그럴 방법이 없습니다.

따라서 결제 건수가 0건이라는 사실은 x402에 반하는 증거가 아닙니다. 그것은 저에 대한 증거입니다. "봐라, 아무도 이 프로토콜을 사용하지 않는다"라고 결론짓는 것은 저렴한 수법입니다. 단지 그것을 무너뜨리기 위해 저의 무행동(inaction)을 가지고 허수아비(straw man)를 만드는 것이니까요. 결제를 수락할 수 없는 서버에서 결제가 발생하지 않았다는 사실은 수요에 대해 아무것도 말해주지 않습니다.

흥미로운 부분은 다른 것입니다. 로그에 남아 있는 무언가 말입니다.

x402 경제에서 도착하는 유일한 것들은 정찰대뿐입니다

제 액세스 로그(access logs)에는 402.ad-mcp-probe라고 자신을 식별하는 프로브(probe)가 정기적으로 나타납니다. 이것은 에이전트 경제(agentic economy)를 위한 검색 엔진이라고 스스로를 설명하는 402.ad 카탈로그에 속해 있습니다. 이 프로브는 단 하나의 서버만 찌른 것이 아니라, 체계적으로 9개 서버 전체를 훑었습니다. 그리고 혼자가 아닙니다. 제 로그에는 누가 무엇을 할 수 있는지 지도로 그려내는 유사한 인덱싱(indexing) 서비스 함대(fleet)가 통째로 나타납니다.

그 카탈로그 뒤에 숨겨진 논리가 실질적인 부분입니다. 이 카탈로그는 두 가지 카테고리를 인덱싱합니다: "MCP 서버"와 "x402 API"입니다. 프로브가 무료 응답을 반환하는 엔드포인트(endpoint)에 도달하면 첫 번째 버킷(bucket)에 분류합니다. 만약 402 또는 401을 반환하는 엔드포인트에 도달하면, 이를 유료이며 잠재적으로 x402와 호환 가능한 것으로 표시합니다. 새로운 서비스를 등록하기 위한 자체 프로그래밍 인터페이스(programmatic interface) 비용은 0.10 USDC이며, x402를 통해 지불할 수 있습니다. 에이전트 경제의 카탈로그가 에이전트 경제의 프로토콜을 사용하여 리스팅(listing) 비용을 청구하는 것입니다. 이것은 단순히 프로토콜을 인덱싱하는 서비스가 아니라, 프로토콜을 직접 사용하는 서비스입니다.

이 글이 존재하는 단 하나의 문장으로 요약하자면 이렇습니다: x402 경제 전체에서 실제로 저에게 도달한 것은 제가 결제를 수락할 수 있는지 확인하는 탐사(probes)뿐이었습니다. 지갑을 가진 에이전트(agents)가 아닙니다. 수요(demand)도 아닙니다. 그저 매퍼(mappers)들뿐입니다.

인프라가 먼저 구축됩니다. 유료 트래픽이 발생하기 전에 카탈로그(catalogs)는 누가 결제를 수락할 수 있는지 목록을 작성합니다. 이것은 불만이 아니라 관찰 결과입니다. 하지만 이는 두 가지 방식으로 해석될 수 있으며, 정직하려면 두 가지 모두를 살펴봐야 합니다.

동일한 현상에 대한 두 가지 해석

첫 번째 해석: 기차보다 먼저 놓이는 철로. 모든 결제 네트워크가 형성되는 방식입니다. 누군가 카드로 결제하기 전에 단말기(terminal)가 존재해야 하며, 단말기가 존재하기 전에 누군가는 가게들을 돌아다니며 누가 단말기를 원하는지 파악해야 합니다. 매핑(mapping) 단계는 항상 수요에 앞서며, 위의 수치들은 기차가 이미 어딘가에서 달리고 있음을 시사합니다. 단지 나의 철로 위가 아닐 뿐입니다. 만약 이것이 순전히 과장(hype)뿐이었다면, Stripe는 제품을 출시하지 않았을 것이고, AWS는 이를 CloudFront 과금 계층(billing layer)에 포함시키지 않았을 것이며, Linux Foundation은 이를 지원하지 않았을 것입니다.

두 번째 해석: 결코 도착하지 않을 기차를 위한 철로. 이것 또한 모든 기술 버블(tech bubble)이 시작되는 방식입니다. 열광자들이 인프라를 구축하고, 카탈로그가 이를 인덱싱하며, 생태계는 스스로의 성장을 축하합니다. 하지만 최종 고객은 결코 도착하지 않습니다. 왜냐하면 그들의 문제는 다른 더 저렴한 방식으로 해결 가능했기 때문입니다. 카탈로그에서 보내는 탐사(probes)는 수요가 아닙니다. 그것은 수요가 실현될 것이라는 도박에 걸린 타인의 매몰 비용(sunk cost)일 뿐입니다.

저는 이 두 가지 해석 중 어느 것이 맞는지 모르며, 아는 척하지도 않을 것입니다. 하지만 저는 어떤 신호를 찾아봐야 하는지는 알고 있으며, 그것이 더 유용합니다:

• 단순히 존재 여부를 묻는 것이 아니라, 가격을 묻는 정찰대(probe)가 도착할 것인가? "카탈로그에 당신이 있습니다"와 "이 쿼리의 비용은 얼마입니까?"의 차이는 지도와 시장의 차이입니다.
• 401 오류를 받았을 때 실제로 결제를 시도하는 에이전트(agent)가 로그에 나타날 것인가? 오늘날 에이전트들은 거절당하면 그냥 떠나버립니다. 에이전트 중 하나가 마침내 결제를 통해 거절을 해결하려고 시도할 때, 트래픽의 본질은 변화해 있을 것입니다.
• 인간 고객이 물어볼 것인가? 가장 강력한 신호는 기계가 만드는 것이 아닙니다. 에이전트를 구축하는 누군가가 구독 모델이 자신의 니즈에 맞지 않는다는 이유로 단위당 비용을 지불하고 싶다며 저에게 메시지를 보낸다면, 논쟁은 끝난 것입니다.

저는 아직 이 세 가지 신호 중 단 하나도 보지 못했습니다. 이것은 의견이 아니라 사실이며, 제 데이터를 바탕으로 x402 수요에 대해 솔직하게 주장할 수 있는 유일한 사실입니다.

그렇다면 x402를 활성화해야 할까요?

이것은 위의 수치들을 읽은 후 모든 API 운영자가 스스로에게 던지는 질문입니다. 보편적인 정답은 없기에, 저의 사례를 통해 이 문제를 풀어보겠습니다.

찬성 (For). 에이전트에게 장벽은 제로입니다. 등록도, 키(key)도, 인간의 액세스 승인을 기다릴 필요도 없습니다. 제 데이터는 정확히 단위당 비용을 지불할 가치가 있는 작은 쿼리들입니다. 기업 확인 한 번, 환율 확인 한 번, 제재 스캔 한 번 같은 것들 말이죠. Stripe, AWS, Google에 의해 생태계가 추진되고 있는 지금, 통합 경로는 계속해서 짧아질 것입니다. 오늘 일주일이 걸리는 작업이 1년 후에는 라이브러리와 세 줄의 설정만으로 가능해질 수 있습니다.

반대 (Against). 저의 유료 고객은 구독을 이용하는 사람들이지, 지갑을 가진 에이전트가 아닙니다. USDC로 결제한다는 것은 체코의 맥락에서 세무 및 회계 작업의 완전히 새로운 장을 의미하며, 이는 아직 아무도 실제로 표현하지 않은 수요를 위해 제가 떠안아야 할 오버헤드(overhead)입니다. 게다가, 추가되는 모든 결제 경로는 고장 날 수 있는 요소를 하나 더 늘리는 것입니다. 즉, 더 많은 코드, 더 넓은 공격 표면(attack surface), 그리고 이미 티어(tiers), 할당량(quotas), 쿼리당 제한(per-query limits)을 추적하고 있는 시스템에서 모니터링해야 할 항목이 더 늘어남을 의미합니다.

결정: 활성화하지는 않겠지만, 게이지(gauge)는 설정해 두겠습니다. 이것은 제가 x402를 믿지 않기 때문이 아닙니다. 저는 지난 6월과 마찬가지로 x402를 믿습니다. x402는 결국 기계 간 마이크로페이먼트 (machine-to-machine micropayments)를 장악할 것입니다. 제가 활성화하지 않는 이유는 "프로토콜이 성장하고 있다"와 "누군가 나의 특정 데이터를 단위당 구매할 것이다" 사이에는 제가 뒷받침할 데이터가 없는 거대한 가정이 존재하기 때문입니다. 오늘 x402를 활성화한다는 것은 타인의 수치에 기반하여 터미널을 구축하고, 저를 방문하는 매퍼(mappers)들이 언젠가 구매자를 데려오기를 바라는 것을 의미합니다.

대신 제가 할 일은 더 저렴하고 더 많은 정보를 제공하는 방식입니다. 바로 이전 섹션에서 언급한 세 가지 신호를 측정하는 것입니다. 저는 이미 제 서버에서 트래픽 분류 (traffic classification)를 수행하고 있습니다. 저는 카탈로그 프로브 (catalog probe)와 실제 도구 호출 (tool call)을 구분할 수 있습니다. 참고로, 이 구분이야말로 이 분야의 수많은 확신에 찬 채택 수치들이 무너지는 지점이기도 합니다. 결제를 원하는 첫 번째 에이전트가 제 로그에 나타나거나, 첫 번째 인간이 단위당 결제를 요청할 때, 그것은 단순한 트렌드가 아니라 증거에 기반한 베팅이 될 것입니다. 그때까지 기다리는 것이 저에게는 가장 저렴한 옵션입니다. 또한 이는 되돌릴 수 있는 선택이며, 이는 절반만 구축된 결제 레이어 (payment layer)에 대해서는 할 수 없는 말입니다.

여기서 얻은 교훈

"x402가 폭발적으로 성장하고 있는가?"라는 질문에 대한 답은, 사용 가능한 모든 지표를 기준으로 볼 때 "예"입니다. 제 로그는 그 사실을 부정하지 않지만, 제 로그는 그것에 대해 아무것도 모르기 때문입니다. 이것이 솔직한 버전입니다. 결제 게이트웨이 (payment gateway)가 없는 서버에서 결제가 0건이라는 것은 프로토콜에 대한 데이터 포인트가 아니라, 저의 우선순위에 대한 데이터 포인트입니다.

프로토콜에 대한 실제 데이터 포인트는 프로브 (probe)입니다. 누군가는 누가 기계 결제를 수락할 수 있는지 파악하기 위해 돈을 쓰고 있으며, 그 지도를 팔 대상이 생기기도 전에 이 작업을 수행하고 있습니다. 이것은 거대한 무언가의 전조이거나, 결코 형성되지 않을 시장에 대한 값비싼 인벤토리 (inventory) 중 하나일 것입니다. 오늘 이 두 가지 중 어느 쪽인지 절대적인 확신을 가지고 말하는 사람은 누구든 당신에게 무언가를 팔려고 하는 것입니다.

이상하게도, 그 불확실성은 저를 불안하게 만들지 않습니다. 그것은 제가 지금 당장 결정을 내릴 필요가 없음을 의미합니다. 저는 그저 무엇을 지켜봐야 하는지만 알면 됩니다. 수요가 나타나면, 보도 자료를 통해 읽기 전에 제 로그(logs)에 먼저 나타날 것입니다. 그것이 제가 거대 플레이어들에 대해 가진 유일한 우위(edge)입니다. 저는 미리 베팅할 필요가 없습니다.

x402 채택 수치 출처: Chainalysis — x402 에이전트 결제 (agentic payments) 채택. 제 서버의 트래픽 데이터는 제 MCP 서버 포트폴리오 전반의 액세스 로그 분류 (access log classification)를 통해 가져왔습니다.