요즘 개발 커뮤니티들을 보고 있으면, Flutter 전환 후기 글들이 많이 올라오는 것 같습니다.
제가 다니는 회사에서 5.0 서비스로 메이저 버전업을 하면서 디자인과 Flutter 도입을 진행했엇습니다.
이제 서비스가 릴리즈가 되었기에 안드로이드 개발자의 관점에서 인터넷에 많은 Flutter 전환 후기처럼 한번 블로깅 해봅니다.
전환도입의 이유
인력자원의 부족
원래 안드로이드 개발자와 iOS 개발자가 함께 있었는데 잦은 퇴사로 인한 인력구성이 변경되는 일이 잦다보니 우리가 계획했던 릴리즈들을 인력이 없어서 못하는 경우가 자주 발생했습니다.
그러면서 자연스럽게 이 공백을 채우기 위한 솔루션을 찾다보니 Cross Platform 언어를 검토하게 되었습니다.
왜 Flutter 인가?
Cross Compile 도입을 검토하던 시기가 21년 2월말 ~ 3월 초였는데 일단 알려진 크로스 플랫폼 위주로 검토를 하였습니다.
1. 주 구성원이 Java, Kotlin, Swift 등과 같은 강타입의 객체지향 패러다임에 익숙함
일단, Flutter, ReactNative, Cordova 정도 검토를 했는데, 안드로이드, iOS 인력이 모바일 개발의 주 구성원이다보니 Non Type 언어이며 프로토타입 기반의 JavaScript 에 런닝커브가 더 큰 경향이 있어서 Dart 를 사용하는 Flutter 에 점수를 더 주었습니다.
2. 성능 자체에 이슈가 없다고 판단
화면 렌더링 시 60fps의 성능이 나올 수 있다면 앱의 동작이 충분히 부드럽게 느낀다고 합니다.
플러터는 이 조건에 부합하기 때문인지 실제 서버 응답을 받아 간단한 리스트 뷰로 출력하는 프로토타입 프로그램을 만들어 봤을 때, 성능이 저하된다는 느낌은 없었습니다. 그리고, React Native 와 달리 브릿지가 없어서 더 빠른 속도를 보여준다 라는 이야기도 있었습니다.
3. 구글의 지원 과 third-party 플러그인 활용해 Native 개발 리소스 절약 가능하다고 판단
맵뷰, GPS, Alarm, Notification, deeplink 등 Native 기능을 사용해야하는 부분들은 플러그인을 통해 지원 받아 개발 리소스를 아낄 수 있다고 판단했습니다. 그리고, 무엇보다 3월초에 Flutter 2.0 이 발표되면서 구글이 지원이 계속 이어지겠구나 생각이 들면서 장기적으로 계속 발전할 수 있겠다라는 판단하에 선택을 했습니다.
4. 공식문서가 잘 되어 있었음
도입중에 느낀 장/단점
장점
선언적 UI의 편리함
안드로이드는 XML layout 을 가지고 inflate 한 후 setText, set~~ 이라는 메소드들로 set 을 하는 것이 View 의 내용을 변경합니다. 이것은 명령형 UI의 기본 동작입니다. 즉, 데이터 변화에 따른 View 변경 로직을 프로그램해줘야 합니다.
이렇게 되면 프로젝트가 커져 로직, View 가 많아지면 VIew 와 Data 간의 이어주는 로직들이 복잡해지게 되고 오류로 쉽게 이어지게 됩니다. 그래서, 이러한 View 변경로직을 줄이고자 데이터 바인딩과 같은 기술들이 대체안으로 나오고 한거죠
하지만, Flutter 는 Swift UI, React, Android 의 Compose 와 같이 선언적 UI 를 지원합니다.
Flutter 의 선언적 UI 는 쉽게 이야기 하면 데이터가 변해서 이전 View 의 인스턴스를 수정하는 것이 아니라 기존 View 인스터스를 파괴하고 새롭게 생성해서 VIew 를 그린다고 이야기할 수 있습니다. 이렇게 되면 상태가 변하면 자동으로 View 가 변경되니 View 변경을 위한 로직이 없어지게 됩니다.
상세한 내용은 아래 링크들을 보시면 잘 나와 있습니다.
- 위젯 소개 : https://docs.flutter.dev/development/ui/widgets-intro
- 선언적 UI 소개: https://docs.flutter.dev/get-started/flutter-for/declarative
처음에는 선언적 UI 에서 화면을 갱신하는 것이 어색했는데, 조금만 해보니 익숙해지더라구요.
확실히 UI 를 구성하는데 쉽고 직관적입니다. 특히, listView 와 애니메이션을 한번 구성해보시면 바로 느끼실 껍니다. 아니 꼭 Flutter 가 아니더라도 Compose 로 listView와 애니메이션을 구성해보시면 바로 선언적 UI 의 힘을 느낄 수 있습니다.
Hot reload
Hot reload는 업데이트된 소스 코드 파일을 실행 중인 Dart 가상 머신(VM) 에 주입하여 작동합니다.
VM이 새로운 버전의 필드 및 함수로 클래스를 업데이트한 후 Flutter 프레임워크는 위젯 트리를 자동으로 다시 빌드하여, UI 를 수정하자 마자 바로 결과물을 볼 수 있습니다. 최근, 안드로이드 Compose 코드랩을 진행하고 있는데 Compose 의 Preview 기능과 비교해보면 Flutter 의 Hot reload 가 훨씬 빠르고 성능이 더 좋습니다. 이렇게 빠르게 UI 수정 사항을 볼 수 있기 때문에 UI 생산성이 높습니다.
참고로 Hot reload 에 대한 상세한 사항은 아래 글을 참조해주세요.
- 플러터의 Hot reload란 : https://yojkim.medium.com/flutter에서의-hot-reload란-8fb2ecdc757f
- 플러터 공식문서의 Hot reload: https://docs.flutter.dev/development/tools/hot-reload
쉬운 비동기 구현
플러터는 Future 나 isolate 라는 것으로 비동기 구현을 합니다.
기본적으로 http 통신 과 같이 단순히 대기가 필요한 것은 future 를 이용하고, 연산이 많이 걸리는 것은 isolate 를 이용합니다.
이 두 방법 다 안드로이드 의 비동기 방법인 코루틴, 스레드 생성 처리 보다 쉬웠습니다.
상세한 것은 아래 자료를 참조하시면 되고, 추후에 한번 Future 와 isolate 에 대해서 공부했던 내용을 정리해서 블로그에 소개해볼까 합니다.
- https://dart.dev/codelabs/async-await
- https://medium.com/dartlang/dart-asynchronous-programming-isolates-and-event-loops-bffc3e296a6a
- https://dart.dev/guides/language/language-tour#isolates
- https://docs.flutter.dev/cookbook/networking/background-parsing
안드로이드와 유사한 디자인 패턴들
주로 Flutter 는 BLoc 패턴을 사용합니다.
플러터에서 유명한 플러터 인액션 이라는 책에서도 BLoc 패턴를 주로 자세히 소개하고, 예전 버전의 Flutter 샘플을 보면 많이 사용되는 걸 볼 수 있었습니다.
사실, 요즘에는 안드로이드나 iOS 개발자들이 많이 넘어와서 그런지 MVVM, MVP, MVI, CleanArchitecture 등 다양한 아키텍처 패턴을 적용한 샘플 앱들을 볼 수 있어 친숙했습니다. 그리고, 안드로이드의 LiveData, flow, rx 와 같은 유사 개념을 가진 객체들이 제공되어 이를 가지고 안드로이드와 같이 상태관리 및 리엑트 프로그래밍까지 구현할 수 있습니다.
단점
양날의 검 플러그인
디지털페이지 의 경우 Naitive 의 기능을 많이 사용해야합니다.
이를 테면 연락처에 접근해서 연락처를 가져온다던지, Native 의 캘린더 일정들을 가지고 와야되며, 포그라운드 서비스로 위치를 추적하기도 하고, 홈위젯도 개발해야 하는 등 Native 고유의 기능들을 사용해야할 일이 많습니다. 또한, 카카오, 네이버, 애플, 페이스북 로그인을 지원합니다.
그렇다 보니 개발 리소스를 줄이기 위해 third-party 플러그인을 많이 사용하게 되고 의존성이 높아집니다.
그러다보니 기능 구현은 급한데 플러그인 업데이트가 늦어지면 직접 플러그인 소스를 받아 수정하는 일이 생깁니다.
디지털페이지는 3월초에 프로젝트에 null safety 를 적용했는데, 빠르게 업데이트가 안되는 플러그인이 많아 직접 받아서 null safety 를 적용하기도 했습니다.
그리고, 사용하는 플러그인에 원하는 기능이 부족해서 튜닝하는 일도 잦았습니다.
그러다보니, 안드로이드 개발자, iOS 개발자 결국 Native 를 다 알아야 하고 Native 코드가 많아지니 생산성이 정말 높은 것이 맞나라는 생각이 들었습니다. Nativie 기능을 많이 사용해야한다면 그리고, Native 쪽에 코드가 잦은 변경이 예상된다면 Flutter 전환을 하는 것이 맞나 라는 생각을 다시 해보시길 바랍니다.
Keyboard 수동 컨트롤이 어려움
일반적으로 Flutter 에서 키보드 컨트롤은 Focus 로 하게 됩니다.
focus 를 clean 하면 키보드가 hide 되고, Focus 가 TextFiled 에 커서가 가면 자동으로 노출되게 됩니다.
키보드를 수동으로 제어 해야 한다면 Focus 관리가 살짝 복잡하게 되게 됩니다. 그래도, Flutter 위젯에서의 제어는 할 만합니다.
만약, 웹뷰의 TextFiled 같은 곳에서 수동으로 키보드를 컨트롤을 많이 해야한다면 Flutter 로 해당 화면 전환을 다시 한번 고려해보는 것이 좋습니다.
이건 제가 개발한 메모앱의 UI 특수성일 수도 있습니다만,
웹뷰에서 에디터에 글자를 입력하다가 객체를 입력하기 위해 메뉴의 아이템을 선택하면 Flutter 의 BottomSheet 나 Dialog 가 나오게 됩니다. 메모 앱이기 때문에 이 BottomSheet 와 Dialog 에서 동작을 마친 뒤 복귀를 하면 연속적인 입력 경험을 위해서 키보드를 보이는 상태로 만들어야 합니다.
이 때 웹뷰안의 페이지라는 특성 때문에 자바스크립트 통신으로 웹 element 에 focus 를 강제로 주고 키보드를 강제로 보이도록 Native 작업을 해줘야 합니다. 이러한 작업이 많을 경우 선언적 UI 의 장점을 반감 시키는 것 같기도 하고, 번거롭기 때문에 Flutter 로 해당 화면 전환을 다시 한번 고려해보는 것이 좋습니다
안드로이드 웹뷰 키보드 이슈
안드로이드 웹뷰안에서 키보드를 사용할 때 이슈가 있습니다.
제가 알기로는 현재 유명한 웹뷰 플러그인들은 기본적으로 Native 뷰를 플러터에 삽입하는 것으로 구현이 되어 있습니다.
이렇게 Nativie View 를 플러터에 삽입하는 방법에는 두가지 가 있는데 DisplayMode 와 HybridComposition 입니다.
애석하게도 DisplayMode 로 웹뷰를 사용할 경우 키보드 자체가 나오지 않는 현상과 영문 이외 키보드가 사용이 안되는 현상이 있는 것으로 알고 있습니다. 이러한 이슈는 HybridComposition 모드를 사용하면 해결 할 수 있습니다.
그런데, 이 모드를 사용하면 안드로이드 10 이전에서 UI 의 FPS 가 감소 될 수 있는 단점이 있습니다.
또한 HybridComposition 을 사용하는 두 뷰가 dim background가 적용된 채로 겹쳐지면 안드로이드 앱의 UI의 FPS 가 급격하게 떨어지니 참고하길 바랍니다. (예, HybridComposition 사용하고 있는 웹뷰위에 Flutter 의 BottomSheet 나 Dialog 로 또 다른 HybridComposition 를 사용하는 웹뷰를 띄우거나 맵뷰를 띄우는 등의 행위)
이 문제를 해결하는 데 많은 시간을 소요했습니다. 어떻게 해결했는지 알고 싶으신 분은 아래 글을 참고하시면 될 것 같아요.
https://developside.tistory.com/107
[Flutter] 웹뷰 하이브리드 모드 관련 이슈 해결
서문 이제 네이티브 앱을 플러터로 변경하고, 앱의 디자인 까지 변경한 디지털페이지 5.0 프로젝트가 막바지로 접어들었습니다. 11월 중에는 끝이 날 것 같은데, 끝이 나면 이 프로젝트에 대해 회
developside.tistory.com
Nativie 의 View 를 Flutter 에서 사용하게 하는 방법이나 HybridComposition 에 대해 자세히 알고 싶으면 아래 링크를 참조하시면 됩니다.
커리어에 대한 걱정
저는 사실 지방에 있을 때는 안드로이드를 주 개발업무가 아니었기 때문에 실제 안드로이드 Native 총 경력은 3~4년 정도 밖에 되지 않습니다. 깊이감이 깊어 지려 할 때 Flutter 로 전환한거라 아쉬움이 많습니다.
스스로 기술적으로 깊어졌다라는 생각이 들지 않으니 불안감이 생기더군요.
그래도, 최근에는 네이버 지식인 앱과 같은 큰 규모의 서비스들도 플러터 전환하고 후기들이 올라오고 있는 것으로 봐서는 상승세는 분명한 것 같습니다.
그래서, 저는 업무 외 꾸준히 안드로이드에 대한 공부를 지속해 깊이 있게 학습하고, 추후에는 더 나아가 iOS, Web 까지 해보려고 합니다. 요즘 모바일은 웹뷰를 통해 웹과 연동되지 않는 부분이 없고, Flutter 를 하려면 iOS를 알아야 하기 때문입니다.
아, 그리고 꼭 flutter 를 해서 불안함만 있었던 것은 아닙니다.
최근 안드로이드의 중심 키워드는 Compose 일 것 같은데요. Compose 를 이해하는데 많은 도움이 되었습니다. 선언적 UI 의 개념이나 상태관리, 아키텍처, 기본 CS 요구 지식 등은 비슷하기 때문입니다.
결론을 말씀드리면 걱정이 안되는 것은 아니다. 그런데 Flutter 를 해보면 안드로이드, iOS 다 알아야 하는 상황이 온다.
그래서, Flutter, 안드로이드, iOS 공부의 필요성을 느끼게 되고 전문가 수준의 언어로 자신의 메인 플랫폼으로 깊이감을 더하고 나머지 모두 익히면 된다. 로 결론 지을 수 있을 것 같아요.
이 정도로 하면 도움이되는 플러터 전환 후기가 되려나요?
지금 전환 도입을 추진하시는 분이나 플러터를 공부하고자 하시는 분에게 조금이나마 도움이 되었으면 좋겠습니다.
그리고, 디지털페이지처럼 전면 도입이 아니더라도 부분 도입도 가능하니 플러터 도입에 대해서 관심이 있으신 분은 한번 찾아보셔도 괜찮을 것 같습니다.
참고로, 아래는 최근 네이버 지식인, 그리고 gs리테일 도입후기 인데요.
제 글과 함께 보시면 많은 도움이 될 것 같아 함께 공유합니다.
'Tech & Programming > 모바일(Android, Flutter)' 카테고리의 다른 글
| [안드로이드]Room 의 기본 (0) | 2022.03.02 |
|---|---|
| [Flutter] 웹뷰 하이브리드 모드 관련 이슈 해결 (0) | 2021.11.02 |
| 플러터 StatelessWidget? StatefulWdiget? (0) | 2021.08.21 |
| Google I/O 2021 Keynote 키워드 요약 (0) | 2021.05.27 |
| Android Context (0) | 2020.11.13 |