절전에서 재개하면 깨지는 앱 ── 전원 이벤트의 구조와 재개에 강한 업무 앱을 만드는 방법

「노트북을 닫고 다음 날 아침 열었더니 업무 앱이 오류투성이였다」「장치 감시 앱이 점심시간 뒤에만 데이터를 놓친다」「Excel로 출력하는 상주 도구가 가끔 연결 오류로 멈춘다」── 이런 문의에는 공통된 용의자가 하나 있습니다. 절전입니다.

데스크톱 PC가 주류이던 시대의 업무 앱은 「PC는 켜 둔 채로 둔다」를 암묵의 전제로 작성되어 왔습니다. 그러나 현재의 주전장은 노트북이고, 기본값에서는 방치하면 몇 분 만에 절전에 들어갑니다. 게다가 Modern Standby(모던 대기) 대응 기기에서는 절전의 의미 자체도 종래와 달라져 있습니다. 이 글에서는 Windows에서 업무 앱·장치 제어 소프트웨어를 만드는 개발자를 대상으로, 절전 전후에 OS가 앱에 무엇을 알리는지, 무엇이 깨지는지, 재개에 강한 앱을 어떻게 작성하는지를 1차 정보를 바탕으로 정리합니다.

1. 먼저 결론

• 절전은 앱에 「거부권이 없는」 이벤트입니다. 직전에 WM_POWERBROADCAST(PBT_APMSUSPEND)로 알림이 오지만, 유예는 약 2초이고, 긴급 절전에서는 알림조차 오지 않습니다.¹²
• 절전에서 재개하면 PBT_APMRESUMEAUTOMATIC이 도착하고, 사용자 조작에 의한 재개에서는 추가로 PBT_APMRESUMESUSPEND가 도착합니다. 재연결 같은 필수 처리는 전자에 두는 것이 기본입니다. 다만 Modern Standby의 저전력 유휴 출입은 이 알림과 일치하지 않는 경우가 있으므로, 알림은 보조로 봅니다.³⁴
• TCP 연결·시리얼 포트·장치 핸들은 재개를 건너 살아남지 않는다는 전제로 설계합니다. 재개 알림과 통신 오류를 계기로 다시 맺는 재연결 로직이 본체입니다.
• 타이머와 시각 처리를 주의합니다. 절전 중에는 주기 처리가 멈추고, 재개 직후 어떻게 발화하는지는 타이머 API와 실행 환경마다 다릅니다. 「경과 시간의 큰 점프」도 일어나므로, 재개 때 일정을 다시 짜는 것이 안전합니다.
• 절전시키고 싶지 않은 구간은 명시적으로 억제합니다. SetThreadExecutionState(ES_SYSTEM_REQUIRED)나 전원 요청(PowerSetRequest)을 쓰고, 처리가 끝나면 반드시 해제합니다.⁴⁵
• Modern Standby 기기에서는 절전 중에도 시스템이 간헐적으로 동작하지만, 데스크톱 앱은 일시 정지됩니다. 「우리 앱은 절전 중에도 동작해야 한다」는 기대는 가질 수 없습니다.⁶
• 조사는 powercfg(/requests, /lastwake, /sleepstudy)와 이벤트 로그의 Kernel-Power가 정석입니다.

2. 절전 전후에 무엇이 일어나는가 ── 전원 이벤트의 흐름

OS는 전원 상태의 변화를 모든 앱에 WM_POWERBROADCAST 메시지로 브로드캐스트합니다.² 절전과 재개에 관련된 주요 이벤트는 세 가지입니다.

PBT_APMSUSPEND는 절전 직전의 알림이며, 여기서 파일을 닫고 상태를 저장하는 준비를 할 수 있습니다. 다만 조건이 둘 있습니다. 첫째, 처리에 허용되는 시간은 앱마다 약 2초이며, 넘기면 시스템은 기다리지 않고 진행합니다.¹ 둘째, 배터리 잔량이 위기적인 경우 같은 긴급 절전에서는 이 사전 알림 없이 바로 절전합니다.² 「절전 전에 반드시 끝낸다」는 설계는 성립하지 않습니다. 알림은 「가능한 범위에서 하는」 기회로 보고, 본체는 재개 쪽에 둡니다.

재개 쪽은 두 단계입니다. PBT_APMRESUMEAUTOMATIC은 절전 전이에서 재개할 때 도착합니다. 그 위에서, 전원 버튼이나 키 입력처럼 사용자 조작으로 재개한(또는 그 뒤에 사용자가 있는 것이 감지된) 경우에는 이어서 PBT_APMRESUMESUSPEND가 도착합니다. 반대로 네트워크를 통한 원격 깨우기나 유지보수를 위한 무인 재개에서는 PBT_APMRESUMEAUTOMATIC만 도착합니다.³ 이 두 단계가 바로 역할 나눔의 힌트입니다 ── 연결을 다시 맺는 일처럼 기계적인 복구는 PBT_APMRESUMEAUTOMATIC에서, 화면 갱신이나 다시 로그인 요구처럼 사용자 대상 동작은 PBT_APMRESUMESUSPEND에서 수행합니다.

sequenceDiagram
    accTitle: 절전과 재개의 알림 흐름
    accDescr: 절전 직전에 PBT_APMSUSPEND가 약 2초의 유예와 함께 도착하고, 재개 때는 PBT_APMRESUMEAUTOMATIC이 반드시 도착하며, 사용자 조작에 의한 재개인 경우에만 이어서 PBT_APMRESUMESUSPEND가 도착한다
    participant OS as OS
    participant A as 앱
    OS->>A: PBT_APMSUSPEND（유예 약 2초）
    A->>A: 상태 저장·연결 닫기
    Note over OS: 절전（코드는 동작하지 않는다）
    OS->>A: PBT_APMRESUMEAUTOMATIC（재개 때 도착）
    A->>A: 재연결·상태 복구
    OS->>A: PBT_APMRESUMESUSPEND（사용자 재개 때만）
    A->>A: 화면 갱신 등 사용자 대상 처리

그림 1: 알림은 「직전에 한 마디, 재개 뒤에 한두 마디」뿐입니다. 복구의 주역은 재개 쪽 처리가 됩니다.

flowchart TB
    accTitle: 보통 절전과 긴급 절전의 차이
    accDescr: 보통 절전에서는 직전에 PBT_APMSUSPEND가 도착하고 약 2초의 준비 시간이 있지만, 위기적 배터리 등에 의한 긴급 절전에서는 사전 알림 없이 멈추므로, 사전 알림에 의존한 설계는 성립하지 않는다
    n2["보통 절전"] --> pre["PBT_APMSUSPEND（약 2초의 유예）"]
    pre --> s1["준비한 뒤에 정지"]
    e2["긴급 절전（배터리가 거의 다 된 때）"] --> s2["사전 알림 없이 정지"]
    s2 -.-> l2["「알림이 온다는 전제」의 설계는 성립하지 않는다"]

그림 2: 긴급 절전은 예고가 없습니다. 그래서 준비는 「되면 이득」이고, 본체는 재개 쪽에 둡니다.

참고로 WM_POWERBROADCAST는 저전력 상태의 종류(절전인지 최대 절전인지)를 구분하지 않습니다.⁴ 앱에게는 「멈췄다가 돌아왔다」는 한 종류의 사건으로 다루는 것이 올바른 추상입니다. 창이 없는 서비스나 콘솔 앱에서는 RegisterSuspendResumeNotification을 콜백 방식(DEVICE_NOTIFY_CALLBACK)으로 써서 같은 알림을 받을 수 있습니다.⁷

flowchart TB
    accTitle: 재개 두 단계의 처리 역할 나눔
    accDescr: 재개 때 도착하는 PBT_APMRESUMEAUTOMATIC에는 재연결처럼 기계적인 복구를 두고, 사용자 조작 때만 도착하는 PBT_APMRESUMESUSPEND에는 화면 갱신이나 다시 로그인 요구처럼 사용자 대상 처리를 둔다
    ra["PBT_APMRESUMEAUTOMATIC（재개 때）"] --> m["기계적인 복구"]
    rs["PBT_APMRESUMESUSPEND（사용자 재개 때）"] --> u["사용자 대상 처리"]
    m -.-> m1["재연결·핸들 다시 열기"]
    u -.-> u1["화면 갱신·다시 로그인 요구"]

그림 3: 무인 재개에서는 후자가 오지 않으므로, 필수 복구를 후자에 두면 놓칩니다.

3. Modern Standby ── 「절전」의 의미가 바뀌었다

하나 더 잡아 두어야 할 오늘날의 사정이 Modern Standby입니다. 종래의 S3 절전이 「시스템 전체를 멈춘다」는 단순한 모델이었던 데 비해, Modern Standby 기기의 절전은 화면을 끈 뒤에도 시스템이 간헐적으로 계속 동작하는, 스마트폰에 가까운 모델입니다.

여기서 업무 앱에 중요한 점은, 데스크톱 앱은 절전 진입의 첫 단계에서 Desktop Activity Moderator(DAM)에 의해 일시 정지된다는 것입니다.⁶ 시스템 자체는 네트워크 유지와 알림 수신을 위해 가끔 동작하지만, 그 혜택을 받는 것은 이 구조에 대응한 구성 요소이고, 일반적인 데스크톱 앱의 코드는 실행되지 않습니다. 즉 개발자 관점에서는 Modern Standby든 S3든 결론은 같습니다 ── 절전 중에는 자신의 코드가 동작하지 않는다는 전제로 설계한다는 것입니다.

flowchart TB
    accTitle: 종래 절전과 Modern Standby의 차이
    accDescr: 종래의 S3 절전은 시스템 전체가 정지하지만, Modern Standby에서는 화면이 꺼진 뒤에도 시스템이 간헐적으로 동작한다. 다만 데스크톱 앱은 DAM에 의해 일시 정지되므로, 어느 쪽이든 앱의 코드는 동작하지 않는다
    s3["종래의 S3 절전：전체가 정지"] --> conc["앱의 코드는 동작하지 않는다"]
    ms["Modern Standby：시스템은 간헐 동작"] --> dam["데스크톱 앱은 DAM으로 일시 정지"]
    dam --> conc

그림 4: 모델은 바뀌어도, 데스크톱 앱에게 결론은 「절전 중에는 동작하지 못한다」로 같습니다.

또 하나의 주의는 알림을 얼마나 믿을 수 있느냐입니다. Modern Standby에서는 저전력 유휴의 출입이 종래의 절전 전이와 일치하지 않아, 알림이 오지 않은 채로 연결이 깨져 있는 일이 있을 수 있습니다. 재개 알림은 보조로 보고, 오류 감지에서의 재연결(5장)을 복구의 본선에 두십시오.

또 하나의 차이는 동작이 「흐릿한」 느낌입니다. 절전의 깊은 곳에 들어가기까지가 단계적이고, 끊김이나 정지의 시점이 S3만큼 뚜렷하지 않습니다. 「화면이 꺼진 것뿐」과 「절전했다」의 구분이 사용자에게도 잘 잡히지 않으므로, 증상을 들을 때는 「덮개를 닫았는지」「몇 분 방치했는지」를 확인할 필요가 있습니다.

4. 무엇이 깨지는가 ── 전형적인 증상

TCP 연결이 죽어 있다. 절전 중에 연결 상대·NAT·방화벽은 이쪽의 침묵을 타임아웃으로 처리하고 연결을 폐기합니다. 나쁜 점은, 이쪽 소켓은 오류를 모르는 채로라서 재개 후에 송수신하고 나서야 실패한다는 것입니다. 혹은 더 나쁘게, 수신 대기인 채로 언제까지나 오류가 나지 않는 경우도 있습니다(그래서 keepalive가 필요합니다). 데이터베이스 연결과 WebSocket도 같은 구도입니다.

시리얼 포트·USB 장치의 핸들이 무효가 된다. USB 연결 기기는 재개 때 한 번 「빠졌다가 다시 꽂힌」 것처럼 보이는 경우가 있어, 열어 둔 핸들은 오류를 반환하게 됩니다. 장치 제어 앱에서 「점심시간 뒤에만 통신 오류」가 되는 전형 패턴입니다. 재연결 설계는 시리얼 통신 기사에서도 다룹니다.

시간의 연속성이 깨진다. 「10초마다 폴링」 같은 타이머 구동 처리는 절전 중에는 발화하지 않습니다. 재개 직후에 어떻게 발화하는지(기한이 지난 분이 곧바로 한 번 발화하는지, 다음 주기까지 아무 일도 없는지 등)는 사용하는 타이머 API와 실행 환경에 따라 다르므로, 놓친 분의 처리를 암묵의 동작에 맡기지 말고, 재개 알림에서 일정을 다시 짜는 것이 안전합니다. 또한 경과 시간 기준 계산(이전 시각과의 차분)이 갑자기 「8시간분」이 되어, 평균값 계산이나 타임아웃 판정이 깨집니다. 「매일 밤 2시에 실행」 같은 정시 처리는, 그 시각에 PC가 잠들어 있으면 그냥 실행되지 않습니다(필요하면 작업 스케줄러의 절전 해제 기능으로 깨웁니다).

flowchart TB
    accTitle: 시간의 연속성이 깨지는 세 가지 형태
    accDescr: 주기 처리는 절전 중에 멈추고 재개 후 발화는 API마다 다르므로 재개 때 일정을 다시 짜고, 이전 시각과의 차분은 재개 후 거대한 값이 되므로 가드하며, 정시 처리는 잠들어 있으면 실행되지 않으므로 작업 스케줄러의 절전 해제를 검토한다
    t1["주기 처리：절전 중에는 멈춘다"] -.-> g1["재개 때 일정을 다시 짠다"]
    t2["경과 시간의 차분：거대화"] -.-> g2["이상한 차분을 가드한다"]
    t3["정시 처리：잠들어 있어 미실행"] -.-> g3["절전 해제 설정으로 깨운다"]

그림 5: 타이머와 시각 처리는 「시간이 점프한다」는 전제로 작성합니다. 세 형태 각각에 대처의 형이 있습니다.

flowchart TB
    accTitle: 절전을 건너며 깨지는 세 가지
    accDescr: 절전을 건너면, TCP 연결은 상대 측 타임아웃으로 폐기되고, USB 기기의 핸들은 재연결 취급으로 무효가 되며, 경과 시간 기준 처리는 거대한 시간 점프를 관측한다. 각각 재연결·다시 열기·차분 가드로 복구한다
    sleep["절전 구간"] --> tcp["TCP 연결：상대 측에서 폐기됨"]
    sleep --> usb["USB 기기：핸들이 무효화"]
    sleep --> time["경과 시간：거대한 점프"]
    tcp -.-> r1["오류 감지와 재연결"]
    usb -.-> r2["장치를 다시 연다"]
    time -.-> r3["이상한 차분을 가드"]

그림 6: 깨지는 것은 「연결」「핸들」「시간의 연속성」의 세 계통이며, 각각 복구의 형이 정해져 있습니다.

공유 리소스에 대한 재인증. 네트워크 드라이브나 VPN은 재개 후에 다시 확립해야 하는 경우가 있고, 재개 직후 수 초에서 수십 초는 접근이 실패하는 「기동 초기의 공백」이 있습니다. 재개 직후에 한꺼번에 재시도하지 말고, 조금 기다렸다가 단계적으로 재시도하는 것이 안전합니다.

5. 재개에 강한 앱을 만드는 방법

원칙은 하나입니다. 「연결이나 핸들은 절전을 건너 살아남지 않는다」는 전제로, 언제든 다시 세울 수 있는 구조로 만듭니다.

재개를 감지하고 다시 세운다. 최상위 창의 WM_POWERBROADCAST에서 PBT_APMRESUMEAUTOMATIC을 받으면, 가지고 있는 연결을 폐기하고 다시 맺습니다. 핵심은 재개 알림만 의지하지 않는 것입니다. 알림을 놓치는 일과 알림 전의 통신도 현실에 있으므로, 「통신 오류를 감지하면 재연결한다」는 경로를 반드시 함께 두고, 재개 알림은 그것을 앞당기는 트리거로 위치시킵니다.

// C#: 재개 알림과 통신 오류 양쪽에서 같은 재연결 처리로 합류시킨다
protected override void WndProc(ref Message m)
{
    const int WM_POWERBROADCAST = 0x0218;
    const int PBT_APMRESUMEAUTOMATIC = 0x0012;
    if (m.Msg == WM_POWERBROADCAST && (int)m.WParam == PBT_APMRESUMEAUTOMATIC)
    {
        _connectionManager.RequestReconnect();   // 멱등한 재연결 요청
    }
    base.WndProc(ref m);
}

재연결 처리 자체는 멱등(몇 번 호출해도 안전)하게 만들고, 실패 시에는 지수 백오프를 붙여 재시도하며, 정상 시에는 keepalive로 연결의 생사를 일찍 감지한다 ── 이 세 가지 세트로 두면, 절전 재개뿐 아니라 네트워크 순간 끊김이나 기기의 다시 시작에도 그대로 버팁니다.

flowchart TB
    accTitle: 재개에 강한 재연결 설계
    accDescr: 재개 알림과 통신 오류와 keepalive 실패의 어느 것이든 같은 멱등한 재연결 처리로 합류하고, 실패 시에는 지수 백오프로 재시도한다
    e1["재개 알림（PBT_APMRESUMEAUTOMATIC）"] --> r["멱등한 재연결 처리"]
    e2["통신 오류 감지"] --> r
    e3["keepalive 실패"] --> r
    r --> ok{"성공?"}
    ok -->|"예"| run["정상 운용으로"]
    ok -->|"아니오"| back["지수 백오프 후 재시도"]
    back --> r

그림 7: 재연결을 하나의 멱등한 처리로 모으고, 재개 알림·오류 감지·keepalive의 어디서든 같은 길로 들어갑니다.

시간의 처리를 다시 본다. 「이전부터의 경과 시간」을 쓰는 처리는, 비정상적으로 큰 차분을 감지하면 그 구간을 무효화하는(평균에 섞지 않는다, 타임아웃으로 다루지 않는다) 가드를 넣습니다. 재개를 건너는 경과 시간 계측에는, 절전 중에도 진행하는 시각(실시간)과 처리에 쓴 시간을 구분하는 의식이 필요합니다.

절전시키고 싶지 않은 구간은 명시적으로 억제합니다. 데이터 이전이나 장치와의 연속 통신처럼, 절전되면 곤란한 처리 동안은 SetThreadExecutionState(ES_CONTINUOUS | ES_SYSTEM_REQUIRED)로 시스템을 깨운 채로 둘 수 있습니다(화면도 유지하고 싶다면 ES_DISPLAY_REQUIRED를 추가합니다).⁴⁵ 더 바람직한 방법이, 이유 문자열을 붙일 수 있는 전원 요청 API(PowerCreateRequest + PowerSetRequest)이며, powercfg /requests에 「누가 왜 막고 있는지」가 표시됩니다.⁸ 참고로 SetThreadExecutionState의 억제는 스레드 단위이고, 해제는 설정과 같은 스레드에서 합니다. 스레드가 바뀌는 async/await 등의 처리에서는, 핸들로 관리하는 전원 요청 쪽을 쓰십시오. 주의점이 있습니다. 첫째, 이들이 억제하는 것은 무조작에 의한 자동 절전입니다. 사용자가 덮개를 닫거나 시작 메뉴에서 절전을 고르는 명시적 조작까지는 막지 못하므로, 억제 중이더라도 이 장의 재연결 설계는 빼놓을 수 없습니다. 둘째, Modern Standby 기기의 배터리 구동에서는, 이들 전원 요청도 절전 타임아웃이 지난 뒤 얼마 안 되어 끊깁니다. 중단할 수 없는 처리는 AC 전원이나 운용 쪽에서 보장하십시오.⁸ 셋째, 처리가 끝나면 반드시 해제한다는 점입니다. 해제 누락은 「이 PC가 왠지 절전하지 않게 됐다」는 새 장애가 됩니다.

flowchart TB
    accTitle: 절전 억제의 두 수단
    accDescr: 손쉽게 쓸 수 있는 SetThreadExecutionState와, 이유 문자열을 붙일 수 있어 관리자가 powercfg로 볼 수 있는 전원 요청 API의 어느 쪽을 쓰더라도, 처리 종료 때 반드시 해제한다
    need["절전되면 안 되는 처리 구간"] --> a["SetThreadExecutionState"]
    need --> b["전원 요청（PowerSetRequest）"]
    a -.-> a1["간편함·플래그 지정만"]
    b -.-> b1["이유 첨부·powercfg로 보인다"]
    a --> off["처리 종료 때 반드시 해제"]
    b --> off

그림 8: 어느 수단이든 「끝나면 해제」가 절대 조건입니다. 이유를 보이게 할 수 있는 전원 요청 쪽이 운용에는 친절합니다.

서비스·창 없는 앱은 RegisterSuspendResumeNotification(DEVICE_NOTIFY_CALLBACK)으로 콜백 알림을 받습니다.⁷ 상시 가동이 정말로 요건이라면, 애초에 절전하는 클라이언트 PC에 상주시키는 설계를 다시 보고, 서버 쪽이나 절전하지 않는 운용의 단말로 옮기는 것이 근본 해법입니다.

6. 조사 방법 ── powercfg와 이벤트 로그

전원 주변의 조사는 OS에 딸린 도구가 잘 갖춰져 있습니다.

• 절전하지 않는다: powercfg /requests로, 전원 요청을 내고 있는 프로세스·드라이버를 목록으로 볼 수 있습니다. 「앱이 SetThreadExecutionState를 해제하지 않았다」도 여기서 찾습니다.
• 스스로 깨어난다: powercfg /lastwake로 직전 재개 요인, powercfg /waketimers로 재개 예약 중인 타이머를 확인할 수 있습니다.
• Modern Standby의 품질: powercfg /sleepstudy로 절전 구간마다의 소비 전력과 활동 보고서가 생성됩니다.⁹
• 시계열 확인: 이벤트 로그(시스템)의 Kernel-Power 원본에 절전 진입·재개의 기록이 남습니다. 앱 로그와 맞춰 보면 「오류 직전에 재개가 있었는지」를 객관적으로 확인할 수 있습니다.

flowchart TB
    accTitle: 전원 문제의 증상과 조사 명령의 대응
    accDescr: 절전하지 않는 증상은 powercfg /requests로 전원 요청의 주체를 조사하고, 스스로 깨어나는 증상은 /lastwake와 /waketimers로 재개 요인을 조사하며, 시계열 확인은 이벤트 로그의 Kernel-Power로 한다
    s1["절전하지 않는다"] --> c1["powercfg /requests"]
    s2["스스로 깨어난다"] --> c2["powercfg /lastwake·/waketimers"]
    s3["시계열을 확인하고 싶다"] --> c3["이벤트 로그의 Kernel-Power"]
    c1 -.-> note["해제하지 않은 절전 억제도 드러난다"]

그림 9: 증상과 조사 명령의 대응은 세 계통입니다. 먼저 「직전에 절전했는지」를 확인한 뒤 나눕니다.

문의 대응에서는 먼저 「직전에 PC가 절전하고 있었습니까(덮개를 닫았습니까)」라고 묻는 것만으로, 원인 분리가 한순간에 빨라집니다.

7. 정리

• 절전은 거부할 수 없습니다. 사전 알림(PBT_APMSUSPEND)은 약 2초 유예의 best-effort이며, 긴급 시에는 오지 않습니다. 설계의 본체는 재개 쪽에 둡니다.
• 재개 알림은 PBT_APMRESUMEAUTOMATIC(절전 재개 때)+ PBT_APMRESUMESUSPEND(사용자 조작 때)입니다. 알림이 오지 않는 경우에 대비해 오류 감지의 재연결을 본선에 둡니다.
• 연결·핸들은 재개를 건너 살아남지 않는다는 전제로, 멱등한 재연결+지수 백오프+keepalive의 세 가지 세트를 구현합니다.
• 경과 시간 기준 처리에는 「이상한 차분」에 대한 가드를 넣습니다. 정시 처리는 절전 중에 실행되지 않는다는 전제로 설계합니다.
• 절전되면 곤란한 구간은 SetThreadExecutionState나 전원 요청으로 명시적으로 억제하고, 끝나면 반드시 해제합니다.
• 조사는 powercfg(/requests·/lastwake·/sleepstudy)와 Kernel-Power 이벤트 로그입니다. 문의 대응에서는 「직전에 절전했는지」를 먼저 묻습니다.

절전은 앱에서 보면 「예고 없이 시간이 점프하고, 주변과의 연결이 끊긴 채로 돌아온다」는 이벤트입니다. 이것을 이상 사태가 아니라 일상의 일부로 설계에 넣고 있는지가, 노트북 시대 업무 앱의 안정성을 가릅니다.

관련 기사

• 시리얼 통신 앱의 함정 - 재접속과 로그 설계까지
• 앱에서 본 Windows 종료 ── 종료 알림·다시 시작·전원 차단을 올바르게 견디기
• Windows 효율 모드란 - 녹색 잎 아이콘과 끄는 방법
• Windows에서 Sleep(1)보다 이벤트 대기를 우선해야 하는 이유
• 「응답 없음」의 정체 ── Windows가 앱을 「멈췄다」고 판단하는 구조와, 멈추지 않는 설계

관련 상담 영역

합동회사 코무라소프트에서는 「절전 재개 후에 통신이 깨진다」, 「점심시간 뒤에 장치와의 연결이 끊긴다」 같은 장애의 원인 조사, 기존 앱에 재연결 로직·전원 이벤트 대응을 나중에 넣는 구현, 노트북 운용을 전제로 한 업무 앱·장치 제어 소프트웨어의 설계 리뷰를 다루고 있습니다.

• 장애 조사·원인 분석
• Windows 앱 개발
• 기술 상담·설계 리뷰
• 문의하기

참고 링크

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

앱은 절전에 들어가는 것을 미리 알고 거부할 수 있나요?

현재 Windows에서는 알림은 받을 수 있지만 거부는 할 수 없습니다. 절전 직전에는 WM_POWERBROADCAST 메시지로 PBT_APMSUSPEND 이벤트가 도착하고, 여기서 파일을 닫고 상태를 저장하는 등의 준비를 할 수 있습니다. 다만 처리에 허용되는 시간은 앱마다 약 2초이며, 넘기면 시스템은 앱을 기다리지 않고 진행합니다. 또한 배터리가 거의 다 된 경우 같은 긴급 절전에서는 사전 알림 자체가 오지 않습니다. 따라서 「절전 전에 반드시 끝낸다」는 설계는 성립하지 않고, 「언제 잘려도 재개 때 다시 세울 수 있는」 설계가 필요합니다. 어떻게든 절전시키고 싶지 않은 처리 구간은 SetThreadExecutionState나 전원 요청(PowerSetRequest)으로 명시적으로 억제합니다.

재개한 것은 어떻게 감지하면 되나요?

창이 있는 앱이면 WM_POWERBROADCAST를 처리합니다. 절전에서 재개할 때는 PBT_APMRESUMEAUTOMATIC이 도착하고, 사용자 조작(전원 버튼이나 키 입력)에 의한 재개인 경우에는 그 뒤에 PBT_APMRESUMESUSPEND도 도착합니다. 무인으로 재개했다가 바로 다시 절전하는 경우에는 PBT_APMRESUMEAUTOMATIC만 오므로, 재연결 같은 필수 처리는 PBT_APMRESUMEAUTOMATIC 쪽에 두고, 화면 갱신처럼 사용자 대상 처리는 PBT_APMRESUMESUSPEND 쪽에 두는 구분이 기본입니다. 창이 없는 서비스나 콘솔 앱은 RegisterSuspendResumeNotification을 DEVICE_NOTIFY_CALLBACK 지정으로 쓰면 콜백으로 같은 알림을 받을 수 있습니다.

절전 중에도 앱을 계속 동작시킬 수 있나요?

원칙적으로는 할 수 없습니다. 절전 중에는 CPU 실행 자체가 멈추고(Modern Standby 기기에서는 데스크톱 앱이 Desktop Activity Moderator에 의해 일시 정지되며), 앱의 코드는 실행되지 않습니다. 선택은 두 가지입니다. 하나는 처리 중인 동안만 절전을 억제하는 것입니다. SetThreadExecutionState에 ES_SYSTEM_REQUIRED를 지정하거나 PowerCreateRequest/PowerSetRequest로 전원 요청을 내면, 무조작에 의한 자동 절전을 그 동안 억제할 수 있습니다(powercfg /requests로 확인할 수 있습니다). 다만 사용자가 덮개를 닫는 등의 명시적 절전 조작까지는 막지 못하므로, 억제 중에도 재개에 대한 대비는 필요합니다. 다른 하나는 절전을 받아들이고 「재개 후에 따라잡는」 설계로 가는 것입니다. 야간 배치처럼 정시 처리는 작업 스케줄러의 「작업을 실행할 때 절전 모드 해제」로 PC를 깨우는 방법도 있습니다. 상시 가동이 정말로 필요한 처리는 절전하지 않는 설정의 서버나 서비스로 옮기는 것이 정석입니다.

재개 후에 TCP 연결이나 시리얼 포트가 사용할 수 없게 되는 이유는 무엇인가요?

절전 중에는 네트워크 어댑터와 USB 장치도 저전력 상태로 내려가기 때문입니다. TCP 연결은 상대 측이나 NAT·방화벽의 타임아웃으로 이미 폐기되어 있고, 재개 후의 송수신은 오류가 됩니다(오류가 날 때까지 알아차리지 못하는 경우도 많습니다). USB 시리얼 변환기 등은 재개 때 장치 제거·재연결로 취급되는 경우가 있어, 열어 둔 핸들은 무효가 됩니다. 어느 쪽이든 「핸들이나 연결은 재개를 건너 살아남지 않는다」는 전제로, 재개 알림이나 통신 오류를 계기로 연결을 다시 맺는 재연결 로직을 구현하는 것이 정답입니다. 주기적 keepalive와 실패 시 지수 백오프를 붙인 재시도를 조합하는 것이 정석입니다.

스스로 절전되거나 스스로 재개되는 원인은 어떻게 조사하나요?

powercfg 명령이 첫 번째 도구입니다. 「절전하지 않는다」 쪽에서는 powercfg /requests로, 어떤 프로세스·드라이버가 전원 요청을 내어 절전을 막고 있는지를 목록으로 볼 수 있습니다. 「스스로 깨어난다」 쪽에서는 powercfg /lastwake로 직전 재개 요인을, powercfg /waketimers로 재개 예약 중인 타이머를 확인할 수 있습니다. Modern Standby 기기에서는 powercfg /sleepstudy로 절전 중의 소비와 활동 보고서가 나옵니다. 또한 절전·재개 이력은 이벤트 로그(시스템 로그의 Kernel-Power 원본)에 기록되므로, 「언제 절전했고, 언제 무슨 이유로 깨어났는지」를 시계열로 확인할 수 있습니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.