SAP 통합 플랫폼: 도구, 라이선스, 시나리오

SAP를 더 넓은 시스템 환경에 통합하는 일은 몇 조각이 도무지 맞지 않는 퍼즐을 푸는 것처럼 느껴질 수 있습니다. 서로 다른 도구, 플랫폼, 데이터 형식이 모두 주목을 받으려 경쟁합니다. 통합 옵션이 이렇게 많고, SAP Integration Suite도 그중 하나이며 저마다 자신이 가장 적합하다고 주장하면 막막할 수밖에 없습니다. 팀이 몇 주 동안 플랫폼을 비교하고 나서야 라이선스 영향이나 부하 시 시스템 지연처럼 기본적인 것을 놓쳤다는 사실을 깨닫는 모습을 본 적이 있습니다.

그래서 이 페이지는 상황을 더 분명하게 정리하려 합니다. 완벽하게 분명하지는 않을 수 있지만, 확신을 가지고 선택할 수 있을 만큼은 분명하게 말입니다. SAP 통합 플랫폼을 실무 관점에서 살펴봅니다.

실제로 서로 잘 어울리는 도구
간접 라이선싱이 발목을 잡을 수 있는 지점
SAP Integration Suite, CPI, PI, BTP를 실제로 비교하면 어떻게 다른가
SAP 자체 도구보다 서드파티 도구가 더 합리적인 경우

모든 프로젝트에 통하는 단 하나의 답은 없습니다. 하지만 유스케이스가 확정되면 알맞은 통합 경로는 대개 분명해집니다. 적어도 그렇게 되기를 바랍니다.

1. SAP Integration Suite 소개

SAP 구축은 SAP를 설치하는 데 그치는 일이 드뭅니다. 대개는 레거시 시스템, 클라우드 앱, 데이터베이스, 기업이 수년간 의존해 온 각종 자체 개발 도구까지 SAP가 모든 것과 함께 작동하게 만드는 일입니다.

여기서 통합이 결정적인 역할을 합니다. 통합은 전체 환경을 하나로 묶어 줄 수도 있고, 무언가 깨지기 전까지 아무도 눈치채지 못하는 마찰을 조용히 일으킬 수도 있습니다.

현실에서 통합은 과소평가되기 쉽습니다. 팀은 기능, 프로세스 설계, 테스트에 집중합니다. 프로젝트 후반에 누군가 깨닫습니다.

핵심 데이터가 실시간으로 동기화되지 않는다는 사실
API 한도에 몇 주 전 이미 도달했다는 사실
간접 사용 때문에 라이선스 비용이 두 배가 되었다는 사실
선택한 미들웨어가 부하 시 물량을 감당하지 못한다는 사실

이런 문제는 처음에는 늘 눈에 띄지 않습니다. 그러나 결국 일정, 예산, 심지어 컴플라이언스에까지 영향을 줍니다.

이 페이지는 SAP Integration Suite를 그런 관점에서 살펴봅니다. 프로젝트 현장에서 실제로 어떻게 작동하는지, 어떤 문제를 해결하는지, 리스크가 어디에 숨어 있기 쉬운지를 다룹니다.

구축 평가 시작하기 SAP 통합

2. SAP 프로젝트의 일반적인 통합 시나리오

SAP 프로젝트는 대개 백지에서 시작하지 않습니다. 문서화가 잘된 것도 있고 거의 파악되지 않은 것도 있는, 기존 시스템들이 뒤섞인 상태에서 시작합니다. 통합은 이 모두를 정리해야 하며, 지연을 허용할 여유가 거의 없는 경우가 많습니다.

대부분의 환경에서 나타나는 패턴이 몇 가지 있습니다.

SAP와 비SAP 시스템의 연결. 여전히 쓰이는 레거시 ERP, CRM, 자체 개발 앱.
하이브리드 구성. 동기화를 유지하려는 클라우드 서비스와 온프레미스 시스템의 혼합.
실시간 흐름과 배치 흐름. 빠른 것도 좋지만 대개는 안정적인 쪽이 이깁니다.
API 중심과 미들웨어 기반. 상황에 따라 둘 다 쓰기도 합니다.

SAP Integration Suite 같은 도구는 특히 하이브리드나 클라우드 비중이 큰 환경에서 이런 패턴 상당수를 다루도록 설계되었습니다. 그러나 도구 자체는 해법의 일부일 뿐입니다.

SAP를 외부 플랫폼과 연결하는 일은 형식, 보안, 타이밍이 걸림돌이 되기 전까지는 간단하게 들립니다. 사소한 불일치 때문에 며칠씩 막혀 있는 팀을 본 적이 있습니다. 한쪽은 REST를 쓰는데, 다른 쪽은 플랫 파일을 고집합니다.

하이브리드 구성은 처음에는 유연해 보일 수 있습니다. 실제로는 예외들을 이어 붙인 누더기 위에 세워진 경우가 대부분입니다. 한 서비스는 데이터를 즉시 밀어 넣습니다. 다른 서비스는 여전히 야간 배치 작업에 의존합니다.

실시간 통합은 계획 단계에서 모두의 마음을 끕니다. 하지만 양쪽 시스템이 모두 감당할 수 있을 때만 작동합니다. 늘 그런 것은 아닙니다.

미들웨어는 구조를 제공하고, API는 속도를 제공합니다. 둘 중 무엇을 고를지는 선호보다 이미 갖춰진 것이 무엇인지, 팀이 현실적으로 운영할 수 있는 것이 무엇인지에 달려 있습니다.

고려해야 할 애플리케이션 간 통합 시나리오

1. SAP와 비SAP 통합

SAP는 Salesforce, Oracle, 산업 특화 도구 같은 플랫폼과 연결되어야 하는 경우가 많습니다. 이러한 통합은 핵심 업무 시스템과 프로세스 전반의 연속성을 보장합니다.

SAP와 서드파티 플랫폼 간의 구조화된 데이터 교환 지원
인증, 필드 매핑, 변환 계층 포함
SAP 롤아웃 중 기존 업무 워크플로 유지에 도움

2. 하이브리드 환경(온프레미스 / 클라우드)

대부분의 SAP 고객은 하이브리드 환경에서 운영합니다. 온프레미스 SAP 시스템이 클라우드 플랫폼과 공존하기 때문에, 데이터 일관성과 비즈니스 민첩성을 위해 통합이 필수입니다.

SAP ECC 또는 S/4HANA를 SuccessFactors, Ariba 같은 클라우드 제품과 연결
서로 다른 프로토콜과 보안 모델을 연결
지연과 동기화 문제를 피하려면 강력한 거버넌스 필요

3. 실시간 통합과 배치 통합

실시간 통합과 배치 통합 중 무엇을 고를지는 시스템 성능, 데이터 양, 업무 요구에 따라 달라집니다. 모든 프로세스가 즉각적인 데이터 동기화에서 똑같이 이익을 얻는 것은 아닙니다.

실시간은 주문 생성이나 재고 갱신 같은 트랜잭션에 적합
배치는 가격, 마스터 데이터, 이력 적재 같은 대용량 데이터셋에 적합
대부분의 환경은 프로세스의 중요도에 따라 둘 다 사용

4. API 기반 통합

API 기반 통합은 애플리케이션이 경량 프로토콜을 사용해 서로 직접 통신할 수 있게 해 줍니다. 클라우드 네이티브 서비스와 현대적 개발 환경에 잘 맞습니다.

SAP를 모바일 앱, 포털, 마이크로서비스와 연결하는 데 이상적
배포는 더 빠르지만 엄격한 버전 관리와 보안 처리가 필요
SAP API Management 및 OData 서비스와 함께 흔히 사용

5. 미들웨어 기반 통합

미들웨어는 SAP를 여러 시스템과 통합하기 위한 중앙 통제 지점을 더해 줍니다. 오케스트레이션, 메시지 큐잉, 데이터 변환을 통해 복잡성을 관리하도록 돕습니다.

여러 시스템이 SAP와 상호작용하는 환경에서 사용
중앙 집중식 모니터링과 오류 처리 제공
예: SAP PI/PO, SAP Integration Suite, MuleSoft, Dell Boomi

6. 혼합형 통합 방식

대부분의 기업은 API 전략과 미들웨어 전략을 함께 사용합니다. 이 하이브리드 모델은 시스템 제약, 팀의 역량, 장기 지원 요구에 맞춰 조정됩니다.

직접 통합과 관리형 통합 방식을 결합
향후 확장이나 도구 변경에 대한 유연성 제공
통합을 기술적 우선순위와 비즈니스 우선순위 모두에 맞추는 데 도움

3. SAP Integration Suite 개요

SAP 통합에서 알맞은 Integration Suite를 고르는 일은 대부분의 팀이 예상하는 것보다 더 중요합니다. 이 결정은 기능과 속도를 넘어섭니다. 일정, 지원 모델, 심지어 라이선스에까지 영향을 줄 수 있습니다. 통합이 실패해서가 아니라 플랫폼이 비즈니스 방식과 맞지 않아서 프로젝트가 막힌 경우를 본 적이 있습니다.

SAP는 여러 가지 통합 옵션을 제공합니다. 오래된 것도 있고 새로운 것도 있으며, 사람들이 생각하는 것보다 더 많이 겹치는 것도 있습니다. 어떤 도구를 쓸지를 두고 논쟁이 자주 벌어집니다. 물론 상황에 따라 다릅니다. 무엇을 연결하는지, 데이터가 어떻게 이동해야 하는지, 팀이 무엇을 아는지에 따라서입니다.

모든 것을 다 아우르는 도구는 없습니다. 각각 장단점이 있습니다. 하지만 각 도구가 어디에 가장 잘 맞는지 이해하면 큰 그림이 더 또렷해지기 시작합니다.

가장 널리 쓰이는 SAP 통합 플랫폼을, SAP가 홍보하는 방식이 아니라 실제 프로젝트에서 적용되는 방식을 기준으로 간단히 정리했습니다.

SAP 통합 플랫폼

1. SAP PI / PO (Process Integration / Orchestration)

PI/PO는 오랫동안 온프레미스 SAP 통합의 표준이었습니다. 메시지 변환, 워크플로, 다양한 프로토콜 변환을 처리합니다. 믿을 만하지만 변화가 잦은 환경에서는 다소 무겁게 느껴집니다. 그래도 복잡한 백엔드 로직을 다룰 때는 제 몫을 해냅니다.

SAP 간 통합과 레거시 통합에 적합
IDoc, BAPI, RFC, SOAP 등 지원
ECC 기반 또는 하이브리드 구성에서 자주 사용

2. SAP CPI / Integration Suite

SAP CPI는 더 유연하며, 클라우드 우선 환경과 하이브리드 환경을 위해 설계되었습니다. 특히 SAP에 처음인 팀도 시작하기 더 쉽습니다. 사전 구축된 iFlow가 도움이 되지만, 실제 맞춤화에는 여전히 시간이 걸립니다. 새로운 S/4HANA 프로젝트 대부분에서는 이것이 대개 기본 선택지입니다.

클라우드 및 하이브리드 통합 지원
재사용 가능한 콘텐츠 패키지와 어댑터 포함
SAP Integration Suite 라이선스 모델의 일부

3. SAP API Management

데이터를 실제로 옮기는 것보다 거버넌스에 더 초점을 둡니다. API Management는 누가, 어떤 조건에서, 무엇에 접근하는지를 통제하도록 돕습니다. 배송 차량보다는 정문에 가깝다고 생각하면 됩니다. 파트너나 내부 사용자에게 API를 공개할 때 유용합니다.

트래픽 제어, 스로틀링, 인증에 사용
SAP API를 외부 앱에 공개할 때 유용
CPI나 다른 백엔드 도구를 보완하는 경우가 많음

4. SAP BTP Integration Services

CPI, API Management, 이벤트 처리 등을 포함하는 더 넓은 우산 개념입니다. 도구를 관리하는 중앙 지점을 제공하지만, 도구 자체는 여전히 어느 정도 독립적으로 동작합니다. 가치는 이들을 묶어서 느슨하게나마 통합해 둔다는 데 있습니다.

여러 SAP 통합 구성 요소를 결합
SAP BTP 코크핏을 통한 중앙 집중식 접근
여러 도구를 쓰는 통합 환경에 유용

5. SAP Data Intelligence

Data Intelligence는 데이터가 구조화된 파이프라인으로 플랫폼 사이를 흘러야 할 때 쓰입니다. 트랜잭션보다는 분석에 가깝다고 보시면 됩니다. 일상적인 프로세스 흐름에 속하지 않는 데이터 레이크, ML 도구, 기타 외부 소스를 SAP와 연결합니다.

플랫폼 간 데이터 오케스트레이션에 집중
분석 및 머신러닝 스택과 통합
고빈도 트랜잭션이 아니라 데이터 파이프라인에 최적

6. 알맞은 도구 고르기

단 하나의 “최고” 플랫폼은 없습니다. 알맞은 도구는 무엇을 통합하는지, 통합의 규모가 어느 정도인지, 얼마나 유연성이 필요한지에 따라 달라집니다. 때로는 팀이 이미 익숙한 것이 무엇인지의 문제이기도 합니다. 그것도 중요합니다.

도구가 아니라 유스케이스에서 출발
라이선스, 인력 확보 가능성, 지원 모델을 평가
여러 도구를 병행해서 쓰는 경우가 많음

SAP와 함께 쓰이는 서드파티 통합 플랫폼

1. Dell Boomi

Dell Boomi는 빠른 배포와 재사용 가능한 통합이 필요한 조직에 잘 맞는 로우코드 클라우드 기반 플랫폼입니다. 사전 구축된 커넥터로 SAP에 연결되며, 실시간 워크플로와 배치 워크플로를 모두 효과적으로 처리합니다.

더 빠른 구현을 위한 로우코드 인터페이스
SAP를 클라우드 앱, CRM, 레거시 시스템과 연결
하이브리드 요구가 있는 중견 기업에 적합

2. MuleSoft

MuleSoft는 SAP를 넘어서는 대규모 통합 요구가 있는 기업에서 자주 쓰입니다. API 중심 연결성과 풍부한 개발자 경험을 제공합니다. SAP 커넥터는 강력하지만, 제대로 구성하려면 초기에 더 많은 노력이 필요할 수 있습니다.

유연한 서비스 설계를 위한 API 우선 모델
SAP를 더 넓은 엔터프라이즈 아키텍처에 통합할 때 사용
복잡하거나 분산된 시스템에 더 적합

3. Informatica

Informatica는 데이터 비중이 큰 환경에서 강점을 발휘합니다. ETL, 마스터 데이터 관리, 분석에 초점을 둔 통합에 자주 선택됩니다. SAP와의 직접 통합도 지원하지만, 대개 다른 플랫폼보다 실시간 지향성은 떨어집니다.

대용량 데이터 이동과 정제에 이상적
리포팅이나 MDM 유스케이스에서 SAP와 함께 쓰이는 경우가 많음
성숙한 BI 환경을 갖춘 조직에 적합

4. 서드파티 플랫폼을 쓰는 경우

SAP의 기본 도구가 맞지 않는 경우도 있습니다. 특히 여러 종류의 시스템이 섞인 환경에서 그렇습니다. 서드파티 도구는 더 나은 커넥터, 더 단순한 인터페이스를 제공하거나, 단지 기존의 내부 관행에 맞을 수도 있습니다.

팀이 이미 외부 플랫폼에 숙련되어 있을 때
SAP가 훨씬 큰 아키텍처의 일부에 불과할 때
실시간, 로우코드 또는 고급 데이터 통합이 필요할 때

5. 라이선스와 비용 요인

라이선스는 플랫폼마다 크게 다를 수 있습니다. SAP 도구는 통합 기능을 기존 구독에 묶어 제공하는 경우가 많습니다. 서드파티 도구는 유연성을 줄 수 있지만, 가격 모델이 물량이나 사용자 수에 따라 빠르게 커질 수 있습니다.

트랜잭션 물량과 커넥터를 기준으로 비용을 평가
이미 라이선스를 보유한 SAP 기능과 겹치지 않는지 확인
라이선스 비용만이 아니라 TCO를 고려

6. 통합 유지보수와 지원

서드파티 플랫폼은 서로 다른 지원 모델이 필요할 수 있습니다. 벤더의 든든한 지원을 받을 수 있는 경우도 있고, 내부 역량에 크게 의존해야 하는 경우도 있습니다. 초기 구축 속도만이 아니라 장기 유지보수도 결정에 포함되어야 합니다.

벤더의 SLA와 업데이트 주기를 확인
내부 지식 수준과 외부 컨설턴트의 필요성을 반영
거버넌스, 버전 관리, 보안 업데이트를 계획

4. SAP Integration Suite에서 알맞은 구성 요소 고르기

완벽한 통합 도구는 없습니다. 한 SAP 프로젝트에서 잘 통하는 것이 다른 프로젝트에서는 불필요한 부담이 될 수 있습니다. SAP Integration Suite에서 알맞은 구성 요소를 고르는 일은 지금 다루는 환경이 어떤 모습인지, 그리고 통합이 어떤 압박을 받게 될지에 달려 있습니다. 그 압박은 기술적일 수도, 운영상일 수도, 때로는 정치적일 수도 있습니다.

몇 가지 기준으로 후보를 좁히는 것부터 시작하십시오.

시스템 환경: 몇 개의 시스템이 관련됩니까? 모두 SAP입니까, 아니면 클라우드와 비SAP 도구가 섞여 있습니까?
지연 요건: 데이터가 즉시 이동해야 합니까, 아니면 지연이 허용됩니까?
확장성: 새 시스템이 자주 추가됩니까? 표준화보다 유연성이 중요합니까?
물량: 시간당 몇 건을 옮깁니까, 아니면 분당 수만 건을 옮깁니까?

플랫폼이 요구 사항에 어떻게 대응하는지 대략 정리하면 다음과 같습니다.

SAP 간 연동 - PI/PO 또는 CPI
클라우드 간 연동 - CPI, MuleSoft, Boomi
API 관리 - SAP API Management, MuleSoft
대용량 ETL - Informatica, SAP Data Intelligence
복잡한 오케스트레이션 - PI/PO, MuleSoft, BTP Integration Services

5. Oracle, Microsoft, Salesforce와 SAP Integration Suite

실제 SAP 환경에서 SAP가 홀로 작동하는 경우는 드뭅니다. 많은 환경에는 Oracle, Microsoft, Salesforce 같은 대규모 핵심 업무 플랫폼이 함께 있습니다. 각각 고유한 통합 과제를 안고 있습니다. 기술적인 것도 있고, 구조적인 것도 있고, 라이선스의 회색지대에 걸린 것도 있습니다.

1. SAP ↔ Oracle(ERP, HR, SCM)

SAP와 Oracle은 규모가 큰 기업에서 함께 쓰이는 경우가 많습니다. 하나는 재무를 맡고, 다른 하나는 공급망이나 HR을 관리합니다. 둘이 데이터를 안정적으로 공유하게 만드는 일은 처음에는 더디게 느껴질 수 있고, 특히 데이터 모델이 예상보다 많이 다를 때 그렇습니다.

Oracle 테이블은 API나 스테이징 계층을 통해 노출해야 하는 경우가 많습니다
SAP는 보통 IDoc을 보내거나 BAPI를 사용하므로 변환이 필요합니다
타이밍이 핵심입니다. 배치 처리 시간대 때문에 동기화가 지연될 수 있습니다
Oracle 앱이 SAP 프로세스를 자동으로 실행하면 간접 액세스 리스크가 흔히 발생합니다

2. SAP ↔ Microsoft(Azure, Power Platform, M365)

Microsoft와 SAP는 대부분이 예상하는 것보다 더 많은 지점에서 만납니다. Power BI가 SAP에서 데이터를 가져오든 Teams가 실시간 KPI를 보여 주든, 연결은 늘어나고 있습니다. 하지만 통합에는 신중한 설정이 필요합니다. 매끄러운 부분도 있고, 그렇지 않은 부분도 있습니다.

Azure Logic Apps는 SAP API를 호출할 수 있지만 자격 증명을 신중하게 관리해야 합니다
Power Platform은 커넥터를 제공하지만, 복잡한 흐름에는 맞춤 함수가 필요할 수 있습니다
Microsoft 365(예: Excel)는 SAP 데이터를 오프라인에서 편집한 뒤 다시 동기화하는 데 자주 쓰입니다. 이 구성은 추적하지 않으면 조용히 라이선스 문제를 만들 수 있습니다

SAP와 Azure의 연결성은 개선되고 있지만, 하이브리드 모델에는 특히 온프레미스 시스템이 관련될 때 여전히 강력한 인증이 필요합니다.

3. SAP ↔ Salesforce(고객 데이터, 주문, 지원)

Salesforce는 거의 항상 고객과 맞닿는 쪽에 있습니다. SAP는 백엔드를 맡습니다. 둘을 잇는 일은 대개 고객 레코드, 주문 상태, 서비스 이력을 동기화하는 일입니다.

이런 흐름에는 SAP CPI나 MuleSoft를 쓰는 경우가 흔합니다
오브젝트 모델이 다릅니다. Salesforce는 더 유연하고 SAP는 더 엄격합니다
Salesforce의 API 호출 한도 때문에 대용량 동기화가 멈출 수 있습니다
라이선스를 가진 사용자 없이 Salesforce가 SAP 트랜잭션을 실행하면 간접 라이선스 리스크가 있습니다

이런 연결이 간단해 보일 때도 있습니다. 하지만 물량이 늘거나 프로젝트 도중 프로세스가 바뀌면 복잡성이 드러납니다. 이런 예외를 일찍 계획해 두는 노력이 헛되는 일은 드뭅니다.

CPI 통합

6. 간접 라이선스란 무엇입니까?

간접 라이선스는 SAP 밖의 시스템이 보이지 않는 곳에서 SAP와 상호작용할 때 발생합니다. 아무도 SAP에 직접 로그인하지 않는데도 업무 프로세스는 여전히 SAP에 의존합니다. 흔한 예는 Salesforce가 SAP 사용자가 화면을 전혀 건드리지 않은 채 SAP에 판매 오더를 자동으로 생성하는 경우입니다. 이것도 해당됩니다.

SAP는 이를 “간접 액세스(indirect access)”라고 부릅니다. 이것이 중요한 이유는, 사용자가 SAP를 한 번도 보지 않았더라도 여전히 라이선스 대상 이벤트로 간주되기 때문입니다.

이를 관리하기 위해 SAP는 초점을 사용자에서 문서로 옮긴 Digital Access 모델을 도입했습니다.

대표적인 발생 계기는 다음과 같습니다.

서드파티 포털이 SAP로 주문을 밀어 넣는 경우
모바일 앱이 API로 재고 수준을 확인하는 경우
봇이 로그인 없이 고객 데이터를 갱신하는 경우
CRM이 SAP에서 실시간으로 가격을 가져오는 경우

경계가 어디인지 늘 분명한 것은 아닙니다. 하지만 SAP가 다른 시스템을 대신해 무언가를 처리하고 있다면 확인해 볼 가치가 있습니다.

7. 라이선스와 컴플라이언스 고려 사항(직접 + 간접)

SAP 프로젝트에서 라이선스 문제는 늦게, 때로는 통합 결정이 이미 내려진 뒤에 불거지는 경향이 있습니다. 하지만 중요합니다. 대부분이 예상하는 것보다 훨씬 더. 특히 서드파티 시스템이 Named User 없이 SAP에서 읽거나 SAP에 쓰기 시작할 때 그렇습니다.

핵심 쟁점은 대개 직접 액세스와 간접 액세스로 귀결됩니다. 직접 액세스는 단순합니다. Named User인 SAP 사용자가 로그인해 프로세스를 실행하면, 그 행위는 라이선스 대상입니다. 그러나 간접 액세스는 외부 시스템(Salesforce, 자체 포털, 어쩌면 봇)이 백그라운드에서 SAP와 상호작용할 때 발생합니다. 이것도 SAP의 약관상 사용으로 간주될 수 있습니다.

이에 대응하기 위해 SAP는 Digital Access 모델을 도입했습니다. 사용자 단위로 과금하는 대신, 간접 액세스를 통해 생성된 특정 문서 유형의 건수를 셉니다. 판매 오더, 송장, 자재 이동 같은 것들이 여기에 포함됩니다. 문서상으로는 더 명확합니다. 실제로는 여전히 회색지대가 있습니다.

컴플라이언스 리스크는 선의로 만든 자동화에서 비롯되는 경우가 많습니다. 예를 들면 다음과 같습니다.

사용자 로그인 없이 SAP에서 가격을 가져오는 모바일 앱
SAP에 고객 레코드를 자동으로 생성하는 CRM
매시간 재고 수준을 확인하는 스케줄링 도구

모두 유용한 도구입니다. 하지만 제대로 추적하고 보고하지 않으면 라이선스 노출 위험을 일으킬 수 있습니다.

비용을 관리하는 방법이 있습니다. SAP는 문서 기반 라이선스로 전환하는 고객에게 Digital Access Adoption Program(DAAP) 인센티브를 제공합니다. 리스크가 어디에 있는지 추적하기 위해 사용량 모니터링 도구(SAP Passport 또는 외부 로깅 도구)를 도입하는 기업도 있습니다.

감사는 또 다른 이야기입니다. 기술적일 수도, 상업적일 수도, 둘 다일 수도 있습니다. 예측 가능한 감사도 있고 그렇지 않은 감사도 있습니다. 어느 쪽이든 선제적으로 대응하는 편이 허를 찔리는 것보다 비용이 덜 드는 경향이 있습니다.

1. Salesforce가 SAP에 판매 오더를 생성하는 경우

영업 담당자가 Salesforce에 거래를 입력하면, Salesforce가 주문 데이터를 SAP로 자동 전송합니다. SAP 사용자는 로그인하지 않지만 백엔드 문서가 생성됩니다.

문제점: 판매 오더가 간접 액세스를 통해 생성되며, 이는 SAP 디지털 라이선스 대상입니다.
완화 방안: SAP의 Digital Access 모델을 적용해 이를 문서로 집계하거나, Named User인 SAP 사용자의 워크플로를 통해 실행되도록 구조를 바꿉니다.

2. 자체 포털이 SAP에서 가격을 읽는 경우

공개 웹 포털 또는 파트너용 웹 포털이 API를 통해 SAP에서 가져온 실시간 가격을 표시합니다. SAP 인증은 사용되지 않습니다.

문제점: 가격 데이터 접근이 Named User를 우회하여, 추적 가능성 없이 SAP 백엔드가 노출됩니다.
완화 방안: 접근을 SAP API Management를 거치도록 하고, 적절한 사용자 인증이나 쿼터 통제를 적용합니다.

3. 모바일 앱이 재고 가용성을 확인하는 경우

창고 팀이 SAP에 직접 로그인하지 않고 실시간 SAP 재고를 조회하는 모바일 앱을 사용합니다.

문제점: 데이터가 간접적으로 접근되며, 물량이나 빈도에 따라 라이선스 책임이 발생할 수 있습니다.
완화 방안: 모바일 사용자에게 라이선스를 부여하거나, 접근이 문서 기반 라이선스 임계값을 지키는지 확인합니다.

4. 이커머스 플랫폼이 송장을 생성하는 경우

온라인 구매가 SAP로의 송장 자동 전기로 이어집니다. 이 프로세스는 전적으로 시스템 간에 이루어지며 SAP 사용자는 개입하지 않습니다.

문제점: 송장 생성이 간접적으로 이루어지면 SAP의 Digital Access 모델상 라이선스 대상 이벤트입니다.
완화 방안: 송장 문서를 디지털 액세스 라이선스 집계에 포함하고 물량 추세를 모니터링합니다.

5. HR 시스템이 SAP에 직원 데이터를 쓰는 경우

서드파티 HR 소프트웨어가 직원 마스터 데이터를 관리하며, 배치 작업으로 SAP HCM을 갱신합니다.

문제점: 라이선스를 가진 SAP 사용자 없이 마스터 데이터를 생성하면, 데이터가 처리되는 방식에 따라 규정 위반일 수 있습니다.
완화 방안: 이것이 라이선스 대상 문서로 간주되는지 SAP에 확인하고, 사용량 추적을 구현하거나 Named User를 통해 처리되도록 경로를 조정합니다.

6. BI 도구가 SAP에서 정기적으로 리포트를 가져오는 경우

Power BI나 Tableau 같은 리포팅 플랫폼이 일정에 따라 OData나 JDBC로 SAP 테이블에 연결하여, 조용히 데이터를 가져옵니다.

문제점: 인증되지 않았거나 사용자에게 라이선스가 없다면, 잦은 데이터 추출이 접근 정책 위반이 될 수 있습니다.
완화 방안: 승인된 리포팅 사용자를 통해 접근하게 하거나, 라이선스를 제대로 추적하는 SAP 인증 분석 커넥터를 사용합니다.

8. 제가 어떻게 도와드릴 수 있습니까?

SAP와 디지털 전환 분야에서 25년을 일하며, 킥오프부터 Go-Live까지의 프로젝트와, 아무도 이야기하지 않는 지저분한 중간 과정을 모두 보았습니다. 처음부터 이끄는 경우도 있고, 일이 틀어졌을 때 배의 중심을 잡아 달라는 요청을 받아 투입되는 경우도 있습니다.

어느 쪽이든 제 역할은 같습니다. 비즈니스가 실제로 필요로 하는 것과 시스템이 실제로 제공할 수 있는 것을 연결하는 일입니다. 전문 용어도, 군더더기도 없습니다. 여기서 보시는 내용은 이론이 아닙니다. 현장에서 수년간 실제 압박 속에서 실제 문제를 풀며 다듬어진 것입니다.

요구사항 수집

9. 통합 모범 사례 몇 가지

프로젝트 초기에 통합은 대개 일단 돌아가게 만든다는 뜻입니다. 데이터를 한 시스템에서 다른 시스템으로 옮기고, 몇 가지 항목에 체크하고 다음으로 넘어갑니다. 하지만 진짜 과제는 나중에, 무언가가 조용히 깨지거나 애초에 인터페이스를 어떻게 설정했는지 아무도 기억하지 못할 때 나타납니다.

모범 사례는 경직된 표준을 따르는 것이 아닙니다. 피할 수 있는 리스크를 줄이는 것입니다. 더 강력한 인증을 쓰거나, 규모가 커지기 전에 모니터링을 구축하는 것일 수 있습니다. 때로는 그 시점에는 필요 이상으로 느껴질 만큼 문서화하는 것을 뜻하기도 합니다.

통합을 장기적으로 건강하게 유지하는 데 도움이 되는 것이 몇 가지 있습니다.

OAuth2, SAML, X.509 같은 보안 프로토콜 사용
흐름이 단순해 보여도 모니터링 구축
재사용하거나 확장할 수 있는 iFlow와 API 구축
작동 방식과 실패했을 때 대처법 문서화

이런 단계는 급해 보이는 경우가 드뭅니다. 하지만 나중에 몇 시간을 아껴 줍니다. 때로는 며칠을.

1. 모든 통합 지점 보호

보안은 대개 Go-Live 직전에야 다뤄집니다. 하지만 그때가 고치기 가장 어려운 시점입니다. 시나리오에 따라 OAuth2, SAML 또는 인증서를 사용하십시오. 고정 자격 증명을 쓴다면 제대로 기록하고 교체하십시오. 설정 파일에 그냥 두고 아무도 잊지 않기를 바라서는 안 됩니다.

외부 구간만이 아니라 종단 간 암호화 사용
데이터 리스크에 따라 인증 프로토콜 선택
토큰 만료와 갱신을 일찍 테스트

2. 처음부터 모니터링

모니터링은 사고가 난 뒤에 추가되는 경우가 많습니다. 하지만 무언가 깨지기 전에 갖춰져 있을 때 가장 잘 작동합니다. 최소한의 로깅만 있어도 도움이 됩니다. 화려한 대시보드가 중요한 것이 아닙니다. 무엇이, 언제, 왜 실패했는지 아는 것이 중요합니다. 그렇지 않으면 작은 문제 하나를 추적하는 데도 몇 시간이 걸릴 수 있습니다.

실패와 타임아웃에 대한 알림 설정
응답 시간과 재시도 횟수 기록
가능하면 기존 SAP 모니터링 활용

3. 당장이 아니라 재사용을 위해 설계

당장의 문제를 하드코딩된 임시방편으로 빠르게 풀고 싶은 유혹이 있습니다. 하지만 일회성 조치는 모두 나중에 마찰을 더합니다. 재사용 가능한 iFlow, 공유 변환 로직, 매개변수화된 입력은 프로세스가 변할 때 시간을 아껴 줍니다. 프로세스는 거의 언제나 변합니다.

가능한 곳에서는 템플릿 사용
매핑 단계에 비즈니스 규칙을 넣지 않기
로직을 전송 계층과 분리

4. 운영을 염두에 둔 문서화

문서화는 설계 단계에서 멈추는 경향이 있습니다. 하지만 지원 팀에는 다이어그램 이상이 필요합니다. 엔드포인트가 다운되었을 때나 필드가 누락되었을 때 어떻게 되는지 알아야 합니다. 좋은 문서는 티켓이 올라오기 전에 그런 질문에 답해 줍니다.

재시도 로직, 장애 처리, 버전 정보 포함
상류 및 하류 시스템에 대한 가정 기술
흐름이 바뀌면 문서도 최신 상태로 유지

5. 명확한 책임자 지정

아무도 책임지지 않는다는 사실을 깨닫기까지 몇 달 동안 돌아가는 통합도 있습니다. 실패하면 모두가 다른 누군가가 지켜보고 있겠거니 생각합니다. 이런 일을 피하십시오. 책임자를 지정하십시오. 비공식적이라도 좋습니다. 이 한 단계가 대부분의 기술적 조치보다 다운타임을 더 많이 줄여 줍니다.

흐름과 인터페이스마다 책임을 정의
책임자가 로그와 도구에 접근할 수 있도록 보장
온보딩 및 인수인계 문서에 책임자를 포함

6. 출시만이 아니라 변화에 대비해 구축

인터페이스는 고정된 것이 아닙니다. 필드가 바뀝니다. API는 버전이 올라갑니다. 물량은 늘어납니다. 흐름이 너무 경직되어 있으면 작은 변화에도 깨집니다. 지금은 요구사항이 안정적으로 보이더라도 처음부터 조정에 대비해 계획하십시오.

매핑과 설정에 버전 관리 적용
알려진 한계와 제약을 명확히 문서화
릴리스 주기마다 통합 흐름 검토

10. 총비용과 ROI 고려 사항

통합 프로젝트는 시스템을 연결하고, 데이터를 동기화하고, 돌아가게 만든다는 기술적 목표로 시작하는 경우가 많습니다. 그러나 그 밑바닥에서는 대부분이 깨닫는 것보다 비용이 더 큰 역할을 합니다. 초기 라이선스뿐 아니라, 워크로드가 커질 때, 요구사항이 바뀔 때, 임시방편이 영구적인 것이 될 때 나중에 불거지는 비용까지 포함해서입니다.

SAP CPI 같은 클라우드 도구는 초기에는 비용 효율이 더 높아 보일 수 있습니다. 하드웨어가 없고 구축도 빠릅니다. 하지만 사용량 기반 가격 체계에서는 물량에 따라 비용이 올라갈 수 있습니다. PI/PO 같은 온프레미스 옵션은 가격이 더 안정적이지만 인프라 부담이 따릅니다.

서드파티 플랫폼도 있습니다. 각각 고유한 라이선스 모델이 있어서, 사용자 단위로 과금하는 곳도 있고 트랜잭션이나 커넥터 단위로 과금하는 곳도 있습니다. 쌓이면 큰 금액이 됩니다.

그래서 통합을 ROI 관점에서 본다는 것은 “지금 얼마가 드는가?”보다 더 많은 것을 묻는다는 뜻입니다. 앞을 내다본다는 뜻입니다. 이것은 어떻게 확장될까? 그리고 바꿔야 할 때 누가 비용을 낼까?

1. 클라우드와 온프레미스 비용

SAP CPI 같은 클라우드 플랫폼은 구축이 더 빠르고 인프라 비용이 낮지만, 가격이 사용량에 따라 늘어나는 경우가 많습니다. PI/PO 같은 온프레미스 도구는 초기 투자가 더 크지만, 특히 하드웨어가 이미 갖춰져 있다면 시간이 지나도 비용이 안정적일 수 있습니다.

클라우드: 구독 기반이며, 메시지 또는 연결 단위인 경우가 많음
온프레미스: CAPEX 비중이 크고, 반복적인 라이선스 비용은 낮음
가격은 시스템 물량과 IT 규모에 따라 달라짐

2. SAP CPI 라이선스의 영향

SAP CPI는 단계별 사용량 기반 모델을 씁니다. 메시지 물량과 처리량에 따라 과금됩니다. 물량이 적거나 중간 수준인 시나리오에서는 예측이 가능하지만, 트래픽이 많거나 최적화되지 않은 흐름은 비용을 급격히 끌어올릴 수 있습니다.

시작 단계는 보통 월 1,000~2,000유로 안팎에서 시작
대용량 메시지나 비표준 어댑터에는 추가 요금
비용을 선제적으로 관리하려면 매달 사용량 추적

3. 서드파티 미들웨어 가격

MuleSoft, Dell Boomi, Informatica는 커넥터 단위, 사용자 단위, 트랜잭션 단위 등 다양한 가격 모델을 따릅니다. 기본 가격은 부담스럽지 않아 보일 수 있지만, 규모를 키우면 새로운 요금이 붙는 한도가 드러나는 경우가 많습니다.

MuleSoft: 라이선스 + API 물량 + 코어 팩(연 약 18,000달러 이상)
Boomi: 통합 프로세스, 커넥터 또는 사용자 등급 단위
Informatica: ETL 물량과 플랫폼 서비스에 따라 비용 결정

4. 시간이 지남에 따른 변경 비용

초기 구축 비용은 이야기의 일부일 뿐입니다. 변경(새 엔드포인트, 매핑 수정, 비즈니스 규칙 변경)은 특히 경직된 환경에서 추가 라이선스 비용이나 개발 비용을 낳을 수 있습니다.

복잡한 환경에서는 연간 변경 비용을 15~30%로 추산
모듈화가 더 잘된 플랫폼일수록 변경 시 마찰이 줄어드는 경향
커스터마이징에는 라이선스 확장이나 컨설팅이 필요할 수 있음

5. 지원 및 유지보수 비용

비용 추정에서 지원은 간과되기 쉽습니다. SAP CPI에는 기본 지원 등급이 포함되어 있지만 응답 시간과 SLA는 다양합니다. 서드파티 도구는 대가를 치르면 더 빠른 지원을 제공하거나, 별도 서비스 계약을 요구할 수 있습니다.

SAP 지원은 기존 엔터프라이즈 계약에 연동
서드파티 도구는 지원 비용으로 연간 라이선스의 15~20%를 청구할 수 있음
시스템이 복잡해질수록 내부 지원 수요가 늘어날 수 있음

6. 구축 이후까지 고려한 ROI 평가

진짜 ROI에는 구축뿐 아니라 시간에 따른 소유 비용이 포함됩니다. 더 싼 플랫폼은 유연성이 부족할 수 있고, 비용이 더 높은 도구는 나중에 다운타임이나 변경 작업을 줄여 줄 수 있습니다. 출시 시점만이 아니라 수명 주기를 기준으로 평가하십시오.

라이선스 + 유지보수 + 지원 + 변경 비용의 합계를 반영
프로젝트 단계만이 아니라 2~3년의 기간에 걸쳐 ROI를 추산
실패하거나 지연된 통합의 비용을 잠재 리스크로 포함

자주 묻는 질문

많은 고객이 SAP 구축을 처음 검토할 때 같은 질문 주변을 맴돕니다.

그중 몇 가지는 직접 떠올려 보셨을 수도 있습니다. 실제로 얼마나 걸리는지, 비용은 얼마나 들지, 시스템이 가동된 뒤에는 어떤 지원이 필요한지 같은 질문입니다. 모두 타당한 질문입니다.

그래서 막연히 짐작하시도록 두지 않고, 무엇을 기대해야 하는지, 까다로운 부분이 대개 어디서 나타나는지 감을 잡으실 수 있도록 명확하고 솔직한 답을 모았습니다.

연락해 주십시오!

1. SAP CPI란 무엇입니까?

SAP CPI, 즉 Cloud Platform Integration은 SAP Integration Suite의 일부입니다. 주로 클라우드나 하이브리드 환경에서 SAP와 비SAP 시스템을 연결하도록 돕습니다. 분산된 환경을 위해 만들어진 미들웨어라고 생각하시면 됩니다.

다음이 포함됩니다.

사전 구축된 통합 플로(iFlow라고 부릅니다)
HTTPS, SFTP, OData 같은 프로토콜 지원
맞춤 매핑, 스크립팅, 라우팅 옵션

CPI는 온프레미스에서 클라우드로 옮길 때, 또는 서드파티 앱이 SAP와 안전하게 통신해야 할 때 특히 유용합니다.

2. SAP는 Salesforce와 어떻게 통합됩니까?

SAP와 Salesforce는 보통 API나 SAP CPI, MuleSoft, Dell Boomi 같은 미들웨어를 통해 데이터를 주고받습니다.

흔한 유스케이스는 다음과 같습니다.

고객 마스터 데이터 동기화
주문 및 송장 상세 정보 전송
지원 케이스 이력이나 가격 정보 공유

어려움은 대개 데이터 모델의 차이와 Salesforce 측의 API 한도에서 비롯됩니다. 신중한 매핑과 스로틀링이 핵심입니다.

라이선스도 우려 사항일 수 있습니다. Salesforce가 SAP에서 작업을 실행하면 간접 액세스가 적용될 수 있습니다.

3. SAP 간접 액세스란 무엇입니까?

간접 액세스는 외부 시스템이 사용자가 직접 로그인하지 않은 채 SAP와 상호작용할 때 발생합니다. 예를 들어 포털이나 서드파티 앱이 API를 통해 SAP에 판매 오더를 생성하는 경우입니다.

SAP는 이를 Digital Access 모델에 따라 라이선스 대상으로 봅니다. 이 모델에서는 사용량을 문서 유형(주문, 송장 등)별로 추적합니다.

팀이 허를 찔리기 쉽습니다. 시스템은 백그라운드에서 조용히 돌아가지만, 라이선스 노출을 일으키는 문서를 생성합니다.

관리 방법은 다음과 같습니다.

외부 시스템이 SAP를 어떻게 사용하는지 평가
문서 생성량 모니터링
SAP의 디지털 문서 기반 라이선스 구조 검토

4. 어떤 SAP 통합 도구가 가장 좋습니까?

무엇을 통합하는지, 얼마나 자주 바뀌는지, 누가 유지보수하는지에 따라 다릅니다.

클라우드 간 또는 하이브리드: SAP Integration Suite(CPI)
온프레미스 SAP 간 연동: SAP PI/PO
API 거버넌스: SAP API Management
데이터 파이프라인과 분석: SAP Data Intelligence
더 넓은 엔터프라이즈 통합: MuleSoft 또는 Dell Boomi

대부분의 환경은 여러 도구를 섞어 씁니다. “최고”는 기능보다 적합성에 달려 있습니다.

5. SAP는 Microsoft, Oracle과 통합할 수 있습니까?

네, 그리고 자주 있는 일입니다.

SAP ↔ Microsoft

Azure Logic Apps, Power Automate 또는 Power BI의 SAP 커넥터
일반적인 용도: SAP 데이터를 Excel, Teams 또는 대시보드로 가져오기

SAP ↔ Oracle

보통 미들웨어(CPI, PI 또는 서드파티)를 거침
유스케이스는 재무, 조달 또는 HR 통합 등

과제로는 서로 다른 인증 모델, 타이밍 불일치, 경우에 따라서는 라이선스가 있습니다.

6. SAP Integration Suite란 무엇입니까?

SAP Integration Suite는 시스템, 앱, 데이터를 연결하기 위한 SAP의 클라우드 네이티브 플랫폼입니다. CPI, API Management, Open Connectors, 이벤트 메시 기능이 포함됩니다.

도구 모음이라고 생각하시면 됩니다. 일부는 사전 구축되어 있고, 일부는 직접 구성할 수 있습니다. 클라우드 우선 환경과 하이브리드 환경을 위해 설계되었습니다.

핵심 이점은 다음과 같습니다.

흔한 통합을 위한 사전 구축 콘텐츠
실시간 및 배치 처리
보안, 모니터링, 거버넌스 도구

SAP는 이를 현대적인 환경을 위한 전략적 통합 계층으로 내세우고 있습니다.

7. SAP CPI가 PI/PO를 대체합니까?

클라우드 비중이 크거나 하이브리드인 환경에서는 그렇습니다. SAP CPI가 선호되는 방향입니다. 하지만 PI/PO도 여전히 지원되고 널리 쓰이며, 특히 ECC 기반 시스템이나 온프레미스 구성에서 그렇습니다.

SAP는 시간을 두고 Integration Suite로 옮기라고 권장하지만, 강제 전환은 없습니다. 프로젝트 일정, 시스템 로드맵, 비용에 따라 달라집니다.

두 가지를 함께 쓰면서 CPI를 점진적으로 도입하는 기업도 있습니다.

8. SAP는 API 보안을 어떻게 처리합니까?

SAP는 표준 보안 프로토콜을 지원합니다.

토큰 기반 인증을 위한 OAuth2
연합 ID를 위한 SAML
시스템 간 신뢰를 위한 X.509 인증서

Integration Suite는 API 스로틀링, 쿼터 적용, 정책 관리도 제공합니다. 대부분의 팀은 SAP 보안 도구를 Azure AD나 Okta 같은 사내 ID 공급자와 함께 사용합니다.

보안 요구는 시나리오마다 다르므로 일찍 계획하십시오.

9. SAP 통합 비용을 좌우하는 것은 무엇입니까?

여러 요인이 비용에 영향을 줍니다.

도구 유형(클라우드와 온프레미스)
트랜잭션 또는 메시지 물량
인터페이스와 시스템의 수
라이선스 모델(예: CPI는 사용량 기반)

예를 들어 SAP CPI 라이선스는 처음에는 낮아 보일 수 있지만 물량에 따라 빠르게 커질 수 있습니다. 서드파티 미들웨어는 커넥터나 사용자 단위로 과금할 수 있습니다.

견적에는 라이선스 비용뿐 아니라 지원 비용과 변경 비용을 반드시 포함하십시오.

10. SAP 통합은 어떻게 모니터링합니까?

SAP Integration Suite에는 모니터링 대시보드, 로그, 트레이스 도구가 내장되어 있습니다. 다음을 할 수 있습니다.

메시지 로그와 오류를 실시간으로 확인
성능과 지연 시간 추적
실패하거나 느린 흐름에 대한 알림 설정

PI/PO 같은 온프레미스 시스템에서는 모니터링을 Integration Engine에서 처리하거나 SAP Solution Manager를 통해 처리합니다.

핵심은 모니터링을 일찍 구축하는 것입니다. 무언가 실패할 때까지 기다리는 것은 미리 계획하는 것보다 대개 비용이 더 듭니다.

지금 진행 중인 일을 말씀해 주십시오.

30분 통화입니다. 프로젝트, 의사결정 또는 문제를 설명해 주십시오. 제가 도울 수 있는지 말씀드리고, 제가 적임자가 아니라면 누가 도울 수 있을지 알려 드리겠습니다.

프로젝트 상담하기

SAP Integration Suite: 도구, 라이선스, 실제 시나리오

지금 진행 중인 일을 말씀해 주십시오.