Intune는 여전히 장치의 베어메탈 이미지를 만들 수 없으며, IT에 아무도 말하지 않은 다른 사항들

명령은 IT가 아니라 리더십에서 나왔습니다

현재 하이브리드 환경을 관리하는 거의 모든 관리자는 같은 질문을 들어본 적이 있습니다: "왜 아직 Intune으로 완전히 이전하지 않았나요?" 이는 보통 지체의 원인이 관성 때문이거나, 오래된 도구에 익숙하고 새로운 도구를 배우기 꺼려하는 IT 팀이 있다는 암묵적인 가정을 동반합니다.

그렇지 않습니다. Intune을 그룹 정책의 완전한 대체제로 몇 달간 테스트한 관리자들은 그룹 정책에 대해 같은 결론에 도달하고 있습니다: Intune은 아직 준비가 되지 않았습니다. 강점이 분명 있지만, 그룹 정책의 1:1 대체제로서는 아직 부족합니다.

Intune가 아직 하지 못하는 것

베어 메탈 이미징 없음.

그룹 정책과 작업 시퀀싱을 결합하면 관리자가 장치를 초기화하고 재부팅이 필요한 복잡한 다단계 설치를 포함하여 처음부터 깨끗한 운영 체제를 다시 로드할 수 있습니다. Autopilot은 이를 대체하지 않습니다. 이미 운영 체제가 설치된 장치를 프로비저닝합니다. 관리자는 작업 시퀀스와 같은 기능이 없어 제조사 불필요 소프트웨어가 포함된 "깨끗한" 장치를 최종 사용자에게 배송한다고 보고합니다.

서버는 범위에 포함되지 않았으며, 괜찮습니다.

Intune은 클라이언트 장치를 관리합니다. Windows Server 관리를 위해 만들어진 것이 아니므로 조건부 액세스 정책 및 규정 준수 강제는 의도적으로 워크스테이션에서 중단됩니다. 이는 로드맵의 구멍이 아니라 의도적으로 그어진 경계입니다.

이것이 실제로 거의 문제가 되지 않는 이유는 하이브리드 환경이 이미 다른 곳에서 서버 관리를 처리하고 있기 때문입니다. SCCM은 여전히 온프레미스 Windows Server 패치 및 베어 메탈 빌드를 처리합니다. Azure Arc는 서버가 어디에 있든 온프레미스든 다른 클라우드든 정책 및 규정 준수 적용을 확장합니다. VMware vSphere는 템플릿 및 클로닝을 통해 프로비저닝 및 이미징을 처리합니다. Ansible(또는 AWX Tower)은 이전에 그룹 정책이 담당했던 지속적인 구성 적용을 수행합니다. 여기에는 빠진 것이 없으며, 대부분의 인프라 팀이 이미 사용하는 몇 가지 도구에 분산되어 있을 뿐입니다.

덜 계층적이고, 더 많은 우회 방법.

Active Directory의 OU 구조는 관리자가 부서, 위치 또는 장치 계층별로 비즈니스가 어떻게 조직되는지 반영할 수 있게 하며, 예외를 깔끔하게 중첩하고 모든 수준에서 관리자 권한을 위임할 수 있습니다. Entra ID 그룹도 중첩할 수 있지만, Microsoft의 자체 지침은 이를 권장하지 않습니다: 큰 그룹을 Intune 대상 안에 중첩하면 Intune이 그 아래 모든 그룹과 구성원을 다시 동기화하도록 강제하여 작은 예외가 깔끔한 상속 모델이 아닌 성능 문제로 바뀌게 됩니다.

할당 필터와 범위 태그는 OU 기반 위임이 하던 일부 기능을 수행하여 완전한 중첩 없이 가시성과 타겟팅 범위를 지정합니다. 둘 다 진정한 상속을 재현하지는 않지만, 위임 스타일의 제어는 처음 보기보다 더 가깝습니다.

Intune에서는 여전히 동적 그룹화가 존재하지만, 그룹 정책 관리자들이 익숙한 것보다 범위가 좁습니다. Entra ID 동적 디바이스 그룹은 제조사 및 모델과 같은 속성으로 필터링할 수 있으며, Intune 할당 필터는 여기에 OS 버전 및 CPU 아키텍처와 같은 디바이스 속성을 추가합니다. 현재 Intune에는 그룹 정책 환경에서 자주 사용하는 설치된 소프트웨어 기반의 동적 그룹화 또는 필터링 기능이 없습니다.

더 가까운 범위지만 완전하지는 않습니다.

그룹 정책은 약 4,000개의 ADMX 설정을 지원합니다. Intune의 설정 카탈로그는 이제 모든 플랫폼에서 18,000개 이상의 설정을 포함하며, 관리 템플릿만 해도 GPO에서 직접 가져온 것으로 약 2,500개에 달합니다. 단순한 숫자가 더 이상 핵심이 아닙니다. 남은 것은 아직 Intune에서 깔끔한 대응이 없는 특정 GPO 동작들입니다: 그룹 정책 환경 설정, 일부 레거시 스크립트 기반 구성, 그리고 Intune의 CSP 기반 모델이 아직 노출하지 않는 기능에 의존하는 설정들입니다. 이 격차는 스크립트와 수동 구성 프로필로 채워지며, 이전에 체크박스였던 것을 수작업으로 재구성하는 방식입니다.

그룹 정책 기본 설정에는 고정된 위치가 없습니다.

매핑된 드라이브, 프린터 연결 및 GPP가 자동으로 처리하던 수십 가지 작은 환경 설정은 이제 스크립팅 또는 타사 도구를 사용해야 복제할 수 있습니다.

느리고 예측할 수 없는 정책 적용.

그룹 정책이 몇 초 만에 변경 사항을 적용하는 반면, Intune은 Windows 알림 서비스를 통해 정책을 장치에 전달하며, 이 파이프라인은 사실상 블랙박스입니다. 관리자는 동일한 정책에 대해 즉시부터 72시간까지 다양한 동기화 시간을 문서화했으며, 마감일이 실제일 때 이를 강제로 적용할 신뢰할 수 있는 방법이 없습니다.

문제 해결이 따라잡고 있지만 아직 완료되지 않았습니다.

그룹 정책에는 RSoP와 gpupdate가 있으며, 이는 "왜 적용되지 않는가"를 몇 분 만에 답할 수 있도록 특별히 제작된 도구입니다. Intune에는 이제 대략적인 동등 기능이 있습니다: 동기화는 요청 시 정책 확인을 강제하며, 설정별 정책 상태는 어떤 정책이 장치에 적용되었고 그 이유를 보여줍니다. Intune의 Copilot은 여기에 오류 코드 분석기와 나란히 장치 비교 기능을 추가하며, 2026년 중반부터는 Microsoft 365 E5에 포함되어 별도의 라이선스가 필요 없습니다.

아직 부족한 것은 개념이 아니라 성숙도입니다. 이 도구들은 더 새롭고, 관리자들은 기본적인 것 이상에서는 일관되지 않은 결과를 보고합니다. "왜 적용되지 않는가"에 대한 그룹 정책의 20년 우위는 완전히 사라지지 않았지만, 격차는 보이는 것보다 좁습니다.

네이티브 대역폭 제어 없음.

그룹 정책 환경에서 SCCM을(를) 실행하는 경우 BranchCache 또는 PeerCache를 사용하여 단일 사이트가 느린 WAN 링크를 반복적으로 동일한 콘텐츠를 다운로드하여 과부하하지 않도록 배포를 예약할 수 있습니다. Intune은 장치별로 인터넷에서 가져오며, 사이트 전체에 부하를 분산시키는 피어 투 피어 캐싱이 없습니다. 대역폭이 제한된 위치에서는 배포가 느려지고 경우에 따라 기본적인 해결책 없이 완전한 실패가 발생할 수 있습니다.

원시 SID 및 타사 도구가 필요한 애플리케이션 제어.

그룹 정책 환경에서 AppLocker로 처리하는 세밀한 애플리케이션 허용 목록은 Intune에서 더 어려운 작업입니다. 보안 주체를 참조할 때는 친숙한 이름 대신 원시 SID를 지정하는 경우가 많으며, Windows 업데이트 외의 타사 패치는 별도의 도구가 필요합니다.

클라우드 우선이라면 Intune이 적합합니다

이 모든 것이 Intune이 나쁜 제품이라는 뜻은 아닙니다. Intune은 간단하고 클라우드 우선 환경에 진정으로 적합합니다. 마이크로소프트의 월간 OS 업데이트 제공 인프라는 훌륭합니다. 문제는 더 좁고 구체적입니다: 그룹 정책이 하던 모든 것을 완전히 대체하는 제품으로서 Intune은 아직 완성되지 않았으며, 그렇지 않은 척 하는 것은 문제를 로드맵 슬라이드에서 헬프 데스크 대기열로 옮기는 것뿐입니다.

바로 그래서 많은 조직들이 Intune 도입을 "몇 년 더 하이브리드"라고 표현하지 "완료"라고 표현하지 않는 것입니다. 이는 인력 문제 가 아니라 도구의 공백 문제입니다. Netwrix PolicyPak 이 그 공백을 메우기 위해 만들어졌습니다.

PolicyPak이 Group Policy가 이미 잘하는 기능을 확장하는 방법

PolicyPak은 팀에게 그룹 정책을 제거하고 처음부터 다시 시작하라고 요구하지 않습니다. 이미 구축된 인프라 위에 위치하며 도메인에 가입되었든 원격이든 Intune에 이미 등록되었든 모든 엔드포인트에 동일한 정책 논리를 확장합니다.

• 전체 ADMX 깊이, 부분집합이 아님: 관리 템플릿 관리자는 ADMX 기반이므로 그룹 정책이 지원하는 수천 개의 세분화된 설정이 스크립트로 수작업 재구성되지 않고 그대로 유지됩니다.
• 그룹 정책 기본 설정, 여전히 자동화됨: GPP 관리자는 매핑된 드라이브, 프린터 및 기타 기본 설정을 계속 처리하여 데스크톱을 조용히 일관되게 유지하며 스크립팅이 필요하지 않습니다.
• 실제 계층 구조 및 통합: 확장된 GPO가 통합되어 불필요한 중복을 줄이고 성능을 향상시키면서 관리자가 이미 이해하고 있는 OU 기반 타겟팅 모델을 유지합니다.
• 적용을 입증하는 컴플라이언스 보고: 그룹 정책 컴플라이언스 보고는 팀이 환경 전반에 걸쳐 적용되는 내용을 보여줄 수 있는 방법을 제공하며, 단순히 구성된 내용뿐만 아니라 감사나 화요일 오후 문제 해결 세션에 모두 중요한 사항입니다.
• 도메인이 아닌 엔드포인트를 따르는 적용 범위: 도메인 컨트롤러에 접속하지 않는 장치의 경우, PolicyPak Cloud와 GPO Export Manager는 Intune 또는 기타 MDM 및 UEM 플랫폼을 통해 관리되는 엔드포인트에 동일한 정책을 적용합니다. Intune에 등록된 원격 노트북은 도메인에 가입된 사무실에 있는 컴퓨터와 동일한 최소 권한 규칙과 데스크톱 구성을 받습니다.
• 엔드포인트를 위해 구축된 보안 제어: 로컬 관리자 권한은 제거되며, 일반 사용자는 여전히 안전하고 특정한 권한 상승 경로를 제공합니다. 파일 소유자 기반 허용 목록은 단일 정책으로 신뢰할 수 없는 애플리케이션과 스크립트를 차단하며, DLL 하이잭 보호는 오래된 데스크톱 소프트웨어에서 흔한 취약점 유형을 해결합니다. 애플리케이션, 브라우저, 자바, 이동식 장치 제어가 전체 범위를 완성하며 모두 하나의 콘솔에서 관리됩니다.
• 간소화된 배포 및 패치: 소프트웨어 배포, 자동 패치 및 제거가 Windows, WinGet 및 웹 기반 소스 전반에서 실행되어 Intune이 Windows 업데이트에만 남겨둔 타사 패치 공백을 메웁니다.
• Windows 전용이 아닌 최소 권한: 최소 권한 관리자는 관리자 승인 및 폴더 권한 제어를 Windows뿐만 아니라 Mac에도 확장하여 하이브리드 엔드포인트 환경이 Windows 도구와 별도의 Mac 프로세스 대신 하나의 콘솔에서 최소 권한 관리를 받을 수 있도록 합니다.

PolicyPak이 되려고 하지 않는 것

경계에 대해 직접 말하자면: PolicyPak은 베어 메탈 이미징이나 작업 시퀀싱을 수행하지 않으며, 현재 OSD를 처리하는 도구를 대체하지 않습니다. PolicyPak이 하는 일은 장치가 존재하게 되면, 이미지가 생성되었든, Autopilot을 통해 등록되었든, Intune을 통해 등록되었든, 동일한 정책 엔진과 팀이 이미 신뢰하는 동일한 깊이 수준을 사용하여 구성되고 잠금 설정되며 보고 가능하도록 하는 것입니다.

팀은 그룹 정책의 성숙도와 Intune의 범위 중에서 선택할 필요가 없습니다. PolicyPak은 20년 동안 구축된 계층 구조, 세분성 및 보고 깊이를 유지하며, 이제 Intune이 관리하는 모든 엔드포인트로 확장합니다. 현재 환경에 어떻게 맞는지 확인하세요.