Tec-Blog Technology & DevOps

AI

LLM Wiki vs RAG — 지식은 언제 합성할까

TL;DR

  • RAG는 질문 순간에 문서를 찾아 붙인다. 코퍼스가 크고 자주 바뀌면 유리하다.
  • LLM Wiki는 문서를 넣을 때 LLM이 마크다운 위키로 미리 컴파일한다. 작은~중간 바운디드 지식에서 교차참조·모순 감지가 강하다.
  • 핵심 차이는 “검색 알고리즘”이 아니라 합성 시점(synthesis time) 이다. RAG = query-time, Wiki = ingest-time.
  • 현실에서는 코어 지식은 Wiki, 대량·휘발성 문서는 RAG로 두는 하이브리드가 자주 맞다.
  • 스케일이 커지면 Wiki에도 검색이 붙고, 그때는 사실상 RAG 문제가 다시 열린다.

들어가며

LLM에게 “우리 제품/도메인 지식을 제대로 쓰게” 만드는 방법은 크게 둘로 갈린다.

하나는 익숙한 RAG(Retrieval-Augmented Generation) 다. 질문을 임베딩하거나 키워드로 검색해서, 관련 청크를 프롬프트에 넣고 답을 생성한다.
다른 하나는 Andrej Karpathy가 정리한 LLM Wiki 패턴이다. 원문을 쌓아두고, LLM이 그걸 위키 페이지로 계속 컴파일한다. 질문할 때는 이미 정리된 위키를 읽는다.

둘 다 “외부 지식을 LLM에 넣는” 목적이지만, 언제·어떻게 지식을 합성하느냐가 완전히 다르다. 이 글에서는 기능, 구조, 장단, 선택 기준을 길게 정리한다. (특정 제품·회사 스택 이름은 빼고 일반화한다.)

1. RAG가 하는 일

1-1. 한 줄 정의

RAG = 검색 + 생성.
모델 가중치를 바꾸지 않고, 질문마다 외부 저장소에서 근거를 가져와 프롬프트에 붙인다.

1-2. 전형적인 파이프라인

  1. 인제스트: PDF/HTML/티켓/스펙을 청크로 자른다.
  2. 인덱싱: 키워드(BM25 등) 및/또는 벡터 임베딩으로 인덱스에 넣는다.
  3. 질의: 사용자 질문 → 검색 → Top-k 청크.
  4. 합성: 청크 + 질문을 LLM에 넣고 답 생성.
  5. (선택) 재랭크, 인용(citation), 가드레일.

하이브리드 검색(키워드 + 벡터)을 쓰면 “정확한 코드/고유명”과 “비슷한 의미”를 같이 잡을 수 있다. 이전 글에서 Colab·로컬로 LLM을 붙일 때도, 검색 쪽은 이런 RAG 레이어가 따로 있다.

1-3. RAG가 잘하는 것

  • 규모: 수만~수백만 문서까지 인덱스로 확장하기 쉽다.
  • 신선도: 새 문서만 인덱싱하면 된다. 전체를 다시 “이해”시킬 필요가 없다.
  • 운영 분리: 검색 품질과 생성 품질을 나눠 튜닝할 수 있다.
  • 감사: “어떤 청크를 봤는지”를 로그로 남기기 쉽다.

1-4. RAG가 자주 깨지는 지점

  • 청크 경계: 중요한 문장이 잘리면 검색이 빗나간다.
  • 검색 실패 = 생성 실패: Top-k에 없으면 모델은 그럴듯하게 환각한다.
  • 쿼리마다 합성: 같은 주제라도 질문 표현이 다르면 다른 청크가 붙고, 답의 일관성이 흔들린다.
  • 교차 문서 추론: “A 문서와 B 문서의 모순”을 한 번에 보려면, 애초에 둘 다 검색되어야 한다. 검색이 그걸 보장하지 않는다.
  • 컨텍스트 예산: Top-k를 키우면 노이즈와 토큰 비용이 같이 커진다.

RAG는 “도서관에서 책을 찾아 책상 위에 펼쳐놓고 읽기”에 가깝다. 책이 많고 자주 바뀌면 이 방식이 맞다. 대신 매번 책을 다시 찾아 펼친다.

2. LLM Wiki가 하는 일

2-1. 한 줄 정의

LLM Wiki = ingest-time에 LLM이 지식을 위키로 컴파일하는 패턴.
원본(raw/)은 그대로 두고, 엔티티·개념 페이지와 index.md 같은 목차를 LLM이 갱신한다. 질문할 때는 위키를 탐색·요약한다.

Karpathy가 요약한 취지는 대략 이렇다. RAG만 반복하면 매 쿼리마다 “처음부터 검색·요약”이고, 지식 사이의 연결이 세션 밖으로 잘 안 남는다. 위키처럼 누적되는 중간 산출물이 있으면, 에이전트(또는 사람)가 그 위에 질문을 쌓을 수 있다.

2-2. 디렉터리 감각 (개념)

구현체는 제각각이지만, 패턴은 비슷하다.

  • raw/: 원문. 불변에 가깝게 보관.
  • 엔티티/개념 페이지: 사람, 제품, 용어, 결정 사항 등. 마크다운 + 교차 링크.
  • index.md / 목차: “지금 위키에 뭐가 있는지”의 진입점.
  • SCHEMA.md: 페이지 이름 규칙, 프론트매터, 링크 규칙.
  • log.md: 인제스트·질문 이력. 재현과 디버깅용.

인제스트 한 번이 “파일을 인덱스에 넣는 것”이 아니라 위키 편집 작업이다. LLM이 관련 페이지를 읽고, 모순을 표시하고, 링크를 건다.

2-3. Wiki가 잘하는 것

  • 누적 합성: 같은 주제의 문서가 들어올수록 페이지가 두꺼워지고, 교차참조가 는다.
  • 모순·공백 드러내기: “A는 X라 했고 B는 Y라 함”을 페이지에 적어둘 수 있다. RAG는 그 두 청크가 같은 Top-k에 들어와야 겨우 보인다.
  • 탐색 UX: 사람이 위키를 읽듯, 에이전트도 index → 페이지 → 링크로 다닐 수 있다.
  • 바운디드 지식: 팀 위키, 제품 스펙, 미팅/결정 로그, 논문 한 묶음처럼 경계가 있는 코퍼스에 잘 맞는다.

2-4. Wiki가 자주 깨지는 지점

  • 인제스트 비용: 문서마다 LLM 호출이 나간다. RAG 인덱싱(임베딩)보다 비싸고 느릴 수 있다.
  • 스케일: 페이지가 수천 개를 넘기면, “위키를 어떻게 찾지?”가 다시 검색 문제가 된다. 결국 Wiki 위에 검색(사실상 RAG)을 얹게 된다.
  • 스키마 드리프트: 규칙(SCHEMA)을 안 지키면 링크와 이름이 난장판이 된다.
  • 환각의 형태가 바뀜: RAG는 “없는 청크를 지어냄”, Wiki는 “틀린 내용을 페이지에 써버림”. 잘못된 컴파일은 영구 오염에 가깝다. 검수·로그·원문 추적이 필수다.
  • 실시간성: 초 단위로 바뀌는 로그/메트릭에는 부적합하다.

Wiki는 “사서가 새 책을 받을 때마다 백과사전 항목을 고쳐 쓰는” 쪽에 가깝다. 항목이 쌓이면 읽기 편하지만, 사서(LLM) 인건비가 든다.

3. 기능 비교 — 같은 질문, 다른 경로

가령 질문이 “우리 인증 모듈의 세션 만료 정책이 뭐지?”라고 하자.

RAG 경로

  1. 질문을 검색 쿼리로 바꾼다.
  2. 스펙·ADR·티켓 청크 Top-k를 가져온다.
  3. LLM이 그 자리에서 요약·답변한다.
  4. 다음 질문에서는 1부터 다시(캐시하지 않는 한).

Wiki 경로

  1. 과거에 인증 관련 raw가 들어올 때 Auth / Session 페이지가 이미 갱신되어 있다.
  2. 질문 시 index에서 Auth를 찾아 페이지를 읽는다.
  3. 페이지에 적힌 요약·링크·미해결 이슈를 바탕으로 답한다.
  4. “만료가 30분인지 1시간인지 문서가 엇갈림”이 이미 페이지에 적혀 있으면, 검색 운에 덜 의존한다.

즉 답이 좋아지는 메커니즘이 다르다.
RAG는 검색 재현율/정밀도가 성능을 지배하고, Wiki는 인제스트 품질과 스키마가 성능을 지배한다.

4. 차이 한눈에 (표 대신 문장으로)

  • 합성 시점: RAG는 질문할 때, Wiki는 넣을 때.
  • 저장 형태: RAG는 청크+벡터/키워드 인덱스, Wiki는 사람이 읽는 마크다운 그래프.
  • 일관성: RAG는 쿼리마다 흔들릴 수 있음. Wiki는 페이지가 단일 진실에 가까워지도록 유도(단, 컴파일이 틀리면 고착).
  • 확장: RAG는 수평 확장에 익숙. Wiki는 지식 밀도↑에 강하고 문서 수↑에는 추가 검색이 필요.
  • 비용 곡선: RAG는 질의당 검색+생성. Wiki는 인제스트당 생성 비용이 크고 질의는 상대적으로 싸다(페이지 읽기).
  • 감사: RAG는 retrieved chunk ID. Wiki는 page diff + raw 출처 링크가 자연스럽다.
  • 업데이트: RAG는 재인덱싱. Wiki는 재컴파일(관련 페이지만 또는 전량).

“어느 쪽이 더 똑똑한가”가 아니라 어느 시점에 똑똑해지기를 원하는가의 문제에 가깝다.

5. 선택 기준 — 실무에서 어떻게 고르나

5-1. RAG를 기본으로 둘 때

  • 문서량이 크고, 매일/매시간 늘어난다.
  • 질의 패턴이 다양하고, “한 번에 다 읽어둘” 경계가 없다.
  • 법무·규정처럼 원문 인용이 필수라 청크 단위 근거가 필요하다.
  • 팀이 이미 검색 인프라(ES, 벡터DB)를 운영 중이다.

5-2. Wiki를 기본으로 둘 때

  • 지식 범위가 제품 하나, 팀 하나, 프로젝트 하나처럼 경계가 있다.
  • 결정 이력, 용어 정의, 아키텍처처럼 연결이 중요하다.
  • 같은 질문을 반복해서 하고, 답을 “문서화해 두고” 싶다.
  • 에이전트가 장기간 같은 워크스페이스에서 지식을 키운다.

5-3. 하이브리드가 자주 맞는 이유

실무 코퍼스는 한 덩어리가 아니다.

  • 코어(용어, ADR, 온보딩, 반복 Q&A) → Wiki로 컴파일해 두면 질의 품질이 안정된다.
  • 롱테일(티켓 10만 건, 로그, 외부 논문 전체) → RAG로 두고, 필요할 때만 끌어온다.
  • Wiki 페이지에 “관련 raw / 검색 키워드”를 적어 두면, 에이전트가 Wiki에서 출발해 RAG로 확장할 수 있다.

반대로, Wiki가 커지면 index.md만으로는 못 찾는다. 그때 Wiki 본문에 검색을 얹는 순간, 아키텍처 박스 이름은 Wiki여도 내부는 RAG다. 부끄러워할 일이 아니라 자연스러운 진화다.

6. 설계 시 같이 볼 디테일

6-1. 청크 vs 페이지

RAG의 단위는 청크(토큰·문단). Wiki의 단위는 토픽 페이지.
청크는 검색 친화적, 페이지는 인간/에이전트 탐색 친화적이다.
억지로 하나를 고르기보다, 인제스트 파이프라인에서 raw → (청크 인덱스) → (위키 페이지) 를 단계로 두어도 된다.

6-2. 임베딩만으로 부족한 순간

동의어, 약어, 코드 체계(예: 진단 코드)처럼 표기가 조금만 달라도 벡터 검색이 흔들린다.
그래서 RAG 쪽은 키워드·동의어 사전·리랭크를 붙이고, Wiki 쪽은 페이지에 “이 용어 = 저 용어”를 명시한다. 문제는 같고 해법의 저장 위치가 다르다.

6-3. 평가

  • RAG: retrieval recall@k, citation 정확도, 답변 충실도.
  • Wiki: 페이지 커버리지, 깨진 링크 수, 모순 플래그 해소율, 반복 질문의 답 안정성.

둘 다 “LLM 점수가 올랐다”만으로는 부족하다. 실패가 검색인지 컴파일인지를 나눠야 다음 투자가 맞다.

6-4. 보안·권한

RAG는 인덱스/필터 레벨 ACL을 걸기 쉽다.
Wiki는 페이지 단위 권한이 직관적이지만, 컴파일 과정에 민감 raw가 섞이면 요약에 유출될 수 있다. ingest 프롬프트와 저장 경로를 권한 경계에 맞춰야 한다.

7. 자주 나오는 오해

“Wiki가 RAG를 대체한다”
→ 스케일과 실시간성에서는 대체가 아니라 보완이다. 대체처럼 보이는 구간은 작은 코퍼스뿐이다.

“RAG에 요약 인덱스만 넣으면 Wiki다”
→ 정적 요약 덤프와, 교차링크·스키마·로그를 유지하는 컴파일 루프는 다르다. 후자가 Wiki 패턴의 핵심이다.

“파인튜닝하면 RAG/Wiki 둘 다 필요 없다”
→ 파인튜닝은 형식·말투·좁은 스킬에 강하고, 최신 문서·감사 가능한 근거에는 약하다. 지식 동선과 학습은 겹치되 같은 층이 아니다. (Few-shot vs SFT 글과 맞닿는 지점이다.)

“에이전트면 알아서 Wiki를 만든다”
→ 스키마·검수·원문 추적 없이 돌리면, 틀린 위키가 빠르게 권위를 얻는다. 자동화할수록 가드레일이 더 필요하다.

8. 실무에 옮길 때 짧은 로드맵

  1. 지식 지도 그리기: 바운디드 코어 vs 롱테일 문서를 나눈다.
  2. 롱테일부터 RAG: 검색·인용·평가 루프를 먼저 돌린다.
  3. 코어만 Wiki 파일럿: 용어집 + ADR + 온보딩 Q&A처럼 반복 질의 구간만 컴파일한다.
  4. 연결: Wiki 페이지에 “추가 근거는 검색” 링크/쿼리 힌트를 남긴다.
  5. 스케일 관찰: Wiki 페이지 수·깨진 링크·인제스트 비용이 임계를 넘으면 Wiki에 검색을 얹는다.

이 순서를 지키면 “전부 Wiki”, “전부 RAG” 이분법에서 벗어나기 쉽다.

마무리

RAG와 LLM Wiki는 라이벌이라기보다 합성 시점이 다른 두 지식 엔진이다.

  • 질문이 올 때마다 도서관에서 책을 찾게 할 것인가 (RAG).
  • 책이 들어올 때마다 백과사전을 고쳐 쓰게 할 것인가 (Wiki).

코퍼스가 크고 빠르면 RAG, 경계가 있고 연결이 중요하면 Wiki, 대부분은 둘의 하이브리드다.
다음 설계 회의에서 “검색 모델을 바꿀까?”만 묻지 말고, “이 지식은 넣을 때 합성할 가치인가, 물을 때 합성할 가치인가?”를 먼저 물어보면 선택지가 선명해진다.

관련해서 에이전트 쪽 작업 분해는 Kanban으로 멀티에이전트 업무 분해를, 프롬프트만으로 갈지 학습으로 갈지는 Few-shot vs SFT를 보면 이어서 읽기 좋다.