바이낸스 Kline Data 뜻 2026｜OHLC·캔들 마감·거래량·시간대 읽기

바이낸스 Kline Data 뜻 2026｜OHLC·캔들 마감·거래량·시간대 읽기

바이낸스 Kline Data는 정해진 시간 구간의 가격과 거래량을 캔들 형태로 요약한 자료입니다. 개별 체결을 한 줄씩 보는 Trade Stream이나 현재 대기 수량을 보는 Depth와 다릅니다. 시간 구간 안에서 어떤 가격이 처음·마지막·최고·최저였는지, 얼마나 거래됐는지 살펴보는 자료입니다.

실시간 캔들은 아직 끝나지 않은 구간을 반복 갱신합니다. 같은 캔들의 값이 여러 번 바뀌는 것은 정상일 수 있으며, 메시지를 받을 때마다 새 캔들로 추가하거나 거래량을 계속 더하면 잘못된 차트가 됩니다. 캔들 식별자와 마감 여부를 이해하는 것이 중요합니다.

이 글은 2026년 10월 29일 확인한 Binance Spot WebSocket 공식 문서의 Kline/Candlestick Streams를 중심으로 설명합니다. 현물 UTC 및 UTC+8 스트림을 구분하며 선물·지수·마크 가격 캔들에 같은 규칙을 자동 적용하지 않습니다. 숫자 사례는 가상 자료입니다.

1. OHLC의 기본 의미

O는 구간의 시작 가격인 open, H는 high, L은 low, C는 close를 뜻하는 일반적인 캔들 표기입니다. 현물 스트림의 k 객체에서는 소문자 o·h·l·c로 해당 값을 읽습니다. 캔들이 아직 진행 중이면 c는 그 시점까지의 최신 값으로 바뀔 수 있습니다.

캔들 한 개는 구간의 요약입니다. 같은 OHLC를 가진 두 구간이라도 내부의 거래 순서는 다를 수 있습니다. 고가를 먼저 찍었는지 저가를 먼저 찍었는지, 어떤 가격에서 얼마나 거래됐는지 모두 복원할 수 있는 것은 아닙니다.

시가와 전 캔들 종가

시가는 해당 캔들 구간의 open 값이고 이전 캔들 종가와 개념이 다릅니다. 두 값이 항상 같아야 한다고 강제하는 검증 규칙을 임의로 만들지 않습니다. 자료 종류와 실제 거래 상황을 확인해야 합니다.

차트의 모양만 보고 원본 값을 고쳐서는 안 됩니다. 예상과 다르다면 대상 심볼·구간·시간대·캔들 마감 여부와 원본 메시지를 먼저 확인해야 합니다. 시각적으로 자연스럽게 만들기 위해 데이터를 바꾸면 분석의 근거가 사라집니다.

고가·저가와 전체 경로

고가와 저가는 구간의 극값을 요약하지만 그 사이의 모든 가격 경로를 보여주지는 않습니다. 캔들만으로 특정 손절·익절 가격이 어떤 순서로 닿았는지 확정할 수 없는 상황이 있습니다. 백테스트에서 이런 순서를 임의로 유리하게 가정하면 결과가 왜곡될 수 있습니다.

더 세밀한 순서가 필요하면 목적에 맞는 개별 체결 등 다른 자료가 필요합니다. 더 작은 캔들로 바꾸어도 그 구간 안의 모든 사건 순서가 자동 복원되는 것은 아닙니다. 자료의 해상도와 분석 요구를 함께 고려해야 합니다.

2. 스트림 이름과 interval

현물 UTC 캔들 스트림 이름은 {symbol}@kline_{interval}입니다. 공식 문서는 1s, 1m, 3m, 5m, 15m, 30m, 1h, 2h, 4h, 6h, 8h, 12h, 1d, 3d, 1w, 1M을 안내합니다. m은 분이고 M은 월이므로 대소문자를 바꾸면 의미가 달라집니다.

공식 Update Speed 항목은 1s interval에 1000ms, 나머지 interval에 2000ms를 안내합니다. 캔들 길이와 메시지 갱신 주기는 다른 값입니다. 1분 캔들을 구독한다고 메시지를 반드시 1분에 한 번만 받는 것이 아닙니다.

캔들 길이와 갱신 간격

1m은 한 캔들이 요약하는 구간의 길이를 뜻합니다. 구간이 끝나기 전에도 현재 캔들의 고가·저가·종가·거래량 등이 갱신될 수 있습니다. 받은 메시지 수를 캔들 수로 세면 진행 중인 한 캔들을 여러 개로 잘못 셀 수 있습니다.

갱신 속도는 서버가 자료를 제공하는 방식에 관한 문서상 안내입니다. 네트워크와 클라이언트 처리 때문에 실제 도착 간격은 달라질 수 있습니다. 갱신 간격과 투자 판단의 정확도 또는 수익성을 연결하지 않습니다.

월과 고정 시간 길이

1M은 월 단위라는 의미이며 모든 월이 같은 일수라고 가정해 고정 초 수를 곱하지 않습니다. 날짜·구간 경계는 공식 시간 규칙과 반환된 시각을 기준으로 읽어야 합니다. 시간 계산을 단순 문자열 치환으로 처리하면 월말과 주 경계에서 문제가 생길 수 있습니다.

내부 데이터셋에는 interval을 문자열 그대로 보존하고 구간 시작·종료 시각을 함께 기록하는 편이 좋습니다. 표시 이름만 "분봉"으로 저장하면 정확히 몇 분인지, 어떤 시간대의 경계인지 나중에 알기 어렵습니다.

3. k 객체의 주요 필드

스트림의 최상위에는 이벤트 종류 e, 이벤트 시각 E, 심볼 s가 있고 실제 캔들 자료는 k 객체에 들어갑니다. combined stream을 사용하면 그 바깥에 stream·data 포장이 추가됩니다. 어느 단계의 객체를 읽는지 명확히 해야 합니다.

같은 글자라도 자료마다 의미가 다름

Trade Stream의 t는 거래 ID이지만 Kline의 k.t는 캔들 시작 시각입니다. 이런 차이 때문에 모든 메시지를 공통 필드 이름만으로 처리하는 파서는 위험할 수 있습니다. 이벤트 종류와 객체 경로를 함께 확인해야 합니다.

최상위 E와 k.T도 서로 다른 시각입니다. E는 이벤트 시각, k.T는 구간 종료 시각입니다. 도착 지연을 계산하면서 k.T를 이벤트 발생 시각처럼 사용하는 경우 진행 중 캔들에서는 이상한 결과가 나올 수 있습니다.

수량 필드의 대소문자

v와 V는 전체 기초 자산 거래량과 taker buy 기초 자산 거래량을 구분합니다. q와 Q도 같은 관계에서 quote 자산 거래량을 구분합니다. 키를 모두 소문자로 바꾸면 전체와 부분 수량이 충돌할 수 있습니다.

taker buy 수량은 전체 거래량에 추가로 더하는 별도 시장 거래량이 아닙니다. 전체 안에서 특정 방향으로 분류한 값입니다. 전체 v에 V를 더해 총량이라고 부르면 중복 계산이 됩니다.

4. x=false와 x=true

x는 캔들이 마감됐는지 알려주는 필드입니다. false인 메시지는 진행 중인 구간의 갱신으로 읽고 true인 메시지는 마감 상태로 읽습니다. 로컬 시계가 다음 분으로 넘어갔다고 원본 마감 표시를 무시해서는 안 됩니다.

네트워크 지연으로 마감 메시지가 늦게 도착할 수 있습니다. 반대로 화면의 시계와 거래소 시각에 오차가 있을 수도 있습니다. 캔들 상태를 판단할 때 메시지의 구간 식별자와 x를 함께 사용하는 것이 중요합니다.

진행 중 거래량은 누적 증가분이 아님

같은 캔들에서 v가 10인 메시지 다음에 v가 12인 메시지가 왔다면 구간 거래량이 12로 갱신된 것으로 읽어야 합니다. 10과 12를 더해 22로 만드는 것은 같은 구간 누적값을 중복 더하는 오류입니다.

필요에 따라 두 갱신 사이의 차이를 계산할 수는 있지만 그것은 클라이언트가 정의한 파생 값입니다. 재연결·중복·누락·순서 문제를 고려하지 않고 차이값을 실제 모든 개별 체결로 취급하지 않습니다. 원본 캔들 상태와 파생 변화량을 분리하세요.

식별 키를 명확히

캔들을 저장할 때 시장·심볼·interval·시간대 기준·시작 시각을 구분할 수 있습니다. 같은 시작 숫자라도 다른 interval이나 다른 시장 자료가 같은 캔들이 되는 것은 아닙니다. 같은 키의 갱신과 새로운 구간 생성을 나누어 처리해야 합니다.

마감된 캔들을 기준으로 분석한다면 진행 중 자료가 계산에 섞이지 않도록 정책을 정합니다. 실시간 화면은 진행 중 값을 보여줄 수 있지만 보고서에서 확정 값처럼 표시하지 않도록 상태를 드러내야 합니다.

5. 다섯 가지 캔들 처리 사례

예시 1. 같은 분봉이 여러 번 갱신

같은 시작 시각의 1m 캔들에서 c가 100, 101, 100.5로 차례로 바뀌었다고 가정합니다. 이것은 세 개의 새 분봉이 아니라 같은 진행 구간의 갱신일 수 있습니다. 저장 키와 x를 확인해 한 캔들의 현재 상태를 갱신해야 합니다.

각 갱신을 모두 이력으로 남길 수는 있지만 그 이력 행 수를 캔들 수로 보고하면 안 됩니다. 원본 갱신 로그와 최종 캔들 테이블은 목적이 다릅니다. 차트에 어느 자료를 사용하는지도 명확히 해야 합니다.

예시 2. 거래량을 중복 합산

한 캔들의 v가 3, 7, 10으로 갱신됐다면 마지막 상태의 전체 거래량은 10입니다. 세 값을 더한 20이 아닙니다. 이 오류는 실시간 업데이트를 개별 거래처럼 처리할 때 발생할 수 있습니다.

가상 입력으로 같은 키를 반복 전달해 최종 값이 10인지 확인합니다. 같은 메시지를 두 번 전달해도 거래량이 늘어나지 않아야 합니다. 진행 중 상태와 마감 상태를 각각 넣어 업데이트 정책을 검증하세요.

예시 3. 마감 전 가격을 확정값으로 사용

진행 중 c=105를 보고 분석했는데 마감 메시지에서는 c=102가 됐다고 가정합니다. 진행 중 가격이 바뀐 것으로 볼 수 있으며 그 자체로 자료 오류는 아닙니다. 마감 기준 전략이나 보고서에 105를 확정 종가처럼 저장하면 기준이 달라집니다.

분석 시점에 알 수 있었던 정보와 나중에 확정된 정보를 구분해야 합니다. 과거 분석에서 최종 고가·저가·종가를 구간 시작부터 알았던 것처럼 사용하면 미래 정보를 섞는 문제가 생깁니다. 자료의 가용 시점을 기록하는 것이 중요합니다.

예시 4. 같은 날짜의 일봉이 다름

UTC 기준 일봉과 UTC+8 기준 일봉은 구간 경계가 다릅니다. 같은 달력 날짜처럼 표시되어도 포함된 체결 범위가 다를 수 있습니다. OHLC와 거래량 차이가 있다는 이유만으로 어느 한 자료가 잘못됐다고 단정하지 않습니다.

비교 전에 시장·심볼·interval·경계 시간대를 맞춥니다. 화면 표시만 한국시간으로 바꾼 것과 실제 캔들 집계 경계를 바꾼 것은 다릅니다. 이 둘을 구분해야 일봉 비교가 의미를 가집니다.

예시 5. taker buy와 전체 거래량

가상의 v=10, V=6이라면 전체 기초 자산 거래량 안에서 taker buy 수량이 6인 관계로 읽습니다. 전체를 16으로 더하지 않습니다. 같은 단위와 동일 구간이라는 조건을 확인한 뒤 부분과 전체의 관계를 해석해야 합니다.

q와 Q는 quote 자산 단위이므로 v·V와 직접 더하지 않습니다. 비율을 만들 때도 분자와 분모의 단위를 맞추고 분모 0을 처리해야 합니다. 방향 비중이 크다는 사실만으로 이후 가격을 보장하지 않습니다.

6. UTC와 UTC+8 경계

기본 UTC 스트림과 시간대 오프셋 스트림은 구분됩니다. 공식 UTC+8 스트림 이름은 {symbol}@kline_{interval}@+08:00 형태입니다. 문서는 일봉 등을 UTC+8의 시작과 끝에 맞춰 집계한다고 설명합니다.

그러나 payload의 E·t·T 같은 Unix timestamp를 UTC+8 숫자로 바꿔 읽는다는 뜻은 아닙니다. 공식 문서는 이 타임스탬프가 UTC로 해석되는 절대 시각임을 명시합니다. 구간 경계 시간대와 타임스탬프 표현을 분리해야 합니다.

화면 표시 시간대와 집계 시간대

UTC 일봉을 한국시간으로 표시하면 시작 시각이 한국 달력에서 다르게 보일 수 있습니다. 이것은 표시 변환이지 원본 캔들이 한국시간 자정 기준으로 다시 집계됐다는 뜻은 아닙니다. UI에서 시간대 이름을 보여주면 혼동을 줄일 수 있습니다.

자체적으로 한국시간 경계의 구간을 만들고 싶다면 어떤 원본 자료에서 어떻게 재집계할지 별도 정의가 필요합니다. 이미 요약된 캔들 몇 개를 아무 조건 없이 합쳐 정확한 원하는 구간이 된다고 가정하지 않습니다. 구간 정렬과 원본 해상도를 확인해야 합니다.

시간 단위 선택

공식 일반 규칙은 기본 밀리초와 선택적 마이크로초 설정을 안내합니다. 연결 설정과 저장 단위를 일치시켜야 합니다. 한 번 변환한 값을 다시 변환하거나 숫자 자릿수만 보고 임의 처리하지 않습니다.

원본 시각, 표준 저장 시각, 표시 문자열을 별도로 관리하면 변환을 추적하기 쉽습니다. 특히 날짜 경계·주 경계·월 경계는 가상 사례로 검증해야 합니다. 시스템 시계 설정과 캔들 집계 규칙이 같은 것이라고 생각하지 않습니다.

7. REST 자료와 실시간 갱신 연결

과거 캔들을 REST로 받고 현재 구간은 스트림으로 갱신하는 구조를 사용할 수 있습니다. 다만 REST와 스트림의 응답 모양이 같다고 가정해서는 안 됩니다. 현재 공식 REST 문서의 배열 순서·파라미터·구간 규칙을 확인한 뒤 내부 표준 구조로 변환해야 합니다.

두 경로가 같은 캔들을 포함하는 겹침은 자연스럽게 발생할 수 있습니다. 겹침 자체를 피하려고 임의로 한 구간을 건너뛰기보다 식별 키를 기준으로 같은 캔들인지 확인하는 것이 중요합니다. 데이터셋 범위와 구간 경계가 같아야 비교할 수 있습니다.

마지막 캔들의 상태

과거 목록의 마지막 항목이 언제나 마감된 구간이라고 가정하지 않습니다. 요청 시점과 자료 범위를 확인해야 합니다. 실시간 스트림의 x와 연결할 때는 같은 심볼·interval·시작 시각인지 먼저 확인합니다.

구간이 같아 보여도 시간대 기준이 다르면 다른 자료일 수 있습니다. UTC와 UTC+8을 섞어 저장하면 하루 경계에서 값이 덮어써질 위험이 있습니다. 키에 집계 기준을 포함하는 이유입니다.

복구 완료의 기준

재연결 뒤 새 캔들 하나를 받았다고 중단 기간의 모든 구간이 복구된 것은 아닙니다. 마지막 저장된 구간과 현재 구간 사이에 무엇이 빠졌는지 확인해야 합니다. 조회 제한과 반환 범위 때문에 여러 번의 확인이 필요할 수 있습니다.

누락된 캔들을 0 거래량·이전 종가로 자동 채우는 것은 별도의 보간 정책입니다. 실제 거래소 원본처럼 표시해서는 안 됩니다. 원본·보간·미확인 상태를 구분하면 분석 결과의 한계를 설명할 수 있습니다.

8. 거래량과 평균을 해석하는 기준

v는 기초 자산 거래량, q는 quote 자산 거래량입니다. 같은 구간에서 q를 v로 나누는 산술 관계를 검토할 수 있지만 v=0 처리와 자료 정의를 확인해야 합니다. 캔들의 c나 (o+h+l+c)/4와 같은 임의 평균이 실제 수량 가중 평균과 같은 값은 아닙니다.

특정 파생 값을 사용한다면 계산식을 명시해야 합니다. 여러 캔들의 종가를 단순 평균한 값과 구간 전체 거래 금액을 전체 수량으로 나눈 값은 서로 다를 수 있습니다. 평균이라는 이름만으로 같은 지표라고 비교하지 않습니다.

캔들 거래량과 호가 수량

거래량은 구간 동안 실제 거래된 흐름이고 호가 수량은 관측 시점에 제시된 상태입니다. 둘은 단위가 같은 자산 수량처럼 보여도 시간적 의미가 다릅니다. 특정 순간의 호가 수량과 한 시간 거래량을 같은 종류의 재고처럼 더하지 않습니다.

함께 분석할 때는 어느 시점의 호가와 어느 기간의 거래량을 비교하는지 적어야 합니다. 자료의 시점과 범위를 명시하지 않으면 숫자가 큰 쪽을 강한 수요로 잘못 해석할 수 있습니다.

표본 구간 변경

1분 캔들과 1시간 캔들은 관찰 해상도가 다릅니다. 짧은 구간의 극값을 더 긴 구간으로 합칠 때 시가·종가·최고·최저·거래량 각각의 규칙이 다르다는 점을 이해해야 합니다. 모든 필드를 단순 평균하는 방식은 적절하지 않습니다.

재집계에는 구간이 정확히 정렬되고 원본이 완전하다는 조건도 필요합니다. 중간 분봉이 빠졌다면 긴 구간의 결과도 불완전할 수 있습니다. 계산이 가능하다는 사실과 원본에 충실한 결과라는 사실을 구분하세요.

9. 오류 진단 표

가상 메시지로 같은 캔들의 반복 갱신, 마감 전후, 다음 구간 전환, 늦게 도착한 마감 메시지를 시험합니다. 수신 순서와 저장 정책이 맞는지 확인하고, 중복 입력이 거래량을 늘리지 않는지 검증하세요.

차트 렌더링과 데이터 저장을 별도로 확인하는 것도 중요합니다. 화면에는 정상처럼 보이지만 내부에 같은 구간이 여러 행으로 저장될 수 있습니다. 반대로 저장은 올바른데 시간대 표시만 잘못될 수도 있습니다. 원본부터 표시까지 단계별로 비교하세요.

10. 진행 중 캔들 저장을 직접 검산

같은 시작 시각의 가상 1분 캔들을 세 번 받았다고 가정합니다. 아래 표는 실제 시장 자료가 아니라 업데이트 규칙을 확인하기 위한 입력입니다. 시가가 100인 동일 구간을 관찰하며 마지막 메시지에서 마감됐다고 가정합니다.

최종 캔들은 시가 100, 고가 103, 저가 98, 종가 99, 거래량 8입니다. 거래량을 2+5+8=15로 계산하지 않습니다. 고가를 세 값의 평균으로 구하지도 않습니다. 각 갱신이 같은 구간의 현재 요약이라는 의미를 유지해야 합니다.

같은 키 갱신과 다음 키 생성

세 메시지의 시장·심볼·interval·시작 시각·시간대 기준이 같다면 같은 캔들 상태를 갱신하는 관계입니다. 다음 구간의 시작 시각이 들어오면 새로운 캔들입니다. 단순히 메시지 도착 횟수나 로컬 분 변화만으로 키를 만들지 않습니다.

원본 갱신 이력을 보관하고 싶다면 별도 로그를 만들 수 있습니다. 그러나 최종 캔들 테이블에는 같은 구간이 중복되어 합산되지 않아야 합니다. 이력과 최종 상태를 분리하면 마감 전 어떤 값이 보였는지도 추적할 수 있습니다.

마감 메시지의 재수신

동일한 마감 메시지를 다시 받았을 때 거래량과 캔들 수가 늘어나지 않는지 확인합니다. 네트워크 재연결이나 자료 병합 과정에서 같은 구간을 다시 처리할 수 있습니다. 같은 입력을 여러 번 적용해도 최종 결과가 일관돼야 합니다.

반대로 같은 키에서 값이 예상과 다르면 조용히 아무 값으로 덮어쓰기보다 출처·시각·자료 종류를 확인할 수 있어야 합니다. UTC와 UTC+8이 섞였는지, 다른 interval인지, 파싱 과정에서 필드가 바뀌었는지 점검합니다. 원인을 확인하지 않고 일치하도록 원본을 수정하지 않습니다.

진행 중 분석과 마감 분석

둘째 갱신에서 c=102를 사용한 판단은 그 시점에 관찰한 정보에 기반합니다. 나중에 종가가 99로 바뀌었다고 당시 입력이 99였던 것처럼 과거 판단을 다시 쓰면 안 됩니다. 실시간 의사결정 기록에는 실제 사용한 자료 버전을 남겨야 합니다.

마감 분석은 x=true를 확인한 값을 사용하도록 정책을 정할 수 있습니다. 어느 방식을 선택하든 결과 이름에 진행 중인지 마감 기준인지 드러내는 것이 좋습니다. 두 방식의 성과나 통계를 같은 조건처럼 비교하지 않습니다.

11. 여러 캔들을 합칠 때의 조건

더 짧은 구간을 더 긴 구간으로 재집계하려면 대상 구간이 정확히 정렬되어야 합니다. 예를 들어 일련의 완전한 짧은 구간을 합친다고 가정하면 시가는 첫 구간의 시가, 종가는 마지막 구간의 종가, 고가는 최대 고가, 저가는 최소 저가라는 일반적인 요약 관계를 검토할 수 있습니다. 모든 가격 필드를 단순 평균하지 않습니다.

거래량은 같은 단위의 비중복 구간을 합산해야 합니다. 같은 캔들의 반복 갱신을 여러 구간처럼 더하면 안 됩니다. 진행 중 구간이 포함됐다면 재집계 결과도 아직 변할 수 있다는 상태를 유지해야 합니다.

누락 구간이 있을 때

중간 구간 하나가 빠졌다면 전체 요약의 고가·저가·거래량이 불완전할 수 있습니다. 나머지 구간만 계산한 결과를 완전한 원본 긴 캔들과 같다고 보장하지 않습니다. 자료 완성도와 빠진 구간을 표시해야 합니다.

누락을 이전 종가로 채웠다면 그 값은 보간 자료입니다. 원본과 별도 구분하고 재계산할 때 어떤 정책을 적용했는지 남깁니다. 연결 장애를 실제 무거래 구간으로 바꾸어 해석하지 않는 것이 중요합니다.

시간대가 다르면 경계도 다름

UTC 기준 자료를 UTC+8 일봉으로 바꾸려면 원하는 구간을 구성할 만큼 충분한 원본 해상도와 범위가 있어야 합니다. 이미 요약된 UTC 일봉 하나의 숫자만으로 다른 경계의 정확한 일봉을 만들 수는 없습니다. 구간 내부 정보가 사라졌기 때문입니다.

표시 시각만 바꾼 자료를 새로운 시간대 기준 캔들로 이름 붙이지 않습니다. 원본 집계 경계와 화면 표시 시간대를 모두 남기면 이 차이를 설명할 수 있습니다. 비교 도구를 만들 때 특히 중요한 구분입니다.

12. 분석 결과에 함께 적을 정보

캔들 기반 보고서에는 시장·심볼·interval·집계 시간대·대상 기간·마감 여부·누락 처리 방식을 적을 수 있습니다. 차트 이미지 하나만으로는 이 조건을 모두 알기 어렵습니다. 같은 모양처럼 보여도 서로 다른 자료일 수 있으므로 재현 가능한 설명이 필요합니다.

가격 정밀도와 거래량 단위도 표시합니다. 기초 자산 거래량과 quote 거래량을 바꿨다면 기존 보고서와 비교할 때 변경점을 알 수 있어야 합니다. 단위를 감춘 채 막대 높이만 비교하면 시장 활동의 의미를 잘못 해석할 수 있습니다.

백테스트에서 주의할 정보 시점

완성된 캔들의 고가·저가·종가를 구간 시작 시점부터 알았던 것처럼 사용하는 것은 실제 관측 순서와 다릅니다. 데이터가 언제 이용 가능했는지 모델링해야 합니다. 이 글은 특정 전략을 제시하지 않지만 자료 시점의 혼동은 어떤 분석에서도 점검해야 할 문제입니다.

캔들 내부의 손절·익절 도달 순서가 불명확하면 그 불확실성을 유지해야 합니다. 유리한 순서를 선택해 수익을 확정하는 방식은 근거가 부족합니다. 더 세밀한 자료를 쓰더라도 수수료·실행 가능성·지연은 별도 검토가 필요합니다.

저장 오류와 표시 오류 구분

원본 t·T는 정상인데 화면 시간만 다르면 표시 변환 문제일 수 있습니다. 반대로 화면은 정상인데 내부에 같은 구간이 중복 저장됐다면 집계 단계에서 문제가 드러날 수 있습니다. 원본·변환·저장·표시를 나누어 검산해야 합니다.

작은 가상 자료를 입력하고 각 단계 결과를 표로 비교하면 원인을 좁힐 수 있습니다. 전체 차트를 다시 그려 보는 것만으로는 중복과 시간대 오류를 발견하기 어려울 수 있습니다. 검증은 최종 이미지뿐 아니라 자료 의미까지 확인하는 과정입니다.

13. FAQ

Q1. Kline은 개별 거래 목록인가요?

시간 구간의 가격·거래량 요약입니다. 구간 안의 모든 거래 순서를 제공하지 않습니다. 세부 체결 순서가 필요하면 목적에 맞는 다른 자료를 검토해야 합니다.

Q2. 1m이면 메시지가 1분에 한 번 오나요?

1m은 캔들 구간입니다. 진행 중 구간도 갱신될 수 있습니다. 공식 Update Speed와 interval을 구분해야 합니다.

Q3. m과 M은 같은가요?

m은 분, M은 월을 뜻합니다. 대소문자를 바꾸면 다른 구간이 됩니다. 저장과 요청에서 원래 표기를 유지하세요.

Q4. x=false는 오류인가요?

진행 중 캔들이라는 뜻입니다. 정상적인 갱신 상태일 수 있습니다. 마감 기준 분석에서는 확정 자료와 구분해야 합니다.

Q5. v가 10에서 12로 바뀌면 합계는 22인가요?

같은 캔들 누적값을 갱신한 것이므로 마지막 상태는 12로 읽습니다. 메시지별 v를 계속 더하면 중복 계산이 됩니다.

Q6. c는 언제나 확정 종가인가요?

진행 중 캔들에서는 바뀔 수 있습니다. 구간 식별자와 x를 함께 확인해야 합니다. 확정값이 필요한 보고서에 진행 중 값을 섞지 않습니다.

Q7. k.t는 거래 ID인가요?

캔들 시작 시각입니다. Trade Stream의 t와 의미가 다릅니다. 이벤트 종류와 객체 경로를 기준으로 해석해야 합니다.

Q8. v와 q는 같은 거래량인가요?

v는 기초 자산, q는 quote 자산 거래량으로 단위가 다릅니다. 단순히 더하거나 같은 축에 표시하지 않습니다.

Q9. V를 v에 더해야 하나요?

taker buy 수량은 전체 거래량 안의 분류입니다. 추가로 더하면 중복 계산이 됩니다. 전체와 부분의 관계를 유지하세요.

Q10. UTC+8 스트림은 timestamp도 8시간 더하나요?

캔들 경계가 UTC+8 기준이라는 뜻입니다. 공식 문서는 Unix timestamp는 UTC로 해석한다고 안내합니다. 원본 숫자를 임의로 이동하지 않습니다.

Q11. 한국시간 표시와 한국시간 일봉은 같은가요?

표시 시간대를 바꾸는 것과 집계 경계를 바꾸는 것은 다릅니다. UTC 일봉을 한국시간으로 보여줘도 원래 포함된 거래 구간은 바뀌지 않습니다.

Q12. OHLC로 고가·저가 도달 순서를 알 수 있나요?

구간 요약만으로 모든 내부 순서를 알 수 없습니다. 백테스트에서 유리한 순서를 임의로 가정하지 않도록 주의해야 합니다.

Q13. 재연결하면 빠진 캔들이 모두 복구되나요?

새 자료 수신과 과거 구간 복구는 다릅니다. 마지막 저장 구간과 실제 반환 범위를 확인하고 누락을 별도로 관리해야 합니다.

Q14. 빈 구간을 이전 종가로 채워도 되나요?

그것은 별도 보간 정책입니다. 실제 원본과 구분해 표시해야 합니다. 오류나 누락을 정상 무거래 구간처럼 숨기지 않습니다.

Q15. 가장 먼저 만들 검증은 무엇인가요?

같은 캔들 갱신이 새 캔들로 추가되지 않는지, v가 중복 합산되지 않는지 확인합니다. 이후 x·시간대·단위·구간 경계를 검증하세요.

14. 체크리스트

• 현물 캔들 자료인지 확인했다.
• interval과 메시지 갱신 주기를 구분한다.
• m·M 대소문자를 보존한다.
• raw·combined·k 객체 경로를 구분한다.
• k.t·k.T·E의 의미를 나누어 저장한다.
• 같은 캔들 갱신과 새 구간을 구분한다.
• 진행 중 v를 반복 합산하지 않는다.
• x=false와 true를 구분한다.
• v·q·V·Q 단위를 확인한다.
• UTC·UTC+8·표시 시간대를 구분한다.
• 원본 시간 단위를 보존한다.
• REST·스트림 겹침을 같은 키로 확인한다.
• 누락·보간·원본 자료를 구분한다.
• 캔들 요약으로 모든 거래 순서를 추측하지 않는다.

핵심 정리

바이낸스 Kline Data를 정확히 사용하려면 캔들 모양보다 구간·상태·단위를 먼저 이해해야 합니다. 같은 구간의 갱신을 올바르게 처리하고, 마감 여부와 시간대를 확인한 뒤 가격과 거래량을 비교하세요.

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