한줄 요약
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에게 처리를 요청하면 다음 흐름으로 진행된다.
- LLM이 소스를 읽고 주요 내용을 사용자와 논의한다
- 위키에 요약 페이지를 작성한다
- 인덱스와 관련 개체 페이지를 업데이트한다
- 기존 내용과 충돌하는 정보가 있으면 해당 페이지에 명시적으로 표시한다
- 새로 생긴 크로스레퍼런스를 연결한다
핵심은 "지식을 한 번 컴파일하고 최신 상태로 유지"하는 것이다. 매 질문마다 재조합하지 않는다.
3단계: 실제 사용 환경
Karpathy 본인은 한쪽에 LLM 에이전트, 반대쪽에 Obsidian을 열어두고 사용한다. LLM이 대화를 기반으로 위키를 편집하면, Obsidian의 그래프 뷰와 링크를 따라가며 실시간으로 결과를 확인하는 방식이다. 그는 이 구조를 이렇게 표현했다.
"Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase."
활용 가능한 맥락
- 개인: 목표, 건강, 심리, 자기계발, 일기와 아티클을 쌓으며 자신에 대한 구조화된 그림을 만든다
- 리서치: 논문과 보고서를 읽으며 진화하는 테제를 가진 종합 위키를 점진적으로 구축한다
- 독서: 챕터별로 인물, 주제, 플롯 스레드를 쌓아 팬 위키처럼 풍부한 동반 위키를 만든다
- 비즈니스/팀: 슬랙, 회의록, 프로젝트 문서를 먹여 LLM이 유지하는 내부 위키를 운영한다
