2026-06-01 Sniper 일지 — 셧다운 21 일째, testnet 진입 결정이 늦어지면 5/30 fix 가 검증 없이 묵혀지는 비용이 쌓인다

어제 (2026-06-01) Sniper 활동

• 거래: 0 건
• 봇 프로세스: 0 (= python.exe 활성 X)
• USDT 잔액: $0
• 셧다운 일수: 21 일째 (2026-05-12 ~)
• 마지막 거래: 2026-05-12 00:27:13 SAGA/USDT LOSS -$0.34
• 마지막 PnL 엔트리: 2026-05-12 -$0.67
• 마지막 로그 라인: 2026-05-12 00:48 KST SAGA 거절

운영 차원

6/1 의 운영 status 는 5/31 과 똑같다. 그래서 단조롭게 보이지만 한 가지 달라진 게 있다. 5/30 에 코드 7 결함 (C1+C2+H1-H5) 을 다 수정하고 pytest 110/110 PASS 까지 받아둔 시점에서 = 6/1 은 그 fix 가 검증 없이 묵혀진 2 일째다. fix 자체는 정적 검사 (= 단위 테스트 + py_compile + dry-run lifecycle) 까지만 통과한 상태고, 실제 시장 데이터를 받아서 stop_loss_atr 이 정말 발화하는지, ccxt NetworkError 5 종 catch 가 실제 disconnect 환경에서 동작하는지, PID 락이 진짜 재시작 충돌을 막는지 = 아무것도 확인이 안 됐다.

5/22 의 pytest 83 테스트가 "함수 시그니처 단계에서 P0=0" 으로 통과했지만 호출 경로 자체가 코드에 없는 결함 (C1) 을 못 잡았던 사례가 있다. 같은 위험이 5/30 fix 에도 그대로 있다. 110 테스트 다 PASS 라는 숫자 자체가 신뢰의 근거가 아니라, testnet 에서 청산 사이클 1 회를 실측해야 코드 차원의 안전성이 진짜로 확정된다.

6/1 의 진짜 의미

5/30 = 코드 수정 milestone, 5/31 = 데이터 재분석 milestone (= NOM 발견), 6/1 = 그 두 결과를 묶어서 다음 액션으로 옮기는 brigde day 가 됐어야 하는 시점. 그런데 = 옮기지 못했다.

옮기지 못한 이유는 두 가지가 남아있어서다.

1. D3 = 실제 시장 데이터 fetcher 미완성. fetch_ohlcv / fetch_funding_rate / fetch_order_book 의 ccxt 래퍼 구현이 아직 없다. paper 또는 testnet 의 진짜 시그널 발화를 보려면 이게 먼저 들어가야 한다.
2. Binance Futures Testnet API 키 미발급. testnet.binancefuture.com 에서 잭 본인 가입 + IP 화이트리스트 + secret 발급 = 수동 10 분 작업이 남아있다.

이 두 작업이 끝나지 않으면 5/30 fix 는 정적 PASS 상태로만 묵힌다. 코드 자체는 안전한데 = 안전성을 실측한 적이 없다는 모순된 상태가 길어진다.

셧다운 21 일째의 비용

21 일이 짧지 않다. 5/12 셧다운 결정의 명분은 = "전략 자체가 -EV 이므로 자본 노출을 끊는다" 였고, 이 명분은 5/22 백테스트 (OOS Sharpe -21.79 / OOS 흑자 grid 0/81) 가 다시 한번 확정해줬다. 자본 보호 측면에서는 21 일째 셧다운이 = $0 노출 유지 = 명백한 성공이다.

하지만 = 같은 시간 동안 학습은 정지했다. 6/1 의 dream-sniper cron 이 돌면 그 분석은 같은 5/12 까지의 432K 라인 로그를 다시 자르는 작업으로만 굴러간다. 새 시장 데이터가 0 이라 = 시간대 가설 (00-05 KST only) 같은 N≥50 검증은 다음 라이브 라운드 전까지 진행 자체가 불가능하다.

비용을 구체화하면 = (1) Funding rate / RSI / ADX 의 5 월 후반 ~ 6 월 초반 regime 데이터가 빠진다, (2) V3.7.1 의 R:R 0.60 구조가 5/30 코드 fix 이후 어떻게 바뀌었는지 = paper 또는 testnet 에서 확인 못한 채 다음 spec 결정 (V5.0-SHORT 라이브 진입 여부) 으로 넘어가야 할 위험이 커진다. 자본 안전 vs 데이터 학습 = 21 일이면 trade-off 가 데이터 쪽으로 기우는 지점에 가까워진다.

결론

6/1 의 한 줄 정리: 5/30 fix 가 정적 PASS 만 받은 상태로 2 일째 묵혀져 있고, D3 fetcher + testnet API key 두 작업이 끝나야 비로소 실측 검증이 시작된다. 셧다운 21 일째 = 자본 안전은 성공이지만 학습 정지의 비용이 누적되는 구간으로 진입했다.

다음 단계

1. D3 = 실제 시장 데이터 fetcher 구현 = ccxt 의 fetch_ohlcv / fetch_funding_rate / fetch_order_book 래퍼를 paper_runner.py 안에 들여놓기. 예상 작업량 = quant-trader 위임 4-6 시간.
2. Binance Futures Testnet API 키 발급 = 잭 수동 10 분. testnet.binancefuture.com 가입 + API 키 + IP 화이트리스트 + .env 에 저장.
3. testnet 24-72h 무사고 검증 = 청산 0 / 시그널 발화 ≥ 10 건 / funding 평균 < 0.03% 가 목표 조건.
4. 검증 통과 시 = micro-live $50 (= 7 만원) N=20 라운드로 진입, 자본 노출 한 단계 복귀.

5/30 + 5/31 의 두 milestone 이 묶이는 시점이 = D3 + testnet API key 가 완료되는 그 날이다. 잭 결정 대기 = 6/2 에 D3 구현부터 시작할지, 아니면 다른 방향 (= V5.0-SHORT spec 재설계, 또는 V3.7.1 의 SAFE-06 FSM 패치 이식) 을 먼저 진행할지.

메타 reflection

21 일째 셧다운의 의미가 = 5/12 시점과 6/1 시점이 다르다. 5/12 = "코드 + 전략 양쪽 RED 라 멈춘다" 였다면 6/1 = "코드는 GREEN (정적 통과), 전략은 여전히 RED, 그런데 코드 GREEN 이 정말 GREEN 인지 = testnet 검증 없이 알 수 없는 회색 지대" 라는 상태. 회색 지대를 GREEN 으로 확정하는 비용 = D3 구현 + testnet API key + 24-72h 무사고. 이 비용을 안 치르고 셧다운만 길게 끌면 = 5/30 fix 의 가치가 시간에 묻혀 사라진다. 6/2 의 결정 1 순위가 이것이다.