Flutter

구글에서 개발하는 크로스 플랫폼 프레임워크. 한글로는 '플러터'로 주로 쓴다. 안드로이드와 iOS를 지원하며, 2019년 구글 I/O에서는 웹 개발까지 할 수 있는 Flutter Web 프레임워크까지 들고 나왔다. 즉 안드로이드, 아이폰, 웹에서 돌아가는 앱을 하나의 코드로 전부 개발할 수 있다는 이야기다. 물론 정말 이렇게 할 수 있는 범위는 기기 공통으로 제공하는 기능으로 한정하며 특정 OS에서만 지원되는 기능이나 하드웨어를 컨트롤하려면 그에 맞는 네이티브 코드가 필요하다. 이 부분은 안드로이드라면 코틀린, iOS라면 스위프트를 사용해서 붙일 수 있도록 Flutter에서 지원하고 있다. 구글의 차세대 OS로 점쳐지고 있는 Fuchsia도 UI 단에서는 Flutter를 기반으로 할 것으로 보인다. 즉 현재의 행보는 모바일과 데스크톱을 걸친 다양한 환경들을 Fuchsia로 통합하기 위한 포석으로 볼 수 있다.

특징

지금까지 모바일을 겨냥한 크로스 플랫폼 프레임워크는 아파치 코르도바처럼 웹 뷰를 사용하되 여기에 사용되는 자원을 각 기기에 미리 심는 방식, 즉 앱이 로컬 웹 서버로 돌아가도록 해서 웹 앱보다는 빠르고 OS 관계 없이 똑같은 인터페이스를 제공하거나, 리액트 네이티브나 자마린처럼 각 OS의 네이티브 기능을 최대한 활용해서 인터페이스는 조금 차이가 나지만 빠른 속도를 추구하는 방법이 있는데, Flutter는 이들 둘과는 아예 다르다. 각 OS의 네이티브 그래픽 기능을 최대한 활용하되 각 OS의 유저 인터페이스를 무시하고 몽땅 Flutter가 자체 제공한다. 즉, 각 OS는 그림 그릴 캔버스만 제공하고 그 위에 뭘 표현할지는 Flutter가 다 그려버리는 것. 그 때문에 OS에 관계 없이 똑같은 모습의 유저 인터페이스를 제공하며, iOS에서 구글의 머티리얼 디자인을 100% 활용한 앱을 실행시킬 수 있으며 반대로 안드로이드에서 iOS 스타일의 쿠퍼티노 디자인 앱을 사용할 수도 있다. Flutter는 두 가지 디자인을 기본 제공한다. 네이티브 UI를 활용하는 것에 비해서 속도 면에서 불리하지 않은가 싶을 수 있는데 테스트 결과를 보면 상당히 준수하게 나온다. 렌더링 엔진이 무척 좋은 듯. 사실 모바일 게임들은 상당수가 자체 인터페이스를 사용한다. 다만 Flutter 웹은 HTML와 CSS를 사용한다. 이쪽은 이 두 가지로 어지간히 다 할 수 있기도 하고 웹 표준을 무시하면 매장당하므로.

핫 리로드(Hot Reload) 기능을 제공하여 코드가 변경된 부분이 바로바로 디버그 모드의 앱에 반영되는 것도 특징이다. 네이티브도 코드가 변경되었을 때 전체 컴파일 및 패키징 없이도 변경 내용을 반영하는 기능이 있지만 Flutter의 핫 리로드는 이보다 훨씬 빠르고 간편하다. 애초에 Flutter 설계 때부터 이 기능을 염두에 두었다고 한다.

Flutter에서는 모든 요소가 위젯(Widget)이다. 페이지조차도 위젯이다. 따라서 Flutter의 UI는 위젯의 트리 구조다. 위젯은 상태 변화가 없는 Stateless Widget과 상태 변화를 감지하는 StatefulWidget 두 가지로 나뉘는데, 특이한 것은 위젯 자체는 불변(immutable)이다. 따라서 위젯을 업데이트할 수 없다. 변할 경우에는 어떻게 하냐고? 새로운 위젯으로 대체한다. 예를 들어 어떤 위젯의 색깔을 바꾸고 싶을 때에는 기존 위젯에 setColor() 같은 메소드를 불러서 업데이트하는 게 아니라 아예 새로운 스타일을 가진 위젯으로 바꾸는 것이다. 업데이트(update)하지 않고 대체(replace)하는 것이 Flutter 방식이다. 이런 방식을 선언식 UI(declarative UI)라고 부른다. 기존 방식은 명령식 UI(Imperative UI)라고 부른다. 따라서 구조 자체는 상당히 단순한 편이다.

또한 UI를 구성하는 방식이 XML과 같은 외부 파일이 아니라 코드 자체 안에서 구현하는 방식이다. 페이지 자체도 위젯이기 때문에 위젯을 구성하는 build() 메소드 안에서 자식 위젯을 정의하고, 자식 위젯 안에서 자식 위젯을 정의하고... 이런 방식이다. 배치 방법, 마진이나 패딩 같은 것들도 모두 코드로 구현한다. 따라서 위젯의 구성이나 모양을 바꿀 때마다 코드를 다시 컴파일해야 하지만 위에서 이야기한 핫 리로드 때문에 별 불편하지는 않긴 하다.

단점

문제점이라면 Flutter의 개발 언어인 Dart가 별 인기가 없다는 것... 원래는 자바스크립트를 대체할 언어로 들고 나왔지만 시장에서 완전히 파묻혔으며, 자바스크립트의 대안은 MS가 들고 나온 타입스크립트가 잡고 있는 실정이다. Dart나 타입스크립트나 간단한 컴파일을 통해 자바스크립트로 번역되기 때문에 이미 상당히 성숙해 있으며 개발자 저변도 넓은 자바스크립트를 대체한다기보다는 보완하는 역할 정도인데, 여기서도 타입스크립트한테 완전히 밀려서 쓰레기 취급 받던 언어다. 기능 확장을 위한 패키지들도 파이썬이나 자바스크립트에 비하면 형편없이 부족하다. 아무튼 구글에서 그냥 파묻기에는 아까웠던 건지 Flutter를 통해 Dart를 부활시킨 셈인데, Dart의 문법이 간단한 편이며 진입장벽이 낮기 때문에 자바스크립트나 자바 같은 언어들을 잘 알고 있다면 Flutter를 쓰기 위해서 Dart를 배우는 게 큰 시간 낭비는 아니긴 하다. 그리고 Dart 자체도 기능이 형편 없거나 배우기가 지랄맞거나 한 언어는 아니며 단지 자바스크립트를 대체하겠다는 욕심이 너무 큰 나머지 외면 받은 탓이 크다. 자세한 내용은 Dart 항목 참조. 아무튼 Flutter 덕분에 Dart의 사용층이 넓어지고 있는 추세다.

용량도 아직은 문제인데, 네이티브 <<< 자마린 < Flutter로 나타난다. 자마린도 .NET 프레임워크를 비롯한 덩치 큰 라이브러리를 품고 들어가기 때문에 달랑 Hello world 하나 보여주는 웹이 수십 메가에 이른다고 불만이 많은데, Flutter는 이보다 조금 더 크다.

개발 환경

안드로이드 스튜디오, IntelliJ IDEA, 비주얼 스튜디오 코드에서 사용할 수 있다. 이들 모두는 기본 제공 기능이 아니며 플러그인을 설치하면 쓸 수 있다. 모두 크로스 플랫폼 개발 환경이므로 윈도우, 맥, 리눅스에서 개발할 수 있다. 실행은 안드로이드라면 실제 기계가 없어도 안드로이드 SDK에서 제공하는 에뮬레이터를 사용하면 되지만 iOS는 실제 기기를 사용할 수 없다면 맥과 Xcode가 필요하다.