Table of Contents

비트코인 주소 형식 1·3·bc1q·bc1p를 구분하는 방법

비트코인 메인넷에서 수신 주소는 1, 3, bc1q, bc1p처럼 서로 다른 문자로 시작할 수 있습니다. 이 접두어는 단순한 디자인 차이가 아니라 수신자가 만들고자 하는 거래 출력의 인코딩과 지출 조건에 관한 단서를 줍니다. 그렇다고 접두어만 보고 지갑의 소유자, 보안 수준, 거래소 신뢰성을 판단할 수 있는 것은 아닙니다.

주소는 비트코인 그 자체를 담는 계좌번호도 아닙니다. 송금 거래는 특정 조건을 만족하는 사람만 나중에 쓸 수 있도록 새 UTXO를 만들고, 주소는 그 출력 조건을 사람이 복사하기 쉬운 문자열로 표현한 것입니다. 주소를 잘못 입력하거나 상대 서비스가 해당 형식을 지원하지 않으면 되돌릴 중앙기관이 없습니다.

이 글은 2026년 8월 5일 확인한 Bitcoin Core 30.0 공식 RPC 문서와 Bitcoin Core 출력 디스크립터 문서, BIP 13·141·173·341·350을 기준으로 작성했습니다. 특정 코인이나 지갑을 추천하지 않으며, 비트코인 가격 변동·수수료·보관 실패로 원금 손실이 발생할 수 있습니다.

비트코인 주소 형식 1·3·bc1q·bc1p를 구분하는 방법 — 핵심 개념을 이해하기 위한 로드투코인 설명 이미지

주소·공개키·개인키·스크립트의 역할

개인키는 지출 권한을 증명하는 서명을 만들 때 쓰는 비밀값입니다. 공개키는 개인키에서 파생되며 서명을 검증하는 데 사용됩니다. 주소는 공개키 자체 또는 지출 스크립트를 정해진 방식으로 해시하고 인코딩한 문자열일 수 있습니다. 주소를 안다고 개인키를 계산할 수는 없습니다.

비트코인 거래 출력에는 scriptPubKey가 기록됩니다. 이 스크립트는 “어떤 조건을 충족해야 이 UTXO를 쓸 수 있는가”를 정의합니다. 지갑은 사용자가 입력한 주소를 해석해 적절한 scriptPubKey를 만듭니다. Bitcoin Core 30.0의 getaddressinfo는 주소에서 생성되는 scriptPubKey, witness 여부와 버전, 지갑이 알고 있는 디스크립터 같은 정보를 반환합니다.

요소	역할	공개 여부	분실·오류 시 영향
개인키	유효한 지출 서명 생성	반드시 비공개	백업도 없으면 자금 지출 불가
공개키	서명 검증의 기준	지출 과정에서 공개될 수 있음	개인키를 대신하지 못함
주소	출력 조건을 전달하는 인코딩 문자열	수신을 위해 공유	오입력 송금은 일반적으로 취소 불가
scriptPubKey	UTXO의 잠금 조건	블록체인에 공개	지출자는 대응 조건을 충족해야 함
디스크립터	지갑이 주소·스크립트를 파생하는 정책 표현	백업 정책에 따라 관리	키만 있고 정책 정보가 없으면 복구가 복잡해질 수 있음

따라서 “주소를 백업하면 코인이 백업된다”는 표현은 정확하지 않습니다. 자금을 복구하려면 개인키나 시드뿐 아니라 다중서명 임계값, 키 순서, 파생경로, 디스크립터 등 지출 정책 정보가 필요할 수 있습니다.

1로 시작하는 레거시 P2PKH

메인넷에서 1로 시작하는 주소는 일반적으로 P2PKH(Pay to Public Key Hash)를 Base58Check로 인코딩한 형식입니다. Bitcoin 개발자 문서에 따르면 P2PKH는 공개키를 SHA-256으로 해시한 뒤 RIPEMD-160으로 다시 해시한 값을 사용합니다. 메인넷 P2PKH 버전 바이트 0x00을 앞에 붙이고 이중 SHA-256 체크섬을 더해 Base58로 표현합니다.

P2PKH 출력은 지출할 때 유효한 서명과 공개키를 제시해야 합니다. 오랫동안 널리 사용되어 호환성이 높지만, SegWit 형식보다 동일한 경제적 지출 조건에서 거래 가중치가 커질 수 있습니다. 블록 공간 수요가 같다면 더 큰 가상 크기는 더 높은 총수수료로 이어질 수 있습니다.

접두어 1만 보고 그 주소가 안전하거나 위험하다고 판단하면 안 됩니다. 주소 생성기의 난수 품질, 개인키 보관, 피싱 여부는 주소 모양과 별개의 문제입니다.

3으로 시작하는 P2SH와 감싼 SegWit

메인넷에서 3으로 시작하는 주소는 일반적으로 P2SH(Pay to Script Hash)입니다. BIP 13은 스크립트 해시에 지급하는 주소 형식을 정의합니다. 송금자는 복잡한 전체 지출 조건을 알 필요 없이 스크립트 해시에 해당하는 출력으로 보낼 수 있고, 수신자는 나중에 실제 redeemScript와 충족 자료를 제시합니다.

3 주소는 다중서명일 수도 있고, native SegWit을 P2SH 안에 감싼 P2SH-P2WPKH 또는 P2SH-P2WSH일 수도 있습니다. 즉 접두어만으로 내부 정책이 단일서명인지 다중서명인지 확정할 수 없습니다. 초창기 SegWit을 직접 지원하지 않던 발신 서비스와 호환하기 위해 감싼 형식이 널리 쓰였지만, 추가 스크립트 자료 때문에 native SegWit보다 지출 크기가 커질 수 있습니다.

이 차이는 수신 시점보다 나중에 해당 UTXO를 지출할 때 수수료에 영향을 줍니다. 주소가 짧아 보인다고 실제 거래가 항상 작은 것도 아닙니다.

bc1q로 시작하는 native SegWit v0

메인넷의 bc1q 주소는 대체로 witness version 0의 native SegWit 출력입니다. 단일키 해시에 지급하는 P2WPKH 또는 스크립트 해시에 지급하는 P2WSH가 여기에 포함됩니다. BIP 141은 Segregated Witness의 합의 규칙과 거래 가중치 구조를 정의하고, BIP 173은 v0 witness 주소의 Bech32 인코딩을 정의합니다.

Bech32는 사람이 읽을 수 있는 접두부(HRP)와 데이터, 체크섬으로 구성됩니다. 메인넷의 HRP는 bc, 테스트넷은 tb이므로 네트워크 구분에 도움이 됩니다. 대소문자 혼용은 유효하지 않으며, 화면에 보인 일부 문자만 비교해서는 안 됩니다.

SegWit은 서명 관련 witness 데이터를 기본 거래 구조와 분리해 가중치 할인을 적용합니다. 이 때문에 동일한 단일서명 UTXO를 지출할 때 P2WPKH가 P2PKH보다 보통 더 작은 vsize를 가질 수 있습니다. 그러나 총수수료는 vsize × sat/vB이므로 주소 형식만으로 최종 수수료를 확정할 수 없습니다. 입력 개수, 출력 개수, 실제 스크립트 경로와 당시 수수료율이 함께 필요합니다.

bc1p로 시작하는 Taproot v1

메인넷에서 bc1p로 시작하는 주소는 일반적으로 witness version 1의 Taproot 출력입니다. BIP 341은 Taproot 출력을 32바이트 witness program을 가진 native SegWit v1 출력으로 정의합니다. v1 이상의 witness 주소는 BIP 350의 Bech32m 체크섬을 사용합니다. v0의 Bech32와 v1의 Bech32m을 바꾸어 쓰면 안 됩니다.

Taproot 출력은 키 경로 지출과 스크립트 경로 지출을 결합할 수 있습니다. 일반적인 협력 상황에서는 키 경로로 지출하고, 필요한 경우에만 스크립트 경로와 해당 조건을 공개하도록 구성할 수 있습니다. 그렇다고 bc1p 주소가 자동으로 다중서명이나 더 안전한 보관을 뜻하지 않습니다. 단일키 Taproot일 수도 있고, 지갑 구현과 백업이 부실하면 주소 형식과 무관하게 손실이 발생합니다.

일부 오래된 거래소·지갑은 Taproot 수신 주소로의 출금을 지원하지 않을 수 있습니다. 유효한 비트코인 주소라는 사실과 특정 서비스가 그 형식으로 출금할 수 있다는 사실은 다릅니다.

네 주소 형식 핵심 비교표

메인넷 시작 문자	대표 출력	인코딩	witness 버전	일반적 특징	확인할 호환성
`1`	P2PKH	Base58Check	해당 없음	레거시, 넓은 호환성	현대 지갑에서 수신·지출 가능한지
`3`	P2SH, 감싼 SegWit 등	Base58Check	내부 정책에 따라 다름	스크립트 해시, 접두어만으로 정책 불명	redeemScript·디스크립터 백업
`bc1q`	P2WPKH·P2WSH	Bech32	0	native SegWit v0	발신 서비스의 Bech32 지원
`bc1p`	P2TR	Bech32m	1	Taproot 키·스크립트 경로 가능	발신 서비스의 Taproot 지원

이 표는 일반적인 메인넷 형식을 요약합니다. 테스트넷·regtest는 다른 HRP와 버전 바이트를 사용합니다. 3으로 시작한다고 반드시 다중서명 또는 SegWit인 것은 아니며, bc1q 길이도 P2WPKH와 P2WSH에서 다를 수 있습니다.

수수료를 숫자로 비교하는 계산 예시

가상의 단일 입력·두 출력 거래가 있다고 가정합니다. 레거시 P2PKH 입력을 쓰는 거래의 가상 크기를 226 vB, native SegWit P2WPKH 입력을 쓰는 거래를 141 vB라고 단순 가정하겠습니다. 당시 선택한 수수료율이 20 sat/vB라면 예상 총수수료는 다음과 같습니다.

P2PKH 예상 수수료 = 226 vB × 20 sat/vB = 4,520 sat

P2WPKH 예상 수수료 = 141 vB × 20 sat/vB = 2,820 sat

차이는 1,700 sat입니다. 비트코인 가격을 임의로 1 BTC=1억 원으로 가정하면 1 sat=1원이라서 약 1,700원 차이입니다. 이 원화 환산은 구조를 보여주기 위한 가정이며 기준일의 실제 시장가격이 아닙니다.

항목	P2PKH 가정	P2WPKH 가정	차이
가상 크기	226 vB	141 vB	85 vB
수수료율	20 sat/vB	20 sat/vB	0
총수수료	4,520 sat	2,820 sat	1,700 sat
1 sat=1원 가정 환산	4,520원	2,820원	1,700원

실제 거래 크기는 입력 UTXO 수, 잔돈 출력, 서명 길이, P2WSH·Taproot 스크립트 경로 등에 따라 달라집니다. 수수료율도 멤풀 혼잡과 목표 확인 시간에 따라 변합니다. 따라서 표의 고정 vB를 모든 거래에 적용하거나 특정 주소 형식이 언제나 일정 비율 저렴하다고 단정하면 안 됩니다.

송금 전에 단계별로 확인하는 방법

첫째, 수신자가 제공한 주소를 신뢰할 수 있는 경로에서 다시 확인합니다. 메신저 클립보드 악성코드가 주소를 바꿀 수 있으므로 처음과 끝 몇 글자만 보지 말고 하드웨어 지갑 화면이나 별도 채널로 전체 주소를 검증합니다.

둘째, 네트워크를 확인합니다. 비트코인 메인넷 출금인지, 테스트넷인지, 다른 체인의 토큰 전송인지 구분합니다. 비슷한 이름의 네트워크를 선택하면 복구가 불가능하거나 복잡해질 수 있습니다.

셋째, 발신 서비스가 주소 형식을 지원하는지 확인합니다. 서비스의 공식 출금 안내에서 Bech32·Taproot 지원을 확인하고, 지원하지 않는다고 표시되면 억지로 진행하지 않습니다. 주소를 다른 형식으로 임의 변환해서도 안 됩니다.

넷째, 자체 노드를 운영한다면 Bitcoin Core 30.0의 getaddressinfo 또는 validateaddress로 주소의 유효성과 witness 버전을 확인할 수 있습니다. 유효한 주소라는 결과는 상대방 소유권을 증명하지 않습니다.

다섯째, 처음 보내는 주소나 큰 금액은 적은 테스트 금액으로 수신을 확인한 뒤 본 전송을 검토합니다. 테스트 송금도 수수료가 들고, 피싱 사이트에서 확인했다면 안전을 보장하지 않으므로 주소 검증을 먼저 해야 합니다.

주소 형식과 지표 조합별 해석

관찰	가능한 의미	단정하면 안 되는 내용	추가 확인
`1` 주소	P2PKH 레거시 출력	오래된 주소라서 개인키가 취약함	지갑 백업·키 생성 방식
`3` 주소	P2SH 출력	반드시 다중서명임	redeemScript·디스크립터
`bc1q` 주소	SegWit v0 출력	항상 최저 수수료임	입력 수·실제 vsize·feerate
`bc1p` 주소	Taproot v1 출력	자동으로 프라이버시·보안이 완벽함	키·스크립트 경로와 지갑 구현
주소 유효성 통과	체크섬과 형식이 맞음	수신자가 믿을 만하거나 주소를 통제함	별도 소유권 확인

주소 모양은 기술적 출력 유형을 알려줄 뿐 투자 가치나 상대방 신용을 평가하지 않습니다. 블록 탐색기에서 거래 이력이 보이지 않는 새 주소도 정상일 수 있고, 이력이 많다고 안전한 주소인 것도 아닙니다.

시장과 이용자가 다르게 반응하는 이유

새 주소 형식은 합의 규칙이 활성화되어도 모든 지갑과 거래소가 즉시 지원하지 않습니다. 서비스는 입출금 모듈, 수수료 계산, 콜드월렛, 회계·감시 시스템을 함께 시험해야 하므로 지원 시차가 생깁니다. 하드웨어 지갑 펌웨어와 복구 도구도 해당 스크립트 유형과 파생경로를 알아야 합니다.

수수료 절감 효과도 시장 혼잡에 따라 체감이 달라집니다. sat/vB가 낮을 때 80 vB 차이는 작지만 혼잡으로 수수료율이 높아지면 금액 차이가 커집니다. 반면 UTXO가 많이 쪼개져 있다면 주소 형식보다 입력 개수가 수수료를 더 크게 좌우할 수 있습니다.

Taproot 사용 증가를 곧바로 비트코인 가격 상승 신호로 해석하는 것도 근거가 부족합니다. 기술 채택은 지갑 지원, 특정 애플리케이션 활동, 수수료 환경과 관련될 수 있지만 미래 수요와 시장가격을 보장하지 않습니다.

흔한 오해와 데이터의 한계

주소에 비트코인이 들어 있다: 실제로는 UTXO가 스크립트 조건에 잠겨 있습니다.
3은 모두 다중서명이다: P2SH는 감싼 SegWit 등 여러 redeemScript를 담을 수 있습니다.
bc1이면 모두 같은 형식이다: bc1q v0는 Bech32, bc1p v1은 Bech32m을 사용합니다.
유효성 검사 통과는 상대방 인증이다: 체크섬 검사는 소유자 신원이나 거래 신뢰성을 확인하지 않습니다.
새 주소 형식은 개인키도 새 암호를 쓴다: 출력·서명 방식의 차이를 키 보관 안전성과 혼동하면 안 됩니다.
주소를 재사용해도 문제없다: 재사용은 거래 연결성을 높여 프라이버시를 약화시킬 수 있습니다.

블록 탐색기의 주소 유형 분류는 도구 구현에 따라 표현이 다를 수 있습니다. 주소 잔액은 해당 문자열과 연결해 찾은 UTXO의 합계일 뿐 지갑 전체 잔액이 아닙니다. HD 지갑은 많은 수신·잔돈 주소를 사용합니다. 또한 이 글의 vsize 예시는 단순화된 가정이며 실제 서명과 스크립트 데이터를 직렬화한 결과가 우선합니다.

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

비트코인 전송은 승인 후 취소가 어렵고 오입금 복구를 보장하는 중앙기관이 없습니다. 피싱 주소, 잘못된 네트워크, 호환되지 않는 출금 시스템, 개인키·시드 분실로 전액 손실이 발생할 수 있습니다. 거래 수수료는 전송액과 별도로 소모되며, 시장가격 하락으로 원금 손실도 발생할 수 있습니다. 주소 형식이 최신이라는 이유만으로 보관과 거래가 안전해지는 것은 아닙니다.