열흘 동안 세 번의 출시가 있었습니다. 7월 14일, Visa, Mastercard, American Express, Stripe, Google, AWS, Coinbase를 포함한 40개 회원사를 보유한 x402 Foundation이 Linux Foundation 산하에서 운영을 시작했습니다. 7월 23일에는 Coinbase가 모든 Coinbase Business 계정에 대해 x402 USDC 결제를 활성화했습니다. 7월 24일, Cloudflare는 어떤 오리진(origin)이든 유료 에이전트에게 모든 리소스에 대한 비용을 청구할 수 있게 해주는 Monetization Gateway를 출시했습니다.

PayPal은 낯선 사람에게 온라인으로 안전하게 결제할 수 있는 환경을 만들었습니다. 이번 주는 AI 에이전트들이 그들만의 'PayPal 모멘트'를 맞이한 주였습니다.

또한, 무엇이 해결되었고 무엇이 해결되지 않았는지 정확히 짚어볼 좋은 시점이기도 합니다. 우리가 계속해서 받고 있는 질문들이기에 FAQ 형식으로 정리해 보겠습니다.

이번 주에 실제로 어떤 일이 일어났나요?

x402 프로토콜은 30년 동안 예약되어 있었지만 사용되지 않았던 상태 코드인 HTTP 402 "Payment Required"를 활성화합니다. 서비스가 결제 지침과 함께 402 응답을 보내면, 에이전트는 스테이블코인(현재는 Base 상의 USDC) 결제에 서명하고 결제 증빙과 함께 재시도합니다. 계정도, API 키도, 등록된 카드도 필요하지 않습니다.

이번 주에 이것은 더 이상 실험 단계에 머물지 않게 되었습니다. 이제 중립적인 표준 기구가 프로토콜을 관리합니다. 모든 Coinbase Business 계정은 차지백(chargebacks) 없이 에이전트 결제를 수락할 수 있습니다. 새로운 CDP x402 SDK를 사용하면 단 몇 줄의 코드만으로 모든 API, MCP 서버 또는 웹 서비스에 결제 수락 기능을 추가할 수 있습니다. 그리고 웹의 상당 부분을 담당하는 Cloudflare는 이제 에지(edge)에서 에이전트의 접속을 계량화(meter)할 수 있습니다.

또 다른 신호가 있습니다. Coinbase는 지난 6월 Base 문서 페이지에서 소프트웨어 생성 트래픽이 처음으로 인간 트래픽을 초과했다고 보고했습니다. 구매자는 이미 기계입니다.

이제 내 에이전트는 무엇을 결제할 수 있나요?

요청당 비용 발생 항목: API 호출 (API calls), 콘텐츠 접근 (content access), 컴퓨팅 (compute), 데이터 (data). CoinDesk의 보고에 따르면, 30일 동안 약 7,500만 건의 x402 트랜잭션이 발생하여 약 2,400만 달러가 결제되었습니다. 평균 결제 금액은 32센트였습니다.

이 평균 금액은 약점이 아닙니다. 그것은 설계된 방식입니다. x402는 마이크로페이먼트 (micropayment) 레일입니다. 즉, "계정 없이 에이전트가 요청당 어떻게 결제할 수 있는가?"라는 질문에 매우 훌륭하게 답합니다.

그렇다면 여전히 할 수 없는 것은 무엇인가요?

우리가 관심을 갖는 질문은 이것입니다: 어느 쪽도 서로를 신뢰하지 않을 때, 두 에이전트가 서로 다른 체인(chain)을 가로질러 어떻게 실제 가치를 교환할 수 있는가?

결제 레일(payment rail)은 구매자로부터 판매자에게로 돈을 한 방향으로 이동시킵니다. 차지백 (chargeback, 결제 취소) 없는 수익을 얻는 판매자는 보호받습니다. 하지만 자산 대 자산 (asset-for-asset) 거래는 두 개의 다리가 필요합니다. 만약 에이전트 A가 Ethereum 상에서 50,000 USDC를 보내고 에이전트 B가 BTC를 돌려줘야 한다면, B의 이행을 무엇이 강제할까요? 32센트 규모의 HTTP 결제 흐름은 그러한 리스크를 감당하도록 설계된 적이 없으며, 그렇게 하겠다고 주장하지도 않습니다.

이 양방향 문제는 결제 (settlement)의 문제이며, 이는 다른 원시 요소 (primitive)를 가진 다른 레이어 (layer)의 문제입니다.

결제 레이어는 어떤 모습인가요?

해시 타임락 계약 (Hash-time-locked contracts, HTLCs)입니다. 압축된 흐름은 다음과 같습니다:

1. 에이전트 A가 타임아웃(timeout)과 함께 hash(secret) 조건으로 체인 1에 자금을 잠금(lock)합니다.
2. 에이전트 B가 동일한 해시와 더 짧은 타임아웃을 사용하여 체인 2에 상대 자산을 잠금합니다.
3. A가 B의 자금을 청구하기 위해 비밀값(secret)을 공개하며, 이 과정에서 비밀값이 온체인 (on-chain)에 게시됩니다.
4. B는 공개된 비밀값을 사용하여 A의 자금을 청구합니다. 만약 어떤 단계라도 지연되면, 양측 모두 타임아웃 후에 환불받습니다.

두 단계(legs)가 모두 완료되거나, 둘 다 환불됩니다. 중간에 브릿지(bridge), 수탁자(custodian), 혹은 허니팟(honeypot)이 존재하지 않습니다. 상대방의 자금이 도착할 때까지 귀하의 돈은 지갑을 떠나지 않습니다. 트레이드오프(tradeoffs)는 실재하며 명시할 가치가 있습니다: 해당 기간 동안 자본이 잠기며(locked), 타임아웃(timeout) 매개변수에 주의가 필요하고, 양쪽 체인이 동일한 해시 함수(hash function)를 지원해야 합니다. 우리는 이전에 이러한 트레이드오프에 대해 작성한 바 있습니다. 결제 단계(settlement leg)는 공개되어 있으며, 문서에서 정확한 작동 방식을 읽어볼 수 있습니다.

결제 레일(payment rails)과 결제 레이어(settlement layers)가 경쟁하고 있나요?

아니요, 이들은 계층적으로 쌓입니다(stack). 에이전트가 가격 피드(price feed)를 조회하기 위해 x402를 통해 32센트를 지불하고, 상대방 탐색(counterparty-discovery) API를 위해 몇 센트를 더 지불한 다음, 실제 50 ETH ↔ BTC 거래를 HTLC(Hashed Timelock Contract)를 통해 원자적(atomically)으로 결제할 수 있습니다. 레일이 상단에 있고, 결제가 하단에 있는 구조입니다. 스택의 상단을 표준화하는 x402 재단은 하단 스택에게도 좋은 소식입니다. 이는 에이전트가 인간의 개입(human in the loop) 없이 거래한다는 개념을 정상화(normalize)하기 때문입니다.

두 단계 이상의 거래는 어떻게 되나요?

다단계 원자성(Multi-leg atomicity)은 동일한 프리미티브(primitive)를 확장합니다. 하나의 비밀값(secret) 아래 여러 HTLC 단계를 체인처럼 연결하면, 전체 경로가 완료되거나 아니면 모두 취소(unwind)됩니다. 이는 삼각 거래(triangular trades)를 수행하거나 여러 거래소에 규모를 나누어 집행하는 에이전트에게 중요합니다. 부분 실행(partial execution)은 그 자체로 하나의 리스크 범주이기 때문입니다.

다른 곳에서도 결제 측면을 검증하고 있나요?

이번 주, 예상치 못한 방향에서 예가 있었습니다. Arqitech가 MPCH, Pixelplex, sFOX와 함께 전통 금융(TradFi) 기관을 겨냥하여 Canton MainNet에서 비수탁형(non-custodial) 크로스체인 HTLC 원자적 스왑(atomic swap)을 실행했습니다(7월 23일 발표). 기관과 AI 에이전트는 동일한 이유로 동일한 프리미티브로 수렴하고 있습니다. 둘 다 거래 중간에 중개자를 신뢰하고 싶어 하지 않기 때문입니다.

저희의 경우: Hashlock의 밀봉 입찰 (sealed-bid) RFQ + HTLC 결제 기능이 Ethereum 메인넷에서 엔드 투 엔드 (end-to-end)로 작동합니다. Sui 컨트랙트는 배포 및 CLI 테스트를 마쳤으며, Bitcoin 흐름은 signet에서 검증되었습니다. 두 가지 모두 아직 결제를 위해 라이브 상태는 아니며, 실제로 작동하기 전까지는 라이브라고 부르지 않을 것입니다. MCP 서버는 에이전트를 위한 6가지 도구를 노출하며 (npm: hashlock-tech/mcp, scoped), 프로토콜 설계는 SSRN에 작성되어 있습니다.

남겨진 질문

에이전트 커머스(agent commerce)의 결제 측면은 10일 만에 표준화 기구, Fortune-500 멤버 리스트, 그리고 엣지 배포(edge deployment)를 확보했습니다. 하지만 결제(settlement) 측면은 거래 상대방 위험(counterparty risk)이 실제로 존재하는 영역입니다.

따라서 다음과 같은 미결 질문이 있으며, 저희는 실제적인 답변을 듣고 싶습니다: 여러분의 에이전트가 이전에 본 적 없는 거래 상대방과 자산을 교환해야 할 때, 현재 무엇을 사용하나요? 수탁 기관(custodian), 브릿지(bridge), 아니면 할 수 없어서 아무것도 사용하지 못하나요? 댓글로 알려주세요.