RAG 서비스는 왜 데모에서 잘되고 운영에서 흔들릴까?

RAG 서비스가 데모에서 그럴듯한 답을 했다고 해서 운영 환경에서도 안정적으로 작동하는 것은 아닙니다. 실제 서비스에서는 필요한 자료를 찾았는지, 그 자료를 바탕으로 답했는지, 사용자가 볼 권한이 있는지, 실패했을 때 안전하게 멈추는지를 각각 확인해야 합니다.

RAG는 검색 증강 생성의 약자로, 질문과 관련된 외부 자료를 검색한 뒤 그 내용을 AI에게 전달해 답변에 활용하는 방식입니다. 중요한 점은 문제가 생겼을 때 ‘AI가 틀렸다’로 묶지 않는 것입니다. 검색이 잘못됐는지, 검색 결과를 읽고도 답변이 잘못됐는지에 따라 개선 방법이 다릅니다. OpenAI의 RAG 평가 안내는 검색에 잘못된 자료가 들어오는 경우와 모델이 주어진 자료를 잘못 활용하는 경우를 구분합니다.

검색 실패와 답변 실패는 따로 봐야 합니다

회사 문서에서 휴가 정책을 찾는 가상의 서비스를 생각해 보겠습니다. 사용자가 ‘올해 휴가를 며칠 쓸 수 있나요?’라고 물었을 때, 오래된 규정만 검색됐다면 모델을 바꾸기 전에 문서 갱신과 검색 조건부터 확인해야 합니다. 최신 규정이 전달됐는데도 답변이 예전 기준을 말했다면 답변 생성과 지시, 검증 방식을 살펴봐야 합니다.

위 표는 문제를 나누기 위한 편집 예시입니다. 같은 증상에도 원인은 여러 개일 수 있으므로 실제 입력과 검색 결과, 응답을 함께 살펴야 합니다. Microsoft의 RAG 평가 안내는 검색 단계별 평가와 전체 응답 평가를 모두 기록하도록 설명합니다.

출처 링크만으로 정확성이 보장되지는 않습니다

검색된 문서에 링크를 붙여도 그 문서가 답변의 주장을 실제로 뒷받침하는지는 별도 문제입니다. 운영자는 질문별로 기대하는 근거 문서와 필요한 조건을 정한 평가 사례를 만들고, 검색 결과와 최종 답변을 나눠 비교하는 편이 좋습니다.

처음부터 모든 질문을 시험할 필요는 없습니다. 자주 묻는 질문, 최신 문서와 예전 문서가 충돌하는 질문, 관련 자료가 없는 질문을 우선 모아보세요. 자료가 없을 때 답을 만들어내지 않는지도 확인 대상입니다. 이 사례 구성은 실무 적용 제안이며 특정 서비스에서 측정된 결과는 아닙니다.

문서 접근 권한은 검색할 때부터 적용해야 합니다

내부 문서 검색에서는 ‘관련 문서인가’와 함께 ‘이 사용자가 볼 수 있는 문서인가’를 확인해야 합니다. 모델에게 비공개 내용을 보여준 다음 답변에서만 가리도록 맡기는 방식은 신뢰하기 어렵습니다. 검색 단계와 문서 저장·접근 계층에서 각 사용자의 권한 범위를 적용하고, 테스트 계정마다 노출되는 자료를 점검해야 합니다.

검색된 문서 안에 악의적인 지시가 섞일 수 있다는 점도 고려해야 합니다. 문서는 답변의 자료이지 시스템의 새 지시가 아닙니다. 문서 내용이 도구 호출이나 비밀 정보 공개를 지시하는 상황을 별도 평가하고, 도구 권한과 접근 범위를 제한하세요. Microsoft의 RAG 보안 평가 안내는 검색 자료를 통한 간접 프롬프트 인젝션과 접근 통제의 필요성을 함께 다룹니다.

재시도는 무조건 반복하지 말고 상한을 둡니다

문서 검색이나 모델 호출이 일시적으로 실패할 때 재시도는 도움이 될 수 있습니다. 반대로 권한 오류처럼 다시 호출해도 바로 해결되지 않는 문제를 계속 반복하면 비용과 부하만 늘 수 있습니다.

따라서 오류 종류를 구분하고, 재시도 횟수와 총 대기 시간에 상한을 두며, 간격을 점차 늘리고 요청 시점을 분산하는 방식을 검토하세요. 이미 SDK에서 재시도하고 있는지 확인해야 여러 계층의 재시도가 겹치지 않습니다. 외부에 저장·발송하는 작업이라면 같은 요청이 반복돼도 중복 실행되지 않도록 설계해야 합니다. AWS의 재시도 지침도 재시도 제한과 지수 백오프, 지터, 멱등성 확인을 권합니다.

캐시는 빠르지만, 남의 답을 돌려주지 않아야 합니다

비슷한 질문에 기존 답변을 재사용하는 캐시는 속도와 비용을 줄이는 선택지가 될 수 있습니다. 다만 질문이 비슷하더라도 사용자 권한, 적용 날짜, 문서 버전이 다르면 같은 답을 그대로 보여주기 어렵습니다.

예를 들어 부서마다 휴가 규정이 다르다면 질문 문장만 비슷하다는 이유로 다른 부서의 결과를 재사용해서는 안 됩니다. 캐시 키와 만료 조건에 사용자·권한 범위와 자료 변경을 어떻게 반영할지 정하고, 실제 업무 질문으로 잘못된 재사용이 없는지 시험해야 합니다. 이는 원문의 의미 기반 캐시 아이디어를 운영 조건에 맞춰 확장한 편집 제안입니다. 일정한 유사도나 비용 절감률을 모든 서비스의 정답으로 제시할 수는 없습니다.

운영 전에 무엇부터 확인하면 좋을까요?

처음에는 기능을 많이 추가하기보다 실패를 구분할 수 있는 관측 지점을 만드는 것이 유용합니다. 최소한 질문, 검색된 문서의 식별 정보와 버전, 최종 응답, 오류 종류, 응답 시간, 요청별 비용을 권한과 개인정보 정책에 맞게 확인할 수 있어야 합니다.

검색 품질과 답변 품질을 따로 평가하고, 권한이 없는 자료와 근거가 없는 질문을 시험 사례에 포함하세요. 그다음 실제로 자주 발생하는 실패부터 검색 개선, 지시 수정, 재시도 제한, 캐시 적용을 선택하는 편이 낫습니다. 대기열이나 다중 모델 폴백은 요청량과 장애 양상에 따라 도움이 될 수 있지만, 모든 서비스에 처음부터 필요한 것은 아닙니다.

RAG의 신뢰성은 모델 하나의 성능이 아니라 자료 준비 → 권한을 지킨 검색 → 근거에 맞는 답변 → 오류 대응과 지속적인 평가가 연결될 때 높아집니다. 각 단계에서 무엇이 잘못됐는지 볼 수 있어야 다음 개선도 정확해집니다.