현재 에이전트 인프라(agent infrastructure)에서 널리 인용되는 수치는 Crossmint의 프로토콜 데이터에서 나옵니다: x402는 Base와 Solana를 통해 1억 5천만 건 이상의 트랜잭션(transactions)을 처리했으며, 에이전트 간 결제(agent-to-agent payments)는 가장 빠르게 성장하는 세그먼트입니다. Solana 단독으로 현재 해당 A2A(agent-to-agent) 거래량의 약 49%를 차지하고 있습니다. 이는 2년 전에는 현재의 형태로 존재하지 않았던 프로토콜 위에서, 실제 규모로 작동하는 머신 간 결제(machine-to-machine payment) 네트워크입니다.

이번 분기의 나머지 발표 사항들인 AWS Bedrock AgentCore, Shopify의 UCP, Google의 AP2를 더해보면 명확한 그림이 그려집니다: 빅테크(big tech) 기업들이 에이전트 경제의 결제(payment) 레이어를 구축하고 있으며, 이는 성공적으로 작동하고 있습니다. 이 글은 이에 반대하는 의견을 내기 위한 것이 아닙니다. 레일(rails)은 훌륭합니다. 하지만 구조적으로 그것들은 단방향(one-way)이며, 바로 그 특성이 레일이 멈추는 지점을 정확히 정의합니다.

레일(rail)의 기계적 구조

어떤 에이전트 결제 레일이든 상태 머신(state machine)으로 분해해 보면 동일한 형태를 띠게 됩니다:

1. 에이전트가 402 Payment Required(또는 의도 명령(intent mandate), 또는 체크아웃 세션)를 수신합니다.
2. 에이전트가 이체(transfer)를 서명하고 제출합니다: 에이전트 → 판매자.
3. 판매자(또는 조력자)가 수령을 확인하고 리소스를 해제합니다.

한 단계(One leg). 한 방향(One direction). 구매자의 리스크는 요청 가격에 의해 제한되며, 판매자는 가치가 전달된 후에만 물품을 인도합니다. 컴퓨팅 자원(compute), 데이터셋(dataset), API 호출(API call), 또는 추론(inference)을 구매하는 에이전트에게 이것은 정확히 올바른 프리미티브(primitive)입니다. 절차가 간소하고, 즉각적이며, 저렴하기 때문입니다. x402에서 에이전트 간(agent-to-agent) 거래량이 증가하는 이유는 이 설계가 해당 작업에 적합하기 때문입니다.

무엇이 이를 안전하게 만드는지 주목하십시오: 트랜잭션(transaction)은 규모가 작고, 일방적이며, 판매자의 인도는 결제가 이미 완료되었음을 조건으로 합니다. 신뢰 모델은 "구매자가 먼저 지불하되, 실패하더라도 손실이 아닌 번거로움 수준인 충분히 저렴한 것에 대해 지불한다"는 것입니다.

거래(trade)의 기계적 구조

이제 작업의 성격을 바꿔보겠습니다. 두 에이전트 — A와 B라고 부릅시다 — 가 자산을 교환(exchange) 하고 싶어 합니다: A의 ETH를 B의 BTC와 교환하는 것입니다. 어느 쪽도 서로를 신뢰하지 않습니다. 종종 자산은 서로 다른 체인(chains)에 존재합니다. 여기서 중요한 상태 머신(state machine)은 더 이상 단일 단계가 아니라, 두 단계의 결합된(joint) 상태입니다:

• 두 단계 모두 완료 → 거래 결제(settled). ✅
• 어느 단계도 완료되지 않음 → 거래 취소, 양측 모두 환불. ✅
• 한 단계는 완료되었으나 다른 단계는 완료되지 않음 → 한 에이전트는 두 자산을 모두 보유하고, 다른 에이전트는 아무것도 보유하지 못함. ❌

세 번째 상태가 바로 문제의 핵심입니다. 이것은 예외적인 상황(edge case)이 아닙니다. 두 단계가 독립적으로 커밋(commit)되고 한쪽 당사자가 적대적일 때 발생하는 _기본적인 결과(default outcome)_입니다. 거래 프리미티브(trade primitive)는 바로 이 세 번째 상태에 도달할 수 없게 만드는 메커니즘입니다.

왜 두 개의 레일(rails)만으로는 거래가 성립되지 않는가

유혹적인 답변은 이렇습니다: "그냥 반대 방향으로 두 번의 결제를 실행하면 됩니다." A가 레일을 통해 B에게 지불하고, B가 레일을 통해 A에게 지불하는 방식입니다. 하지만 각 레일의 전송은 제출되는 즉시 무조건적(unconditional)입니다. 이것이 바로 결제 수단으로서의 장점입니다. 따라서 먼저 지불하는 쪽은 상대방에게 공짜 옵션(free option)을 넘겨주는 셈이 됩니다. B는 A의 단계(leg)를 취하고 두 번째 단계는 그냥 보내지 않을 수 있습니다. 순서(sequencing)를 정하는 것은 이 문제를 해결하지 못하며, 단지 희생자를 선택할 뿐입니다.

그 위에 중개자(intermediary)를 덧붙일 수는 있습니다. 거래소(exchange), 수탁 촉진자(custodial facilitator), 또는 양쪽 단계를 모두 받아 전달하는 에스크로 서비스(escrow service) 같은 것 말입니다. 그것은 실제로 작동하며, 오늘날 대부분의 거래가 이루어지는 방식이기도 합니다. 하지만 이는 에이전트들이 피하려고 했던 바로 그 요소를 다시 도입하는 것입니다. 즉, 특정 시간 동안 두 자산을 모두 보유하고 있으며, 실패하거나, 동결하거나, 혹은 사라질 수 있는 제3자를 불러오는 것입니다. 불과 몇 분 전에 발견한 상대방과 기계적인 속도로 거래하는 자율 에이전트(autonomous agents)들에게 "거래 장소(venue)를 신뢰하라"는 말은 기묘한 토대입니다.

세 번째 상태를 도달 불가능하게 만드는 프리미티브

중개자 없이 이를 수행하는 구조는 이미 수년 전부터 알려져 왔습니다: 바로 해시 타임락 계약(hash time-locked contract, HTLC)입니다. 두 단계 모두 동일한 해시 H = sha256(s) 하에 잠깁니다. 어느 한 쪽의 단계를 청구하려면 온체인(on-chain) 상에서 프리이미지(preimage) s를 공개해야 합니다. 그리고 한 체인에서 s가 공개되는 순간 그것은 공개 정보가 되므로, 상대방은 이를 사용하여 다른 체인에서 자신의 단계를 청구할 수 있습니다. 타임락(timelocks, 체인 지연 시간을 고려한 안전 마진을 두어, 자금 제공자의 환불이 가능해지기 전에 청구자의 창구가 만료되도록 설정함)은 만약 s가 공개되지 않는다면 두 단계 모두 환불됨을 보장합니다.

그 결과, 거래(trade)에 실제로 필요한 세 가지 상태(three-state) 속성이 나타납니다. 즉, 매 순간 각 자산은 잠금(locked), 해제(released) (preimage가 공개되어 양측 모두 청구 가능), 또는 환불(refunded) (만료되어 자금이 원래 위치로 복귀) 상태 중 하나에 있게 됩니다. 제3자가 무언가를 보유하는 상태는 없으며, 타임아웃(timeout) 경계가 지난 후 한쪽이 양쪽 자산을 모두 가지게 되는 도달 가능한 상태도 존재하지 않습니다.

이것은 결제 최적화(payment optimization)가 아닙니다. 이는 다른 문제를 해결하는 다른 프리미티브(primitive)입니다. 이것이 바로 TCP가 HTTP와 경쟁하지 않는 것과 마찬가지로, 이것이 결제 레일(rails)과 경쟁하지 않는 이유입니다.

우리가 보는 레이어 맵(layer map)

현재 부상하고 있는 스택은 대략 다음과 같은 모습입니다:

• 의도 / 권한 부여 (Intent / authorization) - Google AP2, OpenAI+Stripe ACP: 이 에이전트가 거래를 해야 하는가, 누구의 위임(mandate)에 의한 것인가?
• 신원 / 평판 (Identity / reputation) - ERC-8004: 이 에이전트는 누구인가, 그동안의 실적(track record)은 어떠한가?
• 결제 레일 (Payment rails) - x402 및 그 위에 구축된 조력자(facilitators): 가치를 한 방향으로 빠르고 저렴하게 이동(move) 시킴.
• 거래 결제 (Trade settlement) - 양방향, 크로스 체인(cross-chain) 교환을 위한 청구 또는 환불(clear-or-refund): 양쪽 모두 혹은 둘 다 아님, 수탁자(custodian) 없음.

결제(settlement) 상위의 모든 레이어는 그 위에 위치할 수 있으며(그리고 위치해야 합니다). ERC-8004를 통해 인증하고, AP2 위임 하에 협상하며, x402를 통해 API 호출 비용을 지불하는 에이전트라 할지라도, 신뢰할 수 없는 상대방과 자산을 교환(exchange) 하는 첫 순간에는 여전히 최하위 레이어가 필요합니다. (과부하된 단어인 "결제(settlement)"를 일주일간 매핑해 본 결과, 여기서 발생하는 대부분의 이견은 실질적인 내용이 아닌 어휘의 문제라는 것을 배웠습니다. 따라서 이 부분은 한 문장으로 갈음하겠습니다.)

이것이 우리가 구축하는 레이어입니다. Hashlock은 밀봉 입찰 방식의 RFQ(에이전트가 의도를 유출하지 않고 확정된 견적을 받을 수 있도록 함)와 HTLC 원자적 결제(atomic settlement)를 결합하여, 6개의 도구를 가진 MCP 서버로서 에이전트에게 노출됩니다. 해당 패키지는 npm의 hashlock-tech/mcp (scoped)입니다. 체인 상태는 항상 정직하고 동일한 순서로 명시합니다: ETH 메인넷 엔드 투 엔드(end-to-end) 라이브; Sui 컨트랙트 배포 및 CLI 테스트 완료 (게이트웨이 배선 진행 중); BTC signet 검증 완료, 메인넷 대기 중.

프로토콜 수준의 세부 사항을 원하신다면, 문서를 통해 RFQ-plus-HTLC 흐름을 처음부터 끝까지 살펴볼 수 있습니다: hashlock.markets/docs. 출처: github.com/Hashlock-Tech/hashlock-mcp. 학술 논문: SSRN.

논쟁할 가치가 있는 질문

레일(Rails)의 성장 곡선(1억 5천만 건 이상의 트랜잭션, 가장 빠르게 성장하는 부문으로서의 에이전트 간 거래)은 에이전트들이 이미 끊임없이 무언가를 구매하고 있음을 보여줍니다. 열린 질문은 그들이 언제부터 '거래(Trading)'를 시작할 것인가 하는 점입니다. 즉, 체인 간의 재무(Treasury) 재조정, 인벤토리 스왑(Swapping inventory), 서로에게 담보(Collateral) 제공 등을 수행하는 단계 말입니다. 그런 일이 발생하면, '절반만 완료된 거래(Half-completed-trade)' 문제는 더 이상 이론적인 문제에 머물지 않게 됩니다.

그렇다면: 에이전트가 '구매'가 아닌 '거래'를 하게 된다면, 가장 먼저 무엇을 거래할 것이라고 예상하십니까? 그리고 에이전트가 거래소(Venue)를 통해 거래하도록 허용하시겠습니까, 아니면 거래소가 돈을 보유할 수 없는 메커니즘을 통해서만 허용하시겠습니까?