사내 문서를 연결한 RAG(Retrieval-Augmented Generation) 데모는 빠르게 만들 수 있습니다. PDF를 잘라 임베딩하고, 벡터 데이터베이스에서 가까운 조각을 찾아 언어 모델에 넣으면 그럴듯한 답이 나옵니다. 하지만 운영에 들어가면 “문서에 분명히 있는데 못 찾는다”, “폐기된 규정을 답한다”, “다른 부서만 볼 수 있는 내용을 보여준다”는 문제가 나타납니다.
이 문제를 모델의 환각으로만 부르면 원인을 놓칩니다. RAG 답변의 품질은 모델 이전에 무엇을 색인했고, 어떤 권한으로, 어느 시점의 문서를, 어떤 검색 조합으로 가져왔는지에 의해 크게 결정됩니다. 모델은 주어진 근거가 잘못되면 그 잘못을 유창하게 설명할 뿐입니다.
핵심: 기업 RAG는 벡터 검색 프로젝트가 아니라 권한과 버전이 살아 있는 지식 공급망을 만드는 프로젝트다.
RAG 실패를 세 층으로 나눠 보자
답이 틀렸을 때 프롬프트부터 고치기 전에 실패가 어느 층에서 생겼는지 구분해야 합니다.
- 수집·색인 실패: 필요한 문서가 없거나 표·제목·각주가 깨졌고, 최신 버전과 권한이 반영되지 않았다.
- 검색 실패: 문서는 있지만 잘못된 조각이 상위에 올라오거나 필요한 여러 조각을 함께 찾지 못했다.
- 생성 실패: 올바른 근거를 찾았지만 모델이 내용을 왜곡하거나 근거 밖의 정보를 추가했다.
각 층의 지표도 다릅니다. 수집은 색인 지연과 누락률, 검색은 정답 근거의 Recall@k와 순위, 생성은 근거 충실도와 인용 정확도를 봅니다. 최종 답변 점수만 측정하면 어디를 개선해야 하는지 알 수 없습니다.
문서를 글자 수로만 자르면 의미가 끊어진다
고정 길이 분할은 빠르고 단순하지만 계약서의 조항과 예외, 표의 머리글과 값, 매뉴얼의 단계가 서로 떨어질 수 있습니다. 검색 결과에는 “단, 다음 경우는 제외한다”는 문장만 나오고 무엇의 예외인지 빠지는 식입니다.
문서 종류에 따라 구조를 보존해야 합니다. 제목과 하위 절의 계층, 목록, 표의 열 이름, 그림 설명, 페이지와 원본 위치를 함께 저장합니다. 작은 조각에는 상위 제목과 문서 요약을 붙이고, 검색 후에는 주변 조각 또는 부모 절을 다시 가져오는 방식이 효과적입니다.
모든 문서에 같은 크기를 적용할 필요도 없습니다. 로그는 고정 구간이 적합할 수 있지만 계약서는 조항, FAQ는 질문·답변, 회의록은 안건, 소스코드는 함수와 클래스를 기준으로 나누는 편이 낫습니다. Microsoft의 RAG 아키텍처 가이드 역시 문서 구조와 의미에 맞는 청킹, 관련 없는 컨텍스트 제거를 중요하게 다룹니다.
조각만 저장하지 말고 부모 문서와 연결한다
검색 단위는 작아야 정확하지만 답변에 필요한 맥락은 더 클 수 있습니다. 그래서 자식 조각에는 반드시 원본 문서 ID, 부모 절 ID, 제목 경로, 페이지, 주변 조각 순서가 있어야 합니다. 검색은 작은 조각으로 하고 모델에는 필요한 부모 범위를 제공할 수 있습니다.
이 연결은 인용에도 필요합니다. 사용자가 인용을 눌렀을 때 원본 문서의 정확한 절이나 페이지로 이동해야 합니다. 조각 텍스트만 별도 저장하면 원본이 수정된 뒤 무엇을 근거로 답했는지 재현하기 어렵습니다.
권한은 답변 직전에 가리면 늦다
기업 RAG의 가장 위험한 설계는 모든 문서를 검색한 뒤 모델이 만든 답에서 민감정보를 제거하는 방식입니다. 권한 없는 문서가 모델 컨텍스트에 들어간 순간 이미 데이터가 노출 경계를 넘었습니다. 답변 필터가 표현을 가리더라도 로그, 캐시, 추적 데이터에 남을 수 있습니다.
문서 또는 조각에 원본의 ACL, 그룹, 테넌트, 보안 등급을 함께 색인하고 검색 단계에서 호출자의 권한으로 결과를 제한해야 합니다. Azure AI Search의 문서 수준 접근제어도 수집 시 권한 메타데이터를 보존하고 쿼리 시점에 사용자·그룹 권한과 비교하는 구조를 제공합니다.
애플리케이션에서 검색 결과를 받은 뒤 제거하는 사후 필터보다 검색 엔진 내부의 사전 필터가 안전합니다. 상위 k개를 먼저 뽑고 권한 없는 문서를 제거하면 사용자가 볼 수 있는 좋은 문서가 k 바깥에 있어 검색 품질도 떨어집니다.
권한 동기화 지연을 설계해야 한다
원본 저장소에서 직원의 그룹이 변경되거나 문서 권한이 회수돼도 검색 색인이 즉시 바뀌지 않을 수 있습니다. 공식 문서도 원본 권한 변경이 색인에 다시 동기화된 뒤에야 쿼리 결과에 반영될 수 있음을 설명합니다. 이 시간차가 보안 사고가 될 수 있습니다.
중요 문서는 이벤트 기반으로 권한 변경을 즉시 반영하고, 주기적인 전체 대조 작업으로 누락을 찾습니다. 권한 철회 이벤트가 지연될 때는 해당 저장소나 문서 집합을 일시적으로 검색에서 제외하는 안전 모드도 고려할 수 있습니다. 색인 메타데이터에 마지막 권한 동기화 시각을 남기고 허용 지연 목표를 모니터링해야 합니다.
최신 문서와 ‘당시 문서’는 다르다
기업 질문에는 두 종류의 시간이 있습니다. “현재 출장비 한도는 얼마인가?”는 최신 유효 규정이 필요하지만 “2025년 3월 계약 당시 적용 규정은 무엇인가?”는 과거 시점의 문서가 필요합니다. 무조건 최신 버전만 남겨도, 모든 버전을 같은 비중으로 검색해도 틀립니다.
문서에 최소한 다음 시간 정보를 저장합니다.
- 원본 생성·수정 시각과 색인 시각
- 업무상 효력이 시작되고 끝나는 유효기간
- 버전 번호, 이전·다음 버전, 현재 승인 상태
- 초안·검토·승인·폐기 상태
- 기준 시점이 없는 질문에서 사용할 기본 우선순위
질문에서 기준 시점을 추출해 필터에 넣고, 시점이 모호한데 결과가 달라질 수 있다면 사용자에게 되묻습니다. 답변에는 문서 버전과 유효일을 함께 표시해야 합니다.
삭제는 색인에서도 삭제되어야 한다
원본 파일을 삭제했다고 벡터 색인의 조각이 자동으로 사라진다고 가정하면 안 됩니다. 수집 방식에 따라 삭제 감지를 별도로 설정해야 하고, 인덱서 초기화나 재실행이 고아 문서를 자동 정리하지 않을 수도 있습니다.
원본 문서별 조각 목록을 관리하고 삭제 이벤트가 오면 관련 임베딩, 키워드 문서, 캐시를 함께 제거합니다. 주기적으로 원본 목록과 색인을 대조해 고아 조각을 찾습니다. 법적 보존 때문에 즉시 삭제할 수 없는 경우 검색 비활성화 상태와 보존 저장소를 분리합니다.
벡터 검색만으로는 정확한 식별자에 약하다
벡터 검색은 의미가 비슷한 표현을 찾는 데 강하지만 제품 코드, 오류 번호, 계약 조항, 사람 이름, 약어처럼 정확한 문자열이 중요한 질문에서는 키워드 검색이 더 낫습니다. “NF-2048”을 찾는데 의미가 비슷한 다른 제품 문서가 올라오면 곤란합니다.
그래서 기업 검색은 키워드 검색과 벡터 검색을 병렬 실행한 뒤 결과 순위를 합치는 하이브리드 방식이 기본에 가깝습니다. Azure AI Search와 Elastic의 공식 문서는 서로 다른 순위 목록을 RRF(Reciprocal Rank Fusion)로 결합하는 패턴을 설명합니다. 이후 더 정밀한 재순위 모델이 상위 후보를 질문과 다시 비교할 수 있습니다.
검색 점수는 정답 확률이 아니다
벡터 유사도 0.8이 답의 정확도 80%를 의미하지 않습니다. 검색 알고리즘과 임베딩 모델에 따라 점수 범위가 다르고, 하이브리드 결합 점수도 해석 방식이 다릅니다. 고정 임계값을 복사해 적용하면 질문 유형에 따라 너무 많이 답하거나 지나치게 거절할 수 있습니다.
실제 평가 질문에서 정답 근거가 포함된 경우와 없는 경우를 모아 임계값을 교정합니다. 상위 결과 간 점수 차이, 서로 독립된 출처의 일치, 최신성과 권한, 재순위 점수를 함께 봅니다. 중요한 업무는 단일 점수보다 “필수 근거가 존재하는가” 같은 결정적 조건을 추가합니다.
답하지 않는 능력이 품질이다
근거가 없는데도 항상 답하도록 프롬프트하면 RAG는 일반 지식이나 추측으로 빈칸을 채웁니다. 사용자는 문서 기반 답변으로 믿기 때문에 일반 챗봇보다 위험할 수 있습니다.
다음 상황에서는 답변을 보류하거나 명확히 제한해야 합니다.
- 권한과 시간 필터를 통과한 근거가 없는 경우
- 동일한 효력의 문서들이 서로 모순되는 경우
- 질문의 대상·제품·기준 시점이 모호한 경우
- 검색 결과가 질문의 핵심 조건을 포함하지 않는 경우
- 안전·법률·재무상 사람의 확인이 필요한 경우
거절 문구만 보여주기보다 부족한 정보와 다음 행동을 안내합니다. “근거가 없습니다” 대신 “현재 승인 상태인 국내 출장 규정에서는 해당 항목을 찾지 못했습니다. 해외 출장 규정을 확인할까요?”처럼 범위와 선택지를 제공합니다.
인용은 장식이 아니라 검증 인터페이스다
답변 끝에 문서 링크 몇 개를 붙였다고 인용이 완성되는 것은 아닙니다. 각 주장과 근거 조각을 연결하고, 사용자가 원문의 해당 위치를 바로 확인할 수 있어야 합니다. 답변에 없는 문서를 출처로 붙이거나 링크한 문서에 실제 주장이 없다면 신뢰는 더 낮아집니다.
생성 단계에는 문서 ID와 제목, 절, 페이지, 버전, 유효일을 전달합니다. 모델이 만든 인용을 그대로 신뢰하지 말고 인용 ID가 실제 검색 결과에 존재하는지 코드로 검증합니다. 답변 문장과 근거의 의미 일치도도 별도 평가합니다.
모든 질문을 하나의 색인에 넣지 않는다
인사 규정, 제품 매뉴얼, 고객 계약, 소스코드는 갱신 주기와 권한, 검색 방식이 다릅니다. 거대한 단일 색인은 관리가 간단해 보이지만 관련 없는 후보가 늘고 권한 실수의 영향 범위가 커집니다.
업무 도메인과 보안 경계별 지식 소스를 나누고 질문 분류기가 필요한 소스를 선택하게 할 수 있습니다. 다만 분류 오류로 필요한 색인을 놓칠 수 있으므로 여러 후보를 선택하거나 불확실할 때 범위를 확장하는 전략이 필요합니다. 테넌트 데이터는 논리 필터만 믿기보다 위험도에 따라 물리적 색인 분리도 검토합니다.
GraphRAG는 언제 필요한가
일반 RAG가 특정 조항이나 사실을 찾는 데 적합하다면, 여러 문서 전체에서 관계와 주제를 종합해야 하는 질문에는 그래프 기반 접근이 도움이 될 수 있습니다. Microsoft GraphRAG는 엔터티·관계·주장을 추출하고 커뮤니티 요약을 만들어 지역적 질문과 전체적 질문에 서로 다른 검색 방식을 제공합니다.
그러나 모든 문서를 지식 그래프로 만들 필요는 없습니다. 색인 비용과 갱신 복잡성이 커지고, 추출된 관계 자체가 틀릴 수 있습니다. “특정 고객의 최신 계약 해지 조건”은 잘 설계된 하이브리드 검색이 더 단순할 수 있습니다. “여러 프로젝트에서 반복되는 공급망 위험과 관련 조직을 요약”하는 질문처럼 관계와 전체 구조가 중요한 경우에 평가를 거쳐 도입합니다.
RAG 평가는 답변과 검색을 분리한다
최종 답이 틀리면 검색 결과부터 봅니다. 정답 근거가 상위 k개에 들어왔는지, 권한·시간 필터가 맞았는지, 재순위 뒤 살아남았는지 확인합니다. 검색이 성공했는데 답이 틀렸다면 생성 프롬프트와 모델을 봅니다.
평가 데이터에는 실제 질문, 필요한 근거 문서와 조각, 기준 시점, 사용자 권한, 허용 답변과 거절 조건을 포함합니다. 다음 지표를 함께 봅니다.
- 검색 재현율: 필요한 근거가 상위 결과에 포함되는가
- 검색 정밀도: 관련 없는 조각이 컨텍스트를 차지하지 않는가
- 근거 충실도: 답변의 주장이 검색된 자료로 뒷받침되는가
- 인용 정확도: 인용한 위치에 실제 근거가 있는가
- 거절 정확도: 근거가 없을 때 답하지 않고, 있을 때 불필요하게 거절하지 않는가
- 권한 누출률: 볼 수 없는 문서가 검색·답변·로그에 등장하지 않는가
운영에서 봐야 할 지표
색인된 문서 수만 보면 시스템이 건강해 보일 수 있습니다. 원본 대비 누락 문서, 마지막 성공 동기화, 삭제 대기 조각, 권한 동기화 지연, 버전이 충돌하는 문서를 함께 봐야 합니다.
검색 측면에서는 빈 결과율, 재질문율, 답변 거절률, 사용자가 인용을 열어 본 비율, 낮은 관련도 결과, 도메인별 검색 지연을 봅니다. 모델이나 임베딩, 청킹, 재순위 설정을 바꿀 때 동일한 평가 세트로 회귀 테스트합니다.
30일 개선 계획
1주차: 실패를 층별로 분류한다
최근 잘못된 답변 30~50개를 모아 색인, 검색, 생성 실패로 나눕니다. 정답 문서, 기준 시점, 사용자 권한을 표시해 최소 평가 세트를 만듭니다.
2주차: 문서 메타데이터를 보강한다
원본·부모 조각 연결, 제목 경로, 버전, 유효기간, 승인 상태, ACL, 마지막 동기화 시각을 색인에 넣습니다. 수정·삭제·권한 변경의 동기화 흐름을 점검합니다.
3주차: 하이브리드 검색과 재순위화를 비교한다
키워드, 벡터, 하이브리드 검색을 평가 세트에서 비교합니다. 정확한 코드와 의미 질문을 구분해 가중치를 조정하고, 상위 후보에 재순위화를 적용합니다.
4주차: 인용 검증과 거절 기준을 배포한다
주장별 근거 연결과 인용 ID 검증을 넣습니다. 근거가 부족하거나 모순될 때 답변을 보류하는 기준을 실제 사용자에게 적용하고 피드백을 다음 평가 사례로 수집합니다.
네이처프랙탈이 제안하는 접근
네이처프랙탈은 RAG 프로젝트를 벡터 데이터베이스 선정부터 시작하지 않습니다. 실제 질문과 실패 비용, 원본 시스템의 권한·버전·갱신 흐름을 먼저 분석합니다. 문서 유형별 파싱과 청킹을 설계하고, 하이브리드 검색·재순위화·인용 검증을 평가 데이터로 비교한 뒤 운영 시스템에 연결합니다.
좋은 RAG는 모든 질문에 자신 있게 답하는 시스템이 아닙니다. 볼 수 있는 최신 근거를 정확히 찾고, 근거가 부족하면 그 사실을 설명할 수 있는 시스템입니다. 이 원칙이 지켜져야 지식검색이 챗봇 데모를 넘어 기업 업무의 신뢰할 수 있는 기반이 됩니다.
실무 체크리스트
- 문서 구조와 종류에 맞춰 청킹하고 부모 문서와 연결했는가?
- ACL과 테넌트 정보가 조각마다 보존되고 검색 전에 적용되는가?
- 권한 변경·문서 수정·삭제가 색인과 캐시에 얼마나 늦게 반영되는지 아는가?
- 유효기간과 버전을 사용해 현재·과거 시점 질문을 구분하는가?
- 키워드와 벡터 검색을 실제 질문으로 비교하고 결합했는가?
- 인용이 실제 검색 근거와 원본 위치를 가리키는지 검증하는가?
- 근거 부족·모순·모호한 시점에서 답변을 보류할 수 있는가?
- 검색과 생성 품질을 분리해 회귀 테스트하는가?
