하루가 실제로 어떻게 생겼나
데이터 엔지니어링 마케팅 자료는 Spark cluster 와 Iceberg lakehouse 통해 unicorn 타고 실시간 추천 시스템 가는 길. 실제 하루는:
- 대시보드 숫자 이상해 보인다는 Slack 메시지 triage (밝혀진 원인: upstream 이 지난 화요일 enum 값 바꿈).
- 누군가의 dbt PR review. Join key 에 빠진
not_nulltest 잡기. - 새 ingestion 위한 작은 Pandera schema 작성. 일주일치 historical 데이터에 돌리기; 0.3% row 가 fail; producer 에 loop in.
- 데이터 사이언티스트와 30분 미팅, 그들이 필요한 feature 에 대해 schema 가 지원 가능하지만 freshness SLA 안 된다고 설명.
- Transient API 실패 더 잘 처리하게 Airflow DAG 조정.
- 지난주 사고가 기존 거에서 step 누락한 거 보여서 runbook 업데이트.
이건 멋진 일, 그리고 대부분 화려하지 않아. 지루한 부분이 곧 일이고; 화려한 부분은 사이드 디시야.
시니어와 미드를 가르는 것
같은 본능, 다른 타이밍.
- Mid: "이 transformation 느림, 더 큰 warehouse 로 옮기자"
- Senior: "이 transformation 느린 이유는 model 이 Type 2 dimension 셋 join 하니까; surrogate key 쓰게 model 변경, 자연-key-with-validity 아니라"
- Mid: "schema 변경돼서 우리 깨짐, consumer 패치하자"
- Senior: "schema 변경돼서 우리 깨짐; contract + CI 체크 작성해서 다시 일어날 수 없게"
- Mid: "on-call 시프트 나빴어, 알림 fix 하자"
- Senior: "on-call 시프트 나빴어, 검증 게이트 단단히 해서 on-call 주의 필요한 사고 비율 줄이자"
안 변하는 것
Schema. Lineage. Idempotency. Contract. Validation. Observability. 이 quest 의 어휘가 2026 시니어 데이터 엔지니어의 작동 어휘 — 그리고 아마 2030 의. 도구는 회전 (오늘 hot orchestrator 가 내일 legacy 마이그레이션); 원리는 살아남아.
본인 인생의 다음 47 시간
끝났어. 노트북 들고, inbox 에서 가장 지저분한 CSV 골라, Pandera 검증 + Polars transform + 위에 dbt model + freshness 체크 있는 partitioned Parquet warehouse 로 바꿔. 허락 안 필요해. 오후 한 번 필요해. 가.