Medium - What's Revolutionary about Flutter

15 Aug 2019 in Trend

원문 - Wm Leler

Trend 파악을 Medium 기고문 요약 포스팅 - 플러터의 혁신적인 점에 대해

What is Flutter

플러터 모바일 앱 SDK는 과거에 일반적이었던 “cookie cutter” 앱과는 달리 새로운 방법으로 아름다운 네이티브 앱을 만들 수 있습니다. 플러터를 사용해 본 사람이라면 정말 좋아할 것입니다. 한번 이거랑 이거랑 이거를 봐보세요. 아니면 써드파티에서 컴파일된 기사와 비디오 리스트를 보세요.

새로운 시스템을 접하면 으례 그러듯 사람들은 무엇이 플러터의 차이점인지, 다른 방식으로 하는지, “플러터의 어떤 점이 새롭고 흥미로운 것인가” 에 대해 알고 싶어합니다. 당연한 질문입니다. 이 기사에서는 기술적인 관점으로 해당 질문에 대해 무엇이 플러터이고 왜 그런지 대답을 해보겠습니다.

그전에 짧게 역사에 대해 말씀드리겠습니다.

A brief history of mobile app development

모바일 앱 개발은 비교적 최신 분야입니다. 외부 개발자들이 앱을 만들어온지 10년 가까이 되니 개발도구들이 계속 발전하는 것은 당연합니다.

The Platform SDKs

애플 iOS SDK는 2008년에 릴리즈 되었고 구글 안드로이드 SDK는 2009년에 릴리즈 되었습니다. 이 두 SDK들은 오브젝트 C와 Java로 대표되는 다른 언어를 기반으로 합니다.

여러분의 앱은 플랫폼과 위젯을 만들거나 카메라와 같은 서비스를 접근하려고 대화합니다. 위젯은 스크린 캔퍼스에 그려지고 이벤트는 위젯에게 전달됩니다. 이것은 간단한 구조이지만 위에서 언급한 네이티브 언어의 차이 말고도 각 플랫폼마다 위젯이 다르므로 플랫폼마다 앱을 만들어야 합니다.

WebViews

첫 크로스 플랫폼 프레임워크는 자바스크립트에 기반을 둔 웹뷰입니다. 예제들은 연관된 프레임워크들을 포함합니다: PhoneGap, Apache Cordova, Ionic, 기타 등등. 애플이 그들의 iOS SDK를 발표하기 전에 그들은 외부 개발자들에게 아이폰을 위한 웹앱을 만들도록 장려했습니다. 그러니까 웹 기술을 이용해서 크로스 플랫폼 앱을 만드는 것은 당연한 단계입니다.

여러분의 앱은 HTML을 만들고 플랫폼의 웹뷰에 그것을 표시합니다. 자바스크립트와 같은 언어는 네이티브 코드(서비스와 같은)와 바로 통신하기가 매우 어렵습니다. 그래서 그들은 “bridge”를 이용하여 자바 영역에서 네이티브 영역으로 컨텍스트를 교환합니다. 플랫폼 서비스들은 대개 자주 호출되지 않으므로 이것은 그렇게 성능 문제를 일으키지 않습니다.

Reactive Views

ReactJS(그리고 기타)와 같은 반응형 웹 프레임워크들은 주로 인기있는 이유가 그것이 반응형 프로그래밍의 패턴을 사용하여 웹뷰를 간단히 만들 수 있기 때문입니다. 2015년에 React Native는 모바일 앱에게 반응형 스타일 뷰의 많은 장점을 가져다 주었습니다.

React Native는 매우 유명하지만 자바스크립트 영역이 플랫폼 위젯의 네이티브 영역을 접근할 때 Bridge를 지나야 합니다. 위젯은 꽤 빈번하게 접근되므로(애니메이션, 이동, 유저 스와이프와 같은 기능은 초당 60번까지 접근) 이것은 성능 문제를 일으킬 수 있죠. 다음은 React Native에 관련된 기사의 내용입니다.

여기에 보이는 이 줄이 리액트 네이티브의 성능을 이해하는 핵심 요소입니다. 각 영역 내에서는 매우 빠릅니다. 성능 병목지점은 주로 한 영역에서 다른 영역으로 이동할 때 발생합니다. 좋은 리액트 네이티브 앱을 설계하려면 브리지를 최소한으로 유지해야 합니다,

Flutter

리액트 네이티브처럼 플러터도 반응형 스타일 뷰를 제공합니다. 플러터는 자바스크립트의 브릿지가 일으키는 성능 문제를 피하기 위해 Dart라고 하는 컴파일된 프로그래밍 언어를 사용합니다. 다트는 다양한 플랫폼의 네이티브 코드에 사전 컴파일 됩니다. 이것은 플러터에게 자바스크립트 브릿지를 사용한 컨텍스트 교체를 하지 않아도 플랫폼과 통신할 수 있게합니다. 네이티브 코드로 컴파일링 하는 것은 앱의 시작 시간도 향상 시킵니다.

플러터가 자바스크립트 브릿지 없이 리액티브 뷰를 제공하는 유일한 모바일 SDK라는 것만으로도 플러터는 사용해볼 가치가 있고 흥미롭습니다. 그러나 플러터를 더욱 혁신적으로 만드는 것이 있는데 그것은 위젯을 구현하는 방법입니다.

Widgets

위젯은 뷰에 영향을 미치고 제어하는 요소이며 앱의 인터페이스 입니다. 위젯이 앱의 가장 중요한 부분이라고 해도 과언이 아닐 것입니다. 사실 위젯 하나로 앱을 만들거나 박살낼 수 있습니다.

• 위젯의 외관과 느낌은 최고입니다. 위젯은 보기 좋아야하고 다양한 화면 크기가 있어야 하죠. 느낌도 자연스럽습니다.
• 위젯은 빠르게 수행되어야 합니다: 위젯 트리를 만들기 위해서 위젯을 전개하고(자식을 선언하여), 화면에 나열하고, 그리거나 애니메이션 할 수 있습니다.
• 최신 앱들의 위젯은 확장가능하고 수정가능해야 합니다. 개발자들은 멋진 앱들을 추가할 수 있는 것을 원하고 모든 위젯을 앱 브랜드에 맞게 수정하길 바랍니다.

플러터는 위젯의 외관이 좋고 자연스러우며 빠르고 모두 수정가능하고 확장가능한 새로운 구조를 가지고 있습니다. 그래요, 플러터는 플랫폼 위젯이나 DOM 웹뷰를 사용하지 않고 자체 위젯을 제공합니다.

플러터는 확장가능하고 수정할 수 있는 위젯을 만들고 앱 내의 플랫폼으로 부터 렌더링합니다. 플러터가 플랫폼으로부터 요구하는 것은 화면에 위젯을 표시할 수 있는 캔버스와 터치와 타이머 같은 이벤트, 그리고 카메라와 위치정보 같은 서비스 들입니다.

물론 데이터 인코딩과 디코딩을 위한 다트 프로그램과 네이티브 플랫폼 코드(iOS, Android 개별로) 사이에 인터페이스가 필요합니다만 자바스크립트 브릿지에 비해서는 훨씬 빠릅니다.

위젯을 옮겨서 앱에서 그리는 것은 앱의 용량에 영향을 미칩니다. 안드로이드에서 가장 단순한 앱은 약 4.7MB 입니다. 플러터의 장점이 이런 단점과 맞먹는 것인지 결정하는 것은 여러분 입니다. 그러면 나머지 장점에 대해서 얘기해 봅시다.

Layout

플러터의 가장 큰 개선점은 레이아웃을 하는 방법입니다. 레이아웃은 제약조건을 기반으로 위젯의 크기와 위치를 결정합니다.

일반적으로 레이아웃은 어떤 위젯에도 적용될 수 있는 큰 규칙들의 집합입니다. 이 규칙들은 다양한 레이아웃 메소드 들을 구현합니다. 잘 알려진 CSS 레이아웃 예제를 살펴봅시다. CSS는 HTML(위젯들) 요소에 적용되는 프로퍼티들(제약조건)을 가지고 있습니다. CSS3은 375개의 프로퍼티를 정의합니다.

CSS는 레이아웃 모델의 수와 박스 모델, 플로팅 요소, 테이블, 복수의 텍스트 열, 미디어 페이지 등등 입니다. 추가적으로 flexbox와 grid 같은 레이아웃 모델은 나중에 추가되었는데 개발자와 디자이너들이 레이아웃을 넘어서는 제어를 원하고 또한 테이블과 투명이미지를 통해 그들이 원하는 것을 얻으려고 했기 때문입니다. 전통적인 레이아웃은 개발자들이 새로운 레이아웃 모델을 추가할 수 없었기 때문에 flexbox와 grid는 CSS에 추가되어야 했고 모든 브라우저에서 구현되었습니다.

전통적인 레이아웃의 또 다른 문제는 제약조건이 충돌하거나 서로 상호작용해서 한 요소에 적용된 규칙이 수십개가 되었습니다. 이것은 레이아웃을 느리게 만들었죠. 게다가 레이아웃의 성능은 일반적으로 N제곱이었기 때문에 요소들이 늘어날 수록 레이아웃은 더욱 느려졌습니다.

플러터는 구글 팀의 크롬브라우저 멤버들에 의해 테스트가 시작되었습니다. 그들은 전통적인 레이아웃 모델을 무시하면 더욱 빠르게 렌더링이 될 수 있는지 확인하고 싶었습니다. 몇 주후 그들은 엄청난 성능 향상을 확인했습니다. 그들이 발견한 것은

• 대다수의 레이아웃은 간단하게 연관되어 있다: 스크롤링 페이지 위에 텍스트, 화면의 크기에 따라 크기와 위치가 바뀌는 사각형, 그리고 테이블, 플로팅 요소 등등
• 대다수의 레이아웃은 위젯의 하위항목에 한정되며 하위항목은 일반적으로 하나의 레이아웃 모델만 쓰기 때문에 해당 위젯을 지원하기 위한 제약조건의 수는 매우 작다.

우리는 레이아웃이 위젯의 헤드에서 시작된다면 레이아웃이 매우 간단해 질 수 있는 것을 알아냈습니다.

• 모든 위젯에 적용할 수 있는 레이아웃의 모든 제약조건을 가지는 것 대신 각 위젯이 그들이 필요로 하는 간단한 레이아웃 모델을 명시하는 것
• 각 위젯이 훨씬 작은 레이아웃 제약조건만 고려하므로 레이아웃은 매우 최적화 됨
• 더욱 레이아웃을 더욱 간단히 하기 위해 거의 모든것을 위젯 안으로 넣음

아래는 레이아웃이 있는 간단한 위젯 트리를 만드는 코드 입니다.

new Center(
  child: new Column(
    children: [
      new Text('Hello, World!')),
      new Icon(Icons.star, color: Colors.green)
    ]
  )
)

이 코드의 결과물은 쉽게 예상이 가시겠지만 아래와 같이 표시됩니다.

이 코드에서는 레이아웃을 포함하여 모든 것이 위젯안에 있습니다. Center 위젯의 중앙은 화면과 같은 부모의 안에 있는 자식입니다. Column 레이아웃 위젠은 위젯의 리스트와 같은 자식들을 수직으로 배치합니다. column은 텍스트 위젯과 아이콘 위젯을 가지고 있습니다.

플러터에서는 centering과 padding이 위젯입니다. 자식에게 적용하는 Themes들도 위젯입니다. 심지어 applications와 navigation들도 위젯입니다.

플러터는 열 뿐만아니라 행, 격자, 리스트 등등의 레이아웃을 위한 위젯들을 많이 가지고 있습니다. 게다가 플러터는 Sliver 레이아웃 모델이라고 하는 스크롤링에 사용되는 특수한 레이아웃 모델이 있습니다. 플러터의 레이아웃은 매우 빨라서 스크롤링에 사용될 수 있습니다. 잠깐 생각해 봅시다. 스크롤링은 화면에 표시된 이미지가 그들의 손가락에 붙어서 드래그 하는 것처럼 부드럽고 즉각적인 느낌이 와야 합니다.

스크롤링을 위한 레이아웃을 사용함으로써 플러터는 아래 화면과 같이 더욱 진보된 스크롤링을 구현할 수 있습니다. 아래는 GIF이미지들 이라는걸 기억하세요, 플러터는 더욱 부드럽습니다. 여러분은 (반드시) 자신의 앱에서 이것을 실행해 볼 수 있습니다. 이 기사의 끝에 리소스 영역을 참고하세요.

Flutter Gallery app

Posse Gallery app

Posse Gallery app

대개 플러터는 단을 패스에서 레이아웃을 수행합니다. 이 말은 선형적인 복잡도를 가지기 때문에 많은 수의 위젯을 처리할 수 있습니다. 또한 플러터는 가능하다면 캐싱을 통해 레이아웃의 모든 것을 실행하지 않을 수 있습니다.

Custom design

이제 위젯이 앱의 일부이기 때문에 새로운 앱을 추가하거나 기존의 앱을 수정하여 새로운 외관이나 느낌을 주도록 혹은 회사의 브랜드와 일치하게 할 수 있습니다. 모바일 디자인의 트렌드는 몇 년전에 일반적이었던 cookie cutter 앱이 아닌 유저를 기쁘게 하고 보상을 느끼게 하는 커스텀 디자인 입니다.

플러터는 iOS와 Android를 위한 풍부한 맞춤형 위젯과 Material Design을 가지고 있습니다. 사실 우리는 플러터가 매우 우수한 Material 디자인의 구현한 것들 중 하나라고 말하곤 합니다. 우리는 다양한 플랫폼의 네이티브 위젯들이 가진 느낌과 외관을 플러터의 위젯 세트를 이용하여 일치하게 하는데 사용하고 있습니다. 앱 개발자들은 동일한 커스텀을 살짝 수정해서 그들이 원하고 필요로 하는 위젯을 만들 수 있습니다.

More about Reactive Views

반응형 웹뷰를 위한 라이브러리들은 virtual DOM입니다. DOM은 HTML Document Object Model로서, 자바스크립트를 사용하여 HTML 문서를 수정하는 API입니다. Virtual DOM은 DOM의 추상화 버전으로 프로그래밍 언어의 객체를 사용하여 만들어진 것입니다.

ReactJS와 같은 시스템으로 구현된 반응형 웹뷰에서 virtual DOM은 불변성을 가지기 때문에 변경 사항이 있는 경우 새로 빌드 해야 합니다. Virtual Dom은 실제 Dom과 비교하여 작은 변경의 집합을 생성하여 실제 DOM을 업데이트 시킵니다. 최종적으로 플랫폼이 실제 DOM을 사용하여 다시 렌더링을 하고 캔버스에 그립니다.

이것은 추가적인 작업을 하는 안좋은 방식처럼 들릴 수 있지만 HTML DOM 문서를 조작하는 것이 매우 시간이 걸리기 때문에 충분히 가치있습니다.

Reactive Native도 같은 일을 하지만 모바일에 국한됩니다. DOM 대신에 그것은 모바일 플랫폼의 네이티브 위젯을 조작합니다. virtual DOM 대신에 React Native는 위젯의 가상 트리를 구성하고 실제의 위젯과 비교한뒤 변경사항이 있을 때 업데이트 합니다.

React Native는 네이티브 위젯과 통신하기 위해 브릿지를 통한다는 것을 기억하세요. 그래서 가상 위젯 트리는 그냥 네이티브 위젯을 사용하는 것보다 브릿지를 최소한으로 유지하는 데 도움이 됩니다. 마지막으로 네이티브 위젯이 업데이트 되면 플랫폼은 그것들을 캔버스에 그립니다.

React Native는 모바일 개발에 있어서 큰 승리였고 플러터에게 영감을 주었지만 플러터는 더욱 진보했습니다.

플러터에서 호출하면 위젯과 렌데러는 플랫폼에서 유저의 앱 내로 이동합니다. 네이티브 플랫폼에는 위젯 조작하는 부분이 없기 때문에 가상 위젯트리는 이제 그냥 위젯트리가 됩니다. 플러터의 렌더러는 위젯트리를 그리고 플랫폼의 캔버스에 그립니다. 이것은 매우 간단하고 빠릅니다. 추가적으로 사용자 영역에서 애니메이션이 발생해서 앱(개발자들)은 더욱 많은 것을 제어할 수 있습니다.

플러터의 자체 렌더러는 흥미롭습니다. 화면에 업데이트가 필요한 위젯만 렌더하기 위해 내부적으로 몇 개의 트리 구조체를 가지고 있습니다. 예를 들어 렌더러는 “합성을 통한 구조적 리페인팅”을 사용합니다. (구조적 이란 말은 위젯을 말하며 화면의 사각 영역보다 더욱 효율적입니다.) 위젯이 변하지 않으면 위젯이 움직이더라도 캐시의 비트블리트를 사용해 매우 빠르게 처리됩니다. 이것이 플러터에서 스크롤링을 매우 우수하게 만들어 주는 이유 중 하나 입니다.

The Dart programming language

플러터는 - 다른 리액티브 뷰를 사용하는 시스템과 같이 - 새로운 프레임 마다 뷰 트리를 갱신합니다. 그것은 많은 오브젝트들이 오직 한프레임에만 살아있도록 하죠. 다행히 다트는 객체들은 이런 시스템에 매우 효과적인 “generational garbage collection”을 합니다. 추가적으로 객체 할당은 싱글 포인터에 의해 수행되며 매우 빠르고 락을 요구하지 않습니다. 이것은 UI jank나 stutter를 피하는데 도움이 됩니다.

다트는 또한 “tree shaking”컴파일러가 있어서 오직 앱에 필요한 코드만 포함합니다. 큰 위젯 라이브러리에서 한 두개만 사용한다고 해도 맘 편하게 사용하실 수 있습니다.

Hot reload

플러터의 가장 인기있는 특징은 매우 빠른 상태저장 핫리로드 입니다. 여러분은 앱이 실행되는 동안에 수정을 할 수 있으며 수정된 코드는 몇 초내에 반영됩니다. 만약 앱의 에러가 발생한다면 일반적으로 에러를 고치고 에러가 없었던 것 마냥 계속할 수 있는 것이죠. 그냥 새롭게 풀 리로드를 해도 빠릅니다.

hot stateful reload

개발자들은 이것이 그들이 앱을 그릴 수 있게 한다고 말합니다. 하나의 수정을 앱을 재시작하지 않아도 거의 실시간으로 결과를 볼 수 있죠.

Compatibility

위젯들이 플랫폼이 아닌 앱의 일부이기 때문에 호환 라이브러리들이 필요없습니다. 다른 OS 버전에서도 동일하게 동작할 것입니다. 이것은 오래된 OS 버전의 앱을 테스트하는 필요를 없애줍니다. 게다가 이것은 당신의 앱이 미래의 OS 버전에서도 동작할 수 있는 것이죠.

우리가 질문받는 잠재적인 위험이 하나 있습니다. 플러터는 네이티브 플랫폼 위젯을 사용하지 않기 때문에 새로운 iOS/Android 버전이 나와서 새로운 위젯을 지원하거나 기존의 위젯의 동작을 수정할 경우 플러터가 그것을 반영하는데 오래걸리지 않을까 하는 것입니다.

• 먼저 구글은 플러터의 큰 내부 고객이므로 플러터는 위젯의 집합들이 현재 플랫폼 위젯 집합과 가능한 비슷하도록 유지할 것입니다.
• 만약 위젯 업데이트가 유독 느린 경우가 있다고 해도 구글만이 플러터의 위젯을 관리하는 사용자가 아닙니다. 플러터의 위젯들은 확장성과 커스텀에 우수하기 때문에 누구나 업데이트 할 수 있습니다. 풀리퀘스트를 할 필요도 없고 여러분은 굳이 플러터가 업데이트가 되길 기다릴 필요가 없습니다.
• 위에 지적한 점들은 당신이 새로운 변경사항을 앱에 적용하고 싶을 떄 입니다. 만약 새로운 변경점을 앱에 적용하고 싶지 않다면 상관없습니다. 위젯은 앱의 일부이므로 앱의 외관을 나쁘게 만들지 않는 이상 위젯은 절대 바뀌지 않을 것입니다.
• 게다가 오래된 버전의 OS에서도 새로운 위젯을 사용할 수 있는 장점이 있죠.

Other benefits

플러터는 간단함 때문에 빠르고 넓은 커스텀과 확장성 때문에 강력합니다.

다트는 여러분이 앱의 능력을 확장할 수 있는 소프트웨어 패키지 저장소를 가지고 있습니다. 예를 들어 Firebase에 접근하기 쉽게 하는 무수한 패키지가 있으므로 여러분은 serverless 앱을 만들 수 잇습니다. 외부 기여자는 Redux Data Store에 접근할 수 있는 패키지를 만들고 있습니다. 이 패키지들은 “플러그인” 이라고 불리며 카메라나 가속도측정기와 같은 플랫폼 서비스와 하드웨어에 OS 독립적으로 쉽게 접근하게 만듭니다.

물론 플러터는 오픈소스이기 때문에 플러터가 앱의 일부가 되어 렌더링 된다는 사실과 함께 앱에서 원하는 모든 것을 수정할 수 있다는 것입니다. 아래 이미지의 초록색은 모두 수정할 수 있습니다.

So, “What’s new and exciting about Flutter?”

만약 누군가 플러터가 뭐냐고 묻는다면 이제 이렇게 대답하실 수 있으실 겁니다.

• 자바스크립트 브릿지 없이 반응형 뷰의 장점을 가질 수 있다.
• 빠르고 부드럽고 예측가능하다. 코드는 네이티브 코드쪽으로 사전컴파일 된다.
• 개발자는 레이아웃과 위젯을 모두 제어할 수 있다.
• 예쁘고 수정가능한 위젯을 사용할 수 있다.
• 핫리로드와 같이 개발자에게 좋은 도구가 있다.
• 호환성이 좋고 성능이 좋고 재밌다.

Resources

• Watch the Flutter videos from Google I/O 2018
• Watch the videos from DartConf2018, held Jan 23-24, 2018 in LA, California
• Introducing Flutter video
• Why Flutter uses Dart

Summary

• 플러터는 플랫폼 위젯이 아닌 자체 렌더러와 위젯을 지원하여 OS, Version 독립적으로 앱을 구동시킬 수 있다.
• 오래된 버전의 앱을 테스트하는 시간을 줄여주며 낮은 버전의 앱에서 최신 위젯을 쓸 수 있다.
• 반응형 뷰를 구성하기 위해 자바스크립트 브릿지가 필요하지만 성능 저하가 문제가 된다.
• 플러터는 다트를 이용하여 자바스크립트 브릿지가 필요없기 때문에 매우 간단하고 속도가 빠르다.
• 플러터는 예쁜 위젯을 제공할 뿐더러 오픈소스에 확장성, 수정이 용이하므로 퀄리티 있는 앱을 빠르게 만들 수 있다.