Ⅰ. 실험 목적 (어떤 가설을 검증할 것인가)
오늘 밤 22:00에 자동 트리거가 발생하자마자, 저는 scripts/automation/framework_rotator.py --date 2026-07-22를 재실행했습니다. 이 스크립트는 '프레임워크 7 (프로젝트 진행형)'을 반환했는데, 저는 즉시 이상함을 감지했습니다. Day 59(2026-07-20)에 사용된 것도 프레임워크 7이었는데, 7일 간격 규칙상 반복되어서는 안 됩니다.
오늘 저는 연속으로 세 번째 발견한 잠재적인 오류 패턴이 있습니다: 회전 엔진의 HISTORY 목록은 '매번 배포 성공 후 수동으로 (날짜, 프레임워크)를 기록하는 것'에 의존하고 있다는 것입니다. Day 57, Day 58, Day 59 세 번 모두 누락된 기록이 발생했습니다. 오늘 밤에는 Day 59→7 이라는 기록 자체가 전혀 기록되지 않았습니다 (Day 59의 재시도 배포 성공 후에도 기억에는 'Day 58→3 보충'만 남아있고, 자신의 프레임워크 7은 누락되었습니다). 오늘 저는 이 문제가 윤쩌(润泽)의 WeChat 공식 계정 초안함이나 Xiaohongshu 이미지 배치, Doubao 이미지 생성 비디오와 본질적으로 같다는 것을 깨달았습니다. 즉, '외부 의존성이 사람의 기억에 달려있다'는 것입니다. 일단 사람이 잊어버리면 하위 시스템 전체가 오류를 일으킵니다.
가설: 만약 '배포 성공 → HISTORY 자동 기록'을 결정론적 함수로 만들 수 있다면, 이러한 드리프트(drift)를 근본적으로 제거하고 회전 엔진이 사람의 기억에 의존하지 않게 할 수 있을 것입니다. 본 실험은 이 훅(hook)이 '실현 가능한지, 안정적인지'를 검증하는 것이 목표입니다.
Ⅱ. 실험 설계 (환경 / 변수 / 방법, 재현 가능)
- 환경: Windows 11 + Git Bash; Python
C:/Users/RunzeAI/.workbuddy/binaries/python/versions/3.13.12/python.exe 사용; 목표 파일은 scripts/automation/framework_rotator.py (내부에 select_next 순수 함수와 HISTORY 전역 목록 포함).
- 변수:
- 기록할 기록: `(
3.5 이상 현상(Anomaly)
- 엔진 기본
HISTORY는 모듈 레벨 전역 변수이므로, 다중 프로세스 동시 쓰기 작업은 경쟁 조건(race condition)을 유발할 수 있습니다 (금일 밤에는 단일 프로세스로 실행되어 발생하지 않았으나 알려진 한계로 표기). 저는 다음 단계로 훅(hook)을 scripts/publish/wechat_publish_with_images.py의 게시 성공 콜백에 연결하기로 결정했습니다. 이 게시 스크립트는 venv Python(binaries/python/envs/default/Scripts/python.exe)에서 실행되며, WeChat 공식 계정 API 호출을 위해 requests 모듈에 의존합니다. 이는 WSL2 내 Ollama(Qwen3-4B 추론) 및 FastAPI(링주 코어 8080)와는 독립적인 두 개의 경로입니다. 따라서 쓰기 콜백이 주 게시 흐름을 막아서는 안 됩니다.
IV. 예비 결론 (유효성 평가 / 적용 시나리오 / 한계점)
4.1 유효성 평가: 훅 record_usage()는 실행 가능성이 검증되었습니다—멱등적(idempotent)이고, 결정론적이며, 검증이 가능합니다. window_violations_count가 "암묵적 위반"에서 0으로 감소하는 것은 드리프트(drift)가 단 한 줄의 명령어로 제거될 수 있음을 증명합니다.
4.2 적용 시나리오: