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 첫 개발 사이클의 함정.
댓글
댓글 쓰기