작업계획서·롤백계획서·점검계획 — 실패를 가정하고 준비한다

운영계 반영을 앞두면 엔지니어는 보통 "어떻게 작업할지"만 머릿속에 그립니다. 그러나 운영 반영의 통제는 세 개의 다른 질문에 답하는 세 개의 문서로 이뤄집니다. 각 문서는 서로 다른 순간을 보증합니다.

세 문서가 노리는 공통점은 상황을 사람의 즉흥 판단에 맡기지 않는 것입니다. 새벽 2시에 장애가 났을 때 가장 위험한 것은 "그때 가서 생각하자"입니다. 그 순간 사람은 당황하고, 당황한 사람은 실수합니다. 세 문서는 그 순간에 읽을 대본을 미리 써두는 일입니다.

특히 롤백계획서는 '있으면 좋은 것'이 아니라 변경 승인의 전제 조건입니다. 다음 절에서 보듯, 승인자가 가장 먼저 던지는 질문이 여기서 나옵니다.

변경자문위원회(CAB)나 운영 책임자가 변경 요청서를 받았을 때, 경험 많은 승인자는 "이거 잘 되겠네"부터 보지 않습니다. **"이거 실패하면?"**부터 봅니다. 그래서 가장 먼저 나오는 질문이 "롤백 가능한가?"입니다.

이 질문이 핵심인 이유는 운영계의 비대칭성 때문입니다. 변경이 성공하면 얻는 이득은 점진적이지만, 실패하면 잃는 손해(매출·신뢰·SLA 위반)는 즉각적이고 큽니다. 그래서 운영은 '성공 확률을 높이는 것'만큼 '실패 비용을 낮추는 것'을 중요하게 봅니다. 롤백 경로는 실패 비용을 낮추는 가장 직접적인 안전장치입니다.

롤백 가능성에 따라 변경의 위험 등급과 통제 수준이 달라집니다.

여기서 신입이 흔히 오해하는 지점 — "롤백이 불가능하면 그 변경은 못 한다"가 아닙니다. DB 스키마 마이그레이션처럼 원천적으로 되돌리기 어려운 작업도 운영에는 늘 있습니다. 핵심은 '롤백 불가를 인지하고 그에 맞는 대비를 했는가'입니다. 모르고 못 되돌리는 것과, 알고 다른 안전장치를 마련한 것은 전혀 다릅니다.

작업계획서(작업절차서)는 "누가 해도 같은 순서로 작업하고, 어디서 멈추면 어디로 되돌리는지"를 담는 문서입니다. 잘 쓴 작업계획서는 작업자가 새벽에 졸려도, 다른 사람으로 교대해도 손이 멈추지 않게 합니다.

필수 요소는 네 가지입니다.

• 단계(Step): 작업을 되돌릴 수 있는 최소 단위로 쪼갠 순서. "배포한다" 같은 뭉뚱그린 단계 금지.
• 담당(Owner): 각 단계를 누가 실행하고 누가 확인(검증)하는지. 실행자와 확인자를 분리하면 실수가 줄어듭니다.
• 예상 소요시간(ETA): 각 단계가 몇 분 걸리는지. 누적 시간이 점검창을 넘으면 계획 자체가 틀린 것입니다.
• 롤백 포인트(Rollback point): 각 단계 이후 "여기서 실패하면 어디로 되돌리는가". 이 컬럼이 작업계획서를 롤백계획서와 잇는 다리입니다.

아래는 결제 모듈 v2 운영 반영의 작업계획서 예시 템플릿입니다.

누적 예상시간이 약 85분입니다. 점검창이 새벽 1시~3시(2시간)라면 여유 시간이 35분 남습니다. 이 여유분이 롤백에 쓸 시간 예산입니다. 여유가 롤백 소요시간보다 작으면, 점검창을 늘리거나 작업 범위를 줄여야 합니다. 이 계산을 빼먹으면 "롤백하려는데 점검창이 끝나 트래픽이 들어오는" 최악의 상황이 됩니다.

롤백계획서의 가장 흔한 실패는 "문제 생기면 되돌린다"라고만 적어두는 것입니다. 새벽에 그 한 줄은 아무것도 알려주지 않습니다. 롤백계획서는 네 가지를 구체적으로 적어야 합니다.

• 원복 조건(트리거): 언제 롤백을 결정하는가. "결제 실패율 5% 초과가 5분 지속" 같은 측정 가능한 기준. 누가 그 결정을 내릴 권한이 있는지(롤백 결정권자)도 함께.
• 원복 절차: 작업계획서의 롤백 포인트를 실제 명령·순서로 풀어쓴 것. 즉흥이 끼어들 틈이 없어야 합니다.
• 데이터 복구: 코드·설정은 파일을 바꾸면 되지만, 작업 중 쌓인 데이터는 그렇지 않습니다. 마이그레이션한 테이블, 새로 들어온 주문을 어떻게 다룰지 명시.
• 롤백 불가 케이스 대비: 되돌릴 수 없는 작업을 만났을 때의 우회 안전장치.

원복 조건은 측정 가능해야 합니다. "느려지면"이 아니라 "응답시간 p95가 2초 초과로 10분 지속"처럼.

데이터 복구는 가장 까다로운 부분입니다. 코드 롤백은 5분이지만, 그사이 들어온 주문 데이터를 버릴 수는 없습니다. 그래서 롤백계획서에는 "신규 버전이 쓴 데이터를 구버전이 읽을 수 있는가"를 미리 검토해 둡니다. 읽을 수 없다면, 점검창 동안 트래픽을 차단해 신규 데이터 자체가 생기지 않게 하는 식으로 작업을 설계합니다(앞 작업계획서의 2단계 트래픽 차단이 그 역할입니다).

롤백 불가 케이스는 정직하게 적습니다. DB 스키마 변경처럼 컬럼을 지우면 데이터가 사라져 되돌릴 수 없는 작업은, "롤백 불가" 한 줄로 끝내지 않고 다음을 명시합니다 — (1) 작업 직전 전체 백업과 그 백업의 복구 리허설 결과, (2) 컬럼을 지우는 대신 미사용으로 남겨 다음 배포에서 정리하는 단계적 전략, (3) 복구 시 데이터 손실 범위와 예상 복구 시간. 이렇게 적힌 롤백계획서를 본 승인자는 "못 되돌린다"가 아니라 "되돌릴 수 없는 걸 알고 대비했다"로 읽습니다.

반영을 마친 직후가 가장 위험한 착각의 순간입니다. "배포 명령이 성공했다"거나 "헬스체크가 200을 준다"를 보고 "끝났다"고 선언하는 것. 헬스체크 200은 프로세스가 떠서 응답한다는 신호일 뿐, 핵심 기능이 정상이라는 보증이 아닙니다. 잘못된 설정으로 배포된 앱도 헬스체크는 멀쩡히 통과하면서 결제만 실패하는 일이 흔합니다.

그래서 점검계획은 두 개의 층으로 설계합니다.

• 1층 — 인프라/프로세스 신호: 프로세스 기동, 헬스체크 응답, 오류 로그 급증 여부, 의존 서비스(DB·외부 API) 연결. "살아 있는가"를 본다.
• 2층 — 핵심 기능 시나리오: 실제 사용자가 하는 일을 한 번 끝까지 해본다. 결제 서비스라면 로그인 → 상품 조회 → 장바구니 → 주문 → 실제 결제 1건 성공. "쓸 수 있는가"를 본다.

아래는 결제 모듈 v2 반영 후 점검 체크리스트 예시입니다.

2층까지 통과해야 비로소 "정상 반영"을 선언합니다. 특히 이번 변경의 목적이 '신규 카드사 연동'이므로, 그 신규 카드사로 실제 결제가 성공하는지를 확인하지 않으면 점검의 의미가 없습니다. 점검계획은 항상 이번 변경이 무엇을 위한 것이었는지를 반영해 설계해야 합니다.

확대

그림: 헬스체크 200(프로세스가 살아 있다)과 서비스 정상은 다르다 — 1층 인프라 신호를 지나 2층 핵심 기능 시나리오(이번 변경의 목적)까지 통과해야 "정상 반영"이다.

롤백계획서가 완벽해도, 새벽 3시에 그 계획을 실행하는 것은 문서가 아니라 사람입니다. 그리고 그 순간의 사람은 문서와 다르게 움직일 강한 이유를 갖고 있습니다. 롤백이 늦어지는 진짜 원인은 대부분 절차의 부재가 아니라 심리와 조직 역학입니다.

• 매몰비용 — "5분만 더 보면 고칠 수 있을 것 같다": 몇 주를 준비한 작업을 되돌리는 결정은 심리적으로 비쌉니다. 원인이 눈앞에 보일 것 같은 상태가 가장 위험합니다 — 5분이 30분이 되고, 그사이 점검창이 끝납니다. 트리거를 측정 가능한 숫자로 적는 진짜 이유가 여기 있습니다. 판단을 숫자에 위임해, 매몰비용이 끼어들 틈을 없애는 것입니다.
• 롤백 = 실패라는 기록의 공포: 결과보고에 롤백 발생이 적히면 발주사 앞에서 '실패한 작업'이 된다는 인식이 있는 조직에서는, 모두가 롤백 선언을 서로 미룹니다. 성숙한 조직은 반대로 기록합니다 — 트리거 충족 후 몇 분 만에 롤백을 개시했는가를 통제 능력의 지표로 삼고, 오히려 트리거를 넘기고도 붙잡고 있었던 쪽을 문제 삼습니다. 롤백은 실패가 아니라 통제가 작동한 증거라는 합의가 결과보고 양식에까지 반영돼야 실제로 작동합니다.
• 결정권자의 부재와 상향 회피: 계획서에 결정권자가 적혀 있어도, 새벽에 그 사람이 전화를 안 받거나 "일단 본부장께 여쭤보고"가 시작되면 트리거는 장식이 됩니다. 결정권자에게는 연락 불가 시의 대행 순서까지 붙어야 하고, 트리거 충족 시의 롤백은 승인 사항이 아니라 보고 사항(선 실행, 후 보고)이라는 위임이 사전에 합의돼야 합니다.

작업계획서·롤백계획서를 검토하는 관리자라면 마지막 질문 하나를 더하세요 — "트리거가 충족됐을 때, 현장에서 가장 낮은 직급의 작업자가 롤백을 개시할 수 있습니까?" 이 답이 '아니오'라면 계획서가 아니라 권한 설계가 미완성입니다.