바이낸스 Reference Price 뜻 2026｜기준 가격·null·엔진 시각·다른 가격과 비교

바이낸스 Reference Price 뜻 2026｜기준 가격·null·엔진 시각·다른 가격과 비교

바이낸스 Reference Price는 현물 공식 데이터 문서에 별도 스트림으로 정의된 기준 가격 자료입니다. 마지막 체결 가격, 호가 중간값, 개인 매수 단가를 임의로 대신 넣어도 되는 값이 아닙니다. 공식 응답에서 기준 가격이 없으면 r이 null일 수 있다는 점과, t가 기준 가격이 유효했던 엔진 시각이라는 점을 먼저 이해해야 합니다.

이 글은 2026년 10월 30일 Binance Spot WebSocket 공식 문서의 Reference Price Streams를 확인해 작성했습니다. 공식 항목은 스트림 이름, 갱신 속도와 필드 의미를 제시합니다. 공개되지 않은 세부 산식, 구성 시장, 계정별 적용 여부를 추측으로 채우지 않고, 확인할 수 있는 데이터의 읽기와 검증 방법을 설명합니다.

먼저 확인할 네 가지

payload에는 e와 s도 포함됩니다. e는 referencePrice 이벤트 유형, s는 심볼입니다. 이 짧은 구조를 보고 다른 가격 데이터의 필드나 계산식을 자동으로 가져오지 않습니다. 특히 일반 Ticker의 통계 시간이나 Average Price의 구간 필드가 동일하게 존재한다고 가정하지 않습니다.

1. 기준 가격이라는 말부터 구분하기

일반적인 대화에서는 비교를 위해 선택한 가격을 모두 기준 가격이라고 부르기도 합니다. 내가 어제 종가를 기준으로 수익률을 계산할 수도 있고, 주문 직전 중간 호가를 실행 성과의 기준으로 정할 수도 있습니다. 그러나 공식 스트림의 Reference Price는 그렇게 임의로 정한 개인 분석 기준과 구분해야 합니다.

같은 단어를 쓰더라도 출처가 다르면 의미가 다릅니다. 공식 데이터 필드 r을 표시할 때는 그 출처를 유지하고, 자체 계산한 기준값이라면 자체 계산임을 밝힙니다. 임의의 중간값을 r 대신 넣고 공식 기준 가격이라고 표시하면 실제 자료의 부재가 숨겨집니다.

이 구분은 주문 규칙을 해석할 때도 중요합니다. 어떤 기능이 reference price라는 표현을 사용한다면 그 기능의 문서에서 정확히 무엇을 참조하는지 확인해야 합니다. 이름이 같다는 이유만으로 모든 주문 규칙이 이 스트림의 값을 그대로 사용한다고 단정할 수 없습니다.

이 글이 다루는 범위

여기서는 현물 Reference Price 스트림의 응답을 읽고, 가격이 없을 때의 상태를 관리하며, 다른 가격 자료와 비교하는 방법을 다룹니다. 특정 계정에서 주문을 넣는 UI 절차나 레버리지 상품의 청산 계산을 설명하는 글이 아닙니다. 확인하지 않은 화면 버튼과 제한 수치를 만들어 넣지 않습니다.

공식 설명이 짧다는 이유로 기능을 과장할 필요도 없습니다. “기준 가격이 존재하는지”, “어느 심볼의 값인지”, “언제 유효했는지”를 정확히 확인하는 것만으로도 데이터 처리에서 중요한 오류를 줄일 수 있습니다. 알 수 없는 부분은 추가 근거가 필요한 질문으로 남기는 것이 정확한 사용법의 일부입니다.

2. 필드별 의미

공식 예시의 r은 가격 문자열로 표시되거나 기준 가격이 없으면 null이 될 수 있습니다. 숫자 문자열을 처리할 때와 null을 처리할 때는 분기해야 합니다. 모든 값을 숫자로 강제 변환한 뒤 실패하면 0으로 넣는 방식은 데이터 의미를 훼손할 수 있습니다.

t는 소문자입니다. 다른 Trade 메시지에서 소문자 t가 거래 ID라는 사실을 기억하고 있더라도 여기서는 그 의미를 적용하지 않습니다. 필드 이름의 의미는 메시지 유형 안에서 결정됩니다. 같은 한 글자 이름을 모든 데이터에 공통으로 해석하지 않습니다.

심볼과 단위

가격은 해당 거래쌍의 기준 자산 단위로 해석해야 합니다. 공식 예시의 심볼과 숫자는 응답 구조 설명용이며 현재 지원 심볼 목록을 대신하지 않습니다. 예시에 나온 이름을 보고 동일한 시장이 내 계정에서 거래 가능하다고 단정하지 않습니다.

실제 분석에서는 공식 심볼 정보로 기초 자산과 기준 자산을 확인하고 자료에 함께 기록합니다. 다른 기준 자산 가격을 비교하려면 환산 기준과 시각을 명시해야 합니다. 환산한 결과를 원래의 공식 r 값과 같은 필드에 덮어쓰지 않고 별도 계산값으로 보관합니다.

3. null은 왜 중요한가

null은 기준 가격이 없다는 상태를 전달할 수 있습니다. 가격 0과 다릅니다. 0을 실제 가격으로 넣으면 차이율 계산에서 0으로 나누는 오류가 나거나, 가격이 폭락한 것처럼 경고가 뜨거나, 잘못된 그래프가 그려질 수 있습니다.

기준 가격이 없을 때 마지막으로 알던 값을 계속 보여 줄 수도 있지만, 그 경우에는 “이전 값”이라는 상태와 마지막 유효 시각을 명확히 표시해야 합니다. 현재 유효한 기준 가격처럼 보이게 해서는 안 됩니다. 이전 값 보존과 현재 값 존재 여부를 별도 열로 관리하는 방법이 좋습니다.

또 다른 실수는 null이 나오면 자동으로 Last Price나 평균 가격을 대신 쓰는 것입니다. 이는 사용자가 선택한 대체 정책일 수는 있어도 공식 Reference Price가 복구됐다는 뜻은 아닙니다. 대체값을 사용하는 이유와 출처를 별도로 표시하고, 그 정책이 주문이나 위험 계산에 어떤 영향을 주는지 검토해야 합니다.

표시 상태를 나누는 예

자체 화면에서는 “유효 값 수신”, “기준 가격 없음”, “연결 끊김”, “아직 수신 전”, “파싱 오류”를 구분할 수 있습니다. 이 다섯 상태는 모두 숫자가 보이지 않는 결과를 만들 수 있지만 원인과 대응이 다릅니다. 단순히 빈칸 하나로 처리하면 사용자는 무엇을 해야 하는지 알기 어렵습니다.

이 상태 이름들은 설명을 위한 자체 설계 예시입니다. 바이낸스 앱의 공식 상태 명칭이라고 주장하는 것이 아닙니다. 실제 서비스의 UI가 무엇을 표시하는지는 직접 확인해야 하며, 데이터 문서만으로 화면 동작까지 단정하지 않습니다.

4. t를 시간으로 읽기

공식 문서는 t를 기준 가격이 유효했던 엔진 타임스탬프로 설명합니다. 내 프로그램이 메시지를 받은 시각과 다르며, 마지막 체결 시간이라고 설명되어 있지도 않습니다. 거래 메시지의 T나 다른 이벤트의 E를 가져와 같은 뜻으로 번역하지 않습니다.

일반 WebSocket 문서의 기본 시간 단위와 연결 옵션을 확인한 뒤 날짜로 변환합니다. 밀리초를 초로 오해하거나 마이크로초 옵션을 사용하고도 밀리초로 처리하면 날짜가 크게 어긋납니다. 시간대 표시를 한국시간으로 바꿀 때는 원본 순간은 그대로 두고 표시만 변환합니다.

수신 시각과 t의 차이를 관찰하는 것은 가능하지만, 이를 전부 네트워크 지연이라고 단정하지 않습니다. 유효 시각의 의미와 실제 이벤트 전달 시점은 같지 않을 수 있고, 로컬 시계 오차도 영향을 줍니다. 측정 목적과 한계를 기록해야 의미 있는 지표가 됩니다.

오래된 값의 처리

가격 r이 숫자로 존재하더라도 t가 오래된 경우에는 사용 목적에 맞는지 검토해야 합니다. 최신 기준을 요구하는 기능이라면 오래된 값을 정상 현재값처럼 사용하지 않는 정책이 필요합니다. 얼마를 오래됐다고 볼지는 해당 기능의 공식 조건이나 자체 운영 요구에 따라 정합니다.

임의로 정한 유효기간을 거래소의 공식 제한으로 표현하지 않습니다. 예를 들어 자체 화면이 5초 후 회색 표시를 한다고 해서 거래소 가격이 5초 후 무효가 된다는 뜻은 아닙니다. 데이터의 공식 의미와 소비 프로그램의 운영 규칙을 나눠 설명합니다.

5. 다른 가격과 무엇이 다른가

Last Price와 비교

Last Price는 마지막 체결 가격을 나타내는 자료입니다. Reference Price가 마지막 체결과 같을 수도 다를 수도 있지만, 같은 숫자가 나온다고 두 기능이 동일하다고 결론내릴 수 없습니다. 한 번의 일치와 정의의 동일성은 다릅니다.

마지막 거래가 드물거나 가격이 급변하는 상황에서는 서로 다른 목적의 가격 자료가 더 눈에 띄게 달라질 수 있습니다. 차이를 해석하려면 각 자료의 시각과 정의를 확인해야 합니다. 차이가 있다는 이유만으로 어느 쪽이 잘못됐다고 단정하지 않습니다.

Average Price와 비교

Average Price는 구간 i와 평균 w, 마지막 거래 시간 T를 제공하는 별도 스트림입니다. Reference Price에는 같은 구간 필드가 제시되어 있지 않습니다. 따라서 r을 “5분 평균”이라고 부르거나 Average Price의 w를 r의 공식 산식이라고 설명하지 않습니다.

평균 가격과 기준 가격이 가까워 보인다면 그 관측 사실까지만 말할 수 있습니다. 특정 샘플에서 유사하다는 이유로 내부 계산 방식을 추정해 확정된 공식처럼 쓰면 안 됩니다. 기능의 이름과 관측 상관관계는 공식 정의를 대체하지 않습니다.

Book Ticker와 비교

Book Ticker는 현재 최우선 매수·매도 가격과 수량 변화에 관한 자료입니다. 기준 가격은 상대방의 대기 주문을 의미하지 않으므로 r에서 원하는 수량을 거래할 수 있다는 보장이 없습니다. 실행 가능성은 실제 호가와 주문 조건을 따로 확인해야 합니다.

매수·매도 호가의 중간값을 자체 기준으로 계산할 수는 있습니다. 그러나 그 중간값을 공식 Reference Price라고 부르지 않습니다. 계산값에는 “호가 중간값”이라는 별도 이름과 사용한 두 호가의 시각을 붙여야 합니다.

Mark Price·Price Index와 비교

선물 관련 가격 지표는 해당 상품의 공식 문서에서 정의와 사용 목적을 확인해야 합니다. 현물 Reference Price를 선물 청산 가격이나 Mark Price의 다른 이름으로 설명하지 않습니다. 같은 기초 자산을 다룬다고 모든 가격 필드가 서로 교환 가능한 것은 아닙니다.

시장과 상품을 구분하는 습관은 실무에서 특히 중요합니다. 현물 데이터로 선물 포지션 위험을 계산하거나, 선물 지표를 현물 주문 규칙의 값으로 대체하는 것은 별도 근거가 필요한 작업입니다. 이 글의 범위에서는 그런 대체를 하지 않습니다.

6. 실제 데이터 검증 절차

1단계: 기능 이름과 문서 범위를 고정

Spot Reference Price Streams를 대상으로 한다고 기록합니다. 관련 주문 규칙을 조사한다면 그 규칙의 공식 문서를 별도로 첨부합니다. 같은 표현이 있는 다른 상품 문서를 섞지 않습니다. 자료의 출처와 확인 날짜를 적어 두면 변경 후 차이를 추적하기 쉽습니다.

2단계: 심볼과 메시지 유형 확인

실제 응답의 e가 referencePrice인지, s가 의도한 심볼인지 확인합니다. 결합 스트림이면 바깥 stream과 안쪽 data를 구분합니다. 이름이 다른 메시지를 같은 형식으로 읽지 않도록 파서를 분리합니다.

3단계: r의 상태를 먼저 검사

숫자 문자열인지 null인지 구분합니다. 아직 메시지가 오지 않은 상태와 null을 수신한 상태도 분리합니다. 숫자가 아닌 예상 밖 값이 오면 정상 가격으로 강제 변환하지 않고 검증 실패로 남깁니다.

4단계: t와 수신 시간을 기록

시간 단위를 확인하고 원본 숫자를 보존합니다. 화면 표시 시간대와 내부 계산 시간대를 일관되게 관리합니다. 비교하는 다른 자료도 같은 시간 기준으로 정리하되, 서로 다른 시각의 값을 완전히 동시 자료라고 부르지는 않습니다.

5단계: 목적에 맞는 비교 수행

Last Price, 평균 가격, 호가 중간값 중 무엇과 비교하는지 명시합니다. 차이 계산의 분모와 단위도 적습니다. r이 없거나 비교 자료가 오래됐다면 계산을 보류하고 이유를 표시합니다. 누락을 숨기기 위해 이전 값을 자동으로 현재값처럼 넣지 않습니다.

6단계: 주문 규칙과 연결할 때 추가 확인

어떤 규칙이 이 가격을 사용하는지 공식 근거가 있는지 확인합니다. 해당 규칙의 적용 대상과 현재 심볼 조건도 검토합니다. 이 연결이 확인되지 않았다면 참고용 비교 화면으로만 사용하고 주문 허용 범위를 확정하는 계산으로 확대하지 않습니다.

7. 다섯 가지 가상 사례

사례 1: r이 null인 경우

어떤 심볼의 메시지에서 r이 null이라고 가정합니다. 프로그램이 이를 숫자 0으로 바꾼 뒤 마지막 가격 100과 비교하면 100의 차이나 0으로 나누는 오류가 발생합니다. 올바른 첫 반응은 “기준 가격 없음”이라는 상태를 보존하는 것입니다.

이전 유효 값 99가 저장돼 있다면 참고용으로 보여 줄 수는 있습니다. 그러나 현재 r과 같은 칸에 정상값처럼 넣지 않고 이전 값과 시각을 따로 표시합니다. 계산이 현재 기준 가격을 요구한다면 그 계산은 보류해야 합니다. 이는 데이터 부재를 숨기지 않는 처리 예시입니다.

사례 2: 기준 가격과 마지막 가격이 다른 경우

가상의 r이 100이고 마지막 체결 가격이 102라고 합시다. 차이는 2이며 r을 분모로 한 비율은 2%입니다. 여기서 확실히 말할 수 있는 것은 선택한 두 관측값의 차이입니다. 2%가 확정 차익이나 곧 회복될 괴리라는 결론은 나오지 않습니다.

두 값의 시각과 시장을 확인하고 현재 호가도 별도로 봅니다. 마지막 체결 102가 지금 매도 가능한 가격일 수도 없을 수도 있습니다. 기준 가격은 실제로 거래할 수 있는 상대 주문을 뜻하지 않으므로 이 차이만으로 매매 결과를 계산하지 않습니다.

사례 3: 새 수신이지만 t가 변하지 않는 경우

메시지를 새로 받았는데 r과 t가 이전과 같다고 가정합니다. 수신 이벤트가 새롭다는 사실과 기준 가격이 새롭게 유효해졌다는 사실을 구분해야 합니다. 값을 반복 수신했다고 해서 그 시각을 현재 시간으로 덮어쓰면 원래 유효 시각이 사라집니다.

원본 t와 로컬 수신 시간을 각각 유지하면 같은 값의 반복 전달인지 다른 문제인지 살펴볼 수 있습니다. 정확한 원인을 확인하기 전에는 엔진 장애나 네트워크 지연이라고 단정하지 않습니다. 공식 의미와 실제 관측을 구분한 기록이 먼저입니다.

사례 4: 서로 다른 기준 자산을 비교한 경우

한 거래쌍의 r이 100 USDT 단위이고 다른 거래쌍의 r이 0.002 BTC 단위라고 가정합니다. 숫자 100이 더 크다고 첫 자산의 가치가 더 높다고 결론내릴 수 없습니다. 단위가 다르고 기초 자산도 다를 수 있기 때문입니다.

비교하려면 동일 자산과 기준 통화로 환산하는 절차가 필요하며 환산 가격의 시각과 비용도 고려해야 합니다. 환산 결과는 자체 계산값으로 남깁니다. 원래 공식 r 값과 환산값을 같은 출처인 것처럼 표시하지 않습니다.

사례 5: 중간 호가로 대체한 경우

기준 가격이 없을 때 매수 호가 99와 매도 호가 101의 중간값 100을 계산했다고 합시다. 100은 그 두 호가에서 계산한 중간값입니다. Reference Price 스트림이 100을 제공한 것이 아니므로 공식 기준 가격으로 기록하면 안 됩니다.

자체 분석에서 대체 기준이 필요하다면 “호가 중간값 대체”라는 출처와 두 호가의 시각을 남깁니다. 그 대체가 허용되는 용도인지도 검토합니다. 특히 주문 규칙을 검증하는 목적이라면 공식적으로 다른 값을 넣어도 되는지 확인되지 않은 이상 같은 계산으로 취급하지 않습니다.

8. 상태 관리 표를 설계하는 방법

데이터 상태를 숫자 하나로만 저장하면 복구 과정에서 문제가 생깁니다. 심볼, r 원본, r 상태, t 원본, 수신 시각, 연결 상태, 출처를 분리하면 원인 분석이 쉬워집니다. 마지막 유효 가격을 보존한다면 그 가격의 시각도 함께 보존합니다.

예를 들어 현재 상태는 “기준 가격 없음”인데 마지막 유효 가격은 100일 수 있습니다. 이 두 정보를 동시에 표현할 수 있어야 합니다. 마지막 값이 있다는 이유로 현재 상태를 정상으로 바꾸거나, 현재 값이 없다는 이유로 모든 과거 기록을 지우는 방식은 각각 다른 문제를 만듭니다.

운영 기록에는 무엇을 언제 관측했는지만 담고 추측 원인을 사실처럼 적지 않습니다. “11시 3분에 null 수신”은 관측이고 “거래소가 유동성 부족으로 가격을 중단”은 별도 근거가 필요한 설명입니다. 원인과 현상을 구분하면 나중에 공식 안내가 나왔을 때 기록을 정확히 해석할 수 있습니다.

원본과 파생값 분리

원본 r을 소수 두 자리로 반올림해 저장하면 작은 변화를 잃을 수 있습니다. 표시를 위해 반올림하더라도 원본 문자열은 보존하고, 차이율이나 환산값은 별도 필드로 저장합니다. 파생값을 원본 위치에 덮어쓰면 어떤 계산을 했는지 추적할 수 없습니다.

또한 값의 자료형을 함께 검증합니다. 문자열 가격, null, 시간 숫자, 심볼 문자열은 다른 자료형입니다. 화면에 모두 글자로 보인다고 내부 처리도 같은 방식으로 해서는 안 됩니다. 가격 계산을 하기 전에 유효 값인지 확인하는 단계가 필요합니다.

9. 오류 해결 순서

r을 찾을 수 없는 경우

먼저 실제 메시지 유형을 확인합니다. 다른 스트림을 받았거나 결합 구조에서 data 내부를 읽지 않았을 수 있습니다. 원본 응답을 보고 문서의 필드와 비교합니다. 없는 필드를 0이나 이전 가격으로 자동 보충하기 전에 구조가 맞는지 확인합니다.

시간이 비정상적으로 보이는 경우

t를 거래 ID로 처리하지 않았는지, 시간 단위가 맞는지 확인합니다. 초·밀리초·마이크로초 변환과 시간대 변환을 각각 검사합니다. 원본 숫자를 남겼다면 어떤 단계에서 잘못됐는지 재현할 수 있습니다.

기준 가격과 다른 시세가 크게 다른 경우

시장, 심볼, 단위, 시각을 먼저 맞춥니다. 비교 값이 Last Price인지 평균인지 호가인지 확인합니다. 이 조건이 다르면 가격 차이 자체가 이상 현상의 증거가 아닐 수 있습니다. 공식 정의가 없는 내부 계산 차이를 추정해 단정하지 않습니다.

null이 반복되는 경우

null은 문서상 가능한 상태이므로 곧바로 파서 오류라고 부르지 않습니다. 해당 심볼과 공식 지원·규칙을 확인하고 현재 값이 필요한 계산은 보류합니다. 새로고침이나 재연결을 무한 반복한다고 기준 가격이 생기는 것은 아닙니다. 원인이 확인되지 않으면 관측 상태를 그대로 기록합니다.

연결이 끊긴 경우

연결 관리 규칙에 따라 복구하고 새로 받은 값의 상태와 시각을 확인합니다. 이전 화면의 숫자가 남아 있다는 이유로 새 연결의 검증을 생략하지 않습니다. 끊긴 동안 모든 과거 값이 복원됐다고 가정하지 않고 누락 구간을 별도로 표시합니다.

10. 분석 결과를 설명할 때의 표현

“Reference Price보다 마지막 가격이 높다”는 관측과 “가격이 과대평가됐다”는 판단은 다릅니다. “기준 가격 없음”과 “가격이 0이다”도 다릅니다. “t가 오래됐다”와 “거래소가 고장났다”는 역시 다른 주장입니다. 각 문장이 요구하는 근거 수준을 구분합니다.

보고서에는 비교한 스트림과 시각, 단위, 계산 방법을 함께 적는 편이 좋습니다. 예를 들어 “같은 심볼의 관측 r과 Last Price 차이, r 기준 비율, 각 수신 시각”처럼 범위를 명확히 하면 다른 사람이 재검토할 수 있습니다. 단순한 빨간색 경고만으로 원인까지 전달하려 하지 않습니다.

불확실성을 정확히 표시하는 것은 분석을 약하게 만드는 일이 아닙니다. 확인 가능한 데이터와 아직 확인되지 않은 연결을 분리하면 실제 오류를 더 빨리 찾을 수 있습니다. 숫자가 있다고 모든 해석이 가능한 것은 아니라는 점을 기억해야 합니다.

11. 위험과 한계

기준 가격이 있다고 해당 가격에 원하는 수량을 거래할 수 있는 것은 아닙니다. 실제 시장에는 스프레드, 잔량, 지연, 수수료와 가격 변동이 있습니다. 통계적 기준과 실행 가능 가격을 혼동하면 예상과 실제 체결 사이의 차이를 과소평가할 수 있습니다.

공식 스트림의 짧은 설명만으로 내부 산식을 재현하거나 구성 거래소를 확정할 수 없습니다. 확인되지 않은 계산식을 사용하면 현재 샘플에는 맞아 보이더라도 다른 시장 상황에서 틀릴 수 있습니다. 공식 문서가 제공한 범위를 넘어서는 주장은 추가 근거가 필요합니다.

공개 데이터에서 참여자의 신원이나 의도도 알 수 없습니다. Reference Price와 다른 가격의 차이를 특정 세력의 조작 증거로 단정하지 않습니다. 시장 구조나 데이터 정의 차이 등 여러 가능성이 있으며, 인과관계는 별도 검증이 필요합니다.

운영 상황별 검증 연습

Reference Price는 숫자를 계산하는 연습만큼 상태를 구분하는 연습이 중요합니다. 작은 표에 네 가지 가상 입력을 적어 봅니다. 첫 행은 정상 숫자 r과 t가 있는 경우, 둘째는 r이 null인 경우, 셋째는 아직 아무 메시지도 받지 않은 경우, 넷째는 연결이 끊겼지만 이전 숫자가 남은 경우입니다. 화면에는 모두 비슷한 빈칸이나 같은 숫자로 나타날 수 있으나 처리해야 할 의미는 다릅니다.

정상 숫자 행에서는 심볼과 시간 단위를 검증한 뒤 비교 계산을 허용할 수 있습니다. null 행에서는 현재 기준 가격이 없다는 사실을 표시하고, 그 값을 필요로 하는 계산은 보류합니다. 수신 전 행에서는 데이터 초기화가 끝나지 않았음을 표시합니다. 연결 끊김 행에서는 이전 값을 참고로 남기더라도 현재 연결 상태와 마지막 수신 시간을 함께 보여 줍니다.

이 네 경우를 모두 0으로 처리하면 차이율, 그래프, 경고가 동시에 잘못될 수 있습니다. 반대로 모두 마지막 값으로 채우면 자료가 없는 상황이 정상 상태처럼 보일 수 있습니다. 상태를 정확히 표현하는 것은 화면 디자인의 문제가 아니라 계산 입력의 의미를 보존하는 문제입니다.

비교표의 분모를 검증하기

가상의 r이 80이고 비교 가격이 100이라면 r 기준 차이는 25%입니다. 비교 가격 100을 분모로 쓰면 20%입니다. 같은 두 숫자라도 분모에 따라 결과가 달라지므로 “괴리 20%”처럼 정의 없는 표현을 쓰지 않습니다. 계산식을 함께 표시해야 다른 사람이 결과를 이해할 수 있습니다.

이번에는 r이 null이라고 합시다. 앞의 계산에 0이나 이전 값 80을 조용히 넣으면 현재 자료로 계산한 것처럼 보이지만 실제로는 그렇지 않습니다. 이전 값을 이용한 참고 계산이라면 그 사실과 이전 유효 시각을 표시해야 합니다. 현재 기준값이 필수인 검증이라면 계산 자체를 보류하는 것이 맞습니다.

시각이 다른 비교의 한계

11시 00분의 기준 가격과 11시 05분의 마지막 체결 가격을 비교하면 5분 사이 시장 움직임이 포함됩니다. 이것을 같은 시각의 가격 괴리라고 부를 수 없습니다. 두 시각을 함께 적고 분석 목적이 시점 간 변화인지 동시 가격 비교인지 구분합니다.

더 가까운 시각의 값을 찾더라도 각 데이터의 유효 시각과 수신 시각은 다를 수 있습니다. 완벽한 동시성이라고 주장하기보다 허용한 시간 차이와 자료 선택 규칙을 기록합니다. 이 규칙은 자체 분석 정책이며 거래소의 공식 동기화 보장을 뜻하지 않습니다.

값의 변경 이력을 남기는 이유

최신 값만 저장하면 나중에 문제가 발생했을 때 무엇이 들어왔는지 확인하기 어렵습니다. 중요한 검증이라면 원본 값, 상태 변경, 수신 시각을 필요한 범위에서 기록합니다. 특히 숫자에서 null로 바뀐 순간과 연결이 끊긴 순간은 서로 다른 사건이므로 분리해 남기는 편이 좋습니다.

다만 기록이 있다고 모든 원인을 알 수 있는 것은 아닙니다. 로그는 관측을 보존하는 자료이며 거래소 내부 상태를 직접 보여 주지 않습니다. 로그에 없는 사유를 추측해 장애 원인으로 확정하지 않고, 공식 공지나 추가 확인이 필요한 항목을 별도로 정리합니다.

다른 담당자에게 전달할 때

문제를 보고할 때는 “가격 이상”이라는 짧은 문장보다 시장·심볼·원본 r·t·수신 시각·비교한 자료와 계산식을 전달하는 편이 유용합니다. 자격 증명이나 계정 비밀정보는 공개 데이터 검증에 필요하지 않으므로 포함하지 않습니다. 재현에 필요한 최소 자료와 추측을 구분합니다.

예를 들어 “r=null을 수신했는데 화면이 이전 값을 현재값으로 표시했다”는 보고는 수정할 대상이 명확합니다. 반면 “거래소 기준 가격이 틀렸다”는 주장은 원본과 비교 기준 없이는 평가하기 어렵습니다. 현상, 처리 결과, 기대 동작을 나눠 적으면 실제 문제를 좁힐 수 있습니다.

12. 자주 묻는 질문

Q1. Reference Price는 마지막 체결 가격인가요?

동일한 것으로 정의하지 않습니다. 별도 스트림이며 마지막 체결 자료와 구분합니다.

Q2. r이 null이면 가격이 0인가요?

아닙니다. 기준 가격이 없다는 상태와 실제 숫자 0은 다릅니다.

Q3. null이면 이전 값을 사용해도 되나요?

참고용 보존은 가능하지만 현재 유효 값처럼 표시하지 않습니다. 용도별 대체 정책과 출처를 분명히 해야 합니다.

Q4. t는 거래 ID인가요?

이 스트림에서는 기준 가격이 유효했던 엔진 타임스탬프입니다. 다른 메시지의 t와 의미가 다릅니다.

Q5. t와 수신 시각 차이가 네트워크 지연인가요?

전부 그렇게 해석할 수 없습니다. 유효 시각의 의미와 로컬 시계 오차도 고려해야 합니다.

Q6. Average Price와 같은 계산인가요?

같다고 가정하지 않습니다. 공식 항목이 서로 다르며 평균 구간 정보를 임의로 가져오지 않습니다.

Q7. 호가 중간값을 r로 대신 넣어도 되나요?

그 값은 자체 계산한 중간 호가입니다. 공식 Reference Price로 기록해서는 안 됩니다.

Q8. 모든 심볼에서 항상 값이 있나요?

그렇게 보장하지 않습니다. 실제 응답과 최신 공식 지원 조건을 확인해야 합니다.

Q9. 기준 가격으로 주문하면 체결되나요?

실제 체결은 현재 호가와 주문 조건에 달려 있습니다. 기준 가격은 상대 주문을 보장하지 않습니다.

Q10. 선물 Mark Price와 같은가요?

같은 기능으로 취급하지 않습니다. 상품과 공식 정의를 각각 확인해야 합니다.

Q11. 내부 계산식은 무엇인가요?

이 글에서 확인한 스트림 설명만으로 세부 산식을 확정하지 않습니다. 공개되지 않은 내용을 추측하지 않습니다.

Q12. 1000ms마다 반드시 새 가격이 생기나요?

갱신 속도와 값의 변경, 실제 수신 시간은 구분해야 합니다. 모든 수신에서 가격이 바뀐다고 보장하지 않습니다.

Q13. 다른 가격과 차이가 나면 오류인가요?

먼저 시장·심볼·단위·시각·정의를 맞춥니다. 서로 다른 목적의 가격은 다를 수 있습니다.

Q14. 이 값으로 주문 필터 통과 여부를 확정할 수 있나요?

해당 필터가 무엇을 참조하는지 공식적으로 확인해야 합니다. 이름만으로 연결하지 않습니다.

Q15. 기준 가격이 낮으면 매수 기회인가요?

그 자체로 매매 기회를 보장하지 않습니다. 비교 관측과 투자 판단은 별개입니다.

13. 체크리스트

• Spot Reference Price 문서를 기준으로 확인했다.
• e와 s가 의도한 자료인지 확인했다.
• r의 숫자와 null을 구분한다.
• 아직 수신 전과 null 수신을 구분한다.
• t를 엔진 시각으로 해석한다.
• 시간 단위와 표시 시간대를 확인했다.
• 이전 유효 값의 시각을 함께 보존한다.
• 원본과 환산·차이율 계산값을 분리한다.
• 다른 가격과 비교할 때 출처를 표시한다.
• 기준 가격 부재를 다른 값으로 몰래 대체하지 않는다.
• 주문 규칙과의 연결은 별도 공식 근거로 확인한다.
• 현재 실행 가능 가격은 호가로 따로 확인한다.
• 내부 산식과 참여자 의도를 추측하지 않는다.
• 누락 구간과 연결 상태를 기록한다.

핵심 정리

바이낸스 Reference Price를 읽는 핵심은 기준 가격이라는 이름에 많은 의미를 덧붙이는 것이 아니라, 공식 값의 존재 여부와 출처·시각을 보존하는 것입니다. null을 숨기지 않고 다른 가격과 구분하면 기준 자료를 사용하는 분석과 시스템을 더 정확하게 검토할 수 있습니다.

공식 확인 자료: Binance Spot WebSocket Streams — Reference Price Streams.

이 글은 시장 데이터 이해를 위한 정보이며 투자 권유가 아닙니다. 사양과 지원 조건은 변경될 수 있습니다. 실제 거래 전 최신 공식 문서와 주문 조건을 확인하고 가격 변동, 슬리피지, 수수료 위험을 고려하세요.