Karpathy의 LLM Wiki 패턴과 OpenClaw 3계층 메모리 구축기

AI 에이전트를 오래 쓰다 보면 가장 먼저 부딪히는 한계가 있습니다. 분명 어제까지는 잘 알고 있던 프로젝트 맥락, 반복 실수, 운영 규칙을 새 세션이 열리면 다시 설명해야 한다는 점입니다. 단순한 불편을 넘어서, 작업 품질과 속도를 동시에 깎아먹는 문제이기도 합니다.

이번 글에서는 Andrej Karpathy가 2026년 4월 공개한 LLM Wiki 아이디어를 실제 운영 환경에 적용한 경험을 정리해보겠습니다. 단순히 원문을 요약하는 수준이 아니라, 왜 이 방식이 기존 RAG와 다르게 작동하는지, 실제 구현에서는 어떤 식으로 변형했는지, 그리고 왜 SQLite 기반 검색 계층까지 추가하게 되었는지를 함께 다룹니다.

결론부터 말씀드리면, Karpathy의 방식은 “문서를 그때그때 다시 찾는 구조”보다 “지식을 한 번 정리해 누적시키는 구조”에 가깝습니다. 그리고 이 차이가 AI 에이전트의 체감 기억력을 크게 바꿉니다.

Karpathy가 공개한 LLM Wiki 방식이 왜 주목받았을까

Karpathy가 공개한 gist의 핵심은 단순합니다. 대부분의 LLM 문서 활용 방식은 질문할 때마다 원문에서 관련 조각을 다시 찾아 조합하는 RAG 형태인데, 이 방식은 매번 처음부터 다시 추론해야 합니다. 반면 LLM Wiki는 원문과 사용자 사이에 지속적으로 관리되는 위키 계층을 둡니다.

새 문서가 들어오면 LLM은 그것을 단순 인덱싱하지 않고, 기존 위키 문서에 반영합니다. 관련 개념 페이지를 수정하고, 새 사실이 기존 주장과 충돌하면 그 점을 표시하고, 요약과 연결 구조를 업데이트합니다. 즉, 검색 대상이 “원시 문서 묶음”이 아니라 “이미 정리된 지식 베이스”가 되는 것입니다.

Karpathy는 이 구조를 세 레이어로 설명합니다.

• Raw sources: 원문 자료, 논문, 기사, 로그, 문서. 읽기만 하고 수정하지 않는 계층입니다.
• The wiki: LLM이 직접 유지하는 마크다운 지식 베이스입니다. 요약, 엔티티 문서, 주제 문서, 연결 구조가 여기에 들어갑니다.
• The schema: 위키 구조와 동작 규칙을 정의하는 운영 문서입니다. 어떤 파일을 어떻게 갱신할지, ingest와 query와 lint를 어떻게 수행할지 정하는 역할입니다.

여기서 중요한 포인트는 단순 저장이 아니라 유지보수 자동화입니다. Karpathy는 위키 운영의 가장 귀찮은 부분이 읽기나 사고가 아니라 정리, 교차참조, 갱신 같은 bookkeeping이라고 봤고, 바로 그 반복 노동을 LLM이 맡는 구조를 제안했습니다.

기존 RAG와 무엇이 다른가

겉으로 보면 둘 다 “문서를 기반으로 답하는 시스템”처럼 보이지만, 실제 동작 방식은 꽤 다릅니다.

구분	기존 RAG	LLM Wiki 방식
질문 시 동작	원문에서 관련 조각을 다시 검색	정리된 위키를 우선 참조
지식 누적	질문마다 재구성	위키에 누적, 갱신
교차참조	실시간 조합 의존	미리 연결된 상태 유지
모순 관리	질문 시점에만 드러남	위키 갱신 과정에서 표시 가능
운영 감각	검색 시스템	지식 베이스 관리 시스템

즉, RAG가 “그때그때 찾아서 답하는 구조”라면, LLM Wiki는 “한 번 읽고 정리한 지식을 계속 키워가는 구조”라고 이해하는 편이 더 정확합니다.

실제 구현에서는 왜 그대로 쓰지 않고 확장했는가

Karpathy의 원안은 매우 설득력 있었지만, 실제 운영 환경에서는 그대로 적용하기보다 조금 변형할 필요가 있었습니다. 이유는 분명했습니다. 개인 작업 기록, 서버 운영 메모, 자동화 규칙, 반복 실수 방지 지식이 계속 쌓이기 시작하면, 마크다운 파일만으로는 검색 정밀도가 금방 떨어지기 때문입니다.

그래서 실제 구현은 다음과 같은 3계층 메모리 구조로 정리했습니다.

• Layer 1. MEMORY.md: 세션 시작 시 빠르게 읽는 슬림 허브
• Layer 2. memory/*.md: 토픽별 위키 문서, 즉 Karpathy식 Wiki 계층
• Layer 3. SQLite memory.db: 구조화 저장과 정밀 검색을 담당하는 계층

이 구성은 Karpathy의 “Wiki + Schema” 사고방식을 유지하면서도, 실제 운영에서 필요했던 검색성과 검증 가능성을 강화한 형태라고 볼 수 있습니다.

Layer 1, MEMORY.md를 슬림 허브로 만든 이유

AI 에이전트가 매 세션마다 무거운 장기 메모리 파일 전체를 읽게 하면, 기억은 잘할지 몰라도 토큰 낭비가 커집니다. 그래서 MEMORY.md는 상세 내용을 다 담는 파일이 아니라, 현재 운영에 필요한 핵심 요약과 위키 링크만 담은 허브로 두는 편이 효율적이었습니다.

예를 들어 이 파일에는 다음과 같은 정보만 남깁니다.

• 중요 토픽 파일 링크
• 인프라 핵심 요약
• 반드시 잊지 말아야 할 운영 규칙

이렇게 하면 세션 시작 시 에이전트는 전체 구조를 빠르게 이해하고, 필요한 순간에만 하위 wiki 파일을 읽으러 가면 됩니다. 실무에서는 이 설계가 체감 속도에 꽤 큰 차이를 만들었습니다.

Layer 2, Karpathy 패턴의 핵심인 Wiki 토픽 파일

실질적인 기억 저장은 대부분 이 계층에서 이뤄집니다. 토픽별 파일을 나누고, 중요한 사건이나 결정, 반복되는 오류, 서버 운영 원칙 등을 구조화해서 적재하는 방식입니다.

예를 들어 다음과 같은 파일 구성이 가능합니다.

• projects.md: 진행 중인 서비스와 프로젝트 상태
• errors.md: 반복 실수, 장애 원인, 해결 패턴
• server-infra.md: 서버 구조, 접속 방식, 운영 주의사항
• cron.md: 자동화 스케줄과 실제 동작 상태
• blog.md: 블로그 자동화 관련 규칙
• 일일 로그 파일: 날짜별 raw log 기록

여기서 특히 효과가 컸던 것은 errors.md 같은 운영 교훈 파일이었습니다. 예를 들어 “PM2 kill 금지”, “특정 DB 파일 복사 금지”, “크론 모델 정보는 반드시 실측 확인 후 답변” 같은 항목이 쌓이면, 에이전트가 관련 작업 전에 미리 경계할 수 있게 됩니다.

이 부분은 Karpathy가 말한 lint 개념과도 연결됩니다. 위키를 단순 저장소로 두지 않고, 실수 패턴과 모순을 계속 정리하는 살아 있는 지식 계층으로 운영하는 것입니다.

Layer 3, SQLite를 추가한 이유

이 부분은 Karpathy 원안과 가장 크게 다른 확장입니다. 원문 gist는 위키 자체를 중심에 놓고 설명하고 있고, 소규모에서는 그것만으로도 충분히 잘 작동합니다. 하지만 운영 기록이 수백 건 이상 쌓이면, 마크다운 grep만으로는 원하는 내용을 정확히 찾기 어려워집니다.

예를 들어 다음과 같은 질문은 구조화 검색이 있을 때 훨씬 강해집니다.

• PM2 관련 기억만 최근 순으로 보고 싶을 때
• 중요도 8 이상인 의사결정만 모아 보고 싶을 때
• 특정 프로젝트와 서버 운영 이력이 교차되는 기록을 찾고 싶을 때

이 때문에 memory.db에는 제목, 본문, 카테고리, 태그, 중요도, 생성일 같은 메타데이터를 같이 저장하고, FTS5 같은 전문 검색 기능을 붙였습니다. 이렇게 해두면 wiki 파일은 사람과 에이전트가 읽기 좋은 지식 구조를 담당하고, SQLite는 검색과 검증, 통계를 담당하는 식으로 역할이 분리됩니다.

정리하면, wiki는 이해를 위한 계층이고, DB는 검색과 검증을 위한 계층입니다.

이 구조가 실제로 체감 성능을 어떻게 바꿨는가

이 구조의 장점은 생각보다 단순한 데서 나옵니다. 새 세션이 열렸을 때 모든 것을 다시 설명하지 않아도 되고, 반복 실수를 기록해두면 다음 작업에서 미리 회피할 수 있고, 애매한 기억은 DB나 원문 로그로 교차 검증할 수 있습니다.

실제 운영 기준으로 체감된 효과는 다음과 같았습니다.

• 세션 재설명 비용 감소: 매번 프로젝트 배경과 운영 규칙을 처음부터 설명하지 않아도 됩니다.
• 반복 실수 감소: 과거 오류와 해결법이 누적되면서 예방 효과가 생깁니다.
• 기억 검증 가능: “예전에 이렇게 했던 것 같다” 수준의 회상을 실제 기록으로 확인할 수 있습니다.
• 지식 누적 구조 형성: 답변이 채팅창에서 사라지지 않고, 다시 위키에 편입될 수 있습니다.

이 지점이 중요합니다. 좋은 답변을 한 번 하고 끝내는 것이 아니라, 그 답변 자체가 다시 지식 베이스의 일부가 되면서 시스템이 점점 똑똑해지는 구조가 만들어집니다.

Karpathy 방식에서 특히 참고할 만한 운영 개념 3가지

원문 gist를 실제 구현 관점에서 다시 보면, 특히 유용한 개념은 세 가지입니다.

1. Ingest

새로운 정보가 들어오면 단순 저장이 아니라 요약, 연결, 기존 문서 수정까지 한 번에 처리하는 흐름입니다. 이 과정이 자동화될수록 wiki는 빠르게 성장합니다.

2. Query

질문에 답할 때도 단순 검색으로 끝나지 않고, 유의미한 분석 결과는 다시 wiki에 저장할 수 있습니다. 즉, 질의 행위 자체도 지식 축적의 일부가 됩니다.

3. Lint

위키에 모순, 고아 페이지, 최신 정보 미반영 상태가 없는지 점검하는 과정입니다. 사람이 하기 귀찮은 유지보수를 LLM이 잘 맡을 수 있는 영역이기도 합니다.

결국 이 세 가지가 돌아가야 위키가 단순 메모장이 아니라 운영되는 지식 시스템이 됩니다.

직접 만들어보려면 어떤 순서가 좋은가

처음부터 거대한 구조를 만들 필요는 없습니다. 오히려 작게 시작하는 편이 훨씬 좋습니다.

1. MEMORY.md 하나로 시작: 자주 반복하는 핵심 규칙만 정리합니다.
2. 토픽 파일 3~5개 분리: projects, errors, infra 정도만 먼저 나눕니다.
3. 일일 로그 도입: 중요한 변화가 생길 때 날짜별 기록을 남깁니다.
4. 검색 한계가 올 때 SQLite 추가: 처음부터 DB를 붙이기보다 필요가 생긴 뒤 붙이는 편이 낫습니다.
5. cron 또는 자동 ingest 추가: 일정 시점부터는 수동 정리를 줄이고 자동 반영을 붙입니다.

즉, Karpathy 원안의 철학으로 시작하고, 운영 규모가 커질 때 필요한 계층만 추가하는 방식이 가장 현실적입니다.

이 방식이 잘 맞는 사람

특히 다음과 같은 경우라면 효과를 보기 쉽습니다.

• AI 코딩 에이전트를 매일 쓰는 개발자
• 프로젝트 맥락이 길고 자주 끊기는 업무 환경
• 반복 실수나 운영 규칙을 기억시키는 일이 중요한 팀
• 문서가 많은데, 단순 RAG만으로는 누적 감각이 부족한 경우
• 개인 위키나 Obsidian, Markdown 기반 워크플로우를 이미 쓰는 경우

반대로 자료량이 매우 적고, 장기 누적보다 단발성 검색이 더 중요하다면 기존 RAG만으로도 충분할 수 있습니다. 결국 핵심은 “지식을 계속 쌓아야 하는가”입니다.

마무리, LLM 시대의 위키는 다시 의미가 생긴다

한동안 개인 위키나 팀 위키는 늘 비슷한 문제를 겪었습니다. 만들 때는 좋은데, 유지가 너무 귀찮아서 결국 방치되는 경우가 많았습니다. Karpathy가 짚은 것도 바로 그 지점입니다. 사람은 읽고 생각하는 것보다, 정리와 업데이트를 꾸준히 하는 일을 더 지겨워합니다.

그래서 LLM Wiki 방식은 단순히 “AI가 문서를 읽어준다”가 아니라, AI가 지식 베이스의 유지보수자 역할을 맡을 수 있다는 점에서 의미가 있습니다. 그리고 실제 구현에서는 여기에 검색성과 검증성을 보완하는 계층을 더하면서, 꽤 현실적인 운영 구조를 만들 수 있습니다.

정리하면 이렇습니다.

• Karpathy의 LLM Wiki는 RAG의 대체라기보다, 지식 누적형 운영 패턴에 가깝습니다.
• 실제 운영에서는 MEMORY 허브, wiki 토픽 파일, SQLite 검색 계층으로 확장하는 방식이 실용적입니다.
• 핵심은 기술 난이도보다 역할 분리와 ingest 습관입니다.

AI 에이전트의 기억력을 진지하게 개선하고 싶다면, 단순 프롬프트 트릭보다 이런 구조 설계를 먼저 보는 편이 훨씬 효과적입니다.

참고로 Karpathy의 원문 gist는 GitHub에 공개되어 있으며, 여기서 설명한 전체 사고방식의 출발점이 됩니다. 실제 구현 전에 한 번 직접 읽어보시면 왜 이 패턴이 많은 사람에게 바로 와닿는지 이해가 되실 것입니다.

참고 자료
- Andrej Karpathy, llm-wiki gist
- 실제 운영 기반 OpenClaw 메모리 wiki 및 3계층 메모리 구조 적용 사례

---

📌 함께 보면 좋은 글

• 생성형 AI 저작권 문제, 실무에서 실제로 걸리는 상황들
• AI 뭐가 달라졌길래 — 직접 확인해봄
• OpenAI 한 달 써보고 느낀 점: 업무 자동화 실전 가이드