그룹 정책(GPO) 실무 입문 ── 동작 방식·적용 확인·Intune과의 역할 분담

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

「설정을 바꿨는데 적용되지 않는다」「gpupdate를 실행하라는데 무슨 일이 일어나는지 모르겠다」「개발 PC에서는 되는 앱이 고객사에서만 안 되고, 들여다보니 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인지는 단말의 ID 기반으로 정합니다. 같은 설정을 양쪽에서 구성하면 결과가 보장되지 않습니다. 이전을 검토할 때는 Group Policy analytics를 쓸 수 있습니다.⁸⁹
• 개발자에게 GPO는 「고객사에서만 안 된다」의 단골 원인입니다. 실행 정책, 방화벽의 로컬 규칙 병합 비활성화, 프록시·드라이브 구성처럼 앱의 전제를 바꾸는 설정이 중앙 관리로 배포됩니다.¹⁰¹¹

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

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

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

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

flowchart TB
    accTitle: 워크그룹 PC와 도메인 가입 PC가 처리하는 GPO
    accDescr: 워크그룹 PC가 처리하는 것은 로컬 GPO뿐이며, 도메인 가입 PC는 로컬 GPO에 더해 Active Directory에서 배포되는 도메인 GPO도 처리한다
    pc{"PC의 가입 형태는?"}
    pc -->|워크그룹| wg["로컬 GPO만 처리"]
    pc -->|도메인 가입| dom["로컬+도메인 GPO"]
    dom -.-> note["실무의 GPO는 거의 도메인 GPO"]

그림 1: 워크그룹 PC는 로컬 GPO만 처리하고, 도메인 가입 PC는 도메인 GPO도 처리한다.

어느 GPO든 내용은 크게 두 계통입니다.

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

「PC에 묶인 설정인가, 사람에 묶인 설정인가」라는 축은 이후의 적용 순서에서도 적용 확인에서도 그대로 나옵니다. 같은 항목이 양쪽 구성에 있는 설정도 있으므로, 설정을 찾을 때는 반드시 두 계통을 모두 보는 습관을 들이세요.

flowchart TB
    accTitle: GPO 내용의 두 계통
    accDescr: 어느 GPO든 컴퓨터 구성과 사용자 구성의 두 계통이 있으며, 컴퓨터 구성은 시작 시에 적용되어 그 PC에 로그인하는 누구에게나 적용되고, 사용자 구성은 로그인 시에 적용되어 그 사용자가 어느 PC에 로그인하든 적용된다
    gpo["GPO의 내용"] --> comp["컴퓨터 구성"]
    gpo --> user["사용자 구성"]
    comp --> boot["시작 시에 적용"]
    user --> logon["로그인 시에 적용"]
    boot -.-> anyone["로그인하는 누구에게나 적용"]
    logon -.-> anypc["어느 PC에서든 적용"]

그림 2: GPO에는 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에서 고쳤는데 원래대로 돌아간다」는 고장이 아니라 이 사양대로의 동작입니다.

flowchart TB
    accTitle: LSDOU의 처리 순서와 나중에 처리된 쪽이 이김
    accDescr: GPO는 로컬, 사이트, 도메인, OU 순으로 처리되며, 충돌 시에는 나중에 처리된 GPO가 이기므로 대상에 가까운 OU의 GPO가 가장 강하고 로컬 GPO가 가장 약하다
    l["1. 로컬 GPO"] --> s["2. 사이트"]
    s --> d["3. 도메인"]
    d --> ou["4. OU（상위부터 순서대로）"]
    ou --> win["충돌 시에는 나중에 처리된 쪽이 이김"]
    win -.-> strongest["대상에 가까운 OU의 GPO가 가장 강함"]
    win -.-> weakest["로컬 GPO가 가장 약함"]

그림 3: LSDOU는 처리되는 순이며, 같은 설정이 충돌하면 나중에 처리된 GPO가 이긴다.

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

flowchart TB
    accTitle: 같은 위치에 여러 GPO가 있을 때의 링크 순서
    accDescr: 같은 사이트나 도메인이나 OU에 여러 GPO가 링크되어 있으면 GPMC의 링크 순서로 처리 순이 정해지며, 번호가 가장 작은 GPO가 마지막에 처리되어 가장 우선한다
    multi["같은 위치에 여러 GPO"] --> tab["GPMC의 링크 순서로 결정"]
    tab --> last["번호가 가장 작은 GPO가 마지막에 처리"]
    last --> win["나중에 처리된 쪽이 이겨 가장 우선"]

그림 4: 같은 링크 대상에서는 링크 순서 번호가 가장 작은 GPO가 마지막에 처리되어 이긴다.

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

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

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

flowchart TB
    accTitle: 상속 차단과 강제의 관계
    accDescr: 상속 차단은 상위로부터의 GPO 상속을 멈추지만, 강제된 GPO는 하위에서 상속이 차단되어 있어도 반드시 적용되고 하위 GPO에도 덮어씌워지지 않는다
    upper["상위로부터의 GPO"] --> blocked{"하위에서 상속 차단?"}
    blocked -->|아니요| inherit["그대로 상속됨"]
    blocked -->|예| enforced{"GPO에 강제 설정?"}
    enforced -->|아니요| stop["상속이 멈춤"]
    enforced -->|예| apply["반드시 적용됨"]
    apply -.-> noover["하위 GPO에 덮어씌워지지 않음"]

그림 5: 상속 차단은 상위로부터의 상속을 멈추지만, 강제된 GPO는 차단을 넘어 반드시 적용된다.

강제는 「나중에 처리된 쪽이 이김」 원칙을 깨는 장치이므로, 많이 쓰면 RSoP를 읽어도 직관에 어긋나는 결과가 늘어납니다. 전사에서 반드시 지키게 할 보안 설정에만 쓰는 것이 정석입니다.

3.3. 보안 필터 처리

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

한 가지 중요한 주의가 있습니다. 적용 대상을 좁힐 때 기본값인 Authenticated Users에서 「읽기」까지 빼면 안 됩니다. 보안 업데이트 MS16-072(2016년) 이후 사용자 쪽 정책은 컴퓨터의 보안 컨텍스트로 가져오므로, 컴퓨터 계정이 GPO를 읽지 못하면 대상 사용자에게 두 권한을 주었더라도 사용자 쪽 GPO가 적용되지 않습니다.¹⁴ 좁힐 때는 대상 그룹에 「읽기+그룹 정책 적용」을 준 뒤, Authenticated Users(또는 Domain Computers)에는 「읽기」만 남기는 형태가 맞습니다.¹⁴

flowchart TB
    accTitle: 보안 필터의 적용 판정
    accDescr: GPO가 적용되려면 대상 사용자 또는 컴퓨터가 읽기와 그룹 정책 적용 권한을 모두 가져야 하며, 사용자 쪽 GPO는 여기에 더해 컴퓨터 계정이 읽을 수 있어야 한다
    target["GPO 링크 대상 하위의 대상"] --> perm{"읽기와 적용 권한 둘 다?"}
    perm -->|아니요| deny["필터로 거부"]
    perm -->|예| usergpo{"사용자 쪽 GPO?"}
    usergpo -->|아니요| apply["적용됨"]
    usergpo -->|예| comp{"컴퓨터가 읽기 가능?"}
    comp -->|예| apply
    comp -->|아니요| deny2["적용되지 않음（MS16-072）"]

그림 6: 적용에는 「읽기」와 「그룹 정책 적용」이 모두 필요하고, 사용자 쪽 GPO에서는 컴퓨터 계정의 읽기도 필요하다.

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

flowchart TB
    accTitle: 그룹 변경이 필터에 반영될 때까지
    accDescr: 그룹 멤버십은 로그인 때 만들어진 보안 토큰으로 평가되므로, 사용자 변경은 다시 로그인하고 컴퓨터 변경은 다시 시작해야 새 토큰이 되어 비로소 필터에 반영된다
    change["그룹 멤버를 변경"] --> old["이전 토큰 상태에서는 미반영"]
    old --> u["사용자는 다시 로그인"]
    old --> c["컴퓨터는 다시 시작"]
    u --> token["새 토큰으로 평가"]
    c --> token
    token --> ok["필터에 반영"]
    old -.-> bg["백그라운드 업데이트로는 풀리지 않음"]

그림 7: 그룹 변경은 로그오프나 다시 시작으로 새 토큰이 만들어진 뒤에야 필터에 반영된다.

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

flowchart TB
    accTitle: 루프백 처리의 생각법
    accDescr: 루프백 처리는 컴퓨터의 위치를 기준으로 사용자 구성을 적용하는 특수 모드로, 바꾸기와 병합의 두 모드가 있으며, 공유 PC나 키오스크 단말처럼 로그인한 사람 전원에게 같은 사용자 설정을 적용하고 싶을 때 쓰인다
    shared["공유 PC·키오스크 단말 등"] --> lb["루프백 처리"]
    lb --> base["컴퓨터의 위치로 정함"]
    base --> rep["바꾸기 모드"]
    base --> mrg["병합 모드"]
    lb -.-> aim["로그인한 전원에게 적용"]

그림 8: 루프백 처리는 컴퓨터의 위치를 기준으로 사용자 구성을 적용하는 특수 모드로, 바꾸기와 병합의 두 모드가 있다.

4. 언제 적용되는가 ── 포그라운드 처리와 백그라운드 업데이트

「설정했는데 적용되지 않는다」의 절반은 그저 아직 적용 시점이 오지 않았을 뿐입니다. 적용에는 두 종류가 있습니다.²

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

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

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

flowchart TB
    accTitle: DC 도달 가능 여부와 적용이 닿는 방식
    accDescr: 도메인 컨트롤러에 도달할 수 있는 가동 중인 단말에는 백그라운드 업데이트에 대응하는 설정이 2시간 정도면 퍼지지만, 오프라인이나 VPN 미연결 반출 PC에는 다음에 DC에 붙을 때까지 닿지 않는다
    pc{"DC에 도달할 수 있는가?"}
    pc -->|예| ok["2시간 정도면 퍼짐"]
    pc -->|아니요| ng["붙을 때까지 닿지 않음"]
    ng -.-> ex["오프라인이나 VPN 미연결 반출 PC"]

그림 9: DC에 도달할 수 있는 가동 중인 단말에는 2시간 정도면 퍼지지만, 오프라인 단말에는 다음에 DC에 붙을 때까지 닿지 않는다.

주의할 점은 gpupdate로는 적용되지 않는 설정이 있다는 것입니다. 사용자 쪽 소프트웨어 설치나 폴더 리디렉션은 로그인 시, 컴퓨터 쪽 소프트웨어 설치는 시작 시에만 처리됩니다. gpupdate에는 이를 위한 /logoff(업데이트 후 로그오프)와 /boot(업데이트 후 다시 시작) 옵션이 있습니다.³ 「gpupdate /force를 실행했는데도 안 들어간다」고 소란 피우기 전에, 그 설정이 다시 시작·로그인이 필요한 종류인지 확인하세요.

flowchart TB
    accTitle: 설정이 적용되는 경로
    accDescr: GPO 변경은 백그라운드 업데이트 대응 설정이면 기본 약 90분과 0~30분 오프셋으로 닿고, 포그라운드 처리에서만 적용되는 설정은 시작이나 로그인을 기다려야 하며, 급할 때의 gpupdate에도 포그라운드용 설정에는 /logoff나 /boot가 필요하다
    change["GPO를 변경"] --> kind{"백그라운드 업데이트에 대응하는가?"}
    kind -->|예| bg["약 90분+0~30분에 업데이트"]
    kind -->|아니요| fg["시작·로그인 시에 적용"]
    bg --> done["적용"]
    fg --> done
    rush["급할 때"] -.-> upd["gpupdate 실행"]
    upd -.-> force["/force로 전부 재적용"]
    upd -.-> reboot["포그라운드는 /logoff나 /boot"]

그림 10: 백그라운드 업데이트로 닿는 것은 대응하는 설정뿐이고, 포그라운드 처리에서만 적용되는 설정은 gpupdate 후에도 로그오프나 다시 시작이 필요하다.

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장의 우선순위를 다시 봅니다

flowchart TB
    accTitle: RSoP 보고서에서 먼저 볼 세 가지
    accDescr: gpresult 보고서에서는 먼저 적용된 GPO 목록에 목적한 GPO가 들어 있는지를 보고, 이어서 거부된 GPO 목록과 이유를 확인한 뒤, 마지막으로 설정마다의 우선하는 GPO로 어느 GPO 값이 이겼는지를 짚는다
    rep["RSoP 보고서를 연다"] --> one["1. 적용된 GPO 목록"]
    one --> two["2. 거부된 GPO와 이유"]
    two --> three["3. 설정마다의 우선하는 GPO"]
    three -.-> review["다른 GPO가 이겼다면 재검토"]

그림 11: RSoP 보고서는 적용된 GPO, 거부된 GPO와 이유, 설정마다의 우선하는 GPO 순으로 본다.

5.2. GroupPolicy 운영 로그

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

flowchart TB
    accTitle: GroupPolicy 운영 로그를 좁히는 절차
    accDescr: GroupPolicy 운영 로그에서는 정책 처리 한 번마다 고유한 ActivityID가 붙으므로, 시스템 로그의 경고나 오류에서 ActivityID를 집어 사용자 지정 보기로 그 한 번분의 이벤트만 좁혀 읽는다
    sys["시스템 로그의 경고·오류"] --> aid["ActivityID를 집음"]
    aid --> cv["사용자 지정 보기로 좁힘"]
    cv --> one["처리 한 번분의 이벤트를 읽음"]
    one -.-> rec["적용과 거부의 GPO 목록이 이유와 함께"]

그림 12: 운영 로그는 시스템 로그에서 ActivityID를 집어, 사용자 지정 보기로 정책 처리 한 번분만 좁혀 읽는다.

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 키를 읽고, 값이 있으면 그것을 우선하며, 없으면 자신의 설정(preference)이나 기본값을 쓰는 식으로 동작합니다. 「구성되지 않음」 정책은 레지스트리에 아무것도 쓰지 않습니다.⁶ 즉 관리 템플릿 정책은 앱 자체의 설정을 바꿔 써서 「문신(tattooing)」을 남기는 것이 아니라, 다른 곳에 둔 강제 값이 우선 참조되는 장치입니다. 정책 구성을 그만두면 앱은 자신의 설정값을 따르는 상태로 돌아갑니다.

flowchart TB
    accTitle: 정책 값과 앱 설정의 우선관계
    accDescr: 정책에 대응하는 앱은 먼저 Policies 키를 읽어 값이 있으면 그것을 우선하고, 없으면 자신의 설정이나 기본값을 쓰며, 구성되지 않음 정책은 레지스트리에 아무것도 쓰지 않는다
    app["정책 대응 앱이 설정을 읽음"] --> haspol{"Policies 키에 값이 있는가?"}
    haspol -->|예| pol["정책 값을 우선"]
    haspol -->|아니요| pref["자신의 설정이나 기본값을 사용"]
    notconf["구성되지 않음 정책"] -.-> nowrite["레지스트리에 아무것도 쓰지 않음"]

그림 13: 정책은 앱 자체의 설정을 바꿔 쓰는 것이 아니라, 다른 곳에 둔 강제 값이 우선 참조되는 장치이다.

다만 모든 정책이 전용 키에 쓰는 것은 아닙니다. 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

flowchart TB
    accTitle: 적용되지 않을 때의 원인 분리 절차
    accDescr: 먼저 gpresult의 RSoP 보고서로 적용된 GPO와 거부된 GPO를 확인하고, 부족하면 GroupPolicy 운영 로그를 ActivityID로 좁히며, 배포된 실제 값은 레지스트리의 Policies 키에서 직접 확인한다
    start["설정이 적용되지 않음"] --> rsop["gpresult /h로 RSoP 확인"]
    rsop --> found{"적용과 거부 이유를 알 수 있는가?"}
    found -->|예| fix["우선순위나 필터를 재검토"]
    found -->|아니요| oplog["GroupPolicy 운영 로그를 봄"]
    oplog -.-> aid["ActivityID로 한 번분만 좁힘"]
    rsop -.-> reg["Policies 키의 실제 값을 직접 확인"]

그림 14: 원인 분리는 gpresult /h를 출발점으로, 부족하면 GroupPolicy 운영 로그, 실제 값은 Policies 키를 직접 확인하는 식으로 기계적으로 진행한다.

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

GPMC의 「관리 템플릿」에 늘어선 설정 항목의 정의는 ADMX 파일(설정 정의 본체)과 ADML 파일(언어별 표시 문자열)로 적혀 있습니다. 각 PC에는 C:\Windows\PolicyDefinitions에 OS 기본 정의가 들어 있고, 관리 도구는 이를 읽어 설정 화면을 만듭니다.⁷

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

flowchart TB
    accTitle: 중앙 저장소의 구조
    accDescr: 도메인 컨트롤러의 SYSVOL 아래에 PolicyDefinitions 폴더를 만들면 내용이 모든 도메인 컨트롤러에 복제되고, 그룹 정책 도구가 기본값으로 중앙 저장소를 참조하므로 관리 단말마다 정의가 어긋나지 않는다
    create["SYSVOL 아래에 생성"] --> cs["PolicyDefinitions"]
    cs --> repl["모든 DC에 복제됨"]
    cs --> ref["GP 도구가 기본값으로 참조"]
    ref -.-> benefit["단말마다 정의가 어긋나지 않음"]
    cs -.-> adml["ADML은 언어별 폴더로"]

그림 15: SYSVOL의 PolicyDefinitions는 모든 도메인 컨트롤러에 복제되고, 그룹 정책 도구가 기본값으로 참조한다.

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

flowchart TB
    accTitle: 중앙 저장소 업데이트 절차
    accDescr: 업데이트는 버전 이름의 작업 폴더에 OS분과 앱분의 ADMX 일체를 모으고, 현재 폴더를 이름을 바꿔 빼 둔 뒤 작업 폴더를 운영 이름인 PolicyDefinitions로 이름을 바꾸며, 문제가 나면 빼 둔 이전 폴더로 되돌린다
    work["버전 이름의 작업 폴더"] --> gather["OS분과 앱분을 모음"]
    gather --> evac["현재 폴더를 이름을 바꿔 빼 둠"]
    evac --> rename["작업 폴더를 운영 이름으로"]
    rename --> live["운영으로 참조됨"]
    live -.-> back["문제 시 이전 폴더로 되돌림"]

그림 16: 업데이트는 작업 폴더에서 일체를 모으고, 현재 폴더를 빼 둔 뒤 이름 변경으로 운영에 올린다.

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

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

판단의 축은 단순합니다. 단말의 ID 기반(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」이라고 관리 주체를 정해 한쪽으로 모으는 것이 하이브리드 운영의 첫 원칙입니다.

flowchart TB
    accTitle: GPO와 Intune의 역할 분담
    accDescr: 단말의 ID 기반이 온프레미스 AD이고 사내에 상주하면 GPO, Entra 가입이나 사외 단말이면 Intune이 맞으며, 하이브리드에서는 같은 설정의 이중 구성을 피하고 설정 영역마다 관리 주체를 한쪽으로 모은다
    q{"단말의 기반과 소재는?"}
    q -->|AD 가입이고 사내 상주| gpo["GPO가 확실하고 세밀도도 높음"]
    q -->|Entra 가입이나 사외| intune["Intune이면 사외에도 닿음"]
    q -->|하이브리드| split["영역마다 한쪽으로 모음"]
    split -.-> warn["이중 구성은 결과가 보장되지 않음"]
    split -.-> ana["분류에는 Group Policy analytics"]

그림 17: 역할 분담은 단말의 ID 기반과 소재로 정하고, 하이브리드에서는 같은 설정을 GPO와 MDM 양쪽에서 구성하지 않는다.

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

flowchart TB
    accTitle: Group Policy analytics로 분류하기
    accDescr: GPMC에서 XML 형식으로 내보낸 GPO를 Group Policy analytics로 가져오면 설정마다 MDM에서 지원되는지 비권장이나 대응 불가인지를 나눌 수 있고, 대응이 끝난 설정은 설정 카탈로그 정책으로 옮길 수 있다
    exp["GPMC에서 XML로 내보내기"] --> imp["analytics로 가져오기"]
    imp --> ana["설정마다 대응 상황을 분석"]
    ana --> ok["MDM 대응 완료"]
    ana --> dep["비권장·대응 불가"]
    ok --> mig["설정 카탈로그 정책으로 이전"]

그림 18: Group Policy analytics는 내보낸 GPO를 가져와, MDM으로 옮길 수 있는 설정과 옮길 수 없는 설정을 나눈다.

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

마지막으로 수탁 개발 입장에서 짚어 둘 이야기입니다. 고객사 GPO는 여러분의 앱이 전제로 삼는 조건을 조용히 바꿔 버립니다. 「개발 PC에서는 되는데 고객사에서는 안 된다」의 한 원인으로, 방화벽이나 바이러스 백신과 나란히 GPO는 단골입니다. 실례를 바탕으로 듭니다.

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

flowchart TB
    accTitle: 고객사 GPO가 바꾸는 앱의 전제
    accDescr: 고객사 GPO는 실행 정책 강제, 방화벽의 로컬 규칙 병합 비활성화, 드라이브나 프록시 배포, 사용자가 설정을 되돌릴 수 없는 상태라는 형태로 앱의 전제 조건을 바꿔, 고객사에서만 동작하지 않는 현상의 한 원인이 된다
    gpo["고객사 GPO"] --> ep["실행 정책의 강제"]
    gpo --> fw["로컬 규칙 병합 사용 안 함"]
    gpo --> env["드라이브·프록시 배포"]
    gpo --> lock["설정을 되돌릴 수 없음"]
    ep --> sym["고객사에서만 안 되는 한 원인"]
    fw --> sym
    env --> sym
    lock --> sym

그림 19: 고객사 GPO는 실행 정책이나 방화벽, 환경 구성처럼 앱의 전제 조건을 조용히 바꿔 버린다.

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

flowchart TB
    accTitle: 개발 측의 세 가지 대비
    accDescr: 개발 측 대비는 앱이 의존하는 환경 전제를 도입 요건으로 문서화해 도입 전에 고객사 정보시스템에 확인을 요청하는 것, 문제 시 gpresult 보고서와 Policies 키의 실제 값을 확인하는 것, 관리자 권한이 필요한 처리를 설계 단계에서 나누어 두는 것의 세 가지이다
    dev["개발 측의 대비"] --> doc["1. 환경 전제를 문서화"]
    dev --> chk["2. gpresult와 실제 값으로 확인"]
    dev --> priv["3. 권한 필요 여부를 설계에서 분리"]
    doc -.-> ask["도입 전에 고객사 정보시스템에 확인 요청"]

그림 20: 개발 측 대비는 환경 전제의 문서화, gpresult와 실제 값으로의 확인, 관리자 권한 필요 여부의 설계 분리 세 가지이다.

9. 정리

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

관련 글

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

관련 상담 영역

합동회사 코무라소프트에서는 GPO 관리 하의 고객사 환경에서 업무 앱이 동작하지 않는 현상의 원인 조사, 도입 요건(실행 정책·방화벽·네트워크 전제)의 정리, AD 환경을 인수한 정보시스템 담당자를 위한 정책 실사나 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 중 어느 쪽으로 관리해야 하나요?

단말의 ID 기반에 맞추는 것이 기본입니다. 온프레미스 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 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.