🔐 멀티시그 지갑은 키를 몇 개까지 넣을 수 있나요, 비트코인 코어 소스로 본 주소 방식별 한도

멀티시그(multisig) 지갑은 공개키 여러 개를 하나로 묶어 두고, 그중 정해진 수만큼 서명이 모여야 코인을 옮길 수 있게 만든 지갑이에요. 키 세 개 가운데 아무 두 개의 서명이 필요하면 「2-of-3」이라고 불러요. 그럼 키는 몇 개까지 묶을 수 있을까요. 2026년 10월 5일 오후 8시 19분(한국 시각)에 비트코인 코어 공식 저장소에서 정식 최신판 31.1의 소스를 받아 읽어 보니, 답은 주소 방식마다 달랐어요.

• 베어 멀티시그(bare multisig, 출력 스크립트에 멀티시그를 그대로 넣는 방식)는 키 3개까지예요. 코어 노드가 거래를 중계할지 정하는 정책(표준성) 한도예요.
• P2SH 방식은 압축 공개키 기준 15개까지예요. 스크립트 한 덩어리가 520바이트를 넘으면 안 된다는 합의 규칙에 걸려요.
• P2WSH 방식에서 멀티시그 명령(OP_CHECKMULTISIG)을 쓰는 multi()·sortedmulti()로 만들면 20개까지예요. 이 명령 자체가 정한 합의 규칙 상한이고, 이 방식의 정책 한도는 그보다 넉넉해요. 같은 P2WSH라도 미니스크립트 thresh()로 짜면 이 상한 대신 다른 검사를 받는데, 아래에 따로 적었어요.
• 탭루트 스크립트의 multi_a는 코어 지갑이 999개까지 받아요. 소스 주석은 이 숫자가 탭스크립트의 스택 한도(원소 1,000개) 때문이라고 적었어요.

여기서 「정책」 한도를 넘는다는 건 무효라는 뜻이 아니에요. 코어의 정책 파일(policy.h)은 거래 크기 한도 같은 값에 「중계하거나 채굴할 의향이 있는(willing to relay/mine)」 거래의 기준이라는 주석을 달았어요. 노드가 무엇을 받아 퍼뜨릴지 고르는 기준이라는 뜻이고, 스크립트가 규칙에 맞는지 가르는 합의 검사는 다른 파일(interpreter.cpp)에서 해요. 아래 표에 두 성격을 나눠 적었어요.

이 글은 소스와 공식 문서에 적힌 한도와 만드는 순서를 정리한 글이에요. 특정 지갑 제품을 고르거나 권하지 않고, 코인 매수나 매도를 권하지도 않아요.

이 글이 읽은 문서

2026년 10월 5일 오후 8시 19분부터 20분 사이(한국 시각)에 아래 파일을 직접 받았어요. 미니스크립트 검사 코드(miniscript.h)는 같은 날 오후 8시 48분에 같은 v31.1에서 더 받았어요. 조회 시점 GitHub의 정식 최신판은 2026년 7월 8일 공개된 v31.1이었고, 태그 목록 맨 위에는 정식판이 아닌 32.0 후보판(v32.0rc3)이 있었어요. 같은 파일을 개발 중인 master와 v32.0rc3에서도 받아 대조했는데, 이 글에 나오는 상수 13개는 세 판에서 값이 모두 같았어요.

멀티시그는 어떻게 움직이나요

멀티시그를 표준 거래로 처음 정한 문서는 2011년 10월에 번호를 받은 BIP-11이에요. 이 문서가 든 쓰임새는 두 가지예요. 하나는 2-of-2로, 내 컴퓨터의 키와 지갑 보호 서비스의 키가 함께 서명해야 돈이 나가게 하는 방식이에요. 다른 하나는 2-of-3 에스크로로, 구매자·판매자·분쟁 중재인이 키를 하나씩 갖고 둘이 동의하면 돈을 옮기는 방식이에요.

스크립트 모양은 단순해요. BIP-11은 m [pubkey]...[pubkey] n OP_CHECKMULTISIG(원문은 대괄호 자리에 중괄호 표기)처럼 필요한 서명 수 m, 공개키 n개, 키 개수 n을 차례로 적고 마지막에 멀티시그 명령을 붙인다고 적었어요. 쓸 때는 서명들 앞에 빈 값(OP_0)을 하나 더 넣어요. BIP-11은 그 이유를 「OP_CHECKMULTISIG가 스택에서 항목을 하나 더 꺼내는 버그가 있어서」라고 적었어요.

코어의 실행 코드(interpreter.cpp 1131-1132행)는 필요한 서명 수가 키 개수보다 많으면 실패로 처리해요. 디스크립터 문서는 이 구조를 「제공된 키 n개 가운데 아무 k개가 서명해야 하는 k-of-n 정책」이라고 설명해요. 그래서 2-of-3이라면 키 하나만 손에 넣어서는 코인을 옮길 수 없고, 키 하나를 잃어도 남은 두 개로 서명할 수 있어요.

주소 방식별 키 개수 한도

멀티시그 명령의 합의 상한은 20개예요

script.h 34행에 MAX_PUBKEYS_PER_MULTISIG = 20이 있고, 주석은 「멀티시그 하나에 들어가는 공개키의 최대 수」라고 적었어요. 실행 코드(interpreter.cpp 1117-1118행)는 OP_CHECKMULTISIG가 받은 키 개수가 20을 넘으면 SCRIPT_ERR_PUBKEY_COUNT 오류로 실패시켜요. 키 개수만큼 스크립트 연산 수(한도 201개)에도 더해요.

이 20개는 OP_CHECKMULTISIG를 쓰는 모든 방식에 공통으로 걸리는 바닥 규칙이에요. 베어 멀티시그와 P2SH는 그 위에 더 좁은 한도가 하나씩 더 붙어서 실제 상한이 낮아지고, P2WSH에서 multi()로 만들면 이 20개까지 그대로 가요.

베어 멀티시그는 3개에서 멈춰요

policy.cpp의 IsStandard 함수에는 「x-of-3 멀티시그까지 표준으로 지원」이라는 주석과 함께, 키 개수가 1보다 작거나 3보다 크면 표준이 아니라고 보는 조건이 있어요. 이 3은 따로 이름 붙은 상수 없이 함수 안에 숫자로 적혀 있어요. 2011년 BIP-11도 「n이 3 이하일 때만」이라고 적었어요. 같은 파일 118-125행 주석은 20-of-20 출력 스크립트를 두고 「표준으로 보지 않는다」고 적었어요. 합의 규칙으로는 20개까지 실행되지만, 기본 설정의 코어 노드는 키 4개 이상인 베어 멀티시그 출력을 만드는 거래를 중계하지 않는다는 뜻이에요.

3개 이하라도 노드 설정에 따라 막힐 수 있어요. -permitbaremultisig 옵션의 설명은 「P2SH가 아닌 멀티시그 출력을 만드는 거래를 중계」이고, 기본값은 켜짐(policy.h 51행 DEFAULT_PERMIT_BAREMULTISIG 값 true)이에요. 이 옵션을 끈 노드는 그런 거래를 bare-multisig 사유로 거부해요(policy.cpp 151-152행). 코어 지갑도 단독 multi() 디스크립터에 키를 4개 이상 넣으면 「베어 멀티시그에는 공개키를 최대 3개까지만」이라는 오류를 내요.

P2SH는 520바이트 상자에 15개가 들어가요

P2SH 출력에는 스크립트 원문이 아니라 20바이트 해시만 들어가요(BIP-16). 쓸 때 서명들과 함께 스크립트 원문(리딤스크립트)을 데이터 한 덩어리로 내밀면, 노드가 해시를 대조한 뒤 그 스크립트로 다시 검증해요. 문제는 그 한 덩어리의 크기예요. 스택에 밀어 넣는 데이터는 520바이트를 넘을 수 없고(script.h 28행 MAX_SCRIPT_ELEMENT_SIZE = 520, interpreter.cpp 447-448행), 이건 합의 규칙이에요.

압축 공개키는 33바이트이고 밀어 넣는 표시 1바이트가 붙어 키 하나에 34바이트가 들어요. 앞뒤 숫자와 명령 3바이트를 더해 직접 계산해 보면 이래요.

15개일 때 513바이트라는 값은 BIP-16의 「520바이트 제한」 절과 policy.cpp 118-125행 주석에 같은 계산식으로 적혀 있어요. BIP-16은 OP_CHECKMULTISIG 자체는 키 20개까지 받지만 압축 공개키로는 P2SH에서 15개가 최대라고 적었고, 리딤스크립트가 520바이트를 넘으면 그 P2SH 출력은 쓸 수 없다고 했어요. 앞에서 본 대로 출력에는 해시만 들어가서(BIP-16) 주소만 봐서는 뒤의 스크립트를 알 수 없다는 점(BIP-67도 같은 점을 적었어요)까지 합치면, 키를 너무 많이 넣은 P2SH 주소는 돈을 받을 수는 있어도 꺼낼 수 없는 주소가 될 수 있다는 뜻이에요. 코어 지갑은 이런 디스크립터를 처음부터 「P2SH script is too large」 오류로 거부하고, 그 자리 주석에 「압축 공개키 최대 개수를 15개로 제한한다」고 적었어요(descriptor.cpp 2367-2369행).

정책 쪽에도 같은 숫자가 있어요. policy.h 41행 MAX_P2SH_SIGOPS는 「표준 P2SH 스크립트 안의 서명 검사 연산 최대 수」로 15예요. 이 값은 키 개수를 직접 세는 규칙이 아니라 서명 검사 횟수 한도인데, 코어는 키 n개(16개 이하)짜리 멀티시그 하나를 서명 검사 n회로 세요(script.cpp 173-174행). 그래서 P2SH 멀티시그는 정책으로도 15개에서 멈춰요. 같은 주석은 15-of-15를 쓸 때 서명 부분(scriptSig)이 1,627바이트가 되고, 이를 반올림한 1,650바이트를 표준 한도(MAX_STANDARD_SCRIPTSIG_SIZE)로 삼았다고 적었어요.

P2WSH에서 멀티시그 명령으로 만들면 20개까지 가요

P2WSH는 스크립트 원문을 서명 부분이 아니라 위트니스 맨 끝 원소에 넣어요. 실행 코드(interpreter.cpp 1929행)는 그 원소를 스크립트로 따로 꺼낸 뒤 실행하기 때문에, 520바이트 한도는 스크립트 자체가 아니라 남은 원소(서명들)에만 걸려요(같은 파일 1858-1860행). 스크립트 자체의 합의 한도는 10,000바이트(428행)이고, 정책 한도는 3,600바이트(policy.h 59행 MAX_STANDARD_P2WSH_SCRIPT_SIZE)예요.

키 20개를 모두 넣은 20-of-20 스크립트를 직접 계산해 보면 685바이트로, 3,600바이트 정책 한도에 한참 못 미쳐요. 서명 쪽 정책도 넉넉해요. 위트니스 원소는 스크립트를 빼고 100개까지(policy.h 53행), 원소 하나는 80바이트까지(55행)인데, 20-of-20이라도 빈 값 1개와 서명 20개로 21개예요. 그래서 multi()로 만든 P2WSH는 정책이 아니라 합의 상한 20개가 실제 한도가 돼요. P2SH로 한 번 감싼 P2WSH도 정책 검사(policy.cpp 273-305행)에서 안쪽 P2WSH를 꺼내 같은 기준을 적용해요.

다만 이 20개는 OP_CHECKMULTISIG를 쓸 때의 상한이에요. 코어 디스크립터 문서는 P2WSH 안에서 미니스크립트 thresh()로 짠 멀티시그 예시(블록 높이에 따라 필요한 서명 수가 4개에서 1개까지 줄어드는 방식)도 실었어요(descriptors.md 50행, 182-186행). 이 모양은 키마다 OP_CHECKSIG로 따로 확인하고 결과를 더해서 20개 상한을 받지 않아요. 대신 코어 지갑은 이런 디스크립터를 받을 때 연산 201개(합의 한도), 쓸 때 필요한 위트니스 원소 100개와 스크립트 3,600바이트(정책 한도)를 넘는지 검사하고, 넘으면 받지 않아요(miniscript.h 1566-1569행, 1590-1598행, 1670-1672행, descriptor.cpp 2605행). thresh(k,pk(...),s:pk(...),...) 모양을 miniscript.h가 연산을 세는 방식대로 셈해 보면 키 n개에 연산이 3n-1개라서, 산수로는 키 67개(연산 200개)까지가 연산 한도 안에 들어가고 68개면 203개로 넘어요. 이 숫자는 계산일 뿐이고, 실제 노드에서 이런 지갑을 만들거나 거래를 보내 시험하지는 않았어요.

탭루트에서는 멀티시그 명령이 꺼져 있어요

탭루트의 스크립트 규칙인 BIP-342는 「비효율적인 OP_CHECKMULTISIG와 OP_CHECKMULTISIGVERIFY를 끈다」고 적고, 대신 OP_CHECKSIGADD라는 새 명령을 넣었어요. 코어의 실행 코드도 탭스크립트 안에서 OP_CHECKMULTISIG가 실행되면 전용 오류로 실패시켜요(interpreter.cpp 1108행). 실행되지 않는 분기 안에 있으면 무시돼요(BIP-342). 탭스크립트에서 꺼진 명령어 전체는 비트코인 스크립트에서 꺼진 명령어 정리에서 따로 다뤘어요.

BIP-342가 제시한 대체 모양은 <pubkey_1> CHECKSIG <pubkey_2> CHECKSIGADD ... <pubkey_n> CHECKSIGADD m NUMEQUAL이에요. 키마다 서명이 맞으면 1씩 더하고, 끝에서 합계가 m인지 확인하는 방식이에요. 위트니스에는 키마다 원소를 하나씩 두는데, 서명할 키 자리에는 서명을, 서명하지 않는 키 자리에는 빈 값을 넣어요. 코어 디스크립터에서는 이 모양을 multi_a라고 부르고 tr() 안에서만 쓸 수 있어요.

탭스크립트에는 스크립트 크기 10,000바이트 한도와 연산 201개 한도가 적용되지 않아요(BIP-342 128-129행). 대신 위트니스 크기에 비례하는 서명 검사 예산이 새로 생겼고, 원소 하나 520바이트 한도는 그대로예요(130-132행). 키 개수에 직접 걸리는 건 스택 원소 1,000개 한도예요. BIP-342는 이 한도를 실행 전 처음 스택에도 적용한다고 적었어요. 코어는 script.h 36-37행에 MAX_PUBKEYS_PER_MULTI_A = 999를 두고 「BIP342의 스택 한도 때문」이라고 주석을 달았어요. 키 999개를 모두 요구하는 999-of-999 스크립트를 직접 계산하면 33,970바이트예요. 다만 이렇게 큰 거래가 실제로 중계되는지는 이 글에서 시험하지 않았어요.

탭루트에는 키 여러 개를 하나로 합치는 방법도 있어요. 코어 디스크립터 문서는 tr() 안에서만 쓰는 musig() 표현을 MuSig2 키 집계라고 소개해요. BIP-342 각주는 키를 합치는 방식이 더 효율적이지만 서명을 함께 만드는 대화형 절차가 필요하다고 적었어요. musig()에 참여자를 몇 명까지 넣을 수 있는지는 이번에 코드에서 찾지 못했어요.

비트코인 코어로 2-of-3을 만드는 순서

31.1 튜토리얼의 첫 문장은 「지금은 비트코인 코어만으로 멀티시그 지갑을 만들 수 있다」예요. 디스크립터 문서와 튜토리얼(시험용 signet 네트워크 기준)이 적은 순서를 명령 이름과 함께 옮기면 이래요.

4번에서 가져오는 디스크립터는 wsh(sortedmulti(2,XPUB1/<0;1>/*,XPUB2/<0;1>/*,XPUB3/<0;1>/*)) 한 줄이에요. 끝의 <0;1>은 받는 주소(0)와 잔돈 주소(1)를 한 줄로 함께 정한다는 표시예요. 디스크립터 문서는 하드웨어 기기나 외부 서명기를 제대로 지원하려면 xpub마다 마스터 키 지문과 파생 단계 같은 출처 정보를 함께 넣으라고 적었어요.

몇 가지 주의점도 문서에 있어요.

• 멀티시그 지갑은 공동 서명자의 서명이 필요해서 단일 서명 지갑처럼 거래를 바로 만들고 서명하지 못해요. 그래서 부분 서명 거래(PSBT, BIP-174) 형식으로 주고받아요.
• 서명용 지갑 셋은 프라이버시 문제(공개키 재사용) 때문에 따로 쓰지 말고 감시 전용 멀티시그 지갑의 거래에 서명하는 데만 쓰라고 했어요.
• 튜토리얼은 받은 코인이 확인을 최소 1번 받은 뒤에 쓸 수 있다고 적었어요.
• 한 사람씩 차례로 서명해 넘기는 방식도 되는데, 이때는 combinepsbt가 필요 없고 마지막 서명자가 전파해요. 문서는 서명자가 많으면 동시에 서명하는 방식이 나을 수 있다고 적었어요.
• 같은 PSBT에 각자 서명한 것을 합칠 때 joinpsbts를 쓰면 Input txid:pos exists in multiple PSBTs 오류가 나요. 이 경우는 combinepsbt를 써요.

xpub을 뽑는 경로도 짚어 둘게요. 31.1 튜토리얼은 기본 WPKH 경로(m/84'/1'/0')에서 xpub을 뽑고, BIP-45나 BIP-87이 정한 경로를 따르지 않는다고 밝혔어요. 「지금은 코어 지갑에서 특정 경로를 뽑을 방법이 없다」고도 적었어요. 그런데 32.0 후보판(v32.0rc3)의 같은 문서에서는 이 단계가 derivehdkey라는 명령으로 m/44h/1h/0h 경로를 지정해 뽑는 방식으로 바뀌어 있었어요. 아직 정식판이 아니라서 이 글은 31.1 기준으로 적었어요. 경로 번호가 무엇을 뜻하는지는 지갑 파생 경로 BIP-44·49·84·86 정리에 있어요.

키 순서와 백업에서 갈리는 것

디스크립터 문서는 multi()에서는 키 순서가 의미를 가진다고 적었어요. 같은 키라도 순서가 다르면 다른 스크립트가 되고, 코어는 그 출력을 같은 지갑의 것으로 찾지 않아요. 반면 sortedmulti()는 키를 BIP-67 방식으로 사전순 정렬해서 스크립트를 만들기 때문에 순서가 상관없어요. BIP-67은 이렇게 정렬하면 같은 키 묶음과 같은 필요 서명 수에서 늘 같은 P2SH 주소가 나오고, 서비스 제공자 도움 없이도 다른 쪽이 지갑을 복구할 수 있다고 적었어요. 다만 비압축 공개키는 이 규격과 맞지 않는다고 했어요. 튜토리얼이 sortedmulti를 쓴 이유도 「xpub 순서를 신경 쓰지 않고 지갑을 다시 만들 수 있게」였어요.

백업에서 갈리는 점도 여기서 나와요. 튜토리얼은 디스크립터 한 줄이 출력 방식(wsh)과 참여한 xpub들을 정한다고 설명해요. 주소는 키 묶음 전체와 필요한 서명 수로 정해지니, 내 시드 문구 하나만 적어 두어서는 다른 참여자의 공개키를 알 수 없어요. 디스크립터 문서는 이 예시 방식의 단점으로 참여자마다 서명용 지갑과 멀티시그 지갑 두 개를 관리하고 백업해야 한다는 점을 들었어요. 시드 문구 자체를 보관하는 방법은 시드 문구 백업·복구 정리에 따로 있어요.

주소 앞글자로 출력 방식을 가려 보는 법은 비트코인 블록 6개의 출력 형식 분류에 표로 정리해 두었어요.

정리

이 글이 다루지 않은 것

• 하드웨어 지갑이나 모바일 지갑 제품이 멀티시그를 몇 개 키까지 지원하는지는 제품 문서를 열지 않아서 쓰지 않았어요.
• MPC 방식 지갑과 이더리움 등 다른 체인의 멀티시그는 이 글에서 다루지 않았어요.
• 미니스크립트 thresh()로 짠 P2WSH 멀티시그의 키 개수는 연산 수를 셈한 계산만 적었고, 노드에서 지갑을 만들거나 거래를 보내 확인하지 않았어요.
• 멀티시그 거래의 수수료 비교, BIP-45·BIP-87 같은 멀티시그 파생 경로 규격 본문은 열지 않았어요.

모든 내용은 2026년 10월 5일 오후 8시 19분부터 20분 사이(한국 시각, miniscript.h는 8시 48분)에 받은 비트코인 코어 v31.1 소스·문서와 BIP 원문 기준이에요. 상수 값은 같은 시각 master와 v32.0rc3에서도 같았지만, 다음 판에서 문서나 정책이 바뀔 수 있어요.

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