RAG의 원리

이 장에서 배울 것

이전 장에서는 프롬프트를 더 잘 쓰는 방법을 배웠다. 역할을 정하고, 출력 형식을 지정하고, 예시를 주면 LLM의 답변 품질은 좋아진다. 하지만 프롬프트만으로 해결하기 어려운 문제가 있다.

예를 들어 회사 내부 규정, 최신 공지, 제품 매뉴얼, 계약서 조항처럼 모델이 원래 학습하지 않았거나 자주 바뀌는 정보가 필요할 때다. 이때 사용하는 대표적인 설계 방식이 RAG다.

RAG는 Retrieval-Augmented Generation의 줄임말이다. 우리말로 풀면 검색으로 보강한 생성이다. 핵심은 간단하다. 먼저 질문과 관련된 문서를 찾고, 그 문서를 근거로 LLM이 답하게 한다.

이 장에서는 다음을 배운다.

• RAG가 필요한 상황

• RAG의 전체 파이프라인

• 프롬프트에 지식을 직접 넣는 방식과 RAG의 차이

• 한국어 문서에서 검색 품질을 떨어뜨리는 요인

• 작은 FAQ 문서로 검색 결과를 직접 평가하는 방법

• RAG를 사용할 때 흔히 하는 실수

왜 이 주제가 중요한가

LLM은 많은 것을 알고 있는 것처럼 보인다. 하지만 모든 것을 알고 있지는 않다. 더 중요한 점은, 알고 있는 것처럼 답할 수 있다는 것이다. 이 현상을 hallucination, 즉 그럴듯한 허위 답변이라고 부른다.

프롬프트만 잘 쓰면 어느 정도 줄일 수 있다. 예를 들어 모르면 모른다고 답하라고 지시할 수 있다. 그러나 모델에게 필요한 근거 문서가 없으면 정확한 답을 보장하기 어렵다.

RAG는 이 문제를 시스템 설계로 다룬다. LLM에게 모든 것을 외우게 하는 대신, 필요한 순간에 신뢰할 수 있는 문서를 찾아 제공한다. 따라서 RAG의 목적은 LLM의 기억을 마법처럼 늘리는 것이 아니다. 답변에 사용할 근거를 외부에서 찾아 넣는 것이다.

이 차이를 이해해야 한다. RAG는 모델 자체를 바꾸는 기술이 아니다. 문서를 준비하고, 잘게 나누고, 검색하고, 검색된 문서를 프롬프트에 넣고, 그 근거 안에서 답하게 만드는 전체 흐름이다.

핵심 개념 설명

RAG의 기본 파이프라인은 다음 순서로 이해할 수 있다.

1. 질문 입력

2. 문서 수집

3. 청킹

4. 임베딩

5. 벡터 저장소 저장

6. 검색

7. 재순위화

8. 컨텍스트 주입

9. 답변 생성

각 단계를 차례로 보자.

질문 입력

사용자가 질문을 입력한다. 예를 들어 다음과 같다.

• 환불 신청은 구매 후 며칠 안에 가능한가요?

• 사내 노트북 반납 절차를 알려 주세요.

• 제품 A의 보증 기간은 얼마인가요?

LLM에게 바로 물으면 일반적인 답을 할 수는 있다. 하지만 회사나 제품마다 규정이 다르기 때문에 문서 기반 답변이 필요하다.

문서 수집

먼저 답변 근거가 될 문서를 모은다. FAQ, 매뉴얼, 약관, 공지사항, 내부 위키, PDF, 상담 스크립트 등이 여기에 포함된다.

이 단계에서 중요한 것은 문서의 신뢰도다. 오래된 문서와 최신 문서가 섞여 있으면 검색은 성공해도 답변은 틀릴 수 있다. RAG의 품질은 모델보다 문서 관리에 더 크게 흔들릴 때가 많다.

청킹

청킹은 긴 문서를 작은 조각으로 나누는 작업이다. 조각 하나를 청크라고 부른다.

예를 들어 30쪽짜리 PDF 전체를 한 번에 검색 대상으로 삼으면 너무 크다. 반대로 한 문장씩 자르면 맥락이 끊긴다. 그래서 보통 문단, 소제목, 목록 단위로 의미가 유지되도록 나눈다.

청크가 너무 크면 질문과 정확히 맞는 부분을 찾기 어렵다. 청크가 너무 작으면 필요한 조건이나 예외 조항이 빠질 수 있다.

임베딩

임베딩은 텍스트를 숫자 벡터로 바꾸는 일이다. 2장에서 배운 것처럼 모델은 텍스트를 그대로 계산하지 못한다. 의미가 비슷한 문장들이 가까운 위치에 놓이도록 숫자로 표현한다.

예를 들어 환불 기간과 반품 가능일은 표현은 다르지만 의미가 가깝다. 임베딩 검색은 이런 의미적 유사성을 활용한다.

벡터 저장소

문서 청크를 임베딩한 뒤에는 벡터 저장소에 넣는다. 벡터 저장소는 질문 벡터와 가까운 문서 벡터를 빠르게 찾기 위한 저장 공간이다.

일반 데이터베이스가 정확한 키워드나 조건 검색에 강하다면, 벡터 저장소는 의미가 비슷한 문서를 찾는 데 강하다.

검색

사용자 질문도 임베딩으로 바꾼다. 그리고 벡터 저장소에서 질문과 가까운 문서 청크를 찾는다. 보통 상위 k개를 가져오는데, 이를 top-k 검색이라고 한다.

예를 들어 top-k가 3이면 가장 관련 있어 보이는 문서 3개를 가져온다. k가 너무 작으면 필요한 문서가 빠질 수 있고, 너무 크면 관련 없는 문서가 섞여 답변 품질이 떨어질 수 있다.

재순위화

재순위화는 검색된 후보 문서들을 다시 정렬하는 과정이다. 처음 검색은 빠르게 넓게 찾고, 재순위화는 질문과 문서의 관련성을 더 꼼꼼히 판단한다.

항상 필요한 단계는 아니지만, 문서가 많거나 질문이 복잡할수록 도움이 된다. 특히 비슷한 문서가 많은 FAQ, 정책 문서, 제품 매뉴얼에서는 유용하다.

컨텍스트 주입

검색된 문서를 LLM 프롬프트에 넣는다. 이를 컨텍스트 주입이라고 한다. 여기서 컨텍스트는 답변에 참고할 근거 자료를 뜻한다.

좋은 RAG 프롬프트는 보통 다음 규칙을 포함한다.

• 제공된 문서만 근거로 답하라.

• 문서에 없으면 없다고 말하라.

• 답변에 사용한 출처를 표시하라.

• 서로 충돌하는 문서가 있으면 최신 문서를 우선하라.

이 규칙이 없으면 모델은 검색 문서를 참고하되, 자신의 기존 지식이나 추측을 섞을 수 있다.

답변 생성

마지막으로 LLM이 검색된 문서를 바탕으로 답변을 만든다. 이때 답변 품질은 세 가지에 달려 있다.

첫째, 관련 문서를 제대로 찾았는가. 둘째, 찾은 문서가 신뢰할 수 있는가. 셋째, 모델이 문서 근거 안에서 답했는가.

RAG에서 생성은 마지막 단계다. 앞의 검색과 문서 준비가 좋지 않으면 아무리 좋은 모델을 써도 답변은 흔들린다.

프롬프트에 직접 넣기와 RAG의 차이

작은 지식은 프롬프트에 직접 넣을 수 있다. 예를 들어 이벤트 안내 문구 한 개나 짧은 정책 하나는 시스템 프롬프트에 포함해도 된다. 하지만 문서가 많아지고 자주 바뀌면 문제가 생긴다.

프롬프트에 직접 넣는 방식은 간단하다. 빠르게 실험할 때 좋다. 반면 RAG는 구축할 것이 많다. 문서 수집, 청킹, 임베딩, 검색, 평가가 필요하다.

따라서 모든 문제에 RAG를 붙일 필요는 없다. 기준은 명확하다. 지식이 적고 잘 변하지 않으면 프롬프트로 충분하다. 지식이 많고 자주 바뀌며 출처가 중요하면 RAG가 적합하다.

쉬운 비유 또는 사례

LLM을 시험 보는 학생이라고 생각해 보자. 프롬프트는 시험지 위에 적힌 지시문이다. 지시문을 잘 쓰면 답안 형식은 좋아진다. 하지만 학생이 교재 내용을 모르면 정확한 답을 쓰기 어렵다.

RAG는 시험 전에 필요한 교재 페이지를 찾아 책상 위에 펼쳐 주는 방식이다. 학생이 책을 전부 외울 필요는 없다. 대신 질문과 관련된 페이지를 잘 찾아야 한다.

문제는 여기서 생긴다. 엉뚱한 페이지를 펼쳐 주면 학생은 그 페이지를 보고도 틀린 답을 할 수 있다. 너무 많은 페이지를 펼쳐 주면 중요한 부분을 놓칠 수 있다. 오래된 교재를 주면 답변도 오래된 기준을 따를 수 있다.

그래서 RAG의 핵심은 단순히 문서를 많이 넣는 것이 아니다. 필요한 문서를 정확히 찾아, 답변에 쓸 수 있는 형태로 제공하는 것이다.

한국어 문서에서 특히 주의할 점

한국어 RAG는 영어 문서보다 신경 쓸 부분이 많다. 한국어가 어렵다는 뜻이 아니라, 실제 업무 문서의 형태가 다양하기 때문이다.

청크 크기

한국어 정책 문서는 한 문장 안에 조건이 많이 들어간다.

예를 들어 구매 후 7일 이내에는 환불 가능하나, 개봉 상품은 제품 하자가 있는 경우에만 가능하다는 문장이 있다고 하자. 이 문장을 잘못 나누면 환불 가능이라는 정보만 남고 개봉 상품 예외 조건이 빠질 수 있다.

청크는 의미 단위로 나누어야 한다. 숫자 조건, 예외, 적용 대상은 같은 청크 안에 남기는 편이 안전하다.

문단 경계

소제목과 본문이 분리되면 의미가 약해질 수 있다. 예를 들어 소제목이 계약 해지이고 본문에 30일 전 통보라고만 되어 있다면, 본문만 검색될 때 무엇을 30일 전 통보해야 하는지 불분명하다.

청크를 만들 때는 소제목을 본문 앞에 붙여 주는 것이 좋다.

표와 목록

한국어 업무 문서에는 표가 많다. PDF에서 표를 추출하면 열과 행이 깨지는 경우가 있다. 그러면 검색 결과에 제품명과 보증 기간이 잘못 연결될 수 있다.

표는 가능하면 행 단위로 풀어 쓰는 것이 좋다. 예를 들어 제품 A 보증 기간은 1년, 제품 B 보증 기간은 2년처럼 문장 형태로 바꾸면 검색과 답변이 쉬워진다.

PDF 추출 품질

PDF에서 복사한 텍스트는 줄바꿈, 머리말, 꼬리말, 페이지 번호가 섞일 수 있다. 이 잡음은 검색 품질을 떨어뜨린다.

RAG를 만들기 전에는 문서 정제가 필요하다. 중복된 페이지 제목, 의미 없는 번호, 깨진 문자를 제거해야 한다.

메타데이터

메타데이터는 문서에 붙이는 추가 정보다. 예를 들어 문서 제목, 작성일, 부서, 버전, 카테고리, URL 같은 정보다.

메타데이터가 있으면 검색 결과를 더 잘 통제할 수 있다. 최신 문서만 검색하거나, 고객지원 FAQ만 대상으로 검색하거나, 특정 제품 문서만 필터링할 수 있다.

직접 해보는 실습

이번 실습에서는 작은 한국어 FAQ 문서 묶음을 만들고, 질문에 대해 어떤 문서가 top-k로 나와야 하는지 직접 판정한다. 실제 임베딩 API나 벡터 저장소를 붙이기 전에도 이 평가 습관이 중요하다.

1단계: FAQ 문서 만들기

다음과 같은 FAQ 6개를 준비한다.

2단계: 질문 만들기

다음 질문을 사용한다.

• Q1. 개봉한 상품을 단순 변심으로 환불할 수 있나요?

• Q2. 하자가 있는 제품은 언제까지 환불되나요?

• Q3. 다음 달 구독 결제를 막으려면 언제 해지해야 하나요?

• Q4. 물건이 이미 출고됐는데 주소를 바꿀 수 있나요?

3단계: 기대 top-k 판정하기

각 질문에 대해 가장 관련 있는 문서를 직접 고른다.

이제 실제 임베딩 검색을 붙였다고 가정하고 결과를 비교한다. 만약 Q1의 top-1이 D2로 나온다면 완전히 틀린 것은 아니지만 부족하다. D2는 제품 하자에 대한 문서이고, Q1은 단순 변심과 개봉 여부를 묻기 때문이다.

검색 결과를 볼 때는 단순히 비슷한 단어가 있는지가 아니라 질문의 의도와 답변 조건이 맞는지를 확인해야 한다.

4단계: 평가 기록 남기기

다음 형식으로 기록한다.

정답 문서가 top-3 안에 들어오면 생성 단계에서 답할 가능성이 생긴다. 하지만 top-3 안에 있어도 관련 없는 문서가 너무 강하게 섞이면 답변이 흔들릴 수 있다.

이 실습의 목표는 완벽한 검색 시스템을 만드는 것이 아니다. RAG에서 검색 품질을 직접 판정하는 감각을 기르는 것이다.

흔한 실수와 오류 분석

실수 1. RAG를 붙이면 hallucination이 사라진다고 믿는다

RAG는 hallucination을 줄일 수 있지만 없애지는 못한다. 검색된 문서가 틀렸거나, 관련 문서가 빠졌거나, 모델이 문서 밖의 내용을 섞으면 여전히 잘못된 답변이 나온다.

따라서 답변 프롬프트에는 문서에 없는 내용은 답하지 말라는 규칙이 필요하다. 또한 답변에는 출처를 붙이는 것이 좋다.

실수 2. 문서를 너무 크게 자른다

문서 하나를 통째로 넣으면 검색은 대충 맞아 보여도 답변 근거가 흐려진다. 긴 청크 안에는 여러 주제가 섞이기 때문이다. 이 경우 모델이 질문과 관련 없는 부분을 근거처럼 사용할 수 있다.

실수 3. 문서를 너무 작게 자른다

반대로 한 문장씩 자르면 조건이 끊긴다. 환불 가능이라는 문장과 예외 조건 문장이 분리되면 잘못된 답변이 나올 수 있다.

청킹의 기준은 글자 수만이 아니다. 의미가 유지되는지가 더 중요하다.

실수 4. 출처 없는 답변을 허용한다

RAG 답변에 출처가 없으면 검증하기 어렵다. 사용자는 답변이 문서에서 온 것인지 모델의 추측인지 알 수 없다.

실무에서는 최소한 문서 제목, 문서 ID, 업데이트 날짜 정도를 함께 보여 주는 것이 좋다.

실수 5. 최신 문서와 오래된 문서를 섞어 둔다

오래된 정책 문서가 검색되면 모델은 오래된 기준으로 답할 수 있다. 문서에는 버전과 날짜를 붙이고, 검색 단계에서 최신 문서를 우선하도록 설계해야 한다.

요약

RAG는 LLM이 답하기 전에 관련 문서를 검색해 근거로 제공하는 시스템 설계 패턴이다. 모델을 다시 학습시키는 것이 아니라, 질문에 맞는 외부 문서를 찾아 프롬프트에 넣는 방식이다.

전체 흐름은 질문 입력, 문서 수집, 청킹, 임베딩, 벡터 저장소, 검색, 재순위화, 컨텍스트 주입, 답변 생성으로 이어진다.

프롬프트에 지식을 직접 넣는 방식은 간단하지만, 지식이 많고 자주 바뀌면 유지보수가 어렵다. RAG는 구축 비용이 있지만 최신성, 출처 관리, 문서 기반 답변에 강하다.

한국어 문서에서는 청크 크기, 문단 경계, 표와 목록, PDF 추출 품질, 메타데이터가 검색 품질에 큰 영향을 준다. 좋은 RAG는 좋은 모델만으로 만들어지지 않는다. 좋은 문서 준비와 검색 평가가 함께 필요하다.

퀴즈

1. RAG에서 Retrieval은 무엇을 뜻하는가?

2. RAG가 LLM의 hallucination을 완전히 없애지 못하는 이유는 무엇인가?

3. 청크가 너무 작을 때 생길 수 있는 문제는 무엇인가?

4. 프롬프트에 지식을 직접 넣는 방식보다 RAG가 더 적합한 상황은 언제인가?

5. 한국어 PDF 문서를 RAG에 넣기 전에 확인해야 할 점을 두 가지 쓰시오.

체크리스트

• RAG가 검색으로 보강한 생성 방식임을 설명할 수 있다.

• RAG의 전체 파이프라인을 순서대로 말할 수 있다.

• 프롬프트 직접 주입과 RAG의 차이를 최신성, 유지보수성, 비용 관점에서 비교할 수 있다.

• 한국어 문서에서 청킹과 메타데이터가 중요한 이유를 설명할 수 있다.

• 작은 FAQ 문서 묶음에서 질문별 기대 top-k 결과를 판정할 수 있다.

• RAG를 붙여도 출처 확인과 답변 검증이 필요하다는 점을 이해했다.

다음 장 연결

이번 장에서는 LLM에게 필요한 문서를 찾아 넣는 RAG의 흐름을 배웠다. 다음 장에서는 LLM이 단순히 문서를 읽고 답하는 것을 넘어, 외부 도구를 호출하는 방법을 배운다.

예를 들어 재고 조회, 주문 취소, 일정 등록, 계산기 실행처럼 실제 행동이 필요한 작업이 있다. 이런 경우에는 문서 검색만으로 부족하다. 다음 장의 주제는 Function calling과 도구 사용이다.