📏 비트코인 송금 수수료 — 보내는 금액이 아니라 거래 크기로 정해지는 자리

결론부터 말하면, 비트코인 송금 수수료는 보내는 금액을 따라가지 않아요. 수수료가 붙는 대상은 금액이 아니라 그 거래가 블록에서 차지하는 데이터 크기예요. 단위는 vB(가상 바이트)이고, 지갑 화면에 뜨는 sat/vB는 1 vB당 몇 사토시를 낼지 정하는 단가예요.

실측에서 바로 확인돼요. 2026년 8월 14일 오후 1시 14분에 확정된 블록 962371 안에서, 20,282.525 BTC를 옮긴 거래는 2,770 사토시를 냈고 0.0155 BTC를 옮긴 거래는 11,340 사토시를 냈어요. 금액 차이는 백만 배가 넘는데 수수료는 뒤쪽이 네 배 넘게 컸어요. 두 건의 전체 실측값은 아래 표에 그대로 옮겨 두었어요.

이 글의 숫자는 전부 조회 시각이 박혀 있어요. 2026년 8월 14일 오후 1시 25분(KST)에 다시 호출한 값으로 썼고, 규격에 관한 주장은 3자 도구 설명이 아니라 BIP-141 원문에서 받아 왔어요. 오늘의 숫자보다 남기고 싶은 것은 내 거래가 몇 vB인지 확인하고 거기에 단가를 곱해 보는 절차예요.

수수료는 보내는 금액이 아니라 거래 데이터 크기(vB)에 붙어요

은행 송금에 익숙하면 금액이 커질수록 비용도 커진다고 생각하기 쉬워요. 비트코인은 그 구조가 아니에요. 블록에 들어갈 수 있는 자리가 데이터 크기로 제한돼 있고, 채굴자는 그 제한된 자리를 두고 경쟁하는 거래들 사이에서 1 vB당 얼마를 내는지를 봐요. 금액 칸에 적힌 숫자는 자리를 더 차지하지 않아요.

블록 962371에서 뽑은 두 건을 나란히 놓으면 구조가 바로 보여요.

블록 962371(2026-08-14 13:14:26 KST 확정)의 거래를 mempool.space 공개 API에서 개별 조회한 값. 조회 시각 2026-08-14 13:24 KST.

두 거래의 가상 크기는 276 vB와 189 vB로 비슷한 급이에요. 갈린 것은 단가예요. 앞쪽은 10.04 sat/vB를 골랐고 뒤쪽은 60.00 sat/vB를 골랐어요. 금액은 이 계산에 한 번도 등장하지 않아요.

그래서 "비트코인 송금 수수료가 얼마인가"라는 질문은 그대로는 답이 안 나와요. 답이 나오는 형태로 바꾸면 이래요. 내 거래는 몇 vB이고, 나는 1 vB당 몇 사토시를 낼 셈인가. 두 값을 곱하면 그게 수수료예요.

언제 어느 창구에서 재 봤는지 — 측정 시각과 권장 수수료율

숫자를 옮기기 전에 어디서 어떻게 받았는지부터 밝혀 둘게요. 아래 세 응답은 모두 mempool.space 공개 API를 파이썬 표준 라이브러리로 직접 호출해 받은 것이고, 응답 바이트 수까지 같이 적어 두었어요.

조회 시각 이후의 값은 이 글이 보증하지 않아요. 수수료율은 분 단위로 바뀌어요.

권장 수수료율 응답은 다섯 등급으로 와요. 이번 호출에서는 다섯 등급이 전부 같은 값이었어요.

mempool.space /api/v1/fees/recommended 응답 원문(74 bytes), 2026-08-14 13:25:16 KST.

급행과 여유가 갈리지 않는다는 것은 자리를 두고 벌이는 경쟁이 느슨한 국면이라는 뜻이에요. 다만 이 상태는 오늘 이 시각의 관측일 뿐이고, 몇 시간 뒤에 다시 재면 다른 그림이 나올 수 있어요. 그래서 이 글은 값을 외우게 하려는 글이 아니라 재는 자리를 알려 주려는 글이에요.

vB가 무엇인지는 BIP-141 원문이 정의해 두었어요

sat/vB의 분모인 vB는 3자 도구가 만든 편의 단위가 아니에요. 세그윗을 도입한 규격 문서 BIP-141에 정의가 그대로 적혀 있어요. 원문을 옮기면 이래요.

Transaction weight is defined as Base transaction size * 3 + Total transaction size (ie. the same method as calculating Block weight from Base size and Total size).

Virtual transaction size is defined as Transaction weight / 4 (rounded up to the next integer).

한국어로 옮기면 거래 무게 = 기본 크기 × 3 + 전체 크기이고, 가상 크기 = 거래 무게 ÷ 4(다음 정수로 올림)이에요. 여기서 자주 빠뜨리는 대목이 괄호 안의 올림 처리예요. 나누어떨어지지 않으면 위쪽 정수로 올라가요.

같은 문서가 기본 크기와 전체 크기도 정의했어요.

Base transaction size is the size of the transaction serialised with the witness data stripped.

Total transaction size is the transaction size in bytes serialized as described in BIP144, including base data and witness data.

즉 기본 크기는 서명 부분을 걷어 낸 크기이고, 전체 크기는 서명까지 포함한 크기예요. 서명 데이터가 무게에 한 번만 들어가고 기본 데이터가 네 번 들어가는 구조라, 같은 바이트라도 서명 쪽이 가볍게 계산돼요.

말로만 보면 추상적이니 위에서 본 거래로 계산을 재현해 볼게요. 35abdf283ecf 건의 응답값은 전체 크기 379바이트, 무게 754였어요. 정의를 뒤집으면 기본 크기는 (754 − 379) ÷ 3 = 125바이트예요. 다시 정의대로 넣으면 125 × 3 + 379 = 754가 나오고, 754 ÷ 4 = 188.5를 올림하면 189 vB예요. API가 준 값과 정확히 맞아요. 수수료 11,340 사토시를 189로 나누면 60.00 sat/vB이고, 이것도 응답과 일치해요.

블록 쪽 규격도 같은 문서에 있어요. 원문은 "The new rule is block weight ≤ 4,000,000"이에요. 무게 상한이 4,000,000이므로 4로 나눈 1,000,000 vB가 블록 한 개의 자리예요. 실제로 블록 962371의 무게는 3,997,952였고 vB로 환산하면 999,488이라 상한의 99.9퍼센트를 채웠어요.

거래를 무겁게 만드는 것은 금액이 아니라 입력 개수예요

그러면 무엇이 vB를 키울까요. 실측으로 보면 답이 분명해요. 입력의 개수예요.

블록 962371의 거래 목록에서 앞에서부터 250건을 받아 코인베이스 거래를 뺀 249건을 세어 봤어요. 가상 크기의 중앙값은 141 vB였고, 가장 작은 거래는 66 vB, 가장 큰 거래는 6,164 vB였어요. 두 끝 사이가 93배 넘게 벌어져요.

가장 컸던 01b5a4765bbb 건을 열어 보면 이유가 바로 나와요.

블록 962371 소속 거래를 mempool.space 공개 API에서 개별 조회, 2026-08-14 13:24 KST.

1 BTC 남짓을 옮기는데 6,164 vB를 썼어요. 앞에서 본 20,282 BTC짜리 거래가 276 vB였던 것과 비교하면 22배가 넘어요. 갈린 지점은 입력 67개예요. 지갑에 잔돈처럼 흩어져 들어온 조각을 여러 개 긁어모아 보내면 조각마다 서명이 붙고, 그만큼 데이터가 늘어요.

여기서 실생활로 넘어오는 함의가 하나 나와요. 소액 입금을 여러 번 받아 쌓아 둔 지갑은 나중에 한 번에 보낼 때 거래가 무거워져요. 같은 금액이라도 어떻게 받아 두었는지에 따라 낼 돈이 달라지는 셈이에요. 반대로 큰 덩어리 하나로 받아 둔 지갑은 큰 금액을 보내도 거래가 가벼워요.

지갑 종류도 영향을 줘요. 서명이 어느 자리에 실리느냐가 주소 형식에 따라 다르기 때문이에요. 주소가 어떤 형식으로 갈리고 형식마다 무엇이 달라지는지는 지갑 주소 형식별 오타 감지 방식 정리에 따로 적어 두었어요. 그 글은 오타를 걸러내는 힘을 다뤘고, 이 글은 같은 형식 차이가 크기에 미치는 영향을 다뤄요.

대기 물량이 4천만 vB인데 권장 수수료율이 1 sat/vB인 이유

여기가 이 글에서 가장 오해가 잦은 대목이에요. 조회 시각에 대기 중인 거래가 76,584건, 물량으로는 39,857,145 vB였어요. 블록 하나가 1,000,000 vB를 담으니 단순히 나누면 약 40블록 분량이에요. 10분에 한 블록이 나온다고 보면 여섯 시간이 넘는 양이에요. 그런데 권장 수수료율은 최저치인 1 sat/vB예요. 모순처럼 보이지만 아니에요.

같은 응답에 실린 수수료율 분포를 보면 풀려요. 대기 물량을 수수료율 구간별로 쪼갠 값에서, 1 sat/vB 이상 구간에 들어 있는 물량은 52,197 vB뿐이었어요. 전체 39,857,145 vB의 0.13퍼센트예요. 나머지 99.87퍼센트는 그보다 낮은 단가를 매단 채 줄에 서 있어요. 다만 이 응답은 대기 물량을 구간 단위로 묶어 주기 때문에, 멤풀에서 가장 높은 단가가 얼마였는지는 이 응답만으로 알 수 없어요.

mempool.space /api/mempool 응답의 수수료율 분포를 구간별로 합산, 2026-08-14 13:25:16 KST.

그래서 대기 건수만 보면 판단을 그르쳐요. 줄이 길어도 그 물량이 낮은 단가 구간에 몰려 있으면 다음 블록에 들어가요. 봐야 할 것은 건수가 아니라 두 가지예요. 첫째는 vB 총량이고, 둘째는 그 물량이 어느 단가 구간에 몰려 있는지예요.

블록이 실제로 받아 간 수수료도 같은 방향을 가리켜요. 블록 962371의 총수수료는 806,522 사토시였고, 채굴 보상 전체는 313,306,522 사토시였어요. 둘을 나누면 수수료 비중은 0.26퍼센트이고, 나머지 312,500,000 사토시(3.125 BTC)는 블록 보조금이에요.

같은 블록 안에서도 수수료율이 벌어져요

같은 블록에 실렸다고 해서 같은 단가를 낸 것은 아니에요. 블록 962371의 응답에는 수수료율 분포가 함께 실려 있는데, 가장 낮은 값이 0.40 sat/vB, 중앙값이 0.52 sat/vB, 가장 높은 값이 60.16 sat/vB였어요. 한 블록 안에서 150배 가까이 벌어진 셈이에요.

최근 세 블록을 나란히 놓으면 이래요.

mempool.space /api/v1/blocks 응답, 조회 시각 2026-08-14 13:25:17 KST. 수수료율은 소수 셋째 자리에서 반올림.

왜 한 블록 안에서 단가가 벌어질까요. 단가를 정하는 주체가 보내는 쪽이기 때문이에요. 지갑이 자동으로 넉넉하게 잡아 주기도 하고, 사용자가 직접 올려 잡기도 해요. 60 sat/vB를 낸 거래는 중앙값의 약 115배를 낸 셈인데, 그 블록이 0.40 sat/vB짜리까지 실어 줬으므로 0.52 sat/vB만 냈어도 같은 블록에 들어갔을 가능성이 커요. 다만 그 판단은 보낸 시점에는 알 수 없어요. 다음 블록이 언제 나올지, 그사이 어떤 거래가 밀려들지는 미리 확정되지 않으니까요.

직접 센 249건 표본에서는 더 낮은 값도 나왔어요. 71e12f925496 건은 153 vB에 수수료가 16 사토시뿐이라 0.10 sat/vB였어요. API가 블록 지표로 준 최저값 0.40 sat/vB보다 낮아요. 어긋나 보이지만 같은 창구의 /api/v1/cpfp/ 응답을 열면 정리돼요. 이 거래에는 같은 블록에 함께 실린 자식 거래 9b4fb31dad92가 딸려 있고, 자식은 66 vB에 474 사토시를 냈어요. 부모와 자식을 한 묶음으로 보면 수수료는 490 사토시, 무게는 610 + 264 = 874라 4로 나누면 218.5 vB예요. 490을 218.5로 나누면 2.24 sat/vB이고, 응답이 effectiveFeePerVsize 값으로 준 2.242562929061785와 같아요. 블록 지표의 최저값 0.40 sat/vB보다 오히려 위예요.

그러니까 이 거래는 낮은 단가로도 실린 사례가 아니에요. 뒤에 붙은 거래가 수수료를 얹어 묶음 단가를 끌어올린 사례예요. 표본 249건 중 블록 최저값 아래에 있던 거래는 이 건과 c6074dfa4dd8 두 건뿐이었는데, 두 건 다 같은 구조였어요. c6074dfa4dd8의 묶음 실효 단가도 2.25 sat/vB로 최저값 위에 있었어요. 두 숫자는 애초에 모순이 아니었던 셈이에요.

거래소가 고정으로 떼는 출금 수수료와는 다른 층이에요

여기까지가 온체인 층이에요. 국내 거래소에서 코인을 밖으로 보낼 때 화면에 뜨는 숫자는 다른 층이라 섞으면 안 돼요. 거래소는 대체로 종목별로 고정 수량을 떼요. 조회 시각에 두 곳의 공개 API를 열어 확인했어요.

각 거래소 공개 API 직접 호출, 2026-08-14 13:25 KST. 두 곳만 확인한 값이며 국내 전체를 뜻하지 않아요.

0.0008 BTC는 80,000 사토시예요. 같은 시각 업비트 원화 마켓의 BTC 체결가가 89,400,000원이었으니 원화로 약 71,520원이에요.

온체인 쪽과 자릿수를 맞춰 보면 차이가 드러나요. 앞에서 잰 표본의 중앙값 141 vB에 조회 시각 권장 단가 1 sat/vB를 곱하면 141 사토시, 원화로 약 126원이에요. 80,000 사토시와 141 사토시는 약 567배 차이예요.

원화 환산은 업비트 KRW-BTC 체결가 89,400,000원(2026-08-14 13:25:39 KST) 기준.

이 차이를 두고 거래소가 부당하게 뗀다고 읽는 것은 성급해요. 거래소가 고정 수량을 정하는 근거와 그 수량을 어떻게 쓰는지는 공개 응답에 들어 있지 않고, 이번에 확인하지 못했어요. 여기서 말할 수 있는 것은 두 숫자가 서로 다른 층에서 나오고 자릿수가 다르다는 사실까지예요. 거래 수수료와 출금 수수료를 포함해 코인을 쓸 때 새어 나가는 비용이 어떤 갈래로 나뉘는지는 코인 수수료 총정리에 정리해 두었어요. 그 글은 비용의 갈래를 넓게 훑고, 이 글은 그중 온체인 한 갈래만 규격까지 파고들어요.

네트워크를 어느 것으로 고르느냐에 따라 화면에 뜨는 고정 수량이 달라지는 종목도 있어요. 같은 자산이라도 전송 경로가 여럿인 경우가 그래요. 경로를 고를 때 무엇을 확인해야 하는지는 출금 네트워크 선택 가이드에 따로 적어 두었어요. 그 글은 경로 선택과 잘못 보냈을 때의 대처를 다루고, 이 글은 경로가 정해진 다음 비트코인 위에서 값이 어떻게 계산되는지를 다뤄요.

내 거래가 몇 vB인지 확인하는 순서

이 글이 남기려는 절차예요. 결과를 보장하는 방법이 아니라 어느 값을 어디서 봐야 하는지를 정리한 순서예요.

1. 지갑이 보여 주는 단위를 먼저 봐요. 화면에 sat/vB로 뜨면 그것이 단가예요. 총액만 뜨는 지갑이라면 상세 보기나 고급 설정에서 단가 항목이 따로 있는지 확인해요.
2. 그 시점의 권장 단가를 따로 재요. 지갑 안의 추천값과 외부 창구의 값이 다를 수 있어요. 위에서 쓴 /api/v1/fees/recommended처럼 공개된 창구를 하나 정해 두면 대조가 쉬워요.
3. 내 거래의 가상 크기를 확인해요. 보내기 직전 화면에 vB가 표시되는 지갑도 있고, 보낸 뒤 탐색기에서 거래를 열어야 보이는 경우도 있어요. 표본 중앙값이 141 vB였으니 규모를 가늠하는 기준점으로 삼을 수 있어요.
4. 단가와 크기를 곱해 총액을 확인해요. 141 vB에 1 sat/vB를 곱하면 141 사토시예요. 지갑이 제시한 총액과 이 계산이 크게 어긋나면 크기 쪽을 다시 봐요.
5. 입력이 몇 개 묶였는지 봐요. 총액이 예상보다 크면 대개 여기서 갈려요. 잔돈 조각이 여러 개 묶이면 vB가 배로 뛰어요.
6. 대기 물량은 건수 대신 vB와 단가 분포로 봐요. 건수가 많아도 물량 대부분이 내 단가보다 낮은 구간에 몰려 있으면 낮은 단가로도 다음 블록에 들어갈 수 있어요.
7. 거래소 창구를 통해 보낸다면 층을 갈라요. 그 화면의 숫자는 종목별 고정 수량일 가능성이 크고, 온체인 단가와는 계산 근거가 달라요.

이 글에서 확인하지 못한 것

범위를 밝혀 둘게요. 아래는 이번 조회에서 확정하지 못한 항목이에요.

• mempool.space는 3자 도구예요. 규격 주장은 BIP-141 원문으로 받쳤지만, 실시간 수치는 이 창구의 응답이에요. 노드를 직접 돌려 같은 값을 재현하지는 않았어요.
• 블록 분포값이 어느 범위까지 묶음 실효 단가인지는 응답에 설명돼 있지 않아요. 표본 249건 중 블록 최저값 0.40 sat/vB 아래였던 두 건은 /api/v1/cpfp/로 묶음 실효 단가가 각각 2.24 sat/vB와 2.25 sat/vB임을 확인했어요. 다만 블록 분포의 모든 구간이 같은 방식으로 계산된 값인지는 이 창구의 응답만으로 확정하지 못했어요.
• 표본은 전수가 아니에요. 블록 962371은 거래가 6,126건인데 개별로 받은 것은 목록 앞에서부터 250건(코인베이스 제외 249건)이에요. 중앙값 141 vB와 범위 66~6,164 vB는 그 표본 안의 값이에요.
• 멤풀에서 가장 높은 단가가 얼마였는지는 이 응답으로 알 수 없어요. /api/mempool의 수수료율 분포는 대기 물량을 구간 단위로 묶어 주는 형식이라 구간별 물량은 나오지만 위쪽 끝값은 나오지 않아요. 같은 이유로 1 sat/vB 경계에서도 구간 하나만큼의 어림이 남아요. 이번 응답에서 그 구간의 물량은 52,197 vB, 전체의 0.13퍼센트였어요.
• 거래소가 고정 수량을 어떻게 정하고 그중 얼마를 실제 온체인 전송에 쓰는지는 공개 응답에 없어요. 이번에 확인한 것은 코인원과 코빗 두 곳의 BTC 고정 수량이 각각 0.0008 BTC라는 사실까지예요.
• 지갑이 실제로 몇 vB를 만들지는 미리 확정할 수 없어요. 어떤 조각을 몇 개 묶을지는 지갑 소프트웨어가 정하고, 그 규칙은 제품마다 달라요.

오해와 원문을 한 표로

자주 묻는 질문 (FAQ)

Q. 비트코인 송금 수수료는 결국 얼마인가요?

한 숫자로 답하면 그 답은 하루도 못 가요. 계산식으로 답하면 오래 남아요. 수수료는 거래의 가상 크기(vB) × 단가(sat/vB)예요. 2026년 8월 14일 오후 1시 25분에 조회한 권장 단가는 다섯 등급이 모두 1 sat/vB였고, 같은 시각 블록 962371 표본의 가상 크기 중앙값은 141 vB였어요. 두 값을 곱하면 141 사토시이고 원화로 약 126원이에요. 다만 이 값은 조회 시각의 값이고, 단가와 크기 모두 바뀌므로 보내기 전 화면에서 직접 확인하는 편이 맞아요.

Q. 큰 금액을 보내면 수수료도 많이 나오나요?

금액 자체는 계산에 들어가지 않아요. 블록 962371에서 20,282.525 BTC를 옮긴 거래는 276 vB에 2,770 사토시를 냈고, 0.0155 BTC를 옮긴 거래는 189 vB에 11,340 사토시를 냈어요. 다만 간접적인 연결은 있어요. 큰 금액을 만들려고 작은 조각을 여럿 묶으면 입력 개수가 늘어 가상 크기가 커져요. 커지는 원인은 금액이 아니라 묶인 입력의 개수예요.

Q. sat/vB의 vB는 바이트와 다른가요?

달라요. BIP-141은 거래 무게를 기본 크기의 세 배에 전체 크기를 더한 값으로 정의하고, 가상 크기를 그 무게를 4로 나눈 값으로 정의해요. 나누어떨어지지 않으면 다음 정수로 올려요. 실제로 블록 962371의 한 거래는 전체 크기가 379바이트인데 가상 크기는 189 vB였어요. 서명 데이터가 무게에 한 번만 반영되기 때문에 바이트 수보다 작게 나온 값이에요.

Q. 대기 중인 거래가 4천만 vB나 쌓였는데 1 sat/vB로 보내도 되나요?

조회 시각의 분포를 보면 그 물량의 99.87퍼센트가 1 sat/vB 미만 구간에 몰려 있었어요. 그 시각 기준으로는 1 sat/vB가 대기 물량 대부분보다 위에 있었다는 뜻이에요. 다만 이 응답은 대기 물량을 구간 단위로 묶어 주기 때문에 멤풀에서 가장 높은 단가가 얼마인지까지는 알려 주지 않아요. 그리고 이 분포는 관측 시점의 상태이고 계속 바뀌어요. 보내기 직전에 같은 창구를 다시 재서 그때의 분포로 판단하는 편이 맞아요.

Q. 왜 어떤 거래는 60 sat/vB나 냈나요?

단가를 정하는 주체가 보내는 쪽이기 때문이에요. 지갑이 넉넉하게 잡아 주기도 하고 사용자가 직접 올리기도 해요. 블록 962371의 중앙값이 0.52 sat/vB였으니 60 sat/vB는 그 약 115배예요. 다만 보내는 시점에는 다음 블록에 얼마나 자리가 남을지 알 수 없어요. 결과를 놓고 보면 과했다고 말할 수 있어도, 그 판단을 사전에 내릴 수 있었다는 뜻은 아니에요.

Q. 거래소 출금 화면에 뜨는 수수료가 이 값인가요?

아니에요. 층이 달라요. 조회 시각에 코인원과 코빗의 공개 API를 열어 보니 BTC 값이 각각 0.0008 BTC 고정이었어요. 원화로 약 71,520원이고, 같은 시각 온체인 실측 141 사토시(약 126원)와 약 567배 차이가 나요. 거래소 값은 종목별로 미리 정해 둔 수량이고 온체인 값은 크기와 단가의 곱이라 계산 근거가 서로 달라요. 두 곳만 확인한 값이므로 국내 전체가 같다는 뜻은 아니에요.

Q. 수수료를 적게 내면 거래가 사라지나요?

이번 조회로 확인한 범위에서는 낮은 단가의 거래도 줄에 남아 있었어요. 조회 시각 대기 물량 39,857,145 vB 중 39,804,948 vB가 1 sat/vB 미만 구간에 있었어요. 다만 낮은 단가만으로 블록에 들어간다고 읽으면 안 돼요. 블록 962371에 실린 0.10 sat/vB짜리 거래는 같은 블록에 함께 실린 자식 거래가 474 사토시를 얹어 준 덕에 묶음 단가가 2.24 sat/vB가 된 경우였어요. 그리고 언제 처리되는지는 그때그때 분포에 달려 있고, 지갑이나 노드가 오래된 거래를 대기열에서 내리는 정책은 이 응답으로 확인하지 못했어요.

Q. 이 글의 숫자를 그대로 믿어도 되나요?

측정 시각의 값으로만 봐 주세요. 권장 단가와 대기 물량은 2026년 8월 14일 오후 1시 25분(KST), 블록 지표는 같은 날 오후 1시 25분 조회 기준이에요. 규격에 관한 부분(가상 크기 정의, 무게 상한 4,000,000)은 BIP-141 원문이라 시각과 무관하지만, 실시간 수치는 분 단위로 바뀌어요. 이 글이 남기려는 것은 값이 아니라 값을 재는 자리예요.

이렇게 걷힌 수수료가 채굴자 수입에서 차지하는 몫도 따로 세어 봤어요. 블록 998개를 누가 캤는지 세어 봤어요에 채굴 풀 점유율과 함께 정리해 뒀어요.

정리

• 비트코인 송금 수수료는 금액이 아니라 거래의 가상 크기(vB)에 붙어요. 같은 블록에서 20,282 BTC 건이 2,770 사토시, 0.0155 BTC 건이 11,340 사토시를 냈어요.
• 가상 크기의 정의는 BIP-141 원문에 있어요. 무게 = 기본 크기 × 3 + 전체 크기, 가상 크기 = 무게 ÷ 4(올림)이에요.
• 블록 한 개의 자리는 무게 4,000,000, 곧 1,000,000 vB예요. 블록 962371은 999,488 vB를 채웠어요.
• 크기를 키우는 것은 금액이 아니라 입력 개수예요. 입력 67개짜리 거래는 6,164 vB였고 표본 중앙값의 43배가 넘었어요.
• 조회 시각 권장 단가는 다섯 등급이 모두 1 sat/vB였고, 대기 물량의 99.87퍼센트가 그보다 낮은 구간에 있었어요.
• 한 블록 안에서도 단가가 0.40에서 60.16 sat/vB까지 벌어졌어요. 단가는 보내는 쪽이 정해요.
• 거래소 화면의 고정 수량은 다른 층이에요. 코인원과 코빗의 BTC 값은 0.0008 BTC였고 온체인 실측과 약 567배 차이가 났어요.

수수료가 얼마인지를 외우려 하면 매번 다시 검색하게 돼요. 대신 크기와 단가라는 두 칸만 기억해 두면 화면에 뜨는 숫자가 왜 그 값인지 스스로 검산할 수 있어요. 오늘 잰 값은 오늘의 값일 뿐이고, 재는 자리는 그대로 남아요.

이 글은 공개 API 응답과 규격 문서 원문을 직접 열어 정리한 정보 제공 글이며 매매를 권유하는 글이 아니에요. 특정 시점에 전송하라거나 보류하라는 뜻으로 읽지 말아 주세요. 가상자산은 변동성이 크고 원금 손실 위험이 있으며, 거래와 보유의 판단과 책임은 본인에게 있어요.

확인한 자료: mempool.space 공개 API의 권장 수수료율 응답(74 bytes), 대기 상태 응답(3,523 bytes), 최근 블록 응답(30,180 bytes)과 블록 962371 소속 거래 250건의 개별 조회 응답, 코인원 공개 통화 정보 응답과 코빗 공개 통화 정보 응답, 업비트 원화 마켓 시세 응답. 모두 2026년 8월 14일 오후 1시 21분부터 1시 26분(KST) 사이에 직접 호출해 받았어요. 묶음 실효 수수료율은 같은 창구의 /api/v1/cpfp/ 응답을 같은 날 오후 2시 20분부터 2시 30분(KST) 사이에 따로 받아 확인했어요. 확정된 블록의 값이라 조회 시각에 따라 달라지지 않아요. 규격 인용은 bitcoin/bips 저장소의 BIP-141 원문(26,314 bytes)이에요.