사내 문서 AI 검색, RAG만 붙이면 정말 정확해질까?

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

사내 문서는 분명 존재하는데 필요한 답은 좀처럼 찾기 어렵습니다. 파일명은 제각각이고, 같은 정책을 설명하는 문서가 여러 버전으로 흩어져 있으며, 담당자의 머릿속에만 남은 정보도 적지 않습니다. 그래서 많은 스타트업이 생성형 AI와 RAG를 결합한 사내 문서 AI 검색을 검토합니다.

하지만 데모에서 그럴듯한 답을 내놓는 것과 직원이 매일 믿고 쓰는 검색 시스템을 만드는 것은 전혀 다른 문제입니다. 디게라티는 기업용 AI 검색 프로젝트를 설계해 온 검색 인프라 전문가에게 구축 순서, 비용, 보안, 정확도 평가 방법을 질문했습니다. 답변은 특정 제품을 추천하기보다 실제 도입 판단에 필요한 원칙을 중심으로 구성했습니다.

Q. 사내 문서 검색에 RAG가 필요한 이유는 무엇인가요?

A. AI에게 회사의 최신 근거를 찾아주는 구조입니다

RAG는 사용자의 질문과 관련된 자료를 먼저 검색한 뒤, 검색된 내용을 근거로 생성형 AI가 답변하도록 만드는 방식입니다. 범용 언어 모델은 우리 회사의 최신 인사 규정, 지난주 확정된 제품 정책, 특정 고객과의 계약 조건을 원래 알 수 없습니다. RAG는 모델을 다시 학습시키지 않고도 내부 자료를 답변 맥락에 연결한다는 점에서 실용적입니다.

전문가는 “RAG를 챗봇에 문서를 붙이는 기능 정도로 이해하면 실패하기 쉽다”고 강조합니다. 디지털 정보가 저장되고 처리되는 기본 개념은 디지털 용어 설명에서도 살펴볼 수 있지만, 기업 검색에서는 정보의 존재 여부뿐 아니라 현재 유효한 정보인지, 누가 볼 수 있는지, 어떤 문장이 답의 근거인지까지 관리해야 합니다.

예를 들어 직원이 “법인카드로 식대를 얼마까지 결제할 수 있나요?”라고 물었다고 가정해 보겠습니다. 시스템은 단어가 비슷한 문서를 보여주는 데서 끝나지 않고, 시행일이 가장 최근인 규정과 예외 조항을 찾아 답변에 출처를 붙여야 합니다. 오래된 규정을 인용한다면 문장 자체가 자연스러워도 좋은 검색이라고 할 수 없습니다.

• 일반 검색: 관련 문서나 페이지의 위치를 보여줍니다.
• RAG 검색: 관련 구간을 찾아 질문에 맞게 설명하고 근거를 함께 제시합니다.
• 모델 추가 학습: 지식과 행동 패턴을 모델에 반영하지만 자료가 바뀔 때마다 갱신하기 어렵습니다.
• 업무 자동화 에이전트: 검색 결과를 넘어 승인 요청이나 티켓 생성 같은 행동까지 수행합니다.

“RAG의 첫 번째 목표는 말을 잘하는 AI가 아니라, 직원이 답의 근거를 직접 확인할 수 있는 검색 환경이어야 합니다.”

Q. 문서를 많이 넣을수록 답변 정확도가 높아지나요?

A. 문서 수보다 최신성·구조·중복 관리가 먼저입니다

자료를 많이 넣으면 검색 범위는 넓어지지만 정확도가 자동으로 높아지지는 않습니다. 오히려 폐기된 정책, 회의 중 작성한 초안, 동일 문서의 복사본이 함께 들어가면 AI가 서로 충돌하는 내용을 근거로 선택할 수 있습니다. 직원 30명의 스타트업이라도 드라이브와 협업 도구를 연결해 보면 수천 개 파일이 발견되는데, 그중 실제 답변 근거로 쓸 수 있는 문서는 일부일 가능성이 큽니다.

가장 먼저 해야 할 일은 자료마다 소유자, 작성일, 최종 수정일, 적용 조직, 보안 등급, 유효 상태를 붙이는 것입니다. 특히 파일명에 ‘최종’, ‘최종수정’, ‘진짜최종’이 반복되는 조직이라면 AI 도입보다 문서 생애주기 규칙을 먼저 정해야 합니다. 시스템이 최신 버전을 판단할 메타데이터가 없다면 더 큰 언어 모델을 사용해도 충돌은 해결되지 않습니다.

A. 문서를 자르는 방식도 질문 유형에 맞아야 합니다

RAG는 긴 문서를 검색 가능한 작은 구간, 즉 청크로 나누어 색인합니다. 청크가 지나치게 짧으면 조건과 예외가 분리되고, 너무 길면 관련 없는 문장이 섞여 검색 정밀도가 낮아집니다. 예컨대 환불 규정에서 ‘구매 후 7일’만 검색되고 바로 뒤의 ‘디지털 콘텐츠 사용 시작 시 제외’가 빠진다면 위험한 답이 만들어집니다.

1. 정책 문서: 조항과 하위 예외를 함께 묶고 시행일을 메타데이터로 보존합니다.
2. 회의록: 회의 단위로 저장하되 결정 사항, 담당자, 기한을 별도 필드로 추출합니다.
3. 기술 문서: 제목과 코드 블록, 오류 메시지의 관계가 끊어지지 않도록 나눕니다.
4. 고객 문의: 개인정보를 제거하고 해결 여부와 제품 버전을 함께 기록합니다.
5. 계약 자료: 계약 당사자와 유효 기간별로 접근 권한을 별도 적용합니다.

초기에는 모든 저장소를 한꺼번에 연결하지 않는 편이 낫습니다. 질문 빈도가 높고 문서 소유자가 명확한 영역 하나를 선택하세요. 신규 입사자 온보딩, IT 장비 신청, 제품 기능 설명처럼 범위를 제한하면 검색 실패의 원인을 데이터, 권한, 검색 방식 중 어디에서 찾아야 하는지 훨씬 선명해집니다.

Q. 키워드 검색과 벡터 검색 중 무엇을 선택해야 하나요?

A. 기업 환경에서는 두 방식을 섞는 하이브리드 검색이 유리합니다

벡터 검색은 질문과 문서의 의미가 비슷한지를 계산하므로 표현이 달라도 관련 내용을 찾는 데 강합니다. 직원이 “퇴사할 때 노트북을 어떻게 반납하나요?”라고 물었을 때 문서 제목이 ‘오프보딩 자산 회수 절차’여도 연결할 수 있습니다. 반면 제품 코드, 오류 번호, 고객사명, 법률 조항처럼 정확한 문자열이 중요한 질문은 전통적인 키워드 검색이 더 안정적입니다.

따라서 실무에서는 키워드 검색과 벡터 검색 결과를 합친 뒤 다시 순위를 매기는 하이브리드 검색이 자주 쓰입니다. 검색 결과 후보를 넓게 뽑고, 재순위화 모델이 질문과 가장 밀접한 구간을 상단으로 올리는 구조입니다. IT가 정보의 수집·처리·전달을 포괄한다는 맥락은 IT 개념 자료에서 확인할 수 있으며, 사내 검색 역시 생성 모델 하나가 아니라 수집부터 전달까지 이어지는 시스템으로 봐야 합니다.

A. 질문을 재작성하는 단계가 검색 품질을 좌우합니다

사용자는 완전한 문장으로 질문하지 않습니다. “맥북 반납”, “출장비 해외”, “로그인 403”처럼 짧게 입력하거나 앞선 대화를 전제로 “그 예외는?”이라고 되묻습니다. 검색 전에 대화 맥락을 포함한 독립 질문으로 바꾸고, 사내 약어를 공식 용어로 확장하면 관련 문서를 찾을 가능성이 커집니다. 다만 재작성 과정에서 원래 질문의 숫자나 제품명이 바뀌지 않도록 원문도 함께 보존해야 합니다.

검색 후보 개수도 무조건 늘려서는 안 됩니다. 관련 구간을 너무 많이 모델에 전달하면 비용과 응답 시간이 증가하고, 서로 다른 문서의 표현이 충돌할 수 있습니다. 작은 평가 질문 세트를 만든 뒤 후보 개수와 재순위화 범위를 바꾸며 정답 근거가 실제로 포함되는 비율을 측정하는 편이 안전합니다.

Q. 정확도는 어떤 숫자로 평가해야 하나요?

A. 답변 문장보다 검색 근거를 먼저 채점해야 합니다

“직원들이 써 보니 괜찮다고 했다”는 평가는 출시 판단의 근거로 부족합니다. 질문을 조금만 바꾸거나 다른 부서가 사용하면 결과가 급격히 달라질 수 있기 때문입니다. 먼저 실제 업무 질문 50~100개를 모으고, 각 질문에 정답 문서와 반드시 포함되어야 할 근거 구간을 지정해야 합니다. 질문은 쉬운 것만 고르지 말고 최신 버전 구분, 접근 권한, 답이 없는 상황까지 섞어야 합니다.

평가는 크게 검색 단계와 생성 단계로 나눕니다. 검색 단계에서는 상위 결과 안에 정답 근거가 들어왔는지 확인하고, 생성 단계에서는 답변이 그 근거를 충실히 반영했는지 봅니다. 검색에 정답 문서가 없는데 생성된 답이 맞아 보인다면 모델이 일반 지식으로 추측했을 가능성이 있으므로 성공으로 처리해서는 안 됩니다.

• 근거 재현율: 필요한 자료가 상위 검색 결과에 포함된 비율입니다.
• 근거 정밀도: 가져온 자료 중 실제 질문과 관련된 자료의 비율입니다.
• 근거 충실성: 답변의 주장들이 제시된 문서로 뒷받침되는 정도입니다.
• 답변 가능성 판단: 자료가 없을 때 억지로 답하지 않고 모른다고 말하는지 확인합니다.
• 인용 정확성: 출처 링크가 실제 해당 문장과 조항으로 이어지는지 점검합니다.
• 응답 시간: 사용자가 업무 흐름을 끊지 않고 기다릴 수 있는 속도인지 측정합니다.

A. 실패 사례를 별도 데이터로 축적해야 개선됩니다

운영 중에는 좋아요 비율만 보지 말고 실패 사유를 분류해야 합니다. ‘문서가 없음’, ‘최신 버전 선택 실패’, ‘권한 필터 오류’, ‘검색은 성공했지만 답변 왜곡’, ‘질문 의도 오해’처럼 원인을 나누면 개선 순서가 보입니다. 답변이 틀렸다는 신고만 쌓이면 팀은 매번 프롬프트를 수정하게 되지만, 실제 원인은 원본 문서의 중복일 수 있습니다.

평가 세트는 한 번 만들고 끝내는 시험지가 아닙니다. 새 정책이 생기거나 제품명이 바뀌면 질문과 정답 근거도 갱신해야 합니다. 매주 실패 질문을 검토해 대표 사례를 회귀 테스트에 추가하면, 검색 설정을 바꾼 뒤 기존에 잘되던 질문이 망가지는 현상을 빠르게 발견할 수 있습니다.

“정확도 90%라는 숫자보다 더 중요한 질문은 나머지 10%가 어떤 업무에서 발생하며, 틀렸을 때 회사가 감당할 피해가 얼마인가입니다.”

Q. 보안과 비용은 어느 단계에서 따져야 하나요?

A. 문서를 수집하는 순간부터 원래 권한을 유지해야 합니다

사내 문서 AI 검색에서 가장 위험한 사고는 외부 유출만이 아닙니다. 평소에는 볼 수 없던 급여표, 인사 평가, 투자 협상 자료가 내부 검색을 통해 다른 직원에게 노출되는 것도 중대한 권한 사고입니다. 원본 저장소에서 문서를 가져올 때 사용자와 그룹 권한을 함께 동기화하고, 검색 결과를 만들기 전에 권한 필터가 적용되도록 설계해야 합니다.

생성 단계에서 “이 내용은 보여주지 마세요”라고 프롬프트에 적는 것은 접근 통제가 아닙니다. 권한이 없는 문서는 검색 후보 자체에 들어오지 않아야 하며, 답변에 표시되는 제목과 미리보기에도 같은 규칙이 적용되어야 합니다. 퇴사자 계정 비활성화, 부서 이동, 외부 협력자 권한 만료가 검색 색인에 얼마나 빨리 반영되는지도 반드시 시험해야 합니다.

• 원본 저장소의 사용자·그룹 권한을 색인과 동기화합니다.
• 주민등록번호, 계좌번호, 건강 정보 등 민감정보는 수집 전 탐지·마스킹합니다.
• 질문, 검색 문서, 생성 답변을 누가 열람할 수 있는지 로그 권한을 구분합니다.
• 외부 모델 사업자의 데이터 보관 기간과 재학습 사용 여부를 계약에서 확인합니다.
• 삭제 요청이 발생했을 때 원본, 검색 색인, 캐시, 로그에서 제거되는 경로를 시험합니다.
• 프롬프트 인젝션 문장이 문서 안에 포함됐을 때 시스템 지시를 침범하지 않는지 점검합니다.

A. 비용은 모델 사용료보다 전체 운영 단위로 계산합니다

초기 비용에는 문서 수집 커넥터, 텍스트 추출, 임베딩 생성, 검색 인덱스, 재순위화, 생성 모델 호출이 포함됩니다. 운영을 시작하면 변경 문서 재색인, 로그 보관, 평가 자동화, 보안 검토, 실패 사례를 수정할 담당자의 시간도 들어갑니다. 따라서 “질문 한 번에 얼마인가”만 계산하면 실제 총비용을 크게 낮춰 보게 됩니다.

예산이 제한된 스타트업은 모든 질문을 가장 큰 모델로 보내기보다 작업을 나누는 방식이 효과적입니다. 질문 분류와 검색어 확장은 작고 빠른 모델로 처리하고, 복잡한 종합 답변에만 성능이 높은 모델을 사용할 수 있습니다. 반복 질문은 권한과 문서 버전을 확인한 뒤 캐시하되, 정책 변경이 잦은 영역은 캐시 만료 시간을 짧게 두어야 합니다.

시범 운영에서는 월 비용 상한과 함께 질문당 허용 비용을 정하고, 부서별 사용량을 관찰하는 것이 좋습니다. 사용량이 많다는 사실만으로 성공은 아닙니다. 직원이 검색 시간을 실제로 줄였는지, 잘못된 답을 검증하느라 더 많은 시간을 쓰지는 않는지까지 업무 지표와 연결해야 합니다.

Q. 우리 조직은 작은 실험과 본격 구축 중 어디서 시작할까요?

A. 문서가 흩어진 팀은 4주짜리 제한 실험이 맞습니다

자료가 개인 드라이브, 메신저, 위키에 흩어져 있고 최신 문서의 소유자도 불분명하다면 전사 검색부터 시작하지 마세요. 한 부서와 하나의 질문 유형을 정한 뒤 4주 동안 문서 정비와 평가를 함께 진행하는 편이 좋습니다. 예를 들어 고객지원팀의 제품 사용법 질문만 대상으로 삼으면 정답 문서와 실패 비용을 비교적 명확히 정의할 수 있습니다.

첫 주에는 자주 묻는 질문과 정답 근거를 수집하고, 둘째 주에는 중복 문서와 권한을 정비합니다. 셋째 주에는 키워드·벡터·하이브리드 검색을 같은 질문으로 시험하며, 넷째 주에는 실제 사용자에게 제한 공개합니다. 이때 답변마다 출처, 문서 수정일, 피드백 버튼을 보여주고 고위험 질문은 담당자에게 연결하세요.

1. 한 달에 반복되는 내부 질문이 최소 수십 건인지 확인합니다.
2. 그 질문에 답할 공식 문서와 책임자가 존재하는지 찾습니다.
3. 정답 질문, 애매한 질문, 답이 없는 질문을 평가 세트에 함께 넣습니다.
4. 오답이 발생했을 때 사람에게 전환되는 경로를 만듭니다.
5. 검색 시간 절감, 근거 확인률, 위험 오답률을 도입 전후로 비교합니다.

A. 문서 체계가 잡힌 조직은 검색 계층부터 본격 설계합니다

반대로 문서 소유자와 폐기 규칙이 이미 운영되고, 저장소 권한이 일관되며, API로 변경 이력을 받을 수 있는 조직이라면 본격 구축을 고려할 수 있습니다. 이 경우에는 단순 챗봇 화면보다 수집 계층, 권한 필터, 검색·재순위화, 답변 생성, 감사 로그를 분리해 설계해야 합니다. 정보기술의 범위와 활용 맥락은 IT 관련 지식백과처럼 기본 자료를 참고할 수 있지만, 실제 기업 환경에서는 각 계층의 책임자를 지정하는 일이 더 중요합니다.

첫 번째 독자, 아직 “어느 문서가 최신인지 담당자에게 물어봐야 아는” 스타트업이라면 고가의 전사형 AI 검색 제품보다 문서 100개 안팎의 제한 실험을 권합니다. 질문 세트를 만들고 문서 소유권부터 바로잡으면, RAG가 해결할 문제와 조직 운영이 해결할 문제가 분리됩니다.

두 번째 독자, 이미 문서 정책과 접근 권한이 안정적으로 관리되고 여러 부서가 같은 검색 수요를 반복해서 제기한다면 하이브리드 검색, 재순위화, 권한 동기화, 자동 평가를 갖춘 본격 시스템이 적합합니다. 다만 처음부터 업무 실행 권한까지 AI에 주지는 마세요. 검색 답변의 위험 오답률과 출처 확인 행동이 충분히 안정된 뒤, 승인 가능한 낮은 위험 작업부터 단계적으로 연결하는 선택이 현실적입니다.