금요일 오후, 협력사 엔지니어가 메신저로 한 줄 보냅니다. "결제 모듈 설정 좀 바꿔서 방금 반영했어요. 별거 아니라 따로 보고는 안 했습니다."
토요일 오전, 고객센터에 전화가 폭주합니다. 결제는 되는데 주문 완료 알림 문자가 안 갑니다. 고객은 결제가 안 된 줄 알고 또 결제합니다. 중복 결제 환불 처리, 사과 공지, 야간 긴급 복구.
원인은 단순했습니다. 결제 모듈이 알림 서비스를 호출하는 방식을 바꿨는데, 그 변경이 알림 서비스에 영향을 준다는 걸 아무도 따져 보지 않았습니다. "결제만 바꿨다"고 생각했지만, 결제는 주문 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 현장에서 영향도 분석의 근거는 대개 구축 프로젝트가 끝날 때 납품된 인터페이스 정의서·연계 목록이고, 그 문서는 검수일 기준의 스냅샷입니다. 시스템은 그날부터 계속 변했는데 지도는 그날에 멈춰 있습니다.
- 미등록 연동은 조용히 쌓입니다: 운영 2~3년 차가 되면 "옆 부서 개발자가 담당자에게 구두로 물어보고 API를 직접 호출"한 연동이 반드시 생깁니다. 정식 연동 신청은 절차가 무겁고 시간이 걸리니, 급한 쪽은 아는 사람에게 엔드포인트만 받아 갑니다. 그 담당자가 이동·퇴사하면 그 연동을 아는 사람은 조직에 0명이 됩니다.
- 그래서 '영향 없음'은 두 가지 뜻입니다: "영향이 없다"와 "영향을 모른다". 문서 기준으로 성실하게 분석해도, 문서 밖의 의존성에는 원천적으로 닿을 수 없습니다. 이 상태에서 RFC의 영향도 칸은 점점 이전 RFC의 복사본이 되어 갑니다 — 어차피 같은 문서를 보고 쓰니까.
- 드리프트가 진행 중이라는 신호: ① 변경 유발 장애의 사후 분석에 "몰랐던 연동이 있었다"가 반복해서 등장한다 ② RFC 영향도 문구가 건별로 거의 동일하다(복붙) ③ CMDB·연계 목록의 최종 갱신일이 구축 검수일 근처에 멈춰 있다.
- 처방은 문서가 아니라 트래픽: (1) 실측으로 지도를 다시 그립니다 — API 게이트웨이·웹서버 액세스 로그에서 호출원을 집계하면, 문서에 없는 의존성이 IP와 호출량이라는 사실로 드러납니다. 분기마다 실측 대 문서를 대조하는 것만으로 미등록 연동이 잡힙니다. (2) 장애를 갱신 트리거로 씁니다 — 변경 후 장애에서 미등록 의존이 발견되면, 복구와 함께 CMDB 반영을 종결 조건에 포함시킵니다. 같은 지뢰는 두 번 밟지 않게 됩니다. (3) 연동을 양성화합니다 — 발주사 명의로 "미등록 연동은 변경 공지·SLA 보호 대상이 아니다"를 공지하면, 숨은 연동이 스스로 신고할 유인이 생깁니다. 벌이 아니라 보호를 조건으로 걸어야 나옵니다.
영향도 분석의 품질 상한선은 분석자의 성실함이 아니라 의존성 데이터의 신선도입니다. 지도가 낡았다면, 항해술이 아니라 지도를 고쳐야 합니다.
상황: 수행사가 내부 조회 API의 응답 형식을 개선하는 변경을 진행했습니다. 교과서적으로 했습니다 — RFC 작성, 인터페이스 정의서 기준 연계 시스템 3곳 확인, 3곳 담당자 사전 공지와 호환성 확인, 야간 점검창 적용. 다음 날 오전, 전혀 다른 본부의 실적 집계 시스템이 데이터를 못 받아 일일 실적 보고가 멈췄고, 해당 본부장이 "우리 시스템 죽여 놓고 공지도 없었냐"며 발주사 IT 부서에 항의했습니다. 수행사는 그 시스템의 존재 자체를 몰랐습니다.
원인: 2년 전, 실적 집계 시스템을 만들던 타 부서 개발자가 정식 연동 신청 대신 당시 운영 담당자에게 구두로 물어 API 엔드포인트를 받아 직접 호출하도록 구현했습니다. 그 사실은 어떤 문서에도 남지 않았고, 허락해 준 담당자는 이듬해 다른 프로젝트로 이동했습니다. 인터페이스 정의서는 3년 전 구축 검수일 이후 한 번도 갱신되지 않았으므로, 수행사의 영향도 분석은 성실했지만 낡은 지도 위에서 성실했던 것입니다.
진단: 재발 우려가 제기되자 수행사는 문서 대신 트래픽을 봤습니다. API 게이트웨이 액세스 로그 한 달치에서 호출원 IP를 집계하니, 인터페이스 정의서에 있는 3곳 외에 미등록 호출원이 3곳 더 나왔습니다 — 멈췄던 실적 집계 시스템, 어느 팀의 사내 대시보드, 출처를 아무도 모르는 배치 서버 하나. 문서상 연동의 절반이 지도 밖에 있었던 셈입니다.
해결: (1) 실측으로 발견된 6개 호출원을 전부 CMDB·연계 목록에 등록하고, 분기마다 액세스 로그 집계와 문서를 대조하는 '의존성 실측' 절차를 운영 업무에 넣었습니다. (2) 발주사 명의로 전사 공지를 냈습니다 — "미등록 연동은 향후 변경 공지·장애 SLA 보호 대상에서 제외되며, 이번 달 내 신고 시 소급 등록" — 공지 후 2주간 미등록 연동 4건이 추가로 자진 신고됐습니다. (3) RFC 영향도 칸에 '조회 근거(연계 목록 버전·실측 기준일)'를 명시하도록 양식을 바꿔, "무엇을 보고 영향 없다고 판단했는가"가 문서에 남게 했습니다. 이 사건이 남긴 교훈은 절차 준수가 아니라 데이터 신선도였습니다 — 영향도 분석은 문서 검토가 아니라, 문서를 의심하는 일까지 포함합니다.
한국 SI/SM 현장에서 변경 관리는 단순히 "기술 작업을 한다"가 아니라 "고객사 운영 환경을 바꾸는 일을 통제한다" 입니다. 실제 작업은 협력사(하도급) 엔지니어가 하더라도, 변경의 책임은 관리자(운영 담당·PM)에게 있습니다.
그래서 변경에는 보통 이런 흐름이 따라붙습니다. (1) 요청 — 작업 필요가 생기면 RFC를 작성해 등록합니다. (2) 검토 — 운영·보안·해당 서비스 담당이 영향도와 리스크를 본다. (3) 승인 — 내부 운영 책임자뿐 아니라, 운영 중인 시스템이면 고객사 운영 담당의 승인이 필요합니다. 고객 시스템을 우리 마음대로 바꿀 수 없기 때문입니다. (4) 일정 협의 — 영향이 가는 변경은 점검창(maintenance window), 즉 사용자가 적은 합의된 시간대(예: 토요일 새벽)에 잡고, 그 전에 작업 공지로 영향을 받을 사용자·고객에게 미리 알립니다.
확대
그림: 운영 시스템 변경은 요청→검토→승인→일정 협의의 통제된 합의를 거치며, 작업은 협력사가 해도 영향·승인·점검창·롤백을 설계·통제하는 책임은 관리자에게 남는다.
여기서 관리자가 자주 부딪히는 현실은, 협력사가 "별거 아니니 그냥 하겠다"고 할 때입니다. 기술을 아는 관리자는 그때 "영향도부터 봅시다 — CMDB상 이 모듈이 무엇과 연결돼 있죠?" 라고 되물을 수 있습니다. 영향도·점검창·고객 승인·작업 공지는 협력사를 불신해서가 아니라, 변경의 영향을 예고된 범위 안에 가두기 위한 공통 절차입니다. 이 절차를 설계하고 통제하는 것이 SI/SM 관리 직무의 핵심 중 하나입니다.
실전 랩으로 손에 익히기: 변경요청·영향도 분석 실습 — RFC 필수 항목·CMDB 연계 영향분석·승인 연결을 설계합니다.
관련 모듈로 더 깊이:
- CAB와 변경 승인 — 작성된 변경요청서를 심의·승인하는 CAB와 승인 경로
- 변경 관리(변경 활성화) — 변경을 표준·일반·긴급으로 나눠 통제하는 전체 흐름
- 변경계획서·롤백계획서·작업절차서 — RFC에 첨부되는 변경·롤백 문서의 실무 작성법
다음 모듈에서는 이렇게 작성된 변경요청서를 실제로 누가 어떻게 심의하고 승인하는지 — 변경자문위원회(CAB)와 변경 승인의 구조, 표준·일반·긴급 변경별 승인 경로, 그리고 CAB이 빠지기 쉬운 형식주의의 함정까지를 다룹니다.