LLM 위키: 새로운 AI 지식 아키텍처 이해하기

LLM 위키는 소스 문서를 수집할 때 이를 지속적이고 상호 연결된 지식 베이스로 컴파일한 뒤, 매번 원시 청크를 다시 검색하는 대신 그 베이스에서 답을 제공합니다. 이렇게 하면 질문할 때마다 매번 처음부터 지식을 재구성하는 대신, 소스를 추가할수록 지식이 축적됩니다.

LLM 위키 아이디어가 어디서 나왔는지, Retrieval-Augmented Generation (RAG)과 어떻게 비교되는지, 그리고 AI 시스템의 지식 관리 방식에 진정한 변화를 가져오는지 차근차근 살펴보겠습니다.

LLM 위키 개념의 기원

LLM 위키 아이디어는 2026년에 Andrej Karpathy가 제시했고, 이를 실제로 실행 가능한 형태로 발전시킨 몇몇 오픈 소스 프로젝트에서 받아들였습니다.

아이디어는 단순합니다. 2026년의 AI 시스템은 같은 문서를 반복해서 읽는 데 많은 시간을 씁니다. PDF를 업로드하면, 모델은 청크를 검색해 질문에 답하고 넘어갑니다. 다음 주에 같은 주제의 PDF를 또 업로드하면 모델은 똑같은 일을 반복합니다. 아무것도 이어지지 않습니다.

가장 큰 전환점은 검색과 컴파일이 서로 다른 작업이라는 점입니다.

예를 들어:

• 검색 우선 시스템은 질의 시점에 관련 텍스트 조각을 찾아 모델의 컨텍스트로 전달합니다. 모델은 검색기가 찾아 올린 것만으로 작업합니다.
• 컴파일 우선 시스템은 소스가 유입될 때 각 소스를 한 번 읽고 핵심을 추출해 구조화된 지식 베이스에 기록합니다. 이후 모델은 그 베이스에서 답합니다.

LLM 위키는 두 번째 범주에 속합니다. 새 소스를 추가하면, 모델은 이를 읽고 기존 페이지를 업데이트하며 필요한 경우 새 페이지를 만들고, 이미 정리된 내용과 모순되는 부분을 표시합니다. 소스를 추가할수록 지식 베이스는 확장되고, 모델은 그만큼 더 탄탄한 기반 위에서 답변할 수 있게 됩니다.

이는 RAG가 표준이 된 이래 지배적이었던 검색 우선 패러다임에서 처음으로 구체적으로 벗어난 접근입니다. RAG는 각 질의를 원시 문서에 대한 새로운 조회로 취급합니다. LLM 위키는 수집 시점에 일을 끝내고, 질의 시점에는 이미 충분히 숙고된 베이스를 읽도록 만듭니다.

LLM 위키란 무엇인가?

LLM 위키는 소스 문서에서 정보를 지속적으로 종합하여 구조화되고 상호 연결된 페이지로 유지·관리하는 AI 기반의 지속적 지식 베이스입니다.

폴더에 담긴 파일이나 벡터 스토어와 구분되는 세 가지 요소가 있습니다.

• 지속성: 페이지는 한 번 만들어지면 새 소스가 도착할 때마다 업데이트됩니다. 종합 내용이 이미 기록되어 있으므로 질의 시점에 다시 도출할 필요가 없습니다.
• 지속적 업데이트: 수집되는 모든 소스는 위키 전반의 수정을 유발합니다. 예를 들어 새로운 개체에 대한 새 페이지 생성, 기존 요약의 개정, 최신 데이터가 이전 주장과 충돌하는 지점에 대한 주석 추가 등이 있습니다.
• 이중 독자: 페이지는 사람이 읽기 편하면서도 AI 에이전트가 추론하기에 충분히 구조화되어 있습니다. 마크다운, 교차 링크, 일관된 레이아웃이 두 역할을 동시에 수행합니다.

핵심은 위키가 1차 지식 계층이 된다는 점입니다. 원본 문서는 감사 추적을 위해 원시 저장소에 남겨두되, 직접 질의하지는 않습니다. 채팅 시스템, 에이전트, 연구 보조 도구는 컴파일되고 상호 참조된 지식이 있는 위키를 읽습니다.

LLM 위키 아키텍처

아키텍처는 세 단계 파이프라인에 가깝습니다. 소스가 유입되고, 모델이 이를 위키 페이지로 컴파일하며, AI 애플리케이션이 그 페이지를 읽습니다. 

LLM 위키 아키텍처

각 단계를 차례로 보겠습니다.

소스 문서

텍스트 기반이라면 무엇이든 수집할 수 있습니다. 예를 들어:

• 문서와 PDF
• 개인 노트와 회의 녹취록
• 코드 저장소
• 기사에서 클리핑하거나 사이트에서 스크레이핑한 웹 콘텐츠

원시 소스는 불변 저장소에 보관됩니다. 한 번 수집되면 모델은 이를 읽기만 하고 수정하지 않으므로, 어떤 위키 주장도 해당 출처로 깔끔하게 추적할 수 있습니다.

지식 컴파일

이 단계에서 위키가 만들어집니다. 새 소스가 도착하면 모델은 다음 작업을 수행합니다.

• 개념 추출: 개체, 주제, 정의, 주장 등을 소스 텍스트에서 추출합니다.
• 기존 페이지 업데이트: 해당 개체나 개념의 페이지가 이미 있으면 새 정보를 반영해 개정하고, 모순점을 표시합니다.
• 새 페이지 생성: 기존 페이지에 들어맞지 않는 내용은 별도 페이지로 만듭니다.
• 관련 주제 연결: 위키가 성장해도 페이지가 연결된 상태를 유지하도록 양방향 교차 참조를 추가합니다.

단일 소스 수집으로 10~15개 페이지가 “업데이트”될 수 있습니다. 이게 핵심입니다. 새 자료를 기존 지식에 연결하는 작업을 RAG처럼 매 질의 시점이 아니라, 수집 시점에 한 번만 수행하는 것입니다.

AI 애플리케이션

위키는 다양한 소비자 유형이 읽을 수 있도록 설계됩니다. 예를 들어:

• 채팅 시스템은 원시 문서 대신 컴파일된 지식을 기반으로 질문에 답합니다.
• 연구 보조 도구는 교차 참조를 따라가며 주제에 대한 그림을 구축합니다.
• 소프트웨어 에이전트는 장기 작업 전반에 걸쳐 위키를 내구성 있는 메모리로 사용합니다.
• 엔터프라이즈 지식 시스템은 내부 도구, 대시보ards, or MCP servers.

위키는 가운데에 있습니다. 한쪽에서는 소스가 유입되고, 다른 쪽에서는 애플리케이션이 이를 읽으며, 컴파일 계층이 양쪽을 동기화합니다.

LLM 위키 vs 전통적 RAG

전통적 RAG와 LLM 위키의 가장 큰 차이는 ‘작업이 언제 수행되느냐’입니다.

전통적 RAG

RAG는 질의 시점에 문서 청크를 검색합니다. 질문을 하면 임베딩 검색이 벡터 스토어에서 상위 k개의 관련 청크를 가져오고, 그 청크가 질문과 함께 모델의 컨텍스트에 추가됩니다. 모델은 그 임시 컨텍스트에서 답을 생성하고, 응답이 완료되면 모든 것을 잊습니다.

컨텍스트는 일회용입니다. 

직전 질문에 답했던 청크는 모델이 답변을 마치는 순간 컨텍스트에서 사라집니다. 내일 관련 질문을 하면 검색기는 다시 실행되고, 청크를 다시 가져오며, 모델은 다시 종합합니다. 질의 사이에 축적되는 것은 없습니다.

LLM 위키

LLM 위키는 수집 동안 정보를 컴파일합니다. 소스를 추가하면 모델은 한 번 읽고, 중요한 내용을 구조화된 페이지로 작성하고, 교차 참조를 업데이트하며, 결과를 내구성 있는 마크다운으로 저장합니다. 따라서 질의 시점에는 원시 청크에서 다시 종합하지 않고, 컴파일된 베이스에서 읽는 일이 됩니다.

지식은 지속되며, 진화합니다. 

새 소스마다 위키 전반에 걸쳐 수정이 이루어지므로, 모순이 표시되고, 오래된 요약이 개정되며, 주제 간 연결은 시간이 갈수록 조밀해집니다.

트레이드오프

어느 한쪽이 항상 더 낫지는 않습니다. 최적화 목표가 다릅니다.

다음 사항을 유념하세요:

• 최신성: RAG는 질의 시점에 원본 문서를 직접 읽기 때문에 이 점에서 유리합니다. 기본 문서를 업데이트하면 다음 질의에서 즉시 반영됩니다. LLM 위키는 페이지를 업데이트하려면 소스를 재수집해야 하므로 원시 사실과 컴파일된 지식 사이에 지연이 발생합니다.
• 정확성: 많은 소스에 걸쳐 종합이 필요한 질문에서는 LLM 위키가 유리합니다. 종합이 이미 이루어져 있고 검토되어 있기 때문입니다. RAG는 관련 조각이 컨텍스트 윈도우에 담을 수 있는 범위를 넘는다면 연결 고리를 놓칠 수 있습니다. 한 번에 전체 그림을 보지 못하기 때문입니다.
• 유지보수: RAG는 일단 벡터 스토어를 구축하면 인덱싱이 기계적이어서 거의 유지보수가 없습니다. LLM 위키는 활성 유지가 필요합니다. 예를 들어 오래된 주장 감지용 린트 패스, 모순 검사, 고아 페이지 정리를 위한 간헐적 검토 등이 있습니다. 그 대가로, 유지되는 위키는 시간이 지날수록 풍부해지는 반면 RAG 인덱스는 평면적으로 유지됩니다.
• 확장성: RAG는 검색 문제이므로 문서 수에 따라 예측 가능하게 확장됩니다. LLM 위키는 규모가 커질수록 컴파일된 지식을 일관되게 유지할 수 있는 모델의 능력에 좌우됩니다. 일정 규모를 넘으면 위키 자체에 인덱스 파일, 검색 도구, 임베딩 레이어가 필요해집니다.

나란히 정리하면 다음과 같습니다:

LLM 위키와 RAG 비교

실무에서는 RAG와 LLM 위키가 상호 보완적이기도 합니다. 일부 구현은 위키가 인덱스 파일로 감당하기 어려울 만큼 커지면 위키 자체에 RAG를 적용합니다.

AI 에이전트가 LLM 위키에서 얻는 이점

AI 에이전트는 채팅 시스템보다 무메모리 문제의 타격이 큽니다. 단일 대화에서는 재검색을 어느 정도 감내할 수 있지만, 에이전트는 수시간에서 수일 동안 실행되며 수십 개 작업에 걸쳐 같은 사실을 반복해서 다시 발견합니다. LLM 위키는 배운 것을 저장할 곳을 제공해 다시 배울 필요가 없게 합니다.

지속적 지식이 가장 잠재력을 보이는 영역은 다음과 같습니다:

• 소프트웨어 개발: 몇 주에 걸쳐 코드베이스에서 작업하는 코딩 에이전트는 모듈, 규약, 과거 버그, 설계 결정에 대한 지식을 쌓습니다. 위키가 없으면 그 컨텍스트는 매 세션마다 다시 구축됩니다. 위키가 있으면, 에이전트는 컴파일된 페이지를 읽고 지난 세션이 끝난 지점에서 이어갑니다.
• 장기 연구: 수백 편 논문에 걸쳐 주제를 추적하는 에이전트는 모든 내용을 컨텍스트에 담을 수 없습니다. 위키는 요약을 정리하고 변화하는 흐름을 전체 코퍼스를 재독하지 않고도 재방문할 수 있게 합니다.
• 엔터프라이즈 어시스턴트: 사내에 배포된 어시스턴트는 매일 다른 직원들로부터 같은 질문을 받습니다. 위키를 통해 매 요청마다 같은 페이지 집합을 검색하는 대신 컴파일된 내부 지식으로 답할 수 있습니다.
• 조직 메모리: 사람이 떠나거나 회의가 끝나면 팀은 컨텍스트를 잃습니다. 녹취록, 티켓, 문서로 공급되는 LLM 위키는 그 컨텍스트를 유지합니다.

올바르게 구현하면, LLM 위키의 효과는 다음 세 가지에서 드러납니다:

1. 중복 검색 감소: 컴파일된 페이지를 읽는 에이전트는 어제 실행했던 동일한 웹 검색이나 벡터 쿼리를 반복할 필요가 없습니다.
2. 더 풍부한 컨텍스트: 위키 페이지에는 이미 종합 정보가 담겨 있으므로, 에이전트는 원시 청크보다 더 조밀하고 잘 연결된 기반에서 각 작업을 시작합니다.
3. 누적 학습: 모든 세션이 위키에 기여하며, 다음 세션은 이전 세션의 성과를 토대로 이익을 얻습니다. 이렇게 해야 에이전트가 매 프롬프트마다 초기화되지 않고 시간이 지날수록 실제로 업무 능력이 향상됩니다.

LLM 위키 구축

위키 구축 워크플로우는 반복 루프입니다. 소스가 들어오고, 페이지가 작성·재작성되며, 코퍼스가 커질수록 전체가 스스로 정제됩니다.

LLM 위키 구축 루프

• 문서 수집. 첫 단계는 소스를 원시 저장소에 넣는 것입니다. 문서는 한 번 읽힌 뒤 불변 상태로 보관되어, 이후의 모든 주장을 특정 출처로 추적할 수 있습니다. 수집은 단일 파일, 배치, 혹은 모델이 감시하는 폴더에서의 스트림일 수 있습니다.
• 개체와 개념 식별. 새 소스마다 모델은 중요한 것—명명된 개체, 핵심 개념, 주장, 정의, 관계—을 추출합니다. 이 순간 비정형 텍스트가 위키가 분류할 수 있는 형태로 바뀝니다. 추출 과정은 기존 위키를 확인해 이미 다룬 내용과 새로움도 판별합니다.
• 페이지 생성 또는 업데이트. 새 개체에는 새 페이지를, 기존 페이지에는 새 정보를 반영한 개정을 수행합니다. 새 소스가 기존 주장과 충돌하면 덮어쓰지 않고 페이지에 표시합니다. 단일 소스 수집으로도 보통 10~15개 페이지가 수정되는데, 소스는 대개 한 가지 이상의 내용을 다루기 때문입니다.
• 링크 유지. 페이지가 연결된 상태를 유지하도록 양방향 교차 참조를 추가합니다. 새 RAG 페이지가 벡터 데이터베이스를 언급하고, vector databases 페이지가 이미 있다면, 두 페이지 모두 서로 연결됩니다.
• 지속적 정제. 주기적 린트 패스로 시간이 지나며 누적되는 문제를 잡습니다. 예를 들어 페이지 간 모순, 최신 소스가 대체한 오래된 주장, 아무도 링크하지 않는 고아 페이지, 스쳐 지나가듯 언급됐지만 전용 페이지가 없는 중요한 개념 등이 있습니다. 이 단계가 위키의 확장 과정에서 건강함을 유지합니다.

세부 구현은 스택에 따라 달라지지만, 전체 형태는 비슷합니다. 수집, 추출, 작성, 연결, 정제—그리고 다시 루프.

LLM 위키 시스템의 공통 기능

대부분의 LLM 위키 구현은 유사한 기능 세트를 갖추고 있습니다. 세부는 다르지만, 구성 요소는 프로젝트 간에 공유됩니다.

자동 지식 컴파일

위키는 스스로 글을 씁니다. 소스가 수집되면 모델이 중요한 내용을 추출해 사람 개입 없이 페이지로 분류합니다. 수동 유지보수는 전통적 위키의 발목을 잡습니다. 사람은 교차 참조와 요약을 업데이트하는 일을 금세 지루해하기 때문입니다. 모델은 그렇지 않으므로, 이 기능이 전체 패턴을 가능하게 만듭니다.

연결된 페이지

모든 페이지는 교차 참조를 통해 관련 페이지와 연결됩니다. transformers 페이지가 attention mechanisms를 언급하면, 양쪽 페이지가 서로 연결됩니다. 그 결과 참조를 따라 걸어가며 탐색할 수 있는 그래프가 형성되어, 몰랐던 연결 고리를 발견할 수 있습니다.

출처 표기

모든 페이지의 모든 주장은 특정 출처로 추적됩니다. 원본 문서는 불변 상태로 남아 정보의 출처를 언제든 검증할 수 있습니다. 이는 두 가지 측면에서 중요합니다. 정확성 검증이 필요할 때 감사 추적을 제공하고, 출처가 제거되면 모델이 주장을 깔끔하게 철회할 수 있게 합니다.

지식 그래프

위키의 연결 구조 자체가 지식 그래프입니다. 노드는 페이지, 엣지는 교차 참조이며, 그래프의 형태는 코퍼스가 실제로 무엇을 다루는지 보여줍니다. 중요한 개념 주변에는 허브 페이지가 자연스레 생기고, 고아 페이지는 빈틈을 알리며, 조밀한 클러스터는 위키가 가장 잘 아는 영역을 나타냅니다.

지속적 메모리

위키는 세션을 넘어 이용 가능합니다. 대화 컨텍스트는 대화가 끝나면 사라지지만, 위키 페이지는 디스크에 마크다운으로 남습니다. 이것이 채팅 모델을 며칠, 프로젝트, 에이전트 실행에 걸쳐 지식을 이어갈 수 있게 바꿉니다.

지속적 업데이트

새 소스는 단순 추가가 아니라 기존 페이지의 수정을 유발합니다. 지난달 논문이 6개월 전 기록과 모순된다면, 위키는 이를 표시하고 영향을 받는 페이지를 업데이트합니다. 지식 베이스는 오래된 주장을 축적하기보다 시간이 지날수록 정확에 가까워집니다.

이 기능들은 서로 독립적이지 않습니다. 출처 표기가 없는 위키는 신뢰할 수 없습니다. 마찬가지로 지속적 업데이트가 없는 위키는 금세 낡아가고, 연결된 페이지가 없는 위키는 요약 모음일 뿐입니다. 가치는 이 모든 요소가 함께 작동할 때 생깁니다.

LLM 위키의 실제 적용 사례

지금까지 살펴본 패턴은 범용적입니다. 이제 LLM 위키가 유용할 수 있는, RAG보다 더 유용할 수도 있는 실제 적용 사례를 몇 가지 살펴보겠습니다.

연구 문헌

수십, 수백 편에 걸쳐 주제를 추적하는 누구나 같은 문제를 겪습니다—논문이 처리 속도보다 더 빨리 쌓인다는 점입니다. LLM 위키는 도착하는 각 논문을 읽고, 주장을 추출해 관련 개념 아래에 정리하고, 기존에 읽은 내용과의 모순을 표시합니다. 그 결과는 다시 읽지 않을 PDF 폴더가 아니라, 해당 분야의 최신 흐름을 반영한 지속적 종합물입니다.

엔지니어링 문서화

코드베이스는 대개 스프린트마다 문서 부채가 늘어납니다. 보통 설계 결정은 슬랙 스레드에서 이뤄지고, 아키텍처 노트는 누군가의 Notion에 남습니다. 실제 최신성을 보장받는 유일한 출처는 코드입니다. 코드베이스, 주석, PR, 내부 문서로 공급되는 위키는 코드와 연결된 시스템의 윤곽을 컴파일할 수 있습니다. 엔지니어는 3년 전 그 모듈을 작성한 사람에게 묻는 대신 위키에 질문할 수 있습니다.

엔터프라이즈 지식 베이스

기업은 티켓, 회의 녹취록, 제품 사양, 내부 위키 전반에 걸쳐 지식을 축적합니다. LLM 위키는 이 모든 곳에서 수집해 단일 지식 계층으로 컴파일하여 최신 상태를 유지할 수 있습니다. 직원은 네 가지 도구를 따로 검색하지 않고 한 번만 질의하면 됩니다.

개인 지식 관리

노트 앱은 저장 문제는 해결했지만 종합 문제는 해결하지 못했습니다. 여전히 수백 개의 노트, 글, 하이라이트가 있고, 대부분은 다시 보지 않습니다. 예를 들어 Obsidian 볼트를 공급원으로 하는 위키는 산더미 같은 노트를 실제로 질의할 수 있는 컴파일된 지식체로 바꿔줍니다. 

AI 에이전트 메모리

수시간에서 수일 동안 실행되는 에이전트는 배운 것을 저장할 장소가 필요합니다. 위키는 세션을 넘어 사용할 수 있는 내구성 있는 메모리를 제공—무엇이 통했고, 무엇이 통하지 않았는지, 이미 읽은 파일, 시도했던 경로 등을 담습니다. 이는 특히 top of Claude Code or similar tools 기반의 에이전트에서 유용합니다. 동일한 코드베이스를 여러 세션에 걸쳐 작업하므로, 이전 실행의 컨텍스트가 현재 실행의 효율을 좌우합니다.

현재 LLM 위키 구현 현황

2026년의 LLM 위키 분야는 초기 단계입니다. 존재하는 것의 대부분은 개인 또는 소규모 팀이 만든 오픈 소스입니다. 현재 RAG 수준과는 거리가 있습니다.

Karpathy's original gist is where a lot of 구현자들이 출발했습니다. 이 문서는 패턴을 충분한 상세로 설명해, LLM 에이전트를 보유한 누구나 Claude Code 같은 도구에 문서를 붙여 넣어 자체 버전을 구축할 수 있도록 합니다. 현재 존재하는 많은 위키는 공유된 아이디어 위에 구축된 개인 프로젝트로 시작합니다.

오픈 소스 노력이 아이디어가 구체화되는 장입니다. like llm-wiki.net publish their 코드를 관대한 라이선스로 공개해, 다른 이들이 포크·확장·자신의 워크플로우에 맞게 적응시킬 수 있게 합니다. 장점은 위키가 무엇을 하는지 정확히 볼 수 있고, 기본 설정이 필요와 맞지 않을 때 변경할 수 있다는 점입니다.

로컬 우선 접근은 전적으로 사용자의 머신에서 실행됩니다. 소스는 디스크에 저장되고, 위키는 마크다운 파일 폴더이며, 모델은 로컬 에이전트를 통해 읽고 씁니다. 마크다운과 교차 참조에 최적화된 Obsidian이 가장 흔한 프런트엔드입니다. 소스가 머신 밖으로 나가지 않고, 모델이 작성한 모든 페이지를 검토할 수 있어 통제력이 큽니다.

호스팅형 구현도 등장하기 시작했지만 아직은 드뭅니다. 위키는 본질적으로 사용자 소유—사용자 소스, 사용자 페이지, 분류 결정—이기 때문에, 이 패턴은 RAG만큼 SaaS 모델에 잘 맞지 않습니다. 호스팅형은 대체로 팀 위키에서, 공유 지식의 가치가 타인의 인프라에 소스를 호스팅하는 비용을 상회할 때 가장 잘 작동합니다.

하지만 2026년 7월 현재, 어느 것도 완성 단계가 아닙니다. 여전히 많은 부분이 모색 중이며, 오늘 존재하는 대부분의 프로젝트는 프로토타입에 가깝습니다.

장점과 한계

LLM 위키 패턴은 강점과 비용을 모두 갖습니다. 구축 여부를 결정하기 전에 양쪽을 아는 것이 좋습니다.

장점

• 지속적 지식: 위키는 단일 세션이 끝난 뒤에도 남아 있습니다. 모델이 지난달 도출한 내용은 오늘도 페이지에 남아 있고, 새 작업은 초기화가 아니라 그 위에 구축됩니다.
• 재사용 가능한 종합: 소스 간 연결 작업은 수집 시점에 한 번만 이뤄집니다. 이후의 모든 질의는 원시 텍스트에서 재종합하지 않고 컴파일된 결과를 읽습니다. 연산을 절약하고, 모델이 이미 사고 과정을 거쳤기 때문에 더 나은 답을 제공합니다.
• 반복 검색 감소: 특정 주제에 대한 페이지가 이미 있는 위키는 그 주제가 나올 때마다 원시 코퍼스를 검색할 필요가 없습니다. 이는 수시간 동안 실행되며 같은 검색을 반복할 여지가 큰 에이전트에게 특히 중요합니다.
• 구조적 구성: 페이지와 교차 참조는 특히 PDF 폴더와 비교할 때 탐색과 추론이 가능한 형태를 제공합니다.

한계

• 최신 상태 유지: 소스가 변경되면 위키를 재수집해야 합니다. 문서가 업데이트됐는데 수집을 재실행하지 않으면 위키는 이전 버전을 참조합니다. RAG는 질의 시점에 라이브 소스를 읽기 때문에 이 문제가 없습니다.
• 검증의 어려움: 위키 페이지의 모든 주장은 모델이 작성했습니다. 출처 표기가 도움은 되지만, 모델이 출처를 올바르게 요약했다는 점을 여전히 신뢰해야 합니다.
• 유지보수: 모순 검사와 재수집은 공짜가 아닙니다. 유지되지 않는 위키는 낡아가고, 유지에는 모델이 일을 하더라도 시간과 연산이 듭니다.
• 지식 드리프트 가능성: 매 수집은 모델이 작은 오류를 도입할 기회입니다. 수백 번의 수집이 누적되면 이들이 복합적으로 작용할 수 있습니다. 처음에는 정확했던 페이지가 충분한 개정을 거친 후에는 미세하게 틀어질 수 있습니다.

LLM 위키에 대한 흔한 오해

LLM 위키는 새 개념이지만, 이미 몇 가지 오해가 있습니다. 무엇이 잘못됐는지 살펴보겠습니다.

LLM 위키는 RAG를 대체한다

그렇지 않습니다. 두 방법은 서로 다른 문제를 풉니다. RAG는 자주 변하는 코퍼스에 대한 빠른 조회에 적합합니다. LLM 위키는 시간이 지나며 지식체를 구축하는 데 적합합니다. 실제 시스템의 상당수는 둘 다 사용합니다—원시 소스의 최신성은 RAG로, 그 위의 컴파일된 종합은 위키로.

또 하나의 벡터 데이터베이스일 뿐이다

벡터 데이터베이스는 검색을 위해 텍스트를 인덱싱합니다. LLM 위키는 모델이 읽고, 이해하고, 재구성한 텍스트를 씁니다. 벡터 데이터베이스는 넣은 청크를 돌려줍니다. 위키는 소스를 수집하기 전엔 존재하지 않던 페이지를 돌려줍니다. 출력물이 전혀 다릅니다.

지식 베이스는 한 번 만들면 업데이트가 필요 없다

사실이 아닙니다. 소스는 변하고, 새 소스가 도착하며, 모델의 실수는 잡아야 합니다. 유지되지 않는 위키는 다른 문서화와 마찬가지로 낡아갑니다. 차이는 대부분의 유지보수를 모델이 처리한다는 점이지, 유지보수가 사라진다는 뜻은 아닙니다.

AI 에이전트에만 이득이 있다

에이전트는 실행 시간이 길고 내구성 있는 메모리의 이점을 가장 크게 보이므로 가장 분명한 사례이지만, 사람에게도 위키는 가치가 있습니다. 주제를 추적하는 연구자, 코드베이스에서 일하는 엔지니어를 떠올려 보세요. 개인 지식 베이스를 쌓는 모든 이가 같은 누적적 종합의 이익을 얻습니다. 

LLM 위키가 새로운 AI 아키텍처가 될까?

아직 단언하긴 이르지만, 가능성 있는 경로는 분명합니다. 지속적 지식은 검색 우선 시스템을 대체하지 않고 나란히 자리할 것입니다. 라이브 조회는 RAG가, 컴파일된 장기 컨텍스트는 위키가 담당합니다. 더 큰 미해결 과제는 검증과 규모입니다 — 모델 오류가 위키 페이지에 기록되는 것을 어떻게 잡아낼지, 매우 큰 위키에서 이 패턴이 스트레스 테스트를 통과할지 아직 아무도 완전히 해결하지 못했습니다. MCP는 에이전트에 위키를 노출하기에 자연스러운 적합처럼 보이지만, 신뢰 요건이 추가되므로 엔터프라이즈 채택은 더 더딜 것입니다.

아직 확립된 패턴은 아닙니다. 앞으로 나아갈지는 유지보수와 검증 문제를 해결할 수 있는지에 달려 있습니다. 이에 대한 추가 질문은 아래 FAQ에서 더 다룹니다.

결론

LLM 위키는 소스를 모델에 건넬 때 AI 시스템이 수행하는 일을 바꾼다는 점에서 2026년에 나온 가장 흥미로운 아이디어 중 하나입니다. 매 질의마다 같은 문서를 다시 읽는 대신, 모델이 한 번 읽고 시간이 지날수록 좋아지는 지식 베이스로 정리합니다.

개념은 아직 부상 중이고 현재 구현은 초기 단계이지만, 아이디어는 유망하며 더 큰 흐름을 가리킵니다. AI 시스템은 일회성 컨텍스트에서 지속적 지식으로 이동하고 있으며, LLM 위키는 그 변화가 실제로 어떤 모습일지 보여주는 첫 진지한 시도 중 하나입니다.

최신 동향을 따라가고 싶지만 혼란스럽다면, AI Fundamentals 트랙에 등록하세요. 용어를 익히고 업무에서 효과적으로 AI를 활용할 수 있게 됩니다.