사내 문서 AI 검색, RAG보다 먼저 정해야 할 3가지

회사 내부 문서 검색 AI는 모델 선택보다 “어디를 연결하고, 누가 볼 수 있으며, 어느 범위부터 시작할지”를 먼저 정해야 합니다.

들어가며 — 독자가 지금 이 문제를 검색하는 이유

회사 안에는 이미 많은 지식이 쌓여 있습니다.

SharePoint와 OneDrive 문서, Confluence 회의록, 파일서버의 설계 자료, 제안서, 품질 이슈 보고서까지 다양합니다. 문제는 자료가 없다는 데 있지 않습니다. 필요한 순간에 찾기 어렵다는 데 있습니다.

그래서 많은 조직이 “사내 문서 AI 검색”이나 “RAG PoC”를 검토합니다.

하지만 처음부터 전사 챗봇을 만들거나, 어떤 모델을 쓸지부터 정하면 방향이 쉽게 흔들립니다.

사내 문서 AI 검색의 출발점은 기술 이름이 아니라 운영 조건입니다.

• 어떤 저장소를 연결할 것인가?
• 기존 문서 권한은 어떻게 지킬 것인가?
• 어느 팀의 어떤 문제부터 작게 해결할 것인가?

이 세 가지가 정리되지 않으면 검색 품질을 따지기 전에 보안, 범위, 운영 리스크에서 막힐 가능성이 큽니다.

1. 먼저 “어떤 저장소를 연결할지” 정해야 합니다

사내 문서 AI 검색을 시작할 때 가장 먼저 할 일은 전체 문서를 한 번에 연결하는 것이 아닙니다.

우선 하나의 저장소를 고르는 일입니다.

예를 들면 다음 중 하나입니다.

• SharePoint
• OneDrive
• Confluence
• 파일서버
• 팀별 문서 라이브러리

Microsoft의 Microsoft 365 Copilot connectors 문서는 Microsoft 365 외부 데이터까지 Copilot과 Microsoft Search 경험으로 확장할 수 있다고 설명합니다. 즉, 사내 지식 검색은 특정 문서함 안에서 끝나는 문제가 아니라, 어떤 외부·내부 데이터 원천을 연결할 것인지의 문제로 이어집니다.

출처: Microsoft 365 Copilot connectors overview

하지만 연결할 수 있다고 해서 모두 연결해야 하는 것은 아닙니다.

작은 PoC라면 “전사 문서 전체”보다 “한 팀의 FAQ 문서 검색”이 더 현실적입니다.

예를 들어 설계팀은 설계 변경 이력 문서, 품질팀은 유사 품질 이슈 사례, 영업팀은 제안서 문구 재사용처럼 구체적인 업무 장면부터 시작할 수 있습니다.

이렇게 범위를 좁히면 세 가지가 좋아집니다.

1. 검색 대상 문서가 명확해집니다.

2. 사용자 피드백을 빠르게 받을 수 있습니다.

3. 권한과 보안 검토 범위가 줄어듭니다.

처음부터 “우리 회사의 모든 지식을 답하는 AI”를 목표로 잡기보다, “이 팀이 자주 찾는 문서를 더 빨리 찾게 하는 AI”로 시작하는 편이 실무적으로 안전합니다.

2. 기존 권한을 유지할 수 있는지 확인해야 합니다

사내 문서 AI 검색에서 가장 중요한 질문은 “답을 잘하느냐”만이 아닙니다.

“그 답을 볼 권한이 없는 사람에게 보여주지 않는가”가 더 중요할 수 있습니다.

SharePoint agents 관련 안내는 사용 권한이 있는 사이트와 문서 라이브러리 내용을 대상으로 답변한다고 설명합니다.

출처: Get started with agents in SharePoint

이 관점은 사내 AI 검색을 도입할 때 중요한 기준이 됩니다.

AI가 문서를 요약하거나 답변을 만들더라도, 원본 문서의 접근 권한을 우회해서는 안 됩니다.

따라서 PoC 단계에서도 다음을 확인해야 합니다.

• 사용자가 원래 볼 수 있는 문서만 검색되는가?
• 팀별·직무별 권한이 답변에도 반영되는가?
• 퇴사자, 조직 이동자, 외부 협력자 권한 변경이 검색 결과에 반영되는가?
• 답변에 민감 문서 내용이 섞여 나오지 않는가?

사내 문서 AI는 “검색창을 더 똑똑하게 만드는 일”처럼 보이지만, 실제로는 기존 문서 권한 체계를 AI 경험 안에서도 유지하는 일에 가깝습니다.

그래서 RAG를 구현하기 전에 문서 권한 구조부터 점검해야 합니다.

3. 전사 AI보다 “팀별 상담원”으로 시작하는 편이 현실적입니다

많은 조직이 AI를 도입할 때 “전사 공통 챗봇”을 먼저 떠올립니다.

하지만 부서마다 문서의 종류와 질문 방식은 다릅니다.

설계팀은 설계 변경 이력이나 기술 기준을 찾고, 품질팀은 유사 이슈와 조치 사례를 찾습니다. 영업팀은 과거 제안서 문구나 고객 대응 자료를 재사용하고 싶어 할 수 있습니다.

Google은 Gemini Enterprise를 업무용 AI의 새로운 진입점으로 소개하며, Google Workspace, Microsoft 365, Salesforce, SAP 등 회사 데이터에 연결하고 노코드 워크벤치로 정보 분석과 에이전트 오케스트레이션을 지원한다고 설명합니다.

출처: Introducing Gemini Enterprise, Gemini Enterprise

이 흐름에서 중요한 점은 “AI 하나가 모든 업무를 해결한다”가 아닙니다.

오히려 각 팀의 데이터와 업무 맥락에 맞게 작은 AI 적용 단위를 만들 수 있다는 점입니다.

예를 들면 다음과 같습니다.

• 설계팀: 설계 변경 이력 찾기
• 품질팀: 유사 품질 이슈 사례 검색
• 영업팀: 제안서 문구 재사용
• 관리팀: 사내 규정 FAQ 검색

이런 접근은 “AI를 도입하자”는 추상적인 목표보다 훨씬 설득력이 있습니다.

사용자가 실제로 반복해서 겪는 검색 문제를 다루기 때문입니다.

4. 제품 기능보다 서비스 지속성과 운영 리스크도 봐야 합니다

사내 지식 AI 도구를 고를 때 검색 품질이나 답변 기능만 비교하면 부족합니다.

공식 로드맵, 신규 가입 가능 여부, 데이터 커넥터 지원 범위, 권한 유지 방식까지 함께 확인해야 합니다.

AWS의 Amazon Q Business 공식 페이지는 2026년 7월 30일부터 신규 고객에게 더 이상 열리지 않는다고 공지하고, 유사 기능으로 Amazon Quick을 안내합니다. 기존 고객은 현재 서비스를 계속 사용하거나 Q index를 Quick에서 활용할 수 있다고 설명합니다.

출처: Amazon Q Business, Amazon Q Business now generally available

이 사례는 사내 AI 검색 도입에서 중요한 시사점을 줍니다.

도구를 선택할 때 “지금 기능이 좋아 보이는가”만 볼 것이 아니라, 앞으로도 안정적으로 운영할 수 있는지 확인해야 합니다.

특히 사내 문서 AI는 한 번 연결하면 업무 흐름 안으로 들어옵니다.

그런데 서비스 방향이 바뀌거나, 신규 고객 지원 정책이 달라지거나, 커넥터 지원 범위가 기대와 다르면 운영 부담이 커질 수 있습니다.

따라서 PoC 단계에서도 다음 질문이 필요합니다.

• 이 제품은 공식적으로 계속 지원되는가?
• 신규 고객이나 신규 워크로드에 제한이 있는가?
• 우리 회사가 쓰는 저장소와 연결할 수 있는가?
• 기존 문서 권한을 유지할 수 있는가?
• 향후 다른 도구로 전환해야 할 때 데이터와 인덱스를 어떻게 다룰 수 있는가?

사내 문서 AI 검색은 단순한 기능 테스트가 아니라, 장기 운영 가능성까지 함께 보는 도입 과제입니다.

바로 적용하는 체크리스트 또는 비교 기준

사내 문서 AI 검색 PoC를 시작하기 전, 아래 항목부터 확인해볼 수 있습니다.

1. 검색 범위

• 전사 문서 전체가 아니라 한 팀 또는 한 저장소로 시작하는가?
• SharePoint, OneDrive, Confluence, 파일서버 중 우선 연결 대상을 정했는가?
• 검색할 문서 유형이 명확한가?
• 자주 묻는 질문이나 반복 검색 업무가 있는가?

2. 권한과 보안

• 사용자가 원래 볼 수 있는 문서만 검색되는가?
• 문서 권한 변경이 AI 검색 결과에도 반영되는가?
• 민감 문서가 답변에 섞이지 않도록 통제할 수 있는가?
• 외부 협력자나 조직 이동자의 접근 권한을 관리할 수 있는가?

3. 팀별 적용 시나리오

• 설계팀은 설계 변경 이력 검색처럼 구체적인 문제가 있는가?
• 품질팀은 유사 이슈 사례 검색처럼 반복 업무가 있는가?
• 영업팀은 제안서 문구 재사용처럼 재활용 가치가 있는 문서가 있는가?
• “전사 챗봇”보다 “팀별 상담원” 형태로 좁힐 수 있는가?

4. 제품과 운영 리스크

• 공식 문서에서 서비스 지원 상태를 확인했는가?
• 신규 고객 또는 신규 사용에 제한이 있는지 확인했는가?
• 필요한 커넥터를 지원하는가?
• 기존 권한 체계를 유지할 수 있는가?
• 향후 다른 제품으로 전환할 때 고려할 요소가 있는가?

5. PoC 성공 기준

• 사용자가 실제로 찾고 싶어 하는 질문을 기준으로 테스트하는가?
• 답변의 출처 문서를 확인할 수 있는가?
• 검색 실패 사례를 수집할 수 있는가?
• 한 팀에서 반복 사용해볼 만큼 범위가 작고 명확한가?

마무리 + 생각해볼 질문 1개

사내 문서 AI 검색은 RAG라는 기술 이름보다 먼저 정해야 할 것이 많습니다.

어떤 저장소를 연결할지, 기존 권한을 어떻게 지킬지, 어느 팀의 어떤 문제부터 풀지 결정해야 합니다.

처음부터 전사 AI를 만들려고 하면 범위가 커지고 검증이 어려워집니다.

반대로 한 팀의 FAQ 검색, 설계 변경 이력 찾기, 품질 이슈 유사 사례 검색처럼 작게 시작하면 실제 업무 개선 여부를 더 빠르게 확인할 수 있습니다.

사내 AI 검색의 첫 질문은 “어떤 모델을 쓸까?”가 아니라 “누가, 어떤 문서를, 어떤 권한으로, 왜 찾는가?”여야 합니다.

생각해볼 질문:

우리 조직에서 가장 먼저 AI 검색으로 줄일 수 있는 반복 검색 업무는 어느 팀의 어떤 문서에 있을까요?