들어가며
Jetpack이 뭔지, Compose가 뭔지, State/remember와 리컴포지션까지 정리했으니 이번 글에서는 지금까지 본 내용을 특징으로 묶어보고, 장단점과 Jetpack 전체와의 관계까지 정리하면서 마무리하려고 한다.
Compose의 주요 특징
관심사 분리 측면에서는 UI와 로직을 모두 Kotlin으로 작성하기 때문에, XML과 코드 사이에 있던 암묵적인 의존 관계가 명시적으로 드러난다.
동적 UI 구성 측면에서는 if문이나 반복문 같은 언어 기능을 그대로 활용해 상태에 반응하는 화면을 구성할 수 있다. XML에서는 조건 분기를 표현하려면 뷰를 미리 다 만들어두고 visibility를 코드에서 바꾸는 식으로 우회해야 했는데, Compose에서는 Kotlin 코드로 그대로 표현하면 된다.
@Composable
fun Greeting(isLoggedIn: Boolean) {
if (isLoggedIn) {
Text("환영합니다")
} else {
Text("로그인이 필요합니다")
}
}성능 측면에서는 앞선 글에서 정리한 리컴포지션, 위치 기반 메모이제이션, Slot Table 덕분에 바뀐 부분만 다시 그린다.
테스트 측면에서는 Composable 함수가 입력(상태)에 따라 출력(화면)이 정해지는 구조에 가깝기 때문에 단위 테스트를 작성하기 수월하다.
장점과 단점
장점은 관심사 분리, 동적 UI 구성의 편의성, 성능 최적화, 테스트 용이성이다. 코드량도 줄고 유지보수도 상대적으로 쉬워진다. Navigation, ViewModel, 코루틴 같은 기존 Jetpack 라이브러리와도 자연스럽게 함께 쓸 수 있다.
단점은 학습 곡선이다. Slot Table, 리컴포지션, 메모이제이션 같은 내부 동작이나 State와 remember를 이용한 상태 관리 개념을 새로 익혀야 한다. 이번에 직접 코드를 짜보면서도 remember 하나 이해하는 데 세 가지 버전을 비교해봐야 했을 정도였다. 또한 이미 XML로 만들어진 대규모 기존 프로젝트라면 한 번에 Compose로 전환하기 어렵기 때문에, 기존 View와 Compose를 함께 쓰면서 점진적으로 마이그레이션하는 전략이 필요하다.
Jetpack과 Compose의 관계
정리하면 Jetpack은 안드로이드 개발 전반을 돕는 라이브러리 모음이고, Compose는 그 안에서 UI를 만드는 방식을 담당하는 라이브러리다. Compose를 쓴다고 해서 ViewModel이나 Room 같은 다른 Jetpack 라이브러리를 안 쓰는 게 아니라, 오히려 이런 라이브러리들과 조합해서 쓰는 경우가 대부분이다. ViewModel이 상태를 들고 있고 Compose 화면이 그 상태를 구독해서 그리는 구조가 실무에서 가장 흔하게 쓰이는 패턴이라고 한다.
마무리
Jetpack이 라이브러리 모음이라는 것부터 시작해서, 그 안의 대표 라이브러리들, Compose의 선언형 UI, State와 remember, 리컴포지션과 Slot Table까지 순서대로 정리해봤다. 개념만 읽었을 때는 잘 와닿지 않던 부분들(특히 remember의 필요성, "바뀐 부분만 다시 그린다"는 말)이 직접 코드를 짜고 Logcat으로 확인해보면서 훨씬 명확해졌다. 다음에 Compose로 화면을 만들 때는 이번에 확인한 것처럼 State/remember의 스코프와 리컴포지션 범위를 의식하면서 짜야겠다는 생각이 들었다.
