# InsuWiki 아키텍처 심층 비교: LLM Wiki(Obsidian) vs Firestore+Next.js

## Lv.4 작업

## Agent Meeting 설정
- **사이클**: 무한 (전원합의까지)
- **모델**: 모든 참여자 opus
- **스킬**: `/agent-meeting` 반드시 호출 (SKILL.md 전체 규칙 준수)
- **로키(레드팀)**: 필수 참석
- **페르소나**: SKILL.md persona-list에서 선택 (팀 자체 멤버 사용 금지)
- **3문서**: 미팅 완료 후 반드시 계획서/맥락노트/체크리스트 작성

## 배경

### LLM Wiki 패러다임 (Andrej Karpathy)
Andrej Karpathy가 제시한 "컴파일 타임 지식 정리" 방식:
- 3계층: Raw Sources → Wiki Pages → Schema
- 4커맨드: /ingest(자동 구조화), /query(교차 참조 종합 답변), /file-answer(답변→소스 순환), /lint(위키 건강 검사)
- 엔티티/컨셉 자동 추출 + 교차 연결
- RAG 대비 토큰 95% 절감 (Atlan 분석)
- 참고 URL: https://aboutcorelab.com/llm-wiki-in-obsidian-for-2nd-brain/

### 현재 InsuWiki 아키텍처
- 스택: Next.js + Firebase Auth + Firestore + Cloud Functions
- 데이터: documents 컬렉션 (sourceType, verificationStatus, authorityTier 등)
- 카테고리: 생명보험/손해보험/공통/기타 (4개, 넓음)
- 검색: Firestore 기본 쿼리 (벡터 검색/RAG 없음)
- 승인: 다중 검토 시스템 설계 중 (task-1639.1 완료)
- 신뢰도: TrustBadge 4단계 (3→공식확인/전문가검증/참고정보 + 검토대기)

### 핵심 질문
제이회장님: "어떤 방안이 더 고도화된 방안인지, 비용/확장/SaaS화까지 고려했을 때 더 유리한지 심층적 검토 필요"

## Agenda 1: 아키텍처 비교 분석

### 비교 축 (5개)

#### 1. 비용 측면
- LLM Wiki: 인제스트 시 1회 LLM 호출 비용 vs RAG 매 쿼리 비용
- Firestore: 읽기/쓰기 과금 모델, Cloud Functions 호출 비용
- 우리 환경: Claude Max (내부 LLM 무제한) → 비용 구조 다름
- 인프라 유지 비용 비교

#### 2. 확장성 측면
- LLM Wiki: 마크다운 파일 기반 → 수천~수만 건 시 성능?
- Firestore: 수평 확장 내장, 실시간 동기화, 인덱스 제약(200개)
- 동시 사용자 처리: Obsidian(로컬) vs Firestore(서버리스)
- 데이터 양 증가에 따른 스케일링 전략

#### 3. SaaS화 가능성
- LLM Wiki: 개인 지식 관리 도구 → B2C SaaS로 전환 시 멀티테넌시 과제
- Firestore+Next.js: 이미 웹앱 → SaaS 전환 자연스러움
- 인증/결제/테넌트 분리 구현 용이성
- 보험 도메인 특수 요구사항 (규제, 감사 추적)

#### 4. 지식 품질 관리
- LLM Wiki: /lint로 위키 건강 유지, 하지만 **할루시네이션이 위키에 영구 기록**되는 위험
- Firestore: 신뢰도 체계 + 다중 검토 + 감사 로그 → 보험 정보 정확도 보장
- 보험 정보 오류 = 금소법 위반 가능 → 이 제약이 아키텍처 선택에 미치는 영향

#### 5. 검색/발견 품질
- LLM Wiki: 엔티티/컨셉 자동 추출 + 교차 연결 → 연관 정보 발견 우수
- 현재 InsuWiki: 카테고리 4개 + 키워드 검색 → 연관 발견 약함
- 하이브리드: Firestore 인프라 + LLM Wiki의 엔티티 추출 패턴 접목 가능성

## Agenda 2: 방향 결정

전원합의로 아래 중 하나 결정:

**A. 현행 유지 (Firestore+Next.js)**
- 이유: SaaS화, 보안, 다중 사용자 → 현행이 우세
- 단, LLM Wiki에서 3가지 선택 흡수:
  1. 엔티티/컨셉 자동 추출 (카테고리 세분화)
  2. /lint 패턴 (위키 건강 검사)
  3. /query 패턴 (검색 종합 정리)

**B. LLM Wiki로 전환**
- 이유: 지식 관리 패러다임 자체가 우월
- Firestore를 백엔드로 유지하되, 마크다운 기반 구조로 전환

**C. 하이브리드 신규 설계**
- Firestore 인프라 + LLM Wiki 지식 관리 패턴 결합
- 새로운 아키텍처 설계 필요

## Agenda 3: (방향 A 확정 시) 3가지 흡수 기능 설계

### 3-1. 보험 엔티티/컨셉 자동 추출
- "실손보험", "갱신형 vs 비갱신형", "자동차보험 자기부담금" 등 추출
- 카드 간 교차 연결 (tags 또는 entities 서브컬렉션)
- 인제스트 시 내부 LLM(claude CLI)으로 엔티티 추출
- Firestore에 entities 컬렉션 또는 documents 필드로 저장

### 3-2. /lint (위키 건강 검사) 스크립트
- 중복 카드 탐지 (유사도 비교)
- 모순 정보 감지 (같은 엔티티에 상충하는 답변)
- 고아 항목 정리 (교차 연결 없는 고립 카드)
- 주기적 실행 (Scheduled Function 또는 수동)

### 3-3. /query 패턴 → 검색 종합 정리
- Phase 3 체크리스트에 이미 포함 ("종합 정리 보기" 버튼)
- LLM Wiki의 교차 참조 종합 답변 패턴 참고
- 엔티티 기반 관련 카드 자동 수집 → LLM 종합 → 신뢰도별 정렬

## 참조 파일
- InsuWiki PRD: `/home/jay/workspace/memory/plans/insuwiki/review-trust-system/plan.md`
- 체크리스트 v3: `/home/jay/workspace/memory/plans/insuwiki/review-trust-system/checklist.md`
- 맥락노트: `/home/jay/workspace/memory/plans/insuwiki/review-trust-system/context-notes.md`
- InsuWiki 앱: `/home/jay/projects/insuwiki/`
- Firestore 타입: `/home/jay/projects/insuwiki/nextapp/src/types/firestore.ts`

## 보고서
`/home/jay/workspace/memory/reports/task-{TASK_ID}.md`