R을 시작하며..

빅데이터가 화두로 떠오르면서 함께 주목받는 언어가 바로 “R”이다.
R은 오픈소스 기반의 데이터 분석엔진이다.
이미 대학이나 연구소 등에서는 통계분석 툴로 많이 사용해왔는데,
최근 들어 하둡과의 연동을 지원하는 라이브러리로 인해 빅데이터 분석과 데이터 마이닝 툴로 급격히 관심을 받고 있다.

R의 가장 큰 장점이자 강점이라고 한다면, 무한한 패키지이다.
우리가 생각하는 왠만한 기능은 이미 누군가 패키지로 만들어두었다고 보면된다.
또한 누구나 패키지를 만들어 공유할 수도 있다.
R을 잘 사용하는 방법은 어떤 패키지를 활용하면 되는지 아는 것이라고 할 수 있다.

새로 접하는 R은 생소하지만, 이미 많은 사람들이 사용하고 있기 때문에 조금만 검색해도 많은 레퍼런스를 찾을 수 있다.
관련 사이트를 소개하면 다음과 같다.

• R 프로젝트 : http://www.r-project.org
• 한국 R 사용자 모임 : http://r-project.kr
• R을 경험해보기 좋은 사이트 Try R: http://tryr.codeschool.com/

R 사용법은 각자 공부해야 하는 부분이다. 위에서 소개한 사이트를 통해 R을 설치하고 기본적인 사용법을 익혀보자. CodeSchool 의 Try R 의 경우 단계별로 따라가면서 해볼수 있게 되어있으므로 꼭 해보길 추천한다. 이 글에서는 실무적으로 활용한 R에 대해 공유하고자 한다.

R 따라하기

이번에는 처음 시작하는 단계로 누구나 쉽게 접할 수 있고, 흥미를 느낄 수 있는 wordcloud를 같이 구현해보자.
트위터에서 “kth”라는 키워드로 트윗을 검색한다.
1/21부터 1/27까지 1주일간의, 한국어로 된 트윗만 대상으로 한다.
아래는 R 소스코드이다.

우선 필요한 라이브러리들을 설치해야한다.
설치는 한번만 하면 되고, 이후에는 로딩만 해준다.
twitteR 패키지에 있는 searchTwitter 함수를 사용해서 검색을 한다.
사용법을 알고 싶을 때는 콘솔에 help(searchTwitter)를 입력하면 document를 볼 수 있다.
다른 함수들도 help()를 사용해 사용방법과 args를 확인하고 값을 적절히 변경해보면 기능을 금방 이해하는데 도움이 된다.

searchTwitter를 사용하면 리턴값은 해당 패키지에서 사용하는 클래스 형식이다.
str(result)를 해서 데이터형을 확인해볼 수 있다.
해당 트윗의 내용, 등록일, 등록한 사용자의 id와 스크린네임, RT까지 리턴된다.
여기서 필요한건 트윗 내용이기 때문에 text 부분만 따로 뽑아주었다.

이대로 따라해주기만 하면 다음과 같은 wordcloud가 완성된다.

kth DevOps

kth 에서 DevOps 팀을 조직한지 거의 1년이 되었습니다.
이전의 포스팅과 H3 2013 에서 DevOps 에 대해서 소개해 드린 바 있습니다.

DevOps 이전 포스트 보기

• DevOps, 개발과 운영의 새로운 문화
  
• [DevOps] 요리사가 뭔말인가? Chef Series #1 #2 #3

kth 뿐만 아니라 대 고객서비스를 하고 있는 곳에서는
기획 > 설계 > 개발 > 빌드 > 테스트 > 배포 > 모니터링
에 이르는 어플리케이션 라이프사이클에 대한 고민을 가지고 있습니다.
 
이 단계를 짧게 연속적으로 끊임없이 Agile 하게 수행할 수 있어야 고객이 원하는 것을 신속히 제공하여 서비스의 사용률 하락 없이 계속 발전해 나갈수 있는데요. 저희 팀에서는 각 단계별로 직접 개발하거나, 오픈소스 솔루션을 도입/개선 해서 해결하고 있습니다.

Safari Tour

이번 글에서는 어플리케이션 라이프사이클의 가장 마지막에 있는 모니터링을 위해 직접 개발한 Safari Tour 를 소개하고자 합니다. 이 이름은 Netflix 의 Chaos Monkey 에서 영감을 받아 다음의 개념들을 담을 수 있도록 하기위해 “사파리 투어 (Safari Tour)” 라고 명명하였습니다.

<Safari Tour>

(image from :  http://www.safari.com/wp-content/uploads/2010/11/jeep_safari1.jpg)

<Safari Tour Entity>

사파리투어는 야생에서 원숭이(동물)를 데려다 훈련시키고 그것들을 우리에 넣어서 원하는 지역에 배치하고 코스를 지정하는 것이 실제 동물원에서 관람객을 받아서 관광할 수있게 하는 것과 비슷하다고 할 수 있습니다.

<Safari Tour 절차>

Architecture

Safari Tour 는 서비스 개발자, 기획자, 사업담당자가  DevOps 팀에 별도로 요청이나 교육 없이도 쉽게 등록하여 서비스의 안정성을 높일 수 있도록 개발되었습니다. 이러한 사용성에 대한 요구와 운영의 요구를 수용하기 위해 다음과 같이 주요 요구사항들을 정리하여 그에 맞는 아키텍처를 수립하였습니다.

사파리투어 아키텍처의 요건

1. Zookeeper 는 지역에 구애받지 않고 쉽게 배치할 수 있어야 한다.
2. 모니터링 트래픽을 여러 Zookeeper 가 분산해서 처리해야 한다.
3. Single point failure 를 극복하기 위해  job 을 클러스터링 할 수 있어야 한다.
4. 모니터링 대상 프로토콜을 쉽게 확장 할 수 있어야 한다.
5. 모니터링 등록이 쉬여야 한다.
6. 단순확인 및 시나리오모드 모두 지원해야 한다.
7. 이 시스템은 DevOps팀만이 아니라 모든 사용자가 주인이고 신뢰대상이므로, 생성한 오너는 생성/수정/삭제의 자유를 보장해야 한다.

<Safari Tour Architecture>

이 아키텍처에서는 중추적이 역할을 하는 가장 중요한 부분이 Work Message Bus 인데, 처음엔 Gearman 의 Job Server 모델을 사용하려 했으나, 메시지에 대한 보안 대책이 없어, SSL 과 인증을 지원하는 RabbitMQ 를 사용하게 되었습니다. 그 다음 모니터링을 수행할 Zookeeper 는 테스트 시나리오가 XML 포멧으로 오픈되어 있어 전용 툴을 사용하지 않아도 외부에서 직접 생성하여 사용할 수 있는 SoapUI 를 채택하였습니다.

<Safari Tour 에서 사용한 오픈소스>
 

Monitoring, Alarm

Safari Tour 에서 모니터링을 등록하는 순서는 다음과 같습니다.

1. Monkey 를 신규 생성한다.
   1. 타켓 URL 을 입력한다.
   2. http method 를 선택한다. (GET, POST, PUT, DELETE)
   3. header 가 필요하다면 입력한다.
   4. http body 에 파라미터가 필요하다면 입력한다.
   5. 성공으로 판단할 조건으로 status code, response time, response body 입력한다.
2. Cage 를 생성한다.
   1. 모니터링을 수행할 Zoo 를 선택한다.
   2. 이미 생성된 Monkey 를 순서대로 배치한다.
   3. Monkey 에서 지원하지 않는 프로토콜 또는 좀더 복잡한 시나리오가 필요하다면 SoapUI 에서 생성한 프로젝트 xml 을 붙여넣는다.
   4. History 통계에서 묶어서 보고싶은 Tour 를 선택한다.
   5. 모니터링을 수행할 시간과 주기를 선택한다.
3.  약 1분 후 메인화면에서 모니터링 결과를 확인할 수 있다.

<모니터링을 등록 / 확인하는 동영상>

Safari Tour 는 직접 등록한 모니터링에 대한 알람 뿐 아니라, Amazon Cloud Watch – SNS 와 연동하여 발송 할 수 있습니다.
Amazon SNS(Simple Notification Service) 는 Cloud Watch 에서 발생한 알람을 SMS, email, http/https 로 발송할 수 있는데, 운영자가 인지하는데 가장 효과적인 SMS 는 특정 지역으로 한정되어 있어 우리나라 이통사로는 발송할 수 없습니다. 이를 위해 SNS 를 https 로 받아 룰에 따라서 대상자에게 SMS 를 발송할 수 있습니다.

Open API

Safari Tour 에서 웹에서 모니터링을 등록하고 확인할 수도 있지만, Open API 를 통해서 직접 등록, 조회 할 수 있습니다.

<Open API List>

진행 예정 사항

• 외부 서비스 오픈
  Safari Tour 는 현재 1.0 버전으로 kth 내부에서 사용되고 있으며, 2월 말 kth API Store를 통하여 외부 오픈을 시작합니다.
• 배포 후 자동 모니터링
  개발 예정인 배포시스템과 연동하여, 배포된 시스템을 타켓으로 테스트를 수행하여 배포 즉시 배포 성공/실패 여부를 판단할 수 있도록 합니다.
• Open API 확대
  데이터 위주에서 page 에 직접 include 할 수 있는 그래프 API 추가
• 모니터링 추적
  모니터링이 발생해서 database 에 수집되기 까지 거쳐야 하는 단계를 실시간 추적하여 지연구간을 파악할 수 있도록 합니다.

Reference

• Rabbit MQ  http://www.rabbitmq.com
• SoapUI http://www.soapui.org
• Redis http://redis.io
• Ruby on Rails http://rubyonrails.org
• Nginx http://nginx.org

2013년 2월 4일, kth 기술전략팀이 발행하는 기술 신동향 & 뉴스 링크입니다.

[ 모바일 - 아이폰/안드로이드 ]

• [kth 모바일 리포터]스마트폰 이용고객 이제 지갑 열 준비 되었다!! http://t.co/mB51PbSm 5번째 연재되는 kth의 생생한 모바일 사용자 리포트!
• 인스타페이퍼 개발자 마르코의 iPhone Plus 예상 http://t.co/QNN5Brpr 만약 나온다면 4.94인치, 640×1136 픽셀, 16:9 비율의 아이폰 플러스가 나올것이다.
• BusinessInsider 예상 2013 모바일 트렌드 http://t.co/li6iVfWg 미니&저가 타블렛과 함께 타블렛의 성장,개발도상국들의 스마트폰 확대,모바일 결제 와 광고의 급격한 성장예상. 쉬운 예상들이지만 배경들의 수치데이터가 좋네요

[ 웹사이트, 웹서비스, 웹기술 ]

• jQuery 플러그인 Registry 오픈 http://t.co/ttWx6ipC GitHub가 지원하는 WebHooks 이용. 이 뉴스를 보는 제 관점은 이런 외부연계를 위한 WebHook 같은 기능 제공이 정말 중요하다는 것이 더 크게 보여집니다
• 반응형 디자인 북마클릿 – 브라우저 툴바에 넣고 누르면 바로 현재페이지를 아이폰/아이패드(가로/세로)까지 반응형 디자인 테스트 가능하게 해줍니다. http://t.co/zVfUQWfc 모바일 키보드 보기 까지 있네요(아이폰 키보드만 지원)
• Prefetching 을 이용하여 사이트 속도 빠르게 하기 http://t.co/qTKHriga DNS/Resource/Page Prefetching에 대한 소개. 대역폭낭비 및 통계를 복잡하게 하는 면이 있지만 알아 둬야 할 내용들
• Form Follows Function – 멋진 HTML5 데모 사이트 http://t.co/60PHUa4n 눈이 휘둥그래지는 데모들!
• Nginx 와 Lua 로 API 확장하기 http://j.mp/WoDrVe Nginx를 API Proxy로 사용하면서 Lua를 이용해서 데이터변환,API 재정의,데이터 취합등이 가능하게 하는군요.
• 왜 구글은 JSON결과앞에 while(1); 을 추가하는가 http://j.mp/WoDQHb Cross-site Request Forgery 를 방지하기 위함. JSON결과를 내보내는 공개 API를 가진곳에서는 참고할만한 질답쓰레드

[ 프로그래밍/HTML5/CSS/Javascript ]

• 느린 네트웍 환경을 만들어 앱 테스트 하는 방법 http://t.co/IOwRtSNO 윈도에선 Fiddler2,맥에선 Network Link Conditioner,리눅스에선 Trickle 그외에 Charles,RoboHydra,TCPMon
• 빠른 웹사이트 작성을 위한 웹 퍼포먼스 집중 강좌 http://t.co/RdA11ThS 구글 Make The Web Fast 팀 Ilya의 3시간짜리 강의자료. PDF 130장. 이러닝 플랫폼인 Parleys를 통해 청취가능
• Flight – 트위터가 공개한 경량 컴포넌트 기반 자바스크립트 프레임워크 http://t.co/u5tbXXeH 이벤트 기반으로 DOM 노드에 연결,다른 컴포넌트들과 완전히 독립된 형태로 기능 추가가 가능. mixin 지원

[ DB,DevOps,클라우드,웹서버 기술 ]

• 추천 시스템 분석 – 어떻게 아마존과 넷플릭스가 당신의 취향을 예상하는가? http://t.co/8yBxrFr8 실시간 분석시스템 DAISY를 개발중이신 김정민PD의 깔끔한 번역. DAISY내부의 추천엔진에 대해서도 후속글이 이어질 예정입니다.
• DevOps 리딩 리스트 http://t.co/FRuLm8EQ
• 데이터시각화 공부하기 http://t.co/EEqT6yLN 이에 따라 어떻게 하면 데이터를 1) 효과적으로, 2) 효율적으로, 3) 아름답게 표현할 수 있을 것인가
• Drake – 데이터를 위한 make 툴. 데이터 정제를 위한워크플로우 관리,단계별 실행,다른 쉘툴과의 연계등. CSV를 이용한 예제가 친숙하네요 http://t.co/pXRtlVap
• Collaborative Filtering @ Spotify http://j.mp/YvM7rh CF의 기본개념부터 어떻게 구현했는지, 그리고 다양한 분야에 응용한 사례들까지 정리. 깔끔한 발표자료네요

[ 추천글 ]

• 레티나 디스플레이와 디자인의 미래 http://t.co/5p9f7KtV 스큐어모피즘(오리지널 사물을 본떠 만드는 데 충실한 디자인) 에서 탈피하기 시작한 것은 레티나 해상도 디자인 시대의 개막을 의미한다.
• AirBnB TechTalks – 매주 수요일 저녁에 자사직원들 대상으로 외부강사를 초청해서 진행하는 기술 세션들을 정리해서 올리고 있네요 http://t.co/h39sPMoT
• 내가 하는 편이 빠르다 병에 관한 정리 http://t.co/nf6gyQR4 ・「맡긴다」란 「실패할 권리를 주는 것」 ・실패의 경험을 쌓게해주는 것이 상관의 일 ・일은 책임과 함께 맡긴다 ・계획과 검증은 함께 하고, 실행은 혼자서 하게 한다

피드백 환영합니다!

kth 개발자 블로그를 RSS리더에서 구독하시면, 매주간의 기술뉴스와 kth 임직원들이 작성하는 다양한 전문기술 글들을 보실수 있습니다.

CVI(Customer Value Innovation)팀 내 조사/분석파트는 시장동향분석, 고객리서치, 고객데이터 분석 등을 통해 고객 Needs 및 Unmet Needs를 발굴하여 서비스 개선과 활성화를 위해 노력하는 조직 입니다.

“2012년 스마트폰 이용자 조사”의 목적은 스마트폰 서비스를 제작하셨거나 계획하고 계신 개발사 또는 인디 개발자분들께 이용자 관점에서 생각하고, 고민하는 기회를 가졌으면 하는 바램으로 기획 되었으며,  이전 조사 결과는 아래 링크를 통해 확인하실 수 있습니다.

▶2012년 3분기스마트폰 이용자조사 > [kth 모바일 리포트]갤럭시 이용자 33%, 아이폰으로 갈아탈 것
▶2012년 2분기스마트폰 이용자조사 > [kth 모바일 리포트]앱 설치 시 사용자들의 리뷰 영향력 높아져
▶2012년 1분기스마트폰 이용자조사 > [kth 모바일 리포트]연령 낮을수록 ‘스크린샷’, 높을수록 ‘앱설명’ 보고 앱 선택

이번  4분기 조사는 2012년 스마트폰 이용자 조사 중 마지막 조사이며 1년을 정리하는 내용으로 작성 되었습니다.
아래  조사대상에서 아이폰 이용자 4,137 명은 최신성을 유지하기 위해 iOS6 이용자만을 대상으로 하였으나,   iOS5와  iOS6 구분이 필요한 일부 항목에서 iOS5 이용자 330명의 응답결과가 포함되었음을 말씀 드립니다.

2012년 4분기 스마트폰 이용자 조사

▶ 조사제목 : 2012년 4분기 스마트폰 이용자 조사
▶ 조사기간 : 2012년 12월19일 ~ 12월31일
▶ 신  뢰  도 : 95% 신뢰수준의 오차범위 ± 1.34%
▶ 조사대상 : 스마트폰(팟게이트)이용자 총 5,371명(아이폰 4,137명+ 안드로이드폰 1,234명)응답

※용어의 정의 :  구글플레이 = 안드로이드마켓 , Q=Quarter(분기). 4Q=4분기를 말함

1. 구글플레이 이용자가 어플 설치 시 가장 많이 찾는 메뉴는 “인기무료 애플리케이션”

아래  [그래프1]에서 보듯이 2012년 동안 구글플레이 이용자들이 신규 어플을 설치하기 위해 가장 많이 찾는 메뉴는  ”인기무료애플리케이션”으로 확인 되었다. 그러나,  3Q부터 “인기무료애플리케이션 메뉴를 찾는 이용자 비율이 감소하는 특이치가 발견 되었는데 감소한 이용자들이 어떤 메뉴로 이동하였는지?[그래프2]에서 확인해 보자

[그래프1] 구글플레이 이용자 어플 설치 시 많이 찾는 메뉴

2. 인기무료메뉴와 신규인기 뮤료메뉴는 반비례 관계

[그래프1]에서 어플설치시 “인기 무료 애플리케이션”을 방문하는 비율이 2012년 2Q(68.6%)에서 3Q(57.1%) 로  11.5% 로 감소되었는데, 2Q에서 3Q로 넘어갈 때  약 11.5%의 방문량이 증가 메뉴는 찾아보니  ”새 인기무료애플리케이션” 로 확인되었다. 즉 [그래프2]에서 보듯이 “인기무료” 메뉴 방문자가  대부분 ” 새 인기 무료” 메뉴로 이동 했다고 예상할 수 있다. 그렇다면 왜? “인기무료”메뉴에서  ”새인기무료”로 이동했는지? [그래프3]에서 확인해 보자

[그래프2] 인기무료 메뉴와 신규인기무료 메뉴의 방문비교

3. 구글 플레이에서는 “무료인기” 메뉴에 Major앱이 많을 때 신규어플을 런칭하라!

[그래프3]은 “애니팡”을 대상으로 “앱스토어”와 “구글플레이”에 런칭시점부터 약 170일간의 랭킹 추이 그래프이다. 애니팡은 앱스토어에서 런칭당일 즉시 1위에 랭크 되었지만, 구글플레이에서는 1위가 되기까지 17일 걸렸다.  또한 1위 달성 후 24위까지 하락 하기까지 기간을 보니 앱스토어에서는 57일이 걸렸고, 구글플레이는  141일이 걸렸다.

이렇게 앱스토어보다 구글플레이가 높은 순위에 올라가는 기간도, 높은 순위에서  다시 내려오는 기간도 오래 걸리는 이유는 폰별 이용자 특성도 있지만 안드로이드폰이 아이폰에 비해  월등히 많은 이용자가 있기 때문이기도 하다. [그래프3]과 같이 인기 어플들이 구글플레이  ”무료인기”메뉴 상위에 랭크되어 오랫동안 머물게 되면  ”무료인기”메뉴를 자주 방문하는 이용자인 경우는 순위변동을 거의 느낄 수 없을 것이다.

따라서, 전혀 순위 변화가 없는 것 처럼 보이는 “인기무료”보다  순위변화가 자주 일어나는 ” 새 인기무료” 메뉴를 찾을 수 밖에 없기 때문이다. 이는 우리가 홈페이지 방문 시 업데이트 되지 않은 “회사소개” 한 번 이상 방문하지 않고 업데이트가 자주 일어나는 “게시판”을 보는 이유와 같다.

만약 안드로이드 어플개발이 완료 되었는데 런칭시점을 저울질하는 개발사가  너무 많은 Major 앱들로 인해 런칭시점을 못 잡고 있다면, “무료인기”메뉴을 매일매일 모니터링한 다음  “무료인기”메뉴에서 Major 앱들이 정말 많이 포진되어 순위 변화가 거의 없을 때, 신규앱으로 런칭하여 “새 인기 무료” 메뉴에서의 기회를 잡는 방법은 어떨까? 제안해 본다.

그런데 왜? 하필 2Q도 아니고  3Q부터 이런 이런 현상이 나타 났을까?? [그래프4]에서 확인해 보자

[그래프3] 애니팡 앱스토어 & 구글플레이 랭킹추이

4. 2012년 7월 구글플레이(안드로이드마켓) 카카오톡 게임센터 출시로 Major 어플 양성소

2012년 3Q 시점에 구글플레이  ”무료인기” 메뉴에서 어플의 순위 변화가 없으려면, 그 시점에 딱!! 맞춰 엄청난 Major 앱들이 많이 출시 되어야  가능한 일인데, 도대체 어떤 앱들이 한꺼번에 상위에 올라가서 내려오지 않았을까?  [그래프4]는 2012년 9월 12일 동일한 시간대에  ”앱스토어 랭킹순위”와 “아이폰 카카오톡 게임센터를 통해 출시 된 어플”리스트를 캡쳐한 자료이다.

앱들을 자세히 보면 어떤  Major 앱들이 있었는지? 바로 확인이 가능하다. 그런데, 2012년 9월13일이면 4Q에 반영되어야 되지 않나? 의문을 가질 수 있는데, [그래프4]는 다시 말해 앱스토어 사례이고, 구글플레이(안드로이드마켓)  카톡 게임센터는 2012년 7월에 런칭했고 [그래프1]와 같은 3Q의 특이치가 가능한 것이다.

[그래프4]2012년 9월13일 앱스토어 랭킹순위 & 아이폰 카카오톡 게임센터 적용 게임리스트

5. iOS5 에서 iOS6로 넘어가도 이용자가 어플 설치시 가장 중요하게 생각하는 것은 오직 무료!!

[그래프5]에서 앱스토어 이용자들은 어플 설치시 가장 많이 찾는 메뉴로  ”차트”를 선택했다.  ”차트” 방문자가 3Q에 비해 4Q에 늘어난 이유는 2012년 3Q시점이 iOS6로 업데이트 된 지 얼마 되지 않은 시점으로 iOS5 에서 가장 많이 찾았던 메뉴인 “인기25>무료” 메뉴가 “차트>무료”에 있다는 것을 3Q에는 모르고 있다가 4Q에 학습된 것으로 예상된다.

[그래프5]iOS6 이용자가 어플설치 시 많이 찾는 메뉴

참고로 [그래프6]에서는 4Q 조사 응답자 중 iOS5(n=330) 이용자들만 추출하여 분기별 추이를 확인해 보았다. 그 결과 1Q~3Q에 비해 특이치는 없었고,  iOS5이용자는 여전히 어플설치 시 “인기25메뉴”를 가장 많이 찾는다는 응답을 했다.

[그래프6]iOS6 이용자가 어플설치 시 많이 찾는 메뉴

6. 대량의 어플 설치는 입소문 즉, “좋은리뷰”에서 시작된다. !

[그래프7~8]에서 가장 중요하게 해석해야 할 부분은 2012년 내도록 이야기 했던 “리뷰”에 대한 부분인데, “리뷰”는  1Q ~ 4Q까지 꾸준히 증가한 유일한 요소이기도 하다.  마케터는 좋은 리뷰를 받기 위해 “바이럴 마케팅”과  ”리뷰이벤트”를 충실히 기획 하겠지만 “프로모션/마케팅”을 통한 긍정 리뷰를 끌어내는 데는 한계가 있다는 것은 금방 깨닫게 된다. 교과서 같은 이야기이지만 고객니즈를 근거로  고객이 원하는 서비스를 만들고 고객으로부터 좋은 리뷰를 받아야  성공? 아니 생존! 할 수 있다는 교훈을 얻을 수 있는 부분으로 해석된다.

[그래프7]아이폰 이용자 어플설치 시 영향을 미치는 요인

7. 고객은 이제 지갑 열 준비 되었다!!

[그래프7] 앱스토어와 [그래프8]구글플레이 할 것 없이 어플 설치 시 가장 많은 영향을 미치는 요소는”무료”에 대한 니즈로 나타났는데, 여기서 개발사 입장에서 미미하지만 긍정적인 부분은 찾을 수 있었다. 그 것은 무료에 대한 고객니즈가 분기가 가면 갈수록 감소하고 있다는 것인데, 이는 아주 느리긴 하지만  고객들이 앱을 사용하는 데 있어 비용을 지불할 준비가 조금씩 되고 있다는 것이 긍정적인 부분이라 하겠다. 그럼 실제 유료 결제경험이 얼마나 늘었는지? [그래프9]에서 확인해 보자

[그래프8]구글플레이 이용자 어플설치 시 영향을 미치는 요인

[그래프9]에서는 최근 한달간 유료어플 설치경험에 대한 질문인데,  3Q 대비 4Q가 안드로이드폰(+6%증가), 아이폰(+7%증가) 이용자 모두 유료결제 경험이 상승 하였음을 확인할 수 있다.

[그래프9]2012년 3Q 대비최근 한달간 유료어플 설치경험 추이 

[그래프10] 스마트폰 이용기간과 유료어플 설치경험을 비교해 보면 이용기간이  2년 이상이 되는시점부터 유료결제 금액상승이 다른 이용기간에 비해 높이 나타나는 것을 확인할 수 있다. 2009년  iPhone 출시 후 2012년은 많은 수의 스마트폰 이용자의 이용기간이 벌써 2년을 넘었거나 2년이 넘는 시점이라는 개발사 입장에서는 좋은소식이 아닐 수 없다.

[그래프10] 최근한달간 유료어플 설치경험_스마프폰 이용기간별

또한, [그래프11~12]에서 보듯이 지난 3Q대비 4Q는 “구글플레이/아이폰/남자/여자/나이” 를 불문하고 1만원 이상 유료결제한 이용자들이 모두 상승했음을 볼 수 있는데 이 또한  고객들이 돈을 지불할 의사가 있다고 예상할 수 있으며 개발사 입장에선 아주 긍정적인 지표다.

[그래프11] 최근 한달간 설치한 유료어플 총금액 3Q~4Q추이비교_OS별/성별

[그래프12] 최근 한달간 설치한 유료어플 총금액 3Q~4Q추이비교_연령별

8. 스마트폰 이용자들의 가장 관심 카테고리는 “게임”

[그래프13~14]에서 이용자들의 관심 카테고리를 확인해 본 결과  ”게임”카테고리의 독주는 2012년 내내 이어진 트랜드이고, 이와 같은 이용자 성향은 2013년에도 크게 변화하지 않을 것으로 예상되고, Start-up 개발사가 신규 앱을 고민하고 있다면, 비록 게임 카테고리가 blue ocean이 아닌 blood ocean이 되어 버린지 오래지만, 안정적인 수익구조는 아니지만 최소한의 수익구조를 위해 “게임” 카테고리가  도전을 게을리 할 수 없는 카테고리임에는 분명하다.

[그래프13] 구글플레이 이용자 관심 카테고리 3Q~4Q추이비교

[그래프14] 아이폰 이용자 관심 카테고리  3Q~4Q추이비교

9. 휴대폰 구매시 가장 중요하게 생각하는 것은 제조사의 단말기 기종!!

[그래프15]에서는 휴대폰 구매시 가장 영향을 많이 미치는 요인에 대한 질문에서 56%의 이용자가 “단말기제조사”를 답했다. 직설적으로 말하면 갤럭시, 아이폰, 옵티머스, 베가, 넥서스 등등 단말기 기종이 가장 큰 영향을 준다는 것이다. 즉, 우리가  다른 혜택이 아닌 “최신형 단말기를 바꿔 준다”는 TM(Tele Marketng)전화를 받는 이유가 여기에 있는 것 같다.

[그래프15] 휴대폰 구매시 영향을 미치는 요인

[그래프15]에서 제조사 단말기가 휴대폰을 선택하는 가장 중요하다고 하는 의견에 뒷 받침할 수 있는 내용을 [그래프16]에서 추가로 확인할 수 있는데, 아래 휴대폰 종류>아이폰 이용자 수치를 보면  3Q대비 4Q에 스마트폰을 변경하겠다는 의향이 크게 감소 하였는데, 그 이유는  iPhone5가 2012년 4Q 에 출시되어 아이폰으로 스마트폰을 변경하고자 하는 이용자의 니즈가 충족되었다고 볼 수 있다.

실제 스마트폰 이용기간이 약 2년 전후 시점에서 대부분 약정기간이 끝나기 때문에,  스마트폰 변경의향이 이용기간이 2년 전후로 부터  높아지는 것은 이미 공공연한 사실이다. 그런데 2년 전후의 이용기간을 가지고 있는 이용자들이 [그래프16]에서 3Q에 비해 4Q 니즈가 높아져야 함에도 불구하고, 감소한 이유가 2년 전후의 이용기간을 가지고 있는 스마트폰 이용자가 신규 iPhone5 출시로 니즈가 충족되었기 때문에 4Q의 변경의향이 감소하여 하였다고 볼 수 있다.

참고로, 아래 휴대폰 종류 중 안드로이드 계열의 갤럭시부터~넥서스까지 안드로이드 폰 이용자의 변경의사가 3Q에 비해 4Q가  높아지고 있는데, 이 또한  안드로드폰 개열의 신규 단말을 기다리는 잠재 수요로 볼 수 있다.

단, 위 결론은 아이폰 이용자는아이폰으로 이동할 가능성이 높고, 안드로이드폰 이용자는 안드로이드폰 이용이 높을 것이라는 전제을 가정으로 하였는데, 실제 [그래프17]에서 보듯이 갤럭시 보유 이용자는 갤럭시를 아이폰 이용자는 아이폰을 소유하고자 하는 니즈가 다른 기종에 비해 높게 나타나고 있다.

 [그래프16] 스마트폰 변경의향 추이

10. 아이폰 vs 갤럭시폰 이제부터 진검승부!!

[그래프17]에서 갤럭시를 보유하고 있는 고객이 아이폰를 사고 싶어하는 비율이 32.8%에서 30.8%로 -2.0%로 소폭 감소하였지만, 아이폰을 보유한 고객이 갤럭시폰를 사고 싶어하는 비율은 23.8%에서 31.7%로 +7.9%로 상승하였다.

따라서, 종합적 보면 갤럭시고객이 아이폰으로 이동희망 31%로  아이폰에서 갤럭시로 이동희망 32%인데, 아이폰입장에서 보면 이제 “갤럭시가 경쟁 할만한 상대로 올라왔다”고 이야기 할 수 있을 것이고, 갤럭시 입장에서 본다면 이 시점이 “Golden Cross”다 라고 이야기 할 수 있을 것이다. 여하튼 이용자의 입장에서는 어떤 스마트폰을  선택해야 할지? 행복한 고민이 아닐 수 없다.

[그래프17] 현재 보유한 스마트폰 이용자가 신규 스마트폰 구매 희망한  스마트폰 비율

지금까지 4분기 스마트폰 이용자 조사 결과를 말씀 드렸습니다.^^

2009년 아이폰이 등장 후

우리 개발사 들은
2010년 앱만 만들면 대박날 것이라는 기대로 달려 왔습니다.
2011년 앱을 만들어 봐야  돈 도 안 된다고 푸념 한 적도 있었습니다.
2012년 IAP(In App Purchase/Products)와 SNS구조의 절묘한 조화로  조금씩 대박 회사들이 나타나는 것을 보았습니다.
2013년에는 이제 고객들이 지갑을 조금씩 열기 시작 했습니다.
조금만 더 힘 내서 2013년에는 모든 개발사가 대박을 나길 기원합니다.
새해 복 많이 받으세요~^^ 화이팅!!

PS) 안내의 말씀
2012년 3분기 조사 결과 발표 후 한 분께서 이런 문의를 주셨습니다…
[문의] 현재 안드로이드폰 이용자가 아이폰 이용자 보다 거의 10배 많은 상황인데, 왜? “조사대상”에 아이폰 이용자가 더 많나요?..시장 점유율에 맞게 안드로이드 이용자를 늘어야 되는 것이 아닌가요?

문의 주신분께는 별도로 답변을 드려 이해해 주었는데, 여러분들도 궁금해 하실 것 같아 말씀 드리고자 합니다.
다시한번 문의 주신분께 감사드린다는 말씀 드리며, 그 이유에 대해 설명 드리겠습니다. 문의 주신 말씀이 200% 맞는 말씀이십니다.  그럼에도 불구하고 저희가 X고집^^으로 조사대상에 대해 추가/변경 하지 않고 끝까지 밀어 붙힌 이유는 저희의  최초 기획의도가 있었기 때문이었습니다.

저희 “스마트폰 이용자 조사”의 최초 기획의도는 “스마트폰 이용자”가 어떻게 변화 하는지? 추이”를 보자! 었습니다. 그런데 만약 ”추이조사” 진행 시 중간에 조사대상자가 흔들리게 되면, 이전 조사자료가 추이 분석에 의미가 없어지기(ㅠ.ㅠ) 때문에 본의 아니게 고집을 피운게 되었습니다. 다시 한번 양해 부탁 드리며  2013년에는 여러분들께서 주신 많은 의견 반영하여 좀 더 도움되는 정보로 다시 찾아 오겠습니다.

여러분들의 의견/조언/제안 등등 많은 댓글 부탁 드립니다.^^

대단히 감사합니다. (”)(..)

★ 동일 데이터!! 다양한 생각!!

들어가기전

추천분야는 1990년대에 시작된 이후 지금까지 꾸준히 발전 해오고 있습니다. 비교적 조잡하고 부정확한 형태로부터 시작 했지만, 데이타가 다양하고 많아질수록 더욱 발전 하였고 그러한 데이터와 함께 혁신적인 알고리즘을 덧붙여 갔습니다. 이러한 추천시스템은 현재 아마존 상품 추천, 넷플릭스 영화추천, 페이스북의 친구 추천 등 대형 서비스와 함께 지속적으로 영역이 확대되어가며 점점 중요성이 높아지고 있습니다. 또한 대학들은 이러한 추천을 정규 코스로 추진 해가고 있으며, 휴대폰 회사들은 다른 이통사로 이탈확률이 높은 고객들을 예측하기 위해 사용하기도 합니다 .

이러한 추천의 배경이 무엇인지 살펴보도록 하겠습니다.

[추천 효과]

• Netflix : 대여되는 영화의 2/3가 추천으로부터 발생
• Google News : 38% 이상의 조회가 추천에 의해 발생
• Amazon : 판매의 35% 가 추천으로부터 발생
• Netflix Prize (~2009) Netflix에서 주관하는 경연대회로, 영화 선호도를 가장 잘 예측하는 협업 필터링 알고리즘에 수상 (US$1,000,000)

협업 필터링(Collaborative filtering)

이런 추천의 근간이 되는 유사점을 분류하는 방식에 협업 필터링 이라 불리는 방법이 존재 합니다. 사전에 누적된 대규모의 데이터를 활용하여 이를 분류하고 분류된 데이터의 기준을 기반으로 새로운 데이터에 대입하여 분류하는 방법 입니다. 이러한 협업 필터링의 분류기준은 대표적으로 두 가지가 존재 합니다.

[출처 :Deconstructing Recommender Systems by JOSEPH A. KONSTAN, JOHN RIEDL  /  OCTOBER 2012]

사용자 기반(user-user)

두 사용자의 공통된 아이템을 기반으로 얼마나 많이 일치하는지 거리를 수치화 하는 방법을 사용합니다. 예를 들어, 짐과 제인이 각각 트론이라는 영화에 5점을 입력하였다면, 그 둘 사이의 거리는 0입니다. 반면, 한명은 5 점, 나머지 한명은 3점을 입력하였다면 거리는 증가하게 됩니다. 이러한 사용자간의 유사도를 활용하여 추천하는 방식이 사용자 기반이라고 볼 수 있겠습니다. 그러나, 사용자 기반의 필터링은 공통점을 이끌어내는 것이 쉽지 않다는 문제점이 존재합니다. 사용자 간의 공통점이 추천에 활용할 수 없을 많큼 데이터가 부족할 수 있기 때문입니다. 한가지 예를 들면, 대부분의 사람들은 블록버스터 영화에 선호도가 집중하는 경향이 있습니다. 대부분의 데이터가 블록 버스터 영화에만 데이터가 몰려있기 때문에 추천의 결과가 모든 사용자들에게 동일한 현상이 발생할 확률이 높으며, 이는 추천에 대해 무의미한 결과를 가져 오기도 합니다. 또는 웹사이트를 기준으로 볼 때 어떤 페이지의 특정 부분을 클릭하는데 많은 시간이 걸리기 때문에 데이터 수집 자체에 어려움을 겪을 수도 있습니다. 간단한 설명이라 부족한 점이 있지만 , 추천에 있어 적절한 데이터 양의 부족으로 인해 공통요소(분류기준)을 분류한다는 게 아주 단순하다고는 볼 수 없습니다. 이를 보완할 수 있는 방법 중 하나가 아이템 기반이라 할 수 있습니다.

아이템 기반 (item-item)

오늘날 대부분의 추천시스템은 사용자 기반 대신 아이템간이 거리를 사용하는 아이템 기반을 활용합니다. 넷플릭스와 아마존이 세부적인 내용은 공개하진 않지만, 아이템 기반의 다양한 알고리즘을 사용한다고 공개적으로 언급하고 있습니다. 아이템 기반에 대해 예를 들어 설명을 간략히 하면, 톰클랜시의 책을 좋아하는 사람들이 Clive Cussler의 책도 아주 좋아한다면,Clancy 와 Cussler는 아주 가깝다고 볼 수 있습니다. 즉, 사용자기반과 동일하게 유사도를 기준으로 아이템 간의 거리를 측정한 후 유사한 아이템을 추천하는 방식을 취한다고 볼 수 있습니다. 대부분 사용자대비 아이템이 적은 수를 차지하고 있기 때문에 아이템을 기준으로 볼 때 아주 다양한 관계 데이터가 발생할 확률이 높다고 볼 수 있습니다. 이러한 방식은 데이터가 누적 될수록 추천의 정확도가 높일 수 있는 가능성이 있습니다.

참고로, 원하는 전화번호를 쉽게 찾아 전화 할 수 있는 대표적인 114전국전화 앱에서도 아이템 기반의 분석을 통해, 추천 검색어, 검색품질 개선에 사용되고 있다.

문제점

비율의 일관성(inconsistency of ratings)

위에서 언급된 두가지 방식을 사용한다고 해도 여러가지 추가적인 문제점이 존재 합니다. 우선 첫번째로 비율의 일관성 문제 입니다. 다시 말해, 같은 아이템에 같은 방법일 지라도 재 측정시 값이 변할수 있으며, 원인은 사용자의 취향 이라는게 항상 고정되어 있는 것이 아니기 때문입니다. 1990년대 후반에 MIT에서 진행한 한 실험은 하나의 원본 비율이 1년후 7가지 형태로 변화 될 수 있음을 증명한 사례가 있다고 합니다. 이렇듯 축적된 데이터라고 하더라도 여러가지 요인에 의해 변동이 가능하다는 사실은 염두 해야만 합니다..

유사 아이템 추천

추가적으로 사용자 및 아이템 기반의 알고리즘은 일관성보다 더욱 큰 문제가 존재합니다. 적용 기준이 엄격하기 때문에, 동일한 아이템이 아닌 유사한 아이템을 기반으로는 적용 불가 하다는 것입니다. 예를 들어 설명 하자면, 모네의 수련 그림에 대한 팬이라고 가정 봅시다. 250 개의 작품중 사용자마다 정말 좋아하거나 또는 좋아하지 않는 작품이 존재 할수 있습니다. 이러한 상세 취향은 기본 알고리즘만 가지고는 각자 그들의 취향을 알수 없습니다. 그래서 이러한 유사취향 문제를 해결할 수 있는 차원 축소라 불리는 방법이 존재 합니다. 이 방법은 사용자 아이템 기반의 알고리즘보단 많은  계산량이 요구되기 때문에 실제 적용하기 까지 상당한 시간이 소요됬지만, 컴퓨터의 성능이 나날이 발전함에 따라 적용 가능하게 됐습니다.

차원축소(dimensionality reduction)

차원축소를 이해하기 위해 다른 수많은 사람들과 음식 취향을 비교하는 것으로 예를 들어보자. 거대한 메트릭스로 취향을 표현할 수 있다. 각각의 사람들의 취향과 수천가지 음식을 표로 만들어볼 수 있습니다. gave grille 5점, braised short rib 4.5점, s, fried chicken wing 2점,cold tofu rolls 1점,roasted portobello mushroom 5점, steamed edamame with sea salt 4점,등..이렇게 각각의 음식에 대해 점수를 부여한 데이터를 기반으로 , 추상화 단계를 거쳐 (예를들어, 짠음식,생선요리등) 유사한 기준으로 분류한 후 , 새로운 아이템을 유사도 분류 기준에 대입하여 적용하면 어느정도 같은 취향으로 분류가 가능하게 됩니다.

이러한 차원 축소를 적용한 추천은 상세한, 특정음식에 대한 점수가 그리 큰 영향을 미치지는 않습니다. 그렇지만 다양한 음식에 대해 차원감소를 적용함으로서 발생하는 일반화 현상은 이해하고 있어야 합니다.  예를 들면, beef, salty things, and grilled dishes는 좋아한다 로 정의 될수 있고, chicken and anything fried는 싫어한다로 정의 될 수 있으며, vegetable은 보통으로 정의 될수 있습니다. 이러한 형태로 축소시 약 50에서 100개의 차원으로 축소가 가능하게 되며, 차원을 보는 것만으로도 ,추천자는 새로운 음식이 속하는 범위를 빠르게 결정하는게 가능하게 됩니다. 이는 아직 분류되진 않은 유사한 아이템을 특정 사용자 에게 추천할수있게 하는 더욱 일반화된 방법이라고 볼수 있습니다. 차원 축소가 많이 적용될수록 추천이 더욱 효율적이라 할 수 있으며, 이러한 차원축소를 적용하기 위해 사용되는 방법중 특이값 분해 (Singular Value Decomposition, SVD)를 사용할수 있습니다.

추가 고려 사항

지금까지 추천의 기본적인 배경지식에 대해 살펴보았습니다. 추가적으로 알아두어야 할 몇 가지 부분을 좀더 알아보도록 하겠습니다.

만약, 이메일로 어떤 물건을 추천한다고 가정해 봅시다. 사용자가 이메일을 확인 후 쓸모 없는 내용이라 판단된다면, 그리고 이런 결과가 지속적으로 반복 된다면, 사용자로부터 신뢰를 잃을 것이며, 스팸으로 분류되어 사용자에게 어떠한 정보도 전달할 수 없는 상태로 이어질 수 있습니다. 이렇듯 정확한 정보를 전달하는 것은 매우 중요한 요소이며, 정확한 정보 전달 이후에 사용자와 판매자 둘 다 이익이 발생 해야 한다는 것 입니다.

정확성

정확한 추천이 어떻게 이루어 질 수 있는지 아마존의 온라인 스토어를 예를 들어 설명해보도록 하겠습니다.

아마존은 사용자에게 적절한 추천을 하기 위해 몇가지 방법으로 사용자의 성향을 파악합니다. 대부분 사용자가 해당 페이지에 접근한 후 활동한 내역들 기반이라 볼 수 있습니다. 예를 들면 제품에 대한 별점 적용수치, 방문한 페이지중 상세페이지까지 확인 했는지, 반복해서 접속한 페이지, 구매의향이 있는지, 실제 제품을 구매했는지, 동일한 세션 안에서 확인했던 목록 정보등, 클릭했던 모든 사용자 행동을 기반으로 성향을 파악 합니다. 이런 모든 사용자 데이터를 차후에 활용하기 위해 모아 둘 것입니다. 심지어 로그인 하지 않은 사용자 데이터 까지 모아서 활용하기도 합니다. 이런 대량의 데이터 수집활동은 온라인 스토어에서만 이루어 지는 것이 아니며 월마트와 같은곳 에서도 사용자 영수증 데이터(구매목록)를 활용 중에 있습니다. 나아가 전세계에서 지금도 진행되고 있는 중입니다. 단 유럽의 경우 법적으로 데이터 수집범위에 따라 제약을 받을 수 있습니다.

business rules

시스템이 잘못된 추천을 방지하고 사용자의 신뢰를 잃지 않으며 판매자의 수익을 최고로 하기위해 추가 적용된 부분이 business rules 입니다. 예를 들어 , 비틀즈와 같은 유명한 음악가들의 앨범을 모든 방문자에게 추천을 하고 있다고 가정해 보면, 통계적으로 옳은 수치가 적용됐다고 볼 수 있지만, 실제 구매는 거의 이루어 지지 않을 가능성이 있습니다. 모는 방문자들이 앨범에 대해 실제 높은 별점을 부여하기는 하지만 대부분 앨범을 소유 했기 때문입니다. 또 하나의 예로, Netflix의 영화추천 시스템의 사례를 설명하면 액션 영화를 좋아하는 사람에게 The Avengers(액션영화) 라는 영화를 추천 할 수도 있습니다. 그러나 실제론 Netflix에서는 대여 불가 항목 이라면, 추천 해야 될 영화 일지라도 서비스에서 허용하는 한계를 고려하고, 이러한 점들이 시스템에 당연히 반영 되야 할 것입니다. 그리고 기타 비즈니스 적인 요인들이 접목 되 야할 부분은 각 서비스별도 무수히 존재할 것이며 이를 잘 반영 해야 된다는 점은 중요한 부분 이라 생각 됩니다.

마지막으로 추천시스템을  검토 중이라면 아래 오픈소스들을 활용해보는 것을 추천 합니다.

참고로, kth 데이터지능팀의 대용량 실시간 분석 솔루션인 DAISY(Data Intelligence System)에서는 Apache Mahout 기반으로 추천엔진을 구성하고 있습니다!

2013년 1월 21일, kth 기술전략팀이 발행하는 기술 신동향 & 뉴스 링크입니다.

새해 첫 발송인데 좀 늦어졌습니다. 새해에도 잘 부탁드립니다.

[ 웹사이트, 웹서비스, 웹기술 ]

• 페이스북이 내놓은 그래프 검색 http://j.mp/XqYS48그에 대한 주요 기사들을 정리했습니다.
  • 새로운 페이스북의 검색 엔진: Graph Search http://t.co/LIrsnxv5
  • 페이스북 그래프 검색은 구글 검색과 뭐가 다른가 http://t.co/q95tj7NB 그래프검색은 페이스북을 사용자들이 보는 주요화면인 타임라인/뉴스피드 에 이은 “3번째 뷰”
  • 페이스북 그래프 서치의 안쪽 http://t.co/KOQCb3Yi 제목을 입력하면 그걸 해석해서 검색한 내용으로 화면을 만들어주는 PoC를 본 마크 주커버그 왈, “그거 만들기는 불가능해 보이는데, 만약 만든다면 정말 멋질거야”
  • 페이스북의 과감한 시도, 그래프 검색 http://t.co/q2k2j6px Wired 스티븐 레비 기사의 한글 번역본. 개발 뒷 이야기지만, 기술보다는 사용자 관점이 잘 정리된 기사네요.
• SavePublishing – 웹사이트 기사내용 일부를 포함해서 트윗할때 편한 북마클릿 http://t.co/C8jm4zJB 북마클릿 클릭하면 웹페이지내의 문장들이 버튼으로 바뀌고, 선택하면 트윗창으로 복사. 편하네요.
• 아마존 AutoRip – CD를 사면 그 안에든 내용의 무료 MP3를 제공하는 서비스 http://t.co/ZH85z21w 이제 씨디사서 미개봉으로 소장할수 있게 되는군요. 예전에 아마존에서 산 음반들까지도 해준다고
• MOOC ( Massive Open Online Courses ) http://t.co/XZbZ6vWJ 국내에선 누가 할 수 있을까요 ? NHNNEXT 에서도 커리큘럼과 수업자료들을 공개해주면 좋을 것 같습니다.
• Freebook Sifter – 아마존에 등록된 무료 eBook들만 리스팅 해주는 웹사이트 http://t.co/MDRm6L3N 킨들사용자 분들은 꼭 돌아다녀 보세요

[ 추천글 ]

• 아마존의 제품 개발 방법 http://t.co/OT2CqllV “working backwards” PM이 한장짜리 완료보고서를 예상 작성후,제품 수익자들에게 배포해서 확인하고 그 내용이 정말 타당할때까지 반복수정. 실제 개발시엔 시금석으로 사용
• 제프 베조스의 비즈니스 레슨 12 http://t.co/HtX50fLh
  • 비젼은 확고하되 디테일은 유연하게
  • 피자 두판의 작은팀
  • 실험을 지속하라
  • 탐험하고 발명하라
  • 길게 봐라
  • 혁신=실험+발명
  • 슬라이드대신 6P 문서메모로 회의
  • 고객에 주목
  • 변하지 않는 것에 기반한 전략수립
  • 위험을 초기에 인식하고 제거
  • 나중에 후회하지 않기 위해 지금 시작하라
  • 유행보다는 자신이 더 열정을 가지는 아이템을 선택하고, 고객 중심으로 work backward 하라
• 일반 사용자용 소프트웨어를 중심으로 변화되는 SW산업의 새로운 미래 http://t.co/UubE6UET NHNNEXT에서 만든 애니메이션. 정말 잘 만드셨네요. 강력 추천합니다.
• 구글닥스 ( Google Docs ) 가계부 2013년 버전 http://t.co/FZXdPNF4 by 김종민님 ( @kimjmin )
• Wired Gadgetlab 에서 정리한 CES http://t.co/oAVVgRdg 시선가는 제품들을 실시간으로 정리한 라이브 블로깅이어서 CES 전체 분위기를 보는데 가장 좋은듯
• 링크드인이 뽑은 2012년 베스트기사 12 http://t.co/gHPFjKVs 두고두고 챙겨볼만 합니다
• 뛰어난 직원의 8가지 특징 http://t.co/GnPGikFP 자신의 Job Description을 뛰어넘음/조직에 색깔을 부여하는 괴짜/하지만 중요상황엔 조직에 스며듬/칭찬하길 즐기고/조용히 불평/남들이 묻지않을때 질문/오류찾기를 즐기고/항상 뭔가를 손봐서 좋게 만든다
• 성공적인 비즈니스를 시작하는 5가지 팁 by 리처드 브랜슨 http://t.co/yRKF7U24 말하는것보다는 들어라/심플하게 유지/자신의 일에 자신감을 가져라/즐겁게하면 성공은 따라올것이다/버리고 다시 시작하라
• 데이터 사이언티스트를 위한 인터뷰 질문 리스트 http://t.co/FhenfuwR 첫번째 질문은 저도 좋아하는거네요. bitly 의 chief scientist 힐러리메이슨이 작성한 글
• 면접자가 하면 좋을 질문 5가지 http://t.co/dA86WXH6 – 처음 3달간 제가 어떤 일을 완수하길 바라시나요? – 여기 회사의 탑퍼포머들의 공통점은 뭔가요? 5개중 이 두개 질문은 마음에 드는군요 ;)
• 맥 프리비 번들 – 유용한 맥앱 8가지 무료 http://t.co/X64w6e2V 아이콘을 관리해주는 IconBox2 ($15) / 클립보드매니저 ClipBuddy ($30) 두개만으로도 훌륭하네요. 맥사용자분들 필수 다운! (트위터/페북계정 필요)
• QLMarkDown – OSX 퀵룩에서 마크다운을 볼수 있게해주는 플러그인 http://t.co/GUZogiOs 마크다운으로 문서 많이 만드시는 분들은 필수 설치 ;)
• IT Trend 2013과 플랫폼 전략 자문 프로그램 http://t.co/89opX0Qw 한국 마이크로소프트에서 만든 62페이지 슬라이드. 트렌드 전반을 이해하기 좋습니다.

[ 프로그래밍/HTML5/CSS/Javascript ]

• 프로그래머가 알아야 할 Latency 값들 http://t.co/Enk4OTX1
• howdoi – 스택오버플로우에서 원하는 샘플코드를 찾아주는 코맨드 라인 툴 http://t.co/0PKOd7Ay 정말 말도 안되게 편하군요. howdoi [원하는코드] [언어] 로 끝. howdoi tokenize bash/js/java..
• KTH의 지오펜싱 솔루션, Encloser 를 소개합니다. http://t.co/7yfp0ib8 단순한 경위도 반경단위 위치검색이 아닌, 폴리곤 형태로 정밀한 위치검색 기능을 API로 제공하며, 차후에 baas.io 에도 제공될 예정입니다.
• 빅데이터 시대, kth DAISY를 소개합니다. http://t.co/7GUKDpPm 지난 H3에서 간단히 소개드렸던 kth의 대용량 실시간 분석/추천 솔루션 DAISY를 소개합니다. 각 레이어별 상세내용 및 활용사례도 계속 공개예정
• Netflix API 최적화 사례 http://t.co/ozi8aYTh 동적 디플로이 되는 EP/그루비,JRuby,클로저등 다양한 언어 지원을 위한 JVM런타임/비동기 Java API + Functional Reactive 프로그래밍 모델의 조합
• Cubism.js – 시계열 데이터 시각화를 위한 자바스크립트 라이브러리 http://t.co/Ko1vVbJl D3플러그인이고 Graphite 데이터를 기본지원해서 각종 메트릭 보여주는데 딱 일듯

피드백 환영합니다!

kth 개발자 블로그를 RSS리더에서 구독하시면, 매주간의 기술뉴스와 kth 임직원들이 작성하는 다양한 전문기술 글들을 보실수 있습니다.

Geo-Fencing : 지오펜싱이란

모바일디바이스에서 꼭 필요한 기능으로 사용자의 위치를 파악해 반경이 아닌 특정구역을 설정해 사용자가 들어오면 정보를 제공하는 기법을 일컫는 말이다. 포스퀘어를 비롯해 많은 위치기반서비스들에선 기본적으로 이용되는 기법이다.  예를 들자면 길을 걷다가 주변마트나 상점의 할인정보와 쿠폰이 도착하여 판매하는 매장이 있는지도 알려준다.  더 나아가면 자신이 구입하고자 하는 물건등을 등록해 놓으면 해당 물건이 주변상점에서 할인하는 정보를 푸시해 주는 서비스로 활용 가능하다. 한 마디로 인공 지능형 비서인 셈입니다.

Smart Mobile Company를 지향하는 KTH에서 Mobile의 필수 요소인 지오펜싱 서비스를 위한 위치기반 처리 플랫폼,  메시지 푸시 플랫폼,  쿠폰 발급 플랫폼으로 이루어진 [엔클로저 솔루션]을 만들어 사내 서비스에 활용하고 발전 시켜 나가고 있습니다.

KTH 지오펜싱 솔루션 [Encloser (엔클로저)] 서비스 활용 소개

사용자가 이동하면서 지오펜싱 영역을 지날 경우 지오펜싱 영역에 정의된 메시지를 사용자의 핸드폰으로 전송되는 예제입니다. 사용자가 현재 있는 지역에서 바로 접근할 수 있는 곳의 메시지가 전송되므로, 사용자에게는 유용한 정보를 제공할 수 있고, 광고주 혹은 메시지 전달자는 불특정 다수의 접근 불가한 고객이 아닌 실제 접근할 수 있는 고객에게 정보를 제공할 수 있습니다. 따라서 오프라인 매장 광고의 경우 접근 불가한 사용자에게까지 메시지가 전달되지 않아 스팸성으로 인식되지 않아서 유용한 정보 전달로 인식되어 실제 방문 혹은 구매로 이어질 수 있는 고객의 수가 기존 메시지 광고보다 높습니다.

기술보유 현황

엔클로저 시스템구성

위치기반 처리 플랫폼: 사용자가 지오펜스 영역에 들어오는 것을 확인하기 위해서, 사용자의 위치를 수신 받아 설정된 지오펜스 영역과의 공간 연산을 할 수 있는 플랫폼으로 공간데이터의 연산처리, 변환, 입력 기능을 할 수 있는 위치 검색 플랫폼

메시지 푸시 플랫폼 : 사용자가 지오펜스 영역에 들어왔을 경우,  사용자에게 설정된 안내메시지, 지역정보, 상점 정보등의 정보를 모바일 기기에 보내기 위한 플랫폼

쿠폰발급 플랫폼 : 정보 제공 및 광고 목적으로 발급되는 쿠폰의 등록,  유효기간 설정등의 역활을 수행하는 플랫폼

특장점

윈도우, IOS, 안드로이드의 다양한 플랫폼 지원합니다.
: Open API 방식으로 OS와 관계없이 다양한 플랫폼에서 활용 가능한 서비스를 만들 수 있습니다.

지오펜스, 메시지, 쿠폰 서비스를 동시에 제공할 수 있습니다.

사용자가 광고나 쿠폰 등 정보를 받을수 있는 지오펜스 영역을 복잡도를 가진 다각형으로 설정 할수 있습니다.

[기존 반경 검색 영역]                                                                                    [엔클로져 솔루션의 다격형 지오펜스]

기존의 반경 검색으로는 사용자의 위치 기준으로 접근성이 고려되지 않고,  일정 거리로만 검색이 되어 사용자가 접근할 수 없는 지역에도 정보가 푸싱이 되어 사용자의 입장에서는 스팸으로 인식되어 버렸습니다.
그러나, 엔클로저는 다각형 지오펜스 설정으로 정확하게 전달하고 싶은 지역의 영역을 설정하여 접근성이 떨어질 수 있는  지역에 있는 사람에게는 정보를 전달하지 않음으로써 정보로서의 가치를 사용자에게 전달할 수 있는  타겟팅 서비스가 가능합니다.

디테일한 영역 설정 이외에 프렌차이즈 서비스의 경우 가맹점이 위치한 지역의 정보 전달이 가능 합니다. 예를 들면, 둘둘치킨 신대방2동점에서 쿠폰 정보를 전달하고자 할 경우 서울시 동작구 신대방2동을 설정하면 신대방2동에만 정보 전달이 이루어지도록   타겟팅을 할 수 있습니다.

데이터 구축 현황

전국 지오펜싱 영역 5만5천건 구축 (전국에 주요관심지역 홍대거리 대학로 가로수길 국립공원 등등)

[서울 구축 사례 #1]

[서울 구축 사례 #2]

상업지구 구축 예정 (쿠폰광고에 활용 예정)
: 소상공인등의  중소사업자가 엔클로저에서 지역 데이터를 분석하여 상점 주변에 사람이 많이 왕래하는 지역중에서 광고를 푸시할 지역을 선택하고 해당 지역에 대한 집중 타겟팅이 가능하도록 활용할 예정입니다.

서비스 적용 현황

[아임인]

아임인 서비스에서 소셜 게시글을 작성할 때 내 위치를 검색하지 않아도 위치한 유명 영역을 추천하여 줌으로서 소셜 게시글 입력에 대한 편의성을 높이도록 하였습니다.
추가 적용 예정 사항으로  아임인에서 소셜 게시글을 작성할 때 작성 위치 주변의 쿠폰을  즉시 발급 될 수 있도록 개발 예정입니다.
[디지털 전단지]

특정 지역을 지나는 사용자를 대상으로 쿠폰을 발송하도록 하였습니다.(예 :강원도 여행을 하고 있는 와중에 맛집 검색을 위해서 [아임리얼맛집] 앱을 실행하였을 때 강원도 가을 여행 쿠폰 3종 셋트 발송)

[T커머스 적용 예정]

티커머스에 등록된 상품중 지역성이 있는 상품의 경우 고객이 접근 가능한 곳이면,  할인 정보나 구매정보를 알려주어 구매를 유도하도록 할 예정입니다.

향후진행 예정 사항

T커머스에서 위치기반 정보 분석 서비스
T커머스사업에서 상품 추천 푸시 서비스에서 활용 할 예정으로 사용자들의 위치를 파악한 후, 빅데이터 분산 처리 분석 시스템인 KTH DAISY와 연계하여 사용자의 구매정보를 분석한 후 어떤 유형의 소비자인지 파악하여, 어디에 주로 가는지, 무슨 상품에 관심이 많은지, 어떤 정보를 원하는지를 주로 분석하여 사용자가 꼭 필요로 하는 서비스를 추천하도록 하는 인공지능형 서비스를 가능케하고 맞춤형 타겟팅 정보 푸시를 할 수 있도록 할 예정입니다.

baas.io Encloser API 제공
개발자들이 모바일 앱에서 꼭 필요한 위치기반의 서비스를 손쉽게 개발 할 수 있도록 백엔드 단의 사용자의 위치 파악, 위치 기반의 주소 연산, 주변 POI(Point of Interest) 검색등을 제공하여 간단한 아이디어 만으로도 쉽게 개발 할 수 있도록 할 예정입니다 

사용자 맞춤 서비스 제공
사용자가 미리 설정한 옵션에 따라서 관광 여행, 부동산, 쇼핑등의 컨시어지 서비스를 제공할 예정입니다. (예를 들면, 사용자가 1억원대의 아파트와 50만원대의 명품백을 설정하였을 경우 해당 설정에 따라서 사용자의 이동 경로에서 해당 하는 부동산과 상품이 있을 경우 메시지 알림을 통해서 사용자에게 정보를 제공합니다.)

Keyword : Data, Analytics,  In-Memory

매년 Gartner는 향후 기업들이 비즈니스를 하는데 있어서 중요한 영향을 끼칠 잠재력을 가진 전략기술 10가지를 소개한다. 2012년 소개에서 부터 Big Data라는 용어가 나오더니, 2013년에는 크게 3가지의 데이터 및 분석에 대한 전략기술을 소개했다.

전략적 빅데이터(Strategic Big Data), 실용 분석(Actionable Analytics), 인메모리 컴퓨팅(Mainstream In-Memory Computing)이다.
즉, 기존 데이터웨어하우스(DW)를 벗어나, 새로운 데이터 분석 기술을 결합해 빅데이터를 실용분석하여 사용할 것이며, 빅데이터를 처리하려면 성능과 응답시간을 향상시킬 수 있는 인메모리 기술에 주목했다.

kth DAISY

몇년 전부터 국내에서도 빅데이터, 대용량 분산처리 등에 대한 얘기들이 나왔으며, 인터넷, 모바일, 통신 등의 영역에서 발빠르게 준비를 하고, 실제 적용하여 서비를 개선 발전 시켜가고 있다. 그 영역이 의료, 생산, 공공 등 다양한 분야로 확산되어 가고 있는 현실이다.

Smart Mobile Company를 지향하는 kth에서도 꾸준히 준비해 온 결과, 대용량 실시간 분석/추천 솔루션인 DAISY(Data Intelligence System)를 만들어, 서비스 전방위적으로 활용하고 있다. DAISY의 목적은 데이터를 통한 서비스 및 사업의 가치를 높이는 역할을 하고자 만들어진 솔루션이다.

• DAISY : Data Intelligence System
  • 구성
    • 대용량 데이터 수집
    • 배치 분석
    • 실시간 복합 이벤트 분석
    • 추천
    • Visualization
  • 특징
    • Data 전체 라이프사이클 관리 기능 – 수집/저장/분석/통합/유지/폐기
    • Data 유형 변화에도 시스템 변경 없이 적용 및 운영 – 정형/비정형 데이터 처리 가능
    • Business 요구사항에 부합되는 적절한 분석 및 Latency 지원 – 실시간(Real-time, Near Real-Time), 배치(Batch)
    • 다양한 분석 알고리즘,  방법론 적용 가능 – MapReduce, Mahout, R 등의 오픈소스 활용
    • 오픈 소스 기반의 저비용, 고효율 플랫폼이며, Scale In/Out 용이

이 글에서는 kth에서 대용량 실시간 분석/추천 솔루션인 DAISY를 어떻케 구축을 했으며, 상세한 기술 스택 및 향후 로드맵에 대해서 이야기 하고자 한다.

DAISY 시작하기

DAISY라는 오픈 소스기반의 대용량 실시간 분석/추천 플랫폼을 만들어 서비스에 제공하기까지는 쉽지 않은 과정이 있었다.

구축하는 시스템의 구성 요소들이 오픈 소스라는 점, 대량의 데이터를 처리 및 관리해야 한다는 점, 갈길 바쁜 서비스에 당장 도움을 줄 수 없다는 점 등이 있었지만, 아래와 같은 원칙을 가지고 진행을 했다.

1. 프로토타이핑
   • 긴 iteration을 갖고 완성을 하는 게 아니라, 우선 가능성 판단을 2주 정도의 iteration을 갖고, 빨리 검토하여 위험성을 확인 후 실적용.
2. 쉬운 접근성 보장
   • 다양한 오픈 소스중에서 개발자들이 익숙한 환경의 오픈 소스를 선택.
   • 예를 들어,  MR,PIG 보다는 SQLike한 문장으로 분석할 수 있는 Hive, 실시간 분석에는 SQLike한 문장을 사용할 수 있는 Esper의 EPL, 기존 RDB의 데이터를 쉽게 통합 할 수 있는 Sqoop을 우선선택
3. 서비스 개선 우선
   • 시스템 구축이 목적이 아님. 즉, 시스템 구축보다는 어떻케 하면 서비스를 개선 할 수 있느냐가 우선.
   • 복잡다단한 시스템 없이도 서비스를 개선할 수 있는 방법은 다양하며, 그것을 먼저 고민해야하고, 그것을 위해 필요에 의해 시스템을 구축해야 하는 쪽으로 전략을 삼아야 한다.

그리고, 무엇보다 중요한 것은 의사결정권자(경영진)의 확고한 지원이다. 대량의 데이터를 수집관리해야 한다는 점, 오픈 소스라는 리스크 등에서 쉽게 진행을 결정하기에는 힘들다. kth에서는 경영진의 확고한 지원으로 보다 더 빨리 진행이 될 수 있었다.

위 3가지 원칙, 즉, 빠른 프로토타이핑, 쉬운 접근성, 서비스 개선을 가지고 진행한 DAISY의 전체 시스템을 소개한다.

DAISY 기술 스택 (Simple)

 DAISY 시스템 구축 진행 방향

앞서 말했듯이, 서비스 개선을 위해 필요한 시스템부터 하나씩 구축하여 활용하며, 통합을 진행한다.

1. 데이터 오픈
   • 기존에 내부에 있는 데이터, 즉, DB, Log 등을 모아서 개발실, 나아가 관심있는 사람들에게 모두 오픈하여(물론, 보안은 지키며..), 누구나 데이터를 들여다 보면서 분석에 대한 분위기 조성이 필요했다.
   • 우선, kth의 서비스 DB 데이터(아임IN,  푸딩.투, 114전국전화, 아임리얼맛집  등)를 한 곳에 모아 오픈했다.
   • 데이터를 통합 할 때 사용한 오픈 소스는 Apache Sqoop 또는 DB Im/Export
2. 데이터 수집
   • 이후 필요한 과정이 DB외의 정형/비정형 데이터, 로그에 대한 수집이 필요했다. 수집은 향후 분석을 위한 준비과정이며, 가장 중요한 과정이다. 이 과정에선 각 서비스 시스템에 영향을 최소화 하도록 주의해야 한다.
   • DB의 경우 주로 Sqoop를 통해 수집을 하며, 로그는 각 서비스의 상황에 맞게 DAISY 수집 Agent를 각 서비스 서버에 넣거나, FTP등 다양한 방법으로 수집을 한다. 그리고, 수집된 로그는 DAISY내의 수집 Queue로 보내면 수집과정은 완성된다.
   • 여기서 수집 Queue는 Apache Kafka이다. 단순히 수집 역할 뿐 아니라, 향후 Data Sync, EAI 등 kth 내의 데이터 유통의 전반적인 역할이 가능하여 Apache Kafka를 선택했다.
3. Visualization
   • 수집 다음으로 중요한 과정으로 대부분 ETL(데이터 전처리), 분석 등을 들 수 있겠지만, 그 보다 더 빨리 준비하고 오픈했던 부분은 Visualization 이다. 즉, 대용량 분산 처리, ETL, 분석 등을 하기 위해 많은 시간과 각 서비스 담당자들을 협의하고 설득하는 과정이 필요한데, 앞서 얘기했듯이, 서비스 운영,구축에 갈길 바쁜 서비스 담당자들이 아무런 내용을 보지 않고, 말로는 설득하기 힘들 것이다. 이럴 때 필요한 것이 Visualization이다.
   • 데이터를 오픈하고, 수집하고 나면 통계 등 간단한 Insight가 나온다. 그런 Insight를 Chart 등의 Visualization으로 보여주면 다음 기대감도 높아지고, 협의 및 설득도 쉬워진다. 그래서 분석보다는 먼저  Visualization에 심혈을 기울리게 된다. 또한, 대용량 분산처리, ETL, 분석등을 위한 시간을 벌 수 있으며, 병렬로 진행할 수 있다.
   • Visualization을 위해서는 각종 Chart Tool(Google ChartAPI)과 R 및 기타 Chart Open Source들을 사용했다.
4. 분석
   • 이제 젤 중요한 분석 단계이다. 분석의 단계 또한 처음부터 어려운 Mining 보다는 간단한 ETL을 통한 집계, 통계를 먼저 진행한다.
   • 기존 개발자들의 접근성을 고려하여 선택한 것이 Apache Hive이다. Hive는 SQLike한 문장을 통해 ETL을 손쉽게 처리할 수 있으며, 필요하면 Java로 UDF(User Defined Function)을 만들어 다양한 처리가 필요하다. 이 UDF는 나중에 실시간 분석 엔진인 Esper에서도 활용할 수 있다.
   • 분석의 꽃-Mining은 다음 단계의 추천을 위해 필요한 부분이다.
5. 추천
   • DAISY의 목표인 데이터 마이닝을 통한 추천, 이 추천을 위해 DAISY에서는 Apache Mahout과 R을 활용하여 추천 플랫폼을 구성하였다.
   • 다양한 Mining 오픈 소스가 있지만, 가장 널리 알려진 Apache Mahout과 R을 이용하게 되었다.
   • R은 상용솔루션에 대한 부담이 있고, 오픈 소스 기반의 Apache Mahout은 적용하기에 아지 미흡한 점이 존재한다. Apache Mahout을 활용하여 추천 시스템을 만들었다.
   • Mahout 등을 활용한 추천의 효과는 예를 들면,
     • Netflix : 대여되는 영화의 2/3가 추천으로 부터 발생
     • Amazon : 판매의 35%가 추천으로 부터 발생
     • Google News : 38% 이상의 조회가 추천에 의해 발생
6. Real-Time  분석
   • 위 내용까지 구축을 하고 나면, Near Real-time 및 Batch 처리가 완료된다. 이후 나오는 요구사항 실시간이다. 위 Hadoop EcoSystem 기반의 배치 분석을 통해서는 실시간성 요구사항을 수용하기 힘들다.
   • Real-Time, Real Real-Time을 위해서는 다른 솔루션이 필요했으며, 그 요구사항을 만족하는 오픈소스의 조합이 Storm-Esper이다. 이 조합을 통해 모든 메시지를 실시간으로 신뢰성 있게 처리할 수 있으며, 인메모리 분석, 이벤트 처리를 할 수 있었다.
   • 실시간 분석을 통해 실시간 랭킹, 실시간 로그 분석 등 다양한 분야에 활용이 가능했다.
   • 전 세계적으로 지난 해(2012)까지는 실시간 분석의 기반이 마련되었다면, 올 해(2013)부터는 실제 사업, 서비스에 활용되는 아주 많은 사례들이 나올 것이다. 실시간 처리를 위한 대형 벤더들의 많은 솔루션이 있지만, 위 2가지의 오픈소스의 조합으로 충분히 대응이 가능하리라 판단된다.
7. 모니터링 & Workflow
   • 다양한 서비스 서버로 부터의 수집과 분산된 저장소 등 운영해야할 서버가 금방 수십 대로 늘어 날 것이다. 모니터링의 중요성이 대두 되는데, 여러 유료 모니터링 솔루션이 있지만, 오픈 소스중에서 DAISY에서 가장 적합한 모니터링 솔루션으로 JBOSS의 RHQ를 선택했다.
   • DAISY의 모든 서버가 Java 기반이라 JMX를 활용하여 원하는 모든 자원을 모니터링 할 수 있으며, 문제점 발생시 24시간 노티를 받고 있다. 서버의 일반적(CPU, MEMORY, DISK 등) 상황 뿐 아니라, HDFS, M/R Job의 상태 등도 웹콘솔로 확인 할 수 있다.
   • Job들의 Workflow를 매번 서버상에서 Configuration 바꿔가기 보다 웹콘솔상에서 Workflow를 관리 할 수 있다.
   • 오픈 소스인 Apache  Oozie 를 커스트마이징하여 Workflow를 직접 구현해서 사용하고 있다.

자 이제 Step-by-Step 으로 각각 필요한 시점에 만든 솔루션 DAISY의 전체 Full-Stack을 공개한다.

DAISY 기술 스택 (Full)

• Layer 별 주요 모듈에 대해 설명하면,

TO-DO

이렇케 DAISY 솔루션의 전체 구성이 완료되어 운영되어 지고 있으며, 향후 DAISY는 아래와 같이 발전시켜 나갈 예정이다.

1. OpenAPI화
   • DAISY에서 분석/추천되어진 내역들을 OpenAPI화 하여 우선 kth 내부의 서비스 등에 제공
2. DAISY Tech Open
   • Batch 및 실시간을 적용한 사례들을 지속 오픈
3. 실시간 분석을 위한 최적의 솔루션으로 발전

DAISY 솔루션을 아래 그림으로 다시 정리한다.

Reference

• CEP / Esper
  • EsperTech http://esper.codehaus.org/
  • kth H3 2012 오픈 소스로 구현하는 실시간 데이터 처리를 위한 CEP http://h3.kthcorp.com/2012/session/index/S054
  • About Esper : http://wp.me/p2Stwv-76
• Storm
  • http://storm-project.net/
  • About Storm : http://wp.me/p2Stwv-5p
• Hive
  • http://hive.apache.org/
  • About Hive : http://wp.me/p2Stwv-3l
• Sqoop
  • Apache Sqoop : http://sqoop.apache.org/
  • About Sqoop : http://wp.me/p2Stwv-3O
• Mahout
  • http://mahout.apache.org/
  • About Mahout : http://wp.me/p2Stwv-4L
• JBoss RHQ
  • http://www.jboss.org/rhq

2012년 12월 17일, kth 기술전략팀이 발행하는 기술 신동향 & 뉴스 링크입니다.
 

[ 추천글 ]

• Spotify 가 어떻게 계속 성장하면서도 Agile 할수 있는가 http://t.co/NkjbD06Y  Squads / Tribes / Chapters / Guilds 로 구성된 딜리버리에 최적화된 매트릭스 조직. 멋진 회사! 배울게 많은 14장 PDF
• 변화를 위한 아키텍팅 by Etsy http://t.co/ihuzDSyf “모든 엔지니어는 1%의 사용자들에게 새 기능을 런치할수 있다” 지속적 배포와 통합 , 메트릭 기반 개발 때문에 가능한 일이군요. Etsy 정말 멋지네요.
• 스타트업 아이디어를 얻는 방법 by Paul Graham http://t.co/yGCDRLx6 문제에서 시작하라/우물처럼 좁고 깊게 파라/먼저 자신이 미래에 살도록 하고, 거기서 부족한 것 & 재미나 보이는 것을 만들어라.. 등 필독 강추!
• 하루안에 배울수 있는 몇가지 유용한 컴퓨터 기술이 무엇일까요 ? http://t.co/Uijiq0ud  Git/정규식/스택오버플로우/NoSQL익히기/SQL기본기능익히기/HTML파싱도구 익히기 등
• [공개SW 활용 성공사례] KTH – 공개SW로 일체 구성된 백엔드 서비스로 BaaS 시장 개척 http://t.co/dnKgf8hd
• 디자인이 담기는 전체를 생각하다. #H3 디자인 스토리 http://t.co/vi4jekHj H3 개발자 컨퍼런스의 전체 디자인을 담당한 정덕주PD와의 생생 인터뷰. H3가 어떻게 디자인 되었는지를 알려드립니다.

[ 웹사이트, 웹서비스, 웹기술 ]

• Say Hello to Octicons http://t.co/hKxrmOdc 레티나에서도 이쁘게 보이는 GitHub의 웹페이지에 쓰이는 아이콘들이 어떻게 만들어 졌는지 설명하는 슬라이드. 아이콘폰트 방식이군요
• 구글 어낼리틱스(GA)를 이용하여 웹 퍼포먼스 이상 감지하기 http://t.co/YHWwxt6r GA야 말로 구글이 웹/앱 운영자와 개발자에게 주는 큰 선물. 잘 익혀서 쓰는 것이 성공의 지름길이라고 생각합니다. Google Analytics 교육은 구글에서 운영하는 온라인 교육과정 을 추천합니다. http://t.co/zfty6YP5
• 스케일러블한 웹 아키텍처와 분산 시스템 만들기 http://t.co/qQIitkN4 요즘 웹서비스들의 복제/파티셔닝/캐쉬/프록시/인덱스/로드밸런서/큐 등을 전반적으로 다룬 Dobbs저널의 장문기사. AOSA2에서 발췌해서 잘 정리했네요
• 4백만 기부자,총 2억5천만불을 펀딩한 오바마 캠페인측의 웹스택 http://t.co/iQ9uFX5c Jekyll 기반 정적 웹페이지. S3와 Akamai CDN. LESS 와 Optimizely. REST기반 결제 API
• Optimizely – 웹사이트 기반 A/B 테스팅을 쉽게 해주는 서비스 http://t.co/ZWUbd8T3 유료서비스이긴 한데, 실시간 편집툴이 아주 편하군요. 오바마캠페인 측에서 썼다고 해서 더 유명해졌습니다.
• 페이스북 HipHop 프로젝트의 현재 http://t.co/0Fq7sLpO HHVM(힙합VM)이 HPHPc(힙합 PHP-to-C++ 컴파일러) 수준으로 빨라져서 대체되었다고.. PHP를 계속 발전시키는 페이스북..
• SlickSlide – deck.js,impress.js,reveal.js 등으로 만들어진 발표자료로 발표시, 참석자들이 자신의 장비에서 같은 페이지를 볼수 있도록 동기화 해주는 온라인 툴 http://t.co/HbCNb5vN
• 왜 우리가 Mobile First 에서 Web First 로 Pivoting 하는가 http://t.co/JxDO8tcY 대세를 거스르는? 의견이지만, 성공하기 힘든 모바일보다는 사용자가 쉽게 접근할수 있는 웹을 무시할수 없다는 이야기. 재미있습니다.
• 2013년 구글 방문자의 1위는 모바일기기가 될것이며, 유튜브는 트래픽 25%가 모바일에서, 한국의 경우는 유튜브 모바일 트래픽이 이미 50% 초과 http://t.co/b2XKQzYZ 하지만 과연 모바일에서 걸맞는 수익이 날지? 구글의 위기일지도
• HAProxy 에 NPN 과 SPDY 적용하기 http://t.co/086X6S7H NPN(Next Protocol Negotiation) 자체는 SPDY만을 위한건 아니지만, 현재로선 SPDY용으로만 사용중

[ 모바일 - 아이폰/안드로이드 ]

• Xcode LLDB Tutorial http://t.co/qHTwY0cN Xcode 4.5 부터 기본 디버거가 LLDB로 변경되었죠.
• MS Surface와 iPad 4세대의 HTML5 점수비교표 http://t.co/IETyTu2W 아직은 Surface가 갈길이 멀군요
• 2012 3Q의 전세계 모바일 기기 점유율은 안드로이드 72.4%, iOS 13.9%, RIM 5.3%, 바다 3.0%, 심비안 2.6%, MS 2.4% 라고 by 가트너 http://t.co/733h1ZIL 안드로이드 점유율이 1년새 20% 증가

[ 프로그래밍/HTML5/CSS/Javascript ]

• jsTimezoneDetect – 자바스크립트로 타임존 알아내기 http://t.co/O68zatH6 gzip 상태로 1.65KB
• Photobooth.js – HTML5 와 웹캠을 이용해서 웹페이지에 포토부스 달기 http://t.co/jkLJ7Vjk  크롬21/FF17/오페라12 버전이상에서 동작
• Goorm – 국내에서 개발된 오픈소스 클라우드 기반 IDE http://t.co/H3VlOUpE C/C++부터 Java/Dart/Go/Node.js 등을 지원하는 군요. node와 몽고DB기반으로 우분투와 Mac에서 실행가능
• HTML5 앱과 사이트를 빠르게 만들 50가지 퍼포먼스 팁 http://t.co/8hvvZ6dU MS IE PM인 Jatinder Mann의 1시간짜리 발표와 212페이지 슬라이드
• 플리커 업로더가 어떻게 브라우저 상에서 (죽지않고) 1만장의 사진을 보일수 있게 했나 ? http://t.co/gR57xiZF 발표자료와 블로그글 참고 http://t.co/P8STttAZ
• 모바일 기기에서 HTML5 터치 최적화하기 by 플리커 http://t.co/wwf3KKxz
• 유용한 git alias 모음 http://t.co/LgPw86kV 예제까지 포함되어 있어서 보기 좋군요. log 관련 alias 가 쓸만할듯

[ DB,클라우드,웹서버 기술 ]

• NGINX,PHP-FPM+APC,Varnish 로 WordPress를 빠르게 바꾸기 http://t.co/AOqOOIWX 단계별로 잘 정리되어있네요. 보통 블로그만들때 APM+WP 인데, 바꿔볼만할듯
• Envato가 Solr 에서 Elasticsearch로 교체한 이야기 http://t.co/vX5551Do ES가 설치도 쉽고, 복제와 샤딩도 쉽고 성능도 뛰어남. 단, 아직 초기 버전이라 좀 불안하고 문서도 없다는게 약점
• SoundCloud 의 새 검색기능을 위한 아키텍처 http://t.co/CiuJr4V3 역시 Solr로 시작했다가 ElasticSearch 로 바꿨네요. 위의 Envato 사례와 많이 겹치는듯
• Solr 와 ElasticSearch 의 비교 @ 스택오버플로 http://t.co/BtyzY80Z 그중에서 “Solr는 일반적인 검색을 만들때 좋지만, Elasticsearch 는 현대적인 실시간 검색을 위한 아키텍처로 한 단계 더 뛰어나다”
• AWS SDK for Node.js 개발자 프리뷰 공개 http://t.co/WqQt0rB7 npm으로 설치한후 S3,EC2,SWF,DynamoDB 등을 쉽게 쓸수 있음. 아마존의 직접 지원!
• Typical “Big” Data Architecture http://t.co/yXgad9qI 너무 간략화 된것 같기는 한데.. 그림한장과 함께 짧은글로 정리되어서 좋네요 ;)
• Tengine – nginx를 개량한 오픈소스 웹서버 http://t.co/9SuKAu54  동적모듈로딩/인풋바디필터/Lua스크립트 지원/로그개선/여러개의 CSS&JS 요청 합쳐서 처리등 다수 포인트를 개선
• 모니터링시 빅데이터 문제들 @ eBay http://t.co/WrD2HAjZ 일 500TB 로 커져버린 데이터 사이즈, 로그/메트릭/이벤트 등 다양하게 분산된 데이터인한 데이터 품질문제 등

피드백 환영합니다!

kth 개발자 블로그를 RSS리더에서 구독하시면, 매주간의 기술뉴스와 kth 임직원들이 작성하는 다양한 전문기술 글들을 보실수 있습니다.

원문 : http://earlybird.kr/1584

시작하며

모바일의 시대, 플랫폼의 시대가 도래하면서 IT기업에게 open API는 가장 중요한 자산으로 자리잡았다. 어떤 형식으로 API를구성하고 어떤 포맷으로 데이터를 주고받을 것인가에 대한 싸움도 치열했는데, SOAP & XML 과 REST & JSON이 경합을 벌인 끝에 REST & JSON의 승리로 끝났다. 이제 새로 생기는 모든 웹 서비스, 모바일 서비스들은 REST & JSON 기반으로 API를 제공하고 있으며 인증 방식으로는 OAuth 2.0을 택하고 있다.

얼마 전 OAuth 의 메인 에디터인 Eran Hammer 가 자신의 블로그에 자신이 OAuth 2.0 editor를 그만둘 것이며 OAuth 2.0 스펙에서 자신의 이름을 지워 달라는 글을 올렸다. OAuth는 SNS와 모바일 세상에서 가장 중요한 인증 방법으로 자리잡았고 OAuth 2.0은 아직 최종 스펙이 나오지는 않았지만 Facebook, Google 등에서 이미 널리 사용되고 있는 스펙이기에 이 소식은 많은 사람들의 관심을 받았다. 이 글에서는 OAuth에 대한 간단한 소개와 함께 OAuth 2.0에 대한 이야기를 해보려고 한다.

OAuth 1.0a – API 인증을 위한 만능 칼

OAuth 를 만들고 활성화 시키는데 기여한 가장 유명한 회사는 트위터다. 트위터를 비롯한 웹 개발자 들이 API의 인증(authentication; 이 사용자가 누구인가)과 권한 부여(authorization; 로그인 한 사용자가 무엇을 할 수 있는가?)를 동시에 제공하는 인증 프로토콜을 찾다가, 결국 적당한 것이 없다고 결론 내리고 새로 만든 것이 OAuth 1.0 이다. OAuth 1.0은 2007년 10월에 확정되었으나 나중에 세션 고정 공격(session fixation attack) 보안 결함이 발견되어 2009년 6월에 이 문제가 개선된 OAuth 1.0a가 발표되었다. OAuth 1.0은 보안 결함이 있는 버전이기 때문에 더 이상 사용해서는 안되는 버전이다. OAuth 1.0a는 2010년 4월에 “The OAuth 1.0 Protocol” 이라는 이름으로 RFC5849 문서 번호를 부여 받으며 IETF 표준이 되었다. RFC 표준이름에는 1.0뒤에 “a”가 붙지 않지만 많은 사람들이 아직도 OAuth 1.0a라고 부른다. 이 글에서도 명확하게 하기 위해 OAuth 1.0a라고 표현하기로 한다.
이 글의 주요 내용은 OAuth 2.0이긴 하지만, 1.0a에 대해서도 간단히 알고 넘어가려고 한다.

OAuth 1.0a의 장점

OAuth 1.0a가 기존의 다른 인증과 구분되는 특징은 크게 두 가지이다. 첫째, API를 인증함에 있어 써드파티 어플리케이션에게 사용자의 비밀번호를 노출하지 않고 인증 할 수 있다는 점. 둘째, 인증(authentication)과 API권한 부여(authorization )를 동시에 할 수 있다는 점이다. OAuth 1.0이 만들어지는 시점에는 써드파티에게 비밀번호를 노출하지 않고 인증하는 방법으로서 이미 Open ID가 있었다. 하지만 Open ID는 API의 권한 부여기능을 가지고 있지 않았고 인증 방법도 OAuth와는 방향이 많이 달랐다.

OAuth 1.0a 동작방식

OAuth 1.0a 가 작동하기 위해서는 기본적으로 유저(user), 컨슈머(consumer), 서비스 프로바이더(service provider)가 있어야 한다. OAuth 1.0a 인증을 3-legged OAuth 라고 부르기도 하는데 OAuth는 둘이서 하는 것이 아니라 셋이서 하는 것이라는 말이다. 간단하게는 각각 유저는 트위터 사용자, 컨슈머는 트위터 단말 어플리케이션, 서비스 프로바이더는 트위터 API 서비스 라고 생각하면 쉽다.

< OAuth 1.0a 트라이앵글>

새로운 트위터 어플리케이션을 앱스토어에서 다운 받았지만, 아직은 어플리케이션을 신뢰할 수 없는 상황이라고 하자. 사용자는 이 어플리케이션에 아이디와 비밀번호를 저장하면 이 어플리케이션이 또 다른 어떤 짓(몰래 아이디/비밀번호를 수집하는 등)을 할 지 모르기 때문에, 어플리케이션에 비밀번호를 저장하고 싶지 않다. OAuth 1.0은 이 경우 트위터 단말 어플리케이션 (consumer)에게 인증토큰(access token)만을 전달하고 단말 어플리케이션이 인증토큰으로 트위터 API(service provider)를 사용할 수 있도록 해준다.

< OAuth 1.0a 인증 프로세스>

이 과정에서 사용자가 서비스 프로바이더의 API를 사용하겠다고 로그인 할 때, 컨슈머는 서비스 프로바이더의 로그인 화면으로 사용자를 리다이렉트 하게 된다. 이 서비스 프로바이더의 화면은 아래와 같은 정보를 제공한다.

사용자가 이 화면에서 로그인을 완료하면 다시 컨슈머로 리다이렉트 되고 동시에 컨슈머는 인증토큰을 사용할 수 있게 된다. 이 인증 토큰은 컨슈머가 사용자의 아이디/패스워드 없이 허가 받은 API에 접근할 수 있게 해준다. 사용자는 컨슈머에 저장되어있는 인증 토큰이 유출 되더라도 서비스 프로바이더의 관리자 화면에서 언제나 그 인증토큰의 권한을 취소(revoke)할 수 있다.

OAuth 1.0a의 인증 과정에서 request token 등 추가적인 개념에 대해서는 이 글에서는 자세히 설명하지 않는다. OAuth 1.0a인증 과정에 대한 자세한 설명은 관련 자료가 많이 있으니 참고하길 바란다.

인증토큰

OAuth 1.0a 인증이 완료가 되면 컨슈머 (예를 들면 트위터 모바일 어플리케이션)은 사용자의 아이디/패스워드를 직접 저장하게 되는 것이 아니라, 인증토큰(access token)을 받게 된다. 이 인증 토큰은 OAuth 2.0에서도 같은 개념으로 사용된다. 인증토큰은 커베로스(Kerberos)의 티켓 개념과 비슷하다라고 할 수 있는데, 아래와 같은 특징을 가진다.

1. 컨슈머가 아이디/패스워드를 가지지 않고 API를 사용할 수 있음
2. 필요한 API에만 제한적으로 접근할 수 있도록 권한 제어 가능
3. 사용자가 서비스 프로바이더의 관리 페이지에서 권한 취소 가능
4. 패스워드 변경 시에도 인증 토큰은 계속 유효함.

자, 그러면 사용자의 스마트폰에 트위터를 인증해 놓은 상태에서, 스마트폰을 분실했을 때, 핸드폰을 습득한 사람이 내 트위터에 접근하지 못하게 하기 위해서 어떻게 해야 할까? 트위터 사이트에서 비밀번호를 바꿔도 트위터 어플리케이션은 계속 사용할 수 있다. 핸드폰을 분실 했다면, 아래와 같이 트위터 관리 페이지에서 어플리케이션 인증을 취소(revoke)하면 된다.
또한, 같은 원리로 트위터 비밀번호를 바꾸어도 내가 트위터 인증을 해놓은 수많은 어플리케이션들과 트위터 내보내기 설정해 놓은 서비스 들에서 다시 인증할 필요 없이 그대로 사용할 수 있다.

OAuth 2.0 – API 인증을 위한 만능 도구상자

OAuth 2.0은 OAuth 1.0a 와 호환되지 않으며 사용되는 용어부터 시작해서 많은 것들이 다르다. OAuth 1.0a가 만들어지고 어느 정도 지난 후에 IETF 표준이 된 반면에 OAuth 2.0은 거의 초기부터 IETF 표준 프로세스 안에서 만들어지고 있다. OAuth 2.0의 첫 번째 draft가 등록된 것은 2010년 4월 이었고, OAuth 1.0a에서 불편하다고 느꼈던 모바일에서의 사용성 문제나 signature 생성과 같은 개발이 복잡하고 CPU를 많이 소비하는 기능의 단순화, 기능과 규모의 확장성 등을 지원하기 위해 만들어 졌다. 그러기 위해 표준이 매우 커지고 복잡해 졌는데, 이것은 OAuth 1.0a 표준의 정식 명칭이 “OAuth 1.0 프로토콜(The OAuth 1.0 Protocol)“ 인데 반해 OAuth 2.0의 정식 명칙이 “OAuth 인증 프레임웍(The OAuth 2.0 Authorization Framework)” 인 것을 봐도 알 수 있다. 또한 OAuth 1.0은 하나의 RFC문서로 되어있지만, OAuth 2.0은 여러 개의 표준으로 작업이 이루어지고 있으며 그 표준들은 http://tools.ietf.org/wg/oauth/ 에서 확인 할 수 있다. OAuth 1.0a가 인증을 위한 만능 칼 이라면, OAuth 2.0은 인증을 위한 도구상자라고 할 수 있다. 다만 그 안에는 몇몇 위험한 도구들이 섞여있으니 검증된 도구만을 사용해야 하는데 그 안에 무엇이 있는지 알아보자.

OAuth 2.0이 1.0a에서 개선된 부분을 정리해보자

1. 간단해 졌다.
   OAuth 1.0a에서는 https 가 필수가 아니었기 때문에 API를 호출할 때 signature를 생성해서 호출해야 했다. 때문에 OAuth 1.0a API를 테스트 하려면 curl등을 사용하기 힘들고 별도의 API 콘솔등을 사용해서 테스트 해야 했다. OAuth 2.0의 Bearer 토큰 인증 방식을 쓰면 더 이상 signature 가 필요 없기 때문에 API를 테스트하거나 예제를 만들 때 간단하게 curl등 직관적인 방법을 사용해서 문서화하고 개발 할 수 있게 되었다.
2. 더 많은 인증 방법을 지원
   OAuth 1.0a는 한가지 인증 방식을 제공한다. HMAC을 이용한 암호화 인증 방식이다. 하지만 OAuth 2.0은 시나리오별로 여러가지 인증 방식을 제공하기 때문에 웹브라우저, 모바일 등의 다양한 시나리오에 대응할 수 있게 해준다.
3. 대형 서비스로의 확장성 지원
   커다란 서비스를 만들기 위해서는 인증 서버를 분리할 수 있어야 하고 또한 인증 서버를 다중화 할 수 있어야 한다. OAuth 2.0에서는 실제 API 서비스를 하는 서버와 인증 역할을 하는 authorization server의 역할을 명확히 구분함으로서 인증서버의 분리와 다중화 등에 대한 고려가 되어있다.

또한 OAuth 1.0a에서는 사용자(user), 써드파티 어플리케이션(consumer), API 서버(service provider)로 불리우던 것이 OAuth 2.0에서는 용어도 바뀌었다.

• Resource Owner : 사용자
• Resource Server : API 서버
• Authorization Server : 인증서버 (API 서버와 같을 수도 있음)
• Client : 써드파티 어플리케이션

OAuth 2.0 spec 구성

위 홈페이지에서도 볼 수 있지만, 현재 OAuth 는 oauth-v2 와 oauth-v2-bearer 라는 2개의 표준이 가장 핵심적인 부분이며 현재 RFC에 등록되기 위한 과정을 밟고 있는 중이다. 대부분 “OAuth 2.0 지원”이라고 하는 서비스 들은 이 2가지 spec을 지원한 다는 것을 의미한다. 이 외에도 SAML, JSON 웹 토큰, MAC 토큰 등의 방식이 있지만 아직 활발히 수정 중 이기 때문에 실제 서비스에서 사용되고 있지는 않다.

OAuth 2.0의 버전들

API 서비스를 일찍 시작한 회사들은 기존의 OAuth 1.0a 를 계속 유지하는 경우도 많이 있다. 1.0a와 2.0을 사용하는 유명한 서비스 들은 아래와 같다.

OAuth 2.0의 최종 버전이 나오는데 오래 걸리고 있기 때문에 Facebook, Google 등은 OAuth 2.0 spec의 draft 버전이 올라가면서 그 개선사항들을 구현해 오고있다. 현재 최신 draft 는 31버전인데 주요 서비스들이 구현하고 있는 버전들은 아래와 같다.

위 버전들은 서비스가 제공하는 OAuth 인증 페이지에서 수집한 것들이다. 보통 OAuth 2.0 spec의 draft 10 ~ 22 정도를 많이 구현하였는데 중요한 변경사항은 아래와 같은 것이 있다.

1. HTTP 헤더 앞 부분에 bearer 토큰을 보내기 전에 “OAuth” 에서 “Bearer”로 수정
2. “oauth_token” 이름이 “access_token” 으로 변경
   위 변경사항 때문에 아직까지는 두 가지를 모두 받아들이는 서비스들이 많다. RFC로 확정이 되면 더 이상은 변경이 불가능 하기 때문에 최종 안으로 정리가 될 것이다.

다양한 인증 방식 (Grant types)

앞에서 OAuth 1.0a가 동작하기 위해서는 사용자, 컨슈머, 서비스 프로바이더가 필요하고 3-legged OAuth 라고 불리우기도 한다고 하였지만, OAuth 2.0은 2-legged 모델 등 다양한 인증 방식을 지원한다. 3-legged 모델의 장점은 최종 사용자 뿐 아니라 개발자가 누구인지도 인증하기 때문에 어떤 어플리케이션이 API를 사용하는지 통계/과금 을 위한 필수적인 정보를 얻을 수 있다는 점이다. user-agent 나 referer 같이 변경될 수 있는 값이 아닌 인증을 통해 확실하게 구분할 수 있기 때문에 개발자가 API를 비정상적으로 호출하고 있다거나 할 때 개발자와 직접 연락하는 등의 조치를 취할 수도 있다. 그럼에도 불구하고 리다이렉트와 같은 OAuth에서 필요로하는 동작이 불가능한 시나리오, 둘이서만 인증하는 시나리오 등을 지원하기 위해 OAuth 2.0은 2-legged 모델도 지원하나, 그래도 OAuth 2.0에서 가장 기본이 되는 것은 3-legged 모델이다.

Client 는 기본적으로 Confidential Client 와 Public Client 로 나뉜다.

• Confidential 클라이언트는 웹 서버가 API를 호출하는 경우 등과 같이 client 증명서(client_secret)를 안전하게 보관할 수 있는 Client를 의미한다.
• Public Client는 브라우저기반 어플리케이션이나 모바일 어플리케이션 같이 client 증명서를 안전하게 보관할 수 없는 Client를 의미하는데 이런 경우 redirect_uri 를 통해서 client를 인증한다.

OAuth 2.0이 지원하는 인증방식은 client 종류와 시나리오에 따라 아래 4가지가 있다. 하지만 실제로 Authorization Code Grant와 Implicit Grant를 제외하고는 일반적인 3-legged OAuth 가 아니기 때문에 open API에서는 많이 사용되지 않는다.

1. Authorization Code Grant
   웹 서버에서 API를 호출하는 등의 시나리오에서 Confidential Client가 사용하는 방식이다. 서버사이드 코드가 필요한 인증 방식이며 인증 과정에서 client_secret 이 필요하다.
   로그인시에 페이지 URL에 response_type=code 라고 넘긴다.
2. Implicit Grant
   token과 scope에 대한 스펙 등은 다르지만 OAuth 1.0a과 가장 비슷한 인증방식이다. Public Client인 브라우저 기반의 어플리케이션(Javascript application)이나 모바일 어플리케이션에서 이 방식을 사용하면 된다. Client 증명서를 사용할 필요가 없으며 실제로 OAuth 2.0에서 가장 많이 사용되는 방식이다.
   로그인시에 페이지 URL에 response_type=token 라고 넘긴다.
3. Password Credentials Grant
   이 방식은 2-legged 방식의 인증이다. Client에 아이디/패스워드를 저장해 놓고 아이디/패스워드로 직접 access token을 받아오는 방식이다. Client 를 믿을 수 없을 때에는 사용하기에 위험하기 때문에 API 서비스의 공식 어플리케이션이나 믿을 수 있는 Client에 한해서만 사용하는 것을 추천한다.
   로그인시에 API에 POST로 grant_type=password 라고 넘긴다.
4. Client Credentials Grant
   어플리케이션 이 Confidential Client일 때 id와 secret을 가지고 인증하는 방식이다.
   로그인시에 API에 POST로 grant_type=client_credentials 라고 넘긴다.
5. Extension
   OAuth 2.0은 추가적인 인증방식을 적용할 수 있는 길을 열어놓았다. 이런 과도한 확장성을 메인 에디터인 Eran Hammer는 매우 싫어했다고 한다.

Password Credentials Grant와 Client Credentials Grant는 기본적으로 우리가 생각하는 OAuth 의 프로세스를 따르지 않기 때문에 반드시 인증된 client에만 사용되어야 하며 가능하면 사용하지 않는 것이 좋다.

다양한 토큰 지원(Access token)

OAuth 2.0은 기본적으로 Bearer 토큰, 즉 암호화하지 않은 그냥 토큰을 주고받는 것으로 인증을 한다. 기본적으로 HTTPS 를 사용하기 때문에 토큰을 안전하게 주고받는 것은 HTTPS의 암호화에 의존한다. 또한 복잡한 signature 등을 생성할 필요가 없기 때문에 curl이 API를 호출 할 때 간단하게 Header 에 아래와 같이 한 줄을 같이 보내므로서 API를 테스트해볼 수 있다.
Authorization: Bearer

또한 OAuth 2.0은 MAC 토큰과 SAML 형식의 토큰을 지원할 수 있지만 현재 MAC 토큰 스펙은 업데이트 되지 않아 기한 만료된 상태이고 SAML 토큰 형식도 아직은 활발하게 수정중이기 때문에 사용할 수 없는 상태이다. 정리하자면, OAuth 2.0은 다양한 토큰 타입을 지원한지만 실질적으로는 Bearer 토큰 타입만 지원한다.

Refresh token

클라이언트가 같은 access token을 오래 사용하면 결국은 해킹에 노출될 위험이 높아진다. 그래서 OAuth 2.0에서는 refresh token 이라는 개념을 도입했다. 즉, 인증 토큰(access token)의 만료기간을 가능한 짧게 하고 만료가 되면 refresh token으로 access token을 새로 갱신하는 방법이다. 이 방법은 개발자들 사이에서는 논란이 있는데, 토큰의 상태를 관리해야 해서 개발이 복잡해 질 뿐만 아니라 토큰이 만료되면 다시 로그인 하도록 하는 것이 보안 면에서도 안전하다는 의견이 있기 때문이다.

API 권한 제어 (scope)

OAuth 2.0은 써드파티 어플리케이션의 권한을 설정하기 위한 기능이다. scope의 이름이 스펙에 정의되어있지는 않으며 여러 개의 권한을 요청할 때에는 콤마등을 사용해서 로그인 시에 scope를 넘겨주게 된다.

http://example.com/oauth?….&scope=read_article,update_profile

OAuth 2.0은 위험한가?

Eran Hammer가 OAuth 2.0가 형편없다고하며 자신의 블로그에서 제시한 이유는 OAuth 2.0이 너무 복잡하고 안전하지 않다는 점이다. 그는 자신의 블로그에 이렇게 된 이유를 설명하고 있다. OAuth 2.0 스펙에 참가한 사람들은 주로 웹 커뮤니티 멤버들과 대형 기업멤버들로 되어있었다. 웹 관련 멤버들은 OAuth 1.0a와 비슷하되 단점을 개선한 버전을 만들기를 원하는데 반해, 기업 쪽 사람들은 OAuth 2.0을 자신의 솔루션을 위한 인증 framework으로 사용할 수 있도록 유도하며 OAuth 2.0을 너무 복잡하게 만들었고 또 거의 무한한 확장성을 가질 수 있게 하면서 거의 모든 것에 ‘OAuth 2.0 호환’ 딱지를 붙일 수 있게 되었다는 것이다. 그는 OAuth 2.0이 더 간결하고 제한된 스펙이 되기를 원했다. 실제 블로그에서는 “OAuth 1.5 정도의 내용을 가진 새로운 OAuth 2.1이 10page 정도의 짧은 문서로 새로 나왔으면 좋겠다” 라고 했다.

그가 블로그 글에서 지적한 OAuth 2.0의 문제점은 어떤 것들 일까?

1. OAuth 1.0a에서는 token 과 함께 token 비밀번호를 같이 받는데 2.0에서는 이 토큰 비밀번호가 없어져서 실제로 클라이언트를 구분하기가 힘들어 졌다.
2. OAuth 1.0a의 signature 기능을 없애서 SSL 기능에 의존함으로서 더 위험해졌다. 또한 이렇게 된 것은 기업 솔루션에 적용 되기위한 것이었다.
3. OAuth 2.0에서 토큰 유효기간을 설정 할 수 있고 또 만료가 되면 갱신 되어야 한다. 이 변화는 OAuth 1.0 개발자들이 토큰 상태까지 관리해야 한다는 점에서 매우 커다란 변화이다. 이 기능은 자체적으로 인코딩 되어서 저장되는 토큰을 위한 것인데 이런 토큰은 권한을 취소(revoke) 하는데에 문제가 있기 때문에 또 다시 유효기간을 짧게 가져가게 된다.
4. 권한 부여 방식
   OAuth 2.0에서는 너무 많은 방식을 지원 하고있다. 이는 여러 보안상의 문제점의 가능성을 의미한다.
   또한 OAuth 2.0을 IETF에서 시작한 것을 후회하는 말도 하면서, 그렇다고 딱히 다른 대안이 있는 것도 아니라는 의견도 밝힌다. 현재 워킹 그룹이 합의를 하지 못하고 있는 사항들에 리스트도 적었는데, 그만큼 OAuth 2.0스펙이 너무 포괄적이며 스펙은 더 많은 제한을 가지고 있고 많은 것이 결정되어있어야 한다는 이야기라고 그는 계속 주장 한다

위 글에 대한 반박 글은 참 많지만 그 중에 유명한 것은 아래 2개이다.

• In Defense of OAuth 2.0
• The OAuth 2 Sky is NOT Falling

위 글에서는 OAuth 2.0의 장점들과 실질적으로는 OAuth 2.0 워킹 그룹이 잘 해나가고 있다는 내용의 글들이다. Eran Hammer는자기 자신의 첫 번째 글이 커다란 반향을 일으키자, 내용을 어느 정도 개선한 두 번째 글을 쓰기도 했다. 이 글에서 몇몇 OAuth 2.0을 잘 받아들인 단체들을 언급하면서, Facebook이나 Google은 OAuth 2.0이 직접 내렸어야 하지만 내리지 못한 결정들을 직접 내리고 OAuth 2.0을 성공적으로 구현했다고 이야기 하고있다. 하지만 그는 자신의 신념에는 변화가 없다는 뜻을 다시 한번 비추었다. 즉 OAuth 2.0이 명확하게 정의하지 않을 부분을 잘 구현한다면 OAuth 2.0은 꽤 쓸만한 표준이나, Eran Hammer는 현재의 OAuth 2.0은 너무 많은 부분들을 허용하고 있고 복잡하기 때문에 안전하지 않다고 주장한 것이다.

정리하자면, 가장 많이 사용되는 Grant type인 Authorization Code 방식이나 Implicit 방식을 사용하고 access token으로서는 Bearer 토큰을 사용하며 HTTPS를 통해서 서비스하고 널리 사용되는 라이브러리들을 사용해서 구현한다면 OAuth 2.0은 안전하다고 할 수 있다. 다만 아직 표준 진행중인 토큰 방식을 사용하거나 자신만의 Extension을 정의해서 사용하는 경우도 OAuth 2.0이라고 부를 수는 있지만 아직은 안전하지 않다고 할 수 있다.

OAuth 2.0에 대한 예상질문

이상 OAuth 2.0에 대해서 알아보았다. 마지막으로 간단한 몇 가지 사항을 짚어보자

1. SSL을 사용하지 않는 bearer 토큰은 안전하지 않나?
안전하지 않다. MAC token을 사용할 수 있지만 OAuth 2.0에서는 실질적으로 관리되고 있지 않은 스펙이다. OAuth 2.0을 이용한 API 호출에는 반드시 HTTPS를 사용해야 한다.

2. API를 서비스하는데 HTTPS를 쓸 수 없는 상황이다. 어떻게 해야 하는가?
그런 경우라면 현 시점에서는 OAuth 1.0a 를 사용하는 것이 최선이다. 아직 OAuth 2.0 스펙은 자체 암호화를 지원하지 않는다.

3. OAuth 2.0의 대안이 있는가?
의미있는 대안은 현재 없다. Facebook, Google 등이 모두 API 인증방식으로OAuth 2.0을 채택했기 때문에 대세는 이미 OAuth 2.0이다.

4. API 사용자를 생성하는 좋은 방법은?
이 이슈는 API의 고전적인 이슈 중 하나이다. API인증을 하기위한 사용자를 생성하는 API는 어떻게 인증해야 하는가에 대한 이야기 이다. API를 사용해서 사용자를 생성한다면, CAPCHA 등의 방법을 사용할 수 없기 때문이다. 보통 다양한 조건체크, email 확인 등의 방법을 사용하기도 하지만, 가능하면 사용자 추가는 그냥 웹 브라우저상에서 직접 하도록 하는 것이 정답이다.

마무리 하며

암호 기술과 함께 인터넷상에서 인증 관련 기술들은 매우 빠르게 발전하고 있다. 최근에는 SHA-3 해쉬 알고리즘이 기나긴 선정과정을 걸쳐 최종 선정되는 커다란 뉴스가 있었고API인증에 있어서도 OAuth 2.0 뿐만 아니라 openid 진영의OpenID Connect 도 활발히 활동하고 있다. 많은 우여곡절 속에서 OAuth 2.0 spec은 최종안을 위해서 달려가고 있는데 예상보다 많은 시간이 걸리고 있고 또 잡음이 있다는 것은 그만큼 많은 사람들과 기업들에게 OAuth 2.0가 중요하고 많은 기대를 하고 있다는 것을 말해준다.

OAuth 2.0의 기본 스펙은 안전하다. 다만 스펙에 참여하고 있는 일부 기업들의 욕심으로 생긴 일부 추가적인 기능들과 방향성에 논란이 있는 상황이다. 이슈가 되는 Refresh 토큰이나 추가기능을 제공하는 extension, 그리고 아직 RFC 단계에 있지 않은 스펙 들 때문에 OAuth 2.0전체가 안전하지 않다고 할 수는 없다. HTTP 1.1스펙의 PATCH 나 HEAD 메소드는 거의 사용되지 않지만 그렇다고 HTTP 1.1 의 GET/POST 메소드 까지 버릴 수는 없지 않을까?

AES나 SHA-3 등과 같은 암호화 알고리즘이 NIST같은 미국 정부기관의 주도로 정해지는 것과 달리 OAuth 는 IETF의 열린 프로세스에 따라서 스펙이 결정되고 메일링 리스트를 통해서 주로 토론이 이루어진다. 이 글을 쓰면서 인터넷 실명제 위헌 판결에 따라서 개인 인증에 대한 중요성이 부각되고 있는 우리나라에서 인터넷에서의 주민번호 대체품으로서 한국 정부가 OAuth 프로바이더를 만드는 것은 어떨까 하는 상상도 해보았다. 더 많은 사람들이 OAuth 2.0등의 열린 인증방법에 관심을 가지고 더 많은 자료들이 API를 통해 공개되고, 또 안전하게 접근할 수 있는 날이 오기를 기대해 본다.

참고자료

• OAuth 2 – OAuth 2 공식 홈페이지
• IETF OAuth 2 spec
• OAuth 2.0 and the Road to Hell (2012.7.26)
  모든 사건의 시작이된 OAuth 2.0 editor Eran Hammer의 폭탄선언
• On Leaving OAuth (2012.7.30)
  윗 글의 후속 글
• In Defense of OAuth 2.0
• The OAuth 2 Sky is NOT Falling
• An Introduction to OAuth 2
  OSCON 2012 발표자료
• OAuth 2 Simplified
• IETF OAuth Word Group 메일링 리스트