LLM Wiki란? RAG 다음을 노리는 AI 지식 구조 3계층 정리

에그코드 개발 이야기 · AI 지식 구조

AI에 자료를 아무리 많이 넣어도, 다음 질문에서 또 처음부터입니다.

어제 읽힌 문서를 오늘 다시 찾아 읽습니다.

쌓이는 게 없다는 뜻입니다.

2026년 4월, 이 문제를 정면으로 건드린 글이 하나 올라왔습니다.

안드레이 카파시가 공개한 llm-wiki.md라는 짧은 문서입니다.

X에 올린 글은 1,600만 회 넘게 조회됐고, 공개된 gist는 5,000개가 넘는 스타를 받았습니다.

에그코드도 자체 서비스를 만들며 AI 도구를 매일 쓰는 입장이라, 그냥 넘기기 어려운 제안이었습니다.

이 글에서는 LLM Wiki가 무엇인지, RAG와 어떻게 다른지, 어떤 한계가 있는지까지 정리했습니다.

LLM Wiki란 무엇인가

여기서 LLM 뜻은 대규모 언어 모델(Large Language Model)입니다.

챗GPT나 클로드처럼 글을 읽고 쓰는 AI 모델을 말합니다.

형태는 특별하지 않습니다.

마크다운 문서가 들어 있는 폴더 하나입니다.

문서 생김새는 위키백과와 비슷합니다.

개념 하나에 페이지 하나, 페이지끼리는 링크로 이어집니다.

핵심은 누가 그 문서를 쓰느냐입니다.

사람이 아니라 AI가 씁니다.

자료를 하나 넣으면 AI가 읽고, 관련된 페이지들을 알아서 고쳐 씁니다.

RAG와 무엇이 다른가

RAG 뜻부터 짚고 가겠습니다.

검색 증강 생성(Retrieval-Augmented Generation)의 줄임말입니다.

AI가 답하기 전에 관련 문서를 찾아 읽고, 그 내용을 근거로 답하는 방식입니다.

챗GPT에 파일을 올려 질문할 때도 비슷한 일이 일어납니다.

다만 늘 같은 방식은 아닙니다.

파일이 작으면 내용을 통째로 넣고, 크면 조각내서 필요한 부분만 찾아 읽습니다.

방식은 갈려도 결과는 같습니다.

대화가 끝나면 정리된 내용이 남지 않는다는 점입니다.

어제 다섯 개 문서를 이어 붙여 답을 만들었어도, 오늘 같은 질문을 하면 처음부터 다시 합니다.

LLM Wiki는 정리하는 시점을 앞으로 당깁니다.

질문할 때가 아니라, 자료를 넣을 때 한 번 정리합니다.

한 가지는 짚고 가야 합니다.

둘은 대체 관계가 아닙니다.

원문이 자주 바뀌는 실시간 정보는 RAG가 낫습니다.

3개 층으로 이루어져 있습니다

LLM Wiki는 세 개의 층으로 나뉩니다.

누가 어느 층을 만지는지가 명확하게 갈립니다.

첫째, 원본 자료 층입니다.

직접 고른 논문, 기사, 문서, 데이터가 들어갑니다.

AI는 여기를 읽기만 하고 고치지 않습니다.

모든 주장의 출처가 되는 기준점이라, 훼손되면 안 되기 때문입니다.

둘째, 위키 층입니다.

AI가 만든 마크다운 문서들이 쌓이는 곳입니다.

이 층은 AI가 전부 소유합니다.

사람은 읽고, 쓰는 건 AI가 합니다.

셋째, 운영 규칙 층입니다.

CLAUDE.md나 AGENTS.md 같은 파일에 적습니다.

AI 도구에 지침을 주려고 원래 쓰던 파일인데, 여기서는 위키 관리 규칙을 적는 용도로 씁니다.

위키를 어떤 구조로 쓸지, 자료를 넣을 때 무엇을 할지 정해둔 문서입니다.

이 규칙 파일이 없으면 AI는 그냥 잡담 상대입니다.

실제로 하는 일은 3가지뿐입니다

운영은 생각보다 단순합니다.

넣고, 묻고, 점검합니다.

넣기(Ingest) — 자료를 하나 넣으면 AI가 읽고 위키 전체에 반영합니다.

요약 페이지를 만들고, 관련 개념 페이지를 갱신하고, 기존 내용과 충돌하면 표시해둡니다.

카파시는 자료 하나가 보통 10개에서 15개 페이지를 건드린다고 설명합니다.

묻기(Query) — 원문이 아니라 위키에 질문합니다.

목차를 먼저 훑고, 관련 페이지만 골라 읽고, 출처를 붙여 답합니다.

여기서 중요한 게 하나 있습니다.

잘 나온 답은 다시 위키에 새 페이지로 저장합니다.

점검(Lint) — 가끔 위키 자체의 상태를 검사합니다.

페이지끼리 모순은 없는지, 낡은 주장은 없는지, 아무 데도 연결되지 않은 페이지는 없는지 봅니다.

여기에 파일 두 개가 축이 됩니다.

index.md는 모든 페이지를 한 줄 요약과 함께 모아둔 목차입니다.

log.md는 언제 무엇을 넣고 물었는지 시간순으로 쌓는 기록입니다.

자료 100개, 페이지 수백 개 규모까지는 이 목차 방식만으로 돌아갑니다.

왜 지금 이 방식이 통할까

사실 이 아이디어 자체는 새롭지 않습니다.

카파시도 1945년 배니바 부시가 제안한 '메멕스(Memex)'와 닮았다고 언급합니다.

개인이 직접 고른 자료를 모으고, 자료 사이에 연결을 만들어두는 개인 서고 개념입니다.

그럼 80년 동안 왜 안 됐을까요.

읽고 생각하는 게 힘들어서가 아닙니다.

진짜 힘든 건 뒤치다꺼리입니다.

새 자료가 들어올 때마다 관련 문서 열 개를 열어 고치고, 링크를 다시 걸고, 어제 쓴 요약이 오늘 자료와 어긋나는지 확인하는 일.

사람은 이 일을 오래 못 합니다.

위키가 주는 가치보다 관리 부담이 먼저 커지기 때문입니다.

AI는 지치지 않습니다.

한 번에 열다섯 개 파일을 고치는 데 불평하지 않고, 링크 하나를 빠뜨리지도 않습니다.

알고 써야 할 4가지 한계

기대만 보고 들어가면 실망하기 쉽습니다.

네 가지는 미리 계산에 넣으셔야 합니다.

하나, 원문이 바뀌면 다시 넣어야 합니다.

위키는 넣은 시점의 내용을 붙들고 있습니다.

원문이 갱신돼도 다시 넣지 않으면 옛 내용을 계속 말합니다.

둘, 모든 문장을 모델이 씁니다.

위키 페이지의 문장은 사람이 쓴 게 아닙니다.

출처를 달아둬도, 요약이 정확한지는 결국 사람이 확인해야 합니다.

셋, 관리에도 비용이 듭니다.

모순 점검과 재정리는 공짜가 아닙니다.

손이 덜 갈 뿐, 시간과 연산 비용은 계속 들어갑니다.

넷, 오차가 조금씩 쌓입니다.

자료를 넣을 때마다 작은 오류가 섞일 수 있습니다.

수백 번 반복되면 처음엔 맞던 페이지가 조금씩 틀어집니다.

시작하는 방법

거창한 준비는 필요 없습니다.

설치할 프로그램도, 데이터베이스도 없습니다.

1단계, 폴더를 두 개 만듭니다.

원본 자료를 넣을 폴더와 위키가 쌓일 폴더를 나눕니다.

원본 폴더는 AI가 건드리지 않는 영역으로 둡니다.

2단계, 운영 규칙 파일을 적습니다.

자료를 넣을 때 무엇을 할지, 페이지를 어떤 형식으로 쓸지 정리합니다.

처음부터 완벽할 필요는 없고, 쓰면서 고쳐갑니다.

3단계, 자료를 하나씩 넣습니다.

한 번에 몰아넣지 말고 하나씩 넣으면서 결과를 읽어보세요.

도구는 파일을 직접 읽고 쓰는 코딩 에이전트가 필요합니다.

클로드코드나 Codex 같은 도구가 여기 해당합니다.

메모 앱 옵시디언을 AI 작업에 함께 쓰신다면, 그래프 뷰로 어떤 페이지가 중심이고 어떤 게 외톨이인지 한눈에 보입니다.

결과물이 그냥 마크다운 파일이라, 깃(Git)에 올리면 변경 이력과 되돌리기가 그대로 따라옵니다.

마치며

LLM Wiki는 아직 정립된 방식이 아닙니다.

대규모 환경에서 검증되지도 않았고, 검증 문제도 남아 있습니다.

모든 상황의 정답도 아닙니다.

자주 바뀌는 정보를 다룬다면 RAG가 더 나은 선택입니다.

다만 방향 하나는 분명해 보입니다.

지금 쓰고 계신 AI 도구에 자료를 계속 넣고 계신다면, 한 번 확인해보세요.

그 결과가 어디에 남고 있는지.

함께 읽어보세요 — 검색을 스스로 운전하는 Agentic RAG · 정보를 그래프로 잇는 GraphRAG · 대화가 길어질수록 AI가 헛소리하는 3가지 이유