RAG 는 순수 LLM 의 무엇을 지웠고, 지우지 못한 것은 무엇인가

“RAG 가 LLM 을 유용하게 만들었다” 는 서사는 절반만 맞다. RAG 의 아이디어 자체 — “질문을 받으면 관련 문서를 찾아서 답한다” — 는 새로운 게 아니다. 정보 검색(IR)은 60년 된 분야다. RAG 가 실제로 지운 것은 “LLM 시대에 그 오래된 아이디어를 다시 갖다 붙여야 했던 이유”, 즉 순수 LLM 만으로는 답할 수 없는 세 가지 종류의 질문 이다.

먼저 사실.

논문: Lewis, Perez, Piktus, Petroni, Karpukhin, Goyal, Küttler, Lewis, Yih, Rocktäschel, Riedel, Kiela — “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”, NeurIPS 2020.¹
2020년 공개. Facebook AI Research(현 Meta AI) 주도.
이름 자체가 아키텍처를 그대로 압축한다 — Retrieval(검색) + Augmented(증강된) + Generation(생성).

이 논문이 나온 시점은 GPT-3 가 발표된 해와 같다. 우연이 아니다. LLM 이 커질수록, LLM 만으로는 답할 수 없는 질문의 목록도 같이 커졌다. 그 목록에 대응하려고 RAG 가 나왔다.

1. 순수 LLM 이 못 하는 세 가지

1-1. Knowledge cutoff — 학습 이후에 생긴 사실을 모른다

GPT-4 의 학습 데이터가 2023년 12월까지라면, 2024년 4월에 통과된 법률을 물어보면 알지 못하거나 예전 사실을 말한다. 모델은 학습 시점의 세계를 파라미터 안에 고정된 스냅샷 으로 갖고 있다.

이걸 갱신하려면 다시 학습시켜야 한다. 175B 파라미터 모델의 재학습은 수백만 달러 규모. 매주 변하는 사실을 매주 재학습할 수는 없다.

1-2. Hallucination — 모르는 것을 그럴듯하게 만든다

LLM 은 “다음 토큰의 확률” 을 계산한다. 확률적으로 그럴듯한 문장을 만들지만, 그것이 사실인지는 언어 모델링 목표와 무관하다. 존재하지 않는 논문을 인용하고, 없는 API 를 호출하고, 만들어낸 판례를 진지하게 설명한다. Wikipedia 도 이 문제를 명시한다 — RAG 는 “정책이 존재하지 않는데도 설명하는 챗봇” 을 줄이려는 시도다.¹

1-3. Attribution — 답의 출처를 댈 수 없다

순수 LLM 이 “이 정보는 X 논문에 나옵니다” 라고 말해도, 실제로 그 정보가 그 논문에서 나왔는지 검증할 수 없다. 모델의 대답은 수천억 문서를 압축한 파라미터의 산물이지, 특정 원본을 참조한 결과가 아니다. 규제 · 의료 · 법률 · 학술 영역에서 이건 치명적이다 — “모델이 그렇게 말했다” 는 근거로 쓸 수 없다.

이 세 통증에 RAG 이전에 어떤 대응들이 시도됐는지 먼저 보자.

2. RAG 이전의 대응들 — 왜 부족했나

2-1. 대응 A — “그냥 물어보자”

가장 단순한 접근. 문제는 위 세 통증 모두에 취약하다는 것. 개인 지식 챗봇, 사내 문서 QA, 최신 뉴스 요약 — 전부 불가능하거나 위험하다.

2-2. 대응 B — 파인튜닝

내 데이터로 모델을 미세조정한다. 이론적으로는 도메인 지식이 모델에 들어간다.

문제 셋.

비용. GPT-3.5 파인튜닝만 해도 데이터 준비 · 학습 · 배포 · 유지가 든다. GPT-4 급 모델은 파인튜닝 자체를 지원 안 하거나 비쌈.
정적. 하루에 문서 100개가 추가되는 지식 베이스를 그때마다 파인튜닝할 수는 없다.
여전히 hallucinate 한다. 파인튜닝은 “이 스타일로 말해라” 를 잘 가르치지만, “이 사실만 말해라” 를 강제하지 못한다.
출처 못 댐. 파인튜닝된 모델도 여전히 파라미터에서 답을 뽑는다 — 특정 문서를 참조한 게 아니다.

2-3. 대응 C — 롱 컨텍스트에 다 넣기

“컨텍스트 창이 100만 토큰이면 그냥 다 넣으면 되지 않나?” 물리적으로 가능은 하다. 문제는 셋.

비용. 입력 토큰당 과금. 매 질문마다 1M 토큰을 보내면 요청당 수 달러.
성능. 긴 컨텍스트에서 중간 부분의 정보를 모델이 놓친다(“lost in the middle” 현상, 여러 연구에서 재현됨).
여전히 상한이 있다. 회사 위키가 1M 토큰이 아니라 100M 토큰이면 어떻게 넣나.

이 세 대응이 다 부족한 자리를 RAG 가 채웠다.

3. RAG 의 아이디어 — 옛것과 새것의 조합

RAG 는 두 개의 오래된 것을 합쳤다.

옛것 1: 정보 검색(IR). 문서 컬렉션에서 질의어와 관련된 문서를 찾는 기술. TF-IDF(1972), BM25(1994), 그리고 2018년경부터 dense retrieval (신경망 임베딩 기반) 이 등장.

옛것 2: 조건부 생성. 프롬프트에 컨텍스트를 넣고 이어서 쓰는 언어 모델. GPT 스타일 언어 모델의 기본기.

새것: 이 둘을 하나의 학습 파이프라인으로 묶은 것. RAG 논문의 기여는 (1) retriever 와 generator 를 함께 학습 하고, (2) knowledge-intensive 태스크에서 이 조합이 순수 seq2seq 보다 뛰어남을 증명한 것.

산업에서 지금 널리 쓰이는 “RAG” 라는 단어는 논문의 엄밀한 구조 그대로가 아니다. retriever 는 미리 학습되고, LLM 은 검색 결과를 프롬프트에 받아 답을 생성하는 형태가 실무 표준. 논문의 이름을 받아 아키텍처의 총칭이 됐다.

4. 모던 RAG 스택 — 실제로 어떻게 생겼나

┌─────────────────────────────────────────────────────────────────┐
│ 1. 인덱싱 파이프라인 (한 번, 그리고 문서 추가 시)                    │
│    ┌────────────┐   ┌──────────────┐   ┌────────────┐          │
│    │ 원본 문서   │→ │ 청킹(chunking)│→ │ 임베딩 모델 │→ 벡터 DB │
│    │ (PDF, MD)  │   │ (500토큰씩)   │   │ (bge, e5)  │  저장    │
│    └────────────┘   └──────────────┘   └────────────┘          │
└─────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────┐
│ 2. 질의 파이프라인 (매 요청)                                        │
│    ┌────────┐   ┌────────────┐   ┌──────────┐   ┌───────────┐  │
│    │ 사용자  │→ │ 질의 임베딩 │→ │ 벡터 DB   │→ │ LLM 프롬프트│→ 답 │
│    │ 질문   │   │            │   │ top-k 검색│   │ (컨텍스트) │    │
│    └────────┘   └────────────┘   └──────────┘   └───────────┘  │
└─────────────────────────────────────────────────────────────────┘

프롬프트는 대략 이렇게 만들어진다.

아래 컨텍스트를 사용해 질문에 답하세요.
컨텍스트에 없는 내용은 "정보가 부족합니다" 라고 답하세요.

[컨텍스트 1] 정산 시스템은 매일 새벽 2시에 배치를 시작한다...
[컨텍스트 2] 배치 실패 시 알림은 Slack #settlement-alerts 로 발송된다...
[컨텍스트 3] 재시도 정책은 3회, 지수 백오프 30분 간격...

질문: 정산 배치가 실패하면 어떻게 되나요?
답:

이 하나의 구조가 위 세 통증을 다 다룬다.

Knowledge cutoff: 벡터 DB 는 오늘 업데이트하면 오늘부터 반영. 모델 재학습 없이 지식 갱신.
Hallucination: 컨텍스트에 없는 내용은 답하지 말라고 명시. 완전히 사라지진 않지만 크게 줄어든다.
Attribution: 어느 청크에서 답이 나왔는지 프롬프트가 알고 있어서 함께 반환 가능.

5. RAG 가 실제로 지운 것

5-1. “내 데이터로 챗봇 만들려면 파인튜닝해야 한다”

2022년까지의 통념. 이제는 대부분 RAG 로 시작하고, 파인튜닝은 말투 · 응답 형식 · 특정 태스크 성능 을 위해서만 쓴다.

5-2. 지식의 최신성을 모델 학습 주기에 묶는 것

문서 추가 · 수정 · 삭제가 벡터 DB 업데이트로 반영된다. 모델은 그대로 둔다.

5-3. “답의 근거” 를 반환할 수 없다는 제약

answer 와 함께 sources: [doc_id, page, chunk_id, similarity_score] 를 함께 돌려줄 수 있다. 규제 산업에서 이게 열어준 문이 크다.

5-4. 진입 장벽

2020년경 이런 시스템을 만들려면 IR 팀 + ML 팀 + 인프라 팀이 필요했다. 지금은 LangChain · LlamaIndex 같은 라이브러리와 pgvector · Chroma · Qdrant 같은 벡터 DB 로 1인 개발자가 주말에 프로토타입 을 만든다.

6. RAG 가 지우지 못한 것 — 여기가 진짜 어려운 부분

RAG 가 만능이 아니다. 실무 RAG 시스템의 성능이 실망스러운 이유는 대개 아래 다섯 중 하나다.

6-1. 검색 품질이 상한이다

LLM 은 컨텍스트에 있는 것만 쓸 수 있다. 답을 담은 청크가 top-k 검색에 안 걸리면, 아무리 좋은 LLM 이라도 답을 못 한다. 그리고 retrieval quality 는 사람이 평가하기가 매우 어려운 문제 다 — 정답이 하나가 아니고, 문서마다 관련성 판정이 다르다.

6-2. 청킹 전략이 성능을 결정한다

500 토큰 vs 1000 토큰, 오버랩 100 vs 200, 문단 단위 vs 문장 단위 — 이 결정 하나로 답 정확도가 20~30% 씩 오르내린다. 문서 유형마다 최적 청킹이 다르다. 표가 많은 문서는 표 단위, 코드가 많은 문서는 함수 단위, 논문은 섹션 단위.

6-3. 임베딩 모델이 도메인을 못 이해할 때

법률 · 의료 · 도메인 특화 용어가 많은 문서에서 범용 임베딩 모델(OpenAI text-embedding-3, BGE 등)은 유사도 판단을 어긋내기 쉽다. 도메인 임베딩 파인튜닝이 필요할 수 있는데, 그 순간 RAG 로 파인튜닝을 없앤다는 명분이 흔들린다.

6-4. 다단계 추론(multi-hop) 에 약함

“A 회사의 CEO 는 누구고, 그 사람이 이전에 다녔던 회사는 어디인가?” 는 두 개의 서로 다른 문서에서 두 번 검색해야 한다. 순수 RAG(한 번 검색) 는 이걸 못 한다. Agent 나 반복 검색(Iterative RAG) 같은 확장이 필요.

6-5. Hallucination 은 줄어들 뿐 사라지지 않는다

컨텍스트에 있는 문장을 잘못 조합하거나, 컨텍스트를 무시하고 파라미터 지식에서 답하는 경우가 여전히 발생. “컨텍스트에 없으면 모른다고 답해라” 는 지시를 지키지 않는 경우도 흔하다.

7. Before / After

	순수 LLM (2020~2022)	RAG (2023~)
지식 최신성	학습 시점에 고정	벡터 DB 업데이트로 즉시 반영
도메인 지식	파인튜닝 필요	문서 넣고 검색
출처 제시	못 함	청크 ID · 문서 ID 함께 반환
Hallucination	상수	감소 (제거는 아님)
비용 구조	프롬프트 토큰만	프롬프트 토큰 + 임베딩 저장 + 검색 비용
시스템 복잡도	낮음 (API 한 번)	높음 (벡터 DB, 인덱싱 파이프라인, 청킹, 리랭킹)
성능 병목	모델 크기 · 프롬프트 품질	검색 품질 · 청킹 · 임베딩

RAG 는 문제를 지운 게 아니라, 문제를 이동시켰다. LLM 의 hallucination 을 IR 의 retrieval quality 문제로 옮겼고, 파인튜닝의 정적성을 벡터 DB 의 인덱싱 파이프라인 관리 문제로 옮겼다.

이동시킨 곳이 다루기 쉬운 곳이냐 — 그건 대체로 그렇다. IR 은 60년의 기법이 쌓여 있는 분야고, 벡터 DB 는 SQL 만큼 성숙한 인프라는 아니지만 이해할 수 있는 소프트웨어 시스템이다. 반면 “LLM 이 왜 이 답을 냈는가” 는 여전히 아무도 정확히 답할 수 없는 질문 이다.

8. 정리 — 한 문장

RAG 는 “LLM 이 아는 것만으로는 부족한 질문” 을 위해 나왔다. 이 질문의 범주에는 최신 사실, 회사 내부 문서, 규제상 출처가 필요한 답, 그리고 hallucination 을 감당할 수 없는 응답이 들어간다. RAG 이전 이 질문들에 대한 답은 “안 됩니다” 또는 “파인튜닝하세요” 였다. RAG 이후 답은 “문서를 벡터로 넣고 검색해서 프롬프트에 붙이세요” 가 됐다.

대신 새로운 어려움이 생겼다 — 검색이 안 걸리면 답도 없고, 청킹이 나쁘면 검색이 안 걸리고, 임베딩이 도메인을 이해 못 하면 청킹이 소용없다. RAG 는 LLM 을 “쓸 수 있게” 만들었지만, “잘 쓰이게” 만드는 건 여전히 IR 기법과 도메인 이해가 있는 사람의 일이다.

Wikipedia, Retrieval-augmented generation — https://en.wikipedia.org/wiki/Retrieval-augmented_generation. Lewis 등 12인 저자의 2020년 NeurIPS 논문 “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks” 가 원점; RAG 가 다루는 세 가지 LLM 한계(환각, 지식 최신성, 출처 제시)를 명시; 아키텍처는 retriever + generator + vector database. ↩ ↩²