Flutter 프레임워크와 네이티브 안드로이드 앱 개발의 비교 분석

현재 모바일 시장은 안드로이드와 iOS로 양분되어 있고, 두 플랫폼은 생태계와 사용자 기반의 특성이 다르다. 이에 따라 최근에는 하나의 플랫폼이 아닌 다중 플랫폼을 대상으로 하는 Flutter의 등장으로 전통적인 방식으로 안드로이드 플랫폼에 최적화된 앱을 개발하는 방법과 다중 플랫폼을 지원하는 방법 간의 기술을 분석하고 비교함으로써 개발자들이 어떤 기술을 선택할지에 대한 결정에 도움을 주려고 한다.



글/ 고려대학교 주병권 교수님 연구실

주병권 (고려대학교 전기전자공학부 교수)
정성욱 (고려대학교 전기전자컴퓨터공학부 석사 과정)
 

목 차

1. 서론
2. Flutter 프레임워크란?
   2-1. Flutter의 개요와 특징
   2-2. Flutter의 아키텍처와 작동 원리
   2-3. Flutter의 장점 및 한계
3. 네이티브 안드로이드 앱 개발
   3-1. 안드로이드 앱 개발의 개요와 특징
   3-2. 안드로이드 네이티브 장점 및 한계
   3-3. 안드로이드 네이티브 개발의 변화
4. 비교분석
   4-1. 개발속도
   4-2. 소스코드 크기
   4-3. 성능
5. 결론
6. 참고 문헌


1. 서론 

스마트폰 산업이 발전함에 따라 앱 개발은 점차 중요한 기술로 자리잡고 있으며, 사용자들이 원하는 다양한 요구를 충족하기 위해서 다양한 개발 기술과 프레임워크가 등장하고 있다. 현재 모바일 시장은 안드로이드와 iOS로 양분되어 있고, 두 플랫폼은 생태계와 사용자 기반의 특성이 다르다.

이에 따라 최근에는 하나의 플랫폼이 아닌 다중 플랫폼을 대상으로 하는 Flutter의 등장으로 전통적인 방식으로 안드로이드 플랫폼에 최적화된 앱을 개발하는 방법과 다중 플랫폼을 지원하는 방법 간의 기술을 분석하고 비교함으로써 개발자들이 어떤 기술을 선택할지에 대한 결정에 도움을 주려고 한다.

2. Flutter 프레임워크란? 

Flutter는 Google에서 지원하는 오픈 소스 프레임워크로써 다중 플랫폼을 단일 코드 베이스로 구축하게 되며 iOS, Android, Web, Windows, MacOS, Linux의 여섯 가지 플랫폼에 대한 애플리케이션 개발을 지원한다. 또한, 다중 플랫폼 개발 프레임워크이면서도 네이티브에 가까운 성능을 보여주는 장점을 가지고 있다.

2-1. Flutter의 개요와 특징

다중 플랫폼을 지원한다는 특징 외에도 Flutter는 많은 특징을 가지고 있다. 첫 번째로 Google은 생산성 향상에 초점을 둔 기능을 내세우고 있는데, 네이티브 방식의 개발과 다르게 개발 중인 앱이 디바이스 혹은 에뮬레이터에서 실행 중일 때에도 코드를 수정하고 저장하면 바로 수정 내용이 반영되는 Hot Reload 기능을 가지고 있다. 이로써 UI 구성에 소모되는 시간을 대폭 줄일 수 있어 생산성 향상에 좋은 영향을 주는 특징을 가지고 있다.

두 번째로는 UI 렌더링을 Skia라는 오픈 소스 그래픽 라이브러리를 이용하여 진행하기 때문에 네이티브 컴포넌트를 사용하지 않게 되어 플랫폼에 관계없이 비슷한 화면을 구성할 수 있는 장점이 있다. 마지막으로 렌더링이 bridge를 통해 OEM Widgets을 거치지 않고, Canvas에 직접 렌더링을 한다는 특징이 있다. 거기에 실제로 업데이트가 필요한 Widget(View)들만 업데이트 하도록 내부적 트리 구조를 가지고 있어 높은 성능을 보여준다.

2-2. Flutter의 아키텍처와 작동 원리

Flutter는 다중 플랫폼을 지원하기 위해 애플리케이션이 직접 플랫폼 서비스와 인터페이스 할 수 있도록 설계되어 있다. 그렇기 때문에 Flutter의 아키텍처와 작동 원리는 애플리케이션의 성능에 중요한 영향을 미치게 되어있다. 아키텍처는 크게 Framework, Engine, Platform Embedder 레이어로 나눌 수 있다. 이 아키텍처가 어떻게 구성되어 있는지 모바일 애플리케이션을 기준으로 알아보려고 한다.
 

그림 1에서 나타내듯이 Framework 레이어에서는 실제 개발자가 사용하는 상위 기능들을 다루고 있다. 구글에서 제공하는 안드로이드 기본 디자인 가이드인 Material Design과 애플에서 제공하는 아이폰 기본 디자인 가이드인 Cupertino Design의 기능을 제공하고 있으며, Flutter에서 제공하는 Widget(Flutter Platform Widget) 패키지를 이용해 프로그래밍하여 하나의 코드 베이스로 두 플랫폼을 모두 지원할 수 있게 된다.

이렇게 개발된 소스는 Rendering 과정에서 Bridge를 통하지 않고 네이티브 코드로 컴파일 되어 앱의 성능도 향상시킬 수 있다. 그리고 사용자의 경험을 향상시키기 위해 Animation, Painting, Gestures를 지원하고, 이들을 지원하기 위한 기초 클래스를 Foundation에서 제공한다.

Engine 레이어는 Flutter의 핵심 레이어 역할을 다양하게 수행하여 렌더링 및 실행을 다루고 있다. 그래픽 엔진인 Skia를 기반으로 애플리케이션의 UI를 그려내어 다중 플랫폼에서 동일한 그래픽을 렌더링할 수 있게 지원하고, 입출력(I/O) 기능을 이용하여 파일 및 디렉토리에 접근하여 작업을 진행할 수 있게 하며, Shared Preferences를 통하여 앱의 상태를 유지하기 위한 간단한 데이터를 저장할 수 있도록 지원한다. 그리고 네트워킹 기능을 통하여 소켓 통신이나 Http 요청을 지원하고, Dart 가상 머신(Virtual Machine, VM)으로 Dart 코드를 기계어로 변환하여 실행하도록 지원한다. 

Embedder 레이어는 각각의 플랫폼에서 구동될 수 있도록 운영체제와의 연계를 위한 플랫폼의 Entry Point를 제공한다.  즉, 이 레이어는 Flutter 엔진을 기존의 네이티브 애플리케이션에 통합하고, 네이티브 플랫폼과의 상호 작용을 가능하게 하는 역할을 수행하게 된다. 여기서 MacOS, Android, Windows, Linux Embedder가 제공된다.

2-3. Flutter의 장점 및 한계

같은 기능을 하는 모바일 앱을 개발하는 입장에서 Android와 iOS로 모바일 시장이 양분되고 있어 서로 다른 플랫폼에 맞는 네이티브 앱을 동시에 출시해야 한다는 부담이 있다. 당시에도 Web App이나 크로스 플랫폼 프레임워크는 있었지만 네이티브 앱을 완전히 대체하기엔 여러가지 문제점이 있었다. 이때 Flutter 프레임워크의 등장으로 모바일 개발의 새로운 패러다임이 자리잡게 되었다.

Flutter는 개발 언어로 Dart를 채용함으로 JAVA, C#과 같은 컴파일 언어가 가진 특징을 활용해 기존의 네이티브 앱 개발자들에게 친숙한 개발 환경을 제공하였다. 그리고 크로스 플랫폼의 가장 큰 장점인 하나의 코드 베이스로 Android와 iOS앱을 개발할 수 있기 때문에 개발의 시간과 비용을 절약할 수 있고, 생산형을 향상시키는 장점을 가지고 있다. 그리고 활발한 커뮤니티와 다양한 라이브러리를 제공하여 커스터마이징이 용이하고 네이티브를 대체할 수 있는 패키지나 라이브러리를 제공한다.



그림 2의 사이트는 Google에서 제공하는 Dart, Flutter 패키지 라이브러리 사이트이다. 이 곳에서 개발자는 목적에 맞는 패키지나 라이브러리를 검색하여 제공받을 수 있기 때문에 앞으로는 Flutter가 네이티브 앱을 완전히 대체하는 수준까지 성장할 수 있는 가능성이 있다고 생각이 된다.

하지만 아직까지는 그 한계가 분명히 존재하고 보완되어야 할 부분도 있다. 일단 Flutter는 Plugin을 통해 네이티브의 기능을 사용할 수는 있지만, 모든 네이티브 기능을 지원하는 것은 아니다. 즉, 필요한 기능을 구현하기 위해 네이티브 개발자가 직접 Plugin을 개발해야 하는 상황이 발생할 수도 있다. 그렇기 때문에 기존의 네이티브 개발 지식을 완전히 대체하기는 아직은 무리라고 볼 수 있다.

그리고 많이 개선되었다고는 하지만 아직까지 네이티브 앱에 비해 성능이 떨어지는 부분이 있고, 복잡하거나 고성능을 요구하는 앱일수록 이 문제는 더 부각될 수밖에 없다. 마지막으로 Flutter로 개발된 앱은 Flutter Engine이 포함되어 있기 때문에 앱의 용량 크기가 커지는 문제가 있다.

3. 네이티브 안드로이드 앱 개발

Android Studio를 이용하여 Kotlin 혹은 JAVA 언어를 이용하여 Android 플랫폼에 특화된 앱을 개발하는 방식이다. 현재 안드로이드 개발자에게 가장 친숙한 방식이며, 오랜 시간 유지되어 왔기 때문에 안전성이 보장되어 있다. 이는 Android Studio를 중심으로 필요한 SDK, 빌드 도구, 플랫폼 도구 등의 개발 환경을 구성하고 있다.

3-1. 안드로이드 앱 개발의 개요와 특징

네이티브 안드로이드 앱은 Android Studio(IDE)와 Android SDK를 사용하여 개발되며, Kotlin 혹은 JAVA 언어를 이용하여 작성하게 된다. JAVA는 전통적인 안드로이드 개발 언어이며 추후에 Kotlin이 안드로이드 공식 언어로 채택되었다. 이러한 환경은 안드로이드 플랫폼에 최적화되어 있고, 하드웨어 기능(GPS, 카메라, 파일시스템 등)을 쉽게 활용할 수 있게 제공된다.

그리고 안드로이드 플랫폼의 다양한 UI Component를 제공받아 XML 또는 Compose를 통해 Material Design을 구성하기 때문에 사용자에게 일관된 UI를 제공할 수 있다. 가장 안드로이드 플랫폼에 최적화된 방식이기에 Android SDK와 함께 최적화된 코드를 사용하므로 높은 성능의 앱을 제공할 수 있게 된다. 특히나 Android Studio의 경우 안드로이드 앱의 개발, 테스트 및 배포하는 데 필요한 모든 도구를 제공하는 공식 통합 개발 환경이기 때문에 개발자에게 매우 친숙한 개발 환경을 제공해준다.

3-2. 안드로이드 네이티브 장점 및 한계 

안드로이드 네이티브 앱은 안드로이드 플랫폼에 최적화되어 있기 때문에 높은 성능을 보장할 수 있으며, Android SDK의 모든 기능에 액세스 권한을 가지고 있어서 안드로이드 플랫폼의 모든 기능을 활용하여 다양한 앱을 개발할 수 있다. 그리고 Android SDK의 지속적인 업데이트와 개선 사항을 제공받을 수 있기 때문에 새로운 안드로이드 버전에 즉시 대응하고 새로운 기능을 지원할 수 있다.

만약에 스마트폰의 하드웨어 기능(GPS, 카메라, 파일시스템 등)을 많이 활용해야 하는 앱을 개발할 경우엔 하드웨어 기능에 접근성이 좋은 네이티브 앱이 개발의 편리성을 제공할 수 있다. 하지만 안드로이드 플랫폼에 최적화되어 있는 부분은 장점이 될 수도 있지만, 반대로 단점이 될 수도 있다.

Android와 iOS 앱을 모두 사용자에게 제공해야 하는 현재의 모바일 시장에서는 플랫폼에 각각 대응하는 별도의 앱을 개발하는 리소스가 필요하게 되므로 개발 시간과 비용이 증대되는 단점이 있다. 또한, Android SDK에 대한 이해도가 요구되기 때문에 Kotlin이나 JAVA와 같은 개발 언어 외에도 추가적인 학습이 필요하여 초기 학습 곡선이 높을 수 있다. 그리고 나아가 점점 발전하고 있는 크로스 플랫폼 프레임워크로 인해 미래에는 네이티브 앱 개발자의 수요가 감소될 수도 있다.

3-3. 안드로이드 네이티브 개발의 변화

안드로이드 네이티브 개발의 전통적인 방식은 Widget 기준으로 Dart 언어를 이용해 화면과 기능을 개발하는 Flutter와 다르게 화면과 기능을 분리하여 개발을 진행하게 된다. 기본적으로 XML 레이아웃 파일을 사용해 화면을 구성하고 앱의 각 화면은 Kotlin이나 JAVA를 사용해 액티비티(Activity)나 프래그먼트(Fragment)로 구현된다.

기능 역시 Kotlin이나 JAVA를 사용하여 데이터베이스 액세스, 네트워크 통신, 파일 처리 등을 구현한다. 즉 화면은 XML로 개발하고 그 외의 기능은 Kotlin이나 JAVA로 개발하게 되는 것이다. 여기서 화면을 구성하는 XML은 마크업(Markup) 언어라고 표현하는데 일반적인 프로그래밍 언어와 어떤 차이가 있는지 그림으로 설명하려고 한다.



그림 3은 XML 코드의 예시를 나타내고 있는데, 태그를 이용하여 화면을 구성하는 내용이 어떻게 배치되고 어떤 크기와 모양을 가지며 여백은 어느 정도인지를 표현하는 방식이다. 이렇게 데이터를 기술하는 정도로만 사용되기에 일반적인 프로그래밍 언어와 차이를 보이게 되는데 이것을 마크업(Markup) 언어라고 표현한다.

화면을 구성하는 방식 때문에 네이티브 안드로이드 개발자들은 마크업 언어에도 학습이 필요했으며 유지보수를 하는 과정에서 화면을 수정하려면 XML을 이용해야 했고, 기능을 수정하려면 Kotlin이나 JAVA를 수정해야 하는 번거로움이 있었다. Google은 이러한 마크업 언어로 화면을 만드는 것보다 선언형 언어를 이용하여 기존보다 적은 코드로 네이티브 화면을 구축할 수 있는 방법을 새롭게 제안하게 되고, 여기서 Compose가 등장하게 된다.
 


그림 4는 Google 공식 Developers 사이트에 기재되어 있는 화면이다. Google은 공식적으로 마크업 언어를 축소하고 선언형 언어로 화면까지 구성할 수 있는 방안을 제시하고 권장하였다.

이에 따라 네이티브 개발자들은 새로운 패러다임에 적응해야 했고, 추가적인 학습을 위한 리소스가 소모되게 되었지만, 여기서 중요한 점은 Compose가 도입된 네이티브 개발 코드를 보면 Flutter와 굉장히 흡사 해졌다는 것이다. 이 사실이 중요한 이유는 기존의 네이티브 안드로이드 개발자들이 Compose에 완전히 익숙해지는 시점이 온다면 Flutter개발로 전환하는 것에 진입장벽이 거의 없어진다는 의미이다.

4. 비교분석

이제 실제로 두 가지의 개발방식 간의 차이를 비교 분석해보려고 한다. 이 분석을 통해서 앞으로 모바일 개발자들이 어떠한 방안을 채택할지에 대해 도움이 되었으면 한다.

4-1. 개발속도

물론 개발속도는 개발자의 경험과 역량에 따라 바뀔 확률이 높지만, 기본적인 개발과정에 대해서만 다뤄보고 분석해보려 한다. Flutter의 UI 테스트 과정은 앞서 말했듯이 Hot Reload 기능이 있기 때문에 유리한 것이 사실이다. 네이티브 개발도 Compose의 등장으로 인해 Preview가 잘 구현되어 있지만 실제로 개발을 해보면 Preview의 로딩속도가 아직은 생각보다 느리다는 걸 체감하게 되고, 앱을 다시 빌드해야 하는 상황이 많이 발생하게 된다.

그리고 여기서 크로스 플랫폼의 장점이 크게 작용하게 되는데 Flutter로 앱의 개발이 완성되는 순간 Android와 iOS에 맞는 설정 정도만 보완해주면 두 플랫폼에서 실행이 가능한 두개의 앱을 모두 얻을 수 있다. 반면 네이티브 안드로이드 개발은 iOS 버전을 따로 개발해야 하는 단점이 있다. 여기서 속도를 맞추기 위해 Android 개발자와 iOS 개발자를 모두 이용하면 되지만, 그렇게 되면 비용적인 부분이 Flutter 개발자에 비해 부담될 수밖에 없다. 하지만 실제 현장에서는 생각했던 부분과 많이 달랐다.

우리에게 필요한 기능을 구축하기 위한 Flutter가 제공하는 기능은 한계가 있었고, 패키지나 라이브러리에서는 제공되지 않았기 때문이다. 거기에 Flutter 라이브러리에서 버그가 발견되는 경우도 있었다. 결국 각 플랫폼에 맞는 네이티브 Plugin을 따로 개발하게 되었고 이는 생각보다 시간과 비용을 절감해주는 장점을 크게 느끼지 못했다.

4-2. 소스코드 크기

Dart 언어를 사용하는 Flutter는 JAVA를 사용하는 네이티브 안드로이드 개발에 비해 기능 구현에 필요한 소스가 적어지는 효과가 있다. 이는 Dart 언어가 getter, setter의 자동 생성 및 Java보다 더 간결한 표기법을 제공하기 때문인 것으로 보인다. 다만 이 점은 Kotlin과 비교하게 되면 큰 차이를 느끼지 못하게 되며 오히려 Kotlin이 제공하는 응용클래스와 같은 부분들이 Dart에서는 제공되지 않는 점에서 아쉬운 부분일 수 있다.

이는 JAVA를 사용하여 네이티브 안드로이드 개발을 하고 있는 개발자들에겐 큰 이점으로 다가올 수 있는 부분이라고 보며 Kotlin을 사용한다 하여도 큰 차이점을 느끼지 못할 정도로 Dart언어가 발전했다는 것을 알 수 있다.

실제로 동일한 기능을 하는 Dart 앱의 소스코드는 4351줄이었던 반면 JAVA 앱의 소스코드는 6949줄이었다고 한다.^[5]
여기서 전체 소스코드 중 사용자 인터페이스(UI)에 사용되는 코드의 비율은 Dart 앱의 경우 74%, JAVA 앱의 경우 73%로 거의 동일한 비율이 이용되었다고 하니 기능 구현 뿐 만 아니라 화면 구성에 이용된 소스코드도 절감되었다고 볼 수 있다^.[5]

4-3. 성능

Flutter로 개발된 앱과 네이티브 안드로이드로 개발된 앱을 테스트해보았을 때, 분명 미세한 성능의 차이는 존재했다. 이는 실제 개발자가 아니라면 크게 느끼지 못할 정도의 미세한 차이였으나 스마트폰 환경에 따라서 순간적으로 체감되는 부분도 한번씩 발생하였다. 그리고 다중 플랫폼을 지원하는 특성상 화면 구성에도 미세한 차이가 나타났다.

 

그림 5에서는 동일한 앱을 그림 5(a)네이티브 안드로이드로 개발한 화면과 그림 5(b)Flutter로 개발한 화면을 보여주고 있다. 전체적인 기능이나 디자인은 크게 차이가 나지 않게 개발이 가능했으나, 상단 내비게이션 영역과 하단 내비게이션 영역이 Flutter로 개발한 경우엔 앱 설정을 따라가지 않고 플랫폼을 따라가는 것을 확인할 수 있다.

이것은 다중 플랫폼을 지원하는 Flutter의 특징으로 볼 수 있는데 특히나 하단 내비게이션 영역의 경우 iOS에서는 존재하지 않기 때문에 앱이 그 영역을 침범하지 않도록 화면이 설계되어 있는 것으로 보인다. 네이티브 안드로이드로 개발한 경우에는 안드로이드 플랫폼에 최적화되어 있기 때문에 상단과 하단의 모든 영역을 앱이 가져갈 수 있는 것으로 보인다. 실제로 앱을 사용하는 사용자 입장에서는 바로 알아차리기엔 어려운 부분이나 일반적인 안드로이드 앱과는 다른 어색함을 느낄 수 있다고 생각된다.

5. 결론

Flutter는 빠른 생산성과 강력한 성능을 가지고 있는 것이 분명했고, 앞으로의 모바일 시장에 큰 변화를 가져올 수 있겠다는 느낌을 받았다.

다만 현재 시점에서 네이티브 앱을 100% 대체할 수 있는지에 대해서는 조금은 회의적이었다. 그러나 Flutter가 가진 최대 장점인 크로스 플랫폼 개발이 가능하다는 것과 앞으로 Google에서 지속적으로 발전시킬 여지가 충분하기 때문에 기술이 발전할수록 Flutter를 선택하는 회사와 개발자들이 많아질 것 같은 생각이 들었다. 최종적으로 네이티브 앱과 큰 차이를 느끼지 못하는 수준까지 발전하게 된다면 Flutter를 선택하지 않을 이유가 없기 때문이다.


6. 참고 문헌

[1] Eric Windmill. (2019). Flutter in Action
[2] Dmitry Jemerov, Svetlana Isakova. (2017). Kotlin in Action
[3] Miquido. “Swift vs Kotlin vs Flutter in App Development: What to Choose?” Retrieved 2021.12.08, from
[4] Sungho Choi. Entry strategy of Mobile Application in multiple platforms, evidence from Korea 2023.2
[5] Yoonsik Cheon외 1명, Creating Flutter Apps from Native Android Apps, September 2020; revised: May 2021
[6] Flutter docs. Flutter Architecture Overview
[7] Google. Android Developers
[8] Dart packages. Pub dev