# Agent 미팅: InsuWiki 협업 검토 시스템 + 신뢰도 UX 설계

**날짜**: 2026-04-11
**소집 이유**: 제이회장님 1인 승인 병목 해소 + Firestore 신뢰도 필드 활용 설계
**참여 페르소나**: 엔키(백엔드), 이쉬타르(프론트엔드), 나부(UX/UI), 닌기르수(테스터)
**미팅 모드**: hybrid
**토론 깊이**: thorough
**총 사이클 수**: 2

---

## Cycle 1 (Independent Round)

### 팀장 분석

현재 시스템:
- wiki-statuses.json 파일 기반 상태 관리 (동시성 제어 불가)
- `/api/wiki/entries/{id}/approve` API에 인증 미구현 (SEC-01 CRITICAL)
- Firestore documents 컬렉션에 sourceType/verificationStatus/authorityTier 필드 존재하나 프론트엔드 미활용
- authorityTier 하드코딩: kakao_expert=3.5, 나머지=4

### 페르소나 의견

**엔키(백엔드)**: Firestore 서브컬렉션 기반 리뷰 데이터 모델 제안. 상태 전이 엔진(State Machine) + Firebase Custom Claims 권한 모델. compositeReliabilityScore 사전 계산. 외부 노출 3단계(HIGH/MEDIUM/LOW) 추천.

**이쉬타르(프론트엔드)**: InsuWiki 앱 내 6번째 탭(조건부 노출) 추천. TrustBadge 컴포넌트 + TrustFilter(체크박스+슬라이더) 설계. 3단계 반응형(Desktop/Tablet/Mobile) 전략. Firestore 실시간 리스너 + 소프트 락.

**나부(UX/UI)**: 4단계 신뢰도 등급 추천(공식확인/전문가검증/참고정보/검토대기). 검토자 3가지 페르소나 분석. "근거 대결" 기반 의견 충돌 해결. 미검증 레이블 "검토 대기" 제안. 프로그레시브 디스클로저 + 컨텍스트 반응형 미검증 콘텐츠 처리.

**닌기르수(테스터)**: CRITICAL 9건 + HIGH 14건 리스크 식별. 인증 부재(P0 블로커), Race Condition, 듀얼라이트 일관성, 기존 문서 authorityTier 부재, 자기검토 방지. Firestore 쿼리 제약 및 접근성 테스트 요구사항.

### 합의/결론 (Cycle 1)

**전원 합의 12건:**
1. wiki-statuses.json → Firestore 마이그레이션 필수
2. 인증(Authentication) 반드시 선행 (P0 블로커)
3. reviewer 역할 추가 (admin/reviewer/member/guest)
4. Firestore 서브컬렉션으로 리뷰 데이터 관리
5. 상태 머신 패턴으로 상태 전이 관리 (draft→in_review→approved/rejected/revision_requested)
6. admin이 고위험 콘텐츠 최종 승인 권한 보유
7. compositeReliabilityScore 사전 계산하여 Firestore 저장
8. TrustBadge는 색상 + 텍스트 이중 인코딩 (접근성)
9. 기본 필터: "검증된 정보만" (안전한 기본값)
10. 초기 검토자: 제이회장님 초대제 (5~8명)
11. 자기 검토(self-review) 금지
12. 프로그레시브 디스클로저 (정보 레이어링)

### 미해결 항목
- 신뢰도 외부 등급 수 (3 vs 4)
- 미검증 콘텐츠 레이블
- 검토 UI 위치

---

## Cycle 2 (Sequential — 쟁점 해결)

### 팀장 분석

3건의 쟁점에 대해 양측 논거를 비교 분석.

### Devil's Advocate (닌기르수 기반)

**지정**: 닌기르수

1. **실패 시나리오**: 검토자 병목 — 5~8명의 초기 검토자 이탈/비활동 시 "검토 대기" 콘텐츠 적체 → 위키 전체 신뢰도 하락 악순환
2. **후회 이유**: 4단계 등급이 과잉 — "공식 확인" 해당 콘텐츠가 5% 미만이면 불필요한 복잡성 (단, 4→3 축소가 3→4 확장보다 용이)
3. **더 단순한 대안**: 검토 시스템 없이 출시 — 제이회장님 수동 "확인됨" 배지 방식 (구현 비용 1/5, 그러나 보험 정보 신뢰도 요구사항에 미달)

**반박**: 검토자 병목은 모니터링+알림으로 대응 가능. 4단계→3단계 축소는 역방향보다 쉬움. 검토 시스템 없는 출시는 Plan B로 기록하되, "신뢰할 수 있는 보험 정보"가 차별화 핵심이므로 채택 불가.
**판정**: 반박 수용. DA 우려에 대한 대응책을 설계에 포함.

### 비관습적 대안: AI 사전 분류 + 인간 검토 하이브리드

LLM이 콘텐츠 등록 시 자동 등급 추천 → 검토자는 AI 추천을 승인/수정만.
- 최강 지지 논거: 검토 속도 2~3배 향상, 병목 직접 완화
- 최강 반론: AI 오분류 → "AI가 OK했으니 대충 승인" 위험
- 이상적 시나리오: 콘텐츠 500건+, 검토자 20명+ 규모
- 노력 수준: 중간 (API 호출 비용 + 프롬프트 튜닝)
- 리스크 등급: 중간

**판정**: Phase 2에서 도입 검토. MVP에서는 인간 검토만. Firestore 스키마에 `aiSuggestedGrade` 필드 예약.

### 합의/결론 (최종)

| 쟁점 | 결정 | 핵심 근거 |
|------|------|-----------|
| 신뢰도 등급 | **4단계** (공식확인/전문가검증/참고정보/검토대기) | 보험에서 공식 정보와 전문가 의견 구분 필수 |
| 미검증 레이블 | **"검토 대기"** | 기여자 동기 보호 = 초기 위키 생존의 핵심 |
| 검토 UI | **앱 내 탭 통합** (조건부) | 5~8명 규모에 별도 패널은 과잉 (YAGNI) |

---

## Temporal Interrogation (시간대별 결정사항)

### [HOUR 1] 작업 시작 첫 1시간
- [RESOLVED] Firebase Custom Claims로 reviewer 역할 구현 (기존 Auth 확장)
- [RESOLVED] Firestore 서브컬렉션 구조: documents/{docId}/reviews/{reviewId}
- [OPEN] 인증 미들웨어를 대시보드 서버(Python)에 먼저 적용할지, InsuWiki 앱(Next.js)에 먼저 적용할지 — 팀 협의 필요

### [HOUR 2-3] 핵심 구현 중반
- [RESOLVED] 상태 전이: draft→in_review→approved/rejected/revision_requested
- [RESOLVED] compositeReliabilityScore 가중치: source(0.20), verification(0.25), authority(0.25), review(0.15), freshness(0.10), sourceReference(0.05)
- [OPEN] 기존 문서 authorityTier 백필 기본값 — kakao_community는 4, 나머지는 5로 할지 (닌기르수 BV-01-F 이슈)
- [OPEN] Firestore 복합 인덱스 조합 수 — 인덱스 상한(200개) 대비 필요 인덱스 수 사전 산정

### [HOUR 4-5] 구현 후반 + 통합
- [RESOLVED] TrustBadge: 4단계 × 색상(남색/녹색/황색/회색) + 텍스트 레이블
- [OPEN] 기존 대시보드 `/api/wiki/entries/{id}/approve` 하위 호환성 — 기존 API 유지하면서 새 리뷰 API 병행할지, 마이그레이션 기간 결정
- [OPEN] E2E 테스트: 검토 워크플로우 전체 흐름 테스트 시나리오 확정

### [HOUR 6+] 마무리 + QC
- [RESOLVED] 머지 전략: worktree 브랜치에서 작업 후 아누 판단
- [OPEN] 문서화 범위 — Firestore 스키마 변경 사항 문서 갱신 대상 파일 목록
- [OPEN] 배포 순서 — 백엔드(인증+리뷰API) → 프론트엔드(TrustBadge+필터) → 검토 UI 순차 배포

---

## 최종 합의 사항

1. **인증 선행**: 다중 검토 시스템 구현 전 API 인증 레이어 필수 (P0)
2. **Firestore 전환**: wiki-statuses.json → Firestore status 필드 + reviews 서브컬렉션
3. **4역할 체계**: admin / reviewer / member / guest (Firebase Custom Claims)
4. **상태 머신**: draft → in_review → approved / rejected / revision_requested
5. **콘텐츠 위험도별 차등 정책**: 고위험(약관해석 등)=admin 최종승인 필수, 저위험=reviewer 합의 자동승인
6. **4단계 신뢰도**: 공식확인(남색) / 전문가검증(녹색) / 참고정보(황색) / 검토대기(회색)
7. **compositeReliabilityScore**: 6개 구성요소 가중 평균, Firestore에 사전 계산 저장
8. **검토 UI**: InsuWiki 앱 내 6번째 탭 (reviewer/admin에게만 조건부 노출)
9. **기본 필터**: "검증된 정보만" (Tier 1~3만 표시, Tier 4는 의도적 행동 필요)
10. **초기 검토자**: 제이회장님 초대제 5~8명, 오픈 모집은 안정화 이후
11. **자기 검토 금지 + 근거 기반 검토** (투표 아닌 근거 대결)
12. **감사 로그**: documents/{docId}/auditLog/{logId} 서브컬렉션
13. **접근성**: 색상+텍스트 이중 인코딩, aria-label, 최소 터치 타겟 24×24px
14. **AI 사전 분류**: Phase 2에서 도입 검토, 스키마에 aiSuggestedGrade 예약

## 미해결 항목
- 기존 대시보드 API 하위 호환 마이그레이션 기간 (OPEN)
- 기존 문서 authorityTier 백필 기본값 (OPEN)
- Firestore 복합 인덱스 사전 산정 (OPEN)
- 검토자 적체 모니터링 알림 임계값 (OPEN — 7일/20건 초과 가설)

## 구현 우선순위 (Phase 분리)

### Phase 1 (MVP — 2주)
- 인증 미들웨어 + reviewer 역할
- Firestore status 마이그레이션 + reviews 서브컬렉션
- 상태 전이 엔진
- TrustBadge 컴포넌트 + 기본 필터
- 미검증 콘텐츠 경고 배너

### Phase 2 (확장 — 4주)
- 검토 탭 UI (대기열 + 상세 + 액션)
- compositeReliabilityScore 계산 + 정렬
- 감사 로그
- 분야별 전문가 태그
- 알림 시스템

### Phase 3 (성숙 — 4주)
- AI 사전 분류 도입 검토
- 전문성 가중 검토 시스템
- 게이미피케이션 (품질 기반 뱃지)
- 사용성 테스트 + 등급 체계 검증

## 다음 단계
- 합의 사항을 기반으로 구현 태스크 지시서 작성
- Phase 1 서브태스크 분해 및 팀원 할당
- Firestore 스키마 변경 PR 선행