사내 문서 검색, 챗봇보다 먼저 "Gemini Enterprise 업무 포털"로 검증해야 합니다

사내 AI 검색 PoC는 답변 품질보다 먼저 "어떤 업무 앱을 연결하고, 권한을 어떻게 지키며, 검색 결과를 어떤 업무 흐름으로 바꿀 것인가"를 확인해야 합니다.

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

사내 문서 AI 검색을 만들겠다고 하면 대개 첫 질문은 이렇습니다.

"RAG를 직접 구축해야 할까, 아니면 완성형 제품을 써야 할까?"

그런데 현업 입장에서는 그보다 먼저 물어야 할 질문이 있습니다.

"직원이 매일 쓰는 문서와 업무 앱을 한곳에서 찾고, 기존 권한을 유지한 채 답변받고, 그다음 행동까지 이어갈 수 있는가?"

이렇게 보면 사내 AI 검색은 단순한 챗봇 문제가 아닙니다. 업무 포털에 더 가깝습니다. Google Cloud가 소개한 Gemini Enterprise는 이 관점에서 검토해볼 만한 후보입니다. Google Cloud는 Gemini Enterprise를 "AI in the workplace"의 새 진입점으로 소개했고, 공식 문서에서는 기업용 검색, 커넥터, 권한 기반 접근, no-code 워크플로우를 주요 요소로 설명합니다.

이 글은 "Gemini Enterprise가 좋은가?"를 단정하려는 글이 아닙니다. 사내 문서 검색/RAG 후보로 검토할 때, PoC에서 무엇을 먼저 확인해야 하는지 정리하는 글입니다.

챗봇이 아니라 업무 포털로 봐야 하는 이유

사내 문서 검색이 실패하는 이유는 보통 모델 성능만의 문제가 아닙니다.

문제는 더 단순합니다.

• 문서가 여러 업무 앱에 흩어져 있습니다.
• 사용자는 최신 문서가 어디에 있는지 모릅니다.
• 검색 결과가 나와도 접근 권한이 맞는지 불안합니다.
• 답변을 받은 뒤 다시 Jira, Confluence, SharePoint, ServiceNow 같은 업무 도구로 이동해야 합니다.

Gemini Enterprise 공식 문서는 Confluence, Jira, Microsoft SharePoint, ServiceNow 등 여러 업무 앱과의 커넥터를 언급합니다. 제품 설명도 단순 대화형 챗봇보다 기업용 검색과 업무 흐름 통합에 가깝습니다. 출발점을 "챗봇 하나 만들기"로 잡으면 답변 UI만 보게 됩니다. 반대로 "업무 포털 검증"으로 잡으면 확인해야 할 항목이 달라집니다.

첫째, 어떤 업무 앱을 연결할 수 있는지 봐야 합니다.

둘째, 기존 권한이 검색 결과에 반영되는지 봐야 합니다.

셋째, 검색이 끝난 뒤 업무 흐름을 만들 수 있는지 봐야 합니다.

넷째, 운영자가 이를 통제하고 감사할 수 있는지 확인해야 합니다.

Google Cloud의 Gemini Enterprise 개요 문서는 Gemini Enterprise를 기업 사용자가 사내 정보와 도구에 접근하는 진입점으로 설명합니다. 이 설명대로라면 PoC의 목표도 "질문에 답하는 챗봇"이 아니라 "업무 앱을 묶는 AI 검색 포털"이어야 합니다.

PoC 1단계: 연결할 업무 앱을 먼저 고른다

사내 검색 PoC에서 흔한 실수는 문서를 무작정 많이 넣는 것입니다. 이렇게 하면 데모는 그럴듯해 보이지만, 현업 검증은 오히려 어려워집니다.

Gemini Enterprise를 검토한다면 먼저 커넥터 기준으로 범위를 좁히는 편이 안전합니다. 공식 자료에서 언급된 Confluence, Jira, Microsoft SharePoint, ServiceNow 같은 업무 앱 중 하나 또는 두 개를 고르고, 그 안에서 실제 업무 질문을 만듭니다.

예를 들면 이런 식입니다.

• "최근 프로젝트 회의 결정사항을 찾는다"
• "특정 설비 변경 요청과 관련된 Jira 이슈를 찾는다"
• "SharePoint에 있는 표준 절차서에서 필요한 항목을 찾는다"
• "ServiceNow 티켓과 관련 문서를 함께 확인한다"

여기서 중요한 것은 "검색이 된다"가 아닙니다. 사용자가 원래 하던 일을 더 적은 이동으로 끝낼 수 있는지 봐야 합니다.

Google Cloud의 제품 페이지는 Gemini Enterprise를 업무용 AI 플랫폼으로 소개합니다. 따라서 PoC 질문도 일반 지식 질문이 아니라 실제 업무 앱 안에 있는 정보로 구성해야 합니다. 그래야 이 제품이 사내 업무 포털 후보인지, 단순 검색창에 가까운지 판단할 수 있습니다.

PoC 2단계: 권한 기반 검색을 검증한다

사내 문서 검색에서 가장 민감한 부분은 답변 품질보다 권한입니다.

Gemini Enterprise 공식 문서는 "permissions-aware access"를 명시합니다. 검색과 답변이 사용자 권한을 고려해야 한다는 방향입니다. 이 항목은 PoC에서 반드시 따로 검증해야 합니다.

검증 방법이 복잡할 필요는 없습니다. 같은 질문을 서로 다른 권한의 사용자 계정으로 던져보면 됩니다.

예를 들어 다음과 같이 나눌 수 있습니다.

• 일반 직원 계정
• 특정 프로젝트 멤버 계정
• 관리자 또는 리더 계정

같은 질문을 했을 때 각 계정이 볼 수 있는 문서와 답변이 달라져야 합니다. 접근 권한이 없는 문서의 내용이 답변에 섞이면 안 됩니다. 반대로 권한이 있는 문서인데 검색되지 않는다면 업무 활용성이 떨어집니다.

이 검증은 "보안팀이 나중에 볼 문제"가 아닙니다. 사내 AI 검색 PoC의 첫 번째 통과 기준에 가깝습니다. 권한이 흔들리면 검색 품질이 좋아도 실제 배포가 어렵습니다.

PoC 3단계: no-code 워크플로우를 업무 산출물로 확인한다

Gemini Enterprise를 단순 검색 도구로만 보면 no-code workflow builder의 의미를 놓치기 쉽습니다.

사내 검색의 목표는 답변을 읽고 끝나는 것이 아닙니다. 현업은 보통 답변 이후에 다음 행동을 합니다.

• 관련 이슈를 확인합니다.
• 문서 링크를 공유합니다.
• 요청 내용을 정리합니다.
• 담당자에게 후속 작업을 넘깁니다.
• 표준 절차에 맞는 다음 단계를 확인합니다.

따라서 PoC에서는 "좋은 답변"보다 "작은 업무 산출물"을 하나 정하는 편이 좋습니다.

예를 들어 산출물을 이렇게 잡을 수 있습니다.

"SharePoint 문서와 Jira 이슈를 바탕으로, 특정 프로젝트의 변경 요청 요약을 만든다."

이 산출물을 기준으로 보면 검증 질문이 선명해집니다.

• 필요한 원문을 찾았는가?
• 출처 링크를 확인할 수 있는가?
• 사용자의 권한 안에서만 답변했는가?
• 후속 업무로 이어지는 흐름을 만들 수 있는가?
• 현업 담당자가 결과를 검토하고 수정할 수 있는가?

Google Cloud가 Gemini Enterprise 소개 글에서 업무 현장의 AI 진입점을 강조한 이유도 이 지점과 맞닿아 있습니다. 기업용 AI 검색은 "질문과 답변"에서 끝나지 않습니다. 검색 결과가 업무 흐름으로 이어져야 합니다.

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

Gemini Enterprise를 사내 문서 검색/RAG 후보로 검토한다면, PoC 체크리스트를 다음 순서로 잡아볼 수 있습니다.

1. 연결 범위

• 연결하려는 업무 앱이 명확한가?
• 공식 커넥터로 연결 가능한 앱인가?
• Confluence, Jira, Microsoft SharePoint, ServiceNow 등 기존 업무 도구 중 어디부터 검증할 것인가?
• 데모용 문서가 아니라 실제 업무 문서로 테스트하는가?

2. 권한 검증

• 서로 다른 권한의 사용자 계정으로 같은 질문을 테스트했는가?
• 권한이 없는 문서 내용이 답변에 섞이지 않는가?
• 권한이 있는 문서는 정상적으로 검색되는가?
• 검색 결과와 답변에서 출처를 확인할 수 있는가?

3. 업무 산출물

• 단순 질의응답이 아니라 하나의 업무 결과물을 정했는가?
• 예: 변경 요청 요약, 프로젝트 이슈 정리, 표준 절차 확인, 티켓 관련 문서 검색
• 답변 이후 사용자가 어떤 행동을 해야 하는지 정했는가?
• no-code 워크플로우로 만들 수 있는 최소 흐름을 정의했는가?

4. 운영과 거버넌스

• 누가 커넥터를 추가하거나 제거할 수 있는가?
• 어떤 데이터 소스를 PoC에 포함하고 제외할 것인가?
• 민감 문서가 포함될 가능성을 사전에 점검했는가?
• 배포 전 감사, 보안, 권한 검토 기준을 정했는가?

5. 기존 RAG 구축과 비교할 기준

비교 항목	직접 RAG 구축	Gemini Enterprise 검토 포인트
시작점	문서 수집과 색인 설계	업무 앱 연결과 사용자 경험
핵심 검증	검색 품질, 청킹, 임베딩	커넥터, 권한 기반 접근, 업무 흐름
운영 부담	인프라와 파이프라인 직접 관리	제품 기능과 관리 정책 확인
현업 체감	챗봇 또는 검색창	업무 포털형 진입점
보안 검증	별도 설계 필요	permissions-aware access 동작 검증 필요

여기서 중요한 것은 어느 쪽이 무조건 낫다는 결론이 아닙니다. 직접 RAG 구축은 세밀한 제어가 필요할 때 유리할 수 있습니다. 반대로 Gemini Enterprise 같은 제품은 이미 쓰는 업무 앱과 권한 체계를 중심으로 빠르게 검증해볼 수 있습니다.

PoC의 질문은 이렇게 바뀌어야 합니다.

"답변을 잘하나?"보다

"우리 업무 앱, 권한, 산출물 흐름에 맞게 쓸 수 있나?"

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

사내 문서 AI 검색을 챗봇으로만 보면 모델 답변 품질에 시선이 쏠립니다. 하지만 실제 배포 단계에서는 업무 앱 연결, 권한, 출처, 운영 정책이 더 빨리 발목을 잡습니다.

Gemini Enterprise를 검토한다면 PoC를 크게 만들 필요는 없습니다. Confluence나 SharePoint 같은 핵심 문서 저장소 하나, Jira나 ServiceNow 같은 업무 앱 하나를 고릅니다. 그리고 실제 현업 질문 하나를 정합니다. 그 질문에 대해 권한이 지켜지는지, 출처가 보이는지, 결과가 업무 산출물로 이어지는지 확인합니다.

그 정도면 이 제품이 우리 회사의 AI 업무 포털 후보인지, 아니면 아직은 일반 검색 챗봇 수준으로만 써야 하는지 판단할 수 있습니다.

생각해볼 질문은 하나입니다.

우리 회사에서 AI 검색이 가장 먼저 해결해야 할 문제는 "문서를 찾는 것"인가요, 아니면 "문서를 찾은 뒤 다음 업무까지 이어주는 것"인가요?