Flutter

구글에서 개발하는 크로스 플랫폼 프레임워크. 한글로는 '플러터'로 주로 쓴다. 프로그래밍 언어로는 구글에서 개발한 Dart를 사용한다. 안드로이드와 iOS를 지원하며, 2019년 구글 I/O에서는 웹 개발까지 할 수 있는 Flutter Web 프레임워크까지 들고 나왔다. 즉 안드로이드, iOS, 웹에서 돌아가는 앱을 하나의 코드로 전부 개발할 수 있다는 이야기다. 2020년 들어서는 윈도우와 맥OS, 리눅스까지도 지원해서 데스크톱 프로그램까지도 Flutter로 만들 수 있다. 2021년 3월부터 웹과 데스크톱 지원이 베타에서 공식 버전으로 올라왔다.

물론 정말 이렇게 할 수 있는 범위는 기기 공통으로 제공하는 기능으로 한정하며 특정 OS에서만 지원되는 기능이나 하드웨어를 컨트롤하려면 그에 맞는 네이티브 코드가 필요하다. 이 부분은 안드로이드라면 코틀린, iOS라면 Swift를 사용해서 붙일 수 있도록 Flutter에서 지원하고 있다. 구글의 차세대 OS로 점쳐지고 있는 퓨시아(Fuchsia)도 UI 단에서는 Flutter를 기반으로 할 것으로 보인다. 즉 현재의 행보는 모바일과 데스크톱을 걸친 다양한 환경들을 퓨시아(Fuchsia)로 쉽게 옮겨가는 징검다리로 볼 수 있다.

2021년 3월 3일에 열린 Flutter Engaged 행사에서는 Flutter 2를 발표했다. 베타 상태였던 웹과 데스크톱 환경 개발을 정식으로 지원하는 것이 주요한 변화다. 데스크톱과 웹, 모바일을 연계해서 각각의 환경에 최적화된 기능을 제공하는 앱을 만들 수 있을 것으로 기대하고 있다. 특히 우분투 리눅스 개발사인 캐노니컬이 그동안 Flutter를 우분투에 포팅하기 위해서 공동 개발을 진행해 왔는데, 앞으로 우분투용 앱 개발을 위한 기본 도구로 Flutter를 쓸 것이라고 발표했다. 또한 Dart 언어 차원의 널 안전성 지원도 공식화했다. 다만 이 때문에 널 안전성에 대비하지 않은 코드와 패키지들이 문제를 일으킬 수 있으므로 서둘러 기존 프로젝트를 Flutter 2로 이식하려고 하지 말고 Dart의 널 안전성 지원을 충분히 이해하고 패키지들이 안정화될 때까지 기다릴 필요가 있다.

2022년 5월 11일에는 Flutter 3을 발표했다. macOS와 리눅스를 안정 버전으로 지원하며 특히 macOS는 인텔 CPU와 애플 실리콘 양쪽 모두를 네이티브로 지원할 수 있게 되었다. 또한 캐주얼 게임을 지원함으로써 모바일, 데스크톱, 웹에 이르는 플랫폼의 캐주얼 게임을 단일 소스코드로 만들 수 있다. 구글은 핀볼을 비롯한 몇 가지 샘플 게임을 직접 해볼 수 있도록 제공하고 있다.

Flutter 2부터는 Dart의 널 안전성을 지원하며, Flutter 2.2부터는 새로운 프로젝트를 만들면 널 안전성을 적용한 코드가 만들어진다.

특징

기기에 독립된 사용자 인터페이스

지금까지 모바일을 겨냥한 크로스 플랫폼 프레임워크는 아파치 코르도바처럼 웹 뷰를 사용하되 여기에 사용되는 자원을 각 기기에 미리 심는 방식, 즉 앱이 로컬 웹 서버로 돌아가도록 해서 웹 앱보다는 빠르고 OS 관계 없이 똑같은 인터페이스를 제공하거나, 리액트 네이티브나 자마린처럼 각 OS의 네이티브 기능을 최대한 활용해서 인터페이스는 조금 차이가 나지만 빠른 속도를 추구하는 방법이 있는데, Flutter는 이들 둘과는 아예 다르다. 각 OS의 네이티브 그래픽 기능을 최대한 활용하되 각 OS의 유저 인터페이스를 무시하고 몽땅 Flutter가 자체 제공한다. 즉, 각 OS는 그림 그릴 캔버스만 제공하고 그 위에 뭘 표현할지는 Flutter의 렌더링 엔진인 Skia가 다 그려버리는 것. 그 때문에 OS에 관계 없이 똑같은 모습의 유저 인터페이스를 제공한다. Flutter는 두 가지 인터페이스 디자인을 기본 제공한다. OS에 따라 디자인을 달리 하는 것도 가능해서 안드로이드에서는 머티리얼, iOS에서는 쿠퍼티노 인터페이스 를 사용하는 식으로 할 수도 있고 그 반대로도 할 수 있다! 같은 앱에서 입맛에 맞게 어떤 부분은 머티리얼, 어떤 부분은 쿠퍼티노 디자인을 적용할 수도 있다. 다만, 똑같은 기능을 하는 인터페이스라고 해도 모양이나 크기가 다를 수 있으므로 이를 감안해야 한다. 네이티브 UI를 활용하는 것에 비해서 속도 면에서 불리하지 않은가 싶을 수 있는데 테스트 결과를 보면 상당히 준수하게 나온다. 렌더링 엔진인 Skia는 C++로 구현했는데 최적화를 무척 잘 했는지 성능이 아주 좋다. 그리고 지금도 계속 최적화를 하고 있어서 업데이트 될 때마다 어느 정도나 성능을 향상시켰는지 공지한다.

그런데 Skia는 iOS에서 초기 로딩 지연 문제가 있었는데, 이를 해결하기 위해서는 렌더링 엔진을 처음부터 다시 설계해야 했다. 구글은 새로운 엔진인 Impeller를 구현했고, 3.7부터 프리뷰로 발표한 다음 3.10부터 iOS에는 기본 렌더링 엔진으로 정식 적용했다. 안드로이드는 여전히 Skia를 기본으로 쓰고 있지만 3.10을 발표하면서 프리뷰로 적용할 수 있도록 발표했다. 차후에 안드로이드도 Impeller로 이사갈 가능성이 높다. Skia를 Impeller로 바꾸어도 기존 코드를 건드릴 필요가 전혀 없다.

다만 Flutter 웹은 HTML와 CSS, 자바스크립트를 사용한다. 이쪽은 이 두 가지만 가지고도 어지간히 다 할 수 있기도 하고 웹 표준을 무시하면 매장당하는 문제도 있다. Flutter를 웹 개발에 쓰면 사실상 HTML나 CSS 코딩 없이 Dart만으로 다 만들 수 있다.

핫 리로드

핫 리로드(Hot Reload) 기능을 제공하여 코드가 변경된 부분이 바로바로 디버그 모드의 앱에 반영되는 것도 특징이다. 네이티브도 코드가 변경되었을 때 전체 컴파일 및 패키징 없이도 변경 내용을 반영하는 기능이 있지만 Flutter의 핫 리로드는 이보다 훨씬 빠르고 간편하다. 위젯의 속성을 바꾸고 나서 그게 어떤 모양으로 보이는지 아주 간단하하게 확인해 볼 수 있기 때문이다. 뭐 하나 바꿀 때마다 다시 컴파일하고 실행하는 것과는 비교도 안 되게 빠르고 편리하다. 특히 재실행이 아니라, 실행 상태를 유지하면서 코드를 바꾼 내용만 반영해 주기 때문에 위젯의 디버깅에 큰 이점을 가진다. 애초에 Flutter 설계 때부터 이 기능을 염두에 두었다고 한다. 정확하게는 Dart 가상머신이 제공하는 기능이다. 다만 핫 리로드로 바로 변경이 적용되는 부분은 위젯을 그리는 부분, 특히 Widget.build() 메서드 안에 있는 코드이며, 조건에 따라 완벽하게 올바른 실행을 보장하지는 않기 때문에 코드가 문제가 없는데도 오류가 나거나 이상하게 동작할 수 있다.

핫 리스타트도 엄청나게 편리한 기능인데, 1초 정도면 되는 핫 리로드에 비하면 길지만 4~5초 정도면 재실행이 되므로 코드 한 번 고칠 때마다 다시 컴파일해서 실행시키려면 분 단위로 기다려야 했던 앱 개발 환경과 비교해 보면 정말 눈물날 정도로 순식간이다. 핫 리로드는 현재의 데이터가 초기화되지 않는다. 즉 위젯이 가진 속성값을 변경시키고 나서 핫 리로드를 했다면 변경된 값이 그대로 유지된다. 반면 핫 리스타는 모든 값이 초기화된다. 만약 여러 페이지로 된 앱을 첫 페이지에서 다른 페이지로 넘어간 상태에서 핫 리로드를 했다면 넘어간 페이지를 그대로 유지하지만 핫 리스타트는 첫 페이지로 돌아간다. 핫 리로드는 현재의 실행 상태를 유지한 채로 프로그래머가 위젯을 변경한 부분만 업데이트해 주며, 핫 리스타트는 앱을 재실행하는 것으로 볼 수 있다. 핫 리로드를 했을 때 오류가 나거나 코드는 바꿨는데 생각과는 달리 외관이나 동작이 달라지지 않았다면 핫 리로드가 아닌 핫 리스타트로 재실행을 시켜보는 게 좋다. 핫 리로드나 핫 리스타트 둘 다 기존의 재실행 방법에 비해서 눈물날 정도로 빠르기 때문에 앱 개발 기간을 엄청나게 단축시켜 준다. 경우에 따라서는 핫 리스타트를 해도 계속 나는 오류가 있어서 다시 빌드가 필요할 수도 있다. 예를 들어 패키지를 새로 설치했거나 지웠을 때라든가 이미지, 폰트와 같은 자산(asset)을 추가했을 때와 같이 pubspec.yaml 파일을 변경했다면 이를 반영하기 위해서는 다시 빌드해야 한다.

핫 리로드나 핫 리스타트는 기기의 접속을 끊으면 변경된 내용이 반영되지 않으므로 변경된 내용을 기기에 완전히 심기 위해서는 실행을 중단시킨 다음 다시 컴파일해서 실행시키거나 프로파일 모드 또는 릴리즈 모드로 실행시켜야 한다. 참고로 프로파일 모드는 디버깅 정보가 그대로 다 뜨지는 않지만 앱 성능 측정과 로깅 기능은 유지하는 모드로, 릴리즈 모드에 준하는 속도를 내면서도 디버깅에 일부 도움을 받을 수 있다.

웹용 Flutter는 아직 핫 리로드는 지원하고 있지 않으며, 핫 리스타트만 지원한다.

위젯

Flutter에서는 모든 요소가 위젯(Widget)이다. 페이지조차도 위젯이다. 심지어는 아예 가장 기본이 되는 App 클래스 조차도 StatelessWidget 클래스에서 상속 받는다! 대부분의 위젯은 child, 또는 children 속성으로 자식 위젯을 품을 수 있다. 따라서 Flutter의 UI는 위젯의 트리 구조다.

위젯은 상태 변화가 없는 Stateless Widget과 상태 변화를 감지하는 Stateful Widget 두 가지로 나뉜다. 중요한 것은 위젯 자체는 stateless든 stateful이든 불변(immutable)이다. 따라서 위젯 안의 모든 속성은 final이어야 하며, 위젯을 업데이트할 수 있는 메서드 같은 것은 제공하지 않는다. 만약 위젯이 어떤 텍스트를 출력하고 있고, 그 텍스트가 바뀌어야 한다면 안드로이드나 iOS 네이티브로 계산할 때에는 그 위젯의 setText() 메서드를 호출한다든가 해서 매개변수로 새 텍스트를 넘겨주는 식으로 텍스트를 바꿀 것이다. 즉 명령을 통해 인터페이스를 업데이트 한다. Flutter는 이렇게 하지 않는다. 위젯이 표시할 텍스트는 stateless든 stateful이든 위젯이 만들어질 때 생성자의 매개변수로 넘겨야 하고, 이 값을 바꿀 수 있는 메서드는 없다. 위젯의 색깔을 바꾼다든지, 위치를 바꾼다든지 하는 것도 명령으로 업데이트할 수 없다. 위젯은 build() 메서드를 제공하는데, 이 메서드는 위젯이 만들어졌을 때 한 번만 호출된다.

그렇다면 상태의 변화를 감지하는 Stateful Widget은 상태 변화에 어떻게 대응하나? Flutter가 채용하는 방식은 위젯과 상태를 다른 클래스로 분리한다. 즉 위젯을 그리는 build() 메소드를 위젯이 아닌 상태 (state) 클래스가 가지고 있고, 이 상태 클래스를 immutable인 위젯에서 createState() 메소드에서 만들어 가지고 있는 방식으로 문제를 해결한다. State 클래스는 final이 아닌 속성을 둘 수 있다. 위젯의 상태가 변하면, 즉 위젯의 모양에 영향을 미치는 데이터에 변화가 생기면 상태 클래스에 있는 build()가 위젯을 처음부터 다시 그리며 자신이 품고 있는 위젯 트리도 여기서 다시 그린다. 어떤 상태 변화가 있을 때마다 build()를 불러서 전체 위젯을 다시 그린다면 굉장히 효율이 떨어질 것처럼 보이지만 의외로 좋은데, 실제로는 Flutter 엔진이 어떤 부분이 변했는가를 검사한 다음, 영향을 받는 위젯을 'dirty' 상태로 표시하고, 이 위젯들만 다시 그리는 방식으로 효율을 낸다. 만약 stateful한 위젯에서 상태에 변화를 일으키는, 즉. 위젯을 다시 그려야 하는 dirty한 데이터 변경이 있다면 setState() 메서드를 호출해서 그 안에서 데이터를 변경해야 한다.

UI에 영향을 미치는 데이터가 비동기적으로 변한다면 이는 Dart의 Future 또는 Stream 클래스를 이용해서 반영할 수 있다. 이 때에는 위젯의 build() 메서드 안에서 각각 FutureBuilder 또는 StreamBuilder 클래스를 사용해서 처리한다. 특히 구글의 제품인만큼 구글의 NoSQL 동기화 데이터베이스인 Firestore와 궁합이 기가 막히게 좋다. StreamBuilder를 사용하면 데이터베이스가 업데이트 되었을 때 자동으로 동기화가 되고 UI에 반영된다. 쉽게 말해서 UI 단에서는 업데이트에 대비해서 따로 뭘 할 게 없다는 뜻이다. 다만 단점도 있는데, 이들 위젯이 속해 있는 부모 위젯이 다시 그려질 때, 즉 build()가 호출될 때, 이것들도 다시 build()가 호출되므로 Future 혹은 Stream 객체를 다시 만들어서 그리며, 그때문에 데이터가 불필요하게 다시 로딩되거나 깜빡이는 현상이 나타난다.

또한 UI를 구성하는 방식이 XML과 같은 외부 파일이 아니라 코드 자체 안에서 구현하는 방식이다. 페이지 자체도 위젯이기 때문에 위젯을 구성하는 build() 메소드 안에서 자식 위젯을 정의하고, 자식 위젯 안에서 자식 위젯을 정의하고... 이런 방식이다. 배치 방법, 마진이나 패딩 같은 것들도 모두 코드로 구현한다. 따라서 위젯의 구성이나 모양을 바꿀 때마다 코드를 다시 컴파일해야 하지만 위에서 이야기한 핫 리로드 때문에 별 불편하지는 않긴 하다. 가독성 측면에서도 XML이 딱히 낫다고 보기 어렵고 효율성 측면에서도 좋은 소리는 못 듣기 때문에 UI 레이아웃을 코드로 구현하는 부분은 좋은 평가를 받는다. 참고로 설정 파일은 YAML(확장자 .yml) 형식을 사용한다. 프로젝트에 포함시킬 외부 패키지, 글꼴, 그리고 이미지를 비롯한 자산(asset) 파일은 이 안에 포함시켜야 한다.

기존 위젯을 가지고 새로운 위젯을 만들려면 기존 위젯은 상속하지 않는 것이 좋다. 일단 실제로 해 보면 구현이 잘 안 되는 걸 알 수 있다. 대신 StatelessWidget 또는 StatefulWidget 클래스를 상속해서 새 위젯 클래스를 만든 다음 build() 메서드에서 확장하고자 하는 위젯에 내가 구현한 기능을 붙인 위젯 객체를 돌려주는 방식으로 구현해야 한다.

그밖에

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

Flutter의 사용자층이 넓어지면서 Flutter는 물론 Dart의 기능을 확장해 주는 패키지들도 빠른 속도로 늘어나고 있다. 패키지 관리를 위해서 자바스크립트가 npm, 파이썬이 pip을 사용하는 것처럼 Flutter의 프로그래밍 언어인 Dart도 Pub을 제공한다. pub.dev 웹사이트에서 패키지를 검색해 볼 수 있으며 필요한 패키지를 Pub으로 설치 및 관리할 수 있다. 필요한 패키지는 pubspec.yaml 파일에 추가해서 'flutter pub get' 명령으로 받아올 수 있다. 비주얼 스튜디오 코드나 안드로이드 스튜디오는 pubspec.yaml 파일 변경을 감지해서 자동으로 pub get 명령을 실행하거나 명령을 실행할지 물어본다.

성능

일반적으로 크로스 플랫폼으로 개발한 앱은 네이티브와 비교해서는 속도는 느리고, 메모리를 비롯한 자원은 많이 잡아먹는 것으로 알려져 있다. 이는 네이티브 UI를 최대한 활용하는 자마린이나 리액트 네이티브도 피해갈 수 없는 문제다. 그렇다면 Flutter는? 우크라이나에 소재를 둔 인베리타소프트라는 곳에서 크로스 플랫폼인 리액트 네이티브와 플러터, 그리고 네이티브로 iOS는 오브젝티브C와 스위프트, 안드로이드는 자바와 코틀린을 사용해서 성능 실험을 해 보았다. 원문은 여기에서 확인할 수 있다. 메모리 위주 성능 측정을 위해서는 가우스-르장르드 알고리즘(Gauss–Legendre algorithm)을, CPU 위주 성능 측정에는 보웨인 알고리즘(Borwein algorithm)을 사용했다. 결과는?

	iOS		안드로이드
	가우스-르장드르	보웨인	가우스-르장드르	보웨인
리액트 네이티브	2992.0	582.1	3289.3	821.9
Flutter	188.7	179.5	272.5	285.2
스위프트	218.3	35.0	—	—
오브젝티브C	127.5	16.7	—	—
자바	—	—	222.0	143.0
코틀린	—	—	223.0	144.0

수치는 같은 알고리즘으로 만든 앱을 실행시켰을 때의 처리시간을 밀리초 단위로 보여주는 것이므로 숫자가 낮을수록 성능이 좋다.

일단 리액트 네이티브는 Flutter에 비해서 성능이 많이 떨어지는 모습을 보여준다. 메모리 위주의 테스트에서는 10배 이상 차이가 나며, CPU 위주 테스트에서도 3배 이상 느리다. Flutter와 각 OS별 네이티브로 개발한 앱을 비교해 보면 아무래도 네이티브가 좋긴 하지만 그래도 리액트 네이티브에 비하면 Flutter가 훨씬 낫다. 게다가, iOS에서 메모리 위주의 테스트를 했을 때에는 스위프트보다 오히려 빠르다! 스위프트 의문의 1패 부수적으로 iOS 환경에서는 스위프트가 오브젝티브C가 확실히 느린 것으로 나타나는 반면, 안드로이드 환경에서 자바와 코틀린은 별 차이가 없다. 이렇게 본다면 성능 면에서 조금이라도 속도가 빨라야 하는 정도가 아니라면 Flutter가 괜찮은 선택으로 보인다.

단점

문제점이라면 Flutter의 개발 언어인 Dart가 별 인기가 없다는 것... 원래는 자바스크립트를 대체할 언어로 들고 나왔지만 시장에서 완전히 파묻혔으며, 자바스크립트의 대안은 MS가 들고 나온 타입스크립트가 잡고 있는 실정이다. Dart나 타입스크립트나 간단한 컴파일을 통해 자바스크립트로 번역되기 때문에 이미 상당히 성숙해 있으며 개발자 저변도 넓은 자바스크립트를 대체한다기보다는 보완하는 역할 정도인데, 여기서도 타입스크립트한테 완전히 밀려서 쓰레기 취급 받던 언어다. 기능 확장을 위한 패키지들도 파이썬이나 자바스크립트에 비하면 형편없이 부족하다. 아무튼 구글에서 그냥 파묻기에는 아까웠던 건지 Flutter를 통해 Dart를 부활시킨 셈이다. Flutter에 힘입어 Dart도 약진하고 있고, 크로스 플랫폼 언어 시장에서는 리액트 네이티브와 치열한 1위 경쟁을 벌이는 수준까지 올라왔다. 하지만 지금으로서는 Dart는 Flutter 말고는 별로 써먹을 데가 없다.

자바스크립트는 웹 프론트엔드 쪽에서는 말할 것도 없는 필수요소고, Node.js의 성공으로 프론트엔드와 백엔드까지 한 가지 언어로 퉁칠 수 있는, 명실상부한 대세다. 엘렉트론 프레임워크를 쓰면 크로스 플랫폼 데스크톱 애플리케이션까지 만들 수 있고, 이를 활용한 비주얼 스튜디오 코드를 비롯한 훌륭한 작품들이 있다. 그런데 Dart는? 물론 Flutter도 웹과 데스크톱을 지원하기 시작했지만 자바스크립트에 비하면 그 격차는 아득히 멀고, Dart를 자바스크립트로 변환할 수 있지만 그럴 거면 그냥 자바스크립트를 쓰거나, 자바스크립트의 언어 구조가 영 별로라면 타입스크립트라는 훌륭한 대체재도 있다. 현재로서는 Dart의 미래는 오로지 Flutter에 달려 있고, 만에 하나 Flutter가 망하면 Dart는 정말로 쓰레기가 된다. 과연 Dart라는 새로운 언어를 배워가면서까지 Flutter를 꼭 써야 하나? 하는 의구심이 들 수밖에 없다.

Dart의 문법은 자바스크립트와 닮은 구석도 꽤 있고, 진입장벽이 낮기 때문에 자바스크립트나 자바 같은 언어들을 잘 알고 있다면 Flutter를 쓰기 위해서 Dart를 배우기 위해 시간을 많이 들일 필요는 없다. 그리고 Dart 자체도 기능이 형편 없거나 배우기가 지랄맞거나 한 언어는 절대로 아니며 처음에는 쉬워보이지만 쓰면 쓸수록 헷갈리기 쉬운 자바스크립트에 비하면 버그가 적고 깔끔한 코드를 만들 수 있다. 또한 Flutter의 장점으로 손꼽히는 핫 리로드나 핫 리스타트는 그만큼 Dart가 잘 디자인된 언어라는 것을 보여주는 증거이기도 하다. 단지 자바스크립트를 대체하겠다는 욕심이 너무 컸던 것도 있고, 다른 웹 브라우저 입장에서 보면 크롬 웹 브라우저를 가지고 있는 구글에게 좋은 일을 굳이 해줄 이유도 없으니 이들에게 외면 받은 탓이 크다. 자세한 내용은 Dart 항목 참조. Flutter 덕분에 Dart가 재발견되고 사용층도 넓어지고 있는 추세이고 이를 지원하는 개발 도구도 늘어나고 있으며, 여러 가지 기능을 손쉽게 추가시킬 수 있는 패키지도 빠르게 늘고 있기 때문에 Dart 언어 자체도 여러 가지로 쓰기가 좋아지고 있으며 악평도 줄어들고 있다. 그래도 이미 세상에는 많은 C# 또는 자바스크립트 개발자들이 있고, 이들은 기존에 손에 익은 언어로 개발할 수 있는 플랫폼을 선호하기 때문에 이들보다 개발 인구가 훨씬 적은 Dart는 약점을 안고 있다.

또한 각각의 운영체제 및 하드웨어 쪽으로 특화된 기능을 활용하는 데에는 한계가 있다. 이건 Flutter만이 아닌 모든 크로스 플랫폼의 한계라고 봐야 할 문제. 이런 부분은 각 운영체제마다 필요한 대로 네이티브 코드를 붙일 수 있다. 다만 카메라나 위치정보처럼 공통적인 인터페이스를 잘 제공하는 패키지들도 늘어나고 있기 때문에 네이티브 코드로 처리해야 할 부분들이 점점 줄어들고 있기도 하다.

국제화 부분도 불편한 점으로, 문자열 자원을 언어별로 관리하는 게 안 되는 건 아니지만 각각의 언어별로 문자열을 모두 클래스로 만들어야 하기 때문에 안드로이드나 iOS 네이티브로 개발할 때보다는 많이 번거롭고 툴의 지원도 별로 좋지 않다. 이런 부분들은 시간이 지나면서 여러 가지 툴이 나오면서 나아지고는 있다. 구글은 JSON 형식 기반의 ARB 파일을 만들어서 컴파일하면 클래스가 자동으로 만들어지는 방법도 제공하고 있어서 많이 편해지긴 했지만 그래도 최소한 안드로이드라면 네이티브로 개발할 때보다는 좀 복잡하다.

코드 스타일 면에서는 자바스크립트의 그 악명 높은 콜백 지옥을 방불케 하는 들여쓰기 지옥이 있다. 위젯을 만들 때에는 속성을 생성자의 매개변수로 전달하는 방식을 사용하는데, Flutter의 레이아웃은 위젯의 트리 구조로 이루어진다. 자식 위젯은 보통 부모 위젯의 child(단일 위젯) 또는 children(위젯의 배열) 속성으로 전달하는데, 레이아웃이 복잡해지면 그만큼 위젯의 계층 수도 늘어나고, 그러면 부모 위젯 생성자의 chlid 속성에 자식 위젯의 생성자가 들어가고, 그 자식 위젯의 생성자 child 속성에 손자 위젯의 생성자가 들어가고... 이런 식으로 이어진다. 또한 위젯의 여백을 준다든가, 테두리 모양을 바꾼다든가, 위젯들을 정렬한다든가, 사용자 입력 반응 기능이 없는 위젯에 이러한 기능을 부여한다든가 할 때에도 위젯을 사용하므로 위젯의 계층 수가 두 자릿수로 갈 수 있으며 이렇게까지 가면 콜백 지옥 저리가라 할 정도의 들여쓰기 지옥을 맛볼 수 있다. 이를 피하려면 build() 안에 모든 위젯 렌더링 코드를 넣지 말고 Widget 객체를 돌려주는 몇 개의 메서드로 쪼갠 다음 이를 build()에서 부르거나, 여러 클래스에 걸쳐 쓰인다면 별도로 위젯 클래스를 만들어서 분리하는 방법도 있다.

용량도 아직은 문제인데, 자체적으로 사용자 인터페이스를 렌더링하는 Skia 엔진이 들어가므로 운영체제의 UI 관련 라이브러리를 불러다 쓰면 되는 네이티브보다는 덩치가 클 수밖에 없다. 릴리즈 모드로 컴파일 하면 Skia 중에 실제 앱에서 쓰는 부분만 포함시키는 방식으로 크기를 줄이긴 하지만 그래도 네이티브와는 차이가 꽤 난다. 구글도 이 점은 알고 있기 때문에 버전을 올려 나가면서 앱의 크기를 줄이는 데 많이 신경쓰고 있다. 이런 문제는 다른 크로스 플랫폼도 안고 있다. 예를 들어 .NET 프레임워크의 크로스 플랫폼 버전인 모노 프레임워크를 안고 들어가야 하는 자마린 역시 'Hello world!' 하나 보여주는 앱도 용량이 장난 아니다.

개발 환경

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

안드로이드 스튜디오는 구글에서 공식 제공하는 툴이고 뛰어난 IDE로 정평이 나 있는 IntelliJ IDEA를 기반으로 한 만큼 좋은 개발 환경을 제공한다. 다만 덩치가 커서 저사양 컴퓨터에서는 부담스럽고, 원래 자바 또는 코틀린을 위한 툴이었기 때문에 Dart 지원은 좀 떨어지는 느낌이 있다. 비주얼 스튜디오 코드에 구글이 공식 Flutter 플러그인을 제공하고 있으며, 이를 통해 코딩, 리팩토링, 디버깅은 웬만큼 할 수 있다. 무엇보다도 안드로이드 스튜디오보다는 가볍다는 게 확실한 장점이기 때문에 고급 개발자들 중에는 이쪽을 더 선호하는 이들도 많다. 물론 이쪽도 무료다. iOS용 앱 개발을 위해 맥과 Xcode가 필요한 건 이쪽도 마찬가지다.

개발을 위해 비주얼 스튜디오 코드를 사용하더라도 용량에 이유가 있다면 안드로이드 스튜디오는 깔아놓는 게 좀 더 편하다. 예를 들어 에뮬레이터 관리 툴은 안드로이드 스튜디오를 쓰는 게 확실히 편하며 새로운 Flutter 프로젝트를 만들 때에도 안드로이드 스튜디오를 쓰면 마법사 인터페이스로 좀 더 자세한 선택사항을 손쉽게 지정할 수 있는 반면, 비주얼 스튜디오 코드는 기본설정값으로 만들거나 명령줄에서 선택사항을 지정해야 한다.

윈도우든 맥이든 리눅스든 개발 자체는 가능하지만 문제는 테스트인데, 에뮬레이터든 실제 아이폰이든 iOS에 앱을 올려서 테스트해 보려면 반드시 Xcode가 필요하고, 폐쇄적인 정책으로 먹고사는 애플답게, Xcode는 맥OS에서만 쓸 수 있으므로 반드시 맥이 필요하다. 반대로 맥에서는 안드로이드 에뮬레이터 사용에 제약이 없으므로 결국 크로스 플랫폼 개발을 위해서는 맥을 쓸 수밖에 없다. 당장 맥에 돈을 투자하기 어렵다면 Xcode가 돌아갈만한 맥을 중고든 뭐든 구한 다음, 개발 작업은 주로 다른 컴퓨터에서 하고 iOS 테스트만 맥에서 할 수도 있는데, 이러나 저러나 맥이 있긴 있어야 한다.

IDE가 싫다면 자기가 좋아하는 코드 편집기로 코딩하고 실행이나 빌드는 명령줄에서 처리하는 것도 얼마든지 가능하다. IDE를 사용하더라도 결국은 명령줄을 써야 할 때가 종종 있다. 릴리즈 버전 빌드를 한다든가, Pub 패키지 업데이트를 한다든가 할 때에는 명령줄을 이용해야 한다.

간단한 Dart 코드를 웹 브라우저 안에서 편집하고 실행하는 Dartpad도 제공하는데, 여기서도 간단한 Flutter 앱 정도는 돌려볼 수 있다. 아 주 간단하게 Flutter 기본 코드를 만들어 주기도 한다. 실행은 같은 웹 브라우저 창 안에서 이루어진다.