들어가며 배달의민족 주문접수 채널은 파트너의 주문 관리를 돕기 위해 매일 수백만 건의 주문을 실시간으로 처리하며, 다양한 디바이스를 지원하고 있습니다. 점차 다양해지는 디바이스 생태계에 대응하고자, 신규 제품에 Flutter + Clean Architecture를 선택했고, 나아가 비즈니스 요구사항에 더 빠르게 대응하기 위해 웹뷰 기반 컨테이너 앱(App Shell)으로 전환까지 진행 중입니다. 이 글에서는 Flutter 도입 과정과 아키텍처 설계 경험을 공유합니다. […]
The post 배달의민족 주문접수 채널에 Flutter를 도입하며 고민한 것 first appeared on 우아한형제들 기술블로그. || 들어가며
배달의민족 주문접수 채널은 파트너의 주문 관리를 돕기 위해 매일 수백만 건의 주문을 실시간으로 처리하며, 다양한 디바이스를 지원하고 있습니다.
점차 다양해지는 디바이스 생태계에 대응하고자, 신규 제품에 Flutter + Clean Architecture를 선택했고, 나아가 비즈니스 요구사항에 더 빠르게 대응하기 위해 웹뷰 기반 컨테이너 앱(App Shell)으로 전환까지 진행 중입니다.
이 글에서는 Flutter 도입 과정과 아키텍처 설계 경험을 공유합니다.
1. 왜 Flutter였나?
비즈니스 관점의 멀티 플랫폼
늘어나는 플랫폼 요구사항
최근까지 Windows, Android 모바일, iOS 세 가지 플랫폼을 지원하고 있었지만, 다양한 디바이스에서 주문을 관리하고 싶다는 파트너 요구가 커져 플랫폼 확장이 필요했습니다.
macOS 데스크톱: Mac 디바이스로 주문을 관리하고 싶은 요청 증가
Android 태블릿/POS: Windows POS에서 Android 기반 디바이스로 전환 추세
향후 확장성: 신규 디바이스 지원 및 접수 채널 통합 대비
개발 생산성과 비용
기존에는 Windows, Android 모바일, iOS 각 플랫폼별로 주문접수 채널을 개발해야 했고, 하나의 기능을 추가하려면 각 플랫폼에 맞춰 반복 구현해야 했습니다.
현재는 Android 태블릿/POS와 macOS 버전을 Flutter로 운영 중이며, Windows와 모바일 플랫폼(Android 모바일, iOS)은 점진적으로 전환하고 있습니다.
Flutter 도입으로 현재까지 확인된 효과는 다음과 같습니다.
인력 절감: Android와 macOS 각각 별도의 개발자가 필요했지만, Flutter 개발자가 두 플랫폼을 담당합니다.
개발 속도 향상: 한 번의 구현으로 멀티 플랫폼에 동시 배포할 수 있게 되었습니다.
유지보수 효율성
버그 수정이나 기능 변경 시에도 한 번의 수정으로 모든 플랫폼에 반영됩니다. 플랫폼 간 동기화 이슈가 줄어들고, 동일한 기능과 UX를 제공할 수 있습니다.
일관된 사용자 경험
파트너님들에게 동일한 UX를 제공할 수 있습니다. 이는 학습 비용을 줄이고, OS별 다른 UI로 인한 혼란을 줄일 수 있습니다.
저희의 선택
장기적으로 Windows, Android, iOS, macOS 4개 플랫폼을 모두 지원해야 하는 상황에서 생산성을 확보하려면 단일 코드베이스가 필수적이었습니다. 이 조건을 만족하면서 성숙한 생태계를 갖춘 프레임워크는 Flutter가 유일했고, 저희에게 적합한 선택이었습니다.
Flutter의 한계와 해결: "Write Once, Adapt Everywhere"
플랫폼 차이의 현실
처음에는 코드 하나로 모든 플랫폼을 동일하게 지원할 수 있을 것이라, 즉, "Write Once, Run Everywhere"를 기대했지만, 실제로는 플랫폼마다 주변기기 제어, 권한 시스템, 알림 방식, 업데이트 등 메커니즘이 다른 부분들이 존재합니다. 저희 경험상 "Write Once, Adapt Everywhere"에 가깝다고 느꼈습니다.
예를 들어 앱 업데이트 하나를 구현하더라도 각 플랫폼마다 다른 방식이 필요했습니다.
Android: Google Play In-App Update API
macOS: Sparkl