문제 정의와 해결 전략
다양한 이상 현상을 관측할 수 있는 지표들을 모니터링 할 수 있는 대시보드가 있다. 대시보드의 문제는 지표가 너무 많다는 것이다. 지표의 홍수 안에서 사용자는 자신이 무엇을, 어떻게 볼 수 있는지 알기 어렵다. 따라서 문제 정의는 아래와 같다.
근본적인 문제를 해결하는 방법도 있다. 각 지표의 기능과 역할을 엄밀히 검토하여 유용한 것들만 남기는 것이다. 하지만 오늘은 대시보드가 주인공이다. 어떻게 하면 사용자가 헤매지 않고 대시보드에서 원하는 바를 얻어 갈 수 있을까? 아니 그보다 먼저. 사용자는 대시보드에서 무엇을 얻어가고 싶은가?
사용자의 니즈를 구분하는 첫 번째 기준은, 특정한 지표에 대한 목적성이다. 특정 지표에 대한 목적이 없는 사용자도 있을까? 물론 있다. 그들은 막연하게 중요한 지표를 보고 싶어한다. 마치 네이버의 실시간 검색어처럼. 나머지 사용자는 목적이 있다. 그들은 구체적으로 특정 지표를 보고 싶어한다. 따라서 두 분류의 사용자를 위해 두 개의 페이지 개발이 필요하다.
두 페이지 중 앞선 우선순위는 물론 검색 페이지이다. 애초에 구체적인 목적이 없는 사용자의 유입을 유도하는 것이 배는 어렵기 때문이다. 따라서 문제 정의를 다시 해보면, 특정 지표를 검색하고자 하는 사용자에게 어떻게 지표를 제공할까? 아니 그보다 먼저. 우리가 제공하는 지표는 어떻게 생겼지?
지표란 사전적으로 특정 이벤트를 관측하는 변수이다. 예를들어 더워짐이라는 이벤트를 관측하기 위해 우리는 온도기에 있는 수은의 높이라는 변수를 관측한다. 일반적으로 지표는 세 가지 질의를 통해 설명할 수 있다.
- 무슨 이벤트를 관측하려는 지표인가?
- 어떤 데이터를 사용하여 만든 지표인가?
- 데이터를 어떻게 가공하여 만든 지표인가?
지표에게 가장 중요한 것은 첫 번째 질문. 관측하려는 이벤트이다. 우리가 온도기를 하루종일 보고 있어도, 수은의 높고 낮음이 무엇을 의미하는지 모른다면 그냥 멍하니 벽을 쳐다보고 있는 것과 다를 것이 없다. 그렇다면 사용자가 관측하려는 이벤트를 통해 지표를 검색하도록 제공하면 좋을까? 물론 좋다. 하지만 이는 이상적이다. 앞서 말한대로 우리는 너무 많은 지표를 가지고 있다. 그리고 각 지표에 관측하려는 이벤트를 라벨 붙여주는 것은 꽤나 어려운 일이다. 예를들어 실업율이라는 변수를 생각해보자. 실업율이 지난 분기 2%에서 요번 분기 4%가 되었다. 이것이 무엇을 의미하는가? 경제학 교수님이라면 수 십 분을 더 이야기하실 수 있겠지만, 이를 몇 개의 키워드 혹은 한 줄로 일반화하는 것은 아주 어렵다. (주의: 실업률이 2배가 되었다는 것은 관측하려는 이벤트가 아니다. 그저 변수의 추이에 대한 사실일 뿐이다)
지표에게 가장 중요하지 않은 것은 세 번째 질문. 어떻게 가공하였는가 이다. 예를들어 인플레이션 지표를 생각해보자. 에너지 물가가 어떻게 가공되었는지 궁금한 적이 한 번이라도 있었는가? 거래별 평균을 내었는지, 거래량에 가중 평균을 내었는지, 집계 과정에서 극단치를 제거하였는지… 이런 것들을 궁금해하는 사용자는 이미 대시보드에서 헤매지 않는 고수일 가능성이 높다. 사실은 답정너였다. 우리는 어떤 데이터를 사용하여 만든 지표인지를 통해 검색 기능을 제공하려고 한다.