2026-07-02

충전기는 꽂혀 있었는데 밤새 노트북이 꺼진 이유를 Claude Code로 추적한 기록

어젯밤 ThinkPad X1에 작업을 걸어두고 잤다. 충전기도 꽂아뒀다. 아침에 보니 노트북이 꺼져 있었다.

아래는 그 원인을 Claude Code에게 추적시킨 실제 작업 세션을 거의 그대로 옮긴 것이다. 내가 입력한 말은 파란 박스, Claude의 답과 실행한 명령·출력은 그 아래에 이어진다. 반복되는 로그만 일부 줄였고 명령과 출력은 실제 세션의 것이다.

01"왜 꺼져 있던 거야?"

부팅 기록에서 정상 종료 흔적 찾기

SEAPY

너 어제 내가 일 시켜놓고 컴퓨터 안끄고 갔는데 왜 컴퓨터 갑자기 꺼져 있던거야? 로그 뒤져서 찾아봐

어제 밤 갑자기 꺼진 원인을 찾기 위해 시스템 로그(journalctl, 부팅 기록)를 뒤져보겠습니다.

Bash(journalctl --list-boots | tail -5)
-4 535b93ed…  Thu 2026-06-18 17:02:59 KST — Sat 2026-06-20 16:54:06 KST
-3 dc502841…  Sun 2026-06-21 09:45:57 KST — Sun 2026-06-21 14:47:44 KST
-2 8379d0ad…  Mon 2026-06-22 01:48:31 KST — Tue 2026-06-30 11:55:21 KST
-1 209d84be…  Tue 2026-06-30 11:56:54 KST — Thu 2026-07-02 01:30:27 KST
 0 4f0b26d4…  Thu 2026-07-02 10:47:09 KST — Thu 2026-07-02 10:50:17 KST
Bash(last -x shutdown reboot | head)
reboot   system boot  7.0.9-arch2-1    Thu Jul  2 10:47   still running
reboot   system boot  7.0.9-arch2-1    Tue Jun 30 11:56   still running
shutdown system down  7.0.9-arch2-1    Tue Jun 30 11:55 - 11:56  (00:01)
reboot   system boot  7.0.9-arch2-1    Mon Jun 22 01:48 - 11:55 (8+10:06)
… (이하 생략)

부팅 기록상 이전 세션이 7월 2일 새벽 01:30:27에 끝났고, last -x에 정상 shutdown 기록 없이 "still running"으로 남아있습니다. 이건 정상 종료가 아니라 갑자기 죽었다는 신호입니다. 이전 부팅 로그의 마지막 부분을 확인하겠습니다.

Bash(journalctl -b -1 -n 100 --no-pager | tail -60)
… (1Password keepalive, snapper 스냅샷 등 평범한 로그 반복) …
Jul 02 01:00:03 x1 limine-snapper-sync[198970]: Updated: /boot/limine.conf
Jul 02 01:18:24 x1 1password[1519]: INFO … Server session extension succeeded …
Jul 02 01:28:25 x1 1password[1519]: INFO … Server session extension succeeded …
Jul 02 01:29:26 x1 1password[1519]: INFO … Server session extension succeeded …
Jul 02 01:30:27 x1 1password[1519]: INFO … Server session extension succeeded …
(여기서 저널 끝. 종료 절차 로그 전혀 없음)

로그가 새벽 01:30:27에 1Password 정기 keepalive 같은 평범한 메시지를 끝으로 뚝 끊겼습니다. systemd 종료 절차("Stopping...", "Reached target Shutdown")가 전혀 없어서, 정상 종료·전원버튼 종료·배터리 부족에 의한 graceful 종료가 아닙니다. 하드 전원 차단(커널 패닉, 펌웨어 강제 종료, 배터리 완전 방전 등)에 해당합니다. 원인을 더 좁혀보겠습니다.

02용의자 소거

열 폭주? 커널 패닉? 배터리 경고? — 전부 아님

Bash(journalctl -b -1 | grep -iE 'battery|thermal|critical|overheat|upower' | tail)
Jun 30 11:56:54 x1 kernel: ACPI: thermal: Thermal Zone [THM0] (46 C)
Jun 30 11:56:54 x1 kernel: ACPI: battery: Slot [BAT0] (battery present)
Jul 01 16:31:01 x1 upowerd[1080]: failed to convert brightness: 3
(배터리 부족 경고·열 이벤트 없음 — 부팅 시 초기화 로그뿐)
Bash(ls -la /sys/fs/pstore/ /var/lib/systemd/pstore/)
total 0
(비어 있음 — 커널 패닉 덤프 없음)

배터리 부족 경고나 열(thermal) 이벤트, 커널 패닉 덤프(pstore) 모두 없습니다. 한 가지 흥미로운 점: 01:30에 꺼진 뒤 아침 10:47까지 꺼진 채로 있었다는 것. UPower가 남기는 배터리 이력 파일은 재부팅 후에도 남아있으니, 그 시각에 배터리가 실제로 방전됐는지 확인해보겠습니다.

03결정적 단서: upower 배터리 이력

"충전기 연결됨" 상태로 31% → 1%

Bash(tail -30 /var/lib/upower/history-charge-5B11M90161-58-1493.dat)
1782917714  31.000  pending-charge
1782917924  30.000  pending-charge
1782918134  29.000  pending-charge
… (약 3분에 1%씩 일정하게 하락) …
1782922824  3.000   pending-charge
1782923004  2.000   pending-charge
1782923215  1.000   pending-charge

결정적 단서가 나왔습니다. 배터리 이력에서 충전기가 꽂힌 것으로 인식된 상태(pending-charge)인데 배터리가 31% → 1%까지 계속 떨어진 기록이 있습니다. 타임스탬프를 시각으로 변환해서 꺼진 시각과 맞는지 확인하겠습니다.

Bash(date -d @1782917714; date -d @1782923215; grep -v pending history-charge… | tail)
2026-07-01 23:55:14 KST   ← 31% 시점
2026-07-02 01:26:55 KST   ← 1% 시점 (저널 끊김 01:30:27 직전!)
---
1782884764  100.000  charging        ← 07-01 14:46 만충
1782902596   99.000  fully-charged   ← 07-01 19:43부터 하락 시작
1782903106   97.000  fully-charged
… (fully-charged 상태인데 계속 하락) …
1782904757   90.000  fully-charged
Bash(awk '$1 >= 1782902596' history-charge… | awk '{print $3}' | sort | uniq -c)
    10 fully-charged
    88 pending-charge
     0 discharging   ← 방전으로 인식된 샘플이 단 하나도 없음

상태 카운트가 결정적입니다. 19:43 이후 배터리가 99%→1%로 떨어지는 동안 단 한 번도 "discharging"으로 기록되지 않았습니다. 시스템은 끝까지 "충전기 연결됨"으로 인식하고 있었습니다. 그래서 배터리 부족 경고도, 비상 hibernate도 발동하지 않은 겁니다.

04타임라인 재구성

hibernate 복귀가 방아쇠였다

Bash(journalctl -b -1 | grep -iE 'hibernat|hypridle|sudo' …)
Jul 01 17:15:39 x1 systemd-logind[1028]: The system will hibernate now!
Jul 01 19:43:16 x1 systemd-sleep[101084]: System returned from sleep operation 'hibernate'.
Jul 01 20:31:03 x1 sudo[158559]: seapy : PWD=/home/seapy/llm-wiki ; COMMAND=…   ← 작업 시작
Jul 01 20:32:07 x1 systemd[1147]: app-Hyprland-hypridle-…scope: Consumed … 44min…  ← idle 데몬 종료(잠들지 말라고 꺼둠)
Bash(journalctl -b -1 | grep -iE 'ac_adapter|ACPI.*AC' …)
(부팅 초기화 로그 외 아무것도 없음 — AC 어댑터 분리/연결 이벤트가 밤새 단 한 건도 기록되지 않음)

로그로 재구성한 어제 타임라인:

  • 07-01 14:46배터리 100% 만충 (정상 충전 중)
  • 07-01 17:15자리 비운 사이 시스템 hibernate 진입
  • 07-01 19:43hibernate 복귀 — 이 시점부터 충전이 실제로는 안 되기 시작 (배터리 99%)
  • 07-01 20:31작업 시작, 직후 idle 데몬(hypridle) 종료 — 밤새 깨어있도록
  • 19:43 → 01:26배터리 99% → 1%, 약 5시간 45분에 걸쳐 방전 — 내내 "충전기 연결됨"으로 인식
  • 07-02 01:30배터리 0% — EC(임베디드 컨트롤러)가 하드 전원 차단

배터리 타임라인 — 2026-07-01 14:00 → 07-02 01:30

전 구간에서 시스템 인식 상태는 "AC 연결됨"(fully-charged/pending-charge) — discharging 샘플 0개 · 출처: /var/lib/upower/history-charge-*.dat

데이터 표로 보기 (주요 샘플)
시각배터리upower 상태
07-01 14:46100%charging → 만충
07-01 17:15~100%hibernate 진입 (전원 꺼짐)
07-01 19:4399%fully-charged (복귀 직후)
07-01 20:1990%fully-charged
07-01 20:3087%pending-charge
07-01 23:5531%pending-charge
07-02 01:261%pending-charge
07-02 01:300%강제 전원 차단 (저널 끊김)
20:30–23:55 구간은 앞뒤 실측 샘플 사이 선형 보간. 나머지는 upower 실측값.

1차 결론

정상 종료가 아니라 배터리 완전 방전에 의한 하드 전원 차단. 그런데 시스템은 방전되는 내내 "충전기 연결됨"이라고 믿고 있었기 때문에 어떤 저전력 보호도 발동하지 않았다.

05"무슨 소리야, 충전선 연결했었는데"

반박 → 물리적 증거로 재확인

SEAPY

무슨소리야 배터리가 왜 방전해. 충전선 연결했었는데.

충전선이 연결돼 있었다는 말씀, 로그와 정확히 일치합니다 — 그래서 더 문제였던 겁니다. 시스템도 밤새 "충전기 연결됨"으로 인식했는데, 실제 전력은 배터리에서 빠져나가고 있었습니다. 전압 이력과 배터리 용량으로 물리적 방전이었는지 확인하겠습니다.

Bash(awk … history-voltage…; cat /sys/class/power_supply/BAT0/energy_full)
== 전압 이력 (방전 구간) ==
1782902596  13.244  fully-charged    ← 19:43
1782923215  10.768  pending-charge   ← 01:26
== 배터리 용량 ==
58910000   (58.9Wh — 5시간 45분에 걸쳐 약 10W씩 실제 소모)

전압이 13.24V → 10.77V로 실제로 떨어졌습니다. 소프트웨어 기록 오류가 아니라 물리적 방전입니다. 그리고 USB-C 전원 컨트롤러 쪽 로그에서 이상한 점이 하나 더 나왔습니다.

Bash(각 부팅에서 'ucsi PPM init failed' 발생 여부 카운트)
kernel: ucsi_acpi USBC000:00: error -ENODEV: PPM init failed
---
boot -5: 1   boot -4: 1   boot -3: 1   boot -2: 1   boot -1: 1   boot 0: 0
(사건 당일 포함 직전 5개 부팅에서 USB-C PD 관리 인터페이스 초기화 실패)
Bash(awk '$1 >= 1782950000' history-charge… — 아침 부팅 직후 첫 배터리 기록)
1782956840  100.000  fully-charged   ← 07-02 10:47 부팅하자마자 이미 만충!

맞습니다, 충전선은 꽂혀 있었고 전기도 살아 있었습니다. 그런데 노트북이 그 전기를 안 받아왔습니다:

  • 충전기가 정상이었다는 증거 — 새벽 1:30에 꺼진 뒤 아침 10:47에 켜는 사이, 노트북이 꺼진 상태에서 바로 그 선으로 배터리가 0% → 100% 만충돼 있었습니다. 선이 빠졌거나 멀티탭이 꺼져 있었다면 불가능한 일입니다.
  • 그런데 켜져 있는 동안엔 방전됐다는 증거 — 전압 실측 하락 + 시간당 약 10W 소모.

최종 결론

hibernate에서 깨어난 직후(19:43)부터, 노트북의 전원 컨트롤러(EC)가 "충전기 꽂혀 있음"은 인식하면서도 USB-C 전력 협상(PD)을 다시 맺지 못해 전력을 한 방울도 안 끌어오는 상태에 빠졌다. 시스템도 사용자도 "충전 중"이라 믿는 상태라 배터리 부족 경고가 하나도 안 떴고, 0%가 되자 하드웨어가 전원을 끊었다. 죽으면서 EC가 리셋됐고, 그래서 밤새 정상적으로 충전이 재개됐다.

권장 조치 두 가지:

  • 펌웨어 업데이트 — 이런 EC/PD stuck은 Lenovo가 BIOS 업데이트로 고치는 단골 문제입니다. fwupdmgr refresh && fwupdmgr get-updates로 확인해보시길 권합니다.
  • 밤샘 작업 걸기 전 확인 습관 — 특히 hibernate/suspend를 거친 날엔 cat /sys/class/power_supply/BAT0/statusCharging/Full인지 확인하거나, 그냥 충전선을 한 번 뽑았다 다시 꽂으면 PD 재협상이 일어나 안전합니다.

06조치: 펌웨어 업데이트

Claude의 제안을 받아 fwupdmgr 확인 — 문제의 당사자인 PD·EC 펌웨어가 포함된 업데이트 발견

SEAPY

fwupdmgr 업데이트 확인해줘

Bash(fwupdmgr refresh && fwupdmgr get-updates)
LENOVO 21V7000VKR
├─System Firmware:
│ │   Current version:    0.1.16
│ │   Problems:           • Device requires AC power to be connected
│ └─ThinkPad X1 Carbon 14th / X1 2-in-1 11th System Update:
│       New version:      0.1.18       Urgency: High
│       Lenovo System Firmware Version 1.18
│       (UEFI BIOS:1.12, ECP:1.08, MEFW:21.00.06.1503,
│        PD Firmware:1.13, Thunderbolt Retimer:8.28.02.02)
└─UEFI dbx:
  └─Secure Boot dbx Configuration Update:
        New version:      20260402      (CVE-2026-8863)

어제 문제와 직결되는 업데이트가 있습니다. 이 번들에 PD Firmware 1.13(어제 문제를 일으킨 USB-C 전력 협상 펌웨어)과 EC 1.08("충전기 꽂혀 있음"이라고 오인식했던 임베디드 컨트롤러 펌웨어)이 포함돼 있습니다. 단, AC 전원 연결이 필수인데 지금 충전선이 빠져 있습니다. 꽂아주시면 진행하겠습니다.

SEAPY

충전선 꽂았어, 업데이트 진행해

Bash(cat /sys/class/power_supply/AC*/online BAT0/status; bootctl status | grep -i secure)
1
Charging  93
Secure Boot: disabled   (dbx 업데이트 위험 요소 없음)
Bash(fwupdmgr update -y --no-reboot-check)
Successfully installed firmware   ← UEFI dbx (즉시 적용)
Successfully installed firmware   ← System Firmware 0.1.18 (스테이징)
Do not turn off your computer or remove the AC adapter while the update is in progress.
---
System Firmware:  Update State: Needs reboot

재부팅만 하시면 됩니다. 플래싱 중 전원이 끊기면 안 되니 충전선을 절대 뽑지 마시고, 재부팅하면 Lenovo 펌웨어 업데이트 화면에서 몇 분간 진행되며 중간에 자동으로 몇 번 더 재부팅될 수 있습니다.

SEAPY

재부팅했어

Bash(fwupdmgr get-devices | grep -A6 'System Firmware'; 재확인)
System Firmware:
    Current version:    0.1.18
    Update State:       Success
---
AC: 1   BAT0: Charging 100%
단, ucsi_acpi 'PPM init failed'는 이번 부팅에서도 간헐 재발
(충전은 막지 않는 커널 드라이버↔플랫폼 궁합 문제 — 별개 사안으로 기록)

펌웨어 업데이트가 성공적으로 적용됐습니다. 어제 문제의 당사자였던 PD 펌웨어 1.13과 EC 1.08이 새로 올라갔습니다. 진짜 검증은 다음번 hibernate → 복귀 때 배터리가 정상 충전되는지입니다.

07기록 남기기

같은 함정에 다시 안 빠지도록

SEAPY

그래 위키에 이 디바이스에 대해 위 조치한 내용 정리해

개인 위키의 장비 인벤토리 문서(ops/devices/computers/thinkpad-x1-gen14.md)의 "알려진 이슈"에 사건 경과·물증·조치·재발 시 대처법을 추가하고, 장비 overview와 이력도 갱신한 뒤 커밋했습니다.

Bash(git commit && git push)
[main 12783aa] x1 hibernate 복귀 후 충전 stuck→배터리 완전 방전 사건 기록 + 펌웨어 0.1.18 업데이트 반영
 2 files changed, 26 insertions(+)

08이 세션에서 얻은 것

이 페이지의 명령·출력은 2026-07-02 실제 Claude Code 세션의 것입니다 (반복 로그만 축약). 원인 분석, 펌웨어 업데이트, 위키 정리, 그리고 이 글의 작성까지 모두 같은 세션에서 이루어졌습니다.