RAG는 아직 필요할까? LLM Wiki와 역할이 갈리는 진짜 기준 3가지 — 샘 호트만
한 줄 요약
RAG(질문 시점 검색)와 LLM 위키(미리 만든 정리 레이어)는 경쟁 기술이 아니라 같이 쓰는 짝이며, 선택 기준은 정확도가 아니라 질문 유형·자료 변경 빈도·반복 횟수 3가지 + “무엇을 안 넣을 것인가”라는 승격 규율이다.
영상 메타
- URL: https://youtu.be/GrEFRTmbMfI
- 채널: 샘 호트만 : AI 엔지니어의 시선
- 길이: 미상
- 업로드: 2026-08-08
- 조회수: 288 / 좋아요 23
- 시청일: 2026-08-08 KST (🦉 가 자막 추출 후 요약)
픽업
- RAG는 오픈북 시험(질문 때마다 도서관에서 책을 찾아온다), LLM 위키는 시험 전에 만든 요약 노트다. 노트는 책을 대체하지 않는다 — 핵심은 벡터 DB를 뺐다는 게 아니라 원본과 정리본을 분리했다는 것.
- 둘의 차이는 비용을 내는 시점(질문 순간 vs 적재 순간)보다 더 중요한 게 있다: 검색은 원본에 있는 것만 찾지만, 정리본은 만드는 순간 원본 어디에도 없던 문장(새 레이어)이 생긴다. 그리고 정리본은 인덱스가 있어 “없다는 사실”도 안다.
- 판단 기준 3가지 — ①원문을 그대로 보여 달라는 질문이 많으면 검색, 여러 자료 종합 설명이 많으면 정리본 ②안 바뀌는 자료는 한 번 정리하면 오래 가고, 빨리 바뀌는 자료일수록 최신 원문 검색이 중요 ③같은 질문이 반복될수록 정리본의 값이 올라간다.
- “승격”이 핵심 규율 — 모든 원문을 정리본으로 바꾸는 게 아니라, 반복해서 쓸 가치가 있고 사람이 한 번 확인한 것만 올린다. 기준 없이 다 밀어 넣었다가 지표 바닥이던 대본의 훅이 “어엿한 지식”으로 올라와 근거로 되돌아온 실제 사고를 겪었다 — 원본이 사실이라고 지식이 되는 건 아니다.
- 시작 순서는 3단계 — 구조 그리기 전에 실제로 물어볼 질문 5~10개부터 적고, 자료를 한 폴더에 모아 AI가 직접 뒤지게 하고, 같은 종합을 반복하게 될 때만 위키를 붙인다. 스키마.md는 원본 딱 하나로 규칙을 검증한 뒤 확대한다 — 규칙이 틀린 채 전체를 밀면 같은 오류가 전 자료에 복사된다.
- RAG를 붙이는 시점: Anthropic 문서 기준 자료가 20만 토큰(약 500쪽)보다 작으면 통째로 넣으면 되고 RAG는 불필요. 그 위로는 숫자가 아니라 실패 증상(검색 누락·표현 불일치로 못 찾음·목차 비대·다인 동시 사용)이 시점을 정한다. 크로마의 18개 모델 실측 — 입력이 길수록 단순 문제도 정확도가 떨어지고 무관 문서 1개만 섞여도 성능이 내려간다.
- 위키가 망가지는 신호 2가지: 답은 그럴듯한데 출처가 하나뿐일 때 / 원본을 고쳤는데 정리본이 옛 문장을 말할 때. 좋은 지식 베이스는 많이 쌓인 게 아니라 안 좋은 게 안 들어간 것 — 찾아오는 능력만큼 거절하는 능력을 봐야 한다.
용어
- RAG (검색 증강 생성) [하니스 · 패턴]: 질문이 들어오면 관련 자료를 검색해 모델 입력에 붙여 주는 표준 패턴 — 검색 방법이 벡터 검색 하나로 정해진 것은 아니다.
- LLM 위키 [지식 · 컨텍스트 자산]: 원본은 그대로 두고 자주 쓰는 설명만 미리 편집해 둔 파생 레이어. 카파시의 개인 지식 베이스 아이디어 기반으로 이 영상이 붙인 이름(업계 표준 용어 아님).
- 승격 [워크플로우 · 문화]: 원문을 정리본으로(회사에선 개인 지식을 팀 지식으로) 올릴지 사람이 검토·승인하는 관문. 이 한 단계를 빼면 지식 베이스는 곧바로 쓰레기장이 된다.
- 스키마.md [지식 · 컨텍스트 자산]: AI의 기억 자체가 아니라 그 기억을 어떻게 관리할지 적어두는 규칙 문서 — 스킬.md가 에이전트의 업무 매뉴얼이라면 이건 데이터 설계도.
- 벡터 데이터베이스 · 임베딩 [도구 통신 (MCP · CLI · API)]: 문장을 수치 벡터로 바꿔 유사도로 찾게 하는 검색 인프라 — RAG의 여러 구현 수단 중 하나일 뿐.
- 컨텍스트 윈도우 [컨텍스트 · 캐시]: 모델이 한 번에 읽을 수 있는 입력 한도. 100만 토큰까지 커져도 실제로 정확히 쓸 수 있는 양이 그만큼 늘어난 건 아니다.