Account Abstraction(계정 추상화)이란?
Account Abstraction(계정 추상화)은 블록체인 계정의 거래 승인과 실행 방식을 더 유연하게 만들어 지갑에 다양한 기능을 구현할 수 있도록 하는 개념과 기술적 접근을 말합니다.
기존의 일반적인 개인키 기반 계정에서는 개인키로 만든 서명이 거래 권한의 핵심 역할을 합니다. Account Abstraction을 활용하면 계정이 어떤 조건에서 거래를 승인할지 더 다양하게 설계할 수 있습니다.
예를 들어 여러 인증 방법, 계정 복구, 여러 작업의 묶음 처리, 특정 조건의 가스비 지원 등 일반 사용자가 지갑을 더 편리하게 이용할 수 있는 기능과 연결될 수 있습니다.
하지만 Account Abstraction 자체가 특정 지갑 하나나 단일 기능을 의미하는 것은 아닙니다. 블록체인과 구현 방식에 따라 구조와 지원 기능이 달라질 수 있습니다.
가족 웹툰으로 먼저 알아보기
아빠는 계정을 ‘추상화한다’는 말이 너무 어렵게 느껴집니다. 큰딸의 설명을 들으며 Account Abstraction이 복잡한 블록체인 계정의 승인과 거래 처리 방식을 더 유연하게 만드는 개념이라는 점을 알아보고, 엄마와 나나는 편리한 기능이 추가되더라도 실제 권한과 거래 내용을 확인해야 하는 이유를 함께 살펴봅니다.
웹툰 핵심 설명
46-1. Account Abstraction이 뭐야?
계정 추상화는 블록체인 계정의 거래 승인과 실행 방식을 더 유연하게 구성할 수 있도록 하는 개념과 기술적 접근입니다.
46-2. 왜 계정을 추상화한다는 거야?
초보자는 복잡한 기술 용어보다 개인키 하나에만 의존하던 계정 규칙을 더 다양한 방식으로 설계할 수 있게 만든다고 이해하면 쉽습니다.
46-3. 거래 승인 방법을 더 다양하게 만들 수 있어.
구현 방식에 따라 여러 인증 조건이나 복구 규칙 등을 계정 기능에 적용할 수 있습니다.
46-4. 여러 작업을 한 번에 처리할 수도 있어.
여러 블록체인 작업을 하나의 사용자 흐름으로 묶어 기존보다 단순하게 처리하도록 설계할 수 있습니다.
46-5. 가스비 사용 경험도 달라질 수 있어.
특정 구조에서는 다른 주체가 네트워크 비용을 대신 부담하는 등 기존과 다른 가스비 처리 경험을 구현할 수 있습니다.
46-6. 편리해도 실제 권한과 거래는 확인해야 해.
Account Abstraction이 사용 과정을 간단하게 만들어도 실제로 어떤 거래와 권한이 실행되는지는 이용자가 확인해야 합니다.
45화 Smart Account와 Account Abstraction은 어떻게 연결될까?
Smart Account는 스마트 컨트랙트 등의 기능을 이용해 거래 승인, 복구와 권한 관리 규칙을 유연하게 구성할 수 있는 계정을 말합니다.
Account Abstraction은 이러한 프로그래밍 가능한 계정과 사용자 경험을 구현하는 데 연결되는 더 넓은 개념과 기술적 접근으로 이해할 수 있습니다.
따라서 초보자는 Smart Account는 실제 계정에 가까운 개념, Account Abstraction은 계정의 작동 방식을 더 유연하게 만드는 접근으로 먼저 구분하면 이해하기 쉽습니다.
왜 기존 블록체인 계정은 불편할 수 있을까?
기존의 개인키 기반 지갑에서는 이용자가 개인키와 복구 정보를 안전하게 관리해야 합니다.
또한 블록체인 작업마다 트랜잭션 서명을 확인해야 하고, 네트워크에 따라 가스비를 지급하기 위한 기본 자산도 필요할 수 있습니다.
이러한 과정은 블록체인에 익숙하지 않은 이용자에게 복잡하게 느껴질 수 있습니다.
Account Abstraction은 무엇을 바꾸려는 걸까?
핵심은 블록체인 계정의 인증과 거래 실행 규칙을 더 유연하게 만드는 것입니다.
기존처럼 하나의 고정된 계정 동작 방식에만 의존하지 않고 계정이 어떤 요청을 유효한 것으로 인정할지 다양한 규칙을 적용할 수 있도록 설계할 수 있습니다.
이를 통해 보안과 복구, 거래 실행과 가스비 처리 등에서 새로운 사용자 경험을 구현할 수 있습니다.
개인키가 없어지는 기술일까?
그렇게 이해해서는 안 됩니다.
Account Abstraction을 사용하더라도 계정을 인증하고 거래를 승인하기 위한 암호학적 권한은 필요합니다.
다만 하나의 개인키 서명만을 고정된 계정 규칙으로 사용하는 대신 여러 키나 인증 방법, 스마트 컨트랙트 규칙 등을 활용할 수 있도록 설계할 수 있습니다.
Account Abstraction과 Seedless Wallet은 같은 걸까?
같은 개념은 아닙니다.
Seedless Wallet은 이용자가 하나의 전통적인 복구 문구를 직접 보관하는 방식에 의존하지 않는 키 관리와 복구 구조에 초점을 둡니다.
Account Abstraction은 계정이 거래를 승인하고 실행하는 방식을 더 유연하게 만들기 위한 더 넓은 접근입니다.
두 기술이 하나의 지갑에서 함께 사용될 수는 있지만 같은 의미로 사용해서는 안 됩니다.
계정 복구도 더 유연하게 만들 수 있을까?
Account Abstraction을 활용한 계정에서는 구현에 따라 여러 장치나 지정된 복구 주체, 추가 인증 조건 등을 이용한 복구 기능을 설계할 수 있습니다.
예를 들어 하나의 키를 잃어버렸다고 즉시 모든 접근 권한을 잃는 대신 미리 정한 조건을 충족하면 계정의 인증 권한을 변경하도록 구성할 수 있습니다.
하지만 복구 기능을 제공한다는 사실만으로 안전성이 보장되는 것은 아니며 실제 복구 권한과 조건을 확인해야 합니다.
여러 작업을 하나로 묶는다는 것은 무슨 뜻일까?
DApp을 이용하다 보면 토큰 승인과 실제 스마트 컨트랙트 실행 등 여러 단계가 필요할 수 있습니다.
Account Abstraction과 Smart Account 구조에서는 여러 작업을 하나의 사용자 요청으로 묶어 더 간단한 흐름으로 처리하도록 설계할 수 있습니다.
하지만 화면에서 한 번의 작업처럼 보인다고 실제 실행되는 권한까지 하나뿐이라는 뜻은 아닙니다.
토큰 승인 과정도 달라질 수 있을까?
사용자 경험 측면에서는 여러 작업을 묶어 토큰 승인과 이후 작업을 더 간단하게 보여줄 수 있습니다.
하지만 실제로 스마트 컨트랙트에 토큰 사용 권한이 부여되는 구조라면 어떤 대상에 어느 범위의 권한이 설정되는지 확인해야 합니다.
특히 무제한 토큰 승인처럼 큰 권한이 설정되는 경우에는 편리한 화면과 별개로 실제 승인 내용을 살펴봐야 합니다.
가스비를 다른 사람이 대신 낼 수도 있을까?
Account Abstraction과 연결된 일부 구조에서는 서비스나 별도의 주체가 특정 조건에서 이용자의 네트워크 비용을 대신 부담하는 기능을 구현할 수 있습니다.
이용자는 네트워크 기본 자산을 직접 준비하지 않고도 특정 거래를 실행할 수 있는 사용자 경험을 제공받을 수 있습니다.
하지만 비용 자체가 사라지는 것은 아니므로 누가 가스비를 부담하며 어떤 조건과 제한이 있는지 확인해야 합니다.
Paymaster는 어떤 역할을 할까?
일부 계정 추상화 구조에서는 Paymaster가 특정 조건에 따라 거래의 가스비를 지원하거나 대신 지불하는 역할을 할 수 있습니다.
서비스가 신규 이용자의 첫 거래 비용을 부담하거나 특정 기능에 한해 가스비를 지원하는 사용자 경험 등을 설계할 수 있습니다.
하지만 Paymaster가 모든 거래의 비용을 항상 대신 내주는 것은 아니며 실제 정책과 조건을 확인해야 합니다.
Account Abstraction과 DApp은 어떻게 연결될까?
DApp은 Account Abstraction을 활용한 지갑과 연동해 기존보다 간단한 로그인·거래·복구 경험을 제공할 수 있습니다.
사용자가 복잡한 블록체인 절차를 모두 직접 처리하지 않아도 되도록 인터페이스를 구성할 수 있기 때문입니다.
하지만 이용 과정이 단순해져도 지갑 연결과 실제 거래 권한을 확인하는 기본 원칙은 중요합니다.
Account Abstraction의 주요 장점
- 유연한 인증: 다양한 거래 승인 조건을 구현할 수 있습니다.
- 복구 기능: 계정 접근 권한을 복구하는 여러 방식을 설계할 수 있습니다.
- 거래 단순화: 여러 작업을 하나의 사용자 흐름으로 묶을 수 있습니다.
- 가스비 경험 개선: 다른 주체가 네트워크 비용을 지원하는 구조를 구현할 수 있습니다.
- 권한 세분화: 특정 기능이나 기간에 제한된 권한을 구성할 수 있습니다.
- 사용자 경험: 기존 블록체인 지갑의 복잡한 절차를 줄이는 데 활용될 수 있습니다.
Account Abstraction의 주요 위험
- 스마트 컨트랙트 위험: 계정 로직에 코드 오류나 취약점이 존재할 수 있습니다.
- 권한 설정 오류: 인증이나 복구 권한을 잘못 구성할 수 있습니다.
- 서비스 의존성: 일부 기능이 특정 인프라나 사업자에 의존할 수 있습니다.
- 복잡성: 사용자 화면은 단순해져도 내부 구조는 더 복잡할 수 있습니다.
- 악의적인 서명: 편리한 거래 흐름 속에서 실제 실행 내용을 확인하지 않을 수 있습니다.
- 가스비 조건: 비용 지원이 항상 적용된다고 잘못 이해할 수 있습니다.
Account Abstraction을 이해할 때 확인할 것
- 계정 유형: 어떤 방식의 Smart Account를 사용하는지 확인합니다.
- 인증 방식: 어떤 키와 인증 조건으로 거래를 승인하는지 확인합니다.
- 복구 구조: 키나 기기를 잃었을 때 어떤 방법으로 복구하는지 확인합니다.
- 거래 처리: 여러 작업이 하나로 묶여 실행되는지 확인합니다.
- 가스비: 누가 네트워크 비용을 부담하고 어떤 조건이 적용되는지 확인합니다.
- 권한: 세션 키나 토큰 승인 등에 어떤 사용 범위가 설정되는지 확인합니다.
- 서비스 의존성: 특정 서비스가 중단됐을 때 계정 사용에 어떤 영향이 있는지 확인합니다.
Account Abstraction을 처음 사용할 때 어떤 순서로 확인할까?
Account Abstraction이 적용된 지갑을 처음 사용한다면 화면의 편리함보다 계정 주소 → 인증 방식 → 거래에 포함된 작업 → 가스비 처리 → 남아 있는 권한 → 복구 방법 순서로 확인하는 것이 좋습니다.
일반적인 지갑보다 사용 과정이 간단하게 보일 수 있지만 내부에서는 여러 스마트 컨트랙트 작업이나 권한 처리가 이루어질 수 있습니다.
따라서 버튼을 몇 번 눌렀는지가 아니라 실제로 어떤 거래와 권한이 실행됐는지 이해하는 것이 중요합니다.
EOA와 Smart Account를 함께 사용할 수도 있을까?
구현 방식에 따라 기존 개인키 기반 계정이 Smart Account의 생성이나 관리, 인증 과정에 연결될 수 있습니다.
이 경우 기존 계정과 Smart Account가 서로 다른 주소를 사용할 수도 있습니다.
따라서 자산을 보내거나 DApp과 상호작용하기 전에 현재 어떤 주소가 실제 작업을 수행하고 있는지 확인해야 합니다.
UserOperation은 무엇일까?
일부 Account Abstraction 구조에서는 일반적인 트랜잭션과 구분되는 사용자 작업 요청을 UserOperation이라고 부를 수 있습니다.
이용자가 원하는 작업과 필요한 인증 정보를 포함한 요청이 별도의 처리 과정을 거쳐 최종적으로 블록체인에서 실행될 수 있습니다.
초보자가 세부 데이터 형식을 외울 필요는 없지만 사용자가 만든 요청이 기존 거래와 다른 경로로 처리될 수 있다는 정도로 이해하면 됩니다.
Bundler는 어떤 역할을 할까?
일부 Account Abstraction 구조에서는 Bundler가 여러 UserOperation을 받아 처리하고 블록체인에서 실행될 수 있도록 전달하는 역할을 할 수 있습니다.
이용자 입장에서는 지갑에서 작업을 요청하지만 내부에서는 Bundler 같은 구성 요소가 거래 처리 과정에 참여할 수 있는 것입니다.
따라서 Account Abstraction은 지갑 화면 하나만 바뀌는 것이 아니라 거래가 네트워크로 전달되는 과정 자체에도 새로운 구성 요소가 추가될 수 있는 구조입니다.
Bundler가 거래를 마음대로 바꿀 수 있을까?
구체적인 보안 구조는 구현에 따라 다르지만 이용자가 승인한 작업이 어떤 조건에서 유효한지 계정과 프로토콜의 규칙에 따라 검증될 수 있습니다.
Bundler가 존재한다는 이유만으로 이용자의 모든 계정 권한을 가진다고 단정해서는 안 됩니다.
반대로 특정 인프라에 문제가 생겼을 때 거래 제출이나 사용자 경험에 어떤 영향을 줄 수 있는지는 확인할 필요가 있습니다.
Paymaster가 있으면 가스비용 코인이 없어도 될까?
특정 구조에서는 Paymaster가 조건을 충족하는 UserOperation의 네트워크 비용을 지원할 수 있습니다.
따라서 이용자가 네트워크 기본 자산을 직접 준비하지 않아도 특정 작업을 실행할 수 있는 사용자 경험이 가능할 수 있습니다.
하지만 모든 거래에 적용되는 것은 아니며 지원 한도와 대상 작업, 기간 등의 조건이 있을 수 있습니다.
Paymaster 지원이 끝나면 어떻게 될까?
서비스가 가스비 지원을 중단하거나 해당 거래가 지원 조건을 충족하지 못하면 이용자가 직접 네트워크 비용을 부담해야 할 수 있습니다.
따라서 무료 거래에 익숙해졌더라도 실제 가스비 구조와 필요한 기본 자산을 이해해두는 것이 좋습니다.
가스비 지원은 계정 추상화의 가능한 기능이지 영구적인 무료 거래 보장은 아닙니다.
세션 키를 사용하면 매번 서명하지 않아도 될까?
일부 Smart Account에서는 특정 기간과 작업 범위에 제한된 세션 키를 이용해 반복되는 작업을 간소화할 수 있습니다.
예를 들어 정해진 DApp과 특정 기능에 대해서만 일정 기간 권한을 허용하는 구조를 설계할 수 있습니다.
하지만 세션 키의 권한 범위가 지나치게 넓다면 해당 키가 노출됐을 때 영향을 받을 수 있는 범위도 커질 수 있습니다.
세션 키에서는 무엇을 확인해야 할까?
세션 키를 사용하는 경우 최소한 다음 내용을 확인하는 것이 중요합니다.
- 유효 기간: 언제부터 언제까지 사용할 수 있는지 확인합니다.
- 허용 대상: 어떤 DApp이나 스마트 컨트랙트에서 사용할 수 있는지 확인합니다.
- 허용 작업: 어떤 기능까지 실행할 수 있는지 확인합니다.
- 자산 범위: 특정 자산이나 수량 제한이 있는지 확인합니다.
- 취소 방법: 필요하지 않을 때 권한을 어떻게 제거하는지 확인합니다.
여러 거래를 묶으면 가스비도 무조건 줄어들까?
여러 작업을 배치로 처리한다고 해서 모든 상황에서 네트워크 비용이 반드시 줄어든다고 단정할 수는 없습니다.
실제 비용은 실행되는 스마트 컨트랙트 로직과 네트워크 상태, 거래 구조 등에 따라 달라질 수 있습니다.
배치 기능의 핵심은 이용자의 여러 작업을 단순한 흐름으로 만들 수 있다는 점이며 항상 더 저렴하다는 의미는 아닙니다.
Account Abstraction에서도 잘못된 서명을 할 수 있을까?
그럴 수 있습니다.
사용자 경험이 간단해져도 이용자가 악의적인 요청이나 잘못된 작업을 승인하면 계정의 정상적인 인증 절차를 통해 실행될 가능성이 있습니다.
따라서 트랜잭션 서명에서 배운 것처럼 어떤 사이트가 무엇을 요청하고 있는지 확인하는 원칙은 그대로 중요합니다.
한 번의 승인으로 여러 작업이 실행된다면?
Account Abstraction에서는 여러 작업이 하나의 사용자 요청으로 묶일 수 있기 때문에 확인 화면이 기존보다 간단해질 수 있습니다.
하지만 한 번의 승인 안에 토큰 권한 설정, 자산 이동과 스마트 컨트랙트 실행 등 여러 동작이 포함될 가능성을 고려해야 합니다.
따라서 한 번만 서명한다 = 하나의 단순한 작업만 실행된다고 생각해서는 안 됩니다.
토큰 승인 권한은 그대로 남을 수 있을까?
Account Abstraction이 적용됐더라도 특정 스마트 컨트랙트에 토큰 사용 권한을 부여했다면 해당 권한은 별도로 존재할 수 있습니다.
사용자 화면에서 승인과 실제 작업이 하나로 묶여 보이더라도 온체인에서 어떤 권한이 설정됐는지 확인해야 합니다.
더 이상 필요하지 않은 기존 권한은 토큰 승인 취소(Revoke)와 관련된 상태를 확인할 수 있습니다.
Account Abstraction을 사용하면 복구 문구가 필요 없을까?
반드시 그렇지는 않습니다.
계정의 인증과 복구를 어떤 방식으로 설계했는지에 따라 전통적인 복구 문구를 사용하지 않는 구조도 있을 수 있고 기존 키와 복구 정보를 함께 사용하는 구조도 있을 수 있습니다.
따라서 Account Abstraction이라는 용어만 보고 복구 문구가 무조건 사라진다고 생각해서는 안 됩니다.
기기를 잃어버렸을 때 계정을 복구할 수 있을까?
Smart Account의 규칙에 따라 다른 장치나 Guardian, 추가 인증 수단 등을 이용한 복구 구조를 만들 수 있습니다.
하지만 실제 복구 조건을 충족하지 못하면 계정 접근이 어려워질 수 있으므로 어떤 정보와 참여자가 필요한지 미리 확인해야 합니다.
특히 복구 주체와 권한 변경 조건이 어떻게 설정되어 있는지 이해하는 것이 중요합니다.
서비스 회사가 없어지면 계정도 사라질까?
온체인 Smart Account와 서비스 회사의 앱·서버는 구분해서 이해할 필요가 있습니다.
계정 자체가 블록체인에 존재하더라도 Bundler나 Paymaster, 복구 인터페이스 등 일부 기능이 특정 서비스 인프라에 의존할 수 있습니다.
따라서 서비스가 중단됐을 때 다른 방법으로 거래를 실행하거나 자산을 이동할 수 있는지 확인하는 것이 중요합니다.
Account Abstraction의 호환성도 확인해야 할까?
중요합니다.
모든 블록체인과 모든 지갑이 같은 Account Abstraction 구조를 지원하는 것은 아닙니다.
사용하는 Smart Account를 다른 지갑이나 서비스에서도 관리할 수 있는지, 특정 네트워크에만 의존하는지 등을 확인하면 장기적인 사용과 복구 구조를 이해하는 데 도움이 됩니다.
Account Abstraction 사용 후 확인할 것
- 계정 주소: 실제 사용한 Smart Account 주소가 맞는지 확인합니다.
- 실행 작업: 하나의 요청 안에서 어떤 작업들이 실행됐는지 확인합니다.
- 인증 권한: 어떤 키와 인증 방법이 현재 계정을 제어할 수 있는지 확인합니다.
- 세션 키: 임시 권한이 있다면 범위와 만료 시점을 확인합니다.
- 토큰 승인: 스마트 컨트랙트에 어떤 토큰 권한이 남았는지 확인합니다.
- 가스비: 이용자, Paymaster 또는 다른 주체 가운데 누가 비용을 부담했는지 확인합니다.
- 복구 구조: 기기 분실 시 실제 복구 방법이 준비되어 있는지 확인합니다.
- 서비스 의존성: 특정 Bundler·Paymaster·지갑 서비스 없이도 계정을 관리할 수 있는지 확인합니다.
Account Abstraction에서 가장 중요한 습관
Account Abstraction에서 가장 중요한 것은 “블록체인이 편해졌으니 거래 내용을 몰라도 된다”고 생각하지 않는 것입니다.
사용자 화면에서는 여러 단계가 하나로 줄어들 수 있지만 내부적으로는 인증, 토큰 권한, 스마트 컨트랙트 실행과 가스비 처리 등 여러 작업이 이루어질 수 있습니다.
따라서 계정 주소 확인 → 인증 방식 확인 → 실행 작업 확인 → 남은 권한 확인 → 가스비 처리 확인 → 복구 방법 확인 → 서비스 의존성 확인을 하나의 관리 과정으로 이해하는 것이 중요합니다.
FAQ
Q. Account Abstraction과 Smart Account는 같은 건가요?
완전히 같은 개념으로 볼 필요는 없습니다. Smart Account는 프로그래밍 가능한 계정 자체를 설명하는 데 사용될 수 있고, Account Abstraction은 계정의 인증과 거래 실행 방식을 더 유연하게 만들기 위한 더 넓은 개념과 기술적 접근을 설명합니다.
Q. Account Abstraction을 사용하면 개인키가 없어지나요?
아닙니다. 계정을 인증하고 거래를 승인하기 위한 암호학적 권한은 여전히 필요할 수 있습니다. 다만 하나의 개인키 서명에만 의존하지 않고 여러 키나 인증 방법, 스마트 컨트랙트 규칙 등을 활용할 수 있도록 설계할 수 있습니다.
Q. Account Abstraction과 Seedless Wallet은 같은 건가요?
아닙니다. Seedless Wallet은 전통적인 하나의 복구 문구를 직접 관리하는 방식에 의존하지 않는 키 관리·복구 구조에 초점을 둡니다. Account Abstraction은 계정의 인증과 거래 실행 규칙을 유연하게 만드는 더 넓은 접근입니다.
Q. Account Abstraction을 사용하면 복구 문구가 필요 없나요?
반드시 그렇지는 않습니다. 사용하는 Smart Account와 지갑의 설계에 따라 기존 복구 문구를 사용할 수도 있고 다른 복구 구조를 사용할 수도 있습니다. 실제 복구 방법을 해당 지갑에서 확인해야 합니다.
Q. Paymaster가 있으면 모든 거래의 가스비가 무료인가요?
아닙니다. Paymaster는 특정 조건에서 이용자의 네트워크 비용을 지원하도록 구성될 수 있지만 모든 거래를 항상 무료로 처리한다는 의미는 아닙니다. 지원 대상과 한도, 조건 등을 확인해야 합니다.
Q. Bundler는 제 개인키를 가지고 있나요?
Bundler가 거래 처리 과정에 참여한다는 사실만으로 이용자의 개인키를 보유한다고 이해해서는 안 됩니다. 실제 계정 권한과 인증은 Smart Account와 관련 프로토콜의 규칙에 따라 검증될 수 있습니다.
Q. 한 번만 서명하면 여러 거래가 실행될 수도 있나요?
구현에 따라 여러 작업을 하나의 사용자 요청으로 묶을 수 있습니다. 따라서 확인 화면이 간단하더라도 어떤 토큰 권한과 스마트 컨트랙트 작업이 포함되어 있는지 확인하는 것이 중요합니다.
Q. Account Abstraction을 사용하면 토큰 승인 위험도 없어지나요?
아닙니다. 특정 스마트 컨트랙트에 토큰 사용 권한을 부여했다면 해당 권한은 별도로 관리해야 할 수 있습니다. 더 이상 필요하지 않은 권한은 토큰 승인 취소(Revoke)와 관련된 상태를 확인할 수 있습니다.
Account Abstraction을 쉽게 기억하는 방법
“블록체인 계정의 인증과 거래 실행 규칙을 더 유연하게 만들어 다양한 지갑 기능을 구현할 수 있게 하는 접근”이라고 기억하면 됩니다.
지금까지 배운 개념을 연결하면 다음처럼 구분할 수 있습니다.
Smart Account = 프로그래밍 가능한 계정
Account Abstraction = 계정의 인증·실행 방식을 더 유연하게 만드는 접근
Seedless Wallet = 전통적인 하나의 시드 문구 관리에 의존하지 않는 키 관리·복구 방식에 초점
Account Abstraction의 목적을 단순히 “가스비를 없애는 기술”로 기억하기보다 인증 → 복구 → 권한 → 거래 실행 → 가스비 처리까지 계정 사용 경험을 유연하게 만들 수 있는 구조로 이해하는 것이 좋습니다.
핵심 정리
Account Abstraction(계정 추상화)은 블록체인 계정의 거래 승인과 실행 방식을 더 유연하게 만들어 다양한 지갑 기능을 구현할 수 있도록 하는 개념과 기술적 접근입니다.
이를 활용한 Smart Account에서는 구현에 따라 여러 인증 방법과 계정 복구, 세션 키, 여러 작업의 묶음 처리와 Paymaster를 통한 가스비 지원 같은 기능을 제공할 수 있습니다.
하지만 사용 과정이 간단해진다고 블록체인 거래의 위험이 사라지는 것은 아닙니다. 스마트 컨트랙트 취약점, 잘못된 권한 설정, 악의적인 서명, 서비스 의존성과 복구 설정 오류 등의 위험이 존재할 수 있습니다.
따라서 Account Abstraction을 이용할 때는 계정 주소 → 인증 방식 → 실행되는 작업 → 남아 있는 권한 → 가스비 처리 → 복구 구조 → 서비스 의존성을 함께 확인하는 것이 중요합니다.
참고 자료
Account Abstraction의 구현 방식과 Smart Account의 인증·복구·거래 처리·가스비 지원 구조는 블록체인 네트워크와 지갑, 프로토콜에 따라 다를 수 있습니다. 실제 이용 시에는 사용하는 지갑이나 서비스의 최신 공식 기술·보안·복구 문서를 우선 확인하고 실제 계정에 설정된 권한과 거래 내용을 직접 확인하는 것이 좋습니다.
Disclaimer
본 콘텐츠는 Account Abstraction, Smart Account, 가상자산 지갑 및 블록체인 계정 기술에 대한 일반적인 정보 제공과 이용자 보호를 목적으로 하며 특정 지갑, 가상자산, DApp, 프로토콜 또는 서비스의 이용이나 투자를 권유하지 않습니다. Account Abstraction을 활용한 서비스에는 스마트 컨트랙트 취약점, 잘못된 인증·복구·권한 설정, 피싱, 악의적인 거래 서명, 서비스 및 인프라 의존성, 네트워크 비용과 원금 손실을 포함한 다양한 위험이 존재할 수 있습니다. 실제 이용 전 해당 지갑이나 서비스의 최신 공식 기술·보안·복구 자료와 계정의 실제 권한 및 거래 내용을 직접 확인하시기 바랍니다.