Flutter 란?

이 글은 플러터에 대해서 소개하는 글입니다.

이 글에서 다루고자 하는 내용은 크게 두 가지입니다.

첫 번째는 플러터에 대한 소개와 앱 서비스 개발시 고를 수 있는 선지에 대해서 다룰 것이고,

두 번째는 네이티브 프레임워크를 사용하는 팀에서의 경험과 개인적으로 플러터를 사용하면서 느낀 점입니다.

플러터란?

플러터는 구글에서 개발한 크로스 플랫폼 프레임워크입니다.

여러 플랫폼에서 제공되어야하는 서비스를 하나의 코드베이스로 관리하기 위해서 사용됩니다.

크로스 플랫폼 프레임워크? 

크로스 플랫폼 프레임워크란 하나의 코드베이스로 여러 플랫폼에 동시에 서비스를 제공하기 위한 프레임워크입니다.

대표주자들은 React-Native/Javascript(이하 RN), Xamarin/C#, Flutter/dart 정도가 있습니다.

크로스 플랫폼 프레임워크는 최종적으로 자바스크립트, C#, 다트로 짠 코드들이 네이티브 코드로 변경되어 동작하게 된다는 점이 같습니다.

앱 서비스 개발시 고를 수 있는 선지

멀티 플랫폼에 서비스를 동시에 제공하는 방법은 세가지가 있습니다.

첫째는 네이티브 앱, 둘째는 크로스 플랫폼 프레임워크, 셋째는 하이브리드 앱 입니다.

네이티브 앱

네이티브 앱은 플랫폼의 네이티브 언어와 프레임워크를 이용해서 개발하는 것입니다.

기기의 성능을 최대한 이끌어 낼 수 있다는 장점이 있지만. 각 플랫폼 별로 모두 개발할 수 있어야한다는 문제가 있습니다.

크로스 플랫폼 프레임워크

크로스 플랫폼 프레임워크는 하나의 코드베이스로 두 플랫폼에서 제공되는 서비스를 개발할 수 있습니다.

하나의 코드베이스로 네이티브 코드를 호출할 수 있고, 각각의 플랫폼에 대해서 많이 공부하지 않아도 자바스크립트, C#, 다트에 대해서 안다면 개발을 시작할 수 있다는 장점이 있습니다.

하이브리드 앱

하이브리드 앱은 웹 페이지를 웹뷰로 감싸서 플랫폼에 내는 방법입니다.

웹 개발로 앱도 동시에 개발할 수 있고, 각각의 플랫폼에 완전히 동일한 경험을 하게 만들어 줄 수 있다는 장점이 있습니다.

 

위 세 가지 선택지에 대해 더 자세하게 다루는 것은 다른 게시물에서 다루도록 하겠습니다.

네이티브 vs 플러터

이 섹션은 안드로이드와 IOS를 각각 개발했던 회사와 개인적으로 플러터로 앱을 개발하면서 느낀 점에 대해서 다룹니다.

 

네이티브

저는 회사생활을 하면서 안드로이드와 IOS에 동시에 서비스하는 팀에서 일했습니다.

서버 파트에 있었지만 각 파트와 함께 유기적으로 일을 했는데요.

안드 팀과 IOS팀의 개발자분들과 함께 일하면서 느낀 점은 크게 두 가지가 있었습니다.

 

첫 번째는 플랫폼마다 UI, UX 에 대한 니즈가 다르다는 것이었습니다.

예를 들어, 아이폰 유저들은 왼쪽에서 오른쪽으로 패닝했을때 페이지의 뎁스가 하나 낮아지길 기대합니다.

반면, 안드로이드 유저들은 드로어가 나타나길 기대하죠. 이를 만족시키지 못하면 유저들은 당황하고, 불편함을 느낍니다.

그렇기 때문에 언어나 프레임워크와 별개로 앱 서비스를 운영한다면 유저가 기대하는 UI,UX를 만족시켜줘야합니다.

이러한 플랫폼별 대응은 크로스 플랫폼 프레임워크를 사용해도 대응을 해줘야합니다. 어떤 방식으로 개발을 하던 반드시 지켜줘야하기 때문입니다.

 

두 번째는 네이티브 프레임워크로 개발하는 것은 생각보다 많은 에너지가 든다는 점이었습니다.

각 플랫폼 별로 네이티브 프레임워크로 개발하면 각 파트별로 개발자 뽑기, 혹은 각 개발환경에 대해서 배우기 외에도 +a의 업무가 발생합니다.

이 +a는 바로 관리 포인트입니다.

네이티브 프레임워크로 개발하면 각 파트가 서로 다른 언어와 프레임워크가 다르기 때문에, 코드리뷰를 포함한 개발 프로세스에서 다른 파트의 구현체를 확인하기가 어렵습니다. 그렇기 때문에 어떤 기능을 개발할때 플로우를 매번 공유하고, 확인하면서 클라 개발팀 전체에서 관리가 필요하게 됩니다. 이런 관리 포인트의 예시를 아래에서 설명할건데요.

 새로운 피쳐를 개발하다보면 세부 기획을 빠뜨리는 경우가 있습니다. 그리고 그런걸 모두가 놓치는 경우도 가끔 생기는데요.

다들 어떻게 짜야할지 본인 머릿속으로만 생각하다가 파트별로 기능을 다르게 구현하는 걸 몇번 봤습니다. 이런 문제가 파트 안에서 발생하면 코드리뷰를 하는 과정에서 해결 할 수 있습니다. 그러나 이렇게 파트사이에서 소통 실수를 한 경우는 서로 다른 언어와 프레임워크를 사용하다보니, 코드 리뷰에서 해결하지 못하게 됩니다. 일종의 "믿고간다" 상태로 작업을 한다고 할 수 있습니다.

그런데 "믿고 가다가" 서로 다르게 개발한 부분을 발견하면, 새로운 문제가 더 생깁니다. 서버파트에서는 버전 분기를 추가로 타줘야하고, 각 파트간에 커뮤니케이션 비용이 다시 발생하고, 더 커지는 문제들이 있겠죠.

 

이런 문제를 겪은 이후에는 서로 어떻게 구현할지 맞춰서 진행을 했습니다. 다른 회사의 다른 팀들도 아마 이 관리 이슈를 겪었을 텐데요.

작업의 흐름속에서 해결되지 않기 때문에 이 문제를 항상 적잖이 신경쓰고 있을 것이라 생각합니다.

만약 하이브리드 앱이나, 크로스 플랫폼 프레임워크를 사용하면 어떻게 되었을까요? 코드리뷰를 하는 과정에서 이런 문제들은 다 잡혀서 배포가 되지 않았을까요? 저는 이런 관리 포인트들은 하이브리드 앱, 크로스 플랫폼 프레임워크를 사용하면 해소될 것이라고 생각합니다. 코드리뷰하는 과정에서 문제를 발견할 수 있기 때문입니다.

 

플러터

저는 개인 프로젝트를 진행하면서 플러터로 앱을 만들고 있습니다.

처음에 플러터를 선택한 이유는 혼자서 두 플랫폼에 네이티브 앱을 만들 수 없었기 때문입니다.

한 달정도의 시간으로 개발을 완료하려고 했고, 그러다보니 크로스 플랫폼을 선택했습니다.

 

고민하던 프레임워크는 RN과 플러터였는데요. 둘중에서 플러터를 한 이유는 제 리엑트 실력때문이었습니다.

저는 리엑트를 사실 그렇게 잘하지 못했고. 제가 리엑트 네이티브를 하면 모르는게 생겼을 때 리엑트를 몰라서 못하는건지 아니면 RN을 몰라서 못하는건지 모르겠는 상황이 올 것 같았습니다. 그리고 플러터가 앞으로 점점 더 우세해질 것 같은데, 지금 시작하면 선두주자가 될 수 있겠다 라는 생각이 들어서 플러터로 개발을 시작했습니다.

 

플러터의 장점

플러터를 쓰면서 좋았던 점은 세 가지가 있었습니다.

 

모든 것은 위젯

첫 번째로 모든 것이 위젯이라는 점이었습니다.

리엑트를 까려고 하는건 아닌데요. 리엑트는 JSX를 피하기가 어려운데, JSX와 클래스를 통해서 코드를 관리해줘야하는게 불편했습니다. 반면 플러터는 모든게 위젯이라는게 되게 편리했습니다. 애니메이션, 레이아웃, 제스쳐같은 부분들도 다 위젯으로 개발을 해야하니까 코드 관리가 깔끔하고 Composition관계가 명확하게 보여서 좋았습니다.

많은 구현체

두 번째로 각 플랫폼별로 당연히 있어야하는 기능들이 다 구현되어있었다는 점입니다.

예를 들어서 버튼이 있으면 그냥 버튼이 아니라 안드로이드용 버튼, IOS용 버튼이 따로따로 구현되어있기 때문에 이런 부분을 직접 구현하지 않아도 되었다는 점이 좋았습니다.

이게 RN이나 자마린 같은 경우는 버튼을 사용하면 해당 뷰가 플랫폼에 종속되어서 보여지는데, 플러터는 플랫폼에 종속되지 않고 내가 보여주고 싶은 부분을 편하게 구현할 수 있어서 좋았습니다.

핫 리로드

세 번째로 개발을 하면서 빠르게 개발된 화면을 볼 수 있어서 편했습니다.

웹 개발이랑 다르게 앱 개발은 어떤 화면을 개발하고나서 확인을 하려면 재 빌드를 해야하는 경우가 많은데요. 플러터는 Hot reload를 지원하기 때문에 빠르게 프로토 타입을 만들고 확인할 수 있는 점이 좋았습니다. 

 

플러터의 단점

제가 플러터 칭찬을 많이 했는데요. 이제 단점에 대해서도 좀 이야기 해보려고 합니다.

플러터의 단점은 아예 네이티브를 안 만질 수는 없다는 점입니다. 왜냐하면 앱이 커지다보면 네이티브가 필요한 순간이 오기 때문입니다.

하지만 네이티브만큼 성능이 필요한 어플을 만들고 있다면 돈을 들여서 네이티브 개발자들을 채용할 수 있는 기업이 된 것이라고 생각합니다. 그렇기 때문에 그렇게 나쁜 소식은 아니라고 생각합니다.

또한 네이티브를 사용하지 않고 플러터만 사용하면서 동시에 해결하는 방법도 있습니다. 속도가 중요하지 않은 스크린, 페이지들을 웹뷰로 대체하는 것입니다. 주요 페이지를 제외하고 웹뷰로 갈아끼워서 작업을 한다면 앱의 무게를 가볍게 만들 수 있고, 앱 마켓에 검수를 받지 않고 수정사항을 반영할 수 있기 때문입니다.

마무리

아예 새로운 도메인인 클라이언트 개발, 그리고 플러터에 대해서 시작했습니다.

앞으로는 플러터에 대한 정보와 좋은 자료 번역을 시리즈로 다뤄보려고 합니다.

궁금하거나, 하고 싶은 말이 있으시면 댓글을 통해서 말해주시길 바랍니다.

 

감사합니다.