바이낸스 SBE 시장 데이터 뜻 2026｜바이너리 스트림·호가 갱신·연결 관리

바이낸스 SBE 시장 데이터 뜻 2026｜바이너리 스트림·호가 갱신·연결 관리

바이낸스 SBE 시장 데이터는 현물 거래와 호가 정보를 Simple Binary Encoding 형식으로 전달하는 스트림입니다. 사람이 읽기 쉬운 JSON과 달리 스키마에 맞춰 바이너리를 해석해야 합니다. 형식이 달라져도 시장 데이터가 체결 보장이나 미래 가격 예측으로 바뀌는 것은 아닙니다.

2026년 11월 3일 공식 SBE Market Data Streams 문서를 기준으로 연결 조건과 자료의 의미를 정리합니다. 특정 지연 시간이나 수익 개선을 보장하지 않으며 실제 API 키를 입력하는 실습은 포함하지 않습니다.

SBE와 JSON을 구분하기

JSON은 필드 이름과 값을 텍스트로 읽기 쉽습니다. SBE는 정해진 스키마와 메시지 구조에 따라 바이트를 해석합니다. 따라서 일반 JSON 파서에 시장 데이터 프레임을 그대로 넣으면 정상적으로 읽을 수 없습니다.

SBE를 선택하는 것은 데이터 표현 방식을 선택하는 일입니다. 거래쌍의 실제 유동성, 주문 우선순위, 거래 수수료를 자동으로 바꾸는 기능은 아닙니다.

SBE 시장 스트림과 REST API 응답을 SBE로 받는 기능도 구분해야 합니다. 둘 다 SBE라는 이름을 사용하지만 접속 경로와 형식 선택 방법이 다릅니다. REST의 Accept 헤더 설정을 시장 스트림 구독 방법으로 그대로 복사하지 않습니다.

연결 전 확인할 조건

공식 시장 스트림 문서는 stream-sbe.binance.com 또는 해당 호스트의 9443 포트를 안내합니다. 스트림 이름에 쓰는 symbol은 소문자입니다.

접근에는 API 키가 필요하며 현재 문서는 Ed25519 키만 허용한다고 설명합니다. 연결할 때 X-MBX-APIKEY 헤더를 사용하고 timestamp와 서명은 필요하지 않다고 안내합니다.

공개 시장 데이터 접근에 추가 키 권한은 필요하지 않으며, 키에 IP 허용 목록이 설정되어 있다면 그 주소 조건은 적용됩니다. 시장 데이터를 읽기 위해 불필요한 거래·출금 권한을 추가하는 방식으로 접근하지 않습니다.

키를 URL이나 공개 로그에 붙이지 않습니다. 연결 오류를 진단할 때는 민감값을 제거한 호스트·키 유형·오류 정보와 현재 공식 조건을 대조합니다.

하나의 연결에서 두 종류의 프레임

구독 요청과 응답은 JSON 텍스트 프레임이고 시장 데이터는 SBE 바이너리 프레임입니다. 서버 종료를 알리는 serverShutdown 이벤트도 JSON으로 안내됩니다.

따라서 모든 메시지를 바이너리 디코더 하나로 처리하거나, 모든 메시지를 JSON으로 처리하면 일부 메시지를 놓칠 수 있습니다. 프레임 종류를 먼저 구분하고 각 처리 경로로 전달해야 합니다.

제어 응답을 받았다는 사실과 실제 시장 이벤트를 정상 해석했다는 사실도 다릅니다. 연결 성공, 구독 성공, 디코딩 성공, 자료 갱신을 단계별로 확인합니다.

제공되는 시장 스트림

체결 스트림

trade 스트림은 원시 거래 정보를 실시간으로 전달하며 메시지 이름은 TradesStreamEvent입니다. 실제 시장에서 발생한 거래 자료이지 특정 사용자의 주문 체결 확인 자료는 아닙니다.

공개 거래가 발생했다고 본인의 주문이 체결됐다고 연결하면 안 됩니다. 개인 주문 결과는 별도 계정 자료에서 확인해야 합니다.

최우선 매수·매도 스트림

bestBidAsk는 최우선 매수·매도 가격과 수량을 전달합니다. 공식 문서는 JSON의 bookTicker와 대응하지만 eventTime과 auto-culling 차이가 있다고 설명합니다.

최우선 호가만으로 전체 주문장 깊이를 알 수는 없습니다. 큰 수량의 실행 가능성을 판단하려면 필요한 범위의 주문장 자료를 별도로 검토해야 합니다.

Diff Depth

depth 스트림은 주문장 증분 갱신을 전달하며 작성일 문서는 20ms 갱신 주기를 안내합니다. 이는 사용자에게 도착하는 종단 지연을 보장하는 숫자가 아닙니다.

로컬 주문장을 유지하려면 공식 스냅샷과 업데이트 연결 절차를 따라야 합니다. 메시지를 받는 것만으로 로컬 주문장이 정확해지는 것은 아닙니다.

Partial Book Depth

depth20은 상위 20개 가격 수준의 스냅샷을 제공하며 작성일 문서는 50ms 갱신을 안내합니다. 전체 주문장의 모든 가격 수준을 뜻하지 않습니다.

부분 스냅샷과 증분 업데이트를 같은 방식으로 누적하면 잘못된 주문장을 만들 수 있습니다. 자료가 현재 상태 전체인지 변화분인지 먼저 구분합니다.

Auto-culling의 의미

최우선 호가 스트림은 부하가 높을 때 오래된 대기 이벤트를 버리고 최신 이벤트를 전달할 수 있다고 설명합니다. 같은 symbol에서 T1 이벤트가 대기 중인데 T2가 생기면 T1 대신 T2를 전달하는 예시가 제시됩니다.

이는 최신 상태 전달을 위한 동작이며 모든 중간 변화가 보존된 이력이라는 뜻이 아닙니다. 받은 이벤트만으로 모든 순간의 호가 변화를 완전히 복원했다고 주장하면 안 됩니다.

이 특성을 다른 스트림 전체에 임의로 확대하지 않습니다. 어떤 스트림에 어떤 동작이 문서화되어 있는지 구분해야 합니다.

시간 단위와 스키마

공식 문서는 시간과 timestamp 필드가 마이크로초 단위라고 안내합니다. 밀리초를 기대하는 기존 프로그램에 그대로 넣으면 시간 표시와 지연 계산이 크게 틀어질 수 있습니다.

단위를 명시적으로 변환하고 원본값도 보존합니다. 서버 이벤트 시각과 로컬 수신 시각은 다른 값이므로 단순 차이를 계산하기 전에 시계 동기화와 단위를 확인해야 합니다.

스키마는 공식 시장 스트림 문서가 연결하는 자료를 사용합니다. REST용 스키마나 과거 예제의 버전을 현재 시장 스트림에 무조건 적용하지 않습니다.

가격과 수량의 표현도 스키마에 따라 해석해야 합니다. 바이트를 숫자로 읽었다는 사실만으로 소수점 위치와 단위가 맞는 것은 아닙니다.

연결 유지와 재연결

공식 문서는 단일 연결이 24시간 동안 유효하므로 그 시점의 연결 종료를 예상하라고 안내합니다. 서버 종료 예고 이벤트를 받았을 때도 새 연결을 준비해야 합니다.

서버는 20초마다 ping 프레임을 보내며 1분 안에 pong이 돌아오지 않으면 연결을 닫는다고 설명합니다. 응답 pong에는 받은 ping의 페이로드를 복사하도록 안내됩니다.

아무 내용의 pong을 임의로 자주 보내면 연결이 계속 유지된다고 생각하면 안 됩니다. 실제 ping에 맞춰 응답하고 문서의 제어 메시지 제한도 지켜야 합니다.

현재 문서는 클라이언트 메시지 초당 5개, 단일 연결 최대 1024개 스트림, IP당 5분 동안 300회 연결 시도 제한을 안내합니다. 제한은 변경될 수 있으므로 구현 전 다시 확인합니다.

가상 사례 1: 바이너리를 JSON으로 처리

연결과 구독 응답은 정상인데 시장 이벤트에서 파싱 오류가 발생했다고 가정합니다. 모든 메시지를 JSON 파서로 처리했는지 확인합니다.

텍스트 제어 프레임과 바이너리 시장 프레임을 나누면 원인을 좁힐 수 있습니다. 오류를 빈 데이터로 바꿔 표시하면 실제로 자료가 없는 것처럼 오해할 수 있습니다.

가상 사례 2: 시간 단위 착오

마이크로초 값을 밀리초로 해석해 비정상적인 날짜가 표시됐다고 가정합니다. 서버가 잘못된 시간을 보낸다고 단정하기 전에 단위 변환을 확인합니다.

변환 후에도 지연이 이상하면 서버 이벤트 시간과 로컬 수신 시간의 의미, 시스템 시계 상태를 대조합니다. 숫자를 임의로 잘라 맞추는 방식은 피합니다.

가상 사례 3: 중간 호가 누락

최우선 호가 이력에서 중간 상태가 보이지 않는다고 가정합니다. auto-culling이 문서화된 스트림인지 확인하고 모든 중간 이벤트 보존을 전제로 분석하지 않습니다.

관측된 최신 상태와 완전한 역사 기록은 다른 목적의 자료입니다. 누락 가능성이 있는 자료로 틱 단위 전체 경로를 확정해서는 안 됩니다.

가상 사례 4: 재연결 후 주문장 불일치

연결이 끊긴 뒤 새 이벤트만 기존 로컬 주문장에 붙여서 가격 수준이 맞지 않는 상황입니다. 연결 공백의 업데이트를 놓쳤을 수 있습니다.

공식 로컬 주문장 동기화 절차에 따라 상태를 복구해야 합니다. 연결이 다시 열렸다는 사실만으로 데이터 연속성이 복원됐다고 판단하지 않습니다.

가상 사례 5: 상위 20단계를 전체 유동성으로 사용

depth20 자료만 보고 시장 전체 주문 수량을 계산했다고 가정합니다. 상위 20개 가격 수준 밖의 주문은 그 자료에서 확인되지 않습니다.

보고서에는 관측 범위를 명시하고 전체 시장 깊이로 과장하지 않습니다. 데이터 범위와 분석 결론의 범위를 맞추는 것이 중요합니다.

도입 전 점검 순서

먼저 필요한 자료가 개별 체결인지 최우선 호가인지 전체 로컬 주문장 유지인지 정합니다. 목적에 따라 스트림과 복구 방법이 달라집니다.

다음으로 공식 스키마에 맞는 디코딩을 준비하고 알려진 자료로 가격·수량·시간 단위를 확인합니다. 잘못 읽은 숫자가 정상 범위처럼 보일 수도 있으므로 단순 파싱 성공만으로 검증을 끝내지 않습니다.

이후 제어 프레임, 구독 결과, 시장 이벤트, 연결 종료를 각각 처리합니다. 재연결 후에는 구독 복원과 데이터 동기화까지 확인해야 합니다.

마지막으로 자료의 한계를 사용자 화면에 반영합니다. 최우선 호가, 부분 깊이, 증분 주문장, 개인 주문 결과를 같은 이름으로 표시하지 않습니다.

실무 설계: 수신과 해석을 나눠 보기

SBE를 처음 적용할 때 가장 먼저 할 일은 빠르다는 표현을 붙이는 것이 아니라 수신 경로를 분리하는 것입니다. 연결 관리, 제어 메시지, 바이너리 해석, 정규화된 시장 자료, 화면 표시를 각각 구분하면 어디에서 오류가 생겼는지 찾기 쉽습니다.

네트워크에서 바이트가 도착했다는 사실은 디코딩 성공을 뜻하지 않습니다. 디코딩이 성공했다는 사실도 가격과 수량의 단위가 정확하다는 뜻은 아닙니다. 단위가 맞더라도 자료가 오래되거나 동기화가 끊겼다면 현재 시장 상태로 사용할 수 없습니다.

이 과정을 한 번의 성공 표시로 뭉치지 않는 것이 중요합니다. 운영 화면에는 연결 상태와 마지막 정상 자료 수신 시각, 디코딩 오류 여부, 주문장 동기화 상태를 별도로 보여줄 수 있습니다. 이는 특정 거래소가 제공하는 UI가 아니라 소비 프로그램을 설계할 때 고려할 구조입니다.

원본 자료와 해석 결과

문제를 재현하려면 원본 프레임과 해석 결과의 연결이 필요합니다. 다만 모든 자료를 무제한 저장하면 용량과 운영 부담이 커집니다. 필요한 진단 범위를 정하고 API 키 같은 인증값은 원본 기록과 분리해야 합니다.

바이너리 원본을 보존하는 경우 어떤 스키마와 디코더 버전으로 읽었는지 기록하면 좋습니다. 나중에 값이 잘못 해석된 사실을 알게 됐을 때 같은 바이트를 다시 확인할 수 있기 때문입니다.

해석 결과만 저장하면 디코더 오류가 원본 시장 오류처럼 보일 수 있습니다. 반대로 원본만 저장하면 문제 발생 당시 어떤 화면과 계산에 쓰였는지 알기 어렵습니다. 두 자료의 목적을 나누고 연결 식별자를 유지하는 방식이 유용합니다.

정규화 계층의 역할

JSON과 SBE를 함께 사용하는 프로그램은 각 전송 방식의 필드를 공통 내부 구조로 바꿀 수 있습니다. 이때 이름이 비슷한 값을 무조건 같은 항목으로 합치면 안 됩니다.

예를 들어 최우선 호가 자료와 상위 20단계 자료는 포함 범위가 다릅니다. 둘 다 “호가”라는 이름으로 저장하더라도 범위와 출처를 명시해야 분석 과정에서 구분할 수 있습니다.

시간 단위도 정규화할 수 있지만 원본 단위와 변환 방법을 보존해야 합니다. 모든 값을 내부 밀리초로 바꾸면 마이크로초 정밀도를 잃을 수 있으므로 시스템 목적에 맞는 저장 정밀도를 결정합니다.

자료의 신선도를 평가하는 방법

시장 데이터에서는 최신이라는 말의 기준을 정해야 합니다. 마지막 메시지를 받은 시각, 메시지 안의 이벤트 시각, 화면을 그린 시각은 서로 다릅니다.

연결은 열려 있는데 특정 symbol의 자료가 갱신되지 않을 수도 있습니다. 시장 변화가 없어서인지 구독이 누락됐는지 디코더가 오류를 내고 있는지 단순 연결 상태만으로는 알 수 없습니다.

따라서 “연결됨” 표시와 “자료 정상” 표시를 분리하는 것이 좋습니다. 어떤 조건에서 오래된 자료로 분류할지는 실제 서비스 목적과 스트림 특성을 고려해 정해야 하며, 문서에 없는 시간을 Binance의 보장값처럼 제시하면 안 됩니다.

수신 시각만으로 계산한 지연

로컬 수신 시각에서 이벤트 시각을 빼면 지연과 비슷한 숫자가 나올 수 있습니다. 그러나 두 시계가 동기화되어 있는지, 시간 단위가 맞는지, 이벤트 시각이 무엇을 의미하는지 먼저 확인해야 합니다.

음수 지연이 보인다고 서버가 미래 데이터를 보낸다고 결론내릴 수 없습니다. 시계 오차나 변환 오류일 수 있습니다. 큰 지연도 네트워크뿐 아니라 로컬 큐의 적체 때문에 발생할 수 있습니다.

측정값에는 관측 지점과 계산 기준을 붙입니다. “수신 지연”과 “화면 표시 지연”을 같은 성능 숫자로 광고하면 실제 운영 상태를 오해하게 됩니다.

오래된 자료의 사용 중단

데이터가 오래되거나 동기화가 의심되면 이를 사용자에게 정상 시세처럼 계속 보여주지 않는 정책이 필요합니다. 오래된 값을 유지하더라도 마지막 확인 시각과 상태를 표시해야 합니다.

자동 분석에 쓰는 경우에는 불완전한 자료를 정상 신호로 변환하지 않도록 해야 합니다. 재연결 직후 첫 메시지 하나를 받았다는 이유만으로 모든 종목과 모든 가격 수준이 복구됐다고 판단하지 않습니다.

사용 중단 기준과 복구 기준을 문서화하면 운영자가 같은 상황에 다른 판단을 내리는 일을 줄일 수 있습니다. 이 기준은 프로그램의 책임 범위이며 거래소의 공식 보장과 구분해야 합니다.

주문장 동기화가 별도 작업인 이유

증분 메시지는 이전 상태에 변화를 적용하는 자료입니다. 이전 상태가 잘못됐거나 중간 변화가 빠졌다면 이후 메시지를 정확히 읽어도 결과 주문장이 틀릴 수 있습니다.

스냅샷은 특정 시점의 상태를 제공하지만 스트림과 연결되는 경계를 맞춰야 합니다. 스냅샷을 가져오는 동안에도 시장은 움직이므로 단순히 스냅샷 뒤에 도착한 모든 메시지를 붙이면 된다고 가정해서는 안 됩니다.

공식 로컬 주문장 절차에서 설명하는 업데이트 식별자와 연결 조건을 따라야 합니다. 이 글에서는 다른 전송 형식의 필드명을 SBE에 임의로 붙이지 않으며, 실제 스키마의 필드와 공식 연결 문서를 함께 확인하도록 권합니다.

복구 전에 기존 상태를 신뢰하지 않기

연결 공백이 생겼다면 기존 주문장을 마지막 정상 상태로 보관할 수는 있지만 현재 상태로 확정해서는 안 됩니다. 별도의 동기화 중 표시가 필요할 수 있습니다.

복구 과정에서 이전 연결과 새 연결의 이벤트가 겹칠 수 있습니다. 중복과 순서를 다루는 절차 없이 모두 적용하면 수량이 두 번 바뀌거나 과거 상태로 돌아갈 수 있습니다.

반대로 겹치는 자료를 전부 버리면 필요한 경계 업데이트까지 놓칠 수 있습니다. 공식 식별자 규칙을 기준으로 연결하고, 자신이 임의로 정한 도착 순서를 시장 처리 순서로 간주하지 않습니다.

부분 스냅샷의 범위

상위 20단계는 그 범위 안의 상태를 읽는 자료입니다. 범위 밖 가격 수준이 현재 없는지, 단지 제공되지 않았는지 구분해야 합니다.

표에 없는 가격을 모두 수량 0으로 해석하면 전체 주문장이 왜곡될 수 있습니다. 부분 자료를 전체 자료로 확장하는 과정에서 생기는 전형적인 오류입니다.

분석 결과에는 “관측된 상위 범위”라는 범위를 붙입니다. 전체 유동성, 전체 매수 대기금, 전체 매도 대기량 같은 표현을 쓰려면 그 결론을 뒷받침하는 자료 범위가 필요합니다.

Best Bid/Ask와 Depth를 함께 볼 때

최우선 호가는 간단한 스프레드 화면에 유용할 수 있습니다. 깊이 자료는 여러 가격 수준의 수량을 살피는 데 쓰입니다. 두 스트림은 목적과 갱신 방식이 다르므로 같은 순간의 값이라고 무조건 가정하지 않습니다.

각각의 자료 수신 시각과 의미를 기록하면 불일치가 생겼을 때 원인을 좁힐 수 있습니다. 한쪽은 더 최신이고 다른 쪽은 아직 갱신 전일 수 있습니다.

이 불일치를 임의 평균으로 덮으면 실제로 존재하지 않은 호가를 만들 수 있습니다. 어느 자료를 어떤 화면이나 계산에 사용할지 명확한 기준이 필요합니다.

스프레드 계산의 단위

최우선 매도 가격과 매수 가격의 차이는 가격 단위의 스프레드입니다. 비율로 표시하려면 분모를 무엇으로 정했는지 명시해야 합니다.

공식 스트림이 제공하는 값과 내부 계산한 지표는 구분해 저장합니다. 계산식이 서비스마다 다르면 같은 “스프레드율”이라는 이름으로도 값이 달라질 수 있습니다.

스프레드가 좁다는 사실만으로 큰 주문의 비용이 작다고 보장할 수 없습니다. 최우선 수량과 더 깊은 수준의 주문장, 실제 실행 시점이 영향을 주기 때문입니다.

체결 데이터와 호가 데이터

공개 체결은 이미 일어난 거래이고 호가는 대기 중인 주문 상태입니다. 체결 가격이 최우선 호가와 다르게 보일 때는 자료 시각과 범위를 먼저 확인합니다.

한 메시지의 도착 순서를 실제 사건 순서와 동일하다고 생각하면 분석이 틀릴 수 있습니다. 서로 다른 스트림을 합칠 때는 이벤트 시각의 의미와 전송 특성을 고려해야 합니다.

관측 자료만으로 개별 참가자의 의도나 주문 전략을 확정할 수도 없습니다. 호가 변화와 체결 기록은 시장 상태를 보여주지만 비공개 판단 과정까지 알려주지는 않습니다.

스키마 변경에 대비하기

디코더는 스키마에 의존합니다. 따라서 적용한 스키마 파일과 생성 도구, 디코더 버전을 관리해야 합니다. “SBE 지원”이라는 이름만으로 모든 메시지 버전을 처리할 수 있다고 가정하지 않습니다.

공식 문서와 변경 기록을 확인하고 새 메시지나 필드가 추가됐을 때 프로그램이 어떻게 반응하는지 검토합니다. 모르는 메시지를 정상 자료로 잘못 해석하는 것보다 명확히 구분해 기록하는 것이 낫습니다.

스키마를 바꾸는 작업과 운영 배포를 한 번에 수행하면 문제가 생겼을 때 원인을 찾기 어려울 수 있습니다. 별도 검증 환경에서 대표 메시지와 경계 상황을 확인한 뒤 적용하는 절차가 도움이 됩니다.

파싱 성공과 의미 검증

바이트 배열에서 숫자를 읽는 데 성공했어도 가격의 지수나 수량 단위가 틀리면 결과는 잘못됩니다. 정수 부호, 크기, 반복 그룹 길이 등도 해당 스키마에 맞게 해석되어야 합니다.

검증에서는 정상적인 값뿐 아니라 빈 배열, 다양한 자릿수, 여러 symbol과 메시지 종류를 확인합니다. 한 종목 한 메시지가 정상이라고 전체 지원을 확정하지 않습니다.

시장 자료와 디코더 결과를 비교할 때도 시점 차이를 고려합니다. 다른 경로에서 받은 값이 조금 다르다고 곧바로 디코더 오류라고 판단하지 않고 자료의 이벤트 시각과 범위를 대조합니다.

부하와 큐 관리

시장 이벤트를 받는 속도보다 처리하는 속도가 느리면 로컬 큐가 늘어날 수 있습니다. 연결이 정상이어도 화면과 계산은 오래된 자료를 처리하게 됩니다.

이때 문제를 네트워크 지연으로만 분류하면 실제 원인을 놓칩니다. 디코딩, 저장, 분석, 화면 렌더링 중 어느 단계에서 시간이 쌓이는지 구분해야 합니다.

큐를 무조건 크게 만드는 방식은 자료 손실을 늦출 수 있어도 오래된 자료를 더 오래 처리하는 결과를 낳을 수 있습니다. 목적에 맞는 처리와 복구 정책이 필요합니다.

임의 삭제의 위험

최우선 상태 화면과 완전한 이력 기록은 자료 손실에 대한 요구가 다릅니다. 어떤 화면은 최신값이 중요하지만, 어떤 분석은 사건의 연속성이 중요합니다.

클라이언트가 임의로 메시지를 버릴 경우 그 사실과 영향을 기록해야 합니다. 특히 증분 주문장에서는 중간 이벤트 누락이 상태를 깨뜨릴 수 있으므로 단순히 최신 메시지만 남기는 정책을 적용하면 안 됩니다.

서버의 문서화된 auto-culling과 클라이언트의 임의 드롭은 별개의 동작입니다. 둘을 같은 이름으로 묶으면 누락 원인을 추적하기 어려워집니다.

운영 장애를 분류하는 표

이 표는 원인을 확정하는 표가 아니라 확인 순서를 정하는 도구입니다. 실제 오류 응답과 로그를 근거로 다음 단계를 선택해야 합니다.

오류를 재현할 때는 인증값을 제거하고 메시지 종류, 스키마 버전, 발생 시각과 처리 단계처럼 필요한 정보만 공유합니다. 원본 API 키를 보여줄 필요는 없습니다.

도입 여부를 결정하는 질문

현재 서비스가 원하는 것은 사람이 보는 간단한 시세 화면인지, 많은 종목을 처리하는 분석 파이프라인인지, 정밀한 로컬 주문장인지 먼저 정해야 합니다.

SBE를 사용하면 스키마 관리와 바이너리 진단 능력이 필요합니다. 기존 JSON 구조가 목적을 충분히 충족한다면 형식 변경 자체를 성과로 볼 필요는 없습니다.

반대로 자료량과 처리 구조 때문에 SBE를 검토한다면 실제 측정 기준을 정합니다. CPU 사용량, 처리 지연, 오류 복구 시간, 데이터 정합성을 함께 봐야 합니다. 특정 형식의 이름만으로 전체 성능을 평가하지 않습니다.

비교 측정 시 같은 조건 맞추기

서로 다른 종목 수와 다른 저장 방식으로 측정한 결과는 형식 차이만을 보여주지 않습니다. 구독 범위, 네트워크 환경, 처리 단계와 시각 기준을 가능한 한 맞춰야 합니다.

측정 결과에는 평균뿐 아니라 긴 지연 구간과 복구 상황도 포함할 수 있습니다. 평상시에는 빠르지만 연결 종료 뒤 복구하지 못하는 시스템은 실무에서 신뢰하기 어렵습니다.

이 글은 실제 성능을 측정한 결과를 제공하지 않습니다. 따라서 몇 배 빠르다거나 특정 수익 개선이 있다는 숫자를 제시하지 않습니다. 사용 환경에서 검증한 자료만 해당 환경의 결과로 설명해야 합니다.

실무 인수 점검표

운영에 넘기기 전에는 정상 구독뿐 아니라 오류와 복구의 결과도 확인합니다. 잘못된 스키마, 끊어진 연결, 느린 처리, 오래된 자료가 각각 어떤 상태로 나타나는지 확인할 수 있어야 합니다.

운영자는 마지막 정상 자료 시각과 현재 동기화 상태를 읽을 수 있어야 합니다. 단순한 녹색 연결 표시만으로 모든 자료가 정확하다고 판단하게 만들지 않습니다.

또한 어떤 자료가 저장되고 어떤 자료가 생략되는지 문서화합니다. auto-culling이 있는 스트림으로 만든 이력을 나중에 완전한 감사 기록으로 오해하지 않도록 목적과 한계를 남깁니다.

담당자가 바뀌어도 같은 방식으로 진단할 수 있도록 스키마 경로, 공식 문서, 설정의 의미, 재연결과 동기화 절차를 연결합니다. 실제 비밀값 대신 비밀값을 관리하는 위치와 권한 원칙을 설명하면 됩니다.

FAQ

Q1. SBE를 쓰면 거래가 더 유리해지나요?

데이터 표현 방식만으로 체결 우선순위나 수익을 보장할 수 없습니다.

Q2. 일반 JSON 파서로 읽을 수 있나요?

시장 바이너리 이벤트는 공식 스키마에 맞는 디코딩이 필요합니다.

Q3. 제어 메시지도 모두 바이너리인가요?

구독 제어와 응답, 서버 종료 이벤트는 JSON 텍스트 프레임으로 안내됩니다.

Q4. API 키가 필요한가요?

현재 공식 시장 스트림 문서는 키가 필요하며 Ed25519만 허용한다고 안내합니다.

Q5. 거래 권한을 추가해야 하나요?

공개 시장 데이터에 추가 키 권한은 필요하지 않다고 설명합니다. 불필요한 권한 확대를 하지 않습니다.

Q6. 시간 단위는 무엇인가요?

공식 문서는 마이크로초로 안내합니다. 밀리초 기반 시스템과 연결할 때 변환이 필요합니다.

Q7. bestBidAsk는 모든 호가를 주나요?

최우선 매수·매도 정보입니다. 전체 주문장 깊이가 아닙니다.

Q8. 모든 중간 호가 변화가 보존되나요?

bestBidAsk에는 부하 상황에서 오래된 이벤트를 생략하는 auto-culling이 설명되어 있습니다.

Q9. depth20은 전체 주문장인가요?

상위 20개 가격 수준의 부분 스냅샷입니다.

Q10. 20ms는 네트워크 도착 보장인가요?

공식 갱신 주기와 실제 종단 지연은 다른 개념입니다.

Q11. 연결이 계속 유지되나요?

현재 문서는 단일 연결의 24시간 유효기간과 재연결 필요성을 안내합니다.

Q12. 연결만 복구하면 주문장도 복구되나요?

자료 공백이 있었다면 공식 동기화 절차가 필요합니다.

Q13. 공개 체결로 내 주문 체결을 알 수 있나요?

본인 주문 결과는 개인 계정 자료에서 확인해야 합니다.

Q14. REST SBE 설정과 같은가요?

같은 인코딩 이름을 쓰지만 전송 경로와 설정 방식이 다릅니다.

Q15. 무엇부터 검증해야 하나요?

목적에 맞는 스트림, 스키마, 단위, 프레임 분기, 재연결과 동기화입니다.

체크리스트

• 공식 시장 스트림 문서를 기준으로 연결하는가.
• 키 유형과 IP 조건을 확인했는가.
• 불필요한 권한을 추가하지 않았는가.
• 텍스트와 바이너리 프레임을 분리하는가.
• 공식 스키마와 메시지 유형을 확인하는가.
• 시간·가격·수량 단위를 검증하는가.
• 부분 깊이와 전체 주문장을 구분하는가.
• auto-culling의 분석 한계를 반영하는가.
• ping·pong과 제어 메시지 제한을 지키는가.
• 24시간 연결 종료와 서버 종료 이벤트에 대응하는가.
• 재연결 후 구독과 자료 동기화를 확인하는가.
• 개인 주문 기록과 공개 시장 자료를 분리하는가.

핵심 정리

바이낸스 SBE 시장 데이터는 자료의 전달과 해석 방식을 이해하는 주제입니다. 빠른 데이터라는 인상보다 어떤 범위의 자료를 어떤 단위와 연속성으로 받는지 확인하는 것이 먼저입니다.

공식 참고 자료

• Binance SBE Market Data Streams
• Binance SBE FAQ
• Binance Spot WebSocket Streams

이 글은 기술 정보이며 투자 권유가 아닙니다. 연결 조건·스키마·제한은 변경될 수 있으므로 실제 적용 전 최신 공식 문서를 확인하세요.