Arm 윈도우 노트북 덮개 덮어두면 왜 자꾸 꺼지는겨?

Summary 노트북 덮개를 닫았다 열면 시스템이 절전 모드에서 깨어나지 못하는 문제는 최신 윈도우 업데이트로 해결되었다. 문제의 원인은 퀄컴 관련 드라이버와 ACPI의 상호작용 결함으로, 이를 파악하기 위해 많은 시간과 노력을 들였으나 결국 업데이트 하나로 해결된 경험을 통해 시스템의 작동 원리에 대한 깊은 이해를 얻게 되었다.

이거 똥꼬쇼 다 의미 없었다~ 윈도우 최신 업데이트 하니까 다 해결~!

https://chatgpt.com/share/67bd33e4-7b8c-800d-b420-b8c5f4666c43

https://grok.com/share/bGVnYWN5_4d54b36e-ccf2-4185-947f-e009d3c24123

https://chatgpt.com/share/67c9250a-8f7c-800d-8ef5-901bdc689695

덮개를 닫으면 죽는 노트북, 그 기나긴 삽질의 끝에서

돌이켜보면 허무한 결론이었다. 내가 겪었던 문제, 그리고 그 문제를 해결하기 위해 쏟아부었던 수많은 시간과 노력은 결국 최신 윈도우 업데이트 하나로 해결되었다. 하지만 그 과정에서 얻은 시스템에 대한 깊은 이해는 분명 의미 있는 자산으로 남았다. 이 글은 그 길고 길었던 여정에 대한 기록이다.

왜? - 문제는 단순했지만, 원인은 깊었다

문제는 단순했다. 노트북 덮개를 닫았다 열면, 시스템이 절전 모드에서 깨어나지 못하고 그대로 먹통이 되었다. 전원 버튼을 길게 눌러 강제 재부팅을 해야만 했다. 처음에는 전원 관리 옵션이나 빠른 시작 켜기 같은 간단한 설정을 건드려 보았지만, 문제는 해결되지 않았다. 단순한 소프트웨어 충돌이 아님을 직감하고, 문제의 근원을 파고들기 시작했다.

그렇게 들여다본 이벤트 뷰어는 복잡한 단서들로 가득했다. 가장 먼저 눈에 띈 것은 ‘Kernel-Power 이벤트 ID 41’이었다. 시스템이 정상적으로 종료되지 않았다는, 즉 블루스크린도 없이 갑작스럽게 전원이 차단되었음을 의미하는 로그였다. 무언가 운영체제가 제어할 수 없는 수준에서 문제가 발생하고 있었다.

어떻게? - 가설을 세우고, 검증하며 나아갔던 길

단서는 같은 시간대에 기록된 다른 경고 메시지들에 있었다. ACPI\\QCOM...으로 시작하는 장치들과 Windows Hello Face 드라이버가 \\Driver\\WUDFRd를 로드하지 못했다는 경고가 반복적으로 나타났다. 이는 내 노트북의 핵심 칩셋인 퀄컴(Qualcomm) 관련 하드웨어와 얼굴 인식을 위한 센서 드라이버들이 절전 모드에서 복귀하는 과정에서 제대로 깨어나지 못하고 있음을 시사했다. 여기서 첫 번째 가설이 세워졌다. ‘모던 스탠바이(Modern Standby)‘라는 저전력 대기 모드에서 특정 사용자 모드 드라이버(UMDF)가 깨어나지 못해 시스템 전체가 멈춰버리는 현상.

이 가설을 바탕으로 제조사(Lenovo) 홈페이지를 샅샅이 뒤져 최신 BIOS와 칩셋, ACPI 관련 드라이버를 모두 설치했다. 장치 관리자에 떠 있던 ‘알 수 없는 장치’들도 전용 드라이버를 찾아 모두 인식시켰다. 심지어 Windows Hello Face 기능을 아예 꺼보기도 했다. 하지만 증상은 간헐적으로 계속되었다. 무언가 더 근본적인 원인이 있는 것 같았다.

고민은 더 깊어졌다. 이벤트 로그를 다시 뜯어보던 중, 시스템 강제 종료 직전에 수많은 ‘ACPI 열 영역(Thermal Zone)’ 관련 로그가 기록된 것을 발견했다. 이는 시스템의 온도 센서들이 상태를 보고하는 과정인데, 여기서 두 번째 가설에 도달했다. 만약 퀄컴 ACPI 관련 드라이버의 오작동으로 인해 순간적으로 시스템 온도가 임계치를 넘었다는 ‘거짓 신호’가 발생한다면? BIOS/UEFI는 하드웨어 보호를 위해 운영체제에게 제어권을 넘기지 않고 즉시 전원을 차단해버릴 수 있다. ‘이벤트 ID 41’에 블루스크린 코드가 없었던 이유가 바로 이것 때문일 수 있겠다는 생각에 무릎을 쳤다. 드라이버 로드 실패가 원인이 아니라, 그 실패가 초래한 ‘센서 오류’가 진짜 원인일 수 있었다.

그래서? - 허무한 결론, 그러나 값진 과정

이 두 번째 가설까지 세우고 나니, 내가 할 수 있는 노력은 거의 바닥이 난 상태였다. 드라이버는 최신이었고, 펌웨어도 마찬가지였다. 내가 통제할 수 없는 영역, 즉 드라이버와 펌웨어, 그리고 운영체제 사이의 미세한 상호작용 결함이라는 결론에 다다를 수밖에 없었다.

그리고 며칠 뒤, 모든 고민이 무색하게도 정기 윈도우 업데이트를 설치하자 거짓말처럼 문제가 사라졌다. 덮개를 닫았다 열어도 시스템은 언제 그랬냐는 듯 멀쩡하게 깨어났다. 나의 기나긴 분석과 삽질은 결국 마이크로소프트나 퀄컴이 배포한 패치 하나로 해결될 문제였던 것이다.

허탈했지만 한편으로는 후련했다. 이 과정을 통해 나는 내 노트북이 어떻게 잠들고 깨어나는지, 모던 스탠바이라는 개념이 무엇인지, ACPI와 UMDF가 시스템에서 어떤 역할을 하는지를 몸으로 배우게 되었다. 단순히 ‘해결되었다’는 결과보다, 문제의 본질을 이해하기 위해 파고들었던 그 시간들이 나에게는 더 값진 경험으로 남았다. 결국 모든 문제 해결의 과정은, 설령 그것이 삽질로 끝난다 할지라도, 그 자체로 배움의 기회임을 다시 한번 깨닫게 된 시간이었다.