infra
Platform

모듈 맵

[ITSM] IT 거버넌스·운영 KPI·지속적 개선(CSI) — 숫자로 운영을 경영한다

0 / 64 완료

펼치기
0 / 64 완료0%

IT 서비스·프로젝트 관리 · 27 / 64

[ITSM] IT 거버넌스·운영 KPI·지속적 개선(CSI) — 숫자로 운영을 경영한다

IT 거버넌스(방향·평가·모니터링)와 운영 KPI(MTTR·MTBF·SLA 준수율·FCR 등)를 정의하고, 측정한 지표를 지속적 개선(CSI)으로 연결하는 흐름을 한국 기업의 월간 운영보고·개선과제 맥락으로 정리합니다

🚨INCIDENT ALERT
HIGH

분기 보고 회의, 같은 팀 두 운영 리더.

A는 슬라이드를 채워 왔습니다. "이번 분기 정말 열심히 했습니다. 야근도 많이 했고, 티켓도 1,200건 처리했고, 다들 고생했습니다." 임원이 묻습니다. "그래서 작년보다 나아진 겁니까?" A는 머뭇거립니다. "체감상으로는 나아진 것 같은데… 수치로는 따로 안 봤습니다." 회의는 인상과 정성으로 흘러가고, 다음 분기에 무엇을 바꿀지는 정해지지 않습니다.

B는 한 장의 표를 띄웁니다. "MTTR이 42분에서 28분으로 33퍼센트 줄었습니다. SLA 준수율은 96퍼센트로 목표 95퍼센트를 넘겼고요. 다만 재발률이 18퍼센트로 높습니다 — 같은 원인의 장애가 다섯 건 중 한 건꼴로 다시 납니다. 그래서 다음 분기 개선과제는 '상위 재발 원인 3건의 근본 제거'로 잡았고, 목표는 재발률 10퍼센트입니다." 임원은 고개를 끄덕입니다. 무엇이 좋아졌고, 무엇이 문제이며, 다음에 무엇을 할지가 한 화면에 있습니다.

두 사람의 차이는 노력의 양이 아니라 운영을 경영하는 언어입니다. A는 '한 일'을 말했고, B는 '만든 결과와 다음 행동'을 숫자로 말했습니다. 이 모듈은 IT를 감(感)이 아니라 지표로 방향 잡고(거버넌스), 측정하고(KPI), 그 숫자를 개선으로 되돌리는(CSI) 흐름을 다룹니다.

이번 챕터에서 배울 것
  • 1IT 거버넌스(평가·방향설정·모니터링)와 운영 관리(실행)의 차이를 구분하고, 거버넌스가 무엇을 결정하는지 설명할 수 있다
  • 2핵심 운영 KPI(MTTR·MTBF·SLA 준수율·FCR·변경 성공률·재발률)의 정의와 산식, 목표 설정법을 말할 수 있다
  • 3측정한 지표를 통찰로 해석하고, 지속적 개선(CSI)과 개선 등록부로 연결하는 흐름을 그릴 수 있다
  • 4허영 지표와 지표 조작(굿하트의 법칙)의 함정을 식별하고, 균형 잡힌 지표 묶음으로 방어할 수 있다
  • 5한국 기업의 월간 운영보고·KPI 대시보드·개선과제 관리 맥락에서 운영 KPI 표와 CSI 개선 등록부를 작성할 수 있다

거버넌스 — 누가 방향을 정하고 감독하는가

💡개념

거버넌스는 '실행'이 아니라 '방향과 감독'이다

운영을 오래 하다 보면 이상한 순간이 옵니다. 다들 바쁘게 일하는데, 정작 "우리가 지금 옳은 일을 하고 있는가"를 아무도 묻지 않습니다. 일을 옳게(efficiently) 하는 것과 옳은 일(the right thing)을 하는 것은 다른 질문이고, 후자에 답하는 것이 거버넌스입니다.

국제 표준(ISO/IEC 38500, COBIT)은 거버넌스를 세 가지 활동, 곧 EDM으로 정의합니다.

활동한 줄 의미운영의 예
평가(Evaluate)현재 상태와 선택지를 가늠한다"지금 SLA 준수율과 재발률이 어디쯤인가, 무엇이 가장 아픈가"
방향설정(Direct)우선순위·목표·자원 배분을 정한다"다음 분기는 재발률을 10퍼센트로 낮추는 데 집중한다"
모니터링(Monitor)정해진 방향대로 가는지 감독한다"월간 KPI 대시보드로 목표 대비 진척을 본다"

거버넌스(Governance)와 관리(Management)는 자주 섞이지만 층이 다릅니다.

  • 거버넌스: 옳은 일을 하게 만든다 — 방향·우선순위·평가·감독. (의사결정 체계)
  • 관리: 일을 옳게 한다 — 계획·구축·운영·개선. (실행)

거버넌스가 "재발률을 줄이자"고 방향을 정하면, 관리가 "어떤 문제부터, 누가, 언제까지 근본 원인을 제거할지"를 실행합니다. 거버넌스 없이 관리만 있으면 열심히는 하는데 방향이 없고, 관리 없이 거버넌스만 있으면 말만 있고 결과가 없습니다. 이 모듈에서 KPI는 거버넌스의 '눈'이고, CSI는 거버넌스의 '손'입니다.

거버넌스(EDM: 평가·방향설정·모니터링)가 목표를 지시하고, KPI가 측정해 통찰을 주고, CSI 개선 등록부로 되돌리는 좌→우 흐름과, 하단에 CSI 4박자 닫힌 순환 및 허영 지표·지표 조작 함정을 보여 주는 다이어그램

그림: 감(感)이 아니라 숫자로 — 방향 잡고(거버넌스), 측정하고(KPI), 개선으로 되돌린다(CSI). 측정은 끝이 아니라 시작이다.

운영 KPI — 무엇을, 어떻게 재는가

💡개념

좋은 KPI는 정의·산식·목표가 모두 있다

"우리 운영 잘하고 있나요?"에 감으로 답하면 회의가 길어지고 결론이 안 납니다. KPI(Key Performance Indicator, 핵심성과지표)는 그 질문에 숫자로 답하게 합니다. 다만 숫자 하나만 던지면 해석이 갈리므로, 모든 KPI는 (1) 무엇을 재는지(정의), (2) 어떻게 계산하는지(산식), (3) 얼마가 목표인지(목표)를 함께 가져야 합니다.

운영에서 가장 자주 쓰는 핵심 지표를 정리하면:

지표정의산식방향
MTTR(평균 복구 시간)장애 발생 후 정상화까지 걸린 평균 시간총 복구 시간 ÷ 장애 건수낮을수록 좋음
MTBF(평균 무장애 시간)한 장애와 다음 장애 사이 평균 정상 가동 시간총 정상 가동 시간 ÷ 장애 건수높을수록 좋음
SLA 준수율약속한 서비스 수준(SLA)을 지킨 비율(SLA 충족 건 ÷ 전체 건) × 100높을수록 좋음
1차 해결률(FCR)에스컬레이션 없이 첫 접점에서 해결한 비율(1차 해결 건 ÷ 전체 건) × 100높을수록 좋음
변경 성공률롤백·장애 없이 성공한 변경의 비율(성공 변경 ÷ 전체 변경) × 100높을수록 좋음
재발률같은 원인으로 다시 발생한 인시던트 비율(재발 인시던트 ÷ 전체 인시던트) × 100낮을수록 좋음

읽는 법의 핵심은 각 지표가 답하는 질문이 다르다는 것입니다.

  • MTTR vs MTBF: MTTR은 "고장 나면 얼마나 빨리 고치나"(복구 역량), MTBF는 "얼마나 안 고장 나나"(안정성). 둘 다 좋아야 가용성이 올라갑니다. MTTR만 낮고 MTBF가 짧으면 '자주 고장 나는데 빨리 고치는' 피곤한 운영입니다.
  • SLA 준수율: 95퍼센트가 목표라면 100건 중 5건까지는 약속을 못 지켜도 되는 게 아니라, 그 5건이 '누구의, 얼마나 중요한 서비스였나'를 같이 봐야 합니다. 비율 뒤의 무게를 봅니다.
  • FCR(1차 해결률): 높을수록 사용자가 여러 단계로 떠넘겨지지 않고 한 번에 해결된다는 뜻입니다. 서비스데스크 품질의 핵심 신호입니다.
  • 변경 성공률·재발률: 이 둘은 운영의 '체질'을 보여줍니다. 변경 성공률이 낮으면 통제 없는 배포가, 재발률이 높으면 문제관리(근본 원인 제거)가 약하다는 신호입니다.

거버넌스 목표("안정적이고 약속을 지키는 운영")가 "빨리 복구한다·약속을 지킨다·재발을 줄인다" 세 목표로 갈라지고, 다시 MTTR·SLA 준수율·변경 성공률·재발률 지표(각각 정의·산식·목표 포함)로 내려가는 KPI 트리 다이어그램

그림: 거버넌스 목표가 지표로, 지표가 측정값으로 내려온다 — 좋은 KPI는 정의·산식·목표를 모두 갖추고, 목표에 못 미친 지표가 곧 개선과제(CSI)가 된다.

측정의 함정 — 숫자가 거짓말하는 두 가지 방식

💡개념

허영 지표와 지표 조작

지표를 도입하면 운영이 좋아질 것 같지만, 잘못 고른 지표는 오히려 운영을 망칩니다. 두 가지 함정을 반드시 알아야 합니다.

1) 허영 지표(Vanity Metric) — 보기엔 좋은데 행동을 못 바꾸는 숫자. "처리 티켓 1,200건", "누적 가입자 10만 명", "총 알림 5만 건" 같은 숫자는 크고 인상적이지만, "그래서 무엇을 바꿀 것인가"로 이어지지 않습니다. 처리 건수가 많다는 건 거꾸로 신고가 많았다는 뜻일 수도 있죠. 좋은 지표는 행동을 부르는 '실행 지표(actionable metric)'입니다 — 재발률이 18퍼센트라면 "상위 재발 원인부터 제거하자"는 행동이 바로 나옵니다.

2) 지표 조작(Gaming) — 지표가 목표가 되면 지표가 왜곡된다. 이것이 굿하트의 법칙입니다: "측정이 목표가 되는 순간, 그 측정은 좋은 지표이기를 멈춘다." MTTR만 KPI로 걸면, 운영자는 '진짜 빨리 고치기'가 아니라 '티켓을 빨리 닫고 새로 열기'로 숫자를 만듭니다. FCR만 보면 해결 안 된 건도 '해결'로 종료하고 싶어집니다.

방어책은 두 가지입니다.

  • 균형 잡힌 묶음(balanced set): 단일 지표가 아니라 서로 견제하는 지표를 함께 봅니다. MTTR(속도)은 재발률·재오픈율(품질)과 짝지어, "빨리 닫았는데 다시 열린다"를 잡아냅니다.
  • 숫자 뒤의 품질 검증: 종료된 티켓을 표본 점검해 '정말 해결됐는지' 확인합니다. 지표는 대화의 시작이지 끝이 아닙니다.

핵심 감각: 지표는 행동을 유도한다. 그러니 "이 지표를 KPI로 걸면 사람들이 어떤 편법을 쓸까"를 먼저 상상하고, 그 편법을 막을 짝 지표를 함께 설계해야 합니다.

이 상황에서 어떤 지표를 봐야 하는가
장애가 났을 때 너무 오래 끌어 고객 불만이 크다MTTR(평균 복구 시간)복구 절차·에스컬레이션·런북으로 단축
장애가 너무 자주 난다 — 빨리 고쳐도 또 난다MTBF + 재발률문제관리로 근본 원인 제거가 핵심
고객·발주사에 약속한 서비스 수준을 지키는지 보고해야 한다SLA 준수율비율 뒤의 '어떤 서비스였나' 무게까지
서비스데스크가 일을 윗단계로 자꾸 떠넘긴다1차 해결률(FCR)지식베이스·권한·교육으로 1차 역량 강화
배포·변경만 하면 사고가 난다변경 성공률변경관리·롤백 계획·점검창 정비
처리 건수가 많다고 자랑하는데 서비스는 안 좋아진다허영 지표 의심 — 실행 지표로 교체재발률·고객 영향 시간 등 행동을 부르는 지표로

직접 해보기 — 월간 운영 KPI 표와 CSI 개선 등록부 만들기

1이번 달 운영 데이터로 KPI를 계산하고 통찰을 끌어낸다

아래는 어느 운영팀의 이번 달 원자료입니다. 이 숫자로 KPI 표를 채우고, 목표와 비교해 '무엇이 문제인지'를 한 줄씩 적어 보세요.

TEXT
[이번 달 원자료]
- 인시던트 총 100건, 총 복구 시간 2,800분
- 그중 같은 원인으로 재발한 인시던트 22건
- 서비스데스크 1차 접점에서 바로 해결한 건 64건
- SLA 대상 건 100건 중 약속 시간 내 처리 94건
- 이번 달 변경 작업 40건, 그중 롤백·장애로 실패한 변경 4건
- 목표: MTTR 25분 이하 / SLA 준수율 95% 이상 / FCR 70% 이상 / 변경 성공률 95% 이상 / 재발률 10% 이하

산출물은 두 개의 표입니다. (1) 운영 KPI 표 — 지표·정의·산식·목표·실적·달성 여부. (2) CSI 개선 등록부 — 목표를 못 채운 지표를 개선과제로 옮겨 담은 표. 계산과 정답 해석은 ObserveBlock에 있습니다.

지표 · 정의 · 산식 · 목표 · 실적
🔍실행 후 확인할 것
  • MTTR = 2,800분 ÷ 100건 = 28분 → 목표 25분 미달(빨간불). 복구 시간이 살짝 길다
  • SLA 준수율 = 94 ÷ 100 × 100 = 94% → 목표 95% 미달(노란불). 6건이 약속을 넘김
  • FCR(1차 해결률) = 64 ÷ 100 × 100 = 64% → 목표 70% 미달(노란불). 1차에서 못 끝내는 비율이 높다
  • 변경 성공률 = (40 − 4) ÷ 40 × 100 = 90% → 목표 95% 미달(빨간불). 열 번 중 한 번꼴로 변경 사고
  • 재발률 = 22 ÷ 100 × 100 = 22% → 목표 10% 크게 미달(빨간불). 다섯 건 중 한 건 이상이 같은 원인 재발
  • 통찰: 가장 아픈 곳은 재발률(22%)과 변경 성공률(90%). 즉 "근본 원인 제거"와 "변경 통제"가 약하다. MTTR·SLA·FCR은 목표에 근접 — 큰 불부터 끄는 게 맞다
  • CSI 연결: 미달 지표 중 영향이 큰 순서로 개선과제를 등록 → 재발률↓(문제관리 강화), 변경 성공률↑(롤백·점검창 정비)를 이번 분기 우선과제로

측정에서 개선으로 — CSI와 개선 등록부

💡개념

지표 → 통찰 → 개선: 측정은 끝이 아니라 시작이다

KPI를 잘 계산해도, 보고서에 숫자만 박고 끝나면 운영은 그대로입니다. 측정의 목적은 보고가 아니라 개선입니다. 이 측정→통찰→개선의 순환이 **지속적 서비스 개선(CSI, Continual Service Improvement)**입니다.

ITIL의 CSI는 "어떻게 개선할까"를 일곱 단계의 흐름으로 봅니다. 실무에서 외울 핵심은 네 박자입니다.

  1. 무엇을 잴 것인가 — 비전·목표와 연결된 지표를 고른다. (허영 지표를 피하는 단계)
  2. 측정한다 — 정의·산식대로 데이터를 모은다.
  3. 분석해 통찰을 얻는다 — "이 숫자가 무엇을 말하는가, 어디가 가장 아픈가"를 해석한다.
  4. 개선을 실행하고 다시 측정한다 — 개선과제를 만들어 실행하고, 효과를 같은 지표로 확인한다.

여기서 통찰이 흩어지지 않게 잡아 두는 장치가 **CSI 개선 등록부(CSI Register, 개선과제 관리대장)**입니다. "재발률이 22퍼센트로 높다"는 통찰을 누가·언제까지·어떤 목표로 개선할지 한 줄로 못 박아 추적합니다.

항목의미
개선 ID추적용 번호 (예: CSI-2026-03)
개선과제무엇을 개선하는가 (한 줄)
근거 지표어떤 KPI의 어떤 값에서 출발했는가 (예: 재발률 22%)
목표개선 후 도달할 값 (예: 재발률 10%)
담당·기한누가, 언제까지
우선순위영향·긴급도 기준 (높음/중간/낮음)
상태등록 → 진행 → 완료 → 효과 검증

위 실습의 미달 지표를 등록부로 옮기면 이렇게 됩니다.

개선 ID개선과제근거 지표목표담당·기한우선순위
CSI-2026-03상위 재발 원인 3건 근본 제거(문제관리 연계)재발률 22%재발률 10%운영팀·이번 분기높음
CSI-2026-04변경 롤백 계획·점검창 의무화변경 성공률 90%95% 이상변경관리자·6주높음
CSI-2026-051차 해결률 향상(지식베이스·권한 정비)FCR 64%70% 이상서비스데스크·8주중간

핵심은 개선이 '느낌'이 아니라 '근거 지표가 있는 추적 가능한 과제'가 된다는 점입니다. 다음 달 보고에서 같은 지표를 다시 재면, 개선이 효과가 있었는지를 숫자로 답할 수 있습니다.

현장에서 자주 보는 함정

증상: 월간 운영보고에 KPI 표가 빠지지 않습니다. MTTR, SLA 준수율, 처리 건수가 매달 슬라이드에 뜹니다. 그런데 1년이 지나도 재발률은 그대로고, 같은 장애가 분기마다 반복됩니다. 보고는 "측정"에서 멈추고 "개선"으로 가지 않습니다.

원인: 지표를 보고용으로만 쓰고 행동용으로 쓰지 않았습니다. (1) 숫자만 있고 통찰("그래서 어디가 가장 아픈가")이 없거나, (2) 통찰은 있는데 그것을 잡아 둘 개선 등록부가 없어 매달 휘발됩니다. 게다가 처리 건수 같은 허영 지표가 슬라이드를 채우면, 진짜 아픈 곳(재발률·변경 성공률)이 가려집니다.

해결 방향(이 트랙·이 모듈의 핵심):

  • 모든 KPI에 목표선을 긋는다 — 목표 미달 지표가 곧 개선 후보다.
  • 미달 지표를 CSI 개선 등록부로 옮겨 담당·기한·목표를 못 박는다.
  • 다음 보고에서 같은 지표를 다시 재 개선 효과를 숫자로 검증한다(닫힌 순환).
  • 허영 지표(처리 건수)를 실행 지표(재발률·고객 영향 시간)로 교체한다.
  • 단일 지표 집착(MTTR만)을 균형 묶음으로 바꿔 지표 조작을 막는다.

대시보드의 목적은 '예쁜 보고'가 아니라 '다음 행동의 결정'입니다. 매달 같은 숫자가 떠 있다면, 그건 안정된 게 아니라 개선이 멈춘 신호입니다.

💼
실무 맥락
현업 패턴

발주사·원청의 IT 운영 담당, 서비스데스크·운영(SM) 관리자, PMO 자리에 서면, 당신이 매달 마주하는 의식이 월간 운영보고입니다. 한국 기업·공공기관의 운영보고는 대개 "지난달 무슨 일이 있었나"가 아니라 "약속한 수준을 지켰는가, 무엇을 개선하고 있는가"를 묻습니다. 그 자리에서 정성("열심히 했습니다")은 통하지 않습니다 — 임원과 발주처가 보는 것은 KPI 대시보드의 목표 대비 실적개선과제(CSI)의 진척입니다.

그래서 실무에서 관리자는 운영 KPI 표(지표·정의·산식·목표·실적)를 매달 갱신하고, 목표를 못 채운 지표를 **개선과제 관리대장(CSI 개선 등록부)**으로 옮겨 담당·기한·목표와 함께 추적합니다. 협력사(하도급) 엔지니어가 실제 복구·변경 작업을 하더라도, SLA 준수와 재발 방지에 대한 책임과 보고는 관리자의 몫입니다. 숫자로 말하지 못하는 관리자는 잘못된 보고에 속고, 숫자로 말하는 관리자는 발주처와 대등하게 다음 분기 우선순위를 협상합니다. 거버넌스(방향)·KPI(측정)·CSI(개선)는 그 협상 테이블의 공용어입니다.


관련 모듈로 더 깊이:

다음 모듈에서는 ITSM의 '운영' 언어를 넘어, 정해진 기간과 범위 안에서 새로운 것을 만들어 내는 또 다른 관리의 세계 — Phase 5의 프로젝트 관리 입문을 다룹니다.

지식 확인

퀴즈 — 4문제

Q1

IT 거버넌스(Governance)와 운영 관리(Management)의 가장 본질적인 차이는?

Q2

장애 100건의 총 복구 시간이 500분이었다. MTTR(평균 복구 시간)은 얼마이며, 이 값이 낮을수록 무엇을 뜻하는가?

Q3

한 운영자가 '이번 달 처리 티켓 수 1,200건'을 자기 성과로 보고했다. 이것이 '허영 지표(vanity metric)'가 될 수 있는 이유는?

Q4

지표를 KPI로 걸었더니 운영자가 '인시던트를 5분 만에 임의로 종료(Close)하고 곧장 새 티켓으로 다시 여는' 일이 생겼다. 이 현상의 이름과 교훈은?

0 / 4 답변

🧪 실습으로 확인하기

Jira 이슈·스프린트·백로그 — 일을 티켓으로 굴리기

초급

Jira(클라우드 무료 플랜)에서 프로젝트를 만들고 이슈 타입·워크플로우를 구성한 뒤, 백로그를 스프린트로 끊어 보드로 운영하고 JQL·번다운으로 현황을 읽는 전 과정을 직접 구성한다.

60📋 4단계💻 직접 환경
실습 시작하기 →

이것도 배워보세요