LLM-Wiki - LLM을 활용하여 개인 지식저장소 구축 하기

1 week ago 3

(gist.github.com/karpathy)

Andrej Karpathy가 최근 자신은 코드보다 개인 지식 저장소 구축에 토큰을 더 많이 쓰고 있다며, 이 LLM 기반 위키를 생성하기 위한 아이디어 가이드 파일을 공개
에이전트에게 이 파일을 전달하면 알아서 위키를 생성하고, 사용법을 가이드 함
LLM이 직접 위키를 작성·관리하는 방식으로, 쿼리 시마다 원문에서 정보를 재추출하는 RAG 방식과 달리 지식이 점진적으로 축적되는 영속적 위키(persistent wiki) 를 구축
위키는 Obsidian 등의 도구로 열어두고 LLM이 마크다운 파일을 실시간으로 편집·업데이트하며, 사용자는 소싱과 질문에 집중하는 역할 분담 구조
새 소스를 추가할 때 LLM이 내용을 읽고 기존 위키에 통합·교차 참조하며, 단일 소스 처리 시 10~15개 위키 페이지를 업데이트할 수 있음
개인 건강·목표 관리, 연구, 독서 노트, 팀 내부 위키 등 지식이 시간에 걸쳐 축적되는 모든 영역에 적용 가능
위키 유지 관리의 핵심 장벽이었던 북키핑 비용을 LLM이 거의 0에 가깝게 낮춤으로써, 사람들이 포기하던 위키 관리 문제를 해결

핵심 아이디어

대부분의 LLM 문서 활용 방식은 RAG(Retrieval-Augmented Generation): 파일 컬렉션을 업로드하면 LLM이 쿼리 시 관련 청크를 검색해 답변을 생성하는 방식
- NotebookLM, ChatGPT 파일 업로드, 대부분의 RAG 시스템이 이 방식으로 동작
- 매번 지식을 새로 추출하며, 지식의 누적이 없음
LLM-Wiki의 접근 방식은 다름: LLM이 원문에서 직접 검색하는 대신 영속적 위키를 점진적으로 구축·유지
- 새 소스 추가 시 LLM이 내용을 읽고 핵심 정보를 추출하여 기존 위키에 통합
- 엔티티 페이지 업데이트, 토픽 요약 수정, 새 데이터와 기존 주장의 모순 표시, 합성 강화
위키는 영속적·복리 축적형 결과물(persistent, compounding artifact): 교차 참조가 이미 구성되어 있고, 모순은 이미 표시되었으며, 합성은 이미 반영된 상태
실제 사용 예: LLM 에이전트를 한쪽에, Obsidian을 반대편에 열어두고 LLM이 편집한 내용을 실시간으로 확인
- Obsidian = IDE, LLM = 프로그래머, 위키 = 코드베이스

적용 분야

개인: 목표, 건강, 심리, 자기개발 추적 — 저널, 기사, 팟캐스트 노트를 모아 구조화된 자아 기록 구축
연구: 수주~수개월에 걸쳐 논문, 기사, 보고서를 읽으며 진화하는 테제를 담은 포괄적 위키 구축
독서: 챕터별로 정리하며 등장인물, 테마, 플롯 실을 페이지로 구성 — Tolkien Gateway처럼 수천 개의 상호 연결 페이지를 개인 독자가 구축 가능
비즈니스/팀: Slack 스레드, 미팅 전사, 프로젝트 문서, 고객 통화로 LLM이 유지·관리하는 내부 위키 구성 가능
그 외 경쟁 분석, 실사(due diligence), 여행 계획, 강의 노트, 취미 심층 탐구 등 지식이 축적되는 모든 영역에 적용 가능

아키텍처 (3개 레이어)

원문 소스(Raw sources): 큐레이션된 소스 문서 컬렉션 — 기사, 논문, 이미지, 데이터 파일
- 변경 불가(immutable), LLM은 읽기만 하고 수정하지 않음
- 이 레이어가 진실의 원천(source of truth)
위키(The wiki): LLM이 생성하는 마크다운 파일 디렉터리 — 요약, 엔티티 페이지, 개념 페이지, 비교, 개요, 합성
- LLM이 이 레이어를 완전히 소유: 페이지 생성, 소스 추가 시 업데이트, 교차 참조 유지
- 사용자는 읽기만 하고, LLM이 작성
스키마(The schema): LLM에게 위키 구조, 컨벤션, 워크플로를 알려주는 설정 문서 (Claude Code의 경우 CLAUDE.md, Codex의 경우 AGENTS.md)
- LLM을 일반 챗봇이 아닌 체계적인 위키 관리자로 만드는 핵심 설정 파일
- 사용자와 LLM이 시간이 지남에 따라 함께 진화시킴

주요 작업(Operations)

인제스트(Ingest): 새 소스를 원문 컬렉션에 추가하고 LLM에게 처리를 지시
- LLM이 소스 읽기 → 핵심 내용 논의 → 위키에 요약 페이지 작성 → 인덱스 업데이트 → 관련 엔티티·개념 페이지 업데이트 → 로그 항목 추가
- 단일 소스가 10~15개 위키 페이지에 영향을 줄 수 있음
- 소스를 하나씩 처리하며 관여하거나, 감독을 줄이고 일괄 처리하는 방식 모두 가능
쿼리(Query): 위키를 대상으로 질문하면 LLM이 관련 페이지를 찾아 인용과 함께 답변 합성
- 답변은 마크다운 페이지, 비교 표, 슬라이드 덱(Marp), 차트(matplotlib), 캔버스 등 다양한 형태 가능
- 좋은 답변은 위키에 새 페이지로 다시 저장 가능 — 탐색 자체가 지식 베이스에 쌓임
린트(Lint): 주기적으로 LLM에게 위키 상태 점검 요청
- 점검 항목: 페이지 간 모순, 최신 소스에 의해 대체된 낡은 주장, 인바운드 링크 없는 고아 페이지, 자체 페이지 없는 중요 개념, 누락된 교차 참조, 웹 검색으로 채울 수 있는 데이터 공백

인덱싱 및 로깅

index.md: 콘텐츠 중심 파일 — 위키의 모든 페이지를 링크, 한 줄 요약, 메타데이터와 함께 카탈로그화
- LLM이 쿼리 응답 시 인덱스를 먼저 읽고 관련 페이지를 탐색
- ~100개 소스, 수백 개 페이지 규모에서 임베딩 기반 RAG 인프라 없이도 잘 작동
log.md: 시간순 기록 — 인제스트, 쿼리, 린트 통과 내역을 순서대로 기록
- 각 항목의 접두사를 일관되게 작성하면 Unix 도구로 파싱 가능
  - 예: ## [2026-04-02] ingest | Article Title → grep "^## \[" log.md | tail -5로 최근 5개 항목 확인

선택적 CLI 도구

위키가 성장하면 LLM이 더 효율적으로 작동할 수 있도록 소형 도구 구축 가능
qmd: 마크다운 파일을 위한 로컬 검색 엔진 — BM25/벡터 하이브리드 검색과 LLM 리랭킹, 모두 온디바이스
- CLI(LLM이 셸 아웃 가능) 및 MCP 서버(LLM이 네이티브 도구로 사용 가능) 지원
소규모라면 인덱스 파일만으로 충분하며, 필요에 따라 LLM의 도움으로 간단한 검색 스크립트 직접 제작 가능

팁 및 도구 활용법

Obsidian Web Clipper: 웹 기사를 마크다운으로 변환하는 브라우저 확장 — 소스를 원문 컬렉션에 빠르게 추가하는 데 유용
로컬 이미지 저장: Obsidian Settings → Files and links에서 첨부 폴더 경로 설정 후 단축키로 이미지를 로컬 디스크에 저장 가능
- LLM은 인라인 이미지가 포함된 마크다운을 한 번에 읽지 못하므로 텍스트를 먼저 읽은 뒤 이미지를 별도로 확인하는 방식으로 처리
Obsidian 그래프 뷰: 위키 전체 형태 파악 — 연결 관계, 허브 페이지, 고아 페이지 확인에 최적
Marp: 마크다운 기반 슬라이드 덱 포맷 — Obsidian 플러그인 제공, 위키 콘텐츠에서 직접 프레젠테이션 생성 가능
Dataview: 페이지 프론트매터를 대상으로 쿼리를 실행하는 Obsidian 플러그인 — LLM이 YAML 프론트매터(태그, 날짜, 소스 수)를 추가하면 동적 테이블과 리스트 생성 가능
위키는 마크다운 파일의 git 저장소 — 버전 기록, 브랜칭, 협업을 무료로 제공

작동 원리

지식 베이스 유지의 핵심 장벽은 독서나 사고가 아니라 북키핑(bookkeeping): 교차 참조 업데이트, 요약 최신화, 모순 표시, 수십 페이지에 걸친 일관성 유지
사람들이 위키를 포기하는 이유는 유지 관리 부담이 가치보다 빠르게 증가하기 때문
LLM은 지루함을 모르고, 교차 참조 업데이트를 잊지 않으며, 한 번에 15개 파일을 처리 가능 → 유지 관리 비용이 거의 0에 수렴
이 아이디어는 Vannevar Bush의 Memex(1945) 와 정신적으로 연관됨: 개인적이고 능동적으로 큐레이션되며, 문서 간 연결이 문서 자체만큼 가치 있는 지식 저장소
- Bush가 해결하지 못했던 "누가 유지 관리하는가" 문제를 LLM이 담당