비트코인 세그윗 SegWit은 무엇이고 왜 필요한가
📋 목차
세그윗은 비트코인 거래에서 서명 데이터를 따로 떼어 뒤쪽에 붙인 2017년 업그레이드예요. 이 변화로 거래 ID가 도중에 바뀌던 문제가 사라졌고, 같은 금액을 보내도 수수료를 30% 넘게 아낄 수 있게 됐습니다.
지갑을 새로 만들면 주소 종류를 고르라는 화면이 나오죠. 1로 시작하는 것, 3으로 시작하는 것, bc1q, 그리고 bc1p. 넷 다 비트코인 주소인데 왜 갈라져 있는지는 아무도 설명해주지 않아요.
거래소 커뮤니티나 지갑 앱 리뷰를 보면 "세그윗 주소 쓰면 수수료 싸다"는 말은 흔하게 돌아다닙니다. 그런데 뭐가 어떻게 싸지는지, 지금 내 지갑에 있는 코인을 옮겨야 하는 건지까지 답해주는 글은 생각보다 드물더라고요. 어떤 글은 "블록 크기가 4MB로 늘었다"고 하고, 어떤 글은 "1.8MB 정도"라고 합니다. 둘 다 맞는 말인데 조건이 다릅니다.
공개된 프로토콜 문서와 체인 데이터를 나란히 놓고 정리해보니, 세그윗은 결국 "서명을 거래 데이터의 어디에 둘 것인가"라는 단 하나의 결정에서 출발한 변화였어요. 그 결정 하나가 수수료, 주소 형식, 라이트닝 네트워크까지 전부 바꿔놨습니다.
 |
| 비트코인 레거시 거래와 세그윗 거래의 데이터 구조를 나란히 비교 |
세그윗을 한 문장으로 줄이면 서명 자리 옮기기
Segregated Witness. 우리말로 옮기면 "분리된 증인"입니다. 여기서 증인(witness)은 법정에 나오는 사람이 아니라, 이 코인을 쓸 권한이 나에게 있다는 걸 증명하는 디지털 서명을 뜻해요.
2017년 이전 방식, 그러니까 지금 레거시라고 부르는 구조에서는 이 서명이 각 입력(input) 바로 옆에 붙어 있었습니다. 거래 데이터 곳곳에 서명이 흩어져 있는 셈이죠. 그리고 그 거래의 고유 식별자인 거래 ID는 서명을 포함한 전체 데이터를 해시해서 만들었어요.
세그윗은 이 서명들을 전부 걷어서 거래 데이터 맨 뒤에 있는 별도 구역으로 몰아넣습니다. 그리고 거래 ID를 계산할 때 그 구역은 빼버려요. 남는 건 "누가 누구에게 얼마를 보냈는가"라는 결과뿐입니다. 서명은 검증에는 쓰이지만 신원증명에는 안 쓰이는 구조가 된 거예요.
활성화 시점은 정확합니다. 2017년 8월 24일, 블록 높이 481,824번부터 네트워크가 새 규칙을 적용하기 시작했어요. 채굴자 95%가 준비 신호를 보내는 조건이 충족된 뒤 약 2주 뒤였습니다.
여기서 짚고 갈 게 하나 있어요. 세그윗은 하드포크가 아니라 소프트포크였습니다. 업그레이드하지 않은 옛날 노드도 세그윗 블록을 유효하다고 보고 그대로 받아들였거든요. 옛 노드 입장에서는 서명 부분이 비어 보이는 조금 이상한 거래일 뿐, 규칙 위반은 아니었습니다. 체인이 둘로 갈라지지 않고 넘어갈 수 있었던 이유가 여기 있어요.
세그윗이 실제로 해결한 두 가지 문제
첫 번째는 거래 가변성(transaction malleability)입니다. 이름이 어려운데 내용은 단순해요.
비트코인이 쓰는 서명 방식에는 수학적으로 짝이 되는 값이 존재합니다. 서명 안의 특정 값을 뒤집어도 여전히 유효한 서명이 나와요. 거래의 내용은 하나도 안 바뀌는데, 서명이 바뀌었으니 전체 데이터를 해시한 거래 ID는 달라집니다. 즉 내가 방송한 거래를 중간의 아무 노드나 붙잡아서 ID만 바꿔 다시 퍼뜨릴 수 있었다는 뜻이에요.
사용자 입장에선 짜증나는 수준이지만, 거래소나 자동화 시스템 입장에선 사고로 이어집니다. 내가 보낸 거래 ID를 계속 추적하고 있는데 그 ID가 블록에 안 들어오니까, 시스템이 "전송 실패"로 판단하고 한 번 더 보내는 식이죠. 2014년 마운트곡스는 파산 당시 이 문제를 손실 원인 중 하나로 지목했는데, 이후 분석에서는 가변성만으로 전체 손실을 설명하기 어렵다는 반론이 많았습니다. 어느 쪽이든 프로토콜의 약점이었다는 사실 자체는 개발자들 사이에서 오래전부터 합의된 부분이었어요.
서명이 거래 ID 계산에서 빠지면 이 공격은 원천적으로 불가능해집니다. 세그윗 거래의 ID는 내가 만든 순간 확정되고, 블록에 들어갈 때까지 그대로 유지돼요.
두 번째는 블록 용량입니다. 2017년은 비트코인 수수료가 사상 처음으로 심각하게 치솟은 해였어요. 블록 하나에 담을 수 있는 데이터가 1,000,000바이트로 묶여 있었고, 거래 수요는 그걸 넘어섰거든요. 블록 크기를 그냥 2MB로 늘리자는 진영과, 구조를 바꿔서 공간을 확보하자는 진영이 갈렸고 결과적으로 후자가 소프트포크 형태로 먼저 자리를 잡았습니다.
4,000,000 웨이트 유닛이라는 새 계산 단위
세그윗 이후 블록 크기는 바이트로 재지 않습니다. 웨이트 유닛(WU)이라는 단위를 씁니다. 규칙은 딱 세 줄이에요.
블록 한 개의 상한은 4,000,000 WU. 일반 데이터 1바이트는 4 WU로 계산. 그리고 서명이 들어가는 witness 영역의 1바이트는 1 WU로만 계산합니다. 서명 데이터에 75% 할인을 준 거죠. 이걸 4로 나눈 값이 우리가 수수료 계산할 때 쓰는 가상 크기(vB, virtual byte)입니다.
왜 하필 할인이냐면, 서명 데이터는 검증이 끝나면 노드가 굳이 영원히 붙들고 있지 않아도 되는 성격이기 때문이에요. 잔액 계산에 필요한 정보는 서명이 아니라 입출력 내역입니다. 저장 부담이 상대적으로 가벼운 데이터에 낮은 값을 매긴 셈이죠.
📊 실제 데이터
일반적인 블록은 서명 데이터가 전체의 60% 안팎을 차지합니다. 이 비율로 계산하면 일반 데이터 40만 바이트 × 4 = 1,600,000 WU, 서명 데이터 60만 바이트 × 1 = 600,000 WU, 합계 2,200,000 WU가 나와요. 상한 4,000,000을 여기에 나누면 약 1.81배. 그래서 세그윗은 실질적으로 블록 상한을 1.8MB 부근까지 올린 효과로 이야기됩니다. 다만 블록에 담긴 거래 구성에 따라 이 값은 매번 달라집니다.
2023년 이후 오디널스 같은 데이터 삽입 방식이 등장하면서 witness 영역을 꽉 채운 블록이 나오기도 했어요. 그런 블록은 실제 용량이 3MB를 넘기도 합니다. 평상시 블록과는 성격이 다른 특수한 경우라고 보는 편이 맞아요.
내 주소가 세그윗인지 3초 만에 구분하는 법
주소 맨 앞 글자만 보면 됩니다. 아래 표에 정리해뒀어요. 크기 수치는 입력 1개, 출력 2개짜리 표준 송금 기준입니다.
| 주소 앞자리 | 유형 | 송금 크기 |
|---|---|---|
| 1… | 레거시(P2PKH) | 약 226 vB |
| 3… | 호환 세그윗(P2SH) | 약 172 vB |
| bc1q… | 네이티브 세그윗 | 약 141 vB |
| bc1p… | 탭루트(P2TR) | 약 142 vB |
3으로 시작하는 주소가 조금 헷갈립니다. 원래 3번대는 스크립트 해시 주소라서 다중서명 지갑에도 쓰이거든요. 세그윗이 나온 뒤에는 세그윗 구조를 옛날 형식 껍데기에 감싸 넣는 용도로도 쓰였고, 그래서 "호환 세그윗" 또는 "래핑 세그윗"이라고 불려요. bc1을 못 읽는 서비스가 많던 시절의 과도기 해법이었습니다.
bc1q부터가 진짜 세그윗, 이른바 네이티브 세그윗입니다. 껍데기 없이 세그윗 구조를 그대로 씁니다. bc1p는 2021년 11월 활성화된 탭루트 주소로, 세그윗 위에 슈노르 서명을 얹은 형태예요.
💡 꿀팁
지갑 설정에서 파생 경로를 보면 주소 유형이 바로 나옵니다. m/44'로 시작하면 1번대, m/49'는 3번대, m/84'는 bc1q, m/86'은 bc1p예요. 같은 시드 문구라도 이 경로가 다르면 완전히 다른 주소 묶음이 만들어집니다. 지갑을 옮길 때 잔액이 0으로 보이는 사고의 절반 이상이 여기서 나와요.
세그윗 수수료 절감, 직접 계산해보기
비트코인 수수료는 보내는 금액과 무관합니다. 오직 거래 데이터의 가상 크기(vB)와, 그때그때의 시장 단가(sat/vB)를 곱해서 나와요. 1억 원어치를 보내든 1만 원어치를 보내든 데이터 크기가 같으면 수수료도 같습니다.
계산해볼까요. 단가를 20 sat/vB로 잡으면, 레거시 226 vB × 20 = 4,520 사토시. 네이티브 세그윗은 141 vB × 20 = 2,820 사토시. 차이가 1,700 사토시, 비율로는 약 38%입니다. 단가가 5 sat/vB로 한산한 시간대라면 각각 1,130 사토시와 705 사토시로 줄고, 절감액도 425 사토시로 작아져요.
여기서 중요한 포인트. 절감 비율은 고정이지만 절감 금액은 그날 네트워크 혼잡도에 따라 몇십 배씩 출렁입니다. 2026년 8월 15일 기준으로도 mempool 상황에 따라 1 sat/vB 미만부터 수십 sat/vB까지 폭이 넓어요. 수수료 시세는 실시간으로 바뀌니 송금 직전에 확인하는 편이 안전합니다.
입력 개수가 많아지면 차이가 확 벌어집니다. 소액 입금이 여러 번 쌓인 지갑에서 한꺼번에 보낼 때, 입력마다 서명이 하나씩 붙거든요. 입력이 10개면 절감분도 대략 10배가 됩니다. 자잘한 UTXO를 정리하는 통합 거래에서 세그윗의 이득이 가장 크게 체감되는 이유예요.
반대로 자주 오해되는 부분도 있어요. 내가 지불하는 수수료를 결정하는 건 내가 쓰는 코인이 어떤 형식으로 잠겨 있느냐이지, 상대방 주소가 무슨 형식이냐가 아닙니다. 받는 주소 형식은 출력 크기에 몇 바이트 영향을 줄 뿐이에요. 레거시 주소에 코인을 쌓아둔 채로 상대에게 bc1q 주소를 받아 보내봐야 큰 절감은 없습니다.
세그윗에 관해 잘못 알려진 이야기들
"세그윗으로 블록이 4MB가 됐다"는 설명은 절반만 맞습니다. 상한선이 4,000,000 웨이트 유닛인 건 사실인데, 그게 4MB의 실제 데이터를 뜻하려면 블록 전체가 서명 데이터로만 채워져야 해요. 현실의 블록은 일반 데이터와 서명 데이터가 섞여 있어서 보통 1.8MB 안팎에 머뭅니다.
"비트코인 세그윗은 다른 코인"이라는 오해도 자주 보입니다. 거래소 출금 화면에 BTC와 BTC(SegWit)이 따로 뜨니 그렇게 읽히는 건데, 둘은 같은 체인의 같은 자산이에요. 주소를 만드는 방식이 다를 뿐 서로 자유롭게 주고받을 수 있습니다.
"bc1 주소는 아직 못 쓰는 데가 많다"도 이제는 옛날 이야기에 가깝습니다. 체인 데이터를 보면 2022년 이후 세그윗 입력을 포함한 거래 비중이 85~90% 선에서 유지되고 있어요. 다만 아주 오래된 결제 게이트웨이나 소규모 서비스 중에는 여전히 Bech32 주소를 인식하지 못하는 곳이 남아 있습니다.
⚠️ 주의
주소 형식보다 훨씬 위험한 건 네트워크 선택입니다. 비트코인 주소가 맞더라도 출금 화면에서 BSC나 다른 체인의 래핑 토큰 네트워크를 고르면 자산이 도달하지 않고, 이 경우 복구가 사실상 어려워요. 처음 쓰는 주소라면 금액을 최소 단위로 나눠 한 번 보내보고, 도착을 확인한 뒤 나머지를 옮기는 순서를 권합니다. 투자 판단이나 세금 처리처럼 개인 상황이 갈리는 부분은 전문가 상담을 권장합니다.
마지막으로 "세그윗 쓰면 수수료가 항상 싸다"는 말. 같은 시점 기준으로는 맞지만, 혼잡한 시간대의 세그윗 거래가 한산한 시간대의 레거시 거래보다 훨씬 비쌀 수 있어요. 형식보다 타이밍이 금액에 미치는 영향이 더 큽니다.
세그윗에서 탭루트와 라이트닝으로 이어진 길
세그윗의 진짜 파급력은 수수료가 아니라 그 위에 뭘 지을 수 있게 됐느냐에 있었습니다.
라이트닝 네트워크를 보면 이해가 빠릅니다. 라이트닝은 두 사람이 채널을 열어두고, 아직 방송하지 않은 거래에 미리 서명해서 주고받는 구조예요. 그런데 아직 확정되지 않은 거래의 ID가 중간에 바뀔 수 있다면, 그 ID를 참조하는 후속 거래는 통째로 무효가 됩니다. 거래 가변성이 남아 있는 한 안전한 채널을 만들 수 없었던 거죠. 세그윗이 그 전제를 깔아준 뒤에야 라이트닝 구현체들이 실제로 돌아가기 시작했습니다.
탭루트도 세그윗 위에 얹힌 확장입니다. 2021년 11월 활성화됐고, 슈노르 서명을 도입해서 다중서명 거래를 체인 위에서 단일 서명처럼 보이게 만들었어요. 3명 중 2명 서명 조건이든 혼자 쓰는 지갑이든 겉보기가 같아지니 프라이버시 측면의 이득이 큽니다. 다만 단일 서명 송금만 놓고 보면 bc1q와 크기가 거의 비슷해서, 일반 사용자가 체감할 절감폭은 크지 않아요.
그럼 지금 쓰던 지갑을 옮겨야 할까요. 판단 기준은 세 가지로 정리됩니다. 앞으로 이 잔액에서 송금을 몇 번이나 할 것인지, 옮기는 시점의 단가가 낮은지, 그리고 주고받는 상대 서비스들이 해당 형식을 지원하는지. 한두 번 쓰고 말 잔액이라면 옮기는 비용이 절감분을 잡아먹습니다. 반대로 자주 움직이는 지갑이면 한산한 시간대에 한 번 정리해두는 쪽이 누적으로 유리해요.
거래소를 주로 쓴다면 굳이 신경 쓸 일이 적습니다. 입금 주소는 거래소가 만들어주고, 출금 수수료는 거래소가 정한 고정값인 경우가 대부분이거든요. 개인 지갑을 직접 운용하는 사람일수록 주소 형식 선택의 실익이 커집니다.
 |
| 2017년 세그윗 활성화부터 2021년 탭루트, 라이트닝 네트워크 확산까지 이어지는 비트코인 업그레이드 연표 |
자주 묻는 질문
Q. 거래소에서 bc1q 주소로 출금 신청이 막히면 어떻게 하나요?
받는 쪽 지갑에서 3으로 시작하는 호환 세그윗 주소를 새로 발급받아 쓰는 방법이 있습니다. 대부분의 지갑은 계정 추가 메뉴에서 주소 유형을 바꿀 수 있어요. 주요 거래소는 bc1q 출금을 지원하지만, 오래된 결제 시스템이나 소규모 서비스에서는 여전히 막히는 경우가 있습니다.
Q. 레거시 주소의 코인을 세그윗 주소로 옮기는 게 이득인가요?
옮기는 것도 하나의 거래라서 그 순간 수수료가 한 번 나갑니다. 앞으로 그 잔액을 몇 번 쓸지와 옮길 때의 sat/vB 단가에 따라 손익이 갈려요. 단가가 낮은 시간대에 정리해두면 이후 송금마다 절감이 쌓이지만, 장기 보관만 할 잔액이라면 서두를 이유가 크지 않습니다.
Q. bc1q와 bc1p 중 어느 쪽을 기본으로 쓰는 게 나을까요?
호환성을 우선한다면 bc1q입니다. bc1p는 다중서명이나 복잡한 조건을 걸 때 강점이 크고, 단일 서명 송금 크기는 bc1q와 거의 같아요. 받는 쪽 서비스가 Bech32m 형식을 인식하는지 먼저 확인하는 게 순서입니다.
Q. 세그윗 주소로 보낸 코인이 사라질 수도 있나요?
지원되는 주소 형식끼리는 사라지지 않습니다. 네 가지 형식 모두 같은 비트코인 네트워크를 공유하니까요. 문제가 되는 상황은 주소를 잘못 입력했거나, 비트코인이 아닌 다른 체인의 네트워크를 선택했을 때이고 이 경우는 복구가 어렵습니다.
Q. 시드 문구로 지갑을 복구했는데 잔액이 0으로 나옵니다.
파생 경로가 달라 엉뚱한 주소 묶음을 보고 있을 가능성이 큽니다. 같은 시드라도 m/44', m/49', m/84', m/86'은 서로 다른 주소를 만들거든요. 지갑 설정에서 주소 유형이나 경로를 바꿔가며 조회하면 잔액이 나타나는 사례가 많습니다.
본 포스팅은 공개된 프로토콜 문서와 체인 데이터를 바탕으로 작성되었으며, 전문적인 의료·법률·재무 조언을 대체하지 않습니다. 정확한 정보는 해당 분야 전문가 또는 공식 기관에 확인하시기 바랍니다. 본 글의 내용은 정보 제공 목적이며, 개인 상황에 따라 결과가 다를 수 있습니다. 반드시 전문가와 상담 후 결정하시기 바랍니다. 수수료 단가와 거래소별 지원 형식은 수시로 바뀌므로 실제 송금 전 공식 페이지에서 다시 확인하는 편이 안전합니다. 본문 수치는 2026년 8월 15일 확인 기준입니다.
👉 함께 읽으면 좋은 글: 비트코인 블록체인 원리: 거래가 기록되고 검증되는 방식
👉 함께 읽으면 좋은 글: 비트코인 P2P 네트워크 구조: 중앙 서버 없이 거래되는 원리
👉 함께 읽으면 좋은 글: 비트코인 메인넷과 사이드체인 차이: 확장 방식 비교
👉 함께 읽으면 좋은 글: 비트코인 거래 속도와 확장성 문제는 왜 생길까
세그윗은 서명의 위치를 바꿔 거래 ID를 고정하고, 블록 공간을 실질적으로 1.8배가량 넓힌 업그레이드입니다. 오늘 당장 쓸 수 있는 결론은 하나예요. 지갑에서 bc1q 계정을 기본으로 쓰고, 자주 움직이는 잔액이라면 단가가 낮은 날 한 번 정리해두는 것.
거래소만 쓰는 분이라면 주소 형식보다 네트워크 선택을 확인하는 습관이 훨씬 값집니다. 개인 지갑을 직접 굴리는 분이라면 파생 경로부터 확인해보세요. 다중서명이나 여러 사람과의 공동 관리가 필요한 상황이면 bc1p 쪽을 살펴볼 만하고, 단순 보관과 송금만 한다면 bc1q로 충분합니다.
지금 쓰는 지갑 주소가 어떤 형식인지 한번 확인해보시고, 결과가 어땠는지 댓글로 남겨주세요. 주소 형식 때문에 겪었던 상황이 있다면 그 이야기도 다른 분들께 도움이 됩니다.
댓글
댓글 쓰기