Navigation Compose 전환 순서

Navigation Compose로 전환할 때 가장 위험한 선택은 화면을 보이는 대로 하나씩 바꾸는 것입니다. UI는 Compose로 바뀌었는데 navigation, argument, ViewModel 경계가 그대로 남으면 구조가 더 복잡해질 수 있습니다.

전환의 핵심은 화면을 Compose로 바꾸기 전에 이동 경로와 상태 소유권을 먼저 정리하는 것입니다. 이 글은 Fragment Navigation에서 Navigation Compose로 옮길 때의 현실적인 순서를 정리합니다.

Navigation Compose 전환 전에 먼저 정할 것

Fragment Navigation에서 Navigation Compose로 옮긴다는 것은 XML 화면을 Compose 함수로 바꾸는 일만 뜻하지 않습니다. 화면 이동 방식, argument 전달 방식, back stack 처리, ViewModel scope까지 같이 바뀝니다.

그래서 처음에는 어떤 화면을 먼저 Compose로 만들지보다 navigation 경계를 먼저 봐야 합니다. 앱 전체를 한 번에 바꾸기 어렵다면 특정 feature 단위로 경계를 잡고, 그 안에서만 Compose navigation을 적용하는 방식이 현실적입니다.

route를 문자열로만 방치하지 않기

Navigation Compose는 route 문자열을 사용합니다. 작은 예제에서는 “detail/{id}” 같은 문자열이 충분하지만, 화면이 늘어나면 오타와 argument 누락이 자주 생깁니다.

처음부터 타입 안전 route까지 도입하지 않더라도 route를 한 곳에 모아 관리하는 습관은 필요합니다. 화면 이름, 필수 argument, optional argument를 흩어두지 않는 것만으로도 전환 비용이 줄어듭니다.

object Routes {
    const val Home = "home"
    const val Detail = "detail/{itemId}"

    fun detail(itemId: Long): String = "detail/$itemId"
}

object Routes {
    const val Home = "home"
    const val Detail = "detail/{itemId}"

    fun detail(itemId: Long): String = "detail/$itemId"
}

Fragment와 Compose를 섞는 기간

대부분의 실제 앱은 Fragment를 모두 지우고 Compose로 다시 만들 수 없습니다. 한동안 Fragment 안에 ComposeView를 넣거나, Compose 화면에서 기존 View 기반 화면으로 넘어가는 혼합 기간이 생깁니다.

이 기간에는 규칙이 필요합니다. 어떤 화면은 Fragment Navigation이 소유하고, 어떤 feature는 Compose NavHost가 소유하는지 정하지 않으면 back stack 흐름이 흐려집니다.

• 앱 루트 navigation은 당분간 기존 Fragment Navigation이 맡는다
• 새 feature 내부 화면 이동은 Compose NavHost로 묶는다
• feature 밖으로 나가는 이동은 명시적인 callback으로 올린다
• 공유 ViewModel scope를 화면 단위로 다시 확인한다

ViewModel 공유를 다시 보기

Fragment에서는 navGraphViewModels, activityViewModels 같은 패턴으로 ViewModel scope를 나눴을 수 있습니다. Compose로 옮기면 hiltViewModel이나 backStackEntry 기반 ViewModel 사용 방식이 달라질 수 있습니다.

전환 중 가장 흔한 문제는 상태 소유권이 애매해지는 것입니다. 화면 상태는 해당 route에 가깝게 두고, 여러 화면이 공유하는 작업 상태는 feature graph 수준에서 소유하는 편이 좋습니다.

단계적 마이그레이션 순서

1. 기존 navigation graph에서 feature 경계를 표시한다
2. 새로 만들거나 변경이 잦은 feature 하나를 고른다
3. route와 argument 규칙을 먼저 만든다
4. feature 내부 화면만 Compose NavHost로 묶는다
5. Fragment 밖으로 나가는 이동은 callback으로 연결한다
6. ViewModel scope와 saved state 사용 지점을 검토한다

자주 깨지는 지점

• argument를 문자열로 직접 이어 붙여 encoding 문제가 생긴다
• Fragment back stack과 Compose back stack이 동시에 같은 흐름을 소유한다
• ViewModel scope가 바뀌어 화면 재진입 때 상태가 사라진다
• 기존 deep link를 새 route 구조에 맞춰 검증하지 않는다

정리

Navigation Compose 전환은 UI 프레임워크 교체가 아니라 이동 구조를 다시 정리하는 작업입니다. 화면을 먼저 바꾸기보다 route, argument, ViewModel scope, Fragment 혼용 기간의 규칙을 먼저 세우는 편이 안전합니다.

관련 글은 collectAsStateWithLifecycle 사용 기준, Compose 상태 호이스팅은 언제 해야 할까, StateFlow와 SharedFlow 차이를 함께 보면 좋습니다. 외부 기준은 Android Developers – Navigation with Compose, Android Developers – Migration strategy, Android Developers – Interoperability APIs를 확인했습니다.