SAP Integration Suite: 의사결정과 운영 환경의 트레이드오프

SAP Integration Suite는 SAP BTP 위의 SAP 통합 플랫폼입니다. Cloud Integration(이전의 CPI)에 API Management, Event Mesh, Integration Advisor, Open Connectors, 그리고 PI/PO에서 이전하기 위한 도구가 더해집니다. S/4HANA 클라우드 프로젝트의 기본 미들웨어이자 PI/PO에서 벗어나는 경로이며, PI/PO의 표준 유지보수는 2027년에 끝납니다. 인터페이스 지연은 기술에서 비롯되는 경우가 드뭅니다. 불분명한 오너십, 레거시 시스템에 대한 검증되지 않은 가정, 실패를 찾아내기보다 통과하도록 설계된 테스트에서 비롯됩니다. 이 가이드는 통합 리드, 아키텍트, 프로그램 매니저를 위한 것입니다. 각 구성 요소의 용도, 표준 콘텐츠와 커스텀 개발, PI/PO 마이그레이션, 레거시와 테스트 리스크, Go-Live 후 거버넌스를 다룹니다.

PI/PO는 시한이 정해져 있습니다. SAP Process Integration과 Process Orchestration 7.5는 2027년 말까지 표준 유지보수 대상입니다. 선택적 연장 유지보수는 2030년 말까지 이어지며, 그 이후에는 SAP 지원이 끝납니다. SAP의 마이그레이션 레퍼런스 아키텍처가 경로를 설명합니다. Integration Suite에는 PI/PO 시나리오별 규모를 산정하는 Migration Assessment 애플리케이션과, Cloud Integration의 마법사 기반 마이그레이션 도구가 들어 있습니다. 웨이브로 나눠 이전하십시오. 위험이 낮은 SAP 간 플로를 먼저, B2B와 EDI를 중간에, 대용량 주문 플로를 마지막에 둡니다. 마감 압박 속의 강제 전환은 더 오래 걸리고 비용도 더 듭니다.

1. 웨이브 1위험이 낮은 SAP 간 플로Migration Assessment로 모든 시나리오 규모를 먼저 산정
2. 웨이브 2B2B와 EDI
3. 웨이브 3대용량 주문 플로
4. 2027PI/PO 7.5 표준 유지보수 종료연말. 이 시점 전에 끝나도록 웨이브를 계획
5. 2030선택적 연장 유지보수 종료연말. 이후 SAP 지원 종료

출처: SAP 유지보수 일정 및 마이그레이션 레퍼런스 아키텍처, 2026년 10월 확인

클라우드 계약이 무엇을 포함하는지 확인하십시오. RISE와 GROW 계약에는 보통 Integration Suite 비용을 충당할 수 있는 SAP BTP 크레딧이 포함됩니다. Integration Suite를 MuleSoft나 Boomi와 기능만으로 비교하기 전에, 사용 권한이 어떤 에디션과 메시지 볼륨을 포함하는지 확인하십시오. 포함된 플랫폼의 경제성은 비교 결과를 바꿉니다.

AI는 단계적으로 도입되고 있습니다. Cloud Integration은 2024년 중반부터 Premium 에디션에서 생성형 AI 플로 생성을 제공해 왔습니다. 이것이 만드는 것은 iFlow의 구조(단계, 채널, 예외 서브프로세스)이지 매핑이나 스크립트가 아닙니다. 2026년 3월에 출시된 SAP의 enhanced 에디션은 텍스트 기반 플로 생성과 스크립트 최적화를 더했고, SAP는 Integration Suite의 Joule을 2026년 3분기에 정식 출시할 계획이었습니다. 표준 플로에는 쓸 만합니다. 깊은 비즈니스 로직이 들어간 복잡한 오케스트레이션에는 여전히 시니어 아키텍트가 필요합니다.

Integration Suite는 서비스의 집합입니다. 작업에 맞는 서비스를 쓰는 것이 환경이 얼마나 오래 버티는지를 좌우합니다.

구성 요소	역할	잘못 쓰면 생기는 일
Cloud Integration(CPI)	메시지 플로, 라우팅, 변환. 대부분의 iFlow의 기본 선택	API와 이벤트까지 모두 CPI에 몰아넣으면 지원하기도 테스트하기도 어려워짐
API Management	보안, 호출 한도, 분석 등 API 노출을 통제	건너뛰면 점대점 호출이 늘어나고, 나중에 거버넌스를 덧붙이기 어려움
Event Mesh	분리된 트리거를 위한 비동기 메시징	추적되지 않는 큐가 아무도 모르게 쌓임
Integration Advisor	EDIFACT, X12, IDoc 같은 B2B 포맷의 매핑 제안	팀이 높은 커버리지를 가정함. 한 팀은 80%를 기대했지만 40%에 가까웠음
Open Connectors	서드파티 클라우드 앱용 사전 구축 커넥터	누군가 모니터링하지 않으면 외부 API 변경이 커넥터를 소리 없이 깨뜨림
Migration Assessment와 도구	PI/PO 시나리오의 규모 산정과 마이그레이션	실제 마이그레이션 계획이 아니라 일회성 견적으로 취급됨

Integration Suite를 "애드온이 붙은 CPI"로 보는 팀은 API Management와 Event Mesh를 무시하는 경우가 많습니다. 복잡도가 따라잡기 전까지는 그래도 됩니다. 제 SAP CPI 가이드에서 Cloud Integration 자체를 더 깊이 다룹니다.

사전 구축된 SAP 통합 콘텐츠는 프로세스가 표준일 때 정말 유용합니다. 표준 프로세스로 S/4HANA를 SAP Ariba나 SuccessFactors에 연결하는 것은 깔끔하게 맞는 경우가 많습니다. 실제 프로세스는 SAP의 레퍼런스 경계 안에 머무는 경우가 드뭅니다.

표준 콘텐츠를 선택하는 경우는 다음과 같습니다.

1. 시나리오가 SAP 간 연동이며 SAP의 레퍼런스 프로세스에 가깝다
2. 플로가 단순하고 대부분 단방향이다
3. SAP의 매핑을 그대로 받아들이고 제공되는 확장 지점으로만 확장할 수 있다

커스텀 개발을 선택하는 경우는 다음과 같습니다.

1. 수년간의 내부 결정으로 프로세스가 SAP의 모델에서 멀어졌다
2. 조건부 라우팅, 다단계 로직, 레거시의 특이 동작이 관련된다
3. 대폭적인 수정이 표준 패키지에 대한 SAP의 지원 정합성을 깨뜨릴 수 있다

블루프린트 단계에서 결정하십시오. 결정이 늦어지면 팀은 프로젝트 중반에야 "표준" iFlow가 지원 정합성을 잃을 만큼 대폭 수정되었다는 것을 발견하고, Go-Live 압박 속에서 다시 만듭니다. 표준 콘텐츠가 맞춤형 마스터 데이터 구조, 추가 필드, 레거시 인증을 한꺼번에 흡수하리라 가정해서 몇 주를 잃는 프로젝트를 보았습니다. 흡수하지 못했습니다. 설계 단계에서 했어야 할 분석이 UAT 중에 이루어졌습니다.

대규모 SAP 프로젝트에서 통합은 워크스트림 사이에 가장 먼저 떨어지는 일인 경우가 많습니다. 인터페이스는 팀 경계를 넘나드는데, 조율을 맡은 사람이 없습니다. 두 프로젝트 팀이 같은 비즈니스 파트너를 대상으로, 같은 엔드포인트를 가리키는 별도의 통합을 서로 모른 채 만든 것을 보았습니다. 둘 다 UAT까지 알지 못했습니다. 그것은 기술의 실패가 아니라 구조의 실패입니다.

중앙 통합 거버넌스를 일찍 세우십시오.

1. 모든 워크스트림이 볼 수 있는 공유 통합 백로그
2. 인터페이스마다 지정된 오너, 딜리버리 내내 추적
3. 주요 배포 전 워크스트림 간 조율 체크포인트
4. Go-Live를 약속하기 전에 인터페이스 의존성 점검, 공유 엔드포인트와 큐는 컷오버 계획에 순서를 정해 반영
5. 환경 간 자동 배포, 랜드스케이프별 자격 증명 문서화

가장 어려운 통합 문제는 최신 플랫폼에서 나오는 경우가 드뭅니다. 핵심 프로세스 한가운데에 있는 오래된 시스템에서 나옵니다.

레거시 ERP는 동시 동기 호출을 처리하지 못하는 경우가 많습니다. 병렬 API 호출을 다섯 개 보내면 서버가 느려지거나, 멈추거나, 데이터를 소리 없이 떨어뜨립니다. 비동기 통합은 수신 시스템이 큐를 처리할 수 있을 때만 도움이 되는데, 많은 시스템이 그러지 못합니다.

프로토콜 불일치는 흔하고 늦게 발견됩니다. 설계는 OAuth2와 REST로 했는데, 레거시 시스템은 30초 하드코딩 타임아웃의 SOAP를 쓰고 토큰 갱신을 제대로 처리하지 못합니다.

한 고객 사례에서는 서드파티 급여 시스템이 발급한 토큰이 매주 만료되어, 미들웨어 플로가 매주 금요일마다 실패했습니다. 두 번째 UAT 사이클까지 아무도 알아차리지 못했습니다. 이런 특이 동작은 흔하고, 일정을 갉아먹습니다.

표는 설계 동결 전에 점검할 리스크를 정리한 것입니다.

리스크	흔한 문제	설계 시 할 일
동기 호출 한계	병렬 호출에서 레거시가 잠김	비동기 메시징 사용. Event Mesh나 Cloud Integration으로 호출 간격 분산
프로토콜 불일치	레거시가 REST나 OAuth를 거부하거나 SOAP에서 타임아웃	설계 시작 전에 프로토콜과 타임아웃 확인
API 호출 한도	배치 작업이 서드파티 스로틀링을 초과	API Management에서 호출 제한. iFlow에 대기 로직 추가
토큰 만료	한가한 시간대에 플로가 소리 없이 실패	갱신 주기를 일정에 반영하고 만료를 모니터링
경직된 포맷	동적 페이로드가 레거시 파싱을 깨뜨림	실제 운영 환경 샘플로 검증
폴백 부재	파일 전송이 재시도 없이 실패해 데이터가 갇힘	미들웨어에서 버퍼링. iFlow에 재시도와 알림 구축

이 문제들의 클라우드 간 버전은 제 글 ERP와 Salesforce의 통합이 실패하는 이유와 해결법을 보십시오.

통합은 기능 테스트가 확인하는 방식으로 깨지지 않습니다. 타이밍 압박 아래에서, 백그라운드 잡이 겹칠 때, 입력이 하나씩이 아니라 대량으로 들어올 때 실패합니다. 기능 테스트는 트랜잭션이 전기되고 메시지가 로그에 나타난다는 것을 증명합니다. 첫 급여 실행이 IDoc을 한꺼번에 쏟아낼 때 무슨 일이 벌어지는지는 증명하지 못합니다. 한 프로젝트에서는 시스템 통합 테스트에서 깨끗해 보였던 IDoc이 실제 급여 볼륨이 들어오자 큐를 멈춰 세웠습니다. 부하 테스트만이 이를 찾아냈습니다.

인터페이스 테스트는 다음을 다뤄야 합니다.

1. 동시 사용자가 있는 현실적인 데이터 볼륨
2. 서비스 중단과 복구 동작
3. 미들웨어와 백엔드 전반의 타임아웃과 재시도
4. 실시간 호출과 함께 실행되는 배치 잡
5. 월 마감과 기타 피크 기간

개발 환경은 깨끗합니다. 교착 상태, 경쟁 상태, 스로틀링은 다른 시스템과 배치 윈도가 실제로 돌아가는 UAT와 프리프로덕션에서 나타나므로, 부하 테스트는 거기서 하십시오. 책임은 분명히 나누십시오. 기능 팀은 전체 플로에 걸친 비즈니스 결과를 검증하고, 통합 팀은 로그, 재시도, 예외 플로를 맡고, 프로젝트 리드는 커버리지를 확인합니다. 제 SAP 성능 테스트 가이드에서 부하 측면을 다룹니다.

Integration Advisor는 정형 B2B 포맷의 매핑을 제안합니다. 엄격한 규약을 따르는 파트너에게는 실제로 설정 시간을 줄여 줍니다. 레거시 시스템, 커스텀 필드, 조건부 로직, 문서화되지 않은 규칙이 있는 엔터프라이즈 통합에서는 출발점일 뿐입니다.

제가 함께 일한 한 팀은 매핑 커버리지 80%를 기대했습니다. 실제 커버리지는 약 40%였습니다. 나머지는 커스터마이징하고, 비즈니스와 검증하고, 수작업으로 테스트해야 했습니다.

수년에 걸쳐 비공식적으로 쌓인 비즈니스 로직(지급 조건, 가격 카테고리, 단위 관례), 비즈니스 맥락에 따른 조건부 규칙, 표준 포맷 밖의 예외는 해결해 주지 못합니다. 이런 것에는 기능 쪽 입력이 필요합니다. 그것이 없으면 인터페이스는 기술적으로는 매핑되었지만 특정한 경우에 논리적으로는 틀립니다.

Go-Live 이후 문서가 어긋나고 오너십이 공식화되지 않으면 통합은 열화됩니다. 쓸모 있는 문서는 필드 매핑과 변환 로직, 그리고 엔드포인트, 토큰 갱신, 자격 증명 교체 같은 인증 세부 사항을 다룹니다. 또한 오류 처리, 폴백 규칙, 월 마감과 급여 같은 중요 시기의 볼륨 예상도 다룹니다. 시험해 볼 기준은 이렇습니다. 다음 주에 지원팀에 합류한 사람이 문서만으로 장애가 난 인터페이스를 문제 해결할 수 있는가?

인터페이스는 볼륨이 적더라도 모니터링, 에스컬레이션, 라이프사이클 변경을 맡을 지정된 오너가 필요합니다. 오너가 없으면 비즈니스가 기다리는 동안 장애가 Basis, 미들웨어, 기능 팀 사이를 오갑니다. 하이퍼케어 이후에는 모니터링이 흐지부지되기 쉽습니다. 정기적인 오류 로그 리뷰, 프로젝트에서 지원 조직으로의 공식 인수인계, 비즈니스와 IT가 합의한 서비스 수준을 갖추십시오. 방치된 통합은 Go-Live 몇 주 뒤에 불거지는 전기 지연, 누락된 송장, 어긋난 재무 보고서의 많은 부분 뒤에 있습니다.

SAP Integration Suite란 무엇이며 CPI와 어떻게 다릅니까?

이전에 SAP Cloud Platform Integration(CPI)이라 불리던 Cloud Integration은 Integration Suite 안의 한 기능입니다. 이 스위트는 통제된 API 노출을 위한 API Management와 비동기 메시징을 위한 Event Mesh를 더합니다. B2B 매핑 제안을 위한 Integration Advisor, 서드파티 클라우드 앱을 위한 Open Connectors, PI/PO를 위한 평가 및 마이그레이션 도구도 포함합니다. 이름만 바뀐 CPI로 보는 팀은 API Management와 Event Mesh를 건너뛰는 경우가 많고, 나중에 거버넌스 공백으로 대가를 치릅니다.

SAP PI/PO 지원은 언제 끝납니까?

SAP Process Integration과 Process Orchestration 7.5는 2027년 말까지 표준 유지보수 대상입니다. 고객은 2030년 말까지 선택적 연장 유지보수를 받을 수 있으며, 그 이후에는 SAP 지원이 끝납니다. Integration Suite에는 시나리오별 규모를 산정하는 Migration Assessment 애플리케이션과 아티팩트를 반자동으로 옮기는 마이그레이션 도구가 들어 있습니다. 기한을 기다리지 말고 웨이브 계획부터 세우십시오.

SAP 통합에서 표준 콘텐츠와 커스텀 개발은 언제 써야 합니까?

시나리오가 SAP 간 연동이고, SAP의 레퍼런스 프로세스에 가깝고, 비교적 단순할 때 표준 콘텐츠를 쓰십시오. 프로세스가 SAP의 모델에서 벗어났거나, 레거시의 특이 동작을 별도로 처리해야 하거나, 조건부 및 다단계 로직 때문에 표준 패키지를 크게 바꿔야 할 때는 커스텀으로 구축하십시오. 블루프린트 단계에서 결정하십시오. 지나치게 수정된 표준 플로를 Go-Live 압박 속에서 다시 만드는 것은 처음부터 깨끗하게 커스텀으로 만드는 것보다 비용이 더 듭니다.

복잡한 프로그램에서 SAP 통합 장애의 원인은 무엇입니까?

대부분 구조적 원인입니다. 모니터링과 오류 해결의 지정된 오너가 없어서 장애가 팀 사이를 오갑니다. 두 워크스트림이 서로 모른 채 엔드포인트나 큐를 공유하는 통합을 만듭니다. 동시 호출을 받지 못하는 레거시 시스템이 부하 상황에서야 발견됩니다. 그리고 따로 돌리면 깨끗하게 통과하지만 배치 중첩이나 피크 볼륨은 한 번도 시뮬레이션하지 않는 테스트입니다.

SAP Integration Suite의 통합 테스트는 어떻게 구성해야 합니까?

기능 테스트를 넘어, 첫 월 마감이나 급여 실행 같은 현실적인 볼륨을 다루십시오. 실시간 인터페이스와 함께 돌아가는 배치 잡, 다운스트림 시스템을 쓸 수 없을 때의 복구, 대량 작업 중 서드파티 호출 한도를 테스트하십시오. 부하 및 성능 테스트는 운영 환경과 비슷한 환경에서 실행하십시오. 깨끗한 개발 시스템은 문제를 가려 버리기 때문입니다.

Go-Live 이후 SAP 통합은 어떻게 거버넌스해야 합니까?

모든 인터페이스에 모니터링, 에스컬레이션, 변경을 맡을 지정된 오너를 두십시오. 매핑, 인증과 자격 증명 교체, 오류 처리, 볼륨 예상 같은 문서를 최신으로 유지하십시오. 그리고 정기적인 오류 로그 리뷰, 프로젝트에서 지원 조직으로의 공식 인수인계, 합의된 서비스 수준을 갖춘 장기 지원 모델을 만드십시오. 눈에 띄지 않게 된 통합은 방치됩니다.