WorkManager Constraints는 안드로이드 백그라운드 작업을 설계할 때 가장 먼저 이해해야 할 기준 중 하나입니다. 결론부터 말하면 Constraints는 작업을 귀찮게 만드는 옵션이 아니라 작업을 언제 돌려야 덜 문제를 만드는지 선언하는 장치입니다.
이번 글에서는 WorkManager Constraints가 왜 필요한지, 네트워크·충전·배터리 조건을 어떻게 판단해야 하는지, periodic work와 expedited work를 어떻게 구분해야 하는지 실무 기준으로 정리하겠습니다.
먼저 결론
- Constraints는 작업을 최적 조건까지 미루기 위한 실행 조건이다
- 조건이 안 맞으면 실패보다 대기로 이해하는 편이 맞다
- 조건을 많이 건다고 항상 더 좋은 설계가 되지는 않는다
- PeriodicWorkRequest는 주기 시간이 지나도 조건이 맞지 않으면 지연될 수 있다
- expedited work는 즉시성 축이지 Constraints를 대신하는 기능이 아니다
백그라운드 작업은 빨리 도는 것보다 맞는 순간에 도는 것이 더 중요할 때가 많습니다.
WorkManager Constraints가 필요한 이유
사진 업로드, 로그 전송, 캐시 정리, 서버 동기화 같은 백그라운드 작업은 화면에 보이지 않아도 배터리와 네트워크, 저장 공간에 영향을 줍니다. 그래서 WorkManager는 enqueue 즉시 실행보다 시스템 상태와 사용자 경험에 맞는 실행을 우선합니다. 공식 문서도 Constraints를 work를 최적 조건이 충족될 때까지 지연시키는 조건으로 설명합니다.
대표 조건 다섯 가지
- NetworkType: 어떤 네트워크에서만 실행할지 정한다. 대용량 업로드는 UNMETERED가 자연스럽고, 작은 동기화는 과할 수 있다.
- RequiresCharging: 충전 중일 때만 실행한다. 무거운 작업에는 적합하지만 가벼운 동기화에는 지연만 늘릴 수 있다.
- BatteryNotLow: 배터리가 부족할 때는 실행하지 않는다. 배터리 민감 작업에 유용하지만 작은 작업까지 기본처럼 붙일 필요는 없다.
- StorageNotLow: 저장 공간이 부족할 때는 실행하지 않는다. 파일 생성이나 캐시 확장 작업에서 의미가 크다.
- DeviceIdle: 기기가 idle 상태일 때만 실행한다. 적극 사용 중인 기기에 부담을 줄 수 있는 배치 작업에 더 어울린다.
코드 예제
val constraints = Constraints.Builder()
.setRequiredNetworkType(NetworkType.UNMETERED)
.setRequiresCharging(true)
.build()
val uploadWork = OneTimeWorkRequestBuilder<UploadWorker>()
.setConstraints(constraints)
.build()
WorkManager.getInstance(context).enqueue(uploadWork)이 코드는 ‘지금 바로 실행’보다 Wi‑Fi이고 충전 중일 때 실행해도 좋다에 더 가깝습니다. 그래서 enqueue 직후 바로 안 돈다고 해서 이상한 것이 아니라 조건을 기다리고 있을 가능성이 큽니다.
작업이 안 도는 것처럼 보이는 이유
val constraints = Constraints.Builder()
.setRequiredNetworkType(NetworkType.UNMETERED)
.setRequiresCharging(true)
.setRequiresBatteryNotLow(true)
.setRequiresStorageNotLow(true)
.build()이 조합이 틀렸다는 뜻은 아닙니다. 하지만 모든 작업에 이렇게 붙이면 실행 가능한 순간이 거의 오지 않을 수 있습니다. 문제는 scheduler보다 설계일 가능성이 크다는 점을 먼저 의심하는 편이 좋습니다.
PeriodicWorkRequest에서 더 헷갈리는 이유
공식 문서에 따르면 periodic work에도 Constraints를 적용할 수 있으며, repeat interval이 지났더라도 조건이 맞지 않으면 실행이 지연되거나 해당 주기에서 건너뛴 것처럼 보일 수 있습니다. 그래서 periodic work는 ‘정시에 반드시 한 번’보다 ‘조건이 맞는 범위 안에서 반복 시도’에 가깝게 이해해야 합니다.
expedited work와는 무엇이 다른가
expedited work는 WorkManager 2.7.0에서 도입된 개념으로, 중요하고 user-initiated하며 짧게 끝나는 작업에 적합합니다. 다만 quota와 시스템 workload 영향을 받기 때문에 무조건 즉시 실행된다고 이해하면 안 됩니다. 즉시성이 핵심인 별도 축이지, Constraints를 지워 주는 만능 버튼은 아닙니다.
실전 체크리스트
- 이 작업은 지금 꼭 끝나야 하는가
- 네트워크 비용이 큰가
- 배터리 부담이 큰가
- 충전 중일 때만 해도 되는가
- 저장 공간이 부족할 때 멈추는 편이 안전한가
- periodic work라면 실제 사용자 환경에서 실행 기회가 충분한가
- expedited 후보라면 정말 짧고 사용자 주도적인 작업인가
이 기준으로 보면 Constraints는 옵션 암기보다 훨씬 실전적인 설계 도구로 보이기 시작합니다.
정리
WorkManager Constraints는 백그라운드 작업을 느리게 만드는 장애물이 아니라, 언제 실행해야 사용자 경험과 시스템 자원에 덜 해로운지 선언하는 기준입니다. 마지막으로 핵심만 다시 적으면 Constraints는 실패 조건이 아니라 대기 조건에 가깝고, periodic work는 주기만으로 보장되지 않으며, expedited work는 Constraints의 대체재가 아닙니다.
공식 참고 문서는 Define work requests와 Constraints API reference입니다.
관련해서는 Hilt EntryPoint 정리처럼 안드로이드 백그라운드/시스템 경계에서 자주 막히는 글도 같이 보면 좋습니다.
공식 기준은 Android Developers define work requests와 Constraints API reference를 함께 보면 가장 정확합니다.
