시작하기 전에

안녕하세요. LINE Biz+ Pay App Dev 팀에서 앱 클라이언트의 iOS 버전을 개발하고 있는 박혁준입니다. 저는 얼마 전 열렸던 LINE Developers Meetup에서 제가 발표했던 내용을 공유하려고 합니다. Flutter를 새로운 프로젝트에 사용해 보려고 조사했던 내용과 적용하려고 했던 이유, 그리고 적용하지 못했던 이유까지 한 번 짚어보겠습니다. 특히 Flutter에 대해 잘 모르거나 적용해 보면 어떨까 고민했던 분들에게 도움이 되었으면 좋겠습니다.

Flutter란?

Flutter는 Google에서 개발한 크로스 플랫폼 모바일 앱 개발 프레임워크입니다. ‘크로스 플랫폼’, ‘사용자 경험’, ‘개발 환경’, ‘Google’, 이 4가지 키워드로 Flutter를 설명하겠습니다.

먼저 크로스 플랫폼 기술은 하나의 코드를 여러 플랫폼에서 사용할 수 있게 해주는 기술을 말합니다. 모바일에선 보통 Android와 iOS 환경 모두에서 사용할 수 있게 해주는 것입니다. 이렇게 되었을 때 가장 매력적인 점은, 개발할 때와 유지 보수할 때 플랫폼 별로 따로 대응할 필요가 없어 비용이 크게 절감된다는 점입니다. 단순하게 계산하면 Android와 iOS용 앱을 코드 하나로 개발한다면 비용이 1/2, 여기에 웹까지 대응하다면 1/3로 줄어듭니다. 물론 실제로 정확하게 이 정도의 효과가 나오진 않겠지만, 그래도 공수를 상당히 줄일 수 있다는 점은 큰 장점입니다.

다음으로 사용자 경험 측면입니다. 우선 디자인을 꼽을 수 있습니다. Flutter는 기존에 존재하는 Android와 iOS의 위젯을 사용하지 않고, 자체 Skia 엔진을 이용해 UI를 ‘그리는’ 방식을 사용합니다. 그래서 iOS에서 Material 디자인을, Android에서 Cupertino 디자인을 쉽게 구현할 수 있는데요. Google이 제공하는 위젯을 통해 이것이 가능합니다. Flutter에는 Google이 직접 제공하는 위젯과 사용자들이 개발한 많은 위젯이 있어서 자신이 원하는 디자인을 만드는 데 결코 부족하지 않습니다. 또한 사용자 경험에 중요한 영향을 끼치는 성능이나 속도도 네이티브 환경에서 만든 애플리케이션과 비교했을 때 뒤처지지 않는다고 이야기합니다.

다음으로 개발 환경 측면에서 살펴보겠습니다. 먼저, Visual Studio code, Android Studio 등에서 개발이 가능합니다. 코드를 오픈소스로 제공하고 있어서 개발자가 내부 코드를 찾아보고 참고하면서 개발할 수 있습니다. 또한 개발한 코드를 수정과 동시에 적용하여 살펴볼 수 있는 Hot Reload 시스템도 적용되어 있습니다. 특별하게 뛰어난 점이 있다고 말하기는 어렵겠지만, React Native의 장점을 많이 갖고 있다고 말할 수 있습니다.

마지막으로 짚고 넘어가고 싶은 점은 Flutter를 개발한 주체가 바로 Google이라는 점입니다. Google은 전 세계적으로 손꼽히는 큰 기업인데요. 특히 모바일 분야에선 모바일 시장의 한 축을 담당하는 OS, Android 플랫폼을 가지고 있는 기업입니다. 모바일 분야에서 Android OS에 익숙해진 사용자는 다른 OS가 탑재된 스마트폰은 사용하기 어렵고, 그런 고객들이 많이 존재하기 때문에 전 세계의 많은 업체들이 직,간접적으로 Google의 지배를 받을 수 밖에 없습니다. Flutter는 Google에서 만들었기 때문에, 개발자 입장에서는 Flutter로 앱을 만들면 적어도 많은 사용자가 이용하는 Android에선 잘 실행될 것이라는 확신을 가질 수 있고, 또 Google이 밀어주는 한 Flutter는 절대로 사라지지 않겠다고 생각할 수도 있습니다. 만약 똑같은 걸 Google이 아닌 다른 곳에서 만들었다면 이렇게 화제가 되거나 많은 사람들이 사용하지 않았을 수도 있습니다. Google이 만들었기 때문에 더 많은 사람이 주목하고 있고, 또 실제로 그 점이 우리가 더 관심을 가져야 하는 이유가 된다고 생각합니다.

LINE Pay 앱 프로젝트 진행

간단하게 Flutter를 살펴 보았으니 이제 Flutter를 적용하려고 했던 LINE Pay 앱 프로젝트에 대해서도 살펴보겠습니다. LINE에서 Pay 서비스를 지원한 지 벌써 수년이 지났고, 일본과 대만, 태국 등에서는 좋은 성과를 내기도 했습니다. 하지만 아무래도 LINE이라는 큰 프로젝트에 종속되어 있었기 때문에 사용성 면에서 한계가 있었던 것도 사실인데요. 이런 이유로 LINE Pay 기능을 제공하는 앱을 별도로 만드는 프로젝트가 시작됐고 현재 일본에서는 이 앱이 출시되어 사용할 수 있습니다. 저희 팀은 이 프로젝트에서 클라이언트 개발을 맡게 되었는데요. 어떻게 만들지 회의하는 과정에서 크로스 플랫폼에 대한 이야기가 나왔습니다. 완전히 새롭게 시작하는 프로젝트인 만큼 새로운 기술을 적용하고 싶은 욕심과 도전 의식이 있었고, 개발하고 유지 보수하는 비용도 획기적으로 줄일 수 있지 않겠냐는 기대도 있었습니다. 그래서 크로스 플랫폼을 한 번 시도해 보기로 했는데요. 시도하기 전에 여러 크로스 플랫폼 중에서 어떤 걸로 개발을 진행할 지 결정해야 했습니다. 유명한 크로스 플랫폼으로 Xamarin, React Native, Flutter를 꼽을 수 있는데요. 결정하기 위해 이 3가지를 비교해 보았습니다. 아래는 React Native와 Flutter의 구조를 간략하게 표현한 그림입니다.

각 크로스 플랫폼은 여러 측면에서 장점과 단점이 있었는데요. 그중에서 Flutter로 결정한 이유를 간단하게 말씀드리자면 성능과 UI 개발 편의성, 그리고 트렌드 측면에서 강점을 보였기 때문이라고 말할 수 있습니다. 위 그림을 보면 Flutter는 React Native와는 달리 중간에 bridge가 없습니다. 바로 캔버스에 그림을 그리듯이 표현하고, 네이티브 위젯을 사용하지 않습니다. 그래서 속도가 빠른 편인데요. 이것이 큰 장점 중 하나로 꼽힙니다. 또한, Xamarin은 UI 개발 편의성이 좋지 않다는 점이 약점으로 꼽히는데요. 그에 비해 Flutter는 UI 개발이 간편하고 자유롭다는 평이 많았습니다. 마지막으로 저희가 프로젝트에 착수할 즈음에 Flutter가 정식으로 출시되어서 많은 관심을 받고 있었던 터라 이 트렌드를 따라가도 괜찮겠다는 생각이 들어서 Flutter로 결정하게 되었습니다. 아래는 1년간 Google Trend의 변화인데요. Flutter가 뚜렷한 상승세를 보이는 걸 확인할 수 있습니다.

왜 적용하지 못했는가?

결론부터 말씀드리자면 저희는 Flutter를 적용하는 개발 과정에서 많은 어려움을 겪었고, 결국 iOS와 Android 네이티브 개발을 각각 진행하는 방식으로 돌아왔습니다. 왜 그래야 했는지 설명하겠습니다.

이 프로젝트의 핵심 기능은 QR 코드를 이용한 간편한 결제와 쉽게 쿠폰을 받아서 사용할 수 있는 시스템, 근처 가맹점 찾기, 그리고 이 모든 기능을 사용자가 간단한 제스처로 사용할 수 있는 것이었습니다. 이를 위해 카메라 기능과 확실하고 깔끔한 제스처 처리, 웹 뷰 처리, 그리고 자바스크립트 통신이 필요했습니다. 이런 기능들을 개발 프로토 타이핑할 때 겪었던 어려움을 예로 들어 Flutter를 적용하지 못했던 이유를 설명하겠습니다. 아래는 실제 앱 스토어에서 LINE Pay 앱 가이드 화면인데요. 간편한 결제, 쿠폰, 근처 가맹점 찾기 기능을 강조하고 있다는 걸 확인할 수 있습니다.

먼저 플러그인 관련 문제입니다. 아주 당연한 이야기지만 Flutter는 만들어진 지 얼마 되지 않았기 때문에 이를 지원해주는 플러그인도 아직 높은 수준에 도달하지 못한 상태였습니다. 앞서 말한 카메라나 웹 뷰를 사용하기 위해선 플러그인이 필수였는데요. 현재 Flutter 공식 플러그인의 버전은 둘 다 1.0을 넘지 못했습니다. 사실상 알파나 베타 단계라는 뜻입니다. 실제로 커스터마이징해서 기능을 만들려고 했을 때, 제공하는 함수나 변수 등의 자유도가 낮아서 어려움이 많았습니다. 플러그인에서 제공하지 않는 기능이 필요하다면 저희가 직접 개발해야 합니다. 그래서 플러그인을 직접 수정하면서 개발해 보았는데요. 이 과정에서 각 플랫폼별로 그에 맞는 코드가 들어가야 해서 플랫폼 의존성이 생각보다 높아졌습니다. 만약 이런 코드가 계속 늘어나고 각각의 유지 보수를 따로 해야 한다면 크로스 플랫폼을 사용하는 의미가 퇴색된다고 생각했습니다. 플러그인이 아닌 프로그램의 기본적인 구현에서도 로직이 Flutter와 네이티브 쪽으로 나뉘어 버리기 십상이었습니다. 또한 플랫폼 별로 따로 뷰를 만들어서 사용하려면 특정한 Flutter 뷰를 사용해서 호출해야 하는데요. 공식 문서에 그런 식으로 사용할 경우 성능상 문제가 발생할 수 있으니 쓰지 않는 편이 좋다고 적혀 있기도 했습니다.¹ 이렇게 성능상 문제가 발생할 수 있다면 아무래도 사용하기 힘들겠다는 생각이 들었습니다.

개발에 필요한 정보도 부족했습니다. 특히 제스처 처리를 구현할 때 Flutter가 기본적으로 제스처를 어떻게 처리하는 지, 혹은 네이티브 뷰의 제스처 인식과는 어떻게 구별되는 지 등에 대한 정보가 굉장히 부족했습니다. Gesture Arena, Gesture Recognizer Factory와 같은 이름과 코드는 찾았으나, 이를 어떻게 사용해야 잘 사용하는 것인지에 대한 정보를 찾기는 쉽지 않았습니다. 예를 들어 Flutter에서 제공하는 제스처 정보는 보통 네이티브에서 제공해 주는 가공되지 않은 제스처 정보가 아니라 조금 가공된 형태의 제스처 정보였는데요. 이로 인해 정해져 있지 않은 제스처를 처리할 때 어려움을 겪었습니다. 앞으로 또 이러한 문제에 부딪쳤을 때 물어볼 만한 사람도 없고, 정보를 찾기도 쉽지 않다면, 개발 과정에서 많은 어려움을 겪게 될 것 같다는 걱정이 들었습니다.

지금까지 살펴본 내용을 간단히 정리하면 결국은 Flutter를 사용할 때 얻을 수 있는 장점과 감당해야 할 리스크를 계산하는데 문제가 있었다고 요약할 수 있습니다. 처음엔 새로운 기술을 적용해 볼 수 있고 개발과 운영에 필요한 시간과 공수를 줄일 수 있다는 장점이, Flutter 학습 시간이 어느 정도 필요하다는 리스크보다 클 거라고 생각했습니다. 하지만 검토 결과 학습하는데 필요한 시간이 예상을 뛰어넘는 수준이었습니다. 또한 플러그인을 보완하기 위해서도 시간이 필요하고, 플랫폼 의존도가 높아질 수도 있다는 예상치 못했던 리스크도 발견되었습니다. 결국 이런 리스크를 감당하기 어렵다고 판단했기 때문에 Flutter를 포기하게 되었습니다.

Flutter를 쓰기 위해선 어떻게?

지금까지 주로 Flutter의 단점에 대해 이야기했는데요. 그렇지만 만약 저에게 Flutter는 영 못 쓸 도구냐고 묻는다면 아니라고 대답할 겁니다. 도구는 결국 도구일 뿐입니다. 어떻게 사용하냐에 따라 결과는 천차만별입니다. 저희는 Flutter라는 도구를 잘 모르고 시작했기 때문에 실수가 많았고, 그래서 제대로 사용하지 못한 것이라고 생각합니다.

그럼 어떻게 사용했어야 하는가를 생각해 보았는데요. 가장 중요한 것은 좀 더 확실하고 철저한 프로토타이핑, 그리고 UX 측면을 더 고려하는 것이라고 생각합니다. 저희가 프로젝트를 시작하고 Flutter에 대해 알아볼 때 이미 기획과 UX 측면은 많이 결정된 상태였습니다. 즉 Flutter에 대해 잘 알지 못하고 프로토타이핑도 되어 있지 않은 상태에서 이미 결정된 사안을 확인해 본 셈입니다. 그래서 저희가 잘못 대처한 부분이 많았습니다. 예를 들어 Flutter에서 어떤 기능이 혹시라도 처리되지 않는다면, 개발 팀에서는 그에 대한 어떤 대안을 내놓으면 괜찮을 거라고 생각했습니다. 하지만 기획 팀에서는 이미 대안으로 대체할 수 없는, 확실히 결정한 컨셉이 있었고, 저희는 그 컨셉을 개발할 수 있을 지에 대한 확신이 없었습니다. 프로토타이핑으로 잡아둔 시간이 짧았고, Flutter를 제대로 알지 못했기 때문에 이건 개발 가능하고 저건 불가능하다는 이야기를 하기가 어려웠던 거죠. 만약 저희가 좀 더 일찍 알아보고 확실하게 준비하여 처음부터 이야기를 잘 풀어나갔다면 가능했을지도 모를 일입니다. 

Flutter에 대해 찾아보면 대부분 좋은 얘기만 쓰여 있습니다. 하지만 당연하게도 만능 도구는 없습니다. 각 상황별로 그에 맞는 도구가 따로 있고, Flutter도 그렇습니다. 확실하게 프로토타이핑해서 요구 사항을 명확히 만족시킬 수 있다는 확신이 들었다면 충분히 좋은 도구가 될 수 있다고 생각합니다.

Flutter의 미래와 결론

Flutter는 지금도 계속해서 발전하고 있습니다. Dart언어는 2018년에 codementor에서 최악의 프로그래밍 언어로 꼽혔는데요. 그 오명을 2019년에는 떨쳐냈습니다. 아래는 codementor에서 선정한 2018년도와 2019년도, 학습하는 관점에서 최악인 프로그래밍 언어의 순위입니다. Dart의 순위가 2018년엔 1위였지만 2019년엔 14위까지 떨어진 것을 볼 수 있습니다.

Google에서는 모바일을 넘어 데스크톱 앱, 웹, 임베디드 시스템에까지 Flutter를 적용하겠다는 포부를 밝혔습니다. 또한 그동안 부족했던 웹, Google Map, Firebase ML Vision, 앱 내 구입을 위한 패키지를 제공하겠다고 밝히기도 했습니다.

물론 Flutter만 변화하는 것은 아닙니다. Apple은 새로운 iOS 버전에 맞게 완전히 새로운 개발 환경을 출시하겠다고 예고했고, Android도 Jetpack으로 대표되는 새로운 변화를 계속해서 선보이고 있습니다. 이렇게 많은 것들이 끊임없이 변화하기 때문에 플랫폼 시장에서는 어떤 기업이, 혹은 어떤 프레임워크가 최종 승자가 될지 아무도 알 수 없습니다. 다만 확실한 건 역사적으로 변화가 많은 때가 곧 기회가 많은 때였다는 것입니다. 항상 준비하고 있어야 뒤처지지 않습니다.

저희는 LINE Pay 앱 프로젝트를 진행하면서 Flutter라는 새로운 기술을 선택하지 못했습니다. 하지만 오히려 그렇기 때문에 더욱, 여러분이 저희보다 더 많은 준비를 해서 도전하고 성공했으면 좋겠다고 생각합니다. LINE에서는 Flutter를 비롯한 여러 새로운 기술에 주목하고 있는데요. 얼마 전에는 LINE Login SDK 팀에서 iOS나 Android SDK가 아닌 Flutter를 위한 플러그인을 개발해서 선보이기도 했습니다. LINE에서는 저희가 그러했듯, 늘 새로운 도전을 시도할 수 있습니다. 저희 역시 기회가 된다면 다시 도전할 생각이며, 한 번 더 기회가 된다면 그때는 꼭 ‘성공담’이라는 이름으로 발표하고 싶습니다. 긴 글 읽어주셔서 감사합니다.

---

1. Embedding iOS views is an expensive operation and should be avoided when a Flutter equivalent is possible - https://api.flutter.dev/flutter/widgets/UiKitView-class.html
   Embedding Android views is an expensive operation and should be avoided when a Flutter equivalent is possible - https://api.flutter.dev/flutter/widgets/AndroidView-class.html