이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- 개인 프로젝트에서 데이터 파이프라인을 어디까지 단순화해도 되는가?
- 기업 운영에서 owner, SLA, 알림, 감사가 필요한 이유는 무엇인가?
- 같은 batch와 event 설계가 규모에 따라 어떻게 달라지는가?
- 과한 도구 도입과 부족한 운영 흔적을 어떻게 구분하는가?
개요
개인 프로젝트와 기업 데이터 운영의 차이는 도구 이름보다 책임 범위에 있다.
개인 프로젝트에서는 하나의 DB, 하나의 scheduler, 수동 재실행으로도 충분할 수 있다.
기업 운영에서는 같은 구조라도 owner, SLA, 알림, 권한, 감사, 변경 절차가 필요하다.
데이터 파이프라인은 실패했을 때 다른 사람이 원인을 찾고 안전하게 다시 실행할 수 있어야 운영 수준이 된다.
원리
작은 프로젝트에서는 복잡도를 줄인다.
큰 조직에서는 불확실성을 줄인다.
이 두 기준을 섞으면 작은 프로젝트에는 불필요한 플랫폼이 생기고, 기업 서비스에는 장애 때 아무도 믿을 수 없는 수동 스크립트가 남는다.
핵심 질문은 다음과 같다.
- 장애를 누가 발견하는가?
- 누가 재실행할 권한을 가지는가?
- 재실행하면 어떤 데이터가 바뀌는가?
- 소비자는 지연과 보정을 어느 정도 허용하는가?
- 변경 이력을 누가 설명할 수 있는가?
수준 비교
| 항목 | 개인 프로젝트 | 기업 운영 |
|---|---|---|
| 실행 | Spring Scheduler, cron | Airflow, managed scheduler, runbook |
| 상태 기록 | job_history table | 중앙 job metadata, audit log |
| 알림 | 실패 로그 확인 | Slack/PagerDuty, severity |
| 재처리 | 날짜 범위 수동 실행 | 승인된 backfill 절차 |
| 품질 검증 | count, 최신 시각 | freshness, completeness, accuracy rule |
| 권한 | 개발자 직접 실행 | 역할 기반 권한, 승인 |
| 문서 | README | owner, SLA, dependency, rollback |
비교의 목적은 기업 방식을 그대로 흉내 내는 것이 아니다.
작게 시작하더라도 나중에 커질 수 있는 흔적을 남기는 것이다.
개인 프로젝트 예시
CREATE TABLE job_run_history (
job_run_id bigserial PRIMARY KEY,
job_name varchar(100) NOT NULL,
target_date date NOT NULL,
status varchar(20) NOT NULL,
started_at timestamp NOT NULL,
finished_at timestamp NULL,
processed_count bigint DEFAULT 0,
error_message text NULL
);이 정도 table만 있어도 “어제 job이 돌았는가”, “몇 건 처리했는가”, “실패했으면 왜 실패했는가”를 남길 수 있다.
Kafka나 Airflow가 없어도 운영 사고를 설명하는 연습이 된다.
기업 운영 예시
pipeline: order_daily_mart
owner: data-platform
service-owner: order-service
sla: D+1 08:00 KST
alert: #data-alerts, P2 after 30m delay
source: orders, payments, refunds
target: mart.order_daily
rerun-permission: data-platform oncall
quality-gates:
- source_count_match
- paid_amount_sum_match
- freshness_under_90m기업 운영 문서는 장애 때 읽히는 문서다.
문서에 owner와 SLA가 없으면 알림이 울려도 누구의 문제인지 결정하지 못한다.
판단 축
- 혼자 운영하면 자동화보다 단순한 재실행 가능성을 먼저 둔다.
- 여러 팀이 소비하면 owner와 계약을 먼저 둔다.
- 장애 영향이 사용자 화면으로 번지면 알림과 severity를 둔다.
- 돈, 정산, 규제 데이터면 감사 로그와 승인 절차를 둔다.
- 반복 재처리가 잦으면 수동 SQL이 아니라 runbook과 job parameter로 바꾼다.
실패 모델
- 개인 프로젝트에서 Kafka, Airflow, warehouse를 붙였지만 실패 로그가 없다.
- 기업 서비스에서 batch를 개발자 노트북 SQL로 재실행한다.
- 알림은 오지만 target table, 처리 범위, 영향 서비스를 알 수 없다.
- 데이터 팀은 mart를 고쳤지만 백엔드 팀은 event schema 변경을 모른다.
- 재처리 권한이 넓어 운영 데이터가 조용히 덮어써진다.
운영 지표
job_success_rate: 반복 실행이 안정적인지 본다.mean_time_to_detect: 실패를 발견하는 데 걸린 시간이다.mean_time_to_recover: 재처리 또는 보정 완료까지 걸린 시간이다.manual_rerun_count: 자동화가 필요한 반복 수동 작업의 신호다.quality_gate_block_count: 품질 검증이 실제 배포나 공개를 막은 횟수다.unaudited_change_count: 승인 없이 target data가 바뀐 횟수다.
데이터 품질 수준
개인 프로젝트에서는 다음 세 가지만으로 시작해도 된다.
- source count와 target count 비교
- target 최신 시각 확인
- 핵심 금액 합계 비교
기업 운영에서는 품질 rule을 배포와 분리하지 않는다.
mart build가 성공해도 품질 rule이 실패하면 dashboard 공개를 막거나 stale 표시를 해야 한다.
협업 기준
개인 프로젝트에서는 모든 맥락이 한 사람 머릿속에 있어도 굴러갈 수 있다.
기업 운영에서는 다음 정보가 문서에 있어야 한다.
- producer service와 owner
- consumer와 downstream owner
- schema 변경 연락 방식
- 재처리 요청 템플릿
- 장애 등급과 알림 채널
- 보관 기간과 삭제 정책
실전 팁
- 개인 프로젝트라도
job_run_id와target_date는 남긴다. - 처음부터 운영 플랫폼을 붙이기보다 실패를 재현하고 재실행하는 절차를 만든다.
- 기업 환경에서는 “누가 봐도 다시 실행할 수 있는가”를 리뷰 기준으로 둔다.
- 데이터가 돈이나 계약과 연결되면 수동 수정 권한을 좁힌다.
- 문서에는 정상 흐름보다 실패 후 판단 순서를 더 자세히 남긴다.
위험 신호!
- 개인 프로젝트가 도구 설치 기록만 있고 데이터 처리 이력이 없다.
- 기업 batch가 특정 개발자 계정과 로컬 파일에 의존한다.
- 재실행하면 어떤 기간이 덮어써지는지 아무도 모른다.
- 품질 검증 실패가 알림으로만 오고 공개 차단은 되지 않는다.
- 장애 회고에 재처리 범위와 검증 SQL이 남지 않는다.
확인 질문
확인 질문
- 개인 프로젝트에서 최소한 남겨야 하는 운영 흔적은 무엇인가?
- job 실행 이력, 대상 범위, 처리 건수, 실패 메시지, 수동 재실행 방법이다.
- 기업 운영에서 owner와 SLA가 없으면 어떤 문제가 생기는가?
- 알림이 발생해도 책임 팀, 영향 범위, 복구 우선순위를 결정하기 어렵다.
- 과한 도구 도입과 필요한 운영 준비를 구분하는 기준은 무엇인가?
- 도구 수가 아니라 실패 발견, 영향 파악, 안전한 재처리가 가능한지로 판단한다.
참고 문서
- Spring Batch Reference
- Apache Airflow Documentation
- Google SRE Book, Monitoring Distributed Systems
- Martin Kleppmann, Designing Data-Intensive Applications