[et_pb_section][et_pb_row][et_pb_column type=”4_4″][et_pb_text]

트위터에서 만든 OpenKoreanText가 있습니다.

https://openkoreantext.org/

게임 광고에 대한 분석을 하다 보면 종종 재밌는 사실을 알 수 있습니다.

그 중에 재밌는 것은 게임 내에서의 게임 광고입니다.

게임 내에 다른 게임 광고

모바일 게임을 설치해서 하다보면 아이템을 얻거나 다시시도를 하는 댓가로 광고를 보게하는 것이 많다. 광고 수익을 얻기 위한 것인데 게임 광고에서는 유난히 다른 게임의 광고가 많이 나옵니다.

이것은 예전에는 카니발라이제이션이라는 문제라 하지 않았던 것입니다. 즉 다른 게임의 광고를하면 사용자가 그 게임을 설치해서 하게 되고 지금 하는 게임은 하지 않기 때문입니다.

하지만 그럼에도 불구하고 최근 게임광고가 게임에 많이 보이는 이유는 다음과 같습니다.

모바일 게임에서 모바일 게임 광고가 많이 나오는 이유

• 게임은 원래 하던 사람이 하기 때문에
• 이 사람들은 하던 게임이 지루하면 새 게임을 깔아서 할 것이 분명하기 때문에
• 최근 게임들은 쉽게 질리는 것이 많고 게임 유저들이 콘텐츠 소비 속도가 매우 빠른 것이 특징
• 이렇게 해서 클릭 수익을 얻는다면 그게 게임을 계속하게해서 아이템을 판매해서 얻는 것보다 수익이 더 낫기 때문
• 어차피 모든 사용자는 언젠가는 게임을 그만할 것이기 때문에 고객 리텐션을 크게 생각하지 않고 광고를 하게 만드는 전략

※ 현재 설치된 앱은 모바일 사용자의 특성을 나타낸다.

• 게임 앱을 설치해서 게임을 많이 하는 사람은 게임을 또 설치할 가능성이 높다. 따라서 게임 앱에 다른 게임 광고를 하는 것은 매우 효과적이다.
• 이커머스의 버티컬 상품도 마찬가지다. 고기를 판매하고 싶으면 육류 앱이나 신선식품 앱에 광고를 하는 것이 효율이 가장 좋다. 그들은 이미 육류나 신선식품에 대해 매우 관심이 많고 적극적이기 때문이다.

같은 카테고리의 앱에서 같은 카테고리의 상품 광고를 하는 것은 매우 효과적이 수 있다

나이키 의류 앱이 있다면 현실적으로는 어려울 수 있겠지만 여기에서 아디다스나 다른 스포츠웨어 광고를 한다면 매우 클릭율이 높을 수 있습니다.

이런 것을 이용해서 많은 버티컬 이커머스(특정 카테고리만 판매하는 쇼핑몰)나 종합 이커머스에서는 메타 쇼핑이라는 것을 하려고 비즈니스 전환을 많이 하고 있습니다.

즉 메타쇼핑같은 곳에서 어떤 카테고리 또는 여러 카테고리의 상품을 모아서 추천시스템 같은 것을 해서 잘 보여주고 광고를 한다면 일반 광고 매체보다 클릭율과 구매율이 더 높아질 가능성이 매우 큰 것입니다.

이것은 이미 메타쇼핑 또는 버티컬 쇼핑에 자주 접속하는 사용자라면 적극적으로 제품을 구매할 의향이 있다는 것이며 구매에 적극적이기 때문에 정보를 얻기 위해서 클릭에도 적극적입니다.

카니발라이제이션은 어떻게 피하나?

예를 들면 특정 육류 판매 쇼핑 앱에서 타사의 육류 상품을 판매한다면 자사의 육류가 판매되지 않을 것이기 때문에 문제가 됩니다.

이 문제를 해결하는 방법은 매우 간단합니다.
회사를 여러 개 설립해서 만든 후에 브랜드와 상표를 다르게 하고 동일한 육류를 판매하는 것입니다.

일종의 트릭이지만 잘 알려진 예로 음식배달이 있습니다.

음식배달에도 많이 사용하는 방법으로 같은 업소가 여러 음식을 다른 상호로 배달앱에 등록하는 경우입니다. 이렇게 하면 음식업체에서는 전화를 받을 화률이 매우 높아 집니다. 물론 배달앱의 검색에서 상위에 나오게 하기 위해서 광고비, 홍보비가 많이 드는 것은 별개의 문제입니다.

링크 구문 앞에 느낌표!를 붙여주면 할 수 있습니다.
하지만 크기 조정을 하려면 html태그를 직접 사용해야 합니다.

![Github_Logo](./github.png)  

<img src="./github.png" width="100px" height="50px" title="Github_Logo"/>
<img src="./github.png" width="100px" height="50px" title="Github_Logo"></img>

PyCuRL을 설치하다보면 이런 에러가 나올때가 있습니다.

src/pycurl.h:206:13: fatal error: gnutls/gnutls.h: No such file or directory
206 | # include

패키지 의존성문제인데 다음과 같이 합니다. apt나 apt-get을 사용하면 안되고 반드시 aptitude를 쓰세요.

sudo aptitude install libgnutls28-dev libidn2-dev

시계열로 고객의 구매패턴을 확인하려면 많은 드릴다운과 데이터 탐색이 필요합니다. 하지만 간단한 특징으로 몇 가지 중요한 인사이트를 얻을 수도 있습니다.

가장 짧은 계졀단위를 먼저 본다

사람의 계절성(Seasonality) 중 가장 짧은 것은 하루입니다. 하루 다위로 어떻게 행동이 반복되는지 보면됩니다.

데이터 탐색에 의한 인사이트

그래프와 자료를 공유할 수는 없지만 위의 데이터는 다음과 같은 간단한 인사이트가 있습니다.

• 가장 인터넷서핑이 활발한 시간은 10시 ~ 11시, 13시 ~ 18시, 20시 ~ 23시입니다.
• 구매는 보통 오전 9시경 ~ 10시경, 오후 7시에 새벽 13시까지에 가장 많이 발생한다.

1일 일과의 사용자들의 웹서핑 패턴과 구매 패턴을 분석하면 광고클릭모델이나 광고전환모델을 만들 때 매우 유용한 특성, 자질(feature)에 대한 힌트를 얻을 수도 있습니다.

데이터 설명

우선 위의 그림은 2022년 9월의 추석연휴를 전후로 7일간의 인터넷 사용자들의 여러 웹사이트에서 발생한 웹사이트의 페이지뷰 중의 일부 트래픽의 패턴입니다. PC와 Mobile을 모두 포함한 것인데 모바일과 PC는 양상이 조금 다르긴 합니다.

웹사이트 페이지뷰와 사용자 구매패턴과의 상관관계

여기서 말하는 웹사이트는 뉴스, 신문, 커뮤니티, 각종 블로그를 말하고 인터넷 사용자는 매체를 돌아다니며 콘텐츠를 섭취하는 사람들을 말합니다. 이 사람들은 이런 매체들을 돌아다니가 어느 시점에 광고를 클릭하거나 또는 직접 쇼핑몰에 직접접속해서 물건을 보고 구매를 합니다.

웹사이트 페이지뷰와 사용자들의 구매 패턴과는 상관관계가 있을까? 하는 궁금증이 생길 것입니다.

단순한 아이디어로는 “어느 시간대에 광고를 보여주면 물건을 살까?” 같은 것이 있습니다.

인터넷서핑이 활발한 시간은 직장인들의 출퇴근 시간과 직장내에서의 행동패턴과 관련이 있습니다. 출근 후 앉아서 시간을 때우고 싶어지는 시간대입니다.

구매는 이것과는 다른데 구매는 정신이 또렷하고 바쁘지 않으면서 올바른 판단을 할 수 있는 시간대입니다. 이 시간대에는 구매하려고 봐 두었던 물건의 구매를 확정하거나 가격대 또는 유형이 비슷한 물건을 찾아다니는 특성이 있습니다.

그외에 소소한 인사이트로는

• PC사용자에 비해 모바일 사용자는 새벽시간대의 트래픽이 조금 더 많다.

위의 이유로 추정할 수 있는 것은

PC나 데스크탑은 누워서 쓰거나 할 수 없지만 모바일은 편안하게 누워서 새벽까지 사용가능하기 때문입니다. 이 시간대에 사용자들이 소비하는 컨텐츠는 게임, 웹툰, 소설, 틱톡, 유튜브 같은 엔터테인먼트가 많습니다.

fluentd는 데이터 인제스쳔(Data ingestion) 레이어를 구성하는데 매우 유용한 도구입니다.

fluentd를 microk8s로 구성하는 방법입니다.

우분투(Ubuntu)에 microk8s 설치하기

microk8s는 snap으로 설치해야 합니다.

그래서 snap이 없는 우분투 구버전은 먼저 snap부터 설치합니다. 최근 우분투에는 snap이 기본 설치되어 있습니다.

snap설치

sudo apt-get install snapd

microk8s 설치

sudo snap install microk8s –classic

helm3 활성화

계정을 root로 전환합니다. 일반 사용자로 해도 되지만 몇 가지 선행작업이 있어서 조금 귀찮습니다. 여기서는 그냥 root로 하겠습니다.

sudo su –
microk8s enable helm3
microk8s helm3 init

init을 하면 이런 에러가 발생할수도 있습니다.

Adding stable repo with URL: https://kubernetes-charts.storage.googleapis.com
Error: error initializing: Looks like “https://kubernetes-charts.storage.googleapis.com” is not a valid chart repository or cannot be reached: Failed to fetch https://kubernetes-charts.storage.googleapis.com/index.yaml : 403 Forbidden

이럴 때는 다음과 같이 해결합니다.

해결법

Use the –stable-repo-url argument to specify the new repository:

helm init –stable-repo-url https://charts.helm.sh/stable –service-account tiller
Use the –skip-refresh argument and replace the stable repo:

해결법 실행명령

helm init –client-only –skip-refresh
helm repo rm stable
helm repo add stable https://charts.helm.sh/stable
Upgrade helm to 2.17.0 or later.

이제 fluentd의 helm 레파지토리를 추가합니다.

fluentd helm 레파지토리 추가

microk8s helm3 repo add fluent https://fluent.github.io/helm-charts
microk8s helm3 repo update

fluentd 설치

fluentd를 설치합니다.

microk8s helm3 install fluentd fluent/fluentd

fleuntd의 기본 values를 봅니다.

microk8s helm3 show values fluent/fluentd

fluend가 실행되어 있는지 서비스 확인

root@pr-01:~# microk8s kubectl get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
Kubernetes ClusterIP 10.152.183.1 443/TCP 3h16m
fluentd ClusterIP 10.152.183.249 24231/TCP 26m

A/B 테스트를 한다고 하지만 정작 테스트 결과를 왜곡해서 해석하거나 자기가 해석하고 싶은대로 해석하는 경우가 많습니다. 오늘은 온라인 서비스에서 하는 A/B테스트에 대한 불편한 사실에 대해서 얘기해 보겠습니다.

A/B테스트의 개념을 제대로 알자

A/B 테스트는 통계학의 실험계획법의 하나입니다. 역사가 오래된 과학적 실험 및 결과 확인 방법입니다. A/B테스트는 의료과학에서 정말 많이하는데 신약, 수술법, 처치법에 대한 테스트를 하기위해서 하고 온라인 서비스에서 UI의 변경이나 기능변경을 할 때 어떤 것이 좋은지 확인할 때도 씁니다.

실험대상을 A군과 B군으로 나누고 B군에 벼환를 주고 그 결과의 차이를 비교한다는 의미해서 A/B 테스트라고 부릅니다.

간단하게 정리하면

아무 처치도 하지 않은 콘트롤 그룹(Control Group, A)과
어떤 처치를 한 테스트 그룹(Threatment Group B)을 두고

• Control Group 콘트롤그룹: 아무 처치도 하지 않은 것
• Treatment Group 트리트먼트 테스트 그룹: 어떤 특정한 처치를 한 것

이때 Threatment group은 여러개가 있을 수 있습니다. T1, T2, T3이렇게 번호를 붙여서 여러가지 다른 처치를 하게 할 수도 있습니다. 온라인 서비스의 UI라면 UI1, UI2, UI3과 같이 새 UI를 한 번에 테스트해볼 수 있습니다.

콘트롤 그룹과 테스트 그룹의 샘플 수는 같아야 한다

콘트롤 그룹과 트리트먼트 그룹의 샘플 수는 같아야 합니다.
만약 사용자를 대상으로 하는 UI 버킷테스트라면 적용 받는 사용자는 동일하게 분할해야 합니다.

정확히 샘플 수가 같을 필요는 없고 카이스퀘어 테스트를 해서 균둥하다고 나올 정도면 됩니다.

최소한 시즌이 두 번은 반복될 수 있는 기간 동안 진행한다

여기서 말하는시즌은 온라인 서비스의 경우에는 2주를 말합니다. 월별로 특성을 타는 테스트라면 2개월은 돌려야합니다. 시즌을 2번 돌리게 하는 것은 시즌내에서는 특정 시점에 따라 기복이 있을 수 있고 잠시 튀는 경우가 생기기 때문입니다. 그리고 행위나 반응에 대한 샘플 수를 늘리기 위한 것입니다.

여기서 “하루 또는 1시간만하고 테스트 결과가 좋으니 테스트가 더 좋다”라고 판단하는 분들이 많은데 이게 좀 문제입니다. 과학적으로 보면 이건 사기나 마찬가지입니다.

어째서 1시간만 해도 되는지 1일만 해도 되는지 그게 괜찮은지에 대한 근거가 전혀 없습니다. 보통 왜 그 기간동안 하느냐라고 물으면 “그 정도면 충분하지 않을까요?” 라고 말합니다.

매우 비과학적인 사고여서 통계학에서 절대 하지 말아야 할 행위로 규정하고 있는 것입니다.
저렇게 하는 이유는 어떤 테스트 방법으로 어떻게 평가해야 하는지 모르기 때문입니다.

어떤 평가 방법을 써야 하는가?

A/B테스트는 실험을 시작하고 시간이 경과한 후 또는 어떤 처치를 한 후에 두 그룹의 차이가 있는지 없는지, 어떤 것이 더 좋은지를 확인하는 것입니다.

검정법

진행 후에 결과에 대한 검증법은 통계적 검정법을 쓰는데 통계적 검정법은 간단하게는 t-test부터 F-test 등 매우 많습니다. 샘플 수, 상황, 데이터의 분포에 따라 어떤 평가방법을 써야 하는지 각각 다르므로 어떤 평가방법을 써야하는지는 잘 알고 있어야 합니다.

T-test면 다되나?

평균의 유의미한 차이는 T-test를 하면 되고 원래 두 그룹의 평균차이가 달랐다면 부산분석을 통해 분산이 차이가 발생했는지 유의미한지를 확인해야합니다.

CTR이 좋아졌는지 보려면?

예를들어 테스트그룹1이 콘트롤그룹보다 CTR이 좋은지 보려면 2주간 버킷테스를 진행하고 CTR에 대한 T-test를 수행하면됩니다. 이때 CTR의 분포가 정규분포에 가까워야 합니다.

CTR은 하루 또는 전체 기간의 CTR을 계산하는 것이 통상적인데 페이지뷰는 있지만 CTR이 없는 경우에는 CTR이 계산이 안되는 것들은 버리고 불균등한 샘플의 숫자는 많은쪽에서 일부 줄여서 버려야 합니다.

의료과학에서의 A/B테스트

의료과학에서는 실험 대상의 샘플도 적고 콘트롤이 잘 안되고 관찰도 잘 안되는 문제 때문에 매우 어렵습니다. 온라인의 경우에는 콘트롤이 잘되고 샘플도 많습니다만 정작 실험 후에는 판단을 엉망으로 해서 잘못된 판단을 하는 것이 문제지만 의료과학은 케이스가 그때그때 다들 다르다는 문제가 있습니다. 그래서 그때 그때 방법을 선택해서 검정을 해야 합니다. 케이스별로 잘 알려진 통계적 검정법이 있는데 어떤 것을 써야 할지 애매할 때가 많습니다. 이런 경우에는 의료통계 전문가에게 물어봐야 합니다.

의료과학은 결과에 대한 검증이 매우 예민하고 철저하기 때문에 잘 해야하는데 사용해야 합니다. R언어를 사용하는 분들은 논문이 이미 R언어를 사용해서 실험을 평가한 것이 많으므로 관련 논문을 참조하거나 커뮤니티에 물어보면 어떤 테스트를 써야하는지 잘 알려주니 적극 활용할 필요가 있습니다. 미국의 유명한 의료과학 대학과 제약회사들은 모두 R언어를 기본으로 사용합니다.

그래서…

A/B테스트는 버킷을 분리해서 서로 다른 효과를 적용하게 만드는 시스템을 만드는 것이 가장 어렵습니다.

하지만 버킷테스트를 진행하고 나서 실험결과에 대한 올바른 과학적 해석과 그 논리적 결함, 통계적 해석 왜곡에 대한 검증도 매우 중요합니다.

테스트를 진행하고 단편적인 결과만 보거나 자신에게 유리한 것만 본다면 실패한 실험이 되므로 매우 주의해야 합니다.

의료과학에서 얼마나 철저하게 검증하는지 안다면 A/B테스트가 만만하지 않다는 것을 알 수 있습니다. 물론 온라인 서비스의 버킷테스트는 의료과학과는 달리 사람의 생명에 직접적연 영향을 주지 않을

만약 실험 결과에 대한 해석과 검정을 어떻게 하는지 모른다면 아예 하지 않는 것이 오히려 좋습니다.

A/B테스트를 진행하고 나서 그 결과가 믿을 만한 것인지 알고 싶다면 통계학의 가설검정법에 대해 공부해야 합니다.

데이터 기반으로 의사결정을 하는 것은 이미 전세계적으로 당연히 해야 할 것으로 다를 인지하고 있습니다.

하지만 많은 한국회사들은 빅데이터, 데이터과학, 디지털트랜스포메이션을 도입해서 데이터기반 의사결정을 하려고하지만 대부분 실패를 맛보고 예전에 하던 경험기반의 주먹구구식 의사결정을 합니다.

데이터 기반 의사결정이 실패하는 대부분의 이유는 데이터 과학이 사기이거나 데이터 과학자의 역량 부족이나 실패보다는 경영자나 관리자 또는 조직원들의 문제인 경우가 대부분입니다.

즉 실행을 하는 사람들의 인식과 사고와 이해 관계의 문제입니다.

사람의 문제가 대부분입니다.

많은 한국회사들이 지난 십 수년동안 데이터 기반 의사결정을 하기 위한 시도를 했지만 제대로 한 곳은 거의 없습니다. 많은 회사들의 데이터 책임자, 실무자, 의사결정권자들과 얘기하거나 하다보면 처음에는 데이터 기반 의사결정이 꼭 필요하며 꼭 하고 싶다는 말과 함께 시작하지만 대부분 실패하게 됩니다.

여기에는 회사들 마다 나름대로 원인과 이유가 있겠지만 공통적으로 보이는 어이없는 원인들도 있습니다.

우선 조직내에서 수직적 레벨로 어느 위치에 있는지에 따른 문제점들입니다.

결정권자들의 문제 (탑 레벨의 문제)

결정권자들의 경우입니다. 이 경우가 문제가 가장 많습니다. 전후가 어쨌든 의사결정을 하는 최종 결정권자들이기 때문입니다.

보통 조직(회사)내에서는 결정권자들이 데이터기반 의사결정에 대해 무지하거나 잘못된 결정을 하는 것에 대해서 아무도 지적하거나 언급하지 않습니다. 이런 걸 잘못해서 결정권자의 귀에 그런 의견을 말한 사실이 알려지면 속된말로 찍혀서 인사상 불이익을 받거나 하는 문제에 휘말릴 수 있기 때문입니다. 사회생활 잘하고 싶은 것입니다.

필자가 듣거나 경험해 본 결정권자들의 문제는 여러가지 케이스로 나타납니다.

데이터기반 의사걸정을 하는 모양새만 갖추고 싶어한다

원래부터 데이터 기반 의사결정은 할 생각이 없거나 그게 뭔지 본질은 관심이 없는 케이스입니다. 본인이 데이터 기반 의사결정을 하는 합리적이고 선진화된 사람으로 각색되어 보여주길 원하는 것이고 실상 결정을 할 때는 자기가 하고싶은대로 해버립니다.

“데이터로 파악한다고 다 아는 것도 아니고 다 맞는 것도 아니잖아?” 이렇게 생각하거나 말하는 경우도 매우 많습니다.

데이터기반 의사결정 필요성을 아예 모르는 경우도 많습니다. 그냥 남들이 그걸 한다고 하고 그걸 하면 괜찮은 의사결정권자로 보일 것 같으니 그게 포장용으로 필요할 뿐입니다.

“나는 데이터기반 의사결정을 할 줄 아는 선진적이고 진보된 사람이야.” 라는 말을 하며 그런 사람으로 알려지길 바라지만 실제로 행동은 그렇게 하지 않는 것입니다.

수단과 목적이 바뀐 것입니다. 의사결정을 잘하기 위한 것이 목적이고 데이터기반 의사결정은 그걸 하기 위한 방법 중 하나입니다. 그런데 데이터 기반 의사결정을 한다는 것만 보여주고 싶은 것이 목적이고 그 수단으로 그걸 한다는 포장만 하는 것입니다.

안타깝게도 어떤 기업이든지 이런 사람이 거의 필연적으로 그리도 다수 존재합니다.

보고 싶은 것만 본다

데이터 기반의 분석결과는 그 분석이 틀리지 않고 맞다는 전제하라면 좋은 결과가 나올 수도 있고 안좋은 결과가 있을 수도 있고 세부적으로는 좋고 나쁨이 섞여 있을 수 있습니다.

이 중에서 자기가 보고 싶은 것만 봅니다. 그러니까 자기가 하고 싶은 것을지지하는 결과만을 선택하고 그게 아닌 결과는 무시해 버립니다.

이렇게 할꺼면 데이터를 확인할 필요가 없습니다. 그냥 자기가 하고 싶은 대로 하면 됩니다. 하지만 그렇게하면 비론리적이라는 말을 듣기 때문에 논리적이라는 말을 듣기 위한 포장용으로 자신에게 유리한 결가만 필요한 것입니다.

어떤 실험, 사실 탐색, 인사이트 도출과 같은 것은 보통 좋은 사실과 나쁜 사실이 뒤섞여 나오는경우가 많습니다. 대표적인 실수는 여기에서 자신이 원하는 결과에 유리한 것만 채택하고 나머지는 별거 아니라고 무시해 버리는 것은 가장 경계해야 할 것이고 그렇게 하지 않는 것은 도덕적으로 문제가 있는 것입니다.

데이터를 보긴 하지만 결정 자체를 안한다

의사결정이란 시의적절하게 해야 합니다. 즉 할 때는 해야 하는데 무조건 의사결정을 안합니다. 데이터를 보는 이유는 사람의 경험에 의한 의사결정이 왜곡이 많거나 틀릴 위험이 많기 때문에 최대한 현실을 제대로 보고 참고해서 결정을 하기 위한 것입니다.

결정을 안 하는 결정권자는 데이터 기반이든 아니든 문제가 매우 많습니다.

이런 결정권자가 있는 회사는 서서히 망합니다.

다행인 것은 당장 망하지는 않습니다. 하지만 더 불행인 것은 이런 회사는 반드시 망합니다.

매니지먼트 레벨들의 문제

본부장, 센터장, 사업장, 유닛장, 팀장 등과 같은 상위 또는 중간 매니저들의 문제입니다.

이런 사람들도 데이터기반 의사결정에 문제를 만드는 경우가 많습니다. 사실 문제를 가장 많이 만드는 사람들은 이 사람들입니다.

위에서 하라고 시키니까 하는 척만 한다

위에서 “데이터 기반으로 의사결정” 하자고 탑다운으로 지시가 내려온 경우입니다. 그게 뭔지도 모르겠고 인터넷 검색을 하고 업체를 찾아서 하는 시늉을 합니다.

그러고나서 “이거 잘 안되는거네. 거봐 사기라니깐” 이렇게 말합니다.

원래부터 하고 싶은 생각이 없었던 것입니다.

뭔지, 왜 해야하는지 학습할 생각은 없습니다. 뭔지 다 이해했지만 본인이 충분히 잘하기 때문에 그런 it인력이나 솔루션 업체들 돈이나 퍼주는 그런 것은 낭비라고 생각하는 것입니다.

부하직원에게 말해도 무슨 말인지 알아듣지 못한다

데이터 기반을 왜 해야하는지 같이 일을 해야 할 팀 동룝 또는 부하직원들이 이해를 못하는 경우입니다. 혼자 데이터 추출하고 데이터 검증을 하거나 데이터 관련 부서로부터 협조를 받아야 하지만 그렇게 하지 못하는 경우도 많습니다.

데이터 기반 의사결정에 필요한 기술이 없다

태블로 같은 BI도구를 사거나 하둡, 스파크, 빅쿼리, GCP같은 것을 써서 카운트를 세고 그래프를 예쁘게 그리고 나서 의사결정을 하면 데이터기반 의사결정이라고 생각해버립니다.

데이터를 집계하고 시각화하는 것이 데이터 기반 의사결정을 하기 위한 출발점이긴하지만 데이터 기반 의사결정은 그런 그래프와 데이터를 보고 여러가지 고민과 생각과 탐색을 해서 결론을 내는 것입니다. 즉 데이터를 제대로 집계하거나 추출, 가공하고 시각화한 데이터 요약을 해석 하는 방법을 터득해야 합니다. 그런데 그 방법은 익히기 매우 어려운 기술이고 잘 정리된 튜토리얼이 없습니다.

그래서 본인이 잘하고 있다고 착각하기 쉽지만 실상은 아닌 경우가 많습니다.

실무자들의 문제

마지막으로 실무자들의 문제가 있습니다. 즉 데이터 과학자, 데이터 분석가가 아닌 사람들입니다.

대부분의 실무자들은 데이터기반의 어쩌고 하는 것에 대해 기본적인 거부감을 가지고 있습니다.

뭔지 잘 모를말로 자신들보다 지적, 과학적으로 우위에 있다는 것을 과대포장하기 위해 데이터기반이라는 것을 만들어냈다고 생각하는 것입니다.

“실제로 해보니 안되드라”

데이터분석을 하고 인사이트 도출을 위한 미팅을 하기 위해서 초기 셋업 미팅을 하면 이런 피드백을 꽤 많이 합니다.

그리고 이런 상황에서 시작하는 프로젝트는 실상을 보면 애초에 협조하거나 잘되길 바라지 않고 방해하는 일이 허다합니다.

데이터기반으로 의사결정을 하게 되면 경험기반의 자신들의 노하우가 쓸모가 없어지는 것 같고 컴퓨터에게 자신들의 일자리를 잃어버릴 것 같은 느낌 때문입니다.

즉 애초레 제대로 할 생각도 없었고 잘 안되길 바라고 그렇게 되도록 행동한 것입니다.

“내가 진짜로 여러 번 같이 해봤는데 그거 현실성이 없더라니깐”

이렇게 말하는 사람들도 다수입니다.

앞서 말했듯이 제대로 안해봤거나 사실은 여러번 안해본 것입니다.

반약 데이터기반 의사결정이라는 것이 말만 그럴듯하고 정말로 안되는 거라면 데이터기반 의사결정은 꼭 필요한 것이며 많은 실수를 바로잡았다고 말해온 실리콘벨리의 선진적인 회사들은 모두 단체로 거짓말과 사기를 치고 있는 것입니다.