# 📅 Agent 회의록: Wiki 보호 전략 9-Agent 종합 검토

> **일시**: 2026-02-15 21:40
> **참석자**: PM, Planner, Backend, Frontend, Data, QA, Legal, UX, Reflect (전원 참석)
> **안건**: Wiki 정밀 보호 전략(Revision, Rate Limiting)에 대한 잠재적 위험(Issue) 도출

---

## 1. 각 에이전트별 잠재적 이슈 제기 (Issues Raised)

### ⚖️ Legal Agent (법률/규제) - **CRITICAL**
- **Issue 1 (개인정보 잔존)**: "사용자가 실수로 PII(주민번호, 전화번호 등)를 올렸다가 삭제해도, `revisions` 컬렉션에 영구히 남습니다. 이는 GDPR/개인정보보호법 위반 소지가 있습니다."
- **Issue 2 (잊혀질 권리)**: "회원 탈퇴 시, 그 사용자가 기여한 'Revision'의 작성자 정보는 어떻게 처리합니까? 익명화(Anonymization) 프로세스가 필요합니다."
- **제안**: **특정 Revision 영구 삭제(Purge)** 기능이 관리자에게 반드시 있어야 함.

### 💾 Data Agent (데이터/비용)
- **Issue 3 (저장소 비용 폭발)**: "모든 수정 사항을 전체 스냅샷(Full Snapshot)으로 저장하면, 10KB 문서가 100번 수정될 때 1MB가 됩니다. Firestore 비용이 급증할 수 있습니다."
- **제안**:
    - **Differencing**: 변경분(Diff)만 저장 (구현 복잡도 높음).
    - **Pruning Policy**: 오래된 버전은 **기간별 압축**(예: 1달 전 데이터는 1주일 1개만 남김) 또는 **최대 개수 제한**(최근 50개) 도입.

### 🖥️ Frontend Agent (UI/UX 구현)
- **Issue 4 (Diff 구현 난이도)**: "텍스트 기반의 Diff는 쉽지만, 이미지나 테이블이 포함된 Markdown/HTML의 Diff를 시각적으로 보여주는 것은 까다롭습니다."
- **Issue 5 (Rate Limit 경험)**: "사용자가 기껏 긴 글을 썼는데 '저장 실패(Rate Limit)'가 뜨면 좌절합니다. **낙관적 UI(Optimistic UI)** 처리가 오히려 독이 될 수 있습니다."

### 🎨 UX Agent (사용자 경험)
- **Issue 6 (History 노이즈)**: "'오타 수정', '점 하나 찍음' 같은 마이너한 수정 내역이 History를 도배하면, 정작 중요한 변경을 찾기 힘듭니다."
- **제안**: **'Minor Edit' (알림/기록 최소화) 체크박스**를 제공하거나, 짧은 시간 내의 연속 수정은 **하나의 버전으로 Squash**해야 함.

### 🔧 Backend Agent (성능/로직)
- **Issue 7 (Transaction 경합)**: "문서 저장 시 `documents` 업데이트 + `revisions` 추가가 Transaction으로 묶여야 하는데, 동시 수정이 빈번하면 재시도(Retry)로 인해 대기 시간이 길어질 수 있습니다."

### 🧪 QA Agent (테스트)
- **Issue 8 (복원 정합성)**: "과거 버전으로 복원(Restore)했을 때, 그 사이 변경된 **메타데이터(Tag, Link)**와의 불일치가 발생할 수 있습니다. 본문은 과거로 갔는데, 태그는 현재 상태라면?"

### 🧠 Reflect Agent (지식 관리)
- **Issue 9 (문맥 파편화)**: "AI가 문서를 분석할 때, 어느 버전을 '진실(Truth)'로 봐야 합니까? 너무 잦은 버전 변경은 AI의 검색/요약 품질을 떨어뜨릴 수 있습니다."

## 2. 대응 전략 수정 (Revised Strategy)

### A. Legal 대응: "Admin Purge" & "Hard Delete"
- `admin`은 특정 Revision을 영구 삭제할 수 있는 권한을 가짐.
- 탈퇴한 사용자의 `updatedBy`는 `unknown` 또는 `deleted_user`로 마스킹.

### B. Data 대응: "Snapshot + Pruning"
- Diff 저장은 복잡하므로 **Full Snapshot**을 유지하되, **오래된 버전은 자동 정리(Pruning)**.
    - 규칙: 최근 30일(무제한) -> 그 이후(주당 1개) -> 1년 이후(월당 1개). (추후 Cloud Function으로 구현)

### C. UX/Frontend 대응: "Debounce & Squash"
- **Squash**: 동일 사용자가 5분 이내에 연속 저장하면, 새로운 Revision을 만들지 않고 **마지막 Revision을 덮어씌움(Update last revision)**. (노이즈 감소)
- **Diff View**: 초기에는 `jsdiff`를 이용한 텍스트 라인 단위 Diff만 제공 (MVP).

## 3. 결론 (Consensus)
초기 기획보다 **"법적 리스크(PII)"**와 **"저장소 효율(History Noise)"** 문제가 중요하게 대두됨.
이를 반영하여 Spec을 수정해야 함.

**Action Item**:
1.  `revisions` 저장 로직에 **Squash 전략** (5분 내 본인 수정 병합) 추가.
2.  `Admin`용 **Revision 강제 삭제 API** 추가.
3.  탈퇴 회원 처리 정책 수립.