Flutter 편집하기

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

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

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

==특징==

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

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

다만 Flutter 웹은 [[HTML]]와 CSS, [[자바스크립트]]<ref>Flutter가 나오기 전부터 [[Dart]]는 [[자바스크립트]]로 컴파일할 수 있는 기능을 제공했다.</ref>를 사용한다. 이쪽은 이 두 가지만 가지고도 어지간히 다 할 수 있기도 하고<ref>아파치 코르도바가 내장한 [[HTML]]을 UI에 사용하는 방식으로 크로스 플랫폼 모바일 앱을 구현할만큼 HTML과 CSS만 있으면 웬만한 UI는 다 구현할 수 있다.</ref> 웹 표준을 무시하면 매장당하는 문제도 있다. Flutter를 웹 개발에 쓰면 사실상 [[HTML]]나 CSS 코딩 없이 [[Dart]]만으로 다 만들 수 있다.<ref>애초에 Flutter의 구조가 웹 구조에 힌트를 얻은 것이기도 하다. [[자바]] 기반 아파치 위켓 웹 프레임워크는 모든 것을 위젯으로 보고 모든 구성요소를 위젯 트리 구조로 구성하며, [[XML]] 같은 것을 쓰지 않고 UI도 코드로 몽땅 처리하는 데다가 stateless와 stateful 개념을 가지고 있어서 많은 면에서 Flutter와 닮아 있다.</ref>

===핫 리로드===

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

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

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

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

===위젯===

Flutter에서는 모든 요소가 위젯(Widget)이다. 페이지조차도 위젯이다. 심지어는 아예 가장 기본이 되는 App 클래스<ref>App 클래스 객체를 main() 함수에서 runApp() 함수 매개변수로 전달하는 것이 모든 Flutter 앱의 시작 지점이다.</ref> 조차도 StatelessWidget 클래스에서 상속 받는다! 대부분의 위젯은 child, 또는 children 속성으로 자식 위젯을 품을 수 있다. 따라서 Flutter의 UI는 위젯의 트리 구조다.

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

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

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

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

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

===그밖에===

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

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

==성능==

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

{| class="wikitable"
|-
! !! colspan="2" | iOS !! colspan="2" | 안드로이드
|-
! !! 가우스-르장드르 !! 보웨인 !! 가우스-르장드르!! 보웨인
|-
| 리액트 네이티브 || style="text-align:right;" | 2992.0 || style="text-align:right;" | 582.1 || style="text-align:right;" | 3289.3 || style="text-align:right;" | 821.9
|-
| Flutter || style="text-align:right;" | 188.7 || style="text-align:right;" | 179.5 || style="text-align:right;" | 272.5 || style="text-align:right;" | 285.2
|-
| [[스위프트]] || style="text-align:right;" | 218.3 || style="text-align:right;" | 35.0 || style="text-align:right;" | &mdash; || style="text-align:right;" | &mdash;
|-
| [[오브젝티브 C]] || style="text-align:right;" | 127.5 || style="text-align:right;" | 16.7 || style="text-align:right;" | &mdash; || style="text-align:right;" | &mdash;
|-
| [[자바]] || style="text-align:right;" | &mdash;|| style="text-align:right;" | &mdash; || style="text-align:right;" | 222.0 || style="text-align:right;" | 143.0
|-
| [[코틀린]] || style="text-align:right;" | &mdash; || style="text-align:right;" | &mdash; || style="text-align:right;" | 223.0 || style="text-align:right;" | 144.0
|}

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

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

==단점==

문제점이라면 Flutter의 개발 언어인 [[Dart]]가 별 인기가 없다는 것... 원래는 [[자바스크립트]]를 대체할 언어로 들고 나왔지만 시장에서 완전히 파묻혔으며<ref>[[자바스크립트]]를 대체하려면 바로 [[HTML]] 안에 삽입해서 돌아갈 수 있도록 브라우저가 지원해줘야 하는데 구글이 만든 크롬 말고는 지원하는 브라우저가 없다. 물론 크롬의 점유율이 높긴 하지만 맥 사용자는 대부분 사파리를 쓰며 아이폰이나 아이패드는 닥치고 사파리, 그리고 파이어폭스도 어느 정도 사용자층을 가지고 있는 점을 생각해 보면 자바스크립트의 대안이라는 원래 목적은 실패에 가깝다.</ref>, [[자바스크립트]]의 대안은 [[MS]]가 들고 나온 [[타입스크립트]]가 잡고 있는 실정이다. [[Dart]]나 [[타입스크립트]]나 간단한 컴파일을 통해 [[자바스크립트]]로 번역되기 때문에 이미 상당히 성숙해 있으며 개발자 저변도 넓은 [[자바스크립트]]를 대체한다기보다는 보완하는 역할 정도인데, 여기서도 [[타입스크립트]]한테 완전히 밀려서 쓰레기 취급 받던 언어다. 기능 확장을 위한 패키지들도 [[파이썬]]이나 [[자바스크립트]]에 비하면 형편없이 부족하다. 아무튼 구글에서 그냥 파묻기에는 아까웠던 건지 Flutter를 통해 [[Dart]]를 부활시킨 셈이다. Flutter에 힘입어 Dart도 약진하고 있고, [[크로스 플랫폼]] 언어 시장에서는 리액트 네이티브와 치열한 1위 경쟁을 벌이는 수준까지 올라왔다.<ref>[https://www.statista.com/statistics/869224/worldwide-software-developer-working-hours/ "Cross-platform mobile frameworks used by software developers worldwide in 2019 and 2020"], Statista, 2 July 2020.</ref>

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

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

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

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

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

==개발 환경==

[[안드로이드 스튜디오]], IntelliJ IDEA<ref>무료로 쓸 있는 커뮤니티 에디션에서도 쓸 수 있다. [[안드로이드 스튜디오]] 자체가 IntelliJ IDEA 기반이다.</ref>, [[비주얼 스튜디오 코드]]에서 사용할 수 있다. 이들 모두는 기본 제공 기능이 아니며 플러그인을 설치하면 쓸 수 있다. 모두 크로스 플랫폼 개발 환경이므로 [[윈도우]], 맥, [[리눅스]]에서 개발할 수 있다. 다만 [[iOS]]용 실행 패키지를 빌드하려면 맥과 [[Xcode]]가 있어야 한다.<ref>빌드 명령은 [[안드로이드 스튜디오]] 또는 [[비주얼 스튜디오 코드]]로 실행하지만 XCode만이 애플의 코코아 프레임워크에 접근할 수 있도록 막아놓았기 때문에 [[Xcode]]의 빌드 툴 체인이 있어야 실제로 빌드를 할 수 있기 때문이다. 어떤 애플 기반 개발 환경에서는 어떤 툴을 쓰든 마찬가지다. 하지만 [[Xcode]]는 무료 배포이므로 맥만 있으면 다운로드 받을 수 있다.</ref> 실행은 안드로이드라면 실제 기계가 없어도 안드로이드 SDK에서 제공하는 에뮬레이터를 사용하면 되지만 [[iOS]]는 에뮬레이터도 맥에서만 돌릴 수 있으므로 맥과 Xcode가 필요하다.

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

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

IDE가 싫다면 자기가 좋아하는 코드 편집기로 코딩하고 실행이나 빌드는 명령행에서 처리하는 것도 얼마든지 가능하다.

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

{{각주}}