Karpathy의 LLM 위키 - RAG의 한계를 넘는 새 패턴과 Graphify 사례

이 글에서 다루는 내용

Andrej Karpathy가 2026년 4월 공개한 LLM 위키(LLM Wiki) 개념은 기존 RAG의 한계를 정면으로 짚으면서 큰 파장을 일으켰습니다. 매번 벡터 검색으로 원본을 끌어오는 대신, LLM이 한 번 컴파일해 둔 지식 산출물을 영원히 쿼리하는 패턴을 제안했고, 한 달 만에 NEXUS·agentmemory 같은 후속 프로젝트들이 줄지어 등장했습니다. 이 글은 카파시의 제안 내용, 기존 RAG와 갈라지는 지점, 그리고 같은 원리를 코드베이스에 적용한 Graphify 사례를 정리합니다. 특히 "토큰은 줄어들고 동시에 답변 정확도는 올라간다"는 일견 모순처럼 들리는 가설이 왜 이 패턴에서는 성립하는지 메커니즘 단위로 풀어 봅니다. 기준 시점은 2026년 5월입니다.

---

1. 기존 RAG의 한계 - 매번 검색하는 비용

RAG(Retrieval-Augmented Generation)는 LLM에 외부 지식을 주입하는 표준 패턴입니다. 흐름은 단순합니다.

1. 문서를 작은 청크로 쪼갠다
2. 각 청크를 벡터 임베딩으로 변환해 벡터 DB에 저장
3. 사용자 질의도 같은 모델로 임베딩
4. 코사인 유사도가 높은 청크를 찾아 LLM에 컨텍스트로 전달

이 흐름은 분명한 약점들을 안고 있습니다.

• 같은 질의를 두 번 던져도 매번 임베딩 모델·벡터 DB·LLM을 새로 호출
• 임베딩 유사도는 의미 검색을 흉내내지만, "근처에 있다"가 곧 "맞는 답"을 보장하지 않음
• 청크 단위로 잘려 있어 문서 간 연결·반박·맥락이 사라짐
• 토큰 비용이 사용량에 비례해 누적

RAG가 보편적으로 자리잡은 만큼 이 한계도 함께 누적되어 왔고, "이걸 더 잘하는 방법"이 아니라 "다른 패턴으로 대체하는 법"이 필요해진 시점에 카파시의 제안이 나왔습니다.

---

2. Karpathy의 제안 - "Compile Once, Query Forever"

카파시가 LLM 위키 idea file에서 던진 가장 강력한 한 줄은 다음 비유입니다.

"Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase."

해석하면 사용자는 원본 자료를 던져 넣는 사람이고, LLM은 지식을 컴파일해 정리하는 프로그래머이며, 위키 그 자체가 재사용 가능한 산출물이라는 발상입니다. 한 번 잘 정리해 두면 같은 비용을 다시 치를 필요가 없습니다. VentureBeat 기사가 이 제안을 소개할 때 쓴 표현이 핵심을 잘 짚습니다 — "RAG를 우회한다". 검색을 강화하는 것이 아니라 검색을 줄이는 방향이기 때문입니다.

---

3. LLM 위키의 3계층 구조

카파시의 제안은 단순한 디렉터리 규약 위에 세워집니다.

계층	역할	누가 쓰는가
raw/	원본 자료(논문, 깃허브, 블로그, 영상 전사 등). 불변	사람 (드롭만)
wiki/	LLM이 컴파일한 위키 페이지. 마크다운 + 백링크	LLM
schema.md	디렉터리 구조와 워크플로우 규칙의 단일 진실원	사람

LLM은 raw/에서 읽고 wiki/에 쓰며, schema.md를 따라야 합니다. 위키는 시간이 지날수록 백링크가 촘촘해지고, 페이지 간 모순이 자동으로 표시되며, 콘텐츠 인덱스(index.md)와 작업 로그(log.md)가 함께 유지됩니다. 결과적으로 자료가 누적될수록 가치가 복리로 늘어나는 구조가 만들어집니다.

카파시의 idea file은 Claude Code·Codex·OpenCode·Pi 같은 LLM 에이전트에 그대로 복붙해 쓰도록 설계되었습니다. 사용자가 위키를 직접 쓰는 일은 거의 없고, LLM이 정리·교차 참조·일관성 유지를 모두 담당합니다.

---

4. Graphify - 같은 원리를 코드베이스에 적용

카파시의 제안이 문서·논문·전사를 정리하는 데 초점이 맞춰져 있다면, Graphify는 같은 패턴을 코드와 SQL 스키마, 인프라 설정, 영상까지 확장한 도구입니다. safishamsi/graphify에서 오픈소스로 공개되어 있고, Claude Code·Codex·Cursor·Gemini CLI·OpenCode·Antigravity 등 거의 모든 AI 코딩 어시스턴트와 호환됩니다.

핵심 메시지는 카파시의 위키와 똑같습니다.

"코드베이스 전체를 한 번 컴파일해 두면, 이후의 모든 질의에서 LLM이 파일을 다시 grep할 필요가 없다."

설치는 한 줄입니다. 셸에 다음을 붙여넣으면 CLI가 등록되고, 어시스턴트별 스킬도 함께 설정됩니다.

pip install graphifyy && graphify install

그 뒤로는 어시스턴트 안에서 /graphify . 한 줄이면 현재 폴더 전체가 그래프로 변환됩니다.

---

5. Graphify의 3-Pass 아키텍처

Graphify는 결정론적 처리와 LLM 처리를 명확히 분리합니다. 카파시의 위키가 "LLM이 컴파일러"라면, Graphify는 그 컴파일을 세 단계로 나눠 가장 확실한 단계부터 결정론적으로 끝냅니다.

패스	역할	LLM 사용
Pass 1 AST 추출	tree-sitter로 클래스·함수·임포트·콜 그래프·주석을 결정론적으로 추출	❌
Pass 2 미디어 전사	faster-whisper로 영상·음성을 로컬 전사 (캐시 보관)	❌
Pass 3 의미 추출	Claude 서브에이전트가 병렬로 문서·논문·이미지·전사에서 개념·관계를 추출	✅

핵심 아이디어는 "코드가 처리할 수 있는 일은 코드에 맡기고, LLM은 정말 추론이 필요한 자리에만 쓴다"는 분업입니다. tree-sitter가 19개 언어에서 동일한 노드/엣지 구조를 만들어 주기 때문에, 다음 단계에서 언어별 분기 없이 통일된 그래프를 구성할 수 있습니다.

---

6. 임베딩 없이도 의미 검색이 되는 이유 - Leiden 커뮤니티 검출

세 패스의 결과는 NetworkX 그래프 한 개에 합쳐진 뒤, Leiden 알고리즘으로 클러스터링됩니다. Leiden은 그래프의 위상 — 다시 말해 엣지 밀도만 보고 커뮤니티를 찾기 때문에, 임베딩 모델이나 벡터 DB가 전혀 필요하지 않습니다.

흥미로운 점은 이 시스템에서도 의미적 유사도가 살아있다는 것입니다. Pass 3에서 LLM이 "구조적으로는 연결이 없지만 의미상 가까워 보이는" 노드 쌍을 발견하면 semantically_similar_to 엣지를 추가합니다. Leiden이 이 엣지까지 함께 보고 커뮤니티를 형성하기 때문에, 결과적으로 개념적으로 가까운 노드들이 같은 클러스터에 모입니다. 이 과정에서 임베딩 유사도 계산은 한 번도 일어나지 않습니다.

산출물은 세 가지로 표준화돼 있습니다.

• graph.html — 브라우저에서 클릭·필터·검색 가능한 인터랙티브 시각화
• graph.json — 전체 그래프 데이터 (재처리 없이 다시 쿼리)
• GRAPH_REPORT.md — 사람이 읽기 좋은 평문 감사 리포트

---

7. 가설 검증 - 토큰은 줄고 정확도는 오를 수 있는가

일반적으로 LLM 시스템에서 토큰 절감과 정확도 향상은 상충 관계로 알려져 있습니다. 컨텍스트를 줄이면 정보가 빠지고, 정보가 빠지면 정확도가 떨어집니다. 그런데 카파시-Graphify 패턴은 두 결과가 동시에 나온다고 주장합니다. 가설 검증의 형태로 이 주장을 따져 봅니다.

가설: "compile once, query forever" 패턴에서는 토큰 사용량이 줄면서 답변 정확도가 함께 올라간다. 두 결과가 trade-off가 아니라 같은 원인에서 나오는 부산물이다.

7-1. 메커니즘 분해 - 각 단계가 어디에 기여하는가

3-pass 아키텍처를 단계별로 따져 보면, 각 단계가 토큰과 정확도 모두에 양의 효과를 만든다는 것을 확인할 수 있습니다.

단계	토큰 영향	정확도 영향
Pass 1 — AST 추출	LLM 호출 0회 (tree-sitter 결정론)	코드 구조 100% 정확 (환각 가능성 0)
Pass 2 — 미디어 전사	로컬 실행 + 캐시 → 재전사 시 토큰 0	전사 결과 일관성 보장
Pass 3 — 의미 추출	LLM 1회만, 그래프에 캐시	신뢰도 점수가 붙어 검증 가능
질의 시점	관련 노드만 잘라 전달 → 입력 토큰 일정	정확히 잘린 노드라 노이즈 적음

핵심은 "한 번 정확하게 정리해 두면, 그 정확도가 모든 후속 질의에 그대로 이어진다"는 점입니다. RAG처럼 매 질의마다 의미 검색을 다시 시도하지 않으니, 검색의 부정확성이 누적되지 않습니다.

7-2. RAG와의 직접 비교 - 같은 질의를 N번 했을 때

같은 질의를 100번 던지는 시나리오를 가정하면 두 패턴의 차이가 드러납니다.

관점	기존 RAG	LLM 위키 / Graphify
초기 비용	청크 임베딩 1회 (가벼움)	컴파일 1회 (LLM 토큰 한 번 크게)
매 질의 비용	임베딩 + 벡터 검색 + 청크 N개 컨텍스트 → 입력 토큰 N에 비례	관련 그래프 노드만 → 입력 토큰 거의 일정
100회 누적 토큰	100 × N (선형 증가)	초기 컴파일 + 100 × 작은 상수
의미 정확도	유사도 기반 → 매번 다른 청크가 뽑힐 수 있음	고정된 그래프 → 같은 질의에 같은 노드
맥락 보존	청크 단위로 잘려 문서 간 연결 손실	엣지가 연결을 명시적으로 유지

비용 곡선의 차이는 단순합니다. RAG는 사용량에 비례해 직선적으로 늘어나고, Graphify는 큰 초기 비용 한 번 뒤로 거의 평평합니다. 두 곡선이 만나는 지점(손익분기) 이후로는 사용량이 늘어날수록 격차가 벌어집니다.

7-3. 가설은 어디까지 일반화되는가

위 메커니즘이 작동하려면 두 가지 조건이 필요합니다.

• 같은 자료를 반복 질의하는 패턴 — 1회성 질의에서는 컴파일 비용이 회수되지 않습니다. 자료가 안정적이고 사용량이 누적되는 경우에 효과가 큽니다.
• 구조화 가능한 자료 — 코드, 문서, 논문처럼 명확한 노드·엣지가 존재해야 합니다. 자유 형식 대화 로그처럼 구조가 약한 자료에는 효과가 제한적입니다.

두 조건이 맞으면 가설은 메커니즘적으로 성립합니다. 절댓값(몇 배 절감인지)은 저장소 크기·질의 패턴·언어 분포에 따라 달라지지만, 방향성(토큰↓·정확도↑)은 일관됩니다. 본인 환경에 적용해 직접 측정해 보시면 두 곡선의 형태를 가장 확실하게 확인하실 수 있습니다.

---

8. 한계와 적용 시 주의점

두 패턴 모두 강력하지만 만능은 아닙니다. 도입 전에 알아두면 좋은 한계 몇 가지를 짚어 둡니다.

• 초기 컴파일 비용: 위키든 그래프든 처음 한 번은 LLM 토큰이 크게 듭니다. "compile once"의 비용은 결국 한 번에 몰려 있습니다. 작은 저장소·소량 자료부터 시도해 흐름을 익히는 편이 안전합니다.
• 지속적 갱신 필요: 코드가 자주 바뀌면 그래프도 자주 다시 만들어야 합니다. Graphify는 graphify hook install로 git commit마다 자동 재빌드하는 옵션을 제공합니다.
• LLM 환각의 잔류: Pass 3(의미 추출)에서는 여전히 LLM이 일부 잘못된 관계를 만들어 낼 수 있습니다. INFERRED 플래그와 신뢰도 점수가 붙어 있어, 나중에 검토할 때 구분할 수 있게 되어 있습니다.
• 정확도 검증의 책임: 위키든 그래프든 일정 시점에 사람이 한 번씩 감사해 주지 않으면 모순이 누적됩니다. 카파시 idea file에 WikiLinterAgent가 명시된 이유입니다.

---

마무리

Karpathy의 LLM 위키가 큰 반향을 일으킨 이유는 RAG를 더 잘 만드는 법이 아니라 RAG를 다른 패턴으로 대체하는 법을 제시했기 때문입니다. Graphify는 이 패턴이 문서뿐 아니라 코드에도 그대로 통한다는 것을 보여 준 첫 실무 사례입니다. 두 도구의 메시지는 한 줄로 정리됩니다.

검색을 빨리 하지 말고, 검색이 필요 없는 산출물을 먼저 만들어 두자.

당장 적용할 수 있는 출발점은 두 가지입니다. 자기 노트나 연구 자료가 쌓여 가는데 정리할 엄두가 안 난다면 카파시의 LLM 위키 패턴을 raw + wiki + schema 3계층으로 시도해 보시기 바랍니다. 코드베이스에 LLM을 자주 던지고 있다면 위에서 본 한 줄 명령으로 Graphify를 도입해 토큰 사용량부터 측정해 보면 변화가 즉시 체감됩니다.

• Karpathy LLM Wiki gist: gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
• VentureBeat 보도: RAG를 우회하는 LLM 지식 베이스 아키텍처
• Graphify 공식: graphify.net
• Graphify GitHub: github.com/safishamsi/graphify
• tree-sitter AST 추출 (19개 언어): graphify.net/tree-sitter-ast-extraction
• Leiden 커뮤니티 검출 (임베딩 없는 클러스터링): graphify.net/leiden-community-detection

관련 글

함께 읽으면 좋은 글

• 클로드 토큰 절약 방법 - 비용 레버 8가지
• Claude Code 설치 및 활용 완벽 가이드