안드로이드 Navigation Component와 FragmentManager 차이는 화면을 바꾸는 API 차이로만 보면 오히려 더 헷갈립니다. 실무에서는 화면 전환의 규칙을 프레임워크에 맡길지, 직접 제어할지를 먼저 정하는 편이 훨씬 낫습니다.
이번 글에서는 back stack, 화면 결과 전달, deep link, 복잡한 전환 제어 관점에서 무엇을 선택하면 좋은지 정리합니다. single activity 구조를 고민 중이라면 안드로이드 single activity 구조는 왜 많아졌을까 글과도 자연스럽게 이어집니다.
먼저 차이부터 짧게 정리
- Navigation Component는 화면 이동 규칙을 graph 중심으로 관리하는 도구에 가깝다
- FragmentManager는 FragmentTransaction과 back stack을 직접 제어하는 저수준 도구에 가깝다
- 단순히 어느 쪽이 더 최신인지보다 얼마나 직접 제어해야 하는지가 더 중요하다
한 줄로 줄이면 정형화된 흐름은 Navigation Component, 세밀한 전환 제어는 FragmentManager가 더 잘 맞습니다.
Navigation Component는 화면 간 이동 규칙이 비교적 분명할 때 강합니다. 목록에서 상세로 이동하고, 로그인 이후 홈으로 가고, deep link로 특정 화면을 열고, app bar와 뒤로 가기 동작을 맞추는 흐름처럼 앱 전체에 공통 규칙이 있는 전환에서 특히 편합니다.
- 화면 흐름을 navigation graph로 한눈에 보고 싶을 때
- deep link, app bar, up navigation을 구조적으로 맞추고 싶을 때
- 팀원이 늘어도 화면 이동 규칙을 일관되게 유지하고 싶을 때
이때의 장점은 편의 기능 자체보다 흩어지기 쉬운 화면 이동 규칙을 한 군데로 모은다는 점입니다. Android Developers의 Navigation 문서가 계속 강조하는 부분도 바로 이 구조화입니다.
FragmentManager를 직접 다루는 편이 나은 경우
반대로 모든 화면 전환이 graph로 잘 정리되는 것은 아닙니다. 탭마다 back stack을 따로 유지해야 하거나, 여러 컨테이너를 동시에 다뤄야 하거나, dialog·bottom sheet·임시 fragment 교체처럼 전환 자체가 UI 제어 로직에 가까운 경우도 있습니다.
- 여러 back stack을 세밀하게 다뤄야 할 때
- 한 화면 안에서 fragment를 부분 교체하는 구성이 많을 때
- 화면 전환보다 동적 UI 조립의 비중이 더 클 때
이런 경우에는 FragmentManager를 직접 다루는 편이 오히려 덜 우회적입니다. 너무 일찍 Navigation Component에 모든 전환을 욱여넣으면 graph는 늘어나는데, 정작 예외 처리는 여기저기 흩어지는 경우가 생깁니다.
back stack에서 체감되는 차이
두 도구의 차이는 back stack에서 가장 선명하게 드러납니다. FragmentManager를 직접 쓰면 addToBackStack 여부, pop 시점, 특정 transaction 단위 제어를 더 명시적으로 만질 수 있습니다. Navigation Component를 쓰면 이런 제어를 nav graph와 action, popUpTo 같은 규칙으로 표현하게 됩니다.
즉 FragmentManager는 조작에 가깝고, Navigation Component는 선언에 가깝습니다. 어느 쪽이 더 쉬운지는 팀이 겪는 복잡도의 종류에 따라 달라집니다.
// FragmentManager 직접 제어 예시
parentFragmentManager.beginTransaction()
.replace(R.id.container, DetailFragment())
.addToBackStack(null)
.commit()이 코드는 단순하지만, 화면 결과 처리·app bar 동기화·deep link·복수 진입 경로까지 늘어나면 직접 관리해야 할 규칙이 빠르게 많아집니다.
실무에서 자주 하는 오해
그렇지 않습니다. Navigation Component도 결국 Fragment 기반 전환 위에서 동작합니다. 예외 상황을 이해하려면 FragmentManager와 back stack 감각이 여전히 필요합니다.
FragmentManager를 직접 쓰면 구조가 더 유연하다
유연한 것은 맞지만, 규칙이 커질수록 팀 내 일관성이 무너지기 쉽습니다. 유연함이 늘수록 관리 비용도 같이 늘어난다고 보는 편이 정확합니다.
둘 중 하나만 순수하게 써야 한다
실무에서는 혼합도 흔합니다. 큰 화면 이동은 Navigation Component로 두고, 일부 dialog나 child fragment 제어는 FragmentManager로 직접 다루는 식입니다. 중요한 것은 혼합 자체가 아니라 경계를 의식적으로 나누는 것입니다.
선택 기준 다섯 가지
- 화면 흐름이 graph로 표현되면 Navigation Component가 유리하다
- 예외 전환이 많고 세밀한 제어가 핵심이면 FragmentManager가 낫다
- deep link와 app bar 통합이 중요하면 Navigation Component가 편하다
- 동적 UI 조립이 많으면 FragmentManager를 직접 쓰는 편이 단순할 수 있다
- 팀 전체 규칙을 통일해야 하면 선언형 graph가 유지보수에 유리하다
핵심은 최신 도구를 따르는 것이 아니라 복잡도를 어디에 둘지 결정하는 것입니다. 전환 규칙의 복잡도를 프레임워크에 맡길지, 코드로 직접 감당할지를 먼저 고르면 선택이 훨씬 쉬워집니다.
팀 운영 관점에서 보면 더 분명해진다
혼자 개발하는 앱에서는 FragmentManager 직접 제어가 크게 부담되지 않을 수 있습니다. 하지만 팀 개발로 넘어가면 화면 이동 규칙이 코드 여러 군데에 흩어지는 순간부터 유지보수 비용이 커집니다. 이때 Navigation Component의 장점은 API 편의보다 팀 공통 규칙을 강제하기 쉽다는 데 있습니다.
- 새 팀원이 들어와도 graph를 먼저 보면 흐름을 읽기 쉽다
- 뒤로 가기, app bar, deep link 같은 규칙을 화면마다 따로 다시 쓰지 않아도 된다
- 예외 흐름이 생기면 그 예외가 정말 필요한지 더 빨리 보인다
실수하기 쉬운 사례
예를 들어 상세 화면으로 이동하는 코드를 Fragment 곳곳에서 직접 transaction으로 작성하면, 어떤 화면은 back stack에 넣고 어떤 화면은 넣지 않는 식의 차이가 생기기 쉽습니다. 처음에는 작은 차이 같아도, 나중에는 뒤로 가기 경험이 화면마다 달라져 앱이 산만하게 느껴집니다.
반대로 Navigation Component를 도입했는데도 모든 예외 흐름을 action과 graph에 억지로 우겨 넣으면 graph만 커지고 해석은 오히려 어려워질 수 있습니다. 그래서 중요한 것은 도구 선택 자체보다 어디까지를 공통 규칙으로 보고, 어디부터를 예외 제어로 볼지를 나누는 일입니다.
마무리
안드로이드 Navigation Component와 FragmentManager 차이는 편의 기능 차이보다 제어 범위와 구조화 수준의 차이에 가깝습니다. 화면 흐름이 비교적 정형화되어 있다면 Navigation Component가, 복잡한 동적 제어가 핵심이라면 FragmentManager가 더 자연스럽습니다.
처음부터 완벽한 정답을 찾기보다, 현재 앱의 back stack 규칙과 예외 전환이 어디에서 생기는지부터 적어보면 선택이 훨씬 선명해집니다. 공식 기준은 Android Developers Navigation 문서도 함께 참고해보세요.
