1. 행사시간
09:30 ~ 17:20 (점심시간 12:35 ~ 13:55)
2. 행사 목차
(1) Compose 성능 최적화를 위한 Stability 마스터하기 - 엄재웅
(2) 앱 성능 영혼까지 끌어올리기 - 배필주
(3) Compose UI 컴포넌트 설계와 테스트 - 김수현
(4) compose-video 오픈소스 라이브러리 개발기 (배포까지) - 이상훈
(5) 플레이어 SDK 개발자의 Kotlin Multiplatform 도입기 - 모진섭
(6) Compose Material3 커스텀 디자인 시스템 구축기 - 권대원
3. 내용
전날부터 어떤 사람이 있을지 궁금한 나머지 들뜬 마음으로 잠을 잘 이루지 못하고 갔다. 조금 피곤하긴 했지만 역시나 많은 사람이 모여 있었다. 줄을 오래기다릴까봐 40분정도 일찍 도착했는데 6명정도 밖에 없어서 순조롭게 1등으로 입장할 수 있었다.
QR코드를 찍고 입장하니 당근, 카카오뱅크, JETBRAINS가 입구에서 반겨주었다. 필자는 셋다 받았는데 JETBRAINS의 스티커가 예뻐서 한개씩 전부 가져왔다. 나머지 당근, 카카오뱅크 행사도 참여하고 당당하게 입장!
(1) Compose 성능 최적화를 위한 Stability 마스터하기 - 엄재웅
첫번째 시간에는 Compose를 사용한 성능 최적화 방법에 대한 발표였다. Jetpack Compose에는 최적화를 위한 기능이 내장되어 있지만 개발자는 이로 하여금 UI요소의 렌더링 방법을 이해하고 사용하는 것이 Compose의 최적화에 더 효율적이라는 것이다. 기본적인 Compose 노드 렌더링은 다음과 같다.
- Data -> Composition -> Layout -> Drawing -> UI
각 단계에 있어 간단하게 이야기 하자면 "데이터 -> 구성 -> 레이아웃 -> 그리기 -> UI" 이다. 데이터를 컴포저블 메모리 슬롯에 할당하고 레이아웃 노드에 위치시킨 다음 캔버스에 렌더링 한 다음 UI가 된다는 것이다. 사실 이부분은 그렇게 중요한 것이 아니다. 이러한 과정들을 거쳐 UI를 생성하는데 특별한 사유에 의해 다시 그리게 만들면 메모리가 너무 비 효율적이라는 것이다.(전체적인 내용)
여기서 용어 몇 가지만 설명하고 가자.
- Recomposition : 컴포즈를 다시 그리는 것
- Smart Recomposition : Stable과 Unstable을 구별하여 Recomposition을 실행
- Stable : 안정적
- Unstable : 불안정적
Recomposition을 실행하는데 있어 Stable과 Unstable을 구별하여 수행한다고 했다. 그것이 Smart Recomposition이다. 그렇다면 Stable은 어떤것을 이야기 할까?
- String을 포함한 기본 유형
- (Int) -> String과 같은 람다 표현식으로 표현된 함수 유형
- 모든 public property가 불변 (value)
- @Stable, @Immutable과 같은 stability 어노테이션을 사용
상기와 같은 내용들은 모두 Stable 상태라고 한다. 그렇다면 Unstable은 어떤것일까?
- Kotlin의 collections에서 제공하는 List, Map 등을 포함한 모든 인터페이스와 Any 타입과 같은 추상 클래스
- 하나 이상의 가변적(variable) 본질적으로 불안정한 public property
즉 값이 변경될 것 같으면 Unstable 라는 것이다. 그렇다면 여기서 궁금한것이 생길것이다. 과연 @Stable, @Immutable의 차이는 무엇일까?? 이부분은 뒤에서 다루기로 하자.
이밖에도 Composable 함수는 몇가지 추가적인 사항들로 Composable 함수 실행을 최적화 하는데 Restartable, Skippable, Moveable, Replaceable 등 여러 그룹으로 분류하여 실행을 최적화한다. 이중 중요한 두가지만 놓고 이야기를 해보자.
- Restartable : Recomposition ,특별하게 Composable함수를 명시하지 않아도 Restartable로 간주된다.
- Skippable : Recomposition을 안하고 Skip하는 것으로 Restartable인 동시에 Skippable일수도 있다.
그럼 이제 이전에 말했던 Immutable과 Stable에 대해 알아보자
- Stable : 동일한 입력에 대하여 동일한 결과를 반환
- Immutable : 불변 보장
어떻게 보면 비슷해보일 수 있지만 Stable은 일정한 값을 동일하게 반환한다는것에 차이가 있다. Recomposition이 어떻게 이루어지는지 알았으니 무조건 Recomposition 되는 것을 방지하는 것에 대해 알아보자
- NonRestartableComposable : 특별한 매개변수의 변경으로 Recomposition을 막는 역할을 한다.
특별한 값에 의해 Recomposition을 막는다면 불필요한 Composable 노드 메모리 할당을 막을 수 있을 것이다.
Composable 함수의 여러가지 사용 방법과 효율적인 사용을 위한 Recomposition을 알아볼 수 있었다. 어느때보다 Compose에 대해 깊게 알아갈 수 있는 시간이었다.
(2) 앱 성능 영혼까지 끌어올리기 - 배필주
성능 최적화를 위해서는 크게 5가지요소를 체크해야 한다.
- 라이프사이클 로깅
- 메모리 체크
- 네트워크 체크
- 언어 리소스
- 기기사양
- 인스톨러
일단 라이프 사이클 로깅부터 살펴보자. 엑티비티 실행이나 화면 전환시 onSaveInstanceState를 호출하는데 이 때 데이터 손실이 일어나기 때문에 onSaveInstanceState를 사용하여 로깅을 실시한다. 회전이나 엑티비티가 변경되어도 데이터가 그대로 유지되는지 확인할 수 있다.
그 다음으로 메모리 체크는 메모리 누수가 있는지 체크하는 것이다. 메모리 누수를 체크하는 방법에는 여러가지가 있지만 프로파일링을 하는 방법이 가장 쉽고 간단하다. 안드로이드 스튜디오에서 하단의 Profiler를 클릭하여 Memory탭을 클릭하면 간단하게 확인할 수 있다. 그 밖에 앱 내에서 코드로 구현하여 확인하는 방법도 있으니 편한 방법으로 확인하도록 하자.
네트워크 체크는 한국에서는 많은 영향을 끼치지 않지만 기본적으로 네트워크 상태가 연결되어 있는지 확인하는 코드를 같이 포함하도록 하자. 인터넷 통신환경이 잘 구축되어 있지 않은 지역같은 경우에는 갑작스럽게 네트워크 연결이 끊기면 유저 입장에서 인터넷이 끊긴건지 앱이 정상적으로 동작하지 않는지에 대하여 여부를 혼동할 수 있다.
해외에서 다양한 언어로 접근하는 글로벌 앱 같은 경우에는 언어 리소스가 중요한 영향을 끼친다. 영어로 지원한다고 해도 영어를 할줄 모르는 국가도 있기 마련이다. 이러한 다양한 언어의 지원은 다양한 국가에서 사용할 수 있도록 지원해준다.
한국에서는 최신형 휴대폰으로 자주 바꾸는 편이지만 이런 물질적인 소유욕이 적거나 아직 삶의 여유가 많지 않은 국가 같은 경우에는 최신형 휴대폰을 사용하지 않는 경우가 많다. 최신 코드로 짜여진 앱도 좋지만 낮은 OS버전 지원으로 다양한 휴대폰에서 사용할 수 있도록 지원하는것 또한 중요하다. 가장 베스트는 저사양 고효율 앱이 아닐까 싶다.
대부분의 앱은 PlayStore에서 다운받을 수 있다. 삼성에서 보안을 위하여 PlayStore에서 앱을 다운로드 받는것을 권장하는 만큼 인하우스 배포보다는 PlayStore에서 다운받는것을 권장한다. 또한 다양한 국가에서 다운 받고 검색해볼 수 있도록 PlayStore배포는 앱 홍보면에서도 높은 효율을 가진다.
이처럼 앱을 어떻게 해야 최적화를 할 수 있는지에 대해 알아보았다. 발표를 듣는 중 느낀 것이지만 당연하면서도 개발하는 입장에서 나 자신과의 싸움으로 놓지 말아야할 중요한 사항인 것 같다.
(3) Compose UI 컴포넌트 설계와 테스트 - 김수현
컴포즈 설계는 선언형 UI이기 대문에 XML과 다르게 각 UI를 하나의 컴포넌트로 생각하자. 각 컴포넌트가 모여 하나의 UI를 이루기 때문에 유연성이 있고 재사용성이 뛰어나다. 하지만 XML은 하나의 값만 잘못 어긋나더라도 XML전체가 잘못되는 증상이 발생된다. 이러한 면에서 Compose는 하나의 컴포넌트로서 UI가 코드와 같이 어울릴 수 있는 기회를 제공해 준다. 이러한 Compose를 테스트하는 방법에는 3단계가 있다.
- Compose UI Testing
- Compose Preview
- Compose Screenshot Testing
이 세가지는 각각 Compose UI를 그리고 동작을 만든다. Preview를 만든다. 스크린샷을 찍는다 이렇게 3단계로 나누어 진행한다. 어렵지 않게 @Preview를 만들어 그 안에 Compose의 테스트 동작을 입력하고 스크린샷을 찍어 확인하는 것이다. 간단한 방법이지만 가장 효율적이고 좋은 방법이라고 생각한다. 필자는 @Preview를 놓고 Compose UI테스트 코드까지만 진행하여 스튜디오 실행 시 미리보기로 확인하는 용도로만 사용한다.
(4) compose-video 오픈소스 라이브러리 개발기 (배포까지) - 이상훈
Compose로 video player를 만들어 라이브러리화 까지 진행한 내용이다. 일반적으로 규모가 있는 회사 같은 경우에는 피커나 플레이어 같은 것들을 회사만의 라이브러리를 만들어 사용한다. 공통 소스로 배포되어 잇는 라이브러리 같은 경우에는 IOS와 디자인이 다르게 나오거나 혹은 OS 버전 업데이트시 회사 자체적으로 문제를 해결할수가 없는 경우가 발생된다. 그래서 이 내용을 듣게 되었고 Compose로 비디오플레이어를 만들어 라이브러리 배포 까지 진행하여 회사 자체 상품을 만드는 과정을 들을 수 있었다. 어쩌면 자체적으로 만든 피커나 비디오플레이어 라이브러리를 배포하거나 사용하는것도 좋은 방법일 것 같다.
사실 어떻게 배포하는지에 대한 방법보단 라이브러리를 얼마나 편의성있게 사용할 수 있도록 만드는지가 가장 중요한 요소인 것 같다. 가령 발표자는 비디오플레이어를 제작하였는데 비디오플레이어를 사용하는 동안 얼만큼에 데이터를 사용하였는지와 가로모드로 회전시 어떻게 동작할것인지 어떤식으로 플레이어 재생 위치를 수정할 것인지에 대한 것들이다. 그리고 PIP기능까지 더한다면 유투브 처럼 좋은 동영상 플레이어가 될 것이다.
이 발표를 듣게된 이유는 회사에서 제작하여 사용하는 캘린더 피커나 타임피커 혹은 사진, 동영상 뷰 같은것들을 라이브러리를 직접 제작하여 사용하는 것도 좋은 방법일꺼라 생각하여 듣게 되었다. 자체적으로 제작하여 사용하면 편의성도 높아지고 직접 원하는 디자인으로 커스텀할 수 있기 때문이다. 사실 이 발표에서 어떻게 하는지를 알게된 것 보다. 어떤 생각을 갖고 진행되었으며 어떤 과정을 거쳐 완성되었고 어떤느낌을 받았는지 발표자의 생각과 느낌을 듣고 싶었다. 궁금했던 것들을 해소할 수 있었고 좋은 시간이 되었던 것 같다.
(5) 플레이어 SDK 개발자의 Kotlin Multiplatform 도입기 - 모진섭
Naver 비디오 플레이어 SDK개발자의 Kotlin을 사용한 KMP 도입을 발표하는 자리였다. 모든 OS에 사용할 수 있도록 JS를사용하여 개발이 되었다고 한다. 개발과정에서 격는 여러가지 에러사항과 그것을 어떻게 해쳐나갔는지에 대하여 들을 수 있는 자리였다. "Kotlin 개발자로서 다른 OS개발자들의 LearningCurve 때문에 Kotlin 개발자에게 의존적이게 되는 현상"이나, "각각의 OS에 사용된 해당 OS에 최적화된 라이브러리의 사용을 대비하여 어떻게 대처해 나갔는지"에 대하여 논의 할 수 있었다. 이번 발표에서 느낀것은 각각의 개발자가 느끼는 에러사항에 대하여 모두 공통적으로 느끼는 사항이라는 것에 대하여 알 수 있었다. 또한 개발자를 프로젝트에 섭외할 때에도 각자 자신의 커리어에 도움이 되지 않거나 현업에 치여 있어 새로운 프로젝트를 진행할 의사를 긍정적으로 비추지 않는 것에 대해서도 논하게 되었다.
사실 KMP(KMM)자체는 아직 안정적으로 개발할 수 있도록 만들어지지 않았기 때문에 상업적으로 결과물을 낸다는 것은 어려운 일이다. 많은 개발자는 알고 있지만 지금부터 도전하는 이유는 추후 안정화 작업이 진행된 이후에 발생될 시너지 효과와 새로운 분야에 대해 도전하고 싶은 갈망, 그리고 자신이 맡은 프로젝트에 대하여 새롭게 해결해 나가고 싶은 욕구 때문일 것이라고 생각한다. 필자도 KMM에 관심이 많아 이 발표를 듣게 되었지만 아직 이분야에 대하여 깊게 파고들 만큼 발전하지 않은 것 같아 간단한 이론적으로만 알아가기로 했다.
(6) Compose Material3 커스텀 디자인 시스템 구축기 - 권대원
컬리에 근무중인 발표자의 프로젝트로 Compose를 활용하여 앱에 사용되는 UI컴포넌트를 개발하고 재사용성을 만들어 개발 하는 부분에 있어서 디자이너와 개발자가 만들어진 컴포넌트를 활용하여 좀 더 효율적으로 개발에 임할 수 있도록 디자인을 객체화 하는 작업을 진행했다고 한다. 각각 컴포즈 컴포넌트들을 사용하는 부분에 있어서 디자이너와 상호 협의하여 공통적으로 사용할 수 있게 만들고 디자이너가 개발자에게 디자인 변경 요청하는 부분에 있어 좀 더 정확한 의견 전달과, 개발자가 디자이너에게 받은 요청사항에 대하여 좀 더 정확하게 파악하여 개발 방향과, 제안 오류에 대하여 시간을 최소화 하고 다른 개발에 집중 할 수 있는 시간을 확보하는 것이 목표라고 한다.
KPDS의 구성은 다음과 같다.
- Core-Component
- Button
- Topbar
- Dialog
- Image
- TextField..
- Foundation
- Color
- Typography
- Icon
- Spacing
- Radius...
다음과 같이 나누어 컴포넌트를 구성하고 정해진 컴포넌트를 가지고 디자이너가 수정요청을 하는것이다. 이렇게 컴포즈는 디자이너와 개발자를 한대 묶어 같이 개발할 수 있는 계기도 마련하는 것 같다. 비록 컴포즈를 활용하는 것에 국한되어 있지만, 향후 안드로이드 개발도 프론트엔드처럼 UI부분에 있어 디자이너와 같은 공통 분야가 생기지 않을까 하는 생각도 하게 되었다.
