Skip to main content

ITIL Overview

IT 서비스 관리(ITSM) 프레임워크, 서비스 가치 체계, 핵심 프랙티스

🎯 ITIL이란?​

ITIL (Information Technology Infrastructure Library): IT 서비스 관리(ITSM)를 위한 베스트 프랙티스 프레임워크.

항목설명
발행Axelos (현 PeopleCert), 영국 정부에서 시작
현재 버전ITIL 4 (2019)
성격IT 서비스를 어떻게 관리/운영할 것인가
자격증ITIL Foundation → Managing Professional → Strategic Leader
적용 범위IT 서비스를 제공하는 모든 조직

ITIL의 역사​

버전연도특징
ITIL v11989영국 정부 IT 운영 가이드 (40권+)
ITIL v22000서비스 지원 + 서비스 제공으로 정리
ITIL v32007서비스 라이프사이클 5단계
ITIL 42019가치 체계 중심, Agile/DevOps 포용

왜 알아야 하나?​

이유설명
운영 이관SI 구축 후 운영 단계에서 ITIL 기반 체계를 요구하는 경우
SLA 관리서비스 수준 관리의 표준 프레임워크
PPDIOO와 연결PPDIOO의 Operate/Optimize 단계를 깊게 다루는 것이 ITIL
공통 언어인시던트, 문제, 변경 같은 운영 용어의 출처
제안서"ITIL 기반 운영 체계 수립" 문구가 제안서/RFP에 등장

다른 프레임워크와의 관계​

프레임워크범위초점
PMBOK프로젝트 (한시적)관리
SI 라이프사이클구축 프로젝트절차/산출물
PPDIOO설계~운영기술 수명주기
ITIL운영 (지속적)서비스 관리

📊 핵심 개념​

서비스 (Service)​

ITIL에서 가장 중요한 개념. 모든 것을 "서비스"로 봄.

용어설명
서비스고객이 특정 비용/리스크 없이 원하는 결과를 얻도록 가치를 제공하는 수단
서비스 제공자서비스를 만들고 운영하는 조직 (IT 부서, MSP 등)
서비스 소비자서비스를 사용하는 사람/조직 (사용자, 고객)

인프라 관점 예시:

서비스제공자소비자
이메일 시스템IT 인프라팀전 직원
ERP 시스템SI 운영팀업무 담당자
클라우드 IaaSCSP (AWS, NCP 등)개발팀

가치 (Value)​

ITIL 4의 핵심 철학: IT 활동의 목적은 가치 창출.

개념질문인프라 예시
유용성"필요한 기능이 있나?"DB 서비스가 CRUD를 지원하는가
보증"안정적으로 쓸 수 있나?"가용성 99.9%, 응답시간 3초 이내

🏗️ ITIL 4 서비스 가치 체계 (SVS)​

ITIL 4의 최상위 구조. 모든 구성 요소가 가치 창출을 향함.

구성 요소설명
지도 원칙의사결정의 가이드라인 (7개)
거버넌스조직의 방향 설정, 감독
서비스 가치 사슬가치 창출의 운영 모델 (6개 활동)
프랙티스조직의 자원을 활용한 작업 수행 방법 (34개)
지속적 개선모든 수준에서의 지속적 개선

🧭 7대 지도 원칙 (Guiding Principles)​

모든 ITIL 활동에 적용되는 의사결정 가이드라인.

#원칙설명인프라 예시
1가치에 집중모든 활동이 가치 창출에 기여해야모니터링 대시보드가 실제 의사결정에 쓰이는가?
2현재에서 시작기존 것을 버리지 말고 활용AS-IS 장비 중 재활용 가능한 것은?
3피드백과 함께 반복한 번에 다 하지 말고 단계적으로전체 이관 대신 서비스별 순차 전환
4협업하고 가시성 확보사일로를 깨고 투명하게인프라/개발/보안 팀 간 장애 정보 공유
5총체적으로 사고부분이 아닌 전체를 보기네트워크만 빨라도 DB가 느리면 소용없음
6단순하고 실용적으로복잡한 프로세스는 지켜지지 않음변경 관리 절차가 실제로 실행 가능한가?
7최적화하고 자동화수작업을 줄이고 자동화반복 점검을 스크립트/자동화로 전환

💡 7번 원칙이 DevOps/자동화와 연결되는 지점. ITIL 4에서 Agile/DevOps를 포용하려는 의도가 반영됨.

🔗 서비스 가치 사슬 (Service Value Chain)​

가치를 만들어내는 6개 활동. 순서가 정해진 게 아니라 필요에 따라 조합함.

활동설명인프라 예시
Plan방향 설정, 포트폴리오 관리연간 인프라 투자 계획, 기술 로드맵
Improve지속적 개선성능 튜닝, 자동화 도입
Engage이해관계자와 소통사용자 요구사항 수집, SLA 협의
Design & Transition서비스 설계, 변경 관리신규 시스템 설계, 운영 이관
Obtain/Build서비스 구성 요소 확보장비 조달, 시스템 구축
Deliver & Support서비스 제공, 운영 지원일상 운영, 장애 대응, 백업

🛠️ 34개 프랙티스 (Practices)​

ITIL v3에서는 "프로세스"라고 불렀던 것. ITIL 4에서는 프랙티스로 확장 (프로세스 + 사람 + 기술 + 정보).

3개 카테고리​

카테고리수설명
일반 관리14조직 전반에 적용
서비스 관리17IT 서비스에 특화
기술 관리3기술 인프라 관련

핵심 프랙티스 (인프라 엔지니어 관점)​

34개 중 실무에서 자주 만나는 핵심 프랙티스를 중심으로 정리.

🔥 인시던트 관리 (Incident Management)​

인시던트: 서비스의 정상적인 운영을 중단시키거나 품질을 저하시키는 계획되지 않은 사건.

목표: 가능한 빨리 정상 서비스로 복구.

심각도/우선순위 매트릭스:

영향도 높음영향도 중간영향도 낮음
긴급도 높음P1 (Critical)P2 (High)P3 (Medium)
긴급도 중간P2 (High)P3 (Medium)P4 (Low)
긴급도 낮음P3 (Medium)P4 (Low)P4 (Low)

에스컬레이션:

유형설명예시
기능적 에스컬레이션전문 팀으로 이관L1 → L2 → L3
계층적 에스컬레이션상위 관리자에게 보고담당 → 팀장 → 부서장

인프라 인시던트 예시:

인시던트심각도대응
서버 다운 (서비스 중단)P1즉시 대응, HA 절체 확인
디스크 사용률 95%P2긴급 정리 또는 증설
백업 실패P3원인 확인, 재수행
모니터링 알림 오탐P4임계치 조정

💡 인시던트 관리의 핵심은 "원인 분석"이 아니라 "빠른 복구"임. 원인 분석은 문제 관리에서 함.

🔍 문제 관리 (Problem Management)​

문제 (Problem): 하나 이상의 인시던트의 근본 원인 또는 잠재적 원인.

목표: 인시던트의 근본 원인을 찾아 재발을 방지.

인시던트 vs 문제:

구분인시던트문제
성격증상원인
목표빠른 복구재발 방지
시간즉시 대응시간을 두고 분석
예시"서버가 죽었다""왜 서버가 죽었나?"

근본 원인 분석 (RCA) 기법:

기법설명
5 Whys"왜?"를 5번 반복하여 근본 원인 추적
피시본 다이어그램원인을 카테고리별로 분류 (HW, SW, Network, 인적 오류)
타임라인 분석장애 발생 전후 이벤트를 시간순 정리

5 Whys 예시:

인시던트: WAS 서버 응답 지연

1. 왜? → WAS 서버 CPU 100%
2. 왜? → 특정 쿼리가 무한 루프
3. 왜? → 인덱스 없이 Full Scan
4. 왜? → 테이블 변경 후 인덱스 미적용
5. 왜? → 변경 시 DBA 리뷰 절차 없음

→ 근본 원인: DB 변경 관리 프로세스 부재
→ 대응: DB 변경 시 DBA 리뷰 필수화

🔄 변경 관리 (Change Enablement)​

변경 (Change): IT 서비스에 영향을 줄 수 있는 모든 추가, 수정, 제거.

목표: 변경으로 인한 장애를 최소화하면서 신속하게 변경 수행.

💡 ITIL 4에서는 "Change Management"가 아니라 **"Change Enablement"**로 이름이 바뀜. 변경을 통제하는 것이 아니라 가능하게 하는 것이 목적.

변경 유형:

유형승인리스크예시
표준 변경사전 승인낮음사용자 계정 생성, 패스워드 리셋
일반 변경CAB 승인중간방화벽 룰 추가, 서버 증설, 패치
긴급 변경긴급 CAB높음보안 취약점 긴급 패치, 장애 대응

CAB (Change Advisory Board):

역할설명
구성PM, 인프라, 개발, 보안, 운영 담당자
목적변경의 리스크/영향 평가, 승인/반려
회의정기 (주 1회) + 긴급 시 수시

PIR (Post-Implementation Review):

변경 후 검토. "변경이 성공했는가? 문제는 없는가?"

점검내용
목표 달성변경 목적이 달성되었는가
부작용예상치 못한 영향은 없는가
프로세스변경 절차가 적절했는가
교훈개선할 점은 무엇인가

📊 서비스 수준 관리 (Service Level Management)​

SLA (Service Level Agreement): 서비스 제공자와 고객 간에 합의한 서비스 수준.

목표: 서비스 품질 목표를 설정하고, 측정하고, 관리.

SLA 구조:

항목내용예시
가용성서비스 가동 시간 비율99.9% (월 43분 이하 중단)
응답 시간서비스 요청 후 응답까지3초 이내 (95 percentile)
장애 대응장애 인지 후 대응 시작까지P1: 15분, P2: 30분
복구 시간장애 발생 후 복구까지P1: 1시간, P2: 4시간
보고운영 보고 주기월간 운영 보고서

SLA 관련 용어:

용어설명
SLAService Level Agreement — 고객과의 합의 (외부)
OLAOperational Level Agreement — 내부 조직 간 합의
UCUnderpinning Contract — 외부 벤더와의 계약

SLA 위반 시:

단계대응
경고임계치 접근 시 사전 알림
위반원인 분석, 재발 방지 계획
반복 위반서비스 개선 계획 (SIP), 계약 조정

📦 서비스 구성 관리 (Service Configuration Management)​

CI (Configuration Item): 관리 대상이 되는 모든 구성 요소.

CMDB (Configuration Management Database): CI와 그 관계를 저장하는 데이터베이스.

CI 유형예시
HW서버, 스위치, 스토리지, 방화벽
SWOS, 미들웨어, DB, 애플리케이션
문서설계서, 운영 매뉴얼, SOP
서비스이메일, ERP, 웹 서비스

CMDB가 중요한 이유:

  • 장애 시: "이 서버가 죽으면 어떤 서비스가 영향받지?" → CMDB에서 관계 추적
  • 변경 시: "이 스위치를 바꾸면 어떤 서버가 연결되어 있지?" → 영향 범위 파악
  • 용량 관리: 전체 자산 현황 파악

CMDB 도구:

도구특징
ServiceNow엔터프라이즈 ITSM 플랫폼
NetBox오픈소스 IPAM + DCIM
iTop오픈소스 CMDB/ITSM
Jira Service ManagementAtlassian 생태계

🔁 지속적 개선 (Continual Improvement)​

모든 프랙티스에 적용되는 상위 개념임. PPDIOO의 Optimize와 직접 연결됨.

개선 레지스터 (Improvement Register):

모든 개선 아이디어를 기록하고 추적하는 목록.

ID개선 항목출처우선순위상태담당
1백업 자동화인시던트 분석높음진행 중인프라팀
2모니터링 임계치 조정오탐 과다중간대기운영팀
3패치 관리 자동화보안 감사높음계획보안팀

🏗️ 추가 주요 프랙티스​

릴리스 관리 (Release Management)​

새로운 서비스나 변경된 서비스를 운영 환경에 배포하는 것을 관리함.

항목설명
릴리스 계획배포 일정, 순서, 롤백 계획
빌드/테스트스테이징 환경에서 검증
배포운영 환경에 적용
사후 검증배포 후 정상 동작 확인

IT 자산 관리 (IT Asset Management)​

IT 자산의 전체 수명주기를 관리함.

단계활동
조달구매/임대, 라이선스 확보
배치설치, 구성, 사용자 할당
운영사용 추적, 유지보수
폐기EOL 장비 처분, 데이터 삭제

가용성 관리 (Availability Management)​

SLA에 정의된 가용성 수준을 달성하고 유지함.

지표계산설명
가용성(%)(합의시간 - 중단시간) / 합의시간 × 100서비스 가동률
MTBF총 가동시간 / 장애 횟수평균 장애 간격
MTTR총 중단시간 / 장애 횟수평균 복구 시간
MTBSIMTBF + MTTR평균 장애 간 시간
예시:
  월간 서비스 시간: 720시간
  중단 시간: 43분 (0.72시간)
  
  가용성 = (720 - 0.72) / 720 × 100 = 99.9%

용량 및 성능 관리 (Capacity and Performance Management)​

현재와 미래의 용량/성능 요구를 충족하도록 관리함.

활동설명
모니터링CPU, 메모리, 디스크, 네트워크 사용률 추적
트렌드 분석사용량 증가 추세 파악
용량 계획향후 필요 용량 예측, 증설 계획
성능 튜닝병목 식별, 최적화

🏢 공공 SI에서의 ITIL 적용​

적용 시점​

SI 프로젝트가 끝나면 운영 단계로 넘어감. 이때 ITIL 기반 운영 체계가 적용됨.

공공 운영에서 자주 쓰이는 프랙티스​

프랙티스공공 적용
인시던트 관리장애 대응 체계, 심각도 분류, 에스컬레이션
문제 관리반복 장애 분석, RCA, 재발 방지
변경 관리모든 변경 기록, CAB 승인, 롤백 계획
서비스 수준 관리SLA 정의, 월간 보고, 가용성 측정
구성 관리자산 대장, CMDB, 구성 변경 추적

운영 보고서​

보고서주기내용
일일 점검매일시스템 상태, 이벤트, 백업 결과
주간 보고매주인시던트 현황, 변경 이력, 이슈
월간 보고매월SLA 달성률, 성능 추이, 용량 현황
분기 보고분기운영 종합, 개선 사항, 차기 계획

RFP/제안서에서의 ITIL​

RFP나 제안서에서 ITIL 관련 문구가 나오는 패턴:

맥락예시 문구
운영 체계"ITIL 기반 IT 서비스 관리 체계 수립"
장애 관리"ITIL 인시던트/문제 관리 프로세스 적용"
변경 관리"ITIL 변경 관리 절차에 따른 체계적 변경 통제"
SLA"ITIL 서비스 수준 관리 기반 SLA 관리"

🆚 ITIL v3 vs ITIL 4​

구분ITIL v3 (2011)ITIL 4 (2019)
구조5단계 라이프사이클서비스 가치 체계 (SVS)
단계전략→설계→전환→운영→개선가치 사슬 6개 활동
단위26개 프로세스34개 프랙티스
접근프로세스 중심가치/원칙 중심
Agile/DevOps제한적적극 포용
유연성순차적 라이프사이클필요에 따라 활동 조합

ITIL v3 서비스 라이프사이클 (참고):

💡 공공 SI에서는 아직 ITIL v3 용어(프로세스, 라이프사이클)를 쓰는 경우가 많음. v4의 개념은 알되, v3 용어도 병행해서 이해하면 좋음.

📋 요약​

핵심 구조​

구분내용
SVS지도 원칙 + 거버넌스 + 가치 사슬 + 프랙티스 + 지속적 개선
7대 원칙가치 집중, 현재에서 시작, 반복, 협업, 총체적, 단순, 자동화
6개 가치 사슬 활동Plan, Improve, Engage, Design/Transition, Obtain/Build, Deliver/Support
34개 프랙티스일반 관리(14) + 서비스 관리(17) + 기술 관리(3)

인프라 엔지니어가 꼭 알아야 할 프랙티스​

프랙티스핵심
인시던트 관리빠른 복구가 목표, 원인 분석은 문제 관리에서
문제 관리근본 원인 분석(RCA), 재발 방지
변경 관리모든 변경은 기록/승인, 롤백 계획 필수
서비스 수준 관리SLA 정의, 측정, 보고
구성 관리CMDB로 CI와 관계 추적

🔗 관련 문서​

🔗 참고 자료​