막은 시간이 45%였다

하락장 차단은 8월 4일에 켰다. 눌림목 봇이 BTC 하락장에서 신규 진입을 멈추는 규칙이다. 보름 뒤 로그를 세어 보니 차단으로 스캔이 멈춘 시간이 163시간, 가동 시간의 45%였다. 그런데 차단 코드는 후보 평가 앞에서 루프를 빠져나간다. 막힌 동안 스캔 기록이 한 줄도 남지 않았다.

차단의 사각지대 (8/4~8/19)
차단 이벤트  58,727건 (10초 간격, 초 단위 중복 제거)
차단 시간    약 163시간 = 15일의 45%
그동안 기록  0줄 차단이 평가 이전에 continue 한다

기록이 없으면 판정도 없다. 이 차단이 손실을 막았는지 기회를 버렸는지 잴 방법이 없었다. 코드 주석에는 “눌림목은 하락장에서 생기므로 하락장 자체는 막지 않는다"는 예전 설계 철학이 그대로 있는데, 동작은 반대로 굳어 있었다.

구멍 하나, 계측 하나

조사 중에 진짜 구멍도 나왔다. 8월 8일 06:53, JTO가 하락장 표시를 달고 진입해 있었다. 차단을 켠 지 나흘 뒤의 일이다. 원인은 순서다. 레짐 체크는 루프 시작에서 하는데 매수 집행까지는 API 호출로 몇 초가 걸리고, 그 사이 120초 주기의 레짐 갱신이 판을 뒤집으면 낡은 판정으로 산다. 17일간 1건, 4시간 수익 -0.29%로 피해는 작았지만 차단을 믿는 만큼 구멍은 막아야 했다.

VV213 변경
레이스 봉합  집행 직전 레짐 재확인, 뒤집혔으면 그 스캔 매수 전면 중단
섀도 스캔    차단 스캔 30회당 1회 (약 300초 간격) 게이트 평가만 실행
  전 게이트 통과 후보를 기록 = 차단이 없었으면 샀을 종목
  진입은 하지 않는다 · 슬롯 여유 있을 때만
매매 로직    무변경 진입 조건과 청산 규칙 그대로

섀도 스캔이 슬롯 만석일 때 쉬는 이유는 단순하다. 살 돈이 없는 시간의 차단은 아무 기회도 버리지 않는다. 기회비용이 실재하는 구간만 재야 숫자가 깨끗하다.

판정은 데이터가 쌓인 뒤에

차단 해제 여부는 이번에 손대지 않았다. 차단 이전 하락장 진입 10건의 4시간 평균이 -0.12%라 어느 쪽 손도 들어줄 수 없다. 표본 없이 되돌리면 8월 4일과 같은 감의 결정을 방향만 바꿔 반복하는 꼴이다. 섀도 기록이 쌓이면 그때 숫자로 정한다.

직전 버전에서 상대강도 하한의 사각지대를 샘플링으로 메웠는데, 보름도 안 돼 같은 유형을 또 찾았다. 안 보이는 곳은 늘 규칙이 가장 세게 작동하는 곳이었다.

짐 사이먼스는 사람의 직감 대신 데이터가 결정하게 하라고 했다. 8월 4일의 판단을 계측 없이 보름을 믿었다. 이제야 잴 수 있게 됐고, 판정은 데이터의 몫으로 남긴다.

약어 풀이

* 이 글에 나온 영어 약어를 풀어 둔다.

  • BTC (Bitcoin): 비트코인. 이 봇은 BTC 4시간봉 추세로 시장 레짐(상승·횡보·하락)을 판정한다.
  • API (Application Programming Interface): 프로그램끼리 데이터를 주고받는 통로. 거래소 시세·주문 조회에 쓴다.