RAG는 Retrieval-Augmented Generation의 약자로, 한국어로는 검색 증강 생성이라고 합니다. 한 줄로 말하면, AI가 답을 만들기 전에 관련 문서나 데이터베이스를 먼저 찾아보고, 그 내용을 참고해 답변을 생성하게 하는 방식입니다.
챗GPT 같은 LLM은 학습 때 본 지식을 바탕으로 답합니다. 하지만 회사의 최신 공지, 어제 바뀐 요금제, 내부 매뉴얼, 비공개 계약서 내용은 모델이 모를 수 있습니다. RAG는 이때 "모르면 외부 자료를 찾아보고 답하라"는 구조를 붙여 줍니다.
AI 생성 이미지
RAG는 '검색'과 '생성'을 붙인 구조다
RAG를 이해하려면 이름을 둘로 나누면 됩니다.
Retrieval: 필요한 정보를 검색해서 가져오는 단계
Generation: 가져온 정보를 바탕으로 답변을 생성하는 단계
예를 들어 직원이 사내 챗봇에 이렇게 묻습니다.
"올해 육아휴직 신청 절차가 어떻게 바뀌었어?"
일반 LLM은 그 회사의 내부 인사 규정을 모릅니다. 알고 있는 척 답하면 틀릴 가능성이 큽니다. 반면 RAG를 붙인 챗봇은 먼저 사내 문서 저장소에서 "육아휴직", "신청 절차", "2026 인사 규정"과 관련된 문서를 찾습니다. 그다음 찾은 문서 일부를 LLM에게 함께 넣어 줍니다.
그러면 LLM은 머릿속 지식만으로 답하지 않고, 검색된 문서를 참고해 답합니다.
흐름은 보통 이렇습니다.
사용자가 질문한다.
시스템이 질문과 관련된 문서를 검색한다.
검색된 문서 조각을 질문과 함께 LLM에 넣는다.
LLM이 그 자료를 근거로 답변을 만든다.
가능하면 답변 아래에 출처 문서를 표시한다.
AWS는 RAG를 사용자의 질문에 맞는 외부 정보를 먼저 가져오고, 그 정보를 프롬프트의 맥락으로 추가한 뒤 LLM이 답변을 생성하는 흐름으로 설명합니다.1 즉 RAG는 모델을 새로 학습시키는 기술이라기보다, 답변 직전에 참고자료를 붙여 주는 기술에 가깝습니다.
왜 RAG가 필요할까
RAG가 자주 언급되는 이유는 LLM의 약점과 직접 연결됩니다.
첫째, LLM의 지식은 제한적입니다. 모델은 학습된 데이터에서 패턴을 배웠지만, 모든 최신 정보를 실시간으로 알고 있지는 않습니다. 신제품 가격, 오늘 바뀐 정책, 회사 내부 문서, 고객별 계약 조건은 기본 모델 안에 없을 수 있습니다.
둘째, LLM은 모르는 내용도 그럴듯하게 말할 수 있습니다. 이것이 할루시네이션입니다. 특히 질문이 애매하거나, 모델이 모르는 고유명사나 최신 정보를 묻는 경우 틀린 답을 자연스럽게 만들 수 있습니다.
RAG는 이 문제를 줄이기 위해 쓰입니다. IBM은 RAG를 AI 모델을 외부 지식베이스와 연결해 성능을 높이는 구조로 설명하며, 학습 데이터만 의존할 때보다 최신성·전문성·정확성을 보완할 수 있다고 봅니다.2
비유하면 이렇습니다.
일반 LLM은 시험장에서 기억만으로 답하는 학생에 가깝습니다. RAG가 붙은 LLM은 시험 전에 관련 교재 페이지를 찾아보고 답하는 학생에 가깝습니다. 물론 교재를 잘못 찾거나 내용을 잘못 읽으면 틀릴 수 있습니다. 하지만 적어도 기억만 믿고 지어내는 위험은 줄어듭니다.
사내 문서 챗봇은 어떻게 가능할까
RAG의 대표 사례는 사내 문서 챗봇입니다.
회사는 이미 많은 문서를 갖고 있습니다. 인사 규정, 보안 정책, 제품 매뉴얼, 고객 지원 FAQ, 영업 제안서, 회의록, 기술 문서가 여기저기 흩어져 있습니다. 문제는 사람이 찾기 어렵다는 점입니다.
RAG 시스템은 이 문서들을 AI가 검색할 수 있는 형태로 정리합니다. 사용자가 자연어로 질문하면, 시스템은 관련 문서 조각을 찾아 LLM에 넣고 답변을 만듭니다.
예를 들면 이런 식입니다.
질문: "우리 제품의 엔터프라이즈 요금제에서 API 호출 한도는 얼마야?"
RAG 챗봇은 가격 정책 문서, API 문서, 최신 공지 중 관련 부분을 찾아봅니다. 그리고 이렇게 답할 수 있습니다.
"엔터프라이즈 요금제의 기본 API 호출 한도는 월 100만 회입니다. 단, 계약 조건에 따라 별도 한도가 적용될 수 있습니다. 자세한 내용은 '2026 엔터프라이즈 요금 정책' 문서의 API 사용량 섹션을 확인하세요."
여기서 중요한 것은 답변의 말솜씨가 아닙니다. 어떤 문서를 근거로 답했는지입니다. RAG는 답변 아래에 출처를 붙일 수 있기 때문에, 사용자는 AI 답을 그대로 믿지 않고 원문을 확인할 수 있습니다.
문서를 그냥 넣으면 되는 걸까
RAG는 "문서를 연결하면 끝"처럼 보이지만 실제 품질은 여러 단계에서 갈립니다.
첫 번째는 문서 분할입니다. 긴 PDF나 매뉴얼 전체를 한 번에 넣기는 어렵습니다. 그래서 문서를 작은 조각으로 나눕니다. 이 조각을 흔히 청크(chunk)라고 부릅니다.
조각이 너무 작으면 앞뒤 맥락이 사라집니다. 예를 들어 "신청은 30일 전까지 해야 한다"라는 문장만 남고, 그것이 육아휴직인지 장비 대여인지 빠질 수 있습니다. 반대로 조각이 너무 크면 검색 결과에 불필요한 내용이 많이 섞입니다. 필요한 문장 하나를 찾기 위해 관련 없는 문단까지 모델에 넣게 됩니다.
두 번째는 임베딩입니다. 임베딩은 문장의 의미를 숫자 벡터로 바꾸는 과정입니다. 어렵게 들리지만, 쉽게 말하면 문장들을 의미 지도 위의 좌표로 바꾸는 일입니다.
"환불 규정이 궁금해요"와 "결제 취소는 언제까지 가능한가요?"는 단어가 다르지만 의미는 가깝습니다. 임베딩을 사용하면 단어가 정확히 일치하지 않아도 의미가 비슷한 문서를 찾을 수 있습니다.
세 번째는 벡터 검색입니다. 사용자의 질문도 숫자 벡터로 바꾸고, 문서 조각들의 벡터와 비교해 의미가 가까운 것을 찾습니다. 이때 쓰이는 저장소를 벡터 데이터베이스라고 부릅니다. Google Cloud도 RAG를 검색·데이터베이스 같은 정보 검색 시스템과 생성형 LLM을 결합하는 구조로 설명하며, 벡터 데이터베이스와 검색 계층, 맥락 주입이 핵심 구성요소라고 설명합니다.3
네 번째는 출처 표시입니다. RAG 답변에서 출처는 장식이 아닙니다. 사용자가 답을 검증할 수 있게 하는 안전장치입니다. 특히 법무, 의료, 금융, 인사, 보안처럼 틀리면 손해가 큰 분야에서는 "그럴듯한 답"보다 "확인 가능한 답"이 중요합니다.
RAG는 파인튜닝과 무엇이 다를까
RAG와 파인튜닝은 자주 비교됩니다. 둘 다 AI를 업무에 맞게 쓰기 위한 방법이지만 역할이 다릅니다.
파인튜닝은 모델을 추가 학습시켜 답변 방식이나 판단 기준을 바꾸는 방법입니다. 예를 들어 고객 문의를 "환불", "배송", "장애 신고"로 분류하는 기준을 반복 학습시키는 데 적합합니다.
RAG는 모델 자체를 바꾸지 않고, 답변할 때 참고할 자료를 검색해 넣는 방식입니다. 최신 정책, 사내 문서, 제품 매뉴얼처럼 자주 바뀌는 정보에 적합합니다.
간단히 나누면 이렇습니다.
말투, 형식, 반복 판단 기준을 안정화하고 싶다 → 파인튜닝 검토
최신 문서나 내부 자료를 근거로 답하게 하고 싶다 → RAG 검토
간단한 지시와 출력 형식만 바꾸면 된다 → 프롬프트부터 시도
그래서 기업의 "사내 AI 도입" 기사에서 RAG가 자주 등장합니다. 회사는 모든 내부 문서를 모델에 새로 학습시키고 싶지 않습니다. 비용도 크고, 문서가 바뀔 때마다 다시 학습해야 하며, 민감 정보 관리도 어렵습니다. RAG는 내부 지식베이스를 검색 대상으로 두고, 필요한 순간에만 관련 자료를 불러오는 방식이라 실무적으로 유용합니다.
RAG도 할루시네이션을 완전히 없애지는 못한다
RAG는 강력하지만 만능은 아닙니다.
검색된 문서가 틀리면 답도 틀릴 수 있습니다. 오래된 문서가 최신 문서보다 먼저 검색되면 잘못된 안내가 나올 수 있습니다. 문서 조각이 너무 짧으면 모델이 맥락을 오해할 수 있습니다. 반대로 너무 많은 자료를 넣으면 모델이 중요한 내용을 놓칠 수 있습니다.
또 LLM이 검색된 문서를 제대로 읽지 못하고, 없는 내용을 덧붙일 수도 있습니다. RAG는 할루시네이션을 줄이는 방법이지, 없애는 보증서가 아닙니다.
좋은 RAG 시스템에는 보통 이런 장치가 필요합니다.
최신 문서와 오래된 문서를 구분한다.
신뢰할 수 있는 문서만 검색 대상으로 삼는다.
답변에 사용한 문서 출처를 표시한다.
모르는 경우 억지로 답하지 않게 한다.
중요한 업무에서는 사람이 최종 확인한다.
검색 품질을 계속 평가하고 개선한다.
Dataquest의 RAG 설명도 문서 분할, 임베딩, 벡터 데이터베이스 저장, 의미 기반 검색, 검색 결과를 프롬프트에 넣기, 출처 반환을 실제 RAG 흐름의 핵심 단계로 정리합니다.4 결국 RAG 품질은 "좋은 모델"만으로 결정되지 않습니다. 좋은 문서 관리, 좋은 검색, 좋은 출처 표시가 함께 필요합니다.
뉴스에서 RAG를 보면 이렇게 읽자
AI 뉴스나 제품 발표에서 "RAG 기반 사내 챗봇", "RAG로 할루시네이션 감소", "기업 데이터와 LLM 연결" 같은 표현을 자주 볼 수 있습니다. 이때는 다음 질문을 해보면 됩니다.
첫째, 어떤 자료를 검색하나? 웹 전체인지, 사내 문서인지, 고객 데이터베이스인지, 제품 매뉴얼인지 확인해야 합니다.
둘째, 최신 자료가 반영되나? RAG의 장점은 최신성과 내부 지식 활용인데, 실제로 문서가 자주 업데이트되지 않으면 효과가 떨어집니다.
셋째, 출처가 표시되나? 출처 없는 RAG 답변은 검증하기 어렵습니다. 특히 업무용 AI라면 답변 근거를 원문 링크나 문서명으로 확인할 수 있어야 합니다.
넷째, 권한 관리는 되어 있나? 사내 RAG 챗봇이 모든 직원에게 모든 문서를 보여주면 보안 사고가 됩니다. 사용자의 직무와 권한에 따라 검색 가능한 문서가 달라야 합니다.
다섯째, 틀렸을 때 책임 구조가 있나? AI가 내부 규정을 잘못 안내했을 때 누가 확인하고 수정할지 정해져 있어야 합니다.
RAG는 AI가 갑자기 모든 것을 알게 만드는 마법이 아닙니다. 더 정확히 말하면, AI가 답하기 전에 참고할 자료를 찾아주는 업무 구조입니다. 그래서 RAG를 이해하면 사내 문서 챗봇, AI 검색, 고객지원 자동화, 최신 정보 답변이 어떻게 가능한지 훨씬 선명하게 보입니다.
같이 보면 좋은 단어
할루시네이션: AI가 근거 없는 내용을 그럴듯하게 말하는 현상입니다. RAG가 왜 필요한지 이해하는 출발점입니다.
AI 검색: 검색엔진이 단순 링크 목록을 넘어 답변을 생성하는 흐름을 이해할 수 있습니다.
컨텍스트: RAG가 검색한 문서를 LLM에 넣을 때, 그 자료가 어떤 입력 범위 안에서 작동하는지 이해하는 핵심 개념입니다.
참고
2IBM, What is retrieval augmented generation (RAG)?
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.