[견고한 데이터 엔지니어링] 01장

March 5, 2026

book-cover

[견고한 데이터 엔지니어링] 1장. 데이터 엔지니어링이란 무엇인가?

읽은 책: Fundamentals of Data Engineering (Joe Reis, Matt Housley)
목표: 데이터 엔지니어링의 정의와 데이터 엔지니어의 역할, 데이터 엔지니어링 생애주기를 큰 그림으로 잡기

0. 이 장이 던지는 질문

데이터 엔지니어링이라는 직군은 최근에 생겨난 것처럼 느껴지지만,
사실 데이터가 존재하는 순간부터 누군가는 항상 데이터를 “쓸 수 있는 형태로 만드는” 일을 해왔다.

이 장의 핵심 질문은 이거다:

데이터 엔지니어링이란 정확히 무엇인가?
데이터 엔지니어는 다른 직군(데이터 과학자, 데이터 분석가)과 어떻게 다른가?
데이터 엔지니어에게 요구되는 비즈니스/기술 역량은 무엇인가?
조직의 데이터 성숙도에 따라 데이터 엔지니어의 역할은 어떻게 달라지는가?

1. 데이터 엔지니어링이란?

책에서 제시하는 정의:

“데이터 엔지니어링은 원시 데이터를 고품질의 일관된 정보로 변환하는 시스템과 프로세스를 개발, 구현, 유지보수하는 것이다.”

핵심 키워드를 정리하면:

원시 데이터(Raw Data): 저장된 그대로의, 정제되지 않은 데이터
고품질·일관된 정보: 다운스트림(분석, ML 등)에서 실제로 활용 가능한 형태
시스템과 프로세스: 단발성 작업이 아닌, 재현 가능하고 안정적인 파이프라인

중요 포인트:

데이터 엔지니어링은 “데이터 과학을 위한 준비 작업”에 그치지 않는다.
비즈니스 가치를 만들어 내는 독립적인 엔지니어링 분야다.

2. 데이터 엔지니어 vs 데이터 과학자

많은 사람이 두 직군을 혼동하지만, 책은 명확하게 구분한다.

구분	데이터 엔지니어	데이터 과학자
주된 관심사	데이터 수집·이동·저장·변환	데이터 분석·모델링·예측
산출물	데이터 파이프라인, 데이터 플랫폼	인사이트, ML 모델
핵심 역량	시스템 설계, 분산 처리, 데이터 아키텍처	통계, ML, 도메인 지식
주요 질문	“어떻게 데이터를 안정적으로 전달할까?”	“데이터에서 무엇을 발견할 수 있나?”

개인 메모: 현실에서 두 역할이 겹치는 경우가 많지만,
조직이 성숙할수록 분리된다. 데이터 엔지니어 없이는 데이터 과학자도 일하기 어렵다.

3. 데이터 엔지니어링 생애주기(Data Engineering Lifecycle)

이 책의 핵심 프레임워크다. 데이터가 소스에서 최종 소비까지 거치는 5단계를 정의한다.

생성(Generation) → 저장(Storage) → 수집(Ingestion) → 변환(Transformation) → 서빙(Serving)

3.1 생성(Generation)

소스 시스템에서 데이터가 만들어지는 단계
애플리케이션 DB, IoT 디바이스, 로그, 서드파티 API 등
데이터 엔지니어가 직접 제어하기 어렵지만, 소스 데이터의 특성을 이해해야 한다.

3.2 저장(Storage)

데이터를 어디에, 어떻게 저장할 것인가
오브젝트 스토리지(S3 등), 데이터 레이크, 데이터 웨어하우스, RDBMS 등
“저장”은 단순히 쌓는 것이 아니라 접근 빈도, 비용, 쿼리 패턴을 고려한 설계다.

3.3 수집(Ingestion)

소스 시스템에서 데이터를 가져오는 단계
배치(Batch) vs 스트리밍(Streaming) 방식 선택이 핵심
신뢰성과 장애 복구 능력도 설계에 포함돼야 한다.

3.4 변환(Transformation)

원시 데이터를 분석/ML에 적합한 형태로 가공하는 단계
정제, 집계, 조인, 비즈니스 로직 적용 등
데이터 품질과 일관성을 여기서 보장해야 한다.

3.5 서빙(Serving)

최종 소비자(분석가, 데이터 과학자, 애플리케이션)에게 데이터를 제공하는 단계
BI 대시보드, ML 피처 스토어, 사용자 facing API 등
다운스트림 사용자가 실제로 쓸 수 있어야 한다는 게 핵심이다.

개인 메모: 생애주기를 이해하면 “나는 전체 흐름의 어느 부분을 담당하는가”를 명확히 알 수 있다.
파이프라인 하나가 터졌을 때 어디부터 봐야 하는지도 빨라진다.

4. 데이터 성숙도(Data Maturity)와 엔지니어의 역할

조직마다 데이터 활용 수준이 다르다.
책은 이를 3단계 성숙도로 구분하고, 각 단계에서 데이터 엔지니어의 역할이 다름을 강조한다.

4.1 1단계: 데이터로 시작하기(Starting with Data)

데이터 인프라가 거의 없는 초기 단계
데이터 엔지니어가 전체를 혼자 다 해야 하는 경우가 많음
우선순위: 빠른 가치 증명, 너무 이른 아키텍처 복잡화는 금물

4.2 2단계: 데이터로 확장하기(Scaling with Data)

데이터 인프라가 갖춰지기 시작하고, 팀이 성장하는 단계
공식적인 데이터 파이프라인, 데이터 웨어하우스 도입이 시작됨
데이터 품질, 거버넌스 이슈가 수면 위로 올라온다.

4.3 3단계: 데이터로 선도하기(Leading with Data)

데이터가 비즈니스 의사결정의 핵심 자산인 단계
셀프서비스 분석, ML 기반 의사결정, 실시간 데이터가 일상화
데이터 엔지니어는 플랫폼/아키텍처 수준의 역할을 담당

개인 메모: 대부분의 스타트업은 1~2단계 사이 어딘가에 있다.
현 단계보다 과도한 아키텍처는 오히려 독이 된다. 성숙도에 맞는 선택이 중요하다.

5. 데이터 엔지니어에게 요구되는 역량

5.1 비즈니스 역량

비용과 가치의 균형을 이해한다.
다운스트림 사용자(분석가, 데이터 과학자, 비즈니스)의 요구를 파악한다.
“기술적으로 가능한 것”이 아닌 “비즈니스에 가치 있는 것”을 우선한다.
커뮤니케이션과 협업 능력이 핵심이다.

5.2 기술 역량

데이터 아키텍처 설계: 시스템 간 데이터 흐름과 저장 전략 이해
소프트웨어 엔지니어링: 코딩, 테스트, 버전 관리, CI/CD
데이터 파이프라인 운영: 배치/스트리밍, 오케스트레이션(Airflow 등)
클라우드 플랫폼: AWS, GCP, Azure의 데이터 서비스 활용
데이터 품질·거버넌스: 데이터 신뢰성과 메타데이터 관리

개인 메모: 기술 역량 목록이 방대하게 느껴지지만,
결국 “데이터가 어디서 와서 어디로 가는가”를 이해하는 게 가장 기본이다.

6. 데이터 엔지니어링의 “언디커런트(Undercurrent)”

책이 생애주기 외에 강조하는 횡단 관심사(cross-cutting concerns):

보안(Security): 접근 제어, 암호화, 민감 데이터 처리
데이터 관리(Data Management): 데이터 카탈로그, 계보(Lineage), 품질 관리
데이터옵스(DataOps): 파이프라인의 운영 자동화, 모니터링, 장애 대응
데이터 아키텍처(Data Architecture): 시스템 전체의 설계 원칙
오케스트레이션(Orchestration): 파이프라인 의존성·스케줄링 관리
소프트웨어 엔지니어링(Software Engineering): 코드 품질과 테스트 가능성

이 언디커런트들은 생애주기의 특정 단계에 국한되지 않고 전체에 걸쳐 적용된다.

7. 이 장의 결론: 데이터 엔지니어링의 큰 그림

정리하면:

데이터 엔지니어링은 원시 데이터를 쓸 수 있는 정보로 만드는 시스템과 프로세스 전체다.
생애주기는 생성 → 저장 → 수집 → 변환 → 서빙의 5단계다.
데이터 성숙도에 따라 엔지니어의 역할과 집중해야 할 아키텍처 복잡도가 달라진다.
비즈니스 역량과 기술 역량을 모두 갖춰야 진짜 데이터 엔지니어다.
생애주기 전반에 걸친 언디커런트(보안, 거버넌스, DataOps 등)을 놓치면 안 된다.

8. 내가 적용해볼 체크리스트

현재 내가 담당하는 데이터 파이프라인이 생애주기의 어느 단계에 걸쳐 있는지 설명할 수 있나?
우리 조직의 데이터 성숙도 단계는 어디인가? 현 단계에 맞는 아키텍처를 쓰고 있나?
데이터 소스의 특성(변경 빈도, 볼륨, 스키마)을 문서화하고 있나?
파이프라인 장애 시 탐지·복구 프로세스가 정의돼 있나?
다운스트림 사용자가 데이터를 어떻게 쓰는지 파악하고 있나?

9. 한 줄 요약(5줄)

데이터 엔지니어링은 원시 데이터를 고품질 정보로 만드는 시스템과 프로세스 전체다.
데이터 엔지니어링 생애주기는 생성·저장·수집·변환·서빙의 5단계로 구성된다.
조직의 데이터 성숙도에 따라 엔지니어가 집중해야 할 역할과 아키텍처가 달라진다.
비즈니스 이해와 기술 역량을 함께 갖춰야 한다.
보안, 거버넌스, DataOps 등의 언디커런트는 생애주기 전체에 걸쳐 적용돼야 한다.