서핑베어
홈 › 블로그 › 사내 문서 검색 AI(RAG)
사내 문서 검색 AI(RAG) 도입 실무 가이드
RAG는 "사내 문서를 읽고 그 문서를 근거로 답하는" 구조입니다. 모델 성능보다 문서 상태가 결과를 좌우하기 때문에, 도입 순서를 잘못 잡으면 좋은 모델을 써도 답이 나오지 않습니다.
도입 5단계 권한 처리 실패 지점
결론부터
RAG(검색 증강 생성)를 한 줄로 줄이면 이렇습니다 — 질문이 들어오면 사내 문서에서 관련 부분을 찾아, 그 부분만 근거로 답을 만듭니다. 모델이 "아는 것"으로 답하지 않기 때문에 출처를 표시할 수 있고, 사내 규정처럼 외부에 없는 내용도 다룰 수 있습니다.
동시에 이 구조가 약점도 정합니다. 찾지 못하면 답하지 못하고, 문서가 낡았으면 낡은 답을 자신 있게 합니다. 그래서 RAG 도입의 대부분은 모델 작업이 아니라 문서 작업입니다.
도입 5단계
자주 나오는 실패와 원인
| 증상 | 실제 원인 | 먼저 볼 곳 |
|---|---|---|
| 답이 그럴듯한데 틀렸다 | 낡은 문서가 색인에 남아 있음 | 문서 버전·폐기 처리 |
| "모른다"만 반복한다 | 질문 표현과 문서 용어가 다름 | 질문 목록 대비 문서 커버리지 |
| 특정 부서 질문만 잘 된다 | 그 부서 문서만 정리되어 있음 | 문서 정리 범위 |
| 보면 안 되는 내용이 나온다 | 권한을 답변 단계에서 처리함 | 검색 단계 권한 필터 |
| 같은 질문에 다른 답 | 중복 문서가 서로 다른 내용을 담고 있음 | 중복 제거 |
직접 만들 것인가, 도구를 살 것인가
판단 기준은 문서의 종류와 권한 구조입니다. 문서가 한 곳(예: 사내 위키)에 모여 있고 권한이 단순하면, 그 도구에 붙어 있는 검색 AI로 시작하는 편이 빠릅니다. 별도 구축은 대개 비용만 늘립니다.
반대로 문서가 파일 서버·메일·그룹웨어에 흩어져 있거나, 부서별로 볼 수 있는 범위가 다르면 연동과 권한 처리가 작업의 대부분이 됩니다. 이때는 도구 선택보다 설계가 먼저입니다.
어느 쪽이든 첫 단계는 같습니다. 1단계 질문 목록으로 작게 시험하고, 정답률을 기록한 다음 범위를 넓히는 것입니다. 전사 도입을 첫 목표로 잡으면 검증 없이 규모만 커집니다.
자주 묻는 질문
RAG와 모델 파인튜닝은 무엇이 다릅니까?
RAG는 문서를 그때그때 찾아 근거로 씁니다. 문서를 고치면 답도 바로 바뀌고, 출처를 표시할 수 있습니다. 파인튜닝은 모델 자체를 조정하는 방식이라 내용이 바뀔 때마다 다시 학습해야 하고 출처 표시가 어렵습니다. 사내 규정처럼 자주 바뀌는 내용은 RAG가 맞습니다.
문서가 정리되지 않았는데 시작할 수 있나요?
전체를 정리할 필요는 없습니다. 질문 30~50개에 답하는 문서만 정리하면 시작할 수 있습니다. 오히려 전체 정리를 조건으로 걸면 프로젝트가 시작되지 못합니다.
답이 틀렸을 때 책임은 어떻게 처리합니까?
근거 표시가 그 장치입니다. 답과 함께 원문 위치를 보여주면 사용자가 확인할 수 있고, 틀린 원인이 문서인지 검색인지 구분됩니다. 인사·법무·안전처럼 결과가 무거운 영역은 답을 참고용으로만 쓰고 최종 확인을 사람이 하도록 정해두는 편이 안전합니다.
데이터가 외부로 나갑니까?
구조에 따라 다릅니다. 문서 일부가 모델 요청에 포함되므로, 그 요청이 어디로 가고 저장되는지, 학습에 쓰이는지를 계약에서 확인해야 합니다. 이 조건이 확정되기 전에는 민감 문서를 색인에 넣지 않는 편이 안전합니다.
문서 상태부터 확인
어디까지 준비됐는지 먼저 보세요
AX 준비도 진단은 업무·데이터·기술·조직 네 축으로 현재 상태를 점수화합니다. 데이터 축 점수가 RAG 도입 난이도를 그대로 보여줍니다.