Kronopia

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 서비스 가 같은 카테고리에 들어간다. 어시스턴트 외에 문서 자동 처리, 마스터 데이터 자동 정제, 코드 생성 보조 같은 영역이 같은 우산 아래 묶이는 그...

  14편에서 BTP CAP 첫 사이클의 세 함정을 짚었고, 18편에서 PCE Configuration 운용 4단계를 정리했다. 19편은 그 둘이 만나는 자리, PCE가 Clean Core로 굳혀진 후에 BTP 사이드카가 그 위에 올라갈 100일의 시간선이다. 이 글은 13·14편과 같은 자료 누적형 예상 가이드 글이다. 작가의 일반 컨설팅 경험과 시리즈 14·18편 자료를 기반으로, PCE 운영을 안착시킨 그룹사가 마주할 100일을 셋업 → 사이클 → 안착의 세 단계로 미리 정리한다. 실제 100일이 진행되면 케이스 보강 글을 따로 올리려 한다. D+1 ~ D+7 — 첫 주: 셋업과 첫 코드 첫 주에는 코드가 아니라 환경이 일이 된다. BTP 구독을 활성화하고, Cloud Foundry 또는 Kyma 공간을 dev·test·prod로 분리하고, 14편에서 결정한 언어(Node.js 또는 Java) 런타임을 깔고, Cloud Connector로 PCE와 BTP를 연결한다. 이 셋업 자체가 작은 프로젝트가 된다. 환경 분리, 권한 모델, 인증서 관리, 네트워크 경로가 모두 처음 잡힌다. 첫 코드는 비즈니스 가치가 없어야 한다. CAP의 표준 템플릿으로 Hello World 수준의 OData 서비스를 띄우고, PCE의 표준 OData를 Cloud Connector를 통해 호출해보는 단계다. 이 셋업이 끝나면 PCE와 BTP가 서로 통신할 수 있는 상태가 확인된다. 첫 주의 가장 흔히 예상되는 함정은 Cloud Connector 셋업 누락이다. 빠진 채로 첫 코드를 짜면 PCE 호출이 모두 timeout으로 떨어지고, 디버깅이 환경 문제인지 코드 문제인지 구분이 안 되는 상태에 빠질 수 있다. 첫 주는 조용히 통신만 확인하면 성공이다. D+8 ~ D+30 — 첫 달: 첫 사이클 완성 첫 주가 끝나면 진짜 첫 사이드카를 만들어볼 수 있다. 비즈니스 가치를 가진 하나의 작은 기능, 예를 들어 고객 마스터의 자체 필드 추가 같은 경계가 분명한...

  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편에서 본...

15편에서 한국 그룹사가 2026에 RISE 묶음 으로 가장 많이 간다고 짚었고, 16편에서 PCE와 BTP를 함께 결정해야 하는 5가지 이유 를 정리했다. 17편은 그 결정의 다음 갈래 다. 정확히 말하면 PCE vs RISE 가 아니라 PCE 단독 도입 vs PCE를 RISE 묶음으로 도입 의 비교다. PCE 자체가 RISE 묶음에 포함될 수 있는 제품이라, 비교는 제품 이 아니라 도입 방식 에서 일어난다. 같은 PCE를 어떤 방식 으로 받을 것인가의 다섯 가지 비교 축을 정리한다. 1. 계약 구조 항목별 분리 vs 통합 묶음 PCE 단독 도입은 기능 라이센스, 인프라, 마이그레이션 서비스, 운영 지원 을 각각의 항목으로 협상한다. 각 항목이 다른 계약, 다른 갱신 주기, 다른 책임 주체를 가진다. 그룹사 IT 부서가 항목별로 SAP·SI·하이퍼스케일러·BTP 영업과 동시에 협상 테이블에 앉는 구조다. RISE 묶음은 이 모든 항목을 하나의 묶음 계약 으로 받는다. SAP가 인프라(자체 또는 하이퍼스케일러 제휴) + 기능 라이센스 + 마이그레이션 도구 + 일정 수준의 BTP credit + Premium Support까지 한 묶음으로 제공한다. 계약 구조의 차이는 몇 번의 협상 과 몇 개의 책임 주체 를 만들 것인가의 차이다. 2. 포함 서비스 RISE에 기본으로 들어 있는 것 RISE 묶음의 큰 매력은 기본 포함 서비스의 폭 이다. BTP credit이 일정 수준 포함되어 11·12편의 라이센스 함정을 일부 완화하고, Cloud Application Lifecycle Management 같은 운영 도구가 함께 들어오고, SAP Activate Methodology 같은 마이그레이션 표준이 자동으로 적용된다. PCE 단독 도입에서는 이 항목들을 별도로 협상 해야 한다. 어떤 항목은 SI 패키지로, 어떤 항목은 SAP 별도 라이센스로, 어떤 항목은 그냥 누락된 채로 들어간다. 즉 RISE는 항목 누락의 위험 을 줄이는 대가로 항목별 최적화의 자...

11편에서 BTP 라이센스의 함정을, 12편에서 CBO 전환 비용의 4가지 카테고리를 다뤘다. 시즌 2의 시그니처 메시지가 거기서 풀렸다면, 16편은 그래서 어떻게 결정해야 하는가 의 액션 가이드다. PCE 도입 결정에 BTP를 함께 묶어야 하는 다섯 가지 이유를 정리한다. 이 글은 한국 그룹사의 IT 임원·PM·재무 의사결정자가 RISE 묶음의 구성 을 처음 협상할 때 손에 쥘 수 있는 결정 프레임이다. 단일 패키지를 고르는 시대는 지났고, 조합과 시점 이 결정의 본체가 됐다. 1. 협상력은 PCE 결정 시점에 가장 크다 11편에서 떠날 수 있는 쪽이 협상에서 강하다 고 짚었다. 그룹사가 어떤 SAP 시스템에도 아직 의존하지 않은 시점은 PCE 도입 결정 직전 단 한 번 뿐이다. 이 시점에 BTP를 함께 협상 테이블에 올리면, BTP는 PCE 협상의 조건 으로 작동한다. 조건 이라는 단어가 핵심이다 — BTP credit, 사용량 한도, 갱신 주기, 가격 보호 조항 같은 항목이 PCE 패키지 전체의 조건 과 묶이면 단독 협상에서는 받을 수 없는 균형점이 만들어진다. 분리하면 이 조건이 사라진다. PCE 협상이 끝난 회사는 이미 PCE 위에서 작동하는 회사이고, 어디로 떠날 수 있는 회사 가 아니다. 이때부터 BTP 협상은 가격의 게임이 아니라 조건 변경의 정도 를 다투는 게임이 된다. 그룹사 의사결정자가 시작 단계에 잡아야 하는 것은 최저가 가 아니라 협상력 자체 다. 2. CBO 분류는 PCE 시작 단계에 끝나야 BTP 사이드카가 가볍다 4편에서 CBO 개발의 3단계 위계(Key User → Embedded → Side-by-Side)를 정의했고, 12편에서 Side-by-Side로 가는 결정 이 4가지 비용을 만든다고 풀었다. PCE만 먼저 결정하고 운영에 들어가면, 어느 CBO를 사이드카로 옮길지 가 운영 후 재분류 작업이 된다. 이 재분류는 이미 동작 중인 CBO 를 다루기 때문에, 분류 결과가 수정만으로 끝나지 않고 재개발까지 가게 된...

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편의 결...

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의 데이터 모델을 그...

12편에서 CBO를 BTP로 옮기는 진짜 비용 이 4가지 카테고리에서 발생한다고 짚었다. 그 비용 위에 본격 시행착오가 쌓이는 첫 자리가 BTP Integration Suite다. 13편은 PCE에서 BTP로 통합을 옮길 때 그룹사가 흔히 마주하는 3가지 시행착오 함정 을 정리한다. 이 글은 진행 중인 시행착오 자료가 누적되기 전 에 작성된 예상 패턴 글이다 — 시리즈 5·6·12편 자료와 일반 컨설팅 경험을 기반으로 했고, 실제 시행착오 발생 시 보완 글을 따로 낸다. CPI 시행착오, 그대로 옮기기의 함정 기존 PI/PO의 iFlow를 그대로 옮기면 BTP의 장점을 절반쯤 놓친다. 그룹사가 가장 흔히 가는 길은 단순하다. 기존 SAP PI/PO 위에서 만든 iFlow(인터페이스 흐름)를 BTP CPI(Cloud Platform Integration)로 1:1 마이그레이션 . 빠르고 익숙하다. 그러나 이 그대로 옮기기 는 두 가지 전제를 깬다. 첫째, On-Prem PI는 사내 네트워크 위에서 동작했고, 둘째, 동기 호출과 짧은 응답 에 최적화돼 있었다. BTP CPI는 인터넷 위 에서 동작한다. 보안 모델은 mTLS·OAuth·Cloud Connector로 재설계되어야 하고, 메시지 처리는 분산 환경의 비동기 가 더 자연스럽다. 그대로 옮기면 기존 iFlow에 잠복해 있던 가정 이 운영에서 드러난다. 6편의 일탈 사례와 같은 구조다. 환경 조건 이 다른데 코드는 그대로다. CPI 첫 통합의 진짜 일은 마이그레이션이 아니라 재설계 다. 어떤 iFlow가 1:1로 옮겨도 되고, 어떤 iFlow가 Cloud Native 패턴 으로 재설계되어야 하는지의 분류가 시작 단계에 끝나 있어야 한다. 분류 없이 옮기면 통합 테스트가 환경 차이 에서 실패한다. API Management 시행착오 노출 분류가 늦어지는 함정 API Management는 도구가 아니라 분류 결정 이다. API Management의 본질은 게이트웨이·정책 도구가 아니라 경계 ...

  11편에서 BTP 라이센스 협상의 진짜 시점은 PCE를 결정할 때 라고 짚었다. 그러나 라이센스는 시작일 뿐이다. 12편은 그 너머의 비용 CBO를 BTP로 옮기는 진짜 비용 을 본다. 이 비용은 4가지 카테고리(개발·운영·라이센스·학습)에서 발생하지만, 발생 패턴 으로 묶으면 셋이다. 즉시 비용, 누적 비용, 조직 비용. 4편에서 정의한 Side-by-Side로 옮겨야 하는 경우 가 실제로 어떤 비용을 만드는지 정리한다. 이 글도 얼마인가 는 다루지 않는다. 결정 프레임만 다룬다. 즉시 비용과 개발 / 한 번이지만 언어가 다르다 Embedded Steampunk는 익숙한 언어 , Side-by-Side는 다른 언어 다. 4편에서 본 3단계 위계의 차이는 코드 위치 만이 아니다. Embedded Steampunk는 PCE 안에서 ABAP for Cloud로 작성된다. 기존 ABAP 개발자가 언어 전환 없이 적응할 수 있는 영역이다. Side-by-Side는 다르다. CAP(Cloud Application Programming)은 Node.js 또는 Java 위에서 작동하고, BTP 위 Steampunk도 PCE의 ABAP과는 다른 런타임 에 산다. 즉 Side-by-Side로 옮긴다는 결정은 플랫폼 결정 이자 언어 결정 이다. 이 결정의 즉시 비용은 단순한 코드 라인 수가 아니다. 외부 컨설턴트 의존도가 상대적으로 높아지고 , 내부 개발자의 시간당 생산성 도 학습 기간 동안 떨어진다. 같은 기능을 PCE 안에서 ABAP으로 풀 때와 BTP 위에서 CAP으로 풀 때, 코드 시간 은 비슷할 수 있지만 조직 시간 은 다르다. 개발 비용은 한 번 발생하지만 언어 전환의 부담 은 코드 라인 너머에서 작동한다. 이 부담을 가볍게 만드는 유일한 방법은 Side-by-Side 결정을 시작 단계에 묶어서 학습 일정을 미리 깔아두는 것이다. 누적 비용 운영과 라이센스는 지속 발생한다 개발이 끝난 후가 진짜 시작이다. CBO 하나를 BTP로 옮기면,...

10편에서 늦은 분담은 라이센스에서 가장 먼저 무거워진다 고 짚었다. 11편은 가장 먼저 무거워지는 자리 가 정확히 어디인지 본다. 이 글은 얼마인가 를 다루지 않는다. SAP 공식 가격표나 회사별 계약 금액은 의미 있는 정보가 되기 어렵다. 협상 결과는 회사·시점·묶음에 따라 달라진다. 다루는 것은 어떤 결정이 어떤 비용 구조를 만드는가 의 프레임이다. 라이센스는 기술 결정이 아니라 타이밍 결정이다. 언제 결정하느냐가 얼마를 내느냐보다 중요하다. 함정 1. 분리 결정의 환상 PCE 먼저, BTP 나중이라는 결정은 두 번의 협상 을 만든다. 그룹사가 흔히 가는 길은 단순하다. PCE 도입을 먼저 결정하고, 운영을 안착시키고, 그 다음에 BTP를 검토한다. 이 순서가 자연스러워 보이는 이유는 분명하다. PCE 자체가 큰 결정이고, BTP는 나중에 봐도 된다 는 인상을 준다. 그러나 이 분리는 협상 테이블 위에 올릴 수 있는 카드 를 둘로 쪼갠다. PCE 협상 시점에 BTP가 결정 패키지에 포함되어 있다 면, BTP가 PCE 협상의 조건 으로 작동할 수 있다. 분리하면 그 조건이 사라진다. PCE는 PCE대로 협상이 끝나고, BTP는 BTP대로 별도 협상에 들어간다. 분리 결정의 진짜 비용은 협상력의 분리 에서 시작된다. 동시에 두 번의 학습 곡선 과 두 번의 내부 합의 가 생긴다. IT 부서가 두 번 의사결정 자료를 만들고, 재무 부서가 두 번 검토하고, 경영진이 두 번 승인한다. 이 행정 비용 은 보이지 않게 누적된다. 함정 2 — 구독 모델의 누적 효과 BTP는 한 번 사는 라이센스가 아니라 지속 누적되는 구독 이다. PCE는 비교적 정해진 구조 의 라이센스다 — 사용자 수, 모듈, 환경을 정하고 그 위에서 운영된다. BTP는 다르다. BTP는 서비스·사용량·계정 단위로 누적 되는 구독 모델이다. CAP 한 앱이 늘어나면 컴퓨트 사용량이 늘고, Integration Suite 메시지 수가 늘면 그쪽 사용량이 늘고, 사용자가 늘면 계정 비용이 ...

시즌 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는 회사 고유 영역을 자유롭게 푼다. 이 분...

.8편에서 Cutover의 5일이 끝나는 지점이 D+1이라는 시작점 이라고 짚었다. 그 시작점부터 약 30일이 Hyper Care다. 이 30일은 시스템이 안정화되는 기간이라기보다는 조직이 새 시스템에 적응하는 기간이다.  PCE 전환 사례에서, 운영 개시 직후 한 달이 어떻게 세 가지 원칙 으로 굴러갔는지 본다. 변경 최소화 지루함이 안전이다 오픈 직후의 안전은 새로운 일을 하지 않는 것 에서 온다. Hyper Care 기간의 가장 흔한 실수는 작은 개선 요청에 즉시 반응 하는 것이다. 사용자가 "이 화면에 항목 하나만 추가하면 좋겠다"고 보내면, 운영팀은 별로 큰 일이 아니라고 생각해서 빠르게 반영한다. 그러나 PCE 같은 통합 시스템에서 작은 변경 한 건 은 잠재적으로 미식별 의존성 을 건드린다. 7편에서 본 Role-Catalog-Tile-매뉴얼의 4단 매핑이 그 예다. Tile 하나를 바꾸면 그 Tile을 보는 Role이, 그 Role을 가진 사용자가, 그 사용자에게 배포된 매뉴얼이 조용히 어긋난다. 원칙은 단순하다.  비상 변경(Critical/Hotfix)만 허용 . 신규 기능 배포는 일단 멈추고, 사용자 요청은 목록 에만 쌓아둔다. 작은 수정 한 건이 미식별 의존 을 깨뜨려 다른 기능을 멈추게 할 수 있다는 가능성을 늘 의식해야 한다. 이 원칙이 지루하게 느껴진다면 그것이 정확히 원하는 상태 다. Hyper Care 기간의 지루함 은 안정 운영이 작동하고 있다는 신호다. 시스템 자체에 변화가 적을수록, 사용자가 새 시스템에 적응할 시간을 얻는다. 모니터링 최대화 — 보는 것을 늘리기 변경을 줄이는 만큼 보는 것 을 늘린다. Hyper Care의 모니터링은 네 갈래 로 작동한다. 첫째, SXI_MONITOR  인터페이스 송수신 로그. 6편 일탈 사례에서 LIMS 인터페이스 차단의 검증에 쓰인 도구다. 둘째, MB51  재고 이동 이력. 품질재고 → 가용재고 같은 상태 전환이 정상 범위인지 ...

시즌 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는 분 ...

5편에서 데이터소스의 동기화 전략을, 6편에서 운영 직후 일탈 사례를 봤다. 7편의 질문은 다르다. 그 래서 누가 그 시스템을 어떻게 쓰는가 . PCE 전환 프로젝트에서 Fiori Role 설계와 사용자 교육은 서로 다른 작업 처럼 보이지만, 실제로는 같은 결정의 두 얼굴 이다. PCE 전환 사례에서, RZ040부터 사용자 매뉴얼까지 4단 매핑이 어떻게 변화관리 자체가 되었는지 본다. RZ040 Role 설계가 변화관리의 출발점이다 Role은 권한의 명단이 아니라 변화관리 대상자의 명단이다. RZ040(사용자 Role 정의서)은 SAP에서 누가 무엇을 할 수 있는가 를 모듈 단위로 정리한 산출물이다. 본 프로젝트의 As-is 분석 폴더에는 RZ040이 FI·MM·SD·CO·PP·QM·IM·EX 8개 모듈로 각각 잡혀 있다. 8개 파일이 따로 분리된 것은 우연이 아니다 — 모듈마다 권한 단위가 다르고, 변화관리 강도도 다르다 . FI(재무)의 Role 한 줄과 PP(생산)의 Role 한 줄은 같은 무게로 다뤄질 수 없다 . Role은 본질적으로 한 사람의 하루 를 정의한다. SD Role을 받은 영업담당자는 그 안에서만 화면을 본다. PP Role을 받은 생산담당자는 다른 화면을 본다. 그러니까 Role 정의서가 모듈별로 완성되는 순간 , 그 모듈을 쓰는 사용자 명단도 함께 고정 된다. Role 정의가 끝나는 순간 변화관리 대상자 명단이 함께 끝난다 — Role 한 줄 옆에 어떤 부서, 어떤 역할의 사용자 가 따라붙는지 채워두면 변화관리 부서는 그 명단으로 교육 계획을 짜기 시작한다. Catalog Group → Tile — Role을 화면 위에 펼치기 Catalog Group은 Role과 Tile의 다리다. Fiori 환경에서 사용자가 실제로 보는 것은 Tile이다. Tile은 SAP 트랜잭션이나 앱을 화면 위 작은 카드 로 펼친 단위다. Role이 정의됐어도, 그 Role에 어떤 Tile이 붙는가 가 따로 매핑되어야 한다. 그 다리가 ...

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

1편에서 PCE 전환 시 BW가 가장 먼저 흔들린다는 점을 짚었다. 5편은 그 흔들림이 어디서 어떻게 작동하는지를 본다. PCE 마이그레이션의 기본 전제 하나 PCE에는 Open Item만 이관된다 . 과거 데이터는 BW에 남거나 별도 백업으로 보관된다. 이 전제가 BW 데이터 연계를 단순 마이그레이션이 아니라 데이터소스 성격에 따른 동기화 전략 분기 문제로 만든다. BW의  동기화  영역과 비동기화 영역을 처음부터 다른 전략으로 접근해야 한다. CBO 데이터소스 — 기간 기준 동기화가 가능한 영역 회사가 직접 만든 데이터소스는 가장 다루기 쉬운 영역이다. CBO 데이터소스(ZBIF_KNA1_001, ZSD_A701_001 같은 Z 접두사로 시작하는 generic D/S)는 회사가 직접 정의했기 때문에 추출 시점, 추출 키, 데이터 적재 기간을 직접 통제 할 수 있다. 본 프로젝트의 데이터소스 현황 산출물에서 CBO 데이터소스는 80여 개가 잡혀 있고, 대부분 SDI 기반 (SDIEABA100, SDIBABA100)이다. SDI(Smart Data Integration)는 HANA에서 외부 시스템 데이터를 가상 또는 복제 방식으로 연결하는 방식이고, 이 위에서 만든 generic D/S는 추출 로직이 회사 손 안에 있다 . 이 영역의 동기화 전략은 단순하다.  PCE의 데이터 적재 기간을 고려하여 기간 기준으로 동기화 . "이 시점부터 이 시점까지의 데이터를 가져와라"는 명령이 그대로 통한다. 여기서 막히는 일은 거의 없다. 기간만 정확히 잡으면 데이터는 원하는 대로 들어온다. CBO 데이터소스의 정의 자체가 동기화 가능성의 첫 번째 자산이다.  회사가 자기가 만든 것은 자기가 끌어올 수 있다. PCE 전환 직전 80여 개 CBO 데이터소스 중 무엇을 살리고 무엇을 폐기할지 가 시작 단계에 정리돼 있어야 이 동기화가 실제로 가볍게 끝난다. STD-FCM 데이터소스 결산 사이클이 제약 조건 표준 데이터소스 중...

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 개발자가 가장 적응하기 쉬운 영역 익숙한 언어, 익숙...