금요일 오후 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로 의존 관계를 확인해 영향도를 산정 → 진짜 블래스트 반경을 보고 리스크 등급을 매김.
- 리스크에 맞는 승인·점검창·롤백 계획을 사전에 정의 → 실패해도 정해진 절차로 빠르게 원상 복구.
- 변경과 인시던트를 연결해 추적 → 변경이 원인인 장애 비율을 측정하고 줄여 나감.
변경 관리는 변경을 막는 일이 아니라, 변경을 보이게(기록)·예측 가능하게(영향도)·되돌릴 수 있게(롤백) 만들어 장애를 줄이는 일입니다.
심화 — 점검창이 희소자원이 되면, 변경은 뭉쳐서 위험해진다
심화: 야간 점검창 관행의 경제학 — 리스크 비례 통제가 죽는 경로
한국 기업 운영 현장에는 "운영 중 변경 금지"라는 불문율이 있습니다. 발주사 보안·운영 규정에 "변경은 지정 점검창(주로 심야·주말)에만"이 못 박혀 있는 경우도 흔합니다. 취지는 안전이지만, 이 규칙이 리스크와 무관하게 일률 적용되는 순간 역설이 시작됩니다.
- 점검창이 희소자원이 됩니다: 창이 월 1~2회뿐이면 그 사이에 변경이 적체됩니다. 다음 창이 열릴 때 여러 팀의 변경이 한 창에 몰리고, 변경의 배치 크기(batch size)가 커집니다. 변경 관리의 기본기 — 작게, 자주, 분리해서 — 와 정반대 방향입니다.
- 한 창에 몰린 변경은 서로를 오염시킵니다: 각 변경은 개별로 승인받았지만, 같은 새벽에 함께 적용될 변경들 사이의 상호작용은 아무도 평가하지 않습니다. 장애가 나면 어느 변경이 원인인지 분리할 수 없고, 롤백 순서도 얽힙니다.
- 새벽은 가장 안전한 시간이 아니라 가장 취약한 시간일 수 있습니다: 검증할 현업 담당자는 자고 있고, 참관 인력은 최소이고, 작업자는 피로합니다. 저위험 변경까지 새벽 3시에 하게 되면, 규칙이 만들어낸 피로가 규칙이 막으려던 실수를 만듭니다. 월요일 아침 장애가 유독 잦은 조직이라면 주말 점검창의 후유증을 의심해야 합니다.
- 형식화 신호: ① 점검창 하나에 변경이 상시 5건 이상 몰린다 ② 긴급 변경 비율이 계속 올라간다(창을 못 기다린 변경이 긴급이라는 이름으로 우회) ③ 표준 변경 카탈로그가 몇 년째 안 자란다 — 저위험 반복 작업조차 전부 점검창행이라 표준으로 등록할 유인이 없기 때문입니다.
- 처방: (1) 리스크 등급이 낮은 변경은 주간 적용을 공식 허용하고 표준 변경 카탈로그로 흡수합니다 — "야간 = 안전"이 아니라 "리스크 비례 = 안전"이라는 원칙을 발주사와 규정 개정으로 합의합니다. (2) 점검창 내 변경 수에 상한을 두고, 같은 창에 배정된 변경 간 상호작용·롤백 순서를 창 단위로 한 번 더 검토합니다. (3) 긴급 변경 비율을 월간 지표로 관리합니다 — 이 숫자는 개별 변경이 아니라 변경 절차 자체의 건강도를 보여주는 체온계입니다.
점검창 규칙은 안전장치로 태어나지만, 일률 적용되는 순간 변경을 뭉치게 만들어 스스로 리스크를 키웁니다. 좋은 변경 통제는 변경을 밤으로 몰아넣는 것이 아니라 작고 자주, 리스크에 맞는 시간에 흘려보내는 것입니다.
상황: 분기 점검창(일요일 01:00~05:00)에 변경이 몰렸습니다 — 보안팀의 방화벽 정책 정비, 운영팀의 WAS 버전 패치, 개발팀의 배치 스케줄 변경. 세 건 모두 개별로는 승인이 끝난 상태였습니다. 월요일 08:40, 대외 서비스에 간헐적 타임아웃이 시작됩니다. 상황실에서 "어젯밤 뭐가 들어갔죠?"라는 질문에 세 팀이 각자 "저희 건은 검증 끝났습니다"라고 답합니다. 어느 변경이 원인인지, 조합이 원인인지 아무도 모릅니다.
원인: 점검창이 분기 2회뿐이라 석 달치 변경이 한 창에 적체·집중된 것이 구조적 원인입니다. 각 변경요청서의 영향도 분석은 자기 변경 하나만 봤고, 같은 창에서 함께 적용될 변경들의 상호작용은 어느 문서에도 없었습니다. 실제 원인은 방화벽 정책 정비로 WAS와 외부 API 사이의 keepalive 관련 설정이 바뀐 상태에서, 패치된 WAS의 커넥션 재사용 동작이 달라져 간헐 타임아웃을 만든 것 — 두 변경의 조합이었습니다.
진단: 단일 원인 추적이 불가능해 순차 롤백으로 갈 수밖에 없었는데, 여기서 두 번째 문제가 드러났습니다 — 롤백 순서가 얽혀 있었습니다. 방화벽을 먼저 되돌리면 WAS 패치 상태를 검증할 수 없고, WAS를 먼저 되돌리면 배치 스케줄 변경이 참조하는 모듈이 사라집니다. 세 팀이 롤백 순서를 협의하는 데만 한 시간, 전체 원복과 검증에 네 시간이 걸렸습니다. 각 변경은 통제됐지만, 창(window)은 아무도 통제하지 않았던 것입니다.
해결: 사후 검토에서 개선은 개별 변경이 아니라 점검창 운영에 집중됐습니다. (1) 점검창을 분기 2회에서 격주로 늘려 적체를 줄이고, 창 하나당 변경 수 상한(3건)을 정했습니다. (2) 창 배정 시 같은 창의 변경 목록을 놓고 상호작용·롤백 순서를 검토하는 '창 단위 리뷰'를 신설했습니다 — 창 전체의 적용 순서와 역순 롤백 계획이 한 장으로 정리됩니다. (3) 리스크 낮음 등급 변경은 발주사와 합의해 주간 적용을 허용하고 표준 변경으로 등록해, 애초에 창으로 몰리는 물량 자체를 줄였습니다. 다음 분기부터 창당 평균 변경 수가 절반으로 줄었고, "월요일 아침 장애"라는 말이 회의에서 사라졌습니다.
발주사·원청의 IT 운영 담당, 서비스데스크·운영(SM) 관리, 프로젝트 관리(PM/PMO) 자리에서 변경 관리는 매일 마주치는 통제 지점입니다. 실제 작업은 협력사(하도급) 엔지니어가 하더라도, "이 변경이 무엇에 영향을 주고, 누가 승인했고, 언제 어떤 점검창에 적용하며, 실패하면 어떻게 되돌리는가" 를 설계하고 통제하는 책임은 관리자에게 있습니다.
현장에서 관리자는 협력사가 올린 변경 요청서를 보고 "이 변경의 영향 범위가 정말 이게 다인가(CMDB 의존 관계와 맞는가)", "리스크 등급에 비해 승인 경로와 롤백 계획이 충분한가", "점검창과 사전 공지가 잡혀 있는가"를 검토합니다. 기술을 아는 관리자는 "캐시 설정만 바꾸는 거라 영향 없다"는 말에 속지 않고, "그 캐시에 주문 서비스가 매여 있지 않냐"고 되물을 수 있습니다.
특히 금요일 오후·연휴 직전·이벤트 기간 같은 변경 동결(change freeze) 구간을 정하고, 변경 일정이 서로 충돌하지 않게 조율하는 것도 관리자의 일입니다. 통제 없는 변경이 인시던트의 최대 원인이라는 사실은, 곧 변경 관리가 운영 안정성에 가장 직접적으로 기여하는 관리 활동이라는 뜻입니다.
실전 랩으로 손에 익히기: 변경 승인 실습 — 표준/일반/긴급 분류와 CAB·롤백 계획을 직접 설계합니다.
관련 모듈로 더 깊이:
- 변경요청서와 영향도 분석 — 변경을 실제로 흘려보내는 변경요청서(RFC)와 영향도 분석
- CAB와 변경 승인 — 변경을 누가 어떤 경로로 심의·승인하는지(CAB·ECAB)
- 구성 관리와 CMDB — 변경 영향 범위 판단의 근거가 되는 구성 관계 정보
다음 모듈에서는 이 변경을 실제로 흘려보내는 문서인 변경요청서(RFC)와 영향도 분석을 구체적으로 다룹니다 — 어떤 항목을 채우고, CMDB의 의존 관계로 영향 범위를 어떻게 산정하며, 승인·점검창·롤백 계획을 변경요청서에 어떻게 명시하는지 실무 양식으로 정리합니다.