Karpathy LLM Wiki 패턴: 한국어 종합 정리 (kmyu99 Notion)

요약

Andrej Karpathy가 2026년 4월 4일 GitHub Gist로 공개한 LLM Wiki 아이디어 파일을 중심에 두고, 한국어 커뮤니티의 후속 논의를 한 문서로 합친 기술 리포트다. 저자 kmyu99가 2026년 5월 6일 개인 Notion에 작성했고, 최상위 11개 절로 구성된다.

합성한 자료는 다섯 편이다. Karpathy의 영어 Gist가 중심이고, 박재홍의 실리콘밸리 위키독스 글, GeekNews의 요약과 Hacker News 의견 정리, unclejobs-ai의 한국어 번역본과 역자 주석, nashsu/llm_wiki 구현 분석이 여기에 붙는다.

이 글이 11.1절에 출처로 적은 gist 주소는 https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f 다.

핵심 주장은 RAG와 LLM Wiki의 차이가 검색 기술이 아니라 지식 관리 워크플로에 있다는 것이다. RAG는 질의(query)가 들어올 때마다 같은 지식을 처음부터 다시 찾아 조립하지만, LLM Wiki는 소스를 받아들이는 시점에 지식을 한 번 컴파일해 두고 그 결과를 계속 갱신한다. 그래서 위키는 질문을 던질수록 풍부해지는 산출물이 된다.

문서의 값어치는 원문 패턴 소개보다 그 주위에 붙은 것들에 있다. 여섯 가지 비판을 반론과 함께 정리했고, 한국어 사용자가 실제로 부딪히는 아홉 가지 운영 문제를 목록으로 만들었으며, 점검용 프롬프트 전문을 그대로 실었다.

읽는 순서로 보면 앞의 여섯 절이 패턴을 세우고, 7장이 그 패턴을 흔들며, 9장과 10장이 실제로 쓸 때의 조건을 붙인다. 패턴 소개만 필요하다면 2장에서 5장까지로 충분하고, 도입 여부를 판단하려면 7장과 10장을 함께 봐야 한다.

배경

원문의 성격과 공개 맥락

이 글이 다루는 원문은 Andrej Karpathy가 2026년 4월 4일 GitHub Gist로 공개한 파일이다. 저자는 전 Tesla AI 디렉터이자 OpenAI 창업 멤버로 소개된다.

원문의 성격은 완성된 소프트웨어가 아니라 아이디어 파일이다. 구체적 구현을 배포한 것이 아니라 패턴을 전달하는 문서이고, Claude Code나 OpenAI Codex 같은 LLM 에이전트에 그대로 복사해 넣어 쓰도록 설계돼 있다. Gist 한 편이 곧 실행 가능한 지시문 역할을 하는 셈이다.

공개 배경으로는 Karpathy 본인의 말이 인용된다. 최근 코드보다 개인 지식 저장소를 구축하는 데 토큰을 더 많이 쓰고 있다는 것이다. 도구를 만들던 사람이 도구로 지식을 쌓는 쪽으로 시간을 옮겼다는 신호다.

반응은 컸다. Hacker News에서 댓글 700개가 넘게 달렸고, Gist는 별과 포크를 5,000개 이상 받았으며, 한 달 만에 다수의 구현체가 등장했다. 이 글은 그 한 달 사이에 쌓인 한국어 논의를 정리하려고 쓰였다.

문서 구성

원문은 최상위 11개 절로 짜여 있고, 앞의 여섯 절이 패턴 설명, 뒤의 다섯 절이 비판과 적용과 출처를 맡는다.

8장 전체가 구현 사례에 배정돼 있는데 그 안의 세 소절이 취소선 상태라는 점이 이 문서의 특이한 지점이다. 자세한 내용은 아래 결과 절에서 다룬다.

질의마다 반복되는 재발견

일반적인 LLM 문서 워크플로는 RAG다. 파일을 올리면 시스템이 문서를 chunk로 잘라 vector database에 넣고, 질문이 들어오면 관련 chunk를 검색해 답변을 만든다. NotebookLM, ChatGPT 파일 업로드, 시중 대부분의 RAG 제품이 이 구조를 쓴다.

이 구조의 근본 문제는 LLM이 매 질의마다 지식을 처음부터 찾아야 하고 같은 것을 재발견한다는 점이다. 문서 다섯 편을 종합해야 답할 수 있는 미묘한 질문이라면, 같은 질문을 내일 다시 물어도 LLM은 어제와 똑같이 처음부터 조립한다.

사라지는 것은 답변만이 아니다. 이전 질의에서 발견한 문서 사이의 연결고리, 자료끼리 어긋나는 지점, 여러 자료를 겹쳐 얻은 해석이 전부 채팅 히스토리와 함께 없어진다. 지식이 축적되지 않는다.

위키를 LLM이 쓰게 한다는 전환

LLM Wiki는 LLM에게 인덱싱이 아니라 위키의 저술과 유지를 맡긴다. 사람이 페이지를 쓰지 않고 LLM이 쓰고 관리한다.

새 소스가 들어오면 LLM이 하는 일은 네 가지다. 소스를 읽고 핵심 정보를 추출하고, 기존 위키에 통합하면서 entity와 개념 페이지를 갱신하고, 새 데이터가 기존 주장과 어긋나면 그 자리를 표시하고, 진화 중인 종합 분석을 강화하거나 반박한다.

그 결과 지식은 한 번 컴파일되고 최신 상태로 유지된다. 질의 시점에 재도출하지 않는다.

문서의 성격

이 문서는 1차 자료의 요약이 아니라 다수 자료의 한국어 합성이다. 영어 Gist 한 편과 한국어 자료 세 편, 구현체 분석 한 편을 출처를 밝혀 엮었고, 자체 실험이나 벤치마크는 없다.

원문 8장의 세 소절은 Notion 원문에서 취소선으로 표시돼 있다. 8.1 Farzapedia, 8.2 Karpathy가 정리한 네 가지 장점, 8.3 nashsu/llm_wiki 구현 상세가 여기 해당한다. 취소선을 붙인 이유는 문서 안에 설명돼 있지 않으므로, 이 페이지는 해당 내용을 기록하되 취소선 상태라는 사실을 함께 남긴다.

합성한 자료

11장이 밝힌 출처를 발행 순서로 늘어놓으면 논의가 어떻게 번져 나갔는지가 보인다.

세 한국어 자료가 각각 다른 몫을 맡는다. GeekNews가 영어권 반응을 옮겼고, unclejobs-ai가 번역과 실전 주석을 더했으며, 박재홍이 비판적 분석을 맡았다. 이 글은 세 자료를 한자리에 모아 원문의 주장과 나란히 놓는다.

여기에 Hacker News 스레드(item 47640875)와 Karpathy의 X 후속 트윗이 더해진다. 스레드에서는 베이스라인 비교 부재, 모델 붕괴 우려, 권한과 다중 사용자 문제가 제기됐고, 후속 트윗에서는 Farzapedia가 좋은 실사례로 언급되고 네 가지 장점이 정리됐다.

핵심 개념

persistent compounding artifact는 한 번 컴파일된 뒤 최신 상태로 유지되는 지식 산출물을 뜻한다. 이 문서가 위키의 정체를 규정하는 말이다. 교차 참조가 이미 걸려 있고, 모순점이 이미 표시돼 있으며, 종합 분석이 이미 모든 자료를 반영한 상태다. 그래서 소스를 더 넣을수록, 질문을 더 던질수록 위키가 풍부해진다.

**재발견(re-discovery)**은 LLM이 매 질의마다 같은 지식을 처음부터 다시 찾아내는 것을 뜻한다. 이 문서가 RAG의 근본 문제로 지목하는 현상이며, 위키가 없애려는 낭비가 바로 이것이다.

**북키핑(bookkeeping)**은 교차 참조 갱신, 요약 갱신, 모순 표시, 일관성 유지처럼 지식 베이스를 유지하는 데 드는 기록 관리 작업을 가리킨다. 이 문서는 위키 유지의 실제 장벽이 읽기나 사고가 아니라 북키핑이라고 본다.

사전 컴파일과 런타임 조립의 구분은 "이건 결국 RAG 아니냐"는 비판에 대한 반론의 핵심이다. RAG는 질의 시점에 조각을 모아 답을 조립하고, LLM Wiki는 수집 시점에 이미 조립을 마쳐 둔다. 검색 알고리즘이 아니라 조립을 언제 하느냐가 다르다는 주장이다.

Schema는 위키 구조와 컨벤션, 유지 관리 워크플로를 정의하는 파일이다. Claude Code는 CLAUDE.md, Codex는 AGENTS.md를 쓴다. 이 파일이 LLM을 범용 챗봇이 아니라 체계적인 위키 관리자로 바꾼다.

**고아 페이지(orphan page)**는 다른 어떤 페이지에서도 인바운드 링크를 받지 못한 위키 페이지다. 위키가 커질수록 늘어나며, 점검 작업의 대표 검사 항목이다.

**손실 압축(lossy compression)**은 원문을 위키 페이지로 다시 쓰는 과정에서 정보가 빠지는 현상을 가리킨다. 이 문서는 이것을 패턴의 구조적 위험으로 다룬다.

아이디어 파일은 원문 Gist의 성격을 규정하는 말이다. 실행 가능한 소프트웨어가 아니라 패턴을 적은 문서이고, 에이전트에 복사해 넣으면 그대로 운영 지시문이 된다. 그래서 이 패턴에는 설치할 것이 없고 채택할 규약만 있다.

방법

3계층 아키텍처

시스템은 소유권과 가변성을 기준으로 세 층으로 나뉜다.

Raw Sources는 사용자가 직접 골라 모은 문서 더미이자 정보의 원(source of truth)이다. LLM은 읽을 수 있지만 절대 수정하지 않는다. 이 규칙이 지켜져야 위키에서 요약 오류가 발견됐을 때 원문으로 돌아가 검증할 수 있다.

Wiki는 LLM이 생성한 마크다운 디렉토리로, 요약과 entity 페이지, 개념 페이지, 비교 자료, 개요, 종합 분석을 담는다. 새 원본이 도착하면 LLM이 페이지를 갱신하면서 상호 참조를 관리하고 내용을 일관되게 유지한다. 사용자는 읽기만 한다.

Schema는 사람과 LLM이 함께 발전시키는 유일한 층이다. 사용자가 운영 규칙을 넣고, 운영하다 부딪힌 문제를 다시 규칙으로 반영하는 식으로 시간이 지나며 두꺼워진다.

각 층의 쓰기 권한이 다르다는 점이 이 구조의 핵심이다. 사람만 쓰는 층, LLM만 쓰는 층, 둘이 같이 쓰는 층이 분리돼 있어서 누가 무엇을 망가뜨렸는지 추적할 수 있다.

이 경계는 저절로 지켜지지 않는다. 9.4절이 스키마의 필수 항목으로 금지 사항을 꼽으면서 원시 소스 수정 금지와 원문 통째 복사 금지를 예로 든 것이 그래서다. 앞의 금지는 Raw 층을 불변으로 지키고, 뒤의 금지는 Wiki 층이 원문을 그대로 옮겨 담아 요약이라는 제 몫을 놓지 않게 한다.

Karpathy 본인의 사용 방식은 이 구조를 소프트웨어 개발에 빗댄다. Obsidian이 IDE, 내용을 고치는 LLM이 프로그래머, 위키가 코드베이스에 해당한다.

역할 분담도 명시된다. 사람은 소스 큐레이션과 탐색 방향 결정, 질문 던지기를 맡는다. LLM은 요약, 교차 참조, 분류, 기록 관리 같은 허드렛일을 전부 맡는다.

세 가지 작업

운영은 세 작업의 반복이다. 시점과 산출물이 각각 다르다.

세 작업의 시점이 겹치지 않는다는 점이 이 구조의 요령이다. 수집은 소스가 들어올 때, 질의는 대화 중에, 점검은 주기적으로 일어난다. 사람이 세 가지를 동시에 신경 쓸 필요가 없고, 각 시점에 LLM이 무엇을 해야 하는지가 Schema에 이미 적혀 있다.

세 작업은 서로에게 입력을 준다. 수집이 페이지를 만들면 질의가 그 페이지를 읽고, 질의가 만든 좋은 답변이 다시 페이지가 되며, 점검이 그렇게 불어난 페이지들의 정합성을 확인해 다음 수집 대상을 제안한다.

수집

수집의 특징은 파급 범위다. 소스 하나를 넣으면 위키 페이지 10개에서 15개가 영향을 받는다. 요약 페이지 하나만 새로 생기는 것이 아니라, 인덱스가 갱신되고 그 소스가 언급한 entity와 개념 페이지가 함께 고쳐지고 로그에 항목이 붙기 때문이다.

수집에는 두 가지 운영 방식이 있다.

페이지 10~15개라는 숫자는 6장의 경제학 논증과 직접 이어진다. 사람이 소스 하나를 읽고 관련 문서 열 곳 이상을 손으로 고쳐야 한다면 위키는 오래가지 못한다. 이 패턴이 성립하는 조건은 그 열 몇 번의 수정을 LLM이 빠짐없이 해낸다는 것이다.

질의

질의는 위키를 대상으로 질문하고, 관련 페이지를 검색해 읽고, 인용과 함께 답변을 합성하는 흐름이다. 출력 형태는 질문에 따라 달라진다. 마크다운 페이지, 비교 테이블, Marp 슬라이드 덱, matplotlib 차트, 캔버스가 모두 가능하다.

이 작업에서 문서가 강조하는 것은 좋은 답변을 위키에 새 페이지로 되돌려 저장할 수 있다는 점이다. 비교 분석, 새로 찾아낸 연결고리, 심층 분석이 채팅 히스토리로 사라지지 않고 다음 질의의 재료가 된다. 탐색 활동 자체가 지식 베이스에 쌓인다.

질의가 수집과 같은 방향으로 작동한다는 뜻이기도 하다. 보통의 시스템에서 읽기는 상태를 바꾸지 않지만, 여기서는 질문 한 번이 페이지 한 장을 남길 수 있다. 위키가 소스 개수가 아니라 사용 횟수에 비례해 커지는 이유가 여기 있다.

점검

점검은 주기적으로 위키의 상태를 확인하는 작업이다. 검사 항목은 여섯 가지다.

• 페이지 간 모순
• 새 소스에 의해 대체된 낡은 주장
• 인바운드 링크 없는 고아 페이지
• 언급만 되고 자체 페이지가 없는 중요 개념
• 누락된 교차 참조
• 웹 검색으로 채울 수 있는 데이터 공백

문서는 LLM이 조사할 새 질문과 찾아볼 새 소스를 제안하는 데 특히 뛰어나다고 덧붙인다. 점검이 결함 목록을 뽑는 데 그치지 않고 다음 수집 대상을 정하는 단계로도 쓰인다는 뜻이다.

임베딩 없는 인덱싱

이 패턴은 vector database 없이 마크다운 파일 두 개로 검색을 대신한다.

두 파일이 나누는 것은 검색의 두 방향이다. index.md는 무엇이 있는지를 주제로 찾게 해 주고, log.md는 언제 무슨 일이 있었는지를 시간으로 찾게 해 준다. vector database가 하던 일을 목차와 일지가 나눠 맡는 구성이다.

log.md는 일관된 접두사를 쓰면 unix 도구로 파싱할 수 있다. 문서가 든 예시 형식은 ## [2026-04-02] ingest | Article Title 이고, 최근 다섯 항목은 다음 한 줄로 뽑는다.

grep "^## \[" log.md | tail -5

이 방식이 통하는 범위에는 상한이 있다. 소스 약 100개, 페이지 수백 개 규모까지는 임베딩 기반 RAG 인프라 없이 잘 작동한다고 본다.

그 이상으로 커지면 선택적으로 CLI 도구를 붙인다. 문서가 권하는 것은 qmd다. 마크다운용 로컬 검색 엔진이고, BM25와 벡터 하이브리드에 LLM reranking을 결합하며, 온디바이스로 동작하고, CLI와 MCP 서버를 모두 지원한다.

Obsidian 보조 도구

문서는 Obsidian 주위의 보조 도구를 용도와 함께 나열한다.

이미지 로컬 다운로드에는 주의 사항이 붙는다. 이 작업은 URL이 깨질 수 있는 상황에 의존하지 않게 해 주고 LLM이 이미지를 직접 보게 해 주지만, LLM은 인라인 이미지가 포함된 마크다운을 한 번에 원시적으로 읽지 못한다. 해결책은 LLM이 먼저 텍스트를 읽고, 그다음 참조된 이미지의 일부 또는 전부를 별도로 확인해 추가 맥락을 얻게 하는 것이다. 문서는 이 절차가 조금 번거롭지만 충분히 잘 작동한다고 적는다.

적용 영역

패턴을 쓸 수 있는 영역으로 다섯 가지가 제시된다.

다섯 영역의 공통점은 자료가 한 번에 다 모이지 않고 시간을 두고 들어온다는 것이다. 논문을 한 편씩 읽거나 미팅을 한 번씩 하거나 챕터를 한 장씩 넘기는 식이다. 그래서 새 자료가 기존 이해를 갱신하는 일이 반복되고, 그 갱신을 누가 기록하느냐가 문제가 된다.

유지보수 비용이라는 관점

문서가 이 패턴의 진짜 통찰로 꼽는 것은 경제학이다. 지식 베이스를 유지하는 데 드는 부담은 읽기나 사고가 아니라 북키핑이다. 교차 참조를 갱신하고, 요약을 갱신하고, 모순을 표시하고, 일관성을 유지하는 일이 사람을 지치게 한다.

사람들이 위키를 포기하는 이유도 여기서 나온다. 유지 관리 부담이 위키가 주는 가치보다 빠르게 증가하기 때문이다.

LLM은 정확히 이 부담에 강하다. 지루함을 모르고, 교차 참조 갱신을 잊지 않으며, 한 번에 파일 15개를 처리할 수 있다. 유지 관리 비용이 거의 0에 수렴하면서 개인 지식 관리의 경제학 자체가 바뀐다는 것이 문서의 결론이다.

역사적 계보로는 Vannevar Bush의 Memex(1945)가 언급된다. 개인적이고 능동적인 큐레이션이라는 점, 문서 사이의 연결이 문서 자체만큼 가치 있다고 본 점이 같다. Bush가 풀지 못한 "누가 유지보수하느냐"를 LLM이 담당한다는 것이 이 패턴의 위치다.

Memex가 남긴 문제를 다시 보면 이 패턴이 무엇을 해결했는지가 분명해진다. Bush의 구상에서 연결을 만들고 유지하는 주체는 사람이었고, 그래서 저장소가 커질수록 사람이 감당해야 할 몫도 함께 커졌다. LLM은 그 몫을 대신 맡을 수 있는 첫 후보다.

11.5절은 관련 개념으로 J.C.R. Licklider의 "Man-Computer Symbiosis"(1960)도 든다. 인간과 컴퓨터가 각자 잘하는 일을 나눠 맡는다는 구상이며, 사람이 방향을 정하고 LLM이 기록을 관리한다는 이 패턴의 역할 분담과 같은 계보에 놓인다.

한국어 운영 아홉 항목

9장은 unclejobs-ai의 한국어 번역본에 달린 역자 주석에서 발췌한 것으로, 한국어 사용자가 실제로 부딪히는 문제를 다룬다. 원문 Gist가 영어권 환경을 전제로 쓰였기 때문에 파일명과 검색에서 먼저 문제가 생기고, 그다음이 도구 연동과 운영 규칙, 마지막이 비용 감각이다.

몇 항목은 세부가 더 있다.

9.1의 태그 처리는 frontmatter에 한국어와 영어 태그를 함께 적는 것이다. 예로 tags: [인공지능, artificial-intelligence]처럼 쓰면 Dataview 질의에서 양쪽이 모두 잡힌다.

9.2가 말하는 교착어는 어간에 조사와 어미가 붙어 같은 낱말이 여러 표면형으로 나타나는 언어 유형이다. 형태소 분석 없이 문자열만 맞춰 보는 검색이 한국어에서 잘 듣지 않는 이유가 여기 있다.

9.2는 대책을 세 가지 제시한다. 먼저 qmd의 한국어 토크나이징 지원 여부를 확인해야 한다. 확인이 어려우면 차선책으로 index.md에 영어 키워드를 병기한다. 대안으로는 BM25의 한글 약점을 보완하는 가드레일을 두는 방법이 있고, kurthong의 seCall이 사례로 붙어 있다.

9.3의 연동 방식은 Claude Code 세션을 vault 루트에서 여는 것이다. 주의 사항은 세 가지다. .obsidian/ 설정 디렉토리를 LLM이 건드리지 않도록 스키마에 명시하고, Linter 플러그인으로 LLM이 쓴 마크다운을 자동 정규화하며, Templater로 페이지 템플릿을 미리 만들어 두면 지시가 편해진다.

9.4가 꼽는 스키마 필수 항목은 다섯 가지다. 디렉토리 구조(raw/, wiki/, wiki/entities/ 등), 페이지 템플릿(entity와 소스 요약과 개념 페이지의 frontmatter 및 필수 섹션), 네이밍 규칙(kebab-case, [[위키링크]]와 마크다운 링크의 구분), 수집 워크플로 체크리스트, 금지 사항(원시 소스 수정 금지, 원문 통째 복사 금지)이다.

9.5는 도입 시점을 숫자로 못박는다. Claude Code라면 .mcp.json에 등록하고, 위키가 50페이지를 넘으면 진지하게 고려할 가치가 있다고 본다. 셸 명령어로 검색하는 것과 네이티브 도구로 호출하는 것의 차이가 이 규모부터 벌어진다는 판단이다.

9.6은 두 층으로 나눈다. 1차 레이어가 위키(컴파일된 지식)이고 2차 레이어가 원시 소스 RAG(원문 검증 도구)다. 위키에서 답을 얻되 의심스러우면 원문으로 내려가는 구조다.

9.7은 원문에 명시되지 않은 실전 가치로 소개된다. 새 세션을 열 때마다 어제까지의 분석이 사라지는 문제를 스키마 한 줄로 해결한다는 것이다.

9.8은 비용 감각을 두 방향으로 제시한다.

점검 프롬프트

9.9절이 제공하는 프롬프트는 다음과 같다.

위키 상태를 점검해줘. 아래 항목을 순서대로 확인하고 결과를 보고해:

1. index.md에 등록되었지만 실제 파일이 없는 항목 (깨진 링크)
2. 파일은 있지만 index.md에 누락된 페이지 (미등록 페이지)
3. 다른 페이지에서 한 번도 링크되지 않은 고아 페이지
4. 2개 이상의 페이지에서 서로 모순되는 주장
5. 언급은 되지만 자체 페이지가 없는 주요 개념
6. source_count가 3 이상인데 요약이 1문단 이하인 빈약한 페이지
7. 최근 수집된 소스가 기존 주장을 업데이트했어야 하는데 반영 안 된 곳

각 항목에 대해 발견 사항과 구체적인 수정 제안을 함께 알려줘.

4장의 점검 항목 여섯 가지와 견주면 검사 대상이 넓어졌다. 4장이 위키 내부의 의미 문제(모순, 낡은 주장, 고아 페이지, 미생성 개념, 누락 교차 참조, 데이터 공백)를 보는 데 비해, 이 프롬프트는 index.md와 실제 파일의 정합성(1번, 2번)과 페이지 품질(6번)까지 검사한다.

추가된 항목이 모두 기계로 확인할 수 있는 것이라는 점도 눈에 띈다. 링크가 깨졌는지, 파일이 인덱스에 등록됐는지, 요약이 한 문단을 넘는지는 판단이 아니라 대조로 답할 수 있다. 반면 4장의 모순 검출은 판단을 요구한다. 두 종류를 한 프롬프트에 담아 LLM에 한꺼번에 시키는 구성이다.

항목 6번의 source_count는 페이지 frontmatter에 소스 개수를 적어 둔다는 전제를 깔고 있다. 5장이 index.md의 메타데이터로 소스 수를 들고 9.1절이 frontmatter 태그 병기를 권한 것과 이어지는 설계다.

RAG 실무자 관점

10장은 이 패턴의 위치를 검색 기술의 새 패러다임이 아니라 지식 관리 워크플로의 재구성으로 규정한다. nashsu의 관련성 모델과 질의 파이프라인은 결국 그래프 RAG에 가깝다고 본다. 그래서 "RAG가 아니다"라는 프레이밍을 곧이곧대로 받지 말고, hybrid search와 사전 컴파일된 지식 레이어의 조합으로 이해하기를 권한다.

적용 판단은 두 목록으로 갈린다.

두 목록을 가르는 기준은 하나로 모인다. 손실 압축을 감당할 수 있느냐다. 적합 목록의 네 가지는 요약이 조금 거칠어도 다시 원문을 보면 되는 작업이고, 신중 목록의 세 가지는 요약 오류가 그대로 결과가 되거나 원문이 계속 바뀌어 위키가 뒤처지는 작업이다.

기존 기법과의 연결도 짚는다. GraphRAG, multi-hop 검색, 계층적 요약, BM25와 벡터를 섞는 hybrid search가 자연스럽게 이어지며, 기존 도구만으로도 충분히 구현할 수 있다. Karpathy의 기여는 새 알고리즘이 아니라 워크플로와 철학 측면에 있다는 평가다.

이 관점은 7.1의 반론과 겹치면서도 한 걸음 물러선다. 7.1이 RAG와 다르다고 반박한 자리에서, 10장은 다르다는 프레이밍을 곧이곧대로 받지 말라고 권한다. 같은 문서 안에서 원문의 주장과 실무자의 유보가 나란히 놓인 셈이다.

결과

이 문서는 합성 article이라 자체 벤치마크가 없다. 인용한 수치는 다음과 같다.

Gist 댓글에서 발견된 구현체 12개는 paulshomo/co-wiki, gowtham0992/link, jgoldfed/keppi, doum1004/llmwiki-cli, cagataysengor/llm-wiki-studio, kytmanov/obsidian-llm-wiki-local, tuirk/Kompl, swarmclawai/swarmvault, skyllwt/OmegaWiki, axoviq-ai/synthadoc, theafh/ai-modules, hang-in/seCall이다.

수치를 읽을 때 유의할 점은 전부 인용치라는 것이다. 별 수와 댓글 수는 원문 1장이 보고한 값이고, 페이지 10~15개라는 파급 범위도 Karpathy가 제시한 규모 감각이지 계측 결과가 아니다. 이 글은 그 값들을 재검증하지 않고 옮긴다.

세 개의 임계치가 서로 다른 층위를 가리킨다는 점도 눈여겨볼 만하다. 소스 100개는 임베딩 없이 운영할 수 있는 자료 규모, 50페이지는 MCP 서버 도입을 검토할 페이지 규모, 100페이지는 검색 도구가 필요해지는 페이지 규모다. 앞의 하나는 자료를 세고 뒤의 둘은 산출물을 센다.

출처 구조

11장은 인용한 자료를 다섯 묶음으로 나눈다.

출처를 이렇게 층으로 나눈 것 자체가 이 글의 방법이다. 원문 하나에 번역과 요약과 비판과 구현체를 각각 다른 묶음으로 붙여, 어느 주장이 Karpathy의 것이고 어느 주장이 한국어 커뮤니티의 해석인지 구분할 수 있게 했다.

취소선으로 표시된 구현 사례

아래 세 항목은 원문 8.1절에서 8.3절에 있고, Notion 원문에서 취소선으로 표시돼 있다. 취소선의 의도를 문서가 밝히지 않았으므로 폐기인지 재검토인지 판단할 근거는 없다. 다만 같은 내용이 11장의 출처 설명에는 취소선 없이 남아 있어, 사실 자체를 부정한 것으로 보기는 어렵다.

Farzapedia는 Karpathy 본인이 좋은 사례로 언급한 구현이다. 일기와 Apple Notes, iMessage를 합쳐 2,500건을 입력해 위키 문서 400개를 자동 생성했다. 친구, 스타트업, 좋아하는 애니메이션, 영감 이미지까지 백링크로 연결한다.

입력 2,500건에서 문서 400개가 나왔다는 것은 여러 기록이 한 문서로 묶였다는 뜻이다. 일기와 메시지를 그대로 옮긴 것이 아니라 인물과 주제 단위로 다시 조직했다는 신호다.

설계 목적이 특이하다. 사용자가 읽으려고 만든 위키가 아니라 에이전트가 활용하는 지식 베이스로 만들었다. Claude Code를 위키에 연결하고 index.md를 진입점으로 삼아 에이전트가 직접 탐색하게 한다. 1년 전에 RAG 기반으로 시도했으나 성능이 부족해 파일시스템 직접 탐색으로 바꿨다는 이력도 붙어 있다. 새 항목을 추가하면 관련된 기존 문서 2~3개를 자동으로 갱신하거나 새 문서를 만든다.

Karpathy가 정리한 네 가지 장점은 기존 AI 개인화 방식과 대비해 제시된다.

이 절은 에이전트 활용 능력이 21세기의 핵심 스킬이라는 문장으로 맺는다.

nashsu/llm_wiki는 Karpathy 패턴을 Tauri 데스크탑 앱으로 구현한 것으로, GitHub 별 23개다. 구현 요소는 네 가지다.

관련성 모델의 네 신호는 가중치가 다르다.

가중치 순서에서 Source overlap이 Direct link보다 높다는 점이 눈에 띈다. 같은 원본에서 나온 페이지들이 명시적 링크보다 더 강한 관련성 신호로 취급된다는 설계다.

질의 파이프라인은 네 단계다.

이 앱은 다국어를 지원하고 Chrome 확장(웹 클리퍼)과 멀티 포맷(PDF, DOCX, PPTX, XLSX)을 다룬다.

그 밖의 구현 사례

8.4절은 취소선 없이 다섯 가지를 든다.

이 다섯은 앞의 두 사례와 위치가 다르다. Farzapedia와 nashsu가 패턴을 어디까지 밀어붙일 수 있는지 보여 주는 사례라면, 8.4절의 목록은 공개 한 달 사이에 여러 사람이 같은 패턴을 각자의 도구로 옮겼다는 사실 자체를 보여 준다. joonan30의 항목이 31일의 누적을 제목에 달고 있는 것도 같은 맥락이다.

한계

여섯 가지 비판

7장은 이 패턴을 향한 비판을 반론과 함께 정리한다.

여섯 항목 중 7.3과 7.5는 반론이 붙지 않는다. 손실 압축과 검증 부재는 이 문서도 열린 문제로 남겨 둔다.

반론이 붙은 세 항목도 성격이 다르다. 7.1은 개념 정의를 다시 하는 반론이고, 7.2는 비판이 겨눈 대상을 학습에서 운영으로 옮기는 반론이며, 7.4는 상대의 전제인 컨텍스트 확장이 실제로는 한계를 없애지 못한다는 반론이다. 세 반론 모두 새 실험이 아니라 논증으로 답한다.

7.2와 7.3은 서로 이어진다. 모델 붕괴 논의는 학습 맥락이라 적용되지 않는다고 반박하면서도, 요약을 다시 요약할 때 뉘앙스가 빠진다는 점은 인정한다. 그 인정이 곧 7.3의 손실 압축 문제이고, 그래서 원본을 불변으로 두고 언제든 되돌아갈 수 있게 하는 3계층 구조가 방어 수단으로 남는다.

7.6은 다른 다섯 항목과 성격이 다르다. 시스템의 결함이 아니라 사용자에게 생기는 변화를 다루며, 근거도 벤치마크가 아니라 한 개발자의 경험담이다. 이 글은 그 후기를 반박하지 않고 그대로 싣는다.

7.5의 결론은 적용 범위를 좁히는 쪽이다. 소규모에서 중규모, 느린 변화, 사람이 큐레이션하는 연구 폴더에는 유용하다. 대규모나 빠른 변화, 고위험, 멀티유저, 엔터프라이즈 환경에는 검증이 필요하다.

이 문서 자체의 한계

위의 여섯 항목이 패턴을 향한 비판이라면, 아래는 이 글이 그 비판을 다루는 방식에서 생긴 한계다.

• 취소선 영역의 상태가 미결이다. 8.1절에서 8.3절이 취소선으로 남아 있고 그 이유가 문서 안에 없다. 내용을 폐기한 것인지 재검토 중인 것인지 판단할 근거가 없다.
• 자체 검증이 없다. GitHub 별 수, Hacker News 댓글 수, Farzapedia 2,500건 같은 수치는 출처 자료의 보고치를 그대로 옮긴 것이다.
• 영어권 자료가 Karpathy 한 명에 몰려 있다. 한국어 자료는 세 편을 다루지만 영어권 비판은 Hacker News 스레드 요약에 그친다.
• 항목 수가 문서 안에서 어긋난다. 11.2절은 unclejobs-ai 역자 주석을 10가지로 소개하지만 9장은 아홉 항목만 발췌하고, 9.9절은 아홉 항목짜리 프롬프트를 표방하지만 코드 블록에는 일곱 항목이 들어 있다.

문서가 남긴 미해결 항목

• qmd의 한국어 토크나이징 지원 여부. 9.2절이 확인이 필요하다고 적고 결론을 내지 않는다.
• BM25의 한글 약점 보완 방법. 가드레일 대안으로 kurthong의 seCall 사례를 언급하지만 방법을 설명하지 않는다.
• 베이스라인 비교 실험. 7.5절이 지적한 우위 증거 부재는 반론 없이 남는다.

핵심 용어

관련 페이지

• LLM Wiki 입문 튜토리얼 (Data Science Dojo): 같은 Karpathy Gist를 다룬 영어권 입문 튜토리얼. 따라 하기용 절차와 프롬프트 전문을 제공하는 실행 가이드라서, 비판 정리와 한국어 운영 문제를 맡는 이 페이지와 역할이 나뉜다.
• RAG, LLM Wiki, or GBrain? 에이전트 메모리 결정 프레임워크 (Liu): RAG와 LLM Wiki와 GBrain 중 무엇을 쓸지 판단하는 영어 1차 자료. 3계층 정식화와 단일 수집이 페이지 1015개에 영향을 준다는 규모 감각이 같다. 다만 context window 성능 저하 지점은 Liu가 한도의 3040%라 적고 이 글은 100만 토큰 기준 20만에서 30만 토큰이라 적어 수치가 다르다.
• AKB, llmwiki, GBrain 비교 및 AKB 발전 방향: 같은 저자가 쓴 후속 비교 문서. 이 글이 정리한 LLM Wiki 패턴을 다른 지식 베이스 방식과 나란히 놓는다.
• garrytan/gbrain: 마크다운 파일을 지식 원본으로 두고 계속 쌓는 에이전트 메모리 도구. 같은 발상에 검색 엔진과 권한 모델을 붙인 사례다.
• Lum1104/Understand-Anything: Karpathy 패턴으로 만든 위키를 지식 그래프로 시각화하는 오픈소스. 이 글이 말하는 Graph View의 역할을 도구로 확장한 것이다.
• LLM Wiki: Karpathy LLM Knowledge Base 패턴의 한국어 레퍼런스 구현: 이 글 8.4절이 이름만 들고 지나간 구현체. Claude Code CLI를 호출해 수집과 질의와 점검을 자동화한 한국어 레퍼런스 구현이다.
• claude-obsidian: Self-Organizing AI Second Brain for Obsidian + Claude Code: 8.4절이 든 "Obsidian AI Second Brain"의 개별 페이지. Claude Code 스킬과 Obsidian vault 구조로 같은 패턴을 정착시켰다.
• LLM-Wiki Labs: 연구실 위키 운영을 인터랙티브 페이지로 공개한 저장소: 8.4절이 든 "Compounding Wiki, 31일의 누적"의 개별 페이지. 패턴을 실제로 운용한 기록이다.
• Beyond Semantic Similarity: Rethinking Retrieval for Agentic Search via Direct Corpus Interaction: 임베딩 없이 에이전트가 grep과 bash로 원본을 직접 검색하는 Direct Corpus Interaction. Farzapedia가 RAG를 접고 파일시스템 직접 탐색으로 옮겨간 것과 방식이 겹친다.
• PageIndex: Next-Generation Vectorless, Reasoning-based RAG: vector database 없이 목차를 컨텍스트 안에 두고 추론으로 찾아가는 retrieval. 임베딩 없는 index.md 발상과 통한다.
• PageIndex: The RAG Framework That Threw Out Vector Databases and Still Hit 98.7% Accuracy: 같은 계열의 실증 사례. vector database를 걷어낸 구성의 성능을 벤치마크로 보인다.
• LightRAG: Simple and Fast Retrieval-Augmented Generation (EMNLP 2025): 그래프 기반 RAG. 이 글 10.1절이 nashsu의 관련성 모델을 그래프 RAG에 가깝다고 본 판단과 이어진다.
• LeanRAG: Knowledge-Graph-Based Generation with Semantic Aggregation and Hierarchical Retrieval (AAAI-26): 계층적 지식 그래프 기반 retrieval. 사전 컴파일된 구조 인덱스라는 점이 같다.