# 맥락노트: InsuWiki LLM Wiki 패턴 흡수

**작성일**: 2026-04-11
**근거**: Agent Meeting 합의 (task-1641.1), 2 사이클
**참여자**: 오딘, 토르, 미미르, 로키(DA), 야누스

## 결정 근거

### 방향 A 선택 (현행 유지 + 3가지 흡수)

**비용 축**
- 결정: 현행 Firestore가 비용 최적. LLM Wiki 전환 불필요.
- 근거: Firestore 100K건까지 월 $31. LLM Wiki 전환 시 초기 Ingest $10,000+. Claude Max 환경에서 LLM 토큰 절감 이점 무의미 (야누스, 오딘).
- 추가: SaaS화 시 매 쿼리 LLM 호출 비용 발생 (GPT-4o 기준 10만 쿼리/월 = $1,000) (토르).

**확장성 축**
- 결정: Firestore의 수평 확장이 LLM Wiki보다 우월.
- 근거: 마크다운 1,000건+ 시 index.md 토큰 한계 (~125K 토큰). 분할 시 RAG와 복잡도 수렴. Firestore O(log n) 인덱스 (토르).
- 핵심 수치: Firestore 1M reads = $0.06, 쿼리 <100ms. LLM Wiki grep O(n) 선형 저하.

**SaaS화 축**
- 결정: Firestore 기반이 즉시 SaaS 전환 가능.
- 근거: 멀티테넌시 — Firestore subcollection/프로젝트 분리 즉시 가능. 마크다운 기반은 OS 레벨 접근 제어 필요, 보안 감사 통과 어려움. Firebase Auth 이미 통합 완료 (야누스, 오딘).

**지식 품질 축**
- 결정: 인간 검토 + 상태 머신이 보험 도메인에 필수.
- 근거: "보험 정보 오류 = 금소법 위반". 현행 4역할 검토 + draft→approved 상태 머신은 규제 준수 설계. LLM 자동 생성은 할루시네이션 영속화 + 증폭 리스크 (로키).
- 공격 벡터: Prompt Injection → cascade update로 1건 오염 → 10-15페이지 확산 (로키).

**검색/발견 축**
- 결정: LLM Wiki의 엔티티/컨셉 자동 추출은 Firestore 위에서 구현 가능.
- 근거: 현행 5탭 카테고리의 평면적 한계 인정. 그러나 entities 컬렉션 + extractedEntities 필드 추가로 네트워크 구조 구현 가능 (오딘, 미미르).

### LLM Wiki 전환(B) 기각

| 기각 축 | 핵심 사유 | 발언자 |
|---------|----------|--------|
| 확장성 | 1,000건+ 시 index.md 토큰 한계, 파일시스템 I/O 병목 | 토르 |
| 보안 | Prompt Injection cascade, Git 접근 제어 부적합, 감사 추적 불가 | 로키 |
| SaaS | 멀티테넌시/인증/결제 레이어 전무, 보안 감사 통과 불가 | 야누스 |
| 비용 | 전환 비용 대비 절감 미미, Claude Max에서 토큰 절감 무의미 | 야누스 |
| UX | 메타데이터 관리/다중 사용자 동시 편집에 열등, TrustBadge 구현 곤란 | 미미르 |

### 로키 DA 도전과 해소

**도전 1: Claude API SPOF**
- 수용: 3기능 모두 Claude 의존은 리스크.
- 해소: 큐 기반 비동기 + 3회 재시도 + pending 마킹 + 수동 재처리 UI.
- 기각: fallback LLM(Gemini)은 비용 대비 효과 낮음.

**도전 2: entities 쓰레기 데이터**
- 수용: LLM 추출 비결정적, 중복/불일치 누적.
- 해소: suggestedEntities(임시) → 사용자 확인 → entities(확정) 승격 워크플로우.

**도전 3: 수동 태그 5개가 더 단순**
- 부분 수용: 순수 수동 태그는 업로드 마찰 높고 태그 품질 관리 비용 발생 (미미르 반박).
- 해소: 자동 추출 초안 + 사용자 확인 하이브리드.

**도전 4: PII 유출 (가장 심각)**
- 수용: CF 자동 트리거 → 고객 개인정보 외부 전송 → 개인정보보호법 위반.
- 해소: 자동 트리거 제거 → 명시적 "엔티티 추출" 버튼 + PII 마스킹 레이어(정규식 기반).

**도전 5: lint 모순 감지 할루시네이션**
- 부분 수용: 보험 약관의 맥락 의존적 조항에서 false positive 높음.
- 해소: 모순 감지만 LLM 사용(나머지 3항목 규칙 기반) + confidence score + 0.8 미만은 "검토 필요" 분류.

**도전 6: Prompt Injection (/query)**
- 수용: 검색어가 프롬프트에 삽입 → 권한 밖 문서 노출 + cache 오염.
- 해소: system/user 역할 분리 + 사후 권한 필터링 + tenant_id cache 바인딩.

### 기각된 비관습적 대안

**SQLite+FTS5+LLM 요약 (토르)**
- 기각 사유: Firestore 이미 충분한 검색/저장 성능 제공. 마이그레이션 불필요. 실시간 동기화/멀티유저 기능 재구현 필요.

**역방향 위키 (미미르)**
- 기각 사유: 현 단계 5~8명 사용자, query_logs 부족으로 패턴 축적 데이터 없음.
- 부분 반영: Phase 3 이후 query_logs 1,000건+ 축적 시 재검토. 맥락노트에 기록.

## 주의사항

### PII 마스킹 필수
- Claude API에 문서 콘텐츠 전송 전 반드시 PII 마스킹 실행
- 정규식 패턴: 주민번호(NNNNNN-NNNNNNN), 전화번호(010-NNNN-NNNN), 계좌번호
- 마스킹 실패 시 API 호출 차단 (fail-safe)

### 엔티티 승격 워크플로우
- 자동 추출 결과는 suggestedEntities에만 저장
- 사용자가 확인/수정 후 entities 컬렉션에 승격
- 미확인 suggestedEntities는 검색에 활용하되 "미확인" 표시

### Phase 1과의 의존성
- Phase 1 Week 3 마이그레이션에서 extractedEntities/suggestedEntities/entityLinks 필드 예약 추가
- entities 컬렉션 스키마는 Phase 3에서 생성 (Phase 1에서는 빈 필드만 예약)

### Claude API 비용 관리
- Claude Max 내부 사용 시 비용 0이나, rate limit 존재
- SaaS화 시 사용자별 API 호출 과금 모델 필요 (향후 결정)
- 비용 상한선: 월 API 호출 횟수 모니터링 + 알림 (API 사용량 대시보드 연계)