오늘 (3월 31일), GetX 가 pub.dev에서 최고 like 수가 많은 패키지가 되었다.

내가 like 몇 백 일때 부터 사용했던 플러그인이 불과 1~2년만에 이렇게 성장해서 기쁘다. (당시에는 비슷한 이름, 기능의 플러그인인 get_it 보다도 like가 낮았다.)

앞으로도 2위와 격차는 점점 벌어질 것이다.

코드 무단 표절이나 라이크 수 조작 같은 여러 논란들이 있지만 그런 이야기는 여기서는 할 필요가 없을 것 같다.

GetX

GetX의 최대 장점은 편의성이다. 바꿔 말하면 플러터의 귀찮은 것들을 한꺼번에 해결 해준다.

context로 부터 해방. 간편한 문법. 큰 사용자 커뮤니티. pubspec.yaml 에 의존성 라인이 짧아지고, 

문서도 깔끔하게 정리되어 있는 편이다.

주변을 보면 사용할 때의 만족도도 상당히 높았다.

초보자가 상태 관리를 처음 시작할 때 provider보다도 접근하기가 편하고, 한 번에 많은 기능을 얻게 된다는 점에서 추천할 만하다.

GetX를 사용하는 이유는 마치 플러터로 처음 앱 개발을 시작하는 이유와 비슷해 보인다.

안드로이드, iOS 뿐만 아니라 일상적으로 접하게 되는 거의 모든 플랫폼에서 사용 가능한 앱을 한꺼번에 개발하는 것.

Get 광신도

나는 플러터도 좋아하고, GetX도 좋아하고 실 서비스 개발에서도 사용하고 있다.

하지만 광신도들이 생겨나고 있는 것 같아서 안타깝다.

이 광신도들의 주장은 이거다.

어차피 플러터랑 GetX로 다 되는데 다른거 왜 함?

사실 이게 완전히 허무맹랑한 소리였다면 자연스럽게 정화되었겠지만,

플러터와 GetX가 정말로 만능에 가까운 걸출한 툴 들이기 때문에 이 논리가 먹혀들어간다. 

특히, 플러터를 시작한 지 얼마 안된 사람들이 Provider 쓸까요? GetX 쓸까요? 물으면 광신도들이 저 주장을 하는데,

이걸 반박하기에는 해야 할 말이 많고, 사실 실제로 웬만한 프로젝트에서는 GetX로 충분하고, KISS 원리에 의해서 단순함이 아주 큰 미덕이기 때문에

결국 결론이 GetX 무조건! 최고! 로 끝나게 된다. 어설프게 반박하다가는 "GetX 안 써보고 또 저러네..." 이런 소리 듣기 십상이다.

국밥을 좋아하는 그 분들이 생각난다.

놀랍게도 레딧이나 플러터 공식 디스코드에서도 허구하면 riverpod vs Get 대결이 벌어진다.

빠가 까를 만든다고 했던가... 나는 열렬한 GetX 비밀신도이지만, 저런 광신도들은 너무 싫다. 무조건적으로 GetX가 옳다고 주장하기 때문에 건전한 토론을 못하게 하고 순수한 입문자들을 또 다시 광신도로 만든다. 

반대로 무조건 GetX는 싫다고 하는 사람들(Get 혐오자) 도 너무 싫다.

우린 모든 것에 장단점이 있다는 것을 인정하고, 필요한 곳에 알맞는 도구를 이용해서 만들어야 한다.

장점은 굳이 여기서 더 설명할 필요 없이 써보면 알게 되므로 한계점만 말하겠다.

Get의 한계

GetX의 단점은 여러 가지가 있다. Cargo Cult 프로그래밍 을 하지 않으려면 사용하는 도구의 세부적인 구현을 알거나

최소한 한계점 정도는 명확히 알고 있어야 한다.

GetX/lib

GetX는 지원하는 기능이 많다. GetX라는  모노레포 안에 저런 패키지들이 다 들어가 있다. 

그렇게 위대한 코드가 들어있는 것은 아니다. Stream와 Rx를 알고 기본적인 다트와 플러터에 대한 지식이 있다면 내부 코드를 쉽게 분석할 수 있는 수준이다. 

많은 이슈

ecosystem 자체가 크기 때문에 이슈가 많이 발생하게 된다.

이슈가 많은 만큼 PR도 많지만 결국 개인이 관리하는 레포기 때문에 PR 리뷰를 혼자하게 된다.

이렇게 반론할 수 있다. 기능이 많은 만큼 당연히 이슈도 많은거 아닌가?

맞는 말이다. 그러면 일단 이슈가 많다는 것과 이슈 처리가 상대적으로 늦다는 것을 인정하는 셈이다.

모노레포

개인적으로 GetX에 대해서 가장 아쉬운 점은 레포를 분리했으면 어땠을까 하는 것이다. 선택적으로 필요한 만큼 쓰는 거면 Get 혐오자들이 지금보다 많이 줄었을 것이다. 어차피 미들웨어들인데 분리하려면 충분히 분리할 수 있었을 것이다.

지금은 get을 통으로 flutter pub get 해오는 방법 밖에 없다. pub에서 get을 가져온 다음에 import 할때는 기능 별로 분리해서 import 하는 것은 가능하다.

모노레포라서 좋아하는 사람들도 있으니 취향에 맡긴다.

Get Storage

Get_storage 라는 Get 생태계의 key-value 저장소 패키지가 있는데 광신도들은 벤치마크 그래프만 보고 hive 왜 쓰냐고 우리 GS는 너무 빨라서 await도 필요없다~~ 이러는데 문서를 볼 때 그림 말고 글도 읽을 필요가 있다.

논란의 벤치마크

거기 바로 밑의 문단에 레포 주인이 직접 GS는 데이터베이스가 아니라고 Hive나 Sqflite 쓰라고 해놨다.