1편 · 약 20분

데이터 플랫폼 운영 모델: source, ingestion, storage, transform, serving

데이터 플랫폼은 파이프라인이 아니라 운영 시스템이다

데이터 플랫폼을 "ETL 파이프라인 모음"으로 보는 시각이 여전히 흔하다. 하지만 그 관점으로 운영하면 곧 한계에 부딪힌다. 소스 시스템이 조용히 스키마를 바꾸고, 파티션 하나가 빠진 채 다음 레이어로 넘어가고, 모든 대시보드가 "3일 전 데이터"를 보여주는데 어디서 막혔는지 아무도 모르는 상황이 생긴다.

데이터 플랫폼은 하나의 운영 시스템이다. 각 레이어에는 소유자, 계약, 장애 정의, 복구 절차가 있어야 한다. 이 장은 source → ingestion → storage → transform → serving 다섯 레이어를 운영자 관점에서 정리한다.

다섯 레이어 개요

Source OLTP DB
SaaS API
이벤트 스트림
파트너 피드

→

Ingestion CDC / Batch
스키마 검증
랜딩존

→

Storage Raw / Bronze
Silver
Gold

→

Transform 정제·조인
비즈니스 로직
집계·파생

→

Serving DW / Mart
BI / API
ML Feature

Cross-cutting: 데이터 품질 · Lineage · 관측성 · 비용 · 보안

데이터 플랫폼 운영 레이어 전체 구조

각 레이어는 독립적으로 장애가 날 수 있고, 독립적으로 모니터링되어야 한다. 레이어가 명확하게 분리되지 않으면 문제가 어디서 왔는지 파악하는 데 불필요한 시간을 쓴다.

1. Source: 소스 시스템을 이해하는 것부터 시작된다

소스 시스템은 데이터 플랫폼이 통제할 수 없는 영역이다. OLTP 데이터베이스, SaaS 애플리케이션, 파트너사 API, IoT 장치, 이벤트 스트림이 여기에 해당한다. 소스는 자신의 일정에 따라 스키마를 바꾸고, API 명세를 변경하고, 배치 내보내기를 재구성한다.

운영자가 소스에 대해 문서화해야 할 항목은 다음과 같다.

항목	설명
소스 유형	OLTP DB, SaaS, 이벤트, 파일, API
소유자	소스 시스템의 팀과 연락처
변경 통지 경로	스키마 변경 시 누가 어떻게 알림을 주는가
내보내기 방식	CDC, 전체 덤프, 증분 쿼리, Webhook
내보내기 주기	실시간, 5분, 1시간, 일 1회
예상 볼륨	일 행 수, 파일 크기, 증가율
스키마 안정성	얼마나 자주 바뀌는가, 하위 호환 여부

소스 시스템과의 관계는 암묵적 계약에서 명시적 계약으로 바꾸는 것이 목표다. 소스 팀이 스키마를 바꾸기 전에 데이터 플랫폼 팀에게 알려야 한다는 약속, 중단 없이 하위 호환 변경만 할 수 있다는 규칙이 없으면 ingestion 레이어는 항상 뒤처지게 된다.

2. Ingestion: 경계에서 품질을 잡아야 한다

Ingestion은 소스 데이터를 플랫폼 안으로 가져오는 레이어다. 여기서 잡지 못한 문제는 downstream으로 전파되면서 수정 비용이 기하급수로 커진다.

수집 패턴

패턴	특징	대표 도구
Full load	전체 테이블을 매번 가져옴. 단순하지만 대용량에 비효율	mysqldump, SELECT *
Incremental	변경된 행만 가져옴. updated_at 또는 id 기반	Spark, Airbyte
CDC (Change Data Capture)	DB binlog/WAL을 읽어 변경 이벤트 스트림 생성	Debezium, Maxwell
Event streaming	애플리케이션이 직접 이벤트 발행	Kafka, Kinesis
API polling	REST/GraphQL API를 주기적으로 호출	Airbyte, Fivetran

Ingestion 레이어의 운영 체크포인트

스키마 검증: 소스에서 들어온 데이터의 스키마가 기대와 맞는지 확인한다. 필드가 사라지거나 타입이 바뀌면 즉시 알려야 한다. 조용히 통과하면 downstream 쿼리가 NULL을 채우거나 타입 캐스팅 오류를 낸다.

완전성(completeness) 검사: 오늘 들어온 행 수가 기대 범위 안인지 확인한다. 소스 시스템 장애나 내보내기 로직 버그는 "데이터가 없음"이 아니라 "데이터가 줄어듦"으로 나타나는 경우가 많다.

신선도(freshness) 검사: 마지막으로 데이터가 갱신된 시점이 SLA 안인지 확인한다. 배치가 실패하거나 CDC 커넥터가 멈추면 데이터가 조용히 낡아간다.

랜딩존(landing zone): ingestion된 원본 데이터를 raw 형태로 보관한다. 나중에 재처리하거나 문제를 디버깅할 때 소스를 다시 붙잡을 필요 없이 이 원본을 사용할 수 있다.

멱등성(idempotency): 같은 ingestion 잡을 여러 번 실행해도 결과가 달라지지 않아야 한다. 재시도와 backfill이 데이터 중복을 만들면 안 된다. 파티션 단위로 덮어쓰거나, MERGE/UPSERT를 사용하거나, dedup 키를 관리하는 방법 중 하나를 선택해 명확히 문서화해야 한다.

ingestion 레이어의 SLA 예시
- 배치 소스: 매 시간 15분 이내 랜딩존 도착
- CDC 소스: 소스 커밋 후 5분 이내 스트림 도착
- 완전성: 기대 행 수 ±20% 이탈 시 알림
- 스키마 위반: 0건 (즉시 실패 처리, downstream 차단)

3. Storage: 레이어를 나눠야 운영이 쉬워진다

스토리지 레이어는 데이터를 어디에, 어떤 형태로 보관하는지 정의한다. 현대적인 데이터 플랫폼은 목적별로 레이어를 나눠 각각의 SLA와 품질 기준을 다르게 가져간다.

Medallion 아키텍처

레이어	별칭	내용	변경 가능 여부
Raw / Landing	Bronze	ingestion된 원본 그대로	불변 (append-only)
Cleansed	Silver	타입 변환, 중복 제거, 기본 품질 검증 완료	덮어쓰기 가능
Aggregated / Mart	Gold	비즈니스 로직 적용, 집계, serving 준비	재계산으로 덮어쓰기

Raw 레이어를 불변으로 유지하는 이유는 재처리 안전망을 확보하기 위해서다. Silver나 Gold에 버그가 있어도 Raw가 있으면 소스 시스템을 다시 붙잡지 않고 재처리할 수 있다.

스토리지 운영 체크포인트

파티션 전략: 날짜 기준 파티션은 ingestion과 쿼리 모두에 유리하다. 너무 잘게 나누면 small file 문제가 생기고, 너무 크면 파티션 pruning 효과가 줄어든다.
파일 포맷: Parquet, ORC 같은 컬럼형 포맷은 분석 쿼리 성능이 좋다. 스키마 진화(schema evolution)를 지원하는지 확인한다.
보존 정책: Raw는 규정 준수에 맞게, Silver/Gold는 비즈니스 SLA에 맞게 보존 기간을 정한다. 오래된 파티션은 저렴한 cold storage로 티어를 내린다.
컴팩션: 스트리밍 ingestion은 작은 파일을 많이 만든다. 주기적인 컴팩션이 없으면 쿼리 성능과 메타데이터 관리 비용이 올라간다.

4. Transform: 재현 가능한 변환이 신뢰를 만든다

Transform 레이어는 원본 데이터에 비즈니스 로직을 적용해 의미 있는 테이블과 지표를 만드는 곳이다. dbt, Spark, SQL 엔진 등이 여기에 해당한다.

변환 레이어의 운영 원칙

선언형 + 버전 관리: 변환 로직은 코드로 관리된다. SQL 파일, dbt 모델, PySpark 잡은 Git에 커밋되고, 리뷰를 거쳐 배포된다. "누가 언제 무엇을 바꿨는가"를 추적할 수 없는 데이터는 신뢰할 수 없다.

재현 가능성: 같은 입력에 같은 변환 로직을 적용하면 항상 같은 출력이 나와야 한다. 현재 시간(NOW()), 외부 API 호출, 비결정적 함수는 재현성을 깨뜨린다.

점진적 처리(incremental): 매번 전체를 다시 처리하는 것은 비용과 시간이 크다. 새로 들어온 파티션만 처리하고 append하는 방식이 기본이다. 단, 재처리(backfill) 시에는 전체 계산이 가능해야 한다.

의존성 체인: A → B → C 순서로 테이블이 의존할 때, A가 늦으면 B와 C도 늦는다. 오케스트레이터(Airflow 등)에서 upstream SLA miss를 감지하고 downstream을 대기시키거나 알림을 보내야 한다.

변환 레이어의 장애 패턴

증상	원인	대응
특정 날짜 파티션 값이 비어 있음	upstream 데이터 지연 / ingestion 실패	upstream 상태 확인 후 재실행
집계 수치가 전날 대비 급변	소스 스키마 변경 / 로직 버그	lineage 추적 → 변경 이력 확인
잡이 과거보다 현저히 느려짐	데이터 볼륨 증가 / 리소스 경합 / 파티션 skew	실행계획 분석, 파티션 재조정
backfill 결과가 정기 실행과 다름	비결정적 로직 / 외부 의존성	재현성 점검, 로직 수정

5. Serving: 소비자가 기대하는 형태로 제공된다

Serving 레이어는 변환된 데이터를 최종 소비자에게 전달한다. BI 도구, 분석 쿼리, 애플리케이션 API, ML 피처 스토어가 여기에 해당한다.

Serving 패턴

소비 형태	인터페이스	특징
대화형 분석	BI 대시보드 (Tableau, Redash 등)	읽기 전용, 집계 테이블
자가 서비스 쿼리	데이터 웨어하우스 (BigQuery, Snowflake, ClickHouse)	SQL, 권한 제어
애플리케이션	REST API / GraphQL	낮은 레이턴시, 캐시 중요
ML	피처 스토어 (Feast 등)	시점 일관성, 온라인/오프라인 일치
스트리밍	Kafka 토픽 재발행	실시간 소비

Serving 레이어의 운영 체크포인트

신선도 SLA: "이 대시보드는 언제까지 갱신되어야 하는가"를 명시한다. BI 도구가 오래된 데이터를 보여주면 사용자는 데이터를 신뢰하지 않게 된다.

쿼리 비용 통제: 자가 서비스 쿼리 환경에서는 비효율적인 쿼리 하나가 전체 클러스터 비용을 크게 올릴 수 있다. 쿼리 타임아웃, 슬롯 제한, 비용 경고를 설정한다.

소비자 영향도 분석: serving 테이블의 스키마나 파티션 구조를 바꾸면 downstream 소비자가 깨진다. 변경 전에 누가 이 테이블을 쓰는지 lineage로 파악해야 한다.

Cross-cutting 관심사: 레이어를 관통하는 것들

데이터 플랫폼의 신뢰성은 각 레이어보다 레이어를 관통하는 세 가지에서 결정된다.

관측성(Observability)

각 레이어에서 발행하는 SLI:

Ingestion: 도착 지연, 행 수 편차, 스키마 위반 건수
Storage: 파티션 completeness, 파일 크기, 컴팩션 backlog
Transform: 잡 실행 시간, 실패율, upstream 지연 전파
Serving: 쿼리 응답 시간, 캐시 적중률, SLA miss 빈도

경고는 소비자가 이상을 발견하기 전에 발생해야 한다. "대시보드가 이상하다"는 티켓을 받고 나서 조사하는 것은 이미 SLA를 놓친 것이다.

Lineage

Column-level lineage가 있으면 소스 필드가 어떤 변환을 거쳐 어떤 serving 테이블로 흘러갔는지 추적할 수 있다. 이는 영향도 분석(impact analysis)의 기반이다. "이 소스 필드가 바뀌면 어떤 대시보드가 깨지는가?"라는 질문에 즉시 답할 수 있어야 한다.

비용

레이어별로 비용을 측정한다. 어떤 파이프라인이 클러스터 비용의 몇 %를 차지하는지, 어떤 소비자가 쿼리 비용의 가장 큰 비중을 차지하는지 파악하지 못하면 비용 최적화는 추측에 의존하게 된다.

운영 모델 요약

레이어 핵심 운영 지표 장애 정의 대응 소유자

Source 변경 통보 여부 스키마 무통보 변경 소스 시스템 팀

Ingestion 도착 지연, 완전성 SLA 초과, 스키마 위반 데이터 엔지니어

Storage 파티션 completeness 누락 파티션, 비용 폭증 데이터 엔지니어

Transform 잡 성공률, 지연 잡 실패, SLA miss 데이터 엔지니어

Serving 신선도, 쿼리 지연 신선도 SLA 위반 데이터 엔지니어 + 소비자 팀

레이어별 운영 책임 매트릭스

실전 체크리스트

새로운 데이터 소스를 플랫폼에 연결할 때

[ ] 소스 소유자와 변경 통지 경로가 합의되어 있는가?
[ ] ingestion 패턴(CDC/배치/API)이 결정되어 있는가?
[ ] 스키마 검증 규칙이 정의되어 있는가?
[ ] 완전성과 신선도 SLA가 숫자로 정해져 있는가?
[ ] raw 레이어에 원본이 보관되는가?
[ ] 멱등성이 보장되는 재처리 방법이 있는가?
[ ] 소비자(serving 레이어)까지의 lineage 추적이 가능한가?
[ ] 장애 시 알림이 오고, 런북이 있는가?

파이프라인 장애 중 확인할 것

어느 레이어에서 문제가 시작됐는가? (ingestion? transform? serving?)
소스 시스템 자체의 문제인가, 플랫폼 내부 문제인가?
해당 파티션의 데이터는 raw에 있는가?
downstream 소비자에게 영향이 가고 있는가?
재처리하면 중복이 생기지 않는가?
수동 개입 없이 자동 복구가 가능한가?

기억할 문장

데이터 플랫폼은 계층이 깊어질수록 문제의 수정 비용이 올라간다. Source에서 잡으면 알림 하나로 끝나고, Serving에서 발견되면 소비자가 내린 의사결정까지 재검토해야 한다. 운영자의 가치는 문제가 나기 전에 경계를 설정하고, 문제가 났을 때 레이어를 빠르게 분리해서 원인을 찾는 능력에 있다.

다음 장에서는 소스와 플랫폼 사이의 암묵적 계약을 명시적으로 만드는 데이터 계약(Data Contract)을 다룬다.

References

Databricks, What is DataOps — https://www.databricks.com/blog/what-is-dataops
Unstructured.io, Ensuring Data Quality at the Ingestion Stage — https://unstructured.io/insights/data-quality-at-ingestion-a-framework-for-ai-ready-pipelines
Medium, Modern Data Architecture in Practice: From Ingestion to Insights — https://medium.com/@roop11lucky/modern-data-architecture-in-practice-from-ingestion-to-insights-c2da871e10e3
Medium, Data Ingestion, Processing and Big Data Architecture Layers — https://medium.com/digital-transformation-and-platform-engineering/data-ingestion-processing-and-big-data-architecture-layers-3cb4988c07de
Monte Carlo, What is Data Orchestration — https://montecarlo.ai/blog-what-is-data-orchestration/