Share           Pin It

지난 글 '데이터 문제 접근하기'에서 마지막 단계인 테스트가 중요하다고 적었습니다. 테스트와 관련해서 팀내에 공유했던 글이 있어서, 블로그/일반에 맞게 조금 수정해서 올립니다.

===

최근 구글의 데이터 사이언스에서 개설한 Unofficial Google Data Science 블로그에 가장 최근에 올라온 Experiment Design and Modeling for Long-term Studies in Ads의 주요 논문과 이 논문에 엮인 참조논문들을 보면서 (모든 논문을 제대로 읽은 것은 아님^^) (온라인) 테스트를 이해하는 도움글이 필요할 것같아서 간단히 글을 남깁니다.

테스트의 목적이야 새로 추가/개선된 기능이 실제 효과가 있는지를 미리 확인해보는 것입니다. 인터넷 업계에서는 새로운 기능을 모든 사용자들에게 한꺼번에 오픈하는 것이 아니라, 소수의 사용자들에게 먼저 적용해서 반응을 본 후에 전체에 공개하는 것이 일반적입니다. 당연히 반응이 나쁘면 기존 것을 유지하거나 새로운 개선안을 다시 테스트 합니다. 여러 대안이 있다면 그것들 중에서 가장 좋은 것을 선택하는 방법으로 테스트를 진행할 수도 있습니다. 여러 측면에서 테스트를 구분할 수가 있습니다.

오프라인 테스트와 온라인 테스트
오프라인 테스트는 새로운 기능이나 설정값을 실 사용자들에게 보여주고 반응을 추적하지 않고, 기존에 쌓아뒀던 로그 데이터를 이용해서 신규 기능이 적용됐을 때 어떻게 작동하고 어느 정도의 성능을 낼 것인가?를 미리 예측/시뮤레이션해보는 것입니다. 오프라인 테스트의 전제 조건이 충분한 (로그) 데이터입니다. 제대로 된 오프라인 테스트를 위해서 현재 로깅하는 것보다 훨씬 더 많은 데이터를 쌓아놓아야 하는데, 이게 현실적으로 불가능한 경우가 많습니다. 그래서 (정성적으로 확인이 됐다면) 오프라인 테스트를 스킵하는 경우도 종종 발생하고, 원래 봐야하는 평가 지표가 아닌 다른 2차, 3차 지표로 원래 지표를 확인해서 원래 지표를 가늠하는 수준에서 진행되는 경우도 있습니다.

오프라인 테스트가 기존의 데이터를 바탕으로 성능을 유추하는 것이라면, 온라인 테스트는 변경된 기능을 소수의 사용자들에게 실제 노출시켜서 반응을 보는 것입니다. 뒤에서 설명하겠지만 흔히 말하는 버킷테스트나 A/B 테스트가 온라인 테스트를 의미하는 경우가 많습니다. 제한된 사용자지만 실 사용자들의 반응을 확인함으로써 전체 적용 시의 효과를 미리 확인할 수 있습니다. 소수 (보통 5%나 10%)의 제한된 사용자들에게만 변경된 것을 노출시키기 때문에 성능이 더 나쁘더라도 전체의 성능 크게 떨어뜨리지 않는 방법입니다. 

버킷 테스트, A/B 테스트
온라인 테스트를 흔히 버킷 테스트라고 부르는데, 이는 특정 버킷 (선택된 제한된 사용자군)에게만 새로운 기능/설정이 적용되어서 (즉, 나머지 사용자들은 현재 설정대로 노출) 그들의 행동을 확인하기 때문에 버킷 테스트라고 부릅니다. 그리고 A/B 테스트라고도 부르는데, 이는 A그룹과 B그룹으로 나눠서 다른 것을 보여주기 때문입니다. A/B 테스트는 '현재 vs 신규'로 구분하는데, 경우에 따라서 'A, B, C, D...' 등으로 더 많은 그룹으로 세분화해서 동시에 테스트를 진행해서 가장 성능이 좋은 그룹/설정을 선택할 수도 있습니다. 실험에서 A그룹은 대조군 Control 또는 comparison으로 현재 상태를 그대로 적용한 그룹이고, B그룹은 실험군 Experiment로 새로 적용된 기능을 보여주는 그룹입니다.

구글이나 페이스북같이 수천만, 수억명의 사용자가 사용하는 서비스라면 1%미만의 버킷을 설정해도 됩니다. 테스트 버킷이 너무 적으면 결과의 신뢰성이 떨어지고, 너무 크면 실 서비스 지표에 영향을 주기 때문에 늘 그렇듯 적당히 (과학적인 글에서 비과학적인 표현이지만) 정하면 됩니다. 사용자나 PV가 적은 서비스라면 50% 버킷을 정해도 좋고, 아니면 특정 기간 (몇 시간, 하루 ~ 일주일 등)을 정해서 100% 버킷을 정해도 됩니다. 단, 기간으로 버킷을 정할 때는 계절/요일 등의 외부 요소에 의해서 서비스 지표가 달라진다는 점을 염두에 둬야 합니다. 온라인 테스트는 상시 진행되는 것이므로 버킷의 사이즈를 정하는 테스트를 먼저 진행하는 것도 필요할 수도 있습니다.

버킷 구분: 트래픽 기준과 사용자 기준
이런 버킷 또는 B그룹을 선택할 때 트래픽 기준으로 구분할 수도 있고, 사용자 기준으로 구분할 수도 있습니다. 트래픽 기준이라면 현재 들어오는 트래픽 중에 임의로 10%의 트래픽에는 신규 기능을 노출시키는 것입니다. 예를들어, 랜덤함수를 사용해서 0.1보다 작으면 신규 기능을, 0.1보다 크면 기존의 것을 그대로 보여주는 형태입니다. 이렇게 하면 구현 자체는 쉬울 수 있지만, 로그에 A/B그룹을 명시해줘야하는 불편함이 발생하고, 또 모든 사용자들에게 임의로 10%가 노출된다는 점이 장점이면서 단점일 수도 있습니다.

이에 비해서 사용자 기준의 경우, 10%의 사용자를 실험군으로 설정해서 그들에게만 신규 기능을 노출시키는 방법입니다. 보통 사용자 ID나 쿠키 정보를 활용해서 사용자를 구분합니다. ID를 사용하면 좋은 점은 ID가 시간이 변해도 바뀌지 않는다는 점이지만, 모든 사용자가 매번 로그인해서 사용하지 않는다는 단점이 있고, 쿠키 기반의 경우 쿠키가 변경되면 데이터 추적이 불가능하다는 단점이 있습니다. (특별한 경우가 아니면 쿠키가 변경될 가능성은 매우 낮음) 그리고, 사용자 기반의 경우 테스트 기간 동안 실험군을 고정시킬 수도 있고, 특정 주기마다 다른 사용자를 실험군으로 설정할 수도 있습니다. 특히 테스트의 편향성 bias를 체크하기 위해서 (알고리즘이 미적용된 깡통 서비스가 제공되는) 임의 random 버킷을 설정하는 경우가 있는데, 특정 사용자가 항상 임의 그룹에 속하게 되면 그 사용자들에게 늘 나쁜 서비스만 제공되기 때문에, 임의 버킷의 경우 주기적으로 (매시간/매일) 변경해주는 것이 좋습니다.

보통 ID체계를 숫자로 표시했을 때, 'ID mod 버킷수'로 해서 특정 나머지값을 가지는 그룹을 실험군으로 선택합니다. 예를들어, ID가 10153159337581569라면 10153159337581569 % 100하면 나머지가 69이므로, 이 사용자는 69번 버킷에 속하게 됩니다. 10153159337581569 % 10으로 해서 9번 버킷에 속할 수도 있습니다. 이런 식으로 버킷을 구분해서 원하는 비율만큼 실험군으로 정하면 됩니다. %100인 경우, 69번 버킷만 실험군으로 사용하겠다면 실험군은 1%가 되는 것이고, 68번 69번을 사용하겠다면 2%가 되고... 60(6#)번대를 모두 사용하겠다 또는 9로 끝나는 (#9)를 모두 사용하겠다고 하면 10% 버킷이 만들어 집니다. %1000으로 하면 더 세부적인 그룹이 만들어집니다. 그런데, 임의의 버킷을 만들기 위해서 ID체계도 임의적으로 적용돼야 한다는 점은 중요합니다. '1로 끝나는 모든 ID는 남성이고, 2로 끝나면 여성이다' 이런 식의 규칙이 있다면 임의 버킷을 만들 수가 없습니다. 물론, 필요에 따라서 성별, 연령 등을 구분해서 버킷을 만드는 경우도 있습니다.

A/B 테스트를 적용할 때, 트래픽 또는 사용자 기준 외에도 시간 기준으로도 적용할 수가 있습니다. 하루동안 모든 사용자에게 적용하고 롤백한다와 같이 모든 트래픽/사용자가 시간 기준으로' A그룹 - B그룹 (하루) - 다시 A그룹'이 되는 식입니다. 그런데 이건 참 위험한 방법입니다. 특히 B그룹이 적용됐을 때 예상치 못한 외부 효과 때문에 더 좋게/나쁘게 결과가 나올 가능성이 많기 때문입니다. 이런 외부효과에 영향을 받지 않기 위해서 같은 기간 동안 A/B그룹을 나눠서 함께 보고 비교하는 것이 일반적입니다. 보통 A/B 테스트를 진행한 후에 그냥 성능이 더 좋은 쪽 (예를들어, B)이 있으면 모든 사용자에게 그냥 B (신규 기능)을 적용하는 것이 일반적인데, 서두에 소개한 구글 블로그의 논문에서는 A/A - A/B - A/A 과정을 거치는 것을 추천합니다. 뒤쪽에 A/A를 진행하는 이유는 테스트 기간동안 B그룹에 속했던 사용자들이 신규 기능에 학습돼서 테스트 후에도 이상행동을 보이는지를 확인하기 위해서라고 합니다. 예를들어, 새로운 기능 B가 사용자들을 실망시켜서 테스트 기간 이후에 B그룹에 속했던 사용자들이 서비스에서 이탈해버리는 경우도 발생할 수 있습니다. 단기적으로 성능이 좋은 것도 중요하지만, 장기적으로 사용자의 학습에 의한 효과도 같이 보기 위해서라고 합니다. (자세한 것은 첫번째 논문 참고)

테스트에서 중요한 것 중에 하나가 편향성 bias이 없어야 한다는 점입니다. 앞서 말한 임의 ID 체계가 필요한 이유도 편향성을 막기 위한 것입니다. 그리고, 편향성을 막기 위해서 실험계획 Design of Experiment (DOE) 또는 Experimental Design이라는 게 필요한데, 이건 따로 공부하세요.

테스트에서 어쩌면 가장 중요한 것은 평가 지표입니다. IMPRESSION (광고에서 노출을 impression이라고 함)을 높일 것인가? 아니면 CTR을 높일 것인가? 등의 지표가 명확해야 합니다. 그리고, 1차 지표 외에도 다른 2차, 3차 지표도 함께 고려될 필요가 있습니다. 광고의 경우 CTR도 높아야 하지만, CTR이 높아졌다고 해서 전체 수익이 낮아지면 안되는 것과 같이, 실험 전에 1차지표 외에 2, 3차 지표도 함께 고민해야 합니다.

평가지표에서 (예를 들어, CTR) 테스트 기간을 거쳐서 단순히 B의 평균 CTR이 A의 평균 CTR보다 높아고 해서 그냥 B가 더 낫다라고 결론을 내리면 안 됩니다. 분산을 함께 봐야지 평균의 함정에서 벗어날 수 있습니다. A의 CTR이 10%이고, B의 CTR이 11%였는데, A와 B의 CTR분산이 모두 2~3%였다면 사실 A와 B가 다르지 않다라고 봐도 무관합니다. 이때 사용하는 방법이 ANOVA (Analysis of Variance)인데, 실험계획을 공부하면 실제 실험계획보다는 ANOVA를 더 중요하게 다룬다는 불편한 진실이...

ANOVA는 가설검증의 방법으로 주로 사용됩니다. 가설검증이란 귀무가설 (Null Hypothesis 또는 H0, A와 B는 같다)를 검증하는 것입니다. A와 B가 평균은 다르지만, 분산 때문에 신뢰구간 내에서 겹칠 수도 있다면 귀무가설을 기각합니다. 즉, 통계적 유의미성을 판단하는 방법입니다. 엑셀에서 ANOVA를 실행해보면 P-value, F-value 등이 나오는데, 이것들을 보고 통계적 유의미성을 판단합니다. 그런데, '과학적인 방법: 통계적 오류들'에서 설명하듯이 P밸류로 유의성을 판단하는 것이 항상 옳은 것은 아니라고 합니다. (참고 원문)

그리고, 온라인 테스트에서 가장 효과적인 검증을 위해서 수치를 그래프로 비쥬얼라이즈해주는 것이 가장 직관적으로 바로 판단할 수 있습니다. 테스트의 설계에서 비쥬얼라이제이션까지 모두 고려돼야... 숫자보다는 눈으로 보는 게 더 감이 오니까...


댓글을 달아 주세요

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
과학자는 자신이 가진 솔루션을 적용할 문제를 찾고 엔지니어는 자신의 문제를 해결할 솔루션을 찾는다라는 말로 과학(자)과 엔지니어링을 구분한 글을 본 적이 있다. 적절한 구분인 것같다. 데이터 분석/마이닝도 같은 관점에서 구분할 수 있을까? 문제에 맞는 솔루션을 찾는 사람은 데이터 마이너고, 알고리즘에 맞는 문제를 찾는 사람은 데이터 사이언티스트라고 부를 수 있을까? 별로 좋은 구분인 것같지 않다.

최근 빅데이터나 데이터 사이언스 등에 관심이 조금 쏠리고 데이터 기반의 무엇 (Data-driven X)이라는 표현을 자주 접하게 된다. 선무당이 사람잡는다는 말도 있지만, 데이터와 연결된 용어들이 범람하면서 데이터 선무당들도 많이 늘고 있는 것같다. 간혹 지난 몇 년동안 엄청나게 많은 데이터를 모아놓았는데 이걸로 빅데이터 분석할 수 있지 않을까요?라는 류의 질문을 받곤 한다. 가혹 (데이터 분석의 생리를) 알만한 사람들도 비슷한 요청을 한다.

앞서 엔지니어와 과학자를 구분하면서 문제와 솔루션 중 어느 것에 익숙한가로 정했다. 데이터 마이닝이 과학이냐 엔지니어링이냐를 구분하기는 문제와 솔루션이 적당한 측도는 아니지만, 데이터를 접근하는 방식에 대해서는 좋은 설명이 될 것같다. 데이터 마이닝은 문제와 솔루션 사이에 데이터가 존재한다. 데이터가 문제와 솔루션 사이를 연결한다고 봐도 좋다. 그래서 크게, 문제(서비스)에 맞는 데이터를 수집해서 적당한 솔루션을 찾는 방향과 솔루션이 적용될 문제를 찾아서 데이터 인사이트를 얻는 방향이 있을 수 있다. 서비스에 익숙한 사람이라면 나이브하더라도 그것에 맞는 알고리즘을 찾아서 적용해보고 필요하면 더 나은 알고리즘을 찾거나 기존 것을 개선하면 된다. 반대로 알고리즘에 익숙하다면 서비스를 조금씩 이해하가면서 자신의 솔루션을 끼워넣으면 된다. 일반적으로 그렇다는 얘기다.

다른 접근법이 있기는 하다. 주변에서 흔히 접하는 것인데, 가장 이해하기 힘들고 피했으면 하는 접근법이다. 앞서 말했듯이, 우리한테 데이터가 많이 있으니 괜찮은 서비스 하나 만들어볼까요?라는 접근이다. 데이터만 (많이) 있으면 서비스가 하늘에서 뚝 떨어진다는 생각이다. 그래서 많은 경우 데이터 접근법이 실패한다. 모든 것은 컨텍스트 내에서 정의된다. 데이터의 컨텍스트는 서비스다. 유능한 사람은 데이터 더미에서 인사이트를 얻을 수 있겠지만, 나같은 범인은 그러지 못한다. 데이터가 많다고 데이터 기반의 실행이 이뤄지는 것이 아니다.

그리고 이런 경우 데이터가 많기는 한데 데이터 분석에 바로 사용할 수 있는 것도 아니다. 그냥 언젠가 필요할 것같으니 다 모아두자는 식으로 데이터를 쌓아둔 경우가 대부분이다. 물론 많은 회사에서 그런 데이터조차도 관리하고 있지 않지만... 불필요하게 공간만 차지하는 필드들도 많고, 정작 필요한 데이터는 애초에 없는 경우가 많다. 데이터를 분석하고 적용하려면 처음부터 다시 데이터를 모으거나 필요한 형태로 가공해야 한다. 데이터가 잘 정립된 곳에서도 데이터를 가지고 새로운 분석을 하거나 서비스를 만들 때 5할은 데이터 정의/변환에 소요되는데, 그냥 데이터만 쌓아둔 경우라면 9할을 여기에 허비하게 된다. 그러면서 서비스를 이해하게 되는 경우도 발생하지만, 깔끔하지는 않다. 어디에 어떻게 활용할지에 대한 목적없이 데이터를 수집해서 분석가들을 힘들게 만들지 않았으면...

데이터에 맞는 문제, 데이터에 맞는 솔루션은 없다. 데이터가 왕이 아니라, 왕이 될 데이터는 따로 있다.

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


댓글을 달아 주세요

Share           Pin It
사내 게시판에 올린 데이터 마이닝 학습 모임을 위한 글입니다.
모든 데이터는 공개가 원칙이고 마이닝 능력은 보편 지식이 돼야 합니다.

===

모든 법의 존재 목적이 사문화돼 폐기되는 것이듯, 모든 조직의 존재 이유도 더 이상 필요의 이유가 사라지는 것이다. 스스로 파괴해서 증식할 것이냐 아니면 파괴당해서 사라질 것이냐의 차이만 존재할 뿐 현재의 모습과 역할이 변해야 하는 것에는 전혀 변함이 없다. 데이터 또는 그것을 다루는 조직의 운명도 다르지 않다.

데이터는 더 이상 소수의 권력이 되어서는 안 되고, 그것을 읽고 해석하는 능력이 전문성이 되어서도 안 된다. 데이터 기반 조직 Data-driven organization이란 단순히 데이터/수치에 의해서 의사결정을 내리는 조직이 아니라, 구성원 모두가 나름의 데이터를 가지고 분석하고 해석해서 현실 문제에 적용할 수 있는 조직이다. 그런 조직에서 데이터 뿐만 아니라 그것을 읽고 해석하는 능력, 즉 데이터빌러티 Datability는 공공재가 돼야 한다.

데이터빌러티의 공유화를 위해서 최소 1. (모든) 데이터를 수집/처리/배포하는 공개 저장소, 2. 누구나 쉽게 데이터에 접근해서 가공할 수 있는 범용 분석 도구, 그리고 3) 분석 행위 및 분석 결과의 의미를 해석하고 필요에 따라 추가 분석할 수 있는 알고리즘 지식이 필요하다. 하드 플랫폼 (데이터 + 도구)에 대해서는 이미 많은 분들이 고민하고 있고 공개된 것들도 존재하지만, 오히려 소프트 플랫폼 (지식 + 사람)에 대한 고민과 여력은 여전히 부족하다.

모두가 데이터 분석 (마이닝)에 전문가가 될 필요는 없지만 모두가 자신의 영역에서 필요한 최소한의 실험과 검증, 분석은 할 수 있어야 한다. 최소한의 지식과 프랙티스도 없이 데이터나 플랫폼을 가지는 것은 면허없이 운전하는 것보다 — 경우에 따라서 — 더 위험할 수 있다. 최소한의 요구조건을 어떻게 갖출 것인가? 말로써 누군가를 변화시키려는 교육의 기본 전제를 믿지 않으며, 입에서 입으로 전해지지 않고 글로만 남겨진 지식도 죽은 지식이다. 결국 스스로 학습하고 유기적으로 엮이는 조직만이 스스로를 파괴하고 변화에 안티프래질하다.

아직 구체적인 실행 방안을 구상한 것은 아니지만 지금 실행하지 않으면 그만큼 계속 늦어질 수 밖에 없다는 결론에 이른다. 어쨌든 실패하기 위해서 시도는 해봐야 한다. 데이터와 마이닝에 관해서 관심과 수요가 높아졌지만, 이제껏 그런 기대치를 충족시켜준 솔루션도 변변치 않았다. 먼저 나서지 못했던 본인+의 과오이긴 하지만, 그래서 계획을 구체화시키고 실행하기에 앞서 실제 요구사항이나 수요가 어느 정도인지 확인이 필요하다.

데이터와 마이닝에 대한 소규모 학습 모임네트워크를 조직했으면 하는 바람이다. 다양한 백그라운드를 가진 5명 내외의 소규모 학습 모임을 만들면 좋겠다. 필요시에는 개념 설명이나 가이드 정도는 해줄 수도 있으나 일방적인 강의 형식은 취하지 않는다. 비슷한 시작점을 갖는 것도 중요하기에 데이터 관련 팀에 소속된 경우는 가급적 배제하고, 제도권 하에서는 자유를 누릴 수 없다. 모임을 통해서 다양한 데이터 문제에 대한 토의 및 컨설팅도 가능하다. 이런 원칙에 동의하고 동참을 원하는 이들이 여전히 있는지 궁금하다. 일단, 한 두 사이클이 돌고 나면 좀 더 다양한 사람들과 다양한 실험이 가능할 듯하다. 그리고 실험의 최종 목표는 '직접 해보니 별 것 없네'를 증명하는 것이다. 유수의 대학 data science 과목의 syllabus를 확인해봐도 별거 없다는 증거는 이미 많다.

그냥 실험을 해보려 합니다. 성공과 실패를 넘어서 후회하지 않고 책임을 피하기 위해서...

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


댓글을 달아 주세요

Share           Pin It

데이터 마이닝의 좋은 점을 하나 꼽으라면 늘 새롭다는 거다. 새로운 도메인의 새로운 문제를 만나기도 하고, 늘 담당하던 서비스지만 새로운 출처의 데이터나 새로운 종류/포맷의 데이터를 만나기도 하고, 그도 아니면 새로운 알고리즘을 배우고 적용하기도 한다. 파라메터를 새롭게 추가하거나 내용을 변경하는 것만으로도 새로운 경험이 된다. 그래서 현재 업무가 지치거나 지루해지면 새로운 서비스를 담당하거나 새로운 데이터를 공급받거나 새로운 알고리즘을 적용하거나 등의 방법으로 매너리즘을 돌파하는 경우가 많다. 물론 이런 과정이 반복되면 새로운 문제가 전혀 새롭지도 않고 새로운 데이터도 전혀 새롭지도 않고 또 하늘 아래 새로운 알고리즘도 없는 것같은 무력감에 빠지지 않는다는 법도 없다.

어쨌든 데이터 마이닝은 늘 새로운 문제와 접근법/해결책과의 조우다. 그렇기에 새로운 문제 또는 접근법을 수용하기에 앞서 과연 내가 이를 받아들일 것인가를 판단하거나, 적용 후에 결과가 만족스러운가를 평가하는 기준이 필요하다. 밸리데이션 프로세스 validation process나 이벨류에이션 메져 evaluation measure가 필요한 것도 그런 연유에서다. 그러나 이 글에서는 그런 수치적 또는 이론적 메져에 대한 얘기는 아니다.

새로운 문제나 해결책을 맡을 것인가를 판단하거나 그 결과를 평가하는 정성적인 기준이 필요할 것같다. 사람들마다 다양한 기준점이 있겠지만, 나는 MVP (Meaning Value Practice) 이렇게 세가지가 중요하다고 생각한다.

첫번째로 Meaning, 즉 의미가 중요하다. 새로운 문제가 의미가 있는가? 새로운 접근법으로 의미있는 결과를 도출할 수 있는가?에 따라서 판단 및 평가 기준을 삼을 수 있다. 빅데이터라는 말에서처럼 쏟아져나오는 데이터가 전부 노이즈로 가득 찼다면 어떨까? 이런 가비지 데이터에서는 의미있는 결과를 얻을 수가 없다. 아니면 새롭게 복잡한 알고리즘을 배워서 적용해봤는데, 기존에 통밥으로 떼려맞추던 것과 별반 다를 것이 없다면 그 알고리즘은 이 문제에서는 쓸모가 없다. 새로운 파라메터를 추가했는데, 개선효과가 없다면 이 또한 의미없는 헛수고에 불과하다. 여러 경우에도 의미있는 변화를 줄 수 없다면 새로운 문제도 새로운 접근법도 수용하지 않는 것이 좋다. 광물의 흔적도 없는데 금이 있다고 가정하고 굴을 파고 들어갈까?

두번째로는 Value다. 즉, 문제를 해결한 후 결과물이 가치가 있어야 한다. 단지 어려운 문제를 해결했다는 자기만족이 아니라, 뽑혀진 의미있는 결과물을 통해서 개선 효과가 있고, 그래서 그 서비스를 사용하는 사람들에게 가치를 줄 수 있어야 한다. 사용성이 좋아져서 시간을 줄려줬다거나 적절한 상품을 추천해줘서 바로 구입할 수 있게 되었다거나 등과 같은 가시적인 성과, 그리고 이에 따른 새로운 가치를 만들어 낼 수가 있어야 한다. 어렵게 금인줄 알고 캐냈는데 알고 보니 황철석이면 어떤 기분일까?

마지막으로 Practice, 즉 실행에 옮겨져야 한다. 결국 실행이 의미를 가치로 변환시켜주는 과정이다. 사실 내가 학교 쪽에 불만을 가지는 이유 중에 하나가 여기에 있다. 어렵게 연구해서 좋은 알고리즘을 만들어냈는데, 실생활에 적용되지 않는 경우가 많다. 나도 논문을 여러 편 적기는 했지만, 당시에는 그냥 주어진 평가점수만 조금 개선하는 방법을 찾아내면 그걸 마치 대단한 연구인양 논문으로 적었던 것같다. 실험실에서 주어진 토이 문제에서는 좋은 효과를 발휘하지만, 실제 문제에 적용될 수 없는 수많은 연구결과들이 그렇다. 단지 논문을 적기 위해서, 단지 특허를 받기 위해서 만들어진 쓰레기 알고리즘들이 넘쳐난다. 업무에서 새로운 문제를 만났을 때, 그 결과물이 실제 서비스에 적용될 가능성이 없다면 왜 처음부터 머리를 싸매어 그 문제를 해결하려고 노력했어야 하는걸까? 진짜 금이 매장되어있는 것은 밝혀졌는데 너무 깊어서 캐내는데 비용이 더 많이 들어가는 상황이라면 채광을 할까?

의도했던 글의 뉘앙스로 글이 적히지 않았다. 조금 억지스러운 표현이 많이 있다. 데이터 마이닝 뿐만 아니라, 다른 많은 일들에서 MVP의 기준에 따라서 생각, 판단할 수 있을 것같다. 내가 지금 하고 있는 일이 의미가 있는가? 내가 하는 일을 통해서 사회에 새로운 가치를 줄 수 있는가? 지금 하고 있는 일이 제대로 실행, 적용될 수 있는가? 해결책을 위한 문제가 아니라, 실제 우리 삶을 변화시키는 경험을 해보고 싶다면 의미, 가치, 실행에 대한 물음에 긍정적 답변을 얻은 후에 해도 절대 늦지가 않다.

(2013.05.30 작성 / 2013.06.04 공개)

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

댓글을 달아 주세요

Share           Pin It
2005년과 2006년에 열린 IEEE International Conference on Data Mining (ICDM)에서 참가자들을 대상으로 설문조사를 한 것이 있습니다. 설문의 주 내용은 현재 또는 앞으로 데이터마이닝에서 가장 중요하게 다루어질 또는 다루어져야할 문제는 무엇이며, 현재 가장 중요한 또는 영향도가 있는 데이터마이닝 알고리즘은 어떤 것인가에 대한 것입니다. 설문을 바탕으로 10가지 데이터마이닝 문제와 10가지 데이터마이닝 알고리즘을 뽑았습니다. 아래의 각각의 문제 및 알고리즘에 대한 설명을 적기에는 공간도 부족하고, 본인의 능력도 부족하기 때문에 글의 마지막에 제시된 사이트 (특히, pdf 문서)를 참조하세요.

10 Challenging Problems in Data Mining
  • 데이터 마이닝의 통일장 이론 개발 (Developing a unifying theory of data mining)
  • 고차원 데이터 처리 및 빠른 데이터 스트림 처리 (Scaling up for high dimensional data and high speed data streams)
  • 시계열 및 순차 데이터 처리 (Mining sequence data and time series data)
  • 복잡도 데이터/지식 처리 (Mining complex knowledge from complex data)
  • 네트워크 데이터 처리 (Data mining in network setting)
  • 분산처리 데이터 마이닝 (Distributed data mining and mining multi-agent data)
  • 생체 및 환경 데이터 마이닝 (Data mining for biological and environmental problems)
  • 데이터 마이닝 프로세스 (Data-mining-process related problems)
  • 데이터 보안 및 프라이버시 (Security, privacy and data integrity)
  • 동적 고비용 데이터 처리 (Dealing with non-static, unbalanced and cost-sensitive data)
평소에 중요하게 생각했던, 대용량 데이터 처리 (Large-scale data), 시계열 데이터 처리 (Time-series data), 그리고 실시간 데이터 처리 (Real-time application)이 모두 포함되어있습니다. 그리고, 네트워크 문제도 항상 관심을 가지고 고민중이고, 어떻게 대용량 데이터를 분산처리할 것인가를 항상 고민중이었는데 이것들도 모두 포함되어 있네요. 데이터마이닝을 하시는 많은 분들이 공통된 문제를 가지고 고민하고 있음을 확인할 수 있었습니다. 이들의 작은 생각들이 한곳에 제대로 모인다면 엄청난 시너지가 발생할 것같습니다.

10 Most Influential Algorithms in Data Mining
C4.5, k_Means, SVM, EM, PageRank, kNN, Naive Bayes, CART 등은 평소에 조금 알고 있었는데... 제가 아직도 잘 모르는 많은 분야들이 포함되어 있네요. 저의 지식 부족으로 wikipedia나 다른 검색결과를 링크 걸어두었습니다. 나열된 10+8 알고리즘들이 대부분 앞서 기술된 10가지 데이터마이닝 문제들과 많이 연관되어 있습니다. (Graph 기반 알고리즘, assocaition rule 등)

이와 관련된 자세한 내용은 다음의 사이트를 참조하세요.

댓글을 달아 주세요