시작하며
Info
이번 포스팅에서는 강의에서 배운 Flutter로 모바일 청첩장을 제작했던 과정이 머릿속에서 완전히 지워지기 전에 짧게나마 기록으로 남기고자 한다. 바로 본론으로 들어가겠다.
개발 과정
1. 개발환경
Flutter Web으로 개발하였고, IDE 툴은 Android Studio, 배포는 Firebase (hosting, realtime-database, file-storage)에 git-action을 통한 자동 배포 파이프라인을 구성했다. Firebase가 GCP를 기반으로 동작하다 보니 자연스럽게 Google Analytics도 함께 적용해보았다.
2. 개발하면서 마주한 포인트들
아무래도 Flutter를 처음 공부하는 입장에서, Flutter의 화려한 부분만을 보고 너무 만만하게 생각했던 탓인지 고생을 꽤 했다. 아래 포인트들은 개발하면서 직면한 다양한 부분들이다.
3. 의외의 생각할 점
-
이미지 로딩 최적화 이미지 사이즈와 로딩: FirebaseStorage에서 이미지를 로딩할 때, 이미지 크기가 너무 크면 로딩 시간이 길어지고 메모리 사용량도 많아지니, 서버 측에서 이미지 크기를 줄이거나 적절한 사이즈로 리사이즈해서 저장해야 한다. 이미지 캐싱: 매번 네트워크 요청을 하는 대신 캐싱 전략을 사용한다. Flutter에서는 CachedNetworkImage 패키지를 이용해 이미지를 캐시할 수 있어서, 네트워크 로드를 줄이고 성능을 높일 수 있다.
-
초기 로딩 성능 향상 비동기 작업 최적화: Firebase.initializeApp()과 이미지 로드를 main()에서 동시에 처리하고 있다면, 이 작업들을 비동기적으로 잘 처리하되, 사용자에게 불필요한 지연이 생기지 않도록 로딩 인디케이터나 초기 화면을 통해 상태를 명확히 표시해야 한다.
-
위젯 트리 최적화 불필요한 MaterialApp 인스턴스 제거: InvitationScreen 위젯에서 새로운 MaterialApp을 반환할 필요가 없으니, 대신 Scaffold를 직접 반환해 불필요한 위젯 계층을 줄여야 한다. 이렇게 하면 렌더링 성능이 좋아질 수 있다.
-
조건부 빌드 최적화: isLoading 상태에 따라 전체 앱을 다시 빌드하는 것보다, 로딩 상태를 다루는 작은 위젯을 사용하는 게 좋다.
-
디버깅 플래그 관리: main.dart에 설정된 디버그 플래그(debugProfileBuildsEnabled 등)는 개발 중에만 사용하고, 프로덕션 빌드에서는 비활성화해야 한다.
이 방법으로 이미지 캐싱 + CDN, 비동기 최적화를 진행했는데 큰 차이가 없어 아래 추가 작업도 진행했다.
-
초기 컨텐츠 최적화 최소 UI 로드: 애플리케이션 시작 시 최소한의 UI 요소만 로드하고, 필요한 데이터와 리소스는 백그라운드에서 로드하도록 한다. 예를 들어, 로고나 간단한 인트로 화면을 먼저 보여주고, 나머지 부분은 데이터가 준비되면 동적으로 로드할 수 있다.
-
스켈레톤 스크린: 실제 컨텐츠가 로드되기 전에 스켈레톤 스크린을 보여줘서 사용자에게 로드 중임을 알리고, 대기 시간을 덜 느끼게 할 수 있다.
-
모듈화 및 지연 로딩: Flutter에서는 코드를 모듈화하고 필요할 때만 해당 모듈을 로드할 수 있도록 지연 로딩을 구현해야 한다.
-
에셋 프리로드: 애플리케이션 시작 시 필요한 이미지, 폰트 등의 리소스를 미리 로드하고 캐시에 저장한다. precacheImage, precachePicture 같은 Flutter 기능을 사용하여 구현할 수 있다.
-
캐싱 전략: 웹에서 Flutter 앱을 실행할 때, 서비스 워커와 적극적인 캐싱 전략을 사용해 필요한 자산을 캐시하고 네트워크 요청을 최소화해야 한다. PWA(Progressive Web App) 구성의 일부로 구현할 수 있다.
-
성능 분석 도구 사용: Flutter의 Performance view, Chrome DevTools, Lighthouse 등을 사용해 성능 문제를 식별하고 분석해야 한다.
정리하며
쉽지 않은 도전이었으나 그만큼 뜻깊고 재밌었던 시간이었다.