LLM이 읽고 쓰는 Obsidian vault 설계 (1편) — Karpathy LLM Wiki 패턴 적용기

TL;DR – 일반 PARA·Zettelkasten은 정제도가 섞이고 출처가 구분되지 않아 LLM과 잘 안 맞는다. – Karpathy의 LLM Wiki 패턴은 “LLM이 위키의 소유자”가 되는 3계층(Raw / Wiki / Schema) 설계다. – 내 Obsidian vault는 여기에 한 트랙을 더해 50 Wiki / 60 AI / Works의 3트랙 책임 분리로 운영한다. – 모든 topic 페이지는 confidence 프론트매터({score, sources_count, last_verified, contradictions})를 가진다. – 다음 편은 자동 ingest 파이프라인, 3편은 weekly lint + auto research 사이클.

ChatGPT한테 “이전에 NAS 마운트할 때 썼던 fstab 옵션 알려줘”라고 물어본 적이 있다. 당연히 모른다. 내 vault에 있는 정보니까. Claude Code한테 같은 걸 물어보면 잘 찾는다 — vault를 읽을 수 있으니까. 두 도구의 차이는 모델이 아니라 “내 컨텍스트에 접근할 수 있는가” 한 가지였다.

이게 LLM 외장두뇌(second brain)를 다시 생각하게 된 출발점이다. Notion에 잘 쌓아둔 노트도, Apple Notes에 흩뿌려진 메모도, LLM이 못 읽으면 죽은 자산이다. 반대로 LLM이 읽고·쓰고·정리할 수 있는 구조의 vault를 갖추는 순간, 모든 세션이 “이전 세션의 학습 위에” 올라간다.

이 시리즈는 그 vault를 어떻게 설계하고 운영하는지에 대한 3부작 기록이다.

• 1편 (이번): 왜 vault 구조부터 다시 짜야 하는가 — Karpathy의 LLM Wiki 패턴과 책임 분리 설계
• 2편: 자동 ingest 파이프라인 — 새 자료가 들어오면 어떻게 위키로 합성되는가
• 3편: weekly lint + auto research 사이클 — vault가 스스로 약점을 찾고 메우는 법

1. 왜 일반 노트 시스템은 LLM과 안 맞는가?

일반 노트 시스템은 정제도와 출처가 섞여 있어 LLM이 사실과 추측을 구분하지 못한다. PARA, Zettelkasten, 데일리 노트는 사람 혼자 읽을 때는 멀쩡하지만, LLM이 같이 읽기 시작하면 세 가지 문제가 드러난다.

문제 1 — 정제도가 섞여 있다. “오늘 회의 메모”, “PR 코드 리뷰 발췌”, “디버깅 중 잘못된 가설”이 같은 폴더에 있다. LLM은 이걸 동등한 가치로 읽기 때문에 잘못된 가설을 사실처럼 인용한다.

문제 2 — 무엇이 “최신 합의”인지 모른다. Zettelkasten은 작은 노트를 많이 만드는 게 미덕이라, 같은 주제에 3년 전 노트와 어제 노트가 공존한다. LLM은 둘 다 읽고 모순된 답을 합성한다.

문제 3 — 자동화가 불가능하다. 노트 한 장에 “사람이 쓴 단상”과 “ChatGPT 응답 복붙”이 섞이면, 도구가 “이 페이지 신뢰도 높여” 같은 자동 lint를 돌릴 수 없다. 사람 글과 LLM 글의 출처가 구별되지 않는 vault는 자동화의 진입 장벽이다.

여기까지가 일반 노트 시스템의 한계다. 다음 장은 이 문제를 풀기 위해 2026년 4월에 등장한 패턴을 소개한다.

2. Karpathy의 LLM Wiki 패턴이란 무엇인가?

LLM Wiki 패턴은 LLM이 마크다운 위키의 소유자가 되어 사용자가 큐레이션한 raw 자료를 점진적으로 통합·유지하는 구조다. 2026년 4월 3일, Andrej Karpathy가 GitHub Gist로 짧게 제안한 뒤 X 포스트 1,600만 조회, Gist 5,000 스타, 485 코멘트를 며칠 만에 기록하며 커뮤니티에 대규모 반향을 일으켰다(수치는 2026-05-27 기준). 슬로건은 이 한 줄이다.

“Obsidian은 IDE, LLM은 프로그래머, 위키는 코드베이스다.”

핵심은 소유권 분리다.

Karpathy 본인은 자기 위키를 LLM이 거의 모든 페이지를 채운 상태로 운영한다고 밝혔다. 본인이 큐레이션한 raw 자료를 LLM이 위키로 컴파일하는 구조다.

여기까지가 패턴의 골격이다. 이제 RAG와 어떻게 다른지가 핵심 질문이다.

LLM Wiki와 RAG는 어떻게 다른가?

이 패턴이 RAG와 결정적으로 다른 지점:

대규모 검색이 필요하면 여전히 RAG가 맞다. GraphRAG나 영속 메모리 레이어를 갖춘 RAG도 누적적 큐레이션이 가능하므로, “LLM Wiki만 컴파운딩한다”는 단언은 과장이다. 하지만 개인 지식 5~10만 토큰 영역에서는 사전 정제된 마크다운 위키가 압도적으로 단순하고 투명하다. 1년 동안 같은 vault에 쌓는다고 가정하면, 잘 설계된 LLM Wiki는 365번의 통합을 거친 한 권의 책으로 자라난다.

3. vault를 어떻게 책임 분리할 것인가? — 3트랙 설계

3트랙 책임 분리는 vault를 50 Wiki(지식), 60 AI(세션 raw audit), Works(큐레이션 산출물)로 나누어 정제도·소유권·불변성을 페이지마다 명시하는 설계다. Karpathy의 원전은 깔끔하지만 한 가지 안 다룬 게 있다 — “LLM이 만든 raw 작업 로그”는 어디에 둘 것인가?

매일 Claude Code 세션을 10개 돌리면 raw 로그가 100KB 이상 쌓인다. 이걸 위키에 그대로 넣으면 노이즈로 오염되고, 안 남기면 나중에 “그때 그거 어떻게 했더라”가 영영 사라진다.

내 vault는 이 셋을 분리해서 운영한다.

vault/
├── 50 Wiki/          ← LLM 외장두뇌 (Karpathy 패턴 본체)
│   ├── raw/             원본 자료 (사람이 큐레이션)
│   ├── topics/          LLM이 합성한 주제 페이지
│   ├── entities/        LLM이 추출한 엔티티 카드 (사람/도구/회사)
│   └── lint-reports/    주간 자동 점검 결과
│
├── 60 AI/            ← AI 세션 raw audit (filterless)
│   ├── sessions/       모든 Claude/Codex/Antigravity 세션 raw 로그
│   ├── scratch/        정제 전 임시 출력 (TTL 30일)
│   ├── summaries/      promote된 세션 요약
│   └── prompts/        재사용 prompt 라이브러리
│
└── 10 Projects/<name>/Works/  ← 큐레이션 산출물 (프로젝트별, 50/60과 별도 위치)

각 트랙의 소유권과 불변성이 다르다:

이렇게 분리하니까 LLM한테 “wiki에서 답해줘”라고 하면 50 Wiki/만 읽고, “지난주 작업 어떻게 했었지”라고 하면 60 AI/를 본다. 검색 범위가 의도에 따라 좁혀진다.

3.1 50 Wiki/ — Karpathy 패턴 본체

핵심 동작 3가지는 슬래시 커맨드로 묶어두었다.

/wiki-ingest    — 새 자료(URL/PDF/텍스트)를 raw에 저장 → topics 페이지에 통합
/wiki-query     — 위키 검색 → 인용 포함 답변 → (새 지식이면) 페이지 저장
/wiki-lint      — 모순/오래된 정보/고아 페이지/누락된 상호 참조 점검

ingest는 append-only다. 기존 페이지를 덮어쓰지 않고 추가만 한다. 이게 LLM Wiki 패턴에서 가장 자주 어기는 원칙인데, 어기면 “이전에 합의했던 결론”이 다음 ingest에 슬쩍 지워진다.

append-only의 예외 처리 명백한 오기·잘못된 인용·보안상 삭제(예: 실수로 ingest된 토큰)는 예외로 인정한다. 단, 일반 ingest 흐름과 분리해서 사람 명시 커밋으로만 수행하고, 삭제 사유를 페이지 footer 또는 변경 로그에 1줄 남긴다.

append-only의 비대화 risk 추가만 하면 페이지가 무한히 커져 컨텍스트 윈도우 한계·검색 비용·읽기 latency가 함께 늘어난다. 운영 가드: ① 페이지 단위 토큰 상한(예: 8K 토큰)을 두고 초과 시 주제별로 분할, ② 분기별 “consolidation pass”로 LLM이 같은 주제의 중복 단락을 한 섹션으로 요약 갱신 (이때만 덮어쓰기 허용, 변경 로그 필수), ③ L1/L2 캐시 분리(자동 로드 메타만 L1에, 본체는 on-demand). 비대화는 막을 수 있는 문제지 패턴의 결함은 아니다.

3.2 60 AI/ — 세션 raw audit

매 Claude Code 세션이 끝나면 Stop hook이 자동으로 raw 로그를 남긴다. 단, Stop hook은 도구별로 기본 제공 여부가 다르다 — Claude Code는 ~/.claude/hooks/에 등록해야 동작하고, Codex/Antigravity는 셸 래퍼나 환경변수 설정이 추가로 필요할 수 있다. 기본 기능으로 오해하지 말고 도구별 문서 확인 후 셋업이 필요하다.

60 AI/sessions/<tool>/YYYY/MM/YYYYMMDD-HHMM-<slug>.md

이 폴더는 filterless audit다. 가치 있든 없든, 성공이든 실패든 전부 들어간다. 일주일 뒤에 “그때 NFS 마운트 어떻게 디버깅했더라” 검색하면 풀 transcript가 나온다. 실패의 발자국도 보존한다는 점이 핵심 — 같은 실패를 두 번 안 하기 위해서.

⚠️ 보안 trade-off raw 세션 로그에는 토큰·환경변수·내부 호스트명이 의도치 않게 섞일 수 있다. Stop hook에 secret-scanning 필터(gitleaks / 패턴 regex)를 두고, 적어도 OP_*/AWS_*/Bearer/JWT 패턴은 마스킹한 뒤 저장하기를 권장한다. 이게 없으면 60 AI/ 동기화 채널이 곧 시크릿 유출 채널이 된다.

이 중 재사용 가능한 절차가 발견되면 사람이 summaries/로 promote하고, 일반화된 지식이면 wiki-ingest로 50 Wiki/topics/에 합성한다. 흐름:

sessions/ (raw, 자동)
  ─ promote →  summaries/ (정제, 수동)
                  ─ wiki-ingest →  50 Wiki/topics/ (영구 지식)

3.3 Works/ — 큐레이션된 작업 산출물

60 AI/sessions/가 “모든” 세션 raw라면, Works/는 “가치 있는” 작업의 큐레이션 산출물이다. 30분 이상 의미 있는 작업을 했을 때만 작성한다. 이게 분리되어 있어야 “이 프로젝트의 의사결정 히스토리”를 LLM이 깔끔하게 추적할 수 있다.

4. frontmatter에 신뢰도를 어떻게 담는가?

topic 페이지마다 confidence 블록을 두어 score·sources_count·last_verified·contradictions를 데이터로 기록한다. 그러면 시간이 지나면 점수가 감쇠하고, 새 소스가 확인하면 강화된다.

내가 실제로 운영 중인 topic 페이지 frontmatter (핵심 블록만 표시):

---
title: Karpathy LLM Wiki 패턴
type: topic
# tags / sources / relationships 등은 생략
confidence:
  score: 10
  sources_count: 6
  last_verified: 2026-04-12
  contradictions: []
---

이 한 덩어리가 /wiki-lint의 입력이 된다. 자동 lint가 매주 일요일 새벽에 돌면서:

• last_verified가 60일 넘은 페이지 → “재검증 필요” 리포트
• sources_count == 1 → “소스 부족, 자료 추가 권장”
• contradictions가 비어있지 않으면 → “수동 검토 필요”

이런 출력이 자동으로 떨어진다. 점수 산정·재검증 리포트 같은 mechanical lint는 LLM 호출 0회다 — 단순히 YAML 파싱과 날짜 비교만 한다. 단, contradictions 필드를 채우는 작업은 LLM 단계가 별도로 필요하다. 모순 탐지 자체는 의미론적 판단이라 정규식으로 안 되기 때문이다. 그래서 운영은 두 층으로 갈라진다.

• 주간 mechanical lint (LLM 0회): 위 3가지 자동 리포트 생성
• 수동/주간 의미 lint (LLM 호출): 의심 페이지에 한해 모순·중복 탐지 후 contradictions 갱신

이렇게 분리하면 mechanical lint만으로도 vault의 약점이 다음 주 작업거리로 변환된다. (자동 lint와 그에 이어지는 auto research 사이클은 3편에서 자세히 다룬다.)

5. LLM 외장두뇌 vault의 5가지 설계 원칙은?

아래는 1~4장에서 도출된 원칙의 요약이다. 노트가 100개일 때도, 1,000개일 때도 같은 운영 비용으로 굴러가게 하는 다섯 가지.

1. Raw / Wiki 분리 — 원본은 불변, 위키는 점진적. 둘을 같은 폴더에 두지 않는다.
2. Append-only ingest — 기존 페이지 덮어쓰기 금지. 새 정보는 섹션 추가로만 (예외는 3.1 참조).
3. 소유권 명시 — 페이지마다 “사람이 쓴 것인지, LLM이 합성한 것인지” frontmatter로 구분.
4. 신뢰도 데이터화 — 모든 topic 페이지가 confidence 블록을 갖는다. mechanical lint는 LLM 0회, 의미 lint는 별도 단계.
5. 세션 raw audit 별도 트랙 — 60 AI/sessions/로 분리. wiki와 섞지 않고, secret-scanning 훅을 거친다.

이 다섯 가지만 지키면 vault는 사람의 손길이 줄어도 무너지지 않는다.

6. 다음 편 예고 — 자동 ingest 파이프라인

이번 편은 “구조를 왜 이렇게 짰는가”까지였다. 막상 굴려보면 가장 자주 만지는 건 ingest 파이프라인이다.

• URL 던지면 → raw 폴더에 자동 저장 → systemd path watch가 감지 → wiki-ingest 트리거 → topics에 합성
• PDF/이미지/회의록 → 어떻게 노이즈를 거르고 정제된 사실만 통합하는가
• 이미 자란 위키에 새 정보가 들어올 때 — 어떤 페이지를 터치하고, 어떤 페이지는 건드리지 않을 것인가

특히 LLM Wiki 패턴의 잘 알려진 실패 사례 중 하나가 “LLM-생성 링크 오염”이다 — 잘못된 wikilink가 다음 ingest에서 소스로 취급되는 사고. 이걸 어떻게 막는지가 2편의 핵심이다.

FAQ

Q1. LLM 외장두뇌(second brain)란 무엇인가? LLM이 직접 읽고·쓰고·정리할 수 있는 구조의 개인 지식 vault다. 일반 노트 앱과 달리 정제도와 출처가 페이지 레벨로 명시되어 있어 LLM이 사실과 추측을 구분할 수 있다.

Q2. LLM Wiki와 RAG 중 무엇을 써야 하나? 개인 지식 5~10만 토큰 규모면 LLM Wiki가 단순하고 투명하다. 자주 변하는 대용량 코퍼스면 RAG가 적합하다. 실전에서는 LLM Wiki 위에 RAG로 동적 청크를 보강하는 하이브리드가 일반적이다.

Q3. 왜 50 Wiki/와 60 AI/를 분리하는가? 정제된 지식과 raw 세션 로그를 같은 폴더에 두면 LLM이 잘못된 가설을 사실처럼 인용한다. 분리하면 “wiki에서 답해줘” / “지난주 작업 어떻게 했었지” 같은 의도별로 검색 범위가 좁혀진다.

Q4. Append-only ingest는 무슨 뜻인가? 새 자료를 통합할 때 기존 페이지를 덮어쓰지 않고 섹션 추가만 한다는 원칙이다. 이전 결론을 다음 ingest가 슬쩍 지우는 사고를 막는다. 명백한 오기나 보안상 삭제만 예외로 인정한다.

Q5. confidence 블록의 신뢰도 점수는 어떻게 계산하나? score(0~10)는 사람이 초기값을 부여하고, sources_count·last_verified·contradictions 세 기계 신호로 매주 자동 점검한다. 60일 이상 미검증이거나 소스가 1개뿐이면 lint가 재검증 작업으로 변환해 리포트한다.

참고 자료

• Andrej Karpathy — LLM Wiki Gist (2026-04-03 게시, 검증일 2026-05-27)
• Ar9av/obsidian-wiki — Karpathy 패턴을 8개 에이전트에 배포한 구현 사례
• rohitg00의 agentmemory 패턴 (LLM Wiki에 신뢰도 점수·타입드 엔티티 추출 추가)
• 본 시리즈 2편(예정): 자동 ingest 파이프라인
• 본 시리즈 3편(예정): weekly lint + auto research 사이클

관련 글

• Karpathy의 LLM Wiki 패턴 — RAG를 대체할 새로운 지식 관리 방법
• DESIGN.md — AI 에이전트를 위한 디자인 시스템이 온다
• 구글 스티치 2.0 사용법: AI로 앱 화면 만드는 무료 디자인 도구 총정리