목차
- 들어가는 글
- Redash 도입 배경
- Redash 활용 방법
- 나가는 글
들어가는 글
제가 근무하고 있는 아이오트러스트는 프로덕트 사용자 데이터 분석을 할 수 있는 환경이 조성되어 있습니다. 그 중 Redash를 BI툴로 도입하여 2년 가까이 사용하고 있는데요. 이번 아티클에서는 데이터 분석 환경을 조성하고자 Redash를 어떻게 도입하여 활용했는지 하나하나 공유 드리고자 합니다.
Redash 도입 배경
데이터 분석가가 없던 시절, 원래 GA와 Amplitude를 통해 아주 기초적인 데이터 현황 만을 확인하고 있었을 뿐, 데이터 카탈로그나 이벤트 정의서 같은 뼈대가 없어 데이터를 적극적으로 활용하기 어려웠습니다.
사내 최초로 데이터 분석가로 입사한 저는 초반 6개월 동안 이러한 상황을 개선하고자, 일관성과 활용도를 갖춘 환경을 만드는 것을 목표로 두었습니다. 그 결과, 약 2년 전부터 아래와 같은 파이프라인을 갖추게 되었고, 조직이 예전보다 훨씬 높은 분석 자유도를 누릴 수 있게 되었습니다.
파이프라인의 최종 영역인 Data Visualization을 위해 Redash를 도입하기로 결정한 배경은 다음과 같습니다.
(1) 데이터 추출의 자유도가 매우 높았기 때문입니다.
많은 데이터 분석가 분들이 공감하시듯, 노코드 PA 툴의 경우 처음에는 마냥 사용하기 편하지만 깊이를 다져갈수록 분석의 자유도가 떨어져 한계에 부딪히기 마련입니다.
반면 Redash의 경우, 쿼리를 직접 작성한 후 출력된 결과를 기반으로 시각화를 할 수 있기 때문에 조건과 집계를 자유롭게 적용할 수 있습니다. 따라서 향후 조직의 데이터 기반 의사결정 깊이가 증진될수록 Redash를 지속적으로 활용할 수 있다는 점이 매력적이었습니다.
(2) 오픈소스를 통해 별도의 비용 없이 이용할 수 있었기 때문입니다.
Docker Compose를 빌드하여 Redash 애플리케이션을 매우 쉽게 개발할 수 있으며, VM Instance 운영 외에 추가 비용이 들지 않았습니다.
Redash 활용 방법
1. 대시보드의 이름과 태그를 정돈하여 사람들이 헤매지 않도록 했어요.
Redash의 단점 중 하나는 각 대시보드를 디렉토리로 분류할 수 있는 기능이 따로 없다는 점입니다. 특히, 사내 구성원이 확인하는 대시보드는 크게 다음 두 가지 종류로 나뉘게 될 것인데요.
- 주기적으로 팔로업해야 하는 기본 대시보드 (범용성)
- Ad-hoc 분석 요청에 의해 만들어진 대시보드 (일회성/특수성)
이 때문에 목적이 다른 여러 가지 대시보드들이 시간이 흐를수록 뒤죽박죽 섞이게 되어 탐색하기 매우 복잡해질 것이 뻔합니다. 탐색의 복잡성은 사용성을 해치게 될 것이고, 결국 조직의 데이터 활용 역량과 시간에 악영향을 끼치게 되겠죠.
이를 어떻게 극복해야 할지 고민하다, 최선의 방법으로 대시보드의 이름과 태그를 통해 탐색의 편의성이 유지될 수 있도록 접근했습니다.
(1) 각 대시보드의 제목에 다음과 같은 Prefix를 달았어요.
- [기본-{
프로덕트 이름}]: 각 구성원들이 주기적으로 확인해야 하는 범용 대시보드 - [Ad-hoc]: 특정 구성원이 요청한 분석 내용을 정리한 대시보드
- [Private]: 민감한 정보를 가지고 있어 특정 구성원들에게만 공유해야 하는 대시보드
- [Public]: 외부 제공 목적의 공개한 대시보드
(2) 대시보드마다 총 2개의 태그를 달아, 필터링하기 용이하도록 만들었어요.
- 상위 개념의 태그: 기본, Ad-hoc, Private, Public 중 하나를 명시
- 하위 목적의 태그: 프로덕트 이름이나 분석을 요청한 구성원 이름을 명시
2. Query Parameters를 적극적으로 사용했어요.
Query Parameters란 Redash가 제공하는 동적 변수 기능입니다. 즉, 사용자가 Redash UI에서 원하는 값을 선택하여 쿼리를 실행할 수 있는 것인데요. 이를 활용하면 다음과 같은 장점이 있습니다.
- 각 케이스 별로 일일이 쿼리문을 생성할 필요 없이, 실행 시점에 Query Parameters 값만 변경함으로써 원하는 데이터가 출력되도록 할 수 있어요.
- 각 케이스 별로 모든 차트를 대시보드에 추가할 필요가 없으므로 대시보드의 가시성이 좋아지고 복잡도를 방지할 수 있어요.
Query Parameters는 Level과 Type 두 가지 차원에서 다음과 같이 분류됩니다.
(1) Level 차원
- 대시보드 레벨 파라미터 (Dashboard Parameter): 파라미터 값을 변경하면 대시보드 내의 모든 차트에 적용됩니다.
- 차트 레벨 파라미터 (Widget Parameter): 파라미터 값을 변경하면 해당 차트에만 적용됩니다.
- 정적인 값을 지닌 파라미터 (Static Value): 파라미터를 특정 값에 고정시킵니다.
(2) Type 차원
- Text: 파라미터 값을 사용자가 자유롭게 텍스트로 입력할 수 있습니다.
- Number: 파라미터 값을 사용자가 숫자로만 입력할 수 있도록 합니다.
- Dropdown List: 사전 정의된 리스트에서 값을 선택합니다. (정적 리스트)
- Query Based Dropdown List: 다른 쿼리 실행 결과 리스트에서 값을 선택합니다. (동적 리스트)
- Date: 특정 날짜를 선택합니다.
- Date Range: 특정 날짜 기간을 선택합니다.
이제 저희가 사용하는 대표적인 Query Parameters를 소개해드리도록 하겠습니다.
(1) 간격 파라미터
아래 쿼리문의 DATE_TRUNC() 함수의 간격을 동적 파라미터로 두었습니다. 이를 통해 사용자가 DAY, WEEK, MONTH, QUARTER, YEAR 기반으로 각 집계 결과를 자유롭게 확인할 수 있습니다.
SELECT
DATE_TRUNC(PARSE_DATE('%Y%m%d', event_date), {{ 간격 }}) AS event_date,
...
FROM
...
(2) 기간 파라미터
아래 쿼리문은 _TABLE_SUFFIX를 통해 일별로 파티션된 테이블 중 조회를 원하는 테이블들만 검색하게 되는데요. 이 기간을 특정할 수 있도록 파라미터화했습니다. 이를 통해, 사용자가 아래와 같이 파라미터 값을 입력하여 조회 기간을 선택할 수 있습니다.
- 정적 기간: 2024년 1월 1일부터 2024년 1월 10일까지
- 동적 기간: This Week, Last Month, This Year 등
SELECT
...
FROM
`events_*`
WHERE
_table_suffix BETWEEN
FORMAT_DATE('%Y%m%d', '{{Date Range.start}}')
AND FORMAT_DATE('%Y%m%d', '{{Date Range.end}}')
(3) 국가 파라미터
국가 파라미터의 경우, Query Based Dropdown List를 사용했습니다. 프로덕트 사용자 유입에 따라 시간이 흐를수록 접속 국가가 지속적으로 증가하기 때문에 정적인 목록으로 관리하기에는 어려움이 따르기 때문입니다.
- 먼저, 국가 목록을 동적으로 불러오는 쿼리를 작성했습니다. (트래픽 규모가 큰 순서대로 정렬하고,
ALL항목도 포함될 수 있도록 했어요.)
- 새로운 접속 국가가 발생할 수 있으니, Scheduled Run을 활성화하여 최신성이 유지될 수 있도록 했어요.
아래 쿼리문은 Country 파라미터의 값이 ALL이면 전체를 출력하고, 그렇지 않을 경우 geo.country 칼럼이 해당 값과 동일한 경우만 출력할 수 있도록 작성한 것입니다.
SELECT
...
FROM
`events_*`
WHERE
...
AND
CASE
WHEN 'ALL' IN ({{Country}}) THEN 1 = 1
ELSE geo.country IN ({{Country}})
END
3. 각 대시보드의 상단에는 제목, 목차, 간단한 가이드를 작성했어요.
사내에는 데이터 분석을 업무에 적극적으로 활용하는 분들도 계시는 반면, 여러 가지 이유로 깊게 관여하지 못하는 분들도 계십니다. 데이터가 업무 관련성이 낮을 수도 있고, 메인 업무만으로도 시간이 부족하실 수도 있고, 혹은 활용은 하고 싶으나 데이터 이해의 어려움을 겪고 계신 것 때문일 수도 있겠죠.
따라서 최대한 많은 구성원들이 빠르고 쉽게 이해할 수 있는 대시보드를 제공하는 것이 가장 중요하다고 생각했습니다. 조금이라도 장벽을 낮추기 위해 아래 사례와 같이 제목, 목차, 그리고 가이드를 작성했습니다.
Redash에서 차트뿐만 아니라 Textbox도 자유롭게 추가할 수 있는데요. 특히, Markdown 문법을 잘 활용하면 시각적으로 보기 편하게 작성할 수 있습니다.
4. 차트에 대한 설명은 좌측에, 각 차트는 우측에 배치했어요.
디자이너와 프론트엔드 개발자 분들이라면 잘 아시듯이, 한국어와 영어는 LTR(Left to Right) 성격을 지닌 언어입니다. (Apple Developer 페이지 참고) 한국어와 영어를 사용하는 사람들은 텍스트와 숫자는 물론, 이미지를 포함한 컨텐츠 자체를 LTR 방식으로 습득하는 경향을 지니고 있는 것입니다.
사용자들의 이러한 인지 성향을 반영하여, 대시보드의 UI를 기본적으로 다음과 같이 배치했습니다.
- 좌측 1/3 영역: 차트의 제목, 정의, 상세한 활용 방법을 작성한다.
- 우측 2/3 영역: 해당 차트나 테이블을 보여준다.
이를 통해, 사용자의 시선 이동 습관을 자연스럽게 따라갈 수 있도록 한 것입니다.
5. 차트의 활용 가이드는 LLM의 도움을 받아 작성했어요.
사실, 데이터 분석가 분들끼리는 대시보드에 표현할 지표의 의미를 정의하고 설명하는 것에는 큰 어려움이 없습니다. 다만, 각기 다른 포지션의 사내 구성원들이 이해하기 쉽게 설명하는 것은 어렵기 마련입니다. 다양한 R&R에 대한 이해와 공감, 그리고 데이터 문해력을 함께 갖추어야 하기 때문이죠. 이러한 상호 간의 얼음 장벽을 조금이라도 해소하기 위해 대시보드 사용자 관점에서 UX Writing이 이루어질 수 있도록 LLM을 활용해봤습니다.
(1) 작성한 프롬프트 샘플
"활성 사용자 수" 차트의 설명 가이드를 작성해주세요.
배경: 사내 BI 대시보드를 이용하는 사내 임직원들에게 보여주는 차트입니다.
조건 1: 데이터 지식이 부족한 임직원이 있을 수 있으니 친절하고 명료하게 표현해야 합니다.
조건 2: 사업 전략, 마케팅, 디자인, 개발 등 각 전문성에 연관된 설명이 있으면 좋습니다.
작성 포맷:
# 활성 사용자 수
> 간략한 정의
---
* 3-5개 Bullet Points 자세한 설명
---
* 3-5개 Bullet Points 차트를 업무에 활용하는 방법 사례
(2) ChatGPT 4o의 답변 사례
6. 하위 제목은 더 크게, 상위 제목은 더 작게 표현했어요.
저를 포함하여 Markdown에 익숙한 분들은 일반적으로 아래와 같이 대제목은 크게, 소제목은 작게 표현하곤 하실 것입니다.
# 1. 대제목
## 1.1. 소제목그런데, 아래와 같이 각 소제목 파트의 양이 워낙 많아 한 화면에 정보의 Hierarchy를 보여줄 수 없는 경우에는 문제가 생길 수 있습니다. 즉, 스크롤을 하게 되면서 사용자는 다음과 같은 혼란에 빠지기 쉬운 것입니다.
“내가 지금 보고 있는 소제목 파트의 대제목이 뭐였지?”
# 1. 대제목
...
...
(중략)
...
...
## 1.1. 소제목
...
...
(중략)
...
...
## 1.2. 소제목이러한 문제가 생길 것을 직감하여, UX/UI 전문가이신 사내 디자이너 및 프론트엔드 개발자 동료 분들께 의견을 구하니 다음과 같은 조언을 해주셨습니다.
“현재 사용자가 focus한 내용은 소제목 파트이니, 소제목을 더 크게 표현하고, 대제목을 작게 표현해주는 게 사용자 경험을 잘 반영해줄 수 있을 것 같아요.”
결국 저는 대제목을 크게 한 번 표현한 이후부터는, 소제목 작성시 대제목을 머릿말 처럼 작게 표시함으로써 소제목에 focus하려는 사용자의 심리를 잘 따라갈 수 있도록 구성했습니다.
7. 카테고리의 Cardinality가 높을 경우, 차트에서는 최대 20개까지만 표현하고, 보충 테이블을 통해 전수를 확인할 수 있도록 구성했어요.
사실 저희 기업은 글로벌 서비스를 운영하고 있다보니, 사용자들의 접속 국가 개수가 100개를 훨씬 넘습니다. 만일 국가별 획득 사용자 수 추이를 차트로 표현한다면 아래의 두 가지 방식이 존재할 것입니다.
(1) 전체 국가를 모두 표현하는 방식
- 장점: 정보의 완전성을 갖출 수 있어요.
- 단점: 가독성이 떨어지고, 브라우저의 메모리 사용량이 지나치게 높아져요.
(2) 상위 N개 국가만 명시하고, 나머지는 “기타”로 집계하는 방식
- 장점: 가독성이 높아져 흐름을 읽기 쉬워져요.
- 단점: 정보가 불완전하여 “소수 국가”의 데이터를 확인하기 어려워져요.
이 딜레마를 해결하기 위해 다음과 같은 접근 방법을 선택했습니다.
- 가독성을 위해 차트에서는 최대 20개국만 명시하기
- 정보의 완전성을 위해 전체 국가 데이터를 별도의 테이블로 보충하기
사실 BI 전문가분들 사이에서 차트에 표현할 Cardinality를 최대 7개로 제한하는 것이 좋다는 불문율이 존재하기도 합니다. 하지만 저희 기업의 사업 특성상 워낙 많은 국가에서 프로덕트가 사용되고 있기 때문에 20개국으로 Limit을 올리기로 결정했습니다.
8. 하이퍼링크를 통해 편의성을 제공했어요.
가령, 컨텐츠 마케팅 영역에서는 각 컨텐츠 페이지를 비교 분석해야 하는 경우가 빈번합니다. 따라서 “페이지별” 인사이트를 제공하기 위한 테이블을 만들 때는 항상 하이퍼링크를 추가했습니다.
비교 분석을 하는 컨텐츠 마케터 시각에서는, 각 페이지의 트래픽, CTA 전환율, Engagements, 체류 시간 등의 수치를 확인하면서 해당 컨텐츠 자체의 정성적인 배경을 파악하는 것이 자연스러운 사고 흐름일 것입니다. 따라서 편하게 해당 페이지로 이동하여 비교 분석할 수 있도록 하이퍼링크를 사용하게 된 것입니다.
9. 각 쿼리문은 모두 Git Repo에 별도로 보관했어요.
Redash에서 각 쿼리문을 저장할 수 있고, 대시보드 처럼 태그를 통해 탐색의 편의성을 높일 수 있습니다.
그러나 대시보드를 만드는 과정에서 쿼리문의 재사용이나 반복 적용된 쿼리문의 전면 수정 등을 진행할 경우 이를 일일이 탐색하려면 엄청난 작업 비효율성을 발생할 것입니다. 따라서 저는 기본적으로 모든 쿼리문을 다음과 같은 체계를 두어 Git Repo로 관리하고 있습니다.
- 디렉토리: 각 대시보드
- 개별 파일: 대시보드에 포함된 각 쿼리문
Git Repo를 통한 관리는 다음과 같은 장점을 가져다줄 수 있습니다.
- 데이터 마트의 도입이나 택소노미의 변경 등으로 인해 모든 쿼리문을 한꺼번에 수정해야 한다면, 반복 작업 시간을 크게 단축할 수 있습니다.
- 쿼리문을 재사용하여 새로운 대시보드를 생성할 경우, 탐색 시간이 크게 단축됩니다.
- VC Code의 Copilot의 코드 생성 기능을 사용함으로써 작업 시간이 매우 크게 단축됩니다.
나가는 글
지금까지 제가 근무하고 있는 아이오트러스트에서 Redash를 어떻게 활용하고 있는지에 대해 말씀 드렸습니다. 이 과정에서 데이터 분석과 엔지니어링 업무를 수행하며 느낀 중요한 점이 하나 있습니다. 바로, 생각을 닫은 채 기계적으로 대시보드를 만드는 행위를 지양해야 한다는 것입니다. 데이터 기반 의사결정과 데이터 리터러시에 기여하기 위해 다음과 같은 내적 질문을 끊임없이 던져야 합니다.
“대시보드를 어떤 방식으로 제공해야 의사결정의 실효성과 데이터 활용도를 높일 수 있을까?”
다양하고 복잡한 기능을 갖춘 웅장한 차트를 제공하는 것도 좋지만, 결국 가장 중요한 것은 사내 구성원들에게 실질적인 도움이 되는 방식으로 제공하는 것입니다. Redash 대시보드를 만드는 과정에서 사용자 심리를 공부하고 LLM을 활용하게 된 배경에도 결국 이러한 고민이 있었습니다.
현재의 대시보드가 결코 완벽하다고 생각하지 않습니다. 사업 전략, 데이터의 변화, 조직의 성장과 변화에 따라 대시보드를 개선해야 하는 시기가 올 것입니다. 고객이 애정하는 프로덕트가 되는 데 기여할 수 있도록 BI에 대한 관심을 지속적으로 갖고 열심히 노력해보겠습니다.
