ChatGPT 같은 LLM을 처음 써보면 꽤 놀랍습니다. 질문을 자연어로 던지면 사람처럼 답하고, 글도 요약하고, 코드도 작성하고, 복잡한 개념도 설명해 줍니다.
그런데 실무에서 LLM을 바로 서비스에 붙이려고 하면 금방 한계가 보입니다.
예를 들어 회사 직원이 챗봇에게 “올해 우리 회사 재택근무 규정 알려줘”라고 물었다고 해보겠습니다.
LLM은 일반적인 재택근무 제도는 설명할 수 있습니다.
하지만 우리 회사의 최신 내부 규정 문서를 직접 본 적이 없다면, 정확한 답을 보장하기 어렵습니다.
이때 필요한 방식이 바로 RAG입니다. RAG는 LLM이 자기 머릿속 기억만으로 답하게 두는 것이 아니라, 답변하기 전에 관련 문서나 데이터를 먼저 찾아보고 그 근거를 바탕으로 답하게 만드는 구조입니다.
이번 글에서는 실제 RAG 파이프라인을 깊게 들어가기 전에,
먼저 왜 RAG가 필요한지,
LLM의 어떤 한계를 보완하는지,
Fine-tuning과는 무엇이 다른지를 중심으로 정리하겠습니다.
1. LLM은 왜 틀릴 수 있는가?
LLM은 질문을 받으면 인터넷에 접속해서 실시간으로 모든 정보를 찾아본 뒤 답하는 존재가 아닙니다. 기본적으로는 학습 과정에서 배운 패턴과 지식을 바탕으로, 다음에 올 가능성이 높은 단어를 이어가며 답변을 생성합니다.
쉽게 말하면 LLM은 엄청나게 많은 책과 문서를 읽고 말하는 법을 배운 사람과 비슷합니다. 아는 범위 안에서는 아주 똑똑하게 답하지만, 모르는 최신 소식이나 내부 문서까지 자동으로 알고 있는 것은 아닙니다.
핵심은 이것입니다.
LLM은 “답변을 생성하는 능력”이 뛰어난 모델이지, 항상 “최신 사실을 조회하는 시스템”은 아닙니다. 그래서 사실 기반 업무에 그대로 사용하면 틀린 답변이 나올 수 있습니다.
LLM이 틀릴 수 있는 대표적인 이유는 크게 네 가지입니다.
| 한계 | 의미 | 예시 |
|---|---|---|
| 학습 시점의 한계 | 모델이 학습한 시점 이후의 정보를 모를 수 있음 | 최근 제품 가격, 최신 법령, 오늘 발표된 정책 |
| 정확성 문제 | 그럴듯하지만 실제와 다른 답을 만들 수 있음 | 존재하지 않는 기능을 있는 것처럼 설명 |
| 환각 | 모르는 내용을 확신 있는 문장으로 생성하는 현상 | 없는 논문, 없는 판례, 없는 사내 규정 인용 |
| 내부 지식 부족 | 회사 내부 문서나 개인 문서를 기본적으로 알 수 없음 | 사내 복지 규정, 프로젝트 회의록, 고객 매뉴얼 |
2. 학습 시점의 한계
LLM의 가장 대표적인 한계는 학습 시점입니다. 모델은 특정 시점까지의 데이터로 학습됩니다.
그래서 그 이후에 바뀐 정보는 모델 내부 지식만으로는 알기 어렵습니다.
예를 들어 다음과 같은 질문을 생각해 볼 수 있습니다.
Q : 2026년 6월에 발생한 가장 이슈있는 일을 알려줘.
이 질문에 정확히 답하려면 모델은 2026년 6월까지의 데이터들이 학습되어 있어야합니다.( 현재 : 2026년 6월 18일 )
다만, 사용하는 모델이 최종 학습 시점이 2026년 4월이라면, LLM은 해당 답변을 내놓지 못할 수도 있습니다. 혹은 엉뚱한 정보를 줄지도 모르죠. 이것이 바로 환각입니다. 이는 뒤에 이어서 설명하겠습니다.
LLM의 문제는 단순히 “똑똑하지 않다”가 아닙니다. 답변에 필요한 최신 자료나 내부 자료를 못 보고 있다는 것이 핵심 문제입니다.
3. 환각 문제
환각, 즉 Hallucination은 LLM이 사실이 아닌 내용을 사실처럼 말하는 현상입니다.
사람이 모르는 문제를 받았을 때 “잘 모르겠습니다”라고 말하면 괜찮습니다. 그런데 LLM은 때때로 모르는 내용을 멈추지 않고 이어서 말합니다. 문장 자체는 자연스럽고 논리적으로 보이기 때문에 사용자는 그 답이 맞는 것처럼 느낄 수 있습니다.
잘못된 답변 예시:
2026년부터 6월부터는 장미와 소나무가 합쳐져 장소나무라는 식물이 생깁니다.
문장 자체는 자연스러울지라도, 말이 안 되는 것을 내뱉을 수 있습니다.
RAG의 핵심 목적 중 하나는 환각을 줄이는 것입니다.
LLM이 자유롭게 상상해서 답하는 것이 아니라, 검색된 문서의 근거를 바탕으로 답하게 만드는 방식입니다.
4. 내부 문서와 최신 정보 문제
실무에서 LLM을 쓰고 싶어지는 순간은 대부분 내 데이터를 물어보고 싶을 때입니다.
- 우리 회사 고객 상담 매뉴얼에서 환불 기준 찾아줘
- 사내 보안 정책에 맞게 외부 파일 공유가 가능한지 알려줘
- 이번 프로젝트 회의록 기준으로 다음 액션 아이템 정리해줘
- 우리 쇼핑몰 FAQ를 기준으로 고객 질문에 답해줘
- 최신 제품 설명서를 보고 기능 차이를 비교해줘
이런 질문은 모델이 일반적으로 배운 지식만으로는 해결하기 어렵습니다.
회사 내부 문서, 개인 문서, 최신 데이터베이스, 업무 시스템 안의 정보가 필요하기 때문입니다.
즉, 실무형 AI 서비스에서는 단순히 “좋은 LLM을 선택하는 것”만으로는 부족합니다.
LLM이 답변에 참고할 수 있는 근거 자료를 어떻게 연결할 것인가가 훨씬 중요해집니다.
5. 그렇다면 RAG란 무엇인가?
RAG는 Retrieval-Augmented Generation의 약자입니다. 한국어로는 보통 검색 증강 생성이라고 합니다.
RAG는 LLM이 답변을 생성하기 전에 관련 정보를 먼저 검색하고, 검색된 근거 자료를 함께 참고하여 답변을 생성하는 방식입니다.
| 용어 | 뜻 | 쉽게 말하면 |
|---|---|---|
| Retrieval | 검색 | 질문과 관련된 문서나 데이터를 찾아오는 단계 |
| Augmented | 증강된, 보강된 | 찾아온 정보를 프롬프트에 추가하는 단계 |
| Generation | 생성 | LLM이 근거 자료를 바탕으로 답변을 작성하는 단계 |
재택근무 예시를 RAG 방식으로 바꾸면 흐름은 이렇게 됩니다.
사용자 질문:
"2026년 우리 회사 재택근무 규정에서 주 3회 재택이 가능한가요?"
RAG 방식:
1. 질문과 관련된 사내 규정 문서를 검색한다.
2. "2026 재택근무 운영 지침" 문서의 관련 부분을 가져온다.
3. 해당 문서 내용을 LLM에게 함께 제공한다.
4. LLM은 문서 근거를 바탕으로 답변한다.이제 LLM은 막연히 “일반적인 재택근무 제도”를 설명하는 것이 아니라, 실제 사내 문서를 근거로 답할 수 있습니다.
6. RAG의 장점
RAG를 사용하는 이유는 단순히 “검색을 붙인다”가 아닙니다. LLM이 실무에서 더 믿을 수 있는 답변을 하도록 만드는 데 목적이 있습니다.
| 장점 | 설명 | 실무 예시 |
|---|---|---|
| 최신 정보 제공 | 모델 학습 이후에 생긴 정보도 검색을 통해 반영 가능 | 최신 공지사항, 최근 정책, 새 제품 설명서 |
| 정확성 향상 | 근거 자료를 참고하므로 막연한 추측을 줄일 수 있음 | FAQ 문서 기반 고객 응대 |
| 도메인 특화 응답 | 특정 산업, 회사, 프로젝트 문서를 반영 가능 | 의료, 법률, 금융, 제조 매뉴얼 기반 답변 |
| 비용 효율성 | 모델을 매번 재학습하지 않고 외부 지식을 연결 | 자주 바뀌는 문서를 검색 인덱스만 갱신 |
| 신뢰성 향상 | 답변에 근거 문서나 출처를 함께 제시 가능 | 사내 규정 답변에 문서명과 조항 표시 |
7. RAG와 Fine-tuning 차이
RAG를 공부할 때 자주 헷갈리는 개념이 Fine-tuning입니다. 둘 다 LLM을 특정 목적에 맞게 더 잘 쓰기 위한 방법처럼 보이기 때문입니다.
Fine-tuning은 모델의 행동 방식이나 응답 스타일을 조정하는 데 가깝고,
RAG는 모델이 답변할 때 참고할 외부 지식을 연결하는 데 가깝습니다.
| 구분 | RAG | Fine-tuning |
|---|---|---|
| 목적 | 외부 문서나 최신 데이터를 참고해 답변 | 모델의 응답 패턴이나 스타일을 조정 |
| 지식 업데이트 | 문서나 검색 인덱스를 업데이트하면 됨 | 새 데이터로 다시 학습 과정이 필요할 수 있음 |
| 최신 정보 반영 | 상대적으로 유리함 | 자주 바뀌는 지식에는 불리할 수 있음 |
| 출처 제시 | 검색된 문서를 근거로 출처 표시 가능 | 모델 내부에 반영되므로 출처 추적이 어려울 수 있음 |
| 적합한 상황 | 사내 문서 Q&A, 최신 정책, 매뉴얼 검색 | 특정 말투, 분류 형식, 반복 업무 패턴 학습 |
예를 들어 고객센터 챗봇을 만든다고 해보겠습니다.
- 고객 응대 말투를 회사 스타일에 맞추고 싶다 → Fine-tuning 또는 시스템 프롬프트가 도움 됨
- 매일 바뀌는 배송 정책, 환불 규정, 이벤트 내용을 반영하고 싶다 → RAG가 더 적합함
따라서 RAG와 Fine-tuning은 경쟁 관계라기보다 역할이 다릅니다. 실무에서는 둘을 함께 쓰는 경우도 있습니다.
8. RAG와 검색 엔진의 차이
RAG는 검색을 사용하기 때문에 검색 엔진과 비슷해 보일 수 있습니다. 하지만 둘은 결과를 제공하는 방식이 다릅니다.
| 구분 | 검색 엔진 | RAG |
|---|---|---|
| 결과 형태 | 문서 목록, 링크, 검색 결과 | 검색 결과를 바탕으로 생성된 자연어 답변 |
| 사용자 역할 | 사용자가 직접 문서를 열고 해석해야 함 | LLM이 검색 자료를 읽고 요약·정리해 줌 |
| 강점 | 많은 자료를 빠르게 찾음 | 찾은 자료를 질문 의도에 맞게 설명함 |
| 주의점 | 사용자가 직접 판단해야 함 | 검색 품질과 생성 품질을 모두 관리해야 함 |
검색 엔진이 “관련 문서 여기 있어요”라고 말하는 도구라면, RAG는 “관련 문서를 찾아보니, 질문에 대한 답은 이렇습니다”라고 말하는 구조에 가깝습니다.
9. Grounded Generation과 출처 기반 답변
RAG를 이야기할 때 함께 등장하는 개념이 Grounded Generation입니다.
Grounded Generation은 말 그대로 근거에 기반한 생성입니다. LLM이 자유롭게 답을 만드는 것이 아니라, 제공된 문서나 검색 결과 안에서 답을 만들도록 유도하는 방식입니다.
Grounded Generation 지시 예시:
아래 제공된 문서 내용만 근거로 답변하세요.
문서에 없는 내용은 추측하지 말고
"제공된 문서에서 확인할 수 없습니다"라고 답하세요.
가능하면 답변 끝에 참고한 문서명을 표시하세요.이런 방식은 환각을 줄이는 데 도움이 됩니다. 특히 법률, 금융, 의료, 사내 규정처럼 잘못된 답변의 위험이 큰 분야에서는 출처 기반 답변이 중요합니다.
다만 RAG를 쓴다고 해서 환각이 완전히 사라지는 것은 아닙니다. 잘못된 문서를 검색하거나, 관련 없는 문서를 가져오거나, 모델이 문서를 잘못 해석하면 여전히 오류가 생길 수 있습니다.
10. RAG가 적합한 사례
RAG는 “질문에 답하려면 외부 자료가 필요한 상황”에서 특히 유용합니다.
| 사례 | 왜 RAG가 적합한가? |
|---|---|
| 사내 문서 Q&A | 내부 규정, 복지 제도, 보안 정책처럼 모델이 기본적으로 모르는 정보가 필요함 |
| 고객센터 챗봇 | FAQ, 환불 정책, 배송 기준이 자주 바뀔 수 있음 |
| 법률·규정 검색 | 최신 법령, 판례, 조항을 근거로 답해야 함 |
| 논문·보고서 분석 | 긴 문서에서 관련 근거를 찾아 요약해야 함 |
| 제품 매뉴얼 챗봇 | 모델이 제품별 세부 사양을 외우고 있지 않아도 문서를 검색해 답할 수 있음 |
11. RAG를 쓰지 않아도 되는 상황
반대로 모든 서비스에 RAG가 필요한 것은 아닙니다. RAG는 검색 시스템, 문서 관리, 인덱싱, 비용 관리가 함께 필요하기 때문에 구조가 더 복잡해집니다.
다음과 같은 경우에는 RAG 없이도 충분할 수 있습니다.
- 일반적인 글쓰기 보조
- 문장 다듬기, 번역, 요약처럼 사용자가 원문을 직접 제공하는 작업
- 창의적인 아이디어 발상
- 정확한 최신 정보보다 표현력이나 구조화가 중요한 작업
- 답변에 외부 근거가 꼭 필요하지 않은 작업
판단 기준은 간단합니다.
답변에 최신 문서, 내부 문서, 특정 데이터베이스의 정보가 필요하다면 RAG를 고려하고, 그렇지 않다면 프롬프트 설계만으로도 충분할 수 있습니다.
12. RAG를 설계할 때 주의할 점
RAG를 붙이면 LLM이 무조건 정확해지는 것은 아닙니다. RAG의 답변 품질은 검색되는 자료의 품질에 크게 의존합니다.
| 주의사항 | 설명 |
|---|---|
| 데이터 품질 | 원본 문서가 틀리거나 오래되면 답변도 틀릴 수 있음 |
| 검색 품질 | 질문과 관련 없는 문서를 가져오면 LLM도 엉뚱한 답을 할 수 있음 |
| 문서 최신성 | 규정, 가격, 정책처럼 자주 바뀌는 정보는 주기적으로 업데이트해야 함 |
| 비용 관리 | 검색 결과를 너무 많이 넣으면 토큰 비용이 증가할 수 있음 |
| 출처 관리 | 사용자가 답변 근거를 확인할 수 있도록 문서명, 위치, 링크 등을 관리하는 것이 좋음 |
13. 전체 흐름 한 번에 정리
마지막으로 이번 글의 흐름을 한 번에 정리해 보겠습니다.
- LLM은 특정 시점까지 학습된 지식을 바탕으로 답변한다.
- 그래서 최신 정보, 내부 문서, 개인 문서에 대한 질문에는 한계가 있다.
- 모르는 내용을 그럴듯하게 말하면 환각 문제가 발생할 수 있다.
- RAG는 답변 전에 관련 문서나 데이터를 검색한다.
- 검색된 근거를 프롬프트에 추가해 LLM이 참고하게 만든다.
- 이 방식은 최신 정보 반영, 정확성 향상, 도메인 특화 응답, 출처 기반 답변에 유리하다.
- Fine-tuning은 모델의 응답 방식이나 스타일 조정에 가깝고, RAG는 외부 지식 연결에 가깝다.
- RAG는 사내 문서 Q&A, 고객센터, 법률·규정 검색, 매뉴얼 챗봇처럼 근거 자료가 중요한 업무에 적합하다.
정리
LLM은 강력한 언어 생성 능력을 가지고 있지만, 모든 정보를 항상 정확하게 알고 있는 것은 아닙니다. 특히 최신 정보, 회사 내부 문서, 개인 문서, 특정 도메인의 세부 지식이 필요한 상황에서는 모델의 기본 지식만으로는 부족합니다.
RAG는 이 한계를 보완하기 위한 실무적인 접근입니다. LLM에게 모든 것을 외우게 하는 대신, 필요한 정보를 검색해서 보여주고 그 근거를 바탕으로 답하게 만듭니다.
RAG는 LLM의 말하기 능력에 검색 능력을 붙여, 더 정확하고 근거 있는 답변을 만들기 위한 구조입니다.
다음 글에서는 실제 RAG 파이프라인을 조금 더 구체적으로 살펴보겠습니다. 문서를 어떻게 나누고, 임베딩은 어디에 쓰이며, Vector Store와 Retrieval이 어떤 역할을 하는지 하나씩 연결해서 정리해 보겠습니다.
