모바일 개발에서 Background Thread: 개념, 작업 및 활용 방법

Background Thread란

Background Thread — 애플리케이션에서 Main Thread가 아니고 UI에 접근할 수 없는 모든 스레드입니다. 그 임무는 메인 스레드를 무거운 작업에서 해방시켜 인터페이스의 응답성을 유지하는 것입니다. 운영 체제는 백그라운드 스레드를 CPU 코어에 분산하여 여러 작업을 병렬로 실행할 수 있게 합니다. iOS는 GCD를 통해, Android는 Java Executors 풀을 통해 스레드 풀을 자동으로 관리합니다.

이벤트를 순차적으로(하나씩) 처리하는 Main Thread와 달리, 백그라운드 스레드는 CPU 코어 수에 의해서만 제한되어 병렬로 실행될 수 있습니다. 예를 들어, 8코어 장치에서는 최대 8개의 병렬 백그라운드 작업을 심각한 지연 없이 실행할 수 있습니다. 그러나 과도한 수의 스레드(수백 개)는 thread starvation — 코어 경쟁 및 컨텍스트 스위치 오버헤드 증가를 초래합니다.

Quality of Service(QoS) — iOS 메커니즘으로, 백그라운드 작업의 우선순위를 지정할 수 있습니다. 값: .userInteractive(가장 높음, 거의 Main Thread), .userInitiated(사용자가 결과를 기다림), .default(표준), .utility(사용자가 직접 기다리지 않음), .background(가장 낮음, 동기화 및 인덱싱용). Android에서는 Thread.setPriority()(1~10)가 이에 해당하지만, Android는 cgroups를 사용한 스레드 우선순위 그룹 관리도 사용합니다.

iOS의 Background Thread: GCD와 DispatchQueue.global

DispatchQueue.global(qos:) — iOS에서 백그라운드 큐를 얻는 주요 방법입니다. GCD(Grand Central Dispatch)는 자동으로 스레드 풀을 생성하고 코어에 작업을 분배합니다. DispatchQueue.global(qos: .background).async {} 호출은 가장 낮은 우선순위로 백그라운드 큐에 블록을 보냅니다. 결과가 즉시 필요한 작업에는 .userInitiated 또는 .utility를 사용하세요.

OperationQueue — GCD 위의 고수준 추상화로, 작업 간 의존성, 최대 동시 작업 수(maxConcurrentOperationCount) 및 우선순위를 설정할 수 있습니다. OperationQueue는 복잡한 멀티태스킹 체인(파일 다운로드→압축 풀기→캐시에 저장)에 유용합니다. 기본적으로 OperationQueue는 달리 지정되지 않는 한 백그라운드 스레드를 사용합니다.

import UIKit

class ImageDownloader {

    func downloadImagesSequentially() {
        let urls = ["https://example.com/1.png", "https://example.com/2.png"]

        // maxConcurrentOperationCount = 2인 OperationQueue
        let queue = OperationQueue()
        queue.maxConcurrentOperationCount = 2
        queue.qualityOfService = .utility

        for urlString in urls {
            queue.addOperation {
                guard let url = URL(string: urlString),
                      let data = try? Data(contentsOf: url)
                else { return }

                DispatchQueue.main.async {
                    print("로드됨: \(url.lastPathComponent)")
                }
            }
        }
    }

    // GCD: 다양한 QoS를 가진 글로벌 백그라운드 큐
    func backgroundTaskWithQoS() {
        DispatchQueue.global(qos: .userInitiated).async {
            // 높은 우선순위 — 사용자가 결과를 기다리고 있음
            let result = self.heavyComputation()
            DispatchQueue.main.async {
                self.showResult(result)
            }
        }
    }

    private func heavyComputation() -> String {
        Thread.sleep(forTimeInterval: 2) // 작업 시뮬레이션
        return "계산 결과"
    }

    private func showResult(_ result: String) {
        print("Result on Main: \(result)")
    }
}

예제에서 OperationQueue는 qualityOfService = .utility를 통한 백그라운드 QoS로 두 이미지를 병렬 로드합니다(maxConcurrentOperationCount = 2). GCD 메서드 backgroundTaskWithQoS는 사용자가 결과를 기다리는 작업에 .userInitiated로 글로벌 큐를 사용합니다. 두 접근 방식 모두 UI 업데이트를 위해 DispatchQueue.main으로 돌아와 종료됩니다 — 이는 iOS의 필수 요구사항입니다.

직렬 vs 동시 백그라운드 큐

GCD는 직렬(serial) 큐와 동시(concurrent) 큐의 두 가지 유형을 지원합니다. 직렬 큐는 작업을 하나씩 순차적으로 실행합니다 — 이는 잠금 없이 공유 리소스(파일, DB)에 접근하는 데 편리합니다. 동시 큐는 작업을 병렬로 실행하여 사용 가능한 코어에 분배합니다. DispatchQueue.global은 항상 동시 큐입니다. 직렬 큐를 만들려면 DispatchQueue(label: "com.app.queue")를 사용하세요.

Android의 Background Thread: Executors와 Dispatchers

Android는 백그라운드 스레드를 위해 여러 추상화 계층을 제공합니다. 클래식한 접근 방식은 java.util.concurrent.Executors.newFixedThreadPool(n) 또는 Executors.newCachedThreadPool()입니다. 현대적인 접근 방식은 Dispatchers.IO(I/O: 네트워크, 파일, DB)와 Dispatchers.Default(CPU 집약적 작업: 정렬, 이미지 처리)를 갖춘 Kotlin Coroutines입니다. WorkManager는 지연 및 보장된 백그라운드 작업용입니다.

HandlerThread — 자체 Looper(메시지 큐)를 가진 백그라운드 스레드를 생성하기 위한 Android 특화 클래스입니다. Executors와 달리 HandlerThread는 Handler를 통해 메시지와 Runnable을 보낼 수 있습니다. 큐잉이 필요한 작업(예: 순차적 DB 쓰기)에 사용됩니다. 사용 후에는 quit() 또는 quitSafely()를 호출하여 리소스를 해제해야 합니다.

// Android: Executors 및 Coroutines Dispatchers
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.withContext
import java.util.concurrent.Executors

class DataRepository {

    private val ioExecutor = Executors.newFixedThreadPool(4)

    // Executors를 통한 클래식 접근 방식
    fun loadDataLegacy(callback: (String) -> Unit) {
        ioExecutor.execute {
            val result = readFromFile()
            val handler = android.os.Handler(android.os.Looper.getMainLooper())
            handler.post { callback(result) }
        }
    }

    // Coroutines를 통한 현대적 접근 방식
    suspend fun loadDataCoroutines(): String {
        return withContext(Dispatchers.IO) {
            // 파일 작업 — 백그라운드 풀에서 실행 중
            readFromFile()
        }
        // 결과가 자동으로 Dispatchers.Main으로 반환됨
    }

    // Dispatchers.Default에서 CPU 집약적 작업
    suspend fun processImage(pixels: IntArray): IntArray {
        return withContext(Dispatchers.Default) {
            // 정렬, 필터링 — Default 풀에서 실행 중
            pixels.sortedArray()
        }
    }

    private fun readFromFile(): String {
        Thread.sleep(1000) // 파일 읽기 시뮬레이션
        return "file_content"
    }

    fun cleanup() {
        ioExecutor.shutdown()
    }
}

DataRepository 예제는 Android에서 백그라운드 스레드의 진화를 보여줍니다. 레거시 메서드 loadDataLegacy는 Main Thread로 돌아가기 위해 Handler와 함께 Executors.newFixedThreadPool(4)를 사용합니다. 현대적인 loadDataCoroutines는 withContext(Dispatchers.IO)를 사용합니다 — coroutine은 스레드를 차단하지 않고 실행 중에 일시 중단되며 자동으로 Main Thread에서 재개됩니다. Dispatchers.Default는 CPU 바운드 작업(정렬, 필터링, 데이터 변환)에 권장됩니다.

백그라운드 작업의 현대적 표준으로서의 Coroutines

Kotlin Coroutines — 단순한 스레드 작업 방식이 아니라 근본적으로 다른 모델입니다. 비동기 작업은 특정 스레드에 바인딩되지 않으며 차단 없이 일시 중단될 수 있습니다. 즉, 백그라운드에 있는 동안 coroutine은 스레드를 점유하지 않고 다른 작업을 위해 해제합니다. 일시 중단 메커니즘을 통해 4~8개 스레드 풀에서 thread starvation 없이 수십만 개의 동시 작업을 실행할 수 있습니다.

세 가지 주요 디스패처: Dispatchers.Main(UI, 1개 스레드), Dispatchers.IO(기본적으로 64개 스레드, 차단 작업용: 네트워크, 파일, DB), Dispatchers.Default(CPU 코어 수와 동일, 집약적 계산용). withContext를 통해 이를 결합하여 개발자는 콜백을 만들지 않고 스레드 간 전환을 수행합니다. withContext는 작업이 완료될 때까지 제어를 반환하지 않는 suspend 함수입니다.

// Coroutines: 백그라운드 작업 구성
import kotlinx.coroutines.async
import kotlinx.coroutines.coroutineScope
import kotlinx.coroutines.delay

suspend fun loadUserProfile(userId: String): UserProfile =
    coroutineScope {
        // 여러 소스에서 병렬 데이터 로드
        val user = async(Dispatchers.IO) { fetchUser(userId) }
        val posts = async(Dispatchers.IO) { fetchPosts(userId) }
        val avatar = async(Dispatchers.Default) {
            processAvatar(fetchAvatar(userId))
        }

        // await() — 모든 작업이 완료될 때까지 일시 중단
        UserProfile(
            user = user.await(),
            posts = posts.await(),
            avatar = avatar.await()
        )
    }

data class UserProfile(
    val user: String,
    val posts: List<String>,
    val avatar: ByteArray
)

suspend fun fetchUser(id: String): String { delay(300); return "User:$id" }
suspend fun fetchPosts(id: String): List<String> { delay(500); return listOf("Post1") }
suspend fun fetchAvatar(id: String): ByteArray { delay(200); return ByteArray(1024) }
suspend fun processAvatar(data: ByteArray): ByteArray { delay(100); return data }

loadUserProfile 함수는 async를 통해 세 개의 병렬 백그라운드 작업을 시작합니다. fetchUser와 fetchPosts는 IO 바운드(네트워크)로 Dispatchers.IO에서 실행됩니다. processAvatar는 CPU 바운드(이미지 처리)로 Dispatchers.Default에서 실행됩니다. await()는 모든 작업이 완료될 때까지 coroutine을 일시 중단합니다. 총 실행 시간은 세 작업의 최대 시간(fetchPosts의 경우 500ms)과 같으며 합계가 아닙니다. 이것이 순차 실행에 비해 coroutines의 핵심 이점입니다.

구조적 동시성: 누수 방지

Structured concurrency — 각 coroutine이 부모 범위를 가지며, 부모 취소 시 자식 coroutine이 자동으로 취소되는 원칙입니다. Android에서 lifecycleScope는 Activity가 소멸될 때 모든 coroutine을 취소합니다. viewModelScope는 ViewModel이 정리될 때 취소합니다. 이는 백그라운드 작업 누수를 방지합니다. 사용자가 화면을 닫으면 백그라운드에 있는 coroutine이 더 이상 필요하지 않은 데이터 로드를 계속하지 않습니다.

// Coroutines와 함께 WorkManager
import android.content.Context
import androidx.work.*
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.withContext

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

    override suspend fun doWork(): Result {
        // Dispatchers.Default에서 실행 중(기본값)
        return withContext(Dispatchers.IO) {
            try {
                syncDataToServer()
                Result.success()
            } catch (e: Exception) {
                if (runAttemptCount < 3) Result.retry() else Result.failure()
            }
        }
    }

    private suspend fun syncDataToServer() {
        // 동기화 시뮬레이션
        delay(1000)
    }
}

// 제약 조건으로 WorkManager 작업 시작
fun scheduleSync(context: Context) {
    val constraints = Constraints.Builder()
        .setRequiredNetworkType(NetworkType.CONNECTED)
        .setRequiresBatteryNotLow(true)
        .build()

    val syncWork = OneTimeWorkRequestBuilder<SyncWorker>()
        .setConstraints(constraints)
        .setBackoffCriteria(BackoffPolicy.EXPONENTIAL, 10, java.util.concurrent.TimeUnit.SECONDS)
        .build()

    WorkManager.getInstance(context).enqueue(syncWork)
}