핵심 인사이트 (3줄 요약)

  1. 본질: 집계 함수(Aggregate Function)는 여러 행(Multi-Row)의 데이터를 입력으로 받아, 그것들을 수학적으로 비비고 압축하여 오직 단 1개의 결과값(Single-Value)만을 뱉어내는 통계 특화 수학 함수 군단이다.
  2. 가치: 1억 건짜리 영수증(로우 데이터) 테이블을 사람이 눈으로 읽을 수는 없다. 집계 함수를 GROUP BY와 융합하면, 1억 건의 거래 내역을 "2026년 각 지점별 월평균 매출액 12줄"이라는 의사결정이 가능한 고차원 비즈니스 리포팅 데이터로 0.1초 만에 깎아내어 경영진의 화면에 쏴준다.
  3. 융합: 집계 함수를 쓸 때 COUNT(*)를 제외한 모든 함수(SUM, AVG, MAX 등)는 NULL 값을 투명 인간 취급하고 계산에서 완전히 배제하는 치명적 딜레마를 갖고 있어, 실무 DBA는 평균치 뻥튀기 오류를 막기 위해 COALESCE나 NVL과 같은 널 치환 함수를 겹겹이 융합하여 정합성을 방어한다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

  • 개념: 집계 함수는 말 그대로 데이터를 '집계(Aggregation)'하는 함수다. SQL의 일반 단일 행 함수(예: LOWER(이름), ROUND(가격))는 데이터가 100줄 들어가면 100줄이 예쁘게 변환되어 그대로 나온다. 하지만 집계 함수(SUM, MAX, AVG, MIN, COUNT)는 데이터가 1만 줄이 들어가도, 통째로 압축되어 딱 1줄의 정답만 나온다.

  • 필요성: 은행 데이터베이스에 고객들의 입출금 내역이 하루에 1,000만 건씩 쏟아진다. 은행 지점장님이 "그래서 오늘 강남지점 총 수신액(SUM)이 얼만데? 가장 돈 많이 예금한 사람 금액(MAX)은?"이라고 물어본다. 개발자가 1,000만 건을 자바(Java) 서버의 배열(Array)로 몽땅 다 퍼 올려서 for 문을 1,000만 번 돌리며 total = total + money 로 더하고 있으면, 네트워크 대역폭이 폭발하고 서버 램(RAM)이 펑 터져 죽는다. "이런 무식한 더하기와 평균 연산을 왜 앱(App) 서버가 하냐? 데이터가 묻혀있는 가장 깊은 곳, DB 엔진(Storage) 네가 직접 광속으로 더해서 나한텐 깔끔한 정답 1개만 던져줘!"라는 빅데이터 처리 오프로딩(Off-loading)의 절박함이 집계 함수를 탄생시켰다.

  • 💡 비유: 단일 행 함수는 과일 공장에서 사과 100개에 일일이 광택제를 발라 **'광나는 사과 100개'**를 그대로 내보내는(1:1 변환) 라인입니다. 반면 집계 함수는 거대한 **'믹서기(Blender)'**입니다. 사과 100개를 넣고 믹서기 버튼을 징~ 누르면, 사과 모양 100개는 싹 다 사라지고(압축), **'사과 주스 1통(통계값 1개)'**이라는 완전히 차원이 다른 결과물 1개만 덜렁 나오게 됩니다.

  • 등장 배경:

    1. OLAP(분석형 데이터베이스)의 성장: 단순 입출력을 넘어서 경영진의 의사결정 지원 시스템(DSS, EIS)을 위해 다차원적인 통계 쿼리 처리가 필수불가결해졌다.
    2. 관계 대수의 발전: E.F. Codd의 초기 관계 모델에는 집계의 개념이 부족했으나, 상용 RDBMS가 폭발하면서 수학적 요약 연산(Aggregation)이 SQL-86과 SQL-92 표준의 핵심 골조로 편입되었다.
┌─────────────────────────────────────────────────────────────┐
│          집계 함수의 믹서기(Compression) 압축 원리 및 문법 작동          │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ [ 원본 데이터 (사원 테이블 10만 건) ]                                │
│   홍길동   영업부   500                                          │
│   이순신   개발부   800     ◀─ 10만 건의 데이터가 쏟아져 들어옴         │
│   김철수   영업부   300                                          │
│                                                             │
│         ▼ [ 🌟 GROUP BY 믹서기 칸막이 발동 ] ▼                   │
│                                                             │
│ ┌───────────────────┐               ┌───────────────────┐     │
│ │ [ 영업부 (Sales) ]│               │ [ 개발부 (Dev) ]  │     │
│ │  500, 300, 200... │               │  800, 700, 600... │     │
│ └─────────┬─────────┘               └─────────┬─────────┘     │
│           │                                     │             │
│           ▼ [ 🧮 집계 함수 5형제의 난도질 압축 ] ▼                  │
│                                                               │
│ 1️⃣ SUM(급여): 다 더해! ➔ 영업부 총합 1000 💰                        │
│ 2️⃣ AVG(급여): 평균 내! ➔ 영업부 평균 333  📊                        │
│ 3️⃣ MAX(급여): 젤 큰거! ➔ 영업부 최고 500  🏆                        │
│ 4️⃣ MIN(급여): 젤 작은! ➔ 영업부 최저 200  📉                        │
│ 5️⃣ COUNT(*): 사람 수! ➔ 영업부 총 3명    👥                        │
│                                                             │
│ 🌟 결과: 10만 줄의 데이터가 완전히 으깨어져서, [영업부 통계 1줄],         │
│         [개발부 통계 1줄]이라는 우아한 대시보드 리포트(통계)로 환골탈태함! │
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] 집계 함수는 절대로 혼자서 춤추지 않는다. **GROUP BY**라는 마법의 칸막이와 영혼의 파트너(Duo)로 엮여 있다. 만약 GROUP BY 없이 SELECT SUM(급여) FROM 사원 이라고 치면, DB는 전체 10만 명을 통뼈 1개의 그룹으로 취급하여 전사 총급여 단 1개만 뱉어낸다. 만약 부서별로 쪼개고 싶다면 GROUP BY 부서로 믹서기 통을 10개(부서 수)로 쪼개고, 그 각각의 믹서기 통 안에서 SUM이나 MAX 모터가 위이잉 돌아가게 세팅하는 것이다. 10만 개의 잡다한 데이터가 10줄의 엑기스(Insight) 통계치로 빚어지는 OLAP(데이터 웨어하우스) 아키텍처의 심장 박동이다.

  • 📢 섹션 요약 비유: 수만 장의 투표용지(원본 데이터)가 쏟아집니다. 개표원이 투표용지 1만 장을 책상 위에 지역별로 쌓아 둡니다(GROUP BY). 그리고 그 쌓인 종이 더미 위에서 "찬성 몇 개, 반대 몇 개"라고 득표수만 딱 1줄로 세어서 칠판에 적습니다(COUNT, SUM). 투표용지 1만 장은 창고에 쑤셔 박고, 사람들은 칠판에 적힌 '결과 숫자 1개(집계)'만 보고 환호하는 것입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

1. 전설의 5대 집계 함수 (Big 5)

RDBMS의 아버지들이 박아둔 ANSI SQL 근본 5형제다.

함수명기능작동 방식 및 아키텍처 꿀팁
COUNT행(Row)의 개수를 센다.COUNT(*)는 NULL이 껴있든 말든 줄수(Row) 자체를 무조건 다 세어버린다. COUNT(컬럼명)을 쓰면 그 컬럼에 NULL이 든 줄은 빼고 정상 데이터만 카운트한다.
SUM숫자 컬럼의 총합을 구한다.숫자형(Number/Int) 데이터에만 먹힌다. 문자열(Varchar)에 썸을 치면 DB가 피를 토하며 에러를 낸다.
AVG숫자 컬럼의 평균을 구한다.🌟 실무 장애 0순위! 분모(Divide)를 계산할 때, NULL 값인 직원은 분모 숫자에서 아예 빼버린다. 따라서 평균이 기형적으로 뻥튀기될 수 있다. (아래 딜레마 참고)
MAX최댓값을 뽑아낸다.숫자뿐만 아니라 날짜(가장 최신일), 문자열(가나다순 맨 끝)에도 기가 막히게 잘 먹힌다. 최신 버전을 찾을 때 MAX(등록일)은 국룰이다.
MIN최솟값을 뽑아낸다.MAX와 동일. 가장 오래된 날짜, 알파벳 A에 가장 가까운 값을 광속으로 인덱스 앞단(First)에서 뽑아낸다.

2. WHERE 절의 패배, HAVING 절의 등장

SQL 문법에는 아주 잔인한 실행 순서(Execution Order) 규칙이 있다. 기계는 FROM ➔ WHERE ➔ GROUP BY ➔ HAVING ➔ SELECT 순서로 굴러간다.

  • 안티패턴의 늪: "부서 평균 월급이 300만 원 이상인 부서만 출력해!"라고 기획자가 요구했다. 주니어 개발자가 키보드를 두드린다. WHERE AVG(월급) >= 300 ➔ DB는 즉시 붉은 에러 창을 띄운다.

  • 아키텍트의 원리 해석: WHERE 절 검문소는 아직 믹서기(GROUP BY)가 돌기도 전인 통원육 사과(개별 Row 데이터) 상태일 때 지나가는 곳이다. 사과 알맹이 1개에게 "너네 반 평균 300 넘어?"라고 물어봤자 알 턱이 없다. 믹서기로 갈아서 주스(평균 통계)가 다 뽑혀 나온 뒤에야 비로소 "이 주스 평균 300 넘어?"라고 채점할 수 있다.

  • HAVING 절의 탄생: 그래서 집계 함수로 뭉개진 '통계 결괏값'을 필터링(자르기)하기 위해, GROUP BY 바로 뒷단에 전용 검문소인 HAVING 절이라는 문법이 창조되었다. (예: HAVING AVG(급여) >= 300).

  • 📢 섹션 요약 비유: WHERE 절은 믹서기에 과일을 넣기 전에 썩은 사과를 눈으로 쳐다보고 걸러내어 쓰레기통에 버리는 채망입니다(집계 함수 사용 불가). HAVING 절은 사과를 다 갈아서 주스(집계 함수 결과)로 만든 뒤에, 당도 측정기를 꽂아서 "당도 10 이하 주스통은 버려!"라고 뭉쳐진 주스통 단위로 걸러내는 필터입니다.

Ⅲ. 융합 비교 및 다각도 분석

딜레마: AVG() 와 NULL의 죽음의 함정

데이터 분석가(Analyst)가 엑셀로 뽑은 부서 평균과, 백엔드 개발자가 뽑은 AVG 쿼리 결과가 100만 원이나 차이가 났다. 왜일까? 집계 함수는 기본적으로 NULL(비어있는 깡통 데이터)을 유령 취급하여 무시해 버리기 때문이다.

직원명보너스 데이터
A 대리100만 원
B 사원50만 원
C 대리NULL (미입력)
D 인턴0원 (안 받음)
  • 멍청한 AVG(보너스)의 계산: A(100) + B(50) + D(0) = 150만 원. 그런데 C대리의 NULL은 데이터가 없는 거니까 분모에서 빼버린다! ➔ 150만 원 / 3명 = 평균 50만 원. (실제로는 4명이 받아야 하는데 3명으로 나눠서 평균이 뻥튀기됨).
  • 아키텍트의 치유책 (COALESCE 융합): 널을 0으로 바꿔서 분모에 강제로 포함시켜야 진짜 통계다. AVG( COALESCE(보너스, 0) ) ➔ C대리의 NULL이 0원으로 치환됨. ➔ 150만 원 / 4명 = 진짜 평균 37.5만 원.

과목 융합 관점 (데이터 무결성): 데이터베이스 스키마(DDL)를 설계할 때, 나중에 통계를 칠 만한 숫자 컬럼(금액, 점수, 조회수 등)에는 애초에 NULL이 들어오지 못하도록 **DEFAULT 0 NOT NULL 제약 조건(Constraint)**을 강력하게 떡칠해 두는 것이, 수백만 건의 BI(Business Intelligence) 통계 리포트 정합성이 붕괴하는 것을 사전에 막는 0순위 데이터 모델링 철학이다.

  • 📢 섹션 요약 비유: 시험을 봤는데 반 학생 30명 중 5명이 결석(NULL)해서 시험지를 안 냈습니다. AVG(점수)는 결석한 5명을 아예 이 세상에 없는 사람 취급해버리고, 시험 본 25명 점수만 더해서 25로 나눠버려 반 평균을 비정상적으로 높게(천재 반) 뻥튀기하는 무서운 착시 거울입니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

  1. 시나리오 — COUNT(*) vs COUNT(컬럼명) 성능과 정합성의 오해: 사용자 행동 로그 테이블 10억 건에서 오늘 들어온 전체 로그 개수를 세어야 한다. 주니어 개발자가 "별표(*)를 쓰면 전체 컬럼을 다 뒤지니까 쿼리가 엄청 느려지겠지? 컬럼 1개만 찍어주면 빠를 거야!"라며 굳이 SELECT COUNT(가입경로) FROM 로그 라고 짰다. 결과값이 10만 개나 비어서 출력되었다.

    • 판단: 완벽한 오해와 무지다. COUNT(컬럼명)은 옵티마이저가 그 컬럼을 일일이 쳐다보며 NULL이 박혀있는지(무시할지) 체크해야 하므로 연산 오버헤드가 더 튄다. 반면 COUNT(*)는 모든 컬럼을 읽는 것이 아니라, **"이 데이터 덩어리(Row)가 디스크에 물리적으로 1줄 존재하느냐"**만 카운트하기 때문에, 가장 덩치가 작은 인덱스(보통 PK) 하나만 쭉(Index Fast Full Scan) 훑어 내리며 0.1초 만에 전체 테이블 행(Row) 숫자를 정확하게 세어내는 가장 빠르고 완벽한 문법이다. 성능을 걱정해 *를 버릴 이유가 1%도 없다.

  2. 시나리오 — 중복 쳐내기 융합 (COUNT(DISTINCT)): 마케팅 팀이 "이번 달에 우리 쇼핑몰에 접속한 순수 방문자 수(DAU)를 뽑아주세요!"라고 했다. 로그 테이블에는 하루에 10번 들어온 홍길동의 기록 10줄이 쌓여있다. 그냥 COUNT(고객ID)를 때리면 방문 횟수가 10번으로 뻥튀기되어 찍힌다.

    • 판단: 집계 함수 괄호 안에 DISTINCT(중복 제거) 키워드를 쑤셔 넣는 아키텍처다. COUNT(DISTINCT 고객ID) ➔ 이렇게 짜면, DB는 메모리 안에서 홍길동 데이터 10개를 1개로 합쳐서(Hash 중복 제거) 콤팩트하게 만든 뒤에, 살아남은 찐 고객(순수 사람 수)만 카운트를 때려준다. 빅데이터 환경에서 COUNT DISTINCT는 각 노드의 메모리를 쥐어짜는 엄청난 셔플(Shuffle) 병목을 유발하므로, 성능 튜닝 시 이 부분의 Group By 해시 전략을 면밀히 감시해야 한다.
  ┌─────────────────────────────────────────────────────────────┐
  │        실무 아키텍처: GROUP BY와 집계 함수의 복합 엔진 실행 계획 (Plan)    │
  ├─────────────────────────────────────────────────────────────┤
  │                                                             │
  │ [ 쿼리 ]                                                      │
  │ SELECT 부서, 직급, SUM(월급) AS 총월급, COUNT(*) AS 인원수         │
  │ FROM 사원                                                    │
  │ GROUP BY 부서, 직급;  ◀─ (그룹 칸막이가 2차원 뎁스로 쪼개짐)             │
  │                                                             │
  │ [ 옵티마이저 내부 해시 그룹핑 (Hash Group By) 전략 ]                │
  │                                                             │
  │ 1. RAM(메모리)에 빈 엑셀 표(해시 테이블)를 넓게 펼친다.                 │
  │ 2. 사원 테이블을 위에서부터 미친 듯이 1줄씩 읽어 내린다. (Full Table Scan) │
  │    ➔ "영업부 대리, 월급 300만 원 들어왔습니다!"                       │
  │ 3. 메모리 해시표에 [영업부-대리] 칸이 없으면 새로 1줄 판다.                 │
  │    ➔ 총월급 칸에 +300 누적, 인원수 칸에 +1 카운트 올림.               │
  │ 4. "영업부 대리, 월급 400만 원 또 들어왔습니다!"                      │
  │ 5. 이미 있는 [영업부-대리] 칸에 쏙 집어넣음.                          │
  │    ➔ 총월급 칸: 기존 300 + 400 = 700 갱신, 인원수: 1+1 = 2 갱신!   │
  │                                                             │
  │ 🌟 아키텍트 판단: 10억 건의 테이블을 디스크에서 메모리로 쭉 훑어버리는      │
  │ 단 한 번의 스트리밍(Sequential I/O) 동안, 위쪽 해시 표 버퍼 안에서 숫자가│
  │ 폭풍처럼 덧셈 갱신되며 집계가 광속으로 끝나는 OLAP의 기적이다!              │
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] 집계 함수가 내부적으로 하드웨어 메모리를 어떻게 쓰는지를 보여준다. 과거(Oracle 9i 시절)에는 뭉치기 위해서 일단 1억 건 데이터를 메모리에 부어놓고 기역니은 순으로 무식하게 전체 정렬(Sort Group By)을 한 뒤에 위아래로 더했다. 시간이 미친 듯이 오래 걸렸다. 현대의 옵티마이저(10g 이후)는 해시 그룹 바이(Hash Group By) 아키텍처로 진화했다. 정렬을 포기한 대신, 해시 함수를 쏴서 메모리상의 똑같은 번지수(Bucket)에 숫자를 던져넣어 그 자리에서 실시간으로 덧셈기(SUM/COUNT) 모터를 돌려버린다. 이 혁명 덕분에 데이터 웨어하우스(DW)의 통계 속도가 천 배 이상 빨라졌다.

도입 체크리스트

  • 기술적: SELECT 절에 일반 컬럼(예: 사원이름)과 집계 함수(예: SUM(월급))를 같이 적어놓고 쿼리를 쏘지 않았는가? 집계 함수를 쓰면 화면은 무조건 '압축된 그룹' 단위로 찌그러진다. 압축되어 증발해 버린 개별 사원 이름을 SELECT 에 적으면 DB는 "1줄로 뭉갰는데 10명 이름을 어떻게 적어줘!"라며 Not a GROUP BY expression 이라는 0순위 에러를 시뻘겋게 뱉어낸다. 믹서기에 간 주스(집계)와 갈지 않은 생사과(일반 컬럼)는 한 그릇에 절대 담길 수 없음을 주니어에게 교육했는가?
  • 운영·보안적: 사내 데이터 포털에서 수억 건의 거래 로그 테이블에 사용자가 필터(WHERE 날짜)도 안 걸고 무지성으로 SELECT 부서, SUM(금액) FROM 로그 GROUP BY 부서 쿼리를 매일 아침 때리고 있지 않은가? 운영 서버(OLTP)의 버퍼 캐시가 다 날아가고 DB CPU가 타버린다. 이런 무거운 전체 집계 쿼리는 야간에 한 번만 배치(Batch)로 돌려서 '결과 요약 테이블(Summary Table / Materialized View)'로 작게 10줄짜리 표로 미리 구워둔 뒤, 아침엔 그 10줄짜리 껍데기만 읽어가도록 아키텍처 격리(CQRS)를 쳐두었는가?

안티패턴

  • 조인(Join) 이후 집계(SUM) 폭발의 카테시안 함정: 부서 테이블 1줄과 사원 테이블 10줄을 1:N 조인(Join)하면, 메모리 안의 데이터는 총 10줄로 뻥튀기(Fan-out)된다. 이때 아무 생각 없이 SUM(부서예산)을 쳐버리면, 부서 예산 1억 원이 10줄 데이터에 다 묻어있기 때문에 1억 * 10명 = 총 부서 예산 10억 원이라는 말도 안 되는 뻥튀기 왜곡 결과가 도출되어 재무 회계가 개박살 난다. 1:N 조인을 할 때는 무조건 서브쿼리 안쪽(N쪽 데이터)에서 먼저 1줄로 예쁘게 그룹핑(GROUP BY) 압축을 완료한 뒤에, 1:1 상태로 바깥쪽 테이블과 깔끔하게 조인을 붙여야 데이터 뻥튀기(Data Explosion) 사태를 막을 수 있다.

  • 📢 섹션 요약 비유: 사과(데이터)를 세어야 하는데, 거울방(1:N 조인)에 사과를 들고 들어가면 거울에 비친 사과가 100개로 보입니다. 그 거울방 안에서 무턱대고 개수(COUNT, SUM)를 세면 망합니다. 반드시 거울방에 들어가기 전에 문밖에서 바구니에 사과를 다 담아서 통계 숫자표(인라인 뷰 집계)를 딱 적어놓고, 그 종이표만 거울방에 들고 들어가야 계산이 틀리지 않습니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분WAS(Java 등) 메모리 로딩 후 For문 집계DB 단 집계 함수(SUM/COUNT) 오프로딩 튜닝개선 효과
정량1,000만 건 데이터 네트워크 덤프 전송DB 단 1회 스캔 후 10줄로 압축(Aggregation)애플리케이션-DB 간 네트워크 I/O 트래픽 99.9% 절감
정량싱글 스레드 반복문(Loop) 처리 지연최적화된 Hash Group By 인메모리 연산 수행수천만 건 대시보드 통계 리포팅 소요 시간 수십 분 ➔ 1초 내외 단축
정성개발자가 통계 알고리즘과 예외(NULL) 떡칠 코딩단 1줄의 선언적 SQL (SELECT SUM(...))백엔드 코드의 순수성 유지 및 수학적 무결성이 검증된 통계 도출

미래 전망

  • 스트리밍 마이크로 배치의 윈도우 집계 (Continuous Aggregation): 과거 집계 함수는 하루 치 테이블 데이터가 다 굳어질 때까지 기다렸다가 야간에 뭉텅이로 돌리는 지루한 배치(Batch)의 전유물이었다. 현대의 Apache Flink, Kafka Streams 등 빅데이터 플랫폼에서는, 쏟아지는 이벤트 스트림(계곡물) 중간에 5초짜리 슬라이딩 윈도우(망)를 쳐두고, 그 망 안에서 5초마다 끊임없이 SUM, AVG 집계 함수를 때려대며 살아 움직이는 라이브 대시보드를 0.1초 만에 갱신하는 차세대 스트리밍 SQL의 심장으로 진화했다.
  • Rollup, Cube, Grouping Sets의 다차원 우주 (OLAP 큐브): 단순한 GROUP BY를 넘어섰다. 기획자가 "부서별 총합도 주고, 연도별 총합도 주고, 회사 전체 총합도 한 화면에 엑셀 피벗 테이블처럼 다 가져와!"라고 악랄하게 요구한다. 옛날엔 쿼리 3개를 UNION ALL 로 억지로 붙였지만, 지금은 GROUP BY ROLLUP(연도, 부서) 단 한 단어만 치면, DB 엔진이 알아서 중간 소계(Sub-total)와 전체 합계(Grand-total) 피벗 행을 마법처럼 촹촹촹 찍어내려 보내는 미친 다차원 큐브 집계의 시대가 열렸다.

참고 표준

  • ANSI/ISO SQL-92: 관계형 데이터베이스에서 SUM, MIN, MAX, AVG, COUNT 5대 집계 함수와 GROUP BY, HAVING의 문법적 순서와 작동 원리를 확립한 글로벌 표준 헌법.
  • SQL:1999 (OLAP 확장): ROLLUP, CUBE 등 데이터 웨어하우스(DW)에 최적화된 다차원 소계/합계 집계 확장 기능(Extensions)이 정의된 규격.

"거대한 혼돈 속에서, 본질(Insight)을 짜내어 단 한 방울의 진리로 떨궈낸다." 집계 함수는 1억 건의 차가운 파편적 로그 데이터가 경영진의 가슴을 울리는 따뜻한 비즈니스 팩트(매출 폭등, 불량률 하락)로 태어나기 위해 거쳐야 하는 우아한 용광로다. 단순히 더하고 세는 초등학생 수학이 아니다. NULL이라는 데이터의 유령을 어떻게 피할지, 거울방(조인) 안에서 어떻게 숫자의 뻥튀기를 막을지, 해시(Hash) 메모리를 어떻게 통제할지 고민하는 순간, 개발자는 SELECT *만 치며 데이터를 구경하던 하수(Viewer)의 티를 벗고, 비로소 데이터의 뼈와 살을 분리해 원하는 형태의 조각상으로 빚어내는 통계 아키텍트(Sculptor)로 군림하게 된다.

  • 📢 섹션 요약 비유: 집계 함수는 포도 1만 송이(수만 건의 데이터)를 넣고 발로 짓이겨 즙을 짜내는 '거대한 와인 압착기'입니다. 포도 알맹이의 원래 모양은 영원히 사라져 버리지만, 대신 그 모든 포도의 달콤함이 완벽하게 뭉쳐진 '최고급 와인 1병(통계 결과값)'이라는 전혀 다른 차원의 비싼 보물로 환골탈태하는 위대한 희생이자 압축 마법입니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭관계 및 시너지 설명
GROUP BY (그룹화)집계 함수를 아무리 써도 전체 총합 1개만 나오는데, 이 문법을 앞에 깔아주면 부서별, 남녀별로 믹서기를 여러 개 쪼개서 소그룹별 통계를 예쁘게 찍어내는 무적의 단짝이다.
HAVING 절 (그룹 필터링)WHERE 절은 믹서기 돌기 전의 사과(원본)만 쳐낼 수 있다. 다 갈아버린 사과 주스(집계 결과)의 당도가 낮은 걸 버리려면 오직 이 전용 검문소만 통과해야 한다.
윈도우 함수 (OVER 파티션)집계 함수처럼 데이터를 더하긴 하는데, 원본 사과(데이터)를 부수지 않고 사과 옆구리에 "너희 팀 총 몸무게 500kg"이라는 스티커만 살포시 붙여주는 마법의 비파괴 함수다.
인라인 뷰 (Inline View 서브쿼리)1:N 조인을 걸다가 SUM 액수가 수십 배로 뻥튀기(Cartesian)되는 재앙을 막기 위해, 조인 전에 FROM 절 괄호 안에서 집계를 1줄로 먼저 쳐서 예쁘게 압축해 두는 방파제다.
ROLLUP / CUBE (다차원 집계)단순한 부서별 합계를 넘어 "부서별 합계 + 연도별 합계 + 전사 총합계"까지 엑셀 피벗 테이블(소계/총계)처럼 1방의 쿼리로 다 쏴주는 끝판왕 확장 마법이다.

👶 어린이를 위한 3줄 비유 설명

  1. 단일 함수는 딸기 100개에 설탕을 발라 딸기 100개 그대로 내보내는(1:1) 마법이에요.
  2. 하지만 집계 함수는 거대한 믹서기라서, 딸기 100개를 넣고 윙 돌리면 딸기 모양은 다 사라지고(압축) 달콤한 **'딸기 주스 1통(결과값 딱 1개)'**만 덜렁 나오게 됩니다.
  3. 데이터베이스한테 "1억 명의 예금통장을 일일이 다 읽어서 화면에 띄우지 말고, 믹서기에 윙 갈아서 우리나라 총 예금액 통계 1줄만 보여줘!"라고 시킬 때 쓰는 엄청나게 빠르고 똑똑한 믹서기랍니다!