
RAG 완전 이해: LLM은 왜 거짓말을 하고, 검색은 어떻게 이를 바로잡는가
1000권을 외운 천재가 왜 어제 환율을 틀리는지, 그리고 '답하기 전에 먼저 찾아봐'라는 단순한 아이디어가 어떻게 AI의 가장 중요한 아키텍처 패턴이 되었는지를 논문과 사례로 풀어본다.

1000권을 외운 천재가 왜 어제 환율을 틀리는지, 그리고 '답하기 전에 먼저 찾아봐'라는 단순한 아이디어가 어떻게 AI의 가장 중요한 아키텍처 패턴이 되었는지를 논문과 사례로 풀어본다.
한 가지 사고 실험을 해보자.
당신 앞에 천재가 한 명 있다. 이 사람은 지난 수십 년간 출판된 책 1000권을 통째로 읽고 기억하고 있다. 역사, 과학, 법률, 의학 — 분야를 가리지 않는다. 어떤 질문을 해도 자신 있게, 유창하게, 그럴듯한 답변을 내놓는다.
그런데 이 천재에게 이렇게 물어보면 어떻게 될까?
"어제 원/달러 환율이 얼마였어?"
천재는 잠시도 머뭇거리지 않고 답한다. "1,285원입니다." 자신감 넘치는 목소리로. 하지만 실제로는 1,342원이었다. 이 천재는 자기가 틀렸다는 사실조차 모른다. 왜? 1000권의 책 어디에도 "어제" 환율은 없었으니까.
이것이 바로 대규모 언어 모델(LLM)의 근본적인 한계다. GPT, Claude, Gemini — 이름이 무엇이든, 이들은 학습 시점까지의 방대한 텍스트를 "기억"하고 있는 천재다. 하지만 학습 이후에 일어난 일, 특정 조직의 내부 문서, 실시간으로 변하는 데이터에 대해서는 자신 있게 틀린 답을 생성한다.
이 문제를 해결하기 위해 등장한 것이 RAG(Retrieval-Augmented Generation) — "답하기 전에 먼저 관련 자료를 찾아보게 하자"라는, 놀라울 정도로 단순하지만 강력한 아이디어다.
RAG가 왜 필요한지 이해하려면, 먼저 LLM이 만들어낸 "그럴듯한 거짓말"의 실제 사례를 봐야 한다.
사례 1: 존재하지 않는 판례를 인용한 변호사
2023년 6월, 뉴욕의 변호사 스티븐 슈워츠는 항공사를 상대로 한 소송에서 ChatGPT가 생성한 법률 브리프를 법원에 제출했다. 문제는 브리프에 인용된 판례 6건이 모두 존재하지 않았다는 것이다. Varghese v. China Southern Airlines, Martinez v. Delta Air Lines 등 — 실제 항공사 이름과 그럴듯한 사건번호까지 갖추고 있었지만, 법원 데이터베이스 어디에도 없는 판례들이었다. 슈워츠 변호사는 법원으로부터 5,000달러의 벌금을 부과받았다.
사례 2: 유령 논문의 양산
학술 분야에서도 같은 문제가 발생했다. 연구자들이 LLM에게 "양자 컴퓨팅의 최근 발전에 대한 참고문헌을 추천해줘"라고 요청하면, 모델은 실제 저자 이름과 실제 학술지 이름을 조합해 존재하지 않는 논문을 만들어낸다. 저자는 실재하고, 학술지도 실재하지만, 그 조합으로 된 논문은 세상에 없다. 2024년 Nature에 발표된 조사에 따르면, ChatGPT가 생성한 학술 참고문헌의 상당수가 이런 "유령 논문"이었다.
사례 3: 자신감 넘치는 오답
ChatGPT에게 "대한민국의 현재 기준금리는?"이라고 물으면, 학습 데이터 시점의 금리를 마치 현재 정보인 것처럼 답변한다. 금리가 3.5%였을 때 학습된 모델은 이미 금리가 변동된 후에도 "현재 기준금리는 3.5%입니다"라고 자신 있게 답한다. "모르겠습니다"라고 하지 않는다는 것이 핵심이다.
이 현상을 이해하려면 LLM의 작동 원리를 알아야 한다. LLM은 본질적으로 **"다음에 올 가장 그럴듯한 단어를 예측하는 기계"**다.
"대한민국의 수도는"이라는 텍스트가 주어지면, 학습 데이터에서 이 패턴 다음에 가장 많이 등장한 단어 — "서울" — 을 출력한다. 이것은 사실을 "알고" 있어서가 아니라, 통계적으로 가장 가능성 높은 다음 토큰을 생성한 것이다.
이 구조가 만들어내는 세 가지 근본적 한계:
| 한계 | 설명 | 비유 |
|---|---|---|
| 학습 데이터 컷오프 | 학습 시점 이후 정보를 알 수 없음 | 2023년에 졸업한 학생에게 2026년 뉴스를 묻는 것 |
| 롱테일 지식 부정확 | 드물게 등장한 정보일수록 부정확 | 1000권 읽었지만 한 번만 나온 사실은 기억이 흐릿 |
| 출처 추적 불가 | 답변의 근거를 제시할 수 없음 | "어디서 읽었는지는 모르겠는데 확실해" |
AI 연구자들은 이 현상을 **환각(Hallucination)**이라고 부른다. 모델이 사실이 아닌 내용을 마치 사실인 것처럼 자신 있게 생성하는 현상이다.
LLM이 가진 지식은 **파라메트릭 지식(parametric knowledge)**이라고 부른다. 수십억 개의 가중치(파라미터)에 학습 데이터의 패턴이 압축되어 저장된 형태다. 마치 천재가 1000권을 읽고 자기 뇌에 기억한 것과 같다.
하지만 세상에는 파라미터에 담기지 않는 지식이 너무 많다:
이 문제를 해결하려는 시도는 크게 두 가지 방향이었다:
2020년, Facebook AI Research(현 Meta AI)의 Patrick Lewis 등이 획기적인 논문을 발표한다.
"Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" (지식 집약적 NLP 태스크를 위한 검색 증강 생성)
이 논문의 핵심 아이디어는 놀라울 정도로 직관적이다:
"언어 모델이 답을 생성하기 전에, 먼저 외부 지식 저장소에서 관련 문서를 검색(retrieve)하고, 그 문서를 참고하여(augmented) 답변을 생성(generation)하게 하자."
앞서 비유한 천재에게 이렇게 말하는 것과 같다:
"네가 아는 것만으로 답하지 마. 답하기 전에 먼저 자료실에 가서 관련 문서를 찾아봐. 그 문서를 읽은 다음에 답해."
Lewis 등은 이 아키텍처를 **RAG(Retrieval-Augmented Generation)**라고 이름 붙였다. 이름 자체가 작동 원리를 설명한다:
Lewis 등의 실험 결과는 인상적이었다. RAG는 오픈 도메인 질의응답(Open-Domain QA)에서 기존의 순수 파라메트릭 모델(당시 BART)을 크게 앞섰고, 심지어 각 태스크에 특화된 모델들과도 대등하거나 더 나은 성능을 보였다.
특히 중요한 발견은 이것이었다: 모델을 재학습시키지 않고도, 외부 지식 저장소만 업데이트하면 모델의 답변이 달라진다. 천재의 뇌를 다시 훈련시킬 필요 없이, 자료실의 책만 바꿔주면 되는 것이다.
RAG가 "최종 답"처럼 등장한 것은 아니다. 그 전에도 LLM의 지식 한계를 극복하려는 시도들이 있었다.
특정 도메인의 데이터로 모델을 추가 학습시키는 방법이다. 예를 들어, 법률 문서 수만 건으로 GPT를 추가 학습시켜 "법률 전문 GPT"를 만드는 식이다.
문제:
"아래 문서를 참고해서 답해줘"라고 프롬프트에 직접 문서를 붙여넣는 방법이다.
문제:
RAG는 파인튜닝의 "도메인 지식 활용"과 프롬프트 엔지니어링의 "외부 문서 참조"를 결합하되, 둘의 단점을 우회한다:
| 방법 | 지식 업데이트 | 비용 | 출처 제공 |
|---|---|---|---|
| 순수 LLM | 재학습 필요 | 높음 | 불가 |
| 파인튜닝 | 재학습 필요 | 중간 | 불가 |
| 프롬프트 엔지니어링 | 즉시 가능 | 토큰 비용 높음 | 가능 |
| RAG | 즉시 가능 | 효율적 | 가능 |
RAG의 작동 과정은 세 단계로 나뉜다. 각 단계를 하나씩 뜯어보자.
사용자가 질문을 하면, 시스템은 먼저 **외부 지식 저장소(knowledge base)**에서 질문과 관련된 문서를 검색한다.
핵심은 "키워드 검색"이 아니라 **"의미 검색(semantic search)"**이라는 점이다. 이것은 5장에서 자세히 다룬다.
검색된 문서 조각들을 사용자의 원래 질문과 함께 LLM에게 전달할 프롬프트에 삽입한다. 실제로는 이런 형태가 된다:
이제 LLM은 "기억"이 아니라 **"참고자료"**에 기반해서 답변한다.
LLM은 주입된 컨텍스트를 읽고, 그에 기반한 답변을 생성한다. 이때 중요한 차이가 생긴다:
개념을 코드로 표현하면 RAG의 구조가 더 명확해진다:
def rag_pipeline(question: str) -> str:
# ① Retrieve: 질문과 관련된 문서를 검색
relevant_docs = vector_store.search(
query=question,
top_k=3 # 가장 관련도 높은 문서 3개
)
# ② Augment: 검색된 문서를 프롬프트에 삽입
context = "\n\n".join([doc.text for doc in relevant_docs])
prompt = f"""아래 컨텍스트를 참고하여 질문에 답하세요.
컨텍스트:
{context}
질문: {question}
"""
# ③ Generate: LLM이 컨텍스트 기반으로 답변 생성
answer = llm.generate(prompt)
return answer
이 코드에서 vector_store.search()가 어떻게 "의미적으로 관련된 문서"를 찾는지가 RAG의 핵심이다.
"우리 회사 재택근무 정책이 뭐야?"라는 질문을 생각해보자.
전통적인 키워드 검색은 "재택근무", "정책" 같은 단어가 포함된 문서를 찾는다. 하지만 실제 사내 문서에는 이렇게 적혀 있을 수 있다:
"직원은 주 2회 이상 사무실에 출근해야 하며, 나머지 근무일은 원격 근무가 가능합니다."
"재택근무"라는 단어가 없다. "원격 근무"라고 되어 있다. 키워드 검색은 이 문서를 놓친다. 하지만 의미적으로는 완벽하게 관련된 문서다.
이 문제를 해결하는 기술이 **임베딩(embedding)**이다. 임베딩은 텍스트의 "의미"를 고차원 숫자 벡터로 변환한다.
비유하자면 이렇다. 모든 텍스트에 **"의미의 좌표"**를 부여하는 것이다. 의미가 비슷한 텍스트는 좌표가 가깝고, 의미가 다른 텍스트는 좌표가 멀다.
실제로는 수백~수천 차원의 벡터지만, 원리는 동일하다. 의미가 비슷하면 벡터가 가깝고, 다르면 멀다.
두 벡터가 얼마나 가까운지를 측정하는 가장 대표적인 방법이 **코사인 유사도(cosine similarity)**다. 두 벡터가 이루는 각도가 작을수록(같은 방향을 가리킬수록) 유사도가 1에 가까워진다.
수백만 개의 문서 벡터 중에서 질문 벡터와 가장 가까운 것을 빠르게 찾아야 한다. 이 역할을 하는 것이 **벡터 데이터베이스(vector database)**다.
Pinecone, Weaviate, Milvus, Chroma, Qdrant 등이 대표적이며, 이들은 근사 최근접 이웃(ANN, Approximate Nearest Neighbor) 알고리즘을 사용해 수백만 벡터 중에서도 밀리초 단위로 유사한 문서를 찾아낸다.
같은 질문에 대해 순수 LLM과 RAG를 적용한 결과를 비교해보자.
질문: "우리 회사 연차 사용 규정이 어떻게 되나요?"
순수 LLM의 답변:
"일반적으로 한국 근로기준법에 따르면, 1년 이상 근무한 근로자에게 15일의 유급휴가가 부여됩니다. 3년 이상 근무 시 2년마다 1일이 가산됩니다..."
→ 법률 일반론은 맞지만, **"우리 회사"**의 규정에 대해서는 답하지 못한다.
RAG 적용 답변 (사내 규정집을 지식 저장소에 포함):
"당사의 연차 규정에 따르면, 입사 첫 해에는 월 1일씩 발생하며, 2년차부터 연 17일이 부여됩니다. 특이사항으로, 분기별 미사용 연차 3일까지는 다음 분기로 이월 가능합니다. (출처: 2026년 인사규정 제24조)"
→ 우리 회사의 구체적 규정을 출처와 함께 답변한다.
질문: "2026년 1분기 AI 시장 전망은?"
순수 LLM의 답변:
"2024년 기준 글로벌 AI 시장은 약 1,840억 달러 규모로 추정되며..."
→ 학습 시점의 오래된 데이터를 현재 정보인 것처럼 제시한다.
RAG 적용 답변 (최신 리포트를 지식 저장소에 포함):
"IDC의 2026년 1월 보고서에 따르면, 글로벌 AI 시장은 2025년에 전년 대비 36.6% 성장했으며, 2026년 1분기에는 특히 에이전트 AI 인프라 분야에서 급성장이 예상됩니다. (출처: IDC Worldwide AI Spending Guide, Jan 2026)"
→ 최신 데이터를 출처와 함께 제시한다.
질문: "우리 프로젝트에서 사용하는 인증 미들웨어는 어떻게 설정하나요?"
순수 LLM의 답변:
"일반적으로 Express.js에서 JWT 인증 미들웨어를 설정하려면 passport-jwt 패키지를 사용할 수 있습니다..."
→ 일반적인 답변. 실제 프로젝트와 무관할 수 있다.
RAG 적용 답변 (프로젝트 코드베이스를 지식 저장소에 포함):
"이 프로젝트는 Clerk(
@clerk/nextjs)을 사용합니다.src/middleware.ts에서clerkMiddleware()로 보호 경로를 설정하고 있으며, 한국어 로컬라이제이션은@clerk/localizations의koKR을 사용합니다."
→ 실제 프로젝트의 구체적인 구현을 정확히 답변한다.
Lewis et al.의 2020년 논문 이후, RAG는 빠르게 발전했다. 주요 이정표를 짚어보자.
DeepMind의 RETRO(Retrieval-Enhanced Transformer)는 학습 단계에서부터 검색을 통합했다. 기존 RAG가 "추론 시"에만 검색을 활용한 반면, RETRO는 모델 학습 자체에 검색 메커니즘을 녹여냈다. 결과적으로, 25배 적은 파라미터로 GPT-3에 준하는 성능을 달성했다.
모든 질문에 검색이 필요한 것은 아니다. "1+1은?"에는 검색이 불필요하지만, "어제 삼성전자 주가는?"에는 필수적이다. Self-RAG는 모델이 스스로 **"이 질문에 검색이 필요한가?"**를 판단하게 했다. 불필요한 검색을 줄여 효율성을 높이고, 검색 결과의 신뢰도까지 자체 평가하는 구조다.
검색된 문서가 항상 관련성이 높은 것은 아니다. CRAG(Corrective RAG)는 검색 결과를 한 번 더 평가하는 단계를 추가했다. 검색 결과가 부적절하면 웹 검색으로 보완하거나, 관련 없는 문서를 걸러내는 자기 교정 메커니즘을 도입했다.
이 흐름이 보여주는 방향은 명확하다: RAG는 단순한 "검색 → 생성" 파이프라인에서, 스스로 판단하고 교정하는 지능적 시스템으로 진화하고 있다.
RAG의 핵심 가치를 한 문장으로 요약하면 이렇다:
RAG는 LLM을 "더 똑똑하게" 만드는 기술이 아니라, "더 정직하게" 만드는 기술이다.
LLM이 모르는 것을 아는 척하는 대신, 관련 자료를 먼저 찾아보고, 그에 기반해 답변하고, 출처까지 밝히게 만든다. 이것은 기술적 개선을 넘어 AI 신뢰성의 근본적인 전환이다.
AI가 "그럴듯하게 말하는 기계"에서 "근거를 가지고 답하는 도구"로 변하는 과정 — 그 중심에 RAG가 있다. 2020년 Lewis et al.의 논문에서 시작된 이 아이디어는, 불과 6년 만에 AI 애플리케이션의 가장 기본적인 아키텍처 패턴이 되었다.
다음 글에서는 기본 RAG의 한계를 극복하는 Advanced RAG 기법들 — 청킹 전략, 리랭킹, 하이브리드 검색 — 을 다뤄보겠다.
참고 논문 및 자료