샘 호트만의 영상 **「RAG는 아직 필요할까? LLM Wiki와 역할이 갈리는 진짜 기준 3가지」**에서는 RAG와 LLM Wiki를 경쟁 기술로 보지 않고, **무엇을 질문 시점에 검색할지와 무엇을 미리 정리해 둘지**의 차이로 설명합니다. ## 가장 쉬운 비유 - **RAG** → 오픈북 시험에서 질문이 나올 때마다 도서관에서 필요한 책을 찾아오는 방식 - **LLM Wiki** → 시험 전에 여러 책을 읽고 요약 노트를 만들어 두는 방식 중요한 점은 **요약 노트가 원본 책을 대체하지 않는다는 것**입니다. 위키에 없는 내용은 다시 원본을 찾아야 하고, 정리본이 맞는지도 원문으로 검증해야 합니다. ## 핵심 차이 1 — 비용을 언제 내는가 RAG는 질문이 들어온 순간 검색·조합 비용을 냅니다. LLM Wiki는 자료가 들어오는 순간 읽고 정리하는 비용을 먼저 냅니다. 즉, **Query-time retrieval vs Ingest-time compilation** 의 차이입니다. ## 핵심 차이 2 — 원본에 없던 지식 레이어가 생긴다 RAG는 원본에 있는 내용을 찾아옵니다. 반면 LLM Wiki는 여러 자료를 하나의 개념 페이지로 합치면서 **원본 어느 한 곳에도 없던 종합 설명이나 인사이트**를 만들 수 있습니다. 이 점이 LLM Wiki의 가장 큰 장점이자 동시에 가장 큰 위험입니다. 좋은 자료를 잘 정리하면 새로운 인사이트가 생기지만, 낮은 품질의 자료를 올리면 **원본 어디에도 없던 잘못된 지식**이 생길 수 있습니다. ## 핵심 차이 3 — “없다”는 사실을 더 잘 알 수 있다 검색 시스템은 못 찾은 것인지, 애초에 없는 것인지 구분하기 어려울 수 있습니다. 정리된 Wiki는 Index를 통해 어떤 개념이 있고 없는지 구조적으로 확인하기 쉽습니다. ## 내 자료는 어느 쪽이 맞을까? 영상에서는 세 가지 질문을 기준으로 제시합니다. ### 1. 어떤 질문을 자주 하는가? 원문 그대로 보여 달라는 질문이 많으면 검색이 유리합니다. 예: - 규정 원문 보여줘 - 회의록에서 정확한 문장 찾아줘 - 계약서 조항 보여줘 반대로 여러 자료를 종합한 설명을 반복해서 요청한다면 Wiki가 유리합니다. ### 2. 자료는 얼마나 자주 바뀌는가? - 거의 안 바뀌는 자료 → 미리 정리해 둘 가치가 큼 - 주기적으로 갱신되는 자료 → 자동 Ingest 필요 - 빠르게 바뀌는 자료 → 최신 원문 검색 비중을 높이는 편이 안전 ### 3. 같은 질문을 몇 번이나 반복하는가? 한 번만 물어볼 질문까지 모두 Wiki로 만들면 관리 비용만 늘어납니다. 반복되는 설명일수록 미리 검토된 Wiki 페이지의 가치가 커집니다. ## 중요한 개념 — 승격 모든 원본 자료가 자동으로 Wiki 지식이 되어서는 안 됩니다. 영상에서는 반복해서 사용할 가치가 있고, 사람이 한 번 검토한 것만 **정리본으로 승격**시키는 방식을 강조합니다. 예를 들어 실패한 마케팅 문구까지 기준 없이 Wiki에 넣으면 AI가 나중에 그것을 성공 사례처럼 재사용할 수 있습니다. 즉, **사실인 자료 ≠ 좋은 지식** 입니다. ## 개인 사용자의 현실적인 3단계 1. 먼저 실제 질문 5~10개를 적는다. 2. 자료를 한 폴더에 모으고 제목과 파일명을 정리한다. 3. 반복해서 여러 자료를 종합해야 할 때 Wiki를 붙인다. 처음부터 Vector DB와 복잡한 RAG 인프라를 붙이지 않아도, 자료 규모가 작다면 Claude Code나 Codex가 폴더를 직접 읽는 것만으로 충분할 수 있습니다. ## RAG는 언제 붙일까? 영상에서는 과거 Anthropic 자료를 인용해 **약 20만 토큰, 대략 500페이지 이하에서는 통째로 읽는 방식도 가능**하다고 소개합니다. 하지만 이 숫자를 절대적인 상한으로 보면 안 됩니다. 컨텍스트 윈도우가 커져도: - 관련 없는 문서가 섞이면 정확도가 떨어지고 - 매번 전체를 읽으면 비용이 커지고 - 자료가 많아질수록 필요한 후보를 좁히는 과정이 중요해집니다. 따라서 RAG를 붙이는 시점은 페이지 수보다 **실패 증상**으로 판단하는 것이 좋습니다. - 관련 자료를 자꾸 놓친다 - 표현이 달라서 검색에 실패한다 - Index 자체가 너무 커졌다 - 답변 속도가 느려진다 - 여러 사람이 동시에 쓴다 - 권한별 접근 제어가 필요하다 ## 회사에서는 기술보다 거버넌스가 먼저 기업에서는 개인용 지식 시스템보다 조건이 더 까다롭습니다. ### 공식 문서 정의 어떤 파일이 공식이고 최신인지 정해야 합니다. ### 권한 필터링 권한이 없는 문서는 AI가 **읽기 전에** 차단해야 합니다. 답변 단계에서 숨기는 것은 늦습니다. ### 검토와 수정 권한 분리 - 일반 직원 → 질문·자료 제출 - 관리자 → 정리본 검토·수정 - 운영 책임자 → 규칙 변경 처럼 역할을 나누는 것이 필요합니다. ## 개인 지식에서 팀 지식으로의 승격 회사에서는 승격 단계가 하나 더 필요합니다. 개인 초안이 바로 팀 지식이 되는 것이 아니라: **개인 초안 → AI 사전 검토 → 사람 승인 → 팀 지식** 과정을 거치는 편이 안전합니다. ## RAG와 Wiki는 결국 같이 쓴다 현실적인 구조는 다음에 가깝습니다. **최신 원문·대규모 자료 → RAG** **반복 설명·검토된 지식 → LLM Wiki** **권한·규칙 → Governance** **질문 라우팅 → Agent** 즉, RAG와 LLM Wiki 중 하나를 고르는 문제가 아니라 **어떤 지식을 어디에 맡길지 설계하는 문제**입니다. ## 핵심 정리 영상의 결론은 명확합니다. > **RAG와 Wiki 중 뭐가 좋은지 묻기 전에, 무엇을 올릴지부터 정해야 합니다.** 좋은 지식베이스는 많이 쌓인 시스템이 아니라 **잘못된 지식이 들어오지 않도록 통제되는 시스템**입니다.