트레이딩 전략 백테스팅 방법론

Stingray 백테스트는 범위가 분명한 질문 하나에 답하도록 설계됩니다. 구체적인 typed market rule이 명시된 과거 기간에 어떻게 작동했는가? 결과는 signal을 평가하기 위한 replay artifact이지, 예측이나 완전한 portfolio simulation이 아닙니다.

이 문서는 replay 시작 전에 무엇을 고정하는지, historical data를 어떻게 평가하는지, fire와 forward return을 어떻게 집계하는지, 어떤 제한을 계속 노출해야 하는지 설명합니다. 현재 예시에 crypto market이 자주 등장하는 이유는 venue, funding, order book, onchain data의 관측 가능성이 높기 때문입니다. 신뢰할 수 있는 데이터와 결제 활동이 programmable rails로 이동하면 같은 방법을 다른 시장에도 적용할 수 있습니다.

방법론 요약

질문	방법	Artifact에 남는 증거
무엇을 테스트했는가?	Replay 전에 typed rule, market, source, interval, window, cooldown을 고정합니다.	Rule definition과 replay metadata
데이터가 충분했는가?	각 source를 resolve하고 timestamp를 보존하며 gap과 잘린 범위를 공개합니다.	Coverage note와 source metadata
Rule은 언제 fire했는가?	Historical sample을 시간순으로 평가하고 raw truth, distinct event, cooldown-filtered notification을 분리합니다.	Fire set, count, event row
그다음에는 무엇이 일어났는가?	각 eligible fire 이후 명시된 horizon의 가격 변화를 측정합니다.	Sample size가 포함된 forward returns
결과를 감사할 수 있는가?	Artifact를 재현 가능하게 유지하고 가정, 미지원 입력, 누락 관측을 노출합니다.	Semantic version, diagnostics, limitations
검토 뒤에는 무엇을 하는가?	실행 결정보다 먼저 rule을 reject, refine, monitor합니다.	Notify, preview-confirm, opt-in activation path

1. Replay 전에 rule을 고정합니다

유용한 백테스트는 사람이 확인할 수 있는 rule에서 시작합니다. Stingray는 historical evaluation을 시작하기 전에 plain-English thesis를 typed definition으로 resolve합니다. Definition에는 다음이 명확해야 합니다.

• Market, symbol, venue 또는 data source
• 모든 condition과 threshold
• Evaluation interval과 historical window
• Cooldown 또는 deduplication policy
• 해석에 사용할 direction과 forward-return horizon

더 좋아 보이는 결과를 만들기 위해 replay가 rule을 조용히 바꾸어서는 안 됩니다. 요청한 source를 사용할 수 없거나, time parameter가 historical interval과 맞지 않거나, definition을 충실하게 평가할 수 없다면 명시적인 limitation 또는 rejection이 올바른 결과입니다.

결과를 본 뒤 threshold를 바꾸면 새 rule이 됩니다. 수정한 rule은 이전 증거를 덮어쓰지 말고 새로운 replay를 받아야 합니다.

2. Data source와 시간을 올바르게 resolve합니다

각 condition에는 replay-safe source contract가 필요합니다. Price, funding, open interest, event, news 입력은 서로 다른 clock과 coverage를 가집니다. Replay는 사용한 source를 기록하고 observation을 timestamp 순서로 평가합니다.

Event 또는 news data에서 중요한 시각은 정보가 시스템에 실제로 사용 가능해진 시점입니다. 나중에 event에 붙은 더 이른 timestamp를 사용하면 당시 관측할 수 없었던 정보를 미리 사용하게 됩니다.

Artifact에는 다음이 공개되어야 합니다.

• 요청한 date range와 실제 적용된 date range
• Native 또는 selected interval
• 누락된 내부 segment와 잘린 edge
• Sampling, aggregation 또는 unavailable 상태인 source
• 사용 가능한 history가 rule 평가에 충분했는지 여부

깔끔한 headline number는 불완전한 coverage를 보상하지 못합니다. Gap 때문에 replay가 유효한 여러 segment로 나뉜다면 그 경계를 남겨야 하며, 존재하지 않는 observation으로 채우면 안 됩니다.

3. Fire를 세기 전에 indicator를 warm up합니다

Indicator와 stateful condition은 값이 의미를 가지기 전까지 일정한 history가 필요합니다. Moving average, RSI, sequence, cross condition을 dataset 첫 행부터 공정하게 평가할 수는 없습니다.

Source와 rule이 요구하는 경우 Stingray는 visible evaluation window 앞의 observation을 warmup에 사용합니다. Warmup data는 indicator와 edge state를 초기화하지만, warmup fire는 사용자에게 보이는 증거로 집계하지 않습니다. Artifact는 warmup boundary를 기록해 첫 visible fire가 초기화되지 않은 indicator 때문에 생기지 않도록 합니다.

Evaluation granularity도 rule과 맞아야 합니다. 5분 condition을 hourly sample로 정직하게 재구성할 수 없습니다. Historical interval이 rule의 가장 작은 time parameter보다 거칠다면 false precision을 암시하지 말고 replay를 명확하게 실패시켜야 합니다.

4. Truthy sample과 actionable fire를 분리합니다

Condition은 여러 연속 sample에서 계속 true일 수 있습니다. 모든 true row를 독립적인 signal로 세면 증거가 과장되고 하나의 market episode가 전체 결과를 지배할 수 있습니다.

현재 replay artifact는 세 가지 view를 구분합니다.

• Raw: 전체 rule이 true인 모든 evaluated sample입니다. Diagnostic 용도입니다.
• Primary: 전체 rule이 false에서 true로 바뀌는 지점입니다. Condition에 새로 진입한 distinct event를 나타냅니다.
• After cooldown: 설정한 notification cooldown을 적용한 뒤 남은 primary fire입니다. Live alert behavior에 가장 가까운 view입니다.

Cooldown은 operational control이지, suppressed fire가 경제적으로 중요하지 않다는 뜻은 아닙니다. 세 view를 함께 보면 rule이 distinct event를 찾는지, 아니면 오랫동안 true 상태로 남는지 알 수 있습니다.

별도의 primary set 없이 raw와 cooldown-filtered set만 제공하는 legacy signal replay에도 같은 해석을 적용합니다. Rule이 다르게 정의하지 않았다면 촘촘하게 몰린 row는 하나의 market episode로 봐야 합니다.

5. Forward returns를 측정하되 P&L로 바꾸지 않습니다

Forward returns는 eligible fire 이후 1시간, 4시간, 24시간처럼 명시된 horizon에서의 가격 변화율을 보여줍니다. 즉, “이 condition이 나타난 뒤 가격은 대체로 어떻게 움직였는가?”를 답합니다.

Artifact가 명시적으로 모델링하지 않는 한 완전한 trading strategy가 아닙니다. Standard signal replay는 다음을 가정하지 않습니다.

• 실제 entry 또는 exit execution
• Position size 또는 leverage
• Fee, spread, slippage, market impact
• Stop-loss 또는 take-profit behavior
• Portfolio constraint 또는 capital allocation

각 summary는 그 뒤의 observation count를 보여줘야 합니다. 긴 cluster의 거의 같은 sample이 다른 모든 episode보다 큰 비중을 차지하지 않도록 distinct event를 공정하게 반영해야 합니다. Average, median, positive share, distribution shape를 함께 보는 것이 하나의 headline statistic보다 유용합니다.

Future data는 fire가 결정된 뒤에만 읽습니다. Forward data는 outcome measurement이며 historical trigger decision의 입력으로 사용되지 않습니다.

6. 하나의 replay artifact 안에서 일관성을 유지합니다

Replay는 저장된 입력으로 재현 가능해야 합니다. 입력에는 rule version, source contract, market identity, interval, window, cooldown, replay-semantics version이 포함됩니다.

가능하면 chart range 변경은 같은 artifact의 다른 window를 읽어야 합니다. Rule을 몰래 다시 실행해 count를 바꾸면 안 됩니다. Chart, fire table, summary metric, selected-event detail은 모두 같은 fire set과 visible window를 사용해야 합니다.

Source history 또는 replay semantics가 실질적으로 바뀌면 결과도 새 version을 받아야 합니다. Reproducibility는 미래의 모든 data vendor가 동일한 history를 반환한다는 뜻이 아닙니다. 특정 artifact의 가정이 감사할 수 있을 만큼 명확하다는 뜻입니다.

7. 결과를 판결이 아니라 증거로 검토합니다

Replay는 다음 순서로 읽습니다.

1. 테스트한 rule이 의도한 rule인지 확인합니다.
2. Return을 보기 전에 source coverage, interval, warmup을 확인합니다.
3. Raw, primary, after-cooldown count를 비교합니다.
4. Clustering과 정확한 fire row를 살펴봅니다.
5. Sample size와 regime context를 포함해 forward returns를 읽습니다.
6. 실제로 수정한 hypothesis는 새 rule로 다시 테스트합니다.

다음 질문이 유용합니다.

• 대부분의 fire가 하나의 volatility 또는 liquidity regime에 몰렸는가?
• 하나의 event나 작은 sample이 결과를 지배하는가?
• 선택한 horizon이 thesis와 맞는가?
• 다른 venue, source, interval을 사용하면 해석이 달라지는가?
• Window를 보기 전에 rule을 선택했는가, 아니면 같은 window에 반복해서 tuning했는가?

같은 historical window에서 rule을 반복 최적화하면 overfitting risk가 커집니다. 결과가 유망하더라도 더 나중이거나 분리된 기간에서 확인한 뒤 monitoring evidence로 취급해야 합니다.

8. Backtest 뒤에도 trust ladder를 따릅니다

Backtest의 일반적인 결과는 세 가지입니다.

• Reject: rule이 noisy, rare, fragile, unsupported 또는 regime-dependent합니다.
• Refine: 하나의 명시적 가정을 바꾸고 새 replay를 생성합니다.
• Monitor: typed rule을 live alert로 실행하고 관측 behavior를 historical artifact와 비교합니다.

Execution은 별도의 결정입니다. Stingray trust ladder는 notify first, 지원되는 경우 preview-confirm, 사용자가 명시적으로 활성화한 경우에만 opt-in execution입니다. Positive historical average가 이 단계를 건너뛰게 하지 않습니다.

알려진 제한

• Historical performance는 future result를 예측하지 않습니다.
• Available history는 source, venue, asset, event type에 따라 다릅니다.
• Candle 또는 sampled data로 정확한 intrabar event 순서를 증명할 수 없습니다.
• Forward returns는 signal 이후 outcome이지, 실현 가능한 trade return이 아닙니다.
• Backtest는 structural change, delisting, liquidity constraint, future market rule을 놓칠 수 있습니다.
• 같은 window에서 여러 test를 하면 우연히 좋은 결과를 찾을 가능성이 커집니다.
• Unsupported 또는 coverage가 부족한 입력은 조용히 근사하지 말고 reject해야 합니다.

공개 전 체크리스트

Stingray replay를 guide, example, benchmark에 사용하기 전에 다음을 포함해야 합니다.

• 정확한 thesis 또는 prompt
• Typed rule 또는 충실하고 읽기 쉬운 summary
• Market, venue, source, interval, date window
• Coverage와 warmup note
• 가능한 경우 raw, primary, after-cooldown count
• Forward-return horizon과 sample size
• Fee, slippage, position sizing, execution의 명확한 제외
• 결과는 historical evidence이며 trading advice나 performance promise가 아니라는 설명

필드별 해석은 백테스트 카드 읽는 법을 참고하세요. 공개 walkthrough는 전략 예시에서 확인할 수 있습니다. Thesis에서 monitor까지의 전체 workflow는 Stingray 작동 방식에 정리되어 있습니다.