사내 챗봇 권한, 무엇부터 확인해야 할까?

직답 요약

사내 챗봇 도입을 검토할 때는 챗봇의 기능이나 설정만 살펴봐서는 충분하지 않습니다. 연결할 문서가 현재 누구에게 공개돼 있는지도 함께 확인해야 합니다. 마이크로소프트는 챗봇 도입 과정에서 위험한 문서를 먼저 검색 대상에서 가려 두고, 문서 분류와 권한 정리는 이후에 진행하는 방식을 안내합니다. 권한 정리가 끝날 때까지 도입을 모두 멈출 필요는 없습니다. 정리하는 동안 특정 문서를 챗봇이 발견하거나 참조하지 못하도록 제한하는 기능을 제공하는 솔루션도 있습니다.

질문 한 줄로 사내 문서를 찾아 주는 챗봇을 부서에 도입했습니다. 첫 주에 들어오는 질문은 대개 예상 범위입니다. 휴가 규정은 어떻게 되는지, 출장비는 며칠 안에 정산되는지 같은 것들입니다. 그러다 어느 날 누군가 이렇게 묻습니다. "우리 팀 평가 자료가 왜 검색되나요?"

챗봇이 잠긴 문을 억지로 연 것은 아닙니다. 그 문은 원래 열려 있었고, 다만 문의 위치를 아무도 몰랐을 뿐입니다. 실제로 사내 챗봇을 먼저 도입한 일부 기업에서도 이와 비슷한 문제가 도입 이후에야 드러났습니다.

따라서 사내 챗봇 도입을 검토할 때는 챗봇에 연결할 문서와 기존 접근 권한을 먼저 살펴봐야 합니다.

챗봇, 도입만 하면 끝일까?

챗봇 도입만큼 보안 관리 또한 중요합니다. 챗봇을 먼저 도입한 일부 회사에서, 볼 필요가 없는 사원에게까지 사내 문서가 열려 있었다는 사실이 도입 뒤에 드러났습니다.

2024년 11월 비즈니스 인사이더 보도에 따르면, 마이크로소프트 365 코파일럿을 도입한 일부 고객사에서 일반 직원이 임원의 받은편지함을 읽거나 민감한 인사 문서에 접근할 수 있다는 사실이 확인됐습니다. 원인은 기업 IT 부서가 내부 문서 접근 권한을 "모두 허용"에 가깝게 느슨하게 설정해 둔 것이었습니다.

비즈니스 인사이더는 코파일럿이 나오기 전까지 일반 직원에게는 민감한 회사 문서를 찾아내 가져올 도구가 없었다고 전했습니다. 즉, 코파일럿 도입으로 얻는 것과 별개로 보안 관리가 필요한 지점은 더 넓어졌다는 것을 시사합니다.

마이크로소프트는 원인을 코파일럿이 아니라 기업의 느슨한 데이터 거버넌스로 지목하고, 신원과 권한의 중앙 관리를 강화하도록 돕고 있다고 밝혔습니다.

챗봇이 권한을 뚫은 걸까, 원래 열려 있던 걸까?

뚫은 것이 아닙니다. 규칙대로 동작했고, 그 결과가 문제로 드러났습니다.

마이크로소프트 공식 문서는 코파일럿이 "각 개인이 접근할 수 있는 데이터만 제시한다"고 명시합니다. 코파일럿의 에이전트도 기존 마이크로소프트 365 데이터 접근 경계 안에서 동작하며 새 권한을 만들지 않는다고 적혀 있습니다. 코파일럿은 설계대로 움직였습니다.

문제는 그 설계가 전제한 조건입니다. "권한이 있는 것만 보여준다"는 문장은 권한이 제대로 걸려 있을 때만 안전 보장이 됩니다. 권한이 느슨하면 볼 수 있는 것을 전부 보여준다는 뜻이 됩니다.

챗봇 도입을 고려한다면 민감한 문서에 대해 접근 권한을 다시 살펴봐야 합니다. 마이크로소프트도 셰어포인트와 원드라이브의 접근 통제를 설명하면서 그 통제가 사용자 권한을 바꾸지 않은 채 코파일럿이 무엇을 발견하고 참조할 수 있는지에 영향을 준다고 적었습니다. 회사 서류함 열쇠를 받아 두고도 서류함이 어느 층에 있는지 몰랐다면 열쇠를 쓸 일 자체가 없었습니다. 여기서 열쇠에 해당하는 것이 문서에 걸린 접근 권한입니다. 챗봇은 서류함이 어디 있는지 찾아 주고 안에 든 내용까지 요약해 줍니다. 열쇠를 새로 준 것이 아니라 어디 있는지 알려 준 셈입니다.

따라서 챗봇 도입을 위해서는 연결할 문서가 현재 누구에게 열려 있는지, 그리고 그 권한이 실제 업무에 필요한 범위로 설정돼 있는지부터 점검해야 합니다.

그럼 챗봇에 연결할 문서는 무엇부터 점검해야 할까?

과도하게 공유된 문서부터입니다. 마이크로소프트는 코파일럿 도입을 준비하는 조직에 먼저 과도하게 공유된 데이터를 찾아 보호하고, 그다음 더 긴 작업인 데이터 분류와 정리를 진행하는 방식을 권장합니다.

즉, 먼저 위험한 문서를 찾고 우선 노출을 막은 뒤 실제 권한을 수정합니다. 그다음 챗봇에 연결할 문서를 결정하면 됩니다.

첫째, 위험 신호가 겹치는 문서를 찾습니다

마이크로소프트가 제시하는 주요 신호는 다음과 같습니다.

• 누구나 열 수 있는 공유 링크가 걸려 있는 문서

• 지나치게 큰 그룹에 권한이 부여된 문서

• 상위 폴더와 다른 개별 권한이 설정된 문서

• 민감한 내용인데 보호 설정이 약한 문서

• 공개 범위가 넓거나 분류가 되지 않은 공간

• 관리자나 책임자가 없거나 오래 방치된 공간

중요한 것은 신호 하나보다 여러 신호가 겹치는 경우를 먼저 보는 것입니다. 예를 들어 인사 정보가 들어 있는 문서에 전사 공유 링크까지 걸려 있다면 우선순위가 높습니다. 마이크로소프트도 여러 위험 요소가 동시에 나타나는 위치를 고위험 영역으로 보고 먼저 검토하도록 안내합니다.

둘째, 정리가 끝날 때까지 위험 문서를 챗봇 검색 대상에서 빼 둡니다

문서 권한을 모두 정리한 뒤에만 챗봇을 열 수 있다고 생각하면 도입 일정이 크게 늘어날 수 있습니다. 반드시 그럴 필요는 없습니다.

마이크로소프트는 위험한 영역을 먼저 찾아 임시로 노출을 줄인 뒤, 실제 권한을 정리하는 방식을 안내합니다. 대표적인 기능이 셰어포인트 관리 기능인 Restricted Content Discovery(제한된 콘텐츠 검색)입니다.

이 기능은 원본 문서의 접근 권한을 바꾸지 않습니다. 이미 접근 권한이 있는 사용자는 기존 방식대로 문서를 직접 열 수 있지만, 해당 문서가 검색이나 코파일럿 답변을 통해 쉽게 발견되지 않도록 제한합니다. 즉, "볼 권한"은 그대로 두고 "챗봇이 찾아 주는 범위"만 줄이는 방식입니다.

반대로 코파일럿이 검색할 수 있는 범위를 지정한 사이트로만 좁혀 두는 방법도 있습니다. 두 방식 모두 기존 권한을 고치는 기능이라기보다 발견 범위를 임시로 통제하는 장치에 가깝습니다.

다만 이런 기능을 너무 넓게 적용하면 코파일럿이 참조할 수 있는 자료 자체가 줄어 답변의 완전성과 관련성이 떨어질 수 있습니다. 또 대규모 공간에서는 설정이 실제로 적용되기까지 시간이 걸릴 수 있으므로 도입 일정에 미리 반영하는 것이 좋습니다.

다른 챗봇 솔루션을 사용한다면 제품 문서에서 한 가지를 확인하면 됩니다. "원본 권한을 바꾸지 않고 특정 문서를 챗봇 검색 대상에서만 제외할 수 있는가?" 그런 기능이 없다면 권한 정리가 끝날 때까지 해당 문서를 챗봇에 연결하지 않는 편이 안전합니다.

셋째, 권한을 실제로 고치고 임시 조치를 해제합니다

임시 조치는 어디까지나 시간을 벌기 위한 장치입니다. 최종적으로는 원래 잘못 설정된 권한을 수정해야 합니다.

대표적으로 확인할 것은 세 가지입니다.

• 필요 이상으로 넓게 부여된 접근 권한 제거

• 상위 폴더와 다르게 설정된 개별 권한 정리

• 문서나 공간의 책임자 지정

부서 단위라면 첫 단계에서 표시한 문서를 하나씩 확인하면 됩니다. 예를 들어 전사 공유 링크는 필요한 인원만 접근할 수 있도록 바꾸고, 오래된 그룹에는 현재 업무상 필요하지 않은 사람을 제외합니다. 특정 문서만 상위 폴더와 다르게 열려 있다면 그 이유가 필요한 설정인지 다시 확인합니다.

이 작업이 끝난 문서부터 임시 검색 제한을 해제하면 됩니다.

넷째, 넘길 것을 가르고 새로 생기는 문서의 기본값을 좁힙니다

여기서 한 가지 더 구분할 필요가 있습니다. 사람이 볼 수 있는 문서와 AI가 답변에 활용해도 되는 문서는 반드시 같지는 않습니다.

예를 들어 열람은 가능하지만, 챗봇이 내용을 요약하거나 다른 질문의 답변 근거로 활용하는 것은 원하지 않는 문서가 있을 수 있습니다. 마이크로소프트도 보호된 문서에서 단순 열람 권한과 내용을 추출해 활용하는 권한을 구분합니다. 강한 보호가 적용된 일부 데이터는 코파일럿과 에이전트가 아예 접근하지 못하도록 설정할 수도 있습니다.

처음부터 복잡한 정보 등급 체계를 새로 만들 필요는 없습니다. 저희는 챗봇 도입 초기라면 연결 후보 문서를 놓고 "챗봇에 넘긴다"와 "넘기지 않는다" 두 가지로만 구분해도 충분하다고 봅니다. 문서 하나마다 한 번씩만 판단하면 되기 때문에 실제 운영도 훨씬 단순합니다.

그리고 앞으로 새로 만들어지는 문서와 폴더에는 같은 문제가 반복되지 않도록 기본 공유 범위를 좁혀 두는 것이 좋습니다. 회사 전체 공유 정책을 바꾸는 일은 정보시스템팀이나 보안팀의 역할일 수 있습니다. 부서에서는 최소한 다음 세 가지 정도를 운영 규칙으로 정할 수 있습니다.

• 챗봇 연결 폴더의 기본 공유 범위를 좁게 설정한다

• 해당 폴더에서는 전사 공유 링크를 만들지 않는다

• 새 문서가 늘어날 때 권한을 다시 확인할 담당자를 정한다

이 규칙이 없으면 문서가 늘어나는 대로 같은 점검을 다시 해야 합니다.

우리가 쓰는 솔루션은 권한을 어떻게 걸까?

권한을 거는 자리는 제품에 따라 다릅니다. 저희가 확인한 것은 원본 문서, 검색 필터, 챗봇 지식 세 곳입니다.

여기까지는 사내 챗봇에 공통으로 적용할 수 있는 절차입니다. 다만 실제로 어디의 권한을 수정해야 하는지는 제품 구조에 따라 달라집니다. 크게 세 가지 방식으로 나눠 볼 수 있습니다.

원본 권한을 그대로 쓰는 경우

마이크로소프트 365 코파일럿이 대표적입니다. 셰어포인트나 원드라이브에 이미 설정된 사용자의 접근 권한을 기준으로 문서를 보여 줍니다. 따라서 문제가 있다면 챗봇 설정이 아니라 원본 문서 권한을 먼저 수정해야 합니다.

필터로 문서를 구분하는 경우

직접 구축한 RAG 시스템에서는 사용자나 부서 정보를 기준으로 검색 단계에서 문서를 걸러 내는 방식을 쓰기도 합니다. 아마존웹서비스(AWS)가 공개한 멀티테넌트 RAG 아키텍처도 이런 구조를 다룹니다.

다만 AWS는 이 방식이 인프라에서 강제되는 격리가 아니라 논리적인 필터링이라는 점을 명시합니다. 따라서 필터 조건이나 중간 애플리케이션 로직에 오류가 생기면 다른 사용자나 조직의 문서가 잘못 노출될 가능성도 고려해야 합니다.

이 경우에는 문서 권한만 보는 것이 아니라 검색 필터를 어떻게 만들고 있는지 구축한 팀에 함께 확인해야 합니다.

지식마다 권한을 새로 지정하는 경우

Dify처럼 원본 파일을 별도의 지식으로 등록한 뒤 그 지식의 접근 범위를 다시 설정하는 제품도 있습니다. 이 구조에서는 원본 파일의 권한과 챗봇 안의 권한이 반드시 같다고 볼 수 없습니다.

따라서 확인해야 할 것은 "누가 지식을 등록했고, 그때 공개 범위를 무엇으로 설정했는가"입니다.

Dify도 기업판에서는 챗봇이나 지식 단위로 접근 범위를 더 세분화할 수 있습니다. 다만 판과 배포 형태마다 다르므로, 실제 도입 전에는 사용하는 요금제에서 어떤 통제가 가능한지 확인해야 합니다.

결국 무엇부터 하면 될까?

챗봇 설정 화면은 마지막에 봐도 됩니다. 먼저 연결할 문서를 목록으로 만들고, 아래 네 가지부터 시작하는 편이 안전합니다.

1. 지금 누구에게 열려 있는지 확인합니다

2. 위험한 문서는 검색 대상에서 잠시 빼 둡니다

3. 실제 권한을 수정합니다

4. 챗봇에 넘길 문서만 다시 연결합니다

그다음 우리가 사용하는 챗봇이 원본 권한을 그대로 따르는지, 검색 필터로 나누는지, 별도의 지식 권한을 만드는지를 확인하면 됩니다. 이 차이는 전체 절차를 바꾸는 것이 아니라 어디의 권한을 확인하고 수정해야 하는지를 결정합니다.

사내 챗봇이 한두 개를 넘어 여러 부서로 늘어나기 시작하면 이런 점검을 챗봇마다 반복하기 어려워집니다. 이때는 만들어진 챗봇과 에이전트를 한곳에 등록하고 정책, 승인, 권한, 감사 이력을 함께 관리하는 별도의 거버넌스 체계를 두는 방법도 있습니다.

오픈네트웍시스템의 AX Foundry는 이런 운영 영역을 다룹니다.

사내 챗봇을 직접 만드는 방법이나 제품 선택이 궁금하다면 Dify 도입 판단 가이드에서 제품 구조와 비용, 배포 형태를 확인할 수 있습니다.

사내 문서를 챗봇이 어떻게 찾아 답변으로 만드는지부터 이해하고 싶다면 RAG란 무엇인가를 함께 참고할 수 있습니다.

자주 묻는 질문

이미 만들어 둔 챗봇은 어떻게 확인할까요?

게시 상태와 접근 권한 설정값을 먼저 보고, 그다음 연결된 문서가 원래 누구에게 열려 있던 것인지 확인합니다. 시험 삼아 만든 챗봇이 기본값 그대로 남아 있기도 하고, 공유하려고 범위를 한 번 넓힌 뒤 되돌리지 않은 경우도 있습니다.

문서 권한부터 정리하려면 시간이 오래 걸리지 않을까요?

전체를 정리할 필요는 없습니다. 챗봇에 연결할 문서만 대상으로 하면 범위가 크게 줄어듭니다. 마이크로소프트도 위험이 큰 곳을 먼저 가려 둔 채 정리와 도입을 함께 진행하는 것을 전제로 안내합니다.

우리가 쓰는 솔루션에 검색 대상에서만 빼는 기능이 없으면 어떻게 할까요?

그 문서를 정리가 끝날 때까지 연결하지 않는 쪽이 안전합니다. 권한을 그대로 둔 채 노출만 줄이는 장치가 없다면, 연결하는 순간 그 문서가 챗봇이 찾을 수 있는 대상이 됩니다. 원본 권한을 상속하는 방식이면 지금 걸려 있는 권한 그대로, 지식을 새로 만드는 방식이면 그 지식에 지정한 범위대로 답변에 실립니다. 연결 목록을 정리가 끝난 문서부터 채워 나가면 도입을 멈추지 않으면서 그 기능이 없어도 비슷한 효과를 낼 수 있습니다.

담당자가 부서를 옮기면 권한은 어떻게 될까요?

Dify 공식 문서는 멤버를 내보내면 그 사람의 작업공간 접근 권한은 즉시 회수되지만, 그가 만들어 둔 챗봇과 지식은 작업공간에 그대로 남는다고 적었습니다. 지식을 따로 등록하는 방식이면 남아 있는 지식의 공개 범위와 소유자를 확인합니다. 문서가 추가되거나 조직이 바뀔 때 그 공개 범위를 다시 볼 사람을 미리 정해 둡니다.

출처

출처

• Business Insider, "Microsoft's Copilot oversharing problem"(2024-11-21): https://www.businessinsider.com/microsoft-copilot-oversharing-problem-fix-customers-2024-11 , 유료 기사로 원문은 열람하지 못했고 Slashdot과 WebProNews의 2차 인용을 통해 확인했습니다

• Microsoft Learn, "Data, Privacy, and Security for Microsoft 365 Copilot": https://learn.microsoft.com/en-us/microsoft-365/copilot/microsoft-365-copilot-privacy

• Microsoft Learn, "Considerations for Microsoft Purview to manage Microsoft 365 Copilot and Channel Agent in Teams": https://learn.microsoft.com/en-us/purview/ai-m365-copilot-considerations

• Microsoft Learn, "Get ready for Microsoft Copilot with SharePoint Advanced Management": https://learn.microsoft.com/en-us/microsoft-365/copilot/get-ready-copilot-sharepoint-advanced-management

• Microsoft Learn, "How do I apply Zero Trust principles to Microsoft 365 Copilot?": https://learn.microsoft.com/en-us/security/zero-trust/copilots/zero-trust-microsoft-365-copilot

• Microsoft Learn, "Microsoft 365 Copilot data protection architecture": https://learn.microsoft.com/en-us/microsoft-365/copilot/microsoft-365-copilot-architecture-data-protection-auditing

• Microsoft Learn, "Restrict discovery of SharePoint sites and content": https://learn.microsoft.com/en-us/sharepoint/restricted-content-discovery

• Microsoft Learn, "Configure a secure and governed foundation for Microsoft Copilot": https://learn.microsoft.com/en-us/microsoft-365/copilot/configure-secure-governed-data-foundation-microsoft-365-copilot

• Dify, "Dify Enterprise"(기업판 사양): https://dify.ai/dify-enterprise

• AWS Architecture Blog, "Secure multi-tenant RAG with Amazon Bedrock and Verified Permissions": https://aws.amazon.com/blogs/architecture/secure-multi-tenant-rag-with-amazon-bedrock-and-verified-permissions/

• Dify Docs, "Web App Access Control": https://docs.dify.ai/en/use-dify/publish/webapp/web-app-access

• Dify Docs, "Manage Members": https://docs.dify.ai/en/self-host/use-dify/workspace/team-members-management

• Dify API Reference, "Create an Empty Knowledge Base": https://docs.dify.ai/en/api-reference/knowledge-bases/create-an-empty-knowledge-base

도입을 검토하고 계신다면

챗봇에 연결할 문서가 지금 누구에게 열려 있는지부터 함께 정리해 드립니다. 오픈네트웍시스템은 진단 단계에서 대상 문서와 개방 범위를 확정하고 한 부서 범위의 검증까지 설계합니다.