Chapter 10: LLM Wiki의 등장 — Karpathy의 Obsidian + Claude Code 워크플로우
10.1 16백만 뷰짜리 gist
2026년 4월 4일, Andrej Karpathy가 gist 하나를 공개했다 [4]. 제목: "LLM Wiki." 내용은 제품 발표가 아니라 패턴 설명이었다. raw source를 그대로 두고, LLM이 그 자료를 읽어 마크다운 wiki를 만들고, 그 wiki를 다시 질문·정리·보강의 기준으로 삼게 한다. 이것을 소개하는 포스트는 16M+ 뷰를 기록했고 [4], gist 자체도 2026년 5월 초 기준 19k+ stars와 4k+ forks를 넘었다 [4].
S8의 더 긴 분석이 잘 짚듯이, 이 gist의 핵심은 "새 앱"이 아니라 idea file이었다 [16]. Claude Code, Codex, OpenCode, Pi 중 무엇을 쓰든 읽을 수 있는 마크다운 규약을 배포한 것이다. 그래서 이 장은 LLM Wiki를 노트 앱 기능으로 보지 않는다. Claude Code에서 Codex로 넘어갈 때 손실되기 쉬운 지식을 어떤 파일 표면에 남길 것인가에 대한 답으로 본다.
왜 그렇게 폭발적 반응이었는가? 패턴이 단순하면서 강력했기 때문이다. 기존 RAG나 파일 업로드 방식은 질문할 때마다 raw document에서 관련 조각을 다시 찾는다. LLM Wiki는 반대로 한 번 읽은 자료를 구조화된 wiki로 "컴파일"한다. 그래서 다음 질문은 raw document 더미가 아니라 이미 축적된 entity page, concept page, comparison page 위에서 시작한다. 핵심 변화는 이것이다. 일회성 채팅 도구가 복리로 쌓이는 개인 지식 엔진으로 바뀐다 [13].
10.2 세 레이어
Karpathy의 LLM Wiki는 세 레이어로 구성된다 [4]:
L1: Raw Sources — 불변 원본
vault/
└── raw/
├── papers/ # PDF, arXiv, 논문
├── articles/ # 블로그, 뉴스
├── notes/ # 회의 메모, 아이디어
└── bookmarks/ # 북마크, 스크랩
LLM은 이 레이어를 읽기만 한다. 쓰지 않는다. 원본 불변성이 보장된다.
L2: Wiki — LLM이 소유하는 마크다운
vault/
└── wiki/
├── entities/ # 사람, 프로젝트, 회사
├── concepts/ # 기술 개념, 용어
├── summaries/ # 논문·글 요약
└── comparisons/ # 비교·대조 페이지
LLM이 L1을 읽고 이 레이어를 작성하고 업데이트한다. 엔티티 페이지, 개념 페이지, 비교 페이지 등.
L3: Schema — CLAUDE.md 또는 AGENTS.md
LLM에게 이 vault 구조를 설명하는 파일. "wiki/entities/에 사람 페이지가 있다", "wiki/concepts/에 기술 용어 페이지가 있다" 등을 알려준다.
세 가지 기본 연산:
- ingest: raw source를 추가하고 wiki 페이지를 생성/업데이트
- query: 질문에 답하기 위해 wiki를 탐색
- lint: wiki 내 깨진 링크, 중복, 불일치 정리
최근 구현 가이드들이 공통으로 강조하는 실전 규칙은 하나 더 있다. L2 wiki는 LLM이 소유하되, 변경 기록은 git으로 남겨야 한다 [8]. wiki가 자동으로 커질수록 hallucination, 중복 page, 잘못된 merge가 발생할 수 있다. 그래서 LLM Wiki의 최소 운영 단위는 raw/, wiki/, CLAUDE.md만이 아니라 git diff, lint, review까지 포함한 작은 편집 루프다.
연구용으로 확장하면 최소 운영 파일이 몇 개 더 필요하다. index.md는 전체 vault의 지도, log.md는 ingest/query/lint 실행 기록, schema.md는 claim page의 필수 필드를 정의한다 [16]. 처음부터 복잡한 지식그래프를 만들 필요는 없지만, claim에는 적어도 source, confidence, scope, evidence, open_question, updated_at, status 같은 필드를 요구해야 한다. 이것이 Codex가 batch ingest를 돌린 뒤에도 사람이 diff에서 판단할 수 있는 최소 단위다.
10.3 패턴이 커뮤니티를 흡수하다
Karpathy의 gist 공개 이후 커뮤니티 반응이 빠르게 형성됐다. 2026년 4월 중순 이후 글들은 이 패턴을 세 갈래로 해석한다:
- [8]:
raw/,wiki/,CLAUDE.md의 3-layer setup을 따라 하는 단계별 가이드 - [13]:
llm-wiki를 "reference implementation"으로 보고, Markdown·git·cross-link가 vendor lock-in을 줄인다고 해석 - [14]: RAG 회사 관점에서 LLM Wiki를 "compiled knowledge artifact"로 해석하고, query-time retrieval과의 비용·품질 trade-off를 비교
- [15]: 논문 5편으로 30분 안에 첫 wiki를 만드는 튜토리얼
- AIMaker[7]와 Paige[6]: Obsidian second brain + Claude Code를 개인 생산성 워크플로우로 확장
Nate Herk의 영상 "Karpathy 10x'ed Claude Code" [10]의 프레이밍이 이 확산을 가장 잘 설명한다: "LLM Wiki is a 10x tool — it converts a one-shot chat tool into a compounding personal knowledge engine." (YouTube ID: 20d5cSkSvcU, 2026-04-05 Nate Herk 업로드; fact-checker가 원본 업로드임을 확인)
10.4 반론: 지식 그래프가 필요하다
커뮤니티가 LLM Wiki를 채택하면서 한계도 드러났다. infranodusllmwiki2026의 비판:
"Karpathy의 LLM Wiki는 flat-file 구조다. 엔티티 간 관계를 표현하지 못한다. 'A는 B를 cited했다', 'C는 D의 후속이다' 같은 관계적 지식은 마크다운 파일로 표현하기 어렵다. Knowledge graph 레이어가 필요하다."
이 비판은 타당하다. 다만 Karpathy의 패턴이 "완벽한 지식 관리 시스템"이 아니라 LLM과 함께 작동하는 좋은 시작점이라는 맥락에서 이해해야 한다. 최근 구현 글들도 같은 결론으로 수렴한다. 개인·팀 규모에서는 Markdown + wikilink + git이 가장 낮은 마찰의 기본값이다. 하지만 citation graph, 실험 lineage, 기업 지식의 권한 경계처럼 관계가 핵심인 use case라면 graph database나 hybrid search를 별도 레이어로 붙여야 한다 [11].
다른 반론도 있다. "그냥 RAG with extra steps 아닌가?"라는 비판은 절반만 맞다. RAG는 대개 query-time retrieval이고, LLM Wiki는 ingest/maintenance-time synthesis다 [16]. "컨텍스트 창이 커지면 필요 없어지는가?"라는 비판도 절반만 맞다. 컨텍스트가 커져도 어떤 주장을 신뢰할지, 어떤 충돌이 남았는지, 어떤 실패 가설을 폐기했는지는 여전히 파일로 남아야 한다. 마지막으로 Zettelkasten 관점에서는 링크를 LLM이 자동으로 만들면 생각의 일부를 잃는다는 반론이 있다. 그래서 LLM Wiki의 안전한 운영 원칙은 "LLM이 링크를 제안하고, 사람이 중요한 링크를 승인한다"에 가깝다.
10.5 "Farzapedia" — 개인화의 극단
Karpathy가 소개한 개념 [4]: "당신만의 위키피디아". 당신의 관심사, 당신이 읽은 논문, 당신이 참여한 프로젝트 — 모두 당신 관점에서 정의된 위키. 전 세계가 같은 위키피디아를 쓰는 것과 달리, 각자가 자기 맥락에서 최적화된 지식 베이스를 갖는다.
이것이 11장의 주제다: 이 패턴을 자신의 활동과 연결한다.
10.6 Claude Code vs Codex: 어느 것으로 LLM Wiki를 운영하는가
Karpathy의 원래 구현은 Claude Code + Obsidian 조합이었다. Codex로도 똑같이 작동한다:
Claude Code 방식: CLAUDE.md에 vault 구조를 설명하고, claude로 대화하면서 wiki를 업데이트한다. 더 대화형이고 빠른 실험에 적합하다.
Codex 방식: AGENTS.md에 vault 구조를 설명하고, codex exec "ingest this paper" 형식으로 태스크를 실행한다. 더 자율적이고 배치 처리에 적합하다.
두 방식 모두 동일한 세 레이어 구조를 사용한다. 선택은 작업 스타일의 문제다. 다만 2026년 4월 이후 가이드들을 보면, LLM Wiki는 특정 도구에 묶인 제품보다 에이전트가 읽고 수정할 수 있는 파일 규약에 가깝다 [4]. 그래서 Claude Code, Codex, OpenCode/Pi, 로컬 모델 중 무엇을 쓰든 핵심은 같다. raw는 불변, wiki는 편집 가능, schema는 명령 체계, 변경은 diff로 검토한다.
S8의 표현을 빌리면, 파일 규약은 portable하지만 agent loop는 그렇지 않다 [16]. raw/, wiki/, index.md, log.md, schema.md는 Claude Code와 Codex가 모두 읽을 수 있다. 하지만 Claude Code의 hooks, subagents, memory store와 Codex의 permissions, rules, goal mode, Worktree는 서로 그대로 이동하지 않는다. 따라서 LLM Wiki를 이관 가능한 형태로 운영하려면 데이터는 마크다운과 git에, 실행 루프는 각 도구의 하네스에 둬야 한다.
참고문헌
- Karpathy, Andrej, "LLM Wiki," gist, 2026. [Karpathy, 2026]
- Karpathy, Andrej, "LLM Wiki tweet," Twitter, 2026. [Karpathy, 2026]
- Karpathy, Andrej, "LLM Wiki talk / post," 2026. [Karpathy, 2026]
- Karpathy, Andrej, "Farzapedia — personalization argument," 2026. [Karpathy, 2026]
- Joshi, "How I built my personal LLM Wiki," Medium, 2026. [Joshi, 2026]
- Paige, "Second brain setup," 2026. [Paige, 2026]
- Aimaker, "AI-powered second brain from LLM Wiki," 2026. [Maker, 2026]
- Starmorph, "LLM Wiki step-by-step guide," 2026. [Starmorph, 2026]
- Mindstudio, "Karpathy Wiki implementation," 2026. [MindStudio, 2026]
- Herk, Nate, "Karpathy 10x'ed Claude Code," YouTube (ID: 20d5cSkSvcU), 2026-04-05. [Herk, 2026]
- Infranodus, "LLM Wiki needs a knowledge graph," 2026. [infranodusllmwiki2026]
- LLM Wiki Full Setup, "Canonical demo," 2026. [llmwikifullsetup2026]
- Cognition, "llm-wiki: the reference implementation of Karpathy's self-building AI memory pattern," 2026-04-16. [Cognition, 2026]
- Denser.ai, "From RAG to LLM Wiki: What Karpathy's Idea Means for AI Knowledge Bases," 2026-04-16. [Denser, 2026]
- Data Science Dojo, "The LLM Wiki Pattern by Andrej Karpathy," 2026-04-16. [Data Science Dojo, 2026]
- Um, T. (terryum), "LLM Wiki에서 AI Scientist까지," survey #S8, 2026. [Um, 2026]