왜 지금 이 두 가지를 비교하는가

안녕하세요, 블록체인 × AI 에이전트로 자율 경제권을 만드는 Komlock lab에서 엔지니어로 일하고 있는 오바라(@brto_0224)입니다.

이 기사를 시작으로, Komlock lab과 Coincheck의 공동 연구로서 AI 에이전트에 관한 것을 테마로 한 연재를 시작합니다. 이번에는 「AI 에이전트가 거래를 수행하는 시대」를 향한 공동 연구로서, 암호자산 영역에서의 실무·규제 대응 지견을 활용하며 진행해 나가겠습니다. 매회 하나의 질문을 던지고, 실제로 만져보며 확인한 것을 써 내려가겠습니다.

첫 번째 단계는 저희가 만들고 있는 Kova와, MetaMask가 내놓은 Agent Wallet의 비교입니다. MetaMask Agent Wallet은 현재 얼리 액세스(Early Access) 중인 프로덕트로, 운 좋게 초대를 받아 실제로 사용해 보고 있습니다.

문서를 읽은 시점에서, 정책(Policy) 주변의 설계가 상당히 다를 것 같다고 느꼈습니다. 실제로 만져보며 가설을 검증해 보니, 생각했던 것 이상으로 설계 사상이 나뉘어 있었습니다.

AI 에이전트에게 지갑을 들려준다는 행위에는 애초에 근본적인 불안이 뒤따릅니다. 2026년 1월에는 Step Finance에서 약 261,000 SOL 이상(약 $27~30M 상당)이 유출되는 사건이 발생했습니다. 보도에 따르면 경영진의 디바이스 침해가 주된 원인으로 지목되는 한편, AI 트레이딩 에이전트에게 큰 권한을 부여했던 것이 피해 확대의 한 원인으로 지적되고 있습니다.

AI 에이전트 월렛은 인간이 매번 승인하지 않아도, 에이전트가 송금·스왑·API 이용료 지불 등을 자율적으로 수행할 수 있도록 하는 월렛입니다. 에이전트에게 무엇을 어디까지 맡길 것인가. 그것을 결정하는 것이 **정책 (Policy)**이라 불리는 메커니즘입니다. Kova도 MetaMask Agent Wallet도 이 단어를 사용하고 있습니다. 하지만 실제로 내용을 나란히 놓고 보면, 같은 단어로 전혀 다른 것을 가리키고 있었습니다.

비교의 척도를 결정하기: MetaMask 공식의 「5개 레이어」

Kova와 MetaMask Agent Wallet을 비교하기 전에, 무엇을 기준으로 비교할지를 정해둡니다.

마침 MetaMask는 2026년 6월 29일 공식 블로그에서, Agentic Wallet을 평가하기 위한 5가지 레이어를 제시했습니다.

커스토디 모델 (Custody Model): 비밀키를 어디서 어떻게 보관할 것인가 -
허가 모델 (Permission Model): 에이전트에게 무엇을 어디까지 시킬지를 어떻게 정의할 것인가 -
사전 실행 보안 체크 (Pre-execution Security Check): 트랜잭션을 보내기 전에 무엇을 확인할 것인가 -
승인 로직 (Approval Logic): 누가·언제·어떻게 최종 판단을 내리는가 -
자금 실행 측면 (Fund Execution): 실제 송금·서명이 어디서 실행되는가

자신들의 프로덕트를 자신들에게 유리한 축으로 평가하는 것이 아니라, MetaMask 스스로가 공개하고 있는 평가 축에 올려 비교하는 것이 논점을 맞추기에 좋습니다. 이후에는 이 5개 레이어에 따라 Kova와 MetaMask Agent Wallet을 하나씩 살펴보겠습니다.

Kova의 설계: 개발자가 규칙을 작성한다

Kova는 Open Wallet Standard (OWS, 비밀키를 에이전트에 노출시키지 않고 여러 체인에서 자산을 다루기 위한 업계 표준)를 기반으로 한 CLI 도구입니다. 비밀키는 로컬에서 AES-256-GCM 암호화를 하여 저장하며, Komlock lab 측의 서버로는 전송되지 않습니다.

셋업은 명령어 하나로 완료됩니다.

이 명령어를 통해 월렛 생성·정책 설정·에이전트용 인증 정보 발행까지 대화 형식으로 진행됩니다.

Kova의 허가 모델은 개발자가 JSON으로 규칙을 선언하는 형태를 취합니다.

spending_limit : 체인과 토큰의 조합별 일일/월간 한도. 송금을 허가하는 토큰도 이 쌍(pair)으로 실질적으로 정의됨 -
allowed_chains : 조작을 허가하는 체인 (CAIP-2 형식) -
expires_at : 정책의 유효 기간 -
sign_allowlist : 서명을 허가하는 메시지의 범위

이러한 규칙들은 Kova가 OperationKind라고 부르는 3가지 분류 중 policy-gated (자금 이동을 동반하는 조작)에만 적용됩니다. read-only (잔액 조회 등)는 규칙 적용 없이 즉시 실행되며, owner-only (키 생성이나 정책 자체의 업데이트)는 에이전트 경로를 통해서는 실행할 수 없습니다. 패스프레이즈(Passphrase)를 가진 인간이 터미널에서 조작하지 않는 한, 정책은 바뀌지 않는다는 뜻입니다.

사전 실행 보안 체크(Pre-execution security check)에 해당하는 부분은 fail-closed 설계로 구현되어 있습니다. 에이전트가 송금을 시도하면 실제 RPC 호출이 이루어지기 전에 정책 평가(Policy evaluation)가 실행되며, 위반 사항이 있으면 그 즉시 거부됩니다.

자금 실행 측면은 dry-run이 기본값입니다.

# 우선은 시뮬레이션만 수행 (실제 전송되지 않음)
kova send --name default --to 0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb --amount 0.001 --chain base-sepolia
# --broadcast 를 붙여야 비로소 실제 전송됨
...

흐름을 도식화하면 다음과 같습니다.

Kova를 만드는 입장에서 보면, 이 설계의 핵심은 정책을 위반했을 때 기계가 문답무용으로 멈추게 하는 데 있습니다. 인간의 판단을 기다리지 않고 거부할 수 있다는 것이 실제 동작 방식입니다.

MetaMask Agent Wallet의 설계: 모드를 선택하다

MetaMask Agent Wallet은 2026년 6월 8일에 얼리 액세스(Early Access)를 시작한, 서버 측의 TEE(Trusted Execution Environment, 신뢰할 수 있는 실행 환경)에서 서명 키를 보호하면서 사용자가 시크릿 복구 구문(Secret Recovery Phrase)을 내보낼 수 있는 자기 관리형(Self-custodial) 지갑입니다.

mm init

으로 실제로 설정을 진행하면, 처음에 이 선택을 요구받게 됩니다.

「Server Wallet」을 선택하면 키는 서버 측에서 관리되며, 에이전트는 개인 키(Private Key) 자체에는 접근할 수 없습니다.

허가 모델은 모드 선택이라는 형태를 취합니다. Kova처럼 개발자가 JSON으로 규칙을 선언하는 방식과는 접근법이 다릅니다.

# Guard Mode(기본값)로 초기화
mm init --wallet server-wallet --mode guard
# 나중에 Beast Mode로 변경할 수도 있음
...

Guard Mode에서는 네트워크 허가 목록(Allowlist), 주소 허가 목록, 토큰 수취인 허가 목록, 24시간 롤링 유출 제한(24-hour rolling outflow limit)과 같은 가드레일(Guardrail)이 자동으로 활성화되며, 여기서 벗어나는 모든 거래는 인간의 승인을 요구합니다. Beast Mode는 이러한 허가 목록을 해제하고 알림 빈도를 낮추는 대신, 위협 스캔(Threat scan)을 통해 악성으로 판정된 거래만을 인간에게 전달합니다.

mm init의 모드 선택 화면에는 이 두 가지 차이점이 그대로 표시됩니다.

실제로 이번 검증용으로 준비한 지갑의 설정을 mm wallet policy get으로 확인하면 다음과 같이 반환됩니다.

{
"wallet_address": "0x37efa27f82db502124faa7451f813a219740927b",
"addresses": { "allowlist": [], "blocklist": [] },
...

rolling_24h: 0 즉, 이 지갑은 현재 소액이라도 자금을 외부로 유출하려고 하면 가드레일 외 상황 = 인간 승인 대기 상태가 되는 설정입니다. Guard Mode의 기본값은 "우선 전부 인간에게 묻는다" 쪽으로 치우쳐 있습니다.

사전 실행 보안 체크는 트랜잭션 시뮬레이션, Blockaid(MetaMask가 채택한 사기·부정 거래 탐지 서비스)에 의한 위협 스캔, MEV 보호의 3단계로 이루어집니다. 안전하다고 판정된 대상 거래에 대해서는 Transaction Protection으로서 월 $10,000까지 보상 대상이 된다고 합니다.

승인 로직의 핵심은 2FA(2단계 인증)입니다. 정책 외 거래나 리스크가 있다고 판정된 거래는 AWAITING_MFA라는 상태로 진입하며, MetaMask Mobile(QR 코드) 또는 이메일(브라우저를 통해 로그인한 경우)을 통해 인간의 승인을 기다립니다.

실제로 Guard Mode에서 1 USDC 송금(유출 한도 초과 + 송금처가 허가 목록 외)을 통해 이를 발생시켜 보았습니다.

승인 화면에는 위반 이유가 두 가지 나란히 표시되어 있으며, outflow.limit_usd(24시간 유출 한도 $0 초과)와 whitelist.token_recipient(송금처가 허가 목록 외)가 동시에 검출되었습니다. 한 건의 거래에 대해 여러 개의 위반 이유가 한꺼번에 제시됩니다.

자금 실행 측면은 송금이나 스왑과 같은 조작을 에이전트 자신의 지갑에서 직접 실행하는 형태입니다.

mm transfer --to <address> --amount <value> --chain-id <id> --token <symbol>
mm swap quote --from ETH --to USDC --amount 1.5
mm swap execute --quote-id <quote-id>

나란히 놓고 보면 알 수 있는 것: 사전 거부와 인간 게이트웨이 (Human Gateway)

여기까지 읽으면 세부적인 구현 차이처럼 보일 수 있지만, 정리하면 차이점은 상당히 단순합니다. 5개 레이어(Layer)로 나열해 보면 차이가 명확해집니다.

가장 큰 차이점은 규칙 위반이 발생했을 때 무엇이 작동하느냐입니다. Kova는 기계가 실행 전에 거부하고 종료합니다. 인간은 관여하지 않습니다. MetaMask Agent Wallet의 가드 모드 (Guard Mode)는 정책 외 거래를 중단시킨 후, 인간에게 판단을 넘깁니다. 둘 다 에이전트의 폭주를 방지하는 것이 목적이지만, 그 과정에 인간을 개입시키느냐 아니냐에 따라 설계가 나뉩니다.

권한 분리 방식에도 차이가 있습니다. Kova는 정책 업데이트 자체를 owner-only(소유자 전용)로 취급하여, 에이전트 경로에서는 건드릴 수 없도록 하고 있습니다. 정책을 완화하고 싶다면 인간이 터미널에서 패스프레이즈 (Passphrase)를 입력하는 방법뿐입니다.

MetaMask Agent Wallet에 대해서는 이 부분이 공개 문서만으로는 파악되지 않아, 실제로 에이전트 경로(인간이 대화형으로 조작하지 않는, 비 TTY CLI 호출)에서 mm wallet trading-mode set beast를 입력하여 확인해 보았습니다.

$ mm wallet trading-mode set beast
{
"ok": false,
...

확인 프롬프트 (Confirmation Prompt)를 자동으로 통과할 수 있는지 확인하기 위해, 표준 입력 (Standard Input)에 y를 흘려보내는 시도도 해보았습니다.

$ echo "y" | mm wallet trading-mode set beast
{
"ok": false,
...

결과는 동일한 에러로 거부되었습니다. 메시지 내용대로 TTY(인간이 실제로 키 입력을 할 수 있는 대화형 터미널)인지 여부를 확인하고 있으며, 파이프 (Pipe)나 자동화 경로를 통한 확인은 허용하지 않습니다. 즉, MetaMask Agent Wallet 역시 자신의 가드레일 (Guardrail)을 해제하는 조작(Guard → Beast 전환)은 에이전트 단독으로는 완결할 수 없는 설계였습니다. Kova의 owner-only와는 구현 형태(패스프레이즈 vs TTY 확인)가 다르지만, "정책을 완화하는 조작은 인간의 물리적인 개입을 요구한다"는 결론은 일치합니다.

어느 쪽이 더 우월하다는 이야기가 아닙니다. Kova의 fail-closed 방식은 기관의 자금이나 고액 거래와 같이 실수가 허용되지 않는 상황에 적합합니다. MetaMask Agent Wallet의 Guard/Beast 모드는 개인이나 소규모 팀이 높은 빈도로 트레이딩을 하는 상황, 즉 1회당 피해액이 제한적인 상황에서 알림 피로 (Notification Fatigue)를 일으키지 않으면서 인간의 판단을 남겨두는 설계입니다. 동일한 과제에 대해 서로 다른 답을 내놓은 두 가지 실례라고 보는 것이 정확할 것입니다.

앞으로 어떻게 될 것인가

선언적 규칙 (Declarative Rule, Kova)과 모드 선택 + 인간 승인 (MetaMask Agent Wallet) 중 향후 어느 한쪽으로 통합될까요? 현재로서는 그렇게 단순하게 흘러가지는 않을 것 같습니다.

한 가지 단서는 Open Wallet Standard (OWS)라는 움직임입니다. MoonPay가 2026년 3월 23일에 MIT 라이선스로 공개한 표준으로, 비밀키 (Private Key)를 에이전트의 프로세스나 LLM의 컨텍스트 (Context)에 전혀 노출시키지 않으면서, 여러 체인에서 자산의 보유, 서명, 결제를 가능하게 하는 것을 목표로 합니다. PayPal, OKX, Ripple, Ethereum Foundation, Solana Foundation, Circle 등 15개 이상의 기업이 이름을 올리고 있으며, Kova도 이 표준을 채택하고 있습니다.

정책 (Policy)에 의한 지출 제한이나 허가 목록 (Allowlist)이라는 발상 자체는 OWS의 사양에도 포함되어 있습니다. 즉, 규칙을 사전에 작성한다는 부분은 업계로서 공유되기 시작한 토대입니다. 그 위에, Kova처럼 기계가 즉각적으로 거부하는 계층을 두텁게 쌓을 것인지, 아니면 MetaMask Agent Wallet처럼 인간의 최종 승인을 남겨두는 계층을 두텁게 쌓을 것인지는 용도에 따라 선택되어 갈 것이라고 생각합니다.

Discussion