AI VIDEO BRIEFING

RAG와 LLM 위키의 차이와 도입 기준, 개인과 회사가 각각 먼저 정해야 할 것들 정리

RAG는 질문이 올 때 자료를 찾아오고 LLM 위키는 미리 정리해 둔다. 두 방식의 진짜 차이는 무엇인지, 검색을 붙일 시점은 언제인지, 개인과 회사가 각각 무엇부터 정해야 하는지 지식베이스 설계 기준을 정리했다.

RAG와 LLM 위키는 경쟁 관계가 아니다: 무엇을 찾아오고 무엇을 미리 정리할지 가르는 기준 영상 대표 이미지

핵심 메시지

  • RAG는 질문이 들어온 순간 관련 자료를 찾아 모델에 붙여 주는 방식이고, LLM 위키는 미리 편집해 둔 정리본을 읽는 방식이라 서로 대체재가 아니다.
  • 정리본은 만들어지는 순간 원본 어디에도 없던 문장을 만들어 내며, 이것이 위키의 진짜 가치이자 동시에 가장 큰 위험이다.
  • 검색은 못 찾은 것인지 원래 없는 것인지 구분하지 못하지만, 정리본은 인덱스가 있어 '없다'는 사실까지 안다.
  • 개인은 질문 목록 작성 → 폴더 정리 → 위키 구성 순서로 시작하고, 파일 검색이 실제 질문에서 자료를 놓치기 시작할 때 검색 체계를 붙이면 된다.
  • 회사는 공식 문서 지정, 모델이 읽기 전 단계의 권한 차단, 검토·수정 권한 분리라는 세 가지 장치를 먼저 갖춰야 한다.

쉽게 이해하기

발표자는 앞선 영상에서 벡터 데이터베이스도 임베딩도 쓰지 않고 유튜브 자막을 모아 위키로 쌓는 시스템을 만들어 보였다. 그러자 댓글이 하나의 질문으로 채워졌다. 그럼 이제 RAG는 안 써도 되느냐는 것이다. 이번 영상은 그 질문에 답하는 이론편으로, 두 방식이 애초에 같은 자리를 놓고 겨루는 기술이 아니라는 데서 출발한다.

비유는 시험이다. RAG는 오픈북 시험에 가깝다. 질문을 받을 때마다 도서관에 가서 필요한 책을 찾아와 펼쳐 놓고 답을 쓴다. LLM 위키는 시험 전에 만들어 둔 요약 노트다. 여러 책에 흩어져 있던 내용을 한 장으로 미리 묶어 두고 시험장에서는 그 노트를 본다. 중요한 것은 노트가 책을 대체하지 않는다는 점이다. 노트를 만들려면 책을 읽어야 하고, 노트에 없는 내용이 나오면 다시 도서관으로 가야 한다.

그래서 진짜 차이는 비용을 언제 내느냐만이 아니다. 검색은 원본에 있는 것만 찾아오지만, 정리본은 만들어지는 순간 원본 어디에도 없던 문장을 만들어 낸다. 여러 자료에 흩어져 있던 이야기를 한 페이지로 묶으면 그 페이지의 결론은 어느 원본에도 없던 것이다. 같은 구조가 반대로도 작동한다. 나쁜 자료가 섞이면 원본 어디에도 없던 헛소리가 새 지식으로 만들어진다.

발표자는 자신이 겪은 사고를 예로 든다. 기준 없이 과거 자막과 글을 전부 밀어 넣었더니, 성과 지표가 바닥이라 스스로 걸러 냈던 문장까지 어엿한 지식으로 올라와 나중에 근거로 되돌아왔다. 내용이 틀린 것은 아니었지만 '따라 하면 안 되는 사례'라는 정보가 어디에도 없었던 것이다. 그래서 그는 승격이라는 단어를 쓴다. 모든 원문을 정리본으로 바꾸는 것이 아니라, 반복해서 쓸 가치가 있고 사람이 한 번 확인한 것만 올린다는 뜻이다.

판단 기준으로는 세 가지 질문이 제시된다. 원문을 그대로 보여 달라는 질문이 많은지 아니면 여러 자료를 종합해 설명해 달라는 질문이 많은지, 그 자료가 끝난 강의처럼 더 바뀌지 않는지 뉴스처럼 계속 올라오는지 회의록처럼 사람이 넣을 때 생기는지, 같은 질문을 몇 번이나 반복하는지다. 빠르게 바뀌는 자료일수록 최신 원문을 찾아오는 쪽이, 반복 설명되는 지식일수록 미리 정리해 두는 쪽이 유리하다.

검색 체계를 언제 붙일지에 대해 영상은 앤트로픽의 엔지니어링 문서를 인용한다. 자료가 20만 토큰, 대략 500쪽보다 작으면 그냥 통째로 넣어도 되고 RAG는 필요 없다는 것이다. 다만 이 숫자를 상한으로 읽으면 안 된다고 강조한다. 크로마가 모델 18개를 놓고 확인한 결과 입력이 길어질수록 아주 단순한 문제에서도 정확도가 떨어졌고, 관계없는 문서를 딱 하나만 섞어도 성능이 내려갔다. 페이지 수는 출발점일 뿐이고, 실제로 붙일 시점은 파일 검색이 관련 자료를 자꾸 놓치거나 여러 사람이 동시에 쓰기 시작하는 실패가 정해 준다는 것이다.

회사로 넘어가면 전제가 통째로 바뀐다. 개인은 무엇을 올릴지 정하고 검토하고 틀렸을 때 대가를 치르는 일을 혼자 하지만, 회사는 이를 나눠야 한다. 무엇이 공식 문서인지 못 박고 새 버전이 나오면 이전 버전으로 만든 정리본을 누가 고칠지 정해야 하며, 권한 없는 문서는 답변에서 빼는 것이 아니라 모델이 읽기 전에 걸러야 한다. 또 질문·제출과 검토·수정, 규칙 변경 권한을 계층으로 나눠야 지식이 흔들리지 않는다.

주요 인사이트

  • 위키를 붙인다는 것은 도구를 하나 더 얻는 일이 아니라, 무엇을 검색에 맡기고 무엇을 정리본으로 올릴지 정하는 책임까지 함께 떠안는 일이다.
  • 위키가 망가지는 신호는 두 가지다. 답은 그럴듯한데 근거를 따라가면 출처가 하나뿐일 때, 그리고 원본을 고쳤는데 정리본이 옛 문장을 그대로 말할 때다. 이때는 자료를 더 넣을 것이 아니라 정리본을 다시 봐야 한다.
  • 사람을 위한 정리는 폴더를 주제별로 나누고 파일명을 통일하는 일이지만, AI를 위한 정리는 읽을 후보를 줄이는 일이다. 위키가 잘 작동하는 이유도 정리를 잘해서가 아니라 안 읽어도 되는 것을 치워 주기 때문이다.
  • 개인과 회사를 가르는 기준은 사람 수가 아니라 틀렸을 때 치르는 대가다. 혼자 쓰더라도 법률 자료나 건강 기록처럼 손해가 큰 자료라면 회사 수준의 장치가 필요하다.
  • 좋은 기업용 AI 시스템은 모든 질문에 혼자 답하는 천재가 아니라 질문을 알맞은 담당자에게 넘기는 접수 창구에 가깝다. 직무처럼 지식 영역을 나누고, 질문이 들어오면 어느 영역을 읽을지부터 고르게 하는 방식이다.

자주 묻는 질문

RAG 대신 LLM 위키만 써도 되나요?

개인이라면 조건이 맞을 때 가능하다는 것이 영상의 답이다. 자료 구조를 눈으로 확인할 수 있고, 파일 검색만으로 필요한 자료가 빠짐없이 나오며, 같은 설명을 반복하고 있다면 파일 기반 위키부터 시작해도 된다. 반대로 자료가 빠르게 바뀌어 매번 원문을 확인해야 하거나, 표현이 달라 자료를 놓치면 안 되거나, 여러 사람이 동시에 쓰며 권한을 걸러야 한다면 검색을 붙이는 편이 낫다.

컨텍스트 윈도우가 커졌으니 그냥 다 넣으면 되지 않나요?

영상은 그렇지 않다고 말한다. 최근 모델이 100만 토큰까지 읽는다고 해서 실제로 쓸 수 있는 양이 그만큼 늘어난 것은 아니라는 것이다. 근거로는 모델 18개를 대상으로 한 확인 결과가 제시되는데, 입력이 길어질수록 아주 단순한 문제에서도 정확도가 떨어졌고 관계없는 문서를 하나만 섞어도 성능이 내려갔다.

회사가 사내 지식 시스템을 만들 때 가장 먼저 할 일은 무엇인가요?

자료를 넣는 것이 아니라 질문을 적는 것이다. 다만 혼자 적지 말고 실제로 쓸 부서마다 다섯 개씩 받으라고 조언한다. 요구가 정해지지 않은 채 자료부터 넣으면 무엇을 만들었는지 아무도 검증할 수 없기 때문이며, 이 질문 목록이 곧 검증 기준이자 부서별 지식 영역의 범위가 된다.

권한 관리는 어떻게 해야 하나요?

문서에 부서와 보안 등급을 적어 두는 것만으로는 지켜지지 않는다고 본다. 그것은 표시일 뿐이고 실제로 막는 장치가 따로 있어야 한다. 특히 순서가 중요해서, 일단 다 찾아온 다음 답변에서 비밀 문서를 빼는 방식은 늦으며 권한 없는 문서는 AI가 읽기 전에 걸러야 한다.

원문과 출처

이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.

YouTube 원본 영상 보기 ↗

관련 AI 소식