보관형 vs 비보관형: AI 에이전트 거래를 안전하게 하는 두 방법

Source: Dev.to

이번 6월에 에이전트 인프라스트럭처에서 유용한 일이 일어났습니다. 여러 팀이 “AI 에이전트를 위한 에스크로 레이어”를 출시했는데, 이는 에이전트가 인간 개입 없이 전체 commit → hold → complete 라이프사이클을 실행할 수 있게 해 주는 프로덕션 MCP 도구입니다. 이제 에이전트는 계약이나 서비스에 가치를 예치하고, 상대방이 전달할 때까지 기다렸다가 완료 시점에 해제할 수 있습니다. 이는 정말 새로운 기능이며, 실제 문제를 해결합니다.

또한 “escrow”(에스크로)와 “settlement”(정산)가 같은 개념인 것처럼 사용되는 경우가 많아 정확히 짚고 넘어갈 필요가 있습니다. 두 개념은 다릅니다. 에이전트가 새벽 3시에 하는 거래를 신뢰할 수 있게 만드는 구조적으로 다른 두 방법이 있으며, 차이는 거래가 진행되는 동안 누가 돈을 보관하느냐에 있습니다.

Held‑custody 모델

제3자—스마트 계약 에스크로, 커스터디 서비스, 결제 중개자—가 자금을 받아 보관하고, 조건이 충족되면 해제합니다. 조건은 전달 확인, 평가자의 증명, 타임아웃, 다중 서명 승인 등 표현 가능한 어떤 것이든 될 수 있습니다.

이 방식은 에이전트 상거래의 큰 범주에 적합합니다. 에이전트가 상인에게 결제하거나 데이터셋을 구매하거나 다른 에이전트를 고용해 작업을 맡길 때, 핵심 질문은 ‘실제로 전달됐는가? 그리고 품질은 어떠한가?’ 입니다. 해시 함수만으로는 이를 판단할 수 없습니다. 커스터디가 있으면 누군가 혹은 무언가가 확인할 때까지 거래를 일시 정지시킬 수 있습니다. 새로운 에이전트‑에스크로 도구는 바로 이 형태—작업, 보류된 잔액, 완료 시 해제—에 맞춰 설계되었습니다. x402 같은 레일을 이용한 에이전트‑상인 결제에서는 held custody가 가장 기본적인 원시적 수단입니다.

비용도 구체적입니다. 보류된 잔액은 허니팟과 같습니다. 커밋과 완료 사이에 누군가가 자금을 제어하므로, 자금을 동결하거나 잃어버리거나 해제 조건을 잘못 설정하거나 탈취당할 위험이 있습니다. 즉, 신뢰 가정과 활성 의존성(커스터디가 온라인이고, 지급능력이 있으며, 해제 시 정직해야 함)을 추가하게 되는 것입니다. 이는 주관적인 전달 여부를 중재할 수 있다는 장점과 맞바꾸는 대가입니다.

No‑custody 모델

HTLC(해시‑시간‑잠금 계약)를 기반으로 한 원자적 스왑에서는 거래 양쪽이 동일한 해시 프리이미지에 잠깁니다. 프리이미지를 공개하면 모든 레그가 동시에 해제되고, 공개되지 않으면 모두 환불됩니다. 에스크로 계정도, 해제 결정도, 제3자가 돈을 보관하는 시점도 없습니다. 거래는 하나의 단위로 정산되거나 완전히 되돌아갑니다.

이 방식은 신뢰하지 않는 두 에이전트가 자산을 교환하는 경우에 적합합니다. 흔히 두 체인 간(예: ETH ↔ BTC) 토큰을 교환할 때 사용됩니다. 여기서 중요한 위험은 “작업이 잘 되었는가”가 아니라 **‘한 쪽은 이행됐지만 다른 쪽은 안 됐고, 누군가가 강탈당했다’**는 점입니다. 원자성은 설계상 이 실패 모드를 차단합니다. 커스터디가 없으므로 허니팟, 동결, 제3자의 정직성에 대한 활성 의존성도 없습니다. 거래는 구조 자체 때문에 안전합니다.

한계

Held‑custody의 강점은 주관적인 전달 여부를 판단할 수 있다는 점이지만, no‑custody는 자산이 원장에 움직이는 경우에만 정산이 가능합니다. 주관적인 전달을 판단하거나, 부분 작업에 대해 단계별 결제를 하거나, 체인 밖 분쟁을 중재할 수는 없습니다. HTLC는 심판자를 제공하지 않으므로, 심판이 필요한 경우엔 사용할 수 없습니다.

간단히 정리하면

• Held custody는 전달이 주관적이거나 오프체인이며, 시간이 걸리는 경우에 유리합니다. 예: 에이전트‑상인 결제, 에이전트 고용 등 “실제로 전달했는가?”가 중요한 상황.
• No custody는 온체인 자산을 깔끔하게 양쪽이 교환하는 경우에 유리합니다. 특히 체인 간 교환에서는 브리지나 커스터디가 가장 큰 단일 실패 지점이 될 수 있기 때문에 원자적 교환이 최선입니다.

이 두 모델은 경쟁 관계라기보다 동일 스택의 서로 다른 레이어라고 볼 수 있습니다. 성숙한 에이전트 경제는 두 방식을 모두 활용합니다. 판단이 필요한 거래에는 held custody를, 판단이 필요 없는 교환에는 원자적 “clear‑or‑refund” 방식을 사용합니다. 실수는 잘못된 모델을 잘못된 상황에 적용하는 것입니다. 예를 들어, ETH‑for‑BTC와 같은 깔끔한 스왑에 커스터디를 끼워 넣으면 필요 없는 허니팟이 생기고, 주관적인 전달물에 HTLC를 쓰면 본질적으로 판단할 수 없는 상황에 부딪히게 됩니다.

Hashlock은 이 스택의 no‑custody 측면을 담당합니다: sealed‑bid RFQ와 HTLC 원자적 정산을 결합하고, MCP 서버와 여섯 가지 도구를 통해 에이전트가 누구도(우리조차도) 자금을 보관하지 않는 교차 체인 거래를 견적, 매칭, 정산할 수 있게 합니다. 현재 체인 상태(반올림 없이)는 다음과 같습니다.

• Ethereum 메인넷: 엔드‑투‑엔드 라이브
• Bitcoin: signet‑validated, 메인넷은 아직 대기 중
• Sui: 계약 배포 완료, CLI 테스트 진행 중, 게이트웨이 연결 작업 진행 중

우리는 아직 BTC 혹은 Sui 메인넷을 주장하고 있지 않으며, 성숙도 비교를 위해 억지로 끼워넣는 것은 바람직하지 않습니다.

정식 설계 논문은 SSRN 백서에서 확인할 수 있습니다: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722
MCP 서버와 도구는 오픈소스로 제공됩니다: https://github.com/Hashlock-Tech/hashlock-mcp (npm에 hashlock-tech/mcp (scoped) 로 게시).

빌더에게 흥미로운 질문은 어떤 모델이 “더 좋다”가 아니라 여러분의 에이전트 흐름에서 경계가 어디에 놓여 있는가 입니다. 지금 에이전트 거래를 설계하고 있다면, 어떤 거래가 중간에 누군가가 돈을 보관해야 하는가, 그리고 어떤 거래가 충분히 깔끔해서 암호학적으로 커스터디를 제거할 수 있는가를 판단해 보세요.

추가 정산 설계 내용: https://hashlock.markets/methodology?utm_source=devto&utm_medium=post&utm_campaign=2026-06-11-custody-or-not