자동매매 백테스트 재현, 남이 제시한 숫자는 가설이다

자동매매 강의나 광고에 나오는 수익률 그래프는 대부분 누군가가 돌린 백테스트 결과입니다. 공개된 전략 사양서를 같은 기간, 같은 규칙으로 직접 재현해 보니 연 수익률은 발표된 숫자의 약 7분의 1이었고, 최대 낙폭은 오히려 더 컸습니다. 이 글은 자동매매의 세 번째 칸인 백테스트를 다룹니다. 남이 제시한 숫자를 어떻게 확인했는지, 그리고 숫자가 맞지 않을 때 무엇을 하고 무엇을 하지 않았는지에 대한 기록입니다.

출발점은 남의 사양서였다

실계좌로 운용 중인 시스템 A는 처음부터 혼자 만든 전략이 아닙니다. 외부에 공개된 전략 사양서를 참고해 만들었습니다. 사양서에는 언제 사고팔지에 대한 규칙과 함께, 과거 몇 년간의 연 수익률, 최대 낙폭 같은 성과 숫자가 적혀 있었습니다.

규칙을 코드로 옮기기 전에 하나를 먼저 정했습니다. 사양서의 성과 숫자는 "목표"가 아니라 "확인해야 할 가설"로 다룬다는 것입니다. 그래서 구현을 마친 뒤 가장 먼저 한 일은 사양서와 같은 기간을 같은 규칙으로 돌려 보는 것이었습니다.

실제로 있었던 일: 재현하니 약 7분의 1

결과는 사양서와 크게 달랐습니다. 같은 기간, 같은 규칙, 현실적인 거래 비용을 넣고 돌렸더니 연 수익률은 사양서 발표치의 약 7분의 1이었습니다. 최대 낙폭은 사양서보다 컸습니다. 덜 벌고 더 잃는 결과였습니다. 사양서 외에 참고하던 목표 숫자 하나는, 그 숫자를 인용한 출처끼리도 서로 맞지 않았습니다. (근거: 시스템 A 벤치마크 리포트와 단계별 결정 기록)

같은 기간, 같은 규칙에서 연 수익률은 사양서의 약 7분의 1, 최대 낙폭은 더 컸다

그렇다고 사양서가 전부 틀린 것은 아니었습니다. "오를 때는 들고 있고, 내릴 때는 현금으로 물러난다"는 핵심 원리는 재현됐습니다. 같은 종목을 아무 판단 없이 계속 들고 있는 방식과 비교하면, 사양서의 원리를 따른 쪽의 낙폭이 훨씬 작았습니다. 틀린 것은 원리가 아니라 숫자였습니다. 이 구분이 중요합니다. 남의 전략을 통째로 믿는 것도, 통째로 버리는 것도 아니고, 무엇이 재현되고 무엇이 재현되지 않는지를 나눠 보는 것이 백테스트 칸의 일입니다.

다른 시스템에서도 비슷한 일이 있었습니다. 참고한 명세의 높은 성과 숫자를 추적해 보니, 짧은 최근 기간의 성과가 긴 기간의 칸에 잘못 적혀 있었습니다. 지난 글에서 다룬 폐기 사례입니다.

숫자에 맞춰 고치지 않았다

재현 숫자가 사양서보다 낮게 나왔을 때 가장 쉬운 길은 규칙의 값을 조금씩 바꿔 사양서 숫자에 가까워질 때까지 돌려 보는 것입니다. 이 길은 처음부터 막아 두었습니다. "계산값을 사양서 숫자에 맞추려고 규칙을 조정하지 않는다"는 것을 되돌릴 수 없는 결정으로 기록해 두고 시작했습니다. 과거 숫자에 맞춰 다듬은 규칙은 과거에만 잘 맞고, 실계좌에서는 그 차이를 그대로 손실로 돌려받기 쉽기 때문입니다. 지난 글에서 다룬 것처럼 낙폭이 기대보다 커서 규칙을 더한 적은 있습니다. 그때도 특정 숫자를 목표로 두지 않았습니다. 더할 규칙을 먼저 정해 구현한 뒤, 같은 기간으로 다시 돌려 나온 결과를 그대로 받아들였습니다.

대신 차이가 어디서 왔는지를 요인별로 나눠서 쟀습니다.

• 미래 데이터 혼입: 판단할 때 그날 이후의 가격을 몰래 보고 있지 않은지
• 거래 비용: 수수료와 체결 오차를 0으로 둘 때와 현실적으로 둘 때의 차이
• 비중 변화: 들고 있는 동안 종목 비중이 저절로 변하는 효과
• 종목 구성: 기간 초반에 아직 상장되지 않은 종목을 어떻게 처리하는지
• 기간: 사양서의 기간과 전체 데이터 기간의 차이

이 중 미래 데이터 혼입은 추정이 아니라 증명으로 확인했습니다. 데이터를 중간에서 잘라 그 시점까지만 보여줘도 그때까지의 판단이 똑같이 나오는지, 100건 넘는 경우를 검사해 혼입이 없음을 확인했습니다. 거래 비용은 0, 현실, 나쁜 경우 세 단계로 돌렸고, 성과는 정확히 그 순서대로 떨어졌습니다. 비용을 0으로 둔 백테스트는 보기 좋은 숫자일 뿐이라는 뜻입니다. 하루에 한 번만 판단하는 이 시스템도 비용 단계에 따라 성과가 눈에 띄게 달라졌으니, 하루에 여러 번 사고파는 전략이라면 그 차이는 훨씬 커집니다. 광고 속 수익률 그래프에 비용 가정이 적혀 있지 않다면, 비용을 넣지 않은 숫자일 가능성부터 의심해 볼 만합니다.

백테스트로 확인한 것. 미래 데이터 혼입, 거래 비용, 비중 변화, 종목 구성, 기간

백테스트와 실거래는 같은 판단 코드를 쓴다

마지막으로 백테스트 숫자가 실계좌와 이어지려면, 과거를 돌릴 때와 실계좌에서 판단할 때 같은 코드가 돌아야 합니다. 백테스트용으로 따로 만든 판단 코드는 아무리 결과가 좋아도 실계좌의 판단을 보증하지 못합니다.

그래서 시스템 A의 판단 코드는 파일을 읽거나, 인터넷에 접속하거나, 현재 시각을 확인하는 일을 전혀 하지 않도록 만들었습니다. 필요한 데이터는 모두 바깥에서 넘겨받기만 합니다. 이렇게 하면 같은 판단 코드를 과거 데이터에도, 오늘의 실시간 데이터에도 그대로 연결할 수 있습니다. 백테스트에서 본 판단과 실계좌의 판단이 같은 코드에서 나온다는 것이 백테스트 숫자를 믿을 수 있는 최소한의 조건입니다.

정리: 백테스트 칸 점검 질문

• 남이 제시한 성과 숫자를 같은 기간, 같은 규칙으로 직접 재현해 봤는가
• 재현 숫자가 다를 때, 규칙을 고쳐 맞추지 않고 원인을 나눠 측정하는가
• 판단이 미래 데이터를 보지 않는다는 것을 검사로 확인했는가
• 거래 비용을 0이 아니라 현실적인 값과 나쁜 경우로 넣어 봤는가
• 백테스트와 실거래가 같은 판단 코드를 쓰는가

다음 글에서는 네 번째 칸인 주문을 다룹니다. 주문은 반드시 실패한다는 전제로 만든 장치들을 정리합니다. 같은 내용을 카드로 정리한 요약은 인스타그램 @wealthgrid.lab 에 올립니다.

※ 특정 종목·수익을 권유하지 않는 개인 시스템 개발 기록입니다. 투자 판단과 책임은 본인에게 있습니다.