LLM을 써 보면 금방 느끼는 한계가 있습니다. 최신 정보가 없거나, 조직 내부 문서를 모르거나, 그럴듯하지만 틀린 답을 하는 경우가 있다는 점입니다. 이때 자주 나오는 해결책 중 하나가 RAG입니다.
RAG는 모델 자체를 다시 학습시키는 대신, 질문과 관련된 외부 문서를 먼저 찾아서 함께 넣어 주는 구조입니다. 그래서 AI 앱 실전 설계에서 매우 자주 등장합니다.
이 글에서는 아래 내용을 정리합니다.
- RAG가 무엇인지
- 왜 필요한지
- 검색, 임베딩, 프롬프트와 어떻게 연결되는지
핵심은 RAG는 모델 안에 없는 정보를 외부에서 검색해 넣어 줌으로써 답변 품질과 grounding을 높이는 구조라는 점입니다.
RAG란 무엇인가
RAG는 Retrieval-Augmented Generation의 줄임말입니다. 보통 아래 두 단계를 결합합니다.
- 질문과 관련된 문서를 찾는다
- 그 문서를 모델 입력에 함께 넣어 답을 생성한다
즉, 모델이 “기억만으로” 답하게 두지 않고, 필요한 자료를 같이 보게 만드는 방식입니다.
왜 RAG가 필요할까
LLM은 강력하지만 아래 같은 한계가 있습니다.
- 최신 정보가 반영되지 않을 수 있다
- 회사 내부 문서를 기본적으로 알지 못한다
- 잘 모르는 것도 그럴듯하게 답할 수 있다
RAG는 이 문제를 완화하는 데 자주 쓰입니다. 모델을 다시 학습시키지 않고도, 질문에 맞는 외부 문서를 함께 넣어 줄 수 있기 때문입니다.
RAG의 가장 기본적인 흐름
입문 단계에서는 보통 이렇게 이해하면 충분합니다.
- 문서를 잘게 나눈다
- 각 문서를 임베딩한다
- 질문도 임베딩한다
- 질문과 가까운 문서를 찾는다
- 그 문서를 프롬프트에 넣고 모델이 답하게 한다
즉, RAG는 검색과 생성이 이어진 구조입니다.
임베딩은 왜 중요한가
RAG에서 임베딩은 질문과 문서의 의미적 유사성을 계산하는 핵심 역할을 합니다. 단순 키워드 매칭보다 의미 기반으로 관련 문서를 찾기 쉬워집니다.
이 때문에 RAG를 이해하려면 임베딩 가이드를 함께 보는 것이 특히 좋습니다.
RAG와 프롬프트는 어떤 관계가 있을까
검색만 잘했다고 끝나는 것은 아닙니다. 찾은 문서를 모델이 잘 쓰게 하려면 프롬프트 구조도 중요합니다.
예를 들어 아래처럼 지시할 수 있습니다.
- 아래 문서만 근거로 답하라
- 문서에 없으면 모른다고 말하라
- 출처를 함께 표시하라
즉, RAG는 검색 구조와 프롬프트 설계가 같이 맞물릴 때 더 잘 동작합니다.
RAG가 hallucination을 줄여 주는 이유
모델이 외부 근거를 함께 보게 되면, 완전히 추측으로 답하는 상황을 줄일 수 있습니다. 물론 완전히 사라지는 것은 아니지만, “근거 있는 답”을 유도하기가 훨씬 쉬워집니다.
그래서 RAG는:
- 사내 문서 QA
- 제품 문서 챗봇
- 정책/약관 검색
- 지식 베이스 도우미
같은 구조에서 특히 자주 쓰입니다.
RAG가 만능은 아닌 이유
입문자에게 중요한 부분입니다. RAG를 붙인다고 자동으로 모든 답변이 좋아지는 것은 아닙니다.
예를 들어:
- 검색 문서가 잘못되면 답도 흔들린다
- chunking이 나쁘면 필요한 문맥을 놓친다
- 프롬프트가 부실하면 문서를 잘 활용하지 못한다
즉, RAG는 구조적 도움을 주지만 품질은 검색, 임베딩, 문서 정리, 프롬프트 설계가 같이 받쳐줘야 합니다.
자주 하는 오해
1. RAG는 파인튜닝의 대체재다
겹치는 부분은 있지만 완전히 같은 문제를 푸는 것은 아닙니다.
2. 검색만 붙이면 답변이 항상 정확해진다
문서 품질과 검색 품질이 낮으면 오히려 혼란스러워질 수 있습니다.
3. RAG는 최신 정보 문제만 해결한다
최신 정보뿐 아니라 내부 문서, 특정 도메인 지식 grounding에도 많이 쓰입니다.
FAQ
Q. RAG와 파인튜닝 중 무엇을 먼저 봐야 하나요?
대부분의 지식 보강 문제에서는 RAG를 먼저 검토하는 편이 현실적입니다.
Q. RAG를 하려면 벡터 DB가 꼭 필요한가요?
작은 예제는 꼭 그렇지 않을 수 있지만, 실전에서는 자주 함께 등장합니다.
Q. RAG는 챗봇에만 쓰이나요?
아닙니다. 검색 보강이 필요한 요약, 분석, 문서 도우미에도 많이 쓰입니다.
Read Next
- RAG와 파인튜닝의 선택 기준이 궁금하다면 파인튜닝 vs RAG 가이드를 이어서 읽어보세요.
- 구현 쪽 예시가 궁금하다면 기존의 Supabase RAG Chatbot Guide도 함께 보면 좋습니다.
심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.
먼저 읽어볼 가이드
검색 유입이 많은 핵심 글부터 이어서 보세요.
- 미들웨어 트러블슈팅 가이드: Redis vs RabbitMQ vs Kafka 개발자를 위한 미들웨어 트러블슈팅 허브 글입니다. Redis, RabbitMQ, Kafka 중 어떤 증상부터 먼저 봐야 하는지와 어떤 문제 패턴이 각 시스템에 가까운지 정리합니다.
- Kubernetes CrashLoopBackOff: 먼저 볼 것들 startup failure, probe, config, resource limit 관점에서 CrashLoopBackOff를 어떻게 나눠서 봐야 하는지 정리한 가이드입니다.
- Kafka consumer lag가 계속 늘 때: 트러블슈팅 가이드 Kafka consumer lag가 계속 늘어날 때 무엇부터 봐야 하는지 정리합니다. poll 주기, 처리 속도, rebalance, consumer 설정까지 실전 기준으로 다룹니다.
- Kafka Rebalancing Too Often 가이드 Kafka consumer group에서 rebalance가 너무 자주 일어날 때 membership flapping, poll timing, protocol, assignment churn을 어떤 순서로 봐야 하는지 설명하는 실전 가이드입니다.
- Docker container가 계속 재시작될 때: 먼저 확인할 것들 exit code, command failure, environment mistake, health check 관점에서 Docker restart loop를 푸는 실전 가이드입니다.
심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.