거래 봇 백테스트에서 미래 참조 편향을 탐지하는 방법

정보의 시간 흐름부터 확인하기

거래마다 네 가지 사건을 기록하세요. 기초 데이터가 발표된 시점, 전략이 이를 읽을 수 있었던 시점, 판단이 이루어진 시점, 주문이 체결될 수 있었던 시점입니다. 캔들 타임스탬프는 최종 고가, 저가, 종가를 알게 된 시점이 아니라 시작 시점을 표시하는 경우가 많습니다. 거래소 데이터 피드, 시장 일정, 세션 경계에 따라 정확한 이용 가능 시점이 달라질 수 있습니다.

10:00으로 표시된 5분 캔들이 10:00부터 10:05 직전까지를 포함한다고 생각해 보세요. 최종 종가에 기반한 규칙은 10:00에 그 종가를 알 수 없습니다. 같은 캔들이 결국 임계값 위에서 마감했다는 이유로 백테스트가 10:00 시가에 매수를 기록한다면 정보 경계를 넘은 것입니다. 10:05 종가 체결도 해당 타이밍을 실제로 지원하는 시뮬레이터가 필요합니다. 기본 봉 마감 전략은 시장가 주문을 다음 이용 가능한 틱, 흔히 다음 봉의 시가에 체결합니다.

이는 가상의 타이밍 예시이며 TensorParadigm의 실제 거래나 성과 결과가 아닙니다.

점검이 필요한 징후

매끄러운 자산 곡선, 거의 완벽한 전환점 진입, 신호를 한 봉 늦추면 무너지는 수익은 더 자세히 살펴볼 필요가 있습니다. 어느 것도 그 자체로 유출을 증명하지는 않습니다. 시장 조성과 일부 단기 시스템은 다른 이유로 특이한 형태를 보일 수 있고, 반대로 유출이 있는 전략도 손실을 낼 수 있습니다.

• 규칙에 해당 봉의 확정 종가가 필요한데 거래가 같은 봉의 고가나 저가에서 나타납니다.
• 과거 테스트에서 1시간 지표가 더 이른 5분 봉 안에서 바뀝니다.
• 특성이 미래 수익률이나 레이블과 놀랍도록 강한 상관관계를 보입니다.
• 전처리를 학습 데이터만으로 별도 학습한 뒤 학습·테스트 결과가 크게 바뀝니다.
• 관련 호가나 관측값을 이용할 수 있기 전에 백테스트가 체결을 기록합니다.

Pine Script 상위 시간봉 요청 확인하기

TradingView는 상위 시간봉의 request.security()에 barmerge.lookahead_on을 사용하면서 요청 표현식에 오프셋을 주지 않으면 과거 봉에서 상위 시간봉의 최종 값이 너무 일찍 노출될 수 있다고 설명합니다. 예를 들어 최종 1시간 종가를 그 시간의 첫 5분 봉에 전달하면 5분 규칙은 한 시간이 끝나기 전에 그 끝을 보게 됩니다.

직전 확정 상위 시간봉만 필요한 전략을 위해 TradingView가 문서화한 리페인팅 방지 패턴은 lookahead_on을 사용하면서 요청 표현식을 상위 시간봉 하나만큼 이전으로 이동합니다. 이 용도에서는 과거와 실시간의 이용 가능 시점이 일치합니다. 이 패턴을 하위 시간봉 요청이나 의도적으로 진행 중인 값으로 거래하는 규칙에 무분별하게 복사하지 마세요.

모든 request.security() 표현식, 시간봉, lookahead 설정, 판단에 쓰이는 봉 인덱스를 살펴보세요. 차트 시간봉에서 계산이 확정되는지도 검토하세요. 상위 시간봉 입력을 고쳐도 여전히 비현실적으로 이른 체결을 허용하는 시뮬레이터가 고쳐지지는 않습니다.

학습 전에 Python 특성 생성 점검하기

중앙 정렬 이동평균은 현재 타임스탬프의 양쪽에서 관측값을 가져옵니다. 특성 열에서 음수 시프트를 쓰면 내일의 값이 오늘 행에 들어갈 수 있습니다. 둘 다 나중에 예측을 평가하는 레이블에는 유효할 수 있지만 오늘의 실거래 판단에 이용 가능한 특성에는 들어가면 안 됩니다.

decision_time, 각 특성의 source_time과 available_time, target_window_end, signal_time, earliest_fill_time 열이 있는 작은 표를 만드세요. 모든 특성에서 available_time이 signal_time보다 늦지 않은지 검사하세요. 다음 봉 수익률 같은 레이블을 만들면 모델 입력, 결합한 메타데이터, 정답을 간접적으로 드러낼 수 있는 전처리에서 제외하세요.

이벤트 데이터에는 실제 발표 시점이나 수집 시점이 필요합니다. 시장 타임스탬프가 붙은 펀딩 비율, 수정된 거시경제 시계열, 뉴스도 그 시점보다 늦게 도착할 수 있습니다. 이런 입력이 거래를 결정할 때는 시점별 스냅샷과 데이터 수정 이력이 중요합니다.

시간 순서대로 나누고 각 폴드 안에서 전처리 학습하기

무작위 분할은 모델이 나중의 시장 국면으로 학습하고 이전 관측값으로 테스트하게 합니다. scikit-learn의 TimeSeriesSplit은 학습·테스트의 시간 순서를 유지하고 사이에 간격을 둘 수 있습니다. 레이블 예측 기간과 겹치는 관측 윈도에 따라 간격을 정하세요. 보편적인 고정 수치가 아닙니다.

각 분할에서 학습 데이터만으로 스케일링, 결측값 대체, 특성 선택, 하이퍼파라미터 선택을 계산하세요. scikit-learn Pipeline은 변환을 교차 검증 안에 유지하는 데 도움이 됩니다. 비지도 스케일러도 전체 표본으로 학습하면 미래 테스트 기간의 특성을 배우게 됩니다. 마지막에 전혀 사용하지 않은 평가 기간을 남기면 개발 중의 선택을 평가하는 데 도움이 됩니다.

테스트 세트를 본 뒤 전략을 반복적으로 바꾸는 것은 개별 특성에 미래 데이터가 없더라도 선택 편향이나 과적합입니다. 실험 기록을 남기고 이 문제를 직접적인 미래 참조 유출과 구분하세요.

신호와 모의 주문 체결 대사하기

신호 시점과 체결 시점은 다릅니다. TradingView 브로커 에뮬레이터는 보통 계산 틱에서 주문을 만들고 이후 이용 가능한 틱보다 빨리 체결할 수 없습니다. process_orders_on_close 옵션은 봉의 마감 틱에서 체결을 시도할 수 있습니다. 다른 봉 내부 설정과 주문 유형도 실행 모델을 바꿀 수 있으므로 한 봉 차이를 버그라고 단정하기 전에 실제 전략 설정을 확인하세요.

의심스러운 각 거래에 대해 사용한 지표 값, 봉 마감 확인, 주문 생성 타임스탬프, 주문 유형, 보고된 체결 시점과 가격을 내보내거나 로그에 기록하세요. 그 가격이 판단 후에 도달 가능했는지 물어보세요. 스프레드, 수수료, 슬리피지 가정은 별도로 포함하세요. 이는 유출을 고치지는 않지만 수정된 백테스트에 경제적 가치가 있는지에 영향을 줍니다.

세 가지 반증 검증 실행하기

첫째, 모든 신호를 완성된 차트 봉 하나만큼 늦추고 결과가 얼마나 바뀌는지 측정하세요. 이는 진단이지 자동 수정이 아닙니다. 유효한 빠른 신호도 지연되면 약해질 수 있습니다. 둘째, 시간 순서 재생에서 지표를 한 봉씩 다시 계산하고 각 판단 시점마다 전체 기록을 사용한 계산과 비교하세요. 셋째, 각 학습 폴드를 독립적으로 다시 구성하고 전략을 고정한 뒤 이후 기간을 확인해 테스트를 다시 실행하세요.

결과가 다르면 대표 수익만 비교하지 말고 처음 불일치한 거래를 추적하세요. 명시된 시점에는 존재할 수 없었던 정확한 데이터 필드나 주문 체결을 식별하세요. 수정한 뒤 실행 비용과 합리적인 매개변수 변동을 적용해 테스트를 반복하세요. 살아남은 결과는 더 나은 증거이지 실거래 성과의 보장은 아닙니다.

의심스러운 한 거래의 구체적인 점검

5분 캔들이 이전 고가 위에서 마감했다는 이유로 봇이 10:00 시가에 매수한다고 가정하세요. 10:00 시가를 제시된 체결로, 10:05 완성을 최종 종가를 처음 알 수 있는 시점으로 기록하고 전략의 실제 판단 및 주문 시점도 적으세요. 조건이 제시된 체결 이후의 정보에 의존하므로 이 규칙 아래에서는 기록된 거래가 유효하지 않습니다.

코드를 고쳐 10:05에 판단하게 했다면 실행 엔진이 실제로 다음에 무엇을 하는지 확인하세요. 다음 틱의 시장가 체결은 다음 봉 시가 근처에서 일어날 수 있습니다. 마감 틱 옵션은 다른 가정이며 시장이 움직인 뒤 도착하는 실제 알림과 일치하지 않을 수 있습니다. 신호 타임스탬프만 옮기면서 예전 진입 가격을 유지하지 마세요.

이제 같은 거래의 1시간 필터도 확인하세요. 한 시간이 끝나기 전에 해당 시간의 최종 종가를 읽는다면 실행 타임스탬프를 고쳐도 5분 진입은 여전히 오염되어 있습니다. 입력의 이용 가능 시점과 체결이 모두 검증을 통과해야 합니다.

유출 없는 백테스트가 알려 줄 수 있는 것과 없는 것

미래 데이터 유출을 제거하면 신뢰할 수 있는 테스트의 기본 요건이 회복됩니다. 하지만 전략이 국면 변화, 장애, 스프레드 확대, 펀딩 지급, 불충분한 유동성 또는 위험 한도를 견딜 수 있음을 입증하지는 않습니다. 유효한 백테스트도 나쁜 거래 시스템일 수 있습니다.

테스트를 재현할 수 있도록 데이터 버전, 전략 코드, 비용, 매개변수 선택, 폴드 경계를 보존하세요. 결함을 발견하면 변경 내용을 설명하고 의심스러운 결과와 수정된 결과를 모두 보고하세요. 투명한 수정은 보기 좋게 다듬은 자산 곡선보다 유용합니다.