백테스팅에서 수익을 내지만 실거래에서 손실을 보는 경우, 슬리피지가 종종 비난받지만, 먼저 Pine Script의 request.security() 함수의 특정 원인을 확인해야 합니다. 트레이딩뷰에서 문서화된 이 문제는 고차원 타임프레임 데이터가 사용되는 방식과 관련이 있습니다. 기본적으로 request.security()는 barmerge.lookahead_off를 사용하여 미래 데이터 누수를 방지합니다. 그러나 인식된 1바 지연을 피하기 위해 lookahead=barmerge.lookahead_on으로 설정하면 치명적인 결함이 발생합니다.이 설정은 과거 백필이 실거래에서 아직 사용할 수 없는 데이터를 포함하도록 허용합니다. 예를 들어, 현재 가격을 고차원 타임프레임의 종가와 비교하는 전략은 일중 바에 대해 백테스팅에서 미래 종가를 사용합니다. 실거래에서는 이 미래 데이터가 존재하지 않아 불일치가 발생합니다.이 문제는 실시간으로 발견하기 어렵기 때문에 은밀합니다. 실시간 거래 중에는 미래 데이터가 존재하지 않으므로 lookahead_on 및 lookahead_off 시리즈 모두 동일한 값을 표시합니다. 그러나 실시간 바가 마감되어 과거가 되면 전체 과거 기록으로 다시 계산되어 실시간으로 관찰된 것과 달라지는 "다시 칠하기(repainting)"가 발생합니다. 이는 작동하는 것처럼 보이는 실시간 세션이 차트를 다시 로드할 때 완전히 변경될 수 있음을 의미합니다.request.security()가 차트 자체 해상도와 같거나 낮은 타임프레임에 사용될 때 관련 변형이 발생합니다. 그러면 lookahead 설정이 어떤 인트라바(intrabar) 값을 반환할지 결정하여 백테스트와 실거래 실행 간의 불일치를 초래할 수 있습니다. 이를 진단하려면 스크립트 사용자는 "lookahead_on"에 대한 모든 request.security() 호출을 검사해야 합니다. 발견되면 명시적인 과거 오프셋이 적용되었는지 확인하십시오.또한 동일하거나 낮은 타임프레임 요청에 대한 인트라바 선택을 확인하십시오. 다시 칠하기의 직접적인 증상은 스크립트 다시 로드 후 최근 마감된 바의 값이 변경되는 것입니다. 과거에 사용 가능한 데이터와 실시간으로 알 수 있는 것 사이의 이러한 중요한 구분은 신뢰할 수 있는 전략 성능에 필수적입니다.