[Flutter] 플러터 앱 배포 후기

안녕하세요. 지스 입니다.

 

드디어 2024/08/08 기준 저희 회사의 신규 앱이 런칭 되었습니다!!!! 와!! 정말 이게 되나 했는데 됐네요 ... ^^

 

개발인원은 총 4명이며, 2명 2명씩 안드로이드 개발자, iOS 개발자였습니다. 저는 iOS 개발을 하고 있었구요..ㅎ

 

개발 기간은 2024.01 ~ 2024.03 까지는 다트언어와 플러터에 대한 공부를 진행하였습니다. 

 

4월 부터는 본격적으로 기획자 분과 디자이너분들, 백엔드 개발자와 회의를 주로 진행하였고 4월 말부터 본격적인 개발을 들어가게 되었습니다.

 

정말 마지막까지는 QA와 개발을 동시에 하느라 야근도 정말 많이 했고, 출시 기간이 3일정도 밀리는 일도 있었습니다.

 

그럼에도 모두들 고생을 많이 하셔서 배포를 할 수 있게 되었는데요!

 

이쯤에서 제가 느꼈던 후기를 한번 쓰고 싶어..그냥 주절주절 의식의 흐름대로 한번 글을 써보려고 합니다.. 두서가 없어도 양해 부탁드려요.

---

 

저는 iOS 개발을 쭉 공부해왔고, 이미 Swift언어를 주력으로 쓰는 상태였습니다.

다만 회사 입사 후에는 Objective-C 언어로 된 앱을 Swift로 바꾸면서 옵젝씨도 많이 건드렸고,,

실제 기획이 들어올때 옵젝씨로 개발한 일 도 있었습니다.

 

이미 옵젝씨와 스위프트에 적응한 저로써는 새로운 언어를 배우는데 회의적이긴 했습니다. Swift를 좀 더 집중적으로 파도 모자랄 시간이라고 생각 했기 때문입니다.

 

그리고 굳이 안드 개발자 iOS개발자가 따로 있는데 굳이 플러터로 하는게 더 개발속도가 느리지 않나 싶기도 했구요 (새롭게 공부를 또 해야 하니)

 

그리고 퍼포먼스가 네이티브처럼 나올까? 라는 불신도 있었습니다.

다만 이 불신은 공식 사이트에서 60, 120 fps를 보장한다는 글이 있어서 안심했습니다!

Flutter Docs

---

 

지금까지 공부를 시작함과 있어서 배포까지의 기억을 되살려 Dart Flutter의 장단점을 정리해보자면.. 아래와 같습니다.

 

장점

• SwiftUI처럼 선언형 UI를 사용하기 때문에 UI만드는 부분이 익숙해지면 굉장히 빠르다.(저는 Swift UiKit을 쓰고 개발을 했던 사람이라 더 체감할 수 있었습니다.)
• 언어가 null Safety를 지원하기 때문에 안전하게 null 처리가 가능하다.
• 비동기 작업을 async await로 쉽게 사용 할 수 있다.
• 메모리 관리를 가비지컬렉터가 하기 때문에 메모리에 대한 신경 쓸 필요가 거의 없다.
• 꾸준한 업데이트가 진행되고 있어 배울게 점점 더 많아 지는게 좋다.(죽은 언어가 아닌)
• 사실 완전 새롭게 나온 언어와 프레임워크가 아니기 때문에 구글링을 했을때 웬만한 정보는 나오게 된다.
• Hot Reload는 신이다. 개발속도 200% 업!

단점

• 클래스 밖에 없기 때문에 값복사를 하는게 까다롭고 귀찮다.
• 값복사 때문에 코드 제네레이터 같은 툴을 사용하게 되고(build runner) 파일이 많아 지면 많아 질 수록 파일 생성이 오래 걸리게 된다.
• 데이터 파싱이 귀찮다.
• 한개의 언어와 프레임워크로 멀티 플랫폼을 지원하지만, 깊게 갈 수록 분기를 쳐야할 상황이나 같은 코드에 iOS와 AOS동작이 다른 경우가 있다. 이에따라 의도하지 않는 동작이 나타 날 수 있다.
• 복잡한 Widget일 수록 괄호지옥에 빠지게 된다. 내가 짠건 괜찮지만 남이 짠 코드를 보기가 쉽지않다.
• Enum을 사용할때 case마다 Enum.EnumType 이렇게 써주는게 굉장히 불편하다.(Swift는 컴파일러가 타입추론을 하여 .Type으로 사용할 수 있다)

 

하지만 단점을 차치하고도 분명 빠르다는건 부정할 수 없는 사실이기 때문에 저희는 플러터로 신규 앱을 개발하기로 합니다.

 

저희 앱 아키텍처는 클린 아키텍처를 구현하고, DI Tool은 GetIt과 Injectable을 쓰게 되었습니다.

구조를 간단히 보여드리자면

packages
 ┣ common
 ┣ data
 ┣ domain
 ┣ presentation
 ┣ util

 

패키지 안에 각자의 모듈로 정의를 해 두어 역활 분담을 정확히 하도록 하였습니다.

이 부분은 제가 블로그에도 잠깐 글을 쓰긴 했었는데, 나중에 추가적으로 자세히 쓰도록 하겠습니다.

 

이렇게 틀을 잡고 본격적으로 개발을 시작하였는데요. 개발 도중 난감했던 부분을 좀 써보려고 합니다..!

 

디자이너들이 원하는 디자인 맞춰주기

사실 플러터의 기본 Material3 디자인을 사용하는게 개발자들 입장에서는 가장 편하겠지만,, 디자이너가 원하는 부분도 충분히 들어줘야 한다고 생각하기 때문에 일단 충분히 회의를 많이 했던 것 같아요. 된다 안된다, 안해봐서 모르겠다, 한번 해보겠다. 이런게 사실 시간은 많이 들어가지만 꼭 해야되는 거라고 생각합니다.

근데 막상 회의를 해보니 Material3를 사용할 수 있는게 몇개 없더라구요.

예를 들어 TextField를 사용하더라도 제가 커스텀을 무조건 해야 되는 상황,,

사실 이 부분은 플러터로 처음하다보니 많이 삽질을 했고, 개발 종료 시점까지 디자이너 분들과 회의를 계속하면서 안되는 것들에 대한 수정을 같이 진행하였습니다.

그래도 디자이너 분들이 저희의 사정을 알고 1px오차까지 안봐준다! 이런 스텐스는 아니셔가지고 다행히... 무사 배포를 했던 것 같습니다.

(사실 맞춰주는게 맞다고 생각하지만 ㅠ)

 

기획이 계속 바뀐다...!

이거는 어쩔 수 없다고 생각합니다. 개발을 하다보면 엇 이게 안되네.. 아니면 어 이럴땐 어떻게 하지? 라는 생각으로 기획팀과 얘기를 하다보면 기획이 바뀌는 경우가 있으니깐요..!

사실 마지막에 정신이 많이 없었지만 다행히 기획팀에서도 안되는 부분 쿨하게 수정해주셔서 기간내에 배포 할 수 있었던 것 같습니다.

 

테스트 코드가 깨진다.

이것은 TodoList로 남겨 둔 것인데요. QA를 함과 새로운 기능이 추가되면서 부터 저희가 초기에 썼던 테스트 코드가 깨지는 현상이 나타났습니다. 사실 바로바로 깨지는 케이스에 대한 수정을 해야 되는데 변명아닌 변명으로 시간이 없다는 핑계와 함께 테스트 코드가 깨지는 채로 계속 작업을 하고 배포까지 진행하였습니다.

그래서 이번달 안에 테스트 케이스를 다시 짜서 에러가 안나는 채로 배포할 예정 입니다. 다음번에 개발할때는 꼭 테스트 코드도 수정하면서 기능 추가 수정을 하고 싶네요..!

 

상태관리 Provider..애증..

처음 개발시에는 Provider가 굉장히 편했습니다. 다만 점점 프로젝트가 커지고 Provider가 갯수가 많이 짐에 따라 컨트롤이 굉장히 어렵다는걸 느꼈어요. Provider가 계속 생성되야 하는지 아니면 싱글턴으로 써야하는지 생각을 해야 하고, 그에따라 코드도 다르게 작성해줘야 된다는게 귀찮았습니다.

저는 Provider를 최대한 잘개 쪼개서 사용했는데 이게 나중에 같이 사용할 일이 있으면 ProxyProvider를 쓰게 되는데, 의도치 않는 동작이 많이 일어 나더라구요. 예를들어 한 Provider의 한개의 프로퍼티만 감지하면 ProxyProvider가 업데이트 되게 하고 싶은데 그게 안되고 무조건 notity가 되면 ProxyProvider가 업데이트가 되는,, 그런 상황,, ㅠㅠ

그리고 context.read나 watch가 안되어 Exception이 나는 경우가 많죠. 이거는 큰 문제라고 생각됩니다. 개발 속도를 현저히 떨어트리는 것 같아요.

저는 그래서 다음에는 riverpod을 사용해볼까 합니다. Bloc은 제가 느끼기에 상태 관리 라이브러리가 아니고, 상태관리를 어떻게 하면 좋을지에 대한 방안같이 느껴져서..ㅎㅎ 이미 프로젝트에 Bloc처럼 abstract class를 활용한 API Result를 사용하고 있기도 하구요!

---

 

저에게 다음에도 또 플러터로 앱 개발할래 라고 묻는다면

저는 매력있는 언어라 또 다시 도전 할 것 같습니다.ㅎㅎ 단점도 많지만 그에 따른 장점도 확실하단걸 깨달았거든요!

확실히 매력있는 언어와 프레임워크라고 생각됩니다..ㅎㅎ 과연 iOS Native로 했을때 기간내에 할 수 있었을까? 라는 생각도 들긴하구요!

 

그럼 오늘은 글을 줄이겠습니다. 감사합니다 ^^