(18편) 이행 산출물2: 컷오버(Cut-Over) CHECKLIST 작성법 알아보기

카테고리 없음

by 늦둥이아빠 2024. 4. 22. 09:27

프로젝트에서 컷 오버(Cut-Over)는 기존에 운영하던 구 시스템을 완전히 중단 시키고 신규 구축한 시스템으로 새로 서비스를 오픈 하는 것을 말하는 것으로 기존 시스템을 신규 시스템으로 완전하게 바꾸는 작업 입니다. 오늘은 Cut-Over Checklist 작성에 대한 구체적 내용과 절차에 대해 알아보도록 하겠습니다.

(18편) 이행 산출물2: 컷오버(Cut-Over) CHECKLIST 작성법 알아보기

직접 전환 전략(Direct CutOver Strategy)

Cut-Over란 직접 전환 전략(Direct CutOver Strategy)이라는 말로 한 순간에 기존 시스템을 새로운 시스템으로 완전히 바꾸는 전략이며, 프로젝트에서 Cut-Over의 의미는 프로젝트 수행 중에 개발환경에서 실제 운영환경으로 전환하는 단계입니다. 또한 실제 운영환경으로 전환하므로 체크리스트를 통해 운영환경 인프라가 들어오는 경우 점검을 하고 이관작업을 한 후 이관한 프로그램에 대하여 점검을 하는 작업을 의미합니다. 또한, 컷 오버는 신규 시스템을 실제 사용자에게 오픈 하는 Go-Live 의사 결정과 함께 진행됩니다.

Cut-Over 시 백업 대책이나 롤백 전략이 없다면, 엄청난 혼란과 함께 매우 위험한 접근이며, 새로운 시스템에 심각한 문제가 발견된다면 엄청난 비용이 발생하게 됩니다.

Cut-Over 절차

Cut-Over 절차는 크게 전환준비, 전환, 검증, 오픈의 단계를 거칩니다. 전환준비단계의 세부공정으로는 사전준비, 공지, 모듈배포 및 설치, 모듈확인, 진행중 문서 확인 등의 작업을 진행하며, 전환 단계에서는 메인 서비스 중지를 시작으로, 메인 서비스를 전환하고, 데이터를 이관하며, 3rd Party 제품 설치 및 모듈을 확인합니다. 검증 단계에서는 다시 메인 서비스를 기동하고 서비스를 확인하고, 데이터를 이관하며, 3rd Party 모듈을 확인하고, 마지막으로 사용자 테스트를 실시합니다. 최종 오픈 단계에서는 최종 확인 후 오픈하고 3rd Party 제품 모듈을 점검하고, 시스템 모니터링을 실시합니다.

전환준비단계에서는 체크 포인트로는 신규 도메인과 방화벽을 확인하고, 기존 서비스 중단을 공지할 수 있는 팝업 창을 만들어 놓는 것입니다. 그리고 가장 중요한 부분은 진행중인 결재 문서를 완료하는 것입니다. 전환단계의 체크 포인트는 기존 서비스를 중지하고 신규 서비스를 기동합니다. 그리고, 사용할 DB 및 파일 데이터를 증분이관합니다. 그리고, 3rd Party 제품에서 해야 할 연계작업이나 색인 작업등을 수행합니다. 검증단계의 체크 포인트는 설치 시스템을 기동하고, 연계, 색인, 이관 등을 검증합니다. 오픈 단계의 체크포인트는 사용자 최종 확인을 거친 후 시스템 모니터링을 실시합니다.

위의 절차는 일반적으로 엑셀로 작업내용 및 시작일자, 시작시간, 종료일자, 종료시간, 소요시간, 세부작업내용, 대상시스템, 협조자, 확인자, 완료여부, 비고 등을 시간 단위로 세세하게 작성합니다.

롤백(Rollback) 정책 수립

롤백이란 작업 중 문제가 발생했을 때, 트랜잭션의 처리 과정에서 발생한 변경 사항을 취소하고, 트랜잭션 과정을 종료하는 것을 말하며, 트랜잭셔느로 인한 하나의 묶음 처리가 시작되기 이전의 상태로 되돌리는 작업을 의미합니다. 트랜잭션의 Insert, Update, Delete 작업을 취소하며, 이전 Commit 한 곳까지만 복구합니다.

롤백에 대한 의사결정은 신규 시스템 최종 점검 평가 후 복구결정을 하며, 고객 의사결정권자가 결정을 하게 됩니다. 복구 결정이 나면 기존 서비스를 재기동하고 기존 시스템에 대한 사용자 테스트를 실시한 다음 기존 시스템을 오픈하고, 신규 시스템 오픈 연기에 대한 안내문을 공지합니다.

마치며

오늘은 이행 단계 산출물 중 오픈 전 Cut-Over Checklist를 작성법에 대해 알아보왔습니다.

프로젝트를 하면서 가장 힘든 시작 시점이 이 부분이 아닐까 생각합니다. 시스템 오픈을 목표로 달려온 프로젝트 종료 시점에 다시 롤백이 된다면 프로젝트 연기는 불가피하며, PM으로서 압박은 상당합니다. 고객이나 본사로부터 양쪽 모두에게 시달리며, 하루하루 그 원인에 대한 해결책을 찾고, 다시 오픈 일정을 잡고 다시 전환을 준비해야 하기 때문입니다.

성공적인 시스템 오픈을 위해서는 어떤 운이 작용하는 것이 아니라 그동안 진행했던 분석, 설계, 구축, 통합테스트까지 쉬지 않고, 꼼꼼하게 체크하고 점검하고 진행된 여러 단계의 과정의 결과입니다. 따라서, 각 과정별 리스크가 있었다면 그 부분을 오픈 전에 해결하는 노력이 필요합니다. 이런 노력이 없다면 설사 오픈이 되었다고 하더라도 오픈 후 안정화과정은 정말 지옥 같은 하루하루를 보낼 수 밖에 없습니다. 모듈 설치에 대한 안내 부족이나 가이드, 매뉴얼의 부재, 그리고 기능 오류, 프로세스 오류, 시스템 연계의 문제, 결재 처리 문제, 데이터 권한 문제, 메뉴 접근 권한 문제, 패치의 문제 등 다양한 이슈가 발생할 수 있습니다.

위의 사항들은 프로젝트 시에는 대부분 개발과 테스트에 집중하기에 오픈 후에 나타나기 때문에 놓치기 쉬운 부분입니다. 오픈 전에 다시한번 체크해서 성공적인 프로젝트가 되었으면 합니다.

이러한 이유들로 인해 적절한 성능 측정은 프로젝트의 성공을 위해 필수적입니다.

프로젝트에 대해 다른 사항이 궁금하시면 아래 링크를 클릭하세요

(1편) 프로젝트: 기술협상서 작성하기
(2편) 프로젝트: 사업수행계획서, WBS 작성하기