아이디어: 조회 시가 아닌 수집 시에 컴파일
모델에 대규모 문서 세트를 제공하는 일반적인 방법은 검색(retrieval)입니다. 문서를 데이터베이스에 넣고, 문서를 부분으로 나누고, 각 부분에 대한 임베딩을 만듭니다. 각 질문에 대해 시스템이 관련 부분을 찾습니다.
이 방법은 작동합니다. 하지만 문제도 있습니다. 시스템이 결과를 저장하지 않습니다. 매번 원본 부분에서 답변을 다시 만듭니다. 열 번째 답변이 첫 번째 답변보다 낫지 않습니다. 동일한 작업 비용을 열 번 지불하게 됩니다.
에이전트 위키(agent wiki)는 이 비용을 이동시킵니다. 모델이 소스를 읽을 때 한 번만 작업을 수행합니다. 결과를 페이지에 기록합니다. 페이지는 그대로 유지됩니다.
새 소스가 들어오면 모델이 다음 단계를 수행합니다. 소스를 읽습니다. 관련 페이지를 변경합니다. 요약을 수정합니다. 페이지와 일치하지 않는 정보를 표시합니다.
두 방법 모두 올바릅니다. 두 가지 측면에서 차이가 있습니다. 첫 번째 차이는 비용을 지불하는 시점입니다. 두 번째 차이는 질문 이후에 무엇이 남는지입니다.
각 시스템은 동일한 세 가지 레이어로 구성됩니다.
레이어 1은 소스 문서입니다. 이것은 여러분의 기사, 논문, 리포지토리입니다. 모델이 이를 읽습니다. 모델은 이를 변경하지 않습니다.
레이어 2는 위키입니다. 위키는 마크다운(markdown) 형식입니다. 모델이 모든 위키를 작성합니다. 위키에는 요약, 각 주제별 페이지, 페이지 간 링크가 포함됩니다.
레이어 3은 스키마 파일입니다. 이 파일은 모델에게 위키의 구조를 알려줍니다. 또한 수행할 작업을 알려줍니다. 일반적인 파일은 CLAUDE.md 또는 AGENTS.md입니다. 이 파일은 모델을 위키의 올바른 관리자로 만듭니다.
시스템은 세 가지 작업을 수행합니다.
수집(Ingest): 모델이 새 소스를 읽습니다. 그런 다음 모델이 각 관련 페이지에 데이터를 기록합니다.
질의(Query): 위키에 질문합니다. 좋은 답변을 새 페이지로 위키에 다시 기록할 수 있습니다.
린트(Lint): 모델이 위키를 검사합니다. 일치하지 않는 정보를 찾습니다. 너무 오래된 정보를 찾습니다. 링크가 없는 페이지를 찾습니다.
작동하는 이유
인간이 관리하는 위키는 시간이 지나면서 부정확해집니다. 원인은 명확합니다. 어려운 부분은 소스를 읽는 것이 아닙니다. 어려운 부분은 아이디어를 갖는 것이 아닙니다. 어려운 부분은 유지보수입니다.
유지보수에는 다음과 같은 작업이 있습니다. 페이지 간 링크를 수정해야 합니다. 요약을 정확하게 유지해야 합니다. 각 새 문서를 기존 페이지와 비교해야 합니다.
이 작업은 멈추지 않습니다. 이 작업은 보상이 없습니다. 바쁜 팀은 이 작업을 가장 먼저 중단합니다. 그러면 위키가 부정확해집니다. 그러면 사람들이 사용하지 않습니다.
모델은 이 작업을 문제없이 수행합니다. 모델은 지루해하지 않습니다. 모델은 링크를 잊어버리지 않습니다. 모델은 한 번에 15개의 파일을 변경할 수 있습니다.
이 아이디어는 오래되었습니다. Vannevar Bush가 1945년에 Memex를 설명했습니다. Memex는 문서 간에 링크가 있는 개인 문서 저장소입니다. Bush는 유지보수에 대한 답이 없었습니다. 모델이 그 답입니다.
이름의 유래
Karpathy의 Gist를 직접 읽어보세요. 요약본보다 더 정확합니다.
그는 일반적인 방법에 대해 이렇게 씁니다: "LLM이 모든 질문마다 처음부터 지식을 재발견하고 있습니다. 축적이 없습니다."
그의 방법은 정보를 검색하지 않고 컴파일하는 것입니다. 그러면 "지식이 한 번 컴파일되고 계속 최신 상태로 유지되며, 모든 질의마다 다시 도출되지 않습니다." 결과는 "지속적이고 축적되는 산출물"입니다.
여러분이 위키를 작성하지 않습니다. 그는 이렇게 씁니다: "여러분은 절대(또는 거의) 위키를 직접 작성하지 않습니다. LLM이 모든 것을 작성하고 유지 관리합니다." 그는 에이전트와 Obsidian을 함께 사용합니다. 그는 이렇게 씁니다: "Obsidian은 IDE입니다. LLM은 프로그래머입니다. 위키는 코드베이스입니다."
Gist는 크기 제한을 제시합니다. 많은 요약이 이 제한을 포함하지 않습니다. 임베딩 없는 방법은 "중간 규모(~100개 소스, ~수백 페이지)에서 놀랍도록 잘 작동하며, 임베딩 기반 RAG 인프라가 필요하지 않습니다."
더 많은 소스의 경우, Gist는 검색을 추가하라고 알려줍니다. qmd를 예시로 듭니다. Gist는 qmd를 "BM25/벡터 하이브리드 검색과 LLM 재순위화를 갖춘 마크다운 파일용 로컬 검색 엔진"이라고 설명합니다.
따라서 규칙은 크기에 관한 것입니다. 규칙은 대체에 관한 것이 아닙니다. 소스 세트가 작을 때는 검색 인프라를 사용하지 마세요. 소스 세트가 커지면 검색을 추가하세요.
실제로 구축된 것들
여기서 패턴이 아이디어에서 엔지니어링으로 바뀌며, 구현 간의 차이점이 유용한 부분입니다.
Cognition: DeepWiki, 공용 유틸리티로서의 위키
Cognition은 이 방법을 GitHub의 공개 리포지토리에 적용했습니다. 공개 리포지토리의 URL에서 github.com을 deepwiki.com으로 바꾸세요. 그러면 해당 코드베이스에 대한 위키를 얻을 수 있습니다. 위키에는 아키텍처 요약, 파일 인덱스, 의존성 그래프, 검색이 있습니다. 위키에는 소스(Cognition)에 대한 링크가 있습니다.
가장 큰 공개 리포지토리 50,000개 이상에 위키가 있습니다. 목록에는 MCP와 LangChain이 포함됩니다.
두 번째 포인트가 더 중요합니다. 위키가 제품이 아닙니다. 위키는 에이전트를 위한 검색 인프라입니다. Devin은 위키를 사용하여 코드베이스에서 관련 코드를 찾습니다. 따라서 DeepWiki는 Devin의 코드 검색 아래에 있는 컴파일된 레이어입니다(Devin Docs).
Factory: AutoWiki, 빌드 산출물로서의 문서
Factory는 이 방법을 지속적 통합(CI)에 적용했습니다. Factory는 문서가 빌드 산출물이어야 하며, 별도의 프로젝트가 아니라고 씁니다. 문서는 소스에서 나옵니다. 코드베이스의 구조를 가집니다. 리포지토리가 변경될 때 변경됩니다(Factory).
위키를 만드는 방법은 두 단계로 이루어집니다. 1단계는 구조적 스캔입니다. README 파일, 패키지 매니페스트, CI 구성, 진입점을 읽습니다. 2단계는 의미적 스캔입니다. 라우트, API 엔드포인트, 서비스 클래스, 데이터베이스 스키마, 기능 플래그를 읽습니다.
Factory는 작업을 전문화된 에이전트 간에 분할합니다. 각 에이전트는 리포지토리의 한 부분을 담당합니다. 각 에이전트는 하나의 좋은 페이지를 작성하기에 충분한 컨텍스트를 얻습니다. 이 방법은 알려진 문제를 방지합니다: 하나의 에이전트만으로는 대규모 리포지토리에 대한 문서를 제대로 작성할 수 없습니다.
Factory는 규율이 아닌 인프라를 통해 위키를 정확하게 유지합니다. /wiki 명령이 위키를 다시 만듭니다. /install-wiki 명령이 CI 워크플로를 작성합니다. 이 워크플로는 기본 브랜치에 푸시할 때마다 위키를 다시 만듭니다. GitHub의 경우, 위키는 리포지토리의 위키 탭에 들어갑니다(Factory Docs).
LangChain: OpenWiki, 코드에서 모든 것으로의 도약
LangChain은 OpenWiki를 오픈 소스 소프트웨어로 출시했습니다. OpenWiki는 CLI 도구입니다. 코드베이스에 대한 에이전트 문서를 작성하고 유지 관리합니다. 그런 다음 LangChain은 OpenWiki Brains를 출시했는데, 두 가지 모드가 있습니다. Code Brain은 리포지토리용 첫 번째 모드입니다. Personal Brain은 여러분의 소스용 두 번째 모드입니다(LangChain).
Personal Brain이 중요한 변화입니다. Gmail, Notion, git 리포지토리, X, Hacker News, 웹 검색에서 데이터를 읽습니다. 이 모든 데이터를 하나의 로컬 마크다운 위키에 기록합니다. 에이전트가 이 위키를 읽습니다. 이 방법이 리포지토리 문서에서 여러분의 작업 문서로 바뀌었습니다.
각 팀은 출력에 대해 동일한 결정을 내렸습니다. 출력은 사람이 읽기 위한 텍스트가 아닙니다. 출력은 LLM 컨텍스트를 위한 구조화된 마크다운입니다. 제목, 페이지 간 링크, 요약이 있습니다. 이 구조를 통해 에이전트가 관련 정보를 빠르게 찾을 수 있습니다. 위키의 독자는 모델입니다.
GBrain: 개인용 오픈 소스 버전
GBrain은 코드베이스가 아닌 개인 지식 저장소에 이 방법을 적용합니다. GBrain은 git 리포지토리에서 마크다운을 사용합니다. 스키마 파일이 있습니다. 주제 간 링크 그래프를 자동으로 만듭니다.
GBrain은 이 방법에 매우 적은 인프라만 필요하다는 것을 보여줍니다. 벡터 데이터베이스가 없습니다. 서비스가 없습니다. 파일만 있습니다. 모델이 파일을 유지 관리합니다. 사람이 파일을 읽을 수 있습니다.
기술 매트릭스
네 시스템은 동일한 구조를 가집니다. git에서 마크다운을 사용합니다. 스키마 파일을 사용합니다. 수집 시 컴파일합니다. 소스가 변경될 때 위키를 다시 만듭니다. 에이전트가 읽을 수 있도록 페이지를 작성합니다. 네 팀이 네 가지 다른 문제를 해결했지만 동일한 구조를 만들었습니다. 이러한 일치는 이 구조가 올바르다는 강력한 증거입니다.
시스템은 유지보수 방식에서 다릅니다. Factory는 CI에서 유지보수를 수행합니다. 다른 세 시스템은 사람이 명령을 실행할 때 유지보수를 수행합니다. 따라서 위키는 마지막 명령만큼만 정확합니다.
한계
한계 1은 크기입니다. Karpathy가 이 한계를 제시합니다. 임베딩 없는 방법은 약 100개 소스에 대해 정확합니다. 더 많은 페이지의 경우 검색 엔진을 추가해야 합니다. Gist는 BM25 검색과 벡터 검색을 함께 사용하라고 알려줍니다.
한계 2는 정확성입니다. 모델이 수집 시 정보를 컴파일합니다. 초기 요약이 소스의 세부 사항을 누락할 수 있습니다. 이후의 모든 답변에 이 오류가 포함됩니다. 원본 부분에서 검색하면 이 문제가 없습니다. 반복 작업 비용과 데이터 손실 위험을 교환하는 것입니다.
한계 3은 오래된 정보입니다. 페이지는 마지막 업데이트만큼만 정확합니다. 이것이 Factory 방법이 중요한 이유입니다. 부정확한 위키는 위키가 없는 것보다 더 나쁩니다. 부정확한 정보가 정확한 정보의 형식을 가지고 있습니다.
한계 4는 비용입니다. 페이지를 만드는 데 토큰을 지불합니다. 아무도 읽지 않는 페이지를 만들 수 있습니다. 또한 변경되지 않은 페이지를 린트하는 데 토큰을 지불합니다.
위키는 메모리가 아닙니다
반드시 알아야 할 한 가지 차이점이 있습니다. 이 분야의 용어는 아직 정확하지 않습니다.
많은 사람들이 이러한 시스템을 메모리라고 부릅니다. LangChain은 OpenWiki를 AI 에이전트를 위한 위키 메모리 레이어라고 부릅니다. 다른 사람들은 위키가 에이전트에 메모리를 제공한다고 말합니다. 여기서 메모리라는 단어는 두 가지 다른 의미를 가집니다.
첫 번째 의미는 문서 세트에 대한 지식입니다. 위키가 이 역할을 합니다. 문서, 리포지토리 또는 Gmail의 데이터를 컴파일합니다. 문서가 무엇을 포함하는지 알려줍니다.
두 번째 의미는 사용자에 대한 메모리입니다. 이것은 다른 데이터입니다. 개인의 선호도를 포함합니다. 개인의 결정을 포함합니다. 팀이 거부한 방법을 포함합니다. 에이전트가 다른 애플리케이션에서 방법을 시도한 결과를 포함합니다.
사용자에 대한 메모리는 다른 구조를 가집니다. 문서 세트가 아닌 개인과 관련됩니다. 수집이 아닌 상호작용에서 비롯됩니다. 또한 각 사용자에 대해 다음 작업을 수행해야 합니다: 일치하지 않는 정보 수정, 너무 오래된 정보 제거, 각 항목의 출처 유지, 요청 시 데이터 삭제.
위키는 첫 번째 작업을 올바르게 수행합니다. 위키는 두 번째 작업을 수행하지 않습니다. Gmail 위키는 에이전트에게 Gmail에 무엇이 있는지 알려줍니다. 화요일 대화에서 결정을 변경했다는 것을 에이전트에게 알려주지 않습니다. 이미 실패한 방법을 알려주지 않습니다.
메모리 레이어는 두 번째 작업을 수행합니다. Mem0이 한 예입니다. 각 메모리를 user_id와 함께 저장합니다. 따라서 메모리는 세션, 애플리케이션, 에이전트 간에 개인과 함께 이동합니다. 사실이 변경되면 해당 위치의 사실을 변경합니다. 매번 새 레코드를 추가하지 않습니다.
두 시스템은 대안이 아닙니다. 둘 다 사용하세요. 오류는 위키를 사용하지 않는 것이 아닙니다. 오류는 위키가 사용자에 대한 메모리를 제공한다고 생각하는 것입니다.
요약
에이전트 위키의 아이디어는 올바릅니다. 지식을 한 번 컴파일하세요. 그런 다음 정확하게 유지하세요. 모든 질문마다 다시 만들지 마세요. 유지보수가 인간의 위키를 막았고, 모델이 비용 없이 유지보수를 수행합니다. 네 팀이 몇 달 안에 동일한 구조를 만들었습니다. 이것은 강력한 증거입니다.
다음 세 가지를 수행하세요. 문서 세트가 안정적이고 자주 읽는 경우 문서를 페이지로 컴파일하세요. 문서 세트가 커지면 Gist가 알려주는 대로 검색을 추가하세요. 문서 세트에 대한 지식과 사용자에 대한 메모리의 차이를 유지하세요. 위키는 첫 번째를 제공합니다. 위키는 두 번째를 제공하지 않습니다.
In Context #17
이 블로그는 In Context 시리즈의 일부로, @mem0ai 블로그 시리즈로 AI 에이전트 메모리 및 컨텍스트 엔지니어링을 다룹니다.
Mem0은 LLM 및 AI 에이전트를 위해 설계된 지능형 오픈 소스 메모리 레이어로, 세션 전반에 걸쳐 장기적이고 개인화된 컨텍스트 인식 상호작용을 제공합니다.
- 무료 API 키 받기: app.mem0.ai
- 또는 오픈 소스 GitHub 리포지토리에서 Mem0을 자체 호스팅
참고 자료
- Andrej Karpathy, LLM Wiki (GitHub Gist, 2026년 4월)
- qmd: 마크다운용 로컬 하이브리드 BM25/벡터 검색
- Cognition, DeepWiki: 모든 리포지토리용 AI 문서
- Devin Docs, DeepWiki
- Factory, AutoWiki 소개
- Factory Documentation, AutoWiki 개요
- langchain-ai/openwiki (GitHub)
- LangChain, Wiki Memory
- garrytan/gbrain (GitHub)
- Vannevar Bush, As We May Think (The Atlantic, 1945)
- Mem0
