바이낸스 Book Ticker 뜻 2026｜최우선 매수 매도 호가·수량·갱신 ID 읽기

바이낸스 Book Ticker 뜻 2026｜최우선 매수 매도 호가·수량·갱신 ID 읽기

바이낸스 Book Ticker는 특정 현물 거래쌍의 최우선 매수·매도 가격과 해당 수량이 바뀌는 정보를 받는 스트림입니다. 마지막으로 거래된 가격을 보여주는 Trade Stream과 관찰 대상이 다릅니다. 체결된 과거 가격에서 현재 제시된 호가로 시선을 옮길 때 알아야 할 자료입니다.

최우선 호가가 보인다고 그 가격에 원하는 전체 수량이 체결된다는 뜻은 아닙니다. 화면을 보는 동안 주문이 바뀔 수 있고 표시 수량보다 주문 규모가 크면 더 깊은 가격대가 중요해집니다. Book Ticker의 장점은 간결함이며, 같은 이유로 전체 호가장을 대신할 수는 없습니다.

이 글은 2026년 10월 29일 확인한 Binance Spot WebSocket 공식 문서의 Individual Symbol Book Ticker Streams를 기준으로 합니다. 선물의 동명 메시지와 현물 필드를 혼합하지 않습니다. 예시 가격·수량은 학습용 가정입니다.

1. 최우선 호가가 뜻하는 것

매수 호가 중 가장 높은 가격을 best bid, 매도 호가 중 가장 낮은 가격을 best ask로 읽습니다. 매수자가 제시한 가격과 매도자가 제시한 가격이라는 방향을 먼저 이해해야 합니다. 내가 매수할 때 참고하는 상대편 호가는 매도 호가이고, 내가 매도할 때 참고하는 상대편 호가는 매수 호가입니다.

이 관계를 반대로 읽으면 체결 비용 계산도 뒤집힙니다. 예를 들어 best bid 99, best ask 101인 가상 상황에서 즉시 매수의 출발점을 99라고 생각하면 상대편 호가를 잘못 선택한 것입니다. 다만 101 역시 실제 주문 전체의 보장 가격은 아니며 관측 당시의 최우선 제시 가격입니다.

가격과 수량을 함께 확인

가격만 보면 두 거래쌍이 비슷해 보이더라도 최우선 가격대에 남아 있는 수량은 다를 수 있습니다. 같은 스프레드라도 관측된 최상단 수량이 작으면 큰 주문의 실행 환경은 다르게 해석해야 합니다. Book Ticker는 가격과 함께 그 가격대 수량을 보여주므로 두 값을 분리해서 읽는 것이 좋습니다.

해당 수량은 특정 개인의 주문 크기나 거래 의도를 뜻하지 않습니다. 같은 가격대의 공개 수량을 관찰하는 자료입니다. 주문자가 누구인지, 왜 주문을 냈는지, 얼마나 오래 유지할지까지 알 수 있다고 해석해서는 안 됩니다.

최우선과 전체 깊이의 차이

첫 번째 가격대만 알면 그다음 가격대에 얼마가 있는지는 알 수 없습니다. 최상단 수량이 충분해 보이더라도 실제 도착 시점에는 줄어들 수 있고, 부족하다면 다음 가격대부터의 비용을 계산할 자료가 필요합니다. 이때 Partial Depth나 전체 로컬 호가장 관리가 다른 역할을 합니다.

Book Ticker의 수량을 전체 유동성으로 표시하는 것은 부정확합니다. "최우선 호가 수량"처럼 범위를 이름에 드러내야 합니다. 관측 깊이를 명확히 하는 것은 지표를 과장하지 않는 가장 간단한 방법입니다.

2. b·B·a·A와 u 필드

현물 Book Ticker의 스트림 이름은 {symbol}@bookTicker입니다. 공식 설명은 해당 심볼의 최우선 bid 또는 ask 가격·수량 변경을 실시간으로 전달한다고 안내합니다. 가격이 그대로여도 수량이 바뀌면 의미 있는 갱신이 될 수 있습니다.

b는 최우선 매수 가격, B는 그 수량입니다. a는 최우선 매도 가격, A는 그 수량입니다. 대문자와 소문자가 다른 값을 의미하므로 필드를 전부 소문자로 바꾸는 변환은 피해야 합니다. s는 심볼이고 u는 order book updateId입니다.

대소문자를 보존

b와 B를 같은 키로 저장하면 가격과 수량 중 하나가 사라질 수 있습니다. a와 A도 마찬가지입니다. 내부 이름을 bestBidPrice, bestBidQty처럼 명확히 바꾸는 것은 가능하지만 원래 의미와 변환 규칙이 유지돼야 합니다.

가격과 수량은 공식 예시에서 문자열로 표현됩니다. 원본 문자열, 계산용 수치, 화면 표시값을 구분하면 소수 정밀도를 관리하기 쉽습니다. 화면에서 100.00으로 보인다고 원본 값도 그 자릿수였다고 가정하지 않습니다.

u는 체결 번호가 아님

u는 호가 업데이트 ID입니다. Trade Stream의 t나 Aggregate Trade의 a와 같은 종류의 거래 식별자가 아닙니다. u의 차이를 체결 건수나 주문 수로 환산하는 것은 공식 필드 의미를 넘어선 해석입니다.

또한 Book Ticker는 모든 깊이 변경을 보여주는 자료가 아닙니다. 최우선 호가에 관련된 정보를 받는 스트림이므로 연속 메시지의 u가 반드시 하나씩 증가해야 한다는 검증 규칙을 임의로 만들지 않습니다. Diff. Depth의 연속성 규칙을 그대로 가져오지 않는 것이 중요합니다.

3. 마지막 체결 가격과 비교

Trade Stream은 이미 체결된 거래를 알려주고 Book Ticker는 현재 관측된 최우선 호가를 알려줍니다. 최근 체결이 한동안 없더라도 대기 주문이 바뀌면서 최우선 호가는 달라질 수 있습니다. 반대로 체결이 계속 발생해도 특정 최우선 가격이 유지될 수 있습니다.

따라서 두 자료가 다르다고 어느 한쪽이 오류라고 단정하지 않습니다. 의미와 관측 시점이 다른 값입니다. 화면에는 "최근 체결가", "최우선 매수", "최우선 매도"처럼 각각의 이름을 명확히 붙이는 것이 좋습니다.

같은 시점이라고 가정하지 않기

서로 다른 스트림을 받아도 메시지가 내 프로그램에 도착하는 순서는 네트워크와 처리 경로의 영향을 받습니다. 두 메시지의 도착 순서를 거래소 내부의 모든 사건 순서라고 단정하지 않습니다. 비교에 사용한 시각과 자료 갱신 상태를 기록해야 합니다.

특히 현물 Book Ticker의 공식 payload에는 Trade Stream과 같은 E·T 필드가 제시되어 있지 않습니다. 다른 제품의 문서를 참고해 현물에 없는 필드를 있다고 설명하면 안 됩니다. 로컬 수신 시각을 기록하더라도 그것은 거래소 이벤트 시각을 대신하는 같은 값이 아닙니다.

체결 가격 차이의 의미

마지막 체결가가 best ask보다 낮다고 해서 현재 그 가격에 매수할 수 있다는 뜻은 아닙니다. 이전 체결이 다른 호가 상태에서 발생했을 수 있습니다. 현재 호가 역시 주문이 도착할 때까지 유지된다는 보장은 없으므로 과거 체결과 현재 제시 조건을 구분해야 합니다.

가격 차이를 전략 신호로 쓰려면 별도의 가정과 검증이 필요합니다. 이 글은 데이터의 의미와 비교 기준을 설명하며 특정 괴리가 수익 기회라는 결론을 제공하지 않습니다. 수수료와 실제 실행 결과도 별도 문제입니다.

4. 스프레드와 중간 가격 계산

가상의 best bid가 99, best ask가 101이라면 단순 가격 스프레드는 2입니다. 두 가격의 산술 중간값은 100입니다. 이 중간값은 분석을 위한 파생 값이며 실제로 거래 가능한 호가가 100에 존재한다는 뜻이 아닙니다.

비율 스프레드를 계산할 때는 분모를 정해야 합니다. 중간 가격을 기준으로 할지, bid 또는 ask를 기준으로 할지에 따라 값이 달라집니다. 공식 수치처럼 이름만 붙이기보다 계산 정의를 함께 표시해야 서로 다른 도구와 비교할 수 있습니다.

계산에 앞서 유효성을 확인

가격이 없거나 파싱되지 않은 값을 0으로 넣고 스프레드를 계산하면 매우 큰 비율이나 잘못된 음수가 나올 수 있습니다. 자료가 정상적으로 수신됐는지, 두 가격이 같은 심볼에서 나온 값인지 먼저 확인해야 합니다. 값이 없는 상태와 실제 0을 구분합니다.

비율 계산의 분모가 0이면 나눗셈을 수행하지 않아야 합니다. 수신 오류·자료 미준비·심볼 혼합 같은 원인을 상태로 남기고 정상 지표처럼 표시하지 않습니다. 단순 계산식보다 입력의 의미를 보존하는 과정이 먼저입니다.

중간 가격과 체결 평균의 차이

중간 가격은 두 최우선 호가에서 계산한 값이고 체결 평균은 실제 거래 가격과 수량에서 계산한 값입니다. 둘은 자료와 목적이 다릅니다. 중간 가격을 내 주문의 실제 평균 체결가로 기록하거나 수수료까지 포함한 비용이라고 표현해서는 안 됩니다.

과거 중간 가격과 실제 체결 결과를 비교하는 분석은 가능하지만 어느 시점의 호가를 기준으로 삼았는지 명시해야 합니다. 주문 결정 시점, 전송 시점, 접수 시점, 체결 시점 중 무엇을 비교하는지에 따라 해석이 달라집니다.

5. 다섯 가지 호가 변화 사례

예시 1. 가격은 같고 수량만 변경

best ask가 101로 유지되면서 A가 5에서 3으로 줄었다고 가정합니다. 가격만 비교하는 화면은 변화가 없다고 표시할 수 있지만 해당 가격대 수량은 바뀌었습니다. Book Ticker를 활용할 때 가격 변경만 저장하면 수량 정보를 놓칠 수 있습니다.

이 감소가 반드시 2만큼 체결됐다는 뜻은 아닙니다. 취소·변경·다른 주문 활동이 영향을 줄 수 있습니다. 실제 체결의 존재는 체결 자료에서 별도로 확인하고, 두 자료만으로 모든 원인을 확정하지 않습니다.

예시 2. 최우선 가격대가 이동

best ask가 101에서 102로 바뀌었다면 새 메시지의 A는 새 최우선 가격 102에 해당하는 수량으로 읽어야 합니다. 이전 101의 수량과 더해서 같은 가격대 잔량처럼 저장하면 안 됩니다. 가격과 수량을 한 쌍으로 갱신해야 합니다.

최상단이 이동한 이유를 특정 주문자의 행동으로 단정하지 않습니다. 메시지는 새로운 최우선 상태를 보여주지만 주문별 전체 내역은 제공하지 않습니다. 관측 결과와 원인 추정은 구분해서 기록하세요.

예시 3. 주문 규모가 최우선 수량보다 큼

best ask 101에 수량 1이 관측됐는데 가상의 매수 규모가 3이라면, 첫 가격대 자료만으로 전체 실행 금액을 계산할 수 없습니다. 나머지 수량에 대한 다음 가격대 정보가 필요합니다. 3×101을 확정 비용처럼 표시하면 최우선 가격이 전체 수량에 적용된다고 가정하는 오류가 됩니다.

그렇다고 최우선 수량이 3 이상이면 실제 체결을 보장할 수 있는 것도 아닙니다. 관측 이후 다른 주문이 먼저 체결되거나 취소가 발생할 수 있습니다. 공개 호가를 바탕으로 한 추정과 실제 주문 결과를 구분해야 합니다.

예시 4. 마지막 체결가와 현재 호가가 다름

최근 거래 가격은 100인데 현재 best bid 99.5, best ask 100.5라고 가정합니다. 세 값은 서로 다른 질문에 답합니다. 100은 최근 체결 결과, 99.5와 100.5는 관측된 최우선 제시 가격입니다. 이 차이 자체가 데이터 오류를 의미하지 않습니다.

차트에 하나의 가격만 표시한다면 어떤 값을 선택했는지 이름을 붙여야 합니다. 최근 체결가를 중간 가격으로 바꾸면서 기존 이름을 유지하면 사용자 해석이 달라집니다. 지표 정의 변경은 화면과 저장 규칙에 함께 반영해야 합니다.

예시 5. 여러 심볼을 한 연결에서 수신

공식 문서는 여러 {symbol}@bookTicker 스트림을 하나의 연결에서 구독할 수 있다고 안내합니다. 같은 연결에서 BTCUSDT와 다른 거래쌍을 받는다면 각 메시지의 s를 기준으로 별도 상태를 유지해야 합니다. 마지막으로 받은 bid와 ask를 전역 변수 하나에 저장하면 서로 다른 시장이 섞일 수 있습니다.

combined 포장에서도 stream 이름과 data의 심볼을 일관되게 처리합니다. 예상한 구독 대상과 실제 메시지가 맞는지 확인하고, 등록되지 않은 심볼이 들어오면 조용히 기존 상태를 덮어쓰지 않습니다. 연결 하나라는 사실과 자료 단위 하나라는 사실은 다릅니다.

6. 수량 불균형 지표를 해석할 때

최우선 매수 수량 B와 매도 수량 A를 비교해 간단한 불균형 지표를 만들 수는 있습니다. 그러나 이는 최상단 두 가격대에 대한 관측입니다. 전체 호가장의 수요·공급이나 모든 참여자의 의도를 나타낸다고 이름 붙이면 과장입니다.

예를 들어 B가 A보다 크더라도 더 깊은 매도 가격대에 큰 수량이 있을 수 있습니다. 현재 최상단 수량은 다음 순간 바뀔 수 있고 실제 거래량과도 다릅니다. 단일 관측으로 가격 방향을 보장하는 해석은 피해야 합니다.

비교 기준의 일관성

수량을 비교할 때 기초 자산 단위인지 quote 금액으로 환산한 값인지 명시합니다. 같은 심볼 안에서는 수량 비교가 가능하지만 다른 심볼 사이에서는 단위와 가격 차이를 고려해야 합니다. 단순히 숫자가 크다는 이유로 더 유동적이라고 판단하지 않습니다.

사용자가 직접 정의한 비율을 쓴다면 분모가 0인 경우와 자료가 미준비인 경우를 처리해야 합니다. 계산식과 관측 깊이를 보고서에 적으면 결과를 재현할 수 있습니다. 임의 지표를 Binance가 공식 제공하는 투자 지표처럼 설명하지 않습니다.

순간값과 기간 통계

한 번 관측한 수량과 일정 기간의 평균 수량은 다릅니다. 평균을 만들 때 이벤트 수 기준인지 시간 가중 기준인지에 따라 결과가 달라질 수 있습니다. 변경이 잦은 구간이 더 많은 메시지를 만들기 때문에 단순 메시지 평균이 시간 평균과 같다고 보장할 수 없습니다.

목적에 맞는 집계 정의를 정하고 자료 누락과 지연을 표시해야 합니다. 이런 통계 설계는 클라이언트의 선택이며 공식 Book Ticker 메시지 자체가 특정 기간 평균을 제공한다는 뜻이 아닙니다.

7. 상태 저장과 갱신 방식

Book Ticker는 대상 심볼의 최신 최우선 상태를 유지하는 데 활용할 수 있습니다. 메시지의 가격과 수량을 함께 해석해 해당 심볼 상태를 갱신합니다. 수량을 이전 값에 계속 더하는 누적 거래량 방식으로 처리하면 안 됩니다.

동시에 원본 이벤트 기록이 필요하다면 최신 상태 저장과 별도 로그를 구분할 수 있습니다. 최신 화면은 마지막 상태를 보여주고 로그는 어떤 갱신을 받았는지 추적하는 용도입니다. 두 저장소의 행 수와 의미를 같은 지표로 보고하지 않습니다.

원자적인 상태 공개

bid 가격만 새 값으로 바뀌고 bid 수량은 이전 값인 중간 상태를 다른 분석 작업이 읽으면 잘못된 조합이 됩니다. 사용하는 실행 환경에 맞춰 한 메시지의 필드를 함께 적용하는 경계를 정해야 합니다. 특정 프로그래밍 기법 하나가 모든 환경의 정답은 아니지만 소비자가 일관된 상태를 읽게 하는 목적은 같습니다.

저장한 업데이트 ID와 가격·수량이 같은 처리 결과를 가리키는지도 확인합니다. ID만 먼저 갱신하고 데이터 저장이 실패하면 이후 상태를 신뢰하기 어렵습니다. 복구 설계에서는 마지막 수신과 마지막 저장의 차이를 고려해야 합니다.

시간 정보가 없는 필드에 의미를 만들지 않기

현물 Book Ticker payload에서 공식적으로 제시하지 않은 이벤트 시각을 u로부터 계산하지 않습니다. u가 큰 숫자라고 타임스탬프 형식이라고 가정할 수 없습니다. 로컬 수신 시각을 별도 메타데이터로 남기는 것은 가능하지만 출처를 명확히 해야 합니다.

다른 시장의 Book Ticker 예시에는 추가 필드가 있을 수 있습니다. 이름이 같다는 이유로 현물과 선물의 메시지 규격을 섞지 않는 것이 중요합니다. 문서의 제품 경로와 현재 payload를 함께 확인하세요.

8. 연결 관리와 오래된 자료 표시

실시간 자료를 사용하는 화면에서는 마지막으로 데이터를 받은 상태가 얼마나 오래됐는지 알 수 있어야 합니다. 다만 메시지가 한동안 없다는 사실만으로 고장을 확정해서는 안 됩니다. 실제 최우선 상태에 변화가 없을 수도 있기 때문입니다.

연결 상태와 최근 수신 시각을 별도로 표시하면 사용자가 판단하기 쉽습니다. 연결이 끊겼는데 이전 호가를 아무 표시 없이 현재 값처럼 보여주는 것은 피해야 합니다. 오래된 자료를 숨길지, 경고와 함께 보일지 목적에 맞게 정할 수 있습니다.

재연결 뒤 상태 준비

연결이 다시 열리면 구독이 정상인지와 새 메시지가 대상 심볼에 대해 수신되는지 확인합니다. 오래된 캐시를 읽었다는 사실과 현재 자료를 받았다는 사실을 구분합니다. 새 연결이 만들어졌다는 이유만으로 기존 값의 최신성을 보장하지 않습니다.

Book Ticker만으로 끊긴 동안의 전체 호가 변화 이력을 복원할 수 있다고 가정하지 않습니다. 현재 상태 관찰과 과거 모든 변화의 기록은 다른 요구입니다. 과거 분석이 필요하다면 수집 범위와 보존 방식, 누락 구간을 별도로 관리해야 합니다.

연결 제한을 존중

공식 문서의 일반 WebSocket 연결·제어 메시지 제한과 ping·pong 규칙을 확인합니다. 메시지가 잠시 없다고 빠르게 연결을 반복 생성하는 방식은 문제를 악화시킬 수 있습니다. 재연결은 실패 원인과 제한을 고려해 설계해야 합니다.

공식 문서는 단일 연결의 수명과 서버 종료 이벤트도 안내합니다. 이런 정상적인 전환을 장애와 구분하고, 재구독과 상태 준비를 점검하는 절차를 마련합니다. 무기한 연결 유지나 자동 과거 복구를 보장하는 자료로 이해하지 않습니다.

9. 오류 진단과 작은 입력 검증

가상 메시지 두 개로 가격 고정·수량 변경을 시험해 보세요. 가격 변경과 수량 변경을 동시에 넣고 한 쌍으로 저장되는지도 확인합니다. 서로 다른 심볼을 번갈아 입력해 상태가 섞이지 않는지 검토하면 단순 정상 사례보다 많은 문제를 찾을 수 있습니다.

잘못된 수치 문자열이나 누락된 필드도 검증해야 합니다. 오류를 0으로 바꿔 정상 호가처럼 표시하지 않는지 확인하세요. 재연결 전 캐시와 재연결 후 새 상태를 구분하는 테스트도 필요합니다.

10. 최우선 호가 관찰표 만들기

Book Ticker를 처음 활용한다면 가격 네 개를 화면에 띄우는 것보다 가격 두 개와 수량 두 개라는 구조를 명확히 하는 것이 좋습니다. 아래는 가상 상태이며 실제 시장의 현재 값을 나타내지 않습니다. 동일한 심볼에서 연속으로 관찰했다고 가정합니다.

첫 상태의 단순 스프레드는 2, 중간 가격은 100입니다. 둘째 상태에서는 가격이 같으므로 두 계산은 유지되지만 최우선 매수 수량이 줄었습니다. 셋째 상태에서는 매수 가격이 올라 스프레드는 1, 중간 가격은 100.5가 됩니다. 가격 지표와 수량 상태가 서로 다른 방식으로 바뀐다는 점을 확인할 수 있습니다.

상태를 하나의 묶음으로 읽기

셋째 상태의 b=100과 첫 상태의 B=4를 섞으면 실제로 관찰하지 않은 조합을 만들게 됩니다. 따라서 한 메시지를 처리할 때 해당 상태의 필드가 함께 공개돼야 합니다. 비동기 화면이나 여러 분석기가 같은 자료를 읽는 환경에서는 이 경계가 중요합니다.

저장된 상태를 다시 읽었을 때도 가격·수량·업데이트 ID가 같은 버전인지 확인해야 합니다. 파일을 여러 조각으로 나눠 쓰거나 부분적으로 갱신하는 구현에서는 중간 실패를 고려해야 합니다. 구현 방식은 달라도 관찰하지 않은 조합을 정상 상태로 만들지 않는 원칙은 같습니다.

가격대 금액으로 바꾸어 볼 때

첫 상태의 최우선 매수 측 quote 금액을 단순히 b×B로 계산하면 396, 매도 측 a×A는 303입니다. 이것은 해당 가격대의 관측 수량에 대한 산술 값입니다. 두 값을 거래소 전체 매수·매도 자금이라고 이름 붙이지 않습니다.

둘째 상태에서는 매수 측 값이 198로 줄지만 그 차이 198을 실제 시장에서 빠져나간 자금이라고 단정할 수 없습니다. 공개 호가 상태의 변화이지 자금 이동 내역이 아닙니다. 취소와 재배치, 체결 등 원인을 확인하지 않은 상태에서 경제적 의미를 과도하게 덧붙이지 않아야 합니다.

상대편 호가를 선택하는 연습

가상의 즉시 매수 수량이 1이라면 첫 상태에서는 매도 측 101·3을 출발점으로 관찰합니다. 즉시 매도라면 매수 측 99·4를 봅니다. 이것은 방향을 이해하기 위한 정적 사례이며 실제 전송 뒤의 체결을 보장하지 않습니다.

매수 수량이 5라면 첫 매도 가격대 수량 3만으로 나머지 2의 가격을 계산할 수 없습니다. Book Ticker에는 그다음 가격대가 없기 때문입니다. 이때 결과를 "전체 비용 미확인"으로 처리할 수 있어야 자료의 한계가 유지됩니다.

스프레드 비율을 표시하는 방식

첫 상태에서 중간 가격 기준 비율을 사용하면 2÷100=2%라는 계산을 할 수 있습니다. bid 기준은 2÷99, ask 기준은 2÷101이므로 결과가 다릅니다. 어느 정의가 사용됐는지 표시하지 않으면 도구 간 비교에서 불필요한 혼동이 생깁니다.

여기서 2%는 예시 호가 간격에 대한 비율이지 거래 수수료율이 아닙니다. 실제 거래 비용에는 주문 규모와 깊이, 수수료, 시장 변화 등 다른 요소가 있을 수 있습니다. 스프레드 하나를 전체 비용으로 단순화하지 않습니다.

11. 관측 시각과 실행 평가를 나누기

주문 실행을 평가할 때 기준 호가를 선택하는 시점이 중요합니다. 사용자가 주문을 결정한 순간, 클라이언트가 요청을 만든 순간, 요청을 보낸 순간, 실제 체결이 발생한 순간은 서로 다를 수 있습니다. 어떤 기준과 비교했는지 적어야 평가가 재현됩니다.

Book Ticker의 로컬 수신 시각을 기록했다면 그것은 내 시스템이 자료를 본 시각입니다. 거래소 내부 상태의 정확한 발생 시각과 동일하다고 주장하지 않습니다. 현물 payload에 없는 시간을 만들어 정밀한 실행 지연이라고 표시해서는 안 됩니다.

오래된 상태를 기준으로 사용한 경우

마지막으로 받은 호가가 오래됐는데 그 값을 현재 실행 기준으로 사용하면 가격 차이가 크게 보일 수 있습니다. 먼저 연결 상태와 최신 수신 여부를 확인해야 합니다. 자료가 오래된 것인지 실제 시장이 급변한 것인지 구분하지 않고 실행 품질을 단정하지 않습니다.

평가 결과에는 사용한 기준 값과 그 수신 시각, 실제 체결 기록의 시각과 출처를 함께 보관할 수 있습니다. 서로 다른 시계와 단위의 차이를 고려해야 하며, 비교 가능한 범위만 해석하는 것이 중요합니다.

표시 단계의 반올림

bid와 ask를 너무 적은 자릿수로 표시하면 두 값이 같아 보일 수 있습니다. 원본 스프레드는 0이 아닌데 화면에서는 0처럼 보이는 상황입니다. 계산은 원본 정밀도로 하고 화면 자릿수 정책을 별도로 정해야 합니다.

반올림 때문에 가격대가 합쳐졌다고 원본 자료를 수정하지 않습니다. 사용자가 확대된 자릿수를 확인할 수 있도록 하거나 표시 단위를 설명할 수 있습니다. 화면의 편의와 분석 데이터의 정확성을 분리하는 것이 좋습니다.

12. FAQ

Q1. Book Ticker는 마지막 체결 가격인가요?

아닙니다. 최우선 매수·매도 가격과 수량을 보여주는 자료입니다. 마지막 체결 가격은 Trade Stream 등 체결 자료와 구분해서 읽어야 합니다.

Q2. b와 B는 같은 값인가요?

b는 최우선 매수 가격, B는 해당 수량입니다. 대소문자가 의미를 구분하므로 키를 일괄 소문자로 바꾸면 정보가 손실될 수 있습니다.

Q3. a와 A는 무엇인가요?

a는 최우선 매도 가격, A는 해당 수량입니다. 매수할 때 상대편으로 참고하는 호가지만 실제 주문 전체의 체결 가격을 보장하지 않습니다.

Q4. u는 거래 ID인가요?

호가 업데이트 ID입니다. 개별 체결 ID와 다릅니다. 차이를 거래 건수나 경과 시간으로 해석하지 않습니다.

Q5. u가 하나씩 증가해야 하나요?

Book Ticker에 Diff. Depth의 연속성 규칙을 그대로 적용해서는 안 됩니다. 최우선 호가 관련 갱신을 받는 자료라는 범위를 이해해야 합니다.

Q6. 가격이 같으면 메시지를 버려도 되나요?

수량이 달라졌을 수 있습니다. 가격뿐 아니라 해당 가격대 수량도 사용한다면 전체 필드를 확인해야 합니다. 가격 고정·수량 변화는 유효한 관측입니다.

Q7. B와 A를 전체 유동성이라고 불러도 되나요?

최우선 가격대 수량이므로 전체 깊이와 다릅니다. 더 깊은 호가를 보려면 다른 자료가 필요합니다. 지표 이름에 관측 범위를 표시하는 것이 좋습니다.

Q8. 중간 가격으로 거래할 수 있나요?

두 호가의 산술 중간값은 분석용 파생 값입니다. 그 가격에 실제 주문이 있다는 뜻이나 체결 보장은 아닙니다. 실제 주문 결과와 구분해야 합니다.

Q9. 수량이 줄면 모두 체결된 것인가요?

그렇게 단정하지 않습니다. 취소·변경 등 다른 원인이 있을 수 있습니다. 실제 거래는 체결 자료에서 확인하되 모든 변화를 일대일로 복원할 수 있다고 가정하지 않습니다.

Q10. 여러 심볼을 한 연결에서 받을 수 있나요?

공식 문서는 여러 Book Ticker 스트림을 한 연결에서 구독할 수 있다고 안내합니다. 심볼별 상태를 분리하고 현재 연결 제한을 준수해야 합니다.

Q11. 현물 메시지에 E·T가 있나요?

이 글에서 확인한 현물 공식 Book Ticker payload에는 해당 필드가 제시되지 않습니다. 다른 제품의 필드를 가져오지 말고 로컬 수신 시각은 별도 출처로 표시하세요.

Q12. 매수 수량이 크면 상승하나요?

최상단 수량만으로 미래 가격을 보장할 수 없습니다. 깊은 호가, 이후 변경, 관측 시점 등 다른 요소가 있습니다. 수량 비교는 제한된 시장 관측입니다.

Q13. 재연결하면 과거 변화를 모두 받나요?

그렇게 가정하지 않습니다. 현재 상태를 다시 관찰하는 것과 중단 구간 전체 이력을 복원하는 것은 다른 요구입니다. 누락 구간을 별도로 관리해야 합니다.

Q14. 스프레드 비율이 도구마다 다른 이유는요?

분모와 관측 시각, 자료 출처가 다를 수 있습니다. bid·ask·중간값 중 무엇을 기준으로 계산했는지 비교해야 합니다. 숫자 차이만으로 오류를 단정하지 않습니다.

Q15. 가장 먼저 검증할 항목은 무엇인가요?

시장·심볼·필드 대소문자와 가격·수량의 대응을 확인합니다. 이후 수량만 바뀌는 사례, 심볼 교차 수신, 오래된 상태, 파싱 실패를 검증하면 좋습니다.

13. 운영 체크리스트

• 현물 Book Ticker 규격을 확인했다.
• 최근 체결가와 최우선 호가를 구분한다.
• b·B·a·A 대소문자를 보존한다.
• 가격과 해당 수량을 함께 갱신한다.
• u를 거래 ID나 시간으로 바꾸지 않는다.
• 심볼별 상태를 분리한다.
• raw·combined 포장 차이를 처리한다.
• 최우선 수량을 전체 깊이라고 표시하지 않는다.
• 스프레드 비율의 분모를 명시한다.
• 중간 가격과 실제 체결가를 구분한다.
• 수량 감소 원인을 임의로 확정하지 않는다.
• 연결 상태와 최근 수신을 별도 관리한다.
• 재연결 후 새 자료 수신 여부를 확인한다.
• 관측 호가를 체결·수익 보장으로 사용하지 않는다.

핵심 정리

바이낸스 Book Ticker는 호가장의 가장 앞부분을 간결하게 관찰하는 자료입니다. 최우선 가격과 수량을 정확히 짝지어 읽고, 체결 기록·전체 깊이·현재 상태의 차이를 유지해야 실제 분석에서 혼동을 줄일 수 있습니다.

이 글은 시장 데이터 해석을 위한 정보성 자료입니다. 특정 주문의 체결이나 투자 성과를 보장하지 않습니다. 실제 이용 전 최신 Binance 공식 문서와 대상 시장의 규격을 확인하세요.