Flutter에서 네이티브를 만질 때: MethodChannel과 생명주기

Flutter로 앱을 만들다 보면 생각보다 빨리 네이티브 기능과 마주치게 된다. 명작방송 앱 작업에서도 화면 구성 자체는 Flutter로 충분했지만, 플랫폼 기능과 연결되는 순간부터는 다른 종류의 주의가 필요했다. 특히 MethodChannel은 연결 자체는 간단해 보여도, 화면이 사라지거나 다시 그려질 때 누가 응답을 받고 누가 정리하는지 흐트러지기 쉽다. 나는 이 지점에서 화면 구조보다 생명주기를 먼저 이해해야 한다는 교훈을 크게 얻었다.

처음에는 채널 호출만 성공하면 된다고 생각하기 쉽지만, 실무에서는 호출 이후가 더 중요하다. 응답이 늦게 돌아왔을 때 이미 화면이 닫혀 있다면 어떻게 할지, 같은 화면이 여러 번 진입되면 리스너가 중복되지 않는지, 예외가 났을 때 사용자 경험을 어떻게 유지할지를 같이 봐야 한다. Flutter 쪽 상태 객체와 Android, iOS 쪽 연결 지점이 느슨하게 맞물려 있으면 작은 누수도 나중에 큰 피로로 돌아온다. 그래서 나는 채널 자체를 화면 코드에 깊게 묻지 않고, 중간 계층에서 생명주기와 예외 흐름을 함께 관리하는 쪽이 더 안전하다고 느꼈다.

메모리 관리도 비슷했다. 짧게 테스트할 때는 문제가 없어 보여도, 실제 사용에서는 화면 전환과 백그라운드 복귀가 반복된다. 이때 정리되지 않은 참조나 중복 등록이 쌓이면 원인 찾기가 매우 어려워진다. 결국 중요한 것은 특정 플랫폼 코드를 얼마나 많이 썼느냐보다, 언제 만들고 언제 해제하는지를 팀이 함께 이해할 수 있느냐였다. 그 기준이 서고 나니 네이티브 연동 자체에 대한 부담도 훨씬 줄었다.

기존에는 Flutter와 네이티브 연결을 별도 기술 영역처럼 느꼈지만, 지금은 상태 관리의 연장선으로 보는 편이 맞다고 생각한다. MethodChannel은 다리 역할을 할 뿐이고, 다리를 건너는 흐름을 정리하는 일이 진짜 설계다. 다음에 비슷한 앱을 만든다면 기능 추가 전에 화면 진입과 종료, 응답 지연, 재진입 케이스를 먼저 표로 정리하고 시작할 것이다.