웨어러블용 Android 앱을 빌드한다는 것은 화면이 꺼질 때 실제 작업이 시작된다는 의미입니다. WHOOP은 회원이 운동, 회복, 수면, 스트레스에 대한 신체의 반응을 이해하도록 지원하며, Android를 사용하는 많은 WHOOP 회원에게는 안정적인 백그라운드 동기화와 연결이 이러한 통계를 가능하게 합니다.

올해 초 Google Play에서는 Android Vitals에 새로운 측정항목을 출시했습니다. 바로 과도한 부분 절전 모드입니다. 이 측정항목은 24시간 동안 누적되고 예외가 적용되지 않는 wake lock 사용량이 2시간을 초과하는 사용자 세션의 비율을 측정합니다. 이 측정항목의 목표는 배터리 소모의 가능한 원인을 파악하고 해결하는 데 도움을 주는 것입니다. 이는 우수한 사용자 환경을 제공하는 데 매우 중요합니다.

2026년 3월 1일부터 품질 기준점을 계속 충족하지 않는 앱은 Google Play 검색 표시에서 제외될 수 있습니다. 앱이 예상보다 많은 배터리를 사용할 수 있음을 나타내는 경고가 Google Play 스토어 등록정보에 표시될 수도 있습니다.

WHOOP의 수석 Android 엔지니어인 마얀크 사이니에 따르면 Android vitals에서 앱의 과도한 부분 wake lock 비율이 권장 기준인 5%를 초과하는 15%로 표시된 후 '팀이 Android 효율성 기준을 높일 수 있는 기회가 생겼습니다'.

팀은 Android vitals 측정항목을 백그라운드 작업으로 인해 CPU가 필요 이상으로 오랫동안 깨어 있다는 명확한 신호로 간주했습니다. 이 문제를 해결하면 우수한 사용자 환경을 계속 제공하는 동시에 낭비되는 백그라운드 시간을 줄이고 안정적이고 시기적절한 블루투스 연결 및 동기화를 유지할 수 있습니다.

문제 파악

시작할 위치를 파악하기 위해 팀은 먼저 Android vitals를 통해 측정항목에 영향을 미치는 절전 모드를 자세히 파악했습니다. Android vitals 과도한 부분 wake lock 대시보드를 참고하여 과도한 부분 wake lock의 가장 큰 원인이 WorkManager 작업자 중 하나 (대시보드에 androidx.work.impl.background.systemjob.SystemJobService로 표시됨)임을 파악했습니다. WHOOP '상시 사용 설정 환경'을 지원하기 위해 앱은 주기적인 동기화 및 웨어러블에 반복 업데이트 제공과 같은 백그라운드 작업에 WorkManager를 사용합니다. 

팀은 백그라운드에서 작업을 실행하는 동안 WorkManager가 wake lock을 획득한다는 사실을 알고 있었지만, 이전에는 Android Vitals에 과도한 부분 wake lock 측정항목이 도입되기 전까지 WorkManager를 넘어 모든 백그라운드 작업이 어떻게 분산되는지 알 수 없었습니다.

대시보드에서 WorkManager가 주요 기여자로 식별되자 팀은 가장 많이 기여하는 작업자를 파악하고 문제를 해결하는 데 집중할 수 있었습니다.

내부 측정항목 및 데이터를 활용하여 원인 좁히기

WHOOP에는 WorkManager 측정항목을 모니터링하기 위한 내부 인프라가 이미 설정되어 있었습니다. 다음 항목을 주기적으로 모니터링합니다.

1. 평균 실행 시간: 작업자가 얼마나 오래 실행되나요?
2. 시간 제한: 작업자가 완료하는 대신 시간 제한이 발생하는 빈도입니다.
3. 재시도: 작업이 시간 초과되거나 실패한 경우 작업자가 얼마나 자주 재시도하나요?
4. 취소: 작업이 얼마나 자주 취소되었나요?

작업자의 성공과 실패뿐만 아니라 다른 요소도 추적하면 팀에서 작업의 효율성을 파악할 수 있습니다.

내부 측정항목에서 일부 작업자의 평균 런타임이 높음을 표시하여 조사 범위를 더욱 좁힐 수 있었습니다. 

팀은 내부 측정항목 외에도 Android 스튜디오의 Background Task Inspector를 사용하여 관심 있는 작업자를 검사하고 디버그했으며, Android vitals에서 플래그가 지정된 측정항목에 맞게 연결된 절전 모드 해제에 특히 중점을 두었습니다.

조사: 작업자 변형 구분

WHOOP는 일부 작업자에 대해 일회성 및 주기적 일정을 모두 사용합니다. 이를 통해 앱은 타이밍만 다르고 동일한 성공 기준을 가진 동일한 작업에 동일한 Worker 로직을 재사용할 수 있습니다.

내부 측정항목을 사용하면 특정 작업자로 검색 범위를 좁힐 수 있었지만 작업자가 일회성인지, 주기적인지, 아니면 둘 다인지 알 수 없었습니다. 따라서 WorkManager의 setTraceTag 메서드를 사용하여 동일한 Worker의 일회성 변형과 주기적 변형을 구분하는 업데이트를 출시했습니다.

이 추가 세부정보를 통해 과도한 부분 절전 모드가 있는 세션에 가장 많이 기여한 Worker 변형 (주기적 또는 일회성)을 명확하게 식별할 수 있습니다. 하지만 데이터에 따르면 두 변형 모두 다른 변형보다 더 많이 기여하지 않는 것으로 나타나 팀은 놀랐습니다.

WHOOP의 Android 엔지니어 II인 Manmeet Tuteja는 '이 분할을 통해 문제가 두 변형에서 모두 발생한다는 것을 확인할 수 있었으며, 이는 예약 구성이 아닌 작업자 구현 내의 공유 비즈니스 로직 문제로 이어졌습니다.'라고 말했습니다.

작업자 동작 자세히 알아보고 근본 원인 수정

작업자 내부의 로직을 살펴봐야 한다는 사실을 알게 된 팀은 조사 중에 플래그가 지정된 작업자의 작업자 동작을 다시 검토했습니다. 특히 작업이 멈춰 완료되지 않는 인스턴스를 찾고 있었습니다.

이 모든 과정을 거쳐 불필요한 wake lock의 근본 원인을 찾았습니다.

진행하기 전에 WHOOP 센서에 연결되기를 기다리도록 설계된 CoroutineWorker입니다. 

센서가 연결되지 않은 상태로 운동을 시작한 경우 센서 연결 여부를 나타내는 whoopSensorFlow이 null이었습니다. SensorWorker에서는 이를 조기 종료 조건으로 처리하지 않고 계속 실행되어 사실상 연결을 무기한 기다렸습니다. 따라서 WorkManager는 작업이 시간 초과될 때까지 부분 절전 모드 해제 잠금을 유지하여 백그라운드 절전 모드 해제 잠금 사용량이 많아지고 SensorWorker의 원치 않는 재예약이 빈번하게 발생했습니다.

이 문제를 해결하기 위해 WHOOP팀은 핵심 비즈니스 로직을 실행하기 전에 연결 상태를 확인하도록 작업자 로직을 업데이트했습니다.

센서를 사용할 수 없는 경우 worker가 종료되어 시간 초과 시나리오를 방지하고 wake lock을 해제합니다. 다음 코드 스니펫은 솔루션을 보여줍니다.

class SensorWorker(appContext: Context, params: WorkerParameters): CoroutineWorker(appContext, params) {
   override suspend fun doWork(): Result {
      ...
      // Check the sensor state and perform work or return failure
       return whoopSensorFlow.replayCache
            .firstOrNull()
            ?.let { cachedData ->
                processSensorData(cachedData)
                Result.success()
            } ?: run {
                Result.failure()
            }
}

과도한 부분적인 절전 모드가 있는 세션 90% 감소

수정사항을 출시한 후 팀은 변경사항의 영향을 확인하기 위해 Android vitals 대시보드를 계속 모니터링했습니다. 

결과적으로 WHOOP는 Worker 변경을 구현한 후 30일 만에 과도한 부분 wake lock 비율이 15% 에서 1%미만으로 감소했습니다. 

이러한 변경사항으로 인해 완료되지 않은 작업의 타임아웃 인스턴스가 줄어들어 평균 런타임이 단축되었습니다. 

백그라운드 작업의 효율성을 개선하려는 다른 개발자에게 WHOOP팀이 전하는 조언은 다음과 같습니다.

시작하기

앱의 과도한 부분 wake lock을 줄이거나 작업자 효율성을 개선하는 데 관심이 있다면 Android vitals에서 앱의 과도한 부분 wake lock 측정항목을 확인하고 wake lock 문서에서 권장사항과 디버깅 전략을 자세히 검토하세요.