작년에 제텔카스텐이란 책을 읽었다. 제텔카스텐(Zettelkasten)에서는 메모 하나에 하나의 생각을 적고 관련 있는 메모끼리 링크로 연결한다. 메모가 쌓일수록 메모 사이의 연결이 새로운 통찰을 만든다는 것이 주요 개념이다. 예를 들면 ‘인스타 DM 모음’ 메모에서 반복되는 질문을 ‘콘텐츠 아이디어’ 메모로 연결시키는 것이다.
책을 읽고 Obsidian에서 실천에 옮겼다. Obsidian은 로컬 마크다운 파일 기반의 노트 앱으로, 파일 간 연결을 만들고 그래프 뷰로 연결 관계를 시각화하는데 최적화된 앱이다.
옵시디언을 통해 제텔카스텐을 실천하며 인스타 콘텐츠 아이디어, 개발 공부 기록 등 약 180개 마크다운 파일이 쌓였고 열심히 연결도 했다.
이론적으로는 좋았지만 실제로는 유지가 어려웠다.
메모가 쌓이면 연결이 점점 끊어진다. 새 메모를 쓸 때마다 기존 메모 중 관련된 것을 찾아서 링크해야 하는데 매번 그러기는 쉽지 않다. 곧이서 소개할 Andrej Karpathy의 말을 빌리면:
The tedious part of maintaining a knowledge base is not the reading or the thinking — it’s the bookkeeping. Updating cross-references, keeping summaries current, noting when new data contradicts old claims, maintaining consistency across dozens of pages. Humans abandon wikis because the maintenance burden grows faster than the value.
지식 베이스 유지에서 지루한 건 읽기나 사고가 아니라 기록 관리다. 교차 참조 업데이트, 요약 최신화, 모순 기록, 일관성 유지. 유지보수 부담이 가치보다 빠르게 증가하기 때문에 인간은 위키를 포기한다.
정확히 내 상황이었다. 180개 파일이 있었지만 그래프 뷰에는 연결 없는 노드가 수두룩했고 메모간 연결을 통한 인사이트는 거의 만들어지지 않았다.
2026년 4월, Karpathy가 “LLM Wiki”라는 글을 올렸다.
ChatGPT에 파일을 첨부하거나 NotebookLM에 PDF를 올려본 적이 있을 것이다. 질문하면 그때그때 관련 부분을 찾아서 답해준다. 하지만 다섯 개 문서를 종합해야 하는 질문을 하면, 매번 그 조각들을 처음부터 찾아서 짜맞춘다. 어제 같은 질문을 했든 안 했든 상관없이 매번 새로 시작한다. 축적이 없다.
LLM Wiki는 다르다. LLM이 점진적으로 위키를 구축하고 유지한다. 새 소스가 들어오면 읽고 핵심을 추출해서 기존 위키에 통합하고, 교차 참조를 추가하고, 모순을 표시하고, 인덱스를 갱신한다. 지식이 한 번 정리된 뒤 최신 상태로 유지된다.
나도 이 글을 Claude Code에 붙여넣고 “내 옵시디언 볼트에 맞게 구축하자”고 했다. 이하는 그 과정이다.
기존에 쓰던 PARA 폴더 구조를 버리고 두 폴더로 교체했다:
raw/ 원본. 내가 넣은 것. LLM이 절대 수정 안 함.
wiki/ LLM이 소유. 종합된 지식.
index.md 전체 카탈로그
log.md 활동 로그
(위키 페이지들)폴더 분류를 버린 이유는 단순하다. LLM이 인덱스를 읽고 필요한 페이지를 찾아주면 폴더를 뒤질 필요가 없기 때문이다. “오늘 할 일이 뭐야?”라고 물으면 LLM이 위키에서 답한다.
raw와 wiki를 나눈 것은 원본을 보존하기 위해서다. LLM이 요약하면서 빠뜨리거나 왜곡할 수 있으니, 원본이 있으면 언제든 검증할 수 있고 스키마를 바꾸면 처음부터 다시 빌드할 수도 있다. raw에는 회의록, 웹 스크랩, DM 대화, 강연 녹취록 같은 원본이 들어가고, 짧은 것(아이디어, 한 줄 메모)은 raw 없이 바로 위키로 간다.
(글을 쓰면서 생각해보니 짧은 메모도 raw로 보냈어야했나라는 생각이 든다…)
위키의 구조, 규칙, 관례를 한 파일에 정의한다. Claude Code가 새 세션을 시작할 때마다 자동으로 읽도록 설정해두었다:
# 위키 시스템 가이드
## 구조
raw/ 사용자 입력 원본. LLM이 절대 수정하지 않는다.
wiki/ LLM 소유 합성 지식.
index.md 위키 페이지 카탈로그
log.md 활동 로그
attachments/ 이미지, PDF 등
## raw/ 규칙
- LLM은 raw/ 파일을 절대 수정/삭제하지 않는다.
- 프론트매터 불필요. 내용이 곧 원본이다.
## wiki/ 규칙
### 페이지 프론트매터
tags: [tag1, tag2]
sources: [raw 파일명 또는 외부 URL]
date: YYYY-MM-DD
updated: YYYY-MM-DD
### 크로스 레퍼런스
- 내부 링크: [[파일명]]
- 외부 링크: [설명](URL)
## 대화 중 위키 반영
대화에서 나온 좋은 분석, 비교, 인사이트는 위키 페이지로 저장한다.
## 할 일 관리
wiki/할 일.md는 살아있는 페이지다. 완료된 항목은 삭제한다.Claude Code에서는 /커맨드명으로 실행하는 자동화 스킬을 마크다운으로 정의할 수
있다. 세 개를 만들었다.
/dump은 위키에 정보를 넣는 방법이다. 떠오르는 생각, 회의 내용, URL 등을 던지면
알아서 처리한다. 짧은 입력(아이디어, 한 줄 메모)은 바로 위키로, 긴 입력(기사,
회의록)은 원본을 raw에 보존한 뒤 위키로 반영한다.
# Dump
사용자 입력을 위키 시스템에 저장한다.
## 워크플로우
1. 분류 판단:
- 짧은 입력: raw 건너뛰고 2번으로.
- 긴 입력: raw/에 먼저 저장.
- URL: 웹페이지 내용을 가져와서 긴 입력과 동일.
- 할 일: wiki/할 일.md에 append.
2. /ingest 스킬의 워크플로우에 따라 wiki에 반영한다.
3. 결과를 알려준다./ingest는 raw에 쌓인 파일을 읽어서 위키에 반영한다. Karpathy의 원문에서
“하나의 소스가 10-15개 위키 페이지에 영향을 줄 수 있다”는 부분이 반영된 핵심
부분이다. 인스타 콘텐츠 아이디어를 ingest하면 콘텐츠 전략, 콘텐츠 아이디어 목록,
릴스 기획 페이지가 동시에 업데이트될 수 있다.
# Ingest
raw/에 있는 파일을 읽어서 wiki에 반영한다. 하나의 소스가 여러 위키 페이지에
영향을 줄 수 있다.
## 워크플로우
1. 대상 결정 (log.md에서 미처리 파일 탐지 또는 경로 지정)
2. 소스 읽기 + wiki/index.md에서 관련 기존 페이지를 모두 찾기
3. 위키 업데이트:
- 관련된 모든 기존 페이지에 새 정보 병합
- 새 주제면 새 페이지 생성
- 모순이면 명시적으로 표시
- 새 페이지 만들면 기존 페이지에도 wikilink 추가
4. index.md, log.md 갱신
5. 결과 보고
## 원격 소스
원격 소스는 API를 통해 읽는다. 원본이 외부에서 갱신될 수 있으므로 재ingest 시
wiki를 최신으로 갱신한다./lint는 위키의 건강 상태를 점검한다. 연결 없는 orphan 페이지, 깨진 링크,
누락된 프론트매터, 인덱스와 실제 파일의 불일치 등을 검사한다. 주기적으로
실행해서 위키가 어지러워지기 전에 잡는다.
# Lint
위키 건강 상태를 점검한다.
## 점검 항목
1. orphan 페이지 — wiki/에 있지만 index.md에 없는 페이지
2. 깨진 링크 — 존재하지 않는 파일을 참조
3. 프론트매터 — 필수 필드 누락 또는 불필요한 필드 잔존
4. index.md 정합성 — 인덱스에 있지만 파일이 없는 항목
5. 중복 페이지 — 병합 제안
6. log.md — 오래된 경우 경고
7. 시스템 정합성 — CLAUDE_GUIDE.md와 커맨드 간 모순 점검Karpathy 글의 마지막 Note도 인상깊었다:
This document is intentionally abstract. It describes the idea, not a specific implementation. The exact directory structure, the schema conventions, the page formats, the tooling — all of that will depend on your domain, your preferences, and your LLM of choice. … The right way to use this is to share it with your LLM agent and work together to instantiate a version that fits your needs. The document’s only job is to communicate the pattern. Your LLM can figure out the rest.
이 문서는 의도적으로 추상적이다. 특정 구현이 아니라 아이디어를 설명한다. 디렉토리 구조, 스키마 컨벤션, 페이지 포맷, 도구는 모두 도메인, 선호, LLM에 따라 달라진다. 올바른 사용법은 LLM 에이전트와 공유하고 함께 자신의 필요에 맞는 버전을 구체화하는 것이다. 이 문서의 역할은 패턴을 전달하는 것이다. 나머지는 LLM이 알아낼 수 있다.
예전에는 도구를 공유하려면 앱이든 라이브러리든 템플릿이든, 구체적인 산출물을 배포해야 했다. Karpathy는 패턴만 공유하고 구체적 구현은 각자의 LLM 에이전트와 만들라고 한다. LLM이 추상적 설명을 읽고 구체적 코드로 변환할 수 있기 때문에 가능한 방식이다. 도구의 공유 단위가 “코드”에서 “아이디어”로 바뀐 셈이다.