기본 콘텐츠로 건너뛰기

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 설정도 이 시점에 마지막 점검이 이뤄진다.  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일을 다룬다.

라벨:

댓글

댓글 쓰기

이 블로그의 인기 게시물

SAP Joule과 Generative AI in SAP / 2026 AI 카테고리의 진입

15편에서 2026 한국 SAP 시장의 풍경 과 다음 12개월의 결정점 세 가지 를 정리했고, 그 셋째가 AI 기능 확산 이었다. 20편은 그 셋째 결정점을 단독으로 들여다본다 SAP Joule이라는 어시스턴트 제품과, 그 너머의 Generative AI in SAP 카테고리. 이 글은 작가가 직접 운영해본 영역이 아닌 시장 자료와 SAP 공식 발표 기반의 트렌드 정리 다. 실제 적용 케이스가 누적되면 보강 글을 따로 낸다. SAP Joule 어시스턴트 카테고리의 등장 SAP Joule은 SAP 제품군 전반에 대화형 인터페이스 를 얹는 어시스턴트다. S/4HANA Cloud, SuccessFactors, BTP, Ariba 등 SAP 주요 제품에 공통 채팅 UI 가 들어가는 그림이다. 사용자가 자연어로 질문하면 Joule이 해당 제품의 트랜잭션이나 데이터를 가져다 답하는 흐름이다. SAP Sapphire 2023~2025의 발표에서 Joule은 전 제품 통합 어시스턴트 로 자리매김했다. Joule의 의미는 어시스턴트 자체 보다 카테고리의 등장 에 있다. SAP는 기존에 트랜잭션 코드(T-code) + Fiori 의 두 인터페이스 층을 가졌다. Joule은 그 위에 제3의 층 을 얹는다. 어떤 업무가 이 제3의 층 으로 넘어갈지, 어떤 업무는 여전히 Fiori·T-code에서 처리될지의 분류 결정 이 새로 추가된다. 시리즈 4편의 Clean Core 위계와 같은 결정 구조가 AI 카테고리에도 작동하게 된다. Generative AI in SAP Joule을 넘어선 카테고리 Joule은 어시스턴트 한 축이고, Generative AI in SAP는 그보다 넓은 카테고리다. BTP의 AI Core·AI Launchpad·Document Information Extraction 같은 기능형 AI 서비스 가 같은 카테고리에 들어간다. 어시스턴트 외에 문서 자동 처리, 마스터 데이터 자동 정제, 코드 생성 보조 같은 영역이 같은 우산 아래 묶이는 그...
댓글 쓰기
자세한 내용 보기

BTP CAP 첫 개발 사이클 PCE 관성을 깨는 결정 3가지

13편에서 Integration Suite는 도구가 아니라 재설계 결정 3가지 라고 짚었다. 같은 본질이 BTP CAP 첫 개발 사이클에서 다른 모습으로 작동한다. 14편은 그룹사가 PCE 안에서 익숙하게 일하다가 BTP 위에서 CAP 첫 사이클을 시작할 때 마주하는 3가지 함정 을 정리한다. 이 글도 13편처럼 자료 누적형 예상 패턴 글이다. 작가 일반 지식과 시리즈 4·12·13편 자료를 기반으로 했고, 실제 CAP 사이클이 진행되면 보완 글을 따로 낸다. 언어 선택의 함정 PCE의 관성에서 벗어나기 CAP의 언어는 Node.js와 Java 둘이지만, 진짜 결정 은 언어가 아니라 관성이다. CAP(Cloud Application Programming Model)은 BTP 위에서 작동하는 SAP의 표준 개발 프레임워크다. Node.js 와 Java 양쪽을 지원하고, 같은 CDS(Core Data Services) 모델 위에서 두 언어가 동등하게 동작한다. 그룹사 첫 사이클에서 이 둘 중 하나를 고를 때, 흔한 함정은 기존 ABAP 개발자가 익숙해 보이는 쪽 을 고르는 것이다. 일반적으로 Java가 문법적으로 더 친숙 해 보여서 그쪽으로 기울고, 그 결정이 팀 역량 분석 없이 굳어진다. 이 결정의 진짜 비용은 코드 라인이 아니라 런타임의 무게 에서 나온다. BTP의 Cloud Native 환경에서 Node.js는 경량 스타트업과 작은 메모리 footprint 를 만들고, Java는 엔터프라이즈 패턴과 큰 컴퓨트 사용량 을 만든다. 12편의 누적 비용 모델이 여기서 작동한다. 작은 CAP 앱을 Java로 짜면 컴퓨트 사용량 이 비례 이상으로 늘어난다. 언어 선택은 팀 역량과 Cloud Native 적합도 의 균형으로 결정해야 한다. ABAP 관성이 Java 관성으로 바뀌고, Java 관성이 학습 미완료 상태의 운영 으로 이어지는 흐름이 가장 흔한 첫 사이클 실패다. 데이터 모델 함정 CDS의 자체성을 살리는 결정 PCE의 데이터 모델을 그...
댓글 쓰기
자세한 내용 보기

2026 SAP 도입 동향 GROW·RISE·BTP의 한국 풍경

14편에서 PCE의 관성 이 BTP의 본질을 가린다고 짚었다. 그러나 이 관성도 시장의 풍경 이 바뀌면서 함께 움직인다. 15편은 시즌 1·2의 마지막 글이다. 한 그룹사 PCE 전환 사례에서 출발한 14편의 이야기를 2026 한국 SAP 시장의 풍경 속에 위치시키고, 다음 12개월의 결정점을 정리한다. 2026 한국 SAP 시장의 풍경 GROW · RISE · BTP 2026의 한국 SAP 시장은 세 가지 패키지 가 재편하고 있다. 첫째, GROW with SAP . 중견기업과 신규 도입 대상에 맞춰진 Public Cloud 기반 패키지다. 표준 프로세스를 받아들이는 대신 도입 속도와 비용 예측 가능성이 높다. 한국 시장에서는 그룹사가 아닌 단일 법인 중견기업 의 진입로로 자리 잡는 추세다. 둘째, RISE with SAP . 그룹사와 대기업의 마이그레이션 묶음 이다. S/4HANA Cloud(주로 PCE)와 BTP credit 이 함께 묶이는 구조라, 시즌 2의 11~12편이 다룬 라이센스 함정 과 CBO 전환 비용 의 시장 배경이 정확히 여기다. 셋째, BTP 단독 도입 . 기존 SAP 시스템 위에 BTP만 얹어 확장 측면 만 가져가는 모델이다. 그룹사 디지털 전환의 두 번째 단계 에서 흔히 선택된다. 한국 그룹사가 2026에 가장 많이 가는 길은 RISE 묶음 이다. 그 묶음 안에 PCE와 BTP가 어떻게 엮이는가 이게 시즌 2의 시그니처 메시지가 출발한 자리다. 2026의 의사결정자는 세 패키지 중 하나 가 아니라 세 패키지를 어떻게 조합하는가 를 결정한다. 단일 패키지를 고르는 시대는 지났고, 조합과 시점이 결정의 본체가 됐다. 이 풍경 속에서 시리즈 1~14편이 닿는 곳 시리즈 1~14편이 다룬 모든 결정이 2026 풍경의 디테일 이다. 시즌 1의 1~9편은 PCE 구축의 풀 라이프사이클 을 다뤘다 . RISE 묶음을 받은 그룹사가 마주하는 9개월의 실제 작업 이다. 1편의 코어보다 주변이 먼저 흔들린다 에서 시작해, 3편의 결...
댓글 쓰기
자세한 내용 보기