hol4b

Karpathy LLM-Wiki 완전 분석: RAG 없이 마크다운으로 만드는 AI 지식 위키

작성자

kevin

카테고리:

,

벡터 DB와 임베딩 파이프라인을 한 번이라도 직접 굴려 본 사람이라면 안다. 지식관리 인프라는 한번 들이면 운영 비용이 의외로 크다. 4월 3일 Andrej Karpathy가 GitHub 깃스트로 공개한 짧은 설계 노트가 그 부담을 정면으로 비웃는다. 제목은 ‘LLM Knowledge Bases’. RAG도, 파인튜닝도, 벡터 DB도 없이 마크다운 파일만으로 LLM이 스스로 가꾸는 지식 위키를 만든다는 발상이다.

공개 12시간 만에 GitHub 스타 2,100개. Karpathy 본인이 단 한 단어도 직접 쓰지 않은 채 100개 문서, 40만 단어 규모의 연구 위키를 만들었다고 밝혔다. 발상이 단순하면서도 무게감이 있다.

RAG와 정확히 어디가 다른가

기존 RAG는 질문이 들어올 때마다 원본 문서를 검색해 즉석에서 답을 만든다. 빠르고 효과적이지만 한 가지 본질적 한계가 있다. 지식이 누적되지 않는다. 매번 처음부터 검색하고, 문서 사이 관계는 기억하지 못하며, 별도 인프라(벡터 DB, 임베딩 파이프라인)를 운영해야 한다.

LLM Wiki는 이 전제를 뒤집는다. 원본을 읽은 LLM이 한 번 지식을 컴파일해 마크다운 파일로 떨궈 둔다. 이후 질문은 이미 정리된 위키를 읽어 합성한다. 백과사전 편집자가 자료를 읽고 항목을 미리 작성해 두는 것과 같은 구조다.

구분 RAG LLM Wiki
질문 처리 원본 검색 → 즉석 생성 위키 조회 → 합성 답변
지식 누적 없음 (매번 처음) 있음 (추가할수록 깊어짐)
인프라 벡터 DB, 임베딩 파이프라인 필요 마크다운 파일과 git만
관계 파악 어려움 역링크·교차참조로 자동화

3계층 디렉토리 — 단순하지만 정교한 구조

전체 구조는 세 폴더로 끝난다.

raw/       ← 원본 자료 (불변. LLM은 읽기만)
wiki/      ← LLM이 생성·관리하는 마크다운
  index.md   (전체 페이지 목록 + 카테고리)
  log.md     (시간순 작업 기록)
  [개념].md  (개념 페이지, 비교 분석, 엔티티 페이지)
schema/    ← LLM에게 역할과 규칙을 정의하는 설정 레이어

raw/는 읽기 전용이다. LLM은 이 폴더에서 자료를 읽어 wiki/에 정리한다. schema/가 핵심 설계 포인트다. CLAUDE.md와 비슷한 역할로, 위키의 페이지 형식·인덱싱·명명 규칙·작업 절차를 LLM에게 가르치는 설정 레이어다. 이게 있기에 사람이 매번 지시하지 않아도 일관된 위키가 누적된다.

세 가지 동작 — Ingest, Query, Lint

LLM Wiki는 세 가지 명령으로 운영된다. 첫 번째는 Ingest. raw/에 새 자료(PDF, 아티클, 메모)를 추가하면 LLM이 요약 페이지를 만들고, 기존 관련 페이지를 업데이트하고, 이미 있는 개념 페이지에 새 자료의 역링크를 걸고, index.md와 log.md를 갱신한다. 한 번 명령으로 전체 위키가 알아서 자라난다.

두 번째는 Query. 질문을 던지면 LLM이 위키 페이지를 조회해 합성 답을 만든다. 흥미로운 점은 그 유용한 답변 자체가 새 페이지로 저장된다는 것이다. 질문이 곧 위키 확장의 입력이 된다.

세 번째는 Lint. 위키가 커지면 모순과 누락이 생긴다. Lint는 주기적으로 페이지 간 모순을 탐지하고, 역링크가 없는 고아 페이지를 찾고, 누락된 교차참조를 식별하고, 오래된 정보에 플래그를 단다. 이게 운영 비용을 결정적으로 낮추는 부분이다. 사람이 안 하면 시스템이 망가지는 일을 LLM이 자기 일로 처리한다.

실제로 시작하려면

Karpathy가 추천한 도구 조합은 군더더기 없이 단순하다. 위키 열람·편집은 Obsidian(역링크 그래프 시각화 포함), 웹 자료 수집은 Obsidian Web Clipper, 명령 실행은 Claude Code 또는 Cursor, 변경 이력 관리는 git. 워크플로 자체는 한 줄이다. raw/에 PDF나 아티클을 떨구고 Claude Code에 “Ingest new files”라고 시키면 끝이다.

한국 커뮤니티에서도 Claude Code 스킬로 구현한 사례(github.com/Astro-Han/karpathy-llm-wiki)가 이미 나왔다. Karpathy가 직접 칭찬한 Farzapedia는 개인 일기·메모 2,500개를 400개 문서 위키로 전환한 사례다.

한 가지 주의 — 모두에게 맞는 패턴은 아니다

위키 규모가 커질수록 모델의 컨텍스트 일관성 유지가 어려워진다는 점은 실제 한계다. HackerNews 토론에서 가장 흥미로운 비판 한 줄은 “위키를 직접 작성하는 과정에서 학습이 일어나는데, 그걸 AI에 맡기면 그 학습 기회를 잃는다”는 것이다. 일리가 있다. 개인 지식관리에는 그래서 양면이 있고, 오히려 효과가 더 큰 곳은 팀 단위 도메인 위키일 가능성이 높다. 사내 운영 매뉴얼, 트러블슈팅 노트, 고객 도메인 지식 — 한 사람이 다 못 읽는 자료가 쌓이는 영역이다.

그래서

RAG 기반 사내 지식 시스템을 구축하려다가 임베딩 파이프라인과 벡터 DB 운영 비용에 멈칫한 팀이 있다면, LLM Wiki는 그 첫 번째 대안이 된다. 인프라 부담이 사실상 0에 가까우면서도 위키가 누적되는 구조다. 도입 전에 작은 도메인(예: 사내 트러블슈팅 노트 50개) 하나로 한 번 굴려 보면 효과 가늠이 빠르다.

지금 할 일

가장 빠른 경험은 Karpathy 원본 깃스트(gist.github.com/karpathy/442a6bf555914893e9891c11519de94f)를 한 번 정독하고, 본인이 가장 자주 참고하는 자료(논문 PDF 10개 정도면 충분)를 모아 raw 폴더에 떨구는 것이다. Claude Code에 Ingest 명령을 한 번 던져 보면 위키 구조가 30분 안에 잡힌다. Obsidian으로 그 폴더를 열면 역링크 그래프가 시각적으로 드러나고, 이 패턴이 본인 작업에 맞는지 한눈에 판단된다.

관련 글

출처

더 많은 게시물