LLM Wiki란 무엇인가: RAG와 다른 지속형 지식베이스 패턴

개요

 최근 Andrej Karpathy가 “LLM Wiki”라는 아이디어를 공유했다. 처음 봤을 때는 단순히 LLM에게 마크다운 문서를 많이 읽게 하는 방식처럼 보일 수 있다. 하지만 내용을 조금 더 자세히 보면 기존 RAG와는 관점이 다르다. RAG는 보통 질문이 들어왔을 때 관련 문서 조각을 검색하고, 그 조각을 LLM의 컨텍스트에 넣어 답변을 생성하는 방식이다. 반면 LLM Wiki는 LLM이 계속 읽고, 정리하고, 수정할 수 있는 지속적인 지식 저장소를 만든다는 관점에 가깝다. 즉, 일회성 검색 시스템이라기보다는 LLM이 장기적으로 관리하는 마크다운 기반 위키라고 볼 수 있다. 이 글에서는 Karpathy의 LLM Wiki 아이디어가 어떤 문제의식에서 나왔고, 기존 RAG와 무엇이 다른지, 그리고 개발자 관점에서 어떤 의미가 있는지 정리해본다.

 

 

llm-wiki

 

내용

기존 RAG의 한계

 LLM을 외부 지식과 연결할 때 가장 흔하게 떠올리는 방식은 RAG다.

 

RAG는 Retrieval-Augmented Generation의 약자로, 대략 다음 흐름으로 동작한다.

 

- 질문이 들어온다.

- 문서 저장소에서 관련 있는 내용을 검색한다.

- 검색된 문서 조각을 프롬프트에 넣는다.

- LLM이 그 내용을 바탕으로 답변한다.

 

이 방식은 매우 실용적이다. 회사 문서, 정책 문서, 코드 문서, 논문, 고객 지원 문서 등을 LLM과 연결할 때 자주 사용된다.

 

하지만 RAG에는 몇 가지 아쉬운 점이 있다.

 

첫 번째는 지식이 매번 검색 시점에만 사용된다는 점이다. LLM은 검색 결과를 보고 답변할 수 있지만, 그 지식을 장기적으로 정리하거나 구조화하지는 않는다. 같은 주제에 대해 비슷한 질문이 반복되어도 매번 다시 검색하고 다시 조합해야 한다.

 

두 번째는 문서가 조각 단위로만 들어간다는 점이다. 검색 시스템은 보통 문서를 chunk로 나누고, 질문과 유사한 chunk를 찾아 넣는다. 이 과정에서 전체 문서의 맥락이나 여러 문서 사이의 관계가 약해질 수 있다.

 

세 번째는 지식 저장소 자체가 LLM이 다루기 좋은 형태가 아닐 수 있다는 점이다.

원본 데이터는 PDF, 웹페이지, 로그, 코드, 메일, 슬랙 메시지처럼 다양한 형태로 존재한다. RAG는 이것을 검색 가능한 형태로 바꾸지만, LLM이 장기적으로 읽고 수정하고 발전시키는 지식 구조로 만들지는 않는다.

Karpathy의 LLM Wiki는 이 지점에서 출발한다.

 

LLM Wiki의 핵심 아이디어

 LLM Wiki의 핵심은 간단하다.

 

 LLM이 사용할 수 있는 마크다운 기반 지식베이스를 만들고, 그 지식베이스를 LLM이 계속 관리하게 하자는 것이다. 여기서 중요한 점은 “문서를 그냥 많이 저장한다”가 아니다. LLM Wiki는 지식을 다음과 같은 형태로 나누어 관리한다.

 

- raw sources

- wiki

- schema

 

raw sources는 원본 자료다.

예를 들어 논문, 블로그 글, 문서, 회의록, 로그, 코드, 링크 등이 여기에 해당한다. 즉, 아직 정제되지 않은 외부 지식이다.

 

wiki는 LLM이 읽기 좋게 정리한 마크다운 문서다.

원본 자료를 그대로 쌓아두는 것이 아니라, LLM이 이해하고 다시 사용할 수 있도록 주제별로 요약하고 연결한 문서라고 볼 수 있다.

 

schema는 위키를 어떻게 작성하고 관리할지에 대한 규칙이다.

예를 들어 문서의 형식, 링크 방식, 태그, 이름 규칙, 요약 방식, 인덱스 관리 방식 등이 여기에 포함될 수 있다.

 

이 구조를 보면 LLM Wiki는 단순한 검색 인덱스가 아니라, LLM이 다룰 수 있는 작은 지식 시스템에 가깝다.

 

RAG와 LLM Wiki의 차이

RAG와 LLM Wiki는 모두 LLM이 외부 지식을 활용하도록 돕는다는 점에서는 비슷하다. 하지만 방향은 다르다.

 

RAG는 질문이 들어왔을 때 외부 문서를 검색한다.

LLM Wiki는 미리 정리된 지식베이스를 계속 유지한다.

 

RAG는 검색 결과를 컨텍스트에 넣는 방식이다.

LLM Wiki는 LLM이 읽고 수정할 수 있는 지식 구조를 만든다.

 

RAG는 문서 조각을 잘 찾는 것이 중요하다.

LLM Wiki는 지식을 어떻게 정리하고 연결하고 갱신할지가 중요하다.

 

예를 들어 어떤 개발자가 “우리 프로젝트의 인증 구조가 어떻게 되어 있지?”라고 질문한다고 해보자.

RAG 방식이라면 관련 코드 파일, README, 이슈, 문서 조각을 검색해서 LLM에게 넣어줄 것이다.

 

LLM Wiki 방식이라면 프로젝트 위키 안에 “Authentication” 같은 문서가 있고, 거기에 인증 흐름, 주요 파일, 토큰 발급 방식, 예외 처리, 과거 변경 이력 등이 정리되어 있을 수 있다. LLM은 그 문서를 읽고 답변할 수 있고, 코드가 바뀌면 위키도 함께 갱신할 수 있다.

 

즉, RAG가 “검색해서 답하기”에 가깝다면 LLM Wiki는 “지식을 유지하면서 답하기”에 가깝다.

 

 

LLM Wiki의 동작 흐름

Karpathy의 아이디어를 개발자 관점에서 보면 대략 네 가지 동작으로 이해할 수 있다.

 

첫 번째는 ingest다.

새로운 원본 자료를 받아서 위키에 반영하는 과정이다.

예를 들어 새 논문을 읽거나, 블로그 글을 추가하거나, 코드베이스를 분석하거나, 회의록을 정리할 때 ingest가 일어난다.

이 단계에서 LLM은 원본 자료를 그대로 복사하는 것이 아니라, 기존 위키와 연결되는 형태로 정리한다.

 

두 번째는 query다.

사용자가 질문하면 위키를 기반으로 답변한다.

이때 중요한 점은 단순히 원본 문서를 검색하는 것이 아니라, 이미 정리된 지식 구조를 활용한다는 것이다. 위키에 잘 정리되어 있을수록 답변의 일관성도 좋아질 수 있다.

 

세 번째는 lint다.

위키에 잘못된 링크, 중복된 내용, 깨진 구조, 오래된 정보가 없는지 검사하는 과정이다.

사람이 관리하는 문서도 시간이 지나면 중복되고 낡는다. LLM이 관리하는 위키도 마찬가지다. 따라서 주기적으로 정리하고 검증하는 과정이 필요하다.

 

네 번째는 index와 log다.

index는 위키의 입구 역할을 한다. 어떤 문서가 있고, 어디서 시작해야 하는지 알려준다.

log는 변경 이력을 남기는 역할을 한다. 어떤 자료가 들어왔고, 어떤 문서가 수정되었고, 어떤 판단을 했는지 기록한다.

이 구조는 일반적인 소프트웨어 프로젝트와도 닮아 있다.

README가 있고, 소스 코드가 있고, 규칙 문서가 있고, 변경 이력이 있는 것처럼 LLM Wiki도 지식 저장소를 하나의 관리 가능한 프로젝트처럼 다룬다.

 

왜 마크다운인가?

LLM Wiki에서 마크다운을 사용하는 점도 중요하다.

 

마크다운은 사람이 읽기 쉽고, LLM도 다루기 쉽다. Git으로 버전 관리하기도 좋고, diff를 보기도 좋다. 링크를 만들거나 문서를 나누는 것도 간단하다.

 

또한 마크다운은 특정 벤더나 도구에 강하게 묶이지 않는다.

벡터 데이터베이스나 검색 엔진은 성능상 유용하지만, 내부에 저장된 지식이 사람이 직접 읽고 고치기에는 불편할 수 있다. 반면 마크다운 위키는 사람이 열어보고 직접 수정할 수 있다.

 

이 점은 생각보다 중요하다.

LLM이 만든 지식베이스라도 결국 사람이 검토하고 신뢰할 수 있어야 한다. 마크다운은 그 중간 지점에 있다.

LLM도 읽고 쓸 수 있고, 사람도 읽고 고칠 수 있다.

 

개발자에게 어떤 의미가 있을까?

LLM Wiki는 특히 개발자에게 흥미로운 아이디어다.

현실의 코드베이스는 문서가 금방 낡는다. README는 오래전에 작성된 상태로 남아 있고, 설계 문서는 실제 코드와 달라지고, 이슈와 PR에는 중요한 맥락이 흩어져 있다.

LLM Wiki를 코드베이스에 적용하면 다음과 같은 형태를 생각해볼 수 있다.

- 프로젝트 구조 요약

- 주요 도메인 개념 정리

- 인증, 결제, 배포 같은 핵심 흐름 설명

- 자주 발생하는 장애와 해결 방법 기록

- 중요한 설계 결정과 변경 이유 기록

- 주요 파일과 모듈의 역할 정리

- 새로운 팀원이 프로젝트를 이해할 때 필요한 진입점 제공

이런 내용이 계속 업데이트된다면 LLM은 단순히 코드를 검색하는 도구를 넘어 프로젝트의 맥락을 이해하는 보조자에 가까워질 수 있다.

특히 큰 코드베이스에서는 “어디를 봐야 하는지” 자체가 중요한 문제다.

LLM Wiki는 그 문제를 줄여줄 수 있다.

 

단점과 주의할 점

물론 LLM Wiki가 모든 문제를 해결하는 것은 아니다.

 

가장 큰 문제는 최신성이다.

위키가 실제 원본 자료나 코드와 달라지면 오히려 혼란을 만든다. 잘못 정리된 위키를 LLM이 계속 참조하면 틀린 답변이 더 그럴듯하게 나올 수 있다.

따라서 LLM Wiki를 사용하려면 주기적인 검증이 필요하다.

코드가 바뀌었을 때 관련 문서도 바뀌어야 하고, 오래된 문서는 표시되거나 제거되어야 한다. 링크가 깨졌는지도 확인해야 한다.

 

또 다른 문제는 출처 관리다.

LLM이 위키를 정리할 때 어떤 원본을 바탕으로 정리했는지 추적할 수 있어야 한다. 그래야 나중에 내용이 의심스러울 때 원문을 확인할 수 있다.

 

마지막으로, 자동화의 범위를 조심해야 한다.

LLM이 모든 지식을 마음대로 수정하게 두면 위험할 수 있다. 특히 회사 문서나 코드베이스처럼 정확성이 중요한 영역에서는 사람이 검토하는 단계가 필요하다.

즉, LLM Wiki는 “LLM이 알아서 다 해주는 문서 시스템”이라기보다는 “LLM과 사람이 함께 관리하는 지식베이스”로 보는 편이 더 적절하다.

 

결론

Karpathy의 LLM Wiki 아이디어는 RAG 이후의 지식 관리 방식을 생각하게 만든다.

 

기존 RAG가 질문 시점의 검색에 초점을 맞췄다면, LLM Wiki는 지식을 지속적으로 정리하고 유지하는 데 초점을 맞춘다.

핵심은 다음과 같다.

 

원본 자료를 raw sources로 보관한다.

LLM이 읽고 쓸 수 있는 마크다운 wiki를 만든다.

schema를 통해 작성 규칙과 구조를 정한다.

ingest, query, lint 과정을 통해 위키를 계속 갱신한다.

index와 log로 탐색성과 변경 이력을 관리한다.

 

이 방식은 특히 코드베이스, 연구 노트, 팀 문서, 개인 지식 관리에 잘 어울린다.

중요한 것은 LLM에게 단순히 더 많은 문서를 넣는 것이 아니라, LLM이 장기적으로 사용할 수 있는 지식 구조를 만들어주는 것이다.

앞으로 LLM을 잘 쓰는 사람과 팀은 단순히 프롬프트를 잘 쓰는 데서 그치지 않을 가능성이 높다.

LLM이 읽고, 수정하고, 다시 활용할 수 있는 지식 환경을 어떻게 설계하느냐가 점점 더 중요해질 것이다.

 

참고

Andrej Karpathy, LLM Wiki

https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

llm-wiki