2007년에 설립된 Airbnb는 현재 전 세계 4백만 명이 넘는 집주인, 즉 호스트와 10억 명이 넘는 손님, 즉 게스트를 연결하도록 성장했습니다. Airbnb 앱의 성공 비결은 혁신적인 개발을 촉진하는 기술 사용과 숨은 공로자인 엔지니어의 역량 강화라는 두 가지 개발 원칙에 집중하는 것이었습니다.
Android의 최신 UI 개발 툴킷인 Jetpack Compose는 Airbnb의 이 두 가지 개발 원칙을 직접적으로 지원합니다. Compose는 적응성과 품질이 뛰어난 엔지니어링과 줄어든 상용구 코드에 적합한 탄탄한 기반을 제공하므로 개발자들은 뛰어난 사용자 경험을 제공하는 데 주력할 뿐만 아니라 두 가지 원칙을 바탕으로 한 기술적 진일보를 이뤄낼 수 있었습니다.
Airbnb는 Compose가 개발자 프리뷰로 제공되었던 2020년에 테스트를 시작했습니다. Airbnb는 얼리 어답터로서 열정적인 자세로 새로운 기능을 사용하고 워크플로를 단순화했습니다. 실제 프로덕션 환경에서 Compose를 사용하며 자신감을 얻은 Airbnb 엔지니어들은 Compose로 인해 개선된 개발 프로세스에 여전히 만족도가 높습니다.
엔지니어를 위한 개발 경험 개선
Airbnb의 엔지니어들은 Compose의 결정론적 테스트를 통해 자체 실행했던 UI 테스트를 철저히 제어하고 잦은 결함을 제거함으로써 사용자 경험 및 앱의 모든 부분에 대한 품질을 대폭 개선했습니다. Compose를 사용해 이전에는 불가능했던 애니메이션 테스트도 수행할 수 있었습니다.
마찬가지로, Airbnb 개발자들은 Compose를 사용해 자동화된 스크린샷 테스트를 코드베이스에 추가했습니다. 스크린샷 테스트를 위한 코드를 따로 작성할 필요가 없어 버그와 회귀를 바로 감지하고, 다양한 기기에서 기능과 UI가 제대로 구현되었는지 검토하고 보장하는 데 더 많은 시간을 할애할 수 있었습니다.
Compose는 View와도 호환성이 좋습니다. 덕분에 Airbnb 엔지니어는 이 새로운 UI 툴킷을 자신의 페이스에 맞춰 손쉽게 온보딩하고 테스트했으며, 전체 기능을 마이그레이션할 필요 없이 Compose의 이점을 누릴 수 있었습니다.
이처럼 엔지니어링 요소를 개선하여 새롭고 향상된 방식으로 이용자에게 서비스를 제공하는 데 필요한 탄탄한 기술 기반을 마련하였습니다.
효율적인 엔지니어링으로 사용자 경험 개선
Airbnb의 의사 결정의 중심에는 늘 호스트와 게스트가 있습니다. 엔지니어링 팀은 Compose를 채택한 후 UI를 더 쉽고 효율적으로 구현해 최종 사용자에게 더 나은 경험을 제공할 수 있었습니다.
Compose를 사용하니 Airbnb의 기능을 구현하는 데 필요한 코드 수가 확연히 줄어들어 업무 효율성이 높아졌습니다. 덕분에 Airbnb는 사용자에게 최상의 서비스를 제공할 수 있는 혁신적인 기능 개발과 관련된 복잡한 작업을 실행하는 데 에너지를 집중할 수 있었습니다.
기능 구현을 위한 코드 수가 줄어들어, Airbnb는 장기적으로 앱 크기의 증가세를 늦출 수 있습니다. 전 세계 곳곳의 수많은 호스트와 게스트(특히 오래된 기기를 사용하거나 데이터 요금이 비싼 국가에서 로그인하는 사용자)가 앱을 손쉽게 다운로드하고 액세스할 수 있도록 보장하기 위해 Airbnb는 앱 크기를 작게 유지하고자 합니다.
Airbnb는 Compose의 엔지니어링 개선 사항을 통해 사용자의 요구사항을 우선시할 수 있었습니다.
Compose로 개발자 생산성 향상하기
Compose 덕분에 UI 개발 과정이 간소화되면서, Airbnb 엔지니어들은 호스트와 게스트에게 이익이 되는 더욱 역동적이고 혁신적인 기능을 개발하는 데 집중할 수 있었습니다.
이 팀들은 복잡한 대규모 프로덕션 환경에서 Compose를 사용하고 신중하게 평가하며 더 쉽고 명확한 UI 개발 경험뿐 아니라 엔지니어링 측면에서도 다양한 이점을 경험했습니다! 현재 Play 스토어 상위 1,000개 앱 중 100개 이상이 Compose를 사용하므로, 이 같은 사례는 더욱 늘어날 것입니다.
저희는 늘 개발 과정 및로드맵 설계에 있어 이처럼 폭넓은 Android 커뮤니티와 긴밀히 협력하며 피드백에 귀 기울이고 있습니다. 따라서 고급 사용 사례를 지원하는 데 중점을 두고 Compose로 앱을 더 쉽게 구축할 수 있도록 기능을 개선했고 새 API와 도구도 제공합니다. Compose는 완전히 새로운 UI 구축 방식을 제시합니다. 그래서 여러분이 Compose에 적응해 외관과 기능 모두 탁월한 앱을 만들 수 있도록 가이드라인, 세션, 고급 토픽에 관한 Codelab을 비롯해 더 심도 있는 영상을 준비했습니다. 이제 새 기능을 소개합니다.
Issue Tracker에서문제로 손꼽히는 버그 중 하나를 처리하기 위해 includeFontPadding을 맞춤설정이 가능한 매개변수로 만들었습니다. 이 값을 false로 설정해야 텍스트가 레이아웃 내에 더 정확히 정렬할 수 있으므로 이 값을 설정하는 것이 좋습니다. 이후 버전에서는 이를 기본값으로 확정하려고 합니다. 만약 값을 false로 설정했을 때 앱에 문제가 생기면 저희에게 알려 주시기 바랍니다. 또한, includeFontPadding을 false로 설정하면 lineHeightStyle 매개변수를 바꿔 Text 컴포저블의 줄 높이를 조정할 수 있습니다. 종합하면 다음과 같은 모습입니다.
여러 줄 텍스트에서 includeFontPadding을 true로 설정한 경우 (왼쪽, 현재 기본값) vs false로 설정하고 lineHeightStyle을 사용한 경우 (오른쪽)
다운로드 가능한 글꼴
Compose 1.2에는 Compose에서다운로드 가능한 글꼴을 추가했습니다. Compose의 새 API로 Google Fonts에 비동기식으로 접근하고, 복잡한 설정 없이도 대체 글꼴을 정의할 수 있습니다. 다운로드 가능한 글꼴 덕분에 여러 앱에서 같은 글꼴을 공유하여 APK 크기를 작게 유지하고 사용자의 시스템 상태를 향상할 수 있습니다.
텍스트 돋보기
Android 텍스트에는 돋보기 위젯이 제공되어 텍스트를 쉽게 선택할 수 있습니다. 이제 Compose도 텍스트 돋보기를 지원합니다.
선택 핸들을 드래그하면 돋보기가 나타나 손가락 아래 무슨 텍스트가 있는지 볼 수 있습니다. Compose 1.1.0에서는 텍스트 필드 내 선택된 영역에 돋보기를 적용했지만, Compose 1.2.0에서는 텍스트 필드와SelectionContainer 모두 지원합니다. 또한, 돋보기를 개선하여 Android 돋보기의 동작이 View와 일치하도록 만들었습니다.
스크롤 컴포저블을 뷰 시스템의 CoordinatorLayout에 삽입할 때, 스크롤 동작을 상호 운용 가능하도록 만들 수 있습니다. 이 덕분에 접기 방식 툴바(collapsible toolbar) 설정이 간편해졌습니다. 새로운 실험용 rememberNestedScrollInteropConnection 메서드를 호출한 결과를 nestedScroll 수정자로 전달하여 이 동작을 옵트인할 수 있습니다. 이 새로운 기능을 구현한샘플을 확인해 보세요.
크기 조절이 가능한 레이아웃을 쉽게 디자인 및 개발하고 테스트할 수 있도록 체계적인 표시 영역 중단점인 창 크기 클래스를 출시했습니다. 현재 Material 3 라이브러리 세트 중 하나인 새 라이브러리material3-window-size-class의 알파 버전에서 사용할 수 있습니다. 창 크기 클래스에 관한 자세한 내용은다양한 화면 크기 지원을 다룬 문서와Crane에서 구현한 샘플을 참고하시기 바랍니다.
성능 중심
여러분의 앱 성능 이해와 개선에 도움을 드리기 위해 새로운 성능 도구와 가이드라인을 제공하는 데 중점을 두었습니다. 이를 통해 앱이 느려지는 이유와 상황을 수월하게 이해할 수 있습니다.
Android Studio Dolphin에서 Layout Inspector를 사용해 컴포저블이 얼마나 자주 재구성하는지 검사하고, 재구성이 지나치게 많이 발생한 컴포저블을 최적화할 수 있습니다. Android Studio Electric Eel에는 재구성 하이라이터가 추가되어 어떤 컴포저블이 언제 재구성하는지 시각적으로 파악할 수 있습니다. 이 새 도구에 관한 자세한 내용은 Android Studio에 관한 새로운 소식을 다룬 블로그에서 확인하실 수 있습니다.
Layout Inspector에서 재구성 횟수와 재구성 하이라이터 확인하기
Compose를 이용해 완전히 새로운 방식으로 UI를 구축하고 앱 성능을 확보하려면 몇 가지 권장사항이 있습니다. 새롭게 공개한문서 페이지에서 최고 성능을 구현하기 위해 Compose 앱을 어떻게 구성하고 설정해야 하는지 확인할 수 있습니다.Jetpack Compose에서 흔히 발생하는 성능 관련 문제를 다룬 I/O 세션에서는 Compose 팀이 흔히 발생하는 성능 관련 문제와 이를 바로잡는 법을 소개합니다.
성능은 저희가 늘 중점을 두는 영역입니다. 이와 관련한 도구와 가이드라인을 개선 및 확장하려 노력하고 있으니, 지금까지의 결과물에 피드백을 주시면 감사하겠습니다.Issue Tracker에 버그를 제출하거나KotlinLang Slack 그룹에 질문을 남겨 주세요.
새로운 도구
기존 기능을 개선했을 뿐만 아니라, Compose를 더 효율적으로 사용할 수 있는 새로운 도구도 업데이트했습니다. 현재 베타 버전인 Android Studio Dolphin에는 Compose 개발을 위한 흥미로운 기능이 추가되었습니다. 새로운 도구로는 재구성 횟수 확인뿐 아니라 모든 애니메이션을 한 번에 보고 수정할 수 있는 애니메이션 조정, 다양한 화면 크기 구축을 돕는 MultiPreview Annotation이 있습니다. Android Studio Electric Eel(Canary)에서는 빠른 반복 작업을 위한 LiveEdit 기능을 제공합니다.
Compose 보다 좋은 건 더 다양한 Compose죠! 드디어 Wear OS용 Compose 베타 버전이 공개되었습니다. 다른 Jetpack 라이브러리와 마찬가지로 베타 버전에서도 완전한 기능과 정식 버전 API를 제공하기 때문에 프로덕션 환경에서 사용 가능한 앱을 구축할 수 있습니다. 자세한 내용은블로그에서 확인해 보세요.
앱 아키텍처 가이드를 현대화할 수 있도록, 저희는 다양한 UI 패턴 중 어떤 것이 가장 효과적인지 살펴보고, 여러 대안 간의 유사점 및 차이점을 확인 및 정리하여 권장 사항으로 알려 드리고자 합니다.
저희가 확인한 사항을 쉽게 알려 드리려면, 너무 복잡하지 않으면서도 친숙한 비즈니스 사례의 예시가 필요했습니다. 그래서... TODO 앱 만드는 법을 모르는 분은 없으시겠죠? 저희가 선택한 앱은 Architecture Blueprints였습니다. Blueprints는 기존에도 여러 아키텍처를 마음껏 실험할 수 있는 공간이었기 때문에 정말 적합한 선택이었습니다.
작동 중인 Architecture Blueprints 앱
최근에는 API 사용이 UI 패턴에 큰 영향을 미칩니다. 그중 주목할 만한한 것이 바로 Jetpack Compose의 상태 API입니다. Compose는 모든 단방향 데이터 흐름 패턴에서 원활하게 작동하므로, 객관적인 비교를 위해 Compose를 사용해 UI를 렌더링했습니다.
이번 블로그 게시물에서는 어떻게 Architecture Blueprints를 Jetpack Compose로 마이그레이션했는 지 알려드리겠습니다. LiveData를 사용하실 분들을 위해 마이그레이션 당시의 샘플을 그대로 두었으며, 리팩터링에서 ViewModel 클래스와 데이터 레이어는 수정하지 않았습니다.
⚠️ 이 LiveData 기반 코드베이스에 사용된 아키텍처는 최신 아키텍처 권장사항을 완벽하게 따르지는 않습니다. 특히 LiveData를 데이터 영역 또는 도메인 레이어에서 사용하면 안 되며, 대신에 플로우와 코루틴을 사용해야 합니다.
주의 사항에 대해 알려드렸으니, 이제 Blueprints를 Jetpack Compose로 리팩터링한 과정에 대해 자세히 알아보겠습니다. dev-compose branch에서 전체 코드를 확인할 수 있습니다.
✍️ 점진적인 마이그레이션 계획
실제로 코드를 작성하기에 앞서, 팀원 사이에 혼선이 일어나지 않도록 마이그레이션 계획을 세웠습니다. 최종 목표는 컴포저블을 이용해 Blueprints를 화면이 있는 단일 활동 앱으로 만들고, 권장 Compose Navigation 라이브러리를 사용해 화면 사이를 이동하는 것이었습니다.
다행히도 Blueprints는 이미 Jetpack Navigation을 사용하여 Fragment로 구현된 다양한 화면 사이를 이동하는 단일 활동 앱이었습니다. Compose로 마이그레이션하기 위해, 저희는 하이브리드 앱을 권장하는 Navigation 호환성 가이드에 따라 Fragment 기반 Navigation 구성요소를 사용하고, Fragment로 뷰 기반 화면, Compose 화면, 그리고 뷰와 Compose를 모두 사용하는 화면을 구현했습니다. 아쉽지만 같은 Navigation 그래프에서는 Fragment 및 Compose 대상을 혼용할 수 없습니다.
점진적 마이그레이션의 목표는 마이그레이션 과정 내내 코드 리뷰를 용이하게 하고 제품을 출시 가능한 상태로 유지 관리 하는 것입니다. 마이그레이션 계획은 다음과 같습니다.
각 화면의 콘텐츠를 Compose로 마이그레이션합니다. UI 테스트를 포함한 각 화면을 개별적으로 마이그레이션할 수 있습니다. 그런 다음 Fragment는 마이그레이션된 각 화면의 컨테이너/호스트가 됩니다.
Navigation Compose로 앱을 마이그레이션하여 프로젝트에서 모든 Fragment를 제거하고, Activity UI 로직을 루트 컴포저블로 마이그레이션합니다. 엔드 투 엔드 테스트도 이 단계에서 마이그레이션됩니다.
View 시스템 종속성을 제거합니다.
저희가 한 일이 바로 이것입니다! 🧑💻 2주간의 내용을 빨리 감기 ⏩ 로 돌이켜보면, 저희는 통계 화면(PR), 추가/편집 작업 화면(PR), 작업 세부정보 화면(PR), 작업 화면(PR)을 마이그레이션하고, Navigation 및 Activity 로직을 Compose로 마이그레이션한 후, 사용하지 않는 View 시스템 종속성 제거까지 마친 최종 PR을 병합했습니다.
Blueprints를 Compose로 점진적 마이그레이션 하는 방법
💡 마이그레이션 주요 사항
마이그레이션 과정에서 Compose와 관련해 몇 가지 유의할 만한 특이 사항을 확인할 수 있었습니다.
엔드 투 엔드 또는 통합 테스트에서도 문제를 전혀 찾지 못했습니다! Espresso와 Compose의 호환성 덕분에, 저희는 Espresso 어설션을 사용해 Views를 확인하고 Compose API를 사용해 Compose UI를 확인합니다. Compose로 마이그레이션하는 과정에서 AppNavigationTest가 어떻게 구현되는지 확인해 보시기 바랍니다.
🤙 ViewModel 이벤트
Blueprints에서 ViewModel 이벤트가 제대로 처리되지 않았습니다. Blueprints는 ViewModel에서 UI로 명령을 보내는 이벤트 래퍼 솔루션을 사용하는데, 이는 Compose에서 원활하게 작동하지 않습니다. 저희는 마이그레이션 동안 이러한 '이벤트'를 상태로 모델링했고, 최근 가이드에도 권장사항으로 포함해 두었습니다.
저희는 화면에 메시지 표시 이벤트 사용 사례를 살펴보면서 LiveData의 Event<Int> 형식을 Int?로 바꾸었습니다. 이 형식에서는 표시할 메시지가 없는 경우의 시나리오도 모델링합니다. 이러한 특정 사용 사례에서는 메시지가 표시될 때마다 UI를 통해 ViewModel을 확인해야 합니다. 다음 코드에서 두 방식의 차이점을 확인해보시기 바랍니다.
얼핏 보기에는 작업량이 더 많아 보이지만, 이 방식을 사용하면 예외 없이 메시지를 화면에 표시할 수 있습니다!
UI 코드에서 이벤트가 한 번만 처리되도록 하려면 event.getContentIfNotHandled()를 호출하는 방법이 있습니다. 이 방법은 Fragment에서는 그럭저럭 괜찮게 작동하지만, Compose에서는 완전히 무용지물이 됩니다! Compose에서는 언제든지 재구성(Recomposition)이 발생할 수 있으므로, 이벤트 래퍼는 유효한 해결책이 아닙니다. 이벤트가 처리되고 함수가 재구성되면(이 방법을 테스트하는 동안 매우 정기적으로 발생) 스낵바가 취소되어 사용자가 메시지를 놓칠 수 있습니다. 절대 발생하면 안 되는 UX 문제죠! Compose 앱에서 이벤트 래퍼 솔루션을 사용해서는 안 됩니다.
특정 시나리오에서 일부 함수를 재구성하지 않는 Compose 코드를 작성할 수도 있지만, 이 경우 이벤트 래퍼 솔루션으로 인해 UI 구현이 제한될 수 있습니다. Compose에서는 이벤트 래퍼 솔루션 사용을 권장드리지 않습니다.
아래의 코드 스니펫에서 이전 (이벤트 래퍼) 코드와 이후 (이벤트를 상태로 모델링) 코드를 비교해 보시기 바랍니다. 화면에 메시지를 표시하는 것은 UI 로직이고 화면 컴포저블이 점점 복잡해지고 있었으므로, 저희는 일반 상태 홀더 클래스를 사용하여 코드를 단순화했습니다(예: AddEditTaskState 참조).
👌 불확실할 때는 앱 정확성을 선택하세요
리팩터링하는 동안 모든 것을 Compose로 마이그레이션하고 싶을 수도 있습니다. 물론 그래도 괜찮지만, 앱의 사용자 환경이나 정확성을 훼손해서는 안 됩니다. 점진적 마이그레이션의 핵심은 앱을 항상 출시 가능한 상태로 유지하는 것입니다.
일부 화면을 Compose로 마이그레이션하는 동안 저희도 이런 충동을 느꼈습니다. 그러나 너무 많은 작업을 동시에 수행할 수는 없기에, 이벤트 래퍼에서 마이그레이션하기 전에 일부 화면을 Compose로 마이그레이션했습니다. Compose에서 이벤트 래퍼를 사용하면 사용자에게 최선의 환경을 제공할 수 없으므로, 화면의 나머지 코드를 Compose에 놔둔 채 Fragment에서 해당 메시지를 계속 처리했습니다. 그 예로 마이그레이션 중 TasksFragment의 상태를 살펴보세요.
🧐 당면 과제
모든 것이 보이는 것처럼 순조롭지는 않았습니다. 🫤 Fragment 콘텐츠를 Compose로 변환하는 것은 간단하지만, Navigation Fragment에서 Navigation Compose로 마이그레이션하는 데 시간이 꽤 걸렸고 고려할 점도 좀 더 많았습니다.
앞으로 Compose로 더 쉽게 마이그레이션할 수 있도록 다양한 측면에서 가이드를 확장하고 개선해야 한다는 목소리도 있습니다. 이 작업이 토론의 불씨가 되어, 곧 새로운 가이드가 나오기를 바랍니다! 🎊
Navigation 초보자이자 ✋ Navigation Compose 마이그레이션을 수행한 사람으로서, 저는 다음과 같은 문제에 직면했습니다.
문서의 어떤 코드에도 선택적 인수로 탐색하는 방법이 나와 있지 않았습니다! 결국 Tivi의 Navigation 그래프 덕분에 실마리를 얻어 문제를 해결했습니다(여기에서 이슈를 확인하고 의견을 전달할 수 있습니다).
XML 기반 Navigation 그래프와 SafeArgs에서 Kotlin DSL로 마이그레이션하는 일은 간단하고 기계적인 작업입니다. 하지만 기존 구현 작업에 참여하지 않았던 저에게는 그다지 쉽지 않은 일이었습니다. 이 작업에 대한 올바른 가이드가 있었다면 큰 도움이 되었을 것입니다(여기에서 이슈를 확인하고 의견을 전달할 수 있습니다요).
이 문제는 당면 과제보다는 간과하기 쉬운 점에 가깝습니다! NavigationUI가 탐색에 관한 일부 작업을 이미 대신 처리하지만, Compose에서는 이 UI를 사용할 수 없으므로 문제를 계속 주시하면서 수동으로 탐색 작업을 처리해야 합니다. 예를 들어 Drawer 화면 사이를 이동할 때 백 스택을 정리된 상태로 유지하려면 특별한 NavigationOptions가 필요합니다(여기에서 예시 참조). 이는 이미 문서에서 다룬 내용이지만, 계속해서 예의 주시 할 필요가 있습니다!
🧑🏫 결론
Navigation Fragment에서 Navigation Compose로 마이그레이션하는 건 재미있는 작업이었습니다! 실제로 프로젝트를 마이그레이션하는 시간보다 동료 리뷰를 받아 보는 시간이 더 길었다는 점도 예상치 못한 즐거움이었죠. 마이그레이션 계획을 세우고 모두가 내용을 미리 숙지한 덕분에, 조기에 기대치를 설정하고 많은 리뷰를 받을 수 있었습니다.
저희의 Compose 마이그레이션 도전기를 재미있게 읽으셨기를 바라며, 앞으로 Architecture Blueprints에서 수행할 실험 및 개선 사항도 적극적으로 공유드리겠습니다.
Compose 코드로 구현한 Blueprints를 보고 싶으시면 dev-composebranch를 살펴보세요. 그리고 점진적 마이그레이션의 PR을 살펴보고 싶으시면 아래 목록을 참조하시기 바랍니다.
