거래소 정정, 늦은 체결, 심볼 매핑과 휴리스틱 개선으로 과거 시황 데이터가 다시 계산될 수 있다. 대시보드 숫자를 복사해 두고 버전·조회시각을 남기지 않으면 재현이 불가능하다. 따라서 원본 응답 해시, 방법론 버전, 수정 공지와 재수집 범위를 기록한다.
과거 시계열이 고정된 장부가 아닌 이유
거래소는 늦게 도착한 체결을 보내거나 이미 보낸 거래를 정정할 수 있다. 데이터 공급자는 심볼·시장 매핑 오류를 고치고 누락 구간을 백필한다. 파생 지표는 구성시장과 계산 규칙이 바뀌면 과거 전체가 다시 계산될 수 있다.
따라서 9월 1일 값은 날짜 하나만으로 식별되지 않는다. 9월 1일 event를 어느 API 버전과 방법론으로 언제 조회했는지까지 있어야 동일한 데이터 스냅샷이 된다.
과거 날짜가 같아도 조회한 시점과 방법론 버전이 다르면 서로 다른 데이터 제품이다.
JOBCOIN 해설
정정·백필·재계산을 구분한다
정정은 이미 존재한 원천 record의 값 또는 취소 상태가 바뀌는 경우다. 백필은 이전에 없던 record가 늦게 추가되는 경우다. 재계산은 동일 원천을 새로운 방법론으로 다시 집계하는 경우다. 결과 숫자는 모두 바뀌지만 원인과 영향 범위가 다르다.
API의 event time과 database time이 있으면 늦은 수집을 식별하는 단서가 된다. 방법론 변경은 announcement·effective date와 변경된 과거 범위를 확인한다. 공급자 공지가 없으면 diff만으로 원인을 단정하지 않는다.
100에서 104로 바뀐 수정치 계산 예시
교육용 가정으로 9월 1일 거래량을 9월 2일에 수집한 v1 값이 100이고, 늦은 체결 백필 뒤 9월 5일 v2 값이 104라면 수정량은 104-100=4, 수정률은 (104-100)/100×100=4%다. 최신값만 덮어쓰면 당시 기사에서 왜 100을 썼는지 재현할 수 없다.
값이 0에서 3으로 바뀌면 백분율 수정률은 분모가 0이라 계산하지 않는다. null에서 3으로 바뀐 것은 0 거래의 수정이 아니라 결측 해소다. revision 상태에는 old value, new value, first_seen, last_seen과 reason을 별도 열로 둔다.
| 원인 | 예시 | 확인할 기록 |
|---|---|---|
| 늦은 원천 데이터 | 거래소 체결 백필 | event time·database time |
| 원천 정정 | 거래소가 거래 취소·수량 수정 | 공급자 정정 공지 |
| 심볼·시장 매핑 | 토큰 교체나 시장명 병합 | reference data 버전 |
| 방법론 변경 | 구성시장·휴리스틱 재계산 | methodology effective date |
event time과 수집 시각을 분리한다
event time은 거래나 블록이 발생한 시각이고 database time은 공급자가 자료를 저장한 시각이다. 9월 1일 체결이 9월 3일 저장되면 9월 1일 봉이 뒤늦게 바뀔 수 있다. API가 두 시각을 제공한다면 원본 응답에 모두 남긴다.
methodology publication date, announcement date, effective date도 서로 다르다. 변경 문서가 공개된 날과 과거 시계열을 다시 계산한 날을 하나의 날짜로 쓰면 영향 범위를 알 수 없다.
- API 원본 bytes와 SHA-256을 보관한다
- 요청 URL·파라미터·UTC 수집시각을 기록한다
- event time과 database time을 분리한다
- 방법론 문서의 버전·효력일을 저장한다
- 재수집은 원본을 덮어쓰지 않고 새 snapshot으로 추가한다
백필과 방법론 변경의 영향 범위
단일 거래소의 하루 누락을 채운 백필은 일부 시장·기간만 바꿀 수 있다. 반면 reference rate 구성시장 규칙이나 adjusted transfer 휴리스틱이 바뀌면 여러 자산의 전체 과거 구간이 재계산될 수 있다. 수정 건수뿐 아니라 earliest_changed_time과 latest_changed_time을 구한다.
집계 지표는 원천 한 줄 수정이 여러 파생값으로 퍼진다. 체결 정정은 1분봉, 1시간봉, 일봉과 거래량 지표를 모두 바꿀 수 있고, 조정 전송량 변경은 NVT 같은 비율에도 영향을 준다. 파생 데이터 계보를 기록하지 않으면 원인을 역추적하기 어렵다.
두 스냅샷을 안전하게 비교하는 절차
동일한 요청 파라미터로 v1과 v2를 키(asset, market, time) 기준 outer join한다. 추가·삭제·값변경·불변 네 상태로 나누고 소수점 반올림 전에 원문 문자열을 비교한다. schema가 달라졌다면 값 비교 전에 필드 매핑을 검토한다.
수정 보고에는 변경 행 수, 전체 행 수, 최대 절대차, 최대 상대차와 변경 기간을 적는다. 값의 분포가 긴 꼬리를 가지면 평균 차이 하나만 쓰지 않는다. 공개 기사에는 최초 게시값과 현재 수정값을 함께 보여 독자가 변경 시점을 알 수 있게 한다.
Coin Metrics 문서는 데이터가 market·asset 등 여러 수준으로 제공되고 방법론이 시장 선택, 계산 알고리즘, contingency와 recalculation 정책을 포함함을 설명한다. 이 원칙은 특정 수정 원인을 자동 확정하지 않으므로 실제 공지를 확인한 범위만 쓴다.
자주 묻는 질문
어제 저장한 값과 오늘 API 값 중 무엇이 맞나요?
각각 해당 수집시점의 스냅샷일 수 있다. 최신값을 현재 공식값으로 쓸 수 있지만 과거 기사 재현에는 당시 원본과 조회시각을 보존해야 한다.
0이 null로 바뀌면 단순 수정인가요?
0은 관측값이고 null은 데이터 부재 상태다. 값 차이와 상태 변화를 별도로 기록하며 백분율 수정률을 억지로 계산하지 않는다.
수정치가 나오면 기존 파일을 덮어써도 되나요?
재현성을 위해 원본은 보존하고 새 snapshot을 추가한다. 두 버전의 key별 diff와 방법론 효력일을 함께 기록한다.
