Andrej Karpathy의 'LLM Wiki' 완전 분석 - 코드 대신 '지식'을 컴파일하는 AI 시대의 공부법

들어가며

2026년 4월 3일, OpenAI 창립 멤버이자 전 Tesla Autopilot Director였던 Andrej Karpathy가 X(구 트위터)에 올린 한 장의 게시물이 개발자 커뮤니티를 조용히 뒤흔들었다. 그는 평소처럼 프롬프트 → 컨텍스트 → 하네스 엔지니어링의 진화같은 기술 이야기를 던진 것이 아니라, 훨씬 더 실존적인 주제를 꺼냈다. "나는 요즘 AI로 코드를 짜는 시간보다, 지식을 정리하는 시간이 더 많다."

그는 이어서 자신이 몇 달째 돌리고 있는 시스템을 공개했다. 원자료를 한 폴더에 던져 넣으면, LLM이 자동으로 위키를 만들고, 새 자료가 들어올 때마다 기존 문서를 업데이트하고, 개념 간 상호 링크를 유지하는 "살아 있는 지식 저장소". 그의 위키는 단일 주제만으로 이미 약 100개 문서, 40만 단어에 도달해 있었다. 놀라운 점은 그 중 사람이 직접 편집한 부분은 극히 드물다는 것이다.

그는 이 아이디어를 llm-wiki라는 이름의 GitHub Gist로 공개했고, 며칠 만에 커뮤니티에서 수십 개의 구현체가 쏟아졌다. 이 글은 그 LLM Wiki 패턴을 3-Layer 아키텍처, Ingest/Query/Lint 3가지 연산, 실제 파일 구조, CLAUDE.md 스키마까지 낱낱이 분석하고, 백엔드 개발자가 오늘부터 적용할 수 있는 형태로 정리한다. 단순한 공부법 소개가 아니다. 이것은 RAG 이후의 AI-도구 통합 표준 MCP 완벽 가이드와 맞닿아 있는, "개인 지식 관리"의 패러다임 전환 제안이다.

1. Andrej Karpathy는 누구인가

시기	경력	주요 성과
2015~2017	OpenAI 창립 멤버 (Research Scientist)	강화학습, 생성 모델 연구
2017~2022	Tesla Senior Director of AI	Autopilot 비전 시스템 책임
2023~2024	OpenAI 복귀	GPT-4 시대의 모델 연구
2024~	Eureka Labs 창업	AI 네이티브 교육 플랫폼

그는 YouTube에서 Neural Networks: Zero to Hero, Let's build GPT from scratch 같은 시리즈로 수백만 명의 개발자를 훈련시킨 사실상의 "AI 시대 교사"다. 그의 트윗이 화제가 되는 이유는 단순한 유명세가 아니다. 그가 말하는 "학습 방법론"은 거의 항상 본인이 수개월 이상 직접 돌려본 실전 결과이기 때문이다. 이번 LLM Wiki 역시 다르지 않았다.

2. 트윗의 핵심 메시지 한 줄 요약

"No vector databases, no RAG pipelines, just markdown files and an LLM that acts like a full-time librarian."
— 벡터 DB도 없고, RAG 파이프라인도 없다. 그저 마크다운 파일들과 풀타임 사서(librarian)처럼 일하는 LLM뿐.

그는 이어서 말한다. "Obsidian is the IDE, the LLM is the programmer, the wiki is the codebase." 즉, Obsidian은 편집기일 뿐이고, 실제로 위키를 쓰고 갱신하는 것은 LLM이며, 완성된 위키 전체가 마치 코드베이스처럼 버전 관리되고 리팩토링된다는 뜻이다. 이 비유가 정확한 이유는 뒤에서 자세히 다룬다.

3. 왜 기존 방식은 부족한가

3-1. Obsidian / Notion의 한계 — 수동 유지보수 문제

Obsidian과 Notion은 훌륭한 도구지만 한 가지 구조적 약점이 있다. 모든 연결, 모든 요약, 모든 태그를 사람이 직접 만들어야 한다는 점이다. 자료가 100개를 넘어가는 순간, 대부분의 개인 위키는 "무덤(knowledge graveyard)"이 된다. 사람들은 자료를 계속 클리핑하지만, 정리할 시간이 없어서 결국 검색도 안 되는 스크랩북이 되어버린다. Karpathy는 이 문제를 abandonment problem이라고 부른다.

3-2. RAG의 한계 — 축적되지 않는 지식

RAG(Retrieval-Augmented Generation) 기반 개인 지식 시스템도 유행했다. 원자료를 벡터 DB에 넣고, 질문 시점에 유사도 검색으로 관련 청크를 가져와 LLM에 붙여주는 방식이다. 문제는 이 과정에서 어떤 것도 "축적"되지 않는다는 점이다.

# RAG의 전형적 흐름
질문 → 벡터 검색 → 관련 청크 5개 → LLM 합성 → 답변
              ↑
       (내일 비슷한 질문을 하면)
              ↓
질문 → 벡터 검색 → 관련 청크 5개 → LLM 합성 → 답변
        # 어제의 종합 결과는 어디에도 저장되지 않음

Karpathy의 표현을 빌리자면 "RAG는 매 질문마다 똑같은 일을 처음부터 다시 한다". 지식이 쌓이지 않고, 개념 간 관계도 암묵적이며, 모순된 자료가 들어와도 시스템이 알아채지 못한다. 그는 이 구조적 한계를 극복하기 위해 완전히 다른 접근을 제안한다.

4. LLM Wiki의 3-Layer 아키텍처

LLM Wiki는 세 개의 레이어로 구성된다. 각 레이어는 "누가 건드릴 수 있는가"가 엄격히 분리되어 있다는 점이 핵심이다.

레이어	역할	편집 주체	특성
Raw Sources (원자료)	논문, 기사, 트윗, 이미지, 데이터 파일	사람만 추가	Immutable (절대 수정 안 함)
The Wiki (마크다운 위키)	요약 페이지, 개념 페이지, 백링크	LLM 전담	지속적으로 진화
The Schema (규칙 파일)	구조, 컨벤션, 워크플로우 정의	사람이 정의	CLAUDE.md 형태

4-1. Raw Sources — 불변 원자료 층

이 폴더는 "append-only"다. 논문 PDF, 웹 스크랩 마크다운, 스크린샷, CSV, 영상 자막 — 어떤 형식이든 던져 넣을 수 있다. 다만 LLM은 절대 이 폴더의 파일을 수정하지 않는다. 원본 자료를 건드리지 않는 원칙은 과학적 재현성을 보장한다. 언제든 위키를 삭제하고 원자료만 가지고 처음부터 다시 빌드할 수 있어야 한다.

4-2. The Wiki — LLM 전담 마크다운 층

여기가 LLM이 주인이다. 새 자료가 들어올 때마다 LLM은 다음을 수행한다.

• 원자료에서 핵심 개념을 추출해 개별 개념 페이지로 분리
• 기존에 같은 개념 페이지가 있으면 업데이트, 없으면 신규 생성
• 관련 개념 간 [[wiki-links]] 형태의 백링크를 자동으로 연결
• 원자료 출처를 각 페이지 하단에 인용 블록으로 기록
• index.md에 새 페이지를 카테고리별로 등재
• log.md에 작업 내역을 append-only로 기록

4-3. The Schema — 사람이 정의하는 규칙 층

바로 이 파일이 CLAUDE.md(또는 시스템 프롬프트)다. LLM이 위키를 다룰 때 따라야 할 규칙을 정의한다. 이 규칙이 없으면 LLM은 매번 다른 스타일로 페이지를 만들어 일관성이 붕괴된다. Schema는 이 시스템의 "헌법"이다.

5. 3가지 핵심 연산: Ingest / Query / Lint

LLM Wiki는 세 가지 연산만 잘 돌아가면 된다. 각각은 LLM에게 주는 명령의 형태로 실행된다.

5-1. Ingest (수집) — 원자료를 지식으로 '컴파일'

# 사용자 명령
"raw/karpathy_llm_wiki_2026-04-03.md 파일을
CLAUDE.md 규칙에 따라 위키에 ingest 해줘."

# LLM이 수행하는 작업
1. 파일 읽고 핵심 개념 추출
2. 각 개념을 wiki/concepts/*.md 에 기록 (기존 페이지는 병합)
3. 영향받는 기존 페이지들의 백링크 업데이트
4. index.md 에 새 항목 추가
5. log.md 에 [2026-04-03 ingest] 라인 추가
6. 모순되는 정보가 있으면 'Counterarguments' 섹션에 기록

이 과정에서 중요한 것은 "한 번의 ingest에 여러 페이지가 동시에 갱신된다"는 점이다. 전통적인 노트 앱에서는 불가능했던 "횡단 업데이트"가 LLM 한 번의 호출로 처리된다.

5-2. Query (질의) — 위키에 묻기

# 사용자 명령
"위키에서 'Virtual Threads와 Reactive 비교' 주제로
답변을 만들어줘. 관련 페이지는 다 인용하고."

# LLM 수행
1. wiki/concepts/virtual-threads.md 읽기
2. wiki/concepts/reactive-programming.md 읽기
3. wiki/concepts/jvm-concurrency.md 읽기 (백링크 추적)
4. 세 페이지를 종합해 답변 생성
5. 답변이 가치 있다고 판단되면 wiki/query-results/ 에 새 페이지로 저장
   → 다음 같은 질문에서는 이 페이지가 바로 참조됨

여기서 RAG와의 결정적 차이가 드러난다. 질의 결과 자체도 위키의 일부가 된다. 오늘 답변한 내용이 내일의 원자료가 되는 구조. Karpathy는 이를 "knowledge compounds, like compound interest"라고 표현했다.

5-3. Lint (정리) — 위키의 건강 검진

# 사용자 명령 (주 1회 또는 자료 10개마다)
"wiki/ 전체에 lint 돌려줘. CLAUDE.md 규칙 따라서."

# LLM 수행
1. 고아 페이지(orphan) 탐지 - 어디서도 링크되지 않는 페이지
2. 깨진 백링크 수정 - 페이지가 리네임된 경우
3. 모순 탐지 - 같은 주제에 서로 다른 주장이 있는지
4. 오래된 정보 플래그 - 'updated' 필드가 6개월 이상 경과한 페이지
5. 누락된 cross-reference 추가
6. 결과를 lint-report.md 에 요약

이 단계가 기존 개인 위키와 가장 큰 차이를 만든다. Obsidian 사용자가 "언젠가 정리해야지" 하고 미뤄두던 작업을 LLM이 주기적으로 대신 해준다. 바로 이 지점에서 abandonment problem이 해결된다.

6. 실제 파일 구조

~/knowledge/
├── CLAUDE.md               # 스키마 (사람이 관리)
├── raw/                    # 원자료 (불변, append-only)
│   ├── 2026-04-03_karpathy_tweet.md
│   ├── 2026-04-05_rag_paper.pdf
│   └── 2026-04-07_obsidian_guide.md
├── wiki/                   # LLM 전담 영역
│   ├── index.md            # 전체 카탈로그 (ingest마다 갱신)
│   ├── log.md              # 작업 로그 (append-only)
│   ├── concepts/           # 개념 페이지
│   │   ├── llm-wiki.md
│   │   ├── rag.md
│   │   └── second-brain.md
│   ├── sources/            # 원자료 요약 페이지
│   │   └── karpathy-2026-04-03.md
│   └── query-results/      # 가치 있는 질의 응답 보존
│       └── 2026-04-10_rag-vs-wiki.md
└── outputs/                # 외부 공유용 리포트
    └── monthly-research-digest.md

7. 페이지 템플릿과 YAML Frontmatter

모든 위키 페이지는 YAML Frontmatter로 메타데이터를 갖는다. 이 구조는 Obsidian의 Dataview 플러그인이나 qmd 같은 로컬 시맨틱 검색 도구와 자연스럽게 연동된다.

---
title: LLM Wiki Pattern
type: concept           # concept | source | query-result
sources:
  - karpathy-2026-04-03
  - karpathy-gist-llm-wiki
created: 2026-04-03
updated: 2026-04-15
confidence: high        # high | medium | low
tags: [knowledge-management, llm, karpathy]
---

## TLDR
LLM이 원자료를 마크다운 위키로 "컴파일"하는 개인 지식 관리 패턴.
RAG의 비축적 문제를 pre-compiled 구조로 해결한다.

## Body
핵심은 3-Layer 구조([[raw-sources]], [[the-wiki]], [[the-schema]])와
3가지 연산([[ingest]], [[query]], [[lint]])이다. ...

## Counterarguments
- LLM 호출 비용이 누적된다는 비판 (월 $10~50 수준 보고됨)
- 페이지 수가 1000 이상이면 전수 lint가 비현실적

## Related
- [[second-brain]]
- [[rag-vs-wiki]]
- [[obsidian-workflow]]

8. CLAUDE.md 스키마 예시

이 파일이 LLM의 모든 행동을 규정한다. 아래는 Karpathy gist에서 영감을 받은 최소 버전이다.

# Knowledge Base Schema (CLAUDE.md)

## 역할
너는 이 위키의 전담 사서(librarian)다.
raw/ 폴더는 절대 수정하지 마라. wiki/ 폴더만 관리한다.

## Ingest 규칙
새 파일이 raw/ 에 들어오면:
1. 핵심 개념을 3~7개로 식별한다
2. 각 개념을 wiki/concepts/<kebab-case>.md 로 생성/갱신
3. Frontmatter의 updated 필드를 오늘 날짜로 설정
4. 해당 원자료를 sources/ 필드에 추가
5. TLDR은 반드시 한 문장, 한국어로 작성
6. Body에는 [[backlink]] 형식으로 관련 개념을 최소 2개 이상 연결
7. 상충하는 기존 정보가 있으면 Counterarguments 섹션에 명시

## Query 규칙
- 답변은 반드시 위키 페이지에서만 근거를 가져온다
- 각 주장마다 인용 페이지를 명시한다
- 질문이 기존 페이지에 없는 새로운 종합이면 query-results/ 에 저장한다

## Lint 규칙 (주 1회)
- orphan 페이지 탐지
- 6개월 이상 updated 되지 않은 high-confidence 페이지 플래그
- 모순 탐지: 같은 개념에 대해 다른 confidence의 주장이 공존하면 경고
- 결과를 wiki/lint-report.md 에 요약

## 절대 하지 말 것
- raw/ 폴더 수정
- 출처 없는 주장 추가
- Frontmatter 없는 페이지 생성
- 원본 텍스트 대량 복사 (저작권)

9. RAG vs LLM Wiki 비교

항목	RAG	LLM Wiki
지식 처리 시점	Query time (매번 재계산)	Ingest time (한 번만 컴파일)
축적 여부	없음 - 매 질의가 독립	복리처럼 누적
개념 간 연결	임베딩 공간의 암묵적 유사도	명시적 백링크 그래프
모순 탐지	불가능	Lint 단계에서 체계적 탐지
저장소	벡터 DB (외부 의존)	로컬 마크다운 파일 (Git 가능)
검색 방식	코사인 유사도 top-k	구조화된 네비게이션 + 시맨틱 하이브리드
비용 모델	Query당 임베딩 + LLM 호출	Ingest당 LLM 호출 (재사용 무료)
이식성	벡터 DB 벤더 종속	완전 로컬, 마크다운 포맷

물론 LLM Wiki가 RAG를 전부 대체한다는 뜻은 아니다. 수천만 건의 기업 문서에는 여전히 RAG가 유리하다. 다만 개인 단위, 단일 주제, 100~1000 문서 규모에서는 LLM Wiki가 명백히 우월하다는 것이 Karpathy의 주장이다.

10. 실전 적용 가이드 - 오늘부터 시작하기

Step 1. 디렉토리 생성

mkdir -p ~/knowledge/{raw,wiki/{concepts,sources,query-results},outputs}
cd ~/knowledge
git init
echo "raw/*.pdf" >> .gitignore  # 대용량은 제외

Step 2. CLAUDE.md 작성

위 섹션 8의 템플릿을 그대로 복사해 ~/knowledge/CLAUDE.md에 저장한다. 이후 자신의 도메인(백엔드 개발, AI 연구 등)에 맞게 "개념 분류" 규칙을 추가한다.

Step 3. 첫 번째 원자료 ingest

# Claude Code 또는 유사 에이전트에서
cd ~/knowledge
claude "raw/ 폴더의 새 파일들을 CLAUDE.md 규칙에 따라 ingest 해줘"

Step 4. Git 커밋으로 버전 관리

git add .
git commit -m "ingest: karpathy llm-wiki pattern"

# 변경 추적
git diff HEAD~1 wiki/concepts/llm-wiki.md
git log --oneline wiki/

버전 관리는 단순한 백업이 아니다. LLM이 어떤 식으로 지식을 변형하는지 diff로 확인할 수 있게 해준다. 잘못된 ingest는 git revert로 되돌리면 된다.

Step 5. 주기적 Lint

# crontab 예시 - 매주 일요일 저녁 Lint
0 20 * * 0 cd ~/knowledge && claude "wiki/ 전체 lint 실행"

Step 6. Obsidian 연동 (선택)

Obsidian의 Vault를 ~/knowledge/wiki로 지정하면 즉시 그래프 뷰, 백링크 패널, 검색이 동작한다. IDE는 Obsidian, 프로그래머는 LLM, 코드베이스는 위키라는 Karpathy의 비유가 여기서 체감된다.

11. 장점과 한계

11-1. 장점

• 지식의 복리 효과: 쓸수록 가치가 누적된다. Obsidian이 "stock"이라면 LLM Wiki는 "growing investment"다.
• 유지보수 자동화: 사람이 할 일은 원자료 투입과 규칙 정의뿐. 링크 관리, 요약 업데이트는 LLM이 담당한다.
• 완전 로컬 + 이식성: 마크다운 파일이라 10년 후에도 읽을 수 있다. 벤더 종속이 없다.
• Git 기반 감사 가능: 모든 변경이 커밋 단위로 추적된다. 잘못된 판단은 되돌릴 수 있다.
• 저비용: 벡터 DB 인프라 불필요. LLM 호출 비용도 매번 새로 계산하지 않으므로 RAG 대비 저렴하다.

11-2. 한계

• 초기 스키마 설계 비용: CLAUDE.md가 부실하면 위키 품질이 즉시 무너진다. 프롬프트 엔지니어링 역량이 전제된다.
• 1000 문서 이상의 확장성: 전수 lint가 현실적으로 어려워진다. 카테고리별 샤딩이나 증분 lint가 필요해진다.
• LLM 할루시네이션: 원자료에 없는 내용을 "정리"라는 명목으로 만들어 넣을 수 있다. Lint 단계에서 cross-check가 필수다.
• 실시간성 부재: ingest 이전의 자료는 반영되지 않는다. 뉴스 모니터링 같은 용도에는 부적합하다.
• 도메인별 편차: 수학처럼 기호가 많은 분야는 마크다운으로 구조화하기 어렵다.

12. 백엔드 개발자를 위한 활용 시나리오

시나리오	Raw Sources 예시	기대 효과
기술 스택 조사	Spring Boot 릴리즈 노트, 블로그, PR 토론	버전 간 변경점을 개념 단위로 정리
시스템 설계 학습	DDIA 책 정리, 대규모 시스템 포스트	패턴 간 상호 참조 자동 구축
사내 지식 공유	회의록, ADR, 슬랙 스크랩	신규 팀원이 읽을 수 있는 위키 자동 생성
장애 회고 DB	포스트모템 보고서, 알림 로그	유사 장애 발생 시 과거 사례 즉시 참조
면접 대비	CS 서적, Leetcode 풀이 노트	주제별 개념 그래프로 복습

특히 세 번째 시나리오 "사내 지식 공유"는 엔지니어링 매니저에게 즉각적인 ROI를 준다. 회고 문서, ADR(Architecture Decision Record), 슬랙 채널 스크랩을 raw/에 던져 넣기만 하면, 신규 입사자가 첫 주에 읽을 수 있는 내부 위키가 자동으로 유지된다. 2026 백엔드 기술 스택 총정리에서 AI 통합 스택 확인하기에서 다룬 Spring AI와 결합하면, 사내 Slack bot 형태로도 구현 가능하다.

13. 커뮤니티 반응과 파생 프로젝트

Karpathy의 게시 이후 며칠 만에 GitHub에는 최소 수십 개의 구현체가 올라왔다. 대표적인 파생 프로젝트 몇 가지를 소개한다.

• NicholasSpisak/second-brain: Obsidian Vault를 바로 LLM Wiki로 전환하는 템플릿
• Sage-Wiki: 컴파일러처럼 엄격한 스키마 검증을 넣은 변형
• Thinking-MCP: 의사결정 패턴을 포착하는 데 특화된 버전
• ELF: 과학 논문 전용으로 수식 렌더링과 인용 그래프를 강화한 구현
• qmd: 대규모 마크다운 위키를 위한 하이브리드 검색 CLI (시맨틱 + 키워드)

흥미로운 점은 이 프로젝트들이 대부분 MCP(Model Context Protocol)와 결합되고 있다는 것이다. 위키 전체를 MCP 서버로 노출하면, Claude Code나 다른 에이전트가 "내 개인 지식 공간"을 표준화된 도구처럼 호출할 수 있다. 이 부분은 MCP 완벽 가이드에서 설명한 철학과 정확히 맞아떨어진다.

14. RAG는 죽는가 — 논쟁의 정리

Karpathy의 게시물 이후 X와 Hacker News에서는 "RAG는 끝났다"는 선언과 "과장이다"는 반박이 격렬히 충돌했다. 냉정하게 정리하면 이렇다.

• RAG가 유효한 영역: 수천만 건의 기업 문서, 실시간 변동 데이터, 법률/의료처럼 인용 추적이 필수인 분야, 다중 사용자 동시 질의
• LLM Wiki가 유효한 영역: 개인 학습, 연구 주제 단위 심층 조사, 소규모 팀 내부 지식, 장기 프로젝트의 설계 결정 기록

즉 두 접근은 상호 대체재가 아니라 용도별 선택지다. Karpathy 본인도 트위터 댓글에서 "엔터프라이즈 RAG를 부정하는 것이 아니다. 개인 지식 관리에 한해 다른 길이 있다는 것"이라고 선을 그었다.

마치며

이 글은 단순히 "OpenAI 출신 개발자가 공유한 공부법"을 소개하는 데 그치지 않는다. LLM Wiki가 제안하는 진짜 메시지는 이것이다.

"LLM의 진정한 킬러 앱은 코드 생성이 아니라, 지식의 자동 구조화일지 모른다."

2022~2024년의 프롬프트 엔지니어링, 2025년의 컨텍스트 엔지니어링, 2026년 초의 하네스 엔지니어링으로 이어지는 진화는 결국 "LLM을 어떻게 더 믿을 만한 파트너로 만들 것인가"에 대한 답을 찾는 여정이었다. Karpathy의 LLM Wiki는 그 여정의 또 다른 분기점이다. LLM에게 코드를 맡기기 전에, 먼저 내 머릿속 지식을 맡겨보라는 제안이기 때문이다.

핵심 요약을 다시 정리한다.

• 3-Layer 구조: Raw Sources(불변) / Wiki(LLM 전담) / Schema(사람 정의). 경계를 엄격히 지킬 것.
• 3가지 연산: Ingest(컴파일), Query(축적형 질의), Lint(건강 검진). 모두 자동화 가능.
• RAG와의 결정적 차이: 쿼리 타임이 아니라 인제스트 타임에 지식이 "컴파일"되어 축적된다.
• 한계 인식: CLAUDE.md 품질과 주기적 Lint가 전제. 1000 문서 이상은 다른 전략이 필요.
• 출발점: mkdir ~/knowledge, CLAUDE.md 작성, 원자료 하나 던지기. 오늘 10분이면 시작 가능.

Karpathy는 트윗 끝에 이렇게 덧붙였다. "My wiki is now the most valuable file in my laptop." — 내 위키는 이제 내 노트북에서 가장 값진 파일이다. 2026년 4월 현재, 이 말이 과장인지 예언인지는 몇 달 뒤에야 판단할 수 있을 것이다. 다만 한 가지는 분명하다. AI로 코드를 대신 쓰게 하는 시대를 지나, 이제는 AI로 나의 지식 자체를 기르는 시대가 시작되고 있다는 점이다. 오늘 밤, ~/knowledge 폴더를 하나 만드는 것으로 그 여정에 합류해보자.