# Agent 미팅: InsuWiki 검토+신뢰도 PRD v2 적합성/적정성 검증

**날짜**: 2026-04-11
**소집 이유**: task-1636.1 Agent Meeting v2 합의(20건) + 제이회장님 피드백 6건 반영 후, PRD v2가 최선인지/빠진 건 없는지/현실적으로 구현 가능한지 검증
**참여 페르소나**: 불칸(백엔드), 이리스(프론트), 아테나(UX), 헤임달(보안QA), 로키(레드팀)
**미팅 모드**: hybrid
**토론 깊이**: thorough
**총 사이클 수**: 2

---

## Cycle 1 (Independent Round)

### 다그다 분석

검증 대상 문서 3종(계획서/맥락노트/체크리스트)과 InsuWiki 코드베이스를 사전 분석했다.

핵심 발견 (코드베이스 근거):
- `firestore.ts:14` — UserRole = 'admin' | 'member' | 'guest' (reviewer 부재)
- wiki-statuses.json 파일 미존재 — 상태는 TypeScript 타입으로만 관리
- `/api/wiki/entries/{id}/approve` API 미존재 (SEC-01 대상이 존재하지 않음)
- TIER_MAP 코드(`constants.ts:29-43`) vs PRD 불일치: regulation 1.5 vs 1, kakao_expert 3.5 vs 3
- `/api/ai/index-wiki`, `/api/ai/search-wiki` 인증 미적용 (CRITICAL)
- `/api/ai/invalidate-cache` Bearer 토큰 존재만 확인, verifyIdToken 미호출

### 페르소나 의견 요약

**불칸(백엔드)**:
- 승인 차등: sourceType 기반 시작 OK, riskLevel override 필드 추가 필요
- 버전 관리: 서브컬렉션 정답 (코드에 이미 versions/revisions 존재, 통합 필요)
- 검색 종합: Phase 3 적절
- 교차 필터: 인덱스 3개면 충분 (200개 한도에 여유)
- Phase 1 일정: 실작업 51시간, 2주 빡빡, 3주 권장
- **Security Rules 상태 머신 비추천** — 서버 사이드 전환 강력 권장
- Big Bang 마이그레이션 과설계 — wiki-statuses.json 미존재, 점진적 마이그레이션이 정답
- documentScores: 인라인 필드 권장
- "자기" 판별: contributorIds 배열 (코드에 이미 존재)
- TIER_MAP: 코드 기준 통일 권장

**이리스(프론트)**:
- 교차 필터: 기존 page.tsx에 카테고리×출처 AND 필터 골격 존재
- SourceBadge→TrustBadge: 어댑터 패턴으로 점진 마이그레이션
- Phase 2: 13일(2.5주), Push 알림 제거 시 2주 가능하나 빡빡
- 오류 신고: 인라인+모달 하이브리드, 기존 피드백 패턴 재활용
- 접근성: 현재 SourceBadge에 aria 속성 전무. SVG 아이콘 교체 권장
- onSnapshot: limit 50 충분, visibilitychange 기반 detach

**아테나(UX)**:
- 오류 신고: 신고 허들 최소화 우선. 선택형 사유 + 선택적 메모 1줄
- **교차 필터: 5~8명 규모에서 과잉**. 카테고리 필터 + 신뢰도순 정렬로 대체
- 검색 종합: 자동 아닌 명시적 버튼 트리거. 결과 3건 이상일 때만 표시
- **TrustBadge: "검토대기"는 프로세스 상태, 정보 성격과 분리 필요**
- **동적 기본 필터: "영리하지만 불투명". 정적 기본 + 시각적 구분 + 토글 권장**
- 게이미피케이션: 6개월→15명 규모 트리거로 변경
- 검토 대시보드: 불필요. "대기 N건, 최고 경과 X일" 한 줄 상태 요약으로 대체
- Phase 2: 2a(시각 변화 1주) + 2b(기능 변화 1.5주) 분리 권장
- 디스클로저 Layer 3: Phase 3로. Layer 2 Popover에 이력 링크 자리 확보

**헤임달(보안QA)**:
- 2단계 승인: CF가 주 강제 지점. Rules는 불변식만
- SEC-01 팬텀 위험. 존재하지 않는 API
- **AI 엔드포인트 3종 인증 부재 = CRITICAL** (SEC-01보다 긴급)
- UserRole 중복 정의: MEDIUM, 단일 소스화 필요
- 오류 신고 DoS: Rate limiting 필수
- **Custom Claims 도입 필수** (get() 10회 제한 대응)
- Emulator 테스트: 400 케이스 관리 가능
- 마이그레이션: 4단계 순서 필요

**로키(레드팀)**:
- 승인 차등: CRITICAL — 위험도 다운그레이드 공격 (메타데이터 조작)
- 오류 신고: CRITICAL — 신뢰도 폭격 공격
- 버전 관리: HIGH — 유령 정보 잔존
- **LLM 검색 종합: CRITICAL — Indirect Prompt Injection**
- API 인증 부재: CRITICAL — SEC-01보다 현실적 위험
- ADMIN_EMAILS 하드코딩: HIGH
- **경량 수정 면제: HIGH** — 숫자 교체/부정어 삽입/점진적 의미 전복
- 검토자 공모: CRITICAL — 소규모 조직의 구조적 취약점
- CF 에러 메시지 정보 노출: MEDIUM

### 합의/결론 (Cycle 1 — 10건)

1. Security Rules 상태 머신 비추천 → 서버 사이드 전환
2. API 인증 부재(SEC-02) CRITICAL 즉시 패치
3. 버전 관리: versions 서브컬렉션 유지
4. documentScores: 인라인 필드
5. "자기" 판별: contributorIds 배열
6. 점진적 마이그레이션 (Big Bang 금지)
7. 검색 종합: 명시적 버튼 트리거 + Prompt Injection 3중 방어
8. 오류 신고: 선택형 사유 + Rate Limiting + 자동 상태변경 금지
9. Custom Claims 도입 필수
10. TIER_MAP 코드 기준 통일

### 미해결 항목 (Cycle 2로)
- Phase 1 일정: 2주 vs 3주
- 동적 기본 필터 vs 정적 기본 + 시각적 구분
- TrustBadge: 4단계 통합 vs 3+1 분리
- 교차 필터 복잡도 정당성
- 경량 수정 면제 구체 기준

---

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

### Devil's Advocate: 헤임달

1. **실패 시나리오**: Week 1의 Custom Claims 세팅 복잡화 → 3주도 압축. 대응: Day 3 체크포인트 + 감사 로그 Week 3 이월 플랜B.
2. **후회 이유**: 정적 기본 필터가 300건 이상에서 정보 과부하. 대응: `useWikiFilter` 훅 캡슐화로 전환 비용 최소화.
3. **더 단순한 대안**: 경량 면제 자체 폐기, 모든 수정 큐 + diff 크기 정렬. 기각: 검토자 1~2명 부담 과다. 단, diff 크기순 정렬은 Phase 3에 반영.

### 비관습적 대안 (미미르 관점): "위키 폐기, LLM-Native Knowledge Base 전환"
- 기각. 법규/판례 도메인에서 LLM 환각 리스크 수용 불가.
- 부분 반영: Phase 3 LLM 응답에 원문 링크 + 문단 하이라이트 필수.

### 합의/결론 (Cycle 2 — 5건)

C2-01. Phase 1: **3주** (Week 1 인증+Claims, Week 2 상태머신+검토, Week 3 백필+통합테스트). Phase 2: 2.5주 (2a 1주 + 2b 1.5주).
C2-02. 필터: **정적 기본("전체")** + 미검증 문서 시각적 구분 + "검증만 보기" 세션 토글. 동적 필터 기각.
C2-03. TrustBadge: **3단계 + VerificationTag 분리**. 어댑터 패턴 마이그레이션.
C2-04. 필터/정렬: **카테고리 칩 + 신뢰도순 정렬**. 교차 필터 기각.
C2-05. 경량 수정: **7조건 AND** (20자이하+숫자없음+부정어없음+URL없음+법규번호없음+고위험아님+7일3회미만). CF 판정.

### DA 반영 설계 수정 (3건)
DA-01. Week 1 Day 3 체크포인트
DA-02. `useWikiFilter` 커스텀 훅 캡슐화 (Phase 2b)
DA-03. Phase 3 검토 큐 diff 크기순 정렬

---

## 최종 합의 사항 (22건 + DA 3건)

**보안 기반 (7건):**
1. SEC-01 재정의: 팬텀 위험. "현재 미존재, 향후 생성 시 인증 필수"
2. SEC-02 CRITICAL: index-wiki/search-wiki/invalidate-cache 즉시 인증 추가
3. Security Rules: 상태 머신 비추천. 불변식만(민감 필드 보호 + approved 직접 전이 차단)
4. Custom Claims 도입: request.auth.token.role로 Rules 접근
5. 경량 수정 면제: 7조건 AND, CF 서버사이드 판정
6. 3계층 방어: Rules(불변식) → CF(비즈니스 로직) → API Routes(인증)
7. 감사 로그: CF only, append-only + Cloud Logging 이중화

**검토 시스템 (7건):**
8. 4역할: admin/reviewer/member/guest (Custom Claims + 문서 기반 이중 관리)
9. 상태 머신: CF 서버 사이드 (draft→in_review→approved/rejected/revision_requested)
10. 이벤트 소싱: 리뷰 생성 → CF onCreate → 상태 전이
11. 자기 검토 금지: contributorIds 배열 기반
12. 검토자 배정 무작위화 + 연속 배정 제한
13. 승인 차등: sourceType 기반 + riskLevel override. 저위험=reviewer 1명, 고위험=reviewer+admin
14. 위험도 자동 판정: CF에서 sourceType/카테고리/키워드 기반 riskLevel 할당

**데이터 모델 (4건):**
15. reviews: 서브컬렉션 documents/{docId}/reviews/{reviewId}
16. versions: 서브컬렉션 유지, revisions와 통합
17. documentScores: reliabilityScores 인라인 필드 (verification 0.30, authority 0.20, source 0.15, review 0.15, freshness 0.10, sourceRef 0.10)
18. TIER_MAP: 코드 기준 통일 (regulation=1.5, kakao_expert=3.5)

**UX (4건):**
19. TrustBadge 3단계 + VerificationTag 분리 (어댑터 패턴 마이그레이션)
20. 정적 기본 필터("전체") + 시각적 구분 + "검증만 보기" 토글
21. 카테고리 칩 필터 + 신뢰도순 정렬 (교차 필터 기각)
22. 검토 UI: 독립 화면(앱바 아이콘+배지) + InlineReviewPanel

**Phase 일정:**
- Phase 1: 3주 (Week 1 인증, Week 2 상태머신, Week 3 백필+테스트)
- Phase 2a: 1주 (TrustBadge + 미검증 배너)
- Phase 2b: 1.5주 (필터 + 검토 UI)
- Phase 3: TBD (오류 신고, 검색 종합 LLM, 교차 필터 재검토)

## 미해결 항목
없음 (7건 전부 확정)

## 다음 단계
- 3문서(계획서/맥락노트/체크리스트) v3 업데이트
- Phase 1 서브태스크 분해 및 팀원 할당 준비