Jetpack Compose 입문: 선언형 Android UI 실전 가이드
Compose는 상태 소유권이 명확할 때 강하다
Compose는 상태가 바뀌면 UI를 다시 계산합니다. 그래서 실무에서는 상태를 어디에 둘지 더 중요해집니다.
일반적으로는 다음 구조가 안정적입니다.
ViewModel이 화면 상태와 부수 효과를 소유한다- Composable은 불변 상태를 받아 렌더링한다
- 사용자 입력은 콜백으로 위로 올린다
이렇게 하면 화면 테스트와 재사용이 쉬워집니다.
상태 끌어올리기는 나중 문제가 아니다
탭, 다이얼로그, 새로고침, 복원, 내비게이션이 섞이기 시작하면 상태를 어디에 둘지에 따라 유지보수성이 크게 갈립니다. 모든 상태를 위로 올릴 필요는 없지만, 여러 UI 조각이 함께 판단해야 하는 값은 초기에 끌어올려 두는 편이 안전합니다.
핵심은 높이 그 자체가 아니라 책임의 명확성입니다.
재사용 컴포넌트는 도메인 의미를 잃지 않아야 한다
Compose는 추출이 쉬워서 오히려 너무 빨리 추상화하기 쉽습니다. CustomBox2, CommonWrapper 같은 이름은 코드량은 줄여도 의미를 숨깁니다. 실전에서는 PaymentSummaryCard, RiskWarningBanner처럼 도메인 의미가 드러나는 이름이 더 오래 갑니다.
성능과 리스트에서 구조가 드러난다
Compose 성능 문제의 상당수는 Compose 자체보다 불안정한 파라미터, composition 안의 무거운 계산, 잘못 설계된 리스트에서 시작됩니다. 큰 리스트는 LazyColumn을 쓰고, 항목 정체성을 안정적으로 유지하고, 비싼 계산은 UI 밖으로 빼는 것이 기본입니다.
출시 전 리뷰 포인트
- 상태가 적절한 수준으로 끌어올려졌는가
- 부수 효과가 lifecycle을 고려해 동작하는가
- Preview가 정상 상태뿐 아니라 실패와 빈 상태도 다루는가
- 폼과 리스트, 구성 변경에서 사용자 입력이 보존되는가
- 접근성과 포커스 이동이 의도적으로 설계되었는가
Compose의 장점은 최신 기술이라는 점보다 상태 모델과 UI 동작을 더 밀접하게 연결해 준다는 데 있습니다. 그 규율을 받아들이는 팀일수록 개발 속도도 빨라지고 디버깅 비용도 줄어듭니다.
Continue Reading
다음으로 읽기 좋은 글
모바일 앱 시작 시간 예산 플레이북
앱 시작 속도는 감으로 개선되지 않습니다. 콜드 스타트와 웜 스타트를 나눠 예산화하는 실전 기준을 정리합니다.
📱 Mobile모바일 학습 경로: 입문부터 고급까지
UI 기초부터 릴리스 통제, 관측성, 크로스플랫폼 판단까지 체계적으로 배우는 모바일 로드맵입니다.
💬 LanguageJava 개발자를 위한 Kotlin 실전 가이드
Kotlin을 Java의 짧은 대체 문법이 아니라, null safety, 상태 모델링, coroutine 구조까지 바꾸는 언어로 보고 실무 기준으로 정리합니다.
📚 IT 이야기안드로이드는 어떻게 모바일의 주류가 되었나
스마트폰 시장이 피처폰 시대에서 플랫폼 경쟁으로 넘어가던 순간, 안드로이드는 어떻게 가장 넓은 생태계를 만든 운영체제가 되었을까요.
다음 탐색