[ITSM] 서비스 수준 관리 — SLA·OLA·UC와 약속을 지키는 측정

🚨INCIDENT ALERT

HIGH

월말 SLA 보고 회의. 발주사 IT 담당이 묻습니다. "지난달 결제 서비스 가용성이 SLA 99.9%인데, 우리 쪽 집계로는 99.4%입니다. 페널티 대상 아닌가요?"

운영사(SM) 담당이 답합니다. "저희 모니터링 기준으로는 99.95%입니다. 새벽 정기 점검 30분은 사전 공지된 계획 점검이라 가용성 분모에서 제외했습니다."

회의는 30분간 '그 30분을 다운으로 세느냐'로 흘러갑니다. 결론이 안 납니다. 계약서에는 "가용성 99.9% 이상"이라고만 적혀 있고, 무엇을 다운으로 셀지, 계획 점검을 빼는지는 어디에도 없기 때문입니다.

문제는 기술이 아니라 약속의 설계였습니다. 같은 한 달, 같은 로그를 보고도 두 숫자가 나옵니다. 게다가 결제 지연의 진짜 원인은 외부 PG사(공급자)의 응답 지연이었는데, 그 공급자와는 애초에 응답시간 계약(UC)이 없었습니다. 이 모듈은 이런 회의가 분쟁이 아니라 합의된 보고가 되도록, SLA·OLA·UC를 어떻게 설계·측정·보고하는지를 다룹니다.

이번 챕터에서 배울 것

1고객과의 약속(SLA), 내부 조직 간 약속(OLA), 외부 공급자 계약(UC)의 관계를 그림으로 설명할 수 있다
2SLA는 그것을 떠받치는 OLA·UC가 정렬돼야 지켜진다는 구조를 사례로 설명할 수 있다
3가용성·대응시간·해결시간 같은 지표를 목표뿐 아니라 측정 방법·측정 기준까지 정의할 수 있다
4SLA 위반·감점(페널티)의 작동 방식과 SLA 리포트가 왜 필요한지 한국 SI/SM 맥락에서 설명할 수 있다
5SLA 항목표와 SLA·OLA·UC 정렬표라는 두 산출물을 직접 만들 수 있다

약속은 혼자 지켜지지 않는다 — SLA·OLA·UC

💡개념

고객과의 약속을 떠받치는 세 계층

서비스 수준 관리(Service Level Management)는 한마디로 **"무엇을, 얼마나 잘 해주겠다고 약속하고, 그 약속을 지키고 있는지 측정·보고하는 일"**입니다. 그런데 고객에게 한 약속 하나는 보이지 않는 여러 약속이 받쳐야 성립합니다. 그래서 약속은 세 계층으로 나뉩니다.

SLA(Service Level Agreement) — 서비스 공급자와 고객(발주사·사용자) 사이의 약속. 바깥으로 드러나는 약속입니다. "결제 서비스 가용성 99.9%, 장애 대응 30분 이내."
OLA(Operational Level Agreement) — 같은 공급자 조직 내부의 팀 사이 약속. "운영팀이 인증 장애를 신고하면 플랫폼팀은 15분 안에 착수한다."
UC(Underpinning Contract) — 공급자와 외부 공급자(하도급·솔루션사·클라우드·PG사) 사이의 계약. "PG사는 결제 API를 99.95% 가용성으로 제공한다."

약속	누구와 누구 사이	성격	예
SLA	공급자 ↔ 고객	대외 약속(드러남)	"결제 서비스 99.9%, 대응 30분"
OLA	내부 팀 ↔ 내부 팀	조직 내부 약속	"플랫폼팀 인증 장애 착수 15분"
UC	공급자 ↔ 외부 공급자	외부 계약	"PG사 결제 API 99.95%"

핵심 명제 하나만 기억하면 됩니다. SLA는 그것을 받치는 OLA와 UC가 함께 지켜질 때만 지켜진다. 고객에게 "30분 안에 복구"를 약속했는데, 그 복구에 꼭 필요한 내부 플랫폼팀이 "우리는 다음 날 본다"는 식이면 SLA는 구조적으로 불가능합니다. 외부 PG사가 SLA 없이 "되는 대로" 응답하면, 우리 SLA도 PG사 변덕에 묶입니다.

고객과의 약속인 SLA를 맨 위에 두고, 그 아래 내부 팀 사이 약속인 OLA와 외부 공급자 계약인 UC가 받치는 세 계층 구조와, 받치는 약속이 느슨하거나 없을 때 SLA가 어디서 붕괴하는지를 보여주는 다이어그램

그림: SLA·OLA·UC 세 계층 — 받치는 약속(OLA·UC)이 SLA보다 같거나 더 엄격해야 SLA가 지켜진다.

💡개념

정렬이 깨지면 어디서 깨지는가

세 계층이 정렬돼 있다는 건, 바깥 약속(SLA)보다 받치는 약속(OLA·UC)이 같거나 더 엄격하다는 뜻입니다. 그래야 안쪽이 여유를 갖고 바깥을 보장합니다.

상황	SLA(고객)	OLA(내부)	UC(외부)	결과
정렬됨	대응 30분	플랫폼팀 착수 15분	PG사 응답 보장	SLA 지킬 여지 있음
OLA가 느슨	대응 30분	플랫폼팀 "익일 처리"	(양호)	내부에서 SLA 붕괴
UC가 없음	가용성 99.9%	(양호)	PG사 계약 없음	외부 변덕에 SLA 붕괴

장애가 SLA를 위반했을 때, "누가 게을렀나"를 먼저 묻기 전에 **"받치는 약속이 애초에 SLA를 떠받칠 만큼 엄격했는가"**를 봅니다. 서비스 수준 관리의 절반은 협상 테이블에서 이 정렬을 맞추는 일입니다.

지표는 '숫자'가 아니라 '측정 방법까지'다

💡개념

가용성·대응시간·해결시간을 정의하는 법

SLA에 가장 흔히 들어가는 지표는 세 가지입니다. 각각은 목표 수치만으로는 약속이 되지 못합니다. 무엇을, 어떤 구간에서, 어떻게 세는지까지 합의돼야 비로소 다툼 없는 약속이 됩니다.

가용성(Availability, %) — 서비스가 정상 동작한 시간의 비율. "99.9%"는 한 달(약 30일) 기준 약 43분의 다운까지 허용한다는 뜻입니다. 측정에서 합의해야 할 것: (1) 무엇을 다운으로 셀지(완전 중단만? 응답 지연도?), (2) 측정 구간(월 단위? 업무 시간만?), (3) 계획된 점검(maintenance window)을 분모에서 뺄지.
대응시간(Response Time) — 신고 접수부터 처리 착수·접수 확인까지. "얼마나 빨리 반응했는가." 합의할 것: 접수 시점의 기준(전화 수신? 티켓 생성?), 업무 외 시간 포함 여부.
해결시간(Resolution Time) — 신고부터 정상 서비스 복구까지. "얼마나 빨리 고쳤는가." 대응과 분리해 약속합니다. 합의할 것: 임시 복구(우회)도 해결로 보는지, 고객 응답 대기 시간을 제외(stop the clock)하는지.

지표	무엇을 보는가	반드시 합의할 측정 기준
가용성(%)	정상 동작 시간 비율	다운 정의, 측정 구간, 계획 점검 제외 여부
대응시간	접수~착수 속도	접수 시점 기준, 업무시간 정의
해결시간	접수~정상화 속도	임시복구 인정 여부, 대기시간 제외 여부

대응시간과 해결시간을 반드시 분리하세요. 원인이 외부에 있거나 근본 원인 분석이 필요한 장애는 대응 5분, 해결 5시간일 수 있습니다. 한 숫자로 뭉치면 "빨리 받았지만 오래 못 고친" 상황을 가립니다.

💡개념

가용성 99.9%가 실제로 허용하는 다운 시간

가용성 목표는 직관보다 빡빡합니다. 한 달을 약 30일(720시간)로 보면 허용 다운은 다음과 같습니다.

가용성 목표	월 허용 다운(약)	체감
99%	약 7시간 12분	하루 안에 충분히 소진
99.9%	약 43분	점검 한 번이면 위태
99.95%	약 21분	사실상 무중단 운영 필요

그래서 목표를 99.9%로 올리는 순간, 계획 점검 30분을 분모에서 빼느냐 마느냐가 달성/미달을 가릅니다. 시나리오의 회의가 30분짜리 논쟁이 된 이유가 여기 있습니다 — 숫자는 같지만 측정 기준이 합의되지 않았기 때문입니다.

💡개념

SLA가 깨질 때 — 측정부터 보상까지의 흐름

SLA는 정의로 끝나지 않습니다. 정의한 약속은 타이머로 측정되고, 임박하면 경보가 울리며, 끝내 넘기면 위반으로 처리되고 보상·재발방지로 이어집니다. 이 흐름이 정해져 있어야 위반이 '갑자기 터지는 사고'가 아니라 '예고된 신호'로 다뤄집니다.

핵심은 위반을 "벌점"이 아니라 "신호"로 본다는 태도입니다. 위반 한 건마다 원인을 봅니다 — 인력이 부족했나? 받치는 약속(OLA·UC)이 SLA를 못 받쳤나? 아니면 목표 자체가 비현실적인가? 그래서 반복되는 위반은 숨길 게 아니라 SLA 재협상 또는 받침 약속(OLA/UC) 강화로 이어져야 합니다. 위반을 감추면 숫자는 잠깐 좋아 보여도 신뢰는 무너집니다.

이 약속/지표를 어떻게 다룰 것인가

고객에게 드러나는 서비스 품질 약속을 정해야 한다SLA로 정의지표·목표·측정방법·보고주기까지 한 세트로

그 약속을 받치는 내부 팀의 책임 시간을 정해야 한다OLA로 정의SLA보다 같거나 더 엄격하게 정렬

외부 공급자(클라우드·PG·솔루션)에 의존한다UC로 확보SLA를 떠받칠 보장 수치를 계약에 명시

'99.9%'만 적혀 있고 측정 방법이 없다측정 기준 먼저 합의다운 정의·구간·계획점검 제외 여부 문서화

대응은 빠른데 해결이 늘 늦다대응·해결 분리 측정한 숫자로 뭉치지 말 것 — 병목이 가려진다

외부 공급자 지연으로 SLA가 깨졌다UC 부재/미흡 점검받치는 계약 없으면 SLA는 구조적으로 불가

직접 해보기 — SLA 항목표와 정렬표 만들기

1결제 서비스의 SLA 항목표 작성

가상의 '결제 서비스' 운영 계약을 맡았다고 합시다. 아래 빈 SLA 항목표를 채워, 각 지표에 목표뿐 아니라 측정 방법·보고 주기까지 적어 보세요. 핵심은 "측정 방법" 칸을 비우지 않는 것입니다.

TEXT

[ SLA 항목표 — 작성 대상 ]
지표        | 목표        | 측정 방법                         | 보고 주기
------------|-------------|-----------------------------------|----------
가용성      | (적어보기)  | (다운 정의·구간·계획점검 제외?)   | (적어보기)
대응시간    | (적어보기)  | (접수 시점 기준?)                 | (적어보기)
해결시간    | (적어보기)  | (임시복구 인정? 대기시간 제외?)   | (적어보기)

작성 요령: 목표 수치는 서비스 중요도에 맞춰 정하되, "측정 방법" 칸에 분쟁이 날 만한 지점을 미리 못 박는다는 마음으로 적습니다. 예) 가용성 측정 구간 = 월 단위, 계획 점검은 사전 공지 시 분모에서 제외.

지표 · 목표 · 측정 방법 · 보고 주기를 한 행씩

2SLA를 받치는 OLA·UC 정렬표 작성

이번엔 위 SLA 각 항목이 무엇으로 떠받쳐지는지를 정렬표로 그려 봅니다. SLA 한 줄을 지키기 위해 어떤 OLA·UC가 필요한지 적고, 받치는 약속이 SLA보다 같거나 엄격한지 확인하세요.

TEXT

[ SLA·OLA·UC 정렬표 — 작성 대상 ]
SLA(고객)              | OLA(내부 팀)             | UC(외부 공급자)
-----------------------|--------------------------|------------------------
가용성 99.9%           | 플랫폼팀 (적어보기)      | 클라우드/PG (적어보기)
장애 대응 30분         | 플랫폼팀 착수 (적어보기) | (해당 시 적어보기)
해결 4시간             | (적어보기)               | PG 응답 (적어보기)

작성 요령: 정렬표를 다 채운 뒤, 받치는 약속(OLA·UC)이 SLA보다 느슨한 칸이 하나라도 있으면 그곳이 미래의 SLA 위반 지점입니다. 표로 그리면 협상에서 무엇을 더 조여야 하는지가 한눈에 보입니다.

SLA 항목마다 받치는 내부 약속(OLA)·외부 계약(UC)을 줄 세우기

🔍실행 후 확인할 것

SLA 항목표의 "측정 방법" 칸이 모두 채워졌는가 — 비어 있으면 그 지표는 보고 때 분쟁이 된다
가용성에 다운 정의·측정 구간·계획 점검 제외 여부가 명시됐는가 — 셋 중 하나라도 빠지면 같은 달이 다른 숫자가 된다
대응시간과 해결시간을 따로 적었는가 — 한 줄로 합쳤다면 병목이 가려진다
정렬표에서 받치는 약속(OLA·UC)이 SLA보다 느슨한 칸이 없는가 — 느슨한 칸이 곧 다음 위반 지점
외부 공급자에 의존하는 SLA 항목에 대응하는 UC가 존재하는가 — UC 없는 의존은 통제 불가 리스크
핵심 감각: 좋은 SLA는 "높은 숫자"가 아니라 "측정 가능하고, 받치는 약속으로 정렬된" 약속이다

현장에서 자주 보는 함정

증상: 매월 SLA 리포트에는 "가용성 99.9% 달성"이 찍힙니다. 그런데 고객은 "느려서 못 쓰겠다"고 하고, 보고 회의는 매번 숫자 다툼으로 끝납니다.

원인: 두 가지가 겹쳐 있습니다. (1) 측정 기준 미합의 — 무엇을 다운으로 셀지, 계획 점검을 빼는지가 정해지지 않아 공급사·발주사가 서로 다른 숫자를 계산합니다. (2) 지표가 체감을 못 담음 — 완전 중단만 다운으로 세니, '살아 있지만 10초씩 느린' 상태는 가용성 100%로 잡힙니다. 약속한 지표가 고객이 실제로 겪는 가치(빠른 결제)와 어긋난 것입니다.

해결 방향(이 트랙에서 깊어짐):

SLA에 측정 방법·측정 기준을 본문으로 명시 — 다운 정의, 측정 구간, 계획 점검 제외 여부를 못 박아 숫자 다툼을 없앤다.
가용성만이 아니라 응답시간(성능) 지표를 SLA에 추가 — '살아 있지만 느린' 상태를 약속에 포함해 체감과 맞춘다.
SLA를 받치는 OLA·UC를 정렬 — 외부 PG 지연이 반복되면 UC에 응답시간 보장을 넣어 구조적 원인을 제거.
정기 SLA 리포트를 합의된 기준으로 발행 — 달성·미달과 감점 적용을 객관적 데이터로 입증해, 회의가 다툼이 아니라 확인 절차가 되게 한다.

서비스 수준 관리는 "숫자를 높게 부르는 일"이 아니라 "측정 가능하고 정렬된 약속을 설계하고, 데이터로 지키는 일"입니다.

💼

실무 맥락

현업 패턴

한국 SI/SM 현장에서 SLA는 추상적 다짐이 아니라 돈과 직결된 계약 장치입니다. 운영(SM) 사업은 보통 과업지시서/계약서에 SLA 항목과 목표를 명시하고, 미달 시 월 운영비의 일정 비율을 깎는 감점(페널티) 조항을 둡니다. 어떤 계약은 연속 미달 시 계약 해지·재입찰 사유로까지 이어집니다.

그래서 운영·PM·PMO 담당자에게 SLA는 두 방향의 일입니다. 위로는 발주사·원청에 정기 SLA 리포트로 달성률을 입증하고 감점을 방어·수용하며, 아래로는 실제 작업을 하는 협력사(하도급)와 내부 팀에 OLA를 정렬해 SLA를 떠받칩니다. 협력사 엔지니어가 작업을 하더라도 SLA 책임은 관리자에게 있으므로, 받치는 약속(OLA·UC)을 SLA보다 엄격하게 잡아두는 것이 관리자의 핵심 방어선입니다.

측정 기준이 모호한 SLA에 서명하면, 월말마다 분쟁에 시달리고 감점도 자의적으로 당합니다. 반대로 측정 방법까지 합의된 SLA와 정렬된 OLA·UC, 그리고 객관적 리포트를 갖추면, 페널티 회의는 다툼이 아니라 데이터 확인 절차가 됩니다. 잘 설계된 약속은 운영사를 보호하는 방패입니다.

관련 모듈로 더 깊이:

가용성·용량 관리 — SLA의 가용성 목표를 실제 자원·이중화로 떠받치는 법
이벤트·모니터링 관리 — SLA 달성률을 측정하고 위반 전조를 잡는 모니터링
공급자·협력사 관리 — SLA를 받치는 외부 공급자 계약(UC)의 관리

다음 모듈에서는 이 약속들이 어떤 자산 위에서 지켜지는지 — 서비스를 구성하는 구성요소(CI)와 그 관계를 추적하는 구성 관리와 CMDB를 다룹니다.