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의 데이터 모델을 그대로 가져오면 CDS의 의미가 사라진다.

CDS는 CAP의 데이터 모델링 핵심이다. 엔티티·관계·뷰를 정의하고, 이 정의가 그대로 OData 서비스로 노출된다. CAP 첫 사이클에서 흔한 함정은 PCE 안의 SAP 표준 객체를 그대로 CDS로 옮기는 것이다. 같은 BUT(Business Partner Table) 구조를 그대로, 같은 키와 관계를 그대로. 이건 Side-by-Side로 옮길 이유 자체를 부정하는 결정이다.

10편과 12편에서 Side-by-Side로 가야 하는 이유 셋 중 하나는 자체 데이터 누적이었다. CAP의 CDS는 정확히 그 자리를 위한 도구다. 회사가 PCE의 표준 객체와 다른 자체 모델을 정의하고, 자체 데이터를 누적하고, PCE와는 API로만 주고받는 구조. 이 구조 위에서 CDS의 가치가 살아난다. 그대로 가져오면 BTP 안에 PCE의 그림자가 만들어지고, 운영 비용은 두 배가 되며, Side-by-Side의 분리 효과가 사라진다. CAP 첫 사이클의 핵심 결정은 어떤 데이터를 PCE에 두고 어떤 데이터를 CDS로 정의할 것인가다. 이 분리가 시작 단계에 끝나야 한 사이클이 재설계로 빠지지 않는다.

운영 모델 함정 Cloud Native CI/CD의 분리

PCE의 transport와 BTP의 CI/CD는 다른 종류의 흐름이다.

PCE 운영 경험이 깊은 팀이 CAP 첫 사이클을 시작할 때 자주 빠지는 함정이 Cloud Native 운영 모델을 가볍게 보는 것이다. PCE의 객체 이관은 CTS(Change and Transport System) 기반으로 순서대로 진행된다. BTP의 CAP 배포는 다르다.  Cloud Foundry나 Kyma 위에서 컨테이너 배포가 작동하고, CI/CD 파이프라인(Git → Build → Test → Deploy)이 분산 환경에서 굴러간다.

이 차이를 가볍게 보면 운영 단계에서 두 가지 비용이 누적된다. 첫째, 환경 분리가 어색해진다. PCE의 DEP·DEQ·DSP 같은 시스템 ID 모델과 BTP의 dev·test·prod 공간 모델이 서로 다른 추상화에서 작동하고, 두 시스템 사이의 환경 매칭이 수작업이 된다. 둘째, 배포 빈도가 떨어진다. 매번 transport 메뉴얼대로 배포하려는 관성이 BTP의 짧고 잦은 배포 가치를 깨버린다. CAP 첫 사이클에서 CI/CD를 PCE의 관성으로 짜면, BTP가 제값을 못 하는 운영에 들어간다. 12편의 운영 비용이 비례 이상으로 누적되는 자리이기도 하다.

결정	함정	시작 단계 결정
언어 선택	ABAP 관성 → Java 관성 → 학습 미완 운영	팀 역량 × Cloud Native 적합도
CDS 데이터 모델	PCE 모델을 그대로 가져옴	어떤 데이터를 PCE에 두고 어떤 데이터를 CDS로
CI/CD 운영	PCE transport의 관성	Cloud Native 파이프라인 + 짧고 잦은 배포

한 줄로

CAP 첫 개발 사이클의 함정은 기술이 아니라 PCE의 관성에서 시작된다. 언어, 데이터, 운영 모델 셋 모두 PCE와 다른 본질을 가진다. 첫 사이클에서 이 본질을 결정으로 받아들이면 두 번째 사이클부터는 가볍다. 받아들이지 않으면 매 사이클마다 PCE의 그림자를 BTP에서 다시 만들게 된다. 시즌 1·2의 마지막 편(15편)에서 BTP 1차 회고와 2026 SAP 동향을 묶어 시리즈를 마친다.