몇 주에 걸쳐 저는 Base 네트워크 상에서 작은 x402 서비스를 구축하여 출시했습니다: token-risk.com. 이는 ERC-20 토큰 및 지갑 주소에 대해 결정론적(deterministic) 구조적 리스크 보고서를 반환하는 호출당 결제(pay-per-call) API입니다. 에이전트들은 호출당 0.01달러의 USDC를 지불하며, 회원 가입이나 API 키가 필요하지 않습니다. 이 서비스는 현재 라이브 상태이며, 온체인(on-chain)에서 실제 자금으로 결제(settle)되고, AI 에이전트들이 실제로 읽는 디스커버리 레이어(discovery layer)에 인덱싱되어 있습니다.

이것은 솔직한 기록입니다. 여기 있는 모든 수치는 0을 포함하여 모두 실제입니다. 결제 트랜잭션(settlement transactions)은 Base 상에 있으며, 직접 확인할 수 있도록 링크를 제공합니다. 저는 이 글을 쓰기 전에 중단 기준을 미리 약속했습니다: 출시 후 8주가 지났을 때, 외부 유료 호출이 0에 머물러 있다면 이 프로젝트에 쓰는 시간을 중단하겠습니다.

우선, 수치부터 살펴보겠습니다

오늘 기준, x402scan 데이터는 다음과 같습니다:

• 15건의 트랜잭션 (transactions)
• 총 거래량(total volume) 0.15달러
• 2개의 구매자 주소 (buyer addresses)

그리고 가장 중요한 수치: 외부 구매자 — 0명.

두 구매자 주소 모두 제 것입니다. 하나는 결제 루프를 검증하기 위해 사용하는 테스트 클라이언트이며, 다른 하나는 디스커버리 실험을 실행하기 위해 자금을 충전한 AgentCash 지갑입니다. 저는 제가 제 통계를 읽을 때 스스로를 제외할 수 있도록 제가 제어하는 모든 주소에 대한 작은 원장(ledger) 파일을 유지하고 있습니다.

사건 1: 너무 길었던 설명. 저는 서비스를 더 쉽게 발견할 수 있도록 서비스 메타데이터를 풍부하게 만들었습니다. 즉, 더 상세한 설명과 명확한 스키마(schema)를 추가한 것입니다. 이렇게 풍부해진 설명은 문자열 길이를 55자에서 717~756자로 늘려놓았고, 이는 결제 촉진자(payment facilitator)가 결제 요구 사항에 적용하는 500자 제한을 초과했습니다. 시스템이 충돌하거나 테스트가 실패(red)하지는 않았습니다. 촉진자는 모든 결제를 조용히 거부했을 뿐입니다. 왜냐하면 해당 제약 조건이 제가 테스트로 감시하지 못하는 제공자(provider) 측에 존재했기 때문입니다. 저는 정확한 길이 오버플로(overflow)를 찾아냈고, 결제 템플릿(payment template)에 부팅 타임 길이 가드(boot-time length guard)를 적용하여 이를 수정했으며, Base 네트워크에서의 실제 유료 정산(tx 0xf3d2504961...481b8e08)을 통해 수정 사항을 확인했습니다. 이제 제 어떤 엔드포인트(endpoint)에서도 이 문제가 반복될 수 없습니다. 모든 엔드포인트가 구축되는 기반인 템플릿에 가드가 포함되어 있기 때문입니다.

사건 2: 제가 완전히 설명하지 못했던 장애 구간. 이후, 특정 경로(route)가 좁은 시간대 내에 다시 실패하기 시작했습니다. 솔직하게 말씀드리면, 제가 조사하러 갔을 때 해당 시간대의 서버 로그는 이미 로테이션(rotate)되어 사라진 상태였습니다. 그래서 유력한 가설을 세울 수는 있었지만, 근본 원인(root cause)을 결코 _증명_할 수는 없었습니다. 저는 무엇이 그 특정 실패들을 유발했는지 확실히 알지 못하며, 아는 척하지도 않을 것입니다.

별개로 제가 해결한 것은 조사 과정에서 발견한 실제 문제였습니다. 제 리소스 URL이 에지(edge)에서의 TLS 종료(termination) 이후 http://로 광고되고 있었고, CDP 디스커버리 레이어(discovery layer)가 다음과 같은 특정 이유로 이를 거부하고 있었습니다: "프로토콜 유형이 http일 때 리소스는 'https://'로 시작해야 합니다." 저는 명시적인 퍼블릭 오리진(public origin)을 고정함으로써(메인넷에서는 HTTPS가 필수이며 폴백(fallback)은 없음) 이를 수정했습니다. 그리고 다음 정산이 이루어진 직후 서비스가 CDP Bazaar 카탈로그에 나타났습니다. 여기서 "직후"라는 표현은 두 개의 데이터 포인트를 통한 관찰 결과일 뿐, 촉진자가 누군가를 인덱싱(indexing)하는 속도에 대한 약속은 아닙니다.

두 사례 모두에서 얻은 교훈이자, 새로운 빌더(builder)에게 문신으로 새겨주고 싶은 교훈은 다음과 같습니다: 실패는 당신의 테스트가 볼 수 없는 경계(boundary)에서 발생하며, 그 순간의 증거를 포착하지 못하면 증거는 증발해 버립니다. 메인넷(mainnet)에서의 유료 프로브(paid probe)는 이제 제 배포 후 체크리스트(post-deploy checklist)의 영구적인 항목이 되었습니다. 이는 단순한 테스트가 아니라 심박수(heartbeat)와 같으며, 저는 다른 무엇을 하기 전에 로그(logs)를 먼저 확보합니다.

그다음, 에이전트가 스스로 이를 찾아내도록 시도했습니다

이 부분이 제가 가장 유용하다고 느꼈으면서도, 동시에 가장 뼈아프게 다가온 대목입니다. 단 한 번의 실행, 단 하나의 토큰, 세 단계의 힌트 — 그러니 이를 벤치마크(benchmark)가 아닌 하나의 일화(n=1)로 취급해 주십시오.

저는 가장 널리 사용되는 x402 클라이언트인 AgentCash를 새로운 에이전트 워크스페이스(workspace)에 설치하고, 특정 Base 토큰이 안전한지 물었습니다. 해당 토큰은 알려진 허니팟(honeypot)이며, '정답'은 명확합니다. 유일한 질문은 에이전트가 그 정답에 도달하기 위해 제 서비스를 찾아내고 사용하는가였습니다.

• Cold ("이 토큰이 안전한가요?"): 에이전트는 honeypot.is, BaseScan, 그리고 로우 RPC 호출(raw RPC calls)을 사용하여 문제를 해결했습니다. 도구가 설치되어 준비되어 있었음에도 불구하고, 제 서비스에는 전혀 손을 대지 않았습니다.
• Warm ("AgentCash가 있습니다 — 이 토큰을 확인하세요"): 에이전트는 AgentCash를 사용했고 실제 돈을 썼습니다 — 하지만 다른 세 가지 서비스에 사용했습니다. 제 서비스는 카탈로그(catalog)에 있었지만, 호출되지 않았습니다.
• Named ("agentcash를 통해 token-risk를 사용하세요"): 에이전트는 동일한 경로 이름(route name)을 가진 다른 서비스를 찾아냈고, 그 서비스에 결제를 시도했습니다. 제가 미처 고려하지 못했던 네이밍 충돌(naming collision)이었습니다.

제가 명시적으로 교정해 준 후에야 — "그게 아니라, token-risk.com을 말하는 겁니다" — 에이전트는 올바른 출처를 발견하고, 이를 호출하여 정확하게 결제(tx 0x8ac953da...98ed81)를 완료했습니다. 에이전트가 돌려받은 보고서는 이전의 모든 스캔 결과와 정확히 일치했습니다.

세 단계, 세 번의 실패. 그중 어느 것도 제품의 결함은 아니었습니다 — 엔진은 실행될 때마다 매번 정확했습니다. 그것들은 수만 개의 카탈로그 항목 중에서, 적어도 하나는 제 것과 이름이 동일한 항목들 사이에서 발견되고 선택되는 것의 실패였습니다.

제품 자체가 아직 할 수 없다고 인정하는 것

시사점을 정리하기 전에 정직한 수치를 하나 더 말씀드리겠습니다. 저는 양극단에 있는 두 주소를 대상으로 지갑 위험 (wallet-risk) 엔드포인트를 실행했습니다. 하나는 수년간의 온체인 (on-chain) 이력을 가진 지갑이었고, 다른 하나는 제가 5분 전에 생성한 지갑이었습니다. 결과 보고서는 바이트 단위까지 완전히 동일하게 나왔습니다. 그것이 해당 엔드포인트의 현재 한계입니다. 즉, 이 엔드포인트는 구조적 정보(컨트랙트 탐지, 검증 상태, 소유 패턴)만 다룰 뿐, 두 지갑을 구분할 수 있는 행동 신호 (behavioral signal)는 아직 갖추고 있지 않습니다. 저는 이 작업을 추측에 기반해 구축하기보다는 실제 수요에 따라 진행하기 위해 제한을 두고 있습니다.

제가 실제로 배운 것

2026년 중반의 기계 결제 가능 API (machine-payable API)의 병목 현상은 코드가 작동하는지 여부나 결제 레일 (payment rail)이 작동하는지 여부가 아닙니다. 이 두 가지는 이미 해결되었으며 오늘날 실제로 USDC를 정산하고 있습니다. 병목 현상은 바로 **발견 (discovery)과 모호성 해소 (disambiguation)**입니다. 에이전트는 귀하의 서비스가 존재한다는 것을 알아야 하고, 그것이 의도에 맞는 적절한 도구인지 결정해야 하며, 이름이 충돌하는 혼잡한 카탈로그 중에서 이를 정확하게 선택해야 합니다. 이것은 엔지니어링 문제가 아니라 배포 (distribution) 문제이며, 저는 제 "배포" 노력의 대부분을 이 사실을 고통스럽게 배우는 데 소비했습니다.

이제 비정형 호스트 (non-canonical host)에서의 유료 호출은 정형 URL (canonical URL)을 포함하는 기계 판독 가능한 421 응답을 받게 됩니다. 이는 테스트되지 않은 교차 호스트 결제 경로를 제공하는 대신 명확하게 거절하는 방식입니다 (리다이렉트 불가: x402 클라이언트는 결제 흐름 중간에 리다이렉트를 따를 것이 보장되지 않음). 저는 이제 서비스를 단순 이름이 아닌 전체 오리진 URL (full origin URL)로 식별하며, 그 과정에서 발생하는 발견의 마찰 (discovery friction) 문제를 클라이언트 유지 관리자들에게 보고했습니다: https://github.com/Merit-Systems/agentcash-skills/issues/24. 단 하나의 해결책이 발견 문제를 해결할 것이라고 거짓말하지는 않겠습니다. 약간의 변화는 줄 수 있겠지만, 정직한 입장은 이렇습니다. 저는 아직 모르며, 몇 주 후에 실제 데이터를 갖게 될 것입니다.

열린 질문

만약 여러분이 x402 서비스를 구축하고 있고, 여러분이 제어할 수 없는 에이전트들로부터 외부 유료 호출(paid calls)을 받고 있다면 — 무엇이 여러분을 발견 가능하게(findable) 만들었는지 진심으로 알고 싶습니다. 제가 보기에는 발견 레이어(discovery layer)가 여전히 "1998년의 야후" 수준이라, 구매자들이 아직 그곳에 없는 것인지 아니면 단지 문을 찾지 못하는 것인지 아직 판단할 수 없기 때문입니다.

만약 여러분이 에이전트 빌더(agent builder)라면: 무엇이 여러분으로 하여금 인간의 개입(human in the loop) 없이 이와 같은 서비스를 신뢰하고 호출하게 만들까요? 이것이 제가 거래의 반대편에서 답할 수 없는 질문입니다.

위의 모든 내용은 재현 가능합니다. 서비스는 token-risk.com에서 라이브로 운영 중이며, 단 1센트도 결제하기 전에 /samples/index.json에서 무료 샘플 보고서를 확인할 수 있습니다. 8주의 기간이 종료되면 후속 내용을 게시하겠습니다. 결과가 어떻든 동일한 정직함으로 공유하겠습니다.