AI Agent에서 온체인 권한 경계까지: ERC-8004가 무엇을 바꾸고 있는가?

DeFi, 계정 추상화, AI 에이전트 등의 애플리케이션 발전에 따라 온체인 승인은 일회성 서명 확인에서 점차 장기적 효력을 발휘하고 반복적으로 사용될 수 있는 실행 권한으로 진화하고 있습니다. 동시에 새로운 변화도 발생하고 있습니다: AI 에이전트는 이미 자동으로 서비스를 요청하고 자동으로 결제를 완료하는 능력을 갖추기 시작했으며, 예를 들어 x402 프로토콜은 HTTP 402 상태 코드를 통해 에이전트가 사람의 개입 없이도 스테이블코인으로 자원과 서비스에 대해 즉시 비용을 지불할 수 있게 합니다. 이는 온체인 행위가 더 이상 고립된 거래가 아니라 지속적으로 실행되는 자동화된 협업 과정이 되게 합니다.

이러한 배경에서 승인 문제는 더욱 확대되었습니다. 현재 Web3 시스템의 승인 방식은 여전히 경계가 모호하고 표현이 거칠며, 주로 자산을 사용할 수 있는지 여부만 해결할 뿐, 구체적으로 무엇을 허용하고 어느 정도까지 허용하는지에 대해서는 답하기 어렵습니다. ERC-8004은 바로 이러한 배경에서 제안되었습니다. 이는 새로운 자산을 정의하지도 않고, 거래나 결제가 어떻게 실행되는지를 변경하지도 않으며, 온체인 행위에 대해 시스템이 이해하고 검증할 수 있는 권한 모델을 구축하려 시도하여, 승인 자체를 설명 가능하고 제약 가능하며 관리 가능한 객체로 만듭니다.

더 큰 시스템 관점에서 보면, ERC-8004은 계정 추상화 및 x402와 같은 자동화 결제 프로토콜과 경쟁 관계가 아니라, 서로 다른 계층에서 분업 협업하는 관계입니다: x402는 행위 발생 후의 가치 교환 문제를 해결하는 반면, ERC-8004은 행위 발생 전에 누가 행동할 수 있는지, 권한이 범위를 넘어서는지 여부에 주목합니다. DeFi, AI 에이전트, 기업 및 RWA와 같은 시나리오에서 이러한 권한 선행, 결제 후행 구조는 승인이 자산 수준에서 행위 수준으로 나아가 더 복잡하고 장기적인 자동화 협업에 통제 가능한 기반을 제공할 것으로 기대됩니다. 학습 비용, 지갑 지원 및 사용자 경험 측면에서 여전히 현실적인 도전에 직면해 있지만, ERC-8004은 단기적인 내러티브 도구가 아니라 Web3가 복잡한 시스템 운영을 수용할 수 있는지에 관한 기반 표준입니다.

1. ERC-8004 제안 동기

온체인 인프라가 지속적으로 진화함에 따라 자산 온체인 및 거래 실행과 관련된 능력은 계속해서 추상화되고 강화되고 있습니다. ERC-20, NFT부터 멀티시그 지갑과 계정 추상화(ERC-4337)에 이르기까지, 사용자가 온체인 활동에 참여하는 진입 장벽은 계속 낮아지고, 계정 자체도 점점 더 지능화되고 있습니다.

그러나 이 과정에서 한 가지 근본적인 문제는 체계적으로 해결되지 않았습니다: 승인 메커니즘 자체는 거의 실질적인 진화를 이루지 못했습니다. 초기 Web3에서 승인은 일회성 개인 키 서명을 의미했습니다. 사용자는 서명을 통해 '동의합니다'를 표현했으며, 송금, 컨트랙트 호출 또는 approve 작업이든, 승인은 일회성 확인 행위로 간주되었고, 위험 경계는 전적으로 사용자가 스스로 부담했습니다.

그러나 오늘날의 온체인 환경은 변화했습니다. DeFi 시나리오에서 approve는 종종 장기적으로 유효합니다; 자동화 전략 및 세션 키 시스템 하에서 승인은 반복적으로 사용됩니다; AI 에이전트나 봇이 거래를 실행하는 모드에서는 사용자가 더 이상 각 작업에 직접 참여하지 않기도 합니다. 승인은 일회성 확인에서 지속적으로 존재하는 실행 능력으로 진화하고 있으며, 일정 기간 동안 어떤 일을 할 수 있는 권한을 넘겨주는 것과 더 유사해졌습니다.

문제는 현재 Web3의 인프라가 이러한 장기 승인 상태에 대해 명확하고 통일된 제약 방식을 거의 제공하지 않는다는 점입니다. 권한 범위 모호, 승인 철회 어려움, 위험 예측 불가능은 수많은 보안 사건의 원인이 되고 있습니다. 동시에 계정 추상화는 이 모순을 더욱 확대시켰습니다: 계정이 거래를 자동으로 실행하고 제3자가 가스비를 대납할 수 있을 때, 계정이 실제로 무엇을 할 수 있고 무엇을 할 수 없는지는 오히려 더 불분명해졌습니다.

바로 이러한 배경에서 ERC-8004가 제안되었습니다. 이는 Web3에서 오랫동안 누락된 한 부분을 보완하려 시도합니다: 승인 자체에 대해 명확하고, 제약 가능하며, 시스템이 이해할 수 있는 권한 모델을 구축하는 것입니다.

2. ERC-8004의 핵심 내용

ERC-8004의 접근점은 자산 형태나 거래 실행 방식에 있지 않고, 승인이 별도로 설명되고, 독립적으로 검증되며, 시스템 수준에서 지속적으로 관리될 수 있는지에 있습니다.

2.1 ERC-8004은 무엇을 정의하나요?

Ethereum Improvement Proposals(EIP) 공식 웹사이트 정의에 따르면: ERC-8004은 이더리움에서 신뢰할 수 있는 자율 에이전트를 발견, 선택 및 상호 작용하기 위한 표준 프로토콜입니다. 이는 온체인 등록, 평판 및 검증 메커니즘을 통해 사전 신뢰 없이도 분산화된 상호 작용이 가능한 에이전트 인프라를 구축합니다.

여기서 자율 에이전트는 AI 에이전트에 국한되지 않으며, 권한을 부여받고 독립적으로 행동을 실행할 수 있는 모든 주체, 예를 들어 컨트랙트, 자동화 스크립트, 멀티시그 또는 서비스 프로세스를 의미합니다. ERC-8004은 실행 주체가 명확한 승인과 권한 경계를 가진 능력을 갖추고 있는지에 주목하며, AI 에이전트는 그중 전형적인 응용 사례일 뿐입니다.

보다 일반적인 관점에서 보면, ERC-8004은 새로운 자산 표준이나 계정 유형이 아니라, 특정 주체가 어떤 조건에서 어떤 행동을 실행할 수 있는지를 설명하고 작업 전에 검증하는 데 사용되는 온체인 권한 표현 및 검증 프레임워크입니다. 따라서 ERC-8004은 '돈이 무엇인가'나 '거래가 어떻게 실행되는가'가 아니라 '어떤 행동이 허용되는가'에 주목합니다. 이는 새로운 자산을 생성하거나 기존 자산 속성을 변경하지 않으며, 단지 자산과 계정 위에 명확하게 검증 가능한 권한 규칙 계층을 추가할 뿐입니다.

또한 ERC-8004은 계정 추상화(ERC-4337)의 대체재가 아닙니다. 계정 추상화는 거래가 어떻게 실행되는지에 주목하는 반면, ERC-8004은 거래 발생 전의 권한 판단을 해결합니다. 계정 추상화가 계정을 더 유연하게 만든다면, ERC-8004은 이러한 유연성에 명확한 경계를 설정합니다.

ERC-8004의 핵심은 승인을 서명에 암묵적으로 포함된 동작에서 명확하게 설명 가능하고, 독립적으로 검증 가능하며, 지속적으로 관리 가능한 권한 객체로 전환하는 데 있습니다.

2.2 ERC-8004의 핵심 메커니즘 프레임워크

ERC-8004의 핵심 메커니즘을 이해하려면 먼저 복잡한 기술 구현을 제쳐두고 이를 '온체인 권한 설명서'로 이해할 수 있습니다. 기존의 승인 로직에서 사용자는 종종 단순히 "내 자산을 조작하는 데 동의합니다."라는 포괄적인 결정을 내립니다. 구체적으로 무엇을 할 수 있고, 얼마나 할 수 있으며, 얼마나 오래 할 수 있는지는 시스템이 추가로 구분하지 않습니다. 반면 ERC-8004 프레임워크 하에서 한 번의 승인은 더 이상 모호한 동의가 아니라, 명확하게 설명 가능하고 시스템에 의해 강제 실행되는 일련의 규칙으로 분해됩니다. 이 '권한 설명서'는 일반적으로 다음 다섯 가지 유형의 핵심 정보를 포함합니다.

승인 주체(Who): 누가 실행할 수 있도록 허용되었나요?

먼저 명확히 해야 할 것은 누가 실행 권한을 부여받았는가입니다. ERC-8004에서 권한을 부여받은 객체는 더 이상 고정된 지갑 주소에 국한되지 않으며, 컨트랙트, 자동화 에이전트, 심지어 단기 작업에 사용되는 세션 키일 수도 있습니다. 이는 승인이 더 많은 복잡한 시나리오에 적응할 수 있게 합니다. 예를 들어: 특정 전략 컨트랙트가 제한된 범위 내에서 작업을 실행하도록 허용하거나, 에이전트가 반복적인 서명 없이도 특정 작업을 완료하도록 허용하는 것입니다. 중요한 점은 권한이 항상 '어떤 명확한 주체'에게 부여되며, 모호하게 넘겨지는 것이 아니라는 점입니다.

실행 가능한 행동(What): 어떤 작업을 허용하나요?

둘째, 어떤 행동을 실행할 수 있도록 허용되었는가입니다. 기존 승인은 종종 전부 아니면 전무(all-or-nothing)였으며, 일단 승인되면 기본적으로 컨트랙트가 권한 범위 내에서 자유롭게 호출할 수 있도록 허용했습니다. 반면 ERC-8004 설계에서 승인은 구체적인 행동 유형, 예를 들어 swap, transfer만 허용하거나 특정 유형의 함수 호출만 허용하는 등 정확하게 지정될 수 있으며, 기본적으로 모든 가능한 작업을 개방하지 않습니다. ERC-8004은 사용할 수 있는지 여부가 아니라 어디까지 사용할 수 있는지에 답합니다.

제약 조건(Under what conditions): 어떤 조건에서만 실행할 수 있나요?

이는 ERC-8004이 기존 승인과 구별되는 핵심 부분입니다. 권한 설명서에서 승인은 일반적으로 명시적인 제한 조건을 동반합니다. 예를 들어: 단일 또는 누적 금액 상한; 실행 빈도 또는 횟수 제한; 특정 프로토콜, 풀 또는 컨트랙트 주소에만 적용 가능 등입니다. 이러한 조건은 사후 모니터링 규칙이 아니라, 실행 전에 반드시 충족되어야 하는 선결 조건입니다. 조건이 성립되지 않으면 작업 자체가 실행될 수 없습니다.

발효 및 실효 규칙(When): 권한이 언제 성립되고 언제 종료되나요?

ERC-8004은 또한 명확한 시간 및 생명주기 개념을 도입했습니다. 승인은 다음과 같이 설정될 수 있습니다: (a) 특정 시간대 내에서만 유효; (b) 한 번 사용 후 자동 실효; (c) 언제든지 철회 가능. 이는 승인이 더 이상 주고 나면 되돌릴 수 없는 장기적인 부담이 아니라, 정밀하게 관리 가능한 임시 능력이 되게 합니다.

검증 방식(How enforced): 규칙이 어떻게 실제로 실행되나요?

마지막으로, 가장 간과되기 쉬운 점: 이러한 규칙이 어떻게 실행되는가입니다. ERC-8004의 핵심 사상은 작업 발생 전에 권한 검증을 수행하는 것입니다. 특정 행동이 사전 정의된 권한 규칙에 부합하지 않으면 시스템은 직접 실행을 거부하며, 문제 발생 후 책임을 추궁하지 않습니다. 이는 바로 ERC-8004이 기존 위험 관리 로직과 근본적으로 다른 점입니다.

2.3 ERC-8004이 추가하는 능력 유형: 이전에는 왜 할 수 없었나요?

표면적으로 보면 ERC-8004은 단지 승인을 더 세분화하는 것처럼 보이지만, 초기 이더리움 승인 모델은 실제로 복잡한 승인 로직을 표현할 수 없었습니다. 기존 승인은 특정 주소가 작업을 수행할 수 있는지 여부만 확인하며, 일단 승인되면 무엇을 할 수 있고, 얼마나 할 수 있으며, 언제 할 수 있는지는 시스템이 인식할 수 없었습니다.

ERC-8004의 핵심 돌파구는 승인을 '신원 판단'에서 '행위 판단'으로 업그레이드한 데 있습니다. 시스템은 사용자가 설정한 권한 경계에 한 번의 작업이 부합하는지 여부를 판단하기 시작하며, 단지 누가 시작했는지 확인하는 데 그치지 않습니다. 이는 승인에 금액, 빈도, 범위 및 유효 기간과 같은 조건이 자연스럽게 포함되게 하여, 사용자의 사후 철회나 인공 모니터링에 의존할 필요가 없게 합니다.

승인 로직이 구조화되면, 이는 처음으로 조합 가능하고 재사용 가능한 능력을 갖추게 됩니다. 다단계, 크로스 프로토콜 작업은 승인 단계에서 명확히 제한될 수 있으며, 실행 시 임시 판단에 맡겨지지 않습니다. 바로 이 때문에 ERC-8004은 진정으로 에이전트 시나리오에 공간을 열어줍니다. 자동화 프로그램은 더 이상 '무제한 승인'이 필요하지 않으며, 명확하고 검증 가능한 행동 범위 내로 제한되어, 경계를 넘어서면 실행이 거부됩니다.

ERC-8004이 추가하는 것은 단순한 '더 안전한 승인'이 아니라, 승인 로직이 시스템에 의해 이해되고 실행될 수 있게 하는 것이며, 이는 기존 승인 메커니즘과의 본질적인 차이점입니다.

3. ERC-8004의 잠재적 응용 방향

ERC-8004은 특정 제품을 위해 설계된 표준이 아니라, 승인 능력에 대한 보편적인 언어와 더 유사합니다. 따라서 그 응용 가치는 단일 시나리오의 폭발적 성장에 나타나는 것이 아니라, 승인이 복잡해진 후 여러 시스템이 동일한 유형의 능력에 대한 공동 수요에 나타납니다.

DeFi: '자산 수준 승인'에서 '행위 수준 승인'으로

현재 DeFi 시스템에서 가장 일반적인 승인 방식은 여전히 '일회성 승인, 무제한 한도'입니다. 예를 들어 사용자가 한 번의 swap, 대출 또는 스테이킹을 위해 먼저