# Option C 하이브리드 탐색: 리스크 심층 분석 미팅

> **일시**: 2026-02-09 13:26
> **참석자**: PM, UX 전문가, Frontend 전문가, Backend 전문가, Data 전문가, QA 전문가
> **안건**: 하이브리드 탐색 구조의 리스크 및 고려사항 심층 분석

---

## 📋 미팅 아젠다

스펙 문서 Section 9의 리스크를 각 에이전트 관점에서 심층 분석하고, 완화 방안을 구체화한다.

---

## 1. 리스크 카테고리 분류

### 🔴 Critical (프로젝트 실패 가능)
### 🟠 High (주요 기능 저해)
### 🟡 Medium (사용성 저하)
### 🟢 Low (마이너 이슈)

---

## 2. 에이전트별 리스크 분석

### 📊 PM (Project Manager) 의견

| 리스크 ID | 리스크 | 심각도 | 상세 분석 |
|----------|-------|--------|----------|
| PM-01 | **범위 확대(Scope Creep)** | 🟠 High | 카테고리 추가 요청, 태그 관리 기능 등 요구사항이 계속 늘어날 가능성. 초기에 MVP 범위를 명확히 정의해야 함. |
| PM-02 | **일정 지연** | 🟠 High | 예상 2주 → 실제 4주 이상 소요 가능. Firestore 인덱스 설정, 마이그레이션 테스트에 예상보다 시간 소요. |
| PM-03 | **사용자 교육 필요** | 🟡 Medium | 기존 사용자가 새 탐색 방식에 적응하는 데 시간 필요. 변경 알림/가이드 필요. |

**PM 권고사항:**
> "Phase 1에서는 카테고리 필터만 구현하고, 태그 시스템은 Phase 2로 분리하는 것을 권장합니다. MVP 우선 원칙."

---

### 🎨 UX 전문가 의견

| 리스크 ID | 리스크 | 심각도 | 상세 분석 |
|----------|-------|--------|----------|
| UX-01 | **인지 부하 증가** | 🟠 High | 카테고리 8개 + 태그 다수 → 사용자가 어디서 시작할지 혼란. 위키 서비스 특성상 "검색 우선" 패턴과 충돌 가능. |
| UX-02 | **분류 결정 어려움** | 🟡 Medium | 문서 작성 시 "어떤 카테고리에 넣어야 하지?" 고민으로 작성 허들 증가. |
| UX-03 | **모바일 UX 문제** | 🟠 High | 가로 스크롤 카테고리 + 태그 → 모바일에서 탐색 어려움. 반응형 설계 필수. |
| UX-04 | **필터 조합 복잡성** | 🟡 Medium | 카테고리 + 태그 + 검색 동시 사용 시 결과 예측 어려움. |

**UX 완화 방안:**
```
1. 카테고리 수 축소: 8개 → 5개 이하 (핵심만)
2. 기본 카테고리 "전체" 강조 (변경 없이 사용 가능)
3. 모바일: 카테고리를 접기/펼치기 드롭다운으로 변경
4. 편집 시 카테고리 필수X, 선택적으로 유도
```

**UX 권고사항:**
> "사용자 테스트 없이 전체 롤아웃은 위험합니다. 최소 5명 대상 프로토타입 테스트 후 진행을 권장합니다."

---

### 💻 Frontend 전문가 의견

| 리스크 ID | 리스크 | 심각도 | 상세 분석 |
|----------|-------|--------|----------|
| FE-01 | **상태 관리 복잡도** | 🟠 High | 탭 + 카테고리 + 태그 + 검색어 + 정렬 = 5개의 필터 상태 조합. URL 동기화, 브라우저 뒤로가기 처리 필요. |
| FE-02 | **성능 저하** | 🟡 Medium | 필터 변경 시마다 Firestore 쿼리 재실행. 디바운싱 + 캐싱 전략 필요. |
| FE-03 | **태그 자동완성 구현** | 🟡 Medium | 기존 태그 목록 실시간 fetch + 유사어 매칭 로직 필요. 별도 API 또는 클라이언트 캐싱. |
| FE-04 | **UI 일관성 유지** | 🟢 Low | 8개 카테고리 색상, 태그 스타일 등 디자인 시스템 확장 필요. |

**Frontend 완화 방안:**
```typescript
// 필터 상태 URL 동기화 예시
const [filters, setFilters] = useSearchParams({
  tab: 'wiki',
  category: 'all',
  tags: [],
  search: '',
  sort: 'latest'
});

// 디바운싱 적용
const debouncedSearch = useDebouncedValue(filters.search, 300);
```

**Frontend 권고사항:**
> "상태 관리를 위해 URL SearchParams 활용을 권장합니다. 새로고침/공유 시에도 필터 상태 유지됩니다."

---

### 🗄️ Backend/Data 전문가 의견

| 리스크 ID | 리스크 | 심각도 | 상세 분석 |
|----------|-------|--------|----------|
| BE-01 | **Firestore 쿼리 제한** | 🔴 Critical | `array-contains-any`는 최대 30개 값만 지원. 태그 10개 이상 동시 필터링 불가. |
| BE-02 | **복합 인덱스 폭발** | 🟠 High | docType × category × tags × updatedAt 조합 많아지면 인덱스 수 급증. Firestore 인덱스 제한 200개. |
| BE-03 | **태그 정규화 문제** | 🟡 Medium | "#신규계약" vs "#신규 계약" vs "#신규_계약" 중복. 저장 전 정규화 로직 필수. |
| BE-04 | **마이그레이션 리스크** | 🟠 High | 기존 문서 1000개 이상 시 배치 업데이트 시간/비용 증가. |

**Backend 완화 방안:**
```typescript
// 태그 정규화 함수
function normalizeTag(tag: string): string {
  return tag
    .toLowerCase()
    .replace(/\s+/g, '')      // 공백 제거
    .replace(/[#_]/g, '')      // 특수문자 제거
    .slice(0, 20);             // 최대 길이 제한
}

// 다중 태그 쿼리 전략 (클라이언트 필터링 혼합)
// 1. 태그 1개만 Firestore 쿼리에 포함
// 2. 나머지 태그는 클라이언트에서 필터링
```

**Backend 권고사항:**
> "태그 다중 필터는 Firestore 제한으로 완벽 구현 불가. 단일 태그 필터 + 클라이언트 필터 혼합 방식을 권장합니다."

---

### 🧪 QA 전문가 의견

| 리스크 ID | 리스크 | 심각도 | 상세 분석 |
|----------|-------|--------|----------|
| QA-01 | **테스트 조합 폭발** | 🟠 High | 8 카테고리 × N 태그 × 2 탭 × 정렬 = 수백 개 테스트 케이스. 자동화 필수. |
| QA-02 | **데이터 마이그레이션 검증** | 🟠 High | 기존 문서의 카테고리 기본값 적용 + 누락 확인 필요. |
| QA-03 | **회귀 테스트 범위** | 🟡 Medium | 기존 검색, 백링크, 편집 기능에 영향 없는지 확인 필요. |
| QA-04 | **성능 테스트** | 🟡 Medium | 1000+ 문서 환경에서 필터링 응답 시간 측정 필요. 목표: 500ms 이하. |

**QA 테스트 계획:**
```markdown
## 필수 테스트 케이스
1. [ ] 카테고리 필터 단독 동작
2. [ ] 태그 필터 단독 동작  
3. [ ] 카테고리 + 태그 조합
4. [ ] 카테고리 + 태그 + 검색어 조합
5. [ ] 필터 초기화 (전체로 돌아가기)
6. [ ] URL 공유 후 필터 상태 복원
7. [ ] 모바일 반응형 테스트
8. [ ] 마이그레이션 후 기존 문서 접근 가능 확인
```

**QA 권고사항:**
> "E2E 테스트 자동화를 구현 초기에 세팅해야 합니다. 조합이 많아 수동 테스트만으로는 커버리지 확보 불가."

---

## 3. 리스크 우선순위 종합

| 순위 | 리스크 ID | 리스크 | 심각도 | 담당 |
|-----|----------|-------|--------|-----|
| 1 | BE-01 | Firestore 쿼리 제한 | 🔴 Critical | Backend |
| 2 | UX-01 | 인지 부하 증가 | 🟠 High | UX |
| 3 | FE-01 | 상태 관리 복잡도 | 🟠 High | Frontend |
| 4 | BE-02 | 복합 인덱스 폭발 | 🟠 High | Backend |
| 5 | PM-02 | 일정 지연 | 🟠 High | PM |
| 6 | UX-03 | 모바일 UX 문제 | 🟠 High | UX |

---

## 4. 합의된 완화 전략

### 🎯 즉시 적용 (Spec 반영)
1. **카테고리 5개로 축소** (생명, 손해, 언더라이팅, 계약관리, 일반)
2. **다중 태그 필터 → 단일 태그 필터로 변경** (Firestore 제한 회피)
3. **태그 정규화 로직 필수** (저장 전 처리)
4. **URL 상태 동기화 구현**

### 📅 Phase 분리
```
Phase 5-1 (1주): 카테고리 필터만 구현 + 마이그레이션
Phase 5-2 (1주): 태그 시스템 추가
Phase 5-3 (선택): 태그 추천/자동완성 고도화
```

### ⚠️ Go/No-Go 조건
- 프로토타입 사용자 테스트 5명 이상 완료
- E2E 테스트 자동화 세팅 완료
- 마이그레이션 스크립트 검증 완료

---

## 5. Action Items

| 담당 | 항목 | 상태 |
|-----|------|------|
| PM | Phase 분리 일정 확정 | 🟡 대기 |
| UX | 카테고리 5개 확정 + 와이어프레임 | 🟡 대기 |
| Frontend | URL 상태 관리 POC | 🟡 대기 |
| Backend | 태그 정규화 + 인덱스 설계 | 🟡 대기 |
| QA | E2E 테스트 시나리오 작성 | 🟡 대기 |

---

## 6. 결론

> **멀티에이전트 합의**: Option C 진행 가능하나, 위 완화 전략 적용 필수.
> **핵심 변경**: 카테고리 8개→5개, 다중 태그→단일 태그 필터로 축소.
> **권고**: Phase 분리 + 사용자 테스트 + E2E 자동화 선행.

---

> 📋 **사용자 결정 필요**: 완화 전략 적용 후 진행 여부 결정