이 문서는 데이터 기초 섹션의 일부입니다.
왜 데이터 엔지니어링이 필요한가요?
여러분이 대형 쇼핑몰을 운영한다고 상상해 보겠습니다. 매일 수만 건의 주문이 들어오고, 고객의 클릭 로그가 쌓이며, 재고 시스템에서는 실시간으로 수량이 변하고 있습니다. 이 모든 데이터를 그냥 방치하면 어떻게 될까요? 아마 “이번 달 가장 잘 팔린 상품이 뭐지?”, “어떤 고객이 이탈 위험이 높지?” 같은 간단한 질문조차 답하기 어려울 것입니다. 데이터 엔지니어링(Data Engineering) 은 바로 이 문제를 해결합니다. 여기저기 흩어져 있는 원시 데이터(Raw Data)를 수집하고, 깨끗하게 정리하고, 분석가나 데이터 과학자가 바로 사용할 수 있는 형태로 만들어 주는 일련의 과정입니다.💡 쉽게 비유하면: 데이터 엔지니어링은 “데이터의 상수도 시스템”과 같습니다. 산에서 내려오는 원수(Raw Data)를 정수 처리(변환)하고, 깨끗한 물(정제된 데이터)을 각 가정(분석가, 대시보드, ML 모델)에 안정적으로 공급하는 파이프라인을 만드는 것입니다.
데이터 엔지니어링의 핵심 역할
데이터 엔지니어링은 크게 세 가지 핵심 역할을 수행합니다.1. 데이터 수집 (Ingestion)
다양한 소스에서 데이터를 가져오는 단계입니다.2. 데이터 변환 (Transformation)
수집한 원시 데이터를 분석에 적합한 형태로 가공하는 단계입니다.- 정제(Cleansing): 중복 제거, 결측값 처리, 오류 데이터 수정
- 표준화(Standardization): 날짜 형식 통일, 통화 변환, 코드값 매핑
- 통합(Integration): 여러 소스의 데이터를 하나로 합치기 (예: 주문 데이터 + 고객 데이터)
- 집계(Aggregation): 일별 매출 합산, 월별 사용자 수 계산 등
3. 데이터 적재 및 서빙 (Loading & Serving)
변환된 데이터를 최종 목적지에 저장하고, 소비자에게 제공하는 단계입니다.- 데이터 웨어하우스 에 적재하여 BI 대시보드에서 조회
- 데이터 레이크 에 저장하여 데이터 과학자가 ML 모델 학습에 활용
- 실시간 서빙 레이어 를 통해 애플리케이션에서 즉시 사용
데이터 팀의 구성과 역할
데이터 조직에는 다양한 역할이 존재합니다. 데이터 엔지니어가 어디에 위치하는지 이해하면, 전체 데이터 흐름이 더 명확해집니다.데이터 파이프라인의 큰 그림
데이터 엔지니어링의 핵심 산출물은 데이터 파이프라인(Data Pipeline) 입니다. 파이프라인은 데이터가 소스에서 최종 목적지까지 흘러가는 전체 경로를 의미합니다.💡 핵심 포인트: 데이터 파이프라인은 “한 번 만들면 끝”이 아닙니다. 매일, 매시간, 때로는 실시간으로 반복 실행되어야 하며, 중간에 오류가 나면 자동으로 감지하고 복구할 수 있어야 합니다. 이것이 데이터 엔지니어링을 단순한 스크립트 작성과 구별짓는 핵심입니다.
현대 데이터 엔지니어링의 트렌드
데이터 엔지니어링은 빠르게 진화하고 있습니다. 최근의 주요 트렌드를 살펴보겠습니다.클라우드 네이티브 (Cloud-Native)
과거에는 온프레미스(On-Premise) 서버에 직접 Hadoop 클러스터를 구축했지만, 현재는 클라우드 기반 플랫폼(Databricks, Snowflake 등)을 사용하는 것이 표준이 되었습니다. 필요할 때 리소스를 늘리고, 사용하지 않을 때 줄이는 탄력적인 운영이 가능합니다.레이크하우스 패러다임 (Lakehouse)
데이터 레이크와 데이터 웨어하우스의 장점을 결합한 새로운 아키텍처입니다. 하나의 플랫폼에서 모든 데이터를 저장하고, SQL 분석부터 ML 학습까지 수행할 수 있습니다. (이 내용은 03. 레이크하우스 아키텍처에서 자세히 다룹니다.)선언적 파이프라인 (Declarative Pipelines)
“어떻게(How)” 처리할지 일일이 코딩하는 대신, “무엇을(What)” 만들고 싶은지만 선언하면 시스템이 알아서 처리해 주는 방식입니다. Databricks의 Spark Declarative Pipelines(SDP)가 대표적인 예시입니다.실시간 처리의 보편화
과거에는 하루에 한 번 배치로 처리하는 것이 일반적이었지만, 이제는 몇 초~몇 분 이내에 데이터를 처리하는 니어 리얼타임(Near Real-Time) 처리가 많은 기업에서 표준이 되어가고 있습니다.현장에서 배운 것들: 데이터 엔지니어의 현실
데이터 엔지니어의 실제 하루 일과
교과서에서는 데이터 엔지니어가 우아하게 파이프라인을 설계하고, 멋진 아키텍처를 그리는 모습을 보여줍니다. 현실은 좀 다릅니다. 제가 20년간 현업에서 관찰한 데이터 엔지니어의 실제 하루 를 솔직하게 그려보겠습니다.💡 핵심 현실: 데이터 엔지니어가 가장 많은 시간을 쓰는 일은 새 파이프라인 개발이 아니라 기존 파이프라인의 장애 대응과 데이터 품질 관리 입니다. 파이프라인은 “만들면 끝”이 아니라, 원본 시스템이 바뀌고, 데이터 볼륨이 증가하고, 비즈니스 요건이 변할 때마다 계속 관리해야 하는 살아있는 시스템 입니다.
데이터 엔지니어 역할의 진화: ETL 개발자에서 플랫폼 엔지니어로
데이터 엔지니어의 역할은 지난 20년간 극적으로 변했습니다.⚠️ 이것을 안 하면 이런 일이 벌어집니다: 2025년에도 “ETL 스크립트만 잘 짜면 된다”고 생각하면 경쟁력을 잃습니다. 현대 데이터 엔지니어에게 요구되는 역량은 코딩 능력보다 플랫폼 설계, 거버넌스, 비용 최적화, 그리고 비즈니스 이해 입니다.
현대 데이터 엔지니어에게 필요한 스킬셋
실무에서 채용할 때, 그리고 팀 역량을 키울 때 제가 사용하는 스킬 매트릭스입니다.필수 스킬 (Must Have)
차별화 스킬 (Nice to Have → 점점 Must로)
2025년 떠오르는 스킬
데이터 파이프라인 장애 대응: 가장 흔한 5가지 원인
“데이터 엔지니어가 가장 많이 하는 일은 데이터 파이프라인 장애 대응이다”라고 말씀드렸습니다. 제가 20년간 경험한 장애 원인을 빈도순으로 정리합니다.💡 장애 대응의 핵심 원칙: (1) 감지가 빨라야 합니다— 고객이 발견하기 전에 알림이 와야 합니다. (2) 복구가 자동이어야 합니다— 일시적 장애는 재시도로 해결. (3) 근본 원인 제거— 같은 장애가 3번 반복되면 아키텍처를 바꿔야 합니다.
ETL vs ELT: 현대 데이터 엔지니어링의 패러다임 전환
데이터 엔지니어링을 이해하려면 ETL과 ELT의 차이를 알아야 합니다. 이 패러다임 전환이 현대 데이터 엔지니어링의 핵심 흐름입니다.💡 왜 ELT가 승리했는가: 클라우드 스토리지가 극도로 저렴해졌기 때문입니다. S3에 원본을 그대로 저장하는 비용이 TB당 월 $23 수준이므로, “일단 저장하고 나중에 변환”하는 것이 경제적으로 합리적입니다. 또한 원본을 보존하면 비즈니스 요건이 바뀌었을 때 처음부터 재수집하지 않아도 됩니다. 이것이 Medallion 아키텍처(Bronze→Silver→Gold)의 기반입니다.
데이터 품질: 모든 것의 기반
파이프라인을 아무리 잘 만들어도, 데이터 품질이 나쁘면 아무 소용이 없습니다.”쓰레기가 들어가면 쓰레기가 나온다(Garbage In, Garbage Out)“는 데이터 엔지니어링의 불변의 법칙입니다.⚠️ 이것을 안 하면 이런 일이 벌어집니다: 한 고객이 데이터 품질 검증 없이 6개월간 파이프라인을 운영했습니다. 어느 날 CEO에게 보고된 매출이 실제보다 20% 높다는 것을 발견했습니다. 원인은 결제 실패 건이 걸러지지 않고 매출에 포함된 것이었습니다. 데이터 품질 문제는 발견이 늦을수록 피해가 기하급수적으로 커집니다. Databricks의 SDP Expectations 기능을 사용하면 파이프라인 내부에서 품질 규칙을 선언적으로 정의할 수 있습니다.
데이터 엔지니어링과 Databricks: 왜 이 조합인가
전통적으로 데이터 엔지니어는 10개 이상의 도구 를 조합해서 파이프라인을 구축했습니다. Databricks는 이 도구 파편화를 해결합니다.도구 파편화의 실제 비용
“도구가 많으면 뭐가 문제냐?”고 물으실 수 있습니다. 실제 비용을 계산해 보겠습니다.⚠️ 오해하지 마세요: “Databricks가 모든 도구를 대체한다”는 뜻이 아닙니다. 조직의 상황에 따라 Airflow, dbt 등 기존 도구를 Databricks와 함께 사용하는 것이 더 나은 경우도 많습니다. 핵심은 도구의 수를 줄이고, 통합의 복잡성을 낮추는 것 입니다.
데이터 엔지니어링 커리어 로드맵
마지막으로, 데이터 엔지니어링 분야로 진입하거나 성장하고 싶은 분들을 위한 현실적인 로드맵입니다.💡 현업 조언: 데이터 엔지니어링은 “코딩만 잘하면 되는” 분야가 아닙니다. 비즈니스 도메인 이해, 커뮤니케이션 능력, 비용 감각이 시니어로 갈수록 중요해집니다. 가장 좋은 데이터 엔지니어는 “왜 이 데이터가 필요한지”를 이해하는 사람입니다.
데이터 엔지니어의 비용 감각: FinOps 시대의 필수 역량
클라우드 시대에 데이터 엔지니어에게 “비용 감각”은 선택이 아닌 필수입니다. 코드를 잘 짜는 것만큼, 그 코드가 얼마의 비용을 발생시키는지 아는 것이 중요합니다.⚠️ 이것을 안 하면 이런 일이 벌어집니다: 한 고객의 데이터 팀이 비용 의식 없이 6개월간 개발한 결과, 월간 클라우드 비용이 180,000으로 3.6배 증가했습니다. 원인의 60%는 “유휴 클러스터”와 “비용이 높은 쿼리”였으며, 2주간의 최적화 작업으로 $80,000까지 줄일 수 있었습니다.