핵심 인사이트

  1. 본질: 변경 관리는 IT 환경의 변경이 서비스 중단·보안 사고 없이 통제되도록 승인·일정·구현·검토를 표준화하는 프로세스다.
  2. 가치: CAB(Change Advisory Board)의 집단 지성 승인은 변경 위험을 사전에 평가하며, 표준 변경(Standard Change) 사전 승인으로 민첩성을 잃지 않는다.
  3. 판단 포인트: 변경의 70%는 위험도가 낮은 표준 변경으로 사전 승인 가능하며, CAB 부담을 줄이면서 비긴급 변경의 신속 처리가 가능하다.

Ⅰ. 개요 및 필요성

변경 관리(Change Management)는 ITIL v3 ST(서비스 전환)의 핵심 프로세스이자 ITIL 4의 변경 실천(Change Enablement Practice)이다. 모든 IT 환경 변경—소프트웨어 패치, 네트워크 구성, 서버 증설, 데이터베이스 변경—은 통제되지 않으면 서비스 중단 또는 보안 취약점 도입의 위험이 있다.

RFC(Request for Change)는 변경을 공식 요청하는 문서로, CAB(Change Advisory Board)가 검토·승인한다. CAB는 기술 전문가, 서비스 관리자, 비즈니스 대표, 보안 담당자 등으로 구성된 다학제 위원회다. 긴급 변경(Emergency Change)은 ECAB(Emergency CAB)가 축소 인원으로 신속 승인한다.

📢 섹션 요약 비유: 변경 관리는 공사 허가증 제도다. 허가 없이 공사하면 배관이 터지듯, 승인 없는 IT 변경은 서비스 장애를 일으킨다. 단, 소규모 보수는 사전 승인으로 빠르게 처리한다.

Ⅱ. 아키텍처 및 핵심 원리

변경 유형설명승인 방식위험도
표준 변경 (Standard)사전 승인된 낮은 위험 변경사전 승인 목록낮음
일반 변경 (Normal)CAB 검토 후 승인CAB 정기 회의중간
긴급 변경 (Emergency)즉각 대응 필요, ECAB 승인ECAB 긴급 회의높음
┌────────────────────────────────────────────────────────────────┐
│                변경 관리 승인 흐름                              │
│                                                                │
│  변경 요청(RFC) 제출                                           │
│         │                                                      │
│         ▼                                                      │
│  변경 유형 분류                                                │
│  ┌──────┬──────────┬──────────┐                               │
│  │표준  │ 일반     │ 긴급     │                               │
│  └──┬───┘ └────┬───┘ └────┬───┘                               │
│     ▼           ▼          ▼                                   │
│  사전 승인    CAB 검토   ECAB 긴급                             │
│  목록 확인   정기 회의   소집                                  │
│     │           │          │                                   │
│     └───────────┴──────────┘                                  │
│                 │                                              │
│                 ▼                                              │
│         변경 일정 수립 (Change Schedule)                       │
│                 │                                              │
│                 ▼                                              │
│     변경 구현 → 테스트 → 서비스 복구 확인                     │
│                 │                                              │
│                 ▼                                              │
│         PIR (Post Implementation Review)                       │
│         CMDB CI 업데이트                                       │
└────────────────────────────────────────────────────────────────┘

📢 섹션 요약 비유: 표준 변경은 사전 허가된 '동네 공사', 일반 변경은 구청 허가 필요한 '건물 개조', 긴급 변경은 소방서가 즉시 출동하는 '화재 대응 공사'다.

Ⅲ. 비교 및 연결

항목ITIL v3 변경 관리ITIL 4 변경 실천 (Change Enablement)
용어Change ManagementChange Enablement
초점위험 통제속도 + 통제 균형
표준 변경있음확대 (자동화 권장)
민첩성낮음 (CAB 지연)DevOps 파이프라인 통합
CAB 역할모든 변경 검토복잡·위험 변경에 집중

📢 섹션 요약 비유: ITIL v3 CAB는 모든 공사 하나하나에 도장을 찍는 관청이라면, ITIL 4 CAB는 위험한 공사만 집중 심의하고 나머지는 자동화로 처리하는 스마트 행정이다.

Ⅳ. 실무 적용 및 기술사 판단

DevOps 조직에서는 CI/CD 파이프라인의 자동화 테스트·배포를 '표준 변경' 카테고리로 등록해 CAB 없이 배포한다. ITIL 4 Change Enablement는 이를 공식화했다. PIR(Post Implementation Review)은 변경 완료 후 의도치 않은 부작용을 확인하며, CMDB를 업데이트해 구성 정보를 최신 상태로 유지한다. Freeze Period(변경 동결 기간)—명절·주요 행사 전후—에는 긴급 변경 외 모든 변경을 금지하는 것이 운영 관행이다.

📢 섹션 요약 비유: 변경 동결 기간은 시험 전날 밤 컴퓨터를 업데이트하지 않는 것과 같다. 지금 잘 되고 있으면 굳이 건드리지 않는다.

Ⅴ. 기대효과 및 결론

체계적인 변경 관리는 변경 유발 인시던트(Change-Induced Incidents)를 60~80% 감소시킨다. 표준 변경 자동화와 DevOps 파이프라인 통합으로 배포 빈도는 높이면서 장애율은 낮추는 'DORA 지표 개선'을 실현할 수 있다.

📢 섹션 요약 비유: 변경 관리는 비행기 정비 프로세스다. 정비를 잘 통제하면 더 많이, 더 빠르게 비행할 수 있다. 통제 없는 정비는 추락을 부른다.

📌 관련 개념 맵

개념설명연관 키워드
RFC (Request for Change)변경 공식 요청 문서CAB, 변경 관리
CAB (Change Advisory Board)변경 위험 평가·승인 위원회일반 변경, ITIL
ECAB (Emergency CAB)긴급 변경 신속 승인 소위원회긴급 변경, MTTR
PIR (Post Implementation Review)변경 사후 검토CMDB 업데이트, 교훈
DORA 지표DevOps 성과 측정 4대 지표배포 빈도, MTTR

👶 어린이를 위한 3줄 비유 설명

  1. 변경 관리는 집을 리모델링하기 전에 '어디 벽을 부숴도 되는지' 전문가에게 확인하는 과정이에요.
  2. 작은 못 박기(표준 변경)는 미리 허가받아 바로 하고, 큰 공사(일반 변경)는 위원회 회의로 결정해요.
  3. 불이 나면 소방서(ECAB)가 즉시 출동해 빠르게 긴급 변경을 처리해요.