금요일 오후, 발주사 운영 담당이 연락해 옵니다. "운영계에서 일부 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의 산출물은 그 판단을 평상시로 앞당기는 도구입니다.
국내 SI·운영(SM) 현장에서 PM은 패치를 직접 운영계에 올리는 사람이 아니라, 그 반영이 안전하게 이뤄지도록 절차와 산출물을 통제하는 사람입니다. 실제 작업은 협력사(하도급) 개발자가 하더라도, 변경요청서·작업절차서·롤백계획서를 검토·승인하고, 발주사와 점검창을 협의하고, 반영 후 결과를 보고할 책임은 관리자에게 있습니다.
특히 공공·금융 운영 환경에서는 변경 한 건마다 변경요청서·CAB 승인·작업공지·결과보고서가 감리와 감사의 증빙이 됩니다. "패치를 빨리 올렸다"가 아니라 "어떤 위험을 분석해, 누구의 승인을 받아, 언제 무슨 절차로 반영하고, 어떻게 검증했으며, 결과가 어땠는가"가 문서로 남아야 합니다. 이 캡스톤에서 만든 네 산출물(WBS·변경요청서·롤백계획서·점검 체크리스트)은 그대로 운영 PM이 매주 만지는 실무 양식입니다.
기술을 아는 PM은 협력사가 "그냥 올리면 된다"고 할 때 영향 범위를 되물을 수 있고, 잘못된 "완료" 보고에 속지 않습니다. 그것이 이 트랙이 길러온 관리자의 눈입니다.
관련 모듈로 더 깊이:
- 변경 관리(변경 활성화) — 변경을 사고 없이 통제하는 변경 관리 절차의 기본
- 변경요청서와 영향도 분석 — 변경요청서와 영향도 분석을 쓰는 법
- 작업계획서·롤백계획서·점검계획 — 점검창에서 되돌릴 수 있도록 롤백 계획을 준비하는 법
다음 모듈에서는 이렇게 반영·운영되는 서비스의 품질을 약속하고 측정하는 언어 — 합의된 목표 대비 실제 운영 수준을 다루는 SLA 관리 시뮬레이션을 진행합니다.