[보관] 33. Probe 종료 cascade에 interim 메모 + CHANGELOG 추가

시각: 2026-04-28 오후 KST 컨텍스트: 사용자가 “P1 종료 시 결과 보고서가 어디 있나?” 질문 → 본 보고서(reports/easy·detailed)는 P9 종료 후 의미 있게 차서 시리즈 7~9일 동안 외부 청중에게 보여줄 게 없음을 발견.

무엇이 있었나

문제

기존 cascade는 4단계:

1. experiments/P{N}-*.md §5·§6 채움
2. history/NN-exp-{N}-decision.md commit
3. reports/detailed.md §3.1 P{N} 행 채움
4. reports/easy.md §3 9 probe 표 P{N} 행 채움

→ 외부 청중(강의 수강생·기업)이 P9 끝나기 전에 볼 수 있는 완성된 형태가 없음. detailed/easy는 빈 슬롯이 99% — 표 한 행 차도 의미 있는 보고서 안 됨. 활용처(강의 부교재·기업 컨설팅)에서 진행 중 공유 채널이 없는 게 부담.

해결

3안 채택: cascade를 6단계로 확장 + 신규 산출물 두 개.

신규 1: reports/interim/ 폴더 + probe별 1쪽 메모

• reports/interim/README.md — 폴더 운영 룰, 메모 형식(5섹션), 작성 시점, 9 probe 일람
• reports/interim/P1-memo.md — 첫 probe 메모 템플릿 ([[]] 슬롯)
• 형식: 1쪽 max, 5섹션
  1. 오늘 무엇을 시험했나 (비개발자 친화)
  2. 어떻게 시험했나 (간략, 상세는 experiments/ 링크)
  3. 무엇을 알게 됐나 (1~3줄 핵심)
  4. 다음 probe로 가는 결정 (채택/폐기/보류 + 이유 + 다음)
  5. 한계/주의 (1줄)
• 청중: 강의 수강생, 기업 의사결정자. 통계 용어 회피.

신규 2: reports/CHANGELOG.md

• v0.0(시리즈 시작 전 템플릿) → v0.1v0.8(P1P8 누적) → v1.0(P9 종합) → v2.0(본 운용 21일 결과)
• 매 probe 종료 시 한 줄 추가
• 결론 변경 시 이전 결론 삭제 금지 — 강의·기업 자료에 인용된 이전 버전 추적 가능해야
• git tag 정렬 가능 (reports-v0.1)

cascade 6단계로 확장

experiments/00-plan.md §5에 표 추가:

#	작업	위치	시간
1	probe doc §5·§6	experiments/P{N}-*.md	실시간
2	history commit	history/NN-exp-{N}-decision.md	5분
3	detailed.md §3.1 행	reports/detailed.md	5분
4	easy.md §3 9 probe 표 행	reports/easy.md	2분
5	interim 메모 신규	reports/interim/P{N}-memo.md	15분
6	CHANGELOG 한 줄	reports/CHANGELOG.md	2분

총 ≈ 30분/probe. 6단계 미완료 시 다음 probe 진입 금지.

reports/README.md 갱신

• 기존 “버전 일람” → “본 보고서” + “진행 중 자료” 두 표로 분리
• interim/ + CHANGELOG.md 항목 추가, 갱신 주기 명시

왜 그렇게 갔나

왜 별도 파일을 안 만드는 옵션 1을 거부했나

“실시간 갱신만 하면 충분하다” 옵션은 detailed/easy의 빈칸을 채우는 것만으로는 외부 청중에게 보여줄 형태가 안 됨. 한 행 차 있는 거대 템플릿보다 1쪽 메모가 오늘 한 일을 즉시 전달하는 데 강함.

왜 옵션 2(CHANGELOG만)도 부족했나

CHANGELOG는 어느 시점의 보고서가 어느 probe까지 반영했는지 추적용. 외부 청중에게 오늘의 발견 자체를 전달하는 건 못함. 추적과 전달은 분리된 기능.

왜 옵션 3(둘 다)으로 갔나

• 강의/컨설팅 활용처 = 진행 중 가시성이 핵심. interim 메모로 일일 자료 가능.
• 분쟁·재인용 = 버전 추적이 핵심. CHANGELOG로 보장.
• 두 기능이 다르므로 두 산출물이 필요. 30분/probe는 9 probe × 30분 = 4.5시간 — 7~9일 시리즈에서 감당 가능.

왜 P1 메모만 미리 작성하고 P2~P9는 안 했나

C8(반증 조건 사전 명시) 정신: 사전 작성은 해당 실험의 반증 조건까지만. 미래 probe의 메모를 미리 적으면 사후 짜맞춤 위험 — 오늘 발견한 것이 아닌 이미 적어둔 것에 결과를 맞추게 됨. 따라서 P2~P9 메모는 그 probe 종료 직후에만 작성.

왜 P9는 메모 없이 본 보고서로 가나

P9는 “L1 통합 분석 = 본 비교”라 1쪽 메모로 압축 불가. P9 종료 시점이 곧 본 보고서(easy/detailed) 첫 의미 있는 갱신 시점. interim P9 메모는 형식상 가능하나 본 보고서와 중복돼 가치 ↓ — interim README에 명시.

무엇이 남았나

즉시 후속

• P1 시작 시 P1-memo.md 슬롯이 실제 결과 형태와 정합하는지 확인. 어긋나면 R&D 후 템플릿 보정.
• git tag 운영 룰 — reports-v0.1 같은 형식으로 동결할지 결정. 사용자 운영 선호에 따라.
• 강의·기업 자료 변환 시 interim 메모를 PDF/이메일 양식으로 옮기는 변환 가이드 — v0.5 시점쯤 한 번 작성 권장.

본 결정의 메타

30분/probe 시간 부담이 실제 운영에서 감당 가능한지는 P1·P2 끝나봐야 답 가능. P3 진입 전 회고에서 검토 — 부담 과도하면 interim 메모를 P3·P5·P9 같은 의존 그래프 분기점에만 작성으로 축소.

알려진 위험

• 중복 자료의 어긋남: 같은 결과를 4곳(detailed/easy/interim/CHANGELOG)에 적으면 결론이 표현마다 미묘하게 갈릴 수 있음. cascade 룰에 “detailed가 진실 원본, 다른 셋은 그 압축본”을 박았으나 운영 규율 필요.
• interim 메모의 가벼운 톤이 잘못 인용될 위험: 비개발자 친화 톤이라 “X가 더 좋았어요”가 detailed의 “X가 W5 통과했고 ICC 0.7+로 검증됨”으로 압축돼 인용되면 정확도 손실. interim README에 “본 보고서 아님” 명시했으나 외부 인용 시 확인 필요.
• CHANGELOG 결론 변경 룰: “이전 결론 삭제 금지”는 데이터 정합성에 좋지만 의사결정자가 어느 버전을 봐야 하는지 혼란 가능. v1.0 이후엔 “최신 = canonical, 이전 = archived” 명시 룰 필요할 수 있음.
• P1-memo.md 사전 템플릿이 사후 짜맞춤 위험: 슬롯에 예시 후보를 적어둔 것이 결과를 그쪽으로 유도할 수 있음. P1 시작 시 템플릿 다시 보고 “결과 후보 예시”는 지우고 빈 슬롯만 남기는 보정 권장.