💾 비트코인 풀노드 용량, 코어 31이 잡아 둔 여유 공간 기준은 856GiB예요

비트코인 풀노드를 직접 돌리려고 저장장치를 고르다 보면 「몇 기가면 되나」에서 막혀요. 글마다 적힌 숫자가 다르고, 같은 숫자라도 GB인지 GiB인지 섞여 있어서예요.

그래서 노드 프로그램인 Bitcoin Core가 스스로 적어 둔 숫자를 소스에서 직접 찾아봤어요. GitHub 저장소의 파일을 2026년 9월 28일 오전 11시 15분부터 25분 사이(한국 시각)에 받아 읽었고, 글에 쓴 태그와 커밋은 모두 2026년 9월 27일 이전에 공개된 것이에요. 결론부터 적을게요.

• 최신 정식 릴리스 31.1의 소스에는 메인넷 데이터 폴더에 필요한 여유 공간 기준이 856으로 적혀 있어요. 개발자 문서가 이 값을 GiB로 재라고 하고 노드도 1024를 세 번 곱해 검사하니, 856GiB이고 10억 바이트 단위로는 약 919GB예요.
• 이 값은 체인을 실시간으로 잰 숫자가 아니에요. 동기화를 마친 노드의 폴더 크기에 5에서 10퍼센트 여유분을 얹어 메이저 릴리스 전에 정하는 가늠값이에요.
• 프루닝(오래된 블록 파일 삭제)을 켜면 기준은 체인스테이트 14GiB에 프루닝 목표를 더한 값이고, 목표의 하한은 550MiB예요.
• 다음 버전의 릴리스 후보인 32.0rc1과 rc2에는 897이 들어 있어요. 조회 시각까지 32.0 정식판은 나오지 않았어요.
• 31.1의 첫 실행 경고 문구와 그래픽 화면은 이 값에 GB라는 단위를 붙여요. 경고 문구를 GiB로 고치는 수정은 개발 브랜치에만 합쳐졌고, 그래픽 화면은 그 수정에 들어 있지 않아요.

소스에 적힌 값은 856과 14예요

값은 src/kernel/chainparams.cpp 의 메인넷 설정(CMainParams)에 들어 있어요. v31.1 태그 파일의 해당 줄은 이래요.

nPruneAfterHeight = 100000;
m_assumed_blockchain_size = 856;
m_assumed_chain_state_size = 14;

두 값의 뜻은 헤더 파일 chainparams.h 의 주석에 적혀 있어요. 앞의 값은 「데이터 폴더에 필요한 최소 여유 공간」이고, 뒤의 값은 「프루닝했을 때 데이터 폴더에 필요한 최소 여유 공간이며 프루닝 목표는 포함하지 않는다」예요.

주석에는 최소라는 말이 들어 있지만, 이 값을 정하는 절차를 적은 개발자 문서 release-process.md 는 조금 더 조심스럽게 적어요. 두 값은 사용자 드라이브에 전체적으로 얼마가 필요한지 가늠하는 기준이고, 블록체인만 딱 잰 값이 아니라고요.

856은 GiB로 재는 값이에요

GB와 GiB는 이름이 비슷하지만 크기가 달라요. 코어 소스 안에서도 두 단위가 따로 쓰여요.

개발자 문서의 계산 규칙은 「이 폴더들의 크기를 GiB로 재라」고 적어요. 노드 초기화 코드인 init.cpp 도 이 값에 1024 * 1024 * 1024 를 곱해서 바이트로 바꾼 뒤 검사해요. 그래서 856은 856GiB로 읽는 게 맞고, 10억 바이트 단위로 바꾸면 약 919.12GB예요. 같은 방식으로 14GiB는 약 15.03GB예요.

그런데 31.1의 표기는 이와 어긋나요. 헤더 주석은 단위를 「in GB」로 적고, 첫 실행 경고 문구도 「Approximately %u GB of data will be stored in this directory」의 숫자 자리에 856을 넣어요.

이 불일치를 고친 것이 PR #35948이에요. 이 PR은 문제를 「기준값은 GiB로 관리되는데 첫 실행 경고는 GB라고 표시한다」고 적었고, 2026년 9월 26일 오전 5시 47분(한국 시각)에 개발 브랜치(master)에 합쳐졌어요. 다만 조회 시각 기준으로 32.0 릴리스 후보 두 개와 32.x 브랜치에는 GB 표기가 그대로 남아 있었어요. 그러니 31.1이나 32.0 후보의 첫 실행 경고에서 856GB나 897GB라는 문구를 보더라도, 그 경고가 실제로 검사하는 크기는 GiB 기준이에요. 그래픽 화면은 계산 방식이 또 달라서 아래에 따로 적었어요.

이 숫자는 체인을 잰 값이 아니에요

release-process.md 에 적힌 계산 규칙을 옮기면 이래요.

1. 동기화를 모두 마친 노드에서 잰다.
2. 메인넷은 데이터 폴더 전체 크기를 재되, 테스트넷·시그넷·레그테스트 폴더와 지나치게 큰 로그 파일(debug.log 같은 것)은 뺀다.
3. 잰 값에 5에서 10퍼센트의 여유분을 얹는다.
4. 이 갱신은 메이저 릴리스를 내기 전에 하는 체크리스트에 들어 있다.

규칙대로라면 856은 31.0이 나오기 전 어느 시점의 폴더 크기에 여유분을 더한 값이에요. 규칙대로 5에서 10퍼센트를 얹었다고 가정하고 거꾸로 나누면 잰 값은 약 778GiB에서 815GiB 사이가 돼요. 하지만 실제로 몇 퍼센트를 얹었는지는 커밋에 적혀 있지 않아 확인하지 못했어요. 측정한 노드가 거래 색인(txindex) 같은 선택 기능을 켜 두었는지도 문서에 서술이 없어요.

이 값은 같은 계열의 유지보수판에서는 바뀌지 않아요. 31.0(2026년 4월)과 31.1(2026년 7월)은 둘 다 856이에요. 2026년 7월 10일에 함께 나온 이전 계열 유지보수판을 열어 보면 30.3은 810, 29.4는 720을 그대로 적고 있어요. 두 유지보수판을 쓰는 사람이 보는 숫자는 각 계열의 첫 판(30.0, 29.0)과 같은 옛 값이라는 뜻이에요.

같은 856이 쓰이는 곳마다 다르게 계산돼요

v31.1 소스에서 이 값이 쓰이는 곳은 두 군데예요. 같은 숫자를 서로 다르게 다뤄서, 실제로 비교하는 크기가 약 49GB 차이 나요.

초기화 코드의 검사는 체인 높이가 1 이하인 첫 실행에서, 재색인 중이 아닐 때만 돌아요. 블록 폴더가 있는 드라이브의 남은 공간이 기준보다 적으면 경고를 띄우는데, 코드는 경고만 띄우고 이 자리에서 실행을 멈추지는 않아요.

그래픽 버전의 화면은 기본 데이터 폴더가 아직 없거나 폴더를 다시 고르도록 설정했을 때 뜨는 폴더 선택 화면이에요. 화면 설명 문구는 856을 「전체 블록체인(856 GB)」처럼 넣고, 필요 공간은 체인스테이트 14를 더한 870으로 계산하되 GB를 10억 바이트로 셈해요. 870GB는 약 810.25GiB라서 초기화 코드의 기준보다 작아요. 사용자가 프루닝을 따로 정하지 않았다면, 남은 공간이 880GB(856과 14에 10을 더한 값)보다 적을 때 프루닝 체크박스가 자동으로 켜지는 것도 이 화면의 동작이에요.

두 계산을 나란히 놓으면, 여유 공간이 880GB에서 919GB 사이인 드라이브는 그래픽 화면의 기준은 넘고 초기화 코드의 기준에는 못 미쳐요. PR #35948은 초기화 코드 쪽만 고쳤고 그래픽 화면 파일(intro.cpp)은 건드리지 않았어요.

릴리스마다 얼마씩 늘었나

태그마다 같은 파일을 열어 메인넷 값만 옮겼어요. 날짜는 GitHub 릴리스 게시일이고, 24.0과 32.0 후보는 릴리스 항목이 없어 태그 날짜로 적었어요.

단위는 버전에 따라 확인되는 정도가 달라요. 「GiB로 재라」는 개발자 문서의 문장은 24.0 태그부터 들어 있어요. 22.0과 23.0 당시 문서는 「데이터 폴더의 크기를 재라」고만 적어 단위가 없었고, 헤더 주석은 GB로 적었어요. 그래서 두 행은 소스의 숫자만 옮겼어요.

단위가 확인되는 24.0에서 31.0까지 메이저 릴리스 일곱 단계 동안 전체 기준은 496에서 856으로 360GiB 늘어 약 1.73배가 됐어요. 한 단계에 평균 약 51.4GiB씩이에요. 폭은 고르지 않아서 26.0에서 27.0 사이는 10GiB, 28.0에서 29.0 사이는 100GiB였어요. 표에 적은 22.0부터 32.0 후보까지 숫자가 줄어든 단계는 없었어요.

다만 이 차이를 체인이 실제로 늘어난 양으로 읽으면 안 돼요. 얹는 여유분이 5에서 10퍼센트로 폭이 있고, 재는 시점도 릴리스마다 달라요.

개발 브랜치의 값은 2026년 9월 9일에 작성된 커밋 「kernel: update assumed blockchain and chainstate sizes」가 9월 11일 PR #36196으로 합쳐지면서 856에서 897로 바뀌었어요. 이 값은 9월 14일과 18일에 태그된 32.0 릴리스 후보 두 개에 들어 있어요. 정식판에 어떤 값이 들어갈지는 조회 시각 기준으로 정해지지 않았어요.

프루닝을 켜면 얼마나 줄어드나

프루닝은 오래된 블록 파일을 지우면서 노드를 돌리는 방식이에요. 그래픽 화면의 설명 문구대로라면 프루닝을 켜도 과거 데이터는 한 번 전부 내려받아 처리한 뒤에 지워요. 내려받는 양이 줄어드는 게 아니라 남겨 두는 양이 줄어드는 거예요. -prune 옵션에 MiB 단위 숫자를 넣고, 31.1 도움말이 적은 값의 뜻은 이래요.

550MiB라는 하한의 계산은 validation.h 주석에 적혀 있어요. 블록 하나를 1MB로 치면 288블록이 288MB이고, 되돌리기 데이터 15퍼센트와 고아 블록 비율 20퍼센트를 얹으면 397MB가 돼요. 블록 파일을 128MB 덩어리로 지우는 구조라 한 덩어리와 그 되돌리기 데이터분 147MB를 더하면 545MB이고, 그래서 550MiB 이상이면 목표를 지킬 가능성이 높다는 설명이에요.

프루닝 노드에 필요한 공간은 헤더 주석대로라면 체인스테이트 기준 14GiB에 프루닝 목표를 더한 값이에요. 목표를 하한인 550MiB(약 0.54GiB)로 잡으면 합계는 약 14.5GiB예요.

그래픽 버전의 폴더 선택 화면은 프루닝 목표 기본값을 2GB로 보여 줘요. 이때 필요 공간 표시는 2와 14를 더한 16GB예요. 같은 화면은 이 목표로 「약 6일 전 백업까지 복원할 수 있다」는 문구도 계산해 붙이는데, 코드가 블록 하나의 데이터를 되돌리기 데이터 포함 2,250,000바이트로 잡고 나눈 값이에요.

짚어 둘 점이 하나 있어요. 초기화 코드의 첫 실행 검사는 프루닝 모드일 때 프루닝 목표와 856GiB 가운데 작은 쪽만 보고, 체인스테이트 14GiB는 더하지 않아요. 그런데 31.1의 경고 문구는 프루닝 중에도 856을 그대로 표시해요. PR #35948은 이 부분도 검사에 실제로 쓴 값을 표시하도록 고쳤어요(개발 브랜치 기준).

프루닝에는 조건도 붙어요. -prune 도움말은 이 설정을 되돌리려면 블록체인 전체를 다시 내려받아야 한다고 경고해요. 또 31.1 코드는 프루닝을 -txindex, -txospenderindex 와 함께 켜면 오류로 멈추고, -reindex-chainstate 대신 전체 재색인(-reindex)을 쓰라고 안내해요. 옵션 전체 목록과 도움말에 안 나오는 옵션은 비트코인 노드 설정 옵션을 전부 센 글에서 따로 다뤘어요.

저장장치 용량과 비교하는 법

저장장치에 적힌 용량과 코어의 기준을 비교하려면 단위부터 맞춰야 해요. 1TB를 10의 12제곱 바이트로 계산하면 약 931.32GiB예요. 여기서 856GiB를 빼면 약 75GiB가 남고, 32.0 후보 값 897GiB를 빼면 약 34GiB가 남아요. 운영체제나 다른 파일을 같은 드라이브에 두면 남는 공간은 그만큼 줄어요.

이 계산은 코어가 적어 둔 기준값끼리 비교한 것이에요. 이 글은 지금 체인의 실제 크기를 재지 않았고, 앞으로 얼마나 늘어날지도 예측하지 않아요. 특정 제품을 추천하지도 않아요. 표에서 확인되는 것은 이 기준값이 메이저 릴리스마다 줄지 않고 늘어 왔다는 사실까지예요.

노드 프로그램을 새로 내려받는다면 버전 폴더 구성과 체크섬 서명 확인 방법을 비트코인 코어 배포 목록을 센 글에 정리해 두었어요.

확인된 것과 확인하지 않은 것

정리하면, 코어 31이 풀노드 한 대에 잡아 둔 여유 공간 기준은 856GiB이고 10억 바이트 단위로는 약 919GB예요. 이 숫자는 여유분을 얹은 가늠값이고 같은 계열(31.0과 31.1) 안에서는 고정돼 있어요. 프루닝을 켜면 기준이 14GiB와 프루닝 목표 수준으로 내려가지만, 되돌리려면 체인 전체를 다시 받아야 해요.

이 글은 매매 권유가 아닌 정보 제공 글이에요. 가상자산은 변동성이 크고 원금 손실 위험이 있으며, 투자 판단은 본인 책임이에요.