EIP-7702 보안 가이드: 바이낸스 63억 달러 해킹 사건을 통해 본 새 메커니즘의 5가지 치명적 블라인드 스팟

10월 30일, Binance에서 63억 달러가 유출되며 전 세계가 충격에 휩싸였습니다. 사후 분석 결과, 공격자가 사용한 건 기존의 개인 키 탈취 방식이 아니라, 올해 막 활성화된 이더리움 신규 메커니즘인 EIP-7702 위임 권한이었습니다. 이건 어떤 ‘새로운 취약점’도 아니며, 오히려 메커니즘 자체의 ‘설계상 맹점’이 인간의 보안 관행과 충돌한 사례입니다. 일반 사용자든 개발자든 누구나 피해를 입을 수 있습니다. 본 기사에서는 전체 공격 체인을 하나씩 풀어 설명하고, 쉬운 말로 EIP-7702가 정확히 무엇인지 알려 드린 뒤, 각각 5가지 실용적인 피해 예방 조치를 제시합니다.

1. Binance 유출 사건에서 EIP-7702는 어떤 역할을 했는가

먼저 사건 자체로 돌아가겠습니다. 10월 30일 새벽, 체인 상 모니터링 전문가 ‘신어(Shen Yu)’가 X(구 트위터)에 충격적인 세부 정보를 게시했습니다. 이더리움 Pectra 업그레이드 이후, Binance의 14개 핫 월렛 주소가 모두 일종의 ‘이상한 거래’ — 즉 type-4 거래 — 에 서명했다는 사실이었습니다. 동시에 이 월렛들은 외부 공격자 계약에 유효한 위임 권한을 부여한 상태였습니다.

현재 커뮤니티에서 복원한 전체 공격 흐름은 대략 다음과 같습니다:

1. 침입 경로: Binance 내부 개발자 또는 운영 담당자의 노트북이 피싱/멀웨어에 의해 해킹됨;
2. 악성 거래 삽입: 공격자는 내부 서명 채널을 확보해 핫 월렛에 type-4 거래를 삽입할 수 있었음;
3. 대량 위임: 단 몇 시간 만에 50개 핫 월렛이 차례로 ‘서명’하며, 자신의 코드 실행 권한을 공격자가 통제하는 계약에 위임함;
4. 통제권 탈취: 위임이 발효된 후, 공격자는 마치 자신의 계약을 호출하듯 해당 핫 월렛을 호출할 수 있게 됨 — 서명 시스템이 보는 건 단지 32바이트짜리 ‘거래 요약’일 뿐이며, 실제로 서명한 건 ‘차량 열쇠를 남에게 넘긴다’는 위임서라는 점을 인지하지 못함.

다행히 사건이 알려진 후, Binance 체인 상 팀이 긴급히 위임 해지 거래를 배포했고, 현재 약 30억 달러 규모의 유출 자산이 성공적으로 잠금 처리됨 — 이는 EIP-7702 위임이 원칙적으로 되돌릴 수 있다는 의미지만, 그 전제는 ‘해지 거래를 아직 서명할 수 있어야 한다’는 점입니다. 이번 사건의 전체 시간 흐름은 이전 심층 보도를 참고하세요: 63억 달러 유출: Binance 핫 월렛, EIP-7702 위임 탈취 당하다.

참고로, Binance는 EIP-7702를 악용한 첫 번째 기관이 아닙니다 — 이미 9월에는 낯선 DApp의 type-4 거래에 서명한 일반 개인 투자자들이 자산을 훔쳐가는 사례가 있었습니다. 그러나 Binance 사건은 이 ‘메커니즘 차원의 보안 문제’를 한순간에 전면에 부각시켰습니다.

2. EIP-7702 핵심 메커니즘 빠르게 보기 (3분 안에 이해)

기존 이더리움에는 두 가지 계정만 존재합니다: EOA(외부 소유 계정)와 계약 계정. EOA는 마치 은행 카드처럼, 개인 키로 한 번 서명하면 한 번만 사용됩니다. 반면 계약 계정은 체인 상에 배포된 코드 로직입니다. EIP-7702가 해결하려는 핵심 질문은 바로 이것입니다: EOA가 일시적으로 계약 계정의 능력을 얻을 수는 없을까?

정답은 ‘위임 권한(delegation)’입니다 — 비유하자면, 당신이 소유한 차량(EOA)을 친구(목적 계약)에게 빌려주는 것입니다. 빌리는 방식은 번호판을 바꾸는 게 아니라, 체인 상에 ‘누가 차량 열쇠를 잠시 맡을 것인가’를 명시한 위임서를 서명하는 것입니다.

기술적으로 보면, EIP-7702는 두 가지 핵심 변화를 도입했습니다:

• type-4 거래: ‘위임 서명’ 전용으로 설계된 새로운 거래 유형입니다. 서명자는 목적 주소에 ETH를 전송할 필요 없이, 단지 위임서를 체인 상에 게시하기만 하면 됩니다.
• 위임은 명시적으로 해지될 때까지 영구적으로 유효합니다. 이것이 가장 중요하면서도 가장 쉽게 간과되는 부분입니다 — ‘자동 만료’도 없고, ‘한 번만 사용’도 없습니다.

좋아 보이죠? 이론상으로는 가스비 대신 계약을 위임하거나, DApp에 일정 기간 자동화 작업 권한을 부여하는 등 다양한 용도로 활용할 수 있습니다. 하지만 이 ‘영구적 유효성’이라는 근본 설계가 거의 모든 보안 사고의 씨앗이 되었습니다.

3. 5가지 치명적인 맹점 (일반 사용자가 가장 쉽게 당할 부분)

다음 5가지 맹점은 일반 사용자가 가장 흔히 빠지는 함정입니다. 각 항목에는 실제 사례가 있습니다.

1. 위임 권한은 자동으로 만료되지 않음 — 사용 후 해지 안 하면 열쇠를 영구히 남에게 넘기는 것과 같음

많은 DApp이 사용자에게 “한 번 delegate 버튼을 누르면 앞으로 이체 수수료가 20% 할인된다”고 유도합니다. 사용자는 그냥 클릭하고 잊어버리죠. 그런데 그 위임은 체인 상에 영구히 남아 있고, DApp 운영팀이 바뀌거나 심지어 주소가 매각돼도, 당신의 지갑 열쇠는 여전히 남의 손에 쥐어져 있습니다.

2. 지갑 UI에 현재 누구에게 위임했는지 표시되지 않음

이것이 현재 전체 생태계에서 가장 곤란한 점입니다. 2026년 10월 기준, 대부분의 주요 지갑(Trust Wallet, Exodus, 심지어 일부 하드웨어 지갑 연동 인터페이스조차)에는 ‘위임 관리’ 페이지가 없습니다. 당신이 type-4 거래를 17번 서명했더라도, 지금 지갑 화면에 보이는 건 단지 ‘거래 요약’ 한 줄뿐이고, 도대체 누구에게 열쇠를 넘겼는지 전혀 알 수 없습니다.
다행히 etherscan.io가 최근 인터페이스를 업데이트했습니다 — 이제 자신의 주소 페이지를 열고 ‘Delegations’ 탭을 클릭하면 모든 과거 위임 기록을 확인할 수 있습니다.etherscan.io는 현재 가장 믿을 수 있는 자기 점검 도구입니다.

3. 서명 즉시 발효 — 추가 확인 없음

DApp에서 ‘확인’ 버튼을 누르면, 지갑 팝업에 ‘가스비 0.001 ETH’라고 표시되고, 당신은 그냥 서명합니다 — 체인 상에서는 당신의 EOA가 공격자 계약에 영구 위임서를 게시하는 일이 벌어집니다. 두 번째 팝업도 없고, 추가 확인도 없습니다. 서명자가 보는 건 단지 32바이트의 거래 요약일 뿐이며, 이게 일반 이체인지 type-4인지 전혀 구분할 수 없습니다.

4. 위임은 중첩 가능하며, 원래 서명자는 전혀 알지 못함

A가 B에게 위임하고, B가 C에게 위임하며, C가 D에게 위임한다—이론상으로는 무한히 중첩될 수 있습니다. 바이낸스(Binance) 사고에서도 이러한 위임 체인의 중첩 징후가 확인되었습니다. 만약 귀하의 지갑이 악성 계약에 의해 이미 장악된 상태라면, 귀하의 동의 없이도 추가 주소들에 대한 제어권을 더 위임할 수 있습니다.

5. 위임 해지 자체도 서명이 필요합니다

이것이 가장 절망적인 부분입니다. 공격자가 이미 귀하의 위임 권한을 확보했다면, 귀하의 자산을 동결하거나 지갑을 악성 계약 모드로 전환시킬 수 있습니다. 해지를 원하시나요? 위임 해지도 서명이 필요합니다. 그런데 그 서명 채널 자체가, 이미 중첩 위임을 통해 공격자에게 장악되었을 가능성도 있습니다.

사, 일반 사용자 실천 체크리스트

여기까지 설명했지만, 지금 당장 무엇을 해야 할까요? 아래 5단계 점검을 순서대로 진행하세요.

✅ 1단계: 즉시 자신의 지갑 위임 기록을 확인하세요.
etherscan.io에 접속해 귀하의 지갑 주소를 입력한 후, “Delegations” 탭으로 이동하세요. 위임 목록에 익숙하지 않은 주소가 보인다면, 그것은 곧 폭탄입니다.

✅ 2단계: 익숙하지 않은 위임이 있다면 즉시 해지하세요.
해지 도구로는 OpenZeppelin Defender 또는 커뮤니티에서 관리하는 EIP-7702 Revoker를 추천합니다. 온체인에서 한 번의 해지 거래에 드는 가스비는 보통 1~5달러 사이이며, 일반 이체와 유사한 방식으로 진행됩니다.
⚠️ 참고: 귀하의 지갑이 이미 악성 위임에 의해 장악된 경우, 해지 시도가 실패할 수 있습니다. 이때는 하드웨어 지갑(Ledger, Trezor)을 사용해 오프라인에서 해지 거래의 서명을 생성한 뒤, 깨끗한 다른 컴퓨터에서 해당 거래를 브로드캐스트하는 것이 현재로서는 가장 안전한 방법입니다.

✅ 3단계: 잠시 지갑 사용 습관을 조정하세요.
Trust Wallet이나 Exodus를 사용 중이라면, type-4 거래를 직접 서명하는 것을 잠시 피하는 것이 좋습니다. 비교적 안전한 조합은 Ledger 하드웨어 지갑 + Rabby 브라우저 확장 프로그램입니다. 하드웨어 서명 장치는 중첩 위임을 자동으로 실행하지 않으며, 적어도 귀하 몰래 ‘조용히’ 서명하지는 않습니다.

✅ 4단계: 낯선 DApp에서 “Delegate” 버튼을 함부로 누르지 마세요.
“가스비 할인”, “수수료 면제”, “자동 수익 창출” 등을 이유로 위임 서명을 요구하는 DApp은 일단 멈춰 세우세요. X(트위터)나 텔레그램에서 해당 DApp 이름과 함께 “hack”, “scam”을 검색해 3분간 배경 조사를 하는 것이, 몇 달러의 가스비를 아끼는 것보다 훨씬 가치 있습니다.

✅ 5단계: 거래소 사용자 특별 안내.
주로 Binance, OKX 같은 CEX를 사용 중이라면, 이들은 핫 월렛 위임을 통합 관리합니다. 따라서 귀하의 개인 계정 차원에서는 별도 조치가 필요하지 않지만, 거래소 공식 앱을 우선 사용하고, 제3자 지갑을 통해 거래소 입금 주소에 type-4 거래를 직접 서명하지 않도록 주의하세요.

오, 개발자 실천 체크리스트

DApp 또는 DeFi 개발자로서, 귀하의 책임은 더욱 큽니다. 다음 5가지는 업계 내 현재 공인된 ‘최소 보안 기준’입니다.

1. 위임 권한에는 반드시 합리적인 만료 시간찌르다(expiry)를 설정해야 합니다.
현재 모든 지갑이 서명 단계에서 expiry를 검증하진 않지만, 귀하가 배포하는 위임 계약 로직 내부에는 반드시 이 검사를 하드코딩해야 합니다. “30일 후 자동 만료”되는 위임과 “영구 유효”한 위임은 보안 수준이 완전히 다릅니다.

2. 프론트엔드 UI는 type-4 거래를 빨간 대형 팝업으로 사용자에게 반드시 경고해야 합니다.
표준 절차는 다음과 같습니다: 사용자가 Delegate 버튼을 클릭하면, 프론트엔드가 독립적인 빨간 모달 창을 띄우고, 굵은 큰 글씨로 “⚠️ 귀하는 지금 EIP-7702 위임 거래에 서명하려 합니다—이로 인해 대상 주소가 귀하의 지갑 코드를 실행할 권한을 얻게 됩니다”라고 명시하며, 계속하려면 사용자가 직접 “위험을 알고 있습니다”라고 입력해야 합니다.

3. 사용자가 입력한 위임 대상(delegation target)은 절대 받아들이지 마세요.
위임 대상 계약 주소는 프론트엔드 코드 내에서 하드코딩되어야 하며, 체인 상에 실제로 배포된 주소와 반드시 일치하는지 검증해야 합니다. 사용자에게 target을 직접 입력하게 한다는 건, 위임 권한의 ‘문짝 번호’를 넘겨주는 것과 같습니다.

4. EIP-7715의 “delegateWithPermissions” 변형으로 업그레이드하세요.
EIP-7715는 EIP-7702를 기반으로 권한 제한(permissions) 기능을 추가했습니다. 이를 통해 위임 대상이 어떤 함수만 호출할 수 있고, 어떤 함수는 절대 호출할 수 없는지를 정의할 수 있습니다. 이론상으로는 표준이 되어야 하지만, 현재 지원 수준은 아직 낮은 편입니다. 가능한 한 빨리 마이그레이션하세요.

5. 테스트 환경에서는 반드시 OpenZeppelin의 7702 감사 스크립트를 강제 실행하세요.
OpenZeppelin은 이미 EIP-7702 보안 감사를 Defender 점검 목록에 포함시켰습니다. 계약을 배포할 때마다, 위임 관련 리스크를 자동으로 스캔하는 스크립트를 돌리는 비용은 거의 제로입니다.

육, 맺음말

EIP-7702는 결함 있는 프로토콜이 아닙니다. 일반 EOA가 계약 기능을 획득할 수 있도록 한다는 이 프로토콜의 핵심 설계 목표는 옳습니다. 문제는 바로 이 ‘영구 유효’라는 기본 가정이, 이더리움 생태계에서 가장 취약한 고리—즉 인간의 보안 습관—과 충돌했다는 점입니다.

바이낸스(Binance) 사고는 EIP-7702가 등장한 이후 지금까지 가장 비싼 보안 교훈이 될 수 있습니다. 그러나 반대로 생각해 보면, 이번 사고는 전체 생태계를 ‘무감각한 위임’이라는 환상에서 단번에 깨워주었습니다. 이제 etherscan에는 위임 탭이 생겼고, 지갑 팀은 보안 팝업을 보완 중이며, OpenZeppelin은 감사 스크립트를 업데이트했습니다—모든 사고는 이 메커니즘을 더 안전하게 만들고 있습니다.

개인적으로 지금 가장 가치 있는 행동은 두 가지뿐입니다: etherscan에서 자신에게 익숙하지 않은 위임이 있는지 확인하기, 그리고 DeFi를 사용하는 주변 친구들에게 이 사실을 알려주기. 그것만으로도 충분합니다.