coredot.today
RAG 완전 이해: LLM은 왜 거짓말을 하고, 검색은 어떻게 이를 바로잡는가
블로그로 돌아가기
RAGLLM벡터 검색임베딩환각

RAG 완전 이해: LLM은 왜 거짓말을 하고, 검색은 어떻게 이를 바로잡는가

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

코어닷투데이2026-03-0433

들어가며: 1000권을 외운 천재의 함정

한 가지 사고 실험을 해보자.

당신 앞에 천재가 한 명 있다. 이 사람은 지난 수십 년간 출판된 책 1000권을 통째로 읽고 기억하고 있다. 역사, 과학, 법률, 의학 — 분야를 가리지 않는다. 어떤 질문을 해도 자신 있게, 유창하게, 그럴듯한 답변을 내놓는다.

그런데 이 천재에게 이렇게 물어보면 어떻게 될까?

"어제 원/달러 환율이 얼마였어?"

천재는 잠시도 머뭇거리지 않고 답한다. "1,285원입니다." 자신감 넘치는 목소리로. 하지만 실제로는 1,342원이었다. 이 천재는 자기가 틀렸다는 사실조차 모른다. 왜? 1000권의 책 어디에도 "어제" 환율은 없었으니까.

이것이 바로 대규모 언어 모델(LLM)의 근본적인 한계다. GPT, Claude, Gemini — 이름이 무엇이든, 이들은 학습 시점까지의 방대한 텍스트를 "기억"하고 있는 천재다. 하지만 학습 이후에 일어난 일, 특정 조직의 내부 문서, 실시간으로 변하는 데이터에 대해서는 자신 있게 틀린 답을 생성한다.

이 문제를 해결하기 위해 등장한 것이 RAG(Retrieval-Augmented Generation) — "답하기 전에 먼저 관련 자료를 찾아보게 하자"라는, 놀라울 정도로 단순하지만 강력한 아이디어다.


1. LLM은 왜 "그럴듯한 거짓말"을 하는가

실제로 일어난 일들

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%입니다"라고 자신 있게 답한다. "모르겠습니다"라고 하지 않는다는 것이 핵심이다.

왜 이런 일이 일어나는가: Next-Token Prediction의 본질

이 현상을 이해하려면 LLM의 작동 원리를 알아야 한다. LLM은 본질적으로 **"다음에 올 가장 그럴듯한 단어를 예측하는 기계"**다.

"대한민국의 수도는"이라는 텍스트가 주어지면, 학습 데이터에서 이 패턴 다음에 가장 많이 등장한 단어 — "서울" — 을 출력한다. 이것은 사실을 "알고" 있어서가 아니라, 통계적으로 가장 가능성 높은 다음 토큰을 생성한 것이다.

Next-Token Prediction
INPUT "대한민국의 수도는"
확률 분포 계산
"서울"
0.92
"부산"
0.03
"인천"
0.01
OUTPUT "서울"

이 구조가 만들어내는 세 가지 근본적 한계:

한계설명비유
학습 데이터 컷오프학습 시점 이후 정보를 알 수 없음2023년에 졸업한 학생에게 2026년 뉴스를 묻는 것
롱테일 지식 부정확드물게 등장한 정보일수록 부정확1000권 읽었지만 한 번만 나온 사실은 기억이 흐릿
출처 추적 불가답변의 근거를 제시할 수 없음"어디서 읽었는지는 모르겠는데 확실해"

AI 연구자들은 이 현상을 **환각(Hallucination)**이라고 부른다. 모델이 사실이 아닌 내용을 마치 사실인 것처럼 자신 있게 생성하는 현상이다.


2. "검색해서 읽고 답하면 되잖아" — RAG의 탄생

문제 인식: 파라메트릭 지식의 한계

LLM이 가진 지식은 **파라메트릭 지식(parametric knowledge)**이라고 부른다. 수십억 개의 가중치(파라미터)에 학습 데이터의 패턴이 압축되어 저장된 형태다. 마치 천재가 1000권을 읽고 자기 뇌에 기억한 것과 같다.

하지만 세상에는 파라미터에 담기지 않는 지식이 너무 많다:

  • 어제 올라온 사내 공지
  • 지난주 업데이트된 API 문서
  • 오늘 아침 발표된 경제 지표
  • 우리 회사만의 내부 규정집

이 문제를 해결하려는 시도는 크게 두 가지 방향이었다:

  1. 모델을 더 자주 재학습시키자 → 비용이 천문학적이고, 시간도 오래 걸림
  2. 모델에게 외부 지식을 참고할 수 있게 해주자 → 이것이 RAG

Lewis et al., 2020: RAG 논문의 등장

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)**라고 이름 붙였다. 이름 자체가 작동 원리를 설명한다:

  • Retrieval — 관련 문서를 검색한다
  • Augmented — 검색된 문서로 입력을 증강한다
  • Generation — 증강된 입력을 바탕으로 답변을 생성한다

논문이 증명한 것

Lewis 등의 실험 결과는 인상적이었다. RAG는 오픈 도메인 질의응답(Open-Domain QA)에서 기존의 순수 파라메트릭 모델(당시 BART)을 크게 앞섰고, 심지어 각 태스크에 특화된 모델들과도 대등하거나 더 나은 성능을 보였다.

특히 중요한 발견은 이것이었다: 모델을 재학습시키지 않고도, 외부 지식 저장소만 업데이트하면 모델의 답변이 달라진다. 천재의 뇌를 다시 훈련시킬 필요 없이, 자료실의 책만 바꿔주면 되는 것이다.


3. RAG 이전의 시도들: 왜 다른 방법은 부족했나

RAG가 "최종 답"처럼 등장한 것은 아니다. 그 전에도 LLM의 지식 한계를 극복하려는 시도들이 있었다.

파인튜닝(Fine-tuning)

특정 도메인의 데이터로 모델을 추가 학습시키는 방법이다. 예를 들어, 법률 문서 수만 건으로 GPT를 추가 학습시켜 "법률 전문 GPT"를 만드는 식이다.

문제:

  • 새로운 정보가 추가될 때마다 재학습 필요 (비용 수천~수만 달러)
  • 학습 데이터가 바뀌면 이전 지식을 "잊어버리는" 파국적 망각(catastrophic forgetting) 발생
  • 여전히 출처를 제시하지 못함

프롬프트 엔지니어링

"아래 문서를 참고해서 답해줘"라고 프롬프트에 직접 문서를 붙여넣는 방법이다.

문제:

  • LLM의 **컨텍스트 윈도우(context window)**에 한계가 있음 — 수만 페이지의 문서를 다 넣을 수 없음
  • 어떤 문서를 넣어야 할지 사람이 직접 선택해야 함
  • 문서가 많아지면 비용이 기하급수적으로 증가

RAG가 이 둘의 장점을 취한 방식

RAG는 파인튜닝의 "도메인 지식 활용"과 프롬프트 엔지니어링의 "외부 문서 참조"를 결합하되, 둘의 단점을 우회한다:

방법지식 업데이트비용출처 제공
순수 LLM재학습 필요높음불가
파인튜닝재학습 필요중간불가
프롬프트 엔지니어링즉시 가능토큰 비용 높음가능
RAG즉시 가능효율적가능

4. RAG는 어떻게 작동하는가 — 3단계 파이프라인

RAG의 작동 과정은 세 단계로 나뉜다. 각 단계를 하나씩 뜯어보자.

사용자 질문 ① Retrieve (검색) ② Augment (증강) ③ Generate (생성) 답변

① Retrieve — "관련 문서를 찾아라"

사용자가 질문을 하면, 시스템은 먼저 **외부 지식 저장소(knowledge base)**에서 질문과 관련된 문서를 검색한다.

핵심은 "키워드 검색"이 아니라 **"의미 검색(semantic search)"**이라는 점이다. 이것은 5장에서 자세히 다룬다.

② Augment — "프롬프트에 문서를 끼워넣어라"

검색된 문서 조각들을 사용자의 원래 질문과 함께 LLM에게 전달할 프롬프트에 삽입한다. 실제로는 이런 형태가 된다:

RAG Augmented Prompt
시스템 프롬프트
아래 컨텍스트를 참고하여 사용자의 질문에 답하세요. 답변은 컨텍스트에 기반해야 하며, 컨텍스트에 없는 내용은 "알 수 없습니다"라고 답하세요.
컨텍스트 — 검색된 문서들
문서 1: "2026년 3월 19일 기준 원/달러 환율은 1,342원으로 전일 대비 5원 하락했다..."
문서 2: "한국은행은 3월 기준금리를 3.25%로 동결한다고 발표했다..."
사용자 질문
어제 원/달러 환율이 얼마였어?

이제 LLM은 "기억"이 아니라 **"참고자료"**에 기반해서 답변한다.

③ Generate — "문서를 참고하여 답변을 생성하라"

LLM은 주입된 컨텍스트를 읽고, 그에 기반한 답변을 생성한다. 이때 중요한 차이가 생긴다:

  • RAG 없이: "원/달러 환율은 약 1,285원입니다." (학습 시점의 부정확한 기억)
  • RAG 적용: "2026년 3월 19일 기준 원/달러 환율은 1,342원이며, 전일 대비 5원 하락했습니다." (검색된 문서 기반)

전체 파이프라인을 코드로 보면

개념을 코드로 표현하면 RAG의 구조가 더 명확해진다:

hljs language-python
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의 핵심이다.


5. "검색"의 핵심 — 임베딩과 벡터 검색

키워드 검색의 한계

"우리 회사 재택근무 정책이 뭐야?"라는 질문을 생각해보자.

전통적인 키워드 검색은 "재택근무", "정책" 같은 단어가 포함된 문서를 찾는다. 하지만 실제 사내 문서에는 이렇게 적혀 있을 수 있다:

"직원은 주 2회 이상 사무실에 출근해야 하며, 나머지 근무일은 원격 근무가 가능합니다."

"재택근무"라는 단어가 없다. "원격 근무"라고 되어 있다. 키워드 검색은 이 문서를 놓친다. 하지만 의미적으로는 완벽하게 관련된 문서다.

임베딩: 의미를 숫자로 변환하기

이 문제를 해결하는 기술이 **임베딩(embedding)**이다. 임베딩은 텍스트의 "의미"를 고차원 숫자 벡터로 변환한다.

비유하자면 이렇다. 모든 텍스트에 **"의미의 좌표"**를 부여하는 것이다. 의미가 비슷한 텍스트는 좌표가 가깝고, 의미가 다른 텍스트는 좌표가 멀다.

의미의 좌표 — 임베딩 벡터 공간
"재택근무 정책" [0.82, 0.15, 0.43, …] 기준 벡터 (Query)
"원격 근무 가능" [0.79, 0.18, 0.41, …] ← 매우 가까움!
"사무실 출근 규정" [0.75, 0.21, 0.39, …] ← 꽤 가까움
"점심 메뉴 추천" [0.12, 0.87, 0.03, …] ← 멀다!

실제로는 수백~수천 차원의 벡터지만, 원리는 동일하다. 의미가 비슷하면 벡터가 가깝고, 다르면 멀다.

코사인 유사도: "의미적 거리" 측정

두 벡터가 얼마나 가까운지를 측정하는 가장 대표적인 방법이 **코사인 유사도(cosine similarity)**다. 두 벡터가 이루는 각도가 작을수록(같은 방향을 가리킬수록) 유사도가 1에 가까워진다.

코사인 유사도 비교
"재택근무 정책"과의 코사인 유사도 (0 ~ 1)
원격 근무 가능
0.94 ✓ 관련!
사무실 출근 규정
0.87 ✓ 관련
점심 메뉴 추천
0.12 ✗ 무관

벡터 데이터베이스: 수백만 문서에서 순식간에 찾기

수백만 개의 문서 벡터 중에서 질문 벡터와 가장 가까운 것을 빠르게 찾아야 한다. 이 역할을 하는 것이 **벡터 데이터베이스(vector database)**다.

Pinecone, Weaviate, Milvus, Chroma, Qdrant 등이 대표적이며, 이들은 근사 최근접 이웃(ANN, Approximate Nearest Neighbor) 알고리즘을 사용해 수백만 벡터 중에서도 밀리초 단위로 유사한 문서를 찾아낸다.

전체 검색 흐름

RAG 검색 파이프라인
문서 수집 PDF, 웹, DB 등에서 원본 수집
청킹 문서를 적절한 크기로 분할
임베딩 각 청크를 벡터로 변환
벡터 DB 저장 인덱싱하여 검색 가능하게
사용자 질문 자연어 질문 입력
질문 임베딩 질문도 같은 벡터 공간으로
유사도 검색 코사인 유사도로 top-k 문서 반환
LLM에 전달 검색 결과 + 질문 → 답변 생성

6. RAG가 만드는 차이 — Before & After

같은 질문에 대해 순수 LLM과 RAG를 적용한 결과를 비교해보자.

사례 1: 사내 정책 질문

질문: "우리 회사 연차 사용 규정이 어떻게 되나요?"

순수 LLM의 답변:

"일반적으로 한국 근로기준법에 따르면, 1년 이상 근무한 근로자에게 15일의 유급휴가가 부여됩니다. 3년 이상 근무 시 2년마다 1일이 가산됩니다..."

→ 법률 일반론은 맞지만, **"우리 회사"**의 규정에 대해서는 답하지 못한다.

RAG 적용 답변 (사내 규정집을 지식 저장소에 포함):

"당사의 연차 규정에 따르면, 입사 첫 해에는 월 1일씩 발생하며, 2년차부터 연 17일이 부여됩니다. 특이사항으로, 분기별 미사용 연차 3일까지는 다음 분기로 이월 가능합니다. (출처: 2026년 인사규정 제24조)"

우리 회사의 구체적 규정을 출처와 함께 답변한다.

사례 2: 최신 정보 질문

질문: "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)"

최신 데이터를 출처와 함께 제시한다.

사례 3: 기술 문서 질문

질문: "우리 프로젝트에서 사용하는 인증 미들웨어는 어떻게 설정하나요?"

순수 LLM의 답변:

"일반적으로 Express.js에서 JWT 인증 미들웨어를 설정하려면 passport-jwt 패키지를 사용할 수 있습니다..."

→ 일반적인 답변. 실제 프로젝트와 무관할 수 있다.

RAG 적용 답변 (프로젝트 코드베이스를 지식 저장소에 포함):

"이 프로젝트는 Clerk(@clerk/nextjs)을 사용합니다. src/middleware.ts에서 clerkMiddleware()로 보호 경로를 설정하고 있으며, 한국어 로컬라이제이션은 @clerk/localizationskoKR을 사용합니다."

실제 프로젝트의 구체적인 구현을 정확히 답변한다.

세 가지 핵심 이점 정리

RAG의 3가지 핵심 이점
환각 감소 근거 없는 답변 대신 문서 기반 답변
최신 정보 반영 재학습 없이 지식 저장소만 업데이트
출처 제시 답변의 근거 문서를 함께 제공

7. RAG 이후의 연구 흐름

Lewis et al.의 2020년 논문 이후, RAG는 빠르게 발전했다. 주요 이정표를 짚어보자.

RETRO (Borgeaud et al., 2022)

DeepMind의 RETRO(Retrieval-Enhanced Transformer)는 학습 단계에서부터 검색을 통합했다. 기존 RAG가 "추론 시"에만 검색을 활용한 반면, RETRO는 모델 학습 자체에 검색 메커니즘을 녹여냈다. 결과적으로, 25배 적은 파라미터로 GPT-3에 준하는 성능을 달성했다.

Self-RAG (Asai et al., 2023)

모든 질문에 검색이 필요한 것은 아니다. "1+1은?"에는 검색이 불필요하지만, "어제 삼성전자 주가는?"에는 필수적이다. Self-RAG는 모델이 스스로 **"이 질문에 검색이 필요한가?"**를 판단하게 했다. 불필요한 검색을 줄여 효율성을 높이고, 검색 결과의 신뢰도까지 자체 평가하는 구조다.

Corrective RAG (Yan et al., 2024)

검색된 문서가 항상 관련성이 높은 것은 아니다. CRAG(Corrective RAG)는 검색 결과를 한 번 더 평가하는 단계를 추가했다. 검색 결과가 부적절하면 웹 검색으로 보완하거나, 관련 없는 문서를 걸러내는 자기 교정 메커니즘을 도입했다.

이 흐름이 보여주는 방향은 명확하다: RAG는 단순한 "검색 → 생성" 파이프라인에서, 스스로 판단하고 교정하는 지능적 시스템으로 진화하고 있다.


마치며: RAG가 중요한 진짜 이유

RAG의 핵심 가치를 한 문장으로 요약하면 이렇다:

RAG는 LLM을 "더 똑똑하게" 만드는 기술이 아니라, "더 정직하게" 만드는 기술이다.

LLM이 모르는 것을 아는 척하는 대신, 관련 자료를 먼저 찾아보고, 그에 기반해 답변하고, 출처까지 밝히게 만든다. 이것은 기술적 개선을 넘어 AI 신뢰성의 근본적인 전환이다.

AI가 "그럴듯하게 말하는 기계"에서 "근거를 가지고 답하는 도구"로 변하는 과정 — 그 중심에 RAG가 있다. 2020년 Lewis et al.의 논문에서 시작된 이 아이디어는, 불과 6년 만에 AI 애플리케이션의 가장 기본적인 아키텍처 패턴이 되었다.

다음 글에서는 기본 RAG의 한계를 극복하는 Advanced RAG 기법들 — 청킹 전략, 리랭킹, 하이브리드 검색 — 을 다뤄보겠다.


참고 논문 및 자료

  • Lewis, P., et al. (2020). "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks." NeurIPS 2020.
  • Borgeaud, S., et al. (2022). "Improving Language Models by Retrieving from Trillions of Tokens." ICML 2022.
  • Asai, A., et al. (2023). "Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection." NeurIPS 2023.
  • Yan, S., et al. (2024). "Corrective Retrieval Augmented Generation." arXiv preprint.
  • Gao, Y., et al. (2024). "Retrieval-Augmented Generation for Large Language Models: A Survey." arXiv preprint.