🔑 같은 시드 문구 하나에 주소가 네 개 — 지갑 파생 경로 BIP-44·49·84·86과 ERC-601이 갈리는 자리

결론부터 말하면, 시드 문구 열두 단어는 지갑 하나를 가리키는 이름이 아니에요. 그 열두 단어에서 나오는 것은 주소가 아니라 나무 한 그루예요. 어느 가지를 타고 내려가느냐를 정하는 것이 파생 경로이고, 그 경로의 첫 칸 하나만 달라도 완전히 다른 주소가 나와요.

얼마나 다른지 직접 재 봤어요. 같은 시드 문구를 고정하고, 메인넷·계정 0번·외부 수신 체인·첫 번째 주소까지 전부 고정한 다음, 경로의 첫 칸만 44에서 49로, 84로, 86으로 바꿨어요. 그랬더니 첫 수신 주소가 이렇게 나왔어요.

같은 문구인데 서로 겹치는 글자가 거의 없죠. 그래서 A 지갑에서 쓰던 시드를 B 지갑에 넣었을 때 잔액이 0으로 보이는 일이 생겨요. 코인이 사라진 게 아니라 B 지갑이 다른 가지를 보고 있는 거예요.

이 글은 그 갈림길이 어느 문서의 몇 번째 줄에서 정해졌는지를 규격 원문으로 짚어요. 그리고 위 네 값이 제 계산이 아니라 규격 문서가 직접 실어 둔 공개 테스트 벡터라는 것도 같이 확인해요. 지갑 앱 조작법이나 자산을 옮기는 절차는 다루지 않아요.

파생 경로는 다섯 칸이고 첫 칸이 나무 전체를 갈라요

경로 표기의 출처는 BIP-44 문서예요. 34번째 줄에 이렇게 적혀 있어요.

m / purpose' / coin_type' / account' / change / address_index

칸이 다섯 개예요. 각 칸이 무엇을 정하는지는 같은 문서가 칸마다 절을 따로 두고 설명해요.

여기서 첫 칸이 특별한 이유는 BIP-43 이라는 더 짧은 문서에 있어요. 이 문서가 나온 배경 자체가 "BIP-32 만 지켰다는 말이 아무 뜻도 없어졌다"는 문제였어요. 21번째 줄에 이렇게 적혀 있어요.

"the BIP32 specification offers implementers too many degrees of freedom. Multiple implementations may claim they are BIP32 compatible, but in fact they can produce wallets with different logical structures making them non-interoperable."

그래서 BIP-43 은 첫 칸을 규격 번호로 쓰자고 제안해요. 새 방식을 만들 거면 BIP 번호를 하나 받아서 그 번호를 첫 칸에 그대로 쓰라는 거예요. BIP-44 는 44를, BIP-49 는 49를, BIP-84 는 84를, BIP-86 은 86을 써요. 번호가 다르면 나무 자체가 겹치지 않아요.

숫자로 보면 이렇게 돼요. hardened 표기는 원래 인덱스에 2의 31제곱을 더한 값이에요.

BIP-44 43번째 줄이 이 값을 직접 적어 둬요. "Purpose is a constant set to 44' (or 0x8000002C) following the BIP43 recommendation." 그리고 이 인덱스는 HMAC 입력에 그대로 들어가기 때문에, 한 자리만 달라도 그 아래 모든 키가 통째로 달라져요. 비슷한 값이 나오는 게 아니라 아무 관계 없는 값이 나와요.

같은 시드에서 나온 첫 수신 주소 네 개 — 규격이 실은 값과 제가 계산한 값

여기가 이 글의 중심이라 값의 출처를 두 칸으로 갈라서 적을게요. 규격 문서가 직접 인쇄해 둔 값과, 문서에 없어서 제가 계산한 값은 신뢰의 성격이 다르니까요.

먼저 시드 문구예요. 이 문구는 제가 만든 것도, 누구의 지갑 것도 아니에요. BIP-84·BIP-86·SLIP-0132 세 문서가 본문에 그대로 인쇄해 둔 시험용 문구예요.

abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about

엔트로피가 128비트 전부 0인 값이라 앞의 열한 단어가 단어 목록의 0번(abandon)이 되고, 마지막 한 단어만 체크섬 때문에 3번(about)이 돼요. 직접 확인해 보니 0이 열여섯 바이트 들어간 값의 SHA-256 첫 바이트가 0x37 이고, 그 상위 4비트 0011 이 마지막 단어 인덱스 3을 만들어요. 합쳐서 132비트, 11비트씩 열두 조각이 열두 단어예요.

🔴 이 문구는 공개된 시험용이라 여기에 실제 자산을 넣으면 즉시 털려요. 값을 눈으로 대조하는 용도로만 봐 주세요.

규격 문서가 직접 실어 둔 값

출처를 하나 짚어 둘게요. 49 경로 주소를 BIP-49 출처로 적으면 틀려요. BIP-49 본문의 테스트 벡터는 84번째 줄부터 104번째 줄까지인데, 거기 실린 값은 전부 테스트넷이에요. 마스터키가 uprv 로 시작하고, 경로가 m/49'/1'/0'/0/0 이고, 주소가 2Mww8dCYPUpKHofjgcXcBCEGmniw9CoaiD2 예요. 두 번째 칸이 1이면 테스트넷이라는 뜻이라 메인넷 주소가 아니에요. 위 표의 37Vuc 로 시작하는 값은 SLIP-0132 가 실은 메인넷 벡터예요.

제가 계산한 값 — 그리고 규격이 같은 경로를 어디까지 실어 뒀는지

아래 값들은 어느 BIP·SLIP·ERC 에도 그 값 그대로는 실려 있지 않아요. 세 저장소(bitcoin/bips·satoshilabs/slips·ethereum/ercs)를 통째로 내려받아 값마다 대소문자 양쪽으로 훑었는데 전부 0건이었어요. 그러니 값 자체는 제 계산 결과로 읽어 주세요.

다만 값이 없다는 말과 경로가 없다는 말은 전혀 다른 말이에요. 저는 처음에 이 표의 마지막 칸을 "이 경로를 실은 규격이 없음"이라고 적었는데, 값이 아니라 경로로 다시 훑어 보니 그 판정이 틀렸어요. 값으로 찾으면 0건인데 경로로 찾으면 나오는 자리가 세 군데 있었거든요. 그래서 칸을 통째로 다시 썼어요.

세 자리를 하나씩 열어서 확인했어요.

• SLIP-0032 116번째 줄. 이 문서 48번째 줄의 시드 문구가 이 글과 똑같은 abandon 열한 번 더하기 about 이에요. 그래서 같은 문구에서 m/44'/0'/1' 을 직접 파생해 직렬화해 봤더니 xprv9xpXFhFpqdQK5owUStFsuAiWUxYpLkvQn1QmVDumBKTvmmjkNEZgpMYoAaAftt3JVeDhRkvyLvrKathDToUMdz2FqRF7JNavF7uboJWArrw 로 문서 값과 글자까지 같았어요. 계정 1번은 벡터가 아예 없는 자리가 아니라 확장키까지는 있고 주소만 없는 자리예요.
• SLIP-0014 addresses.md 109번째 줄. 이더리움 경로 m/44'/60'/0'/0/i 의 주소·공개키·개인키를 index 0부터 9까지 실어요. 다만 이 문서의 루트 문구는 all 을 열두 번 쓴 별도의 시험용 문구(SLIP-0014 31번째 줄)라 이 글의 문구와 달라요. 그 문구로도 돌려 보니 index 0이 0x73d0385F4d8E00C5e6504C6030F47BF6212736A8 로 문서 값과 일치했어요. 즉 규격이 이더리움 경로를 안 다룬 게 아니라, 다른 문구로 다뤄 둔 거예요.
• SLIP-0019 251번째 줄. 거스름 체인 경로 m/44'/0'/0'/1/0 이 세 번째 테스트 벡터에 나와요. 다만 실린 값은 주소가 아니라 scriptPubKey 76a9145a4deff88ada6705ed70835bc0db56a124b9cdcd88ac 이고, 시드도 all 열두 단어에 패스프레이즈 TREZOR 를 얹은 것이라 이 글과 달라요.

그러니까 이 표는 "규격이 손대지 않은 영역"이 아니라, 규격이 다른 문구로 같은 자리를 다뤄 둔 곳이 섞여 있고 이 문구 기준 값만 제 계산이라고 읽는 게 맞아요. 처음 판정이 틀린 이유는 단순해요. 값으로만 검색하고 경로로는 검색하지 않았거든요. "없다"는 늘 검색 범위의 함수라는 걸 이 글에서 두 번 확인한 셈이에요.

어떻게 계산했는지 그대로 밝힐게요

값만 던지면 확인할 방법이 없으니 절차를 적어 둘게요. 외부 지갑 라이브러리는 하나도 안 썼어요. 파이썬 3.12 표준 라이브러리의 hashlib 과 hmac 만 쓰고, 타원곡선 연산·Keccak-256·bech32·base58 은 전부 스크립트 안에 직접 짜 넣었어요.

이렇게 짠 구현이 믿을 만한지 확인하는 방법은 하나뿐이에요. 규격이 실어 둔 값을 다시 만들어 내는지 보는 거예요. 그래서 각 문서의 핵심 벡터 서른여섯 건을 대조했어요. 문서에 인쇄된 값을 한 줄도 빠짐없이 다 돌린 것은 아니고, 경로마다 주소와 확장키를 골라 잡은 서른여섯 건이에요.

여기에 더해 BIP-39 공식 테스트 벡터 파일까지 따로 받아 대조했는데, 그쪽도 시드와 루트 확장키가 맞았어요. 그 대조에서 하나 배운 게 있는데 뒤에서 따로 다룰게요.

확장키 접두어는 합의 규칙이 아니에요

지갑을 쓰다 보면 xpub 말고 ypub·zpub 같은 표기를 만나요. 이게 무슨 규칙인지 헷갈리기 쉬운데, 원래 권고는 정반대였어요. BIP-43 의 Node serialization 절(57번째 줄)에 이렇게 적혀 있어요. 인용한 문장 자체는 60번째 줄부터예요.

"there's no point in using a special version magic described in section "Serialization format" of BIP32. We suggest to use always 0x0488B21E for public and 0x0488ADE4 for private nodes (leading to prefixes "xpub" and "xprv" respectively)."

어느 코인이든 언제나 xpub 을 쓰라는 거예요. 그런데 세그윗이 들어오면서 이 권고가 흔들려요. 같은 계정 xpub 을 받아도 그게 어느 주소 형식으로 읽혀야 하는지 알 수 없었거든요. SLIP-0132 20번째 줄이 그 상황을 이렇게 적어요.

"its original version failed to change the HD seed version bytes (retained xpub prefix), leading to unsustainable user confusion. Either the user must know that the xpub uses BIP-0049 derivation, or the consumer of the xpub must scan both address spaces"

그래서 형제 규격들이 각자 버전 바이트를 바꿔 달았어요. 그리고 그 결과가 세 갈래로 갈렸어요.

BIP-86 자리를 확인할 때는 한 번 더 파 봤어요. "없다"고 쓰려면 못 찾은 것과 없는 것을 구분해야 하니까요. 네 방향으로 확인했어요.

• BIP-86 전문 127줄을 통째로 읽었더니 확장키 버전 절 자체가 없었어요.
• 검색어를 바꿔 버전·접두어·ypub·zpub·SLIP-0132 로 훑었더니, 걸리는 줄이 참고문헌의 문서 제목 하나뿐이었어요. 접두어와 무관한 줄이에요.
• 문서에 실제로 인쇄된 확장키 표기를 전부 뽑아 보니 xprv9s21·xprv9xgq·xprvA3Ln·xprvA449·xpub661M·xpub6BgB·xpub6GL8·xpub6H3W 여덟 개였고 전부 x 계열이었어요.
• SLIP-0132 등록표에서 86 경로 행을 찾아봤는데 한 줄도 없었어요. 그 표의 비트코인 행은 44 경로(xpub), 49 경로(ypub), 84 경로(zpub)와 멀티시그 두 줄이 전부예요.

그러니까 BIP-86 은 새 접두어를 만들다 만 게 아니라 애초에 만들지 않고 xpub 계열로 돌아간 거예요. 접두어가 늘어나기만 하는 흐름이 아니었다는 뜻이에요.

여기서 실무적으로 남는 것도 하나 있어요. SLIP-0132 24번째 줄이 "the extended serialization format does not encode the coin type" 이라고 적어요. 확장키에는 어느 코인인지가 안 담겨 있어요. 그래서 접두어는 규칙이라기보다 등록부에 올려 둔 관행에 가깝고, 어떤 지갑이 어느 접두어를 지원하지 않는다고 해서 그 지갑이 규격을 어긴 것은 아니에요.

비호환 선언을 나란히 놓으면 두 문서가 글자까지 같아요

"다른 지갑에 넣으면 안 보인다"는 현상은 사고가 아니라 설계 의도예요. 규격이 그걸 직접 적어 뒀어요. 두 문서를 나란히 열어 봤는데 문장이 글자까지 똑같았어요.

BIP-49 의 79번째 줄과 BIP-84 의 64번째 줄이에요.

"This BIP is not backwards compatible by design as described under considerations. An incompatible wallet will not discover accounts at all and the user will notice that something is wrong."

BIP-86 의 76번째 줄은 앞 문장을 줄이고 뒷문장은 거의 그대로 이어 가요.

"This BIP is not backwards compatible by design. An incompatible wallet will not discover these accounts at all and the user will notice that something is wrong."

주목할 부분은 "the user will notice that something is wrong" 이에요. 사용자가 이상하다는 걸 알아채는 편이 낫다고 본 거예요. BIP-49 의 37번째 줄이 그 이유를 적어요. 기존 계정에 세그윗 주소를 덧붙이는 방식을 쓰면 "the account might show up but also it might miss some UTXOs" 가 되거든요. 계정은 보이는데 잔액 일부만 빠지는 상황이죠. 그래서 아예 다른 나무를 쓰기로 했다는 거예요. 39번째 줄 표현으로는 "which fails in a more visible way" 예요.

그런데 BIP-44 는 어떨까요. 검색으로 한 번, 구조로 한 번 확인했어요. backward 나 compat 로 훑으면 매칭이 0건이에요. 검색어 하나에 기대면 불안하니 최상위 절 목록을 통째로 뽑아 세어 봤어요.

BIP-44 에는 그 절이 없어요. 대신 형제 규격들에는 없는 절이 두 개 있어요. Account discovery 와 그 안의 갭 리밋이에요. 시기 순서를 생각하면 자연스러워요. BIP-44 는 앞서 나온 첫 규격이라 무엇과 호환될지를 적을 대상 자체가 없었고, 대신 "이 나무를 어떻게 훑을 것인가"를 정해야 했던 거예요.

두 번째 칸만 바꿔도 갈려요 — coin_type 등록부

첫 칸을 고정해도 두 번째 칸에서 또 갈려요. 이 칸의 등록 번호는 BIP-44 본문이 아니라 SLIP-0044 라는 별도 문서가 관리해요. BIP-44 153번째 줄이 "This BIP is not a central directory for the registered coin types" 라고 적으며 목록을 그쪽으로 넘겨요.

제가 그 파일에서 직접 확인한 값이에요.

이 칸이 실제로 키를 가르는지 확인하려고, 같은 시드에 첫 칸을 44로 고정하고 두 번째 칸만 바꿔 공개키 해시를 뽑아 봤어요.

겹치는 값이 하나도 없죠. 다만 이 표는 주소 표기가 아니라 키가 갈린다는 것만 보여 줘요. 라이트코인이나 비트코인캐시 지갑이 화면에 띄우는 주소 표기는 각자 다른 인코딩을 쓰기 때문에 위 해시를 그대로 주소로 옮겨 적으면 안 돼요. 주소 표기가 형식마다 어떻게 달라지고 오타가 왜 걸러지는지는 주소 표기와 체크섬 구조에 따로 정리해 두었어요.

이더리움 쪽은 규격이 스스로 비호환을 적어 뒀어요

지금까지가 비트코인 형제 규격 안에서의 갈림이었다면, 이더리움 쪽은 아예 나무 모양이 달라요. 그리고 그 문서가 자기 입으로 지갑끼리 안 맞는다고 적어 뒀어요. ERC-601 의 18번째 줄이에요.

"different Ethereum clients and wallets use different derivation paths; a summary of them can be found here. Some of these paths violate BIP44, the standard defining derivation paths starting with m/44'/. This creates confusion and incompatibility between wallet implementations, in some cases making funds from one wallet inaccessible on another"

같은 계열의 ERC-600 18번째 줄도 같은 진단을 적어요. "several competing derivation path strategies have sprung up for deterministic wallets, resulting in inter-client incompatibility."

이유는 ERC-601 의 20번째 줄에 있어요. "BIP44 was designed with UTXO-based blockchains in mind, and is a poor fit for Ethereum, which uses an accounts abstraction instead." 바로 앞 인용이 ERC-600 이라 헷갈리기 쉬운데 이 문장은 ERC-601 쪽이에요. ERC-600 은 같은 뜻을 자기 18번째 줄에서 "Because Ethereum is based on account balances rather than UTXO, the hierarchy defined by BIP44 is poorly suited" 라고 적어요. 비트코인은 잔돈을 쪼개 들고 다니는 구조라 거스름 체인과 주소 인덱스가 필요한데, 이더리움은 계정 잔고 하나라 그 칸들이 남는다는 거예요.

그래서 ERC-601 이 제안하는 구조가 이래요. 28번째 줄이에요.

m / purpose' / subpurpose' / EIP' / wallet'

여기서 ERC-600 과 ERC-601 을 섞어 읽으면 안 돼요. 두 문서는 칸 수가 달라요. ERC-600 은 자기 21번째 줄에 "We define the following 2 levels in BIP32 path" 라고 적고 24번째 줄에 m / purpose' / subpurpose' / EIP', 즉 m 뒤 세 칸만 두어요. 거기에 wallet 칸을 하나 더 얹어 네 칸으로 만든 쪽이 ERC-601 이고, 그 선언이 25번째 줄의 "We define the following 4 levels in BIP32 path" 예요. 이 글이 계산한 m/43'/60'/601'/0' 값은 뒤쪽 구조를 따른 거예요.

BIP-44 와 나란히 놓으면 차이가 선명해요.

hardened 범위가 특히 중요해요. ERC-601 은 39·44·49·56번째 줄에서 네 칸 모두 "Hardened derivation is used at this level" 이라고 적어요. 뒤에서 볼 이유 때문에, 이건 공개키만으로는 주소를 미리 뽑아 둘 수 없다는 뜻이 돼요.

그런데 이 문서를 현행 표준처럼 읽으면 안 돼요. 문서 앞머리와 뒷부분에 적힌 값을 그대로 옮기면 이래요.

상태는 Final 인데 테스트 케이스가 미정이고 구현 항목은 "아직 없음" 이에요. ERC-600 도 같아요. 그래서 이 글도 ERC-601 구조로 뽑은 값을 제 계산값 칸에만 넣었어요. 대조할 공식 벡터가 문서에 없으니 그럴 수밖에 없어요.

한 가지 더 짚어 둘게요. 이 세 문서(ERC-55·600·601)는 원래 찾던 저장소에 없어요. 예전 경로로 요청하면 ERC-55 는 128바이트, ERC-600 과 ERC-601 은 각각 130바이트짜리 짧은 응답이 오는데, 크기만 보고 없는 문서로 넘기면 틀려요. 열어 보면 "이 파일은 다른 저장소로 옮겨졌다"는 안내예요. 옮겨진 쪽으로 다시 요청해야 원문이 나와요.

앞 세 칸이 hardened 인 것은 표기 습관이 아니라 능력의 경계예요

경로에 붙는 작은 따옴표를 그냥 관례로 넘기기 쉬운데, 이건 할 수 있는 일과 없는 일을 가르는 선이에요. BIP-32 가 규정으로 적어 뒀어요.

• 66번째 줄: 인덱스 0부터 2의 31제곱 빼기 1까지가 일반 자식, 2의 31제곱부터가 hardened 자식이에요.
• 87번째 줄: 공개키만으로 자식을 만드는 함수는 "only defined for non-hardened child keys" 예요.
• 89번째 줄: hardened 자식을 요구하면 "return failure" 예요. 그냥 안 되는 게 아니라 실패로 정의돼 있어요.

이게 실제로 어떤 차이를 만드는지 계정 하나를 잡고 확인해 봤어요. 84 경로 계정 0번의 zpub 을 꺼낸 다음, 그 zpub 만으로 뽑을 수 있는 것과 없는 것을 갈라 봤어요.

네 번째 칸과 다섯 번째 칸은 hardened 가 아니라서, 계정 확장 공개키 하나만 있으면 그 계정의 주소를 얼마든지 뽑을 수 있어요. 반면 세 번째 칸은 hardened 라서 계정 사이를 건널 수 없어요. BIP-32 213번째 줄이 그 설계 의도를 적어요. 계정 아래 개인키가 새더라도 "never risks compromising the master or other accounts" 가 되게 하려는 거예요.

뒤집어 말하면 계정 확장 공개키는 일반 공개키보다 훨씬 조심해서 다뤄야 해요. BIP-32 212번째 줄이 그 위험을 직접 적어요. 계정 확장 공개키와 그 아래 일반 개인키 하나를 함께 알면 계정 확장 개인키를 아는 것과 같아진다고요. 지갑을 어디에 어떻게 보관할지 고민할 때 하드웨어 지갑과 핫월렛의 차이를 같이 보면 이 부분이 왜 중요한지 감이 잡혀요.

경로가 같아도 안 보이는 자리가 두 개 더 있어요

경로를 맞췄는데도 잔액이 안 보이는 경우가 있어요. 원인이 경로 밖에 두 개 더 있거든요.

갭 리밋 20

BIP-44 124번째 줄이에요.

"Address gap limit is currently set to 20. If the software hits 20 unused addresses in a row, it expects there are no used addresses beyond this point and stops searching the address chain. We scan just the external chains, because internal chains receive only coins that come from the associated external chains."

연속으로 안 쓴 주소 스무 개를 만나면 거기서 멈춘다는 뜻이에요. 그래서 주소를 계속 새로 뽑기만 하고 중간을 비워 두면, 다른 지갑에서 복구할 때 그 너머가 안 잡힐 수 있어요. 129번째 줄은 지갑 소프트웨어가 이 한도를 넘기려 할 때 사용자에게 경고하라고 적어요.

계정 탐색에도 비슷한 멈춤이 있어요. 103번째 줄부터의 절차를 보면, 계정 0번의 외부 체인에 거래 이력이 없으면 그 자리에서 탐색을 끝내요. 118번째 줄이 중요한데, 판단 기준이 잔고가 아니라 거래 이력이에요. 잔고가 0이어도 이력이 있으면 다음 계정으로 넘어가요.

패스프레이즈 칸

이건 대조 작업 중에 확인한 자리예요. BIP-39 공식 테스트 벡터 파일을 받아 대조했는데 시드가 안 맞았어요. 이유를 찾아보니 그 벡터는 패스프레이즈를 TREZOR 로 두고 만든 값이었어요. 실제로 두 경우를 다 돌려 보니 이렇게 갈렸어요.

단어 열두 개가 완전히 같고 경로도 완전히 같은데 주소가 달라요. 패스프레이즈는 PBKDF2 의 salt 에 들어가서 시드 자체를 바꾸거든요. 그러니까 "시드 문구만 적어 두면 된다"는 생각이 위험한 이유가 여기 있어요. 문구를 아무리 잘 보관해도 패스프레이즈를 잊으면 그 나무로는 못 돌아가요. 시드 문구 자체를 어떻게 보관해야 하는지는 시드 문구 백업과 복구에 정리해 두었어요.

잔액이 0으로 보일 때 원문 기준으로 짚어 볼 자리

주소가 갈리는 이유를 규격에서 확인했으니, 실제로 마주쳤을 때 어디를 봐야 하는지 정리해 둘게요. 아래는 어디를 확인하라는 목록이지 자산을 어디로 옮기라는 안내가 아니에요.

• 지갑이 표시하는 주소가 1 로 시작하는지, 3 인지, bc1q 인지, bc1p 인지 확인했다
• 그 표기가 각각 44·49·84·86 경로에 대응한다는 것을 이 글의 첫 표로 대조했다
• 지갑 설정에 파생 경로 표기가 그대로 노출되는지 찾아봤다
• 확장키를 내보낼 때 접두어가 xpub 인지 ypub 인지 zpub 인지 확인했다
• 그 접두어가 SLIP-0132 등록표의 어느 행에 해당하는지 대조했다
• 두 번째 칸이 0인지 1인지 확인했다 (1이면 테스트넷이라 메인넷 잔액이 안 보인다)
• 계정 번호를 0번 말고 다른 번호로 만든 적이 있는지 떠올렸다
• 패스프레이즈를 설정한 적이 있는지 확인했다 (설정했다면 문구만으로는 같은 나무가 안 나온다)
• 주소를 스무 개 넘게 건너뛰며 쓴 적이 있는지 확인했다 (갭 리밋)
• 규격 문서에 실린 시험용 시드와 개인키에는 어떤 자산도 넣지 않았다

오해와 원문을 한 표로

이 글에서 확인하지 못한 것

범위를 밝혀 둘게요.

• 지갑 벤더별 기본 경로. 어느 지갑이 기본으로 어떤 경로를 쓰는지는 벤더 공식 문서를 직접 열지 않았기 때문에 이 글에 쓰지 않았어요. 규격이 스스로 적은 ERC-601·ERC-600 의 두 문장까지만 인용했어요.
• 이더리움 주소값의 외부 검증. 이 글의 이더리움 주소는 어느 규격에도 그 값이 실려 있지 않아서, 제 구현이 ERC-55 케이스 여덟 건과 Keccak-256 표준 벡터 두 건, 그리고 SLIP-0014 의 이더리움 벡터(문구가 다른 별도 시드 기준)를 재현했다는 것까지가 근거예요. 규격의 권위로 제시하는 값이 아니에요.
• ERC-601 의 상태 변경 이력. 문서에 지금 적힌 값(Final)은 읽었지만, 이 문서가 언제 어떤 상태를 거쳤는지 저장소 이력까지는 이번에 열지 않았어요.
• 주소 형식별 실제 지원 현황. 어느 거래소나 서비스가 어떤 주소 형식을 지원하는지는 이 글에서 다루지 않았어요. 규격 문서만 봤어요.
• 멀티시그 경로. SLIP-0132 등록표에는 멀티시그용 대문자 접두어 행도 있는데, 이 글은 단일 키 경로만 다뤘어요.
• 다른 체인의 파생 관행. 솔라나·리플처럼 SLIP-0044 에 번호만 있고 별도 파생 규격이 따로 있는 체인들은 이번에 열지 않았어요.
• BIP-32 의 전체 테스트 벡터. 제 구현은 BIP-49·84·86·SLIP-0132·ERC-55 벡터로 검증했고, BIP-32 문서 자체의 벡터 전수는 돌리지 않았어요.

자주 묻는 질문 (FAQ)

Q. 다른 지갑에 시드 문구를 넣었더니 잔액이 0으로 나와요. 코인이 사라진 건가요?

경로가 다르면 그렇게 보일 수 있어요. 열두 단어에서 나오는 건 주소가 아니라 나무 한 그루인데, 지갑마다 기본으로 타고 내려가는 가지가 다르거든요. 이 글에서 잰 것처럼 첫 칸만 44에서 84로 바뀌어도 첫 수신 주소가 1LqB 로 시작하는 값에서 bc1q 로 시작하는 값으로 완전히 달라져요. 다만 원인이 경로 밖에 있을 수도 있어요. 패스프레이즈를 설정했었는지, 두 번째 칸이 테스트넷(1)으로 잡혀 있지는 않은지, 계정 번호를 0번 말고 다른 번호로 쓰지 않았는지도 같이 확인해 보세요.

Q. xpub, ypub, zpub 은 뭐가 다른가요?

담고 있는 정보의 종류는 같고 앞에 붙은 버전 바이트만 달라요. BIP-43 은 원래 어느 경우에도 xpub 버전 바이트(0x0488B21E)를 쓰라고 권고했는데, 세그윗이 들어오면서 같은 xpub 을 받아도 어느 주소 형식으로 읽어야 할지 알 수 없는 문제가 생겼어요. 그래서 BIP-49 가 0x049d7cb2(ypub), BIP-84 가 0x04b24746(zpub)로 바꿔 달았어요. 즉 접두어는 "이 확장키를 어느 경로 규격으로 읽으라"는 표시예요. 재미있는 건 BIP-86 이에요. 새 접두어를 만들지 않고 xpub 계열로 돌아갔어요.

Q. 경로에 붙는 작은 따옴표는 무슨 뜻인가요?

hardened 파생이라는 표시예요. 인덱스에 2의 31제곱을 더한다는 뜻이고, 실무적으로는 공개키만으로는 그 아래로 못 내려간다는 뜻이에요. BIP-32 는 공개키 파생 함수가 hardened 자식에 대해서는 실패를 반환한다고 규정해요. BIP-44 경로에서 앞 세 칸이 hardened 인 이유가 여기 있어요. 계정 아래 개인키가 하나 새더라도 다른 계정이나 마스터키까지 위험해지지는 않게 하려는 설계예요.

Q. 그러면 계정 확장 공개키(zpub 같은 것)는 남에게 줘도 안전한가요?

일반 공개키만큼 가볍게 다룰 것은 아니에요. 그 계정의 수신 주소와 거스름 주소를 전부 뽑을 수 있으니 거래 내역이 통째로 노출돼요. 이 글에서 확인해 보니 계정 zpub 하나로 수신 0번부터 계속, 그리고 거스름 체인까지 다 나왔어요. 다른 계정으로는 못 건너가지만요. 게다가 BIP-32 는 계정 확장 공개키와 그 아래 일반 개인키 하나를 함께 알면 계정 확장 개인키를 아는 것과 같아진다고 적어요.

Q. BIP-44 를 쓰면 이더리움에서 문제가 되나요?

문제가 된다기보다 규격끼리 의견이 갈려 있어요. ERC-600 과 ERC-601 은 BIP-44 가 UTXO 전제로 설계돼서 계정 모델인 이더리움에 잘 안 맞는다고 적고, 첫 칸을 43으로 바꾼 별도 구조를 제안해요. 다만 두 문서의 칸 수가 달라요. ERC-600 은 m 뒤 세 칸(m/43'/60'/EIP')이고, ERC-601 은 거기에 wallet 칸을 더한 네 칸(m/43'/60'/601'/wallet')이에요. 이 글이 계산한 값은 뒤쪽 구조예요. 다만 그 두 문서는 상태가 Final 로 적혀 있는데도 Test Cases 항목이 TBD 이고 Implementation 은 None yet 이에요. 실무에서 널리 쓰이는 쪽은 여전히 44 로 시작하는 경로인데, 그 사실 자체를 ERC-600 이 Rationale 절에서 "The existing convention" 이라고 인정하고 있어요.

Q. 이 글의 주소를 그대로 믿어도 되나요?

두 종류를 갈라서 보셔야 해요. 44·49·84·86 경로의 첫 수신 주소 네 개는 SLIP-0132 와 BIP-86 이 문서에 인쇄해 둔 공개 테스트 벡터라, 제가 만든 값이 아니라 규격이 실은 값이에요. 반면 이더리움 주소들과 계정 1번, 거스름 체인 주소 같은 값은 어느 규격에도 그 값이 실려 있지 않아서 제가 계산한 값이에요. 뒤쪽은 제 구현이 규격 벡터 서른여섯 건을 재현했다는 근거까지만 있어요. 다만 경로까지 놓고 보면 이야기가 조금 달라요. SLIP-0014 는 이더리움 경로를, SLIP-0032 는 계정 1번 확장키를, SLIP-0019 는 거스름 체인 경로를 각각 실어 뒀어요. SLIP-0014 와 SLIP-0019 는 시드 문구가 달라서 값이 다르고, SLIP-0032 는 문구가 같지만 주소가 아니라 확장키까지만 실어요.

Q. 제가 직접 같은 계산을 해 볼 수 있나요?

절차는 이 글 앞부분의 표에 그대로 적어 두었어요. 표준 라이브러리만으로도 되고 외부 지갑 라이브러리가 꼭 필요하지는 않아요. 다만 검증 순서를 꼭 지키세요. 먼저 규격 문서의 공개 벡터를 재현하는지 확인하고, 그게 맞은 다음에야 벡터가 없는 경로를 뽑아 보는 순서예요. 그리고 실제 자산이 든 시드 문구는 어떤 스크립트에도 넣지 마세요. 규격 문서에 공개된 시험용 문구로만 연습하시는 게 맞아요.

정리

• 시드 문구에서 나오는 것은 주소가 아니라 나무예요. 경로 첫 칸이 44냐 49냐 84냐 86이냐에 따라 같은 시드에서 첫 수신 주소가 넷으로 갈려요. 같은 시드, 메인넷, 계정 0번, 외부 체인, 첫 주소까지 고정하고 첫 칸만 바꾼 결과예요.
• 이 네 값은 제가 만든 게 아니라 SLIP-0132 와 BIP-86 이 문서에 인쇄해 둔 공개 테스트 벡터예요. 제 구현이 이 값들을 포함해 규격 벡터 서른여섯 건을 전부 재현했어요.
• 확장키 접두어는 합의 규칙이 아니에요. BIP-43 은 항상 xpub 을 쓰라고 권고했는데 BIP-49 가 ypub, BIP-84 가 zpub 으로 갈라섰고 BIP-86 은 새 접두어 없이 xpub 계열로 돌아왔어요.
• 다른 지갑에서 계정이 안 잡히는 것은 버그가 아니라 설계예요. BIP-49 와 BIP-84 는 그 선언을 글자까지 똑같은 문장으로 적어 뒀고, BIP-86 은 같은 뜻을 줄여 적어요. 반면 BIP-44 에는 그 절 자체가 없고 대신 갭 리밋 20 이 있어요.
• 두 번째 칸만 바꿔도 키가 갈려요. 등록 번호는 SLIP-0044 가 관리하고 BIP-44 본문은 목록을 그쪽으로 넘겨요.
• 이더리움 쪽은 ERC-601 이 "한 지갑의 자금이 다른 지갑에서 접근되지 않는 경우가 있다"고 규격 본문에 직접 적고 네 칸 구조를 제안해요. 다만 그 문서는 status 가 Final 인데 Test Cases 는 TBD, Implementation 은 None yet 이에요.
• 경로가 같아도 갈리는 자리가 둘 더 있어요. 연속 미사용 주소 스무 개에서 탐색이 멈추는 갭 리밋과, 시드 자체를 바꿔 버리는 패스프레이즈 칸이에요.
• 🔴 이 글에 나오는 시드 문구와 개인키는 전부 규격 문서에 공개된 시험용 값이에요. 여기에 실제 자산을 넣으면 안 돼요.

숫자를 외우는 것보다 남길 만한 건 순서예요. 지갑이 보여 주는 주소가 무엇으로 시작하는지 보고, 그 표기가 어느 첫 칸에 해당하는지 이 글의 첫 표로 대조하고, 그다음에 두 번째 칸과 계정 번호와 패스프레이즈를 차례로 짚어 보세요. 그러면 "코인이 사라졌다"와 "다른 가지를 보고 있다"를 구분할 수 있어요.

이 글은 BIP·SLIP·ERC 규격 원문을 직접 내려받아 정리하고 그 문서의 공개 테스트 벡터로 계산을 검증한 정보 제공 글이며 매매를 권유하는 글이 아니에요. 특정 자산을 사거나 팔라는 뜻으로 읽지 말아 주세요. 가상자산은 변동성이 크고 원금 손실 위험이 있으며, 거래와 보유의 판단과 책임은 본인에게 있어요.

확인한 자료: BIP-0032(28,032바이트)·BIP-0039(6,842바이트)·BIP-0043(2,437바이트)·BIP-0044(6,710바이트)·BIP-0049(5,546바이트)·BIP-0084(4,648바이트)·BIP-0086(5,896바이트) 원문, SLIP-0044(91,232바이트)·SLIP-0132(9,197바이트), ERC-55(3,674바이트)·ERC-600(2,957바이트)·ERC-601(3,992바이트), 그리고 BIP-39 공식 테스트 벡터 파일(152,400바이트). 여기까지는 2026년 8월 20일 오후 3시 38분(한국 시각)에 직접 내려받아 sha256 을 대조했고, 파생 계산은 같은 날 오후 3시 40분부터 3시 44분 사이에 표준 라이브러리만으로 돌렸어요. 벡터가 있는지를 값이 아니라 경로 기준으로 다시 훑으면서 같은 날 오후 4시 44분에 SLIP-0014(19,338바이트)와 그 addresses.md(14,539바이트)·SLIP-0019(26,042바이트)·SLIP-0032(12,170바이트)를 추가로 내려받았고, 그 문서들이 실은 값도 같은 방식으로 직접 재현해 대조했어요.