봇 감지를 멈추고 대신 요금을 부과하기 시작하다: 에이전트 트래픽에 대한 HTTP 402 + USDC

제 추천 및 광고 수익 구조에 문제가 있습니다. 페이지가 크롤러나 마크업을 읽고 떠나는 에이전트에 의해 가져와질 때, 세 가지 일이 동시에 발생합니다. 요청은 대역폭과 오리진(origin) 작업 비용을 소모하고, 광고 슬롯은 사람에게 렌더링되지 않으며, 제휴 링크는 구매로 연결되는 클릭이 일어나지 않습니다. 방문은 일어났지만, 어떤 수익 모델도 이를 감지하지 못합니다.

그래서 저는 가장 명백한 해결책부터 살펴보았습니다. 바로 봇을 감지하고 다르게 취급하는 것이었습니다. 하지만 이것이 잘못된 접근 방식이었고, 왜 그런지 이해하는 과정이 유용했습니다.

사용자 에이전트 문자열(user-agent string)은 사실이 아니라 주장일 뿐입니다. 어떤 클라이언트든 헤더에 GPTBot을 보낼 수 있으며, 크롤러들은 이름이 정기적으로 바뀌거나 위조되거나 생략됩니다. 이 기반 위에 제가 구축하는 모든 것은 결정처럼 꾸며진 추측일 뿐입니다. 따라서 분류는 분석(analytics)이라는 본연의 자리로 남겨두었습니다. 저는 요청이 자동화된 것처럼 보였는지 여부를 보고 목적으로 기록할 뿐이며, 접근을 허용하거나 거부하지 않습니다.

그렇게 해서 정직한 선택지가 남았습니다. 바로 요청 자체에 가격을 매기는 것입니다.

'요청에 가격을 매긴다'는 것이 실제로 의미하는 바

보호된 콘텐츠는 페이지 안에 인쇄되어 있지 않습니다. 그것은 자체 엔드포인트에서 응답하며, 첫 번째 응답은 콘텐츠가 아니라 제안입니다:

GET /functions/paid-link?slug=example-resource

HTTP/1.1 402 Payment Required
...

이 응답에는 리소스의 어떤 부분도 포함되어 있지 않습니다. 페이지를 가져오는 방법만 아는 클라이언트는 가격을 배우고 그 외에는 아무것도 알지 못하며, 이것이 바로 의도된 결과입니다.

x402 규칙에 맞춰 구축된 클라이언트는 제안을 읽고 금액과 수신 주소를 확인한 다음, 해당 요청에 대한 승인(authorisation)에 서명합니다. 그리고 payment-signature 헤더에 서명된 페이로드를 담아 다시 요청합니다. 서버는 승인을 검증하고, 결제가 완료되면 그때서야 페이로드가 공개됩니다.

겉보기보다 더 중요한 두 가지 세부 사항이 있습니다:

가격은 방문자가 아닌 리소스에 속합니다. 동일한 금액이 사람, 크롤러, 에이전트 모두에게 견적되며, 어떠한 승인도 이루어지기 전에 확인할 수 있습니다. 이는 결제가 가능하기 위해 특정 크롤러 이름이 필요하지 않다는 것을 의미하며, 차단(blocking)은 결제 가격 책정(pricing)과 혼동되지 않습니다.

승인은 정산(settlement)이 아닙니다. 서명된 페이로드(payload)는 의도를 증명할 뿐입니다. 돈이 이동했다는 것을 증명하지는 못합니다. 제 서버는 온체인 영수증 자체를 확인합니다. 거래가 성공적이어야 하며, 전방의 요청에서 받은 지불자, 수취인, 금액, 승인 난스(authorization nonce)와 전송액이 일치해야 합니다. 리디렉션(redirect), 성공 플래그(success flag), 또는 클라이언트가 본문에 게시하는 숫자는 결제 증거로 취급되지 않습니다.

겉보기보다 어려웠던 다섯 가지 점

1. 자신에게 거짓말하지 않고 수익을 계산하기. 제 대시보드는 모델링된 가치(modelled value)와 검증된 영수증(verified receipts)을 별도의 열에 보관합니다. 왜냐하면 이 둘은 같은 숫자가 아니기 때문입니다. 가격이 견적된 요청이 수입(income)은 아닙니다. 서명된 승인도 수입이 아닙니다. 오직 성공적인 온체인 영수증과 일치하는 전송액만이 수입이며, 테스트 네트워크 단위는 금전적 가치가 없다고 표시됩니다. 또한 모든 요청에는 결제 상태가 포함되어 있어, 아직 미확정된 정산은 수익 총액에 조용히 합쳐지는 대신 '미확정'으로 계속 표시됩니다.

2. 실패한 시도를 반복 가능하게 만드는 것이 아니라 복구 가능하게 만들기. 결제 흐름은 최악의 방식으로 실패합니다. 즉, 클라이언트는 돈이 이동했는지 확신하지 못합니다. 저의 첫 번째 본능은 재시도(retry)였는데, 이것이 두 번 지불하는 결과를 낳습니다. 대신, 각 승인은 해시되어 저장되며, 동일한 승인으로 두 번째 시도를 하면 원래 거래 해시와 충돌을 일으키며 복구 경로를 반환합니다. 이 복구 경로는 원래 지불한 지갑의 소유권을 확인하며, 절대 두 번째 결제를 요구하지 않습니다.

3. 만료 기간 (Expiry windows). 인증 페이로드(Authorisation payloads)에는 validAfter와 validBefore가 포함됩니다. 구매자가 결제 화면에 너무 오래 머무르면, 이 창이 닫힙니다. 저는 어떤 정산 인프라(settlement infrastructure)에 연락하기 전에 이 창을 확인하고, 정산될 수 없는 결제를 제출하는 대신 특정 오류를 반환합니다.

4. 테스트 환경과 실 서비스는 다른 제품입니다. 저는 동일한 경로를 모든 레코드에 모드를 기재하여 테스트 네트워크에서 실행하며, 테스트 리소스는 메인넷(mainnet) 결제를 받을 수 없습니다. 이 둘을 혼합하는 것이 결국 자신의 장부를 설명할 수 없게 만드는 원인이 됩니다.

5. robots.txt와 가격 책정은 별개의 문제입니다. 크롤링 권한은 접근에 관한 것입니다. 가격은 조건에 관한 것입니다. 저는 유료 엔드포인트(paid endpoint)를 크롤링에서 제외하며, 지불한다는 것이 크롤링할 권리를 의미하지 않습니다. 이 둘을 혼동하는 것은 정직하게 설명할 수 없는 제품을 만듭니다.

이것이 하지 않는 것들

이것 자체만으로는 트래픽을 수익으로 전환시키지 못합니다. 클라이언트가 요청한 것에 대해 지불할 수 있고, 실제로 지불하려는 경우에만 비용을 지불하며, 그것이 전적인 조건입니다. 약속된 유료 방문 횟수, 전환율, 월별 수치 등은 없습니다. 모든 클라이언트가 제안을 거부하면, 제안은 제공되고 콘텐츠는 전달되지 않으며, 당신은 바이트(bytes) 외에는 아무것도 잃지 않습니다.

또한 이는 카드 결제 시스템을 대체하지도 못합니다. 같은 사이트가 대부분의 구매자들이 파일을 다운로드하기 위해 거래에 서명하고 싶어 하지 않기 때문에, Stripe를 통해 카드로 정적인 이커머스 리소스를 판매합니다. 암호화폐 정산(Crypto settlement)은 기계적 지불자(machine payers)와 이미 토큰을 보유한 사람들을 위한 경로이지, 모두를 위한 결제 전략이 아닙니다.

그리고 이것은 출금 시스템도 아닙니다. 정산액은 은행 입금 단계 없이 공개 네트워크의 지갑에 도착하며, 지급 일정이나 처리되는 세금 처리가 없습니다.

제가 이 부분이 흥미롭다고 생각하는 이유

에이전트 트래픽은 계속 증가할 것이며, 그 대부분은 누군가가 비용을 지불하고 생산한 콘텐츠를 읽는 데 사용될 것입니다. 오늘날 웹이 가진 두 가지 선택지는 '차단'하거나 '무시'하는 것입니다. 요청에 가격을 매기는 것은 세 번째 옵션이며, 매우 담백합니다. 탐지 경쟁도 없고, 유지해야 할 크롤러 이름 차단 목록도 없으며, 출처 모델링(attribution modelling)도 없습니다. 요청이 비용을 지불하면 콘텐츠가 제공되고, 그렇지 않으면 아무도 상대방의 시간을 낭비하지 않습니다.

만약 자동화된 읽기 작업이 많은 사이트를 운영하고 있다면, 이 방식이 어떤 부분에서 어려움을 겪게 하는지 정말 알고 싶습니다. 엔드포인트는 무료 API가 아니라 결제 게이트가 적용된 전송 경로(delivery route)이므로, 이 제안을 데모라기보다는 가격으로 간주해 주십시오. 메커니즘은 payperai.ai/ai-link-monetization에서 설명되어 있으며, 관련 주제 페이지는 payperai.ai/monetize-ai-agent-traffic입니다.