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

(gist.github.com/karpathy)

45P by GN⁺ 13시간전 | ★ favorite | 댓글 3개

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이 담당

이 문서의 성격

이 문서는 의도적으로 추상적으로 작성됨 — 특정 구현이 아닌 아이디어 자체를 전달하는 것이 목적
디렉터리 구조, 스키마 컨벤션, 페이지 포맷, 도구 등 세부 사항은 도메인·선호도·LLM에 따라 달라짐
모든 구성 요소는 선택적·모듈식 — 필요한 것만 활용하고 필요 없는 것은 무시
LLM 에이전트와 공유한 뒤 함께 각자의 필요에 맞는 버전을 구체화하는 방식으로 사용을 권장

▲

stadia 2시간전 [-]

별거 없던 기본 볼트 초기화 하고 저 파일 하나 읽게 하고서 이 아이디어를 구체화 하고 싶다고 이야기 하니 superpowers 의 브레인스톰 스킬과 함께 전체 틀을 잡고서 CLAUDE.md 와 옵시디언 플러그인 설정까지 완료했습니다.

답변달기

▲

xguru 13시간전 [-]

이거를 활용한 Farzapedia: 일기·메모·메시지 2,500건으로 만든 개인 Wikipedia

LLM을 활용해 일기, Apple Notes, iMessage 대화 2,500개 항목을 입력으로 400개의 상세 위키 문서를 자동 생성
친구, 스타트업, 관심 연구 분야, 좋아하는 애니메이션과 그 영향까지 포함하며, 백링크(backlink)로 상호 연결
위키는 개인 열람용이 아닌 에이전트가 활용하는 지식 베이스로 설계해, 파일 구조와 백링크가 에이전트가 크롤링하기 용이한 형태
Claude Code를 위키에 연결하고 index.md를 진입점으로 삼아 쿼리 시 에이전트가 필요한 페이지를 직접 탐색하는 방식으로 동작
활용 예시: 새 랜딩 페이지 작업 시 "최근 영감을 받은 이미지와 영화를 참고해 카피와 디자인 아이디어를 줘" 라고 요청하면, 에이전트가 Studio Ghibli 다큐 기반 "철학" 문서, YC 기업 랜딩 페이지 스크린샷이 담긴 "경쟁사" 문서, 저장해둔 1970년대 Beatles 굿즈 이미지까지 종합해 답변 제공
1년 전 RAG 기반으로 유사 시스템을 구축했으나 성능이 좋지 않았고, 에이전트가 파일 시스템을 통해 직접 탐색하는 방식이 훨씬 효과적
새 항목(기사, 영감 이미지, 미팅 노트 등) 추가 시 시스템이 관련 2~3개 기존 문서를 자동 업데이트하거나 새 문서를 생성

Karpathy가 밝힌 LLM Wiki 기반 개인화의 4가지 장점

위 Farzapedia를 LLM Wiki 트윗의 좋은 실사례로 언급하며, "사용할수록 알아서 좋아진다"는 기존 AI 개인화 방식과 비교해 이 접근법의 장점을 4가지로 정리
명시성(Explicit): 메모리 결과물이 위키 형태로 명확히 존재하며, AI가 무엇을 알고 모르는지 직접 확인·관리 가능 - 지식이 불투명한 시스템 내부에 묻히지 않고 눈에 보이는 형태로 존재
데이터 소유권(Yours): 데이터가 특정 AI 제공업체 시스템이 아닌 로컬 컴퓨터에 저장되며, 추출 불가능한 형태로 잠기지 않아 정보에 대한 완전한 통제권 유지
파일 우선(File over app): 메모리가 마크다운, 이미지 등 범용 포맷의 파일 모음으로 구성되어 다양한 도구·CLI와 호환 가능 — 에이전트가 Unix 툴킷 전체를 적용할 수 있으며, Obsidian 등 원하는 인터페이스로 열람 가능
AI 선택 자유(BYOAI): Claude, Codex, OpenCode 등 원하는 AI를 자유롭게 연결 가능 — 오픈소스 AI를 위키로 파인튜닝해 데이터를 참조하는 것을 넘어 가중치 자체에 개인 지식을 내재화하는 것도 원칙적으로 가능
이 방식이 가장 간단한 방법은 아니며 파일 디렉터리 관리가 필요하지만, 에이전트가 이 과정을 상당 부분 도와줄 수 있음
"에이전트 활용 능력(agent proficiency)은 21세기의 핵심 스킬" 이라고 강조하며, 영어로 지시하면 컴퓨터 작업을 대신 처리하는 이 도구를 직접 경험해볼 것을 권장