by
Dec 01. 2022
현장에서 데이터 분석이 어려운 이유
오랜만에 글을 올립니다.
변명을 하자면 작년에 진행했던 모 수입차 브랜드 프로젝트의 진행 건과 개인적인 실생활로 인해 바빴습니다.
프로젝트 내용은 회사의 주요업무 기밀이니 따로 자료를 올리거나 상세히 언급할 수는 없지만
결과적으로 파트너사로 선정되어 PoC 이후 Proposal이 성사되었다는 건만 말씀 드릴 수 있겠네요.
제안한 프로젝트는 고객 상담 데이터 시각화 및 머신러닝 프로젝트로 업무 협의에만 반년이 넘게 걸렸는데요,
(외국계라 기업 내부의 프로세스 상 많은 단계를 거쳐야 하는 점은 이해가 됩니다.)
전 기획 및 PM을 맡아 데이터사이언티스트로서 프로젝트를 이끌어갔고 디자인, 퍼블리싱, 개발 및 데이터 분석은 각자 팀원이 맡거나 외주를 주는 방식으로 진행했습니다.
빅클라이언트와의 첫 데이터 분석 프로젝트 계약 성사라는 쾌거를 이루었지만
한편으로 뒤돌아보면 어떻게 그동안 견딜 수 있었나 생각할 정도로 힘든 순간이 곳곳에 있었습니다.
교육생일 땐 데이터는 주어지고 분석만 하면 되었습니다.
하지만 현장에서 막상 데이터 분석을 하려니 지식, 기술 등의 분석 자체의 어려움보다 다른 현실적인 문제에 부딪치게 되더라고요.
현장에서의 데이터 분석의 어려움은 뭘까?
나는 분석만 하면 될줄 알았지, 차라리 기술이 어려웠다면...1. 데이터를 늦게 전달 받아 시간이 부족했던 이슈
1차 Proposal이 통과되고 그 다음 단계는 PoC (기술검증) 단계를 거쳐서 실제 결과물을 만들어 낸 뒤 데모데이에 발표를 하는 것이었습니다. 발표 후 최종 파트너사로 선정되느냐 마느냐는 그 다음 일이었죠.
앱을 만드는 분야도 있었고 다른 여러 분야가 있었지만 저희가 지원한 부문은 business intelligence 분야로 마케팅 부서의 입맛에 맞는 데이터 분석 아이디어가 필요했었죠.
다행히 제안한 아이디어의 반응은 좋았지만 문제는 시간이었습니다. PoC를 발표하는 날(데모데이)까지 남은 기간은 겨우 두달이었으니까요.
요리에 식재료가 없으면 안되듯이 분석을 하려면 가장 먼저 필요한 것은 데이터입니다.
그런데 그 재료 공급부터가 수월하지 않았습니다. 실제로 고객사로부터 데이터를 받게 된 시점은 발표일로부터 약 3주 전이었죠.
아무리 고객사가 데이터를 늦게 넘겨주는 일이 빈번하다고는 하지만
총 2개월 기간 중 실제로 분석할 시간이 3주밖에 되지 않았다는 건 상당히 크리티컬한 일이었습니다.
분석을 통해 인사이트를 도출하고 개발을 동시에 진행해야 하는 점과
커뮤니케이션 비용으로 인해 분석과 개발에 투자할 시간이 절대적으로 부족했던 것이 사실이었습니다.
물론 고객사에게도 사정은 있었습니다. 담당자님께 데이터를 언제 받을 수 있는지 요청할 때마다 무척이나 미안해하면서 조금만 더 기다려달라고 답변주셨거든요.
가장 큰 이유로는 아무리 협업이라고 하지만 외부에 내부 고객의 데이터를 줘야만 하는 이점이 있냐는 고객 정보 유출에 대해 민감한 이슈가 있었던 것 같습니다.
우여곡절 끝에 프로젝트 종료 후 데이터 파기를 조건으로 데이터를 전달받기로 결정되었지만
NDA와 DPA 같은 협약을 체결 후에 데이터를 보내야 하는 방침 때문에 데이터를 전달받기로 한 시점은 더더욱 늦어졌죠.
게다가 첫번째로 제안한 프로젝트는 고객 상담 데이터를 대시보드로 시각화하는 프로젝트였습니다.
고객과의 통화 음성을 text로 변환해야만 했습니다.
예? 3주만에 STT 솔루션까지 사용해야 한다고요?다행히 고객사는 시간이 부족하다는 사실을 정확히 인지하였습니다. 사전에 상담사들이 정리해놓은 text 데이터를 분석하는 것으로 넘어갔습니다. 저희로서는 천만 다행이었습니다.
(voice를 text로 변환하는 STT 단계를 생략한 것이죠.)
사실 저는 "데이터 분석? 데이터부터 받기가 쉽지 않을텐데"라는 내용을 업계 미리 동료로부터 들었기 때문에 데이터가 늦게 올 것을 대비해놓긴 했습니다.
샘플 데이터를 미리 받아볼 수 있냐고 요청을 했었고요. 얼마 되지 않은 데이터를 KoNLPy(형태소 분석 및 품사 태깅 라이브러리)에 돌려보면서 미리 DB에 어떻게 데이터를 insert할지 분석 로직을 짜고 있었습니다.
또 미리 CTO와 백엔드 개발자와 상의하여 DB를 설계하여 백엔드 테스트코드도 작성한 상태였습니다. 데이터를 전달받고 바로 가공하여 DB에 Insert를 하면 되는 상황이었습니다.
2. 데이터 정의서가 없을 때 발생한 이슈
하지만 어려움은 끝이 없었습니다.
데이터의 카테고리 정의서를 프로젝트 끝나가는 시점에게 받은 탓에 데이터의 카테고리를 전혀 알 수 없어 분석 전에 카테고리부터 라벨링을 해야만 했었거든요
문제는 받은 데이터는 한건이 아니라 빅데이터라는 것이죠. 총 9만건의 데이터 중 일부 잘못 전화함, 끊김, Null 등의 불필요한 데이터를 삭제한 7만여 건의 데이터를 라벨링하기에는 두명의 데이터 분석가 팀원들이 일일이 하기엔 많은 시간과 에너지가 따르는 일입니다.
도대체가 분류는 끝이 없다이럴 때 ML이 구세주처럼 등장합니다. 저는 여기에 자연어처리 ML을 사용하자는 아이디어를 냈고 이전에 같이 머신러닝 엔지니어 교육을 받은 친구를 파트타임으로 고용하여 함께 Bert모델을 개발하였습니다.
LDA와 한글 자연어처리 모델 정확도가 높다는 skt의 koBert모델을 사용하여 카테고리 라벨링을 학습 분류하고자 했습니다.
ML을 개발하기 전에 우선 형태소 분석기와 TDM을 통해 빈도수 높은 단어를 도출하여 카테고리를 전부 세분화하여 일부 데이터를 라벨링을 하고 나머지 데이터를 학습시키면 되는 일이었습니다.
다행히 KoBert ML은 정확도 84%로 나름대로의 카테고리 라벨링을 마칠 수 있었습니다.
3. 필요 데이터의 모수가 부족했었던 이슈
저희가 제안한 프로젝트는 총 2개로 두번째로 제안한 내용은 재구매 예측 ML 개발 프로젝트였습니다.
특정 모델을 구매한 고객 데이터를 기반으로 비슷한 다른 모델을 재구매할 고객을 예측하는 머신러닝 개발이었습니다. 이건 고객정보가 포함된 데이터라 미리 샘플 데이터를 받아볼 수가 없었죠.
나중에 받은 데이터를 확인한 결과 특정모델을 구매한 고객 데이터 수는 무척 부족하였고
모델 개발까지는 시간상 진행이 어려워 EDA 분석까지만 실시할 수 있었습니다.
아무리 애를 써도 어쩔 수 없는 건 어쩔 수 없는 거시다....이에 대한 대안으로는 PoC 이후에 5년 이상 기간의 데이터를 확보하여 재구매 예측 모델을 이어서 개발하는 방안을 제안하였습니다.
하지만 고객사 측에서는 PoC 단계에서 재구매 예측 ML을 많이 기대하셨더라고요.
물론 부족한 시간으로 한개의 프로젝트를 해낸 것만으로도 다행입니다만 선택과 집중을 하지 않았다면 프로젝트는 엎어졌을겁니다
(3주라는 짧은 기간 동안 저는 둘 중 하나는 포기해야만 했습니다. 그나마 시각적으로 가장 고객사에게 어필할 수 있었던 점이 대시보드라고 판단했고요.)
4. 관련 도메인 지식이 부족했던 이슈
BDC, eCOM, EoT고객, bsi , CIC, bcc, Poi 등 이 단어들이 뜻하는 것들이 무엇일까요?
모두 자동차 업계에서 실제로 사용하는 업계용어입니다.
두번째로 힘들게 했던 관문은 부족한 업계 지식때문에 도대체 이 데이터가 뜻하는 게 무엇인지 몰랐던 것이었습니다.
고객사에게 전달받은 데이터는 모두 이러한 용어로 이루어져 있었고 팀원들과 단어 해석에만 한참을 시간을 할애했습니다.
이것은 도대체가 무슨 말이다냐..