[분석] 대시보드를 만드는 과정과 그 속의 고민들
by 소라고동_데이터 분석가 직군과 떼어낼 수 없는 업무 중 하나가 대시보드를 만들고 관리하는 것인데요.
이번 포스팅에서는 대시보드를 만드는 과정에 대해서 정리를 해보고, 그 과정에서 고민했던 내용들을 함께 정리해보려 합니다.
0. 들어가며
작년 12월, 갑작스러운 인사발령으로 인해 회사 내 다른 본부로 조직이동을 하게 되었는데요.
기존엔 상품, 공급사에 대한 분석 및 마진 지표를 살펴보았다면 팀이 바뀐 뒤에는 고객에 대한 분석과 지표들을 바라보게 되었습니다.
즉, 하는 일은 유사했지만 분석의 도메인이 조금 바뀐 것이죠.
처음에는 '어차피 같은 회사 안이고 하는 일이 비슷하니깐 어렵지 않게 업무를 할 수 있겠지?'라는 생각을 했었는데요.
업무를 받아 조금 일을 해보니 다른 회사에서 근무를 하는 것 같이 업무가 낯설더라고요.
이런 상황에서 대시보드를 만들어달라는 요청을 받게 되었고, 이 작업을 하면서 기존의 부서에서 대시보드를 만들었던 기억을 살려 대시보드를 구성했습니다.
그런데 만드는 과정에서 소통을 하다 보니 새로운 부서에서 기대하는 대시보드의 형태가 기존의 부서와는 약간의 차이가 있음을 깨달았습니다. (대시보드의 구성, 시각화 방식 등)
이런 과정을 겪으면서 '지금 상황이 새로운 회사에 들어가서 처음 대시보드를 만들게 된 분석가가 된 기분인데?'라는 생각이 들었고,
언제가 될 진 모르지만 그런 경우가 찾아왔을 때의 스스로의 가이드라인을 만들어놓자는 생각이 들었습니다.
그래서 아래와 같은 분들이 이번 글을 읽으면 좋을 것 같다고 생각이 됩니다.
- 새로운 회사에서 대시보드를 만들어야 할 때 어떻게 하면 좋을지 고민이 되는 분석가
- '분석가들은 어떤 생각/과정으로 대시보드를 만들까?'라는 부분이 궁금한 대시보드 요청 부서
1. 대시보드를 만드는 과정
제가 겪어왔던 경험들을 떠올리며 대시보드를 만드는 과정과 그 속에서 고민했던 내용을 차근차근 정리해 보겠습니다.
지금부터의 내용들은 제 경험들을 통해서 작성된 부분이라 읽으시다 더 좋은 방법이나 과정이 있다면 언제든 댓글 부탁드립니다!
1) 대시보드 필요성 대두
당연한 이야기지만 대시보드가 필요한 상황이 생기거나, 누군가가 대시보드 제작을 요청하는 경우 대시보드 만들기 과정이 시작됩니다.
그런데 대시보드를 요청하는 주체에 따라서 대시보드 제작에 드는 리소스 및 마음의 피로도가 조금씩 달라지는데요.
제가 경험 한 대시보드 요청 주체들의 특징을 아래와 같이 정리해 보았습니다.
< 대시보드 요청 주체별 특징 >
자체 제작 (= 팀 내에서 분석에 필요한 대시보드를 자체적으로 제작하는 경우)
특징
- 대시보드의 목적, 주요 지표, 대시보드 차트의 형태 등이 어느 정도 머릿속에 그려져 있음
- 즉, '대시보드를 구성한 사람 = 작업자'라서 두 주체의 싱크를 맞추는 과정이 생략됨 (비교적 빠르게 작업이 진행)
타 팀 요청 (= 대시보드가 필요한 타 팀에서 대시보드 제작을 요청하는 경우)
특징
- 자체 제작과 달리 대시보드의 목적, 주요 지표 등 작업의 싱크를 맞추는 과정이 필요 (중요)
- 싱크를 맞추는 과정에서 어떤 부분까지 가능한지에 대한 여부를 설명하고 작업의 적정선을 찾아야 함
- 작업 중간중간에 소통을 하기가 비교적 편하기 때문에 빠른 피드백 요청이 가능
- 소통이 생각보다 많이 이루어지기 때문에 타 팀 분들과 친해질 수 있는 장점(?)
경영진 요청 (= 경영진분들이 급하게 지표 확인이 필요한 대시보드 제작을 요청하는 경우)
특징
- 지표에 대해 익숙하고 바라보는 방법을 누구보다 잘 알기 때문에 오히려 간단한 대시보드가 만들어지는
경우가 많음 (다만 빠르게 완성이 되어야 함)
- 간단해 보이지만 동시에 살펴보기 어려운 구성이나 지표들을 하나의 대시보드에 넣어달라고 하는 경우도 있음
- 너무 바쁘셔서 중간중간 소통이 어려워 답답한 경우가 많음
이렇게 대시보드가 필요한 상황이 생기면 요청 주체에 따른 마음의 준비를 하고 다음 단계로 넘어갑니다.
2) (중요) 요청자와 작업자의 생각의 싱크 맞추기
마음의 준비를 하고 나면 실행 단계로 넘어가게 되는데, 이 단계에서의 핵심은 요청자와 작업자의 생각의 싱크를 맞추는 것입니다.
특히 타 팀에서 요청을 주는 경우에 이 과정을 활발하게 할 수 있는데요.
위에서 언급했듯,
- 자체 제작의 경우 내 마음속 요청 내용을 내 손이 작업하기 때문에 이 과정이 필요 없고,
- 경영진의 요청은 단순한 대시보드를 만드는 경우가 많았기 때문에 이 과정의 비중이 비교적 적었습니다.
그러니 앞으로의 내용은 타 팀 요청에 대한 상황을 위주로 글을 이어가겠습니다.
보통 요청을 주실 땐 대시보드에서 보고 싶은 지표들을 리스트업 하거나 예시 차트를 가져와 대시보드 기획안을 구성한 뒤 미팅을 하게 되는데요.
미팅을 통해 아래와 같은 내용들을 위주로 소통을 하게 됩니다.
1. 기획안의 내용 중 가능한 범위 소통
- 요청하는 내용 중 데이터 및 대시보드 툴의 관점에서 작업이 가능한 범위에 대한 안내
→ 대시보드로 구현할 경우 날짜 및 시간, 여러 필터를 염두하고 작업 가능 여부를 생각하는 것이 필요
→ 지표 집계를 위해 배치를 돌릴 때 문제가 없는지 생각하는 것이 필요
2. 필요한 테이블에 대한 소통
- 대시보드 제작 시 익숙하지 않은 테이블을 사용해야 하거나 도메인이 부족한 경우 오히려 질문을 드리는 경우도 존재
(해당 데이터를 보고 있는 테이블이 있는지?, 없다면 유사한 내용을 다룬 대시보드가 있는지?, 그 대시보드는 누가 만들었는지?, 그 테이블 정의서가 있는지? 등)
3. 대시보드 목적에 맞는 지표 및 관점에 대한 소통
- 대시보드 목적에 대해 이해하고 목적에 맞지 않는 지표는 제외, 필요한 부분은 추가, 중복되는 부분은 통합하는 과정 진행
(대시보드의 목적을 흐리게 하는 지표, 차트는 최대한 지양하는 것이 좋다고 생각)
위와 같은 내용들을 미팅을 하며 협의하게 되는데요.
사실 경험상 한 번의 미팅으로 위 내용들 전체를 정확하게 협의하기가 어려웠어서 어떻게 하면 미팅에서 최대한 많은 부분을 이야기할 수 있을지를 고민했고, 지금은 아래의 질문에 대해 정리하고 소통을 하고 있습니다.
해당 대시보드 뷰를 만들기 위해서는 어떤 데이터 레이아웃이 있어야 하지?
쉽게 말하면 '이 요청사항을 데이터로 구현하려면 어떤 모습의 테이블이 갖춰져 있어야 작업이 가능할까?'를 생각하는 방법이고,
이렇게 구체화해서 생각을 하다 보면 머릿속으로만 생각할 때 보다 보다 구체적으로 작업 방식 및 가능 여부를 확인하기 좋더라고요.
물론 이렇게 해도 놓치는 부분이 있을 수 있기 때문에 그런 부분들은 작업 도중에 소통을 하면서 맞춰나가면 된다고 생각합니다.
이 과정에서 막막함을 느낄 때
그런데 이렇게 미팅을 하고 나서도 낯선 지표나 데이터를 다루게 되면 작업에 있어 막막함을 느끼는 경우가 있었는데요.
저도 이번에 부서 이동 후 대시보드를 만들 때 이러한 막막함을 느꼈어서 '내가 이런 감정을 왜 느끼고 있지?'라는 고민을 해봤습니다.
그랬더니 아래와 같은 이유들로 정리가 되더라고요.
낮은 데이터 이해도
문제 : 테이블(데이터)에 대한 이해가 낮아서 어딜 어디서부터 건드려야 할지를 모르겠다.
해결책
- 테이블 정의서가 있는지 찾아보거나 해당 테이블을 활용해서 작성한 쿼리를 들여다보면서 테이블을 이해도를 높인다.
- 해당 테이블을 활용해서 작업을 했던 사람이 있다면 그 사람에게 물어본다.
(궁금한 내용을 잘 정리해서 '제가 생각한 건 이런데 맞나요?'라는 방식으로 물어본다.)
- 해당 테이블로 어디까지 가능하고 불가능한지를 파악한 뒤 추가로 필요한 데이터 작업만 진행하여 작업을 효율화한다.
낮은 도메인 이해도
문제 : 각 지표들의 의미를 잘 모르겠고 어떻게 계산되는지에 대한 이해도가 낮다.
해결책
- 먼저 요청한 대시보드 구성안에 들어있는 용어들을 정의하고 지표들의 정의를 해본다. (계산식도 적어본다)
- 그 내용이 맞는지 요청자와 맞춰보고 추가적인 의미, 지표를 활용하는 방식 등을 물어보고 이해한다.
- 즉, 지표의 위계 (메트릭 하이라키)를 파악해 본다.
나약한 마인드
문제 : 낯선 지표들을 보고 패왕색에 눌린 듯 기가 죽어있다.
해결책
- 이 마인드로는 상황이 해결되지 않음을 인지하고 위 문제들을 하나씩 해결해 나간다. (모르기 때문에 무서운 것이니깐)
막막함을 해소하기 위해서는 대시보드에 필요한 데이터와 지표들에 대한 높은 이해도가 중요하다는 것을 느꼈습니다.
3) 쿼리 작성하고 틀 구성하기
이렇게 싱크를 맞추고 지표에 대해 이해하는 과정을 겪고 나면(사실 동시에 진행되는 경우가 많았습니다) 필요한 쿼리를 작성하고 대시보드 틀을 구성하게 됩니다.
이 작업을 할 때 제가 주로 사용하는 순서는 아래와 같은데요.
- 구성안을 보고 필요한 데이터를 추출하는 쿼리를 작성한다.
- 해당 쿼리의 결과물로 우선 대시보드 화면을 구성해 본다.
- 대시보드 화면을 요청 부서와 함께 보면서 시각화 방식이나 화면 구성 등의 피드백을 주고받는다.
- 피드백이 이루어진 뒤 필요한 테이블 배치를 돌려 대시보드용 테이블을 만든다.
- 최종적인 대시보드 화면을 만들어낸다.
위와 같은 순서를 선호하는 이유는 처음 요청을 줄 때 작성해 주셨던 대시보드 기획안에서 수정되는 부분이 많기 때문인데요.
보통 처음에 대시보드 구성안을 기획한 요청부서에서도 실제로 만들어진 대시보드 화면을 보면 추가/제거할 부분이 생기더라고요.
그래서 최소한의 결과물 (= 쿼리를 이용해서 만든 예시 대시보드 화면)을 통해 피드백을 진행하고 완성된 뷰에 맞는 쿼리를 테이블로 배치 돌려 동일한 작업을 최소화하는 것이 좋아 보였습니다.
그리고 대시보드 툴에 따라 추가적으로 필요한 컬럼들이 있을 수 있어서 일단 데이터로 대시보드 화면을 구성한 뒤 최종 컬럼들을 확정하고 배치를 돌리는 것을 추천합니다.
- (예시) 사용하는 대시보드 툴에서는 누적합 기능을 제공하지 않을 경우, 따로 컬럼을 만들어서 작업을 해줘야 하는 식의 경우가 발생함
4) 값 검수하기
이렇게 테이블 배치를 돌리고 대시보드 화면을 구성하고 나면 배포를 하기 전 검수 과정을 거쳐야 하는데요.
검수는 보통 값 검수와 기능 검수 이 두 가지의 부분을 확인하는 것으로 진행을 했습니다.
< 값 검수 >
목적 = 대시보드에서 표출되는 값들이 정확한 값인지를 확인하기 위함
방식
- 대시보드 전체를 천천히 살펴보면서 사용자 입장이 되어 지표를 음미(?)해본다.
→ 유사한 지표를 다루는 대시보드나 분석 결과물이 있다면 해당 값들과 대시보드의 값을 비교해 본다.
→ 달성률이나 기간 비교를 하는 View 가 있다면 살펴보고 제대로 계산이 되어있는지 확인해 본다.
→ 집계 기간이 다른 값들(일자별 집계치와 월 집계치 등)을 살펴보며 값이 잘 못 계산되어 있지 않는지 확인해 본다.
< 기능 검수 >
목적 = 대시보드의 여러 필터 기능들이 제대로 작동하는지 살펴보기 위함
방식
- 필터나 여러 기능들을 하나씩 눌러보며 잘 작동을 하는지 확인해 본다.
→ 기간 필터를 바꿔가며 기간에 맞는 지표들이 나타나는지 확인해 본다.
→ 체크박스를 선택했을 때 선택한 부분에 대한 지표들이 잘 나타나는지 확인해 본다.
5) 대시보드 가이드라인 작성하기
대시보드를 만들다 보면 해당 대시보드에 들어가는 지표와 구성, 기능들이 제작자 입장에서는 너무나도 익숙한 상황이 되어버립니다.
그래서 '당연히 이 부분을 잘 이해하고 활용하겠지?'라는 생각이 들 수 있는데요.
실제로 사용하는 사람의 입장에서는 처음 보는 대시보드가 나왔고 이 값들을 어떻게 바라봐야 할 지에 대한 막막함을 느낄 수 있습니다.
그렇기 때문에 이 간극을 줄여주기 위한 대시보드 가이드라인이 필요한데요.
저의 경우엔 보통 아래와 같은 정보를 적어주는 편입니다.
- 각 페이지의 목적 (요청부서 외의 다른 부서에서도 대시보드를 볼 수 있기 때문에)
- 페이지별 세부 정보
- 데이터 업데이트 주기
- 들어있는 지표들의 정의 및 계산식
- 각 지표 활용 예시 (이 지표를 보고 어떤 액션을 할 수 있는지?)
- 활용 시 유의해야 할 부분
- 사용한 데이터 소스
위 내용을 누군가에게 설명을 해준다는 생각으로 최대한 상세하게 작성합니다.
6) 마지막으로 요청 부서에게 검수 요청하기
대시보드를 만들고 검수를 한 뒤 가이드라인까지 작성을 하고 나면 최종적으로 요청 부서에게 검수 요청을 하게 되는데요.
요청 부서에서는 해당 도메인에 대한 이해도가 훨씬 높기 때문에 제가 놓친 이상한 값이나 잘못 정의된 지표를 더욱 빠르고 정확하게 발견할 수 있기 때문입니다.
그리고 조금은 다른 이야기지만 개인적으로는 이렇게 대시보드를 만들어가는 과정을 함께 하면서 함께 대시보드를 만들어간다는 느낌을 주는 것이 좋아 보이더라고요. (실제로도 좋은지는 아직 잘 모르겠습니다.)
그렇게 되면 사용자의 대시보드 이해도도 높아지고, 대시보드에 보다 애착을 가지게 되어 대시보드를 잘 살펴본다는 느낌이 있었기 때문입니다.
대시보드는 결국 사용자가 많이 봐주고 그 대시보드를 통해서 액션이 이루어져야 제대로 활용이 되는 것이니깐요.
7) 배포하기
지금까지의 과정을 통해서 대시보드를 배포하고 나면 사실상 대시보드 제작 과정이 완료되었다고 생각할 수 있습니다.
그 후에는 대시보드의 배치가 잘 돌아가고 있는지를 확인해 주면 대시보드를 안정적으로 운영해나가게 됩니다.
8) 활용도 조사하기 (고민 중)
위의 과정에 따라 대시보드를 제작하고 배포하고 나면 작업이 완료되는 것이긴 한데, 요즘에는 어떻게 해야 사람들이 이 대시보드를 더 잘 활용할 수 있을까?라는 고민이 생기더라고요.
열심히 대시보드를 만들어뒀는데 사람들이 잘 사용하지 않는 것만큼 아쉬운 경우가 없고, 이런 경우엔 보는 사람도 없는데 유지보수는 계속해야 하는 그런 비효율이 발생했습니다.
그래서 대시보드를 배포하고 나서 일정한 기간이 지난 뒤 사용 부서에 간단한 설문을 진행해 보는 식으로 활용도를 조사하는 것도 좋겠다는 생각이 들더라고요.
구체적으로 생각한 부분은 아직은 없지만 '대시보드 활용도 파악'이라는 목적을 달성하기 위한 아래와 같은 질문들을 구글폼으로 만들어 뿌려보면 어떨까?라는 생각을 하고 있습니다.
- 대시보드를 사용하는 주기
- 가장 많이 보는 페이지 / 잘 보지 않는 페이지
- 대시보드를 사용하면서 좋았던 기능 or 뷰 / 아쉬웠던 기능 or 뷰
- 이 대시보드를 보고 실제로 어떤 의사결정 및 액션을 진행한 적 있는지?
- 더 추가되면 좋겠다는 기능
- 등등...
물론 바쁜 업무 속에서 이런 설문을 잘해줄지는 모르겠지만, 그래도 일단 시도해 볼 가치는 있어 보여서 조금 시간이 지난 뒤 시도해 볼 생각입니다.
2. 끝마치며
이렇게 대시보드를 만드는 과정에 대해서 정리를 해봤는데요.
정리를 하면서 드는 생각은 크게 두 가지였습니다.
1) 대시보드는 요청자와 제작자가 같이 만드는 것
대시보드를 만들다 보면 요청자는 요청자이고 제작자가 대시보드를 만들어나가는 작업이라는 생각이 들기 쉬운데요.
대시보드는 주로 요청자가 활용하기 때문에 요청자와 함께 대시보드를 만든다는 생각으로 작업을 진행해야 한다는 생각이 들었습니다.
그리고 이 과정은 서로의 부족한 부분을 보완하는 과정이라는 생각이 들었습니다.
- 제작자 = 부족한 도메인과 지표를 바라보는 관점을 배우는 과정
- 요청자 = 부족한 데이터 핸들링 부분을 요청을 통해 채워나가는 과정
즉, 대시보드를 만드는 것은 요청자와 제작자가 각각 부족한 부분을 메꿔서 만드는 공동작업이라는 것
2) 대시보드는 액션의 근거자료가 되어야 한다는 것
대시보드를 만드는 목적은 주요 지표를 트래킹하고, 그 지표들의 변화를 통해 어떠한 액션을 하기 위함인데요.
그렇기 때문에 누군가가 '이런 지표를 보고싶어서 요청드려요!' 라고 한다면 '이 지표를 통해 어떤 액션을 기대하나요?' 라는 질문으로 대시보드의 목적을 명확히 해야하고,
'그 목적을 이루기 위해서는 어떻게 지표를 시각화해서 보여주는 것이 가장 효율적일까?' 라는 고민을 하며 작업을 해야한다고 생각합니다.
즉, 각각의 화면이 어떤 의의를 가지는지, 이 화면을 보고 어떤 의사결정을 할 수 있는지? 에 대한 고민을 하며 대시보드를 만들어야한다는 것
이렇게 이번 포스팅에서는 대시보드를 만들어나가는 과정과 그 속에서의 고민들을 정리해보았습니다.
읽어보시다 의견 있으시면 댓글 부탁드려요!
감사합니다.
'#2 분석 노트 > #2.1. 분석 방법 및 개념' 카테고리의 다른 글
[분석] 분석 결과를 빛내주는 사소한 요소들 (2) | 2024.03.17 |
---|---|
[분석] 데이터를 접할 때 우리가 갖춰야 할 몇 가지 자세 (0) | 2024.03.03 |
[분석] 대시보드용 데이터 마트로 리포팅하기 (3) | 2023.06.18 |
[분석] 회귀분석으로 의사결정을 도와보기 (4) | 2023.06.04 |
[분석] 논리력을 기르는 다양한 방법 중 하나 (4) | 2023.05.21 |
블로그의 정보
고동의 데이터 분석
소라고동_