윈도우 업데이트가 실패하면 검색 결과의 상위 글들은 거의 예외 없이 같은 순서를 권한다. 문제 해결사를 돌리고, 안 되면 DISM과 SFC를 돌리고, 그래도 안 되면 SoftwareDistribution 폴더를 지우라는 것이다. 이 순서가 틀린 것은 아니다. 다만 이 순서는 “무엇이 고장났는지 모를 때의 순서”지, “내 화면에 뜬 코드에 맞는 순서”는 아니다.
업데이트 실패 화면에는 거의 항상 0x로 시작하는 열여섯 자리 코드가 함께 뜬다. 이 코드는 장식이 아니라 서비싱 스택이 어느 단계에서 멈췄는지를 가리키는 식별자다. 마이크로소프트는 이 코드들을 원인과 조치까지 묶어 공개 문서로 정리해두었는데, 정작 한국어 가이드에서는 코드를 “그냥 업데이트 오류”로 뭉뚱그리는 경우가 많다.
공식 오류 코드 목록을 직접 세어 원인별로 나눠봤다
마이크로소프트 러닝의 공통 Windows Update 오류(Common Windows Update errors) 문서를 열어 표를 하나씩 읽으며 분류해봤다. 이 문서에는 서른여섯 개의 고유 오류 코드가 각각 메시지, 설명, 조치(Mitigation) 세 칸으로 정리돼 있다. 문서가 제시한 조치 문구를 기준으로 코드를 묶으면 다음과 같이 갈린다.
| 원인 계열 | 고유 코드 수 | 문서가 지시하는 조치 | 대표 코드 |
|---|---|---|---|
| 네트워크·프록시·업데이트 원본 | 10 | 방화벽·프록시·TLS·엔드포인트 점검 | 0x80072EE2, 0x8024401B, 0x80072F8F |
| 구성 요소 저장소 손상 | 6 | DISM RestoreHealth 후 SFC | 0x800f0831, 0x80070570, 0x80073701 |
| 서비스 상태·그룹 정책 | 6 | 서비스 시작 유형·정책 원복 | 0x80070422, 0x80070BC9, 0x80246017 |
| 권한·파일 잠금(백신 포함) | 4 | 권한 부여 또는 필터 드라이버 제거 | 0x80070005, 0x80070020, 0x80240022 |
| 다운로드 캐시·메타데이터 | 4 | SoftwareDistribution·catroot2 이름 변경 | 0x80242006, 0x8007000D |
| 레지스트리·재부팅 대기 | 4 | 보류 트랜잭션 정리, 레지스트리 값 보정 | 0x80070490, 0x800706be |
| 서비싱 스택 타임아웃 | 2 | 장치 자원 증설, 대기 시간 연장 | 0x800f0821, 0x800F0920 |
이 분류에서 곧바로 드러나는 사실이 하나 있다. 서른여섯 개 코드 가운데 마이크로소프트가 DISM RestoreHealth와 SFC를 실제 처방으로 적어둔 코드는 여섯 개뿐이고, 반대로 네트워크와 프록시 설정을 보라고 적힌 코드는 열 개로 가장 많다. 대부분의 가이드가 1번으로 권하는 DISM·SFC는 공식 문서 기준으로는 전체의 6분의 1에 해당하는 소수 계열의 처방이라는 뜻이다. 코드를 읽지 않고 DISM부터 돌리면, 열에 여섯 번쯤은 십수 분을 쓰고도 같은 화면을 다시 보게 된다.
가장 흔한 계열은 네트워크였다
네트워크 계열이 많다는 점은 직관과 어긋난다. 인터넷이 되니까 업데이트도 될 것 같지만, 업데이트 클라이언트가 쓰는 경로는 브라우저와 다르다. 같은 문서의 Windows Update 문제 해결 문서는 이 차이를 분명히 적어두었다. 윈도우 업데이트는 WinHttp로 부분 범위 요청(HTTP RANGE)을 보내 업데이트를 내려받으므로, 네트워크의 프록시 서버가 HTTP RANGE 요청을 지원해야 한다. 그리고 인터넷 옵션에서 사용자 수준 프록시만 설정하고 시스템 수준인 WinHTTP에 설정하지 않으면 연결이 실패한다.
이 경우 관리자 권한 명령 프롬프트에서 netsh winhttp set proxy 형식으로 프록시를 지정하거나, netsh winhttp import proxy source=ie 명령으로 인터넷 옵션 설정을 그대로 가져올 수 있다. 사내망이나 공유기 단에서 콘텐츠 필터를 쓰는 환경이라면 이 한 줄로 끝나는 문제를, 시스템 파일 복구로 오해해 반나절을 쓰는 일이 흔하다.
같은 계열의 다른 얼굴이 TLS다. 0x80072F8F는 콘텐츠 디코딩 실패를 뜻하는데, 문서는 이 코드의 원인을 클라이언트에 TLS 1.2가 올바르게 구성되지 않은 것으로 지목하고 KB3140245 업데이트 설치를 조치로 제시한다. 오래 꺼두었다가 다시 켠 구형 PC에서 업데이트가 처음부터 막히는 전형적인 패턴이 여기에 해당한다.
DISM이 정답인 경우는 따로 있다
그렇다고 DISM이 무용하다는 말은 아니다. 문서가 DISM RestoreHealth와 SFC를 조치로 명시한 여섯 개 코드는 성격이 뚜렷하다. 0x800f0831은 CBS 저장소가 손상된 상태, 0x80070570은 파일이나 디렉터리가 손상돼 읽을 수 없는 상태, 0x80073701은 참조된 어셈블리를 찾을 수 없는 상태를 가리킨다. 공통점은 구성 요소가 부분 설치 상태로 남아 저장소가 깨졌다는 것이다. 이럴 때만 구성 요소 저장소를 복구하는 조치가 원인에 맞는다.
여기서 순서도 중요하다. 서비싱 스택 업데이트 문서는 서비싱 스택이 곧 윈도우 업데이트를 설치하는 구성 요소이며, 그 안의 CBS가 DISM과 SFC, 기능 변경, 구성 요소 복구의 공통 기반이라고 설명한다. 복구 도구 자체가 서비싱 스택 위에서 도는 셈이라, 스택이 낡았으면 복구 명령도 같이 흔들린다. 2021년 2월부터는 최신 서비싱 스택 업데이트가 월간 누적 업데이트에 함께 묶여 배포되므로, 별도로 챙길 일은 줄었지만 누적 업데이트 자체가 막힌 상황에서는 이 전제가 깨진다는 점을 기억해둘 만하다.
같은 코드라도 공식 설명과 유통되는 설명이 다르다
분류 작업에서 가장 흥미로웠던 대목은 0x800f0922였다. 커뮤니티와 블로그에서 이 코드는 대체로 “EFI 시스템 파티션 공간 부족”으로 설명된다. 그런데 마이크로소프트 문서의 해당 항목은 메시지를 CBS_E_INSTALLERS_FAILED로 적고, 라이선스와 제품 키 토큰 갱신 실패로 업데이트가 롤백되는 경우를 들며 System32의 spp 폴더에 User와 Network Service 계정의 쓰기 권한을 추가하라고 안내한다. 같은 코드가 여러 실패 지점을 공유하기 때문에 벌어지는 일이다.
부팅 파티션 공간이 실제로 문제가 되는 상황도 물론 있다. 다만 기준을 감으로 잡을 필요는 없다. UEFI/GPT 하드 드라이브 파티션 문서는 EFI 시스템 파티션의 최소 크기를 512바이트 섹터 드라이브에서 200MB, 4K 네이티브 섹터 드라이브에서 300MB로 규정하고, 이 파티션은 FAT32로 포맷되며 운영 체제가 관리하므로 다른 파일을 두어서는 안 된다고 못박는다. 윈도우 파티션에 대해서는 64비트 기준 최소 20GB, 초기 설정과 자동 유지 관리가 끝난 뒤 16GB의 여유 공간을 요구한다. 내 PC의 수치를 이 기준과 대보면, 공간이 진짜 원인인지 아닌지가 추측이 아니라 비교로 정리된다.
백신과 그룹 정책이라는 사각지대
권한·파일 잠금 계열 네 개는 사용자가 스스로 의심하기 가장 어려운 원인이다. 0x80070020은 공유 위반인데, 문서는 이 오류가 백신 같은 마이크로소프트 외부 필터 드라이버 때문에 발생한다고 적고 클린 부팅 후 재시도를 첫 조치로 제시한다. 0x80240022 역시 가장 흔한 원인으로 백신 소프트웨어가 SoftwareDistribution 같은 특정 폴더 접근을 차단하는 상황을 든다. 업데이트가 유독 한 대에서만 반복 실패한다면, 그 한 대에만 깔린 보안 소프트웨어를 잠시 내려보는 편이 DISM보다 빠르다.
서비스·정책 계열은 기업이나 학교 PC에서 특히 자주 만난다. 0x80070BC9 항목은 그룹 정책이 TrustedInstaller 서비스의 시작 유형을 수동으로 되돌려 놓으면, 재시작 후 처리해야 할 트랜잭션이 적용되지 못한 채 보류 상태로 남아 다른 모든 업데이트 설치를 막는다고 설명한다. 재부팅을 반복해도 같은 자리에서 실패하는 이유가 여기 있다. 조치는 정책을 자동으로 바꾸고 재시작하는 것이며, 그래도 풀리지 않으면 복구 환경에서 보류된 작업을 되돌리는 단계로 넘어간다.
추측을 끝내는 방법은 로그를 여는 것이다
코드만으로 계열이 좁혀지지 않을 때는 로그가 남아 있다. Windows Update 로그 파일 문서에 따르면 설치 단계의 실마리는 %systemroot%\Logs\CBS 폴더의 CBS.log에 남고, 업데이트 다운로드와 설치가 왜 시작되지 않았는지는 C:\ProgramData\USOShared\Logs의 오케스트레이터 추적 파일에 남는다. 한편 윈도우 8.1 이후의 업데이트 클라이언트는 ETW 방식으로 진단 로그를 만들기 때문에, 예전처럼 WindowsUpdate.log를 바로 열어볼 수는 없고 Get-WindowsUpdateLog 명령으로 추적 파일을 합쳐 읽을 수 있는 형태로 변환해야 한다.
실제 진단은 단순하다. CBS.log를 열어 쉼표와 error 문자열을 검색하고, 실패한 시각과 일치하는 줄을 찾은 다음 그 위로 거슬러 올라가며 어떤 파일이나 레지스트리 키에서 막혔는지 확인한다. 마이크로소프트가 0x80070005 같은 권한 오류의 조치로 제시하는 방법이 정확히 이것이다. 로그를 열기 전까지의 모든 조치는 추측이고, 로그를 연 다음의 조치는 확인이다.
정리하면, 순서를 바꾸는 것만으로 대부분이 줄어든다
정리하면 실전 순서는 이렇게 바뀐다. 먼저 화면의 코드를 받아 적는다. 그다음 공식 문서에서 그 코드를 찾아 어느 계열인지 확인한다. 네트워크 계열이면 프록시와 TLS부터, 저장소 손상 계열이면 그때 DISM과 SFC를, 권한 계열이면 백신과 폴더 권한을, 정책 계열이면 서비스 시작 유형을 본다. 계열이 모호하면 CBS.log를 연다.
문제 해결사를 먼저 돌려보는 것 자체는 여전히 합리적이다. 문제 해결 문서도 첫 단계로 내장 문제 해결사 실행을, 두 번째로 시스템 버전에 맞는 최신 서비싱 스택 업데이트 설치를 권한다. 다만 그것이 실패한 뒤부터는, 남은 시간을 어디에 쓸지가 코드에 따라 달라져야 한다. 서른여섯 개 코드가 일곱 갈래로 나뉘는데 모두에게 같은 처방을 적용할 이유는 없다.
마지막으로 덧붙이면, 이 글의 분류는 마이크로소프트 문서가 각 코드에 적어둔 조치 문구를 기준으로 한 것이고, 코드별 실제 발생 빈도를 잰 통계는 아니다. 문서에 실린 코드가 현장에서 만나는 모든 코드를 덮지도 않는다. 그럼에도 코드를 먼저 읽는 습관 하나만으로, 아무 근거 없이 같은 명령을 반복하는 시간은 확실히 줄어든다.