Day 5 - Week 1 종합 복습

지난 4일간 데이터 엔지니어링의 토대를 세웠다. Day 1에서 역할과 파이프라인, OLTP/OLAP, 레이크/웨어하우스를 봤고, Day 2에서 배치와 스트리밍을 갈랐으며, Day 3에서 AWS 데이터 서비스 지도를 펼쳤고, Day 4에서 데이터 포맷과 스키마 진화를 다뤘다. 흩어진 조각처럼 보이지만, 사실 이들은 하나의 파이프라인으로 꿰어진다.

오늘은 개별 개념을 다시 나열하는 대신, 하나의 시나리오를 처음부터 끝까지 따라가며 네 날의 지식이 어떻게 맞물리는지 본다. 시험은 단편 암기가 아니라 "이 상황에서 무엇을 고를 것인가"를 묻기 때문에, 이렇게 연결해서 보는 것이 가장 효과적인 복습이다.

한 장으로 보는 Week 1

[Day1] 역할·개념          [Day2] 처리        [Day3] 서비스       [Day4] 포맷
 데이터 엔지니어           배치               수집 Kinesis/DMS    CSV/JSON (원시)
 = 파이프라인 책임         vs                 저장 S3/Redshift    Parquet/ORC (분석)
 OLTP vs OLAP             스트리밍            처리 Glue/EMR       Avro (스트리밍)
 레이크 vs 웨어하우스      (지연/처리량)       분석 Athena/QS      스키마 진화
                                              거버넌스 LakeFmt

네 날의 키워드가 결국 "데이터를 어떻게 수집·저장·처리·분석하고 통제하는가"라는 한 질문의 다른 측면들이다.

💡 관련 이론: 이 모든 판단을 관통하는 단일 원칙은 **"워크로드가 설계를 결정한다"**이다. OLTP냐 OLAP냐, 배치냐 스트림이냐, 행형이냐 컬럼형이냐 — 모두 "어떤 식으로 데이터를 읽고 쓰는가"라는 워크로드 특성에서 답이 나온다. 기술을 먼저 고르고 워크로드를 끼워맞추는 게 아니라, 워크로드를 분석해 기술을 고르는 것이 데이터 엔지니어링의 사고법이다.

시나리오로 꿰어보기

전자상거래 회사의 요구를 따라가 보자. 각 요구가 Week 1의 어느 개념에 닿는지 표시했다.

요구 1. "운영 주문 DB에 부하 주지 말고, 그 데이터를 분석할 수 있게 해줘."

• 운영 DB는 OLTP(Day1) → 무거운 집계를 직접 돌리면 안 됨
• DMS의 CDC(Day3)로 변경분만 분석 환경으로 복제
• 분석 환경은 OLAP(Day1) → Redshift 또는 S3+Athena

요구 2. "결제 순간 이상거래를 잡아내고 싶어."

• 즉시성이 필요 → 스트리밍(Day2)
• Kinesis Data Streams(Day3)로 결제 이벤트 수집
• 스키마가 바뀔 수 있으니 Avro + Schema Registry(Day4)

요구 3. "매일 아침 어제 매출 리포트를 자동으로."

• 주기적·경계 있는 데이터 → 배치(Day2)
• Glue(Day3)로 하루치 처리, Parquet(Day4)으로 적재
• Athena/QuickSight(Day3)로 조회·시각화

-- 요구 3의 분석 쿼리 — Parquet으로 저장돼 있어 빠르고 저렴
SELECT region, SUM(amount) AS revenue
FROM orders          -- S3의 Parquet, Glue Catalog에 등록됨