카테고리 보관물: 미분류

빅데이터와 텍스트마이닝

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

빅데이터(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입니다)

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

#!!{"brush":"r"}
filepath <- "/Users/euriion/Downloads/skt_datahub/seoul_calltaxi/"

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

#!!{"brush":"r"}
system(paste("cd", filepath, "; ", "ls -1 *.tsv")) 

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

#!!{"brush":"r"}
filenames <- c(
"서울지역+콜택시+대리운전+이용분석_2013년+8월.tsv",
"서울_콜택시_대리운전이용분석_201309.tsv",
"서울_콜택시_대리운전이용분석_201310.tsv",
"서울_콜택시_대리운전이용분석_201311.tsv",
"서울_콜택시_대리운전이용분석_201312.tsv",
"서울_콜택시_대리운전이용분석_201401.tsv",
"서울_콜택시_대리운전이용분석_201402.tsv"
)

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

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

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

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

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

#!!{"brush":"r"}
system(paste("cd", filepath, "; ", "ls -1 *.tsv | xargs -n 1 head -1 | sort | uniq -c"))

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

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

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

그래야 다루기 쉽습니다.

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

plyr 설치하기

#!!{"brush":"r"}
if (!require(plyr)) { 
    install.packages("plyr") 
}

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

#!!{"brush":"r"} 
filenames.fullpath <- paste0(filepath, filenames) 
filenames.fullpath

아래는 결과입니다.

#!!{"brush":"r"}
## [1] "/Users/euriion/Downloads/skt_datahub/seoul_calltaxi/서울_콜택시_대리운전이용분석_201309.tsv" 
## [2] "/Users/euriion/Downloads/skt_datahub/seoul_calltaxi/서울_콜택시_대리운전이용분석_201310.tsv" 
## [3] "/Users/euriion/Downloads/skt_datahub/seoul_calltaxi/서울_콜택시_대리운전이용분석_201311.tsv" 
## [4] "/Users/euriion/Downloads/skt_datahub/seoul_calltaxi/서울_콜택시_대리운전이용분석_201312.tsv" 
## [5] "/Users/euriion/Downloads/skt_datahub/seoul_calltaxi/서울_콜택시_대리운전이용분석_201401.tsv" 
## [6] "/Users/euriion/Downloads/skt_datahub/seoul_calltaxi/서울_콜택시_대리운전이용분석_201402.tsv" 
## [7] "/Users/euriion/Downloads/skt_datahub/seoul_calltaxi/서울지역+콜택시+대리운전+이용분석_2013년+8월.tsv" 

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

#!!{"brush":"r"}
df <- read.table(filename, , sep = "t", header = F, skip = 1)))

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

#!!{"brush":"r"}
head(df)

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

#!!{"brush":"r"}
NROW(df)

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

#!!{"brush":"r"}
system(paste("cd", filepath, "; ", "wc -l *.tsv"))

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

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

#!!{"brush":"r"}
colnames(df)

아래는 결과입니다.

#!!{"brush":"r"}
"Filename" "V1" "V2" "V3" "V4" "V5"

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

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

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

컬럼이름을 바꿔줍니다.

#!!{"brush":"r"}
colnames(df) <- c("yearmon", "sido", "gugun", "dong", "freq")

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

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

#!!{"brush":"r"}
head(df)

아래는 결과입니다.

#!!{"brush":"r"}
yearmon sido gugun dong freq
1 201309 서울특별시 강남구 압구정동 5
2 201309 서울특별시 강남구 일원2동 8
3 201309 서울특별시 강남구 대치3동 39
4 201309 서울특별시 강남구 일원동 55
5 201309 서울특별시 강남구 압구정1동 82
6 201309 서울특별시 강남구 대치1동 87

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

빅데이터와 샘플링 – Big data and Sampling

한 번쯤 생각을 정리할 필요가 있다고 생각해서 포스팅합니다.
이런 내용은 다루기에는 조심스럽고 복잡한 것이긴 합니다.
빅데이터 문제를 언급하며 흔히 하는 말은, 기존에 알 수 없었던 것들을 많은 데이터 또는 방법론을 적용함으로써 알아낼 수 있다는 것입니다.
굉장히 그럴듯한 말이고 받아들이기에 따라 조금 위험하긴 하지만 사실 틀린 말은 아닙니다.
실제 전수 데이터로 분석한 것과 샘플링을 통해 추정한 것에는 차이가 있을 수 있기 때문입니다.
여기서 약간의 함정은 “다를 수도 있다”입니다. (또는 조심스럽게는 ‘다른 경우가 많다’라고 표현하겠습니다)
이를 반박하는 사람들은 샘플링을 통한 전통적인 통계분석과 빅데이터를 통한 분석이 “별반 다르지 않다”라고 말합니다.
이것이 논쟁의 핵심입니다. 아직도 애매하고 논란의 여지가 있는 부분입니다.
빅데이터를 통한 데이터분석이 전통적인 샘플링 기반의 통계적 분석보다 더 나은 점이 무엇인지, 즉 이론적으로 어떻게 그렇게 되는지 증명해보라고 한다면…
저는 못하겠습니다. 그냥 경험에 비추어 말하는 것입니다. (무책임한 저입니다)
잠깐 옆으로 새서 통계와 빅데이터, 샘플링에 대한 논점에 관한 제 입장을 말씀드리면, “거의 모든 경우에 샘플링으로 거의 모든 문제를 해결할 수 있습니다. 그렇지 않습니다”라고 말하기가 조금, 아니 상당히 조심스럽습니다. 이와 관련해서 여러 관점을 가진 사람들이 달라붙어 말을 꺼낸 사람을 무지몽매한 사람처럼 취급하며 공격하기 시작하기 때문입니다. 학문적 깊이와 고민이 부족해서 이론적으로, 논리적으로, 경험적으로 응대하기 어렵다면 이런 민감한 문제에 대해서는 입을 닫는 것이 처세에 유리할 수 있습니다.
최근의 저는 입을 닫는 쪽입니다. 저는 시류에 편승하는 것처럼 보이려고 노력하는 쪽입니다.
통계적 방법론에서는 샘플링을 통한 방법과 모델의 최적화 방법, 추정방법이 잘 정립되어 있어서 꼭 전수조사를 하지 않아도 대략적인 결과는 맞아떨어지거나, 전수조사(또는 전수조사에 필적할 만큼 많은 검사)를 한 것과 샘플링을 한 것의 차이가 거의 없습니다.
위에서 말한 것이 빅데이터의 “빈약한 필요성”을 반박하는 쪽의 주장입니다. 문제는 이를 반박할 만한 뚜렷한 이론이나 논리, 경험을 제가 가지고 있지 않다는 것입니다. 솔직히 잘 모르겠습니다. 저는 여기에 대한 깨달음이나 확고한 주관이 없습니다. 이것이 앞서 말한 제가 입을 닫는 이유입니다. 아주 깊이 고민해 본 적이 없고, 통계학을 조금이라도 공부했다는 사람들이 다 안다는 중심극한정리도 끝까지 제대로 이해하지 못하고 있습니다. 노파심에 말씀드리지만, 아예 정의나 작동 방식을 모르는 것은 아니지만 기저의 원리를 완전히 이해하지 못했다는 뜻입니다. 결국… 모른다는 말입니다.
그런 것도 제대로 모른다는 사람이 이런 포스트를 건방지게 올리느냐고 하신다면, 조용히 다른 사이트로 이동해 주시기를 정중히 부탁드립니다.
그런데 생각해보면 말장난 같긴 하지만, 위에서 말한 샘플링 논쟁의 핵심은 ‘무엇을 하는데’ 샘플링을 한다, 안 한다는 말이 나오느냐는 것입니다.
데이터의 분포를 확인하기 위해서는 샘플링으로 충분한 것인지, 예측모델을 만들기 위해서도 샘플링으로 충분한 것인지, 살펴봐야 하는 대상이 롱테일의 테일 부분인데도 샘플링으로 충분한 것인지…
인터넷상에 떠도는 글이나 블로그 등을 봐도 이런 부분에 대해서는 잘 언급하지 않고 포괄적으로만 말합니다. 물론 지면 관계상 그랬을 수 있습니다. 그런데 설명하지 않는 것도 문제입니다. “그런 것쯤은 공부를 했다는 사람이면 충분히 기본으로 알고 논점에 들어가야 하는 것 아닌가요?”라고 되물을 수도 있을 텐데, 이것은 정말 말장난이라고 생각합니다. 무엇에 대해서든 정확히 무엇을 하려고 하는지 명시해야 합니다. “상대가 무지해서 대화가 안 돼!”라는 식의 태도는 교만함으로 인한 자신의 무지함을 감추기 위한 것이라고 생각합니다. 아닐 수도 있겠지만 대부분은 그렇다고 생각합니다.
통계 분야에 대한 깊이는 부족하지만, 샘플링도 충분히 가능함에도 불구하고 샘플링을 하지 않고 전수조사를 해보려는 이유는 일반적(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, 클래스 부여)하기 위해서입니다. 학습을 시키기 위해 데이터에 정답을 사람이 일일이 달아주는 작업을 위한 것입니다. 레이블을 달 수 있는 적절한 분량만큼 샘플링하는 것이고, 샘플링한 데이터가 대상 데이터의 대표성을 잘 반영해야 합니다. 단순히 개수로만 따질 문제는 아닙니다.
노파심에 말씀드리지만, 모든 데이터에 레이블이 이미 정확하게 다 달려 있다면 일반적으로 데이터마이닝에서 말하는 지도학습 문제가 아닙니다. 모든 데이터에 레이블이 다 달려 있다면 지도학습을 할 필요가 없습니다.
그리고 만든 모델의 정확도를 판단하기 위해 샘플링된 평가 데이터(test set) 등으로 정확도를 점검합니다. test set은 때로는 training set의 일부이기도 하고 아니기도 하지만, 보통은 training set의 일부입니다.
이제 이렇게 만든 분류 모델(또는 예측 모델)을 실제로 미지의 데이터에 적용하게 되는데, 여기서는 실제로 평가 데이터로 평가한 것보다 대부분 결과가 더 안 좋게 나타납니다. 여러 가지 이유가 있을 것입니다.
샘플링의 문제일 수도 있고 아닐 수도 있지만, 결론은 어쨌든 미지의 데이터에 대해 예측을 제대로 할 만큼 학습이 완벽하지 못한 것입니다.
여기서 샘플링 문제라고 가정하고 극단적으로 질문해보면, 학습 데이터의 샘플링 양을 늘리면 보편적으로 쉽게 잘 해결되느냐는 것입니다. 즉, 100억 개의 모집단이 있고 이를 위한 예측 모델을 만드는데, 학습 데이터를 1,000개 쓰는 것보다 10,000개를 쓰는 것이 더 유리하고, 10,000개보다 100,000개를 쓰는 것이 더 유리한가요?
보편적으로는 그렇다고 대답합니다. 100억 개의 다양성을 모두 만족하기 위해서는 1,000개나 10,000개나 10만 개로도 직관적으로 부족하다는 것을 느낄 수 있습니다. 데이터가 아주 단조로운 데이터가 아니라는 조건에서 말입니다. 물론 실제로 그 도메인에서 직접 해봐야 알 것입니다. 일반화하기는 다소 무리가 있습니다. 그렇다면 10만 개에서 100만 개로, 100만 개에서 1,000만 개로 학습 데이터를 늘리면 다른 것 안 해도 학습 모델의 정확도가 더 좋아질까요? 이것이 사실 실제의 핵심 질문일 것입니다.
모릅니다. 제 경험상 대부분 잘 안 되기 쉽습니다.
100만 개 이상의 학습 데이터를 만드는 것 자체가 거의 불가능에 가까운 일이고, 한다고 해도 그것을 제어하는 일이 거의 인간의 능력 밖의 일이 됩니다. 100만 개나 되는 데이터를 대표성 있게 잘 샘플링하는 것부터가 너무 어려운 문제이고, 100만 개를 태깅할 만한 예산이 현실적으로 없습니다. 도메인에 따라서는 학습 데이터가 유효 기간을 가지는 경우도 많습니다. 오래되면 못 쓰는 데이터가 생긴다는 것입니다.
결국 학습 데이터를 늘리는 방향으로 기존 학습 데이터를 이용해서 유사한 데이터나 부족한 영역의 데이터를 채워 넣기 위해 기계적인 방법을 이용하게 되고, 그것이 잘 알려진 준지도학습(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(Extract, Transform, Load) 과정에서는 이것을 집계(Aggregation)라고도 하는데, 컴퓨팅 파워(Computation power)가 많이 소모되지만 최근에는 가능하면 많이 넣으려는 추세입니다. 자질(Feature)을 많이 넣으면 많이 넣을수록 좋다는 말이 절대 아닙니다. 교과서에도 자주 나오지만 자질이 많다고 반드시 좋은 모델이 생성되는 것은 아닙니다. 다만 많은 자질들이 효과가 있는지 시도해보려 한다는 것이고, 단순하게 몇 개만 해봐서는 성능 향상이 더 이상 나오지 않는 경우가 많다는 것입니다. 자질 추출은 단순히 대상 레코드뿐만 아니라 전체 레코드에 대해 스캔을 다 해봐야 하는 경우도 의외로 많습니다.
검색엔진 같은 곳에서 많이 쓰는 TF-IDF 같은 용어(Term)의 가중치를 추출하는 것이 그렇습니다. 컴퓨팅 파워가 극도로 많이 소모되고, 모델을 만들 때도 만든 모델을 적용할 때도 똑같이 필요한 과정입니다. 그래서 컴퓨팅 파워가 많이 소모될 수밖에 없는데, 이것은 그대로 빅데이터 문제가 되기 쉽습니다. 그리고 자질의 값들 중 일부는 연관된 다른 데이터를 샘플링하고 나서 생성된 값을 쓰는 경우가 있습니다. 데이터가 매우 많고 복잡한 모델의 경우 이런 것도 하게 되는데, 샘플링한 값을 자질로 넣기 위해서는 그것을 결정하는 사람이 매우 수준이 높고 연구를 많이 해야 하며, 전체 흐름과 영향에 대해 완전히 파악하지 않으면 위험천만한 자질이 됩니다. “그럼 빅데이터 솔루션으로 샘플링하지 말고 다 하면 되겠네요?”라는 비꼬는 질문이 나올 텐데, 상황상 안 되는 경우도 비일비재하고 데이터 조인을 반복하다 보면 자원이 천문학적으로 필요한 도메인도 세상에는 존재합니다. 어느 부분에 있어서도 데이터 처리 문제는 샘플링 문제를 사실상 벗어나기 어렵습니다. 빅데이터를 한다 해도 기본적으로 그 소양은 갖추고 있어야 유리하다는 것입니다.
특별한 대상을 탐색하기 위한 고수준 샘플링
제대로 공부하고 제대로 훈련된 분석가라면 특별한 대상을 탐색하고 분석하기 위해 샘플링을 충분히 잘할 수 있고, 그것으로 해석이 가능하며 충분하다고 말할 수 있습니다. 샘플링을 충분히 잘할 수 있으면 사람이 충분히 제어할 만한 수준이 되므로, 모든 데이터를 또는 대용량 데이터를 다 들여다보지 않아도 충분하다고 말할 수 있습니다.
“샘플링을 제대로 하지도 못하면서 그냥 데이터만 막 들이밀면 문제가 잘 해결될 것처럼 말하지 마세요!”
라는 말을 자주 들을 수 있습니다. 샘플링과 대용량 데이터에 대한 얘기가 나오면 절절하게 말씀하시는 분들의 요점이 바로 이것인 것 같습니다.
맞는 말입니다.
정말 지당한 말씀이라고 생각합니다. 하지만 사실 저는 이것을 아주 잘하는 사람을 실제로 많이 보지 못했습니다. 그래서 잘 안 되고 있다고 생각합니다. 제가 많이 보지 못했기 때문에 그런 사람들이 드물다고 말하는 것에 무리가 있다고 할 수 있습니다. 인정합니다.
하지만 그래도 반박하자면…
말로는 뭔들 못할까요? 영역 다툼으로 보이는 행위를 굳이 할 필요는 없습니다. 실제로 보여주시면 되는 것입니다. 저는 아직 그런 분들을 많이 보지 못했습니다.
샘플링해서 분포를 보고 이 분포가 맞는지, 오차가 얼마인가를 계산하는 것보다는 전체를 카운팅해서 집계(aggregation)한 다음 히스토그램(histogram)을 그리는 것이 더 명확하고 쉽습니다.
외국계 IT 포털에서 일하면서 많은 아이디어를 많은 데이터에서 단지 요인(Factor)별로 카운트해보는 것만으로도 독특한 아이템이나 관점을 찾아내는 사람을 많이 봤습니다. 물론 막대한 양의 컴퓨팅 파워가 필요하기 때문에 이것조차도 일반적인 환경에서는 쉽게 따라 할 수 없는 것이긴 합니다.
이런 간단한 것들이 때로는 회사의 매출에 지대한 영향을 끼치기도 했습니다. 몇몇 사례들은 사실 별것 아닌 것 같으면서도 이런 것들이 모여 새로운 거대한 흐름을 만들기도 했습니다. 보통 이런 것들은 바깥세상에 공개하지 않습니다. 별것 아닌 것이어서 그럴 수도 있고, 알려지면 경쟁사가 따라하기 때문에 그것이 곤란해서일 수도 있습니다. 이런 간단하면서도 임팩트 있는 것들은 사내에서도 기밀인 경우가 많습니다. 알려지면 누구나 따라 하기 때문에 공개 시점을 최대한 늦추고 선점 효과를 누리려는 것입니다. 알고 나면 정말 별것 아닌 것들입니다. 먼저 알아내서 선점하면 되는 것들이죠.
구글의 페이지랭크와 같은 것들처럼 알고 나면 별것 아닙니다.
알고 나면 별것 아닌 것 같은 콜럼버스의 달걀 같은 것입니다.
남들도 알고 있고 저도 알고 있는 것은 경쟁에서 무기가 되지 않습니다.
그것을 위해서 수단과 방법을 가리지 않는 것이고, 샘플링 여부 이전에 현대 기업이나 사업에서는 수단과 방법을 가리지 않으려 합니다. 그것이 샘플링이든 통계학의 고수준 지식이 필요하든 상관없이 말입니다.
데이터와 정보 처리에 있어 그 수단 중 하나가 빅데이터 솔루션입니다. 우리가 무언가에 대해 얘기할 때 구체적으로 무엇에 대해 얘기하고 있는지 곰곰이 생각해볼 필요가 있습니다. 저는 빅데이터를 해도 샘플링을 해야 하는 문제는 결국 그럴 수밖에 없다고 생각하는 입장이고, 그 문제를 컴퓨팅 자원을 소모해서 쉽게 해결할 수 있다면 가능한 한 그 방법을 택하겠다는 입장입니다. 저는 빅데이터가 기존 통계학도들이나 빅데이터에 적응하지 않으려는 데이터 분석가들의 생계를 위협하든 말든 사실 관심이 없습니다. 각자 알아서 대비해야 할 문제입니다.
이미 사회에 진출하는 많은 학생들이 빅데이터에 대한 학습도 많이 하고 진출하고 있습니다. 사실 저는 그들이 매우 두렵습니다.
통계 쪽에 대해서는 얘기하지 않았지만 그래도 하고 싶은 말은 있습니다.
혹시 이 글을 읽는 분들 중에서 통계학에 정통하며 샘플링 문제에 있어 고수준의 지식을 가지고 계신 분들이 계시고, 솔직하게 생각해서 그런 분들께서 어설프게 컴퓨터의 힘을 빌려 깊은 지식에 대한 학습 노력 없이 당장 나온 결과만 보고 따라오려는 사람들을 불편하게 생각하신다면, 그분들도 더 노력해야 할지 모르겠습니다. 기계가 어느 정도 많은 것을 해결해주는 시대가 점점 오고 있다는 것은 분명하니까요.