[Data Observability] Day 5: 데이터 가용성(SLO/SLA) 정의 - 데이터 팀의 성과를 수치화하는 법

서론: 장애 건수보다 서비스 수준을 관리하라

데이터 팀 성과를 “파이프라인이 몇 번 실패했는가”로만 보면 개선이 어렵다. 중요한 것은 비즈니스가 체감하는 서비스 수준이다.

그래서 필요한 것이 데이터 SLO/SLA다.

• SLA(Service Level Agreement): 대외/대내 약속
• SLO(Service Level Objective): 내부 목표치
• SLI(Service Level Indicator): 측정 지표

1. 데이터 SLI 설계

관측 메트릭을 그대로 성과 지표로 쓰면 안 된다. 소비자 관점으로 번역해야 한다.

대표 SLI:

1. Freshness SLI: 데이터 최신성 보장 시간
2. Completeness SLI: 기대 레코드 대비 적재 비율
3. Accuracy SLI: 기준 데이터와의 불일치율
4. Availability SLI: 데이터셋 조회 가능 비율

예시:

Freshness SLI = (정시 도착한 배치 수) / (전체 배치 수)

2. SLO 목표값 정하기

SLO는 “야심찬 숫자”가 아니라 “운영 가능한 숫자”여야 한다.

예시:

• 등급 A 대시보드: Freshness 99.9% (15분 이내)
• 등급 B 분석 테이블: Freshness 99.0% (2시간 이내)
• 학습용 피처셋: Completeness 99.5%

모든 자산에 동일한 목표를 적용하면 비용만 급증한다. 데이터 자산을 티어로 구분해야 한다.

3. Error Budget 도입

SLO의 핵심은 Error Budget이다.

Error Budget = 1 - SLO

예:

• SLO 99.9%면 월간 허용 실패는 0.1%

활용:

• 예산 소진 전: 기능 개선/배포 지속
• 예산 초과 후: 신규 기능보다 안정화 우선

이 규칙이 있어야 “신규 개발 vs 신뢰성 개선” 우선순위 논쟁이 줄어든다.

4. SLA 문서화의 실무 포인트

SLA 문서는 길게 쓰기보다 운영에 필요한 최소 항목을 명확히 넣는 것이 중요하다.

필수 항목:

1. 대상 데이터셋/리포트
2. 보장 지표(SLI)와 계산식
3. 목표값(SLO)과 측정 주기
4. 위반 시 에스컬레이션/커뮤니케이션 절차
5. 제외 조건(예정된 점검, 상위 시스템 장애 등)

5. SLO 대시보드 예시

데이터 팀 관점에서 최소 다음 4개를 상시 본다.

• SLO 달성률(자산별/도메인별)
• Error Budget 잔량
• 상위 위반 원인(지연, 스키마, 파이프라인 실패)
• MTTR 추세

중요한 점은 “빨간색 개수”가 아니라 “예산 소모 속도”다.

6. 조직 운영 모델과 연결

SLO 체계가 작동하려면 책임 경계가 분명해야 한다.

• Platform Team: 공통 인프라, 관측 도구, 표준 정책
• Domain Team: 데이터 계약, 품질 규칙, 우선순위 결정
• Data Consumer: 중요도 티어 지정, 변경 사전 통지

이 세 역할이 분리되지 않으면 SLO는 대시보드 숫자로만 남는다.

7. Day 5 체크리스트

1. 핵심 데이터 자산을 티어(A/B/C)로 분류한다.
2. 티어별 SLI/SLO를 2~3개로 제한해 시작한다.
3. 월간 Error Budget 정책을 릴리즈 의사결정과 연결한다.
4. SLA 위반 시 커뮤니케이션 템플릿을 사전에 합의한다.

시리즈 마무리

이번 시리즈는 Data Observability를 “로그 모니터링”이 아니라 “데이터 서비스 신뢰성 엔지니어링” 관점으로 정리했다.

1. 정적 품질 검증의 한계
2. OpenLineage 기반 리니지 표준화
3. 통계적 이상 탐지 고도화
4. 플랫폼 아키텍처 선택 기준
5. SLO/SLA로 성과를 수치화하는 방법

다음 단계는 팀의 실제 파이프라인 1개를 선정해, 위 다섯 축을 2주 내 PoC로 검증해보는 것이다.