SQL의 자유와 시맨틱 모델의 안전을 함께 노린 Malloy

SQL의 자유와 시맨틱 모델의 안전을 함께 노린 Malloy

Malloy 데이터 모델링 뉴스 썸네일

분석 쿼리가 길어질수록 같은 계산식을 여러 곳에 다시 쓰고, 조인 뒤 합계가 틀어지는 문제도 잦아져요. Malloy는 데이터 관계와 계산 규칙을 재사용 가능한 모델로 정의하면서도 기존 데이터베이스의 SQL 실행 능력을 그대로 활용하려는 오픈소스 언어예요. 1

핵심 요약

구분	내용	실무에서 볼 점
언어 성격	시맨틱 모델링 언어와 쿼리 언어를 결합해요	모델을 정의한 뒤 같은 문법으로 탐색과 집계를 이어갈 수 있어요
실행 방식	Malloy 코드를 대상 데이터베이스에 맞는 SQL로 바꿔 실행해요	기존 데이터 웨어하우스를 교체하지 않고 도입 범위를 시험할 수 있어요
오류 방지	조인 관계에서 생기는 합계·평균·개수의 오집계를 줄여요	숫자가 문법상 맞아 보여도 계산 기준이 어긋나는 문제를 언어 차원에서 다뤄요
재사용	쿼리와 계산 정의를 다시 조합할 수 있어요	지표 정의가 대시보드마다 갈라지는 일을 줄이는 데 도움이 돼요
개발 환경	VS Code 확장과 문서, 브라우저 실습 환경을 제공해요	작은 데이터 모델부터 문법과 결과 SQL을 확인하기 쉬워요

1. Malloy는 SQL 위에 관계와 계산 규칙을 쌓아요

Malloy는 별도 데이터베이스가 아니에요. 작성한 모델과 쿼리를 BigQuery, Snowflake, PostgreSQL, MySQL, Trino, Presto 같은 백엔드가 실행할 SQL로 컴파일해요. DuckDB도 네이티브로 지원해 로컬 분석 흐름에 연결할 수 있어요. 2022년 Looker의 실험적 언어로 소개된 뒤 별도 `malloydata` 프로젝트로 옮겨졌고, 지원 범위도 초기 BigQuery와 PostgreSQL 중심에서 넓어졌어요. 1

공식 사이트가 내세우는 장점은 이름 붙이기와 재사용이에요. 예를 들어 항공편 데이터를 분석할 때 출발지 조건, 항공사별 그룹, 운항 횟수, 평균 비행시간을 한 쿼리 안에서 읽을 수 있게 표현해요. SQL의 `SELECT`, `GROUP BY`, 집계식과 정렬 조건을 매번 길게 조립하는 대신, 이미 정의한 관계와 측정값을 불러와 조합하는 방식이에요. 2

이 구조는 지표 이름을 짧게 만드는 데서 끝나지 않아요. 매출, 활성 사용자, 평균 주문액처럼 여러 화면에서 반복되는 계산을 모델에 두면 분석가와 대시보드가 같은 정의를 공유할 수 있어요. 쿼리를 작성하면서 모델을 조금씩 다듬는 흐름도 지원해요. 처음부터 거대한 전사 모델을 완성한 뒤 사용해야 하는 방식보다 작은 범위에서 시험하기 쉬워 보여요.

728x90

중첩 쿼리는 계층형 결과를 자연스럽게 만들어요

일반 SQL로 국가, 도시, 매장처럼 여러 단계의 결과를 만들려면 서브쿼리와 집계를 겹치거나 애플리케이션에서 결과를 다시 묶을 때가 있어요. Malloy의 중첩 쿼리는 쿼리 자체를 재사용 가능한 구성 요소로 다뤄요. 같은 정의를 복사하지 않고 상위 결과 안에 하위 결과를 넣어 계층형 뷰를 만들 수 있어요. 공식 사이트도 풍부한 계층 구조와 쿼리 재사용을 주요 기능으로 소개해요. 2

대칭 집계는 조인 뒤 숫자가 부풀어 오르는 문제를 다뤄요

주문과 주문 상품을 조인하면 주문 한 건이 상품 수만큼 반복될 수 있어요. 이 상태에서 주문 금액을 단순 합산하면 실제 매출보다 큰 값이 나와요. SQL은 쿼리를 실행해 주지만 어떤 집계가 업무 정의에 맞는지까지 판단해 주지는 않아요.

Malloy의 대칭 집계는 테이블 관계와 측정값 정의를 이용해 합계, 평균, 개수의 중복 계산을 막는 데 초점을 둬요. 흔히 팬 트랩이나 캐즘 트랩으로 불리는 조인 집계 오류를 매번 수작업으로 우회하지 않아도 된다는 설명이에요. 분석 결과가 그럴듯하게 보여 검토에서 놓치기 쉬운 오류라서, 복잡한 관계를 자주 다루는 BI 환경에서 특히 확인할 만해요. 1

도입 전에는 생성 SQL과 팀의 모델 관리 방식을 봐야 해요

새 언어를 쓰면 문법 학습과 도구 의존이 생겨요. 기존 SQL 자산을 얼마나 자연스럽게 옮길 수 있는지, 생성된 SQL이 데이터베이스별 비용과 성능 기준을 충족하는지 먼저 확인해야 해요. 팀이 이미 dbt, LookML이나 자체 지표 계층을 운영한다면 책임 범위가 겹치는지도 따져볼 필요가 있어요.

작은 데이터셋으로 같은 지표를 SQL과 Malloy에서 각각 계산해 결과와 실행 계획을 비교하는 방법이 현실적이에요. 조인이 많은 지표, 여러 대시보드에서 반복되는 계산, 계층형 결과처럼 Malloy의 장점이 드러나는 사례부터 시험하면 도입 효과를 판단하기 쉬워요. VS Code 확장과 브라우저 실습 환경이 있어 초기 검토 비용은 낮은 편이에요. 2

왜 중요한가요

데이터팀의 어려움은 SQL 문장이 긴 데만 있지 않아요. 같은 이름의 지표가 보고서마다 다르게 계산되고, 조인 하나로 합계가 달라져도 결과표는 멀쩡해 보일 수 있어요. Malloy는 관계, 차원, 측정값과 쿼리를 한 언어에서 다뤄 이런 차이를 코드로 드러내려 해요. 2

기존 데이터베이스를 그대로 쓰면서 모델 계층을 추가한다는 점도 실용적이에요. 데이터 이동 없이 일부 분석부터 비교할 수 있고, 필요하면 컴파일된 SQL을 살펴 성능과 비용을 검토할 수 있어요. 다만 언어가 오류를 모두 없애 주는 것은 아니에요. 관계와 측정값을 잘못 정의하면 잘못된 기준이 여러 분석에 재사용될 수 있으므로 코드 리뷰, 결과 대조, 지표 소유권은 여전히 필요해요.

Malloy를 검토할 팀이라면 문법의 간결함보다 세 가지를 먼저 보면 돼요. 조인 집계 오류를 실제로 줄이는지, 반복 지표의 정의를 한곳에서 관리할 수 있는지, 생성 SQL이 운영 중인 웨어하우스에서 예측 가능한 비용으로 실행되는지예요. 이 세 조건이 맞으면 SQL을 버리지 않고도 분석 모델의 일관성을 높일 선택지가 될 수 있어요.

참고 자료

1. Malloy - 데이터 관계·변환·모델링을 위한 모던 오픈소스 언어 — GeekNews
2. Malloy 공식 사이트 — Malloy