양대 스토어에 Flutter 앱을 동시에 출시할 때 아무도 말해주지 않는 것들

Flutter 배포에 관한 대부분의 가이드는 실제 압박감 속에서 작업을 수행해 본 적이 없는 사람들이 작성한 것입니다. 그들은 체크리스트를 제공하지만, 혼돈의 과정은 생략합니다. 그러니 제가 첫 양대 스토어 출시 때 허비했던 3일을 여러분은 아낄 수 있도록 도와드리겠습니다.

Flutter는 크로스 플랫폼 (Cross-platform) 개발에 진정으로 훌륭합니다. 하나의 코드베이스 (Codebase)로 두 개의 앱을 만드는 것 — 그 부분은 실제로 작동합니다. 하지만 같은 날 App Store와 Google Play에 배포하려고 시도하는 순간, 여러분은 두 스토어가 단순히 다른 플랫폼이 아니라는 것을 깨닫게 됩니다. 그들은 서로 다른 정부, 서로 다른 타임라인, 그리고 매우 다른 기분을 가진 서로 다른 행성입니다.

리뷰 타임라인은 전혀 비슷하지 않습니다

Apple은 시간을 들입니다. Google은 더 빠르며, 때로는 의심스러울 정도로 빠릅니다. 하지만 아무도 경고해주지 않는 사실이 있습니다. 두 리뷰가 같은 기간 내에 완료되더라도, 앱이 라이브 (Live) 상태가 되는 시간은 다를 수 있다는 점입니다. 이는 조율된 마케팅 추진, 예정된 보도 자료, 또는 실행 준비가 된 소셜 캠페인이 있는 경우 매우 중요합니다. 여러분은 타겟 오디언스의 절반이 오직 한쪽 스토어에만 존재하는 앱을 다운로드하려고 시도하는 상황을 맞이하며 잠에서 깨어날 수도 있습니다.

해결책은 무엇일까요? 최소 3~4일 전에 Apple에 먼저 제출하십시오. Play Console을 건드리기 전에 Apple 리뷰가 진행되도록 만드세요. 그리고 Android에서는 "출시일 설정 (Set a release date)" 옵션을 사용하여 Apple이 따라잡을 때까지 Play Store 출시를 보류할 수 있습니다.

빌드 번호는 조용한 함정입니다

Flutter는 version: 1.0.0+1과 같이 설정하는 단일 pubspec.yaml 파일을 사용합니다. 여기서 + 뒤의 숫자가 빌드 번호 (Build number)입니다. 문제는 여기에 있습니다. Apple과 Google 모두 이 번호를 사용하지만, 이를 해석하는 방식이 다르며 번호를 재사용하거나 건너뛸 수 있는 규칙도 다릅니다.

디버깅을 하는 동안 빌드 번호를 올리고 한쪽 스토어에만 푸시하면, 내부 버전 관리 (Versioning)가 동기화되지 않는 상태에 빠질 수 있습니다. 한쪽 스토어에는 빌드 14가 있고, 다른 쪽에는 빌드 11이 있습니다. QA 팀은 테스트 기기에서 빌드 12를 보고 있습니다. 무엇이 라이브 상태인지 아무도 모르게 됩니다.

간단한 버전 로그 (Version log)를 유지하십시오. 지루한 조언이지만, 절대적으로 필요합니다.

App Store Connect와 Play Console 모두 당신을 거절할 것입니다 - 단지 이유가 다를 뿐입니다

Apple은 개인정보 처리방침 (privacy policy) 문제, Info.plist 내 권한 설명 (permission descriptions) 누락, 또는 픽셀 크기가 잘못된 스크린샷을 이유로 앱에 플래그를 지정할 것입니다. Google은 타겟 API 레벨 (target API level) 준수 여부, 데이터 보안 양식 (data safety form) 누락, 또는 업데이트를 잊은 광고 관련 선언 (declaration about ads)을 이유로 플래그를 지정할 것입니다.

문제는 이렇습니다. Apple의 거절 사유를 수정하는 데 하루를 꼬박 쓰고 나서, 완전히 별개의 이유로 Google의 거절을 당할 수 있습니다. 각 스토어로부터 최소 한 차례의 거절을 받을 것을 계획하십시오. 당신의 앱이 나쁘기 때문이 아닙니다. 단지 두 스토어 모두 각자의 관료주의가 존재하며, 원할 때 움직이는 속도가 느리기 때문입니다.

iOS와 Android에서 권한 (Permissions)은 다르게 동작합니다

카메라, 위치, 또는 알림을 처리하는 Flutter 플러그인 (plugins)은 각 플랫폼에 대해 별도의 권한 처리를 요구합니다. Android에서는 AndroidManifest.xml에 권한을 선언합니다. iOS에서는 Info.plist에 사용 설명 문자열 (usage description strings)을 추가합니다. 하나라도 놓치면 앱이 충돌하거나 거절됩니다.

더 미묘한 문제는 런타임 동작 (runtime behavior)입니다. Android는 여러 권한을 순차적으로 요청할 수 있습니다. iOS는 하나를 요청하며, 사용자가 이를 거부하면 사용자가 직접 설정 (Settings)으로 들어가지 않는 한 다시 기회를 얻을 수 없습니다. 만약 당신의 온보딩 흐름 (onboarding flow)이 하나의 플랫폼만을 염두에 두고 설계되었다면, 다른 플랫폼에서는 제대로 작동하지 않는 것처럼 느껴질 것입니다.

아직 실제 기기에서 테스트하고 있지 않다면, 모든 것을 멈추십시오

시뮬레이터 (Simulators)와 에뮬레이터 (emulators)는 초기 개발 단계에서는 유용합니다. 하지만 출시를 하기에는 충분하지 않습니다. 화면 렌더링 (Screen rendering), 글꼴 스케일링 (font scaling), 제스처 동작 (gesture behavior), 키보드 겹침 (keyboard overlaps) 등은 모두 실제 하드웨어에서 다르게 동작합니다. 최소한 하나 이상의 저사양 Android 기기에서 구체적으로 테스트하십시오. Flutter는 플래그십 폰에서는 아름답게 작동합니다. 하지만 위젯 리빌드 (widget rebuilds)를 최적화하지 않았다면 중사양 Android에서는 버벅거릴 수 있습니다.

감당하기 벅차다면 - 실제로 이 과정을 경험해 본 Flutter 개발자를 고용하십시오

이 과정을 혼자서 수행하는 것이 무의미해지는 지점이 있습니다. 이는 Flutter가 어렵기 때문이 아닙니다. 두 개의 스토어 제출을 조정하고, 거절 사이클 (rejection cycles)을 관리하며, 플랫폼별 버그를 처리하고, 동시에 코드베이스 (codebase)를 깨끗하게 유지하는 일은 출시 주간 동안 진정으로 풀타임 업무 (full-time job)가 되기 때문입니다.

만약 당신이 그 지점에 와 있다면, 단순히 Flutter 앱을 개별적으로 만들어 본 사람이 아니라, 실제 양대 스토어 출시 경험이 있는 Flutter 개발자를 고용하십시오. 그 차이는 상당합니다. 두 스토어 모두에 앱을 출시해 본 개발자들은 지뢰가 어디에 있는지 밟기 전에 이미 알고 있습니다. 그들은 이미 그 3일이라는 시간을 허비해 보았기에, 당신은 그럴 필요가 없습니다.

마지막으로 한 가지

마케팅 출시 일정을 앱 제출일과 같은 날로 잡지 마십시오. 승인이 예상되는 날로부터 2주 뒤로 일정을 잡으십시오. 그 완충 기간 (buffer)을 활용하십시오. 당신은 거의 확실히 그 기간이 필요할 것입니다.