103. SLA (Service Level Agreement)

핵심 인사이트 (3줄 요약)

본질: SLA (Service Level Agreement, 서비스 수준 협약)는 IT 서비스 제공자(벤더)와 고객 간에 맺어지는 가장 최상위의 비즈니스적, 법적 서비스 품질 보증 계약서이다.

가치: 모호한 형용사를 배제하고 가용성, 응답 시간 등 측정 가능한 수치(지표)를 명문화하여, 서비스 장애 시 책임 소재를 명확히 하고 재정적 패널티(Service Credits) 기준을 제공한다.

판단 포인트: 기술 조직 내부의 엄격한 목표인 SLO (Service Level Objective)보다 항상 더 낮고 여유로운 수치로 SLA를 설정하여, 잦은 재무적 배상(위약금) 리스크로부터 비즈니스를 방어하는 것이 핵심 설계 전략이다.

Ⅰ. 개요 및 필요성

클라우드 컴퓨팅과 IT 아웃소싱이 보편화되면서 인프라의 장애가 곧 고객 기업의 대규모 금전적 손실로 직결되는 시대가 되었다. SLA (Service Level Agreement)는 "우리가 제공하는 시스템이 어느 정도의 품질(Uptime, Latency 등)을 보장할 것인가"를 서면으로 확약하는 공식 문서다.

클라우드 사업자가 "최대한 안정적으로 서버를 운영하겠다"라고 구두로 약속하는 것만으로는 블랙프라이데이 같은 대규모 트래픽 발생 시 벌어지는 시스템 다운타임 피해를 보상받을 수 없다. SLA가 없다면 장애 발생 시 책임 회피와 끝없는 법적 공방이 이어지게 된다. 따라서 SLA는 고객에게는 손실에 대한 재무적 보상망(Safety Net)이 되며, 서비스 제공자에게는 서비스 아키텍처의 가용성 목표를 강제하는 가장 강력한 기준점이 된다.

📢 섹션 요약 비유: SLA는 새로 산 자동차의 **'엔진 무상보증 계약서'**와 같다. "차가 잘 달립니다"라는 딜러의 말이 아니라, "3년 또는 6만 km 이내에 엔진이 고장 나면 100% 무상 교체해 준다"라고 도장이 찍힌 법적 안전장치다.

Ⅱ. 아키텍처 및 핵심 원리

SLA 문서가 법적 효력을 발휘하기 위해서는 형용사가 아닌 컴퓨터 모니터링 시스템으로 100% 추적(Tracking) 및 측정 가능한 명확한 수치(Metric)로 구성되어야 한다.

┌────────────────────────────────────────────────────────────────────────┐
│                   SLA (Service Level Agreement) Core Architecture      │
├────────────────────────────────────────────────────────────────────────┤
│                                                                        │
│ 1. 보증 지표 (Service Metrics)                                          │
│    - 가용성 (Availability): 월간 서버 정상 접속 가능 시간 (예: 99.9%)          │
│    - 응답 시간 (Latency): API 호출 시 2초 이내 응답 보장                    │
│    - 복구 시간 (MTTR): 장애 인지 후 서비스 정상화까지 걸리는 한계 시간          │
│                                                                        │
│ 2. 예외 조항 (Exclusions)                                               │
│    - 천재지변(지진), 사전 공지된 정기 점검, 고객측 코드 버그로 인한 장애는 무효!   │
│                                                                        │
│ 3. 재무적 패널티 (Financial Penalty / Service Credits)                  │
│    [ 가용성 구간 ]        [ 보상 크레딧 (다음 달 요금 할인율) ]            │
│    99.9% 이상          ▶  정상 (패널티 없음)                              │
│    99.0% ~ 99.9% 미만  ▶  10% 환불                                      │
│    95.0% ~ 99.0% 미만  ▶  30% 환불                                      │
│    95.0% 미만          ▶  100% 전액 환불                                │
└────────────────────────────────────────────────────────────────────────┘

이 구조에서 가장 핵심적인 원리는 **서비스 크레딧(Service Credits)**이라는 재무적 패널티 조항이다. SLA는 제공자가 목표를 미달했을 때 단순히 사과하는 것이 아니라, 다음 달 청구 요금에서 명시된 비율만큼의 금액을 강제로 할인해 주는 구조로 작동한다. 이 배상금(크레딧)은 벤더의 수익률을 직접 타격하므로 SRE (Site Reliability Engineering) 팀이 인프라에 투자해야 할 가장 강력한 동기부여가 된다.

📢 섹션 요약 비유: SLA 구조는 **'피자 30분 배달 보증제'**와 완벽히 똑같다. "최대한 빨리 갈게요(추상적)"가 아니라, "30분(보증 지표)이 넘으면, 눈비가 오지 않는 한(예외 조항), 피자값을 안 받겠습니다(패널티 크레딧)"라고 명확한 숫자와 보상액을 걸어두는 것이다.

Ⅲ. 비교 및 연결

SRE 생태계에서 SLA는 SLI, SLO와 반드시 트리오(Trio)로 연결되어 시스템 관제의 거대한 방어선을 형성한다. 이 세 가지의 경계를 정확히 구분해야 한다.

지표 명칭	약어 전체 명칭	역할 및 성격	수치 예시	비유
SLI	Service Level Indicator (수준 지표)	시스템 상태를 초 단위로 읽어내는 현재의 실제 관측치	가동률 `99.95%`	현재 자동차 계기판 속도 (110km/h)
SLO	Service Level Objective (수준 목표)	엔지니어링 팀 내부에서 쫀쫀하게 합의한 자체 목표치	가동률 `99.90%`	과속 안 하겠다는 나의 굳은 다짐 (100km/h)
SLA	Service Level Agreement (수준 협약)	고객과 맺은 법적인 외부 계약으로, 위약금 발생의 마지노선	가동률 `99.50%`	경찰의 과속 단속 카메라 벌금 기준 (120km/h)

핵심은 SLA 수치가 항상 SLO 수치보다 낮고 여유로워야 한다는 점이다. 내부 목표인 SLO(99.9%)가 깨지더라도 아직 고객과 계약한 SLA(99.5%)까지는 버퍼가 남아 있으므로 당장 위약금을 물지 않는다. 즉, SLO 위반은 엔지니어들이 코드 배포를 멈추고 시스템을 정비하게 만드는 내부 알람 역할을 하고, SLA는 회사의 재무팀이 출동하게 만드는 최종 파멸의 경계선 역할을 분담한다.

📢 섹션 요약 비유: 이 3단계 구조는 **'시험 성적 방어망'**과 같다. 내 실제 모의고사 점수(SLI)가 85점일 때, 내 마음속 1등급 목표(SLO)인 90점에는 못 미쳐서 우울하지만, 부모님과 약속한 용돈 삭감 컷트라인(SLA)인 70점까지는 한참 남았으므로 당장 주머니가 털리지는 않는 안전거리 확보 전략이다.

Ⅳ. 실무 적용 및 기술사 판단

클라우드 아키텍처 설계와 B2B 외주 계약 체결 시 기술사가 조율해야 할 실무적 판단 기준이다.

체크리스트 및 판단 기준

SLA 합산(Composite SLA) 아키텍처 함정 판단: 마이크로서비스(MSA) 시스템에서 AWS의 EC2 (SLA 99.9%)와 RDS 데이터베이스 (SLA 99.9%)를 동시에 거쳐야만 고객 응답이 나간다면, 이 시스템의 전체 SLA는 $99.9% \times 99.9% = 99.8%$로 뚝 떨어진다. 외부 컴포넌트가 직렬로 연결될수록 전체 가용성은 기하급수적으로 하락(직렬 곱의 법칙)하므로, 단일 장애점(SPOF)을 제거하고 캐싱이나 서킷 브레이커를 도입하여 의존성을 끊어내야 한다.
에러 예산 (Error Budget) 기반의 릴리즈 통제: 모니터링 시스템이 현재 SLA를 위협할 정도로 에러가 치솟았음을 감지하면, 기술 조직의 리더는 즉각적으로 신규 기능 릴리즈(배포)를 중단(Freeze)하고 모든 개발 자원을 시스템 안정성과 버그 수정에 투입하도록 강제해야 한다. 이것이 SLA를 엔지니어링 실무 통제 도구로 쓰는 핵심이다.

안티패턴

내부 부서 간에 법적 SLA를 맺는 행위: 사내의 DB팀과 프론트엔드팀 사이에 금전적 배상이 불가능함에도 무리하게 SLA를 작성하여 책임 전가 문서를 만드는 경우. 사내 부서 간에는 패널티가 동반되는 SLA가 아니라, 상호 협력 지향적인 SLO 문서만을 정의하고 에러 예산 소진 규칙에만 합의해야 전사적 장애 대응에 유리하다.
📢 섹션 요약 비유: 복합 SLA 함정은 **'릴레이 달리기'**와 같다. 한 명이 99% 확률로 바통을 넘기고, 다음 사람도 99%로 잘 넘겨도, 10명이 이어달리면 중간에 누군가 바통을 떨어뜨릴 전체 실패 확률은 무려 10%로 커진다. 부품이 연결될수록 전체 계약 보증은 불리해지므로 여유를 두고 계약해야 한다.

Ⅴ. 기대효과 및 결론

SLA는 추상적이고 감정적인 IT 서비스 품질 논쟁을 객관적인 숫자의 영역으로 끌고 들어와 비즈니스 계약의 투명성을 확보한다. 철저히 관리된 SLA는 고객에게는 시스템에 대한 깊은 신뢰를 심어주고, 제공자에게는 시스템 가용성(High Availability) 아키텍처에 비용을 투자할 명확한 근거(재무적 리스크 방어)를 제시한다.

현대의 SRE 생태계에서 SLA는 단순히 책상 서랍 속에 잠자고 있는 법적 서류가 아니다. 모니터링 대시보드 위에서 실시간으로 갱신되며 코드 배포를 멈출지 말지를 결정하는 살아있는 운영 잣대(Metric)다. 결국 훌륭한 시스템 아키텍트는 인프라만 설계하는 것이 아니라, 고객이 납득하고 회사의 재무를 보호할 수 있는 우아한 SLA 방어선을 함께 설계하는 비즈니스 엔지니어여야 한다.

📢 섹션 요약 비유: SLA는 복잡한 IT 세계의 **'신용 화폐'**와 같다. 장애가 아예 없는 시스템은 세상에 존재할 수 없지만, "장애가 선을 넘으면 내 피 같은 돈(크레딧)을 토해내겠다"는 피도 눈물도 없는 담보가 얽혀 있기 때문에 고객이 안심하고 서버를 맡길 수 있는 것이다.

📌 관련 개념 맵

개념	연결 포인트
SLO (Service Level Objective)	SLA 위반을 사전에 방어하기 위해 SRE 팀 내부적으로 SLA보다 더 타이트하게 설정해 두는 자체 가동률 목표
Error Budget (에러 예산)	SLO를 100%에서 뺀 나머지 잉여 공간. 이 예산(여유 시간)이 넉넉하면 혁신적인 코드 배포를 하고, 바닥나면 릴리즈를 멈춰 SLA 붕괴를 막는다
MTTR (Mean Time To Recovery)	장애 인지부터 서비스 정상화까지 걸리는 평균 복구 시간으로, SLA 패널티를 피하기 위한 가장 직접적인 대응 지표

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

IT 서비스 아웃소싱 및 구두 약속
    │ 장애 시 책임 공방 발생
    ▼
SLA (Service Level Agreement) 명문화
    │ 가용성 지표(Uptime) 및 위약금(Penalty) 계약
    ▼
ITIL 및 ITSM 프레임워크 기반 관리
    │ 
    ▼
SRE (Site Reliability Engineering) 체계 도입
    │ SLI(측정) → SLO(목표) → SLA(계약) 트리오 완성
    ▼
Error Budget (에러 예산) 연동 자동화 릴리즈 통제

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

피자 가게 아저씨가 "최대한 빨리 갈게요"라고 말만 하면 우리가 1시간을 기다려도 화낼 수가 없죠?
하지만 SLA(서비스 협약)는 아예 전단지에 "30분 넘으면 피자값을 100% 환불해 드립니다!"라고 도장을 쾅 찍어놓은 강력한 약속이에요.
이렇게 벌금(위약금)이라는 무서운 규칙을 정해두면, 컴퓨터 회사들이 서버가 고장 나지 않게 훨씬 더 열심히 조심해서 관리하게 된답니다.