Jetpack Compose 공부를 시작하며 느끼는 장점

Jetpack Compose란?

Android 네이티브 UI를 만드는 최신 도구로, 2021년 3월 베타버전이 출시되었고, 2021년 8월 정식으로 출시되었다. Compose는 Kotlin 문법을 사용해 선언적으로 UI를 만든다.

https://developer.android.com/jetpack/compose

Jetpack Compose UI 앱 개발 도구 키트 - Android 개발자  |  Android Developers

 

나는 2021년 11월에 GDG Korea Android에서 주관하는 ComposeFest2021 에 참여해 Compose Codelab을 통해 컴포즈를 처음 사용해봤다.

그 당시에는 기존 XML 방식에서 당장 컴포즈를 공부하고 도입해서 갈아타야하나?에 대한 큰 메리트는 느끼지 못했다. 그 이유는 다음과 같았다.

1. 당시에 나는 안드로이드 개발을 본격적으로 시작한지 갓 1년이 되었고, XML로 만드는 방식의 단점을 느낄 수 없던 상태라 익숙해 진 것을 버리고 새로운 개념을 주입하는 것에 대한 메리트를 느끼지 못했다.

2. 프리뷰 빌드 렌더링 속도가 너무 느렸다. 레이아웃 팔레트를 통해 XML로 작성한 UI를 바로바로 확인 할 수 있었는다. 그러나 이에 반해 프리뷰 렌더링 속도가 느려, 오히려 간단한 레이아웃을 작성할때는 생산성이 떨어지는 느낌을 받았었다. 컴퓨터 사양이 많이 필요하다고 생각했다.

 

그러나 이후 1년이 넘게 서울맛칩을 개발하며 XML 파일을 이용해 UI를 개발하는 방식의 단점을 마주하게 되어버렸다.

1. 화면에 구성요소가 많으면 구성요소 개수에 비해 XML 파일의 코드가 너무 길다. 단적인 예로, 처음에 서울맛칩의 Home화면을 만들 때 XML 코드가 1500줄이 넘었었다. 이렇게 되면 XML파일을 수정할 때 오래 걸린다. 스크롤 내리는 것도 오래 걸리고 심지어, 1000줄이 넘으면 XML파일이 렉이 걸린다.

2. 개발하면 수정 내용이 계속 생기는데 그 때마다, 코틀린 파일, XML 파일을 들락날락 거려야했다. 데이터바인딩과 바인딩결합식까지 사용하며 더욱 심해진 단점이었다. 심지어 텍스트뷰나 이미지뷰가 부모 레이아웃으로 전부 감싸져 있어서, 수정해야 할 내용을 찾는데도 생산성이 떨어졌다.

3. UI 최적화를 위해 <include>를 이용해 부분 View를 만드는데 그럴 때마다, latout.xml 파일을 1개씩 추가로 만들어야 해서 리소스 파일의 개수가 너무 많아졌다. <include>를 사용하기 위해 xml 파일이 1개씩 늘어날때마다 생산성이 떨어진다. 왜냐하면 코틀린 코드한번 고치고, UI 코드도 수정해야하는 경우 확인해야 할 파일이 2개가 되기 때문이다. 그리고 리소스 파일이 늘어날 수록 빌드 속도도 같이 느려진다.

 

이후, 다른 내용을 공부하기 위해 예제를 따라하며 우연히 컴포즈로 UI를 만들게 되었다.
그리고 나서 생각했다. "XML 방식보다 훨씬 좋은 것 같다. 신세계다." 바로 공부해서 숙련도를 올려야겠다고 마음을 먹었다.
서울맛칩을 XML 파일과 데이터바인딩을 사용하여 개발하면서 생산성이 떨어지는 경험을 많이 해서 그런지 2년 전에 비해 많은 장점들이 느껴졌다.

프리뷰 Live Edit 빌드 속도가 무척 빨라졌다.

2년 전에만 해도 내가 큰 메리트를 느끼지 못했던 점이었는데, 안드로이드 스튜디오 버전이 업데이트 되면서 그동안 컴포즈와 관련된 많은 부분이 개선되었다. 특히 프리뷰 렌더링 속도가 많이 빨라졌다. 안드로이드 스튜디오 Live Edit 성능이 더 업데이트 되면서 2년 전에 내가 느꼈던 가장 큰 단점이 상쇄 되었다. 오히려, 프리뷰를 통해 부분적으로 Composible 함수를 만들고 프리뷰를 볼 수 있어서 UI의 부분 부분을 더 디테일하게 만드는데 집중할 수 있었다. 

생각보다 생산성이 훨씬 좋고 직관적이다.

사실 xml파일 하나만 봤을 때는 생각보다 직관성이 좋다. 그러나 위의 두개의 코드를 같이 보면 UI 구성코드는 xml파일에, UI 변경에 대한 코드는 kotlin파일에 서로 다른 언어로 파일이 분리되어있다. 그리고 코틀린 파일에서는 뷰마다 아이디를 부여하고 이를 findViewId()를 사용해 id를 찾아와 객체를 생성한 후 UI를 변경해야 한다.
이를 보완하고자 뷰바인딩, 데이터 바인딩+바인딩결합식이라는게 존재하지만, 개인적으로 바인딩 결합식은 많이 사용할수록 유지보수 효율이 낮아진다고 생각한다. 왜냐하면 데이터 바인딩으로 연결된 함수들이 View와 ViewModel에 둘 다 존재할 경우가 많기 때문이다. 그래서 서로 다른 성격을 가지면서 데이터 바인딩에 의한 의존성이 생겨버린다. 서로 다른 성격의 의존하는 파일들이 많아질수록 유지보수할 때 시간이 오래걸린다. 바인딩 어댑터를 사용하면 확실히 편한건 맞지만 이후의 유지보수 성능은 떨어진다고 생각한다.

이에 반해 컴포즈를 사용하면 해당하는 Composable 함수만 확인하면 된다. 즉 내가 확인해야할 파일의 개수가 줄어드니 당연히 확인해야할 코드 수도 줄어들어 생산성이 올라갈수밖에 없다. 심지어 xml파일에서 TextView를 구현하기 위해서는 기본적으로 5줄 이상의 코드가 생성된다.

그러나 컴포즈는 이 한줄이면 끝난다. 이는 리사이클러뷰도 마찬가지다. 더이상 리사이클러뷰 itemView에 대한 xml파일을 만들지 않아도 되며, 리사이클러뷰 어댑터 클래스 파일을 만들지 않아도 된다. 그리고 어댑터 객체를 생성해 리사이클러뷰 어댑터를 설정하는 코드를 작성하지 않아도 된다.

애니메이션을 구현하는게 훨씬 편하다.

나는 그동안 MotionLayout, animation.xml파일을 사용하는 방법, 코틀린으로 직접 코드를 사용해 애니메이션을 구현해왔다. 나는 Adobe Premiere Pro,  Adobe After Effect를 사용해 동영상 편집을 해본 경험이 있기 때문에 키프레임에 대한 개념이 있는 상태여서 내 손에는 MotionLayout이 가장 편했다. 하지만 MotionLayout을 비롯해 xml파일을 이용해 애니메이션을 구현하는 것은 시간이 오래 걸린다. 그리고 뷰페이저와 같이 모션레이아웃을 사용하지 못할 때는 애니메이션 코틀린 코드들을 직접 레퍼런스에서 참조해 사용했다. 
그런데 컴포즈는 Animation API 를 이용해 쉽게 구현할 수 있다. 
https://developer.android.com/jetpack/compose/animation/composables-modifiers?hl=ko#animatedvisibility

애니메이션 수정자 및 컴포저블  |  Jetpack Compose  |  Android Developers

심지어 원하는대로 애니메이션이 적용되었는지 프리뷰를 통해서 바로 확인 할 수 있다. 반복적으로 전체 빌드를 해서 검사하는 과정을 단축할 수 있다. 훨씬 생산적으로 퀄리티 높게 애니메이션을 편하게 구현할 수 있다.

 

내가 스스로 체감하며 느낀 Compose를 사용한 개발의 장점은 위의 3개이다. 이 장점들로 인해 앞으로 더 Jetpack Compose를 공부할 것이다. Compose를 깎아서(?) XML 만큼 어느 UI라도 만들수 있도록 숙련도를 올릴 것이다. 공부하면서 생기는 장점들과 단점들을 계속 공유할 생각이다. 일단 현재는 많은 수의 xml 파일을 생성하지 않아도 되는 것과 빌드 속도가 훨씬 빨라 2년 전에는 체감하지 못했던 신세계를 맛보고 있다.