기본 콘텐츠로 건너뛰기

Cloud Computing + Personal + Big Data

2010년도 부터인가? IT 시장의 화두가 클라우드 (Cloud) 였다. 전 세계의 모든 IT 업체들이 클라우드 컴퓨팅 전략을 발표했고, 실제로도 IT 환경은 변화되고 있는 중으로 보인다.

2012년을 지나 이제 2013년이다. 아직도 클라우드 컴퓨팅 이슈는 살아 숨쉰다. 다만, 실제 클라우드 컴퓨팅으로 IT 업계가 생각만큼의 실적을 가지지 못한 것으로 보인다. 그리고 이슈의 중심도 클라우드 자체라기 보다는 Big Data 나 Personal Cloud 로 변화되고 있는 듯 하다.

그럼 Big Data라는 것은 무엇일까?

지금은 정보의 홍수 속에 뭍혀서 모든 사람들이 지내고 있다. 의미있는 데이터와 전혀 의미없는 데이터까지 정말 정보의 바다에 빠진 것 같다.

클라우드 컴퓨팅이 기반이 되어 이런 넘쳐나는 데이터들에서 의미있는 데이터들을 만들어내는 것이 “Big Data” 의 본질이 아닐까 한다.

많은 정보의 처리와 분석에 대한 베이스로서의 클라우드와 사용자들이 사용하는 다양한 스마트 기기들 (스마트 폰, 타블렛 PC 등) 을 한 곳의 접점으로 모아줄 수 있는 Personal Cloud 와 SNS 기반의 정보 교류를 가능하게 하는 정보 유통뿐만 아니라 개인들에 맞춤화된 정보 제공인 Big Data 까지…

결국 모든 IT 이슈들이 자체적인 것을 벗어나 점차 융합되고 연결된 모습으로 양상을 바꿔가고 있는 것으로 보인다.

이미 우리들은 알게 모르게 Big Data의 속에 있다.
기업들은 보다 유용한 정보를 가공해서 소비자에게 제공하여 이윤을 창출하고 있고, 개인들 역시 제공되는 정보를 통해서 보다 정제된 정보를 제공받을 수 있기 때문이다.

따라서 기업의 경영 패터다임과 기업 환경의 변화에 발 맞춘 Big Data 분석의 기술 이슈에 대한 검토와 검증이 필요한 시점이다. 어쩌면 이미 늦은 것일 수도 있다.

그럼 실제 Big Data라는 것은 어떻게 사용되고, 어떤 문제점이 존재하는지를 알아보도록 하자.

가장 기본적인 Big Data 의 사용 사례는 트위터에서 특정 정치인이나 유명인사의 여론을 분석하거나, 시 제품 또는 신 제품에 대한 반응을 분석하는 것들이다. 물론 기업이나 포털등에서는 더욱 다양한 형태로 Big Data가 활용되고 있다.

그럼 이런 사례에 존재하는 문제는 무엇일까? 

단순하게 생각해 봐도 SNS  에 존재하는 트윗이나 리트윗 같은 방대한 양의 비 정형 데이터들을 어떻게 취합하고, 의미있는 정보로 가공하기 위해서 거의 실 시간으로 분석할지에 대한 의문이 생긴다.

이런 문제를 해결하기 위해서 클라우드 기반의 분산 플랫폼, 인 메모리 데이터베이스, NoSQL 기술 등의 Big Data 처리 플랫폼과 시맨틱 분석 기술, 신경망 등의 인공지능 기술 등 데이터 분석 기술들이 모두 적용되어야 한다. 그리고 이런 데이터를 정형화된 정보처리 체계와 통합하고, 해석된 결과를 정보의 소비 주체인 사용자들에게 이해하기 쉬운 형태로 제공되어야 한다.

앞으로는 더욱 확장되어 일반 제품의 판매와 유통에도 Big Data 활용의 중요도는 점점 높아질 것이며, 사용자 또한 적극적으로 Big Data 의 정보를 활용하여 의사 결정을 하게 될 것이다. 물론 사용자는 이것이 Big Data 를 통한 정보인지를 인식하지는 못하겠지만…

현재는 어디까지?

이미 오라클, 마이크로소프트, 테라데이타, SAS, SAP 등과 같이 분석 솔루션을 가지고 있는 업체들은 Big Data 분석 도구에 대한 홍보에 열을 올리고 있고, 물 밑 경쟁이 치열하게 진행되고 있으며, 아마존에서도 Big Data 분석 서비스를 출시해 경쟁이 더 치열해 질 것이라고 예측을 하고 있다.

항상 모든 새로운 기술 트렌드가 나오면 다들 난리가 난다. 외산 대형 벤더들의 거품낀 공세와 이런 저런 상황을 검토하지도 않고 무조건 따르려는 관련 단체들까지 가세해서 엉뚱한 방향으로 혼돈의 결과를 만들지 않을까 하는 걱정이 되는 것을 무시할 수 없다. 이미 혼탁해진 것을 느끼는 것은 나만일까??

아직 미래를 논할 수 있는 단계는 아니지만, 명백하게 흐름은 갈 수 밖에는 없다고 본다. 그러나 이런 것들이 트렌드로서 향후 방향이 된다는 것은 부인할 수 없다.

Big Data 는 정말 Big 이어야 하나?

과거에 데이터의 분석이라고 하면 데이터 마이닝 팀이 주도적으로 진행을 했고, 여기서 많은 병목 현상이 발생했다. 당시의 장비와 소프트웨어로 많은 데이터를 원하는 대로 분석하는 것이 쉽지는 않기 때문이다.

그러나 지금의 Big Data는 개발자들이 직접 Hadoop (분석) 이나 NoSQL (실시간) 을 이용해서 데이터를 분석할 수 있는 기회가 제공되고 있다. 더 이상은 전문 데이터 마이너가 아니더라도 운영이 가능하기 때문에 좋은 점이라고 볼 수도 있다.

이런 상황들 때문에 데이터 사이언티스트 (Data Scientist)라는 말도 같이 각광받고 있다. 즉, 데이터 개발자라는 것도 하나의 직군으로 생길 수 있다는 말이다.

“가장 좋은 기술은 쉬운 기술이다.” 라는 말이 있다.

현재 웹이 성공한 이유는 일반인도 웹 페이지 개발이 가능한 수준으로 기술에 대한 접근성이 제공되기 때문이다. 쉬운 사례로 요즘의 블로그는 일반인이 자신의 블로그를 여러 가지 레이아웃 템플릿과 위젯을 이용해서 쉽게 구성할 수 있도록 제공되고 있다.

역시 Big Data 라는 것도 개인이 자신이 관심이 있는 부분에 대해서 Small Data를 분석할 수 있는 클라우드 기반의 플랫폼 시대까지 접근을 해야만 실제 Big Data 가 제대로 된 것이라고 봐야할 것이다.

Big Data 에 중요한 것은?

개발자들이 직접 데이터를 다루기 위해서는 Hadoop 이나 NoSQL을 활용할 수 있는 환경이 필수적이어야 한다. 물론 현재도 오픈 소스로 누구나 접근이 가능하다. 그리고 여러 벤더들에서는 이런 오픈 소스를 이용해서 관리도구 및 기술지원을 제공하는 비즈니스를 이미 시작했다.

오픈 소스를 이용하는 회사들의 가장 큰 장점이면서 단점은 기술의 내재화 비용이다. 사내 개발자들이 이런 오픈 소스의 기술들을 내재화 할 수 없다면 벤더들에 종속될 수 밖에는 없고, 미래가 없다고 봐야할 것이다.

Daum 같은 경우는 백엔드 개발팀의 절반 이상이 자체적으로 Hadoop을 사용하고 있으며, 이를 지원하기 위해서 기술 및 인프라 정보 공유, 사내 세미나 개체 등을 시행하고 있고, 개발자들이 직접 사용할 수 있는 가상 VM 서버를 제공하여 누구나 Hadoop 테스트를 할 수 있도록 하고 있다.

Big Data는 어느 한 순간에 할 수 있는 것은 아니다. Small Data 부터 제대로 활용이 시작되고, 쓰레기 통에 버려지던 무의미한 데이터들을 저장하고 이를 통해서 가치를 얻어 내는 순환 구조가 정착이 되어야만 점차 Big Data로의 접근이 가능한 것이다.

당연히 Small Data를 가공하는데 Big Data의 기술 요소를 무조건 도입 또는 대체하는 것도 위험한 발상이다. 진정한 Big Data는 의미있게 사용되지 못하고 버려지는 데이터를 더 빠르고, 쉽게 분석할 수 있도록 가공하고, 이를 의사 결정에 바로 이용할 수 있는 것. 이라고 생각하고 접근하는 것이 좋다.

당장 시작하려면?

개발자라면 Big Data 에 사용될 수 있는 오픈 소스부터 검토하고 자신의 개발 환경에서 아주 간단한 정보 처리부터 경험해 보도록 하자. 만일 기업에 종사를 하고 있다면 AWS Elastic MapReduce  (Amazon 서비스, 유료) 나 Google Big Query  (Google, 유료) 부터 시작을 해 도록 하자. 이 정도로 시작해서 반은 성공한 것이다.

“시작이 반이니까”

기술은 가치 중립적인 것이다. 항상 새로운 기술이나 트렌드가 탄생되면 배경과 철학을 이해하는 것이 우선이다. 이 것을 모르고는 남들이 떠든다고 해서 그냥 휩쓸려 가는 것 이외에는 남는 것이 없다.

적적한 곳에 적절한 기술을 취사 선택할 수 있는 능력을 키우기 위해서는 항상 배경과 철학을 먼저 이해할 수 있도록 노력하여야 한다.

댓글

이 블로그의 인기 게시물

OData 에 대해서 알아보자.

얼마 전에 어떤 회사에 인터뷰를 하러 간 적이 있었다. 당시 그 회사는 자체 솔루션을 개발할 기술인력을 찾고 있었고 내부적으로 OData를 사용한다고 했다. 좀 창피한 이야기일 수도 있지만 나름 기술적인 부분에서는 많은 정보를 가지고 있다고 했던 것이 무색하게 OData란 단어를 그 회사 사장님에게서 처음 들었다. 작고, 단순한 사이트들만을 계속해서 작업을 하다 보니 어느덧 큰 줄기들을 잃어버린 것을 느끼기 시작했다. 명색이 개발이 좋고, 기술적인 기반을 만들려고 하는 인간이 단어조차도 모른다는 것은 있을 수 없는 것이라서 다시 새로운 단어들과 개념들을 알아보는 시간을 가지려고 한다. OData (Open Data Protocol) 란? 간단히 정리하면 웹 상에서 손쉽게 데이터를 조회하거나 수정할 수 있도록 주고 받는 웹(프로토콜)을 말한다. 서비스 제공자 입장에서는 웹으로 데이터를 제공하는 방식으로 각 포탈 사이트들이 제공하는 OPEN API 포맷을 독자적인 형식이 아니라 오픈된 공통규약으로 제공 가능하며, 개발자는 이 정보를 다양한 언어의 클라이언트 라이브러리로 어플리케이션에서 소비할 수 있도록 사용하면 된다. 공식 사이트는 www.odata.org 이며 많은 언어들을 지원하고 있다. 좀더 상세하게 정의를 해 보면 OData는 Atom Publishing Protocol  (RFC4287) 의 확장 형식이고 REST (REpresentational State Transfer) Protocol 이다. 따라서 웹 브라우저에서 OData 서비스로 노출된 데이터를 볼 수 있다. 그리고 AtomPub 의 확장이라고 했듯이 데이터의 조회만으로 한정되는 것이 아니라 CRUD 작업이 모두 가능하다. Example 웹 브라우저에서 http://services.odata.org/website/odata.svc 를 열어 보도록 하자. This XML file does not appear to have any style in...

C# 에서 Timer 사용할 때 주의할 점.

예전에 알고 지내시던 분의 질문을 받았다. Windows Forms 개발을 하는데, 주기적 (대략 1분)으로 데이터 요청을 하는 프로그램을 작성하기 위해서 Timer 를 사용하는데, 어떤 기능을 처리해야 하기 때문에 Sleep 을 같이 사용했다고 한다. 여기서 발생하는 문제는 Sleep 5초를 주었더니, Timer 까지 5초 동안 멈춘다는 것이다. Timer 라는 것은 기본적으로 시간의 흐름을 측정하는 기능이기 때문에 Sleep 을 했다고 해서 Timer 가 멈추는 일은 생겨서는 안된다. 그러나 실제 샘플을 만들어 보면 ... Timer 가 Sleep 만큼 동작이 멈추는 것을 확인할 수 있다. Windows Forms 는 UI Thread 를 사용하는 것으로 최적화 되어 있으며 여기서 Timer 를 쓰면 UI Thread 에 최적화된 System.Windows.Forms.Timer 가 사용된다. 여기서 문제의 발생이 시작되는 것이다. Sleep 을 사용하게 되면 UI Thread 가 Sleep 이 걸리기 때문에 여기에 속한 Timer 까지도 멈추는 것이다. 이런 문제를 해결하기 위해서는 System.Threading.Timer 를 사용해야 한다. 이 Timer 는 별도의 Thread 에서 동작하기 때문에 Sleep 의 영향을 받지 않는다. 언뜻 보면 쉬운 해결 방법인 것 같지만 Thread 가 분리되었기 때문에 Timer 가 돌아가는 Thread 에서 UI Thread 의 메서드나 컨트롤에 접근하기 위해서는 별도의 명령을 사용해야 하는 문제가 존재한다. 자~ 그럼 여기서 Timer 에 대해서 다시 한번 정리해 보도록 하자. .NET 에서 제공하는 Timer 들 .NET 에서는 기본적으로 3가지 Timer를 제공하고 있다. (MSDN) System.Windows.Forms.Timer - 사용자가 지정한 간격마다 이벤트를 발생시키며 Windows Forms 응용 프로그램에서 사용할 수 있도록 최적화 되어 있다. System...

[Logging] NLog 사용법 정리...

SCSF 에는 기본적으로 Enterprise Library가 사용된다. 예전에도 그랬지만 기능은 훌륭하고 많은 부분에서 최적화(?)된 것일지도 모르지만, 역시나 사용하기에는 뭔가 모르게 무겁고, 사용하지 않는 기능이 더 많다라는 느낌을 지울수가 없다. 이번 프로젝트도 SCSF를 기반으로 하고 있지만, Enterprise Library를 걷어내고 각 부분에 전문화된 오픈 소스를 사용하기로 하였다. 예전에는 Log4Net을 사용했지만, 대량 사용자 환경에서는 메모리 누수와 기타 문제점이 존재한다는 MS 컨설턴트(?)의 전해진 말을 들은 후로는 사용하지 않는다. 대안으로 사용하는 것이 NLog 이다. 조금 후에는 3.0 버전도 나온다고 홈 페이지에 기재되어 있지만, 그 때가 되면 프로젝트는 끝나기 때문에 현재 2.1.0 버전을 사용하기로 했다. [원본 출처] http://cloverink.net/most-useful-nlog-configurations-closed/ 위의 참조 자료에는 다양한 정보들이 존재하므로 꼭 링크를 통해서 관련된 정보를 확인하고 이해하는 것이 좋을 듯 하다. 여기서는 당장 필요한 부분만을 정리하도록 한다. [ Logger 찾기 ] 기본적으로 Logger가 존재하는 클래스를 기반으로 Logger 정보를 구성한다. Logger logger = LogManager.GetCurrentClassLogger(); 주로 Namespace 기반으로 Logger를 설정하는 경우에 유연하게 사용할 수 있다. 또 다른 방법으로는 지정한 문자열로 특정 Logger를 직접 선택하는 방법도 제공된다. 이를 혼용해서 Namespace와 직접 지정 방식을 같이 사용할 수도 있다. 물론 Logger 환경 설정에서 Wildcard (*)를 지정할 수도 있다. Logger logger = LogManager.GetLogger("Database.Connect"); Logger logger = LogManager.Get...