기본 콘텐츠로 건너뛰기

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의 데이...

BTP Integration Suite 첫 통합 — 3가지 시행착오

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의 본질은 게이트웨이·정책 도구가 아니...

SAP CBO BTP 전환의 진짜 비용 — 청구서에 안 나오는 것

  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 하나를...

SAP BTP 라이센스의 3가지 함정 — 분리·구독·협상력

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 메시지 수가 늘면 그쪽 사용량이 늘고, 사용자가 늘면 계정 ...