[심층분석] 매번 처음부터 읽는 RAG는 그만, AI가 직접 위키를 쓰고 키우는 LLM Wiki 파헤치기

들어가며: 매번 처음부터 읽는 AI, 이제 그만

회사 위키나 노션에 문서가 잔뜩 쌓여 있는데, 정작 필요한 걸 찾으려면 한참 헤매는 경험, 다들 있으시죠? 그래서 지난 2년 동안 정말 많은 팀이 RAG를 도입했어요. RAG(Retrieval-Augmented Generation)라는 건, 쉽게 말해서 질문이 들어오면 문서 창고에서 관련 있어 보이는 조각을 몇 개 꺼내 와서 AI에게 '이거 읽고 답해줘'라고 시키는 방식이거든요.

문제는 이 방식이 매번 처음부터 시작한다는 거예요. 어제 물어본 질문과 오늘 물어본 질문이 사실 같은 주제인데도, AI는 매번 새로 문서 조각을 꺼내 읽고 답을 만들어요. 읽은 내용을 기억하지도, 정리해두지도 않아요. 마치 시험 볼 때마다 교과서를 처음부터 뒤지는 학생 같은 거죠. 공부한 게 쌓이지 않으니 실력이 늘 리가 없어요.

오늘 소개할 nashsu/llm_wiki는 이 문제를 정면으로 겨냥한 데스크톱 앱이에요. 핵심 아이디어는 한 줄로 요약돼요. 'AI가 문서를 읽고 버리는 게 아니라, 읽으면서 위키를 쓰고, 계속 고쳐 나가게 하자.' 이게 왜 중요한지, 어떻게 구현했는지, 우리 실무에 어떻게 써먹을 수 있는지 차근차근 풀어볼게요.

LLM Wiki가 뭐냐면

한 문장으로 말하면 '스스로 만들어지는 개인 지식 베이스'예요. PDF, 오피스 문서, EPUB, 웹 클립, 이미지 같은 자료를 넣어주면 LLM이 그걸 읽고 위키피디아처럼 개념별 페이지를 만들어요. 그리고 페이지끼리 링크를 걸어주고, 새 자료가 들어오면 기존 페이지를 업데이트해요.

여기서 '위키'라는 말에 주목해 주세요. 위키의 본질은 두 가지예요. 하나는 '주제별로 정리된 페이지', 다른 하나는 '페이지 사이의 링크'예요. RAG는 원문을 조각내서 보관할 뿐이지 이런 구조를 만들지 않거든요. LLM Wiki는 원문을 재료로 삼아 새로운 구조물을 짓는 거예요. 그래서 이 프로젝트를 'RAG의 대안'이라고 부르는 거죠.

이 아이디어의 뿌리는 Andrej Karpathy가 공개한 'LLM Wiki' 메모예요. 저장소 루트에 llm-wiki.md 파일이 있고 Credits 섹션에서도 그 점을 밝히고 있어요. 'LLM이 매번 문서를 다시 읽는 대신 읽은 내용을 위키 형태로 축적하고 관리하면 지식이 복리처럼 쌓인다'는 취지인데, 이 프로젝트는 그 메모를 실제로 동작하는 크로스 플랫폼 앱으로 구현한 거예요.

기술 분석: 어떻게 동작하나

1. 2단계 Chain-of-Thought 인제스트

인제스트(ingest)라는 건, 쉽게 말해서 문서를 시스템 안으로 집어넣고 소화시키는 과정이에요. 이 프로젝트는 이걸 두 단계로 나눠서 해요.

• 1단계, 분석: LLM이 문서를 먼저 읽고 '어떤 개념이 나오는지, 기존 위키의 어떤 페이지와 관련이 있는지, 새로 만들 페이지는 무엇인지'를 정리해요. 아직 위키 페이지를 쓰지는 않아요.
• 2단계, 생성: 1단계 분석 결과를 바탕으로 실제 위키 페이지를 쓰거나 고쳐요.

왜 굳이 나눌까요? 한 번에 '읽고 바로 위키 써'라고 시키면 LLM이 문서 하나에 매몰돼서 기존 위키와 어긋나는 페이지를 만들기 쉽거든요. 먼저 큰 그림을 보고 계획을 세운 뒤 쓰게 하면 일관성이 훨씬 좋아져요. 사람도 보고서 쓸 때 목차부터 잡고 본문을 쓰는 것과 똑같아요.

여기에 두 가지가 더 붙어요. '소스 추적성(source traceability)'은 위키의 모든 내용이 어느 원문의 어디에서 왔는지 기록해두는 거예요. AI가 지어낸 말인지 원문에 있는 말인지 바로 확인할 수 있죠. '증분 캐시(incremental cache)'는 이미 처리한 문서를 다시 처리하지 않게 해주는 거예요. 100개 문서 중 1개만 바뀌었는데 100개를 다시 읽으면 시간과 API 비용이 낭비되니까요.

2. 4-신호 지식 그래프와 Louvain 커뮤니티 탐지

위키 페이지가 수백 개 쌓이면 어느 페이지가 어느 페이지와 진짜 관련이 있는지 알아내는 게 중요해져요. 이 프로젝트는 네 가지 신호를 조합해서 관련도 점수를 매겨요.

1. 직접 링크: A 페이지가 B 페이지를 링크하고 있으면 당연히 관련이 깊죠.
2. 소스 겹침: 두 페이지가 같은 원문 문서에서 나왔으면 관련 있을 확률이 높아요.
3. Adamic-Adar: 이게 뭐냐면, 소셜 네트워크에서 쓰는 '공통 친구' 지표예요. A와 B가 공통으로 링크하는 페이지 C가 있을 때, C가 모든 페이지가 다 링크하는 허브(예: '머신러닝 개론')라면 그 공통점은 별 의미가 없고, C가 드물게 언급되는 페이지라면 그 공통점은 아주 의미가 크다고 보는 거예요. 흔한 친구보다 희귀한 공통 친구가 더 강한 연결을 뜻한다는 직관이죠.
4. 타입 친화도: '사람' 페이지와 '조직' 페이지처럼 페이지 종류에 따라 원래 잘 붙는 조합이 있다는 걸 반영해요.

이렇게 만든 그래프 위에 Louvain 알고리즘을 돌려요. Louvain은 그래프에서 서로 끈끈하게 연결된 덩어리를 자동으로 찾아내는 커뮤니티 탐지 알고리즘이에요. 친구 관계 그래프에서 '고등학교 친구 그룹', '회사 동료 그룹'을 자동으로 구분하는 것과 같아요. 이걸 위키에 적용하면 '당신 지식 베이스에는 이런 주제 클러스터가 7개 있어요' 하고 알려줄 수 있죠. 클러스터마다 응집도 점수까지 붙여줘서 어떤 주제가 탄탄하게 정리됐고 어떤 주제가 아직 흐릿한지 한눈에 보여요.

그래프가 있으면 재미있는 걸 더 할 수 있어요. Graph Insights의 '놀라운 연결'은 서로 다른 클러스터에 있는데 의외로 강하게 이어진 페이지 쌍을 찾아줘요. '분산 시스템' 클러스터와 '조직 관리' 클러스터가 '콘웨이의 법칙' 페이지로 연결돼 있다면 꽤 흥미로운 발견이잖아요. 반대로 '지식 공백'은 여러 페이지에서 언급은 되는데 아직 자체 페이지가 없는 개념을 찾아주고, 원클릭 딥 리서치로 그 공백을 채울 수 있게 해뒀어요. 위키가 스스로 부족한 부분을 인식하고 채워 나가는 구조인 거죠.

3. 멀티모달 이미지 인제스트

PDF에 들어 있는 그림, 도표, 스크린샷은 기존 RAG에서 거의 버려지던 정보예요. 텍스트만 뽑아 쓰니까요. 이 프로젝트는 PDF에서 이미지를 뽑아내고, 비전 LLM(이미지를 볼 수 있는 모델)에게 사실 기반 캡션을 쓰게 해요. '2023년 대비 2024년 매출이 30% 증가한 막대 그래프' 같은 식으로요. 그러면 나중에 '매출 그래프 어디 있었지?' 하고 검색했을 때 이미지가 결과에 나오고, 라이트박스로 크게 보고, 원문 위치로 바로 점프할 수 있어요.

4. 소스 그라운딩 모드와 벡터 검색

위키 방식의 약점 하나는 LLM이 정리하는 과정에서 원문의 뉘앙스를 살짝 바꿔버릴 수 있다는 거예요. 그래서 'Read Sources Only' 모드가 있어요. 이 모드에서는 위키 페이지를 무시하고 원문 자료만 보고 답하게 해요. 계약서 조항이나 논문 수치처럼 한 글자도 틀리면 안 되는 질문에 유용하죠.

벡터 검색은 LanceDB를 써서 선택적으로 켤 수 있어요. 벡터 검색이 뭐냐면, 단어가 정확히 일치하지 않아도 의미가 비슷한 문서를 찾아주는 기술이에요. '자동차'로 검색했는데 '승용차' 문서가 나오는 식이죠. OpenAI 호환 임베딩 API면 뭐든 붙일 수 있어서 로컬 모델도 쓸 수 있어요. 재미있는 건 이걸 필수가 아닌 선택으로 뒀다는 점이에요. 위키 구조와 링크 자체가 이미 강력한 탐색 수단이니까 벡터 검색은 보조라는 설계 철학이 읽혀요.

5. 기술 스택과 확장성

저장소를 보면 src-tauri 폴더와 vite.config.ts, components.json이 있어요. 즉 Tauri(Rust 기반 데스크톱 프레임워크) + React + TypeScript + Vite + shadcn/ui 조합이에요. Tauri는 Electron과 비슷한 역할인데, Chromium을 통째로 안고 가는 대신 운영체제의 웹뷰를 쓰기 때문에 앱 크기가 훨씬 작고 메모리도 적게 먹어요.

주목할 폴더가 두 개 더 있어요. 'mcp-server'는 MCP(Model Context Protocol) 서버예요. MCP가 뭐냐면, AI 에이전트가 외부 도구나 데이터에 접근할 때 쓰는 표준 규격이에요. 이게 있으면 Claude Code나 Cursor 같은 도구에서 '내 위키에서 이 개념 찾아봐'라고 바로 시킬 수 있어요. 'extension'은 브라우저 확장으로, 웹 페이지를 클립해서 위키에 바로 넣는 용도예요.

모델 설정도 유연해요. 프로젝트마다 다른 모델을 쓸 수 있고, 채팅용 모델과 인제스트용 모델을 따로 지정할 수 있어요. 인제스트는 대량 처리라서 저렴하고 빠른 모델, 채팅은 품질 좋은 모델을 쓰는 식으로 비용을 아낄 수 있죠. PDF 파싱은 내장 파서, 클라우드 MinerU, 로컬 MinerU 중에서 고를 수 있어요. MinerU는 복잡한 레이아웃의 PDF에서 표와 수식을 잘 뽑아내는 오픈소스 도구예요.

RAG vs LLM Wiki: 비유로 이해하기

두 접근법의 차이를 도서관 비유로 정리해볼게요.

RAG는 사서 없는 도서관이에요. 책은 다 있는데 정리가 안 돼 있어요. 질문이 들어오면 검색기가 관련 페이지를 몇 장 복사해 오고, AI가 그 자리에서 읽고 답해요. 장점은 준비가 간단하고 원문에 충실하다는 거예요. 단점은 여러 책에 흩어진 정보를 종합하는 질문에 약하고, 같은 질문을 100번 해도 100번 똑같이 뒤진다는 거죠.

LLM Wiki는 부지런한 사서가 있는 도서관이에요. 새 책이 들어오면 사서가 읽고 주제별 카드를 만들고, 관련 카드끼리 연결해두고, 기존 카드에 내용을 보충해요. 질문이 들어오면 카드 시스템을 따라가면 되니까 종합적인 답이 빨라요. 단점은 사서가 실수할 수 있다는 거예요. 카드에 잘못 요약하면 그 오류가 계속 남죠. 그래서 소스 추적성과 Read Sources Only 모드가 안전장치로 붙어 있는 거예요.

| 항목 | 전통 RAG | LLM Wiki |
|---|---|---|
| 지식 축적 | 없음, 매번 새로 검색 | 위키 페이지로 누적 |
| 종합 질문 | 약함 | 강함 |
| 원문 충실도 | 높음 | 왜곡 가능, 추적성으로 보완 |
| 초기 비용 | 낮음 | 인제스트 시 LLM 호출 비용 |
| 구조 탐색 | 불가 | 그래프, 클러스터, 링크 탐색 |

기존 도구들과도 비교해볼게요. Obsidian은 훌륭한 링크 기반 노트 앱이지만 페이지를 사람이 직접 써야 해요. LLM Wiki는 그 쓰는 일을 AI가 대신하는 셈이죠. NotebookLM은 소스 기반 질답에 강하지만 클라우드 서비스라서 데이터를 밖으로 보내야 하고, 소스를 위키로 재구성해주진 않아요. LLM Wiki는 로컬 데스크톱 앱이라 데이터가 내 컴퓨터에 남고, 어떤 모델을 쓸지도 내가 정해요. 이 '로컬 우선, 모델 자유' 포지션이 이 프로젝트의 차별점이에요.

한국 개발자에게 주는 시사점

시나리오 1: 팀 온보딩 문서 정리

신입이 들어올 때마다 '노션 보세요'라고 말하지만 사실 노션이 뒤죽박죽인 팀 많죠. 기술 문서, 회의록, 슬랙 정리본을 LLM Wiki에 넣으면 '서비스 아키텍처', '배포 절차', '온콜 규칙' 같은 페이지가 자동으로 생기고 서로 링크돼요. 지식 공백 기능은 '다들 언급하는데 문서화가 안 된 개념'을 짚어주니 문서화 우선순위를 정하는 데도 유용해요.

시나리오 2: 논문과 기술 블로그 개인 아카이브

매주 논문이나 기술 아티클을 읽지만 한 달 뒤엔 잊어버리는 분이라면, 브라우저 확장으로 클립해서 넣기만 하면 돼요. 몇 달 쌓이면 Louvain 클러스터로 '내가 요즘 어떤 주제를 파고 있는지'가 보이고, 놀라운 연결 기능이 생각지 못한 논문 조합을 제안해줘요.

시나리오 3: 코딩 에이전트의 장기 기억

MCP 서버 덕분에 Claude Code 같은 에이전트가 위키를 도구로 쓸 수 있어요. 프로젝트의 설계 결정, 과거 장애 회고, 도메인 용어를 위키에 넣어두면 에이전트가 코드를 고칠 때 '이 모듈은 왜 이렇게 설계됐지?'를 스스로 찾아볼 수 있어요.

도입 시 고려할 점

• API 비용: 인제스트 단계에서 문서마다 LLM을 두 번 호출해요. 수천 페이지를 한 번에 넣으면 비용이 꽤 나올 수 있으니 인제스트용 모델은 저렴한 것으로 지정하고 증분 캐시를 잘 활용하세요.
• 한국어 품질: 위키 생성 품질은 모델의 한국어 능력에 좌우돼요. README에 한국어 번역이 있을 만큼 다국어를 신경 쓴 프로젝트지만, 모델은 직접 골라야 하니 한국어에 강한 모델을 인제스트용으로 두는 게 좋아요.
• 민감 정보: 로컬 앱이지만 LLM API 호출은 외부로 나가요. 사내 기밀 문서라면 Ollama 같은 OpenAI 호환 로컬 엔드포인트를 붙이는 방안을 검토하세요.
• 위키 오류 검수: AI가 정리한 페이지가 항상 맞진 않아요. 중요한 답은 소스 추적 링크로 원문을 확인하는 습관이 필요해요.

학습 로드맵

1. RAG의 기본 흐름(청킹, 임베딩, 검색, 생성)을 한 번 직접 구현해보세요. 그래야 LLM Wiki가 무엇을 다르게 하는지 체감돼요.
2. 저장소의 llm-wiki.md와 Karpathy의 원본 메모를 읽고 설계 철학을 이해하세요.
3. 앱을 설치해서 본인이 읽은 아티클 20~30개를 넣어보고, 생성된 위키와 그래프를 살펴보세요.
4. mcp-server 폴더 코드를 읽으면서 MCP가 어떻게 동작하는지 익히세요. 요즘 에이전트 개발의 핵심 규격이라 알아두면 두루 쓰여요.
5. 여유가 되면 4-신호 그래프와 Louvain 부분 코드를 읽어보세요. 그래프 알고리즘이 실제 제품에 어떻게 녹아드는지 배울 수 있는 좋은 예시예요.

마무리: 검색에서 축적으로

지난 2년은 'AI에게 어떻게 문서를 찾아 먹일까'를 고민한 RAG의 시대였어요. LLM Wiki는 질문을 바꿔요. 'AI가 읽은 걸 어떻게 쌓아둘까'로요. 컨텍스트 윈도우가 커지고 모델이 싸질수록, 매번 검색하는 것보다 한 번 정리해두고 유지하는 쪽이 더 합리적인 순간이 올 거예요. 그때는 '지식 베이스'라는 말의 뜻 자체가 '문서 저장소'에서 'AI가 관리하는 살아있는 위키'로 바뀔지도 몰라요.

물론 숙제도 남아 있어요. 위키가 커질수록 모순되는 내용을 어떻게 정리할지, 여러 사람이 함께 쓰는 팀 위키에서는 누가 AI의 수정을 검수할지 같은 문제는 아직 열려 있어요.

여러분은 어떠세요? 지금 팀에서 RAG를 쓰고 있다면 어떤 질문에서 한계를 느꼈나요? 그리고 AI가 정리해준 위키를 얼마나 믿을 수 있을 것 같으세요? 댓글로 경험을 나눠주세요.