콘텐츠로 이동

LLM 위키

LLM을 활용해 개인 지식 베이스를 만드는 하나의 패턴입니다.

이 문서는 아이디어 파일입니다. OpenAI Codex, Claude Code, OpenCode / Pi 같은 LLM 에이전트에 그대로 붙여 넣어 사용할 수 있도록 작성했습니다. 목표는 전체 개념을 전달하는 것이고, 구체적인 구조와 운영 방식은 당신과 에이전트가 함께 채워 나가면 됩니다.

핵심 아이디어

대부분의 사람은 LLM과 문서를 사용할 때 RAG에 가까운 경험을 합니다. 파일 묶음을 업로드하면 LLM이 질문 시점에 관련 조각을 찾아 답을 생성합니다. 이 방식도 작동하지만, 매 질문마다 지식을 처음부터 다시 발견해야 합니다. 축적이 없습니다. 예를 들어 다섯 개의 문서를 함께 종합해야 하는 미묘한 질문을 던지면, LLM은 매번 관련 단편을 다시 찾고 다시 조합해야 합니다. 아무것도 쌓이지 않습니다. NotebookLM, ChatGPT 파일 업로드, 대부분의 RAG 시스템이 이런 방식입니다.

여기서의 아이디어는 다릅니다. 질문 시점에 raw 문서를 다시 검색하는 대신, LLM이 지속형 위키를 점진적으로 구축하고 유지보수합니다. 이 위키는 raw 소스와 사용자 사이에 놓이는 구조화되고 상호 연결된 Markdown 파일 집합입니다. 새 소스를 추가하면 LLM은 단순히 나중을 위해 인덱싱만 하지 않습니다. 소스를 읽고 핵심 정보를 추출해 기존 위키에 통합합니다. 엔티티 페이지를 갱신하고, 주제 요약을 수정하고, 새 데이터가 이전 주장과 충돌하는 지점을 표시하고, 현재까지의 합성을 강화하거나 뒤집습니다. 지식은 매 질문마다 다시 도출되는 것이 아니라 한 번 정리된 뒤 계속 최신 상태로 유지됩니다.

핵심 차이는 이것입니다. 위키는 지속되고 누적되는 산출물입니다. 교차 참조는 이미 연결되어 있고, 충돌은 이미 표시되어 있으며, 합성 결과는 지금까지 읽은 내용을 이미 반영하고 있습니다. 새 소스를 더하고 새 질문을 할수록 위키는 더 풍부해집니다.

실제로는 사용자가 위키를 직접 거의 쓰지 않습니다. LLM이 대부분을 작성하고 유지보수합니다. 사용자의 역할은 소스를 큐레이션하고, 탐색 방향을 정하고, 좋은 질문을 던지는 것입니다. 요약, 교차 참조, 파일링, 일관성 유지 같은 지식 베이스 운영의 귀찮은 일은 LLM이 담당합니다. 제 경우에는 한쪽에 LLM 에이전트를 열고 다른 쪽에 Obsidian을 띄워 둡니다. 대화를 바탕으로 LLM이 파일을 수정하고, 저는 실시간으로 링크를 따라가고 그래프 뷰를 확인하고 갱신된 페이지를 읽습니다. Obsidian이 IDE라면, LLM은 프로그래머이고, 위키는 코드베이스입니다.

이 패턴은 다양한 맥락에 적용할 수 있습니다.

  • 개인용: 목표, 건강, 심리, 자기개발을 장기간 추적하면서 일기, 아티클, 팟캐스트 메모를 구조화된 자기 이해로 누적
  • 리서치: 몇 주 또는 몇 달 동안 논문, 기사, 보고서를 읽으며 점진적으로 가설과 종합이 진화하는 위키 구축
  • 책 읽기: 장마다 내용을 정리하면서 인물, 테마, 사건 흐름, 연결 관계를 페이지로 분해해 풍부한 동반 위키 만들기
  • 팀/비즈니스: Slack 대화, 회의록, 프로젝트 문서, 고객 통화 내용을 받아 유지보수되는 내부 위키 구축
  • 경쟁사 분석, 실사, 여행 계획, 강의 노트, 취미 탐구: 시간이 지날수록 지식이 쌓이고, 그것을 흩어진 메모가 아니라 구조로 정리하고 싶은 모든 경우

아키텍처

세 개의 레이어가 있습니다.

Raw 소스: 선별한 원본 자료 모음입니다. 기사, 논문, 이미지, 데이터 파일 등이 여기에 들어갑니다. 이 레이어는 변경하지 않습니다. LLM은 읽기만 하고 수정하지 않습니다. 이것이 최종 출처입니다.

위키: LLM이 생성한 Markdown 파일 디렉터리입니다. 요약, 엔티티 페이지, 개념 페이지, 비교 문서, 개요, 종합 문서가 여기에 들어갑니다. 이 레이어는 전적으로 LLM이 관리합니다. 새 소스가 들어오면 페이지를 만들고, 기존 페이지를 갱신하고, 교차 링크를 유지하고, 전체 일관성을 맞춥니다. 사용자는 읽고, LLM은 씁니다.

스키마: CLAUDE.md나 AGENTS.md처럼 위키 구조, 규칙, ingest/질의/유지보수 워크플로를 LLM에게 설명하는 문서입니다. 이 문서가 핵심 설정 파일입니다. 일반 챗봇이 아니라 규율 있는 위키 관리자로 LLM을 작동하게 만듭니다. 어떤 방식이 잘 맞는지는 시간이 지나며 사용자와 LLM이 함께 다듬습니다.

운영 방식

Ingest
새 소스를 raw 컬렉션에 넣고, LLM에게 처리하라고 지시합니다. 예를 들어 LLM은 소스를 읽고, 핵심 포인트를 사용자와 논의하고, 위키에 요약 페이지를 만들고, 인덱스를 갱신하고, 관련 엔티티와 개념 페이지를 수정하고, 마지막으로 로그에 항목을 추가할 수 있습니다. 소스 하나가 10~15개 페이지에 영향을 줄 수도 있습니다. 저는 보통 소스를 한 번에 하나씩 ingest하면서 중간에 계속 개입하는 편입니다. 요약을 읽고, 수정 내용을 확인하고, 무엇을 더 강조할지 지시합니다. 하지만 원하면 여러 소스를 한꺼번에 덜 감독된 방식으로 ingest할 수도 있습니다. 어떤 워크플로가 맞는지는 사용자 스타일에 따라 다르며, 그 규칙을 스키마 문서에 기록해 두면 이후 세션에서 일관되게 재사용할 수 있습니다.

질의
사용자는 위키를 대상으로 질문합니다. LLM은 관련 페이지를 찾고 읽은 뒤, 출처와 함께 답을 종합합니다. 답의 형태는 질문에 따라 Markdown 페이지, 비교표, 슬라이드 덱(Marp), 차트(matplotlib), 캔버스 등으로 달라질 수 있습니다. 중요한 점은 좋은 답변은 다시 위키에 저장할 수 있다는 것입니다. 질문 과정에서 나온 비교, 분석, 발견한 연결은 가치 있는 산출물이고 채팅 기록 속에서 사라지면 안 됩니다. 이렇게 하면 탐색 과정도 ingest된 소스처럼 위키 안에 누적됩니다.

Lint
주기적으로 LLM에게 위키 건강 상태를 점검하게 합니다. 서로 충돌하는 페이지, 더 최신 소스에 의해 낡아진 주장, inbound 링크가 없는 orphan 페이지, 자주 언급되지만 별도 페이지가 없는 중요한 개념, 빠진 교차 참조, 웹 검색으로 메울 수 있는 데이터 공백을 찾게 할 수 있습니다. LLM은 추가로 조사할 질문이나 더 찾아볼 소스를 제안하는 데도 유용합니다. 이런 점검이 위키가 커질수록 구조를 건강하게 유지해 줍니다.

인덱싱과 로깅

위키가 커질수록 LLM과 사용자가 탐색하기 쉽게 도와주는 특수 파일 두 개가 있습니다. 역할은 서로 다릅니다.

index.md는 콘텐츠 중심 파일입니다. 위키의 모든 페이지를 링크와 한 줄 설명으로 정리한 카탈로그입니다. 필요하면 날짜나 소스 개수 같은 메타데이터도 붙일 수 있습니다. 엔티티, 개념, 소스 같은 범주별로 정리합니다. LLM은 ingest할 때마다 이 파일을 갱신합니다. 질문에 답할 때는 먼저 인덱스를 읽어 관련 페이지를 찾고, 그 다음 세부 페이지로 들어갑니다. 대략 100개 정도의 소스와 수백 개 페이지 규모에서는 이 방식이 놀랄 만큼 잘 작동하며, 임베딩 기반 RAG 인프라 없이도 충분할 수 있습니다.

log.md는 시간순 기록입니다. ingest, 질의, lint 결과처럼 언제 무엇이 일어났는지를 append-only 형식으로 남깁니다. 유용한 팁은 각 항목 제목을 일관된 접두 형식으로 시작하는 것입니다. 예를 들어 ## [2026-04-02] ingest | Article Title 같은 형식을 쓰면 grep "^## \[" log.md | tail -5 같은 간단한 유닉스 명령으로 최근 기록을 쉽게 조회할 수 있습니다. 이 로그는 위키가 시간에 따라 어떻게 진화했는지 보여 주고, LLM이 최근에 무슨 일이 있었는지 이해하는 데도 도움이 됩니다.

선택 사항: CLI 도구

어느 시점이 되면, LLM이 위키를 더 효율적으로 다루도록 돕는 작은 도구를 만들고 싶어질 수 있습니다. 가장 obvious한 것은 위키 검색 엔진입니다. 규모가 작을 때는 인덱스 파일만으로 충분하지만, 위키가 커지면 제대로 된 검색이 필요해집니다. qmd는 좋은 선택지입니다. Markdown 파일을 위한 로컬 검색 엔진으로, BM25와 벡터 검색, LLM reranking을 온디바이스에서 조합합니다. CLI도 제공하고 MCP 서버도 제공하므로, LLM은 셸 명령으로도 사용할 수 있고 네이티브 도구처럼도 사용할 수 있습니다. 필요하다면 더 단순한 검색 스크립트를 직접 만들어도 됩니다. 그런 정도는 LLM이 빠르게 함께 구현할 수 있습니다.

팁

  • Obsidian Web Clipper는 웹 아티클을 Markdown으로 바꿔 주는 브라우저 확장입니다. raw 소스를 빠르게 모을 때 유용합니다.
  • 이미지를 로컬로 저장하기. Obsidian 설정에서 "Attachment folder path"를 raw/assets/ 같은 고정 디렉터리로 지정하고, Hotkeys에서 "Download attachments for current file"에 단축키를 지정해 두면, 클리핑 후 이미지도 로컬 디스크에 저장할 수 있습니다. 이 작업은 선택 사항이지만 유용합니다. URL이 끊어져도 LLM이 이미지를 직접 볼 수 있기 때문입니다. 다만 LLM은 이미지가 포함된 Markdown을 한 번에 완전히 읽는 데 제한이 있으므로, 먼저 텍스트를 읽고 필요할 때 이미지를 따로 보게 하는 방식이 현실적입니다.
  • Obsidian 그래프 뷰는 위키의 형태를 보는 가장 좋은 방법입니다. 어떤 페이지가 허브인지, 어디가 orphan인지 빠르게 알 수 있습니다.
  • Marp는 Markdown 기반 슬라이드 포맷입니다. Obsidian 플러그인도 있으므로 위키 내용에서 바로 발표 자료를 만들 수 있습니다.
  • Dataview는 frontmatter를 질의할 수 있는 Obsidian 플러그인입니다. LLM이 태그, 날짜, 소스 수 같은 YAML frontmatter를 붙인다면 동적인 테이블과 목록을 만들 수 있습니다.
  • 위키는 결국 Markdown 파일로 이루어진 Git 저장소입니다. 버전 이력, 브랜치, 협업을 그대로 활용할 수 있습니다.

왜 이 방식이 작동하는가

지식 베이스를 유지하는 데서 지루한 부분은 읽기나 사고 자체가 아니라 운영입니다. 교차 참조를 갱신하고, 요약을 최신 상태로 유지하고, 새 데이터가 기존 주장과 어디서 충돌하는지 표시하고, 수십 개 페이지의 일관성을 유지하는 일이 어렵습니다. 사람은 유지 비용이 가치보다 빨리 커지기 때문에 위키를 포기합니다. 하지만 LLM은 지루해하지 않고, 교차 링크를 잊지 않으며, 한 번에 15개 파일을 건드리는 작업도 감당할 수 있습니다. 유지 비용이 거의 0에 가까워지기 때문에 위키는 실제로 유지됩니다.

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

이 아이디어는 Vannevar Bush의 Memex(1945)와도 닿아 있습니다. 개인이 관리하는 지식 저장소와 문서 사이의 연상적 연결을 중시하는 발상입니다. Bush의 비전은 오늘날의 웹보다 오히려 이런 형태에 가까웠습니다. 사적이고, 적극적으로 큐레이션되며, 문서 자체만큼 연결 관계가 중요합니다. 그가 풀지 못한 것은 누가 유지보수를 하느냐였고, 그 부분을 LLM이 맡을 수 있습니다.

메모

이 문서는 의도적으로 추상적입니다. 특정 구현이 아니라 패턴을 설명합니다. 정확한 디렉터리 구조, 스키마 규칙, 페이지 형식, 도구 선택은 도메인과 취향, 사용하는 LLM에 따라 달라집니다. 위에 언급한 모든 요소는 선택적이고 모듈식입니다. 필요한 것만 채택하고 나머지는 버리면 됩니다. 예를 들어 소스가 텍스트뿐이라면 이미지 처리가 필요 없을 수 있습니다. 위키가 충분히 작다면 인덱스 파일만으로 충분하고 검색 엔진은 필요 없을 수도 있습니다. 슬라이드 덱이 필요 없고 Markdown 페이지만 원할 수도 있습니다. 전혀 다른 출력 형식을 쓰고 싶을 수도 있습니다. 올바른 사용법은 이 문서를 LLM 에이전트와 공유한 뒤, 함께 당신에게 맞는 형태로 구체화하는 것입니다. 이 문서의 역할은 패턴을 전달하는 데 있고, 나머지는 LLM이 함께 채워 나가면 됩니다.