Refactor: Scaffold/Overlay in FeelinNavHost needs responsibility seperation

[gdaegeun539]

현재 FeelinNavHost.kt는 단순히 화면 전환과 경로 연결을 담당하는 역할을 넘어, 앱 전체의 UI 구조물인 Scaffold와 차단 오버레이 책임까지 함께 가지게 되었습니다. 최근 PR #50에서 로그아웃 처리 중 로딩 UI를 MainScaffold 내부로 옮기면서 이 문제가 더 도드라졌습니다.

이 이슈는 padding 값 대입 오류처럼 기계적으로 고칠 수 있는 작은 리뷰 수정이 아니라, FeelinNavHost에 비내비게이션 책임이 계속 누적되고 있는 구조적인 문제를 다룹니다.

현재 문제점

현재 app/src/main/java/com/lyrics/feelin/navigation/FeelinNavHost.kt 안에는 다음 책임들이 함께 모여 있습니다.

• 네비게이션 그래프 정의와 각 화면 Route 연결
• 일부 Route에서 ViewModel 상태를 직접 수집하고 화면 상태로 변환
• 하단 바를 포함한 MainScaffold 구성
• 화면 전체를 덮는 blocking loading overlay 구현
• overlay 활성화 중 system back press 차단
• pointer input 소비를 통한 사용자 상호작용 차단
• 접근성 처리를 위한 semantics 설정

이 상태가 유지되면 navigation 변경과 공통 UI 동작 변경이 같은 파일에서 계속 충돌하고, 이후 다른 화면에서도 전역 overlay나 scaffold 동작이 필요해질 때 FeelinNavHost가 더 커질 가능성이 높습니다.

제안 방향

FeelinNavHost는 가능한 한 destination 연결과 graph 구성에 집중하도록 두고, 공통 UI 책임은 별도 레이어로 분리하는 방향을 제안합니다.

예를 들면 다음과 같은 방향을 검토할 수 있습니다.

• MainScaffold를 별도 composable 파일로 추출
• BlockingLoadingOverlay를 별도 공통 UI 컴포넌트로 분리
• overlay의 back press 차단, pointer input 소비, accessibility semantics를 overlay 컴포넌트 내부에 캡슐화
• Route별 상태 수집과 app-level scaffold 상태 전달 책임을 어디에 둘지 정리

정확한 패키지 위치는 구현 시점에 프로젝트 구조에 맞춰 결정하면 됩니다. 예를 들어 공통 design system component로 둘지, navigation과 presentation 사이의 app scaffold 레이어로 둘지는 별도 검토가 필요합니다.

Acceptance Criteria

• FeelinNavHost.kt에서 MainScaffold 구현 책임이 분리된다.
• blocking loading overlay 구현이 별도 composable로 분리된다.
• overlay의 back press 차단, pointer input 소비, accessibility semantics 처리가 한 곳에 캡슐화된다.
• FeelinNavHost.kt는 navigation graph와 route wiring 중심으로 단순화된다.
• 기존 logout loading overlay 동작과 bottom navigation 표시 동작이 유지된다.
• 리팩토링 후 ./gradlew detekt가 통과한다.