Karpathy LLM 위키·Graphify, 정말 작동할까

Obsidian + Karpathy LLM 위키 + Graphify, 화려한 그래프뷰의 진실

지식 아카이브 자동화의 실제 효과와 함정 — 인스타 릴스의 그래프뷰는 실용인가, 전시용 허상인가

전 테슬라 AI 디렉터 Andrej Karpathy가 던진 "LLM 위키" 개념이 트위터에서 약 1,600만 뷰를 기록하며 개발자 커뮤니티를 흔들었습니다. "Obsidian은 IDE, LLM은 프로그래머, 위키는 코드베이스다." 매력적인 비유지만, 직접 써본 사람들은 하나같이 "노트가 쌓일수록 오히려 방향을 잃었다"고 말합니다. 이 글은 그 진단이 사용자 실수인지 구조적 결함인지, 그리고 "키워드만 던지면 AI가 알아서 정리하는 프롬프트"가 실현 가능한지를 근거와 함께 분해합니다.

🧩 LLM 위키란 무엇인가 — RAG와의 결정적 차이

기존 RAG(검색 증강 생성)와 LLM 위키의 본질적 차이는 "언제 지식을 가공하느냐"에 있습니다. RAG는 질의할 때마다 실시간으로 조각을 긁어모으지만, LLM 위키는 자료를 수집하는 시점에 미리 사람이 읽을 수 있는 마크다운으로 컴파일해 둡니다. 매번 다른 조각을 조합하는 RAG의 일관성 부족 문제를, 사전 편집된 위키 페이지로 풀겠다는 발상입니다.

구분	기존 RAG	LLM 위키
처리 시점	질의할 때마다 실시간 검색	수집 시점에 미리 컴파일
저장 형태	벡터 임베딩(불투명)	사람이 읽는 마크다운
지식 연결	유사도 기반 추출	개념 간 명시적 [[링크]]
일관성	낮음(매번 다른 조합)	높음(편집 이력 추적)

구조는 명확한 3계층입니다. 원본 소스(절대 수정하지 않는 불변 진실층) → 위키(LLM이 합성한 요약·개념 페이지) → 그리고 이 둘을 지배하는 스키마(`CLAUDE.md` 같은 "어떻게 수집·유지보수하라"는 계약)입니다.

graph TD
  S[원본 소스
PDF·기사·메모
불변 진실층] --> W[위키
LLM 컴파일
요약·개념 합성]
  C[스키마
CLAUDE.md 계약
수집·유지 규칙] --> W
  W --> A[AI 에이전트
세션 간 참조]
  style S fill:#e8f8f5,stroke:#16a085,color:#117a65
  style W fill:#fef9e7,stroke:#f39c12
  style C fill:#eaf2f8,stroke:#2980b9
  style A fill:#eafaf1,stroke:#27ae60,color:#1e8449

🔗 다이어그램 요약: 수정 불가능한 원본 소스와 유지보수 규칙을 담은 스키마가 함께 위키로 흘러들어 LLM이 합성 페이지를 만들고, AI 에이전트는 매 세션 원본을 다시 읽지 않고 이 컴파일된 위키만 참조합니다.

Karpathy 본인의 연구 위키는 약 100개 문서, 40만 단어 규모로, 문서 하나를 새로 넣으면 기존 10~15개 페이지가 자동 갱신된다고 합니다. 이론만 놓고 보면 분명 우아합니다.

⚙️ Graphify — 역할 분담의 다른 절반

Graphify는 폴더 전체를 쿼리 가능한 지식 그래프로 바꾸는 오픈소스 도구입니다(`pip install graphifyy`). Tree-sitter로 AST를 파싱하고 NetworkX로 그래프를 구축하며 Leiden 클러스터링으로 묶어, 코드·SQL 스키마·논문·이미지·영상에서 구조를 기계적으로 추출합니다. Claude Code·Cursor·Gemini CLI와 호환됩니다.

핵심은 역할 분담입니다. Graphify는 코드 구조 계층(파일 의존성·함수 호출·스키마 관계)을 LLM 환각과 무관하게 보존하고, Obsidian은 인간 가독성 위키 계층(결정사항·진행상황·개념 설명)을 담습니다.

graph TD
  X[코드·논문·스키마] --> G[Graphify
AST 코드 그래프]
  Y[메모·결정사항] --> O[Obsidian
가독성 위키]
  G --> E[AI 에이전트
세션마다 재독 불필요]
  O --> E
  style X fill:#eaf2f8,stroke:#2980b9
  style Y fill:#eaf2f8,stroke:#2980b9
  style G fill:#e8f8f5,stroke:#16a085,color:#117a65
  style O fill:#fef9e7,stroke:#f39c12
  style E fill:#eafaf1,stroke:#27ae60,color:#1e8449

🔗 다이어그램 요약: 코드·논문은 Graphify가 AST 그래프로, 메모·결정사항은 Obsidian이 가독성 위키로 나눠 담고, AI 에이전트는 두 계층을 합쳐 참조하므로 매 세션 코드를 처음부터 다시 읽을 필요가 없습니다.

📊 현황 — 시장은 크지만 수치는 의심하라

AI 강화 개인 지식관리(PKM) 시장은 2025년 약 16.5억 달러에서 연평균 30.3% 성장해 2030년 61.5억 달러에 이를 것으로 전망됩니다. 옵시디언 커뮤니티 플러그인은 2,700개 이상, 인스타그램 "Obsidian Notes" 릴스는 550개 이상 집계됩니다.

2025년

$16.5억

2030년 (전망)

$61.5억

PKM 시장 규모, 연평균 성장률(CAGR) 30.3% — 5년 새 약 3.7배

주요 오픈소스 구현이 내세우는 성과는 화려합니다. `claude-obsidian`은 30일 후 80~200개 위키 페이지 자동 생성을, `claude-code-memory-setup`은 세션당 토큰 최대 71.5배 절감을 주장합니다. 하지만 여기서 멈춰야 합니다.

🧠 수치를 그대로 믿지 말 것: "71.5배 절감"은 126개 TypeScript 파일 React 프로젝트 단일 케이스 기준이고, "AST 모드에서 LLM 호출 비용 0"이라는 가정이 깔려 있습니다. 요인별 분해도 없습니다. 맹신보다 "상당한 절약 가능성"이라는 방향성으로만 받아들이는 것이 안전합니다.

🔍 왜 직접 경험은 부정적이었나 — 구조적 결함 4가지

"너무 많아지면 방향을 못 잡는다"는 보고는 사용자 실수가 아니라 시스템 설계 결함에서 나옵니다. 비판 커뮤니티가 지목한 공백은 네 가지입니다.

① 인식론적 필터 부재
LLM이 수집·합성할 때 "이 주장이 검증 가능한가?"를 묻지 않습니다. 신뢰할 통찰과 그럴듯한 오류가 동등한 권위로 쌓입니다.

② 지식 생명주기 없음
"방금 추가된 추측"과 "수십 번 검증된 사실"이 같은 레이아웃으로 공존합니다. 1년 전 낡은 개념과 오늘 인사이트가 구별되지 않습니다.

③ 엔트로피 대항 메커니즘 부재
중복 자동 감지나 모순 표면화가 없습니다. "만 입력, 무 제거" 구조라 위키가 자체 무게로 무너집니다. 비판자 표현으로 "성장만 하는 위키는 결국 붕괴할 위키"입니다.

④ 오류 복리
LLM이 만든 오류가 위키에 들어가면, 다음 수집 때 그 오류 위에 새 합성 페이지가 쌓입니다. 환각이 복리로 증폭됩니다.

여기에 두 가지 물리적 천장이 더해집니다.

단일 컨텍스트 윈도우 실효 상한 ~10만 토큰 (300~500개 파일)

약 10만 토큰을 넘는 위키는 한 번에 컨텍스트에 들어가지 않습니다. 2계층 분할로 풀려 하면 결국 RAG를 재발명하게 됩니다. 또 옵시디언 네이티브 그래프뷰는 노드 클릭·줌·팬이 전부 — 그래프 위 직접 편집도, 새 연결 생성도, 재배치 영구 저장도 지원하지 않습니다. 노트 300개를 넘으면 엉킨 실타래가 되어 탐색보다 감상용이 됩니다. 거기에 cron·git hook·Python 스크립트 설정 오버헤드까지 더해져, 커뮤니티 자체가 "실제 작업 대신 남의 설정 구경에 빠진다"고 자조합니다.

⚖️ 어디서 효용이 있고, 어디서 실망하는가

🟢 실제 효용이 있는 영역
▶ 소규모 개인 연구(노트 50~200개) — 독서 노트·논문 요약·결정사항 추적. 세션 간 컨텍스트 비용 절감과 개념 간 예상치 못한 연결 발견은 진짜 가치입니다.
▶ 장기 코드베이스 유지(Graphify+Claude Code) — AST 그래프는 환각과 무관하게 구조적 사실을 보존합니다.
▶ AI 에이전트 메모리 계층 — `CLAUDE.md`처럼 맥락을 구조적으로 주입하는 방식.

🔴 기대치를 낮춰야 하는 영역
▶ 인스타 그래프뷰 재현 — 화려한 시각은 3~6개월 누적의 결과. 릴스는 "완성된 금광"이지 "금 캐는 과정"이 아닙니다.
▶ 대규모 팀 지식관리 — 접근 제어·동시 편집 충돌 해결·감사 로그 같은 기업 필수 기능이 전부 없습니다.
▶ 빠르게 변하는 분야 — AI·규제·시장처럼 진실 반감기가 짧으면 합성 페이지가 빠르게 노후화되는데 시스템이 자동 감지하지 못합니다.

🧠 인스타 그래프뷰의 역설: 그래프가 시각적으로 매력적인 구간(노트 100~400개)은 실재합니다. 그러나 그래프가 예쁠수록 그것은 탐색보다 전시에 최적화된 상태입니다. 실제 작업자는 그래프보다 검색창과 [[링크]]를 압도적으로 더 씁니다.

🎯 결론 — 진단은 옳고, 비용은 과소평가됐다

Karpathy의 LLM 위키는 문제 진단이 정확합니다. LLM은 세션 간 기억이 없고, RAG는 일관성이 부족하며, 사전 컴파일이 반복 질의보다 효율적입니다. 이 통찰 자체는 유효합니다. 그러나 구현 난이도와 유지보수 비용이 홍보보다 훨씬 높고, 성공 사례는 대부분 숙련된 개발자가 단일 도메인 장기 프로젝트에 적용한 경우입니다.

"키워드만 주면 AI가 구조화하는 간단한 프롬프트"는 기술적으로 완전히 가능합니다. 동작하는 오픈소스가 여럿 존재합니다. 함정은 "간단한"이라는 수식어입니다. 가치를 유지하려면 인간의 주기적 개입(가지치기·오류 수정·방향 조정)이 반드시 필요하고, 완전 자동화는 현재 기술로 불가능합니다. 직접 시도에서 나온 부정적 리포트는 정확한 관찰이었습니다.

규모와 목적에 따라 도입 판단은 셋으로 갈립니다.

flowchart TD
  A([지식 시스템 도입 검토]) --> B{무엇을 위한
아카이브인가?}
  B -->|에이전트 메모리 계층| C[즉시 권장
CLAUDE.md+Graphify]
  B -->|단일 도메인
노트 200개 이하| D[조건부 권장
정기 가지치기 필수]
  B -->|전 분야 두 번째 뇌| E[비권장
방향 상실 필연]
  style A fill:#3498db,stroke:#2980b9,color:#ffffff
  style B fill:#fef9e7,stroke:#f39c12
  style C fill:#eafaf1,stroke:#27ae60,color:#1e8449
  style D fill:#fef9e7,stroke:#f39c12,color:#e67e22
  style E fill:#fdedec,stroke:#e74c3c,color:#c0392b

🔁 다이어그램 요약: AI 에이전트 메모리 계층은 즉시 권장, 노트 200개 이하 단일 도메인은 정기 가지치기를 조건으로 권장, 모든 분야를 망라하는 "두 번째 뇌"는 비대화와 방향 상실이 설계상 피할 수 없어 비권장입니다.

시나리오	대상	핵심 조건
A · 즉시 권장	에이전트 프로젝트별 메모리	CLAUDE.md + 결정 노트 + Graphify 코드 그래프
B · 조건부	단일 도메인 개인 누적	노트 200개 이하 + 정기 가지치기 + 그래프뷰는 건강 체크용
C · 비권장	전 분야 "두 번째 뇌"	비대화·방향 상실을 막을 자동화가 현재 없음

🧠 마지막으로: 화려한 그래프뷰를 만든 사람들의 공통점은 도구가 아니라 규율이었습니다. 하나의 주제에 집중해 수개월에 걸쳐 천천히 쌓았습니다. 도구는 조건이지 원인이 아닙니다. 도입의 첫 단계는 "AI가 알아서 키워주는 두뇌"가 아니라 "내가 꾸준히 가지치기할 정원"으로 기대치를 재설정하는 것입니다.

참고 자료

▶ AI Critique — Karpathy LLM Wiki
▶ Innobu — Enterprise Reality Check
▶ GitHub — lucasrosati/claude-code-memory-setup
▶ GitHub — safishamsi/graphify
▶ decodethefuture — LLM Wiki 3계층

본 콘텐츠는 지식관리 도구와 기술 동향에 관한 정보 제공을 목적으로 작성되었으며, 특정 도구의 도입이나 투자를 권유하지 않습니다. 인용된 수치와 성과 주장은 출처 시점 기준이며 실제 환경에서 다를 수 있습니다.

📄 Raw Data

# Obsidian + Karpathy LLM Wiki + Graphify: 지식 아카이브의 실제 효과와 함정

## 1. 질문 파악

이 질문의 표면은 "Karpathy의 LLM Wiki 이론과 Graphify를 어떻게 적용하느냐"지만, 실제 의도는 더 날카롭다. 세 가지로 정리된다.

1. **이 접근법이 실제로 작동하는가** — 인스타 릴스의 화려한 그래프뷰가 실용인가, 전시용 허상인가
2. **직접 써봤을 때 겪은 "비대화·방향 상실"이 사용자 실수인가, 구조적 결함인가**
3. **"검색 키워드를 던지면 AI가 알아서 구조를 만드는 간단한 프롬프트"가 실현 가능한가**

결론부터 말하면, 진단은 옳지만 운영 비용이 과소평가되어 있다. 아래에서 근거와 함께 분해한다.

---

## 2. 기초 정보 (Foundation)

### Karpathy의 LLM Wiki — 무엇을 주장하나

2026년 4월 4일, 전 테슬라 AI 디렉터이자 OpenAI 공동창업자 Andrej Karpathy가 GitHub Gist에 "LLM Wiki" 개념을 공개했고, 트위터에서 **약 1,600만 뷰**를 기록하며 개발자 커뮤니티에 확산됐다(출처: AI Critique). 핵심 명제는 한 문장이다.

> "Obsidian은 IDE이고, LLM은 프로그래머이며, 위키는 코드베이스다."

기존 RAG(Retrieval-Augmented Generation)와의 결정적 차이는 **언제 지식을 가공하느냐**에 있다.

| 구분 | 기존 RAG | LLM Wiki |
|------|---------|---------|
| 처리 시점 | 질의할 때마다 실시간 검색 | **수집 시점**에 미리 컴파일 |
| 저장 형태 | 벡터 임베딩(불투명) | 사람이 읽는 마크다운 |
| 지식 연결 | 유사도 기반 추출 | 개념 간 명시적 `[[링크]]` |
| 일관성 | 낮음(매번 다른 조각 조합) | 높음(편집 이력 추적 가능) |

구조는 3계층이다(출처: decodethefuture).
- **원본 소스(Sources)**: PDF·기사·메모 — 절대 수정하지 않는 불변 진실층
- **위키(Wiki)**: LLM이 컴파일한 요약·개념·비교·합성 페이지
- **스키마(Schema)**: `CLAUDE.md`·`AGENTS.md` 형태로 "어떻게 수집·조회·유지보수하라"를 지시하는 계약

Karpathy 본인의 연구 위키는 약 **100개 문서, 40만 단어** 규모이며, 문서 하나를 수집하면 기존 10~15개 페이지가 자동 갱신된다고 한다(출처: AI Critique).

### Graphify — 역할 분담의 다른 절반

Graphify는 폴더 전체를 쿼리 가능한 **지식 그래프**로 변환하는 오픈소스 도구다. Claude Code·Cursor·Gemini CLI와 호환된다(출처: GitHub safishamsi/graphify).
- **처리 대상**: 코드, SQL 스키마, 문서, 논문, 이미지, 영상
- **핵심 기술**: Tree-sitter(AST 파싱) + NetworkX(그래프 구축) + Leiden 클러스터링
- **출력**: HTML, JSON, Obsidian 마크다운 / **설치**: `pip install graphifyy`

역할 분담이 명확하다. **Graphify는 코드 구조 계층**(파일 의존성·함수 호출 그래프·스키마 관계)을 기계적으로 추출하고, **Obsidian은 인간 가독성 위키 계층**(결정사항·진행상황·개념 설명)을 담는다. 둘이 합쳐지면 AI 에이전트는 매 세션 코드를 다시 읽지 않고 이미 컴파일된 그래프를 참조한다.

---

## 3. 현황 데이터 (Current State)

AI 강화 개인 지식관리(PKM) 시장은 2025년 기준 약 **16.5억 달러**, 2030년까지 연평균 30.3% 성장해 **61.5억 달러**에 이를 것으로 전망된다. 옵시디언 커뮤니티 플러그인은 2026년 기준 **2,700개 이상**, 인스타그램 "Obsidian Notes" 릴스는 **550개 이상** 집계된다(출처: AI Critique, Innobu).

주요 구현 레포와 그들이 **주장하는** 성과는 다음과 같다.

| 레포 | 핵심 | 주장 성과 |
|------|------|---------|
| `AgriciDaniel/claude-obsidian` | Claude Code 자기조직 두뇌 | 30일 후 80~200개 위키 페이지 자동 생성 |
| `lucasrosati/claude-code-memory-setup` | Obsidian+Graphify 3계층 메모리 | 세션당 토큰 **최대 71.5배** 절감 주장 |
| Karpathy 원본 Gist | 이론 프레임워크 | 40만 단어, 문서당 10~15페이지 갱신 |

**여기서 수치를 그대로 믿으면 안 된다.** "71.5배 절감"은 126개 TypeScript 파일 React 프로젝트 **단일 케이스** 기준이고, 문서가 이를 요인별로 분해하지 않으며 "AST 모드에서 LLM 호출 비용 0"이라는 가정이 깔려 있다(출처: GitHub lucasrosati). 맹신보다 "상당한 절약 가능성"이라는 방향성으로만 받아들이는 것이 안전하다.

---

## 4. 원인 분석 — 왜 직접 경험은 부정적이었나

직접 시도했을 때 나온 "너무 많아지면 오히려 방향을 못 잡는다"는 보고는 **사용자 실수가 아니라 시스템 설계 결함**에서 나온다. 비판 커뮤니티가 지목한 구조적 공백은 네 가지다(출처: GitHub Gist 비판글, Innobu).

- **① 인식론적 필터 부재**: LLM이 수집·합성할 때 "이 주장이 검증 가능한가?"를 묻지 않는다. 신뢰할 통찰과 그럴듯한 오류가 동등한 권위로 쌓인다.
- **② 지식 생명주기 없음**: "방금 추가된 추측"과 "수십 번 검증된 사실"이 같은 레이아웃으로 공존한다. 1년 전 낡은 개념과 오늘 인사이트가 구별되지 않는다.
- **③ 엔트로피 대항 메커니즘 부재**: 중복 자동 감지나 모순 표면화가 없다. "만 입력, 무 제거" 구조라 위키가 자체 무게로 무너진다. 비판자 표현으로 "성장만 하는 위키는 결국 붕괴할 위키다."
- **④ 오류 복리**: LLM이 만든 오류가 위키에 들어가면, 다음 수집 때 그 오류 위에 새 합성 페이지가 쌓인다. 환각이 **복리로 증폭**된다.

여기에 두 가지 물리적 천장이 더해진다.

- **토큰 천장**: 약 **10만 토큰** 이상 위키는 단일 컨텍스트 윈도우에 들어가지 않는다. 2계층 분할로 풀려 하면 결국 RAG를 재발명하게 된다. "로컬 위키" 패턴의 실효 상한은 대략 **300~500개 마크다운 파일**로 추정된다(출처: Innobu, decodethefuture).
- **그래프뷰의 구조적 한계**: 옵시디언 네이티브 그래프뷰는 노드 클릭·줌·팬이 전부다. **그래프 위 직접 편집, 새 연결 생성, 재배치 영구 저장 — 어느 것도 지원하지 않는다.** 노트 300개를 넘어가면 엉킨 실타래가 되어 탐색보다 감상용이 된다.

마지막으로 **설정 오버헤드**. cron·git hook·Python 스크립트·Zettelkasten 원칙 준수가 모두 필요해, 옵시디언 커뮤니티 자체가 "실제 작업 대신 남의 설정 구경에 빠진다"고 자조한다. 생산성 시스템 관리가 본업을 잠식하는 구조다.

---

## 5. 영향 및 파급 효과 (Impact)

### 실제 효용이 있는 영역
- **소규모 개인 연구(노트 50~200개)**: 독서 노트·논문 요약·결정사항 추적. 세션 간 컨텍스트 전달 비용 절감과 개념 간 예상치 못한 연결 발견은 진짜 가치다.
- **장기 코드베이스 유지(Graphify+Claude Code)**: AST 기반 코드 그래프는 LLM 환각과 무관하게 구조적 사실을 보존한다. 신규 세션에서 "이 프로젝트가 뭐였지"를 다시 설명하는 비용을 줄인다.
- **AI 에이전트 메모리 계층**: `CLAUDE.md`처럼 맥락을 구조적으로 주입하는 방식. (참고로 이 작업 환경의 `memory/` 디렉토리가 이 원리의 경량 버전을 이미 구현 중이다.)

### 기대치를 낮춰야 하는 영역
- **인스타 그래프뷰 재현**: 화려한 시각은 3~6개월 누적의 결과다. 릴스는 "완성된 금광"이지 "금 캐는 과정"이 아니다.
- **대규모 팀 지식관리**: 역할 기반 접근 제어, 동시 편집 충돌 해결, 감사 로그 — 기업 필수 기능이 전부 없다. 2026년 현재 이 공백을 메운 완성 솔루션은 없다.
- **빠르게 변하는 분야**: AI·규제·시장처럼 진실 반감기가 짧은 영역은 합성 페이지가 빠르게 노후화되지만 시스템이 자동 감지하지 못한다.

### "있어보이는 그래프뷰" 인스타 현상 해부
구조는 단순하다. 그래프뷰가 시각적으로 매력적인 구간(노트 100~400개)은 실재하며, 그 구간은 수개월 성실한 수집의 산물이다. **그러나 핵심 역설은 이것이다 — 그래프가 예쁠수록 그것은 탐색보다 전시에 최적화된 상태다.** 실제 작업자는 그래프보다 검색창과 `[[링크]]`를 압도적으로 더 쓴다.

---

## 6. 결론 및 시사점

### 핵심 결론
Karpathy의 LLM Wiki는 **문제 진단은 정확하다**: LLM은 세션 간 기억이 없고, RAG는 일관성이 부족하며, 사전 컴파일이 반복 질의보다 효율적이다. 이 통찰 자체는 유효하다. 그러나 **구현 난이도와 유지보수 비용이 일반적 홍보보다 훨씬 높고**, 성공 사례는 대부분 숙련된 개발자가 단일 도메인 장기 프로젝트에 적용한 경우다.

### 프롬프트 실현 가능성 평가
"키워드를 주면 AI가 학습·구조화하는 간단한 프롬프트" — **기술적으로 완전히 가능하다.** 동작하는 오픈소스 구현이 여럿 존재한다. 함정은 "간단한"이라는 수식어다. 가치를 유지하려면 인간의 주기적 개입(가지치기·오류 수정·방향 조정)이 반드시 필요하며, **완전 자동화는 현재 기술로 불가능**하다. 직접 시도에서 나온 부정적 리포트는 정확한 관찰이었다.

### 세 가지 실용 시나리오
- **A — 즉시 권장**: AI 에이전트의 **프로젝트별 메모리 계층**. `CLAUDE.md` + 결정사항 노트 + Graphify 코드 그래프. 설정 비용 대비 효용이 가장 직접적이다.
- **B — 조건부 권장**: **단일 도메인 개인 지식 누적**(예: 부동산, 트레이딩 전략). 노트 200개 이하 유지 + 정기 가지치기 필수. 그래프뷰는 탐색 도구가 아닌 **건강 체크 지표**로만 사용.
- **C — 비권장**: 모든 분야를 망라하는 "두 번째 뇌". 비대화와 방향 상실은 설계상 피할 수 없는 귀결이며, 이를 막을 자동화가 현재 없다.

### 마지막으로
화려한 그래프뷰를 만든 사람들의 공통점은 도구가 아니라 규율이다. **하나의 주제에 집중해 수개월에 걸쳐 천천히 쌓았다.** 도구는 조건이지 원인이 아니다. 이 시스템을 도입하려면 "AI가 알아서 키워주는 두뇌"가 아니라 "내가 꾸준히 가지치기할 정원"으로 기대치를 재설정하는 것이 첫 단계다.

*(라운드 간 모순: 발견되지 않음.)*
---

## References

- [AI Critique — Karpathy LLM Wiki](https://www.aicritique.org/us/2026/05/08/andrej-karpathys-latest-concept-llm-wiki-and-the-future-of-enterprise-knowledge/)
- [Innobu — Enterprise Reality Check](https://www.innobu.com/en/articles/karpathy-llm-wiki-second-brain-enterprise-reality.html)
- [GitHub — lucasrosati/claude-code-memory-setup](https://github.com/lucasrosati/claude-code-memory-setup)
- [GitHub — safishamsi/graphify](https://github.com/safishamsi/graphify)
- [GitHub Gist — Karpathy 패턴 비판](https://gist.github.com/V-interactions/a0d2a62c1b16d1fecf1bd81e8f611fba)
- [Graphify 공식](https://graphify.net/)
- [decodethefuture — LLM Wiki 3계층](https://decodethefuture.org/en/llm-wiki-karpathy-pattern/)