들어가며
지난 글에서 Jetpack이 라이브러리 모음이라는 것까지 정리했다. 이번엔 그 안에 실제로 어떤 라이브러리들이 있는지, 그리고 그중 가장 먼저 마주치게 되는 ViewModel, LiveData, Room을 조금 더 자세히 살펴보려고 한다.
다섯 개 카테고리
Jetpack은 역할에 따라 다섯 개 카테고리로 나눌 수 있었다.
- UI: Data Binding, Compose, Navigation - 화면을 그리고 화면 사이를 이동
- 데이터: LiveData, Room, Paging - 데이터를 관찰하고 로컬 DB에 저장, 대량 데이터를 나눠서 불러옴
- 생명주기: Lifecycles, ViewModel - 화면 생명주기에 맞춰 안전하게 리소스 관리
- 기능: CameraX, WorkManager - 카메라 제어, 백그라운드 작업 예약 등 특정 기능
- 호환성: AppCompat, Hilt - 구버전 기기 호환과 의존성 주입
카테고리는 다섯 개지만, 실제 앱 하나를 만들 때는 이 카테고리를 넘나들며 여러 라이브러리를 동시에 조합해서 쓴다.
ViewModel과 LiveData
ViewModel은 화면 회전이나 시스템에 의한 액티비티 재생성이 일어나도 데이터를 잃지 않도록, 화면 상태를 액티비티/프래그먼트가 아니라 별도 객체가 들고 있게 만드는 라이브러리다. 액티비티는 화면이 바뀔 때마다 새로 만들어지지만 ViewModel은 화면 구성 변경 동안 살아남는다.
LiveData는 데이터의 변화를 관찰할 수 있는 데이터 홀더다. 값이 바뀌면 관찰 중인 화면에 자동으로 알려주고, 생명주기를 인식하기 때문에 화면이 보이지 않는 상태에서는 불필요한 업데이트를 하지 않는다.
두 라이브러리는 보통 함께 쓰인다. ViewModel이 LiveData 타입의 상태를 들고 있고, 화면은 그 LiveData를 관찰(observe)해서 값이 바뀔 때마다 UI를 갱신하는 구조다. "언제 어떤 뷰를 갱신할지"를 일일이 챙기지 않아도, 데이터가 바뀌는 순간 화면이 알아서 따라온다.
Room
Room은 SQLite를 더 안전하고 편하게 다루기 위한 라이브러리다. SQLite를 직접 쓰면 쿼리를 문자열로 작성해야 해서 오타나 타입 실수를 컴파일 시점에 잡을 수 없었는데, Room은 Entity(테이블 구조), DAO(쿼리), Database(연결) 세 요소로 구성되고 DAO에 함수로 쿼리를 선언해두면 컴파일 시점에 SQL 문법을 검증해준다.
Room은 LiveData나 코루틴 Flow와도 자연스럽게 연동된다. DAO가 특정 데이터를 LiveData로 반환하도록 작성하면, 데이터가 바뀔 때마다 화면이 자동으로 갱신되는 구조를 쉽게 만들 수 있다. ViewModel, LiveData, Room이 하나의 흐름으로 연결되는 셈이다.
장점과 단점
정리하면서 느낀 장단점도 같이 적어둔다.
장점은 코드가 짧고 효율적이며, 다양한 버전/기기에서 일관되게 동작한다는 점이다. 구글이 권장하는 아키텍처를 따르게 되니 설계 고민도 줄어들고, 취업 시장에서도 경쟁력 있는 스택이 된다.
단점은 라이브러리 종류가 많아서 처음엔 언제 뭘 써야 하는지 판단하기 어렵다는 점이다. 또 ViewModel이나 Room의 내부 동작 방식을 모른 채 쓰면 원인을 찾기 어려운 버그로 이어질 수 있다. 예를 들어 ViewModel이 왜 화면 회전에도 살아남는지 모르고 쓰면, 반대로 메모리에 계속 남아있어야 할 데이터가 예상치 못하게 사라지는 상황을 디버깅하기 어려워진다.
마무리
Jetpack 전체를 훑어봤으니, 다음 글부터는 그중에서도 UI를 담당하는 Jetpack Compose를 자세히 파고들어 보려고 한다.
