2026년 4월 3일, Andrej Karpathy가 X에 올린 한 포스트가 며칠 만에 Hacker News 상위에 올랐다. 주요 기술 매체와 커뮤니티에서 분석글이 쏟아졌고 “LLM이 지식을 어떻게 관리할 것인가”가 4월 첫 주 개발자 커뮤니티의 가장 뜨거운 주제가 됐다. LLM의 토큰 소비가 코드에서 지식으로 옮겨가고 있다.
“Something I’m finding very useful recently: using LLMs to build personal knowledge bases for various topics of research interest. In this way, a large fraction of my recent token throughput is going less into manipulating code, and more into manipulating knowledge.”
최근 매우 유용하다고 느끼는 것: LLM을 활용해 관심 연구 주제에 대한 개인 지식 베이스를 구축하는 것이다. 이렇게 하면서 최근 내 토큰 사용량의 상당 부분이 코드를 다루는 데서 지식을 다루는 쪽으로 이동하고 있다.
#raw → wiki → output: 3계층 아키텍처
Karpathy의 시스템은 raw, wiki, output 세 디렉토리로 나뉜다. 소스 코드에서 바이너리를 뽑아내듯, LLM이 원시 자료에서 구조화된 지식을 뽑아내는 구조다.
#원시 소스 — raw/
수정되지 않은 원본 문서를 모으는 곳이다. 웹 기사, PDF, 이미지, 데이터셋, 논문을 있는 그대로 보관한다. 한 번 넣으면 수정하지 않고 삭제하지 않는다. 모든 컴파일의 기반이 되므로 원본을 잃으면 재생성이 불가능하다.
#컴파일된 지식 — wiki/
개념 페이지, 엔티티 프로필, 요약, 교차 참조로 구성된 구조화된 지식이 쌓이는 곳이다. raw/를 컴파일한 결과물이고, 실행 가능한 형태의 지식이다.
Karpathy는 wiki/의 구조를 Gist에 공개했다. 핵심은 스키마다. CLAUDE.md(또는 AGENTS.md)가 LLM에게 위키의 구조와 워크플로우를 지시한다. 이 스키마를 쓰는 것은 곧 “내 도메인을 어떻게 구조화할 것인가”를 결정하는 일이다.
위키의 중심에는 두 개의 파일이 있다.
index.md: 모든 페이지의 카탈로그. 한 줄 요약과 메타데이터로 구성된 라우팅 테이블. LLM이 전체 위키를 네비게이션하는 진입점log.md: 추가 전용(append-only) 연대기. 언제 무엇이 인제스트되었고, 어떤 쿼리가 실행되었는지 기록
#쿼리 결과 — output/
LLM에게 질문하면 답변, 슬라이드, 차트가 output/에 쌓인다. 대부분은 일회성이지만, 쓸 만한 결과는 wiki/로 다시 넣는다(filing back). 모든 쿼리가 위키에 기여한다.
#검색이 아니라 컴파일이다
LLM에게 내 지식을 다루게 하는 표준 해법은 지난 2년 동안 RAG 하나였다. 문서를 벡터 DB에 넣고, 질문이 들어오면 유사한 청크를 찾아 LLM 컨텍스트에 넣는 방식이다. Karpathy가 반직관적인 주장을 한 이유는 이 표준 해법에 근본적인 한계가 있다고 봤기 때문이다.
RAG는 질문이 들어올 때마다 새로 검색하고 조립한다. 벡터 DB가 보는 건 시맨틱 유사도뿐이다. 청크 #4271이 청크 #8903과 서로 모순되는지 모른다. 둘 다 청크 #112의 특수 사례인지도 모른다. 더 최신 연구가 이미 #8903을 뒤집었는지도 모른다. 청크로 자르는 순간 맥락이 끊기고, 문서 사이의 관계는 사라진다.
컴파일은 이 관계를 미리 기록해두는 접근이다. 질문이 올 때 찾는 게 아니라, 새 소스가 들어올 때 LLM이 기존 위키를 읽고 관계를 명시적으로 업데이트한다. 벡터 DB가 “모르는” 것들이 위키에는 적혀 있다. 모순은 모순으로, 특수 사례는 특수 사례로, 대체된 연구는 대체된 것으로. 검색 결과는 매번 새로 조립되지만, 컴파일된 지식은 쌓이고 진화한다.
| 항목 | RAG | 컴파일 |
|---|---|---|
| 처리 시점 | 질문 시점 | 인제스트 시점 |
| 저장 형식 | 벡터 임베딩 (청크) | 마크다운 (페이지) |
| 관계 표현 | 시맨틱 유사도 | 명시적 교차 참조 |
| 모순/대체 추적 | 불가능 | 명시적 |
| 누적 효과 | 없음 | 쌓이고 진화 |
| 인프라 | 벡터 DB 필요 | 파일시스템만 |
“I thought I had to reach for fancy RAG, but the LLM has been pretty good about auto-maintaining index files and brief summaries of all the documents.”
복잡한 RAG가 필요할 줄 알았지만, LLM이 인덱스 파일과 문서 요약을 자동으로 관리하는 것만으로 충분했다.
실제 사례의 규모도 작지 않다. Karpathy의 위키는 한 주제당 100개 기사, 40만 단어다. 주요 모델의 컨텍스트 윈도우에 통째로 들어가고, index.md 하나로 훑을 수 있는 크기다. 벡터 DB가 필요해지는 임계점은 생각보다 훨씬 멀다.
#위키를 진화시키는 세 가지 동작
위키가 한 번 만들어지고 끝나는 문서 모음이었다면 그저 정적 아카이브였을 것이다. Karpathy의 시스템이 흥미로운 이유는 세 가지 동작이 반복되면서 위키가 계속 진화하기 때문이다.
- 인제스트(Ingest): 새 소스를
raw/에 추가하면 LLM이 읽고, 요약하고, 기존 위키의 관련 페이지를 업데이트한다. 하나의 소스가 10~15개 페이지에 영향을 줄 수 있다. Obsidian Web Clipper로 웹을, Docling이나 Marker로 PDF를 마크다운으로 변환해서 넣는다. - 쿼리(Query): 위키를 대상으로 복잡한 질문을 던진다. LLM이
index.md에서 관련 페이지를 찾고, 읽고, 교차 참조하며 답변을 합성한다. 결과는output/에 쌓이고, 쓸 만한 것은wiki/로 돌아간다. - 린트(Lint): LLM이 위키 전체를 대상으로 건강 검진을 수행한다. 페이지 간 모순, 누락된 교차 참조, 오래된 정보, 새 기사 후보를 찾아낸다. 코드에 린터가 있듯, 지식에도 린터가 있다.
인제스트가 지식을 넣고, 쿼리가 검증하고, 린트가 교정한다. 이 순환이 반복될수록 위키는 정적 아카이브에서 살아 있는 시스템으로 진화한다.
#다른 출발, 같은 결론
이 방향으로 움직였던 건 Karpathy만이 아니다.
Shopify CEO Tobi Lütke는 qmd를 공개했다. 로컬에서 동작하는 마크다운 검색 엔진이다. BM25 풀텍스트 검색, 벡터 시맨틱 검색, LLM 리랭킹을 결합하며, 완전히 로컬에서 실행된다. Claude Code의 MCP 서버로 통합되어 AI 에이전트의 메모리 백엔드로도 쓰인다.
qmd와 Karpathy의 컴파일은 정반대처럼 보인다. 하나는 검색 엔진이고, 다른 하나는 “검색이 아니라 컴파일”이라고 선언했다. 그런데 두 접근은 규모만 다를 뿐 같은 문제를 풀고 있다. 위키가 컨텍스트 윈도우에 들어가는 규모면 컴파일로 충분하고, 넘어서면 검색이 필요하다.
Building a Second Brain의 저자 Tiago Forte도 2026년 AI-first로 피벗했다. 원래 BASB는 “개인 지식 관리”였는데, AI 버전은 “개인 컨텍스트 관리”로 재정의했다. 핵심은 AI에게 적절한 정보를 적절한 시점에 제공하는 일이다. Karpathy의 raw → wiki → output이 정확히 이 구조다.
#구조를 지원하는 기술
raw → wiki → output이라는 구조만 보면 특별할 게 없다. 새로운 건 LLM 기술로 이 구조를 유지보수할 수 있게 됐다는 점이다. 세 가지 전제가 2026년에 갖춰졌다.
컨텍스트 윈도우가 확장되면서 개인 위키 규모(수십만 단어)를 LLM이 통째로 읽을 수 있게 됐다. 마크다운이 LLM의 네이티브 포맷이 되면서 변환 비용 없이 직접 읽고 쓸 수 있게 됐다. 그리고 Claude Code와 Codex 같은 에이전트가 파일을 직접 조작하면서, LLM이 스스로 읽고 수정하고 저장할 수 있게 됐다. 읽기, 읽고 쓰기, 읽고 쓰고 유지보수하기. 세 전제가 순서대로 쌓인 것이다.
이 중 진짜 변곡점은 컨텍스트 윈도우가 아니다. Gemini 1.5 Pro는 2024년 2월에 이미 2M 토큰을 제공했지만, 그것만으로 변화는 시작되지 않았다. 결정적인 건 에이전트가 파일을 직접 조작할 수 있게 된 것이다. Claude Code와 Codex 이전까지 LLM은 복사-붙여넣기로만 접근할 수 있었고, 유지보수는 항상 인간의 몫이었다. 파일시스템 API가 열리면서 비로소 위키가 LLM의 관할로 넘어갔다.
“검색이 아니라 컴파일”이라는 프레이밍을 뒤집어 보면, 컴파일은 LLM이 파일을 직접 읽고, 쓰고, 유지보수한다는 것을 전제한다. 벡터 DB도, 독자적인 API도 필요 없다. 기술자(Karpathy), 경영자(Lütke), 이론가(Forte)가 각자의 맥락에서 같은 결론에 도달한 이유다.
LLM에게는 파일시스템으로도 충분하다.
직접 시도해보려면 Karpathy의 Gist를 복사해 자신의 LLM 에이전트에 붙여넣는 것부터 시작할 수 있다.
#참고 자료
- Andrej Karpathy — LLM Knowledge Bases (X) — 원문 트윗
- Karpathy — llm-wiki Gist (GitHub) — CLAUDE.md 패턴, index.md, log.md 구조
- Hacker News 토론 — LLM Wiki, example of an “idea file” — 커뮤니티 반응
- VentureBeat — Karpathy shares LLM Knowledge Base architecture — RAG를 우회하는 마크다운 라이브러리 분석
- Tiago Forte — Introducing The AI Second Brain — BASB의 AI-first 피벗
- qmd by Tobi Lütke (GitHub) — 로컬 마크다운 시맨틱 검색 엔진
- Steph Ango — File over App — 앱은 사라지지만 파일은 남는다