문제: 로그가 너무 많아서 로그가 사라졌다
- 호출 빈도 — 자동매매 전략의
on_candle함수는 종목마다, 매 틱마다 호출 - 문제 코드 — MDD(최대 낙폭) 차단이 걸릴 때마다
logger.info로 무조건 기록 - 실질 — “차단 중”이라는 상태 하나를 매 틱마다 재알림
2026년 7월 30일 실측 결과 — 25분 동안 127,141줄. 초당 약 85줄.
127141 MDD severe (-18%+) — 신규 진입 차단
279 LLM 분석 적용(세션 브리지 claude)
1 WS 계좌 스냅샷 갱신 실패
로그가 사라지면 뭘 잃는가
- 진짜 문제 — 디스크 용량이 아님
- 컨테이너 로그 설정 —
max-size 10m, max-file 3 - 이 속도에서의 결과 — 로그 보존 기간이 25분으로 축소
그날 실제로 잃은 것.
- 매도 체결 기록 — 2건 (둘 다 수익 실현)
-
상태 — 로그에서 조회 불가
- “무엇을 언제 얼마에 팔았는가” — 매매 시스템 사후 검증의 근간
- 귀결: 로그 폭주가 디스크 낭비를 넘어 감사 추적(audit trail) 자체의 소실로 연결
어떻게 고쳤나
- 변경 방향: 매 틱 기록 대신 상태가 바뀌는 순간에만 기록
blocked = mdd_size_factor == 0.0
if blocked != self._mdd_blocked:
... logger.warning(진입 또는 해제)
self._mdd_blocked = blocked
if blocked and not has_position:
return Signal.HOLD, 0.0
세부 판단 세 가지.
- 차단 해제 순간도 기록 — 언제 정상으로 복귀했는지 추적 필요. 진입만 기록하고 해제를 빼면 “언제까지 막혀 있었나”를 알 수 없음
- 로그 레벨 info → warning 상향 — 매매가 멈추는 상태이므로 단순 정보성이 아니라 주목해야 할 사건이라는 판단
-
플래그를 상태 저장/복원(
export_state/import_state)에 포함 — 재시작 후 중복 로그 방지. 이미 있던_last_in_cooldown플래그와 동일 방식
곁다리로 발견한 또 다른 문제
- 로그 문구 — “-18%+”로 하드코딩
- 실제 차단 임계값 — -15% (
_get_mdd_size_factor함수에서mdd <= -0.15일 때 차단) - 즉 로그가 스스로 잘못된 정보를 기록 중
- 조치 — 실제 계산된 DD 값을 그대로 출력하도록 변경해 불일치 제거
검증에서 지킨 선
- 이 작업의 경계 — “로그만 줄이고, 차단 로직 자체는 건드리지 않는다”
- 유지:
HOLD반환 동작 - 변경: 로그 출력 빈도만
추가한 테스트 4건 — 정확히 이 경계를 확인하는 것들.
- 차단이 지속되는 동안 로그가 1회만 기록되는지 (30틱 반복해도 1줄인지)
- 해제 시에도 1회 기록되는지
- 로그를 줄였다고 차단 동작(HOLD 반환) 자체가 흔들리지 않았는지
- 재시작 후에도 플래그가 보존돼 중복 로그가 없는지
관련 테스트 103건 전부 통과.
일부러 하지 않은 것
- 이 작업의 범위 — 로그 문제만
- 제외: MDD -18.4%로 신규 진입이 차단된 상태 자체의 해소
- 이유: equity_peak이 종목별로 분산되며 생긴 별개의 설계 결함 → 별도 처리
남는 교훈
로깅은 “일단 많이 남겨두면 안전하다”고 여기기 쉽다. 하지만 로테이션이 걸린 환경에서는 로그량 자체가 보존 기간을 결정한다. 초당 85줄을 찍는 로거는, 의도와 다르게 “25분 이전 일은 아무것도 몰라도 된다”고 선언하고 있는 것과 같다.
특히 트레이딩처럼 사후 검증이 핵심인 도메인에서는, 로그를 얼마나 남길지도 리스크 관리의 일부다. 상태가 바뀔 때만 기록한다는 원칙 하나로, 로그는 정보를 잃지 않으면서도 양은 극적으로 줄었다.