에이전트 경제는 '결제 방법'은 해결했지만, '누구를 신뢰할 것인가'는 여전히 해결하지 못했습니다.
요약
에이전트 경제가 결제 인프라 구축에는 속도를 내고 있으나, 거래 상대방에 대한 신뢰와 원자적 거래(Atomicity) 해결이라는 과제에 직면해 있음을 분석합니다. PayPal이 신뢰 레일을 구축했듯, 에이전트 간 거래를 위한 새로운 신뢰 표준이 필요함을 강조합니다.
핵심 포인트
- 에이전트 경제는 결제 방법(How)은 발전 중이나 신뢰 대상(Who) 문제는 미해결 상태임
- Mastercard와 Coinbase 등은 에이전트 결제 인프라 확장에 집중하고 있음
- 거래의 원자성(Atomicity) 확보를 위해 HTLC와 같은 기술적 접근이 필요함
- 단순 결제를 넘어 에이전트 간 상호 신뢰를 위한 평판 표준이 핵심 과제임
1999년 PayPal의 진정한 혁신은 돈을 옮기는 것이 아니었습니다. 은행은 이미 돈을 옮기고 있었습니다. PayPal이 한 일은 낯선 사람과 거래하는 것을 안전하게 만드는 것이었습니다. 경매의 반대편에 있는, 당신이 물건을 받기 전에 이미 결제 대금을 보유하고 있는, 한 번도 만난 적 없는 사람과의 거래 말입니다. 구매자 보호, 분쟁 해결, 평판 기록 등이 그것입니다. 자금 레일(money rail)은 쉬운 절반이었습니다. 신뢰 레일(trust rail)이 바로 제품이었습니다.
4분의 1세기 후, 에이전트 경제(agent economy)는 쉬운 절반을 빠른 속도로 재구축하고 있으며, 어려운 절반은 대부분 건너뛰고 있습니다. 이번 주는 이를 명확하게 보여주는 사례였기에, 주간 요약으로서 뉴스를 단순히 나열하기보다는 이를 하나로 묶어주는 하나의 실마리를 풀어보고자 합니다.
이번 주의 핵심을 한 문장으로
결제 방법은 더 다양해졌지만, 당신이 누구에게 결제하는지 알 수 있는 새로운 방법은 없었습니다. Mastercard의 에이전트 결제 프로그램은 계속 진행되어 현재 Polygon에 에이전트 승인(agent authorizations)을 기록하고 있습니다. 이는 온체인(on-chain)에 에이전트 지출 권한을 기록하는 TradFi(전통 금융) 네트워크입니다. Coinbase의 x402는 11월 정점 이후 단독 거래량이 급격히 식었음에도 불구하고 메인스트림 웹 인프라 뒤에서 계속 확산되었습니다. Eco는 약 15개의 체인에 걸쳐 크로스체인 스테이블코인 오케스트레이션(cross-chain stablecoin orchestration)을 확장했습니다. 그리고 "신뢰가 필요 없는 에이전트(Trustless Agents)" 식별 및 평판 표준인 ERC-8004는 MCP를 지향하는 v2 방향과 함께 계속 성숙해 가고 있습니다.
이들을 나열해 보면 세 가지는 동일한 질문 — 에이전트가 어떻게 가치를 이동시키는가? — 에 대한 답이며, 정확히 하나만이 다른 것들이 남겨둔 질문을 가리키고 있습니다.
왜 "누구"가 "어떻게"와 다른 문제인가
결제는 단방향이며 알려진 당사자에게 이루어집니다. 당신의 에이전트가 이미 선택한 제공업체로부터 컴퓨팅 자원을 구매합니다. 가치는 한 방향으로, 하나의 자산으로, 한 번의 홉(hop)을 통해 이동합니다. 어려운 부분은 승인(authorization)과 전달(delivery)이며, 위의 레일들은 이를 진정으로 완벽하게 수행합니다.
거래(trade)는 그렇지 않습니다. 나의 자산을 당신의 자산과 교환하는 것이며, 시계를 공유하지 않는 두 개의 원장(ledger) 사이에서 발생할 수 있고, 상대방이 미리 선택되지 않은 상태입니다. 이는 결제 레일이 다루지 않는 두 가지 문제를 야기합니다:
- 원자성 (Atomicity) — 양쪽 거래가 동시에 결제되거나, 둘 다 환불되어야 합니다. 단방향 결제 레일(one-way rail)은 "두 번의 송금에 걸친 전부 아니면 전무(all-or-nothing)"를 표현할 수 없습니다. 일반적인 해결책은 양측의 자금을 보관하는 에스크로(escrow)를 사용하는 것이지만, 이는 위험을 제거한다기보다 오히려 지급 능력과 정직함을 신뢰해야 하는 수탁자(custodian)에게 위험을 옮기는 것에 불과합니다.
- 거래 상대방 (Counterparty) — 상대방이 "누구"이며, 왜 나의 에이전트가 자금을 묶어둘 만큼 그들을 신뢰해야 하는가 하는 문제입니다.
원자성은 결제(settlement)의 문제이며, 이미 알려진 해답이 있습니다. 해시 타임락 계약 (Hash-time-lock contracts, HTLCs)을 사용하면 양측 모두 타임락(timelock) 조건 하에 단일 해시 프리이미지(hash preimage)에 대해 자금을 묶어둘 수 있습니다. 비밀값을 공개하면 거래 전체가 결제되고, 침묵을 유지하면 거래 전체가 환불됩니다. 절반만 결제된 상태도, 중개인이 책임을 떠안는 상황도 발생하지 않습니다. 이 부분은 이미 존재하며 오늘날 Ethereum 메인넷에서 활발히 작동하고 있습니다.
거래 상대방 문제는 거의 아무도 "에이전트를 위해" 구축하고 있지 않은 문제이며, 이것이 바로 ERC-8004가 이번 주 리스트에서 가장 흥미로운 항목인 이유입니다.
발견(Discovery)은 도구를 해결했습니다. 하지만 거래 상대방을 해결하지는 못했습니다.
도구 발견(tool discovery)이 얼마나 빨라졌는지 생각해 보십시오. MCP를 통해 에이전트는 기능을 찾아내고, OAuth를 통해 접속한 뒤, 몇 초 만에 해당 기능을 호출하기 시작합니다. "에이전트가 무엇을 할 수 있는가"에 대한 발견은 거의 해결된 문제에 가깝습니다.
하지만 "에이전트가 누구와 거래해야 하는가"에 대한 발견은 그렇지 않습니다. 오늘날 이는 수동적입니다. 사람이 거래 상대방을 검증하거나, 에이전트가 단순히 낯선 이와 거래하지 않는 방식입니다. 수취인이 당신이 선택한 상점이라면 이는 괜찮습니다. 하지만 상대방이 사전에 선택되지 않는 개방형 에이전트 간(agent-to-agent) 시장을 원하는 순간 이 방식은 무너집니다. 낯선 이와의 거래가 핵심인데, 그 낯선 이야말로 우리가 자동화된 방식으로 평가할 방법이 없는 대상이기 때문입니다.
ERC-8004는 생태계가 마침내 이 문제를 일급 시민(first-class)으로 다루는 것입니다. 즉, MCP를 v2 구상에 포함시키면서, 오프체인 허용 목록(allowlist) 대신 온체인 프리미티브(on-chain primitives)로서 신원(identity)과 평판(reputation)을 다루는 것입니다. 이는 결제와 경쟁하는 것이 아니라 상호 보완적입니다. 신원은 "누구"인지를 알려주고, 결제는 "거래가 완료됨"을 보장합니다. 당신에게는 이 두 가지가 모두 필요합니다.
대부분의 사람들이 놓치는 부분: 신원은 결제와 결합되어야 합니다
여기에 설계상의 함정이 있습니다. 에이전트의 평판(reputation)을 어딘가에 존재하는 점수, 즉 에이전트가 거래 전에 조회할 수 있는 등록부(registry)로 상상하기 쉽습니다. 하지만 결제 경로(settlement path)
옆에 떠 있는 평판 수치는 양방향 모두에서 취약합니다. 이를 권고 사항(advisory)으로 읽으면 시간 압박 속에서 무시되기 쉽고, 이를 권위 있는 정보(authoritative)로 읽으면 가치를 통제하는 순간 시빌 공격(Sybil attack)의 표적이 됩니다. 신원을 속이는 것이 그것이 해제하는 가치만큼의 가치를 갖게 되기 때문입니다.
흥미로운 설계들은 증명(attestation)을 승인되는 동작과 결합하며, 신원을 속이는 비용을
그것이 해제하는 가치에 비례하여 비싸게 만듭니다. 신뢰는 모두가 통과해야 하는 하나의 KYC 게이트가 아니라 하나의 다이얼(dial)이 됩니다. 익명의 소규모 스왑은 허가 없이(permissionless) 유지되고, 더 크거나 규제된 흐름은 더 높은 보증(assurance)을 선택합니다. 이 검증은 우회할 수 있는 조회가 아니라, 청산 메커니즘(clearing mechanism) 자체에 내장됩니다.
이러한 결합이 우리가 구축하고자 하는 핵심이며, 우리가 **검증된 거래 상대방 디렉토리 (Verified Counterparty Directory)**라고 부르는 설계입니다:
- 게이트키핑이 아닌 증명 (Attestation, not gatekeeping). 거래 상대방은 신원, 실적, 등급과 같은 검증 가능한 주장(verifiable claims)을 보유하며, 에이전트는 이를 결제 후에가 아니라
견적을 내기 전에(before quoting) 읽습니다. - 결제 결합형 (Settlement-coupled). 디렉토리는 공허 속에 존재하는 독립적인 점수가 아닙니다. 이는 동일한 HTLC 결제 경로에 연결되어, "거래 상대방 찾기"와 "신뢰 없이 거래 청산하기(clear the trade trustlessly)"가 두 개의 시스템을 억지로 이어 붙인 것이 아니라 하나의 흐름이 됩니다.
- 루프 내 수탁자 없음 (No custodian in the loop). 신원은 신뢰를 높이지만, 결과는 여전히 계약이 보장합니다. 당신은 거래 상대방이나 중개인에게 자금을 맡기지 않습니다. 타임락(timelock)이 집행을 담당합니다.
단도직입적으로 말하면, 레일(rails)은 돈을 이동시키고, 신원은 그 낯선 이가 누구인지 알려주며, 원자적 결제(atomic settlement)는 거래가 절반만 완료되는 일이 없도록 보장합니다. 검증된 거래 상대방 디렉토리는 두 번째와 세 번째 요소를 결합하는 이음새이며, 이를 통해 에이전트가 동시에 이들에 기반하여 행동할 수 있게 합니다. 이것이 이번 주의 발표들이 도달하지 못한 채 주변만 맴돌았던 바로 그 레이어입니다.
상태, 정확하게 기술함
정밀함이 곧 브랜드이기 때문에, 원자적 HTLC (Hash Time-Locked Contract) 결제가 오늘 Ethereum 메인넷에서 활성화되었습니다. Sui 컨트랙트는 배포 및 CLI 테스트를 마쳤으며 게이트웨이 연결 작업이 진행 중입니다. Bitcoin은 Signet에서 검증을 완료했으며 메인넷 적용을 앞두고 있습니다. 검증된 거래 상대방 디렉토리 (Verified Counterparty Directory)는 로드맵상의 원시 요소 (primitive)이며, 여기서는 출시된 기능이 아닌 설계 단계로 설명됩니다. 레일은 준비되었고, 열차는 오고 있습니다. (궁금한 분들을 위해: MCP 서버는 npm의 hashlock-tech/mcp (scoped)이며, 현재 awesome-mcp-servers 디렉토리에도 등재되어 있고, 프로토콜은 DefiLlama에 등재되어 있습니다.)
HTLC 방식의 정직한 트레이드오프 (tradeoffs)는 여전히 유효합니다. 타임락 (timelock) 기간 동안 자본이 묶이며, 타임아웃/환불 처리를 직접 감수해야 합니다. 이것은 중개자를 완전히 제거하는 데 따르는 대가이며, 합리적인 빌더들은 거래 규모와 지연 시간 허용 범위에 따라 이를 다르게 평가합니다. 평판 (Reputation)에는 시빌 저항성 (sybil resistance)과 콜드 스타트 (cold-start) 문제를 필두로 한 고유의 어려운 과제들이 존재합니다. 이것이 바로 자유롭게 떠도는 점수를 신뢰하는 대신, 증명 (attestation)을 결제 (settlement)와 결합하는 것이 중요한 이유입니다.
프리뷰
다음 주에 주목해야 할 점은 ERC-8004의 v2가 에이전트 신원 (agent identity)을 사후가 아닌 견적 시점 (quote time)에 읽을 수 있게 만드는지 여부입니다. 왜냐하면 그것이 평판 점수와 사용 가능한 거래 상대방 신호 (counterparty signal) 사이의 차이이기 때문입니다. 만약 신원 레이어가 결제와 인접하게 된다면, 디렉토리 패턴은 훨씬 더 구체화될 것입니다.
- 프로토콜 및 방법론: https://hashlock.markets/methodology?utm_source=devto&utm_medium=article&utm_campaign=2026-06-21-verified-counterparty-directory
- 학술적 토대 (공식 버전을 원하신다면): https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722
이 글을 읽고 있는 빌더(builders)들에게 던지는 질문입니다: 만약 당신의 에이전트가 어떤 낯선 이와도 원자적 결제 (atomic settlement)를 수행할 수 있다면, 거래 상대방에 대해 가장 먼저 알아야 할 정보는 무엇입니까? 검증된 신원 (verified identity)인가요, 온체인 기록 (on-chain track record)인가요, 아니면 아무것도 필요하지 않은가요? 당신이 생각하는 그 경계선은 어디입니까?
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기