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를 도입한다는 것은 통합 아키텍처를 다시 그리는 결정이다. 기존 인터페이스 인벤토리를 동기/비동기로 재분류하고, 어디까지 비동기로 가는지를 시작 단계에 정해두지 않으면, 운영 단계에서 어색한 동작이 누적된다.
| 영역 | 시행착오의 본질 | 해법 |
|---|---|---|
| CPI | 1:1 마이그레이션의 환경 가정 | 재설계 vs 재구현 분류 (시작 단계) |
| API Management | 노출 분류가 늦어짐 | 내부·파트너·공개 3분류 + 정책 기본값 |
| Event Mesh | P2P 패턴을 Pub-Sub에 올림 | 동기·비동기 인벤토리 재분류 |
한 줄로
Integration Suite는 도구가 아니라 재설계 결정 3가지다. 그대로 옮기지 말 것(CPI), 미리 분류할 것(API 노출), 다시 그릴 것(Event Mesh 패러다임) 셋 모두 시작 단계에 결정되어야 운영에서 깨지지 않는다. 시즌 1과 시즌 2의 메시지가 한 줄로 모이는 자리이기도 하다. 결정의 무게는 결정 시점에 정해진다. 14편에서 같은 본질이 BTP CAP 첫 개발 사이클에서 어떻게 작동하는지 본다.
댓글
댓글 쓰기