멈출 시각을 먼저 적는다 — 변경 유형·영향 범위·되돌리기 기준

한 줄 요약

좋은 변경 요청서는 "무엇을 한다" 보다 "언제 멈추고 어떻게 되돌린다" 를 먼저 적는다. 되돌리는 데 걸리는 시간을 작업 창에서 거꾸로 빼면 중단 판단 시각이 나오고, 그 시각이 되돌리기의 방아쇠가 된다. 리허설은 그 계획이 낙관적이었는지를 작업 전에 알려 주는 유일한 방법이다.

왜 이게 필요했나

Google SRE 책은 운영 중인 시스템에서 나는 장애의 약 70% 가 변경 때문이라고 적는다. 변경을 없앨 수는 없으니, 변경이 사고가 되는 길을 좁히는 수밖에 없다. 그 책이 드는 방법은 셋이다 — 점진적으로 내보내기, 문제를 빠르고 정확하게 알아채기, 문제가 생기면 안전하게 되돌리기.

변경 요청서(change request)와 작업 계획서는 이 셋을 작업 전에 종이 위에서 확인하는 도구다. 새벽 세 시에 계획보다 20분 늦어진 작업자가 "조금만 더 하면 될 것 같은데" 를 판단하게 두면 대개 계속한다. 멈출 기준을 미리 숫자로 적어 두면 그 판단을 피곤한 사람에게 맡기지 않아도 된다.

어떻게 동작하나

변경 유형. ITIL 4 의 변경 활성화(change enablement) 관행은 변경을 세 가지로 나눈다.

유형	뜻	예
표준(standard)	위험이 낮고 절차가 미리 승인된, 되풀이되는 변경	승인된 절차서대로 하는 설정 값 조정
일반(normal)	평가와 승인을 거쳐 일정을 잡는 변경	새 절차서로 하는 DB 볼륨 증설
긴급(emergency)	지금 하지 않으면 곧 장애가 되어 빨리 처리해야 하는 변경	몇 시간 뒤 만료되는 인증서 교체

유형을 나누는 이유는 승인 비용을 위험에 맞추려는 것이다. 모든 변경을 위원회에 올리면 사람들은 절차를 우회하고, 모든 변경을 그냥 하면 사고가 난다. 긴급 변경도 승인이 없는 것이 아니라 짧은 경로로 승인받고, 사후에 기록을 채운다.

영향 범위. "DB 한 대 재시작" 의 영향은 그 DB 만이 아니다. 그 DB 를 쓰는 서비스, 그 서비스를 쓰는 서비스까지 의존을 끝까지 따라가야 공지 대상과 확인 대상이 나온다. 직접 의존만 보고 공지하면, 두 단계 건너의 정산 리포트 팀이 아침에 빈 화면을 본다.

작업 창과 중단 판단 시각. 작업 창이 02:00~04:00 이고 되돌리기에 최악 50분, 여유 5분이 필요하다면 03:05 가 중단 판단 시각이다. 이 시각까지 작업이 확인까지 끝나지 않으면 되돌리기를 시작해야 창 안에 원래대로 돌아온다. 계획상 작업이 60분이면 03:00 에 끝나므로 창에 "맞는다". 그런데 60분이라는 숫자가 낙관적이라면?

되돌리기 기준은 잴 수 있어야 한다. "문제가 생기면 롤백" 은 기준이 아니다. "03:05 까지 S5 확인이 끝나지 않으면", "오류율이 1% 를 5분 넘게 넘으면" 처럼 시각·비율·건수로 적는다. 작업 단계마다 끝났다고 판단하는 확인 방법(verify)도 적는다. 확인 방법이 없는 단계는 끝났는지 모르는 단계다.

사전 점검과 공지. 작업을 시작하기 전에 되돌릴 근거가 살아 있는지(어젯밤 백업이 성공했는가, 스냅숏을 뜰 공간이 있는가), 작업 대상이 계획서의 전제와 같은지(버전·용량·경로)를 확인하는 목록이 사전 점검이다. 하나라도 어긋나면 작업을 시작하지 않는 것이 규칙이다. 영향 서비스 담당자에게는 시작·종료·되돌리기 결정을 누가 어떤 경로로 알리는지도 요청서에 적는다.

리허설. 개발계나 복제 환경에서 같은 절차를 실제로 돌리고 단계마다 시작·종료 시각을 남긴다. 계획과 실제를 비교하면 어느 단계가 낙관적이었는지 보인다. 리허설에서 중단 판단 시각을 넘겼다면, 본 작업에서도 넘길 가능성이 높다 — 창을 늘리거나, 작업을 나누거나, 느린 단계를 줄일 방법을 먼저 찾는다.

현장에서 만나는 모습

한국 SI·운영 현장에서는 이 문서들이 "작업 계획서", "작업 결과서", "변경 요청(CR)" 이라는 이름으로 오간다. 양식은 회사마다 다르지만, 검토자가 반려하는 이유는 거의 같다 — 롤백 절차가 "원복" 한 단어뿐이다, 영향 서비스 목록이 직접 의존만 있다, 작업 시간 합이 창을 꽉 채운다, 사전 점검에 백업 확인이 없다.

작업이 끝난 뒤에는 결과서가 남는다. 계획한 단계마다 실제 시작·종료 시각, 확인 결과, 계획과 달랐던 점을 적고, 되돌렸다면 그 판단 시각과 근거를 적는다. 다음 같은 작업의 계획서는 이 결과서의 실측 시간에서 출발한다. 결과서 없이 매번 새로 추정하면 같은 단계가 매번 같은 만큼 늦는다.

가장 비싼 실수는 되돌리기 시간을 계산하지 않는 것이다. 작업 60분에 창 120분이면 넉넉해 보이지만, 되돌리기가 50분 걸리면 여유는 5분뿐이다. 리허설 기록이 있으면 이 여유가 실제로는 음수라는 것을 작업 전에 안다.

다음 실습에서 할 것

세 변경 요청의 유형을 가르고, 서비스 의존 목록에서 DB 재시작의 영향 범위를 끝까지 따라간다. 작업 계획표와 창에서 작업·되돌리기 시간과 중단 판단 시각을 계산하고, 그것으로 JSON 변경 요청서를 쓴다 — 머리(유형·창·영향·사전 점검)와 몸(단계별 확인 방법·잴 수 있는 되돌리기 기준). 마지막으로 리허설 기록에서 가장 늦은 단계를 찾고 중단 시각을 넘겼는지 판정한다.