지갑이 AI 에이전트를 내장하기 시작할 때: ERC-8211의 새로운 상호작용 패러다임, 왜 주목할 만한가?

2025년부터 많은 사람들이 새로운 상호작용 방식에 점차 익숙해지기 시작했을 것입니다: GPT나 Gemini에게 "다음 주 홍콩 여행 일정을 계획해 주고 적절한 항공권과 호텔을 추천해 줘"라고 말하면, 그것은 백그라운드에서 정보 검색, 조건 필터링, 경로 선택, 가격 비교 등 일련의 단계를 조용히 완료한 후 최종 결과만 확인하도록 전달합니다.

하지만 동일한 기대를 온체인으로 가져가면 이야기는 완전히 달라집니다.

예를 들어 DeFi 에이전트에게 "지갑에 있는 ETH를 USDC로 교환하고 Base 체인으로 브리징한 후 전액을 Aave에 예치해 줘"라는 명령을 내린다고 가정해 보겠습니다. 객관적으로 말하면, '요구사항 이해'와 '경로 계획' 측면에서 오늘날의 에이전트가 반드시 할 수 없는 것은 아닙니다. 진정한 단절은 실행 단계에서 발생합니다:

여전히 서명, 승인, 교환, 크로스체인, 예치 등 단계별 작업을 완료해야 할 가능성이 높으며, 각 단계마다 슬리피지 변화, 가스비 변동, 브리지 지연 및 온체인 상태 변화의 위험에 노출됩니다. 이는 중간에 한 단계라도 예상에서 벗어나면 앞선 작업을 반드시 롤백할 수 없고, 뒤따르는 작업이 이어지지 못할 수 있음을 의미합니다. 결국 온체인에 남는 것은 종종 완료되지 않은 반쪽짜리 프로세스입니다.

문제는 AI가 충분히 똑똑하지 않다는 것이 아니라, 온체인 실행 레이어가 아직까지 에이전트에 진정으로 적합한 표현 방식을 결여하고 있다는 점입니다.

바로 이러한 이유로, 2026년 4월 초 Biconomy와 이더리움 재단이 공동으로 발표한 ERC-8211은 현재 스마트 계약 실행의 '정적 제한' 문제를 해결하고, AI 에이전트 및 복잡한 DeFi 워크플로우를 위해 더 표현력 있는 실행 레이어를 제공하여 이 누락된 퍼즐 조각을 채우려고 시도합니다. 

1. AI 에이전트가 온체인에 접속하는 '마지막 단절'

지난 1~2년 동안 암호화폐 업계의 관심 초점은 L2 확장, RWA 유동성에서 AI 에이전트가 어떻게 진정으로 온체인 작업을 인수할 것인지라는 매우 파괴적인 주제로 명확히 전환되고 있습니다.

객관적으로 말하면, '자연어로 다단계 DeFi 전략을 지시하는 것'에서 '자율 에이전트가 전체 크로스체인 포트폴리오를 관리하도록 하는 것'에 이르기까지, 최근 우리는 다양한 실천 사례를 목격했으며, 대부분의 구상은 데모 수준에서 이미 성숙했습니다. 자연어 생성 다단계 DeFi 전략, 자율 실행 리밸런싱, 자동 수익 이전, 크로스체인 포지션 조정, 심지어 더 복잡한 포트폴리오 관리까지요.

추론과 오케스트레이션 관점에서 보면, AI의 능력은 상당히 빠르게 발전하고 있습니다. 그러나 실제로 이를 프로덕션 환경에 배치할 때, 실행 레이어의 단점은 점점 더 분명해집니다.

정말로 프로덕션 환경에 적용하려면, 이 단점은 한 문장으로 요약할 수 있습니다: DeFi는 동적이지만, 오늘날 대부분의 배치(batch)는 여전히 정적입니다. 

ERC-8211 공식 웹사이트와 논의 글에서 이 문제를 매우 명확히 설명하고 있습니다. 즉, 기존의 ERC-4337과 EIP-5792는 실제로 '한 번의 서명이 하나의 호출에 대응'하는 구식 모델에서 '한 번의 서명으로 여러 호출을 패키징'할 수 있는 새로운 단계로 발전시켰지만, 이러한 호출의 매개변수는 본질적으로 여전히 서명하는 순간에 고정되는 경우가 많습니다.

다시 말해, 사용자가 서명할 때 입력한 금액, 목표값, 예상 출력은 실제 실행 시점에 온체인 상태 변화에 따라 자동으로 조정되지 않습니다.

그러나 DeFi 자체는 불확실성으로 가득 차 있습니다. 한 번의 스왑의 실제 출력은 실행되는 블록의 슬리피지와 유동성에 달려 있습니다. 한 번의 브리징의 도착 시간과 최종 도착 금액은 브리지 자체의 메커니즘과 수수료에 달려 있습니다. 대출 프로토콜이나 볼트의 share-to-asset 비율도 끊임없이 변화합니다.

결국 사용자나 에이전트가 서명할 때 보는 수치는 많은 경우 현재의 추정치일 뿐, 실행 시점의 실제 결과가 아닙니다.

ERC-8211이 무엇을 해결하는지 이해하려면, 가장 전형적인 예를 살펴보는 것이 좋습니다. 에이전트가 매우 평범해 보이는 일을 하고 싶다고 가정해 보겠습니다. 계정의 ETH를 USDC로 교환한 후 전액을 Spark에 예치하여 이자를 얻는 것입니다.

기존의 정적 배치 처리 모델에서 에이전트는 서명 전에 스왑 후 얼마나 많은 USDC를 받을지 추정해야 하며, 이는 종종 서명 시 두 번째 단계의 입력 금액을 미리 고정하도록 강제합니다. 너무 높게 추정하면 실제 입금액이 부족하여 전체 배치가 직접 롤백되고, 너무 낮게 추정하면 일부 자금이 지갑에 유휴 상태로 남아 아무 일도 할 수 없게 됩니다.

다시 말해, 기본적으로 소위 딜레마에 빠지게 됩니다. 실패 위험을 감수하거나 기회 비용을 감수해야 합니다. 이것이 바로 많은 온체인 프로세스가 겉보기에 복잡하지 않아도, 단계가 5단계, 8단계로 늘어나거나 심지어 두 개의 체인을 가로질러 확장되면 빠르게 취약해지는 이유입니다. 이는 전략 자체가 너무 복잡하여 설명할 수 없기 때문이 아니라, 기존 실행 패러다임이 미리 고정된 매개변수에 너무 의존하기 때문입니다. 

간단히 말해, 정적 배치의 능력 상한은 사실상 에이전트가 실제로 안전하게 실행할 수 있는 전략의 상한을 결정합니다.

이 관점에서 보면, ERC-8211이 해결하려는 것은 AI 에이전트가 어떻게 의사결정을 하는지가 아니라, 에이전트가 이미 의사결정을 내린 후 온체인에 이를 실행할 더 자연스럽고, 안정적이며, 안전한 방식이 있는지 여부입니다. 이를 통해 온체인 실행이 처음으로 AI 에이전트를 위해 네이티브하게 설계된 표현 형태를 갖추게 됩니다. 

2. ERC-8211은 실제로 무엇을 바꾸었나요?

ERC-8211의 핵심 돌파구는 더 많은 단계를 한 번의 서명에 집어넣는 데 있지 않고, 배치 처리를 매개변수가 고정된 트랜잭션 시퀀스에서 '매개변수가 실행 현장에서 동적으로 평가되는 프로그램'으로 업그레이드하는 데 있습니다. 

들어보면 정말 추상적으로 들리지만, 이해하기 어렵지 않습니다. 공식 문서는 이를 설명하기 위해 한 문장을 사용했습니다: From transactions to programs.

이는 ERC-8211이 더 이상 배치를 순서대로 실행되는 작업 목록으로 보지 않고, 런타임에 평가되고 안전 조건을 갖춘 실행 프로그램으로 간주함을 의미합니다. 구체적으로 분해해 보면, 세 가지 조합 가능한 프리미티브를 통해 이를 구현합니다:

• Fetchers(값 추출기): 이 매개변수가 어디에서 값을 가져올지 정의합니다. 이는 특정 주소의 현재 잔액에 대한 한 번의 쿼리가 될 수 있어, 매개변수가 더 이상 서명 시점의 스냅샷이 아니라 실행 순간에 온체인 상태에서 가져온 실시간 판독값이 되도록 합니다.
• Constraints(제약 조건): 매개변수가 해석된 후에는 인라인 제약 조건 검사를 통과해야 합니다. 예를 들어 '교환된 USDC는 적어도 ≥ 2500 이상이어야 함' 또는 '슬리피지는 0.5%를 초과할 수 없음'과 같은 조건입니다. 이러한 제약 조건은 값이 다음 호출로 라우팅되기 전에 검증을 완료하며, 어느 하나라도 통과하지 못하면 전체 배치가 즉시 롤백됩니다.
• Predicates(트리거 조건): 단계 사이의 문지기로 이해할 수 있으며, 값을 생성하는 책임이 아니라 계속 실행할지 여부를 판단하는 책임이 있습니다. 예를 들어 크로스체인 시나리오에서 이더리움 측의 배치는 '크로스체인된 WETH가 이미 입금되었음'이라는 조건을 predicate로 지킬 수 있으며, 입금되기 전까지는 제출하지 않습니다. 

이 설계에서 각 매개변수는 두 가지 질문에 답해야 합니다: 첫째, 이 값은 실행 시 어디에서 와야 하는가; 둘째, 실제로 호출에 사용되기 전에 어떤 조건을 충족해야 하는가. 이렇게 세 가지가 조합되면, 배치는 더 이상 단순한 트랜잭션 시퀀스가 아니라 내장된 안전 검사를 갖춘 프로그램이 됩니다.

결국, 정적 배치 처리의 멘탈 모델은 목록입니다. A, B, C 세 단계를 순서대로 실행합니다. 반면 ERC-8211의 멘탈 모델은 조건이 붙은 프로그램입니다. A 실행 후, A의 실제 출력을 B의 입력으로 사용합니다. B가 제약 조건을 충족해야 C로 진입합니다. 어떤 단계라도 예상에 미치지 못하면 전체 배치가 롤백됩니다.

우리는 사실 이를 AI 에이전트와 복잡한 DeFi 작업을 위해 특별히 설계된 '스마트 배치 처리' 메커니즘으로 간단히 이해할 수 있습니다. 왜냐하면 기존의 온체인 작업에서 복잡한 DeFi 전략을 완료하려면 종종 여러 개의 독립적인 트랜잭션이 필요하기 때문입니다: 대출 프로토콜에서 자금을 인출하고, 토큰을 교환하고, 다른 프로토콜에 다시 예치하는 것까지요(관련 기사 읽기: 암호화 AI 프로토콜 개요: 이더리움의 주요 전장에서 출발하여 AI 에이전트를 위한 새로운 운영 체제를 어떻게 구축할 것인가?). 

각 단계마다 별도의 서명과 확인이 필요하며, 이는 인간 사용자에게는 이미 번거로운 일이지만, 고빈도 자율 작업이 필요한 AI 에이전트에게는 더 큰 병목 현상입니다. ERC-8211의 솔루션은 여러 블록체인 작업을 하나의 트랜잭션에서 조합하여 실행할 수 있도록 허용하고, 각 단계가 실행 시 실제 수치를 동적으로 해석하며, 사전 정의된 조건을 충족해야만 다음 단계로 진행할 수 있도록 하는 것입니다. 

예를 들어, 에이전트는 한 번의 서명 트랜잭션에서 다음을 완료할 수 있습니다: Aave에서 자금 인출 → 실제 수신 금액을 Uniswap에서 교환 → 교환 결과를 Compound에 예치. 모두 원자적으로 실행되며 새로운 스마트 계약을 작성할 필요가 없습니다.

3. 왜 이것이 지갑, 특히 스마트 지갑과 더 관련이 있다고 하는가 

ERC-8211이 지갑 업계의 관심을 끄는 이유는 단지 그것이 에이전트에 적합하기 때문만이 아니라, 상호작용 체인에서 지갑의 위치를 재정의할 것이기 때문입니다.

과거의 지갑은 더욱 안전한 서명기와 같았습니다. 그 역할은 개인 키를 보관하고, 트랜잭션을 표시하며, 사용자가 확인하도록 하고, 서명을 보내는 것이었습니다. 이 역할은 EOA 시대에는 이미 충분히 중요했고, 계정 추상화 시대에도 계속 유효합니다. 그러나 만약 미래에 점점 더 많은 온체인 작업이 에이전트에 의해 대리 수행된다면, 지갑의 역할은 더욱 중앙적이고 중요해질 것입니다.

이유는 간단합니다. 사용자가 더 이상 온체인 작업을 하나씩 조작하지 않고, 에이전트에게 일련의 목표를 실행하도록 권한을 부여하기 시작하면, 지갑은 이러한 더 높은 수준의 상호작용 객체를 수용할 수 있는 능력을 가져야 합니다. 지갑이 표시해야 하는 것은 더 이상 특정 계약 주소와 일부 calldata가 아니라, 전체 '의도-값 추출 로직-조건 판단-최종 결과' 실행 프로그램입니다. 

따라서 미래의 지갑이 이해해야 하는 것은 더 이상 트랜잭션이 아니라 프로그램입니다. ERC-8211은 바로 이 수준에서 지갑에 더 명확한 손잡이를 제공합니다. 왜냐하면 이러한 실행 의미론을 모두 명시적으로 인코딩 구조에 작성하기 때문입니다. 매개변수가 어디에서 오는지, 어떤 조건을 충족해야 하는지, 언제 계속할지, 언제 롤백할지 등이 백엔드 로직에 숨겨진 블랙박스가 아니라 지갑이 해석, 시뮬레이션 및 표시할 수 있는 객체가 됩니다.

지갑 관점에서 보면, 이 전체 메커니즘은 궁극적으로 동일한 지점을 가리킵니다. 즉, 사용자가 더 이상 완전히 이해하기 어려운 저수준 호출에 서명하는 것이 아니라, 결과 지향적이고 경계가 명확하며 조건을 검증할 수 있는 실행 프로그램에 서명하는 것입니다:

• AI 에이전트는 사용자 의도를 이해하고 경로를 생성하는 책임을 질 수 있습니다.
• 지갑은 이 경로를 더 명확한 방식으로 사용자 검토에 제공하는 책임을 집니다.
• 릴레이는 조건이 성립될 때만 제출하는 책임을 지며, 결과를 변조할 권한은 없습니다.

이것이 바로 비수탁 실행이 에이전트형 DeFi의 전제 조건으로 간주되는 이유입니다. 왜냐하면 에이전트는 참여할 수 있지만, 주권, 제약 조건 및 최종 결제는 여전히 온체인에 남아 있기 때문입니다. 이것이 또한 ERC-8211과 스마트 지갑이 진정으로 맞닿는 지점입니다. 바로 '복잡한 의도를 안전하게 표현하는 것'을 프로토콜 레이어 표준에 작성했다는 점입니다.

주목할 점은, ERC-8211이 ERC-4337, EIP-7702, ERC-7579와 같은 계정 추상화 프레임워크와 완전히 호환된다는 것입니다. 이것은 계정 추상화를 대체