[이상한모임X월간지앤선] Flutter: the good, the bad and the ugly

번역: 이상한모임 번역팀

편집: 지앤선 편집장 아델라

Flutter로 첫 번째 앱을 만들고 나서, 또 다른 크로스 플랫폼 개발의 경쟁자인 React Native와 기술적인 장단점을 비교해 봤어요.

 

 

 

 

Flutter를 테스트해 보려고 '작은 이야기'(Little Tales)란 앱을 만들었는데요, 동화를 들려주는 기능에 초점을 둔 일종의 오디오 플레이어입니다. 처음 세 화면은 Android에 어두운 색 테마를 적용한 것이고, 나머지는 밝은 색 테마를 사용한 iOS 화면입니다.

 

작년 이맘때엔, 'React Native: 첫번째 앱을 만들고 난 느낌'이란 글을 올렸어요. 2016, 2017년 그 당시엔 Facebook, Instagram, Tesla, Walmart, Airbnb, Skype 기타 많은 회사들이 React Native를 도입하려고 조사중이거나, 실제 활용하느라(부분적으로라도) 열을 올리고 있었죠.

 

하지만 올해, 유명한 회사들 중에 React Native를 버리겠다고 선언한 곳들도 있는 걸로 볼 때, React Native가 매력을 잃어가는 것 같습니다. 아니면, 이미 잃어버렸을지도 모르죠. (Airbnb의  Gabriel Peal의 글이나 Udacity의 Nate Ebel가 쓴 글 참조) 개발자들의 이야기이나 요즘 올라오는 기사들, 아니면 LinkedIn에서 채용 담당자들이 찾는 것에서 미루어 볼 때, React Native는 더 이상 핫한 기술은 아닌 것 같아요. 그래도 분명한 건 React Native가 죽은 기술은 아니라는 점입니다. 어떤 회사에서 찬밥 신세라도 다른 회사에서는 그렇지 않을 수 있죠. 이런 회사들에서는 전체 앱을 React Native로 만들기보다는 일부 섹션을 만드는 데 활용했고, 그게 사용하기 꽤 복잡한 이유 중 하나지요. 아무튼 React Native의 대중화에 기여하던 큰 회사들이 (글도 올리고, 인기있는 React Native용 오픈소스 라이브러리도 만들고 했죠), 나중에 더 이상 사용하지 않기로 결정하면 커뮤니티에 영향을 줄 수 밖에 없다는 건 부정할 수 없겠죠. 최소한, React Native를 쓸지 말지 결정을 내리지 못하던 팀들은, 위에서 언급한 글들을 보고 이제는 더 쉽게 사용하지 않는 쪽으로 결정을 내리게 된 거죠.

 

그런데 2017년에 또 다른 일이 일어났어요. Google이 Google IO 개발자 컨퍼런스에서 모바일 앱용 자체 플랫폼 기술인 Flutter를 알파 버전으로 공개했어요. 올해 컨퍼런스가 있기 바로 이전에 Flutter는 상용화된 앱을 출시할 수 있을 정도로 개발환경의 준비가 완료되었고 9월 말에는 Release Preview 2를 발표한다고 했어요.

 

블로그에서 전체 발표 내용을 읽어보세요! 여기에는 몇 가지 주요 내용이 나와 있어요.

 

1. 마지막 릴리스된 버전의 주제는 완벽한 iOS 앱이에요(이전에는 Android의 Material Design에 초점이 맞추어져 있었어요). 

 

2. App의 패키지 크기가 줄어서, 현재 Release 모드로 제작된 가장 작은 Android App은 크기가 4.7MB에 불과해요.

 

3. 처음부터 오픈 소스로 시작되었던 Flutter는 현재 Github에서 가장 활발한 상위 50개 repo 안에 듭니다.

 

4. Flutter는 Alibaba(Android, iOS), Tencent(Android, iOS), and Google Ads(Android, iOS)와 같은 몇몇 대기업에서 사용하고 있어요. Alibaba가 현재 중국에서 5천만 명이 넘게 사용하고 있는 Xianyu App(Android, iOS)을 구축하기 위해 Flutter를 사용한 방법에 대한 동영상도 있어요.

 

5. 이 차트는 Flutter가 Stack Overflow에서 얼마나 성장하고 있는지 보여줍니다.

 

 

이 발표 내용이 흥미로워서, Flutter가 뭔지 찾아보고 이해하고, 실제 애플리케이션(앱)을 만들어 봤어요. (항상 그렇듯이 문서를 읽는 것만으로는 새로운 것을 느끼기 충분하지 않기 때문이에요).  ASOS에서 매월 마지막 금요일에 열리는 Tech Develops라는 이벤트는 Flutter를 사용해볼 좋은 기회였죠. 이 행사는 1000명 가까이 되는 기술부서 전체가 자유롭게, 원하는 신기술에 대해 탐구하는 날이거든요.

 

이 페이지 상단에서 (Android와 iOS를 위한) 일부 화면을 볼 수 있고 Play 스토어에서 Android 버전을 다운로드 할 수 있어요. 의견을 보내주시면 감사하겠습니다.

 

Flutter란?

1. Flutter는 Google이 개발한 오픈소스 SDK(Software Development Kit; 소프트웨어 개발 키트)로, 코드 대부분을 공통으로 사용하면서 쉽게 iOS와 Android 앱을 만들 수 있습니다. Flutter는 Android와 iOS SDK의 결합으로 동작하기 때문에 iOS 빌드를 위해서는 (React Native와 Xamarin으로 개발할 때와 같이) macOS 장비가 필요합니다. 저 같은 경우 Android 설치는 매우 수월했습니다. — 웹사이트의 가이드를 따라 했고, ‘flutter doctor’ 커맨드를 사용했습니다. 초반에 iOS 설정에서 몇 가지 문제가 있었지만 Laxman Sahni가 쓴 글이 도움이 되었습니다.

 

2. Flutter는 마찬가지로 Google이 개발한 언어인 Dart 언어를 사용합니다. 그래요, 배워야 할 언어가 하나 더 생겼군요. 하지만 걱정 마세요. Java, JS, Kotlin, Swift 또는 C#에 익숙하다면 쉽게 배울 수 있습니다.

 

3. 앱은 React Native처럼 런타임에 컴파일되지 않고, 미리 네이티브 ARM 코드로 컴파일됩니다. 따라서 중간에 코드를 파싱하고 실행할 JS 브리지가 없기 때문에 성능이 더 좋죠. 하지만 런타임에 새로운 JS 코드 번들을 다운로드받아 실시간으로 업데이트할 수는 없어요.

 

4. iOS/Android의 네이티브 UI 컴포넌트를 감싸는 방법(React Native와 Xamarin이 쓰는 방법) 대신에 Skia(Google Chrome, Chrome OS, Android, Mozilla Firefox, Firefox OS 등 많은 제품에서 그래픽 엔진으로 사용하고 있는 라이브러리)라는 빠른 C++ 2D 그래픽 라이브러리를 통해 UI를 ‘화면 canvas’에 직접 그립니다. Skia 프로젝트는 1996년도에 시작되어 2005년도에 Google에 인수되었습니다. BSD 라이센스로 공개되어 누구나 사용할 수 있어요. 이 점이 굉장한 영향을 가지는데, 이에 대해서는 아래 장단점 부분에서 더 얘기하도록 하죠.

 

5. React Native와 유사하게, Flutter 또한 ‘단방향 데이터 흐름’ 또는 반응형 프로그래밍에 기반하고 있어요. 단방향 데이터 흐름에 대해서는 Elizabeth Denhup이 여기에 간단명료하게 설명해줬어요. 간단히 설명하면, 앱은 변수/속성(더 일반적으로 설명하자면, 화면이나 뷰의 ‘상태’)을 변경하여 사용자의 입력에 반응합니다. 그리고 새로운 상태에 따라 UI를 다시 그립니다. 함수는 UI(버튼 색상, 라벨 텍스트, 리스트의 내용 등)를 직접 변경하지 않습니다.

 

6. React Native와 비슷한 점이 또 있는데, Hot reloading을 지원한다는 점입니다. 코드 에디터에서 일부를 변경하고 저장만 하면, Android 에뮬레이터나 iOS 시뮬레이터에서 UI가 갱신됩니다. 한 번 해보면 이전 방식으로 되돌아가기 어려울 정도로 편리하고 빠릅니다. UI를 프로그래밍 방식으로 생성하기 때문에 시각적 에디터가 없는데, 이 기능이 그를 보완합니다.

 

7. Flutter는 third-party 플러그인을 통해 확장 가능해요. 새로운 커스텀 UI를 추가하거나 아직 기본 클래스에서 지원하지 않는 플랫폼에 따라 달라지는 기능(비디오/오디오, 지불/결제, 저장공간, 카메라, 증강현실, 머신 러닝 등)을 감쌀 수 있습니다. 제가 찾은 플러그인 중에 가장 좋은 플러그인 모음입니다. 종류가 많지만, 사용하다 보면 더 많이 필요하게 될지도 모릅니다.

 

8. 이전 특징에 이어서, Flutter는 (.dart 코드에서 표시할 플랫폼별 UI 위젯이나 로직이 다른 경우) Platform.isIOS와 Platform.isAndroid를 확인 후 각각 다른 코드를 실행하거나 (Flutter가 아직 지원하지 않는 플랫폼 특정 기능을 감싸야하는 경우) 직접 플러그인을 작성하여 플랫폼에 따라 달라지는 코드를 비교적 쉽게 작성할 수 있어요.

 

9. 7번과 관련하여, UI는 빠른 저수준 C++ 라이브러리를 통해 그려지고, 다른 기능들은 그 네이티브 영역으로 매핑되기 때문에 앱에서 성능이 문제되지 않아요(적어도 릴리스 모드에서는—디버그 모드에서는 가상 머신을 통해 Dart 코드를 실행하기 때문에 훨씬 느립니다). 하지만 UI를 다시 그리는 횟수를 최소화하고, 변화된 상태에 따라 정말 필요한 부분만 다시 그려야 합니다. 자세한 내용은 Andrea Bizzotto의 글과 Simon Lightfoot의 글을 참고해 주세요.

 

10. 어떤 텍스트 에디터든 사용할 수 있고, flutter 커맨드로 앱을 작성 및 빌드할 수 있는데요. Flutter 플러그인을 지원하는 Android Studio, VS Code, IntelliJ 중 하나를 쓰는 것을 추천합니다. 이 IDE들은 인텔리센스(Intellisense, 소스 코드의 문맥에 맞는 함수나 변수 이름을 추천 목록으로 보여주는 기능), 자동 완성, 몇 가지 디버깅 도구를 제공하며, 앱을 컴파일/실행하는데 커맨드 라인을 쓰지 않아도 됩니다.

 

 

Flutter 갤러리 앱 샘플은 많은 안드로이드와 iOS 의 UI 컴포넌트들을 보여주고 있어요.

네이티브 앱과 비교해서 Flutter로 만든 앱의 성능과 모습을 보려면, 플레이 스토어에서 Flutter 갤러리 앱을 다운로드 하시면 됩니다(소스코드는 Github에서 보실 수 있어요). 또한 공식문서에 있는 위젯 카탈로그 페이지를 참고하셔도 괜찮아요.

 

장점

1. Flutter가 플랫폼별 네이티브 컴포넌트를 아우르는 래퍼라기 보다는 자체 UI를 그린다는 점에서 장단점이 있어요. 장점은 예를 들어 무언가를 iOS 12버전 아이폰에서 렌더링 한다고 할 때, Flutter는 iOS 버전 뿐만 아니라 Android 폰에서도 동일하게 렌더링 해줍니다. 반면에 React Native 또는 Xamarin에서 제공하는 UI 컴포넌트들은 많은 속성이 특정 플랫폼에서만 지원되거나, 모든 플랫폼을 지원한다고 해도 내부적으로 플랫폼에 따라 약간 다른 방식으로 변환됩니다. 이는 여러분이 다양한 장치와 OS 버전을 대상으로 테스트 해야 하는 것을 의미하며 (일부 상황을 해결하기 위해 플랫폼 별 코드를 작성해야 할 수도 있어요), 일부 사용자에게는 화면이 깨져 (또는 조금 다르게)보일 수도 있다는 것을 알고 있어야 하죠. 특정 OS 버전에서 지원되지 않는 속성이나 기능을 사용하면 앱이 다운될 수도 있어요. 특히 플랫폼별 고유 컴포넌트에 대응되는 서드파티 플러그인을 사용한다면, 다양한 장치에서 앱을 체크해야 합니다. 여러분의 앱이 오디오/비디오, 푸쉬 알람 또는 앱 내 결제 등을 사용한다면 이에 해당될 수 있어요. 이러한 방법의 단점에 대해서는 다음 섹션에서 다루겠습니다.

 

2. Hot reloading은 너무 유용하고, 이게 바로 개발자가 꿈꿔왔던 것이에요. 에디터에서 ⌘+S를 누르면 시뮬레이터에서 앱이 바로 다시 로드 됩니다! 빌드/대기/실행/대기/테스트/다시 시작이라는 끝이 없는 프로세스와는 이제 이별이에요. 사실 여전히 자산이나 플러그인을 변경하거나 탐색, 상태 초기화 또는 로직과 관련된 것을 변경한다면 다시 빌드를 해야하지만, 대부분의 UI 변경사항은 앱 실행 중에 바로 반영됩니다. 여러분의 앱에 UI 요소가 많았다면, 대부분 시간을 여기에 할애했을 것이에요. 

 

3. 저는 재사용 가능한 작은 컴포넌트들이 상태의 변화에 따라 반응하는 전반적인 원칙을 좋아하는데요, 이는 리액트와 리액트 네이티브의 핵심 아이디어 중 하나이기도 합니다. 반응형 앱은 순수 iOS 또는 안드로이드 개발을 통해서도 만들 수 있지만, Flutter(그리고 리액트 네이티브)를 이용하면 더 쉽고 자연스럽게 개발할 수 있어요. 서드 파티 라이브러리들을 통해서 다양한 다른 방법으로 구현되는 것이 아니라, Flutter의 핵심 기술이기 때문이죠.

 

4. Dart는 간단하지만 Swift, Kotlin 또는 Java에 필적하는 강력하고 완벽한 언어에요. async/await/Future를 이용한 비동기 프로그래밍은 매우 간편하며, 완벽하고 일관성이 있습니다. 자바스크립트도 그렇다고는 말하기 어렵죠.

 

5. Flutter와 Dart는 기본적으로 로직의 단위 테스트와 UI/상호작용을 위한 위젯 테스트를 모두 지원해요. 예를 들어 탭이나 스크롤을 했을 때, 위젯 트리에서 자식 위젯을 찾고, 텍스트를 읽어서 위젯의 속성 값이 맞는지 검증할 수 있어요. 어떤 것들을 사용할 수 있는지는 공식 문서에서 잘 설명하고 있어요. Devon Carew가 작성한 이 글은 Flutter 플러그인을 사용해서 이 모든 것들을 여러분의 에디터에 통합하는 방법을 설명하고 있어요.

 

6. 기본 기능으로 앱 UI의 모든 부분에 테마를 설정할 수 있다는 점이 아주 좋았어요. 사실 제 앱의 light 모드와 dark 모드를 만들때 가장 어려웠던 점은 사실 올바른 색상을 선택하는 것이었어요(저는 2개만 만들어 봤는데, 같은 방식으로 열 개라도 만들 수 있었을 것 같았어요). 코드 측면에서 보면, 몇 줄이 되지 않아요(루트 MaterialApp 객체의 테마 속성을 설정하는 방법에 대한 전체 예제는 여기를 보시면 돼요).

 

보너스  제가 계속 말하고 있지만 이것은 Flutter뿐 아니라 모든 크로스 플랫폼 기술의 장점이예요. 두 플랫폼을 위한 앱을 동시에 만듦으로써 훨씬 더 쉽게 앱의 기능을 동일하게 유지할 수 있죠. 기존 개발 프로세스를 이용해서도 두 플랫폼을 위한 앱을 동일한 기능으로 동시에 출시할 수 있지만, 얼마 지나지 않아 여러분은 둘 중 하나가 (다운로드, 판매, 광고 수익 등의 측면에서) 더 잘 된다는 것을 느낄 거에요. 그러면 여러분은 떨어지는 쪽에 소모되는 비용을 줄이려고 할 것이고, 이것은 결국 하나만 남게 된다는 것을 뜻하죠.

 

영화 제목에서 따오긴 했지만(이 영화 아직 못 보셨다면 한번 보시길 바래요, 글을 읽으시는 분들과 제가 세대 차이가 나서 이런 영화 별로 안 좋아 하실수도 있겠지만요)

 

단점

저는 (제목과는 달리) 사실 특별히 나쁘다거나 엉터리 같은 부분은 찾을 수 없었어요. 그러나 어떤 특정 관점에서 봤을 때, 그다지 좋지 않은 부분들은 다음과 같습니다.

 

1. 이미 두어 번 언급했듯이, Flutter는 자체적인 커스텀 UI를 지원하기 때문에 기본적인 컴포넌트가 생성되지 않습니다. 이는 Android의 Material Design과 Cupertinolibrary로 만들어지는 iOS별 컴포넌트를 복제하는 데에는 훌륭하지만, 여전히 네이티브하지 않죠. 이건 몇 가지 의미가 있죠, 예를 들어, (A) iOS 13이 세분화된 컨트롤 방식이나 UISwitch의 렌더링 방식을 변경했다면, CupertinoSegmentedControl 또는 CupertinoSwitch를 사용한 당신의 Flutter 앱은 Flutter가 업데이트되고 재빌드되는 동안 업데이트되기 전의 모양을 유지하고 있을 겁니다. 누군가는 많은 사용자들이 신경쓰지 않을 것이라고 주장할 수 있습니다(저의 비기술자 친구들 대부분도 신경 쓰지 않았고 눈치도 못챘죠. 예로, 그들은 OS의 스타일과 느낌이 온전히 100퍼센트 일치하는지 보다는 앱이 충분히 예쁘게 보이는 것에 신경을 쓸 것입니다). 그러나 여러분이 순수주의자라면 용납할 수 없겠죠. (B) 만약 기존 앱의 한 섹션에만 Flutter를 사용하려는 경우 (여기 Flutter의 wiki, Tomek Polański 의 글, Jan Reehuis의 글에서 다루는), 여러분은 네이티브한 부분과 Flutter 부분의 차이점을 볼 수 있을 겁니다. 다시 말해, 이 문제는 당신(또는 당신의 사용자들)에게 문제가 될 수도 있고 또는 그렇지 않을 수도 있다는 말입니다. 물론 새로운 앱이 100% Flutter로 구현되었다면 문제는 훨씬 덜하겠지요. (C) 개발자로서 가능한 쉽게 개발하기 위해서, 여러분은 그냥 (Material Design 컴포넌트를 사용하는)MaterialApp을 사용할 수 있고 Android와 iOS로 컴파일 하면 됩니다. 네이티브한 스타일이 아님에도 불구하고, 그건 잘 될 것이고, 사실 그것이 제가 앱을 만들면서 한 일입니다. 대신, 여러분이 이것에 신경을 쓰면서 Android용 MaterialApp과 iOS용 CupertinoApp을 사용하기로 결정한다면, 여러분은 여러분의 (당신의 앱에 상당 부분이 될 수도 있는) UI에 대한 모든 코드는 아니더라도 대부분의 것들을 중복해서 작업해야 할 것이고 그것은 설계를 더 복잡하게 만들게 할 것입니다. 그럴 만한 가치가 있는지 신중히 생각하고 결정하기 바랍니다.

 

2. 여기 Github에 괜찮은 UI 컴포넌트와 여러 plugin의 목록이 있습니다. 그러나 React Native나 심지어 Xamarin의 플러그인만큼 풍부하지는 않지요. 그것은 아마도 Flutter가 훨씬 더 새롭고 작은 공동체이기 때문일 것 입니다. 그러나 그것은 현재의 상황이죠. 선택할 수 있는 것은 제한되어 있고, 플러그인 다수가 오래 되었고, 유지보수되지 않았기 때문에 아마도 현재의 Dart/Flutter 버전에서는 더이상 작동되지 않을 것입니다. 일부 컴포넌트들은 (특히 UI가 아닌 플랫폼별 기능들) iOS나 Android 중 하나에서만 사용할 수 있으며 두 곳에서 모두 사용할 수 없습니다. (일반적으로 Android를 지원하고 있습니다. 왜냐하면 Android 개발자들이 iOS개발자들보다 Flutter에 더 많이 참여했고 또한 Flutter는 Google에서 나왔기 때문이죠.) 그러나 그러한 격차를 줄이고 누락된 플랫폼을 위한 플랫폼별 코드를 작성한다면 아무것도 없이 시작하는 것보다 나을 것입니다. 또한 Flutter가 계속해서 인기를 끌면 확실히 상황이 개선될 거예요.

 

3. 디버깅하기가 그리 편하지 않습니다. print/debugPrint문을 사용하여 로그를 보고, 툴을 이용해 CPU/memory를 프로파일링하거나 view hierarchy를 시각화할 수 있습니다. 하지만 Xcode 나 Android Studio에서 기본 SDK로 작업하는 것과 비교하면 하늘과 땅 차이입니다. (디버깅 방법들에 대한 자세한 정보는 공식 문서를 참고하세요 ) 정정 많은 사람들이 이러한 견해는 정확하지 않으며, 얼마든지 Java/Kotlin Android 처럼 breakpoint를 사용하고, 코드를 따라가며, variable value를 검사할 수 있다고 제보했습니다. 이는 Android Studio와 VSCode 모두에 적용됩니다. 좋은 소식이네요.

 

4. 화면 레이아웃에 (또는 더 저수준의 어떤 곳에) 오류가 있을 때 나오는 에러 화면이나 로그가 혼란스럽고 기묘해 보일 수도 있어요. 그건 개발자가 직접 접하는 수준보다 훨씬 저수준의 프레임워크에 있는 코드를 가리키거든요. iOS 와 Android native 에서 에러는 보통 이해하기 쉽게 명확합니다. 만약 그렇지 않다 하더라도, 보통의 경우는 개발자가 에러의 내용을 구글에서 검색하여 해결책을 쉽게 찾을 수 있습니다. Flutter 의 경우, 아직은 상대적으로 커뮤니티가 작기 때문에 쉽게 구글링을 통해 해결책을 찾을 수 없습니다.

 

5. UI를 .dart 파일 안에서 직접 만드는 방식이 쉽고 직관적이긴 합니다. 달리 생각해 보면, UI와 코드가 제대로 분리되어 있지 않은 거죠. 저는 UI를 마크업 코드로 따로 만드는 방식을 선호합니다(Native Android 앱에서 볼 수 있는).

 

6. 안드로이드 개발환경에서는 대다수의 개발자들은 Clean Architecture 와 MVP 패턴으로 개발을 합니다. iOS 에서는 MVC나 MVVM 또는 Viper가 될 수 있습니다. 두 가지 방법 모두 이미 규모가 큰 앱에서 잘 사용되고 있어 검증된, 깔끔하고 잘 알려진 아키텍처 패턴입니다. 하지만 Flutter(React Native 도 마찬가지)에선 아직까지 ‘표준’이라거나 ‘거의 모두가 인정하는’ 널리 사용하는 아키텍처가 없고, 아직 정의되어 가는 단계로 느껴집니다. 현재 올라온 예제들은 모두 단순한데요, 아직 대다수의 개발자들이 입문 단계이기 때문에 심화된 로직을 보기 이전에 간단한 소스로 익숙해져야 하는 단계이기 때문입니다. 하지만 Flutter를 다소 규모가 큰 프로젝트에 사용하려면, 구조화에 대한 명확한 아이디어가 있어야 합니다. 즉, 애플리케이션의 크기와 복잡성이 증가함에 맞춰 스케일링하고 쉽게 관리할 수 있어야 합니다. 저는 본격적으로 계획을 세우기 전에 Brian Eganto의 비디오(layer계층을 코딩하고 테스트 하는 방법에 대한 내용)를 먼저 시청해 보는것과 Github의 샘플 소스를 살펴보는 것을 강하게 추천드립니다. 또한 Didier Boelens가 쓴 article about Streams and RxDart 그리고 posts about Redux와 overall architectural review와 같은 다른 아티클도 살펴보는 것을 추천하겠습니다. 다시 한번 말씀드리지만 저는 Flutter가 당신의 앱을 명확하고 유지보수성이 좋은 아키텍처 구조로 개발하지 못한다고 단정짓지는 않았습니다. 다만 Flutter를 이용하기 위해서는 아직도 에러를 잡고 개발하는 노력을 더 들여야 한다는 것을 말했습니다. 우리에게 익숙한 iOS/Android native 언어처럼 Flutter가 아직은 성숙하지도, 넓은 분야에서 사용되지도 않기 때문입니다. 

 

결론

React Native에 대해 작년에 쓴 글의 대부분을 복사해서 붙여넣기 할 수도 있지만 대신 해당 글의 링크를 남깁니다. 요약하자면, Flutter는 잠재력이 크다는 겁니다. 시작하기 쉬울 뿐만 아니라 실제 무언가를 만들어 보기에도 쉽습니다. 좋은 규칙과 아이디어도 많이 있고요. 하지만 커뮤니티가 아직 작고 크로스 플랫폼을 지원하는 플러그인들이 많지 않습니다. 그나마 가장 좋은 경우여도 선택지가 다양하지는 않죠. 또, 네이티브 UI와 100% 똑같은 UI를 구현할 수 없다는 점도 고려해야 합니다. iOS와 Android의 네이티브 UI와 최대한 비슷하게 만들려면 코드와 구조가 훨씬 복잡해진다는 점도 말이죠.

 

개인적으로는 Flutter가 아래 몇몇 상황에서 (이미 사용 가능한) 매우 유용한 기술이라고 생각합니다.

 

1. 가능한 한 빨리 많은 사용자를 확보하고자 할 때 — 이제 처음부터 시작하는 스타트업이 iOS와 Android 플랫폼에 애플리케이션을 릴리스하려고 한다고 가정해보겠습니다. 어떤 플랫폼에서 좀 더 반응이 좋은지 보고, 투자를 더 한다거나 좀 더 공을 들이려고 말이죠. 이런 상황에서 Flutter로 만든 애플리케이션을 고도로 발전시킨 프로토타입으로 활용할 수 있을 겁니다. 이후에도 Flutter로 작업하면서 발전시켜 나갈 수도 있고, 혹은 전담팀을 만들어서 네이티브 애플리케이션으로 대체시킬 수도 있겠죠.

 

2. UI가 별로 중요하지 않을 때 — 예컨대, OS 내의 다른 요소들과 일관성 있는 UI를 보여주는 것보다 직원들이나 고객들이 모든 장비에서 사용 가능한 것이 더 중요한 영업용 애플리케이션 같은 기업용/B2B 애플리케이션의 경우가 이에 해당합니다. 그루폰이 셀러용 애플리케이션을 만들 때 사용했던 방법입니다. (최종 사용자용은 아니었지만요)

 

결론적으로 처음으로 Flutter를 활용해서 애플리케이션을 만들어 본 경험은 대부분 즐거웠다고 말할 수 있을 것 같습니다. iOS와 Android 네이티브 애플리케이션을 몇 번 만들어 보기는 했지만, 각 플랫폼용 네이티브 앱을 각각 만드는 것보다 Flutter로 만드는 것이 확실히 더 빠르기도 했습니다. (비록 Flutter에 대해 아무것도 모르고 시작했지만요) 이정도면 나쁘지 않은 것 같군요!

 

 

저는 이런 사람입니다. 저는 ASOS.com(iOS app / Android app)의 모바일 팀에서 솔루션 아키텍트로 일하고 있습니다. 저희 팀은 항상 온라인 쇼핑 경험에 변화를 일으키고 싶어하며, 사교적이고 재능 있는 개발자분들을 찾고 있습니다. ASOS는 영국에서 가장 큰 온라인 쇼핑몰이고, 솔직히 얘기하자면, 세계 최고의 패션 테크 회사입니다. iOS는 Swift로, Android는 Kotlin으로 개발하고 있고, 웹 프론트 개발에는 React와 Node를, 백엔드 개발에는 .NET과 Azure를 사용하고 있습니다. Flutter(그전에 사용한 React Native도)는 제가 개인적으로 사용해 본 것뿐이에요. 만약 저희 팀 소개에 관심이 가고 혹시나 아름다운 런던에 살고 계시다면 (이사를 오실 생각이 있다거나요 —유럽에서 최고의 도시잖아요, 이탈리아의 몇몇 도시를 제외한다면요) 연락주세요!

 

🖋 원문 출처: https://medium.com/asos-techblog/flutter-vs-react-native-for-ios-android-app-development-c41b4e038db9

🖋 원문 저자: Marco Bellinaso

Marco Bellinaso – Medium

🖋 기술 번역: 이상한 모임 번역팀