우리는 x402 결제 게이트웨이를 루프 네이티브(Loop-Native)로 만들었습니다 — 방법과 에이전트에게 이것이 필요한 이유

2주 전, Anthropic의 Claude Code 책임자인 Boris Cherny는 무대 위에서 제가 인프라를 구축하는 방식에 대한 생각을 바꿔놓은 말을 했습니다:

"저는 더 이상 Claude에게 프롬프트를 입력하지 않습니다. 저는 루프(loops)를 실행합니다. Claude에게 프롬프트를 입력하는 것은 바로 그 루프들입니다."

그 후 Peter Steinberger는 이에 이름을 붙인 포스트를 올렸습니다: 루프 엔지니어링 (loop engineering). 아이디어는 간단하지만 그 영향력은 엄청납니다. 당신은 프롬프트를 작성하는 것을 멈춥니다. 대신 에이전트를 대신해 프롬프트를 입력할 시스템을 설계하기 시작합니다. 에이전트는 추론(reason), 행동(act), 관찰(observe), 반복(repeat)의 사이클에 진입하며, 목표가 달성되거나 예산에 도달할 때까지 멈추지 않습니다.

이것은 즉시 저에게 한 가지 질문을 던졌습니다: 만약 에이전트가 루프 내에서 자율적으로 실행된다면, "행동(act)" 단계에 돈이 개입될 때는 어떤 일이 벌어질까요?

저는 16개 체인에 걸쳐 170개 이상의 엔드포인트를 보유한 x402 결제 게이트웨이인 Spraay를 운영하고 있습니다. 에이전트들은 이미 MCP 서버를 통해 우리의 배치 결제(batch payment), 에스크로(escrow), 급여(payroll) 엔드포인트를 호출하고 있습니다. 하지만 그 모든 호출은 '발사 후 망각(fire-and-forget)' 방식이었습니다. 에이전트는 요청을 보내고 응답을 받지만, 폴링(polling)을 하지 않는 한 결제가 실제로 정산되는 시점을 알 방법이 없습니다. 폴링은 토큰을 소모합니다. 소모된 토큰은 비용입니다. 그리고 루프 안에서 그 비용은 매 사이클마다 복리로 쌓입니다.

그래서 우리는 게이트웨이를 루프 네이티브(loop-native)로 만들었습니다. 이것이 무엇을 의미하는지, 그리고 우리가 어떻게 구축했는지 설명하겠습니다.

핵심 문제: 루프에는 폴링이 아닌 콜백(Callbacks)이 필요합니다

루프 엔지니어링이 적용된 에이전트가 배치 급여(batch payroll)를 처리하는 모습은 다음과 같습니다:

1. 관찰(Observe): "10명의 직원에게 급여를 지급해야 함"
2. 추론(Reason): "이것들을 Spraay를 통해 배치로 처리해야겠다"
3. 행동(Act): POST /api/v1/payroll/execute
...

콜백(callbacks)이 없다면, 4단계는 메인 루프 내부의 폴링 루프가 됩니다. 에이전트는 기다리는 동안 추론 토큰(inference tokens)을 소모하며 몇 초마다 GET /status를 계속해서 두드립니다. 단일 결제에 대해서는 낭비일 수 있습니다. 하지만 송장 처리, 에스크로 마일스톤 해제, 주간 급여 실행 등 지속적인 운영을 수행하는 에이전트에게 이는 지속 불가능한 방식입니다.

해결책: 에이전트가 모든 요청 시 callback_url을 전달할 수 있도록 합니다. 작업이 완료되면 게이트웨이는 해당 URL로 서명된 페이로드 (payload)를 POST 합니다. 에이전트의 루프 (loop)는 이 이벤트를 수신하여 처리하고 다음 행동을 결정합니다. 폴링 (polling)도, 토큰 낭비도 없습니다.

구현: 세 가지 계층

계층 1: 웹훅 (Webhook) 인프라

핵심 시스템은 백그라운드 디스패치 워커 (background dispatch worker)를 갖춘 Supabase 기반의 이벤트 큐 (event queue)입니다. 에이전트가 요청 본문 (request body)에 callback_url을 포함하면, 게이트웨이는 다음과 같이 동작합니다:

1. 이벤트별 HMAC 서명 비밀키 (signing secret)를 생성합니다.
2. webhook_events 테이블에 웹훅 이벤트를 큐에 넣습니다.
3. 일반 응답과 함께 webhook_id 및 webhook_secret을 포함하는 webhook 객체를 반환합니다.
4. 백그라운드 워커가 대기 중인 이벤트를 폴링 (polling)하여 전달합니다.

에이전트가 callback_url을 포함했을 때 보게 되는 모습은 다음과 같습니다:

POST /api/v1/batch/execute
{
  "token": "USDC",
...

응답:

{
  "success": true,
  "contract": "0x1646452F98E36A3c9Cfc3eDD8868221E207B5eEC",
...

배치 (batch)가 정산되면, 게이트웨이는 HMAC-SHA256으로 서명된 헤더와 함께 에이전트의 URL로 POST 합니다:

POST https://agent.example.com/hooks/spraay
X-Spraay-Signature: sha256=abc123...
X-Spraay-Event: batch.settled
...

에이전트는 원래 응답에서 받은 webhook_secret으로 서명을 검증하고, 이벤트를 처리한 뒤 루프의 다음 단계로 넘어갑니다. 전달에 실패할 경우, 워커는 지수 백오프 (exponential backoff) — 30초, 60초, 120초 — 방식을 사용하여 이벤트를 소진된 것으로 표시하기 전까지 최대 3회 재시도합니다.

핵심적인 설계 결정 사항: 콜백 시스템은 완전히 선택 사항입니다. callback_url을 전달하지 않는 에이전트는 응답에서 아무런 변화도 느끼지 못합니다. 모든 기존 통합 (integration)은 이전과 정확히 동일하게 작동을 유지합니다.

계층 2: 안전 가드 (Safety Guards)

이 부분은 제가 출시 전날 밤잠을 설치게 만든 부분입니다. 만약 에이전트가 자율적인 결제 루프를 실행하고 있다면, 루프에 버그가 발생했을 때 어떤 일이 벌어질까요?

상상해 보세요: 에이전트가 batch.settled 콜백 (callback)을 받았고, 루프 로직이 "좋아, 이제 다음 배치를 결제하자"라고 판단합니다. 에이전트는 또 다른 결제를 실행합니다. 또 다른 콜백을 받습니다. 다시 실행합니다. 루프에 종료 조건이 없으며, 지갑은 몇 분 만에 바닥납니다.

이것은 Spraay의 버그가 아니라, 에이전트 설계의 버그입니다. 하지만 사용자들은 게이트웨이를 탓할 것입니다. 그래서 우리는 에이전트가 어떻게 설계되었든 상관없이 지갑을 보호하는 세 가지 안전 계층 (safety layers)을 구축했습니다:

결제 엔드포인트 (payment endpoints)에 대한 키별 속도 제한 (Per-key rate limiting). 모든 API 키에는 분당 10회의 결제 실행 호출 예산이 할당됩니다. 정당한 배치 작업 (심지어 200명의 수취인이 있더라도)은 단 한 번의 API 호출입니다. 제한에 도달하려면 60초 이내에 완전히 별개인 10개의 작업을 실행해야 합니다. 폭주하는 루프는 몇 초 만에 제한에 도달합니다. 응답에는 X-RateLimit-Remaining 헤더가 포함되어 있어, 잘 설계된 에이전트는 스스로를 조절할 수 있습니다.

{
  "error": "rate_limit_exceeded",
  "message": "Too many requests to /api/v1/batch/execute. Limit: 10 per 60s.",
...

중복 결제 탐지 (Duplicate payment detection). 동일한 API 키가 60초 이내에 동일한 페이로드 (동일한 수취인, 금액, 토큰)를 전송하면, 게이트웨이는 중복 결제를 처리하는 대신 409 오류를 반환합니다. 응답은 중복이 의도적인 경우 에이전트가 이를 어떻게 무시할 수 있는지 알려줍니다 (고유한 idempotency_key 필드 추가).

웹훅 전달 쿨다운 (Webhook delivery cooldown). 어떤 콜백 URL도 5초보다 빠른 간격으로 전달을 받지 않습니다. 이는 가능한 최대 루프 사이클 속도를 제한합니다. 결과를 처리하는 정당한 에이전트는 5초 미만의 콜백이 전혀 필요하지 않습니다. 폭주하는 루프라면 필요하겠지만 말입니다.

세 가지 보호 장치 모두 API 키별로 적용되므로, 대량의 정당한 사용량을 가진 대기업은 자체적인 속도 예산을 가집니다. 또한 세 가지 모두 가산적 (additive)입니다. 즉, 기존의 엔드포인트 로직을 건드리지 않고 미들웨어 체인 (middleware chain)에 위치합니다.

레이어 3: 엔드포인트 연결 (Wiring Endpoints)

엔드포인트를 콜백 인식 가능하게 만드는 데는 약 8줄의 코드면 충분합니다. 웹훅 미들웨어는 callback_url을 포함하는 모든 요청에 webhookCallback 헬퍼 (helper)를 부착합니다. 엔드포인트 핸들러는 단순히 그것이 있는지 확인하기만 하면 됩니다:

// 기존 핸들러 코드가 응답을 생성합니다...

// 웹훅 콜백 추가 (agent가 callback_url을 전달한 경우에만 실행됨)
...

우리는 3개의 엔드포인트 제품군(endpoint families)에 걸쳐 6개의 핸들러(handler)를 연결했습니다:

• 일괄 결제 (Batch payments) — 실행 시 batch.created 발생
• 에스크로 (Escrow) — 모든 상태 전이(state transitions)에 걸쳐 escrow.created, escrow.funded, escrow.released, escrow.disputed 발생
• 급여 (Payroll) — 페이로드(payload) 내에 type: 'payroll'이 포함된 batch.created 발생

에스크로는 본질적으로 상태 머신 (state machine)이기 때문에 가장 흥미로운 사례입니다. 프리랜서 계약을 관리하는 에이전트 루프 (agent loop)는 이제 모든 단계에서 콜백 (callback)을 받을 수 있습니다: 에스크로 생성(escrow created) → 자금 입금(funded) → 작업 완료(work completed) → 자금 해제(released). 각 콜백은 에이전트가 폴링 (polling) 없이도 다음 행동을 결정하는 데 필요한 정보를 제공합니다.

이를 통해 가능한 것들

루프 네이티브 (loop-native) 콜백을 통해 에이전트는 이제 다음과 같은 일들을 수행할 수 있습니다:

자동 급여 처리 (Automated payroll processing): 송장 큐 (invoice queue) 관찰 → 직원 일괄 처리 (batch employees) → 정산 콜백 수신 → 장부 업데이트 → 다음 급여 주기 반복.

에스크로 마일스톤 관리 (Escrow milestone management): 에스크로 생성 → 승인 시 자금 입금 → 작업물 수령 → 인도 시 자금 해제 → 분쟁 처리. 모든 과정이 이벤트 드리븐 (event-driven) 방식으로 이루어지며, 폴링 (polling)이 필요 없습니다.

멀티체인 재무 운영 (Multi-chain treasury operations): 여러 체인에 걸친 잔액 모니터링 → 일괄 리밸런싱 결제 → 정산 확인 → 반복.

여기서 x402의 호출당 과금 모델은 실제로 우리에게 유리하게 작용합니다. 루프 설계된 (loop-engineered) 에이전트는 작업당 더 많은 호출을 수행하며 (이는 사이클의 본질입니다), 이는 게이트웨이를 통해 더 많은 마이크로 트랜잭션 (microtransactions)이 흐른다는 것을 의미합니다. 콜백을 통해 통합을 더 매끄럽게 만드는 것은 에이전트가 Spraay를 결제 계층 (payment layer)으로 사용할 가능성을 높이며, 이는 거래량이 줄어드는 것이 아니라 오히려 늘어남을 의미합니다.

우리가 구축하지 않은 것 (그리고 그 이유)

우리는 의도적으로 루프 오케스트레이션 프레임워크 (loop orchestration framework)를 구축하지 않기로 결정했습니다. 에이전트 생태계에는 이미 Claude Code, OpenClaw, LangGraph, CrewAI와 같은 프레임워크가 충분히 존재합니다. 에이전트 생태계에 없는 것은 자율적인 에이전트 루프 (autonomous agent loops)를 위해 설계된 결제 인프라입니다.

Spraay의 위치는 결제 레이어 (settlement layer)입니다. 우리는 에이전트에게 무엇을 할지 또는 어떻게 루프를 돌릴지 지시하지 않습니다. 우리는 어떤 루프의 "실행 (act)" 단계에서 자금 이동이 포함될 때, 그 인프라가 빠르고, 안전하며, 서명되었고, 이벤트 기반 (event-driven)임을 보장합니다.

직접 시도해보기

Spraay의 루프 네이티브 (loop-native) 웹훅 (webhooks)은 현재 배치 (batch), 에스크로 (escrow), 급여 (payroll) 엔드포인트 (endpoints) 전반에 걸쳐 활성화되어 있습니다. 요청 본문 (request body)에 callback_url을 추가하면, 작업이 해결될 때 서명된 콜백 (callbacks)을 받게 됩니다.

• 게이트웨이 (Gateway): gateway.spraay.app
• 문서 (Docs): docs.spraay.app
• MCP 서버 (MCP Server): smithery.ai/servers/Plagtech/Spraay-x402-mcp
• BPA 명세 (BPA Spec): docs.spraay.app/bpa/1.0/

자금을 다루는 루프 설계형 에이전트 (loop-engineered agents)를 구축하고 있다면, 결제 레이어 (payment layer)에 대해 어떻게 생각하고 계신지 듣고 싶습니다. 어떤 안전 보장 (safety guarantees)이 가장 중요하신가요? 어떤 이벤트 유형 (event types)에 대해 콜백을 받고 싶으신가요?

Spraay는 x402 결제 게이트웨이입니다 — 170개 이상의 엔드포인트 (endpoints), 16개의 체인 (chains), 그리고 주요 차별점인 배치 결제 (batch payments)를 제공합니다. 1인 창업자에 의해 공개적으로 빌드되고 있습니다.

빌드 과정 팔로우하기: X의 @lostpoet, Farcaster의 @plag.