D-5: 윈도우 함수 ② — 차곡차곡 쌓고, 소계와 총계까지 한 번에

안녕하세요, 홍순구 튜터입니다. 지난 시간엔 데이터를 가로로 줄 세워 등수를 매기고(RANK·ROW_NUMBER), 앞뒤 행을 끌어와 비교하는(LAG·LEAD) 윈도우 함수를 배웠어요. 행을 그대로 둔 채 옆 칸에 순위를 붙이는 OVER() 의 정체를 잡은 거죠.

오늘은 같은 OVER() 를 한 단계 더 밀어붙여요. "1월부터 이번 달까지 팔로워를 차곡차곡 더한 누적 합계" 처럼, 처음부터 지금까지를 쌓아 가는 누적을 만들고, 창(window)이 들여다보는 범위를 직접 정하는 윈도우 프레임을 배웁니다. 지난 시간에 풀다 만 LAST_VALUE 의 숙제도 이 프레임으로 깔끔히 마무리하고요.

거기에 더해, 보고서의 끝판왕인 소계와 총계를 한 번에 뽑아 주는 ROLLUP·CUBE 까지 갑니다. "5월 게시물 몇 개, 6월 게시물 몇 개, 그리고 전체 몇 개" 를 쿼리 한 방에 내는 거예요.

 오늘의 여정
   ① 누적이란 — 집계는 한 값으로 뭉치고, 누적은 차곡차곡 쌓아 간다
   ② 누적 SUM — 1월부터 이번 달까지 팔로워 합치기
   ③ 누적 AVG — 그달까지의 평균
   ④ 윈도우 프레임 ROWS BETWEEN — 창의 범위를 직접 정한다 (이동 평균)
   ⑤ LAST_VALUE 숙제 풀기 — 기본 프레임의 함정
   ⑥ ROWS vs RANGE — 행으로 셀까, 값으로 셀까
   ⑦ ROLLUP — 소계와 총계를 한 번에
   ⑧ CUBE · GROUPING SETS — 원하는 소계만 골라서

💡 오늘 수업의 핵심 — "ORDER BY 를 붙인 OVER() 는 처음부터 이 행까지를 쌓아 누적을 만든다. 그 쌓는 범위를 직접 정하는 게 프레임(ROWS BETWEEN)이고, 소계·총계를 한 번에 뽑는 게 ROLLUP·CUBE 다"

🎯 학습 목표

• 누적 SUM·AVG OVER (ORDER BY ...) 로 월별 누적 팔로워·누적 평균을 계산하고, ORDER BY 가 누적을 만드는 원리를 이해한다. (SQLD 2과목 'SQL 활용 — 윈도우 함수', ★빈출)
• 윈도우 프레임(ROWS/RANGE BETWEEN)으로 창의 범위를 직접 정하고, 둘의 차이와 LAST_VALUE 기본 프레임 함정을 구분한다.
• ROLLUP·CUBE·GROUPING SETS 로 소계·총계를 한 번에 뽑고, GROUPING() 함수로 소계 행을 가려낸다. (SQLD 2과목 '그룹 함수', ★★★ 빈출)

Step 1: "누적이란 무엇인가 — 집계는 뭉치고, 누적은 쌓아 간다"

지난 시간 윈도우 함수의 핵심은 "행을 뭉치지 않고 그대로 둔 채 옆에 값을 붙인다" 였어요. 오늘 배울 누적도 그 연장선이에요. 다만 옆에 붙이는 값이 순위가 아니라 "여기까지의 합계" 라는 점이 달라요.

은행 통장을 떠올려 보세요. 입금 내역이 한 줄씩 있고, 그 옆에 "잔액" 칸이 있죠? 잔액은 그 줄까지의 입금을 전부 더한 값이에요. 줄이 내려갈수록 잔액이 차곡차곡 불어나고요. 이게 바로 누적(running total)이에요.

 집계 (C-4) — 여러 달을 "한 값으로 뭉친다"
   100  108  120 ...   ──SUM()──►   713      (결과 한 줄)

 누적 (오늘) — 각 달을 "그대로 두고 그 줄까지의 합을 옆에 붙인다"
   월     팔로워 │ 누적
   1월     100  │  100      통장 잔액처럼
   2월     108  │  208      한 줄 내려갈 때마다
   3월     120  │  328      차곡차곡 불어난다
   ...     ...  │  ...

C-4 의 SUM 은 6개월 팔로워를 더해 713 이라는 한 값으로 뭉쳤어요. 오늘의 누적은 6줄을 6줄 그대로 두고, 각 줄 옆에 "그달까지의 합" 을 붙여요. 1월은 100, 2월은 100+108=208, 3월은 208+120=328… 이런 식이죠.

이걸 가능하게 하는 게 지난 시간 배운 OVER() 에 ORDER BY 를 더하는 거예요. 오늘 데이터는 지난 시간에 만든 월별 팔로워 스냅샷 표(account_monthly_stat)를 그대로 써요. 회원 4명(김재훈·강지수·김유나·박지훈)의 2026년 1월부터 6월까지 팔로워 수가 담겨 있죠.

💡 한 줄 정리 — 집계(SUM)는 여러 행을 한 값으로 뭉치고, 누적은 행을 그대로 둔 채 "그 행까지의 합" 을 옆에 붙인다. 통장 잔액을 떠올리면 쉽다.

Step 2: "1월부터 이번 달까지 더하기 — 누적 SUM OVER" ★빈출

바로 누적 팔로워를 구해 볼게요. 회원별로 1월부터 그달까지 팔로워를 차곡차곡 더합니다.

-- sql/queries/D5_window_frame_rollup.sql
SELECT m.nickname,
       TO_CHAR(s.stat_month, 'YYYY-MM') AS mon,
       s.follower_count,
       SUM(s.follower_count) OVER (PARTITION BY s.member_id ORDER BY s.stat_month) AS cum_follower
FROM   account_monthly_stat s
JOIN   member m ON m.member_id = s.member_id
ORDER BY s.member_id, s.stat_month;

두 가지가 눈에 들어와야 해요. ORDER BY s.stat_month 는 "1월 → 2월 → … 순서로 쌓아라" 라는 뜻이고, PARTITION BY s.member_id 는 지난 시간 배운 그 그룹 나누기예요. 회원이 바뀌면 누적을 0부터 다시 시작하라는 거죠. 김재훈과 박지훈의 결과를 떼어 보면 이래요.

김재훈을 보면 100 → 208(100+108) → 328(208+120) … 통장 잔액처럼 차곡차곡 불어나죠. 그리고 김재훈의 6월(713)에서 박지훈으로 넘어가는 순간, 누적이 713 을 이어받지 않고 박지훈의 1월값 90 부터 다시 시작해요. PARTITION BY 가 회원 경계에서 누적을 끊어 준 거예요. 강지수는 6월 누적이 1460, 김유나는 1260 까지 쌓여요.

ORDER BY 를 빼면 어떻게 될까요? 그러면 "그 행까지" 라는 순서 자체가 없어져서, 누적이 아니라 그 회원의 6개월 전체 합계(713)가 모든 행에 똑같이 붙어요. ⚠️ 누적을 만들려면 OVER() 안에 ORDER BY 가 반드시 있어야 한다는 점, 이게 시험 단골이에요.

💡 한 줄 정리 — SUM(x) OVER (PARTITION BY 그룹 ORDER BY 정렬) 은 그룹 안에서 정렬 순서대로 "그 행까지의 합" 을 쌓는다. ORDER BY 가 없으면 누적이 아니라 그룹 전체 합이 된다.

Step 3: "그달까지의 평균 — 누적 AVG OVER"

함수만 SUM 에서 AVG 로 바꾸면 누적 합계가 누적 평균이 돼요. "1월부터 그달까지의 평균 팔로워" 를 구하는 거죠. 매달 들쭉날쭉한 값을 평탄하게 펴서 추세를 보고 싶을 때 써요.

SELECT m.nickname,
       TO_CHAR(s.stat_month, 'YYYY-MM') AS mon,
       s.follower_count,
       ROUND(AVG(s.follower_count) OVER (PARTITION BY s.member_id ORDER BY s.stat_month), 1) AS cum_avg
FROM   account_monthly_stat s
JOIN   member m ON m.member_id = s.member_id
ORDER BY s.member_id, s.stat_month;

김재훈의 결과만 보면 누적 평균이 어떻게 움직이는지 한눈에 들어와요.

1월은 100 한 개뿐이니 평균도 100 이에요. 2월은 (100+108)/2 = 104, 3월은 (100+108+120)/3 = 109.3 … 이렇게 그달까지의 값을 다 모아 평균을 내요. 4월에 팔로워가 110 으로 한 번 줄었지만, 누적 평균(109.5)은 거의 안 흔들렸죠? 누적 평균은 한 달의 출렁임을 부드럽게 눌러서 "전체적으로 우상향인가" 같은 큰 흐름을 보여줘요.

누적 합계와 누적 평균은 OVER() 절이 완전히 똑같아요. 함수 이름만 다를 뿐이죠. 한 번 누적의 구조를 익혀 두면 SUM·AVG·COUNT·MAX 어디에든 그대로 붙일 수 있어요.

💡 한 줄 정리 — AVG(x) OVER (... ORDER BY ...) 는 "그 행까지의 평균" 을 누적으로 낸다. 한 달의 출렁임을 눌러 큰 추세를 보여 주며, 누적 합계와 OVER() 구조는 동일하다.

Step 4: "창의 범위를 직접 정하기 — 윈도우 프레임 ROWS BETWEEN"

지금까지 누적은 "처음부터 이 행까지" 를 더했어요. 그런데 사실 우리는 한 번도 "처음부터 이 행까지" 라고 직접 적은 적이 없어요. ORDER BY 만 붙였더니 데이터베이스가 알아서 그 범위로 더해 준 거죠. 이 "더하는 범위" 를 윈도우 프레임(frame)이라고 불러요. 그리고 이 프레임은 우리가 직접 정할 수 있어요.

프레임을 적는 문법이 ROWS BETWEEN 시작 AND 끝 이에요. 시작과 끝에 들어갈 수 있는 표현은 다섯 가지예요.

 ROWS BETWEEN 시작 AND 끝 — 다섯 가지 경계
   UNBOUNDED PRECEDING   맨 처음 행부터
   n PRECEDING           현재 행에서 n 줄 위
   CURRENT ROW           현재 행
   n FOLLOWING           현재 행에서 n 줄 아래
   UNBOUNDED FOLLOWING   맨 끝 행까지

예를 들어 누적은 사실 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW(맨 처음부터 현재 행까지)예요. 우리가 Step 2 에서 생략한 그 기본값이죠. 이제 이 범위를 좁혀서 "최근 3개월" 만 보는 이동 평균(moving average)을 만들어 볼게요.

SELECT m.nickname,
       TO_CHAR(s.stat_month, 'YYYY-MM') AS mon,
       s.follower_count,
       ROUND(AVG(s.follower_count) OVER (PARTITION BY s.member_id ORDER BY s.stat_month
             ROWS BETWEEN 2 PRECEDING AND CURRENT ROW), 1) AS mov_avg_3m
FROM   account_monthly_stat s
JOIN   member m ON m.member_id = s.member_id
WHERE  s.member_id IN (1, 12)
ORDER BY s.member_id, s.stat_month;

ROWS BETWEEN 2 PRECEDING AND CURRENT ROW 는 "내 위로 2줄 + 현재 줄 = 최근 3개월" 을 평균 내라는 뜻이에요. 누적 평균(처음부터 다 봄)과 어떻게 다른지 김재훈으로 비교해 보세요.

4월부터 차이가 드러나요. 누적 평균(Step 3)은 4월에 109.5 였는데, 3개월 이동 평균은 112.7 이에요. 이동 평균은 1·2월의 낮은 값을 더 이상 보지 않고 최근 3개월(2·3·4월 = 108·120·110)만 평균 내거든요. 6월을 보면 더 확실해요. 누적 평균은 118.8 인데 이동 평균은 128.3 이에요. 최근 석 달(4·5·6월 = 110·130·145)의 상승세만 잡아내서 더 높게 나오는 거죠.

이동 평균은 "오래된 과거는 잊고 최근 흐름만" 보고 싶을 때 써요. 주가 차트의 5일선·20일선이 바로 이 이동 평균이에요.

💡 한 줄 정리 — 윈도우 프레임 ROWS BETWEEN 시작 AND 끝 은 계산할 행의 범위를 직접 정한다. 2 PRECEDING AND CURRENT ROW 는 최근 3개월 이동 평균이 되고, 생략하면 누적(처음부터 현재까지)이 기본이다.

Step 5: "지난 시간에 풀다 만 숙제 — LAST_VALUE 의 함정" ★빈출

지난 시간 끝에 LAST_VALUE 가 이상하게 동작하는 걸 보고 숙제로 남겼던 거 기억나세요? "구간의 마지막 값" 을 가져와야 하는데 자꾸 현재 행의 값만 돌려줬죠. 오늘 배운 프레임으로 그 정체를 밝히고 해결해요.

각 회원의 "최종(6월) 팔로워" 를 모든 행에 붙이고 싶어요. 먼저 프레임 없이 LAST_VALUE 를 그냥 써 보고(lv_default), 프레임을 끝까지 늘린 버전(lv_fixed)과 나란히 비교할게요.

SELECT m.nickname,
       TO_CHAR(s.stat_month, 'YYYY-MM') AS mon,
       s.follower_count,
       LAST_VALUE(s.follower_count) OVER (PARTITION BY s.member_id ORDER BY s.stat_month) AS lv_default,
       LAST_VALUE(s.follower_count) OVER (PARTITION BY s.member_id ORDER BY s.stat_month
             ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING) AS lv_fixed
FROM   account_monthly_stat s
JOIN   member m ON m.member_id = s.member_id
WHERE  s.member_id IN (1, 12)
ORDER BY s.member_id, s.stat_month;

lv_default 를 보세요. "마지막 값" 을 달라고 했는데 매 줄 자기 자신의 값(100·108·120…)이 나와요. 이게 함정이에요. 원인은 Step 4 에서 본 기본 프레임이에요. ORDER BY 만 쓰면 프레임이 "처음부터 현재 행까지" 로 잡혀요. 그러니 1월 행에서 LAST_VALUE 가 보는 범위는 1월 한 줄뿐이고, 그 안의 마지막은 당연히 1월 자기 자신이죠. 4월 행에선 1~4월까지가 범위라 마지막이 4월 자신이고요.

lv_fixed 는 프레임을 ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING(현재 행부터 맨 끝까지)으로 늘렸어요. 이제 어느 행에서 보든 범위의 끝이 진짜 마지막 행(6월)이라, 모든 줄에 145(김재훈의 6월값)가 제대로 붙어요. 박지훈도 마찬가지로 전부 175(6월값)가 나오고요.

⚠️ 함정 — LAST_VALUE 를 프레임 없이 ORDER BY 만 쓰면 기본 프레임(현재 행까지) 탓에 "마지막 값" 이 아니라 "현재 행 값" 이 나온다. 진짜 마지막을 보려면 ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING(또는 UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING)으로 프레임을 끝까지 늘려야 한다. SQLD 단골 함정이다.

💡 한 줄 정리 — FIRST_VALUE 는 기본 프레임에서도 잘 동작하지만, LAST_VALUE 는 기본 프레임이 "현재 행까지" 라 함정이 생긴다. 프레임을 맨 끝까지 늘려야 진짜 마지막 값이 나온다.

Step 6: "행으로 셀까, 값으로 셀까 — ROWS vs RANGE" ★빈출

프레임을 적을 때 ROWS 말고 RANGE 라고 쓸 수도 있어요. 둘은 비슷해 보이지만 동점(같은 정렬값)을 만나면 결과가 갈려요. 이 차이가 시험에 자주 나와요.

• ROWS 는 물리적인 행을 세요. "위로 2줄" 하면 정확히 2줄이에요.
• RANGE 는 정렬값(value)을 봐요. 정렬 기준이 같은 값을 가진 행(peer)들을 같은 값끼리 묶어서 취급해요.

차이를 보려면 정렬 기준에 동점이 있어야 해요. 그래서 이번엔 회원 구분 없이 24행 전체를 팔로워 수(follower_count)로 줄 세워 누적해 볼게요. 마침 팔로워 100 인 행이 둘(김재훈 1월·박지훈 3월), 130 인 행이 둘(김재훈 5월·박지훈 4월) 있어요.

SELECT TO_CHAR(stat_month, 'YYYY-MM') AS mon,
       member_id,
       follower_count,
       SUM(follower_count) OVER (ORDER BY follower_count
             ROWS  BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS rows_sum,
       SUM(follower_count) OVER (ORDER BY follower_count
             RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS range_sum
FROM   account_monthly_stat
ORDER BY follower_count, member_id;

팔로워가 낮은 쪽 여덟 행만 떼어 보면 차이가 또렷해요.

팔로워 100 인 두 행을 보세요. ROWS 는 첫 100 행에서 285(90+95+100), 둘째 100 행에서 385(90+95+100+100)로 한 줄씩 차곡차곡 더해요. 반면 RANGE 는 두 100 행 모두 385 예요. 정렬값이 같은 행(peer)을 하나로 봐서, 두 100 을 한꺼번에 포함한 합을 똑같이 주는 거죠. 130 인 두 행에서도 똑같아요. ROWS 는 733·863 으로 갈리고, RANGE 는 둘 다 863 이에요.

 정렬값이 같은 행(동점)을 만났을 때
   ROWS  : 물리적 행을 한 줄씩 센다    →  285, 385 (다르다)
   RANGE : 같은 값을 함께 묶어서 본다  →  385, 385 (같다)

여기서 Step 4·5 의 기본 프레임이 다시 등장해요. ORDER BY 만 쓸 때의 기본 프레임은 사실 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 예요. ROWS 가 아니라 RANGE 죠. 그래서 동점이 있는 데이터에서 누적을 낼 땐, 의도와 다르게 동점이 하나로 합쳐질 수 있어요. "한 줄씩 정확히" 누적하고 싶으면 ROWS 를 명시하는 게 안전해요.

⚠️ 함정 — OVER (ORDER BY ...) 의 기본 프레임은 ROWS 가 아니라 RANGE 다. 정렬 기준에 동점이 있으면 누적값이 동점끼리 같아진다. 행 단위로 또박또박 누적하려면 ROWS 를 직접 적는다.

💡 한 줄 정리 — ROWS 는 물리적 행을 세고, RANGE 는 같은 정렬값을 하나로 본다. 동점이 없으면 결과가 같지만, 동점이 있으면 RANGE 는 peer 를 한꺼번에 포함해 값이 같아진다.

Step 7: "소계와 총계를 한 번에 — ROLLUP" ★★★ 빈출

이제 윈도우에서 잠깐 내려와, 보고서의 단골인 소계(subtotal)와 총계(grand total)를 다뤄요. "5월 게시물 몇 개, 6월 게시물 몇 개, 그리고 전체 몇 개" 를 한 쿼리로 뽑는 거예요.

C-4 에서 배운 GROUP BY 는 그룹별 개수만 줬어요. 소계나 총계 행은 따로 쿼리를 또 날려서 합쳐야 했죠. ROLLUP 은 GROUP BY 를 살짝 확장해서, 그룹별 집계에 소계 행과 총계 행을 자동으로 덧붙여 줘요. 지난 시간 예고한 그 기능이에요.

오늘은 게시물에 새로 붙인 카테고리 컬럼(category)을 써요. 게시물 50개에 여행·맛집·일상·음악·패션 다섯 카테고리가 붙어 있어요. 월별·카테고리별 게시물 수를 소계·총계와 함께 뽑아 볼게요.

SELECT TO_CHAR(created_at, 'YYYY-MM') AS mon,
       category,
       COUNT(*) AS n,
       GROUPING(TO_CHAR(created_at, 'YYYY-MM')) AS g_mon,
       GROUPING(category)                       AS g_cat
FROM   post
GROUP BY ROLLUP(TO_CHAR(created_at, 'YYYY-MM'), category)
ORDER BY g_mon, mon, g_cat, category;

상세 행(카테고리별 개수) 사이사이에 소계와 총계가 끼어든 게 보이죠? 5월 다섯 카테고리(맛집5·여행6·음악3·일상6·패션3) 다음에 5월 소계 23 이 붙고, 6월 다음에 6월 소계 27, 맨 끝에 전체 총계 50 이 붙어요. GROUP BY 였다면 9줄(상세)만 나왔을 텐데, ROLLUP 이 소계 2줄 + 총계 1줄을 더해 12줄을 만든 거예요.

그런데 소계·총계 행은 category 칸이 비어 있어요(NULL). 상세 행의 NULL 과 헷갈리지 않을까요? 이걸 가려 주는 게 GROUPING() 함수예요. GROUPING(category) 는 그 행에서 카테고리가 소계로 뭉쳐졌으면 1, 실제 값이면 0 을 줘요. 표의 g_cat 칸을 보세요. 소계·총계 행만 1 이죠. 그래서 "소계 행만 골라 줘" 하려면 GROUPING(category) = 1 같은 조건을 쓰면 돼요.

 GROUP BY ROLLUP(월, 카테고리) — 오른쪽 컬럼부터 단계적으로 뭉친다
   (월, 카테고리)  →  상세 9줄          g_mon=0 g_cat=0
   (월)            →  월 소계 2줄        g_mon=0 g_cat=1
   ()              →  전체 총계 1줄      g_mon=1 g_cat=1

💡 한 줄 정리 — GROUP BY ROLLUP(a, b) 는 상세 + (a별 소계) + 총계를 한 번에 낸다. 오른쪽 컬럼부터 단계적으로 뭉치며, 소계·총계 행은 GROUPING() 함수가 1 로 표시해 가려낼 수 있다.

Step 8: "모든 조합의 소계, 그리고 원하는 것만 — CUBE · GROUPING SETS"

ROLLUP(월, 카테고리) 은 월별 소계만 줬어요. 그런데 "월별 소계도 보고 카테고리별 소계도 보고 싶다" 면요? 이때 CUBE 를 써요. CUBE 는 가능한 모든 조합의 소계를 만들어 줘요.

SELECT CASE WHEN GROUPING(TO_CHAR(created_at, 'YYYY-MM'))=1 AND GROUPING(category)=1 THEN '총계'
            WHEN GROUPING(TO_CHAR(created_at, 'YYYY-MM'))=1 THEN '카테고리 소계'
            WHEN GROUPING(category)=1 THEN '월 소계'
            ELSE '상세' END AS kind,
       TO_CHAR(created_at, 'YYYY-MM') AS mon,
       category,
       COUNT(*) AS n
FROM   post
GROUP BY CUBE(TO_CHAR(created_at, 'YYYY-MM'), category)
ORDER BY GROUPING(TO_CHAR(created_at, 'YYYY-MM')), mon,
         GROUPING(category), category;

GROUPING() 을 CASE 와 엮어서 각 행이 어떤 종류인지(상세/월 소계/카테고리 소계/총계) 이름표를 붙였어요.

ROLLUP 은 12줄이었는데 CUBE 는 17줄이에요. 월 소계 2줄과 총계 1줄에 더해, ROLLUP 에는 없던 카테고리 소계 5줄(맛집12·여행14·음악8·일상13·패션3)이 추가됐거든요. "월로도 잘라 보고, 카테고리로도 잘라 보고, 둘 다 무시한 총계까지" 한 번에 나오는 거죠.

여기서 패션을 눈여겨보세요. 카테고리 소계에 패션 3 이 분명히 있어요. 그런데 상세 행을 보면 5월 패션(3)은 있는데 6월 패션 행이 아예 없죠? 패션 게시물은 5월에만 있고 6월엔 한 개도 없거든요. ⚠️ CUBE 는 실제로 존재하는 조합만 상세 행으로 만들어요. 그래서 (2026-06, 패션) 같은 빈 조합은 0 짜리 행조차 만들지 않아요. 데이터에 없는 조합이 결과에서 통째로 빠진다는 점, 보고서를 읽을 때 꼭 기억하세요.

마지막으로 GROUPING SETS 예요. CUBE 가 모든 조합을 다 만든다면, GROUPING SETS 는 "내가 원하는 소계 조합만 콕 집어" 만들어요. 상세도 총계도 필요 없고 월 소계와 카테고리 소계만 보고 싶다면 이렇게 써요.

SELECT TO_CHAR(created_at, 'YYYY-MM') AS mon,
       category,
       COUNT(*) AS n
FROM   post
GROUP BY GROUPING SETS ((TO_CHAR(created_at, 'YYYY-MM')), (category))
ORDER BY mon, category;

GROUPING SETS ((월), (카테고리)) 는 "월로 묶은 소계 한 벌, 카테고리로 묶은 소계 한 벌만 줘" 라는 뜻이에요. 결과는 딱 7줄(월 소계 5월 23·6월 27 + 카테고리 소계 5줄)이에요. 상세 9줄도, 총계 1줄도 없어요. 필요한 소계만 골라 가벼운 보고서를 만들 때 좋아요.

 세 형제 비교 (월 × 카테고리 기준)
   ROLLUP(월, 카테고리)   →  상세 + 월 소계 + 총계            (12줄)
   CUBE(월, 카테고리)     →  상세 + 월 소계 + 카테고리 소계 + 총계 (17줄)
   GROUPING SETS(...)     →  내가 적은 조합만                  (여기선 7줄)

💡 한 줄 정리 — CUBE 는 가능한 모든 조합의 소계(+총계)를 내고, GROUPING SETS 는 원하는 조합만 골라 낸다. CUBE 는 데이터에 없는 조합은 행을 만들지 않으니, 빠진 조합에 주의한다.

마무리

오늘은 윈도우 함수를 누적과 프레임까지 밀어붙이고, 보고서용 소계·총계를 한 번에 뽑는 ROLLUP·CUBE 까지 봤어요. 지난 시간의 "줄 세우기" 에서 오늘의 "쌓기와 묶기" 로, 분석 쿼리의 큰 줄기를 거의 다 잡은 셈이에요.

오늘 배운 핵심 세 가지

• 💡 누적 — OVER() 에 ORDER BY 를 붙이면 "그 행까지" 를 쌓는 누적이 된다. PARTITION BY 로 그룹마다 0부터 다시 쌓고, SUM·AVG 어디에든 같은 구조로 붙는다.
• 💡 프레임 — ROWS BETWEEN 으로 계산 범위를 직접 정한다. 기본 프레임은 "현재 행까지" 라 LAST_VALUE 가 함정이 되고, 기본값이 RANGE 라 동점에서 ROWS 와 갈린다.
• 💡 소계 — ROLLUP 은 계층 소계 + 총계, CUBE 는 모든 조합 소계, GROUPING SETS 는 원하는 조합만. GROUPING() 함수가 소계 행을 1 로 표시해 가려낸다.

다음 시간 예고

오늘 우리는 데이터를 세로로 쌓아 소계를 냈어요. 다음 시간엔 방향을 틀어서, 데이터를 가로로 펼쳐요. "월" 을 행이 아니라 열(컬럼)로 바꿔서 5월·6월을 나란히 놓는 PIVOT, 한 게시물에 달린 해시태그 여러 개를 #여행 #제주 #바다 처럼 한 줄 문자열로 모아 주는 LISTAGG, 그리고 인기 게시물 상위 N 개만 똑 떼어 내는 Top-N 까지 배웁니다. 오늘 만든 카테고리가 다음 시간 가로 교차표에서 다시 등장해요.

과제

오늘 배운 누적·프레임·소계를 직접 써 보는 과제예요. 결과가 몇 줄 나올지, 누적값이 얼마가 될지 먼저 머릿속으로 그려 본 뒤 실행해서 맞는지 확인해 보세요.

[기초] 누적 SUM 과 누적 AVG

account_monthly_stat 표로 강지수(회원 6번)의 월별 누적 팔로워와 누적 평균을 함께 구해 보세요. (가) SUM(...) OVER (... ORDER BY stat_month) 로 1월부터 그달까지의 누적 팔로워를, 같은 줄에 AVG(...) OVER (...) 로 누적 평균을 붙여 6줄을 출력하세요. (나) 6월 행의 누적 팔로워가 강지수의 6개월 전체 합계와 같은지, 6월 누적 평균이 6개월 전체 평균과 같은지 확인하고 왜 그런지 한 줄로 설명해 보세요.

[응용] 이동 평균과 LAST_VALUE

account_monthly_stat 표로 다음을 해 보세요. (가) 김유나(회원 9번)의 팔로워에 대해 ROWS BETWEEN 1 PRECEDING AND CURRENT ROW 로 최근 2개월 이동 평균을 구하고, 누적 평균(ORDER BY 만 쓴 버전)과 한 줄에 나란히 놓아 어떤 달에 둘이 가장 크게 벌어지는지 찾아보세요. (나) LAST_VALUE 로 각 회원의 6월 팔로워를 모든 행에 붙이되, 프레임을 안 쓴 버전과 ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING 을 쓴 버전이 어떻게 다른지 직접 확인해 보세요.

[심화] ROLLUP·CUBE 와 GROUPING

post 표(카테고리 컬럼 포함)로 다음을 해 보세요. (가) ROLLUP(category) 로 카테고리별 게시물 수와 전체 총계를 구해, 총 몇 줄이 나오는지 확인하세요. (나) CUBE(TO_CHAR(created_at,'YYYY-MM'), category) 결과에서 GROUPING() 을 조건으로 써서 "카테고리 소계 행" 만 골라내 보세요. 그리고 그 결과에 6월 패션이 왜 보이지 않는지(또는 보이는지) 설명해 보세요.

생각해볼 주제

1. 누적을 데이터베이스에서 계산할까, 애플리케이션에서 계산할까

누적 팔로워 그래프를 그릴 때, 오늘처럼 데이터베이스가 SUM OVER 로 누적을 계산해 줄 수도 있고, 월별 원본 값만 받아 와 애플리케이션 코드가 반복문으로 더해 갈 수도 있어요. 두 방식은 각각 어떤 상황에서 유리할까요? 데이터 양, 같은 누적을 여러 화면에서 재사용하는지, 누적 기준(월별·주별)이 자주 바뀌는지를 기준으로 견줘 보세요.

2. 소계·총계를 SQL 의 ROLLUP 으로 낼까, 화면단에서 합칠까

월별·카테고리별 게시물 수 보고서에서 소계와 총계가 필요할 때, ROLLUP·CUBE 로 데이터베이스가 한 번에 내려줄 수도 있고, 상세 데이터만 받아 와 화면(또는 엑셀)에서 합계를 낼 수도 있어요. 소계 행과 상세 행이 한 결과에 섞여 내려올 때 생기는 장단점은 무엇일까요? GROUPING() 으로 소계 행을 구분해야 하는 부담과, 그럼에도 데이터베이스에서 집계할 때의 이점을 함께 따져 보세요.

3. 윈도우 프레임의 기본값을 외워 둬야 하는 이유

오늘 LAST_VALUE 함정과 ROWS/RANGE 차이는 모두 "기본 프레임이 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW" 라는 한 가지 사실에서 나왔어요. 문법을 줄여 쓸 수 있게 해 주는 이런 "똑똑한 기본값" 이, 어떤 경우엔 오히려 함정이 되는 이유는 무엇일까요? 기본값에 의존할 때와 프레임을 항상 명시할 때의 트레이드오프를, 가독성과 버그 예방 관점에서 생각해 보세요.