카테고리 보관물: 미분류

워드프레스 구텐베르크에서 Mermaid 다이어그램 그리기

graph LR M --> e e --> r r --> m m --> a a --> i i --> d

위와 같은 다이어그램을 그리는 R패키지중에 DiagrammeR라는 것을 소개드리면서 Mermaid에 대한 설명을 잠깐 했었습니다.  

지난 포스트 링크입니다.
DiagrammeR – R 다이어그램 그리기

워드프레스 구텐베르크 편집기를 사용할 때 조금 손이 가지만 그래도 워드프레스의 설정에서 고난의 삽질을 하지 않고 간단하게 Mermaid를 사용하는 방법을 설명드리려고 합니다. 데이터사이언스와 관련없는 포스트는 이 블로그에는 잘 안쓰지만 일탈을 해봤습니다.

구텐베르크 Gutenberg

Mermaid를 워드프레스(WordPress)에서 사용하는 방법을 설명하기전에 구텐베르크 얘기를 먼저 해야 하겠습니다.

워드프레스가 글 편집기로 구텐베르크(Gutenberg)라는 것을 쓰도록 유도한지가 꽤 된 것 같습니다. 이 포스트를 쓰는 시점으로부터 수개월 전으로 기억합니다. 원래 구텐베르크가 워드프레스에 기본 패키지에 포함되어 있지는 않는 것 같은데  “편집기로 구텐베르크 써보지 않겠어?” 라는 식으로 관리자화면에서 자꾸 물어보길에 예전에 무심결에 눌러서 플러그인을 설치한 후에 제 블로그도 구텐베르크로 작성하고 있습니다. 그 뒤로는 전 너무 멀리 와버렸습니다. ‘ㅁ’;

구텐베르크는 포스트를 쓰면서 블럭 단위로 콘텐트를 나눠서 관리하고 편집하는 방식인데 위지윅(WYSIWYG)에 중점을 더 둔 편집방식입니다. 물론 그전 방식인 클래식 에디터를 같이 쓸 수 있습니다만 클래식 편집기로 작성한 글은 클래식편집기로만 열리고 구텐베르크로 작성한 것은 구텐베르크 편집기로 열립니다. 

구텐베르크 편집기를 쓰면 편리한 점이 더 많아서 저는 구텐베르크를 주로 쓰고 있습니다. 구텐베르크라는 이름처럼 출판 편집을 위한 소프트웨어를 사용하는 기분이 듭니다.

구텐베르크는 사용하려면 적응기간이 조금 필요합니다. 버그도 아직 꽤 있습니다. 복잡한 구조의 포스팅을 안하시는 분들께는 좋겠고 복잡한 요소들이 잔뜩 있는 포스트를 장벽이 큽니다.

기존에 잘 쓰던 플러그인과 충돌을 하거나 작동이 안되는 부분도 꽤 많아서 플러그인을 별도로 찾아서 추가 설치해야 하거나 포기해야 하는 부분도 상당합니다. 그래서 클래식 편집기에서는 플러그인만 설치하거나 익숙하게 했던 작업도 구텐베르크를 쓰면서 부터는 많이 힘들어졌습니다.

워드프레스에 Mermaid.js 추가하기

워드프레스에 Mermaid.js를 사용하려면 Mermaid.js와 CSS하나만 추가해주면 됩니다. 그런데 이게 플러그인이 없으면 추가하기가 조금 곤란합니다. 현재까지 제대로 지원하는 플러그인은 못찾았고 functions.php를 수정하는 방법이 일반적인데 그렇게하고 싶지는 않았습니다.  저렇게 하면 워드프레스를 업그레이드하거나 테마를 바꾸거나 하면 난장판이 되었던 경험이 있습니다.

그래서 간단하게 붙이는 방법은 글편집에서 워드프레스 구텐베르크 타입에 HTML 요소라는 것이 있어서 블럭 유형을 HTML으로 바꾸고 다음과 같이 HTML 코드를 넣으면 됩니다.

소스 코드에서 js 파일의 링크과 css는 적당히 최신의 것으로 찾아서 바꾸시면 되고 Mermaid코드를 넣을 때 code 태그에 class를 mermaid로 지정하시는 부분이 핵심입니다. code 태그 대신 div나 pre 태그를 사용하면 “>” 기호와 다른 특수문자들을  인코딩(특수기호들을 &#으로 시작하는 코드로 바꾸는 것)하기 때문에 Mermaid.js가 다이어그램 문법을 해석하지 못해서 그림이 표현이 안됩니다. 현재 워드프레스에서는 code 태그의 안쪽은 HTML 인코딩을 하지 않습니다.

위의 소스코드에서 js와 css 파일을 인클루드하는 것은 따로 보관해 두거나 전에 작성했던 포스트에서 복사해서 붙이기는 방법을 쓰고  Mermaid 코드 부분만 따로 작성해서 code 태그 안쪽에 붙여 넣으면 Mermaid 다이어그램을 붙여 넣을 수 있습니다.

DiagrammeR – R 다이어그램 그리기

R 패키지중에 DiagrammeR라는 다이어그램(diagram)을 그릴 수 있게 해주는 것이 있습니다. 다이어그램은 플로우차트(flow chart), 간트 차트(gantt chart), 시퀀스 다이어그램 (sequence diagram)같은 것입니다.

RStudioDiagrammeR 스크린샷

다이어그램을 그릴 때 쓰는 도구는 Visio (Windows 쓰시는 분들) 아니면 OmniGraffle (Mac 쓰시는 분들) 아니면 PowerPoint 와 같이 손으로 그리는 것들이 있고 GraphViz 또는 Mermaid와 같이 정해진 문법을 텍스트로 입력하면 해석해서 시각적으로 표현해주는 도구가 있습니다.

DiagrammeRGraphVizMermaid를 묶어서 연동해 놓은 패키지인데 3가지 방식으로 그래프를 그리게 해줍니다.

  1. Mermaid 문법을 텍스트로 입력한 후 텍스트를 해석해서 렌더링
  2. GraphViz 문법을 텍스트로 입력한 후 텍스트를 해석해서 렌더링
  3. R함수를 사용해서 노드와 엣지를 구성하고 렌더링

패키지를 사용하던 중 GraphViz는 원래 C로 만들어진 binary이므로 R에서 연동해서 사용할 수 있습니다만 Mermaid는 Javascript로 만들어져서 이 두가지를 어떻게 한꺼번에 연동해서 그래프를 시각적으로 표현하게 했는지 갑자기 궁금했습니다.
그래서 살펴봤더니 GraphViz.js와 Mermaid.js를 가져다 연동한 것이고 렌더링된 결과를 표현할 때는 htmlwidgets 패키지를 사용하는 것입니다.
그러니까 결국 웹브라우저를 열고 Javascript를 이용해서 렌더링하는 방식입니다.

그래서 R-GUI에서 렌더링을 하게 되면 웹브라우저가 열립니다.  RStudio에서 렌더링을 시도하면 연동이 되어서 웹브라우저가 실행되지 않고 그래프 패널에 바로 렌더링된 결과를 표현해 줍니다.  위에 넣어 놓은 스크린샷 이미지에서 확인할 수 있습니다.

앞서 말한 렌더링을 하는 세가지 방식중에 Mermaid 문법을 사용하는 것과 GraphViz 문법을 사용하는 것은  RStudio에 연동되어서 파일을 편집할 수 있게 제공하고 있기때문에 R 코드에서 DiamgrammeR 패키지를 로딩할 일이 없게 만들기도 합니다.

RStudioDiagrammeR를 연동해서 .mmd 확장자를 가지는 Mermaid 파일과 .dot 확장자를 가지는 Graphviz dot 파일을 바로 편집하고 코드 하일라이트도 되고 렌더링할 수 있도록 해줍니다.
아래의 링크에서 내용을 확인할 수 있습니다.

https://blog.rstudio.com/2015/05/01/rstudio-v0-99-preview-graphviz-and-diagrammer/

위의 3가지 방식 중 2가지는 앞서 말씀드린 것 처럼 RStudio와 연동으로 인해 DiagrammeR 패키지의 함수를 사용할 일이 없게 만들지만  DiagrammeR 함수를 이용한 방식의 렌더링을 사용하면 data.frame에 있는 데이터를 연동해서 그래프를 그릴 수 있습니다. 이게 가장 큰 장점이지요.

아래는 각각의 방법으로 만든 간단한 장난감 예제입니다. 

Mermaid 문법을 이용한 렌더링

Mermaid 문법을 이용한 예제입니다.

GraphViz 문법을 이용한 렌더링

GraphViz 문법을 이용한 예제입니다.

GrammerR의 R 함수를 이용한 렌더링

전통적인 스타일의 R 함수를 사용한 예제입니다. 아래의 함수들은 DiagrammeR 최신 패키지를 설치해야만 됩니다. 최근에 함수 이름에 변화가 있었던 모양입니다.

dplyr와 연동한 DiagrammeR

역시 RStudio에서 만은 부분을 기여한 패키지인 만큼 dplyr 스타일의 매우 스타일리쉬한 파이프라인 형태의 코딩도 지원합니다.

추가로 네트워크 분석 관련 패키지인 igraph에서 생성한 객체를 DiagrammeR 형태로 변환하는 함수들도 제공합니다.  사용해 보지는 않았습니다. ^^;

SPSS syntax를 R로 변환해주는 웹서비스 translate2R

SPSS 신택스를 R 코드로 자동변환해주는 웹사이트가 나왔습니다. Use R! 2014에서 발표했나보네요.

Use R! 컨퍼런스는 쓸만한 것이 꽤 많이 발표되는 좋은 컨퍼런스입니다.

온라인에서 SAS나 다른 랭귀지를 R 로 변환해 주는 곳을 볼 수 있는데요. 주로 용역인 곳이 많습니다.

그러니까 코드를 등록해주거나 요청을 하면 실제로는 사람이 하는 것이죠. 자동 변환이 잘 안되기 때문일텐데요.

제가 SPSS를 쓰지 않으니 모르겠지만 서서히 자동변환이 나오긴 하는 군요. 웹사이트 도메인을 보면 독일에서 만든 것 같습니다.

자세한 내용은 eoda의 사이트를 참조하세요. 현재는 무료 베타인데 나중에 상용화될지 어떨지는 잘 모르겠습니다.

참조: eoda 웹사이트

Reproducible Research – 재현가능연구

Reproducible Research에 대한 포스팅입니다.

이게 뭔지? 어떻게 하는 것인지? 이런 것들에 대한 내용입니다.

Reproducible Research는 연구나 분석을 할 때 사용한 코드, 데이터, 리포트를 한꺼번에 넣어서 다른 사람들이 받으면 그대로 재현이 가능하도록 하게 배포하고 공유하자는 계몽운동입니다.

어헐… 리서치 분야의 새마을운동인가?

사실 히스토리는 꽤 오래되었습니다. 17세기 부터라고 하는데 그 시대 사람이 아니어서 모르겠구요.
제가 알고 있는 최근 관련 사건은 2006년 Duke 대학의 논문(암세포 관련) 사건인데, 배포된 논문을 재현하는데 시간이 너무 걸려서 문제점을 나중에야 발견했고 그 사이에 그 논문을 근거로 시작한 연구 5개가 졸지에 중단된 사건입니다.

코드와 데이터와 리포트를 한꺼번에 배포하는 것이라고 했는데.
그러면 “Reproducible Research는 코드하고 데이터하고 PDF를 한꺼번에 압축해서 주면 되는거네?” 라고 생각할 수 있습니다.

그렇게 하는 사람도 아직 많습니다. ^^. 하지만 핵심요체는 이런걸 더 쉽게 하자는 것이고 피드백도 쉽게 받을 수 있어야 한다는 것입니다.

Reproducible Research는 소프트웨어 구현체를 위한 개발소스를 배포하는 것에 대한 것이 아닙니다. 단편적인 예로 논문을 배포할 때 논문에 사용한 코드와 데이터와 설명을 한꺼번에 배포하는 것 정도로 이해하면 빠를 것 같습니다.

압축파일로 전달하거나 하는 것은 완전히 종료된 연구결과는 그렇게 해도 되겠지만 어떤 것들은 자신의 연구 결과물도 계속 고쳐나갈 수도 있기 때문에 그렇게 하면 번거롭습니다. 그래서 코드를 계속 형상관리하고 자동으로 생성해서 배포하려고 많이 합니다.

우선 하기전에 몇가지 의문에 대해서 살펴보면…

어느 분야에서 쓰는 것이냐?

  • 연구소, 아카데미 등 학술쪽이 메인입니다.

    각종 논문 양산소들

  • 데이터 분석

    굉장히 좋습니다.

  • 데이터 사이언스

    설마 데이터 사이언스가 주구장창 구현체 개발만 하는 것이 아니라면…

꼭 논문을 쓰거나 어떤 연구소에서 연구를 하는데만 쓰는 것은 아닙니다. 메인이 그쪽이이긴 하지만 인터넷기반의 온라인의 발달로 R&D쪽과 관련이 있다면 모두 해당됩니다.

흐름상 꼭 해야 하는 거야?

남들이 한다고 다 따라할 필요는 없다고 봅니다만 흐름이 있는 것은 분명합니다. 꼭 해야 하는 것은 아니지만 어느덧 많은 사람들이 자기의 연구결과나 분석결과를 온라인에 배포하는 것이 일상화되었습니다.

내 피땀어린 연구물을 왜 배포 하나?

  • 첫번째는 Personal Branding 이유가 많아 보입니다. 어필하는 것이지요. 개인을 상품화
  • 두번째는 연구물을 공유해서 다른 사람들의 피드백을 받음으로써 자기 발전에도 도움이 된다고 생각하는 것입니다
  • 세번째는 논문 점수… 패쓰!

개인의 취향이고 하기 싫으면 안해도 되지만 추세는 배포해서 검증도 받고 성과도 알리는 것입니다. 일종의 자신감 표현일 수도 있고 우물안 개구리로 살지 않겠다는 생각일 수도 있겠구요.

배포를 걱정하는 이유가 내가 고생해서 연구한 것을 왜 남에게 거저 주느냐? 라는 이유일텐데요. 자신의 연구 결과물이 매우 좋다면 배포를 당연히 하지 않겠지요. 하지만 그런 뛰어난 결과물을 만드는 경우가 얼마나 될까요?

내 연구물은 약간의 불가피한 어쩔수 없이 안타깝고 애절한 이유로 조작을 했기 때문에 다른 사람들이 절대 재현해서는 안돼! 아~ 님! 그러시면 안돼요!

Reproducible Research에 필요한 것

온라인 IT활용능력이 필요합니다. 압축파일을 USB에 담아서 주는 세상이 어느덧 지나버린 것 같습니다.

형상관리 또는 코드 보관용 스토리지

보통 리서치를 전문으로 하시는 연구원들을 보면 연구성과물의 백업에 대해 예민한데요. 당연한것 이 성과물이 날아가면 인생이 과거로 회귀하기 때문입니다.

지능은 그대로 나이는 젊어지는 그런 회귀가 아니라 나이는 그대로 성과는 예전으로 돌아가는 회귀. @.@

보통 Reproducible Research에서는 온라인 소스코드 레파지토리를 많이 사용합니다.

물리백업은 외장하드를 여러개 사용하시던지 스토리지를 쓰시던지 각자의 방법이 있잖아요?

많이 발견되는 순서대로 보면

  • Github: 공짜인데 private은 돈 받아요
  • Bitbucket: 공짜인데 private 1개 공짜. 추가는 돈 받아요
  • Dropbox: 형상관리는 아니지만 물리백업의 위험을 최소화하기 위해서
  • 기타: 찾아보면 더러 있습니다.

private repository는 남들에게 안 보이게 숨기는 레파지토리입니다.

온라인을 사용하는 이유는 링크만 던져줘도 자료를 쉽게 공유할 수 있기 때문입니다. 게다가 삭제해도 복원이 가능하고 매우 안정적입니다. 대신 형상관리 소프트웨어를 사용하는 방법을 익혀야 하겠지요. SVN, CVS, GIT 등을 잘 쓰신다면 문제가 별로 없습니다.

살펴보면 대체로 Github을 많이 쓰는 것 같습니다.

형상관리를 회사나 연구소내에서 따로 구축해서 사용하는 경우도 많은데요 백업이나 관리가 잘 되야 하겠지요. 자료를 찾아 보시면 구축하는 방법등이 잘 나와 있습니다.

내부 형상관리가 통째로 날아가면 연구소 폐쇄 또는 폐업… 하지는 않더라구요.

데이터 배포용 레파지토리

연구물을 배포할 때 코드와 함께 사용한 데이터를 같이 주어야 하는데요. 알고리즘을 만들거나 분석기법을 만들거나 응용 분석을 하거나 해도 사용한 데이터가 있을 것입니다.
포함해야 하는 이유는 다른 사람이 재현을 해야하기 때문입니다. 코드만 가지고는 정확히 재현이 안되니까요.

데이터를 배포하는 방법은 크기나 데이터의 출처에 따라 배포하는 방식이 달라집니다.

  • 데이터의 사이즈가 매우 작은 경우

    코드에 넣어 줍니다. 코드에 변환해서 넣는 것이 대부분 가능합니다. 최근에는 데이터들의 크기가 커지기 시작하면서 이 방법은 점점 어렵게 되고 있습니다.

  • 데이터가 오픈데이터인 경우

    오픈데이터는 공개된 곳의 링크를 걸어주면 됩니다. 보통 코드내에서 자동으로 오픈데이터를 긁어오게 만들어 코드를 작성합니다.

  • 데이터가 매우 크고 오픈데이터가 아닌 경우

    웹사이트에 올리거나 Dropbox같은 클라우드 스토리지로 공유합니다. Dropbox외에도 Google Drive라든가 One Drive라든가 여러가지가 많습니다. 대부분 기본 용량은 공짜이고 용량 추가는 비용 지불입니다.

Reproducible Research 작성도구

분석 도구라면 뭐든지 가능하지만 우선 특화된 UI가 있는 분석툴들은 어렵습니다. R, Python, SAS, Matlab은 가능할 것입니다.

Excel로도 하긴합니다만 불편하더군요. 나 퀀트여서 C++, Excel만 하는데? 네.. 알아서 잘!

보통 R을 많이 사용하는 것을 볼 수 있는데요.
이유는 보통 이렇습니다.

  • 공짜입니다.

    받아보는 사람이 결과물을 보기 위해서 소프트웨어를 구매해야 한다면 힘드니까요. 나 오라클에 SQL로 코드짜고 연구했어. 그래서 내가 너에게 오라클 라이센스를 주마! 네! 님짱!

  • 코드가 간결하고 분석이나 리서치하기에 편합니다.

    원래 그런 용도로에 많이 특화되어 있습니다. 나 perl로 무지 간결하게 짤 수 있는데 대신 난독화가 심해져서 읽는 것은 너의 능력문제야! 네! 님짱!

  • 코드와 설명을 함께 넣어 리포트를 쉽게 만들 수 있습니다.

    Sweave나 Knitr같은 패키지로 쉽게 가능합니다. 코드에 주석으로 설명을 적기에는 너무 부담도 크고 할일도 많지요. 보고서나 논문 형태로 포맷팅을 쉽게 할 수 있습니다.

분석결과물이 코드와 데이터만 있는 것이 아니라 설명이 들어 있어야 하는데요. 보통 논문같은 형식이나 보고서 형식을 생각하시면 됩니다. 코드와 데이터만 덜렁 주지는 않습니다.

이정도 코드는 알아보겠지? 하실 수도 있겠지만 간단한 것을 제외하고 내가 만든 알고리즘이나 데이터 분석 절차와 대응 방법을 받는 사람이 쉽게 이해하기 어려우니까요.

참고로 위의 요소를 만족하는 도구로 대안은 Python, Ruby가 있습니다. 그 이유가 전부인 것은 아니지만 저런 이유도 있어서 데이터 사이언티스트가 많이 쓰는 도구로 Python, R이 상위권이기도 합니다.

Reproducible Research 배포처

준비를 다 했다면 배포할 곳이 필요합니다.

헐 @.@ 나는 누군가? 지금까지 뭘 했는가?

학회에 논문 제출?도 하겠지만 그 외는 온라인 커뮤니티에 배포를 많이 하게 되는데요. 커뮤니티에 배포를 하더라도 링크를 주고 링크를 누르면 어떤 사이트로 이동해서 결과물을 보게 하는데요. 그래서 결국 웹사이트가 필요합니다.

네. 도메인따고. 호스팅받고. 설치하고. 세팅하고. 하고. 하고. 하고…

웹블로그는 공짜가 많습니다. 괜찮은 것 하나를 선택해서 쓰면 됩니다. 도메인을 구매해서 연결하는 것도 좋습니다.
많이 쓰는 것으로는 다음과 같은 것들이 있습니다.

  • WordPress 또는 다른 블로그

    Tumblr나 Scriptogr.am 등 많습니다만 WordPress가 가장 만만해요. 공짜로 도메인 연결도 해주는 곳이 많습니다.

  • Github

    웹페이지를 볼 수 있게 지원합니다. 공짜로 도메인 연결도 가능해요. 다른 것들도 있습니다만 Github이 가장 만만해요.

  • 개인 웹사이트

    생각보다 많습니다. 클라우드를 이용해서 쉽게 구축하는 서비스를 제공하는 곳도 많습니다.

이런 추세는 R로 Reproducible Research를 하는 사람들의 트렌드때문인데요. R의 Knitr가 WordPress로 리포트를 배포하는 기능을 지원하기 때문입니다. Rmarkdown을 작성해서 배포하면 WordPress로 플롯과 코드와 설명이 모두 배포됩니다.

Github을 이용하려면 HTML 코드를 작성해서 업로드 해야 하는데 Knitr, Jekyll 조합으로 가능합니다. 요건 설정하기가 조금 까다롭습니다.

많이 알려진 플로우

Reproducible Research는 R 사용자들이 많이 주도하고 있는 상황이라서 R과 관련된 것이 아직까지는 대부분입니다.

많이 쓰는 플로우입니다.

  1. R과 Rstudio를 설치합니다.
  2. Rmarkdown이나 Sweave 형식으로 작성합니다.
  3. 작업하면서 소스코드를 계속 형상관리에 저장합니다.
    1. Github, Bitbucket, …
  4. 사용한 데이터는 오픈 스토리지에 올려 놓습니다.
    1. Dropbox, One Drive, Google Drive, Drive.., Drive.., …
  5. 리포트를 빌드합니다.
    1. 잘되는지 확인해야 합니다.
  6. 배포합니다.
    • WordPress로 배포
    • 또는 Jekyll로 빌드해서 Github에 Push

Reproducible Research 준비가 사실 번거롭고 할 일이 많습니다. 그런데도 하는 사람이 많은 것을 보면 신기하기도 합니다. 이 유행이 언제까지 일지는 모르겠지만 제 생각에는 그래도 앞으로도 당분간은 계속 될 것 같습니다.

세상이 너무 빨리 바뀌고 있네요.

빅데이터와 텍스트마이닝

빅데이터와 테스트 마이닝에 대해서 조금 적으려고 합니다.

빅데이터(Big data)

빅데이터(Big data)는 이제는 설명을 안해도 될 만큼 자료가 많습니다.
구글링을 해서 찾아보시면 되겠지만 너무 많아서 오히려 정리가 안되서 맥락을 이해하기가 어려울 수도 있습니다.

빅데이터는 간단하게 말하면 많은 데이터, 다양한 데이터를 저장, 가공, 처리, 분석하는 것을 통칭해서 말하는 것입니다. 어차피 명확하게 정의하기 어렵고 원래 정의를 만들고 시작한 것도 아닙니다.

사실 이미 빅데이터 리딩그룹쪽에서는 데이터와 관련된 IT기술이나 분석기법은 그 경계나 정의를 명확하게 정하지 않은지가 오래 되었습니다.

텍스트 마이닝 (Text Mining)

텍스트 마이닝은 사람이 써놓은 글을 분석해서 뭔가 쓸만한 것을 뽑는 것입니다.

텍스트 데이터는 특성상 많이 모아야 뭔가 쓸만한 것이 나옵니다. 텍스트 마이닝이 빅데이터에서 언급되고 마치 전부인것 처럼 얘기되기도 하는 이유는 원래 빅데이터의 출발이 IR(Information Retrieval)이 전문인 구글, 야후, 페이스북, 아마존, 넷플릭스등의 온라인 회사에서 시작되었기 때문입니다.  즉 빅데이터 관련 기술을 텍스트 처리에 많이 사용했기 때문입니다.

검색 포털이나 온라인 리테일 회사를 상상하시면 됩니다. 구글, 아마존이 대표적입니다.

이미 아시겠지만 현존하는 텍스트 마이닝의 최강자는 구글입니다. 그리고 그 외의 여러 회사들이 있습니다.

이 회사들의 공통점은 다음과 같습니다.

  1. 온라인 회사이고 많은 접속자가 만들어 낸 로그를 쌓아서 보유하고 있는 데이터가 매우 많다
  2. 대용량 정보처리기술이 회사의 핵심기술이다
  3. 사용자들이 웹사이트에서 행동하는 것을 로그에 쌓아놓고 그것을 다시 가공해서 회사의 서비스를 개선하거나 다른 부가가치를 만들어 낸다

빅데이터와 텍스트마이닝이 혼동되는 이유 중 또 하나는 텍스트데이터는 처리하는데 컴퓨팅 자원이 많이 소모된다는 점도 있습니다.

어찌되었든 텍스트 마이닝을 잘 하려면 필수는 아니지만 빅데이터 기반 기술이 있는 것이 매우 유리하며 그런 경험이 있다면 그렇게 될 수 밖에 없다고 보는 것이 업계 기술자들의 정론입니다.

그렇다고해서 빅데이터를 텍스트 마이닝에만 쓴다는 얘기는 아닙니다. 다시 텍스트 마이닝으로 돌아오면 텍스트 마이닝은 텍스트 데이터를 분석해서 의미, 의도, 경향등을 보는 것을 기본으로 하고 그런 결과물을 다른 데이터와 연동해서 분석하거나 결합해서 부가정보로 쓰게 됩니다. 그 이상을 하려면 텍스트 마이닝 결과물 자체가 비즈니스 모델이 되거나 회사의 이윤을 창출하는 뭔가를 만들어 주어야 하는데 그런것이 많지 않습니다.

텍스트 마이닝이 그 자체로 비즈니스 모델이 되는 것은 기계 번역이나 문서 자동 요약 등과 같은 것이 있습니다.

텍스트 마이닝의 문제점

텍스트 마이닝의 문제점은 상당히 자연어(사람이 쓰는 말, 한국어, 일본어, 독일어, 영어, …)에 영향을 많이 받으며 분석결과물 자체를 그대로 비즈니스 모델에 적용해서 뭔가를 만들어내서 성과를 보기 어렵다는데 있습니다. 자연어처리쪽 분야에 있어서 문제가 있는 분야가 한글 및 한국어의 경우 광학문자판독(OCR, Optical Character Recognition), 음성인식(Speech Recognition), 그리고 감성분석 (Sentimental Analysis)등이 있습니다. 기술적으로 문제라기 보다는 언어를 다루는 문제가 결과물을 보고 품질을 사람들이 쉽게 판단하기 때문입니다.

텍스트 마이닝이 어려운 이유

텍스트 마이닝의 전부가 워크 클라우드가 아니며 데이터를 수집해서 텍스트 마이닝 툴을 사용해서 마우스 클릭을 하면 분석결과가 나오는 것이 아닙니다. 영어권 경우에는 기술적인 진척이 많고 영어의 특성이 분석이 더 쉽다는 것이 없지 않아 잘 되는 것도 있지만 한글 및 한국어에서는 아직은 어렵습니다. 특히 텍스트 마이닝은 자연어처리 도구에 의존성을 매우 큰데, 자연어처리 도구가 그냥 사서 쓰는 소프트웨어가 아니라 사람의 정성스런 손길이 지속적으로 필요한 애물단지입니다. 자체로도 관리가 필요하며 관리가 안되면 쓸모가 없어지는 경우가 많으데다가 관리가 안된 자연어처리 도구를 이용해서 만든 2차 파생물도 함께 엉망이 됩니다.

때문에 사내(in-house)에서 지속적으로 투자하거나 하지 않으면 결과를 보기 어렵고, 당연히 단기 프로젝트에 의한 좋은 결과물은 나오기 어렵습니다. 참고로 자연어 처리 도구는 형태소 분석기, 구문 분석기등과 같은 자연어를 처리하는데 필요한 소프트웨어 라이브러리들입니다. 이것들도 자연어의 특성을 많이 타는 것으로 각 언어별로 다 품질이 다르고 기분석 사전이나 후처리 사전등을 따로 관리해야하는 복잡한 문제가 있습니다.

텍스트 마이닝과 워드 클라우드(Word Cloud)

TV에서 자주 볼 수 있는 화면이 단어들이 둥둥 떠 있고 단어끼리 선을 연결한 시각화 화면이 많은 것입니다. 워드 클라우드라는 시각화 방법입니다.

사실상 텍스트 마이닝의 결과물의 시각화는 워드 클라우드나 워드 클라우드를 변형한 시각화 기법외에는 아직 없습니다

경험이 없는 분들은 어렵게 생각하실지도 모르겠지만 사실 워드 클라우드는 구현하기가 매우 쉽흡니다. 심지어 그냥 오픈 소스 몇개를 붙여서 돌리면 그럴 듯한 것을 만들어서 보여줄 수 있습니다.
문제는 이런것들 돌려서 흥미 위주의 어필 포인트는 되겠지만 결과물이 실제로 도움이 되는 것이 많지 않다는 것이고 그것 때문에 대부분의 일반 기업에서는 빅데이터를 텍스트 마이닝이라고 생각하고 프로젝트를 진행한 뒤에 결과물이 도움이 안되니 빅데이터가 별거 아니고 해봤는데 아니더라고 말하게 된다는 것입니다.

가장 흔히 볼 수 있는 반응입니다

이것은 잘못 접한 정보와 유도된 상황 때문에 발생하는 착각입니다. 빅데이터와 텍스트 마이닝을 구분하지 못하며 제대로 이해하지 못하기 때문입니다.  경험을 해보지 않으면 제대로 구분하기 어려운 것도 사실입니다만 공부가 부족하기 그것을 모른다고 해서 틀린 것을 말하고 그것이 마치 정설인듯 말하는 것은 정당하지 않습니다. 텍스트 마이닝은 쉽지 않습니다. 그리고 텍스트마이닝이 빅데이터와 동치관계는 아닙니다.

데이터 사이언티스트가 사용하는 도구

저는 기업체를 상대로 솔루션 사업을 하고 있는 회사에서 데이터 사이언티스트로 일하고 있습니다. 대외 미팅 중에 아이스브레이킹(ice breaking)을 하면서 가장 많이 받는 질문이 아래 두가지입니다.

  • 데이터 사이언티스(Data Scientist)가 뭐하는 사람인가요?
  • 데이터 사이언티스(Data Scientist)는 무슨 툴(Tool)을 사용하나요?

첫번째에 대답은 검색을 해보면 여기저기 다 있습니다.

대부분 명확하게 정의는 하지만 그 정보들을 취합해 보시면 서로 다르게 정의하고 있는 영역이 보일 것입니다. 그 정의로는 혼동스럽죠. 쉽게 정의하면

  • 광의적으로 보면 데이터 관련된 일은 뭐든 다 해주는 사람. 비즈니스에서 부터 구현 및 서비스까지

    이쯤되면 수퍼맨입니다

  • 협의적으로 보면 공학기술을 이용해서 데이터 분석을 하고 구현체까지 만들어 주는 사람

    데이터마이닝과 프로그래밍을 같이 하는 사람입니다. 좀더 구체적으로는 개발자와 데이터 분석가의 중간쯤 어디입니다. 예전에는 데이터 엔지니어(Data Engineer) 또는 그냥 엔지니어(Engineer)라고 불렀습니다.

두번째 대답의 답은 뭘까요?

데이터 사이언티스트가 빅데이터를 하는 사람으로 가장 잘 알려져 있어서 보통은 빅데이터와 관련된 것을 뭉뚱그려서 같이 물어봅니다.
엔터프라이즈를 대상으로 제품이든 용역이든 팔아먹는 기업에서 몸담고 있는 사람이라면 이쪽의 대답은 당연히 자신의 소속한 회사의 솔루션과 관련된 답을 하기 마련입니다.

영업하는 사람이 아닐지라도 그럴 수 밖에 없습니다.

여러가지 솔루션을 많이 보유하고 있는 회사라면 이것저것 적절한 조합을 합쳐서 말하게 되고 솔루션이 적은 회사라면 특정 솔루션에 대해 말하고 응용할 수 있는 가능성을 얘기하게 됩니다. 제 경우에도 여기에서 자유롭지 않으며 회사의 솔루션이 R인 까닭으로 R이라고 말합니다. 하지만 제가 근무하는 회사와 상관없이 제 경우를 떠나서 언급되었거나 경쟁하면서 다른 사람들이 말하는 것들을 닥치는 대로 나열해 보겠습니다.

플랫폼으로 가장 많이 언급되는 것이 Hadoop ecosystem쪽 입니다.

  • 배치 프로세싱: Hadoop, Hive, Pig, Impala, …
  • 리얼타임: Storm, Spark, …

더 있는데 생각이 안나네요.

시각화쪽으로는 Spotfire, Tableau, CliqView 등이 있습니다.

구현을 해서 웹기반 툴을 만들어 주기도 합니다.

BI 쪽

  • Micro-strategy, Business Object(SAP 솔루션)같은 BI툴
  • Birt나 Jasper같은 리포팅툴

DW 쪽

  • Teradata, Oracle 솔루션들, SAP 솔루션들, EMC 솔루션을

이제 마지막으로 분석툴인데 질문자들이 데이터 사이언티스트는 뭘 쓰나요 할 때 예상대답으로 원하는 것이 주로 이쪽입니다.

R, SAS, SPSS 등이 있습니다.

SAS직원이거나 파트너사소속이면 아마 SAS 솔루션들을 말할 것이고 IBM쪽이라면 SPSS와 기타 IBM솔루션을 말할 것이고, 그것도 아니라면 R을 얘기합니다.

이것들의 범주는 사실 데이터마이닝 툴이라고 볼 수 있습니다.

이쯤되면 그냥 통합 ISP 인프라 솔루션들을 다 나온다고 보면됩니다. 이 상황은 빅데이터와 데이터 사이언티스와 데이터분석과 기존 데이터관련 솔루션들이 빅데이터 트렌드에 합류하면서 잡탕찌게가 되었기 때문입니다.

데이터 사이언티스트는 사용하는 툴이 정해져 있지 않습니다. 자세히 생각해 보면 아시겠지만 그럴것이면 데이터 사이언티스트가 별로 필요 없습니다. 데이터 사이언티스트가 닥치는대로 다 사용한다고는 하지만 사실 각자 주력으로 사용하는 것은 있습니다. 경향을 볼 때 주로 선정대상은 일반적이며 가격이 높지 않은 것을 선택합니다.

오픈 되어 있는 것이 필요하니 오픈 소스를 쓰고 오픈 소스는 자체로는 가격이 없으니 결국 오픈 소스를 선호하게 됩니다.

특정 회사에서 내근만 한다면 특정 툴로만 하는 것도 무리는 없습니다

물론 가격이 비싸고 훈련이 되어 있거나 훈련을 받아야 합니다.

국외의 상황이구요. 국내는 아직 혼란 상태입니다.

외국의 상황을 보죠.
검색을 해서 외국 사이트의 게재물을 읽어보시면 주로 언급되는 데이터 사이언티스트가 가장 많이 쓰는 도구는
R, Python, Java가 나옵니다.

SQL은 거의 기본입니다. 무조건 합니다. 제 경험으로는 실제로도 그렇습니다.

주로 현재는 Python이 가장 많고 그 다음이 R 그리고 Java입니다.

Python과 Java가 많은 이유는 데이터사이언티스트 중에서 공학에서 시작해서 커리어를 확장했기 때문입니다.  공학에서 넘어온 사람은 Python, Java가 많고
통계에서 넘어온 사람은 R이 많습니다.
비즈니스나 경제학에서 넘어온 사람은 여전히 SAS와 Excel을 씁니다.

SAS, Excel빼고 이것들의 공통점은 컴퓨터 랭귀지라는 것입니다.

SAS도 자체 랭귀지가 있습니다만 그냥 분류상으로 빼겠습니다. 많이 애매해졌습니다.

해석해 보면

  1. 첫번째 항상 구현만 하는 것은 아니겠지만 뭔가 구현을 하는 경우가 빈번하기 때문이라는 것을 알 수 있습니다. (주력으로 사용하는 도구이므로…)
  2. 두번째 가능한 특정 솔루션에 의존성을 가지지 않아야 하며 솔루션이나 툴이 중요한 것이 아니다라는 것을 알 수 있습니다. 현재는 가장 각광받는 것이 R과 Python 그리고 빅데이터 솔루션입니다.

하지만 데이터 사이언티스트가 사용하는 도구가 뭐냐를 보기 보다는
데이터 사이언티스트라는 사람 그 자체가 도구라는 사실이 숨겨져 있는 것이 함정입니다.

[컨퍼런스] 데이터사이언티스트가 말하는 빅데이터 분석 사례

(데이터솔루션)[http://www.spss.co.kr/main/main.asp]이 주최하는 빅데이터 세미나입니다.

  • 사이트 주소: http://www.datasolution.kr/imgs_job/marketing/2014/bigdata_01.html
  • 장소: 엘타워 그레이스 1홀
  • 날짜: 2014년 3월 25일 화요일
  • 시간: 13:30 – 17:30

0.5일 오후만 진행하네요.
주로 SPSS를 이용한 사례 중심 발표로 보여집니다.

관심있는 분들은 참여해 보세요.

R – 콜택시/대리운전 데이터 분석 예제 #1

콜택시/대리운전 데이터 분석 예제 #1

SKT의 빅데이터허브에서 받은 콜택시/대리운전 데이터를 이용한 간단한 Data Munging과 EDA를 위한 전처리의 예제입니다.

들어가기 앞서서…

Data Munging(데이터 먼징)은 데이터를 분석하기 위해 데이터를 여러 형태로 변환하는 것을 말합니다. (Data Wrangling 이라고도 합니다) ETL이 뭔지 아신다면 간단한 형태의 on-demand ETL이라고 생각하면 됩니다. Data Munging을 시스템을 이용해서 자동화하면 ETL이 됩니다.

EDA는 다들 알다시피 탐색적데이터분석(Exploratory Data Analysis)입니다. 최근의 추세는 EDA를 위해서 전처리와 Data Munging에서 EDA까지 한꺼번에 수행하는 것이 많습니다. (유행…)

해보기…

우선 bigdatahub.co.kr에서 콜택시/대리운전 데이터를 다운로드 모두 받습니다. 취향이겠지만 TSV 형식으로 받으면 좋습니다. 탭으로 구분된 것이 콤머로 구분된 것보다 다루기 편합니다.

CSV형식은 따옴표의 escaping등의 문제가 늘 있으므로 가끔 이런것이 문제를 일으킵니다. 이런 문제를 미연에 방지하기 위해 TSV형식을 사용하는 것이 좋습니다.
단, 당연한 것이지만 데이터 내부에는 Tab이 들어 있지 않다는 전제가 필요합니다.

TSV형식은 Tab Seprated View의 약어로 구분자(delimiter)가 tab 문자로 구분된 형식입니다. 이 예제에서 파일들이 저장된 경로는 다음과 같습니다. (제 PC는 Mac입니다)

각자의 경로에 맞게 잘 수정하시기 바랍니다.

저장된 파일 목록을 살펴봅니다.

이제 파일이름들로 된 character 타입 벡터를 하나 만들어 줍니다. copy & paste를 하시던가 타이핑을 열심히 하던가 해야 합니다.

다른 tsv파일들이 들어있지 않다면 타이핑하지 않고 그냥 불러올 수 있습니다.

오타방지와 노동력 낭비 방지를 위해서도 이 방법이 더 낫습니다. system 펑션에 intern 옵션을 True로 해주면 됩니다.

위의 내용을 보실 때 한글 자모가 분리된 형태로 보일 수 있는데 제 작업PC가 Mac OS X라서 그렇습니다. 실제로는 문제는 없습니다.

이제 읽어들일 파일이 헤더가 포함되었는지와 모든 헤더들이 동일한지 간단히 확인합니다. 만약 헤더가 일치하지 않으면 data.frame을 머지(merge)할 때 곤란해집니다. 편의를 위해서 unix 명령을 사용할 것이고 Mac OS X나 Linux를 사용하고 있다면 바로 쓸 수 있습니다.

R을 windows를 사용하고 있다면 msys나 cygwin등을 설치하거나 수작업으로 하는 방법이 있습니다.

결과를 보면 한 개의 파일이 다른 헤더를 가지고 있음을 알 수 있습니다.

아마도 “서울지역+콜택시+대리운전+이용분석_2013년+8월.tsv”라는 파일이름을 가진 파일이 원흉일 것입니다. 여튼 header들이 일치하지 않는데 결국 header를 고쳐주거나 header를 무시하고 읽어온 뒤에 header를 다시 붙여주는 방법을 사용해야 합니다. 그리고 어차피 컬럼명이 한글이므로 header는포기하는 것이 유리합니다.

우리는 header를 포기하고 column name들은 임의로 붙일 것입니다. 자 이제 여러 tsv 파일을 모두 읽어서 하나의 data.frame으로 만들어야 합니다.

그래야 다루기 쉽습니다.

파일들을 일곱번 읽어서 rbind하는 방법등 여러가지 방법이 있습니다. 그리고 그 외에도 방법은 여러가지가 있습니다만 여기서는 작업의 편의를 위해서 plyr를 이용해서 한 번에 읽어 버리도록 하겠습니다. plyr 패키지를 불러옵니다. 설치가 되어 있지 않다면 당연히 설치를 해 주어야 합니다.

plyr 설치하기

이제 paste0를 이용해 파일 이름들의 fullpath 벡터를 만들어줍니다.

아래는 결과입니다.

파일 이름이 절대경로로 잘 붙어 있는 것을 확인할 수 있습니다. 자 이제 ldply를 이용해서 몽땅 불러옵니다. header를 읽지 않기 위해서 skip=1 옵션을 준 것을 주의하세요.

자 파일을 읽어 왔습니다. 내용을 확인해 봅니다.

확인해보니 ldply를 사용하면서column이 하나 더 붙었습니다만 그것은 나중에 확인하기로 하고 우선 레코드를 빼먹지 않고 모두 data.frame으로 읽어 왔는지 확인해 봅니다.

총 3115 개의 레코드가 읽혔는데 맞는지 확인해 봅니다. unix명령어의 wc를 이용해서 확인합니다.

3122개가 나왔는데 header의 개수 7을 빼면 3115가 맞습니다. (산수! 산수!)

자 이제 컬럼명을 바꿔줍니다. 원래 컬럼명은 아래와 같습니다.

아래는 결과입니다.

컬럼명을 안 바꾸고 그냥 써도 되겠지만 컬럼의 의미를 인식하기 어려우므로 바꿔줍니다. (깔맞춤의 미학)

그전에 보면 맨 앞의 컬럼명이 filename인데 이것은 하등 쓸모가 없으므로 먼저 제거합니다.

#!!{"brush":"r"}
df <- df[,2:6]

컬럼이름을 바꿔줍니다.

컬럼이름이 로마자 병음 방식으로 상당히 무식해 보이지만 체신청(우체국)과 안행부에서도 채택(?)하고 있는 전통적으로 많이 쓰는 예술적인 네이밍룰입니다.

컬럼이 잘 바뀌었는지 확인해 봅니다.

아래는 결과입니다.

다 되었습니다. 여기까지 데이터를 읽어오는 과정이었습니다. 기회가 되면 이 데이터를 가지고 EDA인 Descriptive Statistics를 해보겠습니다.

빅데이터와 샘플링

한 번쯤 생각을 정리할 필요가 있다고 생각해서 포스팅하는 중이다.(이하 편의상 계속 존칭 생략)
이런 내용을 다루기에는 조심스럽고 복잡한 것이지만…

빅데이터 문제를 들면서 흔히 하는 말들이 기존에 알 수 없었던 것들을 많은 데이터 또는 많은 데이터에 어떤 방법론을 적용 또는 어떤 방법을 많은 데이터에 활용해 봄으로써 알아 낼 수 있다는 말들이다.
굉장히 그럴듯한 말인데 받아들이기에 따라 조금 위험하긴 하지만 사실 틀린 말은 아니다.
실제로 그런것과 샘플링을 통해서 그럴 것이라고 추정한 것에는 다를 수 있는 점이 있기 때문이다.
여기서 약간의 함정은 “다를 수도 있다”이다. (또는 조심스럽게는 다른 것이 많다라고 표현하기로 한다)
그리고 그 말을 반박하는 사람은 샘플링을 통한 전통적인 통계분석과 빅데이터를 통한 분석은 “별반 다르지 않다”라고 말한다.
이것이 논쟁의 포인트이다. 아직도 애매하고 논란의 대상이 된는 부분이다.
빅데이터를 통한 데이터분석이 전통적인 샘플링기반의 통계적 분석보다 더 나은 점이 어떤 것인지, 즉 이론적으로 어떻게 해서 그렇게 되는지 증명해봐라고 말한다면..

나는 못하겠다. 그냥 경험에 비추어 말하는 것이다. (아! 무책임한 나)

잠깐 옆으로 살짝 새서 통계쪽과 빅데이터, 샘플링에 대한 논점에 대해서 내 어프로치(approach)나 스탠스(stance)를 생각해 보면 “거의 모든 경우에 샘플링을 해서 거의 모든 문제를 해결 할 수 있다. 그렇지 않다”를 말하기는 조금 조심스럽다. 아니 상당히 조심스럽다. 이와 관련되어서 여러 관점을 가진 사람들이 달라붙어 말을 꺼내한 사람을 무지몽매한 사람처럼 취급하며 상대를 공격하기 시작하기 때문이다. 학문적 깊이와 고민이 없어서 이론적으로 논리적으로 경험적으로 응대할 수 있다면 이런 민감한 문제에 대해서는 입을 닫는 것이 처세에 유리할 수 있다.

최근의 나는 입을 닫는 쪽이다. 나는 시류에 편승하게 보이려고 노력하는 쪽이다.

통계적 방법론에서는 샘플링을 통한 방법과 샘플링을 통한 모델의 최적화 방법이나 추정방법이 잘 되어 있어서 꼭 전수검사를 하지 않아도 대략의 것은 맞아 떨어지거나 전수검사(또는 전수검사에 필적할 만큼 많은 검사)를 한 것과 샘플링을 한 것의 차이는 거의 없다.

위에서 말하는 것이 빅데이터의 “빈곤한 필요의 이유성”을 반박하는 쪽의 얘기다. 문제는 이것을 반박할 만한 뚜렷한 이론이나 논리나 경험을 내가 가지고 있지 않다는 것이다. 솔직히 잘 모르겠다. 나는 여기에 대한 깨달음이나 확고한 주관이 없다. 앞서에서 말한 내가 입을 닫는 이유이다. 아주 깊이 고민해 본적이 없고 나는 그 통계학을 조금이라도 기웃거리며 공부했다는 사람들은 다 안다는 중심극한원리도 끝까지 잘 이해를 하지 못하고 있다. – 노파심에 말하지만 아예 정의상 무엇이고 어떻게 돌아가는지를 모르는 것은 아니지만 기저의 원리를 완전히 이해 못했다는 말이다. 결국은… 그러니까 모른다는 말이다. –

그런것도 다 모른다는 사람이 이런 포스트를 건방지게 올리느냐라고 말한다면 조용히 다른 사이트로 이동해 주기를 정중히 부탁드린다.

그런데 생각해보면 말장난같긴 하지만 위에서 말한 샘플링 논쟁이 문제는 무엇을 하는데 샘플링을 한다. 안한다라는 말이 나오냐는 것이다.
데이터의 분포를 확인하기 위해서는 샘플링을 해도 충분하다는 것인지 예측모델을 만들기 위해서도 샘플링으로 충분하다는 것인지 살펴봐야 하는 대상이 롱테일에서의 테일 부분인데도 샘플링으로 충분한 것인지…
인터넷상에 떠도는 말이나 블로그등을 봐도 그런말에 대해서 잘 언급하지 않고 포괄적으로만 말한다. 물론 지면관계로 인해 그랬을 수 있다. 그런데 설명하지 않는 것도 문제가 있다. 그런 것쯤은 공부를 했다는 사람이면 충분히 기본으로 알고 논점에 들어가야 하는 것이 아닌가? 라고 되물을 수도 있을 텐데. 이것은 정말 말장난이라고 생각한다. 무엇에 대해서든지 정확히 뭘 하려고 하는지 말해야 한다. “상대가 무지해서 대화가 안돼!”라는 식의 태도는 교만함으로 인한 자신의 무지함을 감추기 위한 것이라고 생각한다. – 아닐 수도 있겠지만 대부분은 그렇다고 생각한다. –

통계적인 분야에 대해서는 깊이가 부족하지만 샘플링도 충분히 가능하지만 샘플링을 하지 않고 전수를 해 보려고 하는 이유는 노말(Normal)한 것들을 보지 않고 노말하지 않은 데이터들을 살펴보거나 혹시 나올 지도 모를 것들을 찾아 보겠다는 것이다. 전반적인 분포나 어떤 특성만 파악하려고 한다면 이런 자원소모가 큰 일은 잘 하지 않을 것이다.
노말한 것들, 직관적으로 쉽게 알 수 있는 것들은 이미 오래 연구가 되어 있거나 잘 알고 있는 것들이다.
더 해도 뚜렷한 성과를 보기 힘들다. 쉽게 성과를 보려면 (이런 생각 자체가 조금 무리이지만) 결국 남들이 보지 못한 것을 봐야 한다. 그것들은 정규분포의 가운데에 근처에 있는 것들이 아닐 가능성이 크다. 그리고 그런것들은 희소성을 가지고 있기 때문에 데이터가 많으면 많을 수록 더 잘 드러나고 제법 많은 양이 늘어나면 그것들 자체로도 어떤 규칙이나 특성들을 가지게 된다는 것을 발견할 수도 있다. (반대로 말하면 없을 수도 있다)
이 가능성 때문에 그 부분에 투자를 하는 것이다.
그런것이 없다고 확신할 수 있고 필요 없다고 생각하면 안하면 되는 것이다.

내가 지금까지 많이 봐왔는데 그건 안봐도 뻔해

라고 확신이 서면 안해도 될 것이다. 대신 일말의 아닐 가능성이나 다른 것이 발견될 가능성은 포기하는 것이다.

해 봤는데도 역시 잘 안나왔어

라는 말과는 다른 말이다. 이 경우에는 할 말이 별로 없다. 뭔가 잘 못한 것이 있을 것이다라는 말로 공격하기 전에. 가능성에 대한 도전을 해 본것과 아닌것의 차이는 크다고 생각한다. 그로 인해 생긴 시야가 당연히 달라져 있을 것이므로 결과가 같던 다르던 상관없이 의미가 있다. 물론 ROI나 output 측면에서 보면 후자쪽이 더 미련한 짓인 것처럼 보일 수 있다. 시간낭비만 한 것으로 보일 수도 있으므로. 하지만 내 경험상 그렇게 해서 괜찮은 것을 찾았다고 말하는 사람들이 꽤 있다. 사실 찾았어도 뭘 찾았는지는 잘 말해주지 않지만. – 이 경우는 아무런 득도 없었는데 무의미해 보이지 않으려고 한 거짓말 일 수도 있다 –

이 포스트에서는 통계적 관점보다는 우선 데이터마이닝관점에서 샘플링 논쟁이 어떤 부분에 해당이 될지에 대해 생각을 정리해 본 것이다. 어쨌든 나는 통계쪽에는 깊이가 별로 없는데다가 추정이니 다변량이니 분포니 이런 것은 머리아프다.

연관규칙탐사

연관규칙탐사는 보통 데이터마이닝 관련 서적의 초반부에 나온다. 쉽고 흥미 있는 주제라서 그런 것 같다.
데이터마이닝에서 샘플링을 안하고 하는 것이 기본적으로 유리한 것으로 우선 생각하는 것은 이 연관규칙탐사(Association Rule Mining)이다. 흔히 말하는 “장바구니탐색”이다. 이것은 논란의 여지가 별로 없을 것 같다. 컴퓨팅파워만 충분하다면 많은 양을 해보는 것이 여러모로 괜찮은 것을 발굴하기 좋은 방법이다.
이것은 빈발도(Frequency)기반이라 샘플링과 샘플링이 아닌 것의 결과의 차이가 굉장히 다르게 나타난다. 지지수(Support number)의 조절로도 많은 차이가 나는 것을 볼 수 있다. – 빈발도는 카운트이고, 지지도는 Threshold이다 – 작은 양의 데이터에서는 볼 수 없었던 특이한 그룹들의 데이터가 눈에 분명 보이는 때가 있다.

관점에 따라서 혹자는 이것을 노이즈라고 하고 혹자는 이것은 새로운 것을 발굴(Discovery)이라고 말한다.

어떤 사람들은

연관규칙탐사는 너무 단순하고 숫자세기 아닌가? 이 논점의 일부로 넣기에는 너무 조잡하고 수준 낮은 대상이다.

라고 말할 수도 있겠다. 샘플링이고 뭐고 이런 간단하고 무식한 것에 무슨 의미를 두드냐는 의미로 받아들인다. – 수준이 낮은 것이라는 말은 개인적으로 조금 거부감이 든다 – 실제로 해보지도 않고 “조잡하고 그런 쉬운것쯤이야”라고 말해 버리는데, 여기서는 의외성을 찾는데 샘플링이 그 의외성을 가리고 있을 가능성이 크다는 말이 하고 싶다. 어쨌든 이렇게 단순하고 조잡해 보이는 알고리즘도 실제로 극단적인 대상에 대해서 해 본 것과 그렇지 않은 것은 차이가 크다. 연관규칙에서 support number를 왜 조절하는지 곰곰히 생각해 보자.

“원래 outlier가 의외성 아닌가? 샘플링을 해도 outlier 영역은 있어서 확인이 가능하다. 앞뒤가 안 맞다” 라고 물으면 답변이 또 길어질 것 같다. 짧게 말하면 내 경험으로는 아닌 경우가 더 많았다. 혹자가 나는 별반 차이가 없는 경우가 더 많았다고 말한다면 나와는 다른 도메인 다른 상황에서 다른 뭔가를 봤을 것이고 그 경험도 당연히 맞을 것이다.

또 다른 질문으로

연관규칙탐사는 원래 샘플링 안하는 것이 아닌가? 샘플링하고 별반 상관 없는 것이 아닌가?

라고 지나가다가 묻는 사람도 있을 것이다. 교과서를 잘 읽어 보면 알겠지만 옜날 교과서는 샘플링을 하는 것을 기본으로 하고 있다. 최근 교과서는 그런 말을 아예 언급하지 않는다. 설명하려고 하는 것이 그런 것은 아니고 최근에는 그렇게까지 깊이 연구되는 쪽이 아니라서 그런 것 같기도 하다.

여하튼 보편적으로 샘플링을 하는 이유가 기본적으로

일일히 숫자세기가 어렵고 모든 모집단의 데이터를 다 얻기 어렵기 때문이다.

라는 데서 우선은 벗어나지 않았으면 좋겠다. 그리고 무엇을 보고 싶은지에 따라 샘플링하는 것과 아닌것도 달라져야 한다고 생각한다.
연관규칙탐사는 샘플링을 하지 않았을 때 유용한 것을 알아 낼 수 있는 대표적인 방법이고 특별히 유용하지 않는 그러니까 샘플링을 해도 충분히 알 수 있는 일반적인 사실을 알고 싶어했다면 샘플링을 하던 하지 않던간에 이것도 별 차이는 없다.

결론적으로 샘플링이고 뭐고 간에 연관규칙탐사에 있어서는 가능한 많은 데이터를 돌려 보면 볼만한 것이 많이 나온다.

지도학습 (Supervised Learning)

지도학습에서는 샘플링이 문제가 된다.
데이터마이닝에서 지도학습, 교사학습, Supervised Learning, 분류(Classification)는 같은 말이다. 용어 선택의 차이일 뿐이다.
이것은 학습데이터와 학습데이터로 만든 모델을 평가할 때 생기는 전반의 문제 때문인데, 샘플링 때문에 미지(Unseen)데이터에 대해 판별을 잘 하지 못하는 것에 대한 우려 때문이다. 샘플링의 문제에서 벗어날 수가 없다.
실제로도 샘플링을 어떻게 하느냐에 따라 결과의 차이가 심하게 난다.

지도학습에서 첫번째 샘플링을 하는 것은 EDA이다. 대충 데이터를 살펴보겠다는 것인데 이것은 다른 것에서도 다 하는 것이므로 넘어가자. – 데이터가 매우 많은 경우 모든 데이터를 사람이 일일히 다 살펴볼 수는 없다. – 그 다음에는 학습데이터(Training-set)을 얻기 위해서 하게 되는데, 정확히는 학습데이터에 레이블링(Labeling, Class를 부여)하기 위해서 이다. 학습을 시키기 위해서 데이터에 정답을 사람이 일일히 따주는 작업을 위한 것이다. 레이블 달 수 있는 적절한 분량만큼을 샘플링하는 것이고 샘플링한 데이터가 대상이 되는 데이터의 대표성을 잘 반영해야 한다. 개수로만 따질 문제는 아니다.
노파심에서 하는 말이지만 모든 데이터에 레이블이 이미 정확하게 다 달려 있다면 일반적으로 데이터마이닝에서 말하는 지도학습문제가 아니다. 모든 데이터에 레이블이 다 달려 있다면 지도학습을 할 필요가 없다.

그리고 만든 모델의 정확도를 판단하기 위해서 샘플링된 평가데이터(test set)등에 데이터를 대고 정확도를 점검한다. test-set은 때로는 training-set의 일부이기도 하고 아니기도 하다. – 보통은 training-set의 일부이다. –

이제 이렇게 만든 분류모델 -또는 예측모델 – 을 실제로 미지의 데이터에 적용하게 되는데 여기서는 실제로 평가데이터에 평가한 것 보다 대부분 결과가 안 좋게 나타난다. 여러가지 이유가 있을 것이다.
샘플링의 문제일 수도 있고 아닐 수도 있지만 결론은 어쨌든 미지의 데이터에 대해 예측을 잘 할 만큼 학습을 완벽하게 못한 것이다.

여기서 샘플링 문제라고 가정을 하고 극단적인 질문으로 학습데이터의 샘플링양을 늘리면 보편적으로 쉽게 잘 해결이 되느냐이다. 즉, 100억개의 모집단이 있고 이것을 위한 어떤 예측모델을 만드는데 학습데이터를 1000개를 쓰는 것보다 10000개를 쓰는 것이 더 유리하고 10000개 보다 100000개를 쓰는 것이 더 유리하냐는 것이다.
보편적으로는 그렇다라고 대답한다. 100억개의 다양성을 다 만족하기 위해서는 1000개나 10000개나 10만개도로 직감적으로도 적다는 것을 느낄 수 있다. 데이터가 아주 단조로운 데이터가 아니는 조건에서 말이다. – 물론 실제로 그 도메인에서 그런 것을 해봐야 알 것이다. 일반화하기는 다소 무리가 있다. – 그래서 10만개에서 100만개로, 100만개에서 1000만개로 학습데이터를 늘리면 다른 것 안해도 학습모델의 정확도가 더 좋아지냐? 가 사실 실제의 의문일 것인데.
모른다. 내 경험상 대부분 잘 안되기 쉽다.
100만개 이상의 학습데이터를 만드는 것 자체가 매우 불가능에 가까운 일이고 한다고 해도 그것을 제어하는 일이 거의 인간의 능력밖의 일이 된다. 100만개나 되는 데이터를 대표성을 가지게 잘 샘플링 하는 것 부터가 너무 어려운 문제이고 100만개를 태깅할 그럴 만한 돈이 현실적으로 없다. – 도메인에 따라서는 학습데이터가 수명을 가지는 경우도 많다. 오래되 면 못 쓰는 데이터가 생긴다는 것이다 –
결국 학습데이터를 늘리는 쪽을 기존 학습데이터를 이용해서 비슷한 데이터나 그렇지 부족한 영역의 데이터를 채워넣기 위해서 기계적인 방법을 이용하려고 하게 되고 그게 잘 알려진 Semi Supervised Learning이다. 이것을 준지도학습 또는 반지도학습이라고도 하는데 Semi Supervised Learning은 학습데이터가 부족한 경우외에도 학습데이터의 레이블이 심하게 불균형인 경우에도 사용한다.
Semi Supervised Learning에서 얼마만큼 어떻게 학습데이터를 기계적으로 채워넣어야 적절한지는 잘 모른다. 매우 어려운 문제이다. 나는 사실 이것을 제대로 해 본적이 없다. 내 능력의 제어권 밖이다.

그래서 지도학습에 있어서는

샘플링과 샘플링을 하지 않은 것의 비교는 불가능하고 원래의 논의 대상도 아니다. 그냥 이것은 뭘 어떻게 해도 다 샘플링이다.

데이터의 양의 차이가 있겠지만 샘플링에서 벗어날 수 없다.

비지도학습 (Unsupervised Learning)

클러스터링(Clustering) 또는 비교사학습, 비지도학습이라고한다.
학습데이터 없이 대충 알고리즘을 통해서 어떻게 데이터가 분류되는지를 보는 쪽이다. 결과에 대한 제어가 안된다. 다만 혹시 뭔가 다른 것을 볼 수 있지 않을까 호기심용으로 쓰이거나 대략 포괄적으로 뭔가 데이터를 분류해 보고 싶은데 어떤 기준으로 분류할지는 정해지지 않은 것을 할 때 쓴다.

이것도 샘플링과 관련이 있는가?

당연히 있다. 데이터베이스 내에 있는 전 사원을 분류해 보고 싶으며 샘플링이 아닌 것이고 고객의 일부 데이터나 전체 데이터를 이용해서 전체의 미지의 고객에 대한 분류를 해보 싶으면 샘플링이다. 또는 사내의 전 사원을 다 해보고 싶은데 양이 많아서 몇 명씩만 뽑아서 했다면 역시 샘플링이다.
알고리즘이나 알고리즘을 제어하기 이후의 문제로 데이터의 양으로 인해 군집화가 잘 되는지 알 안되는지는 차이가 있을 것이다. 클러스터링문제에 있어서 옳고 그름은 없다. 그냥 데이터의 양으로 인해 잘 드러나지 않은 군집이 드러나서 영향을 미치고 결과가 다르게 나올 수 있다.

결국 이것도 샘플링을 잘 하면 해결되는 문제가 아닌가?

라고 물을 수 있다. 분류된 군집의 개체수가 1개일 때와 10개일때와 100개일때의 의미가 없다라고 말한다면 그럴 수 있다. 하지만 대부분의 경우에는 의미가 있다. 이것은 데이터의 양에 따라 차이가 난다. 특별한 다수의 군집을 발견했는데 모두가 개체수가 1인 것과 10개인 것과 100개인것과 20인 것들의 차이가 있을때의 관찰자에게 생기는 시야의 차이는 있다. 물론 이것도 샘플링을 잘했을 때의 이야기라는데는 이견이 없다.
자세히 보고 싶다면 많으면 많을 수록 좋다. 그것이 아니라면 필요 없다.

샘플링을 안하는 것이 빅데이터가 아니라 샘플데이터가 많은 것도 빅데이터 문제이다.

비지도학습은 지도학습과는 달리 레이블링이 필요 없어서 데이터를 늘리는데 컴퓨팅 파워 외에는 문제될 것이 별로 없다. 다만 결과를 해석하고 반복하고 뭔가를 이해하려고 할 때 드는 부담이 매우 늘어날 뿐이다. 이것은 인간의 몫인데 슬슬 기계의 몫으로 넘기려고 하는 도전이 많다. 이것 또한 빅데이터 문제이다.

롱테일

롱테일, 파레토 법칙(Pareto law), 때로는 파워로우(Power law)까지를 잠깐 얘기해 보자.
파워로우는 잠깐 빼고 파레토쪽만 생각해 보면 80대 20으로 잘 알려진 이 문제는 데이터를 바라보는 관점과 해석하는 것에 따른 차이가 있다.
흔히 드는 얘가 대충 전체 매출의 80%를 만드는 것은 상위 20%의 고객이다라는 것으로 유력한 소수의 집단이 큰 흐름에 지대한 영향을 끼치는 것을 말한다. 앞서의 예에서는 두 가지 관점에서 데이터를 바라 볼 수 있는데

  • 전체 매출을 차지하는 20%의 개체들이 매우 중요하다고 보는 관점과
  • 20%의 대상은 소수이며 이미 잘 알려져 탐색이 된 상태이기 때문에 80%에 관심을 가져야 한다는 관점이다.

잘 생각해 보면 사실 이것은 샘플링을 하고 안하고의 문제와 관련이 없을 수 있다.

샘플링을 해도 20%가 80%의 매출을 차지하는 것과 같은 비중을 차지하는 것과 같은 패턴은 잘 달라지지 않는다. 안해도 결국 대부분 마찬가지이고. 80%의 매출을 일으키는 20%의 고객에게만 관심 있다면 이 문제에 있어서 빅데이터는 큰 문제가 아니다.
문제는 반대의 경우인데 이 경우에 20%의 매출을 만드는 80%의 고객들은

  • 영향략이 그리 크지 않지만 무시할 수준은 못된다.
  • 상위 20%의 고객에 대한 연구는 충분히 이루어졌고 더 할 것이 없어 보인다. 그래서 80%의 잉여스러운 존재에 대해서 눈을 돌리고 싶다.
  • 그러나 쪽수도 많고
  • 다양성 때문에 일일히 케어 하자면 너무 디테일 해져야 할 수도 있고
  • 잘 드러나지 않은 것들이 많아서 특성을 살피기에는 투자가 많이 필요하다.

라는 것이 문제다. 경쟁 우위를 확보하기 위해서 이 80%를 케어하기 시작한 것은 제법 오래되었다. 그런데 이런 디테일함을 케어하기 위해서는 사람이 다하기 어려우니 비교적 컴퓨팅파워를 이용해서 기계적으로 뭔가를 얻어내려한다. 이것도 빅데이터 문제다. 물론 이 문제도 대상을 정확하게 규명하고 하나씩 샘플링 해가면서 하면 되지 않느냐인데. 해도된다. 하지만 이제 그러기에는 데이터가 너무 많아지고 있다.

자질 추출 (Feature Extraction)

이 문제는 샘플링과 상관이 없을 가능성이 높다.
지도학습이던지 비지도학습이던지 알고리즘을 돌리고 모델을 만드려면 자질(Feature, 또는 attribute라고 한다. 통계학에서는 독립변수 또는 파생변수등의 변수라고 할 수 있겠다)을 추출해야 한다. – 베이지안 계열 중에는 이 과정이 단순히 카운트 세는 것으로 끝나는 경우가 있어 마치 이 과정이 없는 것처럼 보일 수도 있다. – 보통 ETL(Export, Transform, Loading)과정에서는 이것을 집계(Aggregation)라고도 말할 수도 있는데 컴퓨팅파워(Computation power)가 많이 소모되지만 최근에는 가능하면 많이 넣으려는 추세다. – 자질(Feature)을 많이 넣으면 많이 넣을 수록 좋다는 말이 절대 아니다. 교과서들에도 자주 나오지만 자질이 많다고 반드시 좋은 모델이 생성되는 것은 아니다 – 많은 자질들이 효과가 있는지 시도 해 보려고 한다는 것이고 단순하게 몇개만 해봐서는 성능향상이 더 이상 나오지 않는 것이 많다는 것이다. 자질 추출은 단순히 대상의 레코드 뿐만 아니라 전체의 레코드에 대해서 스캔을 다 해봐야 하는 경우도 의외로 많다.
검색엔진 같은 것에서 많이 쓰는 TFIDF같은 텀(Term)의 가중치를 추출하는 것이 그렇다. 컴퓨팅파워가 극도로 많이 소모되고 모델을 만들 때도 만든 모델을 적용할 때도 똑같이 필요한 과정이다. 그래서 컴퓨팅 파워가 많이 소모될 수 밖에 없는데 이 것은 그대로 빅데이터 문제가 되기 쉽다. 그리고 자질의 값들 중 일부는 연관이 있는 다른데이터의 샘플링을 하고나서 생성된 값을 쓰는 경우가 있다. 매우 데이터가 많고 복잡한 모델의 경우 이런 것도 하게 되는데 샘플링을 한 값을 자질로 넣기 위해서는 그것을 결정하는 사람이 매우 수준이 높고 연구를 많이 해야 하고 그것에 대한 전체 흐름과 영향에 대해서 완전히 파악하지 않으면 위험하기 짝이 없는 자질이 된다. 그럼 빅데이터 솔루션으로 샘플링하지 말고 다 하면 되겠네? 비꼬는 질문이 날아 올텐데 상황상 안되는 경우도 비일비재하고 데이터를 조인의 조인의 조인의…을 하다보면 자원이 천문적으로 필요한 도메인도 세상에는 존재한다. 어느 부분에 있어서도 데이터 처리의 문제는 샘플링 문제를 사실상 벗어나기 어렵다. 빅데이터를 한다고 해도 기본적으로 그 소양은 갖추고 있어야 유리하다는 것이다.

특별한 대상을 탐색하기 위한 수준 높은 샘플링

제대로 공부했고 제대로 훈련된 분석가라면 특별한 대상을 탐색하고 분석하기위해서 샘플링을 충분히 잘 할 수 있고 그것으로 해석이 가능하고 충분하다고 말할 수 있다. 샘플링을 충분히 잘 할 수 있으면 사람이 충분히 제어할 만한 수준이 되므로 모든 데이터를 또는 대용량의 데이터를 다 들여다 보지 않아도 충분하다라고 말할 수 있다.

샘플링을 제대로 하지도 못하면서 그냥 데이터만 막 들이밀면 문제가 잘 해결될 것 처럼 말하지 말라!

라는 말을 자주 들을 수 있다. 샘플링과 대용량 데이터에 대한 얘기가 나오면 피를 토하고 말씀하시는 분들의 요점은 이것인 것 같다.

맞는 말 같다.

정말 지당하게 맞는 말이라고 생각한다. 하지만 사실 나는 이것을 아주 잘하는 사람을 실제로 몇 명 보지 못했다. 그래서 잘 안되고 있다고 생각한다. 내가 많이 보지 못했기 때문에 그런 사람들이 드믈것이라고 말하는 것에 어폐가 있다고 할 수 있다. 인정한다.
하지만 그래도 반박하자면…
말로는 뭔들 못할까? 밥그릇 챙기기로 보이는 행위를 굳이 할 필요는 없다. 보여주면 되는 것이다. 나는 아직 그런분들을 많이 보지 못했다.
샘플링해서 분포를 보고 이 분포가 맞는지 안 맞는지 오차가 얼마인가를 생각하는 것 보다는 전체를 카운팅해서 집계(aggregation) 한 다음에 히스토그램(histogram) 그리는 것이 더 명확하고 쉽다.

외국계 IT포털에서 일하면서 많은 아이디어를 많은 데이터에서 단지 팩터(Factor)별로 카운트 해 보는 것만으로도 독특한 아이템이나 관점을 찾아내는 사람을 많이 봤다. 물론 막대한 양의 컴퓨팅 파워가 필요하기 때문에 이것 조차도 일반적인 환경으로는 쉽게 따라 할 수 없는 것이긴 하다.
이런 간단한 것들이 때로는 간단한 것이 회사의 매출에 지대한 영향을 끼치기도 했었다. 몇몇의 것들은 사실 별것 아닌 것 같으면서도 이런 것들이 이루어져서 새로운 거대한 흐름을 만들기도 했다. 보통 이런것들은 바깥세상에 숨기기 마련이다. 별것 아닌 것이서 그럴 수도 있고 알려지면 따라하기 때문에 그것이 곤란해서 일 수도 있다. 이런 간단하면서도 충격적인 것들은 사내에서도 대내 기밀인 경우도 많다. 알려지면 누구나 따라하기 때문에 알려지는 시점을 늦추고 최대한 시간을 벌려는 것이다. 알고 나면 정말 별거 아닌 것들이다. 먼저 알아내서 깃발 꽂으면 되는 것들.

구글의 페이지링크와 같은 것들처럼 알고 나면 별것 아닌 것이다.

알고 나면 별거 아닌 것 같은 콜럼부스의 달걀 같은 것이다.

남들도 알고 있고 나도 알고 있는 것은 경쟁에 있어서 무기가 되지 않는다.

그것을 위해서 수단 방법을 가리지 않는 것이고 샘플링을 하고 안하고의 이전에 있어서 현대에 기업이나 사업에서는 수단방법을 가리지 않으려고 한다. 그것이 샘플링이 되었던지 통계학의 깊은 수준의 지식이 필요하든지를 떠나서 말이다.

데이터와 정보처리에 있어 그 수단 중 하나가 빅데이터 솔루션이다. 우리가 어떤것에 대해서 얘기할 때 구체적으로 무엇에 대해서 얘기하고 있는지 곰곰히 생각해 볼 필요가 있다. 나는 빅데이터를 해도 샘플링을 해야 하는 문제는 결국 그럴 수 밖에 없다고 생각하는 주의이고 그 문제를 컴퓨팅 자원을 소모해서 쉽게 해결할 수 있다면 가능한 그 방법을 택하겠다는 주의이다. 나는 빅데이터가 기존의 통계학도들이나 빅데이터에 적응하지 않으려하는 데이터 분석가들의 밥줄을 끊던 말던 사실상 관심이 없다. 알아서 챙겨야 할 문제다.
이미 사회에 진출하는 많은 학생들이 빅데이터에 대한 학습도 많이 하고 진출하고 있다. 사실 나는 그들이 매우 두렵다.

통계쪽에 대해서는 얘기를 하지 않았지만 그래도 하고 싶은 말은 있다.
혹시 이 글을 읽는 분들 중에서 통계학에 정통을 했으며 샘플링 문제에 있어서 고수준의 지식을 가지고 있는 분들이 있고 솔직하게 생각해서 그런 분들이 어줍잖게 컴퓨터의 힘을 빌어 그런 깊은 지식에 대한 학습의 노력없이 당장 나온 결과만 보고 따라 오려는 사람들을 불편하게 생각하는 분이 있다면 그 분들도 더 노력을 해야할지 모르겠다. 기계가 어느 정도 많은 것을 해결해 주는 시기가 점점 오고 있다는 것은 분명하니까.

R과 Interactive visualization의 문제

R과 관련없이 유명한 상용 Interactive Data Visualization 툴로는 Spotfire가 있습니다.
Spotfire는 그래프를 그리고 그래프의 영역을 계속 마우스로 선택해 나가면서 데이터를 탐색하게 해주는 툴입니다.
이 포스트에서 언급하는 것들은 주로 spotfire같은 것은 인터랙티브하게 반응하는 UI를 말합니다.
Processing이나 Paper.js같은 미디어아트와는 다소 다릅니다.

Interactive Data Visualization이 뭔데?

데이터 분석에서 Interactive Data Visualization 이 필요한 이유는 데이터탐색을 빠르고 직관적으로 하기 위한 것입니다.
엑셀같은 스프레드시트에 수치를 적어넣고 그래프를 다시 그리거나 R같은 곳에서 코드 적어가며 그래프를 완성해 나가는 방법은 탐색을 하는데 있어 시간이 꽤 걸리고 불편하다는 것입니다.

쉽게 할 수 있는 방법이 있다면 쉽게 해야 한다. 그것이 모티브입니다.

Interactive Data Visualization 애플리케이션이 작동하는 방식은 대충 특정 데이터를 로딩한 다음 그것에 대한 기본 그래프(플롯)나 여러 그래프를 나열해 놓고 한쪽에서 마우스로 눈에 띄는 영역이나 다른 영역을 선택하면 다른 플롯에서도 그 부분이 별도로 표시할 수 있고, 확대도 할 수 있고, 다른 플롯으로 다시 그려볼 수도 있게 해줍니다.

이런 과정을 매우 유연하고 편하고 반복적으로 하게 해주는 것을 말합니다.

때로는 애니메이션 기능을 이용해서 움직이게 만드는 것도 이 부류에 넣기도 하는데 애니메이션은 사실 직관을 찾기 위한 용도이지 진짜 탐색을 위한 용도는 아닌 경우가 많지요.  그부분은 다른 포스트에 따로 적기로 하겠습니다.

R과 Interactive Visualization을 말하기 전에 우선 결론적으로

R로 Interactive Visualization을 구현 하는 것이 매우 어렵다.

R을 위한 Interactive Visualization 패키지로는 ggobi, cranvas, iplot(Acinonyx)등이 가장 유명합니다. 그 외에도 다수가 있지만 그렇게 주류로 사용되지 않습니다. 일반적인 플로팅 패키지중에서 비교적 Interactive Visualization에 가까운 것으로는 역시 ggplot2가 있습니다. ggplot2에 대한 내용은 여기서 자세히 얘기하지 않겠습니다.

R로 Interactive Visualization이 잘 안되는 이유들

우선 아예 안되는 것이 아니라 잘 안되는 것이라고 말해둡니다.  오해의 여지를 줄이기 위해서

1. Cross platform을 위한 렌더링 엔진 문제

iplot과 ggobi같은 R 패키지는 GTK를 사용하고 cranvas는 Qt SDK를 interfacing해 놓은 qtbase 라는 R패키지에 강한 의존성을 가집니다. 물론 이 패키지들도 플랫폼에 따라 렌더링 엔진이 조금씩 다르긴 하지만 적어도 Mac OS X와 Linux를 위한 버전은 확실하게 의존성이 강합니다.  이런 패키지들이 렌더링 엔진을 이렇게 지저분하게 선택해야 하는 이유는 당연히 Cross platform 때문인데 대부분의 R사용자들은 Windows를 사용하지만 대부분의 R의 코어나 패키지 개발자들은 Windows를 사용하지 않고 Linux나 Mac을 사용합니다. 그리고 현존 하는 가장 유력한 범용 Cross Platform용 렌더링 엔진은 Qt, GTK, Java 정도입니다.
Java는 렌더링 엔진이 아니지만 어쨌든 크로스플랫폼으로 화면을 제어할 수 있어서 포함했습니다.
그 외에는 Browser기반의 Javascript + HTML5가 고려해 볼만한 대상이 되겠습니다.

대부분 Interactive Visualization 의 경우 여기서부터가 문제가 생깁니다.
Cranvas는 qtbase를 사용하지만 qtbase는 Windows를 지원하지 않으며 QtSdk를 설치하는 것도 매우 귀찮은 일이고
ggobi와 iplot2가 사용하는 GTK는  Qt보다 설치가하기 더 지저분합니다.
Java는 R과 인터페이싱하기가 너무 복잡하다는 문제점이 있습니다.
이 경우에는 rJava를 사용해서 R에서 Java를 제어할 것인지 Rj를 사용해서 Java에서 R을 제어할 것인지도 고민이 됩니다.
또 R의 패키지는 렌더링엔진을 포함해서 배포할 수 없는 구조이고 사용자가 알아서 다 설치해야 한다는 점입니다.

여기까지의 요점은 아래와 같습니다.

  1. Qt나 Qtk관련 패키지들은 설치 자체가 어렵고
  2. Java는 Interfacing 자체가 또 하나의 숙제고
  3. HTML5+Javascript는 매우 복잡하고 지저분하다.
2. 기존 plotting 평션의 재활용 문제

R에는 많은 plotting관련 패키지들이 있습니다. 기본으로 제공하는 것도 물론 매우 훌륭한다. 대부분의 현존하는 모든 형태의 2차원 플롯은 다 지원하고 미려하고 섬세한 표현이 가능하긴합니다.
하지만 사용자마다 쓰는 플롯이 다르고 원하는 바도 많이 다릅니다.

사람의 욕심은 끝이 없어서 이 미려한 R의 플로팅을 인터렉티브 플로팅에서도 보고 싶어하지만
안타깝게도 렌더링할때 때로는 R의 플로팅용 device를 다시 개발해야하는 문제가 있으며 인터랙티브요소 때문에 plotting에 대한 펑션을 다시 제작해야 하는 경우가 대부분입니다.

이런 방식은 기본 플로팅 평션을 그대로 쓸 수가 없다.

결국 포기하고 포팅을 하거나 새로 만들게 되는데 R의 패키지 제작자들이 많아 1 ~ 2명 정도가 대부분인 것으로 볼 때 많은 종류의 플롯을 지원하기가 당연히 어려울 것이다. 완성도가 높을 수가 없습니다.
대충 어렵게 설치해서 Cranvas, iplot등을 어렵게 쓴다고 해도 이 패키지들의 결과물의 상태가 문제점이 많습니다.

그리 빠르지 않다.
그리 예쁘지 않다.
그리 편하지 않다.

실제로는 그리 쓸만하지 않다는 것입니다.

3. HTML5+Javascript을 활용하는 것은 어색하다.

그러면 크로스플랫폼 문제라도 해결하기 위해서 Application based에서 Web based로 전환하면 어떨까? Web based라면 플랫폼문제가 해결되고 기존의 플로팅 펑션을 그대로 활용하는 것은 일단 포기하는 것으로 생각하고 성능과 편리함을 미세하게 조절하고 경쾌하게 움직이는 것도 역시 다소 희생한다고 하면 시도해 볼 수도 있겠습니다.

R이 범용 랭귀지가 아니기 때문에 이 또한 우아하게 해결이 되지 않지만 그래도 할 수는 있습니다. R로 web service를 할 수 있는 잘 알려진 방법은 다음의 두가지입니다.

  • Apache를 설치하고 rApache모듈을 붙여서 R로 CGI 코딩을 한다.
  • Rook 패키지를 설치해서 CGI코딩을 하고 로칼에서 브라우저로 R에 접속한다.

이 외에도 많지만 요즘 대세는 위 두가지입니다.
위의 두가지중 하나를 선택한 후에는 base로 사용할 Javascript framework을 선택해야 하는데
Processing.js, paper.js, hichart, ExtJs등을 선택할 수 있습니다.

그런데 이쯤되면

이걸 왜 R로 해야하지?

라는 의문이 생깁니다.
애초에 R을 이용한 Interactive Visualization을 하고 싶은 이유는 앞에서 말하지는 않았지만
아래와 같은 이유 때문이 많습니다.

  • R의 강력한 플로팅 기능을 그대로 활용
  • R의 다양한 알고리즘, 펑션이나 관련 패키지를 그대로 활용
  • 최대한 R base에서 많은 부분을 할 수 있도록해서 사용성을 높임

어떤 방법을 선택해도 위 문제중 2가지 이상을 쉽게 해결해 주지 못합니다.
첫번째는 기존 플로팅 펑션을 포팅하는 방법외에는 길이 없습니다.
두번째는 R을 베이스로 작동하게 하면 해결되긴 합니다.
세번째가 문제인데
이것을 해결하기 위해서는 너무 많은 삽질이 필요합니다.
지금까지 제 결론은

R의 그래픽 디바이스를 Web 기반으로 작동하게 하나 만들고 그 디바이스를 이용한 플롯펑션을 만들고, 그리고 인터페이스쪽 부분을 Javascript로 떡칠하는 것입니다.

물론 여기까지의 이런 고민들은 Windows라는 OS를 포기하고 나 혼자만 쓰기로 작정하고 Cocoa 기반으로 만들면 됩니다.  하지만 그러기에는 Windows사용자가 너무 많습니다.

더구나 Big Data를 위해서 Hadoop, Hive, RHive 연동까지도 더불어 생각하면 선택의 폭이 더욱더 좁아집니다.