바이낸스 Rolling Window Statistics 뜻 2026｜1h·4h·1d 통계·O C 경계·캔들 차이

바이낸스 Rolling Window Statistics 뜻 2026｜1h·4h·1d 통계·O C 경계·캔들 차이

바이낸스 Rolling Window Statistics는 현재 갱신 시점을 따라 움직이는 구간의 가격·거래량 통계입니다. 고정된 시작과 끝을 갖는 캔들과 다르며, 하루 통계라고 해서 항상 특정 시간대 자정부터의 자료를 뜻하지도 않습니다. 어떤 시간 범위를 집계했는지 먼저 확인해야 숫자를 올바르게 읽을 수 있습니다.

같은 심볼의 1시간 통계를 연속으로 받더라도 매번 독립적인 새 1시간이 추가되는 것은 아닙니다. 대부분의 구간이 서로 겹칩니다. 거래량을 갱신마다 더하거나 변화율을 단순 합산하면 겹친 자료를 반복 계산하게 됩니다.

이 글은 2026년 10월 29일 확인한 Binance Spot WebSocket 공식 문서의 Individual Symbol Rolling Window Statistics Streams와 All Market Rolling Window Statistics Streams를 기준으로 합니다. REST의 동명 기능이나 다른 시장 규격을 같은 것으로 간주하지 않습니다.

1. 고정 캔들과 이동 구간의 차이

1시간 캔들은 정해진 경계의 한 시간 구간을 요약하고, 마감 뒤 다음 캔들이 이어지는 방식으로 이해할 수 있습니다. 반면 이동 구간 통계는 갱신 시점에 따라 집계 대상 범위가 움직입니다. 같은 1h라는 표시가 있어도 시작·종료 경계가 같다는 뜻은 아닙니다.

예를 들어 10시 30분 부근의 이동 1시간 통계와 10시부터 11시까지의 진행 중 1시간 캔들은 포함 범위가 다릅니다. 두 값의 거래량이나 변화율이 다르다는 이유만으로 어느 쪽이 오류라고 단정하지 않습니다. 먼저 실제 집계 시각을 비교해야 합니다.

자정 이후 누적과 구분

최근 24시간이라는 개념과 오늘 자정부터 현재까지라는 개념은 다릅니다. 이동 구간에는 전날 일부 자료가 포함될 수 있고 시간이 흐르면서 오래된 자료가 빠져나갑니다. 화면의 "오늘"이라는 표현이 어떤 기준인지 명확하지 않으면 오해하기 쉽습니다.

공식 문서는 기본 {symbol}@ticker의 24시간 통계도 UTC 하루 통계와 다르다고 설명합니다. 이 글의 {symbol}@ticker_{windowSize}는 그 기본 ticker와도 별도로 설명되는 스트림입니다. 이름이 비슷하다고 모든 경계 규칙을 같게 처리하지 않습니다.

구간이 움직이면 과거 자료가 빠짐

거래량은 새 거래가 들어와 증가할 수 있지만 오래된 거래가 범위 밖으로 빠지면서 감소할 수도 있습니다. 누적 카운터처럼 항상 증가해야 한다는 규칙을 적용하면 정상적인 감소를 오류로 분류할 수 있습니다.

가격 변화율도 새 가격 변화뿐 아니라 구간 시작 기준이 바뀌는 영향을 받습니다. 마지막 가격이 거의 같더라도 기준 구간이 이동하면 통계가 달라질 수 있습니다. 결과 숫자만 보고 새로운 큰 거래가 발생했다고 단정하지 않습니다.

2. 지원 windowSize와 갱신 주기

현물 개별 심볼 스트림 이름은 {symbol}@ticker_{windowSize}입니다. 현재 공식 문서는 windowSize로 1h, 4h, 1d를 안내하고 갱신 속도는 1000ms로 제시합니다. 임의의 모든 시간 길이가 이 스트림에서 지원된다고 가정하지 않습니다.

1h·4h·1d는 통계 구간 설정이고 1000ms는 자료 갱신 주기에 관한 안내입니다. 이 둘을 혼동하면 한 시간에 한 번만 메시지가 온다고 생각하거나 매초 독립적인 한 시간 거래량이 추가된다고 잘못 해석할 수 있습니다.

여러 구간을 동시에 관찰

같은 심볼의 1h와 4h 통계를 함께 볼 수 있지만 두 거래량을 더해 5시간 거래량이라고 부를 수 없습니다. 구간이 겹치기 때문입니다. 더 긴 구간과 짧은 구간은 비교 대상이지 서로 독립적인 조각이 아닙니다.

내부 저장 키에는 심볼뿐 아니라 windowSize와 자료 종류를 구분해야 합니다. 같은 심볼의 마지막 메시지 하나만 저장하면 1h와 4h가 번갈아 덮어써질 수 있습니다. 화면의 이름과 실제 데이터셋 구성을 일치시키는 것이 중요합니다.

제품과 경로 확인

REST API의 rolling window 기능은 별도 요청 파라미터와 응답 구조를 가질 수 있습니다. WebSocket에서 지원하는 구간 목록을 다른 경로의 모든 지원 범위로 확장하지 않습니다. 문서의 제품·시장·전송 방식까지 확인해야 합니다.

이 글의 수치와 필드 설명은 현물 WebSocket 기준입니다. 선물·옵션·마크 가격 등 다른 자료를 사용할 때는 해당 공식 문서를 다시 확인하세요. 이름이 같은 지표라도 계산 대상 시장과 구간이 달라질 수 있습니다.

3. O와 C로 실제 시간 범위 확인

공식 문서는 O가 항상 분 단위 경계에서 시작하고 C는 현재 갱신 시각이라고 설명합니다. 그 결과 실효 구간은 설정한 windowSize보다 최대 59,999ms 더 넓을 수 있다고 안내합니다. 정확히 고정 길이의 구간이라고 가정하지 않는 것이 핵심입니다.

O와 C는 통계 시작·종료 시각입니다. 이벤트 시각 E와 구분해야 하며 로컬 수신 시각과도 다른 값입니다. 시각 하나만 저장하면 실제 집계 범위와 전달 상태를 함께 복원하기 어렵습니다.

구간 이름보다 실제 경계

보고서에 1h라고만 적기보다 O·C 또는 실제 시작·종료 시각을 함께 보관하면 비교가 쉬워집니다. 서로 다른 시각에 받은 1h 통계는 대부분 겹치지만 완전히 같지는 않은 자료입니다. 동일한 이름이라는 이유로 같은 표본이라고 취급하지 않습니다.

다른 서비스와 숫자가 다를 때도 먼저 실제 경계를 맞춥니다. 단순히 로컬 화면의 시각이 비슷하다는 이유만으로 집계 범위가 동일하다고 볼 수 없습니다. 시간 단위와 자료 갱신 지연도 확인해야 합니다.

시간 단위와 표시 변환

일반 WebSocket 규칙은 기본 밀리초와 선택적 마이크로초 설정을 안내합니다. 현재 연결의 설정을 확인하고 O·C·E를 일관된 단위로 처리해야 합니다. 공식 설명의 59,999ms라는 단위와 내부 저장 단위를 혼동하지 않습니다.

한국시간 표시는 절대 시각을 보여주는 방식입니다. 원본 타임스탬프에 임의로 9시간을 더해 새로운 절대 시각처럼 저장하지 않습니다. 원본 단위와 표시 시간대를 분리하면 다른 자료와 비교할 때 오류를 줄일 수 있습니다.

4. 가격·거래량 필드 읽기

메시지에는 심볼 s, 이벤트 종류 e, 이벤트 시각 E와 함께 p·P·o·h·l·c·w·v·q·O·C·F·L·n이 제시됩니다. 짧은 이름을 다른 스트림과 동일하게 해석하지 않습니다. 예를 들어 여기서 p는 가격 변화이고 Trade Stream의 p는 개별 체결 가격입니다.

대소문자와 의미를 유지

p와 P, o와 O, c와 C는 다른 값을 뜻합니다. 필드 이름을 소문자로 통일하는 변환은 정보 충돌을 만들 수 있습니다. 내부 이름을 바꾼다면 priceChange, statisticsOpenTime처럼 의미가 드러나게 매핑하는 편이 좋습니다.

숫자 문자열과 정수 시각을 같은 처리 방식으로 변환하지 않습니다. 가격·수량의 소수 정밀도, 큰 ID의 정확성, 시간 단위를 각각 고려해야 합니다. 파싱 실패를 0으로 바꾸면 정상 지표처럼 보일 수 있으므로 오류 상태를 별도로 남깁니다.

변화량과 변화율의 차이

가격이 100에서 105로 변한 가상 구간이라면 절대 변화는 5이고 단순한 시작 가격 기준 변화율은 5%입니다. 숫자가 같게 보이는 이 예시만으로 두 필드가 같은 것이라고 생각하면 안 됩니다. 시작 가격이 달라지면 단위와 값의 차이가 분명해집니다.

서로 다른 거래쌍을 비교할 때 절대 변화량만으로 상승 정도를 판단하면 가격 수준 차이를 놓칠 수 있습니다. 비율 역시 구간과 시작 기준이 같아야 비교가 의미 있습니다. 공식 필드와 자체 계산 결과를 혼합할 때 정의를 명시하세요.

5. 다섯 가지 이동 구간 사례

예시 1. 오래된 거래가 구간 밖으로 빠짐

첫 관측에서 거래량 v가 100이고 다음 관측에서 95가 됐다고 가정합니다. 새 거래가 적고 오래된 큰 거래가 범위 밖으로 빠졌다면 이동 구간 거래량은 줄어들 수 있습니다. 항상 증가해야 하는 누적 계정 잔액처럼 검증해서는 안 됩니다.

차이 -5를 취소된 거래량이라고 해석하는 것도 부정확합니다. 이동 구간의 출입 효과가 섞인 결과일 수 있습니다. 어떤 자료가 빠지고 들어왔는지 개별 거래 수준에서 확인하지 않았다면 원인을 확정하지 않습니다.

예시 2. 연속 갱신 거래량을 더함

1h 통계의 v가 100, 101, 102로 갱신됐다고 가정합니다. 이를 더한 303이 세 번의 독립적인 거래량이 되는 것은 아닙니다. 각 메시지는 대부분 겹친 구간을 요약합니다. 최신 통계 상태를 갱신하는 것과 새로운 거래량을 누적하는 것을 구분해야 합니다.

기간 전체 거래량이 필요하면 목적에 맞는 비중복 자료나 명확한 재집계 방법을 선택해야 합니다. 이동 구간 메시지 수가 많다는 이유로 더 정확한 총량을 얻는 것은 아닙니다. 먼저 자료의 겹침 구조를 이해하세요.

예시 3. 1h와 4h를 합산

같은 갱신 시점의 1h 거래량이 20, 4h 거래량이 80이라고 가정합니다. 둘을 더해 100을 5시간 거래량이라고 부를 수 없습니다. 짧은 구간이 긴 구간과 겹치기 때문입니다. 비교는 가능하지만 합산에는 독립 구간이라는 조건이 필요합니다.

두 값의 비율을 계산하는 것도 별도 분석 정의입니다. 단위와 실제 O·C를 확인하고, 그 비율이 미래 거래량이나 가격을 예측한다고 단정하지 않습니다. 분석용 지표와 공식 제공 통계를 구분해 이름을 붙이세요.

예시 4. 같은 1h인데 캔들과 다름

10시 30분의 이동 1h 통계와 10시 시작 1h 캔들을 비교한다고 가정합니다. 집계 시작점과 현재 포함 범위가 다르므로 OHLC·거래량이 일치할 필요가 없습니다. 이 차이를 반올림 오류로만 설명하면 근본적인 구간 차이를 놓칩니다.

비교표에는 자료 종류, 시작 시각, 종료 시각, 마감 여부를 함께 적을 수 있습니다. 캔들의 x와 이동 통계의 O·C는 각각 다른 구조를 설명합니다. 이름이 비슷한 필드를 하나로 합치지 않습니다.

예시 5. 전체 시장 배열에 심볼이 없음

전체 시장 스트림의 한 배열에 어떤 심볼이 없다고 가정합니다. 공식 문서는 변경된 ticker만 배열에 포함된다고 설명합니다. 따라서 빠진 심볼을 상장 폐지나 거래량 0으로 바로 처리하지 않습니다.

이전 상태를 유지하더라도 마지막으로 갱신받은 시각을 함께 관리해야 합니다. 연결이 끊겨 못 받은 것인지 실제로 이번 배열에 변화가 없었던 것인지 구분할 운영 정보가 필요합니다. 자료가 없는 이유를 임의로 하나로 확정하지 않습니다.

6. 전체 시장 스트림의 부분 갱신

전체 시장 이름은 !ticker_{windowSize}@arr입니다. 공식 문서는 1h·4h·1d 구간과 1000ms 갱신을 안내하며 변경된 ticker만 배열에 포함된다고 설명합니다. 배열 하나를 전체 시장의 완전한 새 목록으로 간주하면 안 됩니다.

받은 각 심볼의 상태를 갱신하는 구조와 초기 전체 상태 준비를 구분해야 합니다. 이번 메시지에 없는 심볼을 삭제하는 로직은 자료 의미와 맞지 않을 수 있습니다. 완전한 심볼 목록이 필요한 작업은 해당 목적의 공식 자료를 별도로 확인해야 합니다.

초기 화면의 미준비 상태

연결 직후 아직 한 번도 받지 못한 심볼과 이전에 받았지만 이번에는 변경되지 않은 심볼은 다릅니다. 둘을 모두 0으로 표시하면 미준비 자료가 실제 통계처럼 보입니다. 미수신·최신·오래됨 같은 상태를 목적에 맞게 구분할 수 있습니다.

순위표를 만들 때도 준비된 심볼만으로 계산한 결과인지 명시해야 합니다. 전체 시장 순위라고 이름 붙였는데 일부만 받은 상태라면 사용자가 범위를 오해할 수 있습니다. 계산 대상 집합의 완성도를 확인하세요.

심볼별 갱신 시각

여러 심볼의 메시지가 같은 배열에 들어 있어도 각 통계의 실제 O·C를 보관하는 것이 좋습니다. 화면을 그린 로컬 시각 하나로 모든 자료의 기준 시각을 대체하지 않습니다. 심볼별 최신성과 집계 범위를 확인할 수 있어야 합니다.

서로 다른 windowSize의 배열도 같은 저장 키를 공유하지 않아야 합니다. 1h 순위 화면에 4h 값이 섞이면 숫자는 그럴듯해 보여도 정의가 달라집니다. 자료 종류와 구간을 키에 포함하면 이런 오류를 줄일 수 있습니다.

7. 순위와 비교 지표의 주의점

변화율 순위를 만들 때는 같은 시장·구간·시각 기준을 사용하는지 먼저 확인합니다. 일부 심볼은 최신이고 일부는 오래된 상태라면 순위가 같은 순간을 비교하지 않을 수 있습니다. 최신성 기준을 정하고 제외 또는 표시 정책을 마련해야 합니다.

거래량 순위는 단위를 확인해야 합니다. 기초 자산 수량 v를 서로 다른 코인끼리 그대로 비교하면 자산 단위 차이를 무시하게 됩니다. quote 금액 q도 quote 자산이 다르면 별도 환산 기준 없이 직접 비교하기 어렵습니다.

높은 변화율과 충분한 거래량

높은 변화율이 반드시 큰 거래 금액이나 깊은 유동성을 뜻하지 않습니다. 작은 표본이나 특정 구간의 기준 가격에 따라 비율이 크게 보일 수 있습니다. 가격 변화, 거래량, 호가 상태는 서로 다른 관점의 자료입니다.

순위 상단이라는 이유로 안전하거나 유리한 거래라고 표현하지 않습니다. 통계는 관측한 기간의 요약이며 이후 실행 가격·거래 비용·가격 방향을 보장하지 않습니다. 화면 설명에서 관측과 추천을 분리해야 합니다.

비교를 재현할 수 있게 기록

보고서에는 사용한 windowSize, 실제 O·C, 단위, 심볼 집합, 제외 기준을 남길 수 있습니다. 숫자만 저장하면 나중에 왜 순위가 바뀌었는지 설명하기 어렵습니다. 원본 통계와 파생 순위 결과를 구분하는 것이 좋습니다.

자료를 수정하거나 누락 구간을 복구했다면 보고서 버전이나 갱신 시각을 남깁니다. 조용히 과거 숫자를 바꾸면 같은 보고서를 다시 읽는 사용자가 다른 결과를 보게 됩니다. 분석 목적에 맞는 수정 정책을 미리 정하세요.

8. 저장과 재연결 설계

개별 심볼 이동 통계를 최신 상태로 저장할 때는 이전 메시지의 v·q·n에 새 값을 더하지 않습니다. 각 메시지가 나타내는 현재 구간의 통계를 갱신하는 방식으로 읽어야 합니다. 이력 로그를 남기는 경우에도 행별 값이 서로 겹친다는 사실을 유지해야 합니다.

연결 중단 후 새 통계를 받으면 현재 구간 상태는 관찰할 수 있지만 중단 동안의 모든 통계 갱신 이력이 자동 복원됐다고 볼 수는 없습니다. 현재 상태 복구와 과거 이력 완성은 다른 요구입니다. 필요한 목적에 따라 누락을 표시해야 합니다.

상태와 로그의 목적

최신 상태 저장소는 현재 화면에 필요한 값을 제공하고, 원본 로그는 시간에 따른 통계 변화를 조사하는 데 사용됩니다. 원본 로그의 모든 v를 합산하는 것은 총 거래량 계산이 아닙니다. 자료 집합의 중첩을 이해한 분석만 수행해야 합니다.

진행 상태에는 마지막 수신과 마지막 저장을 구분할 수 있습니다. 수신은 성공했지만 저장이 실패한 경우를 연결 성공 하나로 감추지 않습니다. 오류와 미준비를 정상적인 0 통계로 바꾸지 않는 것이 중요합니다.

오래된 값의 처리

연결이 끊겼는데 이전 값을 현재 통계처럼 보여주면 사용자가 시점을 오해할 수 있습니다. 마지막 갱신 시각과 연결 상태를 드러내는 것이 좋습니다. 임의로 0으로 초기화하는 것도 실제 시장 변화처럼 보일 수 있으므로 상태 표시와 숫자를 구분하세요.

재연결 후 대상 심볼과 windowSize가 맞는 새 메시지를 확인합니다. 다른 구간의 데이터를 받았다고 준비 완료로 처리하지 않습니다. 구독 성공 응답, 실제 데이터 수신, 저장 성공을 각각 검증해야 합니다.

9. 오류 진단과 검증

가상 자료로 같은 심볼의 v가 증가하는 경우와 감소하는 경우를 모두 넣어 보세요. 감소를 무조건 에러로 막지 않는지 확인합니다. 1h와 4h 메시지를 번갈아 넣어 저장 키가 분리되는지도 검증할 수 있습니다.

전체 시장 배열에서 한 심볼만 갱신된 경우 다른 심볼이 삭제되지 않는지 확인합니다. 처음 받지 못한 심볼과 이전 상태가 있는 심볼을 구분하는지도 살펴야 합니다. 이런 검증은 특정 전략 성과가 아니라 자료 의미를 유지하기 위한 절차입니다.

10. 겹치는 구간을 장부로 확인하기

이동 통계를 검산할 때는 숫자 하나보다 포함 구간을 그려 보는 것이 좋습니다. 아래는 개념 설명을 위해 단순화한 가상 관측입니다. 실제 스트림에서는 O의 분 경계와 C의 현재 시각 규칙을 함께 확인해야 하며 이 표를 모든 payload의 정확한 경계로 대체하지 않습니다.

세 관측은 대부분 겹칩니다. 100+98+105를 더한 303이 세 시간 거래량이 아닙니다. 첫 관측의 앞쪽 일부가 다음 관측에서 빠지고 뒤쪽 새 구간이 들어옵니다. 겹치는 자료를 독립 표본처럼 합산하지 않는 원칙을 확인할 수 있습니다.

차이값에 포함되는 두 효과

첫째에서 둘째로 거래량이 2 줄었다고 해서 새로 발생한 거래량이 -2라는 뜻은 아닙니다. 새로 들어온 거래량과 빠져나간 오래된 거래량의 효과가 함께 포함될 수 있습니다. 차이만으로 두 효과를 각각 복원할 수 있다고 가정하지 않습니다.

예를 들어 새 구간에 3이 들어오고 오래된 구간에서 5가 빠지면 순변화는 -2입니다. 이것은 가능한 가상 설명이며 실제 원인을 확인한 것은 아닙니다. 원인을 분석하려면 해당 구간의 더 세밀한 거래 자료와 완전성을 확인해야 합니다.

가격 변화율도 기준이 이동

마지막 가격 c가 같더라도 구간 시작 가격 o가 달라지면 변화량과 변화율이 바뀔 수 있습니다. 결과 숫자가 움직였다는 이유로 마지막 가격에 새로운 급변이 있었다고 단정하지 않습니다. p·P·o·c와 O·C를 함께 읽어야 합니다.

이 관계를 이해하면 차트의 최근 가격이 평평한데 이동 변화율 순위가 바뀌는 상황도 설명할 수 있습니다. 통계 기준이 움직이는 효과와 실제 최신 가격 변화를 구분하는 것이 중요합니다. 순위 변화의 원인을 하나의 거래로 단정하지 않습니다.

11. 전체 시장 캐시 갱신 연습

초기 상태에서 심볼 A와 B의 통계를 받은 뒤 다음 배열에는 A만 들어왔다고 가정합니다. 공식 의미에 따라 변경된 ticker만 전달된 상황이라면 A를 갱신하고 B를 이번 배열에서 빠졌다는 이유만으로 삭제하지 않아야 합니다. 동시에 B의 마지막 갱신 시각을 유지해 최신성을 판단할 수 있어야 합니다.

처음부터 한 번도 받지 못한 심볼 C는 B와 상태가 다릅니다. B는 이전 관측이 있고 C는 아직 준비되지 않았습니다. 둘을 모두 값 0으로 표현하면 수신 상태와 시장 통계가 섞입니다. 화면에서 미준비 상태를 명확히 구분하는 것이 좋습니다.

캐시 키의 구성

같은 심볼 A의 1h와 4h를 별도 키로 저장합니다. 시장·환경·자료 종류까지 구분하면 다른 제품의 비슷한 이름도 섞이지 않습니다. 심볼 문자열 하나만 키로 사용하면 마지막으로 도착한 다른 window가 앞선 값을 덮어쓸 수 있습니다.

캐시를 파일에서 복원했다면 현재 연결에서 새로 받은 자료인지 과거 저장본인지 표시해야 합니다. 파일을 읽었다는 사실만으로 실시간 준비가 끝난 것이 아닙니다. 저장 시각과 실제 통계 C, 현재 수신 상태를 구분하세요.

순위 계산 대상 집합

순위는 어떤 심볼을 포함했는지에 따라 달라집니다. 일부 자료가 미준비이거나 오래됐다면 전체 시장 순위라는 표현이 정확한지 검토해야 합니다. 필요한 최신성 기준을 정하고 제외한 심볼 수나 이유를 기록할 수 있습니다.

동일 quote 자산만 비교하는지, 환산을 수행했는지도 명시해야 합니다. 환산 가격을 사용하는 경우 그 가격의 시각과 출처가 또 다른 가정입니다. 여러 자료를 결합할수록 결과의 정의를 설명하는 일이 중요해집니다.

12. 평균 가격과 구간 수량의 관계

w는 공식 메시지에서 가중 평균 가격으로 설명됩니다. 이 값을 o와 c의 산술 평균이나 고가·저가의 중간값과 같은 것으로 취급하지 않습니다. 같은 구간이라도 거래가 어느 가격에 얼마나 집중됐는지에 따라 평균의 의미가 달라질 수 있습니다.

직접 q÷v를 계산해 대조한다면 단위, 구간 일치, 정밀도와 v=0 조건을 먼저 확인해야 합니다. 계산 결과가 다를 때 원본 필드를 임의로 고쳐 맞추지 않습니다. 자료 규격과 반올림, 수집 시점 차이를 확인한 뒤 설명할 수 있는 범위만 판단해야 합니다.

표본 수가 적은 구간

거래가 적은 구간의 변화율은 몇 건의 거래에 크게 영향을 받을 수 있습니다. 변화율 숫자만 크게 표시하면 거래량과 표본의 한계를 놓치기 쉽습니다. n·v·q를 함께 살펴볼 수 있지만 그것만으로 시장의 모든 유동성을 알 수 있는 것은 아닙니다.

n은 거래 건수이지 해당 구간에 참여한 고유 사람 수가 아닙니다. 공개 자료만으로 투자자 수나 개인별 의도를 복원한다고 설명하지 않습니다. 통계 필드의 이름과 실제 의미를 일치시키는 것이 중요합니다.

관측 결과의 보고 방식

"최근 1h 설정, 실제 O부터 C까지, quote 자산 기준 거래량"처럼 범위를 드러내면 숫자가 무엇을 나타내는지 이해하기 쉽습니다. 여기에 마지막 수신 시각과 자료 상태를 더하면 오래된 값을 현재 값으로 오해하는 것을 줄일 수 있습니다.

동일 정의로 반복 계산한 결과끼리 비교해야 합니다. 중간에 windowSize·심볼 집합·환산 방식·최신성 기준을 바꿨다면 변경점을 표시합니다. 설명 없이 계산 정의를 바꾸고 시계열을 이어 붙이면 시장 변화와 방법 변경이 섞일 수 있습니다.

13. FAQ

Q1. Rolling Window는 오늘 자정 이후 통계인가요?

그렇게 단정할 수 없습니다. 갱신 시점을 따라 움직이는 구간입니다. 실제 O·C와 스트림 종류를 확인해야 합니다.

Q2. 지원되는 구간은 무엇인가요?

이 글의 현물 WebSocket 문서는 1h·4h·1d를 안내합니다. REST나 다른 제품의 지원 범위와 혼동하지 않습니다.

Q3. 1h는 항상 정확히 같은 길이인가요?

공식 문서는 O가 분 경계에 맞춰져 실효 구간이 설정값보다 최대 59,999ms 더 넓을 수 있다고 설명합니다. 실제 O·C를 확인해야 합니다.

Q4. O와 E는 같은 시각인가요?

O는 통계 시작 시각, E는 이벤트 시각입니다. C는 통계 종료 시각입니다. 로컬 수신 시각까지 각각 구분해야 합니다.

Q5. 거래량이 줄면 데이터 오류인가요?

오래된 거래가 범위 밖으로 빠지면서 줄어들 수 있습니다. 항상 증가하는 누적 카운터처럼 처리하지 않습니다. 실제 원인은 자료와 범위를 확인해야 합니다.

Q6. 메시지마다 v를 더하면 총 거래량인가요?

대부분 겹친 구간이므로 중복 합산이 됩니다. 현재 통계 상태를 갱신하는 것과 독립적인 거래량 누적을 구분해야 합니다.

Q7. 1h와 4h를 합치면 5시간인가요?

구간이 겹치므로 그렇게 합산할 수 없습니다. 비중복 구간이라는 조건 없이 거래량을 더하지 않습니다.

Q8. 기본 ticker와 같은 스트림인가요?

공식 문서는 {symbol}@ticker와 이 이동 구간 스트림을 구분합니다. 이름과 경계 규칙을 확인하고 같은 파서·정의를 무조건 적용하지 않습니다.

Q9. p는 현재 가격인가요?

이 자료에서 p는 가격 변화입니다. Trade Stream의 p와 의미가 다릅니다. 마지막 가격 c와 구분해야 합니다.

Q10. 전체 시장 배열에 없으면 삭제된 심볼인가요?

공식 문서는 변경된 ticker만 배열에 포함된다고 설명합니다. 이번 배열에 없다는 사실만으로 삭제·거래량 0을 확정하지 않습니다.

Q11. v로 모든 코인의 거래량 순위를 만들 수 있나요?

서로 다른 기초 자산 단위를 그대로 비교하면 의미가 불분명해집니다. 비교 단위와 범위를 명확히 해야 합니다. q도 quote 자산이 다르면 환산 기준이 필요합니다.

Q12. 높은 변화율이면 좋은 매수 기회인가요?

관측 기간의 통계만으로 미래 가격이나 유리한 체결을 보장할 수 없습니다. 거래량·유동성·비용 등 다른 조건도 있으며 이 글은 투자 추천이 아닙니다.

Q13. 재연결하면 중단 기간 통계가 모두 복구되나요?

새 현재 통계 수신과 과거 모든 갱신 이력 복원은 다릅니다. 필요한 이력 범위와 누락 상태를 별도로 관리해야 합니다.

Q14. 캔들과 값이 다르면 어느 쪽을 고치나요?

먼저 집계 경계와 자료 종류를 맞춥니다. 다른 구간의 값은 달라도 정상일 수 있습니다. 숫자를 같게 만들기 위해 원본을 수정하지 않습니다.

Q15. 첫 검증에서 무엇을 확인하나요?

O·C·E와 필드 대소문자, 겹친 값의 비누적 처리, 전체 시장 배열의 부분 갱신을 확인합니다. 이후 단위·최신성·재연결 상태를 점검하세요.

14. 운영 체크리스트

• 현물 WebSocket의 해당 스트림을 확인했다.
• 1h·4h·1d와 갱신 주기를 구분한다.
• 기본 ticker와 이동 구간 스트림을 구분한다.
• O·C로 실제 집계 범위를 기록한다.
• 분 경계와 실효 구간의 차이를 이해한다.
• p·P·o·O·c·C 대소문자를 보존한다.
• v·q의 단위를 구분한다.
• 연속 이동 구간 거래량을 합산하지 않는다.
• 1h와 4h를 독립 구간처럼 더하지 않는다.
• 거래량 감소를 자동 오류로 분류하지 않는다.
• 전체 시장 배열을 변경된 심볼 갱신으로 처리한다.
• 미수신·오래된 상태를 0 통계와 구분한다.
• 심볼·windowSize별 최신성을 확인한다.
• 관측 순위를 미래 수익 보장으로 표현하지 않는다.

핵심 정리

바이낸스 Rolling Window Statistics를 읽을 때 가장 중요한 질문은 "얼마나 변했나"보다 "어느 구간을 집계했나"입니다. 실제 경계와 단위를 확인하고 겹친 자료를 반복 합산하지 않아야 가격·거래량 비교가 의미를 가집니다.

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