기본 콘텐츠로 건너뛰기

PCE 운용 가이드 도입 직후부터 분기 갱신까지

 

17편에서 PCE 단독 도입과 RISE 묶음 도입의 5가지 비교 축을 정리했다. 어느 쪽을 선택하든 그룹사가 받는 제품은 PCE다. 18편은 그 PCE를 받은 후의 운용 가이드다. 1편에서 Configuration 자유도가 줄어든다고 했고, 3편에서 RZ010이 결정 트리거라고 풀었다면, 18편은 같은 RZ010이 분기별 운용에서 어떻게 굴러가는지를 본다.  PCE 전환 사례의 자료 폴더에는 모듈별 RZ010 산출물이 8개 모듈에 걸쳐 누적되어 있고, 그 산출물이 운용 4단계의 체크리스트를 만들었다.

1단계 도입 직후 (D-Day ~ D+30): Configuration 인벤토리 굳히기

PCE 운영 개시 직후 첫 30일은 Configuration 인벤토리를 굳히는 시간이다. RZ010(설정값 리스트)을 모듈별로 출력하면 현재 상태의 사진이 잡힌다. 본 시리즈의 자료 폴더에는 D1 분류의 Configuration list가 모듈별로 FI·MM·SD·CO·PP·QM·IM·EX 8개 갖춰져 있다. 한 모듈당 수백 줄의 설정값이 인벤토리의 단위가 된다.

이 단계의 핵심은 변경이 아니라 기록이다. 8편 Cutover의 분 단위 시간표가 끝난 직후라 시스템에 손대지 않는다. RZ010을 그대로 떠서 모듈별 v1.0 산출물로 저장하고, 표준값과 차이가 있는 항목을 별도로 표시한다. 이 차이 표시가 다음 단계의 점수 매기기 입력값이 된다. 9편 Hyper Care 3원칙의 변경 최소화가 이 단계에 정확히 작동한다.

체크리스트:

  • 모듈별 RZ010 v1.0 산출물 작성 완료
  • 핵심 설정 수백 줄의 인벤토리 확보
  • 표준값과 차이 있는 설정 별도 표시
  • 변경관리 동결 (Hyper Care 첫 30일)

2단계 안정화 (D+30 ~ D+90): 표준 회귀 점수 매기기

도입 직후 30일이 지나면 시스템이 어느 정도 안정화된다. 이 단계에 각 Configuration 항목에 3분류 점수를 매긴다. 3편에서 본 표준 회귀 / 변형 / 외부 위성의 그 점수다. 운용 측면에서 이 점수는 현재 분기에 어디까지 표준으로 되돌릴 수 있는가의 결정값이다.

본 시리즈의 SD 모듈만 봐도 C사 RZ010과 법인분리 Configuration list가 별도 산출물로 잡혀 있다. 즉 같은 SD 모듈이라도 법인·시점에 따라 다른 설정 풍경이 있고, 점수 매기기는 법인 단위로 따로 이뤄진다. 9편 Hyper Care의 일별 리뷰에 Configuration 항목별 점수 변화를 포함시키면, 안정화 단계의 결정이 명시적으로 누적된다.

체크리스트:

  • 표준 회귀 후보 목록 작성 (모듈·법인별)
  • 변형(Extensibility) 후보 목록 작성
  • 외부 위성 시스템 후보 식별
  • Hyper Care 일별 리뷰에 Configuration 항목 포함

3단계 정기 운영 (D+90 ~ 분기별): 변경 추적과 변형 관리

90일이 지나면 작은 변경이 자연스럽게 누적되기 시작한다. 4편에서 본 Key User Extension과 Embedded Steampunk가 가장 자주 호출되는 단계다. 정기 운영의 핵심은 변경 추적이다. 누가, 언제, 왜, 무엇을 바꿨는지가 RZ010 버전 관리로 남아야 한다.

본 시리즈 자료의 RZ010 파일들이 v1.0, v1.1, v1.2처럼 버전 표기가 붙어 있는 이유가 여기다. 변경마다 사유와 영향 범위를 명시하지 않으면, 분기 후 어떤 변경이 어디서 깨졌는지 추적이 끊긴다. 4편의 Clean Core 위반에 해당하는 변경(예: 비공식 우회, Z 테이블 무제한 사용)이 발생하면 별도 표시하고, 다음 분기 갱신 단계에서 회귀 검토 대상으로 올린다.

체크리스트:

  • RZ010 v1.0, v1.1, v1.2 ... 버전 관리
  • 변경마다 사유와 영향 범위 명시
  • Clean Core 위반 변경 여부 점검
  • 분기별 SAP 표준 업데이트 대응 회의 예약

4단계 갱신 (분기별): SAP 업그레이드 대응

SAP S/4HANA Cloud는 분기별로 표준 업그레이드가 들어온다. 4편에서 Clean Core가 유지되면 업그레이드가 별일 없이 받아내진다고 했다. 18편 운용 가이드의 마지막 단계는 그 별일 없음을 체계적으로 만드는 일이다.

갱신 직전 RZ010 인벤토리를 SAP 업그레이드 노트와 매핑한다. 표준 영역의 변경은 자동 반영, 변형 영역은 재테스트 필수. 6편의 일탈 사례에서 본 CSV 환경 조건이 여기서 다시 작동한다. 운영과 동일한 환경에서 시험하지 않으면 갱신 후 운영에서 무엇이 깨질지 알 수 없다. 재현 환경에서 시험 후 운영 반영의 순서가 분기마다 반복된다. 이 절차가 굳어지면 분기 갱신은 지루할 정도로 조용한 작업이 된다.

체크리스트:

  • 업그레이드 노트 검토 (분기마다)
  • 변형 영역 재테스트 시나리오 준비
  • CSV 검증 절차 활성화
  • 운영 재현 환경에서 시험 후 운영 반영

한 줄로

Configuration 운용의 본질은 Clean Core 유지다. 인벤토리(D-Day~D+30) → 점수(D+30~D+90) → 추적(분기별) → 갱신(분기별)의 4단계가 굴러가면 PCE는 안정적인 코어로 작동한다. 1편의 Configuration 자유도가 줄어든다는 메시지가 운용 단계에서 자유도가 줄어든 만큼 안정성이 늘어난다로 회수된다. 19편에서 BTP 사이드카 본격 도입 첫 100일을 다룬다. lean Core가 지켜진 PCE 위에 어떻게 사이드카가 올라가는지의 시간선이다.

라벨:

댓글

댓글 쓰기

이 블로그의 인기 게시물

SAP PCE에서 BTP로 Clean Core의 두 자리

시즌 1의 1~9편을 한 줄로 압축하면,  Clean Core를 지킨 PCE 환경을 운영에 안착시키는 9개월의 작업 이다. 그러나 같은 원칙이 PCE가 닿지 않는 곳 을 동시에 만든다. 10편은 그 경계가 어디인지, 그 너머에 왜 BTP가 있는지를 정리한다. 시즌 2를 여는 다리다. PCE의 경계 Clean Core가 만든 닿을 수 없는 곳 Clean Core를 지키는 PCE는 모든 것을 풀지 않는 시스템이다. PCE가 푸는 것은 분명하다. SAP 표준에 충실한 운영, 분기별 업그레이드와의 호환성, 통합 데이터 모델 위의 안정성. 시즌 1의 9편이 만든 결과물이 그것이다. 그러나 PCE는 의도적으로 풀지 않는 영역이 있다. 회사가 자체 정의하는 데이터 모델, SAP 표준 트랜잭션을 벗어난 화면, 외부 시스템과의 깊은 도메인 통합 이런 영역은 PCE 안에서 깨끗하게 작동하지 않는다. 이 영역들을 PCE의 한계 라고 읽으면 시스템과 싸우게 된다. 그러나 같은 영역을 Clean Core가 지킨 결과로 바깥에 남은 자리 라고 읽으면 다음 단계가 보인다. 경계는 결함이 아니라 설계다. 4편에서 Side-by-Side로 옮겨야 하는 경우 를 셋으로 정의했을 때, 이미 그 자리는 PCE 바깥에 존재해야 한다 는 것이 합의된 셈이다. 시즌 1을 마치면 이 경계가 정확히 어디에 그려졌는지 보인다. BTP의 입구 — 별도 시스템이 아니라 역할 분담 BTP는 PCE의 확장팩이 아니라 짝패 다. BTP(Business Technology Platform)를 PCE의 플러그인 으로 받아들이면 BTP의 가치를 절반쯤 놓친다. BTP는 PCE 옆에서 독립적으로 운영되는 별도 클라우드 플랫폼이고, CAP(Cloud Application Programming)·Integration Suite·BTP 위 Steampunk가 그 구성 요소다. 핵심은 기능 이 아니라 역할 분담 이다 PCE는 SAP 표준을 지키고, BTP는 회사 고유 영역을 자유롭게 푼다. 이 분...
댓글 쓰기
자세한 내용 보기

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편의 결...
댓글 쓰기
자세한 내용 보기

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의 데이터 모델을 그...
댓글 쓰기
자세한 내용 보기