블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

파이어베이스 애널러틱스를 이용한 모바일 데이타 분석 #1-Hello Firebase

조대협 (http://bcho.tistory.com)


얼마전에 구글은 모바일 백앤드 플랫폼인 파이어베이스를 인수하고 이를 서비스로 공개하였다.

파이어 베이스는 모바일 백앤드의 종합 솔루션으로, 크래쉬 리포팅, 리모트 컨피그를 이용한 A/B 테스팅 플랫폼, 클라우드와 자동 동기화가 가능한 리얼타임 데이타 베이스, 사용자 인증 기능, 강력한 푸쉬 플랫폼 다양한 모바일 기기에 대해서 테스트를 해볼 수 있는 테스트랩 등, 모바일 앱 개발에 필요한 모든 서비스를 제공해주는 종합 패키지와 같은 플랫폼이라고 보면 된다. 안드로이드 뿐만 아니라 iOS까지 지원하여 모든 모바일 앱 개발에 공통적으로 사용할 수 있다.



그중에서 파이어베이스 애널러틱스 (Firebase analytics)는 모바일 부분은 모바일 앱에 대한 모든 이벤트를 수집 및 분석하여 자동으로 대쉬 보드를 통하여 분석을 가능하게 해준다.


이 글에서는 파이어베이스 전체 제품군중에서 파이어베이스 애널러틱스에 대해서 수회에 걸쳐서 설명을 하고자 한다.


파이어베이스 애널러틱스

이미 시장에는 모바일 앱에 대한 데이타 분석이 가능한 유료 또는 무료 제품이 많다.

대표적으로 야후의 flurry, 트위터 fabric, 구글 애널러틱스등이 대표적인 제품군인데, 그렇다면 파이어베이스가 애널러틱스가 가지고 있는 장단점은 무엇인가?


퍼널 분석 및 코호트 분석 지원

파이어베이스 애널러틱스는 데이타 분석 방법중에 퍼넬 분석과 코호트 분석을 지원한다.

퍼널 분석은 한글로 깔데기 분석이라고 하는데, 예를 들어 사용자가 가입한 후에, 쇼핑몰의 상품 정보를 보고  주문 및 결재를 하는 단계 까지 각 단계별로 사용자가 이탈하게 된다. 이 구조를 그려보면 깔데기 모양이 되는데,사용자 가입에서 부터 최종 목표인 주문 결재까지 이루도록 단계별로 이탈율을 분석하여 서비스를 개선하고, 이탈율을 줄이는데 사용할 수 있다.

코호트 분석은 데이타를 집단으로 나누어서 분석하는 방법으로 일일 사용자 데이타 (DAU:Daily Active User)그래프가 있을때, 일일 사용자가 연령별로 어떻게 분포가 되는지등을 나눠서 분석하여 데이타를 조금 더 세밀하게 분석할 수 있는 방법이다.


이러한 코호트 분석과 퍼넬 분석은 모바일 데이타 분석 플랫폼 중에서 일부만 지원하는데, 파이어베이스 애널러틱스는 퍼넬과 코호트 분석을 기본적으로 제공하고 있으며, 특히 코호트 분석으로 많이 사용되는 사용자 잔존율 (Retention 분석)의 경우 별다른 설정 없이도 기본으로 제공하고 있다.


<그림. 구글 파이어베이스의 사용자 잔존율 코호트 분석 차트>

출처 : https://support.google.com/firebase/answer/6317510?hl=en

무제한 앱 및 무제한 사용자 무료 지원

이러한 모바일 서비스 분석 서비스의 경우 사용자 수나 수집할 수 있는 이벤트 수나 사용할 수 있는 앱수에 제약이 있는데, 파이어베이스 애널러틱스의 경우에는 제약이 없다.

빅쿼리 연계 지원

가장 강력한 기능중의 하나이자, 이 글에서 주로 다루고자 하는 내용이 빅쿼리 연동 지원이다.

모바일 데이타 분석 서비스 플랫폼의 경우 대 부분 플랫폼 서비스의 형태를 띄기 때문에, 분석 플랫폼에서 제공해주는 일부 데이타만 볼 수 가 있고, 원본 데이타에 접근하는 것이 대부분 불가능 하다.

그래서 모바일 애플리케이션 서버에서 생성된 데이타나, 또는 광고 플랫폼등 외부 연동 플랫폼에서 온 데이타에 대한 연관 분석이 불가능하고, 원본 데이타를 통하여 여러가지 지표를 분석하는 것이 불가능하다.


파이어베이스 애널러틱스의 경우에는 구글의 데이타 분석 플랫폼이 빅쿼리 연동을 통하여 모든 데이타를 빅쿼리에 저장하여 간단하게 분석이 가능하다.

구글 빅쿼리에 대한 소개는 http://bcho.tistory.com/1116 를 참고하기 바란다.

구글의 빅쿼리는 아마존 S3나, 구글의 스토리지 서비스인 GCS 보다 저렴한 비용으로 데이타를 저장하면서도, 수천억 레코드에 대한 연산을 수십초만에 8~9000개의 CPU와 3~4000개의 디스크를 사용해서 끝낼만큼 어마어마한 성능을 제공하면서도, 사용료 매우 저렴하며 기존 SQL 문법을 사용하기 때문에, 매우 쉽게 접근이 가능하다.

모바일 데이타 분석을 쉽게 구현이 가능

보통 모바일 서비스에 대한 데이타 분석을 할때는 무료 서비스를 통해서 DAU나 세션과 같은 기본적인 정보 수집은 가능하지만, 추가적인 이벤트를 수집하여 저장 및 분석을 하거나 서버나 다른 시스템의 지표를 통합 분석 하는 것은 별도의 로그 수집 시스템을 모바일 앱과 서버에 만들어야 하였고, 이를 분석 및 저장하고 리포팅 하기 위해서 하둡이나 스파크와 같은 복잡한 빅데이타 기술을 사용하고 리포팅에도 많은 시간이 소요 되었다.


파이어베이스 애널러틱스를 이용하면, 손 쉽게, 추가 이벤트나 로그 정보를 기존의 로깅 프레임웍을 통하여 빅쿼리에 저장할 수 있고, 복잡한 하둡이나 스파크의 설치나 프로그래밍 없이 빅쿼리에서 간략하게 SQL만을 사용하여 분석을 하고 오픈소스 시각화 도구인 Jupyter 노트북이나 구글의 데이타스튜디오 (http://datastudio.google.com)을 통하여 시작화가 간단하기 때문에, 이제는 누구나 쉽게 빅데이타 로그를 수집하고 분석할 수 있게 된다.

실시간 데이타 분석은 지원하지 않음

파이어베이스 애널러틱스가 그러면 만능 도구이고 좋은 기능만 있는가? 그건 아니다. 파이어베이스 애널러틱스는 아직까지는 실시간 데이타 분석을 지원하고 있지 않다. 수집된 데이타는 보통 수시간이 지나야 대쉬 보드에 반영이 되기 때문에 현재 접속자나, 실시간 모니터링에는 적절하지 않다.

그래서 보완을 위해서 다른 모니터링 도구와 혼용해서 사용하는 게 좋다. 실시간 분석이 강한 서비스로는 트위터 fabric이나 Google analytics 등이 있다.

이러한 도구를 이용하여 데이타에 대한 실시간 분석을 하고, 정밀 지표에 대한 분석을 파이어베이스 애널러틱스를 사용 하는 것이 좋다.


파이어베이스 애널러틱스 적용해보기

백문이 불여일견이라고, 파이어베이스 애널러틱스를 직접 적용해보자.

https://firebase.google.com/ 사이트로 가서, 가입을 한 후에, “콘솔로 이동하기"를 통해서 파이어 베이스 콘솔로 들어가자.

프로젝트 생성하기

다음으로 파이어베이스 프로젝트를 생성한다. 상단 메뉴에서 “CREATE NEW PROJECT”를 선택하면 새로운 파이어 베이스 프로젝트를 생성할 수 있다. 만약에 기존에 사용하던 구글 클라우드 프로젝트등이 있으면 별도의 프로젝트를 생성하지 않고 “IMPORT GOOGLE PROJECT”를 이용하여 기존의 프로젝트를 불러와서 연결할 수 있다.



프로젝트가 생성되었으면 파이어베이스를 사용하고자 하는 앱을 등록해야 한다.

파이어베이스 화면에서 “ADD APP” 이라는 버튼을 누르면 앱을 추가할 수 있다.

아래는 앱을 추가하는 화면중 첫번째 화면으로 앱에 대한 기본 정보를 넣는 화면이다.

“Package name” 에, 파이어베이스와 연동하고자 하는 안드로이드 앱의 패키지 명을 넣는다.


ADD APP 버튼을 누르고 다음 단계로 넘어가면 google-services.json 이라는 파일이 자동으로 다운된다. 이 파일은 나중에 안드로이드 앱의 소스에 추가해야 하기 때문에 잘 보관한다.


Continue 버튼을 누르면 아래와 같이 다음 단계로 넘어간다. 다음 단계에서는 안드로이드 앱을 개발할때 파이어베이스를 연동하려면 어떻게 해야 하는지에 대한 가이드가 나오는데, 이 부분은 나중에 코딩 부분에서 설명할 예정이니 넘어가도록 하자.


자 이제 파이어베이스 콘솔에서, 프로젝트를 생성하고 앱을 추가하였다.

이제 연동을 할 안드로이드 애플리케이션을 만들어보자.

안드로이드 빌드 환경 설정

콘솔에서 앱이 추가되었으니, 이제 코드를 작성해보자, 아래 예제는 안드로이드 스튜디오 2.1.2 버전 (맥 OS 기준) 으로 작성되었다.


먼저 안드로이드 프로젝트를 생성하였다. 이때 반드시 안드로이드 프로젝트에서 앱 패키지 명은 앞에 파이어베이스 콘솔에서 지정한 com.terry.hellofirebase가 되어야 한다.

안드로이드 프로젝트에는 프로젝트 레벨의 build.gradle 파일과, 앱 레벨의 build.gradle 파일이 있는데



프로젝트 레벨의 build.gradle 파일에 classpath 'com.google.gms:google-services:3.0.0' 를 추가하여  다음과 같이 수정한다.


// Top-level build file where you can add configuration options common to all sub-projects/modules.


buildscript {

  repositories {

      jcenter()

  }

  dependencies {

      classpath 'com.android.tools.build:gradle:2.1.2'

      classpath 'com.google.gms:google-services:3.0.0'

      // NOTE: Do not place your application dependencies here; they belong

      // in the individual module build.gradle files

  }

}


allprojects {

  repositories {

      jcenter()

  }

}


task clean(type: Delete) {

  delete rootProject.buildDir

}



다음으로, 앱레벨의 build.gradle 파일도 dependencies 부분에    compile 'com.google.firebase:firebase-core:9.4.0' 를 추가하고, 파일 맨 아래 apply plugin: 'com.google.gms.google-services' 를 추가 하여 아래와 같이 수정한다.

apply plugin: 'com.android.application'


android {

  compileSdkVersion 24

  buildToolsVersion "24.0.2"


  defaultConfig {

      applicationId "com.terry.hellofirebase"

      minSdkVersion 16

      targetSdkVersion 24

      versionCode 1

      versionName "1.0"

  }

  buildTypes {

      release {

          minifyEnabled false

          proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'

      }

  }

}


dependencies {

  compile fileTree(dir: 'libs', include: ['*.jar'])

  testCompile 'junit:junit:4.12'

  compile 'com.android.support:appcompat-v7:24.2.0'

  compile 'com.google.firebase:firebase-core:9.4.0'

}

apply plugin: 'com.google.gms.google-services'



그리고 파이어베이스 콘솔에서 앱을 추가할때 다운된 google-services.json 파일을 app디렉토리에 복사한다.




이 예제의 경우에는 /Users/terrycho/AndroidStudioProjects/HelloFireBase에 프로젝트를 만들었기 때문에,  /Users/terrycho/AndroidStudioProjects/HelloFireBase/app 디렉토리에 복사하였다.


Gradle 파일 수정이 끝나고, google-services.json 파일을 복사하였으면 안드로이드 스튜디오는 gradle 파일이 변경이 되었음을 인지하고 sync를 하도록 아래 그림과 같이 “Sync now”라는 버튼이 상단에 표시된다.


“Sync now”를 눌러서 프로젝트를 동기화 한다.

예제 코드 만들기

이제 안드로이드 스튜디오의 프로젝트 환경 설정이 완료되었다. 이제, 예제 코드를 만들어 보자.

이 예제 코드는 단순하게, 텍스트 박스를 통해서 아이템 ID,이름, 그리고 종류를 입력 받아서, 파이어베이스 애널러틱스에 이벤트를 로깅하는 예제이다.

파이어베이스 애널러틱스 서버로 로그를 보낼 것이기 때문에, AndroidManifest 파일에 아래와 같이  수정하여 INTERNET과 ACCESS_NETWORK_STATE 권한을 추가한다.

<?xml version="1.0" encoding="utf-8"?>

<manifest xmlns:android="http://schemas.android.com/apk/res/android"

  package="com.terry.hellofirebase">

  <uses-permission android:name="android.permission.INTERNET" />

  <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />

 

  <application

      android:allowBackup="true"

      android:icon="@mipmap/ic_launcher"

      android:label="@string/app_name"

      android:supportsRtl="true"

      android:theme="@style/AppTheme">

      <activity android:name=".MainActivity">

          <intent-filter>

              <action android:name="android.intent.action.MAIN" />


              <category android:name="android.intent.category.LAUNCHER" />

          </intent-filter>

      </activity>

  </application>


</manifest>


다음으로 화면을 구성해야 하는데, 우리가 구성하려는 화면 레이아웃은 대략 다음과 같다.



각각의 EditText 컴포넌트는 tv_contentsId, tv_contentsName,tv_contentsCategory로 지정하였다.

위의 레이아웃을 정의한 activity_main.xml은 다음과 같다.


<?xml version="1.0" encoding="utf-8"?>

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"

  xmlns:tools="http://schemas.android.com/tools"

  android:layout_width="match_parent"

  android:layout_height="match_parent"

  android:paddingBottom="@dimen/activity_vertical_margin"

  android:paddingLeft="@dimen/activity_horizontal_margin"

  android:paddingRight="@dimen/activity_horizontal_margin"

  android:paddingTop="@dimen/activity_vertical_margin"

  tools:context="com.terry.hellofirebase.MainActivity">


  <LinearLayout

      android:orientation="vertical"

      android:layout_width="match_parent"

      android:layout_height="match_parent"

      android:layout_alignParentLeft="true"

      android:layout_alignParentStart="true">


      <TextView

          android:layout_width="wrap_content"

          android:layout_height="wrap_content"

          android:textAppearance="?android:attr/textAppearanceMedium"

          android:text="Contents ID"

          android:id="@+id/tv_contetnsId" />


      <EditText

          android:layout_width="match_parent"

          android:layout_height="wrap_content"

          android:id="@+id/txt_contentsId"

          android:layout_gravity="center_horizontal" />


      <TextView

          android:layout_width="wrap_content"

          android:layout_height="wrap_content"

          android:textAppearance="?android:attr/textAppearanceMedium"

          android:text="Contents Name"

          android:id="@+id/tv_contentsName" />


      <EditText

          android:layout_width="match_parent"

          android:layout_height="wrap_content"

          android:id="@+id/txt_contentsName" />


      <TextView

          android:layout_width="wrap_content"

          android:layout_height="wrap_content"

          android:textAppearance="?android:attr/textAppearanceMedium"

          android:text="Contents Category"

          android:id="@+id/tv_contentsCategory" />


      <EditText

          android:layout_width="match_parent"

          android:layout_height="wrap_content"

          android:id="@+id/txt_contentsCategory" />


      <Button

          android:layout_width="wrap_content"

          android:layout_height="wrap_content"

          android:text="Send Event"

          android:id="@+id/btn_sendEvent"

          android:layout_gravity="center_horizontal"

          android:onClick="onSendEvent" />

  </LinearLayout>

</RelativeLayout>


레이아웃 설계가 끝났으면, SEND EVENT 버튼을 눌렀을때, 이벤트를 파이어베이스 애널러틱스 서버로 보내는 코드를 만들어 보자.

MainActivity인 com.terry.hellofirebase.MainActivity 클래스의 코드는 다음과 같다.


package com.terry.hellofirebase;


import android.support.v7.app.AppCompatActivity;

import android.os.Bundle;

import android.view.View;

import android.widget.EditText;

import android.widget.Toast;


import com.google.firebase.analytics.FirebaseAnalytics;


public class MainActivity extends AppCompatActivity {


  // add firebase analytics object

  private FirebaseAnalytics mFirebaseAnalytics;


  @Override

  protected void onCreate(Bundle savedInstanceState) {

      super.onCreate(savedInstanceState);

      mFirebaseAnalytics = FirebaseAnalytics.getInstance(this);

      setContentView(R.layout.activity_main);

  }


  public void onSendEvent(View view){

      String contentsId;

      String contentsName;

      String contentsCategory;


      EditText txtContentsId = (EditText)findViewById(R.id.txt_contentsId);

      EditText txtContentsName = (EditText)findViewById(R.id.txt_contentsName);

      EditText txtContentsCategory = (EditText)findViewById(R.id.txt_contentsCategory);


      contentsId = txtContentsId.getText().toString();

      contentsName = txtContentsName.getText().toString();

      contentsCategory = txtContentsCategory.getText().toString();


      Bundle bundle = new Bundle();

      bundle.putString(FirebaseAnalytics.Param.ITEM_ID, contentsId);

      bundle.putString(FirebaseAnalytics.Param.ITEM_NAME, contentsName);

      bundle.putString(FirebaseAnalytics.Param.CONTENT_TYPE, contentsCategory);

      mFirebaseAnalytics.logEvent(FirebaseAnalytics.Event.SELECT_CONTENT, bundle);


      Toast.makeText(getApplicationContext(), "Sent event", Toast.LENGTH_LONG).show();

  }

}


MainActivity 클래스에 FirebaseAnalytics 객체를 mFirebaseAnalytics라는 이름으로 정의하고 onCreate메서드에서 FirebaseAnalytics.getInstance(this) 메서드를 이용하여 파이어베이스 애널러틱스 객체를 생성한다.


다음 onSendEvent라는 메서드를 구현한다. 이 메서드는 화면에서 “SEND EVENT”라는 버튼을 누르면 EditText 박스에서 입력된 값으로 SELECT_CONTENT라는 이벤트를 만들어서 파이어베이스 애널러틱스 서버로 보내는 기능을 한다.

컨텐츠 ID,NAME,CATEGORY를 EditText 박스에서 읽어온 후에, Bundle 이라는 객체를 만들어서 넣는다.

파이어베이스 애널러틱스 로그는 이벤트와 번들이라는 개념으로 구성이 된다.

이벤트는 로그인, 컨텐츠 보기, 물품 구매와 같은 이벤트이고, Bundle은 이벤트에 구체적인 인자를 묶어서 저장하는 객체이다. 위의 예제인 경우 SELECT_CONTENTS 라는 이벤트가 발생할때 컨텐츠 ID, 이름(Name), 종류(Category)를 인자로 하여, Bundle에 묶어서 전달하도록 하였다.

Bundle 클래스를 생성한후, bundle.putString(“인자명",”인자값") 형태로 Bundle 객체를 설정한 후에, mFirebaseAnalytics.logEvent(“이벤트명",”Bundle 객체") 메서드를 이용하여 SELECT_CONTENTS 이벤트에 앞서 작성한 Bundle을 통하여 인자를 전달하였다.


앱 개발이 모두 완료되었다. 이제 테스트를 해보자

실행하기

앱을 실행하고 아래와 같이 데이타를 넣어보자


컨텐츠 ID는 200, 컨텐츠 이름은 W, 그리고 컨텐츠 종류는 webtoon으로 입력하였다.

SEND EVENT 눌러서 이벤트를 보내서 파이어베이스 웹콘솔에 들어가서 Analytics 메뉴에 상단 메뉴인 “Events”를 선택하면 처음에는 아무런 값이 나오지 않는다.

앞에서 설명했듯이 파이어베이스 애널러틱스는 아직까지 실시간 분석을 지원하지 않기 때문에 수시간이 지난 후에야 그 값이 반영 된다.


본인의 경우 밤 12시에 테스트를 진행하고 아침 9시경에 확인을 하였더니 아래와 같은 결과를 얻을 수 있었다.



실제로 테스트 시에 select contents 이벤트를 3번을 보냈더니, Count가 3개로 나온다.

그러나 이벤트에 보낸 컨텐츠 ID, 이름 , 분류등은 나타나지 않는다. 기본 설정에서는 이벤트에 대한 디테일 정보를 얻기가 어렵다. 그래서 빅쿼리 연동이 필요한데 이는 후에 다시 다루도록 하겠다.


Dashboard 메뉴를 들어가면 다음과 같이 지역 분포나 단말명등 기본적인 정보를 얻을 수 있다.



이벤트와 이벤트 인자

앞서처럼 이벤트와 인자등을 정해줬음에도 불구하고 대쉬보드나 기타 화면에 수치들이 상세하지 않은 것을 인지할 수 있다. 정확한 데이타를 분석하려면 마찬가지로 정확한 데이타를 보내줘야 하는데, 화면 로그인이나 구매등과 같은 앱에서의 이벤트를 앱 코드내에 삽입해줘야 상세한 분석이 가능하다.

이벤트는 https://firebase.google.com/docs/reference/android/com/google/firebase/analytics/FirebaseAnalytics.Event 에 정의가 되어 있고, 각 이벤트별 인자에 대한 설명은 https://firebase.google.com/docs/reference/android/com/google/firebase/analytics/FirebaseAnalytics.Param 에 있는데, 이미 파이어베이스에서는 게임이나 미디어 컨텐츠, 쇼핑과 같은 주요 모바일 앱 시나리오에 대해서 이벤트와 인자들은 미리 정의해놓았다.

https://support.google.com/firebase/topic/6317484?hl=en&ref_topic=6386699

를 보면 모바일 앱의 종류에 따라서 어떠한 이벤트를 사용해야 하는지가 정의되어 있다.


또한 미리 정의되어 있는 이벤트 이외에도 사용자가 직접 이벤트를 정의해서 사용할 수 있다.  이러한 이벤트를 커스텀 이벤트라고 하는데 https://firebase.google.com/docs/analytics/android/events 를 참고하면 된다.


지금까지 간략하게 나마 파이어베이스 애널러틱스의 소개와 예제 코드를 통한 사용 방법을 알아보았다.

모바일 데이타 분석이나 빅데이타 분석에서 가장 중요한 것은 데이타를 모으는 것도 중요하지만, 모아진 데이타에 대한 지표 정의와 그 의미를 파악하는 것이 중요하다. 그래서 다음 글에서는 파이어베이스 애널러틱스에 정의된 이벤트의 종류와 그 의미 그리고, 대쉬 보드를 해석하는 방법에 대해서 설명하고, 그 후에 빅쿼리 연동을 통해서 상세 지표 분석을 하는 방법에 대해서 소개하고자 한다.


쉽게 이해하는 모바일 데이타 분석



조대협(http://bcho.tistory.com)


모바일 서비스 비지니스를 진행함에 있어서 가장 중요한 것중 하나는 지표에 따른 의사 결정과 서비스 개선이다. 이를 위해서, 어떤 지표들이 필요한지 정의하고 어떻게 측정할지에 대한 정확한 이해가 필요한데, 이 글에서는 모바일 서비스 리포팅에 대해 어떤 지표가 있고 어떻게 활용해야 하는지, 그리고 이런 지표를 수집 분석하기 위한 도구들에 대해서 설명하도록 한다.


모바일 서비스에서 단계별 사용자 흐름


먼저 지표를 이해하기 전에, 사용자가 모바일 서비스 가입부터 사용에서 부터 이익을 내줄때 까지 어떤 흐름을 거치는지에 대해서 살펴볼 필요가 있다. 여러 글들이나 서비스들에서 다소 용어 차이는 있지만 대부분 아래와 같이 단계를 정의한다. 





Acquisitions (사용자 획득 단계)


“사용자 획득 단계”는, 사용자가 앱을 설치 하는 단계로 광고/마케팅등을 통해서 사용자가 앱을 인지하고 설치하는 단계인데, 조금 더 세분화 하면, 설치 후 첫번째 실행을 한 단계로 정의하거나 또는 설치 후 회원 가입까지 한 단계를 “사용자가 획득 되었다” 라고 판단할 수 있다.


사용자의 유입은 검색엔지이나 앱스토어의 검색등을 통하거나, TV,온라인 캠페인(인터넷 광고), 오프라인 캠페인등을 통해서 이끌 수 있다. 유입 경로가 다양하기 때문에 모든 경로에 대한 추적은 불가능하지만, 특히 온라인 캠페인(인터넷 광고) (페이스북이나 카톡 등)는 손쉽게 추적이 가능하고 사용자 획득양에 따라서 광고 플랜을 조절할 수 있기 때문에, 이러한 온라인 캠페인은 시작하기 전에 사용자 유입이 비용대비 어떻게 효과가 있는지를 측정할 수 있는 준비 (분석툴등)를 해놓고 시작해야 한다.


Retention (사용자 유지 단계)


마케팅등을 통해서 사용자를 유입시켰으면 이 유입된 사용자를 서비스에 잡아놓아야 하는데, 이를 Retention, 즉 사용자 유지라고 한다. 이 사용자 유지율을 가입한 사용자가 가입한 이후, 얼마나 꾸준히 재 접속을 하는지를 통해서 측정하는 것이 일반적인데, 1일 후 재접속율, 2일..7일 재접속율을 체크하면 된다. 


이 단계에서 이탈을 방지하고 얼마나 사용자를 Lock in 하여 충성도가 높은 사용자층을 유지하는 것이 중요하다.


Engagement (사용자 활동 단계)


사용자가 서비스를 지속적으로 사용하기 시작하면, 서비스와 사용자간의 인터랙션 즉 활동이 시작되는 단계가 된다. 미디어 서비스일 경우 단방향으로 컨텐츠를 보기만 하는 단방향성의 활동보다는 댓글이나 좋아요 버튼등을 통한 양방향 활동등을 유도하여 서비스의 로열티를 높이고, 서비스에 체류하는 시간을 늘려서 장기적으로 수익화할 수 있는 원천으로 삼아야 한다.


Monetize (수익화 단계)


고정 사용자 층이 형성이 되었으면, 이 사용자 층을 이용하여 수익을 창출해야 하는 데, 광고나 게임의 경우 인앱 구매, 쇼핑의 경우 물품의 실제 구매 단계 까지 연결이 되서 최종적으로 수익을 창출하는 단계이다.


사용자의 인터랙션은 앞에서 설명한바와 같이 위의 그림 처럼 깔때기 형태로 이루어지며 최종 수익을 발생하는 사용자를 얼마나 많이 유도 하느냐가 비지니스의 성패가 된다. 


이러한 흐름을 설명하는 것은 보통 모바일 앱 데이타 분석에 있어서 상당히 많은 지표들이 있고, DAU,MAU,Session Time등 각각의 지표만을 모니터링 하고 분석할뿐 전체 지표가 어떻게 연결되는지 연관성에 대한 인사이트가 적은 것이 대부분의 문제라고 생각하기 때문에 사용자의 단계별 활동에 대한 흐름을 설명하였다.


단계별 지표 정의와 의미


이번에는 위에서 서술한 각 단계별로 모니터링 하는 주요 중요 지표에 대해서 알아보도록 하자



Acquisition 


Download

앱을 다운로드해서 설치한 횟수이다. 이때 중요한 것이 이 Download 수와 실제 사용자 수는 일치 하지 않는다는 것이다. 같은 사용자가 기기를 바꿔서 다시 다운로드할 수 도 있고, 여러기기에 다운로드를 할 수 도 있고 혹은 앱을 지웠다가 재 설치할 수 도 있기 때문에 , 다운로드 수와 사용자 수를 혼돈하지 않도록 한다. 이러한 다운로드 수는 별도의 솔루션을 사용하지 않더라도 구글 플레이 스토어나, 애플 앱스토어 등에서 쉽게 모니터링 할 수 있다.



New User

신규 사용자 수이다.  앱을 설치하고 첫번째로 사용하는 사용자의 수로, 실제로 프로모션등으로 인하여 앱을 설치는 하지만, 사용하지도 않고 삭제하는 경우의 수도 많기 때문에, 별도로 측정이 필요하다.


Demographic Info

그외, 사용자에 대한 기본적인 정보를 수집할 수 있는데, 나이, 성별,  지역적인 위치, 사용 단말의 종류, 통신사등 기본적인 인구 통계나 디바이스에 대한 정보를 수집을 통해서 주로 어떤 사용자 층이 서비스를 사용하는지 인지할 수 있다. 



Install tracking

사용자 획득 단계에서 중요한 지표중의 하나가, 이 사용자가 어디를 통해서 들어왔냐는 것이다. 온라인 마케팅을 통해서 들어온건지. 그렇다면 채널이 페이스북인지? 아니면 웹 사이트 광고인지, 어느 웹사이트 인지? 아니면 공유 기능등을 통한 추천으로 들어온것인지 이메일 마케팅을 통해서 앱 인스톨이 유도 된것인지등이 분석이 되어야 한다.

이러한 분석은 안드로이드 앱의 경우 캠페인 관리 기능을 통해서 UTM 정보라는 것을 획득하면, 어느 경로를 통해서 앱 인스톨이 유도 되었는지 추적이 가능하기 때문에, 결과적으로 어느 마케팅 채널을 통해서 사용자 유입이 활발하게 이루어지는지 판단이 가능하고 이를 통해서 효율적인 채널에 마케팅 리소스를 집중할 수 있도록 해준다.


Retension


Retension rate는 신규 사용자의 재 방문율 분석을 통해서 인지할 수 있다. 이런 수치는 Google Analytics나 Yahoo의 Flurry등읗 이용하여 분석이 가능한데, 아래 그림은 Flurry의 Retension 모니터링 화면이다. 


  


가입자가 가입을 한후에, 날짜가 지남에 따라 얼마나 많은 사람이 남아 있는 가를 볼 수 있다. 당연히 Day 0 에는 100% 일테고, 위의 그림을 보면, 1일 차에는 대략 60%의 사용자가 남게 되고, 그후에 40~50% 사용자가 유지되는 것을 볼 수 있다.


Engagement


Engagement 는 서비스에 대한 사용자의 활동량을 측정하는 수치로 서비스의 종류나 특성에 따라 측정해야 하는 수치가 다르다. 예를 들어 신문이나 방송같은 미디어 서비스의 경우 컨텐츠 뷰수가 중요할것이고, 게임같은 경우에는 플레이 시간이나, 레벨업 등이 중요할 것이고, 쇼핑의 경우에는 상품을 보는 수등이 중요할 수 있다.

이런 추가적인 지표는 각 서비스에 맞게 정의하는 것이 중요하지만, 공통적으로 사용할 수 있는 지표를 보면 다음과 같다


User Path

앱 상에서 사용자의 이동 경로로, 메인 화면으로 갔다가 각각의 메뉴로 사용자가 이동하고 각 메뉴별 체류 시간등을 분석해줌으로써 사용자가 주로 어떤 패턴으로 기능을 사용하는지 또한 어떤 기능이 많이 사용되고 안되는지 등에 대해서 분석이 가능하다.



 

Active User

Active User는 단위 시간동안 그 서비스를 사용한 사용자의 수를 뜻한다.

일반적으로 일단위나 주단위, 월단위를 많이 사용하는데 각각을  DAU(Daily Active User), WAU(Weekly Active User), MAU(Monthly Active User)라고 하고 앱의 서비스 규모를 측정하는 가장 일반적인 지표로 많이 사용된다. 


Session

다음으로 중요한 지표중 하나는 세션(Session)인데, 세션은 한명의 사용자가 한번 앱에 접속해서 사용하고 종료할때까지의 기간을 세션이라고 한다. 한명의 사용자가 하루에 여러번 앱을 사용하면 각각이 하나의 세션으로 취급되며, 일반적으로 안드로이드의 경우 하나의 세션을 사용자의 액션이 없을 경우 30분 후에 종료되는 형태로 정의된다. (cf. 웹에서 HTTP Session이 사용자 액션이 없으면 20분 후에 종료되는 것과 같은 종류로 보면 된다) 

이 세션의 수는 일반적으로 현재 앱을 사용하는 동시 접속자 수와 유사하다고 보면 된다. (사용자가 실제 사용을 종료하고도 30분 정도를 동시 사용자로 측정하기 때문에 다소 오차는 있지만, 전체적으로는 동접자 수와 유사하다고 판단한다.)

https://support.google.com/analytics/answer/2731565 는 Google Analytics에서 사용하는 세션의 개념이다.


Session Lenth

한번 접속했을때 사용자가 앱을 사용하는 시간을  Session Length라고 한다. 이 Session Length가 길다는 것은 그만큼 앱을 사용하는 시간이 길다는 의미로 사용자의 활동이 많다고 볼 수 있으나, 앱의 특성에 따라서 Session Length가 가지는 의미는 다르다. 알람 앱같은 경우에는 설정이나 알람이 울릴때만 앱이 사용되기 때문에, Session Length가 길 수 가 없고 짧다. 그래서 Session Length가 긴것 보다는 총  Session의 수가 얼마나 되느냐가 중요한 척도가 된다. 



Viral

근래에 모바일 서비스에서 중요한 지표중의 하나가 바이럴 지표인데, 페이스북과 같은 SNS 서비스를 통해서 공유가 되고, 이 공유를 통해서 들어오는 사용자 유입은 매우 중요하다. 그래서 추가적으로 SNS 매체별 공유 카운트 등을 별도로 추적할 필요가 있다.


Bounce rate

흔히들 놓치는 수치 중에 하나가 이탈율이다. 사용자 Install이 증가함에도 불구하고, 지속적으로 DAU가 늘어나지 않는 이유는 흔히 앱을 설치했다가 삭제하는 이탈 사용자 때문인데, 이러한 이탈율은 Google play store 등에서 쉽게 추적이 가능하다.


<그림. 구글 플레이스토어에서 일일 Uninstall 사용자 추적 예제> 


Loyalty (하루에 몇번 앱을 사용하는가?)

다음으로는 사용자의 충성도를 측정하는 지표인데, 주로 하루에 또는 일주일에 몇번 앱을 사용하는지를 측정한다. 



추가적으로 고민해야 하는 사항들


앞에서 모바일 앱 데이타 분석에서 일반적으로 살펴봐야 하는 지표들에 대해서 알아보았다. 이런 일반 지표 이외에 추가적으로 고려해야 하는 부분은 무엇이 있을까?


코호트  분석 (Cohort analysis)


코호트 분석이란, 분석 결과를 특정 사용자 그룹으로 (나이 또는 성별 등) 나눠서 더 깊게 분석하는 것으로, 집단의 특성에 따른 인사이트를 얻어서 서비스에 반영할 수 있다.

예를 들어서 DAU가 100만으로 꾸준히 유지 되는 서비스가 있다고 가정할때, 이를 연령 층으로 나누었을때 20대 사용자가 증가하고 30대가 감소한다면, DAU 향상을 위해서 30대를 위한 서비스 개선을 생각하거나 또는 서비스의 방향을 20대로 아예 바꿔 버릴 수 도 있다. 앞의 지표를 하나의 숫자로만 보고 분석하면 집단별 특성을 놓칠 수 있지만, 코호트 분석을 통하면 서비스를 사용하는 집단의 특성에 따라 다양한 해석이 가능하기 때문에 그에 따른 다양한 대응역시 가능하게 된다.


퓨넬 분석 (Funnel analysis)


Funnel / 깔때기 분석이라고 하는데, 특정 목표를 달성할때 까지 사용자의 잔존 비율을 단계별로 분석하는 분석 방법이다. 

앞에서 설명한 Acquisitions > Retain > Engagement > Monetization 의 단계도 뒤로 갈수록 사용자가 점점 낮아지는 깔때기 형태로 일종의 퓨넬 분석에 속한다.





위의 그림은 Flurry에서 제공하는 Funnel 분석 결과 화면으로, 자동차를 판매하는 사이트에서, 각 단계별로 넘어가는 사용자 통계로, Choose Car 단계에서 Check In 단계로 넘어갈때, 43.1 %의 사용자만 넘어간것을 볼 수 있다. 다음 단계는 각각 56.4%, 72.6%로 View State 목표를 달성하는 과정중에 사용자가 Check In 단계에서 가장 많이 이탈함을 알 수 있고 이 부분을 우선 개선해야 하는 것을 알 수 있다. 


이러한 퓨넬 분석을 이용하면, 사용자가 최종 목표에 다다르기 까지 어느단계에서 이탈을 하는지 쉽게 판단이 가능하고, 그 단계를 보강함으로써 최종단까지 사용자를 유도하도록 서비스를 개선할 수 있다.

 

지표의 단순화


지금까지 다양한 지표를 살펴봤는데, 비단 모바일 데이타 분석 뿐 아니라 일반적인 데이타 분석에서도 경험상 보면 필요한 핵심 지표의 수는 그리 많지 않다. 오히려 지표가 많을 수 록 혼란이 생기고, 각 지표의 의미를 이해하기 위해서 많은 노력이 들어간다. 그래서 조직에서 그리고 비지니스에서 꼭 필요한 핵심 지표 위주로 지표를 선정하고 집중해서 관리 하는 것이 훨씬 더 효과적이 아닌가 한다.


추가적인 분석 지표


앞서 살펴본 일반적인 지표 이외에도 모바일 서비스에 있어서 중요한 추가 지표들이 있다.


크래쉬 비율


앱의 사용자 유발하고, 앱 평가를 떨어뜨리는 요인중의 하나가  ANR(Application Not responding : 애플리케이션이 멈춰서 응답이 없는 현상) 또는 앱이 비정상 종료 되는 경우인데, 모든 케이스는 아니지만 상당 케이스는 모니터링 도구를 통해서 추적이 가능하다. 구글의 플레이 스토어의 경우에도 개발자 콘솔을 통해서 이 ANR과 DOWN리포팅 및 로그를 받을 수 있고, 아니면 야후 Flurry나 트위터의 Fabric을 통해서도 이 문제에 대한 로그를 수집 및 분석이 가능하다. 




<그림. Fabric 크래쉬 분석 화면>


앱스토어 평가


서비스의 노출을 위한 검색엔진 최적화 만큼이나 중요한것이 모바일 앱에서는 앱스토어 최적화이다. 앱스토어에 올라가는 이미지, 문구, 분류 체계 그리고 검색 노출이 쉽게 하는 기능뿐 아니라, 앱스토어에서 앱에 대한 평점 관리는 대단히 중요한 지표이기 때문에 이 부분 역시 같이 신경써야 한다.



실제 측정을 위한 절차


그러면 이런 지표들을 측정하고 사용하기 위해서는 어떠한 절차를 거쳐야 할까?


정보 모델의 설계


가장 중요한 것은 정보 모델의 설계이다. 서비스 특성을 감안하여 가장 중요한 성장 동력이 되는 지표가 무엇인지, 앞의 퓨넬 모델에서 설명한 사용자의 획득에서 수익 창출 단계까지 이르기 까지 서비스의 특성에 따라서 어떤 지표가 필요한지를 선정하고, 서비스에 맞춰서 각 지표를 정의하는 것이다.


미디어 서비스의 경우 앱 인스톨, 액티브 사용자 비율, 탈퇴 비율등과 같은 정적 지표와

사용자가 메인에서 리스트로 진입해서 컨텐츠를 보고 댓글을 쓰는 동적 이동에 따른 메인 뷰 수, 컨텐츠 뷰수, 체류 시간과 같은 동선에 따른 지표를 정보 모델로 정의할 필요가 있다.


구현 방식 선정


이러한 정보 모델이 정의 되고, 각 대표 지표가 선정이 되었으면, 이를 실제 구현할 수 있는 구현 방법을 결정해야 하는데, 모바일 데이타 분석은 빅데이타 영역에 속하기 때문에 자체 구축을 하려면 하둡이나 스파크같은 복잡한 인프라가 필요하고 대용량 데이타를 저장 및 분석하기 위한 많은 하드웨어와 인력이 필요하다.


근래에는 클라우드 서비스 형태로 제공되는 모바일 앱 분석 서비스들이 많고 광고 플랫폼을 중심으로 앞에서 언급한 구글,야후,트위터들이 무료 분석 플랫폼을 제공하기 때문에 이러한 무료 플랫폼을 이용하는 것도 하나의 방법이 된다. 

개인적으로는 Flurry를 가장 선호하는데, 사용자 수에 대한 제약이 없고 User Path, Funnel 분석등 다양한 기능을 제공한다. Google Analytics의 경우 기능이 막강하고 다양한 커스터마이제이션이 가능은 하지만 사용법 학습등에 많은 노력이 필요하고, 일정 볼륨이 넘어가면 1억원 이상의 비용을 지급하고 유료로 사용해야 하기 때문에 과연 좋은 선택인가에 대해서는 의문이 있다. 




단 이러한 플랫폼의 경우에는 커스터마이징이 어렵고 이로 인하여 대쉬 보드에 원하는 지표를 다 넣을 수 없는 경우가 많기 때문에 만들어놓더라도 각각의 지표가 연결된 의미를 찾지 못해서 무용지물화 되기 쉬운 단점이 있고, 앱스토어나 기타 흩어져있는 시스템들의 정보를 취합하여 보여줄 수 없다.


중간 대안으로는 정보분석 플랫폼을 사용하되, 이러한 분석 플랫폼들은 오픈 API를 제공하고 있고, 앱스토어도 오픈 API를 제공하기 때문에,  이러한 API를 이용하여 여러 소스로 부터 데이타를 모으고, 조직의 데이타 분석 수준이나 뷰에 적절한 대쉬 보드를 직접 구축하면 훨씬 높은 효과를 얻을 수 있다.


이벤트 태그 삽입


구현 방식이 선정되면 앱에서 발생하는 이벤트 (시작, 종료, 메인 페이지 이동, 댓글 등록)를 플랫폼으로 보낼 코드를 삽입하면 된다.


야후 플러리의 경우 간단하게 이벤트 명을 입력하는 것만으로 이벤트를 로깅 할 수 있다.


[Flurry logEvent:@“EVENT_NAME"];


<코드. 야후 플러리 이벤트 로깅 iOS Object C 예제>


이때 솔루션에 따라 이벤트의 개수와 이벤트의 길이에 제약이 있기 때문에, 정보 모델을 설계할때 적절한 이벤트 수를 정하는 것이 중요하다. (플러리의 경우 300개의 이벤트, 이벤트 명은 255자 이하)

이벤트 명을 정의할때는 정보 모델에 따라서 트리 구조로 계층 구조를 갖는게 좋은데 예를 들어


/main

/main/contents/

/main/contents/comment


식의 REST 형식의 리소스 형태를 사용하게 되면, 훨씬 더 직관적으로 이해 쉽다.



맺으며


모바일건 웹이건 근래의 서비스는 경쟁이 심해지고 빠르게 사용자의 니즈를 이해하고 맞춰나가지 않으면 생존하기 힘든만큼 데이타 분석은 선택이 아니라 거의 필수적이다. 


이러한 데이타 분석은 갑자기 튀어난게 아니라 Dataware house, Business Intelligence, OLAP 등으로 예전 부터 전통적으로 존재하고 있는 시스템이고 다만 구현 방식이나 강조되는 포인트들이 다소 변경된것인데, 경험상으로 보면 이런 시스템을 구현하는 데 많은 비용과 노력을 들이지만 100% 잘 사용되는 경우가 드물다. 

 원인을 보면, 시스템을 구축하지만 이 구축된 정보를 얼마나 쉽게 전달할것인가에 대한 고려가 적고 지표에 대한 이해와 시스템 사용 방법에 대한 교육이 없이 한정된 배경 지식만으로 전체 지표를 이해가 불가능 하기 때문이다.

 시스템을 보는 입장에서 최대한 단순하게 만들어야 되는데, 경험상 BI 프로젝트등을 해보면 멋진 대쉬보드를 만들어놓고도 결국 끝에 가서 나오는 말은 액셀로 보내주세요... 이다.

 시스템의 구축이 전체의 30% 이하 정도의 작업이라면 나머지는 필요한 지표의 정의, 정보 모델의 정의, 사용자가 원하는 대쉬보드의 구축, 구성원들에 대한 데이타 분석 및 시스템에 대한 활용 교육이 지속적으로 제공되어야 한다. 큰그림을 이해하지 못한 상태에서 파편만 보다가는 전체 흐름이나 방향을 놓칠 수 있기 때문에 이 부분에 대해서는 몇번을 강조해도 부족함이 없을것이라 본다.  

모바일 개발 트렌드

아키텍쳐 /모바일 | 2015.11.17 10:55 | Posted by 조대협


모바일 개발 트렌드에 대한 예측


조대협 (http://bcho.tistory.com)


시장 환경


2016년 모바일 개발 트렌드에 대해서 언급하기 앞서서 전체적인 모바일 비지니스 변화를 지켜볼 필요가 있다.


모바일 스타트업 중심의 개발 트랜드가 계속


여러 유니콘(실리콘 밸리에서 급속도로 성장하고 있는 스타트업)들의 실적 약화에도, 내년에도 변함없이 계속해서 스타트업 생태계는 확장이 되어갈 것이고, 그 중심에 모바일 앱이 있을 것 이라고 본다.

많은 모바일 앱들은 톡톡 튀는 아이디어와 새로운 기술들로 무장한 스타트업을 중심으로 개발이 될것이라고 보는데, 모바일 스타트업의 특성상 필요한 몇가지 요구 사항이 있고, 이 요구 사항을 채워주는 기술 위주로 내년은 기술 트랜드가 발전하지 않을까 싶다.


모바일 중심의 스타트업 비지니스에서 개발팀이 필요한 내용을 정리해보면 다음과 같다.


효율성과 스피드가 점점 중요시 됨

스타트업의 본질적인 특성상 적은 인원으로, 개발을 해야 하고, 시장에 많은 경쟁 서비스들과 우위를 점하기 위해서는 스피드가 중요하다. 적은 인원으로 스피드를 내려면, 팀의 효율성이 중요하다. 그래서 효율성을 최대로 할 수 있는 개발 프로세스가 필요하고, 빠르게 배우고 빠르게 사용할 수 있는 기술이 필요하며, 시스템 운영등을 대행해주는 서비스들이 필요하다.


고객 피드백과 실험

근래에 스타트업 아니, 비단 스타트업 뿐 아니라 대부분의 서비스 개발 방식은 “린 스타트업” 방식을 따르는데, 최소한의 기능을 가진 제품을 시장에 출시하고, 그 기능을 피드백을 기반으로 계속해서 보강해 나가는 서비스 개발 프로세스를 가지게 된다.

이 프로세스를 실현화 하려면 새로운 기능이나 UX등에 대해 사용자로 부터 피드백을 받을 필요가 있고, 다양한 옵션에 대해서 실험과 분석을할 필요가 있다. 

이런 실험과 분석을 하기 위해서는 사용자에 앱 사용 패턴을 분석할 수 있는 분석 플랫폼과, 다양한 기능을 테스트할 수 있는 테스팅 플랫폼이 필요하게 된다.


글로벌 서비스

모바일 앱 서비스의 수익 모델을 보면 인앱 결재도 많지만, 아직까지는 광고에 의존하는 모델이 상당히 많다. 이 경우, 한국 시장만 보기에는 시장 규모가 너무 작고, 애플리케이션 성의 앱들은 특별히 한국이라는 시장에 갖혀 있을 필요가 없기 때문에 글로벌로 서비스를 확장하거나 처음부터 아예 글로벌을 타케팅 하는 경우가 많은데, 개인 정보 위치에 대한 속지 주의 (개인 정보는 그 나라를 떠자니 못한다) 요건이나 각 나라의 문화나 계정 체계 (동남아는 라인 로그인을 많이 쓰고, 한국은 카톡 로그인, 미국은 페북 로그인을 많이 쓰는)나 기술적 차이 (중국에서는 구글이나 애플 푸쉬가 작동하지 않는다)로 인하여 각 국가에 맞게 애플리케이션을 수정해야 할 필요가 있다. 


개발 트랜드


그러면 이런 니즈를 맞추기 위해서 개발 트랜트는 어떻게 변화하고 있을까?


클라우드 활용의 가속화

첫번째는 클라우드 서비스 활용의 가속화이다.  클라우드 서비스의 활용은 어제 오늘일이 아닌 이미 보편화된 내용인데,  그렇다면 변화는 무엇인가? 클라우드 서비스 활용이 주로 서버등의 인프라를 활용하는 IaaS 중심이었고, 근래에는 웹서버나 데이타베이스 서버등의 미들웨어를 활용하는 PaaS 형태로 그 중심이 옮겨왔다.

예전에는  아마존의 EC2등에 직접 솔루션을 설치해서 개발을 했는데, 요즘은 그보다  아마존 Beans Talk이나 Heroku 클라우드 같은 PaaS 형태의 사용이 잦아졌고, Redis나 MongoDB등과 같은 다양한 솔루션들이 PaaS 형태로 제공되어 많은 미들웨어를 직접 설치하지 않고 managed 서비스를 사용하는 형태로 이동하고 있다. 이는 복잡한 인프라에 대한 설치 및 운영 비용을 줄이고, 빠른 개발을 할 수 있게 도와준다.

 대표적인 서비스로는 아마존 BeansTalk, IBM BlueMix, Heroku 클라우드등을 예로 들 수 있다.


여기에 한걸음 더 나가서 Fundamental 서비스의 활용이 두드러 지는데, Fundamental 서비스는 애플리케이션을 구성하는데 사용되는 기능을 제공하는 서비스로 대표적으로 푸쉬 서비스, 메세지 큐 서비스, 사용자 계정 관리 서비스등이 이에 해당한다. 특히 이러한 서비스는 여러가지 복잡한 기능들을 추상화해주기 때문에 여러가지 기능들을 동시에 지원해야 하는 경우 쉽게 개발을할 수 있게 해준다. 대표적인 예로는 푸쉬 서비스를 들 수 있는데, 푸쉬는 기본적으로 안드로이드와 iOS를 위한 GCM,APNS 푸쉬 지원뿐 아니라, 중국을 위한 바이두 푸쉬등 다양한 푸쉬를 지원해야 하며, 대량 발송, 예약 발송등 복잡한 기능들을 제공해야 하는데, 이를 일일이 개발하려면 그것만으로도 하나의 제품을 개발하는 정도의 개발 노력이 필요하다. 이러한 고급 기능들이 근래에는 클라우드로 제공되는데, 아마존의 SNS와 같이 대형 클라우드 벤더에서 Fundamental 서비스로 제공하는 기능이나 또는 OneSignal.com 과 같이 특정 도메인(기능)에 전문화된 형태로 서비스가 제공 되는 경우가 있다.


 대형 벤더에서 제공되는 Fundamental 서비스는 해당 클라우드 인프라와 같은 위치에서 서비스가 제공되고 같은 인프라를 사용하기 때문에 통합이 쉽다는 장점을 가지고 있지만 반대로 특정 도메인 기능만 제공하는 전문화된 서비스에 비해서 가격이나 기능적인 면에서 열세인 경우가 많다.


대표적인 서비스로는 앞에서 언급한 푸쉬 전문 서비스인 OneSignal.com , 동영상 인코딩 서비스 heywatch.com, zencoder.com , Redis 전문 서비스인 redislabs.com , 몽고디비 및 DBaas 서비스 전문업체인 compose.io , 검색 전문 서비스인 https://www.algolia.com/ 등을 들 수 있다. 


여담으로 나이가 많은 개발자들은 기술을 탐독하고, EC2등에 직접 깔아서 사용하는 것을 선호하는 반면, 근래에 많은 스타트업 개발자들을 만나서 개발 아키텍쳐를 검토하다보면, 오히려 잘 구성되어 있는 매니지드 서비스들을 잘 엮어서 빠른 시간내에 더 좋은 기능으로 서비스를 개발하는 것을 보면, 세대간에 기술에 대한 접근 방법이 벌써부터 차이가 나지 않는가 한다.



풀스택 개발자

풀스택 개발자란 한명의 엔지니어가 독립적으로 모든 서비스를 개발할 수 있는 수직적인 기술 능력을 가지고 있는 사람을 정의한다. 수직적인 기술 능력이란, 앱-백앤드-인프라 또는 프론트-백앤드-인프라 까지 서비스를 개발하는 데 필요한 모든 End to End  기술을 이야기 한다.

작년까지만 해도 풀스택 개발자가 바람직하다 아니다 라는 논쟁에서 부터, 풀스택 엔지니어는 불가능하다 가능하다 까지 여러 논쟁이 많았다.

결론 부터 말하자면 풀스택 개발자가 가능하고 불가능하고, 바람직하고 말고의 논쟁을 떠나서, 할 수 밖에 없다.


스타트업 인원 구조의 특성상 각 기술 계층에 해당하는 엔지니어를 따로 뽑을 수 가 없기 때문에 한명의 개발자가 앱 개발에서 부터 백앤드 개발까지 모두 맏아야 하며, 시스템을 운영하기 위한 인프라 설치 및 운영까지 모두 커버해야 한다. 


이런 것이 가능한 것은, 스타트업 인력 구성의 한계에 의한 필요성도 있지만, 이런 필요성에 의해서 기술도 그만큼 편리해졌기 때문이다. 스크립트 언어의 발전으로 루비나 node.js 의 경우 학습 비용이 매우 낮고, 생산성이 높게 개발을 할 수 있으며, 아울러, 클라우드의 발전으로 전문적인 하드웨어 전문적인 지식이 없이도 얼마든지 인프라를 운영할 수 있고 더불어 PaaS의 발전으로 하드웨어의 지식이나 미들웨어에 대한 지식이 없이도 설치 및 운영이 가능하게 되었다.


개인적으로 풀스택 개발자의 가능성에 대해서 많은 고민을 했는데, 스타트업에서 만난 엔지니어들을 보면 앱 개발에서 시작했다가 필요로 인하여 서버를 개발하게 되고, 쉬운 방법을 찾아가면서 클라우드를 활용하면서 서버 개발까지 같이 하는 개발자들을 많이 보았다. 특히나 백앤드 개발에 대한 선입관이 없기 때문에 솔루션이나 아키텍쳐 구성에 유연성이 보이고, 기존 전통적인 백앤드 아키텍쳐의 사상을 넘어서는 좀더 실용적인 아키텍쳐 디자인을 하는 것을 볼 수 있었다.


서비스 기반의 데이타 분석

근 몇년 빅데이타 분석의 중요성은 계속 강조되어 왔기 때문에 데이타 분석의 필요성등에 대해서는 별도로 언급하지는 않겠다. 그런데 이 데이타 분석이라는 것이, 많은 양의 데이타를 저장하기 위한 하드웨어 인프라가 필요함은 물론이고, 이를 분석하기 위한 소프트웨어 예를 들자면 하둡이나 스팍과 같은 기술을 도입하기 위해서는 높은 기술 수준과 자금이 필요하기 때문에 일반적인 스타트업에서는 적용이 매우 어렵다. 그래서 빅데이타라는 넘어가야 하는 영역이 있음에도 불구하고 실제로 활용하기가 어려운 영역이었다.

그런데 근래에 광고 서비스 업체나 인터넷 서비스 업체를 중심으로 데이타 수집에 대한 요구와 개발자 생태계를 자기쪽으로 끌어들이기 위한 목적으로 데이타 분석 서비스를 무료 또는 부분 무료로 오픈 하는 경우가 많다.


대표적인예로, 구글 애널러틱스 (aka. GA)나 야후의 Flurry, 트위터의 Fabric과 같은 서비스들이 대표적인 예이며, 한국의 경우 파이브락스(http://www.5rocks.io/en) 가 무료(광고를 내보내야하기는 하지만)에서 서비스를 제공하고 있다. 



< 그림. Yahoo Flurry 스크린샷 >


단순하게는 일/월 방문자수 (DAU/MAU)에서 부터, 사용자가 앱에서 어떤 경로로 돌아다니고 머무는 시간이 얼마인지, 사용자 층은 어떻게 되는지까지 분석이 가능하다.

앱을 개발해서 서비스를 한다면 반드시 사용해야 하는 서비스가 아닐까?


AB 테스팅의 도입 가속

페이스북을 사용하는 사용자라면 어느날 갑자기 앱 업데이트를 하지 않았는데도 새로운 기능이 돌다가 갑자기 그 기능이 없어진것을 확인할 수 있다. 페이스북에서는 사용자의 반응을 살피기 위해서 새로운 기능을 미리 넣어서 배포해놓고,사용자를 A/B 두 그룹 (또는 그 이상)으로 나눠서 사용자의 기능 사용에 대한 반응을 보고 그 기능을 적용할지 여부를 결정하는 방법이다.


A/B 테스팅은 개념 자체는 좋지만, 앱스토어 환경에서 이를 하려면, 

  1. 두개의 기능을 개발해야 하고
  2. 각 기능을 A/B 두개의 사용자 그룹에 별도로 보이게 해야 하며
  3. A/B 사용자에 대한 기능 사용율을 매번 수집하여 분석해야 한다.


물론 직접 코드로 만들 수 도 있지만, 배포된 애플리케이션에서 테스트 비율을 조정한다던지, 테스트 진행 상황에 대한 리포팅을 작성하려면 로그도 수집해야 하고 별도의 개발 노력이 드는게 사실이기 때문에, 막상 쉽게 접근하기는 어렵다.


이런 일반적인 AB 테스팅 개발을 제공하기 위한 클라우드 기반의 서비스가 근래에 들어서 많이 제공되고 있는데, optimizely.com apptimize.com 등 여러 서비스들이 있고, 아마존 AB 테스팅의 경우 무료로 그 기능을 제공한다.

아마존의 경우는 무료인 만큼 기능이 빈약하다. 상용 서비스의 경우에는 5만, 10만 사용자까지 무료로 기능을 제공하거나 수익을 내지 못하거나 펀딩을 받지 못한 스타트업에는 무료로 제공하는 경우도 있으니, 꼼꼼하게 살펴볼 필요가 있다. 


  

<그림. AB 테스팅 도구에서  UI를 변경하는 화면> 

출처 : https://www.leanplum.com/c/blog/page/2/


특히 상용 솔루션의 경우에는 앱이 배포된 상태에서 별도의 재 배포 없이 UI 요소 (버튼 색, 이미지, 텍스트)를 동적으로 변경해서 테스트를 진행할 수 있는 기능을 제공하기 때문에, 손쉽게 UI 개선을 해나갈 수 있고, 특히 GUI 기반의 도구를 제공하기 때문에, 개발팀의 도움 없이 디자인팀이 직접 수정을 해서 테스트가 가능하다.


개발에 대한 공수나, 적절한 플랫폼의 부재로 지금까지 쉽지 않았던 분야인데, 여러 클라우드 기반의 서비스를 기반으로해서 2016년에는 일반 앱 서비스 개발에도 사용 빈도가 꽤 높아지지 않을까 하는 예상을 조심스럽게 해본다.

오픈 소스 머신 러닝 알고리즘 및 클라우드 머신 러닝 서비스


데이타 분석의 다른 영역으로는 데이타를 분석하여, 추천이나 데이타등을 군집화 또는 분류해주는 머신러닝 (Machine Learning) 분야가 있다. 수학적인 지식과 대규모 인프라가 필요하기 때문에, 일반적인 기업이나 개발자들이 접근하기 어려운 부분이었는데, 근래에 하둡과 같은 빅데이타 인프라가 오픈소스화 되고, 또한 복잡한 ML  알고리즘이 오픈소스 패키지로 제공됨에 따라서 급격히 확산이 되기 있는데, 여전히 소규모의 앱 개발자들이 쓰기에는 복잡한 인프라를(하둡,스파크 등) 직접 설치 운영해야 하는 부담이 있었다.

 그러나 근래에 Microsoft 나 Google 등을 중심으로 이 머신 러닝 알고리즘을 클라우드 서비스 형태로 API가 제공됨으로써 개발 접근성이 매우 쉬워졌고, coursera.org 와 같은 온라인 강의를 통해서, 일반 개발자들오 머신러닝 관련된 기술을 쉽게 배울 수 있는 온라인 강좌됨에 따라, 예전에 비해서 훨씬 쉽게, 빅데이타를 활용한 머신러닝 서비스에 접근이 가능하게 되었다. 




<그림.  Microsoft Azure 클라우드의 머신러닝 로직 설계 화면 >




지금까지 짧게지만 앞으로는 모바일 서비스 개발 방향에 대해서 살펴보았다.

전체적인 흐름을 요약해보자면, 스타트업 주도의 개발이 활성화 되면서 적은 인원으로 효율적인 개발을 할 수 있는 환경이 필요함에 따라 앱 개발자가 스크립트 언어등 러닝 커브가 낮은 언어를 이용하여 서버쪽에 구현을 같이하는 풀스택 개발자 형태로 전환되는 현상이 가속화될 것이고, 이에 맞물려서 쉽게 인프라를 사용할 수 있게 하는 클라우드 컴퓨팅 환경의 활용이 플랫폼 형태로 되어 있는 PaaS를 중심으로 활용될것이다.

또한 빅데이타에 대한 활용 부분이 대기업 뿐 아니라, 저 자본에 소인원인 스타트업 앱 개발에도 사용이 되는 대중화의 국면을 맏을 것이라고 보는데, 클라우드 서비스 형태로 제공되는 빅데이타 분석등의 플랫폼을 중심으로 무료 또는 저 비용의 서비스가 활용 될것이며, AB 테스팅 서비스의 활성화로 사용자의 반응을 기반으로 하는 개발이 가속화 될것으로 보인다. 또한 고급 머신 러닝 알고리즘이 오픈소스화 되고, 서비스 API화 되면서 대중화 국면을 맞을 것이다.