데이터를 더 잘 활용하기 위한 BI(Business Intelligence) 툴을 내부에 구축할 때, 여러 가지 선택지가 있습니다. 특히 오픈소스 중에서는 Redash와 Metabase가 가장 많이 거론되는 도구인데요.
이번 글에서는 이 두 툴이 각각 어떤 특징을 가지고 있고, 내부적으로는 어떻게 동작하는지 살펴보겠습니다. 그리고 어떤 조직이나 상황에서 각각의 툴을 선택하면 좋을지도 이야기해보겠습니다.
Redash와 Metabase
Redash
Redash는 SQL을 중심으로 여러 데이터 소스에 손쉽게 접근해 시각화 및 대시보드를 빠르게 만들 수 있도록 도와주는 오픈소스 BI 툴입니다. 2015년 처음 공개됐으며, SQL을 자유롭게 다룰 수 있는 개발자나 분석가들에게 특히 인기가 많습니다.
Metabase
Metabase 역시 2015년 등장한 오픈소스 BI 툴인데요. SQL을 잘 모르더라도 GUI를 통해 간편히 데이터를 질의하고 분석할 수 있는 직관적인 인터페이스가 특징입니다. 데이터 문화를 조직 전체에 쉽게 확산시키고 싶을 때 적합한 툴입니다.
내부 구조 및 동작 방식
Redash의 내부 구조와 동작
Redash는 크게 다음과 같은 구조를 가지고 있습니다.
•
Frontend (React 기반 UI): 사용자에게 SQL 쿼리 작성과 시각화를 제공
•
Backend (Flask 기반): 인증, 쿼리 관리, 데이터 처리 등 로직 처리
•
Worker (Celery): 실제 SQL 쿼리를 비동기로 처리하는 프로세스
•
캐싱 (Redis): 쿼리 결과를 빠르게 불러오기 위해 결과 캐시
•
Metadata DB (PostgreSQL): 쿼리, 대시보드, 사용자 정보 등 메타데이터 저장
Redash에서 사용자가 쿼리를 실행하면, 요청은 Flask 서버를 통해 Celery 작업 큐로 전달됩니다. Worker는 데이터를 DB에서 조회한 후, Redis에 결과를 캐싱하고, 이 결과를 사용자에게 빠르게 반환합니다.
Redash 내부 구조
flowchart LR
User --> Frontend[Frontend - React]
Frontend --> WebServer[Web Server - Flask]
WebServer --> MetadataDB[DB - PostgreSQL]
WebServer --> Redis[Query Queue - Redis]
Redis --> Worker[Worker - Celery]
Worker --> Redis
Worker --> DataSources[여러 데이터 소스]
%% 스타일링(optional)
style User fill:#fdecec,stroke:#fa8072,stroke-width:2px
style Frontend fill:#ffe8b0,stroke:#e08c00,stroke-width:1px
style WebServer fill:#cce5ff,stroke:#3399ff,stroke-width:1px
style MetadataDB fill:#f0fff0,stroke:#008000,stroke-width:1px
style Redis fill:#ffffff,stroke:#b31b1b,stroke-width:1px,stroke-dasharray: 5 5
style Worker fill:#fafad2,stroke:#ccc,stroke-width:1px
style DataSources fill:#eee,stroke:#ccc,stroke-width:1pxMermaid
복사
흐름 설명
1.
사용자(User)는 브라우저로 Redash 웹 UI(React)에 접근해 쿼리를 작성하거나 대시보드를 확인합니다.
2.
Frontend(React)에서 입력된 요청은 Web Server(Flask)로 전달되며, Flask 서버가 사용자 인증, 쿼리 저장, 시각화 요청 등을 관리합니다.
3.
Web Server는 쿼리 실행 요청을 받을 경우, 내부적으로 Redis를 통해 비동기 태스크 큐를 생성합니다.
4.
Worker(Celery)가 Redis에서 태스크를 꺼내어 실제 Data Sources(예: MySQL, PostgreSQL, BigQuery 등)에 쿼리를 날리고 결과를 받아옵니다.
5.
쿼리 결과나 대시보드 설정 같은 메타정보는 Metadata DB(PostgreSQL)에 저장됩니다.
6.
이후 사용자에게 시각화된 결과를 반환하여, Frontend에서 대시보드 형태로 열람할 수 있습니다.
Metabase의 내부 구조와 동작
Metabase의 내부 구조는 다음과 같이 구성됩니다.
•
Frontend (React 기반 UI): 직관적이고 쉬운 데이터 탐색 및 시각화 UI 제공
•
Backend (Clojure/Jetty 기반): 웹 서버 역할을 하며, DB 스키마 분석 및 질의 처리
•
DB 연결과 질의 실행: 질의 결과를 캐싱하여 반복 조회 시 빠르게 응답
•
메타데이터 관리: 자동으로 DB 스키마를 읽어 들여 사용자에게 쉽게 보여줌
Metabase는 사용자가 질의를 보내면, Jetty 기반 서버가 실제 DB로 요청을 보내고 결과를 받아옵니다. 반복적인 질의는 내부적으로 캐싱해 성능을 높입니다.
Metabase 내부 구조
flowchart LR
User --> UI[User Interfaceb - React]
UI --> Server[Metabase Server - Jetty / Clojure]
Server --> AppDB[Application DB - H2/PostgreSQL 등]
Server --> Cache[Query Cache / Metadata]
Server --> DataSources[여러 데이터 소스]
Server --> Pulse[Pulse/Alerts - 이메일/Slack 전송]
Pulse --> Server
%% 스타일링(optional)
style User fill:#fdecec,stroke:#fa8072,stroke-width:2px
style UI fill:#ffe8b0,stroke:#e08c00,stroke-width:1px
style Server fill:#cce5ff,stroke:#3399ff,stroke-width:1px
style AppDB fill:#f0fff0,stroke:#008000,stroke-width:1px
style Cache fill:#ffffff,stroke:#b31b1b,stroke-width:1px,stroke-dasharray: 5 5
style DataSources fill:#eee,stroke:#ccc,stroke-width:1px
style Pulse fill:#fafad2,stroke:#ccc,stroke-width:1px
Mermaid
복사
흐름 설명
1.
사용자(User)가 브라우저를 통해 Metabase UI(React)에 접속합니다.
2.
요청은 Metabase Server(Jetty/Clojure 기반)로 전달되어, 사용자 인증 및 쿼리 실행, 대시보드 생성 등을 처리합니다.
3.
Server는 내부적으로 Application DB(H2/PostgreSQL 등)를 이용해 사용자, 대시보드, 권한, 메타데이터 등을 저장하고 관리합니다.
4.
쿼리 실행 시 Data Sources(여러 DB)와 통신하고, 필요한 경우 Cache(쿼리 결과·메타정보)를 사용하여 빠른 응답을 제공합니다.
5.
Pulse 기능(스케줄 알림, Slack·이메일 전송 등)을 통해 정기적으로 리포트나 대시보드를 자동 공유할 수 있습니다.
기능 및 장단점 비교
구분 | Redash | Metabase |
핵심 컨셉 | SQL 중심 (쿼리 작성이 메인) | GUI 질의 (SQL 몰라도 가능) |
시각화 | 기본 차트/테이블에 충실, 가벼운 시각화 | 보다 다양한 시각화, 대시보드 구성 자유도 높음 |
데이터 연결 | 다양한 DB, NoSQL, BigQuery 등 | 동일하게 다양한 DB, 스키마 스캔 통해 메타데이터 자동 구성 |
권한 관리 | 상대적으로 단순한 편 | 그룹, 역할(Role) 기반 세밀한 권한 설정 가능 |
리포팅 기능 | 기본적으로 대시보드 공유/임베드 정도 | Pulse (스케줄, Slack, 이메일 알림) 등 리포팅 기능 풍부 |
학습 곡선 | SQL만 알면 사용 편리, SQL 미숙자에겐 어려움 | 비기술자에게도 직관적이나, 고급 SQL 커스텀 시에는 설정 다소 복잡 |
어떤 상황에 어떤 툴을 선택하면 좋을까?
Redash를 선택하면 좋은 상황
•
분석가, 개발자 중심의 SQL 친화적인 팀
•
복잡한 쿼리와 빠른 시각화 반복이 필요한 조직
•
다양한 데이터 소스에 유연하게 접근해야 하는 경우
•
가볍게 시각화하고 결과를 빠르게 공유하는 용도로 쓰고 싶을 때
Metabase를 선택하면 좋은 상황
•
전사적으로 비기술자도 데이터를 쉽게 탐색/활용해야 하는 경우
•
기술적 배경이 다양해 SQL 사용이 어려운 사용자가 많은 조직
•
시각화와 리포팅(Pulse) 기능 중심으로 직관적인 BI 환경이 필요한 경우
•
그룹별로 세밀한 권한 관리가 필수적인 대규모 조직
마무리
Redash와 Metabase는 모두 오픈소스 BI 툴로 많은 사랑을 받고 있지만, 결국 중요한 것은 회사 내부의 기술 수준, 사용자의 필요, 그리고 데이터 활용 방식입니다. 데이터 기반의 의사결정 문화가 점점 더 중요해지는 만큼, 여러분 조직의 환경과 필요에 맞는 적절한 툴을 선택하면 좋을 것 같습니다.
다음 글에서는 실제로 Redash와 Metabase를 도입하고 사용해보면서 겪었던 경험을 공유해보려고 합니다.설정 과정에서 마주했던 다양한 이슈들, 그리고 직접 해결했던 트러블슈팅 사례들을 정리해보겠습니다.