백테스트를 실행한 지 6주 뒤, 같은 코드와 설정, 날짜 범위로 다시 실행했습니다. 최종 자산이 달랐습니다. 큰 차이는 아니었지만 Sharpe 비율이 1.31에서 1.08로 바뀌었고, 가장 좋아 보이는 매개변수 세트도 달라졌습니다.
전략은 바뀌지 않았습니다. 과거 데이터가 바뀌었습니다. 공급업체가 며칠치 체결 데이터와 바 데이터를 수정했지만, 첫 실행 때 정확한 입력 스냅샷을 보존하지 않았습니다. 이후 며칠 동안 새 결과가 데이터 수정 때문인지, 파이프라인 버그 때문인지, 아니면 재현할 수 없는 리서치 절차 때문인지 조사했습니다.
월요일: 재실행 결과가 달랐습니다
첫 단서는 유동성이 높은 현물 페어에서 발견한 작은 차이였습니다. 원래 바의 고가는 62,418이었습니다. 재실행 결과에서는 62,431이었습니다. 처음엔 무해해 보였지만 전략의 진입 조건을 살펴보니 임계값이 두 가격 사이에 있었습니다. 바 몇 개만 달라져도 신호가 달라지고, 며칠 뒤 포지션까지 달라졌습니다.
일별 체결 수를 비교해 불일치가 특정 날짜부터 시작된다는 사실을 확인했습니다. 이어 해당 날짜의 원본 행을 비교했습니다. 공급업체가 현재 반환하는 데이터에는 수정된 체결 기록 몇 건과 개정된 집계 바가 들어 있었습니다. 당시 받은 응답에는 변경 로그가 첨부되어 있지 않았습니다.
데이터에서는 흔히 일어나는 일입니다. 거래소는 기록을 바로잡고, 공급업체는 누락된 구간을 채우거나 잘못 기록된 체결을 수정하고 집계 로직을 조정합니다. “1월 데이터”를 요청해도 3월에는 다른 답을 받을 수 있습니다.
화요일: 빠진 수령 기록을 찾았습니다
실행 기록에 공급업체 이름, 심볼, 날짜 범위는 저장했습니다. 하지만 응답 자체나 각 입력 파티션의 콘텐츠 해시는 저장하지 않았습니다. 따라서 어떤 요청을 했는지는 증명할 수 있었지만, 공급업체가 어떤 바이트를 반환했는지는 알 수 없었습니다.
찾을 수 있는 가장 오래된 캐시 파일을 가져와 현재 응답과 비교했습니다. 차이는 분할 조정이나 시간대 변환 때문이 아니었습니다. 소수의 수정된 체결 기록이 바 생성 과정을 거쳐 반영된 결과였습니다. 이로써 한 가지 가설은 배제했지만, 캐시가 불완전해 영향을 받은 모든 바를 정확히 재구성할 수는 없었습니다.
| 기록한 내용 | 답할 수 있었던 질문 | 빠진 내용 |
|---|---|---|
| 공급업체, 심볼, 날짜 범위 | 실행이 어떤 요청을 했는지 | 응답 내용 |
| 파이프라인 버전 | 어떤 코드로 바를 만들었는지 | 정확한 입력 행 |
| 실행 시각 | 작업을 언제 실행했는지 | 당시 이용할 수 있었던 공급업체 데이터 개정본 |
우리는 “같은 쿼리”를 “같은 데이터”로 여겼습니다. 그 가정 때문에 실제보다 실험을 더 재현 가능하게 보이도록 만들었습니다.
수요일: 수정으로 결과 해석이 달라졌습니다
이용할 수 있는 두 버전의 데이터로 문제가 된 날짜들을 재생했습니다. 개정된 바에서는 진입 두 건이 사라졌고 청산 한 건이 1바 늦춰졌습니다. 이 세 거래가 Sharpe 변화의 대부분을 설명했습니다. 전체 가격 시계열은 차트에서 거의 똑같아 보였지만, 전략은 트리거에 가까운 관측값 몇 개에 민감했습니다.
그렇다고 원래 결과가 부정확했다거나 수정된 결과가 무조건 더 낫다는 뜻은 아니었습니다. 결과에 적용 범위를 명시해야 한다는 뜻이었습니다. 이전 실행은 당시 보유한 데이터 스냅샷을 설명했고, 재실행 결과는 공급업체의 현재 과거 데이터를 설명했습니다. 둘 중 하나를 다른 하나의 재현이라고 정직하게 말할 수는 없었습니다.
목요일: 리서치 기록을 바꿨습니다
새 리서치 실행에는 변경할 수 없는 입력 스냅샷을 추가했습니다. 각 파티션에 콘텐츠 해시를 부여하고, 실행 매니페스트에는 출처, 가져온 시각, 스키마 버전, 조정 정책, 변환 코드 버전을 기록합니다. 대용량 데이터셋의 실제 파일은 콘텐츠 주소 지정 스토리지에 보관하므로, 이전 버전을 덮어쓰지 않고도 동일한 파티션을 공유할 수 있습니다.
스토리지 정책이나 라이선스 조건 때문에 원본 데이터를 보관할 수 없을 때는 약관이 허용하는 범위에서 가장 확실한 수령 기록을 남깁니다. 해시, 요청 매개변수, 출처 개정 식별자, 진단에 쓸 소량의 파싱된 행이 여기에 포함됩니다. 해시만으로 데이터를 복구할 수는 없지만, 두 실행에서 서로 다른 바이트를 사용했는지는 알 수 있습니다.
재현 가능한 백테스트에는 데이터 URL만이 아니라 입력 데이터의 식별 정보가 필요합니다. 무엇을 받았는지, 언제 받았는지, 전략이 사용한 행으로 어떻게 변환했는지 기록하세요.
금요일: 다음에는 하지 않을 일
요약 지표만 비교하는 일은 하지 않을 것입니다. Sharpe가 바뀌었다면 무언가 달라졌다는 뜻이지만, 원인이 무엇인지는 알 수 없습니다. 먼저 행 수와 파티션 해시를 확인하고, 처음으로 입력이 달라지는 날짜를 찾으세요. 그런 다음 변환된 행, 신호, 주문, 체결을 차례로 비교하면 됩니다.
수정된 과거 데이터로 이전 데이터를 조용히 덮어쓰는 일도 하지 않을 것입니다. 데이터 수정은 유용하지만, 이전 실행은 원래 입력에 계속 연결되어 있어야 합니다. 새 데이터셋으로는 새 실행을 만들고 이전 실행과의 관계를 눈에 보이게 기록해야 합니다.
이제 실무 원칙은 간단합니다. 재실행의 목적이 실험 재현이라면 데이터 스냅샷을 고정합니다. 수정된 과거 데이터의 이점을 반영하려는 목적이라면 새 실험으로 표시합니다. 이 구분을 배우는 데 며칠이 걸렸지만, 실행 매니페스트에는 한 줄이면 됩니다.
← 전체 글
