항해 기록
7/2 ~ 7/17 — 배가 실제로 달린 2주. 첫 커밋부터 평일 18시(KST) GitHub Actions 무인 갱신으로 항해했다. 이벤트 DB 578건·13개 카테고리, 주간 8편·월간 6편·연간 1편의 리포트 자동 게시, 골든 테스트 301종과 신선도 가드 42종. 커밋 135개 중 38개가 봇의 자동 갱신이었다.
7/20 — 엔진이 멈췄다. 그리고 아무도 몰랐다. 이후 32회 연속으로 한 번도 성공하지 못했다 — 결제·한도 차단 10회(7/20~7/31), 유니버스 확대가 부른 KeyError: 'category' 14회(8/3~8/20), 결제 차단 재발 7회(8/21~8/31), 40분 상한 초과 1회(9/1). 마지막 성공한 갱신은 7/17이고, 발견한 9/4까지 49일이다. 8/1에 사이트에 지연 배너를 달아뒀지만 배너는 당기는 신호다 — 보러 가야 보이고, 파이프라인이 멈추면 볼 이유도 같이 사라진다.
8월 — 멈춘 줄 모른 채 연구는 계속됐다. 실적발표 풀링 검정에 군집 보정을 넣어 "종목을 늘리면 검정력이 오른다"가 틀렸음을 확인했고(7/31), 손으로 박은 종목 목록이 생존 편향의 근원이라 유니버스를 시점별 선정으로 바꿨다(8/1). 그리고 8/29 마지막 커밋 — 위험 전략의 경계에 기준을 세웠더니, 그 기준이 스스로 "만족 불가"라고 답했다. 선정 단계가 사실상 동전던지기였던 것이다(선정 안정성 29%·25%, 기준 70% 미달).
9/4 — 마지막 점검, 그리고 닻. 전수점검에서 32회 연속 실패를 확인하고 코드 쪽 원인 셋을 고쳤다. 그리고 워크플로 둘(daily-update·tests)을 수동 비활성 상태로 남긴 채 다시 켜지 않기로 했다. 고칠 것을 다 고쳐 놓고 켜지 않은 것 — 그게 이 배의 마지막 모습이다.
최종 성적표는 이렇다.
| 검정 | 결과 |
|---|---|
| 개별 사건 169거래일 | 보정 후 유의 22건 — 최대는 호르무즈 봉쇄 -11.65%(t=-8.7) |
| 정례 발표 397건 | 당일 반응 ±0.17% 이내 — 프로젝트 최고 정밀도 |
| 실적발표 9종목 | 8종목이 발표일에 평소의 1.6~6.3배로 요동(q<0.05) |
| 카테고리 평균 13개 | 보정 후 유의 0개 |
| 전략 검증 14항목 | 보정 후 유의 0개 — 마지막까지 살았던 과열 필터도 q=0.168로 탈락 |
| 워크포워드 백테스트 | 전 전략이 매수후보유에 열위(샤프 0.54 vs 0.87) |
판단
이 배의 화물이 음성 결과라는 사실은 부끄러운 게 아니다. 카테고리 평균 0개, 전략 0개, 예측 열위 — "유의하지 않다"를 다중비교 보정까지 걸고 정확하게 말하는 데 두 달을 썼고, 그 과정에서 나온 사고 기록 22건(급등 알림 유실, 미래 날짜 게시, 테스트가 게시물을 덮어써 50일간 들키지 않은 것)이 전부 문서로 남았다. 예측에 성공한 척하는 것보다 이 편이 항해 일지답다.
다만 마지막 교훈 하나는 이 배가 아니라 다음 배들의 것이다. 지연 배너·신선도 가드·정합성 검사 전부 배 안에 있었다. 배가 통째로 멈추자 전부 같이 멈췄고, 알려주는 이가 없었다. 필요한 것은 밖에서 밀어내는 신호다 — 이 처방은 이미 다른 함선들에 실리고 있다.
남은 항로
- 저장소와 데이터는 그대로 남는다 — 이벤트 DB 578건(2000~2026), 게시된 리포트 15편의 URL도 유지된다
- Fleet 카드는 운항 종료로 바꾼다. 운항 기간은 첫 커밋 7/2부터 마지막 점검 9/4까지 65일로 적는다
- 게시 경계 가드, 파이프라인 단독 저자 규칙, "진단도 검증하라" — 이 배에서 만든 규율은 다른 배의 표준 장비가 됐다