금요일 오후 5시 50분.
협력사 엔지니어가 "캐시 설정만 살짝 고치면 응답이 빨라진다"며 운영 서버 설정을 한 줄 바꿉니다. 테스트도, 기록도, 알림도 없었습니다. 10분 뒤 주문 서비스가 통째로 멈춥니다. 당직자는 "방금 누가 뭘 바꿨는지" 알 길이 없어, 멈춘 원인을 찾는 데만 한 시간을 씁니다. 바꾼 사람은 이미 퇴근했습니다.
옆 팀은 같은 캐시 설정을 바꾸는데도 절차가 다릅니다. 무엇을, 왜 바꾸는지 변경 요청을 등록하고, 그 설정에 무엇이 의존하는지 CMDB로 확인해 영향 범위를 보고, 언제(점검창)·누가 승인·안 되면 어떻게 되돌릴지(롤백) 를 정한 뒤 적용합니다. 같은 변경이지만 한쪽은 장애를 낳고, 한쪽은 조용히 끝납니다.
차이는 손기술이 아니라 변경을 통제하는 체계입니다. 운영 인시던트의 가장 흔한 원인은 해킹도 하드웨어 고장도 아닌 통제되지 않은 변경입니다. 이 모듈은 변경을 막는 법이 아니라, 변경을 안전하게 흘려보내는 법을 다룹니다.
- 1변경(Change)을 "운영 환경의 상태를 바꾸는 의도적 추가·수정·제거"로 정의하고, 일상 운영 작업과 구분할 수 있다
- 2표준 변경·일반 변경·긴급 변경 세 유형을 승인 경로와 리스크 기준으로 구분할 수 있다
- 3변경 리스크를 영향도와 발생 가능성 축으로 평가하고, 리스크 등급에 맞는 승인·점검창·롤백 수준을 정할 수 있다
- 4통제되지 않은 변경이 왜 인시던트의 최대 원인이 되는지, CMDB·영향도 분석이 왜 리스크 평가의 핵심인지 설명할 수 있다
- 5변경 유형 분류 표와 리스크 평가 표를 직접 작성해 실제 변경 요청에 적용할 수 있다
변경이란 무엇인가 — 일상 운영과 무엇이 다른가
운영 상태를 의도적으로 바꾸면 그것이 변경이다
장애를 끄는 일(인시던트)은 "원래 상태로 되돌리는" 일입니다. 반면 변경은 지금까지와 다른 상태를 의도적으로 만드는 일입니다. 그래서 변경에는 항상 "혹시 더 나빠지면?"이라는 리스크가 따라옵니다. 변경 관리(ITIL 4에서는 변경 활성화, Change Enablement)는 그 리스크를 통제해 변경의 속도는 살리고 사고는 줄이는 활동입니다.
ITIL 4는 변경을 이렇게 정의합니다: "하나 이상의 구성요소(CI)에 대한, 서비스에 직접·간접으로 영향을 줄 수 있는 의도적인 추가·수정·제거." 핵심 단어는 세 가지입니다.
- 의도적: 사람이 일부러 하는 일. 디스크가 저절로 고장 난 것은 변경이 아니라 인시던트의 원인입니다.
- 상태 변경: 추가(새 서버 투입)·수정(설정 변경, 코드 배포)·제거(서버 폐기, 기능 삭제) 모두 포함합니다.
- 영향 가능성: 운영 서비스에 영향을 줄 수 있어야 변경 통제의 대상입니다.
| 작업 | 변경인가? | 이유 |
|---|---|---|
| 결제 모듈 v2 운영 배포 | 변경 (일반) | 운영 서비스 동작을 의도적으로 바꿈 |
| 만료 직전 SSL 인증서 갱신 | 변경 (표준) | 정형화·반복·저위험 절차 |
| 진행 중 장애 복구용 긴급 핫픽스 | 변경 (긴급) | 의도적 수정이지만 정상 절차를 기다릴 수 없음 |
| 멈춘 서비스를 재시작해 원상 복구 | 변경 아님 (인시던트 대응) | 새 상태가 아니라 원래 상태로 되돌림 |
| 로그 조회·모니터링 대시보드 확인 | 변경 아님 | 상태를 바꾸지 않음 |
여기서 자주 헷갈리는 두 가지를 못 박아 둡니다. 첫째, 장애 복구를 위한 재시작/롤백 자체는 인시던트 대응입니다. 다만 그 복구를 위해 새 핫픽스를 배포한다면 그것은 변경(긴급 변경)입니다. 둘째, "구성을 바꾸는 거의 모든 일은 변경"이라는 감각이 중요합니다 — 설정 한 줄, 방화벽 규칙 하나, DNS 레코드 하나도 변경입니다.
변경의 세 가지 유형 — 표준·일반·긴급
모든 변경을 같은 무게로 다루지 않는다
변경마다 위험과 빈도가 다른데 전부 똑같이 무거운 승인 절차를 거치면, 정작 급한 변경은 늦어지고 사소한 변경에 사람이 지칩니다. 그래서 변경을 세 유형으로 나눠 통제의 무게를 다르게 둡니다. 통제를 줄이는 게 목적이 아니라, 리스크에 비례한 통제가 목적입니다.
- 표준 변경(Standard Change): 리스크가 낮고, 절차가 사전에 정의·승인되어 있으며, 자주 반복되는 변경. 인증서 갱신, 정기 OS 패치, 정형화된 계정 생성 등. 실행할 때마다 변경자문위원회(CAB)를 거치지 않고 사전 승인된 절차로 빠르게 처리합니다. 단, "이 작업을 표준 변경으로 등록하는 것" 자체는 한 번 정식으로 평가·승인받아야 합니다(아무거나 표준으로 부르면 안 됨).
- 일반 변경(Normal Change): 표준으로 미리 승인되지 않은, 매번 리스크 평가와 승인이 필요한 변경. 신규 서비스 배포, 아키텍처 변경, 대규모 마이그레이션 등. 리스크 등급에 따라 권한자 승인 또는 CAB(변경자문위원회) 검토를 거칩니다. 변경 관리의 표준 경로입니다.
- 긴급 변경(Emergency Change): 정상적인 일반 변경 절차를 기다릴 수 없는 상황(주로 진행 중인 장애 복구나 보안 긴급 패치)을 위한 예외 경로. 정규 CAB 대신 긴급 변경자문위원회(ECAB) 또는 긴급 권한자의 축약된 신속 승인을 받고 실행하며, 사후에 정식 검토를 합니다. 빠르지만 가장 위험한 경로라서, 기록과 사후 검토가 특히 중요합니다.
여기서 가장 흔한 오해를 짚습니다. "긴급 변경 = 빨라서 좋은 것"이 아닙니다. 긴급 변경은 통제를 '없애는' 게 아니라 '축약'하는 것이고, 사후 검토 부담이 더 큽니다. 평소 일반 변경으로 충분히 처리할 수 있는 것을 "급하다"는 이유로 긴급으로 밀어붙이면, 통제를 우회하는 나쁜 습관이 굳어지고 결국 그것이 다음 장애가 됩니다.
그림: 변경은 리스크에 비례해 통제의 무게를 다르게 둔다 — 일률 승인이 아니라 비례 통제다.
변경 리스크를 평가한다 — 영향도 × 발생 가능성
리스크는 직감이 아니라 두 축으로 매긴다
"이 변경 위험한가요?"에 직감으로 답하면 사람마다 다르고, 급할수록 과소평가합니다. 그래서 리스크를 두 축으로 분해해 등급을 매깁니다.
- 영향도(Impact): 변경이 실패했을 때 얼마나 많은, 얼마나 중요한 것에 피해가 가는가. 핵심 서비스(결제·주문)인가, 영업시간 중인가, 몇 명이 영향받는가, 되돌리기 쉬운가. 이 영향도를 정확히 보려면 CMDB와 영향도 분석이 필요합니다 — 바꾸려는 구성요소(CI)에 무엇이 의존하는지(블래스트 반경)를 알아야 진짜 영향 범위가 보입니다.
- 발생 가능성(Likelihood): 그 실패가 실제로 일어날 확률. 검증된 절차인가, 테스트 환경에서 검증했는가, 처음 해보는 작업인가, 의존 관계가 복잡한가.
두 축을 곱해 리스크 등급(낮음·중간·높음) 을 얻고, 그 등급에 따라 승인 수준·점검창·롤백 준비·참관 인원을 정합니다. 핵심은 리스크가 클수록 통제를 두껍게, 작을수록 가볍게 — 일률적 통제가 아니라 비례 통제입니다.
| 리스크 등급 | 영향도 × 발생 가능성 예시 | 승인 경로 | 일정·점검창 | 롤백 준비 |
|---|---|---|---|---|
| 낮음 | 영향 작음 + 검증된 절차 (표준 변경 대다수) | 사전 승인 절차로 충분 | 업무 영향 적은 시간대 | 표준 롤백 절차 |
| 중간 | 일부 서비스 영향 + 일부 불확실 | 변경 권한자 승인 | 지정된 점검창 | 명시적 롤백 계획·검증 |
| 높음 | 핵심 서비스 + 의존성 복잡 + 처음 하는 작업 | CAB 검토·승인 | 야간/주말 점검창, 사전 공지 | 롤백 리허설·참관·중단 기준 사전 정의 |
그림: 리스크 등급은 영향도(CMDB로 본 블래스트 반경)와 발생 가능성(검증·경험의 정도)의 교차로 정해지고, 그 등급이 승인·점검창·롤백의 무게를 결정한다.
영향도를 매길 때 던지는 실무 질문은 정해져 있습니다: (1) 어떤 서비스가 영향받나(CMDB 의존 관계로 확인), (2) 영업시간인가, (3) 되돌릴 수 있나·얼마나 걸리나, (4) 이 변경에 묶인 다른 변경이 있나(변경 충돌·일정 중첩). 이 질문들의 답이 안 좋을수록 등급은 올라갑니다.
직접 해보기 — 변경 유형 분류와 리스크 등급 매기기
아래 5건을 (1) 변경 유형(표준·일반·긴급, 또는 변경 아님)으로 분류하고, (2) 변경이라면 영향도와 발생 가능성을 따져 리스크 등급(낮음·중간·높음)과 어울리는 승인 경로를 적어 보세요. 정답과 근거는 ObserveBlock에 있습니다.
A. "내일 새벽, 만료 임박한 와일드카드 SSL 인증서를 정해진 절차대로 갱신합니다." (반복·검증된 절차)
B. "다음 주, 결제 DB를 신규 버전으로 마이그레이션합니다. 주문·정산 서비스가 이 DB에 의존합니다." (처음 하는 작업)
C. "지금 결제 서비스 장애 진행 중. 핫픽스를 즉시 배포해야 매출 손실을 멈춥니다." (장애 대응)
D. "사내 위키 페이지의 오타 하나를 고치려 합니다." (운영 서비스 영향 없음)
E. "사내 그룹웨어에 새 알림 배너 기능을 배포합니다. 전 직원 사용, 영업시간 중 적용 예정." (신규 기능)
분류 직관: 먼저 "반복·사전승인 절차인가(표준)" → "장애를 못 기다리는가(긴급)" → 나머지는 대개 "일반"입니다. 리스크는 무엇에 의존하는가(영향도) × 얼마나 검증됐는가(발생 가능성) 로 봅니다.
유형: 표준 / 일반 / 긴급 · 리스크: 낮음 / 중간 / 높음- A = 표준 변경 / 리스크 낮음. 반복·검증된 사전 승인 절차이므로 CAB 없이 표준 절차로 처리. 업무 영향 적은 새벽 시간대
- B = 일반 변경 / 리스크 높음. 핵심 서비스(주문·정산)가 DB에 의존(CMDB로 블래스트 반경 확인) + 처음 하는 작업 → CAB 승인, 야간 점검창, 롤백 리허설·중단 기준 사전 정의
- C = 긴급 변경 / 리스크 상황상 불가피. 정상 절차를 기다릴 수 없는 장애 복구 → ECAB/긴급 권한자 신속 승인 후 배포, 변경 기록·롤백 계획·사후 정식 검토 반드시 남김
- D = 변경 아님(또는 통제 대상 외). 운영 서비스 동작에 영향 없는 문서 수정. 굳이 변경 절차에 넣어 과잉 통제하지 않는다
- E = 일반 변경 / 리스크 중간. 전사 사용이라 영향은 넓지만 비교적 단순·되돌리기 쉬움 → 변경 권한자 승인, 점검창 지정, 명시적 롤백 계획. 가능하면 영업시간 외로 조정
- 핵심 감각: 같은 "배포"라도 무엇에 의존하고(영향도) 얼마나 검증됐는가(발생 가능성)에 따라 통제의 무게가 달라진다 — 일률 승인이 아니라 리스크 비례 통제
현장에서 자주 보는 함정
증상: 한 팀이 캐시 서버 설정을 바꿨을 뿐인데, 직접 건드리지도 않은 주문 서비스가 같이 멈춥니다. 게다가 당직자는 "방금 누가 무엇을 바꿨는지" 알 수 없어, 멈춘 원인을 찾는 데만 한 시간을 씁니다.
원인: 두 가지 통제 누락이 겹쳤습니다. (1) 영향도 분석을 건너뜀 — 그 캐시 구성요소에 주문 서비스가 의존한다는 사실(블래스트 반경)을 CMDB로 확인하지 않아, 영향 범위를 과소평가했습니다. (2) 변경 기록이 없음 — 무엇을·언제·왜 바꿨는지 변경 요청이 없으니, 장애가 나도 원인을 변경으로 좁히지 못해 복구가 느려졌습니다. 통제되지 않은 변경이 인시던트의 최대 원인이 되는 전형적 경로입니다.
해결 방향(이 트랙에서 깊어짐):
- 모든 변경은 변경 요청으로 기록 → 장애 시 "최근 변경부터 의심"이라는 가장 빠른 추적 경로를 확보.
- 변경 전 CMDB로 의존 관계를 확인해 영향도를 산정 → 진짜 블래스트 반경을 보고 리스크 등급을 매김.
- 리스크에 맞는 승인·점검창·롤백 계획을 사전에 정의 → 실패해도 정해진 절차로 빠르게 원상 복구.
- 변경과 인시던트를 연결해 추적 → 변경이 원인인 장애 비율을 측정하고 줄여 나감.
변경 관리는 변경을 막는 일이 아니라, 변경을 보이게(기록)·예측 가능하게(영향도)·되돌릴 수 있게(롤백) 만들어 장애를 줄이는 일입니다.
발주사·원청의 IT 운영 담당, 서비스데스크·운영(SM) 관리, 프로젝트 관리(PM/PMO) 자리에서 변경 관리는 매일 마주치는 통제 지점입니다. 실제 작업은 협력사(하도급) 엔지니어가 하더라도, "이 변경이 무엇에 영향을 주고, 누가 승인했고, 언제 어떤 점검창에 적용하며, 실패하면 어떻게 되돌리는가" 를 설계하고 통제하는 책임은 관리자에게 있습니다.
현장에서 관리자는 협력사가 올린 변경 요청서를 보고 "이 변경의 영향 범위가 정말 이게 다인가(CMDB 의존 관계와 맞는가)", "리스크 등급에 비해 승인 경로와 롤백 계획이 충분한가", "점검창과 사전 공지가 잡혀 있는가"를 검토합니다. 기술을 아는 관리자는 "캐시 설정만 바꾸는 거라 영향 없다"는 말에 속지 않고, "그 캐시에 주문 서비스가 매여 있지 않냐"고 되물을 수 있습니다.
특히 금요일 오후·연휴 직전·이벤트 기간 같은 변경 동결(change freeze) 구간을 정하고, 변경 일정이 서로 충돌하지 않게 조율하는 것도 관리자의 일입니다. 통제 없는 변경이 인시던트의 최대 원인이라는 사실은, 곧 변경 관리가 운영 안정성에 가장 직접적으로 기여하는 관리 활동이라는 뜻입니다.
관련 모듈로 더 깊이:
- 변경요청서와 영향도 분석 — 변경을 실제로 흘려보내는 변경요청서(RFC)와 영향도 분석
- CAB와 변경 승인 — 변경을 누가 어떤 경로로 심의·승인하는지(CAB·ECAB)
- 구성 관리와 CMDB — 변경 영향 범위 판단의 근거가 되는 구성 관계 정보
다음 모듈에서는 이 변경을 실제로 흘려보내는 문서인 변경요청서(RFC)와 영향도 분석을 구체적으로 다룹니다 — 어떤 항목을 채우고, CMDB의 의존 관계로 영향 범위를 어떻게 산정하며, 승인·점검창·롤백 계획을 변경요청서에 어떻게 명시하는지 실무 양식으로 정리합니다.