플러터 기술 결정 (getx vs riverpod)

결국 비용을 최소화하기로!

저번 포스팅에서 선택의 기준을
경영자의 관점인 '비용의 최소화'에
두기로 마음먹었다.

하지만 비용을 줄이겠다는 미명하에
모든 것을 포기하겠다는 말은 아니다.

전 포스팅에서도 언급했듯, 어디까지나
내가 원하는 최소한의 결과물은 낼 수
있어야 한다는 조건이 붙는다.

철저하게 비용만을 최소화하려 했다면
플러터가 아닌 RN을 선택했을 것이다.

따라서 내가 원하는 수준의 완성도를
정의하여, 기술 선택의 하한선을 둬야한다.
먼저 내가 내야하는 결과물을 정리해보자.

내가 원하는 수준은 어디까지인가?

1. 기능

• 소셜 로그인
  카카오, 구글, 애플 로그인을 구현할 수 있으면 된다. 자체 서버에서 가입 로직을 구현해 놨으니 정말 화면 정도의 수준이다. 조금 욕심을 내자면 validation이 구현되어 있다면 좋겠다 정도?

• 권한 관리
  원하는 시점에 앱 권한을 제어할 수 있으면 된다. 권한 설정 화면으로 보낼 수 있다면 더할나위 없다.

• 네이버 지도 구현
  그냥 핵심이다. 지도를 단순히 띄울 뿐만아니라, 다중 마커를 찍고 탭했을 때의 로직까지 최대한 커스터마이징이 가능해야한다.

• Push 알림
  혼잡도 공유활동의 주기가 임박했음을 알리는 기능이 필요한데, push를 통해 진동이나 소리를 알릴 수 있어야한다.

• 앱 상단 고정
  앱 내 활동을 할때는 status바에 앱을 고정시켜놓고 계속해서 노출시켜줄 필요가 있다. 이 기능을 플러터에서 제공해줄지 모르겠다..

• Web View
  특정 링크로 보낼 때, 앱 내에서 이탈하지 않고 작업할 수 있도록 web view를 제공해야 한다.

• Google Analytics
  사용자 활동 기록을 데이터화시켜야 하므로, GA의 활용이 좋아야한다.

2. 디자인

• 구글 물빼기
  구글은 참 엄청난 기업이지만 디자인 감성은 쉴드칠수가 없다. 특유의 외국 감성이 진하게 묻어나서.. 물빼는 작업이 가능해야한다.

• 애니메이션 활용
  최근 120Hz의 스마트폰이 많아진 만큼 애니메이션이 끊기면 안된다. 뿐만아니라 트렌디하고 디테일한 애니메이션 표현으로 앱 사용 경험을 극대화 해야한다.

• Swipe refresh, Place holder
  직접 서비스를 만들어보니, 로딩시간이 필요한 경우가 많았다. 로딩시간 그 시간 자체를 줄이는 것도 중요하지만 이 시간을 얼마나 자연스럽게 디자인적으로 풀어내느냐도 중요했었다. 이 때 swipe refresh 기능이나 place holder는 꽤 훌륭한 디자인 도구였다.

이제 정말 결정해보자.

서론이 한세월이었다ㅋㅋㅋ
이제 내가 선택한 것들을 보자.

1. Clean Architecture

이건 이해하기 전까지는 dirty architecture였다가
이해하는 순간 정말 clean architecture가 된다.

체계가 너무나 명확하고 합리적이다.
이미 이러한 아키텍쳐로 이뤄진 수많은 서비스가 있다.

지금까지 해오던 방식이었으니
당장 적응할 시간이 필요 없어 효율적이고,
미래를 보더라도 유지-관리에 용이하다.

완성도는 물론 현재-미래의 비용까지 매우 합리적이다.

2. MVVM 패턴

'사람들이 많이 하는데는 이유가 있다'는
말의 정석이 아닐까 싶다.

물론 아직 다른 MVC나 MVP같은 패턴을 써보지 않아
평가에 신빙성이 없지만..

view와 데이터 로직이 철저하게 분리된다는 점이
최고 장점이 아닐까 싶다.

또한, 이는 의존성을 확실하게 구분하는
clean architecture와 잘맞는 부분이 있어보인다.

3. 상태관리 - Riverpod

상태관리 툴을 정하는데 엄청난 고민을 했다.
jetpack compose나 swiftUI에서는 state를
사용하는 것이 그냥 정답처럼 되어있어
별 고민없이 사용하기만 하면 됐었다.

하지만 플러터에서는
GetX, BLoC, Provider, riverpod등
프로젝트의 규모에 따라, 상황에 따라
각기 다른 라이브러리를 선택해 쓰는 듯 했다.

여기서 어떤 선택을 하는지에 따라
개발 흐름 전체가 바뀐다고 봐도 무방했다.

그래서 2023년 05월 현재를 기준으로
자주 사용되는 위 네가지 툴을 비교해봤다.

먼저 BLoC는 중-대규모 프로젝트에
어울린다는 의견이 대세이다.

물론 체계성, 기능적으로는 최고인듯 하지만
조금 과한 감이 있었다.

초기 러닝 커브가 높은 편이고
boiler plate코드가 많아 생산성에
악영향을 끼친다.

추후 필요에 따라 BLoC로 migration할 수는
있어보이나 당장은 서비스 개발-유지-보수에
들어가는 시간(비용)이 너무 많아질 것 같다.

두번째, Provider는 뒤이어
나올 riverpod가 있어 패스했다.

코틀린을 두고 자바를 선택하거나
스위프트를 두고 objectC를 선택하지 않듯

굳이 개선 버전으로 나온 riverpod를 두고
예전 provider를 택할 필요는 없어보였다.

* Getx vs Riverpod

여기서 했던 고민이야말로 정말 개발자 vs 경영자의
관점차이에서 했던 고민이 아닐까 싶다.

여러가지 항목에서 둘을 비교, 분석했다.

	Getx	Riverpod
이미지
소개	상태관리 / Routing / DI 툴	Provider를 발전시킨 상태 관리 툴
출시	1.0.0 버전 기준 20년 언저리	1.0.0 버전 기준 21년 9월
생산성	간단한 코드만으로도 쉽게 각종 기능 구현 가능 (생산성 최고)	getx에 비해서는 밀리지만 그래도 여러 상태관리 툴중에서는 사용하기 좋은 편
러닝커브	낮다. 쉽게 배워 쓸 수 있는듯 다만 방식이 다르다보니 플러터를 배우는게 아닌 getx를 배우는게 될 수 있다는 평이 많음	getx에 비해서는 높지만, BLoC에 비해서는 낮은 듯
pub.dev 좋아요수 23.05.07	12061	riverpod: 2469 (flutter-riverpod: 1620)
깃허브 star수	8.5k	4.5k
깃허브 issue수	775	118
문서	가독성 떨어지는 편	공식 웹페이지 내에 테스트, 가이드, example이 잘 정리되어있음
성능	큰 차이 없음	큰 차이 없음
패키지 무게	무거운 편(기능이 많음)	getx보다 가벼움
업데이트 주기	최근 11개월간 업데이트 되지 않음	몇 주 간격으로 업데이트
장래성	개인이 관리하는 오픈소스로 후원이 없다면 언제 관리가 끊길지 모름	공홈에서 보면 netlify의 후원을 받는 듯 함
특이사항 / 평가	BuildContext를 관리하지 않음 이로인해 커스터마이징에 한계 존재, 버그 발생 가능성 있음 이 때문인지 평가가 극명하게 나뉨	provider의 개선판으로, provider의 특징을 그대로 가져감. 플러터가 공식적으로 provider를 쓰라고 추천했으므로, riverpod도 인정된 셈

요약하자면,

여러가지 핵심 기능을 한방에 해결해주며
배우기도 쉽고 당장 빠르게 결과물을 낼 수 있는,
하지만 라이브러리의 유지/관리가 잘 안되고
buildcontext로 인한 버그 risk가 있으며
언제 지원이 중단될 지 모르는 GetX

vs

구글이 보증하고 netlify가 후원하는 장래성을 가지고
공식 웹 등에서 트렌디하게 지원해주지만
당장 GetX보다 배울것, 할것이 많아
생산성과 시간 측면에서 밀리는 Riverpod

의 가슴이 웅장해지는 싸움이었다.

여기서는 명확한 비교가 정말 힘들었다.
완성도와 비용으로 봐야하는데,
둘다 애매한 부분이 있었기 때문이다.

1. 비용
   당장 getx를 배워 쓰면 여러 가지를 한번에 해결할 수 있어 시간적으로 riverpod에 앞섬. 하지만 추후 어떤 Buildcontext관련 버그가 발생할지 모르고, 이로 인해 구현할 수 없는 기능이 하나라도 있다면 통째로 바꿔야 하므로 시간적으로 매우 큰 손해가 될 수 있음.

2. 완성도
   위와 비슷한 맥락. 둘의 프레임이나 메모리 상 차이는 거의 없으나 앱을 디테일하게 만져 완성도를 높이고 싶은 만큼, 많은 커스터마이징이 예상됨. 여기에서 getx가 buildcontext 문제로 양보해야 하는 부분이 있다면 완성도에서 riverpod에 비해 떨어질 수 밖에 없음.

결론적으로 build context로 인한 완성도 리스크,
후원이 없는 오픈소스 라이브러리라는 리스크

두 가지를 일종의 비용으로 계산해
riverpod가 낫다는 결론을 내렸다.

getx가 편하다니까 본능적으로 '개발 편의성'을
좇은건 아닐까 하는 스스로에 대한 의심도 한 몫 했다.

이는 어디까지나 직접 경험해보지 않고
검색만으로 비교한 뇌피셜이니
판단은 항상 직접 해보길 바란다.

4. Cupertino Icon

완성도에서 구글 물을 빼고 싶다고 했는데,
이에 따라 자연스럽게 material icon이 아닌
cupertino icon을 택했다.

개인적으로 IOS 디자인이 정말 예쁘다고 본다.

5. DI - Getit

---

23.05.19

개발을 진행하다보니, riverpod 에서 provider를
활용할 수 있는데 이게 있으면 굳이 다른 di툴이
필요가 없다. 고로 사용하지 않게 되었다.

---

Depencency Injection의 경우 직접 구현할 수도 있지만
보통 잘 구현된 라이브러리를 가져다 쓴다.

getx를 썼다면 제공되는걸 쓰면 됐겠지만,
riverpod를 쓰기로 했으니 다른 패키지를 써야만 한다.

검색해본 결과 대부분 get_it을 추천하는 듯 하다.
pub.dev에서도 3000개가 넘는 좋아요가 눌렸다.

사실 그렇게 DI가 무거운 기능이 아니라서
큰 고민이 필요할 정도는 아니다.

6. Routing - go_router

이것 역시 getx를 쓰지 않아 선택한 패키지다.
dart 개발진에서 제공하는 공식 패키지며,
fluro(789), beamer(1026)등 타 패키지에 비해 압도적인
pub.dev 좋아요 수(2771)를 보인다.

7. Permission Handler

권한 관리를 도와주는 툴인듯 하다.
flutter permmision만 검색해봐도
거의 얘를 추천한다.
선택의 여지가 없을 듯 하다.

8. 로컬 저장 - Hive

카페 자리의 경우 서버 의존도가 높은 앱이고,
새로 만들 때에는 그 의존도를 더욱 높일 예정이다.

따라서 로컬 저장소의 역할은 짧은 유효기간을 가지는
refresh token을 저장하거나 오늘 하루 보지않기
정보를 잠깐 저장해주는 정도면 충분하다.

SQLLite와 shared_preference, hive 등이
주로 사용 되는듯 한데,
여러모로 hive를 쓰는게 가장 좋아보인다.
그 이유는 다음과 같다.

• 지원하는 타입이 가장 많음
  (DateTime같은거 대충 저장때리면 됨)
• benchmark 점수가 가장 좋음
  (별 의미는 없지만 기왕이면 빠른게 낫지)
• 사용법이 비교적 쉬움
  (NoSQL 기반 key-value 형태)

9. Http통신 - http

통신 라이브러리는 http와 dio 양대산맥으로 보였다.
여기서는 http를 선택했는데, 그 이유는 명확하다.

1. dio는 http보다 좀더 가공된 형태로 보였다. 하지만 나는 서버 통신에 한해서, 날것의 그대로를 쓰는 것을 선호한다. 통신 로직을 쓰다보면 데이터의 형태가 다양해 서비스에 맞게 커스터마이징할 일이 많아지는데, 사용하기 편하라고 미리 만들어준 라이브러리 일수록 이부분에서 어려움을 느낄때가 많았다. 그래서 swift에서도 almofire가 아닌 urlsession을 고집했었다. (근데 왜 ktor썼지)

2. http는 dart 공식 개발팀이 지원해주며 근소하지만 pub.dev 좋아요 수가 앞서 있었다.

10. Url - url_launcher

이 패키지를 통해 전화앱, 메일앱, 설정화면 등
내가 원하는 앱 화면으로 이동시킬 수 있을듯 하다.
이건 굳이 뭘 선택할 것은 아니고 필요하면 쓰는거 같다.

11. 네이버 지도 - flutter_naver_map

사실 가장 걱정되는 부분이다.
벌써 좋아요 3000개를 넘게 받고있는
google map flutter에 비해,

naver map 패키지는 23년 5월 7일 현재 기준
불과 한달전에 1.0.0 버전이 공식 릴리즈 되었다.
(작년쯤엔 플러터앱에 네이버 지도를 쓰는게
굉장히 제한됐었다는 말..)

그나마 나는 1.0.0 버전이 릴리즈 되고
null safty도 지원되니 양반이지만,
그래도 아직 좋아요 40개 정도의
검증되지 않은 패키지니 실제 프로덕트에
넣는게 맞을까 싶은 것이다.

12. Etc

카카오 로그인, 구글 로그인, 애플 로그인 패키지 모두
있는것을 확인했고, webview, firebase, 향상된 animation
패키지 등등 거의 모든게 있다.

왜 플러터로 구현 못하는 앱기능이 거의 없다고
수많은 사람들이 당당하게 말했는지 알 것 같다ㅋㅋㅋ

이제 건물을 지을 자재가 모두 주어진 셈

앱을 만드는 것을 건물을 짓는것에 비유한다면,
이제 어떤 재료로 무슨 기둥을 써서
몇 층짜리 집을 지을지 모두 정했다.

또한 건물의 설계도를 작성하기위한
펜과 종이까지 전부 구비한 셈이다.

이제 그냥 주어진 펜으로 설계도를
그리기만 하면되고, 다 그리면 그대로
짓기만 하면 된다.

문법 공부를 하고, 어떤 기술/라이브러리를
쓸지 결정하는 것만으로 벌써 일주일이 넘는
시간을 썼다. (물론 서류업무도 같이 했지만)

"시작이 반이다" 라는 말처럼 정말
반절을 끝낸 기분이다.