Andrej Karpathy가 2026년 4월, X에 “LLM Knowledge Bases”라는 글을 올렸다.
핵심은 간단했다. “LLM이 위키를 쓰고, 사람은 거의 직접 편집하지 않는다.” raw 소스를 모으고, LLM이 .md 위키로 “컴파일”하고, 질의하고, 결과를 다시 위키에 적립하는 루프. 탐구할수록 지식이 복리로 성장하는 구조. 이후 그는 이 아이디어를 LLM Wiki라는 상세 가이드로 GitHub에 공개했다.
문제는 — 그의 시스템은 100개 문서, 40만 단어 규모였다. 나에게는 10년간 축적한 15,161개 노트, 5,332개 PM 지식 노트가 있었다. 이미 스키마(Frontmatter v5.4), 20개 거버넌스 정책, 17개 템플릿이 갖춰져 있었다.
“Karpathy의 LLM 루프 + 우리의 거버넌스를 결합하면?” 이 질문에서 프로젝트가 시작되었다.
Karpathy 모델 해부: 7개 레이어
Karpathy의 워크플로우를 분해하면 7개 레이어로 나뉜다:
- Data Ingest — 소스 문서를
raw/디렉토리에 색인. Obsidian Web Clipper로 웹→.md 변환 - LLM Compile — LLM이 raw를 위키로 “컴파일”. 요약, 백링크, 개념 분류, 문서 간 링크를 자동 생성
- IDE — Obsidian을 “프론트엔드”로 사용. LLM이 쓴 위키를 열람
- Q&A — 위키가 충분히 크면 LLM 에이전트가 복잡한 질문에 답변. fancy RAG 없이 인덱스+요약으로 충분
- Output — .md, 슬라이드, 이미지로 렌더링. 결과를 위키에 재적립 → 복리 효과
- Linting — LLM “건강 검진”: 불일치 발견, 누락 보충, 새 연결 제안
- Extra Tools — 검색 엔진 등 CLI 도구를 vibe coding으로 구축
1. LLM이 쓰고, 사람은 질문한다 — 위키 편집은 LLM의 영역
2. 순환 축적 — 탐구 결과가 위키에 쌓여 지식이 강화됨
3. 점진적 컴파일 — 새 데이터마다 LLM이 incremental 업데이트
4. Obsidian = 통합 뷰어 — raw + wiki + output을 한 곳에서 열람
Karpathy는 이후 이 아이디어를 LLM Wiki라는 상세 가이드로 정리하여 GitHub Gist에 공개했다 (1,900+ Stars, 348 Forks). X 포스트가 “왜(Why)”였다면, 이 가이드는 “어떻게(How)”에 해당한다.
LLM Wiki: 3-Layer 아키텍처
가이드에서 Karpathy는 시스템을 3개 레이어로 명확히 분리한다:
| 레이어 | 소유자 | 역할 | 우리 Vault 대응 |
|---|---|---|---|
| Raw Sources | 사람 | 불변의 원본 문서. LLM은 읽기만 하고 절대 수정하지 않음 | 00_Inbox/ |
| Wiki | LLM | 요약·엔티티·비교·종합 페이지. LLM이 전적으로 소유 | 40_FullyActiveLearning/ |
| Schema | 사람+LLM 공동 | 구조·컨벤션·워크플로우를 정의하는 설정 문서 (예: CLAUDE.md) | Frontmatter v5.4 + 20개 정책 |
주목할 부분은 Schema 레이어다. Karpathy의 X 포스트에는 명시되지 않았지만, 가이드에서는 이것이 “사람과 LLM이 함께 진화시키는(co-evolved) 설정 문서”라고 분명히 한다. 우리의 Frontmatter v5.4와 거버넌스 정책이 바로 이 Schema 레이어에 해당한다.
3가지 핵심 오퍼레이션
가이드는 시스템의 일상 운영을 3가지 워크플로우로 정의한다:
| 오퍼레이션 | Karpathy 설명 | 우리 구현 |
|---|---|---|
| Ingest | 새 소스 → LLM이 요약 작성 → 인덱스 갱신 → 관련 엔티티/개념 페이지 업데이트. 단일 소스가 10~15개 위키 페이지에 영향 | compile-to-wiki.py + inbox-process.sh |
| Query | 위키에 질문 → LLM이 관련 페이지 검색 → 인용 포함 답변 종합. 가치 있는 결과는 새 위키 페이지로 환류 | vault-search.sh |
| Lint | 정기 건강 검진 — 모순 발견, 오래된 주장 표시, 고아 페이지 식별, 누락 교차 참조, 새 탐구 방향 제안 | vault-disposition.py (부분 구현) |
“지식 베이스 관리에서 지루한 부분은 읽기나 사고가 아니라 — 기록 관리(bookkeeping)다.”
LLM은 수십 개 페이지에 걸쳐 교차 참조를 갱신하고, 일관성을 유지하고, 모순을 감지하는 일에 탁월하다. 사람은 유지보수 부담 때문에 이 작업을 포기하지만, LLM에게는 본업이다. 이 분업이 “사람은 큐레이션·방향 설정·질문·종합, LLM은 인프라 작업”이라는 패턴을 만든다.
Karpathy는 이것을 Vannevar Bush의 1945년 Memex 개념 — 연상적 연결(associative trails)을 가진 개인 지식 저장소 — 의 현대적 실현으로 본다. Bush의 비전은 유지보수 문제를 해결해야 가능했고, LLM이 그 문제를 해결한다.
📎 Karpathy LLM Wiki 전체 가이드 (GitHub Gist)
격차 진단: 150배 규모에서 뭐가 다른가
Karpathy의 시스템과 10년간 구축한 vault를 8개 차원으로 비교했다.
| 차원 | Karpathy | 현재 Vault | 판정 |
|---|---|---|---|
| 규모 | ~100문서 | 15,161문서 | Vault 압도적 |
| 스키마 | 없음 | v5.4, 27 type | Vault 압도적 |
| LLM Compile | LLM이 주 저자 | 사람이 주 저자 | 핵심 격차 |
| Q&A Agent | 위키 기반 질의 | 없음 | 핵심 격차 |
| 지식 축적 루프 | 자동 지식 축적 | 수동/비정기 | 핵심 격차 |
| 도메인 깊이 | 단일 연구 주제 | 10년, 30+ 고객사 | Vault 압도적 |
발견: Vault는 지식의 깊이와 거버넌스에서 압도적이지만, LLM을 지식 조작의 주 에이전트로 활용하는 루프가 빠져 있었다. 두 모델의 장점을 합치면 — “Governed Autonomy” — LLM이 자유롭게 생성하되, 스키마와 정책이 품질을 보장하는 모델이 된다.
구현: 3단계, 3.5시간, 1,082줄
Phase 1: Q&A Agent
13,750개 노트를 frontmatter 필터 + ripgrep 전문 검색으로 질의하는 CLI를 구축했다. 기존 vault-autolinking.py의 regex 파서를 재사용하여 외부 의존성 없이 320줄로 완성. fancy RAG 없이 ~2초에 13,750 노트 검색이 가능했다.
Phase 2: Accumulation Loop
리서치 결과를 자동으로 vault 지식에 환류하는 엔진. 98건의 리서치 파일을 분석하여 정량 점수(0~100) 기반 3단계 판정을 수행하고, 436개 extractable atom을 자동 식별했다.
Phase 3: LLM Compile
Inbox 85건을 5종으로 자동 분류하고, Claude CLI를 통해 Frontmatter v5.4 준수 위키 노트를 자동 생성하는 파이프라인.
전체 산출물: 5개 스크립트, 1,082 LOC — Karpathy가 “hacky collection of scripts”라고 부른 것의 실질적 구현.
벤치마크: 숙련자 대비 실측
모든 시간 추정은 vault를 10년간 운영한 숙련자가 수동으로 수행하는 시나리오 기준이다.
| 기능 | 자동 | 수동 (숙련자) | 속도 | 핵심 차이 |
|---|---|---|---|---|
| Q&A Agent | ~1분 | ~5분 | 5배 | +25% 추가 발견 |
| Accumulation | 0.23초 | ~45분 | 9배 | 436 atoms 자동 |
| LLM Compile | 0.06초 | ~15분 | 7배 | 스키마 준수 |
| E2E 전체 | ~2시간 | ~8시간 | 4배 | 닫힌 루프 |
실전 테스트: 5대 고객사 리스크 검색
삼성/LG/현대모비스/KT/SK의 리스크 도메인 노트를 양쪽 방식으로 검색한 결과:
| 고객 | vault-search | 수동 (find) | 누락 |
|---|---|---|---|
| 삼성전자 | 33건 | 18건 | 15건 (45%) |
| LG | 63건 | 53건 | 10건 (16%) |
| 현대모비스 | 12건 | 12건 | 0건 |
| KT | 41건 | 40건 | 1건 |
| SK | 28건 | 18건 | 10건 (36%) |
| 합계 | 177건 | 141건 | 36건 (20%) |
숙련자가 놓치는 36건은 능력 부족이 아니다. 구조적 한계다. 복합 pm-domain([scope, risk, charter] — 파일명에 risk가 없음), 고객 별칭(lgchem → LG), 타 디렉토리 — 이런 것들은 파일명 검색으로 찾을 수 없다.
5~9배의 속도 차이는 숙련자에게 “편리함” 수준이다. 진짜 가치는 완전성 +25%(복합 도메인 36건 발견 불가), 436 atoms 자동 식별(수동 전수 조사 비현실적), E2E 닫힌 루프(수동은 환류를 “종종 안 함”)이다.
E2E 루프: 지식이 복리로 성장하는 구조
Karpathy 모델의 핵심은 “탐구할수록 지식이 누적되는 복리 효과”다. 이것을 15,000+ 규모에서 실현하려면 거버넌스가 필수다.
| 차원 | Karpathy | Governed LLM KB |
|---|---|---|
| 규모 한계 | ~100문서 | 15,000+ |
| 품질 보장 | LLM 자율 | 스키마+정책+감사 |
| 환류 | 수동 filing | 자동 disposition→extract |
| 검색 | LLM 인덱스 의존 | frontmatter+rg 구조적 |
Karpathy 가설 4가지 검증
| Karpathy 주장 | 검증 결과 |
|---|---|
| “fancy RAG 불필요” | 검증됨 — regex+rg로 13,750 노트 2초 검색, 수동 대비 25% 더 완전 |
| “LLM이 위키의 주 저자” | 인프라 완성 — compile-to-wiki + 품질 게이트로 스키마 준수 자동 생성 |
| “탐구할수록 지식이 누적” | 루프 완성 — disposition → atom 추출 → vault 자동 지식 축적 |
| “incredible new product” | 1,082 LOC — 제품이 아닌 “Governed scripts”가 더 실용적 |
PM/PL 실무자에게 주는 시사점
교훈 1: 과거의 거버넌스가 미래의 자동화 품질을 결정한다
Karpathy에게 없고 우리에게 있는 것 — Frontmatter v5.4, 27 type taxonomy, 20 정책 문서. 이것이 LLM 자동 생성의 “제약 조건 라이브러리”로 변환된다.
교훈 2: “hacky scripts”가 제품보다 실용적이다
1,082줄의 독립적 스크립트 5개가 전체 루프를 구성한다. 각 스크립트가 독립적이라 교체/확장이 쉽고, 디버깅이 투명하다.
교훈 3: RAG는 마지막 수단이다
15,000+ 노트에서도 regex + ripgrep으로 충분했다. 구조화된 메타데이터(frontmatter)가 있으면 RAG가 불필요하다.
교훈 4: 닫힌 루프가 열린 루프보다 100배 가치 있다
수동 축적는 “시간 나면 한다”. 자동 지식 축적는 “항상 한다”. 이 차이가 1년 뒤 지식 자산의 크기를 결정한다.
마치며
Karpathy는 “LLM을 지식 노동자로 고용하라”고 했다. 하지만 경험 많은 PM이라면 알 것이다 — 어떤 노동자든 거버넌스 없이 자율에만 맡기면 규모에서 무너진다.
10년간 쌓아온 스키마, 정책, 감사 체계가 있었기에, LLM에게 자율을 주면서도 품질을 보장할 수 있었다. 이것이 Governed Autonomy — Karpathy가 “incredible new product”라고 부른 것의, PM 관점에서의 답이다.
이 글은 Andrej Karpathy의 LLM Knowledge Bases 포스트와 LLM Wiki 가이드를 분석하고, 10년간 삼성전자·LG·현대모비스·KT·SK 등 30+ 기업 PM 워크숍에서 축적한 15,161개 Obsidian 노트에 적용한 실전 기록입니다. 원본 분석 데이터는 projectresearch.co.kr/insights에서 확인하실 수 있습니다.