CONTENTS

• 목록

9월 KSUG 뉴스레터 : 

SAP의 확장 솔루션 개발을 위한 파트너쉽 (2편)

2022년 9월 28일(수)

 지난 8월 KSUG 뉴스레터를 통해 SAP의 파트너쉽 전략의 대대적인 변화에 대해 알아보았습니다. 이번에는 지난번과 연결하여 많은 SAP의 파트너들과 사용자들이 크게 관심을 가지고 있는 SAP 솔루션의 확장 측면에 대해 좀 더 상세히 살펴보도록 하겠습니다.

 
 지난 1편에서 말씀 드린 것처럼 이전의 SAP는 스스로 제공하는 솔루션에만 집착하는 경향이 강했습니다. 그러나 클라우드 시대를 맞이하여 그들도 전략을 완전히 바꾸었습니다. 구글이나 애플이 B2C에서 플랫폼으로 보여준 성과를 보고, Salesforce의 B2B 플랫폼의 성공 등을 참조하여 SAP도 태세 전환을 완전히 한 것이겠지요. 사실 On-Prem으로 소프트웨어 라이센스를 팔던 시절에는 SAP에 없는 기능을 보유한 솔루션 회사를 잘 안다고 하더라도 SAP가 이를 활용해서 추가적인 매출을 올리거나 실적에 직접 도움을 받을 만한 꺼리가 별로 없었습니다. SAP의 입장에서는 차라리 인수합병을 하거나 유사 기능을 개발해서 내재화를 하고 나서 파는 것이 회사의 이익에 도움이 되는 것이었죠. 그러나 클라우드 시대에는 상황이 완전히 달라졌습니다. 클라우드 방식의 “플랫폼” 전략을 쓰면 되는 겁니다. 다른 회사의 솔루션도 나의 플랫폼을 통해 공급이 되면 내게도 따박따박 매출이 생기는 것입니다. 그러면 이러한 솔루션 네트워크가 크면 클수록 나도 돈버는 더 많이 버는 새로운 게임인거지요. 애플이나 구글 안드로드가 그랬던 것처럼요.

 물론 B2B 솔루션은 구축을 수반해야 하는 면에서, B2C와는 플랫폼으로 운영하기 위한기술적 난이도가 훨씬 어렵습니다. 그러나 B2B에도 클라우드 시대가 무르익어 가면서 PaaS(Platform-as-a-Service)가 점차 기술적인 완결성을 가지게 되면서 본격적인 오픈 전략이 시작됩니다. 사실 기존에는 이러한 외부 솔루션과의 유연한 결합은 CBO(Customer-Bolt-On)를 통한 기능 확대가 가진 할 수 있는 유일한 대안이었습니다. 그러나 이러한 CBO 방식은 개발이나 유지/보수 등에 너무나 단점이 많아서 큰 불평의 근원이 되어왔습니다. 그러면  기존의 CBO 방식이 가진 문제에 대해 살펴보도록 하겠습니다.

 첫째로, 일반적으로 대부분 국내 기업의 ERP에서는 CBO로 만들어 붙인 프로세스가 전체 ERP 프로세스에서 차지하는 비율이 매우 높습니다. 왜냐하면 국내 사용자들은 자신의 프로세스에 대한 고수와 집착이 유독 강하기 떄문이죠. 일부 CBO 프로그램은 고객이 직접 개발 하지만 상당 부분은 외부 협력사(SI사 또는 구축사)에서 개발한 프로그램으로 납품되어 설치되어 있습니다. 그런데 오래된 CBO의 경우에는 개발 경위나 용도가 불분명하고 아는 사람도 없지만 이것을 제거하면 어떤 문제가 생길지 몰라서 그 용도도 모른 채로 관리하게 되는 경우가 태반입니다. 그런데 그러한 CBO의 소유권과 관리의 책임은 고객에게 있으니 결국 CBO가 많을수록 고객의 책임의 범위와 관리비용이 증가합니다.

 둘째로, SAP ERP의 업데이트나 업그레이드가 발생시 모든 ERP 동작(스탠다드 트랜잭션, CBO 트랜잭션, 인터페이스)을 모두 테스트하여야 합니다. 그러다가 추후에 ERP 기능이 개선되어서 구조 변경이 생기면 CBO 프로그램이 동작하지 않으므로 CBO 프로그램의 개선 및 개발 업체의 엔지니어가 방문하여 재배포 작업을 진행해야 하거나, 테스트간에 오작동이나 장애가 발생시, 개발 업체의 엔지니어가 방문하여 장애 처리를 해야 합니다. 이러한 문제로 인하여 업데이트나 업그레이드에 상당한 시간이 소요되고 이러한 시간은 모두 고객의 비용으로 돌아오게 됩니다.

 셋째로, SAP ERP에 가장 많은 부하를 주는 프로그램 상위 100개를 확인해 보면 50~70%가 CBO들입니다. 일반적으로 CBO 프로그램은 AP 서버 내에서 ERP와 함께 동작하므로 ERP 서버의 자원을 상당하게 잠식해서 사용합니다. 그러다가 마감이나 결산처리시 Standard 트랜잭션과 CBO 트랜잭션이 부하를 함께 발생시켜 돌아가는 경우에, CBO 프로그램이 셧다운 되어 버리는 상황이 빈번하게 발생합니다. 게다가 Standard 트랜잭션과 CBO 프로그램이 비즈니스 프로세스상 선수행 관계에 있는 경우, CBO의 장애는 전체 프로세스의 장애로 귀결되는 상황이 발생합니다. 이렇게 일반적으로 CBO 프로그램이 많아지고 핵심 역할을 하는 경우가 늘어남에 따라 작업량이 높아지고 ERP 서버에 높은 부하를 가중시켜 전체 업무에 차질이 생기는 경우가 다발합니다.

넷째로, CBO개발의 핵심이 되는 SAP의 ABAP은 자유롭게 습득하기 어렵고 또한 개발자의 초기 진입장벽이 높습니다. 게다가 SAP ABAP은 기술의 폐쇄성으로 인하여 타시스템과의 연계에 한계가 있고요. 그러니 ABAP개발자의 신규 채용이 어렵고, 나아가 새롭게 등장하는 인공지능, 블록체인 등의 신규 기술들을 접목하여 지능형 ERP환경으로의 전환을 CBO를 가지고 진행하기는 매우 어렵습니다.

 이러한 CBO 프로그램을 통한 기능 확대 방식에 대해 SAP는 지난 많은 세월 동안 수없이 문제점을 지적 받았기에 문제의 원인은 너무 잘 알고 있었습니다. 그러나 해결을 위해 근본적인 방안을 찾기가 어려웠는데, 이제 PaaS 클라우드 플랫폼을 개발하여 CBO의 느슨한 결합(Loosely Coupled) 방식을 제시함으로써 혁신적인 변화를 꽤할 수 있게 되었습니다. CBO 프로그램을 파트너가 지속 재사용 가능한 솔루션으로 개발해서 PaaS를 통해 붙여쓰게 하는 것입니다. PaaS는 ABAP에 대한 폐쇄성을 가지고 있지 않고 JAVA도 개발 언어로 통용이 되므로 각 개발 업체들도 기존에 본인들이 가지고 있는 별도 패키지이던 ABAP 프로그램이던 PaaS인 SAP BTP (Business Technology Platform)위에 연결해 놓으면 클라우드 방식의 서비스가 가능해지는 것입니다.

 앞으로 SAP ERP 프로젝트의 기간은 짧아지고 비용은 적어질 것이라 생각됩니다. 단기간내에는 어렵겠지만 길게 보면 새로운 기술과 트렌드는 기존에 겪었건 많은 개발의 어려움을 해소해줄 것이라 생각합니다. KSUG 파트너들의 SAP의 확장인 특화 솔루션의 개발과 출시도 점차 속도를 내고 있고, 벌써 입소문이 나고 있는 경우를 많이 보아서 앞으로의 추세 가속화를 믿어 의심치 않습니다.