워밍업 모드¶

일부 환경에서는 전략 시작 직후 히스토리 적재 구간(워밍업)을 둘 수 있습니다.

현재 DSL 기준 상태¶

현재 DSL 컨텍스트에는 warm_up 변수가 주입되지 않습니다.

즉, 아래 코드는 현재 기준으로 동작하지 않습니다.

# 현재 컨텍스트에서는 사용 불가
if warm_up:
    hold()

대안¶

히스토리 충분성은 c.close.is_valid(n)으로 직접 확인
초기 구간 차단 로직은 var 카운터로 구현

c = chart("1D")
var.init(run_count=0)
var.run_count = var.run_count + 1

if not c.close.is_valid(50):
    hold(tag="히스토리 부족")
else:
    # 정상 로직
    hold(tag="ready")

멀티 타임프레임에서의 워밍업¶

멀티 타임프레임 전략(예: 5분봉 + 일봉)에서 상위 타임프레임의 과거 봉은 하위 프레임 데이터와 독립적으로 로딩됩니다. 따라서 5분봉 데이터가 3일치뿐이더라도 일봉이 200일치 로딩되면 ta.sma(d1.close, 60) 같은 장기 지표가 정상 계산됩니다.

c.bars는 로딩된 전체 봉 수를 반영하므로, c.bars < 60 같은 워밍업 조건은 상위 타임프레임 히스토리가 충분하면 즉시 통과합니다.

데이터 로딩 실패¶

데이터 로딩에 실패하면 부분 성공으로 처리하지 않습니다. 실패 시 전략 실행이 중단됩니다. 차트 로딩 실패 해결은 FAQ를 참고하세요.

무체결 구간 동작¶

라이브 실행 중 실시간 틱이 없는 구간에서도 봉 마감 타이머가 봉 확정을 유지합니다.

무체결 확정 봉은 거래량 0으로 생성될 수 있습니다.
최신 거래일 분봉 데이터는 공급 지연으로 장 마감 직전 봉이 일부 없을 수 있습니다.

캔들 프리워밍 (always-on)¶

런타임이 기동하고 Upbit 자격증명이 활성화되면, 엔진 ON/OFF나 전략 등록과 무관하게 항상 KRW 마켓 전체의 캔들 이력을 백그라운드로 미리 적재합니다. 이렇게 받아둔 이력은 @universe.metric 메트릭 스윕, 스크리너 테스트 패널, 차트 미리보기가 모두 공유합니다.

동작 순서¶

런타임 시작 직후 Upbit 자격증명 확인 → KRW 마켓 목록 조회.
모든 종목 × 9개 봉 스케일(1T/3T/5T/10T/15T/30T/60T/1H/4H)에 대해 REST 캔들 200봉씩 사전 적재. 일봉(1D)은 Upbit day-candle 경계(KST 09:00)와 라이브 봉 경계(KST 00:00) 차이 때문에 정규화가 도입되는 다음 단계까지 제외됩니다.
디스크 캔들 캐시(UpbitCandleStore)가 이미 가지고 있는 쌍은 REST 호출 없이 즉시 사용 — Upbit 요청 한도(10 req/s)를 우회합니다.
디스크 캐시에 없는 쌍만 10 req/s 한도 내에서 REST로 채웁니다.

예상 소요 시간¶

첫 기동(콜드): 200종목 × 9스케일 = 약 1,800쌍 → 명목 180초 내외.
재기동(웜): 디스크 캐시가 살아 있으면 모든 쌍이 fast-path로 처리돼 초 단위로 완료.

평가 readiness gate (PR-B 도입)¶

워밍업 완료 신호는 app.state.candle_warmup_progress.is_candle_warmup_ready(...)를 통해 라이브 surface 3개에 일괄 readiness gate로 적용됩니다:

라이브 트레이드 (process_tick): 워밍업 완료 전에는 cross-ticker 캔들 저장소 갱신만 수행되며 DSL 평가·주문 제출은 차단됩니다. 워밍업 완료 시점에 stale 데이터 없이 평가가 즉시 재개되도록 cross-ticker 갱신은 게이트 적용 전에 처리됩니다.
유니버스 메트릭 스윕 (evaluate_metric_sweep_task): 시간 기반 스윕 루프와 봉 close drain 모두 차단됩니다.
Studio "스크리너 테스트" (POST /api/studio/screener-sweep): 503 + detail.code == "warmup_in_progress" + 진행률(detail.progress)을 반환합니다. UI는 "워밍업 진행 중" 카드로 안내합니다.

REST 시점 스냅샷은 /api/state 응답 engine 블록에서 노출됩니다:

{
  "engine": {
    "running": true,
    "warmup_phase": "WARMING_UP",
    "warmup_progress": {
      "ready": false,
      "pct": 0.42,
      "loaded_pairs": 84,
      "total_pairs": 1800,
      "total_tickers": 200,
      "required_scales": ["1H","1T","3T","4H","5T","10T","15T","30T","60T"]
    }
  }
}

warmup_phase는 WARMING_UP 또는 READY 두 값을 갖습니다. 자격증명이 등록되지 않은 부팅 경로에서는 READY로 시작해 게이트가 열린 상태로 동작합니다(워밍업이 시작되지 않은 경로를 차단하지 않기 위함).

활성화된(enabled=true) 전략은 워밍업 동안 strategy row의 pending_warmup 파생 필드가 true로 표시됩니다 — UI는 이 필드로 PENDING 배지를 렌더해 "활성화돼 있으나 캔들 데이터 준비 중"임을 알립니다. 워밍업 완료 시 추가 사용자 액션 없이 자동으로 평가가 재개되며 배지가 사라집니다.

백테스트(/api/backtest/full-report)는 자체 히스토리 빌드 경로를 사용하므로 readiness gate 대상이 아닙니다.

WS 진행 이벤트: `candle_warmup_progress`¶

워밍업 진행 상황은 WS 스트림으로 매 (종목, 스케일) REST 페치 완료마다 push되며, frontend는 운영 스트립("전체 종목 워밍업 중" row)과 ScreenerTestPanel PENDING 카드에서 reactive로 구독해 사용자 액션 없이 자동 갱신됩니다. 이벤트 스키마:

{
  "type": "candle_warmup_progress",
  "total_tickers": 200,
  "required_scales": ["5T", "1H"],
  "loaded_pairs": 120,
  "total_pairs": 400,
  "pct": 0.3
}

필드	설명
`total_tickers`	스코프 종목 수
`required_scales`	필요한 봉 스케일 목록
`loaded_pairs`	로드 완료된 (종목, 스케일) 쌍 수
`total_pairs`	전체 (종목, 스케일) 쌍 수
`pct`	진행률 0.0~1.0