
LLM Wiki는 안드레이 카파시(Andrej Karpathy)가 제안한 개인 지식 베이스 구축 패턴으로, Claude Code, Codex 등에 쉽게 활용할 수 있도록 설계된 문서입니다. LLM Wiki는 복잡한 구조가 아니라 매우 단순하게 구성되어 있기 때문에, 세부적인 사항들은 에이전트와 협업하며 채워나갈 수 있습니다. 그럼 해당 글을 바탕으로 카파시가 LLM Wiki를 제안하게 된 배경과 그 핵심 아이디어를 살펴보겠습니다.
1. 왜 LLM Wiki를 제안했는가?
LLM의 기존 문서 활용 방식은 대부분 RAG(Retrieval-Augmented Generation)에 기반합니다. 업로드된 문서는 벡터로 변환되어 저장되고, 사용자의 질문 시점에 관련 청크(chunk)를 검색해 답변을 생성하는 방식입니다. 하지만 이 방식에는 한계가 존재합니다. LLM이 질문에 답하기는 하지만, 매번 관련 청크를 처음부터 다시 조립하는 방식이기 때문에 "축적(accumulation)"의 개념이 부족하다는 것입니다. 새로운 지식이 들어왔을 때 기존 지식과 연결되어 발전되지 않고, 사용자의 질문과 피드백도 지식 발전에 기여하지 못합니다.
이러한 문제를 해결하기 위해 카파시가 제안한 것이 LLM Wiki입니다. 사용자의 질문이 들어올 때마다 단순히 정보를 검색해 답변을 생성하는 방식 대신, LLM이 지속적으로 위키(wiki)를 업데이트해 축적된 지식을 제공하는 것을 목표로 합니다. 새로운 지식이 입력되었을 때, LLM은 색인만 생성하는 것이 아니라 해당 자료를 읽고 핵심 정보를 추출하고 요약해 기존 위키에 통합합니다. 또한, 위키 페이지 간의 상호 참조 구조와 전반적인 주제 요약을 계속 갱신하며, 새로운 지식이 기존 지식과 모순되는 지점은 없는지 검토합니다. 이러한 과정을 통해 지식이 지속적으로 축적되고 발전하는 위키를 만드는 것이 가능합니다.
2. LLM Wiki의 구조
LLM Wiki는 3개의 계층으로 구성됩니다.
1) 원본 소스(Raw Sources) : 사용자가 수집한 기사, 논문, 이미지, 데이터 파일 등 원본 자료들이 모여있는 계층으로, LLM은 각 자료들을 절대 수정하지 않고 읽기만 합니다. 이 계층은 진실의 원천(Source of Truth) 역할을 합니다.
2) 위키(Wiki) : LLM이 생성하고 관리하는 md(markdown) 파일들의 디렉토리로, 지식들의 요약 및 종합된 정보, 엔티티/개념 페이지, 비교, 개요 등이 기록됩니다. 새로운 지식이 들어오면 업데이트와 상호 참조를 진행하고, 일관성을 유지하는 역할을 합니다. 이 계층은 전적으로 LLM이 소유하며, 사용자는 읽기만 합니다.
3) 스키마(Schema) : 위키가 어떻게 구조화되어 있고, 어떤 규칙을 따라야 하는지, 아래에서 설명할 작업은 어떤 워크플로우로 진행되는지를 LLM에게 알려주는 문서입니다. CLAUDE.md, Agents.md와 같은 문서들이 스키마에 해당하며, LLM Wiki에서의 핵심 설정 파일입니다. 스키마는 도메인에 맞게 지속적으로 발전해 나갈 수 있습니다.
3. LLM Wiki의 작업
LLM Wiki에서 진행되는 작업은 총 3가지입니다.
1) Ingest : 새로 들어온 자료를 원본 자료에 넣고, LLM을 통해 기존 위키에 통합하는 작업입니다. 핵심 내용에 대한 논의, 요약 페이지 작성, 인덱스 갱신, 엔티티/개념 페이지 업데이트, 로그 작성 등의 작업 흐름이 이루어집니다. 새로 수집된 자료 하나는 10~15개의 위키 페이지에 영향을 미칠 수 있습니다.
카파시는 여러 자료를 한 번에 수집하기보다는 한 번에 하나씩 자료를 수집하는 방식을 선호한다고 합니다. 이를 통해 작업에 자주 관여하고 자신의 스타일에 맞게 워크플로우를 발전시켜 나갑니다.
2) Query : 위키에 질문을 하고 답변하는 작업입니다. LLM은 사용자의 질문에 맞는 위키 페이지를 탐색하고 종합하여 답변을 제공합니다. 답변은 질문에 따라 텍스트, 표, 슬라이드, 차트 등 다양한 형태를 가질 수 있습니다. 이 작업에서 중요한 점은 좋은 답변은 위키에 새로운 페이지로 보관될 수 있다는 것입니다.
3) Lint : LLM이 주기적으로 위키의 건강 상태를 점검하는 작업입니다. 점검 과정에서 살펴보는 항목은 다음과 같습니다.
- 서로 다른 페이지가 서로 어긋나는 이야기를 하고 있지는 않은지
- 새로 들어온 자료 때문에 옛 페이지의 내용이 이제는 맞지 않게 되어 있지 않은지
- 어디에서도 언급되지 않아 혼자 떨어져 있는 페이지는 없는지
- 여기저기서 자주 등장하는데도 정작 자기만의 페이지가 없는 중요한 주제는 없는지
- 서로 관련 있는 페이지들이 아직 서로 이어져 있지 않은 곳은 없는지
- 인터넷 검색으로 보충할 수 있는 비어 있는 부분은 없는지
이 작업을 통해 위키가 점점 확장되더라도 엉망이 되지 않고 잘 정돈된 상태를 유지할 수 있습니다.
4. Indexing와 Logging
위키가 확장됨에 따라 자료들을 관리하기는 점점 어려워질 수 있습니다. LLM Wiki에서는 두 개의 파일을 통해 이러한 문제를 해결하고자 합니다.
1) index.md : 위키에 있는 모든 페이지를 모은 카탈로그입니다. 주제별로 위키 페이지를 정리하며, 각 페이지에는 링크, 한 줄 요약, 날짜 및 자료 수 등 메타 정보도 함께 기록됩니다. 사용자의 질문에 답을 할 때, LLM은 index.md를 참조하여 가장 적합한 위키 페이지를 찾고 상세 페이지로 이동해 답변을 생성하게 됩니다.
2) log.md : 로그에는 위키와 관련된 모든 활동들이 기록됩니다. LLM은 로그를 통해 타임라인을 파악하고 최근에 어떤 작업들이 수행되었는지 이해할 수 있습니다.
5. 왜 LLM Wiki가 주목받는가?
지식 베이스에 대한 관심과 논의는 과거부터 존재해 왔으나, 기존 방식은 유지보수 관점에서 부담이 많은 부분들이 있었습니다. 자료 간 상호 참조를 업데이트하고, 요약을 최신 상태로 유지하고, 새로운 자료가 기존 지식과 모순되지 않는지 검토하고, 여러 자료의 일관성을 유지하는 등 유지보수에 상당한 노력이 필요했습니다.
하지만 이제 LLM이 유지보수 관련 작업들을 대신 맡아주기에 이러한 부담이 획기적으로 줄어들게 되었습니다. 이제 사람들은 유지보수에 시간을 투자하기보다는 자료 수집, 지식 베이스의 방향성 수립, 지식 베이스를 통한 인사이트 도출에 집중할 수 있게 되었습니다. 이러한 변화로 인해 LLM Wiki가 주목을 받게 된 것입니다.
6. 마무리
LLM Wiki는 많은 관심을 받은 만큼 부정적인 우려도 존재합니다.
카파시도 언급했듯이 LLM Wiki는 개인 지식 베이스를 위한 패턴입니다. 100개 정도의 자료와 수백 개의 페이지에는 적합할 수 있으나, 그 이상으로 커지면 검색 인프라가 필요할 수 있고 RAG와 같이 복잡해질 수 있습니다. 그리고 LLM이 위키를 생성하고 관리하는 것이기에 환각 문제도 배제할 수는 없습니다.
또한, LLM이 개인의 지식 베이스를 관리하게 되면 사람이 사고하는 과정이 사라질 수 있다는 것입니다. 이와 관련해 카파시가 강조하는 것은 LLM에게 모든 사고 과정을 맡기자는 것이 아니라 자료를 관리하는 작업을 맡기자는 것입니다. 어떤 자료를 수집하고, 각 자료를 어떻게 연결하며, 어떤 목표로 나아갈 것인지는 여전히 사람이 결정해야 합니다. 따라서 LLM Wiki는 사람이 생각에만 집중할 수 있도록 돕는 도구라고 보는 것이 맞습니다.
LLM Wiki를 개인 지식 베이스에 적용하고 싶으시다면, 처음부터 방대한 자료에 활용하기보다는 하나의 도메인, 소수의 자료를 활용해 시도하는 것을 추천드립니다.
<참고>
1. https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
2. https://wikidocs.net/blog/@jaehong/10695/
3. https://wikidocs.net/blog/@jaehong/10682/
4. https://yozm.wishket.com/magazine/detail/3711/
'AI > AI Agent' 카테고리의 다른 글
| [LangGraph] 체크포인터 기반 메모리(상태) 관리 방법 (2) | 2026.03.25 |
|---|---|
| [LangGraph] 조건부 엣지 적용하는 방법 (1) | 2026.03.20 |
| [LangGraph] LangGraph 설명 및 기초 (2) | 2026.03.16 |
| [OpenAI Agents SDK] 핸드오프 기반 멀티 에이전트 협업 구현 (1) | 2026.03.13 |
댓글