BTP 사이드카 본격 도입 첫 100일 — 셋업·사이클·안착 예상 가이드

 

14편에서 BTP CAP 첫 사이클의 세 함정을 짚었고, 18편에서 PCE Configuration 운용 4단계를 정리했다. 19편은 그 둘이 만나는 자리, PCE가 Clean Core로 굳혀진 후에 BTP 사이드카가 그 위에 올라갈 100일의 시간선이다. 이 글은 13·14편과 같은 자료 누적형 예상 가이드 글이다. 작가의 일반 컨설팅 경험과 시리즈 14·18편 자료를 기반으로, PCE 운영을 안착시킨 그룹사가 마주할 100일을 셋업 → 사이클 → 안착의 세 단계로 미리 정리한다. 실제 100일이 진행되면 케이스 보강 글을 따로 올리려 한다.

D+1 ~ D+7 — 첫 주: 셋업과 첫 코드

첫 주에는 코드가 아니라 환경이 일이 된다. BTP 구독을 활성화하고, Cloud Foundry 또는 Kyma 공간을 dev·test·prod로 분리하고, 14편에서 결정한 언어(Node.js 또는 Java) 런타임을 깔고, Cloud Connector로 PCE와 BTP를 연결한다. 이 셋업 자체가 작은 프로젝트가 된다. 환경 분리, 권한 모델, 인증서 관리, 네트워크 경로가 모두 처음 잡힌다.

첫 코드는 비즈니스 가치가 없어야 한다. CAP의 표준 템플릿으로 Hello World 수준의 OData 서비스를 띄우고, PCE의 표준 OData를 Cloud Connector를 통해 호출해보는 단계다. 이 셋업이 끝나면 PCE와 BTP가 서로 통신할 수 있는 상태가 확인된다. 첫 주의 가장 흔히 예상되는 함정은 Cloud Connector 셋업 누락이다. 빠진 채로 첫 코드를 짜면 PCE 호출이 모두 timeout으로 떨어지고, 디버깅이 환경 문제인지 코드 문제인지 구분이 안 되는 상태에 빠질 수 있다. 첫 주는 조용히 통신만 확인하면 성공이다.

D+8 ~ D+30 — 첫 달: 첫 사이클 완성

첫 주가 끝나면 진짜 첫 사이드카를 만들어볼 수 있다. 비즈니스 가치를 가진 하나의 작은 기능, 예를 들어 고객 마스터의 자체 필드 추가 같은 경계가 분명한 한 줄짜리 사이드카가 출발점으로 적합하다. CDS로 데이터 모델을 정의하고, OData 서비스로 노출하고, 필요하면 Fiori Elements나 React로 UI를 얹는 흐름이다. 작은 단위로 시작하는 것이 핵심이다. 첫 사이드카가 크면 디버깅이 환경·인증·데이터·UI 어디서 깨졌는지 추적이 어려워진다.

14편의 CDS 모델 함정이 이 단계에 정확히 작동할 영역이다. PCE의 표준 객체를 그대로 옮기지 않고 자체 모델을 정의하는 결정이 필요하다. 같은 단계에 CI/CD 파이프라인을 작동하는 형태로 굳히는 작업도 함께 간다. Git push → Build → Test → Deploy가 5~10분 안에 끝나는 흐름이 안정되면 첫 달의 절반은 성공한 셈이 된다. 첫 달의 핵심은 짧은 배포 사이클의 확립이다. 9편 Hyper Care의 일별 리뷰에 BTP 사이드카 항목을 추가해 PCE 운영과 같은 호흡으로 모니터링하는 흐름이 권장된다.

D+31 ~ D+100 — 안착: 패턴 굳히기

첫 달이 안정되면 두 번째·세 번째 사이드카가 들어오는 단계다. 이 단계의 핵심은 공통 패턴 발견에 있다. 인증 모듈, 로깅 모듈, PCE 호출 공통 함수, 에러 처리 패턴. 첫 사이드카에서 작성된 코드 중 재사용 가능한 부분을 공유 라이브러리로 분리하는 작업이 필요하다. 이 분리가 일어나야 사이드카 수가 늘어날 때 코드 복사가 누적되지 않는다.

12편에서 본 옮긴 CBO 수가 늘면 비용이 비선형으로 증가하는 위험이 이 단계에서 통제 대상이 된다. 공통 패턴이 공유 자산으로 굳혀지면 세 번째 사이드카는 첫 사이드카보다 훨씬 가볍게 만들어질 수 있다. 세 번째 사이드카가 첫 사이드카보다 가볍지 않다면, 공통 패턴 추출이 늦은 상태로 봐야 한다. 100일째 회고에는 첫 사이드카가 제값을 하는가도 함께 점검 대상이 된다. 비즈니스 가치 vs 운영 비용이 비교 가능한 형태로 측정되어야 한다. 측정이 없으면 왜 BTP로 옮겼는지가 한 분기 후 흐려지고, 의사결정자가 다음 사이드카 승인을 망설이게 된다.

한 줄로

BTP 사이드카 첫 100일의 본질은 패턴 굳히기가 될 것이다. 첫 주는 환경, 첫 달은 사이클, 나머지 70일은 공통 자산 추출. 세 단계가 굴러가면 세 번째 사이드카부터 가벼워지는 흐름이 만들어지고, 그 흐름이 시즌 2의 12편 비용 메시지를 실제로 통제하는 자리가 된다. 본 글은 진행 전 예상 가이드이고, 실제 100일이 흐른 후의 케이스는 별도 글로 보강할 예정이다. 20편에서 시즌 2.5의 마지막 편, SAP Joule과 Generative AI in SAP를 다룬다. BTP 위에서 AI 카테고리가 어떻게 새로운 결정 영역을 여는지의 이야기다.