책:데이터 문해력 독후감

2400·2022년 10월 22일

(인상깊은 내용 나열)

(여기서 "인상깊다"의 의미 : 동의/비동의 의 정도가 크다)

문제 정의 및 가설 수립 -> 분석(스킬) -> 결과 해석 및 스토리 구축

( 대충 스킬적인 부분에 집중하지 말고 문제 정의/가설 수립과 결과 해석/스토리 구축이 포인트라는 내용 )

정확한 문제 정의가 포인트인게 맞다.
복잡한 문제도 단순한 문제(의 합)으로 재구성해서 쉬운 문제를 풀도록 정의를 내리는게 어렵다. 그렇기 때문에 포인트이다.
그러나 여기서 끝나서는 안된다. 문제 정의를 제대로 하기 위해선 정상/비정상을 구분하는 "기준"을 "잘" 잡는게 포인트이다.
결과 해석은 나에게도 어려운 영역이다. 때로는 결과가 모호하게 나오는 경우가 있기 때문이다. 모호한 결과가 분석이 잘못되서라기 보다는 진짜로 모호한 결과일수도 있지 않은가?
다만 결과 해석에서 스토리 라인이 중요한 이유는 다른 사람에게 설득/전파하기 유용한 방법이기 때문이라고 생각한다.
그 스토리가 진짜가 아닐수도 있다. 그러나 스토리와 함께 분석 결과가 공유된다면 청중에게 강력하게 전달된다.

데이터 작업 전에 애당초 무슨 말을 하고 싶은지 생각해보고 데이터 작업을 시작한다.

사실 당연한 말이긴 한데 (그리고 당연히 데이터/도표는 의도적으로 삽입되지 않나?), 때로는 맞기도/틀리기도 한 말이라고 생각한다.
데이터 분석가는 답정너이기 쉽다. 내 뇌피셜과 실제 데이터가 다를수도 있다.
의도적으로 내 뇌피셜을 주장하기 위해 입맛에 맞는 데이터만 추리는게 정말 쉽기 때문이다.

( 든 생각 :

그리고 저자가 제시하는 잘못된 분석의 사례들을 보면 전형적인 타의적인 데이터 분석이다.
자의적인 데이터 분석을 한다면 표/그래프만 나열해놓고 분석했다고 말하지 않는다.
오히려 이런 잘못된 분석 결과를 가져왔다면, 내가 일을 지시한 사람이라면 이 사람이 왜 이렇게밖에 할 수 없었을까?를 생각해봐야하지 않을까?
한편 과거의 나도 표 안에 복잡한 선들이 잔뜩 들어있곤 했는데, 사실 내가 이렇게 여러가지 옵션들을 고려했다고 "자랑"하고 싶은 마음도 있었다.
정확히는 분석의 결과 공유 방법이 잘못된 것이다.
이러한 공유가 잘못됐음을 시행착오를 통해 깨닫고나서야 다시는 이런 짓을 하지 않게 됐다.
)

풀고자하는 문제가 명확하지 않다.

~~이런걸 분석해줘. 라고 했을때 난감할때가 있다.
분석을 요청하는 사람이 본인이 뭘 원하는지 모를때가 있다.
그럴수도 있다. 노하우가 많은 분석가라면 찰떡같이 알아들어야지.
그런데 그 전에 정확한 "문제 상황"이 무엇인지 정의조차 안되어 있다면 심각하다.

문제 주제와 관련되어 있는 데이터를 긁어 모은 다음, 시각화하며 살펴보다 어쩌다 발견한 내용을 긁어 모아서 분석 결과로 마무리된다.

만약 어떤 분석가가 이런 결과를 내놓았다면, 난 안타까울 것 같다.
그 분석가도 어떤 가설을 수립하면서 분석을 진행해봤지만 모든 가설에 부합하는 데이터적 패턴을 찾지 못했을 것이고, 차마 빈손으로 분석 결과를 낼 수 없었던 분석가는 이것저것 데이터를 기워서 결과 분석으로 제출했을 것이기 때문이다.
한편으로 무지성 EDA 를 진행하는 식의 데이터 분석이 존재할 수 있나?라는 나 스스로의 편견이 있다.
분석 경진대회의 결과 공유 코드를 보면 항상 EDA 라는걸 형식적으로, 마치 알록달록 예쁘게 장식용으로만 존재하지 EDA 를 통해 인사이트를 얻어서 분석으로까지 이어진 결과를 잘 못본 것 같다. 사실 한번도 본적이 없는 것 같다.
오히려 분석가 주관에 의한 가설을 수립 후 가설이 맞는지 시각화를 통해 증명/설득하는 사례는 수차례 본 것 같다.
그러나 이러한 가설 수립 -> 분석은 너무 너무 어렵다. 데이터를 봤을때 "노하우/독창적인 아이디어"가 있어야만 ~~한 패턴이 있겠지? 라는 가설을 수립할 수 있기 때문이다.

타 팀/회사의 ~~한 문제가 있다고 했을때 원인/문제를 분리하여 본다.

원인과 문제가 뒤섞여있으면 문제 정의가 어렵기 때문이다.
그리고 전달받은 원인이 진짜 원인이 아닐수도 있다는 식으로 비판적 듣기?는 좋은 아이디어다.
다른 사람이 정의한 문제에 대해, 보자마자 이렇게 생각해본다는 접근을 해본적이 없어서 신선하다.
사실 본격적으로 분석을 진행하면 자연스레 이렇게 쪼개보겠지만, 구두로 전달받는 순간에 이렇게 원인/문제를 분리하여, 나아가서 비판적으로 듣는다는걸 생각해보지 못했다.

여러 잘못된 시각화 사례

내 생각에는 모든 시각화에서 "그래서 어떤게/왜 문제인데?" 라는 질문이 나온다.
자료만 보고도 아 이게 문제네! 라고 (직관적으로) 해석될 수 있게 만들어야겠다고 생각이 든다.

이후 언급되는 여러 문제 상황(결론)과 이를 모니터링할 지표들을 언급한다.

대체로 문제 상황(결론)이 진짜 문제가 맞는지? 비판적 사고를 해야한다.는걸 강조하는 것 같다.
그리고 이를 지표화 했을때 적절한가? 인데, 이를 보다보니 굉장히 세분화된 여러개의 지표가 필요하다.는 결과로 이어질 것 같다.
저자가 설명하는 대로라면 문제 상황을 정확히 명시 -> 이를 표현하는 적절한 지표 생성인데, 문제 상황이란건 매번 새롭게 등장하기 마련이고 그때마다 적절한 지표를 추가해야되는건가? 라는 생각이 든다.
지표는 관리가 가능한 한도 내에서 많을수록/다양할수록 좋은건 맞다.
그런데 관리가 가능한 한도라 어느정도일까?
담당자별로 확인해야하는 지표 수가 10개가 넘어가면 이미 관리가 불가능한 수 아닐까?
따라서 지표에도 선택과 집중이 필요하다.
집중이 필요한 지표라 함은, 과거에도 현재에도 미래에도 모니터링이 꼭 필요한, 불변하게 중요도가 높은 지표일 것이다. 중요도가 높기 때문에 담당자가 스스로 찾아봐야 할 것이다.
시기별로 중요한 지표가 달라질 것이다. 이때는 현 시점에서 집중 관리하는 지표 3개, 꾸준히 모니터링이 필요한 지표 5개면 되지 않을까?
사업의 현 상황을 5개 지표로 표현해야 한다면 어쩔수없이 추상적이고 여러 의미/원인으로 해석될 수 있는 포괄적인 지표가 될 수 밖에 없다는 생각이 든다.

( 든 생각 :

지표를 제공하는 "서비스"가 있다고 할떄, 이 서비스는 상당히 수동적인 서비스이다. 사용자가 직접 지표를 확인하기 위해 찾아와야 하기 때문이다.
그런데 사용자(직원)는 사실 일을 그리 적극적으로 하지 않는다.
그래서 실컷 만들어놓고 방치되는 지표들이 존재하는걸 보게된다.
지표에 이상신호가 발생한다면 이용자에게 강력한 알림을 주는 기능이 있으면 게으른 직원들 또한 문제를 보도록 할 수 있겠다.
그러면 이 서비스는 보다 적극적이게 된다.
그런데 여기엔 적절한 이상신호를 감지하는 규칙/모델이 필요한 단점이 있고, 이러한 규칙/모델은 시간이 지남에 따라 오탐/정탐 수준을 관리한다는 관리 요소가 존재한다.
그러면 또 이를 탐지하는 이상신호 탐지의 이상 신호 탐지 규칙이 필요할 것이다.
)