LLM Wiki: RAG를 넘어서는 지식 관리 패턴

Andrej Karpathy가 2026년 4월 공개한 아이디어 파일 분석

문제 정의: RAG의 근본적 한계

대부분의 LLM + 문서 시스템은 RAG(Retrieval-Augmented Generation)로 구현된다. 문서를 업로드하면 청크로 나눠 임베딩하고, 쿼리 시점에 유사도 검색으로 컨텍스트를 꺼내 답변을 생성한다. NotebookLM, ChatGPT file upload, 대다수 RAG 파이프라인이 이 방식이다.

문제는 지식이 축적되지 않는다는 것이다. 다섯 개 문서를 종합해야 하는 복잡한 질문을 던지면, LLM은 매번 처음부터 관련 조각들을 찾아 연결해야 한다. 이전에 비슷한 질문을 했어도 그 합성 결과는 채팅 히스토리 속으로 사라진다.

Karpathy의 핵심 통찰: 지식을 쿼리 시점에 재발견하지 말고, 미리 컴파일해 놓자.

---

핵심 아이디어: 지식을 컴파일하라

소프트웨어 개발에서 소스코드를 매번 인터프리팅하지 않고 한 번 컴파일해서 실행 가능한 바이너리로 만들어두는 이유가 있다. 미리 처리해두면 빠르고, 최적화되고, 반복 비용이 0에 수렴한다.

LLM Wiki는 지식에 같은 논리를 적용한다. RAG가 "인터프리터"라면, LLM Wiki는 "컴파일러"다.

새 문서를 추가할 때 LLM은 단순히 인덱싱하지 않는다. 그것을 읽고, 핵심을 추출하고, 기존 위키에 통합한다. 관련 엔티티 페이지를 업데이트하고, 모순되는 클레임을 플래그하고, 크로스 레퍼런스를 연결한다. 이 과정에서 하나의 소스가 10~15개의 위키 페이지에 영향을 줄 수 있다.

결과적으로 위키는 compounding artifact가 된다. 소스를 추가할수록 단순히 페이지가 늘어나는 게 아니라, 기존 지식이 새 정보로 보강되고 연결이 촘촘해진다. 다섯 개 문서를 종합해야 하는 복잡한 질문? 크로스 레퍼런스는 이미 거기 있다. 두 논문이 서로 모순된다는 사실? 이미 플래그되어 있다. 매 쿼리마다 처음부터 재발견할 필요가 없다.

Karpathy 본인의 셋업은 Claude Code를 왼쪽에, Obsidian을 오른쪽에 열어두는 방식이다. LLM이 마크다운 파일을 편집하면 Obsidian의 그래프 뷰에서 실시간으로 위키가 자라는 걸 볼 수 있다. LLM은 프로그래머, Obsidian은 IDE, 위키는 코드베이스인 셈이다.

---

3계층 아키텍처

Raw Sources — 불변. LLM이 읽지만 절대 수정하지 않는 원본 소스. 진실의 원천.

Wiki — LLM이 소유하는 마크다운 파일 디렉토리. index.md, log.md, 엔티티 페이지, 개념 페이지, 합성 문서로 구성된다.

Schema — LLM에게 위키의 구조와 워크플로우를 알려주는 설정 문서. Claude를 쓴다면 CLAUDE.md, OpenAI Codex라면 AGENTS.md에 해당한다. 이것이 LLM을 "일반 챗봇"이 아닌 "훈련된 위키 관리자"로 만드는 핵심이다.

---

세 가지 핵심 연산

Ingest — 새 소스를 추가할 때의 흐름. 소스를 읽고 → 요약 페이지 작성 → 인덱스 업데이트 → 관련 엔티티/개념 페이지 업데이트 → 로그에 항목 추가. 하나의 소스가 10~15개의 위키 페이지에 영향을 줄 수 있다.

Query — 위키에 질문한다. LLM이 관련 페이지를 찾아 읽고 인용과 함께 답변을 합성한다. 중요한 점: 좋은 답변 자체를 위키 페이지로 저장할 수 있다는 것. 비교 분석, 새로 발견한 연결, 만든 차트—이것들이 채팅 히스토리로 사라지는 게 아니라 위키에 축적된다.

Lint — 주기적으로 위키의 건강 상태를 점검한다. 모순되는 페이지, 인바운드 링크가 없는 고아 페이지, 오래된 클레임, 빠진 크로스 레퍼런스를 찾아낸다.

---

Claude로 구현하기: 실전 예시

Karpathy 본인은 Claude Code + Obsidian 조합을 사용한다. 하지만 claude.ai에서도 충분히 구현 가능하다. 다음은 실제 워크플로우 예시다.

Step 1: CLAUDE.md 작성 (Schema 정의)

 

# My Research Wiki — Schema

## Directory structure
- raw/           : 원본 소스 (읽기 전용)
- wiki/          : LLM이 관리하는 위키
  - index.md     : 모든 페이지 카탈로그
  - log.md       : 시간순 활동 기록
  - entities/    : 사람, 회사, 프로젝트 페이지
  - concepts/    : 개념/기술 페이지
  - sources/     : 소스별 요약 페이지

## Ingest workflow
새 소스를 처리할 때:
1. 소스 읽고 핵심 takeaway 정리
2. wiki/sources/에 요약 페이지 작성
3. wiki/index.md 업데이트
4. 관련 entity/concept 페이지 업데이트
5. wiki/log.md에 ## [날짜] ingest | 제목 형식으로 항목 추가
6. 기존 클레임과 모순 시 [!contradiction] 태그 추가

## Page format
각 페이지는 YAML frontmatter로 시작:
---
title: 페이지 제목
type: entity | concept | source
sources: [소스 목록]
updated: 날짜
---

Step 2: Claude에게 ingest 요청

[아티클 URL 또는 텍스트 붙여넣기]

위 소스를 ingest해줘. CLAUDE.md의 workflow를 따라서:
1. 핵심 takeaway를 먼저 나한테 얘기해줘
2. wiki/sources/ 에 요약 페이지 작성
3. 관련 페이지들 업데이트
4. 어떤 페이지를 수정했는지 알려줘

 

## 핵심 takeaway
1. Transformer의 attention 복잡도가 O(n²)인 이유는...
2. Flash Attention은 tiling 기법으로 이를 해결...
3. 기존 wiki/concepts/attention.md와 충돌: 이전엔 
   "quadratic scaling is unavoidable"로 기술되어 있었음 [!contradiction]

## 생성/수정한 페이지
- wiki/sources/flash-attention-2023.md (신규)
- wiki/concepts/attention.md (업데이트: Flash Attention 섹션 추가)
- wiki/entities/tri-dao.md (업데이트: 주요 논문 목록)
- wiki/index.md (업데이트)
- wiki/log.md (항목 추가)

Step 3: 위키에 질문하기

내가 지금까지 읽은 논문들 중에서 
메모리 효율적인 attention 메커니즘에 대한 내용을 
종합해서 비교 테이블로 만들어줘.
그리고 그 결과를 wiki/concepts/efficient-attention-comparison.md로 저장해줘.

Step 4: Lint 실행

wiki/ 디렉토리를 점검해줘:
- 인바운드 링크가 없는 고아 페이지
- 최근 ingest된 내용과 모순되는 오래된 클레임  
- 언급은 됐지만 독립 페이지가 없는 중요 개념
- 조사해볼 만한 새 질문이나 소스 추천

Claude.ai에서 쓰는 실용적인 팁

Projects 기능 활용 — Claude Projects의 "Project instructions"에 CLAUDE.md 내용을 붙여넣으면 매 대화마다 컨텍스트를 다시 설명할 필요가 없다. 위키 파일들은 Project에 첨부해두면 된다.

증분 업데이트 패턴 — 전체 위키를 매번 올리는 게 아니라, 관련 페이지만 선택적으로 첨부한다. index.md를 항상 포함하면 Claude가 어떤 페이지가 있는지 파악할 수 있다.

답변을 바로 페이지로 — 분석 결과나 비교표를 요청할 때 "그리고 이걸 wiki/concepts/XXX.md 형식으로 바로 만들어줘"를 붙이면 채팅 히스토리가 아닌 위키로 축적된다.

---

어디에 쓸 수 있나

• 논문 리뷰: 주 단위로 논문을 읽으며 연구 위키 구축. 각 논문이 기존 지식 어디에 맞는지 자동으로 통합
• 코드베이스 이해: 대규모 레포를 탐색하며 아키텍처 위키 생성 (Karpathy 본인도 코드베이스 전용 패턴을 언급)
• 경쟁사 분석: 뉴스, 블로그, 발표 자료를 ingest하며 업계 지식 베이스 유지
• 팀 내부 위키: Slack 스레드, 미팅 노트, 프로젝트 문서를 먹이면 LLM이 "살아있는 팀 위키"를 유지

---

왜 지금 이게 가능한가

Karpathy의 설명이 명쾌하다: 위키 관리의 지루한 부분은 독서나 사고가 아니라 북키핑이다. 크로스 레퍼런스 업데이트, 요약 최신화, 모순 기록, 수십 개 페이지의 일관성 유지. 사람들이 위키를 포기하는 이유는 유지보수 부담이 가치 창출 속도보다 빨리 커지기 때문이다.

LLM은 지루해하지 않는다. 크로스 레퍼런스 업데이트를 까먹지 않는다. 한 번에 15개 파일을 수정할 수 있다.

인간의 역할은 소스 큐레이션, 분석 방향 설정, 좋은 질문 던지기. LLM의 역할은 나머지 전부.

---

주의할 점과 커뮤니티 인사이트

5천 개 이상의 스타를 받은 이 Gist에는 이미 수십 개의 구현체가 등장했다. 댓글에서 건진 실용적인 교훈들:

규모가 커지면 (200개 이상 소스) "거짓 일관성" 문제가 생긴다—에러가 통합 과정에서 퍼져 내부적으로 일관성 있어 보이지만 틀린 내용이 된다. 초기엔 인간 검토를 유지하라.

LLM이 위키 내용을 작성한다는 건 "퍼스널 세컨드 브레인"이 아니라 "퍼스널 리서치 인덱스"에 가깝다는 지적도 있다. 글쓰기 자체가 사고 과정인 사람에겐 이 구분이 중요할 수 있다.

Claude Code 사용자라면 CLAUDE.md가 곧 schema다. ## [날짜] ingest | 제목 패턴으로 log.md를 작성하면 grep "^## \[" log.md | tail -5 같은 유닉스 툴로 파싱 가능하다는 팁도 실용적이다.

---

이 패턴이 흥미로운 이유는 기술적 복잡성이 낮다는 것이다. 특별한 인프라 없이, 마크다운 파일과 좋은 schema 문서 하나로 시작할 수 있다. 핵심은 LLM을 "질문에 답하는 도구"가 아닌 "지식 베이스를 유지하는 에이전트"로 사용하는 관점의 전환이다.