# 🧠 에이전트 회의록: 네임스페이스 충돌 및 해결 전략
**일시**: 2026-02-12 11:45
**주제**: 개인(My) vs 공용(Wiki) 문서 간 "동일 이름" 처리 전략
**참석자**: PM, UX 디자이너, 리드 개발자

---

## 1. 핵심 갈등 (Core Conflict)
**PM**: "사용자는 '개인 공간'과 '공용 공간'에서 같은 이름의 문서(예: 'React')를 만들고 싶어 합니다. 단순히 '개인 문서 우선' 규칙만 적용하면, 공식 위키 문서를 영영 못 보게 되는 문제가 발생하지 않을까요?"

## 2. 시나리오 분석 (Scenario Analysis)

### 시나리오 A: 학습 모드 (The "Forking" Intent)
*   **상황**: 사용자가 'React'를 공부하며 자신만의 요약본을 만듭니다. 이미 공식 'React' 문서가 존재합니다.
*   **개발자**: "'개인 우선' 규칙에 따라 `[[React]]` 링크는 무조건 개인 노트로 연결됩니다."
*   **UX**: "학습용으로는 좋지만, 공식 문서를 참조해야 할 때는 불편합니다. 사용자가 공식 문서의 존재를 모르게 될 수도 있습니다(Shadowing)."
*   **해결책**:
    *   **네비게이션 UI**: 개인 문서를 볼 때, 같은 이름의 공식 문서가 있다면 알림 배너를 띄웁니다. *"⚠️ 공식 위키 문서가 존재합니다. [Wiki 문서 보기]"*

### 시나리오 B: 의사소통 왜곡 (The "Definition" Conflict)
*   **상황**: 팀원이 "공식 정책 A"를 의도하고 `[[Policy A]]` 링크를 걸었습니다.
*   **문제**: 나는 "Policy A"라는 이름의 개인 메모(불평글)를 가지고 있습니다. 링크를 클릭하면 내 메모가 뜹니다.
*   **PM**: "작성자의 의도(공식)와 읽는 사람의 경험(개인)이 달라집니다. 오해를 불러일으킬 수 있습니다."
*   **결론**: 위키링크(`[[이름]]`)는 본질적으로 **문맥 의존적**입니다. 이를 기술적으로 강제하기보다, UI적으로 "이것은 당신의 개인 문서입니다"라고 명확히 알려주는 것이 중요합니다.

### 시나리오 C: 발행 충돌 (Publishing Conflict)
*   **상황**: 내 개인 'React' 노트를 다듬어서 '공개(Public)'로 전환하려 합니다. 이미 공용 공간에 'React'가 있습니다.
*   **개발자**: "공용 공간에 이름이 같은 문서가 2개 존재하면 링크가 깨집니다."
*   **PM**: "이름 충돌 시 **발행을 차단**해야 합니다. 1) 이름을 바꾸거나, 2) 기존 문서에 내용을 병합하도록 유도해야 합니다."

### 시나리오 D: 우연한 발견 (Search Discovery)
*   **상황**: 검색창에 "React"를 입력합니다.
*   **동작**: 검색 결과에 두 가지가 모두 뜹니다.
    *   `React` (🔒 My Doc)
    *   `React` (🌍 Wiki Doc)
*   **효과**: "아, 공식 문서가 이미 있었네?" 하고 깨닫게 되어 불필요한 중복 생성을 예방합니다.

### 시나리오 E: 문서의 노후화 (Staleness)
*   **상황**: 내 개인 'Onboarding' 노트는 2년 전 것인데, 공식 문서는 어제 업데이트되었습니다.
*   **위험**: 내 낡은 노트만 보다가 중요한 업데이트를 놓칠 수 있습니다.
*   **완화**: "Shadow 알림"에 *"공식 문서가 최근 업데이트됨"* 뱃지를 추가하여 공식 문서 확인을 유도합니다.

### 시나리오 F: 문맥 없는 복사/붙여넣기 (Context-Free Copy)
*   **상황**: 내 개인 노트의 `[[Project A]]` 링크를 복사해서 슬랙에 붙여넣습니다. 동료가 그걸 자기 위키에 붙여넣습니다.
*   **결과**: 동료에게는 동료의 `Project A` 문서(또는 공식 문서)로 연결됩니다.
*   **통찰**: 위키링크는 **상대적 주소**와 같습니다. 이는 위키 시스템의 특징이므로 사용자의 이해가 필요합니다.

### 시나리오 G: 아카이빙 전략 (Archive Strategy)
*   **상황**: 내 개인 노트보다 공식 문서가 더 완벽해졌습니다. 이제 `[[React]]`를 누르면 공식 문서가 떴으면 좋겠습니다.
*   **행동**: 내 개인 문서 이름을 `React (Legacy)`로 변경합니다.
*   **결과**: 이제 내 서랍에 `React`가 없으므로, 시스템은 2순위인 **공식 문서 `React`**를 찾아 연결합니다.
*   **이점**: 이름 변경만으로 자연스럽게 "공식 문서 우선" 모드로 전환할 수 있습니다.

### 시나리오 H: 이름 변경의 파급 (Renaming Drift)
*   **상황**: 공식 문서 `React`가 `React JS`로 이름이 바뀌었습니다. 내 문서는 여전히 `React`입니다.
*   **결과**:
    *   `[[React]]`: 내 개인 문서로 연결
    *   `[[React JS]]`: 공식 문서로 연결
*   **통찰**: 네임스페이스가 갈라지는 현상입니다. 백링크 시스템이 이를 추적할 수 있어야 합니다.

### 시나리오 I: 사유화 문제 (The "Privatization" Loophole)
*   **상황**: A가 문서를 공개하고, B와 C가 열심히 기여했습니다. 그런데 A가 갑자기 "비공개"로 돌려버립니다.
*   **결과**: B와 C의 기여 내역이 A의 개인 소유물이 되거나 사라집니다. (지식 증발)
*   **제안**: **"공개 = 기여"** 원칙 적용.
    *   한 번이라도 타인의 수정이 발생한 문서는 **비공개 전환 불가** (또는 관리자 승인 필요).
    *   정 필요하면 "사본"만 비공개로 가져가고, 원본은 공용 공간에 남김.

### 시나리오 J: 악의적 훼손 (Vandalism Risk)
*   **상황**: 누군가 공용 문서를 삭제하거나 내용을 전부 지워버립니다.
*   **해결책 1 (권한)**: 공용 문서는 **관리자(Admin)만 삭제 가능**하게 제한. 작성자는 "아카이브(숨김)"만 가능.
*   **해결책 2 (복구)**: **버전 기록(Version History)** 필수 도입. 언제든 이전 버전으로 되돌릴 수 있어야 함.

---

## 3. 기술적 전략 (Technical Strategy)
*   **스토리지 최적화 (버전 관리)**:
    *   모든 버전을 메인 DB에 로드하면 느려집니다.
    *   **Subcollection (`doc/history`)** 사용: 평소에는 로드하지 않고, 요청 시에만 불러옵니다.
    *   **구글 드라이브?**: 공용 위키의 권한 문제로 인해 부적합(❌). Firestore가 정답입니다.

---

## 4. 최종 권고 및 개발 로드맵 (Final Recommendation)

우리는 **"Option 2: 컨텍스트 기반 해결 + UI 투명성"** 전략을 채택하며, 데이터 안정성을 위해 단계별로 접근합니다.

### 🏗️ Phase 1: 네임스페이스 충돌 해결 (즉시 실행)
**기간**: 금주 내 완료
**목표**: 개인과 공용 문서가 '동거'할 수 있는 환경 구축
1.  **ID 팩터링**: `Daily Note` ID를 `daily-YYYY-MM-DD-UID`로 변경하여 날짜 충돌 원천 차단.
2.  **Shadow Indicator**: `내가 가진 문서 == 공식 문서 이름`일 때, 상단에 **"공식 문서 보기" 배너** 노출.
3.  **Conflict Check**: 개인 문서를 `Public`으로 전환할 때, 이미 같은 이름의 공식 문서가 있으면 **차단 및 이름 변경 유도**.
4.  **Navigation Fix**: 문서 성격(My/Wiki/Daily)에 따라 상단 탭 활성화 상태 동기화 (완료됨).

### 🛡️ Phase 2: 데이터 무결성 및 거버넌스 (다음 단계)
**기간**: Phase 1 안정화 직후
**목표**: 지식의 사유화 방지 및 훼손 복구
1.  **삭제 권한 강화**: `Public` 문서는 **관리자만 삭제 가능**. (지식 증발 방지)
2.  **비공개 전환 제한**: 기여자가 2명 이상인 문서는 `Private` 전환 차단 (또는 Fork 처리).
3.  **버전 기록 (History)**: `firestore` 서브컬렉션을 활용한 스냅샷 저장 및 롤백 UI 구현.

---
**결정**: Phase 1 스펙으로 개발을 착수합니다.