Day 5 - Week 1 종합 복습

한 장으로 보는 Week 1

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

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

[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 의 개념은 따로 외우면 흩어지고, 질문 순서로 묶으면 판별 절차가 된다. 시나리오 지문을 만나면 아래 순서로 밑줄을 긋는다.

① 원천이 무엇인가?         DB / 파일 / 이벤트·로그 / SaaS
        ↓                  → 수집 서비스가 정해진다 (Day 3)
② 얼마나 신선해야 하나?    초 이내 / 분 / 시간 / 하루
        ↓                  → 배치·스트리밍·준실시간이 정해진다 (Day 2)
③ 누가 어떻게 읽나?        한 행 조회 / 대량 집계 / 검색 / 대시보드
        ↓                  → 저장소와 포맷이 정해진다 (Day 1, Day 4)
④ 붙은 조건은?             운영 부담 최소 / 비용 최소 / 코드 변경 최소 / 세밀한 권한
                           → 같은 단계의 후보 중 하나로 좁혀진다

• ④가 가장 자주 정답을 가른다. ①~③까지는 보기 두세 개가 살아남고, 마지막 한정어 하나가 승부를 낸다.

오답 보기가 만들어지는 다섯 가지 틀

출제자는 "틀린 기술"이 아니라 "이 상황에는 틀린 선택"을 보기로 만든다. 틀을 알면 소거가 빨라진다.

• 특히 다섯 번째 틀: 서버리스 서비스에는 크기를 키우는 손잡이가 없다. Athena 는 인스턴스가 없으므로 성능 개선은 데이터 쪽(포맷·압축·파티션·파일 크기)에서 한다.

시나리오 연습: 단서에서 정답까지

아래는 연습 문제와 겹치지 않는 새 상황이다. 단서 열을 가리고 정답을 말해 본 뒤 확인한다.

Week 1 숫자·기본값 한 장

숫자는 외울 양이 적을수록 좋다. Week 1 범위에서 지문 판별에 실제로 쓰이는 것만 추렸다.

• 한도·요금 수치는 바뀐다. 시험은 정확한 숫자보다 "기본값이 있고 조정 가능하다", "먼저 도달한 조건에서 동작한다" 같은 동작 방식을 묻는다.

한 파이프라인에서 생기는 장애와 그 원인

개념을 "무엇이 잘못되면 어떤 증상이 나오는가"로 뒤집어 보면 Week 1 전체가 다시 연결된다.

위 표의 조치는 대부분 "데이터를 어떻게 놓느냐"의 문제다. 클러스터를 키우는 것은 마지막 수단이고, 포맷·파티션·파일 크기·분리(운영과 분석, 원본과 가공본)를 먼저 바로잡는 것이 데이터 엔지니어의 일이다. DEA-C01 이 서비스 이름보다 설계 판단을 묻는 이유도 여기에 있다.

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

📖 용어

• 워크로드 : 시스템이 처리해야 하는 일의 성격. 데이터를 어떤 식으로 읽고 쓰는가를 말한다.
• OLTP / OLAP : 소수 행을 빠르게 읽고 쓰는 거래 처리와, 대량 행을 모아 집계하는 분석 처리.
• 레이크하우스 : S3 데이터 레이크 위에 테이블 형식과 카탈로그를 얹어 웨어하우스처럼 쿼리하는 구조.
• schema-on-read / schema-on-write : 읽을 때 구조를 적용하는 방식과, 저장할 때 구조를 강제하는 방식.
• 한정어 : 지문의 "최소 운영 부담", "가장 비용 효율적" 같은 조건 문구. 후보 중 정답 하나를 가른다.
• 소거법 : 조건을 어기는 보기를 하나씩 지워 정답을 남기는 풀이법.
• 파티션 프루닝 : WHERE 조건에 맞는 파티션 폴더만 읽고 나머지는 건너뛰는 것.
• 작은 파일 문제 : 아주 작은 파일이 너무 많아 목록 조회·열기 비용이 커지고 쿼리가 느려지는 현상.