30일간의 flutter 앱 개발

지난 30일동안 이전에 안드로이드로 만들었던 앱을 flutter로 새로 만들었다. 바로 성경앱이다. 이 앱은 2012년 1월에 안드로이드앱으로 만들어서 2014년까지 유지보수를 했었다. 당시 안드로이드에서는 제대로 된 ebook 리더도, 쓸만한 성경앱도 없었기 때문에 안드로이드 개발 연습도 할 겸 필요한 앱도 만들겸 만들었던 것 같다.

성경 - Google Play 앱

안드로이드 폰을 사용하면서 이 앱을 잘 사용하다가 아이폰을 사용하기 시작하면서 점점 이앱을 사용하지 않게 되었다. 이북으로 만들어서 아이북으로 열어보니 앱만큼이나 편하고 좋았다. 그와는 별개로 어쩐 일인지 이 앱은 많은 사람들이 사용하는 앱이 되었다. 2014년 부터 더이상 업데이트 하지 않았음에도 3000명 정도가 사용하고 있었다.

다시 안드로이드를 사용하면서 자연스럽게 구글 플레이북을 통해서 이북으로 성경을 보게 되었다. 근데... 아이북이 어찌나 대단한지 구글 이북리더는 너무 불편했다. 책도 아니고 디지털 컨텐츠도 아닌 이상한 느낌이었다. 그래서 결국 뭔가 더 편한 성경책을 또 찾게 되었다. 그러다보니 이 앱으로 다시 돌아오게 되었다.

근데 이 앱은 더이상 내 폰에서 동작하지 않았다. 그간 너무 오래된 기술이라며 업데이트를 하라는 안내메일을 받고도 무시한 벌을 받는 것일까? 물론 이전에도 db를 asset에서 앱영역으로 복사하는 과정이 좀 이상하긴 했는데 아예 아무런 내용도 나오질 않았다. 그래서 그런지 사용자도 1900명으로 쪼그라들어 있었다.

flutter도 공부해볼겸 나의 불편도 해결할 겸. 이 성경앱을 업데이트 해보기로 했다.

개발 시작

flutter는 1.0이 나온 작년에 이미 개발의 맛을 본 적이 있다. 발표자료와 애니메이션, ci 툴 등 이미 모든 것을 갖춘 상태에서 나온 느낌이라 굉장히 매력적이었고 무엇보다 네이티브에 뒤지지 않는 속도, 편리한 개발도구 제공등이 너무 맘에 들었다. react-native같은 경우는 속도를 떠나서 개발도구가 너무 별로였다. 빌드가 안되는 일이 너무 많았다.

flutter는 막히는 부분이 없었다. 하라는대로 하니 바로 앱이 동작했고 수정하면 즉시 반영(hot reload)되는 것도 너무 좋았다. 거의 전용언어느낌인 Dart도 생각보다 빨리 학습한데다 state 유무로 구분되는 두 종류의 Widget으로 모든 UI를 만드는 것도 이해하기 쉬웠다. 오랜동안 React로 개발을 해서 쉽게 느끼는 것 같기도 하다. 3일정도 투자해서 나름 쓸만한 수준의 티스토리 에디터 모바일 버전을 만들 수 있을 정도였다.

성경앱을 만들기로 한 시점에는 flutter가 무려 1.7 버전이 되어 있었다. api문제로 앱을 실제로 출시하지는 못했지만 다행히 조금만 수정하니 1.0에서 만든 앱이 잘 동작했다. flutter의 업데이트보다도 하루 공부해서 익힌 Dart문법을 몽땅 잊어버린 것이 진짜 문제였다. 다시 시작하는 마음으로 공부를 해야했다.

UI

flutter의 모든 UI는 widget이다. state가 있는 widget, 없는 widget. state가 있다는 것은 변경가능한 데이터를 가지고 있다는 말이다. 변경되는 값에 따라 UI를 바꿀 필요가 있을때 사용한다. 물론 글로벌 앱 state를 관리한다면 StatelessWidget만으로 모든 UI를 만들 수도 있을 것이다. 나는 flutter-redux를 사용해서 글로벌 state를 관리했다.

디자인도 전체를 맘대로 만들 수 있지만 기본적으로 material 디자인과 cupertino 디자인을 제공한다. cupertino UI는 사용해본 적이 없지만 material 디자인은 react로도 많이 해봤다. 그래서 material 을 사용해 UI를 만드는데 좀 더 쉽게 할 수 있었던 것 같다. 아이콘 이름도 대략 알고 있고....

좀 더 아름다운 디자인을 만들 수 있으면 좋겠지만 그런 센스는 없는지라 지금은 완전히 material design에 의존하고 있다.

Data

성경앱은 DB가 필요하다. 버전, 책, 장, 절로 구분된 데이터를 묶어서 보여줘야 하고 검색도 가능해야하기 때문이다. 이전 앱에서도 sqlite를 사용했었는데 flutter에서도 sqflite를 사용하니 이전 앱의 db를 그대로 사용할 수 있었다. 모두 DB를 사용해도 되지만 설정같은 경우는 별도의 환경설정 data를 사용하고 싶었다. 찾아보니 shared_preferences가 괜찮은 것 같아 사용했다.

이런 모듈들은 비동기로 동작하도록 설계되었다. 네트웍을 사용하는 것도 마찬가지겠지만 이런 모듈을 사용하면 자연스레 async, await를 사용하거나 then 류의 체이닝에 익숙해지게 된다. 더불어 widget의 rendering 라이프 사이클에도 익숙해지게 되는 것 같다.

배포

애플 앱스토어는 어떻게 배포하는지 잘 모르지만 안드로이드는 별 거 없다. apk 만들어서 업로드 하는 것이 배포의 전부다. 요새는 app bundle이라는 걸 하도록 유도하는 것 같기는 한데 key 관리가 달라지기 때문에 전환하지는 않았지만 flutter는 명령어 하나로 apk, app bundle 모두를 지원한다.

Github Action도 사용할 수 있는 마당에 CI/CD도 한번 알아봤다. 공식적으로 제안하는 것은 fastlane이라는 도구다. app build, screenshot, change log, beta release, crashlitics 같은 것들을 설정만 하면 바로 다 해준다. 제대로만 동작한다면 너무너무 매력적인 도구다.

그런데 여기에 문제가 있다. 앞서 말했듯이 안드로이드 앱배포는 빌드해서 업로드로 끝이다. 이걸 좀 더 편하게 해보겠다고 fastlane의 설정을 일일이 하는 것이 오히려 번거로운 느낌이었다. 그리고 fastlane이 제공하는 screenshot, change log는 자동으로 만들 성격의 데이터가 아니라는 생각이다. 사용자에게 어필할 수 있는 영역이라 이건 자동으로 하기보다는 수동으로 하는 것이 좋을 것 같다.

물론 설정에 실패해서 더 부정적으로 말하는 것일 수도 있지만 성공사례라고 하는 글을 봤는데도 딱히 성공으로 보이지 않았다.

 

---

 

30일간이라고 했지만 퇴근하고 애 재우고 요리하고 남는 시간에 개발한 거라 실제로 개발한 건 몇시간 되지도 않는다. 여기까지 오는데 소요된 총 일수가 30일이라는 거다. 이것은 업무로 한다면 아마 3-4일 걸릴 것 같다. 뭐 어쨌든 우여곡절 끝에 pure 안드로이드로 개발했던 앱을 flutter로 재작성해서 출시했다. 지금까지는 있던 기능 재구현이었지만 이젠 좀 더 개선을 해봐야겠다. UI는 기능이든.