# 카파시 LLM Wiki 패턴 → InsuWiki 적용 심층 분석

> 분석일: 2026-04-05 | 작성: 마르둑(dev5-team) | task-1482.1
> 원문: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

---

## 1. 카파시 LLM Wiki 핵심 요약

### 1.1 슬로건과 철학

**"Knowledge that accumulates, not re-derives"**

매번 RAG로 원본을 재검색/재합성하지 않고, LLM이 지식을 한 번 컴파일하여 마크다운 위키에 누적/유지하는 패턴이다. Vannevar Bush의 Memex(1945) 비전 — 개인 큐레이션된 지식 저장소 + 문서 간 연상적 연결 — 을 LLM으로 실현한다.

핵심 인사이트: **"인간은 위키를 포기한다 — 유지 부담이 가치보다 빨리 증가하므로. LLM은 지루해하지 않고, 교차 참조 업데이트를 잊지 않고, 한 번에 15개 파일을 수정할 수 있다."**

### 1.2 3-Layer 아키텍처

```
Layer 1: raw/              Layer 2: wiki/              Layer 3: schema
 (원본 소스, 불변)          (LLM 산출물, 마크다운)       (구조/규칙 정의)
 papers/                   index.md                    schema.md
 articles/                 log.md                      (CLAUDE.md와 유사)
 datasets/                 concepts/
 repos/                    entities/
 images/                   sources/
                           syntheses/
      ↓ ingest                  ↑ lint (자기치유)
      → LLM compiler →
```

- **Layer 1 (raw/)**: 불변 원본. LLM은 읽기만 함
- **Layer 2 (wiki/)**: LLM이 소유. 생성/수정/유지 전부 LLM이 담당. 사용자는 읽기만
- **Layer 3 (schema)**: 도메인에 따라 진화하는 위키 규칙서

### 1.3 3대 오퍼레이션

**Ingest** (소스 투입)
- 새 소스 도착 → LLM이 읽고 핵심 논의 → 요약 페이지 작성 → 인덱스 갱신 → 관련 10-15개 페이지 업데이트 → 교차 참조 재구성 → 로그 기록
- 1건씩 깊이 있게 or 배치 ingest 가능

**Query** (질의)
- 사용자 질문 → 위키에서 관련 페이지 검색 → 답변 합성 + 인용 → 좋은 답변은 다시 위키 페이지로 저장 (피드백 루프)
- 다양한 출력: 마크다운, 비교표, 슬라이드(Marp), 차트(matplotlib)

**Lint** (자기치유)
- 주기적 건강 검진: 모순 감지, 오래된 정보, 고아 페이지, 누락된 교차 참조, 데이터 갭 탐지
- 위키가 스스로 치유하는 메커니즘

### 1.4 필수 파일

- `index.md`: 카테고리별 전체 페이지 목록 + 1줄 요약 (LLM이 첫 번째로 읽는 파일)
- `log.md`: append-only 연대기 (`## [YYYY-MM-DD] ingest | Title`)
- `concepts/`: 개념 페이지
- `entities/`: 엔티티 페이지
- `sources/`: 원본 소스 참조
- `syntheses/`: 교차 분석/종합 페이지

### 1.5 커뮤니티 실전 교훈

1. **소스 유형별 분류 후 추출**: 다른 소스 유형은 다른 처리 파이프라인 필요
2. **인덱스 토큰 예산**: 4-Level Progressive Disclosure (L0 ~200토큰 ~ L3 5-20K토큰)
3. **타입별 템플릿**: 엔티티 유형(인물/사건/문서)마다 필수 섹션 다름
4. **Dual Output**: 모든 작업은 결과물 + 위키 업데이트 동시 산출
5. **검증 소유**: LLM은 작성자, 인간은 편집장

---

## 2. InsuWiki 현재 상태

### 2.1 프로젝트 개요

- **기술 스택**: Next.js 16 + Firebase (Firestore) + Vercel
- **콘텐츠 저장**: 100% Firestore 기반 (마크다운 파일 없음)
- **프로젝트 상태**: Phase 미시작 (인프라 구축 + AI 기능 PoC 완료)
- **배포**: https://insuwiki.vercel.app

### 2.2 핵심 데이터 모델

InsuWiki는 이미 풍부한 Firestore 컬렉션 구조를 갖추고 있다:

**위키 문서 계층**:
- `documents/{docId}` — 위키 문서 본문 (마크다운 content 필드)
  - `/versions` — 버전 히스토리
  - `/revisions` — 리비전
  - `/embeddings` — 3072차원 벡터 (gemini-embedding-001)
  - `/ai_suggestions` — AI 노드 추천 결과

**보험 지식 계층**:
- `insurance_terms` — 1,192개 보험 용어 사전
- `insurance_metadata` — 보험상품 메타데이터
- `insurance_chunks` — 약관 PDF 청크 + 768차원 임베딩
- `insurance_tables` — 보험료/해지환급금 표
- `insurance_appendices` — 별표/부속서류
- `insurance_summaries` — 3단계 요약 (L1/L2/L3)

**미디어 지식 계층**:
- `youtube_channels` — 유튜브 채널 목록
- `youtube_knowledge` — 영상 청크 + 임베딩
- `youtube_transcripts` — 자막 청크
- `youtube_summaries` — L1/L2 요약

**운영 계층**:
- `links` — 백링크 (method: manual/static/embedding/semantic)
- `query_cache`, `query_logs`, `rate_limits`, `conversation_sessions`

### 2.3 현재 AI 기능

**구현 완료**:
- 정적 매칭 (exact/alias/공백제거/substring) — precision 100%
- 임베딩 유사도 검색 (gemini-embedding-001, 3072차원) — precision@5: 42.26% (현재 비활성)
- RAG 쿼리 라우터 (TABLE_QUERY/VECTOR_SEARCH/DEEP_QUERY/COMPLEX/AMBIGUOUS)
- PDF 인덱싱 파이프라인 (청킹 + 임베딩 + 용어추출 + 별표분류)
- 유튜브 크롤링 파이프라인 (자막추출 + 임베딩 + 3-Layer 요약)
- Whisper GPU 로컬 STT

**미구현**:
- 아누 서버 Claude 연동 (Phase 2)
- 지식 그래프 자동 구축 (Phase 3)
- 고아 노드/순환 참조 감지

### 2.4 콘텐츠 규모

현재 콘텐츠 규모는 소규모이지만, 잠재 소스는 풍부하다:
- 보험 용어: 1,192건 시딩 완료
- PDF 약관: 인덱싱 파이프라인 구축 완료 (블루그린 배포 지원)
- 유튜브 지식: 크롤링 파이프라인 구축 완료
- 위키 문서: 50건 기준 평가 수행 (실제 운영 건수는 가변)
- 프로젝트 문서: 130개+ (docs/ 내부, 개발 참고용)

---

## 3. LLM Wiki 패턴 적용 가능성 분석

### 3.1 패러다임 대비: 현재 InsuWiki vs LLM Wiki

| 차원 | InsuWiki 현재 | LLM Wiki 패턴 | 갭 |
|------|-------------|--------------|-----|
| 콘텐츠 저장 | Firestore (DB 기반) | 마크다운 파일 기반 | **큰 갭** — 아키텍처 근본 차이 |
| 지식 생성 | 인간 작성 + AI 보조 | LLM이 작성, 인간이 큐레이션 | **패러다임 전환 필요** |
| 교차 참조 | AI 노드 자동 연결 (수동 승인) | LLM이 자동 생성/유지 | **부분 구현** (AI suggestions 존재) |
| 인덱싱 | Firestore 쿼리 + 벡터 검색 | index.md 마크다운 파일 | **대안 존재** (동등 기능) |
| 소스 관리 | PDF → Firestore chunks | raw/ 디렉토리 (불변 파일) | **기능적 유사** |
| 자기치유 | 없음 | Lint 오퍼레이션 | **완전 미구현** |
| 쿼리→지식 루프 | RAG 결과 일회성 | 좋은 답변 → 위키 페이지화 | **완전 미구현** |
| 로그 추적 | query_logs (감사 로그) | log.md (연대기) | **부분 유사** |

### 3.2 Ingest 파이프라인 적용

**현재 InsuWiki의 Ingest**:
- PDF → `pdfIndexing.ts` → insurance_chunks (청크 + 임베딩)
- YouTube → `crawlYoutubeChannels.ts` → youtube_knowledge (청크 + 임베딩)
- 수동 → 사용자가 에디터로 위키 문서 작성

**LLM Wiki 방식 Ingest 적용안**:

소스 유형별 Ingest 파이프라인:

1. **법규 소스** (금융위원회, 금융감독원)
   - 원본: 법령 PDF, 고시, 시행세칙
   - Ingest: LLM이 읽고 → 관련 위키 페이지(약관 해석, 상품 비교, 규제 연혁 등) 10-15개 자동 업데이트
   - 교차 참조: "1200% 룰" 변경 시 → 관련 약관 해석 페이지, 영향 분석 페이지, 상품 비교 페이지 자동 갱신
   - **빈도**: 분기 1-2회 (대규모 제도 변경은 연 1-2회)

2. **약관 소스** (보험사별)
   - 원본: 보험 약관 PDF
   - 현재: `pdfIndexing.ts`가 청킹 + 임베딩만 수행
   - LLM Wiki 방식: 청킹 후 LLM compiler가 약관 요약 페이지, 보장범위 비교 페이지, 주요 면책조항 페이지 등 자동 생성
   - **빈도**: 월별 (상품 갱신)

3. **뉴스/업계 동향**
   - 원본: 보험 관련 기사, 업계 리포트
   - Ingest: LLM이 읽고 → 트렌드 페이지, 관련 개념 페이지 업데이트
   - **빈도**: 주별

4. **유튜브 교육 콘텐츠**
   - 원본: 보험 관련 유튜브 (현재 크롤링 파이프라인 존재)
   - LLM Wiki 방식: 자막 → LLM compiler → 개념 페이지 업데이트 + 실무 노하우 페이지 생성
   - **빈도**: 수시

5. **실무 노하우** (제이회장님 전문 지식)
   - 원본: 음성 녹음 (Whisper STT) → 텍스트
   - Ingest: LLM이 텍스트 분석 → 관련 위키 페이지 업데이트 + 새 개념 페이지 생성
   - **핵심 가치**: 암묵지 → 형식지 전환

### 3.3 Self-Healing Lint 적용

보험 도메인 특화 Lint 규칙:

1. **법규 최신성 검증**: 법규 변경 시 영향받는 모든 페이지 자동 플래그
   - 예: "보험업법 시행령 개정" → 관련 약관 해석, 상품 비교, 수수료 구조 페이지에 "STALE" 마크
2. **교차 참조 무결성**: 고아 페이지(인바운드 링크 0), 끊어진 링크 감지
3. **용어 일관성**: insurance_terms 사전 대비 위키 내 용어 불일치 감지
4. **모순 감지**: 동일 개념에 대해 다른 페이지에서 상충되는 설명 탐지
5. **커버리지 갭**: insurance_terms 1,192개 중 위키 페이지가 없는 용어 식별
6. **정확성 리스크**: 금소법 관련 민감 정보에 대한 소스 인용 누락 감지

### 3.4 Query → Wiki 피드백 루프

현재 InsuWiki의 RAG 쿼리는 일회성이다. LLM Wiki 패턴 적용 시:

1. 사용자가 AI 질의 → RAG 답변 생성
2. 답변 품질 평가 (자동 + 사용자 피드백)
3. 우수 답변 → LLM이 관련 위키 페이지에 반영 (새 섹션 추가 or 기존 내용 보강)
4. 반복 질문 패턴 → 새 FAQ 페이지 자동 생성

**구현 연결점**: 이미 `query_logs`와 `/api/ai/feedback` 엔드포인트가 존재하므로, 피드백 데이터를 위키 업데이트로 연결하는 파이프라인만 추가하면 된다.

---

## 4. 기술적 적용 방안

### 4.1 아키텍처 선택지

#### Option A: 순수 마크다운 전환 (카파시 원본 방식)

```
raw/                         → LLM compiler →  wiki/
  법규/                                         index.md
  약관_PDF/                                     log.md
  뉴스/                                        concepts/보장성보험.md
  유튜브_자막/                                   concepts/1200퍼센트룰.md
  음성_녹음/                                     entities/삼성생명종신보험.md
                                                sources/보험업법_시행령.md
                                                syntheses/2026_보험시장_동향.md
```

- **장점**: 카파시 패턴 100% 구현, Obsidian 연동, Git 버전관리
- **단점**: 기존 Firestore 기반 인프라 전면 재작성, 실시간 협업 어려움, 배포 파이프라인 변경 필요
- **적합도**: 낮음 (기존 투자 폐기 부담 큼)

#### Option B: Firestore 기반 LLM Wiki (하이브리드)

```
Firestore                     → LLM compiler →  Firestore
  raw_sources/                                   wiki_pages/
    법규/{id}                                      index (meta document)
    약관/{id}                                      log (meta document)
    뉴스/{id}                                      concepts/{id}
    유튜브/{id}                                     entities/{id}
                                                   syntheses/{id}
```

- Firestore의 `documents` 컬렉션을 wiki_pages로 활용
- 새 `raw_sources` 컬렉션 추가 (불변 원본 저장)
- LLM compiler를 Firebase Functions로 구현
- **장점**: 기존 인프라 100% 활용, 실시간 동기화, 기존 UI/API 재사용
- **단점**: 마크다운 파일 기반의 단순성 상실, Obsidian 네이티브 연동 불가
- **적합도**: 높음 (가장 현실적)

#### Option C: Dual-Store 하이브리드

```
Git repo (마크다운)  ↔  sync  ↔  Firestore (런타임)
  wiki/                           documents/
    index.md                        {docId}
    concepts/                       /embeddings
    entities/                       /ai_suggestions
```

- 마크다운을 canonical source로, Firestore를 런타임 캐시로
- Git commit → webhook → Firestore 동기화
- Firestore 편집 → 마크다운 파일 sync back
- **장점**: 두 세계의 장점 결합, Obsidian 로컬 편집 + 웹 접근
- **단점**: 동기화 복잡성, 충돌 해결 로직 필요, 두 시스템 유지 부담
- **적합도**: 중간 (장기적으로 가치 있으나 초기 복잡도 높음)

### 4.2 추천 접근: Option B (Firestore 기반 LLM Wiki)

InsuWiki의 현재 상태를 고려하면 Option B가 최적이다.

**핵심 설계**:

#### LLM Compiler 모듈 (`functions/src/wikiCompiler.ts`)

```
┌─────────────────────────────────────────────────┐
│                 Wiki Compiler                     │
│                                                   │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐       │
│  │  Ingest   │  │  Query   │  │   Lint   │       │
│  │ Handler   │  │ Feedback │  │  Runner  │       │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘       │
│       │              │              │              │
│       v              v              v              │
│  ┌──────────────────────────────────────────┐    │
│  │          Page Update Engine               │    │
│  │  - 관련 페이지 식별 (임베딩 유사도)        │    │
│  │  - diff 생성 (silent overwrite 방지)      │    │
│  │  - 교차 참조 업데이트                      │    │
│  │  - index/log 갱신                         │    │
│  └──────────────────────────────────────────┘    │
└─────────────────────────────────────────────────┘
```

**Ingest Handler** (onWrite 트리거):
1. `raw_sources/{type}/{id}` 문서 생성 감지
2. 소스 유형별 프롬프트 템플릿 선택
3. Gemini LLM에 소스 + 관련 위키 페이지(index 참조) 전달
4. LLM 응답: 업데이트할 페이지 목록 + diff
5. 배치 업데이트 실행 + log 기록

**Query Feedback Handler**:
1. `query_logs` 중 feedback score 높은 항목 감지
2. 답변 내용 분석 → 관련 위키 페이지 식별
3. 신규 정보이면 페이지에 반영 (섹션 추가 or 기존 보강)
4. 반복 질문 패턴이면 FAQ 페이지 자동 생성

**Lint Runner** (Cloud Scheduler, 주 1회):
1. index 문서에서 전체 페이지 목록 로드
2. 각 페이지의 교차 참조 무결성 검증
3. 소스 문서의 날짜 대비 위키 페이지 최신성 검증
4. 고아 페이지, 커버리지 갭 리포트 생성
5. 자동 수정 가능한 항목은 diff 생성 후 적용

#### Schema 정의 (보험 도메인 특화)

```yaml
# wiki_schema (Firestore config/wikiSchema 문서)

wiki_structure:
  page_types:
    concept:
      required_sections: [정의, 관련법규, 실무적용, 관련용어, 출처]
      example: "종신보험", "1200% 룰", "실손의료보험"
    entity:
      required_sections: [개요, 보장내용, 보험료, 특약, 비교, 출처]
      example: "삼성생명 종신보험 A형", "DB손해보험 운전자보험"
    regulation:
      required_sections: [법령명, 시행일, 주요내용, 영향분석, 관련약관, 출처]
      example: "보험업법 시행령 제XX조", "금소법 제XX조"
    comparison:
      required_sections: [비교대상, 보장범위, 보험료, 특약, 결론]
      example: "종신보험 vs 정기보험", "2026 실손의료보험 비교"
    practice:
      required_sections: [상황, 해결방법, 주의사항, 관련개념]
      example: "보험금 청구 절차", "다중보험 가입 시 주의사항"

  naming_conventions:
    concepts: "concepts/{kebab-case-korean-or-english}"
    entities: "entities/{보험사}-{상품명}"
    regulations: "regulations/{법령명}-{조항}"
    comparisons: "comparisons/{대상A}-vs-{대상B}"
    practices: "practices/{주제}"

  cross_reference_rules:
    - 모든 보험 용어는 insurance_terms 사전과 연결
    - 모든 약관 해석은 원본 약관(sources)에 인용 필수
    - 법규 관련 페이지는 시행일 + 최종확인일 필수
    - 상품 비교 페이지는 비교 기준일 필수

  accuracy_requirements:
    - 금소법 관련 정보는 반드시 원본 법령 인용
    - 보험료/해지환급금 수치는 source 인용 + 기준일 명시
    - "추정", "일반적으로" 등 불확실 표현 시 명시적 경고
    - 면책조항 해석은 약관 원문 병기
```

### 4.3 기존 코드와의 통합 포인트

| 기존 기능 | LLM Wiki 통합 방법 |
|-----------|-------------------|
| `staticMatching.ts` | Ingest 시 교차 참조 자동 생성의 1차 필터로 활용 |
| `embeddingMatching.ts` | 관련 페이지 식별 시 벡터 유사도 검색 활용 |
| `pdfIndexing.ts` | raw_sources에 원본 저장 + wiki compiler에 ingest 트리거 발화 |
| `crawlYoutubeChannels.ts` | 유튜브 자막 → raw_sources 저장 + ingest 트리거 |
| `ragQuery.ts` | Query 오퍼레이션으로 확장 (답변 → 위키 피드백 루프) |
| `query_logs` | Query Feedback Handler의 입력 데이터 |
| `insurance_terms` | Schema의 용어 사전 역할 (Lint 시 일관성 검증 기준) |
| `links` 컬렉션 | LLM Wiki의 교차 참조와 병합 (method: 'wiki_compiler' 추가) |
| `insurance_summaries` | wiki/ concepts 페이지의 초기 시드 데이터로 활용 |

---

## 5. 도메인 특화 분석 (보험)

### 5.1 보험 지식의 특수성

**정확성 요구**: 금소법(금융소비자보호법) 등 법적 리스크가 존재한다. 잘못된 보험 정보는 소비자 피해로 직결된다. LLM Wiki 패턴 적용 시 다음이 필수:
- 모든 사실 주장에 원본 소스 인용 (법령 조항, 약관 페이지, 공시자료)
- LLM이 silent overwrite하지 않고 diff를 생성하여 리뷰 가능하게
- Lint에서 "무출처 주장" 자동 감지

**시의성**: 보험 상품은 월 단위로 갱신되고, 법규는 분기별로 변경된다. LLM Wiki의 Lint가 이 시의성 관리에 핵심적이다.

**전문성 레벨**: 독자가 보험설계사(FA), 일반 소비자, 보험사 직원 등 다양하다. Progressive Disclosure 방식으로 난이도별 콘텐츠 제공이 필요할 수 있다.

### 5.2 소스 유형 분류

| 소스 유형 | 예시 | 빈도 | Ingest 전략 |
|-----------|------|------|------------|
| 법규 | 보험업법, 금소법, 자보법 | 분기 1-2회 | 전체 위키 영향 분석 필수 (cascade update) |
| 약관 | 보험사별 상품 약관 PDF | 월별 | 상품 페이지 + 비교 페이지 업데이트 |
| 공시자료 | 사업비, 손해율, 경영공시 | 분기별 | 통계/비교 페이지 업데이트 |
| 뉴스/리포트 | 업계 동향, 시장 분석 | 주별 | 트렌드 페이지 + 관련 개념 페이지 갱신 |
| 유튜브 | 보험 교육/해설 영상 | 수시 | 실무 노하우 페이지 보강 |
| 전문가 지식 | 제이회장님 음성녹음/메모 | 수시 | 암묵지 → 형식지 전환 (가장 고부가가치) |

### 5.3 보험 도메인 Lint 규칙 세부

1. **법규 연동 Lint**: 법규 소스의 시행일이 위키 페이지의 기준일보다 신규 → STALE 플래그
2. **상품 가용성 Lint**: 판매 중단된 상품의 위키 페이지에 "판매중단" 경고 자동 추가
3. **수치 정합성 Lint**: 보험료/환급금 수치와 원본 약관 수치 불일치 감지
4. **면책 조항 Lint**: 면책사항 설명이 약관 원문과 상이한 경우 플래그
5. **용어 표준화 Lint**: insurance_terms 사전과 위키 내 용어 불일치 교정 제안

---

## 6. 구현 로드맵

### Phase 0: 기반 준비 (1-2주)

**목표**: LLM Wiki 패턴 도입을 위한 데이터 모델 확장

1. Firestore에 `raw_sources` 컬렉션 추가 (소스 유형별 서브컬렉션)
2. `wiki_index` 메타 문서 생성 (카테고리별 페이지 목록 + 요약)
3. `wiki_log` 메타 문서 생성 (append-only 연대기)
4. `config/wikiSchema` 문서 생성 (보험 도메인 스키마)
5. 기존 `documents` 컬렉션에 `page_type` 필드 추가 (concept/entity/regulation/comparison/practice)

**산출물**: Firestore 스키마 마이그레이션, 시드 스크립트

### Phase 1: Ingest MVP (2-3주)

**목표**: 단일 소스 유형(약관 PDF)에 대한 Ingest 파이프라인 구축

1. `wikiCompiler.ts` Firebase Function 구현 (Ingest Handler)
2. 기존 `pdfIndexing.ts` 확장: 청킹 후 `raw_sources`에 원본 저장 + wiki compiler 트리거
3. LLM compiler 프롬프트 설계 (약관 PDF → 관련 위키 페이지 10-15개 업데이트)
4. diff 생성 + 리뷰 UI (admin 페이지에 "Pending Wiki Updates" 섹션)
5. 교차 참조 자동 생성 (기존 `staticMatching` + `embeddingMatching` 활용)

**검증 기준**: 약관 PDF 1건 ingest → 관련 위키 페이지 10개+ 자동 업데이트 + 교차 참조 생성

### Phase 2: Query 피드백 루프 (2-3주)

**목표**: 사용자 질의의 우수 답변을 위키에 자동 반영

1. Query Feedback Handler 구현 (`query_logs` + feedback score 연동)
2. 우수 답변 → 관련 위키 페이지 보강 or FAQ 페이지 자동 생성
3. 반복 질문 패턴 분석 → 커버리지 갭 리포트
4. "이 답변을 위키에 저장" 사용자 액션 추가 (AISidepanel에 버튼)

**검증 기준**: 질의 100건 중 상위 10% 답변 → 위키 페이지에 반영 + 중복 질의 30% 감소

### Phase 3: Lint 자기치유 (2-3주)

**목표**: 위키 건강 자동 관리

1. Lint Runner Cloud Function 구현 (Cloud Scheduler, 주 1회)
2. 7개 Lint 규칙 구현 (법규 최신성, 교차 참조 무결성, 용어 일관성, 모순 감지, 커버리지 갭, 정확성 리스크, 상품 가용성)
3. Lint 리포트 자동 생성 + admin 대시보드 표시
4. 자동 수정 가능 항목 (교차 참조 추가, 용어 정규화) 자동 적용
5. 수동 리뷰 필요 항목 (모순, 법규 변경 영향) 알림

**검증 기준**: 위키 페이지 50개 기준 Lint 실행 → 이슈 탐지율 90%+ + 자동 수정율 40%+

### Phase 4: 소스 확장 (3-4주)

**목표**: 전체 소스 유형 Ingest 파이프라인 완성

1. 법규 소스 Ingest (금융위 고시 PDF → cascade update)
2. 뉴스/리포트 Ingest (웹 크롤링 → 트렌드 페이지 갱신)
3. 유튜브 Ingest (기존 크롤링 파이프라인 → wiki compiler 연결)
4. 전문가 지식 Ingest (음성녹음/메모 → Whisper STT → wiki compiler)
5. 배치 Ingest 모드 (대량 소스 일괄 처리)

**검증 기준**: 5개 소스 유형 모두 → 위키 자동 업데이트 + 교차 참조 생성

### Phase 5: 고도화 (지속)

1. Obsidian 연동 (Option C Dual-Store): 마크다운 export → Obsidian vault + bidirectional sync
2. 지식 그래프 시각화 (D3.js / react-force-graph) — 기존 TODO와 병합
3. Progressive Disclosure 적용 (독자 레벨별 콘텐츠 표시)
4. 다국어 지원 (영문 위키 자동 생성)

### 비용/효과 분석

**비용 (Gemini API 기준)**:
- Ingest 1건 (약관 PDF ~50페이지): ~$0.10-0.20 (입력 ~100K 토큰 + 출력 ~20K 토큰)
- Lint 1회 (50페이지 위키): ~$0.50-1.00
- Query Feedback 처리 (10건/일): ~$0.05-0.10/일
- 월간 예상: 월 $15-30 (소규모 운영 기준)

**효과**:
- 콘텐츠 생성 속도: 인간 작성 대비 10-20배 (약관 1건 분석 → 위키 10페이지 자동 생성)
- 교차 참조 누락: 0에 수렴 (Lint 자동 감지)
- 법규 변경 대응: 수동 몇 주 → Ingest + Lint로 수 시간
- 콘텐츠 일관성: Lint가 모순/불일치 자동 탐지

**리스크**:
- LLM 환각: 보험 정보 정확성은 법적 리스크 동반 → diff 리뷰 + 소스 인용 강제로 완화
- 비용 증가: 위키 규모 확대 시 Lint 비용 선형 증가 → Progressive Lint (변경된 페이지만 검증)로 최적화
- 복잡성: LLM compiler 로직의 유지보수 부담 → Schema 문서에 규칙 중앙 집중

---

## 7. 아누 시스템 메모리 강화와의 연결

### 7.1 Phase 1-3 메모리 강화와의 시너지

아누 시스템의 메모리 강화 3 Phase는 LLM Wiki 패턴과 직접적으로 공명한다:

| 아누 메모리 Phase | LLM Wiki 대응 | 시너지 |
|-----------------|-------------|-------|
| Phase 1: diary 패턴 (Observation → Reflection → Retrieval) | log.md (연대기) | diary의 구조화된 관찰이 위키 log의 모델 |
| Phase 2: FTS5 인덱싱 | index.md + 벡터 검색 | 동일 문제 해결 (대규모 지식 검색) |
| Phase 3: Progressive Disclosure (3-Layer) | 인덱스 토큰 예산 (L0~L3) | **거의 동일한 패턴** |

**특히 Phase 3 Progressive Disclosure는 카파시가 커뮤니티 피드백에서 "4-level progressive disclosure for index token budgets"로 언급한 것과 정확히 일치한다.** 이미 구현된 아누 시스템의 Layer 1(Index) → Layer 2(Summary) → Layer 3(Full) 패턴을 InsuWiki에 직접 적용할 수 있다.

### 7.2 InsuWiki를 아누 Knowledge Base로 활용

현재 아누 시스템의 지식 기반:
- `memory/MEMORY.md` (마스터 인덱스)
- `~/.claude/memory/` (피드백, 사용자 정보)
- `memory_index.db` (FTS5 SQLite)

InsuWiki가 LLM Wiki 패턴으로 성숙하면:
1. **dispatch.py에서 InsuWiki 참조**: 보험 관련 태스크 dispatch 시, InsuWiki의 wiki_index를 Layer 1로 조회하여 관련 컨텍스트를 태스크에 포함
2. **whisper-compile.py 연동**: 브리핑에 InsuWiki 최신 ingest/lint 상태 포함
3. **Cross-system Lint**: 아누 메모리의 보험 관련 정보와 InsuWiki 위키의 정합성 검증
4. **Knowledge Transfer**: 아누 작업 보고서 중 보험 관련 인사이트를 InsuWiki에 자동 ingest

### 7.3 통합 아키텍처 비전

```
┌──────────────────────────────────────────────────────┐
│                    아누 시스템                          │
│  ┌────────────┐  ┌──────────┐  ┌──────────────────┐  │
│  │ dispatch.py │  │ whisper  │  │ memory_search.py │  │
│  │ (태스크)    │  │ (브리핑) │  │ (FTS5 검색)      │  │
│  └──────┬─────┘  └────┬─────┘  └────────┬─────────┘  │
│         │              │                  │            │
│         └──────────────┼──────────────────┘            │
│                        │                               │
│                   wiki_index                           │
│                   (Layer 1 조회)                       │
│                        │                               │
│  ┌─────────────────────┼─────────────────────────┐    │
│  │              InsuWiki (LLM Wiki)                │    │
│  │                     │                           │    │
│  │  raw_sources/ → LLM compiler → wiki_pages/     │    │
│  │   법규, 약관      ↑ lint ↗     concepts/        │    │
│  │   뉴스, 유튜브                  entities/        │    │
│  │   전문가지식                    regulations/     │    │
│  │                                comparisons/     │    │
│  └─────────────────────────────────────────────────┘    │
└──────────────────────────────────────────────────────┘
```

---

## 8. 결론 및 제안

### 8.1 핵심 판단

카파시의 LLM Wiki 패턴은 InsuWiki의 비전과 **근본적으로 정렬**된다. 둘 다 "체계적 지식 축적"이 목표이며, LLM의 유지보수 능력으로 인간의 위키 포기 문제를 해결한다.

InsuWiki의 현재 상태(Firestore 기반 인프라 + AI 기능 PoC 완료 + 본격 콘텐츠 작업 미시작)는 오히려 LLM Wiki 패턴 도입에 **최적 시점**이다. 대규모 레거시 콘텐츠가 없으므로 전환 비용이 최소화된다.

### 8.2 즉시 실행 가능 항목

1. **Schema 정의**: 보험 도메인 특화 위키 구조 + 페이지 타입 + 교차 참조 규칙을 먼저 확정
2. **insurance_terms 1,192건 → 개념 페이지 시드**: 기존 용어 사전을 LLM compiler로 위키 개념 페이지 자동 생성하여 초기 콘텐츠 확보
3. **기존 insurance_summaries → 엔티티 페이지 전환**: 이미 생성된 3단계 요약을 상품 엔티티 페이지로 구조화

### 8.3 최종 추천

**Option B (Firestore 기반 LLM Wiki)를 Phase 0 → 1 → 2 → 3 순서로 점진 도입**하되, Phase 5에서 Obsidian 연동(Option C)을 추가하여 제이회장님의 로컬 편집 워크플로우도 지원하는 것이 최적이다.

보험 도메인의 정확성 요구사항 때문에 **LLM이 자동으로 위키를 수정하되, diff 리뷰 게이트를 반드시 포함**해야 한다. 카파시의 원본 패턴은 "LLM이 전적으로 소유"하지만, 보험 정보의 법적 리스크를 고려하면 "LLM이 제안하고, 인간(또는 검증 LLM)이 승인"하는 변형이 안전하다.

---

## 부록: 용어 정리

- **LLM Wiki**: Andrej Karpathy가 2026년 4월 공개한 LLM 기반 지식 위키 구축 패턴
- **LLM Compiler**: 원본 소스를 읽고 위키 페이지를 생성/갱신하는 LLM 에이전트
- **Ingest**: 새 소스를 위키에 투입하는 오퍼레이션
- **Lint**: 위키의 건강 상태를 자동 검증/수정하는 자기치유 오퍼레이션
- **Progressive Disclosure**: 정보를 계층별(인덱스 → 요약 → 전문)로 단계 제공하는 패턴
- **Schema**: 위키의 구조, 규칙, 관례를 정의한 문서 (CLAUDE.md와 유사)