같은 것으로 취급하지 마십시오: M365의 보존 정책과 레코드 관리 비교

By Mirko Peters · 2026-08-11

Microsoft 365 규정 준수의 때로는 혼란스러운 세계를 깊이 있게 살펴보겠습니다. 광범위한 규정 준수 규칙을 설정하고 데이터가 완전히 안전하고 잠겨 있으며 법적으로 보호된다고 가정했던 적이 있다면, 여러분만 그런 것이 아닙니다. 그러나 Microsoft Purview가 조직의 디지털 흔적을 어떻게 처리하는지 잘못 가정하면 대규모 규정 준수 사각지대가 생기거나, 더 나쁘게는 데이터가 실수로 손실될 수 있습니다. 이번 포스트에서는 Microsoft 365 보존 정책과 레코드 관리의 핵심 차이점을 분석하고, 이 시스템들이 상호작용하는 방식에 대한 검증된 사고 모델을 제시하며, 테넌트를 보호하기 위한 실행 가능한 청사진을 제공하겠습니다.

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

Titelbild: Stop Treating Them the Same: Retention Policies vs. Records Management in M365

Microsoft 365 컴플라이언스의 다소 복잡한 영역을 깊이 있게 살펴보는 이 글에 오신 것을 환영합니다. 광범위한 컴플라이언스 규칙을 설정하고 데이터가 완벽하게 안전하며 잠겨 있고 법적으로 보호된다고 가정한 적이 있다면, 여러분만 그런 것이 아닙니다. 하지만 Microsoft Purview가 조직의 디지털 흔적을 어떻게 처리하는지 임의로 가정하면 컴플라이언스 사각지대가 커지거나, 더 심각하게는 데이터가 의도치 않게 손실될 수 있습니다. 이 종합 게시물에서는 Microsoft 365 보존 정책과 레코드 관리의 핵심 차이를 짚어 보고, 두 시스템이 상호 작용하는 방식에 대한 검증된 사고 모델을 제시하며, 테넌트를 보호하기 위한 실행 가능한 청사진을 제공하겠습니다.

이 블로그 게시물은 팟캐스트에서 다룬 주제를 자세히 확장한 것입니다. 실제 사례와 깊이 있는 기술적 통찰이 담긴 전체 대화를 듣고 싶다면 Microsoft 365 Retention Policies vs Records Management 에피소드를 꼭 들어 보십시오.

에피소드 개요

대부분의 테넌트는 보존과 레코드 관리를 데이터가 사라지거나 법적 보존 기간을 넘어 남아 있을 때까지 서로 바꿔 쓸 수 있는 스위치처럼 취급합니다. 이 에피소드에서는 M365 규정 준수 기능이 Exchange, SharePoint, OneDrive, Teams 전반에서 어떻게 상호작용하는지 분석하고, 정책이 충돌할 때 무엇이 우선하는지, 감사 및 eDiscovery를 견딜 수 있는 엔드투엔드 프로그램을 어떻게 설계하는지 살펴봅니다.

대상 독자

방어 가능한 보존을 책임지는 규정 준수 및 법무 팀
Purview 정책과 레이블을 운영하는 M365 관리자 / 레코드 관리자
감사와 DSAR에 대비하는 보안 및 거버넌스 리더
기존 공유 폴더를 Microsoft 365로 마이그레이션하는 프로젝트 책임자

핵심 요약

스위치가 아닌 시스템: 보존 정책, 자동 적용 레이블, 레코드, 보존 잠금은 겹치므로 하나의 시스템으로 설계해야 합니다.
우선순위가 중요합니다: 범위가 더 구체적인 설정(항목 수준 레이블/레코드)이 일반적으로 광범위한 위치 정책보다 우선하며, 워크로드별 동작은 서로 다릅니다.
보존 ≠ 변경 불가: 정책은 보관 기간을 제어하고, 레코드는 무엇을 변경할 수 있는지(변경 불가 및 처리)를 제어합니다.
숨겨진 충돌: 기존 정책, 사이트 정책, 자동 적용 레이블이 서로를 조용히 무효화하여 조기 삭제나 무기한 보존을 일으킬 수 있습니다.
감사 또는 드리프트: 정기적인 검토가 없으면 정책이 침전물처럼 쌓여 사각지대와 eDiscovery 실패로 이어집니다.

테넌트가 실수하는 지점

7년 보존 정책이 편집이나 삭제를 막는다고 생각하는 것(그렇지 않습니다. 레코드로 선언해야 합니다).
우선순위 매핑 없이 워크로드마다 다른 보존 기간(예: Exchange 5년, SharePoint 7년, Teams 3년)을 적용하는 것.
.All-sites 정책과 자동 적용 레이블을 과도하게 사용하는 것 → 예측할 수 없는 결과.
규칙을 누가/왜/어디에 만들었는지 문서화하지 않는 것 — 의도에 대한 관리 이력이 없습니다.

사고 모델: 언제 무엇이 우선하는가?

법적 보존 / eDiscovery 보존(가장 강력하며 콘텐츠를 보존합니다).
항목 수준의 레코드(선언된 레코드 또는 규제 레코드)(편집과 삭제를 잠그고 처리를 주도합니다).
정의된 기간/작업이 있는 보존 레이블(항목 수준).
위치 보존 정책(사이트/사서함/OneDrive/Teams).
정책 없음(스토리지 소유자의 행동이 결정합니다).

참고: 워크로드 엔진은 서로 다릅니다(예: Teams 채팅과 SharePoint 문서). 항상 여러분의 테넌트에서 테스트하십시오.

청사진: 비즈니스 요구를 M365 통제에 매핑하기

데이터 분류
- 규제 대상, 계약 대상, 업무용, 일시적 데이터로 나눕니다. 소유자와 원본 시스템(System of Record)을 정의합니다.
위치 목록 작성
- 사서함, Teams(채팅/채널), SharePoint 사이트/라이브러리, OneDrive를 확인합니다. 마이그레이션과 기존 보존 잠금도 기록합니다.
보존 및 레코드 규칙 정의
- 각 분류에 대해 보존 기간, 이벤트/생성 시작 시점, 레코드 선언 필요 여부, 처리 검토, 보존 잠금을 정의합니다.
통제 수단 선택
- 위험도가 높거나 규제가 엄격한 항목(계약서, 환자 및 재무 기록)에는 레코드를 적용합니다.
- 불변성이 필요하지 않은 경우 항목 단위 제어를 위해 보존 레이블을 사용합니다.
- 넓고 위험도가 낮은 기본 설정에는 위치 정책을 사용합니다.
우선순위와 예외 모델링
- 여러 제어가 적용될 때 어떤 제어가 적용되는지 문서화하고, 샌드박스 사이트 + 테스트 사서함 + 테스트 팀에서 파일럿을 진행합니다.
안전한 범위에서 자동화
- 자동 적용 레이블(민감한 정보 유형, 키워드, 학습 가능한 분류기)을 사용해 사용자의 부담을 줄입니다.
폐기 워크플로
- 레코드 폐기에는 검토, 폐기 증명, 감사 추적을 필수로 요구합니다.
배포 및 교육
- 사이트 소유자와 채널 관리자에게 보존과 레코드의 차이를 설명하고, 간단한 결정 트리를 게시합니다.
의도 문서화
- 정책이나 레이블마다 소유자, 범위, 목적, 법적 근거, 시작 이벤트, 종료 작업, 검토 주기를 기록합니다.

운영 가이드라인

변경 관리: 새 정책이나 레이블마다 PRD를 작성하고, 우선순위에 영향을 주는 변경은 동료 검토를 거칩니다.
명명 규칙: [LOB]-[DataClass]-[Years]-[Action]-[Scope](예: FIN-Invoices-7y-Record-SP).
범위 지정 파일럿: 전사 롤아웃 전에 시나리오별로 사서함, 사이트, 팀 단위로 파일럿을 진행합니다.
예외 경로: 신속한 법적 보류 프로세스가 보존 로직을 깨뜨리지 않으면서 다른 모든 설정보다 우선합니다.
사용자 UX: 기본 보기에 레이블/레코드 열을 표시하고, 소유자가 충돌을 확인하는 방법을 교육합니다.

감사 및 향후 대비

분기별 정책 상태 점검
- 고아 레이블, 겹치는 범위, 한 번도 적용되지 않은 자동 레이블 규칙, 만료된 테스트 정책을 점검합니다.
도상 훈련(Tabletop exercises)
- HR 사례, GDPR/CCPA DSAR, 소송 보류를 시뮬레이션하고 검색 소요 시간과 완전성을 확인합니다.
대시보드로 텔레메트리 전달
- 레이블 적용 비율, 레코드 항목, 폐기 대기 항목, 보류 건수, 정책 충돌을 추적합니다.
로드맵 모니터링
- Purview 업데이트 후 다시 평가하고, Teams/SharePoint 엔진의 동작이 바뀌면 파일럿을 다시 실행합니다.

흔한 문제와 해결 방법

“영구” 보존이지만 사용자가 삭제하거나 편집할 수 있음: 레코드가 아닙니다. → 레코드로 선언하거나 규제 레코드를 사용해 더 엄격한 불변성을 적용합니다.
검색에서 Teams 채팅 누락: Teams 보존과 Exchange/SharePoint 매핑이 일치하지 않습니다. → 채팅/채널 정책을 맞추고 내보내기를 테스트합니다.
SharePoint는 일찍 삭제하고 메일은 오래 보관: 기간이 균일하지 않습니다. → 기간을 표준화하거나 필요한 곳에 항목 단위 레이블을 적용합니다.
자동 적용 레이블이 예상치 않게 사이트 정책을 덮어씀: 우선순위 문제입니다. → 자동 적용 범위를 좁히거나, 대상 라이브러리에는 레코드만 적용합니다.

빠른 시작 (첫 2주)

인벤토리 및 히트맵: 위험도 기준 상위 20개 사이트/팀/사서함을 확인하고, 현재 레이블/정책/보류 상태를 기록합니다.
중요 레코드 시리즈 하나 선택(예: 서명된 계약서): 레이블을 레코드로 설계하고, 폐기 검토를 거치는 통제된 라이브러리에서 파일럿을 진행합니다.
한 프로젝트 팀에서 채팅과 문서 보존 맞추기: Teams/SharePoint/Exchange 기간이 의도한 결과와 일치하는지 확인합니다.
감사 대시보드 만들기: 레이블 적용 비율, 레코드 수, 폐기 대기 항목, 발견된 충돌을 표시합니다.
테스트 사용자에 대해 도상 DSAR 실행: 격차를 기록하고 확장 전에 수정합니다.

자주 묻는 질문

보존 정책은 삭제를 막나요? 그 자체로는 막지 않습니다. 항목이 보류 상태이거나 레코드로 선언되지 않은 한 사용자는 삭제할 수 있습니다.
여러 정책이 적용되면 어느 것이 우선하나요? 일반적으로 보류 > 레코드 > 항목 레이블 > 위치 정책 순입니다(워크로드별로 확인하십시오).
모든 항목에 레코드가 필요한가요? 아닙니다. 위험도가 높고 규제를 받는 시리즈에만 사용하고, 나머지에는 레이블과 정책을 사용하십시오.
자동 적용이 교육을 대체할 수 있나요? 도움은 되지만, 소유자는 여전히 레이블, 레코드, 예외를 이해해야 합니다.

결론

Microsoft 365 내에서 규정 준수 제어를 구성하는 일은 "설정하고 잊어버리는" 작업이 아닙니다. 보존 정책과 레코드 관리를 동일한 도구로 취급하는 생각에서 벗어나면, 값비싼 소송 사각지대, 의도하지 않은 데이터 삭제, 혼란스러운 규정 준수 감사로부터 조직을 보호할 수 있습니다. 비즈니스 요구 사항을 신중하게 매핑하고, 우선순위를 존중하며, 전사에 배포하기 전에 항상 샌드박스 환경에서 구성을 테스트하십시오.

이러한 전략을 더 깊이 살펴보고, 전문가의 분석을 듣고, 테넌트의 데이터를 제대로 보호하는 방법을 알고 싶으시다면 관련 팟캐스트 에피소드를 꼭 확인해 보시기 바랍니다: Microsoft 365 Retention Policies vs Records Management.