LLM을 활용하여 개인 지식 베이스를 구축하는 패턴.
이것은 아이디어 문서이며, 여러분이 사용하는 LLM 에이전트(예: OpenAI Codex, Claude Code, OpenCode / Pi 등)에 복사하여 붙여넣을 수 있도록 설계되었습니다. 이 문서의 목표는 상위 수준의 아이디어를 전달하는 것이며, 구체적인 세부 사항은 여러분의 에이전트가 여러분과 협업하여 구현해 나갈 것입니다.
대부분의 사람들이 LLM과 문서를 함께 사용하는 경험은 RAG(검색 증강 생성)와 비슷합니다. 파일 모음을 업로드하면, LLM이 쿼리 시점에 관련 청크를 검색하고 답변을 생성합니다. 이 방식은 동작하지만, LLM은 매 질문마다 지식을 처음부터 다시 발견해야 합니다. 축적이 없습니다. 다섯 개의 문서를 종합해야 하는 미묘한 질문을 하면, LLM은 매번 관련 조각들을 찾아 짜맞춰야 합니다. 아무것도 쌓이지 않습니다. NotebookLM, ChatGPT 파일 업로드, 그리고 대부분의 RAG 시스템이 이런 방식으로 동작합니다.
여기서 제안하는 아이디어는 다릅니다. 쿼리 시점에 원본 문서에서 단순히 검색하는 대신, LLM이 점진적으로 영구적인 위키를 구축하고 유지합니다 — 여러분과 원본 소스 사이에 위치하는, 구조화되고 상호 연결된 마크다운 파일 모음입니다.
새로운 소스를 추가하면, LLM은 단순히 나중에 검색할 수 있도록 인덱싱하지 않습니다. 소스를 읽고, 핵심 정보를 추출하며, 기존 위키에 통합합니다 — 엔티티 페이지를 업데이트하고, 주제 요약을 수정하고, 새 데이터가 기존 주장과 모순되는 부분을 표시하고, 발전하는 종합을 강화하거나 도전합니다. 지식은 한 번 컴파일되고 최신 상태로 유지되며, 매 쿼리마다 재도출되지 않습니다.
이것이 핵심 차이점입니다: 위키는 영구적이고 복리로 성장하는 산출물입니다. 교차 참조가 이미 존재합니다. 모순은 이미 표시되어 있습니다. 종합은 여러분이 읽은 모든 것을 이미 반영합니다. 소스를 추가하고 질문을 할 때마다 위키는 점점 더 풍부해집니다.
위키를 직접 작성하는 일은 없거나 거의 없습니다 — LLM이 모든 것을 작성하고 유지합니다. 여러분은 소스 수집, 탐색, 그리고 좋은 질문을 하는 역할을 맡습니다. LLM은 시간이 지남에 따라 지식 베이스를 실제로 유용하게 만드는 모든 허드렛일 — 요약, 교차 참조, 정리, 기록 관리 — 을 수행합니다.
실제로 저는 한쪽에 LLM 에이전트를, 다른 쪽에 Obsidian을 열어놓고 사용합니다. LLM이 대화를 기반으로 편집하면, 저는 실시간으로 결과를 탐색합니다 — 링크를 따라가고, 그래프 뷰를 확인하고, 업데이트된 페이지를 읽습니다. Obsidian은 IDE이고, LLM은 프로그래머이며, 위키는 코드베이스입니다.
이것은 다양한 맥락에 적용될 수 있습니다. 몇 가지 예시:
개인용: 자신의 목표, 건강, 심리, 자기 개선을 추적하는 것 — 일기 항목, 기사, 팟캐스트 노트를 정리하고, 시간이 지남에 따라 자신에 대한 구조화된 그림을 구축합니다.
연구용: 몇 주 또는 몇 달에 걸쳐 주제를 깊이 파고드는 것 — 논문, 기사, 보고서를 읽고, 발전하는 논지와 함께 종합적인 위키를 점진적으로 구축합니다.
독서용: 각 장을 읽을 때마다 정리하고, 등장인물, 주제, 줄거리 흐름과 그 연결에 대한 페이지를 구축합니다. 마지막에는 풍부한 동반 위키를 갖게 됩니다. Tolkien Gateway 같은 팬 위키를 생각해보세요 — 수천 개의 상호 연결된 페이지가 등장인물, 장소, 사건, 언어를 다루며, 자원봉사 커뮤니티가 수년에 걸쳐 구축한 것입니다. LLM이 모든 교차 참조와 유지 보수를 처리하면서, 읽는 동안 비슷한 것을 개인적으로 구축할 수 있습니다.
비즈니스/팀용: LLM이 유지하는 내부 위키로, Slack 스레드, 회의 녹취록, 프로젝트 문서, 고객 통화에서 데이터를 공급받습니다. 업데이트를 검토하는 사람이 루프에 포함될 수도 있습니다. 팀에서 아무도 하고 싶어하지 않는 유지 보수를 LLM이 수행하기 때문에 위키가 최신 상태를 유지합니다.
경쟁 분석, 실사, 여행 계획, 강의 노트, 취미 심층 탐구 — 시간이 지남에 따라 지식을 축적하면서 흩어지지 않고 정리되기를 원하는 모든 것에 적용됩니다.
세 가지 계층이 있습니다:
원본 소스 — 큐레이션된 소스 문서 모음입니다. 기사, 논문, 이미지, 데이터 파일 등. 이것들은 불변입니다 — LLM은 이것들을 읽기만 하고 수정하지 않습니다. 이것이 여러분의 진실의 원천(source of truth)입니다.
위키 — LLM이 생성한 마크다운 파일 디렉토리입니다. 요약, 엔티티 페이지, 개념 페이지, 비교, 개요, 종합 등. LLM이 이 계층을 완전히 소유합니다. 페이지를 생성하고, 새 소스가 도착하면 업데이트하고, 교차 참조를 유지하며, 모든 것을 일관되게 유지합니다. 여러분은 읽고, LLM이 씁니다.
스키마 — LLM에게 위키가 어떻게 구조화되어 있는지, 관례가 무엇인지, 소스를 수집하거나, 질문에 답하거나, 위키를 유지할 때 어떤 워크플로를 따라야 하는지 알려주는 문서입니다(예: Claude Code의 CLAUDE.md 또는 Codex의 AGENTS.md). 이것이 핵심 설정 파일입니다 — LLM을 범용 챗봇이 아닌 규율 있는 위키 관리자로 만드는 것이 바로 이 파일입니다. 여러분의 도메인에 맞는 것을 알아가면서 LLM과 함께 시간이 지남에 따라 공동 발전시킵니다.
수집(Ingest). 새 소스를 원본 모음에 넣고 LLM에게 처리하라고 지시합니다. 예시 흐름: LLM이 소스를 읽고, 핵심 내용을 여러분과 논의하고, 위키에 요약 페이지를 작성하고, 인덱스를 업데이트하고, 위키 전체에 걸쳐 관련 엔티티 및 개념 페이지를 업데이트하고, 로그에 항목을 추가합니다. 하나의 소스가 10~15개의 위키 페이지에 영향을 줄 수 있습니다. 개인적으로 저는 소스를 하나씩 수집하면서 관여하는 것을 선호합니다 — 요약을 읽고, 업데이트를 확인하며, LLM에게 무엇을 강조할지 안내합니다. 하지만 감독을 줄이고 여러 소스를 일괄 수집할 수도 있습니다. 여러분의 스타일에 맞는 워크플로를 개발하고 향후 세션을 위해 스키마에 문서화하는 것은 여러분의 몫입니다.
쿼리(Query). 위키에 대해 질문합니다. LLM이 관련 페이지를 검색하고, 읽고, 인용과 함께 답변을 종합합니다. 답변은 질문에 따라 다양한 형태를 취할 수 있습니다 — 마크다운 페이지, 비교 표, 슬라이드 덱(Marp), 차트(matplotlib), 캔버스. 중요한 통찰: 좋은 답변은 새 페이지로 위키에 다시 저장할 수 있습니다. 여러분이 요청한 비교, 분석, 발견한 연결 — 이것들은 가치가 있으며 채팅 히스토리 속으로 사라져서는 안 됩니다. 이렇게 하면 여러분의 탐색이 수집된 소스처럼 지식 베이스에 복리로 축적됩니다.
린트(Lint). 주기적으로 LLM에게 위키 상태 점검을 요청합니다. 확인할 항목: 페이지 간 모순, 새로운 소스가 대체한 오래된 주장, 인바운드 링크가 없는 고아 페이지, 언급되었지만 자체 페이지가 없는 중요 개념, 누락된 교차 참조, 웹 검색으로 채울 수 있는 데이터 공백. LLM은 조사할 새 질문과 찾아볼 새 소스를 제안하는 데 능합니다. 이것이 위키가 성장하면서 건강을 유지하게 합니다.
두 개의 특별한 파일이 위키가 성장함에 따라 LLM(그리고 여러분)이 위키를 탐색하는 것을 돕습니다. 각각 다른 목적을 가집니다:
index.md는 콘텐츠 지향적입니다. 위키의 모든 것을 목록화한 카탈로그입니다 — 각 페이지에 링크, 한 줄 요약, 그리고 선택적으로 날짜나 소스 수 같은 메타데이터가 포함됩니다. 카테고리별(엔티티, 개념, 소스 등)로 정리됩니다. LLM은 매 수집 시 이것을 업데이트합니다. 쿼리에 답할 때, LLM은 먼저 인덱스를 읽어 관련 페이지를 찾은 다음 해당 페이지를 자세히 살펴봅니다. 이 방식은 중간 규모(약 100개 소스, 수백 개 페이지)에서 놀랍도록 잘 작동하며, 임베딩 기반 RAG 인프라의 필요성을 없앱니다.
log.md는 시간순입니다. 무엇이 언제 일어났는지에 대한 추가 전용 기록입니다 — 수집, 쿼리, 린트 과정. 유용한 팁: 각 항목이 일관된 접두사로 시작하면(예: ## [2026-04-02] ingest | 기사 제목), 로그를 간단한 유닉스 도구로 파싱할 수 있습니다 — grep "^## \[" log.md | tail -5로 마지막 5개 항목을 확인할 수 있습니다. 로그는 위키 발전의 타임라인을 제공하고, LLM이 최근에 무엇이 완료되었는지 이해하는 데 도움을 줍니다.
어느 시점에서 LLM이 위키를 더 효율적으로 운영하도록 돕는 작은 도구를 만들고 싶을 수 있습니다. 위키 페이지에 대한 검색 엔진이 가장 명백한 것입니다 — 소규모에서는 인덱스 파일로 충분하지만, 위키가 성장하면 적절한 검색이 필요합니다. qmd가 좋은 선택입니다: 하이브리드 BM25/벡터 검색과 LLM 재순위를 갖춘, 모든 것이 기기 내에서 동작하는 마크다운 파일용 로컬 검색 엔진입니다. CLI(LLM이 셸로 호출 가능)와 MCP 서버(LLM이 네이티브 도구로 사용 가능) 모두 제공합니다. 더 간단한 것을 직접 만들 수도 있습니다 — 필요에 따라 LLM이 단순한 검색 스크립트를 바이브 코딩하는 것을 도와줄 수 있습니다.
Obsidian Web Clipper는 웹 기사를 마크다운으로 변환하는 브라우저 확장 프로그램입니다. 소스를 원본 모음에 빠르게 넣는 데 매우 유용합니다.
이미지를 로컬에 다운로드하세요. Obsidian 설정 → 파일 및 링크에서 "첨부 파일 폴더 경로"를 고정 디렉토리(예: raw/assets/)로 설정합니다. 그런 다음 설정 → 단축키에서 "Download"를 검색하여 "현재 파일의 첨부 파일 다운로드"를 찾고 단축키(예: Ctrl+Shift+D)를 바인딩합니다. 기사를 클리핑한 후 단축키를 누르면 모든 이미지가 로컬 디스크에 다운로드됩니다. 이것은 선택 사항이지만 유용합니다 — 깨질 수 있는 URL에 의존하는 대신 LLM이 이미지를 직접 보고 참조할 수 있게 합니다. LLM은 인라인 이미지가 포함된 마크다운을 한 번에 읽을 수 없다는 점에 유의하세요 — 해결 방법은 LLM이 먼저 텍스트를 읽은 다음, 참조된 이미지의 일부 또는 전부를 별도로 보아 추가 맥락을 얻는 것입니다. 약간 번거롭지만 충분히 잘 작동합니다.
Obsidian의 그래프 뷰는 위키의 형태를 보는 가장 좋은 방법입니다 — 무엇이 무엇과 연결되어 있는지, 어떤 페이지가 허브인지, 어떤 것이 고아인지.
Marp는 마크다운 기반 슬라이드 덱 형식입니다. Obsidian에 플러그인이 있습니다. 위키 콘텐츠에서 직접 프레젠테이션을 생성하는 데 유용합니다.
Dataview는 페이지 프런트매터에 대해 쿼리를 실행하는 Obsidian 플러그인입니다. LLM이 위키 페이지에 YAML 프런트매터(태그, 날짜, 소스 수)를 추가하면, Dataview가 동적 테이블과 목록을 생성할 수 있습니다.
위키는 그저 마크다운 파일의 git 저장소입니다. 버전 히스토리, 브랜칭, 협업을 무료로 얻습니다.
지식 베이스를 유지하는 데 있어 지루한 부분은 읽기나 사고가 아닙니다 — 기록 관리입니다. 교차 참조 업데이트, 요약 최신 상태 유지, 새 데이터가 이전 주장과 모순될 때 표시, 수십 개 페이지에 걸친 일관성 유지. 유지 보수 부담이 가치보다 빠르게 증가하기 때문에 사람들은 위키를 포기합니다. LLM은 지루해하지 않고, 교차 참조 업데이트를 잊지 않으며, 한 번에 15개 파일을 처리할 수 있습니다. 유지 보수 비용이 거의 0이기 때문에 위키가 유지됩니다.
사람의 역할은 소스를 큐레이션하고, 분석을 지시하고, 좋은 질문을 하며, 이 모든 것이 의미하는 바에 대해 사고하는 것입니다. LLM의 역할은 나머지 전부입니다.
이 아이디어는 본질적으로 **바니바 부시(Vannevar Bush)의 메멕스(Memex, 1945)**와 관련이 있습니다 — 문서 간 연상적 경로가 있는 개인적이고 큐레이션된 지식 저장소. 부시의 비전은 웹이 된 것보다 이것에 더 가까웠습니다: 사적이고, 능동적으로 큐레이션되며, 문서 간의 연결이 문서 자체만큼 가치 있는. 그가 해결하지 못한 부분은 누가 유지 보수를 하는가였습니다. LLM이 그것을 처리합니다.
이 문서는 의도적으로 추상적입니다. 특정 구현이 아닌 아이디어를 설명합니다. 정확한 디렉토리 구조, 스키마 관례, 페이지 형식, 도구 — 이 모든 것은 여러분의 도메인, 선호도, 그리고 선택한 LLM에 따라 달라질 것입니다. 위에서 언급된 모든 것은 선택 사항이며 모듈식입니다 — 유용한 것을 골라 쓰고, 필요 없는 것은 무시하세요. 예를 들어: 소스가 텍스트 전용이라면 이미지 처리가 전혀 필요 없습니다. 위키가 충분히 작다면 인덱스 파일만으로 충분하고 검색 엔진이 필요 없습니다. 슬라이드 덱은 관심 없고 마크다운 페이지만 원할 수도 있습니다. 완전히 다른 출력 형식 세트를 원할 수도 있습니다.
이것을 사용하는 올바른 방법은 여러분의 LLM 에이전트와 공유하고, 함께 협력하여 여러분의 필요에 맞는 버전을 구체화하는 것입니다. 이 문서의 유일한 역할은 패턴을 전달하는 것입니다. 나머지는 LLM이 알아서 할 수 있습니다.