# ADR: Wiki 문서 보호 및 버전 관리 전략

> **일시**: 2026-02-15 21:45
> **상태**: 승인됨 (Approved)
> **결정자**: PM Agent (User 위임)

## 1. 배경 (Context)
InsuWiki는 다수의 사용자가 참여하는 지식 저장소로, 악의적인 편집(Vandalism)이나 우발적인 데이터 손실 위험이 존재합니다.
단순한 "정기 백업(Snapshot)"만으로는 특정 시점의 미세한 문서 훼손을 복구하기 어렵고, 데이터 손실 창(Window)이 큽니다.

## 2. 고려된 대안 (Alternatives Considered)

### A. 매일 전체 백업 (Daily Full Backup)
- **장점**: 구현이 매우 쉬움 (gcloud 명령 한 줄).
- **단점**: 복구 시점(RPO)이 최대 24시간 전으로 제한됨. 특정 문서만 되돌리기 매우 번거로움.
- **평가**: **기각 (Rejected)**. 재해 복구용으로는 필요하나, Wiki 보호용으로는 부족함.

### B. CRDT/OT 기반 실시간 이력 (Yjs/Liveblocks)
- **장점**: 구글 닥스 수준의 문자 단위 이력 추적 가능.
- **단점**: 구현 난이도가 극도로 높음. 현재 기술 스택(Firestore) 구조를 대폭 변경해야 함.
- **평가**: **기각 (Rejected)**. 현 단계의 오버엔지니어링.

### C. Revision Subcollection + Squash (제안된 안)
- **장점**:
    - **세밀한 복구**: 언제든 특정 버전으로 롤백 가능.
    - **구현 용이성**: Firestore의 기본 기능(Subcollection) 활용.
    - **효율성**: Squash 전략으로 불필요한 저장 최소화.
- **단점**: 저장소 용량 증가 (텍스트라 미미함). PII 문제(Purge로 해결).
- **평가**: **채택 (Accepted)**. 비용 대비 효용(ROI)이 가장 높음.

## 3. 결정 (Decision)
**"Revision Subcollection with Squash Strategy"**를 최종 채택합니다.

### 핵심 근거
1.  **신뢰성**: Wiki 서비스의 핵심 가치는 "데이터 무결성"입니다. 상세 이력 없이는 신뢰를 담보할 수 없습니다.
2.  **가성비**: 복잡한 CRDT 없이도, Subcollection만으로 90% 이상의 '타임머신' 기능을 제공할 수 있습니다.
3.  **확장성**: 추후 '기여자 통계', '문서 신뢰도 점수' 등으로 데이터를 활용할 수 있는 기반이 됩니다.

## 4. 결과 (Consequences)
- **Positive**: 사용자는 안심하고 문서를 수정할 수 있음 (언제든 되돌릴 수 있으므로).
- **Negative**: 구현 공수가 다소 증가함 (API 로직 + UI). 저장소 비용 모니터링 필요.