AI 에이전트가 CEX를 통해 거래할 때 실제로 무엇을 신뢰하는가?

이번 분기에 "AI 에이전트가 이제 거래할 수 있다"는 도구들이 대거 출시되었습니다. Kraken은 AI 에이전트를 위한 암호화폐 거래 도구로 설명되는 CLI를 출시했습니다. Alpaca는 MCP 서버를 출시했습니다. deBridge, Bybit 등도 동일한 방식으로 에이전트에게 기능을 노출하고 있습니다. 이러한 인터페이스들은 정말 훌륭합니다. 깔끔하고, 문서화가 잘 되어 있으며, 자율 에이전트(autonomous agent)가 호출하기 쉽습니다.

하지만 "에이전트가 이를 호출할 수 있다"와 "에이전트가 이를 신뢰할 수 있다"는 서로 다른 주장입니다. 에이전트가 이러한 도구 중 하나를 통해 거래를 실행할 때, 이는 단순히 요청을 보내는 것이 아닙니다. 그것은 신뢰 모델(trust model)을 수용하는 것입니다. 그리고 그 신뢰 모델은 대개 도구의 README에는 보이지 않습니다.

이 포스트는 메커니즘 수준의 차이점(diff)을 다룹니다. 수탁형 거래소(custodial exchange) 도구가 요구하는 신뢰와, 해시 타임 잠금(HTLC) 원자적 결제(atomic settlement)가 요구하는 신뢰의 차이입니다. 마케팅은 배제하고, 신뢰가 없는(trustless) 경로의 정직한 비용을 포함하여 각 설계에서 신뢰가 어디에 위치하는지만 다룹니다.

수탁형 CEX 도구가 에이전트에게 요구하는 신뢰

중앙화 거래소(centralized exchange)를 CLI나 MCP 서버로 감싸면, 변경되지 않은 결제 모델 위에 훌륭한 개발자 접점(developer surface)을 얻게 됩니다. 이때 세 가지 신뢰 가정이 부수적으로 따라옵니다:

1. 수탁 (Custody). 자산은 에이전트가 아닌 거래소가 보유합니다. 에이전트의 "잔액"은 거래소가 제어하는 데이터베이스 행(database row)입니다. 거래는 내부 장부 업데이트입니다. 이는 빠르고 저렴합니다 — 출금 시점에 데이터베이스 행이 실제 온체인 전송(on-chain transfer)으로 변해야 하기 전까지는 말입니다. 입금과 출금 사이의 모든 것은 거래소의 약속입니다.

2. API 키 권한 (API key authority). 프로그래밍 방식으로 거래하는 에이전트는 API 키를 보유합니다. 그 키는 계정에서 활동할 수 있는 소지자 자격 증명(bearer credential)입니다. 유출 시 피해 범위(blast radius)는 키의 전체 권한 범위와 같습니다. 그리고 에이전트는 인간과는 다른 방식으로 비밀을 유출합니다: 로그, 프롬프트 컨텍스트(prompt context), 도구 호출 추적(tool-call traces), 잘못 설정된 환경 등. 키의 범위를 제한(출금 불가, IP 허용 목록 등)할 수 있고 그렇게 해야 하지만, 이는 피해 범위를 좁히는 것일 뿐 소지자 자격 증명 모델 자체를 제거하는 것은 아닙니다.

3. 지급 능력 (Solvency). 가장 근본적인 문제입니다. 내부 잔고는 거래소가 출금을 이행할 수 있는 능력만큼만 유효합니다. 이 가정은 공개적으로, 그리고 반복적으로 실패해 왔습니다. 건전한 잔고를 읽고 있는 에이전트는 해당 잔고를 뒷받침하는 자산이 실제로 존재하며 아무런 제한이 없는지 확인할 수 있는 온체인 (on-chain) 방법이 없습니다.

이 중 그 어느 것도 CLI나 MCP 서버의 버그가 아닙니다. 이는 수탁자 (custodian)를 통해 결제 (settlement)를 라우팅할 때 발생하는 속성입니다. 툴링 (tooling)은 인터페이스를 현대화했을 뿐입니다. 거래 상대방 위험 (counterparty risk)은 인간 트레이더들이 지난 10년 동안 짊어져 온 것과 동일합니다.

이 문제는 인간보다 에이전트에게 더 중요합니다. 자율 에이전트의 핵심은 각 결정마다 인간이 개입 (human in the loop)하지 않고 행동하는 것이기 때문입니다. 인간은 출금 동결과 거래소 중단을 인지합니다. 하지만 에이전트는 더 이상 실제가 아닐 수도 있는 숫자를 바탕으로 계속 거래를 수행합니다.

HTLC 원자적 결제 (atomic settlement)가 에이전트에게 요구하는 신뢰

해시 시간 잠금 계약 (Hash-time-lock contract, HTLC)은 다른 입장을 취합니다. 대차대조표를 믿지 말고, 암호학적 프리미티브 (cryptographic primitive)와 타임아웃 (timeout)을 믿으라는 것입니다. 메커니즘은 다음과 같습니다:

1. 에이전트 A가 비밀값 s를 선택하고 h = hash(s)를 계산합니다.
2. 에이전트 A는 계약에 자금을 잠금(lock)하며, 이 자금은 h와 일치하는 프리이미지 (preimage)가 제시될 때만 에이전트 B에게 해제됩니다. 타임아웃 T_A 이후에는 A에게 환불됩니다.
3. 에이전트 B는 대응하는 측을 잠금하며, 동일한 h에 대해 A에게 해제됩니다. 더 짧은 타임아웃 T_B < T_A 이후에는 B에게 환불됩니다.
4. A는 s를 공개함으로써 B의 자금을 청구합니다. 이 공개는 공공의 영역이므로, B는 동일한 s를 사용하여 A의 자금을 청구합니다.
5. 만약 어떤 단계라도 정체되면, 양측 모두 각자의 타임아웃 이후 환불받습니다. 한쪽 다리(leg)는 결제되고 다른 쪽은 결제되지 않는 부분적 상태는 존재하지 않습니다.

신뢰의 차이가 핵심입니다. 거래 도중에 자금을 보유하는 수탁자 (custodian)가 없습니다. 계약 자체가 에스크로 (escrow) 역할을 합니다. 유출 시 계좌를 털어버리는 소지자 API 키 (bearer API key)도 없습니다. 청구에는 프리이미지 (preimage)가 필요하며, 환불 경로는 시간 제한이 있고 무조건적입니다. 지급 능력 (solvency)에 대한 가정도 필요 없습니다. 자산은 거래소의 장부에 놓여 있는 것이 아니라, 계약 내에 온체인 (on-chain) 상에 잠겨 있어 확인 및 검증이 가능합니다.

정직한 트레이드오프 (tradeoffs)

HTLCs는 공짜가 아니며, 그렇지 않은 척하는 것은 이 포스트가 피하고자 하는 바로 그 마케팅 방식입니다:

• 자본 잠금 (Capital lockup). 자금은 스왑 (swap)이 진행되는 동안 잠깁니다. 수탁형 (custodial) 내부 이체는 즉각적이지만, 아토믹 스왑 (atomic swap)은 타임아웃 (timeout) 대기 시간만큼의 비용을 치러야 합니다.
• 타임아웃 리스크 (Timeout risk) 및 프리 옵션 (free-option) 문제. 자금을 청구하는 당사자가 늦게 공개하여 상대방에게 피해를 주는 (grief) 일을 방지할 수 있도록 매개변수를 선택해야 합니다. T_A와 T_B의 순서를 잘못 설정하면 악용 가능한 비대칭성 (asymmetry)이 발생합니다.
• 라이브니스 (Liveness) 요구사항. 자금을 잠근 뒤 사라지는 당사자는 상대방이 환불을 위해 타임아웃이 끝날 때까지 기다리게 만듭니다. 아토믹성 (Atomicity)은 자금을 _잃지 않음_을 보장하는 것이지, 속도를 보장하는 것은 아닙니다.
• 해시 (Hash) 및 체인 가정. 크로스 체인 (cross-chain) HTLC는 양쪽 체인 간의 호환 가능한 해시 함수 (hash functions)와 각 체인의 최종성 (finality)에 의존합니다. 호환성을 위해 SHA-256 대 Keccak 선택이 중요합니다.

따라서 차이점은 "수탁형은 나쁘고, 트러스트리스 (trustless)는 좋다"가 아닙니다. 이는 서로 다른 비용의 문제입니다. CEX 도구는 즉각적인 내부 결제와 자본 잠금이 없는 대가로 카운터파티 리스크 (counterparty risk)를 부과합니다. HTLC 결제는 수탁자, 키 소유자 (bearer key), 그리고 지급 능력 (solvency)에 대한 도박을 제거하는 대가로 자본 잠금과 타임아웃 지연 시간을 부과합니다.

에이전트 사례가 저울의 균형을 기울이는 이유

수년간 사용해 온 거래소에서 가끔 거래를 수행하는 인간에게는 수탁형 비용이 대개 괜찮습니다. 하지만 인간이 각 거래를 감시하지 않고, 기계의 속도로, 한 번도 만난 적 없는 상대방과 거래하는 자율 에이전트 (autonomous agent)의 경우 계산 방식이 달라집니다. 수탁형 신뢰의 실패 모드 (failure mode)는 조용합니다. 수치가 맞지 않게 될 때까지는 모든 것이 정상처럼 보입니다. 반면 HTLC 결제의 실패 모드는 명확하고 제한적입니다. 최악의 경우, 타임아웃이 지나기를 기다렸다가 자금을 돌려받으면 됩니다.

이것이 바로 결제(settlement)를 래퍼(wrapper)가 아닌 네이티브 프로토콜(native protocol)로 구축하는 이면에 깔린 설계상의 베팅입니다. Hashlock은 6개의 도구 — create_htlc, get_htlc, withdraw_htlc, refund_htlc, swap_quote, swap_execute — 를 갖춘 MCP 서버를 통해 HTLC 원자적 결제(atomic settlement)를 노출합니다. 따라서 에이전트는 CEX 도구와 동일한 사용성(ergonomics)으로 이를 호출하지만, 그 밑단에서는 다른 신뢰 모델(trust model)을 상속받게 됩니다. 결제는 Ethereum 메인넷에서 엔드 투 엔드(end-to-end)로 실시간 작동하며, Sui 컨트랙트는 배포 및 CLI 테스트를 마쳤고, Bitcoin 경로는 메인넷 적용을 앞두고 signet에서 검증되었습니다.

인터페이스의 수렴은 실재합니다. 모든 것이 에이전트가 호출할 수 있는 MCP 도구가 되어가고 있습니다. 하지만 사라지지 않는 질문은 호출 뒤에 무엇이 자리 잡고 있는가 하는 점입니다.

에이전트 트레이딩 인프라를 구축하는 모든 이들에게 던지고 싶은 질문은 이것입니다: 완전 자율 에이전트에게 있어, 즉각적인 결제를 위해 수탁형 거래 상대방 위험(custodial counterparty risk)을 감수하는 것이 수용 가능한 비용인가, 아니면 원자성(atomicity)을 위해 자금이 묶이는 비용을 지불하는 것이 가치 있는 일인가? 당신의 기준선은 어디입니까?

코드 및 문서: https://github.com/Hashlock-Tech/hashlock-mcp · https://hashlock.markets/docs?utm_source=devto&utm_medium=article&utm_campaign=2026-06-22-cex-vs-native
신뢰 모델에 관한 전체 논의 (SSRN 백서): https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722