지난번에 PKM에 관해서 포스팅을 했는데, 이제는 PKM의 관리 주체마저 AI에게 맡기는 개념이 등장했다. 사용자는 그저 읽기만 하면 된다. 바로 안드레 카파시가 소개하는 LLM 위키이다.
안드레 카파시가 트윗과 깃허브 gist로 공개한 LLM 위키(LLM Wiki)는 코드가 아니라 하나의 패턴이다. 흩어진 자료를 LLM에게 매번 다시 읽히는 대신, LLM이 한 번 읽고 정리된 마크다운 지식베이스로 "컴파일"해두면 그다음부터는 훨씬 빠르고 정확하게 대화할 수 있다는 아이디어다.
1. 시작: 트윗 한 줄에서 시작된 아이디어
2026년 4월, 카파시는 자신의 X(트위터) 계정에 최근 연구 자료를 정리하는 방식에 대해 짧은 글을 올렸다. 요지는 이랬다 — "토큰을 코드 작성보다 지식 정리에 더 많이 쓰고 있다"는 것. 그는 원본 자료를 raw/ 폴더에 모아두고, LLM에게 이를 읽혀 wiki/라는 마크다운 파일 묶음으로 "컴파일"하게 만든다고 설명했다.
X의 Andrej Karpathy님(@karpathy)
LLM Knowledge Bases Something I'm finding very useful recently: using LLMs to build personal knowledge bases for various topics of research interest. In this way, a large fraction of my recent token throughput is going less into manipulating code, and more
x.com
이틀 뒤 그는 llm-wiki.md라는 gist를 추가로 공개했다. 실행 가능한 코드가 아니라, Claude Code 같은 에이전트에게 그대로 붙여 넣으면 에이전트가 사용자의 상황에 맞춰 직접 위키 구조를 만들어주는 "아이디어 파일(idea file)"이었다. 이후 커뮤니티에서 이 패턴을 재구현한 오픈소스 프로젝트, Obsidian 플러그인, 에이전트 스킬이 여럿 등장했다.
2. 핵심 아이디어: RAG처럼 "매번 다시 찾기"가 아니라, 컴파일러처럼 "한 번 정리하고 계속 쓰기"
기존 RAG(검색 증강 생성)는 질문할 때마다 원본 문서 더미에서 관련 조각을 다시 찾아 매번 답을 재구성한다. 문서가 늘어날수록 검색은 느려지고, 문서 간의 관계나 모순은 질문할 때마다 새로 추론해야 한다. 카파시의 비유는 이렇다 — 이건 마치 소스코드를 매번 인터프리터로 실행하는 것과 같다. 반면 LLM 위키는 컴파일러에 가깝다. 원본을 한 번 읽고 구조화된 결과물을 만들어두면, 그 뒤로는 컴파일된 결과만 빠르게 읽으면 된다.
| 일반적인 RAG | 카파시의 LLM 위키 |
| 질문마다 원본 문서를 다시 검색 | 원본은 한 번만 읽어 위키로 컴파일 |
| 문서 간 관계는 매번 새로 추론 | 개념·항목 간 링크가 미리 연결돼 있음 |
| 모순되는 자료가 있어도 표시되지 않음 | 모순은 위키에 명시적으로 기록됨 |
| 자료가 많아질수록 응답이 느려짐 | 위키가 커져도 질의는 가볍게 유지 |
| 결과물이 대화 안에서 휘발됨 | 지식이 파일로 남아 계속 누적·성장 |
3. 작동 방식: 수집 → 컴파일 → 질의

01 수집
읽은 논문, 스크랩한 블로그 글, 저장한 이미지 등 원본 자료를 그대로 모아둔다. 카파시는 웹 아티클을 .md로 바꿀 때 Obsidian Web Clipper 확장을 쓰고, 관련 이미지도 단축키로 함께 로컬에 내려받는다고 밝혔다. 이 폴더는 수정하지 않고 원형 그대로 보존한다.
02 컴파일
LLM 에이전트(Claude Code 등)가 raw/의 내용을 읽고 요약·분류한다. 개념별로 문서를 만들고, 문서끼리 서로 링크를 걸고, 서로 다른 자료가 상충하는 부분이 있으면 그 사실 자체를 위키에 명시적으로 남긴다. 새 자료가 들어오면 기존 문서를 갱신하는 식으로 계속 반복된다.
03 질의
위키가 어느 정도 쌓이면(카파시 본인의 예시로는 문서 약 100개, 40만 단어 규모) 이제 위키를 대상으로 복잡한 질문을 던질 수 있다. 에이전트는 필요하면 위키를 더 조사하고 보강하면서 답을 만든다. 매번 원본 뭉치를 뒤지지 않아도 되니 훨씬 빠르고 일관된 답이 나온다.
4. 구조 예시: 폴더 하나, 마크다운 파일 여러 개가 전부다
특별한 소프트웨어가 필요 없다. Obsidian 같은 마크다운 편집기를 "IDE" 삼아 원본과 컴파일된 위키를 눈으로 확인하면서, 실제 파일 작성과 유지보수는 LLM에게 맡긴다. 예를 들어 "AI 연구와 소프트웨어 철학"을 주제로 위키를 만든다면 폴더 구조는 대략 이런 모습이다.

5. 왜 유용한가? 속도보다 소유권이 핵심이다.
- 데이터가 내 손에 남는다. 위키는 그냥 로컬 마크다운 파일이다. 특정 서비스에 자료를 업로드하는 게 아니라, 파일 자체를 소유한다.
- 답이 더 정확해진다. 이미 정리·상호참조된 구조를 읽기 때문에, 매번 원문에서 추론하는 것보다 일관되고 근거 있는 답이 나온다.
- 모순이 숨지 않는다. 자료 간 상충되는 주장을 위키가 명시적으로 기록해두므로, 조사가 쌓일수록 오히려 더 정직한 지식베이스가 된다.
- 특정 회사에 종속되지 않는다. 특정 AI 서비스가 사라지거나 유료화돼도, 마크다운 파일과 폴더 구조는 그대로 남아 다른 도구로 옮길 수 있다.
6. 인생은 실전이다!
마지막으로 실제로 카파시의 llm-wiki.md 파일을 넣고, 클로드 코드에게 단순하게 명령했다.
안드레 카파시의 PKM 방식으로 LLM Wiki라는게 있는데, 해당 파일을 읽고 내 옵시디언 폴더를 정리해 줘.

작업 중인 옵시디언 + 클로드 코드(우측 사이드 하단 옵시디언용 클로디안 플러그인이다.)
해당 파일을 읽어, 변환 계획을 작성한다.(이건 아마 superpowers라는 스킬을 써서 그렇다.) 그리고 그대로 실행하라고 하면, 클로드 코드가 기존에 정리된 폴더와 문서들을 읽으면서 자동으로 CLAUDE.md 파일을 생성하여 이 옵시디언 저장소의 저장 규칙을 작성해 준다.

자동으로 작성된 CLAUDE.md 파일
앞으로 이 옵시디언 폴더를 어떻게 관리해야 하는지 등에 대해 LLM Wiki를 기반으로 만들어낸 파일이다. 아직은 좀 마음에 들지 않는다. 좀 더 클로드에게 채찍질을 해봐야겠다.
'가상' 카테고리의 다른 글
| 개인 지식 관리(Personal Knowledge Management) 방법론 (0) | 2026.07.25 |
|---|---|
| 토큰을 아끼는 AI Berkshire 사용법. 녹는다, 녹아. (0) | 2026.07.24 |
| OpenDart 활용기, XML파일 다운로드 안 받고 고유 번호(기업 코드) 불러오기 (0) | 2021.08.06 |
| Audio SNS 클럽하우스(Clubhouse)에 빠져보자. (0) | 2021.02.10 |
| 이제 블로그 구독도 텔레그램으로! (2) | 2021.01.19 |