> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sifi.life/llms.txt
> Use this file to discover all available pages before exploring further.

# 데이터 엔지니어링이란?

> 이 문서는 **[데이터 기초](/training/01-data-fundamentals/overview)** 섹션의 일부입니다.

## 왜 데이터 엔지니어링이 필요한가요?

여러분이 대형 쇼핑몰을 운영한다고 상상해 보겠습니다. 매일 수만 건의 주문이 들어오고, 고객의 클릭 로그가 쌓이며, 재고 시스템에서는 실시간으로 수량이 변하고 있습니다. 이 모든 데이터를 그냥 방치하면 어떻게 될까요? 아마 "이번 달 가장 잘 팔린 상품이 뭐지?", "어떤 고객이 이탈 위험이 높지?" 같은 간단한 질문조차 답하기 어려울 것입니다.

**데이터 엔지니어링(Data Engineering)** 은 바로 이 문제를 해결합니다. 여기저기 흩어져 있는 원시 데이터(Raw Data)를 수집하고, 깨끗하게 정리하고, 분석가나 데이터 과학자가 바로 사용할 수 있는 형태로 만들어 주는 일련의 과정입니다.

> 💡 **쉽게 비유하면**: 데이터 엔지니어링은 "데이터의 상수도 시스템"과 같습니다. 산에서 내려오는 원수(Raw Data)를 정수 처리(변환)하고, 깨끗한 물(정제된 데이터)을 각 가정(분석가, 대시보드, ML 모델)에 안정적으로 공급하는 파이프라인을 만드는 것입니다.

***

## 데이터 엔지니어링의 핵심 역할

데이터 엔지니어링은 크게 세 가지 핵심 역할을 수행합니다.

### 1. 데이터 수집 (Ingestion)

다양한 소스에서 데이터를 가져오는 단계입니다.

| 소스 유형       | 예시                                 |
| ----------- | ---------------------------------- |
| 데이터베이스      | MySQL, PostgreSQL, Oracle 등의 운영 DB |
| 파일          | CSV, JSON, Parquet, Excel 파일       |
| 스트리밍        | Kafka, Kinesis 같은 실시간 메시지 큐        |
| SaaS 애플리케이션 | Salesforce, SAP, Workday 등         |
| API         | REST API, GraphQL 등을 통한 외부 데이터     |

### 2. 데이터 변환 (Transformation)

수집한 원시 데이터를 분석에 적합한 형태로 가공하는 단계입니다.

* **정제(Cleansing)**: 중복 제거, 결측값 처리, 오류 데이터 수정
* **표준화(Standardization)**: 날짜 형식 통일, 통화 변환, 코드값 매핑
* **통합(Integration)**: 여러 소스의 데이터를 하나로 합치기 (예: 주문 데이터 + 고객 데이터)
* **집계(Aggregation)**: 일별 매출 합산, 월별 사용자 수 계산 등

### 3. 데이터 적재 및 서빙 (Loading & Serving)

변환된 데이터를 최종 목적지에 저장하고, 소비자에게 제공하는 단계입니다.

* **데이터 웨어하우스** 에 적재하여 BI 대시보드에서 조회
* **데이터 레이크** 에 저장하여 데이터 과학자가 ML 모델 학습에 활용
* **실시간 서빙 레이어** 를 통해 애플리케이션에서 즉시 사용

***

## 데이터 팀의 구성과 역할

데이터 조직에는 다양한 역할이 존재합니다. 데이터 엔지니어가 어디에 위치하는지 이해하면, 전체 데이터 흐름이 더 명확해집니다.

| 단계               | 역할             |
| ---------------- | -------------- |
| 데이터 소스           | 원본 데이터 발생      |
| 데이터 엔지니어 → 수집    | 소스에서 데이터 추출    |
| 데이터 엔지니어 → 정제/변환 | 데이터 클렌징 및 변환   |
| 데이터 웨어하우스 / 레이크  | 정제된 데이터 저장     |
| 데이터 분석가 → 분석     | 데이터 기반 인사이트 도출 |
| 데이터 과학자 → ML 모델  | 머신러닝 모델 학습     |
| 경영진 → 비즈니스 의사결정  | 데이터 기반 의사결정    |

| 역할               | 하는 일                  | 주로 사용하는 도구                     |
| ---------------- | --------------------- | ------------------------------ |
| **데이터 엔지니어(DE)** | 데이터 파이프라인 설계·구축·운영    | Spark, SQL, Python, Databricks |
| **데이터 분석가(DA)**  | 데이터를 조회·시각화하여 인사이트 도출 | SQL, BI 도구 (Tableau, Power BI) |
| **데이터 과학자(DS)**  | ML 모델을 만들어 예측·분류 수행   | Python, R, MLflow, TensorFlow  |
| **데이터 아키텍트**     | 전체 데이터 시스템의 구조 설계     | 아키텍처 도구, 거버넌스 프레임워크            |
| **애널리틱스 엔지니어**   | 분석용 데이터 모델(테이블) 설계·관리 | SQL, dbt                       |

***

## 데이터 파이프라인의 큰 그림

데이터 엔지니어링의 핵심 산출물은 **데이터 파이프라인(Data Pipeline)** 입니다. 파이프라인은 데이터가 소스에서 최종 목적지까지 흘러가는 전체 경로를 의미합니다.

| 단계                  | 구성 요소                          | 설명             |
| ------------------- | ------------------------------ | -------------- |
| 데이터 소스              | 운영 DB, 로그 파일, SaaS API, IoT 센서 | 원본 데이터 발생지     |
| 수집 (Ingestion)      | Batch, Streaming               | 데이터를 플랫폼으로 가져옴 |
| 저장 (Storage)        | 데이터 레이크, 데이터 웨어하우스             | 수집된 데이터 저장     |
| 변환 (Transformation) | ETL/ELT                        | 데이터 정제, 표준화    |
| 서빙 (Serving)        | BI 대시보드, ML 모델, 애플리케이션         | 최종 소비자에게 전달    |

> 💡 **핵심 포인트**: 데이터 파이프라인은 "한 번 만들면 끝"이 아닙니다. 매일, 매시간, 때로는 실시간으로 반복 실행되어야 하며, 중간에 오류가 나면 자동으로 감지하고 복구할 수 있어야 합니다. 이것이 데이터 엔지니어링을 단순한 스크립트 작성과 구별짓는 핵심입니다.

***

## 현대 데이터 엔지니어링의 트렌드

데이터 엔지니어링은 빠르게 진화하고 있습니다. 최근의 주요 트렌드를 살펴보겠습니다.

### 클라우드 네이티브 (Cloud-Native)

과거에는 온프레미스(On-Premise) 서버에 직접 Hadoop 클러스터를 구축했지만, 현재는 클라우드 기반 플랫폼(Databricks, Snowflake 등)을 사용하는 것이 표준이 되었습니다. 필요할 때 리소스를 늘리고, 사용하지 않을 때 줄이는 탄력적인 운영이 가능합니다.

### 레이크하우스 패러다임 (Lakehouse)

데이터 레이크와 데이터 웨어하우스의 장점을 결합한 새로운 아키텍처입니다. 하나의 플랫폼에서 모든 데이터를 저장하고, SQL 분석부터 ML 학습까지 수행할 수 있습니다. (이 내용은 [03. 레이크하우스 아키텍처](../03-lakehouse-architecture/README)에서 자세히 다룹니다.)

### 선언적 파이프라인 (Declarative Pipelines)

"어떻게(How)" 처리할지 일일이 코딩하는 대신, "무엇을(What)" 만들고 싶은지만 선언하면 시스템이 알아서 처리해 주는 방식입니다. Databricks의 Spark Declarative Pipelines(SDP)가 대표적인 예시입니다.

### 실시간 처리의 보편화

과거에는 하루에 한 번 배치로 처리하는 것이 일반적이었지만, 이제는 몇 초\~몇 분 이내에 데이터를 처리하는 니어 리얼타임(Near Real-Time) 처리가 많은 기업에서 표준이 되어가고 있습니다.

***

## 현장에서 배운 것들: 데이터 엔지니어의 현실

### 데이터 엔지니어의 실제 하루 일과

교과서에서는 데이터 엔지니어가 우아하게 파이프라인을 설계하고, 멋진 아키텍처를 그리는 모습을 보여줍니다. 현실은 좀 다릅니다. 제가 20년간 현업에서 관찰한 데이터 엔지니어의 **실제 하루** 를 솔직하게 그려보겠습니다.

| 시간               | 하는 일                                                     | 비율                   |
| ---------------- | -------------------------------------------------------- | -------------------- |
| **09:00\~09:30** | 슬랙 확인: "어젯밤 ETL 실패했어요" 알림 3건                             | 장애 대응                |
| **09:30\~11:00** | 실패한 파이프라인 디버깅: 원본 DB 스키마가 변경됨 → NULL 컬럼 추가됨 → 스키마 불일치 에러 | **장애 대응 (30%)**      |
| **11:00\~12:00** | 분석가 요청: "이 데이터 어디서 오는 거예요?" "이 컬럼이 NULL인 이유가 뭐예요?" 응대    | **데이터 지원 (15%)**     |
| **13:00\~14:30** | 신규 소스 시스템 연동 작업 (API 문서 읽기, 인증 설정, 스키마 매핑)               | **새 파이프라인 개발 (20%)** |
| **14:30\~16:00** | 기존 파이프라인 성능 튜닝: 쿼리가 3시간 걸리는 원인 분석 → 잘못된 JOIN 순서 발견       | **최적화 (15%)**        |
| **16:00\~17:00** | 인프라 관리: 클러스터 사이즈 조정, 비용 리포트 확인, VACUUM/OPTIMIZE 스케줄 확인   | **인프라 운영 (10%)**     |
| **17:00\~18:00** | 코드 리뷰, 문서화, 팀 미팅                                         | **협업 (10%)**         |

> 💡 **핵심 현실**: 데이터 엔지니어가 가장 많은 시간을 쓰는 일은 **새 파이프라인 개발이 아니라 기존 파이프라인의 장애 대응과 데이터 품질 관리** 입니다. 파이프라인은 "만들면 끝"이 아니라, 원본 시스템이 바뀌고, 데이터 볼륨이 증가하고, 비즈니스 요건이 변할 때마다 계속 관리해야 하는 **살아있는 시스템** 입니다.

### 데이터 엔지니어 역할의 진화: ETL 개발자에서 플랫폼 엔지니어로

데이터 엔지니어의 역할은 지난 20년간 극적으로 변했습니다.

| 시대             | 역할 이름        | 주요 업무                                       | 핵심 스킬                               |
| -------------- | ------------ | ------------------------------------------- | ----------------------------------- |
| **2005\~2012** | ETL 개발자      | Informatica/DataStage로 ETL 작성, Oracle DW 관리 | SQL, ETL 도구, 스키마 설계                 |
| **2012\~2017** | 빅데이터 엔지니어    | Hadoop/Hive/Pig 스크립트 작성, 클러스터 관리            | Java/Scala, Hadoop 생태계, Linux       |
| **2017\~2022** | 데이터 엔지니어     | Spark/Airflow/dbt로 파이프라인 구축, 클라우드 관리        | Python, Spark, SQL, 클라우드(AWS/Azure) |
| **2022\~현재**   | 데이터 플랫폼 엔지니어 | 셀프서비스 플랫폼 구축, 거버넌스 설계, 비용 최적화               | IaC, CI/CD, 거버넌스, 비용 관리, LLM/AI 활용  |

> ⚠️ **이것을 안 하면 이런 일이 벌어집니다**: 2025년에도 "ETL 스크립트만 잘 짜면 된다"고 생각하면 경쟁력을 잃습니다. 현대 데이터 엔지니어에게 요구되는 역량은 코딩 능력보다 **플랫폼 설계, 거버넌스, 비용 최적화, 그리고 비즈니스 이해** 입니다.

### 현대 데이터 엔지니어에게 필요한 스킬셋

실무에서 채용할 때, 그리고 팀 역량을 키울 때 제가 사용하는 스킬 매트릭스입니다.

#### 필수 스킬 (Must Have)

| 스킬           | 왜 필요한가                     | 수준 기준                          |
| ------------ | -------------------------- | ------------------------------ |
| **SQL**      | 데이터 파이프라인의 80%는 SQL로 작성 가능 | 윈도우 함수, CTE, 최적화를 자유자재로        |
| **Python**   | 비정형 처리, API 연동, 자동화        | pandas, API 호출, 에러 핸들링 수준      |
| **Spark 기초** | 대규모 데이터 처리의 표준             | DataFrame API, 파티셔닝 이해, 셔플 최소화 |
| **Git**      | 코드 버전 관리, 팀 협업의 기반         | 브랜치 전략, PR 리뷰, CI/CD 연동        |
| **클라우드 기초**  | 인프라 이해, 비용 인식              | S3/ADLS, IAM, 네트워크 기본          |

#### 차별화 스킬 (Nice to Have → 점점 Must로)

| 스킬                          | 왜 중요해지고 있는가         | Databricks에서의 활용                          |
| --------------------------- | ------------------- | ----------------------------------------- |
| **IaC (Terraform, Pulumi)** | 인프라를 코드로 관리, 환경 재현성 | Workspace, 클러스터 정책, UC 설정 자동화             |
| **Asset Bundles / CI/CD**   | 파이프라인 배포 자동화        | DAB로 Jobs, Pipelines 배포                   |
| **데이터 거버넌스**                | 규제 대응, 데이터 품질       | Unity Catalog 설계, Row Filter, Column Mask |
| **비용 최적화**                  | FinOps의 핵심          | 클러스터 사이징, Spot 활용, 쿼리 최적화                 |
| **데이터 모델링**                 | 분석 효율성, 성능의 근간      | Star Schema, SCD, Medallion 아키텍처          |

#### 2025년 떠오르는 스킬

| 스킬               | 배경                           | 활용                                       |
| ---------------- | ---------------------------- | ---------------------------------------- |
| **LLM/GenAI 활용** | 코드 생성, 데이터 분류, 비정형 처리에 AI 활용 | Databricks AI Functions, Agent Framework |
| **데이터 품질 엔지니어링** | 데이터 신뢰도가 비즈니스 의사결정의 기반       | SDP Expectations, Great Expectations     |
| **DataOps**      | 소프트웨어 엔지니어링 프랙티스를 데이터에 적용    | 테스트, 모니터링, 관찰 가능성(Observability)         |

### 데이터 파이프라인 장애 대응: 가장 흔한 5가지 원인

"데이터 엔지니어가 가장 많이 하는 일은 데이터 파이프라인 장애 대응이다"라고 말씀드렸습니다. 제가 20년간 경험한 장애 원인을 빈도순으로 정리합니다.

| 순위     | 원인           | 빈도  | 증상                                              | 예방법                                      |
| ------ | ------------ | --- | ----------------------------------------------- | ---------------------------------------- |
| **1위** | 원본 스키마 변경    | 30% | "AnalysisException: cannot resolve column name" | 스키마 진화(Schema Evolution) 활성화, 변경 감지 모니터링 |
| **2위** | 데이터 볼륨 급증    | 25% | OOM(Out of Memory), 타임아웃                        | 오토스케일링, 적응형 쿼리 실행(AQE), 데이터 볼륨 알림        |
| **3위** | 원본 시스템 장애/지연 | 20% | 데이터 미도착, 불완전 적재                                 | 재시도 로직, 데이터 완전성 체크(row count 비교)         |
| **4위** | 코드 변경 오류     | 15% | 배포 후 파이프라인 실패                                   | CI/CD 파이프라인, 스테이징 환경 테스트, 코드 리뷰          |
| **5위** | 인프라 이슈       | 10% | 클러스터 시작 실패, 네트워크 에러                             | Serverless 활용, 멀티 AZ 구성, 장애 알림           |

> 💡 **장애 대응의 핵심 원칙**: (1) **감지가 빨라야 합니다**— 고객이 발견하기 전에 알림이 와야 합니다. (2) **복구가 자동이어야 합니다**— 일시적 장애는 재시도로 해결. (3) **근본 원인 제거**— 같은 장애가 3번 반복되면 아키텍처를 바꿔야 합니다.

### ETL vs ELT: 현대 데이터 엔지니어링의 패러다임 전환

데이터 엔지니어링을 이해하려면 ETL과 ELT의 차이를 알아야 합니다. 이 패러다임 전환이 현대 데이터 엔지니어링의 핵심 흐름입니다.

| 비교             | ETL (Extract-Transform-Load)       | ELT (Extract-Load-Transform) |
| -------------- | ---------------------------------- | ---------------------------- |
| **순서**         | 추출 → **변환**→ 적재                    | 추출 → 적재 → **변환**             |
| **변환 위치**      | 별도 ETL 서버 (Informatica, DataStage) | 타겟 시스템 내부 (Spark, SQL)       |
| **원본 보존**      | 원본이 변환 후 사라질 수 있음                  | 원본을 그대로 저장 (Bronze 레이어)      |
| **유연성**        | 변환 로직을 바꾸면 처음부터 다시                 | 원본이 있으므로 언제든 다시 변환 가능        |
| **시대**         | 2000\~2015년 주류                     | 2015년\~ 현재 주류                |
| **Databricks** | -                                  | ELT 방식 (Bronze→Silver→Gold)  |

> 💡 **왜 ELT가 승리했는가**: 클라우드 스토리지가 극도로 저렴해졌기 때문입니다. S3에 원본을 그대로 저장하는 비용이 TB당 월 \$23 수준이므로, "일단 저장하고 나중에 변환"하는 것이 경제적으로 합리적입니다. 또한 원본을 보존하면 비즈니스 요건이 바뀌었을 때 처음부터 재수집하지 않아도 됩니다. 이것이 Medallion 아키텍처(Bronze→Silver→Gold)의 기반입니다.

### 데이터 품질: 모든 것의 기반

파이프라인을 아무리 잘 만들어도, **데이터 품질이 나쁘면 아무 소용이 없습니다.**"쓰레기가 들어가면 쓰레기가 나온다(Garbage In, Garbage Out)"는 데이터 엔지니어링의 불변의 법칙입니다.

| 품질 차원                 | 의미                   | 검증 예시                           |
| --------------------- | -------------------- | ------------------------------- |
| **완전성(Completeness)** | 필수 데이터가 누락 없이 존재하는가  | 주문 테이블에 고객 ID가 NULL인 비율 \< 0.1% |
| **정확성(Accuracy)**     | 데이터가 실제 값을 정확히 반영하는가 | 주문 금액이 음수가 아닌가, 날짜가 미래가 아닌가     |
| **일관성(Consistency)**  | 시스템 간 데이터가 일치하는가     | 주문 시스템과 결제 시스템의 총액이 같은가         |
| **적시성(Timeliness)**   | 데이터가 필요한 시점에 제공되는가   | 일일 리포트에 어제 데이터가 포함되어 있는가        |
| **유일성(Uniqueness)**   | 중복 데이터가 없는가          | 같은 주문이 두 번 적재되지 않았는가            |

> ⚠️ **이것을 안 하면 이런 일이 벌어집니다**: 한 고객이 데이터 품질 검증 없이 6개월간 파이프라인을 운영했습니다. 어느 날 CEO에게 보고된 매출이 실제보다 20% 높다는 것을 발견했습니다. 원인은 결제 실패 건이 걸러지지 않고 매출에 포함된 것이었습니다. **데이터 품질 문제는 발견이 늦을수록 피해가 기하급수적으로 커집니다.** Databricks의 SDP Expectations 기능을 사용하면 파이프라인 내부에서 품질 규칙을 선언적으로 정의할 수 있습니다.

### 데이터 엔지니어링과 Databricks: 왜 이 조합인가

전통적으로 데이터 엔지니어는 **10개 이상의 도구** 를 조합해서 파이프라인을 구축했습니다. Databricks는 이 도구 파편화를 해결합니다.

| 기존 방식 (도구 파편화)                           | Databricks 통합                        | 이점                    |
| ---------------------------------------- | ------------------------------------ | --------------------- |
| Airflow (오케스트레이션) + Spark (처리) + S3 (저장) | Lakeflow Jobs + Spark + Delta Lake   | 하나의 플랫폼에서 관리          |
| dbt (SQL 변환) + Great Expectations (품질)   | SDP (선언적 파이프라인 + Expectations 내장)    | 변환과 품질 검사를 한 곳에서      |
| Apache Kafka (수집) + Debezium (CDC)       | Lakeflow Connect (커넥터) + Auto Loader | 코드 없이 수집              |
| Terraform (인프라) + GitHub Actions (CI/CD) | Databricks Asset Bundles (DAB)       | 파이프라인 코드와 인프라를 함께 관리  |
| Ranger/Sentry (거버넌스) + Atlas (메타데이터)     | Unity Catalog (통합 거버넌스)              | 권한, 리니지, 메타데이터를 한 곳에서 |

#### 도구 파편화의 실제 비용

"도구가 많으면 뭐가 문제냐?"고 물으실 수 있습니다. 실제 비용을 계산해 보겠습니다.

| 비용 항목       | 10개 도구 조합                                                          | Databricks 통합               | 차이              |
| ----------- | ------------------------------------------------------------------ | --------------------------- | --------------- |
| **라이선스/구독** | Airflow(인프라) + dbt(Cloud) + Fivetran + GE + ... = 월 $5,000~$15,000 | Databricks DBU만 과금          | 상당 부분 절감        |
| **학습 비용**   | 엔지니어 1인당 10개 도구 학습 = 3\~6개월 온보딩                                    | 하나의 플랫폼 학습 = 1\~2개월         | 온보딩 60% 단축      |
| **통합 유지보수** | 도구 간 인터페이스 변경 대응, 버전 호환성                                           | 단일 플랫폼 업그레이드                | 운영 공수 50% 감소    |
| **장애 진단**   | "에러가 어디서 난 거지?" — 5개 시스템 로그를 뒤져야                                   | 단일 Job UI에서 전체 흐름 확인        | 장애 대응 시간 70% 단축 |
| **채용**      | "Airflow + Spark + dbt + Terraform + Kafka 경험자" — 구하기 어려움          | "Databricks 경험자" — 상대적으로 수월 | 채용 효율 향상        |

> ⚠️ **오해하지 마세요**: "Databricks가 모든 도구를 대체한다"는 뜻이 아닙니다. 조직의 상황에 따라 Airflow, dbt 등 기존 도구를 Databricks와 함께 사용하는 것이 더 나은 경우도 많습니다. 핵심은 **도구의 수를 줄이고, 통합의 복잡성을 낮추는 것** 입니다.

### 데이터 엔지니어링 커리어 로드맵

마지막으로, 데이터 엔지니어링 분야로 진입하거나 성장하고 싶은 분들을 위한 현실적인 로드맵입니다.

| 단계       | 기간      | 목표                | 핵심 학습                                |
| -------- | ------- | ----------------- | ------------------------------------ |
| **입문**   | 0\~6개월  | SQL과 Python 기초 숙달 | SQL 윈도우 함수, Python pandas, 기초 ETL 작성 |
| **주니어**  | 6\~18개월 | 첫 프로덕션 파이프라인 구축   | Spark 기초, Delta Lake, 배치 파이프라인, Git  |
| **미들**   | 1.5\~3년 | 복잡한 파이프라인 설계/운영   | 스트리밍, 데이터 모델링, 성능 튜닝, CI/CD          |
| **시니어**  | 3\~5년   | 팀의 데이터 아키텍처 설계    | 거버넌스 설계, 비용 최적화, 팀 멘토링               |
| **스태프+** | 5년+     | 조직 전체의 데이터 전략     | 멀티팀 플랫폼, 데이터 메시, 기술 전략               |

> 💡 **현업 조언**: 데이터 엔지니어링은 "코딩만 잘하면 되는" 분야가 아닙니다. 비즈니스 도메인 이해, 커뮤니케이션 능력, 비용 감각이 시니어로 갈수록 중요해집니다. 가장 좋은 데이터 엔지니어는 "왜 이 데이터가 필요한지"를 이해하는 사람입니다.

### 데이터 엔지니어의 비용 감각: FinOps 시대의 필수 역량

클라우드 시대에 데이터 엔지니어에게 "비용 감각"은 선택이 아닌 필수입니다. 코드를 잘 짜는 것만큼, **그 코드가 얼마의 비용을 발생시키는지** 아는 것이 중요합니다.

| 비용 발생 포인트    | 흔한 실수                     | 절감 방법                             | 절감 효과   |
| ------------ | ------------------------- | --------------------------------- | ------- |
| **클러스터 유휴**  | All-Purpose 클러스터를 24시간 켜둠 | 자동 종료 설정 (10\~30분)                | 60\~80% |
| **과도한 셔플**   | 큰 테이블끼리 무작정 JOIN          | 브로드캐스트 조인, 파티셔닝 최적화               | 30\~50% |
| **풀 스캔**     | `SELECT *` 남발             | 필요한 컬럼만, 파티션 프루닝 활용               | 40\~70% |
| **스토리지 방치**  | VACUUM 미실행, 임시 테이블 방치     | 정기 VACUUM, 임시 데이터 정리 정책           | 20\~40% |
| **중복 파이프라인** | 같은 데이터를 여러 팀이 각각 가공       | Feature Store, 공용 Silver/Gold 레이어 | 30\~50% |

> ⚠️ **이것을 안 하면 이런 일이 벌어집니다**: 한 고객의 데이터 팀이 비용 의식 없이 6개월간 개발한 결과, 월간 클라우드 비용이 $50,000에서 $180,000으로 3.6배 증가했습니다. 원인의 60%는 "유휴 클러스터"와 "비용이 높은 쿼리"였으며, 2주간의 최적화 작업으로 \$80,000까지 줄일 수 있었습니다.

### 데이터 엔지니어링 장애 대응 플레이북

프로덕션 파이프라인 장애 시, 패닉하지 않고 체계적으로 대응하는 플레이북입니다.

| 단계                                 | 시간  | 행동          | 상세                                                                    |
| ---------------------------------- | --- | ----------- | --------------------------------------------------------------------- |
| **장애 감지**                          | 즉시  | 알림 수신       | Slack/PagerDuty/이메일                                                   |
| **Step 1**                         | 2분  | 영향 범위 파악    | 어떤 테이블이 영향받았나? 다운스트림 대시보드/모델은?                                        |
| **Step 2**                         | 5분  | 이해관계자 통보    | "데이터 지연이 발생했습니다. X시까지 복구 예정입니다"                                       |
| **Step 3**                         | 10분 | 원인 분류       | 소스 시스템 문제 → 소스 팀 연락, 스키마 변경 → 스키마 진화 설정 확인, 리소스 부족 → 스케일업, 코드 버그 → 롤백 |
| **Step 4**                         | -   | 복구 실행       | 재실행 가능 → Job 재시작, 데이터 수정 필요 → 타임 트래블 복원 후 재처리                         |
| **Step 5**                         | -   | 사후 분석 (RCA) |                                                                       |
| "같은 장애가 다시 발생하지 않으려면 무엇을 바꿔야 하는가?" |     |             |                                                                       |

```

> 💡 **장애 대응의 황금 규칙**: (1) 먼저 **영향 범위를 파악** 하고 이해관계자에게 알립니다. (2) **원인 파악은 그다음** 입니다. 많은 엔지니어가 디버깅부터 시작하지만, 경영진이 "지금 대시보드가 왜 안 나오냐"고 물어보는 상황이 더 스트레스입니다.

---

### "데이터 엔지니어가 아닌 분에게 드리는 조언"

분석가, 데이터 과학자, 혹은 경영진이 데이터 엔지니어와 효과적으로 협업하기 위해 알아두면 좋은 것들입니다.

| 상황 | 이렇게 요청하면 좋습니다 | 이렇게 요청하면 힘듭니다 |
|------|----------------------|----------------------|
| 새 데이터 소스 추가 | "이 API의 문서입니다. 일 1회 배치로 충분합니다" | "어디서든 데이터 좀 가져와주세요" |
| 쿼리 성능 개선 | "이 쿼리가 5분 걸리는데, 30초 안에 나와야 합니다" | "느린 거 좀 빨리 해주세요" |
| 데이터 품질 이슈 | "이 컬럼에 NULL이 15% 있는데, 원래 0%여야 합니다" | "데이터가 이상해요" |
| 긴급 데이터 수정 | "이 조건의 5건만 이 값으로 변경해주세요" (영향 범위 명확) | "프로덕션 DB 좀 고쳐주세요" |

> 💡 **데이터 엔지니어에 대한 가장 큰 오해**: "데이터를 옮기기만 하는 사람"이라고 생각하는 것. 실제로는 데이터의 **품질, 보안, 성능, 비용** 까지 책임지는 데이터 파이프라인의 **전체 라이프사이클 관리자** 입니다. 좋은 데이터 엔지니어 한 명이 분석팀 10명의 생산성을 좌우합니다.

### 데이터 엔지니어링의 성공을 측정하는 지표

"우리 데이터 엔지니어링이 잘 되고 있는가?"를 측정하는 핵심 지표(KPI)입니다. 경영진에게 보고할 때 사용하세요.

| 지표 | 설명 | 건강한 수준 | 위험 신호 |
|------|------|-----------|----------|
| **파이프라인 성공률** | 전체 Job 실행 중 성공 비율 | > 98% | < 95% |
| **SLA 준수율** | 약속된 시간까지 데이터가 준비된 비율 | > 99% | < 95% |
| **데이터 신선도(Freshness)** | 데이터가 마지막으로 갱신된 시점 | 목표 지연 이내 | 2배 이상 초과 |
| **데이터 품질 스코어** | 품질 규칙 통과 비율 | > 99.5% | < 98% |
| **평균 복구 시간(MTTR)** | 장애 발생~복구까지 소요 시간 | < 30분 | > 2시간 |
| **컴퓨트 비용 효율** | 처리된 데이터 TB당 비용 | 월간 추세 감소 | 월간 추세 증가 |
| **온보딩 시간** | 새 데이터 소스 연동까지 소요 시간 | < 1주 | > 1개월 |

> 💡 **측정하지 않으면 개선할 수 없습니다.**Databricks의 시스템 테이블(`system.lakeflow`, `system.billing`, `system.query`)을 활용하면 이 지표들을 자동으로 수집하고 대시보드로 시각화할 수 있습니다.

---

## 정리

| 핵심 개념 | 설명 |
|-----------|------|
| 데이터 엔지니어링 | 원시 데이터를 수집·변환·적재하여 분석 가능한 형태로 만드는 과정 |
| 데이터 파이프라인 | 데이터가 소스에서 목적지까지 흘러가는 자동화된 경로 |
| 수집(Ingestion) | 다양한 소스에서 데이터를 가져오는 첫 번째 단계 |
| 변환(Transformation) | 원시 데이터를 정제·표준화·통합하는 단계 |
| 적재(Loading) | 최종 목적지(웨어하우스, 레이크)에 저장하는 단계 |

다음 문서에서는 데이터를 저장하는 두 가지 대표적인 방식인 **데이터 웨어하우스** 와 **데이터 레이크** 의 차이점을 자세히 살펴보겠습니다.

---

## 참고 링크

- [Databricks: Data Engineering 공식 문서](https://docs.databricks.com/aws/en/data-engineering)
- [Azure Databricks: What is data engineering?](https://learn.microsoft.com/en-us/azure/databricks/data-engineering/)
- [Databricks Blog: Data Engineering](https://www.databricks.com/blog/category/engineering-blog)
```