금요일 오후, 발주사 운영 담당이 연락해 옵니다. "운영계에서 일부 PDF가 깨져 나옵니다. 표가 어긋나고 한글이 □로 뜬대요. 개발팀이 렌더링 라이브러리 패치를 만들었다는데, 이거 다음 주에 반영 좀 봐주세요."
협력사 개발자는 이미 패치 파일을 들고 "테스트계에선 잘 됩니다. 운영에 그냥 올리면 돼요"라고 합니다. 한쪽에서는 "빨리 좀 해달라"는 압박이 옵니다.
여기서 패치 파일을 그냥 운영계에 복사해 올리는 사람은 엔지니어입니다. PM인 당신이 하는 일은 다릅니다. 이 한 줄짜리 패치를 변경요청서로 만들고, 영향도를 분석하고, 작업절차서와 롤백계획서를 쓰고, 고객과 점검창을 협의하고, 반영 후 체크리스트로 검증하고, 결과를 보고하는 하나의 작은 프로젝트로 굴립니다.
이 모듈은 앞에서 따로 배운 WBS·변경관리·롤백·변경계획서를 한 시나리오 안에서 끝까지 적용해, "관리한다는 것"의 전체 흐름을 손에 익히는 캡스톤입니다.
- 1운영계 패치 한 건을 요구사항 확인부터 결과 보고까지 9단계 프로젝트 흐름으로 설계할 수 있다
- 2변경요청서에 영향도 분석을 포함해 승인·일정·롤백 판단의 근거를 만들 수 있다
- 3작업절차서와 롤백계획서를 작성하고, 객관적인 롤백 판단 기준을 사전에 정의할 수 있다
- 4고객과 점검창·작업공지를 협의하고, 중단 한계선을 합의에 포함할 수 있다
- 5점검 체크리스트로 반영 결과를 검증하고, 산출물이 아닌 결과 중심으로 보고할 수 있다
패치 한 건이 왜 '프로젝트'가 되는가
운영계 변경은 작아도 절차가 있다
테스트계에서 잘 도는 패치가 운영계에서 사고를 내는 이유는 단순합니다. 운영계에는 실제 사용자와 실제 데이터, 그리고 그 모듈에 얽힌 다른 서비스가 있기 때문입니다.
PDF 렌더링 모듈은 보기엔 '문서 출력' 하나지만, 실제로는 여러 서비스가 같은 모듈을 공유하는 경우가 많습니다.
- 주문/결제 영수증 출력
- 계약서·견적서 출력
- 월말 정산 리포트 일괄 생성(배치)
패치가 한글 깨짐은 고쳤는데 표 정렬 로직을 건드려 영수증 레이아웃이 틀어진다면, 고친 것보다 큰 사고가 됩니다. 그래서 운영계 변경은 크기와 무관하게 "무엇이 위험한가 → 어떻게 통제하는가 → 안 되면 어떻게 되돌리는가" 라는 절차를 거칩니다. 이 절차의 묶음이 곧 작은 프로젝트입니다.
PM의 9단계 흐름 — 앞 모듈의 종합
요구사항부터 결과 보고까지, 한 줄로 꿰기
이 캡스톤은 새 개념을 배우는 자리가 아니라, 따로 배운 산출물들을 시간 순서대로 꿰는 자리입니다. 각 단계가 어느 모듈의 적용인지 함께 봅니다.
- 요구사항 확인 — "무엇을, 왜, 언제까지 고치나"를 고객과 합의. 막연한 "PDF 고쳐주세요"를 "한글 깨짐·표 어긋남을, 다음 주 안에, 다른 출력에 영향 없이"로 구체화. (요구사항/범위 모듈의 적용)
- WBS 작성 — 그 일을 더 작은 작업 단위로 쪼개 누가·언제 할지 배치. (WBS·일정 모듈의 적용)
- 변경요청서·영향도 분석 — 이 변경이 건드리는 서비스·사용자·연계 시스템과 위험을 문서로. (변경관리·변경요청 모듈의 적용)
- 작업절차서 — 운영 반영을 단계별 명령/행동으로 적어, 누가 해도 같게. (변경계획서 모듈의 적용)
- 롤백계획서 — 실패 시 되돌리는 절차와 판단 기준을 사전에. (롤백 모듈의 적용)
- 고객 일정 협의·작업공지 — 점검창 시간·중단 한계선 합의, 사용자 공지 발송.
- 운영 반영 — 절차서대로 실행.
- 점검 체크리스트 — 핵심 기능·연계·로그를 확인해 결과를 검증.
- 결과 보고 — 산출물이 아니라 결과("정상 출력 확인")로 보고.
핵심은 1번에서 9번까지가 끊기지 않고 이어진다는 점입니다. 영향도 분석(3)이 점검창 길이(6)와 롤백 기준(5)을 정하고, 롤백 기준(5)이 점검 체크리스트(8)의 합격선을 정합니다. 한 산출물이 다음 산출물의 근거가 됩니다.
확대
그림: 패치 한 건도 아홉 단계의 프로젝트이며, 영향도 분석이 롤백 기준을, 롤백 기준이 점검 합격선을 정하는 근거 사슬로 이어진다.
단계별 판단 기준
확대
운영 패치에서 가장 흔한 사고는 "반영됐다"를 "정상이다"로 착각하는 것입니다. 배포는 산출물일 뿐이고, 정상 출력 검증이 결과입니다. 그래서 PM은 작업 전에 두 기준을 못 박습니다 — 언제 되돌릴 것인가(롤백 트리거)와 언제 끝났다고 할 것인가(완료 기준). 반영 직후 핵심 거래 실패율이 오르면 미련 없이 사전 기준대로 롤백하고, 트리거가 안 걸려도 점검 체크리스트가 끝나기 전에는 완료 보고를 보류합니다. 롤백 판단을 그 순간 즉흥으로 하지 않는 것이 PM의 일입니다.
직접 해보기 — 산출물 4종 작성
아래 산출물 예시를 자신의 표현으로 다시 채워 보세요. 네 산출물이 서로 어떻게 근거를 주고받는지(영향도 → 점검창 → 롤백 기준 → 체크리스트)를 의식하며 작성하는 것이 핵심입니다.
(가) WBS — 작업 분해 구조
| WBS 코드 | 작업 패키지 | 산출물 | 담당 | 일정 |
|---|---|---|---|---|
| 1.1 | 요구사항·범위 확정 | 범위 합의서 | PM | D-5 |
| 1.2 | 영향도 분석·변경요청서 작성 | 변경요청서 | PM, 개발 | D-4 |
| 1.3 | 작업절차서·롤백계획서 작성 | 절차서, 롤백계획서 | PM, 개발 | D-3 |
| 1.4 | 변경 승인(CAB) | 승인 기록 | 승인자 | D-2 |
| 1.5 | 고객 점검창 협의·사용자 공지 | 공지문 | PM | D-2 |
| 1.6 | 운영 반영 | 반영 로그 | 개발(협력사) | D-Day |
| 1.7 | 점검 체크리스트 검증 | 점검 결과 | PM, QA | D-Day |
| 1.8 | 결과 보고 | 결과 보고서 | PM | D+1 |
(나) 변경요청서(요약)
변경요청서 (CR-2026-0142)
- 변경명 : PDF 렌더링 라이브러리 패치 적용(한글 깨짐·표 정렬 수정)
- 요청 배경 : 운영계 일부 PDF 한글이 □로 출력, 표 정렬 어긋남
- 변경 범위 : 렌더링 모듈 v2.3 → v2.3.1 교체 (설정 변경 없음)
- 영향도 분석:
· 직접 영향 : 문서 출력 화면 (사용자 다운로드)
· 연계 영향 : 결제 영수증, 계약서 출력, 월말 정산 배치 (동일 모듈 사용)
· 미영향 : 로그인, 결제 처리, 재고
- 위험도 : 중(연계 서비스 다수) / 가역성: 가능(이전 버전 보관)
- 점검창 : 06-25(목) 02:00~04:00 (사용자 최소 시간)
- 승인 : 운영팀장, 고객 IT담당
(다) 롤백 판단 기준 — 무엇이 보이면 되돌리는가
| 판단 항목 | 정상 기준 | 롤백 트리거 |
|---|---|---|
| PDF 출력 성공률 | 평소 수준 유지 | 출력 실패가 연속 관찰됨 |
| 핵심 거래(영수증) | 정상 출력 | 영수증 레이아웃 깨짐 발견 |
| 정산 배치 | 정상 생성 | 배치 오류 로그 발생 |
| 점검창 시간 | 04:00 이전 검증 완료 | 03:30까지 검증 미완료 |
(라) 점검 체크리스트 — 반영 후 결과 검증
[ ] 한글 PDF 1건 다운로드 → 글자 정상(□ 없음) 확인
[ ] 표 포함 문서 → 정렬 정상 확인
[ ] 결제 영수증 출력 → 레이아웃 정상 확인
[ ] 계약서 출력 → 정상 확인
[ ] 정산 배치 수동 1회 → 오류 로그 없음 확인
[ ] 애플리케이션 로그 → 렌더링 예외 없음 확인
[ ] 이전 버전 보관 위치·롤백 명령 재확인
작성: WBS / 변경요청서 / 롤백 판단 기준 / 점검 체크리스트- WBS의 1.2(영향도 분석)에서 나온 "연계 서비스: 영수증·계약서·정산"이 변경요청서 영향도와 점검 체크리스트 항목으로 그대로 흘러 들어갔는지 — 한 산출물이 다음 산출물의 근거가 되는 연결을 확인
- 롤백 판단 기준의 각 트리거가 점검 체크리스트의 검증 항목과 짝이 맞는지(영수증 깨짐 트리거 ↔ 영수증 출력 점검) — 검증과 롤백이 같은 항목을 본다
- 점검창(02:00~04:00) 안에 "03:30까지 검증 미완료면 롤백"이라는 시간 한계선이 들어가 있는지 — 시간 트리거가 빠지면 작업이 무한정 길어진다
- 변경요청서에 "미영향" 항목이 명시돼 있는지 — 무엇이 안 바뀌는지를 적는 것도 영향도 분석의 일부
- 점검 체크리스트 마지막에 "롤백 명령 재확인"이 들어가 있는지 — 반영 직전까지 되돌릴 준비가 살아 있어야 한다
현장에서 자주 보는 함정
증상: 패치를 새벽 점검창에 반영했더니 본래 깨졌던 한글 PDF는 정상이 됐는데, 아무도 확인하지 않던 결제 영수증 레이아웃이 틀어졌습니다. 현장에서는 "이거 롤백해야 하나, 영수증만 따로 고치면 되나"를 두고 의견이 갈려 30분을 보냈고, 그 사이 업무 시작 시간이 가까워졌습니다.
원인: 두 가지가 빠졌습니다. 첫째, 영향도 분석에서 연계 서비스(영수증)를 누락해 점검 체크리스트에도 영수증 항목이 없었습니다. 둘째, 롤백 판단 기준이 사전에 합의되지 않아 현장에서 즉흥적으로 판단하느라 시간을 허비했습니다. 둘 다 평상시에 정했어야 할 것을 장애 순간에 정하려 한 것이 문제입니다.
해결 방향(이 모듈의 산출물로 예방):
- 영향도 분석에서 같은 모듈을 쓰는 모든 서비스를 끌어내 점검 체크리스트 항목으로 만든다 — 그러면 영수증 깨짐을 사용자보다 먼저 발견한다.
- 롤백 트리거를 객관적 문장으로 미리 적는다("영수증 레이아웃 깨짐 발견 시 즉시 롤백") — 현장에서 토론할 필요가 없다.
- 점검창에 시간 한계선(03:30 미완료 시 롤백)을 넣어, 업무 시작 시간을 넘기는 사고를 구조적으로 막는다.
함정의 본질은 기술 실수가 아니라, 판단을 미뤘다가 장애 순간에 몰아서 하려 한 관리 실수입니다. PM의 산출물은 그 판단을 평상시로 앞당기는 도구입니다.
심화 — 되돌릴 수 없는 변경 앞에서
심화: 가역성 평가와 긴급 변경 — 시나리오가 비틀리는 두 지점
이 캡스톤의 패치는 조건이 좋았습니다 — 이전 버전이 보관돼 있어 되돌릴 수 있고(가역), 새벽 점검창을 잡을 수 있었습니다. 실전에서는 이 두 전제가 자주 무너집니다.
- 롤백이 성립하지 않는 변경: DB 스키마 변경·데이터 마이그레이션을 동반한 패치는 "이전 버전 파일로 교체"만으로 돌아가지 않습니다 — 이미 새 구조로 변환된 데이터가 구버전과 호환되지 않기 때문입니다. 이런 변경의 롤백계획서는 파일 교체 절차가 아니라 작업 직전 백업(스냅샷)으로의 복원 절차와 그 소요 시간이어야 하고, 복원 시간이 점검창을 넘으면 점검창 자체를 다시 협의해야 합니다. 더 성숙한 방식은 되돌리는 대신 앞으로 고치는 롤포워드(roll-forward)를 기본 전략으로 삼되, 그 판단을 현장이 아니라 계획 단계에서 내리는 것입니다. 핵심 질문은 변경요청서 단계에서 던져집니다 — "이 변경은 데이터를 바꾸는가?" 이 한 줄이 빠진 가역성 평가는 평가가 아닙니다.
- 점검창이 없는 긴급 변경: 심각한 보안 취약점이 공표되면 다음 정기 승인까지 기다릴 수 없습니다. 이때 절차를 생략하는 게 아니라 압축합니다 — 사전에 정의된 긴급 변경 절차(약식 영향 분석, 지정 승인자의 유선 승인, 사후 CAB 보고)를 따르고, 문서는 작업 후 하루 이틀 안에 소급 완성합니다. "급해서 절차 없이 했다"와 "긴급 절차로 했다"는 사고가 났을 때 하늘과 땅 차이입니다. 그리고 긴급 변경 비율이 계속 높다면, 그것 자체가 계획 능력의 경고 지표입니다.
- 롤백 리허설: 롤백계획서는 문서가 아니라 능력입니다. 스테이징에서 실제로 한 번 되돌려 본 계획과 머리로만 쓴 계획은 새벽 3시에 완전히 다르게 작동합니다. 고위험 변경은 리허설 완료를 승인 조건에 넣는 것이 안전합니다.
시나리오가 비틀려도 원칙은 같습니다 — 판단을 장애 순간이 아니라 평상시로 앞당긴다. 다만 그 판단 목록에 "되돌릴 수 있는가, 되돌리는 데 얼마나 걸리는가, 기다릴 수 있는가"가 추가될 뿐입니다.
상황: 문서 모듈 패치를 새벽 점검창에 반영했습니다. 이번 패치에는 저장 구조 개선이 포함돼, 반영 직후 문서 메타데이터가 새 형식으로 변환됐습니다. 검증 중 핵심 기능 오류가 발견돼 사전에 합의한 롤백 트리거가 발동했고, 계획서대로 이전 버전 파일로 교체해 재기동했습니다 — 그런데 구버전이 새 형식의 데이터를 읽지 못해 기동 자체가 실패했습니다. 서비스는 패치 오류 상태보다 더 나쁜 전면 중단이 됐습니다.
원인: 변경요청서의 가역성 평가가 "이전 버전 보관됨 → 가역"으로 파일 기준으로만 이뤄졌고, 이 패치가 데이터를 바꾼다는 사실이 평가에 반영되지 않았습니다. 롤백계획서도 파일 교체 절차만 담았을 뿐, 변환된 데이터를 되돌리는 절차(백업 복원)와 그 소요 시간이 없었습니다. 스테이징에서 롤백을 실제로 해 본 적도 없어, 이 구멍이 새벽 현장에서 처음 드러났습니다.
진단: 구버전 기동 로그의 데이터 형식 오류를 보고 마이그레이션의 비가역성을 확인했습니다. 이어서 작업 직전 자동 백업이 남아 있는지, 백업 시점 이후 유입된 데이터가 있는지(점검창이라 없음), 복원 소요 시간이 점검창 잔여 시간 안인지를 차례로 확인한 뒤 백업 복원으로 방향을 바꿨습니다.
해결: 백업 복원으로 패치 전 상태를 회복해 업무 시작 전에 정상화했습니다. 재발 방지로 변경요청서의 가역성 항목을 "이전 버전 보관 여부" 한 칸에서 "데이터 변경 동반 여부 + 되돌리는 방법 + 복원 소요 시간" 세 칸으로 바꿨고, 데이터를 바꾸는 변경은 스테이징 롤백 리허설을 승인 조건으로 못 박았습니다. 점검창 협의에도 복원 시간을 반영해, "롤백에 40분이 걸리면 롤백 판단 마감도 40분 당겨진다"는 계산이 계획서에 들어가게 했습니다.
국내 SI·운영(SM) 현장에서 PM은 패치를 직접 운영계에 올리는 사람이 아니라, 그 반영이 안전하게 이뤄지도록 절차와 산출물을 통제하는 사람입니다. 실제 작업은 협력사(하도급) 개발자가 하더라도, 변경요청서·작업절차서·롤백계획서를 검토·승인하고, 발주사와 점검창을 협의하고, 반영 후 결과를 보고할 책임은 관리자에게 있습니다.
특히 공공·금융 운영 환경에서는 변경 한 건마다 변경요청서·CAB 승인·작업공지·결과보고서가 감리와 감사의 증빙이 됩니다. "패치를 빨리 올렸다"가 아니라 "어떤 위험을 분석해, 누구의 승인을 받아, 언제 무슨 절차로 반영하고, 어떻게 검증했으며, 결과가 어땠는가"가 문서로 남아야 합니다. 이 캡스톤에서 만든 네 산출물(WBS·변경요청서·롤백계획서·점검 체크리스트)은 그대로 운영 PM이 매주 만지는 실무 양식입니다.
기술을 아는 PM은 협력사가 "그냥 올리면 된다"고 할 때 영향 범위를 되물을 수 있고, 잘못된 "완료" 보고에 속지 않습니다. 그것이 이 트랙이 길러온 관리자의 눈입니다.
관련 모듈로 더 깊이:
- 변경 관리(변경 활성화) — 변경을 사고 없이 통제하는 변경 관리 절차의 기본
- 변경요청서와 영향도 분석 — 변경요청서와 영향도 분석을 쓰는 법
- 작업계획서·롤백계획서·점검계획 — 점검창에서 되돌릴 수 있도록 롤백 계획을 준비하는 법
다음 모듈에서는 이렇게 반영·운영되는 서비스의 품질을 약속하고 측정하는 언어 — 합의된 목표 대비 실제 운영 수준을 다루는 SLA 관리 시뮬레이션을 진행합니다.