Kronopia

글

최근 글

BTP 사이드카 본격 도입 첫 100일 — 셋업·사이클·안착 예상 가이드

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 — 첫 달: 첫 사이클 완성 첫 주가 끝나면 진짜 첫 사이드카를 만들어볼 수 있다. 비즈니스 가치를 가진 하나의 작은 기능, 예를 들어 고객 마스터의 자체 필드 추가 같은 경계가 분명한...

자세한 내용 보기

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

자세한 내용 보기

SAP PCE 단독 도입 vs RISE 묶음 5가지 비교

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는 항목 누락의 위험 을 줄이는 대가로 항목별 최적화의 자...

자세한 내용 보기

SAP PCE와 BTP를 함께 결정해야 하는 5가지 이유

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 를 다루기 때문에, 분류 결과가 수정만으로 끝나지 않고 재개발까지 가게 된...

자세한 내용 보기

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

자세한 내용 보기

Kronopia

이 블로그 검색

글

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

BTP 사이드카 본격 도입 첫 100일 — 셋업·사이클·안착 예상 가이드

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

SAP PCE 단독 도입 vs RISE 묶음 5가지 비교

SAP PCE와 BTP를 함께 결정해야 하는 5가지 이유

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

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