KB5066835 자동 재설치 완전 차단 방법과 윈도우11 개발환경 안정화
KB5066835를 삭제만 하고 두면 윈도우가 일정 시간이 지나 자동으로 다시 패치를 내려받기 때문에 localhost가 멀쩡히 돌아오다가도 어느 날 갑자기 또 막혀버리는 현상이 반복될 수 있습니다.
이번 문제는 단순 앱 호환성 수준이 아니라 커널 계층에서 HTTP.sys가 막히는 수준의 충돌이라 자동 업데이트 차단까지 반드시 포함해야 실질적인 해결로 이어집니다.
업계에서는 이를 ‘삭제 → 차단 → 개발환경 재점검’까지를 하나의 세트로 보고 있고, 마이크로소프트가 공식 핫픽스를 내기 전까지는 이 방식이 사실상 표준 대응 절차처럼 쓰이고 있습니다
일반적인 업데이트 일시중단만으로는 재배포를 완전히 막을 수 없어서 그룹 정책 설정이 함께 적용되면 보다 안정적으로 재설치를 차단할 수 있습니다.
KB5066835 삭제 이후 재발 방지 설정과 개발 환경 정상화 체크리스트 (IIS / Docker / WSL
KB5066835를 삭제하면 localhost 자체는 대부분 복구되지만, 문제는 윈도우가 자동으로 다시 업데이트를 내려받아 재설치하려고 시도한다는 점입니다. 개발자 커뮤니티에서는 이를 ‘1회성 해결’이
jab-guyver.co.kr
특히 기업 단위 개발 PC나 상시 로컬 서버 환경이 돌아가는 워크스테이션은 운영체제가 임의로 패치를 덮어씌우면 개발 서비스가 멈출 위험이 있으므로, 일정 수준의 차단은 현실적으로 필수에 가깝습니다.
재활성화는 공식 수정 패치가 배포되기 전 다시 준비되면 그때 수동으로 해제하면 됩니다
아래는 가장 많이 사용되는 차단 방식의 비교표입니다
차단 방식 | 장점 | 적용 범위 | 권장도 |
업데이트 일시 중단 | 간단, UI 기반 | 짧은 기간 | 낮음 |
네트워크 지연 설정 | 업데이트 서버 응답 지연 | 팀 단위 공통 적용 가능 | 중간 |
그룹정책 비활성화 | 자동 재설치 사실상 근본 차단 | 기업/개발PC 최적 | 높음 |
그룹 정책 설정을 해두면 Windows가 동일한 KB 패치를 다시 가져오지 못해 재발 가능성이 가장 낮습니다.
일부 개발자들은 PowerShell 스크립트로 배치해두고 OS 재시작 시 자동으로 정책을 유지하는 방식도 함께 사용하고 있는데, 실제로 장기간 사용하는 PC라면 안정성 측면에서 도움이 되는 방식입니다.
이와 같은 차단 설정까지 적용하면 IIS, Docker, WSL 모두 정상적인 포트 바인딩이 유지되고, 재부팅이나 환경 재초기화 과정에서도 재차 충돌이 일어나지 않으므로 작업 흐름을 되찾을 수 있습니다
윈도우11 KB5066835 삭제로 localhost 오류 복구하는 방법
윈도우11에서 localhost가 막히는 현상은 생각보다 원인이 단순합니다. 커널 단에서 HTTP.sys가 패치와 충돌해 바인딩 요청을 처리하지 못하고 있는 형태인데, 이를 풀어내는 가장 현실적인 방법이
jab-guyver.co.kr
FAQ
그룹 정책 변경은 나중에 다시 원복 가능한가요?
예, 언제든지 동일 경로에서 정책을 ‘구성 안 함’으로 바꾸면 다시 자동 업데이트가 동작합니다. 영구 봉인이 아니라 임시 제어라고 보면 됩니다
Microsoft가 핫픽스를 내면 재차단 해제 후 설치해도 되나요?
핫픽스가 공식 배포되면 업데이트 차단을 해제하고 수동 설치한 뒤 정책을 다시 원래대로 돌리면 됩니다. 핵심은 문제 KB가 아닌 정정 KB인지 확인하는 것입니다
이 방식이 다른 업데이트에도 영향을 주나요?
자동 전체 업데이트를 막는 구조가 아니라 특정 KB가 다시 내려오는 경로를 막는 수준이기 때문에 보안 패치 전체에 큰 영향은 없습니다