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 하나를 BTP로 옮기면, 그 CBO는 옮긴 시점부터 매월 두 가지 비용을 만든다. 운영과 라이센스다. 운영 측면에서 BTP는 Cloud Native 환경이다 — DevOps, CI/CD, 분산 모니터링, 컨테이너 배포 같은 도구·절차가 PCE 운영과 다르다. PCE 운영팀이 BTP 운영을 그대로 받지 못한다는 뜻이다. 별도 운영 체계를 세우거나, 외부 운영 서비스를 받거나, 내부 인력을 늘려야 한다. 어느 쪽도 옮긴 시점에 비용이 시작된다.

라이센스는 11편의 누적 모델이 그대로 작동한다. 옮긴 CBO 수가 늘어나면 BTP의 서비스·사용량·계정 footprint가 함께 늘어나고, 비용은 비선형으로 증가한다. 두 CBO를 옮길 때의 누적 비용은 한 CBO를 옮길 때의 두 배가 아니다. 공유되는 운영 체계는 효율을 만들지만, 서로 다른 도메인의 CBO는 각자 인터페이스·데이터·권한을 만들면서 운영 복잡도를 비례 이상으로 끌어올린다. 운영과 라이센스는 옮긴 시점부터 매월 발생하고, 옮긴 CBO 수가 늘면 누적 페이스가 빨라진다.

조직 비용 — 학습 곡선은 청구서에 나오지 않는다

가장 큰 비용은 청구서에 나오지 않는다.

학습 곡선의 비용은 외부에 지급되는 비용이 아니라 내부 시간이다. ABAP 개발자가 CAP을 익히는 시간, PCE 운영팀이 BTP 모니터링을 익히는 시간, 아키텍트가 사이드카 디자인 패턴을 익히는 시간 — 이것들은 청구서에 한 줄로 안 찍힌다. 그러나 조직 안에서 흘러간 시간은 다른 일을 못 한 시간이다.

학습이 끝나지 않은 상태에서 운영하면 보이지 않는 비용이 더 커진다. 6편의 일탈 사례에서 본 것처럼, 환경 조건이 충분히 이해되지 않은 채 운영에 들어가면 작은 이슈가 큰 이슈로 번진다. BTP 위 CBO도 마찬가지다 — 사이드카가 어떻게 PCE와 동기화되는지, 어떤 인터페이스가 어떤 권한으로 작동하는지, 어떤 모니터링 알림이 진짜 위험인지를 충분히 이해하지 못한 운영은 잠재 결함을 그대로 운영에 쌓는다. 학습 곡선의 비용은 시간으로 측정되고, 이 시간은 결정 시점에 통제할 수 있다. 늦게 결정되면 학습이 운영과 동시에 진행되고, 그 충돌이 새로운 이슈를 만든다.

카테고리발생 패턴시점통제 가능성
개발일회성옮길 때Embedded vs Side-by-Side 결정 단계에서
운영누적 (매월)옮긴 후DevOps 체계 수준에 따라
라이센스누적 (매월)옮긴 후11편 협상 시점에
학습점진적결정 직후 ~ 몇 개월결정 시점에 일정 깔기로

한 줄로

CBO를 BTP로 옮기는 진짜 비용은 4가지 카테고리에서 발생하고, 4가지 모두 결정 시점에 통제된다. 늦은 결정은 라이센스(11편)에서 가장 먼저 무거워지지만, 곧이어 개발·운영·학습이 동시에 작동하기 시작한다. 시즌 2의 다음 편들(13·14편)에서 이 비용 구조 위에서 발생한 실제 시행착오 케이스들을 본다 — Integration Suite 첫 통합과 CAP 첫 개발 사이클의 함정.

댓글

댓글 쓰기

이 블로그의 인기 게시물

S/4HANA Cloud CBO 개발 3단계 — 어디까지 위에서 끝내는가

이미지
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 개발자가 가장 적응하기 쉬운 영역 — ...
자세한 내용 보기

S/4HANA Cloud PCE 전환 시작 단계, 가장 먼저 바뀌는 3가지

이미지
ERP 클라우드 전환 의사결정이 끝나면, IT 담당자와 PM은 곧장 "이제 뭘 먼저 바꿔야 하나"라는 질문에 부딪힌다. 대부분의 현장에서는 '코어만 바꾸면 되죠.'라는 가정으로 시작한다. 이러한 가정이 이 글을 쓰게 된 이유다. 실제로 일을 시작해보면 가장 먼저 흔들리는 건 코어가 아니라 코어 주변 이다. On-Prem SAP에서 S/4HANA Cloud PCE로 가는 한 그룹사 마이그레이션 프로젝트의 시작 단계에서, 가장 먼저 바뀐 세 가지 고민을  시스템 토폴로지(시스템 간 연결 구조)가 먼저 바뀐다 코어가 바뀌는 게 아니라 코어 주변이 먼저 흔들린다. On-Prem 시절 BW(Business Warehouse)는 단순했다. SAP ERP 한 곳에서 데이터를 받아 모델링하고 리포트로 풀어내면 됐다. 소스시스템은 사실상 하나, 네트워크 경로는 사내, 권한 모델은 통합. S/4HANA Cloud PCE로 옮겨가면 이 전제가 흔들린다. BW가 PCE 환경의 데이터를 어떻게 끌어올지, 기존 On-Prem BW를 그대로 둘지 함께 옮길지, 인터페이스 계정 권한을 어떻게 재설계할지 — 이 문제들이 코어 전환 전에 결판나야 한다. 이 그룹사 프로젝트에서도 BW 분과의 초기 산출물은 "소스시스템 변경(안)" 문서였다. 실제 코어 전환보다 한 단계 앞서, 데이터가 어디서 어디로 흐르는가 의 지도를 다시 그리는 일이 시작된 셈이다. WMS와 외부 결재 시스템 같은 주변 인터페이스도 같은 줄 위에 올라온다. PCE는 사내가 아니라 SAP 데이터센터에 있기 때문에, 네트워크·권한·연결 모델 자체가 새 변수가 된다. Configuration의 자유도가 줄어든다 PCE는 클라우드 옷을 입은 On-Prem이 아니다. On-Prem SAP에서는 클라이언트가 Configuration을 비교적 자유롭게 잡았다. RZ010(설정값 리스트)을 뽑아보면, 회사마다 수년간 누적된 커스텀 설정이 수백 줄씩 나오는 게 보통이...
자세한 내용 보기

SAP QM 검사로트 일괄합격 일탈 — CSV가 놓친 한 가지

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