jaso extends j2ee

Cloumon - Hadoop Management Tool

(김형준) — Sun, 29 Apr 2012 23:19:28 +0900

Bamboo에 이어 이번에는 그루터에서 만든 Hadoop, Hadoop Echo 시스템 관리 도구인 Cloumon에 대해 소개하겠습니다. Cloumon은 처음 개발은 오픈소스로 시작하였지만(www.cloumon,org, www.github.com/gruter/cloumon) UI를 전면 개편하고 Hadoop 이외에 Hive, Flume, ZooKeeper 등 여러 솔루션을 관리하는 기능을 추가하여 엔터프라이즈 버전으로 만들었습니다. Cloumon을 엔터프라이즈 버전으로 만든 이유는 아직 국내 기업에게 오픈 소스 솔루션으로만 판매하기 어려운 시장 상황 때문입니다.
Cloumon은 처음에는 판매하는 솔루션이 아니라 그루터 내부 시스템을 관리/운영하기 위해 만들었기 때문에 그루터 내부에서 계속 사용하고 있으며 기능 개선, 솔루션 추가, 업그레이드 등이 꾸준하게 진행되고 있습니다. 다음은 Cloumon에 대한 소개 글입니다.

=====================================================================
클라우몬은 하둡 에코 시스템 기반의 빅데이터 플랫폼을 통합적으로 관리하는 기능을 제공한다. 클라우몬을 이용하여 데이터의 수집, 저장, 분석에 이르는 다양한 오픈 소스를 쉽게 관리, 모니터링 할 수 있다.
하둡과 하둡 에코 시스템은 대부분 오픈 소스로 구성되어 있으며 빅데이터 처리에 강력하고 안정적인 기능을 제공하는 소프트웨어 스택이다. 기능은 강력하지만 각각의 솔루션의 관리 및 모니터링 기능은 취약하며 이를 하나의 관리도구에서 통합 관리하는 것은 쉽지 않다.
모니터링을 위해 Ganglia, Nagios 등과 같은 오픈 소스 모니터링 도구를 활용할 수 있지만 이런 구성은 단순 모니터링만 지원하며 하둡 에코 시스템 내 일부 솔루션은 Ganglia, Nagios 등과 연동되는 기능을 제공하지 않는다.
클라우몬은 기본적으로는 하둡 에코 시스템의 각 개별 컴포넌트에 대한 모니터링 기능 뿐만 아니라 하둡의 파일, 작업 관리, Zookeeper의 노드 관리, Flume의 Data Flow 관리, Hive query workbench 등과 같은 관리하는 기능을 제공한다. 또한 그루터의 빅데이터 플랫폼 솔루션인 BAAS와 연동하여 웹 UI 기반으로 데이터 Flow 제어, 실시간/배치 분석 질의 관리, 분석 결과 조회 기능 등을 제공하는 솔루션이다.

클라우몬은 관리 기능 및 사용자에게 관리화면을 제공하는 애플리케이션 서버와 수집된 모니터링 데이터를 저장하기 위한 데이터베이스로 구성되어 있다.
애플리케이션 서버에서는 각 솔루션의 데몬들에 대한 모니터링 정보를 수집하여 데이터베이스에 저장한다. 각 솔루션 별로 수집되는 정보 및 방식은 모두 다르며 관리자가 설정된 특정 항목의 값이 임계 값보다 큰 값이 수집되면 메일 또는 SMS로 관리자에게 전송한다.
데이터베이스에는 수집된 모니터링 데이터와 설정 정보 등이 저장되며 기본 구성에서는 MySQL 을 사용한다.

빅데이터 통합 관리
클라우몬은 기본적으로는 하둡과 하둡 에코 시스템을 관리, 모니터링하는 기능을 제공하지만 빅데이터 플랫폼을 구성할 경우 플랫폼 전체를 유기적으로 관리하는 역할을 수행한다. 다음은 빅데이터 처리 흐름에 따른 클라우몬의 관리 기능을 매핑한 그림이다.

Hadoop File System 관리
- 모니터링 및 상태 정보 관리
NameNode, DataNode의 데몬 상태와 메모리 Heap 사용 상태, 쓰레드 개수 등의 데이터를 관리하는 기능으로 수집된 데이터는 데이터베이스에 저장되어 장애 발생 시 분석 자료로 활용할 수 있다. 각 수집 항목은 1분 주기로 수집되며 수집 데이터가 관리자가 설정한 임계 값보다 큰 값이 수집되면 관리자에게 알람 메시지를 전송한다. 항목의 임계 값은 서버별로 설정할 수 있다.

- 파일 관리
파일 관리 기능은 하둡에 저장된 파일을 웹 브라우저에 파일 탐색기와 비슷한 사용자 인터페이스를 제공하여 파일 관리를 쉽게 할 수 있다. 파일의 기본 정보뿐만 아니라 파일이 여러 개의 블록으로 분리되어 있는 경우 블록 정보와 블록이 저장된 서버 정보도 쉽게 볼 수 있는 기능을 제공한다.

- 멀티 클러스터 관리
하나의 클라우몬 화면에서 여러 개의 하둡 파일 시스템 클러스터를 동시에 관리할 수 있다.

- 자동 서버 등록 기능
NameNode, DataNode의 환경설정 중 metrics 관련 설정에서 클라우몬 서버에 대한 정보를 설정하면 하둡 데몬 실행 시 자동으로 클라우몬에 등록하고 등록된 이후에는 자동으로 상태 정보를 수집하고 모니터링 한다.

Hadoop MapReduce 관리
- MapReduce 클러스터 관리
JobTracker, TaskTracker의 데몬 상태와 메모리 Heap 사용 상태, 쓰레드 개수 등의 데이터를 관리하는 기능으로 수집된 데이터는 데이터베이스에 저장되어 장애 발생 시 분석 자료로 활용할 수 있다. 각 수집 항목은 1분 주기로 수집되며 수집 데이터가 관리자가 설정한 임계 값보다 큰 값이 수집되면 관리자에게 알람 메시지를 전송한다. 항목의 임계 값은 서버별로 설정할 수 있다.
- MapReduce Job 모니터링
MapReduce 작업 목록과 진행 상황을 관리하는 기능으로 하둡에서 기본적으로 제공하는 모니터링 화면에서는 일정 시간이 지나면 과거의 작업에 대한 상세 정보는 볼 수 없으며 JobTracker를 재시작하면 과거의 작업 실행 이력 정보는 볼 수 없다.
클라우몬에서는 과거의 모든 작업 목록을 조회할 수 있으며 일자로 검색할 수 있다. 작업 목록뿐만 아니라 작업의 Summary, Counter 정보와 job.xml 정보도 볼 수 있으며 진행 중인 작업의 경우 작업 진행 상황과 Map, Reduce Task 목록 정보도 조회 가능하다.
- Job 스케줄링
주기적으로 수행되는 작업을 등록하여 관리할 수 있는 기능으로 작업 등록은 사용자가 만든 Jar 파일 또는 Streaming 명령어, HiveQL 등을 이용하여 등록할 수 있다. 스케줄러에서는 현재 대기 상태에 있는 작업 목록이나 특정 작업의 과거 실행 이력 정보를 제공한다.

Hive 관리
빅데이터 분석에 있어 개발자나 시스템 전문가가 아닌 도메인 전문가, 데이터 전문가가 데이터에 쉽게 접근하게 분석을 수행할 수 있어야 한다. 매번 분석 시 마다 하둡 MapReduce를 프로그램을 개발하는 것은 데이터에 대한 접근을 어렵게 하고 다양한 분석 시도를 하기 어렵다.
Hive는 SQL과 유사한 질의 언어를 이용하여 데이터를 쉽게 볼 수 있는 기능을 제공한다. Hive를 이용한다 하더라도 명령행 라인과 하둡 파일 시스템 명령어, MapReduce 작업 관리 명령어 등을 알고 있어야 하기 때문에 비전문가에게는 쉽지 않다. 클라우몬의 Hive 관리 기능은 웹 기반 질의 실행, 스키마 관리, 질의 실행 결과 조회, 작업 관리 등을 실행할 수 있기 때문에 쉽게 데이터에 접근할 수 있게 해준다.
Hive 관리 도구 중 대부분은 Hive Server를 이용하는 방식으로 구현되어 있는 반면 Cloumon의 Hive 관리 기능은 Hive 모듈을 Cloumon에 탑재하여 Hive session, history, Job 연동 등과 같은 다양한 기능을 제공한다.

- 스키마 관리
Hive의 데이터베이스, 테이블 정보를 관리하는 기능으로 테이블 목록, 생성, 삭제 등 기본 기능과 테이블의 컬럼 정보, SerDe 정보, 파티션 정보 등 상세 정보를 볼 수 있는 화면을 제공한다. 또한 테이블의 데이터 파일에 있는 데이터를 직접 조회하거나 다운로드 할 수 있다.

- 질의 Workbench
HiveQL을 실행하고 실행 결과를 브라우저에서 관리할 수 있는 기능을 제공한다. 질의 저장 기능은 질의를 저장하여 나중에 불러와서 사용할 수 있다.
클라우몬의 Workbench 기능은 Hive Shell 에서 제공하는 History 기능과 세션 기능을 가지고 있어 페이지가 리로딩 되거나 다른 페이지로 이동 후에 다시 접속해도 이전 수행 내역을 볼 수 있다. Hive 질의는 질의 수행 후 결과 조회까지 많은 시간을 기다려야 하는데 이 기능을 이용하면 작업이 종료될 때까지 기다릴 필요 없으며 향후 재 접속 시에 실행 정보를 확인할 수 있다.
Query의 진행 상황 정보를 제공하여 질의가 어느 정도 수행되었는지 한눈에 확인할 수 있다.

- MapReduce 작업 모니터링 연동
Hive 작업은 대부분 하둡 MapReduce 작업으로 실행되기 때문에 MapReduce 작업에 대한 모니터링도 필요하다. 클라우몬은 MapReduce 관리 기능을 제공하기 때문에 이 기능과 Hive 관리 기능을 연동하여 특정 Query에 의해 생성된 MapReduce 작업만 선택하여 관리할 수 있는 화면을 제공한다.

ZooKeeper 관리
- ZooKeeper 클러스터 관리
ZooKeeper 클러스터를 구성하는 서버의 상태 정보 및 각 서버에 접속되어 있는 클라이언트의 접속 상태와 네트워크 트래픽, 큐 대기 시간 등을 모니터링 할 수 있는 기능을 제공한다. ZooKeeper 클러스터에 장애가 발생하면 다른 기능을 수행하는 클러스터에도 영향을 미치는 중요한 컴포넌트이기 때문에 ZooKeeper의 서버들 중 일부 서버에 장애가 발생하면 가능한 빠르게 처리하는 것이 좋다. 클라우몬은 ZooKeeper 서버 장애 즉시 장애 상황을 알려준다.

- 노드 관리
ZooKeeper는 메모리 기반으로 트리 구조의 노드를 가지고 있으며 이들 노드의 정보는 전체 클러스터에서 중요한 메타 정보의 역할을 수행한다. 따라서 운영 중이나 개발 중에 노드의 생성, 삭제 등을 관리하는 작업이 빈번하게 발생한다. ZooKeeper에서 기본적으로 제공하는 관리 기능은 Shell 기반의 명령행으로 관리하기 때문에 한눈에 파악하기도 어렵고 관리가 불편한다.
클라우몬은 탐색기와 같은 구조로 노드의 구조를 보여주고 노드를 쉽게 추가, 삭제, 수정할 수 있는 기능을 제공한다.

- 노드 권한 관리
ZooKeeper의 각 노드는 중요한 메타 정보를 저장하기 때문에 권한 관리가 중요하다. 하지만 명령행 라인으로 권한 관리를 하는 것은 직관적이지 않아 불편하다. 클라우몬에서는 각 노드의 권한 정보를 쉽게 보여주고 노드 생성 시 권한 설정도 쉽게 할 수 있는 기능을 제공한다.

- 노드 Watcher 등록
ZooKeeper는 노드의 자식 노드 생성, 삭제, 수정 등의 이벤트 발생 시 원격에서 등록되어 있는 Watcher를 호출해 주는 기능을 가지고 있다. 이 기능을 이용하여 분산 환경에서 클러스터 멤버쉽, 공유 자원에 락 획득 및 해제 등 중요한 작업을 수행할 수 있는 기능을 제공한다. 이런 기능을 수행하기 위해서 Watcher를 등록하는데 Watcher를 등록하기 위해서 별도의 데몬을 실행해야 하는데 필요할 때 마다 이런 프로그램을 만들어 사용하는 것은 어렵다.
클라우몬은 관리 화면에서 쉽게 지정된 Watcher를 등록할 수 있다, 기본적으로 제공하는 Watcher는 이벤트 발생 시 메일을 전송해주는 MailNotiWatcher가 있으며 Plug-in이 가능하여 사용자가 만든 Watcher를 바로 등록할 수 있다.

Flume 관리

- Flume 클러스터 모니터링
Flume의 Master 서버와 Agent, Collector의 데몬 상태와 메모리 Heap 사용 상태, 쓰레드 개수 등의 데이터를 관리하는 기능으로 수집된 데이터는 데이터베이스에 저장되어 장애 발생 시 분석 자료로 활용할 수 있다. 각 수집 항목은 1분 주기로 수집되며 수집 데이터가 관리자가 설정한 임계 값보다 큰 값이 수집되면 관리자에게 알람 메시지를 전송한다. 항목의 임계 값은 서버별로 설정할 수 있다(일부 기능 제공).

- Data Flow 관리
Flume은 데이터 수집을 위한 솔루션으로 데이터의 소스로부터 저장소까지 일련의 데이터 흐름을 관리하는 것이 중요하다. Flume에서 기본적으로 제공되는 관리 기능에서는 각 단위 데몬에 대한 설정만 가능하고 Data flow 라는 관점에서 관리하는 뷰를 제공하지 않는다.
클라우몬의 Flume Data Flow 관리 기능에서는 하나의 관리 뷰로 데이터 소스, 수집기, 데이터 저장소를 지정하여 관리하는 기능을 제공하여 Agent, Collector의 각 Source, Sink 설정도 chain, fanout을 flow 형태로 정의할 수 있는 화면을 제공한다.

- 다양한 Source, Sink, Decorator 제공
Flume에서 기본적으로 제공되는 Source, Sink, Decorator모듈만으로는 사용자 요구사항에 만족하는 데이터 수집 기능을 구성하는 것은 어렵다. 클라우몬에는 RollingFileTailSource, CheckpointDecorator, MultiSink 등 다양한 Plug-in 모듈을 제공한다.

HBase 관리
- HBase 클러스터 모니터링
Master, RegrionServer의 데몬 상태와 메모리 Heap 사용 상태, 쓰레드 개수 등의 데이터를 관리하는 기능으로 수집된 데이터는 데이터베이스에 저장되어 장애 발생 시 분석 자료로 활용할 수 있다. 각 수집 항목은 1분 주기로 수집되며 수집 데이터가 관리자가 설정한 임계 값보다 큰 값이 수집되면 관리자에게 알람 메시지를 전송한다. 항목의 임계 값은 서버별로 설정할 수 있다.

- HBase Data 관리
HBase에 저장된 데이터를 웹 관리화면에서 조회, 수정, 삭제할 수 있는 기능(향후 제공 예정)

서버 기본 정보 관리
클라우몬은 하둡과 하둡 에코 시스템을 관리, 모니터링하는 솔루션이기 때문에 물리적인 서버 자체에 대한 세부 관리, 모니터링 기능은 제공하지 않는다.
하지만 하둡을 관리하기 위해서는 하둡이 설치되는 서버의 디스크 용량, 네트워크 사용량 등과 같은 기본 정보에 대해서는 모니터링을 수행해야 하기 때문에 물리적인 서버의 기본 정보에 대해서는 모니터링 기능을 제공한다. 다음은 클라우몬에서 관리하는 서버 모니터링 관리 항목이다.

- CPU 사용률, Disk 사용률(파티션 별), 네트워크 In/Out 트래픽, 메모리 사용률

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Bamboo: Data pipeline 개요

(김형준) — Thu, 19 Apr 2012 11:11:58 +0900

명색이 기술 블로그를 지향하면서 요즘은 기술적인 이야기보다 다른 이야기로 많이 채워졌네요. 최근 저의 근황이 기술에 대한 연구보다는 서비스 개발, 프로젝트 진행 등에 많은 시간을 투자하다 보니 그런것 같습니다. 최근 논문 한편 볼 시간도 없는 상황입니다.
그래서 이본 글에서는 알려진 기술이나 오픈소스에 대한 소개보다는 그루터의 서비스(www.seenal.com) 또는 내부 플랫폼에 사용하고 있는 Bamboo에 대해 간단하게 소개 정도만 해볼까 합니다.
Bamboo가 정확하게 어떤 분류 이름을 달아야 할지는 애매해서 일단 제목에서 Data pipeline이라고 했습니다. 내부적으로 Data bus 등이라는 용어가 어떨까 하는 의견도 있습니다.

과거에는 데이터 분석, 처리에 있어 데이터량이 작거나 트랜젝션이 많지 않으면 데이터(트랜젝션) 발생 즉시 데이터베이스 등에 저장하고 이를 웹 화면 또는 질의를 통한 분석을 하였습니다. 데이터가 많으면 주기적으로 안정적인 저장소에 저장하거나 분석 작업을 수행하였습니다.
최근 빅데이터라는 개념이 나오면서 데이터의 크기와 상관없이 비즈니스 요구에 맟는 데이터의 처리 속도가 중요하게 되었습니다. 즉, 데이터의 크기에 상관없이 요구사항이 즉시 처리 해야 하는 경우라면 그 요구사항에 부합되게 처리를 할 수 있는 플랫폼 또는 기술이 경쟁력이 되는 시대가 온 것입니다. 이를 지원하기 위한 오픈소스 진영에서도 Storm, S4 등과 같은 솔루션이 나오고 있으면 조금은 다르긴 하지만 데이터 수집 및 저장에 이르는 일련의 흐름을 쉽고 유연하게 처리할 수 있는 Flume, Chukwa, Scribe 등과 같은 솔루션도 있습니다. 이런 솔루션을 사용하여 끊임없이 들어오는 데이터(트렌젝션)에 대해 연속적(Stream)으로 처리할 수 있겠지만 그루터에서는 자체적으로 Bamboo라는 솔루션을 개발하여 사용하고 있습니다.

Bamboo에 대한 요구사항은 다음과 같습니다.
- 요구사항
. 끊임없이 전송되는 데이터에 대해 측시 처리 가능해야 한다.
. 분산되어 발생되는 데이터의 흐름을 쉽게 제어할 수 있어야 한다.
. 일부 서버의 장애 또는 점검, 비즈니스 로직 변경 등으로 데이터를 받을 수 없는 상황에서도 데이터는 계속 흘러가야 한다.
. 데이터를 처리할 수 있는 로직은 쉽게 추가하거나 제거할 수 있어야 한다.
. 데이터 처리 로직에 부하가 발생할 경우 이를 다시 분산해서 처리할 수 있어야 한다.
. 서버의 장애, 점검 등의 상황에서는 일부 데이터의 유실 또는 중복은 발생할 수 있다.

한줄로 요약하면
"데이터는 계속 흘러야 하고 그 흐르는 데이터는 누구든 쉽게 언제든지 가져다 쓸수 있어야 한다."
입니다.

다른 요구사항은 장점에 대한 요구사항이지만 데이터의 유실 또는 중복이 발생할 수 있다라는 요구사항은 단점에 해당하는 요구사항입니다. 하지만 분산된 환경에서 끊임없이 전송되는 외부 데이터를 유실, 중복없이 관리할 수 있는 솔루션을 개발하는 것은 많은 기술과 시간이 소요됩니다. Bamboo에서 처리하는 데이터의 속성이 소셜네트워크 데이터, 웹 페이지 데이터 등과 같이 외부 인터넷 서비스의 데이터가 주요 데이터이기 때문에 데이터 일부 유실이 되어도 다시 가져올 수 있고 중복은 백앤드에서 처리할 수 있는 구조를 가지고 있기 때문에 시스템을 복잡하게 만들지 말자는 요건으로 요구사항에 추가된 것입니다.
이런 요구사항에 맞추어 다음과 같은 구조를 가지고 있는 솔루션을 만들었습니다.

- 구성요소
. Bamboo Client: 데이터 수집기(Crawler)에 내장되어 수집되거나 생성된 데이터를 Collector로 전송하는 기능
. Bamboo Collector: client에서 전송된 데이터가 모이는 허브 역할을 수행하고 Collector에서는 비즈니스 로직을 처리하지 않고 즉시 백앤드(Group Connector)로 전송하는 기능. 즉 데이터 허브 역할 수행. Group Connector로의 데이터 전송은 동일한 데이터를 모든 Connector에게 전송.
. Group Connector: Collector로 부터 데이터를 받아서 비즈니스 로직을 처리할 각 Receiver 로 데이터를 전송하는 기능. 데이터 스위치 역할 수행. 하나의 Collector에는 여러개의 Group Connector가 붙을 수 있으며 동적으로 추가, 제거가 가능.
. Receiver: 실제 비즈니스 로직을 처리하는 모듈이 탑재되어 있으며 하나의 Group Connector에는 여러개의 Receiver가 붙을 수 있으며 데이터 전송 all 또는 round robin 방식이 있다. Receiver도 동적으로 추가, 제거할 수 있다.

이런 구성이 필요 했던 이유는 서버 등의 부족으로 어떤 서버에서 처리하던 일을 필요에 따라(해당 서버는 다른 역할을 수행하게 하거나 부하가 많이 발생하는 경우 등) 다른 서버로 옮기는 등의 작업이 수시로 발생하고 전체 데이터에 대해 원본 저장, 실시간 분석, 검색 인덱싱, 집계 등 여러 종류의 작업이 수행되어야 하고 이 작업의 종류도 수시로 변하기 때문입니다.
처음에는 하나의 Group Connector에 여러개의 Receiver를 붙여서 처리하다가 Group Connector에 부하가 걸리면 Collector에 새로운 Group Connector를 붙여 데이터 흐름을 하나 더 만들어서 처리하고 하는 등의 방식으로 데이터를 처리하고 있습니다.
위의 데이터 흐름은 고정된 것이 아니고 필요에 따라 Group Connector에 또 다른 Group Connector로 붙일 수 있는 유연한 구조를 가지고 있습니다.

- 사례: Bamboo를 이용한 IDC 이중화
그루터의 서버는 2개의 IDC에 분산되어 있는데 수집은 하나의 IDC에서만 하고 있습니다. IDC 이중화 또는 용도별로 데이터를 활용하기 위해서는 수집을 하지 않는 IDC에도 수집 데이터가 전송되어야 하고 이것은 배치가 아닌 수집 즉시 전달되어야 합니다. 그리고 데이터에 대한 처리도 양쪽 IDC에서 다양하게 추가되거나 제거될 수 있는 상황입니다.
이 요구사항을 만족시키기 위해 Bamboo를 이용하여 다음과 같이 구성하였습니다.

IDC간의 네트워크 비용이 비싸기 때문에 각각 개별 프로그램에서 필요에 따라 데이터를 전송할 경우 불필요하게 유사한 데이터가 전송되는 등의 문제가 있는데 Bamboo를 이용하여 IDC 이중화 데이터 흐름을 구성한 후 반대쪽 IDC에서는 해당 IDC에 설치된 Group Connector에 붙어서 작업을 수행할 수 있도록 구성하였습니다.

이런 구성은 Flume 등을 이용하여 구성하는 것도 가능합니다. 실제로 그루터에서는 Flume도 일부 사용하고 Flume을 효과적으로 관리할 수 있는 관리도구도 만들어서 제공하고 있습니다. 하지만 동적으로 쉽게 데이터의 흐름을 추가하고 바꾸고 하는 작업에서는 Bamboo를 이용하여 쉽게 처리하고 있습니다.
Bamboo는 아쉽게도 오픈소스는 아닙니다. 제가 강연에서 가능하면 기업 내부에서 만든 솔루션은 오픈 소스화 해줬으면 좋겠다고 외치고 있지만 정작 저희가 만든 솔루션은 오픈한 것도 있지만 오픈하지 않은 것도 있습니다. 아직 수익구조가 탄탄하지 않고 국내의 비즈니스 환경이 오픈 소스에 대한 비용 지불에 대한 구조가 정확하게 확립되지 않은 상황이다 보니 전략적으로 아직 공개를 하지 못하였습니다.
Bamboo는 한순간에 뚝딱 만든 솔루션이 아니라 플랫폼과 서비스를 운영하면서 지속적으로 개선하면서 현재의 모습으로 갖추게 되었습니다. 이것은 단순 구축형 프로젝트가 아닌 내부 서비스를 가지고 있기 때문에 지속적인 개선이 가능했던 것 같습니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

내 경력에는 조기축구회 4년이 있다.

(김형준) — Mon, 16 Apr 2012 09:08:10 +0900

NHN에 근무했다는 것이 이렇게 민망할때가 그지 없습니다. 오늘 아침에 출근 길에 다음 기사를 보고 드는 느낌이었습니다.

이해진 "편해서 네이버 왔다는 직원에 억장 무너져"
http://www.hankyung.com/news/app/newsview.php?aid=2012041550991&sid=0002&nid=000&ltype=1

기사를 보자마자 출근글 지하철 안이지만 한마디 적기로 마음먹었습니다.
모든 개발자라면 다 알고 있듯이 소프트웨어 개발은 이미 3D 직군입니다. 국내 많은 부분을 차지하고 있는 SI 프로젝트는 짧은 납기와 적은 비용으로 계속해서 변화하는 고객의 요구사항에 맞추기 위해 개발자들만 죽어 나가고 있는 형국입니다. 프로젝트 수주의 열매는 영업이 가져가고 프로젝트 성공에 대한 성과는 주 계약자인 SI 업체가 가져갑니다.
그렇다고 SI 업체에 있는 개발자는 좋은 환경일까요? 개발 업무를 수행하거나 새로운 기술을 연구, 학습하기는 커녕 보고 문서 작업, 외주 업체 관리 등의 과중한 업무로 개발 코드는 쳐다보지 못하고 있는 상황입니다.
그런 의미에서 보면 NHN의 개발 환경은 정말 "편한" 환경입니다. 서비스 오픈에 집중하여 사내 다양한 리소스(디자인, 기획, 품질 등)가 개발팀과 협업하고 있고 문서 중심의 보고 체계보다는 실무 중심의 보고 체계로 개발자가 개발에 집중할 수 있는 환경을 가지고 있기 때문입니다.
저도 삼성에 있다가 NHN으로 이직을 하였습니다. NHN이 훨씬 편했습니다. 여기서 편했다는 의미는 몸이 편했다는 것이 아니라 개발 환경이 편하고 치열하게 조직내/외부에서 경쟁했던 과거에 비해 조직 문화가 좋아서 편했다는 것입니다.
물론 일부 직원은 말그대로 편하게 지내는 분들도 있을 겁니다. 하지만 그런 일부 직원들의 모습을 보고 전체 직원, 개발자들을 한낱 조기축구회로 만들어 버리는 경영진을 보니 어이가 없습니다.
그러면 다음 질문에 대해서는 어떻게 생각하시나요? 인터넷 환경이 급격하게 변하는 시기에 경영진은 무엇을 했습니까? 모바일 붐을 일으키려는 그 시기에 모바일 센터를 없애고, 메신저 서버스가 모바일에서 킬러 서비스가 되려는 시작의 시기에 네이버 폰 서비스를 없애는 등은 누구의 잘못인가요? 일본 검색 시장 진출에 대한 성과 평가는 어떻게 생각하시나요?
아무리 위기이고 직원들이 이 위기를 공감하지 않는다고 해서 경영진이 수천명의 직원을 조기축구회원으로 만들어 버리는 언급은 위험한 발상입니다. 위기라면 설사 경영진이 잘못하지 않았더라도 경영진의 무능함을 먼저 사과하고 현재의 상황을 공유하여 직원들과 위기를 공유하는게 맞지 않을까요? 새롭고 혁신적인 서비스가 나오지 않고, 서비스의 일정이 지연되는 것이 모두 직장을 편하게 생각하고 있는 직원(개발자)의 잘못일까요?
NHN에 근무하는 중에 지금 새롭게 소프트웨어 개발자를 하려고 하는 졸업생이 너무 부족하여 어렵다 라는 말을 많이 들었습니다. 왜 부족할까요? 좋은 근무 환경(어떻게 보면 편한)의 직장이 너무 없다는 것입니다. 그만큼 공부했으면 다른 직업을 가졌으면 훨씬 더 좋은 대우를 받을수 있다는 것이죠... 그런 의미에서 NHN의 지금과 같은 상황은 소프트웨어 개발 업종으로 들어오지 말라고 이야기하는 것과 마찬가지 입니다.
업무 강도에 대한 이야기를 해보겠습니다. 현재의 NHN은 임직원 수를 보면 이미 대기업입니다. 그리고 과거의 벤처 시절의 긴장과 업무 강도는 성공했을 때 그 성과를 모두 다 가져갈 수 있다는 벤처 회사만의 특징이었을 겁니다. 지금의 구성원은 자기가 아무리 밤새워 일해도 나에게 돌아오는 거는 남들보다 조금 더 많은 성과금이라는 것을 알고 있습니다. 이것도 나의 노력이 내 윗선에 인정을 받았아야 한다는 조건이 달립니다. 이런 대기업적인 조직환경에서 벤처 시대의 긴장감을 요구하는 것 자체가 무리가 아닐까요? 현재의 NHN은 일상적인 관리 문화에서 새로운 것을 만들어내야 합니다. 그런 조직과 프로세스를 만들어 내야 하는 것이 경영진의 숙제인것이고요. 그것을 개발자 또는 임직원의 나태나 긴장감 부족으로 위안을 삼기에는 너무 커져 버리지 않았을까요?
NHN에는 많은 우수한 개발자가 있습니다. 제가 아시는 분들도 많고요. 하지만 많은 분들이 또 나오셨습니다. 그런 분들에게는 애초에 근무 시간이나 근무 강도는 의미가 안되었습니다. 개발자의 생산성은 얼마나 자리에 않아 있고 야근을 했냐가 아니라 얼마나 자기 주도적으로 했냐라고 생각합니다. 그런 측면에서 보면 현재의 NHN 환경은 개발자에게 그냥 늦게까지 야근만 하다가 가는 그런 무의미한 시간 보내기 활동만하는 것이 평가에 더 좋은 그런 회사가 되었습니다.
이런 회사에서 개발자는 어떤 행동 패턴을 보일까요? 1. 그냥 회사에서 시간 뭉개고 자기 개발이나 한다. 2.그냥 딴데 간다.(이런 개발자는 주로 잘하는 개발자일 가능성이...)
이런것을 원하신건가요?
그리고 야근을 강요하고 계시는데 이것은 엄연한 노동법 위반입니다. 야근을 원하시면 정당한 급여에 비례한 야근 수당을 주고 야근을 시켜야하지 않을까요?
우리 개발자들 그렇게 하지 않아도 퇴근하면서도 배포된 프로그램 장애가 나지 않을까 고민하고 자면서도 문자메시지 오면 벌떡 일어나서 모니터 쳐다 보고 있습니다.
위기라면 자신의 잘못을 먼저 살펴보고 직원들을 다독거리고 공감을 이끌어 나가는 것이 리더의 자세가 아닐까 생각해서 안타까운 마음에 글을 적어 보았습니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

조금 다르게 보는 트위터 총선 분석

(김형준) — Tue, 03 Apr 2012 15:27:17 +0900

이번 포스팅은 깔대기 포스팅입니다.
2011/10월 서울시장 선거에서 그루터에서 트위터 데이터를 분석하여 박원순 후보와 나경원 후보의 언급 수, 주요 키워드, 많이 리트윗된 메시지 등에 대해서 서비스를 제공하였습니다.
서울 시장 선거 당시만 해도 소셜 네트워크 데이터에 대해서 이런 서비스를 제공하는데는 몇군데 없었는데 이번 총선에는 포털부터 시작해서 많은 업체들이 서비스를 내놓고 있습니다.
그루터도 처음에는 이런 서비스를 오픈하려고 기획을 했는데 남들 다하는 서비스 만들어 봐야 리소스만 낭비이고 차별화 시키기 어렵다는 내부 의견이 많아서 조금 다른 방향으로 접근해 보았습니다.
그래서 오늘의 총선돌이(님)와 오늘의 네거티브트윗, 보수/진보 각 진영에서 가장 이슈화된 트윗 형태로 만들어 봤습니다.

http://www.seenal.com/election2012

그리고 그루터의 실시간 분석 기술을 이용하여 만든 오늘의 총선돌이(님) 쓴 글이 어떻게 전파되고 누구를 통해 전파되었는지를 한눈에 볼수 있는 리트윗 지도도 볼 수 있습니다. 리트윗 지도는 시스템 리트윗 뿐만 아니라 실시간 네트워크 분석 기법을 이용 멘션된 리트윗도 트레이스하여 보여주고 있습니다.

한번씩 둘러 보세요... 이유있는 댓글 환영합니다. ㅋㅋㅋ
그리고 http://www.seenal.com 도 관심 가져주세요.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

최근 네이버 관련 기사를 보고...

(김형준) — Mon, 02 Apr 2012 11:07:21 +0900

요즘 기사에 대한 의견을 쓰는 글이 많아 졌네요. 시간을 내서 제 생각을 정리하는 글을 많이 올려야 하는데 여유가 없으니 정리가 안되는 것 같습니다. 그러다보니 남이 정리해놓은 글에 제 생각만 올리는 무임승차를 하게 되네요...
이번 글은 "이해진 이재웅 창업자가 네이버와 다음에 주문한 것은" 이라는 기사에 대한 제 생각입니다.
http://media.daum.net/digital/internet/view.html?cateid=1048&newsid=20120330162620370&p=etimesi

제가 다음에는 근무하지 않았기 때문에 다음에 대한 내용은 잘 모르겠습니다. 네이버의 경우 조직이 2006 ~ 2008년 사이에 임직원 수가 갑자기 늘어 났습니다. 제가 느꼈던 것은 이 시기에 대기업의 관리 문화를 많이 적용하려고 했던 것 같습니다. 지원 조직이 많아지고 개발에서는 공통 플랫폼, 표준, 프로세스라는 단어가 많이 나오기 시작했습니다. 조직 관리에서는 개발자에까지 KPI를 작성해야 하고 자기가 수행한 일에 대한 평가가 중요한 요소가 되기 시작했습니다. 즉 더 이상 혁신적인 조직이 아닌 대기업의 조직 문화를 많이 가져오게 됩니다.
저는 대기업에서도 근무해 보았기 때문에 나름 대기업의 문화에 대해서도 친숙하게 알고 있습니다. 대기업의 조직 관리 문화는 그 자체로 경쟁력이 높다고 생각하고도 있습니다. 여기에는 몇십년 동안 다져온 보이지 않는 룰이 있습니다. 그런 룰 속에 조직 문화가 있고 이런것들이 어우러져 불만은 있지만 성과를 내면서 운영되고 있습니다. 또 이런 문화는 전통적인 산업에서 경쟁력을 가집니다.
반대로 인터넷 서비스와 같은 업종에서는 이런 조직 문화는 오히려 경쟁력을 낮춘다고 생각합니다. 많은 이유가 있겠지만 이것을 나열하기 보다는 현재의 인터넷 산업을 주도하고 있는 회사들만 봐도 이것은 명백한 사실입니다. 삼성전자도 애플, 구글, 아마존과 같은 서비스를 만들려고 몇년전부터 천명이상의 개발자를 채용하면서도 아직까지 뚜렷한 성과를 내지 못하고 있는 것만 봐도 알 수 있습니다.
기사에서 말한 조직이 문제인 것만은 맞다고 생각합니다. 하지만 이미 그런 방향으로 수년간 흐른 상태에서 단순히 직원들에게 슬림화만 강조하고 야근만 강조한다고 새로운 돌파구가 만들어 질지는 의문입니다. 대기업의 기업 문화도 아니고 벤처의 기업 문화도 아닌 애매한 상태로 또 다른 실험으로 끝나지 않을까 하는 생각이 듭니다.
최근 네이버가 온라인 마켓을 오픈했다는 소식도 접했습니다. 시장이 지배 사업자로 새로운 시장을 만들기 보다는 우월적인 지위를 이용해 기존의 시장을 장악하려는 전형적인 대기업의 문화를 그대로 따라가고 있습니다. 창조적인 서비스를 만들어서 없는 시장을 개척하거나 해외 시장을 공략하려는 적극성이 부족해 보입니다.
이런 경영전략의 부재를 단순히 조직의 문제로 치부하고 개발자들에게 더 많은 야근을 강요하는 그런 불편한 조직 문화로 바뀌지 않을까 하는 걱정이 더 큽니다. 회사의 비젼이 대부분의 개발자가 공감하고 그런 비젼을 만들어 나가는데 자신도 동참한다고 느낄때 자연스럽게 시간은 더 많이 투자하고 더 좋은 조직이 만들어 진다고 생각합니다.
네이버가 개발자에게 여전히 좋은 직장입니다. 개발자의 한사람으로 국내에 좋은 직장이 많이 생기기를 바라는 마음입니다. 네이버도 계속 해서 개발자에게 좋은 직장으로 남기를 바랍니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

몽고DB 쓰지 마세요...라는 기사를 보며

(김형준) — Fri, 30 Mar 2012 02:07:46 +0900

몽고DB 쓰지 마세요 라는 기사가 나왔습니다.

http://www.bloter.net/archives/103400

기사의 내용이 진의 여부를 가리기 전에 이런식의 기사는 문제가 많다고 생각합니다. 시스템을 구축하는데 있어 모든 상황을 만족시켜주는 솔루션(은총알)은 없는 것과 마찬가지고 어느 정도 완성도가 있는 솔루션이라면 요구사항에 따라 아주 잘 사용될 수도 있습니다.
몽고 DB가 어떤 문제를 가지고 있다 하더라도 어떤 업무에서는 아주 잘 동작하고 최선의 선택이 될 수도 있는데 무턱대고 쓰지 말아야 한다는 식으로 선입견을 주는 것이 잘못된 것이 아닌가 생각합니다.
이 기사를 관리자가 보게 되었을 때 그 개발 조직에서는 MongoDB가 최적의 솔루션임에도 불구하고 개발자가 관리자를 설득하는게 훨씬 더 힘들어 질 것입니다.
언론에서 기사를 내기 위해서는 단정을 짓기 전에 장단점, 해당 솔루션이 사용되기 좋은 상황, 사용하지 말아야 할 상황 등과 같은 정보를 제공했어야 기사로써의 가치가 있지 않을까요?
기사에서 언급한 HBase, Cassandra도 일부 문제점을 가지고 있습니다. 그러면 이들 솔루션도 쓰지 말아야 할까요?
물론 아직까지는 대부분이 NoSQL 솔루션이 쉽게 사용하기 어려운 것이 사실입니다. 제가 하는 대부분의 세미나에서는 NoSQL을 사용하기 위해서는 설치, 사용방법을 익히는 수준에서 검증해보고 사용해서는 안되고 반드시 아키텍처, 동작원리, Failover, Replica 메커니즘 등에 대해 반드시 이해하고 확신이 생길때만 사용하라고 하였습니다. 가능하면 코드 수준에서 검증하는 것이 가장 좋다고도 강조하였고요.
MongoDB도 같은 맥락이지 않을까 합니다.오픈 소스이고 활발하게 사용되는 솔루션이기 때문에 노력만 하면 안정적으로 사용할 수 있고 다소 불안한 부분은 회피 또는 수정을 통해 사용도 가능하기 때문입니다.
이미 MongoDB를 사용하고 있거나 사용을 계획하고 있는 기사에 언급된 문제점들에 대해 정확히 분석을 하고 해당 프로젝트에 그 위험 요소들이 얼마나 영향을 미칠것인가를 예측, 실험을 통해 검증하는 과정을 거친 후 결정을 내리시는 것이 합리적이라고 생각합니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

데이터 분석에 대한 상반된 시각

(김형준) — Wed, 28 Mar 2012 12:05:46 +0900

최근 빅데이터와 관련되어 많은 기사와 글이 나오고 있는데 상반된 의견이 눈에 띄네요.

넥스알 한재선 대표,
“분석 알고리즘이 좋지 않아도 전체 데이터가 많다면 성능은 얼마든지 좋아진다”
http://www.zdnet.co.kr/news/news_view.asp?artice_id=20120326181347&type=xml

트리움 김도훈 대표,
"때론 수집한 데이터 양이 적어도 충분히 통찰력을 얻을 수 있습니다."
http://www.bloter.net/archives/103242

둘 다 새겨들을 만한 얘기인 듯합니다.

각 주장은 회사의 기반이 어디에 있고 무엇을 더 중요시 하느냐에 따라 주장하는 것이 상반되지 않을까 합니다. 넥스알의 경우 빅데이터 기반의 플랫폼을 기반으로 한 분석 플랫폼을 제공하는 것을 메인 비즈니스로 하고 있습니다. 따라서 데이터를 어떤 insight를 가지고 분석을 하느냐에 대한 이슈보다 데이터에 대한 insight를 어떻게 빠르고 쉬운 컴퓨팅 환경에 적용할 수 있느냐에 집중하고 있습니다. 넥스알도 내부적으로는 데이터 분석 기술을 보유하고 있는 것으로 알고 있습니다. 다만 특정 도메인에 대한 접근 보다는 분석 기법 등으로 접근하는 것으로 알고 있습니다.
특정 도메인의 데이터를 집중해서 보는 입장에서는 데이터가 아무리 많아봐야 분석을 제대로 하지 못하면 쓰레기 데이터라고 하는 것도 맞는 이야기인것 같고요.

그러면 제가 속해 있는 그루터는 어떤 상황일까요? 그루터는 빅데이터를 관리, 분석할 수 있는 플랫폼을 기반으로 하여 데이터 분석 서비스를 제공하고 있습니다.
현재는 트위터와 같은 소셜 네트워크 서비스의 데이터를 분석해서 서비스 형태로 제공하고 있습니다. 따라서 두가지를 다 하고 있다고 볼 수 있습니다. 그루터가 제공하고 있는 서비스가 제대로 된 분석을 하고 있는지에 대해서는 고객이 평가할 부분이겠지만 특정 주제를 가지고 심도있게 분석하는 분석(그루터는 이것을 Ad-hoc 분석 서비스라고 합니다)과 다양한 고객을 대상으로 한 온라인 서비스는 다르게 접근하고 있습니다.

http://news.hankooki.com/lpage/it_tech/201203/h20120325213608122310.htm
http://news.hankooki.com/lpage/society/201203/h2012032220571621950.htm

이런 기사들이 빅데이터 플랫폼 기반으로 분석된 내용들입니다.

온라인 서비스는 일반적으로 고객들이 보고 싶어하는 통계에 대한 정보와 필터링, 검색 등의 기능을 중심으로 메세지의 전파 경로, 링크의 전파 경로 등과 같이 데이터가 너무 많아서 사용자가 한눈에 파악하기 어려운 정보를 분석을 통해 잘 모으고, 정리해서 보여주고 있습니다.
이 서비스에도 더 심화된 분석 결과를 제공하는 것을 목표로 서비스를 개선하고 있지만 일반화 시키는 부분과 UI로 어떻게 표현해야 하는지에 대해서 여전히 고민 중입니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

빅데이터와 한국 시장

(김형준) — Wed, 21 Mar 2012 09:45:57 +0900

빅데이터 대한 많은 이야기가 나오고 있습니다. 다양한 회사들이 빅데이터를 외치고 있습니다. 빅데이터 시장에 어떤 회사들이 있는지 정리해 보았습니다.
개인적인 의견이며 글에 많은 오류가 있을 수 있음을 인정합니다. 댓글로 남겨주세요.

흔히 시장을 분석할때 Value Chain을 그립니다. 저는 마케팅 전문가가 아니고 공부도 하지 않았기 때문에 단순히 제가 생각하는 수준에서 분류해 보았습니다.
빅데이터도 데이터이기 때문에 시장에서 데이터에 대한 이해 관계자는 다음 정도일 것입니다.

그림1.

[그림 수정 되었습니다]
- 데이터 생산자
전통적인 데이터 분석 시장에서 데이터 생산자는 기업 자기 자신이었습니다. 기업 내부의 시스템(ERP, CRM, MES 등)이나 고객과의 거래 내역 등의 데이터 였습니다. 빅데이터에서의 데이터 생산자는 기업과 아무런 관계가 없는 일반 사용자 또는 소비자가 대부분입니다.

- 데이터 (수집)가공자
생산된 데이터를 수집하여 의미 있는 정보로 만드는 역할을 수행합니다. 전통적인 데이터 분석 시장에서도 이 역시 기업 자신이었습니다. 하지만 인터넷 서비스의 발전과 소셜 네트워크 데이터의 축적으로 데이터의 생산자와 상관없는 회사가 데이터를 분석해서 서비스를 제공하는 사례가 늘어 나고 있습니다.

- 데이터 소비자
기업 내부 데이터의 경우 분석 결과에 대한 소비자 역시 기업 자신이 됩니다. 공개된 데이터에 대한 분석 결과는 지금까지는 대부분 검색의 형태로 제공되며 데이터 소비자도 일반인이었습니다.

- 데이터 가공 솔루션(장비 등) 제공자
기업 시장에서는 오라클, IBM, HP, 테라데이터 등과 같은 BI/DW 솔루션 공급자가 이 역할을 주로 수행했으며 공개된 데이터에 분석 솔루션은 뚜렷한 솔루션이 없고 자체 개발을 하거나 국내 검색 솔루션 제공 업체가 이 역할을 수행하고 있습니다.

다음은 국내 시장에서 빅데이터에 관심을 보이거나 빅데이터 시장으로 진입을 하려는 업체들을 부분해 보았습니다.

- 포털
포털의 주 서비스이면서 수익원인 검색은 이미 과거부터 빅데이터였습니다. 따라서 이미 10년전부터 빅데이터 시장이 진입해서 수익을 내고 있는 회사들입니다. 빅데이터 관련 기술도 내부적으로 많이 축적된 상태입니다.

- 이동 통신 사업자
이동 통신 사업자는 현재의 통신 사업이 수익적인 측면에서는 포화상태이기 때문에 새로운 사업 기회를 찾고 있습니다. 또한 2천만 ~ 3천만 정도의 사용자를 가지고 있으며 이들 사용자의 콜 이력, 메시지 이력, 앱 사용 이력 등은 이미 빅데이터 입니다. 따라서 이동 통신 사업자도 이미 빅데이터를 가지고는 있습니다. 과거에는 이런 데이터를 단순히 통신 사업을 하는 용도(과금 계산, 요금 추전 등)에만 주로 사용하였으며 이런 용도로 사용하기 위해서는 비용보다는 신뢰성이 더 중요했기 때문에 고가의 장비와 고가의 솔루션으로 많이 해결헀습니다.
최근에는 통신 사업자가 가지고 있는 데이터, 사용자를 이용한 다양한 분석/활용을 하고자 빅데이터 기술에 접근하고 있고 일부 사업자는 몇년전부터 사용하고 있거나 NEXR과 같은 전문 회사를 인수하기도 했습니다.

- 디바이스 생산 회사
삼성전자, LG전자의 경우 과거에는 하드웨어를 만들어서 공급하는 것이 시장에서의 역할이었기 때문에 데이터를 다루는 것은 기업 내부 시스템의 데이터 위주 였습니다. 하지만 애플의 아이폰 등장과 구글의 안드로이드, 아마존의 킨들 파이어 등의 등장으로 전자 회사가 더이상 하드웨어만 공급해서는 경쟁력이 없게 되었고 하드웨어와 잘 연동되는 서비스, 컨텐츠 등을 제공해야 시장에서 살아 남는 시대가 되었습니다.
일년에 판매되는 디바이스가 수억개 이상이 되고 디바이스 자체 또는 디바이스에 탑재되는 앱에서 생산되는 데이터는 빅데이터가 되었습니다. 이렇 상황이 발생한게 불과 2 ~ 3년이기 때문에 그 동안 빅데이터에 대한 준비가 덜 되어 있는 상황입니다. 초창기에는 기존의 엔터프라이즈 솔루션으로 해결을 시도하다가 실패를 경험을 했을 것이며 최근에 오픈 소스 기반의 빅데이터 처리에 대해 관심을 가지며 내부 기술력을 내재화 시키고 있습니다.

- 외산 벤더
빅데이터라는 용어가 작년 초반을 거쳐 하반기에 폭풍같이 이슈화 되면서 가장 발빠르게 움직이고 있습니다. 기존의 BI/DW 솔루션 회사인 테라데이터, 오라클을 비롯하여 EMC, HP, IBM 등도 기존 솔루션 또는 신규 솔루션을 이용하여 공격적인 마케팅을 하고 있습니다.
하지만 빅데이터라는 것이 과거에 비용이 비싸거나 기술적으로 한계가 있고 덜 중요한 데이터를 최근에 공개된 기술을 이용하여 빠르고 저렴하게 분석 가능하게 되면서 발전되어 온 상황에서 고객들이 선듯 외산 벤더를 구매할 것인가에 대해서는 의문입니다.
물론 기존의 BI/DW 구축의 연장 선상에서 프로젝트를 진행할 경우 외산 벤더를 구매하겠지만 이것은 엄밀하게 말하면 빅데이터 라기 보다는 그냥 전통적인 데이터 분석, BI/DW 인 것입니다.
도입하는 조직의 실적이나 외부 포장을 위해 빅데이터라는 용어로 포장을 하고 있는 경우가 많고 벤더도 여기에 동조하고 있는 분위기 입니다.

- 국내 벤더
국내 소프트웨어를 개발하고 배포하는 회사 자체가 별로 없다 보니 빅데이터 관련해서 뚜렷한 솔루션 벤더는 없는 상황입니다.

- SI 사업자
국내 SI 사업자는 두가지로 관점에서 빅데이터를 바라보고 있는 것 같습니다. 하나는 기존 SI 비즈니스가 아닌 새로운 사업 진출의 기회로 삼으려는 시도입니다. 바이오 인포메틱스 등이 이런 경우입니다. 두번째는 기존 SI 사업 즉 고객에 빅데이터 분석 시스템을 구축해주는 사업니다. 전자의 경우 내부 기술력을 확보하는 어려움을 겪고 있으며 후자의 경우 SI 업종의 성격상 매출 규모가 어느 정도 발생해야 하는데 오픈 소스 기반으로 접근할 경우 매출 발생에 어려움이 있기 때문에 애매한 상황입니다.
고객과 협의가 잘되어서 전통적인 솔루션(BI/DW) 중심으로 프로젝트를 수행하면서 포장을 빅데이터로 포장하는 경우가 더 많지 않을까 생각합니다.

- 기존 국내 검색/분석 업체
다음소프트, 솔트룩스, 다이퀘스트 등과 같은 기존 국내 검색/분석 업체로 국내 업체로 가장 활발하게 빅데이터를 이용하여 시장에 참여하려는 시도를 하고 있습니다. 이 업체들은 데이터 분석에 대한 역량을 이미 확보하고 있으면 일부 데이터도 축적하고 있습니다. 하지만 필자가 보는 시각은 이런 업체들도 "빅데이터"라고 말하기 어렵습니다. 기존에 있던 방법론, 기술 등을 그대로 사용하고 있으며 분석, 처리의 비용에 대한 절감도 없으며 성능, 확장성에 대한 부분도 대부분 과거의 기술 상태라고 생각합니다. 물론 내부적으로는 연구하고 있겠지만 아직 상용 수준으로 끌어 올리기에는 부족하다고 할 수 있습니다.
이들 업체들이 세미나, 신문 보도 등을 통해 빅데이터라는 용어를 많이 언급하고 있는데 시장을 왜곡 시키고 있는 원인 중의 하나라고 생각합니다. 고객들이 과거의 전통적인 데이터 분석과 빅데이터 시대의 데이터 분석에 대해서 차이점이나 특징 등에 대해서 구분 못하는 상황이 발생하고 있습니다.

- 연구 기관
국내에 여러 국책 연구 기관 또는 대학 연구소에서도 빅데이터에 대한 연구를 시작하고 있습니다. ETRI에서는 빅데이터 관련 연구 센터가 개소 했다는 소식을 들었습니다. 연구 기관에서의 연구는 다음 항목으로 구분해 볼 수 있습니다.

. 연구 기관 중 일부는 자체 보유한 데이터가 많이 이런 데이터를 처리하기 위해 과거에 사용하는 그리드 컴퓨팅 기술에서 최근의 하둡 기반 분석을 적용하는 연구
. 소프트웨어 개발과 관련된 연구 기관으로 빅데이터를 위한 소프트웨어 플랫폼 연구 및 개발
. 과거의 데이터 분석과 비교하여 빅데이터 시대에서 다양한 데이터가 어떤 의미를 줄 수 있으며 어떤 방법, 시각으로 데이터를 분석해야 하는 지에 대한 데이터 분석 자체에 대한 연구

- 정부
최근 가장 활발하게 빅데이터 대한 토론이나 정책을 수립하고 있습니다. 작년 하반기 대통령의 관심으로 인해 급증했다고 볼 수 있습니다. 여러 국책 과제가 나오고 있지만 이를 수행하는 업체가 빅데이터에 대한 전문성을 가지고 있지 못하기 때문에 과제의 결과물 수준이 좋을 것이라고 생각하지는 않습니다.

- 신생 업체
빅데이터 기술을 바탕으로 하여 새롭게 출현하는 업체가 있습니다. KT거 인수한 NEXR이 대표적인 회사라고 할 수 있습니다. 물론 제가 속한 그루터도 빅데이터 기술을 기반으로 만들어진 회사입니다. 이런 회사는 처음부터 하둡 기반의 에코 시스템에 집중 하면서 기술을 쌓고 이런 기술을 이용하여 데이터 분석 플랫폼을 갖추는데 집중하고 있습니다. NEXR은 KT에서 인수했기 때문에 시장에서 적극적으로 참여하기 보다는 KT 내부 프로젝트에 집중하고 있는 모습입니다. 그루터는 자체 보유한 기술력과 방대한 데이터를 이용하여 데이터 분석 서비스 집중하고 있기 때문에 외부로 빅데이터 기술을 딜리버리 하는데 집중하지는 않고 있습니다. 필자의 생각에는 빅데이터라고 외치는 기술의 중심에 서 있는 부류라고 하면 기존과 다른 방식, 즉 하둡 에코 시스템 중심으로 움직이고 있는 이런 신생업체가 진정한 기빅데이터 전문 기업이라고 생각합니다.

그림2.

위의 상황을 요약해보면 현재 시장에서 빅데이터를 가장 크게 외치고 있는 부류는 "외산 벤더", "국내 검색 업체", "정부" 입니다. 하지만 실제로 빅데이터를 절실하게 필요로 하는데는 "통신 사업자", "전자 회사" 정도 뿐입니다. 그리고 이 두 부류는 전통적인 방법, 솔루션으로 어렵다는 것을 이미 몇차례의 실수로 인해 인식하고 있으며 자체 기술력을 확보하기 위해 인력 확보 및 연구를 하고 있는 상황입니다.
또 다른 관점에서 보면 과거에는 그림1에서처럼 데이터의 종류에 따라 명확하게 구분이 되었으며 각자의 영역에서 역할 분담이 잘 되었다면 빅데이터 시대에는 모든 종류의 데이터가 분석 대상이 되면서 더 많은 이해 관계자가 필요하거나 서로의 범위를 침범해야만 합니다. 특히 포털이나 인터넷 서비스 업체에서 보유하고 있는 기술, 분석 방법이 필요하지만 이들 업체는 이런 비즈니스를 하지 않거나 이제 시작하는 단계로 시장의 기대 수준을 만족시켜주지 못하고 있습니다. 그림 2에서 "?"로 되어 있는 "데이터 분석/가공자", "솔루션 제공자"의 역할을 수행할 주체가 아직 확실하게 정립되지 않은 상황입니다. 이렇다 보니 시장이 아직 혼동스러운 것이 아닌가 생각합니다.
빅데이터와 관련해서 시장 형성이 어려운 가장 큰 이유는 필자는 ROI에 있다고 생각합니다. 기업은 투자를 했으면 투자 비용 이상으로 이익을 가져와야 합니다. 전통적인 BI/DW에서 다루는 데이터는 기업의 핵심 데이터이며 이들은 비싼 솔루션을 도입하여 분석할 가치가 있는 데이터였습니다.
하지만 빅데이터에서 다루는 주요 데이터는 분석 결과가 주는 이익도 명확하지 않으며 데이터 크기나 분석에 투입되는 리소스는 훨씬 더 많습니다. 빅데이터라는 개념이 출현하게 된 것도 하둡 에코 시스템을 기반으로 한 저렴한 비용으로 빠르게 분석할 수 있는 체계가 구성되었기 때문에 투자 금액을 작게해서 분석이 가능하기 때문입니다. 분석 결과가 주는 이익이 작거나 불분명해도 기업 입장에서는 투자할 가치가 있다는 것입니다. 오라클이 빅데이터 어플라이언스라는 제품을 출시하면서 제품의 구성 대부분을 하둡 에코 시스템인 오픈 소스로 배치시키고 가격도 50만불 수준으로 비교적(?) 저렴하게 출시한 것도 시장의 요구가 이렇다는 것을 알기 때문입니다.
하지만 국내에서의 빅데이터를 움직이는 주요 참여자는 외산 솔루션 벤더나 기존 검색 사업자인데 이들의 비용 구조는 변함없는 고비용 구조입니다. 이런 상황에서 기업이 선뜻 투자하기는 어려울 것입니다. 그래서 일부 기업은 자체 기술력 확보에 주력하고 있기도 합니다.

최근 빅데이터가 시장에 관심을 받으면서 "그루터 돈 많이 벌었겠네요." 라는 이야기를 많이 듣고 있습니다. 상황을 다음과 같이 정리해보겠습니다.

인력 투입 방식 프로젝트
- 데이터 분석 플랫폼을 갖추기 위해 그루터에 프로젝트 참여 요청
- 프로젝트가 구축 사업 중심이다 보니 인력 투입 요청
- 인력 단가 많아야 1000만원/월, 심지어 어떤 경우는 600 ~ 700만원/월
- 적절한 수익을 유지하기 위해서는 200 ~ 300만원/월 정도 되는 인력을 많이 투입시키고 핵심 인력 몇명으로 프로젝트를 수행하게 방법이 있지만 그루터의 회사 비전에 맞지 않기 때문에 이런 방식의 계약은 지양
- 현실적인 비용 요구
- 발주 회사 내부 규정 상 어려움이 있음. 검증되지 않은 벤처 인력에 많은 비용을 지불할 수 없음. 외국 회사는 가능
- 프로젝트 참여하지 않는 것으로 결정

솔루션 납품 프로젝트
그루터는 하둡 에코 시스템을 이용하여 빅데이터 플랫폼을 구축하고 모니터링 할 수 있는 솔루션인 BAAS와 Cloumon 보유
- 솔루션 제시
- 레퍼런스 부족(가장 최신의 기술을 도입하면서도 레펀러스를 요구하는...)
- 일단 레퍼런스 문제는 해결
- 가격 협상 -> 구매 부서에서 빅데이터 대한 접근 보다는 기존 솔루션과의 기능, 가격비교
(기존 로그 분석 시스템은 수백만원 정도면 도입 가능한데 기능적으로는 비슷한 것 같은데 왜 그렇게 비싸냐?)
- 오픈 소스 기반의 소프트웨어 스택 제공에 대한 이해 부족
- 솔루션 납품뿐만 아니라 컨설팅도 같이 요구
- 컨설팅에 대한 비용 산정의 앞의 인력 투입 방식에서와 동일한 문제 발생
- 솔루션 납품 실패

크게 이런 두가지 상황으로 나누어 집니다. 물론 도입에 적극적인 고객이 있어 BAAS, Cloumon 등은 레퍼런스도 확보 했으며 인력 투입 프로젝트로 몇군데 수행을 했습니다. 하지만 지금의 빅데이터의 바람에 비하면 실제 프로젝트까지 연결되는 것은 많지 않았습니다.

빅데이터 시장은 여전히 안개속이지만 빅데이터에 대한 제대로된 이해와 기술을 중심으로 접근하기 보다는 기존 사업자들에 의해 왜곡된 형태로 진행되고 있는 것 같아 안타깝습니다. 이런 시장 상황으로 지속되면 비싼 솔루션만 잔뜩 도입하고 결과는 내지 못하는 시행착오를 겪으면서 빅데이터 시장 자체가 붕괴되지 않을까 하는 걱정입니다.
빅데이터를 제대로 하기는 방법은 단 하나입니다. 하둡 에코 시스템에 대한 기술력을 쌓고 이를 기반으로 한 플랫폼을 갖추고 데이터를 축적 시키고 데이터를 분석하는 것입니다. 다른 길은 없습니다. 그 정도 규모의 데이터가 아니면 고민 없이 전통적인 솔루션을 도입하면 됩니다. 단, 전통적인 솔루션, 기법을 도입해 놓고 빅데이터로 포장은 하지 마세요. 시장이 왜곡됩니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

SI 구축 사업자와 클라우드 컴퓨팅 서비스

(김형준) — Tue, 21 Feb 2012 15:30:49 +0900

삼성, 야심찼던 S클라우드 없던일로… 라는 기사를 보니 그동안 생각을 좀 정리해야 할 것 같아서 간단하게 적어 보았습니다.
http://media.daum.net/economic/newsview?newsid=20120219180310657

본 컬럼은 이 기사에 나와 있는 내용과는 무관합니다. SI 구축 사업자가 클라우드 컴퓨팅 서비스를 만들때 얼마나 어려운지에 대한 제 생각을 정리한 내용입니다.

SI 또는 시스템 구축 사업자라고 할 수 있는 업의 특성을 이해하면 SI 중심의 회사에서 이런 클라우드 서비스를 만드는 것이 얼마나 어려운 것인가를 알게됩니다. 대외 시스템 구축 사업은 대부분 고객으로부터 요구사항과 그 요구사항을 실현하기 위한 비용을 받아 프로젝트가 수행됩니다. 시스템 구축 사업자는 이런 프로젝트를 수주하기 위한 영업 비용만 집행하고 그 영업 비용도 프로젝트 바용에에 포함하는합니다. 따라서 회사의 운영 비용 자체가 시스템을 구축하고 납품해주는 고객으로부터 나오고 있습니다.

그러면 클라우드 컴퓨팅 서비스와 같은 서비스 중심의 업종은 어떨까요? 고객이 있기는 하지만 고객이 특별한 요구사항을 주는 경우는 없습니다. 대부분은 서비스 제공자가 자신이 서비스할 서비스의 기획안을 만들고 그 기획안을 기반으로 서비스가 만들어 집니다. 비용도 특정 고객으로부터 지불되기 보다는 수많은 작은 고객으로 부터 지불된다고 할 수 있습니다. 즉, long tail 비즈니스 영역이라고 할 수 있십니다. 물론 S클라우드의 삼성전자(고객) - 삼성SDS(서비스 사업자)의 관계에서는 전혀 다른 관계가 형성되어 있지만 말입니다.

이렇듯 클라우드 컴퓨팅 서비스는 SI 사업자가 잘하는 영역이 아니고 전혀 새로운 영역입니다. 서비스를 구축하는 비용도 자체 내부 투자로 이루어져야 하며 투자 비용도 큽니다. 구축 기간도 시범 서비스만 나오는데 1년 이상이 걸리고 안정화 시켜 정상적인 서비스로 넘어서기에는 2 ~ 3년 이상이 소요될 수도 있습니다. 전통적인 SI 사업자가 투자할 수 있는 비용과 기간을 넘어섭니다. 즉, 잘할 수 있는 영역이 아니라는 겁니다. SI 구축 사업자가 클라우드 서비스를 하기 어려운 이유를 적어 보았습니다

- 시스템 구축이 아닌 서비스 관점에서 접근해야 하는데 서비스 기획력에서 경험 부족
- 자체 핵심 기술력을 가지고 있어야 하는데 많은 부분에서 아웃소싱에 의존
- 인프라 서비스 등의 경우 자체 서비스 또는 자체 시스템에 적용하면서 개선 시켜나가야 하는데 SI 회사 내부에는 시범 적용할 자체 서비스 등이 부족(아마존의 경우 amazon.com에 적용한 기술을 진화 시켜 클라우드 서비스 모델로 발전)
- 투자 비용에 대한 인식 문제(대부분의 프로젝트가 고객에서 비용 지불) - 단기간에 프로젝트 성과를 이루고 싶어 하는 조직 문화
- 일반화된 시스템을 만드는 것보다 특정 고객의 요구사항에 부합되는 시스템 구축 경험이 더 많음

SI 사업자가 이런 문제를 극복하기 위해서는 문제를 제대로 인식하고 기존과는 다른 조직문화, 관리문화, 투자문화, 개발문화를 만들어 내야 하지 않을까 생각합니다. 최근 SI 사업은 소프트웨어 산업과는 차별화된 다른 영역이라고 주장하고 있는데 맞는 주장입니다. 이런 주장을 되집어 보면 소프트웨어 개발이나 서비스 개발에는 SI 사업자가 잘 맞지 않는 것을 스스로 인정하고 있는 것입니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

빅데이터란 무엇이고 어떻게 해야 할까?

(김형준) — Mon, 02 Jan 2012 23:59:10 +0900

모두들 새해 복많이 받으세요.

2012년 새해 첫 포스팅입니다. 많은 이슈가 되고 있는 빅데이터에 대해 간단하게 제 의견을 정리해 보았습니다. 본문의 내용은 지극히 개인적인 의견일뿐입니다. 잘못된 부분도 있을 수 있고 왜곡된 부분도 있을 수 있습니다. 태클은 댓글로 남겨주세요.

빅데이터 개요
2011년 하반기부터 빅데이터라는 용어가 해외 블로그 또는 저널로부터 나오기 시작했습니다. 국내에서도 이 시기에 언론에서 빅데이터에 대해 관심을 가지면서 관련 기사들이 나왔습니다.
필자는 몇년 동안 Hadoop, NoSQL 등과 같은 분야를 연구하고 있었지만 이런 기술셋들에 대해 정확하게 분류할 수가 없었습니다. 2006년 처음 시작할 때에는 분산컴퓨팅, 그리드 컴퓨팅이라는 용어로 시작했는데 뭔가는 맞지 않는 부분도 있었습니다.
Hadoop의 경우 분산 파일 시스템 분야와 분산 처리 분야에 속해 있고 NoSQL은 분산 데이터 베이스에 속해 있었다고 할 수 있죠. 2008년부터 클라우드 컴퓨팅이라는 새로운 용어가 나오면서 가상화 기술(서버 가상화, 스토리지 가상화 등) 들을 비롯한 여러 기술 분야가 클라우드 컴퓨팅을 구현하기 위한 기술 분야로 묶이게 되었습니다. 이때 Hadoop, NoSQL 등도 클라우드 컴퓨팅이라는 용어로 묶이는 분위기였습니다.
클라우드 컴퓨팅을 구현하기 위해서는 서버 가상화뿐만 아니라 VM 이미지나 VM에 마운트 시킬 수 있는 디스크 또는 스토리지 등의 기술이 필요했으며 사용자의 파일 등을 서비스할 수 있는 오브젝트 스토리지 기술도 필요하게 되었습니다.
또한 이렇게 저장된 데이터를 분석하는 기술도 필요하고요. 데이터베이스도 기존의 하나의 서비스만을 위한 데이터베이스가 아닌 하나의 큰 인스턴스로 여러 업무 여러 사용자에게 서비스하는 클라우드 개념을 지원하는 데이터베이스 기술도 필요하게 되었습니다.
이런 이유 때문에 Hadoop, NoSQL 등이 클라우드 컴퓨팅의 한 기술 분야로 정리되지 않았나 생각합니다.
그래도 이 기술 자체만으로는 클라우드의 개념과는 약간은 거리가 있는 듯한데 2010년말 ~ 2011년에 이르러 이런 기술을 정의 내릴 수 있는 용어가 나왔는데 바로 빅데이터입니다. 기술적인 측면이 아닌 데이터 적인 측면에서도 정의를 하겠지만 빅데이터라는 용어를 등장시킨 결정적인 기술이 Hadoop, NoSQL이 아닐까 생각합니다.

빅데이터 정의
그럼 빅데이터에 대한 정의를 간단하게 내려 보겠습니다. 이것도 클라우드 컴퓨팅이라는 정의와 함께 많이 오해하고 있는 용어 중의 하나인 것 같습니다. 지금까지 제가 살펴본 여러 컬럼이나 문서를 통해 보면 다음과 같이 정의할 수 있을 것입니다.

"빅데이터란 시스템, 서비스, 조직(회사) 등에서 주어진 비용, 시간내에 처리 가능한 데이터 범위를 넘어서는 데이터이다."

정의는 제 주관적인 정의입니다.
위 정의에서 좀 더 자세하게 짚고 넘어 가야 할 부분이 있습니다. 먼저 "처리" 라는 용어입니다. 이 부분이 국내 많은 개발자나 언론, 회사 IT 담당 부서에서 혼동하고 있는 부분이 아닐까 합니다.
"처리"는 단순히 배치 분석 작업을 의미하는 것이 아닙니다. 즉 기존의 BI/DW 등에서의 데이터 웨어 하우스만을 의미하는 것이 아니라는 것입니다. 실시간으로 처리되는 데이터도 같이 포함하고 있는 개념입니다.
예를 들어 국내에서만 서비스되는 쇼핑몰이 있습니다. 이 쇼핑몰은 하루에 수백만명의 제품 검색, 구매 요청을 처리 가능합니다. 이 서비스를 아시아권으로 확대 서비스 했을 때에도 사용자의 요청을 처리할 수 있을까요?
서비스 개발에 조금이라도 아는 사람이라면 안된다는 것을 알 것입니다. 사용자가 늘어나면 사용자의 실시간 검색 요청, 구매 요청 등에 대응하기 위해 여러 부분이 바뀌어야 합니다. 웹 서버의 용량, 네트워크 증설, 세션 처리 용량 등이 필요합니다.
이런 증설에서 가장 중요한 부분이 데이터에 대한 부분일 것입니다. 검색도 데이터에 대한 내용이고 구매한 이력을 저장하는 것도 데이터에 대한 내용입니다. 상품을 추천하는 것도 구매한 정보를 이용하여 분석하여 다시 피드백을 주는 데이터에 대한 내용입니다.
빅데이터에서의 "데이터 처리"의 개념은 이렇게 단순 분석이 아닌 사용자의 모든 데이터 요청 유형을 의미하는 것입니다.
그러면 일반적인 데이터와 빅데이터를 나누는 기준은 무었일까요? 이 부분에 대한 답이 앞에서 정의한 빅데이터 정의 부분에서 "비용/시간"이라고 볼 수 있습니다. 그리고 "비용/시간"은 어떤 기술을 사용할 것인가를 결정하는 요소입니다.
데이터를 처리하는데 있어 기업이 투자 가능한 비용의 범위 내에 있으면 빅데이터라고 하지 않습니다. 예를 들어 하루에 수억건 발생하는 이동통신회사의 콜 데이터를 저장하기 위해 이동통신회사는 수십억 ~ 수백억의 비용을 지불해서 고가의 하드웨어, 고가의 데이터베이스 솔루션에 투자하는 것이 가능하다고 하면 그것은 빅데이터라고 보기 어렵습니다.
현재에도 많은 통신회사가 이런 방식으로 과금 시스템이 구축되어 있습니다. 통신회사가 이렇게 비용을 지불할 수 있는 것은 다루는 데이터가 과금에 사용되는 가장 중요한 데이터이기 때문이겠죠. 이런 중요한 데이터를 저장, 처리하는데 기업들은 기꺼이 비용을 지불할 것입니다.
그러면 동일한 데이터이지만 이렇게 저장된 데이터를 이용하여 과금보다는 조금 덜 중요한 기지국의 증설, 통화 품질 등을 분석하는 자료 중의 하나로 활용하는 경우라면 어떨까요? 그리고 기지국의 증설, 통화 품질 분석 등을 위해서 사용자 콜 정보 이외의 다른 여러가지 부가 정보도 같이 사용되어 진다면 앞에서와 같이 사용자 콜 데이터를 저장, 분석하는데 수십 ~ 수백억의 비용을 지불하면서 시스템을 구축할 수 있을까요?
즉 같은 데이터라도 기업에게 어느 정도로 중요하고 그 중요성 만큼의 비용을 지불할 수 있는 수준을 넘어서는 데이터를 다루는 기술을 빅데이터라고 할 수 있습니다. 과거에도 사용자 콜 데이터를 저장하고 과금 처리를 하고 있었는데 이를 빅데이터라고는 하지 않습니다.
따라서 빅데이터를 다루는 기술은 기본적으로 기존의 데이터 방식에 비해 구축 및 운영 비용이 매우 저렴한 기술이라야 합니다.

빅데이터의 특징을 이야기 할때 다음 세가지 특징을 많이 이야기 합니다.

- volume: 데이터의 크기인데 물리적인 크기 보다는 앞에서 설명드린 크기에 대한 내용입니다. 웹 로그 데이터나 한메일, gmail 등의 메일 MIME 데이터는 수 PB 이상이 되지만 트위터 네트워크 데이터는 수십 GB 미만입니다. 앞의 데이터는 안정적인 저장이 가장 큰 해결 과제인 반면 네트워크 데이터는 분석 및 처리가 가장 큰 이슈입니다. 따라서 단순히 물리적인 크기가 아닌 데이터의 어떤 속성이 더 중요하고 그것을 처리하는데 어려움이 있느냐 없느냐 입니다.

- velocity: 데이터를 처리하는 속도입니다. 정의 부분에서도 설명했듯이 배치 분석만을 의미하는 것이 아닙니다. 필요에 따라서 수 많은 사용자 요청을 실시간으로 처리한 후 처리 결과를 반환해주는 기능도 필요합니다. -

various: 전통적인 기업의 데이터 분석은 기업 내부에서 발생하는 운영데이터인 ERP, SCM, MES, CRM 등의 시스템에 저장되어 있는 데이터베이스 데이터 였습니다. 이런 데이터는 잘 정제되어 있고 의미도 명확합니다. 최근에는 이런 데이터뿐만 아니라 기업 외부에서 발생하는 SNS, 블로그, 뉴스, 게시판 등의 데이터나 사용자가 업로드 한 파일, 콜 센터의 고객 상담 내용 등 비정형 데이터도 처리할 수 있는 능력이 있어야 합니다.

그러면 이런 빅데이터는 어떤 회사가 주도하고 있을까요? 지금까지의 소프트웨어는 Oracle, IBM, HP, MS 등과 같은 미국의 소프트웨어 회사 중심이었다면 클라우드 컴퓨팅 이후부터의 기술은 인터넷 서비스 업체인 Google, Yahoo, Facebook, Amazon 등이 주도적으로 이끌고 있습니다.
전통적인 소프트웨어 회사는 그 기술 자체가 회사의 경쟁력이고 판매 되는 상품이었기 때문에 공개되지 않았습니다. 하지만 인터넷 서비스 업체는 기술 자체로 비즈니스를 하는 것이 아니라 그 기술을 이용한 서비스로 비즈니스를 하기 때문에 기술 공개에 있어 자유롭다고 할 수 있습니다.
그리고 이런 회사들이 진정한 빅데이터를 다루고 운영하는 경험이 있는 회사라고 할 수 있습니다. 따라서 빅데이터는 전통적인 소프트웨어 벤더에 의해 만들어진 시장이 아니라 글로벌 인터넷 서비스 업체들에 의해 만들어진 시장과 기술입니다.

관련 기술
그러면 빅데이터를 다루는 기술들은 어떤 것들이 있을까요? 빅데이터라는 용어를 이끌어 낸 것도 Hadoop과 NoSQL의 성공에 있다고 볼 수 있기 때문에 가장 중요한 기술은 Hadoop 이라고 할 수 있습니다.
Hadoop 자체는 파일 시스템과 분산 처리 플랫폼이지만 Hadoop을 중심으로 다양한 에코 시스템이 구축되면서 이제 Hadoop은 빅데이터에 있어 산업계 표준이라고 할 수 있습니다.
다음은 빅데이터를 다루는데 필요한 기술입니다.

- 원본 데이터 저장: 대용량 분산 파일 시스템(Hadoop File System 등)
- 구조적 데이터 저장: 대용량 분산 데이터 저장소(NoSQL-HBase, Cassandra, MongoDB 등)
- 배치 분산 병렬 처리: MapReduce(Hadoop), 그래프 분석(Pregel, GlodenORB 등)
- 데이터 스트리밍 프로세싱: S4, Storm
- 데이터 마이닝: Mahout
- 다양한 데이터 분석 알고리즘
- 기타: 분산 관리(ZooKeeper), 분산 큐(kafka), 분산 캐쉬(Memcached, Redis),
- 기존 전통적인 솔루션: BI/DW, RDBMS 등
- 데이터 분석 기술

이런 기술이 필요에 따라 적절하게 도입되어야 빅데이터를 처리할 수 있는 시스템을 구축할 수 있습니다. 언급한 기술 하나하나 쉽지 않은 기술이며 아직 성숙되지 않은 기술도 많습니다. 다행인것은 대부분 오픈소스로 코드가 공개되어 있고 기술이 많이 공개되어 있다는 것입니다.
여러 기술이 있지만 이 중 가장 중요한 기술은 마지막에 있는 어떤 데이터를 분석할 것인가를 정의하고 데이터간의 관계를 찾아서 의미 없는 데이터로부터 의미를 찾아내는 기술이 가장 중요한 기술입니다.
이 기술은 솔루션이 아닌 사람의 기술입니다. 기업이 빅데이터 처리를 도입하는데 있어 닭이 먼저냐, 달걀이 먼저냐라는 논의가 여기서 나오지 않나 생각합니다.
시스템을 구축하는 기업 입장에서는 "무엇"과 "효과"를 알아야만 시스템 도입을 진행할 수 있지만 국내에는 아직까지 데이터 분석을 잘 할 수 있는 전문가는 많지 않습니다. 따라서 기업에게 "무엇"과 "효과"를 명확하게 제시할 수 있는 경우가 많지 않습니다. 그러면 사람을 키워야 하는데 데이터를 다루는 사람을 키우기 위해서는 데이터를 자주 보게해야 하고 데이터를 만지는 것이 쉬워야 합니다.
그러기 위해서는 빅데이터를 처리하는 시스템을 구축해야 하기 하는데 투자를 위해 다시 "무엇"과 "효과"로 돌아오게 되는 겁니다.

시스템 구축 방안
빅데이터 시스템 구축에 있어 어려움은 시스템 구조가 너무 복잡하다는 것 입니다. 앞에서의 기술에서 보듯이 하나의 솔루션으로 구축되는 것이 아니라 여러 개의 솔루션이 조합되어야 하고 요구사항에 따라 솔루션 선택도 달라지게 됩니다.
일반적으로 운영조직은 복잡한 시스템 구성을 좋아하지 않습니다. 이유는 당연히 운영의 어려움(비용증가)와 장애때문일 것입니다.
과거에 전통적인 시스템은 주로 웹서버(Apache), 애플리케이션서버(Tomcat, JBoss, Weblogic), 데이터베이스(Oracle, MSSQL, MySQL) 등의 구조로 시스템이 구축되어 운영이나 장애 발생에 쉽게 대응할 수 있었습니다.
하지만 빅데이터를 다루기 위해서는 이런 단순한 구조로 시스템을 구축할 수 있다는 생각을 버려야 합니다. 앞에서 설명했듯이 "무엇"과 "효과"에 대해서는 잘 모르겠고 전문가(시스템, 데이터 분석 모두)도 부족한 상황입니다.
구축 하고자 하는 시스템의 복잡도는 과거의 시스템에 비해 비교도 안될 정도 복잡합니다. 기술도 어렵고 전문 기술 지원 회사도 부족합니다. 글로벌 솔루션 회사들의 솔루션은 대부분 고가의 솔루션으로 빅데이터라는 정의에 부합되지 않습니다. 그러면 어떻게 시스템을 구축하고 전문가를 키워나갈 수 있을까요?
다음은 필자가 생각하는 빅데이터 시스템을 구축할 수 있는 최적의 방안입니다.

국내 새롭게 구축되는 대부분의 시스템은 멋진 청사진과 ROI를 내세우며 단기간의 성과에 치중한다. 앞에서 거듭 이야기한 것처럼 빅데이터는 소프트웨어의 종합 선물 세트이며 예술의 경지에 가깝다고 할 수 있다. 멋진 청사진보다는 내실을 다지는 쪽으로 방향을 잡아야 한다.
먼저 현재 나온 솔루션 중에서 가장 안정적이면서 레퍼런스도 풍부하고 엔지니어링 소싱도 다소 쉽다고 할 수 있는 Hadoop File System과 MapReduce를 도입하여 기업에서 필요할 것 같은 데이터를 저장한다.
저장된 데이터를 hive 등과 같은 쉬운 인터페이스를 이용하여 처리할 수 있는 체계 정도만 구축한다.
여기까지 구축 되면 이제는 엔지니어링 분야가 아닌 데이터를 다루는 분야의 사람이 개입되어 데이터를 여기 저기 뜯어 보고, 해체하고 조합하는 과정을 거치면서 "무엇"에 대한 정의를 할 수 있는 역량을 키운다.
이 단계가 지나면 엔지니어링 분야에서는 분산 시스템에 대한 적용 및 운영 능력이 쌓이게 되고 데이터 분석 분야에서는 데이터가 어떤 모양을 가지고 있고 우리 기업이 필요로 한 데이터가 어떤 데이터인지를 조금씩 알 수 있게 된다.
즉 학습이 되고 학습된 결과가 효과를 거두는 시기가 온다. 이렇게 되면 데이터 분석 분야에서는 구체적인 요구사항을 엔지니어링 쪽으로 알려줄 수 있고 엔지니어링에서는 앞에서 설명한 다양한 기술을 조합하여 이 요구사항에 부합되는 시스템을 구축하여 운영할 수 있게 된다.
이런 사이클은 한번에 끝나는 것이 아니라 지속적으로 기업의 활동과 함께 진화해 나가게 된다.

방안의 핵심은 쉬운것부터, 욕심을 버리고, 지속적으로 할 수 있는 체계를 갖추는 것입니다. 이렇게 하기 위해서는 기업 내부에서 투자를 결정하는 의살결정권자의 전폭적인 지지와 관심이 있어야만 가능합니다.
기존의 방식처럼 특정 사업부에 맞기고 그 사업부의 임원의 성과로만 치부해버리면 단기간의 화려한 성과에 매달리게 되고 주변의 도움도 받지 못하게 됩니다. 가능하면 CEO 또는 CTO 직속으로 조직을 두고 여러 사업부에 영향력을 행사할 수있는 임원급에게 업무를 할당하는 것이 성공의 첫 단추입니다.
전사적인 부서로 두어야 하는 필요성 중의 하나는 여러 부서로부터의 데이터를 수집해야 하고 처리된 결과를 다시 필요로 하는 부서로 제공해야 하기 때문이기도 합니다.

그 다음은 내부에 엔지니어링 조직을 갖추는 것입니다. 많은 기업이 IT 관련 부분은 아웃 소싱으로 처리하고 있습니다. 빅데이터는 한번의 프로젝트로 완료되는 것이 아니라 지속적으로 운영, 개선해나가야 하는 것이 가장 중요하기 때문에 내부에 엔지니어링 조직을 갖추는 것이 가장 좋습니다.
물론 비용이 많이 든다고 생각할 수도 있지만 회사의 규모에 따라 다르겠지만 앞에서 언급한 기술을 유지하는 수준이라면 뛰어난 인력 3 ~ 5명 정도를 핵심으로 구성하고 필요에 따라 아웃소싱할 수 있습니다.
문제는 3 ~ 5명의 팀을 제대로 구성하기 위해서는 전통적으로 지급되었던 급여 수준보다는 높은 수준의 급여를 지불해야 할 것입니다. 그 수준에 맞는 인력을 채용해야 합니다.
자체 엔지니어링 팀 구성이 어려우면 아웃소싱이 대안이 될 수 있습니다. 아웃 소싱의 경우에도 앞에서 높은 기술력을 유지하고 있는 회사를 소싱해야 하며 엔지니어링 분야 뿐만 아니라 데이터 분석 분야도 같이 다룰 수 있는 회사를 소싱해야 합니다.
그리고 지속적인 관계를 유지할 수 있는 회사라야 할 것입니다.

데이터 특성을 고려한 시스템
빅데이터 시스템을 구축하는데 있어 한가지 더 중요하게 생각해야 될 점은 "데이터의 특징에 맞는 시스템을 구축해야 한다"라는 것입니다.
일반적으로 데이터의 특징은 다음과 같습니다.

- Consistency 저장된 데이터는 모두에게 같은 데이터가 보여야 한다.
- Availability 언제든지 데이터를 저장/조회할 수 있어야 한다.
- Durability 저장된 데이터는 안정적으로 저장되어야 한다.

현재의 데이터 저장 솔루션(DBMS)은 이런 속성을 잘 만족시키고 있습니다. 그렇기 때문에 고가인 것입니다. 빅데이터 처리에 있어서도 반드시 이 속성을 만족해야 하는지 검토해 봐야 합니다.
페이스북 서비스를 보면 Consistency는 일부 포기하고 있습니다. 내가 쓴 글이 나에게는 보이는데 내 친구에게는 일정 시간 내에는 안보이는 경우도 있습니다. 이것은 서비스 측면에서 Consistency보다는 다른 속성을 더 중요하다고 판단했기 때문에 Consistency 속성을 일부 희생한 것입니다.
국내 서비스 기획자나 의사 결정권자는 절대 받아들이지 않을 속성일 것입니다. 하지만 이제 변해야 합니다. 페이스북이 Consistency 속성을 버린 이유는 그 속성을 유지하는 것보다는 그 속성을 일부 희생하더라도 10억명의 사용자 글을 받아주는 기본 기능이 더 중요했기 때문일 것입니다.
이렇듯 구축하고자 하는 시스템에서 중요하게 생각하는 속성이 무엇인지를 정의하고 그것에 따라 시스템을 구축해야 합니다. 모든 속성을 다 만족하고 몇억명의 사용자에게 서비스되고 안정적으로 운영되는 시스템을 구축하기를 원하는 의사결정권자의 바램은 바램일뿐입니다. 현재의 기술로는 불가능하다고 할 수 있습니다.
중요한 하나를 취하고 덜 중요한 하나를 버리는 의사결정이 필요한 시대입니다.

결론
마지막으로 빅데이터 시스템을 구축하는데 있어 중요한 몇가지를 정리 했습니다.

- 빅데이터는 단순히 많은 데이터를 분석하는것이 아니다.
- 분석뿐만 아니라 시스템, 서비스 자체가 이미 빅데이터에 대한 적응능력이 있어야 한다. - 시스템,서비스를 기획,개발,운영하는 조직도 빅데이터를 다루는 능력이 있어야 한다.
- 빅데이터는 하나의 솔루션으로 해결할 수 없으며 요구사항, Data의성격 등에 따라 다양한 솔루션으로 조합되어야 한다.
- 오픈소스 중심의 소프트웨어 스택을 구축, 운영하기 위해서는 내부 기술력을 갖추어야 한다. 외부시스템 구축 회사나 벤더에 의존해서는 안된다.
- 한번 구축하고 관리만 하면 되는 시스템이 아니라 지속적으로 진화시켜 나가야 하는 시스템이다.
- 단기간(6개월~1년 이내)에 전체 시스템을 구축하고자 하는 욕심은 버려야 한다.
- 처음의 실패를 두려워하지 말고 지속적으로 기술 내재화 및 시스템을 진화시켜야 한다.
- 오픈 소스 검증에 시간을 낭비하기 보다는 작게라도 실행에 옮기는 것이 중요하다.

많은 연구기관에서 2012년에 떠오르는 기술중의 하나로 빅데이터를 꼽고 있습니다. 기업의 경쟁력을 높이는 방법 중의 하나로 데이터 분석의 시대가 오고 있는 것은 사실이지만 쉽지 않은 기술임에는 틀립없습니다.
이런 분위기를 글로벌 소프트웨어 업체들이 편승해서 자사의 솔루션 판매에 열을 올리고 있습니다. 물론 이런 솔루션이 도움은 줄 수 있을 겁니다. 기업에서 고민하는 운영이나 기술 지원의 문제도 어느 정도는 해결해 줄 수 있을 겁니다. 하지만 데이터의 시대에서는 그 어떤 시스템보다도 데이터 그 자체에 대한 이해가 가장 중요하며 이것은 쉽게 얻을 수 있는 것은 아니라는 사실은 반드시 기억해 주시기 바랍니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.