태블로에서 계산은 크게 세 가지 유형으로 이뤄진다. 첫째, 데이터 원본에 대해 계산을 진행하는 기본 계산. 둘째, 현재 비주얼리제이션에 표시된 항목 바탕으로 값을 변환해 셈하는 테이블 계산. 셋째, 연산할 세부 수준을 지정해 셈하는 LOD 계산. 이번 포스트에서는 이 세 개의 계산 중에서 LOD 계산의 정의와 예제에 대해 간략하게 다룬다.

<'디테일'에도 '레벨'이 있다>

테이블 계산을 할 때를 생각해 보자. 월매출 값을 카테고리로 쪼개면 레저, 가구, 식품의 월매출 값을 각각 볼 수 있다. 하지만 이렇게 뭉텅이로 쪼개 버린다면 서브 카테고리, 즉 낚시대와 캠핑 텐트, 의자와 책상, 밀키트와 냉동 식품의 월매출 값을 볼 수 없을 것이다. 반대로 서브 카테고리로 월매출을 쪼갠다면 '그냥 카테고리'의 월매출 값을 각각 보기는 힘들다.

다시 말하면 "차원과 측정값을 테이블 내에 넣으면 그 시점에서 '디테일 레벨'은 고정된다." 디테일 레벨이 높을 수록 각 데이터는 통합되어 있다. 반대로 디테일 레벨이 낮을 수록 데이터는 세분화되어 쪼개져 있다. 카테고리는 서브 카테고리보다 디테일 레벨이 높은 셈이다.

어쩌면 당연해 보이는 말이지만, 이 단순한 조건으로 인해 제한되는 계산들이 많다. 예를 들어 고객별 구매 일자를 최초 구매일로부터 며칠이 지났는지 보고 싶다고 해 보자. 이를 위해서 구매일Order Date의 MIN 값과(MIN[Order Date]) 최초 구매일로부터의 날짜 차이DATEDIFF를 뽑으면 아래와 같이 나오게 된다.

'고객별 최초 구매일' 출력을 예상하고 입력한 값이지만, 실제로는 화면(테이블) 상 디테일 레벨이 (SQL 식으로 말하자면 그룹이) 일 단위로 나눠져 있기 때문에 각 구매일이 모두 최초 구매일 값으로 잡히게 되고 이 식을 통해 DATEDIFF를 계산해 봤자 유의미한 연산이 될 수 없다.

이렇게, 두 값들의 레벨 차이 때문에 테이블 내에서 계산될 수 없는 것들을 실질적으로 연산 가능하게 해 주는 게 LOD 계산Level of Detail Calculation이다. LOD 계산 함수 중 FIXED를 사용하면 현재 뷰 내에(VLOD: View Level of Detail) 나와 있지 않는 다른 차원 기준으로 값을 계산할 수 있다. 아래와 같이 FIXED로 사용자 이름Customer Name을 추가로 그루핑해 주면 고객 별로 최초 구매 일자가 고정돼서 두 날짜 사이의 차이를 계산할 수 있다.

(FIXED [Customer Name]: MIN([Order Date]))

이처럼 LOD 계산을 사용하면 우리 테이블(VLOD)이 가지고 있는 디테일 레벨 외에서도 연산이 가능하다. 

<LOD 표현식의 형태와 종류>

LOD 표현식은 아래와 같은 형태를 가진다. 조건으로 활용할 차원과 집계식을 기재하고 중괄호로 묶어 주는 형태다. 차원 선언은 생략할 수 있는데, 생략하면 전체 테이블 단위로 표현되게 된다. 반대로 여러 가지 차원도 조건으로 설정할 수 있다. 쉼표로 뒤를 이어주면 된다. 또 유념해야 할 점이 하나 있는데, 뒤에 오는 식은 반드시 집계식(집계함수를 표현한 값의 형태)으로 표현해야 한다는 것이다.

지속적으로 설명되고 있는 FIXED는 완전히 독립적인 표현을 설명하는 LOD 표현식이다. 외에도 두 가지 표현식이 더 있는데, 현재 뷰에서 특정 차원을 추가하기 위해 사용(더 세분화)하는 INCLUDE와 반대로 현재 테이블에서 특정 차원을 제외하기 위해 사용(덜 세분화)하는 EXCLUDE다. 다만 FIXED를 제외한 나머지는 잘 사용되지 않기 때문에 이 포스트에서는 FIXED 위주로 다뤘다.

<마치면서>

이번 포스트에서는 LOD의 개념과 형태에 대해 간략하게 알아봤다. LOD는 본격적인 태블로 활용을 위해 꼭 알아둬야 할 개념이다. 마지막으로 태블로에서 제공하는 LOD 표현식의 활용에 대한 공식 가이드를 태그하면서 글을 마친다. 수익 KPI 측정, 코호트 분석 등 LOD 표현식의 활용처에 대해 자세하게 나와 있으니 꼭 한 번 읽어보길 권한다.

<참고>

패스트캠퍼스 전서연님 강의

태블로 공식 블로그

Cheon님 브런치

김소정님 velog

<서론>

실무에서는 종종 두 개 이상의 테이블의 모든 데이터ㅡ기준키가 공백인 데이터를 포함한, 다시 말해 합집합ㅡ를 불러와야 할 경우가 생긴다. 타 데이터베이스에서는 이를 FULL OUTER JOIN이라는 이름으로 지원하지만, mysql에서는 아쉽게도 이를 공식적으로 지원하고 있지 않다. 그러면 mysql에서는 합집합을 구현할 수 없냐고? 그건 아니다. LEFT JOIN과 RIGHT JOIN을 결합하는 것으로 mysql에서도 이를 간접적으로 구현할 수 있다. 외국 블로그에 해당 내용에 대해 예제와 함께 표시한 포스트가 있어 번역해 가져와 본다.

<본문>

sales와 orders라는 두 테이블이 있다고 가정해 보자. sales와 orders에는 동일하게 id주문 아이디와 order_date(형식이 살짝 다른)주문 일자, amount주문 금액 데이터가 들어 있다.

SELECT *
FROM sales;

 +------+---------------------+--------+
 | id   | order_date          | amount |
 +------+---------------------+--------+
 |    1 | 2021-02-02 08:15:00 |    250 |
 |    2 | 2021-02-02 08:30:00 |    200 |
 |    3 | 2021-02-02 08:55:00 |    150 |
 |    4 | 2021-02-02 09:15:00 |    125 |
 |    5 | 2021-02-02 09:30:00 |    250 |
 |    6 | 2021-02-02 09:45:00 |    200 |
 |    7 | 2021-02-02 10:15:00 |    180 |
 |    8 | 2021-02-02 10:30:00 |    125 |
 |    9 | 2021-02-02 10:45:00 |    200 |
 |   10 | 2021-02-02 11:15:00 |    250 |
 |   11 | 2021-02-02 11:30:00 |    150 |
 |   12 | 2021-02-02 11:45:00 |    200 |
 +------+---------------------+--------+


SELECT *
FROM orders;

 +------+------------+--------+
 | id   | order_date | amount |
 +------+------------+--------+
 |    5 | 2021-01-28 |    250 |
 |    6 | 2021-01-29 |    250 |
 |    7 | 2021-01-30 |    250 |
 |    8 | 2021-01-31 |    250 |
 |    9 | 2021-02-01 |    250 |
 +------+------------+--------+

만약 당신이 전체 기간 동안의 매출 합계를 계산한다거나 하는 이유로 두 테이블을 합쳐야 할 필요성이 있다면 아래와 같이 LEFT JOIN과 RIGHT JOIN을 UNION ALL로 결합해 사용할 수 있다. 아래와 같은 식으로.

mysql> SELECT * FROM sales
       LEFT JOIN orders ON sales.id = orders.id
       UNION ALL
       SELECT * FROM sales
       RIGHT JOIN orders ON sales.id = orders.id
       WHERE sales.id IS NULL ;
       
 +------+---------------------+--------+------+------------+--------+
 | id   | order_date          | amount | id   | order_date | amount |
 +------+---------------------+--------+------+------------+--------+
 |    5 | 2021-02-02 09:30:00 |    250 |    5 | 2021-01-28 |    250 |
 |    6 | 2021-02-02 09:45:00 |    200 |    6 | 2021-01-29 |    250 |
 |    7 | 2021-02-02 10:15:00 |    180 |    7 | 2021-01-30 |    250 |
 |    8 | 2021-02-02 10:30:00 |    125 |    8 | 2021-01-31 |    250 |
 |    9 | 2021-02-02 10:45:00 |    200 |    9 | 2021-02-01 |    250 |
 |    1 | 2021-02-02 08:15:00 |    250 | NULL | NULL       |   NULL |
 |    2 | 2021-02-02 08:30:00 |    200 | NULL | NULL       |   NULL |
 |    3 | 2021-02-02 08:55:00 |    150 | NULL | NULL       |   NULL |
 |    4 | 2021-02-02 09:15:00 |    125 | NULL | NULL       |   NULL |
 |   10 | 2021-02-02 11:15:00 |    250 | NULL | NULL       |   NULL |
 |   11 | 2021-02-02 11:30:00 |    150 | NULL | NULL       |   NULL |
 |   12 | 2021-02-02 11:45:00 |    200 | NULL | NULL       |   NULL |
 +------+---------------------+--------+------+------------+--------+

다만 UNION ALL의 경우 합집합이기 때문에 중복 행이 섞여 나올 수 있다. 이럴 경우에는 UNION을 사용해 주면 되는데, UNION의 경우에는 t1과 t2 사이의 중복 값을 걸러서 출력하는 것이어서 유니크 값을 거르는 인덱스가 하나 더 추가된다고 한다. 그래서 ㅡ중복을 거르지 않는 UNION ALL과 대비해서ㅡ 데이터의 크기에 따라 1.5배에서 4배까지 성능 차이가 날 수도 있다고.

그러니까, 웬만하면 FULL OUTER JOIN을 사용할 때는 UNION ALL을 쓰는 게 효율적이겠다. (+ 최소한으로 SELECT해서.)물론 애초에 모델링 차원에서 결합할 일을 배제하도록 설계하는 게 가장 좋겠지만.

<정리>

마지막으로 문법을 정리해 두고 글을 마친다. 순서대로 UNION ALL중복 미제거, UNION중복 제거으로 FULL OUTER JOIN을 적용하는 쿼리다.

SELECT * FROM t1 
LEFT JOIN t2 ON t1.id = t2.id 
UNION ALL 
SELECT * FROM t1 
RIGHT JOIN t2 ON t1.id = t2.id 
WHERE t1.id IS NULL

SELECT * FROM t1 
LEFT JOIN t2 ON t1.id = t2.id 
UNION 
SELECT * FROM t1 
RIGHT JOIN t2 ON t1.id = t2.id

<참고>

ubiq 블로그

sewonzzang님 블로그

<데이터 체크>

<

문제 출처: 프로그래머스, 식품분류별 가장 비싼 식품의 정보 조회하기

테이블명: food_product어느 대형마트의 식품 정보 테이블 견본 

컬럼명: product_id제품식별코드, product_name제품명, product_cd식품코드, category카테고리명, price가격

데이터베이스 구성: 1개 테이블, 5개 컬럼, 40개 로우

>

<시나리오>

당신은 A식품 영업팀 담당자다. 데이터를 통해 정량적으로 제품별 판매 성과를 확인하고자 마트 전산 기재된 자사 상품 기반으로 EDA탐색적 데이터 분석를 진행해보려고 한다. food_product 테이블에서 식품분류별로 가격이 가장 비싸거나 싼 '과자', '국', '김치', '식용유'의 category, price, product_name을 조회하고 싶다면 어떻게 쿼리를 짜야 할까?

<풀이>

'식품분류별' 이라 했으니 상품을 그룹으로 묶어야 한다. 또, GROUP BY와 윈도우 함수 중에는 윈도우 함수를 사용해야 한다. 왜냐면 연산된 결과값이 아니라 연산에 맞는 값을 가진 로우의 리스트를 출력해야 하니까. 이 부분에 대해 좀 더 깊이 알고 싶다면 윈도우 함수Window Function VS GROUP BY 포스트를 읽으면 된다.

WHERE절이 길어지겠다. 1) '과자', '국', '김치', '식용유' category의 상품 중에 2) 식품분류별로 가격이 가장 비싸거나/ 싼 상품만 골라 출력해야 하니까. 이를 반영해 WHERE절을 쓰면 아래와 같다. 이를 보면 서브쿼리를 IN 뒤에 조건절로 넣어 줬는데, 이에 대해 궁금하다면 다중행 서브쿼리 관련해 찾아보면 된다.

WHERE category IN('과자', '국', '김치', '식용유')
        AND price IN (SELECT MAX(price) OVER (PARTITION BY category) FROM food_product)
        -- 가장 비싼 상품의 리스트를 출력하거나

WHERE category IN('과자', '국', '김치', '식용유')
        AND price IN (SELECT MIN(price) OVER (PARTITION BY category) FROM food_product)
        -- 가장 싼 상품의 리스트를 출력하거나

또한 전문은 아래와 같이 쓸 수 있을 것이다. 

SELECT category
        , price
        , product_name
FROM food_product
WHERE category IN('과자', '국', '김치', '식용유')
        AND price IN (SELECT MAX(price) OVER (PARTITION BY category) FROM food_product)
        -- 가장 비싼 상품들만 출력
ORDER BY price DESC

SELECT category
        , price
        , product_name
FROM food_product
WHERE category IN('과자', '국', '김치', '식용유')
        AND price IN (SELECT MIN(price) OVER (PARTITION BY category) FROM food_product)
        -- 가장 싼 상품들만 출력
ORDER BY price DESC

<GROUP BY와 윈도우 함수Window Function는 어떻게 다른가>

윈도우 함수Window Function는 '행을 조건에 맞게 구분해 주는' 함수다. 이쯤 말하면 당신 머릿속에 떠오른 문법이 하나 있을 것이다. 맞다. GROUP BY. 이것 역시 행을 조건에 맞게 구분해 준다. 그러면 의문이 든다. GROUP BY 절과 대비해 윈도우 함수는 어떤 차이점이 있고 그래서 결국 어떤 상황에 사용되는 걸까. 이번 포스트는 이처럼 유사한 문맥에서 사용되는 두 문법, GROUP BY 절과 윈도우 함수의 차이에 대해 탐구해볼 것이다.

<'행을 묶는다' 는 행동에 대한 이해>

문법에 대해 다루기 앞서서 즉 '행을 묶는다'는 행동에 대해 먼저 이해할 필요가 있다. 행을 묶는다는 것은 일차적으로 행 사이의 공통점을 찾는다는 뜻이다. 아래와 같은 엑셀 파일이 있다고 가정해 보자. 

이 엑셀 파일에 '행을 묶으면' 어디에 포커스를 두느냐에 따라 아래와 같이 두 가지 결과물이 나올 수 있다.

1) 행에 포커스를 두는 경우. 아래는 성별 기준으로 행을 묶어서 성별 별 최연장자를 각각 출력한 경우다.

2) 연산한 값에 포커스를 두는 경우. 아래는 이름의 첫 글자, 성 기준으로 행을 묶어서 성 별 나이 최대값을 각각 출력한 경우다.

둘 모두 포커스만 다르지 '행을 묶었다'고 부를 만하다. 이때 후자는 GROUP BY로 구현할 수 있지만, 전자는 어렵다. GROUP BY는 특성상 동일한 기준을 가진 로우들을 하나로 '합치고' 들어가기 때문이다. 그래서 GROUP BY를 가진 쿼리의 SELECT 절에는 GROUP BY된 컬럼과 합쳐진 값들을 연산하는 집계함수밖에 올 수 없는 것이다. 이때 전자는 윈도우 함수로 구현될 수 있다.

<윈도우 함수Window Fuction>

'행과 행 간의 관계를 정의하거나 비교, 연산을 수행할 수 있는 함수'가 윈도우 함수에 대한 정의다. 위에서 알아봤듯이 GROUP BY는 동일한 기준을 가지는 로우들을 다 합쳐 버리지만, 윈도우 함수는 보존해 준다. 이 때문에 GROUP BY로 하지 못 하는 결과를 출력 가능하다. 그룹 내에서 순위/ 비율 뽑기, 연산에 맞는 결과 로우 출력하기(최대값을 가진 사람의 이름을 불러온다거나) 등.

윈도우 함수는 아래와 같은 형식으로 쓰인다.

SELECT WINDOW_FUNCTION (ARGUMENTS) OVER 
( [PARTITION BY 컬럼] [ORDER BY 컬럼] [WINDOWING 절] )
FROM 테이블명 ; 

   1) WINDOW_FUNCTION : 윈도우 함수 

   2) ARGUMENTS(인수) : 함수에 따라 0 ~ N개 인수가 지정될 수 있다. 

   3) PARTITION BY 절 : 전체 집합을 기준에 의해 소그룹으로 나눌 수 있다.   

   4) ORDER BY 절 : 어떤 항목에 대해 순위를 지정할 지 order by 절을 기술한다.

   5) WINDOWING 절 : WINDOWING 절은 함수의 대상이 되는 행 기준의 범위를 강력하게 지정할 수 있다. 

이때의 WINDOW_FUNCTION에는 전용 윈도우 함수 외에도 다양한 기존 함수를 가져다 쓸 수 있는데, 이 부분을 이 포스트에서 정리하지는 않고 참고 포스트 중 해당 내용에 대해 잘 정리한 포스트가 있어 재인용한다*링크는 SQL 전문가 가이드 2013 Edition를 요약했다고 한다. 해당 포스트를 참조해 쓰면, WINDOW_FUNCTION에는 다음과 같은 함수들이 올 수 있다.

   1) 순위 함수: RANK, DENSE_RANK, ROW_NUMBER

   2) 집계 함수: SUM, MAX, MIN, AVG, COUNT

   3) 비율 함수: CUME_DIST, PERCENT_RANK, NTILE, RATIO_TO_REPORT

윈도우 함수는 SQL의 다른 문법들보단 꽤 난이도가 있어 진입장벽이 높지만, 일단 익혀두고 나면 쿼리 다이어트에 도움을 주는 효자 함수다. 시간 내서 익숙해져 보자.

<문제>

<원본 문제: HackerRank The Report>

시험이 끝났다. 하지만 불행히도 당신은 학교 선생님이다. 아이들이 가벼운 마음으로 하교하는 것과 별개로 당신은 채점된 점수 기준으로 아이들의 등급을 매겨야 할 중요한 책무를 수행해야 한다. 당신 앞에는 Students 테이블과 Grades 테이블이 놓여 있다. 하나는 학생의 이름과 점수가 들어 있는 테이블이고 나머지 하나는 점수를 기준으로 학생을 그룹 나누는 등급 테이블이다. 두 테이블은 다음과 같은 값을 가진다. 비교적 덜 삽질하고 아이들의 등급을 매길 쿼리를 짤 방법은 없을까.

<풀이>

물론 저번과 마찬가지로 CASE WHEN으로 일일이 지정해주는 방법도 있겠지만, MIN 값과 MAX 값이 있는 테이블이 이렇게 예쁘게 있다면 LEFT JOIN으로 묶고 BETWEEN만 걸어 줘도 전체 등급을 뽑을 수 있다. LEFT JOIN은 INNER JOIN과 다르게 두 테이블에 동일한 값이 없어도 사용 가능하므로, 일단 옆에 붙여 놓고 같은 테이블에 있는 것처럼 연산에만 뽑아 쓰는 것이다.

SELECT IF(Grade < 8, NULL, Name), g.Grade, s.Marks
FROM Students s
	LEFT JOIN Grades g ON s.Marks BETWEEN g.Min_Mark AND g.Max_Mark
ORDER BY Grade DESC, Name, Marks

거기에, 그러니까 '상수'의 차에는 십 년에 걸쳐 쌓인 카탈로그 뭉치가 쌓여 있었다. 크기가 다양했고 당연히 색, 종이의 종류와 페이지 수, 낡은 정도와 인쇄 톤 그리고 냄새가 달랐다. 거기에선 분명한 축적의 냄새가 났다. 오랜 시간 부식과 흡착이 이루어진 뒤에야 나는 종이 본연의 것이 날아가 주변 환경에 순응하고 그 결과 완전한 변화가 이루어진 냄새. 어떤 기억은 사라지지 않는다. 흰 셔츠에 달라 붙은 커피 자국처럼 끝까지 남는다. 작가는 끈질기게 적체에 대해 쓴다.

신촌의 어느 중고 서점에서 삼 년 전에 구매한 이 책에는 이전 주인이 그어 놓은 흔적이 적체돼 있다. 내게는 영원히 '미지수'일 그 사람은 결코 무시할 수 없는 굵기의 흔적을 책에 남겨 놓았다. '인사적체'. 연두색 색연필로 진하게 그어진 밑줄은 이 책의 생이 끝날 때까지 따라다닐 테다. 나는 이 책을 읽으며 상수와 경애에 더해 미지수의 걸음을 좆게 된다. 때론 연두색 색연필로 굵게, 때론 연필로 각도를 달리해 두어 번 그려진, 밑줄을 따라 가며 나는 그 사람을 읽어 보려 애쓴다. 그러나 오독하겠지. 나는 그가 아니니까. 평생 해독되지 않는 것들에 대해 생각한다. 찾지도 못 할 서류 무더기 안에 적체된 마음들. 본래의 형태를 잃고 제멋대로 오독됐지만 여전히 소중한 것들. 그런 것들에 대해 가끔 생각한다. 

<문제>

<원본 문제: 프로그래머스 가격대별 상품 개수 구하기>

어떤 온라인 쇼핑몰이 있다고 하자. 이 쇼핑몰은 만 원 대부터 팔만 원 대까지 다양한 가격대의 상품을 취급하고 있다. 어느 날 프로덕트 팀에서 데이터 추출 요청이 들어왔다. 제품을 가격대별로 프로모션 진행하려 하니 만 원 단위로 그룹을 나눠 달라고. 이런 상황에서는 쿼리를 어떻게 짜야 할까? 제품 정보가 들어 있는 product 테이블은 다음과 같다.

<풀이>

CASE WHEN으로 일일이 지정해줘도 되지만, 가격이 들어간 컬럼이 있는 상황이므로 조건에 부합되는 대로 계산해서 답을 뽑아도 된다. FLOOR와 TRUNCATE로 각각 아래와 같이 풀 수 있다.

(1) FLOOR

아래와 같이 가격을 10000으로 나눈 뒤 FLOOR를 적용해 주면 각 가격대별로 유니크한 그룹으로 묶인다.   

SELECT FLOOR(price / 10000)*10000 AS price_group
             , COUNT(product_id) AS products
FROM product
GROUP BY price_group
ORDER BY price_group

(2)TRUNCATE

아래처럼 CASE WHEN으로 10,000원 미만 상품을 NULL 값으로 빼 버린 뒤 나머지를 TRUNCATE 해 줘도 동일한 방식으로 묶인다.

SELECT CASE
        WHEN price < 10000 THEN NULL
        ELSE TRUNCATE(price, -4) END AS price_group
        , COUNT(product_id) AS products
FROM product
GROUP BY price_group
ORDER BY price_group

결과값은 아래와 같이 나온다.

GROUP BY에 product_code를 넣어 주면 아래와 같이 그룹별 상품코드를 조회할 수 있겠다.

이제 나는 유령, 해파리, 꿈의 공통된 물성에 관해 적을 수 있다. 세상에서 유리되고 오롯이 한 사람의 안에만 존재하는 것들의 선득한 질감을 느낄 수 있다. 파리한 낯빛의 여자가 해파리 모양의 유령과 꿈을 뱉어내는 모습을 본다. 만진다. 기이할 정도로 차다. 금새 손을 떼지만 다시금 이끌린다. 에우로파의 바다를 더듬는 것 같은 차가움에 매혹된다. 광활한 우주의 형태와 그것을 이루는 가장 작은 것의 형태는 기묘하게 닮았다지. 이렇게나 가까운 것이 지독하게 멀게 느껴지는 것도 자연의 섭리를 따라서인 걸까. 월식의 뒤편에서 오래 잊고 있었던 해파리 떼를 본다.

나침반이 필요하다고 느꼈다. 말없이 표정을 찡그리고 있는 지표들을 보고 있을 때면, 무슨 망망대해에 표류해 온 것만 같았다. 지도도 방향도 없으니 직감에 의지해 나아가야 했다. 실패하든 성공하든 여전히 내 밑엔 바다가 있었고 나는 배 한 척을 가진 채 지도도 나침반도 없이 표류해야 했다. 나침반을 만들기 위해 분석을 배웠지만 여전히 어려웠다. 내가 정확히 어디쯤 있는 거지, 알려 줄 지도가 필요했다. 그리고 린 분석은 이에 대한 좋은 지도였다. (조금 낡긴 했지만. 19~20년 쯤이 이 책의 전성기였던 것 같다. 23년 넘어가서 쓴 글은 거의 없더라.) 자주 꺼내보게 될 것 같다. 사업 모델 전반에 관여해야 하는 창업자와 PM뿐 아니라 데이터 분석가들에게도 좋은 책이다. 지표를 설정하는 것에 대한 방법론이 꽤 상세하게 써져 있는데 GA4나 앰플리튜드 등 분석 툴에 적용하면 꽤 구체적으로 방향 잡을 수 있겠다 느껴져서. 특히 앰플리튜드의 북극성 지표와 이 책에서 다루는 OMTMOne Metric That Matter은 거의 동일한 개념 같았다. 이런 관점으로 본 분이 또 있나 싶어 찾아봤는데, 강한별 분석가 분이 이에 관련해 다뤘던 글이 있어서 첨부해 본다. (링크) 

데이터를 슬기롭게 다루는 방법에 관해

그거 알고 있는가. 데이터 사이언티스트가 하버드 비즈니스 리뷰에서 선정한 21세기에서 가장 섹시한 직업인 거(Data Scientist: The Sexxist Job of the 21st Century, 2012). 십여 년이 지났지만 현재 추이를 보면 데이터 사이언티스트가 왕좌에서 내려올 일은 아직 없는 것 같다. 

데이터라는 분야가 떠오른 지 십여 년이 지났고 여전히 유망하지만 우리 주변은 데이터와 내외하고 있는 듯하다. 데이터를 다루지만 도구처럼 사용하지는 못 한다. 외려 휘둘린다. 이런 기 센 데이터를 슬기롭게 잘 다루는 방법에 관해, 링크드인의 데이터 사이언티스트 모니카 로가티Monica Rogati가 정리한 글이 있어 공유해 본다. 글은 린 분석Lean analytics에서 가져왔으며 문맥에 따라 일부 수정했다.

데이터를 분석할 때 피해야 할 열 가지 함정

하나, 데이터에 결점이 없다고 가정하는 것. 이건 많은 사람들이 간과하는 부분인데, 데이터는 완벽하지 않다. 수집한 데이터의 결점을 제거하는 전처리 과정이 데이터 분석 시간의 대부분을 잡아먹는 경우도 많다. 혹시, 수집한 데이터에서 null이 몇 퍼센트쯤 되는지. 그 데이터가 오측정이 됐는지 검증해 봤나. 측정 자체에 오류가 있어 null 값만 한 삼십 퍼센트 나오고 우편번호 90210 지역에 데이터가 몰려 버리는 일들도 있을 수 있다.

둘, 표준화하지 않는 것. 예를 들어, 결혼식 장소로 인기 있는 도시의 목록을 만들고 있다고 가정해 보자. 이런 목록을 만들려면 결혼식에 참석하기 위해 어떤 도시로 비행기를 타고 온 사람들의 수를 셀 수 있는데, 이때 그 도시를 방문하는 전 항공 승객 수를 고려하지 않으면 그저 비행기를 이용하는 방문객 수가 많은 도시들의 목록이 될 수도 있다. 분석 목적에 맞는 데이터를 이용해야만 유의미한 분석 결과를 얻을 수 있다.

셋, 열외의 사용자들을 배제하는 것. 어떤 웹사이트를 하루에 천 번 이상 방문하는 사람들은 웹사이트의 열혈 팬일 수도 있지만 콘텐츠를 수집해 가는 검색 봇일지도 모른다. 어떤 경우든 이들을 무시하는 것은 실수일 수 있다.

넷, 반대로 열외의 사용자들을 포함시키는 것. 하루에도 천 번 이상 웹사이트를 방문하는 사람들은 예상치 못한 것을 알려줄 수도 있어서 정성적인 관점에서는 흥미로운 대상이겠지만 일반 모델을 구축할 때는 도움이 되지 않는다. "데이터 기반 제품을 구축할 때는 이런 사용자들을 배제해야 합니다. 그렇지 않으면 웹사이트의 '추천' 기능에서 하드코어 팬들이 좋아하는 아이템을 모든 유저에게 추천할 겁니다." 모니카는 조언한다.

다섯, 계절적 변동을 무시하는 것. "올해 성장률이 가장 높은 직업이 '인턴'이라고? 잠깐, 지금은 3월이잖아." 패턴을 살펴볼 때, 시간/ 요일/ 월에 따른 변화를 고려하지 않으면 잘못된 의사결정으로 이어진다. 선풍기가 주력 제품인 쇼핑몰에서 월매출 1억을 했다면 초봄인 3월에는 선방한 거겠지만 한여름인 8월에는 완전 망한 것처럼.

여섯, 성장을 평가할 때 전체 규모를 무시하는 것. 정황 정보는 매우 중요하다. "사업을 막 시작했을 때는 가족이 회원 가입만 해 주셔도 사용자 수가 두 배로 증가할 수 있습니다." 모니카는 말한다.

일곱, 지나치게 많아 의미를 잃은 데이터. 대시보드가 있어도 어떤 데이터를 봐야 할 지 모르면 아무 소용이 없다. 이럴 경우에는 고객을 코호트나 RFM 분석, 혹은 인구통계학/ 기술적 지표로 집단을 나눠 봄으로써 분석이 원활한 범위까지 데이터를 가공해야 한다.

여덟, 거짓 경보를 울리는 지표. 우리는 어떤 문제가 발생했을 때 빠르게 수습하기 위해 경보 시스템을 구축한다. 그러나 경보를 울리는 기준이 지나치게 예민해서 하루 웬종일 울려 댄다면 결국 우리는 그 경보를 무시하게 될 것이다.

아홉, 직접 수집한 데이터만 인정하는 배타적 태도. "여러분의 데이터와 다른 곳에서 수집한 데이터를 합치면 매우 소중한 정보를 얻을 수 있습니다." 모니카는 말한다. "최고의 고객들이 스시 식당이 밀집된 지역에 주로 살고 있습니까?" 그렇다면 이로부터 다음에 어떤 실험을 실시할지 좋은 아이디어를 얻을 수 있다. 아니면, 전략 자체를 짜는 데 영향을 줄 수도 있고.

열, 잡음에 초점을 두는 것. "인간의 속성은 패턴이 없는데도 패턴을 발견하게 돼 있습니다." 모니카는 경고한다. "허상 지표는 무시하고 한 발 물러서서 더 큰 그림을 볼 줄 알아야 합니다."

<

해당 포스트는 데이터리안의 RFM 고객 세분화 분석이란 무엇일까요, RFM 고객 세분화 분석에서 합리적으로 기준을 잡는 방법에 대해를 읽고 작성한 글이다. >

RFM 분석은 인사이트를 위한 분석이 아니다

글에서는 서두부터 못 박아 둔다. "RFM 분석은 인사이트를 위한 분석이 아니다." 또한 실무에서 행하는, 성과를 내는 대부분의 데이터 분석 역시 인사이트를 위한 분석이 아니라고 덧붙인다.

다시 말하면, 아무 데이터나 넣으면 기깔나는 인사이트를 뽑아 주는 어린왕자의 상자 같은 분석 프레임워크는 꿈 속에서나 볼 수 있는 거고, 어떤 가공 과정을 거치든 간에 데이터 분석은 나의 앎에서 플러스 마이너스 몇 퍼센트 한 값에서 결과물을 출력해줄 예정이라는 거다. 나쁘게 말하면 뽑기 확률 낮다는 거고 좋게 말하면 내가 놓친 요행이 없단 소리겠다. 오히려 좋다.

위에서 언급했듯이, RFM 분석은 인사이트를 발굴해내는 것보다는 이후에 집행할 액션 아이템에 맞춰 유의미한 고객 집단을 발굴해내는 데 그 목적이 있다. 좀 더 적확하게 말하면 일부 집단에만 선택적으로 돈을 쓰겠단 거다. (고객들이 추천을 빙자한 광고에 염증을 느끼는 시대다. 다만 충분히 개인의 특성을 반영해 작성된 푸시는 리텐션과 매출에 여전히 유의미하다.)

이처럼 뒤에 이어진 '후속 액션'에 초점을 둔다는 것이 RFM 분석의 특징이다. 이는 리소스가 투여되는 작업이고 보다 신중히 설계해야 한다. 섬세한 정의 없이 인원 수대로 열맞춰 자른 분석에 리소스를 투여할 수는 없지 않겠는가. 보고를 위한 숫자가 아닌 보다 의미있는 숫자를 캐내려면 서비스/ 도메인 파이프라인에 근거한 맞는 '얼마나'를 디자인해야 한다. 

'얼마나'를 가늠하는 것은 어려운 일이다. 판단을 내리는 일이라서 여러 지표가 엮여들 수밖에 없다. 이를 테면, Recency를 제대로 정하기 위해서는 우리 고객의 서비스 구매 주기를 먼저 파악해야 한다. 식품 커머스와 의류 커머스의 구매 주기가 같을 수는 없다. 평균 구매 주기가 정해진다면 우리 서비스의 '활성 사용자' 그리고 '이탈 사용자' 역시 정의할 수 있다. "측정할 수 없다면 관리할 수 없다"고 피터 드러커는 말했다. 반대로 측정된다면 관리할 수도 있는 것이다.

글에서 적듯이, 프레임워크는 내 손에 쥐어진 도구에 불과하다. 그보다 분석에서 중요한 것은 이 도구를 통해 내가 이루고자 하는 목적이다. 포트폴리오를 머리 쥐어 뜯으며 짜고 있을 미래의 나에게 쓴다. 네가 만든 그것은 목적이 있는 분석인가. 있다면 서비스의 방향성에 충분한 목적이었나. 그리고 그 목적을 충분히 달성한 분석이었나. 잊을 때쯤 한 번씩 돌아 보길 바란다. 

참고

RFM 고객 세분화 분석이란 무엇일까요

RFM 고객 세분화 분석에서 합리적으로 기준을 잡는 방법

푸시 클릭률 6배를 만든 고객집중

왜 NULL은 =이 아니라 is를 쓸까

SQL 문법을 처음 배울 때, 꼭 배우는 것이 있다. 'NULL을 찾을 때는 = NULL이 아니라 IS NULL을 사용해야 한다'. 의아하다. 대부분의 프로그래밍 언어에서는 (논리 연산에서) NULL을 0과 같이 취급하지 않는가. SQL에는 어떤 차이점이 있길래 이처럼 특별하게 NULL을 다룰까. 이번 포스트에는 SQL식 NULL의 정의에 대해 알아보면서 위 의문에 대해 파헤쳐 본다.

데이터가 '존재하지 않는 값' 그래서 '아직 모르는 값'

SQL에서의 NULL은 위키백과 기준으로 이렇게 정의된다. 'Null 또는 NULL은 구조적 질의언어(SQL)에서 데이터베이스 내의 값이 존재하지 않는다는 것을 지시하는 데 사용되는 특별한 표시어(Special marker)'. 

이처럼 NULL은 '존재하지 않는 값'이다. 0도 아니고 STRING도 아니고 다른 어느 타입도 아닌 그냥 알 수 없는 값. 데이터베이스에서 값이 존재하지 않는다는 사실을 따로 빼 둘 수 있다는 건 굉장히 중요한 의미를 가진다.

예를 들어, Primary Key를 설정한다고 하자. PK는 NOTNULL, NULL 값이어서는 안 된다. SQL에서는 PK에 NULL이 들어오면 오류를 출력한다. 이로써 의미 없는 로우를 사전에 걸러 낼 수 있다. 다른 컬럼의 경우에도 NULL의 활용이 가능하다. 'NULL'이라는 '존재하지 않는 값'이 이미 존재하니 '0'이나 '9999' 처럼 의미 없는 수로 존재하지 않는 값을 재정의할 필요가 없다. 이처럼 SQL은 NULL을 체크함으로써 SQL는 데이터베이스 자체의 정합성을 확고히 하고 있다.

NULL의 특성

위처럼 SQL의 NULL은 타 언어와 다른 형태로 정의되기 때문에 연산도 조금 다른 방식으로 이뤄진다. 아래에서 직접 예시와 함께 보면서 NULL의 특성을 알아보자.

1) 사칙연산

위와 같은 테이블이 있다고 하자. 첫 번째 로우는 NULL이고 두 번째 로우는 정수다. 이 테이블에 사칙연산을 적용하면: 

SELECT A + 5, A - 5, A * 5, A / 5 FROM nullcheck;

네 연산 모두 동일하게 NULL 값이 출력되는 걸 알 수 있다. 모르는 값에 숫자를 더하고 빼 봐야 여전히 알 수 없는 값인 것이다. 

2) 비교연산

이번에는 비교연산을 진행해 보자. 아래와 같은 테이블에 비교연산을 적용하면:

A = B, A > B, A < B를 각각 적용했을 때 A < B에서 둘 다 정수인 로우가 출력되는 것 외에 나오는 게 없다. 눈여겨볼 점은 1과 NULL뿐 아니라  NULL과 NULL끼리도 안 됐다는 점이다. SQL에서 NULL 값은 '알 수 없는 값' 이므로 알 수 없는 값 사이의 비교는 불가하다.

3) 집계함수

이번엔 집계함수다. 아래 테이블에 집계함수를 적용해 보면:

SELECT COUNT(*), COUNT(구매금액), SUM(구매금액), AVG(구매금액), MAX(구매금액), MIN(구매금액)
FROM zipge;

사칙연산에서처럼 출력이 아예 안 되는 게 아니라 NULL값을 자동으로 빼고 이외의 값을 연산해 준다. 다만, COUNT와 AVG는 주의할 필요가 있어 보인다. 상기 쿼리에서 COUNT(*)와 COUNT(구매금액)은 서로 다른 값을 리턴했다. 주문번호 10003은 주문금액이 NULL이지만 주문번호가 들어가 있으므로 COUNT(*)에서는 값으로 집계된 것이다. AVG의 경우에는 전체 구매액인 19000을 해당 컬럼에서 NULL이 아닌 로우인 3으로 나눈 값으로 출력됐다. 결과적으로 SUM(구매금액) / COUNT(*)와는 서로 다른 답을 출력하게 됐다.

NULL을 TRUE 아니면 FALSE로 설명할 수 있는 유일한 방법

이처럼 SQL은 NULL을 걸러내기 위해 기존 언어에서 사용되던 TRUE, FALSE로 이루어진 2값 논리에 NULL을 추가한 3가 논리(Three-valued logic)를 사용하고 있다.

이제 우리는 처음의 질문에 답할 수 있다. "왜 NULL은 =이 아니라 is를 써야 할까."

답변은 이쯤 되겠다. NULL은 TRUE나 FALSE로 설명될 수 없는 제 3의 값이다. 그래서 NULL은 비교연산될 수 없다. 말 그대로 모르는 값이기 때문이다. 그래서 SQL은 'NULL을 TRUE나 FALSE 두 가지로 비교연산할 수 있는' 문법을 만들었고 이게 IS NULL과 IS NOT NULL이었을 것이다.

참고

1) https://khdscor.tistory.com/53

2) https://yoongaemii.github.io/null_in_sql/

3) https://velog.io/@minnim1010/SQL-NULL-%EC%9D%B4-%EC%95%84%EB%8B%8C-IS-NULL%EC%9D%B8-%EC%9D%B4%EC%9C%A0-9irf8u7o