Karpathy의 LLM Wiki — RAG 다음의 지식 베이스 패턴

Table of contents

• RAG가 매번 다시 짜는 일
• 세 층 — Raw, Wiki, Schema
• 세 가지 작업 — Ingest, Query, Lint
• index.md와 log.md — 두 개의 특별한 파일
• 분업의 재배치 — 사람이 큐레이션, LLM이 잡일
• Claude Code로 굴리기
• 패턴이 막히는 자리
• 잘 맞는 적용 영역
• 참고 자료

RAG가 매번 다시 짜는 일

2026년 4월, Karpathy가 GitHub gist 한 장을 던졌다. 제목은 LLM Wiki. 문서는 코드도 아니고 라이브러리도 아니다. 지식 베이스를 LLM과 어떻게 같이 굴려야 하는가에 대한 패턴 한 장이다. 며칠 만에 커뮤니티 구현이 수십 개 올라왔고, Obsidian 워크플로우·Claude Code 스킬·로컬 Ollama 버전까지 갈래가 갈렸다.

문제 의식은 단순하다. 지금까지 LLM으로 문서를 다루는 방식은 거의 RAG였다. 파일을 잔뜩 업로드해 두고 질문할 때마다 청크를 검색해 답을 짠다. NotebookLM, ChatGPT 파일 업로드가 다 그런 구조다. 잘 굴러가지만, 매 질문마다 LLM이 지식을 처음부터 다시 짠다. 다섯 문서를 종합해야 답이 나오는 미묘한 질문이면, 같은 다섯 조각을 매번 다시 짜 맞춘다. 누적되는 게 없다.

LLM Wiki는 그 흐름을 뒤집는다. 원본을 받으면 그 자리에서 위키 페이지를 갱신하고, 새 사실이 들어오면 기존 페이지의 모순을 표시하고, 질문에 대한 답도 새 위키 페이지로 다시 정리해서 남긴다. 위키는 사라지지 않는다. 다음 질문은 갈수록 두꺼워진 위키 위에서 동작한다.

flowchart LR
    classDef raw fill:#7f8c8d,color:#fff,stroke:#444
    classDef wiki fill:#5ca45c,color:#fff,stroke:#3d7740
    classDef schema fill:#4a90d9,color:#fff,stroke:#2c5d8f
    classDef llm fill:#d4943a,color:#fff,stroke:#9c6a26

    Raw[Raw<br/>원본 문서 / 불변]:::raw
    Wiki[Wiki<br/>LLM이 갱신하는 마크다운]:::wiki
    Schema[Schema<br/>CLAUDE.md / AGENTS.md]:::schema
    Agent((LLM Agent)):::llm
    User[사용자]

    User -->|소스 투입| Raw
    User -->|질문| Agent
    Raw -->|읽기| Agent
    Schema -->|규약| Agent
    Agent -->|읽기·쓰기| Wiki

Karpathy의 한 문장이 분위기를 잘 잡는다. “Obsidian이 IDE고, LLM이 프로그래머고, 위키가 코드베이스다.” 작성자가 소스를 큐레이션하고 방향을 잡으면, LLM이 정리·교차참조·일관성 유지 같은 지루한 부분을 다 떠맡는다. 사람이 위키 유지를 포기하는 이유였던 잡일이 사라진다.

세 층 — Raw, Wiki, Schema

위키는 세 층으로 갈라져 있다. 각자 책임이 분명히 다르다.

Raw. 원본 문서. 기사, 논문, PDF, 이미지, 채팅 로그, 회의록. 불변이다. LLM은 읽을 뿐 절대 고치지 않는다. 진실의 출처(source of truth) 역할이다.

Wiki. LLM이 직접 작성·유지하는 마크다운 파일들. 요약 페이지, 엔티티 페이지, 개념 페이지, 비교표, 종합 페이지가 다 여기에 들어간다. 사람은 거의 안 쓴다. 새 소스가 들어오면 LLM이 영향받는 페이지를 전부 손본다. 한 소스가 들어오면 10~15개 페이지가 바뀐다.

Schema. Claude Code면 CLAUDE.md, Codex면 AGENTS.md 같은 규약 문서. 위키가 어떤 구조인지, 페이지 포맷은 어떤지, 새 소스가 들어오면 어떤 순서로 처리할지가 적혀 있다. 이게 없으면 LLM은 그냥 챗봇이고, 있으면 규율 있는 위키 사서가 된다. 사람과 LLM이 시간이 지나면서 같이 다듬어 간다.

세 층은 디스크 상에서 보통 이런 모양이 된다.

my-wiki/
├── CLAUDE.md             ← 스키마 (LLM 운영 규약)
├── raw/                  ← 원본 (불변)
│   ├── papers/
│   ├── clippings/
│   └── assets/
├── wiki/                 ← LLM이 갱신
│   ├── index.md
│   ├── log.md
│   ├── entities/
│   ├── concepts/
│   └── synthesis/
└── .git/                 ← 마크다운이면 자연스럽게 버전 관리

쉽게 말해, Raw는 읽기 전용 자료실, Wiki는 LLM이 쓰는 사내 위키, Schema는 위키 운영 매뉴얼이다. 셋의 책임이 섞이면 시스템이 무너진다 — 사람이 위키를 직접 고치기 시작하면 LLM의 합성과 충돌하고, 스키마가 없으면 LLM은 매번 다른 포맷으로 페이지를 짠다.

세 가지 작업 — Ingest, Query, Lint

위키 위에서 LLM이 하는 일은 크게 세 가지뿐이다.

Ingest — 소스 한 편을 위키에 녹여 넣기. 새 자료를 raw/에 떨어뜨리고 “이거 정리해” 한 줄을 던진다. LLM은 자료를 읽고, 핵심을 사용자와 짧게 토론하고, 요약 페이지를 새로 만들고, index.md를 갱신하고, 영향받는 엔티티·개념 페이지를 손보고, log.md에 한 줄을 남긴다. 한 소스가 10~15개 페이지를 건드린다. 한 번에 한 소스씩 진행하는 게 보통이다 — 사용자가 요약을 읽고, 강조점을 잡아주고, 그 과정에서 자기 도메인 감을 같이 키워간다.

Query — 위키에 질문하기. 질문이 들어오면 LLM은 원본이 아니라 위키를 먼저 본다. index.md에서 관련 페이지를 골라 읽고, 인용을 달아 답한다. 답이 길거나 가치가 있으면 새 위키 페이지로 저장한다. “RAG vs LLM Wiki 비교 표”를 물어봤다면 그 답이 comparisons/rag-vs-llm-wiki.md로 남는다. 다음에 같은 질문이 들어오면 그 페이지가 출발점이 된다. 탐색이 곧 자산이 된다.

Lint — 주기적인 건강 검진. 위키가 커지면 모순이 생긴다. 옛 소스가 X는 불가능이라고 했는데 새 소스에서 X 가능이 들어왔다면, 두 페이지가 충돌한 채로 남는다. Lint는 그걸 잡는 작업이다. 모순, 시효 지난 주장, 들어오는 링크가 없는 고아 페이지, 빠진 교차참조, 자주 언급되는데 자기 페이지가 없는 개념을 LLM이 직접 훑어 보고하고 손본다. 카르파티는 대략 20개 페이지가 새로 생길 때마다 한 번씩 돌리는 걸 권장한다.

세 작업 모두 LLM이 지치지 않는다는 점에 기댄다. 사람이라면 15개 페이지를 동시에 손보다가 한두 군데 빠뜨리는데, LLM은 한 패스로 통과한다. 위키가 유지되는 결정적인 이유다.

index.md와 log.md — 두 개의 특별한 파일

위키가 커지면 LLM도 길을 잃는다. 그래서 두 개의 특별한 파일이 지도 역할을 한다.

index.md — 콘텐츠 카탈로그. 모든 위키 페이지를 카테고리별로 묶고, 각 페이지마다 한 줄 요약을 단다.

# Wiki Index

## Entities
- [[karpathy]] — OpenAI 공동창립, Tesla AI 디렉터 출신. LLM Wiki 제안
- [[anthropic]] — Claude 시리즈 제작. Claude Code/MCP 생태

## Concepts
- [[rag]] — Retrieval-Augmented Generation. 질의 시 검색·생성
- [[llm-wiki]] — RAG 대신 LLM이 직접 유지하는 위키 패턴
- [[memex]] — Vannevar Bush (1945) 개인 지식 저장소 비전

## Sources
- [[2026-04-02-karpathy-gist]] — LLM Wiki 원문 gist

Ingest 때마다 갱신된다. 질문이 들어오면 LLM은 index.md를 먼저 읽고 관련 페이지로 점프한다. 임베딩 인프라가 없어도, 페이지가 수백 개 이하일 때는 이 인덱스만으로 검색이 충분히 굴러간다.

log.md — 추가 전용 타임라인. 무슨 작업이 언제 있었는지가 적혀 있다.

## [2026-04-02] ingest | Karpathy LLM Wiki gist
- 신규: concepts/llm-wiki.md, sources/2026-04-02-karpathy-gist.md
- 갱신: entities/karpathy.md, concepts/rag.md

## [2026-04-03] query | "RAG vs LLM Wiki"
- 결과: comparisons/rag-vs-llm-wiki.md 신규

## [2026-04-12] lint
- 모순 1건: concepts/rag.md vs concepts/llm-wiki.md (인덱싱 비용)
- 고아 3건: 정리됨

## [ 같은 일관된 prefix로 시작하면 grep "^## \[" log.md | tail -5 한 줄로 최근 5건이 보인다. 위키의 진화 타임라인이 그대로 깔린다.

분업의 재배치 — 사람이 큐레이션, LLM이 잡일

이 패턴이 잘 굴러가는 이유는 기술적 진보가 아니라 분업의 재배치에 있다. 사람이 위키를 포기하는 이유는 읽고 생각하는 부분이 아니라 교차참조 유지·요약 갱신·일관성 관리 같은 잡일이다. 자료 한 편 추가했다고 관련 페이지 12개를 다 돌면서 갱신하는 사람은 없다. LLM은 그걸 한다.

flowchart LR
    classDef human fill:#d4943a,color:#fff,stroke:#9c6a26
    classDef llm fill:#4a90d9,color:#fff,stroke:#2c5d8f

    H[사람]:::human
    L[LLM]:::llm
    Out[유지되는 위키]

    H -->|소스 큐레이션<br/>질문<br/>방향 잡기| Out
    L -->|요약<br/>교차참조<br/>일관성 유지<br/>linting| Out

사람은 큐레이션·방향·질문을 맡고, LLM은 정리·연결·기록을 맡는다. 둘이 합쳐졌을 때 비로소 위키가 유지되는 단계로 넘어간다. 1945년에 Vannevar Bush가 Memex로 그렸던 개인 지식 저장소가 결국 풀지 못했던 게 누가 연결을 유지할 것인가였는데, 그 자리에 LLM이 들어간다.

또 한 가지 결정적인 이점은 답이 사라지지 않는다는 점이다. 챗으로 받은 답은 다음 세션에서 다시 물어봐야 한다. 위키 페이지로 남은 답은 다음 질문의 출발점이 된다. 탐색이 그대로 자산이 되는 구조다.

Claude Code로 굴리기

이 패턴은 Karpathy도 의도적으로 추상적으로 남겼다. 실제 구현은 도메인과 취향에 맡긴다는 뜻이다. 가장 단순한 굴림은 Claude Code 한 개와 마크다운 폴더 하나로 시작한다.

먼저 CLAUDE.md에 운영 규약을 박아 둔다.

# 이 폴더는 LLM Wiki다.

## 구조
- `raw/`: 원본. 절대 수정하지 않는다. 읽기만 한다
- `wiki/`: 너(LLM)가 작성·유지한다. 사람은 거의 손대지 않는다
- `wiki/index.md`: 모든 페이지의 카탈로그. 매 ingest마다 갱신
- `wiki/log.md`: 모든 작업의 타임라인. append-only

## Ingest 절차
1. raw/에 새 파일이 들어왔다고 사용자가 말하면 그 파일을 읽는다
2. 핵심 takeaway 5개를 사용자와 짧게 의논한다
3. 새 요약 페이지를 wiki/sources/에 만든다
4. 영향받는 entity·concept 페이지를 갱신한다 (없으면 새로 만든다)
5. wiki/index.md에 신규 페이지를 등록한다
6. wiki/log.md에 한 줄 추가: `## [YYYY-MM-DD] ingest | 파일명`

## 페이지 포맷
- 한 페이지 = 한 개념. 두 개념이 섞이면 분리한다
- 다른 페이지를 언급할 때 [[페이지명]] 형태로 링크한다
- 출처는 페이지 하단에 `## Sources` 섹션으로 모은다

이 한 장이 왜 LLM이 챗봇이 아니라 위키 사서로 동작하는가의 핵심이다. 여기에 자기 도메인 규약을 더하면 된다 — 논문이면 인용 양식, 비즈니스면 회의록 처리 규칙, 자기계발이면 일기 분류 같은 것.

작업은 LLM과 위키를 동시에 띄워놓고 한다. Karpathy는 Obsidian을 쓴다. 한쪽엔 LLM 에이전트, 한쪽엔 Obsidian 그래프 뷰. LLM이 페이지를 고치면 그래프가 실시간으로 바뀌고, 사용자는 새 노드와 새 연결을 따라가며 위키가 어떤 모양으로 자라는지 본다.

위키가 100~200 페이지 정도까지는 index.md 하나로 검색이 충분히 굴러간다. 그 이상으로 커지면 qmd 같은 로컬 마크다운 검색기를 붙이거나, MCP 서버 형태로 노출해서 LLM이 도구로 호출하게 만들 수 있다.

패턴이 막히는 자리

LLM Wiki도 마법이 아니다. 몇 가지는 명확하다.

한 페이지 = 한 개념이라는 규율을 잃는 순간 무너진다. 페이지 하나에 두세 개념이 섞이면 링크가 흐려지고 답이 산만해진다. Lint 패스가 자주 필요한 이유다.

근거 추적은 페이지 단위까지다. 문장 단위까지 정확히 어느 소스에서 왔는지 추적되지는 않는다. 법적 인용이 필요한 영역에서는 보강이 필요하다.

한 도메인 안에서 누적될 때 가치가 크다. 무작위로 다양한 주제를 던지면 그래프가 흩어진다. 한 연구 주제를 몇 주에서 몇 달 동안 깊이 파는 형태에 가장 잘 맞는다.

소스를 직접 큐레이션해야 한다. 트위터 피드를 통째로 부어 넣는 게 아니라 읽을 만한 것을 골라서 위키에 넣어야 한다. 그 큐레이션이 결국 사용자 몫이다.

마지막으로, 이 패턴은 문서가 누적되는 작업에서만 의미가 있다. 단발 검색에는 RAG가 더 가볍다. LLM Wiki는 몇 주에서 몇 년에 걸쳐 같은 주제를 파는 사람을 위한 도구다.

잘 맞는 적용 영역

Karpathy의 본문이 직접 권하는 적용처가 몇 가지 있다.

• 연구 주제 추적 — 논문·기사·리포트를 몇 달 동안 누적하며 종합 위키를 키운다
• 책 한 권의 동반 위키 — 챕터를 읽을 때마다 인물·테마·플롯을 페이지로 정리. 끝나면 톨킨 위키 같은 팬 위키가 자기 손에 남는다
• 개인 관리 — 일기·아티클·팟캐스트 노트를 모아 자기 자신에 대한 위키를 짠다
• 팀 내부 위키 — Slack 스레드, 회의록, 고객 미팅을 LLM이 정리. 사람이 검토만 한다
• 경쟁사 분석, 듀딜리전스, 여행 계획, 강의 노트, 취미 디깅 — 무엇이든 시간이 흐르며 누적되는 주제

처음 만들 위키의 크기는 작아도 된다. 소스 다섯 편으로 시작해 보고, 두 달 뒤 페이지 100개에서 어떤 모양인지 보면 감이 잡힌다. 패턴 자체가 모듈러다 — Obsidian 안 쓰고 그냥 VS Code로 마크다운만 봐도 되고, Marp 슬라이드도 안 만들고 텍스트만 누적해도 된다. 의미 있는 한 줄은 결국 이거다.

같은 주제를 두 번 검색했다면, 한 번 더 보기 전에 위키 한 페이지로 정리해 둔다. 다음번엔 그 페이지에서 출발한다.

그 한 줄짜리 습관이, 일 년 뒤엔 천 페이지짜리 자기 도메인 위키가 된다.

참고 자료

• LLM Wiki — Karpathy의 원문 gist (2026-04)
• LLM Wiki by Andrej Karpathy: Build a Compounding Knowledge Base — Data Science Dojo
• What Is Karpathy’s LLM Wiki? How to Build a Personal Knowledge Base With Claude Code — MindStudio
• Step-by-Step Guide: Build Your Own AI Second Brain with Obsidian and Karpathy’s LLM Wiki — TheToolNerd
• qmd — 로컬 마크다운 검색기 (MCP 서버 지원)