Xamarin과 Flutter 그리고 크로스 플랫폼의 미래
Xamarin 을 만나다
저는 고등학교 1학년 여름방학에 처음으로 C# 프로그래밍을 배웠습니다.
처음엔 뭐가 무엇인지 몰랐지만, 그때까지 배워왔던 C에 비해 할 수 있는 것들이 많았습니다. 그렇다 보니 자연스럽게 C# 에 빠지게 되었습니다.
고등학교 2학년이 되던 해, 저는 김포프님 유튜브를 즐겨보기 시작했습니다. 당시에는 사람들이 유튜브를 그렇게 많이 볼 때도 아니라 개발자 관련 영상은 포프님 영상을 제외하곤 거의 없었습니다.
김포프님의 영상은 내용 하나하나가 공감 가는 내용이거나 혹은 매우 관심이 가는 내용이었습니다.
그리고 위 영상을 보게 되었고 자마린을 시작해야 봐야겠다는 결심을 하게 됩니다.
최악의 Xamarin.Forms
모바일 개발은 막 안드로이드 스튜디오 1.0이 나올 때쯤 안드로이드 개발 조금 해본 것이 전부였습니다. 하지만 자마린을 배우면 여러 플랫폼의 앱을 한 번에 만들 수 있다는 생각에 자마린을 계속 파기 시작했습니다.
하면서 가장 마음에 안 들었던 점은 UI Previewer가 없다는 것이었습니다. 제가 입문할 때쯤에 막 Visual Studio의 Preview 기능으로 나오기 시작했는데 정말 농담 아니고 단 한 번도 제대로 동작한 적이 없었습니다. 😱
그래서 UI 코드를 짜면 무조건 실행을 해봐야 어떻게 되는지 알 수 있었습니다. 관련 문서도 많이 없던 시절, 어느 한 속성이 뭔지 알기 위해선 한 번 적용해보고 실행해보고 빌드 기다리고 확인해보고 바꿔보고 기다리고 … 고통의 반복이었습니다.
빌드가 빠르면 모릅니다. 정말 빌드 속도도 최악이었습니다. F5 눌러놓고 짧으면 1~2분, 길면 4~5분은 기다려야 앱이 시작했습니다. 😩
그래서 자마린으로 개발했던 학교 프로젝트도 망쳤습니다. 참… 지금 되돌아보면 그때 그냥 안드로이드 앱만 하나 제대로 만들었으면 하는 생각도 듭니다.
어쨌든 제가 입사할 수 있게 해준 건 이 Xamarin.Forms 덕분이고 지금은 많이 발전했고 나아지긴 했지만, 입문 당시엔 정말 최악이었습니다.
Xamarin.Forms 의 한계
Xamarin은 Mono를 기반으로 두고 있는 프레임워크입니다.
Mono란 간단히 이야기하면 C#이 여러 플랫폼에서 돌 수 있도록 하는 프레임워크로 이 Mono를 통해 C#으로 짠 코드가 윈도우, 리눅스, 안드로이드, iOS 등 여러 플랫폼에서 돌 수 있게 됩니다.
(게임업계에서 유명한 Unity 도 Mono 기반입니다.)
그래서 Xamarin을 이용하면 UI는 플랫폼마다 각각 만들어야 하지만 로직은 단 한 번만 C# 코드로 짜면 되므로 많은 사람들이 Xamarin 과 크로스 플랫폼 개발에 관심을 가지게 되었습니다.
그런데 Xamarin은 여기서 한발짝 더 나가게 됩니다.
Xamarin 팀이 생각한 것이 “플랫폼마다 똑같이 텍스트 라벨이 있고 텍스트 인풋이 있고 이미지 컨트롤도 있고 그런데 그냥 이것도 한 번만 쓰면 알아서 플랫폼 UI로 바꿔주면 되는 것 아니야?” 해서 탄생한 것이 Xamarin.Forms입니다.
Forms의 Label컨트롤을 예로 들면 Android에선 TextView 으로, iOS에선 UILabel 으로 각각 플랫폼에 맞는 네이티브 컨트롤로 렌더링됩니다. 이렇게 UI를 추상화할 생각을 하다니 정말 똑똑한 생각인 것 같습니다.
다만 이 방법의 엄청나게 큰 현실적인 한계가 있습니다. 그건 바로 네이티브의 UI 컨트롤들을 모두 Forms 단에서 사용할 수 있도록 추상화를 해줘야 한다는 것입니다.
만약 컨트롤이 iOS엔 자주 쓰이는 컨트롤이지만 안드로이드엔 없는 컨트롤이 있다고 생각해봅시다. 이런 경우 추상화에 있어서 매우 곤란해집니다. 결국 ‘네이티브에선 당연히 되는 게 여기선 안 되네? 자마린 별로네~’ 라고 느껴지게 됩니다.
Xamarin.Forms가 GitHub 스타 100,000개의 유명 레포지토리라면 모를까 제가 시작했을 땐 Microsoft가 인수한 지도 얼마 되지도 않았을 때였고 Forms에는 정말 있어야 한다고 생각한 기본적인 컨트롤들조차 많이 없었습니다.
지금은 Microsoft에서도 힘을 많이 쏟고 있고 많은 오픈소스 개발자분들께서 컨트리뷰션을 하시고 있어 예전보다 많이 쓸 만 해졌지만 부족한 점이 여전히 많이 있습니다.
그러다 Flutter를 알게 되었습니다.
Flutter: 아니 뭐하러 네이티브 UI를 쓰냐 ㅋㅋㅋ
그렇습니다.
‘왜 굳이 힘들게 추상화해서 네이티브 컨트롤을 쓰냐,
걍 비슷하게 렌더링해서 보여주면 되지’ 하는 것이 Flutter의 구조입니다.
그게 무슨 말이냐면 Dart로 UI를 짜면 C++ Skia 엔진이 네이티브 컨트롤과 비슷하게 렌더링합니다. 🤣 그러니 귀찮고 시간만 많이 드는 UI 추상화할 필요도 없는 것이고 이런 구조로 인해 핫 리로딩 같은 편리한 기능도 포함될 수도 있는 것입니다.
구글은 정말 천재인 것 같습니다. 이런 발상은 Java의 JVM같은 가상머신의 발명과 같이 프로그래밍 역사의 한 획을 긋는 수준이라고 생각합니다. 플랫폼에 맞게 엔진만 만들어주면 정말 어느 플랫폼에서든 그 UI가 만들어질 수 있는 것입니다.
(사실 Java의 Swing이나 JavaFX가 이런 구조이긴 합니다만 구려서 현업에선 아무도 안 쓰긴 하죠. 물론 JetBrains의 IntelliJ IDEA같이 휼륭한 프로그램도 있습니다만…)
이 많고 많은 플랫폼의 네이티브 UI를 추상화하는 것은 현실적으로 불가능하기 때문에 제 생각엔 UI를 크로스 플랫폼하는 구조는 이 Flutter 구조가 제일 최선의 방법이라 생각이 드네요.
내가 생각하는 Flutter 의 단점
저는 사실 플러터 앱을 만들어 보긴커녕 Getting Started도 안해봤습니다. 그래서 Flutter에 대한 경험은 하나도 없는데 그런 입문도 하기 전 입장에서 생각이 드는 Flutter의 단점을 적어보았습니다.
(+2020.09.01 수정) 최근들어 회사에서 Flutter 앱을 개발하고 있는데 그 입장에서의 내용도 추가했습니다.
매우 주관적인 생각이니 고려해서 읽어주었으면 합니다.
Dart? 굳이?
Flutter의 개발 언어는 Dart입니다. 사실 Dart라는 언어를 Flutter를 통해 알게 되었지 그 전까진 단 한 번도 들어본 적이 없는 언어였습니다.
프로그래밍 업계에서 언어나 프레임워크, 라이브러리가 많이 쓰이고 있다는 건 그만큼 개발 환경이나 실행 환경이 안정성적으로 검증되었다는 것을 의미하고 그래서 회사에선 프로덕션 레벨에 어느 정도 믿고 쓰게 됩니다.
단언할 수 있는 것은 Dart는 현업에서 주로 쓰이는 언어가 아닙니다. 그러므로 주로 쓰이는 언어들에 비해 라이브러리도 적을 수밖에 없고 어떤 문제가 생겨도 해결하는데 자료가 적어 시간이 오래 걸릴 수밖에 없습니다.
그런데 구글이 메인테이너라는 점이 이 단점을 정말 크게 상쇄해버립니다. 구글은 진짜 다른 회사에 비해 월등히 신뢰성이 높습니다. 그래서 믿고 Dart와 Flutter를 쓸 수 있는 것입니다. 만약 메인테이너가 구글이 아니었다면 ‘개발 언어가 Dart? 그런 마이너한 언어를 어떻게 프로덕션에서 써?’ 하고 바로 업계의 관심 밖으로 밀려 나갔을 것입니다.
(+2020.09.01 수정) Dart를 직접해보고 든 생각은 음… ‘최신이면서 구식같다.’ 입니다. 요즘 대세 언어들인 kotlin, python, JavaScript/TypeScript, swift… 등 서로 영향을 받으며 편리한 문법들과 기능들을 추가하고 있습니다.
제 주 언어인 C#은 위 언어들에 비해 조금 보수적이지만(구닥다리지만) 최근 들어 C# 8.0, 아직 나오지 않은 9.0 버전 등 다른 언어들로부터 좋은 문법들을 가져와 계속 발전해 나가고 있어 종종 불편할 때도 있지만 항상 만족하며 사용하고 있습니다.
그런데 Dart는 음… 분명 어느 부분에 있어서는 좋은데 어느 부분에 있어서는 구닥다리입니다. 자세한 내용은 아래 포스트를 읽어보시면 됩니다. 글을 읽으면서 많은 공감이 갔습니다. 아무튼 그렇다보니 개발할 때 ‘이게 안 돼?’ 하면서 조금 불편할 때가 많았습니다.
단점이라고 생각했던 점, Declarative UI
// Imperative style
b.setColor(red);
b.clearChildren();
ViewC c3 = new ViewC(...);
b.add(c3);
// Declarative style
return ViewB(
color: red,
child: ViewC(...),
);Declarative UI를 간단히 소개하자면 프로그래밍단 코드에서 UI 컨트롤들을 선언적으로 만들어서 UI를 구성하는 것입니다.
저는 예전부터 정말 UI 코드와 동작하는 코드(비즈니스 로직)는 무조건 분리되어야 한다고 생각해왔습니다.
React 를 직접 개발해보진 않았으나 난 그 구조가 전혀 이해가 되지 않는다.
jsx 파일 안에 담기는 UI 코드들과 실제 동작하는 코드들. 유지보수를 어떻게 할 수 있는지 의문이다. 웹 프레임워크 시장을 React 가 꽉 잡고 있는 것이 정말 신기하다.
위 글이 불과 몇개월전에 제가 썼던 글입니다.
UI와 비즈니스 로직이 혼재하면 개발할 때엔 빠르게 개발할 수 있을지 모르나 나중에 코드를 읽을 때 읽기가 어려워지기 시작하고 결국 유지보수가 어려워져 생산성이 저하될 것으로 생각했습니다.
하지만 제 생각과 반대로 Flutter를 포함해 Apple의 SwiftUI 등 현재 모던 UI 프레임워크들은 위에 그렇게 깠던 React와 같이 Declarative UI로 넘어가는 추세입니다.
심지어 Xamarin.Forms도 Declarative UI로 UI를 만들 수 있는 컨트리뷰션이 머지될 예정입니다. 😅
업계의 방향이 이렇다는 것은 이게 실제 UI를 개발하는 데 있어서 개발과 유지보수가 더 유리하다는 것이 검증되었다는 것을 의미합니다.
실제로 Declarative UI로 개발하더라도 UI layer와 Business logic layer를 잘 나눌 수 있겠지만, 강제적으로 나뉘는 것이 아니므로 점점 개발하다 보면 의도치 않게 혼재되게 될 가능성이 있어 이 점이 저에겐 조금 우려되는 점입니다.
내가 원하는 크로스 플랫폼 프레임워크는?
저는 앞으로도 코드 쉐어를 위해 C#, Xamarin을 쓸 예정입니다. 지금까지 쭉 해오기도 했고 정말 많은 플랫폼(윈도우, 맥, 리눅스, 안드로이드, iOS, 타이젠 등)에서 동작하며 또 이 정도로 많은 플랫폼에서 도는 언어는 C/C++를 제외하고는 있지도 않습니다.
다만 UI의 크로스 플랫폼을 얘기하면 다릅니다. Xamarin.Forms는 물론 지금도 계속 발전해 나아가고 있으나 위에서 얘기했듯 정말 2% 부족할 때가 많습니다. 프로덕션 레벨에서 쓰게 되면 하게 될 삽질의 반복과 고통길이 눈에 훤히 보입니다. 😭
(물론 개인적으로 쓰거나 작은 앱이라면 적절하다고 생각합니다.)
그래서 Xamarin을 베이스로 하지만 Flutter로 UI를 만들 수 있으면 좋을 것 같다는 생각이 들었습니다. 찾아보니 실제로 이런 시도가 있었긴 했었지만, 기술적 검토만 진행했을 뿐, 실제 프로덕션으로 개발할 수 있도록 발전되진 못했습니다.
(아무래도 개인 개발자의 단순한 기술적 검토였을 뿐이기에…)
저로서는 Flutter가 잘 되길 바랍니다. 그래서 Xamarin도 Flutter에게 영향을 받아 좋은 점들을 흡수하고 현재 문제가 되거나 불편한 점들을 탈피해 더 발전하는 모습을 보였으면 합니다.
크로스 플랫폼 개발에 무궁한 발전을 기리며.
끝
