자 그래서, 과연 이것도 별로다 저것도 별로다. 뭘 얘기하려고 그랬던 걸까요?
무슨 영업이라도 하려던 것 같습니다.
사실 그렇게 생각하실까봐 걱정이긴 한데요.
걱정 안하셔도 됩니다. 아니라고 일단 우겨보려고 합니다. (?)
하이브리드 플랫폼, 플러터(Flutter)
제가 엔트리 다음으로 한 번 해보시라고 추천하려는 플랫폼(언어가 아닙니다)은, 바로 플러터(Flutter)입니다.
구글에서 2017년에 공개한 하이브리드 프레임워크인데요, 처음에는 모바일 개발용으로 공개됐습니다.
그러니까 iOS와 안드로이드를 동시에 개발하는 용도로 소개됐죠.
그러다 보니, 당시에 동일하게 하이브리드 모바일 앱을 만드는 리액트 네이티브(React Native)와 라이벌 관계가 생겼습니다.
사실 지금도 좀 그런 이미지가 있죠. 아직도 플러터 하면 모바일 앱 만드는 프레임워크 이미지가 있으니까요.
리액트 네이티브는 리액트 기술을 이용해서 모바일 앱을 만들 수 있는 기술로, 나름 꽤 괜찮은 기술입니다.
하지만 왜 아직까지 1.0을 배포하고 있지 않은지는 좀 의문인데, 이 부분은 나중에 따로 포스팅을 좀 해보겠습니다.
이러던 플러터는, 2024년 11월 현재 3.5가 나온 시점에는, 단순히 모바일을 넘어서 웹도 개발하고 (2.0부터 가능해 졌습니다),
이제는 윈도와 mac, 리눅스용 데스크톱용 애플리케이션 개발까지 가능해진, 뭔가 이것저것 다 해볼 수 있을 것 같이 발전했습니다.
플러터가 "나름" 괜찮은 점
앞에서 말씀드렸듯, 하이브리드 프레임워크의 특장점인 하나의 프로젝트로 여러 가지의 OS 환경용을 개발할 수 있다는 겁니다.
플러터 말고도 사실 하이브리드 프레임워크는 여러 가지가 있습니다. 아까 말씀드린 리액트 네이티브도 있고,
지난 주말에 비주얼 스튜디오 코드 말씀드릴 때 소개드린 일렉트론(Electron)도 하이브리드 프레임워크라고 볼 수 있죠.
하지만, 플러터처럼 모바일과 데스크탑, 웹을 모두 아우르는 범용 프레임워크는 흔하지 않습니다.
이번에 제가 플러터를 다음 소개하려고 하게 된 것도, 단순히 모바일 하이브리드에서 그치지 않고,
웹이나 데스크톱까지 아우르는 어플리케이션을 개발할 수 있다는 점을 높이 샀기 때문입니다.
플러터가 별로인 점
플러터가 그렇다고 좋기만 한가? 당연히 아니죠.
일단 너무 이미지가 좋지 않습니다(...)
일단 개발사인 구글이 그 동안 해 놓은 전적이 화려해서(...) 언제 버려질지 모른다는 불안감이 있죠.
몇 달 전에 구글이 대규모 감원을 했다고 해서 또 플러터 버려지는 거 아니냐고 말이 나오기도 했죠.
하지만, 구글이 플러터를 가지고 하려는 목적이 나름 뚜렷하기 때문에, 어느 날 갑자기 버려지지는 않을 것 같습니다.
그래서 그런지, 안티가 많습니다(...)
플러터가 이것저것 할 수 있다니까 일단 까고 보려는(...) 분들이 좀 계신거 같아요.
위에 구글이 언제 버릴지 모른다 부터 시작해서, 리액트 네이티브랑 한창 대립하던 시기엔 무슨 멸망전 하려는 분들도 계셨고(...)
하이브리드 프레임워크는 원체 여기저기 고개를 내밀어서 그런지, "이거 쓰느니 코틀린 스위프트로 그냥 만들고 만다" 라던가,
2.0 시절엔 "이걸로 웹 만들어서 뭐함?" 소리도 듣고, 기타 등등(...)
뭐 근본적으로, 다른 하이브리드 프레임워크보다 빠르다고는 해도, 기본적으로 하이브리드 자체의 한계가 있다보니,
네이티브 프레임워크(원래 그 OS용으로 사용하는 프레임워크)보다는 속도가 느릴 수밖에 없습니다.
또한, OS나 네이티브 프레임워크가 버전 업을 해 버리면 최신의 API 같은 것의 도입이 느릴 수밖에 없죠.
심지어 같은 구글이 만든 안드로이드조차도 대응이 느리니, 애플이나 MS 쪽은 말 할 것도 없을 것입니다.
또한, 플러터를 사람들이 꺼려하는 가장 큰 이유 중 하나가 바로, 사용하는 프로그래밍 언어가 낯설기 때문입니다.
플러터를 이용해서 앱을 개발하기 위해서는 다트(Dart)라는 언어를 배워야 하는데,
이 언어가 사실상 거의 플러터에서만 쓰이고 다른 환경에서는 쓸 일이 없기 때문입니다.
플러터만 계속 쓸 게 아니라면 기존에 파이썬이나 자바 같은 범용성 높은 언어 배우기도 힘든데 굳이...? 싶은 거죠.
그래도 소개해 보는 이유
그럼에도 불구하고 제가 플러터를 소개하는 이유는 두 가지가 있습니다.
첫째로, 다트 언어가 굉장히 배우기 쉽기 때문입니다.
우리가 많이 배우는 다른 프로그래밍 언어와 상당히 문법이 이질적이면 다트 언어를 배우는 데 문제가 많겠지만,
실제로 배우시다 보면 뭔가 친근한 점이 많으실 겁니다. 자바같기도 하고, 자바스크립트 같기도 하고, C# 같기도 하고 그렇거든요.
사용하는 예약어 자체도 특이한 것도 없고, 예약어 용법도 대부분의 C-liked 언어(C언어에서 파생된 언어)가 그렇듯 다 비슷합니다.
둘째로, 플러터를 일단 배우고 나면 다른 환경으로 옮겨가기 쉽기 때문입니다.
모바일이면 모바일, 웹이면 웹, 데스크톱이면 데스크톱 어느 고정된 환경이나,
특정한 프로그래밍 언어에서 공부를 시작해서 특화된 후에,
무언가의 필요로 다시 완전히 다른 환경으로 이전한다는 것은 굉장히 어려운 일입니다.
하지만, 플러터는 그 모든 환경에서 일단 어떻게 움직이는지 살펴볼 수 있습니다.
필요하다면 각각의 구동 원리나 네이티브 파트의 움직임도 확인이 가능합니다.
그러다가, 플러터가 마음에 안들거나, 혹은 하이브리드 환경에서의 움직임의 비효율성에 만족하지 못하고,
좀 더 나은 효율성을 추구하기 위해 각각의 특화된 환경으로 옮겨갈 때,
플러터에서 경험한 해당 OS의 환경과, 일단 확립된 프로그램 개발에 대한 방법론은
새로운 환경으로의 이전을 더욱 쉽게 도와줄 것입니다.
정리
뭔가 변죽은 많이 올려놓고 정리는 잘 못한 느낌이네요. 시간이 없어서(...)
다음 포스팅부터 실제로 플러터를 가지고 뭔가 얘기하다보면 정리가 되지 않을까 생각합니다.
플러터 띄우려고 의도적으로 다른 언어나 프레임워크를 깎아내린 게 아닌가 생각하시는 분들도 계실 듯 합니다.
다시 말씀 드리지만, 플러터가 꼭 유일한 솔루션도 아니고, 이게 최고라고 말씀드리진 않겠습니다.
앞에서도 말씀드렸듯 약점이 적지 않습니다.
오블완 포스팅을 시작할 때 말씀드렸지만, 원래 이 시리즈가 플러터부터 시작할 계획이었지만,
플러터부터 시작을 유도하기에 약점이 적지 않았기 때문에 돌고 돌아 이 지점부터 시작하게 된 것이었습니다.
하지만, 그만큼 또 여러분들께 어필할 수 있는 부분이 많기 때문에 고민도 많이 했고,
덕분에 엔트리까지 만나서 기초적인 부분을 많이 보강할 수 있었습니다.
이 시리즈가 잘 진행될 수 있을지는 모르겠지만,
어쨌든 생각한 내용을 잘 다룰 수 있도록 해보겠습니다.
다음 포스팅에서는 설치해보고 플러터로 앱을 만드는, 아주 고전적인(...) 시작을 해 보겠습니다.
