안드로이드 리눅스 커널 커스터마이징 (Wakelock 전력 통제 모듈)

핵심 인사이트 (3줄 요약)

본질: Wakelock은 Android가 리눅스 커널 (Linux Kernel)에 추가한 전력 관리(PM, Power Management) 확장 모듈로, 애플리케이션이나 커널 서브시스템이 CPU, 디스플레이, 무선 통신 장치의 절전(Suspend) 상태 진입을 선점적으로 방지(Lock)하여, 사용자 경험을 해치지 않으면서도 유휴(Idle) 시간에는 최대한 전력을 절약하는 세밀한 전력 통제 메커니즘이다.

가치: 기존 리눅스의 OPP (Operating Performance Points) 기반 cpuidle 프레임워크만으로는 모바일 기기의 "화면이 꺼진 상태에서도 음악 재생, GPS 추적, 메시지 수신 대기" 같은 복잡한 전력 시나리오를 처리할 수 없었으나, Wakelock은 이를 우아하게 해결하여 Android가 모바일 OS 시장을 장악하는 핵심 기술 기반이 되었다.

융합: Wakelock은 리눅스 커널의 PM 서브시스템과 Android의 PowerManagerService, ActivityManagerService, 그리고 Doze/App Standby 등 상위 전력 정책 계층이 유기적으로 결합된 결과물이며, 커널 수준의 하드웨어 제어와 프레임워크 수준의 앱 생명주기 관리가 융합된 사례다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념 및 정의 Wakelock은 Android가 리눅스 커널의 전력 관리(PM, Power Management) 서브시스템 위에 구현한 잠금 기반(Lock-based) 전력 상태 제어 메커니즘이다. 기본적으로 리눅스 커널은 CPU가 유휴(Idle) 상태가 되면 자동으로 저전력 모드(C-State)로 진입하지만, 모바일 기기에서는 "백그라운드에서 음악이 재생 중이거나", "GPS가 위치를 추적 중이거나", "긴급 메시지를 기다리는 중"에 CPU가 잠들어 버리면 치명적인 사용자 경험 저하가 발생한다. Wakelock은 이 문제를 해결하기 위해 "특정 작업이 완료될 때까지 CPU나 디바이스가 잠들지 못하게 붙잡아 두는(Wake + Lock)" 장치다.

필요성 및 등장 배경 표준 리눅스 커널의 전력 관리는 서버와 데스크톱 환경에 최적화되어 있었다. 서버는 24시간 가동이 기본이므로 CPU를 적극적으로 suspend할 필요가 없고, 데스크톱은 전원 코드가 연결되어 있어 전력 제약이 심하지 않다. 그러나 모바일 기기는 배터리라는 유한 에너지원으로 동작하며, 사용자는 "화면을 끄고 주머니에 넣어도 음악은 계속 재생되어야 하고, 전화는 걸려오면 바로 받을 수 있어야 하고, 메신저 알림도 실시간으로 와야 한다"는 모순적 요구를 가진다. 기존 리눅스의 pm_suspend()는 "모두 잠들거나 모두 깨어있거나"의 이진적(Binary) 접근만 제공했으나, Android는 "CPU는 깨어있되 디스플레이는 끄고", "Wi-Fi는 켜두되 셀룰러는 끄고" 같은 세밀한(Fine-grained) 제어가 필요했고, 이를 위해 Wakelock을 고안했다.

┌──────────────────────────────────────────────────────────────────┐
│      표준 Linux PM vs Android Wakelock 전력 관리 비교             │
├──────────────────────────────────────────────────────────────────┤
│                                                                  │
│  [표준 리눅스 전력 관리]                                          │
│                                                                  │
│  CPU 활동 → (유휴 감지) → cpuidle → C1 → C2 → ... → Suspend   │
│       │                              │                           │
│       │   "아무도 안 쓰면 전체 잠든다"                            │
│       └─── 문제: 모바일에서는 백그라운드 작업이 항상 존재 ────→ │
│           음악 재생, GPS, PUSH 알림 등이 CPU Suspend와 충돌      │
│                                                                  │
│  ─────────────────────────────────────────────────────────────  │
│                                                                  │
│  [Android Wakelock 전력 관리]                                     │
│                                                                  │
│  App A: "음악 재생 중" ──→ PARTIAL_WAKE_LOCK (CPU 유지)         │
│  App B: "GPS 추적 중"  ──→ PARTIAL_WAKE_LOCK (CPU 유지)         │
│  System: "전화 대기"   ──→ FULL_WAKE_LOCK (CPU + Display)      │
│                                                                  │
│  → 활성 Wakelock이 하나라도 있으면 CPU Suspend 진입 불가        │
│  → 모든 Wakelock이 해제되면 비로소 Suspend 진입                  │
│  ※ 디스플레이, Wi-Fi 등은 독립적인 Wakelock으로 제어             │
└──────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 비교도에서 핵심은 Wakelock이 "참조 카운팅(Reference Counting) 기반의 전력 상태 게이트키퍼(Gatekeeper)" 역할을 한다는 점이다. 여러 앱이 각각 자신의 Wakelock을 획득(Hold)하고 있는 동안에는 커널이 CPU Suspend를 시도하지 않으며, 마지막 Wakelock이 해제(Release)되는 순간에만 비로소 저전력 모드로 진입한다. 이는 운영체제의 읽기-쓰기 락(Read-Write Lock)과 유사한 개념으로, 자원(CPU)의 활성 상태를 여러 주체가 공유하여 관리하는 분산 제어 모델이다.

📢 섹션 요약 비유: Wakelock은 '아파트 엘리베이터의 누르고 있기 버튼' 과 같습니다. 누군가가 버튼을 누르고 있는(Wakelock 획득) 동안에는 엘리베이터 문(CPU)이 닫히지 않고, 모든 사람이 버튼에서 손을 떼면(Wakelock 해제) 비로소 문이 닫혀서 대기 모드(Suspend)로 들어갑니다. 한 사람이라도 버튼을 누르고 있으면 엘리베이터는 계속 켜져 있어요.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

Wakelock 유형 분류

Android는 용도에 따라 4가지 Wakelock 유형을 정의한다. API 레벨 17 이후부터는 PARTIAL_WAKE_LOCK만 권장되며, 나머지는 FLAG_KEEP_SCREEN_ON 등 대체 방식을 사용하도록 유도하고 있다.

Wakelock 유형	CPU	디스플레이	키보드	권장 여부	주요 사용 사례
PARTIAL_WAKE_LOCK	ON	OFF	OFF	✅ 권장	음악 재생, GPS 추적, 다운로드
SCREEN_DIM_WAKE_LOCK	ON	Dim	OFF	❌ Deprecated	(구버전) 짧은 알림 표시
SCREEN_BRIGHT_WAKE_LOCK	ON	Bright	OFF	❌ Deprecated	(구버전) 동영상 재생
FULL_WAKE_LOCK	ON	Bright	Bright	❌ Deprecated	(구버전) 전화 수신

내부 아키텍처: 커널-프레임워크 계층 구조

Wakelock은 크게 세 계층으로 나뉜다: (1) 커널 수준의 wakelock 드라이버, (2) HAL (Hardware Abstraction Layer) 수준의 전력 인터페이스, (3) 프레임워크 수준의 PowerManagerService이다.

┌──────────────────────────────────────────────────────────────────┐
│          Wakelock 아키텍처 계층도 (Architecture Stack)            │
├──────────────────────────────────────────────────────────────────┤
│                                                                  │
│  [③ Application / Framework Layer]                               │
│  ┌─────────────────────────────────────────────────────────┐     │
│  │  App: PowerManager.newWakeLock()                        │     │
│  │    ↓                                                     │     │
│  │  PowerManagerService (시스템 서버)                       │     │
│  │    - Wakelock 참조 카운트 관리                            │     │
│  │    - ActivityManagerService와 연동하여                    │     │
│  │      백그라운드 앱 Wakelock 제한 (Doze 모드)              │     │
│  │    - 통계 수집 (Battery Stats)                           │     │
│  └─────────────────────┬───────────────────────────────────┘     │
│                        │ JNI / Sysfs                              │
│                        ▼                                         │
│  [② HAL / Kernel Interface Layer]                                │
│  ┌─────────────────────────────────────────────────────────┐     │
│  │  /sys/power/wake_lock (sysfs 인터페이스)                 │     │
│  │  /sys/power/wake_unlock                                 │     │
│  │    ↓                                                     │     │
│  │  suspend_ops → PM 핵심 서브시스템과 연동                  │     │
│  └─────────────────────┬───────────────────────────────────┘     │
│                        │ Kernel API                              │
│                        ▼                                         │
│  [① Kernel PM Layer]                                             │
│  ┌─────────────────────────────────────────────────────────┐     │
│  │  wakelock.c (커널 드라이버)                              │     │
│  │    - has_wake_lock() → 활성 Wakelock 존재 여부 확인      │     │
│  │    - wake_lock() / wake_unlock()                         │     │
│  │    - pm_suspend() 진입 차단 / 허용 결정                  │     │
│  │    - expire 타이머 (timeout 기반 자동 해제)               │     │
│  └─────────────────────────────────────────────────────────┘     │
│                        ↓                                         │
│  [Hardware: CPU C-States, DVFS, Clock Gating]                    │
└──────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 계층도는 Wakelock이 단순한 API가 아니라 커널-프레임워크에 걸친 3계층 아키텍처임을 보여준다. 앱이 PowerManager.newWakeLock()을 호출하면, 요청은 PowerManagerService를 거쳐 /sys/power/wake_lock sysfs 노드로 전달되고, 최종적으로 커널의 wakelock.c 드라이버가 has_wake_lock()을 확인하여 pm_suspend() 진입 여부를 결정한다. 따라서 Wakelock 문제를 디버깅할 때는 앱 코드, 프레임워크 서비스, 커널 드라이버 세 계층 모두를 점검해야 한다.

Wakelock 동작 흐름

┌──────────────────────────────────────────────────────────────────┐
│             Wakelock 획득-해제 생명주기 (Lifecycle)               │
├──────────────────────────────────────────────────────────────────┤
│                                                                  │
│  [App Process]                                                   │
│    │                                                             │
│    ├──① wl = pm.newWakeLock(PARTIAL_WAKE_LOCK, "MusicPlayback")│
│    │                                                             │
│    ├──② wl.acquire()  ──────────────────────────────┐          │
│    │    │                                              │          │
│    │    │    [PowerManagerService]                     │          │
│    │    │    ├── Wakelock 등록 (mWakeLocks 리스트)     │          │
│    │    │    ├── ref_count++                           │          │
│    │    │    └── /sys/power/wake_lock에 "MusicPlayback"│          │
│    │    │         기록                                │          │
│    │    │                                              │          │
│    │    │    [Kernel]                                  │          │
│    │    │    └── has_wake_lock() = true                │          │
│    │    │        → pm_suspend() 차단                   │          │
│    │    │        → CPU 활성 상태 유지                   │          │
│    │    │                                              │          │
│    ├──③ ... 음악 재생 중 ...                          │          │
│    │    │                                              │          │
│    ├──④ wl.release()  ──────────────────────────────┘          │
│    │    │                                                        │
│    │    │    [PowerManagerService]                               │
│    │    │    ├── ref_count--                                     │
│    │    │    └── ref_count == 0 ?                                │
│    │    │         ├── YES → /sys/power/wake_unlock               │
│    │    │         │        → has_wake_lock() = false             │
│    │    │         │        → pm_suspend() 진입 허용              │
│    │    │         └── NO  → 다른 Wakelock 유지                   │
│    │    │                                                        │
│    └──⑤ (선택) wl.acquire(60000)  // timeout=60초 자동 해제     │
│         └── 60초 후 커널 타이머가 자동 release                   │
│                                                                  │
└──────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 흐름도는 Wakelock의 핵심 동작인 획득(acquire)과 해제(release)가 세 계층에 걸쳐 어떻게 전파되는지를 보여준다. 특히 ④ 해제 단계에서 참조 카운트(Reference Count)가 0이 되는지 확인하는 것이 핵심이다. 하나의 Wakelock이라도 남아 있으면 CPU는 잠들지 못하므로, Wakelock 누수(Leak)는 곧 배터리 방전으로 직결된다. 따라서 timeout 기반 자동 해제(⑤)를 활용하는 것이 안전한 패턴이다.

Doze 모드와 Wakelock의 관계

Android 6.0 (API 23)부터 도입된 Doze 모드는 Wakelock의 남용을 제한하기 위한 시스템 수준 전력 절약 메커니즘이다. 기기가 화면이 꺼진 채 일정 시간 움직임이 없으면, 시스템은 점진적으로 더 깊은(Deeper) Doze 상태로 진입하며, 이 과정에서 백그라운드 앱의 Wakelock 획득을 무시(Ignore)한다.

Doze 단계	윈도우	Wakelock 동작	네트워크	GPS
Light Doze	N/A	부분적 무시	제한적 허용	비활성
Deep Doze - Phase 1	30분	무시	차단	비활성
Deep Doze - Phase 2	60분	무시	차단	비활성
Deep Doze - Phase N	2N×30분	무시	차단	비활성

📢 섹션 요약 비유: Wakelock 시스템은 '병원의 당번 의사(Call Duty) 제도' 와 같습니다. 당번 의사(Wakelock 획득자)가 병원에 머무르는 동안에는 응급실(CPU)이 완전히 문을 닫을 수 없습니다. 한 명의 의사라도 당번이면 응급실은 24시간 가동되고, 모든 의사가 퇴근하면(Wakelock 해제) 응급실은 대기 모드(Suspend)로 전환됩니다. Doze 모드는 "새벽 2시 이후에는 당번 의사가 있어도 응급실을 대기 모드로 전환"하는 관리자의 규칙과 같습니다.

Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)

Wakelock vs 표준 리눅스 전력 관리

비교 항목	Wakelock (Android)	표준 리눅스 PM	차이점 요약
제어 방식	명시적 Lock/Unlock	자동 유휴 감지 (cpuidle)	Android는 앱이 주도, Linux는 커널이 주도
세분성	CPU, Display, Radio 개별 제어	CPU C-State 중심	Android가 더 세밀(Fine-grained)
백그라운드 고려	앱별 Wakelock 관리	프로세스 기반 (없음)	Android가 앱 생명주기와 연동
오용 방지	Doze/App Standby 제한	없음 (신뢰 모델)	Android가 시스템 수준 제어 추가
업스트림	mainline에 통합 시도 중	기본 프레임워크	Android가 리눅스에 기여한 PM 확장

다른 전력 관리 기법과의 비교

기법	계층	역할	Wakelock과의 관계
cpuidle	커널	CPU C-State 진입 관리	Wakelock이 없을 때 작동
cpufreq / DVFS	커널	CPU 주파수/전압 동적 조절	Wakelock과 독립적
Runtime PM	커널	개별 디바이스 전원 게이팅	Wakelock이 장악한 디바이스는 Runtime PM 무시
Doze / App Standby	프레임워크	백그라운드 앱 활동 제한	Wakelock 오용에 대한 안전장치
JobScheduler	프레임워크	조건부 백그라운드 작업 스케줄링	Wakelock 대체 권장 API
WorkManager	라이브러리	호환성 있는 백그라운드 작업	Wakelock 대체 권장 API (권장)

┌──────────────────────────────────────────────────────────────────┐
│      전력 관리 계층간 상호작용 (Power Management Interaction)     │
├──────────────────────────────────────────────────────────────────┤
│                                                                  │
│  [앱이 Wakelock 획득]                                           │
│       ↓                                                          │
│  [PowerManagerService] ──→ Wakelock 등록                       │
│       ↓                   (Doze 모드면 무시 가능)               │
│  [Kernel wakelock.c]                                            │
│       ↓                                                          │
│  has_wake_lock() == true ?                                       │
│       ├── YES → cpuidle 차단, CPU 활성 유지                    │
│       │         단, DVFS는 여전히 동작하여                      │
│       │         주파수를 낮출 수는 있음                         │
│       └── NO  → cpuidle 활성화                                  │
│                 → C1 → C2 → ... → Suspend 순차 진입             │
│                                                                  │
│  ※ Wakelock은 "잠들지 마라"이지 "최고 속도로 돌아라"가 아님   │
│     → Wakelock + DVFS 조합으로 전력 최적화 가능                 │
└──────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 상호작용도에서 중요한 점은 Wakelock과 DVFS (Dynamic Voltage and Frequency Scaling)가 독립적으로 동작한다는 것이다. Wakelock은 "CPU를 잠들지 않게만 할 뿐" 최고 클럭으로 구동하라는 의미가 아니다. 따라서 Wakelock을 획득한 상태에서도 cpufreq 정책(예: powersave, schedutil)에 따라 CPU 주파수가 조절된다. 실무에서는 이 두 메커니즘을 조합하여 "CPU는 깨어있되 낮은 클럭으로 동작"시키는 것이 가장 효율적인 전력 관리 전략이다.

📢 섹션 요약 비유: Wakelock과 다른 전력 관리 기법의 관계는 '자동차의 여러 절전 장치' 와 같습니다. Wakelock은 시동 끄기 방지(엔진이 꺼지지 않게 함), DVFS는 RPM 조절(속도를 낮춰 연료 절약), Doze는 "고속도로에서 10분 이상 안 움직이면 시동 꺼"라는 규칙과 같아서, 여러 장치가 계층적으로 작동하여 최적의 연비(전력 효율)를 만들어냅니다.

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

실무 시나리오 및 디버깅

시나리오 1: 밤사이 배터리 30% 소모 원인 분석

현상: 화면을 끄고 잤는데 아침에 배터리가 30% 이상 소모됨
진단 도구: adb shell dumpsys batterystats, Battery Historian
일반적 원인: 백그라운드 앱이 PARTIAL_WAKE_LOCK을 획득한 채 해제하지 않음 (Wakelock 누수)
해결: 해당 앱의 Wakelock 사용 패턴 분석 → Foreground Service로 전환 또는 WorkManager 사용 권장
명령어 예시: $ adb shell dumpsys power | grep "Wake Locks"

시나리오 2: GPS 네비게이션 중 화면 꺼짐

현상: 네비게이션 앱 사용 중 일정 시간 후 화면이 자동으로 꺼짐
진단: FLAG_KEEP_SCREEN_ON 미설정 또는 SCREEN_BRIGHT_WAKE_LOCK 미사용
해결: WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON 설정 (Wakelock 직접 사용보다 권장)
주의: Wakelock 직접 사용보다 시스템이 관리하는 FLAG_KEEP_SCREEN_ON이 안전함

시나리오 3: Doze 모드에서 긴급 알림 지연

현상: Doze 모드 진입 후 FCM (Firebase Cloud Messaging) 알림이 몇 시간씩 지연됨
원인: Doze가 네트워크 접근을 차단하여 일반 FCM 메시지가 즉시 전달되지 않음
해결: FCM High Priority 메시지 사용 → 시스템이 Doze를 일시적으로 해제하여 즉시 전달

┌──────────────────────────────────────────────────────────────────┐
│        Wakelock 디버깅 체크리스트 (Debugging Checklist)           │
├──────────────────────────────────────────────────────────────────┤
│                                                                  │
│  □ 1. Wakelock 누수 탐지                                        │
│    □ $ adb shell dumpsys power | grep "Wake Locks"              │
│    □ Battery Historian에서 Wakelock 지속 시간 시각화             │
│    □ 특정 앱의 Wakelock hold 시간이 비정상적으로 긴지 확인       │
│                                                                  │
│  □ 2. 코드 패턴 점검                                             │
│    □ acquire()와 release()가 반드시 쌍을 이루는가?              │
│    □ try-finally 블록으로 release 보장하는가?                    │
│    □ timeout 파라미터를 사용하는가? (안전망)                    │
│                                                                  │
│  □ 3. 대체 API 사용 검토                                         │
│    □ WorkManager로 대체 가능한가? (권장)                        │
│    □ Foreground Service로 전환하는 것이 더 적절한가?            │
│    □ FLAG_KEEP_SCREEN_ON으로 충분한가? (화면 켜짐 유지 시)      │
│                                                                  │
│  □ 4. Doze 호환성 확인                                           │
│    □ Doze 모드에서 Wakelock이 무시되어도 동작하는가?            │
│    □ FCM High Priority 메시지를 사용하는가?                     │
│    □ Maintenance Window 동안 작업을 수행하는가?                  │
└──────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 체크리스트는 Wakelock 관련 문제를 체계적으로 진단하기 위한 실무 가이드다. 가장 흔한 실수는 acquire() 후 예외(Exception) 발생 시 release()가 호출되지 않는 것이며, 이를 방지하려면 반드시 try-finally 블록을 사용해야 한다. 또한 Android 6.0+에서는 Doze 모드가 백그라운드 Wakelock을 무시하므로, Wakelock에 의존하는 백그라운드 작업은 WorkManager나 Foreground Service로 전환하는 것이 장기적인 해결책이다.

안티패턴 (Anti-Patterns)

안티패턴	증상	올바른 접근
Wakelock 누수	acquire() 후 release() 누락 → 배터리 급소모	try-finally로 release 보장, timeout 사용
과도한 Wakelock	짧은 작업에 불필요한 Wakelock 획득	WorkManager / JobScheduler로 대체
FULL_WAKE_LOCK 사용	화면을 무한정 켜두어 배터리 소모	FLAG_KEEP_SCREEN_ON 사용
Doze 무시 시도	백그라운드에서 Wakelock으로 Doze 우회	FCM High Priority + Maintenance Window 활용
커널 Wakelock 직접 조작	/sys/power/wake_lock 직접 기록	PowerManager API를 통해서만 접근

📢 섹션 요약 비유: Wakelock 디버깅은 '수도꼭지 누수 점검' 과 같습니다. 눈에 보이지 않는 곳(백그라운드)에서 물(Wakelock)이 계속 틀어져 있으면 수도요금(배터리)이 폭탄 청구서가 됩니다. 그래서 일일이 꼭지를 점검(dumpsys)하고, 자동 차단 장치(timeout)를 설치하고, 아예 사용하지 않는 꼭지는 잠구는(WorkManager 전환) 것이 중요합니다.

Ⅴ. 기대효과 및 결론 (Future & Standard)

정량/정성 기대효과

효과 유형	내용	정량 지표
대기 전력 최적화	Wakelock 정상 관리 시 대기 배터리 소모 최소화	대기 시간 200시간+ (정상 관리 시) vs 12시간 (누수 시)
사용자 경험 향상	백그라운드 작업 중단 방지	음악 재생 끊김율 0% (Wakelock 사용 시)
앱 품질 평가	Google Play에서 Wakelock 오용 앱 경고	Battery Optimized 뱃지 획득 가능
시스템 안정성	과도한 Wakelock으로 인한 열 발생(Thermal Throttling) 방지	기기 온도 5~10°C 감소

미래 전망

Wakelock은 Android 전력 관리의 핵심 메커니즘이지만, 점진적으로 상위 수준(Higher-level) API로 대체되고 있다. Android 12에서는 Exact Alarm 권한이 제한되고, Android 14에서는 백그라운드 Foreground Service에 더 엄격한 제한이 적용되었다. 향후 방향은 "개발자가 직접 Wakelock을 관리하지 않고, 시스템이 앱의 작업 특성을 파악하여 자동으로 전력을 최적화하는" 모델이다. 이를 위해 WorkManager, JobScheduler, FCM (Firebase Cloud Messaging) 등 선언적(Declarative) API가 지속적으로 강화되고 있다.

참고 표준

Android Compatibility Definition Document (CDD): Wakelock 관련 호환성 요구사항
Linux Kernel PM Documentation (Documentation/power/): 커널 전력 관리 공식 문서
Android Developer Guide - Power Management: Wakelock 및 대체 API 공식 가이드
AOSP (Android Open Source Project): Wakelock 커널 소스 코드 (kernel/power/wakelock.c)
📢 섹션 요약 비유: Wakelock의 미래는 '수동 변속기에서 자동 변속기로의 전환' 과 같습니다. 과거에는 운전자(개발자)가 직접 기어를 넣어야(Wakelock 획득/해제) 했지만, 점점 더 스마트한 자동 변속기(WorkManager, Doze)가 엔진(CPU)의 상태를 알아서 판단하여 최적의 기어(전력 모드)를 선택하는 방향으로 진화하고 있습니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
리눅스 커널 PM (Power Management)	Wakelock이 기반으로 하는 커널 전력 관리 서브시스템으로, cpuidle, cpufreq, Runtime PM 등의 메커니즘과 함께 Android의 전력 최적화를 구성하는 기반 계층이다.
Android Doze / App Standby	Wakelock 남용을 시스템 수준에서 제한하는 전력 절약 메커니즘으로, Wakelock에 의존하는 앱은 Doze 모드 진입 시 정상 동작하지 않을 수 있어 대체 API 전환이 필요하다.
WorkManager / JobScheduler	Wakelock의 안전한 대체 API로, 개발자가 직접 Wakelock을 관리하지 않고도 조건부 백그라운드 작업(네트워크, 충전 중 등)을 실행할 수 있는 선언적 작업 스케줄링 프레임워크다.
Binder IPC (Inter-Process Communication)	App→PowerManagerService→커널로 이어지는 Wakelock 요청 경로에서, 프로세스 간 통신을 담당하는 Android의 핵심 IPC 메커니즘이다.
Foreground Service	백그라운드에서 장시간 실행되어야 하는 작업(음악, GPS 등)이 Wakelock 대신 사용해야 하는 Android 공식 백그라운드 실행 메커니즘으로, 사용자에게 알림(Notification)을 표시하여 투명성을 보장한다.

👶 어린이를 위한 3줄 비유 설명

스마트폰은 전기를 아끼기 위해 쓰지 않을 때 잠자리(Zzz) 에 들어요. 그런데 음악을 듣고 있거나 지도를 보고 있을 때는 잠들면 안 되죠!
그래서 "나 아직 일하고 있으니까 잠들지 마!" 라고 스마트폰에게 말해주는 표시(Wakelock)가 있어요. 이 표시가 붙어 있는 동안에는 스마트폰이 깨어 있어요.
그런데 표시를 붙여놓고 깜빡해서 안 떼면(누수), 스마트폰이 잠을 못 자서 배터리가 다 닳아버려요! 그래서 꼭 필요할 때만 붙이고, 다 쓰면 바로 떼는 게 중요해요!