배치 먼저, 실시간 나중: 안전한 데이터 인프라 구축 순서

요약

• 실시간 처리는 단일 데이터 레이크, 카탈로그, 품질 규칙 위에서만 안정적으로 유지된다.
  1. 먼저 배치 파이프라인으로 이 공통 기반을 구축
  2. 그 위에 실시간 스트림을 얹는 방식이 가장 안전하고 경제적

왜 배치 기반을 먼저 다진 뒤 실시간으로 확장할까?

1. Canonical Schema, 저장소 선점

• Iceberg, Delta 같은 레이크 테이블을 배치로 먼저 정의해 스키마, 파티션, 품질 규칙을 확정한다.
• 이후 스트리밍 계층은 같은 테이블을 sink로 삼아 증분 데이터를 적재하면 된다.
• 이 기반이 없으면 실시간 데이터를 어디, 어떻게 저장할지 다시 설계해야 한다.

2. Backfill, 리플레이 대비

• 실시간 파이프라인은 장애나 지연이 발생할 수 있다.
• 배치 인프라가 있으면 과거 데이터를 한 번에 채우거나 스트림을 재생해 정합성을 복구하기 쉽다.

3. 데이터 품질, Compliance 준비

• 금융과 커머스는 감사, 품질 규제가 엄격하다.
• 배치 단계에서 Great Expectations, dbt tests 등으로 품질 규칙을 코드화해 두면
  스트림에서도 Deequ, Flink UDF로 동일 규칙을 재사용할 수 있다.

4. 학습 곡선 & 비용 관리

항목	배치(Spark + Airflow)	실시간(Kafka + Flink)
학습 난이도	익숙한 스택	새 도구, 운영 지식 필요
비용 구조	필요 시 클러스터 가동 → 탄력 비용	24×7 상시 가동 → 고정 비용
운영 복잡도	단순(Cron DAG)	토픽 관리, 윈도, 체크포인트 등 추가

5. 비즈니스 스토리텔링 효과

1. 배치로 핵심 KPI와 인사이트를 빠르게 확보한다.
2. 실시간화로 의사결정 지연을 단축해 업그레이드 과정을 보여준다.
3. 단계별 성과를 제시해 포트폴리오와 사내 발표에서 ROI 향상을 강조할 수 있다.

용어 정리

Term	의미
Backfill	누락, 오류 구간을 배치로 한꺼번에 재적재하는 작업. ex) 5월 1–3일 누락 로그 재적재
Canonical Schema	조직 전체에서 정본(골든)으로 삼는 표준 데이터 모델. 테이블, 필드, 데이터 타입, 명명 규칙을 통일해 배치, 스트림 파이프라인 모두 같은 스키마를 사용. 데이터 불일치와 매핑 비용을 줄여 준다.
Catalog	레이크하우스, 웨어하우스에서 테이블 이름 ↔ 메타데이터 루트 경로를 원자적으로 매핑, 관리. 쿼리 엔진과 파이프라인이 동일한 테이블 목록, 권한, 스키마를 공유. ex) Hive Metastore, AWS Glue, Unity Catalog
Compliance	법, 규제, 사내 정책을 준수하도록 데이터 품질, 접근 권한, 변경 이력을 관리. ex) GDPR, PCI-DSS
Cron	Unix, Linux에서 시간 기반 작업을 실행하는 스케줄러. ex) 0 1 * * * — 매일 01:00 ETL 실행
Replay	스트림에서 특정 구간의 이벤트를 다시 재생해 상태를 복구. ex) Kafka 오프셋 되돌리기
Snapshot	테이블의 특정 시점을 나타내는 불변 메타데이터 레코드. 스냅숏 ID, 타임스탬프, 참조 파일 목록, 부모 스냅숏 ID를 포함. Time-Travel, Rollback, 증분 읽기에 활용. ex) Iceberg snapshot 12345678-...
Table Metadata	단일 테이블의 변경 이력, 버전 정보 모음. Iceberg, Delta 등은 테이블 폴더에 metadata/*.json을 기록. 스냅숏, 스키마 진화, 파티션 통계, Time-Travel을 지원. ex) Iceberg metadata/00000-abc.json