그룹 정책에서 Intune으로 ── 중소기업의 디바이스 관리 이전 가이드

「서버 보수 기한이 닥쳐 교체를 계획하고 있다. 그런데 AD 서버를 다시 사서 도메인과 그룹 정책을 한 주기(5년) 더 이어가야 하는지, 자신이 없어졌다」「재택 근무 노트북에 사내에서 정한 그룹 정책이 아무리 기다려도 적용되지 않는다. VPN에 연결했을 때만 적용되는 상태라면, 관리하고 있다고 말하기 어렵지 않은가」── 지난 몇 년, 중소기업 고객에게서 이런 상담이 꾸준히 늘고 있습니다.

배경에는 일하는 방식의 변화가 있습니다. 온프레미스 Active Directory(AD)와 그룹 정책(GPO)은 「PC는 사내 LAN에 있고, 도메인 컨트롤러에 언제든 도달한다」는 전제 위의 구조입니다. 반출 PC와 재택 근무가 당연한 지금은, 그 전제 쪽이 무너졌습니다. 여기에 더해, 업데이트 관리의 정석이던 WSUS가 2024년 9월에 deprecated가 되었고¹, Microsoft의 디바이스 관리 무게 중심은 Entra ID+Intune(MDM)으로 옮겨 가고 있습니다.

flowchart TB
    accTitle: 전제의 붕괴와 관리 무게 중심의 이동
    accDescr: AD와 GPO는 PC가 사내 LAN에 있고 도메인 컨트롤러에 언제든 도달한다는 전제 위의 구조이지만, 반출 PC와 재택 근무가 일상화되면서 그 전제가 무너졌고, WSUS의 deprecated와 함께 관리의 무게 중심은 Entra ID와 Intune으로 옮겨 가고 있다
    adgpo["온프레미스 AD와 GPO"] -.-> premise["전제는 DC에 언제든 도달하는 것"]
    work["반출 PC와 재택의 일상화"] --> broken["전제 쪽이 무너졌다"]
    premise --> broken
    wsus["WSUS가 deprecated"] --> shift["무게 중심은 Entra ID+Intune으로"]
    broken --> shift

그림 1: AD+GPO의 「PC는 사내 LAN에 있다」는 전제가 일하는 방식의 변화로 무너졌고, 관리의 무게 중심은 Entra ID+Intune으로 옮겨 갔다.

그렇다고 이전이 「전부 아니면 전무」는 아닙니다. Entra join+Intune으로 관리하는 PC와 AD 도메인 조인+GPO PC는 같은 사내에서 공존할 수 있고², 파일 서버 때문에 AD를 남겨 둔 채 신규 PC부터 Intune 관리로 바꿔 가는 단계적 이전이 가능합니다. 이 글에서는 중소기업의 정보시스템 담당자와 경영자를 대상으로, GPO와 MDM의 구조 차이, 전제가 되는 구성, 라이선스, 현재 GPO를 파악하는 방법, 단계적 이전 시나리오, 막히는 지점까지를 2026년 8월 시점의 Microsoft Learn 등 1차 정보를 바탕으로 정리합니다.

1. 먼저 결론

• GPO는 도메인 네트워크에 연결했을 때 적용되고, Intune(MDM)은 인터넷을 통해 동기화합니다. 「재택 PC에 설정이 도달하지 않는다」는 문제는 MDM에서는 구조적으로 생기지 않습니다. 정상 상태의 동기화는 대략 8시간마다이며, 정책 변경 시에는 알림에 의한 동기화도 돌아갑니다.³
• 이전은 「전부 아니면 전무」가 아니라, 공존을 전제로 한 단계적 이전이 현실적인 답입니다. Microsoft 스스로 신규 PC는 Entra join, 기존 도메인 조인 PC는 hybrid join인 채로 교체 주기에서 바꾸라고 권합니다.²
• Intune은 단독 계약도 가능하지만, 중소기업에서는 Microsoft 365 Business Premium에 Intune Plan 1이 포함된 형태로 쓰는 편이 현실적입니다(2026년 8월 시점). 플랜 구성은 계속 바뀌므로 계약 전에 반드시 1차 정보를 확인하십시오.⁴⁵
• 현재 GPO의 현황 파악에는 Intune 기본 제공 Group Policy analytics를 씁니다. GPO의 XML 내보내기를 가져오면 설정마다 이전 가능 여부가 분류되고, 대응 가능한 설정은 설정 카탈로그 정책으로 변환할 수 있습니다.⁶
• GPO 시절의 주요 업무는 거의 Intune에 대응물이 있습니다. 관리용 템플릿에 해당하는 것은 설정 카탈로그⁷, WSUS는 Windows Update for Business, BitLocker 복구 키는 Entra ID 저장⁸, 로컬 관리자 암호는 Windows LAPS⁹, 앱 배포는 Win32 앱(.intunewin)¹⁰과 Microsoft Store 앱(winget 기반)¹¹입니다.
• 그대로 옮기지 못하는 대표 사례는 로그온 스크립트·드라이브 매핑·프린터 배포입니다. PowerShell 스크립트 배포¹², Remediations(구칭 Proactive remediations)¹³, 앱으로 만들기, 또는 「그 운영을 그만두는」 쪽으로 대체합니다.
• 같은 설정을 GPO와 MDM 양쪽에서 배포하지 마십시오. 기본값에서는 충돌 시 GPO가 이깁니다. MDMWinsOverGP를 1로 두면 MDM이 이기지만, 적용되는 것은 Policy CSP 설정뿐입니다.¹⁴
• 도메인 조인 기기와 Entra join 기기는 공존할 수 있고, Entra join 기기에서 온프레미스 파일 서버로의 접근도 가능합니다. AD의 즉시 폐기는 이전의 조건이 아닙니다.²

한 문장으로 정리하면, 「AD 서버를 한 주기 더 교체할 것인가」라는 질문은 「앞으로 5년, 사외에 있는 PC를 무엇으로 관리할 것인가」라는 질문으로 바꿔 판단해야 합니다.

flowchart LR
    accTitle: 판단해야 할 질문의 교체
    accDescr: AD 서버를 한 주기 더 교체할 것인가라는 질문은, 앞으로 5년 사외에 있는 PC를 무엇으로 관리할 것인가라는 질문으로 바꿔 판단한다
    q1["AD 서버를 한 주기 더 교체?"] -->|교체| q2["다음 5년 사외 PC를 무엇으로 관리?"]

그림 2: 서버 교체의 질문은 「앞으로 5년, 사외에 있는 PC를 무엇으로 관리할 것인가」로 바꿔 판단한다.

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 20건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. GPO와 MDM은 무엇이 다른가 ── 적용 구조를 비교한다

먼저 둘을 같은 기준으로 비교합니다. GPO의 구조 자체(LSDOU 적용 순서, gpupdate/gpresult로 확인하는 방법)는 「그룹 정책(GPO) 실무 입문」에서 자세히 다루므로, 여기서는 이전 판단에 영향을 주는 차이로 좁힙니다.

이전 판단에서 가장 중요한 것은 1행과 3행입니다. GPO가 재택 PC에 도달하지 않는 것은 장애가 아니라, 「PC는 도메인 컨트롤러에 도달하는 장소에 있다」는 설계 전제가 지금의 일하는 방식과 맞지 않게 된 것입니다. VPN 상시 연결을 전 직원에게 강제해 GPO를 연장하는 길도 있지만, 그것은 VPN 기반이라는 다른 인프라 유지를 떠안는 선택이기도 합니다.

flowchart TB
    accTitle: GPO 연장인가 MDM 이전인가의 선택
    accDescr: GPO가 재택 PC에 도달하지 않는 것은 설계 전제가 지금의 일하는 방식과 맞지 않게 된 때문이며, VPN 상시 연결을 강제해 GPO를 연장하는 길은 VPN 기반이라는 다른 인프라 유지를 떠안는 선택이 된다
    gap["설계 전제가 일하는 방식과 맞지 않음"] --> sel{"어떻게 대응할 것인가?"}
    sel -->|VPN 상시 연결로 연장| vpn["GPO를 계속"]
    sel -->|MDM으로 이전| mdm["인터넷을 통해 관리"]
    vpn --> cost["다른 인프라 유지를 떠안음"]

그림 3: VPN 상시 연결로 GPO를 연장하는 길은, VPN 기반이라는 다른 인프라 유지를 떠안는 선택이기도 하다.

한편 MDM의 동기화 간격(약 8시간)은 GPO의 주기 업데이트(약 90분)보다 거칠어, 「배포하면 바로 적용된다」는 감각은 통하지 않습니다. 정책의 할당이나 변경 시에는 단말에 알림이 가서 비교적 빠르게 동기화되지만³, 즉시성이 필요한 통제(긴급 차단 등)는 동기화 간격을 전제로 설계해야 합니다.

flowchart TB
    accTitle: GPO와 MDM의 정책 적용 경로
    accDescr: GPO는 사내 도메인 컨트롤러에 연결했을 때만 적용되므로 재택 PC는 VPN 의존이 되지만, Intune은 인터넷을 통해 대략 8시간마다 동기화하고 정책 변경 시에는 알림으로도 동기화하므로 장소를 가리지 않고 도달한다
    officepc["사내 PC"] -->|기동·사인인 시와 주기 업데이트| dc["도메인 컨트롤러"]
    homepc["재택 PC"] --> vpn{"VPN으로 DC에 도달하는가?"}
    vpn -->|예| dc
    vpn -->|아니오| miss["최신 정책이 도달하지 않음"]
    anypc["어디에 있는 PC든"] -->|약 8시간마다 동기화| intune["Intune 서비스"]
    intune -.-> notify["정책 변경 시에는 알림으로 동기화"]

그림 4: GPO는 도메인 컨트롤러에 도달할 때만 적용되고, Intune은 인터넷을 통해 장소를 가리지 않고 동기화한다.

3. 전제의 정리 ── 도메인 조인·hybrid join·Entra join의 세 형태

Windows PC의 「회사에 참여하는 방식」에는 세 형태가 있고, 어느 것을 고르느냐에 따라 쓸 수 있는 관리 수단이 정해집니다.²

hybrid join은 「기존 도메인 조인 PC에 클라우드 신분증을 갖게 하는」 형태이며, 기존 자산을 살리면서 Intune이나 조건부 액세스를 쓰기 시작할 수 있습니다. 다만 Microsoft는 hybrid join을 최종 목표로 두지 말고, 신규·교체 PC는 Entra join으로 할 것을 권합니다.²

여기서 잡아 둘 제약이 하나 있습니다. 기존 도메인 조인 PC(hybrid join 포함)를 Entra join으로 변환하는, Microsoft 지원 대상 수단은 존재하지 않으며, Windows 리셋(와이프)이 필요합니다. 그래서 Microsoft도 하드웨어 갱신이나 OS 교체 타이밍에 맞춰 Entra join으로 옮기라고 권합니다.²

flowchart TB
    accTitle: 세 가지 조인 형태와 이전 경로
    accDescr: AD 도메인 조인만인 PC는 Entra ID에도 등록해 hybrid join으로 만들 수 있지만, Entra join으로 직접 변환하는 수단은 없고 와이프가 필요하므로, 신규·교체 PC를 Entra join으로 하는 것이 권장된다
    adonly["AD 도메인 조인만（GPO）"] -->|Entra ID에도 등록| hybrid["hybrid join（GPO와 Intune）"]
    hybrid -.->|직접 변환 수단 없음| wipe["와이프（리셋）가 필요"]
    wipe --> entra["Entra join（Intune）"]
    newpc["신규·교체 PC"] -->|권장| entra

그림 5: 기존 도메인 조인 기기를 Entra join으로 변환하는 정식 수단은 없고, 신규·교체 PC부터 전환하는 것이 정석이다.

이상에서 중소기업의 현실적인 목표는 이렇게 둘 수 있습니다.

1. 신규·교체 PC는 Entra join+Intune으로 관리한다
2. 기존 도메인 조인 PC는 무리하게 손대지 않고, 교체 주기에서 자연스럽게 바꾼다
3. AD는 파일 서버 인증 등 남은 역할 때문에 당분간 남기고, GPO의 내용만 단계적으로 비워 간다

flowchart TB
    accTitle: 단계 이전 중의 공존 구성
    accDescr: Entra join 기기와 도메인 조인 기기는 같은 사내 환경에서 공존할 수 있고, 전자는 Intune, 후자는 GPO로 관리하면서, AD는 남은 역할 때문에 당분간 남겨 GPO의 내용만 단계적으로 비워 간다
    env["같은 사내 환경"] --> ejoin["Entra join 기기"]
    env --> djoin["도메인 조인 기기"]
    ejoin --> intune["Intune으로 관리"]
    djoin --> gpo["GPO로 관리"]
    gpo -.-> shrink["내용을 단계적으로 비움"]
    env -.-> ad["AD는 남은 역할 때문에 남김"]

그림 6: Entra join 기기와 도메인 조인 기기는 같은 사내 환경에서 공존할 수 있고, AD는 남은 역할 때문에 당분간 남긴다.

Entra join 기기와 도메인 조인 기기는 같은 환경에서 공존할 수 있고, Entra join 기기에서 온프레미스 파일 서버 등 사내 자산에 접근하는 것도 가능합니다.² 다만 이 싱글 사인온에는 전제가 두 가지 있습니다. ①사용자가 Entra Connect(또는 Cloud Sync)로 온프레미스 AD에서 동기화된 하이브리드 ID일 것(클라우드에만 존재하는 사용자는 AD의 Kerberos/NTLM 자격 정보를 얻을 수 없습니다), ②PC에서 도메인 컨트롤러로 네트워크상 도달할 수 있을 것(사외에서는 VPN 등이 필요)입니다.¹⁵ 이전 계획에서는 이 두 가지를 충족하지 않는 사용자·이용 장면이 없는지를 먼저 확인하십시오.

flowchart TB
    accTitle: Entra join 기기에서 온프레미스 자산으로의 SSO 전제
    accDescr: Entra join 기기에서 온프레미스 파일 서버에 접근하려면, Entra Connect 등으로 동기화된 하이브리드 ID일 것과 도메인 컨트롤러에 도달할 수 있을 것 두 가지 전제를 충족해야 한다
    pc["Entra join 기기"] --> cond1{"하이브리드 ID인가?"}
    cond1 -->|예| cond2{"DC에 도달할 수 있는가?"}
    cond1 -->|아니오| ng1["AD 자격 정보를 얻지 못함"]
    cond2 -->|예| ok["파일 서버로 SSO"]
    cond2 -->|아니오| ng2["사외에서는 VPN 등이 필요"]

그림 7: Entra join 기기에서 온프레미스 자산으로의 SSO에는 하이브리드 ID와 도메인 컨트롤러에의 도달이라는 두 가지 전제가 있다.

4. 라이선스와 비용 ── Intune은 어느 플랜에 포함되는가(2026년 8월 시점)

Intune의 기본 라이선스는 Microsoft Intune Plan 1이며, 단독 구독으로도, 각종 Microsoft 365 플랜에 포함되어도 제공됩니다.⁴

중소기업에 중요한 것은 최대 300사용자까지의 Microsoft 365 Business Premium에 Intune Plan 1이 포함된다는 점입니다.⁵ Business Premium에는 Microsoft Entra ID P1과 Microsoft Defender for Business도 들어 있어, 뒤에서 다루는 규정 준수 정책+조건부 액세스 구성까지 이 플랜 안에서 완결됩니다. 한편 Business Standard/Basic에는 Intune이 포함되지 않습니다. 메일과 Office만의 계약에서 디바이스 관리로 발을 들이는 경우, Business Premium으로의 업그레이드 비용이 실질적인 Intune 도입 비용이 됩니다.

flowchart TB
    accTitle: 중소기업용 플랜과 Intune의 관계
    accDescr: 최대 300사용자까지의 Business Premium에는 Intune Plan 1과 Entra ID P1과 Defender for Business가 포함되어 조건부 액세스까지 완결되지만, Business Standard/Basic에는 Intune이 포함되지 않는다
    bp["Business Premium"] -.-> cap["최대 300사용자"]
    bp --> intune["Intune Plan 1"]
    bp --> p1["Entra ID P1"]
    bp --> dfb["Defender for Business"]
    p1 --> ca["조건부 액세스까지 완결"]
    dfb ~~~ std["Business Standard/Basic"]
    std --> noint["Intune을 포함하지 않음"]

그림 8: Business Premium은 Intune Plan 1과 Entra ID P1을 포함하고, Business Standard/Basic에는 Intune이 포함되지 않는다.

주의할 점이 두 가지 있습니다.

• 플랜 구성은 자주 바뀝니다. 2026년에 들어와서도 Intune Suite 기능을 Microsoft 365 상위 플랜(E3/E5 등)으로 재배치하는 변경이 진행되는 등, 포함 내용의 재검토가 이어지고 있습니다.⁴ 이 절의 내용은 2026년 8월 시점의 것으로 다루고, 계약 전에 반드시 Microsoft의 라이선스 페이지와 가격 페이지에서 최신 정보를 확인하십시오.
• Intune 화면에서 쓸 수 있어도, 별도 라이선스를 요구하는 기능이 있습니다. 대표 예가 뒤에서 다루는 Remediations이며, Windows Enterprise E3/E5 계열(Microsoft 365 E3/E5 등에 포함) 라이선스가 필요하고 Business Premium 범위에서는 사용할 수 없습니다.¹³

비용 비교는 「Intune 구독 비용」 대 「0원」이 아닙니다. GPO 쪽에도 AD 서버 하드웨어 교체, Windows Server 라이선스와 CAL, 구축비, 5년분의 보수, 백업, 장애 대응이라는 비용이 들어 있습니다. 서버 교체 견적서와 Business Premium 5년분의 차액을 나란히 놓은 뒤, 「사외 PC에 관리가 도달하는가」라는 능력 차이를 더해 판단하는 것이 올바른 비교입니다.

flowchart TB
    accTitle: 비용 비교의 올바른 생각
    accDescr: GPO 쪽에도 AD 서버 교체와 라이선스, 5년분의 보수 등 비용이 들므로, 서버 교체 견적과 Business Premium 5년분의 차액을 나란히 놓은 뒤 사외 PC에 관리가 도달하는가라는 능력 차이를 더해 판단한다
    gpocost["GPO 지속의 비용"] --> hw["서버 교체·라이선스·CAL"]
    gpocost --> ops["구축·보수·백업"]
    bpcost["Intune 이전의 비용"] --> sub["Business Premium 5년분"]
    hw --> diff["5년분의 차액을 나란히 놓음"]
    ops --> diff
    sub --> diff
    diff --> ability["사외 PC에 관리가 도달하는지를 더함"]

그림 9: 서버 교체 견적과 Business Premium 5년분을 나란히 놓고, 사외 PC에의 관리라는 능력 차이를 더해 판단한다.

5. GPO로 해 온 일을 Intune에서는 어떻게 하는가

GPO 운영의 주요 업무마다 Intune에서의 대응물을 대응표로 보입니다.

몇 가지를 보완합니다.

• 설정 카탈로그는 「GPO 편집기의 클라우드 판」에 해당하는 화면이며, Microsoft도 「온프레미스 GPO와 마찬가지로 세밀하게 구성하고 싶을 때의 자연스러운 이전처」로 위치시킵니다. ADMX-backed 정책(ADMX로 정의된 설정의 MDM 판)도 포함되며, 서드파티 ADMX 가져오기 기능(미리 보기)도 있습니다.⁷
• 규정 준수 정책+조건부 액세스는 GPO에는 없던 발상입니다. 「BitLocker 사용·OS 최신·Defender 가동」과 같은 준수 조건을 정의하고, 충족하지 않는 디바이스에서는 Microsoft 365 접근을 차단할 수 있습니다. 조건부 액세스는 Entra ID P1 기능이며 Business Premium에 포함됩니다.¹⁶
• Remediations는 구칭 Proactive remediations에서 이름이 바뀌었습니다. 감지 스크립트와 복구 스크립트의 쌍을 주기 실행하는 구조로, 「로그온할 때마다 무언가를 고치는」 계열의 GPO 운영을 대체하지만, 앞에서 적은 대로 Windows Enterprise E3/E5 계열 라이선스가 필요합니다.¹³ Business Premium 범위에서는 플랫폼 스크립트(스크립트나 할당이 바뀔 때 실행되고, 실패 시 재시도됩니다)¹²와 Win32 앱의 검색 규칙을 조합해 대체하는 편이 현실적입니다.
• 업데이트 관리의 상세한 선택지(WUfB·Autopatch·WSUS 지속 판단)는 「WSUS deprecated 이후의 Windows Update 관리」에서, BitLocker와 LAPS 설계는 「BitLocker 실무 가이드」「Windows LAPS 실무 가이드」에서 각각 깊게 다룹니다.

flowchart TB
    accTitle: 규정 준수 정책과 조건부 액세스의 흐름
    accDescr: 규정 준수 정책은 준수 조건에 따라 디바이스의 준수 상태를 판정할 뿐이고, 조건부 액세스 정책이 준수 디바이스를 요구함으로써 비로소 준수 디바이스는 허용되고 비준수 디바이스는 차단된다
    policy["준수 조건을 정의"] -.-> cond["BitLocker 사용이나 OS 최신 등"]
    policy --> state["디바이스의 준수 상태를 판정"]
    state --> ca["조건부 액세스가 준수를 요구"]
    ca -->|준수| allow["Microsoft 365 접근 가능"]
    ca -->|비준수| block["접근을 차단"]

그림 10: 준수 상태의 판정은 규정 준수 정책, 차단은 조건부 액세스의 역할이다. 조합해야 비로소 차단이 먹힌다.

6. 현재 GPO의 현황 파악 ── Group Policy analytics로 분류한다

이전 계획의 첫 실작업은 현재 GPO의 현황 파악입니다. Intune에는 Group Policy analytics라는 전용 기능이 있어, 손으로 GPO를 읽어 내지 않아도 설정 단위로 「MDM으로 대체할 수 있는가」를 분류할 수 있습니다.⁶

절차는 다음과 같습니다.⁶

1. 도메인 컨트롤러 등에서 그룹 정책 관리 콘솔(GPMC.msc)을 열고, 대상 GPO를 오른쪽 클릭→「보고서 저장」으로 XML 파일로 내보낸다(파일당 4MB 이하)
2. Intune 관리 센터의 「디바이스」→「Group Policy analytics」에서 XML을 가져온다(복수 선택 가능)
3. 자동 분석 결과, GPO마다 MDM 지원률(Intune에 동등 설정이 있는 비율)이 표시된다
4. 「그룹 정책 이전 준비 상태」보고서에서 설정마다 Ready for migration(이전 가능)/Not supported(대응 설정 없음)/Deprecated(사용 중단됨) 분류를 확인한다
5. Ready for migration 설정은 그대로 설정 카탈로그 정책으로 변환해 배포할 수 있다

flowchart TB
    accTitle: Group Policy analytics로 현황을 파악하는 흐름
    accDescr: GPMC에서 GPO를 XML로 내보내 Intune으로 가져오면 MDM 지원률과 설정마다의 이전 가능 여부가 표시되고, Ready for migration 설정은 설정 카탈로그 정책으로 변환할 수 있다
    export["GPMC에서 GPO를 XML로 내보내기"] --> import["Intune으로 가져오기"]
    import --> rate["MDM 지원률 표시"]
    rate --> report["이전 준비 상태 보고서"]
    report --> ready["Ready for migration"]
    report --> notsup["Not supported"]
    report --> dep["Deprecated"]
    ready --> convert["설정 카탈로그 정책으로 변환"]

그림 11: XML 내보내기부터 가져오기·설정 단위 분류·설정 카탈로그로의 변환까지가 Group Policy analytics의 흐름이다.

일본어 환경에서는 중요한 주의가 있습니다. Group Policy analytics의 비 ADMX 설정 분석은 영어만 지원하며, 영어 이외 언어의 설정을 포함한 GPO를 가져오면 MDM 지원률이 부정확해질 수 있습니다.⁶ 지원률은 대략적인 참고값으로 쓰고, 최종 판단은 설정 단위 목록으로 하십시오.

flowchart TB
    accTitle: 일본어 GPO를 분석할 때의 주의
    accDescr: Group Policy analytics의 비 ADMX 설정 분석은 영어만 지원하며, 일본어 설정을 포함한 GPO에서는 MDM 지원률이 부정확해질 수 있으므로, 비율은 대략적인 참고에 머물고 최종 판단은 설정 단위 목록으로 한다
    jgpo["일본어 설정을 포함한 GPO"] --> limit["비 ADMX 분석은 영어만 지원"]
    limit --> rate["지원률이 부정확해질 수 있음"]
    rate --> use1["비율은 대략적인 참고에 머문다"]
    rate --> use2["최종 판단은 설정 단위 목록으로"]

그림 12: 일본어 GPO에서는 MDM 지원률이 부정확해질 수 있으므로, 최종 판단은 설정 단위 목록으로 한다.

실무에서는 분류 결과를 세 더미로 나눕니다.

1. 버릴 설정 ── Internet Explorer 시절의 설정, 퇴역한 시스템용 설정, 누구도 이유를 설명하지 못하는 설정. 현황 파악의 가장 큰 성과는, 실은 이 더미를 버릴 수 있다는 것입니다. 10년 운영한 GPO에는 상당한 양의 유산이 쌓여 있습니다.
2. Intune으로 옮길 설정 ── Ready for migration 가운데 앞으로도 필요한 것. 설정 카탈로그로 변환하고, 파일럿 그룹에서 검증합니다.
3. 대체책을 설계할 설정 ── Not supported 가운데 앞으로도 필요한 것. 대표 예와 대체의 방향은 다음과 같습니다.

flowchart TB
    accTitle: 현황 파악 결과의 세 가지 분류
    accDescr: 현황 파악 결과는 버릴 설정, Intune으로 옮겨 검증할 설정, 대응 설정이 없어 대체책을 설계할 설정 세 더미로 나눠 다룬다
    result["분류 결과"] --> discard["버릴 설정"]
    result --> move["Intune으로 옮길 설정"]
    result --> alt["대체책을 설계할 설정"]
    discard -.-> legacy["쌓인 유산을 처분"]
    move --> pilot["설정 카탈로그로 변환해 검증"]
    alt --> design["스크립트 배포나 앱화"]

그림 13: 현황 파악 결과는 「버린다」「Intune으로 옮긴다」「대체책을 설계한다」의 세 더미로 분류한다.

7. 단계적 이전 시나리오 ── 5단계와 완료 조건

전체를 5단계로 나누고, 각 단계에 완료 조건을 둡니다. 「언제 끝났다고 말할 수 있는가」를 먼저 정해 두는 것이, 정보시스템 담당 1인의 이전을 좌초시키지 않는 요령입니다.

flowchart TB
    accTitle: 5단계의 이전 시나리오
    accDescr: 파일럿에서 기본 정책, 앱 배포, 기존 PC의 교체 주기에서의 치환, AD의 역할 축소로 단계적으로 나아가, 최종적으로 GPO로 배포하는 설정을 0으로 만든다
    s1["① 파일럿"] --> s2["② 기본 정책"]
    s2 --> s3["③ 앱 배포"]
    s3 --> s4["④ 기존 PC의 자연 치환"]
    s4 --> s5["⑤ AD의 역할 축소"]
    s5 -.-> goal["GPO로 배포하는 설정이 0"]

그림 14: 이전은 파일럿부터 AD의 역할 축소까지 5단계로 진행하고, 각 단계의 완료 조건을 먼저 정해 둔다.

각 단계의 요점입니다.

• ① 파일럿은, 다음 신입 사원 PC나 고장 교환기처럼 어차피 살 PC로 시작합니다. 추가 투자 없이 시작할 수 있고, 실패해도 와이프하고 다시 할 수 있는 것이 신규 기기부터 시작하는 이점입니다. 대수가 늘어나면 OOBE(초기 설정)부터 Entra join+Intune 등록까지를 자동화하는 Windows Autopilot 이용을 검토합니다.²
• ② 기본 정책에서는 GPO의 모든 설정 재현을 목표로 하지 마십시오. 먼저 업데이트·암호화·Defender·화면 잠금·LAPS의 다섯 가지로 좁히고, 규정 준수 정책으로 준수 상태를 시각화합니다. 조건부 액세스로 「준수 디바이스만 접근 가능」을 켜는 것은, 파일럿에서 오탐이 없음을 확인한 뒤입니다.¹⁶
• ③ 앱 배포는 키팅 자동화와 이어집니다. 이미 winget 기반 절차를 갖추고 있다면(「winget + PowerShell로 PC 키팅을 자동화한다」), 그 자산은 Store 앱(신규)이나 Win32 앱 래퍼로 거의 그대로 살릴 수 있습니다.¹¹
• ④ 기존 PC는 3장에서 말한 대로 Entra join으로의 무변환 경로가 없으므로, 원칙은 자연 치환입니다. Windows 10에서의 교체 계획(「Windows 10 지원 종료 이후의 현실적 선택」)이 남아 있는 조직은, 그 교체를 ④와 동시에 진행하면 이중 작업을 피할 수 있습니다.
• ⑤ AD의 역할 축소에서는, GPO가 비워져도 AD가 즉시 불필요해지지는 않습니다. 파일 서버 인증, 레거시 앱의 LDAP 참조 등이 남아 있으면 AD는 「인증 서버」로 축소해 계속합니다. 그것들의 현황 파악과 기한 설정까지가 이 단계의 일입니다.

flowchart TB
    accTitle: GPO가 비워진 뒤의 AD 취급
    accDescr: GPO가 비워져도 파일 서버 인증이나 레거시 앱의 LDAP 참조가 남아 있으면 AD는 인증 서버로 축소해 계속하고, 남은 역할의 현황 파악과 기한 설정까지가 최종 단계의 일이 된다
    gpoempty["GPO가 비워졌다"] --> remain{"남은 역할은?"}
    remain -->|파일 서버 인증| keep["인증 서버로 축소 지속"]
    remain -->|레거시의 LDAP 참조| keep
    remain -->|역할 없음| retire["AD 자체의 폐기를 검토"]
    keep --> task["현황 파악과 기한 설정까지 한다"]

그림 15: GPO가 비워져도 남은 역할이 있으면, AD는 인증 서버로 축소해 계속한다.

8. 막히는 지점

8.1. GPO와 MDM의 이중 적용 ── 기본값에서는 GPO가 이긴다

이전 기간 중에는 GPO와 Intune 양쪽이 같은 PC(hybrid join 기기)에 설정을 배포하는 장면이 생깁니다. 여기서 같은 설정이 충돌하면, 기본값에서는 GPO 쪽이 우선됩니다. Policy CSP의 MDMWinsOverGP를 1로 설정하면 MDM 쪽 설정이 우선되고, 대응하는 GPO 설정은 차단되지만, 이 동작이 적용되는 것은 Policy CSP 아래 설정에 한정되며, Defender CSP 등 다른 CSP에 정의된 설정에는 적용되지 않습니다. Microsoft 스스로도, MDMWinsOverGP 관리 아래 있지 않은 설정을 GPO와 MDM 양쪽에서 구성하면 충돌 상태가 되어 어느 쪽이 이길지 보장되지 않는다고 명시합니다.¹⁴

flowchart TB
    accTitle: GPO와 MDM이 충돌했을 때의 우선 관계
    accDescr: 같은 설정을 GPO와 MDM 양쪽에서 배포하면 기본값에서는 GPO가 우선되고, MDMWinsOverGP를 1로 두면 Policy CSP 아래 설정에 한해 MDM이 우선되지만, 그 외 CSP 설정에서는 승부가 보장되지 않는다
    both["같은 설정을 GPO와 MDM 양쪽에서 배포"] --> flag{"MDMWinsOverGP=1?"}
    flag -->|아니오| gpowin["GPO가 우선（기본값）"]
    flag -->|예| csp{"Policy CSP 아래 설정인가?"}
    csp -->|예| mdmwin["MDM이 우선"]
    csp -->|아니오| unknown["어느 쪽이 이길지 보장되지 않음"]
    both -.-> avoid["원칙은 양쪽에서 배포하지 않음"]

그림 16: 기본값에서는 GPO가 이기고, MDMWinsOverGP가 적용되는 것은 Policy CSP 아래만이다. 원칙은 이중 배포를 피한다.

실무의 원칙은 단순합니다. 우선 제어에 의존하지 말고, 같은 설정을 양쪽에서 배포하지 않는다. Intune으로 옮긴 설정은 대응하는 GPO 쪽 구성을 「구성되지 않음」으로 되돌리거나, GPO 자체의 링크를 뗍니다. 6장의 이전 완료 목록은, 이를 위한 대장입니다.

8.2. 온프레미스 자산에 대한 의존 ── 네트워크 드라이브와 프린터

이전에서 막히는 지점의 상당수는 Intune 기능이 아니라 온프레미스 자산과의 연결입니다. Entra join 기기에서 온프레미스 파일 서버로의 접근 자체는 가능하지만², 드라이브 매핑이나 프린터 배포를 GPO의 로그온 스크립트에 의존하고 있었다면 그 배포 수단만 먼저 사라집니다. 공유의 OneDrive/SharePoint 이전이나 Universal Print로의 교체를 ③ 단계에 넣을지, 당분간은 스크립트 배포¹²로 이을지를 파일럿 중에 정해 두십시오.

flowchart TB
    accTitle: 온프레미스 자산에 의존하는 배포의 교체
    accDescr: 드라이브 매핑이나 프린터 배포를 GPO의 로그온 스크립트에 의존하고 있으면 이전에서 그 배포 수단이 먼저 사라지므로, OneDrive나 SharePoint로의 공유 이전, Universal Print로의 교체, 당장의 스크립트 배포 가운데 무엇으로 대응할지를 파일럿 중에 정한다
    dep["로그온 스크립트 의존"] --> lost["이전에서 배포 수단이 사라짐"]
    lost --> share["OneDrive/SharePoint 이전"]
    lost --> print["Universal Print 등으로 치환"]
    lost --> script["스크립트 배포로 잇는다"]
    share --> decide["파일럿 중에 방침을 결정"]
    print --> decide
    script --> decide

그림 17: 로그온 스크립트 의존의 배포는 이전에서 수단이 먼저 사라지므로, 교체처를 파일럿 중에 정해 둔다.

8.3. 키팅의 재설계 ── Autopilot은 「필수」가 아니다

Intune 이전과 세트로 Windows Autopilot 도입을 권하는 경우가 있지만, 연간 몇 대~십수 대 규모의 조달이라면, OOBE에서 회사 계정으로 사인인해 수동으로 Entra join하는 운영으로도 실질적인 문제는 없습니다. Autopilot이 효과를 내는 것은 조달 대수가 늘어 개봉부터의 무인 설정에 가치가 생겼을 때나, 판매점 쪽의 디바이스 등록을 쓸 수 있을 때입니다. ②③이 갖춰진 뒤에 더하면 되고, 이전의 전제 조건이 아닙니다.

flowchart TB
    accTitle: Autopilot 도입의 판단
    accDescr: 연간 몇 대에서 십수 대의 조달 규모라면 OOBE에서 수동으로 Entra join하는 운영으로 실질적인 문제는 없고, 조달 대수가 늘어 무인 설정에 가치가 생겼을 때 Autopilot을 나중에 더하면 된다
    scale{"연간 조달 규모는?"} -->|몇 대~십수 대| manual["OOBE로 수동 Entra join"]
    scale -->|대수가 늘면| ap["Autopilot로 무인화"]
    ap -.-> later["②③이 갖춰진 뒤에 더함"]

그림 18: 조달 규모가 작을 때는 수동의 Entra join으로 충분하고, Autopilot은 나중에 더하면 된다.

8.4. 「전부 Intune으로 하지 않으면 안 된다」는 오해

마지막은 기술이 아니라 선입견의 문제입니다. Entra join 기기와 도메인 조인 기기의 공존은 정식으로 지원되는 구성이며², 「AD가 남아 있다=이전 실패」가 아닙니다. GPO에 몇 개의 설정이 남은 채로 몇 년을 병행하는 회사는 드물지 않고, 그래도 「새 PC는 모두 클라우드 관리이고, 사외에서도 통제가 먹힌다」는 상태에는 큰 가치가 있습니다. 완전 이전의 아름다움보다, 되돌릴 수 있는 작은 전진을 우선하십시오.

flowchart TB
    accTitle: 완전 이전에 집착하지 않는 병행의 가치
    accDescr: AD가 남아 있으면 이전 실패라는 것은 아니며, GPO에 설정이 남은 채로 몇 년을 병행해도, 새 PC가 모두 클라우드 관리이고 사외에서도 통제가 먹히는 상태에는 큰 가치가 있다
    miscon["AD가 남으면 이전 실패?"] -->|그렇지 않다| run["GPO가 남은 채로 몇 년 병행"]
    run --> value["신규 PC는 사외에서도 통제가 먹힌다"]
    value -.-> forward["작은 전진을 우선"]

그림 19: AD가 남은 채로의 병행이어도, 새 PC가 모두 클라우드 관리가 되는 상태에는 큰 가치가 있다.

9. 정보시스템 담당 1인 체제에서의 현실적인 답

마지막으로, 담당자가 1명(또는 겸임)인 회사에서의 운영 설계를 정리합니다.

• 관리 항목을 처음부터 좁힌다. GPO 시절의 설정을 전부 가져오려 하면, 현황 파악만으로 지칩니다. 7장 ②의 다섯 가지(업데이트·암호화·Defender·화면 잠금·LAPS)부터 시작하고, 필요가 생긴 설정만 더하는 「빼기의 설계」로 하십시오. 설정 카탈로그는 수천 개의 설정을 제공하지만⁷, 쓸 의무는 없습니다.
• 표준 PC 모습을 하나로 정한다. 「이 회사의 PC는 이 정책 군과 이 앱 군」이라는 표준을 한 세트만 유지합니다. 부서별 예외는 그룹과 필터로 표현할 수 있지만, 예외가 늘수록 1명으로는 돌아가지 않습니다.
• 외부 파트너에게는 설계와 템플릿 만들기를 맡기고, 일상 운영은 내재화한다. Intune 이전 외주에서 실패하기 쉬운 것은, 구축을 통째로 맡겨 「관리 화면의 의미를 아무도 모른다」는 상태가 되는 경우입니다. 초기 설계·정책의 템플릿화·이전 판단의 검토 상대를 외부에 구하고, 매일의 PC 추가나 정책 미세 조정은 스스로 할 수 있는 상태를 목표로 하십시오. 거꾸로 말하면, 거기까지 넘겨 주는 파트너를 골라야 합니다.
• 변경은 한 번에 하나. 정책 변경은 1건씩 하고, Intune 보고서(정책 적용 상태나 할당 실패)로 결과를 확인한 뒤 다음으로 갑니다. MDM 동기화는 약 8시간 주기이며³, 「적용되지 않는다」의 대부분은 고장이 아니라 시간의 문제입니다.

flowchart TB
    accTitle: 정책 변경의 운영 주기
    accDescr: 정책 변경은 1건씩 하고, Intune 보고서로 적용 상태를 확인한 뒤 다음 변경으로 간다. 적용되지 않는 경우의 대부분은 약 8시간 주기의 동기화를 기다리면 해결된다
    change["정책 변경을 1건만 한다"] --> report["보고서로 적용 상태를 확인"]
    report --> next["문제없으면 다음 변경으로"]
    next --> change
    report -.-> wait["미적용의 대부분은 동기화 대기"]

그림 20: 정책 변경은 1건씩 하고, 보고서로 결과를 확인한 뒤 다음으로 간다.

10. 정리

• GPO는 도메인 컨트롤러에 도달하는 것이 전제인 구조이며, 사외 PC에는 구조적으로 도달하지 않습니다. Intune(MDM)은 인터넷을 통해 동기화하므로, 이 과제를 근본부터 해소합니다.
• 이전은 「전부 아니면 전무」가 아닙니다. Entra join 기기와 도메인 조인 기기는 공존할 수 있고, 신규 PC부터 Entra join+Intune으로 전환하는 단계적 이전이 중소기업의 현실적인 답입니다. 기존 기기의 변환 경로는 없으므로, 교체 주기에서의 치환이 정석입니다.
• Intune은 Microsoft 365 Business Premium(Intune Plan 1+Entra ID P1)으로 시작하는 것이 중소기업에서는 현실적입니다. 다만 플랜 구성은 계속 바뀌고, Remediations처럼 상위 라이선스를 요구하는 기능도 있으므로, 2026년 8월 시점의 이 글을 그대로 받아들이지 말고 1차 정보를 확인하십시오.
• 현재 GPO의 현황 파악은 Group Policy analytics로 자동화할 수 있습니다. 이전 가능한 설정은 설정 카탈로그로 변환하고, 대응 설정이 없는 로그온 스크립트나 프린터 배포는 스크립트 배포·앱화·운영 폐기로 대체합니다. 일본어 GPO에서는 지원률이 부정확해질 수 있는 점에 주의하십시오.
• 이전은 「파일럿→기본 정책→앱 배포→기존 PC의 자연 치환→AD의 역할 축소」의 5단계로 진행하고, 각 단계의 완료 조건을 먼저 정합니다.
• 이중 적용의 충돌은 기본값에서 GPO가 이깁니다. MDMWinsOverGP는 Policy CSP 한정 구조이므로, 원칙은 「같은 설정을 양쪽에서 배포하지 않는 것」입니다.
• 서버 교체 견적이 나왔을 때가, 이 이전을 검토하는 가장 좋은 타이밍입니다. 「AD를 한 주기 더」의 앞에, 다음 5년의 PC가 어디에서 쓰이는지를 생각해 보십시오.

관련 글

• 그룹 정책(GPO) 실무 입문 ── 동작 방식·적용 확인·Intune과의 역할 분담
• WSUS deprecated 이후의 Windows Update 관리 ── WUfB·Autopatch·Intune을 어떻게 고를까
• Windows 10 지원 종료 이후의 현실적 선택 ── ESU·LTSC·교체 판단표
• winget + PowerShell로 PC 키팅을 자동화한다 ── 절차서를 실행 가능하게 만들기
• BitLocker 실무 가이드 ── 복구 키 관리부터 시작하는 드라이브 암호화
• Windows LAPS 실무 가이드 ── 전 PC 공통 로컬 관리자 비밀번호를 그만두기

관련 상담 영역

합동회사 코무라소프트는 AD+GPO 환경에서 Entra ID+Intune으로의 단계적 이전 설계(현재 GPO의 현황 파악, 정책 재현 방침, 파일럿 계획), 서버 교체와 클라우드 이전의 비교 검토, 기존 업무 앱·키팅 자산을 살린 이전 상담을 다룹니다. 「AD 서버를 한 번 더 사야 하는가」를 함께 검토하는 단계부터여도 괜찮습니다.

• 기술 상담·설계 리뷰
• 기존 자산 활용·이전 지원
• 문의

참고 링크

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

GPO에서 Intune으로 이전하면, 지금 쓰는 그룹 정책 설정을 모두 재현할 수 있나요?

전부를 재현할 수는 없습니다. Intune의 설정 카탈로그에는 ADMX에서 온 항목을 포함해 수천 개의 Windows 설정이 있어 대부분의 보안 설정과 제한은 옮길 수 있지만, 로그온 스크립트로 드라이브 매핑을 하거나 프린터를 일괄 배포하는 것처럼 MDM에 대응하는 설정이 없는 것도 있습니다. 현재 GPO의 XML 내보내기를 Intune의 Group Policy analytics에 가져오면, 설정마다 이전 가능 여부(Ready for migration / Not supported / Deprecated)를 분류할 수 있습니다. 대체 수단이 없는 설정은 PowerShell 스크립트 배포, 앱으로 만들기, 또는 「그 설정을 그만두는」 쪽으로 대응합니다.

Intune을 쓰려면 어떤 라이선스가 필요하나요?

기본은 Microsoft Intune Plan 1이며, 단독으로도 계약할 수 있지만 중소기업에서는 Microsoft 365 Business Premium(최대 300사용자)에 포함된 형태로 쓰는 경우가 일반적입니다. Business Premium에는 Entra ID P1도 들어 있어 규정 준수 정책과 조건부 액세스를 조합하는 구성까지 사용할 수 있습니다. 한편 Remediations처럼 Windows Enterprise E3/E5 계열 라이선스를 별도로 요구하는 기능도 있습니다. 플랜 구성은 자주 바뀌므로 계약 전에 Microsoft 공식 라이선스 페이지에서 최신 내용을 확인하십시오(이 글은 2026년 8월 시점).

AD 서버는 바로 폐기해야 하나요?

아닙니다. Entra join+Intune으로 관리하는 PC와 AD 도메인 조인+GPO로 관리하는 PC는 같은 사내 네트워크에서 공존할 수 있습니다. 파일 서버 인증이나 기존 업무 시스템 때문에 AD를 남겨 둔 채, 신규 PC만 Entra join으로 두는 단계적 이전이 현실적입니다. 반대로 기존 도메인 조인 PC를 Entra join으로 「변환」하는 정식 수단은 없고 와이프(초기화)가 필요하므로, 기존 기기는 교체 주기로 바꾸는 것이 정석입니다. AD 폐기는 GPO가 비고, 남은 역할을 가려낸 뒤에 검토하면 충분합니다.

재택 근무 PC에 그룹 정책이 적용되지 않는 이유는 무엇인가요?

GPO는 도메인 컨트롤러에 연결할 수 있을 때 가져와 적용되는 방식이기 때문입니다. 사외 PC는 VPN 등으로 도메인 컨트롤러에 도달했을 때만 최신 정책을 받으며, VPN을 쓰지 않는 재택 PC에는 사실상 도달하지 않습니다. Intune(MDM)은 인터넷을 통해 정책을 동기화하므로 PC가 어디에 있든 관리할 수 있고, 사외 PC 관리라는 과제는 MDM 쪽 구조로 해소됩니다. 대략 8시간마다의 주기 동기화에 더해, 정책 변경 시에는 알림에 의한 동기화도 이뤄집니다.

같은 설정을 GPO와 Intune 양쪽에서 배포하면 어느 쪽이 우선되나요?

기본값에서는 충돌하는 설정은 그룹 정책 쪽이 우선됩니다. MDMWinsOverGP 정책을 1로 설정하면 MDM(Intune) 쪽이 우선되지만, 이 동작이 적용되는 것은 Policy CSP 아래 설정에 한정되며 Defender CSP 등 다른 CSP에 정의된 설정에는 적용되지 않습니다. 우선 제어에 의존하면 동작을 예측하기 어려워지므로, 실무에서는 「같은 설정을 양쪽 채널에서 배포하지 않는 것」을 원칙으로 하고, Intune으로 옮긴 설정은 원래 GPO에서 삭제해 이중 관리를 피하는 편이 안전합니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.