우리가 Android Compose를 택한 이유: 플레이키보드 이야기

플레이키보드가 안드로이드 앱의 온보딩 화면을 Jetpack Compose 로 만들며, XML 대비 코드가 얼마나 줄었는지를 버튼 컴포넌트 예시로 보여주는 글이다. 기존 Compose 도입 글들이 코드 감소를 자세히 다루지 못했다는 아쉬움에서 출발했다.

핵심 포인트

XML 은 태그와 속성으로 정적 구조를 선언하고 디자인과 논리를 다른 파일에 두지만, Compose 는 함수 호출로 UI 와 상태를 함께 정의한다.
Compose 의 진가는 같은 컴포넌트를 여러 곳에서 쓸 때 나온다. 버튼 하나가 XML 로는 13줄짜리 블록을 화면마다 복사해야 했다.
Compose 로 만든 MainButton 은 버튼 텍스트와 추가 디자인, 클릭 시 실행할 함수만 넘기면 끝난다. 내부 코드를 몰라도 쓸 수 있다.
XML 이었다면 레이아웃 작성과 코틀린 코드 연결, 클릭 이벤트 부여가 각각 필요했는데 이 전부가 함수 하나로 정리된다.
가장 체감된 변화는 리사이클러뷰가 사라진 것이다. item.xml 과 Adapter, ViewHolder 를 만들던 자리를 LazyColumn 하나가 대신한다.

상세 정리

도입 시점의 차이를 세 가지로 정리한다. 선언 방식, 가독성과 유지보수, 애니메이션과 상호작용 구현이다.
XML 은 복잡한 UI 를 표현하려면 태그와 속성이 많아지고 중첩 구조로 가독성이 떨어지며, 디자인과 논리가 분리돼 유지보수가 어렵다.
Compose 는 UI 요소와 상태를 같은 파일에서 관리해 유지보수가 간편하고, 애니메이션과 인터랙션 기능이 내장돼 있다.
Compose 로는 웹 개발처럼 디자인 시스템을 만들 수 있다. XML 의 style 로도 가능했지만 아쉬운 점이 많았고, 안드로이드 공식 문서도 Compose 로 디자인 시스템을 만들기를 권장한다.
적용 지면은 온보딩 화면이다. 특별한 기능은 없지만 사용자 경험과 UI 배치에 집중해야 하는 화면이라 시범 도입 대상으로 골랐다.
새로 그리는 화면 중 하나를 골라 시범 적용하는 방식이라 기존 화면은 건드리지 않았다.
후기는 생산성이 XML 대비 압도적이었고 러닝 커브는 있었지만 충분히 가치 있는 도전이었다는 것이다.
뷰바인딩과 데이터바인딩, 리사이클러뷰로 쌓은 기존 지식이 Compose 를 배우는 데도 도움이 된다며 도입을 망설이는 개발자를 설득하는 것으로 글을 맺는다.