LLM Wiki와 RAG를 함께 쓰기

둘은 경쟁자가 아니다

LLM Wiki를 처음 접하면 RAG를 버려야 하는 것처럼 느껴질 수 있다. 하지만 실무에서는 그렇게 접근하면 곧 막힌다. LLM Wiki와 RAG는 같은 문제를 다른 시점에서 푼다.

RAG는 질문이 들어온 뒤 관련 문서를 찾는다. 문서를 잘게 나누고, 임베딩을 만들고, 벡터 DB나 검색 엔진에서 관련 조각을 가져온 다음, 그 조각을 LLM에게 넣어 답을 만든다. RAG는 LLM이 학습 시점 이후의 정보나 내부 문서에 접근하도록 돕는 대표적인 방법이다¹.

LLM Wiki는 반대로 질문이 들어오기 전에 지식을 정리한다. 원문을 raw/에 보관하고, LLM이 그것을 읽어 wiki/에 개념 페이지, 비교 페이지, 결정 기록, 요약 페이지를 만든다. CLAUDE.md나 AGENTS.md 같은 schema는 LLM에게 어떤 규칙으로 이 위키를 관리할지 알려준다. 이 차이는 흔히 쿼리 시점 조립과 인제스트 시점 컴파일의 차이로 설명된다².

즉 RAG는 찾는 기술이고, LLM Wiki는 쌓는 기술이다. 찾는 기술 없이 큰 지식베이스를 운영하기 어렵고, 쌓는 기술 없이 검색만 하면 매번 같은 해석을 반복하게 된다. 좋은 구조는 둘 중 하나를 고르는 것이 아니라 역할을 나누는 것이다.

작은 규모에서는 Markdown Wiki가 먼저다

개인 연구, 책 집필, 작은 팀의 제품 문서처럼 범위가 제한된 지식에는 Markdown Wiki가 강하다. 이유는 단순하다. 사람이 직접 읽고 고칠 수 있기 때문이다.

벡터 DB 안의 임베딩은 사람이 눈으로 검토하기 어렵다. 검색 결과가 왜 나왔는지 추적하려면 별도의 도구와 로그가 필요하다. 반면 Markdown 파일은 열어보면 바로 보인다. 어떤 문장이 추가됐는지, 어떤 링크가 생겼는지, 어떤 출처가 붙었는지 확인할 수 있다. Git을 쓰면 변경 이력도 남는다.

또 하나의 장점은 반복 해석을 줄인다는 점이다. 예를 들어 AI 에이전트에 관한 글 50개를 모았다고 하자. RAG만 쓰면 질문할 때마다 관련 청크를 찾고, 그때마다 에이전트 정의, 도구 사용, 메모리, 워크플로 차이를 다시 조립해야 한다. LLM Wiki는 처음 ingest할 때 다음과 같은 페이지를 미리 만들어둔다.

• concepts/ai-agent.md

• concepts/agent-memory.md

• comparisons/rag-vs-llm-wiki.md

• decisions/why-we-use-markdown-wiki.md

• timeline/ai-agent-tools-2024-2026.md

이후 질문은 원문 조각이 아니라 이미 정리된 지식층 위에서 시작한다. 이 방식은 특히 비교, 전략, 글쓰기, 의사결정 질문에 강하다. LLM Wiki가 단순 요약 묶음이 아니라 재사용 가능한 지식 표현층이라는 점이 중요하다³.

커지면 RAG 검색층이 필요하다

Markdown Wiki가 좋다고 해서 모든 것을 파일 탐색과 index.md로 해결할 수는 없다. 다음 신호가 보이면 RAG 검색 인프라를 붙일 때다.

• 원문 문서가 수백 개를 넘어선다.

• 긴 PDF, 회의록, 이슈, 슬랙 로그처럼 형식이 다양하다.

• 문서가 자주 갱신된다.

• 여러 사람이 동시에 질문한다.

• 답변마다 정확한 원문 위치를 추적해야 한다.

• 권한, 보안, 접근 제어가 필요하다.

이때 필요한 것은 위키를 버리는 것이 아니다. 원문 검색층을 강화하는 것이다.

RAG 검색에는 여러 방식이 있다. BM25는 키워드 기반 검색이다. 특정 제품명, 고객명, 오류 코드, 법 조항처럼 정확한 단어가 중요한 경우에 강하다. 벡터 검색은 의미 기반 검색이다. 사용자가 같은 뜻을 다른 표현으로 물어봐도 관련 문서를 찾는 데 유리하다. 하이브리드 검색은 이 둘을 합친다. 키워드 검색과 벡터 검색의 결과를 함께 가져오고, 재순위화해서 더 좋은 후보를 고른다⁴.

실무에서는 여기에 메타데이터 필터를 붙인다. 예를 들어 문서마다 다음 정보를 넣어둔다.

system: billing
module: refund
doc_type: meeting-note
version: v2
updated: 2026-05-19
access: internal

사용자가 환불 정책을 묻는다면 먼저 system=billing, module=refund로 범위를 좁힌다. 그다음 BM25와 벡터 검색을 돌린다. 마지막으로 reranker, 즉 재순위화 모델이 질문과 문서를 더 정밀하게 비교해 상위 근거를 고른다. 이렇게 하면 비슷한 단어가 들어 있다는 이유로 엉뚱한 프로젝트 문서가 끼어드는 일을 줄일 수 있다.

실무 아키텍처: 원문 검색층은 RAG, 지식 편집층은 Wiki

가장 현실적인 구조는 다음과 같다.

raw sources
  ├─ articles/
  ├─ papers/
  ├─ meetings/
  ├─ tickets/
  └─ transcripts/
       │
       ├─ 검색 인프라
       │   ├─ BM25 index
       │   ├─ vector index
       │   ├─ metadata filter
       │   └─ reranker
       │
       └─ LLM Wiki
           ├─ concepts/
           ├─ comparisons/
           ├─ decisions/
           ├─ timelines/
           ├─ source-summaries/
           ├─ index.md
           └─ log.md

이 구조에서 RAG는 원문 근거를 찾는다. LLM Wiki는 그 근거를 바탕으로 오래 쓸 수 있는 지식 페이지를 유지한다.

질문이 들어오면 먼저 질문 유형을 나눈다.

예를 들어 사용자가 이렇게 묻는다고 하자.

우리 팀이 RAG만 쓰지 않고 LLM Wiki도 운영해야 하는 이유를 제품팀 관점에서 설명해줘.

이 질문은 개념과 전략을 묻는다. 먼저 Wiki에서 rag.md, llm-wiki.md, product-knowledge-management.md, decision-records.md를 읽는다. 만약 최신 고객 인터뷰나 회의록 근거가 필요하면 RAG 검색층에서 관련 원문을 가져온다. 답변 후에는 좋은 설명을 syntheses/why-product-team-needs-llm-wiki.md로 저장한다. 이렇게 질문이 다시 지식이 된다.

두 방식의 약점을 서로 보완한다

RAG의 약점은 검색 시점마다 맥락을 다시 조립한다는 점이다. 청크가 너무 작으면 앞뒤 논리가 잘린다. 청크가 너무 크면 검색 정확도가 떨어지고 비용이 커진다. 같은 질문을 여러 번 해도 매번 비슷한 추론을 다시 해야 한다. 답변은 생기지만 지식베이스 자체가 똑똑해지지는 않는다.

LLM Wiki의 약점은 반대다. 잘못 요약된 내용이 위키에 남을 수 있다. 한 번 틀린 연결이 만들어지면 다음 답변도 그 연결을 전제로 삼을 위험이 있다. RAG의 오류가 일회성이라면, Wiki의 오류는 누적될 수 있다.

그래서 운영 규칙이 필요하다.

첫째, 원문은 수정하지 않는다. raw/는 증거이고, wiki/는 해석이다. 해석이 틀리면 원문으로 돌아갈 수 있어야 한다.

둘째, Wiki의 중요한 주장에는 출처를 붙인다. 출처가 없으면 확정된 사실처럼 쓰지 않는다.

셋째, 확실성 상태를 남긴다. confidence: high | medium | low, review_status: draft | reviewed | disputed, updated: YYYY-MM-DD 같은 필드를 두면 LLM과 사람이 모두 판단하기 쉽다.

넷째, 모순은 덮어쓰지 않는다. 새 문서가 예전 결정을 뒤집는다면 예전 내용을 삭제하지 말고 superseded_by 또는 contradicts로 연결한다.

다섯째, 중요한 답변은 원문 근거와 위키 해석을 분리해서 작성한다.

원문 근거: 회의록, 논문, 고객 인터뷰에서 확인된 내용
위키 해석: 여러 근거를 바탕으로 정리한 현재 판단
검토 필요: 근거가 부족하거나 서로 충돌하는 부분

이렇게 하면 RAG는 검증 가능성을 제공하고, Wiki는 축적 가능성을 제공한다.

Graph RAG와 온톨로지는 나중에 붙여도 된다

어떤 조직은 처음부터 지식 그래프, 온톨로지, Graph RAG를 만들고 싶어 한다. 물론 개체와 관계가 명확한 영역에서는 강력하다. 예를 들어 고객, 계약, 제품, 기능, 장애, 담당자, 의사결정이 서로 연결된 조직 지식에서는 그래프가 좋은 답을 줄 수 있다. Redis를 업그레이드하면 어떤 서비스가 영향을 받는지, 특정 고객 불만이 어떤 기능 결정과 연결되는지 같은 질문은 그래프 탐색에 잘 맞는다.

하지만 그래프는 공짜가 아니다. 개체 타입을 정해야 하고, 관계 이름을 표준화해야 하며, 중복 엔티티를 병합해야 한다. 처음부터 온톨로지를 과하게 설계하면 실제 지식보다 스키마 관리가 더 커진다.

현실적인 순서는 반대다. 먼저 Markdown LLM Wiki로 시작한다. 반복적으로 등장하는 개념, 관계, 질문을 관찰한다. 그다음 자주 쓰이는 관계만 그래프로 승격한다. LLM Wiki v2 논의에서도 규모가 커질수록 BM25, 벡터 검색, 그래프 탐색을 함께 쓰는 하이브리드 구조가 필요하다고 본다⁵.

처음에는 [[고객 인터뷰]], [[환불 정책]], [[가격 실험]] 같은 링크면 충분하다. 나중에 정말 필요해지면 customer_reported_issue, feature_depends_on, decision_supersedes 같은 타입이 있는 관계로 바꾸면 된다.

단계별 확장 전략

LLM Wiki와 RAG를 함께 쓰는 가장 좋은 방법은 한 번에 완성하려 하지 않는 것이다.

1단계: Markdown Wiki만 만든다.
raw/, wiki/, index.md, log.md, schema만 둔다. 자료 20~50개를 ingest하면서 페이지 규칙을 안정화한다.

2단계: 로컬 검색을 붙인다.
문서가 늘어나면 Markdown 전체 검색, BM25, 간단한 벡터 검색을 붙인다. 아직 대규모 인프라는 필요 없다.

3단계: 원문 RAG를 분리한다.
긴 PDF, 회의록, 이슈, 고객 인터뷰처럼 원문 추적이 중요한 자료를 별도 검색 인덱스로 만든다. Wiki는 요약과 해석을 맡고, RAG는 증거 검색을 맡는다.

4단계: 하이브리드 검색과 리뷰 프로세스를 운영한다.
BM25, 벡터 검색, 메타데이터 필터, reranker를 결합한다. 팀 환경에서는 답변이 바로 위키에 쓰이지 않게 하고, PR이나 리뷰 단계를 둔다.

5단계: 필요한 관계만 그래프로 승격한다.
모든 링크를 그래프로 만들지 않는다. 자주 묻는 영향도 분석, 의존성 분석, 고객-기능-결정 연결처럼 효과가 큰 부분부터 시작한다.

핵심은 단순하다. 작은 지식베이스에서는 Markdown Wiki가 빠르고 투명하다. 큰 지식베이스에서는 RAG 검색층이 필요하다. 그리고 실무에서 가장 강한 구조는 둘을 섞은 구조다.

LLM Wiki는 벡터 DB를 대체하는 제품이 아니다. RAG도 지식 운영을 자동으로 해결하는 만능 장치가 아니다. RAG는 원문을 찾아오고, Wiki는 그 원문을 지식으로 바꾼다. 이 둘이 연결될 때 AI는 단순히 답하는 도구가 아니라, 시간이 지날수록 더 잘 아는 작업공간이 된다.

참고

¹Retrieval-augmented generation

²LLM Wiki vs RAG Knowledge Base: The Karpathy Approach Explained

³LLM Wiki - Compiled Knowledge That RAG Cannot Replace

⁴RAG with Hybrid Search: How Does Keyword Search Work?

⁵LLM Wiki v2 — extending Karpathy's LLM Wiki pattern with lessons from building agentmemory