네이티브 계정 추상화 + 양자 위협 대응: EIP-8141은 왜 아직 이더리움 헤고타의 메인 기능이 되지 못했나?

지난주, 이더리움 핵심 개발자 회의에서 EIP-8141을 Hegota 업그레이드에 포함시킬지 공식적으로 논의했는데, 결과는 예상 밖이었습니다. 비탈릭이 직접 지지한 이 제안은 Hegota의 '주요 기능'으로 지정되지 못하고 '포함 고려'(CFI) 상태를 얻었습니다.

이번 주에는 Google 양자 AI 팀이 최신 백서를 발표하며, 주어진 하드웨어 가정 하에서 ECDLP-256을 해독하는 데 필요한 물리적 양자 비트 추정치가 기존보다 20배나 크게 감소했다고 밝혔습니다. 이는 양자 공격이 임박했다는 의미는 아니지만, 만약 계정 시스템이 향후 검증 로직을 유연하게 교체할 수 없다면, 오늘날 지갑 경험에 대한 많은 논의가 결국 보안 문제로 발전할 수 있음을 우리에게 상기시켜 줍니다.

프로토콜 추진의 현실적 관점에서 보면, EIP-8141은 여전히 너무 무겁습니다. 특히 클라이언트 구현, 트랜잭션 풀 보안 및 검증 복잡성 측면에서 아직 충분히 견고한 합의가 형성되지 않았습니다.

하지만 현재 이 시점에서, EIP-8141이 논의되고 심도 있게 검토할 가치가 있는 부분은 정말 점점 더 많아지는 것 같습니다.

1. EIP-8141은 도대체 무엇을 해결하려는 걸까?

EIP-8141은 비탈릭 부테린(Vitalik Buterin)과 팀베이코(timbeiko) 등 핵심 기여자들이 추진하며, 공식 명칭은 Frame Transactions(프레임 트랜잭션)입니다.

이해하기 쉽게 한 마디로 요약하자면, 이 제안은 단순히 특정 지갑 기능을 추가하려는 것이 아니라, 프로토콜 레벨에서 어떤 계정도 단일 ECDSA 서명 경로에 얽매이지 않고 더 유연한 검증 및 실행 로직을 가질 수 있도록 하려는 것입니다. 

이는 또한 멀티시그, 가스 스폰서십, 키 순환, 소셜 복구, 심지어 미래의 양자 내성 서명 방식을 통합하는 것도 더 이상 지갑 외부에 부착된 추가 기능이 아니라, 이더리움 계정 시스템 내의 '네이티브 멤버'가 될 기회를 가질 수 있음을 의미합니다.

표면적으로만 보면, EIP-8141이 논의하는 것은 매우 구체적인 기능 세트처럼 보입니다: 스테이블코인으로 가스 지불, 다단계 작업을 단일 트랜잭션으로 결합, 더 유연한 서명 방식 지원, 심지어 미래의 양자 내성 서명을 위한 공간 확보. 수년간 ERC-4337부터 EIP-7702까지 지갑 경험을 둘러싼 많은 개선 사항들은 본질적으로 계정이 더 이상 단순한 개인키가 아니라 사용자 정의 규칙을 가진 진입점이 되도록 만드는 데 있었습니다.

문제는 이러한 개선 사항들이 지갑을 점점 더 스마트 계정처럼 만들었지만, 이더리움의 가장 기본적인 기본 계정 모델을 진정으로 건드리지는 못했다는 점입니다.

알려진 바와 같이, 기존 시스템에서 이더리움 계정은 크게 두 가지 유형으로 나뉩니다. 하나는 외부 소유 계정(EOA)으로, 가장 친숙한 형태이며 개인키로 제어되며 트랜잭션을 능동적으로 시작할 수 있지만 프로그래밍 가능성이 부족합니다. 다른 하나는 계약 계정, 즉 스마트 계약 자체로, 복잡한 로직을 실행할 수 있지만 스스로 트랜잭션을 시작할 수는 없습니다.

이는 트랜잭션 시작 능력이 단일 개인키 서명과 오랫동안 묶여 있게 만듭니다. 이 전제가 변하지 않는 한, 오늘날 사용자들이 당연히 가져야 한다고 생각하는 많은 능력들, 예를 들어 서명 규칙을 유연하게 변경하거나, 다른 사람이 가스를 대신 지불하게 하거나, 개인키를 분실한 후 계정 통제권을 복구하거나, 미래에 새로운 암호 체계로 원활하게 마이그레이션하는 것 등은 진정으로 계정의 기본 능력이 되기 어렵습니다.

만약 imToken이나 다른 Web3 지갑을 사용해 본 적이 있다면, 아마도 이러한 문제점들을 경험해 봤을 것입니다. 예를 들어, 지갑에 USDC는 많지만 ETH가 없으면 트랜잭션을 보낼 수 없다는 점(가스는 ETH로만 지불 가능), 시드 구문을 잃어버리면 돈을 완전히 잃어버리고 복구할 수 없다는 점, '승인 + 교환' 작업을 두 번 서명하고 두 번 확인해야 한다는 점 등입니다.

이러한 문제들은 지갑 제품이 '충분히 좋지 않아서'가 아니라, 이더리움 계정 모델 자체의 설계 결과입니다.

이 관점에서 보면, 지난 2년간의 진화는 사실 매우 명확합니다. ERC-4337은 프로토콜을 수정하지 않고도 계정 추상화를 먼저 애플리케이션 레이어에서 실행시켰고, EIP-7702는 EOA가 완전히 확장될 수 없는 것이 아니며, 적어도 스마트 계정에 가까운 능력의 일부를 일시적으로 얻을 수 있음을 추가로 증명했습니다.

즉, 이더리움은 계정 추상화를 원하지 않는 것이 아니라, 더 온건하고 보수적인 방식으로 점진적으로 이 목표에 접근해 왔습니다. 그리고 EIP-8141의 등장은 이 경로가 새로운 국면에 도달했음을 의미합니다. 이 제안은 더 이상 기존 시스템 주변에 스마트 계정 능력을 한 겹 더 쌓는 데 만족하지 않고, 계정 추상화를 트랜잭션 모델 자체에 직접 내장시켜, 계정이 프로토콜 레벨부터 프로그래밍 가능한 검증 및 실행 로직을 갖도록 하려고 합니다.

이것이 바로 EIP-8141이 오늘날 다시 뜨거운 논의가 되는 이유입니다. 한편으로는 상위 레이어 지갑 경험이 이미 네이티브 계정 추상화에 점점 더 가까워지고 있어 프로토콜 레벨이 조만간 따라잡아야 하고, 다른 한편으로는 양자 컴퓨팅이 가져오는 장기적 압력이 '계정이 서명 방식을 유연하게 변경할 수 있는지'라는 먼 미래의 기술적 논의를 반드시 진지하게 고려해야 하는 현실 문제로 앞당기고 있기 때문입니다.

2. EIP-8141은 어떻게 작동할까?

결국, EIP-8141은 완전히 새로운 트랜잭션 유형인 프레임 트랜잭션(Frame Transaction, 트랜잭션 유형 번호 0x06)을 도입합니다.

기존 이더리움 트랜잭션의 기본 로직이 하나의 트랜잭션이 하나의 호출에 대응한다면, EIP-8141이 하려는 것은 하나의 트랜잭션을 규칙에 따라 순차적으로 실행할 수 있는 '프레임' 세트로 분해하여, 원래 함께 묶여 있던 검증, 지불, 실행 세 가지 작업을 분리 처리하는 것입니다.

각 '프레임'에는 세 가지 실행 모드가 있습니다:

• VERIFY(검증 프레임): 트랜잭션이 합법적인지 검증하며, 계정이 정의한 검증 로직을 실행합니다. 통과하면 새로 도입된 APPROVE 오피코드를 호출하여 실행을 승인하고 가스 상한을 지정합니다.
• SENDER(송신 프레임): 실제 작업(예: 자산 전송, 계약 호출 등)을 실행합니다. 호출자 주소는 트랜잭션 발신자 본인입니다.
• DEFAULT(진입 프레임): 시스템 진입 주소를 호출자로 사용하며, 계약 배포, 페이마스터(Paymaster) 검증 등 시나리오에 사용됩니다.

이 메커니즘의 의의는 트랜잭션이 더 복잡해질 수 있다는 것이 아니라, '검증, 지불, 실행'이라는 세 가지 작업을 계정 동작에서 처음으로 분리하여 프로토콜이 네이티브하게 스케줄링하도록 한다는 점입니다.

과거에는 누가 트랜잭션을 검증하고, 누가 가스를 지불하며, 누가 실제 작업을 실행하는지가 기본적으로 동일한 계정 동작에 묶여 있었지만, EIP-8141 설계 하에서는 이 작업들이 서로 다른 프레임으로 분리되어 프로토콜이 명확한 순서에 따라 순차적으로 실행할 수 있습니다. 바로 이 때문에 계정은 더 이상 단일 개인키에 의존해 '전체 서명'할 필요가 없으며, 프로그래밍 가능한 실행 주체에 더 가까운 형태를 갖추기 시작합니다.

구체적인 예를 들어, USDC로 가스를 지불하여 스왑(Swap)을 완료하려 한다고 가정해 보겠습니다. EIP-8141 프레임워크 하에서, 이 작업은 이론적으로 완전한 프레임 흐름으로 구성될 수 있습니다: 먼저 계정이 서명 및 실행 권한을 검증하고, 그 다음 지불자 또는 페이마스터가 비용을 부담할 조건을 스스로 검증한 후, 해당 자산으로 비용을 지불하고, 마지막으로 실제 스왑 작업을 실행합니다.

이렇게 하면 가스 지불과 주요 트랜잭션이 동일한 원자적(atomic) 흐름에 포함될 수 있어, 모두 성공하거나 모두 롤백됩니다.

사용자에게 가장 직관적인 변화는, 이전에 반드시 두세 단계로 나누어야 했고 중간에 실패 위험이 있었던 많은 작업들이 미래에는 하나의 완전한 동작처럼 느껴질 수 있다는 점입니다. 따라서 이러한 원자성은 EIP-8141이 사용자 경험의 파편화 문제를 해결하려는 핵심 중 하나입니다.

그렇다면 이것이 지갑 사용자에게 무엇을 의미할까요? 결과적으로 가장 직관적인 변화는 적어도 네 가지 수준이 있습니다:

• 가스 지불의 추상화: 지갑에 스테이블코인이 있다고 해서 더 이상 작업을 위해 추가로 약간의 ETH를 준비해야 할 필요가 없습니다. 미래에는 DApp, 페이마스터 또는 다른 스폰서가 가스를 대신 지불하는 것이 더 네이티브해질 것입니다.
• 다단계 작업의 병합: '승인 + 스왑', '승인 + 스테이킹'과 같이 현재 종종 여러 번 서명해야 하는 프로세스가 하나의 더 완전한 작업으로 패키징될 기회를 얻습니다.
• 계정 보안 규칙의 개방: 멀티시그, 소셜 복구, 일일 한도, 타임락, 키 순환 등은 더 이상 특정 지갑 제품이 추가로 제공하는 고급 기능이 아니라, 더 네이티브한 계정 로직 위에 구축될 기회를 갖기 시작합니다.
• 서명 방식이 더 이상 ECDSA 단일 경로에 고정될 필요 없음: 이는 계정이 미래에 다른 암호 체계, 포스트 퀀텀(양자 후) 서명 방식을 포함하여 마이그레이션할 수 있는 프로토콜 레벨의 가능성을 처음으로 제공합니다.

3. 왜 Hegotá의 주인공이 되지 못했을까?

간과하기 쉽지만 지갑 사용자에게 매우 중요한 점은: EIP-8141이 최종적으로 구현되더라도 기존 계정 시스템이 전면적으로 뒤집히지는 않을 것이라는 점입니다.

현재 imToken 등 기존 Web3 지갑을 사용하고 있더라도 마이그레이션이 필요하지 않습니다. 이 제안은 하위 호환성을 가지며, 기존 EOA 주소를 계속 사용할 수 있고, 적절한 시기에 계정의 검증 로직을 '업그레이드'하기만 선택하면 됩니다.

하지만 반대로 보면, 바로 이 제안이 충분히 깊이 변경을 가하기 때문에 최근 논의에서 바로 Hegotá의 주인공 기능이 되지 못한 것입니다. 그러나 2026년의 EIP 챔피언 프로세스에 따르면, CFI(포함 고려) 상태는 부정된 것이 아니라 진지하게 고려되는 단계에 들어갔지만, 최종적으로 확정되어 출시될 때가 아직 되지 않았음을 의미합니다.

다시 말해, 핵심 개발자들은 EIP-8141의 방향을 인정하지 않는 것이 아니라, 그 가치를 인정하면서도 현재로서는 여전히 너무 '무겁다'고 판단하고 있습니다.

결국 네이티브 계정 추상화는 ERC-4337처럼 소수의 지갑, 인프라 및 애플리케이션이 점진적으로 추진할 수 있는 것이 아닙니다. 일단 프로토콜 레벨에 들어가면 모든 실행 레이어 클라이언트가 진지하게 구현, 테스트 및 조정해야 하며, 이는 자연스럽게 추진 장벽을 높이고, 핵심 개발자들이 포크 계획을 세울 때 더 안정적인 쪽으로 기울게 만듭니다.

그렇다면 앞으로 무슨 일이 일어날까요? 두 가지 측면으로 나누어 볼 수 있습니다:

• EIP-8141이 CFI 상태에 있다는 것은 계속 평가되고 있음을 의미하며, 제안 작성자는 트랜잭션 풀 보안, 검증 규칙 및 클라이언트 구현과 관련된 핵심 세부 사항을 계속 보완할 것이고, 향후 ACD 회의에서도 더 나아갈 조건을 갖추었는지 재검토할 것입니다.
• 이러한 불확실성이 지속적으로 줄어들면, 향후 업그레이드에서 더 실질적인 포함 단계로 진입할 기회를 얻을 수 있습니다. 그렇지 못하면 더 늦은 업그레이드 주기로 연기될 수도 있습니다.

사실대로 말하자면, EIP-8141도 유일한 네이티브 계정 추상화 제안이 아니며, 그 자체로 어떤 기성 포스트 퀀텀 서명 솔루션도 아니어서 양자 컴퓨팅 문제를 직접 해결할 수는 없습니다. 그러나 그 중요성은 계정이 ECDSA 단일 경로에서 벗어날 수 있는 프로토콜 레벨의 출구를 처음으로 제공했다는 점에 있습니다. 

이 관점에서 볼 때, EIP-8141의 진정한 가치는 그것이 유일한 정답인지 여부에 있는 것이 아니라, '네이티브 계정 추상화의 최종 형태는 도대체 어떻게 생겨야 하는가'라는 질문을 처음으로 매우 완전하게 이더리움 프로토콜 논의 테이블 위에 올려놓았다는 점에 있습니다.

이것은 유일한 솔루션이 아니지만, 현재 가장 야심차고 '완전한 네이티브 AA' 상상력의 상한에 가장 가까운 솔루션 중 하나입니다.

EIP-