Data Engineering 전체 지도

Data Engineering 전체 지도 챕터는 서비스 데이터가 API 트랜잭션에서 끝나지 않고 이벤트, 배치, 스트림, warehouse, 품질 검증으로 이어지는 전체 경로를 잡는다.
목표는 데이터 도구 사용법이 아니라 데이터가 이동하면서 생기는 지연, 중복, 누락, 품질 문제를 판단하는 능력이다.
Java/Spring 백엔드 개발자는 API transaction, event, batch, stream, pipeline, quality rule을 하나의 운영 흐름으로 설명할 수 있어야 한다.

서비스 데이터 흐름 전체 지도: API commit 이후에도 데이터는 이벤트 발행, 비동기 소비, batch 보정, warehouse 적재, 품질 검증을 거쳐 서비스 가치로 바뀐다.
Transactional Data Event Analytical Data: transactional data는 현재 업무 상태, event data는 발생한 사건, analytical data는 의사결정용 파생 모델이라는 점을 구분한다.
Batch Stream Pipeline 구성 요소: batch는 묶음 단위의 재계산, stream은 지속적인 event 처리, pipeline은 이 둘을 의존성과 저장소로 연결한 실행 흐름이다.
개인 프로젝트와 기업 데이터 운영 수준 비교: 개인 프로젝트는 단순한 처리 이력과 수동 재실행으로 시작하고, 기업 운영은 owner, SLA, 알림, 권한, 감사까지 갖춘다.
Data Engineering 학습 로드맵: 운영 DB 이해에서 event, batch, stream, warehouse, quality, runbook 순서로 학습하면 백엔드 개발자가 실전 판단을 잃지 않는다.
이 챕터의 모든 문서는 Web-Database의 OLTP 판단을 넘어, 데이터 이동과 재처리 가능성을 중심으로 읽어야 한다.

도구를 도입하면 데이터 신뢰성이 자동으로 생긴다고 보기 쉽다. 실제 신뢰성은 key, schema, checkpoint, idempotency, 품질 검증에서 나온다.
- Kafka, Airflow, Redis를 쓰더라도 재처리할 수 없으면 운영 가능한 파이프라인이 아니다.
- 작은 프로젝트에서는 단순한 DB table과 scheduler만으로도 핵심 경계를 연습할 수 있다.
운영 DB의 현재 상태와 분석용 파생 데이터를 같은 것으로 보기 쉽다.
- OLTP는 현재 transaction 정합성이 중요하고, 분석 흐름은 지연 허용치와 재계산 가능성이 중요하다.
- 이 차이를 설명하지 못하면 리포트 지연과 API 장애를 같은 언어로 처리하게 된다.
비동기 처리는 실패를 없애는 방법이라고 오해하기 쉽다.
- 비동기는 실패 위치를 뒤로 옮기는 것이다.
- 그래서 DLQ, retry, checkpoint, backfill, quality alert가 함께 필요하다.

이 챕터의 핵심 판단 기준은 무엇인가?
- 데이터가 어디서 생성되고 어디로 이동하며, 실패했을 때 어느 key와 checkpoint로 다시 처리할 수 있는지다.
Web-Database와의 경계는 무엇인가?
- Web-Database는 운영 DB transaction과 query 중심이고, 이 챕터는 운영 데이터가 이벤트, batch, stream, warehouse, mart로 이동하는 신뢰성 중심이다.
개인 프로젝트에서 최소로 챙길 것은 무엇인가?
- 처리 이력, 실패 로그, 작은 batch 범위, 멱등 key, 재실행 방법, 검증 SQL이다.

동블