ITIL Reference 번역본

서비스관리를 위한 레퍼런스 요약집IT ITIL

목차

1. ITIL (INFORMATION TECHNOLOGY INFRASTRUCTURE LIBRARY) 의 개요?............................... 10

1.1. 개요 .................................................................................................................................................. 10

1.2. ITIL의 기대효과 ............................................................................................................................... 11

2. SERVICE SUPPORT의 개요 ................................................................................................................. 12

2.1. 서비스데스크 (기능) ........................................................................................................................ 12

2.2. 구성 관리 ......................................................................................................................................... 13

2.3. 인시던트 관리 .................................................................................................................................. 14

2.4. 문제 관리 ......................................................................................................................................... 14

2.5. 변경 관리 ......................................................................................................................................... 15

2.6. 릴리즈 관리...................................................................................................................................... 16

3. SERVICE DELIVERY의 개요 ................................................................................................................. 17

3.1. SLM (서비스 수준 관리) .................................................................................................................. 17

3.2. 가용성 관리...................................................................................................................................... 18

3.3. 용량 관리 ......................................................................................................................................... 19

3.4. ITSCM (IT 서비스 지속성 관리)...................................................................................................... 19

3.5. 금융 관리 ......................................................................................................................................... 20

4. 서비스데스크........................................................................................................................................... 22

4.1. 개념 .................................................................................................................................................. 22

4.1.1. 서비스데스크의 필요성 ............................................................................................................ 22

4.1.2. 현재 고객 지원상의 문제점..................................................................................................... 23

4.1.3. 콜 센터 ..................................................................................................................................... 23

4.1.4. 헬프 데스크 .............................................................................................................................. 23

4.1.5. 1.5 서비스데스크 ..................................................................................................................... 24

4.1.6. 기대효과 ................................................................................................................................... 24

4.1.7. 지원 서비스에 대한 비용부과 ................................................................................................. 24

4.1.8. 비즈니스 / 운영상의 기대효과 ................................................................................................ 25

4.1.9. 서비스데스크 역할 및 방향..................................................................................................... 26

4.1.10. 고객 인터페이스 ................................................................................................................... 26

4.1.11. 고객 및 사용자 통보................................................................................................................ 27

4.1.12. 현장 지원 .............................................................................................................................. 29

4.1.13. IT 인프라스트럭쳐 모니터링................................................................................................ 29

- 1 -

서비스관리를 위한 레퍼런스 요약집IT ITIL 4.1.14. 자동처리 인시던트................................................................................................................ 29

4.1.15. 서비스데스크 인시던트 전략 ............................................................................................... 30

4.1.16. 인프라스트럭쳐 모니터링 기대 효과................................................................................... 30

4.1.17. 인터넷기술의 이용................................................................................................................ 30

4.2. 서비스데스크 구축 ........................................................................................................................... 31

4.2.1. 프로젝트 팀원 구성 ................................................................................................................. 31

4.2.2. 서비스데스크 매트릭스 목표치 ............................................................................................... 31

4.2.3. 중요 고려사항 .......................................................................................................................... 32

4.2.4. 서비스데스크 구조 선정 .......................................................................................................... 32

4.2.5. 서비스데스크 구조의 종류 ...................................................................................................... 33

4.2.6. 지역 서비스데스크 ................................................................................................................... 33

4.2.7. 중앙집중 형 서비스데스크 ...................................................................................................... 34

4.2.8. 가상 서비스데스크 ................................................................................................................... 35

4.2.9. 서비스데스크 구성 시 고려요소 ............................................................................................. 36

4.2.10. ‘Follow the sun ‘기능 지원 .................................................................................................... 37

4.2.11. 인시던트 분류 작업 ................................................................................................................. 37

4.2.12. 분류 과정 검증 ..................................................................................................................... 38

4.3. 서비스데스크 기술요소.................................................................................................................... 38

4.3.1. 서비스데스크 전산화................................................................................................................ 39

4.3.2. 서비스데스크 전산화의 기대효과............................................................................................ 39

4.3.3. 자체 개발 또는 구매 선정 ...................................................................................................... 39

4.3.4. 멀티 플랫폼 환경 지원 ............................................................................................................ 40

4.3.5. WAN 지원................................................................................................................................. 40

4.3.6. 지능형 전화 시스템, 음성 메일, 이 메일 사용...................................................................... 40

4.3.7. 셀프서비스 도입 ....................................................................................................................... 41

4.3.8. 중요 성공 요소 (Critical Success Factor) ............................................................................... 41

4.3.9. 서비스데스크 아웃소싱 ............................................................................................................ 42

4.4. 서비스데스크의 책임, 기능, 지원요원 필요 수준 .......................................................................... 42

4.4.1. 서비스데스크 기능 ................................................................................................................... 43

4.4.2. 서비스 요청의 등록 ................................................................................................................. 43

4.4.3. 서비스데스크의 기능 강화 ...................................................................................................... 44

4.4.4. 에스컬레이션 관리 ................................................................................................................... 44

4.4.5. 서비스데스크 지원요원 수 ...................................................................................................... 46

4.4.6. 지원요원의 이직 시 고려사항 ................................................................................................. 47

4.4.7. 업무부하 모니터링 ................................................................................................................... 47

4.4.8. 고객만족도 조사 ....................................................................................................................... 47

4.4.9. 소규모의 조직에서 서비스데스크 운영................................................................................... 48

4.4.10. 2차 지원선의 지식 ............................................................................................................... 48

- 2 -

서비스관리를 위한 레퍼런스 요약집IT ITIL 4.4.11. 교육의 필요성 .......................................................................................................................... 49

4.4.12. 콜 수의 조절......................................................................................................................... 49

4.4.13. 업무 정의 .............................................................................................................................. 49

4.5. 서비스데스크 요원의 스킬 셋 ......................................................................................................... 50

4.5.1. 고객의 주요 요구사항.............................................................................................................. 50

4.5.2. 문제 해결 비율......................................................................................................................... 51

4.6. 서비스데스크의 환경 구축 .............................................................................................................. 51

4.6.1. 서비스데스크 환경 구축 시 고려사항 .................................................................................... 51

4.6.2. 서비스데스크의 제공 서비스를 정의 ...................................................................................... 51

4.6.3. 서비스데스크 릴리스 전 필요사항 .......................................................................................... 52

4.6.4. 서비스데스크 광고 ................................................................................................................... 53

4.6.5. 신속한 구축 (Quick Wins) ....................................................................................................... 54

4.7. 서비스데스크 교육 ........................................................................................................................... 54

4.7.1. 소프트 스킬 .............................................................................................................................. 54

4.7.2. 관리적인 측면 .......................................................................................................................... 55

4.7.3. 서비스데스크 요원 프로파일 ................................................................................................... 55

4.7.4. 서비스 요원의 책임과 역할..................................................................................................... 56

4.7.5. 고객 대응 기술......................................................................................................................... 56

4.7.6. 적극적인 경청 .......................................................................................................................... 57

4.7.7. 서비스데스크 요원 교육 .......................................................................................................... 58

4.8. 서비스데스크 프로세스 및 절차...................................................................................................... 58

4.8.1. 고려 사항.................................................................................................................................. 58

4.8.2. 체계적인 조사 기법 ................................................................................................................. 59

4.8.3. 상세한 고객 정보 정의 ............................................................................................................ 59

4.8.4. 고객 데이터베이스 유지보수 ................................................................................................... 60

4.8.5. 고객들에게 서비스데스크를 광고............................................................................................ 60

4.9. 인시던트 리포팅 및 검토................................................................................................................. 61

4.9.1. 효과적인 업무 부하 분석 ........................................................................................................ 62

4.9.2. 리포팅과 검토 주기 ................................................................................................................. 62

4.9.3. 서비스데스크 기록의 저장 ...................................................................................................... 63

4.10. 결 론 ............................................................................................................................................. 64

4.10.1. 중요 성공 요소 ..................................................................................................................... 64

4.10.2. 서비스데스크 구축 도움말 ................................................................................................... 64

5. 인시던트 관리 ......................................................................................................................................... 65

5.1. 인시던트 관리의 목적...................................................................................................................... 65

5.2. 인시던트 관리의 범위...................................................................................................................... 65

5.3. 기본 개념 ......................................................................................................................................... 67

- 3 -

서비스관리를 위한 레퍼런스 요약집IT ITIL 5.3.1. 인시던트 처리 .......................................................................................................................... 67

5.3.2. 제 1선, 2선 및 3선 지원 ......................................................................................................... 69

5.3.3. 기능적(Functional) 대 계층적(hierarchical) 에스컬레이션 ..................................................... 70

5.3.4. 우선순위 (Priority) ....................................................................................................................70

5.3.5. 인시던트, 문제, 알려진 오류 그리고 변경요청 사이의 관계 ................................................ 70

5.4. 인시던트 관리의 이익...................................................................................................................... 72

5.5. 계획과 실행...................................................................................................................................... 73

5.5.1. 타이밍 및 계획......................................................................................................................... 73

5.5.2. 핵심 성공 요인 (Critical success factors) ............................................................................... 73

5.5.3. 발생 가능한 문제 영역 ............................................................................................................ 74

5.6. 인시던트 관리 활동 ......................................................................................................................... 74

5.6.1. 인시던트 발견과 기록.............................................................................................................. 74

5.6.2. 분류와 초기 지원 ..................................................................................................................... 75

5.6.3. 조사와 진단 .............................................................................................................................. 78

5.6.4. 해결과 복구 .............................................................................................................................. 79

5.6.5. 인시던트 종료 .......................................................................................................................... 79

5.6.6. 소유권, 모니터링, 트래킹 그리고 커뮤니케이션 .................................................................... 80

5.7. 인시던트 관리 프로세스의 역할...................................................................................................... 81

5.7.1. 인시던트 관리자 ....................................................................................................................... 81

5.7.2. 인시던트 처리 지원 직원 ........................................................................................................ 82

5.8. 핵심 성과 지표 (KEY PERFORMANCE INDICATORS) ............................................................................ 82

5.9. 도구 .................................................................................................................................................. 83

6. 문제 관리 ................................................................................................................................................ 87

6.1. 문제 관리의 목표 ............................................................................................................................. 87

6.2. 문제 관리의 영역 ............................................................................................................................. 87

6.3. 기본 개념 ......................................................................................................................................... 88

6.3.1. 인시던트 관리와 문제 관리는 무엇인가................................................................................. 89

6.3.2. 문제 제어(Problem Control) ..................................................................................................... 89

6.3.3. 오류 제어.................................................................................................................................. 90

6.3.4. 예방적 문제 관리 ..................................................................................................................... 91

6.3.5. 주요 문제 재 검토 완료 .......................................................................................................... 91

6.4. 문제 관리의 이익 ............................................................................................................................. 91

6.5. 계획과 이행...................................................................................................................................... 92

6.5.1. 타이밍과 계획 .......................................................................................................................... 92

6.5.2. 성공 핵심 요인......................................................................................................................... 92

6.5.3. 위험요인 ................................................................................................................................... 92

6.6. 문제 제어 활동................................................................................................................................. 93

- 4 -

서비스관리를 위한 레퍼런스 요약집IT ITIL 6.6.1. 문제 확인과 기록 ..................................................................................................................... 94

6.6.2. 문제의 분류 .............................................................................................................................. 96

6.6.3. 문제 조사와 진단 ..................................................................................................................... 98

6.6.4. 문제 제어 팁 ............................................................................................................................ 98

6.7. 문제 제어 활동................................................................................................................................. 99

6.7.1. 오류 확인과 기록 ................................................................................................................... 100

6.7.2. 오류 평가................................................................................................................................ 101

6.7.3. 문제 해결 기록....................................................................................................................... 102

6.7.4. 오류 종료................................................................................................................................ 102

6.7.5. 문제 오류 해결 모니터링 ...................................................................................................... 103

6.7.6. 오류 제어 TIP ........................................................................................................................ 103

6.8. 예방적 문제 관리 ........................................................................................................................... 104

6.8.1. 경향 분석................................................................................................................................ 104

6.8.2. 예방조치의 목표 설정............................................................................................................ 105

6.8.3. 예방적 문제 관리에 대한 TIP............................................................................................... 106

6.8.4. 주요 문제 재조사 ................................................................................................................... 106

6.9. 지원기구에 대한 정보제공 ............................................................................................................ 107

6.9.1. 관리 정보 제공....................................................................................................................... 107

6.9.2. 정보의 홍수 ............................................................................................................................ 107

6.10. 매트릭스 ..................................................................................................................................... 107

6.10.1. 이러한 점과 관련한 관리 정보에는 다음과 같은 것이 있다........................................... 108

6.10.2. 정기 감사 ............................................................................................................................ 108

6.10.3. 매트릭스에 관한 TIP.......................................................................................................... 109

6.11. 문제 관리 내의 역할 .................................................................................................................. 110

6.11.1. 문제 관리자 ............................................................................................................................ 110

6.11.2. 문제 지원................................................................................................................................ 110

7. 구성 관리 .............................................................................................................................................. 116

7.1. 구성 관리 의 목적.......................................................................................................................... 116

7.2. 구성 관리의 범위 ........................................................................................................................... 116

7.3. 기본 개념 ....................................................................................................................................... 117

7.3.1. 구성 관리 계획....................................................................................................................... 117

7.3.2. 구성 요소 식별 및 CI............................................................................................................ 117

7.3.3. 구성 제어................................................................................................................................ 118

7.3.4. 구성 상태 기록....................................................................................................................... 118

7.3.5. 구성 요소 검증 및 감사 ........................................................................................................ 118

7.3.6. 구성 정보 기준선(Configuration Baseline) ............................................................................ 119

7.3.7. 구성 관리 Database (CMDB) ................................................................................................ 119

- 5 -

서비스관리를 위한 레퍼런스 요약집IT ITIL 7.3.8. 소프트웨어 및 문서 라이브러리 ........................................................................................... 120

7.3.9. DSL (Definitive Software Library) ........................................................................................... 120

7.3.10. 라이센스 관리 ..................................................................................................................... 120

7.4. 이익 및 발생 가능한 문제점.......................................................................................................... 120

7.4.1. 이익......................................................................................................................................... 120

7.4.2. 발생 가능한 문제점 ............................................................................................................... 121

7.5. 계획 및 구현 .................................................................................................................................. 122

7.5.1. 초기 계획................................................................................................................................ 123

7.5.2. 비즈니스 목표 따른 구현 접근 배치 및 구성 관리의 목적, 목표, 범위, 우선 순위에 대한

협의 123

7.5.3. 구성 관리자의 선임 및 구성 관리 팀 계획 ......................................................................... 125

7.5.4. 기존 시스템 분석 ................................................................................................................... 125

7.5.5. 구성 관리 계획 전개 및 시스템 설계 .................................................................................. 125

7.5.6. 구현을 위한 상세 계획 .......................................................................................................... 126

7.5.7. CMDB와 DSL 적용 ................................................................................................................ 128

7.5.8. 새로운 프로세스의 컷 오버................................................................................................... 129

7.5.9. 구현 관련 기타 고려사항 ...................................................................................................... 130

7.5.10. 비용 ..................................................................................................................................... 131

7.6. 활동 ................................................................................................................................................ 132

7.6.1. 구성 관리 계획....................................................................................................................... 132

7.6.2. 구성 요소 식별....................................................................................................................... 133

7.6.3. CI의 제어................................................................................................................................ 140

7.6.4. 구성 상태 기록....................................................................................................................... 144

7.6.5. 구성 요소 검증 및 감사 ........................................................................................................ 145

7.6.6. CMDB 백업, 기록, 및 관리................................................................................................... 146

7.6.7. 구성 관리 서비스 제공 .......................................................................................................... 146

7.7. 프로세스 제어 ................................................................................................................................ 147

7.7.1. 관리 보고서 ............................................................................................................................ 147

7.7.2. 핵심 성과 지표 (KPI)............................................................................................................. 147

7.8. 다른 프로세스와의 관계 ................................................................................................................ 148

7.9. 구성 관리 프로세스를 위한 도구 .................................................................................................. 151

7.9.1. 구성 관리 시스템 ................................................................................................................... 151

7.9.2. 소프트웨어 구성 관리............................................................................................................ 152

7.9.3. 변경 관리 및 릴리즈 관리 지원 ........................................................................................... 152

7.9.4. 구성 감사................................................................................................................................ 152

7.9.5. 엔터프라이즈 시스템 및 도구 ............................................................................................... 153

7.9.6. 다른 도구................................................................................................................................ 153

7.10. 신기술에 의한 영향.................................................................................................................... 154

- 6 -

서비스관리를 위한 레퍼런스 요약집IT ITIL 7.11. 구성 관리 가이드 ....................................................................................................................... 154

7.11.1. 제어 수준................................................................................................................................ 154

7.11.2. 버전 및 변형? ........................................................................................................................ 155

7.11.3. 구성 관리 도구의 선택 .......................................................................................................... 155

8. 변경 관리 .............................................................................................................................................. 163

8.1. 변경 관리의 목적 ........................................................................................................................... 163

8.1.1. 목적......................................................................................................................................... 163

8.1.2. Best practice ........................................................................................................................... 163

8.1.3. 프로그램/프로젝트 관리 및 변경 관리 ................................................................................. 163

8.2. 변경 관리의 범위 ........................................................................................................................... 165

8.2.1. 왜 변경이 중요한가 ............................................................................................................... 167

8.2.2. 인시던트 분석과 변경 관리의 경계 ...................................................................................... 168

8.2.3. 어플리케이션 개발과 변경 관리 ........................................................................................... 168

8.2.4. 비즈니스 변경과 변경 관리................................................................................................... 169

8.3. 기본 개념 ....................................................................................................................................... 170

8.3.1. 변경 요청................................................................................................................................ 172

8.3.2. 변경 자문 위원회 ................................................................................................................... 174

8.3.3. 변경 측정기준 ........................................................................................................................ 175

8.3.4. 변경의 사전 계획과 변경모델 ............................................................................................... 175

8.3.5. 아웃소싱과 변경 관리............................................................................................................ 177

8.3.6. 중요한 중지 계획 ................................................................................................................... 178

8.4. 이익, 비용 그리고 발생 가능한 문제 ............................................................................................ 179

8.4.1. 이익......................................................................................................................................... 179

8.4.2. 비용......................................................................................................................................... 179

8.4.3. 가능한 문제 ............................................................................................................................ 180

8.5. 활동 ................................................................................................................................................ 182

8.5.1. 운영 프로세스의 실행 계획................................................................................................... 182

8.5.2. 변경 사용과 여과 ................................................................................................................... 182

8.5.3. 우선순위의 할당 ..................................................................................................................... 183

8.5.4. 변경 분류................................................................................................................................ 183

8.5.5. CAB 회의 ...............................................................................................................................184

8.5.6. 영향과 자원 평가 ................................................................................................................... 185

8.5.7. 변경 승인................................................................................................................................ 186

8.5.8. 변경 스케쥴링 ........................................................................................................................ 186

8.5.9. 변경 구성, 시험, 실행............................................................................................................ 188

8.5.10. 긴급 변경 ............................................................................................................................ 189

8.5.11. 긴급 변경 구성, 테스트, 실행 ............................................................................................... 191

- 7 -

서비스관리를 위한 레퍼런스 요약집IT ITIL 8.5.12. 변경 검토 ............................................................................................................................ 192

8.5.13. 효율적이고 효과적인 변경 관리 프로세스의 검토 ........................................................... 192

8.5.14. 역할과 책임 ........................................................................................................................ 193

8.6. 계획과 구현.................................................................................................................................... 196

8.6.1. 변경 관리자 역할 ................................................................................................................... 196

8.6.2. 변경 관리 시스템에서의 결정 ............................................................................................... 196

8.6.3. 시스템 검토 계획 ................................................................................................................... 196

8.6.4. 실행 계획................................................................................................................................ 197

8.6.5. 견본......................................................................................................................................... 197

8.7. 측정기준과 관리 보고.................................................................................................................... 200

8.7.1. 승인을 위한 감사 ................................................................................................................... 201

8.8. 소프트웨어 툴 ................................................................................................................................ 203

8.9. 새로운 기술의 영향 ....................................................................................................................... 204

8.9.1. 비즈니스 범위 ........................................................................................................................ 204

8.9.2. 기술......................................................................................................................................... 205

9. 서비스 수준 관리 (SLM)...................................................................................................................... 207

9.1. 개요 ................................................................................................................................................ 207

9.1.1. SLM의 필요성 ........................................................................................................................ 207

9.1.2. SLM의 목표 ............................................................................................................................ 207

9.1.3. SLM의 범위 ............................................................................................................................ 207

9.1.4. SLM의 기본 개념 ................................................................................................................... 207

9.1.5. SLA 개념 ................................................................................................................................ 207

9.2. SLM 프로세스 ...............................................................................................................................209

9.2.1. SLM의 기대효과..................................................................................................................... 209

9.2.2. 비용 (Cost) ............................................................................................................................. 210

9.2.3. 장애 및 장벽 (Possible Problem & Barriers) ....................................................................... 210

9.3. SLM 프로세스 계획단계 (PLANNING THE PROCESS)....................................................................... 211

9.3.1. 최초 계획 활동 (Initial planning activities) ............................................................................ 211

9.3.2. 최초 서비스수준 인식 조사................................................................................................... 211

9.3.3. UC 및 OLA 계약 (Underpinning contracts and Operational Level Agreements) ................. 211

9.4. SLM 프로세스 구축단계 (IMPLEMENTING THE PROCESS)................................................................ 212

9.4.1. 서비스 카탈로그 작성 (Produce a Service Catalogue) ........................................................ 212

9.4.2. 기대치 관리 (Expecting Management).................................................................................. 213

9.4.3. SLA구조 계획 (Plan the SLA structure)................................................................................. 213

9.4.4. SLR설정 및 드래프트 SLA정의 (Establish Service Level Requirements and Draft SLA) ... 214

9.4.5. SLA 작성 ................................................................................................................................ 214

9.4.6. SLA 합의 ................................................................................................................................ 214

- 8 -

서비스관리를 위한 레퍼런스 요약집IT ITIL 9.4.7. 모니터링기능의 설정 (Establish 모니터링 Capability)......................................................... 216

9.4.8. 외부파트너와의 계약 및 OLA 검토 (Review Contracts & Operational Level Agreement) .. 218

9.4.9. 리포팅 기능 정의 및 절차 검토 (Define Reporting & Review Procedures) ........................ 219

9.4.10. SLA 공개............................................................................................................................. 219

9.5. 진행 프로세스 ................................................................................................................................ 220

9.5.1. 모니터링 및 리포팅 (Monitoring & Reporting) ...................................................................... 220

9.5.2. 서비스 검토회의 (Service Review Meeting).......................................................................... 220

9.5.3. 서비스개선 프로그램 (Service Improvement Program) ........................................................ 221

9.5.4. SLA, 외부파트너 계약, OLA 유지보수.................................................................................. 221

9.6. SLA 내용 및 중요 서비스수준 목표 (SLA CONTENTS & KEY TARGETS).......................................... 221

9.6.1. 새로운 서비스 적용방법 ........................................................................................................ 223

9.7. SLM의 유효성검증을 위한 중요 성능 지표 및 메트릭스 ............................................................. 223

- 9 -


1. ITIL (Information Technology Infrastructure Library) 의 개요?

1.1. 개요

“IT is the business” and “The business is IT”

ITIL의 정의는 다음과 같다.

! Business requirement를 위한 IT Service 배치

! 방법론이 아닌 Best Practices

! ITIL 프로세스의 적용은 조직으로 부터 조직으로의 변경, 즉 프로세스에 따른 조직의 변경을

의미

! 최상의 서비스를 제공하기 위한 최적의 비용을 제시

ITIL의 실체는 United Kingdom’s Office Of Government Commerce (OGC)에 의해 전 세계의 IT 서비스

관리 분야 프로세스의 Best Practice를 모아 정리한 책들의 묶음이며, 1980년대 후반에 만들어진 ITIL은

IT 서비스 관리분야에서 전 세계적인 “de-facto”표준으로 IT 서비스를 지원 구축, 관리하기 위한 일련의

IT서비스 관리 “Best Practice”로 고객에게 Enterprise 기업이 고객에게 고 품질의 IT 서비스를 제공함으

로써 비즈니스 목표를 달성할 수 있는 기반을 제공한다.

ITIL 프레임워크는 최초에 영국정부에 의해 만들어 졌으며 현재 전세계 많은 기업으로부터 그 유효성

및 효율성을 검증 받아 표준 IT 서비스관리 프레임워크로 사용되고 있으며 전세계 기업의 크기나 사업

분야에 관계없이 ITIL 프로세스를 구축, 사용 중이다.

과거에 많은 기업들의 IT 조직이 내부적으로 기술적 중심으로 업무를 집중하는 반면 현재의 IT조직은

비즈니스 조직의 요구 사항에 따라 IT 서비스 품질 향상에 역량을 집중하고 있으며 고객 지향적인 접

근 방식을 채택하고 있다.

즉, IT를 비즈니스로써 인식하고 관리하는 시대가 된 것이다. ITIL은 고품질의 IT 서비스제공에 초점을

맞추고 있으며 특히 고객과의 관계 (IT조직, 고객 및 파트너와의 포괄적 관계를 의미)를 중점적으로 다

루고 있다.

ITIL은 크게 2가지 영역으로 IT 프로세스 영역을 구분하고 있는데 첫 번째는 고객과의 서비스수준 계약,

계약에 따른 서비스 수준 모니터링을 정의하는 “Service Delivery”, 두 번째는 “Service Support”로

Service Delivery를 위한 운영 IT 프로세스를 정의한다.

Service Delivery와 Service Support의 각 모듈은 개별적으로 운영/적용 될 수 있는 것이 아니라 전체적

인 Process의 흐름과 순환으로 완성된다.

- 10 -

서비스관리를 위한 레퍼런스 요약집IT ITIL 기본적으로 ITIL은 ISO 9000 품질 시스템과 EFQM (European Foundation for Quality Management) 및

CMM (Capability maturity model) 과 깊은 관계를 갖고 있으며 IT 서비스 관리에 필요한 주요 프로세스

및 실천 모델 (Best Practice)를 제공함으로써 이러한 품질시스템을 지원하고 있다.

즉, ITIL 프레임워크 및 프로세스 모델을 채택함으로써 각 기업은 IT 서비스 관리 분야에서 ISO와 같은

품질 시스템에 대한 인증을 공인 받을 수 있으며 결과적으로 IT서비스에 대한 품질 및 비즈니스 중심

의 IT 프로세스 실천모델을 보유하게 된다.

서비스 관리의 3대 핵심 목표는 다음과 같다.

! 비즈니스와 고객의 현재와 미래의 요구에 맞게 IT 서비스를 배치

! IT 서비스 제공의 질 향상

! 서비스 제공에 대한 장기간 비용 절감

그림1.1 - Jigsaw diagram

1.2. ITIL의 기대효과

! 서비스 품질의 향상

! 서비스 품질 대비 IT 비용의 계량화

! 비즈니스, 고객 및 사용자 요구를 만족시키는 서비스 구현

! 주요 IT프로세스의 통합

! IT 서비스제공을 위한 조직 내 책임 및 역할의 정의 및 인식

! IT서비스 성능에 대한 지표화

- 11 -

서비스관리를 위한 레퍼런스 요약집IT ITIL 2. Service Support의 개요

“Service Support”영역은 IT 서비스 사용자가 비즈니스 관련 IT 서비스를 향상 받을 수 있도록 보장하는

데 필요한 관련 프로세스를 포함하고 있으며 다음과 같은 주요 프로세스를 포함하고 있다.

! 서비스데스크 (기능)

! 구성 관리

! 인시던트 관리

! 문제 관리

! 변경 관리

! 릴리즈 관리

그림 2.1 Service-Support Process 모델

2.1. 서비스데스크 (기능)

서비스데스크란 모든 ITIL 프로세스를 관리하는 수단 및 접점을 제공하는 Function이다. 고객(내부, 외

부)에게 인시던트 해결을 위한 단일 접점 (SPOC : Single Point Of Contact)을 제공하며 Business service

를 제공하기 위한 People, Process, Technology를 혼합하는 매개체이다.

서비스데스크에서는 모든 event의 처리에 대한 Time-Stamp가 기록이 되므로 어느 Step에서 Pending이

- 12 -

서비스관리를 위한 레퍼런스 요약집IT ITIL 오래 걸렸었는지 확인이 가능하며 Service level Agreement 에 따라 Time base 기준으로 monitoring,

communication, 요청사항에 대한 closing을 진행해 나갈 수 있다. 또한 Work-Order를 이용하여 커뮤니

케이션을 하며 업무 진행을 해 나가므로 Teamwork 및 의사 소통 향상을 가져올 수 있으며, 고객 접점

의 단일화 및 문제 처리 상태에 대한 관리로 문제 인지 및 해결 시간을 단축하여 고객 만족도를 증가

시킬 수 있다.

2.2. 구성 관리

IT 조직이 고객에게 최적의 비용에 최상의 서비스를 제공하기 위해 활용 가능한 Resource에 대해 파악

하고 관리하는 프로세스이다. Infrastructure 혹은 Item의 구성 요소는 CI (Configuration Item)으로 구분되

어 CMDB(구성 관리 Database) 에 정보가 저장되며, CI 정보의 Level과 Depth는 IT서비스제공에 있어

필요한 정보를 판별하여 기록하고 관리한다. 각 CI간에는 종속관계, 연결관계, 상호 보완관계에 대해

분석되어 Relation이 구성되며 비즈니스 환경에 맞게 설계된 CMDB를 근간으로 다른 ITIL 프로세스들

은 필요한 데이터를 이용하게 된다.

그림 2.2 – 구성, 변경 및 릴리즈 관리의 관계

- 13 -

서비스관리를 위한 레퍼런스 요약집IT ITIL 2.3. 인시던트 관리

인시던트란 서비스의 정상적인 수행을 방해하거나 서비스의 quality를 떨어뜨리는 이벤트를 말하며 인

시던트 관리의 목적은 정상적인 서비스 제공을 위해, 문제 사항에 대한 빠른 해결 및 비즈니스 수행에

대한 반대 급부로 인한 충격을 최소화 하는 것이다.

각 인시던트는 우선 순위가 정해져 관리 되며 우선 순위는 Impact와 Urgency 메트릭으로 중요도를 결

정하게 된다.

인시던트에 대한 모든 정보는 CMDB에 저장되어 관리되며 문제 관리와 변경 관리, 릴리즈 관리 프로

세스로 연결되기도 하며, SLA따른 SLM의 근간이 되는 장애 데이터를 제공하게 된다.

그림 2.3 - 인시던트 관리 프로세스

2.4. 문제 관리

문제 관리의 목적은 IT Infrastructure의 장애로 인해 발생 가능한 비즈니스의 Impact를 최소화 하며 비

즈니스에 영향을 끼치는 인시던트 발생의 반복을 억제하는 것이다. 발생한 장애에 대해서는 원인을 아

직 알 수 없는 단일, 혹은 복수의 인시던트를 의미하는 Problem과 문제의 root cause의 진단에 성공하

여 문제 사항의 상태가 정의된 Known error로 구분되며, Known error의 경우 동일 장애 발생 시

Knowledge DB를 바탕으로 빠른 장애 처리를 하여 장애 처리 시간을 최소화 하며 Infrastructure 혹은

개별 Object의 변경을 통해 root cause가 해결될 것이라고 판단되는 경우에는 변경 관리와 더 나아가

릴리즈 관리로 연결되게 된다.

- 14 -


그림 2.4 - 인시던트- 대조 프로세스 플로우

2.5. 변경 관리

변경이란 하나 혹은 하나 이상의 IT Infrastructure의 구성 요소의 새로운 상태에 의한 결과이며 기술적

인 변경이 아닌 프로세스와 관리적인 관점에서의 변경 관리를 의미한다. 변경 관리의 목적은 매일 발

생하는 업무와 변경 관련 인시던트에 의해 발생 가능한 충격을 최소화 하고 모든 변경 사항에 대한 즉

각적인 조종과 효율적인 처리 절차에 대한 표준화된 방법을 확립하는 것이다.

모든 변경의 시작은 RFC(Request For Change)를 통해 시작되며 변경 관리자에 의해 Filtering된 후 변

경 절차가 진행된다. 변경 관리자, 고객, 사용자 대표, 어플리케이션 개발자, 기술 조언자 등으로 구성

된 변경 조정 위원회는 (CAB: 변경이 Advisory Board) 변경에 대한 최종 Authority를 갖고 있는 의사

결정을 하게 된다. 변경 관리를 통해 고객은 다음과 같은 이익을 얻을 수 있다.

! 비즈니스 요구사항에 대해 IT Service를 보다 효율적으로 배치

! 변경 철회 사례 감소

! 사용자의 생산성 향상

! 큰 규모의 변경 사항에 대해 조정할 수 있는 능력 향상

- 15 -

서비스관리를 위한 레퍼런스 요약집IT ITIL 2.6. 릴리즈 관리

릴리즈 관리 는 IT서비스관점에서 보면 일종의 변경사항이며 릴리즈시 모든 사항 (기술적이든 아니든)

을 점검하고 확인하는 과정 이다. 릴리즈는 IT서비스에 대한 인가된 변경의 집합이며 RFC에 의해 정

의된다. 대표적으로 릴리즈는 서비스에 대한 장애해결 수와 품질개선으로 구성된다.

품질관리 및 테스팅을 통해 좋은 품질의 하드웨어 및 소프트웨어를 유지할 수 있으며 테 스트 및 프

로덕션 실 환경도 보다 안정적이고 일관성 있게 관리가 가능하게 되며 사전에 작성된 릴리즈 일정계획

은 고객의 기대치를 정의할 수 있게 해줍니다. 데이터에 근거한 변경관리 (Improved Historical Data

Concerning 릴리즈s) 는 소프트웨어 설치 및 하드웨어 변경과 같은 프로덕션 실 환경 변경사항에 대한

완벽한 감사 및 추적을 가능하게 하며 불법, 비인가 변경위험을 감소시킵니다.

그림 2.5 - 릴리즈 관리 및 변경 관리

- 16 -

서비스관리를 위한 레퍼런스 요약집IT ITIL 3. Service Delivery의 개요

그림 3.1 - Service Delivery processes

“Service Delivery”영역은 IT서비스제공자가 비즈니스 고객에게 충분하고 만족할만한 지원을 제공하기

위해 필요한 서비스 및 프로세스를 정의하고 있으며 다음과 같은 주요 프로세스를 포함하고 있다.

! 서비스 수준 관리

! 가용성 관리

! 용량 관리

! IT 서비스 지속성 관리

! 금융 관리

3.1. SLM (서비스 수준 관리)

SLM은 모든 IT조직이 비즈니스를 지원하기 위해 제공하는 IT 서비스를 정의하고 서비스수준의 충족여

부를 확인하기 위해 반드시 필요한 IT 프로세스이다. SLM 프로세스를 통해 관리 유지하는 SLA

(Service Level Agreement)는 IT조직의 성과를 측정하고 판단하는 구체적인 목표치를 제공하게 된다.

SLM의 목적은 IT 서비스수준에 대한 합의, 모니터링, 리포팅 및 서비스 개선 활동과 같은 반복적인

- 17 -

서비스관리를 위한 레퍼런스 요약집IT ITIL SLM프로세스를 통하여 IT 서비스 품질을 유지하고 개선하는 것이다. 이러한 SLM 프로세스는 반드시

비즈니스 및 비용적 요소와 연계 운영되어야 한다.

효과적인 SLM을 통한 서비스 중단시간의 절감 및 서비스 품질의 개선은 궁극적으로 상당한 재정적 절

감 효과를 가져오게 된다.

그림 3.2 - SLM process

3.2. 가용성 관리

가용성 관리 목적은 IT Infrastructure의 능력을 최적화 하기 위하여 목표를 달성하기 위하여 비즈니스를

가능하게 할 수 있는 서비스의 Availability의 지속적인 수준 유지 및 비용 효과를 얻는 것이다.

SLA에서 정의된 서비스 제공 가용성 대비 실제 제공된 서비스 시간을 계산하며 그러기 위해 각 장애

처리 Step에 대한 기록은 서비스데스크를 통해 CMDB에 저장되게 된다.

그림 3.3 - 인시던트 '라이프사이클' 확장

- 18 -

서비스관리를 위한 레퍼런스 요약집IT ITIL 3.3. 용량 관리

용량 관리의 목적은 효율적인 비용 제공을 통해 비즈니스 요구사항을 충족시키기 위한 현재와 미래의

용량계획이며 Cost 와 Capacity의 균형, Supply 와 Demand의 균형을 맞추는 것이 중요하다.

용량계획은 다음과 같이 관리 된다.

! Business 용량 관리

비즈니스 확장성을 고려한 서비스와 IT 자원의 용량 계획

! Service 용량 관리

고객에 의해 사용되는 IT 서비스의 운영 측면에서의 용량 계획

! Resource Capacity Mangement

IT 인프라스트럭쳐의 개별 구성 요소 측면에서의 용량 계획

그림 3.4 - 용량 관리

3.4. ITSCM (IT 서비스 지속성 관리)

ITSCM의 목적은 필수적인 IT 기술적 요소와 서비스 구성요소의 장애 시, 합의된 시간 안에 복구가 가

능하도록 하는 것이며 IT 서비스 복구계획은 중대한 장애를 복구, 대처, 방지하기 위한 계획 및 절차를

만들기 위한 체계적인 접근방법 이다.

ITSCM은 BCM (Business Continuity Management)프로세스중의 한 부분이며 BCM에 의해 파생된 정보

에 의존한다.

ITSCM은 비즈니스 측면에서 IT서비스의 지속에 초점을 맞추고 있다. 반면 BCM은 비즈니스를 지원하

는 모든 서비스를 포함하는 비즈니스의 지속에 초점을 맞추고 있다.

BCM은 조직 또는 기업이 사전에 설정한 최소 수준의 운영을 지속하기 위해 위험요소를 관리하는 것

에 초점을 맞추고 있다.

BCM 프로세스는 위험요소를 줄이고 비즈니스 복구에 대한 계획을 설정한다.

ITSCM의 범위를 결정하기 전에 비즈니스 현업과 IT서비스 공급자간에 결정 및 합의 되어야 할 최소

- 19 -

서비스관리를 위한 레퍼런스 요약집IT ITIL 비즈니스 필요사항이 있다. 이러한 필요사항에는 대체지역으로의 즉각적인 서비스이전에 대한 필요성

또는 일정기간이상의 장애 시 서비스 구성요소의 복구 필요조건 등을 정의한다.

비즈니스 현업은 이런 사전 사항을 완벽히 이해, 정의 및 합의해야하며 ITSCM은 BCM의 한 부분으로

이러한 필요사항을 제공하기 위한 가장 효율이고 유효한 방법으로 사용할 수 있음을 이해하여야 한다.

그림 3.5 - Business Continuity Management Process Model

3.5. 금융 관리

금융 관리는 조직의 재정 자원의 직무와 같이 들리지만, 이는 비즈니스 목표와 요구를 받아들여 계획

하고 실행하고 있는데 있어 최소한의 손해와 최대 효과를 얻기 위한 비용을 관리를 의미하는 것이며

특히, IT 서비스 제공에 대한 비용관리를 의미하는 것이다.

Financial 부분은 IT부서 단독으로 관리 할 대상은 아니며 조직의 재무 부서와 긴밀한 협조를 통하여

진행되어야 하는 부분이다.

IT 조직은 3개의 주요 프로세스를 통해 IT 서비스의 금융 관리를 수행한다.

! Budgeting: 예산 계획은 조직내의 비용 지출을 제어하고 예견하는 프로세스이며 주기적인 협

의를 통해 (일반적으로 일년에 한번) 예산을 수립하며 현재의 예산 대비 비용 집행에 대해 일

상적으로 모니터링을 수행한다.

! IT Accounting: IT 조직이 실제 비용 집행을 하기 위한 프로세스이다. (특히, 고객에 의해, 서비

스에 의해, 활동에 의해 사용된 비용으로 분류된 비용 집행을 위한)

! Charging: 고객에게 서비스 비용을 청구하는 프로세스, 상세한 분석을 통해 비용을 청구하고,

이에 대해 보고하는 프로세스이다.

- 20 -


그림 3.6 - IT Accounting, Charging and Budgeting cycle

- 21 -

서비스관리를 위한 레퍼런스 요약집IT ITIL 4. 서비스데스크

본 장에서는 IT 조직에서 서비스데스크의 기능과 조직위치에 대해 알아 보고자 한다. 이 글에서 기술되

는 가이드라인, 절차 및 프로세스는 절대적인 것이 아니며 모든 IT 조직에 적용할 수 있는 것은 아니다.

본 장에서는 기술하고 있는 IT 서비스데스크내용은 다음과 같다.

! 개요

! 서비스데스크 구축

! 서비스데스크 기술

! 서비스데스크 기능, 책임 및 인원

! 서비스데스크 담당자의 필요자격 요건

! 서비스데스크 적용

! 서비스데스크 프로세스 및 절차

! 인시던트 레포팅 및 검토

! 결론

ITIL의 다른 프로세스와 달리 서비스데스크는 “프로세스”가 아닌 “기능”으로 IT 서비스관리를 위한 가장

중요한 기능적 역할을 수행한다. 그러한 중요성 때문에 본 책자에서 가장 먼저 소개하고 있다. 서비스

데스크는 고객과 IT서비스간의 접촉창구로 인시던트에 대한 통제/조정역할을 수행한다.

4.1. 개념

4.1.1. 서비스데스크의 필요성

회사에 대한 고객의 지속적인 요구사항의 증가와 다국적 기업화 추세와 따라 세계 최고의 서비스 제공

여부가 결과적으로 기업의 실패 또는 성공을 좌우하는 시대가 되었다. 따라서 기업간의 경쟁우위 확보

가 중요 이슈 사항이며 그 시작은 고객의 비즈니스를 명확하게 이해하고 고객이 원하는 서비스를 제공

하면서 비롯된다.

고객의 사업목표 달성을 위해 고객과 고객의 전산자원에 대한 고품질의 지원이 반드시 필요하며 “서비

스데스크”는 그러한 지원서비스를 위해 필수적인 요소이며 비즈니스의 성패와 밀접한 관련이 있다.

고객이 장애나 불만을 갖게 되면 신속한 조치를 원하게 되며 고객이 원하는 수준의 조치를 빠른 시간

안에 해주는 것이 점점 중요하게 된다. 고객의 전화가 정확한 담당자를 찾지 못해 빙빙 돌거나 해당

담당자가 식사 중이거나 휴일이어서 조치가 안 되는 경우보다 더 열 받는 일은 없을 것이다

- 22 -


그림 4.1- Service-Profit Chain model

4.1.2. 현재 고객 지원상의 문제점

많은 지원 부서들이 서비스품질 개선 및 비용절감에 대한 압박을 받고 있다. 대부분의 지원부서가 수

동적인 고객지원을 하거나 또는 대부분 지원시간을 장애처리에 시간을 소비하는 실정이다.

많은 기업의 현 상황은 다음과 같다.

! 체계적인 고객 지원 시스템이 없음

! 지원인력에 대한 관리 및 교육 부족

! 고객인지도 부족

! 비효율적인 고객지원시스템

! 사후 장애처리 위주 시스템

! 동일장애의 반복적 발생

! 특정 지원에 인력에 편중

! 이력관리 부족

! 변화에 대한 대처능력 부족

! 불 명확한 지원인력 역할

! 전화응대 Skill 부족 및 해결시간 지연

4.1.3. 콜 센터

콜 센터는 전문적으로 대규모의 비즈니스 콜을 처리하는 기능으로 주로 전화를 이용한 고객응대 및 상

품에 대한 거래를 담당한다

4.1.4. 헬프 데스크

헬프 데스크의 근본 목적은 가장 빠른 시간 안에 인시던트를 해결하는 데 있으며 인시던트 콜이 누락

되거나 무시되는 일이 없도록 해야 한다.

- 23 -


4.1.5. 1.5 서비스데스크

서비스데스크는 제공서비스의 범위를 IT 서비스관리 프레임워크 내에 있는 비즈니스 프로세스 관리까

지 확장해서 지원한다. 즉, 인시던트, 장애 및 고객의 질의 응대 뿐만 아니라 고객의 변경요청, 유지보

수 계약, 소프트웨어 라이센스, 서비스수준관리, 구성관리, 가용성 관리, 비용관리 등까지 지원한다.

많은 콜센타 및 헬프데스크가 자연스럽게 서비스데스크로 진화하여 고객에 대한 서비스 품질을 개선하

고 있다.

서비스데스크, 콜센타, 헬프데스크의 공통적인 특징은 다음과 같다.

! 고객과 내 외부 사용자에 대한 대표성

! 고객만족이 주요 목표

! 고객응대 및 고객에게 필요한 서비스를 제공하기 위해 조직, 프로세스와 필요기술을 조정

4.1.6. 기대효과

서비스데스크는 고객, 사용자, IT서비스, 외주용역업체간 필수적인 접점이다. 그리고 이러한 서비스데스

크를 지원하는 비즈니스 원동력은 SLM (Service Level Management)이다.

서비스데스크가 IT조직에 제공하는 기대효과와 가치는 다음과 같다.

! 전산자원을 지원하는 데 필요한 소요비용을 절감하기 위한 중요역할을 수행

! 비즈니스, IT 기술, 프로세스에 대한 변경사항을 통합할 수 있으며 효과적으로 관리

! 인적자원과 IT기술요소를 효과적으로 사용하여 비용을 절감

! 고객만족과 장기간 고객만족을 유지하는 효과

! 비즈니스 기회를 창출

전략적인 관점에서 서비스데스크는 고객을 위한 가장 중요한 역할을 수행한다. 많은 경우에 서비스데

스크는 서비스차원에서 기업의 모든 조직과 부서가 공유하는 유일한 인터페이스이며 이를 통해 모든

직원은 “항상 고객과 고객만족을 생각하는 문화”를 가질 수가 있다.

또한 서비스데스크를 통하여 다음과 같은 중요 관리정보를 얻을 수 있다.

! 인적자원 사용율

! 서비스 개선사항

! 서비스 성능 및 목표 달성

! 고객 교육의 필요성

! 관련 비용

과연 서비스데스크가 대규모의 조직에 적합한지를 의문시하는 경우가 있다. 서비스데스크는 조직규모

에 관계없이 큰 이점을 제공한다.

4.1.7. 지원 서비스에 대한 비용부과

서비스데스크를 설계할 때에는 소요 비용을 고려하는 것이 중요하며 더욱이 비용 회수가 필요한 경우

- 24 -


에는 더욱 중요하다.

정의된 비용부과정책에 따라 서비스데스크의 사용에 대한 비용과 정보를 수집하여 회계시스템에 전달

하여야 한다.

그러나 현실적으로 비용부과정책을 사용하는 것보다는 오히려 단순화하여 비용을 균등하게 분할해서

모든 고객에게 비용을 부과하는 방법이 더 좋은 방법이 될 수도 있다.

이러한 빌링 방식은 다음과 같은 방법에 의해 가능한다.

! 서비스 / 인시던트 종류별 콜 비용

- 데스크 탑 서비스

- 어플리케이션

- 설치 및 업그레이드

- 비즈니스 서비스 (예 : 인사)

! 서비스 요원이 사용하는 물적 자원 및 시간비용

- 시간단위 (일, 분 등)당 단가

- 고정비용

- 지원시간

! 제공받는 서비스 등급

- gold 서비스 수준

- silver 서비스 수준

- bronze 서비스 수준

! Overhead 비용

! Free 서비스

주의사항

콜 당 비용을 부과하는 것은 고객이 서비스데스크를 우회하거나 또는 직접 해결하고자 하는 경우를

발생 시킬 수 있다. 이런 경우 결국 진단 또는 해결시간이 길어지거나 인시던트가 복잡해지는 악영향

을 가져 올 수도 있다

4.1.8. 비즈니스 / 운영상의 기대효과

결과적으로 서비스데스크를 채택하면 비즈니스와 서비스제공상의 다음과 같은 이점을 기대할 수 있다.

! 고객서비스 개선, 인식 및 만족도 향상

! 접촉, 대화, 정보제공 창구 단일화로 고객 접근성 향상

! 고객요구에 더 빠른 대응을 할 수 있으며 좋은 품질을 제공

! 팀워크 및 의사 소통 개선

! 비즈니스에 대한 악영향 감소

! IT 지원 요원의 활용도와 현업요원 생산성 향상

! 의사결정을 위한 유용한 관리 정보의 제공

- 25 -


4.1.9. 서비스데스크 역할 및 방향

현대의 서비스데스크의 기능은 고객접촉기능 및 현업부서 또는 비즈니스를 대신하여 서비스 개선의 목

표에 초점을 맞추고 있다. 운영적인 관점에서 보면 그 목적은 고객과 사용자에게 신속한 서비스복구,

도움, 권고 안을 주기 위한 단일접촉창구의 역할을 수행한다.

예전에 기술 지향적이거나 서비스데스크를 하나의 장벽으로 여기던 IT부서는 점차적으로 사라지고 있

다. 이러한 개념은 점점 고객 중심의 서비스 팀으로 변화되고 있다.

이러한 서비스 팀은 기술 전문가와 비즈니스를 이해하며 협상 및 대화능력과 폭 넓은 기술적 도구를

보유하고 있는 사람들로 구성된다.

이러한 새로운 개념의 서비스 전문가는 모든 비즈니스에 확장된 서비스를 제공하고, 통합된 형태의 수

입원을 창출하는 비즈니스 활동을 하며, IT부서를 넘어서 서비스의 모든 측면을 다루는 능력을 보유한

다.

4.1.10. 고객 인터페이스

근래에는 고객의 인터페이스의 중요성이 가시화됨에 따라 더 이상 전화나 일대일 직접 접촉에만 의지

하지는 않는다. 적극적으로 고객의 요구사항을 등록하고 지속적으로 변경사항을 갱신하고 질문함으로

써 서비스 품질은 크게 향상되고 고객과 사용자의 만족도도 높아질 것이다.

그 방법으로써 이 메일 또는 인터넷을 이용할 수도 있으며 심지어는 팩스도 좋은 도구로 이용 가능 하

다.

그림 4.2- 인시던트 등록 경로

- 26 -


이러한 수단은 다음과 같은 중요하지 않은 액티비티 또한 긴급하지 않은 인시던트에 가장 적합하다.

! 인시던트 제품 구매

! 어플리케이션 관련 문의

! 장비의 이동, 설치, 업그레이드 및 개선 요구

! 소모품 문의

이러한 방법을 통해 지원 팀은 다음과 같은 파생적인 효과를 기대할 수도 있다.

! 전화로 인한 불필요한 방해로부터 해방

! 업무량을 관리가능

서비스데스크 도구는 반드시 자동으로 고객 또는 사용자에게 유일한 ID를 제공함으로써 진행상황에 대

한 Online Query가 가능해야 한다.

4.1.11. 고객 및 사용자 통보

고객과 사용자에게 요청사항의 등록과 진행상황을 확인해주는 것은 서비스데스크의 가장 중요한 역할

중의 하나이다.

하지만 많은 조직이 서비스데스크 요원부족으로 이러한 작업을 수행하지 못하고 있다.

이러한 기능을 이메일과 같은 기능을 통해 대신할 수는 있지만 진짜 중요한 것은 고객과 개인적인 신

뢰를 쌓아 가는 것이다.

<확인 이메일 예제>

고객님 안녕하세요

고객님이 요청한 인시던트가 서비스데스크에 등록되었음을 알려드립니다.

등록 ID는 INC-22323이며 진행상황을 모니터링하기 위한 용도로 사용될 수가 있습니다.

할당된 서비스데스크 요원이 3월 11일 12:00시 전까지 연락을 드릴 예정입니다.

Reference ID INC-22323

설 명 레이져 프린터 동작 불능

사용자 이름 정종훈

위 치 ABC 빌딩 3F 구매부

전화번호 02-3272-1811

이메일 어드레스 [email protected]

완료예정시간 3월11일 오후 5:00

기타 다른 질문이나 요청사항이 있으시면 서비스데스크로 언제든지 연락바랍니다.

(서비스데스크 : 02-333-1111 )

감사합니다

이규호 / 서비스 지원 전문가

- 27 -

mailto:[email protected]


이와 같은 방법은 다음과 같은 모든 경우에도 가능하다.

! 문제해결을 위해 엔지니어를 필요로 할 경우

! 소프트웨어 업그레이드가 필요 시

! 요청사항이 완료되었을 때

! 설치일정이 잡혔을 때

! 더 많은 정보가 필요 시

<설치일정 확인 메일>

고객님 안녕하세요.

설치일정이 확정되었음을 알려드립니다.

ID는 CHG-22325이다. ID는 진행상황을 모니터링하기 위한 용도로 사용될 수가 있습니다.

Reference ID CHG-22325

위 치 ABC 빌딩 3F 개발부 807호

전화번호 02-3272-1811

이메일 어드레스 [email protected]

시작 시간 3월 14일 오전 09:00

완료예정시간 3월 14일 오전 12:00


(서비스데스크 : 02-333-1111 )

감사합니다


- 28 -

mailto:[email protected]


4.1.12. 현장 지원

고객 사이트에 방문할 때에는 방문 확인증을 통해 고객에게 상세내용을 통보하는 서비스가 필요하다.

특히 고객이 약속한 시간에 없었을 경우에는 더욱 필요하다.

<방문 확인 증>

고객님 안녕하세요

서비스지원 전문가가 인시던트 해결을 위해 방문했음을 알려드립니다.

Reference ID INC-23323

인시던트 해결여부 예 () 아니오 ()

일자/시간 2003년 3월 15일 09:20

증 상 프린트가 안됨

조치내역 장애발생 프린터 케이블의 교체

완료예정시간 3월 14일 오전 12:00


(서비스데스크 : 02-333-1111 )

감사합니다


4.1.13. IT 인프라스트럭쳐 모니터링

일반적으로 서비스지원의 역할은 장애발생시 알람으로 통보 받고 이벤트를 처리하는 식으로 진행된다.

그렇지만 대부분의 경우에 인프라 관련 인시던트는 고객에게 직접적인 영향이 가지 전에 발견하거나

또는 발생시 즉각 통보받는다.

이러한 역할을 자동화된 관리도구에서 수행한다.

규칙적으로 인프라스트럭쳐의 여러 측면을 모니터링하고 장애발생시 즉각적으로 인시던트를 발생시키

고 자동으로 해결하기 위해 서비스데스크로 전달된다.

4.1.14. 자동처리 인시던트

모니터링 되는 인시던트 중, 인시던트 발생 시 장애 해결 및 장애 통보를 위한 스크립트, 어플리케이션

혹은 Batch Job을 구동하는 인시던트를 의미한다. 예를 들어, 벡업 작업이 실패하였을 때, 인시던트는

자동으로 지원 시스템에 분류 및 우선 순위가 메겨져 서비스데스크에 등록되며 해당 담당자 혹은 작업

그룹으로 장애 사항을 자동 통보하는 것이다.

- 29 -


4.1.15. 서비스데스크 인시던트 전략

아래 그림은 “ 인프라스트럭쳐 서비스데스크 인시던트” 의 전략을 보여주고 있다.

그림 4.6 – 인프라스트럭쳐 서비스데스크 인시던트

인프라스트럭쳐에서 발생한 인시던트가 등록되면 적절한 사람에게 자동으로 전달된다. 만약 그러한 요

구가 수용되지 않을 경우 에스컬레이션 프로세스에 따라 서비스데스크에게서 액션을 수행한다.

4.1.16. 인프라스트럭쳐 모니터링 기대 효과

! 고객의 영향과 다운타임의 최소화

! 반복적인 수동작업의 자동화

! 분석용 관리정보의 자동취합

! 기 등록된 인시던트는 에스컬레이션 관리자에서 조정

! 서비스 데스트는 예방관리 역할도 수행

! 서비스 가용성과 사용율의 향상

! 운영인력비용 감소

4.1.17. 인터넷기술의 이용

인터넷 기술은 글로벌, 로컬 및 분산 환경의 서비스 관리 지원을 위한 많은 유용한 수단을 제공한다.

! 일반적 마케팅

! 긴급하지 않은 서비스요청을 이메일을 통해 해결

! 벤더제품의 프로그램 Fix 및 업그레이드 공급

- 30 -


! Known Error 공개

! 즉각적인 장애통보

! 관리현황 레포팅

인터넷을 통한 접근은 신중하게 고려하여야 하며 정책적으로 인가 받은 사람만이 접근할 수 있으며 바

이러스, 정규 라이센스등이 검증된 소프트웨어만이 접근할 수 있도록 하여야만 한다.

인터넷을 통한 자료의 퍼블리싱 및 수신은 합법적이며 정확해야 한다. 또한 저작권을 고려하여야 한다.

4.2. 서비스데스크 구축

정확하게 서비스데스크를 설계하는 것은 성공을 위해 매우 중요하며 반드시 명확한 권한과 책임을 부

여하고 비즈니스 목표 정의, 산출물 및 관리자의 승인을 득한 후에 정규 프로젝트 형식으로 진행해야

만 한다.

그러나 시작하기 전에 반드시 명심해야 하는 대전제는 서비스데스크 구축을 통해 달성하고자 하는 목

표를 명확히 하는 것이다.

서비스데스크 구축을 통하여 현재 운영하고 있는 방식을 재평가하고 새로운 방식을 도입하는 것이 필

요하다. 만약 현재의 수동적인 프로세스를 자동화하고 같은 방식이나 절차로 서비스요원을 운영할 생

각이라면 생각을 바꿔야 한다.

서비스데스크구축을 통하여 생산성 향상, 부가가치 창출, 비용 절감, 고객 인식 개선과 같은 효과를 기

대한다면 서비스데스크 구축과 동시에 관련 프로세스 및 상세 실행 안을 재설계해야만 한다.

4.2.1. 프로젝트 팀원 구성

서비스의 운영은 매일 수행되지만 프로젝트 성 품질개선활동은 매일 발생하는 것은 아니며 프로젝트

팀원의 구성도 프로젝트 초기에만 발생하는 것이 일반적이다.

서비스데스크의 구축은 단순히 기능적 구축이 아니라 서비스 개선 활동의 일환으로 생각하여야 하는

것이다.

서비스데스크 프로젝트 팀원을 구성 시에는 성공적인 프로젝트 구축을 위하여 필요 Skill을 고려하여야

하며 서비스 관리 및 구축기술을 보유하고 있어야 한다.

‘Business as usual’은 서비스개선 프로젝트로 인해 유지 관리될 필요가 없으며 이러한 사실을 고객에게

알리고 협의를 하기 위한 인력을 보유하는 것도 중요하다.

만약 필요 Skill을 갖고 있는 인력을 찾지 못하는 경우에는 인력 아웃소싱이나 또는 부서이동/타 프로젝

트에서의 착출 등과 같은 방법으로 내부 인력 교육을 통해 인력구성을 하는 것을 고려하는 것도 하나

의 방법이다.

4.2.2. 서비스데스크 매트릭스 목표치

우선적으로 서비스데스크의 유효성을 검증하고 평가하기 위한 서비스 메트릭스 목표치를 정의하여야

한다. 목표치 설정은 주의 깊게 정해야 한다. 왜냐하면 서비스데스크 구축 결과 검증 및 지속적인 검토

- 31 -


작업은 이러한 매트릭스 목표치 와의 비교이기 때문이다.

따라서 서비스데스크 관리도구 선정과 설계단계에서 메트릭스를 정의하는 게 좋다.

매트릭스 선정 시 가이드라인은 다음과 같다.

! 측정 가능한 메트릭스 정의

! 실효성을 위해 서비스데스크 구축 상세 설계단계를 고려해서 매트릭스를 관리할 것

! 고객과 SLA협의 전에 Baseline을 설정

! 일반적 SLA항목을 적용할 수도 있음

! 고객이 현재 하는 있는 일과 타당성을 반드시 인식하도록 할 것

SLA기준을 설정하기 위해 약 2달 정도의 데이터를 수집하여 기준을 정해야만 한다.

왜냐하면 변경하기 전에 현재의 자원으로 제공하는 서비스수준을 이해하는 것이 반드시 필요하기 때문

이다.

4.2.3. 중요 고려사항

서비스데스크를 구축할 때 반드시 고려해야 하는 중요사항은 다음과 같다.

! 서비스데스크의 비즈니스 필요성을 확실하게 정의하고 이해

! 상위 관리자의 지원 획득, 예산 및 구축을 위한 물적, 인적 자원의 할당 확인

! IT 서비스 운영지원 프로세스를 지원하는 솔루션의 확인

! 구축시간 단축요소(예를 들면, 고객과 구축내용 지속적 공유, 설치시간의 단축 등)를 정의하고

달성

! 명확하게 구축 목표와 산출물을 정의

! 모든 일을 한번에 하려 하지 말고 단순하게 시작하고 단계별 접근방식을 채택

! 중요사안에 대해서는 고객과 함께 협의

! 최종사용자와도 내용협의

! 지원부서에 기대효과를 설명

! IT 부서인원에 대해 서비스 중요성을 교육

! 새로운 서비스와 기대효과에 대해 고객 및 사용자에 대한 지속적 교육 실시

! 새로운 서비스에 대한 광고실시

4.2.4. 서비스데스크 구조 선정

결정할 서비스데스크, Skill수준, 조직구조의 종류는 몇 가지의 중요요소에 따라 의존적이다. 모든 것을

만족시킬 수 있는 범용적 구조는 없다.

비즈니스가 변하면 운영지원형태도 변경되어야 한다. 따라서 유연성이 미래의 성장에 가장 중요한 요

소이다.

- 32 -


4.2.5. 서비스데스크 구조의 종류

3가지 형태의 서비스데스크 구조가 있다.

1. 지역 서비스데스크

2. 중앙집중 형 서비스데스크

3. 가상 서비스데스크

4.2.6. 지역 서비스데스크

전통적으로 IT조직은 비즈니스에 따라 아래 그림과 같은 지역 서비스데스크를 갖고 있다.

그림 4.7 – 지역 서비스데스크

이런 형태의 서비스데스크는 지역적으로 복수의 서비스데스크가 필요하기 전까지는 실용적 형태의 서

비스데스크 구조이다.

만약 복수개의 지역 서비스데스크를 관리해야 하는 경우에는 운영 표준을 정립하는 것인 매우 중요하

다.

지역 서비스데스크 구조를 구축 시 고려사항은 다음과 같다

! 가능한 한 모든 지역적 위치의 서비스데스크에서 적용되는 공통의 프로세스 및 절차를 구축

! 타 서비스데스크에서도 가용한 Skill 공유

! 하드웨어, 소프트웨어 및 네트워크 인프라 스트럭쳐 호환성 검증

! 공통의 에스컬레이션 프로세스, 동일한 영향도, 심각도, 우선순위 및 상태 코드를 사용

! 상위 수준의 요청사항도 공통 레포팅 방법으로 처리

- 33 -


! 공통의 상위 관리자용 레포팅 매트릭스 사용

! 공통의 공유 가능한 데이터베이스를 사용

! 가능하면 자동으로 서비스데스크간에 서비스요청 콜이 전달되거나 에스컬레이션되는 기능 탑

재

4.2.7. 중앙집중 형 서비스데스크

이 구조는 모든 서비스 요청은 중앙위치의 서비스데스크로 기록된다.

그림 4.8 – 중앙집중 형 서비스데스크

조직구조가 지역적으로 복수개가 존재할 경우 중앙집중 형을 사용 할 경우 다음과 같은 비즈니스 기대

효과가 있다.

! 운영비용 절감

! 통합 관리 기능 가능

! 효과적인 가용 자원 사용

- 34 -


4.2.8. 가상 서비스데스크

서비스데스크가 물리적인 위치에 있을 경우 상당히 실용적이지 못할 경우가 있다. 이것은 네트워크 성

능과 통신의 발달 때문이다. 가상 서비스데스크는 전세계 어디에서나 접근 또는 사용이 가능한 개념을

채택하고 있다

그림 4.9 – 가상 서비스데스크

조직이 여러 곳에 사업장이 있을 경우 전세계 사업장에 대한 단일서비스 지원창구를 갖게 되면 다음과

같은 효과를 기대할 수 있다.

! 운영비용 절감

! 통합 관리 가능

! 효과적인 가용자원의 사용

그러나 가상 서비스데스크의 주요 운영상의 제한사항은 전문가 또는 그 역할의 엔지니어가 반드시 서

비스데스크에 있어야 한다는 것이다.

- 35 -


가상 서비스데스크를 구축할 때 다음과 같은 사항을 고려해야만 한다.

! 가상 서비스데스크를 이용하는 모든 사용자는 공통의 프로세스, 절차와 기술을 사용하여야 한

다.

! 공통의 합의된 언어를 데이터 입력 시 사용하여야 한다.

! 고객과 사용자들은 단일 접촉창구를 이용하게 되는 데 Global 전화번호와 한국 내 전화번호는

자동으로 서비스데스크로 전환되는 자동 호 전환 기술 (Automatic Call Distribution)을 이용하여

야 한다.

! 때때로 서비스 전문가 또는 유지보수 요원이 사이트에 있어야 하는 경우가 있을 수 있다.

! 네트워크 성능은 상황에 따라 적용되어야 한다. 이런 상황은 미래 수요량을 의미하며 예를 들

어 부산의 서비스데스크 처리 콜 량이 하루에 겨우 10건이면 네트워크 성능을 고려하지 않아

도 되나 1000건 이상이 되면 네트워크 성능은 주요 고려 요소가 된다.

! 서비스데스크 관리 도구는 업무량 분담 기능을 필요로 한다. 즉 부산의 서비스데스크가 부산

지역의 콜만을 담당하고 있으면 권한 부여 기능을 통해 부산지역의 콜만을 보여주도록 함으로

써 업무량을 조절할 수 있다.

! 이러한 권한에 따른 Viewing 의 분리기능은 타 프로세스, 변경관리, 구성관리 프로세스에서도

반드시 필요하다.

! 가상 서비스데스크에서는 반드시 인시던트에 대한 일관된 프로세스를 사용해야만 한다.

4.2.9. 서비스데스크 구성 시 고려요소

조직에 가장 적합한 서비스데스크 구성을 위해서 결정해야 할 기준은 상황에 따라 다르지만 아래 사항

은 필수사항 이다.

! 비즈니스 목표 및 결과

! 기존 지원조기의 수준 및 스킬 수준

! 예산, 비용 및 비용부과 방법

! 필요 관리정보의 수준과 품질

! 조직의 규모와 비즈니스 성격

! 정치적 고려요소

! 조직 구조

- 사업장 위치 (단일, 복수, 전 세계 위치 여부)

- 지원하는 고객 수

- 근무 시간

- 고객과 지원요원이 사용하는 언어

! 지원 어플리케이션의 수, 종류 및 범위’

- 표준

- 특정

- 맞춤형

! 일반적 비즈니스 요구사항

- 36 -


! 네트워크 구조

! 지원하는 하드웨어, 기술의 수, 종류 및 범위

! 인프라 교체주기

! 고객의 스킬 수준

! 사용자의 스킬 수준

! 지원 요원의 스킬 수준

! 지원 용원의 수 (1, 2차)

! 3rd Party 업체의 신뢰성

! 현재의 콜 볼륨

4.2.10. ‘Follow the sun ‘기능 지원

24시간 지원을 전 세계적으로 해야 하는 경우 아래 사항이 고려 되어야 만 한다.

! 통신장비(교환기 등)의 기능

! SLA에 time zone 지원사항 여부

! 관리자용 리포트의 타 시간대 가용여부

! 현지언어 지원여부

! 여러 언어 사용 요원의 필요성

! 문화적 차이 (예, 스페인의 경우 종종 근무시간이 오전, 빠른 저녁으로 분리되는 경우가 있음)

! 현지용 SLA와 OLA가 필요한지 여부

! 명확한 에스컬레이션 채널과 상위 보고 체계

! 가상 서비스데스크에서는 반드시 인시던트에 대한 일관된 프로세스를 사용해야만 한다

! 전 세계적으로 유일한 콜 ID를 부여할 수 있는 Prefix, Numbering 체계

4.2.11. 인시던트 분류 작업

분류 작업은 인시던트를 제대로 처리하기 위해 필요한 가장 중요한 일중 하나이다. 이런 분류작업은

다음과 같은 용도로 사용된다.

! 해당 인시던트와 연관 서비스나 장비를 정의

! SLA 또는 OLA와 연계

! 인시던트를 해결할 가장 적절한 전문가 선정

! 우선순위 및 영향도 정의

! 업무부하 정도 파악

! 질문내용과 점검 정보 선정

! 솔루션, Known Error, 해결 방안 등을 찾기 위한 조건기준으로 활용

! 최종 해결방안정의 및 요약

! 보고서 매트릭스 정의

최종 분류작업은 최초와는 다를 수 있다. 고객은 인시던트의 장애원인보다는 증상을 가지고 콜을 하는

경우가 많다. 또한 분류작업 수준은 분류 상세 정조에 따라 다르다.

- 37 -


예를 들어 워드 프로세스나 인사서비스와 같은 최상위 분류수준 다음과 같은 상세 분류정보를 필요로

한다.

! 버전 넘버

! 공급자

! 소프트웨어 모듈

! 그룹핑 (예, 비즈니스 어플리케이션, MIS 어플리케이션 등)

인시던트가 종료될 경우에도 종료 분류 또는 종료 코드를 사용하면 효과적이다.

이러한 종료분류에는 실제 원인, 요약정보, 액션의 과정을 기술하여야 만 한다.

! 성공적으로 종료한 인시던트

! 필요한 고객교육정보

! 검토가 필요한 문서

! 필요한 모니터링 항목

! 권고안

! 변경 요청

4.2.12. 분류 과정 검증

분류 작업은 중요하고 최신의 정보를 반영하기 위해 정기적으로 검토되어야 한다.

그러나 처음부터 너무 많은 분류항목을 추가해서 너무 복잡하게 만들면 안 된다. 지원요원이 인시던트

를 등록할 때 혼란을 일으킬 수 있기 때문이다.

또한 Unknown 또는 분류 불가능 같은 항목 추가를 권고한다. 왜냐하면 지원요원이 추측으로 분류하는

오류를 막을 수 있기 때문이다.

일반적으로 가장 이상적인 형태는 단순하게 시작하고 비즈니스 상 필요 시 확장하는 방안이다.

4.3. 서비스데스크 기술요소

많은 서비스데스크 관련 기술들이 있으며 성격에 따라 장점과 단점을 갖고 있다.

중요한 건 기술적 요소, 프로세스 및 서비스데스크 요원의 결합해야만 비즈니스 및 사용자의 요구사항

을 만족 시킬 수 있다는 것이다.

그리고 최근의 기술이라고 해도 검증되지 않은 기술은 피해야 한다.

서비스데스크 관련 인프라에 대한 투자는 장기적인 관점에서 이루어 져야 하며 가장 중요한 것을 알아

야 선정과 구축의 성공을 가져올 수 있다. 인프라는 대체하는 것이 아니라 서비스를 보완하고 개선을

위해 사용해야만 한다. 또한 비즈니스 프로세스를 지원해야 하며 현재와 미래의 요구를 반영하여야 한

다.

서비스데스크의 기술요소에는 다음과 같은 항목이 포함된다.

! 통합 서비스관리와 운영관리시스템

- 38 -


! 선진 통신 시스템 (예, 자동 전달 (auto-routing), hunt group, CTI, VOIP)

! IVR (Interactive Voice Response) 시스템

! 전자 메일 (예, voice, video, 이동 기기, 인터넷, 이메일 시스템)

! 지식 검색 / 진단 도구

! 자동 운영 도구 / 네트워크 관리 도구

4.3.1. 서비스데스크 전산화

많은 지원부서에서 처음에는 문서를 이용한 오프라인 형태의 시스템으로 개별적으로 기록, 갱신 및 해

결을 했다.

그러나 프로세스, 절차, 문서가 잘 정의되어 있더라도 인시던트를 기록하는 것 이상은 불가능했다. 왜

냐하면 해결 전까지는 추적이 불가능하기 때문이다.

전산화된 서비스데스크 도구의 이용은 현대의 서비스데스크 운영에 필수적인 요소가 되었다. 이러한

서비스데스크는 운영상의 효율성, 정확도를 향상시키고 과거의 해결책, Known Error, 콜 이력과 관리정

보를 빠르게 조회 가능토록 하여 준다.

그러나 이렇게 서비스데스크를 전산화하기 위해서는 상당히 많은 노력이 필요한 것도 사실이다.

오늘날의 선진 서비스 관리 시스템은 서비스 요청사항을 관리, 추적, 모니터링하고 계약상의 의무사항,

지원요원 관리 및 워크플로우 기능을 지원한다. 또한 다른 필수 서비스 요소 (예, 변경조정, 구성, 비용,

비즈니스 재해복구, 용량관리, 자동화 운영관리 도구)와 통합된다.

4.3.2. 서비스데스크 전산화의 기대효과

! 모든 지원 요원들이 시스템에 접근 가능하기 때문에 향후 발생일에 대해 인지

! 고객의 서비스 요청사항을 신속하게 처리가능, 효율성 측면에서 개선

! 서비스 요청사항에 대한 추적, 에스컬레이션, 워크 플로우 개선

! 온라인을 통해 더 많은/좋은 정보의 취득 가능

- Known Error, 해결책 및 서비스요청 이력

- 외부 지식 원

! 정확한 관리정보의 획득 가능

! 서비스 요청의 중복현상, 누락 등 방지

! 인적자원의 효율적 운영

! 복잡한 지원업무가 쉬어짐

4.3.3. 자체 개발 또는 구매 선정

자체적으로 개발할 건지 또는 소프트웨어 패키지를 구매할 건지를 결정할 때에 가장 중요한 것은

Reference가 있는지 또는 사용이유에 대한 정확한 조사가 필요 하다.

단순 콜 로깅, 갱신하는 도구는 아주 수월하게 구축하는 것이 가능하나 솔루션은 그렇게 쉽지가 않다.

아래 내용은 자체 개발 또는 패키지 구매를 선택하는데 도움을 줄 수 있다.

- 39 -


! 아래 사항을 설계할 서비스 관리 및 비즈니스 전문가가 있는가?

- 이 메일과 타 통신시스템과 통합

- 운영 자동화

- 다양한 OS지원 및 다국어 지원

- 자산관리, 구성관리, 변경 조정 및 운영자동화와 같은 타 프로세스관리도구와의 통합

! 시스템을 계획, 구축, 업그레이드, 유지보수 할 수 있는 인적 자원을 갖고 있는가?

! 개발에 소요되는 시간은? 개발 자금 출처는? 개발 가능시점은?

! 전문가가 퇴사를 할 경우는?

비즈니스 필요사항이 아주 특별하거나 유일하지 않으면 자체 개발은 비용이 많이 들고 효과를 단기,

중기에는 보기 어렵다.

4.3.4. 멀티 플랫폼 환경 지원

멀티 플랫폼 환경에서 소프트웨어를 선정 시에는 아래 요소를 고려하여야 한다.

! 보유 하드웨어, 네트워크 프로토콜 및 기반기술에서 필요기능을 제공하는가?

! 모든 환경에서 완벽한 기능을 제공하는가?

! 현재의 장비 (예, PC, 워크 스테이션)을 지원하는 가?

! 기능들이 필요 플랫폼 (예, 기본적으로 PC에서 운영될 경우, 현재 보유하고 있는 워크 스테이

션) 하에서 지원되는가?

! 타 플랫폼에서 운영되는 서비스데스크간에 완벽한 기능이 제공되는가?

4.3.5. WAN 지원

! 저속의 네트워크에서 운영이 가능토록 설계되었는가?

! 데이타 전송 최적화기능을 지원하는가?

! 성능은 상황에 따라 적용이 가능한가?

4.3.6. 지능형 전화 시스템, 음성 메일, 이 메일 사용

지능형 전화 시스템, 음성 메일, 이 메일 의 사용은 서비스데스크에 많은 이점을 제공한다. 그러나 그

것을 장벽으로 역으로 이용해서는 안 된다.

IVR (Interactive Voice Response)시스템을 구축하면 고객의 전화가 pass around되는 것을 방지할 수 있

다.

음성 메일과 이 메일 을 사용할 경우에는 정기적으로 내용을 확인하고 남겨진 메모에 대해 신속하게

응대를 해주는 것이 중요하다.

이러한 기술들을 효과적으로 이용하기 위해서 SLA를 도입하여 지속적으로 고 품질의 서비스가 가능하

도록 해야 한다.

- 40 -


4.3.7. 셀프서비스 도입

셀프서비스는 고객이 지원전문가의 직접적 개입 없이 소프트웨어를 이용하여 지원서비스를 받을 수 있

도록 할 수 있다. 결과적으로 고객 스스로 관리할 수 있고, 특히 서비스 근무시간 외 또는 그다지 중요

하지 않은 서비스요청사항에 대해 관리함으로써 운영비용을 줄이고 고객만족도를 향상시킬 수 있다.

셀프서비스를 가능하게 하는 도구는 인터넷, IVR, 무선 통신 등이 있다.

셀프서비스의 주요 특징은

! 고객이 직접 접근 방식을 결정

! 고객이 직접 정보 및 지식을 얻기 위해 접근

! 고객이 스스로 지원을 받기 위한 관리

! 쉽게 접근 할 수 있으며 빠른 해결책이 가능

! 요원 지원시간 절감

셀프서비스의 구축방법은 고객의 비즈니스 목표 및 서비스의 범위에 따라 달라진다.

! 고객이 직접 서비스 요청사항을 등록하고 진행할 수 있도록 구성

! 고객이 해결책 강구를 위한 정보를 검색할 수 있도록 구성

! 고객이 프로그램 갱신 또는 버그 Fix를 다운로드 할 수 있도록 구성

! 고객이 제품 또는 서비스를 구매할 수 있도록 구성

4.3.8. 중요 성공 요소 (Critical Success Factor)

성공적인 셀프서비스 모델을 위해서는 중요한 성공 요소가 있다.

! 상위 관리자의 지원

! 적극적인 관리권한의 이양: 고객이 셀프서비스를 수행 시 올바른 프로세스 및 도구를 사용할

수 있도록 프로세스를 잘 설계하여야 한다.

! 비즈니스 메트릭스 수집 및 사용: 제공되는 서비스의 유효성을 모니터링 하기 위해서 또한 어

떤 셀프서비스를 이용하는지, 얼마나 자주 이용하는지, 무엇 때문에 이용하는지를 아는 것은

매우 중요하다.

! 지원 프로세스의 유지보수: 기존 변경관리 및 Release관리 프로세스가 셀프서비스에서도 준수

되어야 한다.

! 사용이 쉽고 좋은 내용 보유: 고객이 원하는 시점에 편하게 접근하여 원하는 좋은 품질의 정

보를 얻을 수 없으면 셀프서비스는 무용지물이 된다.

! 커뮤니케이션: 고객은 셀프서비스를 사용 시 공식 채널, 지켜야 하는 책임, 또는 얻을 수 있는

가치는 무엇인지를 알고 싶어한다.

항상 고객과 사용자 중에는 셀프서비스 보다는 직접 지원 요원과 접촉을 선호하는 분들이 있다. 중요

한 것은 지원부서와 협의 방법에 대한 선택권을 부여하는 것이다. 따라서 전통적인 형식과 셀프서비스

를 혼합함으로써 좀더 효과적이고 비용을 절감할 수 있으며 고객 서비스 수준을 한 단계 높일 수 있다.

- 41 -


4.3.9. 서비스데스크 아웃소싱

서비스데스크를 아웃소싱 할 때에는 신중해야만 한다. 서비스데스크를 단순히 전체조직에 오버헤드로

보는 것은 아주 큰 손실을 초래 할 수 있다.

서비스데스크는 일종의 “ 당신의 조직이 고객에게 제공하는 전문화된 서비스의 창” 이다.

고객지원 시 지적 자산은 아주 중요한 비즈니스 자산이며 확실히 비즈니스상 필요가 없어지기 전까지

는 폐기되어서는 안 된다.

서비스데스크를 아웃소싱 계획시 또는 아웃소싱 할 때 고려 할 사항은 다음과 같다.

! 아웃소싱 업체가 동일한 서비스데스크를 도구를 사용하고 있는지 여부 – 지원 프로세스를 담

당하는 내부직원이 업체 변경 시 마다 재교육을 해야 하는 것을 방지

! 관리정보에 대한 접근권한은 유지

! 공급업체는 공휴일 또는 담당자의 병가 때에도 적절한 서비스 스킬 및 자격을 갖춘 서비스관

리 요원 제공

! 모든 자원요원의 과거 업무경험 및 상세내용을 검증

! 지속적으로 투자대비 효과, 산출물, 파생 비즈니스 효과 등을 모니터링

! 업체에 의존적인 항목을 주기적으로 검토 – 모든 절차, 기능, 프로세스가 확실하게 최근 것으

로 문서화되어 있는지

! 계약용어, 산출물, 비용부과내용 등 내용을 양자 명확하게 이해 및 합의

! 업체와 계약 협의를 할 때는 전문가 도움을 받을 것

4.4. 서비스데스크의 책임, 기능, 지원요원 필요 수준

서비스데스크의 목표

! 고객에게 단일 접촉 창구의 제공

! 고객의 비즈니스 악영향을 최소화하기 위해 합의된 서비스수준과 비즈니스 우선순위에 따라

장애서비스를 복구

서비스데스크의 책임과 역할은 비즈니스나 인프라스트럭쳐의 성격에 의존적이다. 대부분의 조직에서

서비스데스크의 주요역할은 고객서비스에 영향을 미치는 모든 인시던트를 기록하고 라이프 싸이클 관

리하는 일이다.

서비스데스크에서 신속하게 해결이 가능하지 않은 인시던트는 진단 및 해결을 위해 2차지원선 또는 3rd

Party 업체로 이관하여야 한다. 만약 SLA목표시간 내에 해결이 불가능한 경우에는 장애관리 프로세스

로 이관한다. 장애관리 프로세스에서 서비스데스크의 역할은 고객에게 진행상황을 알려주거나 계속 일

할 수 있는 해결방안을 권고하는 일이다.

서비스데스크는 단일 접촉창구로써 고유의 인시던트 넘버를 포함하여 서비스 팀이 관리하는 요청사항

- 42 -


이나 서비스 가용성에 대한 상태정보를 고객에게 제공하고 일은 매우 중요하다.

상태정보에 포함되어야 할 정보는 다음과 같다.

! 예상 종료시기

! 장비 이동 또는 설치 시기

! 새로운 Release 시기

! 서비스 개선 요청 수용 여부

! 정보 취득 처

! 전산시스템의 주말 가용여부

4.4.1. 서비스데스크 기능

! 콜 접수, 1차 고객 접촉 창구

! 인시던트와 고객의 불만사항 기록 / 추적

! 고객에게 요청사항에 대한 상태와 진행사항을 지속적으로 제공

! 요청사항에 대한 최초 평가, 해결 시도, 이관

! SLA에 따라 모니터링 및 에스컬레이션 절차 수행

! 종료 및 검증을 포함하여 인시더트 라이프 사이클 관리

! 단기적으로 사전에 계획된 서비스수준의 변경사항을 고객과 협의

! 2차 지원과 3rd Party지원그룹 Coordination

! 서비스 개선을 위해 관리정보와 권고안을 제시

! 장애 정의

! 고객 교육의 필요성을 부각

! 인시던트 종료 / 고객 확인

! 장애원인 파악에 도움

4.4.2. 서비스 요청의 등록

고객이 요청한 모든 인시던트와 질의사항, 이력과 해결책은 해결시간이 길고 짧음에 상관없이 반드시

등록되어야만 한다.

실제 경과 시간은 중요성 및 비즈니스 영향도의 척도는 아니다. 예를 들면

! 특정 분야에서 수년간의 경험을 갖고 있는 동료가 1분만에 문제를 해결했다. 만약에 장애를

분석하고 해결책의 과정 정보가 없었더라면 다른 동료는 동일 장애에 대해 다시 해결의 과정

을 겪을 것이다.

! 만약 고객이 제공 받은 서비스에 만족하지 못하고 “ 이번 주에는 장애가 너무 많아 “라고 불만

을 표시했다면 서비스데스크는 그러한 말에 대해 검증하여야 만 한다. 만약 검증하지 않는 다

면 서비스데스크의 신뢰도는 크게 평가 절하 될 것이다.

! 만약 고객이 콜의 진행사항을 물어 보는 데 등록되어 있지도 않다면 매우 당황스러울 것이며

서비스데스크 기능 및 신뢰성에 큰 상처를 입을 것이다.

모든 고객의 접촉은 고개의 요청사항을 이해하는 데 도움을 주는 가치 있는 메트릭스를 제공한다

- 43 -


4.4.3. 서비스데스크의 기능 강화

서비스데스크의 기능은 2차 지원선 및 3rd Party와의 서비스 수준 계약으로 기능적인 측면에서 강화할

수 있다. 따라서 2차 지원 선과 명확한 서비스수준 (SLA/OLA)합의가 필수적이다.

2차 지원선의 각 관리입장에 보면 직원들이 자체적인 프로젝트 마감시간이 있는 상황에서 서비스데스

크를 지원하기 위해 다른 일들을 포기 하는 것은 때에 따라서는 실용적이지 못할 수도 있다. 이런 경

우에는 2차 지원팀이 돌아가면서 서비스데스크를 지원하도록 권고한다. 만약 팀이 2명이라면 1명은 서

비스데스크를 지원하고 1명은 프로젝트 업무에 집중하면 된다.

이런 방법을 정착시키기 위해서는 서비스데스크는 2차 지원 관리자에게 전체 조직규모 예측을 위해 직

원사용현황 및 명확한 업무에 대한 정보를 제공하여야 한다.

4.4.4. 에스컬레이션 관리

Telephone Pickup Times

대부분의 조직에서는 고객의 전화를 특정 벨소리 횟수 (예, 3회내, 10회내)내에 받도록 하고 있다. 이러

한 횟수를 결정 짓는 것은 가용한 사람수에 의존적이다.

그러나 중요한 것은 그러한 횟수를 고객과 사용자와 협의하여 확실하게 정의하여야 한다.

따라서 셀프서비스는 전화 업무량을 크게 줄일 수 있으며 중요 인시던트를 조정할 수 있는 인적자원을

확보 할 수 있다.

그러나 이러한 횟수는 고객의 서비스 품질 인식에 아주 중요한 역할을 하게 되므로 정확하게 유지하는

것이 고객 만족에 매우 중요한 역할을 수행하게 된다.

Telephone Talk Times

전화상으로 고객의 인시던트를 처리하는 대 소요되는 시간은 가용한 지원요원과 스킬 수준에 따라 의

존적이다.

따라서 언제 2차 지원 선으로 인시던트를 이관할 건지 또는 타 지원부서로 이관할 건지를 잘 판단하는

것이 필요하다.

또한 주요 전화번호는 가능한 한 가용 해야 하며 특히 심각한 서비스 장애 시에 이용이 가능 하여야

한다.

따라서 대기 중 콜 정보를 알려주거나 최대 통화시간(예, 1-2분)을 설정함으로써 모든 인시던트를 신속

하게 처리할 수 있는 첨단 전화시스템을 통해 고객의 신뢰를 잃지 않도록 하는 것이 중요하다.

긴급한 고객의 요청 관리

이상적인 환경에서 보면 SLA는 비즈니스상의 요구사항 이다. 그러나 심각한 문제의 고객 콜이 발생했

을 때에는 가능한 한 신속하게 장애를 복구하는 것에만 관심을 갖게 된다.

- 44 -


고객은 중요한 견적서를 보내지 못하는 경우에 대한 압박감을 받을 수도 있으며 사용자를 기다리게 하

는 경우가 발생할 수도 있다.

이럴 경우에 개별적인 고객의 상황에 대해서 서비스데스크가 조사와 같은 작업이 진행되고 있다는 인

식을 주어야 한다. 이런 과정이 궁극적으로 제공 서비스에 대한 고객의 인식에 좋은 효과를 볼 수 있

다.

만약 고객이 서비스데스크에서 해결할 수 없는 일들을 요구할 경우에는 고객에게 정중하게 서비스관리

자에게 얘기하도록 유도해야만 한다.

Managing Service Breach

아무리 잘 운영한다고 해도 서비스 수준 위반은 발생한다. 예를 들어 특정 이벤트가 긴급한 처리를 요

한다거나, 지원요원이 병이 나서 출근을 못한다던가, 여유 부품이 없다거나 장애를 진단할 수 없는 경

우이다.

중요한 건 그러한 서비스 수준 위반이 발생했을 때 장애관리 팀에게 에스컬레이션 함으로써 성공적으

로 관리하는 것이다.

또한 고객에게 서비스 수준 위반의 가능성을 알리고 상황이 어쩔 수 없음을 상호 협의하여 합의된 서

비스수준 위반으로 유도할 수도 있다.

서비스수준 위반 합의 시 중요한 점은 다음과 같다.

! 사전에 고객에게 서비스수준 위반 가능성을 알리고 설명

! 서비스 관리자에게 통보 (서비스 관리자는 갑작스런 정보를 원하지 않음)

! 액션 과정을 합의하여 수행

! 위반이 발생했을 때는 이벤트를 문서화하고 이유를 서술

Managing Customer-initiated service breach

종종 고객이 Known Incident인데도 불구하고 충분한 정보를 알려주지 않아서 또는 고객위치가 네트워

크 접속이 불가능해서 서비스 수준 위반이 발생하는 경우가 있다.

이런 경우 명확하게 이 상황 때문에 진행할 수 없었던 일들이나 경과된 SLA상의 해결시간을 문서화는

것이 필요하다.

Recording service breach detail

상세하게 서비스 수준 위반 내용을 기록하는 것은 현재의 SLA의 실효성 여부를 판단하는 데 매우 중

요하다. 만약 IT 운영 시 계속해서 위반사항이 발생 할 경우에는 명확하게 SLA를 검토하고 변경이 필

요한 부분을 정의해야만 한다. 마찬가지로 고객에 의해 발생된 서비스 수준 위반에 대해서는 반드시

보고해야 한다.

- 45 -


4.4.5. 서비스데스크 지원요원 수

명확한 방법 없이 서비스에 대한 수요를 예측하여 풀 타임 서비스데스크 지원요원 수를 정의하는 것은

매우 어려운 일이다. 서비스데스크 요원 수는 비즈니스 요구에 따라 증감이 결정되며 다음과 같은 중

요기준에 따라 결정한다.

! 사용 가능한 비즈니스 예산

! 서비스에 대한 고객 기대 치

! IT 인프라스트럭쳐 및 서비스 카탈로그 규모, 사용 연수, 설계 및 복잡성, 예를 들어 하드웨어

및 소프트웨어 인시던트 수, 커스터마이징된 소프트웨어 vs 표준 상용 소프트웨어 등

! 지원할 고객 수와 다음과 같은 요소들을 고려

- 외국어를 사용하는 고객 수

- 스킬 수준

- 인시던트 종류

- 콜 종류 (예, 단순한 질의, 특정 어플리케이션 관련 문의 등)별 필요시간

- 필요 내 외부 전문가

! 인시던트 양

! 지원 시간

- 지원시간

- 시간외 지원

- 시간대

- 위치

- 지역간 이동시간

- 요원의 가용여부

! 요청 패턴에 따른 업무량 (예, 일일, 월말 등)

! SLA 정의 (응답 수준 등)

! 응답 방법 유형

- 전화

- 이 메일/팩스/보이스 메일/비디오

- 온라인 접근 / 조정

- 사람 파견

! 필요 교육 수준

! 가용한 지원 기술 (예, 전화 시스템, 서비스데스크 도구 등)

! 현재의 요원 스킬 수준

! 사용하는 프로세스와 절차

모든 항목은 반드시 지원요원 수를 결정하기 전에 신중하게 고려해야만 한다. 또한 문서화 되어야 하

며 서비스가 좋아지면 고객 수가 늘어난다는 것을 명심해야 한다.

- 46 -


4.4.6. 지원요원의 이직 시 고려사항

1차 지원 선은 전통적으로 이직률이 높은 것이 일반적이다. 따라서 필요한 인원과 교육을 검토할 때는

생산성과 빠른 적응력을 고려해서 선정해야만 한다.

Super User

이런 지원요원의 문제를 해결하기 위해 어떤 조직에서는 1차 지원이 필요한 장애 및 문의 사항을 해결

하기 위해서 “ 전문가 “ 고객을 이용하는 경우가 있다. 이 경우에는 주로 특정 어플리케이션 장애부분,

지역적 위치 또는 풀 타임 지원요원이 두기가 어려운 경우에 아주 좋은 해결책이 될 수 있으며 아래

사항을 적절하게 고려해서 조정해야만 한다.

! 명확한 고객의 책임과 역할 정의

! 명확하게 에스컬레이션 채널을 정의

! 표준 지원 프로세스 및 절차를 정의하고 사용

! 모든 요청사항을 기록하고 유지

메인 서비스데스크에 입력된 모든 서비스 요청항목을 통한 상세하고 유용한 사용기록은 내부 관리 팀

에게 전달하여 자원이 정확한 분야에 사용을 검증하도록 할 수 있다.

4.4.7. 업무부하 모니터링

앞에서도 살펴 보았듯이 업무의 부하 량을 세밀하게 관찰하여 필요한 요원의 스킬 수준을 정의하는 것

이 반드시 필요하다. 이러한 분석작업은 다음과 같은 항목을 반드시 포함하여야 한다.

! 서비스데스크가 관리하는 서비스 요청 수

! 지원 요원이 대부분의 시간을 소비하는 서비스 요청 종류

- 장비의 장애

- 비즈니스 어플리케이션 장애

- 통신

- 고객 문의

- 설치 및 업그레이드

! 아래 조직에 의해 해결시간이 오래 걸리는 형태의 서비스 요청사항

- 1차 지원선

- 내부 2차 지원선

- 3rd Party

- 공급자

! 가장 많은 지원을 받는 고객과 가장 많은 지원을 필요로 하는 분야로 나중에 고객과 서비스요

원을 교육시키기 위해 사용

4.4.8. 고객만족도 조사

제공서비스에 대한 고객의 인지와 만족도는 대부분의 지원의 성공과 직결되어 있다. 결과적으로 높은

가용성이나 트랜잭션 처리 수 보다는 서비스데스크가 고객을 만족시키는 지의 여부는 고객의 인지도에

- 47 -


달려 있다. 만족도 조사는 고개의 인지도와 기대치를 조사할 수 있는 아주 좋은 수단이며 강력한 마케

팅 도구로 활용될 수 있다. 그렇지만 성공을 위해서는 몇 가지 중요 요소를 반드시 고려해야만 한다.

! 조사의 범위를 결정

! 주요 대상을 결정

! 명확한 질문 결정

! 답변을 위한 쉬운 질문

! 주기적으로 조사 실시

! 고객이 효과를 이해하도록 확신

! 결과를 공표

! 조사 결과에 대한 액션을 실시

종종 조사 결과는 조직 내 또는 기타 다른 요인으로 변경횟수에 따라 비즈니스 결정으로 이어진다. 매

일 고객 만족도를 모니터링 하기 위해서는 고객의 서비스 요청의 종료 시에 서비스에 대한 고객 만족

도를 조사해야 한다.

조사 대상

명확하게 만족도 조사 대상자를 정의하고 질문의 범위를 정의하는 것이 중요하다. 예를 들면 제공 서

비스의 안정성에 관해 회계부서 담당에게 물어 봐야 하는 질문과 회계 관리자에게 물러 봐야 하는 질

문은 서로 다른 것이 될 수 있다.

담당자 입장에서는 프린터의 잦은 장애가 문제일 수 있지만 관리자에게는 고객 청구서를 제때 발급하

지 못하는 것에만 관심이 있을 수 있으며 그것이 결과적으로 재정적 손실로 이어 질 수 있다.

4.4.9. 소규모의 조직에서 서비스데스크 운영

소규모의 운영조직에서는 풀 타임 서비스데스크 지원이 필요 없을 수도 있다. 그러나 고객에게 단일

접촉 창구를 제공하는 것은 여전히 중요한 일이다.

따라서 다음과 방법으로 보완할 수 있다.

! 모든 지원 인원이 하나의 번호로 통화할 수 있도록 단일 전화번호 유지

! 일, 주 별로 담당업무의 순환

! 셀프서비스 기술에 투자

! 온라인 게시판 이용

4.4.10. 2차 지원선의 지식

많은 경우에 직원 교육을 통한 개발이나 타 지원그룹의 개입 없이 1차 지원 선이나 운영 지원 요원만

으로 서비스데스크 요원의 역할을 수행하는 것을 볼 수가 있다. 서비스데스크에서 2차 지원선의 투입

을 풀 타임이든 순환 방식이든 권고한다. 2차 지원 선은 일반적으로 운영 문서를 제공하고 변경사항을

수행하고 새로운 시스템에 대한 교육을 제공한다.

- 48 -


2차 지원선의 서비스데스크 참여를 통하여 다음과 같은 효과를 기대할 수 있다.

! 고객의 비즈니스 요구사항과 수요를 우선적으로 더 잘 평가

! 1차 지원선의 ‘ us and them ‘ 자세 최소화

! 2차 지원서의 전문화 지식을 서비스데스크 요원에 전파

! 전문가적인 관점에의 기술적 또는 절차적 문제점을 도출함으로써 잠재 장애요소를 밝혀내고

조치가능

서비스데스크의 2차 지원선 참여는 진정한 비즈니스 관점의 서비스를 제공하기 위한 첫 걸음이다.

또한 서비스데스크 요원이 직접 고객과 접촉하여 일할 수 있는 기회를 제공하기를 권고한다.

마지막으로 명심해야 할 사항은 고객의 요구사항에 대해 보다 잘 이해해야 한다.

4.4.11. 교육의 필요성

업무를 주의 깊게 모니터링 하면 고객, 사용자 및 지원 요원에 대한 교육의 필요성을 도출 할 수 있다.

효과적으로 고객과 사용자의 교육을 실시함으로써 콜 수와 서비스 요청 건수를 줄일 수 있으며 더욱

생산성이 높아 질 수 있다.

4.4.12. 콜 수의 조절

일반적인 조직에서는 단지 콜 수를 줄이는 것이 서비스데스크 도입의 직접적 비즈니스 효과로 여긴다.

그러나 처음에는 서비스데스크 도입으로 인한 서비스 개선으로 콜 수가 줄 수 있지만 시간이 지나면

점차적으로 다시 증가한다. 이것은 오히려 고객이 서비스데스크를 신뢰하기 때문이며 결과적으로 고객

이 더 자주 서비스데스크를 이용하게 되는 데 인시던트 콜 뿐만 아니라 도움 요청등과 같은 다양한 지

원요청이 발생하기 때문이다. 이런 사이클은 주의 깊고 지속적으로 모니터링 해야만 한다.

4.4.13. 업무 정의

고객지원업무를 얘기할 때 많은 지원부서는 다음과 같은 통계 데이타에 근거해서 결과를 측정한다.

! 기록된 인시던트 수

! 종료된 인시던트 수

! 합의된 시간 종료 후에도 오픈된 인시던트 수

! 합의된 시간 내에 해결된 인시던트 수

하지만 주어진 기간 내에서 서비스데스크에서 측정 가능한 Best Practice 수치는 다음과 같다.

! 고객이 등록한 인시던트 수와 종류

! 해결책이 도출된 비즈니스 장애 수

! 사전에 계획된 변경 수

- 49 -


4.5. 서비스데스크 요원의 스킬 셋

목표

! 서비스데스크에서 일을 하기 위해 필요한 지원요원의 프로파일을 설정

필요에 따라 서로 다른 형태의 서비스데스크가 있기 때문에 정확한 형태의 서비스데스크와 능력 있는

지원요원을 선정하기 위해서는 많은 신경을 써야 한다.

일반적으로 1차 지원선의 서비스데스크 요원은 고객으로부터 많은 압박을 받고 있으며 때로는 고개의

말도 안 되는 요구에 처하게 되는 경우도 있다. 그럼에도 불구하고 서비스데스크는 IT에 있어서 가장

중요한 역할을 수행한다.

많은 고객의 경우 서비스데스크를 하나의 서비스로 인지하고 있으며 중요한 IT기능의 고객만족 지표로

생각한다. 따라서 정확한 서비스데스크 지원요원에 대한 스킬 셋을 갖는 것은 서비스데스크의 성공뿐

만 아니라 전체적인 IT의 성공을 위해서 아주 중요하다.

서비스데스크에서 근무하는 지원요원의 프로파일은 4.6.1 서비스데스크 환경구축 고려사항에 명시된

사항을 우선적으로 고려해야만 한다.

이런 스킬은 책을 통해서 얻어 지는 것이 아니라 높은 수준의 교육과 관심을 통해 만들어 지는 것이다.

대인 관계 스킬은 서비스데스크요원에게는 필수적이며 고객의 IT 기능에 대한 인식을 좋게 하는 데 좋

은 기회를 제공한다.

따라서 고객 인터페이스를 잘하기 위해서는 얼마나 많은 기술 요원이 현재 스킬을 보유하고 필요교육

을 받았는지 확인해야 한다.

때로는 많은 지원부서에서 빠른 해결을 무조건 좋은 서비스라고 착각하는 경우가 있다. 어떤 경우에는

그런 경우도 있지만 항상 그런 것은 아니다. 중요한 건 등록된 인시던트가 전문적으로 처리되고 있다

는 정보를 제공하여 고객에게 확신을 심어 주는 일이다. 만약 그런 확신이 고객에게 없으면 직접 선호

하는 지원 전문가에게 전화를 해서 해결 하려고 하는 경우가 있을 수 있다. 또 다른 경우 아예 IT에 접

촉하지 않은 경우도 발생할 수 있다.

4.5.1. 고객의 주요 요구사항

서비스데스크에 대한 고객의 주요 요구사항은 다음과 같다.

! 단일 접촉 창구 제공

! 제공 서비스 수준과 시기 협의

! 요청사항의 우선순위 할당 결과 통보

! 요청사항의 진행과정 정보 제공

! 서비스 요청사항이 무시되거나 누락 없이 진행되고 있다는 확신제공

- 50 -


4.5.2. 문제 해결 비율

서비스데스크에서 직접 처리가 가능한 콜 수는 여러 가지 고려 사항에 따라 변동된다. 예상되는 콜 수

를 정하는 것은 안정적인 IT 환경이나 특정 분야에서나 가능하다. 예를 들면 서비스데스크가 모든 콜에

대해서 85 % 콜 해결 율을 목표로 하는 것은 현실적이지 못하며 차라리 상호 합의된 환경에서의 모든

회계서비스에 대한 85%의 콜 해결 율을 목표로 하는 것이 현실적이다.

이것은 결국 서비스데스크의 업무를 정확하게 이해하는 것의 중요성을 보여주는 것이다.

85% 콜 해결율을 만족 시키기 위해선 지원요원에 대한 교육이 필요하다. 만약 서비스데스크의 주요역

할이 주요 비즈니스 어플리케이션을 지원하는 것이면 지원요원에 대해 그 분야의 어플리케이션에 대해

상세하게 교육을 하거나 점검표와 Known Error에 대한 부가적인 자료를 숙지 시키는 것이 더 현실적이

다.

4.6. 서비스데스크의 환경 구축

일단 서비스데스크를 구축하기로 결정하면 지원요원이 근무할 서비스데스크 환경 구축을 고려해야 한

다. 단순히 책상과 전화만을 배치한다고 끝나는 것이 아니다.

고객이 서비스 센터를 방문했을 때 이미지는 서비스에 대한 고객의 인지도 형성과 서비스데스크요원의

콜을 다루는 성실성에 대한 인식을 주기 위한 중요한 요소이다.

많은 조직에서 서비스데스크를 고객에게 품질 있는 서비스제공을 보여주기 위한 수단으로 사용하거나

고객의 콜에 대응하는 방법이나 서비스 기능을 보여주기 위한 용도로 사용한다.

4.6.1. 서비스데스크 환경 구축 시 고려사항

! 가능하면 주요 지원부서와는 위치적으로 떨어진 공간에 다음과 같은 요건을 제공

- 고객과 지원요원을 위해 쾌적하고 편안한 공간

- 소음이 적은 환경

- 별도의 독립적인 공간

! 모든 제품, 하드웨어, 소프트웨어 문서, 고객용 참조자료 등을 위한 도서 비치

! 항상 최신의 서비스 카탈로그 유지

! 회의용 전화기와 무선 통신 세트를 구비

! 회의용 원탁 테이블과 의자를 준비

! 고객에게 주기 위한 음료수 준비

나라면 어떤 대접을 받기를 원할 것인가? 라는 질문을 통해 제공해야 하는 서비스 수준과 환경을 결정

하는 것도 좋은 방법이다.

4.6.2. 서비스데스크의 제공 서비스를 정의

비록 서비스 카탈로그가 서비스 수준관리의 한 부분이라 해도 그 기능을 이해하는 것은 효과적인 서비

스 구축을 위해 매우 중요하다. 서비스 카탈로그는 고객에게 제공하는 서비스에 대한 명세를 정의하며

이것을 통해 고객의 기대치를 정한다.

- 51 -


서비스로 정의하는 것은 비즈니스에 따라 선정해야 한다. 예를 들어 회계 서비스, 프린팅 서비스, 이

메일 서비스, PC 배당 및 설치 서비스 등이다.

전통적으로 전산부서는 각 IT의 구성요소 (예, 서버, 네트워크 등)별로 서비스를 정의하려 한다. 이런

서비스 정의 방법의 문제점은 이런 구성요소에 고객이 관심이 없다는 점에서 혼란을 발생 시킬 수 있

다. 구성요소에 따른 서비스 합의는 고객이 아닌 2차 지원 선간 또는 3rd Party와의 OLA (Operational

Level Agreement)에 의해 정의되고 유지된다.

비즈니스 어플리케이션 별로 서비스를 정의하여 얻는 중요 이점은 콜 등록 시에 즉시 담당자를 분류할

수 있으며 어떻게 조치를 취할 것인지를 알 수 있다는 것이다.

ITIL을 공통언어로 사용함으로써 지원요원은 서비스 요청을 분류한 내용을 별도의 번역 필요 없이 협

의가 가능하다.

4.6.3. 서비스데스크 릴리스 전 필요사항

서비스나 제품이 고객에게 제공되기 전에 아래 사항을 충분히 검증하는 것이 필요하다.

! 최신의 서비스 카탈로그 유지

! 최신의 프로세스, 절차, 문서

! 기술적 지원도구 (서비스데스크 도구, 이 메일, 지식 관리 도구)을 포함하여 서비스데스크 요

원을 필요수준까지 교육실시

! 새로운 서비스 도입 시 미리 제공하여야 하는 절차와 그에 따른 직접적인 효과

! 서비스 데스트 관리 팀에서 합의한 SLA/OLA

! 에스컬레이션 절차

! 고객 접촉 처

! 2차 지원 점검 항목과 Know Error 리스트

! 서비스 가용 계획

! 지원요원의 스킬 수준 리스트

! 상세한 3rd Party 지원 조직도

! 모든 상세한 Known bug와 Known error

! 3rd Party 연락처

! 3rd Party에게 모든 절차와 프로세스를 사전 인지 교육

! 3rd Party와의 상세한 유지보수 계약서

많은 조직에서 새로운 서비스 개발, 계획과 교육에 많은 돈과 자원을 투자한다. 그러나 그러한 새로운

서비스의 가장 중요한 산출물 중의 하나인 “지원”에 대해서는 종종 무시되거나 장애 후에나 추가 된다.

이것은 Release관리에서의 주요한 장애 원인이다. 반대로 새로운 서비스를 “비즈니스를 인식시키는

“ 좋은 기회로 사용할 수도 있다.

이러한 것이 전문적이고 개선된 서비스 운영을 위한 과정이다.

- 52 -


효과적으로 지원하기 위한 방법으로 사용자 핸드북을 이용하는 방법이 있다. 사용자 핸드북은 고객이

서비스데스크로 전화를 하기 전 유용한 정보 (예, 서비스 이름 목록, Screen Number, 에러 코드 등)나

사전 점검사항, 중요 어플리케이션과 장비에 대한 장애해결을 위한 유용한 히트나 Tips를 제공한다.

중요한 것은 고객으로 하여금 전화를 걸어야 할 시점과 발생할 일들을 미리 예측하게 하는 것이다.

질 높은 서비스의 제공은 고객과 서비스데스크 요원이 함께 일할 때만 달성될 수 있다

이런 사용자 핸드북의 배포는 인터넷이나 인트라넷을 통해 온라인으로 제공하는 것을 권고한다.

4.6.4. 서비스데스크 광고

고객의 피드백과 주기적 보고 외에 고객이 서비스에 영향을 미치는 변경사항을 미리 아는 것이 중요하

다. 서비스데스크의 도입을 고객의 인지도를 향상시키고 서비스데스크의 비즈니스 효과를 판매하기 위

한 아주 좋은 고객과의 관계 통로로 사용해야만 한다.

또한, 개인사용자와 전체 비즈니스 모두 양쪽에 서비스데스크를 광고하는 것은 매우 중요하다.

따라서 서비스데스크에 대한 부정적인 반향을 없애기 위해서는 서비스데스크에 적극적이며 긍정적인

의사를 갖고 있는 사람들과 Co-Work해야만 한다. 이것이 지속적으로 고객과 협의하고 서비스데스크의

효과를 광고해야 하는 이유이다. 광고를 할 때는 다음과 같은 요소를 고려해야만 한다.

! 성공 사례 제시

! 일반적인 개선 효과를 부각

- 뉴스 레터를 발간

- 고객 만족도 수준을 정의

! 서비스 개선을 통해 비용절감 효과를 제시

- 유지보수 비용을 절감

- 투자대비 가치

- 고객에 대한 응답력 개선

! 개선이 가능한 분야와 개선방법을 제시

! 마케팅 계획을 설정하고 수행

! 서비스데스크 기능을 광고 할 수 있는 인원의 할당

성공 요소 (Key Success Factor)

성공적인 서비스데스크 구축을 위한 중요 성공 요소는 다음과 같다.

! 효과를 보여주기 위해 신속한 구축 제공

! 시작은 간단하게 하고 단계별 접근법 적용

! 의사를 많이 표현하는 고객과 성공을 하기 위한 중요고객을 포함시킴

! 고객의 관점과의 차이를 설명

! 서비스데스크에 관련된 사람 또는 영향을 받는 모든 사람들이 해야 할 일과 해야 하는 이유를

명확하게 이해토록 함 – 통신담당, 빌딩 서비스 담당도 포함

! 변경발생시 발생할 수 있는 저항을 최소화하기 위해 지원요원에게 기대효과를 설명

! 서비스데스크 요원과 관리자의 고객과 서비스 지향적 자세가 되도록 교육

- 53 -


4.6.5. 신속한 구축 (Quick Wins)

신속한 구축을 실시할 때는 고객에 가장 중요한 사항이 무엇인지를 정의하고 단기간에 서비스 개선을

할 수 있고 고객의 인지도를 향상할 수 있는 경우에 실시해야만 한다.

신속한 구축이 필요한 경우는 다음과 같다.

! 고객과 비즈니스 인식의 개선

! 일반적인 서비스 요청에 대한 신속한 응답

! 인시던트 등록과 종료작업의 전문화/기능 개선

! 고객에게 진행사항에 대한 더 많은 정보 제공

! 고객이 직접 서비스 요청사항을 등록하고 정보 검색

! 서비스 카탈로그와 사용자 핸드북을 발간

! 대화방법의 개선

! 고객과 더 좋은 관계의 설정

! 인시던트 해결시간의 절감

! 비즈니스 리포팅 개선

4.7. 서비스데스크 교육

목적

! 고객과 지원요원에게 서비스 지식과 일하는 참조지식의 개선

! 고객과 사용자 교육을 통해 고객이 서비스 사용을 어렵게 하는 요소나 지원요원에게 불 필요

한 업무 부담을 초래하는 요소를 정의

! 고객, 사용자와 지원요원의 업무를 방해하는 요소 해결을 위한 교육 프로그램 구축

4.7.1. 소프트 스킬

본 장에서는 서비스데스크에서 일하기 위해서 필요한 고객, 사용자와의 대인 관계 기술 등에 대한 내

용을 다루고 있다.

누구나가 고객만족, 장기적인 고객관계를 얘기하고 있지만 품질, 일관성, 신뢰성과 가치, 관계구축과 같

은 것을 실현한다는 것은 어려운 일이다.

고객이 경쟁사로 가거나 관리자에게 불만을 토로하게 되면 관계가 깨지게 된다.

고객과 더 좋은 관계 유지하기 위해서는 단지 고객을 위해서가 아니라 고객에게 할 일을 반드시 고려

해야만 한다. 고객에게 장담한대로 할 일을 하고 있는 지 스스로 검증하고 고객만족과 비즈니스 기회

를 놓치고 있지 않은 지를 확인해야 한다. 작은 일부터 신경을 씀으로써 좋은 관계를 유지할 수 있다.

- 54 -


4.7.2. 관리적인 측면

여기서 언급하는 관리적인 측면은 3가지가 있다.

! 팀워크 고양

! 팀원과 같이 활동

! 솔선수범

팀워크 고양

서비스 관리자는 팀워크와 적극적 참여를 독려해야 한다. 대부분의 지원요원은 고객과 대화하는 시간

에만 불만을 토로한다. 현 환경에서는 많은 변경사항으로 인한 스트레스 요인이 많기 때문에 지원요원

이 개인이 아니라 팀원으로써 일하는 환경을 만드는 것이 매우 중요하며 지원요원에게 주기적으로 프

로세스를 검토하고 필요하면 새로 설계하는 것이 필요하다. 팀원이 좋은 아이디어가 있으면 격려하는

것이 중요한데 이것은 서비스 관리자보다 실무적인 팀원이 훨씬 좋은 판단을 할 수 있기 때문이다.

만약 팀이 의사 결정 프로세스에 관여되어 있으면 각 팀원들이 최종 결정을 잘 내릴 수 있으며 새로운

프로세스의 성공이 보장된다.

팀원과 같이 활동

스트레스를 받는 지원업무에서는 항상 정확한 판단을 하기가 쉽지는 않다. 그리고 관리자는 지원요원

의 실수에 괜찮다고 말하거나 답을 모른다고 말할 수도 있지만 지원요원에게 권고한대로 하기 위해 노

력해야 한다. 팀과 정직하게 그리고 마음을 터 놓지 않으면 지원요원도 그렇게 할 수 없기 때문이다.

대개의 경우 이것은 매우 어려운 일지만 그렇게만 할 수 있다면 매우 강력한 체계를 구축할 수 있다.

좋은 대화 채널을 구축할 뿐만 아니라 상당한 충성도를 기대할 수 있기 때문이다.

솔선 수범

대개 관리자의 생활은 미팅, 보고, 장애로 가득 차 있으며 기타 다른 일을 할 시간적 여유가 없다. 관

리자의 팀원뿐만 아니라 누구 나가 알고 있지만 관리자는 반드시 시간을 내서 고객의 서비스 요청사항

을 직접 처리해야 한다. 반드시 매일, 주 별로 할 필요는 없지만 일단 그 일을 하게 되면 팀원들이 각

일 할 정도로 열심히 충심으로 일을 수행하여야 한다.

팀원의 일을 하게 되면 관리자라는 명함과 역할을 던져 버리고 그 일에 헌신하는 것이 중요하다.

4.7.3. 서비스데스크 요원 프로파일

서비스데스크 요원을 선정하고 유지하는 일은 성공을 위한 첫 걸음이다. 기술적인 스킬 보다는 전문가

적 스킬이 더 중요하다. 사실 많은 서비스 부서가 지원요원을 현업에서 뽑거나 또는 다른 서비스 산업

분야의 요원을 선정해서 필요 시 기술교육을 실시하고 있다.

현대의 서비스데스크 전문가는 많은 필요 스킬과 관련 마인드 셋을 보유한 전문가이며 다음과 같은 요

소를 갖추어야 한다.

- 55 -


! 고객 중심적 사고 / 행동

! 논리 정연하고 방법론적인 생각

! 대인관계 기술

! 다국적 언어 구사 능력

! 비즈니스 목표를 정확하게 이해

! 아래 사항을 이해하고 수용할 수 있는 능력

! 고객장애가 비즈니스에 미치는 영향

! 고객이 없으면 지원부서도 없다는 인식

! 고객은 해당분야에서 전문가라는 사실

! 성실하게 1차 지원서비스를 수행

4.7.4. 서비스 요원의 책임과 역할

고객과 서비스 지원은 어떤 조직에서든 가장 도전적인 역할을 수행하는 부서중의 하나이다.

서비스데스크 요원의 주요 역할은 비즈니스를 위해 제공되는 IT서비스의 지속적인 운영지원에 있으며

갖추어야 할 요소는 다음과 같다.

팀웤

팀웤은 아주 중요한 성공 요소이다 지원요원은 프로세스와 절차 등을 검토하고 수정할 수 있는 가장

좋은 위치에 있으며 가장 중요한 건 고객의 생각을 가장 잘 파악하고 있다는 것이다.

사용자와 공감대 형성

스트레스를 받는 지원 환경에서 항상 고객의 입장에서 일을 처리하는 것은 쉽지가 않다. 고객은 도움

을 요청할 때 스트레스를 받은 상태에서 요청을 하거나 또는 해결시한을 정해 놓기 일수이다. 이때가

진짜 중요한 시점이며 지원부서가 고객에게 가치를 제공할 수 있는 아주 중요한 시점이다.

전문 기술

고객지원 활동은 스트레스를 받는 활동이기 때문에 명확하고 도움을 주겠다는 마음을 갖는 것이 중요

하다. 하루 일과를 시작하기 전에 잠시 개인적인 문제들을 뒤에 남겨 놓고 전문가적 (미소, 긍정적 사

고)으로 행동하려는 마음을 갖는 것이 좋다.

4.7.5. 고객 대응 기술

본 섹션에서는 고객의 서비스 요청을 관리 시에 필요로 하는 다른 스킬을 설명한다

첫 인상

고객과 처음으로 접촉할 때 자신을 소개할 시간을 갖고 장애를 진단, 해결을 위한 계획을 설명한다. 단

순히 장애를 해결하는 것 보단 장애해결을 효과적으로 하려는 지원요원의 능력을 보여주는 것이 중요

- 56 -


하다. 이것을 통해 고객은 능력에 대해 신뢰하고 확신을 갖게 되며 차례로 향후에 접촉 시 일을 보다

쉽게 해결할 수 있다.

작은 장애일지라도 장애 해결에 고객이 어떤 역할을 수행하도록 하는 것도 좋다. 질문에 대한 해결책

을 모를 수 도 있다. 반드시 모든 일에 대해 모든 것을 알 필요는 없다. 중요한 것은 단순히 나는 ‘모

릅니다’ 라고 대답하는 것보단 나의 전문분야가 아니기 때문에 다른 전문가에게 ‘문제해결을 의뢰하겠

습니다’ 라고 하는 것이 명확하고 정확한 방법이다.

지원요원은 항상 건설적이어야 하며 절대로 타인과 충돌해서는 안 된다.

자세

고객의 불만을 기꺼이 지원요원의 것으로 여기는 자세가 중요하다.

실행계획을 공식화하고 고객이 진행사항을 알도록 한다. 이런 과정은 고객의 장애를 지원요원이 중요

하게 여긴다는 인식을 심어주게 되며 해결책이 쉽든, 어렵든 간에 지원요원을 도움 처로 생각하게 된

다. 지원부서가 여러 개로 분리되어 있을 경우에 프로세스에 대한 설명 없이 단순히 타 팀으로 장애를

이관하면 안 된다. 고객장애에 대한 권한을 이관했을 때에도 책임을 갖고 행동해야 한다. 고객에게는

타 지원 팀에 장애 해결을 위한 더 적합한 전문가가 있다는 것을 설명하여야 한다.

고객이 이해할 수 있는 용어의 사용

신속하게 고객의 전문 수준을 이해하는 것이 중요하다. “일정 기간 어플리케이션이나 장비를 사용해 본

경험이 있습니까? “라는 질문을 통해 수준을 파악할 수 있다. 많은 경우 특히 비지니스 어플리케이션의

경우 고객이 지원 요원보다 더 전문가일수도 있기 때문이다.

고객과 장애에 대한 협의를 할 경우 기술 용어를 피하는 방법은 익숙한 비유를 이용하는 방법이다. 예

로써 낮은 네트워크 대역폭을 얘기 할 때 고속도로와 국도를 비유하면서 얘기하는 것이 하나의 방법이

지만 고객을 무시하면 안 된다.

그리고 고객과 인시던트를 진단 시에는 “이상한 증상이나 전에는 보지 못한 증상”이라는 말을 쓰는 것

보다는 다른 용어를 쓰는 것이 좋다.

고객관점

장애를 겪고 있는 고객은 빠른 시간 안에 업무를 할 수 있는 것에만 관심을 갖고 있으며 프로젝트 마

감시한이나 견적서 발행시한에 아마도 압박을 받고 있을 것이다. 고객이 이러한 것에 걱정을 하고 있

으면 설명을 하고 지원요원 범위를 벗어난 조치를 요구하면 정중하게 서비스 관리자에게 얘기하도록

유도하여야 한다.

4.7.6. 적극적인 경청

어떤 사람들은 말을 잘하기는 하지만 말을 너무 많이 해서 고객들을 화나게 하거나 또는 일반적인 실

수에 의한 것보다도 더 큰 좌절감을 느끼게 한다.

- 57 -


지원역할을 수행 시에 듣는 능력은 서비스 개선을 위한 좋은 기술이다. – 물론 말하는 것도 중요하다.

듣는 것과 말하는 것 모두 필수적인 기술이다. 아래사항은 고려해야 하는 요소들이다.

! 피동적으로 말하지 않고 있는 것보단 적극적으로 경청해야 함을 기억하라.

! 말하는 사람의 입장에서 그들의 생각을 이해하려고 노력해야 한다.

! 고객의 말한 것에 대한 단어적 의미를 파악하기 위해 주의 깊게 들어야 한다.

예를 들어, 고객이 갑자기 말하는 “당신의 서비스는 개판이야” 와 같은 말을 왜곡해서 해석하지 말아야

한다. 이 말을 단순한 제공서비스에 대한 불만으로 이해한다면 핵심을 놓친 것이다. 아마도 이 말은

“나는 저녁에 어플리케이션에 로그인 할 수 없는 이유를 이해 할 수 없어” 라고 이해하는 것이 옳을 것

이다.

가장 훌륭한 경청자는 가장 인내심이 많은 사람이다. 질문은 다른 사람이 말하려는 것을 말하게 하는

좋은 수단이다.

경청은 종종 2가지 형태, 수동적 듣기와 적극적 듣기로 구분될 수 있다. 수동적으로 듣는 사람은 다른

사람이 전달하는 대로 메시지를 받아 들이지만 그에 따른 반응을 보인다든가 이해하지 못한 부분을 해

석하려 하지는 않다. 적극적으로 듣는 사람은 전달메시지의 의미를 명확하게 이해하려고 노력을 한다.

4.7.7. 서비스데스크 요원 교육

서비스데스크 교육은 마치 1차 지원 선에만 필요한 것으로 여겨질 때가 있다. 그러나 고객에게 전문적

이고 일관성 있는 서비스를 제공하기 위해서는 서비스데스크를 포함하여 운영부서와 개발부서는 몇 가

지 중요분야에 대한 교육을 받아야 만 한다.

이제 현대의 서비스 조직에서 기술적인 경쟁력 만으로는 충분하지 못하기 때문이다. 고객과 대화하고

협력하는 능력은 필수적인 기술이며 아래 기술 또한 투자를 통해 개발해야만 한다.

! 일반적인 대인관계 기술

! 전화 요령

! 작문 기술 (이 메일, 음성 메일, 편지)

! 적극적인 경청 및 문의 기술

! 스트레스와 불만 관리 기술

4.8. 서비스데스크 프로세스 및 절차

4.8.1. 고려 사항

프로세스와 절차 설계 시에는 폭 넓게 봐야 하며 아래 사항이 필요하다.

! 주기적으로 유효성을 검증하고 필요 시 갱신

! 모든 연관되는 조직을 포함

! 충분한 시간과 자원을 할당

! 대안을 고려 (예, 문서대신 전자 문서화 등)

! 인시던트와 장애 발생 추세에 따라 새로운 참조자료의 제공

- 58 -


4.8.2. 체계적인 조사 기법

고객의 요청사항을 관리하기 위해 체계적인 대화기법을 제공하는 것은 지원부서의 모든 사람에게 고객

응대를 위해 필요하다. 이러한 질문 또는 응답의 정해진 순서는 고객과 지원부서 모두에 잊어버릴 수

있는 항목을 방지 할 수 있다.

공통의 기술을 이용하면 전문적이고 체계적으로 잘 구성된 조직에 대한 인상을 고객에게 줄 수 있다.

중요한 건 아래 사항을 설정하고 유지하여 공통의 체계적인 조사기법을 적용하는 것이다.

! 콜 대기 시간 (고객이 요원과 통화 연결이 되기 까지 소요된 시간)

! 연락처 정의 (예, 이름, 회사, 전화번호 등)

! 연락처 상세

! 고객 응대 대화 (예, 안녕하세요, ABC 서비스데스크입니다, 무엇을 도와 드릴까요 ?, 등) 가능

하면 친숙하게 대화형으로 실시

4.8.3. 상세한 고객 정보 정의

정확하고 고유한 고객정보는 고객의 요청사항과 관리정보가 고유의 것이며 용이하게 선택 할 수 있음

을 확인하기 위해 필수적이다.

고객과 사용에 대해 더 많이 알수록 더 잘 지원할 수 있다.

포함되는 상세 고객정보는 다음과 같다.

! 이 름

! 계정 코드

! 장비 / 고객 ID

! 이 메일 / 인터넷 ID

! 전화번호 / 내선번호

! 위치

! 사원번호

! 관련 기타 정보

고객장애 DB를 구축해서 고객 정보 1, 2개 만으로 나머지 고객 정보를 가져 오는 것이 가능하도록 고

객DB를 구축해야만 한다.

고객을 대할 때 고객이 좋아하는 인사말을 하는 것이 중요하다. 대개 고객과 사용자는 특정한 방법 (예,

Mr, Dr 등) 으로 불려 지는 것을 좋아하며 따라서 시스템에서 이런 호칭을 지원하도록 설계하는 것이

중요하다.

- 59 -


고객이 계정 코드를 잊어 버렸을 때 지원시스템이 다른 친숙한 필드로 검색이 가능하도록 구성하는 것

이 중요하다. 이러한 추가적인 검색기준은 다음과 같다.

! 고객 ID

! 이 름

! 부 서

! 전화 번호

! 우편 번호

! 주소 / 위치

4.8.4. 고객 데이터베이스 유지보수

단일 소스로부터 상세한 고객과 공급자 정보를 유지 보수하는 것은 많은 조직에서는 중요 이슈 사항이

다. 왜냐하면 일반적으로 다음과 같은 몇 가지의 소스가 있기 때문이다.

! 개인별 부서 (예, 이름, 부서, NI 숫자)

! IT 부서 (예, 컴퓨터 ID, 이 메일 주소, 위치)

! 전화 (전화 번호, 팩스 번호)

상세한 고객, 지원요원과 공급자 정보를 유지보수하기 위한 프로세스가 정립되어야 하는 데 이 경우

아래 질문을 고려하여야 한다.

! 무엇이 저장되어야 하는가?

! 정보원은 무엇이고 어디에 있는가?

! 어떻게 통합 할 것인가?

! 최신정보로 어떻게 유지할 것인가?

! 누가 마스터 정보원을 유지보수 할 것인가?

4.8.5. 고객들에게 서비스데스크를 광고

지원부서의 위상을 높이기 위해서는 서비스데스크의 역할이 지원서비스의 성공을 위해 매우 중요하다.

고객과의 관계를 강화하고 확신을 주기 위해서는 서비스데스크 고유의 독립성을 유지하여야 한다.

이를 위한 실행 내용은 다음과 같다.

! 고객이 전산교육실과 지원설비를 방문하도록 초청

! 광고 자료를 사용

! 서비스 세미나와 워크샵을 제공

! 고유의 직인과 편지 머리말을 사용

- 60 -


지식과 절차 검토

고객, 사용자, 지원부서가 사용하는 모든 참조자료와 절차가 잘 유지 관리되고 있으며 최신정보로 갱신

되고 있으며 주기적으로 검토하는 것이 중요하다. 포함되는 검토사항은 다음과 같다.

! 표준 점검 사항

! 교육 매뉴얼

! Known Error와 해결책 리스트

! 제품과 어플리케이션 문서

! 하드웨어 문서

! 지식 베이스

! 지원 전문가의 스킬 셋

! 명령어 절차, 스크립트와 프로그램

! 고객/공급자 데이터베이스

4.9. 인시던트 리포팅 및 검토

목적

! SLA대비 관리자가 성능을 측정하고 필요한 결정을 하기 위한 보고서를 생산

좋은 품질의 관리정보를 제공하는 능력은 지원부서의 성숙도 수준을 보여주는 좋은 지표이다. 최초에

지원조직을 구성할 때는 제공보고서가 거의 없었을 것이다. 지원프로세스가 성숙할수록 서비스 요청사

항에 대한 히스토리, 추세, 업무를 명확하게 이해하고 보고할 필요성이 증대한다.

대개 관리정보는 추가되는 자원과 비용의 타당성을 입증하기 위한 유일한 방법이다.

하지만 때론 보고서는 비즈니스의 개선을 위해서 필요로 하기도 하며 보고서 결과는 지속적으로 서비

스를 개선하고 개발하기 위해서 타당성을 입증하기 위한 필수적인 비즈니스 도구로 사용할 수 있다.

보고서는 고객뿐만 아니라 서비스 제공 프로세스에 기여하는 모든 팀 (물론, 각 팀마다 다른 형태의 정

보가 필요하지만)에게 필수적이다.

! 네트워크 지원부서 (위치별, 시간대별)

! PC 및 하드웨어 지원부서

! 어플리케이션 개발 그룹

! 고객/우선순위별 서비스데스크

! 고객만족 어카운트 관리팀

! 관리 팀 (비즈니스 영향도, 서비스 위반 등)

! 3rd Party

- 61 -


4.9.1. 효과적인 업무 부하 분석

지원조직 내에서 가장 중요하고 비용이 많이 드는 자원은 지원 요원 이다. 따라서 지원 요원 활용을

최적화하는 것이 기본적으로 중요하다. 업무 부하 분석은 지원요원 수준 결정에 도움을 주며 일별 또

는 부별 일의 유형을 분석 할 수 있다.

지원요원과 3rd Party인원에 대한 정확한 업무 부하 분석을 서비스 요청 전 Life Cycle과 각 단계에 소요

되는 시간에 대해 수행할 필요가 있다. 상세한 분석을 위해서 지원요원은 서비스 요청에 따라 일을 한

시간을 입력해야만 한다. 예를 들어 서비스 요청이 서비스데스크에 등록되고 종료된다.

하지만 서비스 요청 Life Cycle동안에 다른 지원조직의 사람이 일하는 시간을 소요할 수도 있다. 따라서

각 개인의 소요시간과 실제의 소요시간이 계산되고 보고 될 필요가 있다.

아래 그림은 종료까지 4시간이 소요된 하나의 서비스 요청의 예제를 보여주고 있다. 아래의 시나리오

에서 3rd Party 엔지니어가 자신의 SLA를 초과 했는지의 여부를 알기를 원한다. 또한 특정 상태, 우선순

위별 각 서비스 요청의 소요된 시간을 알고 싶어한다.

지원 그룹 지원시간

서비스데스크 10분

PC 지원 1시간 50분

3rd Party 엔지니어 1시간 30분

서비스데스크 30분

그림 4.11 - 인시던트 업무 부하 분석

업무 부하 분석은 SLA와 OLA 달성여부를 알아보는 데 중요한 도구이다.

4.9.2. 리포팅과 검토 주기

조직은 검토 회의의 중요도에 따라 반드시 적절한 리포팅과 검토주기를 설정하여 한다. 그래픽한 형태

로 결과를 제공하는 것은 관심분야에 대한 표현방법으로 효과적이다.

공통의 서비스 목표를 제공하기 위해서 서비스 팀의 모든 구성원이 개별적 팀이 아니라 전체 팀으로써

주요 이슈, 관심사, 성과도, 달성치를 알고 있는 것이 중요하다.

아래내용은 검토 주기를 보여준다.

! SLA대비 개별적 인시더트와 장애 상태에 대해 매일 검토

! 그룹별 에스컬레이션을 필요로 하는 분야

! 서비스 위반 가능성 있는 인시던트

! 모든 부각되는 인시던트

- 62 -


주별 검토 항목

! 서비스 가용성

! 주요 인시던트 분야

! 가장 많이 발생하는 인시던트

! 지원요원이 가자 많은 시간을 소비하는 인시던트

! 고객에게 가장 오래 해결 시간을 요하는 인시던트

! 장애 레코드를 생성해야 하는 인시던트

! Known Error와 그에 따른 변경 사항

! 서비스 위반

! 고객 만족도

! 추세, 비즈니스에 영향을 주는 주요 서비스

! 지원요원의 업무 부하

월별 검토 항목

! 서비스 가용성

! 전체 성능, 달성도 및 추세 분석

! 개별적 서비스 목표 달성여부

! 고객의 인지도와 만족도

! 고객 교육

! 지원요원과 3rd Party 성능

! 어플리케이션과 기술적 요소의 성능

! 검토 내용과 리포팅 매트릭스

! 서비스 제공비용

사전 예방기능의 서비스 리포트

온라인 형태든 문서형식 이던지 리포팅은 서비스데스크의 사전 예방적 기능의 수행을 위해 필수적이다.

이러한 사전 예방적 기능을 수행하기 위해 다음과 같은 리포트를 고려할 수 있다.

! 다음 주 예정된 변경사항

! 지난주의 주요 인시던트, 장애, 변경사항

! 지난 주 고객이 불만족한 인시던트

! 지난 주 제 기능을 발휘하지 못한 인프라스트럭쳐 항목 (예, 서버, 네트워크, 어플리케이션)

4.9.3. 서비스데스크 기록의 저장

시간이 지나면 등록된 서비스데스크 인시던트 레코드 총 수가 증가한다. 언제, 무엇을 저장 할 지를 결

정하는 것은 몇 가지 다음과 같은 사항을 고려한다.

! 서비스 요청 양

! 내용의 유용성

- 63 -


! 현재 서비스데스크에서 필요로 하는 지 여부

! 저장될 수 있는 서비스 요청의 형태 여부

! 서비스 요청 형태가 월별, 분기별, 년별 기능에 종속 여부

! 데이터가 현재 진행중인 타 인시던트와 관계가 있는 지의 여부

분기, 연별 인시던트와 관계 있는 정보의 유지는 조심스럽게 고려되어야 만 한다.

4.10. 결 론

서비스데스크 프로세스의 성공적인 구축과 지속적인 지원은 조직에 비용절감, 고객만족, 전문화와 같은

비즈니스 기대효과를 제공한다.

4.10.1. 중요 성공 요소

성공적인 서비스데스크를 도입하고 유지하기 위해서는 다음과 같은 사항이 필수적이다.

! 비즈니스상 필요성을 이해

! 고객의 요구사항을 이해

! 고객, 사용자와 서비스데스크 지원 요원 교육에 투자

! 서비스 목표, 목적과 산출물을 명확하게 정의

! 서비스수준을 실용적으로 정의하고 합의하고 주기적으로 검토

! 비즈니스 부서에 기대효과를 부각

4.10.2. 서비스데스크 구축 도움말

모든 서비스데스크 구축은 프로젝트로써 세밀하게 계획하고 주기적으로 각 단계별 산출물을 검토해야

만 한다.

! 단계별 구축 접근 방법을 채택

! 고객을 프로젝트에 포함시키고 고객의 필요사항을 반영

! 지원요원을 포함

! 지속적으로 진행사항을 측정

! 너무 빠른 구축을 기대하지 말 것

! 어려운 일이란 걸 인식하되 포기하지 말 것

- 64 -


5. 인시던트 관리 5.1. 인시던트 관리의 목적

인시던트 관리 과정의 주요한 목적은 가능한 빨리 정상적인 서비스 기능을 복구하는 것이며 비즈니스

기능에 좋지 않은 영향을 최소화하는 것이다. 그래서 서비스의 질과 가용성의 수준을 가능한 최대로

유지하는 것이다. 여기서 정상적인 서비스 기능은 서비스 수준 관리에서 정의한 범위 내에서 서비스

기능으로 정의된다.

5.2. 인시던트 관리의 범위

ITIL 이라는 전문용어에서 인시던트는 서비스의 표준 기능의 일부가 아니며 서비스의 질을 떨어뜨리는

원인이거나 또는 원인이 될 수 있는 인시던트로 정의된다. 인시던트의 범주에 속하는 예제는 다음과

같다.

! 어플리케이션

- 서비스를 이용 불가

- 고객의 업무를 방해하는 어플리케이션 버그

- 임계치를 초과한 디스크 사용

! 하드웨어

- 시스템 다운

- 자동 경고

- 프린터 불능

- 구성 접근 불가

! 서비스 요청

- 정보/어드바이스/문서의 요청

- 비밀번호 분실

신규 혹은 부가서비스 요청 (예를 들면, 소프트웨어나 하드웨어)은 때때로 인시던트가 아닌 변경요청으

로 간주된다. 그렇지만 관례적으로 볼 때 서비스 요청과 인프라스트럭쳐의 장애에 대한 처리가 비슷하

다는 것을 보여주며, 인시던트 관리 과정의 범위와 정의에 포함된다. 이 장에서 언급하는 인시던트란

단어는 명확하게 정의되어 있지 않든, 보다 기술적인 이슈에 대한 분리를 위해 자신들의 서비스 요청

절차를 개발하려는 조직이든 간에 동일하게 적용하여 언급한다.

더욱 기술적인 면을 지향하는 시스템 관리 기능 내에서 임계치를 초과한 디스크 사용과 같은 자동으로

등록된 인시던트는 가끔 정상적인 기능의 일부로 간주된다. 이런 인시던트는 고객에게 영향을 미치지

않는 서비스 구조일지라도 인시던트의 정의에 포함된다.

그림 5.1은 인시던트 프로세스에 대한 절차를 보여준다. 이것들은 다음과 같이 분리된다.

- 65 -


그림 5.1 – 인시던트 관리 과정

# 입력:

! 서비스데스크, 네트워크 또는 컴퓨터 운영에서 발생하는 인시던트의 세부 항목

! CMDB로부터의 구성 상세

! 문제와 알려진 오류에서 인시던트와 매칭되는 응답

! 분석에 대한 세부 사항

! 인시던트의 분석에 영향을 미치는 변경 요청에서의 응답

# 출력:

! 인시던트 해결을 위한 변경요청; 인시던트 기록 업데이트 (해결책 그리고/혹은 임시 해결책

(Work-around)를 포함하여)

! 분석되고 종료된 인시던트

! 고객과의 커뮤니케이션

! 관리 정보 (리포트)

# 인시던트 관리 활동:

! 인시던트 발견과 기록

! 분류와 초기 지원

! 조사와 진단

! 분석과 복구

! 인시던트 종결

! 인시던트의 Ownership, 모니터링, 트래킹 및 커뮤니케이션

- 66 -


인시던트 관리 과정에 관계되는 역할과 기능은 다음과 같다:

! 외부 공급자와 전문가 지원 그룹을 포함한 제 1선, 2선 및 3선 지원 그룹 (역할)

! 인시던트 관리자 (역할)

! 서비스데스크 관리자 (기능)

5.3. 기본 개념

5.3.1. 인시던트 처리

대부분의 IT 부서와 전문가 그룹은 때때로 인시던트 처리에 기여한다. 서비스데스크는 모든 등록된 인

시던트의 분석과정에 있어서 모니터링 책임이 있으며 사실상 서비스데스크는 모든 인시던트의 소유자

이다. 그 과정은 대부분 수동적이다. 그러므로 능률적이며 효과적으로 다시 하려면 소프트웨어 도구에

의해 지원될 수 있는 공식적인 작업 방법이 요구된다. 서비스데스크로 즉시 분석될 수 없는 인시던트

는 전문가 그룹에 할당될 수 있다. 분석 또는 임시해결책 (Work-around)은 작업에 최소한의 영향을

미치며 사용자의 서비스를 가능한 빨리 복구할 수 있도록 절차가 확립되어야 한다. 인시던트의 원인

해결과 협의된 서비스의 복구 후에는 인시던트가 종료된다.

그림 5.2는 인시던트 라이프 사이클 동안의 활동에 대해 보여준다.

그림 5.2 - 인시던트 라이프 사이클

- 67 -


인시던트의 상태는 가끔씩 ‘작업 흐름 위치’로 알려진 라이프 사이클에서 인시던트의 현재 상태를 나타

낸다. 누구나 각각의 상태와 그 의미를 알고 있어야 한다. 상태를 나타내는 범주에 포함될 수 있는 예

는 다음과 같다.

! 신규

! 승인

! 일정 수립

! 전문가로의 할당과 발송

! 작업 진행 (work in progress : WIP)

! 보류

! 해결

! 종료

인시던트 라이프 사이클의 처음부터 끝까지 인시던트의 기록이 유지되어야 한다는 점은 아주 중요하다.

이런 사실은 서비스 팀의 어떤 구성원이 고객에게 최신의 진행 상태에 대한 안내를 제공할 수 있도록

한다. 업데이트 활동에 포함되는 예제는 다음과 같다.

! 히스토리 세부 사항 업데이트

! 상태 수정 (예를 들어 ‘신규’ 에서 ‘작업 진행’ 혹은 ‘보류’ 상태로)

! 비즈니스 영향과 우선순위 수정

! 소비된 시간과 비용 입력

! 에스컬레이션 상태 모니터링

원래 보고된 고객에게 제공된 설명은 인시던트 진행처럼 변경할 수 있다. 그렇지만 초기 증상에 대한

설명의 유지 및 분석, 그리고 초기 보고 시 사용된 고객의 불만 사항에 대한 언급에 대해 유지하는 것

은 중요하다. 예를 들어 고객은 네트워크 실패 때문에 프린터가 동작하지 않음을 보고했다. 고객에게

응답할 때 초기에 네트워크 문제의 분석에 대해 이야기하는 것 보다는 프린터 인시던트에 대해 분석이

되었음을 설명하는 게 더 낫다. 감사된 히스토리는 진행 상태를 재검토할 때 중요하며 특히 서비스 수

준 관리의 불이행을 분석할 때 중요하다. 인시던트 기록으로의 다음과 같은 업데이트들은 인시던트 라

이프 사이클 동안에 등록되어야 한다.

! 수정한 사람의 이름

! 수정 날짜와 시간

! 수정한 항목 (우선순위, 상태, 히스토리 등)

! 변경 이유

! 소비한 시간

만약 3rd Party 조직이 서비스데스크의 지원 기록을 업데이트하도록 허가 하지 않는다면, 공급자를 대

신하여 기록을 업데이트 해야 할 필요가 있다. 이것은 자원 사용에 대해 적절한 계산을 가능하게 한다.

그렇지만 소프트웨어가 인시던트의 구분 및 정보의 차단을 허용하면 3rd Party 에 의한 직접적인 업데

- 68 -


이트를 허용하기 위한 어떤 조직의 업무를 대신하여 수행할 수 있을 것이다. 이런 결정에서 무엇이 공

급자가 볼 수 있도록 준비되지 않았는지 그리고 어떻게 공급자가 무엇을 하고 있는지에 대해 면밀히

파악할 수 있는지에 대한 고려가 필요하다. 똑 같은 상황이 서비스데스크가 작업 현장에서 일하는 공

급자를 대신하여 요청을 업데이트할 때 존재할 수 있다.

5.3.2. 제 1선, 2선 및 3선 지원

때때로 서비스데스크 보다는 인시던트 해결을 위한 특별한 기술과 시간 및 자원 가지고 있는 전문가

지원 그룹 및 부서가 제 2선 및 3선 지원 그룹이 될 때가 있다. 이런 점을 고려할 때, 서비스데스크 는

제 1선 지원 그룹이 된다.

그림 5.3은 인시던트 해결을 위한 제 1선, 2선 및 3선의 업무 흐름을 보여 준다. 이는 에스컬레이션 수

준에 따라 n-line 지원으로 구성 될 수도 있으며 각 지원 라인은 외부 공급자가 될 수도 있다.

그림 5.3 – 제 1, 2선 및 3선 지원

- 69 -


5.3.3. 기능적(Functional) 대 계층적(hierarchical) 에스컬레이션

에스컬레이션은 인시던트를 적시에 해결을 보조하기 위한 메커니즘이다. 이것은 해결 프로세스의 모든

과정에 수반하여 일어날 수 있다. 제 1선에서 2선 지원 그룹으로의 인시던트 전달은 기능 에스컬레이

션이라 불리며 전문적인 기술 또는 지식의 부족 때문에 주로 발생한다.

기능 에스컬레이션은 동의된 시간 간격이 경과하였을 때 또한 발생한다. 시간 간격을 기반으로 한 자

동 기능 에스컬레이션은 조심스럽게 계획되어야 하며 동의한 분석 시간(서비스 수준 관리)를 초과하지

말아야 한다. 계층 에스컬레이션은 인시던트의 해결이 만족스럽지 못하거나 해결 시간이 없는 시점에

서 발생할 수 있다. 전문적인 기술이나 지식의 부족할 경우에는 계층 에스컬레이션이

또는 다른 지원 직원에 의해 일반적으로 직접 수행될 수 있다. 자동 계층 에스컬레이션은 적정 시간

내 해결이 되지 않을 것과 같은, 어떠한 시간 경과가 중요한 요소로 작용할 때 고려된다.

서비스데스크

5.3.4. 우선순위 (Priority)

인시던트의 우선순위는 비즈니스에서의 영향과 해결 또는 임시 해결책이 필요한 위급한 상황에 의해

결정된다. 인시던트의 해결 또는 요청 처리를 위한 대상은 일반적으로 서비스 수준 관리에서 구현된다.

카테고리와 우선순위 그리고 코딩 시스템의 예는 부록 5A와 5B를 참조한다.

서비스데스크는 다음과 같이 인시던트 관리 과정에서 중요한 역할을 한다.

! 서비스 데스크에 의해 등록되고 보고되는 모든 인시던트 – 자동으로 생성된 인시던트도 서비

스데스크에 의해 등록 되어야 한다.

! 인시던트의 대부분은 서비스 데스크에서 해결된다.

! 서비스데스크는 모든 등록된 인시던트의 해결 절차를 모니터링 하는 독립된 기능이다.

인시던트 통지의 접수에 있어서 서비스데스크에 의해 수행될 수 있는 중요한 활동은 다음과 같다.

! 기본 상세 사항 기록 – 이것은 증상에 대한 시간 데이터 및 상세 사항을 포함한다.

! 서비스 요청이 생성되었다면, 그 요청이 조직의 표준 절차에 따라 처리되도록 조정

! CMDB로부터, 인시던트 발생 CI에 대한 정보를 기록

! 적절한 우선순위 할당과 사용자에게 생성된 시스템의 유일 식별자 부여

! 인시던트를 평가하고, 가능하면, 해결책을 제공한다.

! 성공적으로 해결된 인시던트 기록의 종료 수행: 해결 방법의 상세 기록 및 적당한 카테고리

코드 부여

! 성공적으로 해결되지 못한 인시던트 혹은 다음 레벨의 지원이 필요한 인시던트에 대해 제 2선

지원 조직으로의 할당 (전문가 그룹 등)

5.3.5. 인시던트, 문제, 알려진 오류 그리고 변경요청 사이의 관계

인시던트는 IT 인프라스트럭쳐의 오류 또는 장애의 결과이며 계획된 IT 서비스의 운영으로부터 실제로

또는 일어날 수 있는 변동에 대한 결과이다. 인시던트의 원인은 식별할 수 있으며 원인은 부가적인 조

- 70 -


사, 장애 해결 결과, 임시 해결책 혹은 오류 제거를 위한 변경 요청 없이 기록될 수 있다. 어떠한 경우

에는 인시던트 그 자체가 재빨리 해결될 수 있다. PC의 재 부팅이나 통신 라인의 재 설정은 인시던트

의 내제된 원인에 대한 조사 과정 없이 문제를 해결할 수 있는 하나의 방법이다. 인시던트의 발생 원

인을 확인할 수 없다면, 그것은 문제를 제기하는 것이 적합할 것이다. 사실상 문제는 인프라스트럭쳐에

서 알려지지 않은 오류를 암시한다. 일반적으로 문제 기록은 조사 과정이 보증될 때에만 제기가 된다.

이 영향은 비즈니스 서비스와 공통된 근본 원인을 갖고 있는 것으로 판명되는 유사한 인시던트들의 개

수의 영향을 통해 측정된다. 성공적인 문제 기록 프로세스는 근본 오류의 식별을 통한 결과이며, 기록

은 한번 임시 해결책(Work-Around) 그리고/혹은 RFC가 발행되고 나면 알려진 오류로 전환된다. 그림

5.4에서는 초기 인시던트 보고 시부터 근본적인 문제 해결까지의 논리적인 흐름을 보여준다.

그림 5.4 – 인시던트, 문제, 알려진 오류 그리고 변경요청 사이의 관계

따라서 다음과 같은 정의를 내릴 수 있다.

! 문제 : 근본 원인을 알지 못하는 하나 혹은 하나 이상의 인시던트

! 알려진 오류 : 성공적으로 원인이 규명되고 임시 해결책이 마련된 문제

! 변경요청(RFC) : IT 인프라스트럭쳐 또는 IT 서비스 관점에서의 어떠한 구성요소 변경 요청

문제는 여러 인시던트의 결과일 수 있으며, 몇 개의 인시던트가 발생하고 나서 처리 기간이 오래된, 원

인이 규명되지 않은 것들이다. 문제에 대한 처리는 인시던트 처리와는 완전히 다르므로 문제 관리 프

로세스에서 다루어 진다. 인시던트 해결 과정 동안에 인시던트는 문제와 알려진 오류 데이터베이스에

대해 대응되게 된다. 그것은 비슷한 인시던트가 있는지 이전에 비슷한 인시던트를 위해 행해졌던 해결

행위가 있었는지를 보기 위해 인시던트 데이타베이스에서 적합한 것을 찾게된다. 임시 해결책 또는 해

결책을 이용할 수 있으면 인시던트는 즉시 해결될 수 있다. 만약에 이용할 수 없으면 인시던트 관리는 비즈니스 수행에 최소한의 영향을 주도록 임시 해결책 또는 해결안을 찾아야 할 책임이 있다. 인시

던트 관리가 임시 해결책을 발견할 때 그것은 관계되는 문제 기록을 업데이트할 수 있는 문제 관리 팀

에 의해 해결될 수 있다 (그림 5.5 참조). 이때에 관련된 문제 기록이 있지 않을 수 있다는 점을 주의

하여야 한다. – 예를 들면, 임시 해결책은 통신 라인의 장애 때문에 Fax를 보내지 못하기 때문이다라고

할 수 있지만, 이 시점에서 통신 라인의 장애에 대한 문제 기록이 되지는 않을 것이며, 문제 관리 팀이

기록을 생성해야만 한다. 이 과정은 그러므로 서비스데스크는 인시던트를 존재하는 문제 기록의 명확

한 결과를 링크 시킬 것이다.

예를 들어 임시 해결책은 통신 실패 때문에 팩스에 의해 보고서를 보낼 수 없는 경우와 같이 관계되는

문제 기록은 존재하지 않을 수 있다. 그러나 문제 관리 팀이 생성해야만 하는 통신 실패를 위한 문제

기록이 아닐 수도 있다. 이 과정은 서비스데스크가 존재하는 문제 기록의 결과가 분명한 인시던트에

연결할 수 있다는 것이다.

- 71 -


그림 5.5 – 인시던트 임시 해결책 및 해결 처리

인시던트에 관계된 문제를 조사하는 문제 관리 팀은 문제와(또는) 관계되는 인시던트를 위한 해결책이

나 임시해결책을 발견하는 것 또한 가능하다. 이런 경우에, 문제 관리 팀은 인시던트 관리 과정에 인시

던트의 상태를 알려진 오류 또는 적절하게 종료된 것으로 변경되었음을 알려야 한다.

인시던트가 문제로 인식되는 시점부터는 하나의 문제로 인식되어 하나의 문제 발생을 기록하고 문제

관리 프로세스를 통해 처리되어야 한다. 인시던트 관리는, 언제나와 같이, 비즈니스 프로세스에 대한

가능한 최소한의 단절을 위한 해결 노력에 대한 책임이 있다.

5.4. 인시던트 관리의 이익

인시던트 관리 과정을 실시하여 얻게 되는 주요한 이점은 다음과 같다.

# 전체 비즈니스에 대해

! 적기의 인시던트 해결로 비즈니스의 임팩트 감소

! 이익이 되는 시스템 강화와 수정의 능동적인 확인

! 서비스 수준 관리에 관계된 비즈니스에 초점을 맞춘 관리 정보의 가용성

# 개별 IT 조직에 대해

! 서비스 질의 측면에서 개선된 관리 정보

! 직원 활용도 증대를 통한 효율 증대

! 분실한 혹은 올바르지 않은 인시던트 및 서비스 요청의 제거

! 더욱 정확한 CMDB 정보

! 사용자 및 고객 만족도 증가

반면, 인시던트 관리 구축의 실패는 다음과 같은 결과를 초래한다.

! 인시던트를 관리하고 에스컬레이트하기 위한 사람이 없음

! 전문가 지원 직원이 끊임 없는 방해를 받게 되므로 업무 효율이 떨어짐

! 존재하는 해결책을 참조하기 보다는 매번 인시던트 발생 시 재 분석의 반복이 발생

! 대등한 관리 정보의 부족

! 분실, 혹은 부정확하거나 잘못된 인시던트 관리

- 72 -


5.5. 계획과 실행

5.5.1. 타이밍 및 계획

인시던트 관리 계획을 위한 기준은 다음과 같다.

! 인시던트 관리의 구축과 운영을 별도로 분리하여 계획하지 마라. 가능하면, 계획의 범위는 실

행, 조사 그리고 서비스데스크의 기능, 문제 관리, 구성 관리, 변경 관리, 릴리즈 관리 과정을

포함하도록 하여야 한다.

! 만약 자원이 동시에 모든 서비스 지원 프로세스를 구축하는데 가용 가능하지 않다면, 인시던

트 관리와 함께 서비스데스크 기능의 구축부터 시작한다. 이것은 빠른 성과 획득의 결과를 가

져올 수 있다.

! 인시던트 관리의 계획 단계는 경험상 3개월에서 6개월 정도의 시간을 잡아라. 비록 구현과 개

선 활동이 병행되어야 할지라도 3개월에서 1년 정도의 시간을 잡아라.

! 하드웨어와 소프트웨어의 획득은 시간이 걸릴 수 있다. 가능할 빨리 ITIL 과정을 지원하는 것

들을 찾는 것에 기반하는 행동을 선택해라. 그리고 조직이 필요로 하는 것을 허용하도록 융통

성을 제공해라.

! 이 단계에서 밀접하게 연결되어 있는 시스템에 대해 고려하라. 특히 구성관리와의 링크에 대

해 충분히 고려하도록 한다. 구성 관리 데이터베이스 (CMDB)의 구축 계획을 세우고 기존 장

비의 인벤토리의 전환을 계획하라. 만약 구성 관리 시스템과의 통합이 되지 않는다면, 인시던

트 관리 시스템의 한 부분으로 이 데이터베이스를 구축하라.

! 알려진 오류에 인지하고 어드바이스의 제공으로 서비스데스크 요원에게 도움으로 제공할 수

있도록 문제 관리 시스템과의 인터페이스에 대한 계획을 세워라. 만약 이와 같은 시스템의 구

축이 추후에 예정되어 있다면, 그 동안만이라도 문서의 형태 혹은 다른 전자 솔루션(예를 들어

스프레드 쉬트 등)을 이용하여 그 겝을 줄이도록 해라.

5.5.2. 핵심 성공 요인 (Critical success factors)

성공적인 인시던트 관리를 위한 핵심 성공 요인은 다음의 사항을 고려한다.

! 최신 CMDB는 효과적인 인시던트 관리 프로세스를 위한 사전 조건이다. 만약 CMDB를 사용할

수 없다면 인시던트와 관계되는 CI에 대한 정보를 직접 얻어야 하며 임팩트와 긴급도에 대한

결정에는 훨씬 많은 어려움이 따를 것이고 많은 시간이 소모될 것이다.

! 최신의 문제, 오류 데이터베이스에서의 지식 기반은 임시 해결책 및 해결책 제공을 위하여 개

발 되야 한다. 이는 인시던트 해결 과정의 속도를 높여 줄 것이다. 3rd Party의 알려진 오류에

대한 데이터베이스는 인시던트 해결을 위한 보조도구로 활용 되야 한다.

! 인시던트 관리를 위해 효과적으로 자동화 시스템은 서비스데스크의 성공을 위한 중요 요소이

다. 문서 기반의 시스템은 실제로 실용적이거나 필요하지 않다. 현재는 좋고 값싼 지원 도구를

이용할 수 있다.

! 필요한 인시던트 응대 목표를 얻기 위해 서비스 수준 관리(SLM)와의 밀접한 연결 계획을 세

워라. 적기의 인시던트 해결은 고객과 사용자를 만족 시킬 것이다.

- 73 -


5.5.3. 발생 가능한 문제 영역

다음과 같은 사항을 극복하기 위한 준비를 하라.

! 인시던트 관리 프로세스 구축을 위한 가용 가능한 자원 부재의 결과로 가시적인 관리 혹은 직

원의 참여 부재

! 비즈니스 요구에 대한 뚜렷한 인지 부족

! 재검토나 변경이 되지 업무 사례

! 제대로 정의되지 않은 서비스 목적, 목표 및 책임

! 고객 서비스 수준 협의에 대한 제공 부재

! 불충분한 직원 교육

! 인시던트 해결을 위한 지식의 부족

! 다른 프로세스와의 통합 부족

! 자동화 프로세스를 위한 도구의 부재 및 높은 비용

! 변경에 대한 저항

5.6. 인시던트 관리 활동

이번 장은 5.3장에서 요약된 6가지의 활동에 대한 더 상세한 항목에 대해 논의한다.

! 인시던트 발견과 기록

! 분류와 초기 지원

! 조사와 진단

! 분석과 복구

! 인시던트 종결

! 소유권, 모니터링, 트래킹 및 커뮤니케이션

이들의 각각에 대한 세부 사항은 아래에 자세히 다룬다.

5.6.1. 인시던트 발견과 기록

이벤트 관리 시스템 혹은 서비스데스크로부터의 인시던트 상세 사항은 인시던트 관리를 위한 인풋이다.

결과적인 행동은

! 인시던트의 기본 세부 사항 기록

! 필요 시 전문가 그룹에 경고

! 서비스 요청 처리를 위한 절차 시작

아웃풋은

! 인시던트 세부 사항 업데이트

! CMDB에서의 어떤 오류의 인식

! 인시던트가 해결되었 때 고객에게 공지

- 74 -


모든 인시던트는 기록되어야 한다. 시스템 관리 도구에 의한 인시던트 데이터베이스 내의 에 있는 '기

본 인시던트 기록' 의 자동 생성은 이런 필요조건에 부합하는 최선의 해결책이다. 증상, 기본 진단 자

료, 그리고 관계되는 CI에 대한 정보는 발견과 기록 동안에 인시던트 기록에 포함되어야 한다. 부록

5C는 전체 인시던트 관리 과정 동안에 기록된 자료의 범위를 설명한다. 인시던트 분석, 복구 및 인시

던트 유형과 경향 관리 정보를 위해 이런 자료가 필요하다. 과거에는 서비스데스크에 보고되는 모든

인시던트는 사람이 직접 수작업으로 입력하는 것이 일반적인 사례였다. 수동 입력은 인시던트 기록의

누락 및 서비스 질의 저하를 가져왔다. 그렇지만, 현대적인 기술로 인시던트는 요즘에는 사용자가 직접

시스템에 인시던트에 대한 기록을 수행하는 것을 포함하여 다양한 자동화된 방법으로 인시던트가 기록

될 수 있게 되었다. 그러나 기초가 되는 필요사항은 이런 인시던트가 인시던트 관리 데이터베이스에

여전히 모두 도달해야 하며 서비스데스크는 적절한 경고를 받아야 하며 서비스데스크의 책임인 인시던

트 모니터링에 대한 제어를 유지해야 한다는 것이다.

서비스 수준의 심각한 저하와 특별한 행동이 필요한 경우 서비스 관리자에게 경고가 필요하다. 인시던

트는 표준 서비스 수준 관리 절차에 일치하게 처리되어야 한다. 이런 특정한 절차는 인시던트 관리 과

정의 범위에 포함되지 않는다.

5.6.2. 분류와 초기 지원

입력

! 인시던트 세부 사항 기록

! CMDB로부터 구성에 대한 세부 사항

! 문제와 알려진 오류에 대한 인시던트 매칭으로부터의 응대

이전 활동에 기반한 인시던트의 기록은 인시던트의 원인을 찾기 위해 이제 분석된다. 인시던트는 또한

분류되어야 하며 더 나은 해결 시도를 위한 과정이어야 한다. 부록 5A는 분류 코드의 예제를 제공한다.

행동

! 인시던트 분류

! 알려진 오류와 문제와의 대응

! 새로운 문제, 혹은 여러 인시던트에 의해 발생한 문제에 대한 문제 관리로의 통지

! 임팩트와 긴급도 평가를 통한 우선 순위 부여

! 관련되는 구성에 대한 세부 사항 평가

! 초기 지원 제공 (인시던트의 세부사항 평가 및 빠른 해결책 모색)

! 인시던트 종료나 전문가 그룹으로 전달 그리고 사용자에게 통지

출력

! 인시던트 해결을 위한 변경 요청

! 업데이트된 인시던트의 세부 사항

! 인시던트를 위한 임시해결책 또는 제 2, 3선으로의 인시던트 전달

- 75 -


분류는 인시던트의 원인에 대한 식별 프로세스이며 해결 활동에 대응되는 프로세스이다. 많은 인시던

트를 정기적으로 경험하게 되며, 이로 인해 적합한 분석 행위를 잘 알게 된다. 그러나 이것은 항상 있

는 경우는 아니며 문제와 알려진 오류가 필요한 인시던트 분류 자료의 적절한 것을 찾는 절차이다. 성

공적인 대응은 입증된 해결 행위로의 접근을 가능하게 하며 이것은 조사에 소모되는 노력을 줄여준다.

분류는 인시던트 관리에서 가장 중요한 요소 중의 하나이다. 분류는 다음과 같은 사항들을 위해 사용

된다.

! 인시던트에 관계되는 서비스 지정

! 적절한 서비스 수준 관리와의 연결

! 인시던트 처리를 위한 최상의 전문가 혹은 전문가 그룹 선택/정의

! 비즈니스 영향을 토대로 하는 우선순위 확인

! 무엇을 질문해야 할지 또는 무슨 정보가 점검되어야 하는지를 정의

! 관리 정보를 위한 주요 보고 메트릭 보고 결정

! 알려진 오류나 해결책에 대해 부합하는 관계 확인

최종의 분류는 사용자가 근본 문제보다는 인시던트의 증상만을 보고할 수 있기 때문에 초기에 보고된

분류로부터 변경 될 수 있다. 분류의 수준은 필요한 세부항목에 의존하여 변경 될 수 있다. 예를 들어

워드 프로세스 또는 Payroll 서비스의 최상위 분류는 개관에 알맞다. 그러나 다음과 같은 세부 정보를

얻을 필요가 있다.

! 버전 넘버

! 공급자

! 모듈

! 그룹핑 (예를 들면, 비즈니스 어플리케이션 등)

가능한 많은 정보가 인시던트를 분류할 때 제공되어야 한다. 적절한 분류를 위해서는 다음과 같은 사

항을 고려한다.

! 인시던트 증상의 세부 사항

! 초기 인시던트의 범주

! CI와 관련 세부 정보

! 비즈니스 영향

분류와 대조 과정은 보다 빠른 속도와 지원을 위한 최소한의 자원으로 인시던트를 관리할 수 있게 한

다. 분류-대조 과정은 소위 말하는 전문 소프트웨어의 사용을 위한 이상적인 어플리케이션 영역이다.

서비스데스크는 영향을 받는 CI에 대한 정보를 수집하며 그러므로 사용자가 설정 ID 번호, 일련 번호

등을 물을 때 CMDB에서 일관성이 없는 것들을 발견할 수 있어야 한다. 일관성이 없음이 발견되면 예

외 보고가 발생 되어야 하며 구성 관리 과정에게 알려야 한다. 이것은 매일매일의 보고나 인시던트 관

리 소프트웨어를 통해 자동으로 수행 될 수 있다. 인시던트 관리의 중요한 측면 중의 하나는 비즈니스

에 있어서 영향을 받는 것이 무엇이고 얼마나 중요한 지와 같은 우선순위를 정의하는 것이다. 인시던

- 76 -


트의 우선순위는 결정되어야 하므로 다음과 같은 사항을 고려하여 인시던의 복구 및 해결을 위한 노력

을 해야 한다.

! 비즈니스에 대한 영향

! 비즈니스에 대한 긴급성

! 인시던트의 복잡성, 크기 범위

임팩트는 인시던트 혹은 문제의 ‘비즈니스 중요도’의 측정되며, 때때로 동의된 서비스 수준의 저하를

야기 시키는 인시던트의 범위로 정해진다. 임팩트는 인시던트에 의해 영향을 받는 사람 혹은 시스템의

수로 측정되곤 한다.

영향은 가끔 영향을 받는 시스템 또는 사람의 수로 측정된다. 할당중인 영향을 위한 Criteria를 비즈니

스 관리자와 형식적인 상담에서는 설정해야 한다. 서비스 수준 관리. 영향을 결정할 때 CMDB에 있

는 정보는 어떻게 많은 사용자가 예를 들어 하드웨어 구성 요소의 기술적인 실패의 결과로 손해를 볼

수 있는지를 발견하기 위해 접근이 허용되어야 한다. 서비스데스크는 빨리 활성화하는 도구로 접근해

야 한다.

! 중요한 장비 장애의 사용자에 대한 영향 평가

! 장비 실패에 의해 영향을 받는 사용자 식별

! 문제를 인지하기 위한 접점 확립

! 장애 해결 이후의 경과 제공

! 제 2선 지원 그룹으로의 경고

‘긴급도’는 어떤 임팩트에 대한 인시던트를 해결하는 데 필요한 속도에 대한 것이다.

우선순위는 예상되는 투입 노력에 의해 정의된다. 패스워드의 재설정 등과 같은 임팩트가 낮고 평균적

인 긴급도를 갖는 인시던트는 적은 노력으로 대부분의 조직에 즉시 해결책을 줄 수 있을 것이다.

초기 지원은 서비스데스크에 의한 고객의 만족을 위한 인시던트의 해결을 포함한다.

해결은 다음을 포함하는 여러 영역으로부터 이끌어 낼 수 있다.

! 알려진 오류의 확인

! 서비스데스크 직원의 전문성

! 지식의 검색

이런 일 이후에는 해결책의 상세 기록, 분류 및 고객 만족도 조사 보다는 다른 적은 부가적인 업무가

서비스데스크에 의해 수행될 필요가 있다.

Tip

! 서비스데스크에 의해 직접 해결된 요청의 수는 필수적인 서비스 모니터링 요소이며 이는 사용

자의 만족을 이끌어 낼 것이다.

- 77 -


분류 대조 작업이 성공적이지 못하거나 혹은 해결 프로세스가 복잡하다면, 지원 그룹에 의한 조사와

진단이 다음 단계이다. 비록 해결에 대한 책임이 다른 지원 그룹에게 넘어가더라도, 서비스데스크는 인

시던트에 대한 소유권을 여전히 갖고 있으며, 고객이 만족할 만한 해결이 될 때까지 그것을 관리할 책

임이 있다.

5.6.3. 조사와 진단

입력

! 업데이트 된 인시던트의 세부 내용

! CMDB 내의 구성 세부 내용

활동

! 인시던트의 세부 내용에 대한 평가

! 수집 및 모든 연관된 정보의 분석, 그리고 해결

! (어떤 하나의 임시 해결책을 포함) 또는 n-line 지원자에게로 전달

출력

! 더이상 업데이트 되지않은 인시던트의 세부내용과 선택 또는 필요한 임시 해결책에 대한 설명

가능한 어디에서나, 관련된 사용자에게 품질이 떨어지는 서비스를 통해서라도 비즈니스를 수행 할 수

있도록 해야 한다. 한 예로 문제가 있는 프린터보다 훨씬 먼 거리의 위치에서 수행되는 출력을 필요로

할 수도 있다. 그러한 하나의 임시 해결책의 효과는 비즈니스 상에서 인시던트로 인한 영향 최소화와

연구에 보다 많은 시간 할당 및 구조적인 해결 도출이다. 일시적인 임시 해결책은 또한 다른 사용자들

에게 권고하여도 된다.

인시던트가 지원 그룹에 할당되면 다음을 준수하여야 한다.

! 인시던트의 할당을 수락하고 날짜와 시간을 기록(자동 권장), 다음 사항 명시

- 인시던트의 상태와 정기적으로 업데이트 된 기록

- 서비스데스크를 통하여 해결에 이르기까지의 경과에 대한 내용을 알 수 있다.

- 인시던트의 현재 상태 반영 (예를 들면 진행상의 조치 작업, 및 등등)

! 임시 해결책이 즉시 제공 가능하다면, 확인된 임시 해결책을 서비스데스크/고객에게 권고하라.

! 알려진 에러들, 문제, 해결책, 계획된 변경 또는 지식을 가지고 인시던트 재검토

! 필요하면 할당된 비즈니스 영향과 우선순위를 재 평가하기위해 서비스데스크에 문의하고, 요

구된 동의 된 서비스 수준에 기반하여 조정하라.

! 인시던트 라이프 사이클 측면에서 적절한 모든 세부 사항을 기록해라.

- 해결

- 추가되고 업데이트 된 분류

- 모든 관련된 인시던트를 업데이트

- 소비한 시간

! 종료 작업을 위해 서비스데스크에 인시던트 재할당

- 78 -


조사와 진단은 서로 다른 전문가 지원 그룹과 계속해서 반복되는 이전에 발생했던 문제 제거에서부터

시작하는 반복 프로세스가 될 수 있다. 이것은 서로 다른 vendors로부터 다양한 지원 그룹과 지원 인

원을 포함할 수 있다. 이것은 지원 인원 교대를 통해 철야 근무를 하여 다음날 까지 작업을 진행할 수

도 있다. 이것은 전적으로 엄격하고, 잘 훈련된 접근 및 이해하기 쉬우며 유사한 결과를 보이는 작업

기록을 요구한다.

Tip

지원 그룹이 조사 또는 사용자와 관련된 인시던트 해결에 대해 명확하게 밝히지 못하면 모든 인시던트

에 대해 책임을 가지고 있는 서비스 데스크가 인시던트 관리 프로세스를 조율하여야 한다. 견해 또는

어떤 다른 이슈가 발생한다면 서비스 데스크는 인시던트를 문제 관리 팀으로 올려야 한다.

부록 5D는 인시던트 조사의 전형적인 프로세스를 보여준다. 진행상태 요약에서 지속적으로 증가하는

인시던트 기록은 각각의 작업 시점에 대한 로깅을 포함하여야 한다.

5.6.4. 해결과 복구

입력

! 업데이트된 인시던트의 세부 항목

! 인시던트 분석에 영향을 미치는 변경요청에서의 어떤 응답

! 추론된 임시 해결책 (Work-around) 또는 해결책

활동

! 변경요청 또는 해결책/임시 해결책 (Work-around)을 사용한 인시던트 해결

! 복구 활동

출력

! 장래 인시던트 해결을 위한 변경요청

! 복구에 대한 세부사항을 포함해 해결된 인시던트


해결 또는 활동의 성공적인 실행 후에 서비스 복구는 영향을 받을 수 있으며 종종 전문적인 직원에 의

해 복구 활동이 수행될 수 있다. 인시던트 관리 시스템 해결과 복구 활동 동안에 인시던트와 활동을

허용해야 한다.

5.6.5. 인시던트 종료

입력


! 해결된 인시던트

- 79 -


활동

! 고객과 해결에 대한 확인

! 종결의 범주

! 인시던트

출력

! 갱신된 인시던트에 대한 세부 사항

! 종결된 인시던트 기록

인시던트가 해결되었을 때 서비스데스크는 다음을 보증해야 한다.

! 간결하고 읽을 수 있는 인시던트를 해결하기 위한 활동의 세부 항목

! 근본 원인에 적합하고 완벽한 분류

! 고객과 동의된 해결과 활동

! 인시던트 제어의 관점에 적적한 모든 세부항목에 다음과 같은 것들이 기록된다

- 고객의 만족

- 프로젝트 코드 할당

- 인시던트에 소비한 시간의 기록

- 종결의 날짜와 시간, 사람에 대한 기록

팁

! 이 과정은 서비스 제공자와 고객 사이에 논쟁을 해결함에 있어 중요하다.

! 인시던트 종결 처리 순서에 제한된 접근이 가능해야 함은 중요하다. 그리고 이것은 서비스데

스크 관리자에 의해 제어되어야 한다.

! 인시던트는 부합하는 문제/알려진 오류 기록과 조화되어야 한다.

! 종결된 인시던트가 다시 시작되면 그 이유를 기록하고 나중에 작업이 필요하면 할당된 작업부

하 값을 조절하는 것이 중요하다. 하지만 나중에 작업이 필요치 않으면 새로운 인시던트는 원

래의 인시던트로 연결되어야 한다.

5.6.6. 소유권, 모니터링, 트래킹 그리고 커뮤니케이션

입력

! 인시던트 기록

활동

! 인시던트 모니터

! 인시던트 에스컬레이션

! 사용자에게 통지

출력

! 인시던트 진행에 대한 관리 보고서

! 에스컬레이션된 인시던트의 세부 항목

! 고객 보고서와 커뮤니케이션

- 80 -


서비스데스크는 다음과 같은 절차에 의해 모든 두드러진 인시던트의 해결을 검사하고 소유하기 위한

책임이 있다.

! 모든 인시던트의 서비스 수준과 해결로의 진행과 상태를 정기적으로 모니터

! 서로 다른 전문가 지원 그룹 사이에 이동하며 지원 그룹 사이에 논쟁을 일으키는 인시던트를

특히 주목

! 영향이 큰 인시던트를 모니터링하기 위해 주어진 우선순위

! 알려진 진행상태에 영향을 받는 사용자의 유지

! 비슷한 인시던트의 점검

이런 절차는 각각의 개인적인 인시던트가 가능한 빨리 또는 동의된 어떤 시간의 범위 내에서 해결될

수 있음을 보증하도록 도움을 줄 것이다. 보다 규모가 큰 서비스데스크는 인시던트 모니터링과 트래킹

을 위한 전담 팀의 설립을 고려해야 한다. 인시던트가 만족할 만한 진전을 달성하지 못할 경우 서비스

데스크는 잘 정의된 에스컬레이션 절차대로 행동해야 한다. 이런 절차들은 모든 지원 그룹에 의해 동

의되어야 한다. 그것은 지원 그룹이 너무 인시던트에 몰두하여 진단에 많은 시간을 소비하게 됨을 아

는 것이 중요하다.

팁

! 할당된 해결의 정보와 동의된 서비스 수준 대상을 어길 것 같은 인시던트 확인

! 에스컬레이션 제공자의 주의를 끌고 인시던트의 에스컬레이션을 간주하고 인시던트의 정보에

대한 기록

! 다음과 같은 과정과 에스컬레이션 값들에 동의

- 해결을 위해 동의된 시간과 여전히 해결되지 않은 요청이 75%를 경과했을 때 서비스데스

크는 진행에 할당된 해결자와 상의

- 그런 시간과 여전히 해결되지 않은 요청이 90%를 지났을 때 서비스데스크는 할당된 해결

자의 관리자와 상의

5.7. 인시던트 관리 프로세스의 역할

프로세스들은 조직의 계층에 걸친다. 그러므로 진행에 있어서 수행되어야만 하는 활동에 관련이 있는

책임을 지정하는 것이 중요하다. 조직의 규모가 작거나 비용 때문에 많은 조직의 역할이 병합될 수 있

다. 예를 들어 많은 조직들은 변경 관리와 구성 관리의 역할을 병합시킨다. 역할은 인가 수준과 작업,

책임의 설정을 포함한다.

5.7.1. 인시던트 관리자

인시던트 관리자는 다음의 책임이 있다.

! 효율적이고 효과적인 인시던트 관리 프로세스 운영

! 관리 정보 제출

! 인시던트 지원 직원의 활동 관리

- 81 -


! 인시던트 관리의 효과 모니터링과 개선안 도출

! 인시던트 관리 시스템의 유지와 개발

많은 조직에서, 인시던트 관리자의 역할은 서비스데스크 감독 관리자로 할당된다.

5.7.2. 인시던트 처리 지원 직원

가장 중요한 지원자의 책임은 다음을 포함한다.

! 인시던트 등록

! 인시던트가 종료되지 않을 때 지원 그룹으로 서비스 요청 전달

! 초기 지원과 분류

! 소유권, 모니터링, 트래킹 그리고 커뮤니케이션

! 제 2선 지원자에게 할당되지 않은 인시던트의 해결과 복구

! 인시던트의 종결

서비스데스크의 일부일 수도 있는 전문가그룹, 즉 제2 선 지원자는 다음과 같은 작업에 관계될 것이다.

! 서비스 요청 처리

! 영향을 받는 CI을 포함해 인시던트에 대한 세부사항 모니터링

! 인시던트 조사와 진단

! 가능한 문제의 발견과 문제 기록을 문제 관리 팀에 할당

! 할당된 인시던트의 복구와 해결

소유권, 모니터링, 트래킹 그리고 커뮤티케이션 작업은 다음을 포함한다.

! 모든 인시던트의 해결을 위한 진행과 상태의 모니터링

! 영향을 받는 사용자에게 진행 사항에 대해 통지

! 필요 시 에스컬레이션

5.8. 핵심 성과 지표 (Key Performance Indicators)

프로세스의 성능을 평가하려면 가끔 핵심 성과 지표 (Key Performance Indicators) 라고 말하는 측정할

수 있는 대상과 함께 명확히 지정된 목표가 설정되어야 한다. 다음의 측정 기준은 인시던트 관리 과

정을 위한 예제이다.

! 인시던트의 총 수

! 인시던트의 해결을 달성하기 위해 경과한 시간

! 동의된 응답 시간 내에서 처리된 인시던트의 비율

! 인시던트마다의 평균 비용

! 다른 수준의 지원 그룹으로 에스컬레이션 되지 않고 서비스데스크에 의해 종료된 인시던트의

비율

! 서비스데스크 워크스테이션마다 진행된 인시던트

! 방문할 필요 없이 원격에서 해결된 인시던트의 비율과 수

- 82 -


인시던트를 처리하는 서비스데스크와 지원 그룹 공동으로 일정과 분배 목록을 만들어야 하는 인시던트

관리자의 승인 하에 보고서가 만들어져야 한다. 분배 목록은 최소한 IT 서비스 관리와 전문가들로 구성

된 지원 그룹을 포함해야 한다. 예를 들면 서비스 수준 관리 보고서를 통해 사용자와 고객이 이용할

수 있는 자료를 만들어야 함을 고려해야 한다.

5.9. 도구

인시던트 관리 프로세스를 위한 도구의 요구사항은 다음과 같다:

! 메인 프레임, 네트워크, 서버 등등에서 결점을 발견한 이벤트에 대해 자동으로 인시던트 등록

! 서비스 요청과 인시던트의 처리를 돕기 위한 자동 에스컬레이션 시스템

! 영향을 받은 항목과 실패한 항목의 CMDB로부터 자료 기록의 자동 추출

! 특화된 소프트웨어: 속도와 효율성은 인시던트 처리의 주요 목적이기 때문에 성과는 인시던트

분류의 정확환 수준 및 경고 시점의 성공적인 대조에 의존적이다.

! ACD (전화 교환기) 시스템과의 통합으로 콜 인입 시 자동으로 사용자 전화번호와 사용자가 등

록되도록 한다.

! 진단 도구/모듈의 존재는 진단 프로세스를 보다 쉽게 해준다.

부록 5A: 인시던트/요청 분류를 위한 코딩 시스템 예제

인시던트의 유형 주요 범주 하위 범주 우선순위 표시

실패 소프트웨어 워드프로세스 2

스프레드쉬트 2

비즈니스 어플리케이션 1

하드웨어 메인프레임 1

미드레인지(Midrange) 1

워크스테이션 2

기타

서비스 요청 패스워드 재설정 1

토너 카트리지 변경 3

사용자 지원 사무용 소프트웨어 3

비즈니스 어플리케이션 2

기타

주석: 인시던트를 처리하기 위한 우선순위는 본래 Impact와 urgency에 의해 정의된다. 콜의 유형에 따

라, Impact와 urgency가 사전 정의된 데로 주어질 수 있다. 그러므로 우선순위는 가끔 경험이나 고객과

의 동의와 기대에 기반한다. 또한 인시던트의 유형으로 우선순위 사전 정의를 연결하면 분류 과정의

속도가 빨라지며 서비스데스크가 우선순위 할당에 일관성을 부여하도록 도움을 준다.

- 83 -


부록 5B: 우선순위 코딩 시스템의 예제

높음 중간 영향 낮음

높음 1 2 3

Urgency 중간 2 3 4

낮음 3 4 5

우선순위 코드 설명 대상 해결 시간

1 중요함 1시간

2 높음 8시간

3 중간 24시간

4 낮음 48시간

5 계획 계획

부록 5C: 서비스 인시던트 기록을 위해 필요한 자료

다음의 자료는 인시던트 라이프 사이클 동안 기록되어야 한다.

! 유일한 참조 숫자

! 인시던트 분류

! 기록된 날짜/시간

! 인시던트를 기록중인 사람과(이나) 그룹의 이름과 ID

! 통화한 사용자의 이름/부서/전화번호/위치

! 전화, 메일과 같은 Call에 대한 응답 방법 (Call-back method)

! 증상에 대한 설명

! 범주

! Impact/urgency/priority

! 활성, 대기, 종료와 같은 인시던트의 상태

! 관계되는 CI

! 인시던트가 할당된 지원 그룹/사람

! 관계되는 문제/알려진 오류

! 해결 날짜와 시간

! 종결의 범주

! 종결 날짜와 시간

- 84 -


완벽한 인시던트 라이프 사이클 동안에 제어를 하려면 모든 활동이 기록되어야 한다.

! 인시던트 해결 시도 중인 사람 혹은 지원그룹의 이름/ID

! 전달, 진단, 복구, 해결, 종료와 같은 활동의 유형

! 실행 날짜와 시간

! 실행의 결과와 설명

부록 5D: 인시던트 조사 과정

- 85 -


부록 5E: 서비스 데스크에서의 인시던트 처리

- 86 -

서비스관리를 위한 레퍼런스 요약집IT ITIL 6. 문제 관리

6.1. 문제 관리의 목표

문제 관리의 목표는 우발적 인시던트의 역효과를 최소화 하고, IT 인프라구조내의 오류로 인해 발생하

는 사업상의 문제들을 최소화 하며, 이러한 오류들과 관련된 인시던트의 재발을 예방하는 것이다. 이러

한 목적을 성취하기 위해, 문제 관리는 인시던트의 근본원인을 분석 한 후 이러한 상황을 개선하거나

올바르게 하기 위한 초기 행동을 취한다.

문제 관리 프로세스는 사전/사후 작업 모두를 포함한다. 사후 작업은 하나 이상의 인시던트에 대한 조

치로서의 문제 해결과 관련이 있다. 문제 관리 프로세스는 일어난 일에 대한 반응과 일어나기 전의 반

응 모두를 포함한다. 사전 행동적 문제 관리는 최초 인시던트가 발생하기 전, 문제와 알려진 오류들을

확인하고 해결하는 것과 관련되어 있다.

6.2. 문제 관리의 영역

문제 제어(Problem Control), 오류 제어(Error Control) 그리고 선 예방적 문제 관리(Proactive Problem

Management) 모두는 문제 관리 프로세스 범위 내에 있는 것들이다.

이에 대하여 형식적인 정의를 내려보면 ' 문제 '란 하나 이상의 인시던트들에 잠재하여 있는 알려지지

않은 원인을 말하는 것이며, ' 알려진 오류(Known Error)' 란 성공적으로 원인이 밝혀진 문제로서 이러한

문제에 대하여 '해결책(Work-Around)'이 이미 밝혀져 있는 경우(증명되어 있는 경우)를 말한다.

문제 관리 프로세스에 입력할 사항은 다음과 같다.

! 인시던트 관리부터의 세부 인시던트들

! 구성 관리 데이터베이스로부터의 세부 구성(CMDB) ! 인시던트관리로부터 정의된 임시 해결책

문제 관리의 주요 활동은 다음과 같다.

! 문제 제어

! 오류 제어

! 발생 가능한 문제의 사전 예방

! 동향 확인

! 문제 관리 데이터로부터 관리 정보 취득

! 중요 문제의 검토 완료

이러한 프로세스에 의해 산출 되는 것은 다음과 같다.

! 알려진 오류

! 변경 요청 (RFC: Request for Change)

! 문제기록의 업데이트(해결책 혹은 사용가능 한 임시 해결책)

- 87 -


! 해결된 문제에 대한 종결 기록

! 문제와 알려진 오류에 매칭되는 인시던트에 대한 해결책

! 관리 정보

6.3. 기본 개념

인시던트 발생 초기 단계에서 적절하고 보다 용이하게 접근하는 인시던트의 해결 시도는 인시던트를

효과적으로 해결하는데 있어서 조직이 가지는 핵심 능력이다. 서비스데스크에 접수되는 인시던트들이

전혀 새로운 것이거나 지원 요원들이 이해할 수 없는 경우란 거의 없다.

이와 비슷하게, 제 2선 지원 요원 혹은 제3선 지원 요원들 내의 전문가들은 이미 많은 문제들, 그

리고 '새로운' 인시던트들과 문제들을 해결해 오고 있을 것이다.

이러한 해결책을 위해 쓰이는 리소스를 최적으로 사용하는 방법은 최일선 요원이 적용할 수 있는

방식으로 이러한 해결책을 문서화하는 것이다.

문제 관리 프로세스는 인시던트가 발생하는 횟수와 심각도 그리고 업무상의 문제들을 줄이기 위한

것을 목적으로 한다. 그러므로, 문제 관리의 부분적 목적은 최일선과 제2선 요원들이 즉각 이용할

수 있는 방식으로 이전 사례 및 정보들이 문서화되어 있어야 한다는 점을 확실하게 하기 위한 것

이다. 그러나 이것이 단순히 문서 작성의 중요성을 뜻하는 것은 아니다. 이러한 문제 관리에 요구

되는 것은 다음과 같다.

! 새로운 인시던트 발생시 간단하고도 찾기 쉬운 트리거(trigger)를 통해 쉽게 인용참조 할 수 있

도록 정보의 색인화

! 상황변경에 따른 문서의 적정성 보장을 위한 정기적 감사

- 기술

- 사용 가능한 외부 솔루션

- 비즈니스 사례 및 요구

- 내부 스킬

- 인시던트 발생 빈도 및 파급 정도

! 이와 같은 프로세스는 상세한 재검토를 거쳐야 함

! 정보를 이용하는 요원들에게 가용 정보의 정도와 영향력과 이러한 정보에 대한 접근법과 해독

법을 숙지시키고, 가용정보의 적절성과 이용 편이성에 관한 피드백을 제공하는 것이 요원들의

역할이라는 것을 숙지시키기 위한 교육

! 정보에 관한 적절한 보고 -- 이러한 것은 인시던트 처리 프로세스의 초기 분석 단계나 로깅 단

계에서 정보를 포착할 수 있는 통합 서비스 관리 도구에 일반적으로 기초한다.

문제 관리 프로세스를 용이하게 하기 위해 '전문가 시스템(Expert System)' 소트프웨어를 사용하는

게 일반적이다. 그러나 중요한 점은 이러한 소프트웨어는 전문 지식과, 시스템을 사용하는 요원들

로부터 나오는 최신 피드백을 포함해야 한다는 것이다.

- 88 -


문제와 알려진 오류는 다음과 같은 것으로 확인할 수 있다.

! 인시던트 발생 시 인시던트 분석 [반응적 문제 관리(Reactive Problem Management)]

! 시간대 별 인시던트 분석 [예방적 문제 관리(Proactive Problem Management)]

! IT 기본구조의 분석

! 지식 데이터베이스의 준비(the provision of a knowledge database)

문제는 일반적 징후를 보이는 복합적인 인시던트들의 결과로서 확인된 상태를 말한다. 또한 문제는

원인은 알려져 있지 않지만, 발생시 파급 효과가 큰 하나의 중대한 인시던트로부터 식별되기도 한

다.

알려진 오류는 어떤 문제의 근본 원인을 성공적으로 판단 분석하고, 그 이후 임시 해결책(Work-

Around)이 마련된 상태를 말한다. IT 인프라스트럭쳐의 구조 분석, 지원 소프트웨어에 관한 보고,

사용자-그룹 미팅을 통해서도 문제와 알려진 오류를 확인할 수 있는 경우가 있다. 이러한 것들은

예방적 문제 관리(Proactive Problem Management)라 한다.

문제 관리(Problem Control)는 문제를 알려진 오류(Known Error)로 변경시키는데 초점을 맞춘다.

오류 제어(Error Control)는 변경 관리 절차(Change Management Process)를 통해서 알려진 오류를

구조적으로 해결하는데 중점을 둔다.

6.3.1. 인시던트 관리와 문제 관리는 무엇인가

문제 관리는 한 인시던트의 근본원인 발견과 이러한 원인에 대한 후속 해결조치이다. 많은 경우에 문

제 관리 목표는 인시던트 관리의 목표와 직접적으로 충돌하기도 한다.

왜냐하면 인시던트 관리의 목적은 영구 해결책의 결정 확인 (예를 들면, 미래에 발생하는 인시던트들을

가능한 많이 예방하기 위해 IT 인프라스트럭쳐의 구조적 개선을 추구함으로써 영구 해결책을 모색하는

것) 보다는 임시 해결책(Work-Around)을 통해 가능한 신속하게 소비자에 대한 서비스 제공 중단 상황

을 복구하기 위한 것이기 때문이다.

그러므로 이러한 점에 있어서, 해결책을 발견하는 속도(신속성)는 단지 부차적인(비록 여전히 중요한

것 중 하나이긴 하지만) 중요성을 가질 뿐이다. 잠재적 문제의 조사에는 시간이 필요하므로, 서비스 복

구의 지연을 초래하고 다운타임의 원인이 되기도 하지만 문제의 재발을 방지할 수 있다.

6.3.2. 문제 제어(Problem Control)

문제 제어 프로세스는 효과적이고 효율적인 방식으로 문제를 처리하는 것과 관련이 있다. 문제 제어

(Problem Control)의 목적은 CIS 고장과 같은 근본적 원인을 확인해서, 가능할 때 해결책에 관한 정보

와 어드바이스를 서비스 데스크(Service Desk)에 제공하는 것이다.

- 89 -


문제 제어 프로세스는 인시던트 제어 프로세스와 성질상 매우 유사하며, 인시던트 제어 프로세스에

상당부분 의존한다.

인시던트 제어(Incident Control)는 인시던트를 해결을 위한과 임시 해결책(Temporary Fixes)을 제공

하는데 초점을 맞춘다. 한 인시던트나 일련의 인시던트에 대한 문제가 확인되면, 문제 제어 절차에

따라 문제 기록에 이용 가능한 해결책과 임시 해결책이 기록된다.

문제 제어는 인시던트 재발을 방지하는 것과 관련되어 있기 때문에, 이러한 프로세스는 조심스럽게

관리되고 계획된 접근법을 통해 이루어져야 한다.

문제 제어는 정상적인 서비스를 될 수 있는 한 신속하게 재개 하는 게 목적인 인시던트 제어보다

높은 수준의 관리와 계획이 요구된다. 심각한 업무상 혼란을 초래할 수 있는 문제들의 해결에 우선

순위(Priority)를 두어야 한다.

문제 제어에서 승인된 행위는 다음과 같다.

! 문제 확인과 기록

! 문제 분류

! 문제 조사와 진단법 6.3.3. 오류 제어

오류 제어는 변경 관리 절차(Change Management Process) 감독하에 성공적으로 변경을 완수함으로써

알려진 오류가 제거되기 전까지, 인지 오류(Known Error)를 해결 프로세스를 포함하는 절차들을 다룬다.

오류 제어(Error Control)의 목적은 오류를 인식하고, 오류를 모니터 하며, 가능하고 비용이 적당할 때

오류를 제거하는 것이다.

오류 제어(Error Control)는 개발 (어플리케이션 개발, 확장 유지보수를 포함)과 당면한 환경(상황)사이에

다리를 놓는 역할을 한다. 개발 단계에서 나타나는 소프트웨어 오류는 실제 적용프로세스에 영향을 끼

칠 수가 있다. 그러므로 개발 혹은 유지 상태에서 확인된 알려진 오류는 실제로 적용되는 부서로 넘겨

져야 한다.

오류 제어 에서 인정된 행동은 다음과 같다.

! 오류 확인과 기록

! 오류 평가

! 해결된 오류기록 (해결에 대한 조사, RFC를 올리는 것)

! 오류의 종료

! 문제와 오류해결 경과를 모니터링

실제 문제가 되는 것으로서, 이러한 문제 관리의 각각 프로세스에는 신중한 관리와 제어가 요구된다.

이러한 각각의 제어 프로세스 중에 개별적인 운영 목표가 적용된다.

- 90 -


6.3.4. 예방적 문제 관리

예방적 문제 관리(Proactive Problem Management)는 인시던트가 발생하기 전 문제들을 확인하고

해결하는 것을 목적으로 한 행위들을 다룬다. 이러한 활동들에는 다음과 같은 것이 있다:

! 트랜드 분석

! 대상을 지정한 지원

! 조직에 정보를 제공

인시던트에 대한 대응에 들이는 노력을 인시던트 예방에 돌림으로써, 조직은 소비자들에게 보다 나은

서비스를 제공할 수 있으며, IT 지원 기구 내에서 가용 가능한 자원들을 보다 효과적으로 이용할 수 있

게 된다.

6.3.5. 주요 문제 재 검토 완료

이러한 재검토 프로세스를 통해 피드백 함으로써 개선 프로세스를 지속적으로 수행할 수 있다.

6.4. 문제 관리의 이익

문제 관리를 수행함으로써 얻을 수 있는 이익은 다음과 같다.

! IT 서비스의 질 개선: 문제 관리는 급속히 증대되고 있는 IT 서비스의 질적 순환을 형성하

는데 도움이 된다. 양질의 신뢰성 높은 서비스는 IT 비즈니스 이용자들에게 유익하며, IT

서비스 제공자의 생산성과 사기에도 도움이 된다.

! 인시던트발생(율)의 감소: 문제 관리는 업무 수행에 방해가 되는 인시던트 발생 건수를 감

소시키는데 도움이 된다.

! 영구 해결책: 문제와 알려진 오류가 계속해서 해결됨으로써, 문제와 알려진 오류의 발생건

수 및 영향이 점차적으로 감소하게 된다.

! 조직내(조직원들의) 학습 증대: 문제 관리 프로세스는 이전의 경험으로부터의 학습이라는

개념에 기초하고 있다. 이러한 프로세스를 통해 일정한 추세(동향, 유행)에 대한 과거의 데

이터를 제공하고, 실수를 예방하고 실수로 발생하는 영향을 감소시키는 수단을 제공함으로

써 결과적으로 이용자 생산성의 증대를 가져온다.

! 고객 지원 부서(Service Desk)의 초기 해결 비율 증대: 문제 관리를 통해 서비스 데스크는

콜 로깅(Call Logging)에서 이용할 수 있는 인지된 데이터베이스 내의 해결책 데이터(Work-

Around Data)와 인시던트 해결책의 포착, 보유, 이용을 통해 획득된 정보를 통해서, 서비스

데스크의 초기 해결 비율을 증대 시킬 수 있다.

이와 반대로, 문제 관리 프로세스를 실시하지 않음으로써 나타나는 비용은 다음과 같다.

! 단순히 문제 발생 시에만 대응하는 지원 조직은, 소비자에 대한 서비스가 이미 불통이 되

었을 때에만 문제들에 대처하게 된다.

! IT 사용자 조직은 인시던트의 재발에 직면하여, IT 지원 기구의 질에 대한 신뢰를 잃게된다.

! 고비용이고 종업원의 사기가 낮은 비효율적 지원 기구를 초래한다. 왜냐하면 유사한 인시

던트들을 반복해서 해결해야 하고 구조적 해결책은 제공되기 않기 때문이다.

- 91 -


6.5. 계획과 이행

6.5.1. 타이밍과 계획

타이밍과 계획이 중요하다.

! 양질의 문제 관리는 효과적인 인시던트 관리(Incident Management)에 상당 부분 의존한다.

그러므로 인시던트 관리 프로세스와 동시에, 아니면 인시던트 관리 프로세스 후에 문제 관

리를 시행하는 게 현명하다.

! 만일 리소스가 별로 없다면, 우선은 문제와 오류 제어(즉 대응적 문제 관리)를 시행하는데

집중하는 게 현명하다. 이러한 조치들이 완성되면, 리소스를 예방적 문제 관리(Proactive

Problem Management)로 돌릴 수 있다. 예방적 문제 관리의 질은 서비스 모니터링 활동과

이를 통해 획득된 기초 데이터의 성공적인 이행에 상당부분 달려있다.

! 조직이 소규모인 경우에는 이전날의 ' Top 10' 인시던트들에 매일 초점을 맞춤으로써 대응

적 문제 관리를 채용할 수 있다. 이러한 것은 효과적일 수 있다. 왜냐하면 경험을 통해 볼

때, 문제의 20%가 서비스 단절의 80%를 차지한다는 걸 보여주기 때문이다.

6.5.2. 성공 핵심 요인

고려해야 할 점에는 다음과 같다.

! 효과적인 분류를 통해, 인시던트를 효율적으로 자동 등록케 하는 것은, 문제 관리의 성공

에 중요한 요소이다.

! 성취 가능한 목적을 설정하고 기존 요원들 중 문제 해결에 재능이 있는 사람을 이용하는

것은 중요 고려 사항이다. '파트-타임(part-time)' 문제 관리를 고려해 보라. 이것을 통해 요

원들은 일상적 임무를 제쳐두고 문제를 살펴볼 수 있는 시간을 가질 수 있을 것이다.

! 인시던트 관리와 문제 관리 사이에 잠재하여 있는 대립적 이해관계를 볼 때, 이 두 프로세스 사이의 상호 보완 및 협력이 필수적이다. 또한 이 두 프로세스는 엄청난 시너지효

과를 가지고 있으므로, 상호간에 도움이 될 것이다. 두 프로세스에 관여하곤 하는 지원 요

원들은 두 프로세스 사이에서 이루어지는 행위들의 균형을 맞추는 것이 중요하다는 것을

인식하여야 한다.

6.5.3. 위험요인

문제 관리의 장점(Benefits)은 다음과 같은 것을 통해 감소할 수 있다.

! 적절한 인시던트 제어 프로세스의 부재와 이를 통해 발생하는 인시던트들에 대한 상세한

기록 데이터의 부재

! 문제/오류 기록과 인시던트 기록의 연계 실패. 이는 상당한 잠재적인 유용성의 획득에 실

패했음을 의미한다. 이러한 실패는 대응적 지원(Reactive Support)에서 보다 계획적이고 예

방적인 지원 접근법으로 옮겨가는 데에서 나타나는 주요한 특징이다.

! 관리 책임의 결여. 이로 인해 지원 요원(보통 대응적 인시던트 제어 활동에도 관련되어 있

다)들은 구조적 문제 해결 활동에 충분한 시간을 할당할 수 없다.

- 92 -


! 서비스데스크 역할 침범. 문제 관리 요원은 허가 받은 출처로부터의 지원 요청만 받아들여

야 한다. 만일 문제 관리 프로세스 중 다양한 부서로부터 요구를 처리하게 되면 문제가 발

생할 것이다. 왜냐하면 동일 원인을 가진 인시던트들에 대한 다양한 보고서들이 동일한 방

식으로 해석되지는 않기 때문이다.

! 정보 베이스(Knowledge Base)를 구축하고 유지하는 시간을 갖지 못하면 이러한 장점들을

얻는데 제한이 있을 것이다.

! 인시던트와 문제의 업무에 끼치는 영향력을 정확히 측정하는 능력 부족

6.6. 문제 제어 활동

실제적으로 인시던트의 발생은 피할 수 없는 일이다. 컴퓨터 장비와 통신 라인은 종종 고장 나기도 한

다. 기타 상당수의 인시던트들은 임의적인 고장뿐만이 아니라, 조직 내에서 점차 복잡해 지고 있는 IT

인프라스트럭쳐의 일부에서 오류가 발생함으로써 발생한다.

대응적 문제 제어(Reactive Problem Control)은 미래의 인시던트 재발을 방지하기 위해 인시던트의 실제

적인 근본 원인을 확인하는 것과 관련이 있다. 대응적 문제 제어 프로세스의 세 단계는 다음과 같다.

! 문제 확인과 기록

! 문제 분류 - 업무상 미치는 영향력에 따라

! 문제 조사와 진단

그림 6.1 – 문제 제어

- 93 -


6.6.1. 문제 확인과 기록

문제 확인(Problem Identification)은 다음과 같은 경우 발생한다.

! 인시던트의 초기 지원과 분류를 하는 단계에서, 실제 발생하고 있는 문제와 알려진 오류를

위한 프로세스의 매칭이 성공적이지 못한 경우

! 인시던트 데이터 분석결과 재발 인시던트(Recurrent Incidents)인게 드러난 경우

! 인시던트 데이터 분석결과 현존 문제(Existing Problems) 혹은 알려진 오류와 여전히 일치

지 않는 인시던트인게 드러난 경우

! IT 인프라스트럭쳐를 분석한 결과 문제가 잠재적으로 인시던트를 가져올 수 있다는 게 드

러났을 때

! 주요 혹은 중대한 인시던트(고객 서비스에 심각하고 불리한 영향을 가져오는) 가 발생해서

구조적 해결책을 찾아야 할 때

일부 문제들은 문제 관리 팀 이외의 용량 관리와 같은 외부 인사에 의하여 확인될 수도 있다는 점을

주의 해야 한다. 그럼에도 불구하고 모든 문제는 문제 관리 프로세스를 통해서 통보되고 기록되어야

한다.

가용성 관리 프로세스의 상당수는 IT 인프라스트럭쳐에 대한 문제와 인시던트 발생을 검출하고 회피하

는 것과 관련이 있다. 그러므로 이러한 두 분야 사이에서 발생하는 시너지는 서비스 질의 향상을 위해

서 아주 중요한 도움이 된다.

Tips

! 문제 관리는 노력과 리소스가 요구되므로, 비용이 많이 들 수도 있다. 조직은 신속한 해결

책이 있고, 충격이 적거나, 재발의 가능성이 낮은 인시던트들과 같은 것에 노력과 비용을

투입하는 것은 적합하지 않다고 결정할 것이다. 이러한 경우 CMDB에 알려진 오류, RFCs

그리고 CI와 같은 모든 관련 인시던트와 연관된 명목상의 문제 기록(Dummy Problem

Record)이 도입될 수도 있다.

문제 기록은 데이터베이스에 기록되어야 하며, 이러한 점에서 인시던트 기록과 매우 유사하다. 이 둘은

보통 타당성이 없는 표준 인시던트 데이터(예를 들면, 사용자 데이터)를 차단한다.

그러나 문제 기록은 모든 관련 인시던트 기록과 연결되어야 한다. 인시던트에 관한 해결책과 임시해결

책(Work-Arounds)이 관련된 문제 기록에 기록되어야 한다. 왜냐하면 다른 관련 인시던트가 발생했을

때 다른 이들도 이러한 해결책들에 접근할 수 있도록 하기 위해서이다.

- 94 -


그림 6.2 – 인시던트 매칭 프로세스 플로우

그림 6.2에 나타나 있듯, 문제 확인 프로세스는 문제에 대한 기본 분류가 포함되어 있다. 고장 난 CI

(Configuration Item)의 데이터들은 이러한 기본 분류 데이터에 정확하게 추가 기록되어야 한다. 이론적

으로 보면, 이러한 CI들은 분리 교정(Discrete Amendment)이 가능한 최하위 목록들이다. 예를 들면, 어

플리케이션 코드나 하드웨어 구성요소의 모듈 등 이다. 그러나 이러한 수준의 CI 문제를 확인하는 것

이 문제 식별 단계에서는 불가능할 때도 있다.

- 95 -


6.6.2. 문제의 분류

문제가 확인되면, 고장 난 CI를 검출하고 복구하는데 요구되는 투입 노력의 정도가 결정되어야 한다.

그러므로 기존 서비스 수준에 미치는 문제의 영향력이 어느 정도인가를 인식하는 건 불가능하다. 이러

한 프로세스는 '분류'로 알려져 있다. 실제적으로 지원을 투입하는 곳은은 단일 인시던트(Single

Incident)에 관련된 문제들의 일부분이다.

문제 분류의 절차는 인시던트를 분류하는 절차와 유사하다. 문제 분류 절차에서는 다음과 같은 것을

결정한다.

! 카테고리

! 요소(영향, 요인)

! 긴급성

! 우선순위

문제를 관련 그룹 혹은 관련 범위(예를 들면, 소프트웨어, 하드웨어, 지원소프트웨어 및 기타 관련된 것

들 모두)로 분류한다. 이러한 그룹들은 조직 내 책임자들 혹은 사용자와 고객 기반과 일치 될 수 있으

며, 문제를 지원 요원들에게 할당하는 근거가 된다. 부록 6A는 문제를 분류하는 간단하지만 효과적인

구조의 예이다.

새로운 문제를 확인한 후에는 문제의 영향 (즉, 문제가 업무에 끼치는 영향)을 객관적으로 분석해야 한

다. CMDB에 기록된 IT 인프라스트럭쳐의 구성요소들 사이의 관련성은 문제의 영향력을 결정할 때 상

당한 도움이 될 수 있다.

조직들은 업무상의 필요성이 있는 조직 자체내의 임팩트 코딩 시스템(Impact Coding System)을 설계해

야만 한다. 임팩트 코딩(Impact Coding)은 지원을 효과적으로 할당하는데 있어 가장 유용한 메커니즘이

다. 영향력에 종속된 단순 우선 순위율(Simple Priority Rating)을 더 많이 삽입함으로써 전체적인 제어

메커니즘을 제공할 수 있다.

문제의 영향력을 결정할 때 CMDB에 기록된 IT 인프라스트럭쳐의 구성요소들 사이의 관련성은 상당한

도움이 될 수 있다. CMDB를 조사함으로써, 인시던트가 일어나는 IT 인프라스트럭쳐의 CI에 부분적으로

종속되는(혹은 CI와 동일한) CI를 확인할 수가 있다.

긴급성(Urgency)은 문제 혹은 오류의 해결책이 지연되는 것을 견딜 수 있는 정도를 말한다. 따라서 우

선순위(Priority)와 혼동해서는 안 된다. 우선순위(Priority)는 일련의 아이템들 (예를 들면 인시던트, 문제,

변경 혹은 오류 같은) 이 배열되는 상대적인 순서를 나타낸다. 이러한 우선순위(Priority)는 위험(Risk)과

리소스 가용성(Resource Availability)을 고려함으로써 영향을 받기도 하지만, 주로 긴급성(Urgency)과 영

향(Impact) 모두를 함께 고려해서 결정된다.

- 96 -

서비스관리를 위한 레퍼런스 요약집IT ITIL 업무상 미치는 영향력이 낮음에도 불구하고, 긴급한 해결책이 요구되는 어떠한 사항들은, 업무에 영향

을 끼칠 가능성이 매우 높지만 긴급성은 덜한 어떠한 사항을 처리하기 전에, 처리되어야 하는 경우가

있을 것이다. 각각의 사항에 순위 가치(Numerical Values)를 매겨, 이러한 순위 가치로부터 우선순위

(Priority)를 도출해 내는 것이 도움이 될 때도 있겠지만, 모든 서비스 관리(Service Management)가 그렇

듯이, 이러한 순위들은 상식과 업무상 인지에 따라 변경되어야 한다.

긴급성과 영향력 각각에 1부터 4의 순위가치를 매겨, 어떠한 문제가 발생시, 그 문제에 대하여 긴급성

몇 점, 영향력 몇 점 이렇게 점수를 매긴 후, 그 점수를 합하여 총계를 낸 후, 이를 가지고 문제들 사

이의 우선순위를 매기는 것도 유용한 방법이 될 것이다.

이러한 게 완료되면, 조직은 산출된 우선 순위를 비판적으로 모니터하고 감사해야 하며, 자신들의

요구사항을 반영하기 위해 이러한 기능을 모니터 해야 한다. '긴급성(Urgency)'과 '우선순위(Priority)'

는 부록 A를 참조한다.

긴급성에 영향을 미치는 점들은 다음과 같은 예가 있다.

! 임시 해결책의 가용성

! 임시 해결책의 존재

! 해결책의 계획된 지연 가능성

! 월말 결산 절차를 지원하기 위해 요구되는 장비와 같이, 장래 업무에 미칠 수 있는 영향력의

인식

모든 인시던트, 문제 그리고 변경은 비즈니스 서비스에 미치는 영향력과 긴급성을 가지고 있다.

! 영향력은 비즈니스상 취약한 부분이 있을 가능성(잠재성)을 나타낸다.

! 긴급성은 이러한 영향력을 피하거나, 최소한 감소시키는데 이용할 수 있는 시간을 나타낸다.

Tips ! 초기 단계에서 기회가 있을 때, 모든 문제에 대하여 임팩트 코드를 할당하라. 이러한 임팩트

코드가 완료되면, 상세한 조사를 시작하기 전에, 모든 문제를 관리 부서에 할당하는 게 중요하

다. 할당을 받은 직원은 이러한 문제에 책임을 지며 그래서 모든 커뮤니케이션과 이러한 문제

에 대한 해결 조치를 통합 조정하는 근원이 된다. 즉각적 조치를 취해야 하는 주요 문제들을

영향력에 따라 투입 일정을 작성하라. 이러한 리소스-제어 프로세스가 특정 시간 한계를 초과

한 낮은 영향력 문제들을 고려하고 있는지의 여부를 확실하게 확인 하라.

! 영향력을 분석하는 프로세스에는 한가지 주요한 장애물이 있다: 그건 바로 단편적인 전망

(Snapshot View)이다. 어떤 문제가 로우 임팩트 코드(Low Impact Code)로 올바르게 지정되었다

고 해도, 이 문제로 인해 인시던트의 가파른 증가가 있다면 아마도 이러한 문제는 즉각적인

조치를 필요로 할 것이다. 인시던트 임계치(Incident Thresholds)를 설정할 때는 이러한 어려움

을 염두 해 설정하여야 한다. 그림 6.2에 나타나있듯이, 문제 관리프로세스는 인시던트 기록

(그리고 알려진 오류 기록)내 인시던트와 일치하는 카운트를 유지할 수 있도록 설계될 수 있다.

문제와 오류 제어 시스템은 정기적으로 이러한 카운트를 검색해서, 이러한 카운트를 사전 설

- 97 -


정된 임계치와 비교할 수 있다. 이러한 카운트가 임계치 값과 같거나 혹은 초과 할 때, 이러한

문제/알려진 오류는 즉각 조치를 받는 단계로 올라가야 한다. 그러나 이러한 카운트가 항상 중

요성을 표시해주는 것은 아니라는 점을 인식하여야 한다.

6.6.3. 문제 조사와 진단

문제 조사 프로세스는 인시던트 조사 프로세스와 유사하다. (5장 참조) - 그러나 이 둘 프로세스의 주요

목적에는 상당한 차이점이 있다.

인시던트 관리의 목적은 서비스의 신속한 재개이며, 반면에 문제 관리의 목적은 근본 원인의 진단이다.

조사 활동에는 인시던트 기록 데이터베이스에 등록되는 문제들과 관련된 인시던트들에 대한 가용 가능

한 임시 해결책(Work-Around)를 포함하고 있어야 한다.

문제 관리 활동에는 인시던트 제어(Incident Control)를 지원하기 위해, 문제 기록 내에 최신의 추천 임

시해결책을 포함해야 한다.

가끔씩 진단결과를 통해, 어떠한 문제의 원인이 기록된 CI 내의 오류 때문이 아니라 절차상의 문제라

는 게 드러날 때가 있다. 어떤 프로그램의 특정 버전이 부정확하게 출시되는 게 그 한 예이다. 이러한

문제들은 적절한 분류 코드를 통해 종료된다. 이러한 형태의 문제들로 인해 알려진 오류(Known Error)

가 자동적으로 공식화(Formal)되는 것은 아니다. 이러한 문제를 철저히 추적하고, 이러한 문제에 대해

조치를 취하는 것을 보장하기 위해서는, 이 문제를 알려진 오류로 재 분류하는 것을 고려하거나, 아니

면 RFC를 발생시켜야 한다.

이전부터 지적되어 왔듯이, 문제 조사의 목적은 인시던트 해결 목적과 종종 충돌하고는 한다. 예를

들면, 문제 해결에는 인시던트가 발생했을 때에만 이용 가능한 상세한 진단 데이터가 요구된다; 이

러한 데이터들은 정상적인 서비스의 복구를 상당히 지연시킬 것이다.

문제 분석의 방법

다음은 문제 제어(Problem Control)와 관련해 꼭 기억해야 할 중요한 점을 나타낸 것이다.

! Kepner and Tregoe (부록 6B 참조)

! Ishikawa diagrams (부록 6C 참조)

! brainstorming sessions

! flowchart methods

문제 관리는 조직의 목적에 가장 부합하는 방법을 선택해야 한다.

6.6.4. 문제 제어 팁

다음은 문제 제어와 관련해 꼭 기억해야 할 중요한 점을 나타낸다.

! 인시던트의 분류를 통해 문제 정의의 첫 단계를 내디딜 수 있다. 그러므로 문제 관리는, 일반

적 인시던트와 문제를 분류하는 것에 관한, 인시던트 관리와 밀접하게 관련되어야 한다. '일

- 98 -


반적 용어'로 보고된 인시던트들의 기록 및, ' IT 용어'로 더 자주 표현되고는 하는 최종 검출

원인을 기록하기 위해서라도, 적절한 카테고리를 만들어야 한다.

! 가능하면, 여러 가지 전문분야를 가진 팀(예를 들면, 조정자로서 문제 관리팀) 을 만들어라. 왜

냐하면 조사 프로세스에서 서로 다른 관점에서 다양하게 접근하기 위해서이다.

! 참여 지원 전문가들은 자신들의 임무를 효과적으로 수행하기 위하여 적절한 도구가 진단상 도

움을 줄 수 있다는 것을 명심하여야 한다.

! 만일 어떠한 문제가 시스템 구성상의 오류때문이 아니라, 소위 사용자 교육의 일반적인 결여

때문에 발생한 것이라면, 해결 조치를 실행하고 문제 기록은 종료하라. 이에 대한 대안으로,

새로운 CI 기록(이 예에서는 ' 교육 문제'를 위한)을 만들 수도 있으며, 따라서 이러한 문제는

일반적 형태의 알려진 오류로 변경될 수도 있다. 이렇게 검출된 원인들은, 사용자 정보와 사

용자 교육의 결여와 같은 상황을 반영한다는 점을 명심하라.

! 인시던트 혹은 문제 제어 프로세스중의 조사 절차에는 다음과 같은 점이 요구된다. IT 인프라

스트럭쳐 내 모든 제품에 대한 문서를 이러한 프로세스 중에 이용할 수 있어야 하며, 직원들

이 참조할 목적으로 이용할 수 있어야 한다. 이러한 것들은 다음과 같은 문서들을 포함한다:

- 어플리케이션 시스템

- 시스템 소프트웨어

- 네트워크 하드웨어 및 소프트웨어

- 전반적인 구성 및 네트워크 다이어그램

! 제품 정보와 함께, 문제 해결에 대한 진단 데이터를 수집할 수 있는 효과적인 절차도 필요하

다. 인시던트 발생 시 어떠한 부적절한 이용도 일반 IT 서비스의 재개를 지연시킬 수 있기 때

문에, 지원 요원들이 이러한 절차에 익숙해 져야 하는 게 특히 중요한 점이다. 그러므로 프로

세스를 진행하는 도중 요구되는 점들을 지원하고 보강하는 절차도 필요하다. 그리고 이러한

절차들에는 적절한 교육, 적절한 자격 등이 있을 것이다.

! 종종, 지원 전문가들은 인시던트 관리 프로세스와 문제 관리 프로세스 둘 모두에 참여하기도

한다. 이러한 프로세스들의 목적이 다르다는 점(신속한 해결 vs 구조적 해결)을 명심하면, 이

러한 전문가들에게 고정된 할당율을 두 프로세스 모두에 할당하는 게 유용하다는 것을 알게

될 것이다. 아마도 인시던트 관리에 80%를, 문제 관리에 20%를 할당하는게 적당할 듯하다.

이렇게 함으로써 지원 전문가들이 대응적 인시던트 관리에만 몰두하게 되는 것을 방지할 수

있다.

! 인시던트와 문제 조사를 할 때, 문제 관리 요원들은 최근 변경 내용을 정확하게 기록해야 할

필요성이 있다. 왜냐하면 이러한 것들이 원인에 대한 포인터가 될 수도 있기 때문이다.

6.7. 문제 제어 활동

오류 제어는 알려진 오류를 성공적으로 수정한 프로세스들을 포함한다. 오류 제어의 목적은 IT 인프라

스트럭쳐에 영향을 주는 알려진 오류를 제거하기 위해 IT 구성요소들을 변경하는 것이며, 이렇게 함으

로써 인시던트의 재발을 방지 할 수 있다.

상당수의 IT 부서들은 오류 제어에 관여하고 있으며, 이러한 관여는 실제 사용 환경뿐만 아니라 개발

- 99 -


환경에까지 미친다. IT부서들은 변경 관리 프로세스와 직접적으로 결부되어 있으며, 변경 관리 프로세

스와 밀접한 관련을 가지고 운영된다. 그림 6.3은 오류 제어 프로세스의 세가지 단계를 나타낸다. 모니

터링과 트랙킹 단계는 문제/오류 라이프 사이클 전체를 포함한다.

Figure 6.3 – 오류 제어

6.7.1. 오류 확인과 기록

장애가 발생한 CI (인시던트를 발생시키는 혹은 발생시킬것 같은 CI)가 검출될 때 하나의 오류가 확인

된다. 알려진 오류 상태는 어떤 문제의 근본 원인이 발견되고 이에 대한 임시해결책이 확인되었을때

지정된다

오류 제어 시스템으로 흘러 들어가는 알려진 오류 데이터의 소스에는 두 가지가 있다. 하나는 사용 환

경에서의 문제 제어 하위시스템과, 다른 하나는 개발 환경 내에서의 문제 제어 하부시스템이다. 실 운

용 중에 발견되는 오류들은 문제 제어 활동 조사와 진단에서 설명한 것처럼, 확인되고 기록된다. 이러

한 경우, 문제 기록은 알려진 오류 기록의 기본이 된다. (반면 실제로 이것은 상태 변경만을 포함한다)

알려진 오류의 두 번째 소스는 개발 수행에서 나타난다. 예를 들면, 새로운 어플리케이션 혹은 패키지

릴리즈의 수정 판에는 개발 단계에서 나타난, 알려져 있지만 아직 해결되지 않은 오류들이 포함되어

있을 것이다. 개발 단계에서의 알려진 오류를 나타내는 데이터들은 어떤 어플리케이션 혹은 릴리즈 패

키지가 수정 될 때, 실제 사용 환경에서 관리자들이 이용할 수 있도록 만들어져야 한다.

상당수의 IT 부서들은 이러한 일련의 이벤트 처리를 담당한다. 문제 관리 시스템은 모든 해결 조치에

- 100 -


대한 기록을 제공하고, 지원 요원들에게 모니터링하고 추적할 수 있는 장비를 제공하여야 한다. 또한

인시던트에서 문제로, 알려진 오류로, 변경 요구(Change Request)로, 릴리즈 수정 혹은 긴급한 변경 수

정으로 어느 쪽으로든 조정 탐색할 수 있는 감사를 위한 완전한 단서를 제공하여야 한다.

6.7.2. 오류 평가

문제 관리 요원들은 전문가 요원들과 협동으로, 오류를 해결하는 수단으로서 초기 평가를 수행한다. 필

요한 경우에는, 변경 관리 절차에 따라 RFC를 완료한다. RFC의 우선순위는 업무상 발생한 오류의 긴

급성(Urgency)과 영향(Impact)에 의해 결정된다. RFC 식별자는 완전한 추적 단서를 유지하기 위해, 알

려진 오류 기록에 포함되어야 하며, 그 반대도 마찬가지이다. 이게 아니면, 이 두 가지 기록들이 연결

(Link)되어 있어야 할 것이다.

오류 해결의 최종 단계는 (해결 조치에 대한 상세한 평가가 수행되어야 하는 영향력 분석, 변경을 테스

트 하는 동안 오류가 발생한 목록의 수정 및 개정) 변경 관리의 통제를 받는다. 극단적인 상황에서는,

긴급한 해결책을 취할 수 있는 집행 권한의 부여가 필요하다.

3rd Party 제품에서 발생하는 오류

벤더에서 유지보수 하는 제품 내에서 발생하는 문제들은 '문제 관리팀' 혹은 '전문지원팀'에 의해 확인

되며, 확인시 벤더의 지원 책임자에게 보고되어야 한다. 보고된 문제에 대하여 제때에 대응조치가 이루

어졌는지 확인하기 위해, 벤더의 지원 상황을 계속해서 모니터링 해야 한다.

소프트웨어 유지-보수에 대한 대상이 계약 혹은 라이센스 조건에 명시되어 있고, 이에 대한 유지-보수

에 불응 시에는 3rd Party 조직에 대하여 개선 조치를 취해야 할 것이다. 소프트웨어를 구입할 때, 특히

이러한 사업상의 경쟁이 있을 때, 유지-보수 목표들을 열기해야 할 가능성을 염두 해 두어야 한다. 소

프트웨어 오류를 해결하는데 필수적인 변경들은 '내부 제품'에 대한 변경 관리 절차에 종속되어야 한다.

S/W(software) 환경의 오류 제어

문제와 오류 제어 프로세스는 소프트웨어의 운영 시나 개발 시 언제나 필수적이다. 운영 환경에서의

문제 관리를 위한 지원도구의 초기 기술은 개발 환경에서도 필요하다. 그림 6.4는 운영 환경 및 개발

환경 내에서의 오류 제어에 대한 사이클을 보여준다. 문제 관리 시스템과의 통합은 이와 같은 상황에

대한 통제를 수월하게 해준다.

- 101 -


그림 6.4 – 운용 및 개발 환경에서의 오류 사이클

실제 운용 프로세스 중에 발견되는 오류들은 RFC의 누적을 가져온다. 릴리즈 전략 (이에 대하여는 9

장 릴리즈 관리를 참조)을 세울 때는 시스템 장비를 수정할 수 있는 인가된 변경을 구체화 할 수 있도

록 릴리즈의 최종 완성판을 참작한다.

개발 요원들은 패키지 릴리즈와 관련된 모든 알려진 오류와 문제를 알고 있어야 한다. 개발 요원들은

알려진 오류를 수정할 때 알려진 오류를 제거해야 하지만, 개발 중에 발생하는 새롭게 나타난 오류들

은 오류 수정 데이터 베이스 혹은 CMDB에 추가 해야 한다.

새로운 릴리즈(Release)를 수정할 때, 이렇게 수정된 오류 데이터베이스는 이전 릴리즈의 데이터베이스

를 대신하여 실 운영 버전이 된다. 그 이후에는 실제 운용 프로세스에서 새롭게 오류들이 발견될 때마

다 이러한 조치를 반복한다.

6.7.3. 문제 해결 기록

각각의 알려진 오류에 대한 해결 프로세스는 문제 관리 시스템에 기록되어야 한다. CI, 증상, 그리고 모

든 알려진 오류와 관련이 있는 해결책 혹은 우회 조치에 관한 데이터를 '알려진 오류 데이터베이스'에

유지하는 것이 중요하다. 이렇게 데이터를 저장-유지함으로써 장래 인시던트가 발생하더라도 해결책과

우회조치를 취하는 도중 인시던트를 대조하고 인시던트에 대한 길잡이를 제공할 수 있게 되며, 그럼으

로써 관리 정보를 제공할 수 있게 된다.

6.7.4. 오류 종료

오류를 해결하기 위한 변경조치가 성공하면, 관련된 알려진 오류 기록은 이와 관련된 인시던트 혹은

문제 기록과 함께 종료된다. 인시던트, 알려진 오류, 그리고 문제 기록 프로세스를 ' 종료된 미결

- 102 -


PIR(Post Implementation Review: 추후 실행 검토)' 이라는 잠정 상태로 남겨두는 것을 고려해야 한다.

왜냐하면 개선-수선 조치가 실제로 효과가 있는지를 확실하게 하기 위해서 이다. 그 다음 PIR을 통해

최종 종료전에 해결책의 효과성을 확인할 수 있다.

이러한 점들은 인시던트에 관해서는 사용자들이 현재 만족하고 있는가를 확인하기 위해 사용자(User)

에서 전화를 거는것에 지나지 않는 것일 것이지만, 보다 심각한 문제와 인지오류에 대해서는 정식으로

(재)조사(Formal Review)를 해야 할 것이다.

6.7.5. 문제 오류 해결 모니터링

변경 관리는 RFC(Request For Change: 변경 요청) 프로세스를 책임지는 반면, 오류 제어는 인지오류를

해결하는 프로세스를 모니터링 하는 책임이 있다. 해결 전 프로세스를 통하여, 문제 관리는 문제와 오

류를 해결하는 프로세스인 변경 관리로부터 정기적인 보고서를 받아야 한다.

문제 관리는 사용자 서비스에 미치는 문제와 인지오류의 영향을 계속해서 모니터 해야 한다. 이러한

충격이 심각해지는 상황이 되면, 문제 관리는 이러한 문제를 에스컬레이션 시켜야 하며, RFC의 우선

순위(Priority)를 높이거나 긴급 변경(Urgent Change)을 적절하게 개선하기 위해 변경 자문 위원회(CAB:

Change Advisory Board)에 회부해야 할 것이다.

문제 해결 프로세스는 SLA에 따라 관리되어야 한다. 일반적으로 SLA에는 각각의 측정 기간 동안 (일

반적으로 4주기간으로 반복한다) 오류의 심각성 대 미해결 오류의 비율이 일정 비율을 넘어가서는 안

된다는 것이 규정되어 있다. 문제와 오류의 심각성의 정도가 SLA와 불일치하게 보이는 '사전 정의된

임계치'에 도달하게 되면, 에스컬레이션 해야 한다.

6.7.6. 오류 제어 TIP

다음 사항은 오류 제어와 관련해 기억해야 할 사항이다.

! 모든 알려진 오류가 해결되어야 하는 것은 아니다. 조직은 알려진 오류의 존속 결정을 내릴

수도 있다. 예를 들면, 비용이 너무 많이 든다거나, 기술적으로 불가능 하다거나, 혹은 해결을

하는데 너무 많은 시간이 요구된다거나 하는 이유로. 실제로 오류 제어는 어떠한 문제를 해결

하는데 있어 적당한 투자를 선택하는 것과 관련이 있다.

! RFC를 준비해야 하는 것도 오류 제어의 하나의 의무이다. 해결책들은 기술적 조정을 하는 동

안 발견되기도 한다. 이러한 RFC에는 절차 수정, 작업 방법 수정 그리고/혹은 조직 구조 개선

을 포함해야 할지도 모른다는 점을 명심하라.

! 반복적으로 하드웨어 고장을 일으키는 특정 장치나 장치 카테고리에 따라 표준 오류 기록을

만드는 것도 고려하라. 고장률(고장정도)에 대한 신속한 지침서로서 이용하기 위해 이러한 것

들을 유지하라 -- 비록 평균 무 고장시간(MTBF: Mean Time Between Failures)과 다운타임

(Downtime)과 같은 대부분의 정보들은 인시던트 데이터(Incident Data)로부터 나온다 할지라도.

- 103 -


! 하드웨어 장애 복구의 상당부분은 인시던트 제어 하에서 이루어지는 것이지, 오류 제어나 변

경 관리를 통해 이루어지는 게 아니다. 그러나 특정 하드웨어의 변경은 일반 변경 관리 절차

에 따라야 한다.

! 이론적으로 보면, 실제 사용 환경과 개발 환경에서 인시던트, 문제 그리고 오류 제어에는 일반

도구가 사용되어야 한다. 만일 개발단계에서 특정 CASE 도구를 이용하기 때문에 일반 도구를

사용하는게 불가능하면, 실행 가능한 전달 메카니즘을 설계하여 구축할 할 필요가 생길 것이

다. 특히 실제 적용프로세스에서 획득된 정보를 문제로,인지 오류로, 그리고 '신형 혹은 수정

소프트웨어로 이전되고 있는' 진행중인 변경으로 이전한다는 점에서 핵심적인 문제이다.

6.8. 예방적 문제 관리

문제 제어 그리고 오류 제어에 관하여 지금까지 설명한 활동들은 주로 대응적인 것이다. 예방적 문제

관리 활동(Proactive Problem Management)은 인시던트가 발생하기 전에 문제와 알려진 오류를 확인 해

결함으로써 서비스와 업무상 비용에 미치는 부정적인 영향을 최소화하는데 있다.

문제 예방은 특정 시스템에서 반복적으로 나타나는 문제들과 같은 '개별적인 문제 예방'에서 부터, '전략

결정(Strategic Decisions)'에 이르기까지 다양하다. '전략 결정'은 '네트워크 개선'처럼 상당한 비용이 들어

가는 것들이다. 문제 예방에는 고객들에게 정보를 제공해서 미래에 있을지도 모르는 지원 요구를 미연

에 방지하는 것도 포함되어 있다.

분석은 주로 문제 해결자들에 향상된 조언을 제공하는데 초점을 맞춘다. 이러한 예로서는 온라인 기술

지원 툴 규정을 통해 문제 해결 시간을 절약함으로써, 고객들의 요구를 해결하지 못하고 있는 시간을

줄일 수 있게 되는 것이 있다.

예방적 문제 관리 프로세스내에서 이루어지는 주요 활동들은 경향 분석과 예방 조치의 목표 설정이다.

6.8.1. 경향 분석

인시던트와 문제 분석 보고서는 서비스의 질을 개선시키기 위한 예방 수단 정보를 제공한다. 이러한

행위의 목적은 IT 인프라스트럭쳐 내 ' 취약한' 부분을 확인하고, 이러한 취약성의 원인을 조사하는 것

이다. 이러한 개념으로 볼 때, 만일 CI에 장애가 생긴다고 가정해 볼 때 이러한 장애가 업무에 미치는

영향은 이러한 '취약성'과 비례한다고 볼 수 있다.

인시던트와 문제 분석을 통해 다음과 같은 점을 확인할 수 있다.

! 인시던트의 경향 - 즉 특정 문제 형태가 변경 후 발생하는 것과 같은

! 특정 타입에 나타나는 초기 결점

! 특정 타입에서 나타나는 혹은 개별 부분(부품)에서 나타나는 문제의 재발

! 고객 교육의 증대 혹은 문서자료의 개선의 필요성

- 104 -


인시던트, 문제 그리고 독창적 분석을 분류화 함으로써 일정한 경향을 확인할 수 있으며, 이로 인해 보

다 많은 조사가 필요한 ' 특정 문제 부분 '을 확인할 수 있을 것이다. 예를 들면 분석을 통해 ‘최근에

인스톨한 클라이언트-서버 시스템의 이용과 관련된 인시던트들이 업무에 부정적인 영향을 미치는 여러

인시던트들 중에서 가장 많이 증가하고 있는 인시던트 부분이다’ 라는 것을 알 수 있다.

분석을 통해 – 예를 들면 시스템 관리 툴, 관련 문헌, 조직에서 나타난 인시던트의 분석과 사용자 그룹

으로부터의 피드백의 분석 - 보다 많은 조사가 필요한 '발생 가능한 문제'를 확인할 수도 있다. 또한 뛰

어난 고객들과 함께 공동연구팀(Workshops)을 구성하거나 소비자 여론 조사를 수행함으로써 일정한 경

향(Trends)과 잠재적 문제 분야를 확인할 수 있다.

문제 관리 데이터를 분석하면 다음과 같은 점을 알 수 있을 것이다.

! 한 플랫폼에서 발생한 문제는 다른 플랫폼에서도 발생할 것이란 점 – 예를 들면, 미드레인지

시스템(Midrange System)상의 네트워크 소프웨어에서 발생한 문제는 메인프레임 시스템

(Mainframe System)에서 중대한 문제 중 하나가 될 것이다.

! 재발 문제의 존재 - 이에 대한 예는 다음과 같다. 동일한 고장으로 세대의 라우터가 연속해서

교체되었다면, 이건 개별 라우터 장비의 문제라고 보기에는 적절치 않고, 다른 모델의 라우터

로 교체되어야 한다는 점(즉 개별 라우터의 문제가 아니라는 점)을 나타내는 것이다. 그리고

만일 소프트웨어상의 문제라면, 이때는 주요 변경으로 분류될 수 있을 정도의 '완전한 재개발'

이 필요할 것이다.

6.8.2. 예방조치의 목표 설정

문제 경향을 분석함으로써 IT 인프라스트럭쳐 내의 고장을 확인할 수 있으며, 이러한 확인 후에야 문제

와 오류 통제 부분에서 설명한대로 분석과 정정을 할 수 있을 것이다. 또한 문제 경향 분석을 통하여

보다 많은 지원 조치가 필요한 일반적 문제 부분을 확인할 수 있다. 이러한 경향분석과 관련된 비용을

공개함으로써 의미 있는 비교가 가능하여야 한다.

희소 자원을 가장 효율적인 방법으로 서비스 지원으로 돌리기 위해, 가장 많은 지원 조치를 받고 있는

문제 부분을 조사해볼 필요가 있다. 이러한 것들은 일반적으로 예방적 문제 관리(Proactive Problem

Management)팀의 임무이다.

특정 문제 영역에서 발생하는 인시던트가 관련 업무에 미치는 영향을 평가할 수 있기 위해서는, 이러

한 평가의 한 수단으로서 인시던트의 ' 고통 지수(Pain Factor) '라는 개념을 도입하는 게 유용하다. 이

러한 개념을 통해, 다음과 같은 점을 고려하여 각각의 인시던트 분류에 '고통치(Pain Value)' 가 주어진

다.

! 인시던트량

! 고객에게 영향을 미치는 횟수

! 인시던트 해결에 걸리는 시간과 관련 비용

! 업무에 미치는 비용 - 아마도 이게 가장 중요한 요소일 것이다.

- 105 -


이러한 접근법을 통해 인시던트 발생 횟수는 상대적으로 많지만 서비스 제공 정도에 미치는 영향은 높

지 않은 일련의 인시던트들에 노력을 집중하는 것을 피할 수 있을 것이다. 즉 이러한 접근법은 얼마되

지는 않지만 조직 내 업무에 아주 높은 영향을 미치는 인시던트들을 조사 하는 것이 보다 더 이익이

된다는 점을 나타낸다.

가장 많은 조치를 필요로 하는 문제들이 확인된 후, 문제 관리는 적절한 조치를 개시할 수 있다. 이러

한 조치에는 다음과 같은 것이 있다.

! RFC 제안

! 테스트, 절차, 훈련 그리고 문서화에 관한 피드백 제공

! 고객 교육과 훈련의 개시

! 서비스 지원 요원들에 대한 교육과 훈련 개시

! 충실한 문제 관리 절차와 인시던트 관리 절차 보장

! 프로세스 혹은 절차 개선

6.8.3. 예방적 문제 관리에 대한 TIP

특히 다음과 같은 점을 주의해야 한다.

! CI 강건성(Robustness)의 경향 분석을 통한 부가가치는 자료가 충분히 쌓이기 전까지는 어느

정도 제한적이다.

! 오퍼레이팅 시스템(Operating System)을 운영하는 회사들로부터 얻어진 기술 보고서을 통해 본

질적 문제에 관한 정보를 얻을 수 있다. 하드웨어상의 문제가 발생하기 전에 잠재적 하드웨어

문제를 확인하기 위해서 이러한 보고서들을 정기적으로 감사해야 한다. 이상적으로, 이러한 감

사는 벤더 직원이 해야 하는 것이지만(이럴 가능성은 희박하다), 어떤 경우에든 이러한 감사

완료를 보장하는 것은 문제 관리의 책임이다. 이러한 보고서를 통해서 어떤 고장이 실제로 발

생하기 전에 하드웨어 CI를 수선 교체할 수 도 있을 것이다.

! 예방적 문제 관리를 하는데 있어 전담 직원이 필수적으로 필요한 건 아니다. 소규모의 IT 서비

스 조직에게는, 지원 전문가에게 인시던트와 문제 데이터를 분석하는데 매 6달마다 2주동안의

기간 그리고 RFC를 개시하는 2주 동안을 추가해서 할당하면 이걸로도 충분할 것이다.

6.8.4. 주요 문제 재조사

주요 문제에 대한 해결책을 완성할 때마다, 문제 관리는 주요 문제 재조사를 완료해야 한다. 다음과 같

은 사항을 재검토하기 위해서 해결책 작성에 참여한 적절한 인물들이 소집되어야 할 것이다.

! 올바르게 완료된 것

! 올바르지 않게 완료된 것

! 다음 번에 더 잘하기 위해서 해야 할 일

! 문제가 다시 발생하지 않게 하는 법

! 지원 기구에 대한 정보 제공

- 106 -


6.9. 지원기구에 대한 정보제공

문제 관리는 확인된 문제, 알려진 오류와 변경 요청들에 대한 정보를 제공한다. 이러한 정보는 임시적

인 것 일수도 정기적인 것일 수도 있다. 이러한 정보와 보고들은 문제 관리 프로세스의 질을 모니터링

하기 위해서 관리 목표로 삼기도 한다. 그러나 조직 내에서 이루어지는 의사 결정을 형성하는데 관리

보고서를 이용하 듯, 관리 보고서를 회사와 IT 관리부서에 제출하는 것도 유용한 일이다.

이러한 점 이외에도, 또한 보고서들을 다른 부서와 서비스데스크에 회람시킬 수 있을 것이다.

6.9.1. 관리 정보 제공

관리 정보에는 문제와 인지오류를 조사, 진단, 해결하는데 관리 팀이 소비하는 노력과 자원에 대한 전

망이 담겨 있어야 한다. 이 이외에도, 중요한 점은 진행 상황과 진행을 통해 나타날 결과들에 대한 전

망도 담겨 있어야 한다는 점이다. 측정기준(Metrics)은 신중하게 선택하여야 한다.

왜냐하면 관리 팀(Management)은 신중하고 의미 있는 측정을 통해서만 진행프로세스에 대한 의견을

도출할 수 있기 때문이다.

6.9.2. 정보의 홍수

임시 해결책, 영구 해결책 혹은 해결책의 진전에 대한 간단한 정보들은 문제를 보고한 직원에게 단계

적으로 주어져야 한다. 또한 많은 사람들에게 영향을 미치는 문제가 단 한 사람에 의해서만 보고되었

을 때, 이러한 정보들은 다른 고객들에게도 단계적으로 제공되어야 한다.

이러한 정보들의 확산-배포는 주로 서비스데스크의 임무이다. 이러한 임무를 행하는 서비스 데스크에

대하여 문제 관리 팀은 충분한 정보와 지원을 제공하여야 한다. 문제 관리 팀은 이러한 정보들을 현존

서비스 관리 툴과 데이터베이스에 입력함으로써 관련정보를 직접 서비스데스크와 지원 조직에 배분할

수도 있다.

정보를 효율적으로 분산-공유하기 위해서는, 문제 관리 프로세스는 구성 관리 정보 –예를 들면, 누가

어떤 정보를 언제 어디에서 이용하는가 그리고 기타 필수 접속 세부사항들 - 에 접근할 수 있어야 한

다. 문제 관리에 요구되는 세부 사항들 중 일부는 인시던트 관리 프로세스의 콜 로깅 부분에서 얻을

수 있다. 그러나 문제 관리를 하는데 있어, 문제 발생 전에 미리 합의된 Contact Map이나 공식 커뮤니

케이션 루트를 이용하는 게 보다 효과적일 때도 있다. 이러한 형태의 정보들이 SLA 협상 중(혹은 재협

상 중)에 획득되는 경우도 종종 있다.

이러한 정보를 획득하는 또 다른 소스로는 서비스 수준 관리의 일부를 형성하는 정기 서비스 리뷰

(Regular Service Review)가 있다.

6.10. 매트릭스

인시던트 제어와 문제/오류 제어에서 획득한 정보들을 유지-보유함으로써, 서비스의 질과 서비스 프로

세스의 실행 정도를 나타내는 기준을 도출할 수 있다.

- 107 -


6.10.1. 이러한 점과 관련한 관리 정보에는 다음과 같은 것이 있다.

! RFC 증가량과 이러한 RFC 증가량이 서비스 가용성(Availability)과 신뢰성(Relability)에 미친

영향

! 문제 형태에 따라 나눠진 조직 단위별 조사 진단에 걸린 시간

! 근본 문제가 종료되거나 알려진 오류가 확인되기 전에 발생한 인시던트 량과 인시던트가 미친

영향

! 문제 관리를 위해 신속한 지원 조치를 취한 비율

! 미해결된 문제를 해결하는 데 있어 자원 투입과 관련되어 있는 계획들

- 사람

- 기타 투입된 자원

- 예산 대비 비용

! 착수 조치에 대한 간략한 설명

IT 인프라스트럭쳐내 취약한 부분에 대한 정보와 공급자와 합의된 서비스 수준(Service Levels)에 대한

위반에 관한 정보는 가용성 관리(Availability Management)팀의 업무 중 하나이다. 문제 발생의 빈도수

와 존속기간은 서비스 수준이 합의된 대로 이행되고 있는가에 대한 하나의 기준이 된다.

이에 대하여는 다음과 같은 정보가 요구된다.

! 이에 대하여는 다음과 같은 정보가 요구된다.

- 상태

- 서비스

- 임팩트

- 카테고리

- 사용자 그룹

! 종료된 문제에 소비된 총 시간

! 미해결 문제(Outstanding Problems)를 처리하기 위해 소비된 시간

! 임팩트 코드(Impact Code)와 지원 그룹이 문제 기록이 발생한 때부터 문제 종료를 위해 혹은

알려진 오류 확인을 위해 소비한 평균 소비 시간과 최대 소비 시간

! 모든 임시 해결 조치

! 미해결 문제 해결에 예상되는 시간

! 문제 종료에 걸린 총 시간

6.10.2. 정기 감사

프로세스 제어에는 모든 운영프로세스와 운영절차에 대한 정기 감사가 요구된다. 이러한 감사들은 문

제 관리와 지원 팀이 정해진 절차를 충실히 이행하고 있는지의 여부를 확인하기 위한 것이다. 이러한

감사를 통해 주요 문제 검토를 분석하고, 다음과 같은 점을 체크해야 한다.

! 정해진 스케줄에 의해 보고서를 작성 및 분석하는지의 여부

! 인시던트와 관련된 문제들이 올바르게 확인 기록되었는지 확인 위한, 인시던트의 표본 샘플

- 108 -


! 문제가 올바르게 진단되었고 기 설정한 기간 내에 원인이 밝혀졌는지 확인하기 위한, 문제의

표본 샘플

! 알려진 오류가 CI의 인가된 변경을 통해 제거 되었는지 와 기 설정한 기간 내에 해결되었는지

의 여부를 확인하기 위한, 알려진 오류에 대한 표본 샘플

! 에스컬레이션에 대한 임계치가 설정되어 있는지의 여부

! 정정과 완료를 위한 기록에 관한 표본 샘플

! 문제 관리 직원에 의해 배포되고 수령인(Recipients)에 의해 시행되는 문서들이 올바르게 업데

이트 되고 있는지의 여부

! 정기적으로 보고서가 작성되고 있으며 이러한 보고서가 경향 분석의 관련 근거로서 그리고 예

방 조치를 확인하는데 있어 의미가 있는지의 여부

! 직원 교육 기록

6.10.3. 매트릭스에 관한 TIP

다음사항은 측정을 하는데 있어 명심해야 할 중요한 사항이다.

! 상세사항을 설정하는 단계에서, 이러한 프로세스들에 대한 효과적인 측정법을 설정하라. 효과

성과 경향 평가를 객관적으로 수행하기 위해 문제 관리 운영을 시작할 때, 이러한 측정법을

하나의 대조 표준으로 사용할 계획을 세워라. 미리 실제 세부목표를 설정하라. 이러한 세부목

표는 가능하면 운영을 시작하는 최초 몇 주동안내에 설정하라. 가능하면 이러한 세부목표를

설정하는 하나의 기준으로서 이용하기 위해 현재 이루어지는 지원 활동으로부터 통계를 내어

라. 이러한 작업 수행의 이점은, 후에 문제 관리를 도입함으로써 얻어지는 장점들을 확인하는

데 유용하게 쓰인다는 점이다

! 측정할 수 없는 목표는 설정하지 마라.

! 지원 툴을 구입할 때는, 제품 평가와 시스템-설계가 이루어지는 단계 시기에 적절한 측정수단

을 고려하고, 필요한 통계를 제공하는 도구를 획득한다.

! 핵심 효율 기준(Key Effectiveness Criteria)에 관한 보고서를 작성하기 위한 절차를 개발하라.

문제 관리 팀 은 매달 한번 정기적으로 모든 세부 목표들에 대한 실제 성취도를 조사해야 한

다. 각 조사에 대한 결론을 기록하고, 감사를 위한 기록을 유지하라. 만일 설정목표를 낮춰야

하는 경우가 생기면, 그 원인이 목표가 너무 높아서였는지, 운영상의 잘못 때문은 아니었는지

를 확실하게 하라. 실제 문제 관리를 운영하는 도중 발생한 결함들은 역 추적을 하여 근본적

인 개선을 해야 한다.

! 전 프로세스에 대한 공식적인 효과성- 효율성 리뷰를 작성할 계획을 세워라. 이러한 리뷰를 작

성할 때는 고객의 요구사항이 뭔지에 대하여 특히 관심을 가져야 한다. 이러한 프로세스가 실

제로 운영될 때에 지원 요구사항을 완전하게 만족시킬 수 있다는 사실을 명심하라.

! 문제 관리 프로세스를 도입함으로써 기대되는 장점들이 나타남에 따라, 이에 발맞춰 점점 더

높은 목표를 설정할 계획을 세워라.

! 문제 관리 시스템이 직원들의 업무부담을 줄여주는데 효과가 있는지의 여부를 모니터링 하라.

경험상으로 볼 때, 효과적인 프로세스를 통해(특히 효과적인 변경 관리(Change Management)

- 109 -


와 릴리즈 퀄리티 제어(Release Quality Control)과 함께 이루어질 때) 인시던트와 문제 발생 빈

도를 신속하게 감소시킬 수 있다는 것을 알 수 있다. 이러한 인시던트 발생 빈도의 감소, 그리

고 이어지는 지원 요청 횟수의 감소는 직원수의 감소로 이어질 수 있다. 새로운 어플리케이션

과 새로운 사용자들은 문제와 인시던트를 처리하는 업무부담을 늘릴 수도 있다. 그러므로 문

제 관리 팀은 이러한 업무부담에 영향을 미칠 수 있는 변경(Changes)을 미리 알고 있어야 하

며, 이렇게 미리 인지함으로써 직원 수와 직원배치에 관한 계획뿐만 아니라, 데이터 베이스와

기타 IT 용량에 관한 계획을 세울 수 있게 된다.

! 다른 서비스 관리 프로세스에 의하여 이루어지는 감사는 문제를 나타내는 것일 수도 있는 일

들을 놓치는 경우가 있을 수 있다. 그러므로 필요한 정정 조치를 취할 수 있도록 문제 관리

팀에 관련 정보를 인계해야 한다는 점을 명심하라.

6.11. 문제 관리 내의 역할

모든 프로세스들은 조직 내 모든 기능에 영향을 미치는 경향이 있다. 그러므로 실행해야만 어떠한 절

차 내에서 이루어지는 활동들과 관련된 책임을 명확하게 정의해 주어야 한다. 반면에 융통성도 확보하

기 위해서 역할 개념을 활용할 만 하다.

역할이란 일련의 책임, 행위, 그리고 권한 부여로 정의할 수 있다. 이 장에서는 여러 프로세스에 나타

나는 관련범위내의 역할에 대하여 매우 간략하게 정의를 하였다.

6.11.1. 문제 관리자

문제 관리자는 모든 문제 관리 활동에 대하여 책임을 지며, 다음과 같은 세부적인 책임을 가지고 있다.

! 문제 제어 프로세스의 개발과 유지

! 문제 관리 프로세스의 효율성과 효과성의 조사

! 관리 정보 생산

! 문제 관리 지원요원 관리

! 지원에 투입할 자원의 할당

! 오류 제어 프로세스의 유효성(효과성) 모니터링, 오류 제어 프로세스의 개선책 추천

! 문제와 오류 제어 시스템의 개발 유지

! 예방적 문제 관리 활동의 효과성과 효율성 조사

서비스 데스크 관리자의 역할과 문제 관리자의 역할을 겸직시키는 건 좋지 않다. 왜냐하면 이 두 관리

자의 역할은 본질적으로 상호간에 대립적인 관계이기 때문이다.

6.11.2. 문제 지원

문제 지원에는 다음과 같이 대응 책임(Reactive)과 예방 책임(Proactive) 모두를 가지고 있다.

대응 책임

! 문제 확인 (예를 들면, 인시던트 데이터를 분석함으로써)

- 110 -


! 해결책 확인 혹은 오류 확인을 한 후, 영향을 미치는 정도에 따라 문제 조사

! 오류 제거를 위한 RFC 개시

! 인지 오류 해결책의 진척 여부에 대한 모니터링

! 인시던트 관리 직원에 대하여 미해결의 문제/인지오류에 관련된 인시던트들에 관한 최선의 임

시해결책(Work-Arounds) 자문 제공

! 주요 인시던트 처리 지원과 근본 원인 확인

예방 책임

! 경향 확인과 잠재 문제 요인 확인 (인시던트와 문제 분석을 조사함으로써)

! 문제의 재발을 방지하기 위한 RFC 발동

! 다중 시스템 전반에 걸친 문제 재발의 방지

부록 6A : 문제/오류 카테고리 코딩 구조의 예

코드 구조 카테고리 코드 설명 주석

A A1

A10 A11 A12 A13 A14 A15 A16 A17

CI 관련 무 사용자 실수 컴퓨터 운영 네트워크 관리 사용자 지원 문제 관리 전문가 지원 어플리케이션 개발 관리

이 항목에 대한 CI 추가 고려

A2

A20 A21 A22

절차 실패 변경 관리 S/W 통제 및 분배 기타

이 항목에 대한 CI 추가 고려

B B1 B10

B100 B1000 B1001 B1002 B101

어플리케이션 CI(내부) 어플리케이션 1 모듈 1 트랜잭션 타입 1 파일 업데이트 페이지 락 동시 업데이트 트랜잭션 타입 2

- 111 -

IT서비스관리를 위한 ITIL 레퍼런스 요약집

B11

B12

B110 B111 B120 B121

모듈 2 작업 1 작업 2 문서 컴퓨터 운영 지침서 사용자 절차 지침서

B2 Etc.

어플리케이션 2

C C1 C10 C11

C100 C101 C110 C111

어플리케이션 CI (외부) 패키지 1 모듈 1 작업 1 작업 2 문서 모듈 1 지침서 모듈 2 지침서

C2 Etc.

패키지 2

D D1

D10 D20

유틸리티 소프트웨어 CI (내부) JCL 어플리케이션 1 어플리케이션 2

D2 데이터베이스 유지보수 지원

D3 소프트웨어 라이브러리 유지보수

E E1

E10 E11 E12 E13

시스템 소프트웨어 CI (외부)

메인 프레임 시스템 소프트웨어 운영 시스템 트랜잭션 프로세싱 데이터 관리

- 112 -


E14 E15

통신 / 네트워킹 데이터 센터 관리 어플리케이션 생성

E2 Etc.

미니 컴퓨터 시스템 소프트웨어

F Etc.

컴퓨터 하드웨어 CI

G Etc.

네트워크 하드웨어 CI

6A 참고 : 다음 부록 설명은 원인들에 관한 것이다. "원인"과, 앞에서 설명한 인시던트와 문제 개념

을 가지고 향후의 의미 있는 분석을 위해 "원인을 분류하는 법"을 혼동해서는 안 된다.

부록 6B : Kepner와 Tregoe 분석 Charles Kepner와 Benjamin Tregoe는 문제 분석을 위한 유용한 방법론을 개발하였다. 이 부록에서는

문제 분석 방법론의 하나의 예로서 이들의 방법론을 소개 한다.

Kepner와 Tregoe는 문제 분석(Problem Analysis)은 체계적인 문제 해결 프로세스이어야 하며, 기존의

지식과 경험을 최대한으로 이용해야 한다고 말한다. 그들은 문제 분석을 다음과 같이 다섯 단계로 분

류하였다.

문제 정의 1.

2.

3.

4.

5.

문제의 특성, 발생 위치, 발생 시간, 발생 규모의 설명

가능 원인 규정

가장 가능성이 높은 문제 원인 테스트

실제 원인 검증

가용 가능한 시간과 정보에 따라, 이러한 단계를 확대할 수도 축소할 수도 있다.

제한적인 정보만을 이용할 수 있는 상황이거나, 시간이 매우 촉박할 때에도 성공확률을 높이기 위해

구조적인 문제 분석법을 채택하는 게 좋다.

문제 정의

문제정의에 따라 조사가 이루어지기 때문에, 정해진 서비스 수준을 일탈하는 현상이 발생했을 때 어느

부분의 일탈현상 때문에 발생하였는가를 정확하게 설명할 수 있도록 정의를 내려야 한다.

문제 정의를 할 때, 가장 가능성이 높은 문제 원인이 이미 나타나 있는 경우도 있다. 따라서 조사를 처

음부터 잘못된 방향으로 이끌어 갈 수 있는 원인이 될 수도 있는, 결과의 속단은 바람직 하지 않다.

- 113 -


실제로 복잡한 IT 인프라스트럭쳐와 서비스 수준에 대한 불투명한 동의로 인하여, 문제를 정의하는게

어려울 때도 있다.

문제 설명

다음과 같은 측면에서 문제에 대해 기술된다. (예를 들면, 문제란 무엇인가?)

! 문제의 본질. 어느 부분이 고장 났는가? 문제가 무엇인가?

! 발생 위치. 어디에서 문제가 발생하였는가?

! 발생 시간. 문제가 언제부터 발생하였는가? 얼마나 자주 그러한 문제가 발생하여왔는가?

! 규모. 문제의 발생규모는 어느 정도인가? 얼마나 많은 부분이 영향을 받았는가?

'무엇이 문제인가'는 이러한 질문에 대한 대답을 통해 결정된다. 다음 단계는 유사환경에서 어떤 유사한

부분이 적절하게 작동되는가를 조사하는 것이다. 이것을 통해, ‘모호하지만 아닌 것’의 문제에 대한 해

답은 명확화 된다. (동일한 문제를 보일 것이라고 생각되었는데 실제로는 문제를 보이지 않는 부분은

어느 부분인가?)

이러한 조사를 끝낸 후에 동일한 상황에서 나타나는 상대적인 차이점을 효과적으로 조사할 수 있을 것

이다. 이에 더하여, 이러한 차이점이 발생한 원인일 수도 있는, 과거의 변경(Past Changes)을 확인할

수 있다.

가능 원인 규정

위에서 언급한 차이점과 변경을 기록한 리스트들에는 가장 발생할 확률이 높은 문제 원인이 담겨 있을

것이므로, 이러한 리스트에서 가능 원인을 추출할 수 있을 것이다.

가장 가능성이 높은 원인의 테스트

각각의 가능 원인에는 모든 문제의 증상들의 원인인지의 여부를 결정하기 위한 평가가 필요하다.

실제 원인 검증

테스트를 통해 걸러진 가능 원인들은 문제의 근원으로서 확인 검증되어야 한다.

이러한 작업은 이러한 원인들을 한가지 이상의 방법으로 – 예를 들면 변경을 수정하거나 부품을 교체

하거나 하는 - 검증될 때에만 완료될 수 있다.

신속하고 간단하게 확인 검증할 수 있는 '가능 원인(Possible Causes)'을 우선 처리하라.

- 114 -


부록 6C : Ishikawa 다이어그램

그림 6C.1 - Ishikawa 다이어그램의 예

Ishikawa 다이어그램 – 이는 또한 인과 관계형 다이어그램, 트리형 다이어그램, 혹은 가시형 다

이어그램으로도 불리 운다 - 개별적인 품질 특성(Quality Characteristic), 성과-산출, 혹은 문제에

영향을 미치는 요인들을 나타내는 도표이다. 이 다이어그램은 다이어그램 개발자이고 일본의

품질 관리 전문가인 Kaoru Ishikawa(1915-1989)의 이름을 따서 붙여졌다. 그림 6C.1 은 한 예

이다.

Ishikwaa 다이어그램은 일반적으로 어떠한 그룹의 일원들이 제품, 생산프로세스, 서비스를 어떻

게 개선할 것인가에 대한 아이디어를 쥐어짜내는 프로세스인 브레인스토밍(Brainstorming)프로

세스의 결과이다. 주요 목적은 도표의 '몸통(Trunk)'으로 상징되며, 주요 요인들은 '가지

(Branches)'로 나타난다. 이렇게 '주요 목적과 주요 요인'을 작성한 후 '줄기(Stems) 기타등등'으

로서 두 번째 요인들을 첨가한다. 이렇게 다이어그램을 작성함으로써 토론을 촉진할 수 있으며,

복잡한 문제에 대한 이해를 늘릴 수도 있다. 일본사람들은 관리자 혹은 기타 그룹 원들이 접근

할 수 있는 진열 장소(Display Area)에 Ishikawa 도표를 붙여 놓기도 한다.

미국의 경우를 보면, 생산설비 팀이 경영인 혹은 소비자들에게 하는 프리젠테이션에 Ishikawa

도표를 쓰기도 한다.

- 115 -


7. 구성 관리

7.1. 구성 관리 의 목적

비즈니스는 IT 서비스를 경제적으로 제공하길 필요로 한다. 효율적이고 효과적으로 IT 서비스를 제공하

기 위해서는, 모든 조직이 IT 인프라스트럭쳐와 서비스를 제어할 수 있어야 한다. 구성 관리는 인프라

스트럭쳐의 논리적 모델 정보를 제공한다.

구성 관리의 목적은 다음과 같다.

! 조직과 제공하는 IT서비스와 관련된 구성 정보와 자산 정보를 파악

! 다른 서비스 관리 프로세스를 지원하기 위한 문서와 구성 설정에 대한 정확한 정보 제공

! 사건 관리, 문제 관리, 변경 관리 ,릴리즈 관리를 위한 유효 적절한 근간을 제공

! 인프라스트럭쳐와 다른 예외 사항에 대한 정정에 대해 구성 정보 기록을 검증

7.2. 구성 관리의 범위

구성관리는 IT 구성 요소와, 그것의 버전, 구성요소, 요소간의 관계의 데이터를 분류하고 기록하고 리

포팅하는것이다. 하드웨어와 소프트웨어 그와 관련된 문서들이 구성 관리의 관리 아래있는 아이템이다.

위의 설명에서 보는 바와 같이 구성 관리는 Asset Management와는 별도의 프로세스이다. Asset

Management는 아이템의 화폐가치를 포함하는 회계 프로세스이다. Asset Management 시스템은 각 자

산의 사업 단위, 위치 등에 대한 정보만을 관리하며 각 아이템간의 관계정보는 관리하지 않는다. 어떤

조직들은 Asset Management 에서 구성 관리 프로세스로 전환하기 시작했다.

구성 관리의 기본 실행 방안은

! 계획. 구성 관리에 대한 목적, 목표, 범위, 정책, 절차 및 기술적 상황에 대해 정의하고 계획한

다.

! 식별. 구성 아이템의 소유자와 내부 관계, 그리고 구성 문서 등을 포함한 인프라스트럭쳐의 모

든 CI를 취합하고 식별하여 분류. 이 과정에는 각 CI에 대한 버전, 라벨링 등이 포함되며 구성

관리 Database (CMDB)에 정보를 저장한다.

! 제어. 제어 활동은 허가받고 식별 가능한 구성 항목만 허용하고 처음부터 끝까지 기록하도록

한다. 허가된 변경 요청이나 업데이트된 사양 등과 같은 적합한 제어 문서화가 없는 한 CI를

추가, 수정, 교체 또는 제거하지 않도록 제어한다.

! 상태기록. 각 CI의 주기와 관련된 모든 현재 및 과거 데이터를 보고한다. 이와 같은 활동은 개

발, 테스트, 유지 및 철회 등의 상태를 통해 CI 상태 추적을 가능하게 하는 등의 방식으로 해

당 레코드의 추적을 가능하게 한다.

! 검증 및 감사. 구성 항목이 실제로 존재하는지 여부를 확인하고 구성 항목이 CMDB에 올바로

기록되는지 검사하고 허가된 항목만 IT 환경에서 사용하도록 하는 일련의 검토 및 감사 과정

이다.

- 116 -


7.3. 기본 개념

7.3.1. 구성 관리 계획

구성 관리 계획은 아래 내용의 정의와 협의를 통해 구성된다.

! 구성 관리 목적, 목표, 전략, 정책 및 범위

! 자산 및 구성 정보의 현재 상태에 대한 분석

! 구성 관리를 실제 적용 시키기 위한 기술적, 관리적 측면에서의 고려 사항 조직화

! 변경 및 릴리즈 관리와 같은 관련 프로세스를 위한 구성 관리 프로세스 정책

! 인터페이스. 예를 들어 지원팀, 어플리케이션, 공급자, 프로젝트 사이의 인터페이스

! 구성 관리 활동을 위한 조직의 역할 및 책임, 지원팀, 가이드라인, 관련 프로세스 및 절차

! 하드웨어, 소프트웨어, 문서 정보를 저장하기 위한 라이브러리와 저장 영역의 위치

구성 정책 및 전략은 구성 관리에 의한 핵심 성공 요소 (KSF : Key Success Factor) 및 목표를 설정하

는 것이다. 목표 및 핵심 성공 요소를 취득 및 달성 하기 위해서, 상세 활동 계획 및 요구되는 자원에

대해서는 프로젝트 계획 내에 문서화 되어 관리되어야 한다.

7.3.2. 구성 요소 식별 및 CI

구성 요소 식별 작업은 구성 항목간의 관계와 소유자를 포함하여, 구성 아이템과 구성 구조의 선택의

선별, 식별 및 라벨링으로 구성된다.

CI는 하드웨어, 소프트웨어, 혹은 문서 등이다. 예를 들어 제공하는 IT 서비스를 포함하여, 서버, 장비,

네트워크 구성 요소, 데스크탑, 모바일 장비, 어플리케이션, 라이센스, 텔레커뮤니케이션 서비스, 시설

등이 포함될 수 있으며 CI의 ID 할당 및 각 개별 CI의 버전, CI의 설정 관련 문서 등을 포함한다.

또 다른 데이터로는 CI와 관련된 사건, 알려진 오류, 문제 및 종업원, 공급자, 소유지, 사업부, 업무 절

차 등에 대한 조직과 관련된 데이터가 있을 수 있다.

구성 관리의 중요한 부분은 CI의 관리 수준을 결정하는 것이다. 이 부분은 7.6.2절에서 좀 더 상세히

다룰 것이다.

CI 레벨의 예는 아래 그림과 같다. 시스템 A는 A1, A2, A3의 요소로 구성되어 있다. 또한 각 구성 요소

는 하위의 보자 작은 구성 요소로 분할 될 수 있다. 각 각의 분할 요소들은 하나의 CI가 되는 것이며,

또한 전체 시스템을 나타내는 시스템 A도 하나의 CI가 되는 것이다.

- 117 -


그림 7.1 – 구성 아이템 분할

분산 환경에서, 개별 구성 요소는 많은 다른 서비스 및 형상 구조를 구성하는 하나의 요소가 될 수 있

다. 예를 들어, 네트워크 상에 물려 있는 데스크탑 컴퓨터를 사용하는 직원이 작업을 하는 중앙 금융

시스템과 연결되어 있는 데이터베이스 시스템은 지구촌의 다른 지역에 있을 수 있는 것이다. 네트워크

의 변경이나, 중앙 금융 시스템의 변경은 이 직원, 혹은 이 직원의 업무 프로세스에 영향을 끼칠 것이

다. 제대로 구성 요소에 대해 식별이 되고 관계에 대해 정리가 된다면, 또한 문서화 되어 있다면, 어떠

한 특정 변경에 대해 잠재적으로, 혹은 직접적으로 영향을 받는 범위 및 구성 요소에 대해 효과적으로

파악 할 수 있으며, 변경 관리에 의한 조직의 충격을 최소화 할 수 있다.

7.3.3. 구성 제어

구성 제어란, CI의 인수에서부터 폐기까지의 기록을 식별된 CI에 대해 오로지 승인 받은 절차에 따르도

록 하는 것이다. 구성 제어는 CI의 추가, 수정, 대체 혹은 제거에 대해 어떠한 승인 받지 못한 기록도

하지 못하도록 보장한다.

7.3.4. 구성 상태 기록

구성 상태 기록은 각 CI에 대해 라이프 사이클을 통해, 모든 현재의 상태 데이터 및 과거 기록 데이터

를 기록하는 것이다. 이것은 CI의 상태의 하나의 상태에서 다른 상태로의 변경에 대한 기록을 추적할

수 있게 해준다.

예를 들어, ‘개발’, ‘테스트’, ‘사용’, ‘폐기’로의 상태 변경에 대한 추적.

7.3.5. 구성 요소 검증 및 감사

구성 요소의 검증 및 감사는 CI가 실제 물리적으로 존재하는지에 대한 검증 및 CI의 정보가 CMDB에

정확하게 기록되고 관리되는지를 감사하는 절차이다. 이것은 현재 환경의 변경 정에 구성 정보의 문서

및 릴리즈에 대한 검증도 포함하다.

- 118 -


7.3.6. 구성 정보 기준선(Configuration Baseline)

구성 정보 기준선은 특정 시점의 형상 구조 및 구성 요소의 상세 설정 정보의 캡춰이다.

소프트웨어의 기준선은 향후 특정 버전으로 소프트웨어를 재구성할 수 있는 정보를 제공한다.

구성 정보 기준선은 또한 스냅샷 혹은 CI의 위치에 대한 정보의 기록이다. 비록 CI의 위치가 변경되더

라도, 구성 정보 기준선에 원래의 상태가 기록되어 있으므로 현재 상태와 과거의 상태를 비교할 수 있

다. 구성 정보 기준선은 변경 혹은 릴리즈를 위한 준비로, 관련된 모든 구성요소의 정보를 모으고, 구

성 정보의 감사, 혹은 원복 시 기존 구성 정보를 제공한다.

구성 관리 시스템은 구성 정보 기준선의 보고서, 보존 및 저장을 할 수 있어야 한다.

7.3.7. 구성 관리 Database (CMDB)

많은 조직들은 이미 스프레드 쉬트, 로컬 데이터베이스, 혹은 일반 서류 형태의 시스템으로 구성관리의

몇몇 요소는 관리하고 있다. 오늘날의 거대하고 복잡한 IT 인프라스트럭쳐에서의 구성 관리에는 CMDB

를 포함하여, 기타 지원 도구를 필요로 한다. CMDB는 유연한고 강력한 질의 도구로의 데이터베이스

기술에 근거하며, 다음과 같은 내용들이 CMDB를 통하여 이용된다.

! CI의 구성 요소 및 버전을 포함하는 릴리즈 내용

! 테스트 환경과 실제 적용 후 사용 환경에서의 CI 구성 요소와 버전 내용

! 예정된 (승인된) 변경에 의해 영향을 받는 CI

! 하나의 특정 CI와 관련된 모든 변경 요청(Request for Change : RFCs)

! 특정 기간 동안 특정 공급자에게 구매한 CI 정보

! CI 과거 기록

! 장비와 소프트웨어의 위치 정보. 예를 들어 감사를 지원하기 위한 데이터로 이용할 위치정보

! 예정된 CI의 업그레이드, 대체, 혹은 폐기 정보

! CI와 관련된 변경 및 문제 관리 프로세스의 기록

! 문제에 의해 영향을 받는 모든 CI

CMDB는 사건, 문제, 알려진 오류, 변경, 릴리즈를 포함한 모든 시스템 구성 요소 사이의 관계 정보 및

직원, 공급자, 사업부, 지리적 정보를 포함하는 기업의 정보도 담고 있다.

CMDB의 데이터를 기록하고 업데이트하는 자동화된 프로세스는 비용 절감과 데이터의 기록 오류를 감

소 시키기 위하여 개발되어야 한다. CI의 디스커버리 도구, 재고 관리, 감사 도구, 네트워크 관리 시스

템과 같은 도구들은 CMDB와 연계될 수 있다. 이러한 도구들은 초기에 CMDB 데이터를 구성하고, 그

이후에 CMDB에 저장되어 있는 데이터들의 정보와 실제 현존하는 정보와의 비교에 이용된다.

CMDB는 IT 사용자와, IT 부서 직원, 사업 단위의 상세 정보를 저장하고 제어한다. 이와 같은 정보는

CI의 소유자 변경과 같은 상황에서 사용된다.

또한, 직원의 정보는, CMDB에서 IT 구성요소의 근간을 이루는 관련 정보 및 서비스 수준 관리를 위해

사용되어 진다.

- 119 -


CMDB에는 공급자, 가격, 구매일, 라이센스 갱신 기간 등, CI의 상세 목록이 저장되며, 라이센스 유지보

수 관련 정보 및 계약 정보 또한 저장된다.

7.3.8. 소프트웨어 및 문서 라이브러리

제어되는 라이브러리는 소프트웨어 혹은 알려진 형태 및 상태의 문서 CI가 수집된다. 제어되는 라이브

러리 내의 아이템에 대한 접근 제어는 제한적이어야 한다. 소프트웨어 라이브러리는 시스템 개발 라이

프 사이클을 통해 소프트웨어의 제어 및 릴리즈에 이용된다. (e.g 개발, 구현, 테스팅, 운영)

7.3.9. DSL (Definitive Software Library)

Definitive Software Library (DSL)은 모든 소프트웨어 CI의 최종 승인된 버전의 라이브러리를 저장하고

보호한다. 물리적인 라이브러리, 혹은 저장 공간에는 소프트웨어 해당 버전의 마스터 복사본이 저장되

어 있다. 하나의 논리적인 저장 영역에는 실제로는 하나 혹은 하나 이상의 물리적 소프트웨어 라이브

러리, 혹은 파일이 저장되어 진다. 이 라이브러리는 개발, 테스트, 운영 등의 저장 영역으로 나뉘어 저

장된다. 승인된 소프트웨어 만이 DSL로 허가 되어 지며, DSL은 변경 및 릴리즈 관리를 통해 엄격하게

관리되어 진다.

DSL은 릴리즈 관리와 구성 관리를 위한 공통된 기반을 제공해 준다. 좀더 상세한 내용은 9장의 릴리

즈 관리를 참조한다.

7.3.10. 라이센스 관리

기업의 중역, 혹은 선임 관리자는 기업 내에서 사용되어지는 불법 소프트웨어의 적발 시, 직접 적인 형

사 처벌 대상이 된다. 구성 관리는 소프트웨어 라이센스의 구매에서부터 처분까지 제어 및 모니터링을

한다. 소프트웨어 라이센스 구조 및 다중 라이센싱 스키마는 서비스 공급자와 고객간의 이해와 의사소

통이 필요한 부분이다.

소프트웨어 라이센스의 제어 및 감사의 책임은 명백해야 하며 이는 구성 관리 혹은 구매 및 자산 관리

에 포함되어야 한다. 요즘은 일반 사용자들이 쉽게 인터넷에서 불법 소프트웨어를 다운로드하여 설치

할 수 있으며, 구매 또한 간단하므로 이에 대해 제어를 한다는 것은 상당히 어려운 일이지만, 조직의

보안 정책 내에서 불법 소프트웨어 사용에 대한 상세한 징계 절차를 만들어서 조직원들을 제어해야 한

다. (자세한 내용은 ITIL의 보안 관리 – ISBN 0-11-330014-x 참조)

7.4. 이익 및 발생 가능한 문제점

7.4.1. 이익

IT 자산의 진정한 가치는 제공하는 IT 서비스의 질에 의한 가치로 평가되어야 하므로 단순한 원금 가

치보다 훨씬 크다. 만약 어떠한 장애 혹은 사건에 의해 서비스 제공이 중단된다면, 이는 조직에 중대한

손실을 입힐 것이다.

- 120 -


구성 관리는 효율적이고 경제적인 IT 서비스 제공을 위해 다음과 같은 역할을 한다.

! CI와 관련 문서에 대한 정확한 정보를 제공한다. 이 정보는 릴리즈 관리, 변경 관리, 사건 관

리, 문제 관리, 용량 관리와 같은 모든 다른 서비스 관리 프로세스에서 이용되어 진다. 예를

들어, 만약 새로운 상품이 최소 요구 사양이 있고, 현재의 시스템이 이를 충족 시키지 못한다

면, 구성 관리 프로세스는 업그레이드 계획 및 대체 정보를 제공해 줄 것이다.

! CI의 가치 제어. 예를 들어, 만약 컴퓨터가 도난을 당하였다면 다른 컴퓨터로 대체 되어야만

한다. 구성 관리는 어떤 자산이 제안되어야 하며, 누가 보관에 책임이 있으며, 실제 자산 목록

과 일치하는지 아닌지에 대한 정보를 제공함으로써 IT 관리를 보다 수월하게 하도록 한다.

! 법적 책임 이행. 구성 관리는 IT 인프라스트럭쳐 내의 모든 소프트웨어 아이템의 정보를 관리

한다. 허가 되지 않은 소프트웨어에 대해 구성 요소 감사 혹은 서비스 데스크로의 소프트웨어

장애 접수 발견되는 경우, 불법 소프트웨어 사용에 대해 발견해 내고 파기 할 수 있도록 해준

다.

! 재무 계획 및 지출 계획 지원. 구성 관리는 완전한 CI의 목록을 제공한다. 이는 유지 보수 비

용 및 라이센스 비용 등에 대한 예측을 보다 쉽게 해준다. (유지보수 계약, 라이센스 갱신 일시,

CI 폐기일, CI 대체 비용 등의 정보 제공). 이와 같은 정보 제공을 통해 IT 관리 중역들의 금융

계획을 지원한다.

! 소프트웨어 변경의 가시화.

! 예견되지 않은 사건에 대한 처리 계획 지원. CMDB와 안전한 라이브러리는 재난 등의 발생 시

필요한 CI의 식별 및 위치 정보 등을 제공함으로써 IT 서비스의 복원을 수월하게 해준다.

! 릴리즈 관리 개선 및 지원. 구성 관리 정보는 릴리즈 내의 변경을 조직화하고 CI 버전 정보의

제공으로 릴리즈 관리를 지원한다.

! 사용되는 CI의 버전 제어에 의한 보안 개선. 이것은 뜻하지 않은 혹은 고의에 의한 잘못된 버

전의 추가로 인해 발생된 변경 사항에 대해 CI를 관리하는 것이므로 보다 어렵다.

! 조직내의 비 인가된 소프트웨어 사용의 감소. 허가되지 않은 소프트웨어와 표준화 되지 않은

소프트웨어, 다른 형태로 구성된 소프트웨어의 사용은 관리의 복잡성을 증가 시키고 유지 관

리 비용의 증가를 가져온다. 이러한 상황의 방지는 조직에 이익을 가져온다.

! 예견된 변경에 대해 발생 가능한 충격에 대해 분석을 가능하게 하고 안전하고, 효율적이고, 효

과적으로 변경을 처리할 수 있게 한다. 이는 현재 환경에 대해 변경으로 인한 충격을 최소화

하는 것이다.

! 문제 관리에 문제 발생 경향에 대한 동향 데이터를 제공. 이와 같은 데이터는 특정 CI에 영향

을 끼치는 문제 사항에 대한 경향에 대한 분석을 가능하게 한다. 이 데이터는 문제 관리 프로

세스에서 예견되는 문제를 예방하기 위해 사용되어 진다.

7.4.2. 발생 가능한 문제점

구성 관리 프로세스에서 발생 가능한 문제점이다.

! 너무 상세하게 정의된 CI레벨 (그래서 직원에게 불필요한 업무를 과중시키는) 혹은 너무 상세

하지 않은 CI레벨 (그래서 불충분한 제어를 수행하게 되는)

- 121 -


! 충분한 분석과 설계 없이 시도된 구성 관리 프로세스 구현

! 계획 일정이 너무 의욕적인 경우. 구성 관리와 관련된 직원들 자신이 자신들의 의무 사항과

책임에 대해 충분히 숙지할 만한 시간이 주어지지 않고 성급하게 구성 관리 프로세스를 정착

시키고자 하는 경우에는 병목 현상이 발생한다. 변경과 릴리즈가 진행될 때, 구성 관리 활동에

소요되는 시간은 과거의 경험에 의해 계산 되어진다. IT 관리는 구성 관리에 소요되는 시간과

최상 프로세스 진행 경로를 위해 자동화된 구성 관리 시스템의 구현이 필요하다.

! 책임 관리의 부족. 매니저의 확고한 책임 의식이 없이 몇몇의 직원에 의해 제어되는 구성 관

리는 제대로 실행되기 어렵다. 또한 잘못 진행되는 구성 관리 절차는 매니저에게 보고되고 개

선되어져야 한다.

! 프로세스가 너무 관료적이고 엄격한 경우. 결과적으로, 개별 사용자와 그룹은 구성 관리 프로

세스를 따르려 하지 않게 된다.

! 프로세스가 너무 틀에 얽매여 일상적으로 돌아가는 경우. 어떤 사람들은 프로세스의 빠른 진

행을 위해, 혹은 악의적인 의도로 구성 관리 프로세스 절차를 위배하려 할 것이다. 이와 같은

시도는 그와 같은 시도를 하는 사람에게 구성 관리의 장점에 대해 인지를 시켜 극복해야 할

것이다.

! 프로세스 자체가 비능률적이고 에러가 있는 경우. 이와 같은 경우는 구성 관리를 수동으로 진

행할 때 발생할 수 있는 문제이다. 거의 모든 경우에서 구성 관리 착수 시점부터 자동화된 솔

루션을 채택하여 구현하는 것이 현명하다.

! 도구에 대한 기대치가 비 현실적일 수 있다. 직원과 매니저는 종종 구성 관리 도구가 모든 구

성 관리 프로세스를 다 처리할 수 있다고 생각하며, 그와 같이 안 되는 경우, 도구를 탓하거나

업무를 처리하는 사람이 무능력하다고 생각할 수 있다.

! 선택한 도구가 유연성이 없는 경우. 구성 관리 도구가 새로운 요구 사항이나 모든 CI의 범주

를 지원하지 못할 경우, 시스템에 구성 관리가 반영되지 않는 문제가 발생한다.

! 구성 관리만이 별도로 분리되어 구축된 경우. 만약 구성 관리가 변경 혹은 릴리즈 관리 등의

다른 프로세스와 연계되어 구축되지 않는다면 효율적이지 못하고 충분한 이익을 얻을 수 없는

시스템이 된다.

! 구성 관리 프로세스에 대한 기대치가 비 현실적일 수 있다. 자산과 구성 관리는 잘못된 프로

젝트 관리와 잘못 수용된 테스팅에 대한 보충까지 하지도 않고, 할 수도 없다. 어설프게 제어

된 설치와 테스트 환경은 릴리즈 관리에 영향을 끼치며 부가적으로 사건, 문제, 변경 관리에도

문제를 일으켜 부가적인 자원의 사용을 야기시킨다.

! 구성 제어의 어려움. 예를 들어, 일반 사용자들이 인터넷을 통해 소프트웨어를 다운로드 하여

설치, 사용하거나 개인이 별도 구매하여 사용하는 경우에 대해 제어를 한다는 것은 상당히 어

려운 문제이다.

7.5. 계획 및 구현

많은 기업들이 구성 관리를 구현하기 이전에 자산 관리를 구현한다. 이번 절에서는 자산과 구성 관리

프로세스에 대해 기술한다.

- 122 -


여러 지역의 여러 지원 그룹에 의해 관리되는 분산 시스템에 걸쳐 있는 서비스와 IT 인프라스트럭쳐를

제어하는 것은 세심하고 주의 깊은 계획을 필요로 한다. 이와 같은 계획은 변경 관리, 구성 관리, 릴리

즈 관리 프로세스간의 많은 상호 의존적인 관계로 인해, 같이 포함하여 진행하여야 한다. 변경 관리,

구성 관리 및 릴리즈 관리를 위한 Central Function의 계획 및 구현은 분산되어 있는 스페셜리스트 팀

의 지원과 함께 고려 되어져야 한다. (부록 7A 참조)

7.5.1. 초기 계획

구성 관리를 위한 초기 프로젝트 계획에는 아래 사항들이 포함된다.

! 구성 관리를 위한 목적 및 목표, 범위, 우선순위, 구현의 접근 방법에 대한 동의를 얻는 것

! 구성 관리 프로세스 및 시스템 구축을 위한 담당자 선정

! 기존에 존재하는 구성 관리 시스템과 데이터, 프로세스의 분석

! 높은 수준의 구성 관리 계획 개발 (조직의 변경 관리 및 구성 관리를 포함한)과 구성 관리 시

스템 설계

! 구성 관리를 위한 비용 계획 및 승인과 여분의 자원 위임

! 조직의 정책 및 프로세스에 대한 협의

변경 관리와 구성 관리를 위한 시스템이 종이를 이용한 서류 기반의 시스템이라면 이는 대단히 실용적

이지 못하고 비 현실적인 시스템이 된다. 구성 관리 도구, 특히 CMDB는 컴퓨터 하드웨어와 스토리지

를 필요로 한다. 최소한 구성 관리 지원 도구는 별도의 프로젝트 구성 관리 시스템으로부터 다시 수동

입력을 하지 않고 데이터를 이동 시켜 사용할 수 있어야 한다. 이상적으로, 살아있는 구성 관리 시스템

이란 다른 시스템과의 통합을 통해 같이 움직일 수 있는 시스템이다.

한번 높은 수준의 구성 관리 계획이 동의되고 결정되면, 구현 계획이 수립된다. 구현 단계에는 서비스

와 조직에 대한 정보를 잘 정의한 후 시작하기를 권유한다. 이는 구현 초기에 구성 관리에 대한 이익

을 가시적으로 나타내어 주고 다음 단계로의 보다 효과적인 구현을 가능하게 해준다.

7.5.2. 비즈니스 목표 따른 구현 접근 배치 및 구성 관리의 목적, 목표, 범위, 우선 순위에 대한 협의

구성 관리의 목적 및 목표, 범위, 우선 순위는 서비스 매니저와 다른 매니저들의 협의에 의해 결정되어

지며 비즈니스 요구 사항에 의해 배치되어 지며 구성 관리가 변경 관리와 릴리즈 관리를 포함한

Central Function을 포함하여 수행하는지 어떤지에 대해 협의 되어 진다.

목적 및 범위

운영 환경, 패키지 어플리케이션, 비즈니스 시스템과 조화 할 수 있는 구성 관리, 변경 관리, 릴리즈 관

리 프로세스를 구현하는 것이다.

목표

모든 IT 서비스와 인프라스트럭쳐 구성 요소와 관련된 문서화, 제어하에 두는 것, 효율적이고 효과적인

계획, IT 서비스의 변경 및 릴리즈를 실행을 위한 정보 서비스를 제공하는 것이다.

- 123 -


구성 관리의 상세한 목표는 다음과 같다.

! 서비스 관리와 지원 분야에서 일하는 모든 사람들에게 구성 정보의 물리적 기능적 명세와 함

께 현재의 설정 정보를 제공하는 것

! 업무 절차와 사례에 대해 정의하고 문서화 하는 것

! IT 서비스와 인프라스트럭쳐, CI의 간의 관계를 보충하는 CI 식별, 라벨링, 이름과 버전 기록

! 허가 받고 검증 받은 신뢰할 만한 문서와 소프트웨어, 명세서의 저장 및 제어

! IT 인프라스트럭쳐의 모든 구성 아이템의 현재와 과거 상태에 대한 기록

! CI의 모든 변경 사항의 기록

! 승인된 구성 데이터 및 기록 대비 실제 IT 인프라스트럭쳐의 상태의 추적 및 조정

! 제어 프로세스에 대한 교육과 훈련

! CI, 변경, 릴리즈 관련 리포팅

! 구성 관리 절차와 표준 인프라스트럭쳐에 위배되는 사항에 대한 감사 및 보고

많은 조직들에 대해, 구성 관리 구현에 변경 관리를 포함 시키는 것은 필수적이다. 구성 관리의 실행

의 접근은 조직적, 지리적, 고객 그룹, 지원 그룹 혹은 다른 원칙에 의존적일 수 있다. 어떠한 조직들은

CI 타입에 우선순위를 매긴다.

가장 우선 순위가 높은 항목들은

! 인프라스트럭쳐 서버

! 메인 프레임

! 고객과 공급자 데이터베이스

! 운영 환경과 비즈니스 시스템 관련 어플리케이션 지원

! 중요한 서비스

! 데스크탑 및 소프트웨어 라이센스

! 네트워크

이와 같은 우선 순위는 다른 그룹들의 업무 절차와 사례의 변경과 균형을 이루어야만 한다. 짧은 시간

안에 변경 관리와 구성 관리를 조합하여 구현하는 것은 매우 어려운 일이다.

하드웨어를 포함한 구성 관리 지원 도구에 대한 비용 계획도 수립되어야 한다. 비록 단순한 구성 관리

시스템 보다

사건 관리, 변경 관리, 구성 관리, 릴리즈 관리, 문제 관리, 서비스 데스크를 위한 통합 지원이 되는 도

구가 많은 비용이 드는 것처럼 보이지만, 부가 적인 비용은 부가적인 기능의 통합을 가능하게 한다는

사실로 인해 정당하다는 결론이 난다. 거대한 조직에서는, 이러한 관리 프로세스는 적절한 지원 도구가

없다면 구현 및 실행이 사실상 불가능하다.

- 124 -


7.5.3. 구성 관리자의 선임 및 구성 관리 팀 계획

Central Function이 하드웨어, 통신 장비, 소프트웨어, 사용중인 소프트웨어, 그리고 모든 문서 및 절차

의 변경을 관리 할 수 있도록 셋업 되어 지는 것은 현재 시스템의 운영과 지원 및 유지 보수와 관련이

있다. Central Function의 셋업에 대한 가이드는 부록 7A를 참조한다.

구성 관리는 부지런하고 세심한 주의력을 갖고 있는 직원을 필요로 한다. 다음과 같은 요소들을 고려

하여 구성 관리를 위한 직원의 수를 산정한다.

! 구성 관리에 다른 책임이 할당되는지 아닌지

! 구성 관리 팀에 IT 인프라스트럭쳐와 서비스뿐만 아니라 프로젝트에 대한 책임도 할당 되는지

! 그룹이 변경, 구성, 릴리즈 관리팀이 합쳐져서 구성 되는지

! IT 인프라스트럭쳐의 규모와 관리하여야 하는 CI의 수 및 CI 레벨

! 다른 그룹과 프로젝트의 활동 제한을 수행하여야 하는 직원의 수

! 지원 도구가 어느 정도 지원을 해 주는지

! 변경과 릴리즈의 규모와 발생 빈도, 복잡성

구성 관리 팀의 업무 명세는 개발되어 져야 한다. 구성 관리 팀의 의무에 대한 내용은 부록 7B를 참조

한다. 구성 관리 매니저와 구성 관리 데이터를 관리하는 운영자의 전형적인 업무에 대해 나와 있다.

7.5.4. 기존 시스템 분석

구성 관리 프로세스가 전혀 없는 조직부터, 많은 부분의 구성 관리 프로세스와 절차를 가지고 있는 조

직들이 있다. 기존에 존재하는 구성 관리 절차는 다른 절차들 내에 포함되어 있거나 특정 팀에 한정되

어 있을 것이다. 만약 목표 중 한가지가 일관된 프로세스를 통해 공통된 구성 관리 시스템의 구축이라

면, 중요한 활동 하나는 아래의 내용에 대해 식별하고 분석하는 것이다.

! 상위 단계 CI의 소유자

! 현재의 범위와 자원 (사람과 도구)

! 현재의 변경 관리, 구성 관리의 사례와 프로세스, 절차

! 현재 품목 일람, 하드 카피, 스프레드 쉬트, 혹은 데이터베이스에 저장되어 있는 상위 단계 CI

데이터

! 구성 관리를 담당하는 직원의 역할과 책임 및 능력

7.5.5. 구성 관리 계획 전개 및 시스템 설계

기술적, 플랫폼 측면에서 구성 관리는 조직적으로 분산되어 있다. 예를 들면 메인프레임, 물리적 네트

워크, 데스크탑 등.

어떤 조직에서는 전문가 영역의 집중된 직원을 훈련시키는 것이 비용적인 측면에서 효율적이지 않기

때문에 특정 기술이나 플랫폼의 전문가 별로 지원 그룹으로 나누어 통제한다. 이와 같은 경우, 지원 그

룹의 매니저는 그룹 별로 소유하고 관리하는 CI의 통제에 대한 책임을 갖는다. 변경 관리, 구성 관리,

릴리즈 관리와 중앙 집중화된 CMDB를 위한 조직의 업무 절차는 어떤 경우에도 채택되어 져야 한다.

- 125 -


이와 같은 것은 조직을 위한 변경과 구성 관리 계획 (부록 7A 참조)을 정의하는 것이며, 구성 관리 시

스템을 위한 설계 문서와 기능 문서에 의해 뒷받침 되어 진다.

계획 사이의 관계에 대한 내용은 그 계획에 대해 승인을 하는 각 그룹의 매니저와 업무 진행을 위한

직원이 구성 관리의 전후 관계에 대해 알 수 있도록 문서화 되어야 한다. 관계에 대한 예는 그림 7.2에

나타난다.

계획의 중복을 피하기 위하여 하위 수준의 계획부터 배치하고 상위 수준의 계획으로 이동한다.

비록 조직의 구성 관리의 책임들이 특정 전문가 집단들 기준으로 할당되어야 하는 상황이겠지만, 이상

적인 그림은 만약 자원이 허락한다면, 중앙 집중화된 기능으로 구성 관리의 조직을 구성하는 것이며,

이 것은 통일된 프로세스와 업무 절차를 보장할 수 있다.

구성 관리에 대한 규칙적인 감사와 관리는 구성 관리를 수행하는 조직과는 별개인 다른 조직이 수행하

여야 한다.

그림 7.2 – 조직화된 구성 관리 계획의 예제

구성 관리 계획은 구성 관리에 대한 범위, 시스템 설계를 위한 유용한 입력물 및 다음 단계로의 계획

을 정의한다.

7.5.6. 구현을 위한 상세 계획

구성 관리 범위에 대한 기본적인 결정이 만들어 지고, 계획 활동이 완료되면, 구성 관리 구현을 위한

계획을 고려해야 하는 시기이다. 일반적인 사이트라면 이미 구성 관리 절차와 기록들이 이미 존재할

것이다. 이것들을 명확하게 할 필요가 있다.

주요 실행 내역은 다음과 같다.

! 이미 존재하는 구성 관리의 사례들을 보다 상세하게 분석하고, 다른 서비스 관리 프로세스와

의 상호 관계에 대해 분석한다.

! 구성, 변경, 릴리즈 관리업무에 관여하는 직원과 기존에 존재하는 기능의 능력에대해 분석한다.

- 126 -


! 기존에 하드 카피나 스프레드 쉬트, 혹은 데이터베이스에 존재하는 구성 데이터를 검토하고

데이터의 전환 및 로딩 전략을 개발한다.

! 필요한 것들을 수집하고, 정제하고, 협의를 얻고, 기능 적인 요구 사항들을 명세화 한다.

! 구성 관리 자동화를 위한 개발 업체를 선정한다.

! CMDB와 구성 관리 자동화 도구를 평가하고 선택한다.

! CMDB와 다른 구성 관리 도구를 구매하고 설치한다.

! 변경 관리, 릴리즈 관리 및 다른 서비스 관리 프로세스와의 상호 연계 방안을 포함하여 구성

관리 시스템을 상세히 설계하고, 개발한다.

! CI 타입, 속성, 관계 유형, 상위 단계 CI의 셋업

! 구성 관리 도구와 연계된 구성 관리 비즈니스 프로세스 및 절차 개발

! 성공적인 구성 관리 운영에 영향을 미치지 않도록 구성 관리의 구현이 완료되어 프로세스가

고정되기 전에 CMDB와 구성 관리 지원 도구에 대한 오류 및 문제 사항을 수정하기 위한 충

분한 시간을 확보하여 테스트를 한다.

! 릴리즈 관리와 연계하여 CI를 관리할 저장 공간 대해 계획하고 보안 방안을 마련한다.

! 훈련 계획 및 역할과 책임에 대해 개발 하고 동의를 획득한다.

! 변경 관리와 구성 관리 직원의 훈련 및 의사 소통 방안 마련

구성 관리의 구현, 현재 인프라스트럭쳐의 감사, CMDB의 데이터 구성을 위하여 임시 추가 직원이 필

요할 것이다. 때때로 매니저는 구성관리의 이익을 확인하게 된다면, 보조를 위한 직원을 할당할 것이다.

구성 관리의 구현을 위한 계획은 초기에 구성 관리의 이익을 가시적으로 보여줄 것이며, 다음 단계를

위한 자원과 자금의 제공에 대한 필요성을 알게 할 것이다. 각 단계를 위해 다음과 같은 활동 내역이

계획되어 저야 한다.

! 구성 관리에 할당된 핵심 직원에 대한 교육 일정 인식

! 각 그룹 혹은 기술과 특정 환경에서 필요로 하는 업무절차에 대해 정의하고 개발

! 구성 관리 프로세스와 그와 관련된 프로세스, 인터페이스, 데이터를 지원하기 위한 구성 관리

시스템의 분석 및 설계와 단위 구축

! 구성 관리에 합류하는 직원의 업데이트된 역할과 책임의 평가 및 수립

! 새로운 CI가 추가 되었을 때 가능한 빨리 신규 CI를 등록하는 절차에 대한 수립

! 초기 구성 정보와 관련 기록들을 구성 관리 시스템으로 데이터 입력

! 새로운 절차와 도구가 사용되기 전에 직원에 대한 훈련

! 구현의 실행과 지원

! 지속적인 IT 인프라스트럭쳐 CI의 수집. 구현에 있어 소요되는 대부분의 시간은 CI 인벤토리와

CMDB, DSL을 구축하는데 소요된다.

! 새로운 도구와 업무 절차가 효율적이고 효과적인지에 대한 지속적인 모니터링

만약 구성 관리가 다른 프로세스의 하부 프로세스로 구성된다면, 예를 들어 사건 관리 프로세스와 같

- 127 -


은, 향후 계획은 병렬로 시스템 전반에 걸쳐 진행할 필요가 있다. 지역적인 구성 관리 계획은 특정 기

술 그룹을 위한 제어 프로세스와 CI의 식별로 정의 될 것이다. 그룹의 매니저는 CAB의 구성원과 중앙

의 구성 관리 직원과의 의사 소통을 위한 기점으로서 각 지역 구성 관리 계획을 진행하는 구성 매니저

로 할당될 것이다.

각 구현 단계에서 CMDB의 데이터 구축 계획은 실행 된다. 올바른 데이터의 구축을 위한 시간이 확보

되어 져야 한다. 이 업무를 위하여 비록 구성 관리 지원 도구에 친숙해진 구성 관리 직원이 데이터 입

력을 위한 시간이 있더라도 임시직의, 그러나 숙련된 데이터 입력 요원들의 이용을 고려하여야 한다.

만약 다른 목적에 의해 어떠한 데이터가 전자 형태로 이미 존재한다면, 데이터 형태의 제 가공 및 데

이터 전이를 고려한다.

이상적인 CI의 상태는 CMDB의 데이터가 구성되는 동안 휘발성이 낮은 상태로 유지하거나 동결시켜

놓는 것이지만, 실제로는 이와 같이 되지 않을 것이다. 그러나, 특정 CI에 대해 한번 구성 관리 데이터

가 획득되게 되면, 이 CI들은 즉시 구성 관리의 통제를 받을 수 있을 것이다. CI의 CMDB 구성은 단계

적 방법에 따라 구성하는 것이 가능하다. (예를 들어 하드웨어에서 시작해서 점차 소프트웨어와 네트워

크로 확장해 나가는 것) – 7.5.7 절을 참조한다.

모든 준비가 완료되었을 때, 동의된 시점에서 조직원이 새로운 프로세스를 이용한 업무 진행을 시작한

다. 새로운 절차에 영향을 사람들을 위해 실행 시기와 시점에 대해 공지를 한다 – 특히, 모든 IT 서비

스 직원, 외부 공급자, 서비스 공급자 등. 직원은 착수 시점부터 새로운 업무 절차를 정착시키기 위해

자신들의 역할과 책임에 대해 확인을 해야 한다.

7.5.7. CMDB와 DSL 적용

CI는 CI데이터가 수집 되는 시점부터 구성 관리의 통제 하에 놓이게 된다. IT 인프라스트럭쳐에 추가되

는 신규 아이템 중에 구성 관리의 통제권 밖에 놓이는 아이템은 존재하지 않는다.

CMDB의 데이터 구축을 위한 이상적인 옵션은 CMDB 가 구축되는 동안 변경 사항을 없게 동결 시키

는 것이다. 모든 변경 사항은 구성 관리 아래로 들어 와야만 한다. 실제로는 이와 같이 되기 힘들지만

고려할 만한 가치는 있다. 구성 관리와 변경 관리 업무는 매우 밀접하게 함께 수행된다. - 사실, 다른

것 없이 하나만을 구성한다는 것은 있을 수 없다. CMDB 데이터가 구축되자 마자 구성 기록과 데이터

를 유지하는 것 자체가 어느 정도 수준의 변경 관리를 해야만 하는 것이다.

만약 이와 같은 접근이 가능하지 않다면, 구성 관리 통제 하에 CI 데이터를 수집하고 CMDB에 데이터

를 넣고, CI를 가지고 오는 과정에서 발생하는 변경 사항에 대해 기록하는 것은 필수적이다. 이와 같이

하기 위해, 이 단계들간의 시간 간격은 최소한 지켜져야 한다. 아직 실행되지 않은 변경과 관련된 RFC

와 릴리즈 기록은 먼저 획득되어야 한다. 그 이후부터의 모든 RFC는 CMDB에 포함되어 져야 한다. 이

와 같은 접근으로, CMDB는 승인과 실현을 포함한 모든 후속 변경 절차의 기록을 사용할 수 있게 된다.

- 128 -


릴리즈 관리는 CMDB의 구축과 병렬로 DSL (Definitive Software Library)을 구축해야 한다. 구현 절차는

다음과 같은 사항이 수반되어야 한다.

! 오로지 승인되고 법적 라이센스를 갖고 있는 소프트웨어 만이 DSL로 구성된다.

! DSL에 있는 소프트웨어는 보호되어 진다.

! 소프트웨어는 허가 받은 직원에 의해서만 DSL로부터 확인하고 복사할 수 있어야 한다.

필요한 직원과 하드웨어, 지원 도구가 마련되고, 모든 필요한 교육이 완료되는 시점에서, DSL과 구현

환경은 물리적으로 구축되어야 한다. 보안 허용은 승인된 직원에 대해서만 한정된 접근 권한 정책을

이용하여 확립되어야 한다. DSL과 구축 환경은 계획 단계에서 정의되어진 기준과 일치하는지에 대해

검사를 해보아야 한다.

프로젝트와 어플리케이션 담당자들은 실질적인 산출물들이 인도되기 시작하면 알려야 하며 DSL을 관

리하는 사람들에게 보내야 한다. 배치는 관련 문서(e.g. 라이센스) 와 함께 CMDB와 DSL에 수용되어지

는 적절한 상업 소프트웨어로 구성되어 져야 한다.

관리 구현, 분배, 정착의 실행은 때때로 DSL의 생성 이후에 이루어 진다. 이러한 절차는 그것들이 사

용되어 지기 전에 테스트되어져야 한다. 만약 점진적인 접근이 채택되었다면, 첫 번째 릴리즈 구축은

선별되어진 프로젝트 혹은 공급자로부터 인도되어진 것이 운영에서 수용된 테스팅 주제가 될 것이다.

실 환경으로 릴리즈 되는 것은, 릴리즈 통제 절차에 따라 운영 환경에서 승인된 테스트를 거쳐 사용되

어질 소프트웨어로 되는 것이다. 이러한 절차와 도구를 통해 잠재적으로 발생할 수 있는 많은 문제들

을 발견할 기회를 제공하며 올바르게 수정할 수 있는 기회를 갖게 되는 것이다.

그러나 우발적인 계획은 새로운 절차와 도구의 실패를 야기한다. 만약 소프트웨어 릴리즈가 시급히 필

요하다면, 새로운 절차가 올바르게 될 때 까지, 이전 절차로의 임시 원복에 대한 방안이 필요하다. 가

능하다면, 사이트에 소프트웨어를 분배하기 위한 도구 혹은 절차는 문제가 발생할 경우를 대비하여 실

제 환경과 별도의 장소에서 분리되어 고립되어진 환경에서 테스트하기를 권장한다.

비록 절차가 실제 사용 환경에 적용되기 전에 완벽하게 테스팅 되었다 할지라도, 실 환경에서의 사용

초기 단계에는 어떠한 문제가 발생할 수 도 있으므로, 문제 해결을 위한 시간이 있어야 한다.

7.5.8. 새로운 프로세스의 컷 오버

새로운 프로세스의 적용 시작은 CMDB와 DSL의 데이터 구축과 병렬로 실행 될 수 있다. CI는 CI 데이

터가 수집되고 정보가 CMDB에 저장됨에 따라 점차적으로 구성 관리 통제하에 놓이게 될 것이다. 구

성 관리 통제하에 아직 있지 않은 어떤 CI의 변경 사항도 Central Function에 알려 져야 한다. 만약 가

능하다면, 변경에 의해 영향을 받는 CI는 즉시 통제를 받아야 한다. 새로운 구성 관리 시스템으로 전환

이 되고 난 이후의 새로운 모든 CI는 즉시 통제를 받아야 한다.

많은 경우, 업무 절차의 측정과 약간의 구성 통제, 릴리즈, 분배 및 감사 프로세스를 자동화 하는 도구

- 129 -


의 사용은 이전의 절차 혹은 사례로의 회기를 방지 할 수 있다. – 적어도 발견 할 순 있다 –

새로운 구성 관리 시스템이 운영 중 이라면, 어떠한 새로운 아이템도 구성 관리의 승인 없이는 IT 인프

라스트럭쳐에 새로 추가되어서는 안 된다. 개발 혹은 입수, 그리고 제품의 인수 프로세스의 인터페이스

에서는 이와 같은 상황이 발생 할 수 있다. 구성 관리의 통제가 적용되는 (즉, 단계적인 구현을 위해

일시적으로 배제 시켜놓은 CI 이외의 다른 모든 CI 들) 은 승인 없이 변경 되어져서는 안 된다. 승인

받지 않은 모든 CI와 CI의 버전은 삭제를 하던지 아니면 구성 관리의 통제권에 놓던지 해야 한다.

7.5.9. 구현 관련 기타 고려사항

인프라스트럭쳐와 서비스를 위한 구성 관리는 구성 관리 목표와 예상되는 구성 관리의 이익을 달성할

수 있도록 좋은 계획과 설계가 필요하다.

관리와 직원의 장기적인 책무는 구성 관리를 효과적으로 수행하기 위해 요구되어 진다. 성공적인 구성

관리의 구현은 얼마나 충분히 관련 직원을 훈련시켰는가에 따라 의존적이다. 만약 구성 관리가 인원

부족이나 대한 적절한 훈련이 되지 못한 직원에 의해 수행되어 진다면 병목 현상이 발생하게 될 것이

다. 또한 위와 같은 경우에는 구성 관리 기능에 치명적인 오류를 야기 시키게 되며, 처음에 적절한 인

원 배치를 위해 들어가는 비용보다 잘못된 상황을 제대로 바꾸는데 드는 비용이 훨씬 클 것이다. 부가

적인 직원은 구성 관리 구현 중 짧은 기간 동안 필요할 것이다. (예를 들어, CMDB의 데이터를 구성하

고 CI 인벤토리를 구성하는데 필요한 인원들)

구성 관리의 실행은 IT 인프라스트럭쳐의 일부분 혹은 CI 형태별로 가장 중요하거나 혹은 가장 개선이

시급하게 필요한 부분부터 점진적으로 해 나가는 것이 바람직하며, 그 이후에 다른 영역으로의 시스템

확장을 하는 것이 좋다.

복합적인 IT 시스템과 서비스에서, 구성 관리 시스템의 유지 혹은 구성 관리 데이터가 구식이 되어 형

편없이 되는 것을 막아야 하는 것은 필수적이다. 재검토와 감사 활동은 다음과 같은 계획에 의해 실행

되어야 한다.

! 구성 관리 활동은 구성 관리 계획에 반하여 감사되어 진다.

! 구성 관리 내의 CI의 선별은 효과적인 문제 관리, 변경 관리, 릴리즈 관리를 지원하고 통제할

수 있을 정도로 충분히 (그러나 너무 상세하지 않게) 한다.

! 자원을 충분히 활용하고 직원은 구성 관리 활동을 효과적으로 수행하기 위한 훈련을 받는다.

! 소요 시간과 오류 확인 활동을 감소 시키기 위한 자동화의 적절한 수준이 있다.

! IT 서비스 관리 직원은 완전하고 정확한 최신 정보의 구성 관리 기록 및 데이터의 접근을 지

속한다.

- 130 -


7.5.10. 비용

구성 관리 실행 비용은 이익에 비해 과도할 것이다. 예를 들어, 많은 조직들은 질의 희생 없이 소프트

웨어와 하드웨어 변경의 많은 양을 제어할 수 없다면 만족할 만한 기능이 되지 못할 것이다. 적절한

통제 없이, 조직은 컴퓨터 부정 행위, 부주의한 소프트웨어의 파기, 소프트웨어 바이러스와 다른 악의

의 소프트웨어와 같은 것으로부터의 위협을 받는다. 이와 같은 것으로 부터의 손해는 잘못을 수정하기

위해 엄청난 비용이 소요된다.

구성 관리 기능 실행과 관련된 비용은 직업의 급여와 간접비, 지원 도구, 팀을 위한 설비 비용, 훈련

비용 등이 있다. 초기 운영 비용은 직원이 업무 절차에 대해 숙지하는 동안은 정상적인 상황보다 약간

많을지도 모른다.

구성 관리와 구성 관리의 실제 적용은 어떠한 간접비에 의한 보상보다도 더 큰 서비스 질의 향상을 가

져 올 것이다. 간접비는 다음과 같은 많은 요소들에 의해 발생한다.

! 업무 절차를 개발하고 운영하는 직원 비용

! 하드웨어와 소프트웨어의 구성 요소 식별 및 제어 수준

! 라이센스와 유지 보수 비용을 포함한 CMDB와 DSL을 위한 하드웨어, 소프트웨어

! 각 플랫폼을 위한 구성 관리 도구 소프트웨어

! 구성 관리 시스템과 사용자의 컴퓨터 기억 장치에 액세스하는 사용자 수

! 구성 관리 시스템이 조직의 필요 만큼 끝마무리가 잘되었는지 아닌지

! 구성 관리와 서비스 관리 도구의 통합이 되었는지 아닌지

! 기존에 존재하는 정보의 질과 다양성의 CMDB로의 적용

초기의 데이터 수집 훈련 기간 동안은 직원 비용이 증가할 것이다. 그러나 과부하에 따라 구성 관리와

변경 관리 직원을 분류하는 실수를 범해서는 안 된다. 만약 구성 관리가 수행되지 않았다면, 필요로 하

는 직원의 배치가 증가하는 것 같이 보일 것이다. 잘못된 것을 올바르게 하기 위해서는 시간이 필요하

며, 이로 인해 변경과 문제를 다루기 위한 더 많은 직원이 필요하게 될 것이다.

구성 관리 실행을 위한 다른 소요 비용은 다음과 같다.

! 직원 훈련 및 교육

! CMDB와 DSL로 넣어야 하는 기존 정보의 질과 다양성, 그리고 그것에 대해 재검토하는 노력

! 오염된 데이터를 정제하기 위한 시간과 자원

! 기존 커미트먼트의 영향

- 131 -


7.6. 활동

7.6.1. 구성 관리 계획

구성 관리 계획은 간결하고 중복을 피하기 위해 기존의 절차와 계획을 참조하여야 한다. 구성 관리 계

획은 다음을 정의한다.

! 구성 관리의 목적, 목표, 범위 (그리고 조직의 전반적인 변경 관리와 구성 관리 계획과 어떻게

부합하는지)

! 지원 그룹을 위한 특정 관련 정책, 표준화, 프로세스

! 구성 관리 역할과 책임

! CI 명명 규칙

! 구성 관리 활동을 수행하기 위한 일정 및 절차 : 구성 요소 식별, 통제, 상태 기록, 구성 감사

및 검증

! 타 부분과의 인터페이스 통제. E.g. 변경 관리, 공급자

! 아래의 핵심 인터페이스와 범위를 포함하는 구성 관리 시스템 설계

- CMDB

- 구성 관리 데이터와 라이브러리의 위치

- 다뤄지는 CI에 대한 통제 환경

- 다른 서비스 관리 시스템과의 연계 및 인터페이스

- 지원 도구 (e.g. 구축 및 설치 도구 등)

! CI의 보존 기간, 기록, 보관, 라이센스 관리 등

! 각 다음 단계를 위한 자원 계획, 구성 관리 기준선, 주요 릴리즈 , 기준점, 업무 계획

처음 3개월에서 6개월까지의 중요 계획은 상세히 세우고, 12개월의 계획은 전체적인 윤곽만 구상한다.

계획과 관련된 성과는 서비스를 위해 필요한 자원과 기간 동안의 구성 관리 업무 부하에 대해 주기적

으로 – 적어도 6개월에 한번씩 – 재검토 한다. 계획에 대한 점검은 직원과, IT 자원, 그리고 지원 도구

가 적합한지에 대한 – CMDB의 크기가 구성 관리를 수행하기 충분한지를 포함하여 - 보증을 하게 된다.

시간이 경과함에 따라 구성 관리 활동이 증가한다는 것은 일반적인 사실이다. 제어되는 CI의 개수와

그것에 영향을 끼치는 변경의 빈도수는 변할 것이다. 증가에 대한 정보는 조직의 IT 서비스, 업무 부하

및 용량 계획에 이용되어져야 한다. IT 서비스 관리는 효율적이고 효과적인 구성 관리 기능의 감사 및

재검토, 관리 보고서에 비추어 변경을 실행하기로 결정할 수도 있다.

각각의 재검토 포인트는, 이전 기간 동안의 구성 관리 계획이 실제 활동과 비교하여 어떻게 지켜졌는

지에 대한 것이다. 계획된 프로세스의 불완전한 부분은 다음 계획의 개선에 반영되어져야 한다.

구성 관리 그룹, IT 서비스 관리의 향 후 업무의 고려에서는 중복된 데이터는 깨끗이 제거하고, 오로지

필요한 구성 관리 데이터의 조작만이 보장되어야 한다. CI 명세를 유지하고, 수집하기 위한 비용은 현

- 132 -


재와 잠재적 이익과 비교되어야 한다. 만약 현재의 CI 상세 정도가 너무 많은 비용을 초래한다며, 그

와 같은 상세 수준으로 CI를 저장하지 말아야 한다.

7.6.2. 구성 요소 식별

IT 인프라스트럭쳐 구성은 분해되고, 효과적인 제어가 가능하도록 유일하게 구분되어야 하며, 비즈니스

요구 사항에 맞는 수준으로 기록되고 보고 되어야 한다. 개략적인 가이드는, ‘독립적인 변경’ 수준이어

야 한다는 것이다. 이 유효 범위는 CI의 구축, 릴리즈, 검증, 설치, 분배, 유지 보수, 복구 및 폐기로 관

리되는 하드웨어와 소프트웨어의 포함이다. 이것은 CI의 구축에 사용되어 지는 소프트웨어 도구와 환

경을 포함한다. 식별되어져야 하는 구성 요소의 예는 다음과 같다.

! 하드웨어 (관련된 네트워크 구성 요소 포함)

! OS를 포함한 시스템 소프트웨어

! 비즈니스 및 고객 시스템

! 패키지 – 사용 패키지, 일반적인 프로덕트 및 데이터베이스 제품

! 물리적 데이터베이스

! 환경

! 데이터베이스와 응용 어플리케이션 사이의 데이터 교환 및 EDI (전자 자료 교환 : Electronic

Data Interchange) 링크

! 구성 기준선

! 소프트웨어 릴리즈

! 구성 관련 문서. E.g. 시스템 및 인터페이스 관련 문서, 라이센스, 유지 보수 협약, SLA, 폐기

보고서 등

! 변경 관련 문서

! 다른 자원. E.g. 사용자, 공급자, 계약

! 네트워크 구성 요소

! 서비스 관리 요소 및 용량 계획, IT 서비스 지속성 계획, 사건, 문제 알려진 오류, RFC 등과 같

은 것들의 기록

어느 정도의 CI 수준이 필요한지에 대한 고려는 중요하다. 예를 들어 단지 PC를 PC 수준으로 등록 할

것인지, 아니면 좀더 깊이 들어가 모니터, 기본 Unit, 키보드, 마우스 까지 등록 할지 – 혹은 좀 더 들

어가 네트워크 카드, 하드 디스크 타입 등등까지.

이와 같은 질문은 소프트웨어 (모듈별, 하위 모듈별, 혹은 다른 레벨) 에서도 가능하다. 이는 실 환경에

서 많은 협의와 토의를 통해 어느 정도의 수준이 필요한지에 대해 결정 되어야 한다.

생성되는 데이터베이스의 크기와 감사 및 유지 보수 관련 업무를 고려하여, 정말 각각의 PC를 열고 내

부 구성 요소까지 감사할 필요가 있는지에 대해 자문해 보아야 한다. 이와 같은 이슈에 대한 결정 이

전에, 데이터베이스에 대해 어떻게 유지 보수 할지에 대한 계획 및 정보를 유지 보수하기 위해 무엇을

할 것인지에 대해 고려가 되어야 한다. 예를 들어, 어떻게 1000대의 PC 각각에 설치되고 업데이트 된

- 133 -


소프트웨어를 파악하고 데이터를 관리하기 위해 무엇을 어떻게 할 것인가? 데이터베이스는 과연 인프

라스트럭쳐의 금융 가치를 평가하는데 사용되어 지는가? 하위 수준의 데이터를 관리하는게 비즈니스에

어떤 가치가 있는가? 등에 대한 질문이다.

구성 구조 및 CI 선별

구성 구조는 각 구조에 대한 CI의 위치 및 관계에 대해 묘사되어 저야 한다. 부가적으로 IT 인프라스트

럭쳐의 구성 구조는 특정 서비스에 관련된 모든 구성 요소의 식별을 통한 서비스 구성 구조를 취해야

한다. CI의 분해 과정은 최상위 CI를 어떻게 구성 하는지에 따라 선별되어 져야 한다. CI는 다른 몇 개

의 CI의 하나의 부분이 되 거나, 혹은 동시에 CI 묶음이 될 수 있다. 예를 들면, 데이터 베이스 제품은

많은 어플리케이션에 의해 사용되어 질 것이다. 서비스의 공통 구성 요소와 사용 요소간의 링크는 정

의 되어야 한다. 예를 들어 소매 서비스를 위한 구성 요소 구조는 서버, 네트워크, 소프트웨어 CI 등과

같은 요소로 구성된 인프라스트럭쳐 CI를 사용할 것이다.

다른 구성 요소 구조를 통해 여러 관점으로 나타내어 지는 것은, 변경 관리, 릴리즈 관리, 서비스 보고

서, 충격 분석을 개선한다.

CI 수준은 비즈니스와 서비스 요구 사항에 따라 결정되어 진다. 비록 당장 CMDB에 데이터를 구축하

지 않더라도, 필요한 가장 하위 수준의 CI가 무엇인지에 대한 결정을 해야 한다.

이와 같은 행동은 시간을 투자할 충분한 가치가 있는 것이며, 좀 더 앞을 바라볼 수 있게 해준다. 이는

향 후에 CMDB를 재 구성 해야하는 경우에 발생하는 비용을 절약하여 준다. 그러나 언제나 제대로 된

CI의 수준을 결정한다는 것은 쉬운일이 아니다. 만약 가능하다면, 하위 수준의 CI를 더 분류하는데 지

나치게 제약적이지 않는 구성 관리 도구를 채택하여야 한다. 만약 이것이 가능하지 않다면, 각각의 CI

의 구현 수준과 같은 특성을 기록할 수 있는 도구를 채택하도록 한다. 인프라스트럭쳐와 구성 요소의,

분해에 대해 그림 7.3, 7.4 그리고 7.5를 참조한다.

그림 7.3 – 구성 요소 분해 구조의 예

- 134 -


그림 7.4- 인프라스트럭쳐의 예

그림 7.5 – 그림 7.4의 인프라스트럭쳐에 대한 구성 요소 분해 구조의 예

비록 하나의 자식 CI가 하나의 부모 CI에 속하긴 하나, 자식 CI는 다른 여러 CI의 자식 혹은 부모가

될 수 있다. 만약 표준 소프트웨어 구성 묶음이 사용되어 진다면 (예를 들어 동일 소프트웨어에 접속해

야 하는 전국적 네트워크에 물려있는 모든 단말기), 이러한 묶음은 정의되고 ‘접속’이라는 관계가 수립

될 수 있다. 이것은 각 개별 소프트웨어와 단말기간의 관계 수립 보다 훨씬 적은 수의 관계 정의만이

필요하게 된다.

- 135 -


어떤 경우에는, 네트워크 서비스가 IT 인프라스트럭쳐 혹은 그 일부로 간주되어지지만 구성 관리의 통

제하에 놓일 수 없을 때가 있다. 예를 들어, 다른 조직이 소유하고 있는 외부의 WAN (Wild Area

Network)는 ‘연결’ 혹은 ‘사용되어 지는’ 이라는 관계에 의해 네트워크의 모든 연결의 가장 상위 수준의

CI가 될 수 있다. 그림 7.6 이 이와 같은 관계에 대한 정의를 보여준다.

적당한 CI 수준의 선택은 정보의 사용성과 CI의 통제와 자원 및 노력 사이의 균형에 의한 결정이다.

예를 들어 만약 변경이 그림 7.3의 모듈 1-2-2에서 발생하였다면, 프로그램 수준보다 모듈 수준의 변경

으로 기록하는 것이 나을 것이다.- 그러나 이와 같이 모듈 수준 까지 관리하는 것은 CMDB의 데이터

구성과 유지 보수에 많은 비용이 소요 될 것이다.

반면, 실질적인 변경 사항은 CMDB에서 기록되는 수준으로 만들어 저야 한다. 그러므로, 만약 CMDB

에 프로그램 수준으로 소프트웨어에 대한 정보를 기록하기로 결정 하였다면, 변경은 프로그램 수준에

서 이루어 져야 한다. 예를 들어, 만약 단일 모듈이 변경되었다면, 그것은 프로그램 수준에서 변경이

되어 저야 하므로 전체 프로그램의 재컴파일이 필요하게 될 것이다.

만약 하위 수준의 CI 정보가 가치가 없는 것이라면, - 예를 들어 조직이 키보드를 하나의 소모품으로

간주하는 경우 – 이러한 정보는 저장할 필요가 없다. CI 정보는 변경 관리를 수월하게 하고, 사건과 문

제의 제어, 혹은 독립적으로 움직이고, 복사될 수 있거나 혹은 변경될 수 있는 자산인 경우에만 관리할

가치가 있는 것이다.

조직은 CI 수준에 대해 주기적인 재검토를 위한 계획을 수립하여야 한다.- 하위수준의 CI가 여전히 유

용하고 가치 있는 정보인지, 그리고 CMDB에 충분한 하위 수준의 데이터가 없기 때문에 변경 관리, 문

제 관리, 자산 관리의 조작을 하는데 부족함이 없는지에 대한 확인을 위하여.

- 136 -


그림 7.6 – 외부 네트워크의 예

CI 유형 및 라이프 사이클

구성 요소는 그들에 어디에 위치하는지, 아이템의 상태가 어떠한지, 어디에 사용되어 지는 지 등에 대

해 구분되고 문서화 되어야 하기 때문에 CI의 형태별로 구분 되어져야 한다.

전형적인 CI의 형태는 다음과 같다: 소프트웨어 제품별, 비즈니스 시스템, 시스템 소프트웨어, 서버, 메

인프레임, 워크스테이션, 노트북, 라우터, 허브 등.

각 CI 형태별 라이프 사이클 또한 정의 되어야 한다. 예를 들면, 어플리케이션의 릴리즈는 등록, 승인,

설치, 제거로 정의될 수 있다. 패키지 어플리케이션의 릴리즈를 위한 라이프 사이클의 예는 그림 7.7과

같다. 이와 같은 CI의 상태 변경은 적용 역할은 구성 관리, 릴리즈 관리 등에 의해 정의 되어 진다.

그림 7.7 – IT 인프라스트럭쳐에서의 어플리케이션 릴리즈 라이프 사이클의 예

구성 관리에서는 어떠한 속성이 기록되어 질지에 대해 계획이 세워져야 한다. CI의 다른 형태에 따라

수정되어진 필요 속성들은 현재와 예측 되어지는 CI 형태에 대해서만 주어진다. 어떠한 구성 관리 지

원 도구들은 이와 같은 속성들이 이미 정의되어 있으므로 주의를 하여야 한다. 부록 7C에 CI의 속성에

- 137 -


대한 추천 항목 들이 기술되어 있다. 이 속성은 중요하거나 높은 위험요소를 내제한 CI의 속성으로 유

용하다.

CI 관계

CI 간의 관계는 의존 정보를 제공하기 위하여 기록되어 진다.

예를 들면 다음과 같다.

! 하나의 CI는 다른 CI의 한 부분이다. (예를 들면, 프로그램의 하나의 소프트웨어 모듈, 사이트

인프라스트럭쳐의 한 부분인 서버 시스템)- 이는 부모/자식의 관계이다.

! 다른 CI에 연결된 하나의 CI (예를 들어 LAN에 연결되어 있는 데스크탑 컴퓨터)

! 다른 CI에 의해 사용되어 지는 하나의 CI (예를 들면, 다른 프로그램에 의해 사용되어지는 하

나의 프로그램 모듈, 비즈니스 서비스가 사용하는 인프라스트럭쳐 서버 시스템)

이 보다 훨씬 많은 관계의 형태가 있을 것이다. 그러나 이와 같은 모든 관계 정보가 CMDB에 기록되

어 진다. – 이것은 CMDB에 무엇을 기록하고 무슨 자산을 등록할 것인가 와는 큰 차이가 있다.

관계 구조는 IT 인프라스트럭쳐 CI에 대한 RFC, 사건 기록 (IRs : Incident records), 문제 기록, 알려진

오류, 그리고 릴리즈 기록등과 관련된 정보가 필요하다. 이와 같은 모든 관계는 CMDB에 포함되어져야

한다. RFC, 그리고 모든 변경과 릴리즈 기록은 영향을 받는 CI에 대해 식별되어져야 하며 또한 변경의

구성을 식별하여야 한다. 좀 더 상세한 내용은 9장의 릴리즈 관리를 참조한다.

소프트웨어 식별 및 문서 수집

물리적, 전자적 소프트웨어 라이브러리는 다음과 같은 정보에 따라 유일하게 식별되어야 한다.

! 내용, 위치, 각 라이브러리 매체

! 라이브러리 구성의 최소 상태를 포함하여, 아이템의 목록을 입력하기 위한 상태

! 고의에 의해, 혹은 실수로 발생 할 수 있는 문제점으로부터 라이브러리를 어떻게 보호할지에

대한 방법과 문제 발생 시, 효과적인 복구 절차에 대한 방법

! CI의 등록, 읽기, 업데이트, 복사, 제거를 하는 사람이나 그룹에 대한 접근 및 상태 제어

구성 요소 기준선 식별

구성 관리 기준선 (baseline)은 다음과 같은 이유로 만들어진다.

! 미래 업무를 위한 완전한 기준 (e.g. 어플리케이션의 승인과 같은 CI의 존속 기간 중의 시점)

! RFC에 의해 영향을 받고, 실제 변경이 되는 CI의 기록

! 만약 일이 잘못 되었을 경우 그 시점으로 돌아가기 위해

구성 관리 기준선 (baseline)은 그 목적, CI, 기준선에 의해 통제되는 정보에 따라 유일해야 한다. 구성

관리 기준선은 관련된 설정 문서를 포함하여야 하며, 다음의 내용을 포함한다.

! 릴리즈 기록 (현재, 과거, 그리고 계획된)

! 다른 변경 기록 (현재 , 과거, 그리고 계획된)

- 138 -


! 시스템의 상태와 변경이 승인 되어지고 적용되어 졌을 때의 시스템의 문서

! 패키지 릴리즈가 적용되었을때의 시스템 상태와 관련 문서

! 하드웨어와 소프트웨어 표준 규격

구성 관리 기준선은 특정 시점의 공식적인 협의에 의해 수립되어져야 하며 구성의 일반적인 통제를 위

한 출발 시점으로 사용되어 진다. 기준선의 몇 예제는 다음과 같이 구분된다.

! 특별한 ‘표준’ CI는 같은 형태의 많은 아이템의 구매 시 필요하다. (e.g. 데스크탑 컴퓨터) 만약

몇몇 서버가 부가적인 기판이 포함되었다면, 이는 ‘플러스 기준선’에 대응된다. 만약 모든 향후

도입될 데스크탑 컴퓨터가 이런 기판을 갖는다면, 새로운 기준선이 생성된다.

! 어플리케이션 릴리즈와 그와 관련된 문서

- 복귀하기 위해 ( 수월한 리버전을 가능하게 하기 위하여)

- 원격지에 배포를 위한 소프트웨어의 상태로서

- 향후 도입되어질 소프트웨어의 상태로서

- 승인된 새로운 하드웨어로의 업그레이드 이전의 시스템의 상태로서

- 혹은 소프트웨어

기준선의 존속 기간의 다른 단계에 대응되는 몇몇 기준선은 주어진 기간 동안에 존재할 수 있다. – 예

를 들어, 소프트웨어 릴리즈를 위한 기준선은 현재 존속, 과거에 존속되었던 것, 그리고 지금 보관되어

있는 것, 다음에 설치 되어질 것 (구성 관리 통제아래 변경을 놓기 위한), 테스트 중에 있는 것 등. 더

나아가, 예를 들어, 만약 새로운 소프트웨어가 지역 특성에 따라 점진적으로 내놓아 진다면, 동시에 ‘현

재’라는 기준선에는 하나 이상의 버전이 있게 될 것이다. 그러므로 ‘현재’, ‘과거’, ‘미래’ 보다는 각 단계

가 유일한 버전 넘버에 의해 참조되어지는 것이 최상이다.

명명 규칙

명명 규칙은 기준선, 릴리즈 뿐만 아니라 구성 문서, 변경, CI의 식별에 적용되어지고 수립되어 진다.

명명 규칙은 유일해야 하며 기존의 회사 혹은 공급자의 이름/넘버링 구조를 고려하여야 한다. 명명 규

칙 혹은 정보 관리 시스템은 다음의 관리가 허용되어야 한다.

! 구성 구조내의 CI간의 계층적 관계

! 각 CI간의 계층적 혹은 하위 관계

! CI와 그와 관련된 문서간의 관계

! 문서와 변경간의 관계

! 사건과 변경간의 관계

구성 관리는 명명 규칙이 모든 CI와 제어 형태(예를 들어 RFC)를 위해 확립될 수 있도록 배치하여야

한다. CI의 개개의 인스턴스는 CI의 이름(복사본/일련 번호, 버전)에 의한 유일한 정의가 가능하여야 한

다. 버전은 같은 CI로 간 주 될 수 있는 변경된 CI에 대한 구분을 하여 준다. 같은 CI에 대해 하나 이

상의 버전이 동시에 존재할 수 있다.

- 139 -


명명 규칙이 계획되었을 때, 향후 확장성에 대한 고려는 매우 중요한 부분이다. 유일 식별자는 짧아야

하지만 의미가 있어야만 하고, 가능한 기존의 규칙이 존재한다면 재 사용해야만 한다. 하드웨어의 경우,

만약 CI 명명 규칙이 공급자의 장비 명, 일련 번호, 메커니즘에 근거 하지 않다면 각 공급자를 식별할

수 있고 구성 관리와 관련된 것으로 설정하여야 한다. – 예를 들면, 하드웨어 엔지니어의 편의를 위한

명명 규칙으로.

릴리즈 기록, 변경 기록과 IT 인프라스트럭쳐와 관련된 다른 CI는 CI로 식별될 필요가 있다. 변경을 나

타내는데 사용되어지는 버전 넘버로는 R1, R2, R3, R4,…와 같은 간단한 이름 구조가 권장된다.

CI 라벨 부여

모든 CI는 쉽게 구분할 수 있도록 라벨이 부착되어야 한다. CI에 라벨을 부착하는 것과 라벨의 정확성

을 유지하기 위한 계획이 수립되어야 한다.

물리적으로 제거되지 않는 라벨이 모든 하드웨어 CI에 부착되어야 한다. 모든 케이블과 라인은 각 종

단점과 검사 부분에 대해 명확한 라벨이 있어야 한다. 사용자들이 전화를 통해 문제 사항에 대해 전화

접수를 할 때 그것들에 대해 식별하여 알리기 쉽도록 하기 위해, 같은 종류의 라벨을 위한 표준 색깔

과 형태를 사용하도록 권고한다. 바코드로 읽을 수 있는 라벨은 물리적 감사의 효율성을 개선 시킨다.

DSL내의 소프트웨어의 최종 사본은 시작 파일에 버전 넘버와 CI 명을 담고 있는 소프트웨어 라벨을

갖고 있어야 한다. 모든 소프트웨어를 저장하고 있는 매체는 매체에 담겨있는 각각의 소프트웨어 아이

템의 CI 명, 카피 넘버, 버전 넘버 등에 대해 명확히 라벨을 부여하여야 한다.

문서의 최종 사본은 결코 유출되어서는 안되지만 문서 라이브러리에는 저장되어져야 한다. 만약 문서

가 알려진 시점에서 변경되어질 것이라면, 유효한 문서 수명 날짜에 대한 정보 또한 담겨야 한다. (예를

들어 “본 문서는 2003년 10월 1일 이 후에는 유효하지 않습니다.” 등)

7.6.3. CI의 제어

구성 제어의 목적은 오로지 승인되어지고 식별되어진 CI만이 CMDB에 저장되도록 하는 것이다. 절차

는 기업의 데이터, 시스템, 프로세스의 무결성을 보장하는 것이다. 변경이 진행될 때, 계획되고 동의되

어진 상태의 넘버를 통해 변경되어 진다. 상태의 예를 들면, ‘등록’, ‘사용 적합’, ‘설치’, ‘사용 중’, ‘폐기’,

‘제안’, ‘제안 완료’, ‘변경 중’ 등이 있다. 절차 상 그리고 기술적 통제는 승인 받지 않은 변경이 사실상

불가능하도록 도입되어야 한다.

라이센스는 관리되어져야 하며, CI의 추가, 업데이트, 폐기 혹은 철회등에 따른 전체 라이센스의 업데이

트는 관리 되어야 한다. 관련된 라이센스 비용이 올바르게 지불 되고, 모든 잘못된 것들은 멈추고, 조

직은 구매한 소프트웨어에 대한 모든 법적 제한 사항을 따르도록 통제하는 절차가 필요하다.

- 140 -


진행되는 구성 통제 프로세스는 다음과 같다.

! 모든 새로운 CI와 버전의 등록

! 다음과 관련된 CI의 기록 업데이트

- CI에 발생된 변경 상태 (e.g. 테스트를 위한 개발, 운영을 위한 테스트, 보관을 위한 운영)

- 속성 업데이트

- 소유권과 역할의 변경

- 변경, 구축, 릴리즈로부터 발생한 문서의 관련 새 버전

- 라이센스 통제

- 사건, 문제, 변경, 릴리즈 기록과 관련된 CI의 링크

! 관련된 CI, 상태, 구축 상세와 함께 RFC 업데이트 (8장의 그림 8.3)

! CI가 삭제되거나 폐기될 때의 관련 기록 업데이트 및 CI 보관

! 구성의 무결성 보호

! 정확한 정보의 사용을 보장하기 위하여 CMDB 대비 실제 물리적 아이템이 존재를 확인 한 후

CMDB 업데이트

신규 CI와 버전의 등록

등록 프로세스는 아이템이 주문되거나 개발이 시작되는 시점부터 시작된다. 어떤 조직은 그들이 주문

을 할 때 CI의 확인을 위하여 인수 프로세스를 사용한다. 공급자는 또한 물건의 발송 전에 CI에 라벨

을 붙인다. CI의 주문과 배달을 이와 같은 방법은 구성 관리의 통제 하에 놓인다.

모든 공급 물품은 기록되어지고 그것의 내용물에 대해 검증되어 져야 한다. 검증 절차에 대한 가이드

는 7.6.4절 (구성 상태 기록)을 참조한다. 만약 소프트웨어나 하드웨어가 검사에 만족하지 못한다면, 수

정 작업이 시작된다. 라이센스의 유지 및 속성은 업데이트 되어져야 한다.

조직내의 소프트웨어 개발 제어

조직 내에서 개발되어지는 소프트웨어에 대해, 인수 시점은 일반적으로 운영 승인을 받고 소프트웨어

의 사용이 시작되는 시점이 된다. DSL의 사용이 권고되어지며, 모든 소프트웨어 CI와 관련 문서들은

최종 상태와 양질의 상태에 대한 관리 상태로 들어간다. 등록 절차는 CI가 개발 라이브러리로부터

DSL로 이동 되기 전에 CMDB에 모든 승인된 소프트웨어와 지원 문서의 상세가 들어가도록 보증하여

야 한다. 이상으로는, 물리적 라이브러리로 전달을 하는 유틸리티 프로그램, 혹은 지원 도구는 CMDB

를 자동으로 업데이트 하는 것이다. 승인 받지 않거나 손상을 입은 아이템은 DSL로 들어가도록 허가

되어 질 수 없다.

구성 되어진 소프트웨어 CI에 대해 – 변경 상태에 대해 새로운 기입이 되기 보다 초기부터 개발 단계

동안 같은 CMDB를 사용하여 관리한다. 만약 공유 데이터베이스가 개발과 CI의 존속, 접근 통제에 사

용되어 진다면 오로지 승인된 직원에 대해서만 접근 통제가 이루어 져야 한다. – 예를 들어, 개발 직원

은 개발 CI에만 접근할 수 있도록 한다. 만약 다른 도구나 데이터베이스가 사용되어 진다면, CI 데이터

- 141 -


는 새로운 CMDB로 이동되어 저야 한다. 이상적인 CI 데이터는 다시 입력될 필요가 없는 것이다.

CI 재고

하드웨어, 통신장비, 문서, 소프트웨어 패키지, 운영 시스템 소프트웨어, 유틸리티 등의 재고 CI에 대한

처리 절차도 계획되어 저야 한다. 변경 관리는 새로운 CI가 전달되고 이 CI들의 상태가 전달, 설치, 테

스트, 승인 되어지는 상태가 되기 전에 모든 승인된 새로운 CI 가 CMDB에 올바르게 등록되는 것을

보장하여야 한다. 검사는 전달된 CI가 승인 되어지도록 한다. 이 검사가 만족할만한 수준으로 완료될

때까지 설치 절차는 진행되어서는 않된다.

구축 및 릴리징으로 부터의 신규 CI 및 버전

훌륭한 구축과 릴리즈 통제는 소프트웨어의 버전 업데이트와 하드웨어의 올바른 구축, 릴리즈에 적합

한 대상 환경으로의 분배를 보장한다. 릴리즈 관리와 함께 구성 관리는 아래 사항을 포함하여 릴리즈

프로세스와 구축의 결과물로의 소프트웨어 버전, 하다웨어, 문서에 대해 기록하고 보고한다.

! 구축이 진행될 대상 환경에 대한 상세

! 구축 도구 및 구축되는 모든 구성 요소의 마스터 복사 본을 위한 참조

! 구축이 릴리즈될 환경의 상세

! 사전 릴리즈와 구성 기록을 위한 참조

소프트웨어 품질 관리 검사가 성공적일 때, 소프트웨어는 DSL로 받아 들여지고 복사되어지는 것이 승

인된다. 복사 혹은 분배 프로세스 동안 소프트웨어가 손상되고 변경되지 않도록 주의한다.

CI 업데이트

전달부터 실제 사용되어 지는 진행 과정 동안 CI의 상태는 변경된다. 이상적으로는, 릴리즈 변경과 CI

의 상태에 대해 CMDB에 자동으로 업데이트 되는 것이다. 테스트 보증, 라이센스와 같은 관련된 문화

는 문서 라이브러리의 통제하에 있도록 한다.

CMDB의 CI의 속성 변경은 속성의 변경에 대해 승인되어진 RFC와 함께 업데이트 되어져야 한다. 만

약 속성에 수정이 필요하다면 – 예를 들어, 감사 이 후에 – 변경 기록은 속성 업데이트 절차가 시작

되어져야 한다.

많은 조직에서 특히 고위 직원과 계약직 직원의 소유권과 역할의 변경에 대한 유지는 어렵다. 소유권

변경에 대한 내용의 CMDB 업데이트를 위한 절차는 변경 요청, 사건, 그리고 문제와 관련된 CI의 정보

를 올바른 부분에 알려주기 위해 필수 적이다.

모든 IT 인프라스트럭쳐 아이템은 보증하기 위하여 구성 관리에 의해 권한이 부여되어야 하며, 모든 승

인된 변경의 기록은 CMDB에 기록되어 진다. 하나의 변경이 실행되면, CMDB는 변경에 의해 영향을

받는 CI의 상태 변경을 보여 주기 위하여 수정되어 져야 한다.

- 142 -


라이센스 제어

구성 관리는 안전한 소프트웨어의 마스터 복사본, 문서, 데이터, 라이센스와 공급, 보증, 유지 보수 협

약에 대한 정보의 구성 관리 시스템 혹은 DSL로의 저장에 대한 검증을 해야한다.

소프트웨어 구매와 관련된 조건과 기간은 조직의 법적 제약하에 놓일 것이다. (e.g. 승인 받지 않은 복

사본이 없도록). 누가 구현을 수행하고 있는지, 누가 소프트웨어 아이템의 복사본을 보유하는지에 대해

CMDB에 업데이트되는 것은 특히 중요하다. 이것은 법적 책임의 이행에 대해 조직에 도움을 줄 것이

며, 감사자와 서비스데스크에 허가 되지 않은 복사본의 존재에 대해 체크데 도움을 준다.

CI의 폐기 시 구성 데이터 보관 및 업데이트

CI의 배치 및 제거의 일정 및 통제는 금융적인 측면과 보안의 이유로 중요하다. 조직의 자산에 대한

올바른 철수를 보장하기 위해 이와 같은 절차는 있어야 하며 관련 기록 (e.g. 라이센스 유지, 공급자에

의해 공급 되어진 데스크탑의 수)은 업데이트 되어진다. CMDB는 업데이트 되어져야 하며, CI의 상태는

‘폐기’ 혹은 ‘보관 중’의 최종 상태로 기록되어져야 한다.

구성 정보 무결성 보호

구성에 대한 무결성을 보호하고 변경의 통제의 근간을 제공하기 위하여, CI의 구성 요소와 관련 문서는

다음과 같은 환경하에 있어야 한다.

! 필요 환경 조건과의 균형 (e.g. 컴퓨터 하드웨어, 소프트웨어, 데이터, 문서 등)

! 승인 받지 않은 변경과 파괴로 부터의 보호

! 재난 복구에 대한 제공

! 소프트웨어의 경우, 데이터, 문서, 통제되었던 마스터의 사본의 통제된 검색에 대한 허가

! 계획된 상태와 구성의 구축된 상태의 정합성 지원

! 최신 바이러스 방지 소프트웨어에 의한 보호

상품의 조달, 저장, 지급, 인수, 폐기 프로세스는 목적지로의 장비, 소프트웨어, 문서의 안전한 전달을

보장하여야 한다. 조장 공간은 안정하여야 한다. 조직에 들어오는 상품의 전달이 완전한지와 기록되었

는지에 대한 문서를 확인하라. 설치와 환경에 대한 확인, 전자적 검사는 네트워크에 연결되기 전에 (구

성 관리에 의해서가 아니라) 적합한 사람에 의해 계획되어 지고 완료되어져야 한다. 접근 통제는 구성

관리 데이터베이스, 물리적 하드웨어, 소프트웨어, 문서에 대한 올바른 접근 허용 수준을 갖는 직원에

게 제공되도록 정의되고 부여되어야 한다.

구성 관리는 다음에 의해 매체나 라이브러리와 관련 없이, 저장된 소프트웨어 CI의 무결성을 보장하여

야 한다.

! 재 발생하는 오류 혹은 품질 저하의 영향을 최소화 할 수 있는 저장소의 선택

! CI의 사용과 refreshing이 빈번히 발생하는 것은 견딜 수 있는 저장소

! 재난 사건으로 인한 손실 위험을 최소화 하기 위하여 통제되는 장소에 중복된 복사본을 저장

- 143 -


CI의 일관된 복제는 이질적인 아이템 (소프트웨어 바이러스 혹은 테스트 데이터와 같은)이 없도록 하기

위하여 중요하다. 소프트웨어와 관련 문서가 복제된 상태와 같은 상태를 유지하기 위하여 적합한 매체

를 사용하는 것은 중요하다. 매체는 저장 내용에 대한 무결성을 서비스 전달의 예상되는 기간을 넘기

는 기간 동안 보장 할 수 있는 것을 선택하여야 한다.

구성 관리는 승인된 절차에 의해 준비되어진 전달 매체를 보장하고 릴리즈 식별의 매체에 라벨을 달아

야 한다. 소프트웨어 분배는 소프트웨어의 조작, 패키징, 전달이 되는 동안 소프트웨어의 무결성이 보

장될 수 있도록 설계되어야 한다. 원격지에 대한 자동화된 소프트웨어 분배는 분배 사이클 시간의 단

축과 자원의 절약을 가져온다. 네트워크를 통한 소프트웨어 분배 이후 분배 도달 시점에 릴리즈의 체

크는 필수적이다.

물리적인 아이템의 존재 확인 이후의 CMDB 업데이트

모든 IT 직원은 승인 되지 않은 CI의 발견, 혹은 CMDB의 정보와 일치하지 않는 CI의 발견 시, 이에

대한 보고를 요청하여야 한다. 그들의 권한 레벨에 따라, IT 직원은 다음과 같이 해야 한다.

! 서비스데스크를 통한 문제 보고

! CI 업데이트

! 잘못 기록된 CI에 마크

! 조사를 위한 사건을 등록

! CMDB를 올바르게 하기 위한 RFC 등록

구성 관리는 등록되지 않은 아이템의 출처를 추적해야 하며 CI의 등록, 정정 혹은 삭제를 위한 초기

행동을 해야 한다. 등록되지 않은 CI (인터넷으로부터의 소프트웨어와 허가되어 지지 않은 컴팩트 디스

크)의 ‘black market’ 이 생기는 지 않게 하기 위하여 세심한 조작이 필요하다.

7.6.4. 구성 상태 기록

상태 보고는 변경 히스토리와 현재의 버전, 통제 하의 모든 CI를 위해, 나열되고, 규칙적인 기준에 의

해 만들어 져야 한다. 현재와 이전의 상태, CI의 계획되어진 상태 기록 보고는 다음을 포함하여야 한다.

! 구성 요소 CI 및 현재 상태의 유일 식별. 예를 들어 ‘개발 중’, ‘테스트 중’, ‘운영 중’

! 구성 기준선

! 최근 소프트웨어 아이템 버전과 시스템 기준선/어플리케이션에 대한 상태

! 상태 변경에 책임이 있는 사람. 예를 들어 ’테스트 중’ 에서 ‘운영’으로의 상태 변경.

! 히스토리 변경/감사 추적

! 문제/RFC 오픈

상태 기록 보고는 시스템 기준선에 의해 확립되곤 하며 기준선과 추적할 수 있는 릴리즈 사이의 변경

을 가능하게 한다. 상태 보고는 다음 내용을 포함한다.

- 144 -


! 기준선과 릴리즈 식별

! 시스템 구축/어플리케이션을 위한 최신 소프트웨어 아이템의 버전

! 시스템의 변경 수

! 기준선과 릴리즈의 수

! CI의 사용과 휘발성

! 기준선과 릴리즈의 비교

7.6.5. 구성 요소 검증 및 감사

중대한 릴리즈와 변경이 있기 전에, 특정 구성에 대한 감사는 고객의 환경을 CMDB와 부합시킬 필요

가 있다. 운영 환경, 새로운 릴리즈, 구축, 장비와 표준의 승인 이전에 특정 요구 사항과 계약에 대해

검증되어 저야 한다. 이는 검증 되어진 신규로, 혹은 업데이트되는 CI, 또는 다른 관련 문서(i.e. RFC)의

기능적 요구 사항에 대한 입증에 대한 테스트가 보증되어져야 한다.

물리적 구성 감사는 구성과 관련 문서가 계획대로 구축되어 졌는지에 대한 확인을 수행 해야 한다.

CMDB의 와 CI의 물리적 상태의 일치에 대한 검사를 위한 심의 기관이 필요하다.

CDMB와 CI의 실제 물리적 상태의 일치에 대한 감사는 주기적으로 시행되도록 계획되어져야 한다. 이

러한 감사는 운영 환경에서 사용되어지는, 실제 존재하는 CI와 같은, 존재하는 CI의 올바르고 승인된

버전에 대한 검증이다. 처음부터 테스트 장비, 개인용 컴퓨터, 그리고 다른 등록되지 않은 아이템들은

공식적인 구성 관리를 통해 등록하거나 삭제 되어야 한다. 등록되지 않고 허가 되지 않은 아이템은 어

떻게든 구성 감사가 진행 되는 동안 조사되어져야 하고 수정 행동으로 가능한 주소가 부여되어 등록되

어 져야 한다. 모든 예외 사항은 기록되고 보고 되어져야 한다.

구성 감사는 변경 관리에 의해 적합하다고 승인되고, 변경의 실행이 승인된 변경과 릴리즈 기록에 대

해 부가적으로 검사를 하여야 한다.

구성 감사는 아래의 시기에 따라 고려되어져야 한다.

! 새로운 구성 관리 시스템이 구축되고 나서 바로

! IT 인프라스트럭쳐에 중대한 변경이 있기 전과 후

! 원하는 환경이 되도록 보장하기 위하여 소프트웨어 릴리즈 혹은 설치 이전에

! 불규칙하게 수시로

! 승인 받지 않은 CI의 발견에 대한 대응으로

! 규칙적으로

자동 감사 도구는 주기적으로 감사를 수행할 수 있도록 해준다. 예를 들어, 데스크탑 감사 도구는 설치

된 마스터 구조와 개별 데스크탑의 구조를 비교한다. 만약, 예외 사항이 발견되면, 원래의 상태로 회기

한다. 구성 감사를 위한 rolling 프로그램은 좀더 효과적으로 자원을 사용할 수 있도록 한다. 서비스데

스크와 지원 그룹은 그와 같은 프로그램의 주의에 대해 체크하도록 교육 받는다. 어떠한 일탈도 조사

를 수행하는 동안 구성 관리에 보고되어져야 한다.

- 145 -


만약 승인 되지 않은 CI의 발견 발생 빈도가 잦다면, 구성 감사의 주기를 증가 시켜야 하며, 이 문제에

의해 영향을 받는 IT 인프라스트럭쳐에 대해 명확히 하여야 한다. 승인 받지 않은 설치로 인해 구성 관

리 팀의 규칙적 혹은 빈번한 감사 및 통제의 실행으로 사기를 저하 시키는 것을 주의한다. 만약, 허가

받지 않은 CI의 만연이 발견된다면, 선택적 혹은 일반적 구성 감사는 문제의 범위에 대한 파악, 문제

사항을 개선하기 위한, 허가 받지 않은 CI의 확산을 막기 위한 작업을 시작하여야 한다. 홍보는 이러한

상황을 감소시키는데 도움이 된다.

7.6.6. CMDB 백업, 기록, 및 관리

CMDB의 백업 복사본은 정기적으로 안전한 저장소로 저장되어야 한다. 재난 등에 대비하여 원격지의

다른 저장소에 백업 복사본을 놓는 것이 권고된다. 백업의 빈도 및 보존 정책은 IT 인프라스트럭쳐와

CMDB의 변화 정도 및 크기에 의존적이다. 어떤 도구는 새로운 혹은 변경된 CI 레코드에 대한 선별적

인 복사가 가능할 것이다.

CMDB는 CI의 백업 복사본 정보를 담고 있으며 또한 CI의 과거 기록 및 보존된 CI의 버전, 그리고 가

능하다면 삭제된 CI에 대한 정보도 담고 있다. 과거 정보의 보존의 정도는 조직을 위해 그 정보가 유

용한지에 따라 정해진다. CI의 과거 정보의 기록 보존 정책은 주기적으로 재검토 되어져야 하고 필요하

다면 변경되어 져야 한다. 만약 CI에 대한 저장 비용이 현재 혹은 잠재적 데이터의 가치보다 크다면,

과거 정보를 저장하지 말아야 한다.

전형적으로, CMDB는 물리적으로 사용 가능한, 혹은 각 절차를 알기 위해 쉽게 만들어 질 수 있는, 그

리고 구성 관리의 통제 하에 있는 아이템에 대한 기록만을 담고 있다. 구성 관리가 일정기간 동안 수

행되어 졌을 때, 중복된 CI의 기록은 시스템 적으로 삭제되어 지도록 하여야 한다.

7.6.7. 구성 관리 서비스 제공

구성 관리는 서비스 관리 조직을 위한 가치를 부가 시킨다.

기능에 권고되어지는 서비스는 다음을 포함한다.

! 규칙적인 정보와 특별한 리포팅 서비스

! 새로운 그룹 또는 기술을 위해 구성 관리의 셋업 권고

! 구성 관리의 정책, 절차, 역할, 및 책임

! 샘플 구성 관리 계획

! 운영 환경의 복잡성과 다양한 구성 항목의 수를 감소시키는 방법을 식별할 수 있도록 도와 주

는 보고서

! 기록의 효과적인 취득, 유지 보수 그리고 삭제

! 아래 항목을 포함한 표준 제품의 정보와 목록 업데이트

- 사용 가능한 출시 이름, 위치, 구축 및 릴리즈 정보를 만드는 것

- 제공된 제품에 대해 책임을 갖는 조직의 식별

- 표준 제품 보관을 위한 시기 및 방법의 명세

- 146 -


! 통제되는 문서와 소프트웨어의 복사본을 관리하기 위한 라이브러리 서비스

! 라이센스 관리

! 구성 감사 서비스

7.7. 프로세스 제어

구성 관리는 정기적인 관리 보고서를 사용하고 있는 구성 관리 시스템의 효과와 효율을 지속적으로 평

가하여야 한다. 구성 관리 활동에 요구되어지는 기대치의 증가에 대한 검토는 정기적으로 일정을 잡아

야 한다. 예를 들어, 매 6개월 마다, 만약 좀더 변덕스러운 조직이라면 검토 주기를 더 빨리 해야 할

것이다.

7.7.1. 관리 보고서

구성 관리 보고서는 아래의 내용을 포함하여야 한다.

! 구성 감사 결과

! 발견되어진 등록되지 않은 CI 나 잘못 등록된 CI의 정보 및 정정 행동

! 정보의 용량과 증가

! CMDB와 DSL의 CI 변경 비율 정보

! 구성 관리 업무의 상세 Backlog 혹은 구성관리 활동에 대한 어떠한 지연, 그리고 제안 되어진

처방

! 구성 관리 직원 위치

! 다른 IT 서비스 직원에 의해 업무 시간에 의해 수행되도록 권한이 주어진 업무의 양

! 효율/효과 검토 결과, 성장 검토, 그리고 구성관리 시스템과 잠재적인 문제와 실제 발생한 문

제에 대한 제안

! 형태에 따른 CI의 개수에 대한 분석 및 데이터 (e.g. 서비스, 서버, 라우터, 허브, 소프트웨어

라이센스, 데스크탑 PC 등)

! CI (혹은 자산) 가치

! 사업 부, 지원 그룹 혹은 서비스 별 CI의 위치

관리 보고서는 모니터링 진행, 문제 관리, 변경 관리, 릴리즈 관리, 구성 감사 및 서비스 계획과 같은

서비스 관리 활동을 지원하기 위해 설계되어져야 한다. 보고서는 IT 서비스 관리에 대한 경향 분석 및

심의에 사용되어 진다.

일반적으로 IT 서비스 관리는 이 관리 보고서에 근거하여 계획했었던 구성 관리 작업 부하와 성장을

고려하여 구성 관리를 위한 장래 계획을 세워야 한다.

7.7.2. 핵심 성과 지표 (KPI)

목표 Metric을 위한 측정 가능한 대상은 구성 관리 프로세스의 효율을 위하여 설정 되어야 한다. 아래

Metric에 대해 고려하여 실행 가능한 시간의 범위에 개선을 해야 할 대상을 설정한다.

- 147 -


! ‘구성’ 이 승인되지 않은 경우

! 잘못된 변경을 하게한 사건과 문제에 대한 역 추적

! 잘못된 영향 분석 및 CMDB의 잘못된 데이터, 혹은 잘못된 버전 통제로 인해 성공적으로 완

료되지 못한 RFC

! 변경이 승인되고 실행되기까지의 소요 시간

! 낭비 되어진 라이센스 또는 특정 장소에 사용되어 지도록 투입되지 않은 라이센스

! 구성 감사 동안 보고되어진 예외 사항

! 승인되지 않은 IT 구성 요소의 사용 발견

다른 지표와 대상은 다음과 같다.

! 사용자가 서비스데스크에 전화를 하였을 때 추가 에스컬레이션이 없이 바로 해결이 된 비율의

변화

! 사건과 문제의 중대함과 건수의 변화

! 즉시 해결되지 않은 서비스데스크 요청의 진단 및 문제 해결에 소요된 평균 시간과 비용의 변

화

! 서비스 수준 협약이 위배되어진 경우의 심각성과 건수의 변화

! 매 달 CMDB의 잘못된 식별로 인해 CMDB가 변경되어진 횟수

7.8. 다른 프로세스와의 관계

구성 관리는 많은 다른 통제에 의존적이다. 효과적인 변경 관리, 소프트웨어 통제, 릴리즈 관리, 운영

가능에 대한 승인 테스트, 그리고 신규/다른 네트워크 구성 요소와 하드웨어의 승인 및 설치 절차는 모

두 필수적이다. 만약 이미 존재하지 않다면, 구성 관리에 따라 계획되어져야 한다.

- 148 -


그림 7.8 – 사건, 문제, 릴리즈 관리와 CMDB의 인터페이스

효과적인 문제 관리 절차는 구성 관리로부터 많은 이익을 획득하느냐에 따라 달라진다. 만약 존재하는

문제 관리 절차가 없다면, 가능한 빨리 이와 같은 업무 절차에 대해 고려되어져야 한다. 구성 관리는

사건 관리, 문제 관리, 변경 관리, 릴리즈 관리와 같은 다른 많은 서비스 지원 프로세스의 근간이 된다.

그림 7.8과 7.9는 그 관계에 대해 나타낸다.

- 149 -


그림 7.9 – 구성, 변경 릴리즈 관리 간의 관계

8장, 변경 관리에서는 IT 인프라스트럭쳐 변경의 승인 및 실행에 대한 절차에 대해 설명한다. 이상적인

변경 관리는 구성 관리 시스템의 통합된 한 부분으로 간주되는 것이다. 그러나, 일반적인 설치는 구전

체적인 구성 관리의 채택 없이 변경 관리를 수행하므로, 별도로 다루어 진다.

구성 관리는 사건과 문제의 효과적인 제어를 위한 공헌을 한다. 5장과 6장에서 상세한 내용을 참조한다.

릴리즈 관리는 구성 관리의 일부분으로 간주 되어질 수 있다. 이는 릴리즈의 구축, 분배, 실행에 적용

된다. 이번 장에서는 IT 인프라스트럭쳐의 논리적 모델의 업데이트와 소프트웨어, 하드웨어 그리고 문

- 150 -


서의 통제를 위해 필요한 절차에 대해 다룬다. 논리적 모델은 구축, 릴리즈, 분배, 실행 및 릴리즈의 유

지 보수의 상세 기록 및 통제를 위해 사용되어 진다. 추가 정보는 릴리즈 관리에 관한 9장을 참조한다.

개발 환경과 운영 환경 양측에 대한 구성 요소 통제를 위해 단일 구성 관리 시스템이 사용 되어지기를

권고한다. 만약 다중 플랫폼이라면, 운영 구성 관리 시스템은 ‘마스터’로 명시되어 지며 개발 및

별도의 테스팅 환경의 내 외부 구성 요소의 이동 통제를 위한 시스템은 링크 되어 진다.

구성 관리와 조직의 관리, 금융, 구매 기능과는 밀접한 관계가 있다. 그것들이 하드웨어, 소프트웨어,

문서, 혹은 기타 어떤 것이든지 아니든 CI는 조직의 자산이다. 구성 관리는 재무에 자산의 조건 및 위

치의 어떠한 변경에 대해서도 인지되도록 할 책임이 있다.

7.9. 구성 관리 프로세스를 위한 도구

7.9.1. 구성 관리 시스템

많은 조직은 운영에 있어 어떠한 형태로든 구성 관리를 하고 있다. 그러나 대부분이 종이에 근간을 두

고 있다. 거대하고 복잡한 인프라스트럭쳐를 위한 구성 관리는 CMDB를 유지 관리 할 수 잇는 소프트

웨어 도구에 의해 지원되어 질 때 보다 효과적으로 운영될 수 있다. CMDB는 각각의 CI에 대한 과거

기록 및 속성, 그리고 CI간의 관계에 대하 상세 정보를 담고 있다. 이상적인 CMDB는 DSL 및 다른 소

프트웨어 라이브러리와 링크가 되어져 있는 것이다. 때때로 어떤 도구들은 플랫폼에 걸쳐 전부 자동화

된 솔루션을 제공하기 위한 통합이 필요하다.

구성 관리 시스템은 변경 관리를 통한 유효한 권한 없이 IT 인프라스트럭쳐를 구성하는 것들에 대한

변경 행위를 방지하여야 한다. 승인된 기록은 자동으로 변경으로 유도 된다. 가능한 한 모든 변경은 최

소한 변경이 실행되어 질 때 CMDB에 기록되어져야 한다. 변경에 의해 영향을 받는 각각의 CI의 상태

(e.g. ‘운영 중’, ‘보관 중’ 등 등)는 가능하다면 자동으로 업데이트 되어야 한다. 변경에 대한 자동화된

기록의 예는 소프트웨어가 라이브러리 간에 (e.g. ‘ 승인 테스트’에서 ‘운영’, 혹은 ‘운영’에서 ‘보관 중’

라이브러리로의 ) 이동되어 질 때, 서비스 카탈로그가 변경 되었을 때, 그리고 릴리즈가 분배되었을 때

CMDB가 자동으로 업데이트 되는 기능을 수행하는 것이다.

구성 관리 시스템은 부가적으로 다음의 기능을 제공해야 한다.

! need-to-know 에 근거한 접근 제한을 위한 충분한 보안 통제

! 대단히 복잡한 CI의 지원. E.g. 전체 시스템, 릴리즈, 단일 하드웨어 아이템, 소프트웨어 모듈,

혹은 CI간의 계층적이고 서로 얽힌 관계에 대해, 구성 관리 도구는 RFC의 영향 측정을 지원

해야 한다.

! CI의 추가와 삭제의 용이성

! 입력 데이터의 자동화된 유효성 검증 (e.g. 입력 CI 명이 유일한지에 대한 검증)

! 새로운 CI가 추가되었을 때 자동으로 수립되어 질 수 있는 모든 관계에 대한 자동화된 수립

- 151 -


! 다른 모델 넘버, 버전 넘버, 카피 넘버의 CI 지원

! 어떤 CI가 사건 보고/기록, 문제 기록, 알려진 오류 기록 혹은 RFC의 원인이 될 때 영향을 받

는 CI에 대한 자동 식별

! CMDB로의 문제 관리 데이터 통합, 혹은 적어도 구성 관리 시스템으로부터 분리되어 있는 문

제 관리 데이터베이스로의 인터페이스가 존재

! 만약 어떠한 구성 요소 CI가 변경되었을 때, CI의 버전 넘버의 자동화된 기록과 업데이트

! 모든 CI의 과거 기록에 대한 유지 보수 (현재 버전의 과거 기록 – 설치 일시, 변경 기록, 이전

위치 등 과 같은- 그리고 이전 버전)

! 신뢰할 수 있는 버전으로의 리버전을 위한 지원을 포함하여 구성 관리의 사용 및 관리 지원

! CMDB의 질의의 용이성 및 경향 분석을 포함한 좋은 리포팅 기능 (e.g. 특정 CI에 영향을 끼

치는 RFC의 개수의 식별 능력 등)

! CI 인벤토리의 용이한 리포팅 기능

! 영향 분석을 용이하게 하기 위한 유연한 리포팅 도구

! CI에 연결되어 있는 네트워크 지도 혹은 구성간의 관계에 대해 도식화하여 보여 줄 수 있는

능력 및 그와 같은 지도를 통하여 신규 CI에 대한 정보를 입력할 수 있는 기능

! 부모 CI와 자식 CI 간의 관계를 계층적으로 보여 줄 수 있는 기능

7.9.2. 소프트웨어 구성 관리

지원 도구는 유지 보수를 위해 시스템 분석 시작 시점과 운영을 통한 올바른 설계에 대해 통제가 허용

되어야 한다. 이상적으로는 조직은 라이프 사이클의 모든 간계에 대한 통제가 같은 도구를 통해 이루

어져야 한다는 것이다. 만약, 모든 플랫폼이 하나의 소프트웨어 도구에 의해 지원되지 못한다면, 이는

불가능할지라도. 만약 이것이 불가능 하다면, IT 인프라스트럭쳐의 구성 관리 도구는 적어도 재입력 없

이 소프트웨어 개발 구성 관리 시스템으로부터 CMDB로의 구성 관리 정보의 이동이 가능하여야 한다.

7.9.3. 변경 관리 및 릴리즈 관리 지원

변경, 릴리즈 관리를 지원하기 위하여, 구성 관리 도구는 다음과 같은 사항에 대해 자동화된 지원이 제

공되어야 한다.

! 영향 분석을 보조하기 위해, 제안되어진 변경에 의해 영향을 관련 CI의 식별

! 승인된 변경에 의해 영향을 받는 CI의 기록

! 승인된 기록과 일치되는 패키지 릴리즈를 포함하여 변경의 실행

! 승인된 변경과 릴리즈의 실행 시의 CI 상태 변경 등록

! 알려진 결과로 복귀하기 위한 CI와 CI 패키지의 기준선 기록 – 예를 들어 실행되었던 변경이

실패되어질 경우

7.9.4. 구성 감사

자동화된 구성 감사는 감사의 효율성과 효과를 대단히 증가 시킨다. 감사 도구는 하드웨어 설정의 가

장 민감한 부분의 식별과 설치된 소프트웨어에 대해 정확하게 한정할 수 있다. 이것은 자원의 가용성

- 152 -


으로 CI의 감사 범위를 증가 시킬 수 있고 직원이 감사를 수행하기 보다는 예외 사항에 대해서 처리하

는 데 초점이 맞추어 질 수 있다는 것을 의미한다.

만약 DSL이 CMDB와 통합되지 않는 다면 CMDB와 DSL의 내용의 비교 자동화가 가치가 있을 것이다.

7.9.5. 엔터프라이즈 시스템 및 도구

다음과 같은 시스템은 IT 인프라스트럭쳐를 지원 하기 위해 필요한 변경 관리, 구성 관리, 릴리즈 관리

의 몇 개의 요소를 위한 자동화된 지원을 제공한다.

! IT 서비스 관리 시스템

! CMDB 혹은 도구와의 링크를 위한 통합 기능 제공의 엔터프라이즈 Framework

! 소프트웨어 분배, 발견, 그리고 감사 기능을 가지는 시스템, 네트워크, 어플리케이션 관리 도구

! 개발, 통합 혹은 테스트 팀에 의해 사용되어 지는 구성 관리 시스템

조직 내에 존재하는 혹은 계획된 시스템은 요구 사항 정의 기간 동안 분석되어져야 하며 구조 설계 기

간 동안 고려 되어 져야 한다. 이것은 구성 관리 프로세스의 핵심을 제공하거나 특정 부분을 위한 해

결책이 될 것이다. 이 예제에 대한 인용은 다음과 같다.

! 서비스 관리 도구는 서비스와 CI의 사건 관리, 문제 관리, 변경 관리의 통합을 위한 CI를 제대

로 연결 시킨다.

! 시스템과 네트워크 관리 도구는 CMDB로의 데이터 구축 및 다음 단계의 감사를 돕기 위한 구

성 요소 발견 도구를 제공할 것이다.

! 현재 통제되는 소프트웨어의 구성 관리 시스템은 통제되는 하드웨어와 문서에 의해 사용되어

질 것이다.

7.9.6. 다른 도구

변경 관리, 구성 관리, 릴리즈 관리를 지원하기 위한 많은 지원 도구가 있다. 이것들은 다양한 조합의

형태를 나타낸다.

! 문서 관리 시스템

! 비즈니스 측면에서의 영향 분석을 수월하게 하는 시스템 구조 및 CASE 도구 및 요구 분석,

설계 도구

! 물리적 데이터베이스를 추적하기 위한 데이터베이스 관리 감사 도구

! 분배 및 설치 도구

! 비교 도구 (소프트웨어 파일, 디렉토리, 데이터베이스)

! 구축 및 릴리즈 도구 (입력 및 출력 CI의 목록을 제공하는)

! 압축 도구 (저장 공간을 저장하기 위한)

! 목록 및 구성 기준선 도구 (e.g.날짜-시간 스탬프 및 check sum으로 전체 디렉토리 목록 대해)

! 감사 도구 (이는 또한 발견 혹은 인벤토리 도구라고도 한다)

! 감지 및 발견 도구

! 리포팅 도구

- 153 -


이 개별 도구와 솔루션들은 구성 관리 시스템 혹은 메인 서비스와 통합되어 진다. 다른 경우에는, 통합

은 절차와 데이터 수준의 통합이 될 수도 있다.

7.10. 신기술에 의한 영향

인터넷 기술은 소프트웨어와 문서의 통제와 접근에 방식을 변화시켰다. 예를 들면, 조직은 인터넷을 통

한 문서 혹은 소프트웨어 패키지의 최종 버전을 검색하는 정책을 취할 수 있다.

구성 관리에 대한 새로운 기술에 의한 영향은 다음과 같은 것들이다.

! 서비스 관리, 네트워크, 기업 및 시스템 관리 도구의 성장

! 시스템 및 네트워크 관리 도구를 위한 인터페이스

! 서비스 관리 도구 범위로 들어온 소프트웨어 구성 관리

! drill down의 사실적 표현

! 여러 데이터베이스, 여러 시스템(CMDB, DSL 및 서비스 관리 도구)에 걸친 통합 리포팅을 제

공하는 리포팅 도구

! 발견, 수집, 감사 도구의 연결

7.11. 구성 관리 가이드

특히 세가지 관점에서의 구성 관리 측면에서 가이드를 제시한다.

7.11.1. 제어 수준

많은 조직들이 최 상위 수준의 CI를 정의하는 것부터 시작한다. 그러나 민감한 서비스와 그 구성 요소

의 식별은 구성 관리의 시작 시점에서 유용하다. 어떤 아이템은 특정 시점에 더 민감할 수 있다. 민감

하고 높은 위험 요소를 지니는 CI는 다음과 같다.

! 민감한 전원 공급 장치, 서버 및 기계실

! 주요 사이트의 통신 기기 및 라우터

! 운영 중인 소프트웨어, 컴퓨터 및 접속

! 조직을 위한 규제의 준수에 영향을 받는 아이템

! 보안을 요하는 영역과 시스템을 위한 연결

! EDI와 데이터베이스 공급

! 거래 파트너, 공급자, 고객 및 비즈니스 파트너를 위한 외부 인터페이스

! 고객 시스템의 분기를 위한 인터페이스

! 초기에 추적할 필요가 있는 신 기술 아이템

어떤 조직은 너무 상세하게 관리한다. 그들은 구조의 일부분에 대해 낮은 수준의 상세 목록을 가지기

때문에 모든 다른 구성에서도 이럴 필요가 있다고 생각한다. 비록 이것이 일관성과 이해에 도움을 줄

진 모르지만, 이는 모든 데이터를 관리하는데 충분하지 못한 자원으로 인해 구성 정보에 대한 통제가

힘든 결과를 초래한다. 다시 계획을 세우기 위한 과제는 적당한 통제 수준으로의 회기가 필요할 것이

- 154 -


다. 다른 아이디어는 중복된 아이템 혹은 오래된 세트를 제거하기위해 구성 정보를 정화시키는 것이다.

목표는 최소의 기록을 갖고 최대의 통제를 하는 것이다.

7.11.2. 버전 및 변형?

비록 같은 CI가 IT 인프라스트럭쳐의 하나의 지역 이상에 있을 수 없지만, 같은 CI에 대해 약간 다른

버전을 사용하여 그렇게 하는 것은 가능하다. 이 약간의 다른 버전은 다른 버전 번호를 가질 것이다.

그리고 이와 같은 CI는 ‘변형’이라고 불린다.

변형이 유용할 수 있도록 올바르게 평가하기 위해서는, 초기에 버전 1.1이 사용되어진 A와 B라는 라벨

이 부여된 두 개의 디스크를 갖는 컴퓨터에 대한 고려가 유용하다. 만약 B가 용량과 데이터 전송 속도

를 증설하기 위하여 수정되어 진다면, 이는 버전 1.1.1이 될 것이다. 드라이브 A는 과거의 적합성을 유

지하기 위하여 수정이 되지 않는다. 만약 설계 오류가 A에서 발견된다면 이는 정정된다 (A의 버전은

1.2가 된다) 이 변경은 B에 전달되어져야 한다. (버전 1.2.1을 부여 받기 위해). A와 B는 관계 없는 CI로,

다르게 간주 되어질 것이다. 그러나 많은 공통된 구성 요소를 공유하기 때문에 다른 변형에 대해 하나

로 간주되는 것이 유리할 수 도 있다. 다른 그리고 매우 일반적인 변형의 예는 특정 어플리케이션을

위하여 커스터마이즈 된 표준 시스템이다.

7.11.3. 구성 관리 도구의 선택

많은 소프트웨어 공급자는 자산 관리 혹은 구성 관리 기능을 포함하는 제품을 제공한다. 존재하고 제

안되어진 서비스와 구성관리 도구의 기능에 대한 이해는 기능의 중복 및 Gap을 피하기 위하여 중요하

다. 예를 들면, 어떤 지원도구는 단지 CI의 두 개의 수준 만을 지원하며 이는 매우 제한 적일 수 있다

는 것이다.

조직이 소프트웨어에 더 의존함에 따라, 소프트웨어의 모든 형태를 통제하고 관리하는 능력은 점점 중

요시 되고 있다. 소프트웨어 구성 관리 도구가 조직의 모든 플랫폼을 지원할 수 있는지 등에 대해 고

려하여 구성 관리 도구의 선택에 주의를 기울여라. 자동화된 소프트웨어 파일의 통제 능력은 시간을

절약해 주고 오류를 감소 시킨다. 식별자에 대한 길이는 종종 다른 구조 부분과 중복된 파일명이 될

수 있으므로 소프트웨어에 대해 매우 중요한 문제이다.

부록 7A: 변경, 구성, 릴리즈 관리를 위한 Central Function 변경, 구성, 릴리즈의 Central function은 보다 효율적이고 효과적으로 서비스 관리 구현을 가능하게 한

다. Central function은 현재 운영중인 시스템의 운영, 지원, 유지보수와 관련된 문서의 모든 아이템과 하

드웨어, 소프트웨어의 변경을 관리하는 책임을 갖고 있다.

! 변경, 구성, 릴리즈 관리의 Central function 주요 책무는

! 변경, 구성 관리 계획, 구성 관리 설계, 조직의 릴리즈 정책의 작성 및 유지

! 관리되고 통제될 필요가 있는 모든 CI의 식별

- 155 -


! 다른 서비스 관리자, 프로젝트, 공급자, 고객간의 인터페이스를 위한 Central function 통합

! CMDB와 DSL에 승인되어진 IT 인프라스트럭쳐와 서비스의 반영을 보장

! 하드웨어의 표준, 기술 표준, 문서의 마스터 복사본의 제어 및 유지

! 업체로부터 공급되어진 릴리즈의 등록 및 검사를 포함하여, 지원 서비스 제공

! CI 관리 정보와 보고서 배부 (e.g. CI에 영향을 끼치는 문제와 오류의 범위, 그리고 폐기 일,

라이센스 비용 갱신일자와 비용 등)

! 구성 관리 시스템의 향후 성장과 업무 부하에 대한 인식할 수 있는 정보를 제공 (e.g 구성 관

리를 운영하는데 필요한 적정 인원 및 자원 등)

! 모든 직원이 구성 관리, 변경 관리, 소프트웨어 분배 정책, 프로세스, 시스템을 운영하는데 친

숙할 수 있어야 함

! 다른 서비스 관리 프로세스의 지원을 위한 필요 상태 기록 정의

! CMDB와 DSL의 정기적인 검사; 구성 감사와 프로세스 감사 배치; 정상적인 행동의 정착 및

예외 사항 모니터링

! 다양한 구성과 인프라스트럭쳐의 복잡성을 어떻게 통제할 것인지를 포함하여, 전략, 정책 및

시스템 설계 권고안 마련

! 잘못된 통제로 인해 발생하는 주요 문제 사항에 대한 조사 및 교정 행동 확인

! 인프라스트럭쳐 표준안 권고 및 안내 제공

! 성공적인 최종 서비스 제공을 보장하기 위해 구성 관리와 릴리즈 계획에 대한 프로젝트 권고

및 커뮤니케이션

변경, 구성, 릴리즈 관리 기능 셋업 적절한 기능의 셋업을 위한 계획 프로세스는 초기 구현 단계의 시작 시점으로부터 3개월에서 6개월 사

이에 세워진다. 이 단계는 만약 자금이 마련되지 않고 조달 기간이 길어 진다면 더 늘어 날 것이다.

경험상 직원들이 그들이 맡는 업무에 대해 효과적으로 완전하게 훈련이 되는 데는 적요도 한 달의 시

간이 필요하다. 직원이 적절한 훈련이 되기 전까지는 지원 프로세스는 실행되어서는 안된다. 만약 직원

이 통제 활동을 너무 성급히 실행하려 한다면, 병목 현상에 의해 조직의 다른 파트의 협력을 잃게 될

것이다.

Central function의 계획 및 구현에는 다음의 몇 개의 형태를 포함한다.

초기 평가

이 제어 프로세스는 문제 관리와 서비스데스크와 같은 다른 많은 프로세스의 근간이 된다. 이익에 대

한 평가를 위하여 프로세스의 발표 전 후에 서비스 관리와 지원에 대한 초기 평가의 실행이 계획된다.

Central Function 계획

상위 관리로 부터의 위임은 central function의 초기화를 위하여 필요하다. 권고되는 접근은 단일 기능에

의한 변경 관리와 구성관리, 그리고 어떤 측면에서의 릴리즈 관리의 통합이다. Central function은 구성

관리로의 CI 수용을 위한 절차의 접근 및 진행을 포함한다.

- 156 -


중간과 거대 조직은 적당한 제어 수준을 제공하기 위한 전담 자원이 필요하다. 거대 조직은 중앙의 구

성 관리자로의 간접적 보고 라인을 가지는 지역 구성 관리자가 있어야 할 것이다. 예를 들면, 현장 구

성 관리자, 혹은 주요 인프라스트럭쳐 프로그램을 위한 소프트웨어 구성 관리자 등.

Central Function을 위한 변경, 구성 관리 계획 작성

구성 관리 방법론은 아래 내용을 포함 하는 변경과 구성 관리 계획 (C&CM Plan)을 정의하여야 한다.

! 구성 관리 조직의 역할과 책임

! CMDB, DSL, 구성 관리 도구 및 라이브러리의 설계와 구축

! 변경 관리, 구성 관리, 릴리즈 관리의 정책과 절차

인터페이스 사이의 통제 프로세스는 프로젝트, 공급자, 어플리케이션 팀, 그리고 지원 팀 사이의 인터

페이스에 대해 포함하여야 한다. 프로젝트와 외부 공급자는 IT 서비스 조직을 위한 범위와 구성, 절차

와 인터페이스에 대한 정의의 구성 관리 계획을 가져야 한다.

C&CM Plan (Change & 구성 관리 Plan) 은 통제를 하기 위한 인프라스트럭쳐의 범위에 기술하고 어떻

게 프로세스를 합의된 목표를 달성하기 위하여 실행할 것인지에 대해 기술한다. 계획은 주기적으로 업

데이트 되어야 한다. 이는 현재의 범위와 목표, 프로세스를 반영하기 위함이며, 다음 6개월에서 12개월

까지의 목표를 포함하기 위함이다.

이는 다음과 같은 내용을 포함하여야 한다.

! 통제 되어지는지 서비스와 플랫폼을 포함한 구성 관리의 목표와 범위, 그리고 최 상위 수준의

CI와 그들 간의 관계에 대한 도식 혹은 리스트와 같은 정보, 그리고 자산과 CI를 통제 하에

두는 일정

! 전반적인 구성 관리, 변경 관리, 그리고 릴리즈 관리의 정책

! 관련 정책, 표준 및 프로세스

! 구성 관리를 위한 조직의 책임 및 Central Function 에서의 그들간의 인터페이스(e.g. 기업 내

팀, 시스템 통합자, 하도급 계약과 공급자 간)

! 관련 구성 관리 시스템, 범위, 핵심 인터페이스 –시스템은 라이브러리와 저장소의 혼합으로 구

성되어질 것이고 CMDB와 DSL, 소프트웨어와 라이브러리에서 통제되는 문서의 위치를 포함하

여야 한다.

! CI가 다루어지게 되는 통제 환경

! 다른 서비스 관리 시스템을 위한 링크와 인터페이스

! 각 플랫폼에서 사용되어지기 위한 도구

! 구성 관리 활동을 수행하기 위한 일정 및 절차

- 구성 요소 식별

- 통제

- 상태 기록

- 구성 감사

- 검증

- 157 -


! 라이센스 관리

! 통제 프로세스를 개선 시키기 위한 목표 대상 (효율적이고 효과적으로)

! CI의 보유 기간

역할

기능 내에서의 역할은 구성 관리자, 자산 관리자, 변경 관리자, 릴리즈 관리자, 그리고 변경 자문 위원

회(CAB : Change Advisory Boards) 와 관련된 역할을 포함해야 한다. 변경 자문 위원회로의 에스컬레이

션 메커니즘과 구조 등에 대해서 협의되어져야 한다. 구성 관리자는 변경 자문 위원회의 일원이어야

한다.

계획 지원 도구

Central function은 사용 가능한 지원 도구에 대해 평가하여야 하며 선택된 지원 도구와 지원 도구의 운

영을 위한 하드웨어의 도입을 추진하여야 한다. 이것은 지원 도구의 특성 상 Central function에 대단히

큰 영향을 미치므로 매우 중요한 절차이다.

요원 조직 및 훈련 계획

구성 관리는 부지런하고 세심한 주의력을 갖고 있는 직원을 필요로 한다.

다음과 같은 요소들을 고려하여 구성 관리를 위한 직원의 수를 산정한다.

! 구성 관리 팀에 IT 인프라스트럭쳐와 서비스 뿐 아니라 프로젝트에 대한 책임도 할당 되는지

! 구성 관리에 다른 책임이 할당되는지 아닌지

! 그룹이 변경, 구성, 릴리즈 관리팀의 의무도 수행해야 하는지 아닌지

! IT 인프라스트럭쳐의 규모와 관리하여야 하는 CI의 수 및 CI 레벨

! 다른 그룹과 프로젝트의 활동 제한을 수행하여야 하는 직원의 수

! 지원 도구가 어느 정도 지원을 해 주는지

! 변경과 릴리즈의 규모와 발생 빈도, 복잡성

! 변경 자문 위원회의 인원 수, 미팅의 빈도수와 참석 여부

변경 관리, 구성 관리 및 릴리즈 관리는 프로젝트, 어플리케션 개발 및 실 운영의 민감한 경로에 일반

적으로 존재한다. Central function은 운영중인 하드웨어, 소프트웨어 및 네트워크의 모든 변경 사항을

포함할 것이다. 구성 관리 직원은 직원의 이직 및 부재에 대비해 충분한 인원에 대한 훈련 계획을 세

운다. 최소의 유용한 직원의 수는 두 명이다. – 구성 관리자를 포함하여 – 아무리 작은 조직에서라도

이 두 명이라는 인원수는 보장되어야 한다.

만약 변경 관리, 구성 관리 및 릴리즈 관리 행동이 다른 그룹에 의해 이미 수행되고 있다면, 새로운 직

원을 훈련시키는 동안만이라도 이 그룹으로부터 Central function으로의 직원 인사 이동을 시도한다.

어디에도 준비된 직원이 없다면, 적당한 직원이 채용되거나 훈련되어 질 때 까지 기본적인 통제 활동

을 수행하기 위하여 계약직 직원이나 컨설턴트의 도움을 받도록 한다.

- 158 -


CI에 대한 승인, 설치 혹은 변경에 대해 넘겨 받은 모든 직원은 변경 관리/구성 관리의 권한이 주어져

야 하고 CMDB와 DSL은 새로운 CI 또는 변경의 명세가 업데이트 되어 져야 한다.

초과 시간 및 업무 이동에 대해 고려하여라. 시급한 릴리즈 혹은 긴급한 장애 복구가 필요할 때에도,

변경은 언제나 구성 관리의 통제를 받아야 하며, 언제나 CMDB에 기록되어야 한다. 여기에 3개의 옵션

이 있다.

! 24시간 직원을 대기 시킨다.

! 전화 응대가 가능한 직원을 만든다.

! 이용 가능한 누군가에게 권한을 할당한다. (e.g. 문제 관리, 혹은 컴퓨터 운영 직원) – 적합한

절차와 훈련은 대상 직원을 위해 필요 할 것 이다 – 그러나 업체나 사용자는 안된다.

직원은 일반적인 훈련 코스 및 현장 실습 교육으로 구성된 학습 프로그램이 주어져야 한다. 구성 관리

원칙과 모든 지원 도구의 사용법 교육은 일반적인 훈련 이다. 직원은 그들의 통제하에 있을 통신 설정,

하드웨어, 소프트웨어, 네트워크에 대한 일반적인 이해에 대해 교육되어져야 한다. 훈련은 적당한 다른

책임도 주어진다. 이는 직원에게 문제 관리, 서비스데스크 시스템, 그리고 이러한 운영이 구성 관리를

어떻게 보조하는지에 대한 이해를 준다.

지원 도구가 설치되고, 사용 가능해 지자마자, 그것을 사용하도록 훈련되어진 직원은 곧 바로 업무 수

행을 하여야 한다. 이는 도구의 테스팅과 훈련을 병행해서 지원할 수도 있다. 새로운 직원에 대한 훈련

은 계획되어야만 하는 것이다.

부록 7B : 구성 관리 팀의 책임 구성 관리 매니저의 책임

구성 관리 매니저는

1. IT 서비스 관리자의 협의를 통해 총체적인 목표를 위해 일을 한다.; 조직의 구성 관리 정책과

표준화를 실행 한다.

2. 기존의 구성 관리 시스템을 평가하고, 효율적이고 효과적인 신규 시스템, 혹은 시스템의 개선

을 설계하고 구축, 관리한다. – 평가 및 업무 계획 및 자원 계획, 그리고 계획 대비 업무 진행

사항에 대한 모니터링 및 보고를 포함하여.

3. 관리할, 그리고 정보를 기록할 구성 관리 아이템, 구성 관리 프로세스, 기능에 대한 제안 및 범

위 협의. 구성 관리 계획, 업무 절차, 표준화 개발

4. 새로운 구성 관리 절차의 확립을 지원하기 위한 캠페인 활동. 구성 관리 방법과 프로세스의 변

경에 대한 보장으로 실 적용되기 전에 직원과 의사 소통을 하고 적절한 승인을 받도록 한다.새

로운 구성 관리 시스템의 구축을 계획하고 공표하며 감독한다.

5. 직원의 채용과 훈련을 준비한다. 구성 관리 전문가와 다른 직원에 구성 관리 원칙, 프로세스,

업무 절차에 대해 훈련 시킨다.

- 159 -


6. 소유한 구성 관리 도구에 대해 평가하고 조직의 예산, 자원, 타임 스케일과 기술적 요구 사항

에 가장 적합한 것을 추천한다. 데이터베이스, 소프트웨어 저장소, 워크플로우와 보고서 생성등

에 관하여 효과적인 구성 관리 환경을 만들기 위한 직/간접적인 구성 관리 도구의 커스터마이

징을 한다.

7. 구성 관리 계획을 만들고 관리한다. 이는 CI의 등록 절차를 포함한다. ; 액세스 통제와 권한 통

제. 정확한 역할과 책임이 구성 관리 계획과 절차를 통해 정의되도록 한다.

8. CI가 명명 규칙을 통해 유일하게 구분되도록 제안하고 협의한다. 직원이 목적의 형태, 환경, 프

로세스, 라이프 사이클, 문서, 버전, 포맷, 기준선, 릴리즈와 템플릿을 위한 식별 표준을 따르도

록 한다.

9. 변경 관리, 문제 관리, 네트워크 관리, 릴리즈 관리 , 컴퓨터 운영, 재무와 관리 기능과의 인터

페이스를 제안 혹은 협의한다.

10. CMDB의 데이터 구성을 계획하고 실행한다. CMDB, 중앙 라이브러리, 도구, 공통 코드, 그리고

데이터를 관리하고 유지 보수한다. CMDB의 주기적 보관을 확실히 한다.

11. 관리 보고서, 영향 분석 보고서, 구성 상태 보고서등을 제공한다.

12. RFC를 위한 영향 측정을 용이하게 하고 정식으로 인가된 변경에 대한 보증을 위해 CMDB를

사용하거나 제공한다. 승인된 CI에 의해 영향을 받는 특정 CI를 위해 변경 기록, 구성 기준선,

그리고 패키지 릴리즈 기록을 생성한다. 변경이 실행 될 때마다 CMDB가 업데이트되도록 보장

한다.

13. CI에 영향을 끼치고 있는 오류에 의해 영향을 받는 다른 CI를 식별하기 위해 CMDB를 제공한

다.

14. 물리적 IT 인벤토리가 CMDB와 일치하는지에 대한 감사 활동을 수행하고 오류를 수정하기 위

해 필요한 행동을 시작한다.

15. 규정 절차를 제대로 구성 관리 팀이 수행하는지에 대해 감사하기 위한 보조 감사자. 올바른 행

동이 수행되고 있는가를 보장한다.

구성 라이브러리 관리자(오퍼레이터)의 책임

구성 라이브러리 관리자는 모든 소프트웨어와 구성 관리에 등록되어진 CI의 마스터 복사본의 관리자이

자 보호자이다. 이 역할의 주요 직무는 다음과 같다.

! 지원되는 모든 CI의 수집, 식별, 저장 및 폐기의 통제

! CI의 상태에 대한 정보 제공

! 구성 관리 이슈에 대해 번호를 부여하고, 기록하고, 저장하고 분배

특정한 책임은 다음과 같다.

! 구성 관리 계획을 준비하기 위한 구성 관리 보조

! 구성 관리 라이브러리와 DSL 구조의 식별 생성

! CI를 저장하기 위한 라이브러리 혹은 다른 저장소 생성

! CI의 현재 상태 정보 유지 관리

- 160 -


! 적합한 라이브러리로의 신규 혹은 변경된 구성의 수용 및 인수 기록

! 파기된 복사본의 저장

! 마스터 복사본의 획득

! 검토, 변경, 정정 혹은 정보 제공을 위한 제품의 문제본 복사

! 모든 복사본의 문제사항 기록의 유지 관리

! 복사본의 모든 변경 사항에 대해 통지

! 어떤 CI가 제품의 변경에 의해 영향을 받는지에 대한 측정 보조를 위한 정보의 수집 및 유지

! 구성 상태 기록 보고서 작성

! 구성 감사 작업의 보조

부록 7C : CI 속성 예제 아래의 속성은 CMDB에서 사용되어지는 CI의 속성 예제이다. 하드웨어의 CI 형태는 소프트웨어 CI 형

태와 다른 속성을 갖는다는 것에 주의한다.

속성 설명

CI 이름 CI 형태에 따른 유일한 이름

시리얼 넘버 CI를 유일하게 식별해 주는 넘버 – 예를 들어, 소프트웨어의 카피

넘버, 하드웨어의 시리얼 넘버

범주 CI의 분류 (e.g. 하드웨어, 소프트웨어, 문서 등)

형태 CI 형태에 대한 설명. 범주 정보의 확장 (e.g. 하드웨어 구성, 소프

트웨어 패키지, 하드웨어 장비 혹은 프로그램 모듈)

모델 넘버(하드웨어) CI의 모델 (예를 들어 공급자 모델 넘버. .e.g. Dell model xxx, PC/aa

model yyy)

보증 기간 만료 기간 CI에 대한 공급자의 보증 기간 만료 기간

버전 넘버 CI의 버전 넘버

위치 CI의 위치 정보. 예를 들어 소프트웨어 CI 측면에서는 파일의 형태

인지 다른 매체인지, 혹은 물리적으로 어디에 위치하는지

소유자 CI의 소유자 혹은 소유 부서

소유 기간 CI에 대한 관리 혹은 사용 기간

공급자 CI의 공급자. E.g. 내부 개발 혹은 어느 회사로 부터의 구매

라이센스 라이센스 넘버 혹은 라이센스 협약을 참조할 수 있는 것

공급일 CI가 조직에 공급된 일시

승인일 CI가 조직에서 만족할 만한 테스트를 거쳐 승인되어진 일시

현재 상태 CI의 현재 상태. E.g. 테스트, 운영, 보관

예정된 상태 CI의 예정된 다음 상태. (상태 변경이 발생할 날짜나 시점 포함)

부모 CI와의 관계 부모 CI의 유일 식별자

- 161 -


속성 설명

관계 정보 부모/자식 이외의 모든 CI간의 관계 정보 (e.g. 다른 CI에 연결되어 있다, 사용

되어 진다, 다른 CI에 접근이 허용된다 등의 정보)

RFC 넘버 이 CI에 영향을 미치는 RFC 식별 넘버

변경 넘버 이 CI에 영향을 미치는 모든 변경 식별 넘버

문제 넘버 이 CI에 영향을 미치는 모든 문제 식별 넘버

사건 넘버 이 CI에 영향을 미치는 모든 사건 식별 넘버

주석 텍스트 형태의 기타 부가적인 CI 정보

RFC, 변경 기록, 패키지 릴리즈 기록, 이름, 카피 넘버, 모델 넘버, 버전 넘버 등은 변경에 의해 영향

을 받으며 그것들이 어떻게 영향을 받았는지에 대해 CMDB에 기록되어야 한다. 새로운 버전의 적용,

새 버전의 적용 결과 등도 또한 CMDB에 기록 되어져야 한다.

- 162 -


8. 변경 관리

8.1. 변경 관리의 목적

변경은 문제의 결과로부터 발생한다. 그러나 많은 변경이 비용감소 또는 서비스 개선과 같은 비즈니스

이익을 적극적으로 찾는 과정에서 발생될 수 있다. 변경 관리 프로세스의 목적은 서비스의 질에서 변

경과 관련된 인시던트의 충격을 최소화 하기 위함이며, 모든 변경의 효율적이고 신속한 처리를 위해

표준화된 방법과 절차를 확실히 하고 결과적으로 조직의 운영 개선을 하기 위함이다.

변경 요구에 대한 적절한 응답을 위해, 위험성, 비즈니스 연속성, 변경 영향, 자원요구, 변경 승인에 대

한 판단을 위한 접근이 필요하다. 이러한 것들을 고려한 접근은 변경의 영향에 대비하여 변경을 위해

필요한 것들 사이에 적절한 균형을 유지하기 위해 필수적이다.

특히 중요한 점은 변경 관리 과정은 변경이 발생될 때 일관성 있는 변경의 진행을 위해 높은 가시성과

의사소통 채널을 가진다는 점이다.

8.1.1. 목적

이 장의 목적은 필수적인 과정, 도구들 그리고 의존성을 포함하는 변경 관리 과정을 어떻게 구성하고

실행하는지에 대한 정보를 제공하기 위함이며, 또한 조직이 기대할 수 있는 이익에 대해 설명한다.

8.1.2. Best practice

변경 관리에서 Best practice의 정의는 불가피하게 논쟁의 여지가 있다. 그러나 일반적으로 변경 관리와

구성 관리는 주로 동시에 계획되고 실행된다. 변경과 구성 관리의 동시 실행을 통해 조직은 계획 단계

에서 어느 하나의 과정을 실행하지 않았을 때의 위험성 비교 검토가 가능하다.

8.1.3. 프로그램/프로젝트 관리 및 변경 관리

의존성, 경계선 그리고 역할을 분명히 정의하기 위해서, 변경 관리는 매우 큰 조직적인 프로그램 또는

프로젝트 제어를 위한 과정과 통합되어야 한다. 한가지 예로, 그림 8.1에서 어떻게 통합되어질 수 있는

지 보여주고 있다.

- 163 -


그림 8.1 변경 관리와 프로그램 관리의 경계

- 164 -


8.2. 변경 관리의 범위

변경 관리는 다음과 관련된 변경 프로세스 관리를 담당한다.

! 하드웨어

! 커뮤니케이션 장비와 소프트웨어

! 시스템 소프트웨어

! ‘운영중인’ 어플리케이션 소프트웨어

! 운영중인 시스템을 유지, 지원 및 실행과 관련된 모든 문서와 처리절차

어플리케이션 개발 프로젝트의 제어 아래 있는 어떤 구성 요소들 (예를 들어 어플리케이션 소프트웨어,

문서 또는 처리절차)의 변경은 변경 관리에 해당되는 것이 아닌 변경 관리 절차로 설계되어야 한다. 그

러나 변경 관리 팀은 변경 관리 환경에서 일관성 있는 실행과 유지를 보장하는 어플리케이션 관리 프

로젝트 관리자들과 밀접하게 연결되어야 한다.

이것은 어떤 제안된 변경의 승인을 위한(또는 그 반대) 변경 관리 과정이다. 변경 관리 과정이 진행되

는 동안, 대개의 경우 결정 권한은 그 조직내의 다른 직책의 사람들로 구성 되어진 변경 자문 위원회

(CAB)에게 있다. 제안된 변경의 적절한 관계에 대한 정보를 사용 가능하게 확실히 하는 것에 대한 책

임과 발생할 수 있는 영향을 인지하고 적절히 나타내는 것을 확실히 하는 것에 대한 책임은 구성 관리

에 있다는 점을 명심해라.

제안된 인프라스트럭쳐 변경이 조직의 다른 부분(예를 들면, 어플리케이션 개발 프로젝트 또는 비즈니

스 운영)에 잠재적으로 더 넓은 영향을 주거나, 또는 나쁜 영향을 줄 때 제안된 인프라스트럭쳐 변경에

원인이 있을 것이다. 각 방법으로부터 가능한 부정적인 영향들을 완화시키기 위해, 인프라스트럭쳐와

다른 변경 관리 시스템이 적절히 연결되어야 한다. (그림 8.1)

변경 관리 과정의 정보 데이터는 다음과 같이 구성된다.

! RFC

! CMDB

! 앞으로의 변경 계획 (FSC: Forward Schedule of Changes)

변경 관리 과정의 활동은 다음과 관련되어 있다.

! 변경 제거

! 변경 관리와 변경 진행

! CAB와 CAB/긴급 위원회 개최(단락8.3.2 참조)

! RFCs 검토와 마무리

! 관리 보고

- 165 -


변경 관리 과정의 결과는 다음과 같다.

! FSC

! RFC

! CAB 행동

! 변경 관리 보고서

변경 관리는 변경 또는 변경 기록 업데이트(구성 관리의 범위)에 의해 영향을 받는 구성 요소들을 확인

하는 것에 대해 책임이 없으며, 또한 새로 변경된 구성요소(릴리즈 관리의 범위) 릴리즈를 위한 책임도

없다. 용량 관리, 변경 관리, 구성 관리, 릴리즈 관리간의 관계는 그림 8.2에 나타나있다.

그림 8.2 – 용량 관리, 변경 관리, 구성 관리, 릴리즈 관리의 관계

- 166 -


'A Code of Practice for IT Service Management - PD0005 - 로부터 구해진 범위의 예:

변경 관리 구성:

$ 발생과 기록 변경

$ 변경의 영향, 비용, 이익, 위험 판단

$ 비즈니스 정당성과 승인 획득

$ 변경 실행의 관리와 상호작용

$ 실행 모니터링과 보고

$ 변경 요구의 검토와 마무리

긴급 변경은 때때로 요구되며, 기업은 신중하게 계획을 세워야 한다. 그들은 보통 변경 프로세스를

따르지만 몇몇 세부 사항들은 나중에 기록되기도 한다. 변경 기록은 진행 확인을 위해 규칙적으로

검토되어야 하며, 높은 위험 요소들의 확인을 통해 조직의 서비스 개선을 돕는다.

8.2.1. 왜 변경이 중요한가

‘변경’은 많은 정의를 가지고 있으나 아마 가장 적합한 것은 가장 간단한 것일 것이다: 변경은 한 정의

된 상태로부터 다른 상태로 움직이는 과정이다. 모든 것이 변경되는 비즈니스에서의 그 과정은 이미

충분히 복잡하며 정보시스템과 기술의 신뢰성은 관리에 많은 시간을 소비하게 한다.

! IT에서 비즈니스 변경의 영향 판단

! 비즈니스에서 IT 변경의 영향 분석

! 더 많은 변경을 요구하는 계속적으로 발생되는 문제 확인

! 더욱 더 변경을 발생시키는 원인에 대한 새로운 인식과 도구 적용

변경 관리에는 업무시간 전부가 소요된다.

만일 변경이 위험 노출, 영향과 혼란의 심각성을 최적으로 관리할 수 있고, 첫번째 시도에서 성공한다

면, 비즈니스를 위한 결론은 시간과 돈의 절약과 함께, 조기 이익 실현(또는 위험 제거)이다.

이 장에서는 중간 규모에 초점이 맞춰지지만, 계획, 제어, 위험관리, 혼란 최소화, 커뮤니케이션, 구현,

판단에 대해 조직 또는 인프라스트럭쳐의 어떤 종류 또는 크기에 대해 유일하지 않으며 모든 것에 적

용될 수 있다.

- 167 -


이 장에서는 아래의 변경 관리에 대한 안내를 제공한다.

! 작고 큰 변경

! 주요하거나 경미한 영향의 변경

! 요구되어진 timeframe에서의 변경

! 비용

! 조직들의 다른 종류와 크기

8.2.2. 인시던트 분석과 변경 관리의 경계

이 책의 5장은 인시던트 라이프사이클과 함께 6장 문제 관리를 논의하며, 이 프로세스에 변경 관리의

포함하는 측면을 준비한다. 또한 인시던트 해결과 변경의 경계를 중히 고려한다. 인시던트는 변경이 아

니며, 문제는 변경으로 진행되지 않을 수 도 있다. 인프라스트럭쳐 관리 상황에서 변경은 ‘이전에 규정

된 조건과 다른 상태’에 있는 수정된 문제의 결과이다. 이것은 아마도 눈으로 볼 수 있거나 볼 수 없는

다수의 방법으로 나타날 수 있다.

한가지 예를 들어보자; 한 PC가 고장 나서 교체 받았다. 인프라스트럭쳐 관리는 서비스 콜과 인시던트

기록, 분석과 수정, 구성 관리 기록의 적절한 업데이트를 요구한다. 서비스데스크는 우선적으로 인시던

트를 보고한 사람이 요구할 때 새로운 PC, 교육, 부속 부품을 보장할 것이다.

변경 요구와 서비스 요구의 차이를 아는 것이 중요하다. 많은 조직은 암호의 변경 또는 서비스 시간의

확대를 요구하는 것과 같은 서비스 요구를 변경 요구처럼 잘못 분류 하고 있다. 그 결과 변경 관리 프

로세스는 혼란에 빠지게 된다. 주어진 예는 변경이다. 그러나 변경은 이 책에 기술된 모든 프로세스의

사용보다 더욱 효율적으로 관리될 수 있고, 여과될 수 있다.

최근에 관계된 인프라스트럭쳐 관리는 복구 전략이다. 본래 지침은 확실히 ‘문제’ 변경으로부터 복구의

문제를 언급했다. 그러나 점점 변경을 실행하기 전에 복구는 더욱 중요해지고 있다. 종종, 복구는 마지

막으로 고려된다; 위험은 판단되어야 하고, 완화 계획들은 쓸모없어진다. 그러나 복구가 마지막 남은

선택 사항일 때, 어떻게 본래의 시작위치로 되돌아가는지는 종종 무시되고 단지 고려된다. 변경 관리

과정은 예측하지 못한 심각한 문제 이벤트에서 복구 계획을 포함한 변경 계획을 확실히 해야 한다.

8.2.3. 어플리케이션 개발과 변경 관리

만일 당신이 단지 어플리케이션 개발자와 시스템 분석가에게 모든 변경은 지금 단일 변경 관리 과정의

제어 아래 있다고 알린다면, 당신은 적극적인 지원을 받지 못할 것이다. 그러나 그러한 단일 변경 관리

과정을 위한 많은 합당한 이유들이 있다. 때때로 프로그램의 테스트된 시스템 버전과 프로그램의 요청

이 고객 수락 테스트 단계까지, 시스템 설계와 프로그램을 위한 변경 활동은 소프트웨어를 위한 변경

의 제어를 언제든지 가능하게 하는 것을 불가능하게 한다.

프로그램 개발의 진행에서, 변경 관리를 위해 무엇을 진행해야 하는지 인식되어야 한다. 그러나 빠르고

- 168 -


좋은 커뮤니케이션의 강조와 더불어 보통의 버전 제어는 어플리케이션 개발 팀에게 더욱 중요시된다.

변경 관리의 자금 제공과 어플리케이션 소프트웨어 개발에서 구성 관리는 프로그램 / 프로젝트 예산(실

제로, 그것은 많은 조직에서 best practice로 고려되어졌다)으로부터 발생될지도 모른다. 서비스 관리의

예산을 늘리지 않고 범위를 확장하기 위해, 사용중인 환경의 성과 발표는 추가 자금 공급을 위한 좋은

방법이다.

구성 관리의 관련성을 고려하라. 많은 인프라스트럭쳐 관리 소프트웨어 툴은 어플리케이션 소프트웨어

개발 제어를 위해 고안되었다. 중간 크기에서 큰 조직까지, 거기에는 다수의 새로운 어플리케이션을 작

성하는 중요한 사람들이 있다. 당신이 시작하기를 원하는 구성 관리 단계는 무엇인가? 몇몇 옵션은 다

음을 포함한다.

프로그램 코드 라인은 규칙적으로 변경된다.

! 소프트웨어 모듈

! 공통 모듈

! 완성된 프로그램

! 연결된 프로그램들

! 프로그램들의 세트

변경을 허락치 않는 권고들은 적절하지 않다. 당신은 당신의 비즈니스 운영, 시스템, 자원의 경험에

비추어 스스로 결정해야 한다. 조직은 변경 관리와 구성 관리의 최초 단계에서 비즈니스 드라이버, 위

험, 노동력, 도구, 수용력, 조직적 능력 그리고 비용-이익의 균등에 기반한 분별 있는 결정들을 필요로

한다. 만일 그 결정이 모든 변경을 중심적으로 제어가 가능하다면, 적절한 소프트웨어 툴과 교육에 대

한 주된 투자가 필요할 것이다. 더 많은 정보는 8.8절을 참조하라.

비즈니스 변경의 영향은 결국 사용할 수 있는 변경 관리의 여과할 곳에 고려되어야 하기 때문에, 구성

관리 문제의 범위는 분명하지만 변경 관리 문제의 범위는 아마도 더욱 불분명하다.

8.2.4. 비즈니스 변경과 변경 관리

변경 관리 과정은 비즈니스의 일상의 운영 내에서 변경을 관리한다. 큰 조직은 프로젝트 관리와 제어

에 ‘PRINCE2’와 같은 방법을 사용하지 않는다.

이 장의 뒤의 단락에서, CAB과 변경을 위해 필요한 판단에서 그들의 임시 역할, 그리고 변경의 중요성

과 시간범위에 관하여 다루어진다. 적절한 곳에서 CAB는 프로그램과 프로젝트 관리 팀과 변경 문제,

목표, 영향, 개발이 조직을 통해 단계적인 반응이 일어나는 것에 대해 확실히 하기 위해 서로 밀접하게

연관되어야 한다. 변경 관리에서 변경 계획자를 도울 수 있는 한가지 방법은 변경 모델을 만들고 그

모델의 영향 판단을 위해 용량 관리자와 커뮤니케이션하는 것이다.

- 169 -


8.3. 기본 개념

변경 관리의 기본적인 개념은 기술적이라기보다는 프로세스의 관계와 관리이다. (반면에 인시던트 관리

는 몇몇 프로세스의 기계적 본질의 강조와 더불어 주로 기술적이다.) 그러므로 이 장은 당신이 조직에

서 확인이 필요한 가장 중요한 요소들의 정보 제공에 집중한다.

그림 8.3a와 8.3b는 기본적인 변경 관리 과정의 순서도를 나타낸다.

그림 8.4는 표준 변경 관리 과정을 변경 라이프사이클 관점에서 설명한다.

그림 8.3a –기본적인 Change Management 과정 - part 1.

- 170 -


그림 8.3b – 기본적인 Change Management 과정 - part 2.

- 171 -


그림 8.4 – 표준 변경 관리 과정을 위한 접근

표준 변경은 설정된 경로를 따르는 인프라스트럭쳐를 위한 하나의 변경이며, 상대적으로 공통적이고

특정 요구 또는 요구 세트를 위해 수락된 솔루션이다. 표준 변경의 중요한 요소는 다음과 같다.

! 잘 알려졌고, 증명된 업무

! 사전에 효율적으로 부여된 권한

! 이벤트의 순서는 보통 서비스데스크에 의해 설정될 수 있다.

! 예산상 승인은 전형적으로 미리 규정되거나 변경 요구자의 통제 내에 있을 것이다.

접근이 구성되고 상세하게 기록될 때, 그러한 변경은 조직의 비즈니스 요구를 효율적으로 지원하고 진

행하기 위해 표준 변경 관리 절차가 개발되고 보급되어야 한다.

8.3.1. 변경 요청

변경 요청 (RFC: Request for Change)은 다양한 원인과 사유로 발생된다.

- 172 -

그 사유는 다음을 포함한다.


! 인시던트 또는 문제 보고서에 요구된 해결방법

! 고객 접촉이나 서비스 수준 관리를 통해 나타난 사용자나 고객의 불만

! 제안된 새로운 CI의 도입 또는 제거

! 인프라스트럭쳐의 몇몇 구성요소에 대해 제안된 업그레이드

! 변경된 비즈니스 요구 또는 지시

! 새롭거나 변경된 법률

! 위치 변경

! 벤더 또는 계약자로부터 제품 또는 서비스 변경

RFC는 인프라스트럭쳐의 어떤 부분, 서비스 또는 활동에 관계되어있다.

다음은 몇 가지 예이다.

! 하드웨어

! 소프트웨어

! 문서자료

! 전화통신 시설

! 훈련과정

! IT 인프라스트럭쳐 관리 과정

! 전술상의 계획

! 인프라스트럭쳐 환경

물론 RFC는 단지 문서형태 일 수 있으나, 이와 같은 경우가 점점 증가하기 때문에 아마도 회사 인트

라넷에서 전자적으로 관리된다. 다음 요소는 문서든 전자식이든 RFC 형태에 포함해야 한다.

! RFC 번호(필요한 곳에 문제 보고서 번호를 더하여 참조)

! 변경되는 요소들의 확인과 기술 (만일 구성 관리 시스템이 사용되고 있다면 CI 확인을 포함)

! 변경의 원인

! 변경을 실행하지 않았을 때의 영향

! 변경되는 요소의 버전

! 변경을 제안한 사람의 이름, 위치 그리고 전화번호

! 변경이 제안된 날짜

! 변경의 우선순위

! 임팩트와 자원 판단 (아마 사용하기 적절한 곳에 별도의 형태로 있을 것이다.)

! 적절한 곳에 CAB 추천(사용하기 적절한 곳에서 개별적인 임팩트와 자원 판단 포함)

! 인증 서명(전자식일 수 있다)

! 인증 날짜와 시간

! 예정된 실행(릴리즈 확인과 날짜와 시간)

! 릴리즈 / 실행 계획의 위치

! 변경 작성자 / 실행자의 세부사항

- 173 -

서비스관리를 위한 레퍼런스 요약집IT ITIL ! 복원 계획

! 실제 구현 날짜와 시간

! 검토 날짜

! 검토 결과(필요한 곳에 새로운 RFC 참조를 포함)

! 위험 판단과 관리

! 비즈니스에서 연속적과 우발적 계획에 대한 영향

! RFC의 상태 – 예를 들면 ‘기록’, ‘평가’, ‘거절’, ‘수락’, ‘정지’

릴리즈 또는 구현 계획은 모두를 위하여 제공되어야 한다. 그러나 가장 간단한 변경과 실패한 변경의

복구방법에 대해 상세히 기록하여야 한다. 변경의 완료에서, 그 결과는 변경의 관리 책임에 대한 판단

을 위해 보고되어야 하며, 고객 합의(인시던트, 문제 또는 알려진 오류에 밀접하게 관계된 것을 포함)

를 위한 완성된 변경을 제출하여야 한다. 분명히, 중요한 변경을 위해서 거기에는 전체 과정을 통한 더

많은 고객 입력이 있을 것이지만 주된 요점은 그 고객은 어떤 변경(얼마나 작은 변경 인지는 문제가

되지 않는다.)이 구현되기 전에 상담 되어야 한다는 것이다.

그것의 라이프사이클을 통한 변경 진행에 따라, 변경 요구와 CMDB는 업데이트 되어야 한다. 그 결과

변경을 시작한 사람은 그것의 상태를 알고 있어야 하며, 실제 사용된 자원과 비용은 그 기록의 일부로

기록되어야 한다. 구현 후 검토(PIR: Post-Implementation Review)는 변경이 그 목적을 충족시켰는지, 고

객은 그 결과를 만족하는지 그리고 예상치 못한 영향이 없었는지에 대해 확인되어야 한다. 획득된 사

례는 앞으로의 변경을 위해 피드백이 이루어져야 한다. 작은 조직은 아마 큰 규모의 PIR보다 변경의

부분 점검을 선택할 것이며, 큰 조직에서는 많은 유사한 변경을 실행할 때에 부분 점검에 그 가치를

둘 것이다.

8.3.2. 변경 자문 위원회

변경 자문 위원회(CAB)는 변경의 우선순위와 판단에서 변경을 동의하고 변경 관리를 돕기 위해 존재

하는 핵심부분이다. 그리고 CAB가 개최될 때, 모든 변경이 비즈니스와 기술적 관점으로부터 충분히 평

가되도록 확실히 할 수 있는 구성원으로 선택되어야 한다. 이 구성을 달성하기 위하여, CAB는 고객 비

즈니스 요구와 사용자 커뮤니티를 분명히 이해하는 사람들을 포함해야 한다. (물론 기술적 개발과 지원

기능 뿐만 아니라)

단락 8.5.5를 참조하라.

CAB가 요구될 때, CAB회원은 다음과 같이 구성된다.

! 변경 관리자

! 고객

! 사용자 관리자

! 사용자 그룹 대표

! 어플리케이션 개발자 / 유지자 (적절한 곳에서)

- 174 -


! 전문가 / 기술 컨설턴트

! 서비스 직원(필요 시)

! 사무실 서비스 직원(변경 적용이 악영향을 미칠지도 모르는 부서)

! 계약자 또는 3rd Party 대표(필요에 따라 – 예를 들면 아웃소싱 상황)

CAB의 다음과 같은 점을 강조하는 것이 중요하다.

! 고려되고 있는 변경에 따라 구성될 것

! 단순한 회의의 구성범위조차도 다양하게 고려

! 유용하다고 판단될 때 공급자를 포함시켜야 한다.

! 사용자와 고객 관점을 반영해야 한다.

! 적은 시간을 위해서지만 문제 관리자와 서비스 수준 관리자와 고객 관계 직원을 포함하는 것

이 좋다.

중요한 문제가 발생할 때, 전체 CAB를 소집할 시간이 없을지도 모른다. 그러므로 긴급한 결정들을 할

권한 있는 더 작은 조직을 구성하는 것이 필요하다. 그러한 조직은 CAB 긴급 위원회(CAB/EC: CAB

emergency Committee)이다. 변경 과정은 어떻게 CAB와 CAB/EC의 구성이 위에 나열된 표준과 비즈니

스에 적절할지도 모르는 다른 표준에 기반하여 각 경우에 결정될지를 분류하는 것이다. 이것은 중요한

변경이 제안되었을 때 비즈니스 이익을 적절하게 표현하기 위해서, CAB의 구성의 유연성을 확실히 하

는데 그 의도가 있다. 그것은 또한 CAB/EC의 구성이 어떤 예상할 수 있는 사태에서 적절한 결정을 하

기 위한 비즈니스 전망과 전문적인 관점의 제공을 확실히 할 것이다.

명심할 가치가 있는 실제적인 조언은 CAB는 평가기준을 정의하고 일치하여야 한다는 점이다. 이것은

변경 판단 프로세스에서 각 변경의 판단을 내릴 수 있는 구성원에 의해 템플릿 또는 프레임워크과 같

은 행동을 도울 것이다.

8.3.3. 변경 측정기준

변경 관리(이상적인 비즈니스 관리자들과의 상담에서)는 특정한 의미를 가지고 있는 판단에 대한 생각

을 위해 필요하다. 문제가 되는, 변경이 필요한 인시던트의 수를 계산하기는 상대적으로 쉬운 반면에,

그러한 변경의 근본적인 원인을 찾고 경향을 확인하는 것이 훨씬 더 가치 있다. 변경의 영향을 측정하

고, 변경 관리의 도입 때문에 감소된 혼란을 설명하고, 또한 비즈니스 요구를 확인하기 위한 IT 인프라

스트럭쳐 반응 속도와 효율을 측정하는 것이 더욱 필요하다.

측정은 어디에나 실용적인 비즈니스 목표, 비용, 서비스 가용성, 신뢰성에 연결되어야 한다. 어떤 예측

은 실제 측정과 비교되어야 한다. 구문 8.7은 측정기준과 관리 보고에 대한 더 많은 정보를 제공한다.

8.3.4. 변경의 사전 계획과 변경모델

어떤 다른 것보다 빠르게 변화하는 변경 관리의 하나의 영역은 구현에 앞서 변경 모델을 구축하는 개

- 175 -


념이다. 이것들의 대부분은 데스크탑 장비의 새로 또는 업그레이드와 같은 더 작은 표준 변경에 적용

되었다. 용량 관리는 실제에 앞서 발생 가능한 영향을 판단하기 위해 복잡한 변경들의 대규모 모델들

을 구축하는 것을 도울 수 있다. 일반적으로, 용량 모델 구성은 예외적인 복잡성 또는 규모에 관해 또

는 그 둘 다의 변경을 위해 일어난다.

중요한 변경의 영향의 판단을 위해 책임의 문제는 정의되어야 한다. ‘하나의 사이즈가 모두에게 맞는’

솔루션이 없다는 것은 조직의 크기, 구조 그리고 복잡성이 너무 다양하다는 점이며, 이것은 best-

practice의 문제가 아니다. 그러나 중요한 변경은 민감한 책임의 경계와 커뮤니케이션 개선을 위하여

모든 부분(프로그램/프로젝트 관리와 변경 관리)의 시작부터 논의할 것을 추천한다.

비록 변경 관리가 변경 판단을 확실히 하는 것에 책임이 있지만, 만일 변경이 승인되고, 이어서 개발되

고 테스트되고 실행 및 검토된다면, IT 서비스를 위한 분명한 최종 책임은 자금을 제어할 수 있는 IT

관리자, IT 서비스 관리자 그리고 고객에게 있을 것이다.

변경 관리와 구성 관리의 다른 측면에서의 개념은 소규모의 변경은 PC 교환 또는 규칙적인 소프트웨

어 업데이트와 같은 ‘표준’ 변경 모델의 사용에 의해 만족될 수 있다는 것이다.

미리 정의된 계획은 모든 표준(아마 구축, 테스트 또는 프로세스에 관계된 표준)과 함께 실행되며,

변경 관리는 그러한 변경 관리 과정의 참조 없이 그와 같은 변경에 대해 권한을 줄 수가 있다.

그림 8.4는 변경 관리에서 미리 정의된 변경의 표준 모델을 사용하는 프로세스가 보통의 변경 과정

안에 어떻게 통합될 수 있음을 설명한다. 그 모델의 사용에 관계된 변경의 규모 또는 중요성은 조직의

특성이라는 점을 주의하라.

구현을 위한 스케쥴링 변경의 개념은 일정해야 한다. 그러나 변경 관리가 IT 계획보다 비즈니스 계획에

따라 변경을 설치하는 것이 추천된다. IT 관리가 서비스에 혼란을 최소화 하기 위하여 주말동안 중요한

변경들을 계획하는 것은 흔한 것은 아니다. 그러나 그들 같은 관리자들은 필수적인 유지를 위해 작업

시간동안에 중단 시간을 계획한다. 오늘날, 대부분의 관리자는 서비스 시간 안에 어떤 계획된

중지시간을 피하고, 지연된 실행을 통해 나타날 수도 있는 중요한 문제 또는 매우 긴급한 변경과 함께

같은 방법으로 계획된 대다수의 변경을 확실히 한다.

이 처리를 쉽게 하기 위하여, 변경 관리는 ‘변경의 사전 계획’(FSC: Forward Schedule of Changes)과

‘기획된 서비스 가용성’(PSA: Projected Service Availability)의 생산 및 분배를 적절하게 조정할 것이다.

이 문서들의 최신 버전은 가급적 공통적으로 이용할 수 있는 인터넷 혹은 인트라넷 서버에 저장하여

조직내의 모든 사람이 사용 가능해야 한다. FSC은 그들의 제안된 구현 날짜와 구현이 승인된 모든

변경들의 세부사항을 담고 있다. PSA는 현재 계획된 FSC 때문에, SLA와 서비스 가용성의 동의를 위한

변경의 세부사항을 포함한다. 이 문서들은 서비스 수준 관리, 서비스데스크, 가용성 관리 그리고

비즈니스에 관련된 고객들과 합의되어야 한다. 일단 합의되면, 서비스데스크는 사용 가능한 가장

- 176 -


효율적인 방법을 사용하여 사용자들에게 추가적으로 계획된 서비스 중지시간을 전달해야 한다.

만일 당신의 조직이 변경 관리 프로세스와 전반적인 서비스 지원 모델에 통합된 다른 모델의 프로세스

모델을 중지시켰다면, 실제로 프로세스 변경 비용과 위험 없는 변경의 영향을 판단하는 것은 간단한

일이다. 마찬가지로, 만일 당신이 중요한 변경의 모델을 만들 수 있다면, 당신은 서비스와 서비스 수준

그리고 연속적인 비즈니스 계획에서 변경의 영향을 판단하기 위해 용량 관리, 비즈니스 연속성 관리,

가용성 관리, 서비스 수준 관리의 도움을 이끌어낼 수도 있다.

아마 필요하다면 단계적으로 실행되는 변경과 그런 변경모델의 도움으로, 당신은 완성된 변경을

판단할 수 있고, 계획을 구성할 수 있으며, 변경을 성공적으로 하기위해 적절한 곳에 있어야 하는 모든

것들을 제자리에 있도록 확실히 해야 한다.

상당한 차이가 순서도와 프로세스 모델사이에 있다는 것을 주의하라. 순서도들(몇몇 유용한 보기들은

이 가이드에 제공된다)은 변경 관리가 간단한 정보 흐름들을 보도록 허용하지만 ‘실 운영’을 그대로

추상화 한 것은 아니다. 그러나, 프로세스 모델은 상세한 평가의 능력이 있고 신뢰성이 높은 그림을

제공한다.

변경 계획에 의한 프로젝트 계획을 지원하기 위한 모델과 스케쥴의 사용은 변경의 영향을 예측 가능하

게 한다. 당신은 또한 장래의 계획을 개선하고, 변경이 순조롭게 진행하는 것을 확실하게 하기 위해,

예측을 현실과 비교할 계획의 구현을 볼 수 있다. 변경을 형성하는 것에 관한 정보를 위해 단락 8.5.9

를 참조해라.

8.3.5. 아웃소싱과 변경 관리

서비스 제공의 아웃소싱의 경우, 그 제공하고 있는 아웃소싱된 서비스가 거대한 메인프레임과 대규모

의 운영/네트워크 조직을 사용함으로써 종종 규모의 경제를 만들거나, 또는 그들의 매입 규모 때문에

그들은 거대한 구매력을 가진다는 점을 명심해라. 이런 경우에, ITIL 안내의 적용은 서비스를 제공하는

비용 감소, 더 신뢰성 있는 서비스 제공, 효율 개선의 관점에서 볼 때 분명히 중요한 영향을 줄 것이다.

아웃소싱이 고려 중일 때, 서비스를 제공받는 자는 변경 관리 프로세스에 대해 다음 문제를 고려할 필

요가 있다; ! RFC로부터 모든 소스로부터 발생하는 매일매일의 변경 관리에 대한 책임은 누구에게 있는가?

! 불합리한 변경을 위한 비용을 지불하지 않기 위해 서비스 제공자 위에서 어떤 제어를 하는가?

! 서비스와 서비스 비용의 결과로 일어나는 영향과 더불어 변경은 하나씩 승인되지 않는다는 것

을 어떻게 알 수 있는가?

! 누가 적절한 비용, 승인, 계획, 제어 그리고 구현을 확실히 하는 중요한 비즈니스 변경에 대해

책임이 있는가?

! 누가 변경 후의 시스템과 서비스의 완전성에 대해 책임이 있는가?

! 시스템 보안은 적절히 고려되는가?

! 누가 CAB가 되어야 하는가?

- 177 -


아웃소싱 계약들은 다음과 같은 관점에서 너무 많이 변하기 때문에 보편적인 조언을 제공하는 것은 실

제로 도움이 되지 않는다.

! 비용

! 하드웨어와 소프트웨어 소유권

! 비즈니스가 제공자와 함께 협력관계가 되는 단계 (단순한 제공자-고객 관계보다는 다소)

! 제공되는 서비스의 특성

! 서비스의 범위(인프라스트럭쳐, 서비스/헬프 데스크, 어플리케이션 소프트웨어 개발 등)

이와 같이 서비스 제공자(외주 또는 내주)가 당신의 조직의 요구와 일치하는 변경 관리 기능과 프로세

스를 제공하도록 확실히 해야 한다. 아웃소싱 상황에서 몇몇 조직들은 변경의 승인에 앞서 판단을 위

해 RFC를 그들의 공급자에 맡긴다.

아마도 조언의 가장 현명한 부분은 당신이 서비스 지원, 전달, 관리에 관계된 조직의 모든 것을 통해

변경 관리, 인시던트 관리, 릴리즈 관리, 구성 관리 프로세스를 조정하는 것을 확실히 해야 한다는 점

이다. 아마 중요한 비교들을 하기 위하여 프로세스 모델이 필요할 것이다.

변경 관리는 다음을 고려하여야 한다:

! 계획에는 무엇이 있어야 하는가

! Ownership

! 순환

! 무슨 핵심 비즈니스가 지원되어야 하는가

! 어떻게 그 비즈니스가 IT에 의해 지원되는가

! 비즈니스 연속성과 IT 비상 계획의 연결

! 중요한 요소

! 시간규모

! 위험

! 복구 전략

8.3.6. 중요한 중지 계획

비록 중대한 비즈니스 시스템들의 복구를 위한 계획이 변경 관리에 직접적인 책임이 있지는 않지만,

그들의 관련은 단지 상식적일 뿐만 아니라 필수적이다. 이것은 비즈니스의 기반인 IT시스템과 서비스

복구를 위한 어떤 계획들은 변경을 필요로 할 것이고, 원만한 운영을 확실히 하기 위해 제어되어야

하기 때문이다.

물론, 그것은 또한 잘못되고 있는 계획의 결과에 대해 무엇을 해야 할지 고려되는 것이 필요하다.(또는

비록 당신이 그 계획의 결과로 생긴 변경으로부터 복원이 필요하다 하더라도)

이 경우에, 복원을 위한 계획에 관한 더욱 빠른 조언은 매우 초기의 계획 단계에 특히 밀접한 관계가

있게 된다. 분명히, 거기에는 계획 프로세스를 변경하기 위한 연결이 있어야만 한다.

- 178 -


8.4. 이익, 비용 그리고 발생 가능한 문제

8.4.1. 이익

효율적인 서비스 관리는 에러나 잘못된 결정 없이, 규칙적인 방법으로 변경할 수 있는 능력을 요구한

다. 효율적인 변경 관리는 반드시 서비스의 충분한 공급과 변경의 높은 수준의 대처능력이 요구된다.

효율적인 변경 관리 시스템의 구체적인 이익

비즈니스 요구에 대한 IT 서비스의 더 나은 배치

! 비즈니스와 서비스-지원 직원 사이의 변경에 대한 커뮤니케이션의 증가

! 위험 판단의 향상

! 서비스의 질과 SLA에서 변경의 나쁜 영향의 감소

! 손실을 입기 전에 제안된 변경에 대한 보다 다은 비용 판단

! 더 적은 변경의 복원, 필요할 때 더욱 쉽게 할 수 있는 증가된 능력

! 변경 관리 프로세스를 통해 축적된 변경에 관계된 관리 정보의 활용을 통해서 개선된 문제와

가용성 관리

! 사용자의 증가된 생산력 – 더 적은 혼란과 질적으로 더 높은 서비스 제공

! 계획된 직무로부터 잘못된 변경 복원 또는 긴급한 변경의 실행까지 전환을 위한 더 작은 요구

를 통해 핵심 직원의 생산력 증가

! 큰 규모의 변경의 더 큰 대처 능력

! 서비스의 질과 전문적 접근의 향상을 통해 높아진 IT 비즈니스의 이해

8.4.2. 비용

변경 관리의 두 가지 주된 비용은 직원과 소프트웨어 툴의 지원에 있다.

직원 비용

직원 비용은 구성과 릴리즈 관리를 포함한 변경 관리 역할과 팀, CAB 구성원, 변경 구성자를 위한 비

용을 포함한다. 이 비용은 얻어지거나 얻어질 이익에 의해 중요하게 되어야 한다. 실제적으로 대부분의

조직은 변경을 위한 많은 직원들이 있다.

비록 이 장을 따르면, 변경에서 소비되는 관리시간의 양은 증가를 보이지만, 실제적으로 당신은 변경

관리를 통해 더 적은 시간을 소비할 것이라는 것을 발견할 수 있을 것이다. 비효율적인 변경 관리로부

터 발생되는 문제를 다룰 필요는 없다.

지원 도구

어떤 하드웨어 요구와 함께, 지원도구의 비용은 고려되어야 한다. 비록 변경 관리, 구성 관리, 문제 관

리, 서비스 데스크를 위한 완전한 지원은 아마 ‘간단한’ 변경 관리 도구들보다 더욱 비용이 많이 들 것

이며, 추가적인 비용도 종종 인정된다. 더욱 커다란 조직을 위해, 관리 프로세스가 적절한 지원도구 없

이 효율적으로 실행하기는 사실상 불가능하다.

- 179 -

서비스관리를 위한 레퍼런스 요약집IT ITIL 8.4.3. 가능한 문제

당신이 실행하는 변경 관리 프로세스는 조직의 규모에 적당해야 한다. 절차가 복잡한 프로세스는 효율

성을 감소시킬 수 있다. 문서 기반 시스템 (매우 작은 조직 또는 처음으로 변경 관리를 구성하는 조직

에서 종종 발견된다.)은 관리하기 어렵고 종종 병목현상이 생긴다. 그들은 실질적으로 매우 작은 기관

을 위한 것이다.

아마 단일 변경 관리 시스템이 인프라스트럭쳐의 모든 면에서 사용되어야 한다는 것을 받아들이는 직

원, 고객, 사용자를 구하기에는 문화적 어려움이 있을지도 모른다. 또한 인프라스트럭쳐의 모든 구성요

소는 서로에게 중대한 영향을 줄 수 있다는 것과 개개의 CI를 위한 변경은 공동작업이 필요하다는 것

을 모든 사람들에게 납득시키기 위한 교육이 필요할지도 모른다. 그렇기 때문에 변경 관리 프로세스

참조 없이 변경을 실행할 것이다. 대책은 그러한 허가되지 않은 변화를 막고 인지하기 위해 도입되어

야 한다.

! 규칙적인 자체 감사를 통해 사용자 변경 관리 절차에 관계된 변경 관리 직원, 다른 서비스 관

리 직원과 사용자를 점검해야 한다.

! 조직내에서의 활동에 관한 관리 제어를 실행하며, 계약자는 직원과 기술자를 지원한다.

! 모든 CIs와 버전의 구성 관리 제어 실행

! 서비스 데스크를 통해서 구성 관리 시스템에 알려지지 않은 장비 또는 소프트웨어에 접속하

는 사용자의 인지

! IT 서비스 관리에서 새 직원과 기존 직원의 교육

조직의 변경 관리 과정에 관계된, 하드웨어 기술자와 같은 계약자의 대표자를 확실히 하는

것은 아마 어려울 것이다. 그렇기 때문에, 그러한 수락을 위한 요구가 포함되는 공급자와의

계약이 추천되어진다. 표준 OGC CC88 계약의 12 조항이다. Part 2-C를 참조하라.

만일 계약자가 하드웨어 유지 계약(CMH)의 어떤 부분의 변경을 제안한다면, 계약자는 권한

자에게 알리고, 제안된 변경을 위해 권한자의 동의를 요청한다. 이러한 동의 요청은 불합리

한 보류가 되지는 않는다. 만일 동의가 주어진다면, 변경은 서로 편리한 시간에 수행될 것이

다.

참조 : BSI 출간 “A Code of Practice for IT Service Management” – pd0005-

분명한 이 사항의 처리는 그 문제를 이익으로 바꿀 것이다.

PD0005: 변경 관리에서 발생 가능한 문제

! 이용가능한 자원, 무리한 직원의 확장, 지연의 원인에 대한 변경의 범위는 너무 넓

다.

- 180 -


! 영향받은 시스템의 소유주는 불분명하기 때문에, 지연과 불완전한 판단이 야기된다.

! 만일 변경 관리가 구성 관리 없이 실행된다면 그 솔루션은 훨씬 덜 효율적일 것이다.

! 프로세스는 그것을 따르지 않는 근거를 주기에 너무 절차가 번거롭다.

! 부정확한 구성 데이터는 아마 변경에 관해 상담 되어진 적절하지 않은 사람들에 의한

서투른 영향 판단의 결과를 가져올 것이다.

! 플렛폼과 반대 기억장소 사이의 업그레이드의 좋지않은 동시성은 변경을 어렵게 만들거

나 계획을 불가능하게 만든다.

! 복원 과정은 분실되거나 테스트되지 않는다

! 변경요구의 진전은 손으로 집중적이다. 그것은 간단한 데이터베이스 또는 자동화 시스템

을 시작하는 것이 적합하다.

! 상관과 중간 관리자로부터의 제어의 부족은 실행시간을 늘릴 것이다. 직원은 그 제어를

반대할 것이다. 만일 관리자로부터 권한을 받을 수 없다면 그들은 피하려 할 것이다. ! 그 프로세스는 긴급한 변경가 이루어질 때 자주 실패한다.

- 181 -


8.5. 활동

물론 변경 프로세스와 절차를 관리함에 있어서, 변경 관리는 자신과 다른 비즈니스, 그리고 IT 기능들

사이의 의사소통 관리를 위한 책임이 있다. 변경 관리에서 best practice의 간단한 프로세스 모델은 이

안내서에 요약되어 있다. 그러나 변경 사용, 구성 관리 업데이트, 영향분석과 같은 프로세스가 best

practice에서 필수적인지는 분명히 해야 한다.

조직이 변경 관리 프로세스의 실행을 결정하는 방법은 시간, 우선 순위, 사람 그리고 무엇보다도 돈과

같은 이용할 수 있는 자원들에 의해서이다.

8.5.1. 운영 프로세스의 실행 계획

변경 관리는 이 단락에서 기술된 활동을 위한 운영 절차의 실행 계획을 세우거나, 또는 이 지침을 따

르는 어떤 절차를 수정해야 한다.

8.3.4에 언급된, 프로세스 모델은 순서도보다 더욱 분명한 그림을 제공한다. 그러나 더 큰 이해를 위해,

이후의 사례를 통해 논의되어진다.

8.5.2. 변경 사용과 여과

표준 형식, email, 인트라넷 스크린을 사용해서 기록하는 RFC를 위한 절차는 정해져 있어야 한다. 컴퓨

터기반 지원툴이 어디에서 사용되어지는지에 따라, 그 툴은 그 형식에 맞게 규정되어야 한다. 지원 툴

의 표준이 정해지지 않은 곳이나 문서기반 시스템이 사용 되는 곳에서는 단락 8.3.1에서 보여지는

RFC 형식에 포함된 항목들이 추천된다.

모든 조직의 구성원들에게 변경을 요구할 수 있는 권한이 주어지는 것은 더욱더 추천된다. 만약 그렇

지 않다면, 새로운 도입은 억제되고 중요한 문제는 보고되지 않을지도 모른다. 그 결과, 다수의 사용자

가 있는 곳에서 사용자 요구는 제안되기 전에 상위 사용자 관리자에 의해 인가되어야 한다. 그로 인해

폭넓은 사용자 계층을 가지고 있지 않거나 비실용적인 요구는 제거될 것이다. 요구의 양이 줄어들며,

이것은 유사한 요구 대조 또는 요구 확인에 도움을 주기도 한다. 그러나 사용자 관리자는 새로운 도입

의 억제 또는 제안된 변경에 대해 직원들을 설득시켜야 한다는 것을 명심해야 한다.

모든 RFC는 사용되어야 하고, 순서대로 인증번호가 주어져야 한다. 변경 요구가 문제 기록(PR)의 해결

책과 함께 제출이 되는 경우, 원래의 PR번호가 계속 유지되는 것은 중요하며, 그 결과 문제와 해결책

과의 연결은 쉽고 명확해진다.

모든 CI의 데이터와 그들 사이의 관계를 저장이 가능한 서비스 관리 툴에 의해 RFC가 시작되는 것이

추천된다. 이것은 모든 다른 구성요소에서 시스템의 한 구성요소에 대한 변경의 영향을 판단할 때 큰

도움이 될 것이다. 그들이 실행한 모든 행동은 변경 관리 로그 안에 기록되어져야 한다. 만일 이것이

어떤 이유 때문에 불가능하다면, 그때는 다음에 발생할 수 있는 경우를 위해 수동으로 기록해야 한다.

- 182 -


이 과정에서는 누가 로그인 시스템에 접속하고, 접속 레벨은 무엇인가에 대한 분류가 필요하다. 정상적

으로, 시스템은 어떤 권한 있는 직원에게 허용되거나, 진행 보고서를 RFC(지원 툴은 그러한 행동을 인

식해서 변경 관리를 유지시킨다)에 추가한다. 그러나 만일 변경 관리가 구성 관리 시스템의 통합된 부

분이라면, RFC 접근은 오직 변경 관리 직원 또는 구성 관리 지원 직원에게만 허용되어야 한다.

변경이 시작될 때, 변경 관리는 요구에 대한 고려절차와 완전히 비실용적인 요구의 제거 절차를 정해

야 한다. 이것은 요구한 사람에게 거절된 이유를 간결한 세부사항과 함께 되돌려 보내야 한다. 그리고

그 로그는 사실 그대로 기록 되야 한다. 거절에 대한 항의 권리는 정상적인 관리 경로에 있어야 하며,

그 과정에 포함되어야 한다.

8.5.3. 우선순위의 할당

모든 RFC는 문제와 그 해결을 위한 영향에 기반하여 우선순위가 할당되어야 한다. 이 우선순위 평가

는 만일 필요하다면 변경 관리 또는 CAB에 의해 제일 먼저 토의되고 판단되어야 하는 변경에 의해 결

정된다. 변경 관리는 이 우선순위에 대한 책임을 져야 한다. RFC의 우선순위는 만일 필요하다면 요구

자와 CAB의 협력으로 결정하는 것이 이상적이다. 위험판단은 이 단계에서 매우 중요하다. CAB는 변경

실행 또는 거부의 위험을 효율적으로 판단하기 위해 비즈니스 중요성에 대한 정보를 필요로 할 것이다.

우선순위 판단은 다음의 예로 제공된다. 많은 소프트웨어 툴들은 광범위한 우선순위 판단을 허용한다.

! 즉시. 다수의 사용자들, 중대한 역할의 시스템, 또는 몇몇 심각한 문제에서 서비스 손실 또는

위험한 문제 발생. 이것은 즉각적인 행동이 요구되며, 긴급 CAB 또는 CAB/EC 모임의 소집이

필요하다. 또한 그러한 권한이 주어진 변경의 구성시 즉시 자원이 할당되어야 함

! 높음. 심각하게 영향 받는 몇몇 사용자들 또는 다수의 사용자들에 대한 영향. 변경 구성, 테스

트, 실행자원에 대해 가장 높은 우선순위

! 중간. 심각하지 않은 영향, 그러나 다음에 계획된 릴리즈 또는 업그레이드 때까지 수정을 미룰

수는 없다. 자원에 대해 중간 우선순위

! 낮음. 변경은 합리적이고 필수적이지만, 다음에 계획된 릴리즈 또는 업그레이드 때까지 기다릴

수 있다. 적절하게 자원 할당

RFC는 그들이 ‘수정’해야 하는 순서를 지시하기 위해 이미 조직 내에서 우선순위가 정의되고 합의될

것이다. 이 ‘중요성 코드’는 검토되어야 하며(만일 거기에 좋은 이유가 없다면 왜 아닌지), 변경 우선순

위를 위한 기반으로 사용되어야 한다. 각 우선순위 단계를 위한 시간구조는 미리 결정되어야 하고 단

계적 프로세스는 정의되어야 한다.

8.5.4. 변경 분류

비즈니스에서 변경의 위험 문제는 변경이 허가되기 전에 고려되어야 한다. 변경 관리는 각 RFC를 검

토하여야 하며, 미리 정의된 분류에 따라 처리를 결정한다. 분류 프로세스는 조직에서 허가된 변경을

실행하기 위해 필요한 자원에 대한 변경의 영향을 검토한다. 이 분류의 구조와 복잡성은 관계된 우선

- 183 -


순위의 범위를 포함하는 비즈니스의 요구에 매우 많이 의존한다는 점을 주의해라. (단락 8.5.3을 참조하

라)

위의 우선순위 프로세스는 변경의 순서를 정하기 위해 고려되어야 한다. 작은 변경의 경우 변경 관리

는 서비스 데스크 직원과 같은 특정 부분의 승인을 위한 권한을 위임할 수 있다. 그러나 적절한 보고

구조는 그 곳에 있어야 한다; 권한은 위임할 수 있는 반면에 책임은 위임할 수 없다.

아래에 분류의 예가 있다. RFC의 대다수는 첫번째 두개에 분류될 것이다.

오직 작은 영향에서, 그리고 작은 ‘구성’ 또는 부가적으로 요구된 ‘실행시간’ 자원

변경 관리는 그러한 변경에 대해 권한을 위임하고, 계획해야 한다. 그러나 이것들은 기록되어야 하며,

그 결과는 다음과 같다.

! 기록과 작업 형태를 확인할 수 있다.

! 각 서비스(고객 영역 등)를 위해 정확하고 완전히 비용을 사용할 수 있다.

! 반복적인 Change, 뒤따르는 변경, 그리고 연관된 문제/인시던트 범위를 확인할 수 있다.

요약에서 모든 변경을 기록하는 것은 반복되는 작업을 발견하고 제거의 허용을 통해, 고객에게 효율적

이고 효과적인 서비스를 제공하도록 돕는다. 만일 변경 관리가 그러한 변경에 권한을 주는 것에 대해

어떤 의구심을 가진다면, 변경은 더 폭넓은 판단을 위해 CAB의 구성원에게 형식에 구애받지 않고 위

탁할 수 있다.

중요한 영향, 중요한 구성 또는 요구되어지는 실행시간 자원

긴급한 변경 구성을 위해, 변경 관리는 CAB의 구성원과 상의할지 CAB/EC를 소집해야 할지 결정해야

한다. 어떤 회의에 앞서 모든 문서는 영향과 자원 판단을 위해 배포되어야 한다.

중요한 영향, 매우 큰 규모의 구성 또는 요구된 실행시간 자원 또는 그 조직의 다른부분에 있

을만한 영향

중요한 변경이 IT, RFC에 직접 관계되는 곳은 조직의 최고 관리 위원회 또는 토론과 정책 결정을 위한

다른 적절한 부서에 위탁해야 한다. 그러한 변경은 아마도 CAB을 통해 계획되고 실행되어진다.

8.5.5. CAB 회의

대면 회의는 필수적인 것은 아니다; 많은 위탁 과정의 판단은 컴퓨터 지원툴 또는 email을 통해 전자적

으로 처리될 수가 있다. 단지 매우 복잡하고, 높은 위험성 또는 높은 영향의 경우에는 정식 CAB 회의

가 필수적이다. 그러나 규칙적인 회의 계획을 가지는 것은 좋은 생각이다. (매 6개월, 또는 중요한 프로

젝트가 결과물을 전달하기도 되어있을 때)

그 모임은 정식 검토와 승인된 변경의 종료를 제공하기 위해, 미해결 변경의 검토와 어떤 긴급한 중요

변경의 토의를 위해 사용될 수 있다. 회의는 기본적인 협의사항을 가지고 적절한 곳에서 있어야 한다.

- 184 -


표준 CAB 협의사항은 다음의 검토를 포함해야 한다.

! 실패한 변경, 복원 변경은 인시던트 관리, 문제 관리 또는 변경 관리에 의해서 CAB에 관계없

이 적용된다.

! CAB 구성원에 의해 RFC는 판단된다.

! 변경 검토

! 제안된 변경의 변경 관리 방법은 토의 기간 동안에 수정된다.

! 정해진 기간동안 변경 관리 성공/수행에 대한 토의가 이루어진다. (예: 변경 관리 프로세스에

의해 발생된 비즈니스 이익의 검토)

CAB 회의는 구성원의 시간에 잠재적인 큰 간접비용을 나타낸다.

그러므로 모든 RFC는 FSC, PSA와 함께 미리 배포되어야 한다. 그리고 CAB 구성원에 대해서는 참석

을 하거나, 대리인을 보내거나 또는 어떤 의견을 변경 관리를 통해서 보내는 것과 같이 유연성 있게

적용되어야 한다. 적절한 문서들은 사전에 배포되고 영향과 자원판단을 위해 CAB 구성원(그리고 변경

관리 또는 CAB 구성원에 의해 요청된 사람들)에게 허용되어야 한다.

몇몇 상황에서, CAB 구성원이 고려할 사항을 위해 문서들을 가져가기 전에 더욱 자세한 설명을 위해

CAB 회의에서 RFC들을 표로 만드는 것이 더 바람직할 것이다. 변경 검토는 단락 8.5.12에 토의된다.

8.5.6. 영향과 자원 평가

RFC를 위한 영향과 자원평가를 위탁할 때, 변경 관리, CAB, CAB/EC 또는 이 절차에 관계된 이들(변경

관리 또는 CAB 구성원에 의해 추천된)은 다음 항목들을 고려해야 한다.

! 변경이 고객의 비즈니스 활동에 미치는 영향

! SLA에 정의된 것과 같이, 인프라스트럭쳐와 고객 서비스 그리고 용량과 성능, 신뢰성, 복원력,

긴급 계획, 보안에 대한 영향

! 같은 인프라스트럭쳐(또는 소프트웨어 개발 계획)에서 실행되는 다른 서비스들에서의 영향

! 조직안의 non-IT 인프라스트럭쳐에서의 영향 – 예를 들어 보안, 오피스 서비스, 수송, 비즈니

스 – 고객 헬프데스크

! 변경을 실행하지 않는 영향

! 변경 구현이 요구된 IT, 비즈니스 그리고 다른 자원, 가능성 있는 비용, 요구된 사람의 수와 가

용성, 경과된 시간, 그리고 요구된 어떤 새로운 인프라스트럭쳐 요소

! 현재 FSC와 PSA

! 만일 변경이 구현되었다면, 추가적으로 계속 요구되는 자원

CI의 명세서에 영향을 주지 않는 하드웨어 수리와 같은 어떤 변경은 사전에 영향판단이 필요치 않을

것이다. 그러나 소프트웨어 오류를 수정할 목적의 변경은 형식적인 RFC와 영향 판단의 대상으로 추천

된다.

- 185 -

서비스관리를 위한 레퍼런스 요약집IT ITIL 변경의 판단과 잠재적인 이익의 기반 위에서 평가 담당자들 각각은 그들이 변경을 허가하는지 어떤지

에 대해 명시해야 한다. CAB 구성원은 또한 그들이 변경 관리에 의해 할당되는 우선순위를 결정해야

하며, 그들이 필수적이라 생각하는 사항들에 대해 토론이 이루어져야 한다.

CAB 장점

변경의 우선순위 판단을 기반으로, CAB 구성원은 변경 진행을 결정하기 위한 회의를 가져야 한다.

CAB은 인시던트의 조치로 실행된 변경을 알려야 하며, 후속조치로 추천할 기회가 주어져야 한다.

CAB는 오직 조언을 위한 핵심이라는 점을 명심하라. 만일 CAB에서 추천이 동의되지 않는다면, 변경을

허가할지 안할지에 대한 최종 결론은 관리자(대표자와 같은 IT 관리자 또는 서비스 관리자, 또는 변경

관리자)의 책임이다. 변경 관리 절차는 RFC 종료 권한이 있는 사람의 임명을 보다 명확히 해야 한다.

변경의 특성에 따라, 서비스 수준 동의 참조도 필요할지도 모른다. 어떤 경우에, 고객의 포기는 몇몇

지점에서 요구될 것이다.

8.5.7. 변경 승인

당신이 일하는 조직(큰 규모에서)은 변경의 승인 방법이 규정되어 있을 것이다. 계층적 구조는 아마 변

경 승인의 많은 단계를 강조한다. 하지만 단순한 구조가 더 합리적인 접근을 허용할지도 모른다.

승인 획득

정식 승인은 변경 권한으로부터 각 변경을 위해 획득되어야 한다. 변경 권한은 변경 관리, 서비스 관리

자, 또는 몇몇 다른 추천된 사람 또는 그룹에게 있을 것이다. 낮은 위험의 변경을 위해, 변경 권한은

각 변경을 개별적으로 허가하는 것보다는 허가된 변경을 알리는 것을 선택할지도 모른다. 변경을 위한

승인의 단계는 변경의 크기 또는 위험에 의해 판단되어야 한다. 예를 들면, 큰 기업에서 여러 분산된

그룹에 영향을 주는 변경은 아마 높은-단계의 변경 권한에 의한 승인이 필요할 것이다.

변경 관리 프로세스에는 3가지 주요한 승인 과정이 있다. 재정상의 승인, 기술적 승인, 비즈니스 승인.

재정상의 승인은 변경 비용의 판단과 제한된 예산에서 승인되어진 것 또는 변경 승인을 위해 설정된

이익 표준 비용을 나타낸다. 기술적 승인 단계는 변경이 실행될 수 있고, 분별이 있고, 비즈니스에 제

공되는 서비스에 부적당한 손실없이 수행될 수 있다는 확신이다. 만일 기술적 전문가가 비용 평가(많은

조직에서의 경우)를 제공할 것을 요구 받는다면, 이것은 재정상의 승인보다 우선되는 것이 필요하다.

고객 승인은 비즈니스 관리자가 변경 제안서와 그들 비즈니스에서 영향을 확실히 하기 위해 필요하다.

8.5.8. 변경 스케쥴링

비록 한번에 하나의 변경을 실행하는 것이 더 나을지라도, 예를 들어 오류발생의 분석을 단순화하기

위한 – 이것은 보통 실제적이진 않다. 예를들어, 하드웨어 변경은 아마 그것을 지원하기 위한 운영 시

스템 변경을 요구한다. 어플리케이션 소프트웨어는 ‘한번에 하나의 변경’의 정책은 비실용적으로 느리

기 때문에 빠른 변경이 필요할지도 모른다. 또는 간단한 소프트웨어 변경은 아마 새로운 자료관리, 절

차 그리고 훈련의 동시적인 도입이 필요할지도 모른다.

- 186 -


또한 그 이상의 예로서, 동시에 발생하는 변경의 수는 새로운 표준 데스크탑 구성의 도입에서 고유한

부분이라 생각해라. 변경이 동시에 발생하는 곳에서 문제 발생했을 경우에 그 전체가 복구될 수 있도

록, 그들은 릴리즈에서 패키지화 해야 한다. 패키지된 릴리즈는 이 관점으로부터 단일 변경처럼 고려되

어야 한다. 비록 그것이 많은 개개의 변경을 포함할지 몰라도, 실행 또는 복구 어느쪽이든 하나의 변경

이기 때문이다.

어디든 가능한 곳에서, 변경 관리는 릴리즈를 목표로 승인된 변경을 계획하고, 자원의 할당을 제시하여

야 한다. 변경 관리와 릴리즈 관리 프로세스 사이에는 명백한 연속성이 있다. 릴리즈 관리 프로세스는

변경 관리 프로세스에 영향을 준다. 특히, 인프라스트럭쳐에서 새롭거나 변경된 소프트웨어와 하드웨어

의 도입에 따른 표준 변경의 개발과 유지에 대한 역할을 가진다.

릴리즈는 변경의 명세화인 것처럼, 변경 프로세스는 합의되고, 문서화되고 그리고 유지된 릴리즈 프로

세스 아래에서 릴리즈를 시작한다.

관리할 수 있는 작업에 대한 릴리즈의 크기를 제한하는 것은 중요하다. 특히 그것은 어떤 릴리즈가 완

벽히 구현될 가능성이 거의 없는 경우에 더욱 중요하다. 그것은 더욱 커다란 릴리즈를 필요로 하며, 더

욱더 많은 새로운 오류의 확인과 설명을 필요로 할 것이다. 또한 새로운 릴리즈에 대하여 서비스 데스

크와 같은 지원 활동이 필요할 것이다.

변경 관리 결과물로 FSC가 추천된다. FSC는 이전에 합의된 기간위에서 구현을 위해 권한이 주어지고,

릴리즈가 할당되어진 모든 변경의 세부사항을 포함해야 한다. 조직은 짧은 기간에 대한 분명한 계획과

긴 기간에 대한 대략적인 계획을 세워야 함을 주의해야 한다. 이 모든 것은 FSC에 포함되어야 한다.

다음 2년동안 계획되는 변경의 세부사항은 또한 포함되어야 한다.

FSC는 모든 고객과 사용자, 대표자, 어플리케이션 개발자, 서비스 데스크를 포함하는 서비스 직원, 다

른 관계된 부분별로 분류되어야 한다. 서비스 관리 이외의 FSC의 분류는 서비스 데스크 또는 고객 관

계 프로세스를 통해 이루어져야 한다.

제안되어진 변경과 그들의 타이밍이 많은 영역(서비스 관리 안과 밖)에서 실행과 계획에 영향을 미치기

때문에 변경 계획은 폭넓게 분류되어야 한다. 서비스 관리 외측 지원은 보통 서비스 데스크와 서비스

수준 관리, 고객 관계 관리를 통해 이루어질 것이다. 서비스 관리내에, 그 계획에 대한 접근은 모든 프

로세스에 제공되어져야 한다. 변경 관리는 이 정보를 특정 영향(용량 관리, 가용성 관리 또는 다른 프

로세스에서 예상되는 영향)을 사전에 발견할 수 있는 프로그램을 통해 강화해야 한다.

고객의 요구와 최종 사용자의 요구를 명심하면서, 어떤 계획을 세움에 있어 조직의 비즈니스 요구의

고려가 가장 중요하다.

- 187 -


8.5.9. 변경 구성, 시험, 실행

공인된 RFCs는 변경의 구현을 위해 관련된 기술그룹에 전달될 것이다. 이것은 다음을 포함한다.

! 새로운 생산 모듈을 구성

! 한 개 이상의 소프트웨어 모듈들의 새로운 버전 구현

! 장비나 서비스의 외부 구입

! 하드웨어 변경을 준비

! 새로운 문서나 추가적인 문서를 구성

! 사용자 훈련용 개정안을 준비

변경 관리는 릴리즈 관리와 라인 관리제어 의해 지원되며, 이러한 행동들이 계획대로 실행되고 완성되

는 것을 확실하게 하는 역할을 한다. 릴리즈 관리는 어플리케이션 소프트웨어 개발팀들이 구성관리 설

치와 복구를 제공할 때와 같이 작은 변경에서 더 중요한 역할을 가지고 있다.

본래의 구성요소에서 사용되어졌던 표준과 방법이 변경에서 재사용되는 것을 확실히 하는 것은 중요하

다. 만일 변경 실행 후에 에러가 발생한다면 복구 과정은 서비스에 대해 최소한의 영향을 미치도록 빠

르게 실행되어야 하기 때문에 복구 과정은 각각의 변경을 위해 미리 준비되고 문서화 되어야 한다.

변경이 서비스 품질에 반대의 영향을 주는 것을 막기 위하여, 변경이 완전히 미리 테스트되는 것이 추

천된다.(어디에서 가능한 복구 과정을 포함)

테스트는 다음과 같은 변경의 측면들을 포함해야 한다.

! 성능

! 보안

! 유지가능성

! 지원가능성

! 신뢰성/유용성

! 기능성

이 권고는 끊임없는 기술 업데이트가 일어나는 데스크탑 환경에 특히 관련된다. 여러 경우에서，이것

은 개개의 ‘테스트 환경’을 필요로 할 것이다. 미리 모든 변경들을 테스트하는 것이 항상 가능하거나

정당하다고 인정되는 것은 아니다:그렇지만 보통의 테스트에 추가하거나 또는 보통 테스트 대신에 가

상적인 변경의 영향을 평가하는 모형제작 기술을 사용하는 경우에는 가능할 지도 모른다.

변경 관리는 가능한 모든 변경이 완벽하게 테스트되는 것을 보증하기 위해 감독하는 역할을 맡는다.

완전히 테스트되지 않은 변경들를 포함하는 모든 경우에는 실행 도중 각별한 주의가 요구된다. 변경

관리는 완전한 테스트 없이 설치된 변경에 대한 위험성을 판단해야 한다. 테스트는 또한 다른 인프라

스트럭쳐의 영역들이 변경에 의해 반대의 영향을 받지 않는 것을 확실히 하기 위하여 충분한 복구 테

스트를 포함해야 한다.

- 188 -


변경 또는 어플리케이션이 실행되고 있어도, 테스트를 멈출 필요가 없다는 것을 기억하라. 정상적인 운

영과 서비스 사용은 먼저 테스트되고 먼저 사용될 것이다. 그러므로 실제 사용에 있어 명백한 결함이

발견되기 전에 좀더 많은 행위를 고칠 수 있도록 비 정상적이고 예기치 못한 미래 상황에서 변경의 실

행과 성능 테스트하는 것은 중요하다.

실행되고 있는 서비스에 있는 가장 작은 영향이 있을 때 그런 변경의 실행은 계획되어야 한다. 지원

직원은 어떤 인시던트가 발생해도 신속히 처리할 수 있도록 가까이에 있어야 한다. 제한된 환경(예를들

면, 사용자의 운영그룹을 위한)에 그런 변경을 도입하는 것이 가능한 곳에서 이러한 접근은 고려되어야

한다

비록 실제 이행이 다른 사람들의 책임일 것일 때와 동등한 역할일지라도 변경 관리는 변경이 계획대로

수행되도록 확실히 해야 할 책임을 가지고 있다.(e.g. 엔지니어는 하드웨어 변경을 구현할 것이다.)

8.5.10. 긴급 변경

일반적으로 더 혼란을 일으키고 실패할 수가 있기 때문에 긴급 제안된 변경의 수는 최소로 유지되어야

합니다. 변경을 구성하고 테스트하기 위한 자원의 가용성을 고려하고, 요구되어진 모든 변경은 예측되

고 계획되어야 한다. 그럼에도 불구하고, 긴급한 변경이 필수적인 경우가 발생할 것이고 보통의 변경 관리를 희생하지 않

고, 그런 과정이 그것들을 신속히 처리하도록 고안되어야 한다. 그런 과정은 그림 8.5에 볼 수 있으며

다음에서 설명한다.

- 189 -


그림 8.5 – 긴급 변경 실행 과정

- 190 -

서비스관리를 위한 레퍼런스 요약집IT ITIL 인시던트 제어 직원, 컴퓨터 작동과 네트워크 관리 직원은 인시던트의 어떤 형태(예, 하드웨어 실패)를

피하기 위해 변경 관리의 권한 없이 위임하였을 것이다.

그러한 회피는 CI의 명세서를 변경하지 않는 실행과 소프트웨어 오류 수정을 하지 않는 실행에 대해

제한되어야 한다. 소프트웨어 오류에 의해 발생된 인시던트를 피하기 위한 더 좋은 방법은 잠재적으로

위험한 계획없는 변경의 시도보다는 이전의 신뢰된 상태 또는 버전으로 복구하는 것이다. 변경 동의는

아직은 필수적이다!

8.5.11. 긴급 변경 구성, 테스트, 실행

승인된 변경은 구성을 위해 관계된 기술적 그룹에 할당된다. 변경 관리는 적절한 기술 관리자와의

협력으로, 혹시 직원을 집으로부터 호출한다 하더라도 충분한 직원과 자원이 이 일에 사용가능 하도록

확실히 해야 한다. 승인되고 지원되는 절차와 동의는 이것이 허용되기 위해 적절하여야 한다. 긴급

호출의 비용은 서비스 관리에서 승인되는 실행 비용에 포함되어야 한다. 긴급 변경이더라도 복구

계획은 여전히 고안되어야 한다.

긴급 변경은 가능한 한 많은 테스트가 실행되어야 한다. 완전하게 테스트 안된 변경은 가능하다면

실행되어서는 안된다. 변경이 잘못될 때, 그 비용은 일반적으로 적절한 테스트 비용보다 더 크다는

것을 알 수 있을 것이다. 변경이 실행된 이후에도 여전히 테스트에는 장점이 있다는 점을 다시한번

기억하라.

변경 관리는 어떤 임박한 변경에 대해 가능한 많은 경고를 미리 고객과 사용자에게 주어야 한다.

이것은 서비스 데스크 또는 다른 헬프 데스크를 통해 이루어져야 한다.

특히 적절한 테스트가 이루어지지 않은 어떤 긴급 변경이 실행되었을 때, 어떤 인시던트가

발생하더라도 변경 관리는 적절한 기술적 존재가 사용 가능하도록 확실히 해야 한다.

만일 한번 실행된 변경이 긴급한 문제를 수정하는데 실패했다면, 아마도 반복해서 시도해야 할 필요가

있다. 변경 관리는 비즈니스 요구가 첫째 중요성으로 아직 남아있다는 점을 확실히 해야 할 책임이 있

다. 각 반복이 이 섹션에서 기술된 방법으로 제어되는 것은 중요하다. 변경 관리는 실패한 변경이 신속

하게 복원되도록 확실히 해야 한다.

만일 긴급 변경의 너무 많은 시도가 실패한다면, 거기에는 설명이 필요한 세가지 의문이 있다.

1. 문제는 정확히 분석되었는가?

2. 제안된 수정방법은 적절하게 테스트 되었는가?

3. 솔류션은 정확히 구현되었는가?

그러한 상황에서, 완벽히 테스트된 변경을 허용하기 위해서 또는 서비스를 임시적으로 중지하고 그 때

변경을 실행하기 위해 아마 부분적인 서비스를 제공하는 것이 더 나을 것이다.

- 191 -


긴급한 행동이 완료되어졌을 때(예: 밤샘 작업 또는 주말 작업), 아마 제때에 모든 변경 관리 기록의

업데이트가 가능하지는 않을 것이다. 그러나 그 기간동안에 기록되어지는 것은 필수적이다. 그리고 변

경 관리는 모든 기록이 가능한 한 빨리 완료되도록 확실히 해야 할 책임이 있다. 이것은 가치있는 관

리 정보가 소실되지 않도록 확실히 하기 위해 매우 중요하다. 한 예는 변경의 ‘성공’, ‘실패’, ’부분적 실

패’를 정의하는 속성에 대한 업데이트일 수도 있다. 업데이트는 아마 프로젝트 팀, 릴리즈 또는 어플리

케이션 소프트웨어 개발 관리자와의 협력을 통해 변경을 지원하는 책임있는 사람에 의해 실행되어야

한다. 그리고 실행 후 검토 보다 더 나중에 발생해서는 안된다.

8.5.12. 변경 검토

변경 관리는 미리 정한 기간이 지난후에 모든 실행된 변경을 검토해야만 한다. 이 과정은 아마 CAB

구성원과 관련될 수도 있다; 변경 관리는 검토과정에서 그들의 지원이 필요할 수도 있다.

변경 검토는 CAB 구성원의 정보와 어떤 필수적 행동에 대한 합의를 위해

CAB 회의에서 논의될지도 모른다.

그러한 검토의 목적은 다음을 확립하는 것이다.

! 변경은 기대된 영향과 그것의 목표의 성취

! 사용자와 고객이 그 결과에 대해 만족 또는 어떠한 결점의 확인을 위해

! 기능성, 가용성, 용량 / 성능, 보안성, 유지성 등에서 예상되지 않았거나 바라지 않은 영향을

가지지 않기 위해

! 변경을 실행하기 위해서 사용되어진 자원의 계획

! 실행계획의 정확한 작성

! 변경은 정시에 그리고 정해진 비용에서 실행된다.

! 만일 필요하다면, 정확한 복구계획 기능

어떤 문제와 불일치는 앞으로의 판단 과정 향상을 위해 CAB 구성원, 영향 판단 담당자, 제품 기관과

릴리즈 기관에게 알려야 한다.

변경이 그 목표를 이루지 못했던 곳에서, 변경 관리(또는 CAB)는 수정된 RFC를 포함한 뒤따르는 실행

이 필요한지 결정을 해야 한다.

만일 검토가 만족스럽거나 본래의 변경이 버려진다면, RFC는 로깅 시스템에서 정식으로 마쳐져야 한다.

8.5.13. 효율적이고 효과적인 변경 관리 프로세스의 검토

변경 관리는 어떤 문제의 수정 또는 비효과적 변경의 결과인 변경 관리 시스템에서의 비효율적 발생에

대한 뒤따르는 실행을 구현하여야 한다. 변경 기록 검토는 아마도 문제 관리와 같은 다른 과정에서, 시

스템 구성요소의 신뢰성에서, 직원이나 사용자의 절차 또는 훈련에서 문제를 보여줄 것이다. 이 문제는

변경 관리 보고서에서 강조되고 관계된 관리자에게 보고되어야 한다.

- 192 -

서비스관리를 위한 레퍼런스 요약집IT ITIL 서비스 관리는 효율성과 효과성을 위해 변경 관리 과정을 주기적으로 검토할 것을 추천한다. 그러한

검토는 계획이 정확하게 실행이 되고 그 프로세스가 의도되어진 대로 작용되도록 확실히 하기 위해,

변경 관리 과정이 실행된 이후에 간단히 실행되어야 한다.

어떤 문제라도 소스까지 검토되어야 하고, 가능한한 빨리 수정되어야 한다. 그 후에 변경 관리 과정에

대한 규칙적인 정식 검토가 최소 6개월마다 이루어져야 한다. 또한 변경 관리자는 계속적으로 변경 관

리 과정의 효율성과 효과성을 판단해야 한다.

어떠한 검토에서도, 다수의 RFC가 변경 관리 과정의 문제를 반드시 가리키는 것은 아니라는 점을 유

의해야 한다. 그것은 단지 임시적인 시스템을 반영하는 것일 것이다. 효과적인 변경 관리 과정의 가장

주된 지침은 RFC들의 올바른 혼합의 유지이다.

효과적인 변경 관리 과정의 다른 지시는 다음을 포함한다.

! 부실한 변경 관리로부터 결과되어진 서비스 질에 대한 반대영향의 감소

! 다수의 인시던트에서 변경 실행 추적 감소

! 다수의 변경에서 복구의 감소

! 다수의 긴급 변경 의 감소

! 변경 관리와 구성 관리 시스템의 참조없이 변경을 구성하지 않음

! FSC와 실제 구현된 변경과의 상호작용의 폐쇄

! 백로그에서 높은 우선순위 RFC의 감소, 그리고 증가하고 있지 않은 백로그의 크기

! 자원 판단이 실제 사용된 자원과 비교될 때, 정확한 자원 판단의 증거

! RFC의 규칙적인 검토와 변경 실행, 어떠한 백로그 검토의 명백함

! 비즈니스의 이익과 고객의 만족인 변경의 성공적인 실행

! 합리적으로 거절된 RFC의 감소

이 항목은 변경 관리 과정의 효율성과 효과성의 측정을 위해 사용될 수 있다.

효율성 측정에서, 직원 비용의 단위당 성공적으로 실행된 변경의 양은 필수적으로 고려되어야 한다. 예

를들면, 판단 담당자, 구성자, 실험자의 비용

이것은 아마도 절대적인 단위로 판단하기는 어렵다. 그러나 그것은 일반적으로 전반적인 효율성 증가

에 대한 관찰이 가능하다.

8.5.14. 역할과 책임

분명히, 변경 관리 역할은 효율적인 실행을 위해 책임과 함께 정의되어야 한다.

변경 관리 역할을 위해 제안되어진 책임 리스트는 다음과 같다.

변경 관리자

변경 관리자의 주된 의무는 다음과 같다.

- 193 -


! 모든 RFC에서 실행자와 협력하여, 수신하고 기록하고 우선순위를 할당해라. 전체적으로 비실

용적인 RFC는 거절해라.

! 회의에 앞서 이전 고려사항의 허용을 위해, CAB 회의를 위한 모든 RFC 리스트와 협의사항을

만들고, CAB 구성원에게 모든 RFC를 배포하라.

! 회의에 오는 사람들을 결정하라. 사람들의 전문적 지식의 범위와 무엇이 변경될 것인가?

! 모든 긴급 RFC를 위해 긴급 CAB 또는 CAB/EC 회의를 소집하라.

! 모든 CAB와 CAB/EC 회의에 권한을 주어라.

! CAB 또는 CAB/EC에 의해 주어진 충고에 대해 고려한 후에, 수락할 수 있는 변경을 허용하라.

! 서비스 데스크를 통해 FSC를 발행하라.

! 계획에 따라 변경 구성, 테스트, 실행을 조정하기 위해, 모든 필수적인 부서와 연락하라.

! 문제를 수정하거나 서비스 질을 향상시키기 위해 기회를 잡는 어떤 행동을 포함하여, 발생하

는 모든 진행과 함께 변경 로그를 업데이트 하라.

! 모든 실행된 변경이 그들의 목적을 만족하는지 확실히 하기 위해 검토하라. 복구 또는 실패되

었는지 알아보라.

! 행동을 기다리고 있거나 고려를 기다리고 있는 모든 두드러진 RFC를 검토하라.

! 어떤 경향 또는 발생된 명백한 문제를 결정하기 위해 변경 기록을 분석하라. 관련되는 부서와

함께 수정하라.

! RFC를 마쳐라.

! 규칙적이고 정확한 관리 보고서를 만들어라.

변경 조언 위원회(CAB) 설립

만일 CAB가 설립이 된다면, 적당한 권한을 가져야 한다.(예, 규칙적인 회의, 영향의 범위, 프로그램 관

리와 관련)

적절한 대표자를 확실히 하기 위해, 이 위원회의 구성원은 다음 영역의 대표자를 포함해야 한다.

! 변경에 의해 영향받는 고객

! 서비스 관리 프로세스에서의 모든 분야의 대표자

! 어플리케이션 개발 팀

! 상위의 사용자 또는 그들의 대표자

변경 관리자는 이 위원회의 의장직과 같으며, 변경 관리 또는 구성 관리 지원 직원은 비서관과 같다.

변경 조언 위원회(CAB)

CAB 구성원의 주된 의무는 다음과 같다.

! 모든 제출된 RFC의 검토하라. 가능한 영향, 실행 자원, 모든 변경의 비용에 대한 세부사항을

제공하고 결정하라.

! 관련된 모든 CAB 또는 CAB/EC 회의에 참석하라. 협의사항에서 모든 변경을 고려하고 권한

있는 변경에 대한 의견을 내어라. 모든 변경 계획에 참석하라.

- 194 -


! 상담을 위해 사용할 수 있는 긴급한 변경은 필요하다. (CAB/EC만)

! 제안된 긴급 변경에서 변경 관리에 대한 조언을 제공하라.

- 195 -


8.6. 계획과 구현

변경 관리 프로세스는 조직의 규모에 적절해야 하며, 너무 절차가 복잡한 프로세스를 만드는 것은 행

동의 효율성을 감소시킬 것이다. 다시 한번 이 충고를 명심하라.

8.6.1. 변경 관리자 역할

기존의 변경 관리 또는 구성 관리 시스템이 없는 곳에서는, 첫번째 단계로 변경 관리를 위한 책임을

할당해야 한다. 책임 리스트는 단락 8.5.14에 주어졌다. 지원 직원이 아마 필요할 것이다. 변경 관리는

더 큰 구성 관리 프로세스의 일부로 실현되는 곳에서, 만일 규모가 허락한다면 변경 관리자와 구성 관

리자의 역할은 결합되어진다.

변경 관리자의 첫번째 일은 변경 관리 처리의 목표와 그 효율과 효과를 평가하는 방법에서 서비스 관

리와 일치한다．변경 관리자의 개인의 목적들과 목표들은 변경 관리 프로세스의 효율과 효과에 기반해

야 한다

관리와 관련하여，변경 관리자의 다음 작업은 변경 관리와 구성 관리 프로세스의 범위를 정하는 것이

다. 계획들은 하부 구조와 다른 변경 관리 시스템들이 서로에 대해 효과적으로 연결되는 것을 확실하

게 하여야 한다. 조직의 다른 부분들의 변경 관리 권한들은 이 연결들을 제공해야 하며, 그리고 관리

책임은 그들이 일을 하는 것을 확실하게 하기 위해 필요할 것이다.

8.6.2. 변경 관리 시스템에서의 결정

변경 관리와 구성 관리 시스템이 문서기반인지 툴기반 시스템인지는 초기에 결정하는 것이 필요하다.

문서기반 시스템들은 가장 작은 시스템들을 제외하고 모든 것에 부적당하기 때문에 만일 사용할 수 있

다면, 사용되는 소프트웨어 지원 툴의 몇몇 형태가 추천된다.

시작과 변경의 구현은 통합된 구성 관리 시스템 또는 통합된 IT 서비스 관리 시스템의 제어 아래 이루

어질 것이 추천된다. 그러므로, 변경 관리와 구성 관리를 통합，개선，사용자 사양에 맞추는 툴을 선택

하는 것은 바람직하다. 그러므로 변경 관리와 구성 관리 통합 툴 또는 개선이나 사용자 사양에 맞출

수 있는 툴을 선택하는 것이 타당하다.

지원 툴, 데이터(구성목록 데이터, 변경 책임 등) 획득, 그리고 직원 훈련과 익숙한 지원툴들은 구현하

기 전에 완료되어야 한다.

8.6.3. 시스템 검토 계획

계획은 단락 8.5.12와 8.5.13 그리고 섹션 8.7에 기술된 변경 관리와 구성 관리 검토, 측정기준, 관리

보고서와 감사를 위해 만들어져야 한다.

- 196 -


8.6.4. 실행 계획

변경 관리 실행 계획은 구성 관리와 릴리즈 관리 계획과 동시에 구현되어야 한다. (비록 단계적인 실행

이 실제 일어날지도 모르지만 이상적으로는, 모든 서비스 지원 프로세스는 시작부터 전체적으로 고려

되어야 한다.)

계획들은 시스템과 결합되어진 변경 관리와 구성 관리를 포함해야 한다. 이 계획들은 변경 관리 직원,

다른 직원과 사용자를 위한 훈련 계획은 물론이고, 어떤 소프트웨어 툴을 위한 설치와 테스트 계획을

포함해야 한다. 또한 변경 관리 시작을 위한 준비로 홍보 자료와 세미나들이 준비되어야 하며, 직원과

사용자 사이에 변경 관리의 이익이 강조되어진다.

8.6.5. 견본

의존성 (종속물, 부속 건물, 별관)

단락 8.6.4에서 언급되어진 것 같이 문서 기반 변경 관리 시스템은 대부분의 시스템에서 부적당하다.

그리고 보통은 지원 툴이 필요하다. 섹션8.8은 변경 관리 툴을 위한 요구사항을 설명하며, 현재 사용가

능한 툴의 몇 가지 정보를 준다.

지원하는 많은 프로세스들은 또한 충분히 효과적인 변경 관리를 위해 필수적이다. 이것은 이책의 다른

장에 설명된 문제 관리, 구성 관리, 서비스 데스크 그리고 릴리즈 관리 프로세스를 포함한다.

관리 책임은 적절한 자원들이 사용가능하게 확실히 하기 위해 필수적이다. 그리고 또한 변경 관리 프

로세스의 우회를 막는 것과 같은 모든 서비스 관리 직원 사이에 생기는 규칙의 적절한 수준을 확실하

게 하여야 한다.

직원 교육은 새로운 변경 관리 과정들에서，그리고 지원 툴들의 이용에서 필요할 것이다．CAB 회원들

은 또한 그들에게 기대되는 역할들에 대한 훈련을 필요로 할 것이다．

감사는 그것의 특별한 과정에 따라 변경 관리 프로세스의 감사 프로세스를 단순화하기 위해 변경 관리

툴과 과정을 통해 만들어져야 한다.

과정

병렬 변경 관리 시스템이 실제적으로 실현되긴 힘들다. 그리고 ITIL 기반에서 변경 관리가 실행할 때,

어떤 이전 시스템을 제거하는 것은 추천되어진다. 몇몇 경우에，새로운 방법을 도입하고 확장하는 동

안 기존의 시스템들을 멈추어야 할지도 모른다. 기존의 non-ITIL-변경 관리 시스템 또는 변경 관리 없

이 구성되어진 시스템의 변경은 실행할 때 새로운 시스템으로 옮겨놔야 한다.

새로운 변경 관리 시스템의 어떤 초기적 어려움들은 실행 후 가능한 한 빨리 확인되고 해결되어야 한

다. 어떤 지원툴들은 ‘실제 실행’이전에 완전히 테스트되어야 한다. 그러나 만일 실행 이후에 어떤 문제

- 197 -


가 있다면, 비록 느리고, 비효율적일 것 같다 해도 수동적인 방법으로 돌아가는 것도 일시적으로 필요

할지도 모른다.

사람

IT 관리는 변경 관리 시스템을 권장하고, 정식 변경 관리에 대한 어떤 반대라도 극복하기 위해서, CAB

자원과 적절한 수준의 권한을 주는 지원이 필요하다.

사용자들의 것과 변경 관리 과정에 대한 직원들의 인식은 필수적이다.

이 과정들이 필수적이라는 것을 명백히 해야 하고，변경이 변경 관리 시스템의 밖에서 실현되는 것은

어렵거나 불가능하다.

책임의 적당한 할당은 서비스 질을 확실하게 하기 위해 필요하다. 서비스 관리자는 서비스 팀의 수뇌

이고，서비스 질에 대한 전반적 책임을 가진다. 변경 관리자는 변경 관리 과정에 주어지는 중요성의

정확한 수준을 확실히 하기 위한 서비스 관리자에 대해서 직접적인 책임이 있으며, 그에 대한 지원이

필요하다.

추적은 승낙을 확실하게 하기 위해 필요하다．독립 감사는 변경 관리 과정에 따라 확실히 하기 위한

조직의 컴퓨터 감사 그룹에 의해 규칙적으로(적어도 1년에 한번씩) 수행할 것이 추천되어진다.

계약자의 참가는 충실성을 확실하게 하기위해 요구된다. 계약자의 대표자(예를 들면, 하드웨어 엔지니

어, 환경 또는 수행유지 직원)가 조직의 변경 과정의 인식과 충실성을 확실히 하는 것은 필수적이다.

타이밍

CAB 설정 및 관계된 모두에 대한 새로운 절차의 인식, 훈련과 같은 것은 시스템이 준비될 때까지는

구현되어서는 안된다.

서비스 수준 관리와의 협력을 통해 변경 관리는 실행 시간과 날짜를 정하기 위해서 사용자 관리자 및

다른 관리자들과 연락해야 한다. 이로인해 서비스 질에서 가장 적은 잠재적 악영향을 가지게 될 것이

다. (예를들면, 낮은 작업처리 능력의 기간 동안)

만일 변경 활동의 구현 전과 구현 동안에 직접 ‘중지’하는 것을 허용하는 시간을 측정할 수 있다면, 새

로운 관리 시스템의 실행은 더욱 쉬워질 것이다. 그러나 만일 새로운 시스템이 존재하는 부적당한 변

경 관리 시스템으로부터 문제 발생을 막기 위해 도입되어진다면, 이것은 아마 가능하지 않을 것이다.

변경의 규칙적인 계획은 매우 중요할 수 있다. 심각한 고려사항은 규칙적인 ‘변경 슬롯’ – 변경은 최소

한의 영향으로 사용자 서비스(이를테면, 화요일과 목요일 18시와 20시 사이)에서 구현되어질 수 있을

때의 시간 - 의 도입에 주어져야 한다. 물론 그런 slot은 고객과 사용자가 합의하여야 한다. 만일 변경

의 테스트가 비전용 환경에서 실행된다면, 고려사항은 ‘테스트 슬롯’의 조항에 주어진다.

- 198 -


서비스 관리는 변경 관리 프로세스의 효율을 검토해야 한다. 그리고 변경 관리 시스템 직후의 변경 관

리 프로세스의 효과는 1개월에서 3개월동안 활용 후에 나타난다. 시스템이 만족할 만큼 작동한다고 확

신할 수 있을 때까지는 규칙적인 검토는 매 2개월에서 4개월 간격으로 이루어져야 한다. 그 결과, 서비

스 관리는 변경 관리 프로세스를 최소한 6개월마다 규칙적으로 검토해야 한다. 더 정식적이고 계획적

인 검토와 더불어, 변경 관리자는 계속적으로 변경 관리의 효율과 효과를 감시해야 한다.

변경 관리의 상태에 관한 관리보고의 제안된 빈도는 다음과 같다

$ 변경 관리자 : 서비스의 안정도와 질의 신뢰도에 따라, 매주 또는 더욱 빈번하게

$ IT와 상위 사용자 관리자 : 매달

$ 상위 고객 위원회 : 분기

- 199 -


8.7. 측정기준과 관리 보고

변경의 규칙적인 보고는 고객과 사용자 관리, 서비스에 대해 제공되어야 한다. 여러가지 관리 수준들은

아마도 세부적인 주간 보고서를 요구하는 서비스 관리자로부터 분기별 관리 보고가 필요한 상위 관리

위원회까지 정보의 여러 수준들을 필요로 할 것이다.

관리 보고서들에 다음 사실들과 통계량을 포함한다는 것을 고려하라.

! CI, 구성 유형, 서비스등에 의해 그 기간에 구현된 다수의 변경

! 변경의 원인 분석 (User 요청, 강화, 비즈니스 필요조건, 서비스 콜 / 인시던트 / 문제 해결, 방

법 / 훈련 개선등)

! 다수의 성공적인 변경

! 다수의 변경 문제, 원인(예를 들면, 부정확한 판단, 좋지않은 구조)

! 변경 (문제 심각 단계에서의 이상)에서 발견된 다수의 인시던트와 그 원인들(예를들면 부정확

한 판단, 좋지 않은 구조)

! RFC(그리고 발생 경향)의 수

! 구현된 변경 검토 횟수, 그리고 백로그(시간초과 이상) 검토 판단

! 어떤 CI(특별히 주의할만한 가치가 있는)와 관계된 RFC / PR의 높은 발생율과 그 원인(변경된

사용자 요구, 부실한 구성요소, 좋지 않은 구조)

! 비교를 위해서 이전(이전기간, 지난해)의 그림

! 거부된 RFC의 수

! 성공하지 못한 변경(전체적으로, 그리고 CI에 의한 중단)의 비율

! 변경 관리 프로세스에서 CI와 단계에 의해 중단된 백로그의 변경

고객과의 상담에서 관리 정보가 제출되는 방법에 대한 고려사항이 주어져야 한다. 많은 경우에서, 백분

율과 그래픽 또는 그림의 표현은 단순한 수치 데이터보다 중요하다.

정보는 변경 관리 프로세스의 효과와 효율성의 판단을 위한 기준으로 사용되어질 수 있다. 이것을 위

해, 변경 관리의 직접적인 제어 이외의 영향을 제거하는 것이 필요하다. 예를 들면, 특정 CI에 영향을

주는 빈번한 변경은 아마 아이템의 부실화의 결과이며, 변경 관리에 나쁘게 반영해서는 안된다. 마찬가

지로, 사용자의 시설들에서의 빈번한 변경들은 빠르게 변하고 있는 사용자 요구를 반영할 것이다.

- 200 -


다시한번 말하자면, BSI 출간 “A Code of Practice for IT Service Management (PD0005)“을 다음에 말하는 곳이 진술되는 곳에서 참조하라.

변경 관리 보고서들은 다음에 오는 전부 또는 일부를 포함할 수 있다.

! 변경 요구의 수

! 변경의 %와 수치

! 거부된 것

! 긴급 변경

! 변경 상태

! 실행을 기다리는 변경의 수

- 종류에 의해

- 시간에 의해

! 실행된 변경의 수

- 구성 요소에 의해

- 서비스에 의해

! 백로그 변경과 병목현상

! 변경 비용과 비용 요약

! 변경의 비즈니스 영향

! 비즈니스 지역에 의한 변경 ! CIs에서 변경의 빈도수

8.7.1. 승인을 위한 감사

이 단락은 이 장에서 방법과 조언을 수락하기 위한 변경 관리 프로세스(서비스 팀에 독립적인 조직의

컴퓨터 감사 그룹을 사용) 감사를 희망하는 조직을 위한 점검 리스트이다. 그런 감사는 최소한 매년 완

료되어져야 하고(아마 더욱 자주 요구될 것이다) 특정 문제가 나타난 곳 또는 시작시 추천되어진다.

감사는 다음 항목의 검토를 포함해야만 한다.

! 일정하지 않게 선택된 RFC – 보통, 긴급 그리고 표준 변경

! 변경 기록

! CAB 시간

! FSC

! 일정하지 않은 RFC와 실행된 변경을 위한 검토 기록

- 201 -


다음을 확실하게 점검해야 한다.

! 모든 RFC는 정확하게 기록, 판단, 행동 되어졌는가?

! FSC는 좋은 이유든 그렇지 않든 첨부되었는가?

! CAB 회의에서 발생된 모든 항목은 해결되었는가?

! 모든 변경 검토는 정시에 실행되었는가?

! 모든 문서는 정확하고, 최신이고, 완성되었는가?

- 202 -


8.8. 소프트웨어 툴

가장 작은 조직들을 제외한 모두는 모든 관계된 구성 항목들(CIs)의 저장이 가능한 구성관리 기반툴과

그들 사이의 중요한 관계성이 적용되어야 한다. 그러한 툴은 다음 기능을 가져야 한다.

! RFCs와 PRs을 쉽게 접속할 수 있는 같은 형식의 데이터베이스에 저장 능력

! RFCs, PRs 그리고 CIs 사이의 관계를 식별하는 능력

! 프로젝트에 RFCs를 연결할 수 있는 능력

! 어떤 특정 CI를 변경할 때마다 영향 받는 다른 CIs를 쉽게 확인하는 방법의 제안

! 영향받는 CIs의 ‘소유주들’에 대한 영향과 자원 판단을 위한 요구의 자동적 생산

! RFC의 제출 권한이 주어진 개인을 위해 그들의 단말기 또는 외부에서의 제출 능력

! 권한과 구현의 적절한 단계를 통해 요구들을 ‘진행’시키는 능력과 이 진행의 명확히 기록을 유

지하기 위한 능력

! 변경 관리 직원, 변경 구성자, 검사자 등이 변경 기록에 텍스트를 추가하도록 허용하는 능력

! 문제를 발생시키는 변경을 문제 프로세스에서 분명히 정의해야 한다.

! 어떤 단계에서라도 미리 정의된 시간을 초과하는 RFC에 대한 자동적 경고

! 실행된 변경에 대해 자동적으로 신속한 검토 실행

! 변경에 관계된 동향 정보와 자동적 관리

! 변경을 구성하는 능력

! FSC의 자동 생산

! 프로세스 / 워크플로우 기능

다양한 단계에서 통합되는 모든 5개 서비스 지원 프로세스에 툴은 사용 가능하다. 많은 환경에서 변경

기록을 하기 위해 사용되어지는 일반 PC-기반 데이터베이스와 스프레드시트 패키지를 제외한, 통합된

툴셋은 추천되어진다.

- 203 -


8.9. 새로운 기술의 영향

8.9.1. 비즈니스 범위

기술에 즉시 초점을 맞추기보다는 오히려, 중대한 비즈니스 프로세스를 보호하고 강화하는 변경 관리

의 역할을 고려하는 것이 더 좋다. ‘비즈니스 전망’에서 그림 8.6은 IT 비즈니스를 위한 주된 딜레마를

설명한다. 변경 관리는 이전의 그리드의 좌하 사분 구간과 연관되었다. 거기서 IT와 비즈니스는 폭넓게

관계된다. 더욱이, IT는 변경(신기술)을 야기시키거나 변경을 가능하게 할 수 있으며, 그와 동시에 모든

IT 비즈니스는 늘어난다. 조직 전반에 대한 변경을 관리하는 것은 더욱 어렵게 되고 있으며, 프로그램

과 프로젝트를 관리하는 방법은 정교하게 나오고 있다. 그래서 BSI, OGC 등에 의해 지지되는 변경 관

리 프로세스는 이 관리 문제의 개선을 도와야 한다.

그림 8.6 – 변경의 비즈니스 전망

그림 8.7은 우리가 구성 관리 제어에 사용해야하는 4가지 주요한 요소들을 나타낸다. 몇 년전에, John

Zachman(미국의 구성 관리 전문가)은 만일 IT가 항공계, 공학계와 같은 구성 관리 전문가를 희망한다

면, 비즈니스와 IT 프로세스를 제어하기 위해 지금까지와는 전례가 없던 수준으로 상세하게 정의되어야

한다고 제안했다.

- 204 -


그림 8.7 – 변경 관리와 구성 관리 제어의 확장 범위

구성 관리(그리고 변경 관리)의 영향은 비즈니스와 IT 분야를 통해 확장될 것이며, 큰 이익을 가지고

올 것이다. 그러나 또한 비즈니스로부터 중요한 범위들에 대해 전략적인 투자를 요구하고 있다. 그 결

과, 주요한 변경의 관리에서 충분히 통합되고 영향력이 있는 변경은 점점 중요하게 될 것이다. 이미 비

즈니스 변경 프로그램과 프로젝트(예를 들면 PRINCE2) 관리를 위한 투자가 이루어지고 있음을 볼 수

있다.

8.9.2. 기술

IT Infrastructure Library가 처음 발표되었을 때, 기술의 급속한 성장에 의해 발생되는 영향에서, 변경 관

리의 초점은 변경과 관련되어 증가하는 다수의 IT에 대한 제어에 집중되었다. 수 년내에, 비즈니스는

기술의 빠른 성장이 조직의 비즈니스와 IT측면에서 주요한 문제를 야기시킨 지금까지와는 비할 바 없

을 정도로 IT에 의존하게 된다. 인터넷의 성장이 이것의 주요한 예이다. 그러나 좋은 소식은 변경 관리

의 원리는 변하지 않는다는 것이다. 변하는 점은 비즈니스와 기술의 빠른 변화를 더욱 효과적이고 분

별있게 처리하여야 한다는 점이다.

인터넷

소프트웨어 툴 지원은 민감성과 효과의 몇몇 문제의 조정에 있어 빠르게 발전한다. 많은 벤더들은 데

이터베이스의 원격 업데이트와 더불어 인터넷 환경에서 작동하는 툴을 제공한다.

World Wide Web과 인터넷이 정보의 접속을 향상시키고, 비즈니스와 IT가 그들의 분야를 확장하게 되면

서, 데이터의 보안은 더욱 문제가 되고 있다. 이것은 보안에서 변경의 영향을 판단하는 변경 관리자의

책임 증가를 야기시키며, 안내의 필요성을 인지시킨다.(ITIL 보안 관리 참조 – ISBN 0-11-330014-X)

- 205 -


어플리케이션 소프트웨어 개발

변경 관리가 영향을 미치기 시작하고 있는 또 다른 영역은 어플리케이션 소프트웨어 개발과 요구 설계

이다. 실제 환경에서 새로운 어플리케이션 실행의 영향은 여러해동안 ITIL 교육된 직원에 대한 문제가

되었다. 그러나, 개발라이프사이클에서의 그들의 역할은 잘 알려지지 않았으며, ITIL 책 ‘Software

Lifecycle Support (ISBN 0-11-330559-1)’는 그 문제를 해결하기 위해 출간되었지만 그 문제는 서비스 제

공자의 협의사항에서 충분히 높지 않기 때문에, 최근까지 주로 무시되었다.

릴리즈 관리의 주요한 활동은 변경라이프사이클에 정의되어있다; 소프트웨어 유지와 같이, 자주 무시되

는 프로세스(또는 비즈니스에 대한 중요성에 관해서 설명이 어려운 프로세스)의 기술적 개념은 서비스

관리의 처음부분에서 특별히 중요하게 보여질 수가 있다. 이것은 이 책의 릴리즈 관리의 그림 9.1에서

설명된다.

적당한 구성 관리 제어가 어플리케이션 소프트웨어 개발까지 확장되어짐에 따라, 변경 관리는 요구 명

세에 영향을 준다. 요구 명세는 지금(해야한다!) 디자인 단계에서 인프라스트럭쳐 관리 문제를 고려한

다. 그러한 행동에 의해, 인프라스트럭쳐 관리는 새로운 어플리케이션들의 실제 작동의 기회를 향상시

키는 것뿐만 아니라 유지(그리고 소프트웨어의 유지는 개발의 비용보다 많은 시간이 소요됨이 증명되

었다.)에서의 여러문제들을 감소시킨다.

- 206 -

서비스관리를 위한 레퍼런스 요약집IT ITIL 9. 서비스 수준 관리 (SLM)

9.1. 개요

9.1.1. SLM의 필요성

SLM은 모든 IT조직이 비즈니스를 지원하기 위해 제공하는 IT서비스를 정의하고 서비스 수준의 충족여

부를 확인하기 위해 반드시 필요한 IT프로세스이다.

SLM프로세스를 통해 관리 유지하는 SLA (Service Level Management)는 IT조직의 성과를 측정하고 판

단하는 구체적인 목표치를 제공하게 된다.

9.1.2. SLM의 목표

SLM의 목표는 IT서비스수준에 대한 합의, 모니터링, 리포팅 및 서비스개선활동과 같은 반복적인 SLM

프로세스를 통하여 IT서비스 품질을 유지하고 개선하는 것이다. 이러한 SLM 프로세스는 반드시 비즈

니스 및 비용적 요소와 연계 운영되어야만 한다.

9.1.3. SLM의 범위

IT조직이 제공하는 모든 IT서비스에 대한 SLA가 정의되어야만 한다. 또한 SLA계약 및 OLA

(Operational Level Agreement)계약도 내 외부 서비스제공자와 정의되어야만 한다.

9.1.4. SLM의 기본 개념

SLM프로세스는 기본적으로 고객과 IT조직이 계약한 SLA에 따라 계획 (Planning), 조정 (Co-ordination),

드래프트 안 작성 (Drafting), 합의 (Agreeing), 모니터링 , 리포팅 (Reporting)을 수행하고 서비스성취도

를 계속 검토함으로써 필요 수준의 서비스품질과 합리적인 비용의 서비스품질이 유지되고 점차적으로

서비스품질이 향상되도록 하는 프로세스이다.

9.1.5. SLA 개념

SLA란 IT서비스제공자와 IT고객간에 문서로써 정의된 양자간 IT서비스 목표 치로 정의할 수 있다.

이러한 SLA는 일방적인 계약에 의한 배상의 조건으로 유지되어서는 안되며 진정한 파트너쉽을 통하여

쌍방이 이익이 되는 계약으로 존재하여야 하며 그렇지 않을 경우 결국 SLA는 상호 신뢰가 깨어져서

서로간 책임 전가의 문서로 전력하게 된다. 결과적으로 IT서비스 품질향상을 기대할 수가 없게 된다.

- 207 -


그림 9.1 – 고객과 서비스 수준 관리의 관계

- 208 -

서비스관리를 위한 레퍼런스 요약집IT ITIL 9.2. SLM 프로세스

SLM프로세스는 반드시 계획 (Planning), 구축 (Implementation), 수행 (Execution), 및 통제 (Control)되

어야만 한다.

그림 9.2 - SLM process

9.2.1. SLM의 기대효과

효과적인 SLM을 통한 서비스 중단시간의 절감 및 서비스품질의 개선은 궁극적으로 상당한 재정적 절

감효과를 발생시킬 수 있다. 결과적으로 IT서비스의 장애가 적어지면 IT조직이 사용하는 시간 및 노력

으로 인한 비용이 절감되며 또한 IT고객은 영향 없이 비즈니스활동을 수행할 수 있다.

그 외 SLM으로 인한 기대효과는 다음과 같다.

! IT서비스는 SLR (Service Level Requirements)를 반영하도록 설계된다.

! 고객만족에 따른 고객과의 관계개선

! IT조직과 고객은 확실한 역할 (Role) 및 책임 (Responsibilities)을 갖게 되며 그에 따라 잠재적

인 장애를 막을 수 있다.

! 정확한 서비스목표가 정의됨에 따라 서비스품질이 측정, 모니터, 리포팅 될 수 있다. 즉 목표가

없으면 치지도 못한다는 격언처럼

- 209 -


! IT와 고객은 서비스수준에 대한 명확한 기대치를 공유하게 된다.

! 서비스를 지속적으로 모니터링함으로써 잠재적인 장애요소를 찾아내어 즉각적인 액션을 함으로

써 향후의 서비스 품질을 개선할 수 있다.

! SLM은 공급자 관리를 가능토록 한다. 즉 서비스모니터링을 통하여 내외부 파트너의 성과 치를

측정함으로써 파트너를 평가 및 관리할 수 있는 기반을 마련한다.

! SLA는 고객에게 비용청구의 기초자료로 이용할 수 있다. 즉 고객이 투자한 돈에 대해 어떤 가

치를 받는지를 정의할 수 있다.

! SLM을 통하여 고객과의 정기적인 대화채널을 구축할 수 있다.

SLM을 성공적으로 구축하기 위해서는 고객과의 진정한 파트너쉽이 반드시 필요하다. 이러한 파트너쉽

을 통하여 장애분석 및 해결이 쉽게 가능하고 생산적인 IT서비스 품질 개선이 가능하다. 만약 책임전가

의 문화가 퍼질 경우에는 결과적으로 IT서비스품질개선은 불가능하며 상호 방어적, 수동적인 관계로 전

락하게 될 것이다.

9.2.2. 비용 (Cost)

SLM을 구축하고 수행하기 위한 비용은 개략적으로 다음과 같은 비용요소가 필요하다.

! 담당자 인건비 (봉급, 교육비, 필요인원 선발비용)

! 설비비

! 지원 도구 (모니터링 및 리포팅 도구, 시스템관리도구)

! 지원도구를 운영하기 위한 하드웨어 플랫폼

! 마케팅 비용

그러나 이러한 비용은 결과적으로 IT서비스품질개선을 위한 투자 및 부가가치창출로 나타나게 된다.

9.2.3. 장애 및 장벽 (Possible Problem & Barriers)

! 고객이 정의한 SLA에 대한 서비스 모니터링 (가장 심각한 경우로 고객의 관점에서 SLA를 저해

하는 경우)

! 고객과의 합의 전에 서비스수준목표를 확정하는 경우

! 실현 가능한 목표치가 아닌 단순히 이상적인 목표치를 정의하는 경우

! 불충분한 인적자원 및 시간

! SLM에 충분한 권한 및 Sponsorship이 없는 경우

! SLA가 적정한 수준에서 계약된 경우

! 쌍방간 책임영역이 명확하게 정의되지 가 않아 책임소재에 대한 위헌요소가 존재하는 경우

! 비즈니스 필요요소보다는 IT중심적으로 정의되어 있는 경우

! SLA가 간결, 초점적이지 않고 너무 장황하게 표현되어 있는 경우

! SLA에 대한 충분한 협의가 없는 경우

! 기업 입장에서 SLM이 “overhead”로 인식되는 경우

- 210 -


9.3. SLM 프로세스 계획단계 (Planning the process)

9.3.1. 최초 계획 활동 (Initial planning activities)

SLM이 적용되어 있지 않은 경우 반드시 계획을 세워야 하는 일련의 타스크들이 있다.

! SLM 또는 관련 지원 담당자들을 임명 또는 지명

! Mission Statement의 정의

! SLM기능 및 목표의 정의

! SLM수행을 위한 인식공유 및 지원을 얻어내기 위한 캠페인 실시

! 역할, 책임, Task를 정의

! 활동, 지원, 필요재정, 품질 목표에 대한 정량화

! 위험요소 분석

! SLA내에 포함될 IT 서비스 카탈로그 정의

! 파일롯 SLA를 작성

! SLA모니터링을 위한 지원도구를 정의

! 고객, 내외부 서비스파트너와의 장애발생시 우선순위정책 및 에스컬레이션 방법정의

9.3.2. 최초 서비스수준 인식 조사

SLM 도입을 하기 전에 고객의 현재 서비스수준에 대한 기대치를 알아보는 것이 매우 중요하다.

이러한 과정을 통하여 사전에 SLA 유효성을 판단할 수 있을 뿐더러 진행속도의 조절 및 대상 서비스

에 대한 우선순위를 정하는 것에도 도움이 된다.

반드시 고려해야 할 요소중의 하나는 서비스비용을 지불하는 고객 상위관리자가 서비스를 반드시 이용

하는 사람은 아니라는 사실이다. 따라서 고객그룹 내 모든 인원으로부터의 의견을 수렴하는 것이 필요

하다. 동시에 서비스 제공자 파트너의 인식을 알아보는 것도 중요하다. 왜냐하면 파트너들이 고객과는

다른 인식을 갖고 있을 수 있기 때문이다.

고객만족도 조사 또는 질의서가 고객의 총체적인 인식상황을 알아보는데 도움이 될 수 있으며 고객전

반계층의 인식 도를 알아보기 위하여 고객관리자 및 사용자/운영자들 모두를 알아보는 것이 매우 중요

하다.

종종 시스템운영자와 관리자가 서로 다른 인식을 갖고 있는 경우가 많기 때문이다.

비록 비용이 많이 들고 시간이 더 걸리는 경우도 있지만 때로는 대면을 통한 상담이나 전화조사가 질

의서보다 더 효과적인 경우도 많다.

이러한 2가지 방법이 일반적으로 가장 효과적인 접근 방식이다.

9.3.3. UC 및 OLA 계약 (Underpinning contracts and Operational Level Agreements)

최종 SLA확정하기 전에 SLA목표 치에 대한 외부 파트너와의 계약 (UC) 및 내부 공급자와의 OLA는

사전에 검토되어야 한다.

- 211 -


9.4. SLM 프로세스 구축단계 (Implementing the process)

SLM계획단계의 타스크 도출이 완료되면 SLM을 구축하기 위한 다음 타스크들을 진행해야 한다.

9.4.1. 서비스 카탈로그 작성 (Produce a Service Catalogue)

수년동안 IT 인프라스트럭쳐가 성장하고 발전해왔지만 현재 고객에게 제공되는 모든 서비스에 대한 명

확한 그림을 보여주지는 못했다. 이러한 IT 인프라 서비스에 대한 명확한 그림을 그리기 위해서는 IT

서비스 카탈로그를 작성하기를 권고한다.

그러한 서비스 카탈로그는 고객에게 제공되는 모든 IT서비스와 각 서비스에 대한 특징, 상세고객정보와

지원주체를 포함한다. 작성한 서비스 카탈로그를 정리 요약, 프로그램 라이브러리 검색, IT담당자 및

고객과 협의, 외부 파트너와 구매 기록을 검색하여 고객과 확인하도록 한다.

만약 CMDB (Configuration Management Database)에 자료가 있다면 유용한 정보로 이용할 수 도 있다.

그러면 정확한 “Service”란 무엇일까? 정확하고 명확한 정의란 쉽지가 않다. 많은 경우에 하나의 서비

스는 복수개의 다른 서비스로 구성되어 있으며 하나의 서비스에 종속되는 다른 서비스는 한 개 이상의

IT시스템 (시스템, 네트워크, 어플리케이션 등)으로 구성되어 있다.

분명한 것은 서비스의 정의는 비즈니스와 연관해서 생각해야만 한다는 것이다. 예를 들어 고객에게 어

떤 IT서비스를 이용하고 있고 그러한 서비스가 비즈니스 프로세스와 어떻게 연관되는 지를 물어보면

종종 고객은 명확한 답변을 하는 경우가 있다.

따라서 “서비스”란 비즈니스 프로세스를 가능케 해주는 하나 또는 그 이상의 IT시스템으로 정의할 수도

있을 것이다.

이런 혼돈을 피하기 위한 방법으로 서비스 카탈로그내 서비스들을 서비스종류별로 분류하여 서비스들

을 수직적으로 그룹핑하는 것도 좋은 방법이다. 예를 들면 비즈니스 서비스 (고객의 직접적 인터페이

스), 인프라 스트럭쳐 서비스, 네트워크 서비스, 어플리케이션 서비스 (고객과 직접 인터페이스 되지는

않지만 반드시 필요한 서비스)로 분류하여 각 서비스를 그룹핑하는 방법이다.

이러한 방법으로 서비스들을 그룹핑하면 서비스 카탈로그는 매트릭스, 테이블 또는 스프레드 쉬트로

구성된다. IT조직에 따라서는 이러한 서비스 카탈로그를 CMDB에 통합하여 유지하는 경우도 있다.

각 서비스를 하나의 CI (Configuration Item)로정의하고 CMDB내 서비스 계층과 연계시켜 장애발생시 서

비스와 연계하거나 RFC (Request for Change)와 연계할 수 있다.

따라서 통합도구 (특정서비스에 영향을 주는 Incident에 인덱싱을 하는 도구)를 이용하여 서비스 모니터

링할 수 있는 기초를 마련할 수 있다.

이러한 서비스 카탈로그는 또한 SLM외 타 서비스 관리 프로세스,- BIA (Business Impact Analysis),

- 212 -


Workload Management , Capacity Management – 를 위해 사용될 수도 있다.

BIA와 연계하여 서비스 카탈로그를 작성하게 되면 비즈니스에 가장 중요한 서비스를 우선순위를 매김

할 수 있다

9.4.2. 기대치 관리 (Expecting Management)

고객의 기대치를 관리하는 매우 중요하다. 최초에 적절한 기대치를 설정하고 지속적 체계적으로 고객

의 기대치를 관리하는 것이 중요하다. 일반적으로 고객만족도 = 기대치 – 인지도이기 때문이다.

9.4.3. SLA구조 계획 (Plan the SLA structure)

서비스 카탈로그를 이용하여 비즈니스 요구사항을 가장 잘 적용할 수 있는 SLM을 위한 가장 적합한

SLA구조를 만들어야 한다. 이러한 SLA구조에는 몇 가지 방법이 있다.

서비스 중심 SLA구조

하나의 SLA가 하나의 서비스에 적용되는

방법이다. 이 경우 적용하는 SLA가 모든 동일한 서비스에 적용하는 방법이다.

이러한 방법은 가장 간단한 방법으로 보이지만 고객이 동일한 유형의 서비스에 대한 특별한 SLA를 원

하는 경우나 IT 인프라스트럭쳐의 특성상 다른 서비스수준이 불가피한 경우 (예를 들면 본사는 고속의

네트워크 환경이고 지사인 경우 저속의 네트워크인 경우 동일한 SLA를 적용하기 어려움)에는 적용함

에 어려움이 있다.

이 경우 하나의 SLA 계약 안에 서로 다른 목표치를 갖도록 구성해야 하며 승인 및 품의 주체를 결정

하기 어려운 단점이 있다.

고객 중심 SLA구조

고객그룹별로 SLA를 적용하는 구조로 사용하는 서비스 전체에 대해서 하나의 SLA를 적용하는 구조다.

예를 들면 회계부서가 사용하는 모든 서비스-회계서비스, 어카운팅서비스, 급여시스템, 빌링시스템, 구

매시스템 및 기타 서비스에 대해 동일한 SLA를 적용하는 방법으로 고객은 종종 고객그룹의 모든 요구

사항이 하나의 SLA에 적용할 수 있기 때문에 선호하는 경우가 있다.

고객중심의 SLA구조는 단일 서명에 의해 승인 받을 수 있기 때문에 품의과정을 단순화할 수 있다.

복합 레벨 SLA구조

일부 IT 조직에서는 복합 SLA구조를 채택하는 경우도 있는 예를 들면 3 단계 계층구조로 다음과 같다.

1. 회사 레벨 (Corporate Level) : 회사 전체에 적용하는 일반적 SLM으로 자주 변경되지 않는 특성

을 갖고 있다.

2. 고객 레벨 (Customer Level) : 특정 고객그룹 중심으로 적용되는 SLM으로 사용되는 서비스종류

에 무관하다.

3. 서비스 레벨 (Service Level) : 특정 서비스중심으로 적용하는 SLM이다.

- 213 -


그림 9.3 - Multi-level SLAs

9.4.4. SLR설정 및 드래프트 SLA정의 (Establish Service Level Requirements and Draft SLA)

고객과 SLA구조가 정의 및 승인되면 최초 Draft SLA가 반드시 작성되어야만 한다. Draft SLA작성시에는

최초단계에서부터 고객을 참여 시키는 것이 좋다. 또한 향후 더 상세한 SLA작성과 심층적 회의를 통한

SLA작성을 위해 최초시작단계에서 Draft SLA를 작성하는 것이 좋다.

일반적으로 고객이 원하는 것을 잘 모를 수 있기 때문에 요구사항을 도출하기가 쉽지가 않기 때문에

고객을 도와서 필요사항을 이해시키고 정의하는 데 도움을 주는 것을 권장한다.

최초에 표현된 요구사항을 합의로 이끌어 내기는 대부분 어렵고 비용이 발생할 시점에 변경이 될 가능

성이 크기 때문이기도 하다.

반복적인 조정작업과 협상을 통하여 목표 치와 원하는 것에 대한 균형을 이루는 것이 중요하다.

또한 최초단계에서 SLA형식을 정의하는 것이 이상적이다. 많은 경우에 SLA형식이 Pilot SLA일때 작성

되기 때문이다.

9.4.5. SLA 작성

SLA 문서는 모호한 문장이나 장황하지 않게 반드시 명확하고 간결하게 작성하여야 한다. SLA에서 사

용하는 용어는 규정적인 용어를 사용할 필요는 없다. 누구나 이해할 수 있는 일상적인 용어를 사용하

는 것이 좋다.

따라서 최종 SLA작성 후에 SLA와 관계없는 인원이 SLA문서를 읽어보고 상식 선에서 이해할 수 있는

지를 확인하는 것도 좋은 방법이다. 이러한 과정을 통해 잠재할 수 있는 용어 또는 문장의 모호함이나

불명확성을 방지할 수 있다.

9.4.6. SLA 합의

드래프트 SLA를 기초로 고객 또는 고객대표와 SLA내용, 최초 서비스수준 목표를 검증해야 하며 또한

서비스파트너와도 목표치가 달성가능한지를 검증하여야 만 한다.

SLA합의와 관련하여 발생 가능한 어려움은 정확한 협상 대표를 찾는 일이다. 결국 서비스의

- 214 -


“Ownership”을 찾는 일인데 어떤 경우에는 한 사람의 고객관리자가 기꺼이 SLA를 승인하는 경우도 있

으나 다른 경우에는 몇 번의 협상과정을 거치거나 협상대표를 찾는 일조차 어려운 경우나 모든 고객의

승인을 받아야 하는 경우가 있다.

진정으로 고객그룹의 관점으로 고객을 대표하는 사람이 있다면 가장 이상적이다. 그러나 불행히도 대

표인 경우 현업부서사람이 아닌 서비스와 관계없는 계약 부서인 경우가 많다.

고객이 SLM에 대한 경험이 없는 경우에는 특정서비스 또는 고객과 파일롯 프로젝트를 해야 한다.

만약 파일롯 프로젝트에 고객이 열정적이거나 또는 프로젝트에 참여해서 서비스 품질향상을 원하는 경

우 또한 이상적이다.

또 다른 어려운 점은 고객구성이 서로 다른 계층으로 구성되어 서로 다른 목표와 인식을 갖고 있는 경

우이다. 예를 들면 상위관리자는 서비스를 잘 사용하지 않고 투자비용과 산출물에 대한 가치에만 관심

이 있고 하위 담당자는 매일 서비스를 사용하고 있고 서비스에 대한 응답성, 사용률, 신뢰성에 더 관심

이 있는 경우인데 중요한 것은 모든 계층의 고객요구사항을 포함할 수 있도록 SLA를 정의하고 작성하

는 것이다.

고객 구성상 고객을 대표하는 또 다른 고객그룹 또는 외부 파트너가 있는 경우 SLA가 구체적으로 정

의되면 모든 주체의 합의를 이끌어 내는 것이 매우 중요하다. 만약 합의가 이 단계에서 나오기 힘든

상황이면 모든 주체가 합의할 때까지 계속 협의가 필요하다. 또한 이 단계에서 어떤 내용이라도 다루

어져야 한다.

과거에 모니터링 데이터가 없을 경우에는 최초단계에서 합의를 하는 것보다는 모니터링 데이터가 수집

이 되서 최초 서비스 목표치가 정의될 수 있을 때 하는 것이 좋다.

어떤 경우에는 서비스 목표치가 재협상 될 수도 있으며 일단 SLA가 확정되면 반드시 쌍방간 승인 및

서명이 필요하다.

일단최초의 드래프트안이 확정되고 최초의 장벽이 극복되면 점차적으로 고객에게 SLA를 도입한다. 만

약 다계층 SLA구조로 정의되면 회사레벨의 SLA항목은 회사전반에 걸친 항목을 선정하게 되는데 파일

롯 단계에서 이러한 회사레벨의 SLA항목을 구현하는 것이 매우 가치가 있다.

결과적으로 드래프트 및 협상의 최종 산출물은 SLA에 대한의 고객의 서명 및 승인이다. 쌍방간 합의

SLA에 의해서 모든 활동은 SLA를 충족하기 위해 집중되고 확고한 Sponsorship을 보장 받게 된다.

일반적으로 고객의 상위관리자가 서명할수록 더 많은 Sponsorship을 받게 된다.

이 경우 서비스데스크 요원이 SLM프로세스를 인식하는 것이 중요하다. 왜냐하면 서비스데스크는 SLA

에 대한 대표자역할을 수행하며 필요한 서비스문화를 정착시키며 고객의 Incident, 불만, 문의에 대한

최초 접촉 창구이기 때문이다.

- 215 -


만약 서비스데스크 요원들이 충분히 SLA를 인식하지 못하고 있으면 고객은 SLA에 대한 신뢰를 매우

빠르게 잃어버릴 수 있다.

9.4.7. 모니터링기능의 설정 (Establish 모니터링 Capability)

공통으로 합의될 수 있는 관점에서 효과적으로 모니터하고 측정될 수 있는 것만 SLA에 포함되어야 한

다. 이것은 매우 중요한데 효과적으로 모니터 될 수 없는 항목을 SLA에 포함하게 되면 논쟁만을 불러

일으켜 결과적으로 SLM Process에 대한 신뢰를 떨어뜨리게 되기 때문이다. 많은 조직에서 이것이 “어

려운 방법”이며, 결과적으로 적지 않은 비용과 또한 그들의 문화에 부정적인 영향만을 감수해야 했다.

기존의 모니터링 Capability는 검토되고 필요한 만큼 향상되어야 한다. 이상적으로는 이러한 활동은

Draft SLA 과정의 이전이나, 또는 병행하여 이루어져야 하는데, 이는 모니터링이 제안된 목표의 합리화

를 입증할 수 있어야 하기 때문이다.

모니터링은 고객의 “서비스에 대한 진정한 인식”과 일치해야 하는 것이 기본이다. 그러나 불행하게도

이것은 매우 어려운 일이기도 하다. 예를 들면, 네트웍과 서버와 같은 개별적인 구성 요소들만을 모니

터링하는 것은 고객이 인식하고 있는 서비스가 제공되고 있다는 것을 보장하여 주지 못하기도 한다.

왜냐하면 Desktop이나 application등의 failure로 인해서도 고객은 서비스를 사용할 수 없게 되기 때문이

다. End-to-end 서비스의 관점에서 모든 구성요소들을 모니터링하지 않으면 (사실 이것은 매우 어렵고

비용 또한 많이 들지만), 진정한 서비스를 제공한다고 보기 어렵다. 유사하게, 사용자들은 만약 성능과

관계된 경우, 각각의 사고들은 진단을 지원하기 위해 즉시 보고되어야 한다는 것을 인정해야 할 것이

다.

하나의 Workstation에 여러 개의 서비스가 제공되는 경우, 어느 한순간 사용자가 접속을 시도했던 서비

스의 downtime만을 기록하는 것이 아마도 더 효과적일 수 있다 (물론 고객과 사전에 합의되어야 할 문

제이지만). 고객의 인식은 여러 개의 서비스에서 장애가 일어났었다 할 지라도 그들이 영향을 받았던

것은 보고된 장애순간에 사용자가 접속을 시도했던 서비스에 한정되기 때문이다 – 물론, 항상 그런 건

아니기 때문에 주의가 필요하다.

많은 조직이 고객이 인지하는 가용성을 모니터하기 위하여 그들의 서비스데스크 (CMDB와 연계된)를

사용하고 있다. 이것에는 특정한 인시던트로의 변경/문제 기록을 위한 화면이 있으며, 문제 관리절차를

준수할 것을 요구하기도 한다. 이러한 모든 활동은 가용성 관리 (Availability Management) 기능과의

토론과 합의를 필요로 한다.

서비스데스크는 또한 장애에 대한 응답시간과 처리시간을 모니터링하는 데 사용되기도 하는데, 이때에

도 장애 관리 화면에는 수집된 데이터를 관리하기 위한 수정이 필요할 수도 있으며, Call logging 절차

가 강화되고 철저히 준수되어야 할 필요가 있다. 만약 제 3의 협력업체에 의한 지원이 이루어 진다면,

이러한 모니터링 결과는 또한 공급자 관리를 위한 기초 자료로 활용될 수도 있을 것이다.

- 216 -


SLA에 명시된 모든 인시던트/문제 관리 목표가 서비스데스크 Tool의 그것과 같아야 하고, 또한 그 목

표에 의해 에스컬레이션과 모니터링이 이루어 진다는 것은 매우 중요한 것이다. 조직이 이것을 인식

하지 못한다면, 그리고 제품 공급업체에 의해 제공된 기본 사양만을 사용한다면, 결국 SLA에 합의된

것과는 다른 엉뚱한 자료를 모니터링하는 상황에 봉착하고, 자료를 다시 가공하는 데 엄청난 시간과

노력을 쏟아 부은 후에야 SLA 수준이 맞춰진 것을 확인할 수 있게 될 것이다.

지원 도구에는 관계된 데이터가 수집될 수 있도록 하기위한 field를 추가하는 등의 수정이 필요할 수

있다.

또 하나의 측정하기 매우 어려운 부분은 Transaction Response Time (screen에서 명령을 보내고 받는

데 걸리는 시간)을 모니터링하는 것이다. End-to-End Response Time을 모니터하기가 기술적으로 아주

어려운 경우가 많다. 그런 경우 다음과 같이 관리하는 것이 적절할 것이다:

a. SLA statement에 다음 문구를 삽입한다 - “이 SLA에 의해서 관리되는 서비스는 high-speed 응

답시간을 보장하는 서비스이며, 너무 장시간의 Delay는 없는 것으로 가정한다. Y분 이상의 기간

동안 x초 이상의 응답시간이 감지되는 경우 즉시 서비스데스크에 연락한다.”

b. Reporting 기간 내에 허용될 수 있는 사고의 횟수에 대한 목표치에 대해 합의하고, 이를 SLA에

포함시킨다.

c. Incident 구분에 ‘poor response’라는 포함하고 이러한 사고가 정확하게 기록되고 있으며 이에 적

당한 서비스와 관련되어 있음을 주지시킨다.

d. SLA상에 transaction response time 목표치가 미달된 경우에 대한 주기적인 보고서를 작성하고,

이러한 상황을 개선하기 위해 Problem Management에 조사를 의뢰한다.

이러한 접근방식은 모니터링의 기술적인 제약사항을 제거하여 줄 뿐만 아니라, poor response 장애가

그것이 발생한 시간에 보고된다는 것을 보장하여 준다. 이것은 매우 중요한데, 왜냐하면 slow

response time은 때때로 다른 문제의 발단이 되며, 이러한 문제는 그 순간에만 감지될 수 있는 경우가

많기 때문이다.

그러나 사실 더 좋은 방법은 자동화된 client/server 환경의 응답시간 모니터링을 구현하는 것이다. 이

러한 Tool들은 더욱 더 저렴한 가격에 효과적으로 사용할 수 있도록 개발되고 있다. 이러한 Tool들은

여러 사용자가 경험하는 것과 동일하거나 비슷한 환경에서 응답시간을 측정 또는 표본화 할 수 있는

기능을 제공하고 있다.

SLA가 Requests for Charges (RFCs)를 수집하고 구현할 수 있는 목표를 가지고 있다면, 변경 관리와

관계된 목표치를 모니터링하는 것은 (이상적으로는) 어떠한 변경 관리 Tool (통합된 Service

Management 지원 Tool의 한 부분인 것이 더 낫겠지만) 을 사용하든지 반드시 수행될 수 있으며, 동시

에 변경 기록 화면과 에스컬레이션 프로세스는 이것들을 지원하게 될 것이다.

- 217 -


고객의 전반적인 느낌 등과 같이, 기술적인 혹은 절차에 의해서는 모니터링될 수 있는 ‘soft’ issue들이

많이 있다. 예를 들면, 서비스 장애가 수 차례 보고된 적이 있다 할지라도, 고객은 그러한 장애를 개

선하기 위한 적절한 행동들이 취해지고 있다는 것을 안다면, 긍정적으로 느낄 수도 있다는 것이다. 물

론, SLA의 거의 모든 목표가 준수되고 있다고 할지라도 어떤 Issue (예를 들면 Support Desk직원의 응

대자세 등) 에 의해 고객은 불 만족하는 등의 반대의 경우에도 적용될 수 있다.

Soft Issue에 대한 고객의 인지도를 모니터하기 위한 시도로 다음과 같은 활동이 있을 수 있다.

! 전화를 통한 인지도 조사 (무작위 또는 지역별 대표자를 통한)

! 주기적인 설문 조사

! 만족도 조사 용지 (설치, 서비스 방문이후 고객에게 전달)

! 단체 회의 실시

가능하다면, 이런 것들에 대한 목표치가 설정되고 SLA의 한 항목으로서 모니터 되는 것이 좋다 (예를

들면 1~5점 범위내 3.5 목표 등). Feedback을 준 사용자에게는 적절한 회신이 전달되고, 그들의

comment가 다음 action plan에 포함된다면, 그것이 서비스 개선 프로그램 (Service Improvement

Program) 이 된다는 것을 명심하시기 바란다.

9.4.8. 외부파트너와의 계약 및 OLA 검토 (Review Contracts & Operational Level Agreement)

대부분의 IT 서비스 제공업체는 일정 부분 외부 파트너 (내부 and/or 외부)에 의존하고 있다. 외부 파

트너가 목표를 맞추지 못한다면 IT 서비스 제공업체가 SLA 목표를 맞추지 못하는 경우도 있다. 외부

업체와의 계약은 필수 사항이며, 또한 많은 조직은 보통 OLA라 불리는, 내부 지원조직과의 간단한 계

약형태를 가지는 경우도 있다. 그림에서 이러한 여러 형태를 보여주고 있다.

그림 9.9 - SLA 지원 구조

- 218 -


OLA는 매우 복잡할 필요는 없으나, SLA 목표를 달성하는데 하부조직이 되는 지원조직의 특정 내부 목

표를 확실히 명시해야 한다. 예를 들면, SLA에 장애에 응답하여 이를 처리하는 전체 시간 (물론 장애

등급별로 차이가 있겠지만) 에 대한 항목이 포함되어 있다면, OLA에는 Support Chain상에 있는 모든

구성요소들의 목표치가 있어야 한다 (서비스데스크에서 전화를 받는 목표, 에스컬레이션, 그들에게 지

정된 네트워크 장애에 대한 원인을 조사하여 해결하는 시간에 대한 목표 등). 추가로 전체 지원시간은

각각 외부파트너 업체의 목표로 나누어져 지정되어야 한다. 또한 계약요원에 대한 특정제약사항 (예를

들면, 전화지원이 안 되는 시간)이 있으면 반드시 SLA에 문서화되어야 한다.

그러나 SLA에 포함된 Incident해결시간 목표치가 내외부 공급자와의 OLA항목 또는 계약항목과 반드시

일치되지는 않는다. 이것은 SLA목표치는 모든 IT서비스 지원 사이클 – 감지시간, 서비스데스크 기록시

간, 에스컬레이션 시간, 그룹간 책임소재 정의시간, 실제 해결 시간 , 서비스데스크 검토 및 종료시간)-

을 지원하기 때문이다.

따라서 최종 SLA를 정의하기 전에 SLA의 구문상의 정의 및 배열을 검토, 조정하는 것이 필요하다. 이

렇게 조정 작업이 있을 경우 추가적인 비용을 고려하여야 하며 IT서비스고객이 합의하여야 한다.

OLA는 이러한 SLA목표에 대해 모니터링 되어야만 하며 지원그룹의 관리자에게 통보하여야 한다.

9.4.9. 리포팅 기능 정의 및 절차 검토 (Define Reporting & Review Procedures)

SLA 리포팅 메커니즘과 리포팅 주기 및 형식은 반드시 정의되고 고객과 합의되어야 한다. 또한 서비스

검토미팅의 주기와 형식 또한 고객과 합의 하에 정의되어야 한다.

일반적으로 회의는 주기적으로 시행할 것을 권고하며 주기적인 리포트는 검토 주기를 준수하여 작성되

어야 한다.

SLA항목은 주기적 (일반적으로 회계연도별로 시행)으로 검토되어 그 유효성과 적정성을 평가하여 비즈

니스의 요구사항을 충족시키는 지를 지속적으로 확인해야 한다.

모든 SLA는 반드시 변경관리 프로세스를 준수하여야 하며 변경사항은 서비스 카탈로그에 반영되어야

한다.

9.4.10. SLA 공개

최종 SLA가 확정되면 새로운 SLA를 서비스데스크 및 타 관련조직에 홍보, 통보하여야 한다.

때로는 SLA에서 각 서비스지원부서별 중요 서비스목표를 테이블로 정의하여 쉽게 인식하여 조직별 목

표치 달성을 할 수 있도록 하는 것도 방법이다.

만약 관리도구가 있으면 SLA목표 치에 대한 임계 치를 설정하여 자동으로 통보하도록 할 수도 있다.

SLA와 서비스 목표는 사용자그룹에도 공개하여 사용자가 어느 정조의 서비스를 받들 수 있는 지와 서

비스 불만족기준을 알 수 있도록 할 수 있다.

- 219 -


9.5. 진행 프로세스

9.5.1. 모니터링 및 리포팅 (Monitoring & Reporting)

최종 SLA가 합의되는 즉시 모니터링 기능이 시작되어야 하며 리포트가 작성되어야 한다. 운영 리포트

는 반드시 주기적 – 일별 – 작성되어야 하며 가능할 경우 SLA가 위반되는 경우마다 SLA위반 리포트

가 작성하는 것이 좋다.

리포트는 고객 또는 고객 대표에게 주기적으로 작성, 전달되어야 하며 SLA 검토 회의 전에 미리 해당

IT관리자에게 전달하여 사전에 검토 회의 시 있을 수 있는 고객의 문의나 이견을 해결하는 것이 좋다.

주기적인 리포트의 내용은 서비스품질개선을 위한 조치내용, 향후 서비스품질 상세 예측치, 그리고 모

든 SLA항목에 대한 수행성과를 포함하여야 하며 한눈에 전체 SLA목표에 대한 측정 수치 및 상태를

칼라로 볼 수 있는 SLA Monitoring (SLAM)차트를 서비스 리포트에 포함한다.

이외에도 내부적인 성능검토 및 외부 파트너와의 계약 내용에 따른 성과 평가 등을 위해 기타 다른 리

포트가 필요할 수 있다.

리포트를 작성하고 검증하기 위한 자원은 충분히 배정하여야 한다. 왜냐하면 리포트 작성은 상당한 시

간을 요하는 작업이며 리포트가 서비스품질에 대한 고객의 인식을 정확하게 반영하지 못하면 SLM프로

세스가 유지될 수 없기 때문이다.

SLM프로세스를 잘 운영하기 위해서는 정확한 리포팅 요구사항을 정의하고 가능한 한 리포트 작성을

자동화하여야 한다. 따라서 이러한 리포팅 지원도구를 선정할 때에는 정확성 및 사용 편이성을 우선적

으로 고려하여야 한다.

9.5.2. 서비스 검토회의 (Service Review Meeting)

주기적으로 고객과 지난 주기동안의 서비스 달성 도를 검토하고 그리고 향후 발생할 수 있는 예상 문

제점을 사전에 검토하기 위해 서비스 검토회의를 실시한다. 검토회의는 일반적으로 월별로 진행하며

최소 분기별로 실시한다. SLA를 충족시키는 못한 약점을 보완하기 위해 고객과 서비스제공자는 조치

(Corrective Action)를 취하게 되는 데 모든 조치사항은 기록으로 남겨야 하며 조치사항이 잘 구축되었

는지를 확인하고 진행사항은 다음 회의에서 검토해야만 한다.

서비스수준을 위반한 경우 정확한 서비스 장애요소를 파악하고 재발생을 방지하기 위한 조치에 초점을

맞추어야 한다. 서비스수준목표를 만족하는 것이 현실상 불가능한 경우에는 서비스수준을 재검토하고

다른 서비스수준목표로 재설정하는 것이 필요하다.

또한 서비스장애가 외부 파트너 또는 내부 지원그룹에 의해 발생한 경우이면 파트너와의 계약 또는

OLA를 다시 검토하는 것이 필요하다.

- 220 -


9.5.3. 서비스개선 프로그램 (Service Improvement Program)

SLM프로세스는 서비스개선 프로그램(SIP)을 위한 좋은 시작점일 수 있다. (서비스검토회의를 통해)

서비스품질에 악영향을 미치는 서비스장애를 발견하여 SLM프로세스는 해당장애를 장애관리 프로세스

및 가용성관리 프로세스와 연계하여 장애해결을 위해 필요한 액션을 정의, 실시하는 SIP(Service

Improvement Program)를 개시한다.

또한 SIP 활동으로 사용자 교육, 시스템 테스트, 문서화와 같은 작업이 포함된다.

많은 IT조직들은 SLM과 SIP에 소요자금을 배정하고 있으며 이 경우 빠른 시간 안에 조치가 취해질 수

있으며 효과적, 사전 예방적, 향후를 예상할 수 있는 SLM구축이 가능해진다.

9.5.4. SLA, 외부파트너 계약, OLA 유지보수

SLA, OLA, 파트너계약사항은 항상 갱신, 유지되어야 한다. 이러한 계약은 변경관리 프로세스하에서 주

기적으로 조정되고 검토되어 현재의 IT환경을 반영하고 비즈니스전략 및 요구사항을 잘 반영하여야 한

다.

9.6. SLA 내용 및 중요 서비스수준 목표 (SLA contents & key targets)

도입부 (Introduction)

! 계약의 주체

! SLA에 대한 제목, 간략한 설명

! 서명자

! 일자 : 시작 , 종료, 검토회의

! 범위 : 포함될 내용

! 양자 책임 및 역할

! 계약에 포함될 서비스에 대한 설명

서비스 시간 (Service Hours)

! 서비스 시간 (예, 29*7, 월-금 09:00~ 18:00)

! 특정 일자 (예, 공휴일)

! 서비스 캘린더

! 서비스 연장 정의

가용성 (Availability)

! 계약시간 내 가용성 목표치는 일반적으로 Percentage로 표현된다. – 이 경우 반드시 측정기간

및 방법이 정의되어야 함- 가용성은 전체서비스, 외부파트너 서비스, 중요 IT구성요소 또는 3가지

모두에 대해 표현될 수 있지만 서비스품질을 단순한 세가지 수치로 연관시키는 것은 쉽지 않다.

따라서 서비스 비가용성 (Unavailability)을 측정하는 것이 더 좋은 방법일 수 있다.

- 221 -


신뢰성 (Reliability)

! 배치작업의 성공적인 처리율

! 일반적으로 서비스장애 횟수로 표현하거나 Mean Time Between Failures (MTBF), Mean Time

Between System Incidents (MTBSI)로 표현한다.

지원력

! 지원시간 (서비스시간과는 다름)

! 특정시간 (예, 공휴일)

! 지원 연장

! 응답 목표시간 (예, Incident에 대한 전화응답, Email응답)

! Incident 우선순위에 따른 Incident 해결목표시간 – 목표시간은 Incident 우선순위에 따라 다르게

설정

성능 (Throughput)

! 예상 트래픽 볼륨 및 성능 (Throughput) 지표 (예를 들면 처리되는 트랜잭션 수, 동시사용자 수,

네트워크을 통해 전송되는 데이터량)

트랜잭션 응답시간 (Transaction Response Time)

! 평균 또는 최대 응답시간에 대한 목표치 (때로는 백분위 수의 형태로 표현되는 데 예를 들면 2

초내 95%)

배치작업 처리성능

변경

! RFC (Request For Change)를 승인, 처리, 구축할 때의 목표치, 일반적으로 변경유형 또는 변경

우선순위에 정의된다.

IT서비스 지속성 및 보안 (IT Service Continuity & Security)

! IT 서비스 지속성 계획에 대한 간략한 정의 및 계획을 실행에 옮기기 위한 방법.

! 보안항목에 대한 정의

비용부담 (Charging)

! 상세한 비용부과 및 기간.

서비스 리포트 및 검토

! 서비스 리포트의 주기 및 분배, 내용, 서비스 검토회의

- 222 -


성능에 따른 인센티브 및 페널티 (Performance incentive / penalties)

! 서비스수준에 대한 성과에 따른 금전적 인센티브 및 페널티에 대한 상세

9.6.1. 새로운 서비스 적용방법

Service Level Requirements (SLR)

많은 IT조직들은 기존 서비스에 대해 우선적으로 SLA를 적용하는 반면 개발된 새로운 서비스 또는 구

매된 새로운 서비스에 대한 SLR을 정의하기 위한 절차를 설정하는 것이 중요하다.

SLR은 서비스 설계 시 중요한 기준이 되어야 한다. 따라서 최초단계에서부터 이러한 SLR은 서비스의

설계단계, 개발단계 또는 구매단계에서 진행을 위한 테스트와 시험의 한 부분으로 인식하여야 한다.

새로운 서비스에 대한 드래프트 SLA가 개발되어야 하고 새로운 서비스가 현업에서 사용되기 전에 고

객과 합의되어야만 한다.

지원 계획 (Support Planning)

새로운 서비스가 실 환경에 적용될 경우에 고려해야 할 또 다른 요구사항은 지원관계에 대한 계획과

공식화이다. 이러한 지원과 관련된 프로세스는 변경관리, 구성관리, release관리 등이 있으며 다양한 형

태의 권고 안을 얻을 수가 있다.

지원계획에는 특정한 책임이 정의될 필요가 있으며 OLA에 정의되어야 한다. 지원인력 및 모든 에스컬

레이션 통로를 CMDB에 등록하여야 해서 release관리, 서비스데스크 또는 기타 요원들이 알 수 있도록

해야 한다.

! SLA, OLA, 외부파트너와의 계약은 최신으로 변경 유지되는 비율은 ?

일반적으로 새로운 서비스를 지원하기 위해서는 추가적인 지원 자원이 필요하다. 기존의 인원이 추가

적인 인원 없이 새로운 서비스를 관리할 수는 없기 때문이다.

9.7. SLM의 유효성검증을 위한 중요 성능 지표 및 메트릭스

다음과 같은 중요 성능 지표 (Key Performance Indicator) 및 메트릭스는 SLM 프로세스의 유효성 및 기

능을 판단하는 데 유용하게 사용할 수 있다.

! SLA에 의해 관리되는 서비스의 비율 또는 수?

! 외부파트너와의 계약 및 OLA이 모든 SLA에 대해 체결되어 있는가? 그 비율은?

! SLA는 모니터링되고 있고 주기적으로 작성되고 있는가?

! 검토회의는 정확한 시기에 개최고 있으며 정확하게 기록되고 있는가?

! 검토회의에서 발견된 문제점은 해결하였는가?

! 서비스수준 목표를 달성하는 비율은 얼마인가? 서비스 수준 위반 수준은?

! 서비스수준 위반은 효과적으로 처리하고 있는가?

! 고객의 인식도가 개선되고 있는가?

! 서비스에 대한 IT비용이 감소하고 안정적 수준을 유지하고 있는가?

- 223 -


SLM 책임 및 역할 (Role & Responsibilities)

SLM을 성공적으로 구축하고 구축의 이점을 기대하려면 정확한 역할 및 책임하에 스스로의 타스크를

수행해야 한다.

! SLA 및 OLA대비 서비스성능을 분석 및 검토

- 필요 시 서비스수준 및 목표를 검토

역할 (Role)

조직에서 요구하는 수준까지 SLM 프로세스를 구축, 유지

책임 (Responsibilities)

! 기존 서비스 카탈로그 유지 및 생성

! 다음과 같은 적절한 SLM구조를 구성, 합의 및 유지

- SLA구조 (예, Service based, Customer Based, Multi Level)

- IT서비스 제공조직 내 OLA

- 3rd Party Supplier/계약 관리

- SLM프로세스내 SIP계획 및 프로그램을 수행

! 고객과 SLA를 협상, 합의 및 유지

! IT제공자와 OLA를 협상, 합의 및 유지

! 새로운 서비스에 대한 SLR을 협상 및 합의

! 서비스성능 및 달성 도에 대한 주기적인 리포트 작성

! 다음 사항을 포함하는 정규적인 서비스수준검토 프로세스를 유지

- 이전 검토회의에서의 조치사항을 검토

- 현 성능

- 필요 시 외부 파트너와의 계약 및 OLA 검토

- 서비스수준유지 및 개선을 위해 적절한 조치를 합의

! 서비스수준을 향상시키기 위해 필요한 조치사항을 시작

! 전체 SLM프로세스에 대한 년 단위 검토를 실시하고 필요 시 개정안에 대한 협상, 합의 및 조

정

SLM은 앞에서 설명한 바와 같이 궁극적으로 비즈니스의 요구사항을 반영하여 고품질의 IT서비스를 최

종사용자에게 제공을 목적으로 하며 성공적인 SLM구축을 위해서는 내외부 IT서비스공급자와의 명확한

SLA 및 책임역할에 따라 책임의 전가가 아니라 IT서비스 품질개선을 명확한 목적으로 IT서비스공급자

와 고객이 공동으로 책임을 지는 IT 핵심 프로세스이다.

SLM프로세스가 실 IT환경에서 구현하기 위해서는 해당 프로세스를 관리도구로써 구현하는 것이 중요

하며 더욱 중요한 것은 고객의 IT환경에 적합한 관리도구를 선정하고 현실성 있게 SLM시스템을 설계,

구축하는 것이다.

- 224 -

Documents

ITIL Reference 번역본