RAG란 무엇인가: LLM 검색 증강 생성 원리와 구현 방법
ChatGPT한테 “어제 나온 우리 신제품 스펙 알려줘"라고 물어본 적 있으세요? 아마 자신 있게 틀린 답이 돌아왔을 거예요. 그게 LLM의 고질병이에요. 그리고 그 문제를 푸는 기술이 바로 RAG입니다.
“LLM이 우리 내부 데이터를 모른다.” 기업 AI 담당자들한테 가장 많이 들리는 불만이에요. RAG의 원리와 구현 방식을 제대로 이해하면 이 문제가 풀려요. 단순한 기술 용어가 아니라, 기업 AI의 실용성을 좌우하는 핵심 설계 결정이거든요.
핵심 요약
- RAG(검색 증강 생성)는 LLM이 답변을 생성하기 전에 외부 지식베이스에서 관련 문서를 먼저 검색해 맥락으로 주입하는 방식이에요.
- Meta AI Research의 2020년 논문(Lewis et al.)에서 처음 제안됐고, 2023년 이후 기업 AI 파이프라인의 표준 패턴으로 자리잡았어요.
- AWS 자료 기준으로 RAG를 쓴 LLM 응답의 사실 정확도는 파인튜닝 없이도 최대 45% 향상될 수 있어요.
- 구현 방식은 나이브 RAG, 어드밴스드 RAG, 모듈러 RAG 세 가지로 나뉘고, 팀 규모와 데이터 복잡도에 따라 선택 기준이 달라져요.
LLM의 고질병, 그리고 RAG가 등장한 배경
LLM은 훈련 데이터의 마감일(cutoff date)이 있어요. 그 이후 일은 모르고, 처음부터 학습하지 않은 내부 문서도 당연히 모르죠.
이 문제를 해결하는 방법은 두 가지였어요.
첫째, 파인튜닝(Fine-tuning). 새 데이터로 모델을 다시 학습시키는 거예요. 비용이 크고, 데이터가 바뀔 때마다 반복해야 해요. 둘째, 컨텍스트 주입(Context Injection). 질문할 때 관련 문서를 통째로 프롬프트에 넣는 거예요. 간단하지만 긴 문서를 다 넣으면 토큰 비용이 폭발하죠.
RAG는 이 두 방법의 중간을 찾은 거예요. 질문에 관련된 문서만 “골라서” 컨텍스트에 넣는 방식이에요. Meta AI Research의 Lewis 연구팀이 2020년 논문에서 이 구조를 처음 공식화했고, LangChain·LlamaIndex 같은 프레임워크가 등장하면서 실제 구현이 빠르게 퍼졌어요.
2023년부터는 기업 AI 도입 현장에서 RAG가 거의 기본 구조가 됐어요. AWS, Azure, Google Cloud 모두 자사 AI 서비스에 RAG 파이프라인을 기본 패턴으로 제시하고 있고요. 기업들이 LLM을 “범용 챗봇"이 아니라 “내 데이터를 아는 도구"로 쓰고 싶어하기 때문이에요. 그 수요가 RAG를 필수 기술로 만든 셈이죠.
RAG의 작동 원리: 세 단계로 끝나요
1단계: 문서 인덱싱 (Indexing)
외부 문서(PDF, DB, 사내 위키 등)를 작은 청크(chunk)로 쪼개요. 각 청크를 임베딩 모델로 벡터로 변환해요. 텍스트를 숫자 좌표로 바꾸는 거예요. 이 벡터들을 벡터 데이터베이스에 저장하죠. Pinecone, Weaviate, pgvector 같은 도구들이 여기에 쓰여요.
2단계: 검색 (Retrieval)
사용자가 질문을 입력하면, 그 질문도 동일한 임베딩 모델로 벡터화해요. 그 벡터와 가장 가까운(유사도가 높은) 청크를 벡터 DB에서 찾아내요. 이게 “검색"이에요.
3단계: 생성 (Generation)
검색된 청크들을 LLM 프롬프트에 컨텍스트로 붙여서 보내요. LLM은 “이 문서를 참고해서 답해줘"라는 지시와 함께 질문을 받고 답변을 생성하죠.
핵심은 LLM 자체를 바꾸지 않는다는 거예요. 외부에서 필요한 정보를 “끼워 넣는” 방식이라 유지보수가 훨씬 쉬워요.
RAG 구현 방식 비교: 무엇을 골라야 할까
| 기준 | 나이브 RAG | 어드밴스드 RAG | 모듈러 RAG |
|---|---|---|---|
| 구조 | 기본 검색→생성 | 사전/사후 처리 추가 | 컴포넌트 교체 가능 |
| 정확도 | 보통 | 높음 | 매우 높음 |
| 구현 난이도 | 낮음 | 중간 | 높음 |
| 비용 | 낮음 | 중간 | 높음 |
| 적합한 팀 | 스타트업, 프로토타입 | 중소기업 프로덕션 | 대기업, 복잡한 도메인 |
| 대표 도구 | LangChain 기본 체인 | LlamaIndex, Cohere Rerank | DSPy, 커스텀 파이프라인 |
나이브 RAG는 빠르게 데모를 만들 때 좋아요. 검색→생성만 연결하면 되거든요. 단점은 관련 없는 청크가 섞여 들어올 때 답변 품질이 확 떨어진다는 거예요.
어드밴스드 RAG는 검색 전에 쿼리를 재작성(query rewriting)하거나, 검색 후 관련성 낮은 문서를 재순위(reranking)하는 단계를 추가해요. LlamaIndex 자료에 따르면 리랭킹만 추가해도 검색 정확도가 20~30% 개선되는 케이스가 많아요.
모듈러 RAG는 각 단계를 독립 모듈로 설계해요. 검색기를 바꾸거나 생성 모델을 교체해도 전체 파이프라인이 유지돼요. 의료·법률·금융처럼 도메인 복잡도가 높은 곳에서 자주 쓰이는 방식이에요.
선택은 단순해요. 프로토타입이면 나이브, 프로덕션이면 어드밴스드, 도메인 복잡도가 높으면 모듈러.
실제 팀이라면 어떻게 시작할까
지금 당장 RAG를 도입하려는 팀이라면 세 가지만 챙기면 돼요.
- 임베딩 모델 선택: OpenAI의
text-embedding-3-small은 비용이 저렴하고 다국어 성능이 준수해요. 한국어 특화가 필요하다면 KLUE-RoBERTa 기반 임베딩 모델도 선택지예요. - 청크 전략: 청크 크기는 보통 512~1,024 토큰이 기준이지만, 표나 코드처럼 구조화된 문서는 의미 단위로 쪼개는 게 나아요. 기계적으로 자르면 문맥이 끊겨서 검색 품질이 떨어져요.
- 평가 지표: RAGAS 같은 평가 프레임워크로 “충실도(faithfulness)“와 “답변 관련성(answer relevancy)“을 측정해야 해요. 감으로만 평가하면 나중에 어디서 망가졌는지 알 수 없어요.
이미 도입했지만 성능이 불만족스러운 팀이라면, 먼저 검색 단계를 들여다보세요. LLM이 이상한 답을 한다고 해서 항상 LLM 문제가 아니에요. 검색된 청크가 애초에 엉뚱한 문서였을 가능성이 높아요. 리랭킹 모델 하나 추가하는 것만으로 체감 품질이 크게 올라가는 경우가 많아요.
그리고 앞으로 주시할 흐름 두 가지. GraphRAG는 Microsoft Research가 2024년 공개한 방식으로, 문서를 벡터가 아니라 지식 그래프로 구조화해요. 복잡한 관계 질의에서 기존 RAG보다 정확해요. Long-context LLM은 Gemini 1.5 Pro가 100만 토큰 컨텍스트를 지원하면서 “RAG가 필요 없어지는 거 아니냐"는 질문이 나오는데, 비용과 응답 속도 문제 때문에 당분간은 RAG가 더 현실적인 선택이에요.
마치며: 지금 어디에 있는지 파악하는 게 먼저예요
RAG를 한 줄로 요약하면 이래요. “LLM에게 시험 전에 교과서를 쥐여주는 방식.”
원리 자체는 단순해요. 검색하고, 컨텍스트에 넣고, 생성하는 거죠. 복잡해지는 건 실제 데이터와 만날 때예요. 문서 포맷이 제각각이고, 질문은 모호하고, 평가 기준도 불명확해요.
그래서 지금 팀에게 필요한 질문은 “RAG를 써야 하나?“가 아니에요. “우리 데이터 파이프라인이 RAG를 지탱할 만큼 정돈되어 있나?“가 먼저예요.
기술은 준비됐어요. 데이터는요?
참고자료
- RAG란? - 검색 증강 생성 AI 설명
- RAG(검색 증강 생성)란? - LLM 단점을 보완하는 기술 | 블로그 | 모두의연구소
- RAG란? LLM의 한계를 극복하는 검색 증강 생성 기술 완벽 가이드 (2025) - 피카부랩스 블로그
