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

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 연동까지도 더불어 생각하면 선택의 폭이 더욱더 좁아집니다.

R에서 로케일(Locale)을 바꾸는 코드입니다.
R에서 로케일을 지원하는 펑션(function)들이 아직은 많지 않습니다만 datetime을 다루는 것들 중 일부는 따르는 것이 있습니다. – 다른 언어들도 대부분 그렇습니다 –
아래 예제 코드는 OS별로 Locale코드가 다른 문제로 인해 결과물을 다르게 나올 수 있음을 유의하셔야 합니다.
포맷을 바꾸고 싶으면 Locale에 의존하기 보다는 강제로 세팅을 하는 것이 아직은 편할 수 있습니다.
물론 en_US이기 때문에 이렇게 세팅하면 메세지가 영어로 나옵니다.
한글로 바꾸려면 “ko_KR.UTF-8″로 해야 합니다.


sessionInfo()
Sys.getlocale()
Sys.setlocale("LC_TIME", "en_US.UTF-8")
Sys.setlocale("LC_CTYPE", "en_US.UTF-8")
Sys.setlocale("LC_COLLATE", "en_US.UTF-8")
Sys.setlocale("LC_MONETARY", "en_US.UTF-8")
Sys.setlocale("LC_MESSAGES", "en_US.UTF-8")