Microsoft 365 Copilot 커넥터를 붙이기 전, 사내 문서 권한표부터 검증해야 합니다

Copilot 검색 연결의 첫 단계는 “무엇을 연결할까”가 아니라 “누가 무엇을 보면 안 되는가”를 표로 검증하는 것입니다.

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

Microsoft 365 Copilot을 사내 문서 검색에 활용하려는 조직이 늘어나면 자연스럽게 이런 질문이 나옵니다.

“우리 회사의 업무 시스템이나 문서 저장소를 Copilot에 연결할 수 있을까?”

맞는 질문입니다. Microsoft 공식 문서에 따르면 Copilot connectors는 SaaS 및 온프레미스 데이터 소스를 Microsoft 365 Copilot과 Microsoft Search 경험에 연결할 수 있도록 돕는 기능입니다. Microsoft Graph connectors도 외부 콘텐츠를 Microsoft 365 검색 경험에 연결하는 방식으로 설명됩니다.

하지만 실제 도입에서는 먼저 물어야 할 질문이 따로 있습니다.

“연결했을 때, 사용자가 자신에게 허용된 문서만 보게 되는가?”

Microsoft 공식 문서는 Copilot connectors가 원본 시스템의 권한, 즉 source permissions를 존중해 사용자가 권한 있는 콘텐츠에만 접근하도록 한다고 설명합니다.

출처: Microsoft 365 Copilot connectors overview, Microsoft Search connectors overview

문제는 “권한을 존중한다”는 설명만으로는 우리 조직의 실제 권한 구조가 안전하게 반영되는지 알 수 없다는 점입니다. 특히 부서별 문서, 프로젝트별 산출물, 계약 문서, 인사·재무 관련 파일처럼 접근 범위가 민감한 자료라면 커넥터 설정 전에 권한 검증표부터 만들어야 합니다.

이번 글은 RAG 일반론이 아니라 Microsoft 365 Copilot connectors를 붙이기 전 확인해야 할 권한 검증 산출물에 집중합니다.

커넥터 연결보다 먼저 봐야 할 것은 “검색 노출 범위”입니다

사내 문서 검색 프로젝트는 보통 이렇게 시작됩니다.

• 어디에 문서가 있는가?
• 어떤 시스템을 연결할 수 있는가?
• Copilot에서 검색되게 만들 수 있는가?
• 사용자가 자연어로 질문하면 답변이 나오는가?

하지만 Copilot connectors처럼 기존 업무 시스템과 Microsoft 365 검색 경험을 연결하는 방식에서는 질문의 순서를 바꿔야 합니다.

먼저 확인할 것은 “검색이 되는가”가 아니라 “검색되면 안 되는 문서가 노출되지 않는가”입니다.

공식 문서상 Copilot connectors는 SaaS 및 온프레미스 데이터 소스를 연결하고, 원본 권한을 존중한다고 설명됩니다. 이 방향은 중요합니다. 다만 조직 내부 권한은 문서 저장소마다 다르게 설계되어 있을 수 있습니다.

예를 들어 같은 “프로젝트 문서”라도 실제 권한은 다음처럼 나뉠 수 있습니다.

• 전사 공개 문서
• 특정 부서만 접근 가능한 문서
• 특정 프로젝트 멤버만 접근 가능한 문서
• 관리자 또는 결재권자만 볼 수 있는 문서
• 계약·인사·재무처럼 일부 담당자만 접근 가능한 문서

이런 구조를 표로 정리하지 않은 상태에서 커넥터를 먼저 붙이면 테스트 결과를 해석하기가 어렵습니다.

검색 결과가 잘 나오는 것이 성공인지,

나오면 안 되는 문서가 나온 것인지,

나와야 할 문서가 빠진 것인지 판단할 기준이 없기 때문입니다.

따라서 Copilot connectors 도입 전에는 최소한 다음 질문에 답해야 합니다.

• 이 데이터 소스의 원본 권한 체계는 무엇인가?
• 사용자·그룹·역할 단위 권한은 어떻게 나뉘는가?
• Copilot 검색 결과에서 반드시 숨겨져야 하는 문서는 무엇인가?
• 테스트 계정별로 기대되는 검색 결과는 무엇인가?
• 권한 변경 후 검색 결과 반영 여부는 어떻게 검증할 것인가?

데이터 소스별 권한 검증 매트릭스를 먼저 만드세요

Copilot connectors 도입의 실무 산출물은 “연결 완료”가 아니라 “권한 검증 매트릭스”여야 합니다.

아래와 같은 표를 먼저 만들면 커넥터 설정 이후 테스트 기준이 훨씬 분명해집니다.

데이터 소스	문서 유형	원본 권한 기준	테스트 계정	보여야 하는 문서	보이면 안 되는 문서	검증 상태
확인 필요	전사 공지	전사 접근	일반 직원 계정	전사 공지 문서	제한 문서	확인 필요
확인 필요	프로젝트 문서	프로젝트 멤버 접근	프로젝트 멤버 계정	해당 프로젝트 문서	다른 프로젝트 문서	확인 필요
확인 필요	계약 문서	담당자 제한 접근	비담당자 계정	없음 또는 제한된 결과	계약 원문	확인 필요
확인 필요	부서 문서	부서 그룹 접근	타 부서 계정	없음 또는 공개 문서	부서 내부 문서	확인 필요

여기서 중요한 것은 데이터 소스 이름을 실제 조직 기준으로 채우는 것입니다.

어떤 SaaS나 온프레미스 시스템을 연결할 수 있는지는 조직의 Microsoft 365 환경, 커넥터 지원 범위, 라이선스, 리전, 관리자 설정에 따라 달라질 수 있습니다. 이 부분은 실제 도입 전 관리자 콘솔과 계약 조건 확인이 필요합니다.

다만 표의 목적은 분명합니다.

Copilot이 답을 잘하는지 보기 전에, Copilot이 “보면 안 되는 것을 보지 않는지” 확인하는 것입니다.

이 표는 단순한 체크리스트가 아니라 운영 기준이 됩니다. 나중에 데이터 소스를 추가하거나 권한 정책이 바뀌었을 때도 같은 방식으로 회귀 테스트를 할 수 있습니다.

테스트 계정 없이 권한 검증은 끝나지 않습니다

권한 검증에서 자주 생기는 실수는 관리자 계정이나 프로젝트 담당자 계정으로만 테스트하는 것입니다.

관리자나 담당자는 대부분 많은 문서를 볼 수 있습니다. 그래서 검색이 잘 되는 것처럼 보입니다. 하지만 실제 위험은 권한이 낮은 사용자 계정에서 발생합니다.

따라서 최소한 다음 유형의 테스트 계정이 필요합니다.

• 일반 직원 계정
• 특정 부서 소속 계정
• 특정 프로젝트 멤버 계정
• 프로젝트 비멤버 계정
• 민감 문서 접근 권한이 없는 계정
• 관리자 또는 담당자 계정

각 계정으로 같은 질문을 던져야 합니다.

예를 들어 다음처럼 질문 세트를 구성할 수 있습니다.

질문	일반 직원	프로젝트 멤버	프로젝트 비멤버	관리자
특정 프로젝트 산출물 검색	확인 필요	보여야 함	보이면 안 됨	보여야 함
계약 관련 문서 검색	확인 필요	확인 필요	보이면 안 됨	확인 필요
전사 공지 검색	보여야 함	보여야 함	보여야 함	보여야 함

여기서 “확인 필요”는 실제 조직의 권한 정책에 따라 달라지는 항목입니다.

블로그나 공식 문서만 보고 단정할 수 없습니다.

중요한 것은 테스트 질문을 미리 정해두는 것입니다. 그래야 Copilot 검색 결과가 기대와 다를 때 원인을 추적할 수 있습니다.

가능한 원인은 여러 가지입니다.

• 원본 시스템의 권한 설정이 잘못되었을 수 있음
• 커넥터 설정 과정에서 권한 매핑이 기대와 다를 수 있음
• 데이터 소스별 접근 정책이 문서화되어 있지 않을 수 있음
• 사용자의 그룹·역할 정보가 실제와 다를 수 있음
• 라이선스, 테넌트, 리전, 기능 상태에 따라 동작 범위 확인이 필요할 수 있음

이 중 어떤 원인인지는 실제 환경에서 검증해야 합니다.

따라서 “커넥터가 source permissions를 존중한다”는 공식 설명은 출발점이지, 도입 완료의 증거는 아닙니다.

바로 적용하는 체크리스트

Microsoft 365 Copilot connectors를 사내 문서 검색에 붙이기 전, 다음 순서로 점검해보세요.

1. 연결 후보 데이터 소스를 정리한다

• Copilot 검색에 연결하려는 데이터 소스를 나열한다.
• SaaS인지 온프레미스인지 구분한다.
• 실제 연결 가능 여부는 관리자 콘솔, 계약 조건, 리전, 기능 상태를 확인한다.
• 공식 문서 기준으로 Copilot connectors와 Microsoft Graph connectors의 역할을 확인한다.
• Microsoft 365 Copilot connectors overview
• Microsoft Search connectors overview

2. 문서 유형별 권한 기준을 표로 만든다

• 전사 공개 문서
• 부서 제한 문서
• 프로젝트 제한 문서
• 계약·인사·재무 등 민감 문서
• 관리자 또는 특정 담당자만 볼 수 있는 문서

각 문서 유형마다 “누가 볼 수 있고, 누가 보면 안 되는지”를 명시합니다.

3. 테스트 계정을 준비한다

• 일반 사용자
• 부서 사용자
• 프로젝트 멤버
• 프로젝트 비멤버
• 민감 문서 비권한자
• 관리자 또는 담당자

테스트 계정이 없으면 권한 검증은 추측에 가까워집니다.

4. 검색 질문 세트를 만든다

• 보여야 하는 문서를 찾는 질문
• 보이면 안 되는 문서를 찾는 질문
• 경계 조건을 확인하는 질문
• 권한 변경 후 다시 확인할 질문

질문은 실제 사용자가 물어볼 법한 표현으로 작성합니다.

5. 결과를 “정답 여부”가 아니라 “노출 여부”로 기록한다

검색 품질보다 먼저 볼 것은 권한입니다.

• 기대한 문서가 보였는가?
• 보이면 안 되는 문서가 보였는가?
• 결과에 포함된 출처가 적절한가?
• 계정별 결과가 다르게 나오는가?
• 권한 변경 후 결과가 예상대로 바뀌는가?

6. 확인 필요 항목을 분리한다

다음 항목은 조직마다 달라질 수 있으므로 단정하지 말고 별도로 확인해야 합니다.

• 세부 라이선스
• 테넌트별 사용 가능 여부
• 클라우드 리전 지원
• 미리보기 또는 GA 상태
• 연결 가능한 구체 데이터 소스
• 관리자 설정 조건
• 조직 내부 권한 정책

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

Microsoft 365 Copilot connectors는 사내 문서와 업무 시스템을 Copilot 검색 경험에 연결하는 출발점이 될 수 있습니다. 공식 문서에서도 SaaS 및 온프레미스 데이터 소스 연결, Microsoft 365 Copilot 및 검색 경험과의 연동, source permissions 존중을 설명하고 있습니다.

하지만 실무 도입의 핵심은 “연결할 수 있는가”에서 끝나지 않습니다.

질문은 이것입니다.

“우리 조직의 권한 구조가 Copilot 검색 결과에서도 그대로 지켜진다고 검증했는가?”

커넥터 설정 화면을 열기 전에 데이터 소스별 권한 검증 매트릭스부터 만드세요.

그 표가 있어야 검색 품질도, 보안 검증도, 운영 기준도 같은 기준으로 이야기할 수 있습니다.

생각해볼 질문:

우리 조직에서 Copilot 검색에 연결되면 가장 먼저 문제가 될 수 있는 “보이면 안 되는 문서”는 무엇인가요?