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

- 작성자: [북극곰](https://community.clauders.ai/member/imported-member-7x4Ve2LlfI)
- 공간: [노트 / 글쓰기](https://community.clauders.ai/writing)
- 게시: 2026-04-05
- 연재: [Obsidian AI 지식 볼트](https://community.clauders.ai/series/obsidian-ai-knowledge-vault) 5/6편
- 태그: #옵시디언
- 주소: https://community.clauders.ai/writing/post/andrej-karpathy%EC%9D%98-llm-wiki%EB%A5%BC-%EB%82%B4-%EC%98%B5%EC%8B%9C%EB%94%94%EC%96%B8%EC%97%90-%EC%8B%AC%EC%97%88%EB%8D%94%EB%8B%88-7-660%EA%B0%9C-%EB%85%B8%ED%8A%B8%EA%B0%80-%EC%8A%A4%EC%8A%A4%EB%A1%9C-%EC%A0%95%EB%A6%AC%EB%90%98%EA%B8%B0--7ec8eb18-fcde-8e64-a0c9-efc3049477ba

---

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

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

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

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

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

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

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

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

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

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

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

영어 원문

최종 한국어 명령어

자연어로 쓰면

Ingest

`/적용`

"이 자료 적용해줘"

Query→Wiki Save

`/위키저장`

"이거 위키저장해줘"

Lint

`/점검`

"볼트 점검해줘"

이 과정에서 느낀 건, **남의 시스템을 그대로 쓰면 반드시 이런 불일치가 생긴다**는 거예요. "적용"이라는 단어는 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개 카테고리 인덱스 노트가 하나도 없다"는 발견은 당연하긴 했지만 나름 충격이었습니다.

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

### Before vs After

항목

Before

After

새 자료 투입

어디에 넣을지 고민 / 인박스나 단순 도큐먼트 폴더에 쌓아둠

`/적용`으로 자동 분류·요약·교차참조

좋은 답변 보존

채팅 기록에서 소실

`/위키저장`으로 즉시 위키에 축적

볼트 건강 점검

한 번도 안 해봄

`/점검`으로 전체 스캔 + 보고서 자동 생성

구조적 문제 발견

첫 점검에서 Blocking 4건, Risk 6건 즉시 식별

점검 주기

없음

매주 월요일 새벽 자동 실행

### 결과물

- **3개의 지식관리 명령어** (`/적용`, `/위키저장`, `/점검`)
- **LLM 친화적으로 전환된 시스템 문서** (카탈로그, 가이드)
- **첫 볼트 건강검진 보고서** (3,481개 파일 전수 스캔)
- **주간 자동 점검 시스템** (매주 월요일 새벽 3시)

### 효과적이었던 것

1. **남의 시스템을 그대로 쓰지 말고, 내 시스템에 맞게 변형하라**  
   Karpathy의 LLM Wiki는 훌륭한 패턴이지만, "ingest"를 "적용"으로 바꾸고, 기존 에이전트를 재활용하고, 한국어 명령어를 만드는 과정이 있었기에 제 것이 됐습니다. 남의 프롬프트나 워크플로우를 복붙하면 반드시 어딘가에서 안 맞는 부분이 생깁니다.
2. **설계→구현→검증을 하루 안에 돌려봐라**  
   하루면 설계부터 첫 점검 결과까지 나옵니다. 완벽하게 준비하고 시작하려 하면 영원히 못 합니다. 일단 돌려보고, 보고서가 나오면 그때 고치면 됩니다.

## 🚀 앞으로의 계획

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

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

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