대부분의 "AI + 결제" 이야기는 에이전트를 통해 인간이 무언가를 구매하는 것에 관한 것입니다. 저는 그 반대를 원했습니다. 계정도, API 키도, 인간의 개입(human in the loop)도 없이, 나타나서 한 단위의 작업을 수행하고 그에 대한 비용을 지불하는 익명의 AI 에이전트 말입니다.

그래서 저는 이를 헬프데스크(helpdesk)에 구축했습니다. 이 "에이전트 도어(agent door)"가 어떻게 작동하는지, 그리고 HTTP 402를 실제 결제(settlement)로 연결하며 무엇을 배웠는지 소개합니다.

에이전트에게 API 키를 제공할 때 발생하는 문제

에이전트가 당신의 API를 사용하게 하는 기본 방식은 다음과 같습니다. 인간이 가입하고, 카드를 등록하고, 키를 생성하고, 이를 관리하는 것입니다. 에이전트에게 소유자가 있고 당신의 서비스와 장기적인 관계를 맺고 있다면 이 방식도 괜찮습니다.

하지만 에이전트가 *일시적(ephemeral)*일 때는 최악의 방식입니다. 에이전트는 지금 당장 단 한 번의 작업이 필요하며, 다시는 돌아오지 않을 것입니다. 온보딩(Onboarding), 고객 확인 제도(KYC), 키 로테이션(key rotation), 과금 플랜(billing plans)… 단 한 번의 API 호출을 위해 이 모든 오버헤드가 발생합니다. "다가와서 사용한 만큼만 정확히 지불한다"는 깔끔한 기본 단위(primitive)가 없습니다.

기본 단위: HTTP 402 + x402

HTTP에는 항상 이를 위해 예약된 상태 코드가 있었습니다: 402 Payment Required. x402가 이 코드에 구체적인 의미를 부여하기 전까지는 실제로 사용된 적이 없었습니다. 이제 서버는 기계가 읽을 수 있는 결제 조건과 함께 402로 응답하고, 클라이언트는 결제(온체인 USDC)를 수행한 뒤 X-PAYMENT 헤더를 포함하여 동일한 요청을 재시도합니다. 결제는 요청당 이루어집니다.

계정도 필요 없습니다. API 키도 필요 없습니다. 지불자의 지갑이 곧 정체성(identity)입니다.

도어 (The door)

저의 헬프데스크(DeskCrew)는 워크스페이스당 하나의 MCP 서버를 노출하므로, AI 에이전트가 데스크를 운영할 수 있습니다. 지식 베이스를 검색하고, 티켓을 열고 분류하며, 답장을 초안하고 게시할 수 있습니다. 읽기 도구(Read tools)는 무료이며, 쓰기/AI 도구(write/AI tools)는 유료입니다.

지금 바로 가입 없이 접속해 볼 수 있습니다:

curl -s https://deskcrew.io/api/mcp/deskcrew \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

그러면 도구별 가격이 포함된 도구 카탈로그가 반환됩니다. 유료 도구를 호출하면 다음과 같은 과제(challenge)를 받게 됩니다:

{
  "x402Version": 1,
  "error": "Payment required for tool 'create_ticket'",
...

20000은 USDC의 6자리 소수점 기준으로는 $0.02입니다. 에이전트는 해당 금액에 대한 결제 승인(payment authorization)에 서명하고, X-PAYMENT 헤더와 함께 재시도하며, 결제가 확정되면 도구(tool)가 실행됩니다.

실제로 제대로 구현해야 했던 것들

이상적인 경로(happy path)는 쉽습니다. 흥미로운 부분은 그렇지 않은 모든 상황입니다.

1. 금액, 수취인, 자산은 서버에서 제공되어야 하며, 클라이언트로부터 받아서는 안 됩니다. 클라이언트는 오직 서명된 승인 정보만 보냅니다. 서버는 결제 조건(서버 측 테이블의 가격, payTo = 콜드 월렛(cold wallet), 체인별로 고정된 USDC 컨트랙트)을 구성하고, 서명이 해당 조건들을 충족하는지 검증합니다. 그렇지 않으면 에이전트가 1 wei만 "결제"하거나, 결제 대상을 자신에게 리다이렉트하거나, 가짜 토큰을 건네줄 수 있습니다.

2. 결제되기 전에 부수 효과(side-effecting)를 일으키는 동작을 실행하지 마십시오. 하지만 중복 청구해서도 안 됩니다. verify()는 결제자의 잔액을 _읽기(read)_만 할 뿐, 예약(reservation)을 하는 것이 아닙니다. 따라서 단 한 번의 호출을 위한 자금이 들어있는 하나의 지갑에서 N개의 동시 요청이 들어올 경우, 모두 verify()를 통과할 수 있습니다. 저는 이를 두 가지 방식으로 제한합니다. 첫째는 **지갑당 최대 한 번만 실행 중인 리스(at-most-one-in-flight lease)**이며, 둘째는 동작이 실행되기 _전_에 삽입되는 클레임된 **논스(nonce, EIP-3009)**입니다. 이를 통해 재전송 공격(replay)이나 동시 중복 요청이 하나의 결제로 도구를 두 번 실행하는 것을 방지할 수 있습니다.

3. 실시간 외부 효과(고객에게 이메일을 보내는 것 등)의 경우, 먼저 결제를 확정하십시오. 공정성을 위한 기본 설정은 "성공 시에만 청구한다"입니다. 그래서 대부분의 도구는 실행된 후 결제됩니다. 하지만 "실행되었으나 청구되지 않음"이 실제 남용(귀하의 도메인에서 무료로 발송되는 아웃바운드 이메일)으로 이어지는 특정 동작의 경우, 저는 순서를 뒤집었습니다. 온체인(on-chain)에서 결제를 확인한 후에 전송합니다. 안전한 실패 방향은 "결제되었으나 전달되지 않음"이어야 하며, 결코 "무료로 전달됨"이 되어서는 안 됩니다.

4. 익명성 ≠ 무제한. 지갑별 속도 제한/지출 한도(rate/spend caps), 평판(reputation), 그리고 전달 가능성 차단기(deliverability breaker)가 남용을 제한합니다. 가치가 높은 동작은 획득한 평판을 통해 제한되므로, 가입 첫날의 익명 지갑은 귀하의 고객에게 이메일을 보낼 수 없습니다. 대신 해당 이메일은 사람의 승인을 기다리는 초안(draft) 큐에 담기게 됩니다.

5. 자가 호스팅(Self-host)하는 자금 경로. 나는 나만의 릴레이어(relayer) + 퍼실리테이터(facilitator)를 직접 운영하므로, 에이전트와 결제(settlement) 사이에 제3자가 존재하지 않습니다. USDC는 내가 설정한 가격에 따라 나의 콜드 월렛(cold wallet)으로 입금됩니다. 심지어 핫 키(hot key)가 유출되더라도, 지불자의 자금은 내가 설정한 가격으로 나의 지갑으로만 이동할 수 있습니다 (결제는 경제적으로 결속되어 있습니다).

그만한 가치가 있었는가?

헬프데스크(helpdesk)에 특화하여 말하자면: 워크플로우 중간에 지원 작업을 해결하는 에이전트가 이제 자신이 사용하는 도구에 대해 정확히 비용을 지불할 수 있습니다 — 계정도, 키(key)도 필요 없습니다. 작업당 지불(pay-per-action) 방식이 _에이전트에게 키를 발급하는 방식_보다 나은지는 진정으로 상황에 따라 다르며, 그 경계가 어디인지에 대해 인터넷 사용자들의 의견을 듣고 싶습니다.

하지만 이 패턴은 헬프데스크보다 더 큰 의미를 갖습니다. 402와 서명된 마이크로페이먼트(micropayment)의 결합은 에이전트 웹(agent web)을 위한 누락된 "다가가서 결제하기(walk up and pay)" 프리미티브(primitive)입니다. 아직 초기 단계이고 거칠지만, 오늘날 바로 작동합니다 — 당신은 그저 curl 명령어로 실행해 보기만 하면 됩니다.

직접 시도해 보세요: deskcrew.io · 도어(door): POST https://deskcrew.io/api/mcp/deskcrew · MCP 스펙 + 도구: github.com/webmilmind1/deskcrew-mcp

댓글을 통해 x402 배선(wiring)에 관한 어떤 질문이든 환영합니다.