같은 결제 모듈 v2 배포, 두 운영팀.
A팀은 새벽 2시에 모여 "일단 배포하고 보자"로 시작합니다. 배포 도중 마이그레이션이 절반에서 멈췄고, 누가 무엇을 먼저 했는지 메모가 없어 되돌리지도 못합니다. 4시가 넘어도 결제가 죽어 있고, 고객 공지도 안 나가 콜센터가 폭주합니다. 아침 보고는 "원인 파악 중"입니다.
B팀은 같은 작업을 합니다. 다만 사흘 전에 변경계획서로 승인을 받았고(무엇을·왜·언제·영향), 당일에는 작업절차서의 단계표를 그대로 따라 한 줄씩 체크하며 진행합니다. 2시 40분, 헬스체크가 빨간불을 띄우자 미리 써 둔 롤백계획서의 조건("3시까지 핵심 거래 정상화 실패 시 원복")에 따라 즉시 되돌립니다. 고객에게는 전날 점검 공지가 나갔고, 아침 보고서에는 "예정대로 점검·이상 감지·롤백·정상 운영 복귀, 원인 분석 후 재시도 예정"이 한 장으로 정리돼 있습니다.
두 팀의 차이는 손이 빠른 게 아니라 반영 전에 무엇을 종이에 적어 두었느냐입니다. 이 모듈은 운영계 반영을 통제하는 문서 3종 세트 — 변경계획서·작업절차서·롤백계획서 — 와 공지·점검 체크리스트를 실제 템플릿으로 작성하는 법을 다룹니다.
- 1변경계획서·작업절차서·롤백계획서 세 문서의 역할 분담과 서로의 관계를 설명할 수 있다
- 2변경계획서에 들어가는 변경내용·사유·일정·영향·승인 항목을 자기 손으로 채울 수 있다
- 3작업절차서를 단계·명령·담당·예상시간·확인사항이 있는 단계표로 작성할 수 있다
- 4롤백계획서에서 원복 조건·절차·데이터 복구·롤백 불가 대비를 구분해 설계할 수 있다
- 5한국 SI/SM의 야간 운영 반영 흐름(공지 → 점검 → 반영 → 점검 체크 → 결과보고)에 문서를 배치할 수 있다
왜 세 개의 문서인가 — 독자와 목적이 다르다
하나의 변경, 세 개의 시선
운영계(실서비스) 반영은 "잘되면 본전, 잘못되면 장애"인 작업입니다. 그래서 반영 전에 세 명의 다른 독자를 위해 세 문서를 씁니다. 같은 변경을 세 번 쓰는 게 아니라, 각자 다른 질문에 답하는 것입니다.
- 변경계획서는 승인권자·이해관계자가 읽습니다. 질문은 "이 변경을 해도 되는가?" 무엇을·왜·언제·무엇에 영향을·누가 승인했는가를 봅니다.
- 작업절차서는 *작업자(때로는 협력사 엔지니어)*가 읽습니다. 질문은 "나는 무엇을 어떤 순서로 하면 되는가?" 단계·명령·담당·예상시간·확인사항을 봅니다.
- 롤백계획서는 장애 직전의 작업자·관리자가 읽습니다. 질문은 "이게 잘못되면 어떻게 되돌리는가?" 원복 조건·절차·데이터 복구·되돌릴 수 없을 때의 대비를 봅니다.
| 문서 | 주 독자 | 답하는 질문 | 작성 시점 |
|---|---|---|---|
| 변경계획서 | 승인권자·이해관계자 | 해도 되는가 (무엇을·왜·언제·영향) | 반영 며칠 전, 승인용 |
| 작업절차서 | 작업자·협력사 | 어떻게 단계별로 하는가 | 반영 전, 리허설과 함께 |
| 롤백계획서 | 작업자·관리자 | 실패 시 어떻게 원복하는가 | 반영 전, 작업절차서와 한 쌍 |
| (작업 공지문) | 고객·사용자 | 언제·무엇이·얼마나 영향받는가 | 반영 전, 공지 채널로 |
| (점검 체크리스트) | 작업자·검증자 | 정상 동작·부작용 없음 확인 | 반영 직후 |
핵심 감각: 롤백계획서는 사후 문서가 아닙니다. 작업이 실패한 뒤 쓰는 게 아니라, 반영 전에 작업절차서와 한 쌍으로 미리 써 두는 '보험증서'입니다. 보험은 사고 나기 전에 드는 것입니다.
그림: 같은 변경을 승인권자·작업자·관리자 세 시선으로 나눠 쓰며, 작업절차서와 롤백계획서는 항상 한 쌍이다.
운영 반영 3종 세트 — 빈 양식 다운로드
변경계획서 — 무엇을·왜·언제·영향·승인
승인을 받기 위한 문서
변경계획서는 "이 변경을 운영계에 반영하겠다"는 신청서이자 통제 기록입니다. 핵심은 승인권자가 리스크를 판단할 수 있을 만큼의 정보를 담는 것입니다. 아래는 그대로 복사해 채울 수 있는 템플릿입니다.
[ 변경계획서 ]
1. 변경 개요
- 변경 ID : CHG-2026-0612-01
- 변경 제목 : 결제 모듈 v2 배포 (PG 연동 라이브러리 교체)
- 변경 유형 : 일반 변경(Normal) / 표준(Standard) / 긴급(Emergency) 중 택1
- 작성자/요청부서 : 홍길동 / 결제플랫폼팀
2. 변경 내용 (무엇을)
- 결제 API 서버 payment-svc 를 v1.8 → v2.0 으로 배포
- DB 스키마 변경: payment 테이블에 컬럼 2개 추가(마이그레이션 030)
- 설정 변경: PG사 엔드포인트 URL 교체
3. 변경 사유 (왜)
- 기존 PG 라이브러리 EOL(지원 종료)로 보안 패치 불가
- 해외 카드 결제 실패율 개선(현 4.1% → 목표 1% 이하)
4. 일정 (언제)
- 점검창(작업 시간) : 2026-06-15(일) 02:00 ~ 04:00 (KST)
- 결정 시한 : 03:00 까지 정상화 실패 시 롤백
- 사전 공지 발송 : 2026-06-13(금) 10:00
5. 영향 분석 (무엇에)
- 영향 서비스 : 결제 서비스(전 고객), 주문 서비스(결제 호출부)
- 영향 범위 : 점검 시간 동안 결제 불가(주문 접수는 가능, 결제만 대기)
- 다운타임 : 예상 10분(배포·마이그레이션), 최대 30분
- 연관 변경/의존성 : 없음 (인벤토리 서비스 무관)
6. 리스크 및 대응
- 리스크 : 마이그레이션 실패 시 결제 테이블 불일치
- 대응 : 롤백계획서(RB-2026-0612-01) 별첨, 사전 DB 백업 수행
7. 승인
- 작업 승인(CAB/변경관리자) : __________ (서명/일시)
- 서비스 책임자(운영) : __________ (서명/일시)
- 고객/발주사 통보 확인 : __________ (담당/일시)
8. 별첨
- 작업절차서 WP-2026-0612-01
- 롤백계획서 RB-2026-0612-01
여기서 자주 비는 칸이 결정 시한과 승인입니다. 결정 시한이 없으면 현장에서 "조금만 더"를 반복하다 점검창을 넘기고, 승인 칸이 비면 "누가 시켰나"가 사라져 사고 시 책임 추적이 안 됩니다.
작업절차서 — 한 줄씩 따라 하는 단계표
작업자가 그대로 실행하는 문서
작업절차서의 목적은 단 하나, 누가 해도 같은 순서로 같은 결과가 나오게 하는 것입니다. 그래서 줄글이 아니라 단계표로 씁니다. 각 단계에는 (1) 무엇을(작업), (2) 어떻게(명령/동작), (3) 누가(담당), (4) 얼마나(예상시간), (5) 어떻게 확인(확인사항)이 들어갑니다.
[ 작업절차서 WP-2026-0612-01 — 결제 모듈 v2 배포 ]
작업창: 2026-06-15 02:00 ~ 04:00 / 결정 시한 03:00
참여: 배포 담당(김), DBA(이), 검증(박), 총괄(홍)
| 단계 | 작업 | 명령/동작 | 담당 | 예상시간 | 확인사항 |
|---|---|---|---|---|---|
| 0 | 점검 모드 전환 | LB에서 결제 트래픽 점검 페이지로 전환 | 김 | 2분 | 사용자에게 점검 안내 노출됨 |
| 1 | 사전 백업 | payment DB 풀백업 + 스키마 스냅샷 | 이 | 10분 | 백업 파일 크기·해시 확인, 복구 테스트 1건 |
| 2 | 현 버전 태깅 | payment-svc v1.8 이미지 태그 보존 | 김 | 2분 | rollback용 이미지 레지스트리에 존재 |
| 3 | 마이그레이션 | migration 030 실행(컬럼 추가) | 이 | 5분 | 마이그레이션 로그 성공, 신규 컬럼 2개 존재 |
| 4 | 신버전 배포 | payment-svc v2.0 롤링 배포 | 김 | 5분 | 파드 전부 Running, 구버전 종료 |
| 5 | 설정 반영 | PG 엔드포인트 URL 교체 후 재기동 | 김 | 3분 | 설정값 v2 PG로 적용됨 |
| 6 | 스모크 테스트 | 헬스체크 + 테스트 카드 결제 1건 | 박 | 5분 | 200 응답, 테스트 결제 승인·취소 정상 |
| 7 | 점검 해제 | LB 트래픽 정상 라우팅으로 복귀 | 김 | 2분 | 실제 사용자 결제 표본 정상 |
| 8 | 반영 후 점검 | 점검 체크리스트 전 항목 확인 | 박·홍 | 10분 | 체크리스트 전 항목 통과 |
표로 쓰면 좋은 점: 작업 중 "지금 몇 단계인가"를 한 손가락으로 가리킬 수 있고, 예상시간 합계로 점검창 안에 끝나는지를 미리 계산할 수 있습니다(위 합계 약 44분 + 여유 = 1시간 내). 또 각 단계의 확인사항이 통과해야 다음으로 넘어가므로, 절반에서 멈춘 채 다음을 진행하는 사고가 줄어듭니다.
롤백계획서 — 실패를 가정하고 미리 쓴다
조건 → 절차 → 데이터 복구 → 롤백 불가 대비
롤백계획서는 조건이 절차보다 먼저입니다. "어떻게 되돌리나"보다 "언제 되돌리기로 정했나"가 핵심입니다. 네 부분으로 구성합니다.
[ 롤백계획서 RB-2026-0612-01 — 결제 모듈 v2 배포 ]
A. 롤백 발동 조건 (언제 되돌리는가)
- 헬스체크가 3회 연속 실패
- 테스트 결제(스모크) 승인 실패 또는 응답 5초 초과
- 결정 시한 03:00 까지 핵심 거래 정상화 미달성
- 위 중 하나라도 해당 시 즉시 롤백 (총괄 홍 판단·선언)
B. 롤백 절차 (어떻게 되돌리는가) — 작업절차서의 역순
1) LB 결제 트래픽을 다시 점검 페이지로 전환
2) payment-svc 를 보존해 둔 v1.8 이미지로 재배포
3) PG 엔드포인트 설정을 v1 값으로 원복
4) (필요 시) DB 마이그레이션 030 다운 스크립트 실행 또는 백업 복구
5) 헬스체크·테스트 결제로 v1.8 정상 확인 후 트래픽 복귀
C. 데이터 복구 (되돌릴 때 데이터는)
- 컬럼 추가만 한 경우: 신규 컬럼은 미사용 상태이므로 데이터 손실 없음,
다운 스크립트로 컬럼 제거 또는 그대로 보존(무해)
- 점검 중 실제 거래가 발생했다면: 점검창 내 트랜잭션 로그 보존,
v1 복구 후 정합성 점검(중복 결제·미정산 건 수동 확인)
- 백업 복구가 필요한 경우: 1단계에서 받은 풀백업으로 시점 복구(PITR)
D. 롤백 불가 대비 (되돌릴 수 없을 때)
- 마이그레이션이 비가역적이거나 외부 PG에 이미 결제가 일어난 경우
단순 원복이 불가능 → '전진 복구(fix-forward)'로 전환
- 트리거 기준: 롤백 시도 자체가 30분 내 실패하면 War Room 소집
- 비상 연락: 변경관리자, 서비스책임자, PG사 장애 핫라인
- 최악의 경우 결제만 일시 차단하고 주문은 받는 '부분 축퇴 운영' 결정
가장 자주 빠지는 부분이 **D(롤백 불가 대비)**입니다. 대부분 "되돌리면 되지"라고 가정하지만, 외부 결제망에 이미 거래가 일어났거나 마이그레이션이 비가역이면 되돌릴 수 없습니다. 이때 무작정 원복을 시도하다 더 망가뜨리는 대신, 앞으로 고쳐 나가는(fix-forward) 길과 그 트리거를 미리 정해 둬야 합니다.
위 표를 한 장의 흐름으로 묶으면 이렇게 됩니다. 핵심은 갈림길의 기준(롤백 발동 조건)을 미리 종이에 적어 두는 것입니다. 새벽 작업 중 "조금만 더 해보자"는 즉흥 판단이 가장 위험하므로, 발동 조건과 롤백 한계 시각을 롤백계획서에 박아 두면 현장에서 망설이지 않고 셋 중 하나를 고를 수 있습니다.
직접 해보기 — 작업절차서와 롤백을 한 쌍으로
가상의 작은 변경 하나를 잡고, 위 템플릿을 줄여 작업절차서 단계표와 롤백계획서 A·B를 직접 채워 보세요. 거창할 필요 없이, 다음 변경이면 충분합니다.
변경: 운영 웹서버 nginx proxy_read_timeout 30s → 60s 로 상향
사유: 외부 PG 응답 지연 시 게이트웨이 타임아웃(504) 발생
점검창: 23:00 ~ 23:30 / 결정 시한 23:20
채워야 할 것:
- 작업절차서: 백업 → 설정 변경 → 문법검사 → 리로드 → 확인 (단계·명령·담당·예상시간·확인사항)
- 롤백계획서 A(조건): 어떤 증상이면 되돌릴지 2개 이상
- 롤백계획서 B(절차): 원래 설정으로 되돌리는 순서
힌트가 필요하면 nginx는 nginx -t(문법검사)와 nginx -s reload(무중단 리로드)가 있고, 설정 파일을 바꾸기 전 cp로 백업해 두면 원복이 파일 교체 한 번으로 끝납니다.
대상: nginx 설정 변경(타임아웃 30s → 60s) 운영 반영- 작업절차서에 "백업" 단계가 0~1번에 있는가 — 백업이 없으면 롤백 B의 "원래 설정으로 복귀"가 불가능하다
- 각 단계에 확인사항이 있는가 — 예: 설정 변경 후 "nginx -t 가 syntax is ok 출력" 같은 통과 기준
- 롤백 조건(A)이 측정 가능한가 — "느리면"이 아니라 "504 발생" 또는 "헬스체크 3회 실패"처럼 객관적 신호
- 롤백 절차(B)가 작업절차서의 역순으로 대응되는가 — 바꾼 것을 정확히 되돌리는 짝이 있는가
- 예상시간 합계가 점검창 안에 들어오는가 — 합계 + 여유가 30분(23:00~23:30)을 넘지 않는가
- 핵심 감각: 절차서와 롤백계획서는 항상 한 쌍 — 절차서만 있고 롤백이 없으면 "돌이킬 수 없는 작업"을 하는 것
현장에서 자주 보는 함정
증상: 변경계획서·작업절차서·롤백계획서를 다 갖춰 새벽 점검에 들어갔는데, 정작 결제가 안 되자 "원인을 조금만 더 보자"가 반복됐습니다. 02:00 점검창이 05:00을 넘겼고, 아침 출근 트래픽까지 결제가 죽어 장애로 확대됐습니다. 롤백계획서는 책상 위에 펼쳐져 있었지만 아무도 발동하지 않았습니다.
원인: 문서가 있는 것과 발동 기준이 합의된 것은 다릅니다. (1) 롤백 조건이 "정상화 안 되면"처럼 모호했고, (2) **결정 시한(point of no return)**이 없었으며, (3) "누가 롤백을 선언하는가"가 정해지지 않아 아무도 책임지고 멈추지 못했습니다. 엔지니어 본능은 "고치고 싶다"이고, 그 본능이 시한 없는 현장에서 점검창을 잡아먹습니다.
해결 방향:
- 롤백 조건을 측정 가능한 신호로: "헬스체크 3회 실패", "스모크 결제 승인 실패", "03:00까지 핵심 거래 미정상".
- 결정 시한을 변경계획서·롤백계획서·공지에 동일하게 박아 둔다(예: 03:00).
- 롤백 선언 권한자를 단 한 명 지정(총괄). 그 사람이 시계를 본다.
- 점검 공지에 "최대 04:00까지, 롤백 시 연장 가능"을 적어 두면, 현장도 고객도 시한을 공유한다.
ITSM에서 롤백은 패배가 아니라 계획된 안전장치의 정상 작동입니다. 시한 안에 깔끔하게 되돌린 팀이, 시한을 넘겨 끝까지 고친 팀보다 좋은 운영을 한 것입니다.
한국 SI/SM 현장에서 운영계 반영은 거의 야간·주말 점검창에서 일어납니다. 낮에 결제를 멈출 수 없으니, 트래픽이 적은 새벽에 모여 반영합니다. 이때 관리자(운영 담당·PM)는 직접 명령을 치기보다 문서로 통제합니다 — 변경계획서로 발주사·내부 승인을 받고, 협력사(하도급) 엔지니어가 작업절차서를 그대로 따르게 하며, 롤백계획서로 실패의 출구를 미리 확보합니다.
문서는 안에서만 도는 게 아닙니다. 반영 전날에는 고객 점검 공지(또는 발주사·이용기관 통보)를 정해진 채널로 보냅니다 — "○월 ○일 02:00~04:00 결제 서비스 점검, 해당 시간 결제 일시 중단, 문의 ☎ ...". 야간 작업이 끝나면 아침에 결과보고를 올립니다 — 예정대로 반영했는지, 이상은 없었는지, 롤백을 했다면 왜 했고 다음 계획은 무엇인지. 발주사는 이 세 가지(사전 승인 문서·사전 공지·사후 결과보고)로 "통제된 운영"인지를 판단하고, 그게 곧 SLA·재계약의 신뢰가 됩니다.
그래서 이 자리에서 당신의 실력은 "배포를 빨리 하는 것"이 아니라 **"반영 전에 무엇을 종이에 적어 승인받고, 무엇을 고객에게 알리고, 실패를 어떻게 미리 설계해 두는가"**로 드러납니다. 협력사가 실제 손을 움직여도, 이 세 문서와 공지·보고에 대한 책임은 관리자에게 있습니다.
관련 모듈로 더 깊이:
- 변경 관리(변경 활성화) — 변경계획서가 통과하는 변경관리·승인 프로세스 전체
- 작업계획서·롤백계획서·점검계획 — 롤백계획서를 실제 점검창에서 실행하는 체크리스트
- 릴리스와 배포 관리 — 작업절차서가 적용되는 릴리즈·배포 흐름
다음 모듈에서는 이렇게 반영한 작업의 결과를 한 장으로 정리해 위로 올리는 보고 문서 — 주간 운영 보고서와 경영 보고를 다룹니다.