Microsoft Teams는 이제 단순한 메신저가 아닙니다. 프로젝트 논의, 고객 커뮤니케이션, 파일 공유, 의사결정 기록까지—Teams는 한국 중소기업의 핵심 업무 플랫폼으로 자리 잡았습니다. 그런데 한 가지 질문을 던져 봅니다. 지금 Teams에 쌓여 있는 수천 건의 메시지, 공유 파일, 채널 게시물이 내일 갑자기 사라진다면 어떻게 하시겠습니까?
많은 IT 담당자가 "Microsoft 365에 보존 정책이 있으니까 괜찮다"고 생각합니다. 하지만 실제로 데이터 유실 사고를 겪어 본 분들은 알고 있습니다. M365의 보존 정책은 '백업'이 아닙니다. 보존(Retention)과 백업(Backup)은 목적도, 복구 능력도, 관리 방식도 전혀 다릅니다. 이 차이를 정확히 이해하지 못하면, 정작 데이터가 필요한 순간에 복구할 수 없는 상황에 놓이게 됩니다.
이 글에서는 Teams 데이터 백업이 반드시 필요한 이유, M365 기본 보존 정책의 구조적 한계, 그리고 중소기업이 현실적으로 적용할 수 있는 백업 전략을 구체적으로 살펴보겠습니다.
Teams 데이터는 왜 특별히 보호해야 하는가
Teams 데이터가 다른 업무 데이터와 다른 점은 분산 저장 구조에 있습니다. Teams에서 주고받는 메시지는 Exchange Online 사서함에, 채널에 공유된 파일은 SharePoint Online에, 개인 채팅의 첨부 파일은 OneDrive for Business에 각각 저장됩니다. 하나의 Teams 대화가 실제로는 세 가지 이상의 서비스에 걸쳐 존재하는 것입니다.
이 복잡한 구조 때문에 발생하는 문제가 있습니다. 첫째, 사용자가 실수로 채널을 삭제하면 관련 메시지뿐 아니라 SharePoint의 연결된 파일 라이브러리까지 영향을 받습니다. 둘째, 퇴사자의 계정이 삭제되면 해당 사용자의 1:1 채팅 기록과 OneDrive 파일이 함께 사라질 수 있습니다. 셋째, 팀(Team) 자체를 삭제하면 30일의 소프트 삭제 기간이 지난 후 영구 삭제되며, 이후에는 Microsoft 지원에 요청해도 복구가 불가능합니다.
특히 한국 중소기업 환경에서는 IT 전담 인력이 부족하여 퇴사 처리 시 계정 관리가 늦어지거나, 프로젝트 종료 후 팀 채널을 정리하는 과정에서 중요 데이터가 함께 삭제되는 사례가 빈번합니다. 개인정보보호법에 따른 데이터 보관 의무나 감사 대응을 위해서도 Teams 커뮤니케이션 기록의 체계적인 백업은 선택이 아닌 필수입니다.
M365 보존 정책의 구조적 한계 5가지
Microsoft 365는 보존 정책(Retention Policy)과 소송 보존(Litigation Hold) 등의 기능을 제공합니다. 이 기능들은 컴플라이언스 목적의 데이터 보존에는 유용하지만, '백업과 복구'의 관점에서 보면 명확한 한계가 있습니다.
- 세밀한 복구(Granular Restore)가 어렵습니다. 보존 정책은 데이터를 '보관'할 뿐, 특정 시점의 특정 메시지나 파일을 골라서 원래 위치에 복원하는 기능이 아닙니다. eDiscovery를 통해 검색·내보내기는 가능하지만, 이는 원본 채널에 메시지를 되돌려 놓는 것과는 전혀 다릅니다.
- 복구 속도와 편의성이 부족합니다. eDiscovery 검색 결과를 PST 파일로 내보내고, 이를 다시 사용자에게 전달하는 과정은 IT 담당자에게 상당한 시간과 노력을 요구합니다. 급하게 데이터가 필요한 상황에서 몇 시간, 경우에 따라 며칠이 걸릴 수 있습니다.
- 보존 정책 설정의 복잡성이 높습니다. Teams 채팅과 채널 메시지에 대한 보존 정책은 별도로 설정해야 하며, SharePoint·OneDrive 정책과도 따로 관리해야 합니다. 정책 적용 범위를 잘못 설정하면 보호해야 할 데이터가 정책에서 빠지는 '사각지대'가 생깁니다.
- 악의적 삭제나 랜섬웨어에 취약합니다. 관리자 권한을 탈취한 공격자가 보존 정책 자체를 해제하거나 변경할 수 있습니다. 보존 정책은 Microsoft 365 테넌트 내부에 존재하므로, 테넌트가 침해되면 보존된 데이터도 함께 위험에 노출됩니다.
- Microsoft의 공동 책임 모델을 이해해야 합니다. Microsoft는 인프라의 가용성(서비스가 동작하는 것)에 대해 책임지지만, 고객 데이터의 보호와 백업은 고객의 책임이라고 서비스 약관에서 명시하고 있습니다. 즉, Microsoft가 데이터를 잃어버리지 않도록 노력하지만, 사용자 실수나 악의적 삭제로 인한 데이터 손실까지 책임지지는 않습니다.
M365 보존 정책은 '삭제 방지'에 가깝지, '시점 복구(Point-in-Time Recovery)'가 아닙니다. 보존 정책이 있다고 해서 "3일 전 상태로 Teams 채널을 통째로 되돌린다"는 것은 불가능합니다. 이 차이를 반드시 인식해야 합니다.
보존 정책 vs. 전용 백업 솔루션: 핵심 비교
보존 정책과 전용 백업 솔루션의 차이를 한눈에 비교해 보겠습니다. 아래 표를 통해 두 접근 방식의 근본적인 차이를 확인할 수 있습니다.
| 비교 항목 | M365 보존 정책 | 전용 백업 솔루션 (예: Acronis) |
|---|---|---|
| 주요 목적 | 컴플라이언스·법적 보존 | 데이터 보호·복구 |
| 시점 복구(Point-in-Time) | 미지원 | 지원 — 특정 날짜·시점으로 복원 가능 |
| 세밀한 복구 단위 | eDiscovery로 검색 후 내보내기만 가능 | 개별 메시지, 파일, 채널 단위 복원 |
| 복구 소요 시간 | 수 시간~수 일 (검색·내보내기 과정) | 수 분~수 시간 (솔루션에 따라 차이) |
| Teams 데이터 커버리지 | 채팅·채널 메시지 보존 (파일은 별도 정책) | 메시지, 파일, 탭, 설정 등 통합 보호 |
| 랜섬웨어·관리자 침해 대응 | 테넌트 내부에 보존되므로 함께 위험 | 외부 저장소에 격리 보관, 독립적 보호 |
| 퇴사자 데이터 보존 | 라이선스 유지 또는 별도 조치 필요 | 백업 데이터는 라이선스 해제 후에도 유지 |
| 설정 복잡도 | 높음 (서비스별 개별 정책 설정) | 중간 (통합 관리 콘솔에서 일괄 설정) |
| 추가 비용 | E3 이상 라이선스 필요 (일부 기능) | 별도 백업 솔루션 라이선스 비용 |
보존 정책과 백업은 상호 보완적입니다. 보존 정책은 법적 요건 충족에, 전용 백업은 실질적인 데이터 복구에 사용하는 것이 가장 이상적인 구성입니다. 둘 중 하나만 사용하면 반드시 보호의 빈틈이 생깁니다.
Teams 데이터 백업 전략: 실행 가이드
그렇다면 중소기업 IT 담당자가 Teams 데이터를 체계적으로 보호하려면 어떤 단계를 밟아야 할까요? 아래 체크리스트를 따라 현재 환경을 점검하고 개선해 보시기 바랍니다.
- 현재 보존 정책 현황 점검: M365 관리 센터에서 현재 적용 중인 보존 정책을 확인합니다. Teams 채팅, 채널 메시지, SharePoint, OneDrive에 각각 어떤 정책이 걸려 있는지, 보존 기간은 얼마인지 정리합니다. 정책이 없거나 기본값으로 방치되어 있는 경우가 많으므로 반드시 확인해야 합니다.
- 데이터 유실 시나리오 식별: 우리 조직에서 발생할 수 있는 데이터 유실 시나리오를 나열합니다. 퇴사자 계정 삭제, 사용자 실수로 인한 채널 삭제, 랜섬웨어 감염, 관리자 계정 탈취 등 현실적인 위험을 기준으로 우선순위를 매깁니다.
- 복구 요구사항 정의(RPO/RTO): 데이터가 유실됐을 때 얼마나 오래전 시점까지 복구해야 하는지(RPO), 복구에 얼마나 시간이 걸려야 하는지(RTO)를 정합니다. 예를 들어 "최대 24시간 이내 데이터까지 복구 가능해야 하고, 복구 작업은 2시간 이내 완료" 같은 기준을 수립합니다.
- 전용 백업 솔루션 도입 검토: Acronis Cyber Protect Cloud와 같은 M365 전용 백업 솔루션은 Teams 메시지, 채널, 파일을 포함한 M365 전체 워크로드를 통합적으로 백업합니다. 특히 테넌트 외부의 독립된 저장소에 데이터를 보관하므로, 랜섬웨어나 관리자 계정 침해 시에도 백업 데이터가 안전합니다.
- 백업 주기 및 보관 기간 설정: 업무 중요도에 따라 일 1회 이상 자동 백업을 설정하고, 보관 기간은 법적 요건과 업무 필요성을 고려하여 결정합니다. 한국 개인정보보호법상 관련 기록의 보관 의무 기간을 반드시 확인하십시오.
- 복구 테스트 수행: 백업만 해두고 복구 테스트를 하지 않는 것은 소화기를 사 두고 한 번도 사용법을 확인하지 않는 것과 같습니다. 분기에 한 번 이상 실제 복구 시나리오를 테스트하여 RTO 목표를 충족하는지 확인해야 합니다.
시나리오: 프로젝트 채널 삭제 사고와 복구 과정
어떤 중소기업에서 6개월간 진행한 주요 프로젝트의 Teams 채널이 실수로 삭제되었다고 가정합니다. 이 채널에는 고객과의 회의 기록, 사양 문서, 내부 논의 내역이 모두 담겨 있었습니다.
보존 정책만 있는 경우: 채널 삭제 후 30일 이내라면 관리자가 팀을 복원할 수 있지만, 30일이 지나면 영구 삭제됩니다. 설사 보존 정책이 걸려 있어도, eDiscovery를 통해 메시지를 검색할 수는 있지만 원래 채널 구조 그대로 복원하는 것은 불가능합니다. 파일은 SharePoint 휴지통에서 찾아야 하고, 메시지는 별도로 내보내야 합니다. 결국 완전한 복원은 사실상 어렵습니다.
전용 백업 솔루션이 있는 경우: 백업 관리 콘솔에서 삭제 전 시점을 선택하고, 해당 채널의 메시지와 파일을 원래 위치에 복원합니다. 채널 구조, 대화 흐름, 첨부 파일이 함께 복원되므로 업무 연속성이 유지됩니다. IT 담당자의 작업 시간도 크게 줄어듭니다.
이 시나리오는 가상이지만, 실제로 많은 조직에서 유사한 상황이 발생하고 있습니다. 채널 삭제, 퇴사자 계정 정리, 혹은 외부 공격에 의한 데이터 손실은 "만약"의 문제가 아니라 "언제"의 문제입니다.
Teams 백업, 왜 지금 시작해야 하는가
Teams 활용도가 높아질수록, 그 안에 쌓이는 데이터의 가치도 함께 올라갑니다. 채팅 메시지 하나하나가 업무 지시, 합의 내용, 고객 약속의 증거가 될 수 있습니다. 한국 개인정보보호법이나 업종별 규제에 따라 커뮤니케이션 기록을 일정 기간 보관해야 하는 의무가 있는 경우, 보존 정책만으로는 감사 대응에 필요한 수준의 데이터 관리가 어렵습니다.
또한 최근 클라우드 환경을 노리는 사이버 공격이 증가하면서, M365 테넌트 자체가 랜섬웨어의 타겟이 되는 사례가 보안 업계에서 지속적으로 보고되고 있습니다. 관리자 계정이 탈취되면 보존 정책 해제, 데이터 삭제, 백업 비활성화가 한 번에 이루어질 수 있습니다. 이런 상황에서 테넌트 외부에 독립적으로 보관된 백업 데이터만이 마지막 방어선이 됩니다.
Acronis Cyber Protect Cloud는 M365 워크로드(Exchange Online, SharePoint Online, OneDrive for Business, Teams)를 통합적으로 보호하며, 이미지 기반 백업과 클라우드 간 백업(Cloud-to-Cloud Backup)을 통해 데이터를 안전한 외부 스토리지에 보관합니다. 특히 AI 기반 위협 탐지 기능과 결합하여, 백업 데이터 자체에 악성코드가 포함되는 것을 방지하는 보안 계층까지 제공합니다.
M365 데이터 보호의 핵심 원칙은 3-2-1 백업 규칙입니다. 데이터의 사본 3개를, 서로 다른 2종류의 매체에, 그중 1개는 외부(오프사이트)에 보관하는 것입니다. M365 보존 정책은 이 중 오프사이트 사본에 해당하지 않습니다.
마무리: Teams 데이터, 보존이 아니라 '보호'하십시오
정리하면, M365 보존 정책은 컴플라이언스를 위한 기본 도구이지 데이터 백업·복구 솔루션이 아닙니다. Teams의 복잡한 분산 저장 구조, 퇴사자 관리, 랜섬웨어 위협, 법적 데이터 보관 의무까지 고려하면, 전용 백업 솔루션의 도입은 더 이상 미룰 수 없는 과제입니다.
KDSys는 Acronis 공인 파트너로서 한국 중소기업 환경에 최적화된 M365 백업 솔루션 도입을 지원합니다. 현재 M365 보존 정책 현황 진단부터, Acronis Cyber Protect Cloud를 활용한 Teams·Exchange·SharePoint 통합 백업 설계, 그리고 복구 테스트까지 엔드투엔드로 함께합니다.
- 무료 M365 보호 현황 진단: 현재 보존 정책의 사각지대를 분석해 드립니다.
- 맞춤형 백업 설계: 조직 규모, 업종, 법적 요건에 맞는 백업 주기·보관 기간을 설계합니다.
- 도입 후 지속 관리: 백업 모니터링, 정기 복구 테스트, 정책 업데이트까지 지원합니다.
Teams 데이터가 사라진 뒤에 후회하지 마십시오. 지금 KDSys에 문의하셔서 M365 데이터 보호의 첫 걸음을 시작하세요.