[Android] 멀티 모듈 + Compose 적용기

많이 늦었지만 11월 회고 겸 멀티 모듈 + Compose 적용기에 대한 회고

(회사 프로젝트라 구체적인 내용은 적지 못했습니다. 그냥 회고글입니다.....)

 

11월은 굉장히 바쁘고 정신없었지만 주니어로는 좋은 경험을 할 수 있는 달이었다,

바로 사이드 프로젝트로만 공부할겸 만져보던 Compose를 실제 프로젝트에 적용해 볼 수 있는 기회가 있었고, 거기에 더해 멀티모듈까지 적용해 볼 수 있는 기회가 있었다.

 

시작

 

회사에서 진행하는 신사업에 관련된 앱을 만들어야했다.

상사분이 간단한 앱이니 Compose와 멀티 모듈을 도입해 보자고 하셔서, 프로젝트가 진행이 되었다.

 

나는 처음에 우리 메인앱에 들어오는 다른 피쳐를 작업하고 있었는데 일정이 촉박할 거 같다는 의견에 나도 투입이 되었다.

주어진 시간은 2주....

2주간 기획이 바뀌고, 디자인 변경.... 설계까지 많은 일이 있었다.

하지만 우여곡절 끝에 앱을 출시할 수 있었다.

 

나의 업무

 

우리 팀에는 Compose를 다루어본 사람이 나밖에 없었다.

그렇기 때문에 UI 관련 작업과 State Holder, State hoisting 등 Compose에서 중요한 개념들에 대해 정보를 공유하고, 공용 컴포넌트들을 만드는 작업을 맡게 되었고, 메인 네비게이션에 대한 설계와 백스택 관리, argument 관리 등 네비게이션에 관련된 작업을 맡았다.

피쳐는 홈, 내역, 내역 상세, 외부 앱 연동, 프로필, 프로필 수정 화면에 대한 기능을 설계, 구현하게 되었다.

 

좋았던 점

 

모듈 별 의존성 관리

 

하나의 모듈에 필요 없는 의존성들을 추가해서 프로젝트를 진행하다 보면 결국 라이브러리 관리가 힘들어지고, 

어디에서 왜 쓰는지 찾고, 정리하고, 추가하는 작업도 공수가 많이 들게 된다.

물론 아직 초반의 앱이라 그럴 수 있겠지만 멀티 모듈을 사용한다면 그 점은 싱글 모듈일 때보다 훨씬 관리가 용이해질 거 같았다.

 

리소스 관리

 

위의 장점과 비슷한 맥락으로 리소스 관리 또한 편해진 걸 느꼈다.

빠르게 많은 피쳐들을 구현하고 신기능을 만들고, 있던 기능들을 제거하는 과정을 겪다 보면 (특히나 우리 앱은 번역까지 해야 해서..)

이미지 리소스나 스트링 리소스관리가 굉장히 어려웠다. (실제로 안 쓰는데 존재하는 리소스들도 다수 존재 중...)

하지만 멀티 모듈을 사용하면 해당 모듈에서 필요한 리소스만 추가하다 보니 리소스 관리가 더 용이했고, 이미지나 텍스트가 어디에서 사용되는지 분명하게 알 수 있어서 좋았다.

 

협업에 용이

 

같이 일을 하다 보면 콘텍스트가 꼬이거나 다른 곳의 코드들이 수정되어 rebase나 병합 시에 충돌이 나는 경우가 더러 있는데

멀티 모듈을 쓰다 보니 모듈 별 사용처가 명확해지고, 그만큼 의존성에 대해 신경을 쓰게 되어서 업무 분장에도 도움이 되었고,

어떻게 피쳐를 나누어서 가져가야 할지에 대한 고민을 할 수 있는 기회였다.

 

컴포즈

 

작업 속도

 

특히나 컴포즈의 장점을 많이 느낄 수 있었는데

일단 빌드 속도 확실히 빠르다는 느낌을 받았다.

그리고 Preview가 존재하고, xml을 사용하지 않으니 작업 속도가 확실히 빨라진 느낌을 많이 받았다.

 

UI 구현

 

Preview 기능과 간편한 애니메이션 구현이 가능해서 UI 구현에 쏟는 시간을 많이 단축할 수 있었다.

또한 우리는 써드파티 라이브러리를 사용해서 동적인 뷰를 구성하고 있었는데

 

이번 프로젝트의 경우 사용 유저들 연령층이 높다 보니 업데이트를 최소화하고 앱에 피드백을 빠르게 반영하기 위해서 서버드리븐을 통한 UI를 포함했는데 이와 같은 동적인 뷰를 구성할 때 컴포즈가 아주 유용하였다.

각각의 컴포넌트들을 Compose를 이용하여 구성하고 서버에서 내려준 상태 값에 따라 Composable을 호출해주기만 하면 되니

 

기존 뷰방식에서 RecyclerView를 만들고 ViewHolder 별로 구성해서 xml로 레이아웃을 그리고 하는 여러 과정들이 축약되어 아주 간단하고 좋았다.

 

내비게이션에 대한 학습

 

평소 뷰를 이용해서 네비게이션 컴포넌트를 사용할 때에는 그래프가 한눈에 보여 그리기 편했고, 내가 실제로 어느 정도 알고 있다는 착각을 했다.

하지만 Compose를 이용해서 네비게이션을 설계하다 보니 내가 놓치고 있었던 부분(popTo, popuptoinclusive 등 )들을 더 공부할 수 있는 기회가 되었다.

 

기획부터 설계 배포 사이클 경험

 

내가 입사했을 때는 이미 회사에 앱들을 출시가 된 후였고, 내 업무는 운영관리, 개선 그리고 신규 기능 개발이었다.

하지만 신규 앱을 출시하다 보니 기획부터 설계, 배포까지 모든 사이클을 경험해 볼 수 있는 기회가 되었고, 좋은 경험이었다고 생각한다.

 

아쉬운 점

 

물론 아쉬운 점은 너무나도 많다. 일정이라던가, 일정, 흠.... 일정이나

일정이 많이 타이트했다. 그러다 보니 포기한 부분들이 많았고, 소통도 미스가 꽤나 많았다.

 

앱 퀄리티

 

이 부분은 차차 개선을 하는 중이지만 앱 퀄리티가 많이 아쉬웠다.

거의 1주일 만에 밀어붙여 만들어지다 보니.... 개발자로서 많이 아쉬웠다.

 

클린 아키텍처

 

멀티 모듈을 썼지만 클린 아키텍처를 적용하지는 못했다.

일정이 타이트했고, 앱의 기능이나 규모도 그렇게 크지 않다고 생각해서 구글 앱 아키텍처로 구현을 하였고, 도메인 레이어도 빼고 설계를 진행하였다.

그런데 구현하면서 요구사항이 늘다 보니 usecase의 부재가 좀 아쉽게 느껴졌다.

 

네비게이션 구현

 

확실히 뷰 방식에 조금 더 익숙하다 보니 네비게이션 설계를 하고 사용을 할 때 백스택 관리가 뷰 기반의 방식보다는 더 헷갈렸다.

Compose는 그래프가 도식화되어 보이지 않다 보니 개발을 진행하다가 백스택 구조가 헷갈릴 때가 가끔 있었다.

 

상태 관리

 

바텀 시트나 다이얼로그를 띄우거나 닫을 때, 또는 api 호출 등 State를 이용하여 많은 작업을 처리하였는데

이것도 익숙하지가 않다 보니 개발을 하다가 뇌정지가 오는 경우가 꽤나 많았다.

생각해 보면 간단한 부분도 많았고, 수정해야 할 부분도 많아서 빨리 리팩토링을 진행해보고 싶다.