그룹 정책(GPO) 실무 입문 ── 구조・반영 확인・Intune과의 구분 사용

「이 설정은 GPO로 배포되어 있습니다」「고객사 PC는 그룹 정책으로 묶여 있어서」── Windows 업무 시스템에 관여하다 보면 이 「GPO」라는 말은 일상적으로 오갑니다. 그런데 막상 자신이 AD 환경의 정보시스템 업무를 인계받거나, 고객사의 도메인 참가 PC에 앱을 도입하려는 단계가 되면, 그룹 정책이 언제・어디서부터・어떤 우선순위로 적용되는지를 정확히 설명할 수 있는 사람은 의외로 많지 않습니다.

「설정을 바꿨는데 반영되지 않는다」「gpupdate를 실행하라고 들었지만 무슨 일이 일어나는지 모르겠다」「개발기에서는 동작하는 앱이 고객사에서만 동작하지 않아 조사해 보니 GPO였다」── 이 글은 이러한 상황에 맞닥뜨리는 업무 앱 개발자와, AD 환경을 인계받은 중소기업의 정보시스템 담당자를 대상으로, 그룹 정책의 구조(LSDOU 적용 순서), 반영 타이밍, gpresult와 이벤트 로그를 이용한 원인 분리, ADMX와 중앙 저장소, 그리고 Intune(MDM)과의 구분 사용까지를 2026년 8월 시점의 1차 정보를 바탕으로 정리합니다.

1. 먼저 결론

• 그룹 정책은 「나중이 이깁니다」. 로컬→사이트→도메인→OU(LSDOU) 순으로 처리되며, 나중에 처리된 GPO가 충돌 시 우선됩니다. 로컬 GPO(gpedit.msc)는 가장 약한 계층입니다.¹
• 반영 타이밍은 「전경+백그라운드」입니다. 컴퓨터 구성은 시작 시, 사용자 구성은 사인인 시에 반드시 적용되며, 여기에 더해 기본값으로 약 90분+0~30분의 무작위 오프셋으로 백그라운드 업데이트됩니다(도메인 컨트롤러는 5분).²
• gpupdate /force는 「모든 설정의 재적용」일 뿐, 만능은 아닙니다. 소프트웨어 설치나 폴더 리디렉션처럼 사인인이나 재시작 때만 처리되는 설정이 있습니다(/logoff・/boot 옵션이 존재하는 이유입니다).³
• 원인 분리의 출발점은 gpresult /h의 RSoP 보고서입니다. 적용된 GPO와 거부된 GPO(이유 포함)를 볼 수 있습니다. 더 깊이 파고들 때는 GroupPolicy 운영 로그(Microsoft-Windows-GroupPolicy/Operational)를 이용합니다.⁴⁵
• 관리용 템플릿의 정책은 원칙적으로 레지스트리의 정책 전용 키(Software\Policies 등)에 기록됩니다. 정책 값은 앱 고유의 설정보다 우선되며, 「구성되지 않음」은 아무것도 기록하지 않습니다. 다만 전용 키 바깥에 쓰는 정책도 일부 있습니다(5장).⁶
• ADMX의 중앙 저장소는 SYSVOL의 PolicyDefinitions 폴더입니다. 만들어 두면 GPMC가 도메인 공통의 템플릿 정의를 참조하게 됩니다.⁷
• GPO냐 Intune이냐는 단말의 아이덴티티 기반으로 정합니다. 같은 설정을 양쪽에서 구성하면 결과가 보장되지 않습니다. 이행 검토에는 Group Policy analytics를 사용할 수 있습니다.⁸⁹
• 개발자에게 GPO는 「고객사에서만 동작하지 않는다」의 단골 원인입니다. 실행 정책, 방화벽의 로컬 규칙 병합 비활성화, 프록시・드라이브 구성 등 앱의 전제를 바꾸는 설정이 중앙 관리로 배포되고 있습니다.¹⁰¹¹

2. 그룹 정책이란 무엇인가 ── 로컬 GPO와 도메인 GPO

그룹 정책은 Windows의 설정을 관리자가 중앙에서 정의하고, 대상 컴퓨터와 사용자에게 강제로 적용하는 구조입니다. 설정 묶음을 GPO(그룹 정책 개체)라고 부릅니다. GPO에는 두 가지 저장 위치가 있습니다.

워크그룹(도메인 비참가)의 PC가 처리하는 것은 로컬 GPO뿐입니다.¹ 즉 「GPO로 관리되고 있다」라고 말할 때, 실무상으로는 거의 도메인 GPO를 가리킵니다.

어느 GPO든 내용은 크게 두 계통으로 나뉩니다.

• 컴퓨터 구성: 그 PC에 사인인하는 누구에게나 적용되는 설정. 시작 시에 적용됩니다.
• 사용자 구성: 그 사용자가 어느 PC에 사인인하든 적용되는 설정. 사인인 시에 적용됩니다.

「PC에 결부된 설정인가, 사람에게 결부된 설정인가」라는 축은 이후의 적용 순서에서도 반영 확인에서도 일관되게 등장합니다. 같은 항목이 양쪽 구성 모두에 존재하는 설정도 있으므로, 설정을 찾을 때는 반드시 양쪽 계통을 모두 살펴보는 습관을 들이세요.

3. 적용의 구조 ── LSDOU의 「나중이 이김」과 상속 제어

3.1. LSDOU: 로컬→사이트→도메인→OU

도메인 참가 PC에서 GPO는 다음 순서로 처리됩니다.¹

1. 로컬 GPO
2. 사이트에 링크된 GPO
3. 도메인에 링크된 GPO
4. OU(조직 구성 단위)에 링크된 GPO ── 상위 OU부터 순서대로 처리되고, 마지막으로 대상 컴퓨터/사용자가 직접 소속된 OU의 GPO가 처리됨

머리글자를 딴 LSDOU라고 불리는 순서입니다. 중요한 것은, 이것이 「우선순위가 높은 순」이 아니라 처리되는 순서라는 점입니다. 같은 설정을 여러 GPO가 구성하고 있는 경우, 나중에 처리된 GPO가 이깁니다(충돌하지 않는 설정은 단순히 합쳐집니다).¹ 즉 대상에 가장 가까운 OU의 GPO가 가장 강하고, 로컬 GPO가 가장 약합니다. 「gpedit.msc에서 고쳤는데 원래대로 돌아간다」는 고장이 아니라 이 사양대로의 동작입니다.

같은 사이트・도메인・OU에 여러 GPO가 링크되어 있는 경우에는, GPMC의 「링크된 그룹 정책 개체」 탭의 링크 순서로 결정됩니다. 링크 순서 번호가 가장 작은 GPO가 마지막에 처리되며, 가장 우선됩니다.¹

3.2. 상속 차단과 강제(Enforced)

기본 순서에는 예외를 만들 수 있습니다.¹

• 상속 차단: 도메인이나 OU에 설정하면, 상위로부터의 GPO 상속을 멈출 수 있습니다. 「이 OU만은 전사 표준을 받고 싶지 않다」는 경우의 도구입니다.
• 강제(Enforced, 옛 명칭: 재정의 안 함): GPO 링크에 설정하면, 그 GPO는 하위에서 상속 차단되어 있어도 반드시 적용되며, 하위 GPO에 의해 덮어써지지 않게 됩니다. 상속 차단과 강제가 충돌할 때는 강제가 이깁니다.¹

강제는 「나중이 이김」의 원칙을 깨는 장치이므로, 많이 사용하면 RSoP를 읽어도 직관에 반하는 결과가 늘어납니다. 전사에서 반드시 지켜야 할 보안 설정에 한정하는 것이 정석입니다.

3.3. 보안 필터 처리

링크 위치뿐 아니라 누구에게 적용할 것인가도 GPO 단위로 좁힐 수 있습니다. GPO가 적용되려면, 대상 사용자 또는 컴퓨터가 해당 GPO에 대해 「읽기」와 「그룹 정책 적용」의 두 가지 권한을 모두 가지고 있어야 합니다. 기본값으로는 Authenticated Users(사용자와 컴퓨터를 모두 포함)에 두 권한이 허용되어 있으므로, 링크 대상 하위 전원에게 적용됩니다. 이를 특정 보안 그룹으로 좁히는 것이 보안 필터 처리입니다. 필터는 GPO 전체에 작용하는 것으로, GPO 안의 설정마다 바꿀 수는 없습니다.¹³

한 가지 중요한 주의점이 있습니다. 적용 대상을 좁힐 때, 기본값인 Authenticated Users에서 「읽기」까지 제거해서는 안 됩니다. 보안 업데이트 프로그램 MS16-072(2016년) 이후, 사용자용 정책은 컴퓨터의 보안 컨텍스트로 취득되기 때문에, 컴퓨터 계정이 GPO를 읽을 수 없으면 대상 사용자에게 두 권한을 모두 주었더라도 사용자용 GPO가 적용되지 않게 됩니다.¹⁴ 좁힐 때는 대상 그룹에 「읽기+그룹 정책 적용」을 부여한 상태에서, Authenticated Users(또는 Domain Computers)에는 「읽기」만 남겨 두는 것이 올바른 형태입니다.¹⁴

실무에서는 「그룹에 넣었는데 적용되지 않는다(컴퓨터용 설정인데 사용자만 그룹에 넣었다)」「그룹에서 뺐는데도 계속 적용된다」가 단골 함정입니다. 후자는 백그라운드 업데이트를 기다려도 해소되지 않습니다. 그룹 멤버십은 사인인 시에 생성된 보안 토큰으로 평가되기 때문에, 사용자의 그룹 변경은 사인아웃→사인인, 컴퓨터의 그룹 변경은 재시작을 거쳐 새로운 토큰이 되어야 비로소 필터에 반영됩니다.

또한 공유 PC나 원격 데스크톱 서버처럼 「그 PC에 사인인한 사람 전원에게 사용자 구성을 바꿔치고 싶다」는 상황을 위한 루프백 처리라는 특수 모드도 있습니다(컴퓨터의 위치를 바탕으로 사용자 설정을 적용하는 구조로, 대체와 병합의 2가지 모드가 있습니다).¹⁵ 키오스크 단말이나 교실 PC에서 사용되는 응용 기능이므로, 이 글에서는 존재를 소개하는 데 그칩니다.

4. 언제 반영되는가 ── 전경 처리와 백그라운드 업데이트

「설정했는데 반영되지 않는다」의 절반은 단순히 아직 적용 타이밍이 오지 않았을 뿐입니다. 적용에는 두 종류가 있습니다.²

즉 도메인 컨트롤러에 도달할 수 있는 가동 중인 단말이라면, GPO를 변경한 뒤 아무것도 하지 않아도 백그라운드 업데이트에 대응하는 설정은 2시간 정도면 다 퍼집니다. 오프라인 단말이나 VPN 미연결 상태로 반출된 PC에는, 다음에 DC에 연결될 때까지 도달하지 않습니다. 전경 처리에서만 적용되는 설정은, 여기에 더해 시작이나 사인인을 기다려야 합니다. 서두를 경우에는 대상 PC에서 gpupdate를 실행합니다. 기본값으로는 변경이 있었던 설정만 적용되고, /force를 붙이면 변경 여부와 관계없이 모든 설정을 재적용합니다.³

rem 변경분만 업데이트(보통은 이것으로 충분)
gpupdate

rem 모든 설정을 재적용(캐시된 상태를 의심할 때)
gpupdate /force

주의해야 할 것은 gpupdate로는 반영되지 않는 설정이 있다는 점입니다. 사용자용 소프트웨어 설치나 폴더 리디렉션은 사인인 시, 컴퓨터용 소프트웨어 설치는 시작 시에만 처리됩니다. gpupdate에는 이를 위한 /logoff(업데이트 후 사인아웃)와 /boot(업데이트 후 재시작) 옵션이 마련되어 있습니다.³ 「gpupdate /force를 실행했는데도 들어가지 않는다」며 소란 피우기 전에, 그 설정이 재시작・사인인을 필요로 하는 종류가 아닌지 확인하세요.

5. 반영되지 않을 때의 원인 분리 ── gpresult・이벤트 로그・레지스트리

5.1. gpresult /h로 RSoP를 확인한다

여러 GPO가 겹쳐진 최종 결과(RSoP: 정책 결과 집합)를 확인하는 표준 도구가 gpresult입니다. 관리자 권한의 명령 프롬프트에서 HTML 보고서를 출력하는 것이 가장 읽기 쉬운 방법입니다.⁴⁵

rem 사용자+컴퓨터 양쪽의 RSoP를 HTML 보고서로 출력
gpresult /h C:\temp\gp-report.html /f

rem 콘솔에서 개요만 확인하는 경우
gpresult /r
gpresult /scope computer /r

보고서에서 가장 먼저 봐야 할 것은 다음 세 가지입니다.

1. 적용된 GPO 목록 ── 목표한 GPO가 들어 있는지
2. 거부된 GPO 목록과 이유 ── 보안 필터, WMI 필터, 빈 GPO 등, 적용되지 않은 이유가 표시됩니다⁵
3. 설정별 「우선하는 GPO」 ── 목표한 설정이 어느 GPO의 값으로 정해졌는지. 다른 GPO가 이기고 있다면 3장의 우선순위를 재검토합니다

5.2. GroupPolicy 운영 로그

gpresult로 부족할 때(애초에 처리가 실패한다, 시간이 너무 오래 걸린다 등)는 이벤트 뷰어의 GroupPolicy 운영 로그를 봅니다. 위치는 「응용 프로그램 및 서비스 로그 > Microsoft > Windows > GroupPolicy > Operational」(로그 이름 Microsoft-Windows-GroupPolicy/Operational)입니다. 여기에는 정책 처리의 시작부터 종료까지가, 적용된 GPO 목록・거부된 GPO 목록(이유 포함)과 함께 기록됩니다. 정책 처리 1회마다 고유한 ActivityID가 할당되므로, 시스템 로그의 경고・오류 이벤트에서 ActivityID를 뽑아, 사용자 지정 보기로 그 한 번분만을 좁혀 보는 것이 Microsoft 권장 절차입니다.⁵

5.3. 레지스트리의 Policies 키와의 관계

관리용 템플릿(다음 장)의 정책은 최종적으로 레지스트리 값으로 기록됩니다. 기록되는 위치는 원칙적으로 다음의 정책 전용 키입니다.⁶

• HKEY_LOCAL_MACHINE\Software\Policies(컴퓨터 구성. 권장 위치)
• HKEY_CURRENT_USER\Software\Policies(사용자 구성. 권장 위치)
• HKLM\Software\Microsoft\Windows\CurrentVersion\Policies / HKCU\Software\Microsoft\Windows\CurrentVersion\Policies

여기에는 중요한 설계 사상이 있습니다. 정책에 대응한 앱은 먼저 Policies 키를 읽고, 값이 있으면 그것을 우선하며, 없으면 자신의 설정(프리퍼런스)이나 기본값을 사용하는 방식으로 동작합니다. 「구성되지 않음」인 정책은 레지스트리에 아무것도 쓰지 않습니다.⁶ 즉 관리용 템플릿의 정책은 앱 자체의 설정을 바꿔써서 「문신(tattooing)」을 남기는 것이 아니라, 별도 위치에 놓인 강제 값이 우선 참조되는 구조입니다. 정책 구성을 그만두면, 앱은 자신의 설정값을 따르는 상태로 돌아갈 수 있습니다.

다만 모든 정책이 전용 키에 기록되는 것은 아닙니다. OS 내장 설정 중 일부(예를 들어 「Win32 긴 경로 사용」은 HKLM\SYSTEM\CurrentControlSet\Control\FileSystem의 LongPathsEnabled에 기록됩니다)나, 구세대・서드파티 제품의 템플릿에는 전용 키 바깥의 임의 경로에 쓰는 것이 있습니다. 이런 종류의 설정은 정책 구성을 그만두어도 값이 그대로 남습니다. 목표한 설정이 실제로 어느 키에 쓰는지는 ADMX의 정의나 설정 설명문, gpresult 보고서로 확인하세요.

거꾸로 말하면, 앞서 말한 얌전한 동작은 관리용 템플릿(정책 전용 키)의 틀 안에서만 성립하는 이야기입니다. 스크립트나 그룹 정책 기본 설정(Preferences)으로 Policies 키 바깥에 쓴 값은 일반 레지스트리 값과 같아서, 배포를 그만두어도 자동으로 원래대로 돌아가는 구조는 이 틀 밖에 있습니다. 원인 분리 실무에서는 「목표한 설정이 Policies 키에 쓰여 있는가」를 직접 보는 것이 빠르고 확실합니다.

# 정책으로 배포된 값을 직접 확인하는 예(많은 정책은 Policies 아래에 쓰임)
Get-ChildItem "HKLM:\SOFTWARE\Policies" -Recurse | Select-Object Name
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\System" -ErrorAction SilentlyContinue

6. 관리용 템플릿(ADMX)과 중앙 저장소

GPMC의 「관리용 템플릿」에 나열되는 설정 항목의 정의는 ADMX 파일(설정 정의 본체)과 ADML 파일(언어별 표시 문자열)로 기술되어 있습니다. 각 PC에는 C:\Windows\PolicyDefinitions에 OS 부속 정의가 들어 있으며, 관리 도구는 이를 읽어 설정 화면을 구성합니다.⁷

도메인에서 운영한다면 중앙 저장소를 만드는 것이 기본입니다. 도메인 컨트롤러의 SYSVOL 아래에 PolicyDefinitions 폴더를 만들면(예: \\contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions), 그 내용은 도메인 내 모든 도메인 컨트롤러에 복제되고, 그룹 정책 도구는 기본값으로 중앙 저장소를 참조하게 됩니다.⁷ 이렇게 하면 「편집하는 관리 단말마다 템플릿 버전이 달라 보이는 설정 항목이 어긋나는」 문제가 없어집니다. ADML은 언어별 하위 폴더(한국어라면 ko-KR)에 둡니다.⁷

운영상 주의할 점은 두 가지입니다. 첫째, 새 Windows 버전용 ADMX는 Microsoft가 버전마다 배포하고 있으며, 업데이트할 때는 중앙 저장소 쪽을 교체합니다. 각 PC의 C:\Windows\PolicyDefinitions를 다운로드판으로 치환하는 것은 지원되지 않습니다.⁷ 둘째, 기존 중앙 저장소를 업데이트할 때는 운영 중인 PolicyDefinitions를 직접 덮어쓰지 말고, PolicyDefinitions-24H2와 같은 버전 이름의 작업 폴더에 OS분과 앱분(Office나 Edge 등)의 ADMX 일체를 갖춘 뒤, 현재 폴더를 PolicyDefinitions-23H2 등으로 이름을 바꿔 대피시키고, 작업 폴더를 PolicyDefinitions로 이름을 바꿔 운영에 반영하는 절차가 안내되고 있습니다.⁷ 그룹 정책 도구가 참조하는 것은 PolicyDefinitions라는 이름의 폴더뿐이므로, 버전 이름 폴더에 두기만 해서는 반영되지 않습니다. 문제가 생기면 대피시킨 예전 폴더로 되돌릴 수 있다는 것이 이 방식의 장점입니다.⁷

7. GPO vs Intune(MDM/CSP) vs 수동・스크립트 ── 판단표

Windows 단말의 구성 관리 선택지는 이제 GPO만이 아닙니다. Intune으로 대표되는 MDM은 CSP(구성 서비스 공급자)라는 구조를 통해 OS 설정을 구성합니다. 어느 것을 축으로 삼을지에 대한 판단표입니다.

판단의 축은 단순해서, 단말의 아이덴티티 기반(AD인가, Microsoft Entra인가)과 단말이 어디에 있는가입니다. 온프레미스 AD에 완전히 참가한 사내 거치형 PC 집단에는 GPO가 가장 확실하고, Entra 참가 모바일 PC에는 GPO가 애초에 도달하지 않습니다.

현실의 중소기업은 그 중간, 즉 하이브리드(도메인 참가+Intune 등록)인 경우가 많으며, 여기서 최악인 것이 「같은 설정을 GPO와 MDM 양쪽에서 구성한다」는 것입니다. Policy CSP에는 GPO와 MDM이 충돌했을 때 MDM을 이기게 하는 MDMWinsOverGP라는 정책이 있지만, 적용 범위는 Policy CSP 내의 대응 정책에 한정됩니다. Microsoft 스스로가 이 제어 아래에 있지 않은 설정을 GPO와 MDM 양쪽에서 구성하면 경합 상태가 되어 어느 쪽이 이길지 보장되지 않는다고 명언하며 이중 구성을 피하도록 밝히고 있습니다.⁸ 설정 영역마다 「이것은 GPO, 이것은 Intune」이라고 관리 주체를 정해 한쪽으로 몰아주는 것이 하이브리드 운영의 제1원칙입니다.

GPO에서 Intune으로의 이행을 고려하는 단계에서는 Intune의 Group Policy analytics가 입구가 됩니다. GPMC에서 내보낸 GPO(XML)를 가져오면, 각 설정이 MDM으로 지원되는지, 비권장・대응 불가인지를 분석할 수 있으며, 대응이 끝난 설정은 Intune의 설정 카탈로그 정책으로 이행할 수 있습니다.⁹ 「전부 옮긴다」가 아니라 「옮길 수 있는 것・옮길 수 없는 것・버릴 것을 분류한다」를 위한 도구로 파악하는 것이 실태에 맞습니다. 참고로 Windows Update의 관리 주체도 같은 맥락에서 재편이 진행되고 있습니다. 「WSUS 지원 종료 후의 Windows Update 관리」도 함께 참조하세요.

8. 개발자 관점의 함정 ── 고객사 GPO가 앱의 동작을 바꾼다

마지막으로 수탁 개발의 입장에서 짚어 둬야 할 이야기입니다. 고객사의 GPO는 여러분의 앱이 전제로 삼는 조건을 조용히 바꿔버립니다. 「개발기에서는 동작하는데 고객사에서는 동작하지 않는다」의 원인 중 하나로, 방화벽이나 백신과 나란히 GPO는 단골입니다. 실례를 바탕으로 들어 보겠습니다.

• PowerShell의 실행 정책: 실행 정책은 GPO로 중앙 구성할 수 있으며, GPO에서 비롯된 MachinePolicy/UserPolicy 범위는 로컬이나 프로세스에서 설정한 값보다 항상 우선됩니다.¹⁰ 설치 프로그램이나 운영 스크립트가 「-ExecutionPolicy Bypass를 붙이면 동작할 것」이라는 전제로 만들어져 있다면, GPO 관리 하에서는 시작조차 되지 않습니다. 자세한 내용은 「PowerShell의 실행 정책과 스크립트 서명」을 참조하세요.
• 방화벽의 로컬 규칙 병합 비활성화: GPO/Intune으로 방화벽을 중앙 관리하는 환경에서는 프로필 단위로 「로컬 규칙 병합」(AllowLocalPolicyMerge)을 비활성화할 수 있습니다. 비활성화된 환경에서는 설치 프로그램이 로컬에 등록한 인바운드 규칙이 존재하더라도 적용되지 않습니다.¹¹ 서버형 앱 도입 전에 반드시 확인해야 할 포인트로, 「Windows 방화벽과 업무 앱」에서 자세히 다루고 있습니다.
• 드라이브 할당・프록시 등의 환경 구성: 네트워크 드라이브 할당이나 프린터 등은 그룹 정책 기본 설정(Preferences)으로 배포되는 것이 정석입니다.¹⁶ 「Z 드라이브가 있을 것」「프록시는 직결일 것」과 같은 환경 가정은, 사인인하는 사용자나 PC가 소속된 OU에 따라 무너집니다. 사용자 구성으로 배포된 설정이 서비스나 작업의 실행 계정에는 당연히 적용되지 않는다는 점도 상주형 앱에서는 간과하기 쉽습니다.
• 애초에 설정을 「되돌릴 수 없음」: 관리용 템플릿에서 비롯된 설정은 사용자가 화면에서 바꿀 수 없게(항목이 회색으로 표시) 되어 있는 것이 보통입니다. 「고객사 쪽에서 설정을 바꿔 달라고 하면 해결됩니다」가 통하지 않는다는 점은, 대응 방침 설계에 영향을 줍니다.

개발 측의 현실적인 대비는 세 가지입니다. 첫째, 앱이 의존하는 환경 전제(실행 정책, 대기 포트, 쓰기 대상, 프록시 경로 등)를 도입 요건으로 문서화하고, 도입 전에 고객사 정보시스템에 확인을 요청합니다. 둘째, 문제 발생 시에는 억측이 아니라 gpresult /h의 보고서와 HKLM\Software\Policies 아래의 실제 값을 확인합니다(5장). 셋째, 관리자 권한이 필요한 처리와 그렇지 않은 처리를 설계 단계에서 분리해 두는 것입니다(이 구분은 「Windows의 관리자 특권이 필요해지는 것은 언제인가」에서 다루고 있습니다). GPO는 적이 아니라 환경의 사양입니다. 사양으로 취급하면 원인 분리는 기계적으로 할 수 있습니다.

9. 정리

• 그룹 정책은 GPO 단위의 설정을 로컬→사이트→도메인→OU(LSDOU) 순으로 처리하는 구조로, 충돌은 나중이 이깁니다. 대상에 가까운 OU의 GPO가 가장 강하고, 로컬 GPO가 가장 약한 계층입니다.
• 상속 차단・강제(Enforced)・보안 필터 처리로 기본 흐름을 제어할 수 있습니다. 강제는 상속 차단에도 이기므로, 많이 사용해서는 안 됩니다.
• 적용은 시작 시・사인인 시의 전경 처리와, 기본값 약 90분+무작위 오프셋의 백그라운드 업데이트라는 두 축으로 이루어집니다. gpupdate /force는 모든 설정의 재적용이며, 사인인이나 재시작 때만 처리되는 설정에는 효과가 없습니다.
• 반영되지 않을 때는 gpresult /h → GroupPolicy 운영 로그 → 레지스트리의 Policies 키 순서로 기계적으로 원인을 분리합니다. 거부된 GPO에는 이유가 표시됩니다.
• 관리용 템플릿의 정의는 ADMX/ADML이며, 도메인 운영에서는 SYSVOL의 중앙 저장소로 집약합니다. 업데이트 시에는 로컬의 PolicyDefinitions를 치환하는 것이 아니라 중앙 저장소 쪽을 교체합니다.
• GPO냐 Intune이냐는 단말의 아이덴티티 기반과 소재로 정하며, 하이브리드에서는 같은 설정의 이중 구성을 피하고 관리 주체를 한쪽으로 몰아줍니다. 이행 분류에는 Group Policy analytics를 사용할 수 있습니다.
• 개발자에게 고객사 GPO는 환경 사양의 일부입니다. 실행 정책・방화벽・드라이브나 프록시 구성 등의 전제를 문서화하고, gpresult로 확인할 수 있는 체제를 갖춰 두면 「고객사에서만 동작하지 않는다」의 상당 부분은 두렵지 않습니다.

관련 글

• Windows 방화벽과 업무 앱 ── 인바운드 규칙은 인스톨러에서 등록한다
• WSUS 비권장 이후의 Windows Update 관리 ── WUfB·Autopatch·Intune을 어떻게 선택할까
• PowerShell의 실행 정책과 스크립트 서명 ── ‘Bypass로 덮어버리는’ 운영에서 벗어나는 실무 가이드
• winget + PowerShell로 PC 키팅을 자동화하기 ── 절차서를 실행 가능하게 만들기
• IE 모드 의존 시스템 탈피 가이드
• Windows의 관리자 특권이 필요해지는 것은 언제인가 - UAC, 보호 영역, 설계상의 구분 방법

관련 상담 영역

합동회사 코무라소프트에서는 GPO 관리 하의 고객사 환경에서 업무 앱이 동작하지 않는 현상의 원인 조사, 도입 요건(실행 정책・방화벽・네트워크 전제)의 정리, AD 환경을 인계받은 정보시스템 담당자를 위한 정책 실사(inventory)나 Intune 병용 방침에 관한 기술 상담을 다루고 있습니다. 「gpresult 보고서를 함께 읽어 봐 줬으면 한다」와 같은 단계부터도 괜찮습니다.

• 기술 상담・설계 리뷰
• 불량・오류 조사・원인 분석
• Windows 앱 개발
• 문의하기

참고 링크

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

gpupdate /force를 실행했는데도 설정이 반영되지 않습니다. 왜 그런가요?

먼저 그 설정이 「백그라운드 업데이트로는 반영되지 않는 종류」가 아닌지 확인하세요. 사용자용 소프트웨어 설치나 폴더 리디렉션은 사인인 시에, 컴퓨터용 소프트웨어 설치는 시작 시에만 처리되기 때문에, gpupdate가 끝난 뒤 사인아웃(/logoff)이나 재시작(/boot)이 필요합니다. 다음으로 gpresult /h로 RSoP 보고서를 출력해, 해당 GPO가 「적용된 GPO」에 들어 있는지, 「거부된 GPO」에 이유와 함께 들어 있지는 않은지 확인합니다. 적용되었는데도 동작이 바뀌지 않는다면, 우선순위가 더 높은 다른 GPO가 같은 설정을 덮어쓰고 있을(나중이 이김) 가능성을 의심해 보세요. 보고서에는 각 설정의 「우선하는 GPO」가 표시되므로, 어느 GPO가 이기고 있는지까지 특정할 수 있습니다.

gpresult에 「필터로 거부됨」이라고 표시되는 것은 무슨 의미인가요?

그 GPO는 링크된 위치상으로는 대상에 포함되어 있지만, 필터 처리에 의해 적용 대상에서 제외되었다는 의미입니다. 대표적인 원인은 보안 필터 처리로, GPO를 적용하려면 사용자 또는 컴퓨터가 해당 GPO에 대해 「읽기」와 「그룹 정책 적용」 두 가지 권한을 모두 가지고 있어야 합니다. 기본값으로는 Authenticated Users에 두 권한이 모두 허용되어 있지만, 특정 그룹으로 좁히는 운영을 하는 경우 그룹에 추가하는 것을 빠뜨리거나 컴퓨터 계정을 넣는 것을 잊으면 거부됩니다. 또한 사용자용 GPO에서는 대상 사용자에게 두 권한을 주는 것만으로는 부족합니다. MS16-072 이후, 사용자 정책은 컴퓨터의 보안 컨텍스트로 취득되므로, Authenticated Users 또는 Domain Computers에 「읽기」(「적용」은 불필요)를 남겨 두어야 합니다. 이 밖에 WMI 필터의 조건 불일치나, GPO 쪽에서 사용자/컴퓨터 측 설정이 비활성화되어 있는 경우도 있습니다. 거부 이유는 gpresult 보고서와 GroupPolicy 운영 로그 양쪽에 기록됩니다.

GPO와 Intune 중 어느 쪽으로 관리해야 하나요?

단말의 아이덴티티 기반에 맞추는 것이 기본입니다. 온프레미스 AD에 도메인 참가한 단말이 중심이고 사내 네트워크에 항상 연결되어 있다면, GPO가 가장 확실하고 세밀도도 높은 선택지입니다. Microsoft Entra 참가 단말이나 도메인 컨트롤러에 연결되지 않는 재택 단말이 늘고 있다면, 사외에서도 구성이 전달되는 Intune(MDM/CSP)이 적합합니다. 두 가지가 혼재하는 하이브리드 환경에서는 같은 설정을 GPO와 MDM 양쪽에서 구성하면 충돌해 결과가 보장되지 않으므로, 설정 영역별로 어느 쪽으로 관리할지 정해 한쪽으로 몰아주는 것이 원칙입니다. 이행을 검토하는 단계에서는 Intune의 Group Policy analytics로 기존 GPO를 가져오면, MDM으로 대응 가능한 설정과 미대응・비권장 설정을 분류할 수 있습니다.

로컬 그룹 정책(gpedit.msc)에서 설정한 내용이 도메인의 설정으로 덮어써집니다. 사양인가요?

사양입니다. 그룹 정책은 로컬→사이트→도메인→OU 순(LSDOU)으로 처리되며, 나중에 처리된 것이 충돌 시 이기기 때문에 로컬 GPO는 가장 약한 계층이 됩니다. 도메인 GPO가 같은 설정을 구성하고 있다면, 로컬에서의 변경은 항상 덮어써집니다. 반대로 도메인 쪽이 「구성되지 않음」으로 두고 있는 설정이라면, 로컬 GPO의 값이 그대로 유지됩니다. 검증 등에서 아무래도 로컬 설정을 우선하고 싶은 경우에도, 도메인 참가 PC에서 이 우선순위를 뒤집을 방법은 없으므로, 검증용 OU를 만들어 도메인 쪽 GPO를 조정하거나 도메인 비참가 검증기를 사용하는 것이 현실적입니다.

개발한 업무 앱이 고객사 환경에서만 동작하지 않습니다. GPO가 원인인지 확인하는 방법이 있나요?

고객사 관리자에게 부탁해서 문제가 있는 PC에서 관리자 권한 명령 프롬프트로 gpresult /h report.html을 실행하게 하여 RSoP 보고서를 확인하는 것이 첫걸음입니다. 실행 정책에 의한 스크립트 정지, 방화벽의 로컬 규칙 병합 비활성화, 프록시나 드라이브 할당 구성 등, 앱의 동작을 바꾸는 설정이 적용되어 있지 않은지 살펴봅니다. 함께 레지스트리의 HKLM\Software\Policies와 HKCU\Software\Policies 아래에 관련 제품의 정책 값이 쓰여 있지 않은지 확인하면, 관리용 템플릿에서 비롯된 강제 설정을 기계적으로 찾아낼 수 있습니다. 개발 측에서 할 수 있는 대비로는, 앱이 의존하는 전제(실행 정책, 수신 포트, 쓰기 대상 폴더 등)를 도입 절차서에 명기하고, 도입 전에 고객사 정보시스템 담당에게 확인을 요청하는 것입니다.

저자 프로필

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

Go Komura

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

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