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

「서버 지원 기간이 끝나 교체를 계획하고 있다. 그런데 AD 서버를 또 사서 도메인과 그룹 정책을 다음 주기(5년) 더 돌릴 자신이 없다」. 「사무실에서 정한 그룹 정책이 원격 근무용 노트북에는 전혀 적용되지 않는다. VPN에 연결할 때만 적용된다면, 관리하고 있다고 말할 수 있는가?」── 지난 몇 년, 중소기업 고객의 이런 상담이 꾸준히 늘었습니다.

배경은 일하는 방식의 변화입니다. 온프레미스 Active Directory(AD)와 그룹 정책(GPO)은 「PC가 사내 LAN에 있고 도메인 컨트롤러에 항상 도달할 수 있다」를 가정한 메커니즘입니다. 반출 PC와 원격 근무가 일상이 된 지금, 깨진 것은 그 가정입니다. 거기에 더해, 오래 업데이트 관리의 기본이던 WSUS가 2024년 9월에 비권장이 되었고,¹ Microsoft 장치 관리의 무게 중심은 Entra ID와 Intune(MDM)으로 옮겼습니다.

flowchart TB
    accTitle: 깨진 가정과 무게 중심의 이동
    accDescr: AD와 GPO는 PC가 사내 LAN에 있고 도메인 컨트롤러에 항상 도달할 수 있다고 가정하지만, 반출 PC와 원격 근무가 일상이 되어 그 가정이 깨졌고, WSUS 비권장과 함께 관리의 무게 중심이 Entra ID와 Intune으로 옮겼다
    adgpo["온프레미스 AD와 GPO"] -.-> premise["가정: DC에 항상 도달"]
    work["반출 PC와 원격 근무가 일상"] --> broken["깨진 것은 가정이다"]
    premise --> broken
    wsus["WSUS가 비권장"] --> shift["무게 중심이 Entra ID+Intune으로"]
    broken --> shift

그림 1: 「PC가 사내 LAN에 있다」는 AD+GPO의 가정은 일하는 방식이 바뀌며 깨졌고, 관리의 무게 중심은 Entra ID+Intune으로 옮겼다.

그렇다고 이전이 전부 아니면 전무는 아닙니다. Entra join과 Intune으로 관리하는 PC와 AD 도메인 조인에 GPO인 PC는 같은 회사에서 공존할 수 있고,² 파일 서버용으로 AD를 남기고 새 PC만 Intune 관리로 바꾸는 단계적 이전이 가능합니다. 중소기업의 IT 담당자와 경영자를 대상으로, 이 글은 2026년 8월 시점의 Microsoft Learn 등 1차 정보를 바탕으로 GPO와 MDM의 동작 차이, 전제 구성, 라이선스, 현재 GPO를 목록화하는 법, 단계적 이전 시나리오, 함정을 정리합니다.

1. 먼저 결론

• GPO는 PC가 도메인 네트워크에 연결되어 있을 때 적용되고, Intune(MDM)은 인터넷으로 동기화합니다. 「설정이 재택 PC에 도달하지 않는다」는 문제는 MDM에서는 구조적으로 일어나지 않습니다. 정상 상태 동기화는 대략 8시간마다이며, 정책이 바뀔 때 알림 기반 동기화도 돕니다.³
• 이전은 전부 아니면 전무가 아니며, 공존을 가정한 단계적 이전이 현실적인 답입니다. Microsoft 자신도 새 PC는 Entra join하고, 기존 도메인 조인 PC는 하이브리드 조인으로 남겨 하드웨어 갱신 주기에서 교체하라고 권합니다.²
• Intune은 단독으로 구독할 수 있지만, 중소기업의 현실적인 길은 Microsoft 365 Business Premium에 포함된 Intune Plan 1을 쓰는 것입니다(2026년 8월 시점). 플랜 구성은 계속 바뀌므로, 계약 전에 항상 1차 정보를 확인하십시오.⁴⁵
• 현재 GPO를 목록화하려면 Intune 내장 Group Policy analytics를 씁니다. GPO XML내보내기를 가져오면 각 설정이 이전 가능 여부로 분류되고, 대응물이 있는 설정은 Settings catalog 정책으로 변환할 수 있습니다.⁶
• GPO 시대의 주된 일은 거의 모두 Intune 대응물이 있습니다. 관리 템플릿은 Settings catalog에,⁷ 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 조인 기기는 공존할 수 있고, Entra 조인 기기는 온프레미스 파일 서버에 접근할 수 있습니다. AD의 즉시 폐기는 이전의 조건이 아닙니다.²

한 문장으로 「AD 서버를 다음 주기 더 교체해야 하는가」라는 질문은 「앞으로 5년, 사무실 밖 PC를 무엇으로 관리할 것인가」로 다시 만들어 그 바탕으로 결정해야 합니다.

flowchart LR
    accTitle: 결정해야 할 질문을 다시 만들기
    accDescr: AD 서버를 다음 주기 더 교체할 것인가라는 질문은, 앞으로 5년 오프사이트 PC를 무엇으로 관리할 것인가라는 질문으로 다시 만들어야 한다
    q1["AD 서버를 다음 주기 더 교체할 것인가?"] -->|다시 만듦| q2["앞으로 5년, 오프사이트 PC를 무엇으로 관리하는가?"]

그림 2: 서버 교체 질문을 「앞으로 5년, 사무실 밖 PC를 무엇으로 관리할 것인가」로 다시 만들어 그 바탕으로 결정한다.

2. GPO와 MDM의 차이 ── 적용 메커니즘을 같은 장에서 비교하기

먼저 둘을 같은 장에서 비교합니다. GPO 메커니즘 자체(LSDOU 적용 순서, gpupdate/gpresult로 확인하는 법)는 「그룹 정책(GPO) 실무 입문」에서 깊게 다루므로, 여기서는 이전 결정에 중요한 차이로 좁힙니다.

이전 결정에 가장 중요한 행은 첫째와 셋째입니다. 재택 PC에 GPO가 도달하지 않는 것은 버그가 아니라, 「PC가 도메인 컨트롤러에 도달할 수 있는 자리에 있다」는 설계 가정이 지금의 일하는 방식과 더 이상 맞지 않기 때문입니다. 전 직원에게 상시 VPN을 강제해 GPO를 살릴 수는 있지만, 그것은 VPN 플랫폼이라는 별도 인프라의 유지를 떠안는 선택이기도 합니다.

flowchart TB
    accTitle: GPO를 살리는 선택과 MDM으로 이전하는 선택
    accDescr: 재택 PC에 GPO가 도달하지 않는 것은 설계 가정이 지금의 일하는 방식과 더 이상 맞지 않기 때문이며, 상시 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가 사내 도메인 컨트롤러에 연결할 수 있을 때만 적용되므로 재택 PC는 VPN에 의존하고, Intune은 인터넷으로 대략 8시간마다 동기화하며 정책이 바뀔 때 알림으로도 동기화하므로 PC가 어디에 있든 도달한다
    officepc["사내 PC"] --> dc["도메인 컨트롤러"]
    officepc -.-> when["기동과 사인인"]
    when -.-> when2["더해 주기 새로고침"]
    homepc["재택 PC"] --> vpn{"VPN으로 DC에 도달하는가?"}
    vpn -->|예| dc
    vpn -->|아니오| miss["정책이 오지 않음"]
    anypc["어디에 있든 PC"] --> intune["Intune 서비스"]
    anypc -.-> every["약 8시간마다 동기화"]
    intune -.-> notify["변경 알림 기반"]
    dc ~~~ homepc
    miss ~~~ anypc

그림 4: GPO는 PC가 도메인 컨트롤러에 도달할 때만 적용되고, Intune은 위치와 관계없이 인터넷으로 동기화한다.

3. 전제의 정리 ── 도메인 조인, 하이브리드 조인, Entra 조인의 세 형태

「Windows PC가 회사에 조인하는 방식」은 세 형태가 있고, 어느 것을 고르느냐가 쓸 수 있는 관리 도구를 정합니다.²

하이브리드 조인은 「기존 도메인 조인 PC에 클라우드 정체성을 주는」 형태이며, 기존 자산을 유지한 채 Intune과 Conditional Access를 쓰기 시작할 수 있습니다. 다만 Microsoft는 하이브리드 조인을 최종 목표로 삼지 말고, 새 PC와 교체 PC는 Entra join하라고 권합니다.²

여기서 받아들일 제약이 하나 있습니다. 기존 도메인 조인 PC(하이브리드 조인 포함)를 Entra join으로 변환하는 Microsoft 지원 방법은 없고, Windows 초기화(wipe)가 필요합니다. 그래서 Microsoft도 하드웨어 갱신이나 OS 재설치 때 Entra join으로 옮기라고 권합니다.²

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

그림 5: 기존 도메인 조인 기기를 Entra join으로 변환하는 지원되는 방법은 없고, 새 PC와 교체 PC부터 바꾸는 것이 자리 잡은 패턴이다.

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

1. 새 PC와 교체 PC는 Entra join과 Intune으로 관리한다
2. 기존 도메인 조인 PC는 그대로 두고 하드웨어 갱신 주기에서 자연 교체되게 한다
3. 파일 서버 인증 같은 남은 역할용으로 AD는 당분간 남기고, GPO의 내용은 단계적으로 비운다

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

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

Entra 조인 기기와 도메인 조인 기기는 같은 환경에서 공존할 수 있고, Entra 조인 기기는 온프레미스 파일 서버 같은 사내 자산에 접근할 수 있습니다.² 다만 그 단일 사인온에는 전제가 둘 있습니다. (1) 사용자가 온프레미스 AD에서 Entra Connect(또는 Cloud Sync)로 동기화된 하이브리드 정체성이다(클라우드에만 있는 사용자는 AD Kerberos/NTLM 자격 증명을 얻을 수 없다), (2) PC가 도메인 컨트롤러에 네트워크로 도달할 수 있다(오프사이트에서는 VPN 등이 필요).¹⁵ 이전 계획에서는 이 두 점을 만족하지 못하는 사용자나 사용 시나리오가 없는지 먼저 확인하십시오.

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

그림 7: Entra 조인 기기에서 온프레미스 자산으로의 SSO에는 하이브리드 정체성과 도메인 컨트롤러에의 도달 가능성 두 전제가 있다.

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도 포함되어, 뒤에 나오는 규정 준수 정책과 Conditional Access 구성을 이 플랜 안에서 끝낼 수 있습니다. 반면 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가 포함되어 Conditional Access까지 완결되지만, 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["Conditional Access까지 완결"]
    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 UI에서 열 수 있는 일부 기능은 별도 라이선스가 필요합니다. 대표 예는 뒤에 나오는 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 대응물을 매핑 표로 보여 줍니다.

몇 가지 주석입니다.

• Settings catalog는 「GPO 편집기의 클라우드 판」에 해당하는 화면이며, Microsoft 자신도 「온프레미스 GPO와 같은 세밀함으로 구성하고 싶을 때의 자연스러운 이전 목적지」로 위치합니다. ADMX 기반 정책(ADMX에 정의된 설정의 MDM 판)이 포함되고, 서드파티 ADMX를 가져오는 (미리보기) 기능도 있습니다.⁷
• 규정 준수 정책과 Conditional Access는 GPO에 없던 생각입니다. 「BitLocker 켜짐, OS 최신, Defender 가동」같은 준수 조건을 정의하고, 충족하지 않는 장치에서의 Microsoft 365 접근을 차단할 수 있습니다. Conditional Access는 Entra ID P1 기능이며 Business Premium에 포함됩니다.¹⁶
• Remediations는 Proactive remediations에서 이름이 바뀌었습니다. 감지 스크립트와 수정 스크립트 쌍을 주기적으로 돌리는 메커니즘이며, 「매번 로그온 때 무언가를 고친다」는 종류의 GPO 운용을 대신할 수 있지만, 앞에서 말한 대로 Windows Enterprise E3/E5급 라이선스가 필요합니다.¹³ Business Premium 범위에서 현실적인 대체는 플랫폼 스크립트(스크립트나 할당이 바뀔 때 실행되고, 실패 시 재시도)¹²와 Win32 앱 감지 규칙을 조합하는 것입니다.
• 업데이트 관리의 상세한 선택(WUfB, Autopatch, WSUS 계속 중 결정)은 「WSUS 비권장 이후의 Windows Update 관리」에서, BitLocker와 LAPS의 설계는 「BitLocker 실무 가이드」와 「Windows LAPS 실무 가이드」에서 각각 다룹니다.

flowchart TB
    accTitle: 규정 준수 정책과 Conditional Access의 흐름
    accDescr: 규정 준수 정책은 준수 조건에 대해 장치의 준수 상태만 판단하고, Conditional Access 정책이 준수 장치를 요구할 때만 준수 장치는 허용되고 비준수 장치는 차단된다
    policy["준수 조건을 정의"] -.-> cond["BitLocker 켜짐, OS 최신 등"]
    policy --> state["장치의 준수 상태를 판단"]
    state --> ca["Conditional Access가 준수를 요구"]
    ca -->|준수| allow["Microsoft 365 접근 허용"]
    ca -->|비준수| block["접근 차단"]

그림 10: 준수 상태 판단은 규정 준수 정책의 일, 차단은 Conditional Access의 일이다. 조합해야 차단이 효과를 낸다.

6. 현재 GPO를 목록화하기 ── Group Policy Analytics로 나누기

이전 계획의 첫 실제 작업은 현재 GPO를 목록화하는 것입니다. Intune에는 전용 기능 Group Policy analytics가 있어, GPO를 손으로 읽지 않고 설정마다 「MDM이 이것을 대신할 수 있는가」를 분류할 수 있습니다.⁶

단계는 다음과 같습니다.⁶

1. 도메인 컨트롤러 등에서 그룹 정책 관리 콘솔(GPMC.msc)을 열고, 대상 GPO를 오른쪽 클릭 → Save Report로 XML 파일로 내보냅니다(파일당 4MB 이하)
2. Intune 관리 센터에서 Devices → Group Policy analytics로 가 XML을 가져옵니다(복수 선택 가능)
3. 자동 분석 뒤 각 GPO에 MDM 지원 비율(Intune에 동등물이 있는 설정의 비율)이 표시됩니다
4. Group policy migration readiness 보고서에서 설정별 분류를 확인합니다. Ready for migration / Not supported / Deprecated
5. Ready for migration 설정은 그대로 Settings catalog 정책으로 변환해 배포할 수 있습니다

flowchart TB
    accTitle: Group Policy analytics의 목록화 흐름
    accDescr: GPMC에서 GPO를 XML로 내보내고 Intune에 가져오면 MDM 지원 비율과 설정별 이전 준비도가 표시되고, Ready for migration 설정은 Settings catalog 정책으로 변환할 수 있다
    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["Settings catalog 정책으로 변환"]

그림 11: XML내보내기에서 가져오기, 설정별 분류, Settings catalog로의 변환까지가 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 중 아직 필요한 것. Settings catalog로 변환하고 파일럿 그룹으로 검증합니다.
3. 대체를 설계할 설정 ── Not supported 중 아직 필요한 것. 대표 예와 대체 방향은 다음과 같습니다.

flowchart TB
    accTitle: 목록화 결과의 세 더미
    accDescr: 목록화 결과는 버릴 설정, Intune으로 옮겨 검증할 설정, 대응물이 없어 대체를 설계할 설정의 세 더미로 다룬다
    result["분류 결과"] --> discard["버릴 설정"]
    result --> more{"옮길 것인가 대체할 것인가?"}
    more --> move["Intune으로 옮김"]
    more --> alt["대체를 설계"]
    discard -.-> legacy["레거시를 처분"]
    move --> pilot["Settings catalog"]
    pilot -.-> pilotN["그다음 검증"]
    alt --> design["스크립트 또는 앱으로 만듦"]

그림 13: 목록화 결과를 「버린다」, 「Intune으로 옮긴다」, 「대체를 설계한다」의 세 더미로 나눈다.

7. 단계적 이전 시나리오 ── 다섯 단계와 종료 기준

전체를 다섯 단계로 나누고 각 단계에 종료 기준을 둡니다. 「언제 끝났다고 말할 수 있는가」를 미리 정하는 것이, 1인 IT 이전이 멈추지 않게 하는 요령입니다.

flowchart TB
    accTitle: 다섯 단계 이전 시나리오
    accDescr: 파일럿에서 기준선 정책, 앱 배포, 하드웨어 갱신 주기에서의 기존 PC 교체, AD 역할 축소까지 단계적으로 나아가고, 마지막으로 GPO로 배포하는 설정을 0으로 만든다
    s1["（1）파일럿"] --> s2["（2）기준선 정책"]
    s2 --> s3["（3）앱 배포"]
    s3 --> s4["（4）기존 PC의 자연 교체"]
    s4 --> s5["（5）AD 역할 축소"]
    s5 -.-> goal["GPO로 배포하는 설정이 0"]

그림 14: 이전을 파일럿에서 AD 역할 축소까지 다섯 단계로 나아가고, 각 단계의 종료 기준을 미리 정한다.

각 단계의 핵심.

• (1) 파일럿은 어차피 살 PC── 다음 신입 PC, 고장 교체 등──부터 시작합니다. 새 기기에서 시작하면 추가 투자 없이 시작할 수 있고, 실패하면 초기화하고 다시 시작할 수 있다는 이점이 있습니다. 대수가 늘면 Windows Autopilot으로 OOBE(초기 설정)부터 Entra join과 Intune 등록까지 자동화를 검토합니다.²
• (2) 기준선 정책에서는 모든 GPO 설정을 재현하려 하지 마십시오. 먼저 업데이트, 암호화, Defender, 화면 잠금, LAPS 다섯으로 좁히고, 규정 준수 정책으로 준수 상태를 가시화합니다. Conditional Access에서 「준수 장치만」을 켜는 것은 파일럿에서 오탐이 없음을 확인한 뒤입니다.¹⁶
• (3) 앱 배포는 프로비저닝 자동화와 연속입니다. 이미 winget 기반 절차가 있으면(「winget + PowerShell로 PC 키팅을 자동화하기」), 그 자산은 Store 앱(신규) 또는 Win32 앱 래퍼로 거의 그대로 재사용할 수 있습니다.¹¹
• (4) 기존 PC는 3장에서 말한 대로 Entra join으로의 변환 경로가 없으므로, 원칙은 자연 교체입니다. 아직 Windows 10 교체 계획이 있는 조직(「Windows 10 지원 종료 이후의 현실적 해법」)은 그 교체를 (4)와 동시에 나아가 일을 두 번 하지 않게 할 수 있습니다.
• (5) 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(하이브리드 조인 기기)에 설정을 배포하게 됩니다. 여기서 같은 설정이 충돌하면 기본적으로 그룹 정책이 이깁니다. 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 조인 기기에서 온프레미스 파일 서버로의 접근 자체는 가능하지만,² 드라이브 맵과 프린터 배포가 GPO 로그온 스크립트에 의존하고 있으면, 그 배포 수단이 먼저 사라집니다. 파일럿 중에 공유를 OneDrive/SharePoint로 이전하거나 Universal Print로 바꾸는 것을 단계 (3)에 넣을지, 당분간 스크립트 배포로 다리를 놓을지를 정하십시오.¹²

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이 이득이 되는 것은 조달 대수가 늘고 개봉부터의 무인 설정에 가치가 있거나, 판매점 측의 장치 등록을 쓸 수 있을 때입니다. (2)와 (3)이 갖춰진 뒤에 더해도 되며, 이전의 전제가 아닙니다.

flowchart TB
    accTitle: Autopilot 도입 판단
    accDescr: 연간 조달이 몇 대에서 열몇 대인 규모에서는 OOBE에서 손으로 Entra join해도 실해가 없고, 조달 대수가 늘고 무인 설정에 가치가 있을 때 Autopilot을 뒤에 더한다
    scale{"연간 조달 규모는?"} -->|몇 대에서 열몇 대| manual["OOBE에서 수동 Entra join"]
    scale -->|대수가 늘면| ap["Autopilot으로 무인"]
    ap -.-> later["（2）와（3）이 갖춰진 뒤에 더함"]

그림 18: 조달 규모가 작을 때는 수동 Entra join으로 충분하며, Autopilot은 뒤에 더할 수 있다.

8.4. 「모든 것이 Intune에 들어가지 않으면 안 된다」는 오해

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

flowchart TB
    accTitle: 완전한 이전에 집착하지 않고 병행하는 가치
    accDescr: AD가 남는 것은 실패한 이전이 아니며, GPO에 설정이 남은 채 몇 년을 병행해도 모든 새 PC가 클라우드 관리되고 오프사이트에서도 제어가 동작하는 상태에는 큰 가치가 있다
    miscon["AD가 남으면 이전이 실패인가?"] -->|그렇지 않다| run["GPO가 남은 채 몇 년 병행"]
    run --> value["새 PC는 오프사이트에서도 제어됨"]
    value -.-> forward["작은 전진을 택함"]

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

9. 1인 IT를 위한 현실적인 답

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

• 관리 항목을 처음부터 좁히십시오. GPO 시대의 모든 설정을 가져오려 하면 목록화만으로 지칩니다. 7장 (2)의 다섯(업데이트, 암호화, Defender, 화면 잠금, LAPS)부터 시작하고, 필요가 생겼을 때만 설정을 더하는 「빼기 설계」로 두십시오. Settings catalog는 수천 개의 설정을 제공하지만,⁷ 쓸 의무는 없습니다.
• 표준 PC 이미지를 하나로 정하십시오. 「이 회사의 PC는 이 정책 세트와 이 앱 세트」라는 표준을 하나만 유지합니다. 부서별 예외는 그룹과 필터로 표현할 수 있지만, 예외가 늘수록 한 사람이 따라갈 수 없습니다.
• 설계와 템플릿 만들기는 외부 파트너에게 맡기고, 일상 운용은 사내에 두십시오. 실패하기 쉬운 Intune 이전 외주는 구축을 벽 너머로 던져 「관리 화면이 무엇을 뜻하는지 아무도 모른다」는 상태가 되는 경우입니다. 초기 설계, 정책의 템플릿화, 이전 결정의 상대역은 밖에 맡기고, 목표는 일상에서 PC를 더하고 정책을 스스로 조정할 수 있는 상태입니다. 바꿔 말하면, 거기까지 넘겨 주는 파트너를 고르십시오.
• 한 번에 하나만 바꾸십시오. 정책 변경은 한 번에 하나씩 하고, Intune 보고서(정책 적용 상태와 할당 실패)에서 결과를 확인한 뒤에만 다음으로 갑니다. MDM 동기화는 약 8시간 주기이며,³ 「적용되지 않았다」의 대부분은 고장이 아니라 시간의 문제입니다.

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

그림 20: 정책 변경은 한 번에 하나만 하고, 보고서에서 결과를 확인한 뒤에만 다음으로 간다.

10. 정리

• GPO는 도메인 컨트롤러에의 도달을 가정한 메커니즘이며, 오프사이트 PC에는 구조적으로 도달하지 않습니다. Intune(MDM)은 인터넷으로 동기화하므로, 이 문제를 뿌리에서 해소합니다.
• 이전은 전부 아니면 전무가 아닙니다. Entra 조인 기기와 도메인 조인 기기는 공존할 수 있고, 새 PC를 Entra join과 Intune으로 바꾸는 단계적 이전이 중소기업의 현실적인 답입니다. 기존 기기에는 변환 경로가 없으므로, 하드웨어 갱신 주기에서의 교체가 자리 잡은 패턴입니다.
• 중소기업에서는 Microsoft 365 Business Premium(Intune Plan 1과 Entra ID P1)으로 Intune을 시작하는 것이 현실적입니다. 다만 플랜 구성은 계속 바뀌고, Remediations 같은 일부 기능은 상위 라이선스가 필요하므로, 이 2026년 8월 글을 복음으로 삼지 말고 1차 정보를 확인하십시오.
• 현재 GPO의 목록화는 Group Policy analytics로 자동화할 수 있습니다. Ready for migration 설정은 Settings catalog로 변환하고, 대응물이 없는 로그온 스크립트와 프린터 배포는 스크립트 배포, 작업을 앱으로 만들기, 또는 관행을 그만두기로 바꿉니다. 일본어 GPO에서는 지원 비율이 부정확해질 수 있음에 주의하십시오.
• 이전은 「파일럿 → 기준선 정책 → 앱 배포 → 기존 PC의 자연 교체 → AD 역할 축소」의 다섯 단계로 나아가고, 각 단계의 종료 기준을 먼저 정합니다.
• 이중 적용 충돌은 기본적으로 GPO가 이깁니다. MDMWinsOverGP는 Policy CSP 전용 메커니즘이므로, 원칙은 「같은 설정을 양쪽에서 배포하지 않는 것」입니다.
• 서버 교체 견적이 도착한 때가 이 이전을 검토하기 가장 좋은 때입니다. 「AD의 다음 주기」보다 먼저, 앞으로 5년의 PC가 어디서 쓰일지를 생각하십시오.

관련 기사

• 그룹 정책(GPO) 실무 입문 ── 구조・반영 확인・Intune과의 구분 사용
• WSUS 비권장 이후의 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 Settings catalog에는 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도 포함되어, 규정 준수 정책과 Conditional Access를 조합하는 데까지 갈 수 있습니다. Remediations 같은 일부 기능은 Windows Enterprise E3/E5급 라이선스가 별도로 필요합니다. 플랜 구성은 자주 바뀌므로, 계약 전에 Microsoft 공식 라이선스 페이지에서 최신을 확인하십시오(이 글은 2026년 8월 시점).

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

아닙니다. Entra join과 Intune으로 관리하는 PC와 AD 도메인 조인과 GPO로 관리하는 PC는 같은 사내 네트워크에서 공존할 수 있습니다. 파일 서버 인증과 기존 업무 시스템용으로 AD를 남기고, 새 PC만 Entra join하는 단계적 이전이 현실적입니다. 반대로 기존 도메인 조인 PC를 Entra join으로 「변환」하는 지원되는 방법은 없고 초기화(리셋)가 필요하므로, 기존 기기는 하드웨어 갱신 주기에서 교체하는 것이 자리 잡은 패턴입니다. GPO가 비고 남은 역할을 목록화한 뒤에 AD 폐기를 검토하면 충분합니다.

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

GPO는 PC가 도메인 컨트롤러에 도달할 수 있을 때 가져와 적용되기 때문입니다. 사무실 밖 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 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.