민감도 레이블이 적용되지 않을 때: Microsoft 365 및 Power BI 문제 해결과 해결 방법

By Mirko Peters · 2026-04-21

이 글에서는 Microsoft 365, Power BI 및 관련 앱에서 민감도 레이블이 예상대로 적용되지 않는 이유를 자세히 다룹니다. 레이블 옵션이 보이지 않거나, 자동 레이블 지정이 실패하거나, 설정 문제가 계속 해결되지 않는다면 제대로 찾아오셨습니다. 실무에서 자주 쓰이는 문제 해결 단계를 살펴보고, 라이선스 및 구성 요건을 짚어 보며, 실제 IT 팀과 Power BI 사용자가 가장 자주 마주치는 장애 요인을 정리합니다.

Automatically translated with AI from the original post. Read the English original

Cover: Build Audit-Ready Document Management with SharePoint and Purview

이 글에서는 Microsoft 365, Power BI 및 관련 앱에서 민감도 레이블이 예상대로 적용되지 않는 이유를 자세히 다룹니다. 레이블 옵션이 누락되거나, 자동 레이블 지정이 실패하거나, 구성 문제가 계속 해결되지 않는다면 제대로 찾아오셨습니다. 실무에서 쓸 수 있는 문제 해결 단계를 살펴보고, 라이선스 및 구성 요건을 짚어 보며, 실제 IT 팀과 Power BI 사용자가 자주 겪는 주요 장애 요인을 정리합니다.

복잡한 설명 없이 명확한 답을 제공하고, 확인해야 할 항목을 목록으로 정리하며, 전문가도 어려움을 겪는 고급 문제에 대한 안내를 드립니다. 일반 사용자를 지원하든 전사적으로 보안 정책을 도입하든, 민감한 데이터를 안전하게 보호하고 컴플라이언스 팀의 부담을 덜어 줄 인사이트와 해결책을 이곳에서 찾으실 수 있습니다. "모든 문제를 해결하는 단 하나의 설정"은 없다고 생각하셨다면, 이 자료가 다음에 어디를 살펴봐야 할지 정확히 보여 드릴 것입니다.

민감도 레이블의 이해와 일반적인 적용 실패

민감도 레이블은 오늘날 Microsoft 365 환경에서 데이터 보안의 핵심 축이 되었습니다. 사이버 위협이 더 교묘해지고 SharePoint, OneDrive, Power BI로 더 많은 데이터가 이동하면서, 민감도 레이블이 실제로 무엇을 하는지, 그리고 잘못 작동할 때 어떤 모습으로 나타나는지 이해하는 것이 무엇보다 중요해졌습니다.

Microsoft Purview를 사용하면 조직이 파일, 이메일, 심지어 Power BI 콘텐츠까지 분류하고 보호할 수 있으므로 데이터 민감도를 한눈에 파악할 수 있습니다. 그러나 레이블을 설정했다고 해서 항상 원하는 대로 작동하는 것은 아닙니다. 버튼이 사라지거나, 기본 레이블이 적용되지 않거나, 특정 파일이나 사용자가 아예 제외되는 등 예상치 못한 상황이 실제로 발생할 수 있습니다.

이 섹션에서는 기본 개념부터 살펴봅니다. 민감도 레이블이 무엇을 해야 하는지, 규정 준수와 개인 정보 보호에서 왜 중요한지, 그리고 겉으로 드러나지 않은 채 문제가 생기고 있다는 가장 흔한 징후는 무엇인지 설명합니다. "레이블이 표시되지 않는" 단순한 문제부터 상속 문제나 자동화 오류처럼 까다로운 문제까지, 특히 Power BI와 공동 작업 환경인 SharePoint 및 OneDrive에서 나타나는 주요 실패 패턴을 파악하실 수 있습니다.

"왜 작동하지 않을까?"라는 생각이 드셨다면 끝까지 읽어 주십시오. 이어지는 하위 섹션에서는 흔한 경고 신호, 기본 정의, 그리고 자동 레이블 지정이 실패하는 주요 원인(예상하지 못했던 원인 포함)을 하나씩 다룹니다. 이 글을 마치면 Microsoft 환경에서 민감도 레이블 문제를 찾아내고 해결하는 데 필요한 기초를 갖추게 되실 것입니다.

민감도 레이블이란 무엇이며, 어떻게 작동해야 할까?

민감도 레이블은 Microsoft 365의 파일, 이메일 및 다양한 클라우드 콘텐츠에 적용하여 정보를 분류하고 보호하며 사용 방식을 제어할 수 있는 태그입니다. 이러한 레이블은 Microsoft Purview에서 관리되며, 재무 데이터, 고객 정보, 지적 재산과 같은 민감한 데이터를 안전하게 보호하는 데 도움을 줍니다.

레이블이 적용되면 민감도 레이블은 콘텐츠를 자동으로 암호화하고, 파일에 접근하거나 편집할 수 있는 사용자를 제한하며, 데이터가 잘못 처리되는 경우 알림을 발생시킬 수도 있습니다. Outlook, Word, Teams, SharePoint, Power BI 중 어디에서 작업하든, 레이블은 문서나 메시지와 함께 이동하면서 눈에 보이는 신호이자 보이지 않는 보호막 역할을 합니다.

레이블은 사용자가 직접 설정하거나(수동 레이블 지정), 미리 정의된 규칙에 따라 자동으로 적용될 수 있습니다(자동 레이블 지정). 목표는 끊김 없는 작업 흐름입니다. 일단 레이블이 지정되면, 파일이 어디에 있든 보안 및 규정 준수 정책이 뒤에서 자동으로 작동하여 조직에 안심을 제공합니다.

레이블은 규정 준수 전략의 핵심이며, 규정 준수 감사와 법적 대응을 위한 주요 통제 수단을 제공합니다. 문서 관리의 혼란을 줄이고 위험을 관리하려면 Microsoft Purview를 기반으로 한 탄탄한 민감도 레이블 지정 프로그램을 구축하는 것이 기본입니다. SharePoint와 Teams 전반에서 파일을 보호하는 실질적인 방법은 Purview 방패로 문서 혼란을 멈추는 방법에 관한 이 토론을 들어 보시기 바랍니다.

민감도 레이블의 일반적인 문제와 주의해야 할 사항

레이블이 표시되지 않음: Word, Excel, Power BI 같은 앱에서 예상한 레이블 옵션이 나타나지 않는 현상입니다. 잘못 구성된 정책이나 사용자 액세스 문제 때문인 경우가 많습니다.
레이블 단추가 비활성화됨(회색): 사용자에게 민감도 레이블 단추는 보이지만 선택할 수 없습니다. 라이선스 누락, 오래된 클라이언트, 테넌트 정책 충돌 때문에 발생할 수 있습니다.
레이블이 상속되지 않음: 하위 콘텐츠(내보내기, 보고서, 공유 파일 등)가 상위 항목의 민감도 레이블을 가져오지 못합니다. 보통 상속이 의도대로 작동하지 않거나 해당 시나리오에서 지원되지 않기 때문입니다.
자동 레이블 지정 실패: 기본값으로 적용하거나 키워드를 기준으로 적용하도록 설정된 레이블이 새 콘텐츠에 적용되지 않습니다. 동기화 문제 또는 레이블 정책의 잘못된 구성이 원인일 수 있습니다.
레이블 적용 누락: 사용자가 보호된 콘텐츠로 작업하고 있지만 암호화나 액세스 보호가 트리거되지 않습니다. 이로 인해 데이터가 위험에 노출되며, 적용 설정에 문제가 있다는 신호입니다.

민감도 레이블이 자동으로 적용되지 않는 이유는 무엇입니까?

자동 레이블 지정 정책의 대상이 올바르게 지정되지 않았습니다. Microsoft Purview에서 정책을 설정했지만 정확한 사용자, 그룹 또는 위치를 포함하지 않았다면, 설정이 맞아 보이더라도 레이블이 적용되지 않습니다.
라이선스 제한으로 레이블이 차단됩니다. 올바른 Microsoft 365 또는 Purview 라이선스가 없는 사용자에게는 레이블이 표시되지 않으며 자동 레이블 지정도 적용되지 않습니다. 예를 들어 Power BI에서 효과적으로 레이블을 지정하려면 Power BI Pro 또는 Premium Per User가 필요한 경우가 많습니다.
정책 동기화 지연으로 문제가 발생합니다. 정책을 업데이트하거나 새 레이블을 추가하면, 모든 디바이스와 클라이언트에 변경 사항이 적용되기까지 몇 시간에서 며칠이 걸릴 수 있습니다. 동기화가 완료되기 전에는 자동 레이블 지정이 실행되지 않을 수 있습니다.
하위 상속이 지원되지 않거나 잘못 구성되어 있습니다. Power BI에서 "하위 상속 사용"을 선택했더라도 모든 내보내기, 보고서, 모델이 올바른 전파를 지원하지는 않습니다. 페이지 매긴 보고서나 특정 내보낸 파일 같은 일부 콘텐츠 유형은 상위 레이블을 자동으로 가져오지 않습니다.
디바이스 또는 로그인 컨텍스트가 레이블 적용을 제한합니다. 조건부 액세스나 Intune 정책은 관리되지 않거나 규정을 준수하지 않는 디바이스에서 레이블 사용을 제한하는 경우가 많습니다. 따라서 자동 레이블 지정이 잘 구성되어 있더라도 디바이스가 요구 사항을 충족하지 않으면 조용히 실패할 수 있습니다.
데스크톱 앱의 로컬 캐시 또는 메타데이터 손상. Office 또는 Power BI Desktop 클라이언트가 이전 레이블 목록을 계속 보관하는 경우가 간혹 있습니다. 이 때문에 캐시를 지우거나 앱을 다시 시작하기 전까지 새로운 또는 변경된 자동 레이블 규칙이 표시되거나 적용되지 않을 수 있습니다.
B2B 또는 게스트 사용자의 권한 문제. 게스트나 외부 사용자는 편집 권한이 있더라도 테넌트 간 경계, 정책, 라이선스 제약 때문에 레이블을 적용, 확인 또는 상속하지 못하는 경우가 많습니다.

확신이 서지 않는다면 Purview 감사에 관한 이 가이드와 같이 사용자 활동을 감사하면 자동화와 상속이 어디에서 중단되는지 파악하는 데 도움이 됩니다.

민감도 레이블의 라이선스 및 구성 필수 조건

Microsoft 365와 Power BI 전반에서 민감도 레이블이 원활하게 작동하려면 올바른 기반을 먼저 갖춰야 합니다. 라이선스, 테넌트 설정, 서비스 구성이 모두 올바르게 맞춰져 있어야 한다는 뜻입니다. 요구 사항 하나라도 빠지면 관리 센터에서 정책이 완벽해 보이더라도 사용자가 레이블을 보거나 적용하지 못할 수 있습니다.

이 섹션에서는 레이블 시스템의 "기반 구조"를 살펴봅니다. 즉, 어떤 제품과 역할에 프리미엄 라이선스가 필요한지, 레이블을 보거나 사용하려면 어떤 권한이 필요한지, 레이블 정책이 올바른 사용자와 서비스에 도달하도록 어떻게 범위가 지정되는지를 다룹니다. 또한 이런 단계를 건너뛰면 앱마다 누락된 기능, 비활성화된 단추, 일관되지 않은 레이블 환경이 생기는 이유도 확인할 수 있습니다.

레이블 문제를 해결하거나 대규모 배포를 준비하는 경우, 이 라이선스 및 설정 요구 사항을 검토하는 것이 반드시 필요합니다. 아래 하위 섹션에서는 각 요소를 자세히 설명하므로, 기술적인 문제를 깊이 살펴보기 전에 무엇을 확인해야 하는지 정확히 파악할 수 있습니다. 규정 준수 및 정책 시행에서 드러나지 않는 과제를 더 잘 이해하려면 Microsoft 365 compliance drift에 대한 이 분석을 확인해 보십시오.

민감도 레이블을 보고 적용하기 위한 라이선스 요구 사항

Microsoft Purview Information Protection(MIP) 라이선스: Microsoft 365에서 민감도 레이블을 지정하려면, 레이블을 보거나, 적용하거나, 자동으로 적용해야 하는 각 사용자에게 다음 중 하나가 필요합니다.

Microsoft 365 E5, A5 또는 G5
Information Protection and Governance 추가 기능이 포함된 Microsoft 365 E3
Azure Information Protection P1/P2 또는 이에 상응하는 번들
애플리케이션별 요구 사항:Power BI에서 PBIX 파일이나 작업 영역 내 콘텐츠에 민감도 레이블을 만들고, 적용하고, 상속하려면 Pro 또는 Premium Per User(PPU) 라이선스가 필요합니다.
Power BI에서 레이블이 지정된 콘텐츠만 사용하는 사용자(레이블을 만들거나 변경하지 않는 사용자)는 작업 영역 구성에 따라 더 낮은 등급의 라이선스로도 충분할 수 있습니다.
관리자 및 자동화를 위한 라이선스:Purview 포털에서 민감도 레이블을 만들고 관리하는 관리자에게도 적절한 라이선스가 할당되어 있어야 하며, PowerShell 또는 REST API 자동화를 위해서는 추가 권한이 필요할 수 있습니다.
흔한 누락 사항:라이선스 등급이 부족하거나 잘못 할당된 혼합 라이선스 환경의 사용자는 레이블이나 자동 레이블 지정에 대한 액세스 권한을 잃는 경우가 많습니다.
B2B 게스트 또는 서비스 주체는 대부분의 Microsoft 365 라이선스가 사용자 기반이어서 이러한 시나리오를 자동으로 포함하지 않으므로, 일반적으로 별도의 구성이 필요합니다. 이와 관련해서는 데이터 액세스, 소유권 및 거버넌스도 중요한 역할을 합니다.

민감도 레이블 만들기 및 범위 정의 방법

Microsoft Purview 포털 열기 - Purview 규정 준수 센터로 이동한 다음 데이터 수명 주기 관리에서 "정보 보호"를 선택합니다.
새 레이블을 만들고 속성 정의 - 레이블에 명확한 이름과 설명을 지정하고 적절한 범위(파일, 이메일, Power BI 콘텐츠 또는 전체)를 선택합니다. 암호화, 워터마크, 액세스 권한 등 적용할 보호 조치를 정의합니다.
레이블 정책 대상 설정 - 특정 사용자, 그룹 또는 모든 계정 소유자를 대상으로 지정하여 레이블을 보고 사용할 수 있는 대상을 결정합니다. 레이블이 필요한 위치에 표시되고 실수로 숨겨지지 않도록 할당 내용을 검토합니다.
기본 레이블 및 필수 레이블 구성 - 새 문서를 모두 특정 수준의 보호로 시작하려는 경우 기본 레이블 지정을 사용하도록 설정합니다. 필수 레이블 지정을 설정하면 사용자가 콘텐츠를 저장하거나 보내기 전에 레이블을 적용해야 합니다.
정책 게시 및 배포 모니터링 - 설정에 확신이 들면 정책을 게시하고 사용자에게 알립니다. 채택 현황과 레이블이 지정된 콘텐츠 통계를 정기적으로 검토하여 실수를 조기에 발견합니다. 이 내용은 감사 대비 문서 관리 가이드에서도 다룹니다.

Power BI에서 민감도 레이블 적용 문제 해결

Power BI는 민감도 레이블과 관련해 고유한 어려움이 있으며, 이는 숙련된 관리자도 자주 겪는 문제입니다. Microsoft Purview와 Microsoft 365 테넌트 전체에서 모든 설정을 올바르게 구성했더라도 Power BI에서는 예상치 못한 문제가 발생할 수 있습니다. 레이블 버튼이 이유 없이 비활성화되거나, 보호된 PBIX 파일이 열리거나 게시되지 않는 문제까지 다양하게 나타날 수 있습니다.

그 밖의 주요 문제로는 기본 또는 필수 레이블이 예상대로 적용되지 않는 경우, Power BI Desktop과 서비스 간 이동 시 레이블 상속이 깨지는 경우, 내보낸 보고서에서 주요 보호 기능이 제거되는 경우 등이 있습니다. 또한 B2B 및 게스트 사용자, 행 수준 보안, 콘텐츠 액세스와 관련된 고유한 시나리오도 있으며, 이러한 요소들이 거버넌스 계획을 복잡하게 만들 수 있습니다.

이 섹션에서는 여러분이 마주칠 가능성이 높은 Power BI 레이블 관련 문제를 모두 다룹니다. 각 하위 제목에서는 회색으로 비활성화된 컨트롤, 적용되지 않는 강제 설정, 보호된 파일이나 상승된 보안 설정으로 작업하지 못하는 문제 등의 실제 원인과 해결 방법을 살펴봅니다. 오류 메시지만 나열하는 것이 아니라, 규정 준수 및 보안 전략이 궤도에서 벗어나지 않도록 격차를 메우는 데 중점을 둡니다. 더 넓은 거버넌스 관점이 궁금하다면 Fabric 거버넌스의 환상에서 비효과적인 통제로 드러나는 문제들을 확인해 보십시오.

Power BI에서 민감도 레이블 버튼이 회색으로 표시되거나 보이지 않는 이유

Power BI Desktop 버전이 오래됨: 레이블 기능은 최신 Desktop 클라이언트가 필요합니다. 이전 버전을 사용 중이라면 버튼이 아예 표시되지 않을 수 있습니다.
라이선스 누락 또는 정책 범위 부족: Power BI Pro, Premium Per User 또는 적절한 Microsoft Purview 라이선스가 필요합니다. 라이선스가 없으면 레이블 옵션도 없습니다.
지원되지 않는 위치에 저장된 PBIX 파일: 일부 기능은 로컬 드라이브가 아닌 OneDrive 또는 SharePoint에 저장된 파일에서만 작동합니다.
테넌트 레이블 정책이 게시되지 않았거나 사용자를 대상으로 하지 않음: 관리자가 사용자(또는 작업 영역)를 정책에 포함하지 않았다면 레이블이 표시되지 않습니다.
인터넷 연결 또는 오프라인 모드: 레이블 기능은 클라우드 정책 동기화에 의존합니다. 오프라인 상태라면 레이블이 나타나지 않을 수 있습니다.

Power BI PBIX 파일에서 필수 및 기본 레이블 적용이 강제되지 않는 문제

테넌트 필수/기본 레이블이 구성되지 않음: Power BI에서 강제 적용을 위해서는 특정 테넌트 설정이 필요합니다. 이 옵션이 빠져 있으면 PBIX 파일에 레이블이 지정되지 않습니다.
수동 레이블 재정의 사용: 사용자가 레이블을 제거하거나 변경할 수 있다면, 겉으로는 "필수"로 설정되어 있어도 강제 적용이 우회됩니다.
작업 영역 제외: 강제 적용은 특정 작업 영역에만 범위를 지정할 수 있으며, 포함되지 않은 작업 영역은 그대로 빠져나갑니다.
Desktop과 Service 간 동기화 지연: 새로 게시하거나 만든 콘텐츠는 백엔드 처리 지연으로 인해 레이블이 즉시 반영되지 않을 수 있습니다.

보호된 PBIX 파일 및 콘텐츠 액세스 문제

암호화로 인한 파일 작업 차단: PBIX 파일이 암호화 기능이 포함된 레이블로 보호된 경우, 올바른 액세스 그룹에 할당되지 않은 사용자는 열기, 저장 또는 게시가 차단될 수 있습니다.
B2B 및 게스트 사용자 제한: 외부 협업자는 일반적으로 계정이 레이블의 액세스 정책에 명시적으로 포함된 경우에만 보호된 콘텐츠를 열거나 편집할 수 있습니다. 그렇지 않으면 파일이 로드되지 않거나 게시할 수 없습니다.
서비스 주체 및 자동화 장애: 서비스 주체를 사용하는 자동화 프로세스는 지원되지 않는 시나리오나 누락된 RBAC 권한 때문에 레이블을 적용하거나 제거하지 못하는 경우가 있습니다.
호환되지 않는 레거시 파일: 이전 Power BI Desktop 버전으로 만들었거나 저장한 PBIX 파일은 최신 레이블 보호와 호환되지 않을 수 있으며, 가져오기 또는 액세스 오류로 이어질 수 있습니다.
온프레미스 저장소의 저장 및 게시 오류: PBIX 파일을 로컬 저장소나 클라우드가 아닌 위치에 저장하면 민감도 레이블 보호가 파일과 함께 이동하지 않아, 다른 장치나 Power BI Service에서 액세스 실패가 발생합니다.
테넌트 구성 불일치: Microsoft Purview와 Power BI 테넌트 설정 간의 정책 차이는 레이블 동기화를 막아 "기능 누락" 오류나 보호된 파일 액세스 실패를 초래할 수 있습니다.
행 수준 보안 및 데이터 원본 핸드셰이크 실패: 행 수준 보안을 보호된 파일과 함께 사용하면 역할과 레이블 정책이 완벽하게 일치하지 않는 한 내보내기와 액세스가 실패합니다. 이에 대한 모범 사례는 Power BI에서 RLS 구현을 참고하십시오.

하위 항목으로의 상속 및 레이블 전파 문제

이상적인 상황이라면 데이터 세트나 보고서에 민감도 레이블을 적용하는 순간, 생성되는 모든 하위 파일과 내보낸 항목이 어디로 이동하든 동일한 보안 "배지"를 유지해야 합니다. 하지만 현실은 많은 사람들의 기대만큼 견고하지 않습니다. 특히 내보내기, 페이지 매기기된 보고서, 그리고 Power BI 또는 다른 앱에서 콘텐츠를 재가공하는 경우에는 하위 상속이 완벽하게 작동하지 않습니다.

여기서는 레이블 전파가 제대로 작동하지 않는 경우가 생기는 배경을 짚어 봅니다. 일부 문제는 지원되지 않는 파일 형식처럼 기술적인 원인에서 비롯되고, 다른 문제는 상속을 설정하지 않았거나 내보내기 옵션으로 상속이 무시되는 것처럼 순수하게 정책 측면에서 발생합니다. 레이블 전파는 복잡한 연쇄 구조로 작동하며, 상속이 끊어지면 민감한 콘텐츠가 기대한 보호를 받지 못한 채 남게 됩니다.

다음 하위 섹션에서는 "하위 콘텐츠"임에도 일부 내보낸 Excel 시트나 Power BI 보고서에서 민감도 레이블이 사라지는 이유를 자세히 설명합니다. 또한 페이지 매김 보고서와 모델 기반 레이블 상속이라는 까다로운 영역도 다루어, 무엇을 주의해야 하는지, 그리고 문제 해결에 힘을 쏟을 때 전체적인 개선 효과가 가장 큰 지점이 어디인지 알려 드리겠습니다.

하위 콘텐츠가 민감도 레이블을 상속하지 않는 이유

지원되지 않는 내보내기 형식: Power BI에서 내보내는 CSV나 PDF 같은 많은 하위 콘텐츠는 형식 자체가 레이블 메타데이터를 지원하지 않기 때문에 원본 민감도 레이블을 유지하지 못합니다.
모든 콘텐츠 형식에 대해 상속이 사용하도록 설정되지 않음: Purview 설정에서 "하위 상속"을 켜 두더라도 지원되는 파일 형식과 데이터 흐름만 이 기능에 참여합니다. 페이지 매김 보고서와 일부 하이브리드 보고서는 이 연결 고리를 자주 끊습니다.
수동 내보내기 재정의: 사용자가 "레이블 없이 다운로드"를 선택하거나 타사 도구를 사용하면 상속된 레이블이 적용되지 않습니다.
정책 잘못된 구성: 레이블 정책 범위나 테넌트 구성에 빈틈이 있으면 특정 파일이나 내보내기가 "빠져나가" 레이블 전파 규칙을 벗어날 수 있습니다.
클라이언트 측 앱 동기화 지연: 앱에서 레이블 데이터가 새로 고쳐지지 않았다면, 새로 만들거나 상속된 레이블이 다음 정책 전파 시점까지 표시되지 않을 수 있습니다.

페이지 매김 보고서와 모델 기반 레이블 상속 실패

페이지 매김 보고서에 적절한 상속 연결 지점이 없음: 페이지 매김 보고서가 레이블이 지정된 데이터 집합을 기반으로 하더라도, 특히 연결이 간접적이거나 데이터 원본이 레이블을 인식하지 못하는 경우에는 상속이 자동으로 이루어지지 않는 경우가 많습니다.
내보낸 페이지 매김 콘텐츠에서 레이블이 제거됨: 페이지 매김 보고서에서 내보낸 PDF, CSV, Excel 파일은 내보내기 프로세스의 제약 때문에 민감도 레이블이 아예 빠지는 경우가 많습니다.
데이터 원본과 모델의 격리: 보고서의 모델이 레이블이 지정된 원본과 지정되지 않은 원본을 함께 사용하면 상속 규칙이 모호해져 대체 레이블이 적용되거나 레이블이 전혀 적용되지 않을 수 있습니다.
사용자 지정 커넥터 문제: 사용자 지정 커넥터나 외부 API를 사용하는 보고서는 레이블 메타데이터를 전달하지 못해 자동 전파가 중단될 수 있습니다.
하이브리드 원본의 정책 공백: 온프레미스와 클라우드를 혼합한 하이브리드 환경이나 여러 테넌트를 사용하는 환경에서는 상속이 적용되거나 지원되지 않는 정책 불일치가 자주 발생합니다.
권장 해결 방법: Purview 정책과 Power BI 내보내기 설정을 정기적으로 검토하십시오. 가능한 경우 사용자에게 모델과 파생된 모든 보고서에 레이블을 수동으로 적용하도록 교육하고, 레이블이 없는 내보내기를 지속적으로 모니터링하십시오. 자동 상속에만 의존하는 것은 위험하다는 점을 기억하십시오. 거버넌스 관점을 더 깊이 알고 싶다면 Microsoft Fabric 거버넌스에 관한 이 자료를 참고하십시오.

Defender for Cloud Apps와 연동한 보안, 보호 및 통합

민감도 레이블은 파일에 스티커를 붙이는 것 이상의 역할을 합니다. 암호화와 기기 및 클라우드 서비스 전반의 자동 적용 같은 고급 보안 기능에서 실질적인 힘을 발휘합니다. 하지만 이러한 보호 설정이 강력해질수록, 모든 것이 원활하게 함께 작동하도록 책임진 IT 팀의 복잡성도 함께 커집니다.

이 섹션에서는 민감도 레이블과 연결된 보호 및 암호화 설정이 Microsoft 365, Power BI, 그리고 Microsoft Defender for Cloud Apps 같은 통합 도구 전반의 콘텐츠에 어떤 영향을 미치는지 살펴봅니다. 레이블이 파일에 암호화를 추가하면 누가 문서에 접근하고, 편집하고, 심지어 볼 수 있는지가 달라지므로, 설정이 정확히 맞물리지 않으면 새로운 문제 해결 과제가 생길 수 있습니다.

또한 Defender for Cloud Apps와 Purview에서 제공하는 도구를 활용해 레이블이 지정된 콘텐츠의 규정 준수를 모니터링하고, 액세스를 감사하며, 의심스러운 활동을 경고하는 방법도 살펴보겠습니다. 사전 예방적 위험 관리와 가시성 확보를 위한 도구 모음이라고 생각하시면 됩니다. 규정 준수 편차를 앞서 파악하고 보고 기능을 통합하는 방법에 대해 더 알고 싶다면 Defender for Cloud로 규정 준수를 모니터링하는 방법을 참고하십시오.

보호 설정과 암호화가 레이블 동작에 미치는 영향

암호화가 포함된 민감도 레이블을 할당하면, 콘텐츠가 어디로 이동하든 함께 적용되는 새로운 규칙 세트가 적용됩니다. 문서나 이메일의 경우, 암호화는 누가 파일을 열고, 인쇄하고, 전달할 수 있는지를 제어하며 조직 외부에서도 액세스 제한을 적용합니다.

사용자가 레이블 정책에 포함되어 있지 않으면 이러한 보호 기능이 편집이나 액세스를 차단할 수 있습니다. Power BI PBIX 파일의 경우, 허용된 그룹에 포함되지 않은 사용자는 암호화로 인해 콘텐츠를 게시하거나 저장하지 못할 수 있습니다. 외부 공유나 B2B 협업과 같은 공동 작업 상황에서는 보호 수준이 높은 레이블이 일반적으로 권한이 있는 사용자까지 차단할 수도 있습니다.

일부 레이블 설정은 앱 기능을 비활성화할 수도 있습니다. 예를 들어, 파일이 암호화된 경우 SharePoint나 Teams에서 미리 보기 기능을 사용할 수 없게 될 수 있습니다. 또한 Power BI에서는 행 수준 보안과 민감도 레이블이 함께 작동해야 하며, 그렇지 않으면 특히 모바일이나 포함(embedded) 시나리오에서 액세스가 제대로 작동하지 않을 수 있습니다.

보호 설정은 Conditional Access, Microsoft Defender, DLP 규칙과 같은 다른 보안 기능과도 긴밀하게 연동됩니다. 이러한 통합을 통해 민감한 것으로 표시된 파일이 경고를 발생시키고, 위험한 동작을 차단하며, 필요한 경우 콘텐츠를 완전히 잠글 수 있습니다. 사용자에게 불편을 주지 않으면서 이러한 요소들이 어떻게 결합되어 업무 환경을 보호하는지 자세히 알고 싶다면 이 M365 보안 심층 분석을 참고하십시오.

Defender for Cloud Apps로 민감도 레이블 모니터링하기

레이블 활동 감사: Defender for Cloud Apps와 Microsoft Purview는 레이블 관련 작업을 추적하여, 무단 제거나 레이블 할당 실패를 즉시 파악하는 데 도움을 줍니다.
정책 및 경고 구성: 민감한 정보가 정책 경계를 벗어나 액세스, 다운로드 또는 공유될 때마다 보안 팀에 알리도록 경고를 설정합니다.
대규모 콘텐츠 검색: 자동 검색을 사용하여 보호되지 않은 콘텐츠를 식별하거나, 전체 클라우드 환경에서 레이블 정책 준수 여부를 확인합니다.
지속적인 규정 준수 추적: 규정 준수 편차를 모니터링하고 자동 修復 옵션을 확인합니다. 자세한 내용은 이 Defender for Cloud 규정 준수 가이드에서 확인할 수 있습니다.

고급 시나리오 및 환경별 제한 사항

대부분의 조직은 간단한 Microsoft 365 환경에서 민감도 레이블을 사용합니다. 그러나 소버린 클라우드, 테넌트 간(B2B) 공유를 도입하거나 API 또는 서비스 계정을 통해 레이블 작업을 자동화하려고 하면 상황이 달라집니다. 이러한 고급 시나리오에는 기술적 또는 정책적 제약이 따르는 경우가 많으며, 민감도 레이블에 대한 계획이 어긋날 수 있습니다.

이 섹션에서는 특수한 환경에서 예상해야 할 사항을 다룹니다. 미국 정부(US Government) 또는 독일 클라우드 테넌트, 외부 B2B 사용자 협업, 서비스 주체를 사용하는 자동화 스크립트 등 레이블 지정이 전혀 작동하지 않거나 추가 설정이 많이 필요한 경우를 살펴봅니다. 레이블 기능이 갑자기 사라지거나 조용히 실패하는 이유를 찾느라 난감했던 경험이 있다면 도움이 될 것입니다.

각 하위 주제에서는 고유한 제약 사항을 짚고, 이를 우회하거나 최소화할 수 있는 전략을 제시합니다. 규제 산업에 속해 있거나 여러 테넌트를 운영하면서 감사 대응 상태를 유지해야 하는 경우에 특히 유용합니다. 관리되지 않는 게스트 계정과 관련된 규정 준수 위험이 궁금하다면 게스트 계정 수명 주기 관리에 대한 이 분석을 확인해 보십시오.

소버린 클라우드 및 B2B 협업에서의 민감도 레이블

소버린 클라우드 제한: 미국 정부(US Government) 및 독일 클라우드 버전의 Microsoft 365는 글로벌 테넌트에 비해 민감도 레이블 기능이 전부 제공되지 않거나 일부 기능만 지원하는 경우가 많습니다.
외부/B2B 사용자의 격차: 레이블 정책에 게스트를 명시적으로 포함하거나 테넌트 간 액세스를 사용하도록 설정하지 않으면, B2B 게스트는 편집 권한이 있어도 레이블을 보거나 적용하지 못하는 경우가 많습니다.
협업 중 정책 드리프트: 한 테넌트에서 설정한 정책이 테넌트 경계를 넘어 파일과 함께 이동하지 않을 수 있으며, 그 결과 레이블이 유실되거나 안전하지 않은 기본 설정이 적용될 수 있습니다.
해결 방법: 수동 레이블을 사용하고, 외부 협업자를 교육하며, 게스트 및 파트너 사용자를 더 폭넓게 포함하도록 레이블 정책의 대상 지정을 검토하십시오.

REST API와 서비스 주체를 활용한 민감도 레이블 자동화

API 엔드포인트 제한: 일부 REST API 엔드포인트는 아직 레이블 메타데이터의 읽기 또는 쓰기를 지원하지 않으며, 특히 Power BI나 SharePoint에서 그렇습니다.
권한 및 RBAC 문제: 서비스 주체가 레이블을 관리하려면 적절한 Azure 역할과 위임된 권한이 모두 필요하므로 설정이 까다로울 수 있습니다.
레이블 정리 자동화: 대량 레이블 할당(또는 제거)에는 PowerShell이나 Graph API를 사용하되, 항상 환경에서 특이 동작을 먼저 테스트하십시오. 서비스 계정은 사용자가 수동으로 수행하는 모든 작업을 재현할 수는 없습니다.
문서화되지 않은 오류 메시지: 자동화에서는 원인을 알 수 없는 실패가 흔하므로 모든 내용을 기록하고, API 문서와 최근 업데이트를 자주 확인하십시오. M365 거버넌스를 위한 자동화 모범 사례는 변할 수 있으며, 이는 이 PowerShell 자동화 인사이트(해당하는 경우)에서 다룬 내용과 같습니다.

민감도 레이블 적용에 영향을 주는 사용자 및 디바이스 컨텍스트 제한

민감도 레이블이 실패하는 이유가 라이선스나 관리자 설정 오류 때문이 아니라, 사용자가 작업하는 컨텍스트 때문인 경우가 있습니다. 디바이스 규정 준수, 조건부 액세스, 로그인 상태 같은 요소는 아무런 경고나 눈에 보이는 오류 메시지 없이 레이블 기능을 차단할 수 있습니다.

이 섹션에서는 세부 설정에서나 찾을 수 있는 문제를 다룹니다. 예를 들어 관리되지 않는 노트북에서 로그인한 사용자나, 권한을 어떻게 구성해도 레이블 옵션이 보이지 않는 게스트 사용자의 경우입니다. 이러한 차단은 대개 Intune(디바이스 규정 준수)과 Azure 조건부 액세스 정책으로 제어되며, 이 정책은 게스트, 규정 미준수 디바이스 또는 외부 공유 시나리오에 대해 더 엄격한 통제를 적용할 수 있습니다.

겉보기에 모든 구성이 정상인데도 어떤 정책이 레이블을 조용히 "끄는지" 살펴보고, 상황을 진단하는 방법을 정리하겠습니다. 이는 문서에만 해당하는 이야기가 아니라 Power BI, Teams, Outlook 등 레이블이 표시되어야 하는데 나타나지 않는 모든 곳에 해당합니다. 조건부 액세스 정책에 신뢰를 반영하는 방법에 대한 세부 사항을 다시 확인하려면 신뢰 중심 조건부 액세스 정책 가이드를 참고하십시오.

조건부 액세스, 디바이스 규정 준수, 레이블 사용 가능 여부

디바이스 규정 준수 적용: 조건부 액세스와 Intune은 Office 또는 Power BI 앱에서 레이블 작업을 허용하기 전에 디바이스가 규정을 준수하도록(관리됨, 암호화됨 또는 등록됨) 요구할 수 있습니다.
관리되지 않는 디바이스 차단: 사용자가 Intune/Entra ID 제어 범위 밖의 디바이스에서 로그인하면, 명시적인 오류 메시지 없이 민감도 레이블 적용 옵션이 사라지거나 비활성화(회색 표시)될 수 있습니다.
사용자 지정 인증 컨텍스트: MFA나 위치 기반 규칙을 요구하는 CA 정책은 레이블 지정을 특정 시나리오로만 제한할 수 있으며, 세션이 완전히 신뢰되지 않으면 레이블 지정이 실패합니다.
진단: 관리자는 조건부 액세스 정책 할당과 로그인 로그를 검토해야 합니다. 특정 사용자에게만 레이블 작업이 실패한다면, 원인은 디바이스 규정 준수 격차나 제한적인 정책일 가능성이 높습니다. 에스컬레이션이 필요한 상황에서는 ID 보안 정책 드리프트를 위한 제어 루프가 필수적일 수 있으며, 모범 사례는 이 Entra ID 보안 에피소드에서 확인할 수 있습니다.

민감도 레이블과 게스트 및 외부 사용자 제한

기본적으로 레이블 지원이 없음: B2B 및 외부 협업자는 레이블 정책에 해당 ID나 외부 도메인이 명시적으로 포함되지 않는 한 레이블을 적용하거나 때로는 레이블 자체를 볼 수도 없습니다.
정책 및 권한 격차: 편집 권한이 있더라도 테넌트의 기본 설정이 제한적이거나 라이선스가 할당되지 않으면 게스트는 레이블 지원을 받지 못할 수 있습니다.
유휴 게스트 계정으로 인한 보안 위험: 오래되었거나 관리되지 않는 게스트 계정은 정책을 우회하거나 레이블 적용을 완전히 잃을 수 있습니다. 이 게스트 계정 경고에서 설명하는 대로 게스트 수명 주기를 점검하고 제한하십시오.
구성 권장 사항: 레이블 대상 지정을 정기적으로 검토하고, 기간이 제한된 게스트 액세스를 설정하며, 필요한 경우 게스트가 포함되도록 하십시오. 다만 규정 준수를 위해 액세스 검토는 엄격하게 유지하십시오.

애플리케이션 캐싱 및 정책 동기화 지연으로 인한 레이블 적용 실패

대부분의 가이드가 간과하는 부분이 있습니다. 관리자 설정이 문서상으로는 올바르게 보여도, 레이블 캐싱이나 정책 동기화 지연 같은 애플리케이션 측 문제 때문에 민감도 레이블이 나타나지 않거나 업데이트되지 않을 수 있습니다. 이런 문제는 정책 변경 후 로컬 메타데이터나 캐시 파일이 오래된 상태로 남는 Office 데스크톱 앱과 Power BI Desktop에서 특히 흔합니다.

정책 새로고침이 앱에 반영되지 않았다면 새 민감도 레이블이 나타나지 않거나, 이전 레이블이 그대로 남아 있거나, 이전 자동 레이블 지정 규칙이 계속 적용되는 현상을 보게 될 수 있습니다. 이 경우 사용자는 "나만 문제가 있다"고 생각하기 쉽지만, 실제로는 광범위한 정책 동기화나 캐시 문제일 수 있습니다.

이 섹션에서는 레이블 캐시 지우기와 기기 및 플랫폼 간 정책 전파 시간을 이해하는 방법처럼 내부적인 문제를 해결하는 방법을 다룹니다. 관리자가 정책을 변경한 후 본인이나 사용자가 레이블 문제에 부딪힌다면, 지원팀에 문의하기 전에 가장 먼저 확인해야 할 내용입니다.

Office 데스크톱 앱에서 민감도 레이블 캐시 지우기

Word, Excel, Outlook을 포함한 모든 Office 앱을 닫으십시오. 작업 관리자를 열어 실행 중인 Office 프로세스가 남아 있지 않은지 확인하십시오.
레이블 캐시 위치로 이동: %localappdata%\Microsoft\MSIP 및/또는 %localappdata%\Microsoft\Office\16.0\LabeledDocuments(Microsoft 365 apps 빌드의 경우)로 이동하십시오.
캐시 폴더 삭제 또는 이름 변경: 필요에 따라 "Policy" 또는 "Labels" 하위 폴더를 포함한 캐시 폴더를 삭제하거나 이름을 변경하십시오. 이렇게 하면 Office 앱의 오래되었거나 손상된 레이블 메타데이터가 지워집니다.
Office 앱 다시 시작: 앱이 클라우드에서 레이블 정책을 자동으로 다시 가져오므로 새로 추가되거나 업데이트된 민감도 레이블이 즉시 표시됩니다.
사용 시기: 이 방법은 레이블 정책을 편집한 후, 레이블 카탈로그를 업데이트한 후, 또는 레이블 선택기에 새 레이블이 표시되지 않을 때 꼭 필요합니다. 더 深い 기술적 점검에 들어가기 전에 빠르게 시도해 볼 수 있는 방법입니다.

클라이언트별 정책 전파 지연 이해하기

Office 데스크톱 앱: 특히 Purview 포털에서 대규모 변경을 한 후에는 새 정책이나 레이블이 전파되는 데 최대 24시간이 걸릴 수 있습니다.
웹 앱(Office 온라인, Power BI 서비스): 정책 업데이트는 더 빠르게 적용되며, 보통 1~2시간 안에 반영됩니다. 다만 브라우저에 남아 있는 캐시 때문에 표시가 지연될 수 있습니다.
모바일 및 하이브리드 클라이언트: 모바일 앱은 정책 데이터를 더 오래 캐시할 수 있습니다. 로그아웃 후 다시 로그인하면 새로고침을 앞당길 수 있습니다.
확인 방법: Office 데스크톱, 웹, Power BI의 레이블 목록을 비교하여 동기화 지연을 찾아내십시오. 지연이 계속되면 IT 관리자에게 문의하여 테넌트 동기화 상태를 검토하도록 하십시오.

민감도 레이블 적용 시도에 대한 무음 실패 및 로깅

가장 까다로운 민감도 레이블 문제는 오히려 눈에 보이지 않는 문제일 때가 많습니다. 오류 메시지는 없지만 레이블이 적용되지 않거나 유지되지 않습니다. 이러한 "무음 실패"는 특히 규제 산업에 종사하거나 외부 감사를 통과해야 하는 경우 사용자와 관리자 모두를 힘들게 할 수 있습니다.

이 섹션에서는 레이블 적용이 명백히 실패하지는 않지만 작동하지 않을 때 어디를 살펴봐야 하는지 설명합니다. Microsoft 365 감사 로그, 사용자 기기의 로컬 로그(MIP 클라이언트 또는 Office 앱), 그리고 오류 추적 정보를 분석하는 내용을 다룹니다. 고급 문제 해결 영역이지만, 다른 모든 설정이 올바르게 보일 때 누락된 단서를 찾을 수 있는 곳입니다.

Microsoft Purview의 통합 감사 로그에 접근하고 활용하여 실패하거나 불완전하게 적용된 레이블을 찾아내는 방법을 정리합니다. 또한 UI에는 "성공"으로 표시되지만 실제 결과가 올바르지 않은 경우 MIP 및 Office 앱 로그를 해석하는 요령도 함께 살펴봅니다. 백그라운드에서 무슨 일이 일어나는지 제대로 이해하고 싶다면 Purview 사용자 활동 감사에서 감사 및 포렌식 추적의 세계를 확인해 보시기 바랍니다.

감사 로그를 활용해 민감도 레이블 실패 추적하기

Microsoft 365 감사 로그 접근: Purview 규정 준수 포털로 이동한 후 감사 섹션으로 들어갑니다. 감사 로그 권한이 필요합니다.
민감도 레이블 작업 필터링: "민감도 레이블 적용", "레이블 변경", "레이블 제거"와 같은 이벤트를 검색합니다. "상태"가 실패 또는 불완전으로 표시된 항목을 주의 깊게 확인하십시오.
사용자 및 파일 기록 검토: 실패한 이벤트를 자세히 살펴보고 사용자 계정, 디바이스, 영향을 받은 파일, 그리고 오류 내용(있는 경우)을 기록합니다.
근본 원인 분리: 실패가 항상 특정 사용자, 특정 파일 형식에서 발생하는지, 아니면 정책 업데이트 이후에 발생하는지 패턴을 찾아보십시오. 이를 통해 정책, 라이선스 또는 클라이언트 측 문제를 구분할 수 있습니다.
모범 사례: 규정 준수가 중요한 경우 더 풍부한 신호와 더 긴 보존 기간을 제공하는 Purview Audit Premium으로 업그레이드하십시오. 포렌식 추적에 대한 자세한 내용은 이 단계별 감사 튜토리얼을 참고하십시오.

무음 오류를 찾기 위해 MIP 클라이언트 및 Office 앱 로그 분석하기

상세 로깅 활성화: MIP 및 Office 앱에서 레지스트리 설정이나 명령줄 스위치를 통해 자세한 정보(verbose) 또는 디버그 로깅 모드를 켭니다.
로컬 로그 위치 확인: MIP 클라이언트의 주요 파일은 %localappdata%\Microsoft\MSIP\Logs에 있으며, Office의 로그는 \Logs 하위 폴더에 있습니다.
레이블 작업 후 오류 확인: 사용자가 작업을 수행한 후 0x80070005(액세스 거부)와 같은 오류 코드나 "레이블 적용 실패"를 검색합니다.
지원 팀과 연계: 사용자 측 문제 해결이 막히면 로그와 타임스탬프를 Microsoft 지원팀과 공유하여 고급 진단을 받으십시오.

최종 점검, 피드백 및 권장 리소스

Microsoft 365 및 Power BI의 민감도 레이블 문제에 대한 주요 해결 단계를 모두 살펴보셨습니다. 문제 해결을 포기하거나 지원 티켓을 열기 전에, 체계적인 체크리스트를 사용하여 구성 세부 정보와 정책 설정을 검토하는 것이 좋습니다. 종종 마지막으로 빠뜨린 설정이나 잊어버린 권한이 문제를 해결하며, 깊은 분석이 필요하지 않은 경우가 많습니다.

이 섹션은 에스컬레이션 전에 반드시 확인해야 할 핵심 항목을 요약하며 마무리합니다. 정책 대상 지정, 레이블 게시, 라이선스 할당, 적용 설정을 점검합니다. 또한 지속적인 학습을 위한 피드백 채널, 지원 경로 및 공식 모범 사례 리소스 링크도 제공합니다.

이 부분은 문제 해결을 위한 점검이자 추가 도움으로 이어지는 연결고리 역할을 합니다. 더 깊이 파고들어야 하는 어려운 사례나 새로운 문제를 보고해야 할 때 참고할 수 있도록 신뢰할 수 있는 커뮤니티 포럼, 추천 문서 및 공식 Microsoft 문서 링크를 포함하고 있습니다. 감사 준비가 된 문서 관리에 대한 더 많은 팁은 Purview 및 SharePoint 문서 혼란 해결 방안을 참고하십시오.

민감도 레이블 설정 및 라이선스 요구 사항 검토 체크리스트

테넌트 설정 검증: 민감도 레이블 기능이 활성화되어 있고 Microsoft Purview를 통해 중앙에서 관리되고 있는지 확인하십시오. 테넌트 범위와 기능 토글을 다시 한번 점검하십시오.
레이블 정책 할당 검토: 레이블 정책에 의도한 모든 사용자, 그룹 또는 게스트 계정이 포함되어 있는지 확인하십시오. 정책 범위 지정 문제는 레이블이 표시되어야 할 곳에 나타나지 않는 가장 큰 원인 중 하나입니다.
라이선스 할당 확인: 모든 사용자와 관리자가 Purview Information Protection, Power BI Pro/Premium 또는 레이블을 사용할 수 있는 관련 구독에 대해 라이선스를 부여받았는지 확인하십시오.
정책 전파 및 동기화 확인: 최근의 레이블 또는 정책 변경 사항이 모든 클라이언트에 전파되었는지, 그리고 주요 앱의 민감도 선택기에 표시되는지 살펴보십시오.
필수 및 기본 레이블 적용: 콘텐츠가 레이블 없이 생성되지 않도록 특히 Power BI와 SharePoint에서 기본 레이블 및 필수 적용 설정이 활성화되어 있는지 확인합니다.
게스트 및 B2B 적용 범위: 외부 협업자가 레이블 정책에 포함되는지, 그리고 어떤 방식으로 포함되는지 검토합니다. 사용하지 않는 게스트 계정은 제거합니다. 이와 관련한 내용은 the hidden danger of M365 guest accounts에서 더 자세히 확인할 수 있습니다.
감사 및 활동 로그 점검: Microsoft 365 감사 로그에서 실패했거나 불완전한 레이블 할당을 확인합니다. 이 단계는 규제 대상 기관과 선제적인 IT 모니터링에 필수적입니다.
필요한 경우 레이블 캐시 지우기: 정책을 변경한 후에는 "clear cache" 방법을 사용하여 사용자가 이전 레이블이 남아 발생하는 문제를 겪지 않도록 합니다.
모든 시나리오 테스트: 관리되는 기기와 관리되지 않는 기기, 게스트 사용자에서 레이블 적용을 검증하고, 필요한 경우 웹, 데스크톱, 모바일 플랫폼 전반에서도 확인합니다.

피드백 제출 및 추천 문서 찾기

Microsoft 피드백 채널: Microsoft 365 관리 센터의 피드백 도구를 사용하거나 커뮤니티 포럼을 방문하여 새로운 문제를 보고하고 기능 로드맵에 의견을 제시합니다.
지원 에스컬레이션: 해결되지 않았거나 심각한 민감도 레이블 문제는 Microsoft 365 관리 포털을 통해 지원 티켓을 엽니다. 로그와 상세한 재현 절차를 공유할 수 있도록 준비합니다.
모범 사례 자료 및 문서: 심층 분석과 전문가 주도 토론을 찾아보세요. 예를 들어 감사에 초점을 맞춘 Purview를 활용한 사용자 활동 감사 가이드나 체크리스트 중심으로 Purview 방어 체계를 구축하는 방법을 참고할 수 있습니다.
커뮤니티 학습: 추천된 Microsoft Learn 문서와 신뢰할 수 있는 포럼을 북마크해 두고, 변화하는 레이블 전략과 문제 해결 팁을 꾸준히 확인합니다.