당신의 에이전트가 낯선 이와 거래하고 있습니다. 무엇이 그 낯선 이를 정직하게 유지할까요?

당신의 AI 에이전트가 실제로 거래를 수행하는 순간을 상상해 보십시오. 에이전트는 요청을 게시하고, 다른 에이전트로부터 좋은 가격을 제안받은 뒤 거래를 준비합니다. 에이전트는 해당 거래 상대방(counterparty)을 만난 적이 없습니다. 이름도 모릅니다. 아마 다시는 볼 일도 없을 것입니다. 전체 상호작용은 불과 몇 백 밀리초(milliseconds) 동안 지속되며, 그 후 양측은 각자의 길을 갑니다.

그렇다면 무엇이 그 낯선 이를 정직하게 유지할까요?

인간의 시장에는 일련의 해답이 있습니다. 평판(reputation), 반복적인 거래(repeat business), 법적 구제(legal recourse), 그리고 양측을 보증하는 것이 직업인 브로커(broker) 등이 그것입니다. 하지만 이 중 그 어떤 것도 익명성이 보장되고 고빈도(high-frequency)로 이루어지는 에이전트 간(agent-to-agent) 시장에서는 살아남을 수 없습니다. 일시적인 지갑(ephemeral wallet)을 고소할 수는 없습니다. 단 한 번만 상호작용할 거래 상대방과는 관계를 구축할 수도 없습니다. 만약 당신의 해답이 "양측을 보증하는 신뢰할 수 있는 거래소(venue)를 통해 모든 것을 처리한다"라면, 당신은 방금 삭제하려고 했던 수탁자(custodian)를 다시 구축한 셈이 됩니다.

이 포스트는 돈을 보유한 심판 없이도 이 문제를 실제로 해결하는 계층(layer)에 대해 다룹니다. 두 가지 원시 요소(primitives)는 바로 **실행 보상(execution rewards)**과 **계층형 KYC(tiered KYC)**입니다. 하지만 그 이전에, 당신이 해결하려는 문제 자체를 변화시키는 두 요소의 밑바탕이 되는 토대를 먼저 살펴보겠습니다.

토대: 원자적 결제(atomic settlement)가 있다면 강탈당할 일이 없다

낯선 이와 거래할 때의 위험은 절도, 즉 그들이 당신의 자산을 가져가고 사라지는 것이라고 가정하는 것이 본능적인 직관입니다. 원자적 결제(Atomic settlement)는 구조적으로 그러한 위험을 제거합니다.

거래의 양측은 동일한 조건에 잠깁니다. 즉, 양쪽 모두를 해제하거나 혹은 둘 다 해제하지 않는 해시 프리이미지(hash preimage)입니다. 구체적으로, 각 측은 H = SHA256(s)에 대해 HTLC(Hashed Timelock Contract)를 통해 자금을 예치하며, 이를 청구할 수 있는 유일한 방법은 s를 공개하는 것입니다. 한쪽 체인에서 한쪽의 거래를 청구하기 위해 s가 나타나는 즉시 그것은 공개되며, 상대방은 자신의 거래를 청구하기 위해 이를 복사합니다. 당신의 자금이 통제권을 벗어났는데 상대방의 자금이 도착하지 않는 일련의 사건 흐름은 존재할 수 없습니다. 거래가 완료되지 않으면 양측 모두 환불받습니다.

따라서 익명의 상대방과 거래할 때 최악의 상황은 절도(theft)가 아닙니다. 그것은 바로 **낭비된 타임락 윈도우(wasted timelock window)**입니다. 당신의 자본은 HTLC(Hash Time Locked Contract)에 묶여 있었고, 원했던 가격은 변동되었으며, 기회는 지나갔지만 — 결국 마지막에는 당신 자신의 자산을 돌려받게 됩니다. 당신은 원금이 아니라 시간과 옵션 가치(option value)를 잃은 것입니다.

이러한 재정의는 중요합니다. 왜냐하면 이것이 에이전트 시장에서 평판(reputation)이 정확히 무엇을 해결해야 하는지를 알려주기 때문입니다. "이 낯선 이가 내 것을 훔칠 것인가"가 아닙니다 — 프로토콜이 이미 그 질문에 답했습니다. 진짜 질문은 "이 낯선 이가 실제로 거래를 _완료_할 것인가, 아니면 나에게 견적을 제시하고 내가 확약하는 것을 지켜본 뒤, 나의 타임락(timelock)이 만료될 때까지 잠적(ghost)할 것인가?"입니다. 이것은 그리핑(griefing, 괴롭히기)이며, 절도가 아닌 경제적 공격입니다.

실행 보상: 프로토콜에 의해 강제되는 스킨 인 더 게임(skin in the game)

중도 포기에 따른 비용이 없을 때 그리핑은 저렴하게 이루어집니다. 에이전트는 시장 전체에 매력적인 견적을 뿌리고, 상대방이 자신을 대상으로 자금을 묶게 만든 뒤, 결코 공개하지 않을 수 있습니다. 즉, 자신에게는 비용을 전혀 들이지 않으면서 타임락 기간 동안 다른 에이전트들의 자본을 묶어두는 것입니다. 인간 시장에서 그리퍼(griefer)는 자신의 평판을 불태웁니다. 하지만 익명의 에이전트는 불태울 평판이 없습니다.

**실행 보상(Execution rewards)**은 거래 완료를 수익성 있는 경로로 만듭니다. 메커니즘은 간단합니다: 신뢰할 수 있게 결제하는 상대방은 검증 가능하고 프로토콜 상에 기록된 트랙 레코드(track record)를 쌓으며 수익을 얻습니다; 견적만 내고 잠적하는 상대방은 몰수(forfeit)당합니다. 여기서 "스킨 인 더 게임(skin in the game, 책임 경영/위험 감수)"은 누군가의 서버에 호스팅된 분위기나 별점 시스템이 아닙니다. 그것은 에이전트가 스테이킹(stake)해야 하며 잃을 수도 있는 경제적 포지션이며, 거래를 실행하는 것과 동일한 결제 레이어(settlement layer)에 의해 강제됩니다.

설계 목표는 처벌이 아니라 정렬(alignment)입니다. 당신은 합리적인 에이전트에게 가장 저렴한 전략이 "당신이 제시한 거래를 결제하는 것"이 되기를 원합니다. 거래 미완료 시의 몰수가 실질적이고, 완료 시의 축적이 실질적이라면, 그리핑 전략은 더 이상 이득이 되지 않습니다. 프로토콜 자체가 발행(mint)하고 슬래싱(slash)하는 평판은 새로운 지갑을 생성한다고 해서 속일 수 없습니다. 왜냐하면 새로운 지갑은 스테이킹된 것도, 얻은 것도 없는 상태에서 시작하기 때문입니다.

계층형 KYC (Tiered KYC): 에이전트가 스스로 탐색하는 검증된 거래 상대방 시장

실행 보상 (Execution rewards)이 "거래가 완료될 것인가"라는 질문을 다룬다면, **계층형 KYC (Tiered KYC)**는 다른 질문을 다룹니다. "이 특정 거래를 위해 내가 거래 상대방에 대해 얼마나 알아야 하는가?" 라는 질문입니다.

잘못된 답변은 단일한 글로벌 정책을 적용하는 것입니다. 즉, 모든 상호작용을 완전한 신원 확인 (Identity verification)을 거치도록 강제하거나 (이는 에이전트 시장을 흥미롭게 만드는 허가 없는 (permissionless), 기본적으로 익명인 특성을 죽입니다), 혹은 아무도 검증하지 않는 것 (이는 규제 대상이거나 대규모인 자금 흐름을 불가능하게 만듭니다) 중 하나를 선택하는 것입니다. 계층형 KYC는 시장 구조적 해답을 제시합니다. 거래 상대방은 서로 다른, 식별 가능한 검증 계층 (Verification tiers)에 존재하며, 에이전트는 거래마다 계층을 선택합니다.

• 작고 빠르며 익명성이 보장되는 스왑 (Swap)의 경우, 누구와도 거래하십시오. 원자적 결제 (Atomic settlement)가 여전히 당신을 보호하며, 최악의 경우에도 단지 환불될 뿐입니다.
• 낭비된 타임락 (Timelock) 창이 실제 옵션 비용 (Option cost)을 발생시키는 더 큰 규모의 거래의 경우, 채권을 예치했거나 실행 보상 (Execution-reward) 실적을 쌓은 거래 상대방으로 필터링하십시오.
• 규제된 레일 (Regulated rails)을 통과하는 자금 흐름의 경우, 해당 흐름이 요구하는 계층에서 신원 확인을 통과한 거래 상대방으로 필터링하십시오.

핵심적인 특성: 에이전트가 신뢰 수준을 선택하며, 프로토콜이 이를 위해 수탁자 (Custodian)를 선택하지 않는다는 점입니다. 검증된 거래 상대방 시장은 중개인이 지키는 문이 아니라 하나의 필터 (Filter) 입니다. 거래가 필요로 할 때는 신뢰도를 높이고, 그렇지 않을 때는 완전히 낮출 수 있으며, 어떤 계층에서도 제3자가 자산을 점유하지 않습니다. 이것이 "평판이 존재하는 시장"과 "중개인이 존재하는 시장" 사이의 경계입니다.

이것이 왜 단순히 "평판 점수를 추가하는 것"이 아닌가

이 모든 것을 "에이전트에게 평판 점수를 부여한다"는 식으로 단순화하고 싶은 유혹이 생길 수 있습니다. 차이점은 그 점수가 어디에 존재하며, 무엇을 할 수 있는지에 있습니다.

플랫폼이 호스팅하는 평판 점수(reputation score)는 해당 플랫폼이 제어하는 데이터베이스의 한 행(row)에 불과합니다. 플랫폼이 수정하거나 검열할 수 있으며, 플랫폼의 결정에 따라 사라질 수도 있습니다. 즉, 호스트만큼만 신뢰할 수 있을 뿐이며, 에이전트 시장이 피하고자 했던 바로 그 신뢰할 수 있는 제3자(trusted third party)를 정확히 다시 도입하게 됩니다. 반면 실행 보상(execution rewards)과 프로토콜 상의 검증 계층(on-protocol verification tiers)은 본질적으로 다릅니다. 거래 기록은 결제 계층(settlement layer) 자체에 의해 민팅(minted)되고 슬래싱(slashed)되며, 특정 개인의 사적인 데이터베이스가 아니기에 휴대성(portable)을 가집니다. 그리고 결정적으로, 이는 이미 도난을 불가능하게 만드는 결제 보증(settlement guarantee) 위에 구축되어 있습니다. 당신은 돈을 맡기기 위해 평판 시스템을 신뢰하는 것이 아닙니다. 원금을 실제로 보호하는 부분은 암호학(cryptography)이 담당하는 동안, 당신은 시간을 낭비하지 않기 위해 평판 시스템을 사용하는 것입니다.

에이전트가 이를 다루는 방식

실제로 에이전트가 이 모든 것을 직접 구현하지는 않습니다. 에이전트는 MCP 서버를 호출합니다. 즉, 상대방과 가격을 찾기 위한 밀봉 입찰 방식의 RFQ(sealed-bid RFQ)를 호출한 다음, 6개의 도구에 걸쳐 하나의 작업으로 통합된 HTLC(Hashed Timelock Contract) 생성을 통해 양측의 자금을 잠급니다. 상대방 계층(counterparty tier)은 요청의 매개변수(parameter)이며, 실행 보상 회계(execution-reward accounting)는 에이전트가 이미 사용 중인 결제 계층의 속성입니다. 관련 패키지는 hashlock-tech/mcp(scoped)이며, 소스 코드는 GitHub에 공개되어 있습니다.

우리가 항상 언급하는 방식대로 성숙도에 대해 덧붙이자면, 실행 보상과 계층화된 KYC는 원자적 결제 코어(atomic settlement core) 위에 레이어링된 **상대방 시장 설계(counterparty-market design)**입니다. 해당 코어의 정직한 체인 상태는 변함이 없으며, 우리는 매번 동일한 순서로 말씀드립니다 — ETH 메인넷 라이브(live) 및 엔드 투 엔드(end-to-end) 작동 중; BTC 시그넷(signet) 검증 완료, 메인넷 대기 중; Sui 배포 및 CLI 테스트 완료 (게이트웨이 배선 작업 진행 중). 체인에 대한 주장은 결제 프로젝트가 결코 어긋나서는 안 되는 유일한 지점이며, 신뢰에 관한 글을 쓰면서 이를 조작하는 것은 완전히 잘못된 시작입니다.

열린 질문

결제 보증은 제가 확신하는 부분입니다. 원자적 결제 또는 환불(atomic clear-or-refund)은 낯선 사람이 당신의 원금을 가져갈 수 없음을 의미합니다. 상대방 시장 설계는 논쟁할 가치가 있는 부분입니다. 따라서 진짜 질문은 이것입니다:

자율 에이전트 (autonomous agent)가 다시는 마주칠 일 없는 상대방과 거래할 때, 무엇이 그 상대방을 정직하게 유지해야 할까요? 프로토콜이 발행(mint)하고 슬래싱(slash)하는 암호학적 스킨 인 더 게임 (cryptographic skin-in-the-game)일까요, 아니면 누군가 어딘가에서 호스팅하고 신뢰를 맡아야 하는 평판 점수 (reputation score)일까요? 만약 전자라면, 완전히 새로운 정직한 에이전트들을 배제하지 않으면서도 그리핑 (griefing) 공격의 이득이 없어지도록 몰수 (forfeiture) 수준을 어디에 설정해야 할까요?

결제 프리미티브 (settlement primitive)의 배후에 있는 방법론은 hashlock.markets/docs에 작성되어 있으며, 소스 코드는 github.com/Hashlock-Tech/hashlock-mcp에서, 학술적 기술서는 SSRN에서 확인할 수 있습니다. 여러분은 인센티브 (incentives)를 어떻게 조정할지 진심으로 듣고 싶습니다. 여러분의 논거를 댓글로 남겨주세요.