Apr 14, 2026

마지막 업데이트 Apr 26, 2026

RAG 가이드: LLM이 외부 지식을 더 잘 쓰게 만드는 가장 실전적인 방법

LLM을 실제 제품에 붙여보면 금방 부딪히는 한계가 있습니다. 사내 문서 기반 챗봇을 처음 만들었을 때, GPT-4에 시스템 프롬프트로 “이 회사의 정책 문서를 기반으로 답하세요”라고만 넣었습니다. 결과는 참담했고, 모델은 존재하지 않는 정책을 자신 있게 지어냈습니다. RAG를 붙이고 나서야 비로소 “근거 있는 답변”이 가능해졌습니다.

LLM을 실제 제품에 붙여보면 금방 부딪히는 한계가 있습니다. 모델이 최신 정보를 모를 수 있고, 사내 문서나 제품 문서를 기본적으로 알고 있지 않으며, 그럴듯하지만 틀린 답을 꽤 자신 있게 말할 수 있다는 점입니다.

이 문제를 해결하려고 많은 팀이 가장 먼저 검토하는 구조가 RAG입니다.

RAG는 모델 자체를 다시 학습시키는 대신, 질문과 관련된 외부 문서를 먼저 찾고 그 문서를 모델 입력에 붙여 응답을 생성하게 하는 구조입니다. 그래서 최근 정보, 내부 문서, 제품 문서, 정책 문서가 필요한 AI 기능에서 매우 자주 등장합니다.

빠르게 요약하면 이렇습니다.

RAG는 retrieval + generation을 합친 구조입니다.
모델을 더 똑똑하게 만드는 것이 아니라, 모델이 답하기 전에 필요한 문서를 읽게 만드는 방식에 가깝습니다.
실제 품질은 retrieval quality, chunking, embeddings, prompt grounding, citation, evaluation에 크게 좌우됩니다.
RAG는 hallucination을 줄이는 데 도움이 되지만, 자동 정답 보장 장치는 아닙니다.
최신 정보, 내부 문서, 제품 문서 기반 Q&A에는 매우 잘 맞지만, 규칙 자체를 모델 행동에 깊게 녹여야 하는 문제는 fine-tuning이나 다른 구조가 더 맞을 수도 있습니다.

이 글에서는 그 관점으로 RAG를 설명하겠습니다.

RAG는 “찾고 나서 답하는” 구조다

RAG는 Retrieval-Augmented Generation의 줄임말입니다. 이름 그대로 두 단계를 결합합니다.

질문과 관련된 문서를 찾는다
찾은 문서를 바탕으로 답을 생성한다

즉 모델에게 “기억나는 대로 답해”라고 하는 대신, 먼저 참고할 만한 근거를 붙여준 뒤 답하게 만드는 구조입니다.

이 차이는 단순하지만 효과가 큽니다. 모델이 미리 모든 정보를 파라미터 안에 완벽히 저장하고 있을 필요가 없어지기 때문입니다.

특히 아래 같은 문제에서 바로 힘을 발휘합니다.

최신 정책을 반영해야 하는 고객지원
내부 위키나 문서를 바탕으로 답해야 하는 사내 도우미
특정 제품 문서를 기준으로 설명해야 하는 문서 챗봇
근거 문서를 보여줘야 신뢰를 얻는 지식형 서비스

즉 RAG는 LLM을 “전지적 기억 기계”로 만들기보다, 필요한 근거를 그때그때 붙여주는 방식에 가깝습니다.

왜 RAG가 필요한가

LLM은 강력하지만 아래 한계를 자주 드러냅니다.

최신 정보가 모델 안에 반영되지 않을 수 있다
조직 내부 문서를 기본적으로 모른다
특정 도메인 규칙을 정확히 기억하고 있지 않다
모르는 내용도 그럴듯하게 이어서 말할 수 있다

RAG는 이 문제를 구조적으로 줄이려는 접근입니다. 핵심은 모델을 다시 훈련시키지 않고도, 필요한 문서를 실행 시점에 붙여서 grounding을 높이는 것입니다.

그래서 많은 팀이 “우리 제품은 최신 정보나 내부 문서를 써야 한다”는 순간, fine-tuning보다 먼저 RAG를 검토합니다.

RAG의 가장 기본적인 흐름

입문 단계에서는 아래 흐름만 이해해도 충분히 출발할 수 있습니다.

문서를 적당한 단위로 쪼갠다
각 조각을 벡터로 표현한다
사용자 질문도 벡터로 표현한다
질문과 가까운 문서 조각을 찾는다
그 문서 조각을 프롬프트에 넣고 답을 생성한다

이를 조금 더 실무적으로 쓰면 이렇게 볼 수 있습니다.

document ingest
-> chunking
-> embeddings
-> retrieval
-> prompt grounding
-> answer generation
-> citation / validation

이 흐름을 보면 알 수 있듯, RAG의 품질은 단순히 “문서를 찾았는가”가 아니라 그 앞과 뒤 단계를 얼마나 잘 설계했는지에 달려 있습니다.

chunking이 약하면 retrieval도 약해진다

RAG를 처음 만들 때 가장 자주 과소평가되는 부분이 chunking입니다. 문서를 어떤 단위로 자르느냐가 retrieval 품질을 크게 바꿉니다.

예를 들어 chunk가 너무 크면:

관련 없는 정보까지 같이 들어와서 잡음이 늘고
prompt가 길어지며
핵심 문장보다 주변 문장이 더 많이 노출될 수 있습니다

반대로 chunk가 너무 작으면:

문맥이 끊겨 의미가 약해지고
질문에 답하는 데 필요한 정보가 여러 조각으로 찢어지며
retrieval은 됐는데 실제 답변에는 부족한 상태가 생길 수 있습니다

즉 RAG에서 좋은 retrieval은 좋은 벡터 검색만의 문제가 아니라, 좋은 문서 단위 설계의 문제이기도 합니다.

실무에서는 문서 종류에 따라 chunk 기준을 다르게 잡는 경우가 많습니다. 실제로 한 프로젝트에서 전체 문서를 500토큰으로 균일하게 잘랐다가, FAQ 항목이 두 chunk에 걸쳐 찢어지면서 retrieval 정확도가 40%대로 떨어진 적이 있습니다. FAQ는 항목 단위로, 기술 문서는 heading+코드 블록 묶음으로 chunk 전략을 나눈 뒤 70%대로 올랐습니다.

FAQ 문서는 항목 단위
정책 문서는 섹션 단위
기술 문서는 heading과 코드 블록을 함께 고려

이 부분을 대충 넘기면 이후 단계에서 품질을 끌어올리기가 어렵습니다.

embeddings는 질문과 문서의 의미적 거리를 비교하게 만든다

RAG에서 embeddings는 질문과 문서의 의미가 얼마나 가까운지를 비교하는 핵심 도구입니다.

간단히 말해:

질문을 벡터로 바꾸고
문서 조각도 벡터로 바꾼 다음
서로 가까운 것을 찾는 구조입니다

이 방식의 장점은 단순 키워드 일치보다 의미 기반 검색에 강하다는 점입니다.

예를 들어 사용자가 “비밀번호를 잊어버렸어요”라고 말해도, 문서 제목이 “로그인 비밀번호 재설정 방법”이라면 꽤 잘 연결될 수 있습니다.

이 부분은 임베딩 가이드와 같이 보면 더 입체적으로 이해됩니다. 결국 RAG는 문서를 가져오는 구조이고, embeddings는 그 문서를 의미 기반으로 잘 찾게 만드는 핵심 요소입니다.

retrieval quality가 낮으면 RAG 전체가 흔들린다

많은 초보 구현이 “문서를 가져오기만 하면 된다”는 생각에서 멈춥니다. 하지만 RAG의 실제 품질은 retrieval quality에서 거의 절반 이상이 갈릴 때가 많습니다.

retrieval quality가 낮을 때 흔한 문제는:

질문과 덜 관련된 문서를 가져온다
필요한 문서가 top-k 밖으로 밀린다
너무 많은 문서를 가져와 prompt가 오염된다
비슷한 문서가 중복되어 토큰만 많이 쓴다

그래서 RAG를 개선할 때 자주 보는 포인트는 아래와 같습니다.

top-k를 얼마나 가져올 것인가
reranking이 필요한가
metadata filtering이 도움이 되는가
같은 문서의 중복 chunk가 너무 많이 들어오지 않는가

즉 retrieval은 “찾았다/못 찾았다”가 아니라 얼마나 덜 틀리게, 덜 시끄럽게, 더 필요한 문서를 가져왔는가가 중요합니다.

운영하면서 체감한 팁 하나는, top-k를 5에서 3으로 줄였을 때 오히려 답변 품질이 올라간 경우가 있었다는 점입니다. 비슷한 chunk가 3개나 들어가면 모델이 혼란스러워하는 것 같았습니다. reranker를 추가하고 top-k를 줄이는 조합이 가장 효과적이었습니다.

RAG는 retrieval만으로 끝나지 않고 prompt grounding까지 가야 한다

문서를 찾았다고 끝이 아닙니다. 찾은 문서를 모델이 어떻게 읽고 쓰게 할지도 중요합니다.

그래서 RAG는 retrieval 구조이면서 동시에 prompt 설계 문제이기도 합니다.

예를 들어 prompt에서 아래를 명시할 수 있습니다.

제공된 문서를 우선 근거로 사용할 것
문서에 없는 내용은 모른다고 말할 것
가능하면 근거 문서나 출처를 함께 보여줄 것

이런 지시가 없으면, 모델은 문서를 받았더라도 자기 내부 패턴으로 더 많이 이어서 말할 수 있습니다. 즉 RAG 품질은 retrieval만이 아니라 grounded prompting에 달려 있습니다.

citation은 신뢰를 크게 올려준다

RAG가 유용한 이유 중 하나는 근거 문서를 함께 제시하기 쉽다는 점입니다.

특히 아래 같은 서비스에서 citation은 신뢰를 크게 높입니다.

내부 문서 검색
정책 Q&A
기술 문서 보조
고객지원 답변

사용자가 “왜 이렇게 답했는지”를 확인할 수 있기 때문입니다.

citation을 붙인다고 해서 자동으로 정확해지는 것은 아니지만, 최소한:

근거가 무엇인지 드러나고
잘못된 문서를 붙였는지 진단하기 쉬워지고
사용자가 답을 검증할 수 있게 됩니다

즉 citation은 RAG 품질을 올리는 장치라기보다, 품질을 드러내고 검증 가능하게 만드는 장치에 가깝습니다.

RAG는 hallucination을 줄이지만 없애지는 않는다

RAG를 붙이면 hallucination이 완전히 사라질 거라고 기대하는 경우가 많습니다. 하지만 실제로는 그렇지 않습니다.

RAG가 hallucination을 줄여주는 이유는 모델이 외부 근거를 보고 답하게 만들기 때문입니다. 다만 아래 경우는 여전히 문제가 생깁니다.

retrieval이 틀렸다
chunk가 중요 문맥을 잃었다
prompt가 grounding을 제대로 강제하지 못했다
문서 자체가 낡았거나 잘못됐다
모델이 근거를 보고도 과하게 일반화했다

즉 RAG는 hallucination을 줄이는 매우 좋은 구조지만, “문서를 붙이면 정답”은 아닙니다. 이 균형은 AI hallucination 줄이기 가이드와 함께 보면 더 잘 연결됩니다.

RAG가 특히 잘 맞는 경우

RAG는 아래처럼 외부 지식이 중요할 때 특히 강합니다.

최신 정보가 자주 바뀌는 서비스
사내 문서, 위키, 정책 문서를 기반으로 답해야 하는 시스템
제품 매뉴얼, API 문서, 도움말 센터를 활용하는 챗봇
답변 근거를 보여줘야 신뢰를 얻는 업무 도구

즉 RAG는 “모델을 더 똑똑하게”보다 모델이 필요한 자료를 옆에 두고 읽게 만들고 싶을 때 가장 잘 맞습니다.

RAG가 항상 정답은 아닌 경우도 있다

반대로 아래 상황에서는 RAG만으로는 부족하거나, 다른 접근이 더 맞을 수 있습니다.

지식 검색보다 모델 행동 자체를 바꾸고 싶은 경우
특정 스타일이나 출력 습관을 모델에 깊게 반영하고 싶은 경우
매우 짧고 고정된 규칙만 계속 적용하면 되는 경우
retrieval 비용과 latency가 너무 부담스러운 경우

예를 들어 도메인 문서 기반 답변은 RAG가 잘 맞지만, 특정 형식의 응답 습관이나 모델 행동 편향 자체를 바꾸고 싶다면 fine-tuning이나 system design 변경이 더 적절할 수 있습니다.

이 경계는 Fine-Tuning vs RAG 가이드와 직접 맞닿아 있습니다.

좋은 RAG는 결국 평가 가능한 RAG다

RAG를 운영으로 가져가면 “되냐 안 되냐”보다 “언제 왜 틀리냐”가 더 중요해집니다. 그래서 evaluation이 꼭 필요합니다.

적어도 아래는 자주 봐야 합니다.

retrieval 문서가 실제로 질문과 관련 있었는가
답이 그 문서를 근거로 했는가
citation이 맞았는가
문서가 부족할 때 억지로 답하지 않았는가
top-k, chunking, prompt 변경 후 품질이 나아졌는가

즉 좋은 RAG는 retrieval을 붙인 시스템이 아니라, retrieval이 왜 맞고 왜 틀리는지 계속 볼 수 있는 시스템입니다.

이 관점은 LLM 평가 가이드와도 연결됩니다.

자주 하는 오해

1. RAG는 fine-tuning의 다른 이름이다

둘은 겹치는 목표가 있을 뿐, 문제를 푸는 방식이 다릅니다. RAG는 외부 문서를 붙이는 구조이고, fine-tuning은 모델 행동을 학습적으로 바꾸는 접근입니다.

2. retrieval만 붙이면 답이 자동으로 정확해진다

retrieval 품질, chunking, 문서 품질, prompt grounding이 약하면 여전히 흔들립니다.

3. RAG는 최신 정보 문제에만 쓰인다

최신 정보뿐 아니라 내부 문서, 제품 문서, 정책 문서, 도메인 grounding에도 매우 자주 쓰입니다.

4. vector DB만 붙이면 RAG가 완성된다

vector 검색은 핵심 구성 요소일 뿐입니다. 실제 품질은 문서 준비, retrieval 전략, prompt, citation, evaluation이 함께 결정합니다.

FAQ

Q. 지식 기반 문제라면 RAG를 먼저 봐야 하나요?

많은 경우 그렇습니다. 최신 정보나 내부 문서를 써야 하는 문제라면 RAG를 먼저 검토하는 편이 매우 실용적입니다.

Q. RAG를 하려면 꼭 vector database가 필요한가요?

작은 데모에서는 꼭 그렇지 않을 수 있습니다. 하지만 의미 기반 retrieval이 중요해지는 실전 시스템에서는 자주 등장합니다.

Q. RAG는 챗봇에만 쓰이나요?

아닙니다. 문서 요약, 분석 보조, 검색 보조, 고객지원, 내부 지식 도우미 등 다양한 워크플로에 쓰입니다.

먼저 읽어볼 가이드

검색 유입이 많은 핵심 글부터 이어서 보세요.