금요일 저녁, 협력사 엔지니어가 메신저로 한 줄을 보냅니다. "결제 모듈 패치 운영 반영 완료했습니다."
토요일 새벽 2시, 결제 실패율이 치솟습니다. 패치가 특정 카드사 응답 포맷을 깨뜨렸습니다. 당직자가 묻습니다 — "원래대로 되돌릴 수 있나요?" 돌아온 답: "음... 이전 버전 파일이 어디 있는지 찾아봐야 합니다. 설정도 같이 바뀌어서요. DB 스키마도 한 번 건드렸는데..."
복구에 4시간이 걸렸습니다. 새벽 매출이 통째로 날아갔고, 월요일 발주사 보고에서 가장 먼저 나온 질문은 "왜 되돌리는 데 4시간이나 걸렸습니까?"였습니다.
이 사고의 본질은 '패치가 버그가 있었다'가 아닙니다. 실패를 가정하지 않고 반영했다는 것입니다. 잘 될 때의 계획만 있었고, 안 될 때의 계획 — 롤백계획서 — 이 없었습니다. 이 모듈은 운영 반영 전에 반드시 준비하는 세 가지 문서, 작업계획서·롤백계획서·점검계획을 실제 템플릿으로 다룹니다.
- 1운영 반영 전 작업계획서·롤백계획서·점검계획이 각각 무엇을 보증하는지 구분해 설명할 수 있다
- 2작업계획서에 단계·담당·예상시간·롤백 포인트·사전 점검표를 담아 작성할 수 있다
- 3"롤백 가능한가?"가 왜 변경 승인의 핵심 질문인지, 롤백 불가 케이스를 어떻게 대비하는지 설명할 수 있다
- 4배포 후 점검계획을 인프라 신호와 핵심 기능 시나리오 두 층으로 설계할 수 있다
- 5한국 SI/SM의 야간 점검창·작업공지·결과보고로 이어지는 운영 반영 절차를 따라갈 수 있다
세 개의 문서, 세 개의 질문
잘 될 때가 아니라, 안 될 때를 적는 문서들
운영계 반영을 앞두면 엔지니어는 보통 "어떻게 작업할지"만 머릿속에 그립니다. 그러나 운영 반영의 통제는 세 개의 다른 질문에 답하는 세 개의 문서로 이뤄집니다. 각 문서는 서로 다른 순간을 보증합니다.
| 문서 | 답하는 질문 | 언제 쓰이나 |
|---|---|---|
| 작업계획서(작업절차서) | "정확히 어떤 순서로, 누가, 얼마나 걸려 작업하는가?" | 작업 진행 중 — 손이 멈추지 않게 |
| 롤백계획서 | "실패하면 어떻게 원래 상태로 되돌리는가?" | 작업 실패 시 — 패닉 없이 |
| 점검계획(검증계획) | "반영 후 정말 정상인지 어떻게 확인하는가?" | 작업 직후 — 끝났다고 착각하지 않게 |
세 문서가 노리는 공통점은 상황을 사람의 즉흥 판단에 맡기지 않는 것입니다. 새벽 2시에 장애가 났을 때 가장 위험한 것은 "그때 가서 생각하자"입니다. 그 순간 사람은 당황하고, 당황한 사람은 실수합니다. 세 문서는 그 순간에 읽을 대본을 미리 써두는 일입니다.
특히 롤백계획서는 '있으면 좋은 것'이 아니라 변경 승인의 전제 조건입니다. 다음 절에서 보듯, 승인자가 가장 먼저 던지는 질문이 여기서 나옵니다.
그림: 세 문서는 서로를 참조한다 — 작업계획서의 롤백 포인트가 롤백계획서의 절차로, 점검계획의 실패가 롤백 트리거로 이어진다.
"롤백 가능한가?" — 변경 승인의 첫 질문
실패를 가정하면 우선순위가 바뀐다
변경자문위원회(CAB)나 운영 책임자가 변경 요청서를 받았을 때, 경험 많은 승인자는 "이거 잘 되겠네"부터 보지 않습니다. **"이거 실패하면?"**부터 봅니다. 그래서 가장 먼저 나오는 질문이 "롤백 가능한가?"입니다.
이 질문이 핵심인 이유는 운영계의 비대칭성 때문입니다. 변경이 성공하면 얻는 이득은 점진적이지만, 실패하면 잃는 손해(매출·신뢰·SLA 위반)는 즉각적이고 큽니다. 그래서 운영은 '성공 확률을 높이는 것'만큼 '실패 비용을 낮추는 것'을 중요하게 봅니다. 롤백 경로는 실패 비용을 낮추는 가장 직접적인 안전장치입니다.
롤백 가능성에 따라 변경의 위험 등급과 통제 수준이 달라집니다.
| 롤백 상태 | 위험 인식 | 요구되는 추가 통제 |
|---|---|---|
| 즉시 롤백 가능(분 단위) | 낮음 | 표준 변경으로 신속 승인 가능 |
| 롤백 가능하나 시간 소요(시간 단위) | 중간 | 점검창 충분히 확보, 롤백 리허설 권장 |
| 부분 롤백만 가능 | 높음 | 단계적 반영, 영향 최소 구간부터, 입회자 지정 |
| 롤백 사실상 불가 | 매우 높음 | 사전 백업·복구 리허설 필수, 분리된 안전장치 마련 |
여기서 신입이 흔히 오해하는 지점 — "롤백이 불가능하면 그 변경은 못 한다"가 아닙니다. DB 스키마 마이그레이션처럼 원천적으로 되돌리기 어려운 작업도 운영에는 늘 있습니다. 핵심은 '롤백 불가를 인지하고 그에 맞는 대비를 했는가'입니다. 모르고 못 되돌리는 것과, 알고 다른 안전장치를 마련한 것은 전혀 다릅니다.
작업계획서 — 손이 멈추지 않게 하는 대본
단계·담당·예상시간·롤백 포인트
작업계획서(작업절차서)는 "누가 해도 같은 순서로 작업하고, 어디서 멈추면 어디로 되돌리는지"를 담는 문서입니다. 잘 쓴 작업계획서는 작업자가 새벽에 졸려도, 다른 사람으로 교대해도 손이 멈추지 않게 합니다.
필수 요소는 네 가지입니다.
- 단계(Step): 작업을 되돌릴 수 있는 최소 단위로 쪼갠 순서. "배포한다" 같은 뭉뚱그린 단계 금지.
- 담당(Owner): 각 단계를 누가 실행하고 누가 확인(검증)하는지. 실행자와 확인자를 분리하면 실수가 줄어듭니다.
- 예상 소요시간(ETA): 각 단계가 몇 분 걸리는지. 누적 시간이 점검창을 넘으면 계획 자체가 틀린 것입니다.
- 롤백 포인트(Rollback point): 각 단계 이후 "여기서 실패하면 어디로 되돌리는가". 이 컬럼이 작업계획서를 롤백계획서와 잇는 다리입니다.
아래는 결제 모듈 v2 운영 반영의 작업계획서 예시 템플릿입니다.
| 단계 | 작업 내용 | 실행 / 확인 | 예상시간 | 롤백 포인트 |
|---|---|---|---|---|
| 0 | 사전 점검표 확인(백업·연락망·점검창) | SM 운영 / PM | 10분 | (작업 미시작 — 원복 불필요) |
| 1 | 현재 버전·설정 스냅샷 백업 | 협력사 엔지니어 / SM 운영 | 15분 | 백업 검증 실패 시 작업 중단 |
| 2 | 트래픽 차단(점검 페이지 전환) | SM 운영 / SM 운영 | 5분 | 점검 페이지 해제로 즉시 복귀 |
| 3 | 신규 버전 배포 | 협력사 엔지니어 / 협력사 리더 | 10분 | 1단계 백업본으로 재배포 |
| 4 | 설정·환경변수 적용 | 협력사 엔지니어 / SM 운영 | 10분 | 백업한 이전 설정으로 원복 |
| 5 | 헬스체크 및 기능 점검(점검계획 실행) | SM 운영 / PM | 20분 | 점검 실패 시 3~4단계 일괄 원복 |
| 6 | 트래픽 재개(점검 페이지 해제) | SM 운영 / SM 운영 | 5분 | 이상 시 다시 점검 페이지로 |
| 7 | 작업 결과보고 작성·발송 | PM / 발주사 | 10분 | (사후 — 원복 불필요) |
누적 예상시간이 약 85분입니다. 점검창이 새벽 1시~3시(2시간)라면 여유 시간이 35분 남습니다. 이 여유분이 롤백에 쓸 시간 예산입니다. 여유가 롤백 소요시간보다 작으면, 점검창을 늘리거나 작업 범위를 줄여야 합니다. 이 계산을 빼먹으면 "롤백하려는데 점검창이 끝나 트래픽이 들어오는" 최악의 상황이 됩니다.
롤백계획서 — 원복 조건·절차·데이터·불가 케이스
언제 되돌릴지, 어떻게 되돌릴지, 못 되돌리면 어떻게 할지
롤백계획서의 가장 흔한 실패는 "문제 생기면 되돌린다"라고만 적어두는 것입니다. 새벽에 그 한 줄은 아무것도 알려주지 않습니다. 롤백계획서는 네 가지를 구체적으로 적어야 합니다.
- 원복 조건(트리거): 언제 롤백을 결정하는가. "결제 실패율 5% 초과가 5분 지속" 같은 측정 가능한 기준. 누가 그 결정을 내릴 권한이 있는지(롤백 결정권자)도 함께.
- 원복 절차: 작업계획서의 롤백 포인트를 실제 명령·순서로 풀어쓴 것. 즉흥이 끼어들 틈이 없어야 합니다.
- 데이터 복구: 코드·설정은 파일을 바꾸면 되지만, 작업 중 쌓인 데이터는 그렇지 않습니다. 마이그레이션한 테이블, 새로 들어온 주문을 어떻게 다룰지 명시.
- 롤백 불가 케이스 대비: 되돌릴 수 없는 작업을 만났을 때의 우회 안전장치.
원복 조건은 측정 가능해야 합니다. "느려지면"이 아니라 "응답시간 p95가 2초 초과로 10분 지속"처럼.
| 측정 지표 | 정상 기준 | 롤백 트리거 | 결정권자 |
|---|---|---|---|
| 결제 성공률 | 99% 이상 | 95% 미만 5분 지속 | 당직 SM 리더 |
| 응답시간(p95) | 1초 이하 | 2초 초과 10분 지속 | 당직 SM 리더 |
| 5xx 오류율 | 0.1% 이하 | 1% 초과 즉시 | 당직 SM 리더 |
| 헬스체크 | 연속 통과 | 연속 3회 실패 | 작업자 즉시 판단 |
| 핵심 기능 점검 | 전 항목 통과 | 1개 이상 실패 | 당직 SM 리더 |
데이터 복구는 가장 까다로운 부분입니다. 코드 롤백은 5분이지만, 그사이 들어온 주문 데이터를 버릴 수는 없습니다. 그래서 롤백계획서에는 "신규 버전이 쓴 데이터를 구버전이 읽을 수 있는가"를 미리 검토해 둡니다. 읽을 수 없다면, 점검창 동안 트래픽을 차단해 신규 데이터 자체가 생기지 않게 하는 식으로 작업을 설계합니다(앞 작업계획서의 2단계 트래픽 차단이 그 역할입니다).
롤백 불가 케이스는 정직하게 적습니다. DB 스키마 변경처럼 컬럼을 지우면 데이터가 사라져 되돌릴 수 없는 작업은, "롤백 불가" 한 줄로 끝내지 않고 다음을 명시합니다 — (1) 작업 직전 전체 백업과 그 백업의 복구 리허설 결과, (2) 컬럼을 지우는 대신 미사용으로 남겨 다음 배포에서 정리하는 단계적 전략, (3) 복구 시 데이터 손실 범위와 예상 복구 시간. 이렇게 적힌 롤백계획서를 본 승인자는 "못 되돌린다"가 아니라 "되돌릴 수 없는 걸 알고 대비했다"로 읽습니다.
직접 해보기 — 세 문서를 한 변경에 적용하기
아래 변경 요청을 받았다고 가정하고, 세 문서의 핵심 항목을 직접 채워 보세요. 정답 감각은 ObserveBlock에 있습니다.
[변경 요청서]
- 대상: 운영계 결제 서비스
- 내용: 결제 모듈 v1 → v2 (신규 카드사 연동 추가)
- 동반 변경: 환경변수 1개 추가, DB에 컬럼 1개 추가(삭제 없음)
- 점검창: 화요일 새벽 1:00 ~ 3:00 (2시간)
- 제약: 새벽에도 소수의 해외 주문이 들어올 수 있음
채워야 할 항목:
- 작업계획서: 단계를 롤백 가능한 단위로 쪼개고, 각 단계에 실행/확인 담당과 예상시간, 롤백 포인트를 적는다. 누적 시간이 점검창을 넘지 않는지 확인.
- 롤백계획서: 원복 조건(측정 가능한 트리거)과 결정권자, 원복 절차, 그리고 "새벽에 들어온 해외 주문 데이터"를 어떻게 다룰지(데이터 복구).
- 점검계획: 반영 직후 무엇을 확인하면 "정상"이라 선언할 수 있는지. 헬스체크만으로 충분한지 생각.
작업계획서 → 롤백계획서 → 점검계획- 작업계획서: 백업 → 트래픽 차단 → 배포 → 설정 적용 → 점검 → 트래픽 재개 → 결과보고 순. 누적시간이 2시간 안에 들고, 롤백에 쓸 여유시간을 남겨야 정상
- 롤백 포인트: 각 단계마다 "여기서 실패하면 어디로"가 비어 있지 않아야 함. 비어 있으면 그 단계는 통제 불능 구간
- 롤백계획서 원복 조건: "문제 생기면"이 아니라 "결제 성공률 95% 미만 5분 지속"처럼 측정 가능한 기준 + 결정권자 명시
- 데이터 복구: DB 컬럼은 추가만(삭제 없음)이라 구버전이 무시하고 읽을 수 있음 → 비교적 안전. 다만 해외 주문이 v2 전용 컬럼을 쓰면 롤백 후 그 데이터 처리 방안을 적어야 함
- 데이터 안전장치: 트래픽 차단(점검 페이지) 단계를 두면, 점검창 동안 신규 주문 자체가 안 생겨 롤백 시 데이터 충돌이 사라짐 — 작업 설계로 위험을 없애는 방법
- 점검계획: 헬스체크 200 통과만으로 종료하면 위험. "신규 카드사로 실제 결제 1건 성공"까지 확인해야 v2의 목적이 검증됨
- 핵심 감각: 세 문서가 서로를 참조한다 — 작업계획서의 롤백 포인트가 롤백계획서의 절차로, 점검계획의 실패가 롤백계획서의 트리거로 이어진다
배포 후 점검계획 — 두 개의 층으로 본다
프로세스가 살아 있다 ≠ 서비스가 정상이다
반영을 마친 직후가 가장 위험한 착각의 순간입니다. "배포 명령이 성공했다"거나 "헬스체크가 200을 준다"를 보고 "끝났다"고 선언하는 것. 헬스체크 200은 프로세스가 떠서 응답한다는 신호일 뿐, 핵심 기능이 정상이라는 보증이 아닙니다. 잘못된 설정으로 배포된 앱도 헬스체크는 멀쩡히 통과하면서 결제만 실패하는 일이 흔합니다.
그래서 점검계획은 두 개의 층으로 설계합니다.
- 1층 — 인프라/프로세스 신호: 프로세스 기동, 헬스체크 응답, 오류 로그 급증 여부, 의존 서비스(DB·외부 API) 연결. "살아 있는가"를 본다.
- 2층 — 핵심 기능 시나리오: 실제 사용자가 하는 일을 한 번 끝까지 해본다. 결제 서비스라면 로그인 → 상품 조회 → 장바구니 → 주문 → 실제 결제 1건 성공. "쓸 수 있는가"를 본다.
아래는 결제 모듈 v2 반영 후 점검 체크리스트 예시입니다.
| 층 | 점검 항목 | 정상 기준 | 확인 방법 |
|---|---|---|---|
| 1층 | 프로세스 기동 | 모든 인스턴스 정상 | 프로세스 상태 조회 |
| 1층 | 헬스체크 | 연속 통과 | 헬스 엔드포인트 응답 |
| 1층 | 오류 로그 | 급증 없음 | 최근 로그 5xx 비율 확인 |
| 1층 | 의존 연결 | DB·카드사 API 연결 정상 | 연결 상태·핑 확인 |
| 2층 | 기존 카드 결제 | 1건 성공 | 테스트 결제 실행 |
| 2층 | 신규 카드사 결제 | 1건 성공(v2 목적) | 신규 카드사로 테스트 결제 |
| 2층 | 주문 데이터 적재 | 결제 결과가 정상 기록 | 주문 테이블 조회 |
| 2층 | 응답시간 | p95 1초 이하 | 모니터링 대시보드 확인 |
2층까지 통과해야 비로소 "정상 반영"을 선언합니다. 특히 이번 변경의 목적이 '신규 카드사 연동'이므로, 그 신규 카드사로 실제 결제가 성공하는지를 확인하지 않으면 점검의 의미가 없습니다. 점검계획은 항상 이번 변경이 무엇을 위한 것이었는지를 반영해 설계해야 합니다.
그림: 헬스체크 200(프로세스가 살아 있다)과 서비스 정상은 다르다 — 1층 인프라 신호를 지나 2층 핵심 기능 시나리오(이번 변경의 목적)까지 통과해야 "정상 반영"이다.
현장에서 자주 보는 함정
증상: 변경 승인 때 롤백계획서를 제출했고 승인도 받았습니다. 그런데 실제 장애가 나서 롤백을 시도하니, 적힌 절차대로 안 되거나, 롤백 과정에서 오히려 새로운 장애가 터집니다.
원인: 롤백계획서를 글로만 썼고 한 번도 실행해보지 않았습니다. 종이 위의 절차는 늘 깔끔하지만, 실제로는 백업본이 손상돼 있거나, 이전 설정 파일을 못 찾거나, 롤백 명령에 권한이 없거나, 구버전이 신버전 데이터를 읽다 깨집니다. 검증되지 않은 롤백계획서는 '있다'는 안도감만 줄 뿐, 새벽에는 또 다른 즉흥 작업이 됩니다.
해결 방향:
- 롤백 리허설: 운영과 동일한 스테이징에서 배포→롤백을 실제로 한 번 돌려본다. 백업본 복구까지 포함. 고위험 변경일수록 필수.
- 백업 검증: 백업을 떴다는 것과 그 백업이 실제로 복구된다는 것은 다르다. 작업 전 단계(앞 작업계획서 1단계)에서 백업 검증을 명시적으로 한다.
- 데이터 비대칭 점검: 구버전이 신버전이 쓴 데이터를 읽을 수 있는지 미리 확인. 못 읽으면 트래픽 차단으로 신규 데이터를 막거나, 점검창 동안만 데이터 생성을 보류한다.
- 롤백 결정권자·시간 예산: 누가 롤백을 결정할 권한이 있는지, 롤백에 쓸 시간이 점검창에 남아 있는지 사전에 확정. 새벽에 "이거 되돌려도 되나요?"를 윗선에 물으며 시간을 까먹는 일을 없앤다.
롤백계획서는 '제출용 문서'가 아니라 '새벽에 실행할 대본'입니다. 리허설로 검증되지 않은 대본은 대본이 아닙니다.
한국 SI/SM 현장에서 운영계 반영은 거의 항상 야간 점검창에 잡힙니다. 사용자 트래픽이 가장 적은 새벽 시간대를 골라, 설령 롤백을 하더라도 영향받는 고객을 최소화하기 위해서입니다. "왜 굳이 새벽에?"의 답은 한 문장입니다 — 실패를 가정하기 때문입니다.
그 앞뒤로는 정형화된 절차가 붙습니다. 작업 전에는 작업공지를 돌립니다 — 언제(점검창), 무엇을(변경 대상·내용), 영향 범위(어떤 서비스가 얼마간 중단되는지), 그리고 롤백계획을 발주사·유관 부서·고객사에 사전 공유합니다. 작업 후에는 결과보고를 작성합니다 — 계획 대비 실제 소요시간, 점검 결과, 이상 유무, 롤백 발생 여부와 사유. 이 결과보고가 다음 변경의 작업계획서를 개선하는 입력이 됩니다.
이 자리에서 SM 운영 담당이나 PM은 직접 배포 명령을 치기보다, 협력사 엔지니어가 작성한 작업계획서·롤백계획서를 검토하고 승인하는 통제자입니다. 협력사가 "완료했습니다"라고 보고할 때, "롤백 가능한가요? 점검은 2층까지 했나요? 결과보고는요?"라고 되물을 수 있어야 합니다. 기술을 아는 관리자는 잘못된 "완료" 보고에 속지 않고, 검증되지 않은 롤백계획서를 그대로 승인하지 않습니다. 작업계획서·롤백계획서·점검계획은 그 통제의 공용어입니다.
다음 모듈에서는 운영 반영 이후 서비스를 지속적으로 지켜보는 일 — 이벤트·모니터링 관리(무엇을 관측하고, 어떤 신호에 어떻게 반응하며, 노이즈를 어떻게 줄이는가)를 다룹니다.
관련 모듈로 더 깊이:
- 릴리스와 배포 관리 — 작업계획서·롤백계획서가 실제로 쓰이는 릴리스·배포
- 변경계획서·롤백계획서·작업절차서 — 변경·롤백 문서를 관리자 관점에서 작성·검토하는 법
- 이벤트·모니터링 관리 — 반영 후 점검계획을 이어받아 지속 관측하는 모니터링