갑자기 나타나는 블루스크린(Blue Screen of Death, BSOD)은 언제나 당황스럽습니다. 거의 30년간 소프트웨어로 인한 하드웨어 불안정이라는 경쟁 구도 속에서, 윈도우가 마침내 리눅스를 따라잡았다는 보고를 할 수 있게 되었습니다. 몇 달 전, 윈도우는 지금까지 한 치의 흐트러짐도 없이 안정적으로 돌아가던 제 데스크톱에 '시'로 남을 선물을 안겨주었는데, 바로 연이어 발생한 BSOD 충돌이었습니다.
2025년 7월 업데이트를 적용한 직후, 평소처럼 안정적이던 데스크톱이 무작위로 크래시하기 시작했습니다. 신뢰성이 일순에 바닥으로 추락한 것이죠. 마치 제 리눅스 머신들을 괴롭히던 문제들과 다를 바 없었습니다. 참으로 짜릿한 경험이 아니랄 수 없습니다.
저는 컴퓨터 문제를 대할 때 항상 자기 자신부터 의심합니다. 내가 원인을 만들었거나, 내 시스템에 결함이 있다고 가정하죠. 그런데 매번, 정말 매번 결과는 같았습니다. 범인은 아니요, 특정 벤더가 판매하는 형편없는 소프트웨어였고, 그것이 저의 고요함을 깨고 하드웨어를 오작동하게 만든 것입니다. 이번 사건 역시 예외는 아니었습니다. 7월의 무해해 보이는 월간 업데이트로 시작된 이야기가 어떻게 BSOD로 번졌는지, 함께 살펴보겠습니다.
가만히 있던 시스템이 갑자기 멈추다
어느 토요일 아침, 일어나 보니 데스크톱이 스스로 재부팅되어 있었습니다. 이벤트 뷰어(Event Viewer)를 확인했지만, 시스템이 예기치 않게 종료되었다는 커널 파워 이벤트 외에는 아무런 단서도 없었습니다. 그 직후 Notepad++로 텍스트 파일을 열려는 순간 BSOD가 발생했습니다. 드라이버가 아니라 메인 커널 스레드에서 발생한 예외였습니다. 이상하네요. 참고로 저는 커널 크래시 분석에 상당히 능숙한 편인데, 이 사건조차 특정 범인을 가리키지 않았습니다.
시스템이 복구된 후 시스템 검사와 DISM 복구를 실행하고, 한동안 그대로 두었습니다. 그런데 약 일주일 동안 하루에 두 번씩 "문제가 발생했습니다(Something happened)"라는 알 수 없는 대화상자가 나타났습니다. 아무리 들여다봐도 원인을 찾을 수 없었습니다.
결국 이벤트 뷰어의 정보 섹션에서 다음과 같은 기록을 발견했습니다.
WindowsUpdateClient, 이벤트 ID 44
Windows Update가 업데이트 다운로드를 시작했습니다.
Windows 10 Version 22H2 x64 기반 시스템용 2025-07 누적 업데이트(KB5062554)
시스템은 7월 업데이트를 다시 다운로드하려 했지만 계속 실패하고 있었습니다. 즉, 이 패치에 심각한 문제가 있다는 뜻입니다. 며칠 후, 밤사이 아무 작업도 없는데 또 크래시가 발생했습니다. 다음 날 Windows Update를 실행했지만 7월 업데이트든 더 최신 업데이트든 아무것도 받을 수 없었습니다.
이 시점에서 저는 시스템 이미지를 7월 패치 직후 시점으로 복원하기로 했습니다. XP 시절부터 저는 월간 패치 전후로 항상 전체 이미지를 백업해 왔습니다. 덕분에 마이크로소프트가 버그를 도입하더라도 롤백할 수 있으니까요.
8월 스냅샷을 복원했는데, 부팅 과정에서 데스크톱이 로드되기도 전에 또 BSOD가 발생했습니다. 데스크톱 진입 후에는 2025년 10월 업데이트 세트(윈도우 ESU 프로그램을 이용하지 않는 한 윈도우 10용 마지막 업데이트)까지 적용했습니다. 이로써 "문제가 발생했습니다" 오류는 사라졌습니다.
그러나 약 11일 후, 파일 관리자를 사용하는 중 다시 BSOD가 발생했습니다. 또 다른 커널 함수 오류였고, 주소 오프셋은 거의 동일했습니다. 결국 저는 7월 이전 상태로 완전히 되돌리기로 했습니다. 즉, 7월 이전의 시스템 이미지를 사용한 것입니다.
이것이 도움이 되었는지는 곧 말씀드리겠습니다. 우선 전체 사건의 흐름을 정리해 보겠습니다.
문제의 타임라인
정리하면 다음과 같습니다:
- 완벽하게 안정적이던 데스크톱이 8월 초 7월 패치를 받았습니다. 단, 드라이버는 하나도 건드리지 않았습니다. 자동 드라이버 업데이트는 처음부터 비활성화해 두었거든요.
- 몇 주 후, 이벤트 뷰어에서 dwm.exe 오류를 발견했습니다. 문제와 관련이 있을 수 있어 언급해 둡니다.
- 며칠 후 밤사이 크래시 발생. BSOD 없이 재부팅되었습니다.
- 다음 날, 미니덤프 파일이 수집된 첫 번째 크래시가 발생했습니다.
- 약 2주 후, 또 다른 유휴 상태 야간 크래시. 이번에도 BSOD는 생성되지 않았습니다.
- 7월 업데이트 직후 시점으로 시스템 복원 → 부팅 중 BSOD.
- 2025년 10월 수준으로 업데이트.
- 며칠 후, 시스템이 아무 작업도 하지 않는 상태에서 엔비디아 드라이버 오류 발생:
오류 응용 프로그램 이름: NVDisplay.Container.exe, 버전: 1.39.3323.1171
오류 모듈 이름: ntdll.dll, 버전: 10.0.19041.6456
예외 코드: 0xc0000005
- 4일 후, 마지막으로 기록된 BSOD 발생.
- 7월 업데이트 이전 상태로 시스템 복원.
그리고 그 이후 지금까지 3개월째 시스템은 놀랄 만큼 안정적으로 유지되고 있습니다.
엔비디아? 하드웨어? 드라이버?
아니요. 물론 저도 똑같은 생각을 했습니다. 하지만 저는 드라이버를 전혀 업데이트하지 않았습니다. 그렇다면 왜 드라이버 탓을 해야 할까요? 게다가 데스크톱이 로드되기도 전에 부팅 중에 크래시가 발생했다는 점은 어떻게 설명할 수 있을까요? 그렇다면 엔비디아는 공식에서 빠져야 하는 것 아닌가요?
하드웨어라면 어떨까요? 윈도우 하드웨어 이벤트 로그는 비어 있었고, 신뢰성 보고서도 비어 있었습니다. 부하 상태에서도 모든 것이 완벽하게 작동했습니다. 7월 업데이트 이후 상태에서 수많은 게임 플레이, 16스레드 7z 압축 작업, 3D 디자인 작업 등 온갖 테스트를 해봤지만 문제가 전혀 없었습니다.
문제는 오직 시스템이 유휴 상태일 때만 발생했습니다.
유휴 상태 시스템, 유레카!
솔직히 이 시점에서 조금 화가 났습니다. 엔터프라이즈 환경에서 커널 크래시를 수없이 다뤄온 경험상, 유휴 상태에서 커널 패닉이 발생하는 시스템을 너무 자주 접해 왔기 때문입니다. 물론 그런 경우 예외 코드는 다르고, 대개 불량 CPU나 메모리가 원인이었습니다.
늘 그렇듯 자기 자신부터 의심하는 방식으로 돌아가, 하드웨어 문제일 수 있다고 생각했습니다. 하지만 여전히 설명이 되지 않았습니다. 부하가 없을 때, 즉 프로세서가 저전력 상태일 때만 문제가 나타났으니까요.
그래서 인터넷에서 "AMD Ryzen BSOD idle"을 검색해 봤습니다. 어머나. 제 경우와 완전히, 문자 그대로 완전히 동일한 문제를 논하는 글과 스레드가 쏟아져 나왔습니다. 수년간 완벽하게 작동하던 시스템들이 갑자기 잦은 크래시를 겪기 시작한 것이고, 그 시점이 모두 7월 업데이트와 일치했습니다. 그리고 그 글들은 잠재적인 우회 방법도 짚어주고 있었습니다. 바로 CPU 전압을 아주 조금 변경하는 것이었습니다.
그때 깨달음이 찾아왔습니다. 7월 업데이트는 각종 사이드 채널 공격 완화 조치를 도입했고, 이것이 아마 전원 관리 설정을 건드렸을 가능성이 큽니다. 전원 플랜이 아주 조금이라도 어긋나면 시스템 크래시를 유발할 수 있습니다. 이를 확인하는 가장 빠르고 저렴한 방법은 7월 패치 이전 상태로 되돌리는 것입니다. 다행히 이미지는 준비되어 있었습니다.
그래서 시스템을 되돌렸습니다.
관찰 결과
3~4개월간 데이터를 수집한 결과, 7월 패치 전후로 제 윈도우 10에서 달라진 점은 다음과 같습니다:
- 패치 이후에는 DWM과 엔비디아 드라이버를 포함해 응용 프로그램 및 게임 크래시가 더 많아졌습니다. 이전에는 단 한 번도 없었습니다.
- 패치 이후에는 엔비디아 그래픽 카드가 유휴 상태에서 무려 10도나 더 뜨거워졌습니다. 기존에는 36~37도에서 유지되던 것이 46~47도로 올라갔습니다. 예전 이미지를 복원한 후에는 정상 온도로 돌아왔습니다.
- 7월 이전 상태에서 시스템이 더 빠르고 반응성이 좋습니다.
- 무엇보다 중요한 것은, 7월 이전 상태에서는 BSOD가 전혀 발생하지 않는다는 점입니다.
하필 이 시점에 왜?
회의적인 분들은 이렇게 말할지도 모릅니다. "어머, 하필 윈도우 10 지원 종료(EOL) 직전에 이런 일이 생기네! 윈도우 11로 '업그레이드'하면 해결되는 거 아니야?" 아닙니다. 이것은 음모가 아닙니다. 훨씬 그럴듯한 설명은 순수한 무능함입니다. 지난 몇 년간 윈도우 데스크톱의 품질은 꾸준히 하락해 왔고, 전설처럼 여겨지던 월간 업데이트는 우스꽝스러운 존재가 되었습니다. 마이크로소프트는 리소스를 윈도우 11과 AI 따위로 돌리고 있으므로, 은퇴를 앞둔 오래된 시스템을 그냥 방치했을 가능성이 높습니다.
분명히 말해두겠습니다. 저는 이 시스템을 윈도우 11로 업그레이드하지 않을 것이고, 윈도우 11을 사용할 생각도 없습니다. "시스템과 드라이버를 업데이트하세요"라는 말은 형편없는 코딩의 치료법이 아닙니다. 그런 논리는 절대 지지하지 않겠습니다. 끝.
악의는 보이지 않습니다. 방치가 보일 뿐입니다. 그리고 무엇보다, 이번 BSOD는 윈도우를 진짜 중요한 작업에는 앞으로도 영원히 사용하지 않겠다는 결심을 더욱 굳건하게 만들었습니다. 그동안 저에게는 '윈도우는 안정적이고 리눅스는 말썽꾸러기'라는 명분이 있었습니다. 하지만 이제 두 운영체제 모두 그저 그런 수준이 되었으니, 그 가공의 '갈등'은 사라졌습니다. 리눅스는 이제 충분히 현실적인 선택지입니다. 그리고 더 중요한 것은, 맥북 프로를 구매한 현명한 선택에 대해 감사하게 생각한다는 점입니다. 이제 이런 소프트웨어 걱정은 거의 오락거리 수준이 되었으니까요.
결론
때로는 뼈아픈 각성이 필요합니다. 스스로 준비가 되어 있지 않을 때, 누군가가 필요한 격려를 해주는 것이죠. 올바른 방향으로 나아갈 수 있는 딱 맞는 에너지를요. 윈도우 사용을 접는 데 도움을 준 마이크로소프트에게 감사를 전합니다. 이미 결심하고 있었지만, 이번 연쇄적인 BSOD는 그 결심을 확신으로 바꿔주었습니다. 잘 만들어진 시스템을 이렇게 망가뜨리다니, 마치 정교하게 그려진 작품 위에 페인트를 쏟아붓는 격입니다.
마이크로소프트가 7월에 무엇을 했든, 제 데스크톱을 심각하게 망가뜨렸습니다. 7월 이전 상태로 되돌리니 모든 것이 해결되었습니다. 속도, 온도, 응용 프로그램과 게임의 안정성, 그리고 무엇보다 시스템의 안정성까지요. 저는 이 문제가 100% 소프트웨어 문제라고 확신합니다. 아마 새로운 완화 조치, Secure Boot 관련 설정, 전원 관리 변경 등이 복합적으로 작용해 제 평온을 파괴한 것으로 보입니다. 물론 저답게 잠재적인 하드웨어 문제의 가능성도 열어두고 있습니다. 위의 모든 현상이 기판, CPU, 메모리 등의 기이한 동작 때문일 아주 작은 확률은 존재하니까요. 그 의심도 기록으로 남겨둡니다. 새로운 사실이 밝혀지면 반드시 다룰 것입니다. 하지만 지금까지 확인할 수 있는 모든 것을 종합하면, 이는 소프트웨어 문제라는 논리적 결론에 도달합니다.
그래도 괜찮습니다. 중요하지 않습니다. 이것이 제 윈도우의 유산이 될 것입니다. 오래도록 기억할 값비싼 교훈이죠. 제가 가장 경멸하는 것은 아마추어리즘인데, 이제 윈도우는 그 금메달을 차지했습니다. 이제는 리눅스의 하드웨어 관련 말썽도 좀 더 가볍게 받아들일 수 있고, 맥북의 영광 속에서 휴식을 즐길 수 있습니다. 이 씁쓸하면서도 달콤한 말들로 인사를 마무리하겠습니다.
감사합니다.