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

## 작업 개요
Andrej Karpathy가 2026년 4월 공개한 "LLM Wiki" 패턴을 InsuWiki에 어떻게 적용할 수 있는지 심층적이고 체계적으로 분석한다.

## 카파시 LLM Wiki 핵심 개념

**슬로건**: "knowledge that accumulates, not re-derives"
— 매번 RAG로 재추론하지 않고, 지식을 한번 컴파일해서 누적·유지하는 패턴

**아키텍처 (3 레이어)**:
```
raw/ (원본 소스)           → ingest →   LLM compiler      → compile →  wiki/ (산출물)
 papers                              reads sources                    index.md
 repos                               writes articles                  log.md
 articles                            builds backlinks                 concepts/
 datasets                            lints for gaps                   sources/
 images                                                               schema
                                     ↑ linting — wiki heals itself ↗
```

**핵심 특징**:
- No vector DB, No RAG — 마크다운 파일 기반
- ~100 articles, ~400K words — 중간 규모에 최적
- Obsidian + LLM agent — 시각화 + 자동 유지보수
- Self-healing: lint로 모순/누락/고아 페이지 자동 감지·수정

**3대 오퍼레이션**:
1. **Ingest**: 소스 투입 → LLM이 읽고 → 관련 위키 페이지 10-15개 자동 업데이트 + 교차 참조
2. **Query**: 질문 → 위키에서 검색 → 답변 합성 + 인용 → 좋은 답변은 다시 위키에 저장
3. **Lint**: 주기적 건강 검진 — 모순, 오래된 정보, 고아 페이지, 누락된 교차 참조, 데이터 갭 탐지

**필수 파일**:
- `index.md` — 카테고리별 모든 페이지 목록 + 요약
- `log.md` — append-only 연대기 (`## [YYYY-MM-DD] ingest | Title`)
- `concepts/` — 개념 페이지
- `sources/` — 원본 소스 참조
- `schema` — 위키 구조/컨벤션 정의 (CLAUDE.md와 유사)

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

**원문 gist**: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

## 분석 요구사항

### 1. InsuWiki 현재 상태 파악
- InsuWiki 프로젝트 구조, 기술 스택 확인
- 현재 콘텐츠 관리 방식 분석
- 콘텐츠 규모 (기사 수, 카테고리, 교차 참조 현황)
- InsuWiki 프로젝트 경로: `/home/jay/projects/InsuWiki/`

### 2. LLM Wiki 패턴 적용 가능성 분석
- **Ingest 파이프라인**: 보험 관련 소스(법규, 약관, 뉴스, 업계 동향)를 자동으로 위키에 반영하는 구조
- **자동 교차 참조**: 보험 용어/개념 간 자동 링크 생성 (예: "1200% 룰" → 관련 약관, 영향 분석, 연혁 페이지 자동 연결)
- **Self-healing lint**: 보험 정보의 최신성 검증 (법규 변경 시 관련 페이지 자동 플래그)
- **Query → Wiki 피드백 루프**: 사용자 질문 중 좋은 답변을 자동으로 위키 콘텐츠화

### 3. 기술적 적용 방안
- InsuWiki의 기존 스택(Next.js + Firebase)과 LLM Wiki 패턴의 통합 방법
- 마크다운 기반 vs DB 기반 하이브리드 접근
- LLM compiler 역할을 할 모듈 설계 (ingest/query/lint)
- schema 정의 (보험 도메인 특화 구조)

### 4. 도메인 특화 분석 (보험)
- 보험 지식의 특수성: 약관 해석, 법규 변경, 상품 비교, 수수료 구조
- 소스 유형 분류: 법규(금융위), 약관(보험사), 뉴스(업계), 교육자료, 실무 노하우
- 정확성 요구 수준: 금소법 등 법적 리스크
- 업데이트 빈도: 월별 상품 변경, 분기별 법규 변경, 연 1-2회 대규모 제도 변경

### 5. 구현 로드맵 제안
- Phase별 도입 계획 (MVP → 확장)
- 기술적 선택지 비교 (Obsidian 방식 vs Next.js 통합 방식 vs 하이브리드)
- 비용/효과 분석
- 리스크 및 한계점

### 6. 우리 메모리 시스템과의 연결
- Phase 1~3 메모리 강화 (diary/FTS5/Progressive Disclosure)와의 시너지
- 아누 시스템의 knowledge base로서의 InsuWiki 활용 가능성

## 산출물
- `/home/jay/workspace/memory/research/karpathy-llm-wiki-insuwiki-analysis.md` — 심층 분석 보고서
- 보고서 내 실행 가능한 구현 로드맵 포함

## 참고 자료
- LLM Wiki gist: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
- InsuWiki 프로젝트: `/home/jay/projects/InsuWiki/`
- InsuWiki 프로젝트 컨텍스트: `/home/jay/workspace/memory/projects/insuwiki/`