30시간 RAG 실측 회고 — Karpathy의 llm-wiki는 내 10년 obsidian-vault를 이길 수 있었나

K-1·K-2가 던졌던 약속, 30시간으로 검증해보았습니다

이 시리즈는 작년에 두 편을 먼저 발행했습니다.

• K-1 — Agentic 시대, PM의 온톨로지맵 (2026-03-23): 10년치 PM 코칭 자산을 “AI가 읽을 수 있는 지식망”으로 구조화하는 4단계 전환 방법론. 검색 시간 600배 개선(30분 → 3초)을 정량 결과로 제시했습니다.
• K-2 — Karpathy의 LLM과 Obsidian 지식 결합 (2026-04-04): Karpathy의 3계층 아키텍처(Raw / Wiki / Schema)를 15,161 노트 vault에 적용. “Governed Autonomy”라는 개념과 함께 4~9배 자동화, 25% 완전성 향상, 436 atoms 자동 추출을 측정했습니다.

K-1은 “온톨로지맵을 만들면 RAG가 빨라진다”라는 가설을, K-2는 “Karpathy 패턴을 내 vault에 적용하면 자동화가 작동한다”라는 가설을 각각 입증했습니다.

그러면 이번 K-6는 무엇을 검증해야 했을까요?

2026년 4월 16일부터 17일까지 약 30시간 동안 위 세 질문에 답하기 위해 별도의 llm-wiki repo를 만들고, OneDrive 28,849 파일을 추출하여 obsidian-vault 45,640 노트와 6쿼리 양방향 벤치마크를 돌렸습니다. 이 글은 그 회고입니다.

두 시스템, 두 사상 — Zettelkasten vs Karpathy 3-Layer

이번 실험은 단순한 도구 비교가 아니라 두 가지 지식 관리 철학의 정면 충돌이었습니다. 한쪽은 80년 역사의 독일 카드 박스 시스템을 디지털로 옮긴 Niklas Luhmann의 Zettelkasten, 다른 한쪽은 LLM 시대를 위해 Andrej Karpathy가 설계한 3-layer wiki 패턴입니다. 두 사상은 “지식을 누가, 어떻게 정리해야 하는가”라는 근본 질문에 정확히 반대 답을 내놓습니다.

K-1에서 소개한 온톨로지맵의 10개 레이어가 obsidian-vault에서는 11개 최상위 디렉토리 + 16개 frontmatter 필드로 진화한 반면, llm-wiki는 K-2에서 다룬 Karpathy의 3계층 사상을 OneDrive 384GB 코퍼스에 정직하게 적용했습니다.

obsidian-vault의 규모와 골격 — K-1 온톨로지맵의 진화형

vault는 11개 최상위 폴더로 의미를 분리하고, 16개 frontmatter 필드로 검색 신호를 부여합니다. K-1에서 제시한 10개 레이어가 1년 만에 11개로 정착되었고, K-2 시점 15,161 노트가 본 글 시점 45,640 노트로 3배 성장했습니다.

llm-wiki의 3-Layer 규율 — Karpathy 원칙의 정직한 이행

K-2에서 다룬 Karpathy의 3계층(Raw/Wiki/Schema)을 본 실험은 schema CLAUDE.md에 그대로 박아두고 30시간 동안 한 줄도 안 건드렸습니다.

• raw (immutable) — OneDrive 원본은 SSoT, 이 repo에는 바이너리를 복사하지 않음. raw/manifest.jsonl에 경로·크기·mtime·sha1(head 1MB)만 저장. 총 10.3MB로 28,849 파일 384GB의 지문을 들고 있습니다.
• wiki (LLM-owned) — lecture/, project/, entities/의 markdown. ingest / query / lint 세 가지 동작으로만 갱신. 자동 ingest 절대 금지(Karpathy 원칙).
• schema (사람 소유, 안정 유지) — 페이지 타입·프론트매터·컴팩션 규칙

페이지 타입은 6종으로 단순합니다 — client(조직), concept(프레임워크), synthesis(교차 합성), timeline(연도 스냅샷), question(미해결 모순), entity(인물·도구).

본문 주장은 [^n] 각주로 추적하고, 페이지가 300줄을 넘기면 오래된 내용은 ## Archive 섹션으로 압축합니다 — Karpathy의 “compaction” 원칙입니다. K-2의 Governed Autonomy가 “스키마로 LLM을 통제”하는 거라면, llm-wiki의 compaction은 “공간 제약으로 LLM이 우선순위를 강제로 매기게 만드는” 또 다른 통제 장치인 셈이죠.

도구 스택 검증 — “어떻게 384GB를 텍스트로 바꾸나”

실험 첫 단계에서 8개 샘플 파일에 대해 추출 도구 스택 3종을 비교했습니다.

최종 채택: Docling + MarkItDown + hwp5txt. 6-worker 병렬 PDF 추출로 2,666/6,640 PDF를 처리한 시점에서 시간 제약으로 중단(40% 완료, 재개 가능). 비PDF 10,515 파일은 일괄 추출 완료. 총 13,181 텍스트 파일 5.3GB가 raw/extracted/에 누적되었습니다.

업무로써 두 repo를 어떻게 RAG로 활용하는가

K-1에서 “30분 → 3초 600배”를 말했고, K-2에서 “5~9배 자동화”를 말했습니다. 그러면 실제로 두 시스템을 어떻게 쓰고 있는지, 본 실험에서 정착된 워크플로우를 그대로 공개합니다.

obsidian-vault — 정밀 큐레이션 우선 (K-1 온톨로지맵의 활용 패턴)

K-1에서 제시한 “원소화 + 메타데이터 + 양방향 링크 + 검색성” 4단계가 그대로 검색 패턴이 됩니다.

# 1. 클라이언트 + 도메인 필터 (frontmatter 16필드 활용)
./scripts/vault-search.sh --client samsung --pm-domain risk

# 2. 노트 타입 + 본문 검색
./scripts/vault-search.sh --query "리더십" --type atomic/insight

# 3. 복합 검색 + JSON 출력 (자동화 친화)
./scripts/vault-search.sh --client lg --query "워크숍" --format json

# 4. 인덱스 통계 — 30% 커버리지 자가 진단
./scripts/vault-search.sh --stats

작동 원리는 단순하지만 강력합니다. frontmatter YAML 필드(client, industry, pm-domain, pmbok_ka)로 1차 필터링한 뒤 본문 grep + relevance ranking, 마지막에 retrieval_tier(A>B>C>D)와 quality_score로 정렬합니다.

두 번째로 자주 쓰는 패턴이 디렉토리 라우팅 우선입니다. “Samsung-GAUSS Case Bank”를 찾을 땐 전체 vault를 뒤지지 않고 30_Agentic PM/Samsung-GAUSS/로 직진합니다 — CLAUDE.md에 그렇게 라우팅 규칙이 박혀 있기 때문이죠. K-2의 Governed Autonomy가 검색에 적용된 형태입니다.

세 번째 패턴은 Phase-link 통한 시계열 추적입니다. 본 실험 이후 의무화된 규칙이지요.

project_index.md (PRJ-2026-001)
  ├── Phase1 → atom A (vault link)
  ├── Phase2 → atom B (vault link)
  └── Phase3 → atom C (Q5에서 발견된 V3.2)

llm-wiki — 무차별 추출 + LLM 합성 (Karpathy 패턴)

K-2에서 다룬 “LLM이 wiki를 작성하고 사람은 질문하는” 패턴 그대로입니다. 다만 자동 ingest는 절대 금지이므로, 사용자가 명시 호출 시점에만 작동합니다.

# 1. LLM 매개 질의 (claude -p 호출)
./scripts/ingest.sh --query "Samsung GAUSS PM Agent Phase 3 근거"

# 2. wiki 페이지 직접 grep
grep -rn "Case Bank" lecture/ project/ entities/

# 3. 각주 정의 추적 → manifest를 통해 OneDrive 원본까지
grep "\[\^1\]:" project/clients/samsung.md
# → [^1]: raw/extracted/lecture/삼성전자/20260306-Global-Expert/handout-v18.md

# 4. 원본 텍스트 검증
cat raw/extracted/lecture/삼성전자/20260306-Global-Expert/handout-v18.md

llm-wiki의 묘미는 모든 주장이 raw/extracted/의 텍스트 파일까지 추적된다는 점입니다. manifest.jsonl이 28,849 파일의 sha1 지문을 들고 있기 때문에 OneDrive에서 원본이 바뀌면 즉시 감지됩니다. K-2의 표현으로는 “감사 가능한 자동화(auditable automation)”의 한 형태입니다.

통합 워크플로우 — 본 실험 이후 정착된 3-Step

K-2에서 “닫힌 루프(closed loop)가 지식을 복리로 성장시킨다”고 했는데, 본 실험으로 그 루프에 한 칸이 더 추가되었습니다. 이제는 vault 자체 안에서만 닫혀있던 루프가 OneDrive·llm-wiki·vault 세 곳을 순환합니다.

벤치마크 결과 — 정량 점수와 정성 분석

6개 쿼리는 제 평소 워크플로우 패턴에서 뽑았습니다 — 클라이언트별, 프레임워크별, 시계열별, 신규 개념별로 스펙트럼을 분포시켰습니다. 각 쿼리당 5축 채점(hit 1점 + relevance 5점 + depth 5점 + traceability 5점 = 16점)으로 총 96점 만점입니다.

정량 vs 정성 — K-2의 “구조적 20% 누락” 명제 재검증

vault 우위(Q1·2·3·6)의 공통점 — 큐레이션 10년의 위력

• 연차 누적의 위력 — Samsung 단일 클라이언트에 355개 atom, Agile Simulation 검색 108 히트
• 메타데이터 정밀도 — retrieval_tier, quality_score, pmbok_ka 16필드가 검색 신호로 작동 (K-2의 Frontmatter v5.4)
• 위키링크 그래프 — 한 노트에서 시작해 관련 개념 즉시 도달 (K-1의 양방향 링크)
• PMBOK 다국어판 인덱싱 — 한국어 검색 시 영문 PMBOK 7th까지 자동 매핑

wiki 우위(Q4·5)의 공통점 — 무차별 스캔의 본질 가치

• Q4 (2024-2025 timeline): vault는 2,130건이 산재해 통합 뷰가 없음. wiki는 project/timelines/2024.md 단일 페이지로 LLM이 합성 — Karpathy의 “compaction” 원칙이 정확히 작동한 사례
• Q5 (Case Bank Mode): vault에 완전 부재(0건), wiki는 OneDrive 스캔으로 발견 — 무차별 추출이 blind spot 발견에 결정적

왜 vault에 Case Bank가 없었나 — 5-Why로 파고들기

5-Why로 파고들었습니다.

Why 1: PMBOK Agent V3.2와 Case Bank Mode가 vault에 없었다
 ← Why 2: Samsung-GAUSS Phase3-Agent 산출물이 vault에 큐레이션되지 않았다
   ← Why 3: Phase3 산출물이 OneDrive에만 존재하고 vault 이관 트리거가 발동하지 않았다
     ← Why 4: vault accumulation loop는 [research] done / [pm] done 시에만 작동하고
              OneDrive 직접 작업의 산출물은 자동 스캔 대상이 아니었다
       ← Why 5: AIPM 3-tier 모델에서 OneDrive는 "각 레포의 SSoT"로만 정의되어 있고
                 vault로의 자동 흡수 경로가 설계되지 않았다

구조적 원인은 4가지입니다.

최종 결론 — 통합이 정답이었다

5가지 결론을 도출했습니다.

1. vault는 정밀, wiki는 발견 — 큐레이션 우위(vault 4승)와 blind spot 발견(wiki 2승)은 서로 다른 기능
2. 2점 차이는 “근소”가 아닌 “구조적 우위” — Q2 8점차, Q5 16점차 같은 큰 격차는 도메인 특성 반영
3. wiki의 30시간이 vault의 10년을 따라잡지 못한다 — K-1·K-2가 입증한 “거버넌스의 복리 효과”가 정량적으로 재확인
4. 하지만 wiki는 vault가 영원히 못 발견할 것을 5분 만에 찾아냈다 — Q5의 16점차가 K-2의 “구조적 20% 누락” 명제의 결정적 사례
5. 둘을 병렬 운영하는 것은 30시간을 또 30시간으로 만드는 것 — 통합이 정답

아키텍처 결정 — Before / After

BEFORE (실험 기간):
  OneDrive ──→ llm-wiki (extract → wiki → ingest) ←──→ obsidian-vault
                  (두 시스템 병행, 중복 관리 비용)

AFTER (확정):
  OneDrive ──→ extract pipeline (llm-wiki 유산)
                ↓
              vault-disposition.py
                ↓
              compile-to-wiki.py
                ↓
              obsidian-vault (단일 Knowledge Layer)

K-1에서 제시한 “4단계 전환(원소화 → 메타데이터 → 관계연결 → 검색성)”이 본 실험으로 한 단계 더 진화했습니다. K-2에서 닫힌 루프를 제시했고, K-6는 그 루프에 OneDrive 정기 스캔을 추가했습니다.

llm-wiki repo 처분 — “버리지 않고 흡수”

vault accumulation loop 4가지 개선 (즉시 도입)

1. OneDrive 정기 스캔 (주 1회 cron) — build-manifest.sh + diff + vault-disposition.py --auto-extract
2. vault-search indexed 커버리지 확대 — 30% → 55% (50_Project/Artifact/ 노트 frontmatter 보강)
3. Phase-link MOC 의무화 — PRJ-YYYY-*.md에 Phase별 atom 링크 강제, 빈 Phase는 (해당 없음) 명시
4. [pm] done 체크리스트에 OneDrive 산출물 확인 추가 — 직접 작성된 교안·커리큘럼·retro도 vault-disposition 대상에 포함

당신은 어느 쪽을 먼저 시작해야 하는가

본 글의 최종 결론은 “vault 단일 + extract pipeline 흡수”였지만, 이는 PM 코치 10년 + OneDrive 384GB라는 특수 케이스에서 도출한 결론입니다. 독자분의 상황은 다를 수 있습니다. 30시간을 들이지 않고도 자신에게 적합한 출발점을 고르실 수 있도록, 4가지 페르소나로 정리했습니다.

10초 진단 체크리스트

향후 활용방안 — 1주·1개월·1분기·전사

단기 (1주 — Quick Wins)

※ Quick Win 1~3은 이미 AIPM-349/350/351 사이클에서 완료 (commit 5abc267, 2015472, 4585175 참조)

중기 (1개월)

• OneDrive 주간 cron 셋업 (build-manifest + diff + vault-disposition --auto-extract) — Phase3 같은 blind spot 자동 감지
• vault-search indexed 커버리지 30% → 55% 프로젝트 (50_Project/Artifact/ frontmatter 보강)
• Samsung-GAUSS Phase3 atom 추가 분해 (현재 2개 → 5~7개 목표)
• llm-wiki PDF wave 2 재개 (2,666 → 6,640 완료) — 추가 blind spot 발견 가능성

중장기 (1분기 — 시스템 통합)

• vault-search.sh --aggregate-by-year 옵션 추가 — Q4 패턴(통합 뷰) 영구 해결
• 연도별 Timeline MOC 자동 생성 cron (pm-rel과 연동) — 매년 자동 timeline 페이지
• compile-to-wiki.py에 OneDrive 신규 파일 정기 스캔 통합 — accumulation loop 단일화
• Phase-link 검증 규칙을 pm-audit.sh에 추가 — Phase 분절 재발 방지

전사 적용 가능성 — N=1을 N=N으로

이 실험은 PM 코치 1인의 케이스지만, 다음 영역에 일반화 가능합니다.

핵심 패턴: “OneDrive · SharePoint · Google Drive 등 비정형 코퍼스 → 추출 파이프라인 → LLM 큐레이션 → Zettelkasten Vault” 4단계 구조는 도메인 무관 적용 가능합니다.

1년 뒤 follow-up 벤치마크

30시간이 가르쳐준 것

K-1에서 “10년 경험을 AI가 읽을 수 있는 지식망으로 구조화하라”고 말했고, K-2에서 “거버넌스가 LLM 자율의 품질을 보장한다”고 말했습니다. K-6가 추가하는 한 줄은 이렇습니다.

“거버넌스가 미치지 못하는 영역에 대해서는, 무차별 스캔이 보완 도구로 살아있어야 한다.”

지식 관리 시스템을 운영하는 모든 분께 권하고 싶은 것은, 1년에 한 번이라도 자기 시스템의 blind spot을 의도적으로 찾는 작업입니다. 무차별 스캔, 외부 도구 비교, A/B 벤치마크 — 방법은 무엇이든 좋습니다. 자기 시스템 안에서만 일하면 자기 시스템이 못 보는 것은 영원히 못 보게 됩니다.

저는 이번 실험으로 4가지 vault accumulation loop 개선안을 도출했고, llm-wiki의 extract pipeline은 vault feeder로 살아남았습니다. 30시간 투자의 ROI는 “Case Bank Mode 1건 발견” + “구조적 약점 4개 식별” + “주간 자동화 설계” — K-1이 600배, K-2가 4~9배를 측정했다면, K-6는 “blind spot 발견 능력 = ∞배“라는 다른 차원의 가치를 측정한 셈입니다.

관련 글

• 📘 K-1: Agentic 시대, PM의 온톨로지맵 — Obsidian을 통해 나만의 RAG를 만드는 법 (2026-03-23) — 본 글의 vault 측 사상적 출발점
• 📗 K-2: Karpathy의 LLM과 Obsidian 지식 결합 — Governed Autonomy의 실전 구현 (2026-04-04) — 본 글의 wiki 측 사상적 출발점
• 📕 K-6: 본 글 (2026-04-18) — 두 시스템의 정면 벤치마크

#Karpathy #K-6 #llm-wiki #obsidian-vault #RAG #Zettelkasten #Governed-Autonomy #Knowledge-Management #Agentic-PM #PM #OneDrive #PMBOK #vault-search #Docling

이 글은 PM 코치 10년의 실제 OneDrive 코퍼스(28,849 파일·384GB)와 obsidian-vault(45,640 노트)를 대상으로 2026년 4월 16~17일 30시간에 걸쳐 수행한 실측 벤치마크 회고를 바탕으로 작성되었습니다. Karpathy 사고 체계 시리즈 K-6편이며, K-1·K-2의 가설을 별도 시스템 비교로 정면 검증했습니다. 전체 백서(6 Part + §A CRAAP·AIMQ·Eppler IQF 자체 평가 + §B Known Limitations + §C 출처 12종)는 aipm/research/20260418-deep-llm-wiki-vs-obsidian-vault-whitepaper.md에 보관되어 있으며, vault-disposition 평가 결과 cross-repo-reusable(score 65) 등급을 받았습니다.