금요일 오후, 협력사 엔지니어가 메신저로 한 줄 보냅니다. "결제 모듈 설정 좀 바꿔서 방금 반영했어요. 별거 아니라 따로 보고는 안 했습니다."
토요일 오전, 고객센터에 전화가 폭주합니다. 결제는 되는데 주문 완료 알림 문자가 안 갑니다. 고객은 결제가 안 된 줄 알고 또 결제합니다. 중복 결제 환불 처리, 사과 공지, 야간 긴급 복구.
원인은 단순했습니다. 결제 모듈이 알림 서비스를 호출하는 방식을 바꿨는데, 그 변경이 알림 서비스에 영향을 준다는 걸 아무도 따져 보지 않았습니다. "결제만 바꿨다"고 생각했지만, 결제는 주문 DB·알림 서비스와 연결돼 있었습니다.
이 사고를 막는 두 장의 종이가 있습니다. 변경요청서(RFC) — "무엇을·왜·언제 바꾸고, 실패하면 어떻게 되돌리는가". 그리고 영향도 분석 — "이걸 건드리면 또 무엇이 흔들리는가". 이 모듈은 그 두 장을 어떻게 쓰는지, 그리고 한국 현장에서 점검창·작업 공지·고객 승인이 어떻게 따라붙는지를 다룹니다.
- 1변경요청서(RFC)에 담아야 할 핵심 항목(변경내용·사유·대상·일정·영향·리스크·롤백·승인자)을 빠짐없이 작성할 수 있다
- 2영향도 분석에서 영향 받는 서비스·사용자·연계 시스템을 CMDB의 관계 정보를 활용해 도출할 수 있다
- 3변경의 사유를 "산출물"이 아니라 "결과(기대 효과)" 기준으로 적어 승인자가 이득과 리스크를 저울질하게 할 수 있다
- 4요청→검토→승인→일정협의로 이어지는 변경 승인 절차와 각 단계의 역할을 설명할 수 있다
- 5한국 SI/SM 현장의 고객 승인·점검창(maintenance window)·작업 공지가 왜 필요한지와 어떻게 엮이는지 설명할 수 있다
변경요청서(RFC)는 무엇을 담는가
RFC는 '바꾸기 전에 합의해 두는 계약서'다
변경(Change)은 서비스에 영향을 줄 수 있는 의도적인 추가·수정·제거입니다. 통제 없는 변경은 인시던트의 가장 흔한 원인입니다. 그래서 변경은 말로 흘러가서는 안 되고, 변경요청서(RFC, Request for Change) 라는 한 장의 문서로 남깁니다.
RFC의 목적은 두 가지입니다. 첫째, 변경을 하기 전에 무엇을·왜·언제·무엇에 영향이 가는지를 글로 정리해 검토·승인받는 것. 둘째, 나중에 "누가 무엇을 왜 바꿨는가"를 추적할 수 있게 기록을 남기는 것. 앞 시나리오의 사고는 RFC가 없었기 때문에 검토도, 추적도 불가능했습니다.
RFC가 빠짐없이 담아야 할 항목을 정리하면:
| RFC 항목 | 무엇을 적는가 | 흔한 실수 |
|---|---|---|
| 변경 내용(What) | 구체적으로 무엇을 바꾸는가 | "설정 변경" 같은 모호한 한 줄 |
| 변경 사유(Why) | 왜 바꾸는가 — 기대 효과를 결과 기준으로 | "패치 적용"처럼 산출물만 적음 |
| 변경 대상(Where) | 어떤 서비스·서버·구성 항목(CI)을 건드리나 | 직접 대상만 적고 연계 누락 |
| 일정(When) | 작업 시점·소요 시간·점검창 | 업무 시간 중 작업으로 잡음 |
| 영향도(Impact) | 어떤 서비스·사용자·연계 시스템에 영향 | "영향 없음"으로 단정 |
| 리스크(Risk) | 실패 시 무슨 일이 일어나나·발생 확률 | 리스크 칸을 비워 둠 |
| 롤백 계획(Rollback) | 실패하면 어떻게·얼마 만에 되돌리나 | "문제 생기면 되돌림" 한 줄 |
| 승인자(Approver) | 누가 검토·승인하는가 | 승인 없이 작업자가 자체 판단 |
사유는 결과로 적습니다. "보안 패치를 적용한다"는 산출물입니다. "이 취약점을 방치하면 고객 데이터가 노출될 수 있어, 패치로 그 위험을 제거한다"가 결과입니다. 승인자는 결과로 적힌 사유를 보고 "이 변경의 이득이 리스크보다 큰가" 를 판단합니다.
영향도 분석 — '이걸 건드리면 또 뭐가 흔들리나'
RFC의 가장 어려운 칸은 영향도(Impact) 입니다. 작업자는 보통 자기가 직접 만지는 대상만 봅니다 — "나는 결제 모듈만 바꿨다". 하지만 서비스는 혼자 서 있지 않습니다. 다른 서비스·시스템과 연결돼 있고, 변경의 영향은 그 연결을 타고 번집니다.
영향도 분석은 세 방향으로 따집니다.
- 영향 서비스: 이 변경이 직접 닿는 서비스와, 그 서비스에 의존하는 다른 서비스. (결제 모듈 → 주문 서비스 → 알림 서비스)
- 영향 사용자: 누가, 몇 명이 영향을 받나. 전사인가 일부인가, 외부 고객인가 내부 직원인가. 이것이 변경의 우선순위·점검창 시점을 정합니다.
- 연계 시스템: 외부 결제사(PG)·문자 발송사·정산 배치처럼 우리 통제 밖이지만 엮여 있는 시스템.
이때 결정적으로 쓰이는 것이 CMDB의 관계 정보입니다. CMDB는 구성 항목(CI)들이 무엇과 무엇에 연결돼 있는지를 담고 있습니다. "결제 API"라는 CI에서 관계를 타고 내려가면 "주문 DB", "알림 서비스", "외부 PG"가 줄줄이 딸려 나옵니다. 영향도 분석은 결국 CMDB의 관계 그래프를 따라가며 "여기를 건드리면 어디까지 흔들리나"를 그리는 작업입니다. CMDB가 없거나 갱신이 안 돼 있으면, 영향도 분석은 작업자의 기억과 추측에 의존하게 되고 — 앞 시나리오 같은 사고가 납니다.
그림: RFC는 무엇을·왜·언제를 담고, 영향도 분석은 CMDB 관계로 "이걸 건드리면 또 뭐가 흔들리나"를 본다.
직접 해보기 — RFC 한 장 작성하기
다음 변경 상황을 보고, 아래 두 표를 직접 채워 보세요. 정답 예시는 ObserveBlock에 있습니다.
[변경 상황]
결제 서비스의 보안 취약점(구버전 라이브러리)이 발견됐다.
라이브러리를 v2로 올리는 패치를 적용해야 한다.
결제 API는 주문 DB와 알림 서비스, 외부 결제사(PG)와 연결돼 있다.
적용 후 재기동이 필요하며, 재기동 동안 결제가 약 5분간 중단된다.
먼저 변경요청서(RFC) 표의 빈칸을 채웁니다.
| 항목 | 내용 |
|----------|------|
| 변경 내용 | ? |
| 변경 사유 | ? (결과 기준으로) |
| 변경 대상 | ? |
| 일정 | ? (점검창 포함) |
| 영향도 | ? |
| 리스크 | ? |
| 롤백 계획 | ? |
| 승인자 | ? |
다음으로 영향도 분석 표를 CMDB 관계(결제 API → 주문 DB·알림 서비스·외부 PG)를 따라 채웁니다.
| 영향 구분 | 대상 | 영향 내용 |
|-------------|------|----------|
| 영향 서비스 | ? | ? |
| 영향 사용자 | ? | ? |
| 연계 시스템 | ? | ? |
작성: 변경요청서(RFC) + 영향도 분석- 변경 내용: 결제 서비스의 보안 라이브러리를 구버전에서 v2로 업그레이드하고 서비스 재기동
- 변경 사유(결과 기준): 구버전 라이브러리의 취약점을 방치하면 결제 데이터가 노출될 위험이 있어, 패치로 그 위험을 제거하고 결제 서비스의 보안 수준을 회복한다
- 변경 대상: 결제 API(직접) — CMDB상 주문 DB·알림 서비스·외부 PG와 연결된 CI
- 일정: 토요일 새벽 2시~2시30분 점검창 / 실제 작업 5분 + 검증 시간 / 사전 작업 공지
- 영향도: 재기동 동안 약 5분간 결제 중단 → 그 시간 주문·알림 흐름도 함께 멈춤
- 리스크: v2 호환성 문제로 결제 실패가 지속될 수 있음(중간 확률) / 재기동 실패로 서비스가 안 올라올 수 있음(낮은 확률)
- 롤백 계획: 재기동 후 5분 내 결제 성공률이 평소 수준으로 안 오르면(롤백 트리거) 구버전으로 즉시 되돌림 — 백업해 둔 이전 패키지로 재배포, 약 10분 소요
- 승인자: 운영 책임자(내부) + 보안 담당(취약점 패치이므로) + 고객사 운영 담당(점검창·중단 영향 승인)
- 영향 서비스 = 결제·주문·알림(연쇄) / 영향 사용자 = 점검창 시간대의 결제 시도 고객 / 연계 시스템 = 외부 PG(재기동 중 거래 처리 영향 가능 → 사전 협의)
- 핵심 감각: "결제만 바꾼다"가 아니라 CMDB 관계를 타고 "주문·알림·PG까지 본다"가 영향도 분석이다
현장에서 자주 보는 함정
증상: RFC 없이, 영향도 분석 없이, "금방 되고 별거 아니다"라며 운영 중인 시스템을 바꿉니다. 대개는 무사히 넘어가지만, 어느 날 앞 시나리오처럼 연계 서비스가 조용히 망가지고, 그 사실은 한참 뒤에 사용자 신고로 드러납니다.
원인: 두 가지가 겹쳤습니다. (1) 영향도를 직접 대상만 보고 끝냈다 — 결제만 봤지, 결제와 연결된 알림 서비스는 보지 않았습니다. CMDB 관계를 따라갔다면 보였을 영향입니다. (2) 변경 통제 자체를 건너뛰었다 — RFC도, 승인도, 점검창도, 작업 공지도 없었습니다. 그래서 영향은 '예고된 점검'이 아니라 '예상치 못한 장애(인시던트)'가 됐습니다.
해결 방향:
- '작다'는 작업자의 느낌이지 영향도가 아닙니다. 변경의 크기는 영향 범위 × 리스크로 판단하고, 작아 보여도 영향도 한 줄은 따집니다.
- 영향도는 기억이 아니라 CMDB 관계로 따집니다. CMDB가 비어 있거나 낡았다면, 그 자체가 변경 리스크입니다.
- 운영 시스템 변경은 점검창에, 공지를 동반해 합의된 시간에 합니다. 업무 시간 중 무단 변경으로 인한 중단은 곧 인시던트로 집계됩니다.
- 실패에 대비한 롤백 트리거와 절차를 RFC에 미리 적어, 점검창 안에서 판단을 헤매지 않게 합니다.
한국 SI/SM 현장에서 변경 관리는 단순히 "기술 작업을 한다"가 아니라 "고객사 운영 환경을 바꾸는 일을 통제한다" 입니다. 실제 작업은 협력사(하도급) 엔지니어가 하더라도, 변경의 책임은 관리자(운영 담당·PM)에게 있습니다.
그래서 변경에는 보통 이런 흐름이 따라붙습니다. (1) 요청 — 작업 필요가 생기면 RFC를 작성해 등록합니다. (2) 검토 — 운영·보안·해당 서비스 담당이 영향도와 리스크를 본다. (3) 승인 — 내부 운영 책임자뿐 아니라, 운영 중인 시스템이면 고객사 운영 담당의 승인이 필요합니다. 고객 시스템을 우리 마음대로 바꿀 수 없기 때문입니다. (4) 일정 협의 — 영향이 가는 변경은 점검창(maintenance window), 즉 사용자가 적은 합의된 시간대(예: 토요일 새벽)에 잡고, 그 전에 작업 공지로 영향을 받을 사용자·고객에게 미리 알립니다.
그림: 운영 시스템 변경은 요청→검토→승인→일정 협의의 통제된 합의를 거치며, 작업은 협력사가 해도 영향·승인·점검창·롤백을 설계·통제하는 책임은 관리자에게 남는다.
여기서 관리자가 자주 부딪히는 현실은, 협력사가 "별거 아니니 그냥 하겠다"고 할 때입니다. 기술을 아는 관리자는 그때 "영향도부터 봅시다 — CMDB상 이 모듈이 무엇과 연결돼 있죠?" 라고 되물을 수 있습니다. 영향도·점검창·고객 승인·작업 공지는 협력사를 불신해서가 아니라, 변경의 영향을 예고된 범위 안에 가두기 위한 공통 절차입니다. 이 절차를 설계하고 통제하는 것이 SI/SM 관리 직무의 핵심 중 하나입니다.
관련 모듈로 더 깊이:
- CAB와 변경 승인 — 작성된 변경요청서를 심의·승인하는 CAB와 승인 경로
- 변경 관리(변경 활성화) — 변경을 표준·일반·긴급으로 나눠 통제하는 전체 흐름
- 변경계획서·롤백계획서·작업절차서 — RFC에 첨부되는 변경·롤백 문서의 실무 작성법
다음 모듈에서는 이렇게 작성된 변경요청서를 실제로 누가 어떻게 심의하고 승인하는지 — 변경자문위원회(CAB)와 변경 승인의 구조, 표준·일반·긴급 변경별 승인 경로, 그리고 CAB이 빠지기 쉬운 형식주의의 함정까지를 다룹니다.