Android 백그라운드 작업 완벽 가이드 — WorkManager, Coroutine, Foreground Service 비교와 실전 구현

Android 앱을 개발하다 보면 사용자가 화면을 보고 있지 않은 상황에서도 작업을 처리해야 하는 경우가 있습니다.

예를 들어 다음과 같은 기능입니다.

• 서버에서 최신 데이터를 다운로드하여 SQLite 데이터베이스 갱신

• 사용자가 작성한 메모를 서버에 동기화

• 일정 주기로 새로운 콘텐츠 확인

• 대용량 파일 다운로드

• 사용자가 시작한 장시간 데이터 처리

• 네트워크 연결이 복구되면 실패한 요청 재시도

이러한 기능을 구현할 때 자주 사용하는 기술이 Coroutine, WorkManager, Foreground Service입니다.

세 기술은 모두 백그라운드 작업과 관련이 있지만 역할이 다릅니다.

잘못 선택하면 앱이 백그라운드로 이동했을 때 작업이 취소되거나, 시스템 제한 때문에 실행되지 않거나, 불필요하게 배터리를 소모하는 문제가 발생할 수 있습니다.

이번 글에서는 Kotlin 기반 Android 앱에서 세 기술의 차이를 이해하고, WorkManager를 이용한 데이터 동기화 기능을 구현하는 방법을 정리하겠습니다.

작성 기준: 2026년 10월. Android의 백그라운드 실행 정책은 OS 버전과 앱의 targetSdk에 따라 달라질 수 있으므로 배포 전 공식 문서를 확인해야 합니다.

1. Android 백그라운드 작업이란?

Android 앱은 사용자가 화면을 보고 있을 때만 동작하는 것이 아닙니다.

앱이 백그라운드로 이동한 이후에도 일부 작업이 필요할 수 있습니다.

하지만 Android는 배터리 수명과 시스템 자원을 보호하기 위해 백그라운드 실행을 제한합니다.

따라서 개발자는 작업의 특성에 따라 적절한 실행 방식을 선택해야 합니다.

대표적인 선택지는 다음과 같습니다.

가장 중요한 차이는 작업을 반드시 나중에라도 완료해야 하는지입니다.

2. Coroutine은 백그라운드 작업을 보장하지 않는다

Kotlin Coroutine은 비동기 코드를 작성하기 위한 도구입니다.

예를 들어 다음과 같이 SQLite 데이터를 조회할 수 있습니다.

viewModelScope.launch {
    val birds = withContext(Dispatchers.IO) {
        repository.getBirds()
    }

    _birds.value = birds
}

이 코드는 메인 스레드를 차단하지 않고 데이터베이스 작업을 수행하는 데 적합합니다.

하지만 viewModelScope는 ViewModel의 생명주기에 연결됩니다.

ViewModel이 제거되면 해당 Scope의 Coroutine도 취소됩니다.

따라서 화면이 사라진 이후에도 반드시 완료해야 하는 작업에는 적합하지 않을 수 있습니다.

예를 들어 사용자가 메모를 작성한 뒤 앱을 종료하더라도 서버 동기화가 완료되어야 한다면 WorkManager를 고려하는 것이 좋습니다.

3. WorkManager란?

WorkManager는 Android Jetpack에서 제공하는 백그라운드 작업 관리 라이브러리입니다.

앱이 즉시 실행 중이지 않더라도 완료되어야 하는 작업을 예약할 수 있습니다.

WorkManager는 내부적으로 Android 버전에 맞는 시스템 스케줄링 기능을 사용합니다.

대표적인 특징은 다음과 같습니다.

• 앱 프로세스가 종료되어도 예약 작업 정보 유지

• 네트워크 연결 등 실행 조건 지정

• 작업 실패 시 재시도

• 일회성 작업과 주기적 작업 지원

• 작업 상태 관찰

• 여러 작업을 순서대로 연결

• 중복 작업 예약 방지

다만 WorkManager는 정확한 시각에 실행되는 스케줄러가 아닙니다.

배터리 상태, Doze 모드, 시스템 자원, 실행 제약 조건 등에 따라 작업이 지연될 수 있습니다.

또한 사용자가 앱을 강제 종료하거나 제조사별 백그라운드 제한이 적용된 경우에는 실행이 제한될 수 있습니다.

4. WorkManager 의존성 추가

app/build.gradle.kts에 WorkManager 의존성을 추가합니다.

dependencies {
    implementation(
        "androidx.work:work-runtime-ktx:<version>"
    )
}

<version>에는 프로젝트에서 사용하는 AndroidX WorkManager의 안정 버전을 지정합니다.

현재 SDK와 라이브러리 호환성을 확인한 뒤 적용해야 합니다.

WorkManager는 일반적인 설정에서는 자동으로 초기화됩니다.

별도의 초기화 설정이 필요한 경우에는 공식 문서의 사용자 정의 초기화 방법을 확인해야 합니다.

5. CoroutineWorker 구현하기

Kotlin Coroutine을 사용하는 프로젝트에서는 CoroutineWorker를 활용할 수 있습니다.

예를 들어 서버에서 조류 데이터를 받아 SQLite에 저장하는 작업을 구현한다고 가정하겠습니다.

class BirdSyncWorker(
    appContext: Context,
    workerParams: WorkerParameters
) : CoroutineWorker(appContext, workerParams) {

    override suspend fun doWork(): Result {

        return try {

            withContext(Dispatchers.IO) {
                syncBirdData()
            }

            Result.success()

        } catch (e: CancellationException) {
            throw e

        } catch (e: IOException) {
            Result.retry()

        } catch (e: Exception) {
            Log.e(
                "BirdSyncWorker",
                "Sync failed",
                e
            )

            Result.failure()
        }
    }

    private suspend fun syncBirdData() {
        // 서버 요청 및 SQLite 저장 구현
    }
}

doWork()는 WorkManager가 실행하는 작업의 진입점입니다.

결과는 다음 세 가지로 구분합니다.

모든 오류를 무조건 재시도하면 안 됩니다.

예를 들어 네트워크 일시 장애는 재시도할 수 있지만, 잘못된 데이터 형식이나 인증 권한 문제는 별도 처리가 필요할 수 있습니다.

6. WorkManager에서 Repository 사용하기

실제 프로젝트에서는 Worker 내부에 모든 네트워크 및 SQLite 코드를 작성하기보다 Repository를 사용하는 것이 좋습니다.

WorkManager
     │
     ▼
BirdSyncWorker
     │
     ▼
BirdRepository
     │
     ├── Retrofit API
     │
     └── SQLiteOpenHelper

예를 들어 다음과 같이 구성할 수 있습니다.

class BirdRepository(
    private val api: BirdApi,
    private val dbHelper: BirdDatabaseHelper
) {

    suspend fun syncBirds() {

        val birds = api.getBirds()

        withContext(Dispatchers.IO) {
            saveBirdsToDatabase(birds)
        }
    }

    private fun saveBirdsToDatabase(
        birds: List<BirdDto>
    ) {
        // SQLite 트랜잭션으로 저장
    }
}

Worker에서는 Repository를 호출합니다.

override suspend fun doWork(): Result {

    return try {

        repository.syncBirds()

        Result.success()

    } catch (e: IOException) {
        Result.retry()

    } catch (e: Exception) {
        Result.failure()
    }
}

위 코드는 Repository를 주입받는 구조를 설명한 예시입니다.

실제로 사용하려면 WorkerFactory 또는 의존성 주입 프레임워크를 이용해 Repository를 생성·주입해야 합니다.

의존성 주입을 사용하지 않는 소규모 프로젝트라면 Application Context를 기반으로 Repository를 구성할 수도 있습니다.

7. 일회성 작업 예약하기

일회성 작업은 OneTimeWorkRequest를 사용합니다.

val workRequest =
    OneTimeWorkRequestBuilder<BirdSyncWorker>()
        .build()

WorkManager.getInstance(context)
    .enqueue(workRequest)

이 코드는 데이터 동기화 작업을 한 번 예약합니다.

단, enqueue()가 호출되었다고 작업이 즉시 실행된다는 의미는 아닙니다.

WorkManager는 시스템 상태와 제약 조건에 따라 적절한 시점에 작업을 실행합니다.

8. 네트워크 연결 조건 설정하기

서버와 통신하는 작업은 네트워크 연결이 필요합니다.

WorkManager에서는 제약 조건을 설정할 수 있습니다.

val constraints = Constraints.Builder()
    .setRequiredNetworkType(
        NetworkType.CONNECTED
    )
    .build()

val request =
    OneTimeWorkRequestBuilder<BirdSyncWorker>()
        .setConstraints(constraints)
        .build()

WorkManager.getInstance(context)
    .enqueue(request)

이렇게 하면 네트워크 연결 조건이 충족될 때 작업을 실행할 수 있습니다.

다만 NetworkType.CONNECTED가 인터넷 서버에 실제로 접근할 수 있음을 완벽하게 보장하지는 않습니다.

서버 장애, DNS 문제, 인증 오류 등은 별도로 처리해야 합니다.

9. 중복 작업 예약 방지하기

사용자가 새로고침 버튼을 여러 번 누르면 동일한 동기화 작업이 중복 예약될 수 있습니다.

이 문제를 줄이려면 Unique Work를 사용할 수 있습니다.

WorkManager.getInstance(context)
    .enqueueUniqueWork(
        "bird_sync",
        ExistingWorkPolicy.KEEP,
        request
    )

ExistingWorkPolicy.KEEP는 같은 이름의 미완료 작업이 존재하면 기존 작업을 유지합니다.

다른 정책도 있습니다.

단순한 데이터 동기화에서는 KEEP 또는 REPLACE를 고려할 수 있습니다.

하지만 어떤 정책이 적절한지는 작업의 목적에 따라 달라집니다.

10. 주기적 데이터 동기화 구현

일정 주기로 데이터를 업데이트하려면 PeriodicWorkRequest를 사용할 수 있습니다.

val periodicRequest =
    PeriodicWorkRequestBuilder<BirdSyncWorker>(
        6,
        TimeUnit.HOURS
    )
        .setConstraints(constraints)
        .build()

WorkManager.getInstance(context)
    .enqueueUniquePeriodicWork(
        "periodic_bird_sync",
        ExistingPeriodicWorkPolicy.KEEP,
        periodicRequest
    )

이 예제는 약 6시간 간격의 주기적 동기화를 예약합니다.

하지만 정확히 6시간마다 실행된다고 보장할 수는 없습니다.

WorkManager의 주기적 작업은 최소 반복 간격이 15분이며, 실제 실행 시점은 시스템에 의해 조정될 수 있습니다.

따라서 정해진 시각에 정확히 실행해야 하는 기능에는 적합하지 않습니다.

11. WorkManager 재시도 정책 설정

네트워크 작업은 일시적인 오류로 실패할 수 있습니다.

WorkManager에서는 백오프(Backoff) 정책을 설정할 수 있습니다.

val request =
    OneTimeWorkRequestBuilder<BirdSyncWorker>()
        .setBackoffCriteria(
            BackoffPolicy.EXPONENTIAL,
            30,
            TimeUnit.SECONDS
        )
        .build()

이 예제는 지수 백오프 정책을 사용합니다.

작업이 실패하고 Result.retry()를 반환하면 WorkManager가 재시도를 예약할 수 있습니다.

재시도 간격은 시스템 상태와 WorkManager 정책에 따라 달라질 수 있습니다.

또한 무한 재시도가 적절하지 않은 작업이라면 runAttemptCount를 확인해 제한할 수 있습니다.

if (runAttemptCount >= 5) {
    return Result.failure()
}

단, 재시도 횟수 제한은 작업의 중요도와 오류 유형에 맞춰 결정해야 합니다.

12. 작업 상태를 LiveData로 관찰하기

WorkManager는 작업 상태를 관찰할 수 있습니다.

val workManager =
    WorkManager.getInstance(requireContext())

workManager
    .getWorkInfosForUniqueWorkLiveData("bird_sync")
    .observe(viewLifecycleOwner) { workInfos ->

        val workInfo = workInfos.firstOrNull()
            ?: return@observe

        when (workInfo.state) {
            WorkInfo.State.ENQUEUED -> {
                // 예약됨
            }

            WorkInfo.State.RUNNING -> {
                // 실행 중
            }

            WorkInfo.State.SUCCEEDED -> {
                // 완료
            }

            WorkInfo.State.FAILED -> {
                // 실패
            }

            WorkInfo.State.CANCELLED -> {
                // 취소됨
            }

            WorkInfo.State.BLOCKED -> {
                // 선행 작업 대기
            }
        }
    }

이 코드는 고유 작업 이름에 해당하는 WorkInfo 목록을 관찰하는 예시입니다.

여러 작업 기록이 반환될 수 있으므로 실제 서비스에서는 현재 관리할 작업을 ID나 상태 기준으로 명확하게 선택해야 합니다.

13. Worker에서 진행률 전달하기

파일 다운로드나 데이터 동기화처럼 시간이 오래 걸리는 작업에서는 진행률을 표시하고 싶을 수 있습니다.

CoroutineWorker에서는 setProgress()를 사용할 수 있습니다.

override suspend fun doWork(): Result {

    for (progress in 0..100 step 10) {

        if (isStopped) {
            return Result.failure()
        }

        setProgress(
            workDataOf("progress" to progress)
        )

        delay(300)
    }

    return Result.success()
}

위 코드는 진행률 전달 구조를 보여주기 위한 예시이며 실제 다운로드를 수행하지는 않습니다.

UI에서는 WorkInfo의 progress 데이터를 읽을 수 있습니다.

val progress =
    workInfo.progress.getInt("progress", 0)

다만 WorkManager의 진행률 정보는 작업 실행 중 상태 전달을 위한 것이며, 대량의 데이터를 저장하는 용도로 사용하면 안 됩니다.

14. WorkManager와 SQLite 동기화

SQLite를 직접 사용하는 앱에서는 Worker가 백그라운드에서 데이터베이스를 갱신하는 구조를 만들 수 있습니다.

예를 들어 다음과 같은 테이블이 있다고 가정하겠습니다.

CREATE TABLE korean_birds (
    KTSN INTEGER PRIMARY KEY,
    Species TEXT,
    SpeciesKor TEXT
);

서버에서 최신 조류 데이터를 가져온 뒤 SQLite에 반영할 수 있습니다.

fun saveBirds(
    db: SQLiteDatabase,
    birds: List<BirdDto>
) {
    db.beginTransaction()

    try {
        for (bird in birds) {

            val values = ContentValues().apply {
                put("KTSN", bird.ktsn)
                put("Species", bird.species)
                put("SpeciesKor", bird.speciesKor)
            }

            db.insertWithOnConflict(
                "korean_birds",
                null,
                values,
                SQLiteDatabase.CONFLICT_REPLACE
            )
        }

        db.setTransactionSuccessful()

    } finally {
        db.endTransaction()
    }
}

이 코드는 단순한 데이터 반영 예시입니다.

실제 서비스에서는 다음 사항을 추가로 고려해야 합니다.

• 서버 데이터의 버전 관리

• 다운로드 중 오류 처리

• 데이터 무결성 확인

• 기존 사용자 메모와 좋아요 데이터 보호

• 동기화 중 중복 실행 방지

• 대량 데이터 처리 시 트랜잭션 범위 조절

특히 앱에 내장된 도감 데이터와 사용자 메모를 같은 DB에 저장하는 경우에는 업데이트 과정에서 사용자 데이터를 삭제하지 않도록 주의해야 합니다.

15. WorkManager가 모든 작업에 적합한 것은 아니다

WorkManager는 지속성이 필요한 작업에 적합하지만 모든 백그라운드 작업을 WorkManager로 처리할 필요는 없습니다.

예를 들어 사용자가 검색 버튼을 눌렀을 때 SQLite에서 결과를 조회하는 작업은 일반적인 Coroutine이 더 적절합니다.

viewModelScope.launch {

    val result = withContext(Dispatchers.IO) {
        repository.searchBirds(keyword)
    }

    _searchResult.value = result
}

이 작업은 화면과 직접 연결되어 있으며 사용자가 즉시 결과를 확인해야 합니다.

WorkManager에 예약하면 실행 시점을 예측하기 어려워 검색 화면의 응답성이 떨어질 수 있습니다.

따라서 즉각적인 UI 작업과 지속성이 필요한 예약 작업을 구분해야 합니다.

16. Foreground Service란?

Foreground Service는 사용자에게 인지되는 진행 중 작업을 실행할 때 사용하는 Android 서비스입니다.

일반적으로 지속적인 알림을 통해 작업이 진행 중임을 사용자에게 알려야 합니다.

대표적인 사례는 다음과 같습니다.

• 사용자에게 표시되는 위치 추적

• 미디어 재생

• 연결된 기기와의 지속적인 통신

• 특정 조건에서 허용되는 장시간 데이터 처리

Foreground Service는 일반적인 백그라운드 서비스보다 실행 우선순위가 높지만, 무제한 실행을 보장하는 기능은 아닙니다.

Android 버전과 targetSdk에 따라 시작 제한, 서비스 유형, 권한, 실행 시간 제한 등이 적용될 수 있습니다.

17. Foreground Service의 기본 구조

Foreground Service를 구현하려면 Service 클래스를 작성합니다.

class TrackingService : Service() {

    override fun onBind(intent: Intent?): IBinder? {
        return null
    }

    override fun onStartCommand(
        intent: Intent?,
        flags: Int,
        startId: Int
    ): Int {

        // 서비스 유형에 맞는 알림 생성 및
        // startForeground() 호출 필요

        return START_NOT_STICKY
    }
}

위 코드는 서비스의 기본 구조만 보여줍니다.

실제로 실행 가능한 Foreground Service를 구현하려면 다음 작업이 추가로 필요합니다.

• NotificationChannel 생성

• 진행 중 알림 생성

• startForeground() 호출

• 서비스 유형 지정

• 필요한 권한 선언

• Android 버전별 시작 제한 대응

• 작업 종료 시 서비스 정리

특히 Android 14 이상을 대상으로 하는 앱에서는 Foreground Service 유형과 관련 권한 요구사항을 정확하게 확인해야 합니다.

Android 15 이상에서는 일부 서비스 유형에 실행 시간 제한도 적용됩니다.

따라서 단순히 Service를 선언하는 것만으로 백그라운드 작업을 자유롭게 실행할 수 있다고 생각하면 안 됩니다.

18. WorkManager와 Foreground Service 선택 기준

어떤 기술을 사용할지 고민된다면 작업의 성격을 먼저 확인하는 것이 좋습니다.

특히 대용량 파일 다운로드는 단순히 Foreground Service를 선택하기보다 Android 버전과 작업 유형에 맞는 전송 API를 검토하는 것이 좋습니다.

Android에서는 사용자 시작 데이터 전송 작업을 위한 별도 JobScheduler API도 제공합니다.

19. 앱이 종료되어도 WorkManager가 실행될까?

WorkManager를 사용할 때 가장 많이 궁금해하는 부분입니다.

다음 상황을 구분해야 합니다.

앱 화면을 닫은 경우

Activity가 종료되더라도 WorkManager에 예약된 작업은 시스템 스케줄에 따라 실행될 수 있습니다.

앱 프로세스가 시스템에 의해 종료된 경우

WorkManager는 지속성 있는 작업 정보를 저장하므로, 조건이 충족되면 작업을 다시 실행할 수 있습니다.

사용자가 앱을 강제 종료한 경우

사용자가 설정에서 앱을 강제 종료한 경우에는 Android의 강제 종료 정책에 따라 작업 실행이 제한될 수 있습니다.

이 경우 WorkManager가 즉시 다시 실행된다고 보장할 수 없습니다.

기기를 재부팅한 경우

WorkManager는 일반적으로 재부팅 이후에도 예약된 작업을 복구하도록 설계되어 있습니다.

다만 기기 상태, 앱 상태, 시스템 제한에 따라 실제 실행 시점은 달라질 수 있습니다.

20. WorkManager 작업 중복 실행과 데이터 무결성

WorkManager는 실패한 작업을 다시 실행할 수 있습니다.

따라서 Worker는 가능한 한 같은 작업이 여러 번 실행되어도 데이터가 손상되지 않는 구조로 설계해야 합니다.

예를 들어 다음과 같은 코드는 주의해야 합니다.

db.execSQL(
    "UPDATE user_points SET points = points + 10"
)

같은 작업이 재실행되면 포인트가 중복으로 증가할 수 있습니다.

반면 서버에서 내려받은 최신 상태를 특정 키 기준으로 저장하는 작업은 중복 실행에 더 안전하게 설계할 수 있습니다.

INSERT INTO korean_birds (
    KTSN,
    Species,
    SpeciesKor
)
VALUES (?, ?, ?)
ON CONFLICT(KTSN) DO UPDATE SET
    Species = excluded.Species,
    SpeciesKor = excluded.SpeciesKor;

이 예시는 동일한 KTSN에 대해 데이터를 갱신하는 UPSERT 방식입니다.

다만 실제 프로젝트의 SQLite 버전과 스키마를 확인해야 합니다.

특히 사용자 데이터가 포함된 테이블에서는 무조건 REPLACE를 사용하는 것보다 명시적인 UPDATE 또는 UPSERT가 더 적절할 수 있습니다.

21. WorkManager 테스트 방법

백그라운드 작업은 일반적인 화면 테스트보다 검증할 항목이 많습니다.

다음 시나리오를 확인하는 것이 좋습니다.

1. 네트워크가 연결된 상태에서 작업 실행

2. 네트워크가 없는 상태에서 작업 예약

3. 네트워크 복구 후 작업 실행 여부 확인

4. 앱 화면 종료 후 작업 상태 확인

5. 작업 실행 중 앱 프로세스 종료

6. 작업 실패 후 재시도 확인

7. 동일한 작업 중복 예약

8. 데이터베이스 저장 중 오류 발생

9. 기기 재부팅 후 예약 작업 확인

10. Doze 모드 및 배터리 제한 환경 확인

WorkManager 테스트에는 work-testing 라이브러리를 사용할 수 있습니다.

testImplementation(
    "androidx.work:work-testing:<version>"
)

실제 서비스에서는 에뮬레이터뿐 아니라 제조사별 Android 기기에서도 테스트하는 것이 좋습니다.

22. 백그라운드 작업 구현 체크리스트

• 작업이 화면 생명주기에 종속되는지 확인

• 지속성이 필요한 작업은 WorkManager 검토

• 즉시 응답해야 하는 UI 작업은 Coroutine 사용

• WorkManager의 실행 시점이 정확하지 않음을 고려

• 네트워크 제약 조건 설정

• Unique Work로 중복 예약 방지

• 재시도 가능한 오류와 불가능한 오류 구분

• Worker 취소 및 중단 처리

• SQLite 작업의 데이터 무결성 확인

• 동일 작업 재실행에 안전한 구조 설계

• Foreground Service 유형 및 권한 확인

• Android 버전별 백그라운드 제한 확인

• 배터리 사용량과 네트워크 사용량 검토

• 앱 종료·프로세스 종료·재부팅 상황 테스트

23. 마무리

Android 앱의 백그라운드 작업을 구현할 때는 Coroutine, WorkManager, Foreground Service의 역할을 정확하게 구분해야 합니다.

세 기술은 서로 대체하는 관계라기보다 작업의 목적에 따라 선택하는 도구입니다.

실무에서는 다음 기준을 추천합니다.

1. 화면에서 즉시 실행하고 결과를 표시해야 한다면 Coroutine을 사용합니다.

2. 앱 화면이 사라져도 나중에 완료해야 하는 작업이라면 WorkManager를 검토합니다.

3. 사용자가 인지하는 지속적인 작업이라면 적절한 Foreground Service 또는 전용 API를 검토합니다.

4. 주기적 작업은 정확한 실행 시간을 보장하지 않는다는 점을 고려합니다.

5. 데이터 동기화는 중복 실행과 재시도에 안전하도록 설계합니다.

특히 SQLite와 Retrofit을 사용하는 Android 앱에서는 Repository를 중심으로 데이터 처리 로직을 분리하면 화면 작업과 백그라운드 작업에서 같은 기능을 재사용하기 편리합니다.

백그라운드 작업의 핵심은 단순히 다른 스레드에서 실행하는 것이 아니라, 작업의 지속성·실행 조건·생명주기·재시도 정책을 함께 설계하는 것입니다.

참고 자료

• Android Developers — 백그라운드 작업 개요
  https://developer.android.com/develop/background-work/background-tasks

• Android Developers — WorkManager 시작하기
  https://developer.android.com/develop/background-work/background-tasks/persistent/getting-started

• Android Developers — WorkManager 작업 정의
  https://developer.android.com/develop/background-work/background-tasks/persistent/how-to/define-work

• Android Developers — WorkManager 작업 예약
  https://developer.android.com/develop/background-work/background-tasks/persistent/how-to/manage-work

• Android Developers — Foreground Service
  https://developer.android.com/develop/background-work/services/fgs

• Android Developers — Foreground Service 유형
  https://developer.android.com/develop/background-work/services/fgs/service-types

• Android Developers — 사용자 시작 데이터 전송 작업
  https://developer.android.com/develop/background-work/background-tasks/uidt

• Android Developers — Coroutine
  https://developer.android.com/kotlin/coroutines

태그: Android, Kotlin, WorkManager, CoroutineWorker, Coroutine, Foreground Service, 백그라운드 작업, SQLite, Retrofit, 데이터 동기화, Android Jetpack, MVVM, JobScheduler