동블

그래프 뷰

05. Data Engineering 학습 로드맵 상세

9 min read

이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.

  • Java/Spring 백엔드 개발자는 Data Engineering을 어떤 순서로 학습해야 하는가?
  • 운영 DB, event, batch, stream, warehouse, quality를 어떤 기준으로 연결해야 하는가?
  • 도구 사용법 학습과 운영 판단 학습은 어떻게 구분하는가?
  • 개인 프로젝트에서 로드맵을 검증하려면 어떤 산출물이 필요한가?

개요

Data Engineering 학습은 도구 이름 순서로 시작하면 쉽게 흐려진다.

백엔드 개발자에게 필요한 순서는 운영 DB의 사실, event의 의미, batch의 재계산, stream의 지연 처리, warehouse의 분석 모델, quality의 검증, runbook의 운영 대응이다.

이 순서로 배워야 API 코드와 데이터 파이프라인을 같은 서비스 흐름 안에서 설명할 수 있다.

Kafka를 먼저 배우는 것보다 “같은 event가 두 번 오면 무엇이 깨지는가”를 먼저 이해하는 편이 실전에 가깝다.

원리

학습 로드맵은 추상 개념이 아니라 산출물로 검증한다.

  • 운영 DB를 배웠으면 transaction과 source table을 설명할 수 있어야 한다.
  • event를 배웠으면 event schema와 outbox table을 설계할 수 있어야 한다.
  • batch를 배웠으면 날짜 범위 재처리와 처리 이력을 남길 수 있어야 한다.
  • stream을 배웠으면 offset, lag, idempotent consumer를 설명할 수 있어야 한다.
  • warehouse를 배웠으면 fact, dimension, mart의 grain을 정할 수 있어야 한다.
  • quality를 배웠으면 freshness, completeness, accuracy SQL을 작성할 수 있어야 한다.
  • runbook을 배웠으면 장애 영향 범위와 재실행 절차를 남길 수 있어야 한다.

추천 순서

1. OLTP와 운영 DB 경계
2. Event log와 schema
3. Batch와 scheduler
4. ETL/ELT pipeline
5. Kafka와 stream processing
6. CDC와 outbox
7. 재처리, backfill, idempotency
8. Airflow와 workflow orchestration
9. Data quality monitoring
10. 실전 runbook과 협업 문서

순서는 절대적인 커리큘럼이 아니다.

그러나 운영 DB와 event의 의미를 모른 채 orchestration 도구부터 배우면 실패 원인을 도구 설정으로만 보게 된다.

1단계: 운영 DB와 분석 경계

먼저 OLTP와 OLAP의 차이를 설명할 수 있어야 한다.

주문 API의 transaction과 일별 매출 리포트는 같은 orders table을 바라볼 수 있지만 요구사항이 다르다.

학습 산출물은 다음과 같다.

  • 운영 table과 분석 table의 목적 비교
  • 운영 DB 직접 집계의 위험 정리
  • fact와 dimension의 작은 예시
  • count와 sum 검증 SQL

2단계: Event와 Outbox

다음은 서비스 변화가 어떻게 사건으로 남는지 배운다.

Spring service에서 transaction 안에 outbox row를 남기고, relay가 broker로 발행하는 흐름을 이해한다.

CREATE TABLE outbox_event (
    event_id varchar(36) PRIMARY KEY,
    aggregate_type varchar(50) NOT NULL,
    aggregate_id varchar(100) NOT NULL,
    event_type varchar(100) NOT NULL,
    payload jsonb NOT NULL,
    created_at timestamp NOT NULL,
    published_at timestamp NULL
);

학습 목표는 event 이름보다 schema, version, key, 재발행 가능성을 잡는 것이다.

3단계: Batch와 재처리

batch는 많은 데이터를 한 번에 처리하는 기술이 아니라 범위를 정해 다시 계산하는 능력이다.

Spring Batch나 Scheduler를 쓸 때도 from, to, job_run_id, processed_count를 남겨야 한다.

실패 후 같은 범위를 다시 실행해도 target이 안전해야 한다.

이 단계에서는 작은 backfill script와 검증 SQL을 반드시 작성해 본다.

4단계: Stream과 Idempotency

stream은 빠른 처리보다 재전달을 견디는 설계가 중요하다.

Kafka consumer는 같은 message를 다시 받을 수 있다.

따라서 event id 기반 처리 이력, upsert, offset commit 순서를 이해해야 한다.

학습 산출물은 idempotent consumer 코드와 DLQ 재처리 절차다.

5단계: Pipeline과 Orchestration

여러 task가 의존성을 가지면 Airflow 같은 workflow orchestrator를 검토한다.

여기서 배울 것은 DAG 문법만이 아니다.

source partition, target partition, retry 정책, SLA, 품질 gate가 하나의 실행 단위로 연결되는 방식을 배운다.

6단계: Quality와 Runbook

마지막에는 데이터가 만들어졌다는 사실과 데이터가 믿을 수 있다는 사실을 분리한다.

freshness, completeness, accuracy rule을 만들고, 실패하면 누가 무엇을 멈추고 다시 실행할지 문서화한다.

runbook은 학습의 마지막 결과물이다.

개인 프로젝트 로드맵

개인 프로젝트에서는 다음 순서가 실용적이다.

week 1: 주문/결제 운영 table 만들기
week 2: outbox_event table과 relay 흉내 내기
week 3: Spring Scheduler로 일별 summary 만들기
week 4: 실패 이력과 재실행 endpoint 만들기
week 5: Kafka 또는 Redis Stream으로 consumer 붙이기
week 6: 품질 검증 SQL과 장애 runbook 작성하기

플랫폼보다 산출물이 중요하다.

작더라도 event schema, 처리 이력, 검증 SQL, 재처리 절차가 있으면 로드맵이 작동한다.

기업 학습 기준

기업에서는 도구 사용법보다 변경과 장애의 사회적 비용을 함께 배운다.

schema 변경은 consumer와 analyst에게 영향을 준다.

backfill은 warehouse 비용과 운영 DB 부하를 만든다.

quality alert는 dashboard 공개 여부와 의사결정 지연으로 이어진다.

따라서 로드맵에는 협업 문서와 리뷰 체크리스트가 포함되어야 한다.

실전 팁

  • 새 도구를 배우기 전에 어떤 실패 모델을 해결하려는지 적는다.
  • 각 단계마다 작은 코드나 SQL 산출물을 남긴다.
  • event, batch, stream을 별도 주제가 아니라 재처리 가능성으로 연결한다.
  • Web-Database 학습 내용은 운영 DB 경계로 가져오고, 분석 쿼리 튜닝으로 범위를 넓히지 않는다.
  • 마지막에는 장애 대응 문서까지 작성해야 학습이 끝난다.

위험 신호!

  • Kafka, Airflow, Spark 같은 도구 목록이 로드맵의 대부분을 차지한다.
  • event schema를 설명하지 못한 채 consumer 코드부터 작성한다.
  • batch를 성공/실패 로그 없이 cron으로만 등록한다.
  • warehouse table의 grain을 정하지 않고 dashboard부터 만든다.
  • quality rule과 runbook 없이 “파이프라인 구축 완료”라고 말한다.

확인 질문

확인 질문

  • Data Engineering을 Kafka부터 배우면 어떤 위험이 있는가?
    • 데이터 의미, 재처리 기준, idempotency를 모른 채 도구 설정만 익힐 수 있다.
  • 개인 프로젝트에서 로드맵이 작동했는지 확인하는 최소 산출물은 무엇인가?
    • event schema, outbox 또는 event table, 처리 이력, batch 재실행 방법, 품질 검증 SQL, runbook이다.
  • 백엔드 개발자가 warehouse를 배울 때 먼저 정해야 할 것은 무엇인가?
    • 어떤 사건을 어떤 grain의 fact로 만들고, 어떤 dimension으로 해석할지다.

참고 문서

관련 문서