이더리움 SELFDESTRUCT 완전 정리: EIP-6780 이후 실제로 삭제되는 것

SELFDESTRUCT라는 이름을 보면 삭제 버튼부터 떠올리기 쉬워요. 하지만 현재 이더리움에서는 대체로 그렇지 않습니다. Cancun 실행 레이어 업그레이드 이후, 기존 컨트랙트가 이 명령을 실행하면 보유 이더(ETH)는 전송되고 현재 호출은 멈추지만 코드, 스토리지(Storage), 계정은 남아요. 종료 설계와 재배포, 사고 대응에 오래된 가정을 적용하지 않으려면 블록체인 기초에서 이 차이를 알아야 합니다.

이 글은 최종 확정된 EIP-6780 규칙과 같은 트랜잭션(Same-transaction) 예외, 더 안전한 설계 방식을 설명해요. 아직 확정되지 않은 후속 제안은 현재 합의 규칙과 분명히 구분합니다.

Cancun 이후 SELFDESTRUCT는 무엇을 하나요?

스마트 컨트랙트를 현금 서랍, 운영 매뉴얼, 서류함이 있는 상점으로 생각해 보세요. 과거 SELFDESTRUCT는 상점을 철거 대상으로 표시하고 이더를 수익자(Beneficiary)에게 보낼 수 있었습니다. EIP-6780 이후 기존 상점은 현금 서랍을 비울 수 있지만 건물, 매뉴얼과 서류는 그대로 남아요.

현재 트랜잭션보다 전에 생성된 컨트랙트가 SELFDESTRUCT를 실행하면 다음과 같이 동작합니다.

1. 현재 실행 프레임(Execution Frame)을 종료해요.
2. 컨트랙트의 전체 ETH 잔액을 수익자에게 보냅니다.
3. 코드, 스토리지와 계정을 삭제하지 않아요.
4. SELFDESTRUCT 가스 환급(Gas Refund)을 주지 않습니다.

명령의 효과가 완전히 사라진 것은 아니에요. ETH를 옮기고 실행을 멈출 수 있습니다. 다만 일반적인 컨트랙트 삭제 도구가 아닙니다.

이는 컴파일러 옵션이 아니라 네트워크 규칙이에요. Solidity 공식 문서는 Cancun이 활성화된 체인에서 --evm-version을 바꿔도 과거 동작으로 돌아가지 않는다고 설명합니다.

같은 트랜잭션 예외는 어떻게 작동하나요?

EIP-6780은 컨트랙트가 생성된 바로 그 트랜잭션 안에서 SELFDESTRUCT를 실행할 때만 과거 동작을 유지합니다. 이 좁은 경우에는 트랜잭션 마무리 시 코드, 스토리지와 계정이 제거될 수 있고 잔액은 수익자에게 전송돼요.

여기서 '같은 트랜잭션'은 '같은 블록'이나 '조금 전에 배포됨'보다 엄격합니다. 팩토리(Factory)가 임시 자식 컨트랙트를 만들고 팩토리 트랜잭션이 끝나기 전에 자식이 스스로 파괴되는 흐름은 예외에 들어갈 수 있어요. 트랜잭션 A에서 배포되고 트랜잭션 B에서 파괴된다면 같은 블록에 포함돼도 이미 기존 컨트랙트입니다.

이 예외는 영구 상태가 필요 없는 임시 컨트랙트와 카운터팩추얼(Counterfactual) 패턴을 일부 보존합니다. 그러나 명령이 앞으로도 영구적인 생명주기 도구로 남는다는 보장은 아니에요. EIP-6049는 SELFDESTRUCT를 공식 폐기 예정(Deprecated)으로 지정했고, Solidity는 0.8.18부터 사용 경고를 냅니다.

상황	ETH 잔액	코드와 스토리지	계정 삭제
현재 트랜잭션 전에 존재한 컨트랙트	수익자에게 전송	유지	안 됨
현재 트랜잭션에서 생성 후 파괴	수익자에게 전송	현행 규칙상 제거	현행 규칙상 가능
이후 해당 트랜잭션 범위가 리버트(Revert)	상태 효과 취소	유지	확정되지 않음

이더리움은 왜 동작을 바꿨나요?

앱 관점에서는 계정 하나를 지우는 일이 단순해 보이지만 클라이언트에는 넓은 상태 관리 작업을 요구합니다. EIP-6780은 버클 트리(Verkle Tree) 같은 미래 상태 구조가 한 계정을 여러 키에 나눠 저장하므로 임의 삭제가 더 복잡해진다고 설명해요. 삭제를 제한하면 이런 의존성을 줄이면서 임시 컨트랙트를 위한 좁은 경로는 남길 수 있습니다.

가스 인센티브는 이미 달라졌어요. EIP-3529는 SELFDESTRUCT 환급을 없애고 스토리지 정리 환급을 줄였습니다. 컨트랙트를 파괴해 가스를 돌려받거나 가스 토큰(Gas Token)을 활용하라는 오래된 조언은 현재 규칙에 맞지 않아요.

히스토리(History)와 현재 상태(State)도 구분해야 합니다. 예외 조건에서 현재 상태가 제거되더라도 거래와 이전 컨트랙트 활동은 블록체인 기록에 남아요. 모든 노드, 인덱서, 아카이브와 데이터 제공자에서 파일을 안전 삭제하는 것과는 다릅니다.

EIP-6780 이후 CREATE2 재배포는 왜 막히나요?

일부 오래된 시스템은 CREATE2와 SELFDESTRUCT를 결합해 여러 트랜잭션에 걸쳐 결정론적 주소의 코드를 교체했습니다. 배포하고, 파괴한 뒤, 같은 주소에 다른 런타임 코드를 다시 배포하는 메타모픽(Metamorphic) 방식이에요. EIP-6780 이후 기존 컨트랙트의 코드와 논스(Nonce)가 제거되지 않으므로 이 업그레이드 방식은 작동하지 않습니다.

CREATE2 가이드에서 설명한 주소 계산식이 바뀐 것은 아니에요. 목적지가 다시 생성 가능한 상태가 되는지가 달라졌습니다. 주소에 코드가 남거나 논스가 0이 아니면 EVM 생성 충돌 규칙 때문에 덮어쓸 수 없어요.

업그레이드가 필요하다면 권한과 스토리지 규칙을 감사할 수 있는 명시적 구조를 써야 합니다. 프록시 컨트랙트는 주소를 유지하면서 구현 컨트랙트에 실행을 위임해요. 관리자, 초기화와 스토리지 레이아웃이라는 별도 위험이 있지만, 사라진 파괴 규칙에 기대는 대신 업그레이드 장치를 드러냅니다.

더 안전하게 컨트랙트를 비활성화하는 방법

대부분의 앱에는 삭제보다 통제된 중단이 필요해요. 위험한 동작을 막되 증거와 사용자 출구는 남겨야 합니다.

민감한 기능만 일시 정지하기

일시 정지 플래그(Pause Flag)로 예치, 차입, 발행 같은 기능을 막고 출금이나 복구 기능은 유지할 수 있어요. 권한은 다중서명(Multisig)이나 거버넌스로 보호하고, 어떤 함수가 멈추는지 정의한 뒤 정지와 해제 경로를 모두 테스트해야 합니다.

동작을 영구 비활성화하기

종료를 되돌릴 수 없어야 한다면 단방향 상태 플래그를 설정해 관련 함수가 항상 실패하도록 만들 수 있어요. Solidity 문서도 SELFDESTRUCT 대신 내부 상태를 이용한 비활성화를 권합니다. 다른 진입점, 위임 호출 또는 특권 역할이 이 플래그를 우회하지 않는지 확인하세요.

마이그레이션을 명시적으로 설계하기

후속 주소를 공지하고 신규 활동을 멈춘 뒤, 사용자가 문서화된 절차로 출금하거나 포지션을 청구하게 할 수 있습니다. 잔액, 승인(Approval), 외부 연동이 코드와 함께 자동 이동한다고 가정하면 안 돼요. 자산과 의존성마다 별도 분석이 필요합니다.

업그레이드가 필요하면 검토된 프록시 사용하기

프록시는 지속적인 코드 교체가 의도된 신뢰 가정일 때만 적합해요. 실제 관리자, 지연 시간, 다중서명 임계값, 초기화 상태, 스토리지 호환성과 모니터링을 확인해야 합니다. 업그레이드 가능하다는 이유만으로 불변 컨트랙트보다 안전한 것은 아니에요.

리스크와 감사 체크포인트

• 가짜 종료: 함수가 SELFDESTRUCT를 호출해도 기존 컨트랙트의 코드와 스토리지가 남아 다시 호출될 수 있어요.
• ETH 강제 이동: 명령은 여전히 실행 컨트랙트의 ETH 잔액을 옮길 수 있습니다. 수익자와 실행 권한을 추적하세요.
• 위임 호출 경로: Solidity 문서는 소스에 명령이 없어도 위임된 코드가 SELFDESTRUCT를 실행할 수 있다고 경고합니다.
• 체인별 차이: EVM 호환 네트워크는 업그레이드 일정과 규칙이 다를 수 있어요. 대상 체인과 포크 활성화 상태를 확인하세요.
• 생성자 예외: 같은 트랜잭션 파괴는 현행 규칙에서도 특별합니다. 팩토리, 중첩 생성, 리버트와 잔액 흐름을 직접 테스트해야 해요.
• 미확정 제안: EIP-8246은 2026년 10월 2일 기준 Last Call 상태이며 남은 같은 트랜잭션 ETH 소각 동작 제거를 제안합니다. 향후 네트워크 업그레이드에 포함되어 활성화되기 전에는 현재 메인넷 규칙의 근거가 아니에요.

감사자는 공개 함수 이름만 보지 말고 소스와 바이트코드 경로를 함께 찾아야 합니다. 직접 명령, 인라인 어셈블리, DELEGATECALL로 도달하는 라이브러리, 팩토리가 만든 자식, 수익자 선택과 대상 포크에서의 동작을 점검하세요.

개발자 체크리스트

• 직접 또는 위임 경로에서 SELFDESTRUCT를 실행할 수 있는 모든 지점 찾기
• 실행 컨트랙트가 같은 트랜잭션에서 생성됐는지 기록하기
• 호출 전후 코드, 스토리지, 논스와 잔액 테스트하기
• SELFDESTRUCT 가스 환급 가정 제거하기
• 트랜잭션 간 CREATE2 재배포를 업그레이드 방식으로 쓰지 않기
• 정지, 사용자 출구, 마이그레이션 또는 프록시 통제를 명시적으로 설계하기
• 지원하는 모든 EVM 체인의 포크 규칙 확인하기
• 제안 상태를 추적하되 초안 동작을 활성 합의 규칙처럼 쓰지 않기

자주 묻는 질문

현재 이더리움에서 SELFDESTRUCT는 컨트랙트를 삭제하나요?

대부분 그렇지 않습니다. 현재 트랜잭션 전에 존재한 컨트랙트라면 수익자에게 ETH를 보내고 실행 프레임을 멈추지만 코드, 스토리지와 계정은 유지해요.

같은 CREATE2 주소에 새 코드를 다시 배포할 수 있나요?

기존 컨트랙트를 한 트랜잭션에서 파괴하고 이후 트랜잭션에서 재배포하는 방식은 안 됩니다. EIP-6780 이후 코드와 논스가 남아 생성 충돌이 발생해요. 같은 트랜잭션 임시 패턴은 좁은 예외이지 일반 업그레이드 시스템이 아닙니다.

SELFDESTRUCT는 가스를 환급하나요?

아니요. EIP-3529가 환급을 제거했습니다. 조건에 맞는 스토리지 정리에는 별도 환급 규칙이 있을 수 있지만 컨트랙트 파괴는 가스 환급 전략이 아니에요.

컴파일러 설정으로 예전 동작을 되살릴 수 있나요?

아니요. 명령의 의미는 활성화된 네트워크 포크가 정합니다. 컴파일러 EVM 대상은 생성 바이트코드와 호환성에 영향을 주지만 노드가 실행하는 합의 규칙을 바꾸지 않아요.

종료를 명령 하나가 아닌 기능으로 설계하세요

EIP-6780 이후 SELFDESTRUCT는 대체로 잔액 전송과 실행 종료이며, 같은 트랜잭션 생성이라는 한 가지 예외가 있습니다. 기존 컨트랙트는 사라지지 않고 CREATE2로 여러 트랜잭션에 걸쳐 덮어쓸 수 없으며 파괴 환급도 없어요. 생명주기 통제를 직접 설계하세요. 정지는 세밀하게, 사용자 출구는 보존하고, 마이그레이션과 업그레이드 권한은 명확하게 만들어야 합니다.

이 글은 교육 목적이며 투자 조언이 아닙니다. 스마트 컨트랙트 작업은 되돌릴 수 없고 암호화폐는 변동성이 커요. 올바른 체인 규칙에서 테스트하고, 잃어도 되는 범위의 자금만 사용하며, 최신 1차 문서를 확인하고 스스로 조사하세요(DYOR).

주요 출처

• EIP-6780: SELFDESTRUCT only in same transaction
• EIP-6049: Deprecate SELFDESTRUCT
• EIP-3529: Reduction in refunds
• Solidity 문서: Deactivate and Self-destruct
• EIP-8246: Remove SELFDESTRUCT Burn (제안 상태)