전략 기획자의 데이터 핸들링
야근 없이 퇴근할 수 있는 데이터 핸들링 원칙들
요즘 기획자를 뽑는 채용 공고에 데이터 이야기 안 나오는 것은 거의 보지 못했습니다. 적어도 이런 표현 중 하나는 들어가죠.
‘데이터 분석에 뛰어난 분’
‘데이터를 다루는 솔루션 '###', '@@@'을 잘 다루는 분’
‘데이터를 통해 문제 해결한 프로젝트 경험이 있는 분’
데이터는 기획의 기초가 됩니다. 데이터가 4차 산업 시대의 원유로 평가받듯, 기획자에게는 작은 데이터 하나가 논리의 기초가 되고 퇴근의 지름길이 되죠.
기획이 회사에서 데이터를 다루는 환경은
너무나 다양합니다
과거에 구축한 ERP를 통해 BI 솔루션으로 데이터를 보는 것이 중견 기업 이상에서 마주하는 환경이라면 스타트업에서는 ERP 구축 전 오픈 소스나 간단한 상용 BI 솔루션을 이용해 서버에 있는 데이터를 직접 코딩해서 분석하기도 합니다. 심지어 수기로 모든 것을 오피스 도구에 넣고 하나씩 함수를 짜 가면서 일하는 환경도 있습니다. 데이터는 기업 내부에 어떻게든 존재하지만 적재 방식에 따라 다뤄야 하는 도구가 판이하게 달라집니다.
하지만 도구가 달라도 기획자가 데이터를 처음 마주 대할 때 공통적으로 풀어나가는 문제 해결 방법이 있습니다. 먼저 풀어야 할 과제를 명확하게 정의한 다음 가장 처음 내부에 쌓인 매출, 재고, 발주, 재무, 고객 데이터 등을 보고 무엇이 문제를 푸는 데 도움이 되는 데이터인지 확인합니다. 거기서부터 시작이죠.
목표하는 지표가 무엇인지 알아야 한다
함수에서 말하는 독립변수와 종속변수. X가 변하는 것에 따라 영향을 받는 Y가 무엇인지 정의하는 것이 데이터를 처음 볼 때 혹은 보기 전에 정리되어야 합니다. 정성적인 주제를 풀어나간다 해도 가장 유사한 정량적 목표를 가정이나 추론에 의해 정하는 것이 필요합니다. 간단한 현상을 데이터를 통해 집계하는 것부터 복잡한 예측 모델링에 이르기까지 이것을 정하지 않고는 처음부터 막힐 수밖에 없습니다.
실제 많은 기획자가 초보일 때 무엇을 봐야 할지 몰라서 시간을 허비하는 일을 많이 보게 됩니다. 내부에 어떤 데이터를 가지고 있는지 몰라서 그렇죠. 냉장고에 요리할 재료가 무엇이 있는지 모른 채 요리 이름만 되뇌고 있습니다. 회사 내부에 ERD처럼 데이터가 어떻게 연결되어 있는지 한눈에 볼 수 있는 문서가 있으면 자주 보면서 어떤 데이터가 언제 어떤 순간에 어떤 기준으로 발생하는지는 알고 있어야 합니다. 특히 재무제표에 직접적으로 나오는 항목들은 발생 기준을 정확하게 아는 게 나중에 두 번 일하지 않게 만들 수 있습니다.
#CASE. 생성 방식의 중요성
가령 생산 프로세스가 얼마나 걸리는지 측정하기 위해 ERP에 각 생산 단계별로 찍힌 날짜를 불러와서 상품별로 계산해서 평균을 낸다든지 작업을 할 수 있습니다. 하지만 정확한 현장의 문제를 파악하기 위해서는 간략한 명사로 되어 있을 ERP 데이터의 날짜들이 정확하게 실물을 어떻게 다루는 순간 어떤 경로를 통해 찍히는지 확인이 필요합니다. 시스템으로 인식되어 날짜가 찍히는 경우도 있지만 사람이 입력하는 부분이라면 늦게 입력해도 입력 당시의 시스템 시간으로 올라가 있기 때문이죠. 과거 데이터 정합성에 대한 중요성을 전사적으로 모를 때 일단 일하고 데이터는 부수적으로 그냥 하는 식의 일하는 방식이 여전하다면 이 데이터는 신뢰할 수 없습니다.
#CASE. 기준의 중요성
고객 마일리지 적립의 기준이 되는 것도 마찬가지죠. 기업에서는 부채로 미리 잡는 마일리지가 양날의 검과 같이 다가올 때가 있습니다. 기획과 재무가 함께 이 주제를 놓고 이야기한 적도 있습니다. 하지만 고객이 지불한 금액 중 마일리지 적립 기준을 정확하게 모른다면 계산에 혼선이 있을 수 있습니다. 고객이 한 번 지불한 금액 전체가 마일리지 적립 대상이 되는 것인지 쿠폰 등을 통해 할인받은 것은 제외되는 것인지, 혹은 마일리지 적립에 대한 이벤트가 발생해서 영향을 준 게 있는지 다 확인하지 못하면 나중에 큰 규모의 마일리지 정책에 변화를 주어도 기존에 예상했던 재무 효과를 거두지 못하는 일도 벌어질 수 있습니다.
고유한 열쇠가 되는 변수를 알아야 한다
컴퓨터 공학을 하거나 데이터 관련 교육을 받으면 처음에 알게 되는 내용이지만 경영학이나 기타 전공만 한 사람에게 데이터는 여전히 미지의 이름입니다. 코딩에 대한 생각부터 들면서 어렵고 피하고 싶다고 생각하는 사람들도 있죠. 하지만 이런 분들도 기획을 하면서 데이터를 다루게 되면 고유한 열쇠, 흔히 ‘키(key) 값’이라고 부르는 것에 대해 알아야 합니다.
데이터가 행과 열로 정형화된 포맷으로 구성된 테이블에서 각 행에 해당하는 관측치가 서로 고유하게 다른 정보라는 것을 인식하게 만들어 주는 열이 무엇인지를 키 값이라고 부릅니다. 만약 상품 단위 리포트를 BI에서 보고 있으면 각 행마다 다른 상품으로 열에는 상품의 판매량이나 재고, 만든 사람 등이 나오는 식으로 구성이 되어 있겠죠. 각 행마다 상품이 다 다르고 거기에 맞춰 정보가 열에 들어간다면 상품번호가 키 값일 것입니다. 유입 채널이나 매장 단위의 실적 리포트를 볼 경우에는 매장 코드나 유입 채널 코드가 키 값이겠죠. 보통 BI를 누군가가 레이아웃을 기획할 때 이렇게 하는 경우가 많기에 이런 혼란은 덜 할 것입니다.
#CASE. 복합적인 키값
하지만 직접 서버에서 데이터를 SQL이나 R 등으로 본다면 테이블에서 키 값을 찾지 못해 혼란을 겪을 수 있습니다. 두 가지 이상의 열에 있는 변수를 결합해야 고유한 정보가 되는 경우가 있기 때문이죠.
예를 들어 서버에 있는 한 테이블이 일단위로 매장과 매장 내 포스(POS) 별로 매출을 적재하고 있다면 무엇을 보느냐에 따라 각 행을 그룹으로 만들어서 보는 범위가 달라집니다. 포스마다의 매출을 보고 싶으면 보통 포스 번호가 매장 내에서는 단순한 1~10 사이의 숫자로 이뤄지는 경우가 많아 이 열만 가지고 분석하려면 정확히 어디 매장에서의 포스인지 알 수 없습니다.
이때 매장과 포스를 결합해서 키 값으로 삼아야겠죠. 그것도 일자별로 매출의 추이를 보고 싶으면 일자까지 결합해서 키 값으로 삼아야 데이터를 집계할 때 중복이나 의미 없는 숫자를 연산하지 않을 수 있습니다. 엑셀에서는 눈으로 보면서 함수를 걸기에 몇 개의 열을 합쳐서 다시 새로운 변수를 쉽게 만들 수 있지만 서버에서 직접 데이터를 다루면 데이터 구조를 보기 어려우므로 처음에 주의해야 다시 작업하는 일을 막을 수 있습니다.
키 값을 잘 알아야 하는 이유는 이 테이블과 다른 테이블을 연결할 때 어떤 기준으로 두 개 이상의 테이블을 합칠 것인지 알 수 있기 때문이기도 합니다. 매장 단위의 상품별 매출 정보를 가진 테이블과 상품별 제조 정보에 대한 내용을 담은 테이블은 생성되는 주체가 다르기에 처음부터 하나의 테이블로 모아서 관리하기 쉽지 않습니다. 생산자가 입력하는 제조 정보를 매장에서 발생하면서 포스에서 찍히는 매출 정보와 연결해서 분석하는 일이 유통업 기획자에게는 잦은 일입니다. 이때 두 개의 테이블에서 공통적으로 쓰이는 키 값을 찾아 그것이 중복되거나 누락하는 행이 두 테이블에 각각 있는지, 있으면 어떤 경우인지 미리 알아야 정확한 분석이 가능합니다. 이런 경우라면 보통 상품 코드가 두 개 테이블을 연결하는 키 값이 되겠습니다. ERD 등을 통해 데이터 구조를 평소 많이 봤다면 더 쉽게 해결할 수 있을 것입니다.
정말 의미 있는 관계를 찾아야 한다
어떤 데이터가 있는지 알게 되면 이런 쪽을 좋아하는 기획자는 데이터를 통해 뭔가 하고 싶어 하는 게 많아집니다. 문제 해결의 결과가 되는 지표를 놓고 독립변수로 보고 있는 테이블의 여러 변수들을 넣어서 각 변수의 코드별로 비중이 어떻게 되고 전 기간에 비해 변화가 어떤 지를 가지고 분석 결과를 쓰고 싶어 집니다. 하지만 두 가지 유의 사항을 꼭 확인해 봐야 합니다. 통계적으로 유의미 한 지와 사업적으로 유의미 한 지 말이죠.
통계적으로 의미가 있다는 것은 각 독립변수가 종속변수의 변화를 설명하는 게 통계적으로 맞다는 것입니다. 매출의 변화가 어떤 원인으로 나타나는지 찾는 일에 여러 변수를 투입해 봅니다. 그리고 본인이나 상사들의 직관이나 평소 이야기를 통해 들은 내용들을 변수로 만들어서 아무 검증 없이 원인과 결과를 분석하는 보고서를 만듭니다. 사실 대부분의 회사에서 이렇게 일하기도 합니다. 그렇지만 증명되지 않은 관계로 계속 사업의 피드백을 할 수는 없습니다. 정확히 그것 때문인지 아는 것과 모르고 하는 다음 방향은 다릅니다.
#CASE. Data-driven
유통점에서 최근 매출 부진의 원인이 20대 초반 연령대의 구매가 줄어서라고 판단을 내렸습니다. 관찰과 직관을 통해 그런 결론을 잠정적으로 내린 것이죠. 그러고 나서 20대 초반 고객이 좋아한다고 생각하는 콘텐츠를 더 대대적으로 프로모션 하는 것으로 영업 전략을 바꾸었습니다.
하지만 아무 변화도 일어나지 않았습니다. 나중에 통계를 하는 사람이 분석해보니 유통점에서 20대 초반이 구매한다고 생각한 콘텐츠는 실제로 20대에서 유의미한 차이를 가지고 매출이 더 발생하고 있지 않았고 30대가 실제 더 많이 구매하는 것으로 나타났습니다. 그리고 과거 매출 자료에서 상관 분석을 거친 결과 20대가 더 구매한 콘텐츠는 생각하지 못했던 상품이었고, 이것과 함께 많이 구매하는 콘텐츠는 생각보다 여러 조합이 있다는 것을 처음 알게 되었습니다. 과거 현장에서의 인식이 부정확하고 안일했다는 것을 알 수 있습니다.
사업적으로 의미가 있다는 것은 상관관계든 인과 관계든 어떤 패턴이 나온다는 게 돈이 되는가에 대한 물음입니다. 변수와 변수 사이에 어떤 관계가 보인다는 것을 알게 되었습니다. 한 변수가 증가할 때 나머지 변수가 얼마나 증감하는지, 여러 변수들을 통해 한 변수를 설명하는 식이 나온다든지 기존에 알지 못했던 상품과 채널의 배열을 찾았습니다. 하지만 모든 게 다 쓸모 있지는 않습니다. 이런 조합이 아주 특수하고 적은 수를 차지하고 있다면 아무리 정확한 사실이라도 기업에 이익을 가져다주지 않습니다. 또 비용 대비 편익이 부족하다면 어느 정도 관측치가 있는 데이터라고 해도 안 하는 게 더 나은 경우도 있습니다.
또 전혀 쓸모없는 것 같은 두 개 이상의 관계를 분석해서 상관성이 있다는 것도 주의해야 합니다. 설령 날씨 변화에 따라 매출이 변화하는 관계를 찾았다고 해도 날씨를 미리 아는 게 어렵거나 안다고 해도 할 수 있는 기업 활동이 많이 없다면 이런 정보는 유용하지 못합니다. 내부에서 결과에 대한 핑계를 찾는데 이용될 뿐이죠. 실제 현장에서 피드백을 통해 변화의 실체까지 엮어낼 수 없다면 아무리 화려한 머신러닝 모델링도 폐기되는 일도 있습니다. 사업의 본질이 무엇이냐에 따라 때로는 복잡한 모델링의 확률보다 단순한 두 변수의 관계 설명이 더 효과적인 분석이 될 수 있습니다.
데이터의 성질에 대해 알게 되면 데이터를 붙잡고 아까운 시간을 허비하며 야근하는 일을 막을 수 있습니다. 데이터를 다루는 일은 대부분 처음에 일을 제대로 해 놓지 못하면 뒤로 갈수록 수정할 게 기하급수적으로 늘어나는 성질이 있기에 처음에 더더욱 정확하게 해 놓아야 합니다. 데이터를 집계하는 기준이나 로직을 정확하게 초반에 설계하지 못하면 뒤에서 새로운 지표를 만들어 분석하는 일 모두 수정해야 하는 아찔한 상황을 맞게 됩니다. 돌다리도 두드려 보고 건너가는 게 데이터를 통해 인사이트를 찾는 기획자의 모습이 아닐까 생각합니다.
* 아래 몇 가지 tip을 쓴 아티클을 링크합니다.
작가의 다른 콘텐츠
