Table of Contents

비트코인 다중서명 m-of-n과 단일키 위험을 구분하는 방법

비트코인 지갑의 2-of-3 다중서명은 세 사람이 투표하면 두 사람이 찬성해야 송금된다는 단순한 조직 규칙만을 뜻하지 않습니다. 특정 UTXO를 지출하기 위해 등록된 n개의 공개키 가운데 최소 m개에 대응하는 유효한 서명이 필요하다는 지출 조건입니다. 키를 여러 곳에 나누면 단일키 분실과 탈취 위험을 줄일 수 있지만, 설계와 백업을 잘못하면 오히려 복구가 더 어려워집니다.

이 글은 2026년 8월 4일 확인한 Bitcoin 개발자 거래 문서, BIP 174의 부분서명 비트코인 거래 형식, Bitcoin Core 29.0 RPC 문서를 기준으로 m-of-n 구조와 확인 순서를 설명합니다. 특정 지갑·수탁 서비스·가상자산의 이용을 권하지 않습니다. 다중서명은 가격 변동을 막지 않으며 비트코인 보유에는 원금 손실 가능성이 있습니다.

비트코인 다중서명 m-of-n과 단일키 위험을 구분하는 방법 — 핵심 개념을 이해하기 위한 로드투코인 설명 이미지

정확한 정의: m은 필요 서명 수, n은 등록 공개키 수다

다중서명 스크립트에서 m은 지출에 필요한 최소 유효 서명 수이고 n은 조건에 포함된 공개키 수입니다. 2-of-3은 세 공개키 중 두 개에 대응하는 개인키가 서명해야 지출할 수 있다는 뜻입니다. 한 키가 사라져도 남은 두 키로 지출할 수 있지만, 공격자가 두 키를 확보하면 소유자의 의도와 무관하게 지출 조건을 만족할 수 있습니다.

Bitcoin 개발자 문서는 표준 다중서명 공개키 스크립트를 m-of-n으로 설명하며, m개의 서명이 n개 공개키 가운데 대응되어야 한다고 명시합니다. P2SH 다중서명의 2-of-3 예시도 제공합니다. 공식 구조는 [Bitcoin 개발자 문서의 Transactions](https://developer.bitcoin.org/devguide/transactions.html)에서 확인할 수 있습니다.

구조	지출에 필요한 키	한 키 분실 시	공격자가 필요한 키	대표적 해석
1-of-1	1개 중 1개	지출 불능 가능	1개	단순하지만 단일 실패 지점 존재
1-of-2	2개 중 1개	다른 키로 복구 가능	1개	가용성은 높지만 탈취 임계값도 낮음
2-of-2	2개 중 2개	지출 불능 가능	2개	공동 승인 강제, 복구 여유 없음
2-of-3	3개 중 2개	남은 2개로 복구 가능	2개	승인 통제와 복구 여유의 절충
3-of-5	5개 중 3개	최대 2개 손실 허용	3개	조직형 통제에 유리하나 운영 복잡성 증가

n이 크면 무조건 안전하다는 결론은 틀립니다. 보관 장소가 사실상 같은 위험에 노출되거나 모든 복구 정보가 한 클라우드 계정에 있으면 논리적으로 키가 여러 개여도 실제 실패 지점은 하나일 수 있습니다.

단일서명과 다중서명의 핵심 차이

단일서명 지갑은 하나의 승인 경로를 이해하고 백업하기 쉬운 대신, 그 키 또는 복구 정보가 유출·분실되면 피해가 집중됩니다. 다중서명은 승인 권한을 여러 키로 분산해 한 장치의 고장이나 한 사람의 실수를 견딜 수 있게 설계할 수 있습니다. 반면 키 외에도 지출 조건, 공개키 순서, 파생 경로, 네트워크 같은 구성 정보가 복구에 중요해집니다.

다중서명은 여러 개인키를 합쳐 하나의 개인키로 만드는 것과도 다릅니다. 일반적인 스크립트 다중서명에서는 각 참여자가 자신의 키로 별도 서명을 만들고, 조건이 요구하는 수만큼 서명이 모여 거래가 완성됩니다. 여러 장치가 있으니 자산 가격도 분산된다는 뜻도 아닙니다. 보관 위험을 나누는 기술적 통제일 뿐 자산의 시장 위험은 그대로입니다.

비교 항목	단일서명	2-of-3 다중서명
승인	키 1개	서로 다른 키 2개
허용 가능한 키 손실	원칙적으로 0개	1개
탈취 임계값	키 1개	키 2개
구성 백업	키·파생 정보	각 키 + 지출 조건 + 공개키·파생 정보
거래 준비	단일 지갑에서 끝날 수 있음	부분서명 전달·결합 과정이 필요할 수 있음
수수료 영향	주소 유형과 거래 크기에 좌우	서명·스크립트 경로가 커지면 vsize 증가 가능

임계값을 숫자로 판단하는 방법

다중서명 설계에는 최소 두 가지 임계값이 있습니다. 가용성 임계값은 정상적인 사용자가 m개의 서명 수단을 확보할 수 있는가이고, 탈취 임계값은 공격자가 m개의 키를 동시에 장악할 수 있는가입니다. n-m개까지 키가 없어져도 이론상 지출할 수 있지만, 남은 키의 장치·소프트웨어·구성 정보가 모두 정상이라는 가정이 붙습니다.

2-of-3 구조에서 키 A는 집, 키 B는 사무실, 키 C는 원격 보관소에 둔다고 가정해 봅시다. 집 화재로 A가 사라져도 B와 C로 복구할 수 있습니다. 그러나 A와 B의 복구 문구를 같은 비밀번호 관리자 계정에 저장했다면 계정 침해 하나로 두 키가 노출될 수 있습니다. 장소 수가 아니라 독립적인 위험 요인의 수를 세어야 합니다.

사건 시나리오	사용 가능한 키	2-of-3 지출 가능 여부	핵심 위험
A 장치 고장	B, C	가능	즉시 새 구성으로 이전할 계획 필요
A 분실, C 백업 정보 불완전	B만 확실	불가능 가능	구성 백업 실패
공격자가 A만 탈취	B, C는 안전	공격자 단독 지출 불가	잔여 키로 안전한 이전 필요
공격자가 A와 B 탈취	C만 안전	공격자 지출 가능	공동 실패 원인 분석 필요
세 키는 정상, 정책 파일 분실	A, B, C	도구에 따라 복구 곤란	공개 구성 정보도 백업 대상

단계별 확인법: 주소 생성 전부터 복구까지 시험한다

첫째, 목적을 적습니다. 개인의 단일 장치 고장 대비인지, 법인의 이중 승인인지, 장기 상속 설계인지에 따라 적절한 m과 n이 다릅니다. 둘째, 각 키를 누가 통제하고 어떤 장소·장치·계정에 의존하는지 도식화합니다. 같은 제조사 장치, 같은 운영체제, 같은 클라우드는 공통 실패 원인이 될 수 있습니다.

셋째, 주소 유형과 지출 정책을 기록합니다. Bitcoin Core의 createmultisig는 필요한 서명 수와 공개키 목록으로 다중서명 주소, redeemScript와 디스크립터를 만들 수 있지만 개인키를 지갑에 추가하지는 않습니다. 사용하는 버전과 주소 유형을 공식 [Bitcoin Core 29.0 createmultisig](https://bitcoincore.org/en/doc/29.0.0/rpc/util/createmultisig/) 문서에서 확인해야 합니다.

넷째, 메인넷 자금을 보내기 전에 작은 금액과 별도 시험 환경으로 생성·서명·결합·방송·복구 전 과정을 검증합니다. 다섯째, 한 키를 사용할 수 없다는 가정으로 복구 훈련을 합니다. 여섯째, 구성원이 바뀌거나 키 노출이 의심되면 기존 UTXO가 자동으로 새 정책을 따르지 않는다는 점을 기억하고 새 지출 조건으로 실제 이전해야 합니다.

PSBT가 다중서명 협업에 필요한 이유

다중서명 참여자들이 같은 장치에 개인키를 모으면 분산 보관의 장점이 사라집니다. 부분서명 비트코인 거래, 즉 PSBT는 완전히 서명되지 않은 거래와 서명에 필요한 메타데이터를 참여자·하드웨어 지갑 사이에서 전달하기 위한 형식입니다. 각 서명자는 거래의 입력·출력과 수수료를 확인한 뒤 자신의 키로 부분서명할 수 있고, 충분한 서명이 모이면 최종 거래로 완성합니다.

[BIP 174](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki)는 하드웨어 지갑, 다중서명, CoinJoin 같은 여러 주체의 협업을 위한 PSBT 형식을 정의하고 2-of-3 다중서명 흐름 예시를 포함합니다. PSBT 자체가 거래를 안전하게 만들어 주는 것은 아닙니다. 악성 조정자가 수취 주소나 수수료를 바꿔 제안할 수 있으므로 각 서명 장치에서 최종 출력과 금액을 독립적으로 확인해야 합니다.

PSBT 단계	수행 내용	반드시 확인할 것
생성	입력 UTXO, 출력, 수수료를 구성	잔돈 주소와 총수수료
업데이트	서명에 필요한 메타데이터 추가	이전 출력·스크립트 정보
부분서명	각 참여자가 자신의 키로 서명	수취 주소, 금액, 네트워크
결합	여러 PSBT의 서명 정보를 합침	같은 원거래에 대한 서명인지
최종화	지출 조건을 충족하는 거래 구성	필요한 m개 서명 충족 여부
방송	완성 거래를 네트워크에 제출	TXID와 실제 수수료율

숫자를 넣은 현실적 시나리오

세 명의 담당자가 2-of-3 정책으로 0.8 BTC를 보관한다고 가정합니다. A와 B가 정기 지급을 승인하고 C는 비상 복구용입니다. 지급 거래가 0.10 BTC, 잔돈이 0.69996 BTC, 총수수료가 0.00004 BTC라면 입력 합계 0.8 BTC와 출력 합계 0.79996 BTC의 차이가 수수료입니다. 두 개의 유효 서명이 모여도 출력과 수수료를 확인하지 않으면 잘못된 거래를 공동 승인할 수 있습니다.

키 A가 분실된 경우 B와 C로 기존 UTXO를 쓸 수 있지만, 계속 같은 2-of-3 정책을 유지하면 공격자가 나중에 A를 발견할 위험이 남습니다. 안전한 새 키 D를 만들고 B·C·D로 새 정책을 구성한 뒤, B와 C의 승인으로 잔액을 새 주소로 이전하는 절차가 필요합니다. 이때 새 거래의 수수료와 주소를 양쪽 장치에서 확인해야 합니다.

한편 2-of-2 정책이었다면 A 분실 시 B만으로 이전할 수 없습니다. 1-of-3 정책이었다면 복구는 쉽지만 A 하나를 얻은 공격자도 지출할 수 있습니다. 임계값은 편의성과 보안을 동시에 바꾸므로 보유 금액만으로 결정할 수 없습니다.

수수료와 개인정보 측면의 차이

다중서명 거래는 사용하는 스크립트와 지출 경로에 따라 단일서명 거래보다 데이터가 커질 수 있습니다. 서명과 공개키 또는 스크립트 정보가 더 많이 포함되면 가상 크기가 증가하고, 같은 sat/vB에서 총수수료가 커질 수 있습니다. 정확한 크기는 P2SH, SegWit, Taproot 등 주소·스크립트 방식과 입력 수에 따라 달라지므로 모든 다중서명에 고정 수수료를 적용하면 안 됩니다.

일부 지출 방식은 온체인에서 다중서명 정책의 형태가 드러날 수 있습니다. 지출 정책과 키 재사용은 거래 연결 분석에 영향을 줄 수 있으므로 운영자는 주소 재사용을 피하고 지갑의 정책·프라이버시 문서를 확인해야 합니다. 다만 프라이버시 기능을 범죄 수익 은닉이나 규제 회피 수단으로 사용해서는 안 되며 적용 법령과 사업자 의무를 따라야 합니다.

지표 조합별 해석과 운영 설계

높은 m과 낮은 n-m은 승인 통제가 강하지만 키 하나의 장애가 가용성을 크게 떨어뜨릴 수 있습니다. 낮은 m은 복구가 쉽지만 공격자의 목표 키 수도 줄입니다. 키를 여러 지역에 두되 모든 담당자가 같은 회사 이메일로 복구한다면 물리적 위험은 분산돼도 계정 위험은 집중됩니다. 반대로 서로 다른 장치와 장소를 사용해도 구성 정보를 아무도 복구하지 못하면 정상 키가 남아 있어도 지출이 막힐 수 있습니다.

조직에서는 기술적 m-of-n과 내부 결재 규정을 구분해야 합니다. 기술적으로 두 서명만 있으면 지출 가능한데 규정상 세 명의 승인을 요구한다면, 두 명의 공모를 프로토콜이 막아 주지는 않습니다. 반대로 기술적 3-of-5인데 휴가·퇴사로 세 키를 모으기 어렵다면 결재가 끝나도 지급이 지연됩니다. 권한 변경, 퇴사, 사망, 장기 장애를 포함한 키 교체 절차가 필요합니다.

시장이 다르게 반응하는 이유

대형 보유자의 다중서명 도입은 보관 통제 개선으로 해석될 수 있지만 그 자체가 비트코인 수요 증가나 가격 상승을 뜻하지 않습니다. 거래소 준비금 주소가 다중서명이라는 사실도 지급능력과 부채 규모를 증명하지 않습니다. 공개된 온체인 자산, 고객에 대한 부채, 키 통제 주체, 출금 정책을 함께 봐야 합니다.

반대로 다중서명 키 사고 소식이 나와도 자금이 즉시 탈취됐다고 단정할 수 없습니다. 필요한 임계값 중 몇 개가 노출됐는지, 안전한 잔여 키로 새 정책에 이전했는지에 따라 결과가 다릅니다. 시장은 기술적 사실뿐 아니라 유동성, 규제, 신뢰, 공시의 투명성에 반응하므로 보관 방식 하나를 가격 지표로 사용하면 안 됩니다.

흔한 오해와 데이터의 한계

첫째, 2-of-3이면 세 키 중 아무 두 개의 복구 문구만 있으면 항상 복구된다는 오해입니다. 파생 경로, 공개키 순서, 디스크립터나 redeemScript 같은 구성 정보와 호환 소프트웨어가 필요할 수 있습니다. 둘째, 키 하나를 잃어도 지출 가능하니 방치해도 된다는 오해입니다. 안전 여유가 사라졌고 분실 키가 공격자에게 넘어갈 가능성도 있으므로 새 정책으로 이전을 검토해야 합니다.

셋째, 다중서명이 해킹을 완전히 막는다는 오해입니다. 서명 장치가 같은 악성 거래를 승인하거나 두 키가 공통 백업에서 노출되면 임계값이 무너집니다. 넷째, 서비스 명칭의 다중 승인이 반드시 온체인 다중서명이라는 오해입니다. 수탁 서비스의 내부 데이터베이스 승인일 수 있으므로 기술 구조와 법적 책임을 확인해야 합니다.

공식 개발 문서는 프로토콜과 특정 소프트웨어 동작을 설명하지만 사용자의 상속·세무·법인 결재 요건을 대신하지 않습니다. Bitcoin Core 29.0 문서의 일부 레거시 지갑 명령은 최신 디스크립터 지갑과 사용 범위가 다를 수 있습니다. 실제 구성은 사용하는 지갑 버전과 제조사의 복구 절차를 교차 확인해야 합니다.

원금 손실 위험과 실전 체크리스트

다중서명을 정확히 구성해도 비트코인 가격 하락, 규제 변화, 거래소 파산, 네트워크 수수료 급등 같은 시장·사업자 위험은 없어지지 않습니다. 개인키 또는 구성 정보 손실로 영구 접근 불능이 될 수 있으며, 잘못된 주소로 공동 서명한 거래도 중앙 관리자가 임의로 되돌려 주지 않습니다. 비트코인 투자에는 원금 손실 가능성이 있고 전액 손실도 가능합니다.