[물류 플랫폼 구하기②] 진짜 ‘SaaS’를 검증하는 6가지 매트릭스

솔루션 웹서비스, SaaS(Software as a Service)란 무엇인가?

자사 소프트웨어를 SaaS로 변환하기 위한 핵심 검증 매트릭스

 

글. 박용규 아가도스 대표

 

 

“웹상에서 소프트웨어를 서비스하며 사용료를 받으면 SaaS(Software as a Service) 아닌가요?” 아니. 큰 착각이다.

 

소프트웨어 개발 기술이 발전을 거듭하고 있다. 소유형에서 임대형으로, 그리고 설치형에서 웹서비스형으로 그 방식이 변하고 있다. 국내 소프트웨어 솔루션(ICT) 기업들도 자사의 솔루션 웹서비스를 SaaS라 주장하며 마케팅에 열을 올리고 있다. 이는 물류 플랫폼을 표방하는 기업 역시 마찬가지다. 혹자는 이걸 LaaS(Logistics as a Service)라 부르기도 하던가.

 

하지만 이런 기업들 중에 진정한 의미의 SaaS를 제공하는 기업이 있는가 하면 의문이다. 국내 소프트웨어 기업 대부분은 아직 설치형(SI성 주문제작)과 서비스형(ASP형- 붙박이 기능 서비스) 모델 제공에 머물고 있다. 패키지 완제품형과 SaaS형 서비스 모델로의 전환에는 어려움을 겪고 있다. 무늬만 ‘제품’, 무늬만 ‘SaaS’라 주장하고 있는 것이 현실이다.

▲ 비즈니스 애플리케이션 사업 및 기술 발전 모델

: 소프트웨어를 개발, 운영하고 업무에 사용하도록 하는 ‘소프트웨어 제공 사업’은 산업군과 무관하게 위 그림과 같은 발전 과정을 겪어왔다. 표에 나오는 용어들은 본문 전체에 녹아져있으니 참고.

 

여기서 이런 반박이 나올 수 있겠다. “우리는 클라우드 센터를 운영하며, 애플리케이션 서비스를 하고 있는데 그게 무슨 소린가요?” 하지만 이와 같은 주장은 SaaS 모델이 담고 있는 필요조건을 수행해 본 경험이 없는 국내 서비스 기업들의 논리일 뿐이다. SaaS에는 플랫폼 사업화를 가능하게 만드는 팽창 요소가 내재화돼 있어야 한다. SaaS를 가능하게 하는 소프트웨어는 그 동안 국내 소프트웨어 솔루션 기업들이 하지 않았던 일들을 가능하게 만들어야 한다. 그래야 플랫폼의 사업화도 가능하다.

 

SaaS의 핵심은 ‘COA’

소프트웨어가 플랫폼이 되기 위해선 우선 소프트웨어 개발을 완성품 수준으로 끌어올려야 한다. 그러기 위해서 애플리케이션은 붙박이 서비스가 아닌 각각의 고객에게 최적화될 수 있는 애플리케이션, 즉 COA(Customer Optimized App)가 돼야 한다. 하지만 아쉽게도 국내 소프트웨어 기업들의 COA 기술과 경험은 부족한 것이 현실이다. COA를 얼마나 잘 만드는가. 그 능력이 소프트웨어의 완결화된 품질 지수를 좌우한다. 때문에 서비스 사업 모델의 기반이 되는 소프트웨어 솔루션을 우선 COA로 변환시킬 필요가 있다.

 

기업 솔루션이 COA로 변환된다면 업무 처리 방식이 변하거나 추가돼도 소프트웨어의 재설정 기능을 통해 사용자 환경에 맞춘 응대가 가능하다. 프로그램 코딩이나 컴파일 없이 재정의만으로 할 수 있는 요소가 늘어나는 것이다. 높은 품질을 유지하는 데 드는 비용과 추가 개발 비용 또한 절약할 수 있다.

▲ COA 기반 서비스

 

필자는 SaaS를 하나의 동일한 소프트웨어가 서로 다른 고객사의 요구에 맞춰 변신하는 소프트웨어라고 본다. 마치 손오공처럼 변신과 분신술을 부리는 서비스인 것이다. 그리고 이 SaaS야말로 플랫폼 사업화를 위한 필요조건이다.

 

3가지 핵심 매트릭스 : ‘가변성’과 ‘확장성’

자사의 소프트웨어를 SaaS 사업으로 바꾸고 싶은가. 그렇다면 일단 기존 소프트웨어에 대한 냉정한 검증이 필요하다. 검증 작업이 막막하다면 이제부터 필자가 제시하는 검증 매트릭스를 사용해봄직하다.

▲ SCM 서비스의 SaaS화를 위한 선결핵심 검증사항

 

키워드는 가변성과 확장성이다. 소프트웨어가 플랫폼이 되려면 우선 소프트웨어가 자유롭게 바뀌고 확장할 수 있어야 한다. 자사의 소프트웨어가 자유롭게 바뀌고 확장할 수 있을까? 대체 가변성과 확장성을 만들기 위해서는 무엇이 필요할까? 이 두 가지 질문에 대한 검증이 필요하다. 이는 단순한 개발환경이나 기술 스택에 대한 검증이 아니다. 가변 및 확장 활동유형(Activity Type)과 함께 가변 및 확장이 주어졌을 때 소프트웨어의 재코딩, 재컴파일이 발생하지 않아도 되는지를 검증해야 한다.

 

소프트웨어가 가변성과 확장성을 담보하지 못하면 소수의 자원으로 여러 개의 기업들의 니즈에 맞춘 최적화된 서비스를 제공하는 것이 어려워진다. 여기서 최적화란 리소스 확장이나 공유와 같은 클라우드 인프라 계층(Layer) 상의 멀티테넌트(Multi-Tenant, 다중 사용 기업) 요구사항만 의미하는 것이 아니다. 멀티테넌트별 업무 처리 기능 요구에 대한 가변성과 확장성까지 동시에 충족시킬 수 있어야 한다.

 

가변성과 확장성을 만드는 주체는 누구인가도 검증해야 한다. 이와 함께 소프트웨어의 어플라이언스(Appliance, 유지)가 가능한지 확인해야 한다. 물론 서비스 가변 및 확장 활동시 고객화(Customizing) 이슈로 인해 소프트웨어의 원형에 변화를 줄 수 있다. 하지만 무엇이 어떻게 변화되어 적용되는지가 분명히 통제돼야 한다. 그리고 어플라이언스 활동은 문서 작업이 아닌 서비스 자체에 자동화돼 있어야 한다.

 

물론 ASP(Application Service Provider)와 같은 임대형 모델은 어차피 붙박이 서비스이고, 커스터마이징 이슈를 무시한 서비스 모델이기 때문에 탄력성(Compliance) 유지가 의미 없겠다. 그러나 사용 기업에 최적화된 서비스를 해야 하는 SaaS형 서비스는 1 인스턴스(Instance)를 유지하면서도 사용 기업별로 최적화 업무 서비스 제공이 가능해야한다. 때문에 소프트웨어의 탄력성 관리와 이를 자동화할 수 있는 수단 마련이 필요하다.

 

핵심 검증 이후엔 ‘부가 매트릭스’

▲ SCM 서비스의 SaaS화, 플랫폼 사업화를 위한 부가적 검증사항

 

이제는 핵심은 아니지만 부가적으로 검증하면 좋을 3가지 매트릭스에 대해 이야기한다. 첫 번째는 인터페이스다. 소프트웨어는 ‘나의 기능을 다른 서비스에게’ 또는 ‘다른 서비스의 기능을 내가’라는 식의 인터페이스 요구가 많다. 특히 물류산업은 연결의 복합체라 할 수 있기 때문에 이 인터페이스에 대한 추가, 변경, 확장에 따른 작업 방식을 검증할 필요가 있다.

 

두 번째로 인터페이스 기능의 연장선에서 서로 다른 기술 프레임워크상의 상호 서비스 연동에 대한 검증이 필요하다. 마지막으로 앱 서비스 인프라 환경 변화시 발생하는 활동 유형과 비용에 대한 검증을 할 필요가 있다. 이를 통해 서비스 인프라 환경 변화에 얼마나 능동적이고 빠르게 대응할 수 있는지 사전 확인해야 한다.

 

마지막 검증, 얼마나 SaaS화 됐는가?

이제 마지막 검증이다. 자사의 소프트웨어가 얼마나 SaaS화가 돼있는지 ‘지표’로 측정해보자. SaaS화/플랫폼화 지수 측정은 GS/SP 등의 인증과는 다르다. 소스 품질이나 프로세스 품질의 이슈를 다루지 않고 고객 최적화 시점의 활동과 수단, 그리고 방식을 중심으로 한 COA화 성숙도 검증을 중시한다. (이 지표 측정 결과는 본고 마지막에 국내 물류 플랫폼에 대한 검증을 예시로 공개한다.)

 

국내 기업의 경우 대부분 서비스 개발이 업무 처리 기능 구현 중심으로 진행된다. 고객 최적화 활동을 위한 자동화 도구 탑재는 미약한 것이 맹점이다. 국내 대기업 물류 솔루션조차 업무 처리 기능의 범위나 효율에 대해서만 홍보하고 있는 것이 보인다. COA화를 위한 특별한 전략과 활동은 부재하다. 때문에 글로벌 소프트웨어 기업을 벤치마킹해 개발한 COA화 지수평가 모델로 국내기업을 검증해보면 그 점수가 매우 낮은 것이 현실이다. 국내 솔루션 서비스 기업들이 애플리케이션 SI/SM식 개발의 장벽에 아직도 갇혀 있음을 확인할 수 있다.

 

해결 방법은 단 한가지다. 기존의 개발 고정 관념을 버려야 한다. “이 서비스는 내가 없으면 유지 보수가 안돼”라는 잘못된 자긍심을 버려야 한다. 이제는 “내가 만든 서비스는 내가 없어도 다른 사람이 프로그램 손 안대고 고쳐 쓸 수 있어”라는 생각을 가져야 한다. 비즈니스 애플리케이션은 일반 소프트웨어와 달리 시장과 고객의 변화 요구가 많을 수밖에 없다. 그때그때 뛰어난 개발자 투입으로 해 나갈 수 있다는 보편적 생각을 버리지 않으면, 고객 최적화된 COA는 절대 나오지 않는다.

 

독점을 위한 상생을 만드는 법

앞서 정리한 검증 매트릭스와 ‘SaaS화/플랫폼화 지수’를 검토 항목으로 받아 내재화 시킨 것을 aPaaS(Application Platform as a Service)라 할 수 있다. 단언컨대 이를 통하지 않고서는 플랫폼의 사업화는 어렵다.

 

플랫폼 사업화의 목적은 ‘독점’이다. 플랫폼 중심의 서비스 생태계를 만들고 그에 대한 강한 통제 능력을 앞세워 시장을 독점하는 것이 최종 목적이다. 역설적으로 독점을 만드는 방법은 ‘상생’이다. 실제 글로벌 지배적인 소프트웨어 기업들은 설치형이든 서비스형이든 모든 소프트웨어가 독점이라는 목적을 달성할 수 있는 ‘상생’ 수단을 내재화하고 있다. 핵심 중추 서비스가 CRM(Customer Relationship Management, 고객관계관리)이냐 SCM이냐는 별로 중요하지 않다. 소프트웨어 중추 서비스를 변경해 사용, 확장하거나 전혀 다른 분야의 서비스를 추가하는 작업에 파트너들이 참가할 수 있도록 만들고, 일부는 고객사에서 직접 참여할 수 있는 수단을 제공하는 게 핵심이다.

 

상생을 만드는 방법을 내재화시킨 플랫폼을 ‘애플리케이션 플랫폼’이라 한다. 이를 클라우드상에 서비스하는 레이어를 aPaaS라 한다. 글로벌 SaaS전문 기업들은 중추 서비스와 aPaaS를 함께 서비스함으로 강력한 시장 지배력을 만들었다. 대표적인 기업이 세일즈포스(중추 서비스: CRM)와 서비스나우(중추서비스: ITSM)다. ERP와 SCM 솔루션의 강자인 SAP 역시 aPaaS 기반의 클라우드 서비스 전환을 통해 온오프라인 시장을 확대하고 있다.

 

aPaaS 레이어를 갖춘 앞서 설명한 서비스들과 국내 애플리케이션 서비스의 차이는 플랫폼 생태계의 ‘확장성’에서 나온다. 세일즈포스나 서비스나우 같은 기업들은 플랫폼을 자기 혼자 운영하려고 하지 않는다. 플랫폼 참가자들이 스스로 가치를 변경하고, 생성할 수 있도록 만든다. 이것을 필자는 ‘경기자형(참여형) 플랫폼’이라 칭한다.

 

반면 aPaaS 레이어가 없는 국내 대부분의 서비스들은 플랫폼이 제공하는 모든 서비스를 플랫폼 운영사가 직접 하는 ‘놀이동산형(중앙집중형) 플랫폼’을 벗어날 수 없다. 당연히 성장과 시장 확대에 한계를 가질 수밖에 없다.

 

오늘 이야기를 정리해본다. 결국 개발자가 변화에 대응하면 안 된다. 소프트웨어와 서비스 자체가 변화에 대응할 수 있어야 한다. 그리고 이를 위해서 가장 필요한 것이 애플리케이션의 가변성과 확장성이다. 다음 연재는 애플리케이션의 가변성과 확장성을 확보하기 위해 내재화시켜야 할 것이 무엇인지 살펴보겠다. (계속)