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

• 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 에이전트와 공유한 뒤 함께 각자의 필요에 맞는 버전을 구체화하는 방식으로 사용을 권장

[GN⁺]

Hacker News 의견들

• 이 접근이 결국 모델 붕괴(model collapse) 로 이어질 것 같음
  Nature 논문을 보면, LLM이 문서를 작성할수록 기존의 정확한 정보를 점점 덜 간결하게 재작성하는 식으로 품질이 누적 저하됨
  Karpathy가 이 문제를 못 본다는 게 놀라움. AI 극단주의자들은 뭔가 ‘정상적인 감각’을 잃은 듯한 느낌이 있음
  LLM이 만든 결과보다 “내가 쓴 비법 소스”를 강조하고 싶어질 때, 왜 그런지 스스로 물어봐야 함

  • 그 글은 LLM을 훈련하는 게 아니라, 이미 학습된 모델(ChatGPT나 Claude 등)을 이용해 개인용 위키를 작성하는 내용임
  • Karpathy의 댓글이 플래그로 사라졌는데, Claude가 쓴 장문의 조롱 섞인 문단을 그대로 붙여넣은 형태였음
    그가 그런 식으로 반응한 게 실망스러움. “인간적인 말을 할 수 없다면 차라리 말하지 말자”는 말이 떠오름
    많은 똑똑한 사람들이 ‘기계 속 유령’을 보고 인간적인 감각을 잃어가는 듯함
    Ezra Klein이 쓴 “I Saw Something New in San Francisco” 글이 이 현상을 잘 짚었음
  • 나는 self-updating HTML 파일을 만드는 실험을 해봤는데, 이 저장소처럼 간단한 프롬프트만으로도 순환 없이 꽤 잘 작동했음
  • 내 경험상 LLM은 claude.md 하나도 제대로 유지하지 못함. 위키 전체는 더 불가능함

• 나는 ‘관리 중심’ 접근으로 비슷한 걸 만들고 있음
  작업공간 전반의 기억을 태스크나 프로젝트와 연결하고, SPA 인터페이스로 실시간 제어함
  hmem 프로젝트 참고 가능
  모델이 연구 모드로 전환해 내부 지식을 정리하도록 시도했지만, 결국 LLM 수프처럼 혼란스러워짐
  코딩 프로젝트에서는 명확한 요구사항, 반복적 개선, 잘 문서화된 코드가 가장 효과적이었음. 기억이 너무 많아지면 오히려 오류가 늘어남

• 이건 결국 문제를 미루는 것 같음
  위키를 유지하려면 LLM이 매번 원본 대신 위키를 다시 읽어야 하고, 그 과정에서 2차 오류가 누적됨
  차라리 10M 컨텍스트나 1000tps급 차세대 모델이 나오면 이런 접근은 무의미해질 것 같음

  • 이미 1M 컨텍스트 모델이 있지만, 20만~30만 토큰쯤에서 기억 손실이 시작됨. 10M 컨텍스트라도 근본적 한계는 같음
  • 나는 Obsidian 기반 시스템을 직접 만들어서 구조화된 스키마를 덧씌워 사용 중임
    이 중간 계층이 설계 의도를 포착하고 실제 구현과의 괴리를 파악하는 데 매우 유용함
    완전히 자율적인 자기참조형 시스템은 가치가 없다고 봄. 진짜 가치는 인간이 “이건 이렇게 작동해야 한다”고 개입할 수 있는 구조에 있음
    결국 이런 실험들은 흥미롭지만 현실적으로 무의미함. 대형 모델 제공자들이 훨씬 빠르게 발전하고 있으니, 지금은 단순한 기본형을 쓰는 게 낫다고 생각함
  • “다음 세대 모델이 다 해결할 것”이라는 논리는 맞지만, 그걸 믿으면 아무것도 만들지 않게 됨
  • 목표는 모든 컨텍스트를 유지하는 게 아니라, 질의 가능한 메모리를 만드는 것임. 일종의 아이디어용 데이터 레이크처럼
  • 지금은 흥미로운 논문 몇 편을 요약하는 용도지만, 미래에는 한 분야 전체를 몇 편으로 압축할 수 있는 지식 응축 도구가 될 수 있음

• 이 아이디어는 1960년 Licklider의 “Man-Computer Symbiosis” 에세이를 떠올리게 함
  인간이 목표를 설정하고, 컴퓨터는 가설을 모델로 바꿔 검증하며, 반복적 계산을 담당하는 지능 증폭(Intelligence Amplification) 개념임
  원문 링크 참고

  • 그는 이미 공동 작업용 디스플레이 개념을 예견했음. 사람이 손으로 그린 그래프를 컴퓨터가 인식하고, 즉시 정제된 형태로 표시하는 식의 상호작용을 상상했음

• 관련 아이디어를 구현한 시스템 목록이 여기에 있음
  나는 commonplace라는 LLM 기반 지식베이스를 운영 중임
  이 시스템은 이론 자체를 LLM이 읽고 실행할 수 있게 설계되어, 이론이 곧 런타임이 되는 구조임
  아직 거칠지만 나에게는 잘 맞는 방식임

• 나는 코드베이스 전용으로 비슷한 도구를 만들었음
  llmdoc은 파일 변경을 해시로 감지하고, LLM이 각 파일을 설명하는 단일 자산으로 요약 캐시함
  CLI로 접근 가능하며, 코드 탐색 속도가 크게 향상됨

• 이건 사실상 RAG 구조임
  벡터 DB는 없지만, 의미적 연결 인덱스를 만들고 계층적 구조를 구성해 검색을 돕는 점에서 동일함
  나는 atomic 프로젝트를 만들고 있는데, 위키 합성과 비슷한 아이디어를 적용한 AI 지식베이스임

  • RAG는 임베딩이 필수는 아님. 단순히 grep 검색으로도 충분히 구현 가능함
  • 개인용 KB에는 Multimodal KB + Agentic RAG 조합이 적합하다고 봄
    DocMason을 예로 들면, PPT나 Excel의 다이어그램을 추출해 Codex 같은 에이전트가 분석하도록 함
  • 단순히 “RAG일 뿐”이라고 보기엔 아님. 여기서는 LLM이 위키를 직접 작성하고 유지하며, 백링크를 만들고 불일치를 검사함
    이는 검색이 아니라 지식 합성에 가까움. 마치 LLM이 스스로 Zettelkasten을 관리하는 느낌임
    프로젝트가 흥미로워서 꼭 살펴볼 예정임
  • 이런 앱에 대해 “몇 가지 의문이 있다”로 시작했으면 좋았을 듯함
    나도 LLM-WIKI 개념을 오래 생각해왔는데, OP는 훨씬 깊게 파고든 듯함. 진짜 두 번째 두뇌로 발전하길 기대함
  • 사실 이건 Copilot의 custom instruction 파일과 유사함
    copilot-instructions.md 문서처럼, LLM이 참조할 지침을 담는 구조임

• 나도 회사 프로젝트에서 비슷한 시도를 했음
  번아웃과 가족 간병으로 집중력이 떨어지자, 멀티에이전트 워크플로우에 많은 부분을 위임함
  Obsidian 기반의 마크다운 위키를 중심으로 작동하지만, 결과적으로 새로운 형태의 기술 부채가 생김 — 마치 뇌의 일부가 비어 있는 느낌임
  그래도 이 위키 워크플로우는 너무 중독적이라 멈추기 어려움

  • 나도 ‘깊이 생각하는 능력’ 을 잃을까 걱정됨
  • 잘못하고 있는 건 아님. 다만 일정 복잡도를 넘으면 에이전트가 위키를 유지하지 못하고, 개발자도 전체를 이해하지 못하게 됨
  • 문서 작성의 진짜 가치는 결과물이 아니라, 작성 과정에서 사고가 정리되는 것임
    LLM이 아무리 좋은 결과를 내도, 개인 위키에서는 그 과정이 더 중요함
  • 생각할 시간을 되찾으려면 오프라인 취미를 가져보길 권함
    나는 휴대폰 없이 산책하거나 수영을 하며 머리를 비움. 신체 피로와 정신 피로는 다른 종류라서 도움이 됨

• 이런 접근이 주목받는 게 반가움
  하지만 문서와 구조화된 데이터(작업 항목, ADR 등) 를 섞으면 마크다운만으로는 질의가 어려움
  AGENTS.md 방식은 폴더 규칙을 LLM에 학습시켜 해결하지만, 데이터가 복잡해지면 한계가 옴
  그래서 나는 Binder를 개발 중임
  구조화된 DB에 데이터를 저장하되, 양방향 동기화된 마크다운으로 렌더링함
  LSP로 자동완성과 검증을 제공하고, 에이전트나 스크립트는 CLI나 MCP를 통해 동일 데이터에 접근함

• 나는 VS Code용 AS Notes를 만들었음
  asnotes.io에서 확인 가능함
  개인 지식관리 시스템의 기능을 VS Code에 통합해, 마크다운과 위키링크를 쉽게 작성·연결·업데이트할 수 있음
  mermaid나 LaTeX 렌더링도 지원함
  이렇게 하면 AI 대화의 결과를 마크다운으로 영구 보존할 수 있어, 단순한 Copilot보다 더 많은 가치를 얻는 느낌임

[huturufu]

openclaw내에 내가 구현하려던게 나왔네. 가져다써야지

[stadia]

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

[xguru]

이거를 활용한 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세기의 핵심 스킬" 이라고 강조하며, 영어로 지시하면 컴퓨터 작업을 대신 처리하는 이 도구를 직접 경험해볼 것을 권장

[dkmin]

공유 감사합니다. 돌려봤는데 놀랍습니다.
커뮤니티에서 계속 더 개선된 방법들이 나올 것으로 예상됩니다