LLM에 논문이나 회의록을 넣고 질문하면, LLM은 질문할 때마다 원문을 처음부터 다시 읽습니다. 같은 자료를 여러 번 넣어도 정리된 지식은 어디에도 쌓이지 않습니다. RAG를 써도 마찬가지입니다.
Andrej Karpathy가 공유한 gist “LLM-Wiki” ↗는 LLM이 원문을 읽고 마크다운 위키를 직접 쓰고 고치게 하자는 아이디어 문서입니다. 사용자와 원문(raw source) 사이에 LLM이 관리하는 위키를 한 겹 둡니다. 한국어 커뮤니티에는 GeekNews 번역 토픽 ↗으로 알려졌습니다.
이 글은 gist 원문과 GeekNews 댓글을 바탕으로 LLM-Wiki의 구조, 작업 흐름, 적용 사례와 한계를 정리합니다.
2026-04-17에 확인한 공식 gist karpathy/442a6bf555914893e9891c11519de94f 기준입니다. LLM-Wiki는 아이디어 문서이며, 공식 구현체나 제품은 없습니다.
배경: 왜 RAG만으로는 부족한가
Karpathy는 대부분의 “LLM + 문서” 경험이 RAG 방식이라고 봅니다. 파일을 올리면 질문할 때 관련 청크를 검색해 답을 만듭니다. Karpathy는 이 방식이 동작은 하지만, 질문마다 지식을 처음부터 다시 찾는다고 지적합니다.
“Most people’s experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question.”
LLM-Wiki는 원문을 매번 다시 읽는 대신, 계속 커지는 결과물(persistent, compounding artifact)을 두자고 제안합니다.
“Instead of just retrieving from raw documents at query time, the LLM incrementally builds and maintains a persistent wiki — a structured, interlinked collection of markdown files that sits between you and the raw sources.”
— 동일 gist
위키는 사용자가 아니라 LLM이 씁니다.
“You never (or rarely) write the wiki yourself — the LLM writes and maintains all of it.”
세션 사이에 컨텍스트를 유지하는 방법은 Claude Code Memory에서 다뤘습니다. LLM-Wiki는 이 방식을 개인 위키 규모로 넓힌 것에 가깝습니다.
LLM-Wiki의 3계층 구조
구조는 세 층입니다.
- Raw sources — 기사·논문·이미지·데이터 파일 같은 불변(immutable) 원문
- The wiki — LLM이 직접 생성·갱신하는 마크다운 파일 집합(요약·엔티티 페이지·개념 페이지)
- The schema —
CLAUDE.md/AGENTS.md같은 구성 문서. 위키의 구조와 워크플로우를 정의
위키 계층에는 역할이 정해진 파일 두 개가 더 있습니다.
index.md— 카테고리별로 정리된 “콘텐츠 지향 카탈로그”log.md— 모든 Ingest·Query·Lint 실행을 추가만(append-only) 기록하는 로그
flowchart TD
subgraph Raw [Raw sources]
R1[논문/기사]
R2[노트/메시지]
R3[데이터/이미지]
end
subgraph Wiki [The wiki — LLM이 작성·유지]
S[요약 페이지]
E[엔티티 페이지]
C[개념 페이지]
IDX[index.md]
LOG[log.md]
end
subgraph Schema [The schema]
CFG[CLAUDE.md / AGENTS.md]
end
Raw -->|Ingest| Wiki
CFG -. 구조·규칙 .-> Wiki
User((사용자)) -->|Query| Wiki
Wiki -->|Lint| Wikigist는 폴더 구조를 정하지 않습니다. 아래는 배치 예시입니다.
my-wiki/
├─ CLAUDE.md # 스키마: 구조와 워크플로우 규칙
├─ index.md # 카테고리별 카탈로그 (진입점)
├─ log.md # Ingest/Query/Lint append-only 로그
├─ raw/ # 불변 원문 (건드리지 않음)
│ ├─ papers/
│ └─ notes/
└─ wiki/ # LLM이 쓰고 유지하는 마크다운
├─ entities/
├─ concepts/
└─ summaries/raw 계층은 LLM이 수정하지 않는 원문이고, wiki 계층은 LLM이 쓰고 고치는 작업 공간입니다. 스키마는 위키를 어떻게 유지할지 정한 규칙 문서입니다.
위키 페이지는 아래처럼 서로 링크된 마크다운 문서입니다.
// illustrative: gist의 서술을 토대로 재구성한 위키 페이지 예시 (원문 발췌 아님)
# Transformer
A neural network architecture introduced by ...
## Related
- [[Attention]]
- [[Self-Attention]]
- [[GPT]]세 가지 동사: Ingest / Query / Lint
작업 흐름은 세 동사로 정리됩니다. 각 동사는 LLM이 위키를 다루는 규칙이자, 사용자가 LLM에 내리는 요청입니다.
flowchart TD
A[Raw source 도착] -->|Ingest| B[요약/엔티티/개념 페이지 갱신]
B -->|index 업데이트| C[index.md]
U((사용자 질문)) -->|Query| W[위키 검색·종합]
W --> U
B -->|주기적| L[Lint: 건강 점검]
L -->|모순·고아 페이지 탐지| BIngest — 원문을 흡수해 위키로 번역
원문이 들어오면 LLM이 읽고 사용자와 요점을 정리합니다. 그다음 요약 페이지를 쓰고, 관련 엔티티·개념 페이지와 index.md를 함께 고칩니다.
“the LLM reads the source, discusses key takeaways with you, writes a summary page in the wiki, updates the index, updates relevant entity and concept pages”
gist에 따르면 원문 하나가 들어올 때 위키 페이지 10~15개를 함께 고치는 일도 흔합니다. Ingest는 요약을 저장하는 데서 끝나지 않고, 원문 내용을 기존 페이지 구조에 끼워 넣습니다. 웹 페이지를 원문으로 쓸 때는 Defuddle로 본문만 마크다운으로 뽑아 raw 계층에 넣을 수 있습니다.
Query — 위키를 상대로 묻는다
질의 시점에도 LLM은 원문을 직접 뒤지지 않습니다. 위키에서 관련 페이지를 찾고, 읽고, 답을 종합합니다.
“ask questions against the wiki. The LLM searches for relevant pages, reads them, and synthesizes an answer.”
— 동일 gist
Query는 이미 정리해 둔 위키를 읽으므로, RAG처럼 질문마다 원문을 다시 찾지 않습니다.
Lint — 위키의 건강 검사
위키는 시간이 지나면 내용이 엉킵니다. 그래서 LLM-Wiki는 주기적으로 린트를 실행합니다.
“periodically, ask the LLM to health-check the wiki. Look for: contradictions between pages, stale claims, orphan pages.”
— 동일 gist
LLM이 페이지 간 모순, 낡은 주장, 어디에서도 링크되지 않는 고아 페이지를 찾습니다. GeekNews 요약에 따르면 소스 약 100개, 페이지 수백 개 규모까지는 임베딩 없이 동작합니다. 한 사례에서 나온 참고 수치입니다.
gist가 언급한 도구는 Obsidian, BM25·벡터 하이브리드 검색 도구 qmd, 슬라이드 도구 Marp, 쿼리 언어 Dataview, Obsidian Web Clipper입니다. 모두 선택 사항입니다.
실전 사례: Farzapedia, @stadia, @kurthong
GeekNews 토픽 ↗에는 gist를 보고 직접 위키를 만든 한국어 사용자들의 기록이 있습니다. 세 사례를 옮깁니다.
Farzapedia — 개인 일기·메시지 2,500건에서 400페이지 위키로
@xguru가 공유한 Farzapedia는 개인 일기, Apple Notes, iMessage 2,500건을 넣어 위키 문서 400개를 자동으로 만든 사례입니다. 문서끼리 백링크로 연결되고, Claude Code가 index.md에서 시작해 파일 시스템을 직접 탐색합니다.
RAG와 비교한 평가도 있습니다.
“1년 전 RAG 기반으로 유사 시스템을 구축했으나 성능이 좋지 않았고, 에이전트가 파일 시스템을 통해 직접 탐색하는 방식이 훨씬 효과적”
새 항목이 들어오면 관련 문서 23개도 자동으로 함께 고칩니다. gist가 말한 “원문 하나에 페이지 1015개 갱신”을 작은 규모로 한 셈입니다.
@stadia — Obsidian 볼트를 0에서 시작
@stadia는 빈 Obsidian 볼트와 gist 한 장으로 시작했습니다.
“별거 없던 기본 볼트 초기화 하고 저 파일 하나 읽게 하고서 이 아이디어를 구체화 하고 싶다고 이야기 하니 superpowers 의 브레인스톰 스킬과 함께 전체 틀을 잡고서 CLAUDE.md 와 옵시디언 플러그인 설정까지 완료했습니다.”
처음에 준비한 것은 gist 한 장, 브레인스토밍 스킬, CLAUDE.md 한 개였습니다.
@kurthong — 한국어 검색의 가드레일
@kurthong은 Obsidian 볼트를 GitHub에 백업하고, Codex·Gemini용 파서를 따로 두었습니다. 한국어 검색 문제도 지적했습니다.
“bm25가 한글 검색에 약해서 한국어도 잘 검색할 수 있는 가드레일 적용”
세 사례 모두 원문은 그대로 두고 wiki 계층만 LLM이 고친다는 기본 원칙을 지켰습니다. 달라진 것은 도구와 백업 방식입니다.
한계와 비판
LLM-Wiki에는 비판도 많습니다. Hacker News와 GeekNews 토픽에서 나온 우려는 다음과 같습니다.
- “모델 붕괴(model collapse)로 이어질 것 같음” — LLM이 자기 글을 다시 학습하듯 재작성하는 구조에 대한 염려
- “LLM이 문서를 작성할수록 기존의 정확한 정보를 덜 간결하게 재작성” — Ingest/Lint를 반복할수록 원문의 정밀함이 마모될 수 있다는 지적
- “LLM은
claude.md하나도 제대로 유지하지 못함. 위키 전체는 더 불가능함” — 스키마 문서 한 장도 흔들리는데 수백 페이지의 자기 정합성을 유지할 수 있겠느냐는 반문 - “2차 오류 누적, 새로운 형태의 기술 부채” — 위키 자체가 새 부채의 원천이 된다는 관점
- “일정 복잡도 넘으면 에이전트도 개발자도 위키 전체를 유지·이해 못함” — 스케일이 임계점을 넘을 때의 위험
같은 결의 코멘트로, @sudoeng은 이렇게 정리합니다.
“ai가 점점 쌓여가는 위키 컨텍스트를 감당할 수 있을지 아직 잘 모르겠네요”
이 우려에는 공통점이 있습니다. Ingest나 Lint가 잘못되면 오류가 쌓입니다. 도입한다면 처음부터 log.md처럼 추가만 하는 기록을 남겨, 사람이 변경 내역을 검토(audit)할 수 있게 합니다.
마무리
LLM-Wiki는 사용자와 원문 사이에 LLM이 만들고 유지하는 위키를 한 겹 두자는 제안입니다. 규약은 3계층(raw / wiki / schema)과 세 동사(Ingest / Query / Lint)가 전부이고, 도구는 각자 고릅니다. 규약이 얇아 시작하기 쉽지만, 위키 품질을 지키는 장치도 사용자가 직접 만들어야 합니다.
관련 글
- Claude Code Memory — 세션 사이에 컨텍스트를 유지하는 방법
- Defuddle 살펴보기 — 웹 본문을 마크다운으로 정제해 raw 계층에 넣기
- Superpowers 살펴보기 — 파일 기반 스킬로 에이전트 작업 절차를 묶는 방법
- Perplexity Computer vs OpenClaw — 매니지드 멀티모델 에이전트와 지식·자동화 워크플로
원문과 전체 맥락은 Karpathy의 LLM-Wiki gist ↗와 GeekNews 토픽 ↗에서 확인할 수 있습니다.