AI 에이전트한테 API 팔려면? HTTP 402 결제 게이트웨이 실전 정리

AI 에이전트가 '고객'이 되는 순간, 기존 결제 모델이 깨진다

요즘 인터넷 트래픽의 주류가 사람에서 에이전트로 넘어가고 있다는 얘기, 많이 들어보셨죠. 문제는 이 에이전트들이 우리가 아는 방식으로 돈을 쓰지 않는다는 겁니다.

기존 SaaS는 이렇게 굴러갑니다.

• 월 구독료 또는 선불 크레딧
• 구매자가 카드 등록, 계정 생성
• 최소 결제 단위가 몇 달러~몇십 달러

그런데 에이전트는 다릅니다. 어떤 질문 하나를 해결하기 위해 한 번 검색하고, 한 번 API 호출하고, 한 번 데이터를 긁어옵니다. 그리고 그 결과가 마음에 안 들면 다른 사이트로 갑니다. 사람처럼 '일단 1년 구독해두자'라는 결정을 하지 않아요.

즉, 결제 단위가 요청 1건, 검색 1회, 토큰 1개 수준으로 쪼개져야 한다는 뜻입니다. 카드 결제망은 이걸 감당 못 합니다. 승인 지연, 최소 결제 금액, 신원 확인 같은 게 전부 발목을 잡아요.

그래서 등장한 게 HTTP 402입니다. 원래 1990년대 HTTP 스펙에 'Payment Required'로 예약만 되어 있고 아무도 안 쓰던 상태 코드였는데, 30년 만에 진짜로 쓰이게 된 셈이에요. 이 흐름을 정리한 근거자료는 Cloudflare 공식 블로그에서 확인하실 수 있습니다.

HTTP 402 결제 플로우, 코드로 보면 이렇습니다

개념은 단순합니다. 결제 안 됐으면 402, 결제하면 200. 리다이렉트도 없고 별도 결제 API 호출도 없어요. 요청 하나에 결제 협상이 인라인으로 붙는 구조입니다.

1) 결제 없이 요청하면 402가 떨어진다

$ curl -iX POST https://v2.api2pdf.com/chrome/pdf/html \
  --header "Content-Type: application/json" \
  --data '{"html":"Hello from an AI agent"}'

HTTP/2 402
content-type: application/json
payment-required: eyJ4NDAy...   # 결제 안내 페이로드 (Base64)

응답 헤더의 payment-required에 결제 조건이 담겨 옵니다. 에이전트는 이걸 파싱해서 서명하고 다시 요청하면 됩니다.

2) 결제 수단을 명시해서 호출하면 통과

Cloudflare AI Gateway처럼 자체 결제 엔진이 있는 경우엔 헤더 한 줄만 붙이면 됩니다.

$ curl -iX POST "https://api.cloudflare.com/client/v4/accounts/$CLOUDFLARE_ACCOUNT_ID/ai/run" \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "Payment-Method: x402" \   # ← 이 한 줄이 핵심
  --header "Content-Type: application/json" \
  --data '{
    "model": "z-ai/glm-4.7-flash",
    "input": {
      "max_tokens": 9001,
      "messages": [
        { "role": "user", "content": "What is Cloudflare?" }
      ]
    }
  }'

정산은 Coinbase의 x402 Facilitator를 거쳐 **Base 체인의 USDC(스테이블코인)**로 이뤄집니다. 판매자는 가격 규칙만 정의하면 되고, 결제 검증·재시도·정산·분석은 게이트웨이가 처리해요.

3) 가격 정책은 요청의 어느 부분에든 걸 수 있다

• Fixed pricing: 요청당 고정가 (예: Ceramic.ai의 검색 1회)
• Variable pricing: 최대 비용을 먼저 알려주고 실제 사용량만 정산 (예: API2PDF의 PDF 생성)
• Origin-controlled pricing: 가격 정보를 오리진에서 직접 조회 (예: AI Gateway의 토큰별 과금)

URL, 헤더, 쿼리 파라미터 어디든 매칭 조건으로 쓸 수 있어서, 기존 요금 체계를 그대로 게이트웨이에 얹는 것도 가능합니다.

실사용 사례 4개로 보는 적용 패턴

특히 API2PDF 케이스가 실무적으로 와닿습니다. 기존엔 계정 생성 → API 키 발급 → 한 달 후 카드 등록 단계에서 전환율이 50% 이상 떨어졌다고 해요. 지금은 API 키 없이 요청하면 402를 던지고, 결제되면 바로 PDF를 돌려줍니다. 온보딩 퍼널을 통째로 걷어낸 셈이죠.

이 기술의 한계와 주의사항

솔직히 말하면 아직 만능이 아닙니다.

• 지역 제약: 현재 미국 기반 셀러·바이어 대상 클로즈드 베타입니다. 국내 사업자라면 당장은 그림의 떡이에요.
• 스테이블코인 의존: 정산이 Base 체인의 USDC로 이뤄집니다. 국내 회계·세무 처리 관점에서 코인 결제 매출 인식은 별도 검토가 필요합니다.
• 에이전트 신원 문제: 익명 에이전트에게 리소스를 열어주는 구조라, 악성 대량 호출에 대한 방어는 별도 레이어가 필요합니다.
• 콘텐츠 vs API 구분: 페이지 크롤링처럼 '한 번 가져가서 천 번 쓰는' 리소스는 이 모델에 안 맞습니다. Cloudflare도 이 경우엔 별도의 Pay Per Use 모델을 권장해요.

다음 단계 학습 방향

1. x402 프로토콜 스펙을 직접 읽어보세요. HTTP 402의 헤더 규약과 서명 검증 흐름이 핵심입니다.
2. MCP(Model Context Protocol) 서버에 과금 레이어를 얹는 패턴을 실험해보세요. 에이전트 도구 호출에 자연스럽게 붙습니다.
3. 에이전트를 만드는 쪽이라면, 402 응답을 만났을 때 자동으로 결제하고 재시도하는 클라이언트 로직을 미리 익혀두면 좋습니다.

정리: '구독'에서 '소비'로 넘어가는 결제 패러다임

핵심만 다시 짚어보면 이렇습니다.

• 에이전트는 결과 단위로 소비합니다. 요청 1건, 검색 1회, 토큰 1개.
• 기존 카드 결제망은 이 단위를 감당 못 합니다. 그래서 HTTP 402 + 스테이블코인이 등장했어요.
• Cloudflare는 이걸 몇 번의 클릭으로 켤 수 있는 게이트웨이로 포장했습니다.

국내 SI·B2B SaaS 환경에서는 당장 도입이 어렵더라도, **'우리 API를 에이전트가 소비한다면 어떤 단위로 과금할 것인가'**라는 질문은 지금부터 던져볼 가치가 있습니다. 이 질문에 답을 못 하면, 에이전트 트래픽이 몰려왔을 때 그냥 공짜로 다 나눠주고 있는 셈이니까요.

에이전트가 예측 가능한 결과를 내도록 만드는 피드백 루프 설계에 관심 있다면, AI 코딩 에이전트의 피드백 루프 설계 가이드도 함께 보시면 좋습니다. 대규모 데이터 수집 파이프라인을 다루는 조직이라면 메타의 데이터 수집 시스템 마이그레이션 회고도 맥락 파악에 도움이 될 거예요.

함께 보면 좋은 글

• AI 코딩 에이전트, 예측 가능한 결과를 만드는 핵심 강력한 피드백 루프
• 메타의 대규모 데이터 수집 시스템 마이그레이션, 성공 비결은?