민감도 버튼 비활성화부터 IRM 오류까지, Purview 첫 적용 사례
파일 암호 대신 Purview 문서 보호를 처음 적용하면서 Excel의 민감도 버튼이 비활성화되고 IRM 오류가 발생한 과정을 바탕으로, 설정과 확인 순서를 쉽게 설명합니다.
앞선 고객 사례에서는 중요한 Excel 파일에 열기 암호를 설정했더니 공동편집이 되지 않는 문제를 살펴봤습니다. 암호만 제거하면 협업은 가능해지지만, 파일이 외부로 전달된 뒤의 보호까지 사라질 수 있었습니다.
그래서 고객은 공유 암호 대신 사용자 계정과 권한으로 문서를 보호하는 Microsoft Purview 민감도 레이블을 적용하기로 했습니다.
이번 글은 그다음 단계에서 실제로 진행한 Purview 첫 적용 사례입니다. 처음부터 레이블과 암호화가 바로 작동한 것은 아니었습니다.
“Excel 리본에 민감도 영역은 보이는데 버튼이 회색으로 비활성화되어 있습니다. 레이블을 만들고 게시한 뒤에는 웹용 Excel에서 권한을 지정할 수 있었지만, 데스크톱 Excel에서는 ‘IRM을 사용하도록 구성한 Office 사용자로 로그인하지 않았습니다’라는 오류가 나옵니다. 무엇이 빠진 걸까요?”
먼저 결론부터 말씀드리면, Excel에 민감도 영역이 보이는 것, 사용할 레이블이 게시되는 것, 레이블의 문서 암호화가 작동하는 것은 서로 다른 단계입니다.
이번 사례에서는 레이블 생성과 게시 정책을 먼저 준비한 뒤, 문서를 실제로 보호하는 Azure Rights Management 서비스와 데스크톱 Office의 업무 계정 연결 상태를 차례로 확인했습니다.
먼저 세 가지 용어만 알아두면 쉽습니다
이 문제에는 비슷해 보이는 이름이 여러 개 등장합니다. 역할은 다음처럼 구분할 수 있습니다.
| 용어 | 쉽게 말하면 | 하는 일 |
|---|---|---|
| 민감도 레이블 | 문서에 붙이는 보안 등급표 | ‘기밀’, ‘내부용’처럼 문서의 취급 규칙을 표시합니다. |
| IRM(정보 권한 관리) | 문서를 연 뒤 할 수 있는 일을 제한하는 기능 | 누가 열고 편집·복사·인쇄할 수 있는지 통제합니다. |
| Azure Rights Management | 문서 보호 규칙을 실제로 집행하는 클라우드 서비스 | 사용자의 신원을 확인하고 허용된 권한에 따라 문서를 암호화합니다. |
즉, 레이블은 사용자에게 보이는 보안 등급표이고, Azure Rights Management는 그 등급표에 설정된 암호화와 사용 권한을 실제로 적용하는 서비스라고 이해하면 됩니다.12
민감도 영역이 보인다는 것은 어디까지 정상이라는 뜻일까요?
Excel 리본에 ‘민감도’라는 영역이나 버튼이 보인다고 해서 사용자가 레이블을 바로 적용할 수 있다는 뜻은 아닙니다. 버튼만 보이고 선택할 레이블이 없거나 비활성화되어 있다면, 레이블 정책이 아직 게시되지 않았거나 사용자에게 전달되지 않은 상태, 지원되지 않는 Office·파일 환경 등을 먼저 확인해야 합니다.1
반대로 ‘기밀’과 같은 실제 레이블 이름이 선택 목록에 나타난다면 게시 정책이 해당 사용자에게 도달한 것입니다. 하지만 문서 암호화까지 정상이라는 뜻은 아닙니다. 전체 과정은 다음처럼 이어집니다.
- 관리자가 레이블의 이름과 보호 규칙을 만듭니다.
- 게시 정책을 통해 사용할 사람에게 레이블을 보여줍니다.
- 사용자가 Excel 문서에 레이블을 적용합니다.
- Azure Rights Management가 사용자의 계정과 권한을 확인하고 문서를 보호합니다.
- SharePoint나 OneDrive에서 허용된 사용자들이 문서를 열고 공동편집합니다.
이번 적용에서는 처음에 민감도 버튼이 비활성화된 문제를 해결하고 레이블을 게시한 뒤, 데스크톱 Excel의 암호화 단계에서 IRM 오류를 다시 만났습니다. 서로 다른 단계에서 발생한 두 증상이므로, 하나의 계정 문제로 묶지 않고 레이블 게시와 문서 보호 서비스 상태를 나누어 점검해야 했습니다.
왜 웹용 Excel은 되는데 데스크톱 Excel에서는 오류가 날까요?
웹용 Excel에서 권한 지정 화면이 열린다면 레이블 게시와 SharePoint·OneDrive의 레이블 처리는 상당 부분 준비된 것입니다. 반면 데스크톱 Excel은 현재 로그인한 업무 계정으로 문서 보호 서비스에 연결해 사용 권한을 받아야 합니다.
이때 다음 중 하나가 빠지면 IRM 로그인 오류가 날 수 있습니다.
- 조직의 Azure Rights Management 서비스가 아직 활성화되지 않은 경우
- Excel에 여러 계정이 연결되어 있거나 오래된 로그인 정보가 남아 있는 경우
- 사용자에게 필요한 Microsoft 365 사용권 또는 서비스 계획이 할당되지 않은 경우
- 레이블 정책이나 공동편집 설정이 아직 동기화 중인 경우
- 데스크톱 Office 버전이 해당 기능을 지원하지 않는 경우
따라서 웹에서 된다는 사실은 중요한 단서이지만, 데스크톱 앱의 계정 연결과 문서 암호화까지 보장하는 최종 확인은 아닙니다.
실제로는 이 순서로 확인하면 됩니다
1. 변경하기 전에 문서 보호 서비스 상태를 조회합니다
관리자 PowerShell에서 AIPService 모듈을 사용합니다. 아래 명령은 현재 상태를 읽는 조회 작업이며 설정을 바꾸지 않습니다.
Import-Module AIPServiceConnect-AipServiceGet-AipServiceGet-AipServiceOnboardingControlPolicy
모듈이 없다면 관리자 PC에 Install-Module AIPService -Scope CurrentUser로 설치할 수 있습니다.
Get-AipService가 Enabled이면 문서 보호 서비스가 활성화된 상태이고, Disabled이면 비활성화된 상태입니다.2
Get-AipServiceOnboardingControlPolicy는 모든 사용자가 보호 기능을 쓸 수 있는지, 아니면 특정 그룹이나 조건에 해당하는 사용자만 쓸 수 있도록 제한했는지를 확인하는 명령입니다.5
2. 서비스가 꺼져 있다면 활성화 전 조건을 확인합니다
필요한 사용권을 보유했고 기존 보호 시스템과 충돌하지 않는다면 Enable-AipService로 서비스를 활성화할 수 있습니다.2
다만 이 명령은 한 사용자의 Excel만 고치는 설정이 아닙니다. 조직의 Microsoft 365 환경 전체에서 사용하는 문서 보호 서비스를 켜는 변경입니다. Microsoft 365에서 한 회사가 사용하는 독립된 관리 환경을 ‘테넌트’라고 부르므로, 흔히 ‘테넌트 단위 변경’이라고 표현합니다.
실행 전에는 다음 사항을 확인합니다.
- Azure Rights Management가 포함된 Microsoft 365 서비스 계획을 보유했는지
- 기존에 온프레미스 AD RMS를 사용하고 있지 않은지
- 일부 사용자부터 적용해야 한다면 대상 그룹을 어떻게 제한할지
- 새 문서로 시험할 소유자·편집자·열람자 계정을 준비했는지
AD RMS는 회사 내부 서버에 설치해 사용하던 이전 방식의 권한 관리 시스템입니다. 이를 사용 중이라면 바로 서비스를 켜지 말고 Azure Rights Management로 옮기는 절차를 먼저 확인해야 합니다.2
3. 데스크톱 Office 계정을 다시 확인합니다
서비스가 활성화되어 있다면 Excel에 표시된 이름만 보지 말고 실제 연결 상태를 확인합니다.
- Excel의 파일 → 계정에서 업무 계정과 제품 라이선스가 일치하는지 확인합니다.
- 개인 Microsoft 계정이나 다른 조직 계정이 함께 연결되어 있다면 충돌 여부를 확인합니다.
- 모든 Office 앱을 종료한 뒤 업무 계정으로 다시 로그인합니다.
- 운영 파일이 아닌 새
.xlsx문서나 복사본에 레이블을 적용합니다.
기존 파일에는 과거 암호나 보호 정보가 남아 있을 수 있으므로, 새 문서에서 성공 여부를 먼저 확인해야 원인을 좁히기 쉽습니다.
Get-IRMConfiguration만 보고 판단하면 안 되는 이유
문제를 확인하다 보면 Exchange Online PowerShell에서 Get-IRMConfiguration을 먼저 실행하는 경우가 있습니다. 이 명령은 Exchange 조직의 IRM과 메시지 암호화 설정을 확인하는 명령입니다.4
따라서 InternalLicensingEnabled나 AzureRMSLicensingEnabled가 False이고 LicensingLocation이 비어 있다는 결과는 참고할 단서가 될 수 있지만, 이것만으로 Word·Excel·PowerPoint 문서 보호 서비스가 꺼져 있다고 확정해서는 안 됩니다.
문서 보호 서비스 자체의 상태는 앞에서 설명한 Get-AipService로 따로 확인해야 합니다. 두 명령의 역할을 한 문장으로 구분하면 다음과 같습니다.
Get-IRMConfiguration: Exchange 메일 환경의 IRM 설정 확인Get-AipService: Office 문서 암호화 서비스의 활성 상태 확인
회사 메일이 외부 그룹웨어여도 문서 보호는 가능합니다
메일을 Exchange Online이 아닌 별도 그룹웨어에서 사용한다고 해서 Word·Excel·PowerPoint 문서 보호를 사용할 수 없는 것은 아닙니다. Azure Rights Management를 활성화해도 회사의 MX 레코드나 메일 흐름이 Microsoft 365로 자동 이전되지 않습니다.
다만 Outlook의 메일용 민감도 레이블은 사서함이 Exchange Online에 있어야 지원됩니다.1 따라서 다음 두 범위를 나누어 판단해야 합니다.
- 외부 그룹웨어의 메일 보호: 해당 메일 서비스의 기능과 정책을 따름
- Microsoft 365의 Office 문서 보호: Purview 민감도 레이블과 Azure Rights Management로 구성
이 구분을 해두면 메일 환경을 바꾸지 않고도 Office 문서 보호부터 적용할 수 있습니다.
공동편집을 쓴다면 레이블 설정도 함께 봐야 합니다
사용자가 레이블을 적용하면서 함께 편집할 사람을 직접 지정하려면 레이블에서 다음 항목이 준비되어야 합니다.
- 범위: 파일 및 기타 데이터 자산
- 액세스 제어: 암호화 사용
- 사용자가 레이블을 적용할 때 권한을 지정하도록 허용
- Word·Excel·PowerPoint에서 사용자가 권한을 지정하도록 구성
암호화된 문서의 공동편집을 사용하려면 SharePoint와 OneDrive가 민감도 레이블을 처리하도록 설정되어 있어야 하며, 지원되는 Microsoft 365 Apps 버전이 필요합니다. 설정이 조직 전체에 반영되기까지 최대 24시간이 걸릴 수 있습니다.3
또한 권한 만료일이 설정되어 있거나 이중 키 암호화를 사용하는 레이블은 공동편집과 자동 저장이 지원되지 않습니다.3
공유 권한과 레이블 권한은 서로 다른 문입니다
보호된 파일을 공동편집하려면 보통 두 가지 권한을 모두 통과해야 합니다.
| 권한 | 쉽게 말하면 | 설정하는 곳 |
|---|---|---|
| SharePoint·OneDrive 공유 권한 | 파일이 보관된 방에 들어갈 수 있는 열쇠 | 공유 링크, 사이트 또는 폴더 권한 |
| 레이블 암호화 권한 | 방 안의 보호된 문서를 열 수 있는 열쇠 | 레이블 적용 시 지정한 사용자·그룹과 역할 |
폴더를 이미 공유했어도 보호 파일을 열 사람을 레이블 권한에 다시 넣어야 할 수 있습니다. 같은 사용자를 두 번 지정하는 것처럼 보이지만, 하나는 파일 위치에 접근하는 권한, 다른 하나는 암호화된 내용을 여는 권한입니다.
기밀 문서는 누구나 링크보다 특정 사용자 링크를 권장합니다. 누구나 링크를 만들더라도 레이블 권한이 없는 사용자는 보호된 내용을 열 수 없어야 하지만, 링크가 널리 전달되고 파일 위치에 접근하는 범위가 불필요하게 커질 수 있기 때문입니다.
파일 소유자나 이미 권한을 받은 계정으로 누구나 링크를 열면 편집되는 것이 정상일 수 있습니다. 권한 차단 시험은 기존 로그인 정보가 없는 InPrivate 창이나 별도의 테스트 계정으로 진행해야 합니다.
오류가 사라진 뒤에는 네 가지 역할로 시험합니다
관리 화면에서 오류가 사라진 것만으로 설정이 끝난 것은 아닙니다. 운영 문서를 적용하기 전에 복사본을 만들고 다음 역할로 시험합니다.
- 소유자: 레이블 적용, 사용자 지정, 저장이 되는지 확인합니다.
- 허용된 편집자: 웹과 데스크톱 Excel에서 열기·편집·자동 저장을 확인합니다.
- 허용된 열람자: 문서는 열리지만 편집은 제한되는지 확인합니다.
- 권한 없는 사용자: InPrivate 창이나 다른 PC에서 문서 열기가 차단되는지 확인합니다.
마지막으로 파일을 로컬 PC나 다른 위치에 다운로드해도 동일하게 계정 인증과 권한 확인을 요구하는지 시험합니다. 특정 사용자 링크도 지정한 계정에서만 작동하는지 확인해야 합니다.
민감도 레이블은 파일이 이동한 뒤에도 문서 내용을 보호하는 데 도움이 되지만, 화면 촬영이나 허용된 사용자의 고의적인 재작성까지 모두 막는 기능은 아닙니다. 이런 위험까지 줄이려면 데이터 유출 방지 정책, 관리형 기기와 내부 운영 절차를 함께 검토해야 합니다.
정리하면
이번 사례는 파일 암호 때문에 공동편집이 막힌 문제에서 출발해, Purview 기반의 문서 보호로 전환하는 첫 설정 과정이었습니다. Excel의 민감도 버튼이 비활성화되거나 이후 IRM 오류가 난다면 계정 화면만 반복해서 확인하기보다 다음 순서로 접근하는 것이 좋습니다.
- 레이블이 사용자에게 게시되었는지 확인합니다.
Get-AipService로 문서 보호 서비스의 활성 상태를 확인합니다.- 서비스가 꺼져 있다면 사용권과 기존 AD RMS 여부를 확인한 뒤 활성화를 검토합니다.
- 데스크톱 Office의 업무 계정을 다시 연결하고 새 문서로 시험합니다.
- 공유 권한과 레이블 암호화 권한을 모두 지정합니다.
- 허용된 사용자와 권한 없는 사용자로 실제 파일을 열어 봅니다.
핵심은 민감도 버튼 표시, 레이블 게시, 문서 암호화, 파일 공유를 하나의 설정으로 보지 않는 것입니다. 각 단계를 나누어 확인하면 처음 적용할 때 어느 지점에서 막혔는지 훨씬 빨리 찾을 수 있습니다.
이 글은 카이온아이티가 파일 암호 방식에서 Microsoft Purview 문서 보호로 전환한 고객 환경의 첫 적용 과정을 바탕으로 작성했습니다. 고객을 식별할 수 있는 정보는 포함하지 않았습니다.
Purview 민감도 레이블은 보이지만 Office 앱에서 암호화나 공동편집이 작동하지 않나요?
카이온아이티가 레이블 정책, Microsoft 365 사용권, Azure Rights Management, SharePoint·OneDrive 공유 권한과 Office 앱 상태를 구분해 점검합니다.
참고 자료
- Manage Sensitivity Labels in Office Apps — Microsoft Learn, 2026-09-09 확인
- Activate the Azure Rights Management service — Microsoft Learn, 2026-09-09 확인
- Enable co-authoring for encrypted documents — Microsoft Learn, 2026-09-09 확인
- Get-IRMConfiguration — Microsoft Learn, 2026-09-09 확인
- Get-AipServiceOnboardingControlPolicy — Microsoft Learn, 2026-09-09 확인