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


Archive»


 
 

 

트위터 모바일 SDK 서비스 패브릭에 대한 소개


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




트위터에서는 2014년 부터, 모바일 생태계 지원을 위해서 다양한 기능을 제공하는 Fabric 서비스를 제공하고 있다. 데이타 분석 및 리포팅, 트위터 연동등 다양한 기능을 제공하고 있는데, 대략적인 프로덕트들에 대한 기능과 특징을 살펴보고자 한다.



Crashlytics - Crash Reporting (https://fabric.io/kits/android/crashlytics)


모바일앱에 대한 크래쉬 내용에 대한 수집 및 분석 기능을 제공한다.  

특이한 사항으로는 크래쉬 분석 뿐만 아니라, 베타 사용자나 테스터들에게 앱을 배포할 수 있는 기능을 제공하고 베타 테스트 사항을 추적할 수 있는 기능을 제공한다.

근래에는 게임 개발 SDK인 Unity를 지원하는 기능이 추가 되었다.

 


Answers - Mobile Analytics Kit (https://fabric.io/kits/android/answers/summary) 


Google Analytics나 Yahoo의 Flurry와 비슷한 앱 모니터링/리포팅 서비스이다. Google Analytics와는 다르게 완전 무료이다. (데이타 Limit가 없다.)

단 타 서비스와 차이점은 복잡한 형태의 분석이 불가능하다 Cohort, Funnel 분석이나 User Path등 복잡한 분석은 불가하고 DAU,MAU,Session등 단순한 분석만 가능하다.


단순하기 때문에 지표 이해가 쉬운것이 장점으로 볼 수 있고, 또 다른 장점은 타 서비스에 비해서 리얼타임이라는 것이다. 대쉬보드의 수치는 20~30초 정도의 지연이 있는 수치로, 실시간 이벤트를 하거나 PUSH에 대한 반응을 바로바로 봐야할때나 TV CF후에 반응등 실시간 반응 분석이 필요할때 유용하게 사용할 수 있다.


정확한 분석을 위해서는 Fabric 하나로만은 불가능하겠지만 실시간성을 지원하는 점을 보면, Fabric + Flurry와 같이 두개의 솔루션을 조합해서 사용하는 것을 고려하는 것이 좋다.


Answers에서 특이한 기능중에 하나는, 트위터의 사용자 정보를 기반으로, Fabric Answer 를 통해서 모니터링 되는 사용자에 대한 특성 파악이 가능하다는 것이다. 트위터는 컨텐츠 및 여러가지 종류의 계정 (스포츠, 코메디 등등)을 운영하고 있기 때문에, 트위터는 트위터 사용자의 특성이 어떤지를 알 수 있고, 이 정보를 바탕으로 Fabric이 연동된 서비스의 각 사용자들의 특성을 파악해줄 수 있기 때문에, 서비스 운영 입장에서 사용자에 대한 인사이트를 제공할 수 있다. 




Digit Kit


Digit Kit는 SMS를 이용한 인증 서비스 이다. SMS를 통해서 인증 번호를 전송해서 본인 여부를 확인하는 서비스인데, 200여개의 국가를 지원하고 있고, 가장 중요한건 무료다!!. 글로벌 서비스를 제공 하는 경우 글로벌 SMS 서비스를 고려해야 하고, 또 그에 대한 금액도 만만하지 않은데, 하나의 서비스로 글로벌 커버를 비용 부담없이 제공하는 것은 활용을 고려해볼만하다고 보다. 향후  Email Verification 서비스도 함께 제공할 예정이다. 




Twitter Kit


Twitter Kit은 트위터 기능을 사용하기 위한 모바일 SDK이다. 특이한 점은 트위터로의 공유하는 GUI등을 SDK로 제공해서 어렵지 않게 트위터로의 공유 기능을 구현할 수 가 있다. 




Curator - Twitter contents curation service


트위터 컨텐츠를 모아서 큐레이션 (기존의 컨텐츠들을 2차 가공하여 새로운 컨텐츠를 만드는 것) 해주는 서비스로, 주로 미디어 서비스나 컨텐츠 공급자, 큐레이터에게 유리한 서비스로 Curator라는 저작툴을 이용하여, 큐레이션할 컨텐츠를 골라서 특정 주제에 해당하는 피드를 만들 수 있다. 아래는 서울의 첫눈이라는 주제로 트윗을 검색한 후에, 이를 골라서 콜랙션을 만드는 저작도구 화면이다. 



다음은 큐레이트된 컨텐츠를 임베딩하기 위해서 퍼블리슁 화면이다. 



저작자 표시 비영리
신고

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



조대협(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화 되면서 대중화 국면을 맞을 것이다.


저작자 표시 비영리
신고

대용량 서비스의 트래픽을 줄이는 이미지 최적화 기술 Web-P


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





대용량 트래픽 서비스를 하다보면, 항상 고민하게 되는 것이 인프라 운영 비용에 대한 문제이다.

특히 미디어 서비스의 경우, 네트워크 트래픽을 유발하는 이미지나 동영상에 대한 CDN과 네트워크 비용이 문제가 되고, 사용자 입장에서도 모바일 3G/LTE 망을 통해서 이미지나 동영상을 다운로드 받는 경우, 데이타 사용량에 실제로 연관이 되기 때문에 점점 더 멀티미디어 파일 포맷에 대한 용량 최적화가 문제로 대두 되고 있다.


그중에서, 이미지 압축 방식으로 GIF,JPEG/PNG을 대체할 이미지 포맷으로 BNG,구글 Web-P, Microsoft JPEG-X 등이 소개되고 있는데, 이 중에서 Web-P에 대해서 소개하고자 한다.


기본적으로 JPEG는 손실 압축 기술로, 이미지를 압축했을때, 손실이 발생한다. 특히 텍스트나 정교한 내용이 있을때, 그 내용이 뭉게지는 현상이 있을 수 있지만, 큰 사진이나 일반적인 이미지를 표현하는데 좋고 색 단계를 여러가지 표현할 수 있기 때문에 사진이나 일반 이미지 저장 포맷으로 많이 사용된다.


GIF의 경우 무손실 압축 알고리즘이기 때문에 텍스트가 들어간 이미지등에는 유리하지만, 256 색까지만 표현이 되지 않기 때문에 사진등에는 유리하지 않지만, 움직이는 영상(움짤/Animated GIF)등으로 많이 주목받고 있다. (그런데 이 움짤 용량이 무지 크다.)


JPEG,BPG,Web-P를 비교해보면, 

압축률을 BPG > Web-P >> JPEG 순으로,  BNG 가 가장 압축률이 좋고, 또한 압축된 이미지의 품질또한 가장 높다.


잠재적인 위험이 있는 BPG


그렇지만 문제는 BPG는 내부적으로 HEVC라는 기술을 사용하는데, 이 기술은 MPEG(동영상 압축) 기술의 일부로, 특허가 복잡하게 얽혀 있는 가능성이 있는 것으로 알려져있다. (실제로 BPG 사이트에 들어가도 그렇게 공지하고 있다.) MPEG 기술 안에는 너무 많은 특허가 들어가 있어서 당사자도 특허 참여 여부 또는 제품에 그 특허가 들어갔을때 침해를 당했는지도 찾기 어려워서 MPEG-LA라는 특허관리 업체에서 MPEG 특허를 관리하고, 문제가 생기면 소송을 통해서 특허 권리금을 받아서 MPEG-LA 참여 업체에 특허 권리료를 나눠 준다. 특허 권리에 대해서 BPG 를 개발한 사람이 낸 의견 중의 하나는 HEVC 기술을 하드웨어 가속 기능에 탑재해서 하드웨어 업체 또는 드라이버 업체가 특허를 물면된다는 논리는 내세우고 있는데, 라즈베리파이 같은 저사양 하드웨어등에서 이런일이 가능할까 의문이다. 개인적인 생각으로는 BPG는 특허에 대한 위험성 때문에 널리 확산되기가 어렵지 않을까 싶다.


구글의 Web-P


Web-P는 구글에서 만든 압축 기술로, JPEG에 비해 높은 압축률과 투명 이미지와 GIF 처럼 움짤을 지원한다.

대략 움짤 gif를 web-p로 줄이게 되면 대략 1/4 정도로 사이즈가 줄어드는 효과가 있다




<그림. WebP와 JPEG 화질 비교>

출처 : https://developers.google.com/speed/webp/gallery


아직 브라우져 커버리지는 높지는 않지만, 크롬이나 Opera 등에서 일부 지원하고 있고, Android 플랫폼에서도 지원하고 있다. 




출처 : http://www.slideshare.net/guypod/high-performance-images-beautiful-shouldnt-mean-slow-velocity-eu-2015



또한 재미있는 것중의 하나는 구글에서 제공하는 웹 최적화 플러그인인 페이지 스피드 https://developers.google.com/speed/pagespeed/module/ 플러그인에서, 브라우져의 web-p 지원 여부에 따라서 기존의 JPEG를 web-P로 자동 변환하여 내려주는 기능을 제공하여, 별도의 인프라에 큰 변화를 주지 않고도 web-p를 지원하는데 큰 문제가 없다. 지원이 안되는 브라우져의 경우에는 javascript를 이용하여, web-p를 지원하게 할 수 도 있다.


전체 이미지를 web-p로 바꾸는 것은 무리가 있겠지만, 모바일을 기준으로 볼때 안드로이드 점유율이 상당하기 때문에, 안드로이드 디바이스에만이라도 선별 적용하게 하는것만으로도 용량을 줄이는 큰 효과가 있지 않을까 한다.


참고 : WebP 관련 자료 - https://developers.google.com/speed/webp/

저작자 표시 비영리
신고

IP TV 아키텍쳐의 이해

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

서비스 사업자의 IP TV 아키텍쳐 이해

아키텍쳐 모델

사용자 삽입 이미지

IP TV 아키텍쳐는 크게 서버와, 클라이언트 STB (Set Top Box)두 개로 이루어진다.

센터간 토폴로지 (중앙 방송 센터와 중계 센터)

서버 쪽은 중앙 방송 센터와 각 지역을 커버하기 위한 중계 센터(Sub Center)가 존재한다.
중앙 방송 센터는 전체 컨텐츠와 서비스 등을 통제하며, 중계 센터는 컨텐츠에 대한 중계를 주요 역할을 목적으로 하며, 중앙 방송 센터와 중계 센터 사이는 고속 Private 네트워크를 통해서 연결이 되어 있다. 중계 센터에서는 각 가정으로 Qos 망 또는 Private 망 기반의 IP망을 이용해서 서비스를 제공하며, VOD 서비스의 Latency를 낮추기 위해서 CDN 기반의 Storage 서비스 및 Streaming 서비스를 제공한다.

주요 서비스 컴포넌트

서비스 모델에 따라서는 VOD 서비스, 실시간 방송 서비스, 양방향 애플리케이션 및 공통 인프라 스트럭처로 나뉘어 지는데 각각의 구성 요소를 살펴보면 다음과 같다.

VOD 서비스 (Video on demand service)

·         Contents Acquisition

컨텐츠 제공자로부터 컨텐츠 (동영상) 그에 대한 메타 정보(타이틀, 시간, 배우 정보 ) 가지고 오는 역할을 수행한다. FTP 기타 파일 전송 프로토콜 등을 통해서 컨텐츠를 읽어오고 메타정보는 XML/HTTP 기반의 REST SOAP등을 통해서 읽어오는 구조를 취한다.  그러나 컨텐츠 확보에 있어서, 계약 등의 이슈가 있기 때문에 IP TV 서비스 제공자가 직접적으로 컨텐츠 확보를 하지 않고, 컨텐츠 Aggregator 통해서 컨텐츠를 확보하고, 컨텐츠 Aggregator각각 컨텐츠 제공자의 특성에 맞는 컨텐츠 획득 방안 (DVD 통한 획득, 실제 우편을 통한 획득 ) 따라서 컨텐츠를 모은 후에, IP TV 서비스 제공자에 맞는 형태 (MPEG2 ) 재가공하여 전달한다.

IP TV 서비스 제공자는 특정 포맷과 인터페이스 포맷을 제공함으로써 컨텐츠 획득에 들어가는 인터페이스 비용을 절약하고 기술적인 표준을 유지할 있다.

·         Encoding

확보된 VOD 컨텐츠는 서비스 형태에 맞는 파일 포맷으로 다시 인코딩이 된다.

다양한 디바이스 (모바일,HD TV,SD TV) 해상도에 맞춰서 인코딩이 수행되며, 인코딩 효율을 줄이기 위해서 하드웨어 인코더를 사용하기도 한다.

·         CA/DRM

인코딩 컨텐츠는 불법적인 복제를 막기 위해서 CA/DRM 처리를 한다. 이때 중요한 것은 컨텐츠 제공자 (월트디지니,픽사등) 따라서 특정 규격이상의 안정성(복제에 대한 대비) 요구로 하는 CA/DRM 요구한다.  그런 CA/DRM 통해서 VOD 배포하는 사업자에게만 컨텐츠를 판매하기 때문에, 계약하고자 하는 컨텐츠 제공자에 따라서 CA/DRM 솔루션을 구비하는 것이 필요하다.

·         Contents Storage

인코딩 되고 DRM 처리가 컨텐츠는 실제 서비스를 위해서 중앙 저장소 (Contents Storage) 저장된다.

·         Contents Provisioning

지역이 넓거나 가입자 수가 많은 경우에 지역  중계 센터를 설치 하는 경우가 있는데, 이런 경우, 저장된 컨텐츠는 지역 중계 센터로 배포 (Provisioning)된다.

지금까지 설명한 VOD 서비스의 시스템 프로세스를 정리해보면 다음과 같다.
컨텐츠 제공자(Program Provider)로부터 동영상과 메타 정보를 수집하여 전달 받고, 전달 받은 컨텐츠를 인코딩 DRM 거쳐서 중앙 저장소에 저장하여 서비스를 제공하고, 넓은 지역을 서비스 경우, 중계 센터로 VOD  컨텐츠를 배포 하여 지역 센터를 통해서 서비스를 제공한다.

VOD 서비스의 경우 실시간 성이 아니기 때문에, 미리 인코딩 컨텐츠를 제공하고, 또한 Buffering 가능하기 때문에 일반적인 인터넷 망을 통해서 서비스가 가능하다. 고화질의 컨텐츠를 제공하기 때문에, 일반 Public 망을 통해서 서비스 하는 경우 Buffering 시간이 길어져서 끊김현상등이 발생할 있고, Loading 시간이 많이 필요하기 때문에, 일반적으로 서비스 사업자의 경우 방송센터 또는 중계센터로부터 가정까지 폐쇄된 인터넷 (IP) 이용하여 서비스를 제공한다. (쉽게 말해서 Qos 보장되지 않지만, 빠른 속도의 초고속 인터넷을 사용한다.)

실시간 방송 서비스 (Live broad casting)

실시간 방송의 경우 공중파나 케이블 방송을 IP TV 다시 중계 해주는 서비스로, 실시간 방송은 TV 비즈니스에 있어서 빼놓을 없는 핵심 서비스이다. 실시간 방송의 경우 공중파나 케이블 방송의 컨텐츠를 실시간으로 인코딩 해서 BY PASS 해주는 방식으로, VOD와는 달리 컨텐츠를 저장하지 않기 때문에 아키텍쳐 적으로는 단순할 있으나, 버퍼링을 사용할 없고, 인코딩이 실시간으로 이루어져야 하기 때문에 컴포넌트의 성능적인 요구 사항이 VOD 서비스에 비해서 매우 높다.

·         Encoding

공중파나 케이블 방송으로부터 받은 실시간 컨텐츠를 인코딩 한다. 인코딩에 의해서 타임LACK 발생하면 안되기 때문에, 타임 LACK 최소화하기 위해서 고성능의 하드웨어 기반의 인코딩 장비를 사용한다.

·         Streaming

인코딩된 실시간 방송 Stream 가정까지 전송한다. 이때 VOD 차이점은 VOD 경우 순간 사용자가 보는 컨텐츠가 다르지만, 실시간 방송의 경우 같은 채널을 본다면 같은 사용자의 경우 같은 컨텐츠를 보기 때문에, IP Unicast 아니라 일반적으로 Multicast망을 사용한다.  이런 이유로 실시간 서비스를 제공 하기 위해서는 방송센터 à 가정까지 IP MultiCast 지원해야 한다.

·         EPG (Electronic Program Guide)

방송 프로그램 일정표이다. IP TV에서 실제 EPG 메뉴를 띄워주기도 하고,  EPG 메뉴에서 방송중인 프로그램을 선택해서 이동하거나 예약 시청, 녹화 예약 등을 한다. (녹화의 경우 현재 아키텍쳐 문서에서 배제하였다. 일반적으로 IP TV 서비스 사업자는 실시간 방송에 대한 녹화를 지원하지 않는다. 기술적 문제와 저작권 문제 )

EPG 실시간 방송사와 연계해서 IP TV 플랫폼에 읽어오게 되고, IP TV 플랫폼에서는 플랫폼 표준 규격으로 변경하여 STB 전송해서 EPG GUI 맞게 출력해준다.

·         Qos(Quality of Service) 네트워크

일반적으로 HDMI 화질의 5.1 CH 영상과 음성을 제공하기 위해서는 컨텐츠나 압축률에 따라 차이는 있지만 10~12Mbps 네트워크 대역폭이 안정적으로 필요하다.  이런 이유로, 방송센터 또는 중계 센터에서 가정까지의 Qos (Quality of Service : 12Mbps 대역폭을 항상 유지하는 인터넷 ) 필요하다.  국내 IP TV 사업자는 실시간 방송을 위한 회선의 Qos 보장하기 위해서 가정에 Home Network Gate Way 라는 것을 설치하여 일반 인터넷 망과 분리하여 QoS 보장하는 서비스를 제공한다.

향상된 실시간 방송 서비스

 

양방향 애플리케이션 (Interactive application)

양방향 애플리케이션은 IP TV에서 실행되는 게임이나 노래방 같은 간단한 애플리케이션에서부터 EPG Overlap 광고 (베너, 클릭 기반의 링크)등을 지원하는 애플리케이션을 정의한다.

좀더 나아가서 PIP (Picture in Picture) 같이 방송 중에 여러 화면을 동시에 보여주는 (예를 들어 골프 방송에서 여러 홀을 동시에 보여준다거나, 야구 방송에서 투수 쪽과 타자 화면을 동시에 보여주는 서비스) 인터페이스 역시 양방향 애플리케이션 인터페이스를 이용한다.

양방향 애플리케이션 인터페이스는 동영상 전송을 제외한 모든 IP TV 인터페이스를 포괄하는 기술적인 컴포넌트이다.

·         Application Storage

애플리케이션 컨텐츠 (게임,노래방 ) 애플리케이션 제공자가 업로드 해서 저장하는 공간이다. AppStore같이 개발자가 직접 애플리케이션을 업로드하는 개발 생태계를 가지고 있는 플랫폼의 경우 Application Storage 일종의 개발자 포탈과 같은 인터페이스를 가지면서 애플리케이션 업로드 판매에 대한 정산등까지고 포괄하여 지원한다.

·         Application Server

Application Server 실제 애플리케이션을 구동하거나 클라이언트에 다운로드되서 작동하는 애플리케이션에 대해서 OPEN API 제공하는 서비스를 한다.

Application Server 기능이 다양화 경우 플랫폼 형태로 구성되는 경우가 있는데, OPEN API 기능을 제공하는 여러 단위 컴포넌트와 컴포넌트를 플러그인 하는 통합형 버스(BUS) 통해 STB 서비스를 EXPOSE하는 기능으로 구성되며 이를 흔히SDP (Service Delivery Platform)이라고 이야기 한다.

·         STB VM

STB에는 다운로드 애플리케이션을 관리하고, 실행하는 VM(Virtual Machine:가상 머신) 존재한다. 모바일에서 이야기 하는 안드로이드나, 바다 플랫폼등이 이러한 VM 해당한다.

위에서 설명한 양방향 애플리케이션 실행 환경은 국내 IP TV 플랫폼에서 사용되는 클라이언트 지향형 아키텍쳐 이야기한다. 근래에 들어서 해외의 IP TV 플랫폼인MS MediaRoom이나 국을 TV 같은 경우에는 서버 지향형 아키텍쳐 사용하는데 차이점을 설명 하면 다음과 같다.

클라이언트 지향형 아키텍쳐 (Client Oriented Architecture)

아키텍쳐는 애플리케이션 수행 파일을 직접 STB 다운로드 받아서 VM위에서 구동하는 방식이다. 단말에서 직접 구동되기 때문에, 단말의 여러 기능을 이용할 있고, 중량의 애플리케이션 서비스 (다양한 형태의 서비스) 가능하다는 장점을 가지고 있다.

서버 지향형 아키텍쳐 (Server Oriented Architecture)

서버 지향형 아키텍쳐는 마치 WEB이나 모바일의 WAP처럼 애플리케이션은 실제 서버에 배포되고 TAG 기반의 프레젠테이션 계층(화면) 클라이언트로 전송되는 아키텍쳐 모델로, 애플리케이션의 비즈니스 로직이 서버에서 실행되기 때문에 사양 STB에서도 사용이 용이하다는 장점을 가지고 있으며, 애플리케이션의 변경과 배포가 매우 용이하다.

 MS 경우 PF(Presentation Framework)이라는 것을 사용해서 애니메이션 등을 포함한 다양한 태그 라이브러리를 통한 UI 제공하고, 프로그래밍 모델 역시 기존의 개발 방법과 유사하기 때문에 개발생산성과 개발자 확보가 쉬운 장점을 가지고 있으며, 애플리케이션의 업그레이드 등이 매우 용이하다.

얼마 TV  사업 진출을 선언한 구글의 경우에도 STB 다운로드 받는 형식이 아닌 HTML5 IP TV서비스에 적절한 표준을 추가 함으로써, 서버 지향형 아키텍쳐를 기반으로 IP TV 서비스 인프라를 제공하려는 움직임을 보이고 있다.

공통 서비스 (Common service)

공통 서비스 컴포넌트의 위의 모든 서비스를 제공하기 위해서 제공해야 하는 공통적인 기능들과 함께, 디바이스나 사용자관리와 같은 IP TV 서비스 플랫폼의 인프라를 제공하는 컴포넌트를 정의한다.

·         Billing/Charging

이벤트,패키지 상품과 같이 다양한 과금 정책에 따라서 컨텐츠의 가격을 매기는 것이 Charging,  실제 신용카드나 또는 요금 정산에 포함 시켜서 과금하는 Billing으로 구성된다.

·         Device Profile 관리

STB에 대한 이력과 사용자에 대한 정보를 관리한다. STB Firmware 버전, 다운로드 받은 소프트웨어 이력 등을 관리한다.

·         Device Management

Device에 대한 Firmware Upgrade등을 관리한다.

·         Authentication & Authorization

STB를 통해서 IP TV 서비스를 이용하고자 할 때, 인증 및 권한 관리를 담당한다.

 

IP TV에서의 킬러 컨텐츠

IP TV 비즈니스에 있어서 대부분의 수익은 VOD, 실시간 방송, 그리고 광고에서 창출된다.
광고 수익 기반으로 VOD를 무료로 배포하거나 고품질의 VOD를 유료로 서비스해서 수익을 창출하고, 실시간 방송의 경우 기존 공중파나 케이블을 대체하기 위해서 존재한다.

전통적인 IP TV 서비스 모델에 있어서의 문제점

국내 IP TV 비즈니스 모델에서의 주요 문제점을 살펴보면 다음과 같다.
실시간 방송의 경우 케이블 사업자의 실시간 재전송 비용에 대비해서 공중파 방송사들이 IP TV 사업자에게 상당히 큰 비용의 재전송비를 요구하기 때문에, 실시간 방송 쪽의 수익률이 좋지 않은 편이다.

또한 양방향 애플리케이션의 경우 국내의 IP TV 플랫폼이 대부분 Java 기반 또는 어도비의 플래시 형태를 사용하는데, Java 플랫폼 기반의 애플리케이션의 경우 STB에 탑재되는 JVM (Java Virtual Machine)의 표준이 잘못 구현된 경우가 많고 특성이 다양한 경우가 많아서 개발에 있어서 해당 플랫폼에 대한 경험이 많이 필요하고, 테스트에 많은 시간이 소요되기 때문에, 컨텐츠 제공자가 매우 적은 편이다.  또한 플래시 기반의 컨텐츠로 조금씩 이동 하고 있으나, 플래시 플랫폼의 한계로 인해서 아주 가벼운 형태의 애플리케이션 정도만 (간단한 게임) 서비스가 제공되고 있으며, 아직까지 애플리케이션 개발 생태계가 만들어지지 않은 상태이다.

이런 상황에서, 각 통신사들은 애플리케이션의 서버 플랫폼을 만들기 위해서 SDP (Service Delivery Platform)등을 구축하려고 노력하고 있으나, 애플리케이션 개발 생태계가 확립되지 않은 상태에서 효과를 내기 어렵고 더군다나 IP TV의 핵심 컨텐츠는 애플리케이션 보다는 효과적인 VOD 서비스 및 광고 수익 모델이기 때문에, 전략적이지 못한 투자가 이루어지고 있는 상황이다.

또한 독자적으로 IP TV 플랫폼을 가지기 위해서 STB 개발 비용 및 서버 플랫폼 개발 비용으로 막대한 비용을 투자하고 있으며, 서비스 품질의 경우 처음 개발하는 플랫폼이기 때문에 해외의 전문 IP TV 플랫폼 (Microsoft Mediaroom)등에 비해서 Quality가 떨어진다. 이상적인 방향은 서비스 사업자는 서비스 제공을 위해서 컨텐츠 등에 투자하고, 플랫폼은 선진 플랫폼을 들여와서 사업자의 특성에 맞게 Customization하여 플랫폼에 대한 투자 비용을 줄이는 방향이 바람직하다.
신고
오늘 MS 개발자 행사인 RemixK에 다녀왔습니다.
10년 이상 자바개발자 행사만 다닌 저한테는 다소 낮선 자리였습니다.

오늘 컨퍼런스 내용중에 흥미로웠던것중에 하나가 WinMobile7이었습니다.
년말에나 나올 '내일폰'이긴 합니다만.
Feature들이 흥미로워서 이야기 해봅니다.

크게 개발환경이 SilverLight와 XNA로 나뉘어 지는데, 일반적인 애플리케이션 개발은 SilverLight기반으로 하게 되어 있습니다. 그런데 개발툴이 일반 개발자 개발툴이라기 보다는 동영상 저작도구 같은 느낌이더군요. 아이폰의 Object C 개발환경, 이클립스 기반의 안드로이드 개발환경을 맛본 저로써는 다소 신선했습니다. 저작도구 답게 UI프로그래밍이나 이펙트가 매우매우 쉽습니다.
아마 아이디어만 있다면 웹디자이너라도 쉽게 기본적인 어플은 만들 수 있겠더군요.

그리고 다음이 XNA인데, 게임 개발 플랫폼입니다. 상당히 흥미로운 점은 XNA로 개발된 윈모7게임은 XBOX와, WIN7에서도 똑같이 동작합니다. 물론 화면 사이즈에 맞춰서 다시 렌더링 되서 말이지요. 이게 소위 MS에서 이야기하는 3Screen입니다. 한번 개발해서 모바일,데스크탑,TV에서까지 모두 사용할 수 있다는 겁니다.
게임 개발 프레임웍도 상당히 쉽습니다. 10년전(?)에 Direct X로 게임 개발을 하고 OPEN GL로 3D 프로그래밍 경험을 했을때 이것저것 만드느냐고 상당히 시간이 오래걸렸는데, 허허~~ 오늘 보니 이건 거의 거져 만들더군요. 충돌 로직이나 조이스틱,화면 IO,애니메이션 처리.. 한마디로 거져라고 말할 수 밖에 없을만큼 쉬워졌습니다.

그럼 이런것들이 무엇을 뜻 하느냐?

1. 개발자들의 진입이 쉬워집니다.
누구나 아이디어만 있다면 기술의 장벽을 넘어서 컨텐츠를 제공할 수 있다는 겁니다.
2. 시장이 넓다.
XNA기반의 게임 컨텐츠는 한번 개발하면 PC,X-BOX,모바일 환경에 모두 판매가 가능합니다. 한마디로 개발자의 투자 대비 수익이 늘어나는 거지요..

이 두가지 특징만 해도 모바일 플랫폼으로 무시 못할듯 싶습니다.
여기에 더불어서, 윈모7 탑재 디바이스들은 철저하게 스펙 규약이 있기 때문에 (화면 사이즈, CPU 제약,메모리 제약). 안드로이드가 겪고 있는 여러 스펙의 디바이스로 부터 오는 문제를 피해갈 수 있습니다.

또한 MS의 Azure 클라우드는 모바일 서비스에 새로운 가능을 제시해줍니다. 3G망 기반의 모바일 애플리케이션들은 인터넷을 통해서 통신을 하거나 OPEN API들을 호출합니다. 애플이나 안드로이드에서 작동하는 앱들은 대부분 공개된 오픈 API를 사용합니다.
그렇다면 특화된 서비스를 개발하고 싶다면? 서버 사이드를 구축해야할 필요가 있다면?
사야져... 서버도 사고.. 세팅과 운영도 하고... 개인이 하기는 비용이 만만하지 않습니다. 그래서 일부 전문 업체만 서버를 두고 OPEN API를 통해서 자사의 앱과 통합하는 형태를 가집니다.
그런데....
MS는 Azure를 들고 나왔습니다. 클라우드 플랫폼이져.. 개발이 다른 클라우드 플랫폼에 비해서 매우 쉬운 (비주얼 스튜디오에 개발환경이 통합되어 있어서, 기존 웹 개발 환경만 이해한다면 별도의 Learning Curve가 필요없습니다. ) 장점을 가지고 있고, 사용량에 대해서 과금을 하기 때문에, 손쉽게 서버를 갖출 수 있습니ㅏㄷ.

XNA지원,3Screen,모바일용 클라우드 보유

이 3가지 장점만 해도 모바일 2라운드를 한번 해볼만 하지 않을까 싶네요.
애플이 4세대 아이폰을 내고, 안드로이드 2.2가 경이로운 성능을 보여주기는 하지만 근본적으로 접근 방법이 틀리다는데에서 기대를 걸어봅니다.
신고