Teams 스프롤: Microsoft Teams의 무분별한 확산 관리

Teams 스프롤은 Microsoft 365 환경에서 가장 흔히 간과되는 보안 위험 중 하나입니다. 모든 직원이 승인 없이, 명명 규칙이나 만료 정책 없이 즉시 팀을 생성할 수 있으면, 그 결과는 명확한 소유자가 없는 수백 개의 무관리(거버넌스 미적용) 워크스페이스, 일관되지 않은 명명, 그리고 흩어진 데이터로 이어집니다.

이러한 거버넌스 공백은 측정 가능한 위험을 만들어냅니다. Netwrix 2025 Cybersecurity Trends Report에 따르면, 비즈니스 사용자의 실수나 부주의가 3년 연속 상위 3대 보안 과제에 포함된 것으로 나타났습니다.

Teams 스프롤은 그 위험이 실제로 어떻게 드러나는지를 보여주는 교과서적인 사례입니다. 즉, 의도는 좋았던 협업 결정이라도 보호장치(가드레일)가 없으면 조직 전체에 걸쳐 보안과 컴플라이언스(규정 준수) 노출로 이어진다는 점입니다.

Microsoft Teams 스프롤이란 무엇이며, 왜 발생할까요?

Microsoft Teams 스프롤(Sprawl)은 Microsoft 365 환경 전반에서 팀, 채널, 콘텐츠가 통제되지 않은 채 무분별하게 늘어나는 현상입니다. 단순히 팀이 너무 많다는 수준을 넘어섭니다. 조직이 팀의 소유자를 추적하고, 액세스 제어를 시행하며, 각 작업 영역 내부의 데이터를 파악(인벤토리)할 수 있는 역량보다 팀 생성 속도가 더 빠를 때 발생합니다.

Teams는 독립적으로 존재하지 않기 때문에 문제는 빠르게 악화됩니다. 모든 팀은 기본적으로 Microsoft 365 그룹을 생성하며, 연결된 SharePoint site , 공유 사서함, OneNote 노트ブック도 함께 만듭니다. 이처럼 무분별하게 늘어나는 것은 단순한 디지털 정리되지 않음이 아니라, 실제 보안 및 컴플라이언스 위험을 초래합니다.

그렇다면 왜 이런 일이 발생할까요? Microsoft 365는 기본적으로 Teams 생성을 허용하며, 플랫폼에는 승인 워크플로우가 없고, 명명 요구사항도 없고, 만료 정책도 없습니다. 그 다음 단계에서 스프롤이 환경 전반으로 더 깊게 확산되는 요인은 네 가지입니다.

• 관대(느슨한)한 기본 설정이 토대를 만듭니다: 기본 제공(out-of-the-box) 상태에서 Microsoft 365 그룹 생성이 모든 사용자에 대해 활성화되어 있습니다. 네이티브 승인 메커니즘이 없고, 명명 정책 적용도 없으며, 자동 수명주기 관리 기능도 없습니다. 직접 구성하지 않는 한 이러한 기능은 제공되지 않습니다.
• 팬데믹이 모든 것을 가속했습니다: 2020년에 조직들이 원격 근무를 빠르게 도입하려 하면서, IT 팀은 Teams를 운영·가동하는 데 우선순위를 두었고 이를 관리(거버넌스)하는 일은 그 뒤로 밀렸습니다. 2020~2021년의 이러한 레거시 스프롤은 종종 아직도 해결되지 않은 채 남아 있습니다.
• 기술 전문 지식에 대한 요구는 장벽을 만듭니다: Teams Admin Center에서는 팀 생성을 제한할 수 없습니다. 해당 거버넌스 제어는 Microsoft Entra ID PowerShell 및 Entra 관리자 센터에 있습니다. PowerShell 전문 지식이 없는 조직은 스크립팅 지식 없이도 템플릿 기반 자동화를 제공하는 타사 거버넌스 플랫폼을 사용할 수 있습니다.
• 가시성이 부족하면 문제가 더 커집니다: 기본 사용 보고서는 최근 28일에 대해서만 제한된 활동 데이터를 보여줍니다. 비활성 또는 방치된 팀에 대한 기본 제공 보고서는 없습니다. 보이지 않는 것은 수정할 수 없으며, Microsoft의 기본 제공 도구는 상당한 수준의 가시성 공백을 남깁니다.

이러한 근본 원인은 단순히 운영상의 골칫거리를 만드는 데 그치지 않습니다. 스패롤이 해결되지 않은 채로 시간이 길어질수록 보안, 컴플라이언스, 재정적 위험이 구체적으로 더 악화됩니다.

조직에 Teams 스패롤 문제가 있을 때의 징후

아래 중 하나라도 익숙하다면, 스패롤이 이미 자리 잡았을 가능성이 큽니다:

• 활성 소유자가 없는 팀: 소유자가 없는 팀이나 소유자가 5명 이상인 팀은 책임 소재가 희석되어, 실제로 그 팀 내부의 내용에 대해 아무도 책임지지 않는 상태가 됩니다.
• 90일 이상 활동 없음: 완료된 프로젝트에 대해 보관(아카이빙) 전략이 없고 그대로 유휴 상태로 방치된 팀은 수명 주기 정책이 누락되었음을 의미합니다. 모든 비활성 팀에도 여전히 권한과 데이터가 존재합니다.
• 통제되지 않은 게스트 액세스: 2025년 11월 Teams 업데이트(MC1182004)로 기본적으로 사용자가 어떤 이메일 주소로든 채팅을 시작할 수 있게 되었습니다. 최근에 게스트 액세스 정책을 감사(점검)하지 않았다면, 외부 사용자는 생각보다 더 많은 권한을 가질 수 있습니다.
• 중복되고 일관되지 않은 명명: 이름이 유사한 여러 팀, "Project" 또는 "Test" 같은 일반적인 라벨, 그리고 설명에 맥락이 없는 팀은 모두 명명 표준이 누락되었음을 나타냅니다.
• 만료 정책이 구성되어 있지 않음: 사용 여부와 관계없이 팀이 무기한으로 유지된다면, 완료된 프로젝트 팀도 모두 계속 활성 상태로 접근 가능해져 공격 표면이 확대되고 컴플라이언스 감사가 복잡해집니다.
• 무제한 팀 생성: Microsoft Entra ID를 통해 생성 제한을 구성하지 않았다면, 모든 사용자가 감독 없이 새 팀을 만들 수 있습니다. 이는 기본 Microsoft 365 구성이며, 대부분의 조직은 이를 변경하지 않습니다.

Teams 스프롤이 초래하는 비즈니스 및 보안 위험

통제되지 않는 Teams 환경은 보안 노출, 규정 준수 실패, 운영 비용 전반에 걸쳐 위험을 초래합니다. 각각의 문제는 서로를 악화시키며, 함께 보면 스프롤을 단순한 IT 관리 업무가 아니라 보안 이슈로 다뤄야 한다는 근거가 됩니다.

1. 보안 노출

가장 즉각적인 위험은 무단 액세스입니다. 감독 없이 팀이 무분별하게 늘어나면 멤버십 관리가 무너집니다. 이전 직원은 액세스 권한을 그대로 유지하고, 게스트 사용자는 무기한으로 남아 있으며, 권한 할당은 이에 상응하는 제거 없이 누적됩니다. 그 결과는 access control 관리되지 않는 팀이 늘어날수록 점점 더 악화되는 권한 범위 확장(Privilege creep)입니다.

이러한 액세스 문제는 데이터 가시성 문제로 이어집니다. PHI, PII, Controlled Unclassified Information (CUI), 그리고 재무 기록이 통제되지 않는 팀 전반에 흩어져 있어, 중앙 집중형 인벤토리(자산 목록) 구축이 불가능해집니다.

기본 제공 Microsoft 도구는 특정 팀 안에 무엇이 있는지 확인할 수는 있지만, 수백 개로 늘어난 팀과 그에 연결된 SharePoint 사이트 전반에서 민감한 데이터를 찾아내는 데 필요한 audit trails 를 제공하지는 못합니다.

한편, 관리되지 않는 팀 생성은 관리되어야 할 플랫폼 안에서 사실상 섀도 IT를 만들어냅니다. 직원들이 악의적으로 행동하는 것은 아니지만, 누구나 IT 감독 없이 워크스페이스를 생성하고 데이터를 저장할 수 있다면, 바로 이런 종류의 위험을 대비해 마련된 통제 수단을 우회하게 되는 것입니다.

2. 준수 실패

팀이 무분별하게 늘어나면 여러 규제 프레임워크 전반에 걸쳐 노출이 발생합니다:

• HIPAA: 모니터링되지 않는 팀에 PHI가 들어가면, 조직은 보호되는 건강 정보에 대해 최소 권한(least-privilege) 액세스를 강제할 수 있는 능력을 잃게 됩니다. 침해 사고가 발생하면 60일 내 통지 요건은 PHI가 어디에 저장되어 있는지 파악할 수 있다고 전제하지만, 수백 개의 관리되지 않는 팀에 걸쳐서는 그럴 수 없습니다.
• SOC 2: 감사자는 환경 전반에 걸쳐 액세스 제어가 일관되게 적용되고 있음을 입증할 수 있는 증거를 기대합니다. 팀이 무분별하게 늘어나면 감사자가 찾는 바로 그 유형의 불일치가 발생합니다. 즉, 관리되지 않는 멤버십을 가진 워크스페이스, 소유 책임이 없는 상태, 그리고 누가 무엇에 접근했는지 보여주는 감사 로그(감사 추적)가 없는 것입니다.
• CMMC 2.0: 방산 계약업체의 경우, 무분별한 확장은 평가자(assessors)가 검토하는 액세스 제어 관행을 약화시킵니다. Teams 환경이 Controlled Unclassified Information(통제되지 않은 기밀정보가 아님)인 CUI에 대한 통제된 액세스를 입증하지 못하면, 그 격차가 계약 자격에 불이익을 초래할 수 있습니다.
• GDPR: 팀이 무분별하게 늘어나면 필요 이상으로 개인 데이터가 보관되어, 특정인의 데이터가 존재하는 모든 인스턴스를 찾을 수 없을 때 “잊혀질 권리(right to be forgotten)” 이행을 사실상 불가능하게 만듭니다.

eDiscovery는 이러한 컴플라이언스 위험을 더욱 악화시킵니다. Microsoft Teams는 Microsoft Purview를 통해 eDiscovery를 지원하지만, 범위가 무분별하게 확장되면 운영 측면에서 실용적이지 않게 됩니다.

수백 개의 관리되지 않는 팀에 걸쳐 콘텐츠 검색은 기하급수적으로 어려워지고, 법적 보류를 위한 워크스페이스를 식별하는 일은 거의 불가능해지며, 커뮤니케이션 컴플라이언스 모니터링도 확장할 수 없습니다.

3. 운영 및 재정 비용

보안 및 컴플라이언스 위험이 가장 큰 주목을 받지만, 스프로울(무분별한 확산)은 IT 리소스에 지속적인 부담을 주기도 합니다. 관리되지 않는 모든 팀은 결국 누군가가 우선순위를 정해 처리해야 하는 워크스페이스입니다:

• 소유권 확인
• 해당 정보에 민감한 데이터가 포함되어 있는지 평가하기
• 보관(아카이브)할지 삭제할지 결정하기

대부분의 조직에서는 이러한 선별(트리아지)이 사전에 적극적으로 이루어지지 않기 때문에, 규정 준수 감사나 보안 사고가 문제를 터뜨릴 때까지 쌓여가고, 그 시점에는 정기적인 절차가 아니라 긴급한 정리 작업이 됩니다.

저장 비용은 뒤에서 누적됩니다. 각 팀은 연결된 SharePoint 사이트를 생성하고, 만료 또는 보관(리텐션) 정책이 설정되지 않으면 비활성 팀은 파일, 채팅 기록, 공유 문서를 무기한으로 보관합니다.

수백 개의 고아 팀(활동이 중단된 채 남아 있는 팀)을 보유한 조직은, 비즈니스 목적에 전혀 도움이 되지 않는 저장 비용을 지불하고 있으며, 이에 따른 책임(리스크)도 이미 고려하지 않은 상태로 만들어지고 있습니다.

여기에 디스커버리 비용도 있습니다. 소송이나 규제 조사가 진행되는 동안 법무 또는 컴플라이언스 팀이 관리되지 않은 환경 전반을 검색해야 하는 경우, eDiscovery 처리 비용은 관련 워크스페이스 수에 비례해 증가합니다.

원래는 특정한 범위만을 대상으로 한 검색이어야 할 것이, 일관되지 않은 명명 규칙, 불명확한 소유권, 데이터 분류 부재로 인해 수백 개 팀을 광범위하게 훑는 작업이 됩니다. 이러한 비효율은 곧바로 청구 가능한 작업 시간 증가, 일정 지연, 그리고 디스커버리 프로세스 자체에서의 노출 확대로 이어집니다.

새로운 Teams 스프롤을 방지하는 방법

Teams 생성, 명명, 만료에 대한 거버넌스 제어는 Teams Admin Center가 아니라 Microsoft Entra ID 수준에서 모두 이뤄집니다. 예방을 제대로 적용하려면 디렉터리 수준에서 네 가지를 구성해야 합니다.

팀 생성 제한

Microsoft Entra ID PowerShell 또는 Entra 관리 센터를 사용해 팀을 생성할 수 있는 권한이 있는 모든 사용자를 포함하는 전용 보안 그룹을 만드세요. 그런 다음 디렉터리 수준 설정을 구성해 생성이 해당 그룹으로만 제한되도록 합니다. AzureADPreview 모듈은 2025년 3월 30일에 지원이 종료되었으므로, Microsoft는 장기 지원을 위해 이제 Microsoft Graph PowerShell SDK를 권장합니다.

IT 병목을 유발하는 전면적(일괄) 제한은 피하세요. 목표는 셀프 서비스 협업을 완전히 없애는 것이 아니라, 명명 규칙과 데이터 분류 요구사항을 이해하는 사용자들을 통해 생성이 이뤄지도록 유도하는 것입니다.

명명 정책 구현

Microsoft Entra ID에서 명명 정책을 구성하세요(Entra 관리 센터 → Groups → Naming Policy). 고정 문자열 또는 [Department], [Company], [Office] 같은 동적 특성을 사용해 Teams, Outlook, SharePoint, Planner, Viva Engage를 포함한 모든 Microsoft 365 Groups 워크로드 전반에 걸쳐 일관된 명명을 강제합니다.

일관된 명명은 단순히 조직을 정돈하는 것 이상을 제공합니다. 감사 범위 설정, 컴플라이언스 검색, 그리고 라이프사이클 의사결정을 대규모에서도 현실적으로 만들 수 있습니다. 팀이 예측 가능한 명명 패턴을 따를 때, 소유자, 목적, 민감도 수준을 식별하는 일이 훨씬 쉬워집니다.

만료 정책 구성

Microsoft Entra ID에서 만료 정책을 설정합니다(그룹 → 만료). 이렇게 하면 일반적으로 365일 같은 정해진 기간이 지나면 팀이 자동으로 만료됩니다. 사용이 활발한 팀은 만료 약 35일 전에 자동으로 갱신되므로, 생산적인 팀에는 영향이 없습니다. 모든 팀 소유자는 30일 시점에 갱신 알림을 받습니다.

이것은 스프롤 축적에 대한 가장 효과적인 단일 제어 방법입니다. 만료를 설정하지 않으면, 완료된 모든 프로젝트 팀이 무기한으로 유지되며 아무도 적극적으로 관리하지 않는 권한과 데이터가 계속 쌓입니다.

소유자 요구사항 적용

소유권은 다른 모든 거버넌스 제어의 기반입니다. 책임질 수 있는 소유자가 없으면 명명 정책이 제대로 적용되지 않고, 만료 갱신 사항도 평가되지 않으며, 민감한 데이터에 대한 결정도 내려지지 않습니다.

모든 팀에 최소 두 명의 소유자를 요구하세요. Microsoft Entra ID Access Reviews를 사용해 분기별 소유자 검토를 수행하고, 현재 소유자가 조직을 떠날 경우 새 소유자를 지정하기 위한 에스컬레이션 절차를 정의합니다.

기존 Teams 스팽(혼잡/확산) 정리 방법

거버넌스 정책은 새로운 스팽(확산)을 방지하지만, 이미 관리·감독 없이 존재하는 팀은 다루지 못합니다. 체계적인 정리 프로세스는 다섯 단계로 진행됩니다.

1단계: 인벤토리(현황) 평가

먼저 팀 이름, 소유 상태, 활동 수준, 가시성 설정을 포함해 현재 Teams 환경의 전체 인벤토리를 내보내는 것부터 시작하세요. 다음 기준에 따라 정리 대상 후보를 식별합니다.

• 비활동: 90~180일 동안 활동이 없는 팀
• 소유자 부재: 활성 소유자가 없거나 소유자가 전혀 없는 팀
• 중복: 이름이 유사하거나 동일한 여러 팀
• 1인 팀: 생성되었지만 협업에 한 번도 사용되지 않은 작업공간

2단계: 이해관계자 커뮤니케이션

활성 상태가 아닌 팀의 팀 소유자에게 미리 알리고, 정리(정비) 일정을 수립합니다(일반적으로 30~60일의 사전 고지). 또한 소유자가 팀을 갱신하거나 계속 유지해야 하는 이유를 명확하게 제시할 수 있도록 절차를 제공합니다. 사전 고지가 없이 팀을 삭제하면 조직 내 마찰이 생기고 IT 거버넌스에 대한 신뢰가 약화되므로, 커뮤니케이션은 매우 중요합니다.

3단계: 비활성 팀 보관(아카이빙)

보관(아카이빙)하면 모든 콘텐츠를 유지한 채로 팀이 읽기 전용이 됩니다. 규제가 적용되는 산업의 경우, 보관은 즉시 삭제하는 대신 기본 조치로 삼아야 합니다. 보관된 팀은 규정 준수 목적을 위해 데이터를 보유하는 동시에, 활성 협업에서는 제외되어 추가 권한이 누적되는 것을 방지합니다.

4단계: 불필요한 팀 삭제

삭제는 다음 사항을 확인한 후에만 수행해야 합니다:

• 적용되는 보존 정책이 없습니다
• 데이터에 준수(컴플라이언스) 가치가 없습니다
• 법적 보류(리걸 홀드)가 존재하지 않습니다
• 필요한 데이터가 내보내기(Export) 되었습니다
• 이해관계자 승인(Stakeholder approval)을 받았습니다

삭제된 팀은 영구 삭제되기 전에 30일간 소프트 삭제 상태에 들어가며, 무언가가 성급하게 제거된 경우 복구할 수 있는 기간을 제공합니다.

5단계: 보존 정책 구성

대규모 삭제를 시작하기 전에 Microsoft Purview를 통해 Teams 채널 메시지와 채팅에 대한 보존 정책을 구성하세요. 보존 기간은 규제 요구 사항과 일치해야 합니다. 이러한 정책이 없으면 정리 작업 중 컴플라이언스 가치가 있는 데이터를 실수로 삭제할 위험이 있습니다.

정리가 완료되면, 지속적인 수동 작업 없이 거버넌스를 유지하는 것이 과제로 남습니다. 위의 예방 섹션에서 다룬 만료 정책, 소유자 검토, 생성 제한은 스프롤이 다시 늘어나는 것을 막아줍니다.

Netwrix가 Teams 거버넌스를 지원하는 방법

거버넌스 정책과 정리(클린업) 스크립트는 Teams 스프롤의 구조적인 문제를 해결합니다. 하지만 더 근본적인 과제는 가시성입니다:

• 수백 개의 팀과 연결된 SharePoint 사이트 전체에서 누가 어떤 데이터에 접근 권한을 가지고 있는지 파악하는 것
• 권한이 변경(드리프트)되는 시점을 감지
• 규제 기관이 실제로 인정하는 감사 증빙 자료를 생성

그 공백을 Microsoft의 기본 도구들이 그대로 남겨두고 있으며, 그 지점에 Netwrix가 들어맞습니다.Netwrix 1Secure 복잡한 배포 없이도 1일차부터 Microsoft 365 환경에 대한 가시성을 제공합니다. SharePoint Online의 경우 1Secure는 데이터 액세스 활동을 추적하고, 민감한 데이터 위치를 노출하며, 협업 환경 전반에 걸친 권한 변경 사항을 모니터링합니다.

위험 평가 대시보드는 Teams 스프롤(범람)이 야기하는 문제를 보여줍니다. 예를 들어 과도한 권한, 민감한 데이터에 대한 무제한(열린) 액세스, 접근이 남아 있는 휴면 계정, 그리고 조직 정책을 위반하는 권한 구성 등이 있습니다. AI 기반의 수정(대응) 권장 사항은 팀이 무엇을 먼저 수정할지 우선순위를 정하는 데 도움이 됩니다.

Netwrix Auditor는 규제 산업이 필요로 하는 깊이 있는 컴플라이언스 중심 감사(감사/로깅) 기능을 제공합니다. 빠른 배포와 몇 시간 내 제공되는 리포트로, Auditor는 Teams, SharePoint, Active Directory, 파일 서버 전반에 걸쳐 감사 추적을 제공합니다. Google과 같은 대화형 검색을 통해 조사자는 전체 환경에서 "누가 무엇에 언제 액세스했는지"를(한 번에 한 팀이 아니라) 확인할 수 있습니다.

HIPAA, SOC 2, GDPR, PCI DSS, CMMC에 대한 사전 정의된 컴플라이언스 매핑이 제공되므로, 감사 준비는 증거를 수작업으로 모으는 대신 리포트를 가져오는 것에 가깝게 진행됩니다.

Microsoft 365 환경에서의 특권 액세스를 위해, Netwrix Privilege Secure는 상시 관리자 권한을 없애는 즉시(Just-in-time) 프로비저닝을 제공하며, 감사 추적을 위한 세션 기록(session recording)도 제공합니다.

대부분의 조직은 거버넌스 의지가 부족한 것이 아닙니다. 문제는 Teams 환경 전반에서 무슨 일이 일어나고 있는지, 실제로 조치할 수 있을 만큼 명확하게 파악하는 능력이 부족하다는 점입니다. Netwrix는 이미 과중한 보안 팀에 복잡성을 더하지 않으면서 그 격차를 메워줍니다.

데모를 예약하세요 Netwrix가 실제로 어떻게 작동하는지 확인하고, 관리되지 않은 확산 상태에서 감사 가능한 제어로 얼마나 빠르게 전환할 수 있는지 알아보세요.