모바일 애플리케이션에서의 Race Condition: 본질, 발생 원인 및 예방 방법

Race Condition이란?

Race Condition(경합 상태) — 멀티스레드 프로그램에서 작업의 정확성이 스레드의 예측 불가능한 실행 순서에 의존하는 오류입니다. 두 개 이상의 스레드가 동기화 없이 동시에 공유 리소스에 접근하면, 리소스의 최종 상태가 불확정적이 됩니다.

모바일 개발에서 Race Condition은 특히 위험합니다. 스레드가 다른 속도로 프로세서의 다른 코어에서 실행될 수 있기 때문입니다. 개발자는 어떤 스레드가 먼저 작업을 완료할지 제어할 수 없습니다 — 이는 운영 체제 스케줄러가 결정합니다. IBM의 연구(Concurrency Bugs in Android, 2022)에 따르면, Android 애플리케이션의 중요한 버그 중 약 23%가 경합 상태와 관련되어 있습니다.

Race Condition의 주요 특징은 비결정성입니다. 동일한 코드가 수천 번 오류 없이 작동하다가 갑자기 충돌할 수 있습니다. 이는 진단을 특히 어렵게 만듭니다. 버그는 특정 상황에서만 나타납니다 — CPU 부하, 활성 스레드 수 및 스케줄링 단계에 따라 다릅니다.

경합 상태가 발생하는 방식

비원자적 연산

Race Condition은 스레드가 비원자적 연산 — 여러 단계로 구성된 시퀀스로, 다른 스레드에 의해 중단될 수 있는 것을 실행할 때 발생합니다. 예를 들어, counter++ 증가 연산은 실제로 세 단계로 구성됩니다: 메모리에서 값 읽기, 1 증가, 다시 쓰기. 두 스레드가 이 단계들을 섞어서 실행하면 결과가 잘못됩니다.

동기화 부재

경합 상태의 주요 원인은 공유 데이터에 접근할 때 동기화 부재입니다. 한 스레드가 객체를 변경하고 다른 스레드가 동시에 그것을 읽으면, 읽기 결과는 예측 불가능합니다. Android에서는 애플리케이션 구성 요소(Activity, Service, BroadcastReceiver)가 다른 스레드에서 실행될 수 있기 때문에 이 문제가 더욱 악화됩니다.

코루틴의 잘못된 사용

Kotlin을 사용한 최신 Android 개발에서 Race Condition은 코루틴의 잘못된 사용으로 인해 자주 발생합니다. 두 코루틴이 동기화 없이 서로 다른 Dispatchers에서 공유 상태로 작업하면, 결과는 예측 불가능합니다. 이는 특히 공유 mutable 객체와 함께 Dispatchers.IO와 Dispatchers.Main을 결합할 때 자주 발생합니다.

Kotlin 코드에서의 Race Condition 예제

데이터 경합의 전형적인 예를 살펴보겠습니다 — 여러 스레드에서 카운터 증가입니다. 동기화가 없으면 연산이 서로 겹치기 때문에 최종 값이 예상보다 작아집니다.

class RaceCounter {
    private var counter = 0

    fun increment() {
        // 비원자적 연산 — 세 단계
        counter++  // 읽기, 증가, 쓰기
    }

    fun getCount(): Int = counter
}

fun main() = runBlocking {
    val rc = RaceCounter()
    val jobs = List(1000) {
        launch(Dispatchers.Default) {
            rc.increment()
        }
    }
    jobs.forEach { it.join() }
    println(rc.getCount())  // 예상 1000, 결과 ~997
}

이 예제에서는 1000개의 코루틴이 동시에 increment()를 호출합니다. counter++ 연산의 비원자성 때문에 최종 값이 1000이 되는 경우는 거의 없습니다. 실행할 때마다 다른 결과가 나옵니다 — Race Condition의 전형적인 증상입니다. 경합에 참여하는 스레드가 많을수록 예상 값에서 더 크게 벗어납니다.

해결 방법 — 원자적 유형 또는 잠금 사용입니다. Kotlin에서는 java.util.concurrent.atomic 패키지의 AtomicInteger가 적합합니다. 이는 읽기-수정-쓰기 연산이 프로세서 수준에서 단일 불가분 작업으로 실행되도록 보장합니다.

import java.util.concurrent.atomic.AtomicInteger

class SafeCounter {
    private val counter = AtomicInteger(0)

    fun increment() {
        counter.incrementAndGet()  // 원자적 연산
    }

    fun getCount(): Int = counter.get()
}

경합 상태의 유형

데이터 경합 (Data Race)

데이터 경합 — 가장 일반적인 Race Condition 유형입니다. 한 스레드가 변수에 데이터를 쓰고, 다른 스레드가 동기화 없이 동시에 같은 변수를 읽거나 쓸 때 발생합니다. Java Memory Model에서 이러한 동작은 정의되지 않은 것으로 간주됩니다 — 스레드는 CPU 수준의 캐싱으로 인해 최신 값이 아닌 값을 볼 수 있습니다.

Check-Then-Act

Check-Then-Act 패턴 — 스레드가 조건을 확인한 후 해당 확인에 기반하여 작업을 수행하는 상황입니다. 확인과 작업 사이에 다른 스레드가 상태를 변경할 수 있습니다. 전형적인 예: 컬렉션에 요소가 있는지 확인한 후 제거하는 것. Android에서는 SharedPreferences나 데이터베이스 작업 시 자주 발생합니다.

Read-Modify-Write

Read-Modify-Write — 스레드가 값을 읽고, 로컬 메모리에서 수정하고, 다시 쓰는 상황입니다. 읽기와 쓰기 사이에 다른 스레드가 원래 값을 변경하면, 수정 결과가 손실됩니다. 전형적인 예는 위의 Kotlin 코드에서 분석한 counter++ 연산입니다.

STM (Software Transactional Memory)

Software Transactional Memory(STM) — 공유 데이터에 대한 연산을 데이터베이스와 유사하게 트랜잭션에서 실행하는 접근 방식입니다. 두 트랜잭션이 충돌하면 하나가 롤백되고 재실행됩니다. JVM용 Kotlin에서는 명시적 잠금 없이 접근 충돌을 자동으로 처리하는 Multiverse STM 라이브러리를 사용할 수 있습니다. STM은 특히 Android에서 여러 상호 연결된 객체를 다룰 때 유용합니다.

Android UI에서의 씬 레이스

Race Condition의 특별한 범주 — Activity의 생명주기와 관련된 씬 레이스(thin races)입니다. 전형적인 시나리오: 백그라운드 스레드가 데이터 로딩을 완료했지만 Activity가 이미 소멸됨(화면 회전). 코루틴이 존재하지 않는 View를 업데이트하려고 시도하고 IllegalStateException으로 충돌합니다. 해결책 — viewModelScope 및 Lifecycle-aware 구성 요소를 사용하여 Lifecycle Owner가 소멸될 때 자동으로 코루틴을 취소합니다.

Race Condition 감지 방법

Race Condition 감지는 멀티스레드 애플리케이션 디버깅에서 가장 어려운 작업 중 하나입니다. 표준 테스트는 경합 상태를 거의 발견하지 못합니다. 특정 타이밍 일치에서만 나타나기 때문입니다. Google(Android Testing Guide, 2023)에 따르면, 약 70%의 Race Condition이 테스트 환경에서의 결정론적 실행 순서로 인해 단위 테스트에서 감지되지 않습니다.

주요 감지 방법에는 전문 도구가 포함됩니다. ThreadSanitizer(TSan) — Android NDK에 내장된 동적 분석기로, 모든 메모리 접근을 추적하고 동기화되지 않은 접근을 감지합니다. Java/Kotlin 코드의 경우, Google은 StrictMode와 함께 Android Studio Layout Inspector를 권장합니다. StrictMode는 백그라운드 스레드에서 UI 스레드로의 불법 접근을 가로챕니다.

또 다른 효과적인 접근 방식은 부하 상태에서 테스트를 반복 실행하는 스트레스 테스트입니다. JetBrains의 Lincheck 프레임워크는 JVM에서 동시 데이터 구조를 테스트하기 위해 특별히 설계되었습니다. 연산의 다양한 순열로 시나리오를 자동 생성하고 각 경우에 결과의 정확성을 검증합니다.

Race Condition 예방 방법

원자적 변수

원자적 변수(AtomicInteger, AtomicLong, AtomicReference) — 단일 연산의 데이터 경합을 제거하는 가장 쉬운 방법입니다. 이들은 프로세서의 저수준 CAS 명령(Compare-And-Swap)을 사용하여 잠금 없이 원자적으로 실행됩니다. 이는 낮은 경합 시나리오에서 최대 성능을 제공합니다.

잠금 및 Mutex

Mutex와 잠금 — 복잡한 연산 및 임계 구역에 적합한 고전적인 동기화 메커니즘입니다. Kotlin의 코루틴에서는 kotlinx.coroutines 라이브러리의 suspending Mutex를 사용하여 스레드를 차단하는 대신 일시 중단합니다. 이는 기존 잠금의 특징인 바쁜 대기를 피할 수 있습니다.

상태 격리

상태 격리 — 각 스레드가 데이터의 자체 복사본으로 작업하는 아키텍처 접근 방식입니다. 모바일 개발에서는 Actor 모델을 통해 구현되며, 각 액터가 자신의 상태를 소유하고 다른 액터와 메시지를 교환합니다. Kotlin Coroutines는 Channel과 SendChannel을 통해 Actor 구현을 제공하여 아키텍처 수준에서 Race Condition을 완전히 제거합니다.

추가 보호 수준 — Immutability: 공유 데이터가 원칙적으로 불변이면, 동기화 없이도 Race Condition이 불가능해집니다. Kotlin에서는 val 필드가 있는 data class와 kotlinx.collections.immutable의 컬렉션을 사용하여 스레드 간 게시 시 구조의 불변성을 보장합니다.