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를 다루기 때문에, 분류 결과가 수정만으로 끝나지 않고 재개발까지 가게 된다. 시작 단계에 PCE+BTP를 함께 결정하면, CBO 분류는 Side-by-Side 후보 인벤토리를 PCE 첫 코드 라인 전에 확정하는 일이 된다. As-is 단계의 CBO Program List가 분류 결정의 입력값으로 작동하고, 사이드카로 갈 항목은 처음부터 PCE 안에 코드가 쌓이지 않는다. 분류가 시작 단계에 끝나면 사이드카는 옮기는 일이고, 늦어지면 다시 짜는 일이다.
3. 데이터·UI·외부 결합의 경계는 동시 결정에서만 잡힌다
10편에서 PCE 안에 둘 수 없는 세 영역을 짚었다 — 자체 데이터 누적, 자체 UI, 외부 시스템 깊은 결합. 14편의 CDS 시나리오가 그 디테일이다. 이 세 영역의 경계는 PCE 단독 결정으로는 그릴 수 없다. PCE 안의 데이터 모델이 어디까지 표준 객체로 가고 어디서부터 BTP CDS로 분리될 것인가, 어떤 화면이 Fiori Tile로 풀리고 어떤 화면이 BTP 위 별도 앱으로 가야 하는가, 외부 시스템과의 통합이 PCE 표준 인터페이스로 충분한가 BTP Integration Suite가 필요한가 — 이 세 가지 결정은 PCE의 As-is·To-Be 분석 단계에 BTP 측의 데이터·UI·통합 평면이 함께 그려져야 답이 나온다. 분리해서 결정하면 PCE는 경계를 모르는 상태로 설계되고, 운영 후 BTP를 얹을 때 PCE 모델이 수정 대상이 된다. 경계는 그릴 수 있는 시점에 그려야 비용이 가볍다.
4. 인력·학습 곡선은 동시 결정으로 분산된다
12편에서 학습 곡선의 비용은 청구서에 안 나오는 내부 시간이라고 짚었다. ABAP 개발자가 CAP을 익히는 시간, PCE 운영팀이 Cloud Native 운영을 익히는 시간, 아키텍트가 사이드카 설계 패턴을 익히는 시간 — 이 학습이 동시 결정에서는 PCE 구축 9개월 동안 자연스럽게 분산된다. 1년차에 PCE 구축이 진행되는 동안 몇 명이 BTP 학습 트랙에 들어가 있고, 2년차에 BTP 사이드카가 본격 시작될 때 그 인력이 준비된 상태로 합류한다. 분리 결정이면 학습이 PCE 운영 안착 후에 한꺼번에 시작되고, 인력 확보 협상도 그 시점에 따로 진행된다. BTP 인력 시장은 한국에서 공급이 빠듯한 영역이라 늦은 확보는 시간과 비용을 모두 키운다. 결과는 같다 — 학습 미완 상태의 운영이 새로운 이슈를 만들고, 그 이슈가 Hyper Care 기간 외에서 발생하면 6편의 일탈 사례 같은 구조가 반복된다. 시간을 분산시키는 결정이 곧 비용을 분산시키는 결정이다.
5. 운영 모델은 두 시스템이 동시에 도입돼야 일관된다
14편에서 본 PCE의 transport와 BTP의 CI/CD는 다른 종류의 흐름이다. 분리 도입이면 PCE 운영팀은 transport 모델을 먼저 굳히고, 나중에 BTP 운영을 별도 체계로 받게 된다. 두 운영 모델이 분리된 채 작동하면 변경관리·모니터링·장애 대응의 절차가 시스템마다 다른 회사처럼 굴러간다 — 같은 변경 요청이 PCE 채널로 들어가면 transport로, BTP 채널로 들어가면 CI/CD로 처리되고, 두 채널 사이의 경계 이슈는 어느 쪽도 책임지지 않는다. 동시 도입이면 처음부터 통합 운영 설계가 가능하다 — 어느 변경이 PCE 안에서 transport로 가고 어느 변경이 BTP CI/CD로 가는지의 분담 룰이 시작 단계에 잡힌다. 9편의 Hyper Care 3원칙(변경 최소화·모니터링 최대화·이슈 대응)이 두 시스템에 동시에 적용 가능해진다. 운영 모델의 일관성은 두 시스템이 같은 조직 안에서 같은 시점에 시작될 때만 만들어진다.
한 줄로
다섯 가지 이유는 모두 한 가지를 말한다 — 시작 단계의 결정 무게. 협상력·CBO 분류·경계 짓기·학습 곡선·운영 일관성, 다섯이 모두 PCE 결정 시점에 통제 가능하고, 그 시점을 놓치면 다섯이 모두 후처리 비용으로 누적된다. 11·12편의 시그니처 메시지가 여기서 액션 가이드로 닫힌다. 17편에서 PCE와 RISE with SAP의 다섯 가지 차이를 비교한다 — 동시 결정의 프레임 안에서 어떤 패키지를 고를 것인가의 다음 결정이다.
댓글
댓글 쓰기