에이전트 커머스(agent commerce)에 관한 대부분의 글은 레이어 다이어그램(layer-diagram) 수준의 고도에 머물러 있습니다. 여기에는 레일(rails)이 있고, 저기에는 결제(settlement)가 있으며, 그 사이에는 신뢰 경계(trust boundaries)가 있는 식입니다. 유용하지만 추상적입니다. 오늘은 지면 수준으로 내려가서, 수탁자(custodian)가 루프 어디에도 없는 상황에서 AI 에이전트가 낯선 이와 거래할 때 실제로 어떤 일이 발생하는지 — 호출(call) 단위로 — 살펴보겠습니다.

전체 라이프사이클(lifecycle)은 6개의 MCP 도구에 들어맞습니다. MCP 기능이 있는 모델이라면 무엇이든 이를 구동할 수 있습니다. 통합을 위한 SDK도, 신뢰해야 할 서명 서비스(signing service)도 필요 없습니다. 패키지는 npm의 hashlock-tech/mcp (scoped)이며, 아래의 모든 과정은 현재 Ethereum 메인넷에서 엔드 투 엔드(end-to-end)로 실행됩니다.

페이즈 1: 가격 발견 (Price discovery) - 3개의 도구

**create_rfq**는 거래가 시작되는 지점입니다. 테이커(taker) 에이전트가 견적 요청(RFQ, request-for-quote)을 방송합니다: 페어(pair), 규모(size), 방향(direction), 만료 시간(expiry). 중요한 설계 결정은 RFQ가 밀봉 입찰(sealed-bid) 방식이라는 점입니다. 응답하는 메이커(maker)들은 서로의 견적을 볼 수 없습니다. 인간 OTC 데스크에게 이것은 편의 사항이지만, 에이전트에게는 핵심적인 지지대입니다. 경쟁 견적을 관찰할 수 있는 자율적인 메이커는 밀리초 단위로, 매번, 영원히 경쟁 견적에 맞춰 가격을 조정(shade)할 것입니다. 밀봉 입찰은 모든 메이커가 자신의 실제 가격을 제시하도록 강제합니다.

**list_open_rfqs**는 발견 과정의 메이커 측 도구입니다. 마켓 메이킹(market-making) 에이전트는 열려 있는 RFQ를 폴링(poll)하고, 페어와 규모별로 필터링하여 무엇을 견적할지 결정합니다. 이것은 결제 프로토콜(settlement protocol)을 양방향 시장으로 바꾸는 도구입니다. 즉, 흐름(flow)을 찾을 수 있어야 합니다.

**respond_rfq**는 견적을 제출합니다. 테이커 에이전트는 만료될 때까지 응답을 수집하고, 가장 좋은 것을 선택하여 결제로 넘어갑니다. 아직 발생하지 않은 것에 주목하십시오: 자금이 이동하지 않았고, 승인(approvals)이 부여되지 않았으며, 상대방(counterparty)을 신뢰하지도 않았습니다. 가격 발견은 정보적으로는 풍부하지만 재무적으로는 비활성(inert) 상태입니다. 이는 관리되지 않는 에이전트가 자본을 투입하기 전에 갖춰야 할 정확한 속성입니다.

페이즈 2: 결제 (Settlement) - 2개의 도구, 하나의 비밀

**create_htlc**는 첫 번째 다리(leg)를 잠급니다. 테이커(taker)는 해시 타임락 계약(hash-time-locked contract, HTLC)에 자금을 커밋합니다. 이는 해시락(hashlock, 비밀 preimage의 소유자만이 청구 가능)과 타임락(timelock, 기간 경과 후 자금이 송신자에게 환불됨)의 결합입니다. 자금이 전송된 것이 아니라 커밋된 상태입니다. 그러면 메이커(maker)는 동일한 해시에 대해 다른 체인에서 미러 다리(mirror leg)를 잠급니다.

**withdraw_htlc**는 청구(claim) 단계입니다. 테이커가 메이커의 다리를 인출할 때, 청구 행위 자체가 온체인(on-chain) 상에서 preimage를 공개하게 됩니다. 이것이 바로 메이커가 테이커의 다리를 청구하는 데 필요한 것입니다. 하나의 비밀(secret)이 양쪽 다리를 모두 해결합니다. 한쪽은 자산을 모두 가지고 있고 다른 쪽은 아무것도 가지지 못하는 상태는 존재할 수 없습니다. 이것이 "원자적(atomic)"이라는 말이 마케팅 용어가 아닐 때 의미하는 바입니다. 즉, "빠르다"거나 "솔버(solver)가 먼저 지불하고 나중에 정산한다"는 뜻이 아니라, 거래가 양쪽 다리 모두에서 완료되거나 혹은 양쪽 모두에서 완료되지 않는다는 암호학적 보증을 의미합니다.

어떤 판사도 거래가 완료되었다고 결정하지 않습니다. 완료란 곧 비밀(secret)의 공개 그 자체입니다. 이를 제3자가 의무 이행 여부를 판결하는 에스크로 및 평가자(escrow-and-evaluator) 설계와 비교해 보십시오. 이는 Solidity로 재구축된 인간 기관과 같습니다.

페이즈 3: 언와인드(unwind) - 아무도 광고하지 않는 도구

**refund_htlc**는 여섯 번째 도구이자, 자율 운영을 위해 가장 중요한 도구입니다. 만약 기간이 만료된다면 — 상대방이 사라졌거나, 견적(quote)이 만료되었거나, 에이전트가 흐름 중간에 충돌(crash)했다면 — 타임락(timelock)이 자금을 반환합니다. 청원할 대상도, 지원 티켓도, 분쟁 절차도 필요 없습니다. 전체 시스템의 실패 모드(failure mode)는 "당신의 돈을 돌려받는다"입니다.

이 속성은 깊이 생각해 볼 가치가 있습니다. 왜냐하면 이것이 데모를 보여줄 수 있는 프로토콜과 실제로 계속 실행해 둘 수 있는 프로토콜 사이의 차이이기 때문입니다. 관리되지 않는 에이전트는 결국 존재하는 모든 실패 모드에 직면하게 됩니다. 만약 그 실패 모드 중 하나라도 "인간의 결정이 있을 때까지 자금이 묶여 있다"라면, 당신은 자율 결제(autonomous settlement)를 가진 것이 아니라, 단계만 더 추가된 감독 결제(supervised settlement)를 가진 것뿐입니다.

향후 확장

여기서 이 프리미티브 (primitive)는 현물 스왑 (spot swap)보다 훨씬 더 흥란해집니다. HTLC 구조의 어떤 부분도 결제 창 (settlement window)이 반드시 '지금'이어야 한다고 말하지 않습니다. 타임락 (timelock)을 늘리면 동일한 6개의 호출이 선도 거래 (forward)를 묶어줍니다. 즉, 두 에이전트가 오늘 가격에 합의하고, 양측 모두 오늘 확약(commit)하며, 청구 창 (claim window)은 T+24h(또는 T+7d)에 열리는 방식입니다. 합의와 결제 사이에는 어떤 수탁 기관 (custodian)도 증거금 (margin)을 보유하지 않고, 어떤 청산소 (clearinghouse)도 이행을 보장하지 않으며, 어떤 신용 데스크 (credit desk)도 거래 상대방 위험 (counterparty risk)을 평가하지 않습니다. 양측 모두 나타나면, 하나의 프리이미지 (preimage)가 양측 모두를 결제합니다. 한쪽이 나타나지 않으면, 상대방의 환불 경로 (refund path)가 실행됩니다.

이것이 바로 결제 레일 (payment rails)이 다루지 못하는 간극입니다. x402, AP2, AWS의 새로운 AgentCore Payments 프리뷰 등은 이미 알려진 자산 하나를 한 방향으로 지금 즉시 이동시키며, 실제로 매우 뛰어나게 작동하고 있습니다. 하지만 레일은 나중에 결제되는 양방향의 교차 자산 의무 (cross-asset obligation)를 묶을 수 없습니다. 이를 위해서는 결제 프리미티브 (settlement primitive)가 필요하며, 레일들도 결국 그 아래에 이를 갖추게 될 것입니다.

현재 실행 가능한 환경

에이전트 경제에는 이미 과도한 청구 (overclaiming)가 존재하므로, 체인 기반 청구 (Chain-claim)의 정직성이 중요합니다: Ethereum 메인넷은 엔드 투 엔드 (end-to-end)로 활성화되어 있으며, 이 가이드의 모든 내용은 현재 그곳에서 작동합니다. Sui 컨트랙트 (contracts)는 배포되어 CLI 테스트를 마쳤으며, 게이트웨이 배선 (gateway wiring) 작업이 진행 중입니다. Bitcoin은 signet에서 검증되었으며, 메인넷 적용을 앞두고 있습니다. 공식적인 처리를 원하는 분들을 위해 프로토콜 설계는 우리의 SSRN 논문(https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722)에 문서화되어 있습니다.

문서 및 전체 도구 참조: https://hashlock.markets/docs?utm_source=devto&utm_medium=article&utm_campaign=2026-07-03-forward-tool-walkthrough - GitHub: https://github.com/Hashlock-Tech/hashlock-mcp

제가 계속해서 되묻게 되는 질문은 이것입니다. 6개의 도구 중 5개는 모든 관심을 받지만, 실제로 무인 운영 (unattended operation)을 가능하게 만드는 작업은 refund_htlc가 수행합니다. 만약 당신이 가치 (value)를 다루는 에이전트 (agents)를 구축하고 있다면, 당신의 스택 (stack)의 실패 모드 (failure mode)는 어떤 모습입니까? 자금이 묶인 채 티켓 큐 (ticket queue)가 쌓이는 모습입니까, 아니면 타임락 (timelock)을 통해 돈을 다시 돌려주는 모습입니까?