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 카테고리가 어떻게 새로운 결정 영역을 여는지의 이야기다.
댓글
댓글 쓰기