데이터 아카이올로지

문제: 6개월 전 DB 덤프를 열었더니 is_active=False 인 row 가 있다. 지금 코드 기준으로는 만료된 것 같지만, 그때는 의미가 달랐을 수도 있다. README 도, git blame 도, Slack 검색도 답을 안 준다.

@History 는 이 문제만을 해결하기 위한 태그입니다.

언제 추가하나

추가해야 할 때:

• 컬럼의 NULL 정책이 바뀜
• ENUM 값이 추가/제거/리네임됨
• 기본값이 변경되어 신규/구 row 동작이 달라짐
• 비즈니스 룰 임계값 변경 (예: trial 일수, grace 기간)
• 마이그레이션이 백필 없이 적용됨

스킵해도 되는 때:

• 순수 리팩토링
• 변수명 변경
• 성능 개선
• 의미 변화 없는 인덱스 추가

형식

@History:
  - 2024-03-15: trial 7일 → 14일 (이전 가입자는 7일 기준, 백필 없음)
  - 2024-11-02: valid_until NOT NULL 강제 (migration 0042)

• 날짜는 ISO YYYY-MM-DD (정렬 가능)
• 항목당 한 줄 (이상적으로 60자 이내)
• “왜” 가 아니라 “무엇이 바뀌었나” + 백필 여부

활용 예시

미래의 어떤 분석가가 2024-04 시점 cohort 의 retention 을 보다가:

“2024년 3월 가입자 중 trial 7일 만료된 사람들이 더 많아 보이는데?”

@History 가 답을 줍니다 — “3월 15일에 14일로 늘어났고 백필이 없었다”.

이 정보는 DB 안에 없습니다. 코드 옆에 적어두는 이유입니다.

AI 가 읽는 방식

lore sync 가 만든 L2/L3 마크다운을 Claude Code 가 컨텍스트로 받으면, 이런 질문에 정확히 답합니다:

2024년 6월에 만료된 row 의 trial 길이는 며칠이었나?

→ AI 가 @History 항목을 보고 “14일” 이라고 답합니다.