핵심 인사이트

  1. SLM(Service Level Management)은 SLA·OLA·UC 계층으로 이루어진 서비스 수준 보증 체계 — SLA는 고객 대면 계약, OLA는 내부 팀 간 합의, UC는 외부 공급자와의 계약으로, 세 계층이 정합성을 가져야 SLA 이행이 가능하다.
  2. OLA(Operational Level Agreement)가 SLA 이행의 실질적 기반 — 서비스 데스크, 네트워크팀, 서버팀 간 내부 SLA가 없으면 고객 SLA가 깨지는 병목을 어디서도 파악하지 못한다.
  3. SLM 구현의 함정 — 계약서에만 SLA를 명시하고 OLA 합의와 측정 도구를 갖추지 않으면 SLA 위반 시 책임 소재를 찾을 수 없는 "서류상의 SLM"으로 전락한다.

Ⅰ. SLM 계층 구조

SLM (Service Level Management):
  IT 서비스가 합의된 수준으로 제공됨을 보장하는 프로세스
  ITIL v4 핵심 관리 관행

3계층 구조:

고객
  |
  SLA (Service Level Agreement): 고객 ↔ IT 서비스 제공자
  "IT 부서가 고객에게 제공하는 서비스 수준"
  
IT 서비스 제공자 (내부)
  |
  OLA (Operational Level Agreement): 내부 팀 간 합의
  "서비스 데스크 ↔ 네트워크팀 ↔ DB팀"
  
  |
  UC (Underpinning Contract): IT 제공자 ↔ 외부 공급자
  "외부 클라우드, 통신사, 소프트웨어 벤더와의 계약"

SLA 체인 원칙:
  SLA 약속 ≤ OLA 합의 ≤ UC 계약
  
  예:
  SLA: 인시던트 P1 복구 4시간 이내
  OLA: 서버팀이 네트워크팀에 알림 후 30분 내 처리
  UC: 클라우드 제공자 가용성 99.95% 보장
  
  OLA 위반 → SLA 위반 가능성 높음
  UC 위반 → SLA 위반 가능성 높음

📢 섹션 요약 비유: SLM 3계층 = 레스토랑 서비스 체계 — 손님(고객)에게 "30분 내 음식 제공(SLA)" 약속. 주방팀 내 "15분 내 조리(OLA)" 합의. 식재료 공급사와 "당일 납품(UC)" 계약. 모든 계층 지켜야 손님 약속 이행!

Ⅱ. SLA 설계

SLA (Service Level Agreement) 구성요소:

1. 서비스 범위:
  어떤 서비스, 어떤 업무 시간
  "이메일 서비스, 24×7 x 365"
  
2. 서비스 수준 목표:
  가용성 (Availability): 99.9%
  응답 시간 (Response Time): < 200ms (P95)
  인시던트 해결 시간 (Resolution Time): P1 4시간
  
3. 측정 방법:
  측정 도구: Datadog, Prometheus
  측정 주기: 5분 간격 헬스체크
  보고 주기: 월별 SLM 보고서

4. 책임 한계:
  고객 귀책 제외: 고객 측 네트워크 장애
  계획된 다운타임 제외: 사전 공지 유지보수

5. 위반 시 조치:
  SLA Credit:
  가용성 99.9% 미달 시 → 요금 10% 크레딧
  99% 미달 시 → 25% 크레딧
  95% 미달 시 → 50% 크레딧

6. 검토 주기:
  분기별 SLM 검토 미팅
  서비스 변경 시 SLA 재협의

SLA 작성 원칙:
  측정 가능: "빠른 응답" X → "P99 < 500ms" O
  현실적: 현재 성능 기반 + 개선 여유
  균형: 고객 기대 + 제공 가능한 수준

📢 섹션 요약 비유: SLA = 식당 메뉴판 약속 — "30분 내 배달 보장(가용성+응답시간)". 늦으면 다음 주문 할인(SLA Credit). 측정 가능하고 현실적인 약속이 진짜 SLA!

Ⅲ. OLA 설계

OLA (Operational Level Agreement):
  IT 내부 팀 간 서비스 수준 합의
  SLA 이행을 위한 내부 메커니즘

예시: P1 인시던트 대응 OLA:

서비스 데스크:
  P1 탐지 → 5분 내 분류(Triage)
  15분 내 에스컬레이션 결정
  고객 최초 알림: 30분 내

인프라팀:
  서비스 데스크 에스컬레이션 → 15분 내 대응
  초기 진단: 30분 내
  임시 조치(Workaround): 2시간 내

애플리케이션팀:
  코드 관련 장애 에스컬레이션 → 30분 내 대응
  핫픽스 릴리스: 4시간 내

SLA 연결:
  P1 SLA: 4시간 내 복구
  OLA 합: 5+15+30 = 50분 (서비스 데스크) + 2시간(인프라) < 4시간 ✓

OLA 측정:
  ITSM 도구 (ServiceNow, Jira Service Desk)
  인시던트 각 단계 타임스탬프 자동 기록
  
  주간 OLA 위반 리포트:
  어떤 팀이 어떤 단계에서 OLA 초과?

OLA 거버넌스:
  분기별 팀 리뷰
  반복 위반 팀 → 근본 원인 분석 + 개선 계획

📢 섹션 요약 비유: OLA = 식당 내부 배달 타임라인 — 주방(인프라): 15분, 포장(앱팀): 10분, 배달(서비스 데스크): 5분 합계 30분. 외부 약속(SLA) 지키려면 내부 타임라인(OLA) 먼저 정확히!

Ⅳ. SLM 성숙도와 자동화

SLM 성숙도 모델:

레벨 1 - 임시 (Ad-hoc):
  SLA 문서 있지만 측정 없음
  위반 시 인지 불가
  
레벨 2 - 반응적 (Reactive):
  SLA 측정 도구 있음
  위반 발생 후 인지
  월별 보고서

레벨 3 - 사전 예방적 (Proactive):
  실시간 SLA 대시보드
  위반 임박 시 경보
  Burn Rate 모니터링

레벨 4 - 최적화 (Optimized):
  AI 기반 SLA 예측
  자동 스케일링으로 SLA 유지
  SLA 자동 보고

현대 SLM 자동화:

ServiceNow SLM:
  인시던트 자동 SLA 타이머 시작
  OLA 단계별 자동 에스컬레이션
  SLA 위반 자동 크레딧 계산

Prometheus + SLO:
  SLI(Error Rate, Latency) 자동 수집
  SLO 위반 → PagerDuty 자동 알림
  Error Budget 실시간 계산

Datadog SLO Tracking:
  서비스 수준 목표 정의 → 자동 모니터링
  SLA 리포트 자동 생성 → 고객 공유

📢 섹션 요약 비유: SLM 성숙도 = 배달 추적 시스템 발전 — 레벨 1(배달 완료만 확인), 레벨 2(배달 완료 후 늦음 인지), 레벨 3(실시간 GPS 추적 + 30분 초과 경보), 레벨 4(AI 예측으로 최적 경로 자동 선택)!

Ⅴ. 실무 시나리오 — SLM 체계 구축

제조업 IT 부서 SLM 체계 구축:

현황:
  IT 서비스 200개 운영
  SLA: 계약서에만 존재 (측정 없음)
  월 평균 SLA 위반 클레임: 10건
  근거 없는 클레임 분쟁 잦음

목표:
  측정 기반 SLM 체계 구축
  SLA 위반 인시던트 50% 감소

1단계: 서비스 카탈로그 정의
  200개 서비스를 5개 등급으로 분류:
  P1 (Critical): ERP, 생산 시스템 (24×7)
  P2 (High): 그룹웨어, 이메일 (업무 시간)
  P3 (Medium): HR 시스템
  P4 (Low): 사내 포털, 교육 시스템
  P5 (Minimal): 개발 서버

2단계: SLA/OLA 문서화
  P1 SLA: 가용성 99.9%, 복구 4시간
  관련 OLA: 네트워크팀/서버팀/DB팀 각 1시간

3단계: 측정 도구 구축
  ServiceNow: 인시던트 SLA 자동 타이머
  Zabbix + Grafana: 인프라 가용성 자동 측정
  SLA 대시보드: 실시간 가용성 + OLA 위반

4단계: 월별 SLM 검토
  SLA 달성률: 서비스별
  OLA 위반: 팀별
  반복 위반 → 근본 원인 분석

결과 (6개월):
  SLA 측정 자동화: 100% 서비스 커버리지
  SLA 위반: 10건/월 → 3건/월
  OLA 위반 식별: "DB팀이 병목" 발견 → DB 전담 인력 증원
  클레임 분쟁: 데이터 기반 해결 (클레임 80% 감소)

📢 섹션 요약 비유: SLM 체계 구축 = GPS 배달 추적 도입 — "언제 도착하냐"는 분쟁에서 GPS 기록(SLA 측정 도구)으로 해결. 병목(DB팀) 발견해 인력 증원. 클레임 분쟁 80% 감소!

📌 관련 개념 맵

SLM (Service Level Management)
+-- 계층
|   +-- SLA (고객 대면)
|   +-- OLA (내부 팀 간)
|   +-- UC (외부 공급자)
+-- ITIL v4 관련
|   +-- 인시던트 관리
|   +-- 문제 관리
|   +-- 변경 관리
+-- 측정 도구
|   +-- ServiceNow, Jira SM
|   +-- Prometheus + Grafana
+-- 성숙도
    +-- 임시 → 반응적 → 예방적 → 최적화

📈 관련 키워드 및 발전 흐름도

[ITIL v1 (1989)]
영국 정부 IT 관리 표준
SLA 개념 도입
      |
      v
[ITIL v2/v3 (2000~2007)]
SLM 프로세스 체계화
OLA, UC 개념 정립
      |
      v
[클라우드 SLA (2010s~)]
AWS/Azure SLA 표준화
SLO(Site Reliability) 등장
      |
      v
[ITIL v4 (2019)]
가치 스트림 중심
DevOps + SRE 통합
      |
      v
[현재: AI 기반 SLM]
예측 기반 SLA 관리
자동 스케일링으로 SLA 유지

👶 어린이를 위한 3줄 비유 설명

  1. SLA = 식당 약속 — 손님에게 "30분 내 음식 제공". 위반 시 할인권(SLA Credit). 측정 가능해야 진짜 약속!
  2. OLA = 주방 팀 내부 타임라인 — 주방장에서 홀 서빙까지 각 단계 시간 합산이 손님 약속 시간보다 짧아야 해요!
  3. SLM 성숙도 = 배달 추적 진화 — 완료만 확인(레벨1)에서 실시간 GPS+AI 경로 최적화(레벨4)까지. 데이터 없이는 관리 불가!