Android 백그라운드 작업의 발전사
목차
2025년, 안드로이드 앱에서 꼭 실행해야 할 백그라운드 처리를 하려면 WorkManager만한 것이 없다. WorkManager를 사용해 본 개발자라면 알겠지만 너무나도 쉽게 백그라운드 작업을 구현할 수 있다.
그런데 WorkManager는 안드로이드의 탄생부터 있던 녀석이 아니다. WorkManager가 나오기까지 안드로이드에서는 여러 가지의 시행착오가 있었다. 어떤 것이 탄생했고 사장되었는지 이번 글에서 간단히 훑어보고자 한다.
태초에 Service가 있었다 #
안드로이드를 공부한 사람이라면 Service를 모를 수는 없을 것이다. 안드로이드 앱 구성요소(a.k.a 안드로이드 4대 컴포넌트)로 불리는 4가지 요소 중 하나로, 오래 걸리는 작업을 처리하는데 쓰기 좋은 컴포넌트로 만들어졌다. 기본 제공되는 기능이기도 하고 초창기부터 지원했기 때문에 대부분 Service를 이용해 백그라운드 처리를 구현했다.
하지만 시간이 지나며 Service에 문제점이 발견되기 시작했다. 앱들이 무분별하게 백그라운드 Service를 이용하면 사용자는 알지도 못한 채 계속 메모리와 배터리가 소모되는 현상이 일어나기 때문이다. 이에 구글은 백그라운드 Service에 대폭 제한을 걸기 시작한다.
안드로이드 오레오(API 26)부터 앱이 포그라운드에 있지 않으면 백그라운드 작업을 대폭 제한되도록 만들고, 서비스의 생성을 startService에서 startForegroundService를 통하도록 바꾸었다. 1
즉, 백그라운드 동작을 수행해도 사용자가 작업이 진행중임을 인지할 수 있도록 강제한 것이다.
또한 도즈(Doze) 모드를 도입해 앱 일정 시간 이상 백그라운드에 머무르면 네트워크 활동과 백그라운드 CPU 사용을 지연시켜 배터리 수명을 늘리도록 만들었다. 결국 백그라운드에 있을 때 Service가 온전히 동작할수 있다는 보장이 사라졌다.
불완전한 대체제 JobScheduler #
구글이 백그라운드 Service를 대폭 제한하면서 JobScheduler를 사용하라고 대안을 제시했다. JobScheduler는 안드로이드 롤리팝(API 21)에서 등장했는데, 백그라운드 작업을 언제 실행할지 정할 수 있게 만든 기능이다.
하지만 JobScheduler도 문제가 있었는데 불안정하다는 것이였다. JobScheduler가 등장한 API 21보다 아래의 버전에서는 사용할 수가 없었고 정작 API 21에서는 JobScheduler가 불안정해 문제가 있었으며 이는 마쉬멜로우(API 23)쯤 되어서야 안정화되었다. 결국 개발자들은 버전에 따른 분기 처리를 해야 하는 상황에 놓이게 되었고 백그라운드 처리는 매우 귀찮은 작업이 되었다.
Firebase의 JobDispatcher 제시 #
이러던 중 구글 내부에서도 불편함을 느꼈는지 Firebase에서 JobDispatcher라는 것을 공개한다.
기기가 마쉬멜로우(API 23)이상 높은 버전이면 안정화된 JobScheduler를, 낮은 버전이면 AlarmManager를 이용해 백그라운드 처리를 하도록 도와주는 컴포넌트를 만든 것이다. 매번 불편하게 분기해야 했던 부분을 해소해 준 것은 좋았다.
하지만 Firebase에 속한 라이브러리인 것이 문제였다. 안드로이드 팀이 제시한 대체제가 아니였고 내부적으로는 버전 호환성만 맞춘 것이였다. JobDispatcher도 근본적인 문제를 해결해주지 못했고 결국 이후 WorkManager가 등장하며 deprecated 된다. 2
WorkManager의 등장 #
혼란이 지속되던 와중에 구글은 Google I/O 2018에서 WorkManager라이브러리를 공개한다. 3
WorkManager는 별도의 라이브러리로 만들어져서 Firebase처럼 불필요하게 의존성이 딸려 오지 않고, API 21부터 지원하는 JobScheduler와는 다르게 API 14 이상을 지원하게 만들어져 버전 분기 처리도 해결되었으며, API 21~23 사이의 JobScheduler처럼 불안정한 부분도 2019년 stable release4를 출시하며 해소되었고, Service처럼 백그라운드 작업에 심한 제약이 걸리지도 않는다.
그동안의 백그라운드 처리 방법의 큰 문제점들을 대부분 해결하는 라이브러리였다.
또한 추가로 작업 chaining을 지원해 여러 개의 백그라운드 작업을 순차적으로 엮을 수 도 있고, 안드로이드에 최적화된 방식으로 백그라운드 작업을 수행하기 때문에 배터리 소모나 메모리 소모를 줄일 수 있다. 또한 앱이 종료되거나 기기를 재부팅해도 작업이 동작하도록 만들어져 백그라운드 작업의 실행 보장성도 강화되었다.
앞으로는? #
WorkManager는 지금까지는 큰 문제가 없어 보인다. 예전에 있었던 방식들의 구조적인 문제들이 대부분 해소되었고 추가적인 장점까지 생겼다. 아마 현존하는 대부분의 앱 개발에는 큰 문제가 없을 것이다.
하지만 소프트웨어는 빠르게 바뀌는 분야지 않은가? 앞으로 또 어떤 지점이 문제점으로 돌아올지는 알 수 없다. 계속해서 바뀌어 가는 것이 소프트웨어이고 소프트웨어를 개발하는 개발자는 변화에 따라가야 하는 것이 숙명이라고 생각한다. 앞으로 어떤 방향으로 바뀔지는 알 수 없지만 더 좋은 방향으로 개선되기를 기대한다.