'분석 플랫폼'에 해당되는 글 2건

  1. 2013.01.28 빅데이터 분석을 위해 알아야할 것들
  2. 2013.01.15 Architect가 필요하다.
Share           Pin It

지난 글에서 (빅데이터) 분석 플랫폼에 대한 생각을 적었습니다. (참고. 데이터 분석 플랫폼에 대한 고민) 그냥 잊어버리려했지만 계속 머리 속에서 생각이 더 구체화되고 있습니다. '아키텍트가 필요하다' 글에서도 밝혔듯이 현실적으로 어려운 여건들이 많이 있지만, 전체 퍼즐을 완성하기 전에 부분 그림은 맞출 수 있을 것같다는 느낌이 옵니다. 데이터를 준비하는 과정은 서비스나 도메인에 따라서 최적화시켜야하는 부분이어서 지금 시점에서 구체적인 안을 제시할 수가 없고, 또 분석된 결과를 해석해서 더 가치있는 인사이트로 전개하는 것은 단기간에 해결될 수 있는 것도 아닙니다. 그리고 빅데이터를 위한 하드웨어 및 소프트웨어 인프라를 설계하고 개발하는 것도 제 영역/능력을 벗어난 일입니다. 그렇다면 현시점에서 당장 할 수 있는 것은 분석 시스템 자체의 기능을 공부하고 구현해두는 것밖에 없습니다. 그래서 현재 존재하는 다양한 빅데이터 관련 기술들을 조사해서 분석 시스템에 어떻게 활용될 것인가?를 먼저 생각해보기로 했습니다. 잘 진행이 된다면 팀 내에서 각각의 파트를 나눠서 공부해서 각 파트의 전문가를 한두명씩 양성할 수 있으면 좋겠다는 생각도 해봅니다.

하드웨어 인프라가 갖춰지면, 기본적인 소프트웨어 인프라는 설치하고 설정할 수 있어야 합니다. 모든 소프트웨어 패키지들을 설치할 필요는 없겠지만, 기본적으로 하둡 Hadoop 시스템이나 Hive와 Pig와 같은 스크립팅 시스템은 설치/설정할 수 있어야 할 것이고, 필요에 따라서 카산드라, MongoDB나 HBase와 같은 NoSQL도 설치/설정이 가능해야할 것이고, 그 외에 ZooKeeper와 같은 기반 환경 등도 최적화할 수 있어야 할 것입니다. 분석가의 입장에서는 조금 귀찮은 일이기도 하지만, 설치와 최적화라는 삽질을 통해서 더 시스템을 더 잘 이해하고 활용할 수가 있습니다. 팀에서 처음 하둡 등을 설치할 때, 저도 잘 모르지만 함께 참여해서 다양한 시도를 해봤더라면 지금 빅데이터 시스템을 더 잘 활용하고 있을텐데라는 후회가 늘 따릅니다.

이제 HW/SW 인프라라 세팅되었다면, Java나 Python과 같이 자신에게 편한 프로그래맹 랭귀지로 간단한 데이터에서 작동하는 MapReduce 알고리즘정도는 구현해볼 필요가 있습니다. 하이브나 피그와 같이 다양한 스크립팅 시스템도 개발/지원되고 있지만, 그것들은 테스트 환경이나 프로토타입을 위해서 장려될 뿐, 궁극적으로 서비스를 위해서는 좀더 네이티브한 랭귀지로 최적화, 안정화될 필요가 있습니다. 하둡이 Java로 구현되었기 때문에 자바를 통합 맵리듀스 구현이 가장 바람직하겠지만, 최근에 파이썬 등에서도 많이 최적화되었기 때문에 자신이 편한 개발환경에서 다양한 프랙티스를 해볼 것을 권합니다.

다음으로 필요한 것은 Hive나 Pig와 같은 스크립팅 랭귀지를 마스터하는 것입니다. 자바나 파이썬 등이 편한 개발자가 굳이 스크립팅 언어까지 배울 필요가 있을까?라는 생각도 듭니다. 더우기 사용성에 초점을 둔 스크립팅 언어는 컴파일이 필요한 네이티브들보다는 다양한 활용에 -- 비정형 데이터처리 등과 같은 -- 제약이 많습니다. 그러나 빠르게 구현해서 바로 실행시켜볼 수 있다는 장점이 있기 때문에, 프로토타이핑 단계에서는 스크립팅언어로 그리고 시스템화에서는 네이티브언어로 구현하는 것은 여러 모로 도움이 됩니다. 피그보다는 하이브가 더 SQL과 가깝기 때문에 팀내에서는 일단 하이브의 사용을 권장하고 있습니다. 그리고 밑에서 적겠지만 R을 이용하는 RHive를 사용할 것이라면 Hive에 익숙해질 필요가 있습니다.

그리고 데이터분석이라면 머신러닝을 빼놓을 수 없습니다. 다양한 문서들과 (검색) 로그들을 활용하기 위해서 단순 카운팅이나 몇몇 독립적으로 배포된 알고리즘들은 사용해보고 있지만, 일반적으로 머신러닝으로 알려진 ANN이나 SVM 등과 같은 것들을 비정형 빅데이터에 적용해보는 것은 아직 엄두도 못 내고 있습니다. 그러나 사람들의 생각은 모두 비슷한가 봅니다. 이미 Mahout이라는 이름으로 아파치에서 빅데이터를 위한 머신러닝 오픈프로젝트가 진행중입니다. 저도 Mahout이라는 이름만 들어봤지, 실제 어떻게 이용되고 있는지에 대한 정보는 없습니다. 대충 훑어보니 SVD, 베이지언, 클러스터링 등의 기능들이 포함되어있어서 안정화되면 분석플랫폼에서 아주 유용하게 쓸 수 있을 듯합니다. Mahout 얘기를 하다보니 학교 다닐 때 들었던 Weka라는 자바용 머신러닝 라이브러리가 얼핏 떠오릅니다. ... 아직은 초기/불안정한 단계에 있지만 Mahout도 초반부터 공부해둘 필요가 있을 듯합니다.

그리고 빅데이터가 뜨면서 함께 주목받는 통계 패키지가 있습니다. 바로 R 입니다. SAS나 매트랩 등의 고가의 소프트웨어에 비해서, R은 통계전공자들에게 늘리 이용되고 있는 오픈/프리 소프트웨어입니다. 그런데 R은 빅데이터/하둡과 연결되어 R이 가진 다양한 통계 기능/라이브러리를 빅데이터에 바로 이용할 수 있습니다. Mahout과 같은 빅데이터-네이티브가 아니라서 아직은 훨씬 더 불안정하고 제약사항이 많지만, 큰 프로그램을 구현하기에 앞서 기존의 패키지로 다양한 테스트를 해볼 수가 있기 때문에 유용합니다. 주변에서 R과 하둡을 함께 사용하는 팀이 있는데, 아직은 많이 불안정하다고 합니다. 그냥 초기에 히스토그램을 그려보거나 초기 파라메터값을 설정하는 용도정도의 제한된 사용만 하고 있다고 합니다. 레볼루션 애널리틱스의 R+Hadoop과 국내 NexR의 RHive가 현재 사용중입니다. 저도 일단은 R을 공부해보기로 했습니다. 책도 구입하고 웹의 다양한 튜토리얼도 보고 있지만, 오랜만에 새로운 랭귀지를 공부하는 거라서 쉽지가 않습니다. 매트랩에서는 행렬, SAS에서는 DataSet의 특성을 잘 파악하면 되었듯이, R에서는 벡터를 잘 이해/활용하면 R 좀 쓴다는 말을 들을 수 있을 것같습니다.

마지막으로 데이터 시각화 도구와 결과 리포팅 기능이 필요합니다. 이미 지난 글에서도 적었듯이 (참고, 데이터 시각화 도구들) 웹에서 데이터를 다양한 도표와 그림으로 시각화해주는 오픈소스들이 많이 있습니다. 물론 앞서 언급했던 R에서도 다양한 시각화가 가능합니다. 그러나 R은 여전히 불안정하고 또 웹을 통한 인터렉티브 그래프를 제공해줄 수가 없기 때문에, 자바스크립트 등을 이용한 웹 시각화 도구에 대한 공부가 필요합니다. 그리고 단순히 어떤 시각화 도구를 사용할 것인가보다는 데이터를 어떻게 표현하는 것이 가장 효과적인가에 대한 고민이 더 필요합니다. 예를들어, 같은 데이터라도 막대그래프가 적절할 때가 있고 파이그래프가 더 적절할 때가 있습니다. 그렇듯이 어떻게 보여줄 것인가? 그래서 어떤 효과를 낼 것인가?를 고민하는 것이 어떤 툴을 이용할 것인가보다 더 중요합니다.

요즘 계속 이런 저런 생각들로 머리가 복잡합니다. ... 두서없이 적었지만, 빅데이터 분석에 관심이 있는 초보자들에게는 그래도 도움이 되었으면 합니다. 앞으로는 좀 더 기술적인 것들도 능력이 되는대로 다루겠습니다.

(2013.01.18 작성 / 2013.01.23 공개)

댓글을 달아 주세요

Architect가 필요하다.

Gos&Op 2013.01.15 09:23 |
Share           Pin It

지난 '데이터 분석 플랫폼에 대한 고민'이란 글에서 사용자들이 쉽게 빅데이터를 가지고 분석하고 결과를 해석해서 서비스화를 seamless하게 지원하는 시스템/플랫폼에 대한 고민/생각을 적었습니다. 그런데 지난 밤 (1월 8일)에 잠들기 전에 막상 이 작업을 저의 올해 중점과제로 삼아서 진행해볼까라고 생각하니 좀 막막해집니다. 평소에 제 스타일을 생각해보면 수박의 겉핥기와 차려진 수박먹기는 잘하지만, 정작 수박을 먹기 좋게 다듬어서 내놓는 그런 스타일은 아닙니다. 즉, 관념적으로 개념을 생각해서 대강의 모습을 그리는 작업이나 이미 범용으로 만들어진 서비스를 이용해서 다른 가치를 창출하는 것에는 어느 정도 능하지만, 개념을 구체화하고 그걸 서비스로 구현해내는 능력은 많이 부족합니다. 그런데, 글로 적었던 분석플랫폼이 제대로 작동하기 위해서는 상세 시스템을 설계하고 그것을 구현해는 능력이 필요합니다. 구현 능력은 주변에 잉여력들이 많은데, 시스템 설계 능력을 갖춘 인재를 주변에서 찾는 것이 어렵습니다. (어쩌면 이제껏 이런 고민이 없었기 때문에 그런 능력을 갖춘 사람을 눈여겨보지 않았습니다.)

정형화된 시스템/서비스를 만들기 위해서는 사용자들의 니즈와 트렌드를 읽어서 관념적인 시스템 설계가 우선이고, 다음으로는 관념적인 도면을 더 상세한 컴포넌트로 나누고 각각의 컴포넌트의 상세 설계를 하고, 그리고 각각을 구현하고 전체를 통합하고, 그런 후에 사용자들에게 가치를 전달하는 과정이 필요합니다. 이상의 각 단계에 특출난 재능을 가진 인재들이 있습니다. 각각을 관념형, 설계형, 구현형, 실무형으로 부르면 될 듯합니다. 그림을 그리는 과정을 생각해보면 관념형은 무엇을 어떤 구도로 그릴 것인가?를 정하는 것이고, 설계형은 구체적인 스케치를 하는 것이고, 구현형은 스케치된 바탕 위에 채색을 해서 그림을 완성하는 것이고, 실무형은 완성된 그림을 큐레이션해서 전시해주는 것으로 생각해도 될 듯합니다. 건축에서도 건축 컨셉을 잡고, 설계를 하고, 시공을 하고, 또 그 속에서 살아가는 과정이 이와 비슷합니다. 그림을 스케치하고 건물을 설계하는 사람, 즉 설계형 인재를 Architect라고 부르려 합니다.

Architect의 능력은 어디서 오는 걸까요? 타고난 재능일까요 아니면 교육을 통해서 배우는 걸까요 그것도 아니면 실무 경험을 통해서 획득하는 걸까요? 기본적으로 예술가적 재능이라거나 관념을 형상화하고 구조화하는 것은 타고나는 것같습니다. 이런 자질이나 성향이 없는 사람에게 무조건 '설계능력이 중요해' '앞으로 유망한 직종이 될거야'라고 꼬셔서 교육을 시킨다고 한들교육을 통해서 얻는 지식과 발전가능성에는 한계가 있습니다. 그러나 그런 성향/흥미가 있는 사람들은 소프트웨어 엔지니어링 분야를 좀 더 체계적으로 교육해서 양성할 필요가 있습니다. 그렇게 교육을 받은 후에 실무 경험을 쌓는다면 좋은 소프트웨어 엔지니어 또는 IT/서비스 아키텍트로 성장할 수 있습니다.

아키텍트에게 필요한 능력은 뭘까요? 시스템의 관념적 설계 능력은 굳이 필요없을 듯합니다. 있으면 좋지만 필수능력은 아닙니다. 그러나 관념적인 생각을 듣고 상세 모습을 상상할 수 있고, 그림/다이아그램 또는 슈도 코드 등의 형태로 그것들을 현실화시킬 수 있어야 합니다. 여기까지 글을 적다가 나도 잘 모르는 소프트웨어 엔지니어링에 대해서 왈가왈부하는 것이 부끄러워서 검색찬스를 사용했습니다. 아래에는 한성대의 이민성 교수님의 재미있는 '한국에서 소프트웨어 엔지니어로 성공하는 법'이라는 동영상이 있습니다. 제가 생각하는 모든 것이 녹아있지는 않지만 많은 것을 얘기해주고 있습니다. 그러나 제가 말하고 싶은 아키텍트는 코딩개발자는 아닙니다.

소프트웨어 엔지니어와 관련된 글을 하나더 소개합니다. 제가 이 글에서 적는 아키텍트의 역량과는 조금 차이가 납니다. 감안하고 읽으보세요. '미국에서 소프트웨어 엔지니어로 산다는 것'.  '소프트웨어 아키텍트가 알아야할 97가지' 라는 책도 있네요. 이 책은 한 번 읽어봐야겠습니다. 좋은 아키텍트가 되기 위해서는 참 다양한 능력과 자질이 필요합니다.

관념을 상세로 설계하는 능력과 함께 상세를 관념으로 역변환시키는 능력도 필요합니다. 집의 설계도를 보고 나서 왜 이런 설계도가 나왔는지에 대한 이유를 유추해낼 수 없다면 설계도와 한치의 오차도 없는 집은 지을 수 있어도 원래 구현하고자 했던 철학은 담을 수 없습니다. 완벽하지는 못하더라도 그런 역관념화의 과정을 거쳐야지 애초에 의도했던 바를 (형태는 바뀌더라도) 구현할 수가 있습니다. 그리고 실제 제품 (시스템이나 코드)를 분석하는 리버스 엔지니어링 reverse engineering 능력도 필요합니다. 그런 의미에서 복기능력도 필요합니다. 다른 사람이 만든 서비스에 대한 이해 없이 나만의 독창성을 실현하는 것은 불가능합니다. 그렇지만 타인 (특히, 롤모델)의 설계에 너무 의존적이 되는 것도 경계해야 합니다. 그 외에도 좋은 아키텍트가 되기 위해서 필요한 자질과 능력은 많습니다. 제가 당장 아키텍트가 되지는 않더라도 그런 능력을 가진 인재를 찾기 위해서 어떤 자질과 능력이 필요한지 공부해봐야겠습니다. 위의 책을 읽어보고 인사이트가 있으면 나중에라도 다시 공유하겠습니다.

주변에서 아키텍트의 역량을 지닌 동료를 찾기 힘든 이유는 아마도 대한민국에서는 개발자들이 (소프트웨어) 엔지니어가 아니라 (프로그램) 코더로 성장하기 때문이 아닌가라는 생각을 합니다. 소위 말하는 Geek스러움이 철저한 계획과 설계에 따른 실행이 아니라, 어떤 문제를 만나도 그 자리에서 뚝딱 해결해버리는 그런 괴짜스러움으로 받아들여지는 듯합니다. 인터넷에 떠도는 이과와 문과의 비교라든가, 공대생 이야기는 모두 그런 이상한 미신에 기반을 두고 있습니다.

...
일단 제가 구상하는 것을 실행하기 위해서 함께할 동료들을 많이 모아야겠습니다. 그동안 몇몇은 눈여겨보고 있었지만, 실행에 앞서서 부족한 부분을 채워줄 그런 동료들이 필요합니다. 이제껏 별로 생각을 못했는데, 아키텍트에 적합한 이가 누구인지 언뜻 떠오르지 않습니다. 생각나는 사람은 있지만 그가 이 일에 적합한 사람인가?에 대해서는 확신이 없습니다. 더 열린 마음과 열린 눈으로 주변의 동료들의 숨은 재능을 찾아보고 규합해봐야겠습니다.

댓글을 달아 주세요