[Flutter] 서버개발자의 첫 앱 배포 수난기

서버 혹은 웹만 개발하던 내가

처음으로 개인적인 앱을 출시해봤다.

 

아래는 앱 다운로드 링크다.

https://play.google.com/store/apps/details?id=com.jnot.rojjealbum 

로쩨앨범 - Google Play 앱

 

- 선결론

결론만 먼저 말해보자면
재밌는 경험이었고, 계속 경험중이다.
앱은 에러도 많고
기능도 충분치 않지만
출시해봤다는데 의의를 둔다.
이 앱을 만들게 된 목적도 있기 때문에
조금씩이지만 에러도 수정해 나가고 있다.

출시자체는 안드로이드만 진행했다.
ios는 개인 폰이 아이폰이라서 로컬 빌드로 진행했다.
구글스토어와 달리 애플 앱스토어는 매년 돈을 내야해서 출시를 안한건 아니다.(사실맞다)

앱을 개발하는 내내
서버에서 데이터를 줬으면 하는 마음이 굴뚝 같았다.
어찌보면 이번 기회에 프론트,앱 개발자분들의 마음을 조금은 헤아릴수 있게되었다고 할까.

사실 이게 누군가에게 도움이 되는 글이라기보단
내가 나중에 보고 이랬었지를 기억하려고 써본다.

 

- 기술스택

기본적으로 Flutter + Firebase를 사용하여 개발을 진행했다.

사용한 dependency들

firebase storage

firebase cloud firestore

firebase authentication

kakao login

google admob

 

 

- 진행

첫 기획과 크게 벗어나게 개발되진 않았다.

약한소리지만

아직 flutter에 대한 이해도 부족하거니와

기능적인 면을 광범위하게 고려하다보면 끝이 없을것 같아서

최소한의 기능으로 되는대로 출시했다.

 

- 트러블슈팅

1. 무한스크롤

사실 시작부터 난관이었다.

flutter 공식홈페이지에 예제가 나와있을 정도로 무한스크롤(infinite scrol)은 간단했다.

다만 나는 grid 모양으로 사진이 나오게 하는 화면을 원했고

그 사진들은 firebase를 통해 가져와서 뿌려지게 하고싶었다.

 

flutter 접근 자체를 회사 내에서 작은 스터리를 통해서 찍먹 해본것이 다이기 때문에

future 라거나 builder 같은 것들의 이해가 모자랐다.

뿐만 아니라

내가 직접 서버를 개발할때와는 다르게

firebase에서 data를 받아서 뿌려주는 부분도 쉽게 해결하진 못했다.

 

2. cached image

사진들을 불러와서 잘 뿌려주기는 했는데

다른화면을 갔다오면 이미지를 다시 보여주는데 시간이 꽤나걸렸다.

이때 당시 network image로 image url을 불러왔었다.

cached network image 로 바꿔주면서 조금은 나아진 것 같았다.

 

3. kakao login

사용자 관리를 최소화 하기 위해서

로그인은 카카오로그인만 넣으려고 했다.

개발 과정에서는 전혀 문제가 없었는데

앱을 출시하려고 검토요청을 했는데 내 계정을 전달했음에도

계속 로그인이 안된다고 리젝이 나는 상황이었다.

 

3.1

해외에서 카카오 로그인을 할 경우, 내가 해외로그인을 제한 걸어둔것이 문제인가 싶어서

해당부분을 해제하고 재검토를 했지만 여전히 리젝을 받았다.

3.2

firebase authentication

결국 안되겠다 싶어서 이메일 로그인을 개발하게 되었다.

firebase에서 제공하는 사용자 인증을 적용해서 재검토 요청했고 승인이 났다.

역시 해외라서 카카오 로그인이 문제였나? 했다.

 

** 3.3

앱을 출시하고 나서 카카오 로그인을 시도했는데, 웬걸?

내가해도 카카오 로그인이 안되는 것이다.

뭐가 문제인가 찾다보니

카카오 로그인 해시키가 개발용과 릴리즈용이 따로 제공되어야했었다.

뭐하나 쉬운게 없다.

 

***4. memory leak

출시하고 앱을 테스트해보는데

사진을 불러오다가 어느순간엔가 앱이 꺼져버린다?

 

에러를 추적해보니 memory leak이 발생해서 앱이 꺼져버린것이다.

 

깊게 파지않고 되는대로 개발을 진행하다보니 전혀 신경쓰지 않던 부분에서 문제가 발생했다.

어떤부분을 고쳐야할지 감도 안잡혔다.

 

우선적으로

flutter memory 관리로 검색하여

가능한 부분들을 고쳐나갔다.

최대한 build에 복잡한 연산을 두지않고,

const를 선언해주거나,

setState를 남발하지 않는.

 

출시까지는 setState로만 상태를 관리했다.

물론 getx와 provider를 사용하면 수월하다는 것을 알고 있었지만

간단한 앱이기도 하고 packege를 쓰지않고도 할 수 있지 않을까 싶었다.

 

결과적으론 앱출시에 무리는 없었지만 memory 이슈 때문에

provider를 적용해보게 되었다.

 

써보니 확실히 widget간 데이터를 전달할때나

setState를 그때그때 호출하는것 보다

훨씬 유용한걸 깨달았다.

(이래서 사람은 고생을 해봐야하는건가)

 

 

후기

잡는다고 잡고있지만 사실 아직도 memory 누수로 인한 앱꺼짐은 잡지 못했다.

이것저것 넣는다고 넣어봤는데 어느 부분에서 잘못 개발하고 있는지 잘 모르겠다. 물어볼사람도 없고 흑흑..

계속 찾아봐야겠다.

 

그 외에 자동로그인, flutter storage, splash 화면 등

간단한 사진앱 하나 만들면서도 이것저것 역경이 많았던것 같다.

 

그래도 재밌는 경험이었고

경험중이다.

사람들이 취미로 개발을 한다고 할 때 나는 믿지 않았다.

나는 좀더 효율적으로 일하기 위해,

최신 기술스택을 배우기 위해,

공부하고 시도했기 때문에 취미 혹은 재미로 개발을 한다는게 와닿지 않았었다.

 

근데 이번 프로젝트를 통해서

취미로 개발을 한다는게 이런기분일까 싶었다.