LLM Wiki 패턴 — Karpathy가 제안한 지식 컴파일 전략의 실증 결과
Karpathy의 LLM Wiki 아이디어를 72-run 벤치마크로 검증한 결과, Vanilla 대비 토큰 53% 절감·처리 시간 39% 단축·품질 향상을 확인했다.
LLM에게 매번 같은 질문을 던질 때마다, 에이전트는 코드베이스를 처음 보는 척 탐색한다. Karpathy가 제안한 LLM Wiki 패턴은 이 낭비를 끊는 방법이다.
아이디어는 간단하다. 지식을 한 번 컴파일해두고, 이후 질의는 컴파일된 아티팩트에 대해서만 수행하라. 매번 원본을 읽는 대신, 정리된 위키 노트를 거쳐 답을 내는 방식이다.
이 개념이 실제로 효과가 있을까? roboco.io 팀이 72번의 실험으로 검증했다.
LLM Wiki의 3-Layer 구조
LLM Wiki는 세 층으로 구성된다.
| 레이어 | 디렉토리 | 관리 주체 | 역할 |
|---|---|---|---|
| Layer 1 | raw/ | 사람 | 불변 원본 소스 |
| Layer 2 | wiki/ | LLM | 마크다운 노트, 교차참조, 태그 |
| Layer 3 | CLAUDE.md | 사람 | 행동 규칙 정의 |
핵심은 Layer 2다. LLM이 raw를 읽고 wiki 노트를 생성·갱신한다. 이후 질의는 raw를 직접 읽지 않고 wiki를 경유한다. 비유하면 도서관 사서가 책마다 요약 카드를 만들어두는 것과 같다. 독자는 요약 카드를 보고 원하는 책을 찾는다.
72-run 벤치마크 설계
실험은 세 가지 변종을 비교했다.
[💡 잠깐! 이 용어는?] Vanilla: LLM이 매번 원본 소스를 직접 읽어 답하는 기본 방식. Wiki: LLM이 사전에 생성된 마크다운 위키를 경유해서 답하는 방식. Graphify: 지식 그래프를 추가로 생성해 경로 추적에 활용하는 고급 방식.
- 태스크: 8개 작업 (패치 분석, 크로스 언어 의존성, grep 검색, 역사 분석 등)
- 반복 횟수: 변종별 3회 trial → 총 72회 실행
- 채점 방식: 외부 모델(GPT-5)이 4차원 루브릭으로 점수 산정
루브릭 가중치는 정확성 40%, 완결성 30%, 인용 20%, 과잉 10%다.
결과: Wiki가 거의 모든 지표에서 우위
| 지표 | Vanilla | Wiki | Graphify |
|---|---|---|---|
| 토큰 소비 | 755K | 350K | 617K |
| 처리 시간(초) | 166.5 | 101.1 | 179.8 |
| 품질 점수(0-25) | 15.10 | 16.00 | 13.56 |
Wiki는 Vanilla 대비 토큰을 53.6% 절감하고 처리 시간도 39.3% 단축했다. 품질까지 높다. 통계적 유의성도 확보됐다(Wiki vs Vanilla 토큰: d=0.842, p=0.0105).
Graphify는 토큰 절감도 품질도 Vanilla보다 나쁘다. 세 방식 중 최저 품질(13.56)이다.
태스크별로는 Wiki가 8개 중 5개에서 1위를 차지했다. 특히 여러 출처를 통합해야 하는 작업에서 압도적이다. Vanilla가 유리한 2개는 "단일 출처에서 명확한 답이 있는" 케이스였다.
최소 셋팅 5분
mkdir my-wiki && cd my-wiki
mkdir raw wiki# My LLM Wiki
## 디렉토리
- raw/: 원본 소스 (LLM read-only)
- wiki/index.md: 페이지 카탈로그
## 작업
- /ingest <file>: raw/<file> 통합
- /query <question>: 검색 및 답변
- /lint: 위키 건강도 점검
## 규칙
- frontmatter에 tags, sources 명시
- [[Page Name]] 위키링크 사용
- 충돌 시 양쪽 입장 인용이게 전부다. LLM이 /ingest 명령을 받으면 raw를 읽고 wiki 노트를 작성한다. 이후 질의는 wiki/index.md를 먼저 읽고, 관련 페이지를 찾아 답을 구성한다.
일일 운영 사이클
Wiki를 유지하는 건 세 가지 루틴이다.
| 작업 | 내용 |
|---|---|
| Ingest | 새 소스 통합, 관련 노트 갱신 |
| Query | 인덱스 → 관련 페이지 → 답변 |
| Lint | 주기적 위키 건강도 점검 |
패턴을 성공시키는 두 가지 규칙
실험팀이 발견한 것은 기술보다 운영 규칙이 더 중요하다는 점이다.
첫째, Wiki-first + 출처 검증. Wiki 노트를 먼저 읽고, 의심스러운 사실은 raw에서 직접 확인한다. 무조건 Wiki만 믿으면 오래된 정보로 답을 낸다.
둘째, 인용 규율. 모든 Wiki 활용 사실에 [[페이지명]] 형식의 명시적 인용을 붙인다. 이 규칙 하나로 인용률이 10% 미만에서 정상화됐다고 한다.
[💡 잠깐! 이 용어는?]
위키링크: [[Page Name]] 형식으로 Wiki 페이지를 교차 참조하는 표기법. Obsidian 등 노트 앱에서 백링크 그래프를 만들 때 쓴다.
단일 출처에서 명확한 답이 있는 질문은 Wiki를 거칠 이유가 없다. "grep 결과 바로 내놓기"는 Vanilla가 더 빠르다. 워크로드를 파악하고 상황에 맞는 규칙을 조합하는 게 핵심이다.
정리
- LLM Wiki는 Vanilla 대비 토큰 53% 절감, 시간 39% 단축, 품질 향상을 동시에 달성했다
- Graphify(지식 그래프)는 크로스 컴포넌트 경로 추적에만 써야 한다 — 범용 대체재가 아니다
- 기술보다 인용 규율과 위키-퍼스트 정책이 성패를 가른다
- Obsidian 연동까지 1시간, Obsidian Skills(Dataview, Canvas) 통합까지 1일이면 충분하다
"에이전트에게 같은 걸 반복시키고 있다"는 느낌이 든다면, 지식을 한 번만 컴파일해두는 것부터 시작할 수 있다.
참고:
같은 카테고리 · AI
비슷한 주제의 최신 글
태그가 겹치는 글
공통 태그가 많을수록 위에 보인다
