Andrej Karpathy의 LLM Wiki를 내 옵시디언에 심었더니 7,660개 노트가 스스로 정리되기 시작했다

📝 한줄 요약

Andrej Karpathy가 공유한 "LLM Wiki" 패턴을 내 옵시디언 지식관리 시스템에 접목해서, AI가 지식을 자동으로 분류·점검·확장해주는 반자동 시스템을 만들었습니다.

바쁘시면 이것만 읽어도 돼요:

• Andrej Karpathy의 LLM Wiki 패턴을 내 PKM 시스템에 맞게 변형해서 적용

• AI와 Q&A 6라운드로 시스템 설계를 완성

• /적용, /위키저장, /점검 세 가지 명령어로 지식관리 핵심 루틴 반자동화

• 첫 점검에서 AI 에이전트 5개가 동시에 7,660개 노트를 스캔, 숨겨진 구조 문제 발견

• 핵심 교훈: 남의 좋은 시스템을 그대로 쓰지 말고, 내 시스템에 맞게 변형하라

🎯 이런 분들께 도움돼요

• 옵시디언이나 노션에 노트는 잔뜩 쌓아뒀는데, AI를 어떻게 결합할지 감이 안 잡히는 분

• "AI로 지식관리 자동화"에 관심은 있지만 너무 막연하게 느껴지는 분

• PKM(개인 지식관리) 시스템을 운영하면서 "이걸 AI가 대신 해줬으면..." 하고 생각해본 분

😫 문제 상황 (Before)

저는 옵시디언에 7,660개가 넘는 노트를 관리하고 있습니다. 주로 미디어 아트와 관련한 연구, 강의부텨 AI 강의 까지 활동의 거의 모든 지식이 이 볼트 안에 들어있어요.

시스템 자체는 CMDS의 시스템을 그대로 이식했죠.

문제는 운영이었습니다.

새 자료가 들어오면 "이걸 어디에 넣지?", "기존에 비슷한 노트가 있었나?", "관련 노트들에 링크를 걸어야 하나?"를 매번 고민해야 했고, 대부분은 그냥 Inbox에 던져놓고 잊어버리곤 했습니다. 7,660개 노트의 건강 상태? 깨진 링크가 몇 개인지, 빈 페이지가 어디 있는지 한 번도 전체 점검을 해본 적이 없었습니다.

그러던 중 Andrej Karpathy가 공유한 "LLM Wiki" 패턴을 보게 됐습니다.

핵심 아이디어는 간단했어요:

• 원본 자료(Raw) — 건드리지 않는 소스

• 위키(Wiki) — AI가 유지하는 합성 계층

• 설정(Schema) — AI에게 규칙을 알려주는 설정 파일

"이거다!" 싶었습니다. 이 패턴을 CMDS 시스템에 결합하면, AI와 함께 지식을 확장·검증·적용하는 반자동 시스템을 만들 수 있겠다고 생각했어요.

🛠️ 사용한 도구

• Claude Code: AI 코딩 에이전트 (Claude Opus 4.6 모델)

• 특이사항: brainstorming 스킬로 대화형 설계, 병렬 서브에이전트로 동시 작업

🔧 작업 과정

AI와 6라운드 Q&A로 시스템 설계를 완성하다

LLM Wiki 패턴 문서를 Claude Code에 읽혀주고 이렇게 요청했습니다.

llm-wiki를 완벽히 도입하고 지식을 자동화, 자동 확장하기 위한 방법을 제안해봐.

여기서 인상적이었던 건 AI의 접근 방식이었습니다. 한꺼번에 "이렇게 하세요!"라고 답을 내놓는 게 아니라, 핵심 설계 질문을 하나씩 던지면서 제 선택을 받아갔어요. 마치 시스템 설계 컨설턴트에게 상담받는 느낌이었습니다.

1라운드: "원본과 위키의 경계를 어디에 둘까요?"

AI가 세 가지 방식을 제시했어요 — 폴더 기준, 프로퍼티 기준, 하이브리드. 저는 가장 직관적인 폴더 기준을 골랐습니다. 이미 제 볼트에 참조 자료 폴더(References)와 영구 노트 폴더(Permanent Notes)가 분리되어 있었으니까요.

"ingest"를 뭐라고 부르지? — 스킬 네이밍 논쟁

설계는 끝났는데 예상치 못한 곳에서 막혔습니다. 명령어 이름이었어요.

LLM Wiki 원문에서는 "ingest"(소스를 위키에 흡수)라는 용어를 쓰는데, 한국어로 "이 자료를 인제스트해줘"라고 말하면... 솔직히 어색하잖아요.

이 소스를 ingest 해줘는 한국어로 봤을땐 명확하지 않은데

AI가 "소화", "흡수", "투입" 같은 후보를 제시했고, 몇 번의 핑퐁 끝에 이렇게 정리됐습니다:

이 과정에서 느낀 건, 남의 시스템을 그대로 쓰면 반드시 이런 불일치가 생긴다는 거예요. "적용"이라는 단어는 LLM Wiki 원문에 없지만, 제가 실제로 쓸 때 가장 자연스러운 표현이었습니다.

클라우드 vs 로컬 — 자동 점검의 함정

주간 자동 점검을 설정하려는데 문제가 생겼습니다.

Claude Code에는 원격 스케줄 기능이 있어서, "매주 월요일 자동으로 점검 돌려줘"를 설정하려 했거든요. 그런데 원격 에이전트는 클라우드에서 실행되기 때문에 제 Mac에 있는 옵시디언 볼트에 접근할 수가 없었습니다.

7,660개의 개인 노트를 클라우드에 올리는 건 현실적이지 않았고, 결국 Mac 자체의 예약 작업 기능을 이용해서 매주 월요일 새벽 3시에 로컬에서 자동 실행되도록 설정했습니다.

AI 도구를 쓰다 보면 "클라우드에서 다 되겠지"라고 생각하기 쉬운데, 로컬 데이터를 다루는 작업에서는 이런 제약을 미리 알아두는 게 좋습니다.

설계한 시스템이 진짜로 돌아가는 순간

테스트삼아 /점검을 처음 실행했습니다.

AI가 5개의 에이전트를 동시에 띄워서 볼트 전체를 병렬로 스캔하기 시작했어요. 한 에이전트는 100~200번대 카테고리를, 다른 에이전트는 300~400번대를, 이런 식으로 나눠서 동시에 점검하는 겁니다.

약 10분 후, 종합 보고서가 나왔습니다:

• Blocking 4건: 91개 카테고리 인덱스 노트가 전부 없음 (!)

• Risk 6건: 4개 폴더가 완전히 비어있음, 2,200개 노트에 연결 정보 누락

• Growth 5건: 우선 생성해야 할 인덱스 노트, 자동 보충 가능한 항목 등

구조적 문제를 AI가 10분 만에 찾아낸 거예요.

특히 "91개 카테고리 인덱스 노트가 하나도 없다"는 발견은 당연하긴 했지만 나름 충격이었습니다.

이 순간이 "아, 이 시스템 만들기 잘했다"고 확신한 때였습니다.

✅ 결과 (After)

Before vs After

결과물

• 3개의 지식관리 명령어 (/적용, /위키저장, /점검)

• LLM 친화적으로 전환된 시스템 문서 (카탈로그, 가이드)

• 첫 볼트 건강검진 보고서 (3,481개 파일 전수 스캔)

• 주간 자동 점검 시스템 (매주 월요일 새벽 3시)

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. 남의 시스템을 그대로 쓰지 말고, 내 시스템에 맞게 변형하라
   Karpathy의 LLM Wiki는 훌륭한 패턴이지만, "ingest"를 "적용"으로 바꾸고, 기존 에이전트를 재활용하고, 한국어 명령어를 만드는 과정이 있었기에 제 것이 됐습니다. 남의 프롬프트나 워크플로우를 복붙하면 반드시 어딘가에서 안 맞는 부분이 생깁니다.

2. 설계→구현→검증을 하루 안에 돌려봐라
   하루면 설계부터 첫 점검 결과까지 나옵니다. 완벽하게 준비하고 시작하려 하면 영원히 못 합니다. 일단 돌려보고, 보고서가 나오면 그때 고치면 됩니다.

🚀 앞으로의 계획

지금은 /적용을 수동으로 실행해야 합니다. "이 자료 적용해줘"라고 직접 말해야 하죠.

다음 목표는 반자동 감지입니다. 참조 자료 폴더에 새 파일이 들어오면 AI가 알아서 감지하고 "이 자료를 적용할까요?"라고 제안하는 방식으로 업그레이드하려고 합니다.

그리고 첫 점검에서 발견된 91개 인덱스 노트 부재 문제를 해결하면, 진짜로 AI가 7,660개 노트 사이를 자유롭게 돌아다니며 지식을 연결하는 시스템이 완성될 겁니다.