ERC-7579 모듈형 스마트 계정: 검증·실행·훅과 보안 리스크

스마트 월렛에 복구, 자동 실행, 다양한 서명 방식을 모두 직접 넣으면 계정 코드와 업그레이드가 복잡해져요. ERC-7579 모듈형 스마트 계정은 더 넓은 크립토 지갑 보안 체계 안에서 플러그인 방식을 제안합니다. 초안 표준은 계정과 모듈이 공유할 최소 인터페이스를 정하되, 지갑 내부 설계까지 하나로 고정하지 않아요.

ERC-7579는 무엇을 표준화하려 하나요?

스마트 계정(Smart Account)은 규칙을 코드로 표현하는 컨트랙트 계정이에요. 다중서명, 패스키(Passkey), 복구 가디언(Guardian), 지출 정책, 예약 실행처럼 개인키 하나만 쓰는 외부 소유 계정(EOA)이 직접 표현하기 어려운 기능을 만들 수 있습니다. 이 구분이 낯설다면 먼저 계정 추상화와 스마트 월렛 가이드를 읽어 보세요.

문제는 파편화예요. 어떤 지갑은 복구 기능을 자체 모듈로 제공하고, 다른 지갑은 설치 호출, 실행 데이터, 검증 방식이 모두 다를 수 있어요. 개발자는 같은 기능을 계정 시스템마다 다시 만들어야 하고, 사용자는 한 공급자의 모듈 생태계에 묶일 수 있습니다.

공식 ERC-7579 명세는 호환 스마트 계정 사이에서 모듈을 옮겨 쓸 수 있도록 최소 인터페이스와 동작을 정의해요. 실행, 계정 설정, 모듈 설치, ERC-1271 서명 처리, 선택적 폴백(Fallback)과 훅(Hook)을 다룹니다. 다만 계정 내부를 어떤 구조로 구현할지는 일부러 강제하지 않아요.

USB 규격을 떠올리면 쉬워요. USB는 호환 장치가 어떻게 연결하고 통신하는지 정하지만, 모든 키보드와 노트북의 내부 회로까지 같게 만들지는 않죠. ERC-7579도 스마트 계정과 모듈에 공통 소켓을 제공할 뿐, 꽂는 모듈이 안전하다거나 모든 호환 지갑이 똑같이 동작한다고 보장하지 않습니다.

ERC-7579의 네 가지 모듈 유형

초안은 모듈을 권한에 따라 나눠요. 서명이 유효한지 확인하는 권한과 계정 대신 트랜잭션을 시작하는 권한은 서로 다르기 때문입니다.

모듈 유형	타입 ID	주요 역할	활용 예	핵심 보안 질문
검증자(Validator)	1	작업이나 서명이 유효한지 판단	패스키·다중서명·복구 검증	허가하지 않은 작업을 승인할 수 있나요?
실행자(Executor)	2	계정을 대신해 호출 실행	예약 결제·자동화 전략	누가 실행하고 어디까지 호출할 수 있나요?
폴백 핸들러(Fallback Handler)	3	계정의 함수 응답 방식 확장	기본 계정에 없는 인터페이스 추가	원래 호출자가 보존되고 검증되나요?
훅(Hook)	4	실행 전후에 검사 수행	지출 정책·상태 변화 검사	계정을 멈추거나 위험 경로를 놓칠 수 있나요?

하나의 컨트랙트가 여러 모듈 유형을 동시에 표시할 수도 있어요. 그래도 계정은 타입을 구분해 저장해야 합니다. 실행자에게만 줄 권한이 검증자에게 잘못 열리면 보안 경계가 무너지기 때문이에요.

검증자는 권한의 유효성을 판단해요

검증자(Validator)는 계정의 인증 규칙을 담당해요. 현재 ERC-4337 의존 설계에서는 패킹된 UserOperation을 검증하고 ERC-1271 컨트랙트 서명 검사도 지원할 수 있습니다. 패스키 검증자, 임계값 서명 검증자, 복구 규칙을 예로 들 수 있어요.

ERC-7579가 표준화하는 것은 인터페이스이지 규칙의 신뢰성이 아니에요. 버그가 있거나 악의적으로 업그레이드되는 검증자는 소유자가 원하지 않은 작업을 받아들일 수 있습니다. 서명 구조는 ERC-1271 스마트 컨트랙트 서명 가이드에서 더 자세히 확인하세요.

실행자는 계정을 대신해 행동할 수 있어요

실행자(Executor)는 설치되고 권한을 받으면 executeFromExecutor를 통해 계정 호출을 요청할 수 있어요. 자동화에는 유용하지만 강한 권한입니다. 자체 규칙에 따라 소유자의 새 서명 없이도 호출을 시작할 수 있기 때문이에요.

회사의 법인카드를 가진 직원을 떠올려 보세요. 업무상 결제 권한이 필요하더라도 “이 직원을 믿는가?”만 물으면 부족합니다. “어떤 가맹점에서, 얼마까지, 언제까지 쓸 수 있는가?”를 함께 정해야 해요. 실행자 설치에는 좁은 범위, 명확한 실행 조건, 실제로 시험한 제거 경로가 필요합니다.

폴백 핸들러는 계정 기능을 확장해요

폴백 핸들러(Fallback Handler)는 기본 계정이 구현하지 않은 함수 호출에 응답할 수 있어요. ERC-7579에 따르면 호환 전달은 call 또는 staticcall을 사용하고, ERC-2771 방식으로 원래 호출자를 덧붙이며, 함수 셀렉터(Function Selector)에 따라 라우팅해야 합니다. 호출자 처리가 잘못되면 호환 기능이 권한 취약점으로 바뀔 수 있어요.

훅은 실행 맥락을 검사해요

훅(Hook)은 선택 기능이에요. 실행 전 preCheck, 실행 후 postCheck를 수행할 수 있습니다. 지출 상한이나 결과를 검사할 수 있지만, 모든 트랜잭션이 거치는 핵심 경로가 되기도 해요. 망가지거나 악의적인 훅이 계속 되돌리면 계정 사용 자체가 막힐 수 있습니다.

설치와 실행은 어떻게 이어지나요?

호환 흐름은 크게 여섯 단계로 볼 수 있어요.

1. 앱이 계정을 확인해요. accountId, supportsModule, supportsExecutionMode로 구현 식별자와 지원 기능을 조회합니다.
2. 소유자가 설치를 승인해요. 계정은 모듈 타입, 주소, 초기화 데이터를 넣어 installModule을 호출합니다.
3. 계정이 타입별로 모듈을 기록해요. 모듈의 onInstall을 호출하고 설치가 성공하면 ModuleInstalled 이벤트를 남깁니다.
4. 모듈이 제한된 역할을 수행해요. 검증자는 권한을 확인하고, 실행자는 호출을 요청하며, 폴백 핸들러는 인터페이스를 확장하고, 훅은 맥락을 검사합니다.
5. 계정이 실행 규칙을 강제해요. 지원하지 않는 모드는 되돌려야 하고 실행 진입점에는 알맞은 권한 검사가 필요합니다.
6. 소유자가 모듈을 제거할 수 있어요. 계정은 onUninstall을 호출하고 등록을 지운 뒤 ModuleUninstalled 이벤트를 남깁니다. 단, 악성 모듈이 제거 호출을 방해할 가능성도 고려해야 해요.

실행 모드(Execution Mode)는 32바이트 값으로 호출 유형, 실패 처리 방식, 확장 공간을 표현합니다. 계정은 단일 호출, 배치, 정적 호출, 델리게이트콜(Delegatecall) 중 무엇을 지원하는지 알릴 수 있어요. 모든 구현이 모든 모드를 지원하는 척하지 않아도 됩니다.

ERC-7579의 현재 검증 흐름은 ERC-4337에 의존해요. 번들러(Bundler), 엔트리포인트(EntryPoint), UserOperation도 여전히 관련됩니다. 명세 작성자는 다른 계정 추상화 구조가 등장하면 이 의존성을 확장 표준으로 분리할 가능성을 설명해요. 가스비 후원은 별도 문제입니다. ERC-4337 페이마스터 가이드에서 누가 비용을 부담하고 후원 작업이 왜 실패할 수 있는지 확인할 수 있어요.

상호운용성이 보장하는 것과 보장하지 않는 것

Safe의 ERC-7579 문서는 지원 계정 구현 사이에서 모듈이 작동하도록 하는 것을 목표로 설명해요. Safe는 전체 계정 설계를 바꾸는 대신 Safe7579 어댑터를 사용해 필요한 동작을 제공합니다.

이 사례는 표준의 최소 접근법을 잘 보여줘요. 호환성은 맞춤 통합 작업과 공급자 종속을 줄일 수 있지만, 다음을 보장하지는 않습니다.

• 모든 계정이 모든 실행 모드나 선택적 훅을 지원한다는 것
• 같은 모듈의 설정 방식이 모든 지갑에서 같다는 것
• 모듈이 감사를 받았거나 큰 자산을 맡겨도 안전하다는 것
• 어댑터가 기반 계정의 모든 보안 가정을 그대로 보존한다는 것
• 초안 인터페이스가 앞으로 바뀌지 않는다는 것

기능 호환성과 보안 보증은 별개의 질문이에요. 플러그가 소켓에 맞더라도 그 장치가 무엇을 하는지는 따로 확인해야 합니다.

꼭 확인해야 할 위험과 한계

모듈 설치는 실제 권한을 부여해요

모듈 설치는 화면 테마를 추가하는 가벼운 작업이 아니에요. 검증자는 인증에 영향을 주고 실행자는 계정 호출을 시작할 수 있습니다. 공식 출처를 서로 대조해 모듈 주소, 타입, 초기화 데이터, 지원 체인, 감사 내역, 배포 주체를 확인하세요.

델리게이트콜은 계정 전체 상태를 노출할 수 있어요

명세는 델리게이트콜 실행을 특히 조심해야 한다고 경고해요. 델리게이트콜은 대상 코드를 계정의 스토리지 맥락에서 실행합니다. 안전하지 않은 코드는 소유권, 모듈 설정, 핵심 상태를 손상할 수 있어요.

콜백과 제거가 실패할 수 있어요

onInstall과 onUninstall은 외부 콜백이므로 구현자는 재진입(Reentrancy)을 고려해야 합니다. 악성 모듈이 제거 중 계속 되돌려 스스로 빠지지 않게 만들 수도 있어요. 개발자는 방어적인 제거·복구 설계를 갖춰야 하고, 사용자는 의미 있는 자산을 넣기 전에 비상 경로를 알아야 합니다.

훅은 서비스 거부 지점이 될 수 있어요

항상 되돌리는 훅은 실행을 막을 수 있어요. 한 경로만 검사하는 훅은 다른 경로가 정책을 우회하는데도 안전하다는 착각을 줄 수 있습니다. 계정 설정 변경을 포함해 어떤 행동이 실제로 훅을 거치는지 검토하세요.

레지스트리는 신호이지 보증이 아니에요

초안 ERC-7484는 모듈 증명(Attestation)을 저장하고 검사하는 레지스트리와 어댑터를 제안해요. 증명은 계정이 신뢰 정책을 적용하는 데 도움을 줄 수 있지만, 증명자, 레지스트리 규칙, 취소 속도, 어댑터 동작을 다시 신뢰해야 합니다. 보증이나 보험과 같지는 않아요.

모듈 설치 전 실전 체크리스트

• 지갑과 정확한 계정 버전이 ERC-7579 또는 특정 어댑터를 지원하는지 확인하세요.
• 공식 문서에서 모듈 컨트랙트 주소와 모듈 타입을 대조하세요.
• 미래의 자동 실행까지 포함해 모듈이 받는 최대 권한을 읽어 보세요.
• 배치와 델리게이트콜을 포함한 지원 실행 모드를 확인하세요.
• 감사, 소스코드 검증, 업그레이드 권한, 레지스트리 증명을 검토하세요.
• 누가 설정을 바꿀 수 있는지, 지연 시간이나 다중서명이 적용되는지 확인하세요.
• 소액 계정에서 설치, 정상 사용, 제거를 모두 시험하세요.
• 모듈이나 훅이 실행을 막을 때 쓸 비상 복구 경로를 기록하세요.
• 더 이상 쓰지 않는 모듈은 제거하세요.

자주 묻는 질문(FAQ)

ERC-7579는 이더리움에서 이미 활성화됐나요?

프로젝트가 컨트랙트나 어댑터로 구현할 수 있는 초안 ERC예요. 모든 계정에 자동 적용되는 네트워크 공통 기능은 아닙니다. 사용하기 전에 공식 ERC 상태와 지갑의 최신 문서를 확인하세요.

ERC-7579와 ERC-4337은 같은 표준인가요?

아니에요. ERC-4337은 UserOperation, 번들러, 엔트리포인트를 중심으로 계정 추상화 트랜잭션 흐름을 정의합니다. ERC-7579는 모듈형 스마트 계정과 모듈의 최소 인터페이스와 동작을 정의하며, 현재 검증 설계는 ERC-4337에 의존해요.

ERC-7579를 지원하면 모듈이 안전한가요?

아니에요. 인터페이스 호환성은 높일 수 있지만 모듈 코드, 초기화, 업그레이드, 권한 검사, 지갑 통합은 따로 검토해야 합니다. 공식 명세도 델리게이트콜, 콜백, 악성 훅, 폴백 권한, 제거 실패를 위험으로 언급해요.

모듈 하나가 여러 역할을 할 수 있나요?

가능해요. 한 모듈이 여러 타입을 표시할 수 있습니다. 계정은 그래도 타입을 구분하고 각 역할에 맞는 권한 검사를 적용해야 해요.

기존 스마트 계정도 호환 계정이 될 수 있나요?

가능할 수 있어요. 명세는 업그레이드 가능한 계정이 호환 구현으로 바뀌거나, 일부 업그레이드 불가능 계정이 어댑터나 폴백 구조를 쓸 가능성을 설명합니다. 실제 가능성과 안전성은 원래 계정 구조에 달려 있어요.

핵심 정리

ERC-7579는 스마트 계정 기능에 공통된 최소 연결 규격을 만들려는 시도예요. 검증자는 권한의 유효성을 판단하고, 실행자는 행동을 시작하며, 폴백 핸들러는 인터페이스를 확장하고, 훅은 실행을 검사합니다. 이 구분은 모듈 이동성을 높이고 공급자별 통합을 줄일 수 있어요.

동시에 모듈 검토가 지갑 보안의 핵심이 됩니다. 설치 전에 정확한 주소와 타입을 확인하고, 최대 권한과 업그레이드·제거 통제를 이해하며, 소액으로 시험하세요. 상호운용성은 통합 마찰을 줄일 뿐 스마트 컨트랙트와 운영 위험을 없애지 않습니다.

이 글은 교육 목적이며 투자 조언이 아닙니다(NFA). 스마트 계정과 모듈 소프트웨어는 실패할 수 있고 크립토 자산을 잃을 수 있어요. 반드시 스스로 조사하고(DYOR), 감당할 수 있는 금액만 사용하세요.