Share           Pin It

데이터 분석 및 알고리즘 개발을 업으로 하면서 딥러닝 Deep learning은 늘 관심의 대상이었다. 하지만 알고리즘을 실제 구현해보거나 여러 라이브러리를 이용해서 실제 문제에 적용하는 것을 시도하지 않았기에 그런 의미에서 딥러닝에 문외한이라 할 수도 있다. 그럼에도 -- 빅데이터 기술을 어느 순간부터 결국 업에 적용했던 때와 같이 -- 딥러닝 기술도 언젠가는 내가 담당하는 업에 적용해야할 때가 올 것을 알았기에 알고리즘의 기본 지식을 공부하거나 딥러닝 발전의 주요 논문을 빼놓지는 않고 찾아보곤 했다. 딥러닝의 가능성이 일반에 알려지기 시작한 2013년도부터 계속 지켜봐왔기에 딥러닝 전문가는 아니지만 딥러닝의 발전 과정을 어느 정도 꿰뚫고 있다고 생각하기에 어떤 기술들이 현재의 딥러닝을 가능케했는지를 정리해보는 것이 의미가 있을 듯해서 글을 적는다. 일단 MLP 이전의 내용은 생략한다. 그리고 어플리케이션 특화된 기술 -- 예를 들어, Translation의 랭귀지 모델 등 -- 도 생략한다. 

0. 컴퓨팅 파워 (하드웨어)
아래에 여러 알고리즘이나 트릭을 소개하겠지만, 실제 딥러닝을 가능케했던 것은 결국 컴퓨팅 파워의 기하급수적인 증가에 있다고 본다. GPU/TPU로 대변되는 하드웨어의 발전뿐만 아니라, 딥러닝 시대 이전 시대인 빅데이터를 가능케한 그리고/그래서 현재 딥러닝에 무한한 떡밥을 제공하는 클라우드, 즉 값싼 스토리지의 대중화가 결국 딥러닝을 꽃피웠다고 생각한다. 아래에 소개할 다양한 알고리즘이나 대중화된 오픈소스/라이브러리 등의 소프트웨어 이전에 하드웨어 기술을 빼놓고 딥러닝의 성공을 얘기하는 것은 있을 수 없는 일이다.

1. Pre-taining
90년대 말이나 2000년대 초에 나온 오래된 Neural Network 책을 보면 히든 레이어의 수를 늘리면 더 강력해질 거라는 얘기는 계속 해왔다. 하지만 실제 또는 토이 문제를 해결하는 뉴럴넷은 히든레이어가 겨우 1개, 많아봤자 2개를 넘지 않았다. 데이터의 부재와 하드웨어 성능에도 문제가 있었지만 3개 이상의 히든레이어를 가진 네트워크를 제대로 학습시키는 것이 만만치가 않았다. 이론상으로는 완벽해도, 랜덤에서 시작해서 복잡한 네트워크를 최적화시키는 것이 만만치가 않다. 그렇게 뉴럴넷이 잊혀졌지만 프리트레이닝 방식으로 뉴럴넷을 초기화하는 방법이 소개되면서 딥러닝이라는 시대의 조류를 만들어냈다. (데이터와 하드웨어의 발전과 더해서) 대표적으로 정답세트가 필요없는 auto-encoder 방식이 도입되고, RBM이나 DBN을 이론적으로 풀어내면서 뉴럴넷 학습/최적화가 쉬워졌다. 임의의 초기화가 아니라 어느 정도 길들여진 초기화를 통해서 네트워크의 최적화가 엄청 빠르고 쉬워졌다.

2. ReLU (Recified Linear Unit)
전통적인 뉴럴넷은 히든레이어의 액티베이션을 위해서 주로 sigmoid나 tanh 함수를 사용했다. 수학적으로 좋은 성질 (미분 가능)을 갖고 있기 때문이다. 하지만 레이어의 개수가 증가함에 따라서 최종 아웃풋에서 발생한 loss를 앞쪽으로 제대로 전달하지 못하는 gradient vanishing 현상이 발생했다. 네트워크 구조는 엄청 딥하게 만들어놨지만 backprogation에서 가중치의 변동은 최종 1~2개의 레이어에서만 일어나고 앞쪽 레이어는 실질적으로 무용지물이 되는 현상이다. 이를 위해서 마이너스 영역은 0으로, 포지티브 영역은 y=x로 액티베이션하는 ReLU를 적용하면서 이 문제를 해결했다. 최근에는 마이너스 영역으로 무조건 0으로 치환하는 것도 바람직하지 않아서 y = -ax (a << 1.0)하는 것이 낫다는 연구도 있었고, 더 최근에는 y = x * sigmoid(x)로 바꾸면 더 낫다는 논문도 나왔다. (Step 함수의 수학적 불완전성을 보완한 것이 sigmoid 함수이듯이 같은 식으로 ReLU의 미분가능 버전으로 바뀐 것이 x * sigmoid(x)다. continuous & smooth --> 미분가능)

3. Batch Normalization/Re-normalization
뉴럴넷/딥러닝의 성능은 최적화에 좌우된다. 데이터와 알고리즘의 차원이 큰 경우에 최적화는 매우 불안정하다. 그래서 다양한 regularization 방식이 소개됐다. 가장 쉬운 방식으로 가중치의 절대값의 합을 최소화하는 L1이나 제곱의 합을 최소화하는 L2 regularization을 사용한다. 회귀모델에서는 잘 잘동하는데 딥러닝 구조에서는 이 또한 복잡하다. 그래서 초기 딥러닝에서 네트워크를 안정적으로 학습시키기 위해서 drop-out이라는 방식을 이용했다. 즉, 전체 네트워크에서 임의의 일부 노드를 의도적으로 비활성화시켜도 전체 성능이 떨어지지 않게 만드는 방식이다. 그런데 이 방식은 학습속도를 기하급수적으로 늦춘다는 치명적인 단점이 있다. 그러던 중, 히든 레이어의 액티베이션값을 노말라이제이션을 하면 드랑아웃 등의 별도의 레귤라이제이션없이 모델을 안정적으로 학습시킬 수 있다는 실험 결과가 있었고, 현재의 대부분의 네트워크에 이 기법이 기본적으로 적용돼있다. (더 최근에는 작은 규모 또는 non-iid 미니배치에서도 잘 작동하도록 개선한 re-normalization이 소개됨) 딥러닝/뉴럴넷의 기초가 되는 회귀분석 regression에서 모든 독립/종속변수는 Normal 분포를 따른다는 기본 가정이 있는데 (<-- 매우 중요한 속성임), 히든레이어를 노말라이제션하면서 모델을 안정시켜주는 것 같다.
** 사견을 더 하자면 (주제 넘은 얘기지만), 처음 딥러닝을 공부하는 분들은 인터넷에 올라온 동영상 강의 몇 개만 보고 예제 코드 구현/실행해보는 것만으로 마스터할 수 있다고 생각하는 듯한데, 우선 기초적인 것부터 차근차근 공부했으면 합니다. 미적분, 확통, 응선대, 최적화부터 다 공부하라는 것은 아니지만, 적어도 linear regression정도는 마스터하고 딥러닝을 논했으면 합니다. (딥러닝의 첫 강의가 대부분 회귀분석이기는 하지만...) 가끔 커뮤니티에 올라오는 질문을 보고 있자면 이건 딥러닝을 배우겠다는 건지 아니면 그냥 숟가락을 떠서 입에 넣어달라는 건지...

4. LSTM와 ResNet
현재 딥러닝은 데이터의 디멘젼이 무척 큰 (때론 가변적인) 문제에 잘 적용되고 있다. 그런 문제로 자연어/문자열과 이미지 처리가 있다. 처음에는 문자열 데이터에 RNN을 적용하고 이미지 데이터에 CNN을 적용해서 문제를 해결했다. 하지만 문자열이 길어지거나 레이어가 깊어지면서 약점이 발견됐고, 이를 해결하기 위해서 LSTM과 ResNet이 소개됐고 현재는 거의 기본 방식으로 인식된다. (LSTM과 ResNet은 제대로 공부한 것이 아니어서 더 길게 설명하면 틀린 설명만 추가할 듯합니다.ㅠㅠ 알파고 제로 논문에서 ResNet을 사용한 걸 보고 이 글을 적기 시작했는데 역설적이게도 ResNet에 대해서 제일 모름.) 오리지널 인풋이나 이전 과정의 중간결과물을 재활용(?)해서 네트워크를 개선하는 것이 전혀 새로운 아이디어는 아니지만, LSTM과 ResNet은 이 방식으로 딥러닝의 성능 향상 및 여러 애플리케이션에서 성과를 내고 있다.

이상의 알고리즘이나 방법론은 딥러닝을 안정적으로 최적화시키거나 실제 문제에 더 적합한 구조를 만드는 것들에 관한 것인데, 다음은 딥러닝의 대중화에 기여한 것들에 관한 것이다.

5. Word2Vec W2V은 구조가 매우 단순해서 실제 딥러닝과는 거리가 멀지만, (특히) 일반 개발자들 중에서 딥러닝을 처음 접했던 분들이 처음/쉽게 접하면서 딥러닝의 세계로 이끌었다고 해도 관언이 아니다. 몇 년 전에 딥러닝을 한다는 개발자를 만나면 대부분 그저 W2V으로 어떤 문제를 풀고 있는 경우가 많았다. 형태상으로 유사하지만 W2V은 엄밀히 말해서 딥러닝은 아니다. W2V은 잘 알려졌듯이 데이터를 임베딩하는 방식이다. 고차원의 데이터, sparse한 데이터, 또는 비정형 특히 비수치 데이터를 정형의 수치 벡터로 바꿔주는 것을 임베딩이라고 이해하면 된다. 경우에 따라서 효과적인 데이터 차원 축소 방식을 제공하기도 한다. 그리고 이런 임베딩을 통해서 얻어진 수치벡터가 딥러닝의 인풋으로 활용되기 때문에 딥러닝과 무관하다고 말하기도 어렵다. 이후에 Glove 등의 다른 임베딩 방식의 발견에도 기여했다.

6. TensorFlow 2013년에 텐서플로우가 있었다면 제가 직접 다양한 딥러닝 알고리즘을 구현해서 여러 문제에 적용하는 것을 꾸준히 했을 거라는 생각이 든다. 개발에 익숙치 않은 개발자(??)에게 딥러닝의 모든 알고리즘을 직접 구현한다거나 일부 공개된 라이브러리를 제대로 활용하는 것이 쉬운 일이 아니다. 그래서 구현해서 적용해보는 건 포기하고, 그냥 이 동네에 기웃거리면서 어떻게 발전되는지만 지켜보고 있ㄴ...(ㅠㅠ) 텐서플로우 이전에도 Caffe나 Teano, Torch 등의 오픈 딥러닝 라이브러리가 있었지만 이 분야에 익숙한 전문가들을 위한 전유물이었다. 하지만 구글에서 텐서플로우를 오픈하면서 딥러닝이 좀더 일반인(?)에게로 저변이 확대됐다. 결과적으로 인공지능 (딥러닝)이 많은 부분에서 이젠 엔지니어링 분야로 넘어왔다고 봅니다.
(여담) 구글에 텐서플로우를 공개한 것은 하둡이나 하이브 등의 빅데이터 표준에서 밀렸던 과거가 있었기에 가능했다. 실제 맵리듀스나 빅테이블 등의 많은 빅데이터 개념들이 구글에서 나왔지만 그걸 모방한 하둡이 실질적인 표준이 됐다. 씨는 구글이 뿌렸지만 열매는 다른 기업들이 따먹은 것과 같았는데, 같은 실수를 인공지능 분야에서도 반복하지 않기 위해서 텐서플로우를 공개했고, 현재로써는 대중화에 성공했다고 본다.
추가 (2017.10.31) 갑자기 아이디어가 떠올라서 Python + Keras로 텐플을 이용중이다. 케라스 시퀀스 모델에 위에 설명한 개념들을 기계적으로 추가해서 Run하면 그만이다. 속도는 구조와 데이터가 커서 느리지만, 오늘 딥러닝을 처음 접한 사람도 바로 따라할 수 있다. 엔지니어링의 승리다.

7. Reinforcement Learning과 GAN 현재 가장 핫한 분야는 강화학습과 GAN일 거다. 인공지능 기술을 진짜 인공지능이 되도록 만들어주는 기술이라해도 과언이 아니다. 인공지능을 지능이라 부르기 위해서는 알고리즘이 ‘스스로 적응’할 수 있어야할텐데, 강화학습과 GAN이 가능하게 해주고 있다고 본다. 개인 소견으로 딥러닝이 인공지능의 끝은 아니라고 생각하지만, 어쨌든 현재로썬 강화학습과 GAN의 등장으로 딥러닝이 진짜 인공지능답게 만들어지고 있다고 본다.
(여담) 보통 강화학습을 supuervised와 unsupervised와 별개의 새로운 카테고리에 넣어서 설명하는데, 저의 개인적 의견은 강화학습을 supervised 하위에 넣는 게 맞다고 본다. 처음부터 결과를 알고 있는 supervised와는 달리 결과에 따른 리워드 (win/lose, 점수)가 나중에 평가된다는 점이 다소 다르지만 리워드 자체는 일종의 슈퍼바이저라고 보는 게 맞을 듯하다는 생각에서다. (사견이니 무시해도 된다.)

개발자들이 딥러닝을 쉽게 접급하게 해준 것은 Word2Vec, 일반인들이 딥러닝/AI에 관심을 갖게 만든 것은 강화학습을 이용한 AlphaGo (Atari가 먼저지만, 임팩트 면에서), 일반인들이 (그나마) 쉽게 딥러닝을 공부하고 다룰 수 있게 해준 것은 TensorFlow, 우리 실생활의 문제들에 딥러닝이 적용될 수 있게 해준 것은 LSTM (ResNet은 정확도를 높인..), 그리고 딥러닝을 더욱 인공지능처럼 만든 것은 강화학습과 GAN. ... 일런 것을 가능케해준 여러 지속적인 개선들... 뉴턴은 거인의 어깨 위에 섰기 때문에 조금 더 멀리 볼 수 있었다고 말했지만, 거인은 난쟁이들이 쌓아놓은 무수한 모래 성이 있었기에 그 위에 설 수 있었던 것 같다. 최근 10년, 대부분은 최근 3~4년 내에 일어난 사건들... 빠르다. (물론 LSTM과 같이 20년 전에 제안돼서 지금 꽃을 피우는 기술도 있다.)

설명이 부족하거나 일부 틀린 내용이 있을 수도 있습니다. 좀더 면밀히 공부해서 제대로 수정/보강하도록 노력하겠습니다.

이걸 그냥 적당히 슬라이드로 만들어서 전문가인양 모르는 사람들한테 약이나 팔고 다닐까? 하지만 어려운 기술에 대한 연성의 (쉬운이 아닌) 자료는 아무에게도 도움이 되지 않는다는 걸 깨달았습니다. 일부 약장수를 제외하곤...

** 딥러닝이 지금 인공지능을 이끌고 있지만, 인공지능의 미래가 딥러닝에 있다고는 생각지 않습니다.

=== 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
오랫동안 데이터 관련 업무를 해왔지만, 관련된 모든 것을 완벽하게 알고 있는 것은 아니다. 그저 일을 하면서 느낀 의견일 뿐이고, 어쩌면 다른 많은 데이터 분석가들은 동의하지 않을지도 모른다.

많은 일반인들은 데이터는 매우 정확한 것이다라는 인식을 가진 것같다. 특히 일반 개발자들과 일을 하다보면 대략적인 데이터 관련 로직/알고리즘을 스케치해서 알려주면 세세한 부분까지 내가 알려줬던 내용을 그대로 구현하려는 경향이 있다. 데이터 관련 전문성/경험의 부족에 따른 것일 수도 있고, 그냥 시각의 차이일 수도 있다. 데이터 분석의 결과는 매우 정확하고 그것을 반드시 따라야 한다는 생각을 가졌는지도 모른다.

그런데 분석 업무를 하다보면 엄격하게 정확한 데이터에 기반해서 의사를 결정하기도 하지만, 많은 경우 분석가의 감이나 경험에 의존하기도 한다. 해결해야할 문제를 검토하고 관련된 데이터를 수집하다 보면 대강 이렇게 로직을 만들고 이정도의 파라메터를 설정하면 된다는 그런 감 또는 경험치가 있다. 데이터가 보여주는 완벽한 궤적의 함수를 구하기 보다는 그냥 대강 SQRT를 씌우거나 LOG를 취하는 등의 데이터 변형을 시켜서 적용해 본다. 예를들어, scale-free 네트워크에서 빈도는 폭발하기 때문에 그런 종류의 시스템에서 나온 데이터라면 그냥 LOG를 취한다는 거다. 적당히 값을 키우고 싶을 때는 그냥 제곱을 적용해보고 더 급격히 증가하는 걸 원하면 세제곱을 해보기도 한다. 그런 경험치 함수를 적용해서 로직을 개발하는 경우가 많다. 실제 데이터가 그렇게 말해주기 때문에 그런 수식/로직이 나오지 않을 때가 많다는 거다.

대략적인 로직을 정해서 구현할 개발자들에게 알려줄 때, 어떤 변수의 범위가 필요할 때 특정 값을 지정해주는 경우도 있지만 대략 10정도보다 크면 된다라고 말하는 경우가 있다. 사실 11이 좋을지 9가 더 좋을지 나도 모른다. 그냥 안전한 수치를 정하는 것이고, 또 실제 구현해서 테스트하면서 11이 더 좋은 것 같으면 그냥 11로 해도 된다는 의미도 있다. 그런데 최종적으로 구현된 것을 보면 무조건 '10'으로 고정돼있는 걸 본다. 물론 데이터를 보고 값을 정해서 알려주는 것이 내 역할이기는 하지만, 상대방에게 자유도를 주기 위해서 대략적인 걸 말하는데 상대는 그렇지가 않은 것같다. 정확한 스펙과 순서를 요구한다.

아주 미세한 차이가 큰 (역)효과를 내는 분야가 있다. 달에 우주선을 쏘아올리는 경우 0.01도를 잘못 적으면 그 우주선은 우주 미아가 될 수도 있다. 그런데, 현실에서 우리가 만나는 많은 데이터 문제들이 그렇게 세밀하지가 않다. 하루에 '데이터'라는 쿼리가 1000번 들어오는 것과 1001번 들어오는 것은 별로 큰 차이가 없다. 광고 CTR을 0.1%를 올리는 것은 매출에 큰 영향을 준다. 그러나 광고 노출에서 어떤 조건을 10을 두는 것과 10.1 또는 11로 두는 것에 따라서 실제 광고 CTR이 0.1% 이상 차이가 나는 경우가 많지가 않다. (물론 중요한 변수인 경우는 차이를 낼 수도 있고, 여러 변수들이 복합적으로 작용해서 예상치 못한 결과를 줄 수는 있다. 그러나 그렇게 중요한 변수라면 이미 잘 통제되고 있거나 더 정확한 실험 등으로 값을 특정했을 거다.)

그리고 현실에서 정확한 수치가 아닌 것을 원하는 경우가 있다. 예를들어, 최적화 문제/식을 잘 풀었더니 X = 10.56이 나왔다고 치자. 그런데, 원래 문제의 도메인이 정수형이었다면, 즉 Integer program이었다면 10.56은 틀린 답이다. 10이나 11이 돼야 한다. 만약 제고관리나 생산관리 등에서 오늘 하루동안 완성해야하는 자동차의 대수가 100.56대가 나왔다면 100대를 만들고, 나머지 한대는 0.56만큼 미완성품으로 만들어둬야 하는 게 아니다. 이런 경우 하루에 100대를 생산하거나 101대를 생산하라고 명령이 내려져야 한다. (반제품 상태로 나둬도 되는 경우라서 조금 모호하긴 하다.) 최적화 식을 통해서 내일 컴퓨터 8.4대가 필요하다는 값이 나왔다면 당연히 9대를 가져올 거다. 극단적인 예처럼 보이지만, 현실에서는 정확한 수치보다는 그 상황에 맞는 그럴 듯한 수치가 필요한 경우가 많다.

데이터를 다루는 사람들은 늘 직관의 선물을 감사히 받아들여야 한다. (다음 이야기에서 정확한 분야나 숫자는 의미가 없다) 초보 분석가가 며칠동안 고생해서 8.347이라는 해를 구했는데, 상사는 그냥 빈둥거리며 놀다가 한 8.5정도 나오지 않을까?라고 직관적으로 얘기하는데 어렵게 구한 값과 별로 차이가 없었다 등의 풍문이 많다를. 직관/경험이 맞고 데이터가 틀렸다는 얘기가 아니다. 데이터가 주는 정확함에 너무 집착하지 않았으면 한다는 얘기다. 초기의 미세한 차이가 향후에 큰 차이를 만들어낼 수도 있다. 그런 경우라면 중간에 변화의 폭이 커지는 사이에 조정을 해주면 되는 것이지 처음부터 엄격할 필요는 없다. (물론, 중간에 미세 조정이 불가한 경우도 있겠지만...) 그리고 데이터가 정확하다고 믿겠지만, 데이터 내에 부정확함을 내포하기 때문에 데이터가 거짓은 아니지만 진실을 얘기하지 않는 경우도 많다. 어차피 대부분의 분석은 모집단 전체가 아니라 (편향될 수 밖에 없는) 샘플을 사용한다. 빅데이터도 데이터가 많아져서 부정확함을 상쇄시킬 가능성이 높아진 것이지, 데이터 자체의 부정확함은 여전히 존재한다. 그리고 머신러닝에서 사용하는 대부분의 알고리즘도 처음에는 랜덤에서 시작하기도 하고, 같은 데이터로 여러 번 같은 프로그램을 돌려도 다른 결과값을 내주기도 한다. (물론 그런 랜덤성을 최대한 없애고 결과의 일관성을 확보하도록 알고리즘이 발전하고 각종 트릭들이 보완되는 거다.)

부정확함은 어느 곳에든지 존재한다. 그렇기 때문에 데이터는 정확하다는 것은 일종의 미신이다. 처음에는 모호함이 주는 자유를 즐겨라라는 것을 적고 싶었는데, 뒤로 갈수록 뉘앙스가 달라졌다. 개발자들은 데이터 전문가들을 무조건 믿지는 말아야 한다. 엄격한 것이 틀렸을 가능성이 더 높다.

===
B: https://brunch.co.kr/@jejugrapher
M: https://medium.com/jeju-photography
F: https://www.facebook.com/unexperienced

댓글을 달아 주세요

Share           Pin It
데이터마이닝, 빅데이터, 머신러닝 (기계학습), 인공지능 (AI), 딥러닝 등의 용어가 요즘처럼 친숙했던 적은 없었습니다. 이런 용어가 더 이상 학계나 첨단 산업분야에만 머물지 않고, 일반인들도 각종 언론이나 소셜미디어 통해서 자주 접합니다. 많은 회사들의 잡포스팅에도 이런 종류의 지식 및 스킬을 요구하는 것이 더 이상 낯설지도 않습니다. 빅데이터 같은 경우는 조금 마케팅 용어로 사용되는 경향이 있지만, 데이터 및 컴퓨팅 기술이 확실히 다양한 분야에서 임팩트를 주고 있습니다.

이런 용어들의 기저에는 '데이터 기반의 문제 해결'이 내포돼있습니다. 데이터 기반의 문제 해결을 간단한 프로세스로 정형화할 수는 없습니다. 다루는 사람에 따라서, 풀어야하는 문제에 따라서 매번 다릅니다. 이 분야에 오래 일했던 분들도 그냥 늘 하던 대로 또는 감으로 데이터 문제를 해결하지, A - B - C - D... 이런 식으로 스텝바이스텝으로 문제를 해결하는 않습니다. (저만 그런가요?) 그렇다면, 비숙련자들은 더 어렵게 느껴질 것입니다. 그래서, 얼핏 떠오르는 생각으로 데이터 문제에 접근하는 방법/프로세스에 대해서 짧게 글을 적겠습니다.

** 미리 밝히지만, 경우에 따라서 모두 다릅니다.

'데이터 문제 접근'을 크게 다음의 5단계로 정리했습니다.
- 데이터 문제 정의
- 데이터 수집 및 이해
- 데이터 정제 및 가공
- 알고리즘 구현 / 모델 학습
- 테스트

첫번째, '데이터 문제 정의'는 해결해야할 문제가 무엇이고 어떤 데이터로 어떻게 해결할 것인가?를 정의/정리하는 것입니다. 데이터 문제 자체는 외부 (보통 기획자들의 요청?)에서 전달받는 경우가 많지만, 데이터마이너가 직접 정의를 해야할 경우도 있습니다. 해결해야할 문제가 명확히 정의됐다면 그 다음에는 이 문제를 해결하기 위해서 해당 도메인을 이해하고, 필요한 데이터를 정의하고 (데이터 정의), 적당한 해결 방법/알고리즘을 탐색/리뷰해야 합니다. 이 단계에서 데이터나 알고리즘을 확정짓는 것이 아니라, 이런 데이터를 가지고 이런 분석 방법으로 해결하면 될 것같다 정도로 (개념적으로) 정리하면 됩니다. 즉, 어떤 데이터 피쳐가 필요하고 (필요할 것같고), 어떤 데이터 모델을 사용할 것인가 정도를 정하면 됩니다.

두번째는 앞에서 정리한 데이터를 직접 수집하는 것입니다. 기존부터 존재하던 데이터나 로그를 받아오는 경우도 있지만, 새롭게 로그 시스템을 만들어야 하기도 합니다. 중요한 점에 첫번째 단계에서는 개념적으로 필요한 데이터 목록을 정리했기 때문에 그런 데이터가 모두 실제한다는 보장이 없습니다. 특히 기존의 데이터 및 로그를 그대로 활용하는 경우라면 실제 데이터 종류에 맞게 앞서 리뷰한 알고리즘도 함께 수정해야 합니다. 데이터의 수집과 함께, 수집된/되는 데이터가 어떤 형태로 어떤 값을 가지는지 및 서로 간의 상관관계나 연관성 등에 대해서 검토/이해하는 것도 중요합니다. 첫번째 단계에서 A, B, C 데이터가 존재한다는 가정하에 D라는 알고리즘을 생각했다면, 실제 A와 C 데이터만 존재한다면 D' 알고리즘을 수정하는 과정을 거칩니다.

세번째는 수집된 데이터를 분석용 데이터로 정제하고 가공하는 과정입니다. 새롭게 로그 시스템을 만들었다면, 분석 친화적으로 설계했겠지만, 기존의 데이터와 로그를 그대로 사용한다면 구상했던 알고리즘/모델에 그대로 사용할 수 없을 가능성이 높습니다. 예를들어, 수치 데이터를 사용해야하는 모델이라면, 텍스트 형태의 로그를 수치 데이터로 변환시켜줘야 합니다. 인풋 범위가 [0 100]이라고 가정한다면, 100을 넘는 데이터는 모두 강제로 100으로 하향 조정한다거나 다른 정규화 과정을 거쳐서 [0 100]에 맞춰야 합니다. 그리고 상용의 분석 프로그램을 사용한다면 많은 경우 matrix 형태의 데이터로 데이터를 변환시켜줘야 합니다. 실제 많은 데이터 문제의 승패는 입력 데이터를 어떻게 잘 정제/가공했느냐에 달린 경우가 많습니다.

네번째는 가공된 데이터로 실제 알고리즘을 구현하는 단계입니다. 군집이 필요하면 클러스터링을, 분류가 필요하면 클래시피케이션을, 실수값 예측이 필요하면 레그레션을... 등과 같이 적절한 알고리즘을 구현해야 합니다. 기존의 통계 패키지를 사용한다면 문제에 맞는 모델을 피팅/트레이닝하는 과정이기도 합니다. 이 단계에서 단순히 프로토타이핑으로 끝날 수도 있지만, 그렇게 프로토타이핑한 것을 실제 서비스에서 바로 사용할 수도 있습니다. 복잡한 분석 프로그램은 실 서비스를 위해서 리팩토링이 필요하겠지만, 하둡 기반의 구현이라면 프로토타입과 실 서비스가 크게 다르지 않습니다.

마지막으로는 다른 접근법도 그렇듯이 실배포 전 테스트 과정입니다. 요즘은 운용 중 상시 테스트가 기본인 시대지만, 어쨌든 새로운 것을 적용하기에 앞서 테스트를 거쳐야 합니다. 기본적으로 정성 테스트와 정량 테스트가 있습니다. 정성 테스트는 뽑힌 데이터를 눈으로 대략적으로 확인하는 과정이고, 정성정량 테스트는 실제 수치로 효과를 측정하는 것입니다. 정량화를 위해서 과거 로그를 바탕으로 오프라인 테스트를 먼저 거치고, A/B (버킷) 테스트로 온라인에서 확인합니다. 오프라인 테스트는 원래 확인하고 싶었던 항목을 그대로 확인하지 못하는 경우가 많기 때문에, 다른 부가적인 요소를 확인해서 대략 유추하는 경우도 허다합니다.

경우에 따라서 다양하게 접근하지만, 대게 '문제 정의 > 데이터 정의 > 데이터 수집 > 데이터 가공 > 모델 학습 > 테스트' 과정을 거쳐서 데이터 문제에 접근합니다. 앞서 문제 정의 과정에서 어떤 데이터를 어떤 알고리즘으로 분석할 것인지를 미리 정리한다고 적었지만, 이는 숙련자에 해당되는 경우입니다. 데이터 문제에 접근하기 위해서 데이터 마인드가 필요하다고 많이들 조언합니다. 맞는 말입니다. 그런데 실제 데이터 문제를 해결하기 위해서는 '데이터 감'이라는 게 더 필요합니다. 그런 감이 있어야지 어떤 데이터를 수집하고 어떻게 풀어갈 것인지를 바로바로 캐치하고, 문제가 발생하면 다른 대안을 시도해볼 수 있습니다. 그런데 이런 데이터 감이라는 것은 결국 경험에서 나옵니다. 많은 데이터를 보고, 많은 알고리즘을 공부하고 적용해보고, 많은 문제를 해결해가면서 생기는 것입니다. 처음에는 조금 어렵겠지만, 하다 보면 늘어납니다. 이게 누구나 데이터 분석가가 될 수 있는 이유이기도 합니다.

조만간 각 항목별로 필요한 것들은 더 자세히 다루겠습니다.
===
B: https://brunch.co.kr/@jejugrapher
M: https://medium.com/jeju-photography
F: https://www.facebook.com/unexperienced


댓글을 달아 주세요

Share           Pin It
제목은 좀 거창하게 적었지만, 데이터 분석을 편하게 하기 위해서 원본 로그를 어떻게 적제할 것인가?에 대해서 간략히 글을 적으려 합니다. 오래 전부터 적고 싶었지만 기회가 나지 않아서 미루던 것인데, 완벽하지는 않겠지만 떠오르는대로 적겠습니다. 더 필요한 사항은 추후에 업데이트하겠습니다.

새로운 서비스를 오픈하면 다양한 시스템 히스토리나 사용자 사용 이력이 남습니다. 이를 로그 log라고 부릅니다. 그런데 이런 로그들은 대부분 그냥 시스템의 안정성/성능을 측정하거나 단순히 장애가 발생했을 때 어떤 원인으로 발생했는지 등과 같은 1차원적인 기록 및 대응을 위한 경우가 많습니다. 최근 데이터 분석이 주목을 받으면서 원본 데이터, 즉 로그에 대한 관심도 많습니다. 그런데 실상 로그를 분석해보려고 하면 당장 사용하기에 어려운 경우가 많습니다. 정작 필요한 데이터가 없는 경우도 많고, 있더라도 이상한 형태로 존재하거나 찾기가 어렵게 숨겨진 경우가 많습니다. 그래서 서비스를 준비하면서 처음부터 데이터 분석을 고려해서 로그 시스템도 설계할 필요가 있습니다.

데이터 분석에서 70~80%, 떄로는 90% 이상이 데이터를 정의하고 원하는 형태로 가공하는 작업입니다. 그런데 애초에 데이터 분석에 맞는 데이터만 로그에 남기로, 쉽게 읽을 수 있는 형태로 저장해둔다면 불필요한 초기 작업의 상당수를 줄일 수 있고, 데이터 분석이라는 핵심 역량에 더 집중할 수 있습니다.

가장 먼저 고려될 것은 데이터 포맷입니다. 데이터/로그를 남기는 것만으로 충분치 않고, 사람과 컴퓨터가 읽고 이해할 수 있는 형태로 남겨야 합니다. 가장 먼저 고려되는 형태는 단순히 탭으로 구분된 ASCII 문서입니다. 형태도 가장 간단하고 대부분의 분석 도구에서 바로 읽을 수 있기 때문에 가장 편한 포맷입니다. 불필요한 태그도 없기 때문에 적제된 로그 사이즈도 최소화할 수 있습니다. 그러나 한번 정의된 필드가 변경되면 관련된 모든 시스템을 변경해야 합니다. 그런 필드들의 속성 및 순서는 사전에 합의되야 합니다.

그래서 최근에는 XML, JSON, AVRO 등과 같이 태그(속성)과 값을 매핑한 형태의 구조화된 포맷으로 로그를 남기는 경우가 많습니다. 컴퓨터가 태그를 확인해서 필요한 필드를 따로 불러오면 됩니다. 스키마만 잘 정의되있다면 그것에 따라서 자유롭게 데이터를 추가/삭제/변경할 수 있습니다. 그러나 이런 구조화된 데이터를 컴퓨터가 읽기 위해서 별도의 파싱 parsing 프로그램을 구현해야 합니다. 그리고 태그=값 형태의 페어로 데이터가 저장되기 때문에 불필요하게 로그 사이즈가 커질 수도 있습니다. 

요즘 스토리지 사이즈가 문제가 되지도 않고, 다양한 오픈소스로 데이터를 입출력하는 것이 간단하기 때문에 구조화된 형태로 저장하는 경우가 많습니다. 그러나 많은 서비스에서는 여전히 텍스트 문서로 된 로그가 가장 일반적입니다. 대부분의 웹서버로 사용되는 Apache의 로그도 탭 구분 텍스트로 저장되고 있기 때문에, 이 로깅시스템을 개선해서 부가정보를 남기면 됩니다. 그런데 이런 텍스트 로그는 어떻게 남길 것인가?에 대해서도 데이터 분석을 위해서 좀더 고민을 해야 합니다. 그냥 생각나는대로 온갓 정보를 순서대로 정렬해둔다면 서두에서 말했듯이 데이터를 해석하고 필요한 것만 추려내는데 불필요한 수고가 소요됩니다.

데이터 적제의 원칙이라면 ‘중요하고 필수적인 것은 앞쪽에, 덜 중요하고 부가적인 것은 뒤쪽에’ 놓는다로 요약할 수 있습니다. 파일 스트림을 앞쪽부터 읽기 때문에 필요한 데이터까지만 읽은 후에 멈추면 되기 때문에 빈번히 필요한 것은 앞쪽에 두면 불필요하게 뒤쪽의 데이터를 읽을 이유가 없기 때문입니다.

그러면 어떤 것이 중요한 데이터일까요? 몇 가지 생각나는 것을 나열하겠습니다.
  • Identifiable 필드. 보통 데이터/로그가 한 행씩 누적되기 때문에 그 행(데이터)를 식별해줄 수 있는 값이 앞쪽에 오면 좋습니다. 필요한 데이터를 조회하기 위해서 전체 행을 스캔해서 필요한 데이터인지 여부를 확인할 것이 아니라, 앞쪽의 몇몇 필드만 확인해서 맞드면 전체를 불러오면 되기 때문입니다. Identifiable 필드는 예를들어 사용자의 접속 IP도 될 수 있고, 쿠키값이 될 수도 있고, 때로는 접속/로깅 일시가 될 수도 있습니다.
  • Null이 가급적 없는 필드. 로그에 Null값 또는 공백이 포함되면 간혹 문제를 일으키기도 합니다. 예를들어, 프로그래밍 전에 사람이 눈으로 로그를 대강 훑어보는 경우가 많습니다. 그런데 특정 필드의 대부분의 값이 Null/공백인 경우도 종종 있습니다. 그런데, 여기에 공백이 포함됐다는 것을 인지하지 못하고 특정 필드를 생략하고 데이터를 읽어서 다른 속성에 값을 매핑하는 경우도 발생합니다. 그러면 당연히 제대로 된 분석이 이뤄질 수가 없습니다. 가급적 공백이 없는 데이터를 앞쪽에 저장하는 것이 좋겠지만, 어쩔 수 없는 경우에는 — 실수를 방지하기 위해서 — 공백 여부도 별도로 확인가능하도록 해두는 것이 좋습니다.
  • 자주 사용되는 필드. 당연히 분석에서 자주 사용되는 필드가 있다면 앞쪽에 저장하는 것이 좋습니다. 예를들어, 사용자의 성별을 확인하는 작업이 빈번히 일어나는데 이 데이터를 로그의 뒤쪽에 심어둔다면 매번 전체 행을 모두 읽어와야 하는 불편함이 있습니다. 역으로 아주 가끔, 또는 거의 사용하지 않는 필드라면 뒤쪽에 남겨놔도 남겨놔도 관계는 없을 듯합니다.
  • 정형화된 필드. 가급적이면 값이 정형화된 것들이 앞쪽에 있는 것이 좋습니다. 역으로 값 또는 포맷이 정형화되어있지 않다면 뒤쪽에 부가 필드에 기록하는 것이 좋습니다. 검색에서 쿼리 로그로 작업하는 경우가 종종 있습니다. 그런데 간혹 한글 키워드가 깨어졌거나 인코딩이 이상해서 전체 행에 문제가 발생하는 경우가 있습니다. 탭으로 구분된 로그에서 값에 탭 문자가 들어간 경우도 있습니다. 잘못된 필드값 하나 때문에 뒤쪽에 필요한 데이터를 읽어오지 못하는 경우는 가급적 없어야 합니다. 그래서 잘 정형화/정제된 값들이 앞쪽에 놓이는 것이 좋습니다.
  • 값의 형태가 간단하고 짧은 필드. 비슷한 이유로 긴 스트링보다는 숫자나 짧은 단문/단어가 값인 필드가 앞쪽에 놓이는 것이 좋습니다.
  • 시스템에서 자동으로 생성되는 것이라면 가급적 앞쪽에 둬서 불필요한 작업을 줄일 필요도 있습니다. 예를들어, 아파치 로그를 확장한다고 하면 아파치 서버에서 기본 제공되는 필드는 앞에 동일하게 적제하고 나머지 사용자 정의 필드를 뒤쪽에 쌓아두는 것이 여러 모로 맞습니다.

그리고 단순 변환만을 데이터를 추출할 수 있는 경우라면 굳이 중복해서 데이터를 나눠서 저장할 필요는 없을 듯합니다. 예를들어, 일시 ‘2014.11.10.13:14:20’라는 데이터가 있다면 여기서 날짜나 시간은 substring으로 바로 구할 수 있습니다. 그런데 굳이, 일시, 년, 월, 일, 시, 분, 초 등으로 세분화하거나 중복해서 기록할 필요는 없을 듯합니다. 데이터 사용성을 높이기 위해서 더 다양한 데이터를 저장한다고는 하지만, 간단한 변환으로 해결되는 것 때문에 불필요하게 데이터 필드를 늘려서 사이즈를 증가시키고 데이터 포맷만 복잡하게 만들 가능성도 있습니다. 로그 데이터의 포맷에서 KISS, 즉 Keep It Short & Simple 원칙이 적용됩니다.

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


댓글을 달아 주세요

Share           Pin It
3.5 / 5 데이터마이닝/데이터분석및적용의 인트로덕션으로는 좋으나 내 기대는 완전히 충족시키지 못했다.

슈퍼크런처
카테고리 경제/경영
지은이 이언 에어즈 (북하우스, 2009년)
상세보기

   책에 대해서...  
 
 한마디로 표현해서 무조건 전문가의 (오류를 내포한) 직관에만 의존하지 말고, 데이터에서 밝혀진 검증된 결과도 함께 활용하라 정도로 요약할 수 있을 듯하다. 수학이나 데이터 분석에 별관심이 없었거나 비전공자라면 이런 방법이 있구나라고 생각할 수 있겠지만, 사실 책에서 말하는 것은 회귀분석, DOE (Design of Experiments 또는 Experimental Design) 중에서 Random Sample, 좀더 나아가서 신경망 Neural Network, 평균과 표준편차, 그리고 베이지언 확률 정도의 내용만을 다루는 아주 심플하고 간단한 책이다. 나름 데이터마이닝을 담당하고 있는 입장에서 소개된 기법들이 너무 기본적인 것들이라 시시한 면도 있지만, 저자의 분야에서 적용하는 다양한 사례들을 읽으면서 다른 가능성을 발견할 수가 있었다. 법학대학원의 교수로써 저자가 가지는 데이터마이닝의 한계는 충분히 이해가 가능하고, 실제 산업현장에서 회귀분석 및 실험계획 이상의 복잡한 것들은 사용되지 않는다는 측면에서 저자의 한계보다는 현실을 반영한 결과로 볼 수도 있다. 저자의 주요 주장은 전문가의 조건/직감을 무시하라는 것은 절대 아니다. 그것보다는 더 나은 판단을 내기리 위해서 데이터에 반영되어 있는 숨은 그리고 객관적인 규칙을 최종 판단에 포함시켜야 한다는 것이다. 실제 책에서는 데이터 분석이 전문가들의 직관을 이긴 사례들을 들고 있지만, 그 반대의 경우도 많이 있다는 측면에서 전문가의 직관과 데이터 분석결과는 상보적인 관계에 있다. ... 책에 그래프는 몇 개가 나오지만 수식 등은 등장하지 않기 때문에 수학 비전공자/흥미가 없는 이들도 쉽게 읽을 수 있다. 그리고 이런 개론 서적을 통해서 수학에 흥미를 가지는 것도 의미가 있다. 여담이지만, 유명한 과학자의 말인데, 세상에는 세가지 거짓말, 즉 거짓말, 새빨간 거짓말, 그리고 통계가 있다라고 말했다고 한다. 현재의 데이터 분석/슈퍼크런칭은 기본적으로 확률과 통계를 기본으로 하기 때문에 데이터 분석 결과가 모든 것을 말해주지는 않는다. 즉, 거짓 판단을 내리게 만들 수도 있기 때문에 분석된 결과를 실무에 적용하기 전에 까다로운 검증 작업을 거쳐야 한다.

 함께 읽을 책들은... 수학, 확률 및 통계, 그리고 다양한 데이터마이닝 서적들을 읽으면 좋겠지만 전공학생들이 아닌 이상에야 쉽게 다가가기는 힘들 것같다. 

댓글을 달아 주세요

  1. Favicon of http://nandaro.tistory.com BlogIcon nandaro 2009.07.21 00:05 신고 Address Modify/Delete Reply

    "전문가의 직관과 데이터 분석결과는 상보적인 관계에 있다." 공감되는 말이에요~
    머신 러닝에서도 데이터는 항상 부족할 수 밖에 없고, 이를 보완하는 것은
    일종의 휴리스틱(?) 즉, 경험에 의존한 직관이라 할 수 있으니...
    어떤 선택을 할 때, 인간은 항상 과거로부터의 데이터(역사)와
    현재의 판단(혹은 직관)에 의존하는 것도 유사하고 말이죠~ ^^