같은 논문, 같은 API 레퍼런스, 같은 회의록을 LLM에 반복해서 붙여 넣은 경험이 있으신가요? 질문할 때마다 LLM은 아무것도 모르는 상태에서 원문을 다시 훑습니다. 정보를 여러 번 투입해도 어디에도 쌓이지 않는다는 감각은, RAG를 써 본 분이라면 익숙할 겁니다.
Andrej Karpathy가 공유한 gist “LLM-Wiki” ↗는 이 문제를 다른 각도에서 봅니다. 매번 원문에서 조각을 꺼내 오는 대신, LLM이 직접 마크다운 위키를 쓰고 유지하도록 하자는 아이디어 가이드입니다. 사용자와 raw source 사이에 “LLM이 관리하는 점진적 지식 베이스”를 한 겹 두는 것이죠. GeekNews 번역 토픽(news.hada.io/topic?id=28208 ↗)을 통해 한국어 커뮤니티에서도 빠르게 공유됐습니다.
이 글은 gist 원문과 GeekNews 토픽의 댓글 흐름을 근거로, LLM-Wiki가 제안하는 구조와 워크플로우, 그리고 실제 적용 사례·한계를 정리합니다.
2026-04-17 · 공식 gist karpathy/442a6bf555914893e9891c11519de94f 스냅숏 기준. 이 글은 아이디어 가이드를 소개하며, 구현체·제품이 아닙니다.
배경: 왜 RAG만으로는 부족한가
Karpathy는 오늘날 대부분의 “LLM + 문서” 경험이 RAG 방식이라고 말합니다. 파일을 업로드하고, 질의 시점에 관련 청크를 검색해 답을 생성합니다. 이 방식이 잘 동작할 때도 많지만, 그는 다음과 같이 지적합니다.
“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
그리고 한 번 더 강조하는 문장이 핵심 질감을 보여줍니다.
“You never (or rarely) write the wiki yourself — the LLM writes and maintains all of it.”
이 아이디어의 결은 개인·에이전트가 파일 기반으로 지식을 축적해 가는 다른 흐름과 맞닿아 있습니다. 예컨대 세션 간 컨텍스트를 유지하는 방식은 Claude Code Memory 포스트에서 다뤘는데요, LLM-Wiki는 그 아이디어의 “개인 위키” 버전에 가깝습니다. 에이전트가 파일 기반 규율·지식을 쌓는 넓은 패턴 쪽으로는 Superpowers 에이전틱 스킬 프레임워크가 같은 결의 공명을 보여줍니다.
LLM-Wiki의 3계층 구조
Karpathy가 제시하는 구조는 깔끔하게 세 층으로 나뉩니다.
- 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-Wiki의 워크플로우는 세 개의 동사로 요약됩니다. 각 동사는 LLM이 위키를 어떻게 다룰지에 대한 규칙이면서, 동시에 사용자가 LLM에 내리는 요청의 형태이기도 합니다.
flowchart LR
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는 하나의 raw source가 들어올 때 위키 페이지 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
“이미 한 번 번역해 둔 지도”를 다시 읽는다는 점에서, 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 토픽 news.hada.io/topic?id=28208 ↗에는 Karpathy의 gist에 자극을 받아 직접 위키를 구축한 한국어 독자들의 기록이 올라와 있습니다. 몇 가지를 그대로 옮겨 보겠습니다.
Farzapedia — 개인 일기·메시지 2,500건에서 400페이지 위키로
@xguru가 공유한 Farzapedia 사례는, 개인 일기·Apple Notes·iMessage 2,500건을 입력해 자동으로 400개의 위키 문서가 생성된 경험을 보여줍니다. 문서들은 백링크로 서로 연결돼 있고, Claude Code가 파일 시스템을 직접 탐색하며, index.md가 진입점 역할을 맡습니다.
특히 인상적인 코멘트는 RAG와의 직접 비교입니다.
“1년 전 RAG 기반으로 유사 시스템을 구축했으나 성능이 좋지 않았고, 에이전트가 파일 시스템을 통해 직접 탐색하는 방식이 훨씬 효과적”
또한 새 항목이 들어올 때마다 시스템이 관련된 기존 문서 23개를 자동으로 함께 업데이트한다고 합니다. 이는 gist가 말한 “단일 source → 1015개 위키 페이지 동시 갱신”의 축소판이라고 해석할 수 있는 대목입니다.
@stadia — Obsidian 볼트를 0에서 시작
@stadia의 후기는 “빈 Obsidian 볼트 + gist 한 장”으로 시작한 흐름을 보여줍니다.
“별거 없던 기본 볼트 초기화 하고 저 파일 하나 읽게 하고서 이 아이디어를 구체화 하고 싶다고 이야기 하니 superpowers 의 브레인스톰 스킬과 함께 전체 틀을 잡고서 CLAUDE.md 와 옵시디언 플러그인 설정까지 완료했습니다.”
gist 한 장과 브레인스토밍 스킬, 그리고 CLAUDE.md 한 개가 초기 비용의 전부였다는 점이 눈에 띕니다.
@kurthong — 한국어 검색의 가드레일
@kurthong은 Obsidian 볼트를 GitHub에 백업하고, 코덱스·제미나이용 파서를 따로 두는 구성을 공유했습니다. 특히 한국어 환경에서 반복적으로 발견되는 지점을 이렇게 지적합니다.
“bm25가 한글 검색에 약해서 한국어도 잘 검색할 수 있는 가드레일 적용”
세 사례 모두 공통적으로, 원문은 건드리지 않고 wiki 계층만 LLM이 갱신한다는 LLM-Wiki의 기본 원칙을 지키면서 도구와 백업 전략만 각자에게 맞게 조정한 모습입니다.
한계와 비판
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이 매번 원문을 처음부터 다시 읽는” 구도를 “LLM이 만들고 유지하는 지도”를 한 겹 끼우는 구도로 바꿔 보자는 제안입니다. 3계층(raw / wiki / schema)과 세 동사(Ingest / Query / Lint)가 전부이고, 나머지는 각자의 도구와 취향으로 붙이는 얇은 규약이라는 점이 이 아이디어의 매력이자 위험입니다.
비교와 연결이 될 만한 다른 포스트도 함께 권합니다. 세션 간 컨텍스트를 유지하는 저수준 메커니즘은 Claude Code Memory에서 다뤘고(LLM-Wiki는 그 아이디어의 개인 위키 버전에 가깝습니다), raw source를 깨끗한 마크다운으로 정리하는 전처리는 Defuddle 포스트가 구체적인 파이프라인을 보여줍니다. 파일 기반으로 에이전트가 규율과 지식을 쌓는 더 넓은 패턴은 Superpowers 에이전틱 스킬 프레임워크 쪽과 공명합니다.
원문과 전체 맥락은 Karpathy의 LLM-Wiki gist ↗와 GeekNews 토픽 ↗에서 확인할 수 있습니다.