데이터 엔지니어가 실제로 필요로 하는 수학
It looks like only the source citation was provided. Could you please share the article text you’d like translated into Korean? Once I have the content, I’ll translate it while keeping the source line and all formatting intact.
Source: …
Introduction
방 안에 있는 코끼리 이야기를 해봅시다.
“데이터 엔지니어가 되려면 수학을 잘 해야 할까요?”
학생들과 커리어 전환을 시도하는 사람들에게 이 질문을 수백 번 들어봤습니다. 답은 여러분을 놀라게 할 수도 있습니다:
생각보다 적은 수학이 필요하지만, 전혀 필요하지는 않습니다.
데이터 엔지니어링은 데이터 사이언스와 다릅니다. 여러분은 경사 하강법 공식을 유도하거나 통계 정리를 증명하지 않을 것입니다. 하지만 매일 수학적 개념을 마주하게 되며, 종종 그것을 인식하지 못합니다.
이 글에서는 여러분이 알아야 할 정확한 내용—학문적인 부담 없이 엔지니어를 더 나은 사람으로 만들어 줄 실용적인 수학—을 다루겠습니다.
직설적으로 말하자면, 중요한 것은 다음과 같습니다:
| Concept | How Often You’ll Use It |
|---|---|
| 집합론 (Set Theory) | 매일 |
| 불 논리 (Boolean Logic) | 매일 |
| 기본 통계 (Basic Statistics) | 주간 |
| 집계 및 산술 (Aggregations & Arithmetic) | 매일 |
| 확률 기초 (Probability Basics) | 가끔 |
| 선형대수 (Linear Algebra) | 드물게 |
| 미적분 (Calculus) | 거의 없음 |
학교에서 고급 수학을 어려워했다면, 그것이 여러분을 막지 못하게 하세요. 대부분의 데이터 엔지니어링 수학은 적용 사례를 보면 직관적으로 이해할 수 있습니다.
집합 이론
작성하는 모든 SQL 쿼리는 집합 이론이 실전에서 적용된 것입니다. 집합을 이해하면 SQL을 이해하는 것입니다. 그것이 기본입니다.
집합은 서로 다른 원소들의 모음입니다.
Set A = {1, 2, 3, 4, 5}
Set B = {4, 5, 6, 7, 8}
이는 SQL과 직접적으로 연결됩니다:
| 집합 연산 | SQL 등가 구문 | 결과 |
|---|---|---|
| 합집합 (Union) | UNION | A 또는 B에 있는 모든 원소 |
| 교집합 (Intersection) | INNER JOIN | A와 B 둘 다에 있는 원소 |
| 차집합 (Difference) | EXCEPT / LEFT JOIN | A에는 있지만 B에는 없는 원소 |
| 데카르트 곱 (Cartesian Product) | CROSS JOIN | A와 B의 모든 조합 |
예시 쿼리
-- Union: Combine two sets
SELECT customer_id FROM online_orders
UNION
SELECT customer_id FROM store_orders;
-- Intersection: Find common elements
SELECT a.customer_id
FROM online_orders a
INNER JOIN store_orders b ON a.customer_id = b.customer_id;
-- Difference: Find elements only in first set
SELECT customer_id FROM online_orders
EXCEPT
SELECT customer_id FROM store_orders;
조인을 베른 다이어그램으로 시각화하면 이해가 크게 도움이 됩니다:
- INNER JOIN – 겹치는 부분만
- LEFT JOIN – 왼쪽 전체 + 겹치는 부분
- RIGHT JOIN – 오른쪽 전체 + 겹치는 부분
- FULL OUTER JOIN – 전체 모두
집합 이론이 떠오르면 SQL이 직관적으로 느껴집니다.
불리언 논리
Every WHERE clause, IF statement, and CASE expression is Boolean logic.
| 연산자 | 의미 | 예시 |
|---|---|---|
AND | 두 조건 모두 참이어야 함 | status = 'active' AND age > 18 |
OR | 하나 이상이 참이어야 함 | country = 'US' OR country = 'CA' |
NOT | 조건을 반전시킴 | NOT status = 'deleted' |
진리표 요약
| 식 | 결과 |
|---|---|
TRUE AND NULL | NULL |
FALSE AND NULL | FALSE |
TRUE OR NULL | TRUE |
FALSE OR NULL | NULL |
NOT NULL | NULL |
NULL = NULL | NULL (not TRUE) |
Tip:
WHERE column = NULL은 절대 작동하지 않습니다. 대신WHERE column IS NULL을 사용하세요.
De Morgan’s Laws
NOT (A AND B) = (NOT A) OR (NOT B)NOT (A OR B) = (NOT A) AND (NOT B)
실용 예시
-- Both statements are equivalent
WHERE NOT (status = 'active' AND region = 'EU')
WHERE status != 'active' OR region != 'EU'
De Morgan 법칙을 이해하면 예상대로 동작하지 않는 필터를 디버깅하는 데 도움이 됩니다.
기술 통계
통계학 학위가 없어도 되지만, 몇 가지 기술적 측정값은 이해해야 합니다.
| 측정값 | 의미 | SQL |
|---|---|---|
| Mean | 평균값 | AVG(column) |
| Median | 중앙값 | DB마다 다름 (예: PERCENTILE_CONT(0.5)) |
| Mode | 가장 빈번한 값 | GROUP BY … ORDER BY COUNT(*) DESC LIMIT 1 |
| Range | 최댓값 – 최솟값 | MAX(col) - MIN(col) |
| Variance | 데이터의 분산 | VAR(column) |
| Standard Deviation | 원래 단위의 퍼짐 | STDDEV(column) |
언제 사용하나요
- Mean – 일반적인 평균이지만, 이상치에 민감합니다.
- Median – 왜곡된 분포(예: 급여, 가격)에서 더 적합합니다.
- Mode – 범주형 데이터에 가장 적합합니다.
예시
급여가 {50k, 55k, 60k, 65k, 500k} 라고 하면:
| 통계량 | 값 | 해석 |
|---|---|---|
| Mean | 146k | 이상치 때문에 오해를 불러일으킴 |
| Median | 60k | 일반적인 급여를 더 잘 대표함 |
백분위수 (PostgreSQL 예시)
SELECT
PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY response_time) AS median,
PERCENTILE_CONT(0.99) WITHIN GROUP (ORDER BY response_time) AS p99
FROM api_logs;
P25, P50(중앙값), P75, P99와 같은 백분위수는 성능 지표에서 흔히 사용됩니다.
집계
집계는 계속해서 작성하게 됩니다. 반드시 숙지하세요.
| 함수 | 목적 |
|---|---|
COUNT | 행 수 |
SUM | 값의 총합 |
AVG | 평균값 |
MIN | 최소값 |
MAX | 최대값 |
COUNT(DISTINCT) | 고유값 수 |
Group By
GROUP BY는 데이터를 집합으로 나눈 뒤, 각 집합에 집계를 적용합니다.
SELECT
region,
COUNT(*) AS order_count,
SUM(amount) AS total_revenue,
AVG(amount) AS avg_order_value
FROM orders
GROUP BY region;
이것을 생각하는 방식: “각 지역마다 이 메트릭을 계산한다.”
Window Functions
윈도우 함수는 개별 행을 유지하면서 집계를 수행할 수 있게 해줍니다.
SELECT
order_id,
customer_id,
amount,
SUM(amount) OVER (PARTITION BY customer_id) AS customer_total,
AVG(amount) OVER (PARTITION BY customer_id) AS customer_avg
FROM orders;
PARTITION BY는 다시 집합 이론과 같습니다 — 하위 집합을 정의하고 있는 것이죠.
확률 기본
깊은 확률 이론이 필요하지는 않지만, 몇 가지 기본 개념만 알면 도움이 됩니다.
| 개념 | 정의 |
|---|---|
| 확률 | 사건이 일어날 가능성, 0에서 1 사이 |
| 독립 사건 | 한 사건이 다른 사건에 영향을 주지 않음 |
| 조건부 확률 | 다른 사건이 발생했을 때의 확률 |
일반적인 데이터 엔지니어링 활용:
- 데이터 품질 검사: “레코드 중 결측값이 있는 비율은 얼마인가요?”
- 샘플링: “이 샘플이 대표성을 갖추고 있나요?”
- A/B 테스트: “이 결과가 통계적으로 유의한가요?”
예시: 컬럼의 NULL 값 확률
SELECT
COUNT(*) AS total_rows,
SUM(CASE WHEN email IS NULL THEN 1 ELSE 0 END) AS null_count,
ROUND(
SUM(CASE WHEN email IS NULL THEN 1 ELSE 0 END)::decimal
/ COUNT(*), 4
) AS null_probability
FROM customers;
Numeric Types & Pitfalls
숫자가 어떻게 저장되는지 이해하면 비용이 많이 드는 실수를 방지할 수 있습니다.
| Type | Use Case | Watch Out For |
|---|---|---|
INTEGER | 카운트, ID | 한계에서 오버플로우 |
FLOAT | 과학 데이터 | 정밀도 오류 |
능숙한 데이터 엔지니어가 되기 위해 필요한 실용적인 수학입니다. 이 개념들을 마스터하면 SQL과 데이터 파이프라인이 훨씬 덜 위협적으로 느껴질 것입니다.
DECIMAL
돈, 정확한 값
느리며, 저장 공간 더 많이 필요
-- This might not equal 0.3
SELECT 0.1 + 0.2;
-- Result: 0.30000000000000004
재무 데이터의 경우 항상 DECIMAL을 사용하세요.
-- Integer division truncates
SELECT 5 / 2; -- Returns 2, not 2.5
-- Cast to get decimals
SELECT 5::decimal / 2; -- Returns 2.5
제가 자주 사용하는 패턴
-- 1️⃣ Category percentages
SELECT
category,
COUNT(*) AS count,
ROUND(100.0 * COUNT(*) / SUM(COUNT(*)) OVER (), 2) AS percentage
FROM products
GROUP BY category;
-- 2️⃣ Year‑over‑year growth
SELECT
year,
revenue,
LAG(revenue) OVER (ORDER BY year) AS prev_year,
ROUND(
100.0 * (revenue - LAG(revenue) OVER (ORDER BY year))
/ LAG(revenue) OVER (ORDER BY year), 2
) AS yoy_growth
FROM annual_revenue;
-- 3️⃣ Running total
SELECT
date,
amount,
SUM(amount) OVER (ORDER BY date) AS running_total
FROM transactions;
-- 4️⃣ 7‑day moving average
SELECT
date,
value,
AVG(value) OVER (
ORDER BY date
ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
) AS seven_day_avg
FROM daily_metrics;
데이터 엔지니어라면 우선순위를 낮출 수 있는 분야
| 주제 | 건너뛸 수 있는 이유 |
|---|---|
| 미적분 | 데이터 과학자에게 맡기세요 |
| 선형대수 | 머신러닝 엔지니어링에만 필요합니다 |
| 고급 통계 | 기술 통계를 넘어서는 것으로 필수는 아닙니다 |
| 증명 및 정리 | 여러분은 구축하고 있는 것이지 증명하는 것이 아닙니다 |
나중에 머신러닝 엔지니어링으로 전향한다면 다시 살펴보세요. 핵심 데이터 엔지니어링에는 필요하지 않습니다.
데이터 엔지니어링을 위한 수학 학습 최고의 방법 – SQL을 통해
- 공개 데이터셋을 가져오기 – Kaggle에 많이 있습니다.
- 질문하기 – “지역별 주문 금액의 중앙값은?”
- 쿼리 작성 – 위 개념을 적용하세요.
- 결과 검증 – 논리적으로 타당한가요?
수학이 실제 문제와 연결될 때 직관적으로 이해됩니다.
마스터해야 할 핵심 개념
- 집합론 – 이를 이해하면 SQL이 이해됩니다.
- 불리언 논리 – 모든 필터가 이것에 의존합니다.
- 기술 통계 – 평균, 중앙값, 백분위수.
- 집계 – 일상적인 도구입니다.
- 정밀도 – 데이터 타입을 알아두세요.
수학을 사랑할 필요는 없습니다. 기본을 제대로 잡을 정도로 수학을 존중하면 됩니다. 이론만으로는 한계가 있습니다.
다음은?
- 첫 번째 데이터 파이프라인 구축 — 개념에서 실행 코드까지
- 데이터 엔지니어링 파헤치기: 무엇이며 왜 중요한가
- 파이프라인, ETL, 그리고 웨어하우스: 데이터 엔지니어링의 DNA
- 현장 도구: 현대 데이터 엔지니어링을 구동하는 것
- 데이터 엔지니어가 실제로 필요한 수학 (여기)
- 첫 번째 파이프라인 구축: 개념에서 실행까지
- 경로 설계: 여정을 가속화하는 강좌와 리소스
이 내용이 도움이 되었나요? 이 개념을 적용하는 데 질문이 있나요? 댓글에 남겨 주세요.