📈 BIP-39 단어 목록 중 체코어만 svetr 이 알파벳순보다 두 칸 앞이에요 — 2021년 공개 지적 뒤 지금도 그대로

「BIP-39 단어 목록은 2,048개」라는 문장은 어디서나 볼 수 있어요. 그런데 그 목록이 어떤 순서로 파일에 적혀 있는지를 확인한 글은 드물어요. 규격 본문이 그 순서에 기대는 문장을 하나 적어 뒀는데도요.

BIP-39 규격 원문의 단어 목록 절은 「이상적인 단어 목록」이 갖는 성질을 셋 적으면서 그중 하나로 정렬을 들어요. 그리고 괄호를 열어 구현이 선형 탐색 대신 이진 탐색을 쓸 수 있다고 그 이유를 밝혀 둬요. 이진 탐색은 배열이 정렬돼 있을 때만 옳은 답을 내니까, 이 문장은 검증 가능한 주장이에요. 그래서 그대로 시험해 봤어요. 공식 단어 목록 10개를 파일에 적힌 줄 순서 그대로 배열에 두고 2,048개 단어를 하나씩 이진 탐색으로 찾아본 거예요.

답부터 적을게요. 2,048개를 전부 찾은 목록은 네 개였고, 못 찾은 여섯 개의 원인을 하나씩 뜯어보니 다섯 개는 그 언어의 정렬 규약 안에서 설명이 됐어요. 중국어 둘은 애초에 빈도순이고, 프랑스어의 역전은 전부 분해된 악센트 탓이고, 스페인어는 전부 ñ, 일본어는 전부 작은 가나였어요. 어떤 정렬 기준으로도 설명되지 않는 건 체코어 하나였고, 그 원인은 단어 하나가 제 알파벳 자리보다 두 칸 앞에 놓인 것이었어요.

그리고 이 대목이 이 글의 진짜 이야기예요. 이건 새로 발견한 게 아니에요. 2021년 11월 16일에 이미 공개 보고돼 있었고, 답글도 후속 커밋도 없이 지금까지 그대로예요. 조회 시각은 2026년 9월 16일 오후 2시 5분부터 오후 2시 40분까지(한국 시각)이고, 가격이나 전망은 다루지 않아요.

규격이 정렬을 근거로 삼은 자리를 먼저 확인했어요

세기 전에 「무엇이 어디에 적혀 있는지」부터 갈라 둘게요. 이 주제는 문서가 세 층이라 섞으면 그대로 오류가 돼요.

규격 본문의 해당 문장은 이렇게 적혀 있어요.

c) sorted wordlists

• the wordlist is sorted which allows for more efficient lookup of the code words (i.e. implementations can use binary search instead of linear search)
• this also allows trie (a prefix tree) to be used, e.g. for better compression

여기서 가장 자주 틀리는 자리를 못박을게요. 이 문단은 An ideal wordlist has the following characteristics 로 시작해요. 그러니까 must 가 아니라 ideal이에요. 같은 문단에서 must 가 붙은 것은 UTF-8 과 NFKD 인코딩 하나뿐이고, 정렬은 의무 조항이 아니라 구현이 이진 탐색을 써도 되는 근거로 제시된 성질이에요. 그래서 이 글은 「규격 위반」이라는 말을 쓰지 않아요. 대신 「규격이 근거로 든 전제가 이 목록에서 성립하지 않는다」고만 말할게요.

머리말 표기부터 최근에 바뀌어 있었어요

옛 블로그를 그대로 옮기면 바로 틀리는 자리가 하나 더 있어요. BIP-39 머리말의 현재 값은 Status 가 Deployed, Type 이 Specification, 날짜 필드가 Assigned 2013-09-10이에요. Final 도 Standards Track 도 Created 도 지금 저장소에는 없는 낱말이고, 2026년 1월 12일 커밋들에서 바뀐 거예요. 이 표기 교체가 저장소 전체에서 어떻게 갈렸는지는 BIP 문서 210건의 상태 표기 쪽에서 따로 세어 봤고, 이 글에서는 BIP-39 한 건의 머리말만 확인했어요.

이 글이 다루는 각도를 한 줄로 갈라 둘게요

시드 문구 이야기는 각도가 여러 갈래라 겹치기 쉬워요. 이 글이 보는 자리는 단어 목록 파일 안의 줄 순서 한 건이에요. 종이나 금속판에 어떻게 적어 두느냐는 시드 문구 백업과 보관 쪽 이야기이고, 같은 시드에서 주소가 여러 개로 갈리는 구조는 지갑 파생 경로 쪽 이야기예요. 이 글은 그 둘 어느 쪽도 다시 다루지 않고, 목록 파일을 연 다음 줄 번호만 봐요.

파일에 적힌 줄 순서 그대로 2,048개를 찾아봤어요

방법은 단순해요. 각 목록 파일을 줄 단위로 읽어 정렬하지 않고 그대로 배열에 넣고, 그 배열에서 각 단어를 이진 탐색으로 찾아 같은 단어가 나오는지 확인했어요. 비교 기준은 유니코드 코드포인트 순, 그러니까 파일에 저장된 바이트 그대로예요. 언어별 사전순 기준이 아니라는 점을 미리 적어 둘게요.

먼저 파일 자체의 사실을 확인했어요. 안내 문서가 링크한 목록은 10개이고, 규격이 참조 구현으로 지목한 저장소에는 러시아어와 터키어를 더한 12개가 들어 있어요. 12개 전부 정확히 2,048줄이고 목록 안에 중복 단어는 없었어요. 두 저장소에 다 있는 10개는 sha256 이 10개 중 10개가 완전히 같았어요. 그러니까 이 두 저장소 사이에서는 「어느 사본을 봤느냐」로 결과가 갈릴 여지가 없어요. 지갑이 자체로 번들한 사본이나 그 밖의 미러는 이번에 재지 않았어요.

구현에 따라 달라지는 숫자는 일부러 적지 않았어요

여기서 한 번 걸러야 할 게 있어요. 정렬되지 않은 배열에 이진 탐색을 돌리면 몇 개를 찾느냐가 탐색 구현의 프로브 순서에 종속돼요. 같은 파일에 서로 다른 두 구현을 돌려 보니 값이 이렇게 갈렸어요.

그래서 이 글이 숫자로 주장하는 것은 두 가지뿐이에요. 하나는 2,048개를 전부 찾은 목록이 10개 중 네 개(영어 · 이탈리아어 · 한국어 · 포르투갈어)라는 것이고, 다른 하나는 체코어가 2,048개 중 2,046개라는 것이에요. 위 표의 가운데 값들은 구현이 바뀌면 따라 바뀌니까 본문에서 뺐어요. 참조 구현의 12개 기준으로 넓혀도 전부 찾는 목록은 여전히 네 개예요.

못 찾은 여섯 목록은 저마다 다른 이유였어요

「10개 중 네 개」만 적어 두면 나머지 여섯이 깨진 것처럼 읽혀요. 사실이 아니라서, 여섯 개의 원인을 하나씩 전수로 뜯었어요. 아래 표가 이 글에서 가장 중요한 자리예요.

정규화 기준을 바꿔 가며 다시 세면 이 구분이 더 선명해져요.

프랑스어를 보세요. 코드포인트로 세면 90, NFC 로 합쳐 세면 오히려 139 로 늘었다가, 결합부호를 떼면 0 이 돼요. 이 목록은 처음부터 끝까지 알파벳순으로 정렬돼 있고, 파일이 NFKD 라서 악센트 문자가 두 코드포인트로 저장돼 있을 뿐이에요. 스페인어와 일본어에 남는 11 과 28 도 각각 ñ 과 작은 가나라는 그 언어의 정렬 관습이에요.

체코어만 세 열이 전부 1 이에요. 표기 문제가 아니라 줄 위치 문제라는 뜻이에요.

체코어의 어긋난 자리는 네 줄 안에 있어요

파일을 원바이트 기준으로 열어 해당 구간을 그대로 옮기면 이래요.

1637: svalstvo
1638: svetr
1639: svatba
1640: svazek

세 번째 줄과 네 번째 줄이 두 번째 줄보다 알파벳순으로 앞이에요. 숫자로 정리하면 이렇게 돼요.

한 단어를 두 칸 당겨 놓으면 뒤의 두 단어가 한 칸씩 밀려요. 그래서 자리가 다른 단어는 셋이고, 그중 이진 탐색이 놓치는 건 둘이에요. 나머지 2,046개는 배열 어디에 있든 정상적으로 찾혀요.

정렬 기준을 두고 다툴 여지도 없는 자리예요. 안내 문서의 체코어 항목 「규칙 7」이 이렇게 못박아 두고 있거든요.

7. Words are sorted according to English alphabet (Czech sorting has difference in "ch").

영어 알파벳 순으로 보면 sva 가 sve 보다 앞이고, 체코어 알파벳 순으로 봐도 결론이 같아요. 체코어 정렬이 영어와 갈리는 자리는 ch 를 한 글자로 보는 대목인데, 이 네 단어에는 그 자리가 없어요. 어느 기준을 들어도 svatba 다음이 svazek, 그다음이 svetr 이에요.

한 가지는 분명히 갈라 둘게요. 이건 단어가 잘못 들어갔다는 뜻이 아니에요. 2,048개 단어 구성은 그대로고 줄 순서만 어긋났어요. 각 단어의 인덱스가 바뀐 것도 아니라서, 체코어 목록으로 만든 니모닉의 생성 결과나 복구 결과가 달라지지는 않아요. 영향을 받을 수 있는 자리는 목록이 정렬돼 있다고 가정하고 단어를 찾는 구현 하나뿐이에요.

참고로 뜻은 이래요. svatba 는 결혼식, svetr 은 스웨터, svazek 은 묶음이나 권, svalstvo 는 근육조직이에요.

이건 2021년에 이미 공개로 적혀 있었어요

여기서 이 글의 무게 중심이 옮겨가요. 직접 세어 보고 나서 저장소 기록을 확인해 보니, 같은 이야기가 이미 적혀 있었어요.

체코어 목록이 저장소에 들어올 때의 PR 인 bitcoin/bips PR #493 은 2019년 9월 19일(UTC)에 병합되며 이미 닫힌 PR 이에요. 그 닫힌 PR 의 댓글로 2021년 11월 16일 오후 5시 42분(UTC)에 이런 글이 하나 달렸어요. 축자로 옮기면 이래요.

"I'm not sure how this was missed, but the order of words in the wordlist is not alphabetical. The word "svetr" should come after "svazek". The fact that the list looks sorted but is not may cause subtle bugs in applications using binary search to look up code words."

정렬돼 있는 것처럼 보이지만 아닌 목록이 이진 탐색을 쓰는 응용에서 미묘한 버그를 부를 수 있다는 말이에요. 이 글이 방금까지 재서 확인한 내용과 사실상 같은 문장이에요.

그리고 이것이 그 PR 의 마지막 댓글이에요. 답글이 달리지 않았고, 그 뒤에 체코어 파일을 고친 커밋도 없어요. 목록별 최종 커밋을 뽑아 보면 이렇게 돼요.

프랑스어 줄을 같이 봐 주세요. 목록의 오류가 고쳐진 전례가 있어요. 2018년 1월 1일 커밋의 메시지가 「프랑스어 목록의 오류 두 개를 고쳤다」예요. 그러니 「단어 목록 파일은 원래 안 고친다」는 설명은 이 저장소의 기록과 맞지 않아요.

체코어 파일은 2017년 2월 12일 이후로 손대지 않았어요. 오늘 조회한 저장소 HEAD 는 173f386d(2026년 9월 14일)인데, 그 시점의 파일에도 svetr 은 1638번째 줄에 그대로 있어요. 시간으로 세면 파일이 멈춘 지 9년 7개월, 보고가 올라온 지 4년 10개월이에요.

한 가지는 조심해서 적을게요. 이 확인은 그 PR 안에서만 한 거예요. 그 뒤에 별도의 이슈나 PR 이 열렸는지까지는 확인하지 못했으니, 「아무도 다시 말하지 않았다」가 아니라 「PR #493 에는 후속이 없다」까지만 읽어 주세요.

범위를 바꾸면 답이 바뀌는 숫자들도 있었어요

이번 조사에서 가장 조심스러웠던 대목은 「0건」이라는 표현이에요. 몇 개 목록을 분모로 놓느냐에 따라 참이 되기도 하고 거짓이 되기도 하거든요.

안내 문서의 스페인어 항목 3 은 스페인어 목록이 다른 어떤 언어 목록과도 겹치는 단어가 없다고 적고, 그래서 단어 하나만 봐도 언어를 알 수 있다고 이어가요. 실제로 세어 보면 이렇게 갈려요.

같은 함정이 언어 판별에도 있어요. 참조 구현의 언어 판별 절차를 그대로 재현해 단어를 하나씩 넣어 보면, 10개 목록 기준으로 영어와 프랑스어가 각각 100개씩 판별 불가로 나와요. 그런데 12개 범위로 넓히면 영어는 119개, 프랑스어는 106개가 돼요. 겹치는 쌍도 10개 기준 45쌍 중 2쌍인데, 12개 기준으로는 66쌍 중 8쌍이에요.

체코어 이야기를 하면서 하나 덧붙일 게 있어요. 체코어와 터키어는 15개 단어가 겹쳐요. 그런데 안내 문서의 체코어 규칙 8 은 겹치면 안 되는 대상으로 영어와 이탈리아어와 프랑스어와 스페인어 넷만 적어 뒀고 터키어는 그 목록에 없어요. 터키어는 애초에 그 규칙이 쓰일 때 없던 목록이라서, 이 15개는 규칙 위반이 아니에요. 겹침 숫자를 인용할 때 이 단서가 빠지면 없는 잘못을 만들게 돼요.

이 글이 말할 수 있는 것과 말할 수 없는 것

규격 자신이 비영어 목록을 강하게 말리고 있어요

노출 규모를 부풀리지 않기 위해 반드시 같이 적어야 하는 문장이 있어요. 규격 본문의 목록 절은 이렇게 적어요.

Since the vast majority of BIP39 wallets supports only the English wordlist, it is '''strongly discouraged''' to use non-English wordlists for generating the mnemonic sentences.

대다수 지갑이 영어 목록만 지원하니 니모닉 생성에 비영어 목록을 쓰는 것은 strongly discouraged라는 뜻이에요. 그러니까 체코어 목록을 실제로 쓰는 경우 자체가 규격 차원에서 권장되지 않는 길이에요. 이 사실을 빼고 읽으면 이 글의 한 줄짜리 어긋남이 실제보다 크게 보여요.

그래도 이 조사가 의미를 갖는 자리는 남아요. 규격이 정렬을 근거로 이진 탐색을 허락하는 문장을 적어 뒀고, 공식 목록 10개 중 하나에서 그 근거가 성립하지 않으며, 그 사실이 4년 10개월 전에 공개 보고됐는데도 파일이 그대로라는 것이에요.

확인하지 못한 것

범위를 분명히 해 둘게요. 아래는 이 글이 재지 않은 것들이라, 본문 어디에서도 주장하지 않았어요.

• 실제 지갑이 이진 탐색을 쓰는지 확인하지 않았어요. 하드웨어 지갑 펌웨어나 지갑 소프트웨어가 단어를 어떤 방식으로 찾는지는 코드 감사 없이는 알 수 없어요. 그래서 「체코어에서 실패한다」가 아니라 「규격이 근거로 든 전제가 이 목록에서 성립하지 않는다」까지만 썼어요.
• 실제 복구 실패 사례를 찾지 않았어요. 선형 탐색이나 해시 조회를 쓰는 구현이라면 이 순서와 무관해요.
• PR #493 바깥은 확인하지 못했어요. 다른 이슈나 PR 이 열렸는지는 이 조사의 범위 밖이에요.
• 러시아어와 터키어가 왜 규격 문서 쪽에는 없는지 재지 않았어요. 두 목록이 참조 구현에만 있다는 사실까지만 확인했어요.
• BIP-39 이후의 다른 규격과 비공식 목록은 보지 않았어요. 각 지갑이 자체로 만든 목록도 이 조사에 들어가지 않았어요.
• 정렬 판정은 코드포인트 비교 기준이에요. 언어별 사전순 정렬 라이브러리로 다시 판정하면 숫자가 달라질 수 있고, 그래서 여섯 목록의 원인을 표로 따로 뜯어 놓은 거예요.
• 고정한 시점 밖은 재지 않았어요. bitcoin/bips 는 HEAD 173f386d(2026년 9월 14일), 참조 구현은 HEAD b57a5ad7(2024년 8월 27일) 시점이에요. 이후 커밋이 있다면 이 글의 숫자는 낡아요.

자주 묻는 질문 (FAQ)

Q. 결국 BIP-39 단어 목록을 몇 개로 봐야 하나요?

세는 자리를 먼저 정해야 답이 하나로 나와요. 단어 목록 안내 문서가 링크한 언어는 10개이고, 규격이 참조 구현으로 지목한 저장소에는 러시아어와 터키어를 더한 12개가 들어 있어요. 참조 구현의 언어 나열 함수가 폴더의 파일을 그대로 훑는 방식이라, 코드가 인정하는 언어도 12개예요. 단어 수는 12개 목록 전부 정확히 2,048개였어요.

Q. 정렬이 어긋나 있으면 왜 이진 탐색만 문제가 되나요?

이진 탐색은 배열이 정렬돼 있다는 가정 위에서 가운데를 보고 한쪽을 버리는 방식이라, 가정이 깨지면 찾아야 할 단어가 버려진 쪽에 있어도 알 길이 없어요. 반대로 처음부터 끝까지 훑는 선형 탐색이나 단어를 열쇠로 쓰는 해시 조회는 순서에 기대지 않아서 영향을 받지 않아요. 규격이 정렬을 적어 둔 이유 자체가 이진 탐색을 허락하기 위해서라, 어긋난 자리가 정확히 그 문장에 걸리는 거예요.

Q. 왜 못 찾은 숫자를 목록마다 적지 않았나요?

정렬되지 않은 배열에서는 몇 개를 찾느냐가 탐색 구현의 프로브 순서에 따라 달라지기 때문이에요. 같은 파일에 서로 다른 두 구현을 돌려 보니 프랑스어와 스페인어와 일본어와 중국어 두 목록은 다섯 모두 값이 서로 달랐어요. 반면 2,048개를 전부 찾는 목록이 네 개라는 것과 체코어가 2,046 이라는 것은 두 구현에서 같았어요. 그래서 구현이 바뀌어도 흔들리지 않는 그 둘만 본문의 주장으로 삼았어요. 목록별 적중 개수를 인용한 글을 보면 어떤 탐색 구현으로 센 값인지 함께 적혀 있는지 확인해 보세요.

Q. 한국어 목록은 괜찮은가요?

파일에 적힌 줄 순서 그대로 이진 탐색을 돌렸을 때 한국어는 2,048개를 전부 찾았어요. 다만 한국어 목록은 완성형 음절이 아니라 자모 형태로 저장돼 있어요. 규격이 NFKD 인코딩을 요구했기 때문이고, 결함이 아니라 규정을 지킨 결과예요. 실무에서 주의할 점은 따로 있는데, 키보드로 친 완성형 글자와 파일 속 자모는 바이트가 달라서 정규화 없이 그대로 문자열을 비교하면 하나도 맞지 않아요.

Q. 체코어 목록을 쓰는 지갑이 많나요?

이 조사에서는 세지 않았어요. 다만 규격 본문이 대다수 지갑이 영어 목록만 지원한다고 적으면서 비영어 목록 사용을 강하게 말리고 있어요. 그래서 이 어긋남이 닿는 범위는 「체코어 목록을 지원하면서 이진 탐색으로 단어를 찾는 구현」으로 좁혀지는데, 그런 구현이 실제로 얼마나 있는지는 확인하지 못했어요.

Q. 목록이 고쳐지면 기존 시드 문구는 어떻게 되나요?

갈리는 자리를 정확히 짚어 둘게요. 단어의 인덱스는 파일의 줄 번호로 정해지므로, 줄 순서를 바꾸면 세 단어의 인덱스가 바뀌어요. 그래서 그 세 단어가 든 기존 체코어 니모닉은 체크섬 검증과 엔트로피 복원이 새 파일과 옛 파일에서 갈려요. 다만 시드 자체는 그대로예요. 규격 본문의 시드 생성 절이 시드를 니모닉 문장 문자열에서 PBKDF2 로 뽑는다고 적어 뒀거든요. 이번 건은 단어가 바뀌는 수정이 아니라 줄 위치만 바뀌는 수정이라, 같은 문장을 적어 두었다면 나오는 시드도 같아요. 그러니까 이 한 줄의 무게는 시드가 아니라 검증 쪽에 있어요.

Q. 이 글의 숫자는 언제까지 유효한가요?

저장소 커밋이 기준이에요. bitcoin/bips 는 HEAD 173f386d, 참조 구현은 HEAD b57a5ad7 시점의 파일로 셌어요. 누군가 체코어 파일을 고치면 역전 1 은 0 이 되고 체코어의 2,046 은 2,048 이 돼요. 반대로 규격 본문의 조건 문장이나 안내 문서의 언어별 규칙은 문서를 고치지 않는 한 그대로예요.

정리

• BIP-39 규격 본문은 이상적인 단어 목록의 성질 가운데 하나로 정렬을 들면서 구현이 이진 탐색을 쓸 수 있다고 근거를 밝혀 뒀어요. 다만 이 문단은 must 가 아니라 ideal이에요.
• 공식 목록 10개를 파일에 적힌 줄 순서 그대로 이진 탐색하면 2,048개를 전부 찾는 목록은 네 개(영어 · 이탈리아어 · 한국어 · 포르투갈어)였어요.
• 못 찾은 여섯 개 가운데 다섯은 그 언어의 정렬 규약 안에서 설명됐어요. 중국어 둘은 빈도순, 프랑스어의 역전 90건은 전부 NFKD 악센트(결합부호를 떼면 0), 스페인어의 잔여 11건은 전부 ñ, 일본어의 잔여 28건은 전부 작은 가나(촉음 っ 22건 · 요음 ゃ·ゅ·ょ 6건)였어요.
• 어떤 정규화로도 설명되지 않는 건 체코어 하나였어요. 2,048개가 전부 ASCII 소문자인데 역전이 1건 남고, 원인은 svetr 이 제 자리보다 두 칸 앞에 있는 것이었어요. 자리가 다른 단어는 3개, 이진 탐색이 놓치는 단어는 2개예요.
• 이 건은 2021년 11월 16일에 bitcoin/bips PR #493 댓글로 이미 공개 보고돼 있었고, 그게 그 PR 의 마지막 댓글이에요. 체코어 파일의 최종 커밋은 여전히 2017년 2월 12일이고, 2026년 9월 14일 HEAD 에도 그대로예요.
• 다만 규격 본문 자체가 비영어 목록 사용을 strongly discouraged라고 적어 뒀고, 실제 지갑이 이진 탐색을 쓰는지는 확인하지 않았어요. 그래서 이 글은 「실패한다」가 아니라 「규격이 근거로 든 전제가 이 목록에서 성립하지 않는다」까지만 말해요.

이 글은 매매 권유가 아닌 정보 제공 글입니다. 가상자산은 변동성이 크고 원금 손실 위험이 있으며, 투자 판단과 그 결과에 대한 책임은 본인에게 있습니다.