LLM 백테스트가 샤프 레이쇼를 부풀리는 이유 — 파라메트릭 미래 누수 방어법
백테스트 결과가 의심스럽게 좋았습니다. 샤프 레이쇼 2 넘는데 실거래는 마이너스. point-in-time DB는 깨끗한데 원인은 다른 곳 — LLM이 사전학습 메모리로 미래를 이미 알고 있었던 겁니다. 코드 레벨 look-ahead 방어는 LLM 앞에서 무력화됩니다. 최근 논문 3편(TEMPO, Look-Ahead-Freedom, Oracle)이 각기 다른 각도로 공략했는데, 실무에서 당장 쓸 수 있는 건 형식 검증(LAF)입니다.
제가 평가한 기준 — 방어 깊이와 적용 난이도
세 논문을 실무 적용 관점에서 비교했습니다. 기준은 방어가 코드에서 작동하는지, 모델 안에서 작동하는지였고, 두 번째는 지금 내 파이프라인에 적용 가능한가였어요. 제 환경은 Python 백테스트에 LLM을 뉴스 감성·재무제표 요약 용도로 넣은 구조입니다.
평가 축은 세 개 — 커버리지(어떤 누수를 막나), 확실성(실패 여지), 도입 비용(코드 수정만으로 되는지, 모델 재훈련 필요한지).
세 논문을 실무 렌즈로 평가하기
같은 전략을 대상으로 삼았습니다. 분기보고서 나오면 LLM이 실적 서프라이즈 방향 판단, 긍정이면 매수하는 구조. 2020~2023년 S&P 500 구성종목입니다.
TEMPO — 모델에게 시간 개념을 학습시키기
모델 자체를 고치는 접근입니다. 강화학습(GRPO)으로 LLM이 시간적 규율을 학습하게 만들어요. 누수 모드에서 post-cutoff 정보 사용을 0으로 만들고, 달성되면 성과 모드로 넘어가 정확도를 올립니다.
논문에선 누수율을 2~13%에서 0.6~3.7%로 줄였다고 보고했어요(출처: TEMPO 논문 Abstract). 예측 성과는 6~13% 개선. 제가 볼 때 가장 근본적 해법입니다 — 모델이 스스로 시간을 지키니까요. 문제는 적용 문턱. LoRA 파인튜닝 환경 필요하고 보상 함수를 작업마다 설계해야 해요.
핵심 통찰 — "지식을 지우는 게 아니라 사용 규칙을 학습시킨다" — 은 프롬프트 설계에 반영했어요. "이 날짜 이후 정보 사용 금지"보다 "이 날짜에 당신이 알 수 있는 정보만"이 더 낫더라고요.
Look-Ahead-Freedom — 파이프라인을 형식 검증하기
완전히 다른 접근. 모델을 건드리지 않고 파이프라인 코드를 정적 분석해서 미래 누수 가능성을 판정합니다. 보안 이론의 non-interference를 시간 축으로 적용 — "시점 t의 결정이 t 이후 데이터에 영향받지 않는가"를 타입 시스템으로 검증.
현실 파이프라인 대부분이 쓰는 value-independent fragment(윈도잉, 리샘플링, point-in-time 읽기)에선 선형 시간 안에 판정 가능합니다.
논문 artifact를 제 백테스트 코드에 돌려보니 두 군데서 경고 — 뉴스 데이터 조인이 발행일(published_at) 아닌 수집일(fetched_at) 기준이었고, 재무제표 리스테이트먼트 문제(최종 수정본 대신 as-reported 써야 함)가 있었어요.
장점은 확실성 — 통과하면 파이프라인 레벨 누수 없다는 보장. 단점은 LLM 내부 누수는 못 막음. 필요조건이지 충분조건 아닙니다.
Oracle — 탐지 후 대조군 비교
제목에서 의도 드러남 — "오라클을 소환해서 죽이기". 미래를 아는 모델(oracle)과 모르는 모델의 성과 차이로 누수 여부를 역산. 이건 탐지 도구지 방어책 아닙니다.
실무에선 비슷한 걸 이미 쓰고 있었어요 — walk-forward 기간을 밀면서 성과 급락 지점을 찾는 거죠. 2023년 6월까지 샤프 2.1인데 7월부터 -0.3이면 누수 의심. 문제는 사후약방문 — 누수를 찾긴 하는데 어디서 왜 새는지는 안 알려줍니다.
실무 점검 순서 — 계층 방어가 답
두 달 전 실거래 전환 전 만든 절차입니다.
1단계 — LAF 타입 검증 먼저 돌립니다. 파이프라인 코드에서 구조적 누수(타임스탬프 오정렬, 미래 조인)를 잡아내요. 5분이면 끝나고, 통과해도 안심은 못 하지만 fail이면 확실히 문제.
2단계 — 프롬프트 강화. TEMPO의 temporal discipline 개념을 빌려 cutoff 날짜 명시하고 "이 시점에서 알 수 있는 정보만 사용" 제약을 겁니다. 날짜를 세 번 반복하고 few-shot 예시에 "미래 정보 금지" 케이스 포함. 완벽하진 않지만 누수율이 체감상 절반은 줄어요.
3단계 — walk-forward 대조군. Oracle 변형 — cutoff 날짜만 바꿔가며 백테스트하고 성과 변동성 봅니다. 2023년 6월 cutoff 샤프 2.0, 7월 0.5면 누수 의심. 정상 전략은 cutoff가 한두 달 밀려도 성과가 완만히 변합니다.
핵심은 계층 방어예요. 코드 검증(LAF) + 프롬프트 규율(TEMPO 개념) + 사후 탐지(Oracle) 다 필요합니다. 모델 내부 메모리는 코드로 못 막으니 프롬프트나 파인튜닝으로 보완할 수밖에 없어요.
자주 묻는 질문
Q. LAF 검증 통과했으면 안전한가요? A. 파이프라인 레벨만 안전합니다. LLM 사전학습 메모리 누수는 별개 — 프롬프트 규율이나 TEMPO 같은 모델 레벨 방어가 추가로 필요해요.
Q. 외부 API 모델(Claude, GPT-4)로도 TEMPO 적용 가능한가요? A. 불가능합니다. TEMPO는 LoRA 파인튜닝이 필요한데 API 모델은 가중치 접근이 안 돼요. 프롬프트에 temporal discipline 개념만 반영하는 게 차선입니다.
Q. walk-forward 대조군에서 성과 변동이 얼마나 크면 누수로 봐야 하나요? A. 절대 기준은 없지만, cutoff 한 달 차이로 샤프 레이쇼가 1.0 이상 변하면 의심해야 합니다. 정상 전략은 0.2~0.3 내외 변동이 일반적이에요.
상황별 선택 가이드
제 결론은 명확합니다 — 인프라 환경이 우선순위를 결정해요.
자체 호스팅 모델(Llama, Mistral 등)을 쓰고 있다면 TEMPO가 최우선. 파인튜닝 파이프라인만 구축하면 되고, 한 번 학습시키면 이후 모든 백테스트에서 방어가 작동합니다. 프롬프트보다 확실하고 추가 지연도 없어요. LAF 검증은 파인튜닝 전 파이프라인 정리 단계로 먼저 돌리고, walk-forward는 검증 목적으로 주기적으로 확인하세요.
외부 API 모델(Claude, GPT-4 등)을 쓴다면 LAF → 프롬프트 → walk-forward 순서대로 쌓으세요. TEMPO는 불가능하니 프롬프트 규율을 최대한 강화하는 게 핵심입니다. 저는 cutoff 날짜를 프롬프트 선두·중간·말미 세 군데 배치하고, few-shot 예시 6개 중 2개를 시간 규율 위반 케이스로 채웠어요.
인프라 전환을 고민 중이라면 백테스트 LLM 의존도가 판단 기준. 뉴스 감성·재무제표 요약 정도로만 쓴다면 API로 충분해요. 하지만 복잡한 멀티모달 전략(차트+뉴스+재무 조합)이나 실시간 트레이딩 루프에 LLM이 깊게 박혀 있다면 자체 호스팅 전환이 맞습니다. TEMPO 한 번 학습시키면 누수 방어 비용이 0이 되거든요.
어떤 선택을 하든 walk-forward 대조군은 필수. 성과 급락 지점이 보이면 어디서 새는지 찾아야 하니까요.