12장. RAG가 필요한 이유

1. LLM은 모든 것을 알고 있지 않다

LLM은 많은 지식을 가지고 있다.

일반적인 개발 지식, 문서 작성 방법, 코드 예시, 기술 개념, 번역, 요약 같은 작업을 잘한다.

예를 들어 다음 질문에는 어느 정도 답할 수 있다.

REST API와 GraphQL의 차이를 알려줘.

JWT를 사용할 때 주의할 점을 알려줘.

Node.js에서 비밀번호를 안전하게 저장하는 방법을 알려줘.

이런 질문은 일반적인 지식에 가깝다.

하지만 LLM이 모든 정보를 알고 있는 것은 아니다.

특히 다음 정보는 알기 어렵다.

- 우리 회사 내부 정책
- 우리 서비스의 운영 매뉴얼
- 사내 개발 문서
- 특정 프로젝트의 설계 문서
- 최근 회의에서 결정된 내용
- 고객센터 처리 기준
- 장애 대응 절차
- 회사 내부 API 명세
- 최신 배포 이력

예를 들어 AI에게 이렇게 물어본다고 해보자.

우리 회사 회원 탈퇴 정책 알려줘.

AI는 답할 수 없다.

왜냐하면 “우리 회사”의 내부 정책 문서를 가지고 있지 않기 때문이다.

그런데도 AI가 답을 만들어낼 수는 있다.

일반적으로 회원 탈퇴 시 개인정보는 관련 법령에 따라 일정 기간 보관될 수 있으며...

이 답변은 그럴듯하다.

하지만 우리 회사의 실제 정책과 맞는지는 알 수 없다.

이것이 문제다.

LLM은 모르는 내용을 모른다고 말하기도 하지만,
때로는 일반적인 지식을 바탕으로 그럴듯한 답변을 만들어낸다.

실무에서는 이런 답변이 위험하다.

질문:
우리 서비스에서 환불 가능 기간은 며칠이야?

AI 답변:
일반적으로 결제 후 7일 이내 환불이 가능합니다.

실제 정책:
특정 상품은 사용 여부, 구매 유형, 이벤트 참여 여부에 따라 다름

AI가 일반적인 답을 했지만, 실제 회사 정책과 다르면 문제가 된다.

그래서 내부 문서나 최신 정보를 기반으로 답변하게 만드는 구조가 필요하다.

그 구조가 바로 RAG다.

RAG는 Retrieval-Augmented Generation의 약자다.
쉽게 말하면 AI가 답변하기 전에 관련 문서를 먼저 검색하고, 그 문서를 근거로 답변하게 만드는 방식이다.

2. LLM의 학습 지식만으로는 부족한 이유

LLM은 학습된 지식을 바탕으로 답변한다.

하지만 학습 지식에는 한계가 있다.

첫 번째 한계는 최신성이다.

AI 모델은 학습된 시점 이후의 정보를 모를 수 있다.

예를 들어 회사 정책이 지난달 바뀌었는데, AI가 그 문서를 보지 못했다면 최신 정책을 알 수 없다.

예전 정책:
회원 탈퇴 후 30일 동안 재가입 제한

새 정책:
회원 탈퇴 후 7일 동안 재가입 제한

AI가 예전 정보를 기준으로 답하면 운영상 문제가 생길 수 있다.

두 번째 한계는 내부 정보다.

LLM은 공개된 문서나 학습 데이터에 포함된 일반 정보를 기반으로 답한다.

하지만 회사 내부 문서, 코드, 회의록, 고객센터 매뉴얼은 기본적으로 알 수 없다.

AI가 모르는 정보:
- 우리 회사 관리자 권한 체계
- 특정 API의 내부 처리 흐름
- 장애 발생 시 보고 라인
- 운영팀의 신고 처리 기준
- 정산 예외 처리 정책

세 번째 한계는 도메인 특수성이다.

같은 단어라도 서비스마다 의미가 다를 수 있다.

예를 들어 “하트”라는 단어를 생각해보자.

일반적인 AI는 하트를 감정 표현이나 좋아요 기능으로 이해할 수 있다.

하지만 특정 방송 플랫폼에서는 하트가 후원 재화일 수 있다.

일반 의미:
하트 = 좋아요, 감정 표현

서비스 내부 의미:
하트 = 충전 가능한 후원 재화

이런 도메인 맥락을 AI에게 알려주지 않으면 잘못된 답변을 할 수 있다.

네 번째 한계는 근거 부족이다.

AI가 답을 하더라도 그 답이 어떤 문서를 근거로 한 것인지 알기 어렵다.

실무에서는 “그럴듯한 답”보다 “근거가 있는 답”이 중요하다.

나쁜 답변:
환불은 결제 후 7일 이내 가능합니다.

좋은 답변:
환불은 결제 후 7일 이내 가능하지만,
이미 사용된 하트는 환불 대상에서 제외됩니다.
근거: 고객센터 환불 정책 문서 > 2. 환불 가능 조건

RAG는 이런 문제를 줄이기 위해 사용한다.

3. RAG는 검색과 생성을 결합한 구조다

RAG는 크게 두 가지 과정을 결합한다.

검색 Retrieval
→ 생성 Generation

먼저 사용자의 질문과 관련 있는 문서를 검색한다.

그다음 검색된 문서를 AI에게 함께 전달하고,
AI가 그 내용을 바탕으로 답변을 생성한다.

흐름은 다음과 같다.

사용자 질문
→ 관련 문서 검색
→ 검색된 문서 조각을 AI에게 전달
→ AI가 문서를 근거로 답변 생성
→ 답변과 출처 제공

예를 들어 사용자가 이렇게 묻는다고 해보자.

회원 탈퇴 후 재가입은 언제부터 가능해?

RAG가 없다면 AI는 일반적인 답변을 할 수 있다.

일반적으로 회원 탈퇴 후 일정 기간이 지나면 재가입할 수 있습니다.

하지만 RAG가 있다면 먼저 내부 정책 문서를 검색한다.

검색된 문서:
회원 정책 문서 > 3. 탈퇴 및 재가입
- 회원 탈퇴 후 7일간 동일 계정 정보로 재가입할 수 없다.
- 부정 이용으로 제재된 계정은 별도 심사 대상이다.

그다음 AI는 검색된 문서를 근거로 답한다.

회원 탈퇴 후 동일 계정 정보로는 7일 동안 재가입할 수 없습니다.

다만 부정 이용으로 제재된 계정은 일반 재가입 기준과 다르게 별도 심사 대상입니다.

근거:
회원 정책 문서 > 3. 탈퇴 및 재가입

이 차이가 중요하다.

RAG는 AI가 모르는 정보를 억지로 추측하지 않게 하고,
검색된 문서를 바탕으로 답하게 만든다.

Retrieval은 검색을 의미한다.
Generation은 답변 생성을 의미한다.
RAG는 검색한 정보를 바탕으로 AI가 답변을 생성하게 만드는 구조다.

4. RAG가 필요한 대표적인 상황

RAG는 모든 AI 기능에 필요한 것은 아니다.

일반적인 문장 다듬기나 코드 예시 생성에는 RAG가 없어도 된다.

예를 들어 다음 작업은 RAG 없이도 가능하다.

- 이메일 문장 다듬기
- 코드 예시 작성
- 일반 개념 설명
- 회의록 요약
- 보고서 문체 개선

하지만 다음 상황에서는 RAG가 필요할 가능성이 높다.

- 사내 문서를 기반으로 답해야 한다.
- 최신 정책을 반영해야 한다.
- 답변에 출처가 필요하다.
- 사용자의 권한에 따라 접근 가능한 문서가 다르다.
- AI가 모르면 답하지 않아야 한다.
- 내부 용어와 도메인 지식이 중요하다.

예를 들어 사내 문서 검색 챗봇은 RAG가 거의 필수다.

질문:
관리자 권한 신청 절차 알려줘.

필요한 정보:
- 사내 보안 정책 문서
- 관리자 권한 신청 매뉴얼
- 승인 라인
- 최신 신청 양식

이런 정보는 AI가 기본적으로 알 수 없다.

고객센터 상담 보조도 RAG가 유용하다.

질문:
미성년자 결제 환불 기준은 어떻게 되나요?

필요한 정보:
- 회사 환불 정책
- 고객센터 처리 매뉴얼
- 법무 검토 문구
- 예외 처리 기준

개발 문서 검색에도 RAG가 좋다.

질문:
방송 시작 API는 어떤 순서로 처리돼?

필요한 정보:
- API 문서
- 시퀀스 다이어그램
- 코드 설명 문서
- 장애 이력

운영 매뉴얼 검색에도 사용할 수 있다.

질문:
Redis 장애가 발생하면 어떤 순서로 확인해야 해?

필요한 정보:
- 장애 대응 매뉴얼
- 모니터링 대시보드 설명
- 과거 장애 보고서
- 담당자 연락 체계

RAG는 AI에게 “우리 회사 문서를 읽고 답하게 하는 구조”라고 이해하면 쉽다.

5. RAG가 없을 때 생기는 문제

RAG 없이 내부 정보를 묻는 AI 기능을 만들면 여러 문제가 생길 수 있다.

첫 번째는 환각이다.

AI가 모르는 내용을 그럴듯하게 만들어낼 수 있다.

질문:
우리 회사 정산 지급일이 언제야?

AI 답변:
보통 매월 말일에 지급됩니다.

실제 정책:
매월 10일, 25일 2회 지급

AI가 일반적인 회사 관행을 바탕으로 답했지만 실제와 다르다.

두 번째는 근거 부족이다.

AI가 답을 해도 그 답이 어디서 나온 것인지 알 수 없다.

질문:
관리자 권한 신청은 누가 승인해?

AI 답변:
팀장 또는 보안 담당자가 승인합니다.

문제:
정확히 어떤 문서 기준인지 알 수 없음

세 번째는 최신 정보 반영 실패다.

내부 정책이 바뀌었는데 AI가 예전 정보를 답할 수 있다.

예전 문서:
엑셀 다운로드 권한은 모든 운영 관리자에게 제공

최신 문서:
개인정보 포함 엑셀 다운로드는 팀장 승인 필요

네 번째는 권한 문제다.

AI가 사용자가 보면 안 되는 문서의 내용을 답할 수 있다면 심각한 보안 문제가 된다.

일반 관리자:
정산 정책 상세 문서 접근 불가

하지만 AI가 해당 내용을 답변:
정산 수수료율과 예외 처리 기준 노출

RAG는 단순 검색 기능이 아니다.

제대로 설계하면 다음 문제를 함께 줄일 수 있다.

- AI의 추측 답변
- 출처 없는 답변
- 오래된 정보 기반 답변
- 권한 없는 문서 접근
- 내부 용어 오해

물론 RAG도 완벽하지는 않다.

검색이 잘못되면 답변도 잘못될 수 있다.

하지만 RAG가 없는 구조보다는 훨씬 통제하기 쉽다.

6. RAG의 기본 구성 요소

RAG 시스템은 보통 다음 요소로 구성된다.

문서 저장소
→ 문서 수집기
→ 문서 분할기
→ 임베딩 모델
→ 벡터DB
→ 검색기
→ LLM
→ 답변 생성기

하나씩 쉽게 살펴보자.

6.1 문서 저장소

문서 저장소는 AI가 참고할 원본 문서가 있는 곳이다.

- PDF
- Markdown
- HTML
- Google Docs
- Notion
- Wiki
- GitHub README
- 운영 매뉴얼
- API 문서

RAG는 결국 문서를 기반으로 답변한다.

그래서 문서 품질이 중요하다.

문서가 오래되었거나, 서로 충돌하거나, 제목이 불분명하면 RAG 품질도 떨어진다.

6.2 문서 수집기

문서 수집기는 원본 문서를 가져오는 역할을 한다.

Google Docs에서 문서 가져오기
GitHub에서 Markdown 가져오기
PDF에서 텍스트 추출하기
Wiki 페이지 수집하기

문서를 한 번만 수집할 수도 있고,
주기적으로 다시 수집할 수도 있다.

정책 문서처럼 자주 바뀌는 문서는 최신 동기화가 중요하다.

6.3 문서 분할기

긴 문서를 AI가 바로 검색하기 좋은 작은 단위로 나눈다.

예를 들어 50페이지짜리 운영 매뉴얼을 통째로 검색하면 효율이 떨어진다.

그래서 문서를 작은 조각으로 나눈다.

문서 전체:
운영 매뉴얼 50페이지

분할 후:
- 로그인 장애 대응
- 결제 장애 대응
- Redis 장애 대응
- 방송 입장 장애 대응
- 고객 공지 기준

이 작은 조각을 보통 chunk라고 부른다.

chunk는 긴 문서를 검색하기 좋은 작은 조각으로 나눈 단위다.
RAG에서는 질문과 관련 있는 chunk를 찾아 AI에게 전달한다.

6.4 임베딩 모델

임베딩 모델은 문장을 숫자 벡터로 바꾸는 모델이다.

AI가 문장을 그대로 비교하는 것이 아니라,
문장의 의미를 숫자 형태로 바꿔 비슷한 내용을 찾는다.

예를 들어 다음 두 문장은 표현은 다르지만 의미가 비슷하다.

하트 충전이 안 됐어요.
결제 후 재화가 반영되지 않았습니다.

임베딩을 사용하면 이런 문장들이 비슷한 의미라는 것을 찾을 수 있다.

임베딩은 문장이나 문서를 숫자 배열로 바꾸는 방식이다.
의미가 비슷한 문장은 비슷한 숫자 벡터를 갖도록 만든다.

6.5 벡터DB

벡터DB는 임베딩된 문서 조각을 저장하고 검색하는 데이터베이스다.

일반 DB가 정확히 일치하는 값을 잘 찾는다면,
벡터DB는 의미가 비슷한 내용을 찾는 데 강하다.

예를 들어 사용자가 이렇게 묻는다.

충전했는데 하트가 안 들어왔어요.

벡터DB는 다음 문서 조각을 찾을 수 있다.

결제 승인 후 재화가 반영되지 않은 경우,
결제 승인 내역과 충전 처리 로그를 함께 확인한다.

표현은 다르지만 의미가 비슷하기 때문이다.

벡터DB는 임베딩된 데이터를 저장하고, 의미가 비슷한 문서를 빠르게 찾기 위한 데이터베이스다.

6.6 검색기

검색기는 사용자 질문과 관련 있는 문서 조각을 찾는다.

단순히 벡터 검색만 할 수도 있고,
키워드 검색과 함께 사용할 수도 있다.

예를 들어 다음 질문이 들어왔다고 하자.

방송 입장이 안 될 때 운영팀은 뭘 확인해야 해?

검색기는 관련 문서를 찾는다.

- 방송 입장 장애 대응 매뉴얼
- Redis 장애 대응 문서
- WebSocket 연결 오류 문서
- 최근 방송 입장 장애 보고서

검색 결과가 좋아야 답변도 좋아진다.

RAG에서 검색 품질은 매우 중요하다.

6.7 LLM과 답변 생성기

검색된 문서 조각을 LLM에게 전달하고,
LLM은 그 문서를 바탕으로 답변을 만든다.

프롬프트는 보통 이런 형태가 된다.

아래 문서 내용을 근거로 사용자 질문에 답변해줘.

규칙:
- 문서에 없는 내용은 추측하지 마.
- 근거 문서 제목을 함께 표시해.
- 확실하지 않으면 확인 필요라고 말해.

문서:
[검색된 문서 조각들]

질문:
[사용자 질문]

LLM은 검색된 문서를 읽고 답변한다.

중요한 것은 “검색된 문서 안에서만 답하도록 제한하는 것”이다.

그렇지 않으면 AI가 일반 지식을 섞어 답할 수 있다.

7. RAG의 기본 흐름

RAG는 크게 두 단계로 나눌 수 있다.

1. 문서를 준비하는 단계
2. 질문에 답하는 단계

먼저 문서 준비 단계다.

문서 수집
→ 텍스트 추출
→ 문서 분할
→ 임베딩 생성
→ 벡터DB 저장

이 단계는 사용자가 질문하기 전에 미리 해둔다.

예를 들어 사내 정책 문서를 RAG에 넣는다고 해보자.

1. Google Docs에서 정책 문서 가져오기
2. 본문 텍스트 추출
3. 제목과 섹션 기준으로 문서 분할
4. 각 조각의 임베딩 생성
5. 벡터DB에 저장

그다음 질문에 답하는 단계다.

사용자 질문
→ 질문 임베딩 생성
→ 벡터DB에서 관련 문서 검색
→ 검색 결과를 프롬프트에 포함
→ LLM 호출
→ 답변 생성
→ 출처와 함께 반환

예를 들어 사용자가 질문한다.

엑셀 다운로드 권한은 누가 가질 수 있어?

RAG는 관련 문서를 검색한다.

검색 결과:
- 개인정보 포함 데이터 다운로드 정책
- 관리자 권한 신청 절차
- 엑셀 다운로드 감사 로그 정책

그다음 AI가 답변한다.

개인정보가 포함된 엑셀 다운로드 권한은 일반 관리자에게 기본 제공되지 않습니다.

팀장 승인 후 지정된 관리자에게만 부여되며,
다운로드 시 관리자 ID, 다운로드 시간, 대상 데이터 범위를 로그로 남겨야 합니다.

근거:
- 개인정보 포함 데이터 다운로드 정책
- 관리자 권한 신청 절차

이 흐름이 RAG의 기본이다.

8. RAG와 일반 검색의 차이

RAG를 처음 들으면 “그냥 검색 기능 아닌가?”라고 생각할 수 있다.

검색과 RAG는 비슷한 부분이 있다.

둘 다 사용자의 질문과 관련 있는 정보를 찾는다.

하지만 결과를 제공하는 방식이 다르다.

일반 검색은 관련 문서를 보여준다.

사용자 질문:
회원 탈퇴 후 재가입 기준 알려줘.

검색 결과:
- 회원 정책 문서
- 탈퇴 처리 매뉴얼
- 재가입 제한 정책

사용자는 문서를 직접 열어보고 답을 찾아야 한다.

RAG는 검색 결과를 AI가 읽고 답변으로 정리해준다.

사용자 질문:
회원 탈퇴 후 재가입 기준 알려줘.

RAG 답변:
회원 탈퇴 후 동일 계정 정보로는 7일 동안 재가입할 수 없습니다.
다만 부정 이용 제재 계정은 별도 심사 대상입니다.

근거:
회원 정책 문서 > 3. 탈퇴 및 재가입

즉, 검색은 문서 목록을 주고,
RAG는 문서를 근거로 답변을 만들어준다.

검색:
관련 문서를 찾는다.

RAG:
관련 문서를 찾고,
그 문서를 바탕으로 답변을 생성한다.

하지만 RAG가 항상 검색보다 좋은 것은 아니다.

사용자가 직접 문서를 보고 판단해야 하는 경우에는 검색 결과가 더 적합할 수 있다.

예를 들어 법무 검토나 계약서 검토에서는 AI 요약만 보고 판단하면 위험하다.

이런 경우 RAG 답변과 원문 링크를 함께 제공해야 한다.

AI 요약:
계약 해지 조건은 30일 전 서면 통지가 필요합니다.

출처:
계약서 8조 해지 조항

주의:
최종 판단은 원문 확인 필요

RAG는 검색을 대체하는 것이 아니라, 검색 결과를 더 잘 활용하게 해주는 방식이다.

9. RAG와 파인튜닝의 차이

RAG를 설명할 때 자주 나오는 질문이 있다.

“그냥 우리 회사 문서로 AI를 학습시키면 안 되나?”

이 질문은 파인튜닝과 관련이 있다.

파인튜닝은 기존 AI 모델을 추가 데이터로 더 학습시키는 방식이다.

예를 들어 특정 말투, 특정 분류 기준, 특정 작업 스타일을 모델에 익히게 할 수 있다.

하지만 사내 문서 검색이나 정책 답변에는 보통 RAG가 더 적합하다.

왜냐하면 내부 문서는 자주 바뀌기 때문이다.

정책 문서 변경
→ RAG: 문서만 다시 색인하면 됨
→ 파인튜닝: 모델 재학습 필요 가능

또 RAG는 출처를 제공할 수 있다.

RAG 답변:
이 정책은 "관리자 권한 신청 절차" 문서를 근거로 합니다.

파인튜닝된 모델은 답변을 할 수는 있지만,
그 답이 정확히 어떤 문서에서 나온 것인지 표시하기 어렵다.

RAG와 파인튜닝의 차이를 정리하면 다음과 같다.

예를 들어 회사 정책 문서를 답하게 하려면 RAG가 좋다.

질문:
환불 기준 알려줘.

RAG:
환불 정책 문서를 검색해서 답변

반면 고객 문의를 특정 카테고리로 매우 일관되게 분류하는 모델을 만들고 싶다면 파인튜닝을 고려할 수 있다.

입력:
고객 문의

출력:
정해진 카테고리

하지만 처음 AI 서비스를 만드는 단계에서는 대부분 RAG부터 고려하는 것이 좋다.

파인튜닝은 기존 모델을 특정 데이터로 추가 학습시키는 방식이다.
내부 지식을 최신 상태로 답하게 하는 목적보다는, 특정 작업 방식이나 출력 스타일을 익히게 할 때 더 적합한 경우가 많다.

10. RAG가 잘 맞는 업무

RAG는 특히 문서 기반 업무에 잘 맞는다.

대표적인 예시는 다음과 같다.

10.1 사내 문서 검색 챗봇

직원이 사내 문서를 쉽게 찾고 질문할 수 있게 한다.

질문:
휴가 신청 절차 알려줘.

답변:
휴가 신청은 인사 시스템에서 신청하며,
팀장 승인 후 확정됩니다.

근거:
사내 복무 규정 > 휴가 신청 절차

10.2 고객센터 상담 보조

상담원이 정책 문서를 빠르게 확인할 수 있게 한다.

질문:
결제 후 하트가 반영되지 않은 경우 어떻게 안내해야 해?

답변:
먼저 결제 승인 여부와 충전 처리 로그를 확인합니다.
승인은 되었으나 충전 실패인 경우 재처리 절차를 진행합니다.

근거:
고객센터 결제 문의 처리 매뉴얼

10.3 개발 문서 검색

개발자가 API 문서나 설계 문서를 빠르게 찾게 한다.

질문:
방송 시작 API에서 IVS 채널은 언제 생성돼?

답변:
방송 시작 요청 시 기존 채널 상태를 확인한 뒤,
필요한 경우 IVS 채널 생성 또는 재사용 절차를 수행합니다.

근거:
방송 API 설계 문서 > 방송 시작 흐름

10.4 운영 매뉴얼 검색

장애 대응 시 필요한 매뉴얼을 빠르게 찾게 한다.

질문:
Redis timeout이 증가하면 먼저 뭘 봐야 해?

답변:
먼저 Redis CPU, 메모리 사용량, slowlog, 연결 수를 확인합니다.
이후 API별 timeout 발생 구간과 배포 이력을 함께 확인합니다.

근거:
Redis 장애 대응 매뉴얼

10.5 보안/개인정보 규정 검색

개발자가 보안 기준을 빠르게 확인할 수 있게 한다.

질문:
엑셀 다운로드 로그에는 어떤 정보를 남겨야 해?

답변:
다운로드 관리자 ID, 다운로드 시간, 대상 데이터 범위, 사유를 기록해야 합니다.

근거:
개인정보 처리 업무 가이드 > 다운로드 이력 관리

RAG가 잘 맞는 업무의 공통점은 명확하다.

- 문서가 있다.
- 문서 내용을 근거로 답해야 한다.
- 최신 내용이 중요하다.
- 출처가 필요하다.
- 사용자가 직접 문서를 찾기 번거롭다.

11. RAG가 잘 맞지 않는 업무

RAG가 모든 문제를 해결해주지는 않는다.

다음 작업에는 RAG가 꼭 필요하지 않을 수 있다.

- 일반적인 코드 예시 생성
- 문장 다듬기
- 간단한 번역
- 아이디어 브레인스토밍
- 회의록 단순 요약
- 짧은 텍스트 분류

예를 들어 다음 요청은 RAG 없이도 가능하다.

아래 문장을 임원 보고용으로 다듬어줘.

또 다음 요청도 일반 LLM으로 충분할 수 있다.

JavaScript에서 debounce 함수 예시 만들어줘.

RAG가 오히려 불필요하게 복잡해질 때도 있다.

예를 들어 단순한 문장 다듬기 기능에 RAG를 붙이면 다음 문제가 생길 수 있다.

- 구현 복잡도 증가
- 검색 비용 증가
- 응답 지연
- 불필요한 문서가 답변에 섞임

RAG가 잘 맞지 않는 경우도 있다.

문서가 부정확하거나 오래된 경우다.

RAG는 문서를 근거로 답하기 때문에,
문서 자체가 틀리면 답변도 틀릴 수 있다.

오래된 정책 문서:
환불 가능 기간 30일

최신 실제 정책:
환불 가능 기간 7일

RAG 답변:
30일이라고 답할 수 있음

RAG는 문서 품질에 크게 의존한다.

문서가 정리되지 않은 상태에서 RAG를 만들면 AI가 오히려 잘못된 내용을 더 그럴듯하게 정리해줄 수 있다.

그래서 RAG를 만들기 전에 문서 정비가 필요하다.

- 오래된 문서 제거
- 중복 문서 정리
- 최신 문서 표시
- 문서 제목과 섹션 정리
- 권한 정보 정리
- 문서 소유자 지정

RAG는 좋은 문서를 더 잘 활용하게 해주는 구조다.

나쁜 문서를 자동으로 좋은 지식으로 바꿔주는 마법은 아니다.

12. RAG에서 출처가 중요한 이유

RAG의 큰 장점 중 하나는 출처를 제공할 수 있다는 점이다.

AI 답변이 아무리 좋아도 출처가 없으면 신뢰하기 어렵다.

예를 들어 다음 답변을 보자.

회원 탈퇴 후 7일 동안 재가입할 수 없습니다.

그럴듯하지만, 근거가 없다.

정책 문서 기준인지, AI가 일반적으로 추측한 것인지 알 수 없다.

출처가 있으면 다르다.

회원 탈퇴 후 동일 계정 정보로는 7일 동안 재가입할 수 없습니다.

근거:
회원 정책 문서 > 3. 탈퇴 및 재가입

이제 사용자는 원문을 확인할 수 있다.

특히 다음 업무에서는 출처가 중요하다.

- 고객센터 답변
- 정책 안내
- 보안 기준
- 개인정보 처리
- 장애 대응 매뉴얼
- 개발 API 문서
- 임원 보고 자료

출처가 있으면 AI 답변을 검토하기 쉽다.

AI 답변 확인
→ 출처 문서 클릭
→ 원문 확인
→ 필요한 경우 수정

RAG 답변에는 가능하면 다음 정보를 포함하는 것이 좋다.

- 문서 제목
- 섹션 제목
- 문서 링크
- 작성일 또는 수정일
- 관련 문장

예를 들어 다음처럼 표시할 수 있다.

답변:
개인정보가 포함된 엑셀 다운로드는 팀장 승인 후 가능합니다.

출처:
- 개인정보 처리 업무 가이드 > 4. 데이터 다운로드
- 관리자 권한 신청 절차 > 2. 승인 기준

출처 표시는 AI 답변을 “믿어도 되는 말”로 만드는 것이 아니다.

사용자가 검증할 수 있게 만드는 것이다.

이 차이가 중요하다.

13. RAG와 권한 제어

사내 RAG를 만들 때 가장 중요한 것 중 하나가 권한 제어다.

RAG는 내부 문서를 검색해서 답변한다.

그런데 모든 사용자가 모든 문서를 볼 수 있으면 안 된다.

예를 들어 회사에는 다양한 문서가 있다.

- 개발 문서
- 운영 매뉴얼
- 고객센터 정책
- 정산 정책
- 보안 정책
- 인사 문서
- 임원 보고 자료

각 문서마다 접근 가능한 사용자가 다를 수 있다.

개발팀:
개발 문서, 장애 대응 문서 접근 가능

운영팀:
고객센터 매뉴얼, 신고 처리 기준 접근 가능

재무팀:
정산 정책 접근 가능

일반 직원:
인사 공지 일부만 접근 가능

RAG가 권한을 고려하지 않으면 문제가 생긴다.

예를 들어 일반 직원이 이렇게 물었다고 하자.

정산 수수료 예외 기준 알려줘.

권한이 없다면 답하면 안 된다.

안전한 답변은 다음과 같아야 한다.

해당 정보에 접근할 권한이 없습니다.
필요한 경우 담당 부서에 문의해주세요.

RAG 권한 제어는 검색 단계에서 적용하는 것이 좋다.

사용자 질문
→ 사용자 권한 확인
→ 접근 가능한 문서 범위만 검색
→ 검색 결과를 AI에게 전달
→ 답변 생성

좋지 않은 구조는 다음과 같다.

전체 문서 검색
→ AI에게 모든 검색 결과 전달
→ AI가 알아서 권한 판단

이 방식은 위험하다.

AI에게 권한 판단을 맡기면 안 된다.

서버가 먼저 접근 가능한 문서만 골라야 한다.

안전한 구조:
권한 필터링
→ 허용된 문서만 검색
→ 허용된 문서만 AI에 전달

권한 제어를 위해 문서마다 메타데이터를 저장할 수 있다.

문서 메타데이터:
- document_id
- title
- department
- access_level
- allowed_roles
- created_at
- updated_at

검색할 때 사용자 role과 문서의 allowed_roles를 비교한다.

사용자 role: operation_manager

검색 가능 문서:
allowed_roles에 operation_manager가 포함된 문서

RAG에서 권한 제어는 선택이 아니다.

내부 문서를 다루는 순간 필수다.

메타데이터는 데이터에 대한 추가 정보다.
문서 제목, 작성일, 접근 권한, 소속 부서 같은 정보가 메타데이터에 해당한다.

14. RAG에서 “모르면 모른다”고 답하게 하기

RAG를 만들 때 중요한 원칙이 있다.

검색된 문서에 답이 없으면 AI가 모른다고 말해야 한다.

하지만 LLM은 문서에 답이 없어도 일반 지식을 바탕으로 그럴듯하게 답할 수 있다.

예를 들어 사용자가 이렇게 묻는다.

파트너 정산 예외 승인자는 누구야?

검색된 문서에는 이 내용이 없다고 해보자.

그런데 AI가 이렇게 답하면 안 된다.

일반적으로 팀장 또는 재무 담당자가 승인합니다.

이건 추측이다.

RAG에서는 문서에 근거가 없으면 다음처럼 답해야 한다.

제공된 문서에서는 파트너 정산 예외 승인자를 확인할 수 없습니다.
정산 정책 문서 또는 재무 담당자 확인이 필요합니다.

이를 위해 프롬프트에 규칙을 넣어야 한다.

규칙:
- 제공된 문서에 근거가 있는 내용만 답변해.
- 문서에 없는 내용은 추측하지 마.
- 답을 찾을 수 없으면 "제공된 문서에서 확인할 수 없습니다"라고 말해.
- 일반적인 지식으로 보완하지 마.

이 규칙은 매우 중요하다.

RAG의 목적은 AI가 지식이 있는 척하는 것이 아니라,
문서를 근거로 답하는 것이다.

답을 못 하는 것도 좋은 답변일 수 있다.

나쁜 답변:
정산 예외는 보통 팀장 승인을 받습니다.

좋은 답변:
검색된 문서에서는 정산 예외 승인 기준을 확인할 수 없습니다.
추가로 정산 정책 문서 또는 재무팀 확인이 필요합니다.

실무에서는 모르는 것을 아는 척하는 것보다,
확인 필요라고 말하는 것이 훨씬 안전하다.

15. RAG의 품질은 검색 품질에 좌우된다

RAG에서 LLM 성능도 중요하지만, 검색 품질이 매우 중요하다.

검색된 문서가 틀리면 AI 답변도 틀릴 수 있다.

예를 들어 사용자가 이렇게 묻는다.

회원 탈퇴 후 재가입 제한 기간은?

검색기가 엉뚱한 문서를 가져왔다고 해보자.

검색 결과:
- 휴면 계정 전환 정책
- 장기 미접속 회원 알림 정책
- 회원 등급 정책

이 문서들에는 재가입 제한 기간이 없다.

그러면 AI는 제대로 답하기 어렵다.

반대로 정확한 문서를 검색하면 답변 품질이 좋아진다.

검색 결과:
- 회원 탈퇴 정책
- 재가입 제한 정책

RAG 품질은 다음 요소에 영향을 받는다.

- 문서가 잘 분할되어 있는가?
- 문서 제목과 섹션이 명확한가?
- 임베딩 모델이 적절한가?
- 검색 결과 개수가 적절한가?
- 최신 문서를 우선하는가?
- 권한 필터가 올바른가?
- 키워드 검색과 벡터 검색을 함께 쓰는가?

검색 품질을 높이려면 문서 정리가 중요하다.

예를 들어 문서 제목이 이렇게 되어 있으면 검색 품질이 떨어질 수 있다.

회의 내용 정리
정책 수정
관리자 기능
기타 문서

더 좋은 제목은 다음과 같다.

회원 탈퇴 및 재가입 제한 정책
개인정보 포함 엑셀 다운로드 권한 정책
결제 실패 및 하트 미반영 처리 매뉴얼
방송 입장 장애 대응 절차

문서 제목과 섹션이 명확하면 검색도 잘 되고,
AI 답변의 출처도 명확해진다.

RAG는 AI 기술만의 문제가 아니다.

문서 관리, 권한 관리, 검색 품질, 답변 생성이 함께 맞아야 한다.

16. 간단한 RAG 예시

간단한 예시로 RAG 흐름을 정리해보자.

회사에 다음 문서가 있다고 하자.

문서 제목:
결제 실패 및 하트 미반영 처리 매뉴얼

내용:
고객이 하트를 충전했으나 서비스에 반영되지 않았다고 문의한 경우,
먼저 PG 승인 여부를 확인한다.
PG 승인이 완료되었지만 서비스 충전 내역이 없는 경우,
충전 처리 로그를 확인하고 재처리 대상인지 판단한다.
이미 후원에 사용된 하트는 환불 대상에서 제외된다.

사용자가 질문한다.

하트를 충전했는데 반영이 안 됐다고 하면 어떻게 처리해?

RAG는 질문과 관련 있는 문서를 검색한다.

검색된 문서:
결제 실패 및 하트 미반영 처리 매뉴얼

AI에게 전달하는 프롬프트는 다음과 비슷하다.

아래 문서를 근거로 질문에 답변해줘.

규칙:
- 문서에 있는 내용만 답변해.
- 문서에 없는 내용은 추측하지 마.
- 답변 마지막에 근거 문서를 표시해.

문서:
고객이 하트를 충전했으나 서비스에 반영되지 않았다고 문의한 경우,
먼저 PG 승인 여부를 확인한다.
PG 승인이 완료되었지만 서비스 충전 내역이 없는 경우,
충전 처리 로그를 확인하고 재처리 대상인지 판단한다.
이미 후원에 사용된 하트는 환불 대상에서 제외된다.

질문:
하트를 충전했는데 반영이 안 됐다고 하면 어떻게 처리해?

AI 답변은 다음처럼 나올 수 있다.

하트 충전 후 서비스에 반영되지 않았다는 문의가 들어오면,
먼저 PG 승인 여부를 확인해야 합니다.

PG 승인이 완료되었지만 서비스 충전 내역이 없다면,
충전 처리 로그를 확인하고 재처리 대상인지 판단합니다.

이미 후원에 사용된 하트는 환불 대상에서 제외됩니다.

근거:
결제 실패 및 하트 미반영 처리 매뉴얼

이것이 RAG의 기본 동작이다.

AI가 일반적인 결제 지식을 말하는 것이 아니라,
제공된 내부 문서를 바탕으로 답변한다.

17. RAG 도입 전에 확인할 것

RAG를 도입하기 전에 확인해야 할 것이 있다.

첫 번째는 문서가 존재하는지다.

문서가 없으면 RAG가 답할 근거도 없다.

질문은 많은데 문서가 없다
→ RAG보다 문서화가 먼저

두 번째는 문서가 최신인지다.

오래된 문서를 넣으면 오래된 답변이 나온다.

문서가 오래됨
→ RAG 답변도 오래됨

세 번째는 문서 권한이 정리되어 있는지다.

모든 문서를 아무나 검색할 수 있으면 안 된다.

문서 권한 없음
→ 내부 정보 노출 위험

네 번째는 답변에 출처를 제공할 수 있는지다.

문서 제목, 섹션, 링크가 없으면 답변 검증이 어렵다.

다섯 번째는 사용자가 어떤 질문을 할지 예상해야 한다.

RAG는 문서 검색 기반이기 때문에,
실제 질문과 문서 표현이 너무 다르면 검색 품질이 떨어질 수 있다.

사용자 표현:
하트가 안 들어왔어요.

문서 표현:
재화 지급 실패 처리 절차

이런 경우 도메인 용어와 표현 차이를 고려해야 한다.

RAG 도입 전 체크리스트는 다음과 같다.

- 답변 근거가 될 문서가 있는가?
- 문서가 최신인가?
- 중복되거나 충돌하는 문서는 없는가?
- 문서 접근 권한이 정리되어 있는가?
- 문서 제목과 섹션이 명확한가?
- 출처 링크를 제공할 수 있는가?
- 실제 사용자의 질문 예시가 있는가?
- 답변하지 말아야 할 질문 범위가 정의되어 있는가?

RAG는 기술 도입 이전에 지식 관리가 먼저다.

18. 정리

LLM은 많은 지식을 가지고 있지만, 모든 것을 알고 있지는 않다.

특히 회사 내부 문서, 최신 정책, 운영 매뉴얼, 개발 문서, 고객센터 처리 기준은 기본적으로 알 수 없다.

이런 정보를 AI가 답하게 만들려면 RAG가 필요하다.

RAG는 사용자의 질문과 관련 있는 문서를 먼저 검색하고,
그 문서를 AI에게 전달해 답변을 생성하게 만드는 구조다.

RAG를 사용하면 다음 장점이 있다.

- 내부 문서를 근거로 답변할 수 있다.
- 최신 문서를 반영하기 쉽다.
- 답변에 출처를 붙일 수 있다.
- AI의 추측 답변을 줄일 수 있다.
- 권한별 문서 접근 제어를 적용할 수 있다.

하지만 RAG도 완벽한 해결책은 아니다.

문서가 오래되었거나 검색 품질이 낮으면 답변도 틀릴 수 있다.
권한 제어가 없으면 내부 정보가 노출될 수 있다.
문서에 없는 내용을 AI가 추측하지 않도록 프롬프트와 검증이 필요하다.

RAG의 핵심은 이것이다.

AI가 모르는 것을 억지로 추측하게 하지 말고,
필요한 문서를 찾아서 그 문서를 근거로 답하게 만드는 것

이 구조를 이해하면 사내 문서 검색, 고객센터 상담 보조, 개발 문서 검색, 운영 매뉴얼 검색 같은 실무형 AI 서비스를 만들 수 있다.

12장 핵심 요약