이 글의 목적은 서비스 계약서에서 SLA(서비스수준협약)와 페널티(서비스 크레딧·위약금) 조항을 분쟁 없이 작동하도록 설계하는 방법을 체계적으로 정리하여 실무자가 바로 적용할 수 있게 하는 것이다.
1. SLA·페널티 조항이 실패하는 대표 원인
SLA·페널티 조항은 “측정 가능성”, “책임 경계”, “보상 방식의 적정성”, “운영 절차의 실행 가능성”이 동시에 충족되어야 작동한다. 실제 분쟁은 대개 조항 자체보다 측정 정의와 예외 정의가 부실하여 발생한다.
| 실패 원인 | 현장에서 나타나는 증상 | 예방 설계 포인트 |
|---|---|---|
| 측정 정의 부재 | 가용성/응답시간 산정 근거가 서로 다름 | 측정 주체·도구·구간·표본·계산식 명시 |
| 예외/면책 과다 또는 모호 | 장애가 발생해도 “예외”로 처리되어 보상 불가 | 면책 사유를 좁히고, 고객 협조의무 위반만 예외 처리 |
| 책임 경계 불명확 | 벤더/클라우드/고객 환경 중 어디 문제인지 분쟁 | RACI, 책임분기(경계 지점) 도식화, 로그 보존 의무 |
| 페널티가 과도하거나 약함 | 과도하면 계약 체결 불가, 약하면 개선 유인 부족 | 단계형 크레딧, 상한(cap), 반복 위반 시 해지권 연동 |
| 운영 절차 미정 | 장애 통지·보고·원인분석·재발방지 일정이 없음 | 통지 시한, RCA 제출기한, 개선계획 승인 절차 명시 |
주의 : “최대한 노력한다”, “합리적인 범위” 같은 문구만으로 SLA를 구성하면 법적 다툼에서 수치·기준의 공백이 그대로 리스크가 된다. SLA는 숫자·시간·절차로 구성해야 한다.
2. 설계 순서: 무엇을 먼저 정하고 무엇을 계약서에 넣어야 하는가
2.1 서비스 범위와 경계 정의
먼저 서비스의 “대상(무엇)”, “구간(어디까지)”, “시간(언제)”, “변경(어떻게)”을 정의해야 한다. 예를 들어 SaaS라면 애플리케이션 계층만 책임지는지, 고객 네트워크/VPN 구간까지 포함하는지, 외부 연동 API의 가용성까지 포함하는지부터 확정해야 한다.
| 구분 | 필수 기재 항목 | 예시 |
|---|---|---|
| 서비스 대상 | 시스템/모듈/기능 목록 | 웹 포털, 배치 처리, 외부 API, 관리자 콘솔 |
| 책임 경계 | 벤더/고객/제3자 책임 분기 | 고객 단말·사내망은 고객 책임, 데이터센터~앱은 벤더 책임 |
| 운영 시간 | 24x7, 영업시간, 계획점검 창구 | 24x7 운영, 계획점검은 매월 1회 02:00~04:00 |
| 요금 단위 | 월정액/사용량/프로젝트성 | 월 서비스료 기준으로 크레딧 산정 |
2.2 SLA 지표 선정 원칙
SLA 지표는 “고객 가치에 직접 연결되는 지표”만 선정하는 것이 원칙이다. 지표가 많을수록 측정·운영 부담이 증가하고 예외 조항이 늘어나며 분쟁 가능성이 커진다. 일반적으로 가용성, 사고 대응(응답/복구), 성능(응답시간), 지원(티켓 처리), 데이터(백업/복구)로 구성한다.
3. 핵심 SLA 지표별 설계 방법
3.1 가용성(Availability) 정의
가용성은 “서비스가 정상적으로 요청을 처리할 수 있는 상태”의 비율이다. 계약서에는 측정 지점(외부 모니터링/내부 모니터링), 판정 기준(HTTP 코드, 헬스체크 성공 조건), 집계 단위(월/분/5분), 제외 시간(계획점검)을 확정해야 한다.
| 항목 | 권장 기재 내용 | 실무 포인트 |
|---|---|---|
| 측정 주체 | 벤더/고객/제3자 중 누구 기준인지 | 제3자 모니터링을 병행하면 분쟁이 줄어든다 |
| 측정 지점 | 인터넷 외부, VPN 내부, 특정 리전 등 | 고객망 이슈를 제외하려면 경계 지점이 핵심이다 |
| 집계 단위 | 월 단위, 5분 단위 표본 등 | 표본이 커질수록 단기 장애가 희석되므로 균형이 필요하다 |
| 제외 항목 | 계획점검, 고객 과실, 불가항력 등 | 계획점검은 사전 통지·최대 시간·야간 창구를 함께 묶어야 한다 |
가용성 계산식은 계약서에 그대로 삽입하는 것이 안전하다. 다음은 대표 산식 예시이다.
월 가용성(%) = [(월 총 시간 - (장애 시간 - 제외 시간)) / 월 총 시간] × 100
월 총 시간: 해당 월의 총 분(minute) 또는 총 초(second)
장애 시간: 서비스가 SLA 판정 기준을 충족하지 못한 시간의 합
제외 시간: 계획점검, 고객 요청에 의한 중지 등 계약상 제외되는 시간주의 : “장애 시간”을 단순히 공지된 장애로만 제한하면 객관성이 무너진다. 판정 기준을 “측정 도구가 연속 N회 실패한 구간”처럼 자동화 가능한 형태로 정의해야 한다.
3.2 응답시간(Response Time)·성능 SLA
응답시간 SLA는 평균만 두면 의미가 약해진다. 실무에서는 “백분위수(예: p95)” 또는 “SLO 기반 목표”를 사용한다. 다만 계약서에 백분위 정의를 넣지 않으면 해석이 갈린다. 표본 구간, 제외 트래픽, 정상/비정상 요청 구분, 캐시 여부를 함께 정의해야 한다.
| 구분 | 권장 기준 | 계약서 기재 예시 요소 |
|---|---|---|
| 측정 구간 | 서버 처리시간 또는 End-to-End | API Gateway부터 응답 완료까지 |
| 지표 | p95, p99, 평균 | 월간 p95 1.5초 이내 |
| 제외 조건 | 비정상 요청, 대용량 업로드 등 | 요청 크기 10MB 초과 제외 |
| 트래픽 조건 | 기준 동시 사용자/요청량 | 초당 200RPS까지 성능 보장 |
3.3 사고 대응: 응답시간·복구시간(MTTA/MTTR)·해결시간
지원 SLA는 “응답(acknowledgement)”과 “복구/해결(resolution)”을 분리해야 한다. 응답은 빠르지만 해결은 지연되는 경우가 많기 때문이다. 심각도(Severity) 기준을 객관화하고, 심각도 분류 권한(누가 최종 판정하는지)을 정해야 한다.
| 심각도 | 정의 예시 | 초기 응답 | 우회/복구 목표 | 해결 목표 |
|---|---|---|---|---|
| Sev1 | 전체 서비스 중단 또는 핵심 기능 불가 | 15분 이내 | 2시간 이내 | 8시간 이내 |
| Sev2 | 주요 기능 성능 저하 또는 일부 사용자 영향 | 1시간 이내 | 8시간 이내 | 2영업일 이내 |
| Sev3 | 일반 장애, 대체수단 존재 | 4시간 이내 | — | 5영업일 이내 |
| Sev4 | 문의/경미 결함/개선 요청 | 1영업일 이내 | — | 협의 |
주의 : “영업일” 정의(공휴일 포함 여부, 고객 국가/벤더 국가 기준)를 계약서에서 고정해야 한다. 글로벌 계약에서 이 정의가 빠지면 SLA 분쟁이 구조적으로 발생한다.
3.4 유지보수·계획점검(Planned Maintenance)
계획점검은 허용하되 통제해야 한다. 사전 통지 기간, 월 최대 누적 시간, 야간/주말 창구, 긴급점검의 정의, 점검 실패 시 롤백 의무를 정해야 한다. 또한 “계획점검이라도 통지 절차를 위반하면 제외 시간으로 인정하지 않는다” 같은 장치를 두면 SLA 실효성이 높아진다.
| 항목 | 권장 기준 | 실무 효과 |
|---|---|---|
| 사전 통지 | 최소 7일 전 | 업무 영향 조정 가능 |
| 월 최대 누적 | 예: 4시간/월 | 점검 남발 방지 |
| 시간대 | 02:00~06:00 등 | 고객 피해 최소화 |
| 긴급점검 | 보안 취약점 대응 등 제한 사유 | 예외의 남용 방지 |
4. 페널티(서비스 크레딧·위약금) 설계 원칙
4.1 “서비스 크레딧”과 “위약금(손해배상/지체상금)”의 구분
실무에서 가장 많이 쓰는 방식은 서비스 크레딧이다. 서비스 크레딧은 다음 청구서에서 공제하는 형태로 운영이 쉽고 분쟁 비용이 낮다. 반면 위약금이나 손해배상은 금전 지급 및 손해 입증 문제가 결합되어 분쟁 가능성이 증가한다. 계약 목적과 협상력에 따라 조합하되, 이중 처벌이 되지 않도록 정합성을 맞춰야 한다.
| 구분 | 정의 | 장점 | 주의점 |
|---|---|---|---|
| 서비스 크레딧 | SLA 미달 시 다음 청구액에서 공제 | 산정·집행이 빠름 | 환불/현금지급 여부를 명확히 해야 함 |
| 위약금/지체상금 | 기한 지연·중요 의무 위반에 대한 약정금 | 강한 이행 유인 | 과도하면 무효/감액 위험, 상한 설정 필요 |
| 손해배상 | 실손해를 배상 | 정당성 높음 | 손해 입증 부담이 큼 |
4.2 단계형(티어) 크레딧 설계
가용성 미달에 대해 단일 비율을 주면 “개선 유인”이 약하거나 반대로 “과도한 부담”이 된다. 단계형으로 설계하면 경미한 미달에는 낮게, 중대한 미달에는 높게 보상할 수 있다.
| 월 가용성 | 크레딧(월 서비스료 대비) | 운영 해석 |
|---|---|---|
| 99.9% 이상 | 0% | 목표 달성 |
| 99.5% ~ 99.9% 미만 | 5% | 경미한 미달 |
| 99.0% ~ 99.5% 미만 | 10% | 중간 수준 미달 |
| 99.0% 미만 | 20% | 중대한 미달 |
크레딧 산식은 간결해야 하며, “월 서비스료” 기준인지 “영향 받은 모듈 요금” 기준인지 정해야 한다. 다음은 조항에 넣기 쉬운 형태의 예시이다.
서비스 크레딧 = (해당 월 서비스료) × (적용 크레딧 비율)
해당 월 서비스료: 본 계약에 따라 고객이 실제 청구·납부해야 하는 월 정액 요금(부가세 제외)
적용 크레딧 비율: 가용성 티어에 따라 5%/10%/20% 등주의 : “부가세 포함 여부”, “프로모션 할인 적용 시 기준 금액”, “사용량 과금형의 기준(기본료 vs 총액)”이 빠지면 산정 분쟁이 발생한다.
4.3 상한(cap)과 누적 규칙
페널티는 상한이 필요하다. 상한이 없으면 벤더가 감당할 수 없어 계약 체결이 어려워지고, 반대로 상한이 너무 낮으면 SLA가 형식화된다. 일반적으로 월 단위 크레딧 상한(예: 월 서비스료의 20%~50%)을 두고, 반복 위반 시 고객의 해지권 또는 추가 조치를 연동하는 방식이 균형이 좋다.
| 설계 항목 | 권장 방향 | 예시 문구 요소 |
|---|---|---|
| 월 상한 | 월 서비스료의 일정 비율 | 월 크레딧 총액은 월 서비스료의 30%를 초과하지 않는다 |
| 중복 SLA | 동일 원인 중복 보상 제한 | 동일 장애로 다수 SLA가 동시에 위반된 경우 가장 큰 크레딧 1회만 적용 |
| 누적 위반 | 연속/누적 기준 설정 | 3개월 중 2회 이상 99.0% 미만 시 고객은 해지권을 가진다 |
5. 예외(면책) 조항을 “최소·명확”하게 만드는 방법
예외 조항이 많아질수록 고객 관점에서 SLA는 무력화된다. 반대로 예외가 전혀 없으면 벤더가 통제할 수 없는 위험까지 부담하게 된다. 핵심은 “통제 가능성”과 “입증 책임”을 정하는 것이다. 예외 사유를 제한적으로 열거하고, 예외 적용을 주장하는 당사자가 로그·근거를 제시하도록 설계하는 방식이 실무에서 효과적이다.
| 예외 유형 | 권장 포함 여부 | 명확화 포인트 |
|---|---|---|
| 불가항력(천재지변 등) | 포함 | 범위 제한 및 통지·완화 노력 의무 부여 |
| 고객 과실(설정 변경, 접근권한 미제공) | 포함 | 고객 협조 의무 항목을 구체적으로 나열 |
| 제3자 통신망 장애 | 조건부 | 책임 경계 지점 기준으로만 예외 인정 |
| 보안 공격(DDoS 등) | 조건부 | 표준 방어 범위 및 초과 공격 시 처리 규정 |
| 계획점검 | 포함 | 사전 통지·최대 시간·시간대·절차 위반 시 제외 불가 |
주의 : “벤더가 합리적으로 통제할 수 없는 사유” 같은 포괄 문구는 예외를 무한정 확장시키므로 분쟁에서 SLA를 약화시키는 방향으로 작동하기 쉽다.
6. 운영 절차 조항: 통지·보고·RCA·재발방지까지 계약서에 넣는 방식
SLA는 수치만으로 완성되지 않는다. 장애 통지, 진행 상황 공유, 원인분석(RCA) 제출, 재발방지 대책 이행을 계약상 의무로 만들면 운영 품질이 안정된다. 다음 항목은 계약서 본문 또는 별첨 운영정책으로 고정하는 방식이 일반적이다.
| 프로세스 | 필수 기재 항목 | 권장 기준 예시 |
|---|---|---|
| 장애 통지 | 통지 채널, 통지 시한, 최소 정보 | Sev1은 30분 내 이메일+메신저 통지 |
| 상황 업데이트 | 업데이트 주기, 담당자 | Sev1은 60분마다 업데이트 |
| RCA 제출 | 제출 기한, 포함 내용 | 복구 후 5영업일 내 RCA 제출 |
| 재발방지 | 개선안 일정, 검증 방식 | 개선안 30일 내 적용, 변경 후 모니터링 결과 공유 |
| 증적 보존 | 로그·지표 보존기간 | 최소 12개월 보존 및 요청 시 제공 |
7. 계약서에 바로 넣을 수 있는 조항 구성 템플릿
다음 템플릿은 “본문 조항 + 별첨(SLA 스펙)” 구조를 기준으로 한다. 계약서 본문에는 원칙·절차·권리의무를 넣고, 별첨에는 수치·표·산식·운영표준을 넣는 방식이 유지보수에 유리하다.
[권장 목차 예시] 제X조(서비스수준협약) 제Y조(가용성 및 측정) 제Z조(사고 대응 및 지원수준) 제A조(계획점검) 제B조(서비스 크레딧 및 상한) 제C조(예외 및 면책) 제D조(보고 및 개선) 별첨 1: SLA 지표 및 목표치(표) 별첨 2: 측정 방법 및 산식 별첨 3: 장애 등급 분류표 및 대응시간 별첨 4: 통지·보고 양식7.1 측정·판정 문구에 반드시 들어가야 하는 요소
| 요소 | 필수 이유 | 기재 예시(요지) |
|---|---|---|
| 측정 도구 | 데이터의 출처를 고정 | 외부 모니터링 도구 A 및 내부 지표 B를 기준으로 한다 |
| 판정 규칙 | 장애 시간을 자동화 가능하게 함 | 5분 간격 측정에서 연속 2회 실패 시 장애로 본다 |
| 집계 단위 | 월/분/초 기준 혼선을 제거 | 월 단위로 집계하며 분(minute) 단위로 산정한다 |
| 제외 기준 | 예외 남용 방지 | 사전 통지된 계획점검만 제외한다 |
7.2 서비스 크레딧 청구 절차 문구
서비스 크레딧은 “자동 적용”이 가장 분쟁이 적다. 다만 현실적으로는 고객 청구 방식이 많으므로 청구 기한·필요 자료·지급 방식(공제)을 명확히 한다.
서비스 크레딧 청구 절차 예시(요지) 1) 고객은 SLA 미달이 발생한 월의 익월 말일까지 크레딧을 요청할 수 있다. 2) 벤더는 요청 수령 후 15일 이내 측정자료에 따라 인정 여부 및 금액을 회신한다. 3) 인정된 크레딧은 다음 청구서에서 공제하는 방식으로 제공한다. 4) 본 조항에 따른 크레딧은 해당 SLA 미달에 대한 고객의 유일하고 배타적인 구제수단으로 한다(단, 고의·중과실, 비밀유지, 지식재산권 침해 등은 제외).주의 : “유일한 구제수단” 문구를 넣는 경우에도 예외 영역(고의·중과실, 개인정보/보안 사고, 법령 위반 등)을 어디까지 둘지 합의하지 않으면 협상 단계에서 결렬되기 쉽다.
8. 협상 포인트: 고객과 벤더가 자주 부딪히는 쟁점과 정리 방법
8.1 가용성 목표치(99.9 vs 99.95)보다 중요한 것
목표치 숫자 자체보다 “측정 경계”가 실질을 좌우한다. 고객이 체감하는 End-to-End 기준으로 측정하면 숫자는 낮아질 수밖에 없고, 벤더 내부 기준으로만 측정하면 고객 체감과 괴리가 생긴다. 실무에서는 “벤더 책임 구간”과 “고객 체감 구간”을 구분하여 두 종류의 지표를 병행하거나, 책임 경계 지점에서 측정하되 고객 측 모니터링 결과가 현저히 차이날 때의 조정 절차를 둔다.
8.2 페널티의 형태: 크레딧 중심 + 반복 위반 시 권리 강화
일회성 장애에 대해 현금 배상을 크게 두기보다, 서비스 크레딧을 기본으로 하고 반복 위반 시 고객의 권리(추가 보고, 경영진 에스컬레이션, 해지권)를 강화하는 방식이 장기 운영에서 효과적이다.
8.3 장애의 귀책 판단: 로그·증적 제공 의무가 핵심
귀책 분쟁을 줄이려면 “어떤 로그를 누가 얼마나 보관하고, 요청 시 얼마나 빨리 제공하는지”가 핵심이다. 또한 고객이 접근권한, 테스트 계정, 재현 정보 제공을 지연하면 대응 시간이 늘어나므로 고객 협조 의무와 그 위반 시 SLA 타이머 정지 규칙을 명확히 해야 한다.
| 항목 | 벤더 의무 | 고객 의무 | 타이머 규칙 |
|---|---|---|---|
| 재현 정보 | 요청 시 체크리스트 제공 | 에러 화면/시간/요청ID 제공 | 필수 정보 미제공 기간은 해결 목표 시간에서 제외 |
| 접근 권한 | 보안 정책 준수한 접근 방식 제시 | 필요 권한을 기한 내 제공 | 권한 미제공 기간은 우회/해결 목표에서 제외 |
| 로그 제공 | 요청 후 5영업일 내 제공 | 비밀유지 준수 | 제공 지연 시 보고 의무 위반으로 별도 조치 가능 |
9. SLA·페널티 조항 체크리스트
아래 체크리스트는 계약서 검토 시 빠뜨리기 쉬운 항목을 한 번에 점검하기 위한 것이다.
| 영역 | 체크 항목 | OK 기준 |
|---|---|---|
| 정의 | 가용성, 장애, 계획점검, 영업일 정의가 있는가 | 모든 핵심 용어가 계약서 또는 별첨에 정의되어 있다 |
| 측정 | 측정 주체·도구·지점·집계 단위가 있는가 | 제3자 또는 교차 검증 절차가 있다 |
| 지표 | 가용성·응답·복구·지원 지표가 과도하지 않은가 | 운영 가능한 최소 세트로 구성되어 있다 |
| 예외 | 예외가 좁고 명확하며 입증 책임이 정해졌는가 | 포괄 문구 없이 열거 중심이며 증적 규정이 있다 |
| 보상 | 크레딧 산식·상한·중복 규칙이 있는가 | 월 상한 및 반복 위반 조치가 있다 |
| 절차 | 통지·업데이트·RCA·재발방지 기한이 있는가 | 기한과 제출물(보고서 항목)이 구체적이다 |
| 권리 | 반복 위반 시 해지/재협상/감사 권리가 있는가 | 연속 또는 누적 위반 기준이 수치로 있다 |
FAQ
SLA를 계약서 본문에 넣어야 하는가, 별첨으로 빼야 하는가?
원칙·권리의무·보상 규칙은 계약서 본문에 두고, 수치·표·산식·운영표준은 별첨으로 두는 방식이 실무에서 유지보수에 유리하다. 별첨은 변경관리 절차(양측 서면 합의 등)를 함께 두어야 한다.
서비스 크레딧을 “자동 적용”으로 만들기 어렵다면 무엇을 최소로 넣어야 하는가?
청구 기한, 인정 여부 회신 기한, 산정 기준 금액(부가세·할인 포함 여부), 공제 방식(다음 청구서 공제 또는 환불 가능 여부)을 최소로 고정해야 한다. 이 네 가지가 빠지면 크레딧이 사실상 작동하지 않는다.
가용성 목표치가 99.9%인데도 분쟁이 반복된다. 가장 먼저 의심할 부분은 무엇인가?
측정 지점과 장애 판정 규칙을 먼저 의심해야 한다. 고객 체감 구간(End-to-End)과 벤더 책임 구간이 섞여 있거나, 장애 판정이 수동 공지 중심이면 동일 사건을 두고도 장애 시간 산정이 달라진다.
페널티를 높이면 품질이 무조건 좋아지는가?
반드시 그렇지 않다. 과도한 페널티는 벤더가 위험을 피하기 위해 예외 조항을 늘리거나, 계약 체결 자체가 어려워지는 결과로 이어질 수 있다. 단계형 크레딧과 상한을 두고, 반복 위반 시 해지권 등 비금전적 권리를 강화하는 방식이 실효성이 높다.
지원 SLA에서 “영업일” 기준이 불리하게 작동하는 경우는 언제인가?
공휴일 기준이 다르거나, 글로벌 벤더의 타임존과 고객의 타임존이 다를 때 불리하게 작동한다. “영업일”과 “업무시간”의 기준 국가·시간대를 계약서에서 고정해야 한다.