트레이딩뷰 리페인팅(Repainting)의 공포와 Non-Repainting 수식 설계의 모든 것
반갑습니다! 트레이딩 시스템 개발이나 지표 백테스팅을 하시다 보면 '백테스트에서는 승률이 90%인데 실전에서는 왜 이 모양이지? ' 하고 허탈했던 경험, 한 번쯤 있으실 겁니다. 그 주범이 바로 리페인팅(Repainting, 과거 데이터 왜곡 현상)인데요. 오늘은 실전 트레이더와 개발자분들이 가장 골치 아파하는 Non-Repainting(리페인팅 방지) 스크립트의 수식 구조 설계 원리 를 블로그 포스팅 스타일로 알기 쉽게 파헤쳐 보겠습니다. 트레이딩 자동화나 지표 개발을 공부하다 보면 가장 많이 마주치는 용어가 바로 '논리페인팅(Non-Repainting)'입니다. 백테스트 화면에서는 완벽한 승률을 자랑하던 신호가 실전 매매만 들어가면 뒤늦게 사라지거나 위치가 바뀌어 버리는 현상, 겪어보셨나요? 이번 글에서는 과거 데이터와 실시간 봉 완성 시점 사이에서 발생하는 시그널 왜곡의 원인을 짚어보고, 이를 원천 차단하는 견고한 수식 구조와 파인스크립트(Pine Script) 설계 노하우를 상세히 알아보겠습니다. 1. 왜 리페인팅(Repainting)은 발생할까? (근본 원인 분석) 리페인팅은 단순히 지표의 오류가 아니라, 컴퓨터가 과거 데이터와 실시간 데이터를 처리하는 방식의 허점 때문에 발생합니다. 주요 원인은 크게 세 가지로 나뉩니다. 완성되지 않은 현재 봉( close ) 참조: 실시간으로 움직이는 캔들의 종가는 봉이 마감되기 전까지 계속 변합니다. 마감 전의 close 값을 기준으로 신호를 내면, 봉이 끝났을 때 가격이 반대로 움직여 신호가 증발해 버립니다. 미래 데이터를 끌어오는 security() 함수의 오류: 상위 타임프레임(예: 일봉, 4시간봉)의 데이터를 현재 1분봉으로 가져올 때, 미래의 시점 데이터를 미리 참조( lookahead = barmerge.lookahead_on )하게 되면 백테스트에서는 신성장 동력처럼 보이지만 실전에서는 구현 불가능한 허상이 됩니다. 지그재그(Z...