SAP 컷오버, 오래된 주방에서 새 주방으로 이사하는 날
SAP 컷오버(Cut-over)가 무엇인지, 왜 프로젝트에서 가장 긴장되는 순간인지, 그리고 성공적인 컷오버를 위해 무엇을 준비해야 하는지를 레스토랑 이전 개업 비유로 설명합니다.
안녕하세요, Rabbit입니다! 🐰
오랫동안 운영해온 동네 맛집이 드디어 새 건물로 이전합니다. 수개월 공사 끝에 완성된 새 주방은 최신 설비로 가득합니다. 이제 남은 것은 단 하나, 이 문을 열고 손님을 맞이하는 것입니다.
그런데 이게 단순하지 않습니다. 기존 재료들을 새 냉장고로 옮겨야 하고, 직원들은 새 동선에 적응해야 하며, 기존 단골 손님들에게 새 위치를 알려야 합니다. 이전하는 그날 하루, 모든 것이 동시에 맞아 떨어져야 합니다.
SAP 프로젝트의 컷오버(Cut-over)가 바로 이 순간입니다.
- 컷오버는 기존 레거시 시스템을 끄고 SAP를 실제 업무에 켜는 전환 과정 전체를 말합니다.
- 이 기간 동안 데이터 이전, 설정 최종 점검, 사용자 권한 부여가 동시에 진행됩니다.
- 실패 시 비즈니스가 멈추기 때문에, 철저한 리허설과 롤백 계획이 필수입니다.
컷오버란 무엇인가
컷오버(Cut-over)는 기존에 쓰던 레거시 시스템의 운영을 중단하고, 새로운 SAP 시스템으로 업무를 넘기는 전환 과정 전체를 뜻합니다.
레스토랑 이전으로 풀면 이렇습니다. 특정 날을 이전일로 잡고, 그날 기존 건물의 문을 닫습니다. 새 건물 공사가 완료됐다면 기존 재료와 집기를 옮기고, 신메뉴판을 준비하고, 직원 배치도 새로 짭니다. 그리고 다음 날 아침, 새 건물에서 손님을 받기 시작합니다.
SAP 컷오버도 이와 같습니다. D-day를 정하고, 기존 시스템 사용을 멈추는 다운타임(System Downtime)을 가집니다. 이 시간 동안 데이터를 이전하고, 설정을 최종 확인하고, 사용자 계정을 열어줍니다. 그리고 새벽이 지나면 SAP에서 첫 번째 업무 트랜잭션이 시작됩니다.
대부분의 프로젝트는 기존 시스템을 완전히 끄고 SAP로 100% 전환하는 빅뱅(Big Bang) 방식을 씁니다. 두 시스템을 동시에 운영하는 부담이 크기 때문입니다.
컷오버 기간에 일어나는 일들
다운타임이 시작되면 세 가지 작업이 동시에 진행됩니다.
데이터 마이그레이션이 가장 핵심입니다. 기존 시스템에 쌓인 자재 마스터, 거래처 정보, 재고 수량, 미결 오더를 SAP로 옮깁니다. 레스토랑으로 치면 냉장고의 재료들을 새 냉장고로 옮기면서 유통기한 지난 것은 버리고, 새 레이블을 붙이는 과정입니다.
설정 최종 점검도 진행됩니다. 지금까지 테스트 환경에서 검증했던 모든 설정이 운영 환경에도 제대로 올라가 있는지 확인합니다. 조직 구조, 결재 라인, 가격 조건, 세금 코드 같은 것들이죠.
사용자 계정 활성화와 권한 부여도 이 시점에 이루어집니다. 구매팀 담당자는 구매 관련 화면만, 생산팀 담당자는 PP 관련 화면만 접근할 수 있도록 권한이 설정됩니다.
이 모든 작업이 다운타임 안에 완료돼야 합니다. 시간이 초과되면 비즈니스 중단이 길어집니다.
그림 1. 컷오버 진행 타임라인과 주요 체크포인트
성공적인 컷오버를 위한 세 가지 준비
첫째, 데이터 정제(Data Cleansing)입니다.
기존 시스템에는 오래된 데이터가 쌓여있습니다. 중복된 거래처 코드, 오래전 단종된 자재, 실제와 다른 재고 수량. 이것들을 그대로 SAP로 가져가면 첫날부터 숫자가 맞지 않는 문제가 생깁니다.
컷오버 전에 데이터를 정리하고 검증하는 작업이 반드시 필요합니다. “Garbage In, Garbage Out”이라는 말이 있습니다. 새 시스템에 들어가는 데이터의 품질이 시스템의 품질을 결정합니다.
둘째, 모의 컷오버(Mock Cut-over) 리허설입니다.
실제 컷오버와 동일한 데이터, 동일한 시간 계획, 동일한 담당자들이 참여하는 리허설을 최소 한 번 이상 해야 합니다.
리허설을 통해 각 작업에 실제로 얼마나 걸리는지 측정합니다. 예상보다 오래 걸리는 작업이 반드시 나옵니다. 데이터 이전 스크립트에 버그가 있을 수도 있고, 담당자 간 인계 구간에서 대기가 생길 수도 있습니다. 이 문제들을 실전 전에 발견하고 수정하는 것이 리허설의 목적입니다.
셋째, 런북(Runbook)과 롤백 계획입니다.
런북은 컷오버 기간 동안 누가, 언제, 무엇을, 어떻게 해야 하는지를 분 단위로 정의한 실행 계획서입니다. 각 작업의 담당자, 시작 시간, 완료 확인 기준, 다음 작업 시작 조건이 모두 담깁니다.
💡 핵심: 런북에는 반드시 비상 대응 계획(Contingency)이 포함돼야 합니다. “X시까지 데이터 이전이 완료되지 않으면 어떻게 하는가?” 같은 시나리오별 대응을 미리 정해두지 않으면, 실제 문제가 생겼을 때 혼란이 커집니다.
롤백 계획은 최후의 보루입니다. 컷오버 도중 해결 불가능한 심각한 문제가 생겼을 때, 모든 것을 원래대로 되돌리는 절차입니다. 롤백 결정 시점, 책임자, 절차가 사전에 명확히 정해져 있어야 합니다.
컷오버 당일, 현장 분위기
경험해본 사람이라면 알겠지만, 컷오버 당일은 독특한 분위기가 있습니다. 수개월의 프로젝트가 이 한 번의 전환으로 결론이 납니다.
늦은 밤에 팀원들이 모여 데이터 이전 진행 상황을 체크합니다. 각 작업의 완료 여부를 런북에 체크하면서 다음 담당자에게 인계합니다. 새벽 두세 시에 첫 번째 생산오더가 SAP에서 발행되는 순간, 모니터를 보던 사람들이 긴장을 풉니다.
⚠️ 주의: 컷오버 후 초기 안정화 기간에는 예상치 못한 오류가 반드시 생깁니다. 테스트에서 통과했던 케이스도 실제 데이터가 붙으면 다르게 동작하는 경우가 있습니다. Go-Live 직후 몇 주간은 핵심 담당자들이 현장을 밀착 지원하는 하이퍼케어(Hypercare) 체계가 필요합니다.
하이퍼케어 기간에는 SAP 컨설턴트와 현업 파워유저들이 현장에 상주하거나 즉시 대응할 수 있는 체계를 갖춥니다. 오류 접수 창구를 단일화하고, 긴급도에 따라 처리 우선순위를 정하는 것도 중요합니다. 이 기간이 지나고 나서야 프로젝트가 진짜 마무리됩니다.
Rabbit의 한 끗
컷오버는 프로젝트의 끝이 아닙니다. 시작입니다.
수개월간 만든 것이 처음으로 실제 업무에 적용되는 날입니다. 성공 여부는 그날 하루 아무것도 터지지 않는 것이 아니라, 문제가 생겼을 때 빠르게 파악하고 대응할 수 있는가에 달려있습니다.
잘 만들어진 런북, 충분히 검증된 데이터, 리허설에서 쌓인 경험이 그 대응력을 만들어줍니다. 새 주방에서 첫 손님을 맞이하는 날이 떨리지 않으려면, 그 전날까지의 준비가 전부입니다. 😎
더 읽어보기