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에 등록됨
WHERE order_date = DATE '2026-06-25'   -- 파티션 프루닝
GROUP BY region;

하나의 회사가 세 요구를 동시에 가질 수 있고, 각각 다른 패러다임·서비스·포맷을 쓴다. "정답 하나"가 아니라 요구마다 맞는 조합이 있다는 것이 핵심이다.

💡 관련 이론: 요구 1~3을 한 그림에 합치면 자연스럽게 레이크하우스가 된다. 모든 원시 데이터(주문 CDC, 결제 스트림, 로그)가 S3 데이터레이크에 모이고, 배치·스트리밍 처리를 거쳐 Parquet으로 정제되며, 그 위에서 Athena·Redshift·QuickSight가 분석한다. Day1의 "레이크 vs 웨어하우스"가 현대에선 "레이크하우스로 통합"되는 이유다.

자주 헷갈리는 구분 정리

시험에서 함정으로 나오는 짝들이다.

이 8개 짝의 구분 기준만 정확히 잡아도 Week 1 범위의 시나리오 문제 상당수를 풀 수 있다.

💡 관련 이론: 이 표의 거의 모든 짝은 "유연성·범용성 vs 효율성·전문성"이라는 같은 긴장 구조를 갖는다. 레이크는 유연하지만 관리가 필요하고, 웨어하우스는 효율적이지만 경직됐다. 서버리스(Glue/Athena)는 편하지만 세밀한 제어가 약하고, 클러스터(EMR/Redshift)는 강력하지만 운영 부담이 있다. 트레이드오프를 의식하면 암기가 이해로 바뀐다.

시험 관점 한 줄 정리

DEA-C01은 결국 이 4개 도메인을 묻는다(Day1 재확인).

1. 수집·변환 (34%)   ← Day2 배치/스트림 + Day3 Kinesis/Glue/EMR
2. 저장·관리 (26%)   ← Day1 레이크/웨어하우스 + Day3 S3/Redshift + Day4 포맷
3. 운영·지원 (22%)   ← (Week2 이후) 오케스트레이션·모니터링
4. 보안·거버넌스(18%)← Day3 LakeFormation/IAM/KMS

Week 1은 1·2번 도메인의 토대를 거의 다 깔았다. 다음 주부터 각 서비스의 깊은 디테일(파티셔닝 전략, Glue 잡 튜닝, Kinesis 샤드 등)로 들어가지만, 그 모든 것이 오늘 그린 이 큰 그림 위에 얹힌다는 점을 기억하자.

정리하며

Week 1의 결론은 단순하다. 데이터 엔지니어는 파이프라인을 만드는 사람이고, 그 파이프라인은 수집 → 저장 → 처리 → 분석으로 흐르며 거버넌스가 감싼다. 모든 설계 판단(OLTP/OLAP, 배치/스트림, 레이크/웨어하우스, 행형/컬럼형)은 결국 **"워크로드가 무엇을 요구하는가"**로 귀결된다.

이 사고법을 손에 쥐었다면 Week 1은 성공이다. Week 2부터는 이 골격에 살을 붙여, 각 서비스를 실제로 다루는 법으로 들어간다.