수탁자 없는 선도 결제: 두 에이전트가 하나의 타임락(Timelock)으로 미래 거래를 결합하는 방법

대부분의 원자적 스왑 (Atomic Swaps)에 대한 설명은 현물 (Spot) 사례에서 멈춥니다. 즉, 두 당사자가 자금을 잠그고, 한 명이 비밀을 공개하면, 양측의 거래가 동일한 짧은 시간 안에 완료되는 방식입니다. 깔끔하지만, 이는 거래가 지금 당장 결제된다는 것을 은연중에 가정하고 있습니다.

실제 에이전트 활동의 상당수는 현물이 아닙니다. 그것은 선도 (Forward) 거래입니다. 두 에이전트가 오늘 자산 쌍, 규모, 가격 등의 조건을 합의하고, T+24h 또는 T+48h와 같은 미래의 특정 시점에 결제하는 방식입니다. 인도를 사전 약속하는 조달 에이전트, 내일의 FX 환율에 상당하는 비율을 고정하는 재무 에이전트, 재고 위험을 해소하기 위해 선도 가격을 제시하는 마켓 메이킹 (Market-making) 에이전트 등이 이에 해당합니다. 경제적 원리는 오래된 것이지만, 새로운 점은 거래 상대방이 결코 만날 일이 없는 익명의 소프트웨어라는 점입니다.

이는 현물 스왑에서는 답할 필요가 없는 질문을 던집니다: 합의와 결제 사이의 공백 기간 동안 무엇이 거래를 유지시키는가?

전통적인 시장에서 그 답은 청산소 (Clearing house), 예치된 증거금 (Margin), 거래 상대방의 신용도를 결정하는 신용 데스크와 같은 중개인 체인입니다. 익명의 에이전트들이 활동하는 시장에서는 이러한 중개인들을 제거해야 하며, 이 경우 단순한 형태의 선도 거래는 붕괴합니다. 거래를 묶어주는 장치가 없다면, 가격이 자신에게 불리하게 움직였을 때 어느 쪽이든 단순히 나타나지 않을 수 있습니다. 이것이 바로 거래 상대방 위험 (Counterparty risk)이며, 선도 거래가 관리해야 하는 바로 그 대상입니다.

이 포스트는 대부분의 사람들이 동일 블록 내 원자적 스왑 (Atomic swaps)과만 연관 짓는 HTLC (Hash-time-lock contract) 프리미티브(Primitive) — 즉, 동일한 해시락 (Hashlock)과 타임락 (Timelock) — 가 어떻게 중간에 누구도 자금을 수탁하지 않고도 구속력 있는 선도 의무를 인코딩할 수 있는지에 대해 다룹니다.

타임락 (Timelock)은 당신이 생각하는 것보다 더 많은 일을 하고 있습니다

해시-타임락 계약 (Hash-time-lock contract)의 두 가지 파라미터를 상기해 보십시오:

• 해시락 (Hashlock): hash(s) == H를 만족하는 프리이미지(preimage) s를 공개해야만 자금을 청구할 수 있습니다. 동일한 H가 양쪽 레그(leg) 모두에 사용되므로, 한쪽 레그를 청구하는 행위가 다른 쪽을 잠금 해제하는 비밀값을 공개하게 됩니다. 이것이 스왑(swap)을 원자적(atomic)으로 만드는 핵심입니다. 즉, 양쪽 모두 성공하거나, 둘 다 실패합니다.
• 타임락 (Timelock): 마감 기한 전까지 프리이미지가 공개되지 않으면, 자금은 원래 소유자에게 환불됩니다. 제3자가 이를 결정하는 것이 아니라, 계약(contract)이 이를 강제합니다.

현물(spot) 거래의 경우 타임락은 단순히 안전장치 역할을 합니다. 즉, 멈춰버린 스왑이 자금을 영원히 가두지 않도록 하는 짧은 유예 기간입니다. 하지만 선도(forward) 거래에서 타임락은 단순한 안전장치를 넘어 _그 자체로 하나의 수단(instrument)_이 됩니다.

그 메커니즘은 간단합니다: 자금을 지금 예치하되, 청구는 미래의 결제 창(settlement window) 내에서만 유효하게 만드는 것입니다. 잠금(lock)은 양쪽 레그에 자금이 모두 입금되는 순간부터 존재합니다. 계약 기간 동안 어느 당사자도 자신이 예치한 자산을 인출할 수 없습니다. 자금은 수탁자(custodian)의 계좌에 있는 것이 아니라, 오직 "결제(clear)" 또는 "환불(refund)"라는 두 가지 탈출구만을 가진 계약 안에 들어있기 때문입니다. 결제 창이 열리면, 양측은 공유된 프리이미지를 바탕으로 결제를 진행하며 양쪽 레그가 동시에 결제됩니다. 만약 결제 없이 창이 닫히면, 타임락에 의해 양측 모두 원래 소유자에게 자금이 환불됩니다.

이를 통해 중개자 없이도 선도 거래에 필요한 세 가지 속성을 확보할 수 있습니다:

1. 구속력 (Binding): 자금이 입금되면, 해당 의무는 계약 기간 동안 고정됩니다. 일방적으로 거래를 포기하는 것은 불가능합니다. 자금은 이미 계약에 예치되었기 때문입니다.
2. 비수탁 (No custody): 계약 기간 전체 동안, 그 어떤 상대방이나 플랫폼도 상대방의 돈을 보유하지 않습니다. 계약 자체가 에스크로(escrow) 역할을 하며, 계약은 오직 결제 또는 환불만을 수행할 수 있습니다.
3. 마진 콜 및 신용 조사 불필요 (No margin call, no credit check): "상대방이 이행할 능력이 있는가"라는 질문이 필요 없습니다. 결제는 약속이 아니라 잠겨 있는 레그 그 자체에 의해 담보되기 때문입니다. 채무 불이행(default)은 손실 사건이 아니라, 단지 환불일 뿐입니다.

실행 예시

두 에이전트 A와 B가 있습니다. A는 내일 자산 X를 원하고, B는 내일 자산 Y를 원합니다. 이들은 오늘 환율에 합의합니다.

• t = 0 (합의): A는 해시 H에 대해 자산 X를 잠그는 HTLC (Hashed Timelock Contract)에 자금을 예치하고, B는 동일한 H에 대해 자산 Y를 잠그는 HTLC에 자금을 예치합니다. 결제 창(Settlement window)은 대략 T+24시간으로 정의되며, 그 이후에는 환불 마감일(refund deadline)이 설정됩니다. 이제 양측의 거래가 모두 확정되었습니다. 어느 에이전트도 자신의 자산을 회수할 수 없습니다.
• 기간 중: 수탁(custodial) 행위는 전혀 일어나지 않습니다. X/Y의 가격은 변동될 수 있습니다. 하지만 인출(withdrawal)은 가능한 상태 전이(transition)가 아니기 때문에(오직 창 내에서의 결제(clear) 또는 마감일 이후의 환불(refund)만 가능함), 어느 에이전트도 이를 이용해 대응할 수 없습니다.
• t = T (결제 창 오픈): 프리이미지(preimage)를 보유한 당사자가 자신의 거래분을 청구하며, 이때 온체인(on-chain)에 s를 공개합니다. 동일한 s가 즉시 상대방의 거래분을 잠금 해제합니다. 양측은 하나의 비밀값(secret)을 통해 원자적(atomically)으로 결제됩니다.
• 실패 경로: 만약 청구 없이 결제 창이 닫힌다면(한 에이전트가 잠적했거나, 인프라가 실패하는 등 어떤 이유에서든), 타임락(timelock)이 양측의 거래분을 원래 소유자에게 환불합니다. 자본이 잠겨 있는 기간을 제외하고는 아무도 손해를 보지 않습니다. 최악의 상황은 기간을 낭비하는 것이지, 자산 도난이 아닙니다.

여기서 무엇이 빠져 있는지 주목하십시오: 청산소(clearing house), 예치된 변동 증거금(variation margin), 거래 상대방의 신용 평가, 목적지 체인에서 발행된 래핑된 IOU(wrapped IOU), 가치를 보유한 브릿지 멀티시그(bridge multisig) 등이 전혀 없습니다. 선도 거래(forward)는 두 개의 계약과 하나의 공유된 비밀값에 의해 강제됩니다.

에이전트에게 이것이 특별히 필요한 이유

인간은 지난 한 세기 동안 청산소를 통해 잘 지내왔으므로 왜 바꿔야 하느냐고 반론할 수 있습니다. 답은 에이전트 환경이 청산소가 의존하는 가설들을 깨뜨리기 때문입니다. 청산은 *신원과 구제(identity and recourse)*에 의존합니다. 즉, 알려진 회원, 법적 합의, 채무 불이행자를 추적할 수 있는 능력이 필요합니다. 체인을 가로질러 거래하는 익명의 에이전트들에게는 이러한 요소가 전혀 없습니다. 회원 위원회도, 관할권도, 고소할 대상도 없습니다. 그러한 환경에서 강제 가능한 유일한 선도 거래는 집행이 제도적(institutional)인 방식이 아닌, 계약 내에서 기계적(mechanical)으로 이루어지는 방식뿐입니다.

이것이 바로 "결제 레일(payment rails)만으로 충분하다"는 말이 문제의 본질을 과소평가하는 이유이기도 합니다. 이번 주에 이 점이 명확히 드러났습니다. x402는 Injective를 체인으로 추가했고 누적 결제액 1억 6천만 달러를 돌파했습니다. 이는 진정한 채택(adoption)이며 진지하게 받아들일 가치가 있습니다. 하지만 결제 레일은 결제 시점에 하나의 알려진 자산을 한 방향으로 이동시킵니다. 구조적으로 이는 현물(spot), 단일 다리(one-legged) 도구입니다. 결제 레일이 그 간극을 메우기 위해 수탁자(custodian)를 다시 개입시키지 않고서는, 나중에 결제되는 양방향 교차 자산(cross-asset) 거래를 묶어낼 수 없습니다. 결제 계층(payment layer)의 거래량은 결제(settlement)와 동일한 것이 아니며, 선도(forward) 거래는 레일이 표현할 수 없는 거래의 가장 깔끔한 예시입니다.

Hashlock에서의 위치

선도 결제(Forward settlement)는 우리가 밀봉 입찰(sealed-bid) RFQ와 HTLC 원자적 결제(atomic settlement) 위에 구축하는 기본 요소(primitives) 중 하나입니다. 이는 현물 스왑(spot swaps)을 구동하는 것과 동일한 메커니즘이며, 타임락(timelock)이 즉각적인 의무가 아닌 미래의 의무를 인코딩하도록 재사용된 것입니다. 브릿지도, 수탁자도 없습니다. 양쪽 다리가 모두 결제되거나, 둘 다 환불됩니다.

중요하기 때문에 체인 상태를 정확히 말씀드리자면: Ethereum 메인넷은 엔드 투 엔드(end-to-end)로 활성화되어 있으며, Bitcoin은 signet을 통해 검증되었고, Sui는 배포되어 CLI 테스트를 마쳤습니다. 선도 메커니즘은 문서(docs)에 나와 있으며, 공식적인 버전을 원하신다면 백서(whitepaper)에 정립된 결제 모델에 대한 학술적 설명이 있습니다.

• 문서: https://hashlock.markets/docs?utm_source=devto&utm_medium=post&utm_campaign=2026-06-15-forward-settlement
• MCP 서버 (6개 도구): npm의 hashlock-tech/mcp (scoped)
• 백서 (SSRN): https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722

만약 여러분이 오늘날 에이전트를 위한 선도 또는 이연 결제(deferred-settlement) 흐름을 설계하고 있다면, 여러분의 설계에서 합의와 결제 사이의 거래를 유지하는 것은 무엇입니까? 대차대조표(balance sheet)입니까, 아니면 결제 또는 환불만 가능한 계약입니까? 다른 분들은 기간 리스크(term-risk)의 간극을 어떻게 처리하고 계신지 궁금합니다.