프루닝 비트코인 노드: 저장공간을 줄여도 검증은 가능한가

프루닝 노드는 블록과 거래를 먼저 내려받아 합의 규칙대로 검증하고 UTXO 집합과 블록 인덱스를 갱신한 뒤, 설정한 저장 목표를 넘는 오래된 원시 블록과 undo 데이터를 삭제합니다. 따라서 현재 체인의 유효성을 스스로 검증하는 성격은 유지되지만, 삭제된 과거 블록의 상세 조회와 그 구간을 다시 읽어야 하는 지갑 재스캔은 제한됩니다. 프루닝은 검증 생략 기능이 아니라 검증 후 보관 범위를 줄이는 기능입니다.

프루닝은 검증을 건너뛰는 절약 모드가 아닙니다

새 블록을 받은 노드는 작업증명, 거래 형식, 스크립트와 이중 지출 여부 같은 합의 규칙을 확인합니다. 프루닝을 켜도 이 검증 과정은 먼저 수행됩니다. 검증 결과로 현재 미사용 출력 집합과 체인 상태를 만든 다음, 더 이상 상시 보관할 필요가 없는 오래된 blk·rev 파일을 저장 목표에 맞춰 지웁니다. 그래서 ‘블록을 보지 않고 다른 노드를 믿는다’는 의미의 경량 검증과는 구분해야 합니다.

Bitcoin Core의 초기 프루닝 설명은 원시 블록, undo 데이터, 블록 인덱스, UTXO 데이터베이스를 서로 다른 자료로 나눕니다. 오래된 원시 자료가 사라져도 블록 인덱스에는 체인 전체의 메타데이터가 남고 UTXO 집합은 현재 유효한 지출 가능 출력을 유지합니다. 저장 공간 절감은 검증 결과를 버리는 것이 아니라 검증에 사용한 원본 중 오래된 구간의 상시 보관을 포기하는 선택입니다.

프루닝의 핵심은 ‘덜 검증’이 아니라 ‘검증한 원본을 얼마나 오래 들고 있을지’의 결정입니다.

JOBCOIN 해설

VISUAL GUIDE프로토콜 실행의 기본 구조

1. 01
   프루닝은 검증을 건너뛰는 절약 모드가 아닙니다

   새 블록을 받은 노드는 작업증명, 거래 형식, 스크립트와 이중 지출 여부 같은 합의 규칙을 확인합니다.

2. 02
   남는 데이터와 사라지는 데이터를 따로 봅니다

   프루닝 상태에서도 노드는 최신 블록을 받아 현재 체인 끝까지 따라가고 새 거래를 검증할 수 있습니다.

3. 03
   지갑 재스캔은 키가 아니라 블록 자료의 문제이기도 합니다

   백업한 디스크립터나 키를 지갑에 가져오는 것만으로 과거 잔액이 즉시 완성되는 것은 아닙니다.

AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.

남는 데이터와 사라지는 데이터를 따로 봅니다

프루닝 상태에서도 노드는 최신 블록을 받아 현재 체인 끝까지 따라가고 새 거래를 검증할 수 있습니다. getblockchaininfo의 pruned, pruneheight, size_on_disk 같은 필드는 현재 설정과 보관 하한을 확인하는 출발점입니다. pruneheight 아래의 블록 해시 메타데이터를 안다는 사실과 그 블록의 전체 거래 본문을 로컬 디스크에서 다시 읽을 수 있다는 사실은 같지 않습니다.

삭제된 블록을 요구하는 getblock 계열 호출이나 과거 거래 조회는 자료가 없다는 오류를 낼 수 있습니다. txindex도 오래된 원시 블록이 필요한 용도와 충돌할 수 있으므로 운영 목적을 먼저 정해야 합니다. 단순히 개인 지갑의 최신 입출금과 체인 검증이 목적일 때와, 오래된 거래를 임의로 조회해 주는 탐색기·분석 API를 운영할 때의 보관 요구는 다릅니다.

지갑 재스캔은 키가 아니라 블록 자료의 문제이기도 합니다

백업한 디스크립터나 키를 지갑에 가져오는 것만으로 과거 잔액이 즉시 완성되는 것은 아닙니다. 지갑은 해당 스크립트와 일치하는 과거 거래를 블록에서 다시 찾아야 합니다. 키의 생성 시각이 pruneheight보다 훨씬 앞선다면 필요한 원시 블록이 이미 없을 수 있습니다. 이때 빈 잔액 화면을 키 오류로 단정하기 전에 재스캔 시작 높이와 로컬 보관 범위를 대조해야 합니다.

Bitcoin Core의 rescanblockchain은 지정한 시작 높이부터 지갑 관련 거래를 찾습니다. 디스크립터 가져오기에서도 timestamp는 어디부터 살펴볼지 결정하는 중요한 입력입니다. 너무 늦은 시각을 넣으면 오래된 수신을 놓칠 수 있고, 너무 이른 시각을 넣으면 프루닝 노드가 보유하지 않은 구간까지 요구하게 됩니다. 복구 계획에는 시드뿐 아니라 지갑 종류, 디스크립터, 대략적인 최초 사용 시점도 함께 남기는 편이 안전합니다.

• getblockchaininfo에서 pruned와 pruneheight를 기록합니다.
• 복구할 지갑의 최초 사용 시점 또는 블록 높이를 확인합니다.
• 재스캔 범위가 로컬 보관 구간 안인지 먼저 비교합니다.
• 탐색기·인덱서 용도라면 과거 원문 조회 요구를 별도로 적습니다.
• 비프루닝 전환 전 전체 재다운로드 시간과 여유 디스크를 계산합니다.

저장 목표값은 전체 노드 디스크 사용량의 상한이 아닙니다

prune 값은 주로 블록과 undo 파일에 적용되는 목표입니다. 블록 인덱스, chainstate, 지갑 파일, 로그, 선택한 추가 인덱스 등 다른 데이터는 별도로 공간을 사용합니다. 따라서 설정 숫자만 보고 디스크가 그 크기를 절대 넘지 않는다고 예상하면 운영 중 공간 부족을 맞을 수 있습니다. 최신 블록과 안전한 재구성 처리를 위해 목표보다 일시적으로 더 쓰는 상황도 고려해야 합니다.

노드가 막 설치된 상태라면 초기 동기화 중에도 블록을 검증하고 오래된 파일을 순차적으로 정리합니다. 다운로드 총량이 프루닝 목표만큼으로 줄어드는 것은 아닙니다. 네트워크를 통해 과거 체인을 받아 검증해야 하므로 대역폭과 CPU 부담은 여전히 큽니다. 줄어드는 핵심 자원은 동기화 후 상시 보관할 원시 블록 공간입니다.

운영 목적을 기준으로 프루닝 여부를 선택합니다

개인 검증 노드에서 디스크가 제한되고 오래된 임의 블록을 서비스할 필요가 없다면 프루닝은 실용적일 수 있습니다. 반면 블록 탐색기 백엔드, 연구용 전체 기록, 여러 오래된 지갑의 수시 재스캔, 다른 노드에 광범위한 과거 블록을 제공하는 용도라면 전체 보관이 더 맞습니다. ‘풀 노드인가’라는 한 단어보다 어떤 데이터를 직접 검증하고 어떤 조회를 제공해야 하는지가 선택 기준입니다.

설정을 바꾸기 전에는 데이터 디렉터리 백업과 여유 공간을 확인하세요. 이미 삭제한 과거 블록은 설정을 끄는 것만으로 돌아오지 않으며 다시 내려받고 검증해야 합니다. 디스크 장애 때문에 reindex가 필요한 경우에도 프루닝된 자료만으로 전체 복구가 되지 않을 수 있습니다. 장애 복구 시간을 감당할 수 있는지까지 포함해야 저장 절감의 실제 비용을 알 수 있습니다.

상태 화면은 세 가지 질문으로 판독합니다

첫째, initialblockdownload가 끝났는지 확인합니다. 둘째, headers와 blocks 차이가 줄고 있는지 봅니다. 셋째, pruned와 pruneheight로 보관 범위를 확인합니다. 이 세 질문은 각각 동기화 상태, 검증 진행, 과거 자료 보관을 다룹니다. 프루닝 표시 하나만으로 노드가 최신인지 또는 지갑 잔액이 완전한지 결론 내리면 안 됩니다.

문제가 생겼다면 로그의 마지막 진행 높이, 디스크 여유, 네트워크 연결, 지갑 스캔 상태를 같은 시각 기준으로 남기세요. 그래야 느린 초기 동기화와 보관 자료 부족, 지갑 인식 실패를 구분할 수 있습니다. 프루닝 노드의 안전성 평가는 저장 숫자가 아니라 최신 체인 검증이 정상인지와 필요한 과거 기능을 충족하는지로 해야 합니다.

자주 묻는 질문