IS/OOS 분할만으론 부족｜워크포워드 윈도우 설계

결론: OOS가 한 구간뿐이라면 아직 "한 번의 시험"일 뿐입니다

데이터를 최적화용(IS)과 검증용(OOS)으로 나누는 방법은 과최적화를 의심하는 첫걸음으로 유효합니다. 다만 분할이 한 번뿐이면 OOS 결과는 "그 한 구간에서 어땠는가"만 알려줍니다.

저희의 결론은 다음과 같습니다. OOS를 여러 윈도우로 나누어 앞으로 전진시키며 검증하고, 합계가 아니라 윈도우별로 흑자인지 확인합니다. 합계가 흑자여도 수익이 특정 윈도우에 쏠려 있다면 평가는 보류합니다.

고정 분할의 약점

분할 지점이 결과를 좌우한다

고정 분할에서는 어디서 나눌지를 개발자가 정합니다. OOS가 우연히 추세가 뚜렷한 시기에 걸리면 로직의 실력 이상으로 좋아 보입니다. 반대 시기에 걸리면 쓸 만한 로직을 버리게 됩니다. 어느 쪽이든 분할 지점이라는 하나의 선택에 결과가 의존하고 있습니다.

OOS를 여러 번 보면 더는 OOS가 아니다

또 다른 문제는 개발자 쪽의 행동입니다. OOS 성적이 나쁘면 파라미터를 고치고, 다시 OOS를 봅니다. 이를 반복하면 OOS에 맞는 것을 고르는 것과 다를 바 없어집니다. 형식상으로는 사용하지 않은 데이터지만, 실질적으로는 최적화에 쓰인 셈입니다. 이는 저희 스스로에게도 일어날 수 있는 실수이며, 절차로 묶어 두지 않으면 막을 수 없습니다.

워크포워드 윈도우 만드는 법

워크포워드는 "최적화하는 기간"과 "그 직후의 검증하는 기간"을 한 쌍의 윈도우로 삼아, 시간을 앞으로 밀어 가며 반복하는 방법입니다. 검증 구간은 항상 최적화 구간보다 미래에 있으므로 OOS를 여러 개 얻을 수 있습니다.

윈도우 길이를 정하는 기준

윈도우 길이는 달력상의 연수보다 거래 수로 정하는 편이 안전합니다. 검증 구간에 들어가는 거래가 너무 적으면 흑자인지 적자인지는 우연으로 결정됩니다. 보유 시간이 길고 거래 빈도가 낮은 로직일수록 검증 구간을 길게 잡아야 합니다.

윈도우별로 확인하는 절차

1. 검증 구간이 겹치지 않도록 윈도우를 나열한다
2. 각 윈도우에서 최적화하고, 얻은 파라미터를 직후의 검증 구간에만 적용한다
3. 검증 구간별로 손익, PF, 거래 수, 최대 드로다운을 기록한다
4. PF 1.0 이상인 윈도우가 얼마나 되는지, 적자 윈도우가 어느 시기인지 확인한다
5. 가장 큰 수익을 낸 윈도우를 제외해도 나머지 합계가 흑자인지 확인한다
6. 윈도우마다 선택된 파라미터가 크게 널뛰지 않는지 살펴본다

점검의 핵심은 세 가지입니다.

• 흑자 윈도우가 일부에 집중되어 있지 않은가
• 적자 윈도우의 손실이 흑자 윈도우의 수익에 비해 너무 크지 않은가
• 인접한 윈도우 사이에서 최적 파라미터가 극단적으로 바뀌지 않는가

저희는 모든 윈도우가 흑자여야 한다고 생각하지 않습니다. 추세 추종형은 방향성이 없는 시기의 윈도우에서 지는 것이 보통입니다. 문제 삼아야 할 것은 지는 윈도우의 이유를 설명할 수 없는 경우, 그리고 손실의 깊이가 예상을 넘는 경우입니다.

한계와 주의점

거래 수가 부족하면 윈도우가 성립하지 않는다

ATLAS의 백테스트는 검증 7.5년 동안 1193건의 거래가 있어, 여러 윈도우로 나누어도 각 윈도우에 어느 정도의 거래가 남습니다. 반면 ETHEREUM EA의 백테스트는 검증 7.5년 동안 154건입니다. 이런 저빈도 로직을 잘게 쪼개면 윈도우 하나당 거래가 극히 적어져, 윈도우 단위의 흑자·적자는 판단 자료로 거의 쓸모가 없습니다. 윈도우를 크게 잡거나, 윈도우별 평가는 참고 수준에 그칠 수밖에 없습니다.

공개하고 있는 수치는 전체 기간의 값

실측 랭킹에 실은 PF나 승률은 검증 기간 전체를 통틀어 낸 값입니다. 윈도우별 성적이 아니므로 이것만으로는 과최적화 여부를 판정할 수 없습니다. 이 점을 감안하고 읽어 주십시오.

윈도우 설계 자체도 최적화할 수 있다

윈도우의 길이나 개수를 바꿔 가며 결과가 좋아 보이는 조합을 고른다면, 그것 또한 과최적화입니다. 윈도우 설계는 검증을 돌리기 전에 정하고 나중에 움직이지 않는 것이 전제입니다. 외부에서 그 전제가 지켜졌는지 확인할 방법은 거의 없습니다.

그래도 미래는 알 수 없다

워크포워드를 통과하더라도 과거에 없던 시장에는 대응하지 못합니다. 저희가 운용하는 데모 계좌의 포워드 테스트에서도 손익이 마이너스인 EA가 여러 개 있습니다. 데모 계좌이며 실계좌의 성적이 아니고 시작 이후의 기간도 짧아서, 좋은 결과도 나쁜 결과도 결론을 낼 수 있는 단계가 아닙니다. 검증 기법은 빗나감을 줄이는 도구이지, 적중을 약속하는 것이 아닙니다.

정리

• 고정 IS/OOS 분할은 분할 지점과 OOS를 다시 본 횟수에 결과가 좌우된다
• 워크포워드는 검증 구간을 여러 개 만들어 앞으로 전진시키며 확인하는 방법
• 보는 것은 합계가 아니라 윈도우별 손익. 수익의 쏠림과 파라미터의 안정성을 확인한다
• 거래 수가 적은 로직은 윈도우로 나눌수록 판단이 불안정해진다
• 윈도우 설계는 사전에 고정한다. 통과해도 미래의 성적은 알 수 없다

검증에 대한 생각은 노하우 모음에도 정리해 두었습니다.