[LLM] LLM 환각을 줄이는 방법, RAG 쉽게 이해하기

ChatGPT나 Claude 같은 LLM에게 회사 내부 규정이나 어제 나온 뉴스를 물어보면 엉뚱한 답이 돌아오는 경우가 많습니다. LLM은 학습할 때 본 데이터만 알고, 모르는 내용도 그럴듯하게 지어내는 '환각' 문제가 있기 때문입니다. 이 문제를 해결하는 가장 대표적인 방법이 RAG(Retrieval-Augmented Generation, 검색 증강 생성)입니다. 이 글에서는 RAG의 개념과 동작 과정, 성능을 높이는 기법, 파인튜닝과의 차이와 도입 시 주의할 점까지 정리해 보겠습니다.

 

RAG란 무엇인가요?

RAG는 이름 그대로 검색(Retrieval)으로 생성(Generation)을 보강(Augmented)하는 방식입니다. LLM이 답변을 만들기 전에 질문과 관련된 문서를 먼저 찾아오고, 그 문서를 질문과 함께 LLM에게 넘겨서 "이 자료를 근거로 답해 줘"라고 요청하는 구조입니다.

쉽게 비유하면, 기억에만 의존해 시험을 보던 학생에게 오픈북 시험을 허용하는 것과 같습니다. 모델 자체를 다시 학습시키지 않아도 최신 정보나 사내 문서를 바탕으로 답할 수 있게 됩니다. 이 개념은 2020년 Meta AI(당시 Facebook AI Research) 연구진의 논문에서 RAG라는 이름으로 소개되었고, 지금은 사내 문서 챗봇, 고객센터 상담봇, 기술 문서 검색 도우미 등에 널리 쓰이고 있습니다.

RAG의 주요 장점은 다음과 같습니다.

• 최신 정보 반영: 문서만 업데이트하면 모델을 다시 학습시키지 않아도 새 정보로 답합니다.
• 출처 제시: 어떤 문서를 근거로 답했는지 함께 보여 줄 수 있어 검증이 쉽습니다.
• 환각 감소: 근거 자료가 주어지기 때문에 지어낸 답이 줄어듭니다.
• 비용 절감: 대규모 재학습 없이 기존 LLM을 그대로 활용할 수 있습니다.

 

RAG는 어떻게 동작하나요?

RAG는 크게 미리 준비하는 단계(인덱싱)와 질문이 들어왔을 때 처리하는 단계(검색·생성)로 나뉩니다.

단계	하는 일
① 인덱싱 (미리 준비)
문서 수집	PDF, 웹페이지, 위키, DB 등 답변 근거가 될 자료를 모읍니다.
청킹 (Chunking)	긴 문서를 검색하기 좋은 크기의 조각(청크)으로 나눕니다.
임베딩 (Embedding)	각 청크를 의미를 담은 숫자 벡터로 바꿉니다. 뜻이 비슷한 문장은 비슷한 벡터가 됩니다.
저장	벡터와 원문을 벡터 데이터베이스에 저장합니다.
② 검색·생성 (질문할 때마다)
질문 임베딩	사용자 질문도 같은 방식으로 벡터로 바꿉니다.
검색 (Retrieval)	질문 벡터와 가장 가까운 청크 몇 개를 찾아옵니다.
프롬프트 구성	찾은 청크와 질문을 합쳐 LLM에게 보낼 입력을 만듭니다.
생성 (Generation)	LLM이 주어진 자료를 근거로 답변을 작성합니다.

흐름을 간단한 의사 코드로 표현하면 다음과 같습니다.

# 1) 인덱싱: 한 번만 (문서가 바뀌면 다시)
chunks  = split(documents, size=500, overlap=50)
vectors = embed(chunks)
vector_db.save(vectors, chunks)

# 2) 질문 처리: 질문이 들어올 때마다
q_vec   = embed(question)
context = vector_db.search(q_vec, top_k=5)
prompt  = "아래 자료만 근거로 답하고, 모르면 모른다고 답하세요.\n"
          + context + "\n질문: " + question
answer  = llm.generate(prompt)

프롬프트에 "자료에 없으면 모른다고 답하라"는 지시를 넣어 두는 것도 환각을 줄이는 간단하면서 효과적인 방법입니다.

 

RAG 성능을 높이는 핵심 기법

기본 RAG를 만들기는 어렵지 않지만, 실제 서비스 품질은 대부분 "필요한 문서를 제대로 찾아오느냐"에서 갈립니다. 자주 쓰이는 개선 기법을 정리해 보겠습니다.

• 청킹 전략 다듬기: 무조건 글자 수로 자르기보다 제목, 문단, 표 같은 문서 구조를 기준으로 나누면 의미가 덜 끊깁니다. 청크 사이를 조금 겹치게(overlap) 하면 경계에 걸친 내용을 놓치는 일이 줄어듭니다.
• 메타데이터 활용: 청크마다 문서 제목, 작성일, 부서 같은 정보를 붙여 두면 "2026년 규정만"처럼 조건을 걸어 검색할 수 있습니다.
• 문맥 보강 청크: 청크 하나만 떼어 보면 "이 조항은 위와 같다"처럼 무슨 내용인지 알 수 없는 경우가 있습니다. 임베딩 전에 청크 앞에 "어느 문서의 어떤 부분인지" 짧은 설명을 붙이면 검색 정확도가 올라갑니다.
• 하이브리드 검색: 의미 기반 벡터 검색은 비슷한 뜻을 잘 찾지만, 제품 코드나 고유명사 같은 정확한 단어 매칭에는 약합니다. 전통적인 키워드 검색(BM25 등)과 함께 쓰고 결과를 합치면 두 방식의 약점을 서로 보완할 수 있습니다.
• 리랭킹 (Re-ranking): 1차 검색으로 후보를 넉넉히 가져온 뒤, 질문과 문서를 함께 보고 관련도를 더 정밀하게 매기는 모델로 순서를 다시 정합니다. 상위 몇 개만 LLM에 넘기면 품질과 비용을 함께 잡을 수 있습니다.
• 질문 재작성: 사용자의 짧거나 모호한 질문을 LLM이 검색하기 좋은 형태로 다시 쓰거나, 여러 개의 하위 질문으로 나눠 검색하는 방법입니다.

최근에는 구조를 확장한 변형도 많이 쓰입니다. GraphRAG는 문서에서 인물, 제품, 조직 같은 개체와 그 관계를 뽑아 지식 그래프로 만든 뒤, 연결 관계를 따라가며 검색합니다. 여러 문서에 흩어진 사실을 이어야 답할 수 있는 질문에 유리합니다. 에이전틱 RAG(Agentic RAG)는 정해진 순서대로만 검색하지 않고, LLM이 스스로 어떤 자료를 언제 몇 번 검색할지 판단하며 단계적으로 답을 찾아가는 방식입니다. 다만 이런 고급 기법은 비용과 복잡도가 함께 올라가므로, 기본 RAG의 한계를 확인한 뒤 필요한 경우에 도입하는 것을 추천합니다.

 

RAG vs 파인튜닝, 그리고 도입 시 주의할 점

LLM에 우리 데이터를 반영하는 또 다른 방법으로 파인튜닝(Fine-tuning)이 있습니다. 두 방식은 목적이 다릅니다.

구분	RAG	파인튜닝
바꾸는 대상	모델에 넣는 입력(자료)	모델 자체(가중치)
잘하는 것	최신·사내 지식 반영, 출처 제시	말투, 출력 형식, 특정 작업 능력 학습
정보 업데이트	문서만 교체하면 즉시 반영	다시 학습해야 반영
초기 비용	상대적으로 낮음	학습 데이터 준비와 학습 비용 필요

정리하면 "무엇을 알고 답할지"는 RAG, "어떻게 답할지"는 파인튜닝이 맡는다고 보면 됩니다. 실무에서는 두 가지를 함께 쓰는 경우도 많습니다.

RAG를 도입할 때는 다음 사항을 꼭 확인하세요.

• RAG도 환각을 완전히 없애지는 못합니다. 검색이 엉뚱한 문서를 가져오면 LLM은 그 문서를 근거로 틀린 답을 자신 있게 말합니다.
• 검색과 답변을 나눠서 평가하세요. "정답이 담긴 문서를 찾아왔는가(검색 품질)"와 "찾은 자료에 충실하게 답했는가(생성 품질)"를 따로 측정해야 어디를 고칠지 알 수 있습니다. 실제 사용자 질문으로 정답 세트를 만들어 두고 변경할 때마다 테스트하는 것을 추천합니다.
• 많이 넣는다고 좋아지지 않습니다. 관련 없는 청크까지 잔뜩 넣으면 비용과 응답 시간이 늘고, 정작 중요한 내용이 묻힐 수 있습니다.
• 권한과 보안을 챙기세요. 사내 문서를 다룬다면 사용자가 볼 권한이 없는 문서가 검색 결과로 노출되지 않도록 접근 권한을 검색 단계에 반영해야 합니다.
• 문서 품질이 곧 답변 품질입니다. 오래되거나 서로 모순되는 문서가 섞여 있으면 답변도 흔들립니다. 문서 정리와 주기적인 업데이트가 중요합니다.

 

정리

RAG는 LLM이 답하기 전에 관련 자료를 검색해서 근거로 삼게 하는 방식으로, 모델을 다시 학습시키지 않고도 최신 정보와 사내 지식을 반영하고 출처까지 제시할 수 있습니다. 기본 구조는 문서를 청크로 나누고 임베딩해 저장한 뒤, 질문이 오면 관련 청크를 찾아 LLM에게 함께 넘기는 것입니다. 품질은 대부분 검색 단계에서 결정되므로 청킹, 하이브리드 검색, 리랭킹 같은 기법으로 검색을 먼저 다듬고, 검색과 답변을 나눠 평가하면서 개선해 나가세요.

 

참고자료

• Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" (2020): https://arxiv.org/abs/2005.11401
• Barnett et al., "Seven Failure Points When Engineering a Retrieval Augmented Generation System" (2024): https://arxiv.org/abs/2401.05856
• Edge et al., "From Local to Global: A Graph RAG Approach to Query-Focused Summarization" (2024): https://arxiv.org/abs/2404.16130
• Es et al., "Ragas: Automated Evaluation of Retrieval Augmented Generation" (2023): https://arxiv.org/abs/2309.15217
• Liu et al., "Lost in the Middle: How Language Models Use Long Contexts" (2023): https://arxiv.org/abs/2307.03172
• Anthropic, "Contextual Retrieval in AI Systems": https://www.anthropic.com/news/contextual-retrieval
• Elastic, "RAG(검색 증강 생성)이란?": https://www.elastic.co/kr/what-is/retrieval-augmented-generation