캔들 백필은 최신 파일로 덮어쓰지 말고 전·후 판본을 따로 저장해 거래쌍·간격·버킷 시작시각을 복합키로 비교해야 합니다. 각 봉의 open·high·low·close·volume·거래 수와 원본 파일 SHA-256을 대조해 추가·수정·삭제를 분류합니다. 무거래 구간은 API가 봉을 생략할 수 있으므로 누락과 0거래 봉을 같은 것으로 처리하지 않습니다.
백필 대상 범위를 반열린 구간으로 고정합니다
공지의 거래쌍, 데이터 종류, 시작·종료와 캔들 간격을 UTC로 기록합니다. 경계 중복을 피하려면 내부 비교 범위를 [start,end)처럼 정의하고 API의 inclusive 규칙을 별도로 반영합니다. 한 시간 봉과 하루 봉의 시간대 기준도 확인합니다.
Binance 옵션 kline 문서는 open time이 봉의 고유 식별자라고 설명하며 시작·종료·interval을 받습니다. Coinbase candles는 허용 granularity와 요청당 최대 300개 제한을 둡니다. 긴 범위는 여러 요청으로 나누되 경계 봉이 중복되거나 빠지지 않는지 검증합니다.
백필 검증의 기준키는 행 번호가 아니라 상품·간격·버킷 시작시각입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 백필 대상 범위를 반열린 구간으로 고정합니다
공지의 거래쌍, 데이터 종류, 시작·종료와 캔들 간격을 UTC로 기록합니다.
- 원본 판본과 요청 manifest를 보존합니다
재수집 전에 기존 원본 파일을 읽기 전용 판본으로 보존하고 SHA-256을 계산합니다.
- OHLCV 행을 정규화해 세 종류의 변화를 찾습니다
숫자 문자열의 불필요한 끝 0이나 JSON 공백 차이는 경제적 변경이 아닐 수 있습니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
원본 판본과 요청 manifest를 보존합니다
재수집 전에 기존 원본 파일을 읽기 전용 판본으로 보존하고 SHA-256을 계산합니다. 새 다운로드도 임시 파일에 저장한 뒤 응답 상태, 요청 URL의 비밀 제외 파라미터, 수집 시각, 행 수와 해시를 manifest에 기록합니다. 완료 검증 전 기존 파일을 덮어쓰지 않습니다.
페이지별 start·end와 반환 첫·마지막 open time을 남깁니다. API 200만으로 전체 범위가 왔다고 판단하지 않고 예상 버킷 수와 실제 고유 키 수를 비교합니다. 중복 키가 있으면 값이 같은 중복과 충돌 중복을 분리합니다.
OHLCV 행을 정규화해 세 종류의 변화를 찾습니다
숫자 문자열의 불필요한 끝 0이나 JSON 공백 차이는 경제적 변경이 아닐 수 있습니다. 원문은 보존하되 비교용으로 타임스탬프, open, high, low, close, volume과 거래 수를 정의된 decimal 형식으로 정규화합니다. 필드 순서를 고정해 행 해시를 계산합니다.
구 판본에 없고 신 판본에 있으면 추가, 양쪽에 키가 있으나 행 해시가 다르면 수정, 신 판본에서 사라지면 삭제 후보입니다. 삭제는 즉시 정당한 수정으로 승인하지 않고 공지 범위와 API 결측을 확인합니다.
| 비교 결과 | 분류 | 후속 확인 |
|---|---|---|
| old 없음·new 있음 | 추가 백필 | 공지 범위 일치 |
| 동일 키·값 다름 | 수정 봉 | OHLC·volume 필드차 |
| old 있음·new 없음 | 삭제 후보 | API 누락·범위 경계 |
| 키 중복·값 같음 | 수집 중복 | 페이지 경계 제거 |
| 키 중복·값 다름 | 충돌 | 원천·버전 조사 |
무거래 공백을 누락 데이터로 채우지 않습니다
Coinbase 문서는 거래 tick이 없는 구간에는 데이터가 게시되지 않아 historical rate가 불완전할 수 있다고 명시합니다. 따라서 시간 격자에서 봉이 없다는 사실만으로 백필 실패라고 할 수 없습니다. 제공자의 빈 구간 정책을 기록합니다.
분석용으로 빈 구간을 0 volume과 직전 close로 채우는 선택을 할 수 있지만 이는 원자료가 아니라 파생 변환입니다. 원본 missing 상태와 합성 봉을 구분하고 합성 여부 플래그를 둡니다. 백필 뒤 새 실제 봉이 생기면 기존 합성 봉을 대체하되 변경 이력을 남깁니다.
OHLC 불변식과 거래 자료를 교차검증합니다
각 봉에서 low≤open·close≤high, volume≥0과 버킷 시간 정렬을 검사합니다. volume이 0인데 high·low가 크게 다르거나 거래 수가 음수인 값은 격리합니다. 가격과 수량 decimal 자릿수도 상품 메타데이터와 비교합니다.
변경 규모가 큰 봉은 가능하면 공식 거래 내역을 같은 시간대로 조회해 open 첫 거래, close 마지막 거래, high·low와 volume을 재집계합니다. 집계 규칙이나 거래 데이터 보존 범위 때문에 완전 재현이 불가능하면 그 한계를 기록하고 제3자 데이터로 공식값을 덮어쓰지 않습니다.
- 구·신 원본과 SHA-256, 수집 manifest를 보존합니다.
- 심볼·간격·open time 복합키로 행을 정렬합니다.
- 추가·수정·삭제·중복·충돌 건수를 각각 집계합니다.
- 빈 버킷 정책과 합성 봉 여부를 분리합니다.
- 변경 봉이 수익률·지표·백테스트에 미친 영향을 재계산합니다.
파생 산출물의 오염 범위를 추적합니다
close 한 개가 바뀌면 해당 봉 수익률뿐 아니라 다음 봉 수익률, 이동평균과 변동성 창에도 영향이 이어집니다. volume 수정은 VWAP·거래량 신호를 바꿀 수 있습니다. 변경 봉 목록에서 파생 지표가 참조한 날짜 범위를 계산합니다.
백테스트 결과를 새 판본으로 다시 만들 때 이전 결과를 덮어쓰지 않습니다. data_version과 source hash를 결과에 포함해 어떤 판본이 성과 차이를 만들었는지 확인합니다. 백필 공지는 데이터 개선의 근거이지 과거 전략 성과가 당시 알 수 있었던 값이었다는 근거는 아닙니다.
최종 교체는 전체 재읽기 후 진행합니다
새 파일을 처음부터 끝까지 다시 읽어 키 유일성, 정렬, 예상 범위와 해시를 검증합니다. 부분 다운로드나 마지막 페이지 실패를 성공으로 간주하지 않습니다. 검증 보고서에 원본·신본 해시와 변화 건수를 기록한 뒤 소비자가 새 버전을 선택하게 합니다.
공식 공지에 없는 범위를 전체 수정으로 확대하지 않습니다. 실제 비교에서 공지 밖 변경이 발견되면 오류로 단정하지 않고 별도 조사 대상으로 격리합니다. 다운로드 시각에 따라 추가 정정이 있을 수 있으므로 확인일을 명시합니다.
자주 묻는 질문
파일 SHA-256이 다르면 모든 캔들이 바뀐 건가요?
아닙니다. 포맷이나 일부 행만 달라도 파일 해시는 바뀝니다. 복합키와 정규화 행 해시로 변경 봉을 찾아야 합니다.
시간 격자에 봉이 없으면 0거래 봉을 넣어도 되나요?
원자료와 분리된 파생 처리로만 가능하며, API가 무거래 구간을 생략하는 정책인지 먼저 확인해야 합니다.
백필 뒤 백테스트가 좋아지면 새 결과가 맞나요?
새 판본 기준 결과일 뿐 당시 이용 가능했던 데이터와 다를 수 있습니다. data_version을 표시해 두 결과를 보존해야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
