RAG — 파인튜닝 안 하고도 최신 정보를 아는 법

RAG를 "모델에게 문서를 학습시키는 방법"으로 오해하면, 벡터 데이터베이스에 아무리 많은 자료를 채워 넣어도 모델이 그 내용을 영구히 "기억"하길 기대하다가 실망하게 됩니다. RAG는 학습이 아니라 질문이 들어올 때마다 관련 자료를 찾아 프롬프트에 끼워 넣는 검색 절차이며, 이 차이를 모르면 왜 최신 정보를 놓치거나 엉뚱한 문서를 근거로 답하는지 끝까지 이해하기 어렵습니다.

---

배경 / 왜 지금 이 용어인가

RAG(Retrieval-Augmented Generation, 검색증강생성)라는 이름은 2020년 Patrick Lewis 등이 발표한 논문에서 처음 제안되었습니다. 당시 Facebook AI Research(현 Meta AI)와 UCL, NYU 연구진이 NeurIPS 2020에 발표한 이 논문은 RAG를 "사전학습된 파라메트릭 언어모델과, 검색으로 접근하는 비파라메트릭 외부 메모리를 결합하는 범용 미세조정 레시피"로 정의했습니다(arXiv).

2026년 현재는 프론티어급 모델 다수가 100만 토큰 안팎의 컨텍스트 윈도우를 지원하면서 "이제 RAG 없이 문서를 통째로 넣으면 되는 것 아니냐"는 질문이 다시 나오고 있습니다(Winder.ai). 그런데도 여전히 대부분의 실무 LLM 애플리케이션이 RAG를 기본 구조로 채택하고 있다는 점에서, "RAG가 정확히 무엇이고 언제 쓸모가 있는지"를 다시 정리해 둘 필요가 있습니다.

핵심 데이터 & 현황

지표	내용	출처
최초 제안	2020년 NeurIPS, Lewis 외(Facebook AI Research·UCL·NYU)	Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks"
컨텍스트 윈도우 확대	2026년 프론티어·중급 모델 다수가 100만~200만 토큰급을 지원, 프롬프트 캐싱으로 재사용 비용 절감	Winder.ai, 2026.06.24
방식별 구축 비용·기간(2026)	RAG 약 5천4만 파운드·13주 / 파인튜닝 약 1만6만 파운드·48주 / 하이브리드 약 3만12만 파운드·612주	Winder.ai, 2026.06.24
파인튜닝 데이터 요구량	과거엔 "최소 1,000건" 통념 → 2026년 LoRA 기준 200~500건의 큐레이션 예제로도 가능	Winder.ai, 2026.06.24

해석: 컨텍스트 윈도우가 커진다고 RAG가 사라지는 것이 아니라, "코퍼스가 창 크기보다 작고 거의 안 바뀌는" 좁은 경우에만 롱컨텍스트 단독 사용이 경쟁력을 갖게 된 것에 가깝습니다.

심층 분석

1) RAG는 정확히 무엇인가

RAG는 두 단계로 이뤄집니다. 먼저 사용자의 질문을 임베딩(embedding, 텍스트를 숫자 벡터로 바꾼 것)으로 변환하고, 이를 미리 구축해 둔 벡터 데이터베이스 안의 문서 임베딩들과 비교해 가장 유사한 문서 조각(top-k)을 찾아냅니다(검색, Retrieval). 그다음 이 조각들을 원래 질문과 함께 프롬프트에 넣어 언어모델이 답을 생성하게 합니다(생성, Generation)(NVIDIA Blog). 즉 모델의 가중치는 전혀 바뀌지 않고, 매 요청마다 "지금 이 질문에 필요한 자료"를 찾아 옆에 끼워 주는 방식입니다.

2) 흔한 오해 — 왜 그렇게 읽게 되나

가장 흔한 오해는 "RAG = 모델 학습"입니다. 벡터DB에 문서를 넣는 과정이 "AI를 가르친다"는 표현과 함께 소개되는 경우가 많다 보니 생기는 오해인데, 실제로는 검색 인덱스를 만드는 것이지 모델 파라미터를 바꾸는 것이 아닙니다. 두 번째 오해는 "RAG를 쓰면 환각(hallucination, AI가 그럴듯하지만 틀린 답을 만들어내는 현상)이 사라진다"는 것입니다. 위키백과는 이를 명확히 반박하는데, "모델이 검색된 자료 주변에서도 여전히 환각을 일으킬 수 있다"고 지적합니다(Wikipedia). 검색해 온 문서가 틀렸거나, 서로 다른 문서가 상충하는 내용을 담고 있을 때 모델이 어느 쪽이 맞는지 스스로 판단하지 못하는 경우도 같은 맥락의 한계입니다.

3) 실제로 판단하는 기준

RAG와 파인튜닝, 롱컨텍스트 중 무엇을 쓸지는 "무엇이 바뀌는가"로 구분하는 것이 가장 간단합니다. 검색은 요청 시점에 근거 자료를 골라 주고, 파인튜닝은 예시로부터 모델의 행동 자체를 바꾸며, 롱컨텍스트는 그저 한 번의 요청에 더 많은 자료를 통째로 넣어 주는 것입니다(Winder.ai). 지식이 자주 갱신되거나, 답변에 출처를 명시해야 하거나, 자료 전체가 모델의 컨텍스트 창보다 크다면 RAG가 유리합니다. 반대로 모델이 사실관계는 이미 알고 있는데 답변의 형식·어투·구조만 바꾸고 싶다면 파인튜닝 쪽이 맞습니다.

4) 언제 쓸모 있고 언제 무의미한가

코퍼스가 작고(컨텍스트 창 안에 다 들어가는 수준) 내용도 거의 바뀌지 않는다면, 프롬프트 캐싱을 활용해 문서 전체를 매번 넣는 편이 검색 파이프라인을 따로 구축하는 것보다 단순할 수 있습니다. 반면 문서별로 열람 권한을 다르게 줘야 하거나, 데이터가 매일 갱신되거나, 자료 총량이 창 크기를 넘어서는 사내 지식베이스형 서비스라면 RAG를 대체할 뾰족한 대안이 아직 없습니다.

실전 — RAG를 제대로 읽는 4가지 원칙

1. "RAG 도입"이 "환각 제로"를 뜻하지 않습니다. 검색된 문서 자체가 틀렸거나 오래됐다면, 모델은 그 틀린 내용을 그럴듯하게 재구성해 답할 뿐입니다.
2. 코퍼스 크기와 갱신 주기부터 따져 보는 것이 먼저입니다. 작고 안 바뀌는 자료라면 굳이 벡터DB를 만들지 않고 롱컨텍스트로 넣는 편이 더 저렴할 수 있습니다.
3. 출처 인용이 필요한 영역(법률, 사내 규정, 고객 응대 근거)일수록 RAG의 이득이 큽니다. 어떤 문서에서 나온 답인지 되짚어 확인할 수 있기 때문입니다.
4. RAG와 파인튜닝은 양자택일이 아닙니다. "무엇을 답할지"는 RAG로, "어떻게 답할지"는 파인튜닝으로 나눠 맡기는 하이브리드 구성이 2026년 기준 실무의 기본값에 가깝습니다.