이더리움 컨트랙트 크기 제한: EIP-7954가 바꾸는 것

“컨트랙트 코드 크기가 24,576바이트를 초과합니다”라는 경고는 앞으로 이더리움의 최종 경계가 아닐 수 있어요. 하지만 아직은 아닙니다. 이더리움 컨트랙트 크기 제한은 글램스테르담의 EIP-7954에 따라 늘어날 예정이에요. 개발자에게 더 큰 런타임 코드 공간을 주되 하드캡은 유지합니다. 이 글에서는 제안된 규칙을 블록체인과 EVM 기초에 연결하고, 현재 적용 중인 한도와 네트워크 업그레이드 이후의 한도를 구분해 설명할게요.

2026년 9월 19일 기준 EIP-7954의 상태는 Review예요. 글램스테르담 메타 EIP에는 Scheduled for Inclusion으로 올라가 있지만 메인넷 활성화 시각은 비어 있습니다. ethereum.org는 개발망 테스트 중이며, 확정 날짜 없이 2026년 4분기 메인넷을 예상하고 10월 6일 세폴리아 포크를 다음 이정표로 안내해요. 해당 포크가 목표 네트워크에서 활성화되기 전까지는 기존 코드 크기 규칙이 적용됩니다.

이더리움 컨트랙트 크기 제한이란?

이더리움은 새 컨트랙트가 저장할 수 있는 실행용 런타임 코드(Runtime Code)의 바이트 수를 제한해요. 현재 EIP-170 규칙에서는 초기화 과정이 0x6000바이트, 즉 24,576바이트(24 KiB)를 초과한 코드를 반환하면 컨트랙트 생성이 실패합니다.

컨트랙트를 인증된 케이스 안에 들어가야 하는 기계라고 생각해 보세요. 소스 파일, 주석, 테스트, 생성자 지침은 작업장에 함께 들어올 수 있지만 완성된 기계인 런타임 바이트코드는 케이스 안에 맞아야 설치할 수 있어요. EIP-7954는 케이스를 키우자는 제안이지, 작업장의 모든 경계를 없애자는 제안은 아닙니다.

한도는 Solidity 소스 줄 수가 아니라 바이트코드에 적용돼요. 줄 수가 비슷한 두 프로젝트도 옵티마이저 설정, 라이브러리, 상속, 리버트 문자열, 메타데이터, 컴파일러 버전에 따라 결과 크기가 크게 달라질 수 있습니다. 목표 체인에 사용할 정확한 빌드 결과물을 측정해야 해요.

EIP-7954는 무엇을 바꾸나요?

EIP-7954는 두 가지 합의 상수를 바꿉니다.

대상	현재 한도	EIP-7954 한도	증가 폭
런타임 컨트랙트 코드	24 KiB (0x6000)	64 KiB (0x10000)	약 2.67배
초기화 코드	48 KiB (0xC000)	128 KiB (0x20000)	약 2.67배

런타임 코드는 컨트랙트 주소에 저장되는 실행 바이트코드예요. **초기화 코드(Initcode)**는 생성자를 실행하고 런타임 코드를 반환하는 임시 생성 프로그램입니다. 이더리움은 두 결과물을 서로 다른 단계에서 검사하고 비용을 부과하므로 이 구분이 중요해요.

제안은 EIP-3860이 만든 관계를 유지합니다. 초기화 코드 최대 크기는 런타임 코드 최대 크기의 두 배예요. EIP-3860의 워드 단위 초기화 코드 비용, 코드 저장 비용(Code-deposit Cost), 일반 실행 가스, 다른 배포 검사를 없애지는 않습니다.

경계에서 이 차이는 분명해요. 현재 규칙에서는 24,577바이트를 반환하면 컨트랙트 생성이 실패합니다. EIP-7954가 활성화되면 24,577바이트 결과는 이 크기 검사만큼은 통과할 수 있지만, 65,536바이트를 초과하면 실패해요. 크기 검사를 통과해도 배포 성공을 보장하지는 않습니다. 생성자가 되돌리거나 가스가 부족하거나 다른 합의 규칙 또는 애플리케이션 조건을 위반할 수 있어요.

이더리움에 코드 하드캡이 있는 이유

EIP-170은 스퓨리어스 드래곤(Spurious Dragon) 때 기존 한도를 도입했어요. 근거 문서는 코드 길이에 따라 늘어나는 작업으로 디스크에서 코드 읽기, EVM 실행 전처리, 머클 증명에 코드 추가를 꼽습니다. 경계가 없다면 일정한 비용으로 책정된 호출이 노드에 더 큰 작업을 요구할 수 있어요.

항공사가 수하물 허용량을 늘리는 상황과 비슷합니다. 더 큰 허용량은 정상 승객의 불편을 줄이지만, 항공기에는 여전히 무게 제한이 필요해요. EIP-7954는 64 KiB가 복잡한 앱에 더 많은 유연성을 주면서 블록·상태·데이터베이스·P2P 비용에는 보수적인 경계를 남긴다고 봅니다.

트레이드오프는 실제로 존재해요. 큰 컨트랙트는 한 주소에 더 많은 기능을 담을 수 있지만, 노드가 저장·전송·분석·증명해야 할 최대 코드도 커집니다. 그래서 EIP 보안 항목은 서비스 거부(DoS) 노출을 새 하드캡으로 제한할 수는 있어도 완전히 없어진다고 말하지 않아요.

Solidity 개발자에게 무엇이 달라지나요?

크기 때문에 코드를 나누는 압박이 줄어요

팀은 24 KiB 아래에 맞추기 위해 로직을 라이브러리, 패싯(Facet), 모듈, 프록시 구현으로 나누기도 해요. 64 KiB 상한은 설계 여유를 넓혀 일부 배포를 단순하게 만들 수 있습니다.

그렇다고 모놀리식 컨트랙트가 자동으로 안전해지는 것은 아니에요. 작은 컴포넌트는 책임과 업그레이드 범위를 명확히 할 수 있지만 호출 경계와 거버넌스 복잡성을 늘릴 수도 있습니다. 큰 단일 컨트랙트는 호출하기 쉬울 수 있지만 검토하기 어려울 수 있어요. 최대 바이트 수만 보지 말고 보안, 유지보수성, 신뢰 조건으로 구조를 선택해야 합니다.

기존 컨트랙트가 자동으로 커지지는 않아요

이미 배포된 주소의 런타임 코드는 불변입니다. 프로토콜 한도가 늘어도 기능이 붙거나 라이브러리가 다시 연결되거나 구현이 교체되지 않아요. 업그레이드 가능한 시스템은 여전히 프록시 컨트랙트와 업그레이드 권한에 의존합니다. 업그레이드가 불가능한 시스템은 새 배포와 애플리케이션별 이전 과정이 필요해요.

배포 비용은 여전히 클 수 있어요

새 상한은 더 많은 코드를 배포할 수 있는 허용 범위이지 가스 할인은 아닙니다. 반환하는 런타임 바이트가 많을수록 일반적으로 코드 저장 작업이 늘고, 큰 생성 페이로드에는 콜데이터와 초기화 코드 비용이 따라와요. 글램스테르담에는 별도의 상태 생성·접근 가스 재책정 제안도 있으므로 현재 영수증만으로 미래 비용을 추정하면 안 됩니다. 인접한 변경은 글램스테르담 가스 재책정 가이드에서 확인해 보세요.

도구가 목표 포크를 알아야 해요

테스트넷이 새 규칙을 활성화했는데도 컴파일러나 배포 도구가 옛 한도에서 경고할 수 있어요. 반대로 로컬 개발 체인은 큰 컨트랙트를 허용하지만 목표 네트워크는 아직 거부할 수 있습니다. 모든 테스트 결과에 체인 ID, 블록 또는 포크 설정, 클라이언트 버전, 컴파일러 버전, 옵티마이저 설정, 측정한 바이트 길이를 함께 기록하세요.

실전 마이그레이션·테스트 체크리스트

1. 두 결과물을 모두 측정하세요. 전체 초기화 코드와 반환되는 런타임 코드를 16진수 글자 수가 아닌 바이트 단위로 기록합니다.
2. 현재 한도부터 통과하세요. 글램스테르담 활성화 전에 배포해야 한다면 런타임 코드는 24 KiB 이하, 초기화 코드는 48 KiB 이하로 유지합니다.
3. 포크 설정을 고정하세요. 로컬 VM 규칙이 목표 클라이언트 릴리스와 네트워크 이정표에 맞지 않으면 “글램스테르담 준비 완료”라고 판단하면 안 돼요.
4. 경계값을 시험하세요. 상황에 따라 24 KiB·64 KiB·48 KiB·128 KiB의 정확한 경계와 1바이트 초과 사례를 확인합니다.
5. 가스를 다시 추정하세요. 런타임 코드 크기뿐 아니라 트랜잭션 데이터, 초기화 코드 계량, 생성자 실행, 상태 생성, 코드 저장 비용을 포함합니다.
6. 보안 분석을 다시 하세요. 더 큰 코드는 배포에 성공하더라도 감사 범위, 제어 흐름, 특권 분기를 늘릴 수 있어요.
7. CREATE·CREATE2 팩토리를 재검증하세요. 빌드 결과가 달라지면 팩토리 가정, 솔트, 초기화 코드 해시, 중첩 생성 경로도 달라질 수 있습니다.
8. 작은 대안을 유지하세요. 메인넷 활성화와 프로덕션 클라이언트 지원이 확인될 때까지 현재 한도로 배포 가능한 구조를 남겨 두세요.

리스크와 한계

• 활성화 리스크: 2026년 9월 19일 기준 EIP-7954는 예정돼 있지만 메인넷에서 활성화되지 않았어요. 명세나 일정은 활성화 전에 바뀔 수 있습니다.
• 체인 간 차이: EVM 호환 네트워크는 각자의 포크와 한도를 선택해요. 한 체인에서 통과했다는 사실은 다른 체인의 통과를 증명하지 않습니다.
• 자원 트레이드오프: 최대 크기가 늘면 노드의 최악 조건 코드 저장, 전파, 전처리, 증명 작업도 커질 수 있어요.
• 감사 복잡성: 한 주소에 더 많은 코드를 넣으면 검토 범위가 늘고 드물게 실행되는 분기를 놓치기 쉬워질 수 있습니다.
• 배포 비용 리스크: 허용량이 커져도 대형 배포가 저렴해지거나 다른 가스 제약을 통과한다는 보장은 없어요.
• 아키텍처 리스크: 추가 공간만 믿고 모듈화를 모두 피하면 테스트와 교체가 어려운 강결합 시스템이 될 수 있습니다.
• 시장 리스크: 프로토콜 기능은 ETH 가격을 예측하지 않아요. 크립토 자산은 변동성이 크므로 잃어도 되는 범위에서만 참여하고 스스로 조사하세요.

자주 묻는 질문

이더리움 컨트랙트 크기 제한은 이미 64 KiB인가요?

2026년 9월 19일 기준 메인넷에서는 아니에요. EIP-7954는 Review 상태이며 글램스테르담에 포함 예정이지만 메인넷 활성화 시각은 없습니다. 활성화 전까지 현재 EIP-170의 24 KiB 한도가 유지돼요.

EIP-7954는 초기화 코드 제한을 없애나요?

아니요. 초기화 코드 한도를 48 KiB에서 128 KiB로 높이자는 제안입니다. EIP-3860이 구분하는 초기화 코드와 저장된 런타임 코드의 차이는 계속 중요해요.

활성화 후에는 60 KiB 컨트랙트가 모두 배포되나요?

반드시 그렇지는 않아요. 새 런타임 크기 검사는 통과할 수 있지만 초기화 코드 크기, 가스 부족, 생성자 리버트, 상태 생성 비용, 다른 합의·애플리케이션 규칙 때문에 실패할 수 있습니다.

프록시는 코드 크기 제한을 우회하나요?

각 배포 컨트랙트는 별도로 검사되므로 프록시 시스템은 로직을 여러 주소에 나눌 수 있어요. 공짜 우회는 아닙니다. 델리게이트콜(Delegatecall), 스토리지 레이아웃, 업그레이드 키, 거버넌스라는 별도의 보안 리스크가 생겨요.

개발자는 바이트코드 크기 최적화를 그만둬도 되나요?

아니요. 작은 코드는 배포 비용과 감사 범위를 줄일 수 있어요. 높은 상한은 여유 공간을 제공할 뿐, 코드 크기를 무의미한 지표로 만들지는 않습니다.

1차 출처

• EIP-7954: 최대 컨트랙트 크기 확대
• EIP-170: 컨트랙트 코드 크기 제한
• EIP-3860: 초기화 코드 제한과 계량
• EIP-7773: 글램스테르담 하드포크 메타
• Ethereum.org: 글램스테르담 로드맵
• 이더리움 실행 명세 테스트 릴리스

핵심 정리

EIP-7954는 이더리움 런타임 코드 상한을 24 KiB에서 64 KiB로, 초기화 코드 상한을 48 KiB에서 128 KiB로 높일 예정이에요. 복잡한 앱에 유용한 여유를 주면서 노드 작업에는 명시적인 경계를 남깁니다. 그렇다고 배포 가스, 아키텍처 선택, 감사, 네트워크별 활성화 확인이 사라지는 것은 아니에요.

목표 네트워크가 실제로 활성화하기 전까지 64 KiB를 글램스테르담 예정 규칙으로 다루세요. 배포 전에 최신 EIP, 클라이언트 릴리스, 포크 설정을 직접 확인해야 합니다. 이 글은 교육 목적이며 투자 조언이 아닙니다. 스마트 컨트랙트 동작은 되돌릴 수 없을 수 있고 크립토 자산은 변동성이 크므로 반드시 스스로 조사하세요(DYOR/NFA).