📈 비트코인 코어 배포 목록을 세어 보니 버전 64개와 위험 표시 폴더 4개였어요

비트코인 코어를 받으러 공식 배포 폴더에 들어가면 생각보다 볼 것이 많아요. 버전 번호가 줄줄이 늘어서 있고, 그 사이에 이름부터 심상치 않은 폴더가 섞여 있어요.

파일 하나만 고르면 끝날 줄 알았는데 막상 서너 가지가 한꺼번에 걸려요. 어느 폴더가 최신인지, 옆에 나란히 놓인 체크섬 파일과 서명 파일은 왜 두 개인지, 목록에 이름은 있는데 눌러도 안 열리는 것은 무슨 뜻인지요.

그래서 그 배포 목록을 그대로 세어 봤어요.

이 글이 재는 자리를 먼저 못박을게요. 인증 없이 열리는 공개 배포 경로를 파이썬 표준 라이브러리로 받아, 목록 페이지와 그 안의 체크섬 파일과 서명 파일을 원본 바이트 그대로 저장해 셌어요. 조회 시각은 2026년 9월 9일 오전 10시 40분부터 10시 46분까지(한국 시각) 이고 요청 사이에 1초 남짓을 쉬었어요. 프로그램을 설치하거나 실행하지 않았고 매매 권유가 아니에요.

블록 데이터가 아니라 파일 서버라서 시각을 못박아야 해요

먼저 밝혀 둘 게 있어요. 이건 블록체인에서 읽어 온 값이 아니에요. 블록 높이처럼 누구나 같은 자리를 가리킬 수 있는 눈금이 없고, 파일을 올리거나 정리하면 그대로 바뀌는 파일 서버의 상태예요.

그래서 조회 시각을 못박고, 흔들리는지도 확인했어요. 같은 주소 세 개를 4분 뒤에 다시 받아 원본 바이트끼리 비교했어요.

여기서 제가 한 번 잘못 셌던 것도 적어 둘게요. 처음 비교할 때 저장한 파일을 텍스트 모드로 읽어 다시 인코딩했더니 목록 페이지만 「바뀌었다」고 나왔어요. 원인은 이 파일의 줄바꿈이 CR과 LF 두 글자로 되어 있고, 그 CR 74개를 텍스트 모드 읽기가 지워 버려서 8,585바이트가 8,511바이트로 줄어든 것이었어요. 바이너리로 다시 읽어 비교하니 완전히 같았어요.

그러니 위 표의 「같음」은 바이너리 비교 결과예요. 도구를 한 번 갈아 봤더니 없던 차이가 생겨 보였던 자리라, 숨기지 않고 적어 둬요.

목록에 적힌 폴더는 68개, 그중 64개가 버전 폴더였어요

배포 목록 페이지 하나에서 링크를 뽑아 셌어요. 정규식으로 만든 파서와 별도의 문자열 검색으로 두 번 세어 값을 맞춰 봤어요.

옛 번호와 새 번호가 32개씩으로 정확히 반이에요. 우연이지만 눈에 잘 들어오는 자리예요.

새 번호 32개를 세대별로 갈라 보면 이래요. 합계는 손으로 더해 32개인지 다시 맞췄어요.

한 줄만 모양이 달라요. 30 세대만 30.2부터 시작해요. 30.0과 30.1이 이 목록에 없어요. 이 자리가 뒤에서 다시 나와요.

목록 페이지는 폴더마다 갱신 시각도 같이 적어 둬요. 릴리스 발표일이 아니라 파일이 올라온 시각이에요.

번호가 높은 것이 먼저 올라오고 낮은 세대가 하루씩 뒤에 올라왔어요. 여러 세대를 나란히 손보고 순서대로 올린 흔적으로 읽히는데, 여기서 더 나가지는 않을게요. 시각 표기까지가 이번에 잰 값이에요.

이름은 4개인데 실제 내용은 3가지였어요

이름에 insecure가 붙은 폴더 4개를 각각 열어 봤어요.

여기서 대조를 하나 했어요. 위의 두 폴더는 목록 HTML에서 폴더 이름 부분만 바꿔 놓고 비교하면 완전히 같아요. 그러니 이름은 4개지만 서로 다른 묶음은 3가지예요.

세 묶음 사이에 겹치는 버전은 없었어요. 그리고 22개 중 5개는 본 목록에도 그대로 있어요. 같은 버전이 두 자리에 동시에 놓여 있는 셈이라, 「여기 있으니 저기엔 없겠지」로 넘겨짚으면 어긋나요.

설명 파일 내용도 그대로 옮겨 둘게요.

첫 번째 묶음의 설명 파일은 2015년에 공개된 취약점 하나를 가리키면서, 문제가 집 앞 공유기와 포트를 자동으로 여는 기능에 쓰이는 외부 라이브러리의 XML 파서 버퍼 오버플로라고 적었어요. 미리 빌드해 배포한 실행 파일 안에 그 라이브러리가 함께 들어 있어서 생긴 문제이고, 최신 라이브러리로 직접 빌드하면 피할 수 있다고 덧붙였어요. 영향 범위는 원문에 부등호로 적혀 있는데, 뜻으로 옮기면 0.10.3 미만과 0.11.1 미만이에요.

두 번째 묶음의 설명 파일은 훨씬 짧아요. 126바이트짜리 두 문장이고, 이 폴더의 배포본이 특정 취약점에 노출된다고만 적혀 있어요.

세 번째 묶음에는 설명 파일이 아예 없어요. 흔히 쓰이는 이름 두 가지를 모두 요청했는데 둘 다 HTTP 404였어요. 그러니 이 폴더에 대해서는 폴더 이름 말고 근거로 삼을 문서가 그 자리에 없다는 것이 이번 관측이에요.

옮겨진 것과 지워진 것은 다른 말이에요

앞에서 30 세대만 30.2부터 시작한다고 했죠. 그 두 번호를 본 경로에서 직접 눌러 봤어요.

404를 보고 「없어졌다」로 읽으면 틀려요. 자리를 옮겼을 뿐이고, 옮겨진 자리에서는 파일 32개가 체크섬 파일까지 갖춰 그대로 열려요. 파일 구성만 놓고 보면 같은 세대의 30.2와 항목 수도 용량도 같아요.

그래서 이 절의 결론은 두 줄이에요. 첫째, 본 경로의 404는 삭제가 아니라 이동이었어요. 둘째, 왜 옮겼는지는 이 조사로 알 수 없어요. 그 폴더에는 사유를 적은 문서가 없었고, 폴더 이름 하나가 유일한 단서예요. 이름만 보고 사정을 특정해 적는 것은 이 글이 하지 않을 일이에요.

최신 폴더 하나를 통째로 세어 봤어요

가장 높은 번호인 31.1 폴더를 항목 단위로 셌어요.

빠진 4개가 무엇인지가 중요해요. 체크섬 목록 자신과 그 서명 파일, 타임스탬프 파일, 토렌트 파일이에요. 즉 실제로 내려받아 쓰는 프로그램 파일은 하나도 빠짐없이 목록에 들어 있고, 빠진 것은 목록 자신과 그 부속 파일뿐이에요.

용량 구성도 갈라 봤어요.

대부분의 사람이 실제로 받는 파일 하나는 폴더 전체의 1퍼센트도 안 돼요. 폴더가 5 GiB를 넘는다고 해서 받을 것이 그만큼이라는 뜻이 아니에요. 진단용 파일 6개가 덩치의 대부분이에요.

체크섬 파일의 줄 형식도 확인했어요. 28줄 전부가 소문자 16진수 64자리 다음에 공백 두 칸, 그다음 파일 이름 형식이었고 어긋난 줄은 0개였어요.

그리고 실제로 하나를 받아 맞춰 봤어요.

여기에 유보를 바로 붙일게요. 용량 때문에 전부는 못 받았고 체크섬 목록에 이름이 있는 28개 중 가장 작은 1개만 실제로 내려받아 대조했어요. 나머지 27개는 대조하지 않았어요. 그러니 이 표는 「형식이 실제로 맞아떨어지더라」의 사례 한 건이지, 28개가 모두 맞는다는 확인이 아니에요.

주소에 한 글자만 잘못 들어가도 값이 통째로 달라지는 성질은 지갑 주소 쪽에서도 똑같이 쓰여요. 그 원리를 자릿수로 확인해 본 이야기는 체크섬 쪽 글에 따로 적어 뒀어요.

체크섬 목록은 내려받을 목록이 아니라 만들었을 때의 기록이에요

이번 조사에서 제일 걸린 자리예요. 2021년에 배포된 22.0과 최신 31.1을 같은 방식으로 세어 나란히 놓아 봤어요.

아래 두 줄을 보세요. 22.0의 체크섬 파일은 23개를 부르는데 실제로 남아 있는 것은 11개예요. 나머지 12개는 이름만 남았어요.

사라진 12개가 어떤 성격인지도 봤어요. 이름으로 갈라 보니 12개 중 7개가 용량이 큰 진단용 파일이고, 나머지는 서명 전 단계의 중간 산출물 계열이에요. 최신 31.1에 debug 파일이 6개 남아 있는 것과 대비돼요.

여기서 오해가 갈리는 자리를 못박을게요. 체크섬 파일은 그 릴리스를 만들었을 때 무엇이 있었는지의 기록이고, 지금 내려받을 수 있는 것의 목록이 아니에요. 옛 버전을 받으려다 목록에 이름이 있는데 눌리지 않는다면, 목록이 잘못된 것도 서버가 고장 난 것도 아니라 그 사이에 파일이 정리된 거예요.

다만 왜 지워졌는지는 이 데이터로 알 수 없어요. 용량 때문인지 다른 사정인지 이번 조사는 확인하지 않았어요. 확인한 것은 지금 몇 개가 남아 있는지까지예요.

서명 파일 하나만으로는 검증이 안 돼요

체크섬 파일 옆에는 이름이 같고 확장자만 다른 서명 파일이 놓여 있어요. 네 릴리스에서 이 파일을 받아 안의 패킷을 직접 뜯어 셌어요.

먼저 형식이에요. 서명 종류는 네 릴리스 모두 분리형 문서 서명 하나뿐이었고, 본문을 서명 안에 감싸 넣는 방식은 한 건도 없었어요. 그래서 이 파일 하나만 받아서는 아무것도 확인할 수 없어요. 체크섬 목록 파일과 서명 파일을 둘 다 받아 짝을 지어야 해요. 받는 쪽에서 파일 하나를 빼먹기 쉬운 자리라 따로 적어 둬요.

해시와 공개키 알고리즘도 세어 봤어요. 22.0은 13건 중 12건이 SHA-256이고 1건만 SHA-512였어요. 29.4와 30.3은 전부 SHA-256이고, 31.1도 전부 SHA-256인데 공개키 쪽에서 한 건만 다른 방식이었어요. 나머지는 모두 같은 계열이에요.

31.1의 서명 11건이 만들어진 시각은 협정세계시 기준 2026년 7월 7일 00시 09분부터 같은 날 19시 35분 사이예요. 폭이 19.4시간이에요. 시각이 제각각이라는 것은 한자리에서 몰아 찍은 모양이 아니라는 뜻으로 읽히는데, 여기서 더 나가지는 않을게요.

서명한 키가 릴리스마다 같은지도 봤어요. 지문 문자열을 기준으로 집합을 비교했어요.

마지막 줄이 재미있어요. 개수만 보면 11개로 같은데 안을 들여다보면 구성이 달라요. 개수가 같다고 같은 사람들이라고 읽으면 안 되는 자리예요.

네 릴리스 전부에 서명한 키 5개의 지문은 이래요.

• 0AD83877C1F0CD1EE9BD660AD7CC770B81FD22A8
• 152812300785C96444D3334D17565732E08E5E41
• 637DB1E23370F84AFF88CCE03152347D07DA627C
• CFB16E21C950F67FA95E558F2EEB9F5CC09526C1
• D1DBF2C4B96F2DEBF4C16654410108112E7EA81F

여기서 이 글의 선을 분명히 그을게요. 서명 11건이 실제로 유효한지는 확인하지 않았어요. 공개키를 내려받지 않았고 검증도 돌리지 않았어요. 그리고 이 지문들의 주인이 누구인지도 확인하지 않았고, 이 글은 누구의 이름도 적지 않아요. 이번에 센 것은 파일에 들어 있는 서명 패킷의 개수와 발행자 지문 문자열까지예요.

그러니 위 표는 「서명이 몇 개 붙어 있나」의 관측이고 「누가 무엇을 보증했나」의 관측이 아니에요. 두 문장은 아주 다른 말이에요.

릴리스 후보 폴더는 번호가 이어지지 않는 곳이 있어요

각 릴리스 폴더 안에는 후보판을 담은 하위 폴더가 있어요. 이번에 연 폴더들만 놓고 보면 번호가 1부터 이어지지 않는 경우가 있었어요.

두 줄이 중간을 건너뛰어요. 빠진 번호가 왜 없는지는 확인하지 않았어요. 후보판이 만들어졌다가 정리된 것인지, 애초에 그 번호가 쓰이지 않은 것인지 이 데이터로는 갈라낼 수 없어요. 폴더가 그 자리에 없다는 사실까지가 이번에 잰 값이에요.

세대별로 파일 구성을 나란히 놓아 봤어요

같은 파서로 다시 센 값이에요. 마지막 줄은 옮겨진 폴더 안에서 열린 30.1이에요.

파일 개수는 22.0만 빼고 전부 32개로 같아요. 달라지는 것은 용량이고, 그 증가분의 대부분이 진단용 파일이에요. 항목 수가 34나 35로 튀는 줄은 후보판 폴더가 하나 더 있는 경우예요.

작업하다 헷갈릴 뻔한 자리도 하나 있었어요. 29.4와 31.1의 체크섬 파일이 둘 다 2,956바이트로 길이가 같았어요. 같은 파일이 잘못 놓인 게 아닌지 의심해서 내용을 대조했는데, 길이만 같고 내용은 달랐어요. 버전 문자열의 글자 수가 같아서 생긴 우연이에요. 길이가 같다는 것만으로 같은 파일이라고 판단하면 안 되는 이유가 여기 있어요.

이렇게 릴리스마다 값을 나란히 놓고 보는 방식은 난이도 조정 주기를 잴 때도 썼어요. 같은 프로그램의 다른 축을 잰 이야기는 비트코인 코어 쪽 글에 있어요.

받는 사람 입장에서 정리하면

지금까지 센 것을 받는 쪽 순서로 다시 늘어놓으면 이래요.

첫째, 폴더 하나에서 파일 하나만 받으면 되는 구조가 아니에요. 프로그램 파일과 체크섬 목록 파일, 그리고 그 목록에 붙은 서명 파일까지 세 종류가 한 세트예요. 서명이 분리형이라 목록 파일 없이 서명만 받으면 짝이 안 맞아요.

둘째, 목록에 이름이 있다고 지금 받을 수 있는 건 아니에요. 옛 릴리스에서는 이름 23개 중 12개가 파일 없이 이름만 남아 있었어요.

셋째, 폴더 용량은 받을 용량이 아니에요. 최신 폴더 5.16 GiB 중 진단용 파일이 3.98 GiB를 차지하고, 설치 파일 하나는 37.4 MiB예요.

넷째, 404가 곧 삭제는 아니에요. 30.0과 30.1처럼 자리를 옮겨 둔 경우가 있어요.

번호 체계가 어디서 정해지고 어떤 표기를 쓰는지가 궁금하시면 제안 문서 쪽을 센 비트코인 BIP 글에 따로 적어 뒀어요.

확인하지 못한 것

정직하게 적어 둘게요. 이 글은 목록과 파일 이름과 바이트를 센 기록이고, 그 바깥은 재지 않았어요.

• 서명이 실제로 유효한지 몰라요. 서명 패킷의 개수를 세고 발행자 지문을 읽은 데까지가 전부예요. 공개키를 내려받지 않았고 검증을 돌리지도 않았어요. 지문의 주인이 누구인지도 확인하지 않았고, 이 글은 어떤 이름도 적지 않아요.
• 30.0과 30.1이 옮겨진 사유를 확인하지 못했어요. 그 폴더에는 설명 파일이 없었고 폴더 이름이 유일한 단서예요. 이름만 보고 특정 사안을 지목해 적지 않을게요.
• 22.0에서 파일 12개가 사라진 사유를 확인하지 않았어요. 지금 몇 개가 남아 있는지까지가 이번에 잰 값이에요.
• 후보판 폴더에서 번호가 빠진 이유를 확인하지 않았어요. 폴더가 없다는 사실까지만 셌어요.
• 31.1에 공개된 해시 28개 중 실제로 내려받아 맞춰 본 것은 1개뿐이에요. 가장 작은 파일 하나만 대조했고 나머지 27개는 대조하지 않았어요.
• 릴리스 폴더 64개 중 실제로 열어 본 것은 8개예요. 64개와 32개, 32개라는 수는 목록을 세어 보니 나온 값이고 폴더를 전부 열어 확인한 값이 아니에요.
• 다른 배포 경로는 보지 않았어요. 미러나 소스 저장소에 무엇이 있는지 세지 않았어요.
• 프로그램을 설치하거나 실행하지 않았어요. 이 글은 설치 안내가 아니에요.
• 매매 판단을 담고 있지 않아요. 디지털자산은 원금 손실 위험이 있고 모든 판단은 본인 책임이에요.

정리

네 줄로 줄이면 이래요.

첫째, 목록에 적힌 폴더는 68개이고 그중 64개가 버전 폴더였어요. 옛 번호 32개와 새 번호 32개로 정확히 반씩 갈렸어요.

둘째, 이름에 insecure가 붙은 폴더는 4개인데 실제 내용은 3가지이고 안에 22개 버전이 들어 있어요. 그중 5개는 본 목록에도 그대로 남아 있어요.

셋째, 옮겨진 것과 지워진 것은 달라요. 30.0과 30.1은 본 경로에서 404지만 옮겨진 자리에서는 파일 32개가 체크섬 파일까지 갖춰 열려요.

넷째, 체크섬 목록은 만들었을 때의 기록이고 서명은 짝이 있어야 해요. 2021년 릴리스는 이름 23개 중 11개만 남아 있었고, 서명은 전부 분리형이라 목록 파일과 함께 받아야 해요.

배포 폴더를 세어 보면 파일 하나를 받는 일이 왜 파일 하나로 끝나지 않는지가 드러나요. 다만 이 글은 한 시점의 목록을 못박아 놓고 남긴 관측 기록일 뿐이고, 파일 서버는 새 릴리스가 올라오면 또 움직여요. 어떤 거래도 권하지 않아요.

자주 묻는 질문

비트코인 코어 배포 폴더에는 버전이 몇 개 있나요?

2026년 9월 9일 오전 10시 40분(한국 시각) 기준으로 목록에 적힌 폴더는 68개이고 그중 버전 폴더가 64개였어요. 나머지 4개는 이름에 insecure가 붙은 폴더예요. 다만 이건 목록 페이지를 세어 본 값이고 64개 폴더를 전부 열어 본 값은 아니에요. 새 릴리스가 올라오거나 오래된 파일이 정리되면 숫자가 달라져요.

이름에 insecure가 붙은 폴더는 무엇인가요?

이번 조회 기준으로 이름이 다른 폴더가 4개인데 그중 둘은 목록 HTML이 폴더 이름만 빼고 완전히 같아서, 서로 다른 묶음은 3가지예요. 안에 든 버전을 합치면 22개이고 겹치는 버전은 없어요. 다만 각 폴더가 왜 그렇게 묶였는지는 폴더에 놓인 설명 파일이 적어 둔 범위까지만 확인했고, 설명 파일이 없는 폴더는 사유를 확인하지 못했어요.

30.0과 30.1은 왜 안 열리나요?

본 경로에서는 두 폴더 모두 HTTP 404였어요. 그런데 insecure-wallet-deletion 폴더 아래로 들어가면 30.1은 HTTP 200이고 항목 33개와 체크섬 파일이 그대로 있었어요. 그러니까 이 조회 기준으로는 지워진 게 아니라 옮겨진 상태예요. 왜 옮겼는지는 그 폴더에 설명 파일이 없어서 이번 조사 범위에서는 확인하지 못했어요.

체크섬 목록에 이름이 있으면 지금 받을 수 있는 건가요?

그렇게 읽으면 틀리는 경우가 있어요. 2021년에 배포된 22.0은 체크섬 파일에 이름이 23개 적혀 있는데 이번 조회에서 폴더에 실제로 남아 있는 것은 11개였고 12개는 이름만 남아 있었어요. 반대로 최신 31.1은 28개가 모두 있었어요. 그래서 체크섬 목록은 그 릴리스를 만들 때 무엇이 있었는지의 기록으로 읽는 편이 맞아요.

SHA256SUMS 파일 하나만 받으면 검증이 되나요?

이번에 연 네 릴리스에서는 안 됐어요. 서명 파일의 패킷을 뜯어 보니 종류가 전부 분리형 문서 서명이었고, 본문을 감싸 넣는 방식은 한 건도 없었어요. 그래서 체크섬 목록 파일과 그 옆의 서명 파일을 둘 다 받아 짝을 지어야 해요. 다만 서명이 실제로 유효한지는 공개키를 받아 검증해야 알 수 있고 이번에는 하지 않았어요.

서명이 11건이면 11명이 확인했다는 뜻인가요?

그렇게 읽으면 이 글의 범위를 넘어요. 이번에 센 것은 파일 안에 들어 있는 서명 패킷의 개수와 발행자 지문까지예요. 공개키를 내려받아 검증하지 않았고 지문의 주인이 누구인지도 확인하지 않았어요. 그러니 개수는 파일에 적힌 값이고 유효성이나 신원은 이 글이 말하지 않는 부분이에요.

최신 버전 폴더는 왜 이렇게 용량이 큰가요?

이번 조회에서 31.1 폴더의 파일 32개 합계는 5.16 GiB인데 그중 이름에 debug가 붙은 진단용 6개가 3.98 GiB로 77.2퍼센트를 차지했어요. 반대로 윈도우 설치 파일 하나는 37.4 MiB로 폴더 전체의 0.71퍼센트였어요. 다만 이 구성은 세대마다 다르고, 2021년의 22.0에는 debug 파일이 0개였어요.

이 숫자를 그대로 인용해도 되나요?

조회 시각과 분모를 함께 적어 주시면 좋겠어요. 폴더 68개, 버전 폴더 64개, 조회 2026년 9월 9일 오전 10시 40분, 대상은 공식 배포 경로 하나라는 네 가지예요. 파일 서버 상태라 새 릴리스가 올라오거나 오래된 파일이 정리되면 값이 달라져요.