RAG의 한계를 넘는 LLM 위키: 지식이 쌓이는 개인 지식베이스 구축법 (gist.github.com)

한줄 요약

RAG처럼 매번 재조합하는 대신, LLM이 직접 마크다운 위키를 쌓아가며 지식을 누적하는 구조다.

---

어떤 상황에서 필요한가?

문서를 여러 개 올려두고 질문할 때마다 LLM이 같은 내용을 처음부터 다시 찾아 조합하는 경험, 익숙할 것이다. NotebookLM이나 ChatGPT 파일 업로드 같은 대부분의 RAG 기반 시스템이 이 방식으로 작동한다. 여러 문서를 가로지르는 미묘한 질문이나 장기간 누적된 맥락이 필요한 작업에서는 이 구조가 근본적으로 한계를 드러낸다.

주제를 몇 주에 걸쳐 깊이 파고드는 리서치, 책을 챕터별로 읽으며 등장인물과 주제를 추적하는 독서 노트, 팀의 슬랙 스레드와 회의록을 정리하는 내부 위키처럼 지식이 시간에 따라 누적되어야 하는 상황이라면 이 접근이 훨씬 유효하다.

---

핵심 구현 방법

이 구조는 세 개의 레이어로 나뉜다.

1단계: 레이어 설계

① 원본 소스 (Raw Sources) 논문, 기사, 데이터 파일 등 수집한 원본 문서들이다. LLM은 읽기만 하고 절대 수정하지 않는다. 이 레이어가 유일한 사실의 원천이다.

② 위키 (The Wiki) LLM이 생성하고 유지하는 마크다운 파일 디렉토리다. 개체(entity) 페이지, 개념 요약, 비교 페이지, 전체 개요가 여기에 쌓인다. 사람은 읽기만 하고, LLM이 쓴다.

③ 스키마 문서 (Schema) Claude Code라면 CLAUDE.md, Codex라면 AGENTS.md 같은 설정 파일이다. 위키의 구조, 컨벤션, 소스 처리 워크플로우를 LLM에게 명시적으로 알려준다. 이 파일이 없으면 LLM은 그냥 일반 챗봇처럼 동작한다. 도메인에 맞게 사용자와 LLM이 함께 점진적으로 다듬어 나간다.

2단계: 소스 ingestion 흐름

새 문서를 원본 폴더에 넣고 LLM에게 처리를 요청하면 다음 흐름으로 진행된다.

1. LLM이 소스를 읽고 주요 내용을 사용자와 논의한다
2. 위키에 요약 페이지를 작성한다
3. 인덱스와 관련 개체 페이지를 업데이트한다
4. 기존 내용과 충돌하는 정보가 있으면 해당 페이지에 명시적으로 표시한다
5. 새로 생긴 크로스레퍼런스를 연결한다

핵심은 "지식을 한 번 컴파일하고 최신 상태로 유지"하는 것이다. 매 질문마다 재조합하지 않는다.

3단계: 실제 사용 환경

Karpathy 본인은 한쪽에 LLM 에이전트, 반대쪽에 Obsidian을 열어두고 사용한다. LLM이 대화를 기반으로 위키를 편집하면, Obsidian의 그래프 뷰와 링크를 따라가며 실시간으로 결과를 확인하는 방식이다. 그는 이 구조를 이렇게 표현했다.

"Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase."

활용 가능한 맥락

• 개인: 목표, 건강, 심리, 자기계발 — 일기와 아티클을 쌓으며 자신에 대한 구조화된 그림을 만든다
• 리서치: 논문과 보고서를 읽으며 진화하는 테제를 가진 종합 위키를 점진적으로 구축한다
• 독서: 챕터별로 인물, 주제, 플롯 스레드를 쌓아 팬 위키처럼 풍부한 동반 위키를 만든다
• 비즈니스/팀: 슬랙, 회의록, 프로젝트 문서를 먹여 LLM이 유지하는 내부 위키를 운영한다