AWS WAF가 AI 트래픽 수익화 (AI traffic monetization)라는 기능을 추가했습니다. 이를 통해 귀하의 사이트나 API에 접속하는 AI 봇들에게 콘텐츠 접근에 대한 비용을 청구할 수 있습니다. 지금까지 AI 크롤러 (crawlers)를 다루는 것은 허용하거나 차단하는 이분법적인 선택뿐이었습니다. 이번 기능은 결제를 받고 통과시키는 세 번째 경로를 추가합니다.

여기서 콘텐츠 소유자가 수익화를 설정하는 방법 등 기능 자체에 대해 깊게 다루지는 않겠습니다. 공식 발표에서 해당 내용을 다루고 있습니다.

https://aws.amazon.com/blogs/aws/aws-waf-adds-ai-traffic-monetization-capability-to-help-content-owners-charge-ai-bots-for-content-access/

제가 살펴보고 싶은 것은 반대편의 이야기입니다. 콘텐츠를 방어하는 측의 이야기는 동시에 그것을 읽는 측, 즉 자율 에이전트 (autonomous agents)를 실행하는 측의 이야기이기도 합니다. 수년간 예약되어 있었으나 거의 사용되지 않았던 HTTP 상태 코드 402가 실용적으로 변한다는 것은, 웹을 읽는 에이전트의 비용 구조가 변하기 시작했음을 의미합니다. 결제 프로토콜 자체에 대해서는 x402 명세 (spec)를 참고하겠습니다.

AI가 깨뜨린 "나중에 비용을 회수하는(let them read, recoup later)" 비즈니스 모델

상황을 설명하자면: AI 봇 트래픽은 이제 무시하기에는 너무 커졌습니다. AWS 블로그에 따르면, 많은 콘텐츠 제공업체에게 AI 봇은 웹 트래픽의 절반 이상을 차지하며, AI 전용 크롤러는 전년 대비 3배 이상 성장했습니다.

전통적인 검색 크롤러 (search crawlers)는 인덱스를 구축하고 검색 결과로부터 독자를 다시 보내주었습니다. 반면 AI 봇은 동일한 콘텐츠를 사용하여 요약과 답변을 생성하며, 원본 사이트로 독자를 거의 돌려보내지 않습니다. 제공업체는 페이지 뷰나 광고 노출을 얻지 못한 채 트래픽을 서비스하는 인프라 비용을 지불합니다. 이러한 비대칭성이 바로 비용을 청구한다는 아이디어가 시작되는 지점입니다.

이것이 콘텐츠를 방어하는 측의 관점입니다.

402와 함께 돌아온 수익화 (Monetize), 그리고 두 가지 제약 사항

먼저, 핵심적인 메커니즘부터 살펴보겠습니다.

수익화 (Monetization)는 AWS WAF의 봇 제어 (Bot Control) 기능의 일부로 실행됩니다. 봇으로 판단된 요청에 대해 여섯 가지 작업 중 하나(Monetize / Allow / Block / Count / CAPTCHA / Challenge)를 할당할 수 있습니다. Monetize를 할당하면, 결제가 이루어지지 않은 요청은 HTTP 402 Payment Required를 받게 됩니다. 402와 함께 기계가 파싱 가능한 형태(machine-parsable form)로 작성된 매니페스트 (manifest)가 전달되며, 여기에는 요청당 가격 (USDC 단위), 허용되는 결제 네트워크 (Base 및 Solana), 목적지 주소 등이 명시됩니다. 해당 형식은 Coinbase가 프로그램 간 결제 (program-to-program payments)를 위해 제안한 오픈 프로토콜인 x402입니다.

https://x402.org

두 가지 제약 사항을 주목할 필요가 있습니다. 첫째, Monetize 작업은 Amazon CloudFront와 연결된 웹 ACL (web ACLs)에서만 사용할 수 있습니다. 둘째, 결제 확인 및 온체인 정산 (on-chain settlement)은 요청 경로 (request path) 내부에서 동기식 (synchronously)으로 발생합니다. 공식 문서에서는 이를 "동기식 (synchronously)"이라고 명시적으로 기술하고 있으며, 정산이 확인된 후에만 콘텐츠가 반환됩니다. 해당 지연 시간 (latency)은 결제가 포함된 요청에만 발생하며, 결제가 없는 요청은 영향을 받지 않습니다.

https://docs.aws.amazon.com/waf/latest/developerguide/waf-ai-traffic-monetization-how-it-works.html

소스 코드를 통해 x402의 결제 내부 구조 읽기

x402는 Coinbase에 의해 제안되었으며, 현재는 저장소(repository)가 x402 Foundation으로 이전되어 오픈 표준 (open standard)으로 개발되고 있습니다. 사양 (spec)과 구현 (implementation) 모두 GitHub에 공개되어 있으므로, AWS 문서만으로는 알 수 없는 내용을 직접 읽을 수 있습니다. 공식 문서는 전체적인 흐름까지만 안내하며, 그 이상의 내용은 사양 (spec)에만 나와 있습니다. 따라서 소스 코드를 읽고 402에 무엇이 포함되는지, 어떻게 서명 (signed)되는지, 그리고 어디로 전송되는지를 순서대로 추적해 보겠습니다.

https://github.com/x402-foundation/x402

402 바디는 결제 조건의 매니페스트입니다

402 Payment Required 응답이 반환될 때, x402 v2에서는 결제 조건(payment terms)이 Base64로 인코딩되어 PAYMENT-REQUIRED 헤더에 실려 전달됩니다. 이를 디코딩하면 스펙에서 PaymentRequired라고 부르는 객체를 얻을 수 있습니다. 이 객체는 제공자가 수락하는 결제 수단(accepts)의 배열을 보유하며, 각 요소는 통과하기 위해 어떤 네트워크의 어떤 스킴(scheme)을 사용하여, 어떤 통화로, 얼마를, 어느 목적지로 지불해야 하는지를 선언합니다.

다음은 그 모습입니다. 아래는 v2 스펙의 예시에서 가져온 accepts 배열의 단일 요소입니다.

{
  "scheme": "exact",
  "network": "eip155:84532",
...

각 필드의 의미는 다음과 같습니다:

• scheme (결제 방식, 예: exact)
• network (eip155:84532와 같은 체인 ID)
• amount (가장 작은 단위의 정수로 표현된 금액; 여기서 10000은 USDC 기준 0.01 USD를 의미함)
• asset (통화의 컨트랙트 주소)
• payTo (수신 주소)
• maxTimeoutSeconds (결제 만료 시간)

지불 측은 이 배열에서 자신이 지불할 수 있는 조건 세트를 하나 선택하여 결제를 생성합니다. 여러 네트워크나 통화가 나열될 수 있으며, 무엇을 선택할지는 지불자의 몫입니다.

결제는 전송 그 자체가 아니라 서명된 승인입니다

지불자가 생성하는 것은 서명(signature)과 승인(authorization)으로 구성된 PaymentPayload 객체입니다. 승인(authorization)에는 다음 정보가 포함됩니다: 누구로부터(from), 누구에게(to), 얼마를(value), 유효 기간(validAfter / validBefore), 그리고 재사용을 방지하기 위한 일회용 값(nonce).

{
  "signature": "0x2d6a7588...148b571c",
  "authorization": {
...

값들은 모두 v2 스펙의 예시에서 가져온 것입니다. 앞선 accepts(결제 요청)에 대한 응답으로, 지불자는 이에 서명하여 반환합니다. 이것은 자금 전송의 실행이 아니라, 이러한 조건 하에 해당 금액을 인출할 수 있도록 서명된 허가(permission)입니다. 이는 EIP-3009의 transferWithAuthorization를 사용하며, 금액, 만료 시간, 그리고 일회용 nonce가 서명에 의해 결합되어 있다는 사실이 이후의 예산 편성(budgeting) 설계에서 매우 중요합니다.

https://eips.ethereum.org/EIPS/eip-3009

v1과 v2 사이의 헤더 이름 변경

x402에는 v1과 v2가 있으며, v2에서는 결제 교환 헤더 (payment-exchange headers)가 작동하는 방식이 변경되었습니다. 구현 (implementation)을 직접 다룬다면 반드시 알아두어야 할 차이점입니다.

v1에서는 결제 요청 (payment request)만이 응답 본문 (response body)으로 반환되었고, 결제 (payment)와 결과 (result)는 헤더 (headers)로 전달되었습니다. v2는 이 세 가지 모두를 헤더로 구성하며, 명세서 (spec)에 따르면 x402는 모든 프로토콜 정보 (protocol information)를 헤더에 담아 전달함으로써 응답 본문 (response body)을 서버 구현 (server implementation)의 영역으로 남겨둡니다. AWS 문서에서 결제 서명 (payment-signature) 헤더를 언급하는 이유는 이 문서가 v2를 따르기 때문입니다.

퍼실리테이터 (facilitator)는 검증과 결제를 처리하지만 자금을 보유하지 않음

제공자 (provider)가 온체인 검증 (on-chain verification) 및 전송 (transfer)을 직접 구현할 필요가 없도록, 퍼실리테이터 (facilitator)라고 불리는 중개 서비스가 존재합니다. 퍼실리테이터는 두 가지 역할, 즉 검증 (verify: 서명된 결제가 조건을 충족하는지 확인)과 결제 (settle: 이를 블록체인으로 보내고 확인을 기다림)를 수행합니다. 명세서 (spec)에서 명시적으로 밝히는 점은 퍼실리테이터가 자금을 보유하지 않는다는 것, 즉 수탁자 (custodian)가 아니라는 사실입니다. 퍼실리테이터는 오직 서명된 권한 부여 (signed authorization)를 수신하여 제공자 (provider)를 대신해 검증과 실행을 수행할 뿐입니다. 퍼실리테이터는 이미 Solana, Polygon, Base를 포함한 여러 네트워크에서 프로덕션 (production) 환경에서 운영되고 있습니다.

https://www.x402.org/ecosystem

지불자 (payer) 측면에서의 흐름을 간략히 추적하면 다음과 같습니다:

1. 요청 (request) 전송
2. PAYMENT-REQUIRED가 포함된 402 응답 반환
3. 수락 가능한 조건 (accepts) 중 하나를 선택
4. PAYMENT-SIGNATURE에 서명된 권한 부여 (signed authorization)를 담아 재전송
5. 제공자 (provider)가 퍼실리테이터의 검증 (verify) 기능을 통해 확인하고, 콘텐츠를 가져온 뒤, 결제 (settle)를 통해 확정하고, PAYMENT-RESPONSE와 함께 콘텐츠를 반환

AWS WAF가 처리하는 부분은 이 흐름 중 제공자 (provider) 측입니다.

해당 결제를 위해 AWS WAF는 Coinbase Developer Platform에서 제공하는 x402 퍼실리테이터 (facilitator)를 사용합니다. 만약 오리진 (origin)이 4xx 또는 5xx를 반환하면 결제 (settlement)가 실행되지 않으며 지불자 (payer)에게 비용이 청구되지 않는다는 점에 유의하십시오.

에이전트 런타임 (agent runtime)이 결제 주체가 되다

402 응답이 돌아온다는 것은 이를 수신하고, 결제한 뒤, 다시 콘텐츠를 받으러 가는 에이전트 (agent)가 존재함을 전제로 합니다.

방금 추적한 흐름은 지불 측의 에이전트 런타임 (agent runtime)에 의해 거의 자율적으로 실행될 수 있습니다. 런타임은 402를 수신하고 PAYMENT-SIGNATURE에 서명된 권한 부여 (authorization)를 담아 재전송하는 과정을 처리하며, 결제를 통한 제공자 측의 검증은 요청 경로 (request path) 내부에서 동기적으로 완료됩니다.

이는 에이전트를 운영하는 누구에게나 새로운 설계 고려 사항입니다. 지금까지 웹을 가져오는 자율 에이전트 (autonomous agent)의 비용은 주로 자체적인 토큰 사용량과 대역폭 (bandwidth)뿐이었습니다. 하지만 이제부터는 가져오려는 대상이 수익화되어 있다면, 콘텐츠 자체에 비용이 발생할 수 있습니다. 에이전트의 런타임은 HTTP 클라이언트 (client)인 동시에 결제 주체 (payment actor)가 됩니다. 이것이 바로 구조적인 변화입니다.

직접 에이전트를 운영한다면, 이 변화는 두 가지 새로운 설계 결정 사항을 가져옵니다. 즉, 가져오려는 대상으로부터의 402를 실패로 처리할 것인지, 아니면 결제하고 통과할 것인지, 그리고 결제한다면 어떤 지갑 (wallet)을 사용하여 자동으로 최대 얼마까지 지불할 것인지에 대한 결정입니다. 인증 경로 (auth path)를 선택하는 것이 중요해졌던 것과 마찬가지로, 이제 결제 경로 (payment path)에 대한 결정이 발생하게 됩니다.

첫째, 402 응답을 받은 후 분기점(branch)을 어디에 둘 것인가의 문제입니다. 에이전트의 HTTP 클라이언트가 402를 받았을 때, 이를 스택 상단으로 실패(failure)로 반환할까요, 아니면 즉시 결제 경로(payment path)로 진입할까요? 만약 fetch 내부에서 즉시 자동으로 결제한다면, 에이전트는 402를 인지할 필요가 없지만, 어디서 얼마를 결제했는지 파악하기 어려워집니다. 반대로, 에이전트가 다음 행동을 결정하는 계획 계층(planning layer)으로 이 문제를 올린다면, 작업(task)의 문맥 안에서 결제 결정을 내릴 수 있지만, 분기점들이 호출 경로(call paths) 전반에 흩어지게 됩니다. 인증 토큰(auth token)을 어느 계층에 부착할 것인가와 동일한 결정 사항이 이제 결제에 대해서도 적용됩니다.

둘째, 예산을 어떻게 제한(cap)할 것인가입니다. 이 지점에서 x402의 특징적인 설계가 빛을 발합니다. 인증(authorization)에는 서명(signature)에 의해 고정된 가치(금액, value), 유효 기간(validBefore), 그리고 일회용성(nonce)이 포함됩니다. 따라서 각 결제에 대해 서명하는 시점에 한도와 만료 시간을 결정할 수 있습니다. "요청당 최대 이만큼", "작업당 누적 최대 이만큼", "이 시간이 지나면 무효"와 같은 제어 규칙(harness rules)을 설정한 뒤, 이를 인증 생성 과정에 포함시키면, 설계 단계에서부터 에이전트가 무제한으로 결제하며 폭주하는 것을 방지할 수 있습니다. 한도를 어딘가에 하드코딩(hard-coding)하는 대신 서명된 인증 자체에 내장할 수 있다는 점이 이 설계의 강점입니다.

셋째, 프로덕션(production) 환경에 적용하기 전의 검증입니다. 처음부터 결제가 포함된 코드에 실제 화폐를 사용할 수는 없습니다. x402에는 테스트 네트워크(앞선 예제의 eip155:84532는 Base Sepolia라고 불리는 테스트넷입니다)가 있어, 실제 자산을 이동시키지 않고도 402 반환, 인증 생성, 검증이 일어나는 전체 흐름을 실행해 볼 수 있습니다. 결제 기능을 구현에 적용하기 전 단계로서 이 과정을 한 번이라도 거쳤는지 여부가, 첫 프로덕션 배포(rollout) 시의 심리적 안정감을 결정합니다.

설계 단계에서는 다음 세 가지를 고려하게 됩니다: 어느 계층(layer)이 402를 수신할 것인지, 누구의 지갑(wallet)을 사용하며 한도를 얼마로 설정할 것인지, 그리고 테스트넷(testnet)을 통해 실행할 것인지 여부입니다. 아직 구현 단계는 아닙니다. 단지 전제 조건이 바뀌었음을 인식하고, 판단(judgment)이 어디에서 이루어질지를 결정하는 것만으로도, 결제를 요구해야 할 대상(destinations)이 늘어날 때 당황하지 않게 될 것입니다.

robots.txt가 메울 수 없었던 간극

지불자(payer)의 관점에서 살펴볼 가치가 있는 한 가지 더는 robots.txt와의 관계입니다. robots.txt는 단지 신사 협정(gentleman's agreement)일 뿐이며, 이를 준수하지 않는 크롤러(crawler)를 막을 수 있는 강제력이 없습니다. 허용(allow)과 차단(block) 사이의 중간 지점은 존재하지 않았으며, 차단은 AI 검색을 통해 독자를 유입시키는 환영할 만한 봇(bot)들조차 배제하게 됩니다. 강제력을 가진 메커니즘인 402는 바로 이 간극을 메우기 위해 움직이고 있습니다.