읽고 느낀점
-
비즈니스 인텔리전스 커뮤니티 비저블을 하면서 단순히 데이터 분석이라는게 데이터를 펼쳐놓고 들여다보기만 하는 것이 아니라는걸 깨달았다. 내가 비저블 사전과제로 제출한건 단순 EDA 였는데, 지금 생각해보면 보고자 하는것이 무엇인지도 모르면서 그냥 단순히 얻어걸리기를 바라는 데이터 분석 과정이었다.
-
데이터 문해력이라는게 중요하다는 사실은 너무 많이 들어 알고 있었지만, 사실 SQL이나 Python 같은 스킬적인 부분에 비해 측정 방법도 모호하고, 능력을 기르는 방법도 모호한 부분인게 사실이다.
-
처음에는 컵에 물이 반정도 들어있는 것을 보고 누군가는 :) 컵에 물이 반이나 들어있네 라고 표현하고 누군가는 :) 컵에 물이 반밖에 없네 라고 표현할수 있다고 생각했다. 그래서 데이터 분석가라면 -> 컵에 물이 50% 차있습니다 와 같은 정확한 표현을 하는것이 더 옳다고 생각했다.
-
하지만 데이터 분석 상황에서 가장 중요한것은 "컵에 물이 50% 정도 들어있는게 문제인가?" 하는 부분이었다. 더 나아가 그렇다면 "얼마까지 물을 채워야하고", "왜 물이 그정도로 차있는지를 파악하고 어떻게 물을 효과적으로 원하는 목표치까지 채워야 하는가?" 였다.
데이터 활용 프로세스 5단계
요약
- 문제 및 목적 정의
- 지표 결정
- 현재 상태 파악하고 평가
- 원인 분석
- 해결 방안 모색
1. 문제 및 목적 정의하기
1-1. 이 단계에서는
- 무엇을 알고 싶은지, 어떤 문제를 해결하고자 하는지 구체적이고 명확한 언어로 정리하기
Tip. 문제와 목적은 이미 우리가 알고 있는 것인 경우가 많으며 따라서 ‘의식적으로 다시 확인한다’ 정도의 인식을 하는 것 자체에 의미가 있다.
목적·문제를 모호하게 설정한 상태에서는 우연히 눈에 띈 데이터를 모아 시각화해도 의미있는 결론 도출이 어려움
1-2. 이 단계에서 주의할 점은
- 문제, 원인, 해결방안을 구분하고 문제/목적 정의 시점에 원인과 해결방안을 단정하지 않도록 한다.
1-3. 예시
-
좋은 예) 2022년 들어서 데일리 대시보드에서 매출은 증가하고 있지만 이익률이 감소하는 패턴이 지속적으로 나타나고 있는 것 같다. 이익률 증가/감소 추이를 정확히 파악하고 만약 이익률이 감소하고 있다면 그 원인을 파악해 매출 이익률을 개선하고자 한다.
-
안 좋은 예) 고객들이 많은 상품을 장바구니에 담아서 매출은 증가하고 있지만, 무게에 따른 배송비가 비싸져 이익률이 감소하고 있다. 중량이 가벼운 대체 상품을 많이 소싱해 건당 배송비를 낮춰 이익률을 개선하는 것이 목표이다.
문제를 정의하는 시점에 이미 문제, 원인, 해결방안이 뒤섞여 있다.
문제 정의 단계에 이미 주관적인 추측을 가지고 원인을 단정해버려 데이터 기반한 문제해결이라고 보기 힘들다.
2. 지표 결정하기
2-1. 이 단계에서는
- 목적과 문제에 대해 논리적인 결론을 낼 수 있는 데이터와 지표를 설정한다.
Tip. 문제에 대해 전혀 모르는 사람에게 ‘나의 고민은 이것이다’라고 말할 때 어떤 데이터를 활용할지 생각해보자.
2-2. 이 단계에서 주의할 점은
-
구체적이고 명확한 언어를 사용하고 익숙해서 무심코 사용하는 ‘생산성’과 같은 단어나 표현은 주의한다.
지표를 설정하는 시점에서 ‘원인’과 ‘해결방안’을 단정하지 않도록 한다. -
예) XX 시설 이용 횟수를 주 평균 2회 이상으로 올리고자 한다. 지표는 사용자 만족도로 설정한다.
📌 → 사용자 만족도가 낮아 이용 빈도가 낮다는 원인에 대한 판단이 이미 끝난 상태다. 그리고 사용자 만족도를 높이면 이용 빈도도 높아질 것이라는 해결방안에 대해서도 단정한 상태다.
3. 현재 상태 파악하고 평가하기
3-1. 이 단계에서는
- (파악단계) 문제 상황에 대한 데이터를 그래프나 표 등으로 시각화하고 주요 지표를 실제로 구해보는 단계다.
- (평가단계) ‘비교’를 통해 현재 상황에 대해 평가하고 단순히 지표 해석 결과가 아닌 문제 상황에 대한 결론을 도출한다.
- Tip. 문제나 배경에 대해 전혀 모르는 사람에게 내가 다루는 문제를 설명한다고 생각하자. 여기서 어떤 데이터를 어떻게 보여주면 ‘아 확실히 문제가 있네요’라는 답변을 들을 수 있을지 생각하자.
3-2. 이 단계에서 주의할 점은
-
비교를 통해 어떤 결론을 내릴 수 있는지와 그 결론이 목적이나 문제와 연관성이 있는지 (내가 확인하고자 하는 것을 확인할 수 있는지)를 먼저 검토하고 나서 비교 작업을 수행한다. 그렇지 않으면 단순히 그래프를 그려내는 것에 그치게 된다.
-
결과가 아닌 결론을 내리도록 한다.
-
결과: XXX와 YYY는 차이가 있습니다
→ 그래프를 보고 이를 단어로 바꿔 표현한 것 -
결론: XXX와 YYY의 차이가 존재한다는 것은, ZZZZ라는 의미입니다
→ 그 차이가 결국 어떤 내용인지를 설명하는 것 -
비교를 통해 차이를 못 찾았더라도 틀리거나 문제가 있는 것이 아님을 인지한다. 초기 가설이 틀렸거나 차이가 없다는 사실 자체가 결론이 될 수 있다.
원인에 대해 분석하는 단계를 건너뛰고 해결방안으로 바로 넘어가지 않도록 주의한다.
4. 원인 분석하기
4-1. 이 단계에서는
-
문제/결과에 대한 원인을 분석하고 해결방안(목적)을 도출하기 위한 근거를 찾아낸다.
-
원인 후보를 열거하고, 지표를 결정한 후, 관련성(산포도나 상관계수 등을 활용)을 확인하며 원인을 다각도로 분석한다.
4-2. 이 단계에서 주의할 점은
-
Why를 계속 파고들어야 한다.
적당하게 ‘왜?’라는 질문을 멈춰버린 상태에서 원인을 단정하게 되면, 나중에 최종 단계(해결방안 모색)에서 근본적인 원인에 대한 근본적인 해결책을 찾아내기 힘들게 된다. -
예) 초과근무 시간이 많다 → 왜? → 수요일이 특히 야근이 많아서 평균을 올리고 있다
-
여기서 why를 멈추면 ‘수요일을 야근 없는 날로 지정하자’라는 해결방안을 찾게 되는데 이때 아이디어와 근본적인 문제의 원인 사이에는 큰 간극이 생기게 된다. 실제로는 why를 계속 하다보면 특정 팀의 팀원이 부족해서 평균적으로 야근이 많은데 수요일에는 고객사로부터 요청이 많이 들어오는 날이라 특히 야근이 많아져 초과근무 시간이 올라가는 것일 수 있다. 이때는 해결책이 결코 ‘수요일은 야근 없는 날’이 되어서는 안 된다.
-
적당히 멈추고 해결방안을 모색하는 것을 지양하자 “논리적인 흐름과 구조에 대해 생각하는 것에 비하면 구체적인 방법을 고민하는 것이 즐겁고 편하므로 이를 우선하기 쉽지만, ‘해결방안’을 고민하는 것은 마지막 단계임을 명심하자”
5. 해결 방안 모색하기
5-1. 이 단계에서는
- 논리적으로 분석된 원인에 대한 논리적인 해결책을 제시하고 실행한다
- Tip. 원인 분석을 간과한 결과가 아닌지 검증하기 위해서는 ‘이 해결 방안을 통해 어떤 것을 실현하거나 해결할 수 있나?’, ‘그리고 그 근거는 어디 있나?’ 라는 질문에 대답해보자
5-2. 이 단계에서 주의할 점은
- 해결방안은 문제에 직접 적용하는 것이 아니라 문제를 일으키고 있는 ‘원인’에 적용하는 것임을 명심하자
- 결과적으로 같은 결론에 도달하더라도 위와 같은 ‘적절한 사고 과정’을 거치는 것이 중요함을 명심하자
- 전체적인 로직을 무시한 채 완전히 새롭게 문제를 해결하는 방식을 제시하면 논리적 비약이 발생하기 쉽고 관련성이 부족하여 설득력을 갖기 어려움
- 실제 데이터 활용 1~5단계의 과정에서 많이 간과되는 부분이 1~3단계다. 대부분의 시간을 원인 분석과 해결 방안 모색에 사용하기 때문이다. 1~3단계를 의식적으로 구분해서 한 단계씩 완료해나가면 방향성을 잃지 않고, 문제와 결론의 일치성이 보장되는 데이터 활용이 가능할 것 같다.
레퍼런스
