'구글'에 해당되는 글 29건

  1. 2015.12.28 구글, 페이스북, 링크드인, 야후, 클라우데라, 아파치의 빅데이터 스택 비교
  2. 2015.08.31 실시간 커뮤니케이션... WebRTC 기술을 주목하라!
  3. 2014.08.25 BigData 처리를 위한 맵리듀스(MapReduce)에 대하여~
  4. 2014.08.15 Hive & Pig - 하둡(Hadoop)의 맵리듀스를 보다 편하게~
  5. 2014.03.13 구글, 퀵시 모바일 앱내 컨텐츠 검색은 어떻게 될까?
  6. 2013.07.23 0과 1로 세상을 바꾸는 구글 그 모든 이야기
  7. 2013.02.12 구글 독감 트렌드 분석 - Big Data, Big Insight
  8. 2012.12.24 빅데이터 경영을 바꾸다 - 빅데이터 시대의 새로운 기회를 찾아서
  9. 2012.11.25 알라딘 ttb2에 대한 구글 크롬 악성코드 진단~ (1)
  10. 2012.11.21 빅데이터의 확장 배경과 실제 사례들

구글, 페이스북, 링크드인, 야후, 클라우데라, 아파치의 빅데이터 스택 비교

|



아파치 진영을 중심으로 하둡 기반의 다양한 어플리케이션을 통해서 실시간 처리, 기계학습, 그래프 분석 등을 수행하고 있다. 

하둡의 기본 개념이 구글 시스템에서 시작된 만큼 먼저 구글의 분산 처리 구성을 살펴본다. 

그리고 아파치에서 제공하는 하둡 에코시스템의 구성을 알아본 후, 

클라우데라, 페이스북, 야후, 링크드인 등에서 이를 활용하는 구조를 정리해 본다. 


결국 회사의 용도에 맞춰서 기술들을 잘 조합해서 사용하는 것이 관건인 듯하다. 

물론 필요에 따라 클라우데라의 임팔라나 링크드인의 카프카와 같이 직접 만들수도 있지만 말이다. 


구글 빅데이터 스택

구글은 Chubby라는 'Coordination'을 사용하고, 데이터스토어로는 Big Table을 쓰고 있다. 

그리고 맵리듀스의 상위 언어로 Sawzall을 사용한다. 데이터 통합에는 MySQL Gateway를 이용한다. 


아파치 하둡 에코시스템

아파치에서 제공하는 하둡 에코시스템을 살펴보면 'Coordination'으로 주키퍼를 사용하고, 

데이터 스토어로 HBase를 추천하고 있다. 

맵리듀스의 상위 언어로 Pig와 Hive 같은 것을 추천하고 있고, 데이터 통합은 Sqoop, Flume을 이야기 한다. 


클라우데라, 페이스북, 링크드인, 야후의 하둡 시스템 구성 

마지막으로 각 회사별로 하둡 시스템을 어떻게 구성해서 사용하는지 살펴보도록 하자. 

먼저 하둡 배포판을 제공하는 클라우데라의 구성은 다음과 같다. 

아파치의 하둡 에코시스템과 유사하지만 웹 기반의 UI Framework인 Hue를 제공하고 있는 특징이 있다. 


페이스북은 데이터 통합에 있어 Sqoop이나 Flume 대신 Scibe를 사용하는 점이 다르다. 

대부분의 회사들이 데이터 특성이 있어서인지 데이터 통합 부분은 별도로 구축해서 사용하는 경우가 많은 듯 하다. 

그리고 상위 언어로 HiveQL을 활용하는 Hive를 주로 사용한다. 

 

링크드인은 데이터 통합에 Sqoop과 Kafka를 함께 사용한다. 

Kafka는 실시간 분산 메시징 시스템으로 링크드인에서 개발한 것이다. 

그리고 데이터 스토어로 Voldemort를 사용하고 Pig와 Hive를 모두 사용하고 있다. 


야후는 데이터 통합에 있어 Data Highway를 사용하고 있다. 


이상으로 구글부터 시작해서 각 회사별 하둡 에코시스템의 구성을 살펴봤다. 

Spark의 등장과 함께 하둡 시스템의 기본적인 구성은 이제 정리가 되어 가는 듯 하다. 

어떻게 잘 조합해서 자신의 플랫폼에 적합한 최적의 시스템으로 구성하느냐에 따라 활용도가 결정될 듯 하다. 


이제 빅데이터는 개념과 시스템 구성을 넘어서 진정한 분석을 통한 가치 창출로 넘어가는 단계인 듯 하다. 





Trackback 0 And Comment 0

실시간 커뮤니케이션... WebRTC 기술을 주목하라!

|



휴대폰 뿐만 아니라 TV, 컴퓨터가 상호간 실시간 대화를 한다고 상상해보자. 

영상 통화를 하면서 동시에 채팅과 P2P 데이터 공유까지 가능하다면... 

이것이 현재 떠오르고 있는 WebRTC 기술의 비전이다. 


WebRTC를 활용한 아자르

국내 업체 하이퍼커넥트가 만든 영상 채팅으로 전세계 친구를 찾는 앱 "아자르(Azar)"도 WebRTC 기술을 활용한다. 

아자르는 2013년 앱 론칭 후, 6개월만에 500만 다운로드, 11개월만에 1,000만 다운로드를 달성했다. (현재 2,000만 가입자 수...)

2011년 발표된 WebRTC 기술과 영상 채팅 서비스를 잘 결합한 성공 모델이라 할 수 있을 듯 하다. 


WebRTC란?

WebRTC는 웹을 위한 실시간 통신 규격을 의미한다. 

오디오나 비디오 스트림을 P2P로 주고 받는 것 뿐만 아니라 데이터 전달을 위한 매커니즘도 포함하고 있다. 

서버 중계 없이 클라이언트간 데이터를 빠르게 송수신하기 위해 WebRTC를 사용할 수 있다. 


구글이 2008년 지메일에 영상 채팅을 서비스하고, 2011년 행아웃을 발표하면서

실시간 통신 기술을 보유한 GIPS 회사를 인수하고, 관련 기술을 오픈소스화 했다. 

그리고 2011년 5월 에릭슨(Ericson)이 첫번째 WebRTC 데모를 개발하게 된다. 


2013년 구글 I/O에서 발표한 WebRTC 영상은 다음과 같다.  (http://io13webrtc.appspot.com/#1)


WebRTC의 주요 기능

WebRTC는 비디오, 오디오 데이터를 획득할 수 있고, 네트워크 정보를 파악해 WebRTC 클라이언트들과 정보 교환할 수 있다. 

세션 초기화, 종료 및 에러 처리와 같은 시그널 통신 관리도 가능하다. 

그리고 스트리밍 비디오, 오디오, 데이터의 송수신이 가능한 구조다. 


음성 통신을 위한 VoIP의 SIP와 RTP를 오디오 뿐만 아니라 비디오, 데이터까지 확장하면서 

플러그인 없이 웹 기반으로 확대한 개념 같기도 하다. 


기본적으로 제공하는 API는 다음과 같다. 

  • MediaStream - 카메라, 마이크 등 접근 
  • RTCPeerConnection - 비디오, 오디오 연결 및 대역폭 관리, 암호화 처리 
  • RTCDataChannel - 데이터 통신 채널 



SKT의 PlayRTC

국내에서는 SKT에서 webRTC 기반의 표준 서비스 플랫폼으로 PlayRTC라는 플랫폼과 API를 제공하고 있다. 

 


 2014년 T Developer에서 발표된 내용을 살펴보기 바란다. 


 




Trackback 0 And Comment 0

BigData 처리를 위한 맵리듀스(MapReduce)에 대하여~

|




맵리듀스 개요

맵리듀스(MapReduce)는 기존 하드웨어를 활용한 분산 프로그래밍 모델로서, 

대용량 데이터를 빠르고 안전하기 처리하기 위해 만들었다. 


2014년 OSDI 컨퍼런스에서 구글이 "MapReduce : Simplified Data Processing on Large Clusters" 논문을 발표한 이후, 

맵리듀스는 관심을 받기 시작했다. 


그리고 오픈소스 루씬(Lucene)의 개발자인 더그 커팅(Doug Cutting)이 하둡(Hadoop)을 만들면서 맵리듀스가 널리 알려졌다. 

하둡 오픈 소스 프로젝트는 구글의 분산 기술(GFS, MapReduce)을 기반으로 2006년부터 시작했다. 


하둡 파일 시스템(HDFS)는 대규모 분산 파일 시스템 구축의 성능과 안전정을 보여줬고, 

맵리듀스는 HDFS에 저장된 대규모 분산 파일에 대한 로그 분석, 색인 구축, 검색에 탁월한 능력을 발휘했다. 


이후, 아마존은 맵리듀스 플랫폼(Amazon Elastic MapReduce)을 클라우드 서비스로 제공하기 시작했고, 

몽고디비(MongoDB)와 같은 NoSQL에서도 MapReduce Operation을 제공했다. 


맵리듀스 - 발상의 전환

맵리듀스의 개념을 이해하기 위해, 먼저 기존 프로그래밍 방식을 생각해보자. 

첫째, 데이터를 가져온다. (Fetch Data)

둘째, 가져온 데이터를 처리한다. (Process Data)

셋째, 처리한 데이터를 저장한다. (Save Data)

기존 프로그래밍은 데이터를 가져와서 중앙에서 처리하고 다시 저장하는 구조다. 

하지만 대용량 데이터를 애써 분산 환경에 저장했는데, 처리를 위해 대용량 데이터를 다시 가져와야 한다니? 

즉, 데이터를 가져오는 비용이 많이 든다. 

그래서 데이터를 가져오지 않고 처리할 수 있는 '무엇'이 필요했다. 


이것이 바로 "맵리듀스"이다. 

발상 전환으로 데이터를 가져오지 않고, 데이터가 저장된 곳에서 처리할 수 있도록 만들었다. 

맵리듀스는 크게 맵(Map) 단계와 리듀스(Reduce) 단계로 나눈다. 

맵 단계가 바로 데이터가 저장된 로컬에서 동작한다. 


맵리듀스 이해 

맵 단계와 리듀스 단계 모두 입/출력으로 키-값(Key-Value) 쌍을 가진다. 

키와 값의 타입은 개발자가 선택하며, 맵 함수와 리듀스 함수도 개발자가 직접 작성해야 한다. 


맵리듀스의 단어수 계산(WordCount) 예제로 개념을 정리해 보자. 

"클라우드 컴퓨팅 용어의 정의는 무엇인가?"

"최근 클라우드 컴퓨팅이 화두가 되면서 애매모호한 용어로 인해"


위 두 문장의 단어를 세는 프로그램을 맵리듀스로 처리하면 다음과 같다. 



맵 함수의 입력은 다음과 같다 - 키: 줄번호(라인번호), 값: 문장(라인)

실제 키는 줄번호가 아니라, 파일 각 줄의 시작 오프셋(offset)이 된다. 


맵 함수에서는 각 문장을 공백으로 분류해 단어와 글자 수를 키-값 형태로 제공한다. 

그리고 정렬과 병합이 일어난다. 

여기까지가 분산 저장된 로컬 서버에서 일어나는 작업이다. 


리듀스 함수는 "단어-글자수 목록"을 입력으로 받아서, 각 단어들의 개수를 취합해 최종 결과를 제공한다. 


맵리듀스 구조

맵리듀스의 처리 과정을 한번 더 정리해 보자. 

대용량 입력 파일을 분리(Split)한 후, 맵 함수를 적용한다. 

그리고 리듀스 함수에 전달하기 위해 셔플링(Shuffling)이 일어나고 최종 결과를 생성한다. 


하둡에서 최초 입력 파일은 먼저 스플릿(Split)해서 HDFS에 저장한다. 

대용량 파일을 한번에 처리할 수 없기 때문에, 적절한 크기로 잘라낸 후 맵리듀스로 처리하는 것이다. 

하지만 스플릿의 크기가 너무 작을 경우, 분할 관리 및 맵 태스트 생성의 오버헤드가 있어 역효과가 날 수 있다. 

보통 하둡에서 64MB 이상의 스플릿을 사용하도록 권장하고 있다. 

클라우데라의 CDH에서는 기본값이 128MB로 설정되어 있다. 


셔플링(Shuffling)은 맵 함수의 결과를 취합하기 위해 리듀스 함수로 데이터를 전달하는 역할을 한다. 

그 전에 맵 함수의 결과에 대해 정렬과 병합(Sort & Merge)이 일어난다. 

그리고 각 서버에 나뉜 데이터들을 키를 중심으로 합쳐서 리듀스 함수에 전달한다. 

이렇게 리듀스 함수로 데이터를 전달하는 것을 셔플링(Shuffling)이라고 한다. 


이제 파티셔너(Partitioner)와  컴바이너(Combiner)에 대해서 살펴보자. 

파티셔너는 맵 함수의 결과를 각 파티션으로 나누어 저장하는 역할을 한다. 

파티션을 나누는 기준은 키이며, 기본적으로 키에 해쉬 함수를 적용해 처리한다. 

위 그림에서도 맵 결과를 버퍼에 저장하다가, 디스크에 저장할 때 파티션, 정렬 등의 작업이 일어나는 것을 알 수 있다. 


컴바이너는 일반적으로 리듀서와 동일하게 사용한다. 

그래서 컴바이너를 "로컬 리듀서"라고도 한다.

왜 컴바이너가 필요할까?

맵리듀스는 대용량 처리를 위해 만들었다. 

맵 함수까지는 로컬에서 실행하지만 리듀스 함수로 데이터를 전달하는 것은 네트워크를 이용할 수 밖에 없다. 

로컬에서 리듀스 함수를 먼저 처리한다면, 네트워크로 전달하는 데이터 양이 대폭 감소할 것이다. 


리듀스 함수를 컴바이너로 사용하기 위해서, 리듀스 함수의 입력과 출력의 타입이 같아야 한다. 

그렇지 않을 경우, 별도의 컴바이너를 구현해서 활용할 수 있다. 


컴바이너 적용에 따른 차이는 다음 그림을 살펴보도록 하자. 

컴바이너를 적용함으로써 리듀스 함수로 전달하는 데이터 양이 조금 줄어든 것을 볼 수 있다. 

"뭐 이정도 쯤이야?"하고 생각할 수 있지만, 실제 대용량을 처리할 때 그 차이는 무시할 수 없을 것이다. 


빅데이터를 다룬다면, 맵리듀스의 개념과 구조 정도 이해해야 한다. 

맵리듀스 대신 Hive와 같은 기술로 처리하더라도, 개발자라면 내부적으로 어떤 일이 일어나는지 알아야 하지 않을까?


-- 2012년 2월 29일 처음 작성한 글을 재구성했습니다. 





Trackback 0 And Comment 0

Hive & Pig - 하둡(Hadoop)의 맵리듀스를 보다 편하게~

|



하둡(Hadoop) 프로젝트를 진행할 때 사람들의 고민이 무엇일까? 하고 생각해 봤습니다. 

Java 언어에 익숙하더라도 첫번째로 만나는 문제는 역시 맵리듀스(MapReduce)가 아닐까 합니다. 


맵리듀스는 맵과 리듀스가 합쳐진 것으로 각각의 Map 함수와 Reduce 함수를 구현하고 JobClient를 통해 호출해야 합니다. 

그런데 일반적으로 하둡 프로젝트에서 한번만 맵리듀스를 사용하는 경우는 거의 없습니다. 

대부분 맵 리듀스를 반복적으로 사용하게 됩니다. 


여기에 맵리듀스에서 기본적으로 사용하는 타입인 Text, IntWritable, LongWritable과 같은 것 이외에 객체를 사용한다든지. 

Key 항목이 아닌 Value에 속하는 항목으로 정렬을 하고 싶다든지, 

하는 경우에 많은 개발자들이 어려움을 느끼고 있습니다. 


물론 위와 같은 문제들에 대한 해결책은 맵리듀스에 존재합니다. 

그러나 마치 어셈블리어로 모두다 가능하지만 고급언어로 씌워서 개발자가 좀 더 편하게 개발할 수 있는 환경을 만드는 것처럼 

하둡에서도 맵리듀스로 변환해 줄 수 있는 스크립트 언어들이 존재합니다. 


제가 굳이 고급 언어라고 하지 않고 스크립트 언어라고 하는 이유는 

개인적으로는 아직까지 맵리듀스가 더 나을 수 있다고 보기 때문입니다. 

물론 시간이 흘러 스크립트 언어들의 성능 개선이 이루어지겠지만 맵리듀스로 변환해야 하는 오버헤드는 존재하겠죠.. 


Google Sawzall

이런 스크립트 언어를 맨 처음 만든 것은 역시 Google 이었습니다. 

구글은 GFS와 맵리듀스에서 사용할 수 있는 절차형 프로그래밍 언어를 개발했고 Sawzall 이라는 이름으로 사용하고 있다고 합니다. 


이런 Sawzall을 모델로 Hadoop과 관련한 프로젝트들이 만들어집니다. 

바로 Hive와 Pig 입니다. 



Hive

먼저 Hive부터 살펴보도록 하죠. 

Hive는 HiveQL이라고 하는 SQL과 유사한 쿼리를 사용합니다. 

HiveQL로 정의한 내용을 Hive가 MapReduce Job으로 변환해서 실행한다고 합니다. 


정확하게 설명하면, MapReduce 작업이 필요할 때 Hive는 Java MapReduce 프로그램을 생성하는 것은 아니라고 합니다. 

인터프리터 언어처럼 내장된 Generic Mapper와 Reducer 모듈을 사용하고, 

여기에 Job Plan이라는 XML 파일을 적용해 MapReduce Job을 생성한다고 하네요. 

이렇게 MapReduce Job을 생성하면서 비로소 Job Tracker와 통신하기 시작한다고 합니다. 


Facebook 주도로 개발했고 국내에서도 Hive를 위주로 사용하는 곳도 있습니다. 


예를 한번 살펴보도록 하죠. 

Q) K1 메타 저장소에서 Key 값이 100보다 큰 것을 Key와 count로 출력

hive> select key, count(1) from kv1 where key > 100 group by key


위와 같은 형태로 구현이 가능하다고 합니다. 

실제 SQL 쿼리를 사용하는 것과 같은 느낌이 듭니다. 


이번에는 Hadoop의 기본 예제로 사용하는 WordCount를 Hive로 구성해 보도록 하겠습니다. 

WordCount에 대한 MapReduce 설명은 http://blog.acronym.co.kr/333#wordcount 을 참고하시기 바랍니다. 

CREATE TABLE docs (line STRING);
LOAD DATA INPATH 'docs' OVERWRITE INTO TABLE docs;

CREATE TABLE word_counts AS
SELECT word, count(1) AS count
FROM
   (SELECT explode(split(line,'\s')) AS word FROM docs) w
GROUP BY word
ORDER BY word;



구성도를 살펴보면 Hive에 Metastore가 존재합니다. 

이 부분에 DB 스키마와 같이 저장하는 것 같고 실제 데이터는 하둡의 HDFS에 분산되어 저장되는 구조인 듯 합니다. 

Metastore는 별도의 Relation Database로서 일반적으로 MySQL 인스턴스를 사용한다고 합니다. 

즉, Hive는 주로 MySQL을 사용하여 테이블 스키마와 시스템 메타데이터를 유지하고 있다고 보면 됩니다. 


JDBC, ODBC 드라이버가 존재하는 것으로 봐서 기존 DB와도 연동해서 사용할 수 있는 것 같네요. 

뿐만 아니라, CLI (Command Line Interface), HWI (Hive Web Interface), 그리고 Thrift 서버 프로그래밍을 제공합니다. 


최근에는 다양한 GUI 툴도 제공하고 있는데요. 

Karmasphere(http://karmasphere.com), Cloudera의 Hue (https://github.com/cloudera/hue), 

그리고 Hive-as-a-service를 제공하는 Qubole(http://qubole.com)를 Hive GUI로 활용할 수 있습니다.


Pig

Pig와 관련해서는 http://blog.acronym.co.kr/372 에서 간단하게 정리하기는 했는데요. 

MapReduce의 비직관적이고 반복되는 코딩을 줄이기 위해 간결한 문법으로 새로 만든 스크립트 언어입니다. 

정확하게 설명하면, Pig는 Query Language가 아닌 Data Flow를 처리하는 Laguage라 할 수 있습니다. 


사용자 정의 함수로 확장이 가능하지만 컴파일 과정이 필요하므로 MapReduce에 비해 성능이 떨어진다고 하네요. 

야후(Yahoo)에서는 하둡 작업의 30%를 Pig를 사용하고 있고, 트위터도 사용한다고 들었던 것 같습니다. 

또한 Pig는 외부 데이터를 하둡 클러스터로 가져오고 적절한 형식으로 변환하기 위한 ETL(Extract, Transform, and Load) 프로세스의 일부로도 종종 사용된다고 합니다. 


Pig에 대한 예제를 Hadoop 완벽 가이드에 나오는 내용을 기반으로 살펴보죠. 


Q) 날씨 데이터에서 연중 가장 높은 기온을 계산하는 프로그램

1: grunt> records = LOAD ‘input/sample.txt’
2: >> AS(year: chararray, temperature:int, quality:int);
3: grunt> filtered_records = FILTER records BY temperature != 9999
4: >> AND quality == 1
5:
6: grunt> grouped_records = Group filtered_records BY year;
7: grunt> max_temp = FOREACH grouped_records GENERATE group,
8: >> MAX(filtered_records.temperature);
9:
10: grunt> DUMP max_temp;
11: (1949, 111)
12: (1950, 22)


1~2번째 줄을 보면 HDFS에서 input/ 폴더의 sample.txt를 가져와서 year, temperature, quality를 중심으로 분류합니다. 

그리고 3~4번째 줄에 temperature와 quality가 적절한 값들만 필터링해서 filtered_records에 저장합니다. 

6번째 줄에서 연도별을 기준으로 그룹화해서 grouped_records에 저장합니다. 

그리고 7~8번째 줄에서 각 그룹별로 최고 기온을 체크해서 max_temp에 저장하고 

마지막에 max_temp를 출력하면 결과가 위와 같이 나옵니다. 


실제 관련 책을 보면 위 내용을 맵리듀스로 작성하는 내용이 나옵니다. 

비교해보면 정말 간단하기는 합니다. 


In Pig, you write a series of declarative statements that define relations from other relations, 

where each new relation performs some new data transformation.

Pig looks at these declarations and then builds up a sequence of MapReduce jobs 

to perform the transformations until the final results are computed the way that you want.


마치면서

이상으로 Hive와 Pig에 대해서 간략하게 정리해 봤습니다. 

분명 Hive나 Pig는 발전하고 있고 프로그래밍하기에 보다 편리한 것이 사실입니다. 

하지만 개인적으로는 반드시 하둡을 사용하려면 MapReduce로 한번쯤 직접 해 보시기를 권장하고 싶습니다. 


MapReduce의 처리 흐름을 이해하고 난 뒤 Hive나 Pig를 사용해도 늦지 않을 것이라는 생각이거든요. 

어차피 내부적으로 MapReduce로 변환해 실행한다면 MapReduce를 이해하고 있어야 나중에 응용도 보다 자유롭게 하지 않을까 합니다. 


-- 2012년 11월 2일 작성한 글을 최신 내용으로 업데이트 했습니다. 






Trackback 0 And Comment 0

구글, 퀵시 모바일 앱내 컨텐츠 검색은 어떻게 될까?

|



웹과 인터넷 환경에서 검색은 가장 중요한 플랫폼이었다. 

실제로 한 시대를 풍미했던 최고의 인터넷 기업들은 모두 훌륭한 검색 엔진을 보유하고 있었다. 


알타비스타, 야후, 그리고 구글까지 당시 최고의 기술로 검색 서비스를 제공했다. 

국내에서도 한미르, 엠파스, 심마니, 네이트, 다음, 네이버 등이 있었다. 



하지만 최근 모바일 환경의 트래픽이 점차 늘어남에 따라 

웹 검색 뿐만 아니라 모바일 검색에 대한 관심도 높아지고 있다. 


물론 모바일 웹은 기존의 웹 검색엔진을 그대로 활용할 수 있지만 

문제는 바로 모바일 앱(어플리케이션)이다. 


모바일 앱 내부의 자체 검색은 할 수 있지만 

여러 모바일 앱 컨텐츠를 외부의 검색으로 활용하기 어렵다는 문제를 가지고 있다.  


실제로 모바일 앱 검색 서비스를 제공하던 퀵시(Quixey)는 모바일 앱 내 컨텐츠까지 통합 검색할 수 있는 서비스를 제공할 계획이라고 한다. 



http://besuccess.com/2014/02/betech_20140226/ 기사에 따르면, 

퀵시를 통해 ‘주변에 가장 가까이 있는 택시’를 검색하면 

우버(Uber), 리프트(Lyft), 사이드카(SideCar) 등을 모두 검색하여 가장 가까이 있는 택시를 알려준다. 

만약 ‘주변 태국 레스토랑’을 검색하면 옐프(Yelp), 심리스(Seamless), 그럽헙(GrubHub) 등 여러 앱의 정보를 통합하여 검색 결과를 알려준다.


현재 웹 검색의 최강자인 구글도 앱 내 컨텐츠 검색을 준비하고 있다. 

구글은 안드로이드 4.1 이상의 Google Search App 2.8 버전부터 다음과 같은 앱 내 컨텐츠 검색을 제공했다. 

앱 개발자는 이를 위해 구글의 App Indexing for Google Search를 적용해야 한다.



하지만 이제 구글도 퀵시와 같이 일반 검색에서도 앱 내 컨텐츠를 검색할 수 있도록 준비하고 있다고 한다. 

사용자들의 검색 트래픽이 점차 모바일로 이동해 가면서 

웹 기반이었던 애드센스와 같은 구글의 주요 수익원을 모바일로도 확장하기 위한 것이다. 


만약 구글에서 앱 내 검색이 되고, 해당 앱이 없는 사용자에게 앱 설치를 안내한다면 

어느 개발자가 구글의 앱 인덱싱 API를 적용하지 않을까?

이런 점이 구글의 장점이 아닐까 한다. 


하지만 구글도 기존 검색 시장을 장악하고 있던 야후를 새로운 기술력으로 넘어섰듯이..

모바일 검색에서 새로운 업체가 나타나 구글을 넘어설 날이 올수도 있을 것이다.






Trackback 0 And Comment 0

0과 1로 세상을 바꾸는 구글 그 모든 이야기

|




미니서평

저자인 스티븐 레비는 10년여동안 구글에 대한 글을 써왔다고 합니다.

그래서인지 이제까지 봤던 구글과 관련된 다른 책보다는 구글 내부의 이야기를 자세히 서술하고 있습니다.  


인터넷이라는 거인의 어깨 위에 올라 앉아 세상을 더 좋게, 좀더 평등하고 더 힘을 주는 곳으로 만들기 위해 고민한다. 


인터넷 거인 구글

구글은 페이지랭크로 유명해진 검색엔진부터 시작해서, 

현재는 모바일 OS인 안드로이드와 동영상 서비스인 유투브까지 확장하면서 

진정 인터넷이라는 거인의 어깨 위에 올라온 느낌입니다. 


지메일, 구글 클라우드, 구글 앱 엔진, 구글 플러스, 구글 글래스, 구글 도서, 구글 TV, 구글 자동차.... 

이와 같이 이미 성공한 서비스도 있고, 앞으로의 서비스들을 계속해서 연구/개발하고 발전시켜 나가고 있지요.

특히 기존의 IT 기업들과 차별화된 구글만의 문화를 통해서 이런 성과를 이루어냈다는 점은 대단하다고 생각합니다. 


인재와 기술

구글이 초기에 "마이크로소프트"라는 골리앗에 맞선 다윗의 이미지를 통해서 자리를 잡았던 점도 있을 것입니다. 

하지만 세계 최고의 인재와 우수한 기술에 대한 부분이 있었기에 현재의 위치까지 올라왔겠지요. 


사악해지지 말자

책에도 나오지만 구글 문화의 기반이 된 것은 바로 "사악해지지 말자"는 것이라고 합니다. 

중국에 대한 도덕적 딜레마를 다루는 부분에서는 구글의 사악해지지 않기 위한 노력을 엿볼 수 있었습니다. 

하지만 최근 스노우든의 프리즘 폭로 사건에서 나오는 것처럼, 

미국 정부에 대해서는 개인정보를 제공했다는 논쟁에 휩싸이면서 이슈가 되기는 했습니다. 


데이터의 가치

개인적으로 마켓 분석을 위해 애플 앱스토어와 구글 플레이의 데이터를 살펴보니 

애플은 기술에 대해서는 오픈하지 않지만, 앱스토어 데이터는 RSS형태로 제공해주고 있었습니다. 

반면에 구글은 안드로이드 기술은 오픈되어 있지만, 구글 플레이의 데이터는 별도로 제공하지 않고 있었습니다. 

아마도 구글은 데이터의 가치를 보다 중요하게 여기기 때문이 아닐까 하는 생각을 잠시 해봤습니다. 



밑줄긋기

---

인도 방갈로르에서 앞으로 출시될 제품에 대한 프리젠테이션이 끝나자, 

현지 엔지니어 중 한 명이 메이어에게 흥미로운 질문을 던졌다. 


"제품에 대한 로드맵이 있다고 들었는데, 회사 수익에 대한 로드맵도 있습니까?"


메이어는 머리를 절레절레 흔들었다. 

"그런 생각을 해 본 적은 없습니다. 

우리는 오로지 '사용자'에게 초점을 맞춥니다. 

우리 서비스를 사용하는 사용자가 행복해지면, 수입은 뒤따라 올테죠."


---

페이지는 구글을 최초로 방문한 기자에게 이런 말을 했다. 

"내년에 월등히 좋아지지 못하면 우리는 잊히고 말 것입니다."


페이지와 브린은 둘 다 세계 최고 수준의 엔지니어와 과학자에게 구글의 성공이 달려 있다고 뼛속 깊이 믿었다. 

페이지는 기술기업이란 '엔지니어링에 대한 최고 수준의 이해도'가 있어야 살아남을 수 있다고 봤다. 


---

래리의 답변은 놀랍고도 인상적이었다. 

다른 관점에서 사물을 바라보면 예기치 못한 해결책이 나올 수 있으며, 

작업에만 빠져 있을 때는 대개 나무만 보게 되지만 숲을 볼 필요도 있다고 말했다. 


--- 

구글은 고용을 매우 신중하게 한다. 

페이지와 브린이 최고 수준의 재능과 역량을 가진 인재 덕분에 구글이 성공했다고 여기기 때문이다. 

페이지는 신입직원들에게 출장을 가는 비행기 안에서도 매력적인 논의로 남을 끌어들일 능력이 있어야 한다고 말했다. 

페이지는 구글이 지능이 높은 인재들이 일하고 싶어하는 곳으로 만들겠다는 자신의 아이디어를 구체화했다. 


--- 

페이지와 브린 둘 다 구글이 인터넷 자체와 같이, 빠르게 상향식으로 돌아가야 한다고 생각했다. 

매일같이 변화하여 어제 일도 옛날 일처럼 보여야 한다고 생각했다. 

메간 스미스는 이렇게 해석한다. 

"인터넷 시대에 태어났지 않아요. 그러니 우리 회사도 우리 제품처럼 돌아가야 한다는 의미입니다. 좀 묘하지만요."


--- 

브린과 페이지는 해결책을 제시했다. 관리자를 없애는 것이었다. 

적어도 엔지니어링 부문에는 관리자가 없어야 했다. 

브린과 페이지 생각에 엔지니어는 스스로를 조직화할 수 있어야 했다. 

구글 초창기에는 그런 방식이 실제로 잘 작동했다. 

뭔가 고쳐야 할 일이 있으면 스스로 무엇이 문제인지 알아내 고치면 끝날일이었다. 


---

구글 사업방식은 비용제약적입니다. 처음에는 특히 그랬죠. 

매번 검색 질의를 서비스할 때마다 비용이 들어갑니다. 

광고로 버는 돈은 나중 얘기 였기 때문에 페이지와 브린, 홀즐은 만들 수 있는 인프라 중에 가장 저렴한 인프라를 구축했어요.


---

"개개인의 의견을 반영하다보면 복잡해지지요. 

하지만 구글 제품은 기계 위주입니다. 

기계가 만들어요. 그래야 강력하지요. 그래서 우리 제품이 위대한 겁니다."

다른 말로 해서 구글은 인간의 왜곡이 없는 제품을 원한다는 의미였다. 


---

"우리의 모든 원칙을 깨뜨린다 할 수 있었지만요. 

한 번은 원칙이 정말 올바른지 테스트를 해야 할 때가 있어요. 

융통성이 아예 없으면 안 되죠. 그게 몬테소리에서 배운 걸 겁니다."






Trackback 0 And Comment 0

구글 독감 트렌드 분석 - Big Data, Big Insight

|



빅데이터의 사례로 가장 많이 이야기하는 것이 바로 "Google 독감 트렌드"입니다. 

구글에 집계된 검색어를 기반으로 세계 여러 국가의 독감 유행 수준에 대한 예상 수치를 제공하는 것인데요. 

이를 기반으로 빅데이터에 대한 전략이 어떻게 만들어졌는지 한번 생각해 보기로 했습니다. 


데이터 수집

구글 검색어가 자동으로 구글의 서버에 쌓이게 되므로 데이터의 축적은 기본적으로 이루어졌을 것입니다. 

또한 검색어는 시간에 따른 분포를 나타낸다는 점과 IP를 통한 위치를 파악할 수 있다는 것을 활용한 것이라 볼 수 있습니다. 

즉, 검색어, 시간대, 그리고 위치 정보를 활용해서 독감 트렌드를 분석해 낸 것이죠. 


먼저 독감(ILI - influenza likeness illness)과 관련된 키워드(ILI-related query)들을 정리해서 추출했을 겁니다. 

예전에 뉴스 자동분류 시스템을 개발할 때, 키워드와 시소러스를 정리해서 정확도를 높인 적이 있었는데요. 

여러가지 뜻을 가진 단어들이 많아서 고생했던 기억이 있습니다. 

그라나 독감과 같은 전문적인 단어는 상대적으로 관련 키워드를 추출하기가 용이했을 듯 하지만 여기에도 많은 검증이 있었겠죠. 


데이터 분석

데이터를 분석하기 위해서는 수집된 데이터의 지표들을 기반으로 상관관계를 만들어낼 필요가 있었을 겁니다. 

즉, 해당 지역에서 "실제 병원을 방문한 환자의 수"와 "구글에서 독감 관련 키워드를 검색한 사용자의 수"의 관계가 되겠죠. 


이것은 구글에서 2009년 네이처(Nature)에 발표한 논문을 보면 잘 나와 있습니다. 



"Detecting influenza epidemics using search engine query data"란 제목으로 발표되었는데요. 

(위 제목을 클릭하면 PDF 파일을 받아 볼 수 있습니다.)

여기에 나와 있는 수식을 보면 다음과 같습니다. 



수식을 보면 "실제 병원을 방문한 환자의 수"와 "독감 관련 키워드를 검색한 수"의 관계가 로그를 취했을 때 선형 관계라는 것을 알 수 있습니다. 

절편(intercept), 계수(multiplicative coefficient) 등을 통해 보정값을 설정하고, 자연로그를 사용해서 비선형인 회귀식을 선형 방정식으로 만든것 같네요. 

일반적으로 비선형 방정식은 추정이 어려운 것으로 알고 있습니다. 그래서 선형 방정식으로 바꾸어야 하는데요. 

원래는 다음과 같은 수식이 만들어졌을 것입니다. 



여기에 자연로그를 취해서 선형 방정식으로 만들면 다음과 같이 되겠죠. 



이 함수는 2003년부터 2008년까지 쌓인 데이터를 Training Set으로 해서 기계학습(Machine Learning)을 통해 만들어졌을 것입니다.

실제로 MapReduce를 사용해서 분산 환경에서 쿼리 추출부터 함수 생성까지 수많은 모델을 테스트해서 만들어낸 것이라고 하네요. 

그리고 훈련된 결과를 검증하기 위해서 테스트에 포함되지 않은 유타지방의 42주 데이터와 논문 발표 전 최신 데이터를 사용했다고 하네요. 

어쨋든 데이터가 워낙 방대하게 모아져 있을테니 그만큼 정확도도 높게 나왔을 것 같네요. 


시각화

구글은 검색어를 기반으로 독감을 예측하는 시스템을 구축함으로써 Big Data에서 Big Insight를 찾아냈습니다. 

그리고 마지막으로 이를 2008년부터 google.org를 통해 Google 독감 트렌드라고 시각화(Visualization)해서 보여줍니다. 



지역별로 매우높음, 높음, 보통, 낮음, 매우낮음의 5단계로 정보를 한눈에 보여주고 있습니다. 

역시 시각화의 핵심은 아무리 어렵게 분석했더라도 사용자는 직관적이고 쉽게 알 수 있도록 보여주는 것인 듯 하네요. 


구글 분석 결과를 실제 각국의 보건 당국이 발표한 자료와 비교해 보면 매우 유사하게 나옵니다. 

이를 확인해 주기 위해서 각국의 실제 자료와 비교해서 다음과 같이 보여줍니다. 



마치면서

이상으로 빅데이터하면 가장 많이 이야기하는 구글의 독감 트렌드를 기반으로 실제 빅데이터 구축이 어떻게 되는지 간단히 정리해 봤습니다. 

이런 사례를 살펴보면서 느끼는 점이 많습니다. 

실제 프로젝트를 진행해 보니, 빅데이터에서 내가 원하는 인사이트에 적합한 함수를 만들어내는 것도 상당한 노력을 필요로 하더라구요. 

또한 이를 여러 설명이 필요없도록 단순하면서도 명확하게 시각화 하는 것도 많은 생각을 하게 합니다. 





Trackback 0 And Comment 0

빅데이터 경영을 바꾸다 - 빅데이터 시대의 새로운 기회를 찾아서

|



빅데이터, 경영을 바꾸다 - 6점
함유근.채승병 지음/삼성경제연구소


데이터를 얻는 능력, 즉 데이터를 이해하는 능력, 처리하는 능력, 가치를 뽑아내는 능력, 시각화하는 능력, 전달하는 능력이야말로 앞으로 10년간 엄청나게 중요한 능력이 될 것이다. - 할 배리언, 구글 수석 경제학자


과거를 돌이켜 보면 세상을 바꾸는 기술들이 분명히 있었습니다. 

80년대 후반 처음 봤던 개인용 컴퓨터, 90년대 중반부터 사용하기 시작한 인터넷, 2000대 후반의 스마트폰 등..

그러나 업계의 모든 기대를 받았지만 떠오르지 못하고 사라진 기술들도 많습니다. 


하지만 잘 안되던 기술들이 다른 이름으로 융합되고 새롭게 나타나서 다시 성공하기도 하는 것 같습니다. 

스마트폰도 2000년대 초반 PDA등의 실패가 지금 성공의 기초가 되었다고 하고

웹 2.0도 마케팅 용어에 불과하다는 평가도 받았지만 추후 소셜 네트워크와 같은 새로운 서비스들의 성공으로 나타나기도 했구요. 


빅데이터도 이런 관점에서 바라볼 필요가 있다고 생각합니다. 

과거에 OLAP, 데이터웨어하우스, 데이터 마이닝 등 어떻게 생각해보면 우리는 이미 빅데이터란 것을 경험했었다고 볼 수 있습니다. 

즉, 빅데이터가 과거의 기술들을 기반으로 만들어진 것이라고 본다면 빅데이터는 기술의 문제가 아니라는 것입니다. 

물론 Hadoop이나 NoSQL과 같은 기술요소들은 존재하지만 어떻게 빅데이터를 활용하느냐에 문제가 더 중요하다는 것이죠. 


그런 측면에서 보면 함유근님과 채승병님이 쓴 이 책은 빅데이터를 경영에 적용하는 활용 사례를 중심으로 잘 설명하고 있습니다. 


1부 빅데이터에 주목하는 이유와 배경


먼저 제가 빅데이터의 확장 배경에 대해서 정리한대로 빅데이터의 3가지 요소인 규모(volume), 속도(velocity), 다양성(variety)에 대해서 이야기 하고 있습니다. 

그리고 빅데이터를 좁은 의미와 넓은 의미로 나누어 다음과 같이 정의합니다. 


빅데이터란 보통 수십에서 수천 테라바이트 정도의 거대한 크기를 갖고, 여러 가지 비정형 데이터를 포함하고 있으며, 생성-유통-소비가 몇 초에서 몇 시간 단위로 일어나 기존의 방식으로는 관리가 매우 어려운 데이터 집합을 의미한다. 


빅데이터란 기존의 방식으로는 관리와 분석이 매우 어려운 데이터 집합, 그리고 이를 관리, 분석하기 위해 필요한 인력과 조직 및 관련 기술까지 포괄하는 용어이다. 


마지막으로 빅데이터의 활용 배경으로 기술환경의 변화기업 경쟁 환경의 격화에 대해 이야기 하고 있습니다.

기술 환경의 변화와 관련해서는 다음 사항들을 다루고 있네요. 

  • 저장 매체의 발달과 저장 비용의 하락
  • 사람과 사람, 기계와 기계간 연결 증가
  • 급격히 진보하고 있는 데이터 관리 및 분석 기술 


2부 빅데이터는 어떻게 경영을 바꾸는가?


2부는 이 책의 핵심 내용이라 할 수 있는 빅데이터가 경영을 어떻게 바꾸는지 설명하고 있습니다. 

첫째로 센서 기술과 가치 사슬의 재설계로 새로운 차원의 생산성 향상이 가능하다는 것입니다. 

동시에 생산성 향상으로 고용 감소와 같이 발생할 수 있는 점들을 지적하면서 빅데이터는 단순히 경영이나 기술적 이슈만이 아닌 사회적 정치적 관점에서 폭넓은 접근이 필요하다고 이야기 합니다. 


두번째로 발견에 의한 문제해결에 대해서 이야기 합니다. 

구글 애널리틱스(Google Analytics), 구글 트렌드(Google Trends), 구글 상관관계(Google Correlate)를 이야기 하면서 구글 검색 뒤에 숨겨진 세상의 변화 추이나 관심사들 간의 관계를 무료로 발견할 수 있다고 이야기 합니다 .


기존의 검색과 같은 방법은 무엇에 대한 답을 찾을지 미리 알고 (문제가 무엇인지 미리 알고, 즉 키워드) 시작하는 것이었지만, 

빅데이터는 창의적인 반복적 탐구 과정을 통해 무엇을 질문해야 하는지 (무엇이 문제가 되어야 하는지, 즉 검색할 키워드) 찾아내는 과정이다. 



빅데이터를 통한 발견과 관련된 "예측", "시각화", 그리고 "맞춤화"에 대해서 이야기 합니다. 

저도 실제 빅데이터를 이용하는 서비스를 구성하면서 반드시 다음과 같이 진행해야 한다고 생각하고는 있습니다. 

시각화를 통한 통계 -> 분석을 통한 리포트 -> 예측

특히 예측과 관련해서 고민을 많이 하고 있었는데요. 이 책에서는 예측을 위해서는 모델(model)이 있어야 한다고 하네요. 


'기업의 매출은 광고비에 비례한다'라고 하면 'Y(매출) = aX1(광고비) + b'라는 모델이 성립하고, 

이 모델이 적절하다면 기업은 앞으로 얼마의 광고비를 투입하면 매출이 어느 정도 될지 예측할 수 있다는 것이죠. 

그런데 빅데이터를 통한 예측을 하게 되면 다양한 변수들를 찾아서 예측력을 높일 수 있다고 합니다. 

'Y(매출) = aX1(광고비) + bX2(회사 웹사이트의 상품 홍보 클릭 수) + cX3(SNS에서 자사 제품 등장 수) + d(상수)'와 같이 모델을 확장할 수 있다는 것이죠. 

위 예제는 간단한 선형회귀식이지만 이론적으로는 다른 복잡한 형태의 예측 모형 구축도 가능해지면서 예측력을 한층 높일 수 있다고 하네요. 


세번째로 의사결정의 과학화와 자동화에 대해서 이야기 합니다. 

시장조사기관인 포레스터 리서치에 따르면 과거 20년에서 25년 동안 기업들이 활용 가능한 정보의 5%만으로 의사 결정을 해왔다고 합니다. 

즉 데이터보다 직관에 의존한 의사결정을 많이 해왔다는 것인데요. 이럴 때 발생할 수 있는 오류나 편견에 대해서도 많은 연구 결과들이 있습니다. 


빅데이터를 의사결정에 활용하는 4단계를 저자는 다음과 같이 이야기하고 있습니다. 

1단계: What happened? (회사의 영업 이익이 얼마나 되는지 답하는 수준)

2단계: Where exactly is the problem? (사용자 관점에서 지난주 어떤 영업점의 매출이 높았고 어떤 제품이 잘 팔렸는지 답을 주는 단계)

3단계: What is happening next? (다음달에 어떤 제품이 가장 잘 팔릴지 예측하고 어떤 고객을 대상으로 판촉해야 하는지 예측하는 단계)

4단계: What's the best that can happen? (핵심 의사 결정까지 컴퓨터에 의해 제안되어 더욱 신속하고 정확한 판단과 행도이 가능해지는 단계)


여기에서도 3단계에 예측이 나오는데요. 

구글의 수석 경제학자 할 배리언은 예측은 남들이 예상치 못하는 점을 잡아낼 수 있어야 한다며 다음과 같이 이야기 했다고 합니다. 


돈을 벌기 위해서는 '어떤 일이 벌어질 것인가'와 '사람들이 생각하는 일이 일어날 것인가' 이 두 가지를 예측할 수 있어야 한다. 

돈을 버는 경우는 두 예상치의 차이를 알 수 있을 때이다. 


즉, 다들 예상치 못하는 바를 예측하는 것이 더 정확히 예측하는 것보다 훨씬 값어치가 있다는 것이죠. 


네번째로 새로운 고객 가치와 비즈니스의 창출에 대해서 이야기 합니다. 


빅데이터를 활용한 새로운 비즈니스 중 다양한 혁신으로 신산업을 개척하고 있는 '맥락/상황 인식 비즈니스'와 이를 스마트폰 내에서 구현하는 '스마트 모빌리티 비즈니스', 그리고 '자원 이용 최적화 비즈니스'에 대해서 다루고 있습니다 


참고로 IBM의 2011년 스마트 커머스 보고서에 따르면, 네가지 분야에서 스마트 비즈니스가 진전되고 있다고 합니다. 

물건을 구매하거나(Buy) 거래하는(Market) 부분, 물건을 판매하거나(Sell) 서비스하는(Service) 부분에서 컴퓨터가 사람의 수고를 덜어주면서 스스로 판단해 좀 더 효율적이고 효과적으로 작업을 수행한다는 것이죠. 


3부 빅데이터 시대를 위한 제언


여기에서는 한국 현실에 맞추어 빅데이터 시대를 위한 문제 점검과 해결 방향에 대해서 이야기 합니다. 

특히 관심이 갔던 부분은 빅데이터가 얼마나 지속될 것인가? 하는 것이었습니다. 

실제로 IT 업계의 각종 기술들이 유행과 실망이 반복되는 패턴을 보여왔고 가트너에서도 Hype Curve라는 과장광고 곡선이라는 것도 있다고 하네요. 


1단계(기술 도입기): 기술이 주목받는 계기 (Technology Trigger)

2단계(기대 절정기): 부풀려진 기대의 절정 (Peak of Inflated Expectations)

3단계(실망/침체기): 환멸의 바닥 (Trough of Disillusionment)

4단계(재조명/부상기): 이해의 상승 (Slope of Enlightenment)

5단계(생산성 안정기): 생산성의 안정 (Plateau of Productivity)


과연 빅데이터는 3단계에서 사라질까요? 아니면 5단계까지 성장할 수 있을까요? 





Trackback 0 And Comment 0

알라딘 ttb2에 대한 구글 크롬 악성코드 진단~

|



오늘 블로그를 들어가고 깜짝 놀랐네요. 

보통 크롬을 웹 브라우저로 자주 사용하고 있는데.. 빨간색 바탕에 다음과 같은 화면이 나오더군요.. ㅠㅠ


무슨 문제인지 확인하기 위해 "이 웹사이트 관련 문제점 세부사항"을 클릭해 봤습니다. 


내용을 살펴보니 멀웨어를 배포한다고 하는데 중계 역할을 알라딘 사이트에서 수행하는 것 같았습니다. 

그래서 일단 알라딘 ttb2를 가져오는 스크립트를 제거했습니다. 

아마도 알라딘의 ttb2 서버에 문제가 있는 것 같네요. 


하지만 스크립트를 제거해도 여전히 크롬에서는 악성코드 페이지로 나옵니다. 

그래서 위 화면의 하단의 "Google 웹마스터 도구"를 클릭해서 구글로 "검토 요청을 보내야 합니다. 





일단, 검토 요청은 보내놨는데.. 내일 중으로 다시 한번 확인해 봐야겠네요.. 

개인 블로그라 다행이지 만약 회사의 서비스 등에 붙였다면 상당히 난감했을 듯 하네요. 


요즘 들어서 멀웨어 관련 공격이 많은 것 같습니다. 

모두들 조심하세요~ 





Trackback 0 And Comment 1

빅데이터의 확장 배경과 실제 사례들

|



올해부터 빅데이터에 관심이 부쩍 높아진 것 같습니다. 

클라우드 환경이 대중화되고 하둡 등 분산 처리 기술이 일반화 되면서 자연스럽게 빅데이터에 대한 관심도 늘어나는 것 같습니다. 

하지만 아직도 빅데이터를 단순히 대용량 데이터로만 생각하는 경향이 있어서 

빅데이터의 의미와 실제 사례를 간략하게 정리해 보려고 합니다. 


빅데이터 확장 배경

왜 빅데이터에 관심을 가지게 되었을까요?

먼저 하드웨어가 발달하고 ERP, CRM과 같은 것을 통해 데이터가 충분히 축적되었다는 것입니다. 

이렇게 축적된 데이터를 통해 비즈니스에 기여할 수 있는 인사이트를 만들 수 있을까? 하는 고민이 빅데이터의 시작이라고 생각합니다. 


모든 IT 관련 이슈들이 그러하듯 빅데이터란 것도 하루아침에 나타난 것이 아닙니다. 

예전에 데이터베이스에서도 OLAP 기반의 대용량 데이터 처리에 대한 관심들이 있었죠. 

하지만 데이터의 양이 그때와 비교해 너무 크다는 이슈도 있습니다. 


  • 뉴욕 증권 거래소: 1일 1TB 거래 데이터 생성
  • Facebook: 100억장 사진, 수 PB 스토리지
  • 통신사: 시간당 10GB이상의 통화 데이터, 1일 240GB 생성, 월 생성 데이터의 크기 200TB 이상
  • 메신저: 1일 메시지 41억건


혹자들은 향후 이렇게 축적된 데이터들이 각 비즈니스 사업자간 거래까지 이루어 질 수 있다고도 이야기 합니다. 

즉, 사내에 축적된 데이터를 사고 파는 비즈니스가 만들어 질 수 있다는 것이죠. 

물론 개인정보보호와 같은 이슈들은 있지만 충분히 가능한 이야기라고 생각됩니다. 


빅데이터의 3가지 요소는 다음과 같이 규모, 속도, 다양성으로 주로 다루고 있습니다. 

아래 그림을 참고하세요. 



빅데이터 활용 사례

이런 빅데이터가 실제 어떻게 활용될 수 있는지 사례를 통해 살펴보도록 하겠습니다. 


제품 개발과 관련된 사례


가전 제품을 새롭게 만들때 소비자가 잘 사용하지 않는 기능들을 추가해서 제품 가격이나 생산 비용이 상승하는 경우가 있습니다. 

소비자가 각 기능을 사용하는 빈도를 자동으로 수집해서 분석하면 새로운 제품을 출시할 때 자주 사용하지 않는 기능을 제거할 수 있을 것입니다. 

또한, 예상하지 못한 사용으로 인한 고장등을 파악해서 제품의 성능을 확장할 수도 있겠죠. 


실제 구글에서는 GOOG-411이란 서비스를 2007년부터 2010년까지 무료로 서비스를 했었습니다. 

GOOG-411은 우리나라 114와 같은 전화번호 안내 서비스인데요. 

음성통화이기는 하지만 전화번호 안내를 모두 사람이 아닌 기계가 처리하는 방식으로 되어 있었습니다. 

구글은 왜 이 서비스를 무료로 진행했던 것일까요? 

이유는 바로 구글의 음성인식 알고리즘의 성능 향상을 위해 음성 데이터를 수집하기 위해 진행한 것입니다. 

즉, 이 기간동안 수집된 음성들을 통해서 현재 구글의 음성인식 서비스가 완성되었다고 할 수 있겠죠.. 


마케팅 관련 사례


기존의 POS 시스템을 사용해서 판매량 분석과 같은 작업은 오래전부터 이루어지고 있습니다. 

그러나 POS는 판매시점의 데이터를 분석하게 되는데요. 

빅데이터를 활용하면 고객의 활동이나 동선등을 분석해서 새로운 인사이트를 도출할 수 있다는 것입니다. 


대표적으로 상품 추천 서비스나 최적화된 광고 전송과 같은 것들이 있을 수 있습니다. 

상품 추천을 가장 처음 시작한 아마존은 킨들이라는 전자책에 밑줄 긋기 기능을 제공하고 있습니다. 

사용자가 체크한 부분을 서버에 올리고 다른 사용자와 공유할 수도 있게 구성되어 있다고 합니다. 

이것을 통해 Amazon Popular Highlights 기능을 제공하고 있는데요. 

향후, 소비자에게 책을 추천할 때 가까운 고객이 밑줄 그은 부분을 소개하면서 추천해 줄 수도 있겠죠.. 


우리나라 통신사도 망 혼잡 시간에는 3G 데이터의 과다 트래픽 사용자의 속도를 실시간으로 떨어뜨리는 방식을 취하고 있는데요. 

이런 경우에도 시시각각 생성되는 시간대별, 지역별 트래픽 이용 상황에 대한 데이터를 실시간으로 수집해서 분석하는 것으로 볼 수 있을 듯 합니다. 


기타 사례


건물이나 자동차 등에 센서를 부착해서 데이터를 지속적으로 수집한다면 

매년 또는 분기별로 시행하는 정기 검사가 아니더라도 문제가 발생하기 전에 사전에 파악할 수 있을 것입니다. 

이러한 경우, 대형 사고로 이어지는 문제를 빅데이터를 통해서 사전에 차단할 수 있겠죠. 


요즘 보안과 관련된 이슈도 많은데요. 

신용카드의 부정 사용 방지를 위해서는 결제가 일어나는 짧은 시간이내에 부정 여부를 판단해야 합니다. 

이러한 경우에 수많은 거래 데이터를 분석하기 위한 빅데이터 처리가 필요하겠죠. 

그외에도 광고에서의 부정클릭 방지도 비슷한 로직으로 처리될 것 같습니다. 


또한 GPS나 차량 운행 기록을 수집해서 경제적인 운전 여부를 판단하거나 

수집된 데이터를 통해 장치의 실제 가동 현황등을 파악할 수도 있을 것 같습니다. 


스마트폰의 활용을 분석해서 성별, 연령별 인구분포 및 지역간 인구 이동 현황도 파악이 가능하다고 하네요. 

그리고 스마트 그리드 등과 같은 전력 사용 효율화도 현재 진행중인 것으로 알고 있습니다. 


마치면서 

향후 빅데이터가 활성화되면 온오프라인이 결합된 형태로 서비스가 가능해 질 것이라고 합니다. 

현재 인터넷을 통해 옷과 같은 상품을 살펴보면 다른 사이트를 들어갈 때마다 그 옷이 계속 따라다니는 것을 경험해 보셨을 것입니다. 

바로 리타게팅 광고의 결과인데요. 

나중에는 인터넷을 통해 옷을 살펴보고 난 후, 거리를 지나가다가 그 옷이 진열된 매장의 전광판에 

"들어오셔서 한번 입어보고 가세요" 하는 광고가 나올 수도 있을 것 같다는 생각도 드네요.. ^^


여기에 이야기한 부분 이외에도 실제 빅데이터의 사례는 무궁무진할 것이라고 생각됩니다. 

원래 빅데이터가 의미 없어 보이는 데이터들을 통해서 유의미한 정보를 추출하는 것이기 때문에 

주변의 데이터들에 대해서도 한번쯤 관심을 가져보시기 바랍니다. 


그리고 앞으로 빅데이터와 관련된 인사이트가 중시되면서 빅데이터를 처리할 수 있는 기획자, 기술자, 통계학자 등이 많이 필요할 것으로 보입니다. 

지금부터 준비를 한다면 빅데이터 시대에 핵심 인재가 될 수 있지 않을까 생각합니다. 





Trackback 0 And Comment 0
prev | 1 | 2 | 3 | next