회사에서 미션 중 하나는 팀 소속 주니어 분석가들의 역량을 강화하는 거다. 한동안 어떤 프로그램으로 어떻게 운영할지를 많이 고민했지만, 그들의 현재 상태를 파악하는 게 우선이었다. 그래서 공개된 데이터를 각자의 방식대로 분석한 결과를 정리해서 제출하게 했다. 30여 개의 결과 자료를 보면서 생각이 많아졌다. 여러 자료에서 공통된 부분도 있고, 나름 독특한 관점으로 데이터에 접근한 것도 있었다. 결론부터 말하면 기대치를 충분히 만족시킨 건 없었다. 기술적인 부분(technical skills)은 대부분 나보다 오히려 낫지만 분석이라는 게 기술만으로 완성되지 않는다. 이전 면접 과제 글에서도 적었듯이 데이터 과학자들의 모델 학습을 위한 분석은 정형화된 EDA 과정을 거치면 다소 해결되지만, 사람들을 위한 분석은 좀 더 입체적이다. 제출된 결과물을 보면서 비기술적인 측면에서 아래와 같이 나름 정리했다.
문제가 문제다.
데이터 분석에서 가장 먼저 고려돼야 하는 것은 해결하고자 하는 문제가 무엇인지 명확히 해야 한다는 거다. 외부에서 주어진 경우도 있지만 스스로 문제를 정의해야 하는 경우도 많다. 문제없인 답도 없다. 이번 분석을 통해서 확인하고자 하는 바가 무엇인지 먼저 명확히 정하고 그에 맞는 분석 방법을 택해야 한다. 그런데 대부분은 그저 기계적으로 데이터를 파이썬으로 불러와서 기본적인 통계치를 확인하고 미싱이나 아웃라이어를 확인, 처리하는 등의 작업을 한 걸 볼 수 있었다. 풀고자 하는 문제가 무엇인지 알 수가 없다는 거다. 공개된 데이터에 관한 설명이 부족해서 문제를 정의하는 것이 다소 어려웠을 수도 있다. 이럴 때는 그냥 데이터를 엑셀 등으로 열어서 목적 없이 쭉 훑어보면서 눈에 띄는 특성이나 이상을 기록하며 데이터와 조금씩 친밀해지면 어느 순간 문제가 구체화되는 경우도 있다. 몇몇 친구들은 독특한 시각으로 풀고자 하는 문제를 정의했지만 그렇게 접근한 맥락 설명 없이 바로 직진한 점이 다소 아쉬웠다. 일단 큰 문제를 정의하고 그걸 다시 세부 문제로 쪼개가면서 왜 이 부분을 해결하고자 했는지 등을 명확히 했다면 자연스럽고 듣는 사람들이 쉽게 맥락을 이해할 수가 있을 거다. 회사든 사회든 슬기롭게 생활하기 위해선 의제를 설정하는 능력이 중요하다. 주니어일 때는 명확히 정의된 문제가 주어지는 경우가 많지만, 연차가 차고 승진해서 더 다양한 사람들을 만나야 하는 자리에 이러면 주어진 문제도 점점 더 모호해지고 때론 스스로 문제를 찾아서 해결해야 한다. 그저 간단한 데이터 분석이지만 미리 그런 상황을 훈련하는 것이 필요하다. 상황에 따라서 한 스텝 더 들어가서 얻은 인사이트를 제시하는 것도 능력이다.
도메인이 먼저다.
인터넷을 찾아보면 1) 확률 통계를 비롯한 수학 지식, 2) 프로그래밍 능력, 그리고 3) 비즈니스와 도메인 지식을 데이터 과학자 또는 분석가의 필수 역량으로 꼽는다. 100% 동의한다. 처음에는 수학과 프로그래밍을 익히는 게 급하지만, 현업에서 다양한 상황과 문제를 계속 만나다 보면 그것들을 해결할 때 도메인 지식이 가장 중요하다는 걸 자주 느낀다. 도메인은 문제와 데이터의 맥락을 제공한다. 겉보기에는 같은 데이터더라도 맥락에 따라서 완전히 다른 데이터가 되고 전혀 다른 인사이트가 도출될 수 있다. 도메인 지식은 분석을 쉽게 만든다. 때론 도메인 지식이 일종의 편견이 돼서 분석을 잘못된 방향으로 이끌기도 하고 확증 편향 등의 부작용도 있지만, 도메인 지식의 유무에 따라서 분석의 속도나 질에 차이가 매우 크다. 유능한 분석가라면 도메인 지식이 없이도 주어진 데이터만으로 데이터의 본질과 함의를 찾아낼 수 있겠지만, 보통은 그렇지 않다. 도메인 지식은 문제를 정의하고 가설을 세우는데 큰 역할을 한다.
분석은 선형이 아니다.
일반적으로 통용되는 분석 과정이 있다. 문제를 정의하고, 가설을 세우고, 데이터를 확보해서, 가설이 맞는지 검증해서 결과를 제공한다 정도로 대부분 알고 있다. 대부분의 분석 101 강의에 들어가면 이를 도식화해서 보여줄 거다. 이것만 보면 순차적으로 어떤 액션들을 취하면 최종 결론이 하늘에서 뚝 떨어지는 듯한 착각을 일으킨다. 이건 아주 운이 좋을 때 얘기다. 애초에 풀고자 했던 문제가 명확했고, 운 좋게 근거 데이터가 존재했고, 분석 중에 실수가 전혀 없었다면 순차적인 과정을 통해서 답을 얻어냈을 수도 있다. 하지만 아주 간단한 데이터 문제를 해결할 때조차도 결론이 원샷으로 나오지 않는 경우가 더 많다. 가설과 데이터가 상이해서 다시 가설을 세워야 하는 경우도 허다하고, 분석 작업을 많이 진행했는데 데이터가 가설을 검증하기에 불완전하거나 전혀 엉뚱하다는 걸 눈치챌 때도 있고, 마무리를 지을 때가 됐는데 갑자기 문제 자체가 바뀌는 경우도 있다. 잘 마무리해서 사장님께 보고를 했는데, 사장님이 다른 질문을 하면 다시 처음으로 돌아가야 한다. 데이터를 보다 보면 처음에는 몰랐던 걸 발견해서 애초 계획에 없던 전혀 다른 추가 분석을 진행하는 경우도 종종 있다. 문제를 명확히 정의하고 도메인 지식이 필요한 이유도 이런 혼란을 사전에 최대한 줄이기 위함이다. 그럼에도 분석은 선형적이지 않다. 제출된 결과물들을 보면서 분석을 참 평면적으로 접근했구나라는 느낌을 많이 받았다. 분석가는 그런 지루함을 이겨내야 한다.
해석 없는 분석 없다.
어떤 자료를 보면 그저 몇 페이지 연속으로 별도의 설명도 없이 테이블이나 차트로 가득 차 있다. 데이터를 잘 요약해서 숫자 테이블이나 차트로 그리면 분석이 끝났다고 생각한 것 같다. 간단한 문제에선 몇몇 테이블과 차트만 봐도 상황을 모두 파악할 수 있지만, 문제가 복잡할수록 분석된 것을 어떻게 해석해야 하는지 그리고 그걸 바탕으로 얻은 인사이트가 무엇인지를 명확히 해줘야 한다. 그걸 독자의 몫으로 남기는 건 일종의 직무유기다. 예를 들어, 서비스가 지금 성장하고 있는가?라는 질문에는 그저 월별 활성 사용자 MAU 차트만을 보여주는 것으로도 충분할 수 있지만, 이게 진짜 사용자가 늘고 있는지 아니면 그저 시즈널성이 반영된 일시적인 건지 등을 설명하거나 특정 시점에 어떤 이벤트가 있어서 성장했는지 또는 향후에 계속 성장하려면 어떤 전략을 취해야 할지 등을 부가적으로 제공해줄 수 있다면 더 나은 분석이 된다. 분석은 사실만을 확인하는 작업이 아니다. '분석의 종류 types of analysis’로 검색해보면 descriptive, diagnostic, predictive, prescriptive analysis 이렇게 4개로 구분해서 설명한 글들이 많이 있다. 단순히 현상만 확인하는 descriptive analysis로 충분한 경우도 있지만, 왜 그런지 현상과 원인을 진단하고 미래를 예측하고 그래서 앞으로 어떻게 해야 하는지를 알려주는 것까지 분석이다. 그리고 발견한 것 (findings)이 곧 인사이트인 건 아니다.
최종 결과물이 말한다.
데이터 분석의 최종 결과물은 한 묶음의 테이블이나 차트가 아니라, 소통이다. 분석을 통해서 발견한 것들과 인사이트를 누군가에게는 공유해야 한다. 공유를 위해선 자료화가 돼야 하고, 특히 청자/독자의 언어로 기술돼야 한다. 그냥 취미 삼아 데이터를 보는 데이터 덕후도 있을 수 있지만, 데이터 분석의 최종은 결과적으로 동료가 됐든 상사가 됐든 아니면 일반 대중이 됐든 누군가에게는 분석의 내용을 공유하는 거다. 휘황찬란한 자료를 만들 필요도 이유도 없다. 다만 분석 내용과 결과를 독자나 청자가 쉽게 이해할 수 있도록 깔끔하게 정리하는 것도 데이터 분석가의 능력이다. (말발이 더 해지면… 거의 사기꾼이 되는 거지만.) 외국의 유수의 대기업들이 직원들에게 회의나 발표 자료를 만드는데 너무 많은 시간을 들이지 말라고 가이드하는 것은 자료를 대충 만들라는 의미가 아닐 거다. 2~3분 만에 손으로 대강 그린 그림을 사진 찍어서 공유하면 되는 것을 포토샵이나 일러스터레이터를 열어서 3~4시간 동안 1mm의 오차도 없이 그려서 자료를 만드는 등 그런 걸 하지 말라는 거다. 어차피 회의를 통해서 변경될 거고 더 구체화됐을 때 다시 정리해야 할 거다. 그 시간에 대신 의제에 더 집중, 고민해서 더 나은 해답을 찾으라는 거다. 어차피 우린 디자이너가 아니어서 그들만큼 자료를 예쁘게 잘 만들지 못한다. 대신 핵심을 깔끔하게 정리, 표현할 수는 있어야 한다. 사람에 따라서 이런 작업이 별로 중요하지 않다고 여길 수도 있다. 별로 중요해 보이지도 않는 사소한 것까지 신경을 써야 한다고 말하는 이유는 ‘별로 중요하지 않은 것이 중요한 것을 가릴 수 있기’ 때문이다. 극단적인 예를 들어, 시리즈 B 투자 피칭을 하는데 자료 중에 오탈자가 하나 있었고 만약 투자자가 그 오탈자가 너무 눈에 거슬려서 창업자의 피칭에 집중하지 않는다면 어떻게 될까? 물론 이런 중요한 자료에서 이런 경우는 거의 없겠지만, 평소에 사소한 것을 무시하고 습관이 되면 중요할 때도 지나칠 수 있다. 시작이 반이지만 결과가 나쁘면 제로, 아니 마이너스다.
지원자 모두에게 이런 피드백을 줬다. 나도 아직 데이터 분석이 뭔지 잘 모르겠다. 이렇게 말은 하지만 내가 저렇게 하고 있는지도 모르겠고… 어렵다.
DM ML AD
데이터 분석의 비기술적 측면
반응형