WoL은 켜져 있었는데 노트북은 깨어나지 않았습니다 — 원격 전원의 시행착오

러너 네 대짜리 CI 함대를 만들고 나니 새 걱정이 생겼습니다. 노트북 두 대를 24시간 켜두는 게 아깝다는 생각이었습니다. 무료로 운영하겠다고 시작한 일인데 전기는 무료가 아니니까요.

그래서 평소엔 재워두고 CI가 필요할 때만 깨우기로 했습니다. 결과부터 적겠습니다. 재우는 데는 성공했고, 깨우는 데 실패했습니다. 그날 밤 저는 노트북 앞으로 걸어가 전원 버튼을 눌렀습니다.

먼저 계산부터 했어야 했습니다

전기 요금을 추정해봤습니다. 오래된 노트북이 유휴 상태로 도는 소비 전력은 10와트 안팎이고, 24시간 30일이면 7.2kWh입니다. 가정용 요금으로 환산하면 한 달에 천 원에서 이천 원 정도입니다. 부하가 걸려도 몇천 원을 넘지 않습니다.

이 숫자를 먼저 봤어야 했습니다. 애석하게도 저는 그러지 않았고, 계산은 실패한 뒤에 했습니다. 월 이천 원을 아끼려고 저는 원격 관리 중인 서버를 일부러 재우는 일을 하고 있었습니다.

안전 순서를 설계했다고 믿었습니다

깨우는 방법은 크게 둘입니다. 하나는 RTC 알람으로, 메인보드의 시계에 알람을 걸어두고 시간이 되면 스스로 일어나게 하는 것입니다. 다른 하나가 Wake-on-LAN으로, 잠든 기기의 랜카드가 특정 패킷을 받으면 본체를 깨우는 방식입니다.

저는 RTC 알람을 먼저 검증하기로 했습니다. 자기 힘으로 깨어나는 쪽이 네트워크에 의존하지 않으니 더 안전하다고 봤습니다. 5분 알람을 걸고 재운 다음, 5분 뒤에 돌아오는지만 보면 되는 간단한 실험이었습니다.

사전 확인도 했습니다. 이 기기가 깊은 절전을 지원하는지 봤고, 랜카드가 매직패킷 수신 모드로 설정돼 있는지도 확인했습니다. 둘 다 통과였습니다. 지금 와서 보면 이 확인들이 저에게 준 것은 안전이 아니라 근거 없는 자신감이었습니다.

5분이 지나고, 380초가 지나고, 10분이 더 지났습니다

알람을 걸고 절전 명령을 내렸습니다. 로그상으로 깊은 절전 진입까지는 확인됐습니다. 그리고 5분을 기다렸습니다.

예정 기상 시각 경과 → 응답 없음
+380초 → 응답 없음
+10분 추가 폴링 → 응답 없음

RTC 알람이 발동하지 않았습니다. 이제 남은 것은 WoL이었습니다. 원래는 검증 후에 쓰려던 카드를 비상용으로 꺼내 든 셈입니다.

매직패킷을 보낼 수 있는 방법은 전부 시도했습니다. 전체 브로드캐스트로도, 해당 서브넷 브로드캐스트로도, 직접 지정해서도 보냈고, WoL에 흔히 쓰이는 포트 세 가지를 모두 돌렸습니다. 응답이 없었습니다. ARP 테이블을 확인해보니 해당 기기의 MAC 주소를 아예 못 찾고 있었습니다. 네트워크 상에서 그 기기는 존재하지 않는 상태였습니다.

9분 반을 더 기다렸습니다. 밤 열한 시가 다 되어서, 저는 결국 자리에서 일어나 노트북의 전원 버튼을 눌렀습니다. 콜드 부팅으로 살아났고 가상 머신도 러너도 시계도 전부 정상이었습니다. 데이터 손실은 없었습니다.

다만 하나를 잃었습니다. 절전 중에 무슨 일이 있었는지 기록이 재부팅으로 날아갔습니다. 실패 원인을 사후에 확인할 방법이 사라진 것입니다. 재현하려면 다시 재워야 하는데, 다시 재우면 또 못 깨울 수 있습니다.

나중에 BIOS를 직접 열어봤습니다

며칠 뒤 두 노트북의 BIOS를 실제로 열어 확인했습니다. 여기서 나온 두 가지가 이 편의 핵심입니다.

윈도우 노트북에는 전원 관련 탭이 아예 없었습니다. 메뉴가 다섯 개뿐이었고 그중 전원 항목은 없었으며, 하위 메뉴를 전수로 뒤져도 Wake-on-LAN이나 전원 복귀 관련 설정이 하나도 없었습니다. 저는 "설정이 꺼져 있어서 안 됐나 보다"라고 생각하고 있었는데, 실제로는 켜고 끌 항목 자체가 존재하지 않았습니다. 이 기기는 원격으로 전원을 켤 방법이 구조적으로 없습니다. 손으로 누르는 것만 가능합니다.

씽크패드는 정반대였습니다. Wake-on-LAN 항목을 찾아보니 이미 켜져 있었습니다. 제가 손댄 적 없는 기본값이었습니다. 제가 실패 원인으로 의심하던 바로 그 설정이, 실패하던 순간에 멀쩡히 활성 상태였던 것입니다.

그리고 전원 메뉴에서 뜻밖의 항목을 발견했습니다. 전원 어댑터가 연결되면 자동으로 켜지는 옵션이었습니다. 스마트플러그로 전원을 끊었다 다시 넣기만 하면, 네트워크도 커널도 드라이버도 거치지 않고 확실하게 부팅되는 경로입니다. 제가 밤새 매직패킷을 쏘고 있던 동안, 훨씬 단순하고 확실한 길이 같은 BIOS 안에 처음부터 있었습니다.

두 경로가 동시에 죽었다는 사실

BIOS 확인 결과를 실패 당시 조건과 나란히 놓아보니 그림이 달라졌습니다.

조건	실패 당시 상태
BIOS의 WoL 설정	활성 (기본값)
운영체제의 랜카드 설정	매직패킷 수신 활성
전원 연결	연결됨
매직패킷 발사	같은 네트워크에서 다중 경로로 발사

조건은 전부 충족돼 있었습니다. 그런데도 안 깨어났고, 동시에 RTC 알람도 실패했습니다. 이 두 가지는 서로 완전히 독립된 경로입니다. 하나는 메인보드의 타이머고 다른 하나는 네트워크 카드입니다. 공통점이라고는 둘 다 잠든 상태에서 깨어나는 과정을 통과해야 한다는 것뿐입니다.

그렇다면 문제는 깨우는 쪽에 있는 게 아닙니다. 재우고 되살아나는 경로 자체가 이 기기에서 제대로 동작하지 않는다고 보는 편이 자연스럽습니다. 생각해보면 이 노트북에는 서버용으로 튜닝된 운영체제가 올라가 있습니다. 서버는 원래 잠들지 않습니다. 노트북의 절전 경로는 이 조합에서 거의 검증된 적 없는 코드였을 것입니다.

윈도우에서도 같은 착시가 있었습니다

씽크패드에 매달리느라 뒤늦게 정리한 것이 있습니다. 윈도우 노트북 쪽 사전 조사 기록입니다.

이 기기의 무선 어댑터는 매직패킷 수신도 패턴 수신도 전부 켜져 있었습니다. 설정만 보면 나무랄 데가 없었습니다. 그런데 윈도우에는 지금 이 시스템을 깨울 수 있도록 실제로 무장된 장치가 무엇인지 따로 물어보는 명령이 있습니다.

powercfg /devicequery wake_armed
→ (빈 목록)

하나도 없었습니다. 어댑터 속성에는 깨우기가 켜져 있는데, 시스템이 깨우기 위해 무장해둔 장치는 0개였던 것입니다. 이 편에서 계속 이야기한 설정과 동작의 간극이 여기서는 명령 한 줄로 눈에 보이게 갈라져 있었습니다. 씽크패드에서는 재워보고 나서야 알았던 것을, 윈도우에서는 재우기 전에 물어볼 수 있었던 셈입니다.

층은 더 있었습니다. 이 노트북은 예전 방식의 깊은 절전을 지원하지 않고 최신 대기 모드만 씁니다. 절전 중에도 네트워크를 살려두는 방식이라 깨우는 규칙 자체가 다릅니다. 게다가 전원이 연결된 상태에서는 아예 잠들지 않도록 설정돼 있었고, 연결도 유선이 아니라 무선이었습니다. 무선에서의 매직패킷은 유선보다 훨씬 까다롭고 공유기 쪽 지원까지 필요합니다.

깨우기가 성립하려면 이 층이 전부 맞아떨어져야 합니다. 어댑터 설정, 시스템 무장 목록, 절전 모드의 종류, 연결 방식, 그리고 펌웨어. 어느 한 층만 어긋나도 결과는 똑같이 "안 깨어남" 하나이고, 그 결과만 봐서는 어느 층이 범인인지 알 수 없습니다.

결국 윈도우 쪽은 실제로 재워보는 단계까지 가지 못했습니다. 앞서 적었듯 나중에 BIOS를 열어보니 전원 탭 자체가 없었으니, 이 기기는 처음부터 원격으로 깨울 수 있는 물건이 아니었습니다.

남은 세 가지 교훈

첫째, 설정이 켜져 있다는 것과 실제로 동작한다는 것은 다른 사실입니다. 저는 확인 항목을 하나씩 통과시키며 준비가 됐다고 믿었지만, 그 확인들은 전부 "설정값이 무엇인가"였지 "실제로 깨어나는가"가 아니었습니다. 설정은 의도의 기록일 뿐이고, 동작은 실행해봐야 압니다.

둘째, 확인하는 행위 자체가 위험을 만드는 경우가 있습니다. 깨어나는지 알려면 재워야 하는데, 재우는 순간 못 깨울 위험에 이미 노출됩니다. 저는 안전 순서를 설계했다고 생각했지만, 사실 첫 시도부터 고립 위험 한가운데였습니다. 이런 종류의 검증은 원격만으로는 안전하게 만들 수 없고, 사람이 손 닿는 거리에 있을 때 해야 합니다.

셋째, 비용의 비대칭을 먼저 봤어야 했습니다. 기대 이익은 월 이천 원이었고, 실패 대가는 밤중의 물리적 개입과 CI 함대에서 한 대가 통째로 빠지는 것이었습니다. 이 정도로 기울어진 거래는 성공 확률이 아무리 높아도 하지 않는 게 맞습니다.

대신 위험 없는 절전만 남겼습니다

결국 절전은 접었습니다. 대신 고립 위험이 0인 것들만 적용했습니다. CPU를 절전 모드로 동작하게 바꾸고, 상시 전원 연결 상태에서 배터리가 계속 100%로 유지되며 마모되지 않도록 충전 상한을 낮췄고, 윈도우 쪽은 화면과 디스크만 시간이 지나면 꺼지게 했습니다. 본체는 계속 깨어 있습니다.

배선을 정리하다 알게 된 사실도 하나 적어둡니다. 이 서버는 유선 랜 위에 가상 머신용 네트워크 다리를 올려 쓰고 있는데, 무선은 그 다리의 구성원이 될 수 없습니다. 무선 규격 자체의 제약입니다. 그러니 랜선을 뽑으면 호스트와 가상 머신이 동시에 네트워크에서 사라지고, 네트워크가 끊긴 기계에 원격으로 접속해 네트워크를 고칠 방법은 없습니다. 이것도 같은 교훈의 다른 얼굴이라는 생각이 들었습니다.

다음 편에서는 다시 성능으로 돌아갑니다. 러너 네 대의 속도를 실제로 재봤더니 윈도우 노트북이 압도적으로 느렸고, 저는 그 범인을 자신 있게 지목했다가 틀립니다.