BTP Integration Suite 첫 통합 — 3가지 시행착오

12편에서 CBO를 BTP로 옮기는 진짜 비용이 4가지 카테고리에서 발생한다고 짚었다. 그 비용 위에 본격 시행착오가 쌓이는 첫 자리가 BTP Integration Suite다. 13편은 PCE에서 BTP로 통합을 옮길 때 그룹사가 흔히 마주하는 3가지 시행착오 함정을 정리한다. 이 글은 진행 중인 시행착오 자료가 누적되기 전에 작성된 예상 패턴 글이다 — 시리즈 5·6·12편 자료와 일반 컨설팅 경험을 기반으로 했고, 실제 시행착오 발생 시 보완 글을 따로 낸다.

CPI 시행착오 — 그대로 옮기기의 함정

기존 PI/PO의 iFlow를 그대로 옮기면 BTP의 장점을 절반쯤 놓친다.

그룹사가 가장 흔히 가는 길은 단순하다 — 기존 SAP PI/PO 위에서 만든 iFlow(인터페이스 흐름)를 BTP CPI(Cloud Platform Integration)로 1:1 마이그레이션. 빠르고 익숙하다. 그러나 이 그대로 옮기기는 두 가지 전제를 깬다. 첫째, On-Prem PI는 사내 네트워크 위에서 동작했고, 둘째, 동기 호출과 짧은 응답에 최적화돼 있었다.

BTP CPI는 인터넷 위에서 동작한다. 보안 모델은 mTLS·OAuth·Cloud Connector로 재설계되어야 하고, 메시지 처리는 분산 환경의 비동기가 더 자연스럽다. 그대로 옮기면 기존 iFlow에 잠복해 있던 가정이 운영에서 드러난다 — 6편의 일탈 사례와 같은 구조다. 환경 조건이 다른데 코드는 그대로다. CPI 첫 통합의 진짜 일은 마이그레이션이 아니라 재설계다. 어떤 iFlow가 1:1로 옮겨도 되고, 어떤 iFlow가 Cloud Native 패턴으로 재설계되어야 하는지의 분류가 시작 단계에 끝나 있어야 한다. 분류 없이 옮기면 통합 테스트가 환경 차이에서 실패한다.

API Management 시행착오 — 노출 분류가 늦어지는 함정

API Management는 도구가 아니라 분류 결정이다.

API Management의 본질은 게이트웨이·정책 도구가 아니라 경계 짓기다 — 어떤 API를 누구에게 어떤 정책으로 노출할 것인가. 이 분류가 시작 단계에 끝나지 않으면 두 가지 함정 중 하나에 빠진다. 함정 1, 일단 다 내부용으로 깔고 외부 노출은 나중에 — 외부 파트너 요청이 들어오면 부랴부랴 게이트웨이 정책을 재설계해야 하고, 그 사이 비공식 노출 경로가 만들어진다. 함정 2, 일단 다 외부 노출 가능으로 깔고 — 보안 사고의 위험이 누적된다.

해법은 단순하다 — 분류부터다. 내부 전용, 파트너 노출, 공개 노출의 3분류를 시작 단계에 정해두고, 각 분류마다 정책(Rate Limit, OAuth, Spike Arrest)을 기본값으로 깔아둔다. 노출 분류는 통합 전에 끝나야 운영에서 깨지지 않는다. 이 분류는 7편의 Fiori Role 설계와 같은 패턴이다 — 권한이 곧 누가 무엇을 보는가의 명단이듯, API 노출 분류는 어떤 시스템이 어떤 데이터를 본다의 명단이다. 늦은 분류는 후처리 비용이 된다.

Event Mesh 시행착오 — Pub-Sub 패러다임의 늦은 깨달음

Event Mesh는 새 도구가 아니라 새 패러다임이다.

Event Mesh는 PCE 안의 표준 인터페이스(요청-응답, 폴링)와 다른 Pub-Sub 패러다임 위에서 작동한다. 발행자(Publisher)가 이벤트를 던지면 구독자(Subscriber)가 비동기로 받는다. 발행자는 누가 받는지 모르고, 구독자도 발행자에 의존하지 않는다. 이 분리가 통합 아키텍처에 유연성을 주지만, 기존 P2P 패턴을 그대로 올리면 모순이 발생한다.

흔한 시행착오 — 이벤트를 발행하고 응답을 기다리는 구조. 이건 Event Mesh의 본질을 깨는 패턴이다. 발행 즉시 비동기로 처리되어야 하는 이벤트가 동기 응답을 기다리면, 시스템 전체가 Pub-Sub의 모양은 가졌으나 P2P처럼 작동하는 어색한 상태에 빠진다. 핵심 결정은 단순하다 — 어떤 통합을 이벤트로 풀고, 어떤 통합을 P2P로 남길 것인가. 5편의 BW 동기화 분류와 같은 구조다 — 데이터·메시지의 성격에 따라 도구가 달라진다. Event Mesh를 도입한다는 것은 통합 아키텍처를 다시 그리는 결정이다 — 기존 인터페이스 인벤토리를 동기/비동기로 재분류하고, 어디까지 비동기로 가는지를 시작 단계에 정해두지 않으면, 운영 단계에서 어색한 동작이 누적된다.

영역시행착오의 본질해법
CPI1:1 마이그레이션의 환경 가정재설계 vs 재구현 분류 (시작 단계)
API Management노출 분류가 늦어짐내부·파트너·공개 3분류 + 정책 기본값
Event MeshP2P 패턴을 Pub-Sub에 올림동기·비동기 인벤토리 재분류

한 줄로

Integration Suite는 도구가 아니라 재설계 결정 3가지다. 그대로 옮기지 말 것(CPI), 미리 분류할 것(API 노출), 다시 그릴 것(Event Mesh 패러다임) — 셋 모두 시작 단계에 결정되어야 운영에서 깨지지 않는다. 시즌 1과 시즌 2의 메시지가 한 줄로 모이는 자리이기도 하다 — 결정의 무게는 결정 시점에 정해진다. 14편에서 같은 본질이 BTP 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차 테스트로 구성된다. 이 단계의 핵심은 운영에서 발생할 모든 시나리오를 ...
자세한 내용 보기