안드로이드 앱 개발 시 마주하는 가장 치명적인 문제는 NullPointerException이나 IndexOutOfBoundsException이 아닙니다. 진정한 병목은 안드로이드 프레임워크 고유의 복잡한 Activity Lifecycle(생명 주기)과 이로 인한 메모리 누수(Memory Leak), 그리고 구성 변경(Configuration Change) 시 발생하는 데이터 소실입니다. 특히 비동기 작업(Network I/O, Database Query)이 완료되는 시점에 이미 UI 컨트롤러가 파괴(Destroyed)되었다면, 앱은 IllegalStateException을 던지며 비정상 종료되거나 좀비 메모리를 양산하게 됩니다.
Lifecycle Awareness와 ViewModel의 내부 메커니즘
기존의 안드로이드 개발 방식(MVC 패턴 등)에서는 Activity나 Fragment가 'God Object'가 되어 비즈니스 로직과 UI 로직을 모두 담당했습니다. 이는 화면 회전 시 Activity가 재생성될 때 네트워크 요청을 다시 보내야 하거나, 이미 GC(Garbage Collector) 대상이 되어야 할 Activity Context를 비동기 스레드가 참조하고 있어 메모리 해제가 불가능한 상황(Context Leak)을 초래합니다.
AAC의 핵심인 ViewModel은 이러한 수명 주기 문제의 근본적인 해결책을 제시합니다. ViewModel은 UI 컨트롤러(Activity/Fragment)와 데이터 소유권을 분리합니다. 내부적으로 ViewModelStore에 의해 관리되며, Activity가 구성 변경으로 인해 onDestroy() 호출 후 다시 onCreate() 되더라도 ViewModel 인스턴스는 메모리에 유지됩니다.
ViewModel 내부에서 View, Lifecycle, 또는 Activity Context를 참조해서는 안 됩니다. 이는 GC가 ViewModel보다 수명이 짧은 객체를 수거하지 못하게 하여 심각한 메모리 누수를 발생시킵니다. 시스템 리소스가 필요한 경우 AndroidViewModel을 사용하여 Application Context만을 참조해야 합니다.
// [Anti-Pattern] Activity 내에서 직접 비동기 처리 및 상태 관리
// 화면 회전 시 requestData()가 불필요하게 재호출되거나
// Activity가 종료된 후 UI 갱신 시도 시 크래시 발생 가능성 있음
class LegacyActivity : AppCompatActivity() {
private var data: String? = null
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
requestData()
}
private fun requestData() {
// 네트워크 요청 시뮬레이션
thread {
Thread.sleep(2000)
// 위험: Activity가 이미 파괴되었을 수 있음
runOnUiThread { updateUI() }
}
}
}LiveData와 StateFlow를 이용한 데이터 관찰
데이터의 변경 사항을 UI에 반영하기 위해 폴링(Polling)이나 콜백 지옥(Callback Hell)을 사용하는 것은 비효율적입니다. AAC의 LiveData는 관찰자 패턴(Observer Pattern)을 구현하되, 안드로이드의 생명 주기를 인식(Lifecycle-Aware)한다는 점에서 차별화됩니다. LiveData는 관찰자(Activity/Fragment)가 STARTED 또는 RESUMED 상태일 때만 데이터를 발행합니다. 즉, 백그라운드에 있는 Activity에 무리하게 프래그먼트 트랜잭션을 시도하여 발생하는 크래시를 원천 차단합니다.
최근에는 Kotlin Coroutines의 StateFlow나 SharedFlow가 LiveData를 대체하는 추세입니다. 이들은 안드로이드 플랫폼에 종속되지 않은 순수 Kotlin API이므로 Domain Layer에서도 사용이 가능하며, Clean Architecture 구현에 더 유리합니다. 다만, UI 레벨에서 수집(Collect)할 때는 lifecycleScope.launchWhenStarted 혹은 repeatOnLifecycle을 사용하여 LiveData와 동일한 안전장치를 마련해야 합니다.
// [Best Practice] ViewModel + LiveData (또는 StateFlow)
// 생명 주기를 인식하여 안전하게 데이터 전파
class UserViewModel : ViewModel() {
// 캡슐화: 외부에서는 읽기 전용(LiveData)으로만 접근 가능
private val _userData = MutableLiveData<User>()
val userData: LiveData<User> get() = _userData
fun loadUser(userId: String) {
viewModelScope.launch {
try {
// Repository 패턴을 통한 데이터 획득
val user = repository.getUser(userId)
_userData.value = user
} catch (e: Exception) {
// 에러 처리 로직
}
}
}
}Room Persistence Library: SQLite의 추상화
로컬 데이터베이스 접근 시 SQLiteOpenHelper를 직접 사용하는 것은 런타임 에러의 위험이 크고, 스키마 변경 시 마이그레이션 코드가 기하급수적으로 복잡해집니다. AAC의 Room 라이브러리는 SQLite의 추상 레이어를 제공하며, 컴파일 타임에 SQL 문법을 검증합니다.
Room의 가장 큰 장점은 비동기 쿼리 지원입니다. Main Thread(UI Thread)에서 디스크 I/O를 수행하면 ANR(Application Not Responding)이 발생할 수 있는데, Room은 기본적으로 Main Thread에서의 접근을 차단하여 개발자가 강제적으로 백그라운드 스레드나 Coroutines를 사용하도록 유도합니다. 또한, LiveData나 Flow를 반환 타입으로 지정하면 데이터베이스의 변경 사항이 자동으로 UI에 전파되는 Reactive Data Source를 구축할 수 있습니다.
| 기능 | Raw SQLite / Cursor | AAC Room |
|---|---|---|
| 쿼리 검증 | 런타임 (실행 시 에러 발생) | 컴파일 타임 (빌드 시 에러 검출) |
| 스레드 처리 | 개발자가 수동 관리 | Main Thread 접근 제한 정책 기본 적용 |
| 데이터 관찰 | ContentObserver 등 복잡한 구현 필요 | LiveData, Flow 반환 지원으로 자동 갱신 |
| 객체 매핑 | Cursor에서 수동으로 필드 추출 | Entity 객체로 자동 매핑 (ORM) |
관심사의 분리(Separation of Concerns)와 아키텍처
AAC 도입의 궁극적인 목표는 MVVM(Model-View-ViewModel) 패턴의 정착입니다. UI 컨트롤러(Activity/Fragment)는 단순히 데이터를 표시하고 사용자 입력을 받아 ViewModel로 전달하는 역할만 수행해야 합니다. 비즈니스 로직은 ViewModel에, 데이터 소싱 및 저장 로직은 Repository 레이어에 위임함으로써 코드의 결합도(Coupling)를 낮추고 응집도(Cohesion)를 높일 수 있습니다.
AAC를 활용해 관심사를 분리하면 단위 테스트(Unit Test) 작성이 매우 수월해집니다. ViewModel은 안드로이드 프레임워크에 대한 의존성이 거의 없기 때문에 JUnit을 통해 로직을 검증할 수 있으며, Repository는 Mocking을 통해 가짜 데이터를 주입하여 다양한 시나리오를 테스트할 수 있습니다.
결론적으로 안드로이드 아키텍처 컴포넌트는 단순한 라이브러리 모음이 아니라, 안드로이드 OS의 제약 사항을 우회하고 견고한 애플리케이션을 구축하기 위한 엔지니어링 표준입니다. 초기 학습 곡선은 존재하지만, 유지보수 비용 감소와 앱 안정성 확보라는 측면에서 도입 효과는 명확합니다.
Android Jetpack 아키텍처 가이드 바로가기
Post a Comment