누가 지식을 유지보수하는가. 이 질문이 요즘 자꾸 머릿속에 맴돈다.
Andrej Karpathy가 최근 LLM Wiki 패턴이라는 긴 gist를 올렸다. 핵심은 단순하다. RAG는 매번 질문이 들어올 때마다 문서를 뒤져서 답을 조합한다. 지식이 축적되지 않는다. 같은 질문이 세 번째 들어와도 처음부터 다시 검색하고 다시 조합한다. Karpathy의 제안은 이것이다. LLM에게 위키를 만들게 하고 유지보수하게 하라. 소스가 들어오면 읽고, 마크다운 페이지로 요약하고, 관련 페이지를 업데이트하고, 크로스레퍼런스를 연결한다. 지식이 쌓인다.
읽으면서 고개를 끄덕였다. 그리고 동시에 생각했다. 나는 이걸 이미 하고 있었다. 그리고 한계도 이미 겪었다.
OpenClaw에서 이미 하고 있는 일
내 환경에는 OpenClaw라는 에이전트 시스템이 있다. Rocky라는 메인 오케스트레이터가 study-clipper, blog-gen, memory-coach 같은 스킬들을 돌린다. 구조를 Karpathy의 3계층 모델에 대입하면 이렇게 된다. Raw sources는 내가 읽는 아티클과 유튜브 영상. Wiki는 memory 폴더에 쌓이는 마크다운 파일들. Schema는 AGENTS.md와 각 스킬의 SKILL.md다.
study-clipper는 내가 URL을 보내면 자동으로 실행된다. 아티클을 읽고, 요약하고, 이메일로 보내고, Notion에 저장한다. blog-gen은 그렇게 축적된 소스 중에서 블로그 글을 뽑아낸다. memory-coach는 내가 학습한 내용을 복습 일정에 맞춰 이메일로 보내준다. 이 모든 게 에이전트가 한다. 나는 URL만 던진다. 어제 밤 11시에도 URL 세 개를 연달아 보냈다. 하나는 YouTube 영상이었고, 하나는 Antigravity SDK 문서였다. Rocky가 자는 새에도 처리한다. 나는 다음 날 아침 이메일로 요약을 받아본다.
이건 Karpathy가 말하는 Ingest 워크플로우와 거의 같다. 소스를 투입하면 에이전트가 읽고 추출하고 저장한다. 차이점이 있다면, Karpathy의 위키는 페이지 간 크로스레퍼런스를 강조하는데 내 memory 파일들은 그 연결이 약하다. 파일들이 쌓이긴 하지만 서로를 가리키지 않는다. 이게 내가 projects 폴더에 별도 위키를 만든 이유다. memory는 일상 기록용이고, 위키는 주제별 깊이 축적용이다.
RAG의 한계를 몸으로 겪었다
Karpathy가 RAG의 한계를 지적한 부분에서 나는 단번에 동의했다. 같은 작업을 OpenClaw에게 했었는데 애가 기억을 하지 못해서 다시 처음부터 세팅했어야 했던 경험이 있기 때문이다.
에이전트는 세션이 끝나면 맥락이 사라진다. 다음 세션에서는 이전 대화를 모른다. 이건 RAG가 풀려고 했던 문제와 같다. 문서를 검색해서 맥락을 주면 되잖아? 그런데 실제로 해보니, 검색으로는 "내가 이걸 이미 해놨다"는 상태를 보존할 수 없다. 파일은 있는데, 에이전트가 그 파일의 의미를 이어받지 못한다.
그래서 MEMORY.md와 AGENTS.md를 만들었다. 에이전트가 매 세션마다 읽고 출발하는 기준점이다. 이 파일들이 없으면 Rocky는 매번 새로운 에이전트다. 내가 "아까 말한 그거"라고 해도 모른다. 파일에 적혀 있어야 안다. "If it is not written in a file, it does not exist" — 이건 내 AGENTS.md에 적어놓은 규칙이다.
Karpathy의 위키 패턴이 말하는 것도 결국 같다. 지식은 검색으로 재발견하는 게 아니라, 컴파일된 위키 페이지에서 출발해야 한다. 매번 처음부터가 아니라, 이미 정리된 곳에서 시작해야 한다.
LLM은 지루해하지 않는다
Karpathy gist에서 가장 와닿은 구절이 있다. "인간이 위키를 포기하는 이유는 유지보수 비용이 가치보다 빨리 자라기 때문이다. LLM은 지루해하지 않는다."
study-clipper를 매일 돌리는 건, 인간이 하면 매우 지루한 작업이다. URL을 받고, 아티클을 읽고, 핵심을 요약하고, 이메일을 쓰고, Notion에 정리한다. 같은 포맷, 비슷한 내용, 매일 반복. 사람이면 며칠 만에 그만둘 일이다. 그런데 Rocky는 지루해하지 않는다. 내가 새벽 1시에 URL 세 개를 연달아 보내도, 하나하나 같은 품질로 처리한다. 결과가 들어오면 이메일로 보내고 Notion에 저장한다. 항상 내가 원하는 결과를 갖다 준다.
이게 Karpathy가 말한 핵심이다. 지식 유지보수의 병목은 인간의 지루함이었다. 에이전트는 그 병목이 없다. 같은 작업을 10번, 100번 반복해도 품질이 떨어지지 않는다. 위키 패턴이 작동하려면 "누가 이걸 유지보수하느냐"가 해결되어야 하는데, 에이전트가 그 역할을 한다.
인간은 반복을 싫어한다. 세 번째 같은 작업을 하면 품질이 떨어지고, 다섯 번째에는 대충하고, 열 번째에는 그만둔다. 에이전트는 백 번째가 첫 번째와 같다. 이 특성이 지식 관리에 왜 결정적인가 하면, 위키의 가치는 페이지 수가 아니라 페이지 간 연결의 질에서 나오는데, 그 연결을 유지하는 건 순수 반복 작업이기 때문이다. 새 소스가 들어올 때마다 관련 페이지 10-15개를 업데이트하고, 크로스레퍼런스를 확인하고, 모순을 체크한다. 인간은 이걸 두 주일도 못 한다.
위키 패턴을 어디에 쓸 것인가
Karpathy의 패턴이 빛을 발하는 순간은 하나의 주제를 깊게 파고들 때다. 매일 뉴스를 스캔하고 블로그 글을 쓰는 일상 플로우에는 이미 OpenClaw가 충분하다. study-clipper가 있고, blog-gen이 있고, memory 파일이 있다. 여기에 위키 패턴을 얹을 필요는 없다.
위키가 필요한 순간은 따로 있다. GraphDB를 깊게 공부할 때. 에이전트 하네스 생태계를 추적할 때. 관련 논문과 아티클과 코드가 계속 쌓이는데, 그것들 사이의 관계가 축적되지 않는다고 느낄 때. RAG로는 "3개월 전에 읽은 그 논문이 지금 이 결정에 어떤 영향을 미치는지" 물을 수 없다. 위키에는 그 연결이 페이지 간 크로스레퍼런스로 살아있다.
나는 projects 폴더에 GraphDB Lab과 Agent Harness라는 두 위키를 만들었다. Karpathy의 패턴대로 raw 소스, wiki 페이지, schema(AGENTS.md) 구조로 세팅했다. Rocky가 소스를 읽으면서 위키 페이지를 작성하고, 페이지 간 연결을 유지한다. 내가 할 일은 주제를 정하고 소스를 던지는 것뿐이다.
이 위키가 진짜 힘을 발휘하는 순간은 지금 당장이 아니라 나중이다. 내가 지식을 쌓는 방식, 내가 어떤 경험을 하면서 배웠는지, 어떤 시도에서 실패하고 어떤 접근에서 성공했는지 — 이런 게 위키에 축적되면, 나중에 GraphDB로 실제 프로저트를 진행할 때 Rocky가 그 맥락을 알고 출발한다. 매번 "CK님은 이런 부분을 중요하게 생각하시네요"라고 새로 파악하는 게 아니라, 위키에 쌓인 패턴을 기반으로 제안한다. 내가 어떻게 공부하고 경험을 쌓아왔는지 아는 에이전트가 옆에서 일하는 거다. 이건 RAG로는 불가능하다. RAG는 문서를 검색할 뿐, 나라는 사람의 학습 궤적을 이해하지 못한다.
Karpathy가 Memex를 언급했다. Vannevar Bush가 1945년에 구상한 개인 지식 기계. Bush가 해결 못 했던 건 "누가 유지보수하느냐"였다. 80년이 지난 2026년, 에이전트가 그 답이다. 지식을 축적하고 연결하는 건 여전히 인간의 몫이다. 하지만 그것을 정리하고 유지보수하는 일은, 더 이상 인간이 지루해하며 할 일이 아니다.