클라우드 이전 리허설·컷오버 실행표

클라우드 이전 계획의 첫 줄은 서버 이름보다 업무와 변경 경로가 먼저입니다. B2B 문서 승인·협업 서비스에서는 문서 API와 버전 DB, 승인 이력, 첨부 파일과 작업 권한이 함께 움직입니다. 승인된 버전과 사용자가 읽는 버전이 다르면 같은 문서 이름이라도 업무 결과가 달라집니다. 승인 알림 웹훅이 어느 사건을 전달하는지까지 확인한 뒤 함께 옮길 구성 요소를 정합니다.

이전 묶음에는 대상 버전, 기존 정본, 신규 정본, 전환 전후의 쓰기 주체, 확인 담당을 적습니다. ‘DB를 복사한다’는 문장에는 복사 이후의 변경분과 콜백이 어디에 남는지가 빠져 있습니다. 복사 완료 시점부터 트래픽 전환까지 생긴 기록을 어떻게 반영할지 별도 작업으로 둡니다. 기존 환경을 읽기 전용으로 바꿀 때 외부 요청을 보관하거나 다시 받을 수 있는지도 확인합니다.

작성 예시는 가상 팀 협업 서비스입니다. 작성자는 문서를 제출하고 지정 승인자는 대상 버전을 검토해 승인합니다. 예제 정책에서는 작성자의 자기 승인을 허용하지 않습니다. 문서·승인 정보의 정본은 전환 전 기존 DB, 전환 후 신규 DB로 두며 알림 웹훅의 발송 권한도 한 환경에만 둡니다. 이 예제의 시간·건수·결과는 작성용이며 운영 실행 상태는 미실행입니다. 이후의 권한과 운영 담당 확인은 클라우드 착수·운영 인수 점검표와 연결합니다.

리허설에는 시험 대상, 데이터 범위, 외부 처리 차단, 시작 상태와 기대 결과가 필요합니다. 시험 환경의 복사 속도만으로 운영 소요 시간을 확정할 수 없습니다. 문서 버전 수, 승인 변경량, 첨부 크기, 네트워크와 권한이 실제 운영과 어떻게 다른지 기록해야 합니다. 알림 웹훅을 시험 수신함으로 보낸 리허설에서는 운영 수신자의 전달 확인을 별도 항목으로 남깁니다.

가상 리허설 기록의 최종 동기화는 21:02부터 21:08까지입니다. 문서 40건과 마지막 승인 사건 AP-040을 대조합니다. 21:10까지 첨부 파일 12개의 해시와 역할별 접근을 확인합니다. 21:12까지 시험 문서 DOC-T01의 v3가 지정 승인자에게 보이고, 지정자의 승인은 반영되지만 작성자의 승인 시도는 거부되는지 확인합니다. 21:13에는 기존 알림 웹훅 작업의 중지와 신규 작업자의 실행 준비를 확인한 것으로 기록합니다. 합계 11분은 가상 기록의 값이며 실제 시간 칸에는 수행자의 실측을 적습니다.

결과 상태는 미실행·통과·실패·차단으로 구분합니다. 기대 결과를 적었다고 통과가 되지는 않습니다. 실제 리허설에서는 실행 시각과 로그 위치, 확인한 데이터 범위, 확인자와 미결 항목을 남깁니다. 재시험할 때는 앞선 결과를 지우지 않고 변경한 조건과 결과를 연결합니다. 운영에서만 확인할 수 있는 항목은 누구의 승인으로 어느 단계에서 확인할지도 정합니다.

컷오버는 실제 요청과 쓰기 정본을 새 환경으로 넘기는 작업입니다. 준비 상태를 확인한 뒤 입력·배치·콜백의 쓰기를 통제하고 최종 동기화와 대조를 수행합니다. 이후 승인된 방식으로 트래픽을 전환하고 핵심 업무를 확인한 뒤 신규 쓰기를 엽니다. 구체적인 순서는 서비스의 데이터 구조와 전환 방식에 맞춰 정합니다. 단계별 작업자와 확인자가 같은 정보를 볼 수 있도록 결과 위치를 작업표에 연결합니다.

전환 보류의 작성 예시에서 문서 DOC-018의 v3는 기존 환경에서 승인됐지만 신규 환경에서는 승인 대기로 보입니다. 기존 승인 사건 AP-041이 신규에는 없고 AP-040까지만 반영됐습니다. 문서 40건과 첨부 12개의 해시가 일치해도 승인 상태 대조는 실패입니다. 신규 업무 쓰기를 열지 않고 승인 이력을 재동기화합니다. 버전·승인 상태와 함께 지정자 허용·작성자 거부의 권한 결과를 확인한 뒤 다시 판단합니다.

AWS의 전환 전 준비 지침은 작업 순서·담당·시간과 검증·복귀 계획을 미리 정하도록 설명합니다. 실행표의 항목은 그 원칙을 적용할 서비스의 실제 증거로 채웁니다. 특정 공급자의 템플릿이나 운영 명령을 그대로 실행하는 대신, 승인된 환경에서 확인할 대상과 완료 조건을 확정합니다.

신규 환경에서 업무 기록이 생기기 전과 후의 복귀는 다릅니다. 새 문서 버전이나 승인 기록, 외부 알림 웹훅이 발생했다면 기존 환경으로 요청만 돌려도 그 상태는 따라가지 않습니다. 승인한 대상 버전과 승인자의 권한, 역반영 가능성을 먼저 확인합니다. 이미 전달한 알림이 있다면 같은 승인 사건이 다시 전달될 때 수신 측이 중복 반영하지 않는지도 확인합니다. 데이터와 외부 상태를 모르는 채 자동 복귀를 실행할 조건으로 삼지 않습니다.

복귀 판단 시한의 작성 예시에서는 작업 창이 21:30에 끝납니다. 기존 환경 복귀에 8분, 복귀 후 업무 확인에 5분을 확보하면 마지막 판단 시각은 21:17입니다. 이 시각에 필수 검증이 미완료라면 원래 계획의 계속 진행을 승인하지 않습니다. 남은 시간, 기존 환경의 준비 상태, 신규 쓰기 여부를 확인해 합의한 복귀 또는 비상 절차를 선택합니다. ‘13분이 남았다’는 계산만으로 데이터 복귀가 가능하다고 판단하지 않습니다.

AWS의 컷오버·롤백 지침도 전환 뒤 새 데이터가 발생한 상황을 구분합니다. IXC의 롤백 가능한 배포 해설은 코드·설정·데이터·외부 계약의 호환성을 함께 살펴봅니다. 판단 기록에는 시각, 관측한 값, 선택한 행동, 실행 담당, 승인자와 후속 대사 조건을 남깁니다.

새 환경의 첫 화면이 열린 뒤에도 사용자 업무를 확인해야 합니다. 문서 버전과 승인 상태가 일치하는지, 허가된 역할만 첨부를 열고 승인할 수 있는지 확인합니다. 승인 알림의 사건 ID와 대상 문서·버전도 대조합니다. 시험 수신함에서 같은 사건을 한 번 반영한 결과와 실제 운영 수신자의 전달 확인은 구분합니다. 필요한 업무 검증이 끝나기 전에는 해당 흐름의 운영 완료로 표시하지 않습니다.

종료 기록의 작성 예시에서는 문서 v3와 승인 이력, 첨부 권한, 알림 작업자의 단독 실행을 확인합니다. 시험 수신함의 중복 제거 결과를 남기고 운영 수신자 확인 담당과 다음 시점을 미결 목록에 둡니다. 업무 재개 승인자는 그 영향과 임시 대응을 검토합니다. 미확인 항목이 있어도 무조건 재개한다는 뜻이 아니며, 승인 상태나 접근권한이 어긋나 핵심 업무를 충족하지 못하면 재개를 보류합니다.

기존 환경 종료에는 데이터·로그 보존, 복귀 필요 기간, 남은 대사와 계약 종료 조건이 따릅니다. 새 환경을 운영하기 시작한 사실만으로 기존 자원을 삭제하지 않습니다. 보존 대상과 청구 담당, 회수할 권한, 종료할 작업자와 계정의 목록을 작성합니다. 클라우드 운영 대행으로 이어 맡길 범위와 내부 팀이 계속 맡을 일을 이 기록에서 정합니다.

이전 제안을 비교할 때는 시스템 수와 목표 날짜 외에 조사·설계·동기화·리허설·전환·검증·안정화의 수행 범위를 맞춥니다. 현업은 중단 가능한 시간과 업무 기대 결과를, 기술 담당은 의존 관계와 데이터 접근 조건을 제공할 수 있습니다. 외부 수행사에는 각 단계에서 무엇을 실행하고 어떤 기록을 남길지 요청합니다. 같은 ‘이전 완료’라는 표현도 업무 검증과 기존 환경 정리가 포함되는지에 따라 일이 달라집니다.

IXC의 클라우드 마이그레이션은 의존성 평가와 전환 순서, 리허설·컷오버·안정화를 다룹니다. 출시 전 QA 검수와 연결하면 핵심 업무·권한·예외 경로의 검증 범위를 함께 정할 수 있습니다. 실행표의 미정 항목을 기준으로 내부 조직과 IXC가 맡을 일을 협의합니다. 실제 운영 권한이나 데이터는 합의한 접근 방식으로 다루며 공유용 작성표에는 비밀 값을 적지 않습니다.

완료 판단에 필요한 자료는 이전 묶음과 데이터 정본, 단계별 결과, 진행·보류·복귀 결정, 남은 운영 과제입니다. 가상 작성 예시는 각 기록의 연결 방식을 설명합니다. 실제 실행 결과에는 수행 날짜와 대상 환경, 승인과 증거가 필요합니다. 기존 운영 인수표와 연결할 때는 같은 업무·환경 식별자를 사용해 이전 중 남은 항목이 인수 단계에서 사라지지 않게 합니다.