글램스테르담 가스 재책정: EIP-8037·EIP-8038 개발자 가이드

몇 년 동안 잘 작동한 이더리움 코드도 프로토콜의 가스 가격표가 바뀌면 실패할 수 있어요. **글램스테르담 가스 재책정(Glamsterdam Gas Repricing)**이 개발자에게 던지는 경고입니다. EIP-8037과 EIP-8038은 영구 상태를 만들고, 읽고, 쓰는 비용을 바꿔요. 이 글에서는 이 변화를 블록체인이란 무엇인가와 연결하고 메인넷 활성화 전에 무엇을 점검해야 하는지 알아봅니다.

이더리움 재단은 두 제안 모두 글램스테르담에 포함될 예정이며 현재 개발망에서 작동한다고 안내했어요. 다만 공식 EIP 페이지의 상태는 아직 Review입니다. 현재 명세를 테스트 기준으로 사용하되, 숫자를 다시 영구 상수로 박아 넣으면 안 됩니다.

글램스테르담 가스 재책정은 무엇을 바꾸나요?

이더리움 상태(State)를 모든 풀 노드가 함께 관리하는 공공 창고라고 생각해 보세요. 상자 하나를 읽는 데 일이 필요하고, 라벨을 바꾸려면 더 많은 일이 듭니다. 새 선반을 만들면 앞으로 참여할 노드까지 계속 보관해야 해요. 기존 가스표는 이런 비용 일부를 하나로 묶었고, 커진 상태 데이터베이스에서 드는 실제 작업을 충분히 구분하지 못했습니다.

EIP-8037 공식 명세는 **상태 생성(State Creation)**을 다뤄요. 새 계정, 새 스토리지 슬롯(Storage Slot), 배포된 바이트코드가 대상입니다. 상태 바이트당 비용(Cost per State Byte)을 기준으로 생성 비용을 통일하고 별도의 상태 가스(State Gas) 차원을 도입합니다.

EIP-8038 공식 명세는 **상태 접근과 쓰기(State Access and Write)**를 다룹니다. 연산 비용을 접근, 쓰기, 생성 요소로 나눠요. 웜(Warm)·콜드(Cold) 구분은 유지하지만 여러 상수가 바뀌고 계정 쓰기와 스토리지 쓰기 비용이 명시적으로 분리됩니다.

따라서 “가스가 전부 오른다”는 설명은 정확하지 않아요. 순수 연산, 이미 웜 상태인 읽기, 데이터베이스를 영구히 키우는 작업은 서로 다른 자원을 씁니다. 병목마다 비용을 더 직접적으로 매겨 상태 증가와 디스크 접근 부담을 숨기지 않으면서 블록 용량을 높이려는 설계예요.

EIP-8037은 상태 가스 차원을 어떻게 만드나요?

지금까지 개발자는 보통 가스 카운터 하나를 중심으로 생각했어요. EIP-8037은 블록 수준에서 두 자원 카운터를 제안합니다.

• 실행 가스(Execution Gas): 계산과 일반 실행 작업에 쓰는 가스
• 상태 가스(State Gas): 영구 상태를 새로 만드는 데 쓰는 가스

트랜잭션은 여전히 하나의 gas 한도를 제출하고 실제로 사용한 합산 가스를 지불해요. 내부에서는 익숙한 실행용 gas_left와 함께 상태 가스 저장고(State Gas Reservoir)를 사용합니다. 블록 수준에서는 누적 실행 가스와 누적 상태 가스를 따로 계산하고, 블록 헤더의 gas_used에는 둘 중 더 큰 값이 들어가요.

창고 비유로 돌아가 볼게요. 한 블록 안에서 계산 작업자가 많이 일할 수도 있고, 영구 선반을 설치하는 팀이 많이 일할 수도 있습니다. 어느 자원도 블록 한도를 넘을 수 없어요. 한쪽 사용량이 적다고 다른 쪽 병목이 사라지는 것은 아닙니다.

현재 명세의 상태 바이트당 비용인 CPSB는 1,530 가스예요. 기준 블록 가스 한도 1억 5천만과 연간 약 120GiB의 상태 증가 목표에서 이 값을 도출합니다. 새 스토리지 슬롯은 64 상태 바이트, 새 계정은 120바이트로 모델링하고 배포 코드는 바이트 단위로 과금해요. 아직 검토 중인 명세의 매개변수이므로 애플리케이션의 불변 상수로 취급하면 안 됩니다.

또 하나 중요한 변화가 있어요. EIP-7825의 트랜잭션 상한은 실행 차원에 적용되고, 더 큰 전체 트랜잭션 가스 한도로 상태 생성을 충당할 수 있습니다. 지갑과 RPC 노드는 단순히 고정 여유분을 더하는 대신 새로운 추정 로직을 구현해야 해요.

EIP-8038은 읽기와 쓰기 비용을 어떻게 바꾸나요?

EIP-8038에서도 한 트랜잭션의 첫 상태 접근은 **콜드 액세스(Cold Access)**이고 이후 접근은 **웜 액세스(Warm Access)**라는 기본 원리는 유지됩니다. 달라지는 것은 청구서를 조립하는 방식이에요.

비용 요소	의미	현재 Review 명세 예시
콜드 계정 접근	트랜잭션에서 계정을 처음 읽음	3,000 가스
웜 접근	같은 계정·슬롯을 다시 접근	100 가스
계정 쓰기	계정 리프 데이터를 변경	9,000 가스
스토리지 쓰기	기존 슬롯 값을 순변경	10,000 가스
액세스 리스트 주소	계정 접근을 선결제	2,900 가스
액세스 리스트 스토리지 키	슬롯 접근을 선결제	2,000 가스

현재 초안에서 콜드 스토리지 접근은 2,100 가스로 유지돼요. EXTCODESIZE와 EXTCODECOPY는 코드를 얻기 위해 두 번째 데이터베이스 읽기를 수행하므로 웜 접근 비용이 한 번 더 붙습니다.

스토리지 쓰기는 트랜잭션 시작 시점의 슬롯 값을 기준으로 순계산(Net Metering)해요. 원래 값과 다른 값으로 바꾸면 쓰기 요소를 내고, 같은 트랜잭션에서 원래 값으로 복원하면 프로토콜의 환급 상한 안에서 이 요소를 환급 카운터로 되돌릴 수 있습니다. 비어 있던 슬롯을 처음 만들었다면 EIP-8037 상태 가스도 추가돼요.

액세스 리스트를 만드는 서비스라면 EIP-2930 액세스 리스트 가이드의 계산도 다시 확인하세요. 원리는 유지되지만 기존 2,400·1,900 상수를 캐시한 코드는 제안된 글램스테르담 가격표를 반영하지 못합니다.

어떤 컨트랙트가 실패하거나 성능이 나빠질 수 있나요?

이더리움 재단의 2026년 8월 개발자 안내는 과거 메인넷 트랜잭션을 새 가격표로 재실행한 결과를 네 부류로 나눴어요. 변화 없음, 가스 사용량 등이 달라졌지만 성공, 제출 가스 한도를 높이면 성공, 한도를 크게 높여도 잠재적으로 실패하는 경우입니다. 대다수 트랜잭션은 영향을 받지 않았다고 밝혔습니다.

전체 비율보다 다음 노출 패턴을 점검하는 편이 실용적이에요.

1. 외부 호출에 고정 가스를 전달하는 코드: 예전에 정한 한도 안에서 끝나던 피호출자가 상태 접근·쓰기 비용 상승 뒤 가스 부족으로 실패할 수 있습니다.
2. transfer·send 가정: 솔리디티(Solidity)의 2,300 가스 스티펜드(Stipend)는 영구 호환성 보장이 아니에요. 수신 로직이 상태에 접근하면 연산 가격 변경의 영향을 받습니다.
3. gasleft() 분기: 재책정으로 임계점이 이동해요. EIP-8037 저장고 모델에서는 두 번의 GAS 값을 단순히 빼는 계산만으로 전체 가스 흐름을 설명하기도 어려워집니다.
4. 고정 한도의 사전 서명 트랜잭션: 서명이 유효해도 활성화된 가격표에서 가스 한도가 부족하면 복구할 수 없습니다.
5. 가스 상수를 캐시한 추정기: 지갑, 릴레이어(Relayer), RPC 미들웨어가 옛 공식을 자체 구현하면 정상 트랜잭션을 과소 추정할 수 있어요.

컨트랙트 배포와 스토리지 집약 루프는 특히 자세히 살펴보세요. 변수 이름만 보지 말고 이더리움 스토리지 슬롯 가이드로 실제 배치를 확인한 뒤 대표 상태를 테스트해야 합니다. 기존 슬롯 10개를 업데이트하는 경로와 새 슬롯 10개를 만드는 경로는 비용 구조가 달라요.

개발자를 위한 실전 테스트 체크리스트

1. 코드를 바꾸기 전에 검색하세요

이더리움 재단 안내문이 연결한 영향받는 컨트랙트 검색 도구로 먼저 분류해 보세요. 이어서 소스와 트랜잭션 생성 코드에서 gasleft(), .transfer, .send, {gas: ...}, 고정 가스 한도, 복사해 둔 옵코드 가격표를 찾습니다. 재실행 목록에 주소가 없다고 모든 미래 입력이 안전하다는 뜻은 아니에요.

2. 현실적인 상태를 재현하세요

비어 있거나 채워진 매핑(Mapping), 최초 사용자와 반복 사용자, 컨트랙트 생성, 새 계정으로의 가치 전송, 콜드·웜 접근 경로를 모두 테스트해 보세요. 포크 기반 테스트는 의도한 프로토콜 규칙을 고정하고 실제 분기를 실행할 만큼 충분한 상태를 보존해야 합니다.

3. 지정된 테스트 네트워크에서 실행하세요

공식 안내는 새 가격표를 시험할 곳으로 Platåberget 개발 테스트넷을 제시합니다. 배포하거나 자금을 넣기 전 공식 이더리움 채널에서 현재 네트워크와 클라이언트 지침을 다시 확인하세요. 개발망은 초기화될 수 있고 그 동작이 메인넷 활성화를 보장하지는 않습니다.

4. 증상만이 아니라 가정을 고치세요

제출 가스 한도를 높여 성공한다면 추정기와 사용자 화면의 한도를 업데이트하세요. 내부 호출에 고정량을 전달한다면 사용 가능한 가스를 전달하고 실패를 명시적으로 처리하는 방식이 설계상 안전한지 검토합니다. 보안 경계 역할을 하던 가스 제한을 이유 없이 지우면 안 돼요.

5. 명세 변경 뒤 다시 실행하세요

두 EIP 페이지는 현재 Review 상태입니다. 엔지니어링 기록에 EIP 리비전, 클라이언트·컴파일러 버전, 테스트 날짜를 남겨 두세요. 공개 테스트넷과 최종 클라이언트 릴리스가 나오면 활성화 전에 전체 테스트를 반복해야 합니다.

리스크와 한계

• 명세 변경 리스크: EIP-8037과 EIP-8038이 검토 중인 동안 매개변수와 경계 조건 계산이 달라질 수 있어요.
• 재실행 범위의 한계: 과거 호출만으로 미래 입력, 모든 상태 조합, 프록시 구현, 비공개 제출 트랜잭션을 대표할 수 없습니다.
• 가스 한도 리스크: 트랜잭션 한도를 높인다고 전부 소비되는 것은 아니지만, 내부 호출이 고정 가스만 전달하는 문제까지 고치지는 못해요.
• 보안 트레이드오프: 호출 방식을 바꾸면 재진입(Reentrancy), 실패 격리, 서비스 거부 공격 노출이 달라질 수 있습니다. 기존 제한을 없애기 전에 보안 목적을 확인하세요.
• 수수료 불확실성: 사용 가스는 수수료의 한 요소일 뿐이에요. 기본 수수료(Base Fee), 우선 수수료(Priority Fee), 블록 공간 수요가 실제 ETH 지불액을 결정합니다.
• 시장 리스크: 프로토콜 재책정은 ETH 미래 가격을 알려 주지 않아요. 크립토 자산은 변동성이 크므로 잃어도 생활에 지장 없는 금액만 위험에 노출하세요.

자주 묻는 질문(FAQ)

EIP-8037과 EIP-8038은 최종 확정됐나요?

이더리움 재단은 두 제안이 글램스테르담에 포함될 예정이라고 설명해요. 하지만 2026년 9월 16일 현재 공식 EIP 페이지의 상태는 Review입니다. 현재 명세로 테스트하면서 공식 포크·클라이언트 발표를 계속 확인해야 합니다.

모든 이더리움 트랜잭션이 비싸지나요?

아니요. 특정 상태 생성·접근·쓰기 연산이 대상입니다. 실제 영향은 트랜잭션의 실행 경로와 상태에 따라 달라져요. 네트워크 수수료는 블록 공간 수요에도 영향을 받습니다.

일반 ETH 보유자도 해야 할 일이 있나요?

이더리움 재단은 일반 사용자가 별도 조치를 할 필요가 없으며 업데이트된 지갑과 인프라가 추정을 처리한다고 안내합니다. 포크를 이유로 ETH 전송이나 시드 문구 입력을 요구한다면 따르지 마세요.

가스 한도만 높이면 항상 해결되나요?

아니요. 최상위 제출 한도가 부족한 트랜잭션에는 도움이 됩니다. 하지만 내부 호출 스티펜드가 고정됐거나 가스 잔량에 따라 분기하거나, 교체할 수 없는 사전 서명 트랜잭션이라면 해결되지 않을 수 있어요.

상태 가스는 두 번째 수수료 토큰인가요?

아니요. 트랜잭션은 기존 수수료 시장에서 ETH로 가스를 지불합니다. 상태 가스는 자원 한도를 위한 계산 차원이지 별도 자산이 아니에요.

마무리

글램스테르담 가스 재책정은 오래된 개발 원칙을 다시 보여 줍니다. 가스 숫자는 애플리케이션 API가 아니라 바뀔 수 있는 프로토콜 매개변수예요. EIP-8037은 영구 상태 증가 비용을 따로 계산하고, EIP-8038은 기존 상태에 접근하고 바꾸는 비용을 갱신합니다. 깨지기 쉬운 고정 상수를 제거하고, 추정기를 개선하며, 실제 상태 경로를 테스트하고, 활성화까지 공식 명세를 추적하는 것이 안전합니다.

이 글은 교육 목적이며 투자 조언이 아닙니다. 최신 EIP와 네트워크 상태를 직접 검증하고, 개발망을 신중하게 사용하며, 반드시 스스로 조사하세요(DYOR/NFA).