Android: Jetpack이란?
이번에는 안드로이드의 Jetpack에 대해 포스팅해보고자 한다. Jetpack이 출시된 지 2년이 다 되어가므로 조금 늦었나 싶긴 한데, 다른 사람이 이해하기 쉬운 자료를 만드는 것은 매우 효과적인 공부방법이므로 사실 이 포스트는 나를 위한 글이기도 하다.
Jetpack의 정의
Jetpack이 도대체 뭘까? 구글 이미지 검색 결과는 아래와 같다.
위 이미지만 보아도 jetpack이란 안드로이드 개발자가 애플리케이션 개발을 하는 데 있어서 뭔가 부스터 역할을 하는 건가보다, 추측해볼 수 있다.
실제로 안드로이드 개발자 홈페이지에 따른 Jetpack에 대한 설명도 비슷하다.
Jetpack은 개발자가 고품질 앱을 손쉽게 개발할 수 있게 돕는 라이브러리, 도구, 가이드 모음입니다. 이 구성요소를 통해 권장사항을 따르고, 상용구 코드 작성 작업에서 벗어나며, 복잡한 작업을 간소화하여 중요한 코드에만 집중할 수 있습니다.
Jetpack은 플랫폼 API와는 별도로 제공되는 androidx.* 패키지 라이브러리로 구성됩니다. 즉, 이전 버전과 호환되며 Android 플랫폼보다 더 자주 업데이트되므로 개발자는 항상 가장 뛰어난 최신 버전의 Jetpack 구성요소에 액세스할 수 있습니다.
위 설명에 따르면 Jetpack은 androidx.* 패키지 라이브러리로 구성되므로 Jetpack에서 제공되는 라이브러리, 도구, 가이드에 따르려면 androidx로의 마이그레이션이 필요하다. 하지만 아무리 새것이 좋아도 기존에 사용하던 것을 버리고 취할 수는 없는 법이다. 따라서 Jetpack 혹은 androidx 패키지 라이브러리는 이전 버전과 호환된다.
Androidx Migration
실제로 이전 직장 근무 시 오래된 지원 라이브러리를 사용하고 있는 회사 제품을 걱정했던 것이 무색하게, 무리없이 androidx로 마이그레이션한 경험이 있다. 기존 소스코드를 부분적으로 리팩토링 하거나 새로운 코드를 덧붙인 경험은 있지만 전체 소스코드에 영향을 주는 행위를 한 적은 거의 없던 데다가, 마이그레이션 혹은 그 이후 테스트 기간이나 인원이 따로 주어지지 않는 상황이었기 때문에 괜히 손댔다가 일만 만드는 것이 아닌가하는 걱정이 되었던 것이다. 하지만 compileSdk 수정 후 Android Studio에서 제공하는 ‘Migration to Androidx’ 기능을 이용한 후 IDE에서 미처 처리되지 못한 부분 혹은 sdk변경 과정에서 발생한 컴파일 문제(심각하지 않은)만 수정해주면 되었다.
처음에는 아무래도 ‘마이그레이션’이라는 단어에 압도되었던 것 같다. 회사 제품 측면에서도 분명 언젠가는 마이그레이션을 미룰 수 없을 때가 올 것이고, 개발자로서도 새로운 패키지를 쓰고 싶은 욕심이 당연히 있었기에…
다만 실제로 jetpack의 위력을 느낀 건 회사에서가 아니라 개인 프로젝트를 진행하면서였는데, 이렇게 돌이켜보니뭔가 활력있게 체계적으로 돌아가는 개발팀에 속하고 싶은 욕망이 커진다.
JetPack의 특징
JetPack의 구성요소는 다양하다. 기존의 Support library를 비롯하여 아키텍쳐 컴포넌트를 포함하는데 이를 크게 4가지로 나누어볼 수 있다.
또한 JetPack의 컴포넌트는 안드로이드 플랫폼의 일부가 아니므로 개발자는 원하는 androidx.* 패키지 라이브러리를 이용하여 원하는 컴포넌트만 취사선택하여 이용할 수 있다.
