이더리움 히스토리 만료 완벽 정리: EIP-4444와 노드 프루닝의 의미

모든 이더리움 노드가 2015년부터 쌓인 모든 블록을 영원히 제공해야 한다면 저장 공간은 계속 늘어날 수밖에 없어요. 히스토리 만료(History Expiry)는 이 부담을 다시 나눕니다. 일반 노드는 오늘의 체인을 검증하고, 오래된 전체 기록은 별도 아카이브가 보존하는 방식이에요.

여기서 오해하기 쉬운 부분이 있습니다. 블록체인 기초에서 배운 불변 기록을 지우는 게 아니에요. 이더리움 히스토리 만료는 확정된 블록을 삭제하거나 다시 쓰지 않습니다. 실행 클라이언트(Execution Client)가 오래된 데이터를 얼마나 보관하고 P2P 네트워크에 제공해야 하는지를 바꿔요.

이더리움 히스토리 만료란 무엇인가요?

노드가 다루는 데이터 가운데 다음 두 가지를 구분해야 합니다.

• 상태(State): 새 거래를 실행하는 데 필요한 현재 스냅샷이에요. 계정 잔액과 컨트랙트 저장소 등이 포함됩니다.
• 히스토리(History): 현재 상태까지 온 과정이에요. 과거 블록 본문, 거래 목록, 영수증(Receipt) 등이 들어갑니다.

은행 계좌로 비유해 볼게요. 지금 잔액은 상태이고, 잔액이 어떻게 바뀌었는지 보여 주는 월별 거래명세서는 히스토리예요. 창구가 오늘의 송금을 처리하려면 현재 잔액은 필요하지만 모든 옛 명세서를 각 창구에 쌓아 둘 필요는 없습니다. 기록 보관소가 명세서를 따로 보존할 수 있죠.

히스토리 만료는 이런 역할 분담을 이더리움에 적용합니다. 네트워크는 계속 현재 상태와 새 블록에 합의해요. 달라지는 건 일반 실행 클라이언트가 오래된 기록을 피어(Peer)에 제공하는 기간입니다.

EIP-4444는 무엇을 제안하나요?

EIP-4444는 실행 클라이언트가 제공해야 하는 히스토리에 상한을 두는 제안입니다. 사양에는 오래된 헤더, 블록 본문, 영수증을 P2P 계층에서 약 1년의 이동 창(Rolling Window) 동안 제공하는 구조가 담겨 있어요. 그보다 오래된 데이터는 로컬에서 프루닝(Pruning)할 수 있습니다.

동기화 방식도 달라집니다. 피어가 제네시스부터 모든 블록을 제공하지 않는다면 새 노드는 기존 방식으로 전체 과거를 내려받을 수 없어요. 대신 유효한 약한 주관성 체크포인트(Weak Subjectivity Checkpoint)에서 시작해 최근 체인부터 앞으로 검증합니다.

그렇다고 1년 뒤 지갑 잔액이 사라지는 건 아닙니다. 잔액과 현재 컨트랙트 저장소는 상태 데이터예요. 오래된 트랜잭션 해시가 무효가 되는 것도 아닙니다. 핵심은 데이터 가용성(Data Availability), 즉 앱이 옛 블록이나 영수증을 요청할 때 어느 서비스가 응답하느냐예요.

실제로 적용된 범위는 어디까지인가요?

부분적인 첫 단계는 이미 진행됐습니다. 이더리움 재단은 2025년 7월 모든 실행 클라이언트가 머지 이전 히스토리 프루닝을 지원한다고 발표했어요. 운영자는 2022년 9월 지분증명 전환 이전의 블록 데이터를 제거할 수 있게 됐습니다.

재단은 이를 통해 디스크 사용량을 300~500GB 줄일 수 있고, 이더리움 노드를 2TB 디스크에 여유 있게 담을 수 있다고 설명했습니다. 다만 이것은 특정 시점을 기준으로 한 일회성 경계예요. EIP-4444가 설명하는 약 1년짜리 이동 창과는 다릅니다.

피어끼리 자신이 보유한 범위를 알려 주는 장치도 필요해요. EIP-7642는 eth/69 프로토콜에서 노드가 제공하는 블록 범위를 알리는 방식을 규정합니다. 동기화 중인 클라이언트가 보유하지 않은 데이터를 같은 피어에 반복 요청하는 일을 줄여 줘요.

현재 상황은 세 층으로 나누면 정확합니다.

구분	2026년 8월 5일 기준	실제 의미
머지 이전 프루닝	실행 클라이언트 지원	운영자가 오래된 머지 이전 블록 히스토리를 제거할 수 있음
피어 보유 범위 알림	EIP-7642로 사양화	피어가 자신이 제공하는 과거 범위를 알릴 수 있음
EIP-4444 전체 이동 창	논의·연구 진행 중	모든 일반 노드가 1년 뒤 데이터를 버린다고 가정하면 안 됨

노드 저장 공간을 줄이는 게 왜 중요한가요?

노드를 운영하면 제3자에게만 의존하지 않고 네트워크를 검증하고 거래를 제출할 수 있어요. 하드웨어 요구 사항이 계속 높아지면 가정이나 소규모 운영자의 참여가 어려워집니다. 결국 더 많은 사용자가 대형 RPC 제공자에 의존하면서 인프라가 집중될 수 있죠.

히스토리 만료는 이런 압력을 늦추려 합니다. 오래된 기록은 계속 늘어나지만, 일상적인 검증에 필요한 최근 데이터의 범위를 제한해 디스크 부담을 줄여요. 노드 운영비와 동기화·유지보수 부담을 낮추는 효과를 기대할 수 있습니다.

다만 저장 공간 감소가 곧 거래 처리량 증가를 뜻하지는 않아요. 히스토리 만료는 확장성 자체보다 데이터 보관 책임을 나누는 설계입니다. 역할 분리의 큰 그림은 모듈러 블록체인 가이드에서 이어서 볼 수 있어요.

오래된 이더리움 데이터는 어디에 보관하나요?

만료는 책임을 옮기는 것이지 보존 필요성을 없애는 게 아닙니다. 과거 히스토리는 다음 주체가 보관할 수 있어요.

1. 전체 데이터셋을 의도적으로 유지하는 아카이브 운영자
2. 과거 쿼리를 인덱싱해 제공하는 블록 탐색기와 RPC 제공자
3. 검증 가능한 체인 데이터를 보존하는 분산 저장·검색 네트워크
4. 독립 복사본을 유지하는 연구자, 기관, 커뮤니티 미러

여기서는 검증 가능성이 중요합니다. 제공자가 그럴듯한 JSON 응답만 돌려주는 것으로는 부족해요. 과거 블록 데이터는 정식 체인의 암호학적 커밋먼트와 대조할 수 있습니다. 검열 저항성이 중요한 앱이라면 여러 제공자를 쓰거나 로컬에서 검증한 스냅샷이 필요할 수도 있어요.

일반 지갑 사용자라면 이 과정이 화면 뒤에서 처리됩니다. 반면 탐색기, 세금 계산 도구, 분석 대시보드, 컨트랙트 인덱서를 만든다면 보존 정책을 명시해야 해요. 옛 영수증, 로그, 과거 컨트랙트 거래의 콜데이터를 조회할 때 일반 노드가 아니라 아카이브 소스가 필요할 수 있습니다.

리스크와 트레이드오프

과거 데이터 접근이 중앙화될 수 있어요

소수 상업 제공자만 전체 기록을 보관하면 앱은 그들의 가동 시간, 가격, 필터링 정책, 관할권에 의존합니다. 이더리움 공식 문서도 검열과 가용성 위험을 핵심 쟁점으로 짚어요.

부트스트랩에 체크포인트 가정이 생겨요

체크포인트 동기화는 효율적이지만 새 노드는 유효한 최근 체크포인트를 구해야 합니다. 아무 웹사이트의 값을 무작정 믿지 않도록 신뢰할 수 있는 배포·검증 절차가 필요해요.

앱이 조용히 실패할 수 있어요

연결된 모든 노드가 제네시스 시점 데이터까지 제공한다고 가정한 프로그램은 프루닝 경계에서 불완전한 결과를 낼 수 있습니다. 개발자는 오래된 범위 쿼리를 테스트하고 제공자 한계를 문서화하며, ‘데이터가 없음’과 ‘이 노드가 보관하지 않음’을 구분해야 해요.

히스토리·상태·파이널리티를 혼동하기 쉬워요

오래된 블록 본문을 프루닝해도 해당 블록의 확정성이 취소되거나 현재 잔액과 컨트랙트 상태가 삭제되지 않습니다. 이 층을 섞으면 “이더리움이 블록체인을 삭제한다”는 잘못된 결론이 나와요.

운영자와 개발자를 위한 체크리스트

• 저장 설정을 바꾸기 전에 실행 클라이언트의 최신 프루닝 문서를 확인하세요.
• 설정과 인증 자료를 백업하세요. 체인 히스토리는 운영 백업을 대신하지 않습니다.
• 노드나 RPC 엔드포인트가 제공할 수 있는 가장 오래된 블록을 확인하세요.
• 아카이브 쿼리 경로를 따로 설계하고 보존 경계의 실패를 모니터링하세요.
• 과거 데이터셋을 정식 블록 커밋먼트와 대조하세요.
• 옛 데이터가 필수인 앱은 독립된 대체 소스를 하나 이상 준비하세요.
• 초안 EIP가 적용됐다고 가정하지 말고 최신 이더리움 로드맵을 확인하세요.

자주 묻는 질문(FAQ)

EIP-4444가 오래된 이더리움 거래를 삭제하나요?

아니요. 일반 실행 클라이언트가 오래된 히스토리를 P2P 네트워크에 제공해야 하는 의무를 바꿉니다. 아카이브 복사본은 계속 보관하고 암호학적으로 검증할 수 있어요.

ETH 잔액이나 스마트 컨트랙트도 만료되나요?

아니요. 히스토리 만료는 오래된 헤더, 블록 본문, 영수증을 다룹니다. 현재 잔액과 활성 컨트랙트 저장소는 상태 데이터예요. 상태 만료(State Expiry)는 별도의 연구 주제입니다.

노드가 전체 기록을 계속 보관할 수도 있나요?

네. 운영자와 아카이브 서비스는 전체 히스토리를 유지할 수 있습니다. 제안은 일반 피어가 제공해야 하는 범위를 제한할 뿐, 아카이브 보관을 금지하지 않아요.

EIP-4444는 지금 적용됐나요?

약 1년짜리 완전한 이동 시스템은 아직 아닙니다. 머지 이전 히스토리 프루닝은 지원되지만, 2026년 6월 업데이트된 공식 로드맵은 전체 히스토리 만료를 연구·논의 단계로 설명합니다.

왜 모든 노드가 영원히 아카이브 역할을 하면 안 되나요?

무한히 늘어나는 저장 공간을 의무화하면 독립 검증 비용이 커집니다. 일반 노드의 폭넓은 참여를 유지하면서 충분히 다양한 아카이브가 과거 기록을 보존하도록 균형을 잡는 게 목표예요.

마무리

이더리움 히스토리 만료는 기록 삭제가 아니라 저장 책임의 재배치입니다. 머지 이전 데이터 프루닝은 이미 노드 용량을 줄이고 있지만, EIP-4444의 완전한 이동식 만료는 아직 끝나지 않았어요. 작은 일반 노드와 다양하고 검증 가능한 아카이브가 함께 존재해야 장기 설계가 성공합니다.

지갑 사용자에게는 당장 보이지 않는 변화일 수 있어요. 노드 운영자와 개발자라면 데이터 보존 경계를 인프라 설계에 명시해야 합니다. 최신 클라이언트 동작을 확인하고, 필요한 경우 아카이브 대체 경로를 준비하세요. 로드맵이 바뀔 수 있으니 반드시 스스로 조사하세요(DYOR). 이 글은 교육 목적이며 투자 조언이 아닙니다(NFA).