먼저, 기술블로그와 어울리진 않지만 이 글은 대시보드를 만들기 위한 the Best way는 아닙니다. 대부분이 [김밥 만드는 법] 을 포스팅 했다면, 이 글은 [ 가난한 자취생이 있어보이는 김밥 만드는 썰] 에 가깝습니다.
1편에서는 - 띵동 데이터팀이 ‘왜’ 구글 데이터 스튜디오로 대시보드를 만들게 되었는가? - ‘어떤’ 문제가 있었고 어떤 삽질들로 해결했는가?
2편에서는 - ‘어떻게 ’ 해야 비즈니스 인사이트를 도출하기 쉽게 만드는가? 고민했던 과정들을 풀어나갑니다. 물론 삽질은 나를 강력하게 만들지만, 회사는 나를 기다려 줄 시간이 없거든요… 테크니컬한 부분까지 고려된 화려한 대시보드를 원하신다면 시중에 많은 솔루션이 있으니, 검색을 추천드립니다. (준비물 : 비용을 듣고 놀라지 않을 넉넉한 자본)
[대시보드 =데이터팀의 숙원사업]
데이터팀에 있으면, 아래와 같은 무한 루프를 돌게 됩니다.
> 뫄뫄님, 2019년도 솨솨솨 데이터좀 추출해주세요. > 아 이거 2017년부터 뽑을 수 있나요? > 이거 데이터 양이 너무 많아서 피벗 돌리면 엑셀이 뻗어요 피벗좀.. > 매번 기간마다 요청드리기 좀 그런데, 필터 걸어서 다운받게 해주세요 > 필터에 이것도 추가해주세요 > 데이터가 많아서 한 눈에 보기 힘드네~ 그래프 있으면 좋을 거 같은데?
그리고 여러 부서의 요청을 받으면서, 아래와 같은 문제점을 발견했습니다.
생각보다 많은 사람들이 매일 반복적인 엑셀작업에 시간을 할애한다.
raw-data받아서 함수 돌리다보면 나중에서야 깜빡한 컬럼이 생각난다.
요청자 본인도 정작 어떤 데이터가 필요한지 잘 모른다.
A라는 데이터는 재무팀도 필요하고 영업팀도 필요하다. 그런데 형태가 조금씩 달라서 두 팀 다 같은 데이터로 다른 작업을 하고 있다.
시각화의 힘은 생각보다 강력하다. 하지만 대부분 숫자로 보는 데에 만족한다.
띵동은 이미 빵빵한 raw data를 다운받을 수 있는 웹페이지가 있지만 1,2,3,4의 문제를 해결해주진 못했습니다. 더군다나 비개발자에게 ‘DB에 read only 권한을 드릴게요 직접 쿼리날리세요’ 했을 때는, ‘ 쿼…리?’ 같은 류의 대화가 오갔기 때문에(…) 권한이 있다면 누구나 볼 수 있고, 누구나 다운로드가 쉬운 무언가를 만들어야 했습니다. 이에 정기적으로 요청받은 데이터들을 모아 구글 스프레드 시트에 자동으로 업데이트 해주고, 다운로드 할 수 있게 만들었습니다. (이 방법은 편리하긴 했지만, 엑셀의 최대 행 갯수가 정해져있듯 임시 방편에 불과하고, 누군가는 월별추이를 원하지만 누군가는 일별 추이를 원하는 상황이었기에 모두를 만족시키기 어려웠습니다. )
“왜” 구글 데이터 스튜디오(Google data studio) 로 만들었는가?
프론트엔드 개발자분들의 도움을 받아 시각화를 할 수도 있었지만 [High speed, Low cost] 를 위해서는 데이터를 바로 붙여서 테스트 할 수 있는 솔루션이 필요했습니다. 바로 쓸 수 있는 샘플데이터는 빅쿼리(Big query), GA, 스프레드시트, MySQL 에 있었는데, 마침 이 모든 연결을 가능하게 하는 녀석이 구글 데이터 스튜디오였습니다. 당시 데이터는 최소 일별 추이를 보기 위한 요청이 대부분이어서, 무료임을 감안하면 15분부터 1시간까지 생각보다 빠른 데이터 업데이트 빈도가 매력적이었습니다. 또, 차트를 만들때 쓰인 데이터는 엑셀로 다운로드 받을 수도 있습니다. 게다가 데이터 스튜디오에는 기본적인 그래프 뿐만 아니라, 커뮤니티 시각화 (=제3자 개발자가 개발한 그래프) 라는 예쁘고 효과적인 툴도 사용할 수 있었기 때문에 기본적인 수치를 표현하는 데 부족한 점이 없었습니다.
야심차게 시작했던 띵동 대시보드 초안 1
야심차게 시작했던 띵동 대시보드 초안 2
“어떤” 문제가 있었고 어떤 삽질들로 해결했는가?
솔루션을 리서치할 때, 특히 한글로 된 플랫폼을 사용하신다면 ‘ 약간의 지식만 있다면 Mysql도 쉽게 연결할 수 있더라구요~^^! ’ 같은 글을 대량으로 접하게 됩니다. 하지만 ‘이제부터 각종 에러를 만나게 될테니 마음의 준비를 하시오’ 를 먼저 발견한 사람이 몇이나 될까요? 그동안 마주한 에러만 100개가 넘는 거 같은데, 그 중 문제 해결에 가장 시간을 많이 들인 다섯 가지를 추렸습니다.
1. 2020.03.20(금) 과 2020.03.27(금)은 같은 금요일이 아니다.
띵동의 주문 기반 데이터는 (“YYYY-mm-dd HH:mm:ss”) 같은 datetime을 반드시 갖고있습니다. 이 컬럼 1개로, 일/주/월/연도별 분석 뿐만 아니라 시간, 요일별 분석등에도 활용합니다. 주의할 점은 데이터 소스를 만들때부터 date 필드를 복제해 요일, 시간, 월 같은 필드를 추가하셔야 한다는 겁니다. 예를 들어 [YYYY–mm–dd] 형태의 date필드에, 2020년 3월 20일과 2020년 3월 27일 데이터가 1개씩 존재한다고 가정합니다. 데이터 소스를 만들때부터 date를 카피한 뒤 유형을 ‘요일’로 바꾸시면 3월 20일도, 3월 27일도 같은 ‘금요일’로 인식해서 금요일의 데이터가 2개로 count 됩니다. 그런데 이를 무시하고, date만 가져와서 나중에 date의 측정기준을 ‘요일’로 바꾸시면 이때 요일은 20200320 1개 , 20200327 1개를 뱉습니다.
date의 유형을 시간으로 바꾸면 벌어지는 일
뿐만 아니라 DB에서 굳이 weekday를 분리하여 저장했다면, weekday 컬럼을 가져오실 필요가 없습니다.(아니 안돼 하지마세요) 여러분이 Node.js로 weekday를 가공하셨다면 일요일부터 0,1,2,3..을 출력하겠지만, 파이썬의 weekday function은 월요일부터 0,1,2,3..을 출력합니다. (구글 데이터 스튜디오는 일요일이 0입니다.) 이쯤 되면 별거 아닌데 헷갈리기 시작합니다.
2. 한국인은 한글 데이터를 1개쯤은 갖고 있다.
제가 영어를 하나도 모르는데, 미국에 여행을 갔습니다. 쇼핑을 합니다. 여행 영어책을 보고 한글발음으로 써진 ‘하우 머치?’ 말할 수는 있는데, 상점 주인이 ‘two hundreds’ 라고 하면 저는 못알아 들을겁니다. 마찬가지로 대시보드를 열었는데 꿹띍딃땳뛝 을 보고 싶지 않다면, 인코딩 문제를 짚고 넘어가야 합니다. (이 문제는 여러분이 연결할 데이터가 Google 스프레드시트에 있을때는 생기지 않습니다. ) 얼마 전, 스프레드시트에 저장한 지역주문 데이터가 대시보드에 잘 붙는지 확인한 뒤, MySQL로 그대로 옮겼습니다. 그리고 필터에서 ‘경기도’ 만 선택해 검색했습니다. 어떻게 됐을까요?
공허한 내 마음처럼 텅 빈 그래프(…)
데이터 스튜디오는 MySQL에 있는 한글 value를 못읽습니다. 아니 정확히 말하면 필터가 없다면 읽기는 해서 보여는 줍니다만, ‘경기도’에서 발생한 데이터만 가져와~ 하면 ‘경..기…도? 아몰랑!’ 하는 거죠. 이 문제는 테이블의 캐릭터셋을 바꾼다고 해결되지 않았습니다. 덕분에 저 뿐만 아니라 CJK 유저들(중국어,일본어,한국어) 과 전 세계 각국의 친구들이 공통적으로 유리멘탈이 되는 포인트로 남아있죠. 남의 집 불구경 1>> Accents and Latin Characters in Google Data Studio 남의 집 불구경 2 >> Filter control doesn’t work when I use data in another language instead of English.
이 문제는 데이터팀에 전다정팀장님이 간단히 해결해 주셨는데, 바로 ‘데이터 혼합’입니다. 데이터를 전처리 할 때 테이블끼리 join을 하는 것 처럼, 스프레드시트에 기본적인 한글 index를 넣어놓고 MySQL에 있는 value를 읽을 수 있도록 같은 key로 혼합을 해주는거죠. 스프레드시트의 힘을 빌려야 했지만, 이 방법은 죽어가는 저를 수렁에서 건져준 획기적인 아이디어였습니다.
유레카를 외친 데이터 혼합기능
3. 모바일, 외부환경에서 볼 거라면 커뮤니티 시각화는 쳐다보지도 말자
매번 링크를 타고 대시보드를 확인할 수는 없기에, 완성된 대시보드는 전 사원이 접속하는 TMS(transport management system,배송관리시스템) 에서 확인할 수 있도록 프론드 엔드 개발자님께 요청드렸습니다. 그런데 조심스레 저에게 오셔서 한 마디 하시기를,
“다솔님! 다 했는데, 커뮤니티 시각화는 삽입된 보고서에 표시할 수 없대요ㅎㅎ”
뿐만 아니라, 전달된 링크를 모바일에서 클릭하면 커뮤니티 시각화 도구로 만든 그래프도 마찬가지로 보이지 않았습니다. 이 도구를 잘 이용하면 Gantt chart부터 Heat map, Hexbin map, Radar chart 까지 효과적인 전달(이라 쓰고 ‘간지나게’ 라고 읽음) 이 가능합니다만, 보고서를 외부 환경에 삽입하거나 모바일에서 볼 경우는 확인이 되지 않습니다.
아직도 너무나 아까운 Hexbin map…. [출처 : DSCV Hexbin Map — Usage Guide]
4. 이 중에 네가 쓰는 DB가 무엇이냐?
데이터 소스를 만들기 위한 Google 커넥터
띵동의 메인 데이터는 대부분 Amazon S3, MongoDB 에 들어있습니다. 하지만 둘 다 구글 데이터 스튜디오에서 연결을 지원하지 않습니다. 결국 MySQL에 있는 데이터를 연결하는게 아니라, 대시보드를 위한 데이터 웨어하우스로 MySQL을 사용하는 상황이 되어버렸습니다. 이 때 멈췄어야 할까요? 이 부분은 아직도 의견이 분분합니다. 자체 개발을 하게 되었을 때 들어갈 프론트 개발자님들과 데이터팀의 공수를 생각하면 지금도 이 방법을 선택한게 더 잘 한 일 같고, 좀 더 테크니컬하게 풀어간다면 누군가는 왜 DB 연결도 안되는 구글 데이터 스튜디오를 써야 해? 라고 생각할 수도 있기 때문입니다.
5. 당신의 직무를 고르시오. (1) 개발자 (2) 디자이너 (3) 분석가
보통 분석가가 ‘중요한 데이터를 어떻게 효과적으로 보여줄 건가?’ 에 집중한다면, 대부분의 뷰어들은 ‘이쁘냐?’에 집중합니다. 실제로 -컬러가 너무 강하니 파스텔톤을 톤온톤 해서 쓰면 좋겠다-는 피드백을 받고 수정했을 때, 영업팀에서는 -점주님들께 문의가 오면 빨간색이 뭐고, 파란색이 뭔지 안내를 해야하는데 색이 같은 톤이라 설명하기 어렵다-는 피드백이 있었습니다.
출처 : 블로그 — 네이버
‘예쁜’ 과 ‘효과적’ 은 이렇게 거리가 먼 단어입니다. 심지어 예쁜 기준은 보는 사람마다 매우 다릅니다. 따라서 대시보드를 만드신다면 처음부터 컬러에 공을 들이지 않기를 추천합니다. (어차피 바꾸게 되어있습니다..) 주요 타겟뷰어가 누구인지를 설정하고, 그 타겟이 알아보기 쉬운 컬러를 사용해 표현하는 데 중점을 두시는 것이 좋습니다.
컬러에 대한 감을 잡기 어려우실 때에는 아래를 활용하시면 좋습니다. (클릭하면 링크로 이동합니다) - 이미지를 넣으면 컬러팔레트를 추출해주는 TinEye - 다양한 컬러 팔레트를 보유하고 있는 pinterest - 구글데이터스튜디오 ‘이미지에서 테마 추출’ 기능 사용하기
원하는 이미지를 넣으면, 테마를 추출해줍니다
[ ‘어떻게 ’ 해야 비즈니스 인사이트를 도출하기 쉬울까? ]
아이디어 스케치를 하면 생기는 일.png
막막했던 아이디어 스케치를 효과적으로 끝냈던 방법
팀리더 피드백 미팅에서 가장 많이 나왔던 요구사항
차트를 보기쉽고 전달력있게 개선했던 경험
등은 2편에서 이어집니다.
가입하기
