Binance Auto Trader
사용자 매뉴얼

처음이라면 이 순서만 따라 하세요

Binance Auto Trader는 바이낸스 USDⓈ-M 선물 시장에서 시장 상태를 분류하고, Trend Following과 Mean Reversion 전략을 자동으로 실행합니다. 프로그램을 켠 직후 실거래부터 시작하지 말고 아래 순서를 지키는 것이 중요합니다.

이 매뉴얼을 읽는 가장 빠른 방법

• 처음 사용자: 가입 · API 설정 → 첫 실행 순서 → 백테스트 3단계 → 실거래 체크
• 운영 중인 사용자: Trading 설정 → 화면 패널 → Trade History → 문제 해결
• 전략을 조정하는 사용자: Regime → TF/MR → 포지션 사이징 → 백테스트 엔진

바이낸스 가입 및 API 설정

1. 바이낸스 계정 준비

프로그램 상단의 바이낸스 가입 버튼을 누르면 가입 페이지를 열 수 있습니다. 계정 생성, 본인 인증, USDⓈ-M Futures 활성화를 순서대로 완료하세요. 이미 계정이 있다면 이 단계는 건너뜁니다.

2. Binance에서 API Key 생성

1. 1
   API Management 열기
   바이낸스 계정의 API 관리 화면으로 이동합니다.
2. 2
   새 API 생성
   알아보기 쉬운 이름을 지정하고 보안 인증을 완료합니다.
3. 3
   Key와 Secret 보관
   Secret은 생성 직후 한 번만 표시될 수 있으므로 안전한 곳에 보관합니다.
4. 4
   권한 설정
   읽기와 Futures 거래 권한만 활성화하고 출금 권한은 활성화하지 않습니다.

API 권한 체크

3. 프로그램에 API 입력

1. 1
   프로그램 상단에서 API 설정 버튼을 누릅니다.
2. 2
   API Key와 Secret Key를 붙여넣습니다. Secret은 화면에서 마스킹됩니다.
3. 3
   처음 연습할 때는 Testnet을 선택하고 테스트넷 전용 Key를 입력합니다. 실거래 Key와 테스트넷 Key는 서로 다릅니다.
4. 4
   저장 후 연결 상태와 Account Dashboard의 잔고 표시를 확인합니다.

첫 실행 순서

• 1
  프로그램 실행
  배포 실행 파일 또는 최신 Python 파일을 실행합니다. 창 제목이 현재 배포 버전인지 확인하세요.
• 2
  API 연결 확인
  API 설정에서 Key를 저장하고 Account Dashboard에 잔고가 표시되는지 확인합니다.
• 3
  Market과 제외 종목 설정
  CRYPTO / TRADFI / ALL 중 대상을 고르고, 거래 제한 또는 원하지 않는 종목을 Excluded Symbols에 한 줄씩 입력합니다.
• 4
  Cache Manager 확인
  최초 캔들 다운로드는 백그라운드에서 계속됩니다. 최근 데이터가 준비되면 Trading은 시작할 수 있지만 장기 백테스트는 필요한 기간의 캐시가 준비된 뒤 실행하는 편이 좋습니다.
• 5
  백테스트 3단계 실행
  Sweep으로 후보를 찾고 Validation과 Walk-forward로 과최적화 여부를 확인합니다.
• 6
  추천 설정 적용 후 다시 확인
  Apply Best Settings를 누른 뒤 Market, Top N, Timeframe, 레짐별 파라미터가 Trading 탭에 의도대로 반영됐는지 직접 확인합니다.
• 7
  Testnet 또는 소액으로 시작
  Start Auto Trade를 누르고 Log, Current Top N, Open Positions, Trade History를 함께 확인합니다.

권장 시작값 (보수적)

Cache Manager

프로그램은 Parquet 기반 캔들 캐시를 사용합니다. 최초 실행 시 필요한 캔들을 백그라운드에서 구축하며, 이후에는 새로 마감된 캔들만 증분 업데이트합니다.

동작 방식

• 1
  manifest 확인
  프로그램 시작 시 manifest.json을 읽어 심볼별 캐시 상태를 즉시 확인합니다. manifest는 각 심볼의 첫 캔들·마지막 캔들 시각만 저장하는 경량 인덱스(65KB 수준)입니다.
• 2
  Trading 우선
  최근 데이터 확보 후 자동매매는 즉시 시작할 수 있으며, 나머지 히스토리는 백그라운드에서 계속 구축됩니다.
• 3
  주기적 증분 업데이트
  선택된 Decision / Execute / Trailing TF와 Dynamic TopN 볼륨 랭킹용 4h 캔들을 주기적으로 추가합니다. 업데이트가 끝난 뒤 다음 마감봉 시간까지 대기하므로, 긴 다운로드 중에 다음 업데이트가 중복 큐잉되지 않습니다.
• 4
  백테스트 API Skip
  백테스트 실행 시 manifest를 메모리에 로드하여 심볼별로 O(1) 신선도 체크를 수행합니다. 캐시가 신선하면 API 호출 없이 parquet 파일만 읽어 반환합니다. 캐시 구축 완료 후 반복 백테스트에서 API 호출이 0회로 줄어듭니다.
• 5
  안전 저장
  Atomic Write(.tmp→rename)를 사용하여 종료 중에도 기존 캐시를 보호합니다. manifest는 백테스트 Pass 종료 시 최대 2회 일괄 저장합니다.

Trading 탭

라이브 자동매매의 모든 설정이 이 탭에 집중됩니다. 자동매매 실행 중에는 설정 필드가 비활성화됩니다.

기본 설정

3-TF Entry Engine

Trend Following 전략은 판단과 실행을 분리한 3단계 타임프레임 구조를 사용합니다. Decision TF는 방향을 허가하고, Execute TF는 실제 진입 타이밍을 확인하며, Trailing TF는 진입 이후 청산을 관리합니다.

Regime Settings

각 레짐(QUIET · NORMAL · TREND · PANIC)마다 전략과 파라미터를 독립적으로 설정합니다. 체크박스 OFF 시 해당 레짐에서 신규 진입 없음.

Exit Mode 비교

CI Filter (선택)

Choppiness Index(CI)를 이용해 횡보 구간에서 Trend Following 진입을 차단합니다. Mean Reversion 전략에는 적용되지 않습니다.

서버 Stop (Server-side STOP_MARKET)

포지션 진입 시 Binance 서버에 STOP_MARKET 주문을 자동으로 등록합니다. 봇 프로세스가 다운되거나 네트워크가 끊어진 상황에서도 거래소가 손절을 대신 실행합니다.

정지 / 비상 청산

Trading 화면 패널

실거래 중에는 설정값보다 상태 패널을 더 자주 확인하게 됩니다. 아래 네 영역만 익혀도 현재 프로그램 상태를 빠르게 판단할 수 있습니다.

Excluded Symbols

자동매매에서 제외할 심볼을 한 줄에 하나씩 입력합니다. 예: BTCUSDT. 저장된 목록은 실거래뿐 아니라 Sweep, Validation, Walk-forward에도 동일하게 적용됩니다.

Start · Stop · Emergency Close

Trade History

프로그램이 관리한 거래와 Binance 체결 내역을 바탕으로 진입·청산·실현손익을 보여 줍니다. 프로그램을 다시 실행하면 최근 3일의 Binance 거래 내역을 불러와 기록을 보완합니다.

Backtest Sweep 탭

여러 파라미터 조합을 일괄 테스트해 레짐별 최적 파라미터를 탐색합니다. Sweep은 각 Regime을 독립적으로 테스트하여 후보 세팅을 찾는 단계이며, 실제 시간축 Adaptive 성과 검증은 Validation 탭에서 수행합니다.

Sweep 방식

파라미터 리스트 입력

각 파라미터 필드에 콤마(,)로 여러 값을 입력하면 해당 레짐의 Cartesian Product로 테스트됩니다.

# 예시: NORMAL 레짐
ADX Min:  20, 25, 30
ATR Mult: 1.5, 2.0
Vol Mult: 1.2
Trigger R:1.0, 1.5
Risk %:   0.5

# NORMAL 조합 수: 3 × 2 × 1 × 2 × 1 = 12

Sweep 설정 파라미터

Sweep Combos 카드

Settings 박스 우측에 표시되는 카드입니다. 현재 입력값 기준으로 레짐별 조합 수와 총합, 예상 소요 시간을 실시간으로 계산합니다.

결과 해석

Apply Regime Best

Sweep 완료 후 [Apply Regime Best #1] 버튼을 클릭하면 레짐별 최적 파라미터가 Trading 탭의 Regime Settings에 자동 적용됩니다.

Backtest Validation 탭

Sweep으로 선정한 레짐별 Best Setting을 실제 시간축에서 Adaptive 방식으로 검증합니다. Top N 적용, Regime 전환, 포지션 제한, 손익 곡선을 함께 반영하여 실 운용에 가까운 결과를 확인합니다.

Sweep vs Validation 비교

Walk-forward 탭

Validation 탭에 입력된 단일 설정값을 여러 시간 구간에 반복 적용하여, In-sample(IS) 성과가 Out-of-sample(OOS)에서도 얼마나 비슷하게 유지되는지 확인합니다. Walk-forward는 수익성이 좋은 설정을 찾는 기능이 아니라, 이미 선택한 설정의 시간축 일반화 안정성을 검사하는 기능입니다.

Sweep · Validation · Walk-forward 비교

동작 원리

# 실행 시 한 번 고정
Validation Settings Snapshot → 모든 Window 공통 적용

W1 → IS 계산 + OOS 계산 → PF Similarity 평가
W2 → IS 계산 + OOS 계산 → PF Similarity 평가
W3 → IS 계산 + OOS 계산 → PF Similarity 평가

세팅 방법

① Validation 탭 — 검증할 단일 설정 준비

검증하려는 설정을 Validation 탭에 입력합니다. Sweep 결과를 적용해도 되고, 사용자가 직접 입력한 설정을 사용해도 됩니다.

② Walk-forward 탭 — 기간·Window 설정

결과 테이블 컬럼

일반화 평가 기준

마지막 요약 창

권장 사용 절차

• 1Sweep
  필요한 경우 여러 조합에서 후보 설정을 탐색합니다.
• 2Validation
  선택한 단일 설정의 PF, Net PnL, MDD, 거래 수 등 절대 성과를 확인합니다.
• 3Walk-forward
  같은 Validation 설정으로 여러 Window의 PF Similarity와 Generalization Risk를 확인합니다.
• 4최종 판단
  Validation 수익성이 충분하고 Walk-forward Risk가 낮거나 허용 가능한 수준일 때 실전 후보로 검토합니다.

실행 시간

실거래 시작 전 최종 체크

아래 항목 중 하나라도 확인되지 않았다면 실거래 시작을 미루세요.

• API 설정에서 Testnet이 아닌 실거래 모드와 실거래 API Key를 선택했다.
• API에 Reading/Futures 권한만 있고 Withdraw 권한은 없다.
• Account Dashboard 잔고와 Binance Futures 잔고가 일치한다.
• Sweep 후보를 다른 기간의 Validation과 Walk-forward로 검증했다.
• 수수료와 슬리피지를 포함한 결과에서도 PF, MDD, 거래 수가 허용 범위다.
• Apply Best Settings 후 Market, Top N, TF, 레짐별 값을 Trading 탭에서 다시 확인했다.
• 거래 제한 종목과 원치 않는 종목을 Excluded Symbols에 입력했다.
• Leverage 3~5배, Risk 0.25~0.5%, Max Position 10~15% 등 보수적 값에서 시작한다.
• Start 후 Binance 앱에서 실제 주문·서버 Stop·포지션 수량을 직접 대조한다.
• 인터넷 장애나 프로그램 종료 시에도 대응할 수 있도록 Binance 앱에 로그인할 수 있다.

시장 Regime 분류

봉 마감 시점마다 ATR%(= ATR ÷ 현재가 × 100)를 계산해 4가지 레짐으로 분류합니다. 레짐에 따라 전략·파라미터가 자동 전환됩니다.

레짐별 파라미터 튜닝 가이드

Trend Following 전략

NORMAL · TREND · PANIC 레짐에서 사용합니다. EMA 크로스 + Donchian 돌파 + 거래량 급증 + ADX 필터 4가지 조건이 모두 충족될 때 진입합니다.

사용 지표

진입 조건 (4+1)

트레일링 스탑 메커니즘

Trailing TF 봉 기준 ATR이 변경되면 트레일링 거리도 동적으로 갱신됩니다.

Time Exit

포지션 개설 후 72시간이 경과하면 강제 청산합니다. 평균복귀가 장기간 실패하는 케이스를 방어하는 안전망입니다.

Mean Reversion 전략

QUIET 레짐(ATR% < 2, 저변동 횡보)에서 사용합니다. Bollinger Band 이탈 + RSI 과매도/과매수 + ADX Max 필터 3가지 조건이 모두 충족될 때 진입하고, BB 중간밴드(SMA20) 복귀 시 익절합니다.

사용 지표

진입 조건 (3가지 모두)

청산 로직

청산 우선순위

포지션 모니터링 루프에서 다음 순서로 청산 조건을 확인합니다.

포지션 사이징

두 가지 기준으로 수량을 계산한 뒤 더 작은 값을 최종 수량으로 사용합니다.

계산 예시

# 설정: 잔고=1000 USDT, Risk%=0.5, ATR=50, ATR Mult=2.0
# 레버리지=5, Max Position%=15, 현재가=2000 USDT

손절폭          = 50 × 2.0 = 100 USDT
Risk 기준 수량  = (1000 × 0.5%) ÷ 100 = 0.05 개
Cap 기준 수량   = (1000 × 15% × 5) ÷ 2000 = 0.375 개
최종 수량       = min(0.05, 0.375) = 0.05 개
# → 노셔널 0.05 × 2000 = 100 USDT / 증거금 = 100 ÷ 5 = 20 USDT

WebSocket & API 구조

PriceWebSocketManager

현재 보유 포지션 종목만 구독하는 mark-price WebSocket입니다. 포지션 변경 시 자동으로 구독 종목을 재동기화합니다.

UserDataWebSocketManager (UDS)

Binance User Data Stream으로 계정 이벤트(포지션 변경, 주문 체결)를 실시간 수신합니다.

REST Fallback

WS가 연결되었으나 5초 이상 페이로드가 없으면 DashboardThread가 REST로 전체 가격 스냅샷을 가져와 GLOBAL_PRICE_CACHE를 보충합니다.

API 모니터

Trading 탭 상단의 API Monitor 패널에서 API 호출 현황을 실시간으로 확인할 수 있습니다.

트러블슈팅

진입 신호가 전혀 없을 때

WS 연결 문제

포지션 관련

백테스트 속도 느림

Apply Regime Best 버튼 비활성화

Sweep 완료 후에도 버튼이 비활성화이면 backtest_results/parameter_sweep_summary.csv 파일이 없는 것입니다. Sweep이 정상 완료됐는지 로그를 확인하세요.

로그 해석

Log 창에 출력되는 메시지의 형식과 의미를 시간 순서별로 정리합니다. 메시지에서 {} 부분은 실제 값으로 치환됩니다.

① 시작 시 (Startup)

② 진입 신호 (Signal)

③ 포지션 개설 (Open)

④ 포지션 모니터링 (Monitor)

⑤ 청산 (Close)

모든 청산 로그는 reason 필드로 원인을 구분합니다.

⑥ 경고 및 오류 (Warning & Error)

⑦ 백테스트 로그 (Backtest)

정상 진입~청산 로그 흐름 예시

# ① 신호 감지
SIGNAL BTCUSDT LONG / trend_following / REGIME=TREND ATR%=5.21 SET=...
# ② 수량 계산
BTCUSDT sizing: balance=1000.0, available=850.0, risk=5.0000(0.50%), ...
# ③ 진입 체결
OPEN BTCUSDT LONG qty=0.050 entry=42000.000000 SL=41520.000000 TRAIL_TRIGGER=42480.000000 ...
# ④ 서버 stop 등록
[SERVER STOP] BTCUSDT LONG stop=41520.000000 orderId=12345678
# ⑤ WS 구독 갱신
[WS] Active price stream symbols=3 reason=position_open
# ⑥ 트레일링 활성화
TRAILING ON BTCUSDT LONG trigger=42480.000000
# ⑦ 손절가 갱신 + 서버 stop 갱신 (반복)
TRAIL UPDATE BTCUSDT LONG SL=42200.000000 high=42680.000000
[SERVER STOP] BTCUSDT LONG stop=42200.000000 orderId=12345679
TRAIL UPDATE BTCUSDT LONG SL=42400.000000 high=42880.000000
[SERVER STOP] BTCUSDT LONG stop=42400.000000 orderId=12345680
# ⑧ 청산 + 서버 stop 취소
CLOSE BTCUSDT LONG reason=TRAILING_TAKE price=42400.000000 PnL=+20.0000 USDT
[SERVER STOP CANCEL] BTCUSDT orderId=12345680 TRAILING_TAKE

용어 사전

프로그램 UI 및 로그에 등장하는 모든 용어를 알파벳·가나다 순으로 정리합니다.

기술 지표 (Indicators)

설정 파라미터 (Parameters)

전략 및 레짐 (Strategy & Regime)

청산 및 리스크 (Exit & Risk)

백테스트 성과 지표 (Performance Metrics)

인프라 및 API (Infrastructure)

전체 아키텍처

프로그램은 GUI, 데이터 수집, 캐시, 백테스트 엔진, 실거래 엔진, 주문 실행 계층으로 나누어 동작합니다. 핵심 목표는 실거래와 백테스트의 종목 선정·지표 계산·진입/청산 로직을 최대한 동일하게 유지하면서, 반복 실행 속도를 캐시로 개선하는 것입니다.

아키텍처 다이어그램

PySide6 GUI
  │
  ├─ Trading Tab
  │    ├─ AutoTradeThread
  │    ├─ Price WebSocket
  │    ├─ User Data Stream
  │    └─ Order / Position Manager
  │
  ├─ Backtest Sweep
  │    └─ BacktestThread
  │
  ├─ Backtest Validation
  │    └─ BacktestThread
  │
  └─ Walk-forward
       └─ WalkForwardThread

Binance REST / WebSocket
  │
  ├─ Public Market Data
  │    └─ Candle Cache
  │         └─ Historical Build
  │              └─ Indicator Cache
  │                   └─ market_data Memory Cache
  │                        └─ Backtest / Validation / Walk-forward
  │
  └─ Private Account Data
       ├─ UserDataStream
       ├─ Position State Store
       └─ Order Engine

주요 구성 요소

데이터 흐름

데이터는 REST와 WebSocket에서 들어와 캐시와 메모리 구조를 거친 뒤 전략 엔진에 전달됩니다. 실거래와 백테스트는 실행 시점만 다를 뿐, 가능한 한 같은 지표와 조건을 사용하도록 설계되어 있습니다.

실거래 데이터 흐름

Price WebSocket
      │
      ▼
Global Price Cache
      │
      ▼
Position Monitor / Trailing Stop
      │
      ▼
Order Engine
      │
      ▼
Binance Futures

User Data Stream
      │
      ▼
Balance / Position / Order Event
      │
      ▼
Dashboard / Position State Store

백테스트 데이터 흐름

Binance REST 또는 Local Candle Cache
      │
      ▼
OHLCV DataFrame
      │
      ▼
Historical Build
      │
      ▼
Indicator Cache
      │
      ▼
market_data
      │
      ▼
Dynamic Top N Universe
      │
      ▼
Strategy Signal
      │
      ▼
Virtual Position / Exit Simulation
      │
      ▼
PnL / MDD / PF / Trade Log

데이터별 사용 위치

캐시 구조

캐시는 디스크 파일(재시작 후에도 유지)과 실행 중 메모리(백테스트 1회 동안 유지)로 구성됩니다. 각 계층이 역할을 분담하여 API 호출과 디스크 I/O를 최소화합니다.

캐시 계층 구조

── 디스크 (재시작 후에도 유지) ──────────────────────────────

1. manifest.json                 candle_cache/manifest.json
   심볼별 first/last open_time 인덱스 (65KB 수준)
   API 호출 없이 캐시 신선도를 즉시 판단하는 데 사용

2. Candle Cache (parquet)        candle_cache/{SYMBOL}/{interval}.parquet
   실제 OHLCV 캔들 데이터 (심볼당 100~200KB)
   CacheUpdateThread가 5분마다 새 캔들만 증분 추가

── 메모리 (백테스트 1회 실행 중 유지) ──────────────────────────

3. manifest_cache                백테스트 시작 시 manifest.json 전체 로드
   심볼별 O(1) 신선도 체크 → API skip 여부 결정
   다운로드 중 메모리만 갱신, Pass 종료 시 디스크에 1회 저장

4. market_data                   {symbol: {entry/execute/trailing: DataFrame}}
   parquet 읽기 결과를 메모리에 보관
   같은 실행 내 파라미터 조합 변경 시 재사용 (TF·기간 동일할 때)

5. Indicator Cache               {symbol: DataFrame with EMA/ADX/ATR/RSI/CI}
   _precompute_indicators() 결과
   같은 실행 내 모든 파라미터 조합이 공유

market_data 재사용 조건

같은 백테스트 실행 내에서 파라미터 조합을 바꿀 때, OHLCV 데이터(market_data)는 아래 조건에 따라 재사용 여부가 결정됩니다.

Dynamic Top N 알고리즘

Dynamic Top N은 실거래와 백테스트의 종목 선정 차이를 줄이기 위한 기능입니다. 고정된 Top N 목록을 전체 기간에 사용하지 않고, 4시간마다 과거 24시간 거래량 기준으로 Top N을 다시 선정합니다.

기본 개념

매 4시간마다:
  1. 각 종목의 직전 24시간 quote_volume 합산
  2. 거래량 기준 내림차순 정렬
  3. 상위 N개를 해당 4시간 구간의 활성 Universe로 지정
  4. 기존 보유 포지션은 계속 관리
  5. 신규 진입만 해당 시점의 Top N에 포함된 종목으로 제한

왜 전체 Universe 데이터를 준비하는가?

장기 백테스트에서는 어떤 종목이 특정 시점에 거래량 급증으로 Top N에 들어올지 사전에 알 수 없습니다. 따라서 Dynamic Top N의 정확도를 유지하려면 전체 Universe의 거래량 데이터를 기준으로 각 4시간 버킷의 Top N을 계산해야 합니다.

2-pass 다운로드와 ever-active

거래량 순위 계산에는 4h 캔들만 사용하고, 전략 TF(15m/5m 등)는 한 번이라도 Top N에 들어간 심볼(ever-active)에 대해서만 다운로드합니다. 4h 캔들은 Cache Manager가 백그라운드에서 미리 구축하므로, Sweep 실행 시 Pass 1은 대부분 캐시 읽기만 수행합니다. 이를 통해 전략 TF 다운로드 범위를 전체 Universe(~500개)에서 ever-active(~100개)로 대폭 줄입니다.

Pass 1: 전체 Universe(~500개) × 4h 캔들
        → 4h 캐시는 시작 시 백그라운드에서 사전 구축
        → Sweep 실행 시 manifest 신선 구간은 API 없이 parquet만 읽음
        → 4h vol_data 기반 Dynamic Top N 계산
        → ever_active = 어느 한 버킷에서라도 Top N에 포함된 심볼 집합

Pass 2: ever_active(~100개) × Decision / Execute / Trailing TF
        → 실제 전략 시뮬레이션에 사용할 market_data 구성

※ ever_active가 비어있으면(Pass 1 실패 등) "[WARN] Dynamic TopN empty; fallback to static TopN"
  로그와 함께 Static Top N으로 자동 전환됩니다.

Top N 변경 시 동작

Top N 값을 50에서 100으로 바꾸면 OHLCV 데이터는 재사용하고, 4시간 버킷별 활성 종목 목록만 다시 계산합니다. 따라서 Market, 기간, Timeframe이 같다면 Historical Build는 재사용할 수 있습니다.

백테스트 엔진 동작 방식

백테스트 엔진은 데이터 준비, 지표 계산, Dynamic Top N 생성, 신호 탐색, 가상 체결, 포지션 관리, 결과 집계 순서로 동작합니다.

실행 순서

• 1
  기간 설정
  Recent Days 또는 Date Range 기준으로 테스트 기간을 결정합니다. 지표 안정화를 위해 앞쪽 warm-up 구간을 추가로 확보합니다.
• 2
  manifest 사전 로드
  manifest.json을 메모리에 로드합니다. 이후 심볼별 신선도 체크가 O(1)로 동작하여 API 호출 생략 여부를 즉시 결정합니다.
• 3
  Pass 1 — 4h 볼륨 캐시 로드
  전체 Universe(~500개) × 4h 캔들을 읽습니다. 4h 캔들은 시작 시 백그라운드에서 미리 업데이트되며, manifest가 신선하면 API 호출 없이 parquet만 읽습니다. 부족한 구간만 보충 다운로드하고 결과를 vol_data로 수집합니다.
• 4
  Dynamic Top N 생성 / ever-active 계산
  vol_data 기반으로 4h 버킷별 Top N 목록을 빌드하고, ever-active(전체 기간 중 한 번이라도 Top N에 포함된 심볼 집합)를 도출합니다.
• 5
  Pass 2 — 전략 TF 다운로드
  ever-active 심볼(~100개)만 Decision / Execute / Trailing TF 캔들을 읽습니다. 역시 manifest 신선 시 API 0회. 결과를 market_data로 수집합니다.
• 6
  Indicator 계산
  EMA, ADX, ATR, RSI, CI 등을 심볼당 1회 계산합니다. Sweep은 프로세스 경계를 OHLCV만 통과시키고, 각 worker 프로세스 초기화 시 독립 계산합니다 (pickle 전송량 감소). Walk-forward는 부모 프로세스에서 1회 계산 후 전체 윈도우가 재사용합니다.
• 7
  신호 탐색
  Regime, Strategy, ADX, Volume/RSI, Donchian/BB 조건을 확인해 진입 후보를 만듭니다.
• 8
  가상 체결 및 포지션 관리
  Risk %, Max Position %, Max Long/Short, Leverage, 수수료, 슬리피지를 반영해 포지션을 시뮬레이션합니다.
• 9
  결과 집계
  Net PnL, PF, Win Rate, MDD, Trades, Daily PnL, 레짐별 성과를 계산합니다.

Sweep / Validation / Walk-forward 차이

체결 모델

백테스트는 실제 주문을 내지 않고 가상 포지션을 생성합니다. 수수료와 슬리피지를 반영하여 실거래에 가까운 결과를 계산합니다.

성능 최적화

백테스트 속도는 API 다운로드 → SSD 읽기(parquet) → Indicator 계산 → 전략 조합 실행 순으로 나뉩니다. 각 단계를 캐시와 skip 로직으로 최소화하는 구조입니다.

실행 상황별 속도

최적화 기법 목록

주요 로그 해석

[Pass 1/2] 볼륨 랭킹용 4h 캔들 다운로드: N개 심볼
  → 전체 Universe × 4h 캔들 읽기 시작
  → manifest 신선하면 API 0회, parquet만 읽음

[Pass 2/2] ever-active N개 심볼 전략 TF 다운로드
  → 적어도 한 번 TopN에 든 심볼만 전략 TF 읽기

VOL N/M {sym}     → Pass 1 진행 현황
STRAT N/M {sym}   → Pass 2 진행 현황

[WF-VOL N/M]  / [WF-STRAT N/M]
  → Walk-forward 2-pass 진행 현황