Microsoft Entra 관리 단위 가이드

By Mirko Peters · 2026-04-30 · Updated 2026-07-18

보안, 거버넌스, 액세스 제어, 구현, 실제 활용에 관한 실용적인 지침과 함께 Microsoft Entra 관리 단위를 알아봅니다.

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

Cover: Fix Azure Governance Before Your Next Cloud Audit

Microsoft 365나 Azure로 대규모 조직을 관리하다 보면 상황이 금세 복잡해질 수 있습니다. Microsoft Entra ID의 관리 단위(줄여서 AU)는 테넌트라는 디지털 거리를 지키는 동네 순찰대장 같은 역할을 합니다. 사용자 기반을 나누고 세분화할 수 있으므로, 현지 관리자에게 담당 구역을 관리하는 데 필요한 만큼만 권한을 줄 수 있고, 도시 전체를 맡길 필요는 없습니다.

보안, 규정 준수, 효율성의 균형을 맞추려는 조직에는 중요한 발전입니다. 모든 관리자에게 동일한 관리 권한을 주는 대신, AU를 통해 알맞은 담당자가 알맞은 사용자를 관리하도록 할 수 있습니다. 이 이상도 이하도 아닙니다. 이어지는 내용에서는 AU가 그룹 및 기존 OU와 어떻게 다른지, 그리고 거버넌스를 엄격하게 유지하면서도 관리를 어떻게 수월하게 만들어 주는지 살펴보겠습니다. 역할 범위를 더 명확히 하고 싶든, 테넌트를 세분화하고 싶든, 단순히 혼선을 줄이고 싶든, Entra ID의 관리 단위를 이해하는 것은 충분히 시간을 들일 만한 가치가 있습니다.

Microsoft Entra ID의 관리 단위란 무엇인가요?

Microsoft Entra ID의 관리 단위(AU)는 대규모 정리 작업을 위해 설계된 특별한 컨테이너입니다. 디지털 경계라고 생각하시면 됩니다. 관리자를 이 경계에 할당하면, 해당 울타리 안에 있는 사용자나 그룹만 관리하도록 할 수 있습니다.

AU를 설정한 후에는 사용자 관리자나 헬프 데스크 관리자 같은 관리 권한을 해당 단위에 속한 사용자나 그룹에만 위임할 수 있습니다. 그러면 현지 IT 팀이 다른 곳을 기웃거리지 않고 자신들의 구성원에게만 집중할 수 있습니다. 모든 문을 한꺼번에 열지 않으면서 제어권을 분산하는 것이 핵심입니다.

이 방식은 학교, 다국적 기업, 정부 기관처럼 규모가 크거나 복잡한 조직에서 특히 유용합니다. 뉴저지에 있는 관리자가 도쿄 직원의 비밀번호 재설정을 처리하는 상황은 원치 않으실 것입니다. 말하자면 각자 맡은 구역을 정하고, 모두가 자기 역할을 지키도록 하는 것입니다.

온프레미스 Active Directory의 기존 OU와 달리 AU는 Microsoft 클라우드에만 존재하며, 관리 권한의 범위를 정하는 데 목적이 있습니다. 또한 보안 그룹이나 Microsoft 365 그룹과도 다릅니다. 이들 그룹은 주로 앱과 리소스 액세스에 사용되며 관리 권한을 위한 것이 아닙니다. 핵심은 AU를 통해 클라우드 테넌트 안에서 "누가 무엇을 관리할 수 있는지"를 정할 수 있다는 점이며, 이를 통해 더 정밀하고 안전한 관리가 가능합니다.

Azure 관리 단위가 그룹 및 OU와 다른 점

관리 단위(AU): 위임된 관리를 위해 설계되었습니다. AU 내의 특정 사용자 및 그룹에 대해 관리 역할의 범위를 지정하지만, 파일이나 사서함 같은 리소스에 대한 액세스 권한을 부여하지는 않습니다.
그룹: 앱 및 리소스 액세스(예: Teams, SharePoint, 라이선스 할당)에 사용됩니다. 그룹은 관리 경계를 제한하거나 정의하지 않으며, 권한 부여나 배포를 위한 구성원 관계만 나타냅니다.
조직 구성 단위(OU): 온프레미스 Active Directory의 개념으로, 그룹 정책 적용을 위해 개체(사용자, 컴퓨터)를 계층적으로 구성합니다. 클라우드나 Microsoft 365에서의 위임을 위해 설계되지 않았으며, Entra ID에 직접 대응하는 기능은 없습니다.

요약하면, 관리 범위를 지정할 때는 AU를, 액세스를 관리할 때는 그룹을, 온프레미스 조직 구성에는 OU를 사용하시기 바랍니다. 목적에 맞는 도구를 선택하시면 됩니다.

Microsoft 365를 위한 관리 단위 구현: 주요 시나리오

Microsoft 365 환경이 여러 국가, 부서 또는 규정 준수 영역에 걸쳐 있다면, 중앙의 단일 관리 팀만으로는 충분하지 않습니다. 관리 단위는 바로 이런 상황에서 빛을 발합니다. 통제력을 잃거나 정신없이 바빠지지 않으면서도 복잡한 구성을 관리할 수 있도록 도와줍니다.

관리 단위를 사용하면 필요한 만큼의 권한만 적절히 위임할 수 있으므로, 현지 팀이나 부서장이 필요한 곳에서 비밀번호 재설정이나 그룹 멤버십 관리를 직접 처리할 수 있습니다. 이처럼 테넌트를 세분화하면 누구도 필요 이상의 관리 액세스 권한을 갖지 않게 되므로, 생산성을 높이고 위험을 줄일 수 있습니다.

실제 현장에서는 어려움이 끊임없이 발생합니다. 예를 들어 학부별로 나뉜 대학, 여러 주에 매장을 둔 유통업체, 지역별 IT 팀을 둔 글로벌 기업 등이 있습니다. 관리 단위는 조직의 어느 영역을 누가 담당할지 정의하고, 내부 정책이 실제로 지켜지도록 하는 대표적인 방법이 됩니다.

아래에서는 이러한 단위를 도입할 때 가장 흔히 마주치는 시나리오와 결정 포인트를 하나씩 살펴보겠습니다. 이것이 왜 중요한지뿐만 아니라, 규정 준수, 최소 권한 액세스, 지역 자율성과 같은 일반적인 문제를 해결하는 데 어떻게 도움이 되는지도 확인하실 수 있습니다.

복잡한 관리 시나리오에서 관리 단위를 사용해야 하는 경우

지역별로 분산된 조직: 글로벌 테넌트에 접근하지 않고 해당 지역(예: 유럽, 아시아)의 사용자만 관리하도록 지역 IT 팀을 배정합니다.
부서별 분리: 인사, 재무, 학부 등에 관리 권한을 위임하고, 각 팀의 관리 권한을 자기 부서 범위 안으로 제한합니다.
규정 준수 또는 개인 정보 보호 경계: GDPR이나 HIPAA처럼 서로 다른 규정을 적용받는 사용자를 별도의 관리 단위로 분리하여 보안 경계를 적용합니다.
인수합병: 새로운 사업 부문이나 인수한 회사를 편입하고, 전체 환경에 대한 접근을 열지 않은 채 해당 조직이 자체적으로 관리하도록 합니다.
교육 기관 및 학군: 학교 관리자에게 해당 캠퍼스의 학생과 직원만 관리하도록 권한을 부여하여 다른 학교의 데이터에는 접근하지 못하도록 합니다.

Azure 관리 단위를 활용한 Microsoft 365 테넌트 분할 관리

분산형 관리: 관리 단위를 사용하면 지역 관리자에게 실제로 관리하는 사용자나 그룹에 대해서만 권한을 부여할 수 있습니다. 일상적인 작업에 전역 관리자 권한이 더 이상 필요하지 않습니다. 이는 “주방에 요리사가 너무 많은” 문제를 막는 데 도움이 됩니다.
명확한 보안 경계: 관리 단위로 테넌트를 분할하면 부서, 지역 또는 법인에 맞춘 경계를 설정할 수 있으며, 각 경계마다 적합한 관리 권한을 지정할 수 있습니다.
규정 준수 간소화: IT 팀이 자신의 범위에 속한 사용자만 보게 되므로 감사를 통과하고, 최소 권한 원칙을 적용하며, 데이터 노출 위험을 줄이기가 훨씬 수월해집니다.
간편한 문제 해결: 지역 관리자는 다른 팀의 데이터를 건드리지 않고도 암호를 재설정하거나 라이선스를 관리하고 멤버 자격을 조정할 수 있어 일상적인 관리가 더 원활해집니다.
거버넌스 전략 지원: RBAC, PIM, 정책 적용과 관련된 고급 전략을 찾고 계신다면, 실무 팁은 Azure 거버넌스 및 RBAC 모범 사례에 관한 이 글을 참고하세요.

Microsoft Entra ID에서 관리 단위를 설정하는 방법

Microsoft Entra ID에서 관리 단위를 도입하는 과정은 명확한 질문에서 시작합니다. 누구를 관리하고 싶은지, 그리고 누구에게 그 관리를 맡길 수 있는지를 먼저 정하는 것입니다. 이 구조가 정리되면 관리 단위를 설정할 때 먼저 단위 자체를 만들고, 적절한 사용자 또는 그룹을 추가한 다음, 적절한 수준의 제어 권한으로 관리자 역할을 할당하면 됩니다.

관리 단위는 Azure 포털에서 직접 만들 수 있으며, 단계별로 직관적인 흐름을 제공합니다. 규모가 크거나 변화가 잦은 조직이라면 Microsoft Graph API로 자동화 기술을 활용하여 스크립트가 반복 작업을 처리하도록 할 수 있습니다.

그다음에는 사용자를 적절한 관리 단위에 배치해야 합니다. 필요하면 한 명씩 추가하고, 대규모로 작업한다면 일괄 추가할 수 있습니다. 그룹 멤버 자격은 직접 또는 동적으로 관리할 수 있지만, 디바이스와 리소스(예: SharePoint 사이트)에는 몇 가지 제한이 있으며, 이는 곧 다시 짚어 보겠습니다.

마지막으로 기존 Azure AD 모델을 사용하거나, 필요할 때만 권한을 부여하고 감사 기능을 갖춘 권한 있는 ID 관리(PIM)를 통해 관리자 역할을 할당합니다. 다음 섹션에서는 각 단계를 자세히 다루므로, 이를 따라 하면 자신 있게 구축하고, 보호하고, 위임할 수 있을 것입니다.

Microsoft 365에서 관리 단위 만들기 및 구성하기

Azure 포털 접속: Microsoft Entra ID로 이동하여 관리 단위를 선택한 뒤 “+ 새 관리 단위”를 클릭하면 설정 과정이 시작됩니다.
이름 지정, 설명 추가 및 범위 선택: 관리 단위에 “APAC Sales Admins”처럼 명확하고 설명적인 이름을 지정합니다. 필요하다면 이후 관리자를 위해 설명을 추가합니다.
멤버 추가: 사용자나 그룹을 멤버로 직접 할당할 수 있습니다. 이 관리 단위에서 누구를 관리할지 결정하면, 관리자의 작업은 해당 사용자에게만 적용됩니다.
자동화 옵션: 코드 작업을 선호하신다면 Microsoft Graph API를 사용하여 일괄 또는 자동화된 워크플로에 맞게 관리 단위를 만들고, 업데이트하고, 관리할 수 있습니다. 스크립트를 사용하면 대규모 변경이 더 쉬워지고 오류도 줄어듭니다.
멤버 중복 확인: 범위를 엄격하게 제한하려면 관리 단위 간 멤버가 중복되지 않도록 하세요. 사용자는 특정 역할 컨텍스트에서 하나의 관리 단위에서만 관리될 수 있습니다.

관리 단위에 사용자 및 그룹 할당하기

직접 할당: Azure 포털에서 사용자 > 멤버 추가 경로를 통해 사용자나 그룹을 수동으로 추가하면, 해당 객체가 관리 단위의 관리 대상이 됩니다.
동적 그룹(제한 사항 있음): 동적 그룹을 AU 멤버로 추가할 수는 있지만, AU 자체는 현재 동적 규칙을 기본적으로 적용할 수 없습니다. 동적 그룹 규칙은 AU가 아니라 그룹에 존재합니다.
일괄 가져오기: 대규모 조직에서는 PowerShell 또는 Graph API를 사용하여 여러 사용자와 그룹을 효율적으로 할당하십시오. 시간을 절약하고 일관성을 유지할 수 있습니다.
구성원 정기 검토: 주기적인 점검을 설정하여 소유자가 없는 계정을 제거하고 사용자가 여전히 적절한 범위에 속해 있는지 확인하십시오. 조직 변화는 언제든 일어나므로 경계를 꾸준히 점검하십시오.
디바이스 포함 여부: 현재 노트북이나 휴대폰 같은 디바이스는 AU의 멤버가 될 수 없습니다. AU 관리 대상은 사람과 그룹으로 엄격히 제한되며, 하드웨어나 리소스는 포함되지 않습니다.

Privileged Identity Management로 관리자에게 역할 할당하기

AU별 역할 할당: AU 내부에서 User Administrator, Groups Administrator, Helpdesk Admin 같은 역할을 할당하면 위임된 관리자는 해당 AU 안에서만 권한을 행사할 수 있습니다.
PIM으로 JIT 액세스 활용: Azure AD의 Privileged Identity Management(PIM)를 사용하여 JIT(Just-in-Time) 관리자 액세스를 부여하십시오. 역할을 일시적으로 활성화할 수 있어 “상시 권한”으로 인한 위험을 줄일 수 있습니다.
승인 워크플로 운영: PIM 승인을 설정하여 관리자 액세스에 추가 승인이 필요하도록 하십시오. 규정 준수가 중요하거나 보안 수준이 높은 환경에서 매우 유용합니다.
액세스 모니터링 및 감사: 누가 언제 어떤 역할을 활성화했는지 계속 확인하십시오. 감사 로그를 Microsoft Sentinel에 연결하거나 Purview 감사를 사용하여 M365 전반의 사용자 활동을 포렌식 방식으로 추적하십시오. 이는 거버넌스를 강화하고 보안 체계를 더욱 탄탄하게 만들어 줍니다.
권한 할당 검토: 부여된 역할을 주기적으로 다시 확인하십시오. 오래되었거나 불필요한 권한을 제거하여 권한 누적을 방지하고 최소 권한 원칙을 강화하십시오.

관리 요구 사항, 라이선스 및 제한 사항

AU로 테넌트를 나누기 시작하기 전에 고려해야 할 사전 요구 사항과 제약이 있습니다. Microsoft 365 구독 유형에 따라 제공되는 기능이 다르며, AU를 사용하려면 대상 사용자와 할당된 관리자 모두에게 최소한 Azure AD Premium P1 라이선스가 필요합니다.

AU는 사용자와 그룹 관리에는 충실하지만, 디바이스, SharePoint 사이트 또는 기타 리소스 관리에서는 한계를 드러냅니다. AU는 현재 하드웨어 관리나 세분화된 리소스 액세스 할당을 위해 설계되지 않았습니다. 라이선스 할당과 일부 속성 관리 기능에도 제한이 있어, 대규모 또는 변화가 잦은 환경에서는 별도의 우회 방법이 필요할 수 있습니다.

계층 구조도 걸림돌입니다. 기존 Active Directory의 OU와 달리 AU는 평면 구조이므로 중첩이나 상하위 관계가 없습니다. 따라서 이러한 계층 구조 없이 세분화를 설계해야 합니다. 이것을 복잡성이 줄어든 것으로 볼지, 유연성이 줄어든 것으로 볼지는 관점에 따라 다릅니다.

아래 세부 내용을 살펴보면 AU의 기능적 경계를 이해하게 되며, 이를 바탕으로 IT 담당자와 현업 이해관계자 모두에게 현실적인 기대치를 설정할 수 있습니다.

주요 관리 제한 사항: 계층 구조, 디바이스 및 SharePoint

계층 구조 없음: AU는 평면 구조입니다. 중첩이나 상위/하위 조직 개념이 없습니다. 예를 들어 “북미” AU 아래에 주(State) 또는 지역별 하위 AU를 만들 수는 없습니다. 각 AU는 독립적으로 존재합니다.
디바이스 관리 공백: 노트북, 휴대폰, 프린터 같은 디바이스는 AU로 직접 관리할 수 없습니다. 디바이스 수준의 범위 지정이 필요하다면 다른 솔루션이나 Intune 정책이 필요할 수 있습니다.
SharePoint/OneDrive 제한: AU는 SharePoint 사이트나 OneDrive에 대한 관리 권한의 범위를 지정하지 않습니다. 해당 앱의 데이터 거버넌스는 별도의 전략이 필요하며, 복잡한 데이터 요구 사항에는 Microsoft Dataverse 같은 대안을 고려해야 합니다.
라이선스 할당의 어려움: AU 내부 사용자에게 라이선스를 할당할 수는 있지만, AU 범위의 자동화 기능이 기본 제공되지 않아 대규모로 자동화하기가 더 어렵습니다.
속성 관리: AU 내 사용자 속성의 일괄 업데이트나 보고 기능은 제한적입니다. 이러한 공백을 메우려면 외부 도구, PowerShell 또는 Graph API가 필요한 경우가 많습니다.

administrative unit의 보안, 거버넌스 및 대안

보안과 거버넌스는 AU 설정으로 끝나지 않습니다. 테넌트(그리고 조직의 평판)를 보호하려면 AU를 어떻게 관리할지, 누구에게 위임 권한을 줄지, 그리고 특권 액세스를 시간이 지나면서 어떻게 모니터링하고 검토하고 회수할지까지 고민해야 합니다.

모범 사례로는 최소 권한 원칙을 적용하고, PIM과 연계한 승인 워크플로를 활용하며, 모든 역할 할당을 감사하는 것이 있습니다. 지속적인 모니터링도 놓치지 마십시오. 특권 액세스 검토, 비정상 활동에 대한 경고, 주기적인 보고를 통해 실제로 누가 환경을 운영하고 있는지 더 확실하게 파악할 수 있습니다.

일부 조직에서는 아무리 정교하게 설계한 AU라도 충분하지 않을 수 있습니다. 다단계 세분화, 더 강력한 규정 준수 통제, 또는 고도화된 자동화가 필요할 수도 있습니다. 이런 경우에는 CoreView 가상 테넌트와 같은 대안 솔루션이 필요해집니다. AU로는 아직 구현할 수 없는 방식으로 테넌트를 나눌 수 있기 때문입니다.

정책 적용, RBAC, 자동화된 가드레일 등 빈틈없는 거버넌스를 구현하는 방법을 더 자세히 알고 싶다면 Azure 거버넌스 전략 분석을 확인해 보십시오. AI나 자동화를 고민 중이라면 Copilot 및 Graph 권한 보안 문서도 꼭 읽어 보시기 바랍니다. 코파일럿과 봇이 확산된 환경에서 규정 준수를 유지하는 데 필수적인 내용입니다.

남아 있는 보안 위험과 가상 테넌트 대안

권한 누적(Privilege Creep): 관리자 권한을 검토하지 않으면 이전 관리자나 이직한 사용자가 '좀비' 권한을 계속 보유하게 될 수 있으며, 이는 가장 대표적인 내부 위험 중 하나입니다. 정기적인 검토와 권한 회수가 필수입니다.
감사 및 가시성 격차: 기본 감사 로그만으로는 어떤 AU 안에서 누가 무엇을 변경했는지 쉽게 파악하기 어려울 수 있습니다. 엔터프라이즈 수준의 감독을 위해서는 Entra 로그를 SIEM 도구와 연결하거나, Microsoft Purview 또는 Sentinel을 활용해 강력한 모니터링과 규정 준수 보고서를 확보하십시오. Agentageddon 같은 에피소드에서는 Microsoft 365에서 AI와 거버넌스에 대한 감사가 뒤처질 때 발생하는 위험을 설명합니다.
범위 제약: AU는 클라우드 간 또는 하이브리드 환경을 기본적으로 세분화할 수 없습니다. 하이브리드 또는 멀티 클라우드 환경이라면 더 깊은 경계와 중앙 집중식 거버넌스를 위해 서드파티 도구나 가상 테넌트 솔루션을 검토하십시오.
대안을 고려해야 할 때: AU가 제공할 수 있는 범위를 넘어 다단계 세분화, 규정 준수 매핑, 고급 워크플로 자동화가 필요하다면 CoreView 가상 테넌트와 같은 솔루션을 고려하십시오. 섀도 IT와 AI에는 고도화된 모니터링이 필요합니다. 더 많은 아이디어는 Microsoft Foundry 및 Purview 필수 요소 분석을 참고하십시오.

함께 들으면 좋은 에피소드

Microsoft Entra 관리 단위를 조사 중이라면, 아래 에피소드에서 ID 보안, 거버넌스, 특권 액세스, 구현에 대한 실무적인 맥락을 얻을 수 있습니다.

Microsoft Defender XDR – Simply Explained — ID 거버넌스를 보안 신호, 조사, 대응과 연결하는 방법을 살펴봅니다.
Conditional Access – Simply Explained — 정책 기반 액세스 제어가 ID 결정을 어떻게 강제하는지 알아봅니다.
Privileged Identity Management – Simply Explained — just-in-time 권한, 승인, 액세스 검토의 개념을 이해합니다.
Microsoft Teams Governance – The Illusion of Control — 권한과 소유권을 반복 가능한 운영 절차로 전환하는 거버넌스 방식을 살펴봅니다.