Flutter MVVM 클린 패턴 적용기 — GetX와 Provider 사이

Flutter 프로젝트를 리뉴얼할 때 가장 먼저 부딪힌 문제는 화면이 늘어날수록 상태가 어디서 만들어지고 어디서 사라지는지 팀 전체가 빠르게 파악하기 어려워진다는 점이었다. 처음에는 속도를 위해 한 방식으로 밀어붙이고 싶었지만, 실제 운영을 생각하면 화면 생명주기와 의존성 방향이 더 중요했다. 특히 태블릿 대응, 네이티브 연동, 로그인 이후 복잡한 이동 흐름이 섞이기 시작하면 단순히 "코드가 돌아간다" 수준으로는 오래 버티기 어렵다.

내가 정리한 기준은 세 가지였다. 첫째, 화면이 다시 그려질 때 어떤 상태가 유지되어야 하는지 분명해야 한다. 둘째, 네트워크 호출과 화면 표현을 한 파일 안에서 섞지 않는다. 셋째, 팀원이 기능을 추가할 때 진입 경로를 쉽게 찾을 수 있어야 한다. 이 기준으로 보면 GetX는 빠른 개발과 화면 전환에서 장점이 있었고, Provider는 의존성 흐름을 더 명시적으로 드러내는 데 유리했다. 그래서 둘 중 하나를 맹목적으로 고르기보다, 화면 구조는 MVVM으로 고정하고 상태 주입과 갱신 방식에서 각 도구의 장점을 취하는 식으로 정리했다.

실무에서 특히 도움 된 것은 ViewModel의 책임을 줄인 일이었다. 모든 이벤트를 한 클래스가 다 받게 두면 금방 비대해진다. 대신 화면 최초 진입, 사용자 액션, 네이티브 브리지 응답 같은 흐름을 나눠 메서드 이름부터 의도를 드러내도록 바꿨다. MethodChannel 연동도 화면에서 직접 처리하지 않고 중간 계층을 둬서 테스트와 교체가 쉬워졌다. 덕분에 버그가 생겼을 때도 문제를 화면, 상태, 연동 계층 중 어디서 찾아야 할지 빨리 좁힐 수 있었다.

돌아보면 아키텍처의 목적은 멋진 다이어그램이 아니라 유지보수 비용을 낮추는 데 있었다. Flutter에서 MVVM을 적용할 때 중요한 것은 특정 라이브러리를 신봉하는 태도보다, 팀이 계속 읽고 고칠 수 있는 구조를 만드는 일이라고 생각한다. 다음에도 비슷한 프로젝트를 맡는다면 상태 관리 도구를 먼저 고르기보다, 화면 생명주기와 데이터 흐름 표를 먼저 그리고 시작할 것이다.