Composable UI vs Fragment의 차이점

1. 역할과 책임의 차이
   • Composable: Composable은 UI를 함수형으로 선언하는 방식에 중점을 두며, UI 상태 관리에 최적화되어 있다. UI 구성에 필요한 최소한의 상태와 로직만 포함하는 것이 이상적이다. 비UI 로직이 필요하다면 이를 뷰모델이나 외부 상태 관리로 위임하고, Composable은 주로 화면에 그려지는 역할에 집중한다.
   • Fragment: Fragment는 안드로이드 전통적으로 UI와 비UI 로직을 혼합해서 사용할 수 있는 구조를 제공한다. Fragment 자체가 LifecycleOwner로, 권한 요청, 데이터 로드, 네비게이션 등 다양한 부수 효과나 생명주기 기반 로직을 직접 포함할 수 있어 앱 전반의 UI와 비UI 기능을 혼합해 관리하는 데 적합하다.
2. 상태 관리 및 생명주기
   • Composable은 컴포즈의 선언적 방식에 맞춰 상태(state)와 이벤트(event)를 이용해 화면을 그리며, 이 상태가 변경될 때만 UI를 재구성하는 방식으로 동작한다. 생명주기를 직접적으로 가지지 않고, 상태에 따라 컴포저블이 필요할 때마다 구성되고 해제된다.
   • Fragment는 Android 생명주기(Lifecycle)를 갖고 있어, onCreate, onStart, onStop 등을 통해 상태를 지속적으로 관리할 수 있다. 권한 요청이나 네트워크 호출 같은 부수 효과도 생명주기를 직접 참조해 처리하는 것이 자연스러워, 특정 상태에서만 유지되어야 하는 데이터를 다루기 쉽다.
3. 부수 효과 처리
   • Composable에서는 부수 효과를 위해 LaunchedEffect, remember, DisposableEffect 같은 컴포즈 전용 API가 제공되며, 이러한 부수 효과들은 Composable의 재구성(recomposition)에 의해 영향받는 특성을 갖는다. 즉, Composable 내 부수 효과는 UI 상태 변화와 긴밀히 연관된다.
   • Fragment에서는 생명주기를 기반으로 한 클래식한 부수 효과 관리가 가능하다. onCreate나 onResume에서 부수 효과를 실행하고, onPause, onDestroy에서 정리할 수 있어 Activity와 보다 직접적으로 상호작용할 수 있다.

그렇다면 Fragment도 UI와 비UI 로직을 따로 관리하는가?

⇒ 따로 관리, 혼합 관리 모두 가능하다.

Fragment도 상태와 로직을 뷰모델이나 다른 클래스로 분리하여 관리할 수 있지만, 구조적으로 이를 모두 포함할 수 있는 유연성이 있다. Fragment는 생명주기와 연동된 로직을 기본적으로 가질 수 있고, 이 덕분에 권한 요청이나 네비게이션 등의 로직을 쉽게 다룰 수 있다. 반면에 Composable은 기본적으로 UI 역할에 집중하기 때문에, 권한 요청 같은 로직은 Activity에서 처리하고 UI만 전달하는 방식이 권장될 수 있다.

따라서, Fragment와 달리 Composable은 UI와 상태 변화에 더 집중된 구조이며, 비UI 로직을 직접 관리하는 것보다는 필요한 부수 효과를 UI 흐름 내에서 처리하는 것이 적합하다.