멤풀 적체를 수요로 읽을 때: 재전송·낮은 수수료 거래 구분

멤풀의 미확인 거래 건수는 한 노드가 현재 보관하는 대기 거래의 수입니다. 건수가 많아도 대부분 낮은 수수료라면 높은 수수료 구간의 경쟁은 다를 수 있습니다. 거래의 가상 크기, 수수료율별 대기량, 신규 유입과 블록 포함 및 교체·퇴출을 함께 봐야 적체의 성격을 설명할 수 있습니다.

멤풀은 전 세계가 공유하는 하나의 대기표가 아닙니다

비트코인 노드는 아직 블록에 포함되지 않은 거래를 정책에 따라 받아 멤풀에 보관합니다. 노드마다 연결된 피어, 관측 시점, 메모리 한도와 정책이 달라 보유 목록이 완전히 같지 않을 수 있습니다. 한 서비스 화면의 숫자를 네트워크 전체의 정확한 미처리 주문 수라고 표현하면 관측 범위를 넘어서게 됩니다.

Bitcoin Core의 getmempoolinfo는 호출한 노드의 활성 멤풀 상태를 반환합니다. 분석 화면에는 조회 시각과 노드 버전, 가능하면 수집 간격을 함께 남기는 것이 좋습니다. 같은 이름의 지표라도 서로 다른 시각에 조회했다면 그 사이 생성된 블록과 거래 유입 때문에 값이 달라질 수 있습니다.

멤풀에 들어온 거래는 결제 외에도 지갑 정리, 거래소 출금 배치, 계약 조건의 지출 등 여러 목적을 가질 수 있습니다. 거래 수요 증가를 관찰할 수는 있어도 그 자체로 신규 투자자나 매수세가 늘었다고 결론 낼 수는 없습니다. 처리 대기량과 경제적 동기는 다른 분석 대상입니다.

대기열이 길다는 관측을 설명하려면 무엇이 얼마나 큰 공간을 차지하고 어느 수수료에서 기다리는지 함께 봐야 합니다.

JOBCOIN 멤풀 지표 해설

VISUAL GUIDE거래 요청부터 블록 확인까지

1. 01
   멤풀은 전 세계가 공유하는 하나의 대기표가 아닙니다

   비트코인 노드는 아직 블록에 포함되지 않은 거래를 정책에 따라 받아 멤풀에 보관합니다.

2. 02
   건수·가상 크기·메모리 사용량을 섞지 않습니다

   getmempoolinfo의 size는 현재 거래 건수이고 bytes는 거래 가상 크기의 합입니다.

3. 03
   낮은 수수료의 오래된 거래와 새 경쟁을 나눕니다

   총대기량이 늘었을 때 어느 수수료 구간이 증가했는지 살펴봅니다.

AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.

건수·가상 크기·메모리 사용량을 섞지 않습니다

getmempoolinfo의 size는 현재 거래 건수이고 bytes는 거래 가상 크기의 합입니다. usage는 노드가 멤풀 관리에 사용하는 메모리 양입니다. 이름이 bytes라고 해서 실제 직렬화 크기나 메모리 사용량과 같은 값으로 취급하면 안 됩니다. 위트니스 할인이 반영되는 가상 크기라는 정의를 확인해야 합니다.

같은 1만 건이라도 거래당 가상 크기가 가정상 평균 150vB인 집합과 600vB인 집합은 각각 약 150만vB와 600만vB를 차지합니다. 건수는 같지만 블록 공간과 경쟁하는 양은 네 배 차이가 납니다. 이 예시는 계산 원리를 위한 가상 자료이며 현재 멤풀 측정값이 아닙니다.

메모리 한도에 가까워졌다는 사실도 별도로 해석합니다. RAM을 얼마나 쓰는지와 다음 블록에 어느 거래가 들어갈지는 같은 질문이 아닙니다. 블록 공간 이용률과 대기 거래의 가상 크기를 함께 보되, 노드 내부 메모리 바이트를 블록 용량으로 바로 나누지 않습니다.

낮은 수수료의 오래된 거래와 새 경쟁을 나눕니다

총대기량이 늘었을 때 어느 수수료 구간이 증가했는지 살펴봅니다. 매우 낮은 수수료의 거래가 오래 쌓이는 경우와 상대적으로 높은 수수료의 거래가 짧은 시간에 유입되는 경우는 이용자가 경험하는 경쟁이 다릅니다. 두 상황의 총건수가 같아도 같은 혼잡이라고 설명하기 어렵습니다.

구간별 표를 만들 때는 건수와 가상 크기를 나란히 둡니다. 작은 거래가 많은 구간과 큰 거래가 적은 구간의 공간 부담이 다르기 때문입니다. 관측 구간 경계와 수수료 단위를 고정해야 어제와 오늘을 비교할 수 있습니다. sat/vB와 BTC/kvB를 숫자만 보고 같은 단위로 읽지 않습니다.

개별 거래의 수수료율만으로 순서를 완벽하게 예측할 수도 없습니다. 부모·자식 거래가 연결된 경우 함께 고려되는 경제성이 달라질 수 있습니다. package relay의 묶음 평가를 이해하면 낮은 수수료 거래가 다른 거래와 함께 처리되는 사례를 단순 이상치로 오해하지 않게 됩니다.

재전송과 교체 거래는 유입 건수의 뜻을 바꿉니다

동일한 거래를 여러 피어에서 다시 수신했다고 해서 멤풀 목록에 서로 다른 거래가 계속 쌓이는 것은 아닙니다. 네트워크 메시지 수를 세는 수집기는 재전송을 관측할 수 있지만 현재 고유 거래 목록의 크기와는 측정 대상이 다릅니다. 자료 제공자가 ‘수신 건수’와 ‘대기 건수’ 중 무엇을 표시하는지 확인합니다.

RBF 교체는 더 구체적인 구분이 필요합니다. 기존 거래와 입력을 공유하는 새 거래가 정책 조건을 만족하면 기존 거래 및 관련 후속 거래가 멤풀에서 대체될 수 있습니다. 교체 전후의 해시가 달라졌다는 이유만으로 독립적인 새 결제가 추가됐다고 세면 경제적 활동이 부풀 수 있습니다.

반대로 입력이 겹친다는 이유로 모든 교체를 완전히 같은 목적이라고 확정해서도 안 됩니다. 수취인이나 금액 등 내용이 달라질 수 있기 때문입니다. 분석에는 교체 관계를 남기고 ‘관측된 거래 버전 수’와 ‘대기 중인 고유 거래 수’를 분리하며, 결제 의도 추정에는 별도의 근거가 필요하다고 적습니다.

대기량 변화는 유입에서 여러 출구를 뺀 결과입니다

한 관측 간격 동안 새 거래가 들어오는 동시에 블록 포함, 교체, 만료 또는 정책상 퇴출이 일어날 수 있습니다. 따라서 멤풀 건수 감소를 모두 결제 완료로 해석하면 안 됩니다. 감소 원인을 구분하지 못하는 자료라면 순변화만 관측했다고 한계를 밝혀야 합니다.

가상으로 시작 시점 1,000건에서 독립 신규 거래 200건이 들어오고 150건이 블록에 포함되며 다른 30건이 퇴출되었다면, 다른 변화가 없을 때 마지막 값은 1,020건입니다. 순증 20건만 보면 실제 신규 유입 200건을 놓칩니다. 반대로 유입 200건만 강조하면 처리된 거래를 빠뜨립니다.

교체가 여러 기존 거래와 후손을 한꺼번에 제거할 수 있는 상황에서는 교체 한 번을 항상 건수 변화 0으로 가정하지 않습니다. 정확한 분해가 필요하다면 거래 입장·퇴장 이벤트와 제거 이유를 수집해야 합니다. 단순 주기별 스냅샷 두 개만으로 중간의 모든 사건을 복원할 수는 없습니다.

• 노드와 조회 시각 및 버전을 먼저 고정합니다.
• 총건수와 총가상 크기를 다른 열에 둡니다.
• 수수료 구간별 대기 크기와 유입 변화를 비교합니다.
• 재전송 메시지와 교체 거래 관계를 분리합니다.
• 블록 포함과 그 밖의 제거를 구분하지 못하면 한계를 표시합니다.

대기열을 미래 확인 시간의 보증으로 쓰지 않습니다

현재 대기량은 이미 관측된 거래의 스냅샷입니다. 앞으로 들어올 거래의 수수료와 규모, 블록 생성 간격은 확정돼 있지 않습니다. 대기량을 평균 블록 용량으로 나누는 계산은 거친 비교값이 될 수 있지만 개인 거래가 몇 분 뒤 확인된다는 약속이 될 수는 없습니다.

노드 수수료 추정기의 과거 확인률 기반 추정과 현재 멤풀 분포를 함께 보면 관측과 예측을 구분할 수 있습니다. 시황 기사에서는 ‘대기량 증가’, ‘상위 수수료 구간 경쟁 강화’, ‘추정 확인 시간 변화’를 각각 근거와 함께 쓰는 것이 정확합니다. 어느 하나도 코인 가격 방향을 단독으로 증명하지 않습니다.

자주 묻는 질문