안녕하세요 하용호입니다. 데이터로 일하는 과정을 하다보면, 대시보드를 만들어야 할 일이 종종 발생합니다. 세번째 온라인 시간에 말씀드렸던 데이터팀의 진화과정 Passive LV1,2,3 Active LV1,2 과정에서 Passive LV2에서 보통 대시보드로 일을 하게 됩니다. (데이터팀의 진화과정은 원하시는 분들이 있어서 다시 하나의 글로 정리하겠습니다)

데이터팀 Passive LV2 에서는

의 상태에 이르러 있습니다.

물론 이 때, 끊임없는 요청들을 대시보드에 추가하느라, '대시보드 지옥'에 시달릴 공산도 있습니다만, 뭐 그래도 필요한 과정이긴 하죠. 오늘은 그런의미에서 대시보드 작성의 기준들을 이야기해보겠습니다.

누가 볼 대시보드를 만드는가?

많은 회사들이 대시보드를 만들곤 합니다. 제가 SKT 있을때도 만들었고, 카카오 있을 때도 만들었는데, 그 두가지 대시보드의 양상이 매우 달랐습니다. 동시에 좋은 대시보드란 무엇인가에 대한 나름의 기준을 세울 수 있었습니다.

대시보드의 성격을 가르는 가장 첫번째는 **'누가 볼것인가?'**를 정하는 것입니다. 이것을 통해, 대기업형 대시보드와 스타트업형 대시보드가 갈립니다.

대기업형 대시보드는 대체로 임원분같이 높으신 분들이 보시는 물건입니다. 이것은 대체로 **'결과'**가 주로 보입니다. 그리고 여러화면으로 나뉘기 보다는 가능하면 한하면에 다 담기를 원합니다. 큰 기업의 임원분들은 실무를 잘 모르며, 사실 알 필요가 없기도 합니다. 대시보드의 숫자를 보고 '매출이 왜이렇게 안좋아? 이유가 뭐야?'하고 아래를 잡아 족치면 됩니다. 그리고 이러한 대시보드는 사실 이것 자체로 매일 볼 필요가 그닥 없기 때문에 (역동적이지도 않고 재미도 없습니다) 곧 임원에게도 버려집니다. 결국 아무도 보지 않는 시스템이 되고 맙니다.

그에 비해 스타트업형 대시보드는 조금 다릅니다. 이것을 보는 사람은 실무자들입니다. 이 사람들이 출근해서, 오늘 내가 뭘해야 하지? 라는 발견을 하기 위해서 쓰입니다. 때문에 결과보다는 변화량에 초점을 맞춥니다. 성장을 확인하고 문제를 발견할 수 있게 디자인되어야 합니다. 세세한 변화를 눈치채기 위해서는 대시보드가 한화면에 다 들어가서는 쉽지 않습니다. 때문에 훨씬 더 자유롭게 여러개의 화면으로 만든 대시보드를 운영하게 됩니다. (물론 전부 총집합하여 한번에 이상을 탐지하기 위한 overview는 하나정도 있어야 하긴 합니다)

대시보드 설계를 위한 원칙들

대시 보드 설계에 앞서, 지키면 좋을 원칙들을 몇가지 나열해 보겠습니다.

  1. 한 화면을 인식하는데 5초 이상 걸리면, 잘못 만든 대시보드다. 대시보드의 목적은 문제의 발견입니다. 문제가 있는지 없는지 5초만에 발견되지 않는다면, 해당 화면은 너무 많은 정보를 담고 있거나, 초점이 잡히지 않은 것입니다. 여러개의 페이지로 구성되어도 되니, 적어도 한 페이지 안에서는 5초안에 결론을 낼 수 있게 구성해야 합니다.
  2. 한 화면 안에서 구성은 이상유무(Indicators), 근거(Trends), 백데이터(Details)로 구성한다. 어찌보면 오늘 가장 강조하고 싶은 부분이 2번입니다. 대시보드의 여러 블럭들은 단지 예쁘게 표시되는게 중요한게 아니라, 문제의 발견→확인→실마리파악 의 일하는 과정을 돕기 위해 만들어져야 합니다. 때문에 위에서 아래로 크고 중요한 것들 부터 자잘한 것들 순으로 나열되야 합니다.

보통 역피라미드 구조라고 말합니다. 제일 상단에 이상이 있는지 없는지를 간단한 색 인디케이터로 표시하거나, 가장 큰 KPI의 숫자와 변화량만 표시해서 빠르게 캐치할 수 있게 해줍니다.

중간 섹션에서는 왜 위의 결과인지를 표현해주는 트랜드 여러 핵심 KPI들의 '그래프'가 들어가면 됩니다. (디테일한 숫자는 더 아래로 미룹니다)

가장 하단 섹션에는 세세한 지표들의 트랜드 그래프를 백데이터로 제공해줍니다. 개별 숫자 그리드의 경우는 있어도 되고, 없어도 됩니다. 어차피 실무를 하려면 디테일한 숫자는 내가 직접 봐야하기 때문에, 대시보드에서 모든 문제를 다 볼 수 있게 굳이 숫자 그리드까지 들어갈 필요는 없습니다. (번잡해질 수 있습니다)

![<https://s3-us-west-2.amazonaws.com/secure.notion-static.com/cb07f62f-d7e4-4129-a13a-e17834084edf/Untitled.png>](<https://s3-us-west-2.amazonaws.com/secure.notion-static.com/cb07f62f-d7e4-4129-a13a-e17834084edf/Untitled.png>)
  1. 데이터는 반드시 지난 기준 (전주 or 전달) 대비, 몇 %의 증감이 같이 표시되야 한다. 대시보드의 목적은 많은 사람들이 한눈에 결과를 알기 위해서 입니다. 대시보드에 표현되는 숫자가 절대값인 경우 (예를 들어 오늘 매출 1500만원) 이 것이 적절한 숫자인지, 나아지고 있는지, 나빠지고 있는지 즉각적으로 알기 어렵습니다. 때문에 숫자는 반드시 상대값 (전주 대비 5% 증가, -3% 감소) 이 표시되어야 합니다. 이런 숫자들을 보아야, 현업이 '어 저건 왜 저렇지? 바로 움직여야 겠다' 라는 마음이 생기며, 동시에 매일 보게 되는 대시보드가 됩니다.
  2. 대시보드의 갱신 주기는 빠를수록 좋지만, 액션주기보다 빠를 필요는 없다. 대시보드가 얼마나 자주 갱신될것인가도 중요합니다. 당연히 실시간이 가장 좋고, 일배치가 안좋겠습니다만, 이상 수치를 보고 회사가 대응할 수 있는 액션의 주기가 일단위라면 실시간 시스템이 의미가 없어지겠지요.

외부 플랫폼을 쓰지 않고, 자체적으로 데이터 파이프라인을 구축하고, 대시보드를 만들게 될 경우, 데이터의 갱신주기는 하루보다는 짧은 N시간을 첫번째 목표로 잡는게 좋습니다. (적어도 업무시간중 2번은 업데이트) 처음부터 일배치로 대시보드를 만들겠다고 결정하면, 데이터 파이프라인의 많은 부분들이 일배치 기준으로 작성되게 되는데, 일 해상도를 시간 해상도로 바꾸는 작업은 대체로 완전 개변에 가까운 작업이라 일을 2번하게 되는 경우가 많습니다. 때문에 초기부터 앞으로 회사의 데이터 주기가 짧아진다고 했을 때도 대응할 수 있게 구축하시는 편이 좋습니다.

대시보드로 발견할 수 있는 문제의 발견속도는 갱신주기 * 2배수 시간 정도입니다. 예를 들어서 6시간 시스템의 경우는 보통 문제의 2배수인 12시간 뒤에 발견되곤 합니다. 12시간 정도면 너무 느리지 않게 어떤 이슈들을 고칠 수 있으리라 판단합니다. 물론 차츰 1시간 또는 준 실시간으로 고쳐가는 것이 필요하겠지요

시간이 지나면 대시보드의 주기가, 현업의 업무주기를 앞당겨주는 현상도 발생합니다. 예를 들어 우리 주식시세를 보는 것도 어떤 의미에서 대시보드라고 할 수 있습니다. 만약 내 휴대폰 주식 프로그램이 하루에 한번만 주가를 업데이트 한다면 우리는 주식을 하루에 한번만 사게 될겁니다. 그런데 이게 실시간으로 업데이트 되다보니, 하루에도 몇번씩 들여다보고, 주식을 샀다 팔았다 하게 되죠. 업데이트의 주기가 업무의 주기를 견인하는 예입니다. (그나저나 어제 미국 주식이 떨어져서 슬픕니다ㅠ. 담주 한국 주식은 어떻게 되려나.)