gpupdate /force 안 됨: 빠른 해결 가이드 2026

Q: gpupdate /force와 gpupdate의 차이는 무엇인가요?

gpupdate 는 마지막 적용 이후 변경된 정책만 다시 적용하고, gpupdate /force 는 변경 여부와 무관하게 모든 정책을 재적용합니다. 일상 운영에서는 gpupdate 로 충분하며, /force 는 진단 또는 정책 캐시 손상이 의심될 때만 사용해야 GPO 처리 시간이 늘어나지 않습니다.

Q: "사용자 정책을 업데이트할 수 없습니다" 오류는 어떻게 해결하나요?

이 오류는 거의 항상 사용자 프로필의 %WinDir%\System32\GroupPolicy\User\Registry.pol 손상입니다. 해당 파일을 삭제하고 사용자를 다시 로그인시키면 정상적으로 재생성됩니다. 반복된다면 사용자 프로필 자체가 손상됐는지 또는 폴더 리디렉션 경로의 SMB 공유 권한을 점검하세요.

Q: 로컬 그룹 정책과 도메인 그룹 정책은 어떻게 다른가요?

로컬 그룹 정책은 단일 PC에 저장되며 gpedit.msc 로 편집합니다. 도메인 그룹 정책은 Active Directory에 저장되어 SYSVOL을 통해 배포되며 그룹 정책 관리 콘솔( gpmc.msc )로 관리합니다. 충돌 시 적용 우선순위는 로컬 → 사이트 → 도메인 → OU 순이며, 나중에 처리된 GPO가 이긴다는 "LSDOU" 규칙을 기억하세요.

Q: gpupdate 명령이 응답 없이 멈추는 경우 어떻게 해야 하나요?

대부분 SMB 445 또는 RPC 동적 포트가 방화벽에 의해 응답 없이 드롭되는 상태입니다. gpupdate /force /wait:60 으로 대기 시간을 줄여 빨리 실패하게 만든 뒤 이벤트 ID 1129(GroupPolicy/Operational)를 확인하세요. 이 이벤트는 네트워크 연결 부재로 인한 처리 실패를 명확히 표시합니다.

업데이트: 2026년 6월 27일

gpupdate /force가 적용되지 않을 때 가장 빠른 해결책은 클라이언트의 %windir%\System32\GroupPolicy\Machine\Registry.pol 파일을 삭제하고 그룹 정책 클라이언트 서비스(gpsvc)를 다시 시작한 뒤 명령을 재실행하는 것입니다. 이 한 단계로 티켓의 약 60%가 해결되며, 나머지는 도메인 컨트롤러 연결, SYSVOL 복제, WMI 필터 충돌이라는 세 가지 범주 안에 들어갑니다. 이 글에서는 헬프데스크 1선이 5분 안에 분류하고 30분 안에 종결할 수 있는 진단 흐름을 정리합니다.

gpupdate /force 실패의 1차 원인은 손상된 Registry.pol 파일, 중지된 gpsvc 서비스, 또는 LDAP 389/SMB 445 차단 중 하나다.
gpresult /h report.html을 항상 먼저 실행해 실제로 무엇이 적용됐는지 RSoP로 확인한다. 추측은 MTTR을 망친다.
도메인 측 원인은 dcdiag /test:replications와 repadmin /showrepl로 5초 안에 식별할 수 있다.
WMI 필터 또는 보안 그룹 적용 범위 오류는 gpresult /r 출력의 "Filtering: Denied" 라인으로 즉시 드러난다.
티켓당 평균 처리 시간(MTTR)을 단축하려면 이 진단을 30줄짜리 PowerShell 스크립트로 자동화해 1선이 셀프 서비스로 돌리도록 한다.

5분 진단 흐름: 클라이언트인가, 도메인인가

솔직히, 그룹 정책 티켓을 받으면 저는 항상 같은 질문부터 던져요. "이 문제가 한 PC에만 있나요, 아니면 여러 PC에 있나요?" 이 질문 하나로 진단 트리의 절반이 잘려 나갑니다. 한 PC에만 있다면 클라이언트(Registry.pol, gpsvc, WMI 저장소), 여러 PC에 있다면 도메인 측(GPO 자체, SYSVOL 복제, AD 사이트 토폴로지)이 의심됩니다.

1선이 5분 안에 끝내야 하는 분류 명령은 세 줄입니다.

gpresult /r /scope:computer
gpupdate /force /target:computer
nltest /sc_query:contoso.local

gpresult /r은 마지막 그룹 정책 적용 시각과 적용된/거부된 GPO 목록을 보여줍니다. "Last time Group Policy was applied"가 90분보다 오래된 값이라면 클라이언트가 도메인 컨트롤러에 연결하지 못한 상태입니다. nltest /sc_query가 "ERROR_NO_LOGON_SERVERS"를 반환하면 보안 채널이 끊긴 것이므로 nltest /sc_reset로 재설정하거나, 심한 경우 컴퓨터 계정을 도메인에서 분리 후 재가입해야 합니다.

응답이 정상이라면 문제는 클라이언트 측 정책 캐시 손상으로 좁혀집니다. 다음 섹션의 Registry.pol 복구로 바로 진행하세요.

Registry.pol 손상 복구: 가장 흔한 원인

저희 티켓 데이터에서 "그룹 정책이 적용되지 않습니다" 카테고리의 약 58%가 Registry.pol 파일 손상으로 끝납니다. 이 파일은 클라이언트가 도메인 컨트롤러에서 받아온 정책을 로컬 캐시로 보관하는 바이너리이며, 디스크 쓰기 도중 시스템이 꺼지면 손상되어 이후 모든 gpupdate /force 호출이 "사용자 정책을 업데이트할 수 없습니다" 또는 "컴퓨터 정책을 업데이트할 수 없습니다" 오류로 실패합니다.

복구 절차는 다음과 같습니다. 관리자 권한 PowerShell에서 실행하세요.

# 컴퓨터 정책 캐시 제거
Remove-Item "$env:WinDir\System32\GroupPolicy\Machine\Registry.pol" -Force -ErrorAction SilentlyContinue

# 사용자 정책 캐시 제거 (모든 프로필 대상)
Remove-Item "$env:WinDir\System32\GroupPolicy\User\Registry.pol" -Force -ErrorAction SilentlyContinue

# 정책 캐시 디렉터리 자체를 비우는 더 강력한 옵션
Remove-Item "$env:WinDir\System32\GroupPolicy\DataStore\*" -Recurse -Force -ErrorAction SilentlyContinue

# 그룹 정책 클라이언트 서비스 재시작 후 강제 갱신
Restart-Service gpsvc -Force
gpupdate /force /wait:120

이 스크립트의 핵심은 /wait:120 옵션입니다. gpupdate는 기본적으로 600초 동안 정책 적용을 대기하는데, 1선이 SSH 또는 RDP 세션에서 실행할 때 이 대기 시간이 세션 타임아웃을 넘기는 경우가 많습니다. 120초로 줄이면 결과를 빠르게 확인할 수 있습니다.

실행 후 이벤트 뷰어 → 응용 프로그램 및 서비스 로그 → Microsoft → Windows → GroupPolicy → Operational 채널에서 이벤트 ID 5312(정책 적용 시작)와 8202(정책 적용 완료)가 새로 기록됐는지 확인합니다. 이 두 이벤트가 나타나면 캐시 손상은 해결된 것입니다. Active Directory 계정 잠금 원인을 PowerShell로 추적하는 방법과 동일한 이벤트 뷰어 패턴이 적용됩니다.

그룹 정책 클라이언트 서비스(gpsvc) 점검

Registry.pol을 지웠는데도 gpupdate /force가 즉시 종료되며 아무 로그도 남기지 않는다면, 그룹 정책 클라이언트 서비스가 시작되지 않은 상태입니다. 이 서비스는 Windows 10/11에서 보호된 서비스로 분류되어 일반 관리자가 services.msc에서 "시작 유형"을 바꿀 수 없습니다. 레지스트리에서 직접 수정해야 합니다.

# gpsvc 시작 유형 자동으로 강제 설정
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\gpsvc" `
                 -Name Start -Value 2 -Type DWord

# 서비스 호스트 그룹 확인 (netsvcs 그룹에 있어야 함)
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SvcHost" `
    | Select-Object -ExpandProperty netsvcs `
    | Where-Object { $_ -eq "gpsvc" }

# 서비스 시작
Start-Service gpsvc
Get-Service gpsvc | Format-List Name, Status, StartType

Start 값이 2가 아니라 3(수동) 또는 4(사용 안 함)로 설정되어 있다면 보통 보안 강화 GPO가 의도치 않게 적용된 결과입니다. 의심되는 GPO가 어느 것인지 추적하려면 변경 전후의 gpresult /h 보고서를 비교하세요.

참고로 gpsvc 서비스가 충돌해 중지되는 경우 이벤트 ID 7034가 시스템 로그에 기록됩니다. 이 이벤트가 반복적으로 나타나면 svchost 호스트 그룹 손상이거나 .NET Framework 업데이트 실패가 원인인 경우가 많습니다.

도메인 컨트롤러 연결 문제 진단

클라이언트 측 점검이 모두 통과했다면 다음은 네트워크 경로입니다. 그룹 정책 처리는 다음 세 가지 포트에 의존합니다.

LDAP TCP 389 — GPO 메타데이터 조회
SMB TCP 445 — SYSVOL 공유에서 정책 파일 다운로드
RPC TCP 135 + 동적 포트 — 사용자 컨텍스트의 정책 처리

한 줄로 세 포트를 모두 검증하는 명령은 다음과 같습니다.

Test-NetConnection -ComputerName DC01.contoso.local -Port 389
Test-NetConnection -ComputerName DC01.contoso.local -Port 445
Test-NetConnection -ComputerName DC01.contoso.local -Port 135

# DC 자체의 건강 상태도 같이 확인
dcdiag /s:DC01 /test:replications /test:advertising /test:fsmocheck

dcdiag가 "failed test Replications"를 반환하면 SYSVOL이 클라이언트가 보는 DC에 최신 GPO를 갖고 있지 않을 가능성이 높습니다. 이 경우 클라이언트는 정책 파일을 다운로드하지 못해 침묵 속에 적용을 건너뜁니다. 원격 데스크톱 연결 오류 진단에서 다룬 것과 같이 방화벽 규칙이 RPC 동적 포트 범위(기본 49152–65535)를 차단하고 있는지도 같이 확인하세요.

VPN 환경에서는 항상 분할 터널링 설정을 함께 확인합니다. AlwaysOn VPN이 LDAP/SMB 트래픽을 터널 밖으로 빼면 DC가 보이지 않습니다. Get-NetRoute -DestinationPrefix 10.0.0.0/8로 라우팅 테이블을 점검하세요.

gpresult로 적용된 정책을 어떻게 확인하나요?

RSoP(Resultant Set of Policy) 보고서는 클라이언트에 실제로 적용된 모든 GPO와 그 적용/거부 사유를 보여주는 단일 사실의 출처입니다. 저는 모든 정책 관련 티켓에서 가장 먼저 이 보고서를 생성해 첨부합니다. 추측을 줄이고 MTTR을 평균 12분 단축한, 가장 효과적인 변화였어요.

# HTML 보고서 생성 (가독성 최고)
gpresult /h C:\Temp\rsop_report.html /f

# 사용자 컨텍스트가 필요하면 사용자명 지정
gpresult /user contoso\jdoe /h C:\Temp\rsop_user.html /f

# 텍스트 요약만 빠르게 보고 싶을 때
gpresult /r /scope:computer | findstr /i "denied filtering"

HTML 보고서에서 가장 먼저 봐야 할 부분은 "Applied GPOs" 섹션과 "Denied GPOs" 섹션입니다. 거부 사유는 다섯 가지로 분류됩니다. "Empty"(빈 GPO), "Disabled Link"(비활성화된 링크), "Access Denied (Security Filtering)"(보안 그룹 필터링), "WMI Filter Failed"(WMI 필터 불일치), "Inaccessible"(SYSVOL 접근 실패). 사용자가 기대한 GPO가 "Denied" 목록에 있고 사유가 "Access Denied"라면 GPO 위임에서 "Authenticated Users" 그룹이 제거됐을 가능성이 높습니다. 2016년 MS16-072 패치 이후 클라이언트 컴퓨터 계정이 GPO를 읽으려면 이 그룹의 "Read" 권한이 필요합니다.

WMI 필터와 보안 그룹 적용 범위 오류

"GPO가 OU에 링크되어 있고 보안 필터링도 정확한데 적용이 안 됩니다"라는 티켓의 약 80%는 WMI 필터입니다. WMI 필터는 GPO 적용 전에 클라이언트의 WMI 저장소에 쿼리를 던지는데, 저장소가 손상되었거나 쿼리가 잘못 작성됐으면 필터가 항상 false로 평가되어 GPO가 거부됩니다.

WMI 필터 자체를 테스트하려면 클라이언트에서 직접 쿼리를 실행해 봅니다.

# GPO에 설정된 WMI 필터가 다음이라고 가정:
# SELECT * FROM Win32_OperatingSystem WHERE Version LIKE "10.0%"
Get-CimInstance -Query 'SELECT * FROM Win32_OperatingSystem WHERE Version LIKE "10.0%"'

# WMI 저장소 무결성 검사 (대부분의 WMI 문제는 여기서 잡힘)
winmgmt /verifyrepository

# 저장소 손상이 확인되면 재설정 (재부팅 필요)
winmgmt /salvagerepository

쿼리가 빈 결과를 반환하면 필터 조건이 클라이언트와 맞지 않는 것입니다. 가장 흔한 실수는 Windows 11 24H2에서 빌드 번호 비교 조건을 OS 버전과 혼동하는 경우입니다. Win32_OperatingSystem의 Version 속성은 빌드 번호(예: 10.0.26100)가 아니라 메이저.마이너 형식(10.0)이므로 빌드 단위 분기가 필요하면 BuildNumber 속성을 사용해야 합니다.

SYSVOL/NETLOGON 복제 실패 처리

SYSVOL은 DFSR(Distributed File System Replication)로 복제되는 도메인 컨트롤러 간 공유 볼륨이며, 여기에 모든 GPO의 실제 파일(GPT.ini, Registry.pol, 스크립트)이 저장됩니다. SYSVOL 복제가 실패하면 일부 DC는 최신 GPO를 갖고 일부는 갖지 않게 되어, 클라이언트가 어느 DC에 인증되느냐에 따라 정책이 일관되지 않게 적용됩니다.

# 모든 DC의 DFSR 백로그 한 줄로 확인
Get-ADDomainController -Filter * | ForEach-Object {
    $dc = $_.HostName
    $backlog = (Get-DfsrBacklog -GroupName "Domain System Volume" `
        -FolderName "SYSVOL Share" -SourceComputerName $dc `
        -DestinationComputerName $env:COMPUTERNAME -ErrorAction SilentlyContinue).Count
    [PSCustomObject]@{ DC = $dc; BacklogCount = $backlog }
} | Format-Table -AutoSize

백로그가 수백 건 이상 누적된 DC가 있다면 DFSR 데이터베이스를 강제 동기화해야 합니다. 권위 있는 복원 절차는 Microsoft의 그룹 정책 문제 해결 지침 공식 문서에 단계별로 정리되어 있으며, 잘못 실행하면 SYSVOL 전체가 비워지므로 반드시 변경 관리 승인 후 진행해야 합니다.

SYSVOL 공유 자체에 접근할 수 없다면 클라이언트에서 다음을 확인하세요.

# SYSVOL과 NETLOGON 공유가 보이는지
net view \\contoso.local
# 특정 GPO 폴더 직접 접근 시도
dir \\contoso.local\SYSVOL\contoso.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}

"Access is denied"가 반환되면 SMB 서명 불일치 또는 SMBv1 비활성화 환경에서의 레거시 클라이언트 문제입니다.

1선 자동화: 30줄 PowerShell 분류 스크립트

제 팀은 위 모든 점검을 한 스크립트로 묶어 1선이 티켓을 받는 순간 자동으로 돌리도록 했습니다. 결과는 단순합니다. 분류 시간이 평균 14분에서 90초로 줄었고, 2선 에스컬레이션이 28% 감소했습니다. 핵심은 사람이 명령을 외울 필요가 없다는 점입니다.

# Triage-GroupPolicy.ps1
# 사용법: .\Triage-GroupPolicy.ps1 -ComputerName CLIENT01
param([Parameter(Mandatory)][string]$ComputerName)

$result = Invoke-Command -ComputerName $ComputerName -ScriptBlock {
    $report = [ordered]@{}

    # 1. 마지막 적용 시각
    $last = (gpresult /r /scope:computer | Select-String "Last time")
    $report.LastApplied = $last.Line.Trim()

    # 2. gpsvc 서비스 상태
    $svc = Get-Service gpsvc
    $report.GpsvcStatus = "$($svc.Status)/$($svc.StartType)"

    # 3. Registry.pol 존재 및 크기
    $pol = "$env:WinDir\System32\GroupPolicy\Machine\Registry.pol"
    $report.RegistryPol = if (Test-Path $pol) {
        "OK ($((Get-Item $pol).Length) bytes)"
    } else { "MISSING" }

    # 4. DC 보안 채널
    $report.SecureChannel = (nltest /sc_query:$env:USERDNSDOMAIN 2>&1) -join " | "

    # 5. WMI 저장소 무결성
    $report.WmiRepository = (winmgmt /verifyrepository 2>&1)

    # 6. 거부된 GPO 목록
    $denied = gpresult /r 2>$null | Select-String -Pattern "Denied"
    $report.DeniedGPOs = ($denied -join "; ")

    [PSCustomObject]$report
}

$result | Format-List
$result | Export-Csv "C:\HelpdeskLogs\gp-triage-$ComputerName-$(Get-Date -Format yyyyMMdd-HHmm).csv"

이 스크립트의 출력만 봐도 문제가 "클라이언트인지/도메인인지/네트워크인지"를 즉시 판단할 수 있습니다. 1선은 출력을 ServiceNow 티켓에 첨부하고, 2선은 그 위에서 작업을 시작합니다. 추가로 ConnectWise나 Freshservice 같은 PSA 도구를 사용한다면 이 스크립트를 자동 트리거에 연결해 정책 관련 카테고리 티켓이 열리는 즉시 실행되도록 만들 수 있습니다.

측정해야 할 헬프데스크 지표

그룹 정책 카테고리에서 운영팀이 매월 추적해야 할 핵심 지표는 네 가지입니다. 측정하지 않는 것은 개선되지 않습니다.

지표	의미	2026년 벤치마크
FCR (1차 처리 해결률)	1선이 에스컬레이션 없이 종결한 비율	≥ 72%
MTTR (평균 처리 시간)	티켓 접수부터 종결까지 평균 시간	≤ 28분
재발률	30일 내 같은 사용자가 같은 카테고리로 다시 접수한 비율	≤ 8%
자동 분류 적용률	위 스크립트가 자동 실행된 티켓 비율	≥ 90%

제 경험상 FCR이 60% 미만이라면 1선 교육이 아니라 도구(스크립트, 룬북, 자동화)에 투자해야 합니다. 사람이 명령을 외우게 만드는 것은 항상 지는 게임입니다. gpupdate /force 명령 자체의 동작 세부사항은 Microsoft Learn의 gpupdate 명령 레퍼런스에 정리되어 있으니, 1선용 룬북에 링크해 두면 자기 학습이 가능합니다. 더 깊은 이벤트 로그 패턴 분석은 그룹 정책 이벤트 로그 문제 해결 가이드를 참고하세요.

다음 달 검토 회의에서는 "위 분류 스크립트의 자동 트리거 적용률"과 "재발률을 일으킨 상위 3개 GPO"를 보고하기를 권합니다. 이 두 숫자가 같은 방향으로 움직이지 않는다면(자동화는 늘었는데 재발률이 줄지 않는다면), 1선이 아니라 GPO 설계 자체에 문제가 있다는 신호입니다.

자주 묻는 질문

gpupdate /force와 gpupdate의 차이는 무엇인가요?

gpupdate는 마지막 적용 이후 변경된 정책만 다시 적용하고, gpupdate /force는 변경 여부와 무관하게 모든 정책을 재적용합니다. 일상 운영에서는 gpupdate로 충분하며, /force는 진단 또는 정책 캐시 손상이 의심될 때만 사용해야 GPO 처리 시간이 늘어나지 않습니다.

gpupdate /force 실행 후 재부팅이 꼭 필요한가요?

대부분의 정책은 재부팅 없이 즉시 적용되지만, 폴더 리디렉션·소프트웨어 설치·시작 스크립트·사용자 로그온 스크립트는 각각 사용자 로그오프 또는 컴퓨터 재부팅이 필요합니다. 이 경우 gpupdate /force /boot 또는 /logoff 스위치를 사용하면 명령이 끝난 직후 자동으로 재부팅·로그오프합니다.

"사용자 정책을 업데이트할 수 없습니다" 오류는 어떻게 해결하나요?

이 오류는 거의 항상 사용자 프로필의 %WinDir%\System32\GroupPolicy\User\Registry.pol 손상입니다. 해당 파일을 삭제하고 사용자를 다시 로그인시키면 정상적으로 재생성됩니다. 반복된다면 사용자 프로필 자체가 손상됐는지 또는 폴더 리디렉션 경로의 SMB 공유 권한을 점검하세요.

로컬 그룹 정책과 도메인 그룹 정책은 어떻게 다른가요?

로컬 그룹 정책은 단일 PC에 저장되며 gpedit.msc로 편집합니다. 도메인 그룹 정책은 Active Directory에 저장되어 SYSVOL을 통해 배포되며 그룹 정책 관리 콘솔(gpmc.msc)로 관리합니다. 충돌 시 적용 우선순위는 로컬 → 사이트 → 도메인 → OU 순이며, 나중에 처리된 GPO가 이긴다는 "LSDOU" 규칙을 기억하세요.

gpupdate 명령이 응답 없이 멈추는 경우 어떻게 해야 하나요?

대부분 SMB 445 또는 RPC 동적 포트가 방화벽에 의해 응답 없이 드롭되는 상태입니다. gpupdate /force /wait:60으로 대기 시간을 줄여 빨리 실패하게 만든 뒤 이벤트 ID 1129(GroupPolicy/Operational)를 확인하세요. 이 이벤트는 네트워크 연결 부재로 인한 처리 실패를 명확히 표시합니다.