- 이 포스트는 원티드랩 안드로이드 개발자 지도현 님이 리뷰해 주셨습니다.
Best Practice on Android Instant Apps
원티드 안드로이드앱은 최근 플레이스토어에서 ‘Try Now’기능이 활성화 되었습니다. Instant App 기능을 활용하여 사용자는 설치 없이 네이티브 앱의 기능을 그대로 경험해 보고, 설치와 회원가입을 유도할 수 있게 되었습니다.
원티드 서비스는 서비스 특성상 많은 사람들이 웹에서 가볍게 방문하여 채용정보를 보고 떠나는 사람이 많습니다. 그리고 공유된 채용정보는 페이스북이나 카카오 등 인앱브라우저에서 자주 표현되는데, 이럴 경우 사용자 경험이 좋지 않습니다. 많은 개발사들은 모바일 웹 보다는 네이티브 앱에서 사용자에게 좀 더 좋은 경험을 제공한다는 것을 알고 있으며, 모바일 웹페이지보다 모바일 앱에서 Retension 비율이 더 높은 등 네이티브 앱이 많은 장점을 갖고 있다는 사실을 알고 있습니다.
URL링크를 공유하여 앱에서 실행할 경우에는 웹페이지를 통하여 서비스를 이용할 수 있게 됩니다. 하지만 웹에서는 사용자에게 좀 더 편리한 사용환경을 제공할 수 없습니다. 만약 앱이 앱스토어에 등록되어 있으면? 보통 앱스토어의 설치 가능한 페이지로 이동하게 됩니다.
| URL을 공유받은 사용자 | 웹페이지 이동 | 앱 설치화면 이동됨 |
|---|---|---|
 |
 |
 |
Deep Link 라는 기능으로 바로 네이티브 앱에서 서비스를 바로 사용할 수 있게 할 수는 있습니다만, 여전히 사용자들 대다수는 우리의 앱을 설치하고 사용하지 않고 있습니다.
| 딥 링크 선택 시 | 앱으로 이동됨 | 앱 설치화면 이동됨 |
|---|---|---|
 |
 |
 |
이런 경우 앱스토어의 설치 가능한 페이지로 이동시켜주어 사용자에게 설치하고, 다운로드를 기다리게하고, 설치완료를 한 뒤에 앱을 오픈해보고, 만약 그와중에 원하는 실행 화면이 아닐 경우에는 선택했던 Deep Link를 다시 선택하는 귀찮은 일을 해야합니다.
Instant App은 2016년 Google I/O에서 처음 소개되고, Google I/O 2017에서 정식으로 공개되었습니다. 가장 핵심은 Without Installation, 즉 설치없이 네티이브앱의 사용 경험을 제공할 수 있다는 부분입니다. 아직 Instant App을 모르시는 분들은 Progressive Web App과 혼동하실 수 있습니다. Instant App은 일반 앱과 똑같이 Android SDK로 만들어지는 Native App입니다. (Java, Kotlin, JVM위에서 돌아갑니다.)
Instant App 의 목표
Google I/O 소개에서는 우선적으로 핵심기능을 전반에 배치하여 실제 앱을 사용하고, 회원가입까지 유도하는 전환률 증가에 가장 초점이 맞추어져있다고 소개하고있습니다. 그리고 사용자로 하여금 웹과 앱의 장벽, 즉 URL로 시작해서 앱으로 도달하는 수많은 과정을 줄여 App-First 의 경험을 높일 수 있습니다. (스토어 이동하고, 설치하고, 다운로드 대기하고, 완료되고, 서비스 이용의 기나긴 UX…) 마지막으로, 기존에는 없던 Use Case를 만들 수 있다고 소개합니다.
예를들어, 박물관에 갔다고 가정해 봅니다. 만약 작품별 안내를 받기 위해 앱을 설치해야 한다면? 아마 사용자는 일단 싫어하고, 사용 후 바로 삭제할 것입니다. 그런데 작품마다 NFC태그나 QR코드가 있다고 가정한다면, NFC나 QR코드는 URL을 담을 수 있습니다. 그 URL을 이용하여 인스턴트 앱이 실행된다면? 더 이상 앱은 반드시 설치해야 되는 개념이 아니게 됩니다. 새로운 Use Case들을 만들어 낼 수 있는 도구가 될 것입니다.
개발 환경
구글 I/O에서는 위의 4가지 준비물이 필요하다고 하고있습니다. 하지만 전부 Android Studio 에 있으니까, 아래 한가지만 체크하세요. Instant Apps SDK !!
Build Config
기본적인 환경 설정은 어렵지 않으므로 생략하겠습니다. 중요한 것은 빌드 환경 구성은 아래와 같이 두 가지로 만듭니다 - 일반 앱, 인스턴트 앱
안드로이드 프로젝트는 아마 대부분 app 이라는 모듈 하나에 모든 작업이 이루어 질 것으로 예상됩니다. 하지만 Instant App 구동을 위해서는 App에 들어있는 코드에 대하여 구조변경이 필요합니다.
프로젝트 구조 변경
Google I/O 에서 제시한 프로젝트 구조의 Before/After 입니다. 몇 가지 feature로 구성되던 일반 APK에서, base feature module이라는 것을 가진 프로젝트가 됩니다.
먼저 base feature의 build.gradle 설정 방법 입니다. 맨 위 apply plugin: ‘com.android.feature’ 부분이 기존과 약간 다릅니다. 그리고 또 한가지는 baseFeature 속성을 true 로 해주면 됩니다. 그리고 dependencies 에 중요한 작업이 있습니다. 이 base feature 를 이용하는 다른 모듈을 명시(feature project)하는 것과 apk 프로젝트를 명시하는 것(application project) 입니다. 주의하실 점은 feature-base 모듈은 최대한 작으면서 필수적인 것들만 포함하여야 합니다. 이유는 뒤에서 설명하겠습니다.
이제 feature-ia 의 build.gradle 을 확인해 봅니다. base 가 아닌 기능을 가진 feature module 입니다. 맨 위 apply plugin: ‘com.android.feature’ 부분은 동일하고, dependencies는 base feature module 를 implements 해줍니다. 나머지는 늘 하던대로 필요한 라이브러리를 추가합니다.
feature-ia 의 AndroidManifest.xml 입니다. 기본적인 Deep Link 실행방식과 유사하게 intent-filter를 설정하면 됩니다. 단, meta-data 의 default-url 은 꼭 있어야 합니다. 만약에 default-url 이 빠진 경우에는 예상치 못한 화면으로 landing 처리될 수 있습니다.
위에서 말하는 Installable APK을 생성하는 모듈입니다. 평상시처럼 개발하면 되니까 넘어가겠습니다.
Instant App APKs 를 생성하는 모듈의 build.gradle 입니다. 맨 위 apply plugin: ‘com.android.instantapp’ 부분이 일반 앱 과는 조금 차이가 있습니다. 이 모듈은 소스를 포함하지 않고, build.gradle 에서 Instant App 이 수행해야 하는 feature 들만 명시해 줍니다. Instant App의 결과물은 여러 apk가 묶여진 zip 파일입니다.
인스턴트앱을 위해 추가된 API
인스턴트앱을 위해 추가된 API는 InstantApps 라는 클래스가 있으며, 여기서는 위에 캡쳐한 몇 가지 유용한 함수를 제공합니다. 현재 동작하는 프로세스가 Instant App 인지 체크하는 함수와 앱 내에서 설치하기를 수행해 주는 함수가 전부입니다 !!
라이브러리 호환
경험상, 그리고 개발 과정에서 확인한 내용에 따르면 널리 사용되는 몇 가지 라이브러리는 사용이 어렵습니다. 인스턴트앱을 개발하면서 확인한 사용 가능 / 불가능 라이브러리를 정리해 보았습니다.
| 사용 가능 | 사용 불가능 |
|---|---|
| Firebase Analytics Kotlin + Android Extension (최신버전) Fabric (최신버전) Glide Retrofit ReactiveX RXBinding Timber JUnit Mockito |
ButterKnife GreenDAO |
출시 방법
| 메뉴 | 등록 화면 |
|---|---|
 |
 |
일반 앱과 거의 유사합니다. Play Store Console에 올리면 됩니다. 결과물이 zip파일이라는 점이 다릅니다.
특이한 점은 모바일 Holdback 설정기능이 있습니다. 0과 1사이의 값을 설정하면 그 비율만큼 사용자에게 배포가 가능한데요, 0일 경우에는 전체를 인스턴트 앱으로 출시, 1일 경우에는 딥링크 혹은 웹으로만 사용 가능합니다. (단계적 출시와 유사)
Play Store Console 에서는 일반 앱의 경우 알파, 베타, 프로덕션 출시라는 표현을 사용하지만, Instant App의 경우 개발, 사전출시, 프로덕션이라는 표현을 사용합니다. 그리고 프로덕션 출시가 아니라면 특별히 용량 제한이 없어보였습니다. 약 10MB 정도까지 실제 업로드가 가능했습니다. 하지만 실제 프로덕션으로 등록할 때에는 4MB 를 넘기면 안됩니다. 확인해본 결과 이는 개발자들의 편의를 위한 플레이스토어 정책이라고 합니다. (언제 정책이 수정될 지는 모르겠습니다.)
그리고 base feature 가 최소화 되어야 한다고 하였는데요, proguard 적용 시 base feature module 는 proguard 가 되지 않는것을 경험적으로 알게 되었습니다. 다른 모듈에서 minify 되면서 사라진 코드에 엑세스 되지 않는 현상이 있었는데요, 이 부분은 개발 과정중에 혹시 잘못한 부분이 없는 지 좀 더 확인하고 있는 부분입니다.
얼마나 걸릴까 ?
Google I/O 2017 에서는 평균 6주 정도 소요된다고 얘기합니다. 케이스에 따라 다르겠지만, 인스턴트 앱만 진행한다면 이에 동의합니다.
사실 초기 개발시에는 atom 이라는 구조였는데, 지금보다 상대적으로 복잡한 구조였습니다. 그에 비하면 정말 편해졌습니다.
아직 부족한 점
원티드 인스턴트앱 개발을 하면서 몇 가지 추가적으로 적용하면 좋았을 법한것들을 정리해 보았습니다. 먼저 Google Smart Lock 기능을 한번 제대로 활용해 보면 어떨까 생각해봤습니다. 기존 이메일/패스워드 형태의 로그인을 사용하는 서비스라면 해볼만 합니다. 인스턴트앱에서 로그인/회원가입 기능을 제공하고 smart lock 에 저장해둔 뒤, 일반 앱 설치 후 smart lock 을 이용해 즉시 같은 로그인 정보로 자동 로그인을 시켜준다면 사용자에게 경험적으로 베스트하게 서비스를 제공할 수 있지 않을까 생각해봅니다. 그리고 PostInstallIntent 를 활용한다면 일반 앱이 설치 완료되었을 때, 설치된 앱의 특정 Activity를 실행 시킬 수 있습니다. 인스턴트 앱에서 보던 화면(Activity)을 그대로 유지하면서 자연스럽게 설치된 앱의 실행 화면(Activity)으로 처리가 가능합니다.
마치며
인스턴트앱은 사용자가 설치 없이 직접 사용해보고 설치를 할 수 있다는 점에서 전환률에 많은 도움이 될 것으로 기대하고 있으며, 다양한 실험을 해 볼 수 있을 것으로 생각됩니다. 또, 위에서 말한 것 처럼 확인해보지 못한 부분들도 많으며 새로운 Use case를 만들어 낼 수 있다는 장점이 있습니다. 앞으로 원티드에서도 이 인스턴트앱 기능을 적극 활용할 예정이니 관심있게 지켜봐주시면 감사하겠습니다.
