기본 콘텐츠로 건너뛰기

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 메시지 수가 늘면 그쪽 사용량이 늘고, 사용자가 늘면 계정 비용이 늘어난다. 즉 처음 결정한 BTP 규모시작 가정일 뿐이다.

이 누적 모델 위에서 분리 결정은 위험을 키운다. PCE 결정 시점에 BTP 사용을 과소평가하면, 운영 후 BTP 사용이 늘어나면서 예상보다 빠른 페이스로 비용이 누적된다. 반대로 PCE 결정 시점에 BTP 사용을 과대 가정하면, 사용하지 않는 영역까지 묶이는 낭비 구조가 만들어진다. 구독 모델에서는 시작 단계 결정이 경계가 아니라 방향이다. 어디까지를 BTP로 옮길 것인가의 방향을 시작 단계에 정해두지 않으면 누적의 페이스를 통제할 수 없다.

함정 3 — 늦은 결정의 협상력 손실

BTP 결정이 운영 이후로 미뤄지면 협상 자체가 다른 게임이 된다.

PCE 운영 안착 후 BTP를 협상하면, 이미 PCE 위에서 작동하고 있는 회사가 협상 테이블에 앉는 셈이다. 사용자는 PCE에 적응했고, 데이터는 PCE에 누적되고, 외부 시스템은 PCE 인터페이스에 묶여 있다. 즉 어디로 떠날 수 있는 회사가 아니다.

협상력의 본질은 단순하다. 떠날 수 있는 쪽이 더 강하다. 의존이 깊어질수록 협상력은 떨어진다. 시작 단계의 동시 결정은 떠날 수 있는 시점에 라이센스 구조를 묶어두는 결정이다. 그 시점에는 회사가 어떤 시스템도 아직 의존하지 않은 상태이고, 대안 검토가 의미 있는 협상 수단으로 작동한다. 협상력은 의존이 시작되기 전에 가장 크다. 이 시점을 놓치면, BTP 협상은 가격의 게임이 아니라 조건 변경의 정도를 다투는 게임이 된다. 본질적으로 다른 협상이다.

함정핵심 메커니즘결과
1. 분리 결정협상 카드 분리, 학습·합의 두 번행정 비용 누적, 협상력 약화
2. 구독 누적사용량·서비스 단위로 늘어남시작 가정이 시작일 뿐, 페이스 통제 어려움
3. 늦은 결정의존이 깊어진 후 협상협상이 조건 변경의 게임이 됨

한 줄로

BTP 라이센스 협상의 진짜 시점은 BTP를 도입할 때가 아니라 PCE를 결정할 때다. 시즌 1에서 본 시작 단계 결정의 무게가 라이센스 영역에서 가장 높은 무게로 작동한다. 분리하면 두 번 협상하고, 늦으면 다른 게임이 된다. 현장에서 보면, 이 세 가지 함정은 대부분 동시에 온다 분리 결정을 했고, 구독이 이미 누적됐고, 협상 시점도 지났다. 함정이 하나씩 오는 경우가 드물다는 게 더 큰 문제다.

댓글

이 블로그의 인기 게시물

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