윈도우11 KB5066835 업데이트 문제 삭제 후 개발환경 복구후기 포트 바인딩 불가

윈도우11 KB5066835 업데이트 문제 삭제 후 개발환경 복구후기 포트 바인딩 불가에서 벗어나기

윈도우11 업데이트 직후부터 로컬에서 돌리던 웹앱이 뜻밖에 조용해졌다. 

브라우저는 응답을 기다리다 멈칫했고, Visual Studio 디버깅은 첫 단계에서 움직이지 않았으며, Docker로 띄운 백엔드 컨테이너는 정상적으로 떠 있는데도 외부에서 두드리면 아무 반응이 없었다. 

로그를 아무리 훑어봐도 애플리케이션 레벨의 예외는 없었고 결국 단서는 “포트가 열려 있는데 연결이 성립하지 않는다”는 기묘한 힌트였다. 문제를 좁혀보니 윈도우11의 KB5066835가 설치된 시점과 증상이 시작된 시점이 딱 겹쳤고, 해당 패치를 제거한 직후부터 localhost가 다시 숨을 쉬기 시작했다.

그럼 차근차근 복기해 보며 포트 바인딩 불가가 어떤 모습으로 나타났고, 무엇을 먼저 확인해야 시간을 덜 낭비하는지 기록한 복구 후기다

증상의 실제 체감: 서비스는 떠 있는데, 포트만 벽처럼 막힐 때

애플리케이션 프로세스는 정상 가동이고 CPU·메모리 사용량도 평소와 다르지 않았다. 

netstat로 확인하면 대상 포트는 LISTEN 상태인데 브라우저나 API 클라이언트에서 접근하면 곧바로 타임아웃이 나거나 HTTP/2 세션이 시작도 못 하고 떨어졌다. 

도커 컨테이너 앞단에 프록시를 두었을 때는 프록시가 502를 토해내며 백엔드로 핸드오프 자체를 못 하는 형태였다. 이런 패턴은 애플리케이션 내부 버그라기보다 커널 계층에서 소켓 수립이 가로막히는 때에 자주 보이는 얼굴이라 운영체제 쪽을 우선 의심했다

패치 제거로 반전된 흐름: 재부팅 한 번에 돌아온 localhost

패치 제거는 우선 순위를 단순하게 가져갔다. 

문제가 격발된 최신 패치를 먼저 지우고, 증상이 남으면 바로 이전 품질 업데이트까지 함께 되돌리는 흐름이다. 아래 명령으로 한 번에 처리했고, 재부팅 직후부터 127.0.0.1 응답이 정상으로 돌아왔다

wusa /uninstall /kb:5066835
wusa /uninstall /kb:5065789

삭제 이후에는 잠깐의 숨 고르기가 필요했다. IIS 앱풀과 Docker 데몬이 다시 초기화되며 포트를 재소유하는 데 수십 초 정도 걸렸고, 그 시간을 건너뛰고 바로 점검하면 또 실패로 오해하기 쉽다. 결국 중요한 건 “패치 제거 → 재부팅 → 서비스가 포트를 다시 잡도록 1~2분 대기 → 실제 호출”의 순서를 지키는 것이다

포트 바인딩 불가를 진단할 때 시간을 아껴주는 관찰 포인트

첫째, netstat이나 Get-NetTCPConnection에서 LISTEN이 보이더라도 안심하지 않는다. LISTEN 상태는 포트를 ‘소유’하고 있음을 의미할 뿐, 커널이 해당 요청을 정상적으로 ‘통과’시키고 있다는 보장은 아니다. 둘째, 127.0.0.1과 ::1을 각각 호출해 본다.

 특정 스택에서만 실패하는지 확인하면 우회 실마리가 생긴다. 셋째, 동일 바이너리를 다른 포트로 즉시 띄워본다. 

애플리케이션 문제가 아니라면 포트만 바꾼 인스턴스에서도 동일하게 막히는 경향이 강하다. 이 세 가지 체크를 통해 애플리케이션 레벨에서 헤매는 시간을 크게 줄일 수 있었다

IIS · Docker · WSL별 복구 후 점검 스냅샷

운영 체감상 각 환경은 비슷한 원인으로 막히지만 회복되는 체감 포인트는 조금씩 달랐다. 아래 표의 항목을 순서대로 확인하면 재가동 직후의 불안정을 빠르게 정리할 수 있었다

환경	정상화 확인 포인트	필요 시 추가 점검
IIS	appcmd로 사이트 상태 확인 후 localhost 즉시 응답	앱풀 재시작, 포트 재바인딩, URL 예약 상태 재확인
Docker	컨테이너 기동 직후 포트 노출이 Established로 전환	compose 강제 재생성, 프록시 컨테이너부터 순차 재기동
WSL	wsl --shutdown 이후 백엔드 프로세스 재기동 즉시 호출 성공	네임 리졸브보다 127.0.0.1 직통 호출로 먼저 검증

재발 방지까지 포함해야 진짜 복구: 자동 재설치 차단의 필요

여기서 멈추면 같은 문제가 며칠 뒤 슬그머니 돌아온다. 

업데이트가 백그라운드에서 동일 KB를 재배포하기 때문이다.

 블로킹을 과하게 걸 필요는 없지만 최소한 문제 KB가 자동으로 재설치되지 않도록 업데이트 지연 또는 정책 기반 차단을 걸어두면 장기적으로 훨씬 평온하다. 

마이크로소프트 공식 수정이 배포되면 일시적으로 해제하고 검증된 핫픽스만 수동 적용하는 방식이 가장 안전했다

개발 흐름을 지키는 소소한 팁: 느린 복구 구간을 오해하지 않기

패치 제거와 재부팅 직후 성급하게 부하를 걸면 아직 데몬이 소켓을 완전히 잡지 못한 상태에서 재차 실패가 난다. 그때마다 설정을 뒤흔들면 오히려 회복 시간을 늘린다. 

포트를 다시 연 직후에는 짧은 웜업 구간이 자연스럽다. 모니터링을 켜두고 Established 전환을 확인한 다음 실제 트래픽을 흘리는 식으로 리듬을 잡으면 체감상 훨씬 매끄럽다

정리하며: 포스트모템 관점에서 남겨둔 체크리스트

애플리케이션 로그가 말이 없고, 프로세스는 멀쩡하고, 포트는 열린 것 같은데 요청이 들어오지 않는다면 커널 쪽의 간섭을 의심해 보는 것이 시간을 아낀다. 이번 케이스는 업데이트 제거가 즉효였고, 재설치 차단으로 안정성을 되찾았다. 무엇보다도 복구 과정에서 “서비스 재기동 → 포트 재확보 → 웜업 대기”의 순서를 지키는 습관이 다음 장애에서도 강력한 방어선이 될 것이다

FAQ. 포트가 LISTEN인데도 cURL이 멈추는 이유는 무엇일까?

LISTEN은 포트를 소유 중이라는 신호일 뿐이다. 커널이 연결 수립을 정상적으로 통과시키지 않으면 클라이언트에서는 SYN 이후 왕복이 매끄럽게 이어지지 않아 타임아웃으로 끝난다. 애플리케이션 로그가 비어 있는 이유도 그 지점 이전에서 끊기기 때문이다

FAQ. 패치 제거 뒤에도 간헐적으로 느린 이유는?

서비스가 포트를 재바인딩하고 내부 캐시와 JIT, 컨테이너 네트워크를 따로 올리는 구간이 있어 초기 호출이 굼뜰 수 있다. 이 구간은 정상적인 웜업이며, 반복 지연이 아니라면 성능 이슈로 볼 필요가 없다

FAQ. 방화벽 예외나 hosts 수정으로 해결이 안 되는 까닭은?

방화벽과 hosts는 사용자 공간의 경로 문제를 다룬다. 커널 계층에서 응답 자체가 누락되면 이 두 설정을 바꿔도 증상은 그대로다. 문제의 층위를 구분해 접근해야 한다

FAQ. Docker만 쓰는데 IIS 점검이 필요한가?

직접 IIS를 사용하지 않더라도 동일한 커널 네트워크 스택 위에서 돌아간다. 포트 점유 충돌이나 URL 예약, 소켓 재확보 과정은 공통으로 확인해 두는 편이 안전하다

FAQ. 재설치 차단은 언제 풀어야 할까?

문제가 해결된 수정 패치가 공개되면 창구를 잠시 열어 검증된 KB만 수동으로 적용한다. 이후에는 다시 자동 배포를 켜도 무방하지만 동일 증상이 재현되면 즉시 차단을 재적용한다

관련 명령어 모음

rem 문제 패치 제거
wusa /uninstall /kb:5066835
wusa /uninstall /kb:5065789

rem 설치 내역 검증
Get-HotFix | findstr 5066835
Get-HotFix | findstr 5065789

rem WSL 초기화
wsl --shutdown