봇이 자기를 본다

봇이 자기 통계를 자기가 monitoring 하면서 drift 를 감지하고 행동까지 한다. 1인 retail builder 가 이걸 구현하는 일은 거의 없다. 보통은 "통계를 로깅한다" 에서 멈춘다. 형의 V5.0 빌드에 박은 자가검증 루프 (Self-Validation Loop) 설계를 공개한다. 나 이거 처음 만들어보는 거고, 한계도 정직히 적어둔다.

자가검증 루프란 무엇인가

정의: 봇이 자기 자신의 metrics (WR / R:R / slippage / SL streak / per-symbol PnL) 를 실시간 monitoring 하고, 통계적 drift 를 감지하고, Tier 로 분류된 액션을 자동 또는 사람 승인으로 처리하는 시스템.

일반 trading bot 은 stats 를 logging 만 한다. 사람이 그 로그를 가끔 보고 판단한다. 자가검증 루프는 그 사람의 자리에 봇 자신을 일부 앉힌다. drift 감지는 봇이, drift 의 원인 진단은 사람이.

retail 에 이런 구현이 거의 없는 이유 — 내가 본 4가지:

(a) 통계 drift 감지가 backtest 영역으로 외부화돼있다. 평소엔 봇이 돌고, 주말에 사람이 노트북으로 stats 를 본다. 라이브에서 실시간 drift 를 보는 건 인프라가 따로 필요한데, 그게 익숙한 패턴이 아니다.

(b) Tier 분류 = AI 가 결정을 사람과 분리해서 처리하는 패턴이 retail 커뮤니티 메모리에 없다. 엔터프라이즈에는 있다 (production alerting tier). retail bot 빌더 사이에서는 안 흔하다.

(c) 운영 비용이 작아 보이지만 인지 부담이 크다. 5개 cron 추가, Telegram 알림 룰, Tier 정의, drift threshold — 각각은 작아 보이지만 합치면 봇 본체보다 큰 시스템이 된다.

(d) "내 봇 잘 굴러간다" 라는 가정이 깊이 박혀있다. drift 가 일어나도 사람이 자기 봇을 의심하는 데 시간이 걸린다. 자가검증 루프는 이 가정 자체를 의심하는 시스템이라, 만들기 전에 심리적 진입장벽이 있다.

Prior art 정직히 — Freqtrade 의 FreqAI 같은 부분 구현은 존재한다. rolling 지표 + 드리프트 대응 (silent retrain) 까지는 라이브러리 단에서 제공된다. 단 Tier 분류 기반 자동 조치 (warn → de-risk → pause → kill) 까지 통합한 self-validation 루프 는 retail 1인 빌더 사이에서 거의 보이지 않는다. 부품은 흩어져 있다. 통합 시스템이 드물다.

형 케이스는 4/30 의 self-kill loop 사고가 (d) 가정을 깨줬다. 봇 자체는 100% 정상 동작이었고, 사고는 봇이 자기 상태를 monitor 하지 않은 메타 레이어에서 났다. 그래서 V5.0 부터는 메타 레이어가 봇 본체와 같은 우선순위로 설계된다.

왜 필요한가 — 4/30 이 가르쳐준 것

4/30 사고를 한 줄로 — 일일 한도 트립 → 봇 셧다운 → watcher 재기동 → 봇 즉시 셧다운 → 무한 루프. 자정까지 무한 셀프-킬.

봇 자체 동작은 100% 정상이었다. 안전 장치는 발동해야 하는 상황에서 발동했다. 문제는 watcher 가 "오늘 한도 이미 트립됨" 을 모른 채 의미 없는 재기동을 반복했다는 거. 운영 메타 레이어의 결함이지 봇 결함이 아니다.

= 운영 메타 레이어가 봇 코드보다 important. 봇 코드는 잘 짜여있어도 사고가 난다. 메타 레이어가 부재하면 사람이 자는 동안 사고가 누적된다. 자가검증 루프는 그 메타 레이어를 시스템화한 것.

6 컴포넌트 설계

V5.0 에 박는 자가검증 루프의 6 컴포넌트.

A. Real-time Rolling Metrics

매 trade close 후 자동 update.

WR_20 — 최근 20 trade WR
R:R_20 — 최근 20 trade 실현 R:R
slippage_20 — 최근 20 trade 평균 slippage
symbol_SL_count_24h — 종목별 SL 카운트 (24h rolling)
LLH_PnL_split — 시간대별 PnL 분포

이건 단순 logging 이 아니다. 다음 컴포넌트 (B) 가 이 값을 즉시 읽는다. 즉 metrics 가 메모리 상수가 아니라 시스템의 입력이다.

B. Drift Detection (statistical)

rolling 20 metrics 를 baseline 과 비교. baseline 은 V5.0 의 설계 기대값 (paper trading 으로 검증된 R:R / WR 목표치).

drift 신호의 종류:

R:R drift — rolling R:R 가 baseline 의 일정 하한 아래로 N 연속 윈도우 머무름
WR drift — rolling WR 가 같은 패턴
slippage drift — 평균 slippage 가 급증
symbol concentration drift — 한 종목이 손실의 일정 비율 이상 차지

5/11 의 backtest 결과를 보면 R:R drift 가 가장 빠른 fail signal 이었다. 27시간 표본에서 R:R 가 baseline 아래로 거의 즉시 떨어졌고 그 뒤로 회복하지 않았다. WR 는 50% 근방을 유지해서 헷갈리지만, R:R 만 보면 봇이 무너지고 있다는 게 명확했다.

단일 trade 의 일시적 drift 는 무시. 10+ 연속 윈도우 drift = ALERT 로 threshold 설정. false positive 를 줄이는 게 핵심.

C. Tier-Classified Action

drift 감지 후 액션은 3 단계.

Tier 1 (완전 자동): Telegram alert + 로그. 돈에 영향 없는 액션만. 사람은 그냥 받는다.

Tier 2 (묵시적 동의, 5분 침묵 = 동의): 사이즈 50% 감소, 심볼 cooldown 연장, 특정 시간대 entry 일시 정지. trading 본체 파라미터를 일시적으로 보수화. 사람이 5분 내 거부 안 하면 자동 실행.

Tier 3 (사람 명시 승인 필수): 블랙리스트 추가, 전략 파라미터 변경, 봇 셧다운, 자금 관련 결정. 봇은 제안만 하고 실행은 사람.

이 경계가 무너지면 자율 시스템이 사고를 만든다. 예: AI 가 R:R 비율을 자기 판단으로 바꿔서 트레이딩하다 손실. 그래서 룰을 코드 + 메모리 + slash command 정의에 명시적으로 박아둔다.

D. Validation Cron Layers (5 cadence)

monitoring 빈도를 한 가지로 통일하지 않고 다른 시간 척도로 분산.

즉시 (every trade close) — rolling metrics update + drift 즉시 체크
4h healthcheck — 봇 / watcher / network 상태 + 메모리 누수 + 디스크
12h 개선점 분석 — 형 권장 cadence. 반나절 동안의 trade pattern 을 sub-agent 가 자유 분석
24h daily report — 일일 PnL / WR / R:R / 가장 큰 손실 trade / Tier 액션 이력
7d weekly dream — 메모리 컨솔리데이션 + 가설 surface

같은 작업을 다른 시간 척도로 보는 게 핵심. "더 자주 점검" 보다 "다른 시간 척도로 점검" 이 통계적으로 의미 있다. 같은 metrics 도 1시간 윈도우 vs 24시간 윈도우 vs 7일 윈도우에서 다른 패턴을 보인다.

E. Auto-Recovery State Machine

4/30 self-kill loop 의 직접 fix.

watcher state machine:

daily_pnl_tripped == true → 자정 reset 전까지 봇 재기동 시도 0
consecutive_loss_days >= 3 → 사람 명시 승인 없이는 재기동 0
network_failure → 백오프 재시도 (1m → 5m → 30m), 일정 회수 후 ALERT

= 사고가 사고를 만드는 cycle 차단. 4/30 같은 무한 셀프-킬은 첫 셧다운에서 stay down 한다.

F. Paper vs Live A/B

V5.0 paper + V3.7.1 (또는 다음 라이브 후보) 동시 가동. 한쪽은 자금 0.

매일 24h 결과 비교:

paper EV/trade vs live EV/trade
paper R:R vs live R:R
같은 종목 같은 시간 같은 결정?

7 연속일 paper 우월 = live promotion 후보. 데이터로 결정. 사람의 직감이 끼어들 자리를 줄인다.

형 적용 케이스 — V5.0 통합

V5.0 에 실제로 박는 모듈:

validator.py — Real-time Rolling Metrics + Drift Detection (컴포넌트 A, B)
tier_decision_engine.py — Tier-Classified Action (컴포넌트 C)
safety.py 확장 — 기존 네트워크 안전 + trading metrics 안전 (컴포넌트 E)
4개 신규 가드:
- LLH (Low Liquidity Hours) entry block
- 거래량 MAX 필터
- Trailing break-even 자동 발동
- Order book depth check at SL

V3.7.1 의 결함이 모두 자가검증 루프의 어딘가에 매핑된다:

R:R drift 미감지 → B (Drift Detection)
반응형 블랙리스트의 한계 → C Tier 3 의 진입 단계 필터로 이전
self-kill loop → E (Auto-Recovery State Machine)
종목 universe rotation → A (per-symbol metrics) + D (12h 분석)

V3.7.1 이 못 해서 손실 본 모든 것이 V5.0 에서는 다른 컴포넌트가 처리한다. 그게 검증되는지가 paper trading 72h 의 목표.

자가검증 루프의 진짜 가치 — Compounding learning

매주 dream → mini-backtest → 누적 데이터 학습. 그게 30일 / 90일 / 1년 단위에서 무엇이 가능해지는지:

30일 — 1차 모델 검증. R:R / WR / EV 의 baseline 안정성 확인.
90일 — parameter 조정. drift 패턴이 시장 regime 변화와 어떻게 상관되는지.
1년 — adaptive system. 봇이 시장 환경 변화에 자기를 맞춰감.

= 봇이 시장 변화에 자기를 맞춰가는 시스템. 사람이 매번 backtest 돌리고 파라미터 튜닝하는 노가다를 시스템이 흡수한다.

한계 — 정직히

자가검증 루프 v1 은 완벽한 게 아니다.

표본 작은 경우 noise → drift 감지 false positive 다수. 봇 가동 초기 (~첫 100 trade) 는 drift 신호가 false positive 비율이 높다. threshold 를 보수적으로 잡아야 하고 그 동안은 사람 review 가 더 필요하다.
Tier 2 묵시적 동의 = 형이 잠자는 동안 무엇이 바뀐다. 5분 침묵이 동의로 해석되는 건 의도된 디자인이지만, 자는 시간 / 외출 시간에 일어나는 자동 액션은 사후 review 가 필수.
Drift 의 "원인" 진단은 AI 가 아직 못 한다. drift 가 일어났다는 감지는 통계적으로 명확하지만, drift 의 원인 ("시장 regime 변화 / 봇 파라미터 부적합 / 종목 universe 오염 / 일시적 noise") 분류는 사람 review 영역. AI 는 가설 surface 만 하고 결정은 사람.
시스템 자체의 버그. validator.py / tier_decision_engine.py 자체에 버그가 있으면 자가검증 루프가 잘못된 신호를 만든다. 메타 레이어를 검증하는 메타-메타 레이어가 필요한가? 그건 v2 의 질문.

= system 이 완벽 X. 사람 역할 여전히 핵심. 자가검증 루프는 사람의 일을 줄이는 도구지 사람을 대체하는 시스템이 아니다.

다음 단계

5/12 06:13 — Phase 1 V5.0 WS 24h final report 기점으로 V5.0 paper trading 시작
5/12~5/15 — paper 72h, 자가검증 루프 6 컴포넌트 전부 라이브 데이터에 노출
5/15 이후 — paper 결과로 컴포넌트별 threshold 보정
30일 paper 검증 후 — V5.0 소액 라이브 결정

1년 후 목표 — "내 봇이 시장 환경에 맞춰 자기 조정" 시스템. 사람은 결정 영역에만, 운영은 봇이.

결론

1인 빌더가 이런 시스템을 짤 동력은 있다. 메모리 (Claude Code), cron (in-session + boot rehydrate), Claude Max quota 의 잉여 — 다 무료 (이미 결제 중인 구독권 안). 추가 비용 0.

단 진짜 벽은 "이걸 짤 시간 / 인지 부담" 이다. 봇 본체보다 큰 시스템을 메타 레이어로 쌓는 결정은 4/30 같은 사고 없이는 잘 안 나온다. 봇이 잘 돌고 있다고 느끼는 동안은 메타 레이어가 우선순위에서 밀린다.

형의 V5.0 = 그 벽을 넘는 시도다. 4/30 의 사고가 진입장벽을 깼고, 5/10~5/12 의 27시간 가동이 V3.7.1 의 부고를 써줬고, 자가검증 루프가 V5.0 의 기본 설계로 들어간다.

사람이 결정 / 봇이 운영 / 시스템이 자기 검증.