호가창을 열어 두고 아래로 내려가다 보면 이상한 줄이 보일 때가 있습니다. 가격은 멀쩡히 적혀 있는데 그 옆의 수량 칸이 0입니다.
주문이 사라진 자리가 아닙니다. 화면으로 실려 오는 수량 숫자가 소수점 넷째 자리에서 끊기기 때문입니다. 빗썸 공개 호가창은 잔량을 0.0001 단위로 내주고, 실제 수량이 그보다 작으면 그 칸에 0이 찍힙니다.
그래서 빗썸 원화마켓 482종의 실호가 14,434건을 다섯 번 받아 수량의 소수점 자릿수를 전수로 셌습니다. 다섯 번 모두 넷째 자리를 넘은 호가가 한 건도 없었습니다.
먼저 이 글이 재는 자리를 못박아 두겠습니다. 인증 헤더도 API 키도 한 번도 붙이지 않고 국내 원화 거래소 다섯 곳의 공개 창구를 2026년 9월 12일 오후 1시 19분부터 1시 30분 사이에 부르고 받은 값입니다. 시각은 전부 한국 기준입니다. 가격 전망도 김프 계산도 하지 않습니다. 매매 권유가 아닙니다.
![]()
앞서 다룬 글과 어디가 다른지부터 갈라 둡니다
이 사이트는 8월 25일에 업비트 호가창에 지금은 낼 수 없는 가격이 남아 있다는 글을 썼습니다. 같은 호가창 이야기이니 먼저 갈라 두겠습니다.
그 글이 잰 것은 가격 쪽 눈금입니다. 거래소가 정해 둔 가격 단위와 실제로 호가에 남아 있는 가격이 어긋난 자리를 셌습니다. 이 글이 재는 것은 수량 쪽 표시 자릿수이고, 거래소도 업비트가 아니라 빗썸입니다. 재는 축과 대상이 둘 다 다릅니다.
호가창이라는 화면 자체가 처음이시라면 코인 호가창 보는 법을 먼저 보셔도 좋습니다. 그 글은 화면을 읽는 법이고, 이 글은 그 화면에 실려 오는 숫자의 자릿수를 셉니다.
무엇을 언제 불렀는지부터 적습니다
숫자보다 재료를 먼저 밝혀 두겠습니다. 파이썬 표준 라이브러리로 인증 헤더를 한 번도 붙이지 않고 받았고, 받은 원문은 스냅숏마다 그대로 저장했습니다.
| 거래소 | 창구 | 받은 것 |
|---|---|---|
| 빗썸 | v1/market/all?isDetails=false | 원화마켓 482종 |
| 빗썸 | v1/orderbook?markets= (20종목씩 25회) | 종목당 30호가 양쪽, 5회 반복 |
| 빗썸 | public/orderbook/ALL_KRW | 482종 4,817건, 수량이 문자열 |
| 빗썸 | public/ticker/ALL_KRW | 482종 종가 |
| 빗썸 | public/transaction_history/BTC_KRW?count=100 형태 | 12종목 1,200건 |
| 빗썸 | v1/trades/ticks?market=KRW-BTC&count=100 | 100건 |
| 업비트 | v1/orderbook?markets= (10종목씩) | 원화마켓 288종 전수 |
| 코인원 | public/v2/orderbook/KRW/ 종목별 | 25종목 표본 |
| 코빗 | v2/orderbook?symbol= 종목별 | 25종목 표본 |
| 고팍스 | trading-pairs/ 페어별 /book | 12페어 표본 |
종목 목록은 빗썸 v1/market/all 에서 market 값이 KRW- 로 시작하는 행만 남겨 482종을 얻었고, 같은 시각 public/ticker/ALL_KRW 에서도 482종이 나와 두 창구가 서로 일치했습니다.
여기서 함정 하나를 먼저 적어 둡니다. public/orderbook/ALL_KRW 에 count 파라미터를 붙여도 무시됩니다. 30을 넣어도 종목당 매수 5단과 매도 5단만 옵니다. 30단이 필요하면 v1/orderbook 쪽을 써야 합니다. 고팍스 호가 경로도 order-book 과 orderbook 은 둘 다 404 이고 book 이 맞습니다.
실호가 14,434건에서 다섯째 자리는 한 건도 없었습니다
분모부터 정하겠습니다. 482종에 종목당 30호가, 매수와 매도 양쪽이니 14,460 슬롯입니다. 그런데 이 안에는 호가가 30단을 채우지 못한 종목의 빈 자리가 섞여 있습니다.
| 라벨 | 값 | 세는 방법 |
|---|---|---|
| 슬롯 총수 | 14,460 | 482종 곱하기 30단 곱하기 양쪽 |
| 패딩 | 26건 | 가격도 0이고 수량도 0인 줄 |
| 실호가 | 14,434건 | 슬롯에서 패딩을 뺀 것 |
패딩 26건은 숨은 주문이 아닙니다. 가격 자리까지 0이라 이 글이 세려는 대상과 성격이 다릅니다. 처음 셀 때 이것을 섞어 62건이라는 틀린 수가 나왔고, 분리한 뒤에야 숫자가 맞았습니다. 그리고 이 26건과 14,434건은 다섯 스냅숏 모두 같았습니다.
실호가 14,434건의 수량 소수점 자릿수를 그대로 세면 이렇습니다. 응답이 JSON 숫자형이라 뒤에 붙은 0은 떨어져 나간 뒤의 값입니다.
| 소수점 자릿수 | 호가 수 |
|---|---|
| 0자리 | 26 |
| 1자리 | 2,019 |
| 2자리 | 191 |
| 3자리 | 1,255 |
| 4자리 | 10,969 |
| 5자리 이상 | 0 |
전부 더하면 14,460입니다. 0자리 26건이 앞의 패딩입니다. 그리고 다섯 스냅숏 전부 최댓값이 4였습니다. 다섯째 자리가 실린 호가는 총 72,300 슬롯을 통틀어 한 건도 나오지 않았습니다.
문자열로 다시 받아도 전부 넷째 자리였습니다
JSON 숫자형은 뒤의 0을 떨어뜨리므로 자릿수를 셀 때 미덥지 않은 구석이 있습니다. 그래서 수량을 문자열로 주는 다른 창구로 한 번 더 확인했습니다.
public/orderbook/ALL_KRW 는 수량을 "0.0190" 처럼 따옴표 안에 담아 보냅니다. 오후 1시 21분에 받은 482종 4,817건의 자릿수 분포는 넷째 자리 4,817건 하나뿐이었습니다. 예외가 한 건도 없습니다. 문자열 표면에서 보면 빗썸은 언제나 소수점 네 자리를 채워서 보냅니다. 그래서 수량이 작은 호가는 "0.0000" 이라는 문자열로 옵니다.
그 "0.0000" 이 이 창구에서는 11건, 종목으로는 11종이었습니다. 두 분 전인 1시 19분경 같은 창구에서는 16건 16종이었습니다. 이 창구가 종목당 5단씩만 주기 때문에 뒤에 나올 30단 기준 숫자보다 작습니다.
총합 필드로 되찾을 수도 없습니다
잘려 나간 수량을 총합에서 역산해 복원할 수 있는지도 확인했습니다.
비트코인 응답의 total_bid_size 가 0.7451 이었고, 같은 응답의 orderbook_units 30건에 실린 bid_size 를 그대로 더한 값도 정확히 0.7451 이었습니다. 총합 쪽에 여분의 자릿수가 남아 있지 않다는 뜻입니다. 총합도 같은 눈금으로 끊겨서 옵니다.
그래서 수량이 0으로 찍힌 호가가 32건에서 38건 있었습니다
이제 표제 숫자입니다. 가격은 실려 있는데 수량만 0인 호가를 스냅숏마다 셌습니다.
| 스냅숏 | 시각 | 소요 | 실호가 | 수량 최대 자릿수 | 수량 0 호가 | 해당 종목 |
|---|---|---|---|---|---|---|
| 1회 | 13:22:38 | 4.6초 | 14,434 | 4자리 | 32건 | 29종 |
| 2회 | 13:24:28 | 4.6초 | 14,434 | 4자리 | 32건 | 28종 |
| 3회 | 13:26:30 | 4.7초 | 14,434 | 4자리 | 32건 | 28종 |
| 4회 | 13:27:20 | 4.7초 | 14,434 | 4자리 | 32건 | 29종 |
| 5회 | 13:29:56 | 4.6초 | 14,434 | 4자리 | 38건 | 33종 |
여기서 한 가지를 솔직하게 적어 두겠습니다. 네 번 연속 32건이 나와서 저는 이 값을 고정값으로 읽을 뻔했습니다. 다섯 번째에서 38건이 나와 깨졌습니다. 스냅숏을 넷에서 멈췄다면 이 글은 「32건으로 고정」이라는 틀린 문장을 실었을 것입니다.
그러니 이 값은 하나의 숫자가 아니라 범위입니다. 관측 창 안에서 32건에서 38건, 종목으로는 28종에서 33종 사이를 오갔습니다. 인용하실 때도 범위와 조회 시각을 함께 적어 주시기 바랍니다.
같은 응답을 다섯 번 받은 것이 아닙니다
건수가 안 움직인 자리도 있으므로, 창구가 얼어붙어 캐시된 같은 응답을 돌려준 것은 아닌지 대조군을 함께 봤습니다.
| 스냅숏 | 비트코인 timestamp | 최우선 매수 | 최우선 매도 | total_bid_size |
|---|---|---|---|---|
| 1회 | 1789186958743 | 104,982,000 | 104,983,000 | 0.1914 |
| 2회 | 1789187067708 | 104,970,000 | 104,981,000 | 0.1745 |
| 3회 | 1789187191317 | 104,970,000 | 104,995,000 | 0.1858 |
| 4회 | 1789187240142 | 104,970,000 | 104,994,000 | 0.1859 |
| 5회 | 1789187396525 | 104,990,000 | 104,993,000 | 0.4404 |
다섯 스냅숏의 타임스탬프가 전부 달랐고 최우선 호가와 총잔량도 매번 움직였습니다. 수량이 0으로 찍힌 종목의 구성도 스냅숏마다 바뀌었습니다. 1회에만 나온 종목이 다섯 종 있었고 2회와 3회와 4회에도 각각 세 종씩 새로 들어왔습니다. 반대로 네 번 내내 같은 자리에 있던 종목도 22종 있었습니다.
움직이지 않은 것은 자릿수 쪽입니다. 수량 최대 자릿수 4와 실호가 14,434와 패딩 26은 다섯 번 모두 같았습니다. 그래서 이 글은 자릿수는 구조로 읽고 건수는 범위로 읽습니다.
같은 회사의 체결 내역은 여덟째 자리까지 줍니다
여기가 이 글에서 가장 중요한 대목입니다. 호가창에서 0으로 보이는 수량이 실제로는 거래되고 있습니다.
빗썸 체결 내역 창구를 12종목에 대해 각 100건씩, 모두 1,200건 받았습니다. 열두 종목 전부에서 units_traded 의 소수점 최대 자릿수가 8 이었습니다. 같은 회사가 같은 시각에, 한쪽 창구로는 네 자리를 주고 다른 창구로는 여덟 자리를 주고 있었습니다.
그리고 그 1,200건 가운데 호가창 눈금 한 칸인 0.0001보다 작은 체결이 29건 있었습니다.
| 종목 | 0.0001보다 작은 체결 | 실제 예시 수량 |
|---|---|---|
| BTC | 16건 | 0.00004762 |
| SAND | 5건 | 0.00007647 |
| BCH | 3건 | 0.00008773 |
| ETC | 2건 | 0.00009169 |
| ETH | 1건 | 0.00002888 |
| ADA | 1건 | 0.00002338 |
| LINK | 1건 | 0.00006002 |
| XRP·SOL·DOGE·TRX·PAXG | 0건 | 해당 없음 |
가장 또렷한 한 줄을 그대로 옮깁니다. 오후 1시 10분 56초에 체결된 매수 한 건은 수량이 0.00004762 비트코인이고 금액이 5,001원이었습니다. 이 수량은 호가창 눈금 0.0001의 절반도 되지 않습니다. 같은 주문이 호가창에 잔량으로 걸려 있었다면 화면에는 0으로 보였을 것입니다.
업비트 호환 스키마를 쓰는 v1/trades/ticks 쪽도 마찬가지였습니다. 비트코인 100건에서 trade_volume 의 최대 자릿수가 8이었고, 0.0001보다 작은 체결이 100건 중 15건이었습니다.
다만 범위를 좁혀 두겠습니다. 주문을 실제로 내 보지는 않았습니다. 주문 엔진이 몇 자리까지 받아 주는지는 인증이 필요해 확인할 수 없었습니다. 이 글의 근거는 「체결 내역에 여덟 자리가 남아 있다」는 데까지입니다.
![]()
나머지 네 곳은 호가 수량도 여덟째 자리였습니다
같은 시각대인 오후 1시 21분에 네 곳을 함께 받아 같은 방식으로 셌습니다.
| 거래소 | 표본 | 호가 건수 | 수량 최대 자릿수 | 수량 0 호가 |
|---|---|---|---|---|
| 빗썸 | 원화마켓 482종 전수 | 14,434 | 4자리 | 32건에서 38건 |
| 업비트 | 원화마켓 288종 전수 | 17,280 | 8자리 | 0건 |
| 코인원 | 25종목 표본 | 750 | 8자리 | 0건 |
| 코빗 | 25종목 표본 | 1,320 | 8자리 | 0건 |
| 고팍스 | 12페어 표본 | 4,859 | 8자리 | 0건 |
업비트 쪽은 288종 17,280호가를 4.2초에 받았고 전수입니다. 코인원과 코빗과 고팍스는 표본이므로 이 결과를 그 거래소 전 종목에 그대로 옮기시면 안 됩니다. 표본 안에서 넷째 자리로 끊긴 수량이 한 건도 없었다는 데까지입니다.
읽는 방향도 좁혀 두겠습니다. 자릿수가 여덟 자리라고 해서 그 거래소가 더 낫다는 뜻이 아닙니다. 표시 해상도가 다르다는 관측일 뿐이고, 어느 쪽이 옳은 설계인지는 이 글이 판정하지 않습니다.
같은 0.0001이 비트코인에서는 1만원이고 어떤 코인에서는 0원입니다
눈금 한 칸이 실제로 얼마어치인지를 482종 전체에 대해 계산했습니다. 오후 1시 23분 종가에 0.0001을 곱한 값이고, 이 곱셈은 제가 한 것이지 거래소가 준 숫자가 아닙니다.
| 코인 | 종가 (원) | 눈금 한 칸 (원) |
|---|---|---|
| BTC | 104,982,000 | 10,498.20 |
| PAXG | 5,919,000 | 591.90 |
| XAUT | 5,910,000 | 591.00 |
| ETH | 3,411,000 | 341.10 |
| YFI | 2,987,000 | 298.70 |
| BNB | 996,500 | 99.65 |
반대쪽 끝은 이렇습니다. NFT 는 종가 0.0003원이라 눈금 한 칸이 0.00000003원이고, BTT 는 0.00000005원, PEPE 는 0.00000046원입니다.
482종 전체를 구간으로 나누면 눈금의 값이 한쪽으로 크게 쏠려 있습니다.
| 눈금 한 칸의 원화 가치 | 종목 수 |
|---|---|
| 1,000원 이상 | 1 |
| 100원 이상 1,000원 미만 | 4 |
| 10원 이상 100원 미만 | 6 |
| 1원 이상 10원 미만 | 9 |
| 0.01원 이상 1원 미만 | 176 |
| 0.01원 미만 | 286 |
전부 더하면 482입니다. 가장 큰 쪽과 가장 작은 쪽의 비는 약 3,499억 배입니다.
같은 0.0001이라는 눈금인데 비트코인에서는 1만원어치가 한 칸이고, 482종 중 286종에서는 한 칸이 0.01원도 되지 않습니다. 표시 눈금은 하나인데 그 눈금이 가리는 금액은 종목마다 완전히 다릅니다. 비트코인 호가창에서 0으로 보이는 줄은 금액으로는 1만원 밑의 주문이고, 저가 코인에서 0으로 보이는 줄은 사실상 0원어치입니다. 같은 0을 같은 뜻으로 읽으면 안 되는 이유입니다.
거래소가 문서에 적어 둔 자릿수는 또 다른 것을 잽니다
「그러면 거래소가 자기 자릿수를 어딘가에 적어 두지 않았나」라고 물으실 수 있습니다. 적어 둔 곳이 있기는 한데, 그 값이 재는 대상이 호가 표시와 다릅니다.
코인원은 원화마켓 364행 전부에 거래 수량 단위 qty_unit 을 0.00000001 로 적어 두었습니다. 364행 전부 같은 값이고 예외가 없습니다. 같은 회사의 종목 목록에는 max_precision 이라는 값도 있고 364종 중 54종이 8보다 짧습니다. 다만 이 둘을 나란히 놓고 모순이라고 읽으면 안 됩니다. 코인원 문서는 max_precision 을 출금 가능한 소수점 아래 자릿수로 설명합니다. 거래 단위와 출금 자릿수는 서로 다른 것을 재는 값입니다. 쓸 수 있는 문장은 여기까지입니다. 코인원은 거래를 여덟 자리로 받고, 출금 자릿수는 종목마다 달라 364종 중 54종이 여덟 자리보다 짧습니다.
고팍스는 자산 쪽 scale 과 페어 쪽 baseAssetScale 두 자리에 자릿수를 적어 두는데, 원화 페어 111개 가운데 두 값이 어긋난 페어가 2개 있었습니다. SEI-KRW 가 자산 8에 페어 6이고 STOC-KRW 가 자산 6에 페어 8입니다. 자산 256행 기준 scale 분포는 여덟 자리가 218행으로 대부분이고 여섯 자리 17행, 네 자리 9행 순입니다.
업비트와 빗썸의 공개 창구에는 종목별 수량 자릿수를 적어 둔 필드 자체가 없었습니다. 지갑 상태 창구는 인증을 요구합니다.
마지막으로 함정 하나를 더 적어 둡니다. 코빗 종목 목록에는 withdrawalPrecision 이라는 값이 있고 18이나 24 같은 큰 수가 들어 있습니다. 이건 체인의 소수점 자릿수이지 거래소가 다루는 코인 자릿수가 아닙니다. 이더리움 계열이 18인 것이 그 예입니다. 앞의 코인원이나 고팍스 값과 나란히 놓고 비교하면 사실이 아닌 표가 만들어집니다. 같은 자리에서 넘어지기 쉽다는 이야기는 어제 코인 입금 컨펌 수를 적어 둔 공개 창구는 두 곳이라는 글에서도 한 번 적었습니다.
그래서 무엇을 하면 되는가
관측을 실무 문장으로 줄이면 다섯 줄입니다.
첫째, 빗썸 호가창의 수량 0을 빈 자리로 읽지 마십시오. 가격까지 0인 줄과 가격은 있고 수량만 0인 줄은 응답 안에서 분명히 다릅니다. 앞쪽은 30단을 못 채운 빈 자리이고 뒤쪽은 표시 눈금보다 작은 수량입니다.
둘째, 빗썸 호가 수량은 표시값이라고 보고 코드를 짜십시오. 잔량을 합산해 벽 두께를 재는 코드라면 넷째 자리 아래가 이미 잘려 있습니다. 그 값을 정확한 수량으로 취급하면 눈금 아래가 통째로 빠집니다.
셋째, 총합 필드로 되찾으려 하지 마십시오. 총 매수잔량도 같은 눈금으로 끊겨 오고, 실제로 30호가 합계와 정확히 같았습니다.
넷째, public/orderbook/ALL_KRW 는 다섯 단씩만 줍니다. count 를 붙여도 무시되므로 30단이 필요하면 다른 창구를 쓰셔야 합니다.
다섯째, 거래소마다 자릿수가 다르다는 것을 상수로 박지 마십시오. 같은 시각에 다섯 곳을 받아 보니 한 곳만 네 자리였습니다. 여러 거래소를 함께 다루는 코드라면 자릿수를 거래소별 설정으로 빼 두시는 편이 안전합니다.
확인하지 못한 것
정직하게 적어 두겠습니다.
- 관측 창이 11분 남짓입니다. 오후 1시 19분부터 1시 30분 사이이고, 그 바깥의 시간에 대해서는 이 글이 아무것도 말하지 않습니다. 「항상 네 자리다」가 아니라 「이 창 안에서 네 자리를 넘은 적이 없다」입니다.
- 왜 넷째 자리인지 모릅니다. 빗썸 공개 문서 어디에서도 수량 표시 자릿수를 명시한 문장을 찾지 못했습니다.
- 버림인지 반올림인지 구분하지 못했습니다. 0으로 찍히려면 버림일 때 0.0001보다 작아야 하고 반올림이라면 0.00005보다 작아야 하는데, 바깥에서는 어느 쪽인지 가릴 수 없습니다.
- 수량 0 호가가 살아 있는 주문이라고 단정하지 않습니다. 확인된 것은 가격은 실려 있는데 수량 자리가 0이라는 데까지입니다.
- 주문을 내 보지 않았습니다. 주문 엔진이 몇 자리까지 받는지는 인증이 필요해 확인할 수 없었습니다.
- 코인원과 코빗과 고팍스는 표본입니다. 각각 25종목과 25종목과 12페어이고 업비트만 288종 전수입니다.
- 눈금의 원화 환산은 제가 곱한 값입니다. 종가에 0.0001을 곱했고 거래소가 준 숫자가 아닙니다. 시세가 움직이면 같이 움직입니다.
- 가격과 거래량과 김프와 수익률은 다루지 않았습니다. 디지털자산은 원금 손실 위험이 있고 모든 판단은 본인 책임입니다.
![]()
정리
세 줄로 줄이면 이렇습니다.
첫째, 빗썸 공개 호가창의 수량은 소수점 넷째 자리에서 끊깁니다. 원화마켓 482종 실호가 14,434건을 다섯 번 세는 동안 다섯째 자리가 실린 호가가 한 건도 없었고, 문자열로 주는 다른 창구에서는 4,817건 전부가 정확히 네 자리였습니다.
둘째, 그래서 가격은 있는데 수량만 0인 호가가 32건에서 38건 있었습니다. 네 번 연속 32건이 나와 고정값처럼 보였지만 다섯 번째에서 38건으로 깨졌습니다. 하나의 숫자가 아니라 범위로 읽으셔야 합니다.
셋째, 같은 회사의 체결 내역은 여덟 자리까지 주고 눈금보다 작은 체결이 실제로 있었습니다. 1,200건 중 29건이고 그중 하나가 5,001원어치 비트코인 0.00004762개입니다. 호가창에서 0으로 보일 수량이 실제로 체결됩니다.
여기 적힌 값은 2026년 9월 12일 오후 11분 남짓한 구간의 공개 응답을 세어 둔 기록일 뿐입니다. 거래소는 표시 방식을 예고 없이 바꿀 수 있고, 지금 다시 부르면 다른 값이 나올 수 있습니다. 인용하실 때는 조회 시각과 창구 이름을 함께 적어 주시기 바랍니다. 이 글은 어떤 종목의 매매도 권하지 않습니다.