View에서 Compose로 migrate한 썰 푼다

지난 5월 16일, 쿠링 2.0이 배포되었다. 내가 속한 안드로이드 팀을 비롯하여 서버, iOS, 디자인, PM 등 팀원 모두가 함께 이뤄낸 값진 성과라고 할 수 있다.

10개월 가까이 2.0을 작업하면서 세 번의 계절을 보냈고, 나는 어느새 졸업...

 

이 글에서는 내가 속한 안드로이드 팀을 중심으로, 쿠링 2.0 작업을 되돌아보고자 한다.

2.0

쿠링 2.0의 핵심은 디자인 업데이트이다. 그러나 당시 안드로이드 코드는 전혀 모듈화되지 않았고, ``:app`` 모듈 안에서 참조 관계가 너무 복잡해지고 있었기 때문에 안드로이드 팀은 모듈화 작업을 함께 수행하기로 결정했다.

모듈화

모듈화 작업은 아래 글에서 자세히 돌아보았다.

MAU 세 자릿수 서비스 모듈화한 썰 푼다

Compose 도입

2.0 디자인의 가장 큰 특징은 재활용 가능한 컴포넌트를 활용하여 UI 생산성이 높아진 점이라고 할 수 있다. 같은 컴포넌트를 재활용함으로서 디자인 및 개발 생산성이 높아지고, color, typography의 이름을 통일함으로서 의사소통이 쉬워진다. 

 

즉 UI를 토큰화하여 재활용하는 것이 2.0 디자인의 목적이고, view보다는 Compose가 선언형 UI로서 이 목적에 가장 잘 부합한다. Compose 도입은 어찌보면 필연이었다.

디자인 시스템 토큰화

쿠링 디자인 시스템에서 사용하는 색깔, typo 등을 ``KuringTheme``으로 묶었다. 원래는 ``MaterialTheme``을 부분적으로 사용하고 있었지만, 토큰 이름이 쿠링 시스템과 달라서 ``MaterialTheme``을 계속 사용하기는 어려웠다.

 

``KuringTheme``은 ``MaterialTheme``을 참고하여, 최대한 비슷하게 사용할 수 있도록 구현했다. 우선 color만 먼저 적용했고, typo도 곧 적용할 예정이다.

 

아래 링크에서  ``KuringTheme`` 코드를 볼 수 있다.

KU-Ring-Android/common/designsystem/src/main/java/com/ku_stacks/ku_ring/designsystem/kuringtheme/KuringTheme.kt at develop · ku

컴포넌트

피그마에서 별도로 묶인 컴포넌트를 composable로 구현했다. 디자인이 많이 겹치는 경우에는 enum이나 오버로딩을 활용했고, 컴포넌트 간 공통점이 별로 없다면 별개의 composable로 구현하기도 했다.

 

예를 들어, 아래 스크린샷에서 맨 위는 ``KuringIconTopBar``, 가운데 4개는 ``CenterTitleTopBar``, 마지막 하나는 ``LargeTopAppBar``로 구현했다. 

그런데 디자인대로 구현한 컴포넌트가 디자인과 미묘하게 다른 이슈가 있었다. 피그마와 안드로이드 길이 단위가 각각 px과 dp로 달랐기 때문.

 

수치값은 기본적으로 동일하게 사용하되, 너무 차이가 크면 디자인에 맞게 수치를 조절하는 방식으로 디자인과 UI 사이의 간극을 최소화했다.

UI migration

선언형 UI의 가장 큰 장점은, 컴포넌트가 잘 구현되어 있을 때 생산성이 매우 높아진다는 점이다. 그러면서도 디자인을 거의 그대로 재현할 수 있다. 그야 디자인대로 컴포넌트를 만들었으니 당연하다.

 

프리뷰를 통해 개발하고 있는 UI를 바로 확인할 수 있다는 점도 편리했다. 여러 가지 케이스를 한 눈에 볼 수도 있고, UI 코드를 리뷰할 때에도 큰 도움이 되었다.

Compose UI check

다만 2명이 공동으로 작업하는 특성상, 어느 수준부터 composable로 분리할 것인지 등 컨벤션을 정할 필요가 있었다. 나는 좀 과하다 싶을 정도로 분리하는 경향이 있기도 했고.

 

모듈화에 비하면 UI 작업은 진심으로 즐거웠다.

Single Activity?

Compose는 single activity + navigation 조합을 권장한다. 하지만 작업이 너무 지연되고 있었기 때문에, 기존에 구현되어 있던 Activity에 screen을 하나씩 할당하는 구조를 채택했다.

 

Single activity는 2.0 이후에 도입할 예정이다. Compose navigation이 type-safe을 지원한다는 소식도 있어서, 머지 않은 미래에 작업할 예정이다.

Navigation Compose meet Type Safety

Compose-view interop

바로 위 문단에서 기존 Activity를 최대한 활용하는 방법을 채택했다고 말했는데, 메인 화면의 pager도 비슷한 방법으로 구현했다. 각 page를 Fragment로 구현하고, Fragment 안에서 Compose를 호출하는 것.

// Main screen pager
class MainPagerAdapter(fm: FragmentManager, lc: Lifecycle) : FragmentStateAdapter(fm, lc) {
    private val items = arrayOf(
        { NoticesParentFragment() },
        { ArchiveFragment() },
        { CampusFragment() },
        { SettingFragment() }
    )
}

// SettingFragment
binding.composeView.setContent {
    SettingScreen(
        ...
    )
}

물론 pager도 언젠가 Compose로 migrate해야 한다. 그러나 경우에 따라 기존 view 구조를 일부 활용할 수도 있다는 것.

 

반대로 Compose에서도 view를 호출할 수 있다. 자세한 내용은 아래 글을 참고.

Compose에서 view 사용하기

그런데 view를 일부 활용한 화면에서 디자인을 100% 재현할 수 없는 문제가 있었다. 메인 화면은 view navigation 안에서 Compose를 호출하고 있는데, 이 때문에 bottom sheet 등이 의도대로 작동하지 않는 문제가 있다.

 

이 문제는 Compose 100% migration 작업에서 수정할 예정이다. 

BottomSheet가 완전히 올라오지 않는다. Dimmed 처리도 약간 다르다.

출시

5월 초, 우여곡절 끝에 2.0 작업을 마무리했고, 5월 16일에 배포했다. 작업 기간이 길어서 그런가, 지금까지 출시했던 버전 중 2.0이 가장 안정성이 높다..;;

 

2.0 출시 기념으로 축제 부스도 열었다! 

우리 부스 정상 영업합니다

작년에 이어 두 번째 부스 참가였는데, 많은 학우들에게 쿠링을 알릴 수 있었고 신규 다운로드도 꽤 많이 얻었다. 갤럭시 쓰세요? 제가 안드로이드 앱 담당자에요

아쉬웠던 점: 프로세스의 부재?

프로젝트가 관리되지 않을 때 어떤 일이 일어나는지 실감하게 되었다. 작업 자체는 성공적으로 마쳤지만, 작업 기간이 너무 늘어난 게 제일 아쉽다. 원래 2.0은 작년 말까지 출시할 예정이었는데, 밀리고 밀려서 5월까지 늦춰진 것.

 

나도 그렇고 팀원들도 많이 바빴다고는 하지만, 일정이 구체적으로 정해져 있었더라면 이렇게 느슨하게 작업하지는 않았을 것 같다. 나도 쿠링 작업을 후순위로 미룬 적이 꽤 있어서... 나부터 반성해야 할 부분.

 

그나마 로직을 대부분 재활용해서 다행이지, 로직마저 새로 짰다면 아직도 작업하고 있었을 것이다. 상상만 해도 끔찍하다.

앞으로는

다행히 많은 팀원들이 나와 같은 문제의식을 갖고 있다. 대략 개발 일정을 관리하고, 출시 사이클을 빠르게 반복하면서 개발 활력을 되살리는 것이 제일 중요할 듯. 

 

6월 중순부터 프로세스 개혁 작업을 시작할 건데, 내 능력과 시간이 허락하는 선에서 최대한 주도적으로 참여할 것이다. 쿠링 프로젝트와 팀원들을 좋아하고, 우리 팀이 더 나아지길 바라기 때문이다. 개발 속도가 빨라지면 4월에 모집한 신규 팀원 분들의 온보딩도 한결 수월해질 것이다.

 

안드로이드 팀도 신입을 뽑았는데, 현업 경력도 있으시고 기술적으로 아주 뛰어나신 분이 오셨다. 3명이서 함께 효율적인 코드와 프로세스를 만들어갈 수 있길 기원한다. 

 

앞으로도 쿠링의 여정은 계속됩니다. 화이팅!

↓ 쿠링 다운로드

쿠링 - 건국대학교 공지앱 - Google Play 앱