LLM을 문서와 함께 쓰는 가장 흔한 방식은 아직도 파일 업로드형 RAG다. PDF나 노트를 넣어 두고, 질문이 들어올 때마다 관련 청크를 다시 찾고, 그때그때 답을 생성한다. 이 접근은 빠르게 시작하기엔 좋지만, 읽은 것이 축적되지 않는다는 구조적 한계가 있다. 같은 주제에 대해 여러 번 묻더라도 모델은 매번 처음부터 다시 찾아 읽고, 서로 충돌하는 정보나 장기적으로 중요해진 연결은 별도의 지식 자산으로 남지 않는다.
unclejobs-ai/llm-wiki gist가 흥미로운 이유는 이 문제를 검색 성능이 아니라 “중간 산출물의 부재”로 본다는 점이다. 이 문서는 Karpathy의 llm-wiki.md를 포크한 아이디어 파일로, 핵심 제안은 단순하다. 원문 소스와 질문 사이에 LLM이 지속적으로 관리하는 마크다운 위키를 두고, 새 자료가 들어올 때마다 모델이 요약·교차링크·개념 페이지·충돌 표시·인덱스 갱신을 수행하게 하자는 것이다.
내가 보기엔 이 아이디어의 본질은 RAG의 대안이라기보다, LLM을 “질문 응답기”에서 “지식 저장소 관리자”로 재배치하는 데 있다. 즉 답변의 품질을 매 쿼리의 검색 운에 맡기지 않고, 읽을수록 더 좋아지는 지속적 아티팩트(compounding artifact)를 만들어 놓자는 발상이다.
무엇을 해결하려는가
이 패턴이 겨냥하는 문제는 정보 접근 자체보다도 지식 유지보수다. 개인 연구를 하든, 팀 위키를 운영하든, 팬 위키를 만들든, 가장 힘든 일은 새 자료를 읽는 것보다도 그 내용을 기존 구조에 맞게 다시 정리하고 연결하고 업데이트하는 일이다. 어떤 개념 페이지를 고쳐야 하는지, 어떤 예전 주장과 충돌하는지, 새 소스가 기존 요약을 강화하는지 약화하는지를 사람이 계속 수작업으로 관리해야 한다.
LLM Wiki는 이 유지보수 비용을 거의 0에 가깝게 낮추려 한다. gist의 표현을 그대로 따르면, 사용자는 소스를 고르고 질문을 던지고 해석 방향을 잡는 역할을 맡고, LLM은 요약, 분류, 교차참조, 인덱스 관리, 로그 기록, orphan page 탐지 같은 “지루한 사무 작업”을 맡는다. 즉 문제 정의는 “더 잘 검색하자”가 아니라 “지식 베이스가 버려지는 이유인 운영 부담을 없애자”에 가깝다.
또 하나 중요한 문제의식은 세션 휘발성이다. 일반적인 채팅 기반 LLM 사용에서는 좋은 질문과 좋은 답변이 대화창 안에 갇힌 채 사라진다. 반면 이 패턴에서는 질의 과정에서 나온 비교표, 분석, 연결 발견까지 다시 위키 페이지로 저장해 누적시킨다. 질문조차 지식 생성의 일부로 다루는 셈이다.
핵심 아이디어 / 구조 / 동작 방식
LLM Wiki가 제안하는 구조는 3계층이다. 첫 번째는 raw sources다. 논문, 기사, 이미지, 데이터 파일 같은 원문 소스이며, 이 계층은 불변(immutable)이다. LLM은 읽기만 하고 수정하지 않는다. 두 번째는 wiki 계층이다. 요약 페이지, 개체(entity) 페이지, 개념 페이지, 비교 페이지, 전체 개요 페이지 같은 마크다운 문서들이 여기에 쌓인다. 이 층은 사람이 아니라 LLM이 주도적으로 생성·수정·정리한다. 세 번째는 schema 계층이다. 예를 들어 Claude Code의 CLAUDE.md, Codex의 AGENTS.md처럼, 위키 구조와 운영 규칙을 정의하는 문서다. gist는 이 스키마를 “generic chatbot을 disciplined wiki maintainer로 바꾸는 핵심 설정 파일”로 본다.
운영 루프도 비교적 명확하다. Ingest 단계에서는 새 소스를 raw 컬렉션에 넣고 LLM에게 처리하게 한다. 그러면 모델은 소스를 읽고 요약 페이지를 만들고, 인덱스를 갱신하고, 관련 개체/개념 페이지를 업데이트하고, 로그에 변경 이력을 남긴다. gist는 소스 하나가 10~15개 위키 페이지를 건드릴 수 있다고 설명한다. Query 단계에서는 사용자가 위키에 질문을 던지고, LLM은 관련 페이지를 읽어 답을 합성한다. 여기서 중요한 포인트는 답변 결과도 다시 위키에 저장할 수 있다는 점이다. Lint 단계에서는 위키 전체를 점검하며 충돌, 오래된 주장, orphan page, 누락된 cross-reference, 추가 조사 후보를 찾는다.
인덱싱 방식도 흥미롭다. gist는 임베딩 기반 RAG를 바로 쓰기보다, 중간 규모에서는 index.md와 log.md 두 파일만으로도 충분히 실용적일 수 있다고 주장한다. index.md는 카테고리별 페이지 목록과 한 줄 요약을 모은 콘텐츠 중심 카탈로그이고, log.md는 ingest/query/lint의 시간순 기록이다. 특히 ## [YYYY-MM-DD] ingest | title 같은 접두 패턴을 쓰면 간단한 Unix 도구로도 최근 작업 이력을 파싱할 수 있다는 점을 예로 든다. 즉 이 패턴은 거대한 벡터 인프라보다도, 마크다운과 파일 규율만으로 꽤 멀리 갈 수 있다는 쪽에 가깝다.
또한 문서는 Obsidian을 실질적 인터페이스로 상정한다. 본문에서 “Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase.”라고 표현하듯, 사람은 Obsidian의 graph view와 페이지 브라우징을 통해 결과를 읽고, LLM은 그 파일들을 편집한다. 여기에 Obsidian Web Clipper, Dataview, Marp, 이미지 로컬 다운로드, 그리고 필요 시 qmd 같은 로컬 검색 CLI/MCP를 붙여 운영 도구 체인을 확장한다.
| 계층 | gist에서 제안하는 역할 | 의미 |
|---|---|---|
| Raw sources | 논문, 기사, 이미지, 데이터 등 불변 원문 저장소 | 원본 근거를 보존하고 LLM이 읽기만 하도록 분리 |
| Wiki | 요약/개체/개념/비교/종합 페이지를 담는 마크다운 디렉터리 | 답변을 재생산하지 않고 축적 가능한 지식 자산으로 변환 |
| Schema | CLAUDE.md / AGENTS.md류의 운영 규칙 문서 |
LLM을 일반 챗봇이 아닌 위키 관리자로 규율 |
| 운영 루프 | gist에서 설명한 동작 | 실무적 함의 |
|---|---|---|
| Ingest | 새 소스를 읽고 요약/인덱스/관련 페이지/로그를 한 번에 갱신 | 새 자료가 들어올수록 위키 전체가 더 정교해짐 |
| Query | 위키를 읽고 답을 합성한 뒤, 유용한 답은 다시 페이지로 저장 | 탐색 과정 자체가 지식 축적의 일부가 됨 |
| Lint | 충돌, stale claim, orphan page, 누락 링크 점검 | 시간이 갈수록 위키 품질이 악화되지 않도록 유지 |
| Search tools | 초기엔 index.md, 커지면 qmd 같은 로컬 검색 도구 |
작은 위키는 단순하게, 큰 위키는 점진적으로 고도화 |
공개된 근거에서 확인되는 점
이 gist는 제품이나 논문이 아니라 아이디어 문서다. 따라서 성능 수치나 벤치마크는 없다. 대신 공개적으로 확인되는 것은 패턴의 구체성이다. 문서는 개인, 연구, 독서, 팀 위키, 경쟁분석, due diligence, 여행 계획 등 다양한 적용 맥락을 직접 나열하고 있고, 단순 개념 설명을 넘어서 index.md, log.md, ingest/query/lint 루프, Obsidian Web Clipper, Dataview, Marp, 이미지 다운로드, qmd까지 운영 요소를 꽤 세세하게 제안한다.
또 하나 확인되는 점은 이 패턴이 도구 종속적이지 않다는 것이다. 본문은 OpenAI Codex, Claude Code, OpenCode/Pi 등을 예로 들지만, 특정 모델이나 특정 벤더 기능에 묶여 있지 않다. 오히려 핵심은 “어떤 LLM이든 파일 시스템을 다루고 규율 문서를 읽을 수 있다면 위키 관리자 역할을 수행할 수 있다”는 쪽에 있다. 이 점은 장기적으로 도구 교체 비용을 낮추는 장점이 될 수 있다.
메타데이터 관점에서도 흥미롭다. 현재 페이지는 unclejobs-ai 계정의 gist지만, GitHub UI상 karpathy/llm-wiki.md에서 포크한 것으로 표시된다. 또한 star 12, fork 11, 최근 활동 3주 전이라는 공개 신호가 보인다. 규모가 큰 정식 프로젝트는 아니지만, 적어도 아이디어 파일로서 복제·확장·재배포되기 시작한 상태라고 볼 수 있다.
한편 이 문서는 의도적으로 추상적이다. 마지막 Note 섹션은 디렉터리 구조, 페이지 포맷, 툴링, 출력 형식이 전부 도메인별로 달라질 수 있다고 못 박는다. 다시 말해 이는 “완성된 제품 사양”이 아니라, 에이전트와 함께 각자 구현하라고 던지는 설계 패턴이다. 강점이자 한계가 동시에 여기에 있다.
실무 관점에서의 해석
내가 보기엔 LLM Wiki의 가장 중요한 통찰은 “검색보다 유지보수”를 자동화해야 지식 베이스가 살아남는다는 점이다. 많은 RAG 시스템은 retrieval 품질과 chunking 전략, embedding 모델, reranker에 집중하지만, 실제 현업에서는 지식이 오래 축적되기 위해 페이지 구조, 교차 링크, 시간에 따른 수정 이력, 충돌 관리가 더 중요해지는 순간이 온다. 이 gist는 바로 그 레이어를 LLM의 주 업무로 올려놓는다.
특히 사용자 입장에서 매력적인 부분은 구현 복잡도를 점진적으로 늘릴 수 있다는 점이다. 처음에는 Obsidian + 마크다운 + index.md + log.md만으로 시작하고, 위키가 커지면 qmd 같은 로컬 검색이나 MCP 인터페이스를 붙이면 된다. 이건 초기에 벡터DB와 파이프라인을 전부 올려야 하는 무거운 지식 시스템과 다른 장점이다.
반대로 한계도 분명하다. 첫째, 이 문서는 패턴 제안이지 레퍼런스 구현이 아니기 때문에, 실제 품질은 스키마 설계와 에이전트 규율 수준에 크게 좌우될 것이다. 둘째, 위키를 LLM이 지속적으로 수정하는 구조는 잘못된 요약이나 과도한 일반화가 누적될 위험도 함께 갖는다. 셋째, 원문 소스의 신뢰도와 수집 품질이 낮으면 위키도 그만큼 오염된다. 즉 “유지보수 비용”은 줄여 주지만, “큐레이션과 검증 책임”까지 사라지게 하지는 않는다.
그럼에도 방향성은 상당히 강하다. 앞으로 개인 연구 환경이나 팀 지식 인프라에서 LLM의 가장 큰 역할은 답변 생성 자체보다, 읽은 것을 구조화된 장기 자산으로 계속 편집해 주는 쪽일 가능성이 크다. 그런 의미에서 LLM Wiki는 새로운 제품 하나를 제시한다기보다, 에이전트 시대의 개인/팀 지식 관리 패턴을 매우 간결하게 정의한 문서로 읽는 편이 맞다.