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를 사용한다. 이쪽은 이 두 가지만 가지고도 어지간히 다 할 수 있기도 하고 웹 표준을 무시하면 매장당하는 문제도 있다. Flutter를 웹 개발에 쓰면 사실상 HTML나 CSS 코딩 없이 Dart만으로 다 만들 수 있다.

핫 리로드(Hot Reload) 기능을 제공하여 코드가 변경된 부분이 바로바로 디버그 모드의 앱에 반영되는 것도 특징이다. 네이티브도 코드가 변경되었을 때 전체 컴파일 및 패키징 없이도 변경 내용을 반영하는 기능이 있지만 Flutter의 핫 리로드는 이보다 훨씬 빠르고 간편하다. 애초에 Flutter 설계 때부터 이 기능을 염두에 두었다고 한다. 다만 핫 리로드가 완벽하게 올바른 실행을 보장하지는 않기 때문에 코드가 문제가 없는데도 오류가 나거나 이상하게 동작할 수 있다. 핫 리로드를 했을 때 오류가 나거나 코드는 바꿨는데 외관이나 동작이 달라지지 않았다면 핫 리로드가 아닌 핫 리스타트로 재실행을 시켜보는 게 좋다.

Flutter에서는 모든 요소가 위젯(Widget)이다. 페이지조차도 위젯이다. 심지어는 아예 앱 자체도 위젯이다! 따라서 Flutter의 UI는 위젯의 트리 구조다. 위젯은 상태 변화가 없는 Stateless Widget과 상태 변화를 감지하는 StatefulWidget 두 가지로 나뉜다. 여기서 위젯 자체는 불변(immutable)이다. 따라서 위젯 자체는 업데이트할 수 없다. 그렇다면 StatefulWidget은 상태 변화에 어떻게 대응하나? Flutter가 채용하는 방식은 위젯과 상태를 다른 클래스로 분리한다. 즉 위젯을 그리는 build() 메소드를 위젯이 아닌 상태 클래스가 가지고 있고, 이 상태 클래스를 immutable인 위젯에서 createState() 메소드에서 만들어 가지고 있는 방식으로 문제를 해결한다. 위젯의 상태가 변하면, 즉 위젯의 모양에 영향을 미치는 데이터에 변화가 생기면 상태 클래스에 있는 build()가 위젯을 다시 그린다.

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

각 OS의 네이티브에 붙어 있는 기능을 써야 할 때에는 그 부분만 네이티브로 개발해서 Flutter에 붙일 수도 있다. Flutter는 이를 위한 인터페이스를 제공한다. 단, 네이티브 부분은 안드로이드라면 자바나 코틀린, iOS라면 오브젝티브C나 스위프트와 같이 각자의 네이티브 개발 언어를 써야 한다. 카메라나 GPS처럼 공통으로 제공하는 하드웨어는 Flutter 제공 패키지로도 웬만큼은 다룰 수 있다.

단점

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

또한 각각의 운영체제 및 하드웨어 쪽으로 특화된 기능을 활용하는 데에는 한계가 있다. 이건 Flutter만이 아닌 모든 크로스플랫폼의 한계라고 봐야 할 문제. 이런 부분은 네이티브 코드를 붙일 수 있다.

용량도 아직은 문제인데, 자체적으로 사용자 인터페이스를 렌더링하는 엔진이 들어가므로 네이티브보다는 클 수밖에 없다.

개발 환경

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