11개월 만의 취업

이력서를 넣고 면접을 보러 다닌 지 어느덧 11개월이 지나 취업을 했다.

출근을 한지 일주일이 지났으나, 이번 주까지는 일정이 바쁘지 않고 빠르게 공부를 해서 앱을 출시해야하는 상황에 직면하여 앱 개발을 위한 공부를 하고 있다. (물론 현재 조금씩 보는 업무는 웹이다. 근데 UI수정 정도만 이번 주까지는 했다.)

---

눈 앞에 주어진 선택지. RN vs Flutter

클라이언트가 앱도 출시를 하기 원한다고 하여 내게는 현재 사이트를 앱으로 개발해야하는 숙제가 주어졌다. 리액트(넥스트) 개발자인 내가 조금 더 편하게 개발을 하기 위해서는 아무래도 React Native가 낫지 않을까 하는 생각이 들었고, 대표님도 처음에는 생산성을 생각하여 RN을 언급했다.

하지만 최근의 가장 핫한 앱 개발 프레임워크는 Flutter아닌가? 그렇다고 다트언어를 공부해야하고 익숙한 자바스크립트와 익숙한 “리액트식” 함수 컴포넌트를 활용하고 있는 RN을 뒤로하고 클래스 기반 객체 지향 언어인 다트로 개발하며 클래스 기반의 컴포넌트를 사용하는 Flutter를 굳이 선택해야할 이유가 되지는 않는 듯 했다.

그래서 내가 선택한 게 무엇이냐고 한다면, (그럼에도) Flutter를 선택했다.

---

Why Flutter?

플러터를 처음 알 게 된 것은 3월에 보았던 면접에서였다. 기술 스택은 명시되어있지 않은 백오피스 프론트를 개발한다는 포지션이었는데 면접관이 모두 백엔드 개발자였고 백오피스를 플러터로 개발하고 싶다는 의지를 내비쳤었다.

플러터에 대한 지식이 없던 나는 플러터에 대해 물어봤었고, 왜 플러터를 활용하고 싶어하시는 지에 대해서도 여쭤봤다. 대답은 굉장히 간단했는데, 플러터가 클래스 기반 객체 지향을 근간으로 하고 있기 때문이었다. 아무래도 백엔드 개발자들에게 더욱 친숙한 클래스 기반의 프레임워크라면 (또 다트라는 언어라면) 함께 코드를 다루는 것이 간편할 것만 같았다.

이후에도 9월경 실제 플러터로 백오피스를 개발하고 있다는 곳에도 면접을 봤다. 심지어 실제 웹 서비스를 비롯해 백오피스를 성능이 좋지 않다는 플러터 웹으로 개발하고 있었고 이는 내 흥미를 동하게 했다. 대체 플러터가 무엇이길래 멀쩡한 자바스크립트(아 멀쩡한가..?) 를 두고 다트라는 언어를 굳이 배워가며 플러터를 사용할까?

궁금증을 참을 수 없던 나는, 그리고 오랜 취준으로 취미가 필요했던 나는 다트와 플러터를 찍먹해보고자 하였다. 물론 찍먹이랄 수도 없을 만큼 다트 문법과 플러터 문법만 찔끔 본 것이지만 꽤 흥미로운 구석이 있었다.

1. 자체적으로 정적 타이핑을 지원하는 언어인 점

2. 하나의 언어/하나의 프레임워크로 iOS, AOS, MacOS, Window, Web 까지 모두 처리할 수 있다는 점

3. Material Design과 Cupertino Design을 바탕으로 한 강력한 디자인 시스템과 그로 인한 빠른 개발

4. skia 엔진을 활용한 모든 플랫폼에서 동일한 UI 제공

5. 그리고 생각보다 규모있는 커뮤니티

6. 마지막으로 코드푸시 지원

많은 사람들이 플러터를 얘기하며 구글의 빠른 지원종료 혹은 지독한 신념으로 인한 사용성 저하를 걱정한다.

하지만 그런 구글이라는… 큰 단점조차도 커버할 수 있는 거대한 장점을 지니지 않았나?

앵귤러라는 선례를 걱정하는 사람들이 많은데, 앵귤러는 이미 출시 시기 부터 리액트에 밀리고 뷰에 따라잡히는 모습이었다.

반면 Flutter의 경우, 2019년 기준으로 하위권에 랭킹되었지만 현재는 React-native와 쟁쟁하게 맞붙고 있으며 심지어 근소한 차이로 높은 선호 혹은 사용 중인 것으로 파악된다.

후발주자가 가지는 리스크 중 하나로 커뮤니티의 부재가 있다. 하지만 이마저도 플러터는 고비를 넘기고 무사히 순항 중인 것으로 보인다.

이처럼 발전하고 있고 충분히 성숙해나가는 듯 보이는 기술을 마다할 개발자는 생각보다 많지 않다고 생각한다. 익숙한 게 최고라고 하지만, 충분히 도전해볼만큼의 메리트가 있다면 플러터는 좋은 선택이라고 생각했다.

이게 내가 플러터를 선택한 가장 큰 이유다.

---

사용 경험은 어때?

회사에서 계속 강의듣는 상태라서 일단 문법적인 부분에 대해서는 한번 쓰윽 훑었다.

그리고 강의 따라치기 신공으로 문법을 손으로 익히고 있는데, 일단 사용경험은 좋다 반 음 반이다.

복합적으로는 좋은 쪽이 맞는데, 리액트의 문법과 코드에 익숙해진 상태여서를 논외로 하더라도 플러터 특유의 심각한 네스팅은 좋게 봐줄 건덕지가 0에 가깝다.

네스팅 지옥

간단한 코드를 작성해도 깊은 네스팅에 가독성이 아찔해진다.

 class _NotificationScreenState extends State {
   @override
   Widget build(BuildContext context) {
     return Scaffold(
       body: CustomScrollView(
         slivers: [
           const SliverAppBar(
             title: Text("알림"),
             pinned: true,
           ),
           SliverList(
             delegate: SliverChildBuilderDelegate(
               (context, index) => NotificationItemWidget(
                 notification: notificationDummies[index],
                 onTap: () {
                   NotificationDialog([notificationDummies[0], notificationDummies[1]]).show();
                 },
               ),
               childCount: notificationDummies.length,
             ),
           )
         ],
       ),
     );
   }
 }

그럼 이런 구린 가독성 때문에 개발속도에 차질이 생기는 거 아니냐? 할 수 있다.

구글도 그런 점을 인지했는 지 IDE의 Flutter Plug-in을 설치하면 블록의 범위를 볼 수 있도록 주석처리로 도와준다.

그나마 이 부분 때문에 지독한 네스팅이 참을만하다.

아마 이것을 해결할 수 있는 방법은 개선된 코드 구조를 구글이 제시하는 것이 근본적일 것이고, 최대한 작은 단위로 분해해 관리하고 조립해 쓰는 것이 둘째 아닐까 싶다. (아직 공부 초입이라 모르는 게 많다. 공부하자)

---

개발자 편의를 위한 각종 기능들

widget

플러터는 Widget이라고 불리는 클래스 뭉치들을 활용해 손쉽게 개발할 수 있다. 위젯을 통해서 UI도 그리고 스타일링도 하고 그런다. (애초에 플러터는 UI 라이브러리에 가깝다.)

그런데 이런 위젯은 종류도 다양하고 기존의 웹개발 방식(JS +CSS)의 개발에 익숙한 사람이라면 확실히 헤맬 요소가 많다고 생각이 든다. 패딩 위젯 같은 것의 사용이 그러하다. (내가 헤맸다…)(하지만 제공되는 위젯을 통해 또 Material Design 3.0을 활용한 개인화된 디자인을 통해 빠르게 앱을 빌드하기에는 이만한 게 또 없는 듯하다.)

Hot Reload & Hot Restart

Hot Reload나 Hot Restart와 같이 변경점이 생길 때마다 새로 빌드 없이 즉각적으로 확인할 수 있다는 점 역시 꽤 큰 장점으로 생각된다. 물론 RN도 이러한 장점은 어느 정도 공유하지만. 아무튼 웹개발에서 처럼 빠른 변경점 확인을 할 수 있다는 것은 큰 장점이다.

각종 편의

그리고 플러터를 다루면서 정말 편하다고 느낀 기능이 있는데, 위젯에 커서가 가있을 때 옵션 + 엔터 를 누르면 사용가능한 위젯과 에러에 대한 빠른 해결을 제시해주는 기능이었다. 또한 Flutter Outline 같은 기능을 통해 위젯을 빠르게 분리해주는 기능도. 플러터 잘 모르지만 이 기능… 진짜 빠른 개발이 가능하도록 해준다. 사람들이 플러터가 개발 편의성이 좋다고 얘기하는 거 아마 이것들 때문이지 않을까? (아님 말고.)

강력한 Null Safety

Dart 언어의 특징인데 JS처럼 undefined 타입이 없다. 내가 정말 정의하지 않아서 undefined Err가 뜰 순 있어도 undefined가 반환되는 JS같이 동작하지 않는다.

나는 오직 null 정도에 대해서만 생각하면 되는데, 애초에 정적타이핑을 지원하면 null에 대한 null safety 기능들도 지원하기 때문에 타이핑만 잘해두면 JS처럼 골머리 썩힐 일이 없다. (이건 JS의 문제긴 한 듯 ㅋㅎ)

코드푸시

플러터가 올해들어 더 핫한 키워드가 된 이유는 Dart와 Flutter가 3.1 버전까지 올라오면서 많은 편의기능과 이슈들이 해결되서도 있지만, RN에서만 지원하던 코드푸시를 서드파티를 통해서나마 지원하게 됐다는 점이다.

앱의 특성 상 배포 과정에서 드는 비용(시간같은)이 적지 않은데 RN으로 개발을 하면 업데이트마다 앱스토어, 구글스토어 등에 재심사를 하는 과정을 코드 푸시로 효과적이게 제거할 수 있었다. 이 떄문에 RN이 큰 업데이트가 없이도 꾸준한 인기를 얻었는데 플러터 역시 shorebird 라는 라이브러리를 통해 코드푸시를 할 수 있게 되었다. 이를 기점으로 많은 사람들이 플러터에 대해 긍정적인 평가를 내리게 된 것 같다.

플러터에 대한 기대

구글에서 Dart를 선보이면서 JS를 대체하는 웹 개발 언어이자 Mobile App, PC Client, Embedded 등에서도 동작하는 다재다능한 언어로서의 포부를 내비쳤다. JS 생태계가 웹에서 확고해지면서 Dart를 위한 엔진을 크로미움 엔진에 넣는 시도가 좌초되긴 하였으나, 구글에서 말하는 다트/플러터의 미래에는 웹이 중요한 위치를 차지하는 것 같아 웹 프론트엔드 개발자로서 기대가 된다.

skia 엔진을 활용한 렌더링 특성 상 언어를 파싱해서 HTML과 CSS로 변환해 렌더링하는 것이 아닌 Canvas 위에 그림을 그리는 형태로 플러터 웹은 동작하지만, 구글에서도 이에 대한 문제의식을 가지고 있는 것으로 보이고 이를 해결하기 위해 해법을 찾아내고 있으며 발전을 예고한 만큼 AOS, iOS 크로스플랫폼을 위한 개발 프레임워크가 아닌 웹 개발을 위한 프레임워크로서의 미래도 기다려보게 된다.

모두의 걱정처럼 구글이 다트와 플러터를 버리는 일이 없길 바라며 이만 글을 줄인다.