Share           Pin It

블로그 방명록을 통해서 또 질문이 들어왔습니다. 개별적으로 답변할 수도 있지만 비슷한 고민/의문을 가진 분들을 위해서 공개적으로 글을 적습니다. 질문을 요약하면 아래와 같습니다.

1. 빅데이터 분야로 진출하기 위해서 인문학부생으로서 컴퓨터공학과와 통계학(수학) 중에서 어느 쪽으로 전과/복수전공하면 좋을까요? 

2. '빅데이터'에 대한 부정적 시각도 많은데 관련된 미래 직업/산업에 대해서 어떻게 전망하시나요?

한줄 답변

  1. 컴퓨터 공학과
  2. 표지가 바뀐 고전인지 세련된 표지의 잡지인지는 책자을 열어봐야 안다. 그리고 고전도 시대정신을 따른다.


개인이 처한 모든 상황과 배경을 모르기 때문에 원하는 답변이 아닐 수도 있고, 또 여러 생각으로 길게 적다보니 중언부언할 수 밖에 없음을 양해바랍니다. 철저한 계획이 아닌 어쩌다 보니 지금에 이른 (데이터 분석업을 하는) 사람으로서 제 경험만으로 진로상담해주는 것은 부적합하다고 보지만...

데이터 과학을 하기 위해서 컴퓨터 기술과 수학/통계 지식이 중요하다는 것을 알고 있다는 것에서 매우 고무적입니다. (개인적으로는 도메인 경험을 더 중시하는 입장이지만, 현장의 문제를 확인한 후에 그것을 해결하기 위해서 다시 필요한 기술과 지식을 익히는 것이 자연스러우나 현실적으로 불가능한 구조입니다.) 어쨌든 데이터과학자가 된다는 것은 적당한 컴퓨터를 다루는 기술이 있고 (일반적으로 프로그래밍을 의미함) 적절한 수학 지식을 갖췄다는 의미입니다. 여기서 자신의 진로 방향에 따라서 수학을 잘 아는 컴퓨터공학자가 되느냐 아니면 컴퓨터를 잘 다루는 수학자가 되느냐에 따라서 데이터 과학자로서의 자신을 정의할 수 있습니다.

데이터 과학을 위해서 컴퓨터와 수학이 필요하지만, 모든 컴퓨터 기술이 데이터 과학에 필요한 것도 아니고 모든 수학 커리큘럼이 데이터 과학의 기초가 되지도 않습니다. 모든 학문이 서로 연결됐기 때문에 많이 알수록 다양한 측면에서 도움이 되겠지만, 현실적으로 컴퓨터 공학의 일부와 수학/통계학의 일부를 접목한 것이 데이터 과학입니다. 데이터 과학이라는 별도의 학과가 없는 상황에서 -- 이론적 연구자가 되기를 희망하는 것이 아니라면 -- 수학/통계학을 잘 아는 컴퓨터 공학자가 되는 것이 데이터 과학자가 되는 길이라고 봅니다. 회사에 취직해서 실생활의 문제를 해결하는 것이 진로 방향이라면 컴퓨터공학과로 진학해서 필요한 수학/통계학과 과목을 수강하는 것을 추천합니다. 특히 대학원 진학도 염두에 두고 있다면 데이터 과학을 하는 수학연구실은 (거의) 들어본 기억이 없습니다.

컴퓨터 사이언스가 수학의 한 분야에서 시작했고 다시 데이터 과학은 컴퓨터 공학의 큰 부분이 돼고 있습니다. 결국 데이터 과학은 수학을 기반으로 한 컴퓨터 공학의 분야로 보는 게 맞을 듯합니다. 수학/통계 지식이 데이터 과학을 하는데 중요하지만 컴퓨터 기술은 오늘 날의 데이터 과학에 필수불가결한 요소입니다. 쉽게 사용할 수 있는 많은 통계 패키지와 데이터 라이브러리들이 흔해졌지만... 실질적으로 오늘날과 같이 데이터를 활용하는 분야에서는 수학/통계학자보다는 컴퓨터 공학자의 역할이 더 적합하다고 봅니다. 왜 통계학자가 빅데이터에 실패했는가?와 같은 류의 글들이 몇 년 전에 여럿 있었다는 것만으로도 데이터 과학에서의 사고의 틀 및 기술세트가 무엇인가를 잘 설명해준다고 봅니다.

오늘날 데이터 과학이 주목을 받는 것은 실생활의 문제와 밀접하게 연결되면서 부터입니다. 이론이 연구실을 벗어나서 실용이 되는 과정에서 데이터 과학이 빛을 발하고 있습니다. 정보 지식 사회에서 '실용'이라는 것은 결국 컴퓨터화를 뜻하고, 그걸 달리 말해서 프로그래머블 programable을 뜻한다고 봅니다. 생각을 컴퓨터 언어로 표현할 수 있어야 한다는 뜻입니다. 데이터 과학도 결국 수학이 컴퓨터 언어로 번역됐기 때문에 가능한 분야입니다. 그리고 두번째 질문과 연결이 되는 부분이기도 한데, 지금은 데이터 과학과 관련한 수많은 오픈 소스와 라이브러리들이 넘쳐나고 있고 그걸 어떻게 잘 활용하느냐라는 엔지니어링의 문제가 됐습니다. 순수 수학자가 되는 것이 꿈이 아니라면, 그런데 데이터 과학이란 게 학문보다는 실용의 X라는 점을 고려한다면...

길게 적었지만, 지금 구체적으로 어떤 상황에 처해있고 개인적으로 어떤 계획을 가지고 있는지를 잘 모르지만... 두개의 선택지만 존재한다면 컴퓨터 공학을 추천합니다. 대부분의 데이터 및 인공지능 관련 연구 및 발전은 컴공과에서 나오고 있습니다. 아주 심도깊은 연구 (새로운 알고리즘을 개발한다거나...)를 하기 위함이 아니라면, OR/최적화 관련 교수님이 여럿 있는 산업공학과도 인문학과생에게는 더 편할 수도 있습니다. (산업공학이 데이터과학을 위해서 좋다는 것이 아니라, '현재 학교의 산업공학과에서 OR/최적화 등에 강점이 있다면'을 뜻함.)

'빅데이터'가 마케팅 용어라는 점에는 저도 전적으로 동의합니다. 하지만 빅데이터라는 용어가 탄생될 수 있었던 사회적(?) 환경을 봐야 합니다. 1~20년 전에도 데이터 분석이라는 분야는 존재했지만 왜 갑자기 빅데이터라는 이름을 불리게 됐을까?를 생각해봐야 합니다. 말 그대로 '빅' 데이터라 부를만한 데이터들이 생겨나고 있고 또 적절히 그걸 다룰 수 있어졌고, 그래서 과거에는 상상도 할 수 없었던 것을 이제 할 수가 있게 됐습니다. 데이터의 종류와 양이 기하급수적으로 늘어났고 또 그걸 처리할 수 있는 다양한 기술과 인프라를 갖게 됐습니다. 별로 섹시하지도 않은 '빅데이터'라는 용어가 등장했다는 것은 -- 물론 일부에서는 자신의 기술세트에 대한 생명연장인 경우도 존재하고 거짓 데이터 에반젤리스트들이 존재하지만 -- 단순히 포장지를 바꾼 것만은 아닙니다. 물론 빅데이터라는 용어는 이제 식상해져서 또 새로운 용어를 찾을 것이고, 최근에는 인공지능과 결합해서 새로운 포장지를 찾고 있는 것도 사실입니다. 하지만 이는 역설적이게도 데이터 및 그걸 활용하는 것은 몇 십년 전 과거부터 오늘날, 그리고 앞으로도 계속 필요하다는 것을 보여주는 것입니다. 마케팅을 위해서 책 표지를 항상 바꾸는 것은 잘못된 관행이라 할 수 있지만, 표지가 바뀌었다고 해서 내용이 쓰레기라고 부를 수는 없습니다.

사실 저도 나름 데이터 과학을 하고 있다고 말하지만 -- 최근에는 조금 다른 업무를 하고 있지만 -- 이 분야의 전망, 더 정확히 말해서 직업적 안정성에 대한 미래는 잘 모르겠습니다. 예전에는 그냥 코딩만 하면서 서비스를 구축하던 친구들이 최근 쏟아지는 데이터 관련 오픈소스를 이용해서 데이터 분석 또는 데이터 기반의 서비스를 쉽게 만드는 모습을 보면서 과연 나는 앞으로 무얼 할 수 있을까?를 매일 고민합니다. 데이터 업무가 점점더 쉬워지면서 소위 일반 개발자들이 데이터 개발자가 되는 이 시대에, 내가 지금 다시 프로그래밍 기술을 더 익혀서 그들보다 더 나은 데이터 과학자가 될 수 있을까?라는 의심이 듭니다. 데이터 과학자라는 저의 입지보다 어쩌면 데이터 개발자라는 그들의 입지가 더 커지고 있는 것을 부인할 수 없습니다. (<== 이 현상에 문제가 없다는 것은 아님) 일반론으로 돌아가서 지금 각광을 받고 있는다고 해서 미래가 안전한 것은 아닙니다. 그건 지금은 없어진 많은 과거의 직업이 증명해줍니다. 원론적으로 돌아가서 '과연 내가 뭘 하고 싶은가?', 즉 꿈이 무엇인가의 문제이지 이 직업에 미래가 있는가?의 문제가 아닙니다. 산업이 무너져도 장인은 남을 수 있습니다. 직업의 측면으로 데이터 과학을 보는 것이라면 -- 세상의 모든 다른 직업들과 마찬가지고 -- 이 직업은 미래가 없습니다. 직업은 도구일 뿐입니다.

냉정하게 생각해보시기 바랍니다. 이미 인문학부생이라고 밝혔습니다. 즉, 나이는 20대에 접어들었고 고등학교 때는 이과가 아니었을 가능성이 큽니다. 문과였다면 더 어렸을 때부터 수학이나 과학을 싫어했을 가능성이 큽니다. 지난 5년 또는 10년 동안 수학이나 과학보다 인문학을 더 좋아했던 20대 초반의 인문학과 학생과 어릴 때부터 과학영재라는 소리를 들으면서 자라나서 지금 컴공과나 수학과에 진학한 학생이 있는데, 둘다 데이터 과학자 -- 직업의 안정성을 떠나서 -- 가 되고자 한다면 누가 더 잘 할 수 있을까요? 후자가 더 유리할 수 밖에 없습니다. 하지만, 무엇을 위해서 데이터 과학자가 될 것인가?라는 질문 why으로 돌아가서 생각한다면 결과는 다를 수 있습니다. 예를 들어, 전자의 학생이 소설가가 꿈이었는데 데이터 기반의 인공지능 소설창작 기계를 만들기 위해서 데이터 과학자의 길로 접어든다면 얘기는 달라지지 않을까요?

새로운 포장지를 계속 만들고 있다는 것은 최후의 발악일 수도 있지만 책 표지만 바꿔도 여전히 유효하기 때문일 수가 있습니다. 데이터 과학은 아직은 후자에 가깝습니다. 하지만 직업적 안정성이라는 측면으로 데이터 과학을 선택하겠다면 더 잘 할 수 있고 더 좋아하고 더 자신만이 해야하는 직업을 찾는게 낫습니다. 언론에서 '미래의 유망 직업' 등의 소개글도 그걸 적은 사람이 한번 더 기자 코스프레를 할 수 있게 해주는 것 뿐이지, 그걸 읽는 독자나 그들의 자식들의 미래 먹거리를 걱정하고 알려주는 것이 절대 아닙니다. 로봇과 인공지능이 시대에 안정적인 직업은 없습니다. Absolutely.

저는 당신의 꿈을 응원합니다.


=== Also in...

F: https://www.facebook.com/unexperienced

댓글을 달아 주세요

Share           Pin It

지난주 금요일에 제주에서 대한인간공학회 춘계학술대회가 있었습니다. 프로그램을 준비하시는 분께서 '전문가 세션 > 빅데이터'에 발표해줄 연사가 필요하다고 해서 흔쾌히(?) 수락했습니다. 처음에는 단순히 다음이나 카카오에서 했던 다양한 분석 사례정도만 모아서 '카카오에서의 빅데이터 분석 및 활용' 정도로 발표하면 쉽게 될 거라 생각했습니다. 그런데 청자들이 데이터 분석을 담당하거나 적어도 프로그래머/개발자라면 쉬울 수 있는데, 대부분 인간공학 전공자들이라서 단순히 사례들만 모아서 장광설을 펼치면 죽도 밥도 안 될 것 같다는 두려움이 생겼습니다. 발표자료를 준비할 시간이 겨우 한달정도밖에 없었는데, 여러 고민을 하다가 인간공학을 전공하는 학생들에게도 도움이 될 수 있는 테스팅 방법론을 중심으로 준비하기로 마음을 정했습니다. 온라인 A/B 테스트에서부터 MAB (Multi-Armed Bandit)까지 다루면 될 것 같았습니다. 그런데 또 막상 자료를 준비하다보니 원래 취지가 '빅데이터'인데, 너무 지협적인 문제만을 다루는 듯해서 조금 일반화시켜서 '데이터 과학자의 삶: 신화와 실체'라는 제목으로 정했습니다. 발표자료에서는 '온라인 테스팅'을 중심으로 다뤘지만, 데이터 과학에서 가장 감추고 싶은 실체는 데이터 준비와 정제인데, 이 내용은 말미에 짧게 넣었습니다.

 
슬라이드에 설명이 없으니 짧게 정리하면..

데이터 과학자은 수학/통계 지식과 프로그래밍 능력을 활용해서 데이터에서 비즈니스적 가치를 찾는 사람이다. 그래서, 수학 통계 지식도 필요하고 프로그래밍 스킬도 필요하다. 뿐만 아니라, 도메인 지식이 필요하다. 그러면 데이터 과학자는 슈퍼맨인가? 아니다. 실제 데이터 과학자들이 하는 일은 SQL을 잘 짜서 데이터를 뽑는 일만 한다. 그것도 무한 반복해서... 요즘 회사에 출근해서 가장 많이 보는 화면이 Hue 시스템이다. 그나마 터미널에서 작업하지 않는 것과 Hive 때문에 자바 등의 직코딩을 안해도 되는 것이 참 행복하다.

중요한 파트라서 화면을 캡쳐했는데... 실제 데이터 과학자들은 'SQL과 Data' 사이의 왔다갔다함이 일의 대부분이다. 여기서 인사이트를 얻으면 구현해서 테스트하고 배포한다. 아주 가끔 회귀분석이나 클래시피케이션 같은 고급 알고리즘을 사용하기도 한다. (KR = Knowledge Representation)

'김제동의 톡투유' 장면을 캡쳐했는데, 일반인들이 '빅데이터'에 대해서 생각하는 게 이런 화면이다. 많은 다양한 데이터를 모아서 빨리 가공해서 단어의 출현 빈도나 트렌드, 또는 키워드맵을 만드는 정도... 그러나 데이터에서 가치를 찾아내는 것이 요즘은 더 중요하다. 그래서 빅데이터보다는 스마트데이터로 변하고 있다. 단순히 엔지니어링 문제를 과학으로 바꾸는 것은 결국 분석력이다.

데이터 과학이 과학인 이유는 '과학적 방법'을 사용하기 때문이다. 과학적 방법은 1. 이론으로 증명하든지 2. 실험으로 검증하든지... 그런데 이론은 어렵다. 발표는 테스팅에 집중한다.

보통 과학에서의 실험은 문제에 대한 가설을 세우고 실험해서 실패하면 다시 가설을 세우고 다시 실험하고 이 과정을 반복하다가 실험이 성공하면 가설대로 논문을 작성해서 졸업하면 되지만, 서비스에서는 가설과 검증보다는 관찰과 테스트/비교를 거친다. 그리고 테스트가 성공해서 성공적으로 서비스를 런칭하더라도 다시 처음부터 관찰과 테스트를 무한반복한다. 그리고 온라인 테스트와 오프라인 테스트를 분리해서 진행하는 점도 특이하다. (넷플릭스는 일주일 단위로 '코드 배포 - 오프라인 테스트 - 온라인 테스트 - 서비스 배포'를 반복한다. 넷플릭스 개발자의 발표에서 직접 들은 것)

온라인 테스트는 A/B 테스트 또는 버킷 Bucket 테스트라고 한다. 파란 약과 빨간 약을 실제 사용자들에게 선택하라고 두고 많이 선택하는 걸로 정하면 된다. (인간공학회라서) 아이트래킹으로 비교할 수도 있다. 그런데 나는 데이터 과학자니 데이터로 확인한다. (같은 광고를 다른 타겟 사용자들에게 노출시키고 반응을 확인함)

A/B 테스트를 할 때 트래픽 기반으로 할 수도 있고 사용자 기반으로 할 수가 있다. (귀찮아서 그냥 글로 표현함)

50:50으로 실험군과 비교군을 만들 수 없다. 처음 런칭하는 서비스라면 괜찮지만, 이미 운영중인 서비스의 50%의 트래픽에 검증이 안/덜된 화면을 보여줄 수 없기 때문에 일부 (보통 5~10%)만을 실험군으로 정한다. 바이어스를 없애기 위해서 랜덤군도 둔다. 실험해야할 것들은 산적해있는데 매번 A/B로 나눠서 테스트하는 것은 여러모로 리소스 낭비이므로 실험군을 여러 개를 동시에 적용하고 모니터링 한다.

여담으로 네이버의 상징색이 녹색이듯이 다음의 상징색은 파란색이다. 처음에는 빨간색으로 하자는 의견도 있었지만 실제 사용자 반응에서 파란색으로 했을 때 PV나 클릭률 등이 더 높았다. (입사하기 전에 했던 전설로 들려오는 사례). 여담2. 외국의 경우 보통 엔지니어 중심으로 서비스가 만들어져서 데이터 기반으로 UI/UX를 정하는 것이 좀 일반적인데, 국내의 경우 처음부터 기획자나 디자이너가 함께 일하기 때문에 데이터 기반으로 화면을 구성하는 것이 오히려 더 낯선 풍경이다. (이미 기획자 및 디자이너들은 전문성이 있기 때문에 단순한 수치로 그들의 전문성에 의문을 제기하기는 어렵다. 그래서 UI/UX보다는 랭킹 관련된 곳에만 보통 온라인 A/B 테스트가 적용된다.)

서두에 말했듯이... 데이터 과학자는 마치 꽃길만을 걸을 것 같지만 그렇지 않다. 그리고 데이터 과학에서 알고리즘보다는 데이터가 더 중요하다. 포브스의 기사에 이게 잘 나타나있다. 데이터 과학자들의 업부에서 20%는 데이터를 정의하고 수집하는데, 그리고 60%는 데이터를 정제하는데 사용한다. 그리고 이걸 가장 싫어한다. 그러나 이게 데이터 과학자들의 숙명이다. 이걸 얼마나 잘하느냐가 데이터 과학의 성패를 결정한다. 알고리즘은 중요하다. 그러나 데이터가 나쁘면 알고리즘은 그냥...

정리하면, 데이터 과학은 비즈니스 골을 획득하기 위해서 데이터를 해킹하는 것인데, '바른 데이터 > 바른 평가 > 바른 알고리즘'이다. 나는 데이터 과학자/해커지만, 여러분들은 이런 방법론이나 데이터를 사용해서 '인간 해커'가 되기를 바란다. 그리고 제주에서 즐거운 시간을...

=== Also in...


댓글을 달아 주세요

Share           Pin It
오랜만에 블로그 방명록을 통해서 들어온 질문에 대한 답변을 적어 봅니다. 

질문을 대략 요약하면 다음과 같습니다.
인천에 있는 대학에서 경영학과 4학년으로, 산업경영공학을 복수전공해서 졸업할 예정이다. 제조업 물류 쪽에서 일하고 싶지만, (이런 쪽으로 진로를 정하기 위해서 컴공과보다는) 산업공학과 대학원에 진학해서 데이터마이닝을 전공하고 싶다. 실험계획이나 통계 관련 수업은 이미 들어서 기초적인 지식은 있지만, 겨우 MS SQL만 사용할 정도로 프로그래밍 쪽은 기초가 거의 없다. 그래서, 대학원에서 다뤄야할 기본 프로그래밍 언어는 어떤 것이 있고, 빨리 배우려면 어떻게 해야 할까요?
질문을 대략 요약한 것이라서 제가 답글로 남긴 내용은 위의 요약만으로는 조금 이해하기 어려울 수도 있지만, 짧게 남긴 답글을 먼저 제시하겠습니다.
대학원에 진학하면 수업/숙제를 위해서 또는 프로젝트를 위해서 관련된 언어나 통계툴을 웬만큼 익히게 됩니다. 너무 걱정할 필요는 없을 것같습니다. 학교에서 논문 작성을 위해서는 매트랩을 많이 사용하지만, 라이센스 비용 등도 있고 현장에서 계속 사용하기 위해서는 R을 배우는 것을 추천합니다. 그리고 일반 범용 랭귀지를 배우고 싶다면 C나 자바보다는 요즘은 파이썬으로 시작하는 것도 추천합니다. 매트랩이나 R보다는 파이썬 책이나 한권 사서 먼저 익혀보세요.

최근 가천대학교 산업경영공학과의 최성철 교수가 적은 ‘산업공학과를 위한 프로그래밍 입문 파트1 링크 / 파트2 링크' 또는 ‘산업공학도가 데이터 과학하기'를 먼저 읽어보는 것이 충분히 도움이 될 것같습니다. (위의 포스팅을 페이스북에 올린 후에 최교수와는 페친이 됐는데, 학교 5년 후배였네요. 학교에 있는 동안 마주쳤을 법도 한데… 혹시 최교수가 제주에 올 일이 있어서 연락하면 한 번 만나봤으면 좋겠고, 관련 주제로 회사에서 세미나라도 해줬으면..)

이제껏 데이터마이닝 전공에 대한 몇 차례 글을 적으면서 애써 피했던 주제가 프로그래밍 관련 된 것입니다. 제가 각종 언어 (국어, 영어, 일본어 등의 자연어에서 부터 자연의 언어인 수학, 그리고 컴퓨터 언어인 프로그래밍 랭귀지들)에 자신이 없기 때문에 언어에 대한 적당한 조언자는 아닙니다. 그러나 개념적인 부분에서는 나름 잘 파악하고 있다고 생각하기 때문에 기술적이지 않은 선에서 (데이터마이닝과 관련한 언어 선택을 중심으로) 몇 자 적겠습니다.

96년도에 대학을 들어가서 처음 배운 컴퓨터 언어는 C 였습니다. 정말 못했습니다. 저희 때만 하더라도 포인터와 struct까지 다 배웠는데, 몇 년 후에는 배열정도까지만 배우도록 과정이 축소됐다는 얘기도 들었고, 어쩌면 지금은 C가 아닌 다른 언어로 시작할지도 모릅니다. 인터넷을 접하면서 자연스레 마크업을 다루고 Java도 조금 독학해서 지금은 Java (최근 자바8 등에서 차용된 최신 형태인 람다함수 등은 아직 사용하지 못하고, 여전히 아주 예전 스타일대로 자바 코딩중입니다.ㅠㅠ) 계열로 간단히 먹고 살 정도로 코드를 작성하고 있습니다. (잠시 스쳐간 소소한 언어들도 있지만) 대학원에서는 매트랩으로 수치 연산을 하고 실험 결과로 논문 작성을 주로 했고, 회사에 와서는 SAS로 데이터 가공을 주로 하고 있습니다. 그리고 최근에는 하둡+자바 환경으로 대용량 데이터 MR 작업을 주로 합니다.

진학하는 대학원 연구실이나 담당 교수에 따라서 조금씩 다르겠지만, 통계 위주의 연구실이라면 예전부터 사용하던 통계툴들이 있을 것입니다. 매트랩일 수도 있고, SAS를 사용하는 곳도 있고, 미니탭이나 매스매티카 등을 사용하는 경우도 있을 것입니다. 그리고 요즘은 R도 많이 사용할 듯합니다. 제가 대학원을 다닐 때는 그냥 매트랩으로 다 처리하고 졸업할 시점에 R에 대한 얘기를 처음 접했는데, 제대로 사용하지 못하고 그냥 졸업했습니다. (최근 R을 조금 공부했지만 그냥 코드의 흐름만 이해할 정도입니다.) 즉, 대학원 연구실의 성격이나 수강하는 수업의 교수 특성에 따라서 특정 통계툴을 사용하도록 강제(?)되기 때문에 미리 어떤 툴에 익숙해져야 겠다는 것이 조금 어리석은 생각일 수도 있습니다. 어차피 프로젝트 과제를 하거나 숙제를 하기 위해서는 그런 툴에 빨리 익숙해질 것이기 때문입니다.

그렇지만 논문 작성이 우선이라면 매트랩이나 R을 배울 것을 권합니다. 벡터나 매트릭스 연산이 많이 필요한 분야를 전공하고 싶다면 매트랩이 더 적합하고, 통계 분야로 공부하고 싶다면 R이 더 나은 선택입니다. 그리고 졸업 후에도 계속 사용하는 것이 목적이라면 R이 매트랩보다는 조금 더 매력적입니다. R만으로는 충분히 큰 데이터를 용이하게 다룰 수는 없지만, 다양한 빅데이터 기술들과 연계를 고려한다면 (프로그래밍에 취약한 분이라면) R의 대안이 거의 없다고 봐도 무관할 듯합니다.

대학원에서 과제를 진행하거나 졸업 후에 (학계가 아닌 산업계로) 취직할 때 상용 통계툴로만 해결 가능한 문제는 극소수로 제한됩니다. 그렇기에 범용 프로그래밍 언어 하나 정도는 익혀둘 필요가 있습니다. 다양한 데이터를 전처리하거나 후처리하는 과정에서 꼭 필요합니다. 그리고 웹을 통해서 도출된 결과를 보여주기 위해서는 웹 친화적인 언어를 배우는 것이 좋습니다. 그런 여러 가지를 고려한다면 적당한 대안으로 Java, 파이썬, 스칼라 Scala 정도가 있을 듯합니다. Perl이나 PHP도 일부에서는 사용하지만, 앞의 3개에는 못 미칩니다.

그런데 학교에서 연구하고 또 다양한 (특히 텍스트 형태의) 데이터를 가공하는 것이 목적이라면 파이썬이 가장 강력한 후보라고 생각합니다. Scala는 제가 아직 잘 모르는 언어라서 일단 생략합니다. 여러 종류의 문제에 맞는 오픈소스로 Java 기반의 라이브러리나 프로그램들이 많이 있지만, 과학 연구나 텍스트 마이닝을 위한 파이썬 라이브러리에는 (특히 최근에는) 못 미칠 듯합니다. 파이썬이 자바보다도 더 배우기도 쉽다고 하니 첫 언어 습득으로 파이썬은 좋은 선택입니다. (자바보다는 파이썬이 나중에 나온 언어라서 좀더 진화된 형태를 보여주는 듯함. 그에 비해서 자바는 기존의 C나 C++의 컨벤션을 많이 상속한 마지막 언어라는 느낌이 강함) 최근 구글(Go)이나 애플(Swift) 등에서도 새로운 랭귀지를 발표하는데, 이건 관련 앱을 만드는 등에 최적화됐으니 이 포스팅에서는 굳이 다룰 필요는 없을 듯합니다.

그래서 대학원에 진학하는 사람 그리고 산업계로 진출하려는 사람에게는 파이썬 + R이 가장 강력하고 적절한 조합이 아닐까?라는 생각을 해봅니다. 그런데 최근 이슈가 있는 빅데이터, 특히  Hadoop 기반의 MR 작업을 진행한다면 Java에 대한 이해가 있으면 좋을 듯합니다. 그러나 그런 것도 대부분 파이썬으로 커버가 되기 때문에 특수한 경우가 아니라면 (데이터 가공이 아닌 더 시스템에 치우친 분야로 취업한다거나..) 굳이 자바를 마스터할 필요는 없습니다. 파이썬이면 충분할 듯… 그리고 하나의 언어를 습득하고 나면 두번째, 세번째 언어는 나름 더 쉽게 습득할 수 있기 때문에 필요할 때 다시 배우면 됩니다. (먹고 살려면 배우게 됩니다.)

최근 회사 내에서도 이슈가 되기도 했지만, 빠른 빅데이터 처리 및 분석을 위한 것이라면 파이썬 + R + 하둡보다는 Scala + Spark 형태도 괜찮을 듯합니다. Scala는 Java에 더 진일보한 언어라서 자바를 배우는 것보다 바로 스칼라로 넘어가는 것도 현명한 선택일 듯합니다. (그러나 아직은 Scala는 자바나 파이썬보다는 범용성에서는 다소 떨어진다는 점을 고려해야 합니다. 범용성이란 단순 기능의 커버리지 뿐만 아니라 개발자 커뮤니티나 라이브러리 등을 두루 말하는 의미임.) Spark는 메모리 기반으로 머신러닝 ML 라이브러리를 제공해주고 스칼라에 최적화됐기 때문에 학교가 아닌 산업계에서 경력을 쌓고 유지하고 싶다면 Scala + Spark도 괜찮은 조합입니다.

대략 요약하면 학계에서 계속 경력을 쌓고 싶다면 매트랩이나 R (또는 SAS)를 선택해서 특화시키는 것이 좋을 것같고, 대학원 후에 취업이 목적이라면 R + 파이썬 조합이 괜찮을 듯하고, 그리고 회사에서 더 큰 임팩트를 주고 싶다면 Scala + Spark 조합이 좋을 듯합니다. 그러나 관련 분야에서 몇 년의 시간을 보내고 경력을 쌓다보면 매트랩도 하고 있고 R이나 SAS도 다루고 있고, 어떨 때는 파이썬으로 코딩하고 다른 경우는 또 자바로 코딩하고 있습니다. 대용량 데이터를 다루기 위해서 하둡+자바로 코딩하기도 하고, 더 빠른 분석 등을 위해서 Scala+Spark로 작업하고 있는 자신의 모습을 발견하게 될 것입니다. 당장 어떤 언어를 마스터해야겠다는 욕심보다는 상황에 맞게 빨리 습득하고 시도해보는 것이 중요합니다.

그리고 댓글에 짧게 적었듯이, 일단 프로그래밍 언어를 배워서 익숙해지는 것이 목적이라면 학원 등에 등록해서 수강하는 것도 좋겠지만, 그냥 동네 서점에 가서 파이썬 책 한권 구매해서 처음부터 읽어가면서 책에 나온 예시들을 직접 타이핑해가며 (C&P는 아니라고 생각됨) 연습해보고, 또 더 복잡한 문제를 위해서 인터넷에서 관련 오픈소스를 다운받아서 설치하거나 변경해보면서 연습하는 것만으로 충분할 듯합니다. 그리고 그루터의 정재화님이 올린 ‘프로그래머를 꿈꾸는 학부생들에게' 내용도 참조하시면 좋을 듯합니다.

저는 각종 언어에 젬병이기 때문에, 위의 글은 참조만 하시고 더 전문가들의 조언에 귀기울이시기 바랍니다.

==
페이스북 페이지: https://www.facebook.com/unexperienced


댓글을 달아 주세요

Share           Pin It

어쩌다 보니 책번역에 참여했습니다. 원제목은 'Data Just Right'인데, 번역서는 '데이터는 언제나 옳다'로 정해졌습니다. 그냥 '데이터는 항상 옳다'라고 가번역했는데, 저렇게 출판사에서 정했습니다. 아래는 옮긴이의 글을 다시 올립니다. 책에는 교정돼있지만, 원래의 느낌을 살리기 위해서 최초에 적었던 내용을 그대로 올립니다. 책 가격은 조금 비싼 듯도 하지만, 그건 제 영역 밖의 문제라...

다음책: http://book.daum.net/detail/book.do?bookid=KOR9788998139551

데이터는 언제나 옳다! 대규모 데이터 처리와 분석 실무
국내도서
저자 : 마이클 마누체흐리(Michael Manoochehri) / 정부환,류상호,염화음,이화경역
출판 : 위키북스 2014.05.28
상세보기

===

옮긴이의 글

먼저 밝혀야할 것이 있습니다. 저는 책에 덧붙는 추천사, 감수의글, 옮긴이의 글 등을 싫어해서 대부분 읽지 않습니다. 개인 블로그에 올린 '추천사가 책을 망친다'는 조금 도발적인 제목의 글에서 그 이유를 밝혔습니다. 그런데 지금 제가 번역에 공동 참여하여 이렇게 옮긴이의 글을 적고 여러 분들의 평가를 받아야 하는 아이러니한 상황입니다. 블로그에서도 밝혔듯이 이 글이 책 쪽수만 차지하는 사족이 될 수도 있고 여러분들의 자유로운 사고 및 시각을 방해할지도 모릅니다. 그렇지만 다른 추천사들의 원래 의도가 그러하듯, 여러 분들이 이 책을 읽고 활용하는데 가이드가 됐으며 하는 바람으로 적습니다.

본문에도 나오지만 빅데이터 또는 대용량 데이터 분석이라는 용어로 현재 진행 중인 정보 혁명을 모두 설명할 수 없습니다. 그동안 데이터마이닝이라는 분야가 일반에 덜 알려져서 과소평가를 받아왔지만, 최근에는 빅데이터 물결에 휩쓸려 지나치게 과대포장되어 소개되고 있습니다. 이 분야에서 오랫동안 연구하고 종사했던 분들도 전체를 조망하기에는 너무 큰 분야입니다. 그렇지만 데이터마이닝, 또는 데이터 기반의 의사결정이라는 것이 소수의 전문가들의 전유물에 머무르지 않았으면 하는 오랜 바람이 있습니다. 그런 의미에서 책에서 다루는 다양한 유즈케이스와 관련 기술들이 데이터마이닝과 빅데이터를 처음 접하는 많은 분들에게 도움이 됐으면 합니다.

현재 이 물결에 편승한 다양한 기술들이 매일 등장하고 진화하고 있습니다. 책에서도 다양한 기술들을 소개하고 있지만 전체를 아우르기에는 반의 반도 채 되지 않는다고 장담합니다. 이 책이 쓰여지고 번역되는 동안에도 수많은 기술들이 새로 만들어져서 우리의 선택을 기다리고 있습니다. 이 한 권의 책으로 모두의 필요를 충족시킬 수 없습니다. 그럼에도 불구하고 빅데이터 기술의 흐름을 살펴보고 어떤 기술들이 있는지를 인지하는 것만으로도 빅데이터의 파도를 헤쳐나가는데 좋은 길라잡이가 될 수 있습니다. 저 개인의 경우, 필요할 때마다 부분적으로만 알고 다뤘던 기술 및 흐름을 정리하는 좋은 계기가 됐습니다.

새로운 분야를 시작할 때 대표 기술을 하나 선택해서 깊게 파고드는 것도 연구의 한 방법입니다. 그러나 적어도 급변하는 빅데이터의 파고에 대응하는 적절한 방법은 아닐 수 있습니다. 대학원에 진학해서 연구를 시작하는 단계라면 적어도 1~2년은 기다려줄 수가 있지만, 바로 현장에서 대용량 데이터를 처리해서 의미를 파악하고 새로운 서비스에 적용하는 데는 위험이 따릅니다. 연구를 시작하는 이들에게는 현실적으로 조언하자면, 관심/관련 분야의 전체 흐름을 간략하게라도 먼저 확인한 후에 더 깊게 파고들 세부 분야를 선택하는 것입니다. 나무 몇 그루를 심는다고 당장 숲이 만들어지지 않습니다. 먼저 숲을 확인하고 자신이 가꿀 나무를 선정하는 것이 현실적입니다. 그런 의미에서 이 책은 빅데이터 마이닝을 시작하는 이들에게 좋은 숲지도가 될 것입니다.

처음 출판사로부터 번역 의뢰가 왔을 때 조금 두려웠지만 좋은 경험이 될 것 같아서 수락했습니다. 처음 한 챕터를 번역해보고 '번역하는 것보다 내가 직접 적는게 더 낫겠다'라고 푸념했습니다. 번역이라는 것이 본인의 영어 실력이나 관련 분야의 경험에만 오로지 의존하지 않습니다. 저자의 원래 의도를 파악해야 하고, 그것을 바탕으로 독자들이 쉽게 이해하고 적용할 수 있도록 전달해줘야 합니다. 힘든 과정이었지만 또 의미있는 시간이었습니다. 부족함을 깨닫고 동료를 믿고 기다려야 하는 시간이었습니다. 여러분들도 기회가 된다면 -- 출판을 전제하지 않더라도 -- 번역을 직접 해보셨으면 합니다. 개발자가 가장 많이 사용하는 언어는 C도, Java도, Python도 아닌 영어입니다. 굳이 번역이 아니더라도 영어와 조금이라도 더 친숙해지셨으면 합니다.

처음 하는 장문 번역이라 매끄럽지 못한 부분들도 많이 있습니다. 저희의 부족함에 너른 이해를 바랍니다. 그리고 책내용이나 빅데이터, 데이터마이닝 등과 관련된 다른 의견 또는 질문이 있으시면 저의 블로그나 페이스북을 통해서 연락주시면 저희의 경험을 공유하고 또 저희보다 뛰어난 분들을 연결해드리겠습니다. 제 블로그는 다음검색에서 서두에 언급한 글을 찾으시면 됩니다.

...
옮긴이의 글이 길어지는 것은 바람직하지 않습니다.

"여러 분들의 데이터 항해를 준비하세요. 그리고 떠나세요."

2014년 3월.

==

그리고 아래는 인터넷 등에 책소개 글을 올리는데 필요하다고 해서 적었던 소개글입니다.

인터넷이 보급되면서 데이터의 역습이 시작됐습니다. 모바일 인터넷과 사물 인터넷이 일상화되면서 이제는 빅데이터의 역습이 시작됐습니다. 향후 만물 인터넷의 시대가 도래한다면 빅데이터를 넘어 스마트데이터의 역습도 대비해야 합니다. 오래 전부터 데이터는 우리의 삶에 많은 영향을 주고 있습니다. 빅데이터는 (훨씬) 더 큰 영향을 주고 있습니다. 비즈니스 세계 뿐만 아니라, 일상 생활에서의 모든 의사결정이 데이터를 기반해서 이뤄져야 한다는 얘기입니다. 이제 모든 사람과 조직은 데이터를 적시에 바르게 다루는 기술과 능력을 보유해야 합니다.

불과 3~4년 전만 하더라도 빅데이터를 다룬다는 것, 즉 데이터를 정의하고 수집하고 분석 및 해석해서 의사결정을 내리는 일련의 과정이 소수의 전문가 그룹이나 구글이나 페이스북과 같은 거대 IT기업의 전유물처럼 느껴졌습니다. 불과 몇 년 사이에 처리해야할 데이터의 양과 종류가 기하급수적으로 늘어났고, 또 이를 위한 다양한 기술과 오픈소스가 등장하면서 이제는 데이터는 누구나 접근할 수 있는 공공재가 되고 있고 빅데이터 기술은 누구나 쉽게 다룰 수 있는 보편재가 되고 있습니다.

데이터 및 기술을 누구나 사용할 수 있게 됐지만, 역설적으로 너무나 많은 오픈소스 기술들로 인해서 데이터 기술을 처음 접하는 개인이나 빅데이터 기술을 비즈니스에 활용하려는 기업들은 어떤 기술을 언제 어떻게 활용해야할지 갈피를 잡지 못하는 상황에 이르렀습니다. 이런 (데이터/기술) 혼란기에 마이클 마누체흐리의 오랜 경험을 바탕으로 빅데이터 기술과 흐름을 잘 정리한 '데이터는 언제나 옳다!'는 빅데이터 기술을 배우려는 개발자에게 좋은 길라잡이가 되고 깊은 통찰을 줄 것입니다.

==
페이스북 페이지: https://www.facebook.com/unexperienced

댓글을 달아 주세요

Share           Pin It

며칠 전에 VectureBeat에 Guy Harrison이 적은 Why Hadoop projects fail -- and how to make yours a success라는 기사를 간단하게 정리했습니다. 전체를 번역하는 데는 무리가 있어, 큰 흐름에서 의역 및 생각을 추가했습니다. 자세한 내용은 원문을 참조하시기 바랍니다.

---

클라우드 컴퓨팅이 각광을 받으면서 빅데이터, 특히 하둡은 기업IT의 메인스트림으로 들어왔지만, 무분별한 실행은 애초의 기대/약속을 충족시키지 못하고 값비싼 실패, 소위 하둡행오버 Hadoop Hangover를 경험할 가능성이 높다.

빅데이터는 구글이나 아마존의 성공을 가능케했다. 단순히 차트나 레포트를 통한 실행결정을 하는 것이 아니라, 사용자 경험을 증진시키는 비즈니스 프로세스에 직접적으로 연결된 데이터 기반의 알고리즘이다. 현재 많은 기업들이 단순히 다양한 출처의 원본 데이터를 수집, 저장하는 단계에 머무르고 있다. 데이터를 수집하고 그것의 의미를 파악하는 것만으로는 충분치 않다. 그렇기에 빅데이터 분석이 필요한데, 많은 데이터가 모일수록 덜 복잡한 알고리즘이 필요하다. (개인적으로 더 정확한 알고리즘보다 더 간단하면서 빠르면서 적응적인 알고리즘이 빅데이터 시대에 더 적합하다고 생각함) 그리고 머신러닝과 결합하여 더 많은 데이터는 더 정확한 예측 및 실행모델을 만들지만, 여전히 가장 좋은 답을 얻기 위해서는 인간의 경험과 지능이 필요하다. 데이터 수집은 빅데이터의 단지 시작일 뿐이고, 옳은 질문에 바른 대답을 제시하는 스마트 알고리즘이 필요하다.

구글이나 아마존이 성공한 이유는 많은 데이터를 수집했기 때문만이 아니라, 우수한 인재들이 모여있기 때문이다. 그들은 프로그래밍 스킬이 띄어날 뿐만 아니라, 복잡한 통계 분석 능력, 비즈니스 인사이트, 인지과학 및 창의적 문제해결 능력을 갖춘 인재들, 즉 데이터 과학자들이다. 불행히도 그런 다양한 기술 (통계, 알고리즘, 분산컴퓨팅 등)을 갖춘 인재는 늘 부족하고, 학교에서는 학위 이수정도의 커리큐럼만 가지고 있을 뿐이다. 데이터 과학자들이 늘어나겠지만, 그들은 적어도 경쟁적 비즈니스 전략, 머신러닝 알고리즘, 그리고 대용량 분산/패러렐 데이터 프로그래밍이라는 3가지 분야에 두루 전문성을 가지고 있어야지만이, 기업이 빅데이터 기반으로 미래를 예측하는데 일조할 수 있다. (즉, 기업에서 필요한 인재는 데이터 과학자이고, 그들은 전략, 알고리즘, 프로그래밍(의 조합)에 전문성을 가져야 한다.)

그리고 데이터 과학자들이 활용할 충분한 빅데이터툴도 여전히 부족하다. 맵리듀스 프로그래밍만으로는 빅데이터를 제대로 활용하는 실용적인 방법이 아니다. 빅데이터에서 빅밸류/빅인사이트를 얻기 위해서는 데이터 과학자들이 다양한 통계가설을 테스트하고, 예측모델을 만들고, 결과를 리포팅하고 비쥬얼라이즈해줄 수 있는 도구들이 필요하다. Mahout, Weka, R 등의 오픈소스들이 존재하지만, 여전히 사용하기 쉽지 않고 때로는 기업이 가진 빅데이터를 충분히 수용할만큼 스케일러블하지도 않다. 그래서 기업에서 빅데이터를 제대로 활용하기 위해서는 하둡 및 하둡에코 이상의 빅데이터 분석플랫폼 및 툴킷이 필요하다.

하둡이 많은 데이터를 경제적으로 저장, 처리할 수 있을 뿐만 아니라, 다양한 형태의 데이터를 수용할 수 있기 때문에 성공했다. 그런데 그런 다양한 포맷의 데이터가 제대로 활용되기 위해서는 포맷변경이 필요하다. 하둡은 schema on read를 허용해서 다양한 원본 데이터를 처리할 수 있지만, 여전히 적절한 데이터 스키마를 작성해야 한다. 그러나 자동으로 수집되는 데이터들은 구조가 자주 바뀌고 나중에는 구조를 제대로 파악하기가 힘들어진다는 위험도 내재한다. 그리고 데이터 생성시에 발생한 오류가 너무 늦게 발견되기도 한다. 그래서 데이터 디자인 및 수집 단계에서부터 데이터의 품질과 구조에 많은 주의를 기울일 필요가 있다.

하둡이 복잡한 분석능력을 제공해주지만 여전히 내재된 문제점들이 존재한다. 하둡의 보안성이 여전히 취약하고, 데이터 백업이 어렵고, 기업 내의 기존 모니터링 시스템과의 통합이 부족하고, 리소스 관리가 초보적이고, 실시간 쿼리가 불가능하다. 이런 점들을 고려해서 하둡 프로젝트를 진행해야 한다.

빅데이터는 많은 기업들에게 분명 복잡하지만 잠재력을 가진 파괴적 도전이다. 이제 가격경쟁력이나 애향심만으로는 부족하다. 개인화, 타게팅, 예측추천모델 등의 경쟁적인 차별화가 필요하다. 데이터 기반의 결정 및 실행 능력을 획득하는 것이 생존에 필수적이다.

---

읽으면서 스마트한 빅데이터 분석을 위해서는 결국 기술 지식, 도메인/비즈니스 로직, 그리고 사람에 대한 이해가 필요하다는 것을 느꼈습니다.

페이스북 페이지: https://www.facebook.com/unexperienced

댓글을 달아 주세요

Share           Pin It

데이터 분석을 업으로 하는 사람이 웹디자인을 논하는 것은 좀 주제넘은 것같고, 또 이 주제를 자세히 다루기 위해서는 많은 조사와 정리가 필요하기 때문에 이 글에서는 원론적인 선언만을 다루려 한다. 디자인이라는 것이 일종의 심미, 즉 눈에 보이는 아름다움을 다루는 것 (UI)이다. 그러나 스티브 잡스도 언급했듯이 최근에는 디자인의 기능적인 측면 (UX)도 중요시되고 있다. 그러나 겉으로 드러나는 UI나 겉으로 기능하는 UX에 더하여, 그것을 구성하는 데이터에 대한 인식도 필요하다. 여기서 말하는 데이터란 화면에 뿌려지는 정보뿐만 아니라, 이면에 존재하는 것 -- 소위 말하는 로그 데이터 --를 의미한다.

웹 아카이브에 들어가서 특정 사이트의 히스토리를 검색해보면 예전의 모습이 참 촌스럽고 사용성도 많이 떨어지는 것을 느낀다. 최근 웹사이트들은 심미적으로 많이 세련되었고 사용성도 많이 개선되었다. 그러나 여전히 데이터/로그 관점에서는 크게 변한 것같지가 않다. 여전히 많은 웹사이트들은 아파치 로그 이상의 기록을 남기지 않고 있고 그런 로그를 활용해서 사이트 리뉴얼에 제대로 활용을 못하는 것같다. 물론 최근에 빅데이터가 이슈가 되면서 로그 및 데이터의 중요성이 주목받기 시작했으나 여전히 갈 길이 멀다.

아파치 로그로는 특정 사이트의 PV나 UV 등은 측정할 수가 있다. 이는 10년 전에도 측정이 가능했던 것들이다. 특정 유저가 어디에서 유입되고 어디로 흘러가는지 정도도 파악할 수가 있다. 이정도의 데이터 또는 데이트흐름은 웬만한 서비스에서 대부분 활용된다. 이제는 더 진일보된 데이터 수집 및 분석이 필요하다. 이름있는 큰 회사들은 그나마 그 필요성을 인식해서 다양한 데이터를 수집해서 분석하고 또 실서비스에 반영하고 있지만, 여전히 많은 중소 웹사이트에서 로그 수집은 사치일지도 모르겠다. 그리고 큰 회사의 서비스들도 여전히 로그 수집이 제대로 이뤄지지 않고 있다. 일단 개인정보라든가 필요이상의 데이터를 수집하는 등의 이슈는 일단 논외로 두자.

웹디자인이라는 것이 간단히 말하면 어떤 정보를 어느 위치에 어떤 식 (색상이나 크기 등)으로 배치/표현할 것인가를 다루는 거다. 사용자들이 편하게 느끼는 색상이나 폰트크기를 정하고, 동선이 자연스레 흘러가도록 만드는 것이 웹사이트 디자인이었다. UI/UX의 관점에서는 맞다. 그러나 실제 화면에 배치되었던 정보가 사용자들의 주목을 받고 있는지 얼마나 잘 활용되고 있는지 또는 더 나은 색상이나 구성이 존재하는지 등은 그저 전문가의 경험이나 직관에 의해서 평가되는 것같다. A라는 링크를 상단 100px에 위치할 때와 200px에 위치할 때의 클릭률의 차이라든가, 색상을 파란 계열로 할 때와 붉은 계열로 할 때의 사용자들의 반응의 차이라든가 그런 종류의 테스팅이나 평가를 수행하는 곳은 별로 많지가 않은 것같다. 그저 새롭게 리뉴얼한 사이트의 PV/UV의 증감정도만 체크해서 잘됐다 못됐다정도로 판단하는 것같다.

특정 정보가 노출되었는지, 어느 위치에 어떤 식으로 노출되었는지, 함께 노출되었던 다른 정보들은 무엇인지, 그리고 실제 클릭이 발생했는지 등과 같은 것들이 구분 가능하도록 로그에 남겨져야 한다. 이런 로그가 존재해야지 A/B 테스트를 통해서 더 최적의 노출요소 및 개수 등이 파악되고 이후의 사이트 리뉴얼에 활용될 수가 있다. 그러나 현재 대부분의 웹사이트에서 이런 정보를 얻을 수 있는 방법이 전무하다. 웹사이트 디자인 또는 리뉴얼 작업은 으레 겉으로 보이는 요소를 변경하는 것에 초점을 맞췄기 때문에, 그 속에서 활용되는 데이터에 대한 고려는 애초부터 없었던 경우가 많다. 실제 로그를 남겨야되는가?에 대한 의식이 없는 경우도 많다. 어떤 면에서는, 물론, 쌓이는 로그를 제대로 분석, 활용할 방법이 없었기 때문에 로그를 제대로 남기지 않았던 점을 부인할 수도 없다.

웹디자인도 이제 데이터 기반으로 이뤄져야 하고 테스트 가능해야 한다. Data-Driven Design 및 Design for Testing 개념이 제대로 연구되고 정립될 필요가 있다. 디자인인 인터페이스의 문제이기도 하고 익스피리언스의 문제이기도 하지만, 그 이면의 행동패턴 또는 데이터의 문제이기도 하다. 구글은 항상 새로운 요소를 추가/삭제/변경할 때마다 A/B 테스트를 거친다고 한다. 조금이라도 사용자들의 주목을 받는 사용성이 높은 것을 택한다고 한다. 디자인 단계부터 데이터의 활용을 생각하지 않는다면 그런 A/B 테스트가 불가능하다. 이제 그런 종류의 프랙티스 또는 컨벤션이 모든 사이트에도 적용되었으면 하는 바람이다.

처음 이 글을 생각할 때는 구체적으로 어떤 데이터를 어떤 식으로 남길 것인가?를 다루려고 했지만, 앞서 말했듯이 조사와 정리가 많이 필요한 작업이라 다음 기회에...

(2013.05.27 작성 / 2013.05.29 공개)

페이스북 페이지: https://www.facebook.com/unexperienced

댓글을 달아 주세요

Share           Pin It

얼마 전에 KISTI에서 발표 요청이 들어왔다. 장소가 대전이고 발표일도 수요일이라 고민하는 사이에 이미 다른 발표자로 채워졌다는 소식을 듣고 결국 발표는 불발로 끝났다. 그런데 발표요청을 수락할까 말까를 고민하면서 이미 내 머리는 발표내용을 뭘로 할까?로 고민하고 있었다. 그래서 그때 생각했던 것이 아까워서 일단 발표자료를 만들기로 했고, 마침 다음 주에 팀워크샵에서 발표하기로 했다. 아래는 어제 밤에 정리한 1차 드래프트다.

전혀 새로운 주제를 가지고 발표할 수도 없으니 그냥 인터넷 및 데이터마이닝 트레드에 대한 내용을 준비했다. 2010년도에 모교 (포항공과대학교) 후배들과 울산대 학부생들을 위해서 이미 비슷한 주제로 발표를 했었다. 당시에는 8개의 C자로 요약한 인터넷 트렌드, 검색이야기, 그리고 소셜에 대한 내용을 1~2시간 정도 자유롭게 얘기를 했다. 그런데 새로 만드는 발표자료를 예전 것과 너무 겹치는 것은 식상할 것같아서, 2010년도에 적었던 8개의 C워드는 그냥 나열만하고 당시에 미쳐 넣지 못했던 새로운 3개의 C워드를 추가하기로 했다.

이미 예전에도 글을 적었지만 (인터넷 검색 소셜) 2010년도에는 실시간, 위치, 그리고 소셜의 부상을 다룬 Context, 애플과 구글을 중심으로 벌어졌던 IT기업들 간의 다양한 경쟁관계를 다룬 Competition, 플랫폼과 에코시스템의 주도권 싸움인 Control, 에버노트 넷플릭스 등의 다양한 클라우드 서비스들의 등장을 알리는 Cloud, 대중의 지혜를 활용한 서비스들을 위한 Crowds, 아이패드의 등장과 함께 시작된 소비경제를 뜻하는 Consumption, 편의를 위해서 희생되는 개인정보를 다룬 Convenience, 그리고 마지막으로 모든 것들이 (특히 모바일에서) 연결되는 Connection 이렇게 8개의 C워드로 당시를 정리했었다.

2010년도에 제시했던 단어들이 여전히 유효하고 어떤 것들은 더욱 강화되었다. 특히 Cloud는 빅데이터라는 시대의 화두를 만들어냈고, 당시에는 모바일 투게더 전략이 맞았지만 이제는 더디어 모바일 퍼스트 또는 모바일 온니로 진화했다. 2010년에 전혀 허튼 단어를 선택하지 않았다는 점에 안도감을 느끼면서 새롭게 3개의 단어를 더 추가했다.

2010년도에 위의 발표를 한 직후에 가장 아쉬웠던 단어가 바로 Curation이었다. 아직 핀터레스트가 대중에게 잘 알려지기 전에 발표자료를 만들었기에 Curation이라는 개념을 발표자료에 넣을 엄두를 못 냈던 것이 나의 근시안이었다. 그래서 새롭게 발표자료를 만들면서 가장 먼저 Curation을 추가했다. 특히 아침에 공개했던 글 (참고)에서도 구글리더의 종료는 큐레이션의 부상을 상징한다고 말했다.

두번째로 추가한 단어는 Container다. 이것은 올해 2월 초에 공개했던 '미디어는 메시지다'라는 글에서 소개했던 개념이다. 정보의 관점에서 컨텐츠를 어떻게 이해할 것인가?를 다루었다. 인터넷의 초기에는 컨텐츠가 왕이었지만, 지난 몇년 동안 컨텍스트는 또 다른 컨텐츠로써의 지위를 차지했다. 그런데 맥루한의 말과 같이 그런 컨텐츠와 컨텍스트를 담고 있는 컨테이너도 컨텐츠를 정의하는데 중요한 요소임을 깨닫게 되었다. '미디어가 보여주는 것과 진실'이라는 그림이 보여주듯이 컨텐츠를 담고 있는 컨테이너도 중요한 컨텐츠다. 그리고 그런 컨테이너는 특정 기업의 입장에서는 브랜드이기도 하다.

마지막으로 추가한 단어는 Culture다. Culture에 관해서도 작년에 몇 편의 글을 남겼다. (참고, 참고 등) 내가 문화라고 말하는 것은 두가지 측면이 있다. 첫번째 측면은 흔히 말하는 문화예술을 뜻한다. 기업 내에서 조직원들이 다양한 문화 생활을 즐기면서 그런 가운데 창의적인 사고가 만들어진다는 의미다. 스티브 잡스가 말했던 애플은 인문과 기술의 교차점에 있다는 말에서 밝힌 그 인문 (liberal art)를 의미하는 문화를 뜻한다. 두번째는 조직/기업의 문화를 의미한다. 즉 어떻게 하면 기업이 더 창의적으로 성장할 수 있을까?는 결국 그 기업문화에 달려있다. 경직된 조직이 될 것인가 유연한 조직이 될 것인가 등은 모두 그 기업문화에 달려있다.

여담으로 2010년도에는 증강현실 AR이 주목을 많이 받았는데, 2013년 현재는 Internet of Things가 많은 주목을 받고 있다. 2010년과 2013년을 비교해보면 큰 차이가 없는 것같지만, 또 그 이면에는 엄청난 변화가 있었다는 것을 알 수 있다. 그런 의미에는 우리는 변화를 제대로 쫓아갈 수가 없고 또 그런 변화의 결과가 미래를 더욱 불확실하게 만들고 있다. 그래서 경험해보지 못한 과거를 우리는 살아갈 것이다라고 계속 말하는 것이다.

발표자료의 뒤쪽에 나온 데이터사이언스 (스마트데이터와 예측분석)의 내용은 '빅데이터의 시대는 갔다'를 참조하기 바란다.

(2013.03.25 작성 / 2013.03.28 공개)

댓글을 달아 주세요

Share           Pin It

VentureBeat의 기사를 읽고 글을 적습니다. (참고. Big data is dead. What's next?)

언제나 기술용어가 마케팅용어로 변하는 시점이 되면 죽음 death이라는 단어가 등장합니다. 마케팅의 탄생 시점이 늘 기술의 사망 시점과 묘하게 겹치는 것같다. 인터넷만 국한시켜 생각해보면, 한 때 웹2.0이 기술용어인가 마케팅용어인가를 두고 논쟁이 벌어졌습니다. 그런 논쟁은 기술이 번성하고 이제 마케팅이 시작되는 시점에 벌어졌습니다. 그리고 최근에는 소셜이 그런 과정을 거쳤고, 이제는 클라우드나 빅데이터가 같은 운면에 접어들었습니다. 늘 그랬습니다. Geek의 손을 떠난 새로운 제품/서비스는 결국 마케터들의 손에 전달됩니다. 그 순간 매번 기술의 죽음이 언급됩니다. 마케팅이야 말로 기술과 인물의 결합에서 만들어진 것이고, 기술이 뿌리면 마케팅이 거두는 것입니다. 그러나 마케팅이 시작되는 시점에 기술이 힘을 잃게 됩니다. 그러나/그래서 또 다른 새로운 기술이 등장합니다.

기사에서도 바로 이 점을 말합니다. 많은 회사들과 서비스들이 빅데이터라는 이름 아래 모임으로서 빅데이터의 본래적 의미가 사라졌습니다. 사실 빅데이터라는 말 자체에 -- 데이터를 제외하고는 -- 특별한 기술적 향기가 전혀 없었습니다. 대용량처리, 분산처리 또는 병렬처리에서 느껴지던 기술적 향기가 클라우드 컴퓨팅이나 빅데이터라는 이름으로 불려지면서 이미 사라진지 오래입니다. 일반인들이 이해하는 과정에서 클라우드니 빅데이터라는 말이 마케터들에 의해 만들어진 점을 부인할 수가 없습니다. 실제 많은 이들이 클라우드나 빅데이터를 입에 달고 다니지만 그 본질과 속성을 제대로 알고 말하는 이들이 과연 몇이나 될까?가 항상 궁금했습니다. 10%로 잡는다면 제가 너무 긍정적인 사람일 것입니다.

저자는 빅데이터 이후를 스마트데이터 Smart Data, 데이터 사이언스 Data Science, 뉴에스큐엘 NewSQL, 그리고 예측분석 Predictive Analytics 등에 주목하라고 말합니다. SQL의 관계형 데이터가 최근 NoSQL이라는 비정형 데이터로 변해가고 있고, 더 복잡한 데이터를 위한 새로운 SQL의 필요성은 생길 듯합니다. 그러나 SQL은 너무 기술적인 부분이라 제가 더 자세히 언급할 엄두가 나지 않습니다. 그리고 최근에 종종 듣는 데이터 과학도 기존의 데이터 수집, 분석, 활용을 아우르는 총체로써의 메타포를 제공해주기 때문에 짧게 다루기가 어려운 주제입니다. 제가 처음 기사를 보면서 스마트데이터라는 표현이 눈에 띄었고 (그런데 이것도 너무 마케팅 냄새가 납니다), 오래전부터 스스로 선제적 대응이라 부른 예측 분석은 늘 주목하고 있던 부분입니다. 그런데 스마트데이터와 예측분석을 굳이 따로 떼어서 설명하는 것이 맞지 않다고 생각합니다.

구슬이 서말이라도 꿰어야 보배다라는 속담이 있습니다. 우리에게 많은 데이터가 있지만 그 속의 의미를 찾아내고 서로 연결시키는 정보화 과정이 없으면 데이터는 그저 널부러진 구슬에 불과합니다. 그리고 정보에 가치를 부여하지 못하면 지식으로 진화하지 못하고, 그런 지식을 실생활에 적용해야지 그제서야 삶의 지혜가 됩니다. 데이터를 정보로, 지식으로, 지혜로 만드는 것이 데이터 처리 data processing, 데이터 분석, data analysis, 그리고 데이터 마이닝 data mining입니다. 이런 과정이 없으면 데이터는 그냥 메모리/디스크 공간만 차지합니다. 빅데이터가 대용량 다양성 속도 등에서 장점이 있지만, 가공과 분석의 과정이 없으면 빅데이터도 그저 많은 공간만 차지하는 애물단지입니다. 빅데이터를 분석해서 실서비스에 반영되고 그 서비스를 통해서 사용자들에게 가치를 제공해주는 것이 스마트 데이터입니다.

데이터 분석이 그저 과거의 트렌드와 패턴만 확인하는 것이라면 이 또한 -- 그저 자기 만족일 뿐 -- 큰 의미가 없습니다. 과거는 미래를 가리킵니다. 미래가 항상 과거에 있다는 말이 아니라, 미래에 대한 많은 힌트를 준다는 의미입니다. (그리고, 어떤 미래는 분명 과거에 있습니다.) 데이터 마이닝은 과거를 보지만 항상 미래를 염두에 두고, 모든 결과는 미래의 액션을 위한 것입니다. 기사에 언급된 다양한 추천엔진이라든가 사기방지시스템 등이 모두 미래의 액션을 촉진 또는 억제시키는 것입니다. 데이터를 통해서 미래를 예측하는 것이 예측분석이고, 이를 통해서 사용자의 미래 행동/판단을 지원하는 것이 스마트데이터입니다. 그러나 항상 염두에 둬야하는 점은 '예측분석은 당위성이 아니라 가능성을 제공한다'는 것입니다. 모든 미래가 과거에 있지 않다는 말의 의미입니다. 소위 말하는 블랙스완은 많은 데이터나 정교한 알고리즘으로 찾지 못할 수도 있습니다.

빅데이터 시대는 갔다라고 적었지만 여전히 빅데이터는 스마트데이터와 예측분석의 기저/인프라를 제공합니다. 그 인프라 위에 어떤 알고리즘/창의성을 올려놓을 것인가가 어떤 새로운 시대를 맞을 것인가?를 결정해줍니다. 향후에도 데이터의 양은 더더욱 늘어날 것이고 데이터의 종류도 더더욱 다양해질 것이고, 또 그것들을 가공하고 피드백하는데 필요한 시간은 더더욱 짧아질 것입니다. 이런 환경적 추세에 우리 인간의 지능/창의성을 더하여 미래를 대비하는 것이 미래예측이고 스마트 데이터입니다. 빅데이터 시대에는 '할 수 있다'를 내세웠다면, 스마트 데이터 시대에는 '이룩했다'고 자랑할 수 있어야 합니다. 빅데이터를 잘 활용하면서도 회의적으로 보는 이유가 많은 이들이 그저 '이것도 할 수 있다'만 말하기 때문입니다. 그것을 띄어넘어서 실생활에 진정한 가치를 줄 때 진정한 스마트 데이터 시대가 열립니다.

...

글을 적는 중에 재미있는 그림이 있어서 공유합니다. 데이터마이닝책을 찾아보다가 "Data Mining: Practical Machine Learning Tools and Techniques, 3rd Edition"을 발견했습니다. 2nd 에디션에 서는 녹색 나뭇잎 사이에 있는 녹색 도마뱀 사진을 표지로 삼았는데, 3rd 에디션에서는 아래와 같이 황금들판에 한마리 맹수 사진을 담고 있습니다. 만약 녹음이 우거진 숲속의 누른 맹수라든가 누른 벌판의 초록색 도마뱀이라면 눈에 잘 뛰었을 것입니다. 데이터 속의 의미라는 것이 때로는 그렇게 쉽게 발견되기도 하지만, 많은 경우 아래의 표지와 같이 우리 눈에 쉽게 띄지 않습니다. 아래의 사진과 같이 모호함에서 조금 덜 모호함을 만드는 과정이 데이터마이닝입니다. 집단지성이라는 이름으로 빅데이터가 모든 것을 해결해줄 것같지만, 때로는 더 많은 데이터가 그저 모호함만 가중시킬 수도 있습니다. 그래서 스마트함이 필요합니다. 아래의 맹수는 나의 행동을 경계하는 것일까요 아니면 나를 잡아먹으려고 준비하는 것일까요? 맹수를 발견하는 것이 데이터마이닝이었다면 맹수의 다음 행동을 예측해서 대비하는 것이 스마트 데이터마이닝입니다.

Data Mining: Practical Machine Learning Tools and Techniques, 3rd Edition

이번 글은 어느 때보다 더 두서없이 적었습니다.
(2013.02.25 작성 / 2013.03.06 공개)

댓글을 달아 주세요

Share           Pin It

Wired에 재미있는 사이트가 하나 소개되었습니다. (Wired 기사 링크) Tweetping이라는 서비스입니다. 이름 (Tweet + Ping)이 의미하듯이 전세계에서 올라오는 트윗의 활동성을 실시간으로 분석해서 보여주는 서비스입니다. 지역별로 트윗수나 단어수, 최근에 사용한 해쉬태그 등을 보여줍니다. 기능면에서는 특별할 것도 없지만, 이렇게 트위터의 활동성을 시각화해서 보여준다는 아이디어가 참 좋습니다. 이정도 데이터라면 빅데이터 플랫폼을 이용했을 법하고, 하단에 명시되었듯이 Node.js 등의 최근에 많이 사용하는 오픈소스를 사용해서 보여주고 있습니다. 2013년 2월 4일 (월요일), 오후 2시경에 화면을 캡쳐했는데, 트윗의 절반 이상이 북미 (NA)에서 발생하고 있다는 것도 바로 확인할 수 있습니다. 저는 사이트에 접속해서 바로 화면을 캡쳐해서 수치가 높지 않은데, 몇 시간/며칠을 모아서 보면 또는 시계열로 동영상을 만들어서 보면 재미있는 현상도 발견할 수 있을 듯합니다.




댓글을 달아 주세요

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 공개)

댓글을 달아 주세요