Karpathy의 LLM Wiki: RAG를 넘어 지식이 쌓이는 위키 만들기

Andrej Karpathy가 남긴 LLM Wiki는 단순한 아이디어 메모가 아닙니다. 이 글은 "LLM을 검색기처럼 쓰는 방식"에서 한 단계 더 나아가, LLM이 지식을 계속 정리하고 갱신하는 누적형 위키(compounding wiki) 를 어떻게 만들 수 있는지 보여줍니다.

DevOps 관점에서 이 아이디어가 흥미로운 이유는 분명합니다. 운영 문서, 장애 보고서, 러닝 노트, 회의록, 런북은 시간이 갈수록 쌓이지만, 그 가치는 자동으로 커지지 않습니다. 오히려 오래될수록 흩어지고, 서로 충돌하고, 찾기 어려워집니다. Karpathy가 제안한 방식은 이 문제를 LLM이 대신 정리하도록 설계합니다.

이 글에서는 다음 세 가지를 중심으로 정리합니다.

1. RAG 지식 집적 방식과 Karpathy식 위키 방식의 차이
2. Karpathy가 제안한 지식 수집, 정리, 유지 방법
3. 글에서 바로 가져올 수 있는 실전 팁과 운영 아이디어

---

1. RAG와 Karpathy 방식의 차이

많은 사람들이 LLM과 문서를 연결할 때 가장 먼저 떠올리는 방식은 RAG(Retrieval-Augmented Generation)입니다. 문서를 쪼개서 저장하고, 질문이 들어오면 관련 chunk를 찾아 답변 프롬프트에 넣는 구조입니다.

이 방식은 유용하지만, Karpathy가 지적하듯 본질적인 한계가 있습니다.

RAG의 특징

• 질문이 들어올 때마다 관련 문서를 다시 검색합니다.
• 검색된 조각들을 매번 새로 조합합니다.
• 이전 질문에서 얻은 통찰이 시스템 내부에 잘 남지 않습니다.
• 다중 문서의 미묘한 연결이나 상충 관계를 매번 다시 계산합니다.

즉, RAG는 "그때그때 읽고 답하는 시스템"에 가깝습니다. 검색 성능이 좋아질수록 답변 품질도 올라가지만, 지식 자체가 점점 정돈되지는 않습니다.

Karpathy식 LLM Wiki의 특징

Karpathy가 제안한 방식은 다릅니다. 원문 문서를 그대로 뒤지는 데서 끝나지 않고, LLM이 문서를 읽은 뒤 구조화된 마크다운 위키를 지속적으로 갱신합니다.

• 새 소스가 들어오면 LLM이 핵심을 추출합니다.
• 관련 개념 페이지, 인물 페이지, 비교 페이지를 업데이트합니다.
• 새로운 내용이 기존 주장과 충돌하면 그 차이를 기록합니다.
• 질의 결과도 필요한 경우 위키의 새 페이지로 편입합니다.

핵심 차이는 이것입니다.

구분	RAG	Karpathy식 LLM Wiki
지식 처리 방식	질문 시점에 검색	문서가 들어올 때마다 누적 정리
결과물	답변 중심	위키 중심
학습/축적	약함	강함
충돌 처리	보통 매번 재검색	위키 안에서 충돌과 변경 이력을 관리
장점	단순하고 빠름	시간이 지날수록 더 똑똑해짐

쉽게 말하면 RAG는 "검색 후 답변"이고, LLM Wiki는 "검색 결과를 재가공해 지식 저장소를 키우는 방식"입니다.

내가 보기에는 둘은 경쟁 관계라기보다 계층이 다릅니다. RAG는 읽기 도구이고, LLM Wiki는 쓰기와 유지보수까지 포함한 지식 운영 체계에 가깝습니다.

---

2. Karpathy가 제안한 지식 수집 방법

원문에서 제일 중요한 부분은 "어떻게 지식을 쌓고 유지할 것인가"입니다. Karpathy는 이를 세 개의 레이어로 나눕니다.

1) Raw sources

가장 아래에는 원본 자료가 있습니다.

• 기사
• 논문
• 이미지
• 데이터 파일
• 회의 기록

이 레이어는 수정하지 않습니다. 말 그대로 source of truth입니다. LLM은 읽을 수는 있지만, 원본을 덮어쓰지는 않습니다.

2) The wiki

중간 레이어는 LLM이 직접 관리하는 위키입니다.

• 요약 페이지
• 개념 페이지
• 엔티티 페이지
• 비교 페이지
• 인덱스 페이지
• 통합 서술 페이지

이 층이 핵심입니다. 원본을 단순히 저장하는 것이 아니라, 원본에서 추출한 지식을 서로 연결하고 재구성합니다.

3) The schema

맨 위에는 LLM이 어떻게 일해야 하는지를 적은 schema 문서가 있습니다.

예를 들면 CLAUDE.md나 AGENTS.md 같은 파일이 여기에 해당합니다.

이 문서는 다음을 정의합니다.

• 위키 구조
• 페이지 네이밍 규칙
• 소스 ingest 절차
• 질의 응답 방식
• 충돌 처리 원칙
• 로그 기록 방식

즉, schema는 "이 프로젝트에서 LLM이 일하는 운영 매뉴얼"입니다.

운영 루프: Ingest, Query, Lint

Karpathy는 지식 운영을 크게 세 가지 동작으로 설명합니다.

Ingest

새 자료를 넣고, LLM이 이를 읽어 위키에 통합하는 단계입니다.

흐름은 대략 이렇습니다.

1. 새 소스를 raw collection에 추가합니다.
2. LLM이 소스를 읽고 핵심 포인트를 추출합니다.
3. 요약 페이지를 만듭니다.
4. 관련 엔티티와 개념 페이지를 업데이트합니다.
5. index와 log를 갱신합니다.

이 과정에서 한 문서가 10개 이상 페이지를 건드릴 수도 있습니다. 중요한 점은 "요약만 만드는 것"이 아니라 "기존 위키의 맥락 속에 편입시키는 것"입니다.

Query

질문이 들어오면 LLM은 위키를 탐색하고, 필요한 페이지를 읽고, 인용 가능한 형태로 답합니다.

이 답변이 단발성 채팅으로 끝나지 않고, 가치가 있으면 다시 위키에 편입됩니다. 여기서 지식은 질문 하나를 처리하고 사라지는 것이 아니라, 다시 자산이 됩니다.

Lint

주기적으로 위키를 건강검진합니다.

• 서로 충돌하는 주장
• 최신 자료로 대체된 오래된 내용
• 링크가 끊긴 고립 페이지
• 중요한 개념인데 페이지가 없는 경우
• 더 조사해야 할 데이터 갭

이 단계는 DevOps에서 말하는 drift 점검과 비슷합니다. 문서는 시간이 지나면 자연히 drift가 생기기 때문에, 이를 주기적으로 찾아내는 루프가 필요합니다.

---

3. index와 log가 중요한 이유

원문에서 실무적으로 특히 유용한 부분은 index.md와 log.md입니다.

index.md

index는 내용 중심 카탈로그입니다.

• 모든 페이지의 링크를 모읍니다.
• 짧은 설명을 붙입니다.
• 필요하면 메타데이터를 함께 둡니다.
• 카테고리별로 정리합니다.

작은 규모에서는 이것만으로도 충분합니다. 특히 약 100개 소스, 수백 개 페이지 정도까지는 꽤 효과적이라고 Karpathy는 이야기합니다.

log.md

log는 시간순 기록입니다.

• 언제 ingest 했는지
• 어떤 질문을 했는지
• 어떤 lint를 돌렸는지
• 어떤 페이지를 수정했는지

여기서 아주 실용적인 팁이 하나 나옵니다. 각 로그 항목을 일정한 prefix로 시작하면, 일반 유닉스 도구로도 분석이 쉬워집니다.

예를 들면 이런 식입니다.

## [2026-04-04] ingest | Kubernetes Incident Notes
## [2026-04-04] query | What caused the timeout spike?
## [2026-04-04] lint | stale claims found

이렇게 해두면 grep이나 tail 같은 기본 도구로 최근 작업을 바로 훑을 수 있습니다. DevOps 스타일로 보면, 지식 저장소에도 운영 로그가 필요하다는 뜻입니다.

---

4. 글에서 바로 가져올 수 있는 실전 팁

Karpathy의 글은 철학만 있는 것이 아니라, 바로 적용 가능한 운영 팁이 많습니다.

1) 한 번에 많이 넣기보다 하나씩 정리하기

원문에서는 개인적으로 소스를 하나씩 ingest하고, 중간 결과를 직접 읽어보는 방식을 선호한다고 말합니다.

이건 아주 좋은 습관입니다.

• LLM이 놓친 핵심을 사람이 바로 잡을 수 있습니다.
• 위키가 어떤 스타일로 정리되는지 감을 잡기 쉽습니다.
• 초기 schema를 더 빨리 다듬을 수 있습니다.

대규모 배치 ingest도 가능하지만, 초기에 너무 크게 시작하면 품질을 보장하기 어렵습니다.

2) Obsidian 같은 편집기를 IDE처럼 쓰기

Karpathy는 LLM이 위키를 수정하고, 사람은 Obsidian으로 결과를 검토하는 흐름을 추천합니다.

이 관점이 좋습니다.

• LLM은 반복 작업을 맡습니다.
• 사람은 링크 구조와 의미를 봅니다.
• 위키는 코드베이스처럼 다룹니다.

즉, "문서를 읽는 앱"이 아니라 "지식을 개발하는 IDE"로 생각하는 겁니다.

3) Web clipper와 로컬 이미지 저장을 함께 쓰기

웹 문서를 마크다운으로 넣을 때는 웹 클리퍼가 유용합니다. 여기에 더해 이미지도 로컬로 내려받아 두면 좋습니다.

이유는 단순합니다.

• URL은 나중에 깨질 수 있습니다.
• LLM이 이미지를 직접 볼 수 있어야 맥락이 살아납니다.
• 아카이빙 품질이 올라갑니다.

특히 기술 블로그, 아키텍처 다이어그램, 대시보드 캡처 같은 자료는 이미지 보존이 중요합니다.

4) graph view로 허브와 고립 페이지를 찾기

Obsidian graph view는 위키의 구조를 한눈에 보여줍니다.

• 허브 페이지는 무엇인지
• 고립 페이지는 어디인지
• 연결이 부족한 개념은 무엇인지

DevOps 문서에서는 이런 구조가 특히 중요합니다. 장애 대응 문서나 런북은 서로 엮여 있어야 실제로 찾을 수 있기 때문입니다.

5) Marp와 Dataview 같은 도구를 붙일 수 있다

Karpathy는 위키를 단순 문서 집합으로 두지 말고, 주변 도구와 연결하라고 시사합니다.

• Marp: 위키 내용을 바로 발표 자료로 변환
• Dataview: frontmatter 기반 동적 테이블 생성
• 검색 엔진: 마크다운 파일이 많아질수록 필수

즉, 위키는 저장만 하는 곳이 아니라 재사용 가능한 운영 자산이 됩니다.

6) git repo로 관리하면 버전 히스토리가 공짜다

이건 DevOps 독자에게 가장 익숙한 포인트일 겁니다.

위키를 git repo로 두면 다음이 가능합니다.

• 변경 이력 추적
• 브랜치 분리
• 리뷰와 롤백
• 협업 흔적 보존

LLM 위키는 사실상 "문서형 코드베이스"이기 때문에 git과 매우 잘 맞습니다.

---

5. DevOps에 어떻게 써먹을까

이 아이디어는 개인 지식 정리뿐 아니라 DevOps 작업에도 잘 맞습니다.

장애 대응 위키

• incident ticket
• Slack 스레드
• on-call 메모
• postmortem
• 대시보드 캡처

이 자료를 raw source로 두고, LLM이 장애 원인, 재발 방지, 영향 범위를 정리한 위키를 계속 갱신하면 좋습니다.

런북 위키

운영 중 자주 쓰는 절차는 시간이 지나면 조금씩 달라집니다.

• 인증서 교체 절차
• 배포 롤백 절차
• DNS 변경 절차
• 클러스터 업그레이드 절차

LLM Wiki 방식이라면 새 경험이 들어올 때마다 관련 런북과 교차 링크를 갱신할 수 있습니다.

아키텍처 지식베이스

서비스가 커질수록 시스템은 사람 머릿속에만 존재하면 안 됩니다.

• 서비스 간 의존성
• 팀별 책임 범위
• 운영 계정과 권한
• 외부 벤더와 계약 정보

이런 정보는 RAG로만 읽는 것보다, 위키로 구조화해두는 편이 훨씬 오래 갑니다.

---

6. 핵심 정리

Karpathy의 LLM Wiki 아이디어는 "검색형 LLM"을 넘어서 "지식이 축적되는 운영 시스템"을 제안합니다.

정리하면 이렇습니다.

1. RAG는 질문할 때 검색하고 답한다.
2. LLM Wiki는 문서를 읽는 순간 지식 저장소를 갱신한다.
3. raw sources, wiki, schema의 3층 구조가 중요하다.
4. ingest, query, lint의 반복 루프가 지식을 키운다.
5. index와 log는 규모가 커질수록 필수다.
6. Obsidian, git, web clipper, graph view, Dataview 같은 도구가 실전 효율을 만든다.

개인적으로 이 글의 가장 중요한 메시지는 "LLM에게 답만 시키지 말고, 지식 운영을 맡겨라"라고 봅니다. 검색은 순간적으로 유용하지만, 축적되지 않으면 결국 같은 일을 반복하게 됩니다. 반대로 LLM이 위키를 계속 유지하면, 매번 새로 생각하는 대신 이전의 생각이 자산이 됩니다.

원문: LLM Wiki