🔑 비트코인 개인키는 32바이트 숫자예요, 메인넷 WIF는 5나 K·L로 시작해요

비트코인 개인키는 1부터 n-1 사이의 32바이트 숫자예요. n은 비트코인이 쓰는 타원곡선 secp256k1의 위수(curve order)라는 고정된 상수이고, n-1을 십진수로 쓰면 78자리예요. 같은 숫자를 16진수로 적으면 64글자이고, 비트코인 코어가 쓰는 WIF(Wallet Import Format) 형식으로 메인넷 키를 적으면 압축 공개키용은 K나 L로 시작하는 52글자, 비압축 공개키용은 5로 시작하는 51글자예요. 이 5와 K·L 규칙은 메인넷 WIF에만 맞아요. 테스트넷 WIF는 9나 c로 시작하고, 메인넷 확장 개인키는 xprv로 시작하는 111글자라 모양이 달라요.

2026년 10월 7일 오전 10시 56분부터 11시 1분 사이(한국 시각)에 비트코인 코어 공식 저장소에서 정식판 가운데 가장 높은 번호인 31.1의 소스를 받아 확인한 내용을 먼저 요약하면 이래요.

• 범위: 코어에 들어 있는 secp256k1 라이브러리는 「0이 아니고 곡선 위수보다 작은」 32바이트 값을 유효한 개인키로 봐요. 그래서 개인키가 될 수 있는 값은 1부터 n-1까지예요.
• 생성: 코어의 새 키 생성 함수는 강한 난수로 32바이트를 뽑고, 유효성 검사를 통과할 때까지 다시 뽑아요. 무작위 32바이트가 이 범위를 벗어날 비율은 이 글의 계산으로 약 3.7×10⁻³⁹이에요.
• WIF: 메인넷 접두 바이트 128, 개인키 32바이트, 압축 공개키용이면 0x01 한 바이트를 차례로 붙이고, 끝에 4바이트 체크섬을 더해 Base58 문자로 바꿔요. 맨 앞 접두가 고정이라 메인넷 WIF의 첫 글자가 5나 K·L로 정해져요.
• 다른 모양: 16진수는 64글자, 테스트넷 WIF(접두 239)는 9나 c로 시작, 메인넷 확장 개인키는 xprv로 시작하는 111글자예요. 코어 지갑의 디스크립터 문자열 안에는 WIF나 xprv가 들어갈 수 있어요.
• 확인 명령: 코어 30.0에서 dumpprivkey, dumpwallet, importprivkey를 포함한 옛 지갑 전용 명령 11개가 빠졌어요. 31.1에서는 listdescriptors true나 gethdkeys의 private 옵션으로 개인키가 담긴 문자열을 볼 수 있어요.

이 글은 소스와 공식 문서에 적힌 값과 명령을 정리했고, 직접 계산한 값은 그 자리에 이 글의 계산이라고 따로 적었어요. 이 글에서 전체를 적은 개인키 값은 누구나 아는 1과 n-1뿐이고, 키 문자열로 끝까지 적은 것은 1로 만든 공개 시험값뿐이에요. 둘 다 누구나 계산할 수 있는 값이라 실제 키로 쓰면 안 돼요. 특정 지갑 제품을 고르거나 권하지 않고, 코인 매수나 매도를 권하지도 않아요.

이 글이 읽은 파일

2026년 10월 7일 오전 10시 56분부터 58분 사이(한국 시각)에 아래 파일을 받았고, 11시 0분에 전부 다시 받아 바이트 단위로 대조했어요. 두 번 받은 파일 14개는 모두 같았어요. bitcoin-wallet 도구 파일 3개는 같은 날 오전 11시 20분에 따로 받았어요. 조회 시점 GitHub 정식판 가운데 가장 높은 번호는 2026년 7월 8일 공개된 v31.1이었어요(7월 10일에 나온 v30.3, v29.4는 공개일은 더 늦지만 번호가 낮은 30·29 계열이에요). 태그 목록 맨 위에는 정식판이 아닌 32.0 후보판(v32.0rc3)이 있었어요.

개인키는 어떤 숫자인가요

key.h 53행은 개인키 원재료를 담는 자료형을 부호 없는 바이트 32칸짜리 배열로 정했어요. 주석은 이 자리를 「개인키 원재료를 담는 내부 그릇」이라고 불러요. 그러니까 비트코인 개인키는 256비트, 곧 32바이트로 적을 수 있는 큰 정수 하나예요.

다만 32바이트로 쓸 수 있는 값이 전부 개인키가 되지는 않아요. 코어가 함께 싣는 secp256k1 라이브러리의 설명(secp256k1.h 671-684행)은 이렇게 적었어요.

A secret key is valid if it is not 0 and less than the secp256k1 curve order when interpreted as an integer (most significant byte first).

0이 아니고, 앞 바이트부터 읽은 정수가 곡선 위수보다 작아야 유효하다는 뜻이에요. 곡선 위수 n은 같은 라이브러리의 scalar_4x64_impl.h 16-19행에 64비트 상수 네 개로 나뉘어 적혀 있어요. 이어 붙이면 아래 값이에요.

십진수 변환과 자릿수는 위 상수로 이 글이 직접 계산했어요. 2의 256제곱에서 n을 빼면 432420386565659656852420866394968145599로 39자리예요. 78자리 숫자 가운데 39자리만큼만 빠지는 셈이라, 32바이트 값의 거의 전부가 유효한 개인키예요.

헷갈리기 쉬운 숫자도 하나 있어요. key.h 41-42행에는 279와 214라는 크기 상수가 있는데, 같은 파일 21-25행 주석은 이것을 「모든 매개변수를 포함한 직렬화된 개인키」의 크기라고 설명해요. 개인키 숫자 자체는 32바이트이고, 279바이트나 214바이트는 그 숫자에 다른 정보를 덧붙여 저장할 때의 크기예요.

코어는 개인키를 이렇게 만들어요

key.cpp 162-168행의 새 키 생성 함수는 짧아요. 강한 난수 함수로 32바이트를 채우고, 그 값이 앞의 유효성 검사(key.cpp 158-160행, 라이브러리 검사 함수를 그대로 부름)를 통과하지 못하면 다시 채우는 반복문이에요. 통과하면 압축 공개키를 쓸지 표시만 덧붙이고 끝나요.

난수 함수의 설명(random.h 119-129행)은 「여러 출처에서 엔트로피를 모아 내부 난수 생성기에 넣고, 그것으로 난수를 만든다」고 적었어요. 운영체제 난수 생성기가 실패하면 이 함수도 실패하고, 시험 모드에서도 일반 난수 생성기를 건너뛰지 않는다고 덧붙였어요.

그럼 다시 뽑는 일은 얼마나 생길까요. 무효인 값은 0 하나와 n 이상인 값이라, 그 개수를 2의 256제곱으로 나누면 비율이 나와요. 이 글의 계산으로는 약 3.7×10⁻³⁹, 소수점 아래로 0이 38개 이어진 뒤에야 3이 나오는 크기예요. 라이브러리 설명도 균등한 무작위 32바이트가 무효일 확률은 무시할 만하다(negligible)고 적었어요.

흥미로운 차이가 하나 있어요. 같은 라이브러리 설명은 만약 무효 값이 나오면 「난수원이 심하게 고장 났다고 봐야 하고 다시 시도하지 말아야 한다」고 적었는데, 코어의 생성 함수는 통과할 때까지 다시 뽑는 반복문이에요. 이 글은 어느 쪽이 옳은지 판단하지 않고 두 원문을 그대로 옮겼어요.

개인키를 해독하거나 무작위로 맞히는 방법을 찾는 분도 있을 텐데, 이 글이 소스로 확인한 건 개인키가 될 수 있는 값이 78자리 숫자만큼 있다는 데까지예요. 맞히는 데 걸리는 시간은 계산하지 않았어요. 공개키에서 개인키를 거꾸로 계산하는 양자컴퓨터 공격 논의는 양자컴퓨터와 공개키가 드러나는 주소 형식 정리에서 따로 다뤘어요.

같은 숫자를 적는 여러 모양

WIF는 이렇게 만들어요

비트코인 코어가 개인키를 글자로 바꾸는 함수는 key_io.cpp 231-242행에 있어요. 순서대로 옮기면 이래요.

1. 네트워크 접두 바이트 하나를 둬요. 메인넷은 128(16진수 80)이에요(chainparams.cpp 155행). 테스트넷(testnet3, testnet4), signet, regtest는 모두 239예요.
2. 개인키 32바이트를 이어 붙여요.
3. 압축 공개키를 쓸 키라면 0x01 한 바이트를 더 붙여요(key_io.cpp 236-238행).
4. 지금까지의 바이트를 SHA-256으로 두 번 해시하고, 그 앞 4바이트를 체크섬으로 끝에 붙여요(base58.cpp 137-144행, hash.h 23-24행).
5. 전체를 Base58 문자로 바꿔요. 문자표 58글자에는 숫자 0, 대문자 O, 대문자 I, 소문자 l이 없어요(base58.cpp 20행).

거꾸로 읽는 함수(key_io.cpp 213-229행)는 체크섬을 다시 계산해 맞는지 보고, 접두 바이트 뒤가 32바이트이거나 「33바이트이면서 마지막 바이트가 1」일 때만 받아들여요. 33바이트 쪽이면 압축 공개키용 키로 읽어요. 그래서 0x01은 다른 개인키를 뜻하는 게 아니라, 같은 숫자에서 어떤 모양의 공개키를 쓸지 정하는 표시예요. 공개키는 압축이면 33바이트(16진수로 02나 03으로 시작하는 66글자), 비압축이면 65바이트(04로 시작하는 130글자)예요(pubkey.h 39-40행, descriptors.md 81행). 4바이트 체크섬이 오타를 얼마나 잡는지는 지갑 주소 오타 감지 방식 정리에서 주소를 예로 다뤘어요.

왜 5나 K·L로 시작하나요

위 규칙을 그대로 구현해 가장 작은 개인키(1), 중간쯤 값(2의 255제곱), 가장 큰 개인키(n-1)를 인코딩해 봤어요. 이 표의 길이와 앞 두 글자는 소스의 규칙대로 이 글이 직접 계산한 값이에요.

가장 작은 값과 가장 큰 값의 길이가 같고, Base58은 숫자의 크기 순서를 그대로 지켜요. 그래서 그 사이에 있는 모든 개인키도 같은 길이와 같은 첫 글자 범위에 들어가요. 메인넷 비압축 WIF는 5H, 5J, 5K로 시작하는 51글자, 압축 WIF는 K나 L로 시작하는 52글자가 되는 이유예요. 맨 앞 접두 바이트(128) 하나가 첫 글자를 거의 정하고, 압축 표시 0x01 한 바이트가 길이를 한 글자 늘리면서 첫 글자를 K·L 쪽으로 옮겨요.

개인키 값이 1인 키를 실제 글자로 적으면 아래와 같아요.

🔴 테스트값, 절대 입금 금지. 개인키 값 1은 누구나 아는 값이라, 이 키로 만든 주소에 코인을 보내면 누구든 가져갈 수 있어요.

메인넷 비압축: 5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreAnchuDf

메인넷 압축: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73sVHnoWn

같은 숫자 1인데 끝에 0x01을 붙였는지에 따라 글자 수와 첫 글자가 달라졌어요. 내 지갑에서 나온 개인키가 5로 시작하든 K로 시작하든, 그 자체로 어느 쪽이 맞거나 틀린 게 아니에요.

16진수, 확장 개인키, 디스크립터

같은 개인키라도 지갑이나 도구에 따라 다른 모양으로 보일 수 있어요.

확장 개인키는 개인키 하나가 아니라 아래로 키를 계속 만들어 낼 수 있는 묶음이에요. key.cpp 513-521행은 깊이 1바이트, 부모 지문 4바이트, 자식 번호 4바이트, 체인코드 32바이트, 0 한 바이트, 개인키 32바이트를 차례로 적어 74바이트를 만들고, key_io.cpp 283-292행이 그 앞에 메인넷 버전 4바이트(0x04 0x88 0xAD 0xE4, chainparams.cpp 157행)를 붙여 Base58로 바꿔요. 78바이트를 Base58로 바꾼 길이(111글자)와 첫 네 글자(xprv)는 이 글이 가장 작은 값과 가장 큰 값으로 계산해 확인했어요. 확장 키에서 경로를 따라 키를 내려 만드는 방식은 지갑 파생 경로 BIP-44·49·84·86 정리에서 다뤘어요.

코어 지갑은 키를 디스크립터라는 설명문으로 관리해요. 디스크립터 문서(descriptors.md 84-85행, 237-244행)는 공개키나 xpub이 들어가는 자리에 WIF 형식 개인키나 xprv를 대신 넣을 수 있다고 적었어요. 그리고 개인키가 필요한 경우로 강화(hardened) 파생, 거래 서명, 개인키가 포함된 지갑 디스크립터 출력을 들었어요. 그래서 코어 지갑에서 아래 listdescriptors로 개인키를 꺼내 보면 WIF 한 줄만 따로 나오는 게 아니라, 디스크립터 문자열 안에 든 WIF나 xprv 모양으로 보여요.

코어 30.0부터 dumpprivkey가 없어요

코어에서 개인키를 뽑는 명령으로 dumpprivkey를 떠올리는 분이 있을 텐데, 이 명령은 코어 30.0에서 빠졌어요. v30.0 릴리스 노트 지갑 절(265-270행)의 문장은 이래요.

the legacy-only RPCs addmultisigaddress, dumpprivkey, dumpwallet, importaddress, importmulti, importprivkey, importpubkey, importwallet, newkeypool, sethdseed, and upgradewallet, are removed.

옛 지갑 형식에서만 쓰던 명령 11개가 빠졌다는 뜻이에요. 바로 위 문장(261-263행)은 「BDB 형식의 옛 지갑(legacy wallet)은 더 이상 만들거나 불러올 수 없고, 새 디스크립터 지갑 형식으로 옮길 수 있다」며 migratewallet 명령을 참고하라고 적었어요.

빠진 것은 명령이고, 옛 지갑을 옮기는 길은 릴리스 노트가 따로 적어 두었어요. 31.1의 migratewallet 도움말(wallet.cpp 582-592행)은 옮기기 전에 지갑 백업 파일을 먼저 만들어 같은 지갑 폴더에 「지갑이름-시각.legacy.bak」 형식 이름으로 두고, 옮기기가 잘못되면 restorewallet으로 그 백업을 되살릴 수 있다고 적었어요. 암호화한 지갑은 이 명령에 비밀번호를 함께 넣어야 하고, 옮긴 뒤에는 새 백업을 만들어야 한다고도 했어요.

31.1의 지갑 명령 등록 목록(wallet.cpp 904-964행)에도 dumpprivkey, dumpwallet, importprivkey는 없었어요. 주소 하나의 WIF만 따로 뽑아 주는 전용 명령도 이 목록에서는 찾지 못했어요.

코어 31.1에서 개인키를 확인하는 명령

31.1의 bitcoin-cli 지갑 명령(RPC) 가운데 개인키가 담긴 문자열을 보여 주는 것은 아래 두 가지예요.

두 명령 모두 private 값의 기본은 false라서, 옵션 없이 실행하면 공개 정보만 나와요. listdescriptors는 개인키를 쓰지 않도록 만든 감시 전용 지갑에서 private를 켜면 「감시 전용 지갑에서는 개인 디스크립터 문자열을 가져올 수 없다」는 오류를 내요. 암호화한 지갑은 두 명령 모두 먼저 잠금을 풀어야 하고, 잠금을 푸는 명령 walletpassphrase는 등록 목록에 있어요.

RPC가 아닌 쪽에서도 개인키가 담길 수 있는 출력을 하나 확인했어요. 31.1 소스에 함께 들어 있는 bitcoin-wallet 도구의 dump 명령이에요(RPC였던 dumpwallet과는 다른 명령이에요). 도구 도움말(bitcoin-wallet.cpp 45행)은 이 명령을 「지갑의 키-값 기록을 전부 출력한다」고 설명하고, 실제로는 -dumpfile 옵션으로 정한 파일에 지갑 기록을 한 줄씩 16진수로 적어요(bitcoin-wallet.cpp 39행, dump.cpp 24-110행). 파일을 다 쓰고 나면 도구가 아래 문장을 출력해요(wallettool.cpp 153행).

The dumpfile may contain private keys. To ensure the safety of your Bitcoin, do not share the dumpfile.

덤프 파일에 개인키가 들어 있을 수 있으니, 비트코인을 안전하게 지키려면 이 파일을 공유하지 말라는 뜻이에요. 기록을 16진수로 옮긴 파일이라 위 두 명령의 출력과 모양은 다르지만, 도구의 경고대로 개인키가 담긴 파일처럼 다뤄야 해요.

디스크립터 문서가 개인키를 거래 서명에 필요한 것으로 적었듯, 두 명령의 출력에는 코인을 옮기는 데 쓰이는 정보가 그대로 담겨요. 화면 공유나 메신저, 클라우드 메모에 옮기지 않는 편이 안전해요. 코어 지갑에서 xpub만 뽑아 멀티시그를 만드는 순서는 멀티시그 지갑 키 한도 정리에, 시드 문구를 보관하는 방법은 시드 문구 백업·복구 정리에 따로 있어요.

32.0 후보판(v32.0rc3)의 지갑 소스에는 지갑의 HD 키에서 경로를 지정해 확장 공개키나 확장 개인키를 뽑는 derivehdkey 명령이 새로 있고, 여기에도 private 옵션이 있었어요. 아직 정식판이 아니라서 이 글은 31.1 기준으로 적었어요. 같은 후보판에서도 메인넷 접두 128과 새 키 생성 반복문, listdescriptors와 gethdkeys의 private 옵션은 31.1과 같았어요.

정리

이 글이 다루지 않은 것

• 일렉트럼, 하드웨어 지갑, 모바일 지갑 같은 다른 지갑의 개인키 내보내기 방법은 제품 문서를 열지 않아서 쓰지 않았어요.
• 미니 개인키처럼 비트코인 코어가 쓰지 않는 표기, 이더리움 등 다른 체인의 개인키 형식은 다루지 않았어요.
• 개인키를 무작위로 맞히는 데 걸리는 시간은 계산하지 않았어요.
• 31.1 지갑에서 주소 하나의 WIF를 꺼내는 다른 방법이 있는지는 확인하지 않았어요.
• bitcoin-wallet 덤프 파일 안에서 개인키 기록이 어떤 모양으로 적히는지는 풀어 보지 않았어요.

모든 내용은 2026년 10월 7일 오전 10시 56분부터 11시 22분 사이(한국 시각)에 받은 비트코인 코어 v31.1 소스와 문서, v30.0 릴리스 노트 기준이에요. 다음 판에서 명령이나 문서가 바뀔 수 있어요.

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