💡 핵심 인사이트
변경 관리는 잘 굴러가고 있는 살아있는 IT 시스템(서버, DB, 네트워크)에 무언가 '변경(업데이트, 패치, 설정 변경)'을 가할 때, 그 변경이 나비효과를 일으켜 시스템 전체를 마비시키는 참사(장애)를 막기 위해, 사전에 리스크를 평가하고 공식적인 허락(승인)을 받는 깐깐한 문지기 프로세스입니다.

Ⅰ. 변경 관리가 필요한 이유 (장애의 80%는 사람 손에서 시작)

"DB 서버 메모리 설정값 1줄만 살짝 바꾸고 몰래 재부팅해야지~" (엔지니어의 흔한 생각) 결과는 참혹합니다. 그 DB를 물고 있던 회사의 쇼핑몰, 사내 결재망, 메일 서버가 도미노처럼 무너집니다.

통계에 따르면 전체 IT 대형 장애의 80% 이상은 하드웨어 고장이 아니라, 엔지니어가 무언가를 '변경(업데이트, 설정 수정)'하다가 발생한 휴먼 에러(사이드 이펙트) 때문입니다. 이 끔찍한 폭발을 막기 위해 모든 변경 작업은 엄격한 심판대(변경 관리 프로세스)를 거쳐야만 합니다.

Ⅱ. 변경 관리 프로세스의 핵심 요소

1. 변경 승인 위원회 (CAB, Change Advisory Board)

엔지니어 혼자 판단해서 바꾸지 못하게 막는 공식 심의 기구입니다. IT 부서장, 보안 담당자, 비즈니스 현업 부서 대표가 한자리에 모입니다.

• 개발자가 "주말에 쇼핑몰 검색 엔진 교체(변경)할게요"라고 기안을 올리면, CAB이 모여서 묻습니다.
• "그거 하다가 실패하면 어떻게 롤백(Rollback, 원상 복구)할 계획은 세워놨어?"
• "그거 잠깐 끄는 동안 주말에 매출 떨어지는 건 현업 영업팀과 합의됐어?" 이 철저한 영향도 평가(Impact Analysis)를 통과해야만 비로소 변경 '승인(Approve)'이 떨어집니다.

2. 변경의 3가지 유형

모든 변경을 CAB 회의로 올리면 너무 느리므로(애자일에 반함), 위험도에 따라 분류합니다.

1. 표준 변경 (Standard Change):
   • 노트북 메모리 추가, 특정 포트 방화벽 오픈 등 위험도가 거의 없고 이미 매뉴얼이 확립된 일상적 작업입니다. CAB 회의 없이 서비스 데스크가 바로 승인합니다.
2. 일반 변경 (Normal Change):
   • 새로운 서버 OS 업데이트, 대규모 DB 마이그레이션 등입니다. 만약 실패하면 대형 장애가 날 수 있으므로 반드시 CAB의 정식 회의와 평가, 승인을 거쳐야 하는 메인 프로세스입니다.
3. 긴급 변경 (Emergency Change):
   • 치명적인 해킹(랜섬웨어) 방어 패치를 깔거나, 뻗어버린 서버를 긴급 우회할 때 씁니다. 당장 불이 났는데 모여서 회의할 시간이 없으므로, ECAB(긴급 승인 위원회, 소수 임원)가 유선으로 5분 만에 초고속 승인하고 선(先)조치 후(後)보고 합니다.

Ⅲ. 변경(Change)과 릴리스(Release)의 차이점

두 프로세스가 비슷해 보이지만 구별해야 합니다.

• 변경 관리: "이거 지금 서버에 적용해도 회사가 안 망할까? 영업팀 동의했어?"를 따지는 비즈니스적 위험 심사(허락) 과정입니다.
• 릴리스 관리: CAB의 허락이 떨어졌을 때, 그 코드를 들고 실제로 토요일 새벽에 서버실에 가서 땀 흘리며 시스템에 복사/설치하고 테스트하는 물리적 배포 실행(행동) 과정입니다.

📢 섹션 요약 비유: 변경 관리는 번화가 한가운데서 수도관 공사를 하기 위해 구청에 내는 **'도로 점용 허가 심사'**입니다. 구청(CAB)은 무작정 땅을 파게 두지 않고, "먼지 나는 건 상인(현업)과 합의했냐?", "차량 우회 도로(롤백 플랜)는 그렸냐?"를 철저히 검열한 뒤 통과(승인) 도장을 찍어주어, 공사로 인한 도심 마비를 사전에 막는 방파제입니다.