Monday, August 21, 2023

견고한 안드로이드 앱을 위한 아키텍처 컴포넌트 활용법
  /   No comments   

현대의 안드로이드 애플리케이션 개발은 단순히 기능을 구현하는 것을 넘어, 사용자의 다양한 상호작용과 예측 불가능한 시스템 이벤트에 안정적으로 대응해야 하는 복잡한 과제를 안고 있습니다. 화면 회전과 같은 간단한 구성 변경부터, 시스템에 의한 프로세스 종료, 비동기 데이터 처리, 그리고 복잡한 사용자 인터페이스 상태 관리에 이르기까지, 개발자는 수많은 함정을 피하며 견고하고 유지보수가 용이한 코드를 작성해야 합니다. 이러한 문제들을 해결하기 위해 Google은 안드로이드 아키텍처 컴포넌트(Android Architecture Components, AAC)라는 강력한 라이브러리 및 가이드라인 모음을 제시했습니다.

AAC는 단순히 유용한 도구의 집합이 아닙니다. 이는 안드로이드 앱 개발의 패러다임을 바꾸는 철학에 가깝습니다. 관심사의 분리(Separation of Concerns) 원칙을 기반으로, 테스트가 용이하고, 유지보수가 쉬우며, 확장 가능한 애플리케이션을 구축할 수 있도록 설계된 청사진을 제공합니다. AAC를 통해 개발자는 더 이상 안드로이드 프레임워크의 복잡한 생명주기(Lifecycle)를 수동으로 추적하며 발생하는 메모리 누수나 비정상 종료 문제로 골머리를 앓을 필요가 없습니다. 대신, 애플리케이션의 핵심 비즈니스 로직과 사용자 경험을 향상시키는 데 더 많은 시간을 할애할 수 있게 됩니다.

이 글에서는 안드로이드 아키텍처 컴포넌트의 핵심 요소들을 깊이 있게 탐구하고, 각 컴포넌트가 어떻게 유기적으로 결합하여 강력한 시너지를 내는지 실제 코드 예제와 함께 상세히 살펴볼 것입니다. ViewModel, LiveData, Room과 같은 기본적인 컴포넌트부터 Navigation, Paging, WorkManager에 이르기까지, AAC가 제공하는 풍부한 생태계를 통해 여러분의 안드로이드 앱을 한 단계 더 높은 수준으로 끌어올리는 여정을 시작하겠습니다.

모던 안드로이드 앱의 권장 아키텍처

AAC를 효과적으로 활용하기 위해서는 먼저 Google이 권장하는 앱 아키텍처에 대한 이해가 필요합니다. 이 아키텍처는 애플리케이션을 여러 개의 논리적인 계층(Layer)으로 분리하여 각 계층이 명확한 책임을 갖도록 합니다. 이는 코드의 재사용성을 높이고, 테스트를 용이하게 하며, 팀 단위의 협업을 원활하게 만듭니다.

일반적으로 권장되는 아키텍처는 다음과 같은 세 가지 주요 계층으로 구성됩니다.

  • UI 계층 (UI Layer): 화면에 데이터를 표시하고 사용자 상호작용을 처리하는 역할을 합니다. Activity, Fragment와 같은 UI 컨트롤러와 UI 상태를 관리하고 비즈니스 로직을 위임하는 ViewModel로 구성됩니다. 이 계층은 오직 UI 상태와 관련된 로직만을 다루어야 합니다.
  • 도메인 계층 (Domain Layer): 선택적 계층으로, UI 계층과 데이터 계층 사이의 복잡한 비즈니스 로직을 캡슐화합니다. 예를 들어, 여러 데이터 소스에서 가져온 데이터를 조합하거나 특정 비즈니스 규칙을 적용하는 로직이 여기에 해당합니다. 이 계층은 코드의 재사용성을 극대화하고 UI 계층의 부담을 줄여줍니다.
  • 데이터 계층 (Data Layer): 애플리케이션의 데이터 및 비즈니스 로직을 담당합니다. 일반적으로 Repository(저장소) 패턴을 사용하여 구현되며, 데이터 소스(네트워크, 로컬 데이터베이스 등)에 대한 모든 접근을 관리합니다. UI 계층은 데이터가 어디서 오는지 알 필요 없이 오직 Repository에만 데이터를 요청하면 됩니다. 이는 데이터 소스가 변경되더라도 다른 계층에 미치는 영향을 최소화하는 유연성을 제공합니다.

이러한 계층적 구조에서 AAC의 각 컴포넌트는 다음과 같이 자신의 위치에서 핵심적인 역할을 수행합니다.

  • ViewModel: UI 계층에 속하며, UI 상태를 저장하고 관리합니다.
  • LiveData / StateFlow: UI 계층과 데이터 계층 간의 데이터 흐름을 관찰 가능한(Observable) 형태로 만들어 줍니다.
  • Lifecycle: UI 컨트롤러(Activity, Fragment)의 생명주기를 다른 컴포넌트들이 안전하게 관찰하고 반응할 수 있도록 합니다.
  • Room: 데이터 계층에 속하며, 로컬 SQLite 데이터베이스를 쉽게 관리할 수 있는 추상화 계층을 제공합니다.
  • Data Binding: UI 계층에서 XML 레이아웃과 데이터 모델을 선언적으로 연결하여 보일러플레이트 코드를 줄여줍니다.
  • Navigation: UI 계층에서 프래그먼트 간의 이동 및 전환을 관리합니다.
  • Paging: 데이터 계층과 UI 계층에 걸쳐 대용량 데이터를 효율적으로 로드하고 표시하는 기능을 지원합니다.
  • WorkManager: 애플리케이션의 어느 계층에서든 필요할 수 있는 신뢰성 있는 백그라운드 작업을 관리합니다.

이제 각 컴포넌트가 구체적으로 어떤 역할을 하는지 자세히 살펴보겠습니다.

1. 생명주기 관리의 핵심: Lifecycle & ViewModel

안드로이드 개발에서 가장 다루기 까다로운 부분 중 하나는 바로 '생명주기(Lifecycle)'입니다. Activity나 Fragment는 생성되고, 시작되고, 활성화되고, 중지되고, 결국 소멸하는 복잡한 상태 변화를 겪습니다. 이러한 생명주기를 올바르게 처리하지 못하면 메모리 누수, NullPointerException 발생, 백그라운드에서의 불필요한 리소스 사용 등 심각한 문제로 이어질 수 있습니다.

LifecycleOwner와 LifecycleObserver

AAC는 `Lifecycle` 클래스를 통해 이러한 문제를 해결합니다. Activity와 Fragment는 `LifecycleOwner` 인터페이스를 구현하며, 자신의 생명주기 상태를 외부에 노출합니다. 다른 컴포넌트들은 `LifecycleObserver` 인터페이스를 구현하고 `LifecycleOwner`에 자신을 등록함으로써 생명주기 이벤트를 감지하고 이에 맞춰 안전하게 동작할 수 있습니다.

예를 들어, 위치 정보를 업데이트하는 클래스가 있다고 가정해 봅시다. 이 클래스는 화면이 활성화(Resumed) 상태일 때만 위치 업데이트를 시작하고, 화면이 중지(Paused)되면 업데이트를 중단해야 배터리를 효율적으로 사용할 수 있습니다. AAC 이전에는 `onResume()`과 `onPause()` 콜백 메서드에서 직접 로직을 호출해야 했지만, `DefaultLifecycleObserver`를 사용하면 다음과 같이 생명주기 관련 로직을 완벽하게 분리할 수 있습니다.


class MyLocationListener(
    private val context: Context,
    private val lifecycle: Lifecycle,
    private val callback: (Location) -> Unit
) : DefaultLifecycleObserver {

    private lateinit var fusedLocationClient: FusedLocationProviderClient

    init {
        lifecycle.addObserver(this)
    }

    override fun onResume(owner: LifecycleOwner) {
        super.onResume(owner)
        // 생명주기가 RESUMED 상태가 되면 위치 업데이트 시작
        startLocationUpdates()
    }

    override fun onPause(owner: LifecycleOwner) {
        super.onPause(owner)
        // 생명주기가 PAUSED 상태가 되면 위치 업데이트 중지
        stopLocationUpdates()
    }

    private fun startLocationUpdates() { /* ... */ }
    private fun stopLocationUpdates() { /* ... */ }
}

// Activity에서 사용
class MyActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // MyLocationListener는 Activity의 생명주기를 스스로 관찰하므로
        // onCreate에서 한 번만 초기화해주면 된다.
        MyLocationListener(this, lifecycle) { location ->
            // 위치 정보 업데이트
        }
    }
}

ViewModel: UI 상태의 안전한 보관소

화면 회전은 안드로이드 개발자에게 또 다른 골칫거리입니다. 화면이 회전되면 시스템은 기존 Activity 인스턴스를 파괴하고 새로운 인스턴스를 생성합니다. 이 과정에서 Activity가 가지고 있던 모든 상태 데이터는 소실됩니다. `onSaveInstanceState()`를 통해 데이터를 보존할 수 있지만, 복잡한 데이터를 다루기에는 번거롭고 제한적입니다.

`ViewModel`은 이러한 구성 변경(Configuration Change) 문제를 해결하기 위해 설계되었습니다. `ViewModel` 객체는 연관된 `Activity`나 `Fragment`가 구성 변경으로 인해 재생성되더라도 파괴되지 않고 그대로 유지됩니다. 따라서 UI에 필요한 데이터를 `ViewModel`에 저장하면, 화면 회전이 발생해도 데이터가 안전하게 보존됩니다.

`ViewModel`의 생명주기는 `LifecycleOwner`(Activity/Fragment)의 생명주기보다 깁니다. `LifecycleOwner`가 생성될 때 함께 생성되고, `LifecycleOwner`가 구성 변경으로 파괴되어도 살아남으며, 최종적으로 `LifecycleOwner`가 완전히 종료될 때(예: 사용자가 뒤로가기 버튼을 눌러 Activity를 닫을 때) `onCleared()` 콜백이 호출되면서 소멸합니다.

다음은 카운터 앱의 간단한 `ViewModel` 예제입니다.


// 1. ViewModel 클래스 생성
// ViewModel을 상속받아 UI 상태를 관리할 클래스를 정의합니다.
// 여기서는 count라는 Int 값을 LiveData로 관리합니다.
class CounterViewModel : ViewModel() {
    private val _count = MutableLiveData<Int>(0)
    val count: LiveData<Int> get() = _count

    fun increment() {
        _count.value = (_count.value ?: 0) + 1
    }

    fun decrement() {
        _count.value = (_count.value ?: 0) - 1
    }
}

// 2. Activity에서 ViewModel 사용
class MainActivity : AppCompatActivity() {

    // by viewModels() KTX(코틀린 확장 함수)를 사용하면 보일러플레이트를 줄일 수 있다.
    private val viewModel: CounterViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        val countTextView: TextView = findViewById(R.id.tv_count)
        val incrementButton: Button = findViewById(R.id.btn_increment)
        val decrementButton: Button = findViewById(R.id.btn_decrement)

        // ViewModel의 count LiveData를 관찰하여 UI 업데이트
        viewModel.count.observe(this, Observer { newCount ->
            countTextView.text = newCount.toString()
        })

        incrementButton.setOnClickListener {
            viewModel.increment()
        }

        decrementButton.setOnClickListener {
            viewModel.decrement()
        }
    }
}

이 코드에서 `by viewModels()`를 통해 `ViewModel` 인스턴스를 얻습니다. 이 `ViewModel`은 `MainActivity`가 화면 회전으로 재생성되어도 동일한 인스턴스가 유지되므로 `count` 값은 그대로 보존됩니다. 덕분에 개발자는 더 이상 상태 저장 및 복원 로직을 직접 구현할 필요가 없습니다.

2. 반응형 UI를 위한 데이터 홀더: LiveData와 StateFlow

현대적인 UI는 정적이지 않습니다. 사용자 입력, 네트워크 응답, 데이터베이스 변경 등 다양한 이벤트에 따라 동적으로 변화해야 합니다. `LiveData`는 이러한 반응형 UI를 구축하기 위한 핵심 컴포넌트입니다.

LiveData의 특징: 생명주기 인식

`LiveData`는 관찰 가능한(Observable) 데이터 홀더 클래스입니다. 일반적인 Observable과 가장 큰 차이점은 생명주기를 인식한다는 것입니다. `LiveData`는 `LifecycleOwner`(Activity, Fragment 등)의 생명주기를 관찰하며, 다음과 같은 특징을 가집니다.

  • 안전한 UI 업데이트: `LiveData`는 관찰자가 `STARTED` 또는 `RESUMED` 상태일 때만 업데이트를 전달합니다. 따라서 Activity가 백그라운드에 있거나 종료된 상태에서 UI를 업데이트하려다 발생하는 `IllegalStateException`을 원천적으로 방지합니다.
  • 메모리 누수 방지: 관찰자의 생명주기가 `DESTROYED` 상태가 되면, `LiveData`는 자동으로 관찰자 등록을 해제합니다. 따라서 개발자가 직접 `onDestroy()`에서 리스너를 해제하는 코드를 작성할 필요가 없어 메모리 누수의 위험이 크게 줄어듭니다.
  • 최신 데이터 유지: 관찰자가 비활성 상태(예: 백그라운드)에서 다시 활성 상태로 돌아오면, `LiveData`는 그 즉시 최신 데이터를 전달받습니다.

앞선 `ViewModel` 예제에서 `viewModel.count.observe(this, ...)` 코드가 바로 `LiveData`를 사용하는 부분입니다. `observe` 메서드의 첫 번째 인자로 `this`(LifecycleOwner인 MainActivity)를 전달함으로써, `LiveData`는 `MainActivity`의 생명주기를 알게 되고 안전하게 동작할 수 있습니다.

LiveData의 확장: Transformations와 MediatorLiveData

`LiveData`는 `Transformations` 클래스를 통해 더욱 강력해집니다. `map`과 `switchMap`은 `LiveData` 체이닝을 가능하게 하여 복잡한 데이터 흐름을 간결하게 표현할 수 있도록 돕습니다.

  • Transformations.map(): 하나의 `LiveData` 소스를 다른 형태의 데이터로 변환합니다. 예를 들어 User 객체를 가진 `LiveData`를 User의 이름(String)을 가진 `LiveData`로 변환할 수 있습니다.
  • Transformations.switchMap(): 하나의 `LiveData`가 변경될 때, 그 값을 기반으로 새로운 `LiveData`를 반환해야 할 때 사용합니다. 예를 들어 사용자 ID `LiveData`가 변경될 때마다, 해당 ID로 데이터베이스에서 사용자 정보를 조회하는 새로운 `LiveData`를 생성하여 관찰할 수 있습니다.

class UserViewModel(private val repository: UserRepository) : ViewModel() {
    private val userIdLiveData = MutableLiveData<String>()

    // userIdLiveData가 변경될 때마다 repository.getUserById()를 호출하여
    // 새로운 LiveData<User>를 반환하고, 이를 관찰하게 된다.
    val user: LiveData<User> = Transformations.switchMap(userIdLiveData) { id ->
        repository.getUserById(id)
    }

    fun setUserId(id: String) {
        userIdLiveData.value = id
    }
}

또한, `MediatorLiveData`를 사용하면 여러 `LiveData` 소스를 하나로 병합하여 관찰할 수 있습니다. 예를 들어, 폼(Form)에서 이름 `LiveData`와 이메일 `LiveData`를 모두 관찰하다가, 둘 다 유효한 값을 가질 때만 '저장' 버튼을 활성화하는 `LiveData`를 만들 수 있습니다.

코루틴과의 통합: StateFlow

최근에는 코틀린 코루틴의 `StateFlow`가 `LiveData`의 대안으로 주목받고 있습니다. `StateFlow`는 `LiveData`와 유사하게 상태를 보유하고 관찰할 수 있는 데이터 홀더이지만, 코루틴의 `Flow`를 기반으로 하여 더 풍부한 연산자(operator)를 사용할 수 있고, 비동기 스트림 처리에 더 강력한 기능을 제공합니다. 안드로이드 Jetpack 라이브러리는 `StateFlow`를 UI에서 안전하게 수집(collect)할 수 있도록 `lifecycleScope.launchWhenStarted`나 `repeatOnLifecycle` API를 제공하여 `LiveData`와 유사한 생명주기 인식 동작을 구현할 수 있도록 지원합니다.

3. 로컬 데이터 영속성 처리: Room

대부분의 안드로이드 앱은 데이터를 로컬에 저장해야 합니다. 안드로이드는 기본적으로 SQLite 데이터베이스를 지원하지만, 네이티브 API는 사용하기 번거롭고, 많은 보일러플레이트 코드를 요구하며, 컴파일 시점에 SQL 쿼리의 유효성을 검사하지 않아 런타임 오류에 취약합니다.

`Room`은 SQLite 데이터베이스 위에 추상화 계층을 제공하는 ORM(Object-Relational Mapping) 라이브러리입니다. `Room`을 사용하면 개발자는 자바/코틀린 객체를 통해 데이터베이스와 상호작용할 수 있으며, 다음과 같은 강력한 이점을 얻을 수 있습니다.

  • 컴파일 시간 쿼리 검증: SQL 쿼리에 오류가 있을 경우, 앱이 실행되기 전인 컴파일 시점에 에러를 발견할 수 있어 안정성이 크게 향상됩니다.
  • 보일러플레이트 코드 감소: `Cursor`를 직접 다루거나 데이터베이스 연결을 열고 닫는 등의 반복적인 작업을 `Room`이 대신 처리해 줍니다.
  • 아키텍처 컴포넌트와의 통합: `LiveData`나 코루틴의 `Flow`를 반환 타입으로 직접 사용할 수 있어, 데이터베이스의 데이터가 변경될 때 UI가 자동으로 업데이트되는 반응형 앱을 쉽게 구현할 수 있습니다.
  • 손쉬운 마이그레이션: 데이터베이스 스키마가 변경될 때, `Migration` 클래스를 통해 데이터베이스를 안전하게 업그레이드하는 경로를 제공합니다.

Room의 3대 구성 요소

Room은 크게 세 가지 주요 컴포넌트로 구성됩니다.

  1. Entity (엔티티): 데이터베이스의 테이블을 나타내는 클래스입니다. `@Entity` 어노테이션을 사용하여 정의하며, 클래스의 필드(멤버 변수)가 테이블의 컬럼(열)에 해당합니다. `@PrimaryKey`, `@ColumnInfo` 등의 어노테이션으로 세부 속성을 지정할 수 있습니다.
  2. DAO (Data Access Object, 데이터 접근 객체): 데이터베이스에 접근하는 메서드를 포함하는 인터페이스 또는 추상 클래스입니다. `@Dao` 어노테이션을 사용하며, `@Query`, `@Insert`, `@Update`, `@Delete` 등의 어노테이션을 사용하여 실제 SQL 작업을 수행하는 메서드를 정의합니다.
  3. Database (데이터베이스): 데이터베이스 홀더 역할을 하는 추상 클래스입니다. `@Database` 어노테이션을 사용하여 정의하며, 앱에 속한 모든 엔티티 목록과 DAO에 접근할 수 있는 추상 메서드를 포함해야 합니다. 이 클래스를 통해 앱은 데이터베이스 인스턴스를 얻게 됩니다.

Room 사용 예제

다음은 사용자 정보를 저장하는 간단한 `Room` 데이터베이스 구현 예제입니다.


// 1. Entity 정의
@Entity(tableName = "users")
data class User(
    @PrimaryKey val id: Int,
    @ColumnInfo(name = "first_name") val firstName: String?,
    @ColumnInfo(name = "last_name") val lastName: String?
)

// 2. DAO 정의
@Dao
interface UserDao {
    @Query("SELECT * FROM users")
    fun getAll(): LiveData<List<User>> // LiveData를 반환하여 데이터 변경을 자동으로 감지

    @Query("SELECT * FROM users WHERE id IN (:userIds)")
    suspend fun loadAllByIds(userIds: IntArray): List<User> // 코루틴 지원

    @Insert(onConflict = OnConflictStrategy.REPLACE)
    suspend fun insertAll(vararg users: User)

    @Delete
    suspend fun delete(user: User)
}

// 3. Database 정의
@Database(entities = [User::class], version = 1)
abstract class AppDatabase : RoomDatabase() {
    abstract fun userDao(): UserDao

    companion object {
        @Volatile
        private var INSTANCE: AppDatabase? = null

        fun getDatabase(context: Context): AppDatabase {
            return INSTANCE ?: synchronized(this) {
                val instance = Room.databaseBuilder(
                    context.applicationContext,
                    AppDatabase::class.java,
                    "app_database"
                ).build()
                INSTANCE = instance
                instance
            }
        }
    }
}

// Repository에서 사용
class UserRepository(private val userDao: UserDao) {
    val allUsers: LiveData<List<User>> = userDao.getAll()

    suspend fun insert(user: User) {
        userDao.insertAll(user)
    }
}

이처럼 `Room`은 직관적인 어노테이션 기반의 API를 통해 복잡한 데이터베이스 작업을 매우 간단하게 만들어주며, 다른 AAC 컴포넌트와의 완벽한 조화를 통해 데이터 계층을 견고하게 구축할 수 있도록 돕습니다.

4. UI와 데이터의 선언적 연결: Data Binding

안드로이드 UI 개발에서 `findViewById()`는 오랫동안 사용되어 온 API지만, 많은 보일러플레이트 코드를 유발하고, 런타임에 `NullPointerException`을 발생시킬 수 있는 위험을 내포하고 있습니다. `Data Binding` 라이브러리는 이러한 문제를 해결하고, UI와 데이터를 선언적인 방식으로 연결하여 코드의 가독성과 유지보수성을 향상시킵니다.

`Data Binding`을 사용하면 XML 레이아웃 파일에 직접 변수를 선언하고, 뷰의 속성(예: `android:text`)에 해당 변수를 바인딩할 수 있습니다. 이를 통해 Activity나 Fragment에서 UI 위젯을 일일이 참조하여 데이터를 설정하는 코드를 제거할 수 있습니다.

Data Binding 설정 및 사용법

먼저, 모듈 수준의 `build.gradle` 파일에서 Data Binding을 활성화해야 합니다.


android {
    ...
    buildFeatures {
        dataBinding true
    }
}

그 다음, 레이아웃 XML 파일을 `` 태그로 감싸고, `` 태그 안에 바인딩할 데이터 변수를 선언합니다.


<?xml version="1.0" encoding="utf-8"?>
<layout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto">

    <data>
        <!-- 'user'라는 이름의 UserViewModel 타입 변수 선언 -->
        <variable
            name="userViewModel"
            type="com.example.myapp.UserViewModel" />
    </data>

    <LinearLayout
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:orientation="vertical">

        <!-- "@{}" 표현식을 사용하여 ViewModel의 데이터와 뷰 속성을 바인딩 -->
        <TextView
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:text="@{userViewModel.user.name}" />

        <TextView
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:text="@{userViewModel.user.email}" />

        <!-- 이벤트도 바인딩 가능 -->
        <Button
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:text="Update User"
            android:onClick="@{() -> userViewModel.onUpdateClick()}"/>

    </LinearLayout>
</layout>

마지막으로, Activity나 Fragment에서 바인딩 클래스를 사용하여 레이아웃을 인플레이트하고, 데이터 변수에 실제 `ViewModel` 인스턴스를 할당합니다.


class ProfileActivity : AppCompatActivity() {
    private val userViewModel: UserViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // 바인딩 클래스는 레이아웃 파일 이름을 기반으로 자동으로 생성된다 (e.g., activity_profile.xml -> ActivityProfileBinding)
        val binding: ActivityProfileBinding =
            DataBindingUtil.setContentView(this, R.layout.activity_profile)

        // XML에 선언된 userViewModel 변수에 실제 ViewModel 인스턴스를 할당
        binding.userViewModel = userViewModel

        // LiveData를 Data Binding과 함께 사용하려면 LifecycleOwner를 설정해야 한다.
        // 이를 통해 LiveData가 변경될 때 UI가 자동으로 갱신된다.
        binding.lifecycleOwner = this
    }
}

`binding.lifecycleOwner = this` 코드는 매우 중요합니다. 이 설정을 통해 `Data Binding` 라이브러리는 `LiveData`의 변경을 감지하고, 해당 `LiveData`를 사용하는 뷰를 자동으로 업데이트할 수 있게 됩니다. 이제 `ViewModel`의 `user` `LiveData`가 새로운 값으로 변경되면, 개발자가 별도의 코드를 작성하지 않아도 `TextView`의 내용이 자동으로 갱신됩니다. 이처럼 `Data Binding`은 `ViewModel` 및 `LiveData`와 결합될 때 가장 강력한 시너지를 발휘하며, UI 로직을 Activity/Fragment에서 완전히 분리하여 깔끔하고 테스트하기 쉬운 코드를 작성하도록 돕습니다.

5. 신뢰성 있는 백그라운드 작업 관리: WorkManager

안드로이드에서 백그라운드 작업은 필수적이지만, 관리하기는 매우 까다롭습니다. 네트워크 상태, 배터리 잔량, 기기 유휴 상태 등 다양한 조건을 고려해야 하며, 앱이 종료되거나 기기가 재부팅되어도 작업이 반드시 실행되어야 하는 경우도 있습니다. 과거에는 `AlarmManager`, `JobScheduler`, `FirebaseJobDispatcher` 등 다양한 API가 있었지만, 파편화되어 있고 사용법이 복잡했습니다.

`WorkManager`는 이러한 문제를 해결하기 위해 등장한 통합 솔루션입니다. `WorkManager`는 지연 가능하고(deferrable) 신뢰성이 보장되는(guaranteed) 비동기 작업을 쉽게 예약하고 관리할 수 있도록 설계되었습니다. `WorkManager`의 주요 특징은 다음과 같습니다.

  • 하위 호환성: API 레벨 14까지 지원하며, 내부적으로 기기 버전에 맞는 최적의 API(`JobScheduler` 또는 `BroadcastReceiver` + `AlarmManager`)를 자동으로 선택하여 사용합니다.
  • 제약 조건(Constraints) 설정: 'Wi-Fi에 연결되었을 때만', '기기가 충전 중일 때만' 등 다양한 실행 제약 조건을 쉽게 설정할 수 있습니다.
  • 신뢰성 보장: 앱이 종료되거나 기기가 재부팅되어도 예약된 작업은 결국 실행됨을 보장합니다.
  • 유연한 스케줄링: 일회성 작업(`OneTimeWorkRequest`)과 주기적 작업(`PeriodicWorkRequest`)을 모두 지원합니다.
  • 작업 체이닝(Chaining): 여러 작업을 순차적 또는 병렬적으로 연결하여 복잡한 워크플로우를 구성할 수 있습니다. (예: 이미지 다운로드 -> 압축 -> 서버 업로드)
  • 작업 상태 관찰: `LiveData`를 통해 작업의 현재 상태(ENQUEUED, RUNNING, SUCCEEDED, FAILED 등)를 쉽게 추적할 수 있습니다.

WorkManager 사용 예제

다음은 사용자의 프로필 이미지를 압축하여 서버에 업로드하는 백그라운드 작업을 `WorkManager`로 구현하는 예제입니다.


// 1. Worker 클래스 정의: 실제 작업 로직을 구현
class UploadWorker(appContext: Context, workerParams: WorkerParameters)
    : CoroutineWorker(appContext, workerParams) {

    override suspend fun doWork(): Result {
        // 입력 데이터 받기
        val imageUri = inputData.getString("IMAGE_URI") ?: return Result.failure()

        return try {
            // 1. 이미지 압축 (가상 로직)
            val compressedFile = compressImage(imageUri)
            // 2. 서버에 업로드 (가상 로직)
            val response = uploadToServer(compressedFile)

            if (response.isSuccessful) {
                // 성공 시 출력 데이터 설정
                val outputData = workDataOf("SERVER_URL" to response.body()?.url)
                Result.success(outputData)
            } else {
                Result.retry() // 일시적 실패 시 재시도 요청
            }
        } catch (e: Exception) {
            Result.failure()
        }
    }
}

// 2. 작업 요청 생성 및 실행
fun scheduleUpload(context: Context, imageUri: String) {
    // 실행 제약 조건 설정: 네트워크에 연결되어 있을 때만 실행
    val constraints = Constraints.Builder()
        .setRequiredNetworkType(NetworkType.CONNECTED)
        .build()

    // Worker에게 전달할 입력 데이터 생성
    val inputData = workDataOf("IMAGE_URI" to imageUri)

    // 일회성 작업 요청 생성
    val uploadWorkRequest = OneTimeWorkRequestBuilder<UploadWorker>()
        .setConstraints(constraints)
        .setInputData(inputData)
        .setBackoffCriteria( // 재시도 정책 설정
            BackoffPolicy.LINEAR,
            OneTimeWorkRequest.MIN_BACKOFF_MILLIS,
            TimeUnit.MILLISECONDS
        )
        .build()

    // WorkManager에 작업 등록
    WorkManager.getInstance(context).enqueue(uploadWorkRequest)
}

`WorkManager`는 이처럼 복잡한 백그라운드 작업의 요구사항을 간단하고 선언적인 코드로 처리할 수 있게 해줍니다. 이를 통해 개발자는 배터리 수명과 시스템 상태를 고려하는 안정적인 앱을 더 쉽게 만들 수 있습니다.

6. 그 외 강력한 아키텍처 컴포넌트들

지금까지 살펴본 핵심 컴포넌트 외에도 AAC는 현대적인 안드로이드 앱 개발을 지원하는 다양한 라이브러리를 제공합니다.

Navigation: 단일 액티비티 아키텍처의 완성

과거 안드로이드 앱은 여러 `Activity`를 사용하여 화면을 구성하는 것이 일반적이었습니다. 하지만 이는 화면 간 데이터 전달이 복잡하고, 딥링크(Deep Link) 구현이 어려우며, 화면 전환 애니메이션을 일관성 있게 관리하기 힘든 단점이 있었습니다.

`Navigation` 컴포넌트는 단일 `Activity` 내에서 여러 `Fragment`를 사용하여 UI를 구성하는 'Single-Activity Architecture'를 쉽게 구현할 수 있도록 돕습니다. 주요 기능은 다음과 같습니다.

  • 네비게이션 그래프(Navigation Graph): 앱의 모든 화면(Fragment)과 화면 간의 이동 경로(Action)를 XML 그래프로 시각화하여 관리합니다.
  • 안전한 인수 전달(Safe Args): 화면 간에 데이터를 전달할 때 타입 안정성을 보장하고 보일러플레이트 코드를 줄여주는 Gradle 플러그인을 제공합니다.
  • 딥링크 처리: Manifest 파일 수정 없이 네비게이션 그래프에 직접 딥링크를 정의하여 특정 화면으로 바로 이동할 수 있습니다.
  • 공통 UI 패턴 지원: Navigation Drawer, Bottom Navigation View 등 일반적인 네비게이션 UI 패턴을 쉽게 통합할 수 있습니다.

Paging: 대용량 데이터의 효율적인 로딩

소셜 미디어 피드나 뉴스 목록처럼 끝없이 스크롤되는 데이터를 표시해야 할 때, 모든 데이터를 한 번에 메모리에 로드하는 것은 비효율적이며 `OutOfMemoryError`를 유발할 수 있습니다. `Paging` 라이브러리는 네트워크 또는 데이터베이스로부터 데이터를 작은 단위(페이지)로 점진적으로 로드하여 `RecyclerView`에 표시하는 과정을 단순화합니다.

Paging 3 라이브러리는 코틀린과 코루틴을 기반으로 재설계되어, `PagingSource` (데이터 로딩 정의)와 `PagingDataAdapter` (`RecyclerView.Adapter`의 페이징 지원 버전)를 통해 데이터 로딩, 에러 처리, 로딩 상태 표시(로딩 스피너, 재시도 버튼 등)를 매우 쉽게 구현할 수 있도록 지원합니다.

결론: AAC와 함께하는 미래 지향적 앱 개발

안드로이드 아키텍처 컴포넌트(AAC)는 안드로이드 개발의 복잡성을 줄이고, 개발자가 더 나은 품질의 애플리케이션을 더 빠르게 구축할 수 있도록 돕는 강력한 도구 모음입니다. AAC는 단순히 라이브러리의 집합을 넘어, Google이 공식적으로 권장하는 모범 사례이자 설계 철학입니다.

생명주기를 인식하는 `ViewModel`과 `LiveData`, 보일러플레이트를 제거하는 `Room`과 `Data Binding`, 복잡한 네비게이션과 백그라운드 작업을 단순화하는 `Navigation`과 `WorkManager`에 이르기까지, AAC의 각 컴포넌트는 서로 유기적으로 결합하여 시너지를 발휘합니다. 이러한 컴포넌트를 기반으로 권장 아키텍처를 따르면, 자연스럽게 관심사가 분리되고, 테스트가 용이하며, 유지보수가 쉬운 견고한 애플리케이션을 만들 수 있습니다.

물론 AAC가 모든 문제의 유일한 해결책은 아닙니다. 하지만 안드로이드 생태계의 파편화와 복잡성 속에서 AAC는 개발자에게 명확한 방향을 제시하는 등대와 같은 역할을 합니다. 오늘 소개된 개념과 예제를 바탕으로 여러분의 프로젝트에 AAC를 적극적으로 도입하여, 안정적이고 확장 가능한 고품질 안드로이드 앱을 만들어 보시길 바랍니다.


0 개의 댓글:

Post a Comment