2026년 4월, Andrej Karpathy가 GitHub Gist에 올린 한 장의 문서가 개인 지식 관리(PKM) 커뮤니티를 뒤흔들었다. “나는 요즘 코드보다 개인 지식 저장소 구축에 토큰을 더 많이 쓴다”는 한 마디와 함께.
나는 이 가이드를 읽은 직후 Obsidian 볼트를 초기화하고, 3주간 실제로 운영해봤다. 이 글은 그 과정에서 얻은 실전 경험을 정리한 것이다.
1. PKM은 왜 실패하는가
Evernote → Notion → Roam Research → Obsidian. 도구는 바뀌어도 결말은 같다. 3개월 안에 포기.
근본 원인은 단순하다:
입력 마찰 > 검색 가치 = 시스템 사망
노트를 정리하고, 태그를 달고, 링크를 연결하는 “북키핑” 비용이 나중에 검색해서 얻는 가치보다 빠르게 증가한다. 위키가 커질수록 유지보수 부담이 기하급수적으로 늘어나고, 결국 포기한다.
Karpathy의 통찰은 이 공식을 뒤집는 것이다: LLM이 북키핑을 담당하면 유지보수 비용이 거의 0에 수렴한다.
2. LLM Wiki vs RAG: 근본적 차이
대부분의 LLM 문서 활용은 RAG(Retrieval-Augmented Generation) 방식이다. NotebookLM, ChatGPT 파일 업로드 등. 매번 원문에서 정보를 재추출하며, 지식의 누적이 없다.
LLM Wiki는 다르다:
| 항목 | RAG | LLM Wiki |
|---|---|---|
| 지식 저장 | 원문 청크 | 구조화된 위키 페이지 |
| 업데이트 | 없음 (매번 재검색) | 점진적 축적 |
| 교차 참조 | 없음 | 자동 생성·유지 |
| 모순 감지 | 불가 | LLM이 표시 |
| 소유권 | 플랫폼 종속 | 로컬 마크다운 파일 |
핵심 차이: RAG는 “검색 도구”이고, LLM Wiki는 “지식이 복리로 축적되는 시스템”이다.
3. 아키텍처: 3개 레이어
내가 구현한 구조는 Karpathy의 원본을 한국어 연구자 맥락에 맞게 변형한 것이다.
📁 01_raw/ ← 불변 원본 (LLM은 읽기만)
├── articles/ ← 웹 아티클 클리핑
├── papers/ ← 논문 PDF + 마크다운 변환
├── transcripts/ ← 유튜브/팟캐스트 트랜스크립트
└── notes/ ← 수기 메모
📁 02_wiki/ ← LLM이 생성·유지하는 위키
├── concepts/ ← 개념 페이지 (attention, LoRA, ...)
├── entities/ ← 인물/조직/모델 페이지
├── sources/ ← 소스별 요약 페이지
├── syntheses/ ← 종합 분석 페이지
├── index.md ← 전체 카탈로그
└── log.md ← 작업 이력 (append-only)
📁 03_output/ ← 위키에서 파생된 결과물
├── blog/ ← 블로그 포스트
├── portfolio/ ← 포트폴리오
└── slides/ ← 발표자료
핵심 원칙
- 01_raw는 진실의 원천(source of truth). LLM은 절대 수정하지 않는다.
- 02_wiki는 LLM이 소유. 사용자는 읽기만, LLM이 쓰기.
- 03_output은 위키에서 파생. 블로그 포스트도 위키 기반으로 생성.
4. 워크플로우: Ingest → Query → Lint → Output
4.1. Ingest (원본 → 위키)
새 소스가 01_raw/에 들어오면:
- LLM이 원문을 읽는다
- 사용자와 핵심 내용을 논의한다
02_wiki/sources/에 요약 페이지를 생성한다- 관련
concepts/,entities/페이지를 갱신한다 index.md를 업데이트한다log.md에 기록한다
단일 소스 하나가 10~15개 위키 페이지에 영향을 줄 수 있다. 이 교차 참조 업데이트를 사람이 수동으로 하면 30분. LLM은 2분.
4.2. Query (질의 → 답변)
index.md에서 관련 페이지를 탐색하고, 그래프 기반 탐색을 병행하여 종합 답변을 생성한다. 가치 있는 답변은 syntheses/에 저장하여 지식으로 축적.
4.3. Lint (건강 점검)
주기적으로 위키 상태를 점검한다:
- 페이지 간 모순 확인
- 고아 페이지(인바운드 링크 없는 페이지) 탐지
- 누락된 개념 식별
- 교차 참조 보완
4.4. Output (위키 → 결과물)
위키가 충분히 성숙하면 블로그 포스트, 포트폴리오, 발표자료로 변환한다. 이 글 자체가 Output 워크플로우의 산물이다.
5. 인과 관계 표기: 지식 그래프의 방향성
위키링크 [[개념]]은 “연결”만 표현한다. 하지만 지식 간에는 방향성 있는 인과 관계가 존재한다. 이를 위해 별도의 callout 컨벤션을 도입했다:
> [!causal] 인과 관계
> [[메타러닝]] →(가능하게 함)→ [[DiscoRL]]의 RL 규칙 자동 발견
> 신뢰도: 높음 | 출처: [[discovering-sota-rl-algorithms]]
허용 관계 유형:
→(가능하게 함)→: A가 B를 가능하게 함→(성능 향상)→: A가 B의 성능을 향상시킴→(기반이 됨)→: A가 B의 이론적/기술적 기반→(대체함)→: A가 B를 대체함
이 인과 관계를 파싱하면 방향 그래프가 만들어지고, 순환 참조나 모순을 자동 탐지할 수 있다.
6. 3주 운영 후 실감한 것들
효과가 있었던 것
- 지식의 복리 효과: 소스가 20개를 넘어가면서 새 소스를 인제스트할 때 기존 페이지와의 연결이 자동으로 풍부해졌다. 양자화 페이지에 Gemma 4 적용 사례가 자연스럽게 추가되는 식.
- 검색 없는 탐색:
index.md와 위키링크만으로 원하는 정보에 2~3홉 이내로 도달. 벡터 DB 없이도 ~100개 소스 규모에서 충분히 작동. - 블로그 포스트 생산 속도: 위키가 충분히 채워진 주제는 포스트 초안을 30분 내에 생성 가능.
주의할 점
- LLM의 환각: 위키 페이지에 원본에 없는 내용이 슬며시 들어갈 수 있다.
sourcesfrontmatter로 출처를 강제하고, Lint 시 검증. - 컨텍스트 한계: 위키가 커지면 LLM이 전체를 한 번에 읽지 못한다.
index.md를 진입점으로 삼아 필요한 페이지만 선택적으로 로드하는 전략이 필수. - 초기 투자: 스키마 설계, 컨벤션 정립, 첫 10개 소스 인제스트까지는 수동 개입이 많다. 이후부터 자동화 효과가 체감됨.
7. 기술 스택
| 구성 요소 | 선택 | 이유 |
|---|---|---|
| 에디터 | Obsidian | 위키링크, 그래프 뷰, 플러그인 생태계 |
| LLM 인터페이스 | Kiro (VS Code) | 파일 시스템 직접 접근, MCP 지원 |
| 버전 관리 | Git | 변경 이력, 롤백, 협업 |
| 그래프 시각화 | 자체 Python 스크립트 | 인과 관계 파싱 → graph.json → 시각화 |
| 블로그 | Jekyll (Chirpy 테마) | GitHub Pages 무료 호스팅 |
8. Karpathy가 말한 4가지 장점
- 명시성(Explicit): AI가 무엇을 알고 모르는지 위키 페이지로 직접 확인 가능
- 데이터 소유권(Yours): 로컬 마크다운 파일. 플랫폼 종속 없음
- 파일 우선(File over app): 범용 포맷이라 어떤 도구든 호환
- AI 선택 자유(BYOAI): Claude, GPT, 로컬 모델 등 자유롭게 교체 가능
9. 결론: 누가 유지 관리하는가
Vannevar Bush가 1945년 Memex를 구상했을 때 해결하지 못한 문제가 있었다: “누가 이 지식 저장소를 유지 관리하는가?”
80년이 지나서야 답이 나왔다. LLM이 한다.
입력 마찰을 0에 가깝게 낮추고, 교차 참조를 자동으로 유지하며, 모순을 감지하고, 지식을 복리로 축적한다. 사용자는 소싱과 질문에만 집중하면 된다.
PKM의 역사는 실패의 역사였다. LLM Wiki는 그 공식을 처음으로 뒤집을 수 있는 패턴이다.
관련 개념:
참고 자료:
- Andrej Karpathy, “LLM Wiki Guide” (2026), GitHub Gist
- NEWIT, “카파시도 못 말한 LLM-Wiki의 진실” (2026), YouTube