RAG(Retrieval-Augmented Generation, 검색 증강 생성)는 대형 언어 모델이 답변하기 전에 먼저 자료를 찾아보게 하는 기술이다. 모델은 답변을 생성하기 전에 외부 지식 베이스에서 질문과 관련된 내용을 검색한 뒤, 그 내용을 근거로 답변을 작성한다. LLM의 두 가지 고질병―학습 데이터에 유효 기한이 있다는 점, 모르는 내용을 태연하게 지어내는 점(환각)―을 정면으로 겨냥해, 모델을 '기억에 의존해 답하는' 방식에서 '찾아보며 답하는' 방식으로 바꾼다.
세 단계는 무엇인가
전체 흐름은 이름 그대로 세 단계뿐이다.
- 검색(Retrieval): 사용자의 질문을 벡터로 변환해 벡터 데이터베이스나 문서 저장소에서 의미적으로 가장 관련 있는 텍스트 조각을 찾는다.
- 증강(Augmented): 찾아낸 조각들을 질문과 함께 프롬프트에 넣는다. 모델에게 '오픈북 시험의 참고 자료'를 건네는 셈이다.
- 생성(Generation): 모델은 이 자료를 바탕으로 답변을 구성한다. 잘 만든 구현은 각 문장의 출처까지 표시해 검증할 수 있게 한다.
경계를 짚자. RAG가 바꾸는 것은 '참고 자료'이지 모델 가중치가 아니다. 성능의 상한은 검색해 온 텍스트 조각의 품질에 달려 있다.
RAG와 파인튜닝의 차이
한 줄로 구분하면, RAG는 모델의 참고 자료를 바꾸고, 파인튜닝은 모델 자체를 바꾼다.
- 사내 문서·비공개 데이터·시사성 정보를 다루게 하고 싶다면 → RAG: 자료는 언제든 갱신되고 비용은 낮으며 답변의 근거를 추적할 수 있다.
- 말투나 출력 형식을 바꾸고, 특정 분야 전문가처럼 추론하게 하고 싶다면 → 파인튜닝: 능력을 가중치에 새겨 넣는다.
흔한 오해는 RAG를 '가난한 자의 파인튜닝'으로 보는 것이다. RAG는 모델을 학습시키지 않으며 행동 차원의 문제를 해결하지 못한다. 반대로 파인튜닝도 지식의 최신성 문제는 해결하지 못한다. 학습이 끝난 다음 날이면 새 지식은 다시 낡은 것이 되기 때문이다. 저비용 파인튜닝 방법은 LoRA 파인튜닝이란? 적은 비용으로도 전용 모델을 학습시킬 수 있는 이유를 참고하라.
RAG와 프롬프트 엔지니어링의 차이
프롬프트 엔지니어링이 '어떻게 물을 것인가'의 문제라면, RAG는 '무슨 자료를 갖고 물을 것인가'의 문제다.
잘 다듬은 프롬프트는 모델이 가진 지식을 더 잘 끌어내고 지정된 형식으로 출력하게 돕지만, 모델이 모르는 사실을 만들어내지는 못한다. RAG는 사실을 모델의 입 앞까지 배달한다. 실무에서는 둘을 함께 쓰는 경우가 많다. RAG가 자료를 제공하고, 프롬프트가 규칙을 정하는 식이다. "제공된 자료만을 근거로 답하고, 자료에 없으면 모른다고 밝히며, 정보마다 출처를 표시하라"는 식으로 말이다.
흔한 세 가지 오해
오해 1: RAG는 모델에게 웹 검색을 시키는 것이다. 웹 검색은 RAG의 한 특수한 형태일 뿐이다(검색 대상이 인터넷 전체인 경우). 기업에서 흔한 RAG의 검색 대상은 사내 지식 베이스, 문의 이력, 제품 문서다. RAG의 핵심은 '검색+생성'이라는 구조이지 '인터넷 연결'이라는 동작이 아니다.
오해 2: RAG를 쓰면 환각이 사라진다. 줄일 수는 있어도 없앨 수는 없다. 검색해 온 조각이 엉뚱하거나 모델이 자료를 오독하면 여전히 틀린다. RAG의 진짜 가치는 오류를 검증 가능하게 만드는 데 있다. 답변에 출처가 붙으니 어느 자료에 문제가 있었는지 추적할 수 있다.
오해 3: RAG와 파인튜닝 중 어느 쪽이 더 우월한가. 차원이 다른 이야기다. 하나는 '지식을 어디서 가져올 것인가', 다른 하나는 '능력을 어떻게 만들 것인가'를 다룬다. 실제 운영 환경에서는 둘을 함께 쓰는 경우가 흔하다. 행동 스타일은 파인튜닝으로 잡고, 최신 지식은 RAG로 연결하는 식이다.
가장 잘 맞는 장면
기업 지식 베이스 Q&A(고객 지원, 사내 위키 자동 응답), 장문 문서 어시스턴트(수백 쪽 계약서·매뉴얼·논문에 대한 질문), 그리고 '틀렸을 때 대가가 크고 출처 확인이 필수'인 장면이다. 여러 문서를 넘나드는 종합적인 질문(예: "이들 재무 자료가 공통으로 보여주는 추세는?")을 다루고 싶다면 변형인 GraphRAG를 참고하라.
