테크

2026-07-13

RAG란? RAG를 써도 AI가 틀리는 이유

LLM(대규모 언어 모델, Large Language Model)을 실제 서비스에 올릴 때, RAG(Retrieval-Augmented Generation, 검색 증강 생성)는 이제 선택이 아니라 사실상 기본 설계입니다. RAG란 AI가 답변을 생성하기 전에 관련 문서를 검색하고, 그 내용을 근거로 답하도록 만드는 기술입니다. 사내 지식 챗봇부터 문서 검색 어시스턴트, 스스로 도구를 부르는 AI 에이전트까지, 특정 자료에 근거해 답해야 하는 곳이면 대부분 RAG가 깔려 있습니다. 그런데 RAG를 붙인 뒤에도 AI가 틀린 답을, 그것도 출처까지 달아 내놓는 일이 생깁니다. 왜 그럴까요?

이 질문에 답하려면 RAG를 조금 더 정확히 들여다봐야 합니다. 이름은 익숙하지만 정확히 무엇을 하는 기법인지, 왜 표준처럼 굳었는지, 어디까지 믿어도 되는지는 헷갈리기 쉽습니다. AI 기능을 실제 서비스에 붙이는 입장이라면 RAG의 효용만큼이나 그 한계를 아는 것이 신뢰성 판단에 중요합니다.

‍

RAG란 무엇인가

RAG는 이름 그대로 검색으로 증강한 생성입니다. 쉽게 말하면 AI에게 오픈북 시험을 치르게 하는 방식에 가깝습니다. 외워 둔 지식만으로 답하는 대신, 먼저 관련 자료를 펼쳐 놓고 그것을 근거로 답을 씁니다.

동작은 세 단계로 나뉩니다.

검색(Retrieval): 질문이 들어오면 지식베이스(사내 문서·데이터베이스·웹 등)에서 관련 문서를 찾아옵니다.
증강(Augmentation): 찾아온 문서를 원래 질문과 함께 모델의 입력(프롬프트)에 넣습니다.
생성(Generation): 모델이 그 문서를 근거로 최종 답을 만듭니다.

RAG의 검색·증강·생성 3단계 흐름, 질문에서 답변까지 — *그림 1. RAG의 검색·증강·생성 3단계*

‍

LLM의 지식은 학습을 마친 시점에 멈춰 있습니다. RAG는 그 바깥의 최신 자료나 비공개 자료를 답할 때마다 끌어와 붙여 주는 장치라고 볼 수 있습니다.

이렇게 검색한 문서를 근거로 답하도록 만드는 과정을 흔히 그라운딩(grounding)이라고 합니다. RAG의 핵심 목적도 결국 답변을 실제 근거에 연결하는 데 있습니다.

‍

RAG는 왜 기본이 됐나

몇 년 전만 해도 LLM에 최신 정보나 사내 자료를 반영하려면 모델을 다시 학습시키는 것이 거의 유일한 길이었습니다. RAG로 그 전제가 바뀌었습니다. RAG가 빠르게 표준으로 받아들여진 이유는 LLM의 오래된 약점 두 가지를 한 번에 해결하기 때문입니다. 하나는 학습 이후의 정보나 회사 내부 문서를 알지 못한다는 점이고, 다른 하나는 모르는 것을 그럴듯하게 지어내는 환각(hallucination) 현상입니다.

모델이 자기 기억에만 의존하지 않고 검색해 온 문서를 바탕으로 답하면 환각이 줄고 출처를 함께 제시할 수 있습니다. 모델을 재학습하지 않고도 최신·비공개 지식을 다룰 수 있어 비용과 속도 면의 이점도 큽니다. AWS도 RAG를 '재학습 없이 외부의 권위 있는 지식베이스를 참조하도록 LLM 출력을 최적화하는 방법'으로 정의합니다.

하지만 근거를 가져왔다고 해서 항상 그 근거대로 답하는 것은 아닙니다. 그렇다면 RAG를 적용했는데도 AI는 왜 틀린 답을 내놓을까요?

‍

RAG를 써도 AI가 틀리는 이유

여기서부터가 RAG를 실제 서비스에 도입하는 입장에서 놓치기 쉬운 대목입니다.

RAG는 환각을 줄이지만, 없애지는 못합니다.

AI가 출처까지 그럴듯하게 달고도 틀린 답을 내놓는 이유는 크게 두 단계에서 어긋나기 때문입니다. 검색 단계에서 어긋나느냐, 생성 단계에서 어긋나느냐에 따라 원인도, 해결 방법도 달라집니다.

검색의 실패(retrieval failure): 질문과 관련성이 낮은 문서를 가져오는 경우입니다. 청킹(chunking), 의미 기반 검색, 리랭킹(re-ranking) 등 검색 과정이 제대로 동작하지 않으면 관련성이 낮은 문서가 선택될 수 있습니다. 모델은 잘못된 근거를 바탕으로 답을 생성하기 때문에 자연스럽게 오답으로 이어집니다.
생성의 실패, 곧 미스그라운딩(misgrounding): 문서는 제대로 가져왔는데도 모델이 그 문서에 없는 내용을 지어내거나, 내용을 잘못 해석해 답하는 경우입니다. 근거(ground)와 최종 답변 사이의 연결이 끊어진 상태입니다.

RAG 파이프라인의 두 실패 지점, 검색의 실패와 미스그라운딩 — *그림 2. RAG 파이프라인의 두 실패 지점*

‍

검색의 실패와 미스그라운딩 비교

두 실패는 비슷해 보이지만 원인과 해결 방법이 다릅니다.

구분	검색의 실패	미스그라운딩
문제 발생 위치	검색	생성
검색 문서	잘못 가져옴	제대로 가져옴
원인	검색 품질	모델 해석
해결	검색 개선	생성 결과 검증·관측

‍

예를 들어 사내 휴가 규정에는 "입사 즉시 연차를 사용할 수 있다"고 적혀 있는데도, AI가 "입사 6개월 이후부터 사용할 수 있습니다"라고 답하면서 같은 규정을 출처로 제시하는 경우입니다. 문서는 제대로 검색됐지만 답변은 근거를 벗어난 것입니다. 바로 이런 경우가 미스그라운딩입니다.

RAG 챗봇 미스그라운딩 예시, 근거 문서는 입사 즉시 연차 사용 가능인데 AI는 6개월 이후로 답변 — *그림 3. 미스그라운딩 예시, 근거와 다른 AI 답변*

‍

미스그라운딩이 특히 까다로운 이유는 겉으로 보기에는 그럴듯하기 때문입니다. 답변에는 인용과 출처 링크까지 붙어 있어 신뢰하기 쉽지만, 실제 출처를 확인해 보면 답변을 뒷받침하지 않는 경우가 적지 않습니다. 이런 문제는 이론적인 가능성에 그치지 않습니다. 스탠퍼드대학 HAI/RegLab이 2024년 공개한 연구에 따르면, '환각 없음'을 표방한 상용 법률 조사 AI 도구조차 질의의 17%에서 33% 사이에서 환각을 일으켰습니다.

결국 RAG를 적용했다는 사실만으로 답변을 신뢰할 수는 없습니다. 두 문제는 발생하는 단계가 다른 만큼 줄이는 방법도 다릅니다.

검색의 실패는 검색 단계 자체를 개선해 줄입니다. 문서를 적절한 크기로 나누는 청킹, 검색된 후보의 순서를 다시 조정하는 리랭킹, 검색 전략을 개선하는 것이 대표적인 방법입니다. 반면 미스그라운딩은 검색 품질만 높인다고 해결되지 않습니다. 검색이 완벽해도 모델은 근거를 잘못 해석하거나 근거에 없는 내용을 덧붙일 수 있기 때문입니다. 그래서 운영 단계에서는 생성된 답변이 실제 근거 문서와 일치하는지 지속적으로 확인하고 평가하는 과정이 함께 필요합니다.

두 실패를 줄이는 방법, 검색의 실패는 검색 단계 개선·미스그라운딩은 운영 단계 관측·평가 — *그림 4. 검색의 실패와 미스그라운딩을 줄이는 방법*

‍

자주 묻는 질문

RAG와 파인튜닝(fine-tuning)은 무엇이 다른가요?

파인튜닝은 모델 자체를 특정 데이터로 추가 학습시켜 성향을 바꾸는 방식이고, RAG는 모델은 그대로 둔 채 답할 때마다 외부 자료를 붙여 주는 방식입니다. 자주 바뀌는 지식이나 최신 문서에는 RAG가, 말투나 출력 형식 같은 고정된 성향 조정에는 파인튜닝이 어울린다고 볼 수 있습니다. 선택은 다루는 데이터가 얼마나 자주 바뀌는지에 따라 달라집니다.

RAG와 벡터 데이터베이스(vector database)는 같은 것인가요?

아닙니다. 벡터 데이터베이스는 RAG에서 문서를 검색하기 위해 자주 사용하는 저장소입니다. RAG는 검색·증강·생성 전체 과정을 의미하고, 벡터 데이터베이스는 그 가운데 검색을 구현하는 구성 요소 중 하나입니다.

환각과 미스그라운딩은 같은 말인가요?

같지 않습니다. 환각은 AI가 근거 없이 틀린 답을 내놓는 현상 전반을 가리키고, RAG를 쓰지 않아도 생깁니다. 미스그라운딩은 RAG로 근거를 제대로 가져왔는데 답이 그 근거를 벗어나는 특정 경우, 곧 환각의 한 유형입니다. 원인도 대응도 다르기 때문에 둘을 뭉뚱그리면 문제를 잘못 짚기 쉽습니다.

RAG를 쓰면 환각이 완전히 사라지나요?

완전히 사라지지는 않습니다. 앞서 본 대로 검색 품질을 높이면 크게 줄지만, 검색이 완벽해도 모델이 근거를 벗어나 지어내는 미스그라운딩은 남습니다. '환각 없는 RAG'를 목표로 삼기보다, 남는 환각을 관측으로 붙잡는 편이 현실적입니다.

RAG가 틀렸는지 어떻게 알 수 있나요?

답만 봐서는 알기 어렵습니다. 어떤 문서를 검색해 왔는지, 그 문서가 최종 답을 실제로 뒷받침하는지를 함께 봐야 합니다. 그래서 검색 결과와 생성한 답을 짝지어 기록하고 품질을 지켜보는 관측 체계가 필요합니다.

AI 에이전트에서도 RAG를 쓰나요?

씁니다. 다만 RAG는 에이전트가 쓰는 여러 도구 가운데 하나입니다. RAG가 자료를 찾아 한 번에 답하는 단일 동작이라면, AI 에이전트는 목표를 받아 스스로 계획을 세우고 검색·API 호출·계산 같은 도구를 여러 번 갈아 쓰며 여러 스텝으로 일을 처리합니다. 이때 언제 무엇을 검색할지를 에이전트가 스스로 판단하도록 만든 방식을 에이전틱 RAG(agentic RAG)라고 부르기도 합니다. 스텝이 늘고 도구를 오가는 만큼 어디서 답이 어긋났는지 짚어내기는 더 어려워지는데, 그래서 관측의 단위도 한 번의 호출에서 대화로, 다시 에이전트의 실행 흐름 전체로 넓어집니다.

‍

마치며

LLM은 애초에 모르는 것을 그럴듯하게 지어냅니다. RAG는 그 환각을 줄이려고 답을 실제 근거에 연결하는 방법이지만, 검색이 어긋나거나 모델이 근거를 벗어나면 여전히 틀린 답이 나옵니다. RAG만으로 답변의 신뢰성이 보장되지는 않습니다. 검색이 잘됐는지, 답이 실제 근거에 충실한지를 계속 확인해야만 RAG의 효과를 제대로 얻을 수 있습니다.

그래서 운영 환경에서는 어떤 문서가 검색됐고, 답이 실제 근거와 얼마나 일치하는지, 환각과 토큰 비용은 어떻게 변하는지를 함께 관측하는 LLM 옵저버빌리티가 중요합니다.

관련해서 와탭은 LLM 애플리케이션의 프롬프트·응답·토큰·품질을 추적하는 LLM Observability를 제공합니다. 자세한 내용은 LLM Observability 소개 (와탭 공식 문서)에서 확인할 수 있습니다.

‍

더 읽을거리

Ellen

Technical Writer, WhaTap

와탭랩스(WhaTap)에서 기술 콘텐츠를 기획하고 작성하는 엔지니어로 일하고 있습니다.