금요일 오후, 두 회사의 같은 장면.
P사: 결제팀 리더가 슬랙에 "결제 모듈 v2 오늘 밤에 올립니다"라고 한 줄 남기고 배포합니다. 그날 밤, 마케팅팀이 같은 시간에 잡아둔 대형 쿠폰 이벤트가 시작됩니다. 두 변경이 같은 결제 서비스 위에서 충돌하고, 토요일 새벽 결제가 멈춥니다. 사후에 모두가 묻습니다. "이거 누가 승인한 거예요?" 아무도 대답하지 못합니다.
Q사: 같은 배포가 화요일 정기 변경회의에 안건으로 올라옵니다. 운영 대표는 "그 주말은 쿠폰 이벤트라 결제 변경 동결 기간"이라고 짚고, 보안 대표는 "롤백 스크립트 검증했냐"고 묻습니다. 회의는 배포를 이벤트 다음 주로 미루도록 권고하고, 변경관리자가 그대로 승인합니다. 그 주말, 아무 일도 일어나지 않습니다.
차이는 기술이 아니라 **"변경을 누가, 무엇을 보고, 언제 승인하는가"**라는 통제 구조입니다. 이 구조의 한가운데 있는 것이 CAB(변경자문위원회)이고, 그 옆에 변경 캘린더와 변경 동결이 있습니다. 이 모듈은 그 승인 체계를 다룹니다.
- 1CAB(변경자문위원회)가 변경을 "실행"하는 조직이 아니라 "검토·권고"하는 자문 기구임을 설명하고, 운영·개발·보안·고객 대표가 각각 무엇을 보는지 말할 수 있다
- 2정기 변경회의의 흐름(안건 접수 → 검토 → 권고 → 승인/보류/반려 → 기록)을 그릴 수 있다
- 3표준변경이 왜 CAB를 우회(사전승인)하는지, 일반변경·긴급변경과 어떻게 다른지 구분할 수 있다
- 4ECAB(긴급변경위원회)이 언제, 어떻게 작동하는지와 일반 CAB와의 차이를 설명할 수 있다
- 5변경 캘린더로 일정 충돌을 막고, 변경 동결(이벤트·연말 등)로 고위험 기간의 변경을 통제하는 이유를 설명할 수 있다
CAB — 변경을 '실행'하는 곳이 아니라 '검토'하는 곳
CAB는 자문 기구다 — 책임은 변경관리자에게 있다
변경을 처음 배우는 사람이 가장 많이 오해하는 지점이 이것입니다. CAB(Change Advisory Board, 변경자문위원회)는 변경을 직접 작업하는 조직이 아니고, 변경을 혼자 결정하는 조직도 아닙니다. CAB는 변경 요청을 여러 관점에서 함께 검토하고 "진행해도 좋다 / 보류하라 / 반려한다"를 **권고(advise)**하는 자문 기구입니다. 이름 그대로 'Advisory'입니다.
왜 권고일까요? 변경에는 늘 책임 주체가 있어야 하는데, 위원회는 여럿이라 책임이 흩어지기 쉽습니다. 그래서 최종 승인 권한과 책임은 변경관리자(또는 변경권한자, change authority) 한 사람(또는 명확한 직책)에게 둡니다. CAB는 그 사람이 좋은 결정을 내리도록 다양한 시각을 모아 주는 역할입니다.
CAB가 보는 것은 변경의 '내용이 멋진가'가 아니라 다음 세 가지입니다.
| CAB가 따지는 것 | 구체 질문 |
|---|---|
| 리스크(Risk) | 실패하면 어떤 서비스가, 누가, 얼마나 영향받는가? |
| 준비도(Readiness) | 테스트·롤백·점검창·공지·담당자가 준비됐는가? |
| 충돌(Conflict) | 같은 시점·같은 서비스에 다른 변경이나 동결 기간이 겹치지 않는가? |
즉 CAB는 "이 변경이 좋은 변경인가"보다 **"이 변경이 충분히 검토되고 준비되었는가"**를 봅니다. 멋진 변경도 롤백 계획이 없으면 보류됩니다.
누가 앉는가 — 운영·개발·보안·고객 대표
CAB의 힘은 서로 다른 관점이 한 테이블에 모이는 것에서 나옵니다. 개발자 혼자 보면 "코드는 완벽하다"로 끝나지만, 운영은 점검창을, 보안은 권한 변화를, 고객 대표는 영업시간 영향을 봅니다. 한 사람이 다 못 보는 사각지대를 구성으로 메우는 것이 CAB 설계의 핵심입니다.
| 구성원 | 무엇을 대변하나 | 회의에서 던지는 전형적 질문 |
|---|---|---|
| 변경관리자(의장) | 절차·최종 결정 | "이 변경은 일반변경인가 표준변경인가? 승인 권한은 누구인가?" |
| 운영 대표(SM) | 가용성·점검창·운영 부담 | "점검창은 언제이며 누가 당직인가? 롤백은 몇 분이면 되나?" |
| 개발 대표 | 기술 내용·테스트 | "스테이징에서 검증했나? 의존 서비스에 영향은?" |
| 보안 대표 | 보안·컴플라이언스 | "권한·네트워크 노출이 바뀌나? 보안 검토를 받았나?" |
| 고객/현업 대표 | 업무 영향·일정 | "영업시간에 멈추나? 현업 공지는 나갔나? 마감과 안 겹치나?" |
구성원은 회사마다 다릅니다. 작은 조직은 한 사람이 여러 관점을 겸하고, 협력사(SI/SM) 구조에서는 발주사 담당과 협력사 엔지니어가 함께 들어옵니다. 중요한 것은 머릿수가 아니라 **"리스크를 볼 관점이 빠지지 않았는가"**입니다.
확대
정기 변경회의 — 변경이 흘러가는 길
안건 접수 → 검토 → 권고 → 결정 → 기록
대부분의 조직은 CAB를 정기 회의로 운영합니다. 한국 기업에서는 보통 주 1회(예: 매주 화요일 오전) 모여 한 주 동안 들어온 변경 요청(RFC, Request for Change)을 한꺼번에 검토합니다. 정기로 두는 이유는, 변경을 그때그때 즉흥적으로 승인하면 충돌과 누락이 생기기 때문입니다.
정기 변경회의의 표준 흐름은 이렇습니다.
| 단계 | 하는 일 | 산출 |
|---|---|---|
| 1. 안건 접수 | 마감(예: 회의 전날 정오)까지 RFC 등록 | 안건 목록 |
| 2. 사전 검토 | 변경관리자가 분류(일반/표준/긴급)·완성도 확인 | 검토용 정리본 |
| 3. 회의 검토 | 리스크·준비도·충돌을 각 관점에서 질의 | 검토 의견 |
| 4. 권고 | 진행 / 조건부 진행 / 보류 / 반려를 권고 | 권고안 |
| 5. 결정 | 변경관리자가 최종 승인·서명 | 승인 기록 |
| 6. 일정 반영 | 변경 캘린더에 시점·점검창 등록 | 갱신된 캘린더 |
여기서 자주 놓치는 두 가지가 있습니다. 첫째, 마감 시각이 중요합니다. 회의 직전에 던져진 변경은 충분히 검토할 수 없으므로 다음 회의로 미루는 것이 원칙입니다(긴급변경 경로는 따로 있습니다). 둘째, 결과는 반드시 기록합니다. "왜 보류했는지", "어떤 조건으로 승인했는지"가 남아야 다음에 같은 판단을 재현하고, 사후에 책임을 추적할 수 있습니다.
확대
그림: CAB는 변경을 "실행"하지 않고 "검토·권고"한다 — 최종 결정과 책임은 변경관리자에게 있다.
표준변경 — CAB를 우회하는 사전승인
반복되고 안전한 변경은 미리 승인해 둔다
모든 변경을 매주 CAB에 올리면 회의는 마비됩니다. "신규 입사자 계정 생성", "합의된 패턴의 SSL 인증서 갱신", "검증된 절차대로의 디스크 증설" 같은 변경은 매번 똑같고, 리스크가 낮으며, 절차가 반복적으로 검증되어 있습니다. 이런 변경을 매주 표결하는 것은 낭비입니다.
그래서 ITSM은 변경을 세 갈래로 나눕니다.
| 변경 유형 | 정의 | 승인 경로 |
|---|---|---|
| 표준변경(Standard) | 리스크 낮고 절차가 반복 검증된, 미리 승인된 변경 | CAB 우회 — 사전승인된 절차대로 바로 처리 |
| 일반변경(Normal) | 평가가 필요한 보통의 변경 | 정기 CAB 검토 → 변경관리자 승인 |
| 긴급변경(Emergency) | 미루면 더 위험한, 즉시 처리할 변경 | ECAB 신속 검토 → 긴급 승인 |
표준변경의 핵심은 **"개별 변경을 승인하는 게 아니라 변경 유형(절차)을 한 번 승인해 두는 것"**입니다. 한 번 표준변경으로 등록되면 그 절차대로 발생하는 한 매번 CAB를 거치지 않습니다. 이렇게 비워낸 검토 역량을 진짜 위험한 일반변경에 집중시킵니다.
다만 두 가지 함정이 있습니다.
- 사전승인 ≠ 기록 면제. 표준변경도 "언제, 누가, 무엇을 했다"는 처리 기록은 반드시 남깁니다. 승인 절차를 줄이는 것이지 추적을 없애는 것이 아닙니다.
- 표준변경은 '졸업'으로 얻는다. 처음부터 표준변경은 없습니다. 일반변경으로 여러 번 안전하게 수행되어 절차가 안정되었음이 증명된 뒤에야 "이건 이제 표준으로 빼자"고 CAB가 등록합니다. 검증되지 않은 변경을 편하다고 표준으로 분류하면, 통제 없는 변경에 합법적인 우회로를 깔아주는 셈입니다.
ECAB — 긴급변경을 위한 빠른 길
정기 회의를 기다릴 수 없을 때
장애가 진행 중이거나, 지금 막아야 하는 보안 취약점이 공개되었을 때 "다음 주 화요일 정기 CAB까지 기다리세요"는 답이 될 수 없습니다. 미루는 것이 곧 더 큰 피해이기 때문입니다. 이때를 위한 경로가 **ECAB(Emergency Change Advisory Board, 긴급변경위원회)**입니다.
ECAB은 별도의 다른 조직이 아니라, 긴급 상황에서 신속히 소집되는 축소된 CAB라고 보는 것이 정확합니다. 정기 CAB와의 차이는 이렇습니다.
| 항목 | 정기 CAB | ECAB |
|---|---|---|
| 소집 시점 | 정해진 주기(예: 주 1회) | 긴급 상황 발생 시 즉시 |
| 참여 인원 | 전체 관점 대표 | 결정에 꼭 필요한 핵심 소수 |
| 검토 깊이 | 충분히, 여유 있게 | 핵심 리스크 위주로 신속히 |
| 승인 속도 | 회의 주기에 맞춰 | 수십 분~수 시간 내 |
| 기록 시점 | 회의 중·후 정식 기록 | 우선 처리, 사후 정식 기록 보강 |
ECAB의 원칙은 **"속도는 높이되 통제는 버리지 않는다"**입니다. 빠르게 결정하더라도 누가 승인했는지, 무엇을 바꿨는지, 롤백 계획은 무엇인지는 남깁니다. 다만 정식 문서화는 불을 끈 다음 보강할 수 있습니다. 긴급을 핑계로 기록 자체를 생략하면, 사후에 원인 추적이 막히고 같은 긴급이 반복됩니다.
주의할 함정: "긴급"의 남용입니다. 단지 일정을 못 맞춰서, 미리 신청하기 귀찮아서 긴급변경 경로를 타면 정기 검토를 무력화합니다. 긴급의 기준("미루는 것이 더 위험한가")을 명확히 두고, 사후에 "이게 정말 긴급이었나"를 점검하는 것이 건강한 운영입니다.
확대
변경 캘린더와 변경 동결 — 시간 축의 통제
변경 캘린더 — 충돌을 시간 축에서 본다
개별 변경이 아무리 잘 준비돼도, 두 변경이 같은 시간·같은 서비스에서 만나면 장애가 됩니다. **변경 캘린더(change calendar, 변경 일정표)**는 예정된 모든 변경을 시간 축에 펼쳐 이런 충돌을 미리 발견하는 도구입니다. 흔히 변경 일정(forward schedule of changes)이라고도 부릅니다.
캘린더로 잡아내는 전형적 충돌은 이렇습니다.
- 같은 결제 서비스에 두 팀이 같은 야간 점검창을 잡음 → 한쪽을 미룸
- 대형 마케팅 이벤트와 배포가 같은 주말에 겹침 → 배포를 이벤트 뒤로
- 동결 기간(아래)에 변경이 잡혀 있음 → 동결 해제 후로 이동
- 같은 DB에 의존하는 변경이 연달아 잡혀 롤백 시 서로 얽힘 → 간격 확보
핵심은 캘린더가 단순한 '일정 게시판'이 아니라 충돌 점검 도구라는 점입니다. 새 변경을 등록할 때마다 "이 시점에 다른 변경·동결과 겹치지 않는가"를 보는 것이 사용법입니다.
변경 동결 — 고위험 기간엔 문턱을 극단으로 높인다
특정 기간에는 변경 자체가 큰 위험입니다. 쇼핑몰의 대형 세일 주간, 금융사의 연말정산·결산, 명절 트래픽 정점, 중요한 대외 행사 — 이런 시점에는 평소라면 무난했을 변경도 정점 부하·정점 거래와 만나 대형 장애로 번질 수 있습니다. 그래서 그 기간 동안 변경을 막는 것이 **변경 동결(change freeze)**입니다.
자주 하는 오해는 "동결 = 아무것도 못 함"입니다. 정확한 이해는 **"문턱을 극단적으로 높인다"**입니다.
- 일반변경: 사실상 전면 보류. 동결 전에 끝내거나 동결 후로 미룸.
- 표준변경: 조직 정책에 따라 일부만 허용하거나 함께 동결.
- 긴급변경(보안 패치, 진행 중 장애 대응 등 미루는 게 더 위험한 것): ECAB 등 예외 승인 경로로 엄격히 통제해 허용.
동결은 변경 캘린더 위에 '이 기간은 동결'이라고 명시해 두고, 그 안에 잡히는 변경을 자동으로 걸러냅니다. 동결의 시작·해제 시점과 예외 기준을 미리 공지하는 것이 핵심입니다. "언제부터 언제까지, 무엇이 막히고, 예외는 어떻게 신청하는가"가 분명해야 현업이 동결 전에 변경을 끝내도록 움직입니다.
확대
그림: 변경 캘린더는 게시판이 아니라 충돌 점검 도구다 — 같은 시간·서비스에 겹치는 변경을 미리 드러내 옮기고, 동결 구간 위에 잡히는 변경은 자동으로 걸러진다.
직접 해보기 — CAB 안건 검토와 변경 캘린더 작성
아래는 변경관리자가 정기 변경회의 전 각 안건을 거르는 CAB 안건 검토 체크리스트입니다. 다섯 항목 중 하나라도 비어 있으면 그 안건은 '조건부' 또는 '보류'로 갑니다.
[ CAB 안건 검토 체크리스트 ]
1. 분류 : 일반 / 표준 / 긴급 중 무엇인가? (표준이면 우회, 긴급이면 ECAB)
2. 리스크 : 실패 시 영향 서비스·범위·고객 수는? (상/중/하)
3. 준비도 : 스테이징 테스트 완료? 롤백 계획·소요시간? 담당·당직 지정?
4. 일정 충돌 : 같은 서비스·같은 창에 겹치는 변경 없는가? 동결 기간 아닌가?
5. 공지 : 현업/고객 공지가 점검창 전에 나가는가?
이제 다음 5건을 위 체크리스트로 판정해 보세요. 정답은 ObserveBlock에 있습니다.
A. "신규 입사자 4명 계정 생성." (인사팀, 표준변경으로 등록된 절차 있음)
B. "결제 모듈 v2 배포. 스테이징 검증 완료, 롤백 스크립트 있음." (단, 그 주말은 대형 세일 동결 기간)
C. "방금 공개된 심각도 높은 보안 취약점 긴급 패치. 미루면 노출 지속." (지금)
D. "주문 DB 인덱스 추가. 테스트는 했으나 롤백 계획·소요시간 미기재." (다음 주 화요일 희망)
E. "사내 위키 서버 메모리 증설. 영향 사내 한정, 점검창·롤백·공지 모두 준비." (평일 야간)
판정: 진행 / 조건부 / 보류 / 표준(우회) / 긴급(ECAB)- A = 표준변경(CAB 우회). 이미 표준으로 등록된 절차이므로 정기회의 표결 없이 절차대로 처리하되, 처리 기록은 남긴다
- B = 보류(일정 조정). 변경 자체는 잘 준비됐으나 동결 기간과 충돌 → 세일 종료 후로 이동하도록 권고
- C = 긴급변경(ECAB). 미루는 것이 더 위험하므로 ECAB 신속 검토·승인, 처리 후 정식 기록 보강
- D = 조건부/보류. 리스크는 중간이나 롤백 계획·소요시간이 비어 준비도 미달 → 보완 후 다음 회의 재상정
- E = 진행. 영향 한정·점검창·롤백·공지 모두 충족 → 일반변경으로 승인, 변경 캘린더에 야간 점검창 등록
- 핵심 감각: 같은 "배포해도 되나요"라도 분류·준비도·일정 충돌·동결 여부에 따라 가는 길이 다르다 — CAB는 내용이 아니라 검토·준비·충돌을 본다
위 판정 결과를 시간 축에 펼쳐 **변경 캘린더(변경 일정표)**로 만듭니다. 다음 주 일정에 세일 동결(토~일)이 걸려 있다고 가정합니다. 아래 표를 채워 충돌을 한눈에 드러내 보세요.
[ 다음 주 변경 캘린더 (예시 양식) ]
일자 | 서비스 | 변경(RFC) | 점검창 | 상태/비고
-----------|---------|-----------------|------------|------------------
월 야간 | 사내위키 | E. 메모리 증설 | 22:00~23:00 | 승인 — 영향 사내 한정
화 오전 | (정기 변경회의 — 안건 A·D 검토) | |
화 야간 | 주문DB | D. 인덱스 추가 | 미정 | 보류 — 롤백계획 보완 후
수~금 | (특이사항 없음) | |
토~일 | === 대형 세일 변경 동결 (결제·주문) === | | 동결 — 신규변경 차단
(차주) | 결제 | B. 모듈 v2 배포 | 동결 해제 후 | 이동 — 세일 종료 후 재상정
캘린더: 일자 × 서비스 × 변경 × 점검창 × 상태- 월 야간 E는 동결 전·영향 한정이라 그대로 진행 — 캘린더에 점검창이 명시되어 당직·공지 기준이 생긴다
- 화 야간 D는 준비도 미달로 보류 표시 — 캘린더에 "왜 안 잡혔는지"가 남아야 다음 회의에서 재현 가능
- 토~일 동결 구간을 캘린더에 굵게 박아두면, B 배포가 그 위에 잡히려 할 때 자동으로 걸러진다
- B는 동결과 충돌하므로 "차주 동결 해제 후"로 이동 — 캘린더가 일정 충돌을 시각적으로 강제한다
- 핵심 감각: 캘린더는 게시판이 아니라 충돌 점검 도구다. 새 변경을 등록하기 전 "이 칸이 비어 있는가, 동결과 안 겹치는가"를 먼저 본다
현장에서 자주 보는 함정
증상: 정기 변경회의는 매주 열리는데 형식적입니다. 안건이 회의 직전에 한꺼번에 올라오고, 다들 "문제 없으면 통과"로 빠르게 승인 도장만 찍습니다. 그런데 실제 장애는 회의 안건에 없던 변경 — "급해서 슬랙으로 합의하고 그냥 올린" 변경 — 에서 터집니다.
원인: 두 가지가 동시에 무너진 상태입니다. (1) CAB가 리스크·준비도·충돌을 실제로 따지지 않고 통과 의식으로 변질됐고, (2) CAB를 우회하는 비공식 경로(슬랙 합의, 구두 승인)가 사실상의 메인 경로가 됐습니다. 통제가 종이 위에만 있고 현장은 따로 도는 것입니다.
해결 방향(이 트랙에서 깊어짐):
- 마감 시각을 강제한다. 회의 전날 정오 이후 들어온 일반변경은 다음 회의로 — 충분히 검토 못 한 변경을 통과시키지 않는다.
- 검토 체크리스트를 안건마다 채우게 한다(분류·리스크·준비도·충돌·공지). 빈칸이 있으면 통과 불가 → 회의가 의식이 아니라 검문이 된다.
- 비공식 경로를 닫는다. 진짜 급한 변경은 슬랙이 아니라 ECAB 경로로 — 긴급에도 승인·기록이 따라붙게 한다.
- **사후 점검(PIR)**으로 "긴급이라더니 정말 긴급이었나", "CAB 안 거친 변경이 몇 건인가"를 센다. 우회 경로가 보이면 그쪽을 정식 경로로 흡수한다.
CAB의 목적은 변경을 막는 것이 아니라, 변경이 안전하게 흐르는 길을 하나로 모으는 것입니다. 길이 여러 갈래면 통제는 무너집니다.
심화 — 도장이 다섯 개면 책임은 5분의 1이 된다
심화: 승인의 책임 분산 효과 — CAB 건강도는 반려율로 잰다
한국 기업의 결재 문화에서 CAB는 미묘한 방식으로 변질됩니다. 결재선이 길수록 안심하는 문화에서, 승인은 검토 장치가 아니라 책임을 나눠 갖는(정확히는 흐리는) 장치로 소비되기 시작합니다.
- 승인이 면책으로 작동합니다: 작업자는 "CAB 통과한 건입니다"라는 말로 준비 책임을 회의체에 넘기고, CAB 참석자는 "저는 제 영역만 봤습니다"로 발을 빼고, 변경관리자는 "회의에서 이견이 없었습니다"로 물러섭니다. 승인자가 다섯이면 사고 때 책임은 5분의 1씩 — 즉 사실상 아무에게도 없습니다. 모두가 이 구조를 어렴풋이 알기 때문에, 역설적으로 아무도 깊이 검토하지 않을 유인이 생깁니다.
- 발주사-수행사 구조는 이 효과를 증폭합니다: 발주사 현업 대표는 "기술은 모르니" 배석만 하고, 수행사는 "발주사가 참석한 자리에서 승인됐다"는 사실 자체를 방어막으로 쌓아 둡니다. 양쪽 모두에게 CAB는 검토의 장이 아니라 알리바이의 장이 됩니다.
- 건강도는 느낌이 아니라 숫자로 드러납니다: ① 반려·조건부 비율 — 몇 분기째 반려가 0건이면 CAB는 이미 죽어 있는 것입니다(모든 변경이 완벽했을 리 없습니다). ② 안건당 검토 시간 — 30건을 40분에 처리한다면 건당 80초, 그것은 검토가 아니라 낭독입니다. ③ 회의록의 질문 수 — '이견 없음. 원안 승인'만 반복되는 회의록은 아무도 묻지 않았다는 기록입니다.
- 처방은 책임의 재배치: (1) '승인은 준비도 책임을 이전하지 않는다'를 명문화합니다 — 테스트·롤백·영향분석의 진실성은 끝까지 RFC 작성자 책임이고, CAB는 관점 검토와 충돌 확인을 책임진다고 역할을 갈라 적습니다. (2) 저위험 안건은 **일괄 동의 안건(consent agenda)**으로 묶어 5분에 처리하고, 확보한 시간을 고위험 안건에 배분합니다 — 고위험 건은 사전 리뷰어를 지정하고 안건당 최소 검토 시간을 둡니다. (3) 반려율·질문 수를 분기 운영보고에 CAB 건강 지표로 올립니다 — 재는 순간부터 회의가 달라집니다.
CAB의 실패는 대개 시끄럽지 않습니다. 회의는 매주 열리고, 회의록은 쌓이고, 도장은 찍힙니다. 조용히 만장일치가 계속되는 것 — 그것이 가장 큰 경고 신호입니다.
상황: 분기 마감 주간, DB 파라미터 변경이 적용된 다음 날 아침 발주사 핵심 업무 시스템이 3시간 멈췄습니다. 발주사 감사실이 조사에 착수해 승인 경로를 추적합니다. 작업자: "정식으로 RFC 올렸고 CAB 승인받았습니다." CAB 참석자들: "RFC 영향도 칸에 '영향 없음'이라 적혀 있었고, 그 이상은 저희가 알 수 없었습니다." 변경관리자: "회의에서 아무도 이견을 내지 않아 원안대로 승인했습니다." 다섯 명 모두 절차를 지켰는데, 아무도 검토하지 않은 상태였습니다.
원인: 그 주 CAB 안건은 26건, 회의 시간은 45분 — 건당 검토 시간이 2분이 안 됐습니다. 분기 마감 전 변경이 몰리는 시기마다 반복되던 패턴입니다. 해당 RFC의 영향도 칸에는 근거 없이 '영향 없음'이 적혀 있었지만, 그것을 검증할 시간도, 검증이 누구 책임인지에 대한 합의도 없었습니다. 참석자 각자는 '다른 사람이 봤겠지'라고 생각했고, 그 침묵이 회의록에 '이견 없음'으로 기록됐습니다. 승인 도장이 다섯 개였기에, 오히려 아무도 자기 일로 여기지 않은 것입니다.
진단: 감사팀이 최근 1년치 회의록과 승인 통계를 뽑자 구조가 드러났습니다 — 연간 처리 안건 890건 중 반려 0건, 조건부 승인 3건. 회의록에 기록된 질문은 분기당 평균 2개. 장애를 일으킨 그 RFC와 동일하게 '영향 없음'이라 적힌 안건이 전체의 60%가 넘었는데, 그중 CMDB 의존 관계 확인 흔적이 있는 것은 거의 없었습니다. CAB는 1년 내내 열렸지만, 통계적으로는 한 번도 작동한 적이 없었습니다.
해결: 감사 지적에 따라 CAB 운영이 재설계됐습니다. (1) RFC 양식에 '영향 없음' 선택지를 없애고, 영향 범위 칸에 CMDB 조회 결과 첨부를 필수화했습니다 — 근거 없는 '영향 없음'이 원천 차단됩니다. (2) 안건을 리스크 등급으로 나눠 저위험은 일괄 동의로 5분에 묶어 처리하고, 고위험 안건은 사전 리뷰어 2인 지정 + 안건당 10분 이상 검토로 바꿨습니다. (3) 회의록에 안건별 질문·답변 요지를 기록하게 하고, 반려·조건부 비율을 분기 운영보고 지표에 올렸습니다. (4) '승인은 RFC 기재 내용의 진실성 책임을 이전하지 않는다'는 문구가 변경관리 규정에 들어갔습니다. 다음 분기 반려·조건부 비율은 11%였습니다 — CAB가 처음으로 무언가를 걸러내기 시작한 것입니다.
한국 기업의 IT 운영 현장에서 변경 승인은 대개 주간 변경회의와 **승인 라인(결재선)**이라는 두 축으로 돌아갑니다. 매주 정해진 요일에 변경회의가 열리고, 각 변경은 담당자 → 팀장 → (필요 시) 보안·운영 검토 → 변경관리자/임원으로 이어지는 결재선을 탑니다. CAB는 이 회의체와 결재선이 합쳐진 형태로 존재하는 경우가 많습니다.
발주사·원청의 운영 담당, 서비스 운영(SM) 담당, PM/PMO 자리에 서면 당신은 직접 배포 버튼을 누르기보다 **"이 변경이 어느 경로(표준/일반/긴급)로 가야 하는가, 승인 라인의 누가 무엇을 봐야 하는가, 협력사가 올린 RFC가 충분히 준비됐는가, 동결 기간과 충돌하지 않는가"**를 판정하고 통제합니다. 협력사(하도급) 엔지니어가 실제 작업을 해도, 변경으로 인한 서비스 품질·일정·장애 책임은 관리자에게 있습니다.
그래서 실무에서 통하는 사람은 변경회의에서 "검증했어요?"가 아니라 **"스테이징 결과, 롤백 소요시간, 점검창, 충돌 여부, 동결 일정"**을 구체적으로 묻습니다. CAB 안건 검토 체크리스트와 변경 캘린더는 그 질문을 빠뜨리지 않게 해주는, 관리자의 가장 기본적인 도구입니다.
관련 모듈로 더 깊이:
- 릴리스와 배포 관리 — 승인된 변경을 운영에 안전하게 내보내는 릴리스·배포
- 변경요청서와 영향도 분석 — CAB가 심의하는 변경요청서(RFC)와 영향도 분석
- 변경 관리(변경 활성화) — 표준·일반·긴급 변경별 승인 경로를 정하는 변경관리
다음 모듈에서는 승인된 변경을 실제로 운영 환경에 안전하게 내보내는 단계 — 릴리스·배포 관리(release and deployment management)를 다룹니다.