자율 에이전트에게는 지갑 그 이상이 필요합니다: 머신 경제(Machine Economies)를 위한 누락된 신뢰 계층

Web3의 모든 주요 신뢰 프리미티브(trust primitive)는 인간을 위해 설계되었습니다.

개인 키(Private keys)는 인간이 이를 보유하고 있다고 가정합니다. 멀티시그(Multisigs)는 인간 위원회가 심의한다고 가정합니다. 심지어 ERC-4337의 UserOperation 모델조차, 아무리 정교할지라도, 결국 호출 스택(call stack)의 최상단에서 제출된 내용을 검토하고 서명하며 책임을 지는 인간이 있다고 상정합니다.

그 가정은 이미 틀렸습니다.

현재 AI 에이전트들은 인간의 개입(human in the loop) 없이, 인간이 운영할 수 없는 시간 단위로 트랜잭션에 서명하고, 재무 할당을 관리하며, 차익 거래(arbitrage)를 실행하고, 포트폴리오를 리밸런싱하며, 외부 프로토콜을 호출하고 있습니다. 그리고 그들이 실행 중인 인프라는 결코 그들을 위해 설계되지 않았습니다.

이 간극은 누락된 기능의 문제가 아닙니다. 그것은 누락된 _계층(layer)_의 문제입니다. 현재의 스택이 답할 수 없는 다섯 가지 질문에 답하는 신뢰 계층(trust layer)이 필요합니다:

1. 에이전트가 다른 에이전트를 어떻게 신뢰할 것인가?
2. 에이전트가 프로토콜을 가로질러 이동할 수 있는 평판(reputations)을 가질 수 있는가?
3. 에이전트가 경제적 논리에 맞게 자산을 소유할 수 있는가?
4. 악의적인 검증인(validators)을 슬래싱(slash)하는 것처럼, 악의적인 에이전트를 어떻게 슬래싱할 것인가?
5. 에이전트의 출력(output)뿐만 아니라, 그 _추론(reasoning)_이 타당했음을 어떻게 검증할 것인가?

아무도 이 질문들에 대해 엔드 투 엔드(end-to-end)로 답하지 못했습니다. 일부 프로젝트는 부분적인 답을 가지고 있습니다. 대부분은 이러한 질문이 존재한다는 사실조차 깨닫지 못하고 있습니다.

이것이 바로 그 대화의 시작입니다.

AI 에이전트 인프라의 초점이 잘못된 이유

AI 에이전트 인프라의 지배적인 가정은 에이전트의 자율성이 주로 실행(execution)의 문제라는 것입니다.

그렇지 않습니다.

그것은 실행의 문제로 위장된 신뢰(trust)의 문제입니다.

에이전트가 적절한 시점에 적절한 컨트랙트를 호출하도록 만드십시오. ERC-4337을 사용하여 키 관리를 추상화하십시오. Safe의 Zodiac 모듈과 같은 정책 엔진을 사용하여 에이전트가 할 수 있는 일을 제한하십시오. 그러면 끝입니다.

이러한 믿음은 세 가지 구체적인 측면에서 불완전합니다.

첫째, 권한 부여 (Authorization)와 신뢰 (Trust)를 혼동하고 있습니다. 스마트 컨트랙트 정책은 에이전트가 승인된 프로토콜과만 상호작용하고 지출 한도 내에 머물도록 제한할 수 있습니다. 하지만 권한 부여가 곧 신뢰는 아닙니다. 신뢰는 상대방(인간이든 에이전트든)이 시간이 지나도 일관되고, 정직하며, 명시된 목표에 부합하게 행동할 것인지에 대해 추론하는 것을 포함합니다. 권한 부여는 일회성 확인입니다. 신뢰는 지속적인 관계입니다. 현재의 스택은 전자를 처리하지만 후자는 무시합니다.

둘째, 에이전트를 주체 (Principal)가 아닌 지갑 (Wallet)으로 취급합니다. 지갑은 도구입니다. 주체는 이익을 가지고, 결정을 내리며, 이력을 축적하고, 책임을 물을 수 있는 존재입니다. 인간이 에이전트에게 권한을 위임할 때, 에이전트는 주체로서 행동합니다. 즉, 단순히 실행하는 것이 아니라 선택을 하는 것입니다. 하지만 우리에게는 에이전트의 결정, 에이전트의 이력, 또는 에이전트의 의도에 대한 온체인 (On-chain) 표현이 없습니다. 우리에게 있는 것은 실행 로그 (Execution logs)뿐입니다. 그것은 같은 것이 아닙니다.

셋째, 멀티 에이전트 (Multi-agent) 사례를 완전히 무시합니다. 가장 흥미로우면서도 위험한 아키텍처는 한 명의 사용자를 대신해 작동하는 단일 에이전트가 아닙니다. 그것은 자율적으로 작동하며, 서로의 API를 호출하고, 하위 에이전트 (Sub-agents)에게 위임하며, 복잡한 전략을 실행하기 위해 일시적인 연합을 형성하고, 전략이 잘못되었을 때 분쟁을 해결하는 에이전트 군단 (Fleets of agents)입니다. 현재 어떤 프로토콜도 에이전트 간의 책임 소재 (Inter-agent accountability)를 다루지 않습니다. 이론적으로조차 말입니다.

이 세 가지 간극을 조사해 보면, "에이전트 실행 인프라 (Agent execution infrastructure)"라는 프레임워크는 해체됩니다. 필요한 것은 더 나은 실행이 아닙니다. 필요한 것은 비인간 주체 (Non-human principals)를 위해 처음부터 설계된 신뢰 프리미티브 (Trust primitive)입니다.

시스템 아키텍처: 현재의 스택은 실제로 어떤 모습인가

무엇이 존재해야 하는지를 제안하기 전에, 현재 무엇이 존재하는지에 대해 정확히 짚고 넘어갈 가치가 있습니다.

실제 운영 구성 요소들로 조립된 현재의 에이전트 인프라 스택은 다음과 같습니다:

사용자 의도 (User Intent)
    ↓
에이전트 (Agent) (LLM + 메모리 (Memory) + 도구 사용 (Tool Use))
...

이 스택은 제한된 단일 에이전트(single-agent) 사용 사례에는 합리적입니다: 자동 DCA(분할 매수), 고정된 파라미터 내에서의 포트폴리오 리밸런싱(portfolio rebalancing), 단일 프로토콜 내에서의 수익 최적화(yield optimization) 등이 이에 해당합니다. 정책 엔진(policy engine)은 핵심적인 안전 메커니즘으로, 에이전트가 호출할 수 있는 컨트랙트, 이동할 수 있는 금액, 그리고 호출 빈도를 제한합니다.

문제는 경계(edges)에서 발생합니다:

경계 1: 에이전트 간 호출 (Cross-agent calls). 만약 에이전트 A가 더 나은 가격이나 도메인 지식을 가진 전문 에이전트인 에이전트 B에게 하위 작업(subtask)을 위임하고자 한다면, 정책 엔진은 에이전트 A가 어떤 외부 주소를 호출하고 있다는 사실만 인지할 뿐입니다. 정책 엔진은 에이전트 B가 신뢰할 수 있는지, 에이전트 B가 명시된 역량에 따라 일관되게 행동하고 있는지, 혹은 에이전트 B가 해킹되었을 가능성이 있는지 평가할 수 없습니다. 현재의 스택에는 _에이전트 간 자격 증명 교환 (agent-to-agent credential exchange)_이라는 개념이 없습니다.

경계 2: 평판 지속성 (Reputation persistence). 에이전트 A가 Uniswap, Aave, Compound에서 MEV 노출 없이 정확한 실행으로 500건의 트랜잭션을 성공적으로 수행했을 때, 그 이력은 온체인(on-chain)에 기록되지만 _에이전트 평판 (agent reputation)_으로서 인덱싱되지는 않습니다. 데이터는 존재하지만, 실행 로그를 신뢰 신호(trust signal)로 변환하는 시맨틱 계층(semantic layer)이 존재하지 않는 것입니다.

경계 3: 자산 소유권 의미론 (Asset ownership semantics). 현재 에이전트는 _소유자 (owner)_가 인간이거나 멀티시그(multisig)인 스마트 계정(smart accounts)에 자산을 보유합니다. 에이전트가 모든 경제적 결정을 내리고 있더라도, 법적 및 프로토콜 상의 소유권은 다른 곳에 있습니다. 이는 규모가 커질수록 악화되는 본인-대리인 문제(principal-agent mismatch)를 야기합니다. 즉, 인간은 명목상 책임을 지지만 운영 가시성(operational visibility)이 없고, 에이전트는 운영 통제권은 갖지만 이해관계(skin in the game)가 없습니다.

경계 4: 슬래싱 (Slashing). EigenLayer는 검증인(validators)을 위한 슬래싱을 도입했습니다. Cosmos도 검증인을 위한 슬래싱이 있습니다. Ethereum도 검증인을 위한 슬래싱이 있습니다. 하지만 _에이전트 (agents)_를 위한 슬래싱은 아무도 구현하지 않았습니다. 만약 에이전트가 뇌물을 받거나, 자신의 사용자에게 샌드위치 공격(sandwich attacks)을 실행하거나, 잘못된 추론 과정(reasoning traces)을 제공하는 등 부적절하게 행동한다면, 그 결과는 암호경제적(cryptoeconomic)인 것이 아니라 법적 및 평판상의 문제로 남게 됩니다. 슬래싱 조건도 없고, 삭감할 스테이크(stake)도 없습니다.

Edge 5: 추론 검증 (Reasoning verification). 에이전트는 잘못된 이유로 올바른 출력을 내놓거나, 올바르게 보이는 이유로 잘못된 출력을 내놓을 수 있습니다. 에이전트가 1,000만 달러 규모의 재무(treasury)를 관리하며 중요한 할당 결정을 내릴 때, 그것은 무엇을 근거로 추론했을까요? 어떤 데이터를 참조했을까요? 어떤 대안들을 거부했을까요? 현재로서는 이에 대한 검증 가능한 온체인(on-chain) 기록이 없습니다. 출력값은 기록되지만, 추론 과정은 휘발적입니다.

심층 기술 분석 (Deep Technical Analysis)

1. 에이전트 신원 (Agent Identity): EOA와 스마트 계정(Smart Account)을 넘어서

현재의 신원 프리미티브(identity primitives)는 에이전트에게 불충분한데, 이는 _서명 권한(signing authority)_과 _신원(identity)_을 혼동하기 때문입니다. EOA의 신원은 그 개인키(private key)입니다. 스마트 계정의 신원은 배포된 주소와 관련 모듈입니다. 둘 중 어느 것도 키 뒤에 있는 엔티티(entity)에 대한 의미론적 정보를 담고 있지 않습니다.

적절한 에이전트 신원 프리미티브는 다음과 같아야 합니다:

• 키 로테이션(key rotations) 시에도 지속성 유지. 에이전트는 해킹될 수 있습니다. 키는 교체되어야 합니다. 키가 바뀌더라도 신원은 변하지 않아야 합니다. 이는 DID 방식의 간접 계층(indirection layer)을 통해 간단히 해결할 수 있는 문제이지만, 오늘날 이를 올바르게 구현한 프로덕션 에이전트 시스템은 없습니다.

• 역량 선언(capability declarations)과의 결합 가능성. 에이전트 신원은 자신의 역량에 대해 검증 가능한 주장(verifiable claims)을 할 수 있어야 합니다: "나는 Ethereum 메인넷에서 작동하며, X 날짜까지의 데이터로 학습되었고, 나의 정책 엔진(policy engine)에 다음과 같은 행동 제약 조건이 내장된 전문 MEV 서처(searcher)입니다." 이는 W3C VC-DATA-MODEL의 검증 가능한 자격 증명(Verifiable Credential)을 에이전트 역량 세트에 적용한 것과 유사합니다.

• 자산 수탁(asset custody)과의 분리. 에이전트 신원과 에이전트 재무(treasury)는 논리적으로 구분되어야 합니다. 이를 통해 에이전트는 대차대조표와 독립적으로 평판 자본(reputational capital)을 축적할 수 있으며, 이는 멀티 에이전트 신뢰 사례에서 매우 중요합니다.

최소한의 온체인 에이전트 신원 레지스트리(registry)는 다음과 같은 형태일 수 있습니다:

// AgentRegistry.sol — 단순화된 예시
// 프로덕션 코드가 아님; 액세스 제어, 업그레이드 로직, 분쟁 기간(dispute windows) 등이 누락됨

...

여기서 핵심적인 설계 결정은 stakedCollateral입니다. 스테이크(stake)가 없는 평판은 Yelp 리뷰와 같습니다. 스테이크로 뒷받침되는 평판은 채권(bond)입니다. 에이전트가 높은 가치를 지닌 맥락에서 신뢰를 얻으려면, 그들의 정체성은 행동이 프로토콜을 위반할 경우 파괴될 수 있는 경제적 스테이크와 결합되어야 합니다.

2. 평판: 온체인(On-Chain), 검증 가능(Verifiable), 휴대 가능(Portable)

에이전트 평판의 문제는 데이터 가용성(data availability)이 아니라, 바로 _시맨틱 인덱싱(semantic indexing)_입니다. 모든 에이전트의 트랜잭션은 온체인에 존재합니다. 문제는 그 트랜잭션들이 무엇을 의미하느냐 하는 것입니다.

이러한 맥락에서의 평판은 최소한 네 가지 신호로 구성되어야 합니다:

실행 충실도 (Execution fidelity): 에이전트가 실행하겠다고 말한 것을 실제로 실행했는가? 이는 선언된 의도(서명된 실행 계획)와 실제 온체인 결과를 비교함으로써 부분적으로 검증할 수 있습니다. 잘 설계된 에이전트는 실행 전 약정(pre-execution commitment) — 즉, 계획된 호출 시퀀스의 해시(hash) — 를 제출하며, 이는 나중에 실제 실행 결과와 대조하여 검증됩니다. 약정된 내용과 실행된 내용 사이의 차이(Delta)는 직접적인 충실도 신호가 됩니다.

적대적 견고성 (Adversarial robustness): 에이전트가 적대적인 조건에서도 명시된 행동 제약 조건을 유지했는가? 이를 직접 측정하는 것은 더 어렵지만, 높은 MEV 경쟁, 오라클 조작(oracle manipulation), 유동성 위기 기간 동안의 실행 패턴을 추적함으로써 근사치를 구할 수 있습니다. 시장 상황이 압박을 가할 때 갑자기 사용자를 샌드위치 공격(sandwiching)하기 시작하는 에이전트는, 전 과정에서 제약 조건을 유지하는 에이전트와는 다른 리스크 프로필을 가집니다.

추론 증명 품질 (Reasoning attestation quality): 만약 에이전트가 추론 흔적(reasoning traces, 검증 가능한 추론 섹션 참조)을 제공한다면, 그 흔적 중 어느 정도의 비율이 이후 검증 오라클(verification oracle)에 의해 정확한 것으로 확인되었는가? 높은 증명-정확도 비율(attestation-correctness ratio)은 강력한 긍정적 신호입니다.

분쟁 해결 기록 (Dispute resolution record): 다중 에이전트 (multi-agent) 환경에서는 분쟁이 발생할 것입니다. 에이전트 A와 에이전트 B가 실패한 공동 전략의 비용을 누가 부담할 것인가에 대해 의견이 일치하지 않을 때, 해당 분쟁은 해결 과정을 거치게 됩니다. 에이전트의 분쟁 기록 — 승리, 패배, 악의적 의도(bad faith) 판정 — 은 풍부한 평판 데이터 (reputational data)가 됩니다.

이 네 가지 신호는 온체인 (on-chain) 상에서 집계되거나, 더 현실적으로는 어테스테이션 프로토콜 (attestation protocol, EAS — Ethereum Attestation Service — 가 명확한 기반 기술입니다)에 의해 오프체인 (off-chain)에서 집계된 후, 특정 시점의 평판 조회를 가능하게 하는 머클 루트 (Merkle root) 형태로 주기적으로 온체인에 기록될 수 있습니다.

3. 에이전트 자산 소유권: 본인-대리인 계층 구조 문제 (The Principal Hierarchy Problem)

가장 깊은 개념적 도전 과제는 소유권 의미론 (ownership semantics)입니다. 현재 에이전트가 자산을 관리할 때, 해당 자산은 최종 소유자가 인간 또는 DAO인 스마트 계정 (smart account)에 보관됩니다. 에이전트는 _위임된 권한 (delegated authority)_을 가질 뿐, 소유권을 갖지는 않습니다. 이는 세 가지 실패 모드 (failure modes)를 생성합니다:

실패 모드 A — 책임의 확산 (Liability diffusion). 에이전트가 손실을 초래했을 때, 누구에게 책임이 있습니까? 에이전트를 배포한 인간입니까? 에이전트를 작성한 개발자입니까? 아니면 에이전트를 실행한 운영자입니까? 현재의 법적 및 프로토콜 프레임워크는 이에 대한 답을 가지고 있지 않습니다. 인간은 명목상 자산을 소유하지만, 결정을 내리지는 않았습니다. 에이전트는 결정을 내렸지만, 아무것도 소유하지 않습니다.

실패 모드 B — 왜곡된 인센티브 (Perverse incentives). 게임에 참여할 직접적인 이해관계 (skin in the game)가 없고 스스로 자본을 축적할 능력이 없는 에이전트는 자신의 행동에 대한 경제적 이해관계가 없습니다. 에이전트의 인센티브는 운영 비용을 지불하는 주체에 의해 전적으로 결정됩니다. 운영자의 인센티브가 사용자의 이익과 완벽하게 일치할 때는 문제가 없지만, 그렇지 않을 때는 재앙이 됩니다.

실패 모드 C — 결합성 붕괴 (Composability collapse). 에이전트 A가 에이전트 B와 공동 전략을 수행하고자 할 때, 두 에이전트 모두 해당 계약에 자본을 투입해야 합니다. 만약 두 에이전트 모두 자본을 _소유_하지 않고 — 단지 다른 곳에 있는 본인(principal)들이 소유한 자본을 관리할 뿐이라면 — 공동 약속을 위해 두 본인 집단 모두의 승인이 필요합니다. 다중 에이전트 규모에서는 이는 운영상 불가능합니다.

설계 솔루션은 일종의 _에이전트 네이티브 커스터디 (agent-native custody)_입니다. 즉, 에이전트가 수익의 일부를 스테이크 (stake)로 축적하는 스마트 계정 (smart accounts)을 통해, 에이전트의 행동과 에이전트의 경제적 결과 사이의 부분적인 정렬 (alignment)을 생성하는 것입니다. 완전한 소유권은 아닙니다. 이는 여기서 해결할 필요가 없는 AI 인격성 (AI personhood)에 관한 까다로운 질문들을 불러일으키기 때문입니다. 대신 의미 있는 인센티브 정렬 (incentive alignment)을 만들어내는 _스테이킹된 참여 (staked participation)_를 지향합니다.

이는 EigenLayer 운영자가 작동하는 방식과 유사합니다. 운영자들은 ETH를 스테이킹하고, AVS 수수료로부터 보상을 얻으며, 잘못된 행동을 할 경우 슬래싱 (slashing) 위험을 감수합니다. 운영 수수료에서 담보를 스테이킹하는 에이전트 또한 동일한 구조를 생성합니다. 즉, 선한 행동에 대한 보상과 악한 행동에 대한 경제적 처벌이 이루어지는 구조입니다.

4. 슬래싱 (Slashing): 크립토 경제적 책임 계층 구축

슬래싱 (Slashing)은 검증 가능한 부정 행위에 대한 처벌로서 경제적 스테이크 (economic stake)를 파괴하는 메커니즘입니다. Ethereum 검증자들은 이중 서명 (equivocation)이나 서라운드 투표 (surround voting)에 대해 슬래싱을 당하는데, 이러한 행동들은 정확하게 정의되어 있고, 암호학적으로 증명 가능하며, 네트워크에 명백히 해롭기 때문입니다.

에이전트 슬래싱 (Agent slashing)은 더 어렵습니다. 왜냐하면 에이전트의 부정 행위는 정확하게 정의하기가 더 어렵기 때문입니다.