데이터 엔지니어링이란?

​

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

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

​

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

​

1. 데이터 수집 (Ingestion)

​

2. 데이터 변환 (Transformation)

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

​

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

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

​

데이터 팀의 구성과 역할

​

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

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

​

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

​

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

​

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

​

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

​

실시간 처리의 보편화

​

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

​

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

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

​

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

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

​

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

​

필수 스킬 (Must Have)

​

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

​

2025년 떠오르는 스킬

​

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

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

​

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

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

​

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

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

​

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

​

도구 파편화의 실제 비용

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

​

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

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

​

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

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

​

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

> 💡 **장애 대응의 황금 규칙**: (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)