백테스트가 화려할수록 왜 의심해야 할까 — 수백 번 돌려 '최고'만 보여주는 착시

자동매매를 알아보는 분들이 가장 자주 홀리는 장면은 오른쪽 위로 매끈하게 뻗어 올라가는 백테스트 수익 곡선입니다. "과거 3년에 넣었으면 이만큼 벌었다"는 그래프 한 장이면 마음이 흔들리죠. 그런데 그 그래프를 앞에 두고 거의 아무도 하지 않는 질문이 하나 있습니다. "이거, 몇 번째로 고른 거예요?" 이 질문 하나가 화려한 백테스트의 진위를 가르는 열쇠입니다. 왜냐하면—수백 개의 전략과 설정값을 돌려보고 그중 가장 예쁜 하나만 골라 보여주면, 그 곡선은 실력의 증거가 아니라 순전한 우연의 극단값일 수 있기 때문입니다. 이 글은 그 착시의 정체인 데이터 스누핑(data snooping)과 다중검정(multiple testing)을 코딩 한 줄 없이 풀어내고, 정직한 퀀트가 이걸 어떻게 방어하는지, 그리고 비개발자가 백테스트를 받았을 때 무엇을 물어야 하는지를 정리합니다. 미리 밝혀두자면 이 글은 어떤 전략의 수익이나 시장 방향을 예측하지 않습니다. 백테스트를 읽고 검증하는 방법론에 관한 이야기이며, 과거 성과는 미래를 보장하지 않습니다.

1. "이거, 몇 번째로 고른 거예요?" — 아무도 안 하는 질문

상상해 봅시다. 어떤 사람이 여러분에게 자동매매 전략을 팔러 왔습니다. 노트북을 열더니 지난 3년간 +180%가 찍힌 우상향 곡선을 보여줍니다. 최대 낙폭도 얕고, 승률도 높아 보입니다. 대부분의 사람은 이 지점에서 "오, 얼마죠?"를 묻습니다. 하지만 백테스트를 제대로 아는 사람은 완전히 다른 걸 묻습니다.

이 두 질문이 왜 그렇게 중요할까요? 백테스트라는 도구에는 남들이 잘 말하지 않는 비밀이 하나 있습니다. 충분히 여러 번 시도하면, 실력이 전혀 없어도 눈부신 곡선 하나쯤은 반드시 얻게 된다는 것입니다. 과거 데이터는 이미 정해져 있고 바뀌지 않기 때문에, 그 고정된 데이터에 대고 수백 가지 규칙을 던져 보면 그중 몇 개는 순전히 운으로 과거와 절묘하게 맞아떨어집니다. 그 '운 좋은 하나'를 골라내 액자에 넣어 보여주는 것—이것이 화려한 백테스트의 흔한 정체입니다.

그래서 백테스트를 볼 때 우리가 진짜 알아야 하는 건 "결과가 얼마나 좋은가"가 아니라 "이 결과가 어떻게 태어났는가"입니다. 같은 +180% 곡선이라도, 하나의 명확한 가설을 세워 딱 한 번 검증한 결과인지, 아니면 수백 개를 돌려 우연히 걸린 극단값인지에 따라 그 가치는 하늘과 땅입니다. 겉모습만으로는 이 둘을 구별할 수 없다는 것—그것이 이 글이 존재하는 이유입니다.

2. 동전 1,000개의 우화 — 실력 없이도 '10연승'은 나온다

다중검정이 왜 착시를 만드는지, 유명한 사고실험 하나로 느껴 봅시다. 동전 던지기 예언가 이야기입니다.

어떤 도시에 1,000명이 모여 각자 동전을 던집니다. 규칙은 간단합니다. 앞면이 나오면 살아남고, 뒷면이 나오면 탈락. 한 번 던질 때마다 절반씩 사라집니다. 10번을 던지면? 순전한 확률로, 약 한 명은 앞면만 10번 연속 나옵니다. 이제 그 한 명을 무대에 세워 봅시다. "이분은 동전의 미래를 10번 연속 맞힌 예언가입니다!" 청중은 감탄합니다. 하지만 우리는 압니다. 그는 예언가가 아니라, 단지 1,000명 중 운이 가장 좋았던 사람일 뿐입니다. 그가 다음 동전을 맞힐 확률은 여전히 절반입니다.

백테스트에서 벌어지는 일이 정확히 이겁니다. 1,000명의 사람 = 1,000개의 전략·설정값 조합. 대부분은 과거에서 평범하거나 나쁜 성적을 냅니다. 하지만 그중 한둘은 순전한 우연으로 과거 데이터와 절묘하게 맞아 눈부신 곡선을 그립니다. 그 하나를 골라내 "우리가 찾은 최고의 전략"이라 부르면, 동전 예언가를 천재라 부르는 것과 똑같은 착각에 빠집니다. 결정적으로, 그 곡선은 '미래를 맞힐 능력'을 전혀 증명하지 못합니다. 그저 '과거에 운이 좋았던 후보'를 보여줄 뿐입니다.

이 우화의 교훈은 잔인할 만큼 단순합니다. "얼마나 좋은 결과인가"는 "얼마나 많이 시도했는가"를 모르면 아무 의미가 없다. 10연승이 대단한지 아닌지는, 그가 혼자 던졌는지 1,000명 중 하나인지를 알아야 판단할 수 있습니다. 그런데 백테스트 곡선 한 장에는 '몇 명이 던졌는지'가 적혀 있지 않습니다. 그래서 우리가 직접 물어야 하는 것입니다.

3. 과최적화와 뭐가 다른가 — '하나를 조이기' vs '수백 중 고르기'

자동매매를 좀 알아본 분이라면 과최적화(오버피팅·커브피팅)라는 말을 들어봤을 겁니다. "백테스트에 너무 딱 맞추면 실전에서 무너진다"는 그 이야기죠. 그렇다면 데이터 스누핑은 과최적화와 같은 말일까요? 깊이 연결돼 있지만, 같지는 않습니다. 이 둘을 구분하면 백테스트를 훨씬 예리하게 볼 수 있습니다.

실전에서는 이 둘이 겹쳐서 나타납니다. 예를 들어 어떤 전략의 설정값(예: 이동평균 기간, 손절 폭 등)을 격자처럼 수백 가지 조합으로 훑어 최고 성적을 찾았다면, 이는 '하나를 조인' 과최적화인 동시에 '수백 중 고른' 데이터 스누핑입니다. 두 함정이 손을 잡은 셈이죠. 결말은 비슷합니다—과거엔 눈부시고 미래엔 평범하거나 그 이하.

다만 방어법이 조금 다릅니다. 과최적화는 주로 '규칙을 단순하게, 파라미터를 적게'로 눌러야 합니다. 데이터 스누핑은 '탐색한 횟수를 기록하고, 손대지 않은 데이터로 다시 확인'해야 잡힙니다. 왜 실전에서 백테스트가 무너지는지에 대한 더 넓은 진단(비용 축소, 미래참조, 생존편향 등 7가지 이유)은 백테스트 +50%인데 실거래 −10% — 무너지는 7가지 이유에서 다뤘고, 백테스트를 엔지니어링하는 관점(워크포워드·몬테카를로 포함)은 자동매매 백테스트 완전 가이드에서 정리했습니다. 이 글은 그중에서도 '고르는 행위'가 만드는 착시 한 가지를 비개발자 눈높이로 깊게 파는 자매편입니다.

4. 데이터 스누핑이 숨어드는 5곳

데이터 스누핑은 나쁜 마음을 먹어야만 생기는 게 아닙니다. 선의로 전략을 개발하는 과정에서도 자기도 모르게 스며듭니다. 어디에 숨는지 알면 스스로도, 남의 백테스트를 볼 때도 경계할 수 있습니다.

여섯 곳 모두 공통점이 있습니다. '과거 데이터를 여러 번 들여다보며 좋아 보이는 쪽으로 선택했다'는 것입니다. 한 번의 정직한 검증이 아니라, 수많은 엿보기(snooping) 끝의 취사선택. 그래서 이름도 '데이터 스누핑', 즉 데이터 훔쳐보기입니다. 핵심은 각각의 시도가 부정직해서가 아니라, 시도의 총량이 커질수록 우연한 승자가 나올 확률이 함께 커진다는 통계의 냉정한 산수에 있습니다. 그 산수를 다음 장에서 봅시다.

5. 왜 이게 '거짓말'이 되나 — 다중검정의 산수

통계에는 다중검정(multiple testing / multiple comparisons)이라는 개념이 있습니다. 어렵게 들리지만 핵심은 한 문장입니다. "한 번 시험할 때는 드문 우연도, 여러 번 시험하면 흔해진다."

직관을 위한 예를 들어 봅시다(정확한 수치가 아니라 개념을 위한 단순화된 산수입니다). 어떤 무의미한 규칙이 순전한 우연으로 '좋아 보일' 확률이 한 번의 시험에서 1/20(5%)이라고 해봅시다. 한 개만 시험하면 헛것에 속을 확률은 5%로 낮습니다. 그런데 서로 무관한 규칙 100개를 시험하면 어떻게 될까요? 그중 평균 5개쯤은 순전한 우연만으로 '좋아 보이게' 됩니다. 시험 수를 늘릴수록 '가짜 승자'의 개수도 함께 늘어납니다. 그리고 개발자는 그중 가장 좋아 보이는 하나를 골라 자랑하죠.

이 표가 말하는 바는 명확합니다. 탐색 규모가 커질수록, '아무 의미 없는데 과거에 잘 맞은' 후보의 수가 비례해서 늘어난다. 그러니 "수천 조합을 돌려 최고를 찾았다"는 말은, 방어장치가 없다면 자랑이 아니라 경고일 수 있습니다. 시험을 많이 할수록 우연한 승자를 만날 각오도 함께 커지기 때문입니다.

전문 퀀트 세계에는 이 문제를 정면으로 다루는 개념들이 있습니다. 예컨대 여러 번 시도해 부풀려진 성과지표를 '시도 횟수'를 감안해 깎아 내리는 보정된 성과지표라는 아이디어가 학술적으로 연구돼 왔습니다(용어·수식은 원 논문·공식 자료 확인). 핵심 철학은 같습니다—"몇 번 시도했는지를 성과 평가에 반영하라." 시도 횟수를 숨긴 성과는, 몇 명이 던졌는지 감춘 동전 예언가의 10연승과 같습니다.

6. "우리가 최적화했습니다"가 오히려 신호일 때

자동매매를 팔거나 만들어 주는 곳에서 흔히 쓰는 표현이 있습니다. "수천 가지 조합을 백테스트해 최적의 파라미터를 찾았습니다." 이 말을 들으면 왠지 정교하고 과학적으로 느껴집니다. 그런데 지금까지 읽은 여러분은 이제 반대편 질문을 떠올릴 수 있어야 합니다. "수천 가지를 돌렸다면, 그 최고값이 우연한 승자가 아니라는 걸 어떻게 확인했나요?"

오해하지 마세요. 많은 조합을 탐색하는 것 자체는 잘못이 아닙니다. 전략 개발에서 파라미터 공간을 살펴보는 것은 당연한 과정입니다. 문제가 되는 건 탐색한 바로 그 데이터의 성적을 '최종 성과'로 자랑할 때입니다. 탐색에 쓴 데이터에서의 최고 성적은 정의상 항상 좋아 보이게 마련이니까요. 그래서 '최적화했다'는 말은 그 자체로는 좋지도 나쁘지도 않은 중립적 정보이고, 진짜 판단은 뒤에 따라올 한 마디에 달려 있습니다—"그리고 손대지 않은 다른 기간에서도 확인했습니다."

자동매매 상품·서비스를 고를 때 이 '화법 차이'는 생각보다 강력한 필터입니다. 정직한 쪽은 불확실성을 먼저 꺼내 놓고, 과장하는 쪽은 확실성을 연기합니다. 수익을 단정하거나 '무조건 버는' 그림을 파는 상대를 거르는 더 넓은 체크리스트는 자동매매 사기·허위광고 피하는 법과 수익 인증의 허상 — 현실적 기대치에서 다뤘습니다. 데이터 스누핑을 아는 것은, 그중에서도 '그럴듯한 그래프'로 위장한 과장을 꿰뚫어 보는 눈입니다.

7. 정직한 퀀트가 방어하는 6가지 규율

그렇다면 데이터 스누핑을 완전히 없앨 수 있을까요? 없앨 수는 없지만, 크게 억누를 수는 있습니다. 진지한 퀀트와 개발자들이 쓰는 방어 규율은 대략 여섯 가지로 요약됩니다. 비개발자도 개념만 알아두면, 제작자가 이걸 지키는지 물어볼 수 있습니다.

① 데이터를 나눈다 (표본내·표본외 분리). 전체 과거를 개발·탐색에 쓰는 인샘플(in-sample)과 손대지 않고 마지막 검증에만 쓰는 아웃오브샘플/홀드아웃(out-of-sample)으로 나눕니다. 수백 번 엿보기는 인샘플에서만 하고, 최종 성적표는 한 번도 안 본 홀드아웃에서 확인합니다. 홀드아웃에서도 비슷하면 그나마 우연이 아닐 가능성이 올라갑니다.

② 창을 굴린다 (워크포워드 검증). 한 번만 나누는 대신, '과거로 정하고 → 바로 뒤 미래 조각에서 확인'을 앞으로 굴려가며 반복합니다. 매번 '처음 보는 미래'에 부딪히므로, 과거에만 맞춘 후보는 여기서 정체가 드러납니다. 개념·구현은 백테스트 완전 가이드 참고.

③ 가설을 먼저 세운다. "데이터를 뒤져 뭐가 나오나 보자"가 아니라, "이 규칙은 이런 이유로 작동할 것"이라는 가설을 먼저 적고 그 하나를 검증합니다. 이유를 한 문장으로 설명할 수 없는 규칙은, 데이터를 훔쳐본 결과일 확률이 높습니다.

④ 시도 횟수를 기록한다. 몇 개의 조합·종목·기간을 훑었는지 솔직하게 세어 두고, 그만큼 성과를 보수적으로 깎아 봅니다. "많이 시도했으니 이 성적은 좀 부풀려졌을 것"이라고 스스로 할인하는 태도입니다.

⑤ 단순함을 선호한다. 파라미터가 적고 규칙이 단순한 전략일수록 우연에 걸릴 문이 좁습니다. 과거의 모든 상처에 반창고(예외 조건)를 붙일수록 데이터 스누핑과 과최적화가 함께 자랍니다. 복잡함은 정교함이 아니라 위험 신호일 때가 많습니다.

⑥ 비용을 먼저 넣는다. 수수료·세금·슬리피지를 처음부터 넉넉히 반영합니다. 비용을 빼면 얕은 우위의 가짜 전략도 살아남지만, 비용을 정직하게 넣으면 그런 '우연한 승자' 상당수가 걸러집니다. 체결·슬리피지가 성과를 어떻게 갉아먹는지는 주문 체결의 진짜 원리 — 슬리피지·미체결에서 다뤘습니다.

8. 그래도 남는 한계 — 표본외도 자꾸 보면 오염된다

여기서 정직해야 할 대목이 있습니다. 위의 방어들도 완벽하지 않습니다. 가장 흔한 구멍은 '홀드아웃 소진(검증용 데이터 닳아 없어지기)'입니다. 손대지 않기로 떼어둔 검증용 기간을, 결과가 마음에 안 든다고 자꾸 들여다보며 "그럼 이렇게 고쳐서 다시 검증해 볼까?"를 반복하면, 어느 순간 그 검증용 데이터도 사실상 개발용이 되어 버립니다. 처음 볼 때만 '처음 보는 데이터'이지, 열 번째로 맞춰가며 보면 더는 표본외가 아닙니다.

그래서 홀드아웃에는 규율이 필요합니다. 검증용 데이터는 아껴서, 정말 마지막에 한두 번만 확인하는 것이 원칙입니다. 검증에서 실패했다면, 그 데이터를 보며 고치는 게 아니라 가설 단계로 돌아가 새 데이터로 다시 검증하는 편이 정직합니다. 또한 표본외 기간이 우연히 순탄한 시기였을 수도 있고—미래는 과거의 어떤 조각과도 다를 수 있습니다.

9. 백테스트를 받았을 때 물어볼 7가지

코드를 한 줄도 못 읽어도, 아래 일곱 질문이면 백테스트의 정직성을 상당히 가늠할 수 있습니다. 이건 종목 추천을 구하는 게 아니라 납품물을 검수하는 상식적 질문입니다.

1. "이 결과를 찾기까지 대략 몇 가지를 시도하셨어요?" — 시도 규모를 숨기지 않고 답하는지. 수를 세어 두고 성과를 보수적으로 본다면 좋은 신호.
2. "개발에 쓴 기간과 검증에 쓴 기간이 분리돼 있나요? 검증 기간 성적을 따로 볼 수 있나요?" — 표본내·표본외 분리 여부. 홀드아웃 성적을 보여줄 수 있는지가 핵심.
3. "이 규칙이 왜 작동하는지 한 문장으로 설명해 주실 수 있나요?" — 이유 없이 '데이터가 그렇다'만 반복되면 스누핑 신호일 수 있음.
4. "거래 비용·세금·슬리피지를 넣은 결과인가요?" — 비용을 뺀 화려함은 흔한 착시. 넣고도 견디는지가 중요.
5. "이 전략의 최악 낙폭과 가장 긴 부진 기간은 얼마였나요?" — 좋은 쪽만 보여주는지, 나쁜 순간도 정직하게 드러내는지.
6. "파라미터(설정값)는 몇 개이고, 왜 그 값인가요?" — 값이 많고 근거가 '과거에 제일 좋아서'뿐이면 과최적화·스누핑 동반 위험.
7. "미래 수익을 보장하실 수 있나요?" — "보장 못 한다"고 먼저 말하는 쪽이 오히려 신뢰할 만함. 보장을 말하면 그 자체가 경계 신호.

이 질문들에 구체적 수치·절차 없이 "믿고 맡기시라"로만 답한다면, 그 대답 자체가 하나의 데이터입니다. 반대로 좋은 제작자는 이 질문을 반깁니다. 자기 백테스트의 한계를 스스로 알고 있고, 그걸 투명하게 말하는 것이 결국 신뢰를 쌓는 길임을 알기 때문입니다. 백테스트 리포트에서 수익률 외에 무엇을 봐야 하는지는 백테스트 리포트 읽는 법 — 수익률 외 7가지에서 더 깊이 다뤘습니다.

10. 실전 시나리오 3가지

지금까지의 프레임을 세 가지 가상의 상황에 대입해 봅시다. 모두 개념 이해를 돕기 위한 예시이며 특정 결과를 예측하지 않습니다.

시나리오 A — 눈부신 곡선, 그러나 '한 종목'

누군가 특정 종목에서 +250%가 찍힌 백테스트를 자랑합니다. 물어보니 그는 수십 개 종목에 같은 전략을 돌려보고, 가장 잘 나온 하나를 골라 왔습니다. 나머지 종목 성적은? "그건 별로였다"고 얼버무립니다. → 이건 전형적인 종목 스누핑(위 4장 ②)입니다. 그 +250%는 실력이 아니라 수십 번 던져 나온 앞면일 수 있습니다. 올바른 질문은 "전체 종목 평균은 어땠나요? 미리 정한 하나의 종목·바구니에서 검증했나요?"입니다.

시나리오 B — 정직한 '실망스러운' 리포트

다른 제작자는 훨씬 밋밋한 곡선을 보여줍니다. 대신 이렇게 말합니다. "개발은 2019~2022로 하고, 2023~2024는 손대지 않고 마지막에 한 번만 검증했습니다. 검증 기간 성적은 개발 기간보다 낮지만 방향은 유지됐고, 비용도 넉넉히 넣었습니다. 최악 낙폭은 이 정도였고, 미래는 보장 못 합니다." → 곡선은 덜 화려해도, 이 리포트가 훨씬 믿을 만합니다. 불확실성을 감추지 않았고, 표본외 검증과 비용 반영이라는 방어를 지켰기 때문입니다.

시나리오 C — 개발자 자신이 빠지는 함정

직접 파이썬으로 전략을 만드는 분도 예외가 아닙니다. 백테스트를 돌려 손실 구간이 보일 때마다 "이 조건 하나만 추가하면…"을 스무 번 반복했더니, 과거 곡선이 거짓말처럼 매끈해졌습니다. 하지만 그는 같은 데이터를 스무 번 훔쳐본 것입니다(위 4장 ⑤·⑥). → 실전에서 무너질 위험이 큽니다. 방어는 간단합니다. 손대지 않은 기간을 미리 떼어 두고, 조건을 덧댈 때마다 시도 횟수로 세는 것. 파이썬으로 시작하는 분들을 위한 기초는 파이썬 자동매매 입문 완전 가이드에 정리돼 있습니다.

11. 흔한 오해 5가지

12. 맡길 때 물어볼 것 · 한 장 요약

자동매매를 제작·위탁할 때, 데이터 스누핑에 대한 방어가 설계에 들어 있는지 확인하는 핵심을 한 표로 정리합니다.

13. 자주 묻는 질문