Blog,미분류,엔터프라이즈 AI

RAG는 외부 지식 저장소에서 질문과 관련된 문서를 검색(retrieval)해, 그 내용을 근거로 LLM이 답변을 생성(generation)하게 하는 기법입니다(AWS; IBM). 2020년 Meta(당시 Facebook AI) 연구진이 지식 집약적 작업에서 언어 모델과 검색기를 결합하는 방법으로 처음 제안했습니다(Lewis et al., 2020, arXiv:2005.11401).

RAG가 겨냥하는 문제는 LLM의 구조적 한계 두 가지입니다. 첫째는 최신성 한계입니다. 모델의 지식은 학습 데이터 수집 시점에 멈춰 있어, 어제 개정된 사내 규정이나 오늘 등록된 장애 보고서를 알지 못합니다. 둘째는 환각(hallucination — 근거 없는 내용을 사실처럼 생성하는 현상)입니다. 모델은 답을 모를 때도 확률적으로 그럴듯한 문장을 만들어 냅니다. LLM이 왜 이렇게 동작하는지는 클러스터 글 LLM이란 무엇인가에서 원리부터 설명합니다.

환각이 위험한 이유는 틀렸다는 사실이 문장 표면에 드러나지 않기 때문입니다. 위 사례처럼 인물·연도·기능이 뒤바뀐 답변도 문법과 어조는 정상적인 설명문 그대로여서, 해당 분야를 모르는 사용자는 진위를 가릴 단서를 얻지 못합니다. 게다가 확률 기반 생성이라 같은 질문에도 어떤 날은 맞고 어떤 날은 틀립니다. 사내 규정이나 장애 이력처럼 정답이 이미 문서로 존재하는 영역에서 이런 답변이 나오는 것은 모델의 지식이 부족해서가 아니라 그 문서가 모델에게 주어지지 않았기 때문이며, RAG는 바로 이 지점을 메웁니다.

RAG는 두 한계를 “시험 전에 교과서를 쥐여 주는” 방식으로 우회합니다. 답변 시점에 최신 문서를 검색해 근거로 제공하므로 지식이 낡지 않고, 모델에게 “이 근거 안에서 답하라”고 제약하므로 환각이 줄어들며, 어떤 문서를 참조했는지 출처를 표시할 수 있어 답변 검증이 가능해집니다(AWS). 모델 재학습이 필요 없어 문서가 바뀔 때마다 저장소만 갱신하면 된다는 점이 기업 환경에서 특히 큰 장점입니다.

RAG 파이프라인은 문서를 미리 준비하는 색인 단계와 질문을 처리하는 응답 단계로 나뉘며, 전체 흐름은 여섯 단계로 정리됩니다.

[색인 단계 — 사전 준비]
문서 수집 → 청킹(분할) → 임베딩(벡터 변환) → 벡터 DB 저장

[응답 단계 — 질문 처리]
질문 임베딩 → 유사도 검색(top-k) → 근거 + 질문을 LLM에 전달 → 답변 생성(+출처)

1단계, 문서 수집. 사내 위키·규정집·매뉴얼·티켓 등 근거가 될 문서를 모으고 텍스트를 추출합니다. 이 단계의 품질이 전체 상한선입니다. 중복되거나 낡은 문서가 섞이면 검색이 오염됩니다.

2단계, 청킹(chunking — 문서를 검색 단위의 조각으로 나누는 작업). LLM의 입력 길이에는 한계가 있으므로 문서를 적절한 크기로 자릅니다. 너무 크게 자르면 관련 없는 내용이 섞여 검색 정밀도가 떨어지고, 너무 잘게 자르면 문맥이 끊깁니다. 절·항 같은 문서의 의미 단위를 살려 자르는 것이 기본 원칙입니다.

3단계, 임베딩(embedding — 텍스트를 의미를 담은 숫자 벡터로 변환하는 것). 임베딩 모델이 각 조각을 고차원 벡터로 바꿉니다. 의미가 비슷한 텍스트는 벡터 공간에서 가까운 위치에 놓이므로, 단어가 달라도 뜻이 통하는 문서를 찾을 수 있게 됩니다(IBM).

4단계, 벡터 DB 저장. 변환된 벡터를 원문 조각·메타데이터와 함께 벡터 데이터베이스에 저장합니다.

5단계, 검색. 사용자 질문을 같은 임베딩 모델로 벡터화한 뒤, 벡터 DB에서 가장 유사한 조각 상위 k개를 추출합니다.

6단계, 생성. 검색된 근거와 질문을 함께 프롬프트에 담아 LLM에 전달하고, 근거에 기반한 답변을 출처와 함께 생성합니다(AWS).

도해에서 눈여겨볼 것은 인덱싱과 질의가 서로 다른 시점에 도는 별개의 파이프라인이라는 점입니다. 문서는 미리 벡터화해 저장해 두고, 사용자가 질문한 순간에는 검색과 생성만 수행합니다. 이 분리가 응답 속도를 만들어 내는 구조적 이유이며, 동시에 색인이 낡으면 아무리 좋은 모델을 붙여도 답이 낡는 이유이기도 합니다.

운영 관점에서 한 겹 더 들어가면, 임베딩·검색·생성을 각각 독립 서비스로 떼어 두는 구성이 실무에서 유리합니다. 세 단계는 부하 특성이 전혀 다릅니다. 문서를 대량 적재하는 날에는 임베딩에, 사용자가 몰리는 시간대에는 검색과 생성에 부하가 걸리므로, 한 덩어리로 묶어 두면 병목 구간 하나 때문에 전체를 함께 키워야 합니다. 게이트웨이를 앞에 두면 모델을 교체할 때도 게이트웨이 뒤만 바꾸면 되고 업무 애플리케이션은 그대로 유지됩니다.

이 구조에서 실무자가 기억할 요점은 하나입니다. RAG의 품질 문제는 대부분 생성이 아니라 검색에서 생깁니다. 답이 이상하면 모델을 바꾸기 전에 “올바른 조각이 검색되고 있는가”부터 확인해야 합니다.

벡터 데이터베이스는 수백만~수억 개의 벡터에서 질문 벡터와 가까운 이웃을 빠르게 찾도록 설계된 저장소입니다. 두 벡터가 얼마나 같은 방향을 가리키는지 재는 코사인 유사도(cosine similarity)가 대표적인 거리 척도이며, 전체를 일일이 비교하는 대신 근사 최근접 탐색(ANN, Approximate Nearest Neighbor) 색인으로 속도를 확보합니다.

선택지는 크게 세 갈래입니다. 전용 벡터 DB(Milvus, Weaviate, Qdrant 등), 기존 DB의 벡터 확장(PostgreSQL의 pgvector 등), 그리고 검색 엔진 계열(OpenSearch, Elasticsearch의 벡터 기능)입니다. 어느 것이 정답이라기보다 조건이 답을 정합니다. 문서가 수십만 건 이하라면 이미 운영 중인 PostgreSQL에 pgvector를 얹는 편이 운영 부담이 가장 적고, 대규모·고트래픽이라면 전용 벡터 DB의 색인 성능과 확장 기능이 필요해집니다. 판단 기준은 데이터 규모, 갱신 빈도, 기존 운영 역량과의 궁합, 그리고 접근 권한 필터링 같은 기업 요건의 지원 여부입니다.

벡터와 함께 저장하는 메타데이터의 설계도 검색 품질에 직결됩니다. 문서의 부서·문서 유형·개정일·접근 등급을 메타데이터로 붙여 두면, 검색 시점에 “인사 규정 중 최신본만” 같은 조건 필터를 벡터 유사도와 결합할 수 있습니다. 기업 RAG에서 요구되는 권한 통제도 이 메타데이터 필터가 실행 지점이 되므로, 색인 단계에서 메타데이터 스키마를 정해 두는 것이 나중에 고치는 것보다 훨씬 쌉니다.

한 가지 실무 조언을 보태면, 초기 검증 단계에서는 벡터 DB 선택에 시간을 오래 쓰지 않는 것이 좋습니다. 파이프라인의 품질은 벡터 DB 제품보다 청킹과 검색 전략에서 훨씬 크게 갈리기 때문입니다.

기준은 “가르치려는 것이 지식인가, 행동인가”입니다. 최신 문서·사실·수치를 답변에 반영하는 것이 목적이라면 RAG가 맞고, 답변의 문체·형식·도메인 말투를 모델에 배게 하는 것이 목적이라면 파인튜닝(fine-tuning — 사전 학습된 모델을 자사 데이터로 추가 학습하는 것)이 맞습니다(IBM).

기업 도입 순서에서 RAG가 먼저 검토되는 이유가 이 표에 담겨 있습니다. 갱신이 빠르고, 출처를 남길 수 있고, 권한 통제가 가능하다는 세 가지가 기업 요건과 정확히 맞물리기 때문입니다. 특히 마지막 줄이 중요합니다. 파인튜닝으로 모델에 흡수된 지식은 누구에게나 노출될 수 있지만, RAG는 검색 시점에 사용자 권한으로 문서를 거를 수 있습니다.

이 판단을 두 축의 사분면으로 놓으면 선택이 한결 단순해집니다. 가로축은 외부 지식을 얼마나 끌어 쓰는가(컨텍스트 최적화), 세로축은 모델이 어떻게 행동하게 할 것인가(모델 적응)입니다. 답이 틀리는 원인이 지식 부족이면 가로축을 올리고, 말투나 형식이 흔들리는 것이 문제이면 세로축을 올립니다. 둘 다 문제라면 오른쪽 위, 즉 결합 구성으로 갑니다.

두 방식은 배타적이지 않습니다. 도메인 말투는 파인튜닝으로 배게 하고 최신 사실은 RAG로 붙이는 결합 구성이 실무에서 자주 쓰이며, 여행 예약처럼 외부 데이터 조회와 일관된 응대 형식이 동시에 필요한 업무가 전형적인 사례입니다. 다만 착수 순서는 프롬프트 → RAG → 파인튜닝을 지키는 편이 낫습니다. 비용과 되돌리기 난이도가 그 순서대로 커지므로, 앞 단계로 해결되는 문제에 뒤 단계를 쓰면 지출만 늘어납니다. 파인튜닝이나 자체 서빙을 자사 인프라에서 수행할 때 마주하는 경량 모델 선택 문제는 프라이빗 sLLM 도입과 TCO 자료에서 다룹니다.

RAG 고도화의 실체는 검색 품질 개선이며, 지렛대는 세 곳에 있습니다.

첫째, 청킹 전략입니다. 고정 길이로 기계적으로 자르는 방식은 구현이 쉽지만 문장·문단을 중간에서 끊습니다. 제목·절 단위로 자르는 구조 기반 청킹, 인접 조각과 일부를 겹치게 하는 오버랩, 조각에 문서 제목·상위 절 정보를 메타데이터로 붙이는 보강이 기본 개선 수순입니다. 같은 문서 집합이라도 청킹만 바꿔 검색 적중률이 크게 달라지는 경우가 흔합니다.

둘째, 하이브리드 검색입니다. 벡터 검색은 의미가 비슷한 문서를 잘 찾지만, 제품 코드·오류 번호·고유명사처럼 글자가 정확히 일치해야 하는 질의에 약합니다. 키워드 기반 검색(BM25 등)과 벡터 검색을 결합한 하이브리드 검색은 두 방식의 약점을 상호 보완해, 기업 문서처럼 코드와 용어가 많은 환경에서 사실상 표준 구성입니다.

셋째, 리랭킹(re-ranking — 1차 검색 결과를 더 정밀한 모델로 다시 정렬하는 것)입니다. 벡터 검색이 넓게 후보를 가져오면, 리랭커가 질문과 후보의 관련도를 정밀 채점해 상위 결과를 다시 고릅니다. 계산 비용이 추가되지만 LLM에 전달되는 근거의 순도가 올라가 답변 품질이 눈에 띄게 개선됩니다.

이 세 가지를 조정하려면 “무엇이 좋아졌는지”를 재는 눈금이 필요합니다. 대표 질문 세트를 만들어 검색 적중률과 답변 정확도를 꾸준히 측정하는 평가(evaluation) 체계가 그 눈금이며, 다음 절의 체크리스트에서 다시 등장합니다.

여기까지가 기본형 RAG(Naive RAG 또는 Vector RAG로 불리는 벡터 검색 단독 구성)의 개선 범위입니다. 청킹과 하이브리드 검색, 리랭킹을 모두 손봐도 넘지 못하는 벽이 하나 남는데, 검색 단위가 문서 조각이라는 사실에서 오는 한계입니다.

조각으로 잘린 문서는 조각 사이의 연결을 잃습니다. 계약서의 특약이 본문 어느 조항을 수정하는지, 어떤 장애가 어떤 변경 작업에서 비롯됐는지 같은 관계는 원문에 분명히 적혀 있어도 벡터 공간에는 남지 않습니다. 그래서 기본형 RAG는 “A 부품을 쓰는 설비가 어느 라인에 있고 그 라인의 담당자는 누구인가”처럼 두세 단계를 건너야 답이 나오는 질문(멀티홉 추론)에 약합니다. 각 단계의 근거가 서로 다른 문서에 흩어져 있으면 유사도만으로는 그 경로를 이어 붙이지 못합니다.

GraphRAG는 문서에서 개체(entity)와 개체 사이의 관계를 뽑아 지식 그래프로 만들어 두고, 검색 시점에 그 관계선을 따라가는 방식입니다. 실무에서 쓰이는 형태는 대개 벡터를 버리고 그래프로 갈아타는 것이 아니라 둘을 잇는 하이브리드 구성이며, 2단계로 동작합니다.

1. 벡터로 진입한다. 거대한 그래프를 무작정 탐색하는 것은 비효율적이므로, 먼저 질문을 임베딩해 의미가 가장 가까운 조각이나 개체를 찾습니다. 이때 찾은 지점이 그래프 탐색의 출발점(앵커 노드)이 됩니다.
2. 그래프로 확장한다. 출발점에서 연결된 관계선을 타고 한 단계, 두 단계씩 범위를 넓혀 질문과 관련된 부분 그래프를 뽑아냅니다. LLM에는 텍스트 조각 대신 “이 부품은 저 설비의 구성요소” 같은 관계가 함께 담긴 근거가 전달됩니다.

기업 환경에서 이 구성이 갖는 값어치는 정확도만이 아닙니다. 답변이 그래프의 어느 경로를 거쳐 나왔는지 추적할 수 있어, “이 답은 규정집 3조 2항과 그에 연결된 사례를 근거로 했다”는 식으로 설명이 가능해집니다. 감사와 소명 의무가 있는 금융·법무·공공 업무에서 결정적인 차이를 만드는 지점입니다.

다만 대가가 있습니다. 개체와 관계를 추출해 그래프를 구축하는 인덱싱 비용, 그래프를 최신 상태로 유지하는 운영 부담, 그리고 검색 단계가 늘어난 만큼의 지연이 모두 추가됩니다. 그래서 처음부터 GraphRAG로 시작하기보다, 기본형 RAG를 운영하며 “관계를 못 봐서 틀리는 질문”이 실제로 쌓이는지 확인한 뒤 그 도메인에 한정해 그래프를 얹는 순서가 현실적입니다.

파일럿과 운영의 간격을 줄이려면 다음 여섯 항목을 착수 전에 점검해야 합니다.

• 문서 저장소 정비 — 검색 대상 문서가 어디에 있고, 최신본이 무엇인지 확정합니다. 낡은 문서와 중복본을 정리하는 것이 모델 튜닝보다 먼저입니다. 문서가 여러 도구에 흩어져 있다면 저장소를 하나로 모으는 작업이 선행 과제가 되며, 이때의 선택지는 설치형 문서 저장소 도입 가이드에서 다룹니다.
• 접근 권한 반영 — 부서별·등급별 열람 권한이 검색 단계에서 강제되는지 확인합니다. 권한 밖 문서가 답변 근거로 노출되면 그 자체가 보안 사고입니다.
• 출처 표시 — 답변에 참조 문서와 위치를 표시해 사용자가 검증할 수 있게 합니다. 출처 없는 RAG는 신뢰를 얻지 못해 사용률이 떨어집니다.
• 평가 체계 — 대표 질문 세트로 검색 적중률·답변 정확도를 정기 측정합니다. 눈금이 없으면 개선 작업이 감에 의존하게 됩니다.
• 갱신 파이프라인 — 문서 추가·수정 시 색인이 자동으로 따라가는 구조를 만듭니다. 색인이 낡으면 RAG의 최신성 장점이 사라집니다.
• 인프라 용량 계획 — 임베딩·검색·생성 각 단계의 지연과 비용을 측정합니다. 특히 LLM 추론이 전체 비용의 본체이므로, GPU 서빙 효율이 운영비를 좌우합니다. 이 주제는 vLLM으로 GPU 병목과 도입 비용 줄이기 자료에서 이어집니다.

네 번째 항목인 평가 체계는 무엇을 재느냐가 곧 무엇이 개선되느냐를 정하므로 조금 더 구체적으로 잡아 둘 필요가 있습니다. RAGAS(RAG Assessment)처럼 이 분야에서 통용되는 평가 프레임워크가 쓰는 지표를 빌리면 눈금을 세 묶음으로 나눌 수 있습니다.

• 검색 품질 — 검색된 문서가 질문과 실제로 관련이 있는가(컨텍스트 관련성), 정답에 필요한 핵심 근거를 빠뜨리지 않고 가져왔는가(근거 재현율). 관련 없는 조각이 섞일수록 LLM이 흔들리므로, 많이 가져오는 것과 잘 가져오는 것은 다릅니다.
• 생성 품질 — 답변이 검색된 근거 안에 머물러 있는가(충실성), 그리고 실제 정답과 일치하는가(정확성). 충실성은 환각을 직접 재는 지표여서 가장 먼저 봐야 합니다.
• 운영 지표 — 질문에서 답변까지의 전 구간 지연과 호출당 비용. 검색 단계를 정교하게 만들수록 느려지므로, 사용자가 견디는 응답 시간을 상한으로 두고 품질을 올리는 방식이 안전합니다.

여섯 항목을 관통하는 원칙은 RAG를 “모델 프로젝트”가 아니라 “데이터·운영 프로젝트”로 다루라는 것입니다. 검색되는 문서의 품질과 권한, 그리고 지속 갱신 체계가 갖춰지면 모델은 바꿔 끼울 수 있는 부품이 됩니다.

RAG는 기업이 LLM에서 실질 가치를 얻는 가장 검증된 경로입니다. 그리고 그 성패는 화려한 모델이 아니라 문서 정비, 검색 품질, 권한 통제라는 기본기에서 갈립니다. 자사 문서 저장소의 현재 상태를 점검하는 것부터가 RAG 도입의 실제 출발점이며, 이 기본기는 이후 AI 에이전트로 확장할 때도 그대로 토대가 됩니다. 에이전트가 도구를 쓰고 스스로 판단하려면 결국 신뢰할 수 있는 근거를 꺼내 오는 층이 필요하고, 그 층이 RAG이기 때문입니다.

RAG란 무엇인가요?

질문과 관련된 문서를 먼저 검색해 그 내용을 근거로 LLM이 답변을 생성하게 하는 기법입니다(AWS; IBM). 모델을 재학습하지 않고도 최신 사내 문서를 답변에 반영하고 출처를 표시할 수 있습니다.

RAG를 쓰면 환각이 완전히 사라지나요?

사라지지 않습니다. 근거를 제약하면 환각이 크게 줄지만, 검색이 잘못되거나 모델이 근거를 벗어나 답하는 경우는 남습니다. 출처 표시와 평가 체계, 중요 업무의 사람 검토를 함께 운영해야 합니다.

RAG와 파인튜닝 중 무엇을 먼저 검토해야 하나요?

대체로 RAG를 먼저 봅니다. 지식 갱신이 즉시 반영되고 출처 표시와 권한 통제가 가능해 기업 요건과 맞물리기 때문입니다. 문체·형식을 모델에 배게 해야 할 때 파인튜닝을 추가로 검토합니다.

벡터 DB는 무엇을 기준으로 고르나요?

데이터 규모, 갱신 빈도, 기존 운영 역량, 권한 필터링 지원이 기준입니다. 중소 규모라면 기존 DB의 벡터 확장(pgvector 등)으로 시작하고, 대규모·고트래픽에서 전용 벡터 DB를 검토하는 순서가 일반적입니다.

RAG 답변 품질이 낮으면 무엇부터 점검하나요?

검색 단계부터 점검합니다. 대표 질문으로 “올바른 조각이 상위에 검색되는가”를 확인하고, 문제라면 청킹 전략·하이브리드 검색·리랭킹 순으로 개선합니다. 모델 교체는 그다음 순서입니다.

GraphRAG는 언제 검토하나요?

문서 조각 사이의 관계를 따라가야 답이 나오는 질문에서 기본형 RAG가 반복적으로 틀릴 때 검토합니다. 그래프 구축·유지 비용이 추가되므로, 기본형 RAG를 먼저 운영해 그런 질문 유형이 실제로 쌓이는지 확인한 뒤 해당 도메인에 한정해 얹는 순서가 현실적입니다.

함께 읽으면 좋은 MSAP.ai 글

• 엔터프라이즈 AI란 무엇인가 — 아직도 Prompt? 이제는 AI 에이전트 시대 — 이 시리즈의 필러 글
• LLM이란 무엇인가 — 원리부터 기업 도입 판단까지 — RAG가 보완하려는 모델의 원리와 한계
• 생성형 AI와 판별형 AI — 원리 차이와 선택 기준 — 프롬프트·RAG·파인튜닝을 두 축으로 고르는 기술 선택 매트릭스
• AI 에이전트란 무엇인가 — 정의, 구조, 기업 도입 기준 — RAG로 확보한 근거 위에 자율 실행을 얹는 다음 단계
• AX(AI 전환)란 무엇인가 — 정의부터 DX와의 차이, 추진 4단계까지 — 조직 차원의 전환 로드맵

MSAP.ai 자료

• AI LLM 가속 엔진 vLLM — GPU 병목과 도입 비용 줄이기 — 검색 다음 단계인 추론 서빙의 비용 구조
• 프라이빗 sLLM Qwen 3.6 27B — 데이터 주권과 TCO를 함께 — 사내 문서를 외부로 내보내지 않는 모델 선택
• 노션 대체, 설치형 오픈소스 Docmost 도입 가이드 — RAG의 1차 데이터 소스가 되는 문서 저장소 정비
• OpsKnow Repo — AI 시대 인프라 운영을 위한 지식 저장소 — 운영 지식을 검색 가능한 형태로 축적하는 방법
• 공공기관 AI, 왜 온프레미스여야 하는가 — 문서 반출이 제한된 환경의 RAG 구성

MSAP.ai 제품·서비스

• MSAP.ai 소개 — AI 기반 MSA 플랫폼
• AINP(AI Native Platform) — 통합 옵저버빌리티와 LLM 기반 AIOps
• 컨설팅 서비스 — AI 사용 사례 워크숍·아키텍처 워크숍·PoC 지원
• 자료실 — 백서·발표자료 다운로드

외부 출처

• Lewis et al. — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (arXiv:2005.11401)
• AWS — What is RAG (Retrieval-Augmented Generation)?
• IBM — What Is Retrieval-Augmented Generation?
• Edge et al. — From Local to Global: A Graph RAG Approach to Query-Focused Summarization (arXiv:2404.16130)
• Ragas — RAG 평가 프레임워크 문서