Bitcoin Core의 수수료 추정기는 미래 블록을 정확히 그려 내는 예언기가 아닙니다. 노드가 관찰한 멤풀(mempool) 거래를 수수료율 구간으로 나누고, 구간마다 몇 블록 안에 확인됐는지 통계로 추적해 목표 확인 시점에 맞는 수수료율을 고릅니다. 로컬 노드의 가동 시간과 멤풀 시야, 최근 거래량에 기대므로 새로 띄운 노드나 갑작스러운 수수료 급등, 거래 정책 변화 앞에서는 추정치가 아예 없거나 실제 대기 시간과 어긋날 수 있습니다.
관찰 데이터는 이 노드의 멤풀에서 출발합니다
거래가 멤풀에 들어온 높이와 수수료율, 블록에 담긴 높이를 지켜보면 몇 블록 만에 확인됐는지 알 수 있습니다. 추정기는 비슷한 수수료율을 구간으로 묶고, 성공·실패 표본의 비중을 시간이 갈수록 낮춰 최근 환경에 더 무게를 둡니다. 다른 노드가 보지 못한 비공개 거래나 채굴자 정책은 반영하지 못합니다.
노드를 막 켰거나 그동안 쌓인 표본이 모자라면 믿을 만한 추정치를 내놓지 않을 수 있습니다. 릴리스 노트도 좋은 추정치를 언제나 얻을 수 있는 것은 아니라고 설명합니다. API가 빈 값이나 오류를 돌려줄 때 임의의 0 수수료로 바꿔 넣지 않습니다.
수수료 추정치는 미래 멤풀의 정답이 아닙니다. 이 노드가 지켜본 과거 확인률로 만든, 목표별 확률 판단입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 관찰 데이터는 이 노드의 멤풀에서 출발합니다
거래가 멤풀에 들어온 높이와 수수료율, 블록에 담긴 높이를 지켜보면 몇 블록 만에 확인됐는지 알 수 있습니다.
- 확인 목표는 숫자 하나로 된 약속이 아닙니다
estimatesmartfee의 conf_target은 대략 몇 블록 안에 담기길 바라는지를 나타냅니다.
- 수수료율과 총수수료를 나눠서 봅니다
추정기는 보통 BTC/kvB나 sat/vB 같은 수수료율을 돌려줍니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
확인 목표는 숫자 하나로 된 약속이 아닙니다
estimatesmartfee의 conf_target은 대략 몇 블록 안에 담기길 바라는지를 나타냅니다. 돌려받는 수수료율은 그 관찰 기간과 모드에서 충분한 성공률을 보인 구간을 바탕으로 합니다. 2 블록 목표를 골라도 다음 두 블록 안에 담긴다는 보장은 없습니다.
보수(conservative) 모드는 더 긴 관찰 기간과 넉넉한 기록을 써서 수수료가 갑자기 내려가도 덜 흔들리는 값을 줄 수 있습니다. 절약(economical) 모드는 짧은 기간의 변화에 더 민감하게 반응합니다. 실제 쓰는 Core 버전의 RPC 도움말에서 모드와 허용되는 목표 범위를 확인합니다. 화면에서 ‘빠름·보통’으로 바꿔 부르더라도 블록 목표는 함께 표시합니다.
| 값 | 역할 | 보장 여부 |
|---|---|---|
| 추정 수수료율 | 과거 확인률에서 나온 수수료율 | 블록 포함 보장 아님 |
| conf_target | 목표 블록 수 | 정확한 시간 아님 |
| mempoolminfee | 지금 이 노드가 받는 하한 | 채굴자 포함 보장 아님 |
| minrelaytxfee | 중계 정책 하한 | 네트워크 전체가 같지 않음 |
| fallbackfee | 추정치가 없을 때 지갑이 쓰는 값 | 시장 관찰치 아님 |
수수료율과 총수수료를 나눠서 봅니다
추정기는 보통 BTC/kvB나 sat/vB 같은 수수료율을 돌려줍니다. 실제 수수료는 서명을 마친 거래의 가상 크기에 이 수수료율을 곱해 나옵니다. 입력의 종류와 개수, 잔돈 출력, 증인 데이터가 가상 크기를 바꾸므로 보내는 금액만으로 수수료를 정할 수 없습니다.
코인 선택 뒤 입력이 예상보다 늘면 같은 수수료율에서도 수수료가 커집니다. 지갑은 수수료율의 출처, 예상 가상 크기, 총수수료를 함께 보여 주고 과도한 수수료를 막는 장치를 둡니다. BTC/kB와 sat/vB 사이를 오갈 때는 1000과 1e8 배율이 맞는지 테스트합니다.
- 사용하는 Core 버전과 RPC 도움말을 고정합니다.
- 목표 블록 수와 추정 모드를 기록합니다.
- 돌려받은 수수료율의 단위 변환을 검증합니다.
- 실제 거래의 가상 크기로 총수수료를 계산합니다.
- 추정치가 없거나 급등할 때를 대비해 수수료 올리기 경로를 마련합니다.
멤풀이 급변하면 과거 모델이 따라가지 못합니다
대규모 발행, 거래소 일괄 출금, 해시레이트 변화로 블록 간격이 벌어지는 경우처럼 새 수요가 생기면, 낮은 수수료율의 과거 성공률로는 지금의 대기열을 설명하지 못합니다. 거꾸로 일시적 급등이 끝난 뒤에도 보수 모드 추정치가 한동안 높게 남을 수 있습니다. 멤풀 분포도와 최근 블록을 보조 자료로 보되, 채굴자가 앞으로 무엇을 고를지 단정하지 않습니다.
채굴자마다 블록 템플릿 정책과 비공개 주문 흐름이 다를 수 있습니다. 로컬 mempoolminfee보다 높다는 사실이 넓은 중계나 빠른 확인을 보장하지는 않습니다. 사용자는 얼마나 급한지와 함께 RBF·CPFP를 쓸 수 있는지까지 고려해 골라야 합니다.
예측 오차는 수수료 올리기와 측정으로 다룹니다
수수료 대체(Replace-by-fee)가 가능한 거래라면 알맞은 시퀀스 값과 지갑 정책을 확인한 뒤, 처음엔 낮게 보내고 필요할 때 올릴 수 있습니다. 받는 쪽이나 서비스가 미확인 거래 ID를 고정해 추적한다면 대체 거래가 운영에 주는 영향을 따져 봅니다. CPFP에는 쓸 수 있는 자식 출력과 묶음 정책이 필요합니다.
운영 지표로는 추정치와 실제 확인까지 걸린 블록 수, 생성 당시 멤풀 크기, 수수료를 올린 횟수를 저장합니다. 평균만 보지 말고 목표별로 넘어선 비율을 살핍니다. 어느 하루 잘 맞았다고 항상 같은 고정 rate를 쓰지 않습니다.
자주 묻는 질문
2-block 추정치면 20분 안팎에 확정되나요?
보장되지 않습니다. 블록 간격과 앞으로의 멤풀, 채굴자 선택이 바뀌므로 목표 블록 수에 대한 통계적 추정일 뿐입니다.
추정치가 없으면 0 수수료로 보내도 되나요?
아닙니다. 지갑의 대체값과 현재 중계 정책, 수수료 올리기 전략을 먼저 확인해야 합니다.
수수료율이 같으면 모든 거래의 총수수료가 같나요?
아닙니다. 가상 크기가 입력·출력 수와 스크립트 종류에 따라 달라집니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
