RAG 기초: 검색, 주입, 생성의 운영 기준

RAG는 외부 지식을 검색해 LLM 컨텍스트에 주입하고 답변을 생성하는 패턴이다. 이 스크립트는 RAG가 필요한 이유, 검색 품질을 올리는 단계, 평가와 운영 실패 조건, 대안과의 선택 기준을 정리한다.

Layer: L12
Duration: 길이 미정
Generated: 2026. 5. 25. 오후 4:26:11

원본 문서 읽기 오디오 파일 열기

Script Companion

오디오와 함께 스크립트 보기

01
RAG를 이해하려면 먼저 parametric LLM의 한계를 봐야 한다. 여기서 parametric LLM은 지식이 모델 가중치에 박혀 있는 형태를 뜻한다. 문서가 자주 바뀌면 fine-tuning으로 새 지식을 넣는 비용과 시간이 커지고, 답변이 어느 문서의 어느 부분에 근거했는지도 되짚기 어렵다. 또 학습 분포 밖 질문에서는 그럴듯하지만 틀린 답을 만들 수 있고, 긴 문서를 그대로 넣는 방식도 lost-in-the-middle 문제로 중간 정보가 무시될 수 있다.
02
RAG의 기본 해결책은 진실을 모델 안이 아니라 외부 KV store에 두는 것이다. 벡터 검색과 BM25 같은 검색 인프라에 문서를 넣어두고, 질문이 들어올 때마다 관련 top-K 문서를 찾아 prompt에 주입한 뒤, documents 밖 정보는 모른다고 답하게 제약한다. 이렇게 하면 문서 하나를 바꾸는 것만으로 지식을 즉시 갱신할 수 있고, chunk ID를 답변에 붙여 provenance를 확보할 수 있다. 적절히 구성하면 hallucination도 RAG 없는 baseline 대비 최대 71%까지 줄어든다고 정리되어 있다.
03
가장 단순한 형태는 Naive RAG다. 질문을 embedding하고, top-K chunk를 가져와 prompt에 넣고, 답변을 생성하는 흐름이다. 다만 production에서는 거의 항상 부족하므로 질문을 그대로 검색하지 않는 Query Transformation이 필요하다. Query Rewriting은 사용자 질문을 다시 써서 키워드를 보강하고, 대화의 후속 질문이라면 이전 turn의 정보를 합쳐 검색한다. Multi-Query는 같은 의도를 여러 변형으로 검색해 합집합을 만들고, HyDE는 LLM이 가상 답변을 먼저 만든 뒤 그 답변을 embedding해 검색 품질을 높인다.
04
검색 전략은 문서와 질문의 성격에 따라 달라진다. Semantic 검색은 dense embedding을 쓰는 기본 방식이고, Hybrid 검색은 BM25와 dense 검색을 RRF로 합쳐 한국어, 고유명사, 코드처럼 정확한 토큰 매칭이 중요한 상황에 유리하다. Multi-vector나 ColBERT는 token별 정확도를 높이고, Parent-Child나 Hierarchical 방식은 작은 chunk로 검색하되 더 큰 parent context를 돌려준다. 검색된 chunk들이 같은 parent에 속하면 Auto-merging으로 합쳐 반환할 수 있고, entity 관계가 중요한 경우에는 Knowledge graph 기반 GraphRAG가 선택지가 된다.
05
검색이 끝났다고 품질이 끝나는 것은 아니다. RAG 품질에서 가장 큰 ROI로 정리된 단계가 cross-encoder reranker를 이용한 Re-ranking이다. 먼저 넓게 검색해 후보를 확보한 뒤, reranker가 top-10을 다시 정렬하면 검색은 됐지만 중요한 문서가 뒤로 밀리는 문제를 줄일 수 있다. 특히 Multi-Query처럼 recall을 늘리는 기법은 noise도 함께 늘릴 수 있으므로 reranker가 사실상 필수에 가깝다. latency budget이 50ms보다 작은 환경에서는 reranker가 부담이 될 수 있다는 점도 함께 봐야 한다.
06
Augmentation은 검색 결과를 prompt에 어떻게 넣을지의 문제다. 문서는 XML이나 structured 형식으로 넣는 방식이 권장되고, 위치도 중요하다. Liu et al. 2023의 Lost in the Middle 연구 결과처럼 앞이나 끝 정보가 가장 잘 활용되고, 중간 정보는 무시되기 쉽다. 그래서 운영에서는 검색 결과를 prompt 끝쪽이나 시스템 직후 앞쪽에 두고, 가장 중요한 문서부터 배치한다. Context length도 관리해야 하며, K=5~10이 보통 sweet spot으로 제시된다. 너무 많은 문서는 비용을 늘리고 lost-in-the-middle을 다시 만든다.
07
Generation 단계에서는 답변이 검색 문서에 근거하도록 강제해야 한다. prompt에는 documents에 없는 정보는 답하지 말라는 제약을 넣고, structured output으로 citation을 강제할 수 있다. 검색이 부족하다고 판단되면 multi-hop으로 추가 검색을 하거나, 관련 정보를 찾을 수 없다고 refusal해야 한다. 이 refusal은 기능 부족이 아니라 환각을 막는 안전장치다. 사용자에게 출처 링크를 제공하는 것도 단순한 장식이 아니라 답변 검증과 신뢰성의 일부다.
08
Advanced RAG 패턴은 이름보다 운영 트리거로 구분하는 편이 낫다. 기본값은 Advanced RAG이며, naive로 시작하더라도 query rewriting, hybrid, rerank, citation과 faithfulness gate 순서로 보강해야 production baseline이 된다. Self-RAG는 LLM이 검색 필요 여부를 판단하고 검색과 자기 평가를 거쳐 답변한다. Corrective RAG는 검색 결과 신뢰도를 평가하고 부족하면 web search로 보완한다. GraphRAG는 문서를 entity와 관계 그래프로 바꾸고 community detection을 통해 글로벌 question에 강하다. Agentic RAG는 agent가 검색, DB, 도구를 여러 번 호출하는 구조다.
09
이 변형들은 멋있어서 올리는 것이 아니라 깨지는 조건이 있을 때 선택한다. GraphRAG는 정답이 단일 chunk에 없고 여러 문서의 entity 관계나 community summary를 합쳐야 할 때 의미가 있다. Corrective RAG와 Self-RAG는 검색 결과 신뢰도 점수가 낮을 때 refusal이나 web, manual fallback이 필요한 도메인에 맞다. Modular RAG는 같은 서비스 안에서 HR, 법무, 코드검색처럼 retriever와 filter 정책이 다를 때 필요하다. Agentic RAG는 검색 뒤에 DB 조회, ticket 생성, 권한 확인 같은 tool action이 이어질 때 선택한다.
10
RAG가 항상 정답은 아니다. 자주 갱신되고 출처 인용이 필요하면 RAG가 맞고, 정형 도메인 행동이나 persona, 말투, JSON schema 일관성이 핵심이면 fine-tune이 더 맞다. 한 번에 넣을 수 있고 단발 작업이면 long-context가 유리할 수 있다. 코퍼스 갱신이 1년에 1~2회뿐이면 RAG의 갱신 우위가 사라지고 fine-tune의 호출당 단가 우위만 남는다. 호출량이 월 10k 미만처럼 매우 적으면 벡터 DB hosting과 재색인 인프라 고정비를 회수하기 어려워 long-context가 나을 수 있다.
11
평가는 RAG 운영의 중심이다. Ragas의 4가지 지표는 Faithfulness, Answer Relevance, Context Precision, Context Recall로 정리된다. Faithfulness는 답변이 검색된 문서에 근거하는지를 보며, production 게이트는 0.8 이상, 의료·법률·금융은 0.9 이상으로 제시된다. 0.6은 답변 문장의 약 40%가 검색 결과에 근거하지 않는다는 의미로 해석된다. 다만 Ragas 자체도 깨질 수 있다. FinanceBench 평가에서 default Ragas Faithfulness는 샘플의 83.5%에서 점수를 산출하지 못했으므로, 표·숫자 위주 도메인은 custom rubric이나 cleanlab TLM 같은 독립 검출기를 병행해야 한다.
12
운영에서 가장 위험한 문제는 조용히 실패하는 silent failure다. Stale data는 문서가 갱신됐는데 embedding이 갱신되지 않은 상태이고, Permission leak은 권한 없는 문서가 검색에 노출되는 문제다. Top-K가 너무 크면 lost-in-the-middle과 비용 증가가 생기고, Query mismatch는 사용자 질문 스타일과 문서 표현이 달라 recall이 떨어지는 상황이다. Reranker 누락은 검색은 됐지만 정렬이 엉망인 상태를 만든다. 특히 faithfulness 검증이 빠지면 환각 답변이 citation 형식까지 갖춰 정상 응답처럼 보일 수 있어 가장 알아차리기 어렵다.
13
플랫폼 엔지니어 관점에서 RAG는 검색, 컨텍스트 주입, 합성의 3단계 패턴으로 볼 수 있다. Retrieval은 DB SELECT, search query, cache lookup과 닮아 있고, Augmentation은 template rendering이나 dynamic config injection에 가깝다. Generation은 response synthesis나 materialized view로 볼 수 있으며, Faithfulness 강제는 data validation과 contract test에 대응된다. 그래서 RAG는 사내 문서 챗봇, 고객 지원, 코드 어시스턴트, 의료·법률 문서, 뉴스 요약, agent의 knowledge layer에 연결된다. 핵심은 외부 지식 검색과 출처 인용, 그리고 실패 시 멈추는 기준을 함께 운영하는 것이다.

같은 레이어

L12에서 이어 듣기

원본 문서: content/topics/L12/rag-fundamentals.md
오디오 파일: /podcasts/l12-rag-fundamentals.mp3