월말, 발주사 운영 담당에게서 메일 한 통이 옵니다. "이번 달 SLA 리포트 부탁드립니다."
신입 매니저 A는 티켓 시스템에서 한 달 치 장애 목록을 엑셀로 내려받아 그대로 첨부합니다. 200줄짜리 원본. 발주사는 "그래서 약속은 지킨 겁니까, 아닌 겁니까?"라고 되묻습니다.
선임 매니저 B는 다릅니다. 같은 원본을 지표별로 집계합니다 — 가용성, P1 평균 대응시간, 해결 시간, SLA 준수율. 각 지표를 계약상 목표와 나란히 놓아 준수/미준수를 판정하고, 미준수 3건은 원인별로 분류해 "왜 늦었는지"를 적고, 마지막에 다음 달 개선계획(담당·기한)을 붙입니다. A4 두 장.
발주사는 B의 리포트를 보고 "이번 달은 인증 구간이 문제였군요. 개선안 좋습니다"라고 답합니다.
둘의 차이는 데이터가 아니라 데이터를 약속·원인·개선으로 엮는 능력입니다. 이 캡스톤은 한 달 치 운영 현황을 받아, B의 SLA 리포트를 처음부터 끝까지 직접 만들어 봅니다.
- 1월간 운영 현황(장애·문의 대응 데이터)을 SLA 지표별로 집계해 리포트 표로 정리할 수 있다
- 2KPI(지표)와 SLA 목표를 구분하고, 실적을 목표와 대조해 준수/미준수를 판정할 수 있다
- 3장애 등급별 통계와 평균 대응/해결 시간을 산출하고, 평균과 준수율의 차이를 해석할 수 있다
- 4SLA 미준수 건을 원인별로 분류하고, 각 원인을 구체적 개선계획(담당·기한)으로 연결할 수 있다
- 5SLM·KPI·CSI(지속적 개선)를 하나의 산출물(SLA 리포트)로 종합해 발주사에 보고할 수 있다
캡스톤이 종합하는 것 — 흩어진 한 달을 한 장으로
이번 시나리오: 4월 운영 현황으로 SLA 리포트 만들기
지금까지 트랙에서 따로 배운 조각들이 이 캡스톤에서 하나로 모입니다.
- 서비스 수준 관리(SLM) — 고객과 약속한 SLA를 정의하고 측정·보고하는 활동.
- KPI(지표) — 가용성, 대응시간, 해결시간, 준수율처럼 '무엇을 어떻게 재는가'.
- 인시던트 등급(P1~P4) — 영향×긴급도로 매긴 우선순위. 등급별로 SLA 목표가 다릅니다.
- CSI(지속적 개선) — 측정 결과를 다음 달을 더 낫게 만드는 행동으로 잇는 마무리 고리.
이번 캡스톤의 입력은 가상의 한 달(4월) 운영 현황입니다. 핵심 원본 수치는 다음과 같다고 합시다.
| 항목 | 4월 실적(원본) |
|---|---|
| 총 인시던트 | 42건 |
| P1(전사·핵심 중단) | 2건 |
| P2(부분·주요 서비스 저하) | 7건 |
| P3(소수·업무 가능) | 18건 |
| P4(경미·단일 사용자) | 15건 |
| 서비스 요청(장애 아님) | 60건 |
| 서비스 다운타임 합계 | 약 26분 (월 43,200분 기준) |
이 원본을 그대로 보내면 A의 리포트입니다. 우리는 이것을 지표 → 목표 대조 → 등급 통계 → 미준수 분석 → 개선계획 순서로 가공합니다.
리포트의 뼈대 — 세 개의 표와 하나의 흐름
좋은 SLA 리포트는 화려한 게 아니라 읽는 사람이 3분 안에 판단할 수 있는 구조입니다. 우리는 세 개의 표로 구성합니다.
- SLA 관리표 — 지표별 '목표 vs 실적 vs 판정'. 발주사가 가장 먼저 보는 표.
- 장애 등급별 통계표 — P1~P4 건수와 등급별 평균 대응/해결 시간. '무엇이 얼마나, 얼마나 빨리'.
- 개선계획표 — 미준수·반복 원인에 대한 다음 달 행동(담당·기한). CSI 고리.
흐름은 "지켰는가(SLA 관리표) → 무슨 일이 있었나(등급 통계) → 못 지킨 건 왜이고 어떻게 할 건가(미준수 분석 + 개선계획)" 입니다. 숫자를 나열하는 게 아니라 이 질문 순서로 읽히게 배치하는 것이 핵심입니다.
그림: 흩어진 원본 수치를 세 개의 표로 가공해 "지켰는가 → 무슨 일이 → 어떻게 할 건가" 질문 순서로 읽히게 배치한다.
지표를 어떻게 판정할 것인가
직접 해보기 — 한 달 현황을 리포트로 가공하기
위 4월 원본과 아래 보조 수치를 사용해 직접 표를 채워 보세요. 완성 예시는 ObserveBlock에 있습니다.
[보조 수치 — 4월]
- 가용성: 다운타임 26분 / 월 43,200분
- P1 2건의 대응시작 시간: 9분, 22분 (목표 15분 이내)
- P1 2건의 해결 시간: 95분, 210분 (목표 4시간=240분 이내)
- 전체 인시던트 SLA 준수: 42건 중 38건 준수 / 4건 초과
- 초과 4건의 메모:
· 4/8 P1 결제중단 — 인증 구간 지연으로 해결 210분(원인: 외부 인증 공급자 응답 지연)
· 4/8 P2 주문지연 — 위 장애 여파 (원인: 동일 인증 구간)
· 4/19 P2 배치실패 — 야간 담당 부재로 대응 착수 지연 (원인: 야간 인력 공백)
· 4/26 P3 보고서오류 — 재현 지연으로 해결 장기화 (원인: 지식베이스 미비)
집계 가이드:
- 가용성 = (43,200 − 26) / 43,200 × 100. 소수 둘째 자리까지.
- P1 평균 대응 = (9 + 22) / 2. P1 평균 해결 = (95 + 210) / 2.
- SLA 준수율 = 38 / 42 × 100.
- 미준수 4건은 메모의 '원인'을 외부 공급자 / 인력 공백 / 지식베이스 미비로 묶습니다.
세 개의 표(SLA 관리표·등급 통계표·개선계획표)를 모두 채우는 것이 이 실습의 산출물입니다.
순서: 지표 집계 → 목표 대조 → 등급 통계 → 미준수 분석 → 개선계획- 가용성 = (43200-26)/43200×100 = 99.94% → 목표 99.9% 대비 준수
- P1 평균 대응 = (9+22)/2 = 15.5분 → 목표 15분 대비 근소 초과(주의), 건별로는 1건(22분) 미준수
- P1 평균 해결 = (95+210)/2 = 152.5분 → 목표 240분 대비 준수(평균), 단 4/8 건 210분은 목표 내지만 위험 신호
- SLA 준수율 = 38/42×100 = 90.5% → 목표 95% 대비 미준수(핵심 경고 지표)
- 평균 vs 준수율 해석: 가용성·평균 해결시간은 양호하나, 준수율 90.5%로 떨어진 이유는 소수 P1/P2의 시간 초과 — 평균이 가린 약속 미이행을 준수율이 드러냄
- 미준수 원인 분류: 외부 인증 공급자 지연 2건(4/8 연쇄), 야간 인력 공백 1건(4/19), 지식베이스 미비 1건(4/26)
- 산출물 1 — SLA 관리표(지표·목표·실적·판정)가 한눈에 준수/미준수를 보여줌
- 산출물 2 — 장애 등급별 통계표가 P1~P4 분포와 등급별 대응/해결 시간을 보여줌
- 산출물 3 — 개선계획표가 각 미준수 원인을 담당·기한이 있는 행동으로 연결함
산출물 예시 1 — SLA 관리표 (지표·목표·실적·판정)
| 지표(KPI) | 목표(SLA) | 4월 실적 | 판정 |
|---|---|---|---|
| 서비스 가용성 | 99.9% | 99.94% | 준수 |
| P1 평균 대응 착수 | 15분 이내 | 15.5분 | 미준수(근소) |
| P1 평균 해결 시간 | 4시간(240분) 이내 | 152.5분 | 준수 |
| 전체 SLA 준수율 | 95% 이상 | 90.5% | 미준수 |
| 서비스 요청 처리 | 영업일 2일 이내 | 평균 1.3일 | 준수 |
요약: 가용성·해결 시간은 약속을 지켰으나, P1 대응 착수와 전체 준수율이 목표에 못 미쳤습니다. 원인은 아래 미준수 분석으로 잇습니다.
산출물 예시 2 — 장애 등급별 통계표
| 등급 | 건수 | 평균 대응 착수 | 평균 해결 시간 | 비고 |
|---|---|---|---|---|
| P1 | 2건 | 15.5분 | 152.5분 | 4/8 결제중단(외부 인증 지연) 포함 |
| P2 | 7건 | 24분 | 3.1시간 | 4/8 연쇄 1건, 4/19 배치실패 1건 |
| P3 | 18건 | 1.2시간 | 6.4시간 | 4/26 보고서오류(지식베이스 미비) 포함 |
| P4 | 15건 | 4.0시간 | 1.1영업일 | 경미·단일 사용자, 영향 낮음 |
| 합계 | 42건 | — | — | 서비스 요청 60건은 별도 집계 |
해석: 건수는 P3·P4가 많지만, 약속을 깬 핵심은 소수의 P1·P2입니다. 운영 개선은 '많이 들어온 P4'가 아니라 '약속을 깬 P1·P2 원인'에 집중해야 합니다.
산출물 예시 3 — 개선계획표 (CSI)
| 미준수 원인 | 영향 | 개선 행동 | 담당 | 기한 |
|---|---|---|---|---|
| 외부 인증 공급자 응답 지연 | 4/8 P1·P2 연쇄 2건 | 공급자 UC 재점검·대체 인증 경로 검토, 장애 시 자동 우회 | 플랫폼팀 | 5월 3주 |
| 야간 인력 공백 | 4/19 P2 대응 착수 지연 | 야간 온콜 당번표·에스컬레이션 경로 수립 | 운영팀 | 5월 2주 |
| 지식베이스 미비 | 4/26 P3 해결 장기화 | 반복 장애 3종 처리 절차 KB 등록 | SM 담당 | 5월 4주 |
| P1 대응 착수 지연 | 준수율 90.5% 하락 | P1 자동 호출(알림) 룰 강화, 초동 체크리스트 배포 | 서비스데스크 | 5월 2주 |
이 표가 있어야 리포트가 '평가서'가 아니라 다음 달을 바꾸는 계획서가 됩니다. 5월 리포트는 이 행동들이 준수율을 얼마나 끌어올렸는지로 시작됩니다 — 이것이 CSI 고리입니다.
월간 SLA 리포트는 한 번 찍고 끝나는 사진이 아니라 돌아가는 고리입니다. 측정 → 판정 → 미준수 분석 → 개선계획이 다음 달 측정으로 되돌아오며, 4월에 세운 개선 행동의 효과가 5월 수치로 검증됩니다. 핵심은 개선의 초점을 많이 들어온 P4가 아니라 약속을 깬 소수의 P1·P2 원인에 맞추는 것입니다 — 평균은 양호해도 준수율이 떨어진 진짜 이유가 거기 있기 때문입니다. 이 고리가 돌 때 리포트는 비로소 '평가서'에서 '계획서'가 됩니다.
현장에서 자주 보는 함정
증상: SLA 리포트를 꼬박꼬박 보냅니다. 지표도 깔끔하게 정리돼 있습니다. 그런데 미준수 항목이 매달 비슷하고, 발주사는 "지난달이랑 똑같은데요?"라고 반응합니다.
원인: 리포트가 측정에서 멈추고 개선으로 이어지지 않았습니다. 미준수 건을 '건수'로만 적고 원인 분류와 개선계획(담당·기한)이 없으면, 다음 달에도 같은 원인이 같은 미준수를 만듭니다. 측정은 CSI의 시작일 뿐, 끝이 아닙니다.
해결 방향:
- 미준수 건을 반드시 원인으로 분류한다(외부·인력·절차·지식 등). 분류가 곧 개선의 단위입니다.
- 각 원인에 담당과 기한이 있는 개선 행동을 붙인다. 담당 없는 개선은 안 일어납니다.
- 다음 달 리포트를 지난달 개선 행동의 결과로 시작한다("4월 인증 우회 적용 → 5월 연쇄 장애 0건"). 이 연결이 보이면 발주사는 리포트를 신뢰합니다.
- 실적이 목표에 못 미친다고 목표(SLA)를 임의로 내리지 않는다. 목표 조정은 협상·합의 사항이지, 리포트 작성자가 손댈 수치가 아닙니다.
리포트의 가치는 숫자의 정확함이 아니라, 숫자가 다음 행동을 만드는가에 있습니다.
한국의 SI/SM 현장에서 월간 SLA 리포트는 운영(SM) 사업의 가장 정기적이고 중요한 산출물입니다. 발주사·원청은 이 리포트로 협력사의 운영 품질을 평가하고, 계약 연장·페널티·인센티브를 판단합니다. 그래서 운영 매니저·PMO에게 SLA 리포트 작성은 선택이 아니라 매달 돌아오는 핵심 업무입니다.
이 자리에서 당신은 직접 서버를 만지기보다, 티켓 시스템(Jira Service Management·ServiceNow·Redmine 등)의 한 달 데이터를 약속(SLA)·원인·개선으로 번역합니다. 협력사 엔지니어가 실제 장애를 처리하더라도, "이번 달 약속을 지켰는가, 못 지킨 건 왜이며 어떻게 막을 것인가"를 발주사 앞에서 설명하는 책임은 관리자에게 있습니다.
좋은 리포트는 비난서가 아니라 개선 계획서입니다. 미준수를 숨기지 않고 원인과 대책으로 정면 돌파하는 매니저가, 역설적으로 발주사의 신뢰를 얻습니다. SLM·KPI·CSI를 하나의 표 묶음으로 엮어내는 이 능력이, 기술을 아는 관리자를 협력사·발주사 양쪽과 대등하게 대화하게 만듭니다.
관련 모듈로 더 깊이:
- 서비스 수준 관리 — SLA·SLO를 정의하고 운영 수준을 합의하는 SLM 기본
- IT 거버넌스·운영 KPI·지속적 개선(CSI) — 운영 품질을 지표(KPI)로 측정하고 거버넌스로 잇는 법
- 주간보고·경영보고 — 월간 리포트와 같은 결과 중심 보고를 주간으로 쓰는 법
다음 모듈에서는 운영 단계를 넘어 사업의 시작점으로 거슬러 올라가, 발주사가 낸 제안요청서(RFP)를 읽고 요구사항·범위·평가 기준을 분석해 제안 전략을 세우는 RFP 분석 시뮬레이션을 다룹니다.