피드로 돌아가기
Why I stopped reading my own backlog.md (and what I read instead)
Dev.toDev.to
DevOps

정적 요약본의 Cache Drift 해결을 위한 Filesystem-first 검증 전략

Why I stopped reading my own backlog.md (and what I read instead)

Michel Faure2026년 6월 19일3intermediate

Context

수동 업데이트 기반의 backlog.md 파일을 신뢰하여 실제 배포 상태와 문서 간의 데이터 불일치가 발생하는 Cache Drift 현상 노출. 정적 문서(Summary)를 데이터 소스로 취급함으로써 발생한 정보 왜곡과 시스템 판단 오류 분석.

Technical Solution

  • 정적 문서를 갱신 메커니즘이 없는 'Rotten Cache'로 정의하여 신뢰 계층에서 제외
  • 실시간 상태를 반영하는 state.json 및 git log 등 실제 Filesystem 데이터를 Single Source of Truth로 설정
  • 요약본 생성 시 반드시 refresher(스크립트, 트리거, cron 등)를 동일 커밋에 포함하는 R6 설계 원칙 적용
  • 상태 보고 전 4단계의 shell command(git log, git status, ADR 카운트, jq 기반 JSON 파싱)를 통한 데이터 검증 프로세스 구축
  • Markdown 파일을 '최종 소스'가 아닌 '초안 및 사고 정리용(Draft thinking)' 도구로 역할 재정의

- 파생 데이터(Derived Data) 생성 시 갱신 메커니즘(Refresher)을 반드시 설계에 포함했는가? - 문서화된 상태 정보보다 실제 시스템의 state-file이나 로그를 우선순위에 두는 검증 절차가 있는가? - 자동화되지 않은 정적 요약본을 신뢰하여 의사결정을 내리는 프로세스가 존재하지 않는가?

원문 읽기