분기 보고 회의, 같은 팀 두 운영 리더.
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는 거버넌스의 '손'입니다.
확대
그림: 감(感)이 아니라 숫자로 — 방향 잡고(거버넌스), 측정하고(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차 해결률): 높을수록 사용자가 여러 단계로 떠넘겨지지 않고 한 번에 해결된다는 뜻입니다. 서비스데스크 품질의 핵심 신호입니다.
- 변경 성공률·재발률: 이 둘은 운영의 '체질'을 보여줍니다. 변경 성공률이 낮으면 통제 없는 배포가, 재발률이 높으면 문제관리(근본 원인 제거)가 약하다는 신호입니다.
확대
그림: 거버넌스 목표가 지표로, 지표가 측정값으로 내려온다 — 좋은 KPI는 정의·산식·목표를 모두 갖추고, 목표에 못 미친 지표가 곧 개선과제(CSI)가 된다.
측정의 함정 — 숫자가 거짓말하는 두 가지 방식
허영 지표와 지표 조작
지표를 도입하면 운영이 좋아질 것 같지만, 잘못 고른 지표는 오히려 운영을 망칩니다. 두 가지 함정을 반드시 알아야 합니다.
1) 허영 지표(Vanity Metric) — 보기엔 좋은데 행동을 못 바꾸는 숫자. "처리 티켓 1,200건", "누적 가입자 10만 명", "총 알림 5만 건" 같은 숫자는 크고 인상적이지만, "그래서 무엇을 바꿀 것인가"로 이어지지 않습니다. 처리 건수가 많다는 건 거꾸로 신고가 많았다는 뜻일 수도 있죠. 좋은 지표는 행동을 부르는 '실행 지표(actionable metric)'입니다 — 재발률이 18퍼센트라면 "상위 재발 원인부터 제거하자"는 행동이 바로 나옵니다.
2) 지표 조작(Gaming) — 지표가 목표가 되면 지표가 왜곡된다. 이것이 굿하트의 법칙입니다: "측정이 목표가 되는 순간, 그 측정은 좋은 지표이기를 멈춘다." MTTR만 KPI로 걸면, 운영자는 '진짜 빨리 고치기'가 아니라 '티켓을 빨리 닫고 새로 열기'로 숫자를 만듭니다. FCR만 보면 해결 안 된 건도 '해결'로 종료하고 싶어집니다.
방어책은 두 가지입니다.
- 균형 잡힌 묶음(balanced set): 단일 지표가 아니라 서로 견제하는 지표를 함께 봅니다. MTTR(속도)은 재발률·재오픈율(품질)과 짝지어, "빨리 닫았는데 다시 열린다"를 잡아냅니다.
- 숫자 뒤의 품질 검증: 종료된 티켓을 표본 점검해 '정말 해결됐는지' 확인합니다. 지표는 대화의 시작이지 끝이 아닙니다.
핵심 감각: 지표는 행동을 유도한다. 그러니 "이 지표를 KPI로 걸면 사람들이 어떤 편법을 쓸까"를 먼저 상상하고, 그 편법을 막을 짝 지표를 함께 설계해야 합니다.
직접 해보기 — 월간 운영 KPI 표와 CSI 개선 등록부 만들기
아래는 어느 운영팀의 이번 달 원자료입니다. 이 숫자로 KPI 표를 채우고, 목표와 비교해 '무엇이 문제인지'를 한 줄씩 적어 보세요.
[이번 달 원자료]
- 인시던트 총 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는 "어떻게 개선할까"를 일곱 단계의 흐름으로 봅니다. 실무에서 외울 핵심은 네 박자입니다.
- 무엇을 잴 것인가 — 비전·목표와 연결된 지표를 고른다. (허영 지표를 피하는 단계)
- 측정한다 — 정의·산식대로 데이터를 모은다.
- 분석해 통찰을 얻는다 — "이 숫자가 무엇을 말하는가, 어디가 가장 아픈가"를 해석한다.
- 개선을 실행하고 다시 측정한다 — 개선과제를 만들어 실행하고, 효과를 같은 지표로 확인한다.
여기서 통찰이 흩어지지 않게 잡아 두는 장치가 **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-05 | 1차 해결률 향상(지식베이스·권한 정비) | FCR 64% | 70% 이상 | 서비스데스크·8주 | 중간 |
핵심은 개선이 '느낌'이 아니라 '근거 지표가 있는 추적 가능한 과제'가 된다는 점입니다. 다음 달 보고에서 같은 지표를 다시 재면, 개선이 효과가 있었는지를 숫자로 답할 수 있습니다.
현장에서 자주 보는 함정
증상: 월간 운영보고에 KPI 표가 빠지지 않습니다. MTTR, SLA 준수율, 처리 건수가 매달 슬라이드에 뜹니다. 그런데 1년이 지나도 재발률은 그대로고, 같은 장애가 분기마다 반복됩니다. 보고는 "측정"에서 멈추고 "개선"으로 가지 않습니다.
원인: 지표를 보고용으로만 쓰고 행동용으로 쓰지 않았습니다. (1) 숫자만 있고 통찰("그래서 어디가 가장 아픈가")이 없거나, (2) 통찰은 있는데 그것을 잡아 둘 개선 등록부가 없어 매달 휘발됩니다. 게다가 처리 건수 같은 허영 지표가 슬라이드를 채우면, 진짜 아픈 곳(재발률·변경 성공률)이 가려집니다.
해결 방향(이 트랙·이 모듈의 핵심):
- 모든 KPI에 목표선을 긋는다 — 목표 미달 지표가 곧 개선 후보다.
- 미달 지표를 CSI 개선 등록부로 옮겨 담당·기한·목표를 못 박는다.
- 다음 보고에서 같은 지표를 다시 재 개선 효과를 숫자로 검증한다(닫힌 순환).
- 허영 지표(처리 건수)를 실행 지표(재발률·고객 영향 시간)로 교체한다.
- 단일 지표 집착(MTTR만)을 균형 묶음으로 바꿔 지표 조작을 막는다.
대시보드의 목적은 '예쁜 보고'가 아니라 '다음 행동의 결정'입니다. 매달 같은 숫자가 떠 있다면, 그건 안정된 게 아니라 개선이 멈춘 신호입니다.
심화 — 성적표를 쓰는 손: KPI가 계약·평가와 만날 때
심화: 자기 채점, 낮춰 부르는 목표, 그리고 평균 뒤의 그늘
KPI의 산식과 함정(허영 지표·조작)을 알아도, 한국 SI/SM 현장에서 지표가 굴절되는 더 큰 힘이 남아 있습니다 — 그 숫자가 누구의 돈과 평가에 연결되어 있고, 누가 집계하는가입니다.
- 자기 채점의 구조: SM 계약에서 KPI 실적을 집계·보고하는 쪽은 대부분 측정당하는 당사자인 운영사 자신입니다. 티켓 시스템도, 분류 기준의 해석도, 월간보고 장표도 운영사의 손에 있습니다. 조작이 아니어도 애매한 건은 유리한 쪽으로 분류되기 마련이고, 발주사는 검증할 데이터 접근권이나 인력이 없어 장표를 그대로 받습니다. 성숙한 발주사는 페널티를 올리는 대신 원천 데이터 접근권(티켓 시스템 조회 권한)과 표본 검증(분기마다 무작위 20건의 분류·시각 대조)을 계약에 넣습니다 — 채점자와 수험생을 분리하는 것이 지표 신뢰의 출발점입니다.
- 낮춰 부르는 목표(래칫 효과): 내년 목표가 "올해 실적 + 알파"로 정해지는 조직에서, 목표를 크게 초과 달성하는 것은 보상이 아니라 처벌입니다 — 내년 기준만 올라가기 때문입니다. 그래서 팀은 여력이 있어도 목표를 '적당히' 넘기는 수준에서 실적을 관리합니다. 목표 설정을 전년 실적이 아니라 사업 요구와 벤치마크(이 서비스가 필요로 하는 수준)에서 끌어와야 이 관성이 끊어집니다.
- 평균이 숨기는 그늘: "전사 SLA 준수율 96%"라는 한 줄 뒤에는, 매달 목표를 어기는 특정 서비스 하나가 다른 서비스들의 실적에 묻혀 있을 수 있습니다. 집계 단위가 클수록 보고는 편해지고 진실은 흐려집니다. 거버넌스가 봐야 할 것은 평균이 아니라 분포와 꼬리 — 최악 서비스, 최장 장애, 연속 미달 항목입니다.
- 보고 공수의 잠식: 월간 운영보고 장표를 만드는 데 팀 선임급이 매달 며칠씩 쓰는 조직이 흔합니다. 측정이 자동화되지 않으면 보고가 개선의 시간을 먹습니다 — 그래서 "KPI 집계 자동화"는 사치가 아니라 CSI 등록부의 1순위 후보 과제입니다. 보고에 드는 시간과 개선에 드는 시간의 비율이 그 조직의 성숙도를 말해 줍니다.
상황: 월간 운영보고에서 "측정만 하고 개선이 없다"는 지적을 받은 뒤 CSI 개선 등록부를 도입한 SM 조직입니다. 2년간 47건이 등록됐고 형식도 교과서적입니다 — 근거 지표, 목표, 담당, 기한까지 다 있습니다. 그런데 완료는 9건, 38건이 '진행중'이며 그중 절반은 기한을 1년 이상 넘겼습니다. 운영보고에서 재발률 지적이 나오자 팀장이 답합니다 — "그 건은 CSI-2025-08로 등록되어 관리 중입니다." 지적은 거기서 멈췄고, 다음 달에도 같은 문답이 반복됐습니다.
원인: 등록부가 추적 장치가 아니라 지적 회피 장치로 작동하고 있었습니다. '등록'이 곧 '대응 완료'로 인정되는 순간, 등록부는 개선을 미루는 가장 정중한 방법이 됩니다. 구조적 원인은 세 겹입니다 — ① 개선 과제에 자원이 배정되지 않았습니다. 과제는 운영 인력이 "장애 대응하고 남는 시간"에 하는 것으로 취급됐는데, 그런 시간은 없습니다. ② 완료의 정의가 없었습니다. "근본 원인 제거"가 언제 끝난 것인지 기준이 없으니 담당자는 닫지도 못하고 '진행중'에 방치합니다. ③ 우선순위가 없었습니다 — 47건 중 41건이 '높음'이었고, 전부 중요하다는 것은 아무것도 중요하지 않다는 뜻입니다. 거버넌스(방향설정)가 해야 할 선택을 아무도 하지 않은 것입니다.
진단: 등록부의 건강은 건수가 아니라 흐름으로 진단합니다. ① 과제 평균 체류 기간 — 이 조직은 14개월(건강한 조직은 분기 안팎). ② 등록 후 30일 내 상태 변경(활동 기록)이 있는 과제 비율 — 40%뿐이었고, 첫 달에 움직이지 않은 과제는 그 후로도 영원히 움직이지 않는 패턴이 확인됐습니다. ③ 근거 지표가 재측정된 과제 수 — 47건 중 4건. 즉 완료로 표시된 9건조차 효과가 검증된 것은 아니었습니다.
해결: 등록부를 '많이 담는 그릇'에서 '흐르는 파이프'로 재설계했습니다. ① 동시 진행 상한(WIP limit) 3건 — 새 과제를 시작하려면 기존 과제를 완료하거나 명시적으로 '중단' 처리해야 합니다. ② 등록 요건에 투입 공수(MM)와 임원 스폰서를 필수화 — 자원 없는 등록은 반려. 공수를 쓰는 만큼 월간 운영 계획에서 해당 인력의 티켓 배정을 줄였습니다. ③ 완료 = 근거 지표의 재측정으로 목표 도달 확인으로 정의(포스트모템의 재발 방지 검증과 동일한 원칙). ④ 6개월 무활동 과제는 '중단'으로 정직하게 닫고 사유를 기록 — '진행중'이라는 거짓말을 금지. ⑤ 운영보고 첫 장을 KPI 표가 아니라 **등록부 흐름(시작·완료·중단·체류 기간)**으로 교체. 1년 뒤 등록부에는 11건만 남았지만 완료 8건이 전부 지표로 검증됐고, 재발률은 22%에서 11%로 처음 움직였습니다. 47건의 목록보다 3건의 흐름이 운영을 바꿉니다.
발주사·원청의 IT 운영 담당, 서비스데스크·운영(SM) 관리자, PMO 자리에 서면, 당신이 매달 마주하는 의식이 월간 운영보고입니다. 한국 기업·공공기관의 운영보고는 대개 "지난달 무슨 일이 있었나"가 아니라 "약속한 수준을 지켰는가, 무엇을 개선하고 있는가"를 묻습니다. 그 자리에서 정성("열심히 했습니다")은 통하지 않습니다 — 임원과 발주처가 보는 것은 KPI 대시보드의 목표 대비 실적과 개선과제(CSI)의 진척입니다.
그래서 실무에서 관리자는 운영 KPI 표(지표·정의·산식·목표·실적)를 매달 갱신하고, 목표를 못 채운 지표를 **개선과제 관리대장(CSI 개선 등록부)**으로 옮겨 담당·기한·목표와 함께 추적합니다. 협력사(하도급) 엔지니어가 실제 복구·변경 작업을 하더라도, SLA 준수와 재발 방지에 대한 책임과 보고는 관리자의 몫입니다. 숫자로 말하지 못하는 관리자는 잘못된 보고에 속고, 숫자로 말하는 관리자는 발주처와 대등하게 다음 분기 우선순위를 협상합니다. 거버넌스(방향)·KPI(측정)·CSI(개선)는 그 협상 테이블의 공용어입니다.
실전 랩으로 손에 익히기: 거버넌스·KPI·CSI 실습 — 운영 KPI 선정·허영지표 경계·CSI 개선 사이클을 설계합니다.
관련 모듈로 더 깊이:
- 서비스 수준 관리 — SLA 준수율 같은 KPI의 약속 기준선을 정의하는 법
- 포스트모템 — KPI가 가리킨 문제를 재발 방지(CSI)로 닫는 회고 기법
- 공급자·협력사 관리 — 협력사 성과를 평가 지표로 통제해 거버넌스에 연결하는 법
다음 모듈에서는 ITSM의 '운영' 언어를 넘어, 정해진 기간과 범위 안에서 새로운 것을 만들어 내는 또 다른 관리의 세계 — Phase 5의 프로젝트 관리 입문을 다룹니다.