by
Jul 28. 2022
분석가는 아니지만 분석은 해야 한다면
그래서 SQL부터 배워야 하는 건가?
분석가는 아니다. 그러나 분석은 해야 한다. 고객에 대한 이해의 이론상 절반이 숫자에 있으니까(숫자와 숫자 아닌 것). 그리고 마침 지난 두 달은 이래저래 쿼리로 직접 고객 행동 로그 데이터를 분석하고 확인하는 일이 잦았다.
그런데 취준생부터 3~4년 차 정도의 또래 주니어들이 모인 커뮤니티/단톡방 곳곳에서 '데이터 분석이 요새 직군 불문 필요하다던데 SQL부터 배우면 되나요?'라는 질문을 자주 보거나 듣는다.
분석이란 무엇인지 수박 껍질의 솜털 정도 맛 본 수준이지만, 'SQL부터 배우면 되나요?'에 대한 질문에 대한 생각을, 이른바 비전공자 그리고 분석가 직무가 아닌 입장에서 느낀 분석 업무를 서술하며 풀어보려 한다.
0. 배경과 맥락 없는 분석은 없다
프로젝트든 테스크든 모든 업무엔 목적과 배경이 있다. 갑자기 어느 날 '이유는 모르겠지만 아무거나 숫자 좀 볼까?' 하는 일은 없다. 모든 업무엔 기획이 (숨어) 있다. 그리고 기획엔 배경, 맥락이 있다.
나는 지금 무엇을 위해, 어떤 연유로, 어쩌다가 숫자를 보기로 했나? 거꾸로 말해 이 질문에 대한 답이 없는 숫자 살펴보기는 업무가 아닌 교양 내지는 지적 유흥은 아닐까. (업무 외 시간엔 사실 이런 걸 매우 좋아한다)
나는 지금 무엇을 위해, 어떤 연유로, 어쩌다가 숫자를 보기로 했나?
1. 쓸만한 가설을 세웠는가?
배경과 맥락을 바탕으로 알아보고자 하는 큰 주제가 생기면(Key Question), 그걸 알기 위한 몇 개의 세부 질문과 가설을 세우게 된다.
그런데 이때, 내가 세운 가설이 너무 뻔하진 않은가 생각하게 된다. 애써 지표/척도를 정하고 쿼리도 짜고 해석도 했는데, 사실 구태여 알아볼 필요도 없이 당연한 사실, 또는 조직 내 누군가는 이미 알고 있는 사실이라면?! (몇 번 이래 봤다)
숫자로 최종 스토리라인을 만들다 보면, 나는 혹시나 모를 대단하고 새로운 발견을 기대하며, 야산을 헤매는 심마니의 마음으로 숫자와 쿼리의 산을 헤맨 건 아니었나 돌이켜보게 된다. 숙련된 이들도 대개는 허탕을 치고 마는 산길을, 동네 뒷산도 겨우 오르는 주제에 따라나선 건 아니었는지. 그리고는 집 앞 공터에도 있을 흙이나 한 줌-뻔한 결과물-을 쥐어오고 만 건 아닌지.
물음표만 붙여두면 얼추 모든 게 가설처럼 읽힌다. 그런데 값어치는 모두 다르다. 무엇이 진짜 내가 시간을 들여 검증해볼 만한 가설인가. 또는 탐색해볼 만한 현황인가.
이런 옥석을 가려내는 능력은 서비스와 고객에 대한 이해, 식견과 관심 등 제너럴리스트로서의 '짬'에서 오는 건가 싶다. 그리고 스스로 제일 멀었다 싶고 또 앞으로 제일 오래 쌓아갈 부분이 바로 이 지점이라고 생각한다.
무엇이 진짜 내가 시간을 들여 검증해볼 만한 가설인가.
또는 탐색해볼 만한 현황인가.
2. 가설을 제대로 정의/정리했는가
통역을 전공한 탓에 생긴 이상한 습관인지도 모르겠다. 가끔 아, 다르고 어, 다르다는 데에 집착한다. '진짜 이 문장이 맞나? 정의된 문장의 한 끗 차이로 다른 지표, 다른 분석을 하게 되진 않나?'
좋은 정보란 얼추 이쯤에 어딜 파든 발견할 수 있는 드넓은 고대 유적지가 아니라, 발 폭 하나 차이를 두고 다른 곳을 파면 허탕을 치고 돌아가게 만드는 아주 작은 유물 한 점은 아닐까, 라는 생각을 한다.
아, 다르고 어, 다르다
3. 정의한 가설을 확인하기 위한 적합한 지표와 척도를 세웠는가
문장이 정리면 되면, 그 문장에 대한 답을 얻기 위한 지표와 척도를 선택하는 문제가 남아있다. 가령 기업의 성장은 '매출액'으로 봐야 하나 '순이익'으로 봐야 하나? (물론 이걸 포함해서 가설을 세워버리면 지표 고민이 다소 줄어드는 것 같다)
실험을 설계할 땐 '이 장치는 어느 지표를 건드리게 되나?' 살피던 것처럼, 분석할 땐 '이 가설은 어떤 지표로 어떻게 봐야 하나?' 살펴본다.
우리 제품이 어떤 값을 저장하고 있는지를 기록해둔 DB 스키마도 있고 GTM Taxonomy도 있지만, 덜렁 이것만 있다고 되진 않는다. 이건 분석 가능한 지표의 옵션 리스트일 뿐이니까.
적다 보니 결국 분석도 실험처럼 설계의 영역임을 깨닫는다.
4. 선택한 지표와 척도를 바탕으로 툴을 제대로 세팅하거나 쿼리를 올바르게 작성했는가
이 부분 때문에 많은 또래 주니어 분들이 'SQL을 배워야 하나요?'를 묻는 듯하다.
물론 쿼리를 짜기 이전 및 이후 단계를 잘했더라도 결국 쿼리를 모르거나 제대로 못 짜면 물거품이다. 투자에 대해 가르치던 어느 교수님이 투자 포트폴리오는 학생보다도 못하더라는 일화처럼, 가설은 쿼리 또는 다른 툴/언어를 통해 실행된다.
그런데 역설적이게도 전/후 단계 없이 이것만 잘하면 결국 쿼리 짜는 기계가 되진 않나 싶다. 모든 하드 스킬은 나보다 더 전문가인 기술자에게 외주화 된다. 반면 우리에게 마지막까지 남는 것은 소프트 스킬 아닐까.
5. 나온 숫자를 올바르게 이해했는가
이른바 리터러시인 듯하다. 이 숫자는 정말 개선된 걸까? 전년과 비교하면? 동기간 다른 것과 비교하면? 편차 이내의 있을 법한 변화는 아닌가? 실험이라면 통계적으로 유의미한가? 혹시 우연은 아닌가?
아직 어렵다. 그런데 내 주식창을 바라보며 하는 질문과 대부분 유사하다는 생각도 든다. (ㅎㅎ...) 내 실적은 다른 사람 대비 어떤지. 이 기업은 시장 전반 대비 어떤지. 작년 대비 어떤지. 박스권인지 등등.
6. 액션을 도출했는가?
'쓸만한 가설인가?'와 엮이는 듯하다. 숫자는 유의미한데 우리가 할 수 있는 게 없다면? '이러이러한 의미입니다. '좋아요, 그럼 우리는 뭘 해야 하죠?' '음... 그게 일단.. 이런 의미라는 걸 알았다는 사실을 축하하기?' 같은 상황이라면?
우리 대부분은 연구자가 아니다. '일단 이런 사실을 검증했고 이후 과정은 다른 연구자와 후속 논문에게 미룬다'는 옵션은 없다. 검증된 사실을 바탕으로 서비스를 성장시킬 무언가를 해야 한다.
숫자가 처음일 때, 분석이 처음일 때 숫자의 의미 그 자체에 심취하면 액션을 잊게 되는 것 같다.
검증된 사실을 바탕으로 서비스를 성장시킬 무언가를 해야 한다.
