가이드

RAG로 사내 문서를 연결했는데 왜 엉뚱한 답이 나올까요

RAG로 사내 문서를 연결했는데 답이 엉뚱하다면 모델보다 검색·청킹 단계를 먼저 봐야 합니다. 거꾸로 추적하는 진단 순서와 개인정보 위험을 함께 정리했습니다.

2026-10-20

RAG(검색증강생성)로 사내 문서를 AI에 연결했는데 답이 엉뚱하게 나온다면, 원인은 모델보다 문서를 쪼개고 찾아오는 단계에 있는 경우가 많습니다. Anthropic의 실험에서는 조각(청크)에 문맥을 살려 다시 임베딩하는 것만으로 검색 실패율이 49% 줄었고, 재순위화(리랭킹)를 더하면 67%까지 줄었습니다. 모델을 바꾸기 전에 “문서 정리 → 검색 → 생성” 세 단계를 결과에서부터 거꾸로 짚어 보면 어디서 끊어졌는지 찾을 수 있습니다.

순서는 간단합니다. 눈에 보이는 결과인 생성 단계부터 확인하고, 그다음 검색 단계, 마지막으로 문서를 쪼갠 방식까지 거슬러 올라갑니다. 먼저 RAG가 어떤 흐름으로 작동하는지부터 봅니다.

RAG는 어떤 순서로 작동합니까?

구글 클라우드의 RAG 엔진 설명에 따르면 검색증강생성은 다섯 단계로 이어집니다. 문서를 모으는 데이터 수집, 긴 문서를 작은 조각으로 나누는 데이터 변환(청킹), 각 조각을 숫자 벡터로 바꾸는 임베딩, 검색에 맞게 기술 자료를 정리하는 색인 생성, 질문과 관련된 조각을 찾는 검색, 그 조각을 참고해 답을 만드는 생성입니다.

엉뚱한 답은 마지막 생성 단계에서 눈에 보이지만, 원인은 그 앞의 다섯 단계 어디에나 있을 수 있습니다. 그래서 결과에서 거꾸로 추적합니다.

답이 틀렸다면 생성과 검색 중 어디를 먼저 봅니까?

가장 먼저 확인할 것은 검색된 조각 안에 정답이 있었는지입니다. 정답이 들어 있었는데 모델이 다르게 답했다면 생성 단계 문제이고, 정답이 처음부터 검색되지 않았다면 검색 단계 문제입니다. 두 경우의 해결책은 전혀 다릅니다.

Anthropic의 실험은 이 구분을 구체적인 수치로 보여줍니다. 1차 검색에서 관련성이 높은 상위 150개 조각을 추리고, 그중에서 재순위화(리랭킹)로 모델에 전달할 상위 20개를 다시 고르는 구조입니다. 조각을 문맥 없이 임베딩하면 이 상위 20개 안에 정답 조각이 들어가지 못하는 경우가 많았습니다.

문맥을 살려 임베딩을 다시 만들자 상위 20개 검색 실패율이 49% 줄었고, 재순위화까지 더하자 5.7%에서 1.9%로, 67% 줄었습니다. 같은 질문이라도 검색이 무엇을 모델에 건네주느냐가 답의 정확도를 가장 크게 좌우한다는 뜻입니다.

검색이 놓쳤다면 문서를 어떻게 쪼갰는지를 봅니다

검색이 정답 조각을 찾지 못했다면 원인은 보통 청킹 과정에서 문맥이 끊긴 것입니다. 계약서를 문단 단위로 쪼개면 “이 계약”이 어느 계약을 가리키는지, “그 금액”이 무엇의 금액인지 하는 정보가 조각 밖에 남습니다. 임베딩은 그 조각만 보고 벡터를 만들기 때문에, 원래 문서에서는 분명했던 내용이 조각 단위에서는 모호해집니다.

Anthropic은 이 손실을 줄이기 위해 조각마다 원문서를 참고한 짧은 문맥 설명을 덧붙이는 방식을 제안합니다. 비용은 프롬프트 캐싱을 쓰면 문서 100만 토큰당 1.02달러(일회성)로, 청킹을 다시 설계하는 작업치고는 크지 않습니다.

진단 순서로 보면 검색 실패가 반복되는 문서일수록 원문의 문장이 짧고 지시어가 많은 경우가 많습니다. 모델을 교체하기 전에 그런 문서들의 청킹 방식부터 바꾸는 편이 비용 대비 효과가 큽니다.

검색된 조각에 정답이 없었다면 모델을 바꿔도 소용없습니다. 모델은 건네받은 조각만 보고 답을 만들기 때문입니다.

그전에, RAG가 필요한 규모인지부터 확인합니다

지금까지는 이미 구축된 RAG가 틀렸을 때의 진단입니다. 애초에 이 단계가 다 필요한지부터 확인하면 뒤에서 생길 문제를 미리 줄일 수 있습니다. Anthropic은 지식베이스가 20만 토큰(약 500쪽) 이하라면 RAG 없이 전체 문서를 프롬프트에 그대로 넣는 편이 더 단순하고 저렴하다고 밝힙니다. 사내 매뉴얼 몇 건을 연결하는 정도라면 검색·색인 단계를 건너뛸 수 있다는 뜻입니다.

문서량이 그 기준을 넘는다면 직접 구축할지, 벤더가 관리하는 저장소를 쓸지를 정합니다. 구글 클라우드 RAG Engine은 관리형 Spanner 인스턴스를 벡터 데이터베이스로 쓰면 그 인스턴스 요금이 별도로 청구되고, 지원 리전도 us-central1 등 일부로 제한됩니다. OpenAI의 벡터 스토어는 전체 저장 용량 1GB까지 무료이고 초과분은 GB당 하루 0.10달러로, 만료 정책을 걸어 두면 비용을 통제하기 쉽습니다.

두 방식 중 무엇을 고르든, 결정을 코드로 옮기기 전에 문서량과 요금 구조를 먼저 비교해 두어야 나중에 “검색이 이상하다”는 증상과 “비용이 새고 있다”는 증상을 따로 떼어 진단할 수 있습니다.

사내 문서를 연결하면 개인정보 위험도 함께 커집니다

개인정보보호위원회의 생성형 AI 개인정보 처리 안내서는 RAG가 환각을 줄이고 정확성을 높이는 대신, 검색된 문장에 담긴 개인정보를 그대로 노출할 위험이 상대적으로 커진다고 지적합니다. 외부 지식베이스를 찾아 답을 만드는 구조 자체가, 그 지식베이스에 있던 민감한 내용을 질문에 반응해 그대로 꺼내 올 수 있다는 뜻입니다.

안내서는 이런 유형을 검색형 에이전트로 분류하고, 비식별화되지 않은 문서나 민감정보가 사용자 질의에 반응해 출력될 수 있으므로 외부 데이터 접근 통제, 사용자 인증, 응답 필터링, 기록 관리를 갖추도록 권고합니다. 레드티밍 점검 항목에도 외부 벡터형 DB 오염, 검색증강생성 결과 조작, 캐시 오염이 올라 있습니다.

그런데도 정책 방향은 RAG 쪽으로 이동하고 있습니다. 행정안전부의 공공부문 AI 도입·활용 가이드는 기관 내부의 최신 문서를 먼저 찾아 답하게 하는 ‘RAG 우선 전략’을 반영해, 환각 현상을 막고 행정 데이터에 기반한 답변을 하도록 설계했다고 밝혔습니다. 사내 문서를 연결하는 조직이라면 정답 추적 순서와 함께 접근 통제·필터링 체계를 같은 시점에 갖춰야 합니다.

모델을 바꾸기 전에 확인할 순서

답이 틀렸을 때 할 일은 모델 교체가 아니라 순서대로 거슬러 올라가는 점검입니다.

검색된 조각 안에 정답이 있었는지 확인합니다 — 있었다면 생성 단계, 없었다면 검색 단계 문제입니다.
정답 조각이 상위 150개 후보에는 있었지만 상위 20개에서 빠졌다면 리랭킹을 추가합니다.
후보 단계에서부터 빠졌다면 청킹 방식을 바꿔 조각에 문맥을 되살립니다.
이 모든 단계를 시작하기 전에, 지식베이스가 20만 토큰 이하라면 RAG 없이 프롬프트에 통째로 넣는 선택지를 먼저 검토합니다.

자주 묻는 질문

RAG와 파인튜닝은 어떻게 다릅니까?
RAG는 모델의 가중치를 바꾸지 않고 질문마다 외부 지식베이스를 검색해 참고자료로 붙입니다. 모델 자체를 다시 학습시키는 파인튜닝과 달리, 문서가 바뀌면 다시 학습할 필요 없이 색인만 갱신하면 됩니다.
지식베이스가 작으면 RAG가 필요 없습니까?
Anthropic은 지식베이스가 20만 토큰(약 500쪽) 이하면 전체를 프롬프트에 넣는 편이 더 단순하고 저렴하다고 밝힙니다. 그보다 크다면 검색 단계가 필요해집니다.
검색 실패를 줄이는 가장 간단한 방법은 무엇입니까?
문맥을 살린 임베딩으로 바꾸는 것만으로 상위 20개 검색 실패율이 49% 줄고, 리랭킹을 더하면 67%까지 줄어듭니다. 청킹 방식을 손보는 것이 모델을 바꾸는 것보다 효과가 큽니다.
RAG를 쓰면 개인정보 유출 위험이 커집니까?
개인정보보호위원회는 검색된 문장에 담긴 개인정보가 그대로 노출될 위험이 상대적으로 커진다고 보고, 접근 통제·사용자 인증·응답 필터링·기록 관리를 권고합니다.
공공기관도 RAG를 우선 적용해야 합니까?
행정안전부의 공공부문 AI 가이드는 기관 내부 문서를 먼저 찾아 답하게 하는 RAG 우선 전략을 반영했습니다. 다만 개인정보 안전조치를 함께 갖추는 것이 전제입니다.