이 글을 3줄로 요약하면
· 0x8024402c는 WU_E_PT_WINHTTP_NAME_NOT_RESOLVED, 프록시 서버나 대상 서버의 이름을 확인하지 못했다는 뜻입니다.
· 파일이 손상된 게 아니라 서버까지 가는 길이 막힌 상태라, 업데이트 재시도만 반복해도 그대로입니다.
· 개인 PC인지 회사 PC인지에 따라 볼 항목이 갈립니다. 아래 판별표에서 자기 환경을 먼저 찾으세요.
0x8024402c는 정확히 무슨 뜻인가
코드 이름 하나가 이미 원인의 범위를 절반으로 줄여 줍니다.
마이크로소프트 공식 문서는 이 코드를 WU_E_PT_WINHTTP_NAME_NOT_RESOLVED로 정의하고, "프록시 서버 또는 대상 서버 이름을 확인(resolve)할 수 없다"는 설명을 붙여 두었습니다. Win32의 ERROR_WINHTTP_NAME_NOT_RESOLVED와 같은 상태입니다.
즉 이 오류는 업데이트 파일이 잘못됐다는 뜻이 아닙니다. 파일을 받으러 가야 할 서버의 주소를 이름으로 찾는 단계에서 실패한 것입니다. 그래서 SFC나 DISM부터 돌리는 접근은 대개 시간만 씁니다. 먼저 볼 곳은 네트워크와 정책입니다.
같은 문서는 이 실패가 인터넷의 윈도우 업데이트로 직접 붙는 경우와 사내 WSUS 서버로 붙는 경우 양쪽에서 모두 일어날 수 있다고 구분합니다. 이 구분이 이 글의 판별 기준입니다. 개인 PC와 회사 PC는 확인해야 할 항목이 아예 다릅니다.
시작하기 전에 코드가 정말 이 번호가 맞는지부터 확인해 두는 편이 좋습니다. 설정 → Windows 업데이트 → "업데이트 기록"을 열면 실패한 항목 옆에 코드가 그대로 표시됩니다. 실패 항목이 여러 개인데 코드가 서로 다르면 원인도 하나가 아닙니다.
환경과 증상으로 원인 좁히기
어떤 PC에서 언제 떴는지가 확인 순서를 정합니다.
| 증상 | 유력한 원인 | 먼저 볼 항목 |
|---|---|---|
| 브라우저는 되는데 업데이트만 실패, 개인 PC | 업데이트가 쓰는 이름 확인 경로만 막힘 | 원인 A → nslookup·DNS |
| VPN을 켜 둔 상태에서만 발생, 끄면 진행됨 | VPN이 DNS·프록시 경로를 바꿔 놓음 | 원인 B → 프록시 초기화 |
| 회사·기관 PC, 다른 직원 PC도 같은 증상 | 사내 WSUS 서버 연결 불가 | 원인 C → UseWUServer |
| ".NET Framework 3.5" 같은 선택적 기능 설치 중 발생 | FoD를 WSUS에서 받지 못하는 버전 조합 | 원인 C → 버전 조건 |
| 네트워크는 정상인데 매번 같은 자리에서 실패 | 업데이트 캐시·구성 요소 손상 | 원인 D → 캐시 초기화 |
| 공유기를 바꾸거나 회선을 옮긴 뒤부터 발생 | DNS 서버 응답 문제 | 원인 A → DNS 변경 |
원인 ADNS 이름 확인 실패
코드 이름이 직접 가리키는 곳이라 여기부터 봅니다.
공식 문서가 안내하는 첫 단계도 ping으로 연결을, nslookup으로 이름 확인을 각각 검증하는 것입니다. 두 가지는 다른 것을 봅니다. 이름 확인이 안 되면 연결 자체가 시작되지 않습니다.
1이름 확인이 되는지 먼저 본다
주소가 여러 개 나오면 이름 확인은 정상입니다. "서버가 응답하지 않습니다"나 시간 초과가 나오면 DNS 쪽이 원인으로 확정됩니다.
2DNS 캐시를 비운다
예전에 실패한 응답이 캐시에 남아 계속 재사용되는 경우가 있습니다. 비운 뒤 업데이트를 한 번 다시 시도합니다.
3DNS 서버를 바꿔 본다
Win + R에 ncpa.cpl을 입력해 어댑터 목록을 열고, 사용 중인 어댑터 우클릭 → "속성" → "인터넷 프로토콜 버전 4(TCP/IPv4)" → "속성"에서 DNS 서버를 직접 지정합니다. 바꾼 뒤 ipconfig /flushdns를 한 번 더 실행합니다.
회사 PC에서는 DNS를 임의로 바꾸지 않습니다
사내망은 내부 이름을 사내 DNS로만 찾을 수 있게 구성된 경우가 많습니다. 공용 DNS로 바꾸면 업데이트는커녕 사내 시스템 접속까지 끊길 수 있습니다. 회사 장비라면 이 단계를 건너뛰고 원인 C로 가세요.
이 방법이 안 통하는 경우
nslookup은 정상인데 업데이트만 실패한다면 이름 확인은 문제가 아닙니다. 업데이트 구성 요소는 브라우저와 다른 경로(WinHTTP 프록시 설정)를 쓰므로 원인 B로 넘어가세요.
원인 B프록시·VPN·방화벽이 요청을 가로챔
브라우저는 멀쩡한데 업데이트만 막히는 전형적인 갈래입니다.
윈도우 업데이트는 브라우저의 프록시 설정을 그대로 쓰지 않고 시스템 수준의 WinHTTP 프록시 설정을 따릅니다. 예전에 켰던 VPN이나 보안 프로그램이 이 값을 남겨 두면, 브라우저는 정상인데 업데이트만 존재하지 않는 프록시로 가려다 이름 확인에서 실패합니다.
1현재 WinHTTP 프록시 설정을 확인한다
"직접 액세스(프록시 서버 없음)"가 정상 상태입니다. 여기에 모르는 주소가 찍혀 있으면 그것이 원인입니다.
2프록시와 네트워크 스택을 초기화한다
관리자 터미널에서 위에서부터 차례로 실행하고 재부팅합니다. 사내 프록시를 반드시 거쳐야 하는 환경이라면 이 초기화가 오히려 접속을 끊으므로, 회사 장비에서는 담당자 확인 후에 실행하세요.
3VPN과 보안 프로그램을 끈 상태로 한 번만 확인한다
VPN을 끄고 업데이트가 진행되면 원인이 확정됩니다. 확인이 끝나면 보안 프로그램은 반드시 다시 켭니다. 끈 상태로 두는 것은 해결이 아닙니다.
브라우저 프록시와 시스템 프록시는 다른 설정입니다
설정 앱의 "프록시"를 껐어도 WinHTTP 값은 그대로 남아 있을 수 있습니다. 반드시 netsh winhttp show proxy로 별도로 확인하세요. 이 차이 때문에 "프록시 껐는데도 그대로"라는 상황이 생깁니다.
이 방법이 안 통하는 경우
프록시가 비어 있고 VPN도 안 쓰는데 같은 코드가 반복된다면, 업데이트를 받아 올 대상 자체가 사내 서버로 지정돼 있을 수 있습니다. 원인 C로 넘어가세요.
원인 C사내 업데이트 서버(WSUS) 지정
회사·기관 장비이거나 선택적 기능 설치 중이라면 여기가 핵심입니다.
정책으로 사내 업데이트 서버가 지정되면, PC는 마이크로소프트가 아니라 그 서버에만 업데이트를 요청합니다. 서버 이름을 확인하지 못하면 결과는 똑같이 0x8024402c입니다. 공식 문서도 이 경우를 별도 항목으로 나눠 설명합니다.
1정책 값이 걸려 있는지 확인한다
레지스트리 편집기 주소창에 HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU를 붙여 넣습니다. 키 자체가 없으면 사내 서버 지정이 아니므로 이 항목은 해당되지 않습니다. UseWUServer 값이 1이면 사내 서버로만 받도록 지정된 상태입니다.
2지정된 서버 주소가 실제로 닿는지 본다
한 단계 위 WindowsUpdate 키의 WUServer 값에 서버 주소가 적혀 있습니다. 그 주소를 nslookup으로 확인해 보면, 이름이 안 풀리는지 아니면 풀리는데 응답이 없는지가 갈립니다.
회사 장비의 이 값을 임의로 바꾸지 않습니다
정책으로 배포된 값이라 개인이 바꿔도 다음 정책 적용 때 되돌아가고, 보안 업데이트 관리 체계에서 이탈하게 됩니다. 확인만 하고 "WSUS 서버 이름 확인에 실패하고 있다"는 사실을 담당자에게 전달하는 편이 훨씬 빠릅니다.
선택적 기능(FoD)은 버전 조합을 먼저 확인합니다
공식 문서 기준으로 선택적 기능을 WSUS에서 받으려면 Windows Server 2025 이상 또는 윈도우 11 22H2 이상이어야 합니다. Windows Server 2022·2019와 윈도우 11 21H2 이하는 WSUS로 FoD를 받을 수 없어 ISO 이미지나 네트워크 리포지토리를 써야 합니다. 이 조합이면 네트워크를 아무리 손봐도 같은 코드가 반복됩니다.
이 방법이 안 통하는 경우
개인 PC라 정책 키가 아예 없고 네트워크도 정상이라면 남은 갈래는 업데이트 구성 요소 쪽입니다. 원인 D로 넘어가세요.
원인 D업데이트 캐시와 구성 요소 손상
네트워크가 확실히 정상인데도 같은 자리에서 실패할 때 씁니다.
업데이트 관련 파일과 인증서 저장소가 어긋나면, 통신은 되는데 이후 단계에서 실패하며 앞 단계의 코드를 그대로 물고 나오는 경우가 있습니다. 이때는 서비스를 멈추고 캐시 폴더를 비웁니다.
1관련 서비스를 멈춘다
"서비스를 중지했습니다"가 세 번 모두 나와야 합니다. 하나라도 실패하면 재부팅 후 다시 시도합니다.
2캐시 폴더 두 곳의 내용을 비운다
탐색기로 C:\Windows\SoftwareDistribution과 C:\Windows\System32\catroot2를 열고 안의 내용만 지웁니다. 폴더 자체는 남겨 둡니다. 지워진 파일은 다음 업데이트 확인 때 새로 만들어집니다.
3서비스를 다시 켜고 재시도한다
서비스 창에서 Windows Update의 상태가 "실행 중", 시작 유형이 "수동(트리거 시작)" 또는 "자동"인지 확인한 뒤 업데이트를 다시 확인합니다.
이 방법이 안 통하는 경우
캐시를 비운 뒤에도 같은 코드가 나온다면 손상은 원인이 아닙니다. 다시 원인 A~C로 돌아가되, 다음 항목의 기록과 로그로 실패 지점을 먼저 특정한 뒤 움직이세요.
어느 단계에서 막혔는지 정확히 찾아내는 법
기록과 로그를 보면 어느 원인으로 갈지가 확정됩니다.
1업데이트 기록에서 실패 항목과 코드를 확인한다
코드가 정말 0x8024402c인지, 다른 코드가 섞여 있는지부터 확인합니다. 여러 코드가 번갈아 나온다면 원인이 하나가 아니라는 신호입니다. 실패 시각도 함께 기억해 둡니다.
2업데이트 로그를 읽을 수 있는 형태로 뽑는다
관리자 파워셸에서 실행하면 바탕화면에 WindowsUpdate.log가 만들어집니다. 실패 시각 근처에서 어떤 주소로 붙으려다 실패했는지 확인하면, 대상이 마이크로소프트인지 사내 서버인지가 바로 드러납니다.
3문제 해결사로 구성 요소 상태를 한 번에 점검한다
설정 → "시스템" → "문제 해결" → "기타 문제 해결사"의 Windows Update 항목을 실행하면 서비스 상태와 캐시를 자동으로 점검합니다. "문제를 찾지 못했습니다"가 나오면 구성 요소는 정상이라는 뜻이므로 네트워크 쪽(원인 A·B)으로 좁혀집니다.
자주 묻는 질문
검색으로 자주 들어오는 질문만 추렸습니다.
Q.인터넷은 잘 되는데 왜 업데이트만 안 되나요?
A.브라우저와 업데이트가 서로 다른 프록시 설정을 보기 때문입니다. 업데이트는 시스템 수준의 WinHTTP 설정을 따르므로, netsh winhttp show proxy로 그 값을 따로 확인해야 합니다.
Q.SoftwareDistribution 폴더를 비우면 받아 둔 업데이트가 사라지나요?
A.내려받아 둔 파일은 지워지고 다음 확인 때 다시 받습니다. 이미 설치가 끝난 업데이트는 영향을 받지 않으며, 폴더는 자동으로 다시 만들어집니다.
Q.코드가 0x8024402c가 아니라 0x80244로 시작하는 다른 번호입니다.
A.0x80244 계열은 업데이트 클라이언트와 서버 사이의 통신 단계에서 나오는 코드 묶음이라 확인 지점이 겹칩니다. 다만 뒷자리마다 실패 지점이 달라서, 정확한 원인은 해당 코드의 정의를 따로 확인하는 편이 안전합니다.
Q.회사 노트북인데 담당자 없이 혼자 해결할 수 있나요?
A.정책으로 잠긴 항목은 개인이 바꿔도 되돌아갑니다. 원인 C의 확인까지만 하고, WSUS 서버 이름 확인에 실패하고 있다는 점을 담당자에게 전달하는 쪽이 빠릅니다. 확인 결과와 실패 시각을 함께 알려 주면 더 좋습니다.
Q.문제 해결사가 "문제를 찾지 못했습니다"라고만 나옵니다.
A.문제 해결사는 서비스와 캐시 같은 로컬 구성 요소만 봅니다. 이 결과는 "구성 요소는 정상"이라는 정보로 읽고, 원인 A와 B의 네트워크 확인으로 넘어가면 됩니다.
함께 보면 좋은 글
같은 윈도우 업데이트 계열 오류를 다룬 글입니다.
윈도우 업데이트 0x80070422 오류 해결 순서 업데이트 서비스가 아예 꺼져 있을 때 나오는 코드입니다 · 눌러서 확인하기 → 윈도우 업데이트 0x80073712 오류 해결 순서 구성 요소 저장소가 손상됐을 때 확인할 글입니다 · 눌러서 확인하기 → 윈도우11 업데이트 0x800f0922 오류 해결 순서 VPN 환경에서 함께 자주 나오는 업데이트 오류입니다 · 눌러서 확인하기 →참고 문서 · Error Code 0x8024402C When You Try to Install a Windows Update or a Feature on Demand (Microsoft Learn)
