백엔드 개발자를 위한 네이티브 모바일 앱의 특징

모바일 앱이 가진 고유한 특징은 뒷단의 백엔드 개발에도 영향을 미칩니다. 이러한 특징들은 웹 기반 서비스에 익숙한 백엔드 개발자들이 쉽게 놓칠 수 있는데요. 

 

많은 앱들이 웹뷰 형태로 네이티브와 웹을 결합한 형태로 구성되어 있으나, 그렇기에 더욱 네이티브 앱의 특징을 명확하게 인지하지 못하는 경우도 발생합니다.

 

이번 글에서는 Building Mobile Apps at Scale [1]의 내용을 중심으로, 백엔드 개발과 관련 깊은 네이티브 모바일 앱의 특징들을 알아보겠습니다.

 

---

모바일 앱은 바이너리가 스토어(구글플레이 또는 앱스토어)를 통해 업로드 되고, 유저가 모바일 기기에 다운로드 받아 설치되며 배포됩니다. 이러한 모바일 앱의 환경이 모바일 앱 개발과 네이티브 앱이 사용하는 백엔드 API 개발에 영향을 미칩니다.

 

'설치형'이다

상태관리

모바일 앱 또한 웹 또는 백엔드와 같이 여러 복잡한 문제들이 상태관리에서 발생합니다. 대부분 이벤트 기반으로 변경되는 앱의 상태관리는 웹과 유사하게 Reactive Programming 형태로 발전해왔습니다. 하지만 웹 또는 백엔드와 달리, 앱은 아래와 같은 이슈들을 마주하게 됩니다:

 

• 작고 제한된 성능의 모바일에서 만약 앱이 과도한 리소스를 사용한다면, OS는 매우 짧은 노티만 주고 앱을 kill하게 됩니다. 이러한 앱 상태 변화에 반응하여 앱은 상태를 저장하고, 재시작 시 상태를 복원할 수 있어야 합니다.
• 권한, 연결 상태, 블루투스 상태 등 다양한 글로벌 앱 상태가 존재하고, 앱의 컴포넌트들은 watch하고 있는 상태에 따라 다르게 반응하여야 합니다. 글로벌 앱 상태를 처리하는 핸들러의 구현 방식에 따라 부하를 주거나, 코드의 복잡도가 올라가거나, tight-coupling이 생기는 등의 trade-off가 발생할 수 있습니다.
• 앱의 기존 상태와 Deeplink와 같은 앱의 특정 화면에 대한 직접적인 접근이 맞물리면서, 상태관리의 leak이나 예상치 못한 상태 등이  발생할 수 있습니다.

 

바이너리는 모바일 기기에 존재하고 실행된다

애플과 구글은 앱에 송신되는 실행가능한 코드를 허용하는 부분에 대해서 매우 엄격한 기준을 가지고 있습니다 (일부 버그 픽스 같은 경우  CodePush [3]와 같이 허용된 우회적 방법이 가능하나). 또한, 앱을 스토어에 배포하기 위해서는 24 - 48 시간 정도가 소요됩니다. 그리고 그렇게 스토어에 배포되었더라도 사용자는 최신 버젼으로 업데이트하기까지 오랜 시간이 걸리고, 항상 유저가 최신 버전의 앱을 사용한다는 보장도 할 수 없습니다 (강제 업데이트를 하더라도). 

 

즉, 한 번 배포된 앱을 수정하여 사용자의 기기에서 업데이트되기까지가 오래걸리고, 어렵고, 불가능할 수도 있습니다. 그렇기에 애초에 꼼꼼히 테스트하여 실수 없이 배포하고, Feature Flag Strategy [2]를 통해 특정 기능을 켜거나 끌 수 있도록 하거나, 최대한 강제 업데이트를 완전하게 지원하는 등의 대책이 필요합니다. 이는 작성한 코드 뿐만 아니라, 그러한 코드가 의존하고 있는 3rd party SDK나 라이브러리도 포함됩니다.

 

하지만 "모든 최신 버젼 배포 시 최대한 완전한 강제 업데이트를 하고 이전 버젼을 지원하지 않는다"가 정책이 아니라면, 하위버젼이 사용하는 백엔드 API도 하위호환을 지원해야 합니다.

 

그렇기에 백엔드도 최대한 초기에 기존 버젼 하위호환에 대한 지원과 그것을 위한 API 디자인, 모니터링 및 폐기 전략 등이 고려되어야 합니다. 최소한 관련해 어떠한 정보도 얻을 수 없기에, 어떠한 액션도 취할 수 없는 상황은 피할 수 있도록 해야 합니다.

 

바이너리 사이즈가 영향을 준다

앱 사이즈는 앱 설치 conversion rate에 영향을 줍니다 [4]. 특히, 이머징 마켓(인도, 브라질 등)에서 그러한 특징이 두드러지는데요. 그렇기에 여러 글로벌 앱들은 기능을 축소하고 사이즈를 줄인, lite 버젼을 제공하고 있습니다.

 

 

다양한 모바일 기기와 구글과 애플에 영향을 받는 OS 환경에서 실행된다

다양한 환경의 지원과 모니터링

앱이 실행되는 모바일 기기는 종류가 다양합니다. 모바일 기기는 다양한 지역, 장소, 조건에서 사용됩니다 (예, 외곽 이동중). 또한, 그러한 모바일 기기에서 실행되는 OS는 빠르게 진화하고 있습니다. 모바일 기기가 다양한 용도에 쓰이는 만큼 여러 종류의 칩이 들어가고, 여러 기능(블루투스, 카메라, 통화 등등)과 관련된 인터랙션이 존재합니다. 

 

모든 조건을 다 지원할 수 없기에, 앱은 지원할 수 있는 타겟을 명확히 범주화하고, 그러한 범주에서 오래된 기기나 OS 버젼에서 앱이 정상적으로 작동하는지 테스트해야 합니다. 그리고 피할 수 없이 발생하는 버그나 오류를 모니터링하고 디버그 [5]할 수 있도록 모바일 기기 상에서 발생하는 충분한 정보가 개발자에게 전달 될 수 있도록 해야 합니다. 

 

Image from [5]

 

다양한 네트워크 조건에서 사용되는 모바일 앱이기에, offline support도 고려되어야 합니다. 일시적인 네트워크 연결 끊김으로 인한 부부은 retry를 고려하거나, 그러한 상황에서의 상태 처리도 생각해볼 수 있습니다.

 

Deeplink

앱의 특정 부분에 직접 접근하도록 하는 딥링크는 이해는 쉬우나, 여러가지 조건과 맞물리면 매우 복잡하고 까다로울 수 있습니다 [6]. 그러한 조건들로는 아래와 같은 사항들이 존재합니다:

 

• 하위호환: 위에서 살펴본 하위호환은 딥링크에서도 해당됩니다. 예로, 마케팅으로 배포되었던 딥링크는 새로운 버젼 출시 이후에도 동작해야 합니다.
• 다양한 진입점: 딥링크를 통해 사파이 브라우저, 다른 앱(Notes, 문자 등), 해당 앱 내, Push notification 등 다양한 진입점에서 접근 가능합니다. 또한, 이는 아래에서 언급될 상태와 함께 고려되어야 합니다.
• 상태: 실행되는 앱의 상태와 딥링크로 인한 진입이 정상적으로 상호작용하는지 고려되어야 합니다. 기존 상태가 초기화되어야 할지, 보존되어야 할지 그로 인해 예상치 못한 상태로 앱이 crash가 발생하지는 않는지 생각해보아야 합니다.
• iOS와 Android의 구현의 차이

 

iOS와 Android이 제공하는 것들

이 점에서는 크게 2가지, Push & Background notification과 In-App Purchase가 존재합니다.

 

 

Push & Background notification

iOS와 Android 모두 각각 APNS와 FCM을 통해 Push notification을 지원합니다. Push notification을 보내는 부분은 백엔드에서 진행되기에, 어떻게 보낼지, 보낸 notification을 클릭 시 어떤 형태로 동작할지 등과 관련해 백엔드와 많은 커뮤니케이션이 필요하게 됩니다. 보통 통합된 도구를 사용해 비교적 간단히 설정할 수 있으나, 아래와 같은 이슈가 발생할 수 있습니다:

 

• 딥링크와 유사하게 메시지의 액션이 어떤 형태로 동작하여 앱에 접근하게 될지, 하위호환은 어떻게 처리할지 등에 대한 고려가 필요합니다.
• 유저가 notification을 끄고 킬 수 있습니다 (background notification과 같은 예외를 제외하면).
• Push nofitication의 전달이 보장되지 않습니다. 중간 전달자인 애플과 구글이 throttling하는 경우도 있으며, 기기의 연결 이슈가 존재할 수도 있습니다. 그리고 애플과 구글은 관련한 구조나 전달과 관련된 정보를 제공하지 않고 blackbox 형태로 제공하고 있습니다.
• 테스팅이 어렵습니다. 

하지만 위와 같은 이슈에도 Push notification은 여전히 유저 진입 통로, 마케팅, 정보제공 등의 목적에 유용하며 Background notification [7, 8]과 같은 기능은 백엔드의 변경사항을 앱에 전달하기 위한 목적으로도 사용될 수 있습니다.

 

In-App Purchase

앱 상에서 디지털 상품을 판매하는 경우 IAP를 통하지 않고 우회하여 판매하기는 여러모로(우회를 찾거나 또는 그 여파를 감당하기가) 쉽지 않습니다. 

 

어쩔 수 없이 IAP를 진행하더라도 고비용의 수수료와 iOS & Android의 각기 다른 정책과 제약(가격 변경, 매출 파악, 회계처리 등의 어려움 등), IAP 유저와 백엔드 회원계와의 매핑 등의 구조적 한계를 감수해야 합니다. 

 

구현 이후에 테스트와 운영 시에도 위와 같은 복잡한 구조로 인해 어렵습니다. 특히 금액과 관련된 예민한 사항이기에, CS와 관련한 준비가 필수적입니다.

 

 

 

 

Reference

[1] Building Mobile Apps at Scale, Gergely Orosz

[2] https://www.uber.com/en-KR/blog/piranha/

[3] https://learn.microsoft.com/en-us/appcenter/distribution/codepush/

[4] https://medium.com/googleplaydev/shrinking-apks-growing-installs-5d3fcba23ce2

[5] https://www.datadoghq.com/monitoring/mobile-application-monitoring/

[6] https://albertodebortoli.com/2019/04/16/deep-linking-at-scale-on-ios/

[7] https://firebase.google.com/docs/cloud-messaging/concept-options#data_messages

[8] https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/pushing_background_updates_to_your_app