서론: 왜 LLM Wiki인가
ChatGPT나 Claude는 강력하지만 내 컨텍스트를 모릅니다.
어제 논의한 내용을 오늘 다시 설명하고, 같은 프로젝트 설정을 매번 복사하고, 10번 읽은 기술 노트를 다시 검색해야 했던 경험이 있다면 이 글이 해결책입니다.
2026년 현재, LLM을 개인 지식 시스템으로 쓰는 방법은 세 가지입니다.
- 단방향 QA — LLM에 물어보고 답만 듣는 전통적 방식
- RAG (Retrieval-Augmented Generation) — 문서 저장소 + 벡터 검색
- LLM Wiki — 지식 한 번 축적, 영구 유지, 지속 성장 (본 글 주제)
1. LLM Wiki가 해결하는 3가지 근본 문제
문제 1: 지식 소멸
LLM 채팅은 세션이 끝나면 지식도 사라집니다. 중요한 인사이트, 코드 스니펫, 디버깅 기록이 모두 검색 불가능한 채로 증발합니다.
문제 2: 반복 질문
RAG는 매번 원천 문서부터 재검색, 재요약합니다. 같은 내용을 5번 물으면 5번 토큰을 소모합니다.
문제 3: 지식 단절
프로젝트 A에서 배운 교훈이 프로젝트 B에 반영되지 않습니다. 조직도 개인도 동일합니다.
LLM Wiki의 철학: 지식은 한 번 축적하면 영구 유지되고, 서로 연결되며, 계속 성장한다.
2. LLM Wiki 아키텍처: 3-Layer 구조
Karpathy가 제안한 LLM Wiki 패턴은 3-Layer 아키텍처로 구성됩니다.
wiki/
├── SCHEMA.md # 규칙, 구조, 태그 분류
├── index.md # 목차 + 각 페이지 1줄 요약
├── log.md # 모든 작업 로그 (순차 추가)
├── raw/ # Layer 1: 원천 자료 (변경 불가)
│ ├── articles/ # 웹 기사, 클리핑
│ ├── papers/ # 논문 (PDF, arXiv)
│ ├── transcripts/ # 회의록, 인터뷰
│ └── assets/ # 이미지, 다이어그램
├── entities/ # Layer 2: 엔티티 (사람, 조직, 제품)
├── concepts/ # Layer 2: 개념/주제 페이지
├── comparisons/ # Layer 2: 비교 분석
└── queries/ # Layer 2: 저장할 만한 질문 응답
Layer 1 — Raw Sources (원천 자료)
변경 불가능한 원천 자료 저장소입니다. 에이전트가 읽지만 절대 수정하지 않습니다.
- URL에서 markdown 추출 → raw/articles/ 저장
- PDF 논문 → raw/papers/ 저장
- 각 파일은 source_url, ingested, sha256 메타데이터 포함
Layer 2 — The Wiki (지식 베이스)
에이전트가 생성/수정하는 마크다운 파일입니다. 모든 페이지는 상호 연결됩니다.
- entities/: 사람, 조직, 제품, 모델 소개
- concepts/: 개념 설명, 현재 상태, 열린 질문
- comparisons/: 대조 분석, 표 형식 권장
- queries/: 다시 파생하기 힘든 깊은 질문 응답
Layer 3 — The Schema (규칙)
SCHEMA.md가 Wiki의 규칙과 원칙을 정의합니다.
- 파일 네이밍 규칙, wikilink 사용 의무
- 프론트매터 양식 (title, tags, sources 등)
- 태그 분류학 — 10~20개 상위 태그 정의
- 페이지 생성/수정/분할/보관 기준
- 충돌 시 처리 절차 (Update Policy)
3. 실전 구축 가이드
3-1. 초기화
- Wiki 경로 결정 (기본 ~/wiki 또는 WIKI_PATH 환경 변수)
- 위 3-Layer 디렉토리 구조 생성
- 도메인 정의 — 이 Wiki가 무엇을 다루는지 구체적으로 명시
- SCHEMA.md 작성 — 규칙, 태그 분류, 프론트매터 양식
- index.md + log.md 초기화
- 첫 소스 ingest 시작
#!/bin/bash
# Wiki 초기화 스크립트
WIKI="${WIKI_PATH:-$HOME/wiki}"
mkdir -p "$WIKI"/{raw/{articles,papers,transcripts,assets},entities,concepts,comparisons,queries}
# SCHEMA.md, index.md, log.md 생성 후 도메인 설정 완료
3-2. SCHEMA.md 핵심
SCHEMA.md는 Wiki의 질 관리 시스템입니다. 프론트매터 양식 예시:
---
title: Page Title
created: YYYY-MM-DD
updated: YYYY-MM-DD
type: entity | concept | comparison | query
tags: [from taxonomy]
sources: [raw/articles/source-name.md]
confidence: high | medium | low
contested: true
contradictions: [other-page-slug]
---
3-3. Ingest 파이프라인
소스를 Wiki에흡수하는 6단계 프로세스:
- 원천 자료 캡처 — web_extract로 markdown 추출 또는 PDF 저장
- raw/에 원본 저장 (프론트매터 + sha256 포함)
- 사용자와 핵심 내용 논의 — 어떤 부분이 중요한지 확인
- 기존 페이지 검색 — search_files로 중복 확인
- 페이지 생성/수정 + wikilink 연결 (최소 2개)
- index.md 업데이트 + log.md에 작업 기록
3-4. 페이지 생성 기준
- 2개 이상 소스에서 언급된 경우 → 페이지 생성
- 1개 소스의 핵심 주제인 경우 → 페이지 생성
- 단순 언급/주석 → 페이지 생성X, 기존 페이지에 참조 추가
- 200줄 초과 → 분할하여 하위 주제로 분리
4. 데이터 축적 전략
4-1. 주기적 소스 수집
- RSS/블로그 모니터링 — blogwatcher CLI로 정기 폴링
- arXiv 검색 — 관심 분야 최신 논문 자동 트래킹
- YouTube/팟캐스트 — 자동 전사 후 transcript 저장
- 중요한 AI 대화 기록 — markdown으로 저장 후 ingest
- 주간 소스 수집 → 일괄 ingest → index/log 함께 업데이트
4-2. Cross-Reference (상호 참조)
강한 Wiki의 핵심은 링크 밀도입니다.
- 새 페이지 생성 시 최소 2개 이상의 wikilink 포함 필수
- 기존 페이지도 새 페이지를 거꾸로 링크하도록 수정
- Obsidian Graph View로 연결 밀도 시각화
4-3. sha256 기반 소스 변경 감지
---
source_url: https://example.com/article
ingested: 2026-06-20
sha256: a1b2c3d4e5f6...
---
(본문 내용)
재인제스트 시 hash를 재계산합니다. 일치하면 스킵, 불일치면 drift 발생으로 플래그 처리.
5. 활용: Wiki 기반 LLM 작업
5-1. Wiki Query
- index.md로 관련 페이지 식별
- 100페이지 이상이면 search_files로 키워드 검색 추가
- 관련 페이지 모두 읽어서 종합 답변 작성
- 답변이 충분히 가치 있으면 queries/에 저장
5-2. Obsidian 통합
Wiki 디렉토리는 Obsidian vault로 바로 동작합니다.
- [[wikilinks]]는 클릭 가능한 링크로 렌더링
- Graph View로 지식 네트워크 시각화
- Dataview 플러그인으로 프론트매터 기반 쿼리
- 예: TABLE tags FROM entities WHERE contains(tags, company)
5-3. 서버 환경 Obsidian 동기화
npm install -g obsidian-headless
ob login --email <email> --password '<password>'
ob sync-create-remote --name "LLM Wiki"
cd ~/wiki && ob sync-setup --vault "<vault-id>"
ob sync --continuous
5-4. Lint (자동 건강 점검)
- Orphan pages — 들어오는 wikilink가 없는 페이지
- Broken wikilinks — 존재하지 않는 페이지를 가리키는 링크
- Index completeness — index.md에 누락된 페이지
- Frontmatter validation — 필수 필드 누락, 태그 검증
- Stale content — 90일 이상 업데이트 안 된 페이지
- Contradictions — 주장이 충돌하는 페이지
- Quality signals — confidence: low 또는 single-source 페이지
6. 실제 운영 팁
- raw/는 절대 수정하지 않는다 — 수정은 Wiki 페이지에서
- 세션 시작 시 SCHEMA + index + log 항상 먼저 읽기
- 페이지 생성 후 index.md와 log.md 반드시 업데이트
- 200줄 초과 페이지는 분할 — 하위 주제로 분리
- 10개 이상 페이지를 수정할 때는 사용자에게 범위 확인
- log.md가 500라인 초과하면 log-YYYY.md로 회전
7. RAG vs LLM Wiki 비교
┌─────────────┬──────────────────────┬─────────────────────┐
│ 기준 │ RAG │ LLM Wiki │
├─────────────┼──────────────────────┼─────────────────────┤
│ 지식 저장 │ 원문 벡터화 │ 에이전트가 요약/종합 │
│ 검색 │ 매번 원문 재검색 │ 인덱스 기반 접근 │
│ 토큰 소모 │ 질문할 때마다 발생 │ 한 번 축적 후 재사용 │
│ 연결성 │ 벡터 유사도만 │ 명시적 wikilink │
│ 유지보수 │ 신규 문서 추가 │ Lint로 품질 관리 │
│ 적합한 규모 │ 대용량 문서 │ 중규모 지식 베이스 │
└─────────────┴──────────────────────┴─────────────────────┘
RAG와 Wiki는 상호 배타적이지 않습니다. 대규모 문서군은 RAG로, 정교한 지식은 Wiki로 — 하이브리드 패턴도 효과적입니다.
8. 마치며
LLM Wiki는 지식을 자산으로 전환하는 가장 실용적인 방법입니다.
ChatGPT에 의존하기만 하면 지식은 언제나 임차인입니다. 나만의 Wiki를 구축하면 지식의 소유자가 됩니다.
오늘 첫 소스를 ingest해서 시작하세요. 작은 Wiki도 1개월 후에는 예상치 못하게 강력한 지식 네트워크가 되어 있습니다.
