비즈니스 데이터 분석에 있어 핵심적인 인사이트 내용만 남기고
요청자와 커뮤니케이션을 통해 분석에 너무 많은 내용을 담으려 하지 말 것
분석은 다각도로 했어도 핵심적인 내용이 아니라면 과감히 쳐 내는 것도 필요하다.
즉, 데이터 분석을 하는 목적/의도/배경을 파악하고 실제 액션까지 이어질 수 있도록 하는
데이터 분석 해석 & 제안이 중요한 것이다.
이 부분을 많이 잊고 "분석 열심히 했으니까 다 공유해야지" 라는 마인드도 생긴 것 같다.
아까워서.. 이것도 나름 인사이트인 걸? 이라는 생각이 더 복잡하게 만드는 것 같다.
정보의 간결성 / 핵심을 믿고 축약하고 쳐내는 것도 필요함을 늘 잊지 말아야 겠다.
[CASE 17] 분석 도구가 엑셀 파일을 읽어들이지 못한다.
다른 사람들이 활용하는 시트에 대해서 이해해보기, 이해하는 과정은 의미있는 과정이다.
실무자가 어떤 분석을 원하는 지는, 그들이 만든 엑셀 파일 안에 담겨 있다. 데이터 분석을 비즈니스에 활용하고자 한다면 다른 사람들이 손댄 엑셀 파일을 주의깊게 살펴보는 일이 중요하다. 사람들이 여기저기 손댄 지저분한 엑셀 파일일수록 데이터 분석을 비즈니스 영역에서 잘 활용할 수 있는 보물이 숨겨져 있다.
[CASE 18] 데이터 항목이 무슨 의미인지 이해하기 어렵다.
- 데이터 항목이 갖는 의미 이해할 수 없을 때 분석 요청자와 함께 한다. 수치 제공을 해주는 것도 의미있는 것!
- 데이터 시각화 한다 > 그래프에서 읽어낼 수 있는 정성적인 특성을 확인 > 그래프 단위 확인한다.
그래프를 통해 정성적인 측면을 이해할 수 있다 (EDA 과정), 시계열 그래프로 주기성 확인 가능,
히스토그램으로 값이 균등하게 분포 or 편향 여부 확인 가능하다.
정량적인 측면을 보여줄 때는 수치 / 단위 명시가 필수적이다.
✏️ EDA : 그래프와 대푯값으로 데이터의 분포와 특징을 발견
> 데이터의 분포와 값을 다양한 각도에서 관찰하며 데이터가 표현하는 현상을 더 잘 이해할 수 있도록 도와주고
데이터를 다양한 기준에서 살펴보는 과정을 통해 문제 정의 단계에서 미처 발견하지 못한 다양한 패턴을 발견함으로써
이를 바탕으로 기존의 가설을 수정하거나 새로운 가설 추가할 수 있다
➡️ EDA 의 분석 건수를 늘려서 인사이트를 제공해주자
[CASE 19] 프로젝트가 시작됐는 데 구성원 간에 손발이 맞지 않는다.
분석 결과 해석, 다음 할 일 정하는 부분은 다른 사람과 논의하자. 여러 명과 컴케한다면 더더욱 좋음
데이터 준비 > 분석 처리 > 분석 결과 해석 > 다음 할 일 정하기 ⇒ 중간 공유 활성도를 높이고 방향을 잡아가기
[CASE 20] 통계 모델은 과학적이며 객관적이라고 믿는다.
데이터를 기록하는 것부터 통계 모델을 만들고 그 결과의 유효성을 검증하는 것까지 모든 과정에서 사람의 힘이 개입된다.
그럼에도 최대한 자신의 주관을 배제할 수 있는 방향을 찾아 이런 사실을 분석 요청자와도 충분히 공유할 수 있도록 노력하는 것이 좋다.
➡️ 완벽하게 객관적인 것은 없음을 인지하고 이에 대한 부분을 잘 전달하는 게 중요하다.
✏️ 타파트가 쓰고 있는 시트와 업무에 대해서 이해하고 EDA 분석 안건 늘려 케이스를 늘리자
[CASE 26] 분석 요청자가 예상 외의 결과를 기대한다.
데이터 분석에 거는 기대 중 하나는 “지금껏 상상하지 못한 뜻밖의 사실을 알 수 있다”이다.
→ 이건 “데이터 마이닝”의 단계로 대다수의 데이터 분석은 생각보다 대단한 사실을 알아 내지 못한다.
오히려 당연한 사실을 당연하게 알게 될 뿐!
지금까지 해왔던 직감과 경험을 통해 정성적으로 알고 있던 사실을 정량적으로 뒷받침하는 것도 데이터 분석의 중요한 역할이다.
☑️ 의외의 결과가 나오는 일은 그리 흔하지 않음을 분석 요청자에게 전달하자!
[CASE 27] 가독성이 낮은 분석 스크립트를 작성했다.
동일한 처리 과정을 수행하더라도 데이터 분석가에 따라 전혀 다른 스크립트가 나오기도 한다.
대부분의 분석 프로젝트는 반복적으로 수행됨
☑️ 가독성 높은 스크립트 작성과 주석 작성 & 네이밍 규약을 통해 읽기 좋은 스크립트 작성하기
[CASE 28] 평가 지표가 비즈니스에 도움이 되지 않는다.
분석 요청자에게 모델 구축 결과를 설명할 때는, 적어도 산포도와 시계열 그래프를 제시하는 게 좋다.
산포도 활용하면 예측값과 어긋나는 경우가 실젯값이 클 때인 지 작을 때인지와 같은 경향성 보여줄 수 있다,
시계열 그래프로는 언제 여측 결과가 적중했으면 하는 지, 또는 언제 다소 빗맞아도 문제없겠는 지를 질문하며 확인할 수 있다.
비즈니스 영역에서 통계 모델은 ‘실제로 사용할 수 있어야 비로소 가치’를 지닌다.
통계 모델이 어떻게 사용되며 활용할 만한 가치가 있는 지 등을 포함해 통계 모델의 성능이 결정된다.
분석 요청자와 모델을 어떻게 활용할 것인 지 사전 협의 필요,
결과를 판단해서 분석 요청자에게 전달하는 경우 ‘더 좋은 모델’, ‘더 나은 결과’라는 함의 안에 여러가지 뜻에 대한 해석을 전달해보기
✏️ 27~28 케이스의 경우 당장 적용하진 않겠지만 추후 참고하면 좋을 것 같아 기록해둔다.
[CASE 29] 분석 요청자의 의도를 잘못 읽고 분석을 진행해버렸다.
인터뷰에서는 먼저 분석 목적을 명확히 하기 > 해당 목적을 달성하기 위한 문제 설정과 분석 내용 결정
인터뷰시 분석 요청자의 의도를 세심히 읽을 수 있도록 인터뷰 진행하기
→ 분석 목적, 분석을 통해 알 수 있는 것들을 정리해 분석 요청자에게 중간 공유하기
☑️ 이후 팀원들과 상의 후 분석 내용 구체화 이후 분석 요청자의 더블체크 진행 후 분석 진행
*분석 목적과 의도는 분석 프로젝트의 좌표와 같은 역할!
[CASE 30] 분석 작업만이 데이터 분석가의 본분이라고 착각하고 있다.
분석 진행 후 보고 단계에서 할 일
- 사실 : 데이터를 통해 직접 안 것은 무엇인가 열거한다
- 해석 : 데이터 이면에서 무슨 일이 벌어지고 있는 가를 고찰한다
- 가정 : 이대로 아무것도 하지 않는다면 어떻게 될까를 예상한다
- 대책 : 무엇을 해야 할까 제안한다
- 해결 : 대책을 실행하면 어떻게 될까를 예상한다
➡️ 보고 단계에서 해야 할 일은 계산 결과에 대한 “해석”과 “제안”
일정 짤 때 해석과 제안 정리하는 시간 확보와 함께 검토해야 할 계산 결과의 수를 줄이기
⇒ 계산에 이어 분석 요청자가 이해하고 곧이어 액션으로 옮길 수 있도록 해석과 제안을 하는 것까지가 분석!
[CASE 31] 보고서 내용을 정작 분석 요청자가 이해하지 못하고 있다.
보고를 받는 쪽에게 부담을 주는 보고서는 사람을 피곤하게 한다.
- 사실에 관한 의견과 해석에 관한 의견은 같은 줄에 쓰지 않는다.
- 사실 의견과 해석 의견의 글자 색 다르게 한다.
- 사실 의견과 해석 의견을 화살표로 연결한다.
➡️ 3가지 방법 중 구분 가능하도록 쓴다. ⇒ 의견 쓸 때 사실과 해석을 분명히 구분해서 쓰기
이건 보고 나서 바로 보고서 작성할 때 적용하도록 노력하고 있다. (*읽는 이의 입장 배려하기 기본 전제!)
[CASE 32] 보고용 슬라이드에 정보를 너무 많이 넣었다.
- 너무 많은 정보를 담으면 이해하기 어렵고 보고를 하는 자리에서 여러 문제 일으킬 수 있다.
- “심플하게 만들자” 쓸데없는 정보를 과감히 제거하자.
- 의견을 먼저 젛은 후 그에 맞춰 그래프나 표 만들기
- 보고 받는 쪽이 궁금해 할 내용은 엑셀로 표 만들기
최종 결과를 내기 위해 무수한 분석을 했으니 그 내용을 다 담고 싶기도 할 것이고 결론과 간단한 내용만 결과로 내놓으면 논리적 비약이 있는 것 아닌가 싶을 수 있다. 그치만 최종 결과물에 굳이 데이터 분석가의 고민 흔적까지 넣을 필요 없음을 명심하기!
➡️ 간단한 분석 자료를 만들기 연습하자
[CASE 33] 핵심을 놓친 보고서를 만들었다.
- 보고 받는 쪽이 알고 싶어 하는 내용 및 이후 액션 감안할 때 중요한 사항들에 대해서만 이해하기 쉽도록 보고서에 적기
- 보고서 잘 작성하는 tip
- 분석 작업과 보고서 작성 작업 사이에 재충전할 수 있는 시간적 여유 두기
- 보고 받는 쪽이 알고 싶어 하는 내용 종이에 적어보고 충분히 이해하기 쉽게 꼼꼼히 적혀있는 지 보고서 여러번 검토하기
- 분석하면서 고생스러웠던 점을 종이에 적어보고 보고서에 필요 이상으로 과하게 들어가 있지는 않은 지 검토
➡️ 모든 내용을 적을 필요 없다. 2~3줄로 끝나도 된다. 내 고생을 적지 않기
[CASE 34] 거듭 확인했는 데도 보고서에 오탈자나 틀린 숫자가 있었다
분석 결과 숫자, 오탈자 틀리지 말 것, 보고할 때 매끄럽게 설명할 수 있도록 흐름을 갖출 것
내가 많이 약한 부분 “핵심 인사이트만 추려 논리적으로 얘기하기”
[CASE 35] 밤샘 여파로 결과 보고할 때 유의미한 토의를 하지 못했다.
분석 결과의 보고와 토의에 힘 써야 한다. “인사이트 전달”, “액션 도출”에 힘을 쏟자
34~35 의 경우 어찌보면 뻔한 이야기일 수 있지만 중요한 부분! 크로스 체크 / 정합성 체크 또한 분석가에게 있어 중요하다.
✏️ 핵심적인 인사이트 내용만 담고 요청자가 확인하고 싶은 내용만 담자. 모든 것을 담으려고 하다 보면 내용이 산으로 간다.
✏️ 분석 요청자의 핵심 필요사항과 맥락을 파악하여 "분석 방향 기획과 필요성"을 명확히 하는 것도 중요하다.
'Case Study' 카테고리의 다른 글
| 실전 데이터 분석 35 - 필수 데이터 분석을 통해 ROI 높이기 (0) | 2025.08.24 |
|---|---|
| 실전 데이터 분석 35 - 실무에서 분석하는 데에 있어서의 어려움 (0) | 2025.08.20 |
| 내가 보기 위해 정리한 마케팅 용어 (0) | 2021.11.02 |