- 공유 링크 만들기
- X
- 이메일
- 기타 앱
이 글의 목적은 Windows 업데이트 중 0x8024D009 오류와 함께 “서비스 등록 실패” 성격의 증상이 나타날 때, 개인 PC 환경과 기업 WSUS 환경을 모두 포함하여 원인을 분류하고 재현성 있게 복구하는 절차를 제공하는 것이다.
1. 오류 0x8024D009의 의미와 ‘서비스 등록 실패’가 같이 보이는 이유
0x8024D009는 Windows Update Agent 자체 업데이트(Self-update)가 Wuident.cab의 지시문에 의해 “건너뛰어진 상태”를 나타내는 코드로 분류된다. 이 상태에서는 Windows Update 구성요소가 기대하는 파일·가상 디렉터리·권한·서비스 구성이 맞지 않아, 업데이트 검사 단계에서 서비스 초기화 또는 등록 관련 작업이 연쇄적으로 실패하는 경우가 많다.
현장에서 “서비스 등록 실패”라는 표현은 다음과 같은 여러 케이스를 포괄해 표시되는 경우가 많다.
- Windows Update 문제 해결사에서 “Service registration is missing or corrupt”로 진단되는 상황이다.
- 업데이트 서비스(wuauserv)·BITS·암호화 서비스(cryptsvc)·MSI(msiserver)가 중지/비활성/손상되어 업데이트 구성요소 등록이 실패하는 상황이다.
- 기업 환경에서 WSUS SelfUpdate 가상 디렉터리(특히 80 포트)가 누락되거나 익명 액세스가 막혀 클라이언트가 WUA 자체 업데이트를 받지 못하는 상황이다.
주의 : 기업 환경(WSUS, 프록시, 보안 제품, 하드닝 정책)에서는 로컬에서 무조건 초기화 스크립트를 실행하면 정책 위반 또는 배포 실패가 재발할 수 있다. 먼저 “공용 Microsoft 업데이트 서버 사용 여부”와 “조직 업데이트 서버(WSUS) 사용 여부”를 구분한 뒤 절차를 적용해야 한다.
2. 먼저 환경을 분류하는 체크(개인 PC vs WSUS 관리 PC)
2.1 조직에서 관리 중인지 빠르게 판별하는 방법
다음 항목 중 하나라도 해당하면 WSUS 또는 조직 관리 정책을 의심해야 한다.
- 설정 > Windows 업데이트 화면에 “일부 설정은 조직에서 관리한다”는 문구가 표시되는 상황이다.
- 업데이트 서버 주소가 레지스트리에 지정된 상황이다.
- 사내망/VPN에서만 업데이트가 동작하는 상황이다.
:: 1) 레지스트리에서 WSUS 사용 여부 확인(관리자 CMD) reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v WUServer reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v WUStatusServer reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v UseWUServer :: 2) 그룹 정책 적용 여부 빠른 확인 gpresult /rUseWUServer 값이 1이고 WUServer/WUStatusServer가 존재하면 WSUS 경유 구성이 강하게 의심되는 상황이다.
2.2 증상별로 우선순위를 정하는 표
| 주요 증상 | 가능성이 큰 원인 | 우선 적용 절차 | 비고 |
|---|---|---|---|
| 0x8024D009 + 회사 PC + 업데이트 서버 지정 | WSUS SelfUpdate/권한/IIS 구성 문제 | 5장(WSUS 점검) 우선 적용 | 클라이언트 초기화만으로 해결되지 않는 경우가 많다. |
| 0x8024D009 + 개인 PC + 프록시/VPN 없음 | Windows Update 구성요소 캐시/서비스 손상 | 3장(클라이언트 복구) 우선 적용 | SoftwareDistribution, catroot2 재구성이 핵심이다. |
| 문제 해결사에서 서비스 등록 누락/손상 진단 | 서비스 비활성/권한/레지스트리 손상 | 4장(서비스·구성요소 등록) 적용 | DISM/SFC까지 연계하는 것이 안정적이다. |
| 업데이트 다운로드는 되나 설치가 반복 실패 | 구성 요소 저장소 손상 또는 MSI 경로 문제 | 3장 + 6장(DISM/SFC) 적용 | 누적 업데이트·SSU 불일치도 점검 대상이다. |
3. 표준 복구 1단계: 업데이트 구성요소(캐시·서비스) 초기화
가장 재현성이 높은 표준 절차는 업데이트 관련 서비스를 중지한 뒤, SoftwareDistribution 및 catroot2를 재생성하는 방식이다. 이 방식은 “서비스 등록 실패” 성격의 진단이 동반될 때도 효과가 높은 편이다.
3.1 관리자 권한 CMD로 실행하는 권장 순서
:: 0) 관리자 권한 CMD에서 실행해야 한다.
:: 1) 업데이트 관련 서비스 중지
net stop wuauserv
net stop bits
net stop cryptSvc
net stop msiserver
:: 2) 캐시 폴더 이름 변경(복구 시 자동 재생성)
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 catroot2.old
:: 3) 서비스 재시작
net start msiserver
net start cryptSvc
net start bits
net start wuauserv
:: 4) 재부팅 후 업데이트 재시도 권장
shutdown /r /t 0주의 : 기업 단말에서 업데이트 원본이 WSUS인 경우, 위 절차로 “클라이언트 측 캐시”는 초기화되지만 “WSUS SelfUpdate 문제”는 그대로 남을 수 있다. 0x8024D009가 지속되면 5장을 반드시 수행해야 한다.
3.2 폴더가 ‘사용 중’이라고 나오면 적용하는 보완 절차
서비스 중지가 제대로 되지 않거나 보안 제품이 점유하면 폴더 이름 변경이 실패할 수 있다. 다음 보완 명령을 적용한 뒤 다시 시도하는 방식이 실무적으로 유효하다.
:: 서비스 상태 확인 sc query wuauserv sc query bits sc query cryptsvc sc query msiserver :: 강제 종료가 필요한 경우(업무 영향 고려 후 사용) taskkill /f /im TiWorker.exe taskkill /f /im MoUsoCoreWorker.exe4. 표준 복구 2단계: 서비스 시작 유형·의존성·구성요소 등록 복구
“서비스 등록 실패”가 계속되면 서비스가 비활성화되어 있거나, 업데이트 구성 DLL 등록이 꼬였거나, 네트워크 구성(WinHTTP 프록시)이 비정상인 경우가 많다. 이 장은 해당 항목을 순서대로 정리한 것이다.
4.1 필수 서비스 4종의 권장 상태
| 서비스 | 서비스명 | 권장 시작 유형 | 권장 상태 | 설명 |
|---|---|---|---|---|
| Windows Update | wuauserv | 수동(트리거) 또는 수동 | 필요 시 실행 | 업데이트 검색·다운로드·설치 핵심 서비스이다. |
| Background Intelligent Transfer Service | bits | 자동(지연 시작) 또는 수동(트리거) | 필요 시 실행 | 다운로드 전송 계층이며 손상 시 다운로드/검사가 실패할 수 있다. |
| Cryptographic Services | cryptsvc | 자동 | 실행 중 권장 | 서명 검증, 카탈로그 처리에 필수이다. |
| Windows Installer | msiserver | 수동 | 필요 시 실행 | MSI 기반 업데이트 설치에서 사용될 수 있다. |
4.2 시작 유형 강제 복구(정책에 의해 비활성화된 경우 제외)
:: 관리자 CMD sc config wuauserv start= demand sc config bits start= delayed-auto sc config cryptsvc start= auto sc config msiserver start= demand
:: 즉시 기동
net start cryptsvc
net start bits
net start wuauserv주의 : 시작 유형이 계속 원복되면 로컬 변경이 아니라 그룹 정책 또는 보안 하드닝에 의해 제어되는 상황이다. 이 경우 정책 원인을 제거하지 않으면 재발한다.
4.3 Windows Update DLL 재등록(서비스 등록 실패 성격에 유효)
업데이트 구성요소 등록이 손상된 경우를 대비해, 업데이트 관련 DLL을 재등록하는 절차이다. 일부 환경에서는 전체가 필요하지 않을 수 있으나, “서비스 등록 실패”가 반복되는 경우에는 순서대로 적용하는 편이 안전하다.
:: 관리자 CMD cd /d %windir%\system32 regsvr32 /s atl.dll regsvr32 /s urlmon.dll regsvr32 /s mshtml.dll regsvr32 /s shdocvw.dll regsvr32 /s browseui.dll regsvr32 /s jscript.dll regsvr32 /s vbscript.dll regsvr32 /s scrrun.dll regsvr32 /s msxml.dll regsvr32 /s msxml3.dll regsvr32 /s msxml6.dll regsvr32 /s actxprxy.dll regsvr32 /s softpub.dll regsvr32 /s wintrust.dll regsvr32 /s dssenh.dll regsvr32 /s rsaenh.dll regsvr32 /s gpkcsp.dll regsvr32 /s sccbase.dll regsvr32 /s slbcsp.dll regsvr32 /s cryptdlg.dll regsvr32 /s oleaut32.dll regsvr32 /s ole32.dll regsvr32 /s shell32.dll regsvr32 /s initpki.dll regsvr32 /s wuapi.dll regsvr32 /s wuaueng.dll regsvr32 /s wuaueng1.dll regsvr32 /s wucltui.dll regsvr32 /s wups.dll regsvr32 /s wups2.dll regsvr32 /s wuweb.dll regsvr32 /s qmgr.dll regsvr32 /s qmgrprxy.dll regsvr32 /s wucltux.dll regsvr32 /s muweb.dll regsvr32 /s wuwebv.dll4.4 WinHTTP 프록시 초기화(사내 프록시·보안 게이트웨이 환경 포함)
업데이트 에이전트는 WinHTTP 설정에 영향을 받는 경우가 많다. 불필요한 프록시가 설정되어 있으면 업데이트 서버에 접근하지 못해 비정상 상태가 지속될 수 있다.
:: 관리자 CMD netsh winhttp show proxy netsh winhttp reset proxy :: 네트워크 스택 초기화(필요 시) ipconfig /flushdns netsh winsock reset netsh int ip reset5. 기업 환경 핵심: WSUS SelfUpdate 문제로 0x8024D009가 발생하는 경우의 조치
0x8024D009는 특히 WSUS 환경에서 “클라이언트 자체 업데이트가 전달되지 않는 상태”에서 자주 발생한다. 이 경우 클라이언트에서 캐시만 초기화해도 재발한다. 서버 측에서 SelfUpdate 구성(가상 디렉터리, 80 포트 바인딩, 익명 액세스, 디렉터리 권한)을 정상화해야 한다.
5.1 WSUS 서버에서 확인해야 하는 필수 조건
| 점검 항목 | 정상 기준 | 이상 시 영향 | 조치 방향 |
|---|---|---|---|
| SelfUpdate 가상 디렉터리 존재 | IIS에 SelfUpdate가 존재해야 한다. | 클라이언트 자체 업데이트가 실패할 수 있다. | Selfupdate.msi 재설치 또는 가상 디렉터리 재생성이다. |
| SelfUpdate가 80 포트 사이트에 연결 | 기본 웹 사이트(또는 80 포트 바인딩 사이트) 하위에 있어야 한다. | WSUS가 8530/8531을 사용해도 자체 업데이트는 80 포트를 요구하는 구성이 존재한다. | SelfUpdate/ClientWebService를 80 포트 사이트에 바인딩하는 방식이다. |
| 익명 액세스(Anonymous) 허용 | SelfUpdate 및 기본 웹 사이트에서 익명 액세스가 활성화되어야 한다. | 인증 단계에서 차단되어 SelfUpdate가 동작하지 않는다. | IIS 인증 설정에서 Anonymous를 활성화하는 방식이다. |
| SelfUpdate 폴더 권한 | Administrators/SYSTEM 전체, Users 읽기, IUSR 읽기 권한이 필요하다. | 파일 제공이 막혀 자체 업데이트가 실패할 수 있다. | NTFS 권한 복구 및 IUSR 계정 점검이다. |
| 기본 웹 사이트 IP 바인딩 | All Unassigned 또는 127.0.0.1 포함 구성이어야 한다. | 로컬 루프백 접근이 실패하여 SelfUpdate 트리가 동작하지 않을 수 있다. | IIS 바인딩에서 127.0.0.1 포함 또는 All Unassigned 적용이다. |
5.2 WSUS 서버 조치 절차(운영 표준 형태)
다음 절차는 WSUS 서버에서 SelfUpdate 전달이 실패할 때 적용하는 대표적인 조치 순서이다.
- IIS 관리자에서 80 포트로 바인딩된 사이트를 확인한다.
- 해당 사이트 하위에 SelfUpdate 가상 디렉터리가 존재하는지 확인한다.
- SelfUpdate 가상 디렉터리의 인증에서 Anonymous가 Enabled인지 확인한다.
- 기본 웹 사이트(또는 80 포트 사이트) 자체도 Anonymous가 Enabled인지 확인한다.
- SelfUpdate 실제 경로가 서버의 SelfUpdate 폴더를 정확히 가리키는지 확인한다.
- SelfUpdate 폴더의 NTFS 권한에서 Users 읽기 및 IUSR 읽기 권한이 보장되는지 확인한다.
- SelfUpdate가 누락되었거나 파일이 비정상이라면 Selfupdate.msi를 재실행하여 구성요소를 복구한다.
- 필요 시 IIS를 재시작하여 적용한다.
:: WSUS 서버(관리자 CMD)에서 IIS 재시작 예시 iisreset주의 : WSUS가 사용자 지정 사이트(예: 8530)로 운영되는 구성에서도 SelfUpdate는 80 포트 사이트에서 동작해야 하는 형태가 존재한다. 포트 변경만으로 해결하려고 하면 클라이언트가 계속 0x8024D009를 반환할 수 있다.
5.3 클라이언트 측에서 WSUS 자체 업데이트 상태를 재동기화하는 명령
서버 측 구성을 정상화한 뒤 클라이언트가 즉시 재탐지하도록 유도하는 절차이다.
:: 클라이언트(관리자 CMD) wuauclt /detectnow wuauclt /reportnow :: Windows 10/11에서 탐지 트리거로 자주 쓰는 방식(관리자 PowerShell) usoclient StartScan usoclient StartDownload usoclient StartInstall6. 구성 요소 저장소 복구: DISM/SFC로 서비스 등록 실패 재발을 줄이는 방법
업데이트 관련 파일 자체가 손상되면 캐시 초기화로 일시 복구되더라도 누적 업데이트에서 다시 실패하는 패턴이 나타날 수 있다. 이 경우 구성 요소 저장소 복구를 병행하는 것이 실무적으로 안전하다.
:: 관리자 CMD Dism.exe /Online /Cleanup-Image /RestoreHealth Sfc.exe /Scannow :: 완료 후 재부팅 권장 shutdown /r /t 07. 재발 방지 체크리스트(현장 점검용)
7.1 업데이트 실패가 반복되는 단말에서 자주 놓치는 항목
- 시스템 드라이브(C:) 여유 공간 부족 상태이다.
- 시간 동기화가 크게 틀어진 상태이다.
- VPN/프록시가 상시 적용되어 업데이트 서버 접근이 간헐적으로 차단되는 상태이다.
- 서드파티 보안 제품이 SoftwareDistribution 또는 catroot2 접근을 차단하는 상태이다.
- 서비스 시작 유형이 정책에 의해 Disabled로 강제되는 상태이다.
7.2 최소 점검 명령 세트
:: 디스크 여유 확인 fsutil volume diskfree c:
:: 시간 동기화 상태 확인
w32tm /query /status
:: 필수 서비스 상태 확인
sc query wuauserv
sc query bits
sc query cryptsvc
sc query msiserver8. 로그 확인으로 원인 확정(필요 시)
조치 후에도 0x8024D009가 지속되면 “클라이언트 문제인지, WSUS 서버 문제인지”를 로그로 분리해야 한다. Windows 10/11에서는 WindowsUpdate.log가 즉시 텍스트로 누적되지 않을 수 있어 변환이 필요할 수 있다.
:: 관리자 PowerShell(Windows 10/11) Get-WindowsUpdateLog :: 생성된 WindowsUpdate.log를 열어 SelfUpdate, wuident.cab, WSUS URL 접근 실패 등을 확인한다.FAQ
0x8024D009인데 개인 PC에서도 WSUS 점검이 필요한가?
개인 PC라면 WSUS 점검보다는 3장과 4장의 구성요소 초기화 및 서비스 등록 복구가 우선이다. 다만 과거에 회사 계정으로 관리되던 기기이거나, 레지스트리에 WUServer/UseWUServer 흔적이 남아 있다면 정책 잔재 제거가 필요할 수 있다.
캐시 폴더 이름 변경 후 업데이트 기록이 사라지는가?
SoftwareDistribution을 재생성하면 “업데이트 기록 표시”가 일부 비어 보일 수 있다. 이는 표시용 로컬 데이터가 초기화되는 영향이며, 실제 설치된 업데이트 자체가 제거되는 동작은 아니다.
서비스 시작 유형을 바꿨는데 다시 Disabled로 돌아가는 이유는 무엇인가?
로컬 설정이 아니라 그룹 정책, 보안 기준, 하드닝 스크립트 등에 의해 주기적으로 강제되는 상황일 수 있다. 이 경우 정책 원인을 제거하거나 예외를 부여해야 재발이 줄어든다.
WSUS가 8530 포트인데도 80 포트를 봐야 하는 이유는 무엇인가?
WSUS 관리 사이트를 사용자 지정 포트로 운영하더라도, 자체 업데이트(SelfUpdate) 트리가 80 포트 바인딩 사이트에 있어야 정상 동작하는 구성 시나리오가 존재한다. SelfUpdate와 ClientWebService의 80 포트 바인딩, 익명 액세스, 권한 구성이 핵심이다.
가장 빠르게 효과를 보는 순서는 무엇인가?
개인 PC는 3장의 서비스 중지 및 SoftwareDistribution/catroot2 재구성이 우선이다. 기업 WSUS 환경은 5장의 SelfUpdate(80 포트, 익명 액세스, 권한, 가상 디렉터리) 점검이 우선이다. 이후에도 재발하면 6장의 DISM/SFC를 병행하는 것이 안정적이다.