# 회의록: 콘텐츠 공개 범위 및 보안 전략 수립

> **일시**: 2026-02-11 17:00
> **참석자**: Jay (PM), Alex (Reflect Specialist), Sarah (UX), Ken (Security)
> **안건**: Wiki 및 Daily 문서의 민감 정보 보호를 위한 공개 범위(Visibility) 정책 수립

---

## 1. 현황 및 문제점 (Current Status)

### 1.1. 데이터 구조 및 보안 규칙
- **Wiki (`documents`)**: 현재 `isAuthenticated()` 규칙만 적용되어 있어, **로그인한 모든 사용자가 모든 문서를 볼 수 있음.**
- **Daily (`dailyNotes`)**: 현재 보안 규칙(firestore.rules)에 **명시적 정의가 누락**되어 있음. (기본적으로 차단되거나, 잘못된 설정 시 전체 공개 위험)
- **Schema**: `Document` 타입에 `visibility: 'private' | 'shared'` 필드가 존재하지만, 실제 로직(DB Rules/Frontend)에는 반영되지 않음.

### 1.2. 사용자 요구사항
- "모든 카드를 Wiki에 오픈하면 안 되는 부분이 있다."
- 개인적인 기록(Daily)이나 민감한 업무 문서는 **기본적으로 비공개**여야 함.

---

## 2. 전문가 의견 (Expert Opinions)

### 🗣️ Alex (Reflect Specialist)
> "지식 관리 도구(Reflect, Obsidian)의 핵심은 **'Private by Default'**입니다."

- **제안**: 모든 문서는 생성 시 기본적으로 **Private (비공개)** 상태여야 합니다.
- **공유 모델**: 'Shared Graph' 또는 'Public Space' 개념을 도입하여, 사용자가 **명시적으로 공개를 선택한 문서만** 타인에게 노출되어야 합니다.
- **Transclusion(임베딩)**: Private 문서 내에 Public 문서를 링크하는 것은 자유롭지만, Public 문서에서 Private 문서를 임베딩할 땐 "권한 없음" 처리가 필요합니다.

### 🛡️ Ken (Security Agent)
> "Firestore Security Rules를 통해 데이터 레벨에서 원천 차단해야 합니다."

- **Rule 변경안**:
    - **Daily Notes**: `authorId`가 본인인 경우에만 `read/write` 허용 (철저한 개인화).
    - **Wiki Documents**: `visibility` 필드에 따라 접근 제어 분기.
        - `public`: 모든 인증된 사용자 읽기 가능.
        - `private`: `authorId` == `request.auth.uid` 인 경우만 읽기 가능.
- **필드 강제**: 모든 문서 생성/수정 시 `visibility` 필드 작성을 강제해야 합니다.

### 🎨 Sarah (UX Designer)
> "사용자가 현재 문서의 공개 여부를 직관적으로 알 수 있어야 합니다."

- **UI 요소**:
    - 문서 제목 옆에 🔒(Private) / 🌏(Public) 아이콘 표시.
    - 에디터 상단에 '공개 범위 설정' 토글 또는 드롭다운 제공.
    - Wiki 목록(사이드바)에서 Private 문서는 흐리게 표시하거나 별도 섹션(예: 'My Desk')으로 분리.

---

## 3. 합의된 솔루션 (Proposed Solution)

### 3.1. 공개 범위 (Visibility) 레벨 재정의
| 레벨 | 식별자 (`visibility`) | 설명 | 적용 대상 |
| :--- | :--- | :--- | :--- |
| **비공개 (기본)** | `'private'` | 작성자(Author) 본인만 열람/수정 가능 | **Daily Notes 기본값**, 개인 메모 |
| **팀 공개** | `'team'` (or `'shared'`) | 인증된 **팀 멤버 전원** 열람 가능 (수정 권한은 별도 논의) | **Wiki 문서 기본값**, 업무 매뉴얼 |
| **전체 공개** | `'public'` | (옵션) 로그인하지 않은 사용자도 열람 가능 (추후 고려) | 대외비 아닌 공지사항 등 |

*(현재 InsuWiki는 사내 시스템이므로 `team`이 실질적인 '전체 공개' 역할을 함)*

### 3.2. 구현 로직 (Implementation Plan)

#### A. Firestore Security Rules 업데이트
```javascript
// documents 컬렉션
allow read: if resource.data.visibility == 'team' || resource.data.authorId == request.auth.uid;

// dailyNotes 컬렉션
allow read, write: if resource.data.userId == request.auth.uid;
```

#### B. 데이터 마이그레이션
- 기존의 모든 Wiki 문서(`documents`)는 `visibility: 'team'`(공개)으로 일괄 업데이트 (업무 지식 공유 목적이므로).
- Daily Notes는 로직상 개인만 접근하도록 수정.

#### C. 프론트엔드 수정
- **문서 생성 시**: `visibility` 선택 UI 제공 (기본값: Wiki='team', Daily='private').
- **리스트 필터링**: '전체 문서' 탭에서는 `team` 문서만, '내 문서' 탭에서는 `private` + `team` 문서 노출.

---

## 4. 결정 요청 (Action Required)
위 전략(Private/Team 이원화 및 Daily 전면 비공개)으로 진행하시겠습니까?
특히, **기존에 작성된 Wiki 문서들을 'Team(전체 공개)'으로 일괄 설정**할지, 아니면 **'Private'으로 돌리고 선별적으로 공개**할지 결정이 필요합니다.

**(권장: 업무용 위키이므로 기존 문서는 'Team', 신규 생성부터 선택권 부여)**