Claude를 충분히 오래 사용하다 보면, 별다른 노력 없이도 Karpathy의 LLM Wiki를 갖게 됩니다

Claude와 매일같이 작업하다 보면, 당신의 작업에 대한 기억이 쌓이게 됩니다. 그리고 그것은 그리 거창한 것이 아닌, 평범한 마크다운 (markdown) 파일들의 더미로 나타납니다. 하나의 인덱스, 수많은 작은 노트들, 그리고 몇 가지 규칙들 말이죠. 이것은 기본적으로 Karpathy의 "LLM Wiki"와 같으며, 흥미로운 점은 아무도 이것을 설계하지 않았다는 것입니다. Claude 자체의 기억력이 당신을 자연스럽게 그 상태로 이끕니다.

내가 만들 것이라 예상했지만, 만들지 않은 것

나는 몇 주 동안 동일한 프로젝트에서 Claude와 함께 작업하며, 유용한 점은 그것이 기억을 한다는 사실입니다. 일주일 후에 다시 돌아와도 Claude는 우리가 무엇을 결정했는지, 내가 일을 어떻게 처리하는 것을 좋아하는지, 그리고 무엇이 아직 미결 상태인지 이미 알고 있습니다. 나는 다시 설명할 필요가 없습니다.

나는 이것을 구현하는 과정이 복잡할 것이라고 가정했습니다. 어딘가에 기억을 담당하는 특별한 데이터베이스 (database)가 있을 것이라고 생각했죠. 보통 "AI에게 기억을 부여하라"는 말은 그런 식으로 들리곤 합니다.

하지만 그런 것은 전혀 없습니다. Claude가 유지하는 것은 자신이 직접 쓰고 읽는 노트들로 구성된 일반 텍스트 파일 폴더입니다. 그것이 기억의 전부입니다. 그리고 나는 이것을 설정한 적이 없습니다. 그저 매일 Claude를 사용하면서 한 번에 하나씩 노트가 쌓였을 뿐이며, 그 과정에서 두 가지 작은 습관이 이를 형성했습니다.

Andrej Karpathy는 그가 "LLM Wiki"라고 부르는 짧은 글에서 이와 동일한 패턴을 설명했습니다. 즉, 데이터베이스를 쿼리 (query)하는 대신, 서로 연결된 마크다운 (markdown) 노트를 스스로 유지하는 에이전트 (agent)입니다. 나를 놀라게 한 점은 여기에 도달하기 위해 내가 한 일이 거의 없다는 사실입니다. 나는 이 패턴을 찾아 나선 것이 아니라, 그 안에 우연히 안착했습니다. 그래서 이 글은 내가 의도치 않게 도달하게 된 버전, 즉 그것이 어떻게 생겼는지, 왜 그런 형태가 되는지, 그리고 어디에서 작동을 멈추는지에 대한 기록입니다.

실제로 어떻게 생겼는가

파일에는 두 가지 종류가 있습니다.

하나의 인덱스 (index). 이것은 MEMORY.md라고 불리며, 매 세션이 시작될 때 컨텍스트 (context)로 로드됩니다. 그리고 각 노트당 한 줄로만 구성되어 있습니다:

- [User Profile](user_profile.md) - 내가 누구인지, 역할, 계정 정보
- [Writing Preferences](feedback_writing.md) - 짧게 유지, 일반 하이픈 사용, 과장 금지
- [Project X status](project_x.md) - 프로젝트 X에 대한 주요 (PRIMARY) 항목; 먼저 읽을 것

그다음은 노트 자체입니다. 파일당 하나의 사실(fact)을 담으며, Claude가 무엇을 보고 있는지 알 수 있도록 각 파일에는 몇 줄의 프론트매터 (frontmatter)가 포함됩니다.

---
name: feedback_writing
description: "초안을 작성하는 방식 - 이 노트가 관련이 있는지 결정하는 데 사용됨"
...

이것이 시스템의 전부입니다. 노트는 위키 (wiki)와 동일한 방식으로 [[name]]을 사용하여 관련 노트와 연결됩니다. 제가 사용하는 방식에는 네 가지 유형이 있습니다. 즉, '내가 누구인지', '업무 방식에 대한 피드백', '진행 중인 프로젝트 상태', 그리고 '외부 리소스에 대한 포인터'입니다. 하지만 유형 태그 (type tag)는 편의를 위한 것일 뿐 필수적인 것은 아닙니다.

정보를 찾는 과정도 매우 단순합니다. 세션이 시작될 때 Claude는 인덱스 (index)를 읽습니다. 어떤 내용이 관련이 있을 것 같으면, Claude는 그 한 줄짜리 description을 사용하여 전체 노트를 열지 여부를 결정한 다음 내용을 읽습니다. 검색 엔진도 필요 없고 설정할 것도 없습니다. 위에서 아래로 읽을 수 있는 짧은 인덱스와 파일 전체에 걸친 일반 텍스트 검색 (plain text search)만으로도 충분합니다.

왜 데이터베이스가 아닌 이런 형태인가

두 가지 습관이 이 시스템을 만들었으며, 그것이 실제 핵심입니다. 구조는 그 습관에서 자연스럽게 도출된 것입니다.

첫 번째는 군더더기 없이 유지하는 것입니다. 모델이 한 번에 보유할 수 있는 텍스트 양에는 한계가 있으므로, 매 세션마다 로드되는 인덱스는 작게 유지되어야 합니다. 그렇지 않으면 실제 작업 공간을 침범하게 됩니다. 이 하나의 제한 사항이 설계의 대부분을 주도합니다. 파일당 하나의 사실을 담아 인덱스의 각 줄을 짧게 유지합니다. 노트는 내용이 오래되면 업데이트하거나 삭제하며, 영원히 추가만 하지 않습니다. 계속해서 커지는 노트는 더 이상 로드할 여력이 없기 때문입니다. 인덱스를 읽는 비용을 저렴하게 유지하는 것이 전체 시스템을 사용 가능하게 만드는 핵심입니다. 이는 모든 것을 데이터베이스에 쏟아붓는 (dump-everything-into-a-database) 방식이 건너뛰는 단계입니다.

두 번째는 규칙을 가지고 작성하는 것입니다. 즉흥적으로 내버려 두면, 에이전트(agent)는 이미 네 개의 기존 노트가 다루고 있는 내용에 대해 다섯 번째 노트를 작성하게 되고, 결국 엉망진창이 됩니다. 이를 방지하는 것은 소수의 규칙들입니다. 즉, 프론트매터 (frontmatter), 타입 (types), 그리고 가장 중요한 규칙인 '새 노트를 작성하기 전에 이미 해당 내용을 다루는 노트가 있는지 확인하고, 있다면 대신 업데이트하라'는 규칙입니다. Claude에는 이러한 규칙들이 이미 내장되어 있으며, 이것이 제가 별도로 규칙을 추가할 필요가 없었던 이유입니다. 이러한 규칙들은 Claude를 일반적인 챗봇 (chatbot)이 아닌 세심한 노트 기록자로 만들어 주며, 의도적으로 지루하게 설계되었습니다.

파일 접근 방식이 잘 작동하는 데에는 더 깊은 이유가 있습니다. 일반적인 방식은 질문이 나올 때마다 원본 문서들을 처음부터 다시 뒤져서 답을 찾기 때문에, 아무것도 축적되지 않습니다. 위키 (wiki)는 다릅니다. 사고 과정이 한 번 수행되고 기록됩니다. 제가 잘못된 가정을 바로잡을 때, Claude는 더미 위에 새로운 조각을 추가하는 것이 아니라, 노트를 수정하거나 삭제합니다. 이해(understanding)는 매번 검색을 다시 수행하는 것이 아니라 노트 안에 살아 있습니다. 지식은 처음부터 다시 시작하는 대신 계속해서 쌓여갑니다.

작동이 멈추는 지점

솔직하게 짚고 넘어가겠습니다. "마크다운 (markdown)이 데이터베이스 (database)를 이긴다"는 식의 과장은 글의 질을 떨어뜨리는 종류의 과장된 주장(overclaim)이기 때문입니다.

이것은 작고 개인적인 도구입니다. 한 명의 사람, 한 명의 에이전트, 디스크 위의 노트들입니다. 수백 개의 노트까지는 잘 작동합니다. Karpathy는 검색 기능이 정말로 필요해지기 전의 한계를 약 100개의 소스 정도로 보았는데, 이는 제가 경험한 것과 일치합니다. 그 단계를 넘어서면 마크다운을 대체하는 것이 아니라 마크다운 위에 실제 검색 기능을 추가하게 됩니다. 파일은 계속 작동하지만, 수동으로 무언가를 찾는 단계는 지나게 됩니다.

더 큰 변화는 노트의 개수가 아니라 사람입니다. 여러 에이전트(agents)와 여러 팀이 동일한 메모를 작성하는 서버에 이를 구축하게 되면, 파일 폴더만으로는 충분하지 않게 됩니다. 동시에 작성하는 사람이 많아지고, 파일명이 아닌 의미(meaning)를 통해 정보를 찾아야 하는 사람들이 생겨나기 때문입니다. 바로 이 지점에서 더 무거운 도구들이 제 역할을 하게 됩니다. 관리형 메모리 저장소(managed memory store), 벡터 데이터베이스(vector database), neo4j와 같은 그래프 저장소(graph store), 그리고 GraphRAG와 같은 그래프 기반 검색(graph-based search) 등이 그것입니다. 이러한 용어들은 현재의 문제가 아닌, 그 더 큰 문제에 대한 해답입니다. 이를 가장 먼저 고려하는 것이 실수입니다. 개인적인 규모(personal scale)에서는 불필요한 비용과 설정이 따르기 때문입니다.

또한 아무도 최신 상태로 유지하지 않으면 메모는 쓸모없게 되지만, 이는 데이터베이스를 포함한 모든 메모에 해당되는 사실입니다. 여기서 유일한 장점은 정리가 저렴하다는 것입니다. Claude가 죽은 노트를 가지치기(pruning)하고 링크를 수정하는 지루한 작업을 수행합니다. 당신은 그저 계속 질문하기만 하면 됩니다.

이 중 어느 것도 새롭거나 특별한 것이 아닙니다. 폴더 안에 있는 마크다운(markdown) 파일일 뿐입니다. 규모가 커지더라도 아이디어는 동일합니다. 구조화된 메모를 유지하고 정보를 찾아보는 것 — 단지 누가 사용하는지에 따라 규모만 달라질 뿐입니다.

직접 시도해보고 싶다면

설정할 것이 거의 없습니다. Claude에서는 이미 이 과정이 자동으로 일어나고 있습니다. Claude는 별도의 지시 없이도 노트를 보관하고, 인덱스(index)를 작성하며, 이들을 연결하고, 중복을 방지합니다. 저는 Claude에게 이러한 규칙을 전달한 적이 없습니다. Claude가 이미 구축해 놓은 것을 읽어보고 나중에야 이를 발견했을 뿐입니다.

따라서 조언은 간단합니다. 실제 프로젝트에서 몇 주 동안 Claude를 사용해 본 다음, Claude의 메모 폴더를 열어 확인해 보세요. 구조가 이미 잡혀 있을 것입니다.

이것이 제가 계속해서 되돌아오는 지점입니다. 저는 메모 시스템을 구축하지 않았고, 설정하지도 않았습니다. 저는 그저 작업을 했을 뿐이고, 확인했을 때 그것은 이미 그곳에 있었습니다.

Karpathy의 LLM Wiki gist: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f