LLM Wiki

https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

LLM을 활용해 개인 지식 베이스를 구축하는 패턴.

이 문서는 아이디어 노트이며, OpenAI Codex, Claude Code, OpenCode / Pi 등 여러분이 쓰는 LLM 에이전트에 그대로 복붙해서 쓰도록 설계되었습니다. 목표는 전체적인 아이디어를 전달하는 것이고, 구체적인 구현은 여러분과 에이전트가 함께 협업하면서 만들어 가는 것입니다.

핵심 아이디어

대부분 사람들이 LLM과 문서를 함께 쓸 때 떠올리는 방식은 RAG에 가깝습니다. 파일 묶음을 업로드해 두면, LLM이 질의 시점에 관련 조각들을 찾아와서 답변을 생성하는 식이죠. 이 방식도 잘 동작하긴 하지만, LLM은 매 질문마다 지식을 처음부터 다시 발굴하는 셈입니다. 지식이 축적되지 않습니다. 다섯 개 문서를 종합해야 풀리는 미묘한 질문을 던지면, LLM은 매번 관련 부분을 다시 찾아 쪼개고 이어 붙여야 합니다. 아무것도 쌓이지 않습니다. NotebookLM, ChatGPT 파일 업로드, 대부분의 RAG 시스템이 이런 식으로 동작합니다.

여기서 제안하는 방식은 다릅니다. 단순히 질의 시점에 원본 문서에서 검색만 하는 것이 아니라, LLM이 점진적으로, 지속적으로 유지되는 위키를 구축합니다. 이 위키는 구조화된, 상호 연결된 마크다운 파일 모음이며, 여러분과 원본 소스 사이에 놓이는 중간 계층입니다. 새 소스를 추가하면 LLM은 단순히 “나중을 위한 검색 인덱스”만 만드는 것이 아니라, 문서를 읽고 핵심 정보를 뽑아 기존 위키에 통합합니다. 엔티티 페이지를 업데이트하고, 주제 요약을 수정하고, 새로운 데이터가 이전 주장과 충돌하는 부분을 메모하고, 전체적으로 쌓여 가는 종합 내용을 강화하거나 도전하게 만들죠. 지식은 매번 다시 추론되는 것이 아니라 한 번 “컴파일”되고, 이후에는 계속 최신 상태로 유지됩니다.

핵심 차이는 이것입니다. 위키는 지속적으로 축적되는 산출물이다. 크로스 레퍼런스(상호 참조)는 이미 걸려 있고, 모순은 이미 표시되어 있으며, 종합 내용은 지금까지 읽어 온 모든 것을 이미 반영합니다. 새 소스를 추가하고 새로운 질문을 던질수록, 위키는 계속 더 풍부해집니다.

여러분은 이 위키를 거의(또는 아예) 직접 쓰지 않습니다. 위키를 쓰고 관리하는 건 전부 LLM의 몫입니다. 여러분은 소스를 찾고, 탐색하고, 좋은 질문을 던지는 역할을 맡습니다. LLM은 나머지 허드렛일 — 요약하기, 상호 참조 걸기, 분류하기, 장부 정리하기 같은, 시간이 지날수록 “진짜 쓸 만한” 지식 베이스를 만들어 주는 일을 전부 맡습니다. 실제로 저는 한쪽에는 LLM 에이전트를, 다른 한쪽에는 Obsidian을 띄워 둡니다. LLM은 우리 대화를 바탕으로 위키를 수정해 나가고, 저는 그 결과를 실시간으로 살펴봅니다. 링크를 따라가 보고, 그래프 뷰를 확인하고, 갱신된 페이지를 읽어 보죠. Obsidian이 IDE라면, LLM은 프로그래머이고, 위키는 코드베이스입니다.

이 패턴은 여러 맥락에 적용할 수 있습니다. 예를 들면:

개인: 나의 목표, 건강, 심리, 자기계발을 추적하면서, 일기, 아티클, 팟캐스트 노트를 차곡차곡 쌓아, 시간이 지날수록 구조화된 “나 자신”의 위키를 만드는 용도.
리서치: 몇 주, 몇 달에 걸쳐 한 주제를 깊이 파고들며, 논문·기사·보고서를 읽고, 점진적으로 포괄적인 위키와 진화하는 “논지(thesis)”를 만드는 용도.
책 읽기: 챕터마다 정리하면서 등장인물, 테마, 플롯 흐름, 상호 연결관계를 위한 페이지를 구축. 다 읽었을 때는 풍부한 동반 위키가 생깁니다. Tolkien Gateway 같은 팬 위키를 떠올려 보세요 — 수년 동안 커뮤니티가 만든 수천 개의 상호 연결된 페이지(캐릭터, 장소, 사건, 언어 등). 그런 걸 혼자 읽으면서, LLM이 크로스 레퍼런싱과 유지보수를 대신 해 주는 형태로 만들 수 있습니다.
비즈니스/팀: Slack 스레드, 미팅 기록, 프로젝트 문서, 고객 콜 로그를 먹여 두고 LLM이 유지하는 내부용 위키. 사람 검토를 포함할 수도 있습니다. 아무도 하기 싫어하는 “위키 관리”를 LLM이 맡기 때문에, 항상 최신 상태로 유지됩니다.
경쟁 분석, 실사(due diligence), 여행 계획, 강의 노트, 취미 딥다이브 등 — 시간이 지나며 지식을 축적해야 하고, 흩어져 있기보다는 정리되어 있으면 좋은 모든 경우에 쓸 수 있습니다.

아키텍처

레이어는 세 가지입니다.

Raw sources — 여러분이 엄선한 원본 문서 모음입니다. 아티클, 논문, 이미지, 데이터 파일 등이 여기에 들어갑니다. 이 계층은 변경 불가능(immutable)합니다. LLM은 여기에서 읽기만 할 수 있고, 수정은 하지 않습니다. 이것이 최종적인 “진실의 원천(source of truth)”입니다.

The wiki — LLM이 생성한 마크다운 파일 디렉터리입니다. 요약, 엔티티 페이지, 개념 페이지, 비교, 개요, 종합 내용 등이 여기에 들어갑니다. 이 계층은 전적으로 LLM의 소유입니다. LLM이 페이지를 만들고, 새 소스가 들어올 때마다 업데이트하고, 상호 참조를 유지하며, 전체 일관성을 맞춥니다. 여러분은 읽기만 하고, 쓰기는 전부 LLM이 합니다.

The schema — 위키가 어떤 구조를 갖는지, 어떤 규칙과 컨벤션을 따르는지, 새로운 소스를 넣거나 질문에 답할 때, 또는 위키를 유지보수할 때 어떤 워크플로우를 수행해야 하는지 LLM에게 알려 주는 문서입니다. (예: Claude Code라면 CLAUDE.md, Codex라면 AGENTS.md 같은 파일.) 이게 핵심 설정 파일입니다. 이 덕분에 LLM이 “막연한 챗봇”이 아니라 “규율 있는 위키 관리자”로 동작합니다. 이 스키마는 여러분과 LLM이 함께, 도메인에 맞는 좋은 방식이 무엇인지 탐색해 가며 계속 진화시켜 나가게 됩니다.

오퍼레이션

Ingest. 새 소스를 raw 컬렉션에 떨어뜨리고, LLM에게 “처리해 달라”고 요청합니다. 예시 플로우는 이렇습니다. LLM이 소스를 읽고, 여러분과 함께 핵심 인사이트를 대화로 정리하고, 위키에 요약 페이지를 쓰고, 인덱스를 갱신하고, 관련 엔티티/개념 페이지 여러 개를 업데이트하고, log에 항목을 추가합니다. 소스 하나가 위키의 10~15개 페이지를 건드릴 수도 있습니다. 개인적으로는 소스를 한 번에 하나씩 넣으면서, 제가 직접 개입하는 방식을 선호합니다. 요약을 읽고, 업데이트를 확인하고, 어디에 강조를 둘지 LLM에게 가이드를 주는 식이죠. 하지만, 여러분은 여러 소스를 한꺼번에 배치 인제스트해서 덜 살펴보는 워크플로우를 택해도 됩니다. 어떤 워크플로우가 자신의 스타일에 맞는지는 여러분이 정하고, 한 번 정한 워크플로우는 나중 세션에서도 쓸 수 있도록 스키마 문서에 기록해 두면 됩니다.

Query. 질문은 위키를 대상으로 던집니다. LLM은 관련 페이지를 검색해 읽은 뒤, 인용을 포함한 답변을 종합합니다. 답변은 질문에 따라 여러 형태를 취할 수 있습니다 — 하나의 마크다운 페이지, 비교 테이블, 슬라이드 덱(Marp), 차트(matplotlib), 캔버스 등. 여기서 중요한 통찰은 이것입니다. 좋은 답변은 그대로 위키에 새로운 페이지로 편입할 수 있다. 여러분이 요청한 비교, 분석, 새롭게 발견한 연결 관계는 모두 가치 있는 산출물입니다. 이런 것들이 채팅 히스토리 속으로 사라지게 두지 않는 게 좋습니다. 이렇게 하면, 탐구 과정에서 나온 산출물도 인제스트된 소스와 마찬가지로 지식 베이스 안에서 복리로 쌓이게 됩니다.

Lint. 주기적으로 LLM에게 “위키를 건강 검진해 달라”고 요청합니다. 예를 들면 다음을 살펴보게 할 수 있습니다. 페이지 간 모순, 더 최신 소스에 의해 무효화된 오래된 주장, 어떤 페이지로부터도 링크되지 않은 고아 페이지, 여러 곳에서 언급되지만 전용 페이지가 없는 중요한 개념, 빠져 있는 상호 참조, 웹 검색을 통해 메울 수 있는 데이터 공백 등. LLM은 새로 던져 볼 만한 질문이나 찾아볼 만한 새 소스를 제안하는 데도 능합니다. 이런 작업이 위키가 커지는 동안 건강을 유지하는 데 도움이 됩니다.

인덱싱과 로깅

위키가 커질수록 LLM(그리고 여러분)이 탐색하기 쉽게 도와 주는 특수 파일 두 개가 있습니다. 둘의 역할은 서로 다릅니다.

index.md는 콘텐츠 중심입니다. 위키 안의 모든 것을 카탈로그 형태로 담고 있습니다 — 각 페이지를 링크와 한 줄짜리 요약, 그리고 필요하다면 날짜나 소스 개수 같은 메타데이터와 함께 나열합니다. 엔티티, 개념, 소스 등 카테고리별로 정리됩니다. LLM은 인제스트가 일어날 때마다 이 파일을 갱신합니다. 질문에 답할 때는 먼저 인덱스를 읽고 관련 페이지를 찾아 들어간 뒤, 그 페이지들을 세부적으로 읽는 식으로 동작합니다. 이 방식은 소스가 약 100개, 페이지가 수백 개 정도 되는 “중간 규모”까지는 꽤 잘 먹히고, 별도의 임베딩 기반 RAG 인프라 없이도 충분합니다.

log.md는 시간 순서 중심입니다. 언제 무엇을 했는지 — 인제스트, 쿼리, 린트 패스 등을 순서대로 쌓아 두는 append-only 기록입니다. 유용한 팁 하나: 각 항목을 일관된 프리픽스로 시작하게 만들어 두면(예: ## [2026-04-02] ingest | Article Title⁠), 단순한 유닉스 도구로도 쉽게 파싱할 수 있습니다. 예를 들어 grep "^## \[" log.md | tail -5⁠만 해도 마지막 5개 항목을 볼 수 있습니다. 로그는 위키가 어떻게 진화해 왔는지에 대한 타임라인을 제공하고, LLM이 “최근에 무슨 작업이 있었는지” 이해하는 데 도움을 줍니다.

선택 사항: CLI 도구

어느 시점이 되면, LLM이 위키를 더 효율적으로 다룰 수 있게 돕는 작은 도구들이 필요해질 수 있습니다. 위키 페이지 전체를 대상으로 하는 검색 엔진이 가장 대표적인 예입니다. 위키가 작을 때는 index 파일만으로도 충분하지만, 커지기 시작하면 제대로 된 검색이 필요해집니다. qmd는 좋은 선택지입니다. 마크다운 파일을 대상으로 로컬에서 동작하는 검색 엔진이고, BM25와 벡터 검색을 혼합한 뒤 LLM으로 재랭킹까지 수행하면서도 전부 온디바이스에서 돌아갑니다. CLI를 제공해서 LLM이 셸 명령으로 호출할 수도 있고, MCP 서버도 있어서 LLM이 네이티브 툴처럼 사용할 수도 있습니다. 아니면 더 단순한 걸 직접 만들어도 됩니다 — 필요해질 때 LLM에게 “대충 돌아가는 나이브 검색 스크립트”를 같이 만들어 달라고 시킬 수 있습니다.

팁과 요령

Obsidian Web Clipper는 웹 아티클을 마크다운으로 변환해 주는 브라우저 확장입니다. 소스를 raw 컬렉션에 빠르게 넣는 데 매우 유용합니다.
이미지는 로컬로 다운로드하기. Obsidian Settings → Files and links에서 “Attachment folder path”를 고정된 디렉터리(예: raw/assets/⁠)로 설정합니다. 그다음 Settings → Hotkeys에서 “Download”를 검색해 “Download attachments for current file”을 찾고, 단축키(예: Ctrl+Shift+D)를 연결합니다. 아티클을 클리핑한 뒤 이 단축키를 누르면, 모든 이미지가 로컬 디스크로 내려받아집니다. 필수는 아니지만 꽤 유용합니다. LLM이 깨질 수 있는 URL에 의존하지 않고, 이미지를 바로 읽고 참조할 수 있게 해 주기 때문입니다. 다만 LLM은 인라인 이미지를 포함한 마크다운 전체를 한 번에 “직접” 읽지는 못합니다. 현실적인 우회 방법은, 먼저 텍스트를 읽게 한 뒤, 필요한 일부 또는 전체 이미지를 별도로 보게 해서 추가 컨텍스트를 얻게 하는 것입니다. 약간 번거롭긴 하지만 실제로는 꽤 잘 동작합니다.
Obsidian의 그래프 뷰는 위키의 전체 형태를 보는 최고의 방법입니다. 무엇이 무엇과 연결되어 있는지, 어떤 페이지가 허브 역할을 하는지, 어떤 페이지가 고아 페이지인지 한눈에 알 수 있습니다.
Marp는 마크다운 기반 슬라이드 덱 포맷입니다. Obsidian 플러그인이 있습니다. 위키 콘텐츠로부터 바로 프레젠테이션을 생성할 때 유용합니다.
Dataview는 페이지의 프론트매터를 대상으로 질의를 실행하는 Obsidian 플러그인입니다. LLM이 위키 페이지에 YAML 프론트매터(태그, 날짜, 소스 개수 등)를 추가하도록 해 두면, Dataview가 동적인 테이블과 리스트를 생성해 줍니다.
위키는 결국 마크다운 파일로 이루어진 하나의 git 리포지토리일 뿐입니다. 버전 히스토리, 브랜치, 협업 기능을 그대로 공짜로 얻게 됩니다.

왜 이 방식이 통하는가

지식 베이스를 유지보수하는 데 지루한 부분은 읽기나 생각 자체가 아닙니다. 귀찮은 건 장부 정리입니다. 상호 참조를 업데이트하고, 요약을 최신 상태로 유지하고, 새 데이터가 예전 주장과 충돌할 때 그 사실을 표시하고, 수십 개 페이지에 걸쳐 일관성을 맞추는 작업이죠. 사람들이 위키를 포기하는 이유는, 유지보수 비용이 가치 증가 속도보다 더 빨리 커지기 때문입니다. 반면 LLM은 지루하다고 느끼지 않고, 상호 참조 업데이트를 깜빡하지 않고, 한 번에 15개 파일을 건드리는 것도 아무렇지 않습니다. 유지보수 비용이 거의 0에 수렴하기 때문에, 위키는 계속 관리되고 살아 있는 상태를 유지합니다.

사람의 역할은 소스를 선별하고, 분석 방향을 정하고, 좋은 질문을 던지고, “이게 무엇을 의미하는지”를 생각하는 일입니다. LLM의 역할은 그 외의 모든 것입니다.

이 아이디어는 정신적으로는 Vannevar Bush가 1945년에 제안한 Memex와도 비슷합니다. 개인이 큐레이션하는 지식 저장소에 문서들 사이의 연관 경로가 촘촘히 연결된 형태죠. Bush가 상상한 것은 지금의 웹이라기보다는, 여기서 말하는 것에 더 가깝습니다. 비공개이고, 적극적으로 큐레이션되며, 문서들 자체만큼이나 “문서 사이의 연결”이 중요하다는 점에서 그렇습니다. 그가 풀지 못했던 부분은 “이걸 누가 유지보수하느냐”였습니다. 그 역할을 LLM이 맡는 것입니다.

Note

이 문서는 의도적으로 추상적인 수준에 머무릅니다. 구체적인 구현이 아니라 아이디어 자체를 설명하는 것이 목적입니다. 정확한 디렉터리 구조, 스키마 컨벤션, 페이지 포맷, 도구 선택 등은 전부 여러분의 도메인, 선호, 사용하는 LLM에 따라 달라질 것입니다. 위에서 언급한 모든 요소는 선택적이고 모듈식입니다. 쓸 만한 것만 골라 쓰고, 필요 없으면 무시하면 됩니다. 예를 들어 여러분의 소스가 전부 텍스트라면, 이미지 처리는 전혀 필요 없습니다. 위키 규모가 작다면 index 파일만으로 충분하고, 별도 검색 엔진도 필요 없을 수 있습니다. 슬라이드 덱에는 관심 없고, 그냥 마크다운 페이지만 있으면 되는 사람도 있겠죠. 완전히 다른 출력 포맷을 원할 수도 있습니다. 이 문서를 활용하는 올바른 방법은, 여러분이 쓰는 LLM 에이전트와 이 문서를 공유한 뒤, 둘이 함께 여러분의 필요에 맞는 버전을 구체화해 나가는 것입니다. 이 문서의 유일한 역할은 패턴을 설명하는 것입니다. 나머지는 여러분의 LLM이 알아서 만들어 줄 수 있습니다.