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


Archive»


 
 

Google 앱앤진에 node.js 애플리케이션을 배포하기


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

PaaS 서비스란?

PaaS란 Platform as a service의 약자로, 간단하게 설명하면, Linux VM등에 직접 node.js나 기반 환경을 설치하고 디스크와 네트워크 구성, 오토스케일링등의 구성이 필요 없이, 개발자가 작성한 코드만 올려주면, 이 모든 것을 클라우드에서 대행해주는 서비스의 형태이다.

인프라 운영을 위한 별도의 작업이 필요하지 않기 때문에, 숫자가 적은 기업이나 개발에만 집중하고 싶은 기업에는 적절한 모델이라고 볼 수 있다.

근래에 스타트업 비지니스가 발달하고 또한 사용하는 기술 스택들이 복잡해짐에 따라 각각의 기술 스택에 대한 설치나 운영에 대한 인력을 두기보다는 PaaS와 같은 매니지드 서비스를 이용해서 애플리케이션을 개발하는  방식이 스타트업을 중심으로 많이 이루어지고 있다.

구글 클라우드 소개

구글 클라우드는 전세계에 걸쳐 유투브와 구글 검색, 이메일등의 서비스를 하는 구글의 인프라의 경험을 구글 외부의 개발자들에게 개방하기 위해서 개발된 클라우드 서비스이다.

글로벌을 대상으로 서비스를 하던 경험을 기반으로 글로벌 그리고 대용량 서비스에 적절한 특징들을 많이 가지고 있는데, 그 중에서 눈여겨 볼만한것이 네트워크와 빅데이타 서비스이다.

네트워크

구글은 자체 서비스를 위해서 전세계에 걸쳐서 많은 네트워크 망을 가지고 있다. 특히 전세계에 걸쳐 70개 이상의 Pop (Point of Presence)라는 서버들을 보유하고 있는데, 구글 클라우드에서 동작하는 애플리케이션은 클라이언트가 직접 그 데이타 센터의 서버로 인터넷을 통해서 접속하는 것이 아니라, 먼저 가장 가까운 Pop 서버로 연결이 된 후, Pop 서버와 구글 클라우드 데이타 센터간은 구글의 전용 광케이블을 이용해서 접속이 되기 때문에 빠른 네트워크 성능을 보장한다.

예를 들어 한국에서 미국의 서버를 접속하게 되면 일반 인터넷망을 타는 것이 아니라, 가까운 일본에 있는 구글 Pop 서버를 접속한 후에, 구글 광케이블망을 통해서 미국 데이타 센터에 접속하게 된다. 얼마전 7월에 일본-미국을 연결하는 20TB의 구글 클라우드 전용망이 오픈되었기 때문에, 훨씬 더 빠른 접속 속도를 보장받을 수 있다.

이런 특징 때문에, 구글 클라우드를 사용할 경우 여러 국가에 서비스를 제공하는 글로벌 서비스의 경우 이러한 망 가속의 잇점을 볼 수 있다.


또한 내부 네트워크 역시, 1 CPU당 2 GB의 대역폭을 제공한다. (실제 테스트해보면 1.6~1.8 GB정도가 나온다) 최대 8 CPU에 16 GB의 대역폭 까지 지원하기 때문에, 내부 노드간 연산이 많거나 또는 노드간 통신이 많은 클러스터링 솔루션을 사용할때 별도의 비용을 지불하지 않고도 넉넉한 네트워크 대역폭 사용이 가능하다.

빅데이타

구글은 사람들에게 알려진바와 같이 데이타를 기반으로 한 서비스에 강하며 특히 빅데이타를 처리하는 능력이 뛰어난 회사이다. 이러한 빅데이타 처리 기술이 클라우드 서비스로 제공되는데, 알파고와 같은 예측 통계학적인 머신러닝이나 딥러닝 이외에도, 분석 통계학적인 데이타 분석 서비스가 많은데 그중에서 특출난 서비스들로 Pub/Sub, Dataflow, BigQuery 등이 있다.

Pub/Sub은 전달 보장이 가능한 대용량 큐 시스템이다. 오픈소스 Kafka와 같은 서비스라고 보면 되고, 이러한 분산큐를 직접 깔아서 운영하기 어려운 사람들에게 쉽게 대용량 큐 서비스를 제공한다.

Dataflow는 스트리밍 및 배치 분석 시스템인데, Spark Streaming이나 Apache Flink와 같은 스트리밍 프레임웍과 유사하다고 보면된다. 윈도우,트리거,워터마크와 같은 스트리밍 서비스에서 발전된 개념을 이미 내장하고 있다.

마지막으로 BigQuery는 대용량 데이타 저장/분석 시스템으로 SQL과 같은 문법으로 데이타 분석이 가능하며, 데이타 저장 비용은 구글에서도 가장 싸다는 데이타 저장소인 CloudStorage 보다 저렴하며, 1000억개, 4TB의 레코드에 대해서 like 검색을 하는데 소요되는 시간이 불과 30여초로, 빠른 성능을 보장한다. (이 30초 동안에 CPU가 수천개, DISK역시 수천개가 사용된다.)


구글 클라우드 앱앤진

오늘 살펴볼 서비스는 구글 클라우드 중에서도 앱앤진이라는 PaaS 서비스이다. 구글은 처음 클라우드 서비스를 시작할때 PaaS 기반의 서비스를 제공하였고, 내부적으로도 PaaS 서비스를 오랫동안 제공해온 만큼, 진보된 형태의 PaaS 플랫폼을 가지고 있다.

그중에서 이번에는 새롭게 앱앤진 Flex environment 라는 새로운 서비스를 소개 하였다.

Flex environment에는 기존의 Java,PHP뿐 아니라, 요즘 스타트업등에서 많이 사용되는 Python, Ruby on rails 그리고 node.js를 지원한다.

그리고 재미있는 점 중의 하나는 일반적인 PaaS가 VM에 대한 로그인 (telnet 이나 SSH)를 지원하지 않는데 반하여, Flex environment 는 SSH 로그인을 제공함으로써, 고급 사용자들에게 많은 기능과 디버깅에 있어서 편의성을 제공한다.

계정 가입

자아 그러면 이제, 구글 앱앤진 Flex environment를 이용하여, node.js 애플리케이션을 배포해보도록 하자.

먼저 GCP 클라우드를 사용하기 위해서는 구글 계정에 가입한다. 기존에 gmail 계정이 있으면 gmail 계정을 사용하면 된다. http://www.google.com/cloud 로 가서, 좌측 상당에 Try it Free 버튼을 눌러서 구글 클라우드에 가입한다.




다음 콘솔에서 상단의 Google Cloud Platform 을 누르면 좌측에 메뉴가 나타나는데, 메뉴 중에서 “결제" 메뉴를 선택한후 결제 계정 추가를 통해서 개인 신용 카드 정보를 등록한다.


개인 신용 카드 정보를 등록해야 모든 서비스를 제한 없이 사용할 수 있다.  단 Trial의 경우 자동으로 한달간 300$의 비용을 사용할 수 있는 크레딧이 자동으로 등록되니, 이 범위를 넘지 않으면 자동으로 결제가 되는 일이 없으니 크게 걱정할 필요는 없다. (사용자가 Plan을 올려야 실제 카드에서 결재가 된다. 그전에는 사용자의 카드에서 결재가 되지 않으니 걱정하지 마시기를)


프로젝트 생성

계정 생성 및 결제 계정 세팅이 끝났으면 프로젝트를 생성한다.

프로젝트는 VM이나 네트워크 자원, SQL등 클라우드 내의 자원을 묶어서 관리하는 하나의 집합이다. 여러 사람이 하나의 클라우드를 사용할때 이렇게 프로젝트를 별도로 만들어서 별도로 과금을 하거나 각 시스템이나 팀별로 프로젝트를 나눠서 정의하면 관리하기가 용이하다.


화면 우측 상단에서 프로젝트 생성 메뉴를  선택하여 프로젝트를 생성한다.



프로젝트 생성 버튼을 누르면 아래와 같이 프로젝트 명을 입력 받는 창이 나온다. 여기에 프로젝트명을 넣으면 된다.


node.js 애플리케이션 준비

클라우드 프로젝트가 준비되었으면, 이제 구글 클라우드에 배포할 node.js 애플리케이션을 준비해보자.

Node.js 애플리케이션은 Express 프레임웍을 이용한 간단한 웹 애플리케이션을 작성해서 배포하도록 한다.

기본적으로 nodejs와 npm이 설치되어 있다고 가정한다. 이 글에서는 node.js 4.4.4 버전과 npm 2.15.1 버전을 기준으로 작성하였다.

Express generator 설치

Express 프로젝트는 Express 프로젝트 고유의 디렉토리 구조와 의존되는 파일들을 가지고 있다. 그래서 프로젝트를 생성하려면 Express generator가 필요하다. Express generator가 Express 프로젝트에 맞는 프로젝트 구조를 생성해주는데, Express generator를 설치하려면 아래 그림과 같이

% npm install express-generator -g

명령을 사용하면 설치가 된다.



프로젝트 생성

Express generator 설치가 끝났으면 이제, express 프로젝트를 생성해보자.

다음 명령어를 이용하여 helloappengine이라는 Express 프로젝트를 생성한다.

% express --session --ejs --css stylus helloappengine




Express 프로젝트 및 Express 프레임웍에 대해서는 http://bcho.tistory.com/887 http://bcho.tistory.com/888 글을 참고하기 바란다.

코드 수정

생성된 코드에서  ~/routes/index.js 파일을 다음과 같이 수정한다.


var express = require('express');

var router = express.Router();


/* GET home page. */

router.get('/', function(req, res, next) {

 res.render('index', { title: 'Hello Appengine' });

 console.log('Hello Appengine');

});


module.exports = router;


의존성 모듈 설치와 node.js 런타임 버전 정의

Express 애플리케이션 개발이 다 끝났다. Express 애플리케이션을 실행하려면, Express 프로젝트에 필요한 모듈들을 설치해야 하는데, 의존 모듈들은 ~/package.json에 이미 자동으로 생성되어 있다.

이 파일을 다음과 같이 수정한다.

“engines”라는 항목에 node.js의 버전을 아래와 같이 명기하는데, 이는 구글 앱앤진이 이 애플리케이션을 수행할때 어느 버전의 node.js를 가지고 수행을 할지를 지정한다.


{

 "name": "helloappengine",

 "version": "0.0.0",

 "private": true,

 "scripts": {

   "start": "node ./bin/www"

 },

 "engines":{

    "node":"4.4.4"

 },

 "dependencies": {

   "body-parser": "~1.15.1",

   "cookie-parser": "~1.4.3",

   "debug": "~2.2.0",

   "ejs": "~2.4.1",

   "express": "~4.13.4",

   "morgan": "~1.7.0",

   "serve-favicon": "~2.3.0",

   "stylus": "0.54.5"

 }

}




이 의존성 모듈 설치는 package.json 파일이 있는 디렉토리에서 아래와 같이

% npm install

명령어만 실행해주면 자동으로 설치된다.


테스트

샘플 애플리케이션 개발 및, 이를 실행하기 위한 환경 설정이 모두 끝났다.

그러면 이제 샘플 애플리케이션을 로컬에서 실행해보자.

실행은 ~/ 디렉토리에서 다음과 같은 명령을 실행하면된다.

% node ./bin/www



실행한 후, 결과를 확인하려면 http://localhost:3000 번으로 접속하면 아래와 같은 결과가 나오는 것을 확인할 수 있다.



구글 앱앤진으로 배포 준비

애플리케이션 개발 및 테스트가 끝났으면 이제 구글 앱앤진으로 이 애플리케이션을 배포해보자.

app.yaml 파일 작성

구글 앱앤진 Flex environment 로 애플리케이션을 배포하기 위해서는 애플리케이션에 대한 기본 정보를 app.yaml에 정의해야 한다. 이 파일은 배포할 node.js 애플리케이션이 있는 ~/ 디렉토리에 위치 시킨다.

runtime은 어떤 언어 (node.js , ruby 등)을 지정하고, VM으로 실행할지를 vm:true 로 정의한다.


runtime: nodejs
vm: true


Google Cloud SDK 설치

다음으로 배포를 하려면, gcloud라는 명령을 사용해야 하는데, 이 명령어는 Google Cloud SDK를 설치해야 사용할 수 있다. Google Cloud SDK는 https://cloud.google.com/sdk/downloads 에서 다운 받아서 설치한다.

Google cloud SDK 설정하기

Google cloud SDK 설치가 끝났으면, 혹시 google cloud SDK가 업데이트 되었을 수 있으니, 다음 명령어를 이용하여 최신 SDK로 업데이트 한다. (알파,베타 버전과 같은 신 기능이 들어가면 업데이트가 된다.)


% gcloud component update


라는 명령어를 수행하면 다음과 같이 업데이트 된 내용이 나오면서 업데이트 를 할 것인지 물어보고 “Y”를 선택하면 자동으로 Google Cloud SDK를 업데이트 한다.



Google Cloud SDK 배포가 끝났으면 gcloud 명령을 이용하기 위해서 초기화 작업을 해야 한다. 초기화 작업은 gcloud 명령을 사용했을때, 내 구글 클라우드 프로젝트 중 어느 프로젝트에 명령을 내릴 것인지, 그리고 어떠한 구글 계정을 사용할것인지 그리고 명령을 내릴때 어떤 리전을 디폴트로 해서 명령을 내릴것인지를 정하는 것이다. 사용자에 따라서 여러개의 프로젝트를 가질 수 도 있고, 또한 관리 목적상 여러개의 클라우드 계정을 가질 수 도 있기 때문이다.

초기화 방법은 다음과 같이 명령어를 실행하면 된다

% gcloud init

이 명령을 사용하면, 앞에서 언급한 바와 같이, gcloud 명령을 내릴 때 사용할 계정과, 디폴트 프로젝트 그리고, 리전을 선택하게 된다.


이제 배포를 위한 모든 준비가 끝났다.

구글 앱앤진으로 배포

이제 배포를 해보자. 배포는 매우매우 쉽다.

앞서 작성한 Express 애플리케이션이 있는 ~/ 디렉토리에 가서 다음 명령어를 수행하면 된다.

% gcloud app deploy

명령을 실행하면 다음과 같이 node.js 애플리케이션이 배포 되는 과정을 볼 수 있다.

배포는 수분이 소요된다. (내부적으로는 Docker 컨테이너를 이용하여 배포가 된다.)

서비스 기동확인

배포가 완료되면 자동으로 서비스가 기동이 된다.

서비스 기동 확인은 http:{프로젝트명}.appspot.com 으로 자동으로 서비스가 뜨게 된다.

해당 URL을 접속해보자. 여기서는 프로젝트명이 “useful-hour-138023”이다.


서비스가 정상적으로 기동 됨을 확인하였다.

모니터링

구글 클라우드 콘솔에 들어가 보면 현재 기동중인 node.js 앱을 확인할 수 있다.

콘솔에서 “App Engine”을 선택하면 다음과 같은 화면이 나온다.



아래 Instances 부분을 보면 Flexible 이라는 이름으로 현재 2개의 인스턴스가 기동되고 있고, 평균 QPS (Query Per Second : 초당 처리량)이 10.898 인것을 확인할 수 있다.


매니지드 서비스이기 때문에, 부하가 늘어나면 자동으로 인스턴스를 추가하고 줄어들면 자동으로 삭제하여 부하에 탄력적으로 대응을 자동으로 해준다.


로그 모니터링은 클라우드 콘솔에서 “Logging”이라는 메뉴를 선택하면 아래와 같은 화면이 나온다.


앱앤진 관련 request log 및 기타 로그들이 다 나오는데, 앞서 샘플코드에서 console.log(“Hello Appengine”) 명령어를 이용하여 Stdout으로 “Hello Appengine”이라는 문자열을 출력하도록 하였기 때문에, 이 문자열이 제대로 출력되었는지를 확인해보자.

App Engine 을 선택하고, 다음 “stdout”을 선택하면 위와 같이 앱앤진의 Stdout으로 출력한 로그들만 볼 수 있는데, 위와 같이 “Hello Appengine” 문자열이 출력된것을 확인할 수 있다.

수정 및 재 배포

그러면 다음으로 애플리케이션을 수정해서 배포해보자. routes/index.js를 다음과 같이 수정해보자


var express = require('express');

var router = express.Router();


/* GET home page. */

router.get('/', function(req, res, next) {

 res.render('index', { title: 'Hello Appengine is updated' });

 console.log('Hello Appengine is updated');

});


module.exports = router;



코드 수정이 끝났으면 배포를 해보자. 재 배포 역시 간단하게

%gcloud app deploy

명령어를 수행하면 간단하게 배포가 된다.

배포가 완료된 후 URL로 들어가서 확인을 해보면


애플리케이션이 업데이트 된것을 확인할 수 있다.

롤백

앱앤진의 장점 중에 하나가 배포도 쉽지만, 롤백도 매우 쉽게 가능하다는 것이다.

클라우드 콘솔에서 App Engine을 선택하고, 아래와 같이 Versions라는 메뉴를 선택하면 아래와 같은 그림을 볼 수 있다.




현재 두개의 버전이 배포되어 있고, 위의 최신 버전에 Traffic Allocation이 100%로 되어 있는 것을 확인할 수 있다. 이는 새로 배포된 버전으로만 트래픽이 100% 가고 있다는 의미인데, 롤백은 트래픽을 예전 버전으로 라우팅 해주고, 새버전의 서비스를 정지 시키면 된다.


아래 그림과 같이 예전 버전을 선택한 후에, 상단 메뉴에서 “Migrate Traffic”을 선택한다.



그러면 아래와 같이 트래픽이 이전 버전으로 100% 가고 있음을 확인할 수 있다.

그리고 나서 새 버전을 선택한 후 상단의 STOP 버튼을 눌러주면 아래 그림과 같이 새버전의 상태가 Serving 에서 Stopped로 변경된것을 확인할 수 있다.




예전 버전으로 롤백이 잘 되었는지를 확인해보자.

아래 그림처럼 예전 버전으로 롤백이 되었음을 확인할 수 있다.



버전별로 트래픽 분산하기

앱앤진의 장점 중의 하나가 여러 버전을 유지할 수 있고, 버전간에 트래픽을 자유롭게 조절할 수 있다. 예를 들어서 v1으로 90%, v2로 10% 의 트래픽을 보내는 것등이 가능하다.


이렇게 트래픽을 조절하는 것은 크게 2가지 방법으로 활용이 가능한데, 서버단의 A/B 테스팅과 카날리 테스팅이다.

A/B 테스팅은 사용자를 두개 이상의 집단으로 나눈후, 기능 A,B 에 대한 반응을 본 후, 반응이 좋은 기능을 선택하는 방식으로, 모바일 클라이언트단에서 많이 사용되고, 서버단에는 구현이 쉽지 않았는데, 트래픽을 버전별로 나눠서 주는 기능을 사용하면 손쉽게 A/B 테스팅을 수행할 수 있다.


다음으로 카날리 테스트는 옛날에 광부들이 광산에 들어갈때 카나리아 새를 데리고 들어가서 유독가스가 나오면 카나리아 새가 먼저 죽는 것을 보고 위험을 감지하는 방법에서 유래된것으로 서버 배포에서는 전체 사용자를 대상으로 새 버전을 배포하는 것이 아니라 1~2%의 사용자에게 배포해보고 문제가 없으면 전체 사용자에게 배포하는 개념으로, 마찬가지로 v2에 1~2%의 트래픽만 할당하고 나머지 98~99%는 v1에 할당하는 방식으로, 해서 v2에 대한 안정성 검증을 한 후에, v2를 전체 배포 하는데 활용할 수 있다.


버전간 트래픽 비율을 지정하는 방법은 클라우드 콘솔의 앱앤진 메뉴에서 Version을 선택하고 상단 메뉴에서 → 가 두개 겹쳐진 아이콘 (맨 우측)

를 선택하면 아래와 같이 Split traffic 이라는 메뉴가 나온다.

여기서 1개 이상의 Version을 추가한 후에, 각 버전으로 보낼 트래픽의 비중 (%)을 정의한다.






위의 예제에서는 xxx4403 버전으로 30%, xxxx3136 버전으로 70%의 트래픽을 보내도록 하였다.

설정을 완료한 후에 SAVE를 누르고, 다시 Version 부분을 보면, 수분 있다가 아래 그림과 같이 xxxx3136 버전에 70% 트래픽이 xxx4403 버전으로 가게 된다.


부가 기능에 대해서

구글 클라우드에서 앱앤진만 쓸 수 있는 몇가지 좋은 서비스 들이 있는데, 다음과 같다.

매니지드 memcached

앱앤진에서는 구글 매니지드 memcached 서비스를 사용할 수 있다 별도의 설정 없이 바로 사용이 가능하며, 최대 100GB 까지 사용이 가능하다. (100GB 이상도 요청하면 사용이 가능) Shared memcached의 경우에는 별도의 비용없이 일반적인 캐쉬로 사용이 가능하지만, 용량이나 성능등이 보장이 되지 않으니 주의가 필요하다.

https://cloud.google.com/appengine/docs/python/memcache/

보안 스캐닝 (Security Scanning)

매우 유용한 기능중의 하나가 보안 스캐닝 기능이다 앱앤진 메뉴에서 Security Scanning이라는 메뉴를 선택하면 앱앤진으로 개발한 웹 사이트에 대한 보안 스캐닝을 할 수 있는데, 한번만 스캐닝할 수 도 있고 자동 스케쥴 방식으로, 주기적으로 스캐닝 하는 것도 가능하다.


보안 정책이 수시로 업데이트 되기 때문에, 정기적으로 보안 스캔을 하는 것을 권장한다.

텍스트 검색 (Search)

node.js에는 지원하지 않지만, Python,Java,PHP,Go (앱앤진 Standard environment)에서만 지원되는 기능중 하나는 구글 검색 엔진과 같은 검색 엔진을 지원한다. 텍스트 검색 HTML 그리고 GEO_POINT (위/경도 기반 검색)이 가능하다.

https://cloud.google.com/appengine/docs/java/search/?hl=en_US

결론

지금까지 간략하게나마 구글 클라우드에 대한 소개, 앱앤진에 대한 개념 및, 간단한 node.js express 애플리케이션을 작성해서 배포해봤다. 다음글은 앱앤진에 대한 조금 더 구체적인 환경에 대해서 알아보도록 하겠다.


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



조대협(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.09.25 13:58 | Posted by 조대협

"권도균의 스타트업 경영" 중에서.


기업 문화란 무엇일까? 기업 문화는 규율의 성격을 갖는다. 상벌과 같은 조직 경험을 통해 구성원이 특정한 행동을 하도록 만드는 가치들의 모음이다.

(중략).

암묵적으로 규율화되어 조직 내에 뿌리내린 것이 훨씬 더 많다. 조직 문화란 “조직 구성원들로 하여금 다양한 상황에 대한 해석과 행위를 불러일으키는 조직 내에 공유된 정신적 가치” 라고 정의할 수 있다. 회사의 목표를 위해 조직원이 해야 할 일이 무엇인지 가르쳐 준다면 조직 문화는 그일을 기꺼이 수행하도록 동기를 부여하고 그가 헌신적으로 노력하게 한다. 그리고 갈림길에 섰을때 무엇을 선택해야 하는지 결정을 할 수 있도록 하는 것이 바로 조직의 정신이다.

(중략)

조직은 민감하기 때문이다. 그이야기가 꼭 사장의 입에서 나올 필요도 없다. 직월들끼리 직원과 팀장, 임원들 간에 조직 사이에서 하는 말,행동,표정 모두가 서로에게 영향을 끼치며 하나의 암묵적 규율로 쌓아간다. 문서로 만들어진 규정보다 CEO의 지나가는 말 한마디, 표정,행동(결정) 하나가 더 큰 신호가 된다.

CEO의 행동과 결정에 일관성이 없으면 조직이 어떻게 행동해야 할지 혼란 스러워 한다. 그래서 직원들은 CEO가 이랬다 저랬다 한다고 불평한다.


형식적으로 따르는 규율과 실질적으로 맏는 규율이 다른 이중성이 깊어지면서 조직은 정렬되기보다 각자 살길을 알아서 찾으면서 무법천국이 된다.


(중략)

대부분의 사람들은 자신의 미션에 대한 충성심과 신뢰로 평가하는 그런 조직에서 일하길 간절히 바라고 있다. 신뢰가 없으면 명시적으로 만들고 구축한 모든것들이 무너진다. 실력은 없는데 줄 잘 선 친구가 승진했다. 혹인 사장과 학교 선후배끼리 모든 것을 결정한다는 식의 믿음이 퍼지면 훌륭한 인사평가 시스템은 무용 지물이 되고, 동아줄을 붙잡는게 그 기업의 문화가 된다. 자율적으로 일하라고 말하면서도 정작 지원이 동의하지 않는 일을 시키거나, 자율적으로 한 일의 결과에 대해 불평을 하면, 시킨 일이나 열심히 하고 자발적으로 일하지 않는 것이 기업 문화로 자리 잡는다.


사람들은 좋은 조직 문화를 ‘좋은 인간 관계’로 오해하기도 한다. 다른 사람들과 싸우지 않고 잘 어울리는 조직을 좋은 문화를 가진 조직으로 생각한다.

“좋은 조직문화를 가지고 있는지 여부에 대한 판단 기준으로는 조직이 달성하는 성과이지 상호 조화가 아니다. 우수한 성과에 대한 만족 그리고 회사에서 여러 업무들 사이의 적절한 조화를 바탕으로 하지 않는 ‘좋은 인간과계’는 실질적으로는 좋지 않은 인간 관계다. 이는 사람들이 무조건 순응 하도록 하고 또 사람들을 위축 시킨다.


피터 드러커가 이야기 했다. 그는 어느 대학 총장이 한 말을 영원히 잊을 수 없다고 하면서 인용했다.

“일급의 교수가 강의를 제대로 하도록 여건을 마련해주는 것이 나의 업무다. 그가 자신의 동료들이나 나와의 관계가 좋은가 하는 것은 중요하지 않다. 사실 진정으로 훌륭한 교수들 가운데 두가지 일을 모두 잘하는 교수는 소구에 지나지 않는다. 분명히 말하건데 대학에는 이런저런 문제가 없는 교수들이 별로 없다. 하지만 그들이 잘만 가르친다면야 그것말고 대학에서 달리 무슨 문제가 있겠는가?”


(중략)

조직 문화의 신뢰의 정점은 CEO이다. 사람들은 친절한 CEO를 원할것이라고 생각하지만, 친절한 성격보다는 일관되며 원칙을 따르는 CEO를 원하고 더 신뢰한다.

CEO가 조직 문화의 방향과 회사가 추구해야 하는 가치를 결정하지만, 스스로가 거기에 가장 먼저 복종해야 한다. 똑똑한 직원들은 CEO의 말과 행동과 표정의 미묘한 차이를 간파하고 일관성을 체크하고 간파한다. 감추고 싶어도 드러나는 것이 CEO의 인격과 욕심과 통합성이다. 조직 문화는 CEO 인격에 대한 신뢰이다.

요즘 팀 문화에 대한 관심이 많아서 경영과 변화 관리에 대한 책들을 보고 있는데, 

대부분 큰틀은 린 스타트업 프레임웍과 유사하지만 군데군데 배워야할 내용들이 많다.

몇 가지 다시 생각해야 하는 구절들을 정리해보면 다음과 같다.



권도균의 스타트업 경영 수업

저자
권도균 지음
출판사
로고폴리스 | 2015-08-05 출간
카테고리
경제/경영
책소개
스타트업 경영의 본질을 본격적으로 다룬 국내 최초 스타트업 경영...
가격비교



엔지니어들을 많이 채용 한다고 해서,더 많은 일을 할 수 있는 것은 아닙니다. 때때로는 생산성이 떨어지는 일도 있지요. 끝나는 일보다 안 끝나는 일이 확실히 더 많아질겁니다. 그 이유는 바로, 아주 대단한 사람들이라도 실상은 포탄인 경우가 많기 때문입니다. 

하지만 여러분의 회사에 필요한 것은 대포이죠. 대포를 통하여서만 포탄을 발사할 수 있습니다. 그러므로 회사의 생산성은 대포를 통해서만 포탄을 발사할 수 있습니다. 그러므로 회사의 생산성은 대포를 확보해야만 늘어납니다. 그 후에 포탄을 옆에 둔다면, 정말 많은 일들을 할 수 가 있지요. 

(중략)

대포란 무엇인가를 정의해보자면, 문제의식에서 부터 구체적인 아이디어를 이끌어내고 사람들을 모아 제품을 완성시켜 문제를 해결하는 사람들이라 할 수 있겠습니다.


일이 많아져서 사람을 채용하고 난 후에 거꾸로 채용한 직월을 먹여살리기 위해 일을 찾아야 하는 고민에 빠진 회사들이 많다. 개인의 인생도 그렇지만 먹고 살기 위해 혹은 먹여 살리기 위해 사업을 운영하는 단계로 접어들면 잘못된 갈림길로 접어든 것이다. 낮은 단가의 용역을 받아들일 수 밖에 없고, 그러면 좋은 직원들은 가장 먼저 회사를 그만 둔다. 용역을 마무리하기 위해서는 다른 직원을 채용해야 하는데, 그보다 못한 직원을 채용하게 된다. 이렇게 회사는 악순환의 고리에 들어간다.



경영의 목표는 뛰어난 사람들을 데리고 훌륭한 결과를 내는 것이 아니라, 평범한 사람들을 데리고 탁원한 결과를 내도록 만드는 활동이다. 세상에는 뛰어난 사람들이 부족하기 때문이다.


스타트업이 자주 하는 말이 있다.

“그렇게 이야기 했는데 직원들이 못 앗알 듣는다.”

(중략) CEO는 오차 방정식을 풀 수 있지만, 조직의 직원들이 그 방정식 풀기를 기대하는 것은 무리다. 조직과 직원에게는 일차 방정식을 제시해야 한다. 회사의 성공을 가능케 하는 간단하고 분명한 하나의 공식을 제시해야 한다. 조직의 비전은 분명하고 단순하게 정의하고 제시 해야 한다.

(중략)

“이어 원 랩스에서 조언자이자 투자자로서 스타트업을 평가할때 우리는 OMTM (One Metric That Matters)를 얼마나 명확하게 이해하고 추적하는지를 보았다. OMTM을 즉시 말할 수 있고 현재 단계와 일치하면 그 스타트업은 긍정적인 평가를 받았다. 반면 OMTM을 모르거나 단계에 맞지 않는 지표이거나 지표가 여러 개 이거나, 지표 현재값을 모르면 그 스타트업은 문제가 있다고 판단했다. 하나의 핵심 지표는 창업자의 경영 철학으로 결정해야 하는 것이다. 그것을 결정하지 못하는 창업자는 아직 자신의 사업이 무엇인지 잘 모르고 있다는 말이다. 당영히 조직원들도 같이 모를 수 밖에 없다.


사람들은 솔직하게 말하지 않는다. 사름들은 상대방이 어떤 생각을 하는지 고려해 말하고 행동한다. 고객의 마음을 알기 힘들지만 함께 일하는 직원의 마음을 알기도 또 얻기도 힘들다. 좋은 의미로든 나쁜 의미로든 서로를 배려하느냐 커뮤니케이션에서 오류가 생긴다. 속마음을 이야기하려고 노력하지 말고 그냥 무엇을 원하는지를 직접 이야기하라. 빙빙 돌려 배경을 설명하면서 이해하고 알아서 자발적으로 일해주기를 기대하며 고문하지 암ㄹ고 그냥 이것을 해달라고 요구하라



경력 직원들 가운데 손발이 될 직원이 있어야 그 일을 할 수 있다는 말을 자주 하는데, 그말은 이렇게 해석할 수 있다.

‘나는 필요 없는 사람이니 나 대신 진짜 일을 할 수 있는 그 직원을 채용하고 나를 해고하세요’

그런데 웃기는 일은 많은 조직이 그 일을 잘할 사람을 채용해서 그 일을 할 수 없다는 사람 밑에 배치 한다는 사실이다. 할 줄 하는 사람에게 권한을 줘야 하는데 반대로 한다. 그러면 조직의 허리에는 보고 받고 보고 하고, 지시 받고 지시 하면서 잡음만 더하면서 의사 소통과 일의 진행을 방해하는 중간 관리자로 채워진다.


초기 직원을 채용할 때, 창업자는 자신이 경험하지 못한 부분과 부족한 부분을 보강하는 목적으로 해야 하는데, 조직과 시스템을 갖추는 것을 선망하는 초보 CEO는 성급하게 중간 관리자를 세워 시스템을 구축하려는 실수를 범한다. 중간 관리자가 필요하긴 하지만 도저히 버틸 수 없을때 까지 회사는 수평적이라야 한다. 수평적 조직이란 직급 없이 이름을 부르는 것으로 이루어지는 것이 아니라, 직원 한 사람 한 사람이 누구도 대체할 수 없는 독립된 업무 권한과 책임을 갖는 것을 말한다. 직원에게 줄 권한을 뺏어 중간 관리자에게 주지 마라. 게으른 CEO는 중간 관리자의 요약 정리된 보고를 좋아하고 용기가 없는 CEO들은 조직의 문제를 정면으로 마주해 해결하려 하기보다 중간 관리자 뒤에 숨거나 사람을 새로이 충원해 문제를 피해가려고 한다. 그런 회사는 CEO 뿐만 아니라 중간 관리자들도 또 중간에 사람을 넣어서 그런 CEO 흉내 내게 되는 악순환이 형성된다.


40대에 다시 도전을 시작합니다.

사는 이야기 | 2015.05.12 10:09 | Posted by 조대협

40대에 새로운 도전을 시작합니다.


1990년대의 벤처, 첫 외국 회사 BEA, NHN, 오라클, 마이크로소프트,사업, 중간 중간 프리렌서 까지,그리고 대기업까지. 40대에 올때까지 정말 파란만장한 시절은 보낸거 같습니다. 남들이 보면 화려하다고 할 수 있지만 와이프한테 월급도 제대로 못갔다 주고 힘들었던 시절도 많았습니다.


오랜 여행끝에 대기업에 안착을 했습니다. 2년 반이지만 정말 재미있었습니다. 이번에는 마지막이라고 안착하고 안정적인 삶을 살아 보려고 결정했습니다. M&A도 해보고, 박사님들 스카웃 할려고 미국 로드 투어도 해보고고, 글로벌 회사에서 치프 아키텍트라는 것도 해봤습니다. 짧은 시간 동안 설계한 서버 아키텍쳐만 수십개이고, 돌아가는 서버 인스턴스만 몇 백개 같습니다.

그런데 몬가 이상하더군요.. 세상은 정말 빠르게 변하고 있는데… 저는 계속 미생이 되가는 것 같았습니다. 물론 그 대기업도 많이 변하기 위해 노력 하고 있는데… (자율 출퇴근제도 있어요…!!) . 많이 허전하더라구요. 아직은 회사가 변화는 속도가 제가 변하고 싶은 속도를 못 따라 가는거 같더군요. 근데 그전 회사에서는 교육도 받고 트랜드도 배우고 발전했는데, 몬가?? 소모되는 느낌?? 채우고 발전 하는 것 보다 소모되는 느낌있었습니다.


교육은 환경 안전 교육만 기억납니다. 물론~~ 비지니스는 많이 배웠습니다. 그런데 정작 엔지니어링은 그다지 배우지 못한거 같습니다.


여기서 몇가지 이야기를 해보고 싶습니다. 한국의 대기업의 연봉 체계는 다릅니다. 사원급의 연봉이 보너스를 합치면 왠만한 중소기업 과장 부장급까지 되니까요. 그런데 대한민국에서 가장 똑똑한 사람들이 오는 회사가.. 기계적인 일만 시키다가 엔지니어가 됬다가.. 결국은 관리자가 됩니다. 근데 이 관리자는 관리를 배운 사람이 아니라서 관리를 제대로 못할뿐더러. 이 연봉을 다른데서는 받을 수 없으니까는 어떻게든 버틸라고 하니… 기술은 없고. 버티기는 해야겠고. 그래서 이런 조직에서 살아남을려면 어떻게 해야할까요?? 한국 사회는 고용 시장이 유연하지 않기 때문에 그 나이에 나가면 새로운 직업을 구하기 어렵습니다. 50대에 코딩하면서 그 월급 받기도 힘들구요. 결과는 정치 세력화 되는 것 밖에 방법이 없거나… 모르면서 쪼는 수 밖에 없겠지요.

모두가 그렇다는 것은 아닙니다. 그 간에도. 많이 바꿀라고 노력하시는 분들이 있기 때문에 바뀌고 있습니다.

(근데 웃기지 않나요? 그렇게 욕을 하면서도 그 회사 갈려고 그렇게 돈쓰고 노력하고 하는게??)

그런데, 저는 제 딸을 그런데 보내기는 아직은!! 싫습니다. 아마 제 딸이 취업을 할때는 바뀌어 있겠지요. 아니면 망하거나. 


많은 사람들이 저한테 어리석은 선택을 했다고 말합니다. 좋은 대기업에 좋은 포지션을 왜 포기하고 스타트업을 가느냐고… 기득권을 포기하는 건 어려운 일인건 사실입니다. 두달은 고민한거 같은데… 제 은사 분이 말씀 하시더군요. “해도 후회 할것이고. 안해도 후회할것이라고…” 나이 마흔을 넘어서 마지막으로 도전을 해볼까 합니다. 해보고 후회할라고요.


그래서 오늘 부터 옐로모바일의 피키캐스트에 CTO로 조인 합니다. 말도 많은 회사이지만 월 방문자 600만에, 하루 방문자가 150만명인 서비스 입니다. 급속하게 성장하고 있고 풀어야할 과제도 많지만 그만큼 할것도 많고 역량을 발휘할 수 있는 환경입니다.



 대기업과 다르게 스타트업은 빠르게 움직여야 생존하고 소유하고 있는 자원도 차이가 납니다. 말 그대로 정글인 환경인데, 기존 환경과는 다르게, 행동 하나하나가 비지니스에 바로 영향을 주기 때문에, 조금 더 기민하고 효율적으로 움직여야 합니다.


기존의 엔지니어, 아키텍트의 롤에서 임원으로 역할을 변경하면서, 생각해야하는 주제와 해야하는 일도 바뀌어 가는 것을 느낍니다. 40대의 늦은 도전이지만, 아직 젊다고 생각하고 모험을 시작합니다.


2015년 5월 12일

조대협

 


린스타트업 - #3 성장 엔진 이론

비지니스/스타트업 | 2015.05.07 01:28 | Posted by 조대협

성장엔진


린 스타트업에서는 성장 엔진이라는 개념을 사용하는데, 이 성장 엔진이란, 린 스타트업에 따르면 "회사가 지속적으로 성장을 달성하는데 쓰는 메커니즘이다. "

린스타트업에서 성장엔진을 다음과 같은 변수로 정의하고 있다.

기본적으로 스타트업의 성장은 사용자가 늘어남을 전재로 하되, 사용자가 늘어나는 것 뿐만 아닌 비지니스 모델에 따라서 다음과 같은 지표를 추가 지표로 사용한다.


1. 재방문율 : 복합 비율로 측정


대부분의 서비스들에 해당하는 지표로, 기존 사용자의 재 방문율이다.

일반적으로는 액티브 사용자를 사용하지만, 린스타트업 프레임웍에서는 "복합 비율"이라는 성장 변수를 사용한다. 

재방문율 성장 엔진의 기본 개념은 신규 고객 유치율 > 가입 해지율 이 넘는지를 살펴본다. 가입 해지율은 명시적으로 계약을 해지 않더라도 서비스를 더 이상 방문하지 않는 고객의 비율을 의미한다. (일주일 동안 한번도 로그인 하지 않은 사용자등)

즉, 매주 10%의 고객이 증가하는데, 매주 가입 해지율이 10% 이상이면 이 회사의 사용자 수는 늘어나고 있지만 실제로는 성장하지 않고 있는 것이다.

복합 비율의 계산은 

(자연 성장율) - (가입 해지율) 

이다. 즉 전체 사용자 증가율에서 해지율을 빼보면, 서비스가 성장하고 있는지 여부를 판단할 수 있다.


2. 바이럴 성장 엔진


입소문이 아닌 서비스를 사용하는 사용자가 신규 사용자를 유치하게 되는 방식

- 핫메일의 보내는 메일 끝에, 핫메일 링크를 달아서 가입을 유도 한다던가

- 페이팔을 써서 친구한테 돈을 보내면, 받는 친구가 페이팔을 가입해야 한다던가.


이렇게 기존 사용자층이 서비스 사용을 통해서 신규 사용자를 확보하는 메커니즘을 바이럴 성장 엔진이라고 한다.

바이럴 성장엔진은 "바이럴 계수" 라는 것으로 측정하는데, 계산식은 다음과 같다.

(기존 고객 1명당 신규 고객 유치율)

즉, 10명의 고객중 1명만 1명의 신규 고객을 유치했으면 바이럴 계수는 0.1이 된다.

10명의 고객이 100명의 신규 고객을 유치했으면 계수는 10이된다.


이 바이럴 계수가 1 이상이면 한명의 고객이 한명 이상의 신규 고객을 가지고 온다는 개념으로, 바이럴 성장엔진에 의존하는 회사는 이 바이럴 계수를 높이는데 초점을 둬야 한다.

이렇게 바이럴 계수를 높이는 전략으로는 친구를 추천하면 추가 용량을 주는 것과 같은 드롭 박스의 전략등을 들 수 있다.

 

3. 유료화 성장엔진


유료화 성장엔진은 , 계산 방법은 

(고객당 수익:LTV-Life time value 또는 고객당 잠재가치 ) - (고객당 신규 유치비용:CPA-Cost per aquisition )

유료 서비스가 아니더라도, 광고등을 통해서 수익을 창출하는 서비스의 경우에도, 고객당 발생 가능한 광고 수익이 "고객당 수익" 개념이 된다.

페이스북과 같은 SNS 서비스가 있다고 가정하자 이 서비스에 신규 고객을 유치하기 위해서  들어 10억의 돈으로 100만명의 사용자를 모집했다고 하자 , 인당 고객 유치 비용은 1000원이고, 이 한명의 고객이 평생 광고를 보면서 발생할 수 있는 수익은 8만원이라고 할 때, 수익률은 8만원 - 1000원 = 79000원이다.

유료화 성장엔진을 사용하는 기업은, 이 LTV-CPA의 차이를 꾸준히 늘려나가는 것이 필요하다. 

※ 주) 마치 ROI(Return of investment) 개념 같은데. 게임과 같은 서비스가 적절한 모델일듯.



선택과 집중


기술적으로는 두개 이상의 성장 엔진을 사용할 수 있기는 한데, 책의 저자의 말에 따르면 성공한 스타트업은 하나의 성장 엔진에 집중한 경우가 많다고 한다.

하나의 성장엔진에 집중하고 회사의 모든것을 그 성장엔진이 돌아가는데 필요한 방향으로 특화한다. 세 엔진을 모두 선택하게 되면 복잡해지고 집중하기 어렵기 때문에 운영이 어렵다.


성장 엔진 부분은 세번을 읽고 도저히 이해가 안되서 글로 재정리하면서 다시 이해중인데, 결론적으로 보면, 회사의 성장을 이끄는 지표가 무엇인지를 조금 더 구체적으로 정의해주고, 기존의 허수 지표를 피할 수 있는 조금 더 효과적인 지표를 3가지 성장엔진 모델을 통해서 제시해주고 있다. 특히 스타트업의 서비스를 DAU나 MAU 등과 같은 액티브 사용자 계수으로만 측정하는 경우가 많은데  이보다는 복합 비율과 같은 

린 스타트업의 프로세스 개요

일단 현재 이해한것 까지 중간 정리, 린스타트업은 도요타의 린 방법론을 기반으로 IMVU CTO인 에릭리스가 정리한 스타트업의 프로세스이다.

기본적으로 스타트업의 제품 및 서비스 개발의 행위를 학습으로 정의하고 있으며, 빠르게 최소한의 기능을 가지고 있는 서비스를 빠르게 개발하여 시장에 릴리즈한 후 고객의 반응을 수치화한 데이타를 기반으로, 판단하여 이를 기반으로, 제품의 개발 방향이 맞는지를 학습하여 끊임없이 서비스를 수정/개발해 나가는 프로세스이다.

전체적인 프로세스를 도식화 하자면 다음과 같다.


※ 이 그림은 일반적으로 소개되는 린스타트업의 프로세스가 아니라, 본인이 이해하고 내용을 가감한 프로세스이다.

 



가설과 구현


먼저 가설을 세우고, 이 가설(아이디어)를 기반으로 서비스를 개발한다. 이때, MVP (Minimum Viable Product)이라는 개념을 사용하는데, 컨셉을 구현하기위한 최소한의 기능만을 가지고 있는 제품(또는 서비스)를 정의한다.

일반적으로 고객은 자신이 무엇을 원하는지를 잘 모른다. 소프트웨어 개발에서 요구 사항 분석이 실패하는 이유중의 대부분이 고객이 요구 사항을 제대로 정의하지 못하기 때문이다. 왜냐? 고객도 무엇을 원하는지를 모르기 때문에, 그렇지만, 고객은 자기가 좋아하는 것과 좋아 하지 않는 것에 대한 구별할 수 있는 능력은 있다. 그래서, MVP를 가지고 고객에게 제시하면 그때 부터 고객은 그 제품이 좋은지 나쁜지에 대해서 이야기할 수 있고, 그 피드백을 기반으로 제품을 개선할 수 있다.

제품이 개선될것을 전제로 하기 때문에, 커다른 덩치 큰 제품을 만들지 않는다. 다 만든 다음에, 나중에 그 방향을 바꾸게 되면, 다 만드는데도 많은 시간이 소요될뿐더러 만든 다음에, 전체 기능을 폐기 하게 되면 그 비능이 크기 때문이다.

MVP 부터 시작해서 고객의 피드백과 반응을 통해서 제품의 방향을 유연하게 설정하면서 고객이 만족할만한 제품을 진화적으로 만들어 나간다.


지표의 정의와 측정


고객의 피드백과 반응을 수집하고 이를 제품에 반영하려면, 이를 수치화 즉 지표화할 필요가 있다. 지표화를 하기 위해서는 무엇을 지표화 해야할지를 결정해야 한다.

서비스 기능 추가 개선후, 가입자 수가 증가 했는지? 아니면 서비스 사용 시간이 늘어났는지? , 어떤 작업을 했으면 그것이 어떤 효과를 나타내는지를 정량적으로 수치화해야 한다.

일반적으로 스타트업이 실패하는 이유중의 하나가, 이 정량화를 기반으로한 측정을 하지 않거나, 적절하지 않은 지표를 정했기 때문인 경우가 많다. 이를 허수지표라고 하는데, 이 허수 지표에 대해서는 뒤에서 다시 언급하도록 한다.


1) AB 테스트

지표 측정 방식에서 효과적으로 활용할 수 있는 추가적인 기법중의 하나가 AB 테스트이다. AB테스트는 같은 서비스를 두개의 고객군을 나눠서 A고객과 B고객에 서로 다른 기능을 제공하여 그 피드백을 살펴보는 방식이다.

신규 기능을 개발했을때,  새로운 기능을 무조건 운영 시스템에 반영을 하는 것이 아니라, 일부고객군에게만 적용한 후에, 그에 대한 반응을 정량적으로 측정한 후, 반응이 좋은 경우에만 그 기능을 운영시스템에 전체 반영하는 기법인데, AB 테스트를 위해서는 먼저, 여러개의 고객군에 서비스를 차등 제공할 수 있는 개인화 기능이 제공되어야 하며, 또한 기능 구현시 마다 배포를 할 수 있는 자동 배포 (Continues Delivery : aka. CD) 프레임웍이 준비되어야 한다.

그리고, 각 테스트 표본집단 별로 신규 기능에 대한 고객 반응을 측정할 수 있는 리포팅 시스템 개발이 전제되어야 한다.

자동화나 리포팅 시스템은 이러한 AB 테스트를 효율적으로 할 수 있는 도구에 불과하다. 무엇보다 중요한것은 AB 테스트를 위한 표본 집단의 선출 방식과, 고객의 반응을 어떤 지표로 정의할 것인가가, 가장 중요하다.


 2) 빅데이타 분석

린 스타트업 프레임웍에서 가장 중요한것은 가설에 대한 테스트 결과를 지표를 통해서 분석해야 하는 것인데, 이를 위해서는 데이타 분석이 필요하다.

단순히 정형화된 데이타를 수집해서 간단한 리포트만을 뽑아내는 것이 아니라, 방문로그,체류 시간, 광고 집행 시기, 마케팅 시기등 다양한 소스에서 오는 데이타에 대한 상관 관계 분석을 통해서 지표를 재정의 및 발전 시켜 나가야 하는데, 이를 위해서는 향후 분석과 데이타에 숨어있는 상관 관계 분석을 위해서 가급적 많은 데이타를 저장할 필요가 있다. 이런 많은 데이타를 정재되지 않은 상태로 저장하기 위해서는 큰 데이타 저장소가 필요한데, 이러한 개념은 과거의 데이타 웨어 하우스와 유사한 data lake 라는 곳에 데이타를 모으고, R등의 데이타 분석 언어를 이용하여 데이타에서 지표를 산출해내고, 이를 리포팅 시스템을 통해서 뽑아낼 수 있다. (이구조에 대해서는 이전 포스트 http://bcho.tistory.com/984 를 참고하기 바란다.)

결과적으로, data lake 나 리포팅등 지표를 확인할 수 있는 통계 시스템이 필요한데, 기존과 데이타의 양이 틀리기 때문에, 빅데이타 기반의 분석 시스템은 린 스타트업 프레임웍에서 대단히 필요한 부분이 된다.

그렇다고 스타트업에서 Spark,Hadoop, DW와 같은 고급 기술을 기반으로 대규모 분석 시스템을 만들 수 는 없는 노릇이고, 가급적이면 처음에는 구글 애널러틱스나, 클라우스 SaaS또는 PaaS형태의 데이타 분석 시스템을 이용하여, 유효 지표를 뽑아내서 사용하는 것이 더 바람직하다.


결국은 학습의 반복


린 스타트업의 핵심 프레임웍은 학습이다. 가설을 세우고 가설을 테스트하고 검증한후, 가설이 틀린 부분을 수정해나가면서 고객의 needs를 알아가는 학습의 과정이며, 회사의 비지니스 모델이 무엇이 적절하고, 어떤 기능이나 서비스가 핵심인지를 계속해서 배워나가는 학습의 반복이다.

새로운 이벤트, 새로운 기술을 넣는 것이 아니라, 이러한 지루한 반복을 통한 학습과 개선을 통해서 서비스(제품)을 개선해나가고 가치를 부여하는 과정이 스타트업이 아닌가 싶다.

※ 린 스타트업 책에서는 제품 개발에 대해서의 학습을 강조했지만, 인사나, 팀 문화, 재무 까지 스타트업에서는 학습의 반복이 아닐까 한다. 처음부터 모든 부분을 알거나 해당 분야에 대한 전문가를 영입해서 사업을 시작할 수 없는 만큼, 스타트업 기업이 성장해감에 따라 회사 경영에 대한 부분도 계속해서 학습하면서 만들어 나가야 한다.

다만, 이 학습은 계속 되고 학습에 따라 회사가 발전해나가야 하지, 이 학습이 목표와 방향성을 잃고 학습이 정체되는 순간, 스타트업은 퇴락의 길을 걷지 않을까?

 

혁신 회계와 지표


앞서 설명한 지표에 대해서는 조금 더 깊게 생각해볼 필요가 있다.


혁신 회계                              


린스타트업에서는 혁신회계라는 재미있는 개념을 소개하는데, 전통적인 기업이 매출과 손익이라는 금전적인 지표를 회계의 지표로 삼는데 반해서, 린 스타트업의 혁시 회계에서는 금전적인 지표 보다는 서비스 성장을 판단할 수 있는 지표를 회계의 지표로 삼는다.

이는 아마도, 스타트업의 모델이 대부분 성장 후에, 상장, 매각, 유료화등의 다양한 출구 전략을 선택하기 때문에, 출구 전략전 사업을 확장을 주요 지표로 하기 때문이 아닌가 싶다. 실제로 대부분의 서비스 기반의 스타트업은 가입자수나 액티브 사용자 수 또는 LTV (Life time value : 사용자당 평생 기대 수익)등을 기반으로 가치를 평가 받아서 투자를 받거나 상장을 하는 모델이기 때문에, 이러한 혁신 회계 지표가 오히려 적절하지 않은가 한다.


지표의 개념이 없는 스타트업


많지는 않지만, 가끔 스타트업의 시스템 구조를 진단 해주다보면, 이런 혁신 지표를 정의하지 않고 경영을 하는 경우가 많은데, 초반에는 그럴 수 있다고 치더라도, 이는 위험한 방식이 아닌가 싶다.

지표에 대한 개념이 없이 수~수십억의 마케팅 비용을 집행하면서, 마케팅을 통한 사용자 유입률이나 사용시간 증가분을 측정하지 않는 등이 대표적인 예인데이는 투자 대비 효과에 분석 준비 없이 비용을 집행하기 때문에, 잘못하면 효과없이 소중한 비용만 낭비하는 결과를 일으킬 수 있다.

앞에서도 설명하였듯이, 린 스타트업 프레임웍에서는 아이디어가 제품화/서비스화 된 결과에 대한 측정을 할 수 있는 유효 지표를 정의하는 것이 선행되어야 한다.


허수 지표에 대해서


그러면 이러한 지표 정의에 있어서 가장 경계해야할것이 허수 지표인데, 예를 들어서 설명하자 A사의 서비스의 가입자수가 꾸준히 늘어나고, 1억 이상의 가입자를 가지고 있다고 할때, 이 서비스가 성공적인 서비스일까? 지표상으로 봤을때는 그럴 수 있다.

그러나 몇가지 현실적인 가정을 만들어보자, A사는 핸드폰을 만드는 회사이고, 음악을 들려주는 앱을 단말이 판매 될때 이 서비스를 프리로드하였다. 그리고, 핸드폰을 초기화할때 이 서비스가 자동으로 가입되도록 하였다. 그렇다면 이 서비스를 실제로 사용하지 않지만 가입한 사용자 수는 많아지게 되고, 가입자 지표는 많지만 서비스가 실제로 사용되지 않기 때문에, 이 지표를 기반으로 1억 이상의 가입자를 처리할 수 있는 시스템을 확장하는 등의 비용이 투자될 수 있고, 또한 사업이 잘된다는 착각에 빠질 수 있다. 가입자 수 보다는 사용자의 재방문율 또는 주별 사용시간등을 측정하는 것이 오히려 현실적일 수 있다.

또 다른 허수 지표의 예를 들어보자, 스마트폰 유료앱을 판매하는 서비스라고 할때, 판매되는 라이센스 수 만 측정하면 될까? 끼어 팔기나 정치적인 원인에 의해서 라이센스가 판매되는 경우는 비지니스에서 흔한 케이스이다. 1000만 라이센스가 판매되었다고 하더라도, 그중에 실제로 사용되는 라이센스가 100만이라면, 이 사업이 제대로 가고 있다고 할 수 있을까? 제대로된 지표는 판매된 라이센스가 아니라 사용되고 있는 (액티베이션된) 라이센스이다.

이 밖에도 잘못된 지표를 양산 하는 경우는 많다. 광고나 이벤트로 인해서 반짝 가입자수가 늘었다가 사용자가 사용하지 않는 서비스등도 그러한 예에 속할 수 있다.

이렇게 일반적으로 생각할 수 있는 가입자 수, 라이센스 판매량등을 지표로 삼아서 사업을 꾸려나갈 수 있지만 실제로 사업에서 유효하 지표가 무엇인지를 제대로 판단하여 정의하고, 이를 기반으로 사업의 방향을 정해야 한다.

이렇게 사업의 진정한 가치와 동떨어지고, 잘못된 판단을 유발할 수 있는 지표를 허수 지표하고 한다.


결론


지금까지나마 간략하게 린 스타트업으 대략적인 프로세스에 대해서 살펴보았고, 그 중에서 가장 중요한 지표(혁신회계)에 대해서 살펴보았다. 무엇보다 중요한 것은 스타트업 서비스에 새로운 가설을 기반으로 한 서비스나 기능을 추가했을 때 이를 측정할 수 있는 지표를 정의하고 측정하는 것이 중요하며, 특히 이 지표 정의시, 스타트업의 성장을 제대로 측정할 수 있는 유효 지표를 정의하고 허수 지표를 제거하는 것이 중요하다.

스타트업에서 일하기 위한 준비


멀쩡하게 국내 최고 기업중의 하나인 기업을 다니다가, 스타트업의 일원으로 몬가를 만들어 내겠다는 생각에, 안정적이고 좋은 직장을 박차고 나왔다. 마흔이 넘은 나이에, 스타트업이라니, 누가 보면 제정신이 아니라고 할 수 도 있겠지만이번이 인생에 있어서 마지막 도전이 아닐까 하는 생각이 든다. 해도 후회, 안해도 후회 할거면 해보고 후회하자는 결정을했다.

지금까지 일해온 방식이, 최종 의사 결정자이기 보다는 의사 결정을 수행하는 입장에 있었기 때문에, 새로운 일은 나름대로 도전이다

더군다나, 대기업이나 벤더의 경험에서 스타트업이라는 무한의 정글로 도전을 하면서, 다른 비지니스 모델과 환경, 그리고 모바일 및 스타트업의 전성 시대에서, 생각하는 방식이 다른 젊은 사람들과의 일은 기존에 일하던 방식에서 무엇인가의 변화가 필요하다는 생각을 가지도록 하였다.

그래서, 스타트업과, 사람들이 일하는 문화에 대해서 다른 시각을 가지기 위해서, 휴가 기간동안, 피플웨어와 린스타트업이라는 두권의 책을 가지고 왔건만, 도무지 제대로 이해가 되지 않아서, 글로써 정리함으로써, 내것으로 만들고자 한다.

다른 세대의 개발자, 다른 환경 그리고 다른 역할


다른 세대의 개발자


이직을 결정하고 나서, 시간이 나는데로, 새로운 회사의 사람들과 대화를 하고 이해하려고 노력을 했다. 흔히 말하는 현대의 스타트업 개발자들의 특성을 파악하고 준비하기 위함이었는데, 몇가지 발견한 흥미로운 사실이 있는데, 그 중에서 첫번째는 나름 혁신 적이고 변화에 빠른 사람이라고 생각한 나 조차도, 이미 새로운 세대에 비교해서는 새로운 세대가 아니라는 것이다.

새로운 세대, 스타트업 개발자의 특징을 몇가지 보면, 기술이나 역할에 대한 두려움(?)이 없고, 멀티롤을 한다. 내가 경험한 몇 안되는 스타트업은 모바일 서비스를 기반으로 하는 회사들로, 대부분 모바일 개발자가 주요 엔지니어링을 하고 있으며, 필연적으로 필요한 서버 백엔드와 인프라 엔지니어링도 이 모바일 개발자가 배워서 하고 있었는데, 기존의 서버 개발자들이 같은 업무를 수행했다면, 아마도 조금 더 좋은 설계와 많은 검증으로 좋은 시스템을 만들어 냈을 것이다. 그러나, 그 만큼 리소스(시간)도 많이 소요되었을 것이고, 해보지 않은 분야에 대한 거부감도 생각보다 컸을 것이다.

그러나, 이 모바일 백 그라운드의 스타트업 엔지니어들의 특징중의 하나는 새로운 기술에 대한 거부감이 상대적으로 적고, 인터넷의 발전(스택 오버플로등)등으로 그냥 자료를 찾아서 한다. 말 그대로 그냥한다. 애자일 방법론에 대해서 제대로 교육을 받거나 공부를 해본적은 없지만, 인터넷에서 찾아본 문화와 단편적인 지식으로나마 애자일 스럽게 나름 효율적인 프로세스를 구축해가고 있다.

고가용 고성능 시스템을 만들지는 못하지만, 서비스가 커감에 따라 장애등을 겪으면서 시스템을 고도화해나가고, 직접 고객 서비스에서 피드백을 받으면서 만든 코드하나하나가 비지니스에 영향을 주는 것을 느끼면서 배워 나가고 있다.

오히려 대기업이나 벤더에서 잘 닦여진 프로세스와 가이드 보다, 직접 몸으로 부딪혀 나가면서 서비스를 해나가는 정글에서 배워나간 지식들이 훨씬 더 가치가 있게 보인다고나 할까?


다른 환경


팀 확장을 위해서, 사람들을 뽑고, 기존 사람들을 살펴보면서 인지한것 중의 하나는 환경이 차이가 꽤나 크다는 것이다. 스타트업인 만큼 자금 집행이 쉽지 않기 때문에 많은 돈을 주고 엔지니어를 데리고 오거나, 쉽게 교육등에 투자하기가 어려우며, 또한 좋은 복리후생이나 안정적인 직업 보장성으로 사람을 데리오기도 힘들다. 이른바 스타트업에서 열정페이론이 언급되는 이유도 이런 이유가 아닌가 싶다.

그렇다면 어떻게 사람을 데리고 와야 할까? 결국 스타트업은 사람이 우선인데, 어떻게 사람을 유지하고 좋은 사람을 데리고 올 수 있을까? 금전적인 부분은 배제하고 생각할 수 있는 것은, 일하고 싶게 만들어 주는게 아닐까 싶다. 대부분 좋은 보상을 받는 회사에 근무하고 있는 사람이 이직을 원하는 이유는 나는 더 할 수 있는데, 회사가 주는 권한이 작다.” “내가 인정을 덜 받고 있다.” “조금 더 옳고 효율적인 방향으로 일하고 싶다.”라는 느낌이 아닌가 싶다. 그렇다면 결국 대기업에 비해서 스타트업이 줄 수 있는 메리트는 권한이다. 스스로 납득할 수 있는 일을 하게 하고, 그것을 하기 위해서 스스로가 팀을 납득 시키도록 하는 환경을 조성해야 한다. 이를 위해서는 팀 중심으로 일을 해야하고, 납득을 제대로 하기 위해서 같은 눈 높이를 가져야 한다. 극단적인 예를 들어 엔지니어가 자동화를 하고 싶은 의지가 있을 때, 이것이 비지니스에 얼마나 도움이 되는지 다른 사람을 납득시키고 수행할 수 있어야 한다. 이렇게 의견을 제시하고 상대방을 납득 시킬 수 있는 환경을 조성하는 것이 수평적인 소통 문화, 그리고 결정된 일을 권한을 가지고할 수 있게 하는 권한을 이양하는 문화 조성이 필요하지 않을까 한다.


다른 역할


지금까지 내가 해왔던 역할이라면, 개발 팀원으로써 지시를 받아서 일을 하거나, 매니져로써 지시를 내리는 입장이었다. 이번 역할을 그 이상의 역할에서 팀이 제대로일 할 수 있도록 하는 역할이다. 팀의 규모가 커지고 비지니스의 속도가 빨라지며 기술의 변화가 심해짐에 따라서 일일이 지시를 통해서 해결할 수 는 없다. 권한을 다른 사람에게 대행 시키고 의사 결정 권한을 분산 시켜야 하는 역할이다. 지금까지는 직접 코딩하고, 직접 설계하고, 직접 팀을 관리했지만 이번부터는 팀원들이 이것을 할 수 있도록 만들어 줘야 하는 역할이다. 즉 직접 뛰는 역할 보다는 뛸 수 이쓴 환경을 조성해 주는 역할이다.

이번에 피플웨어를 읽던 중 재미있는 구절중의 하나가

대다수의 관리자는 자신에게 기술적인 걱정보다 사람 걱정이 더 많다는 사실을 기꺼이 인정한다. 그러면서도 그렇게 관리하는 관리자는 극히 드물다. 그들은 기술이 주요 걱정 거리인 양 간리한다. 팀원들이 풀어야 할 가장 꼬이고 재미난 퍼즐을 스스로 고민하며 시간을 보낸다. 마치 업무를 관리하기 보다는 직접 업무를 수행하려는 듯 행동한다.” – 피플웨어 3

예전에 약 60명 정도의 팀을 이끌고 전체적인 프로그램을 관리할때는 돌이켜보면, 직접 기술을 고민하고 해결하려고 한적이 있었다. 스스로를 VP of engineering / Chief Architect로 정의했으니까주요 기술 의사 결정에 관여하고 가이드를 주는 일을 했는데.. 근래에는 이게 과연 옳은 행동이었는지에 대해서 고민중이다. (아직 결론은 내지 못했지만…) 그렇다고 경험을 통해서 이미 겪고 알고 있으면서 의견을 개진 하지 않고 팀이 풀도록 놔두는 것 역시, 내 경험에 대한 낭비가 되고경험을 잘 살려서 팀을 옳바른 방향으로 갈 수 있도록 돕는 것 역시 새로운 역할에서 주어진 숙제가 아닌가 싶다.


결론


구체적인 실천 방향에 대해서 고민해보고 또 고민을 하지만 결론은 나지 않는다. 아직 우리가 어떻게 일하고 있는지 나는 모르기 때문이다. 아마도 2~3개월 같이 서비스를 개발해나가고 사람과 부딪혀 가면서 이해해야 아마도 구체적인 실천 방향을 정의하고 실행해 나갈 수 있지 않을까 싶다. 그럼에도 불구하고 책을 읽고 생각을 하고 정리를 하는 것은 최소한의 방향성과 다른 환경에서 일하기 위한 기본 원칙을 나름데로 정의하기 위함이다.

예전, 대기업에 입사할때 숙식을 하는 교육을 받은 적이 있다. 이때, 조별로 많은 과제를 수행했는데, 어떤 부분에서는 답답하기까지 했다. 만약에 팀이었고, 내가 리드 였다면 결정하고 지시해서 빠르게 끝낼 수 있었을 거라는 생각을 했었는데, 결과는 의외였다. 모두 처음 만났기 때문에 서로 동등한 입장에서 경청을 해야 했고, 동등하게 의견도 낼 수 있었다. 내 입장에서는 속이 타들어가고 답답하면서도 두번,세번을 물러서서 생각을 해야했고 의견을 들었어야 했다사람들이 의견을 이야기 하고 새로운 방법을 낼때 마다 놀라운 일이 생겨났다. 내가 생각지도 못한 방법이 나왔고, 그 방법들은 성공했다. 나는 의견을 듣다가 정리되지 않는 부분에 대해서 약간의 방향성만 잡아주고 정리만 해주면 그 아이디어들은 잘 실현화가 되었다. (나는 이것을 leverage 한다고 한다.) 대략 일주일간의 경험이었지만, 존중과 경청, 그리고 각자의 재능이 어떻게 섞여서 새로운 효과를 나타내는 지를 경험한 시기였다. 그래서 팀이 모이고 경청을하고 재능이 섞이면 어떤일이 일어나는지 알 수 있다. 얼마전에 만난 스타트업 대표는 이를 캐미”(Chemi)라고 불렀다. 아마도 화학반응에서 떠온 말이 아닌가 싶다.

그러기 위해서는 나의 권한을 명령 보다는 경청을 하고 존중을해서 사람들이 가지고 있는 재능을 이끌어 내주고, 나의 경험을 바탕으로 의사 결정을 내리고 지시를 하기 보다는 경험을 공유하고 의견을 줘서 팀이 올바른 방향으로 나갈 수 있도록 도와줘야 하지 않을까 싶다. 스타트업에서 리더는 방향을 알려주고 팀을 앞으로 이끄는 주인공이 아니라, 팀이 올바른 방향으로 나갈 수 있게 뒤에서 도와주는 조연이 되어야 하지 않을까?

 

막상 책을 읽은 내용을 정리하려고 글을 쓰기 시작했는데, 책 내용은 막상 정리를 하지 못했다. 다음 글 부터는 책에서 읽은 내용을 정리 하기 시작하겠다.

오랜만의 포스팅입니다. 그간 많이 바뻤습니다.

요즘 시스템 운영쪽에 관심이 많아서 Devops (Development + Operation)쪽을 틈틈이 보고 있습니다. 오늘은 조직의 성숙도별 개발 모델과 함께, CD (Continuous Delivery)와 Devops에 대해서 설명해보고자 합니다.



회사의 규모나 성숙도에 따라서 개발 모델을 크게 다음과 같이 3단계로 나눠볼 수 있습니다.


1. 스타트업


소규모에 처음 서비스 개발을 시작한 스타트업 기업 같은 경우에는 일단 모든 의사 결정이 빠르다. 아이디어가 나오면 별도의 승인이나 분석 없이 바로 개발하고, 개발이 끝나면 바로 배포 한다. 규모가 작고 모든 의사 결정이 팀내에서 이루어지기 때문에 매우 빠르다. 그리고 인력이 적기 때문에, 분석/설계/개발 및 운영이 같은 그룹에서 이루어진다.


2. 성숙된 개발 조직

어느정도 조직이 성숙되고, 인원이 많아지고 이익에 대해서 고민을 하게 되면, 조금더 체계화된 개발 프로세스를 원하게 된다.

한정된 예산으로 서비스를 개발하게 되며, 인원이 많아짐으로써 품질 저하를 막기 위해서 역할이 세분화 되고 체계화 된다.




아마 대부분의 일반적인 서비스 개발 이나 시스템 개발 기업들은 이러한 프로세스를 따를 것이다. 아이디어가 나오면, 발표하고 경영진을 설득하여 예산을 정하고, 요구 사항 분석을 통해서 범위를 정한후, 개발/테스트/수정을 한후, 모든 테스트를 통과하면 릴리즈 일정을 결정하고 산출물을 정리한후, 운영팀으로 이행한다.


체계화 되어 있기는 하지만, 앞서 설명한,Start up에 비해서는 전체적인 프로세스가 느리고, 운영으로 이관후, 자잘한 Fix나 Enhancement가 어렵다. 그리고, 새로운 기능이나 컴포넌트를 개발하려면, 새로운 프로젝트를 시작해서 위와 같은 전과정을 다시금 거쳐야 한다.


3. CD와 Devops기반의 개발 모델

요즘 같이 새로운 서비스가 많이 나오는 시절에, 저런형태의 개발 프로세스는 빠른 기능 추가등이 불가능하고, 운영중의 피드백을 받기 어려워서 SNS와 같은 서비스에는 적절하지가 않다. 

그래서 CD (Continuous Delivery)와 Devops라는 개념을 사용하는데


CD

CD는 Continuous Delivery의 약어로

운영 시스템에 계속해서 Fix나 새로운 기능을 지속적으로 Release를 하는 개념이다.

쉽게 예를 들어보면, 프로젝트 기간이 끝나면 릴리즈를 하는게 아니라, 매일매일 새로운 FIX나 기능이 추가되면 거의 매일 릴리즈를 하는 개념으로 보면 된다.

Face Book의 경우 이런식으로 매일 개발자가 새로운 기능을 운영 환경에 반영 및 추가 하는 것으로 알고 있다.


Devops

Devops는 Netflix에서 주로 시작된 개념으로 개발팀과 운영팀을 하나로 묶어서, 커뮤니케이션에서 오는 장애를 해소하고 빠른 서비스 개발과 반영을 하고자 함에 있다.

보통 개발팀과 운영팀이 나눠져 있는 것이 전통적인 모델인데, 이 경우에는 운영중에 고객의 요구 사항등이 개발쪽에 잘 전달되지 않고, 매일 서비스를 운영하면서 개선 사항이 있더라도 개발팀에 전달되기가 어려운 경우가 많다. 반대로, 개발쪽에서 무엇인가를 수정하면 수정 내용이 운영쪽에 제대로 전달되지 않아서 배포 실수등을 유발하여 시스템 장애를 유발하는 경우가 많다

그래서 Devops는 두팀을 하나로 합침으로써, 서로간의 의사소통을 빠르게 하고, 개발자가 직접 운영환경을 컨트롤함으로써 빠른 피드백을 받고, 빠른 반영을 통해서 서비스의 신속성을 향상 시키는 모델이다.


보통 이런 개념을 채용한 개발 모델은 다음과 같다.


위의 그림은 TDD를 채용한 그림인데, 먼저 테스트 계획서를 작성한후, 개발 및 테스트를 수행한후, 운영환경에 배포하고, 모니터링을 한다. 그리고 바로 신규 기능에 대한 피드백이나 효과를 모니터링해서 다시금 요구 사항을 정의하는 형태를 따른다

이렇게 Devops와 CD를 적용하기 위해서 중요한것은 자동화된 툴셋이 매우 중요하다.

개발 반영시 자동으로 꼼꼼하게 테스트를 할 수 있어야, 운영시 발생하는 장애를 방지할 수 있으며, 위의 전체 프로세스의 주체는 개발자가 되기 때문에, 복잡한 인프라나 미들웨어에 대한 배포를 자동으로 할 수 있어야 한다.

물론 자동화 툴셋은 어디까지나 구현 관점이다. 더 중요한것은 문화적인 차이점을 이해해야 하고, 프로세스의 변화를 인지하고 바꿔야 한다.

기존의 조직처럼 운영과 개발이 나눠져 있는 경우 조직을 합친다는 것은 기존에 가지고 있는 프로세스,  조직 구조를 모두 바꿔야 하는 것을 의미하며, 아울러서 기술셋도 모두 바꿔야 한다.

아울러 예산 집행 방식에 있어서도 기존에는 개발비용과 운영 비용을 나눠서 미리 잡아놓고 집행했기 때문에 초기 투자비와 운영비용(Running Cost또는 Opex), Devops 방식은 있는 인원들이 쭈욱 업그레이드와 운영을 계속해서 나가는 방식이라서 초기 투자비용보다는 운영비용(Running Cost)에 대한 부분이 커진다.


Devops나 CD의 경우에는 분명히 서비스 관점에서 가지는 이득은 매우 많지만, 변화의 폭이 기존 개발 방식에 비해서 매우 크기 때문에, 함부로 달려들 것은 아니라고 본다. 

그러나 스타트 업에서 규모가 커질 경우 위에서 언급한 정형화된 프로세스보다는 CD/Devops기반의 개발 프로세스로 비교적 쉽게 이동할 수 있고 얻는 이득도 많다.

기존의 대기업이나 SI기업의 경우에는 Devops 모델을 도입하기에는 변경되어야 하는 부분이 매우 많기 때문에, 매우 신중한 접근이 요구 된다.