컷오버 계획 세우기 - 오픈 당일 Go No-Go 코드동결 롤백 병행 기준

오픈일과 컷오버 창은 어떻게 다를까?

오픈일은 달력의 날짜이고, 컷오버는 그 날짜 안의 시간 창입니다. 창의 시작, 되돌릴 수 있는 마지막 시각, 운영 인계 시각을 세 칸으로 나누지 않으면 마일스톤만 초록입니다.

WBS에 오픈이라고 한 줄만 있으면, 그 줄의 종료일은 대개 검수 주와 같습니다. 그런데 검수 사인은 합의 시나리오를 받았다는 기록이고, 그날 밤 구시스템을 멈추고 신시스템을 켜는 일은 다른 작업입니다.

창을 쪼개 보세요. 시작 시각, 되돌릴 수 있는 마지막 시각, 운영이 인수하는 시각.

세 칸이 비면 주간보고는 오픈일만 초록이고, 새벽에 연계 한 건이 막히면 그 초록은 전화 목록이 됩니다. 공개된 논의에서도 전환은 개발이 끝난 뒤의 작은 프로젝트가 아니라, 받는 쪽 운영이 일을 이어갈 수 있는 출구 조건을 따로 적으라고 말합니다.

시스템 자체는 준비됐는데 운영 환경이 안 된 상태로 날짜만 맞추는 일이 여기서 납니다. 날짜만 마일스톤으로 남겨 두고 창을 분 단위 순서로 적지 않으면, 오픈은 축하 문자가 되고 전환은 그 다음 주 장애 목록이 되죠.

Go No-Go 판정은 누가, 어떤 숫자로 내릴까?

창을 열기 전과 창 한가운데, 두 번 판정합니다. 결정권자 실명과 숫자 기준이 표에 있어야 하고, 검수 사인만으로 Go를 대신하면 No가 사라집니다.

창을 열기 전 판정은 전제입니다. 백업 확인, 리허설에서 남은 치명 결함 건수, 당일 역할 출근, 롤백 절차 검토.

이 네 칸이 비면 Go는 분위기죠. 창 한가운데 판정은 더 짧아야 합니다.

오류율, 연계 응답, 핵심 화면 로그인처럼 미리 박아 둔 숫자만 보고 계속할지 되돌릴지를 고릅니다. 허용 오류가 애매하면 새벽 세 시에 회의가 다시 열리죠.

실패 건수 50, 또는 창의 절반이 지났는데 핵심 경로가 안 열린다처럼 문장에 숫자를 넣어야 누구든 같은 결정을 합니다. 검증(Validation)이 받은 것은 시나리오 합격이고, 소프트웨어사업 관리 지침이 말하는 인수는 시험과 검사로 계약 요구를 확인한 뒤의 종료 절차입니다.

그 사인을 컷오버 허가로 읽으면 No를 말할 사람이 없어지죠. 결정권자를 실명으로 한 칸에 두고, 그 사람이 창에 안 나오면 대체 한 명까지 적어 두세요.

이름이 비면 새벽에 가장 큰 목소리가 Go가 됩니다.

코드 동결을 안 열면 당일 밤이 왜 흔들릴까?

동결은 개발 종료가 아니라 관련 시스템에 손을 대지 않는 기간입니다. 예외는 긴급 변경 창구로만 넣고, 창 안의 패치는 컷오버 순서표를 밀어 버립니다.

오픈 전날까지 커밋이 들어오면, 리허설에서 맞춘 시계가 당일에 다시 틀어집니다. 동결 범위를 개발 저장소만으로 두면 운영 배치, 방화벽, 계정, 연계 기관 쪽이 당일 밤에 바뀌죠.

관련 시스템이라고 적을 목록을 착수 후반에 한 장으로 만듭니다. 애플리케이션, 배치, 계정, 네트워크, 외부 연계.

예외가 필요하면 변경관리 긴급 창구로만 넣습니다. 창 안에서 고친 한 줄이 연계 순서를 밀어 버리면, 그 한 줄의 저자는 현장에 없고 롤백 담당만 남죠.

동결 시작 시각을 컷오버 창보다 앞에 두는 이유입니다. 창과 동결이 같은 시각이면, 동결은 구호이고 실제로는 전날 밤 핫픽스가 주인입니다.

주간보고 첫 장에 동결 위반 건수를 한 줄로 남기면, 오픈 전 주에 손대는 일이 줄어들죠. 위반이 0인데 당일 새 패치가 있으면 그 보고는 동결을 안 본 숫자입니다.

롤백 문장만 있으면 왜 못 되돌릴까?

문제 있으면 되돌린다는 문장은 계획이 아닙니다. 트리거 숫자, 되돌리는 데 걸리는 시간, 데이터 기준점이 창보다 짧아야 실제로 돌아갑니다.

백업에서 복원한다는 한 줄은 담당이 없고 시계가 없습니다. 컷오버 표에는 세 숫자를 같이 둡니다.

무엇을 보면 되돌리는지, 되돌리는 데 몇 분이 걸리는지, 그 분이 남은 창보다 짧은지. 세 번째가 더 길면 이미 되돌릴 수 없는 지점을 지난 겁니다.

업무연속 논의에서 쓰는 회복 목표 시간도 같은 질문입니다. 활동을 언제까지 되살릴지, 데이터를 어느 시점까지 잃어도 되는지를 시간으로 박아 두지 않으면 롤백은 감정입니다.

Risk(위험) 목록에 전환 실패를 올려 두고도 트리거가 없으면, 그 줄은 예견만 있고 당일 조치가 없죠. 데이터 이관이 한쪽으로만 흐르는 구간은 되돌림 자체가 불가능한 시각이 있죠.

그 시각을 창 한가운데 판정과 같은 칸에 두지 않으면, 팀은 이미 지나간 길을 되돌리라고 밤새 싸웁니다. 리허설에서 롤백을 한 번이라도 시계에 맞춰 돌려 보세요.

연습하지 않은 되돌림은 당일에 문서 제목만 남습니다.

병행운영과 빅뱅은 어디서 갈라야 할까?

병행은 두 시스템을 같은 거래로 비교하는 기간입니다. 비교 항목과 구시스템 종료 조건이 없으면 병행은 구호이고, 빅뱅은 더 긴 동결과 더 짧은 되돌림 창이 필요합니다.

병행을 안전장치로만 부르면, 현업은 이틀을 이중 입력하고 비교표는 비어 있습니다. 무엇을 대조할지, 누가 매일 차이를 닫을지, 며칠 뒤 구시스템을 끌지를 세 칸으로 적습니다.

차이가 남아 있는데 기간만 늘리면 병행은 피로만 남기고 전환은 미뤄지죠. 빅뱅은 창 하나에 끊고 켜는 방식이라 동결이 길고 되돌림 마감이 더 앞입니다.

거래량이 밤에 멈추지 않는 업무, 외부 기관이 창을 안 열어 주는 연계는 빅뱅 한 방에 안 들어갑니다. 반대로 비교할 분모가 없고 이중 입력이 불가능한 화면은 병행을 붙여도 숫자가 안 나오죠.

방식을 구호로 고르지 말고, 비교가 되는 업무와 창이 고정된 업무를 표에서 가릅니다. 한 사업에 두 방식이 섞여도 됩니다.

정산처럼 숫자가 맞아야 하는 줄은 병행, 조회성 화면은 빅뱅. 섞는 대신 오픈 한 날짜에 전부를 넣으면, 가장 느린 연계가 전체 창의 주인이 됩니다.

리허설을 한 번만 돌리면 무엇이 남을까?

한 번의 리허설은 순서표의 시계 오류를 찾습니다. 빠진 사람, 실제 롤백, 운영 인수 칸은 두 번째에 드러나고, 개발 환경만 돌리면 당일 권한이 비어 있습니다.

전날 한 번 돌려 보고 오픈하는 현장이 많습니다. 그 한 번은 대개 개발이 자기 순서를 읽는 시간이죠.

방화벽 담당이 자리에 있는지, 기관 점검 창이 리허설 시간에 실제로 열리는지, 롤백을 시계에 맞춰 끝까지 갔는지는 두 번째에야 드러납니다. 운영이 인수하는 칸을 리허설에 넣지 않으면, 오픈 다음 날 안정화 계획이 시작되는데 이벤트 연락망이 개발 채팅에만 있습니다.

환경을 운영과 같게 맞추지 않은 리허설은 순서표 읽기입니다. 계정, 인증서, 배치 창, 로그 위치가 당일과 다르면 찾은 결함은 개발의 결함이고 당일의 결함은 따로 오죠.

리허설 결과 한 장을 창 전 판정 자료로 붙입니다. 치명 미조치, 시계 오차, 빠진 역할.

세 칸이 비어 있는데 Go를 받으면, 그 Go는 날짜를 지킨 결정이지 전환을 허가한 결정이 아닙니다. 횟수를 자랑하지 말고, 당일 창과 같은 순서로 같은 사람이 같은 트리거를 한 번 이상 닫아 본 기록을 남기면 됩니다.