SAP Cutover & Go-Live — 마지막 24시간의 시퀀스

시즌 1의 1~7편이 결정과 설계에 관한 이야기였다면, 8편은 그 결정이 시간 위에서 작동하는 순간에 관한 이야기다. PCE Cutover & Go-Live는 흔히 D-Day 24시간으로 압축되어 이야기되지만, 실제 작업은 D-3에서 D+1까지의 5일 위에서 분 단위로 굴러간다. 한 그룹사 PCE 전환 사례에서, 마지막 5일이 어떻게 시간 단위로 조각나서 진행됐는지 본다.

D-3 ~ D-1 — 사전 작업: 환경 조건을 운영에 일치시키기

오픈 직전 3일은 운영 환경의 조건을 마지막으로 맞추는 시간이다.

D-Day에 시스템을 옮기는 일은 그 자체로는 짧다. 길고 위험한 것은 옮길 수 있는 상태를 만드는 사전 작업이다. 본 프로젝트의 오픈 시나리오에서 D-3(12.29)에 Migration CTS 반영과 DataSource 활성 프로그램 실행이 잡혀 있다. CTS(Change and Transport System)는 SAP 객체 이관의 표준 채널이고, Request List에 잡힌 객체들이 순서대로 운영 시스템에 반영된다. 7편의 Fiori Role·Tile 설정도 이 시점에 마지막 점검이 이뤄진다 — DW Fiori 초기 Setting 가이드와 Fiori Role Tile Check List가 별도 산출물로 잡혀 있는 이유다.

D-2(12.30)는 SAP 표준 Setting 점검의 날이다 — LO Cockpit Setting 점검, CO-PA Setting 점검, DataSource 활성화 점검. 이 점검은 코드 검증이 아니라 Configuration 상태 검증이다. 6편의 일탈 사례에서 본 것처럼, 환경 조건이 운영과 다르면 코드는 통과해도 시스템은 깨진다. 이 3일 동안의 점검은 D-Day 작업의 입력값을 보장하는 일이다 — D-Day가 잘 굴러갈지의 90%는 D-3에서 결정된다.

D-Day — 24시간의 시퀀스: BWP 백업 → 소스시스템 변경 → 데이터 추출

D-Day는 분 단위로 잡힌 일정표 위에서 작동한다.

본 프로젝트의 오픈 시나리오는 D-Day(26.1.1)의 작업을 시간 단위로 정렬한다. 08:30 ERP 데이터 최종 추출 모니터링, 08:30~09:00 BWP 백업, 09:10~10:00 DEPCLNT100 수정, 09:15~10:00 SDIEABA100 수정 — 5편에서 본 Logical Name 변경 7개가 분 단위로 시퀀스 위에 올라온다. BWP 백업은 되돌아갈 수 있는 마지막 지점이다 — 무엇이 잘못되어도 이 백업으로 회복 가능하다는 보장이 D-Day 작업의 모든 결정을 가볍게 만든다.

이 시퀀스의 핵심은 순서다. 소스시스템 변경 전에 ERP 데이터를 다 추출해야 하고, BWP 백업 후에 변경을 시작해야 하고, 변경이 끝나야 새 환경에서 데이터 적재가 가능하다. 한 단계라도 순서가 어긋나면 되돌릴 수 없는 상태에 빠진다. 이 24시간 안에 BW·BC·각 모듈 컨설턴트가 같은 시계로 움직이지 않으면 시퀀스 자체가 무너진다. 오픈 시나리오의 담당파트 컬럼이 BW·BC·운영담당자·컨설턴트로 명확히 분리된 이유 — 누가 어떤 시간에 무엇을 책임지는가가 표 위에 박혀 있어야 24시간이 굴러간다.

D+1 이후 — Hyper Care 진입: 조용한 시작이 정답

오픈 직후의 안전은 적게 움직이는 것에서 온다.

D-Day가 끝나고 시스템이 운영에 진입하면 다음 단계는 Hyper Care다 — 집중 모니터링 기간이다. 이 기간의 핵심 원칙은 단순하다 — 변경을 최소화하고 모니터링을 최대화. SXI_MONITOR(인터페이스 모니터링), MB51(재고 이동 이력), 프로세스체인 실행 결과 등 로그 기반 검증이 매일 반복된다. 새로운 기능 배포는 일단 멈춘다.

이 단계가 중요한 이유는 6편에서 본 일탈 사례에서 분명해진다 — D+5(2026.1.6)에 발생한 품질재고 일괄 합격 일탈은 D-Day 작업이 아니라 운영 데이터의 흐름에서 드러났다. 즉 Cutover의 결과는 D+1에 끝나는 게 아니라 D+30까지 누적된다. Hyper Care는 D-Day의 연장이지 별개의 단계가 아니다. 본 프로젝트의 Closing Support 폴더가 1.5에 따로 잡혀 있는 것은 우연이 아니다 — Cutover의 작업과 Hyper Care의 작업은 같은 시퀀스의 후반부다. 9편에서 이 후반부 30일을 따로 다룬다.

시점주요 작업산출물 / 입력
D-3 (12.29)Migration CTS 반영CTS Request List, Role 정의서
D-2 (12.30)DataSource 활성화, LO/CO-PA Setting 점검DataSource 현황, Setting 가이드
D-1 (12.31)프로세스체인(일·월) 모니터링·실행, 프로세스체인 중지BW 분과 WBS
D-Day (26.1.1)BWP 백업, 소스시스템 변경(7개 Logical Name), ERP 데이터 추출, Delta 동기화오픈 시나리오 시간표
D+1 ~ D+30Hyper Care 모니터링, 이슈 대응Closing Support 절차

한 줄로

Cutover의 본질은 결정의 결과를 시간 위에 올리는 일이다. D-3까지 환경 조건을 운영에 일치시키고, D-Day는 분 단위 시퀀스로 작동시키고, D+1부터는 적게 움직이며 모니터링한다. 이 5일이 무너지지 않게 만드는 진짜 자산은 시간표가 아니라, 1~7편에서 합의해둔 결정과 설계다. 결정이 잘 잡혀 있으면 24시간은 지루할 정도로 조용하게 지나간다. 9편에서 그 다음 30일을 다룬다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

S/4HANA Cloud CBO 개발 3단계 — 어디까지 위에서 끝내는가

이미지
1·2·3편을 거쳐 As-is 산출물의 결정 트리거가 작동했다고 치자. CBO List는 BTP / 표준 흡수 / 폐기 로 분류되었고, RZ010은 표준 회귀 / 변형 / 위성 으로 점수가 매겨졌다. 그 다음 질문 — 변형으로 가야 할 항목을 어떻게 개발하는가. PCE는 On-Prem이 아니다. 자유롭게 ABAP을 수정하던 시절의 도구는 일부만 남았다. 한 그룹사 PCE 전환 사례에서, CBO 개발 결정이 어떻게 3단계 위계로 정리됐는지 본다. Key User Extension으로 끝내도 되는 경우 가장 안전한 출발점은 가장 가벼운 도구다. PCE에서 새로 추가하거나 변형해야 할 항목을 받으면, 첫 번째 질문은 항상 같다 — 이걸 Key User Extension으로 풀 수 있는가 . Key User Extension은 비개발자(현업 키 유저)가 UI 도구로 필드를 추가하고, 양식을 바꾸고, 작은 룰을 거는 SAP 공식 확장 방식이다. 화면 하나에 필드 두 개 추가, 송장 양식 마스킹 변경, 사용자 정의 데이터 캡처 — 이런 작은 변형 의 대부분은 여기서 끝나야 한다. 이걸 건너뛰는 것 이 흔한 함정이다. 구관(舊官) ABAP 개발자가 보면 Key User Extension은 권한이 부족한 도구 처럼 보인다. 그래서 일단 Embedded Steampunk나 BTP로 직행한다. 결과는 작은 일에 큰 도구 를 쓴 것 — 변경관리도 무거워지고, 운영도 무거워진다. Key User로 끝낼 수 있는 일을 Embedded로 가져가면, SAP 표준 업그레이드마다 회귀 테스트 부담이 따라온다. PCE의 Clean Core 원칙은 여기서 시작된다. Embedded Steampunk가 필요한 경우 표준 동작을 비틀어야 할 때, 같은 시스템 안에서 푸는 옵션. Embedded Steampunk(in-app extensibility)는 PCE 안에서 ABAP for Cloud로 직접 코드를 작성하는 방식이다. 기존 ABAP 개발자가 가장 적응하기 쉬운 영역 — ...
자세한 내용 보기

S/4HANA Cloud PCE 전환 시작 단계, 가장 먼저 바뀌는 3가지

이미지
ERP 클라우드 전환 의사결정이 끝나면, IT 담당자와 PM은 곧장 "이제 뭘 먼저 바꿔야 하나"라는 질문에 부딪힌다. 흔한 오해는 코어 시스템(SAP 자체)만 갈아끼우면 된다는 가정이다. 실제로 일을 시작해보면 가장 먼저 흔들리는 건 코어가 아니라 코어 주변 이다. On-Prem SAP에서 S/4HANA Cloud PCE로 가는 한 그룹사 마이그레이션 프로젝트의 시작 단계에서, 가장 먼저 바뀐 세 가지를 정리한다. 시스템 토폴로지(시스템 간 연결 구조)가 먼저 바뀐다 코어가 바뀌는 게 아니라 코어 주변이 먼저 흔들린다. On-Prem 시절 BW(Business Warehouse)는 단순했다. SAP ERP 한 곳에서 데이터를 받아 모델링하고 리포트로 풀어내면 됐다. 소스시스템은 사실상 하나, 네트워크 경로는 사내, 권한 모델은 통합. S/4HANA Cloud PCE로 옮겨가면 이 전제가 흔들린다. BW가 PCE 환경의 데이터를 어떻게 끌어올지, 기존 On-Prem BW를 그대로 둘지 함께 옮길지, 인터페이스 계정 권한을 어떻게 재설계할지 — 이 문제들이 코어 전환 전에 결판나야 한다. 이 그룹사 프로젝트에서도 BW 분과의 초기 산출물은 "소스시스템 변경(안)" 문서였다. 실제 코어 전환보다 한 단계 앞서, 데이터가 어디서 어디로 흐르는가 의 지도를 다시 그리는 일이 시작된 셈이다. WMS와 외부 결재 시스템 같은 주변 인터페이스도 같은 줄 위에 올라온다. PCE는 사내가 아니라 SAP 데이터센터에 있기 때문에, 네트워크·권한·연결 모델 자체가 새 변수가 된다. Configuration의 자유도가 줄어든다 PCE는 클라우드 옷을 입은 On-Prem이 아니다. On-Prem SAP에서는 클라이언트가 Configuration을 비교적 자유롭게 잡았다. RZ010(설정값 리스트)을 뽑아보면, 회사마다 수년간 누적된 커스텀 설정이 수백 줄씩 나오는 게 보통이다. PCE에서는 이 자유도가 좁혀진다. SAP S...
자세한 내용 보기

SAP QM 검사로트 일괄합격 일탈 — CSV가 놓친 한 가지

이미지
  3편에서 As-is 산출물의 결정 트리거를 정리했고, 4편에서 CBO 개발의 3단계 위계를 다뤘다. 그러나 자료를 결정으로 읽지 못하고 문서로 쌓아둔 결과가 어떻게 나타나는지는 별개의 이야기다. 한 그룹사 PCE 전환 프로젝트가 운영 개시 직후 2026년 1월 초 에 마주한 품질재고 일괄 합격 일탈 사례를 본다. 사건은 GMP 사이트 9곳을 포함한 10개 플랜트에서 동시에 발생했고, 그 원인은 CSV 테스트 단계에서 놓친 한 가지 에 있었다. 일탈의 모습 — 생산오더 빈값에서 시작된 일괄 합격 검사로트 한 건이 전체 플랜트의 검사대기 재고를 끌고 갔다. LIMS(외부 품질관리 시스템)에서 SAP로 시험 결과를 보내면, SAP는 해당 검사로트를 합격으로 판정하고 재고 상태를 품질재고 → 가용재고 로 전환한다. 정상은 해당 검사로트에 대해서만 판정이 적용되어야 한다. 그러나 운영 개시 직후 발생한 일탈은 3~4초 간격으로 동일 시점 검사대기 재고가 일괄 가용으로 전환 되는 현상이었다. 원인의 출발점은 한 가지였다 — 생산오더 값이 빈값(blank)으로 산출된 검사로트 . PCE 마이그레이션 시 생산입고 검사유형(코드 04)의 검사로트는 생산오더와 함께 정상 이관되었다. 그러나 LIMS에서 판정 결과를 수신할 때, 검사로트와 생산오더를 매핑하는 마이그레이션 매핑 테이블 조회에서 일부 로트의 생산오더가 빈값으로 반환됐다. 이 빈값이 다음 단계의 SQL 조회 조건으로 들어가면서, 생산오더가 빈값인 모든 검사로트 가 일괄 합격 처리 대상으로 포함됐다. 한 검사로트의 빈값이 플랜트와 무관하게 전사 검사대기 재고를 끌고 가는 구조가 그 짧은 순간에 작동한 것이다. CSV 테스트가 놓친 한 가지 — 운영 환경 조건 미반영 테스트는 운영의 마이그레이션 상태를 그대로 재현하지 못했다. PCE 전환의 CSV(Computer System Validation) 단계는 2차·3차 테스트로 구성된다. 이 단계의 핵심은 운영에서 발생할 모든 시나리오를 ...
자세한 내용 보기