Karpathy LLM Wiki 패턴 실제 적용기, AI 에이전트 3계층 메모리 구축했다

Karpathy가 "LLM Wiki"라는 걸 공개했다

며칠 전 Andrej Karpathy가 GitHub Gist에 "llm-wiki"라는 아이디어 파일을 올렸다. OpenAI 공동창업자이자 전 Tesla AI 디렉터가 내놓은 건데, 핵심은 꽤 단순하다.

"The tedious part of maintaining a knowledge base is not the reading or the thinking — it's the bookkeeping."

위키를 관리하는 건 읽기나 생각이 아니라 정리 작업이 귀찮은 거다. 사람은 위키를 만들다 결국 관리를 포기하는데, LLM은 그 정리 작업을 지치지 않고 해준다는 거다.

Karpathy가 제안한 구조는 세 개 층이다:

• Raw Sources — PDF, 아티클, 트랜스크립트 같은 원본 자료. LLM은 읽기만 하고 절대 수정 안 한다.
• The Wiki — LLM이 직접 쓰고 관리하는 마크다운 파일들. 요약, 크로스레퍼런스, 인덱스를 알아서 만든다.
• The Schema — 위키 구조와 규칙을 정의한 설정 파일. LLM이 어떻게 행동할지 지시하는 설계도다.

그리고 핵심 오퍼레이션이 세 가지다:

• Ingest: 새 소스를 읽고, 요약 쓰고, 관련 페이지 업데이트. 소스 하나가 10~15개 위키 페이지를 건드릴 수 있다.
• Query: 위키에서 검색하고 답변. 가치 있는 탐색 결과는 다시 위키에 저장 — 지식이 복리로 쌓인다.
• Lint: 주기적으로 모순, 누락, 고아 페이지를 점검. 위키의 건강 상태를 유지한다.

RAG(Retrieval-Augmented Generation)와 뭐가 다르냐면, RAG는 질문할 때마다 문서를 새로 검색하고 조합한다. 어제 같은 질문 했어도 오늘 또 처음부터. Karpathy의 Wiki 패턴은 한 번 읽은 걸 "컴파일"해서 영구적으로 정리해둔다. 크로스레퍼런스도 이미 만들어져 있다. 그래서 지식이 누적되는 거다.

이걸 왜 적용하게 됐나

사실 나는 Karpathy가 공개하기 전부터 비슷한 문제를 겪고 있었다. Claude Code라는 AI 코딩 에이전트를 매일 쓰는데, 세션이 끝나면 다 잊는다. 새 세션 열 때마다 같은 설명을 반복해야 했다.

MEMORY.md라는 단일 파일에 기억을 때려넣기 시작했는데 금방 한계가 왔다. 파일이 커지면서 매 세션 토큰 낭비가 심해졌고, 특정 기억을 찾으려면 전체를 읽어야 했고, 에러 해결법과 서버 정보와 프로젝트 현황이 다 뒤섞였다.

그러다 Karpathy의 Wiki 패턴을 보고 "이거다" 싶었다. 근데 내 상황에는 한 가지가 더 필요했다 — 세분화된 검색. 위키 파일이 수십 개가 되면 마크다운만으로는 부족하다. 그래서 SQLite DB 계층을 추가했다.

3계층 메모리 아키텍처

전체 구조를 한눈에 보면 이렇다:

┌─────────────────────────────────────────────┐
│           Layer 1: 액티브 메모리              │
│        (MEMORY.md — 슬림 허브/인덱스)         │
│   → 매 세션 자동 로드 (부팅 화면)              │
└──────────────────┬──────────────────────────┘
                   │
┌──────────────────▼──────────────────────────┐
│         Layer 2: Wiki 토픽 파일               │
│    (memory/*.md — Karpathy 패턴 적용)         │
│   → 토픽별 구조화된 지식 저장소                 │
└──────────────────┬──────────────────────────┘
                   │
┌──────────────────▼──────────────────────────┐
│           Layer 3: SQLite 기억 DB             │
│         (memory.db — 565건, 12 카테고리)       │
│   → FTS5 전문 검색 + 교차 검증                 │
└─────────────────────────────────────────────┘

Layer 1 (액티브 메모리)은 Karpathy가 말한 Schema 계층과 비슷한 역할이다. Claude Code가 매 세션마다 자동으로 읽는 "부팅 화면"인데, 이 파일은 목차만 담는다. 토픽 파일로의 링크 테이블과 인프라 요약 한두 줄. 에이전트가 "이 사람은 서버 3대 쓰는 개발자구나" 정도만 파악하고, 상세한 건 필요할 때 Layer 2를 읽으러 간다.

Layer 2 (Wiki 토픽 파일)가 Karpathy 패턴을 가장 직접적으로 적용한 부분이다. memory/ 디렉토리 아래 토픽별로 마크다운 파일을 분리했다. people.md, projects.md, errors.md, cron.md, server-infra.md 같은 식이다. Karpathy 원본과 다른 점은, index.md와 MEMORY.md를 분리한 것, 그리고 log.md 대신 날짜별 일일 로그 파일을 쓰는 것이다. 30일 지나면 자동 삭제하되, 중요한 건 이미 토픽 파일에 반영된 상태니까.

개인적으로 가장 효과가 큰 건 errors.md다. 에러를 만날 때마다 쌓는데, 이게 Karpathy가 말한 Lint 오퍼레이션의 실용 버전이다. "PM2 kill → cloudflare-tunnel 같이 죽음 → SSH 접속 불가", "크론 모델 정보는 반드시 jobs.json에서 직접 확인" 같은 걸 누적하니까 AI가 같은 실수를 반복하지 않는다.

Layer 3 (SQLite DB)는 Karpathy의 원본에 없는 확장이다. 기억이 565건, 12개 카테고리에 걸쳐 쌓이니까 마크다운 검색만으로는 한계가 왔다. FTS5 전문 검색 인덱스를 붙여서 "PM2 관련 기억 찾아줘" 같은 요청에 즉시 응답할 수 있게 했다. 카테고리별로 보면 event 105건, infra 98건, blog 57건, tesla 55건 순이다.

Ingest 파이프라인 — 위키가 스스로 자라는 구조

Karpathy가 강조한 Ingest 오퍼레이션을 두 가지 방식으로 자동화했다.

실시간 Ingest: 대화 중에 "기억해줘"라고 하면 즉시 Layer 3(DB)에 저장하고, 관련 토픽 파일(Layer 2)도 업데이트한다. Layer 1(MEMORY.md)은 허브 구조라 건드릴 일이 거의 없다.

야간 자동 Ingest: 매일 새벽 1시에 cron이 돌면서 당일 대화 로그에서 중요한 내용을 추출하고, 각 토픽 Wiki 파일에 반영한다. memory.db에도 자동 저장. Karpathy가 말한 "인간은 소스를 큐레이션하고, LLM이 나머지를 처리한다"의 구현이다.

2개월 운영 후 솔직한 후기

같은 실수 반복이 0건이 됐다. errors.md 덕분에 "PM2 kill 금지", "ix-data.db 복사 금지" 같은 실수를 단 한 번도 반복하지 않았다. 이전에는 최소 3번은 반복했다.

세션 시작이 10초면 끝난다. 예전에는 2~3분 설명을 반복했는데 지금은 MEMORY.md → Wiki 자동 참조로 바로 작업에 들어간다.

기억의 교차 검증이 가능하다. Wiki에 "deepseek 모델 썼다"고 적혀 있었는데, memory.db에서 확인하니 다른 모델이었다. 기억을 기억으로만 의존하지 않고 DB로 검증할 수 있다는 게 Layer 3의 가치다.

아직 부족한 것도 있다. 위키 파일 간 크로스레퍼런스가 약하고, DB와 Wiki 간 동기화가 100%는 아니다. Karpathy 패턴은 마크다운 한 레이어라 이런 문제가 없는데, DB를 추가하면서 생긴 트레이드오프다.

Karpathy 원본 vs 내 구현 비교

	Karpathy LLM Wiki	내 3계층 구현
구조	Raw Sources → Wiki → Schema	MEMORY.md 허브 → Wiki 토픽 → SQLite DB
인덱스	index.md 단일	MEMORY.md(슬림) + index.md(상세) 분리
로그	log.md (append-only)	날짜별 파일 (30일 보관 후 삭제)
검색	마크다운 텍스트 검색	FTS5 전문 검색 + 카테고리 필터
Lint	LLM 주기적 건강 점검	errors.md 누적 + cron 자동 동기화
복잡도	마크다운만, 단순	SQLite 추가로 약간 복잡
검색 정밀도	보통	높음 (FTS5 + SQL)

마무리하면

Karpathy가 딱 맞는 말을 했다. 위키 관리의 병목은 "읽기"나 "생각"이 아니라 정리 작업이다. LLM은 그 정리를 지치지 않고 해준다.

내가 여기에 덧붙인 건 SQLite DB 계층이다. 기억이 수백 건 넘어가면 마크다운 검색만으로는 한계가 있고, 구조화된 검색과 교차 검증이 필요해진다. 기술 자체는 단순하다 — 마크다운 파일 몇 개와 SQLite DB 하나. 중요한 건 계층 간 역할 분리와 자동 Ingest 파이프라인이다.

Karpathy의 원본 Gist는 GitHub에 공개되어 있다. 관심 있으면 거기서 시작해서 자기 상황에 맞게 확장해보면 된다.

이 글에서 소개한 시스템은 OpenClaw + Claude Code 환경에서 약 2개월간 실제 운영 중이며, 565건의 기억을 12개 카테고리에 걸쳐 축적하고 있다.

---

📌 함께 보면 좋은 글

• Google Antigravity 사용기, 에이전트 개발 흐름이 왜 달라졌나
• AI 코딩 도구 실제 사용 현황, JetBrains 설문에서 읽히는 것들
• Vercel Sandbox CLI 사용법, 개발 흐름이 왜 더 단순해졌나