백테스트(Backtest, BT)는 무거운 처리입니다. 시그널을 15개 생성하여 각각을 IS(In-Sample) 기간 및 OOS(Out-of-Sample) 기간으로 테스트하면, 1회의 야간 배치(Batch) 작업에 수 시간이 걸립니다.

이 기사에서는 과거의 백테스트 결과로부터 "합격할 것 같은 후보"를 LightGBM으로 예측하여, BT 실행 전에 후보의 78%를 기각하는 메커니즘의 구현을 소개합니다.

문제: 백테스트가 병목 현상(Bottleneck)

자동 매매 Bot 개발에서는 알파(Alpha, 이익 기회)를 탐색할 때 대량의 후보를 백테스트해야 합니다.

필자가 운용하고 있는 GMO coin용 시스템에서는 매일 밤 15개의 후보를 생성하여 IS/OOS 평가를 수행하고 있습니다. 합격률은 약 2.75%(2,036개 후보 중 56개 합격)입니다.

즉, 97.25%의 후보는 BT를 돌려도 불합격입니다. 이 낭비를 줄일 수 있다면, 동일한 계산 비용으로 더 많은 후보를 탐색할 수 있습니다.

합격률: 56 / 2036 = 2.75%
→ 100개 후보 BT를 해도 2~3개만 합격
→ 합격하지 않는 97개의 BT 시간이 통째로 낭비됨

접근 방식: 메타 모델(Meta-model)로 사전 필터링

아이디어는 간단합니다.

과거의 BT 결과를 트레이닝 데이터(Training Data)로 사용하여, "이 전략 타입 × 통화 쌍 × 시간 프레임의 조합은 합격하기 쉬운가?"를 학습시킨다.

이것이 "대리 모델(Surrogate Model)"이라고 불리는 접근 방식입니다. 실제 BT를 실행하는 대신, 저렴한 예측을 통해 사전에 후보를 좁힙니다.

특징량(Feature): 단 3개의 범주형 변수

놀라울 정도로 심플하며, 특징량은 다음 3가지만 사용합니다.

"BT 결과의 수치(PF, Calmar ratio 등)는 사용하지 않나?"라고 생각하실 수도 있습니다.

사용하지 않습니다. 이유는 두 가지입니다.

• BT 전 시점에서는 당연히 BT 결과가 존재하지 않음 (추론 시에 사용할 수 없음)
• "어떤 조합이 역사적으로 합격하기 쉬운가"라는 구조적 패턴을 배우고 싶음

구현 코드

학습 (train_categorical_surrogate.py)

import csv, json, pickle
from pathlib import Path
import pandas as pd
...

추론 (auto_bt_runner.py 내)

import pickle
from pathlib import Path
# 모델 로드
...

결과: 78.5%의 후보를 기각

평가 결과(evaluation_report.json):

데이터: 2,036건 (합격=56, 합격률=2.75%)
5-fold CV AUC: 0.753 ± 0.048
임계값(Threshold) 0.30에서의 성능:
...

임계값 0.30이라는 낮은 설정이 중요한 포인트입니다.

"합격하기 쉽다"라는 확신이 없더라도 합격 가능성이 있는 후보는 모두 BT를 실행합니다. 정밀도(Precision)보다 재현율(Recall)을 최우선으로 한 설계입니다.

합격 후보를 놓칠 리스크보다, 불필요한 BT를 줄이는 것이 목적이므로 이 설계는 합리적입니다.

실제 BT 절감 효과:

• 15개 후보 → 78.5% 기각 → 실제로 BT를 하는 것은 약 3.2개 후보 (15 × (1 - 0.785))
• 탐색 효율: 이론상 약 5배 (15 ÷ 3.225)

구현 시 주의할 점 (ハマりポイント)

pickle + LightGBM의 환경 의존성 문제

categorical_surrogate.pkl은 LightGBM 모델을 pickle로 직렬화한 것입니다. 이 파일을 로드하려면 실행하는 Python 환경에 lightgbm이 설치되어 있어야 합니다.

필자의 경우, 학습 환경(.venv_ml)과 BT 실행 환경(.venv_quant)에서 venv를 나누어 사용하고 있었습니다.

학습: .venv_ml/bin/python3 → lightgbm ✅
실행: .venv_quant/bin/python3 → lightgbm ❌ (설치 누락!)

이 상태에서 cron이 야간에 실행되면, 다음과 같은 에러가 발생하며 조용히 실패합니다:

ModuleNotFoundError: No module named 'lightgbm'

수동 실행은 별도의 쉘에서 venv를 활성화(activate)하여 작동하고 있었기 때문에, "수동은 성공하지만 cron은 실패하는" 수수께진 증상이 나타났습니다.

교훈: pickle로 직렬화된 ML 모델을 별도의 venv에서 사용할 경우, 의존 라이브러리(dependency library)가 설치되어 있는지 반드시 확인해야 한다.

# cron에서 사용하는 python에 lightgbm이 있는지 확인
/path/to/.venv_quant/bin/python3 -c "import lightgbm; print(lightgbm.__version__)"

학습 데이터의 품질이 핵심

2,036개의 샘플로 학습했다고는 하지만, 합격률 2.75%(56/2036)라는 극단적인 불균형 데이터(imbalanced data)입니다.

scale_pos_weight = 불합격 수 / 합격 수 = 1980 / 56 ≈ 35

라는 가중치 부여가 없다면, 모델은 모든 데이터를 "불합격"으로 예측할 뿐입니다.

LightGBM의 LGBMClassifier에는 scale_pos_weight 파라미터가 있으며, 이를 설정함으로써 불균형 데이터를 다룰 수 있습니다.

미지의 카테고리 (새로운 전략 추가 시)

새로운 전략 타입(strategy type)을 추가할 경우, LabelEncoder가 미지의 카테고리(unknown category)를 만나 에러가 발생합니다.

# 대책: 미지의 카테고리를 핸들링
try:
    enc_val = encoder.transform([category])[0]
...

구현에서는 미지의 카테고리가 들어올 경우 대리 필터(surrogate filter)를 통과하도록 설계했습니다.

요약

단 3개의 카테고리 변수만으로 78%의 BT(백테스트)를 스킵할 수 있는, 심플하고 효과적인 대리 모델(surrogate model) 구현을 소개했습니다.

포인트를 정리하면:

• 특징량(feature)은 "전략 타입 × 통화쌍 × 시간봉" 3가지만 사용
• LGBMClassifier + scale_pos_weight (불균형 대응)
• 임계값(threshold)은 낮게(0.30) 설정하여 high-recall 설계
• pickle 로드 시 lightgbm의 venv 확인 필수

대리 모델은 탐색 효율화의 기초 단계이지만, 실제 운용 시 축적된 BT 데이터가 늘어날수록 정밀도가 향상됩니다. 2,036건에서 AUC=0.753이었으나, 데이터가 두 배가 된다면 추가적인 개선을 기대할 수 있습니다.

관련 기사

Discussion