SaaS(Software As A Service)는 오프라인을 통해 라이선스 단위로 거래되던 기존 소프트웨어 비즈니스 모델과 달리 온라인을 통해 소프트웨어를 이용하고 사용한 만큼 비용을 지불(Pay as you go)하는 모델이다.
이용자들 입장에서 SaaS는 인트라넷과 IT 시스템을 구축하는데 따른 위험을 줄일 수 있다. 관리 걱정 없이 언제 어디서나 해당 서비스에 접속하여 업무를 수행할 수도 있다. 딴데 신경쓰지 않고 핵심 사업과 업무에 만 집중하면 되는 것이다. 초기 투자 비용을 줄일 수 있으며 사용한 만큼 지불하면 되기 때문에 투자 대비 효과(ROI, Return Of Investment)가 높다는 것도 SaaS의 장점이다.
고객 입장 뿐만 아니라 업체 입장에서도 SaaS는 매력적이다. SaaS 업체는 안정적으로 예측가능한 고정 수익을 확보할 수 있을 뿐만 아니라 항상 고객과 함께 하기 때문에 적기에 시장에서 원하는 서비스나 기능을 추가할 수 있다. 개발과 지원, 판매와 마케팅 비용도 기존 소프트웨어 비즈니스 모델에 비해 저렴하다.
하드웨어 성능 증가와 가격 하락, 네트워크의 급속한 보급 등에 따른 클라우드 컴퓨팅 기술의 발전은 지금껏 SaaS의 미래를 장밋빛으로 예측하는데 부족함이 없었다. 실제 2003년 가장 최초로 SaaS라는 용어를 사용했던 가트너를 비롯해 여러 시장 예측 기관들은 앞다투어 SaaS 의 성공을 예견했었다.
그러나 현실은 순탄치만은 아닌 것 같다.
작년 12월 가트너가 미국과 영국에 있는 기업 333개를 대상으로 하여 조사해 이번에 발표한 'SaaS 사용 현황과 전망 보고서'에 따르면 향후 2년간 조사 대상 333개 기업중 58%가 현수준을 유지, 32%가 확장하겠다고 했으며 5%가 축소, 5%는 중단하겠다고 한다. 서비스를 확장하겠다는 기업보다 유지하겠다는 기업이 많다는 것은 현재 제공되는 SaaS 서비스에 문제가 있다는 것을 의미한다.
실제 가트너 보고서에 따르면 이러한 원인이 예상보다 높은 비용(42%), 그리고 기존 레거시 애플리케이션과 통합의 어려움(38%), 기술적 요구를 만족시키지 못함(33%) 등 사용자 만족도 측면에 있다고 분석했다.
또 SaaS 도입시 기업이 가장 중요시 여기는 점은 기술적 요구 사항 지원(46%), 보안(33%) 그리고 통합 용이성(29%), 사업부의 요구 사항 지원(29%)순으로 조사되었다.
지금껏 SaaS 업계는 비용적인 측면에서 SaaS가 기존 방식보다 저렴하며 , OpenAPI와 통합 플랫폼을 통해 기존 애플리케이션과 쉽게 통합할 수 있다고 주장해 왔다. 또 간단한 설정과 개방된 개발 환경을 통해 사용자가 원하는 요구 사항을 손쉽게 반영할 수 있다고 강조해왔다.
가트너 보고서에 따르면 이러한 SaaS업계의 주장이 현실과 괴리가 있음을 알 수 있다. 과연 이러한 문제를 어떻게 해석하고 해결해야 할까.
먼저 , 비용측면에서 SaaS 업체는 서비스 총소유비용(TCO,Total Cost of Owbership)을 줄여야 한다. 실제 소프트웨어 1종을 구매하면 해당 라이선스 구매 비용, 관리 비용, 업그레이드 비용, 기술 지원 비용, 유지보수 비용 등 전체 TCO는 구매 비용의 3~4배 정도가 된다고 알려져 있다. 이에 비해 SaaS는 라이선스 구매 없이 사용한 만큼 비용을 지불하면 될 뿐 관리,업그레이드,기술지원 등의 부가 비용 지불은 발생하지 않는 것이 정상적이다.
그러나 실제 현실은 그렇치 않은 것 같다. 많은 SaaS 업체들은 컨설팅 비용 등의 명목으로 고가의 비용을 요구하는 것으로 알려져 있다. 이러한 비용을 줄이거나 없애야 한다. 이를 통해 고객에게 직접적인 비용 절감 효과를 제공해야 한다.
기술적으로 고객의 레거시 애플리케이션과 통합할 수 있는 현실적인 방안도 제공해야 한다. 기업이 보유하고 있는 많은 레거시 애플리케이션은 보통 비표준 API를 사용한다. 이러한 애플리케이션을 SaaS 서비스에 보다 손쉽게 연결할 방법을 제공해야 한다. 단순히 SOAP과 Rest 방식의 OpenAPI 를 제공하는 것만으로는 통합이 어렵다.
과거 대용량 메일 발송 SaaS 서비스를 이용한 적이 있었다. 이 서비스를 이용하기 위해서는 고객 DB를 연계해야 만 했는데 가능한 방법이 2가지였다. 하나는 배치 방법으로 스프레드시트에 고객 파일을 넣어서 FTP로 보내는 방법이었고 다른 하나는 고객 DB를 열어 주는 것 이었다. 별 수 없이 고객 DB를 열어 줄 수 없어 배치 방법을 사용했지만 정말 황당한 상황에 끔찍한 결정이었다.
만약 이런 경우 해당 업체가 레거시 시스템을 연동하기 위한 서비스 연계 모듈을 제공했다면 쉽게 해결 할 수 있었을 것이다. 이 연계 모듈을 고객 방화벽내에 설치한 후 레거시 DB 시스템을 연계하고 아웃바운드 보안 연결을 통해 고객 정보를 전달할 수 있다. 특히, 해당 고객 정보를 별도로 저장하지 않고 바로 활용한 후 삭제함으써 보안성을 높일 수 도 있다. 이렇듯 고객의 현실에 기반한 해결 방안을 제공해야 한다.
빌링 SaaS 서비스 업체인 OpSource는 바로 이러한 방법을 사용하여 레거시 응용 시스템을 빌링 서비스와 연계한다. Opsource는 고객에게 에이전트 SW를 제공한다. 이 에이전트 SW는 고객 방화벽 내에 위치하면 레거시 시스템으로 부터 고객 정보와 고객의 사용 정보 등을 안전하게 빌링 서비스에 제공하여 빌링 요청을 처리한다. 이처럼 기존의 레거시 애플리케이션을 효율적으로 통합할 창의적인 방법을 제공해야 한다.
SaaS 입장에서 고객의 기술적 요구를 만족시키지 못한다는 것은 동전의 양면일 수 밖에 없다. SaaS는 규모의 경제가 달성됐을 때 성공한다. 다시 말해, 고객이 어느 정도 수준에 도달했을 때 수익을 내며 그 임계치를 넘는 순간 수익율은 가파르게 증가한다.
그러나 증가하는 고객에 비례해서 증가하는 고객의 기술적 요구 사항에 따라 시스템에 손을 댈 수 도 없다. 개별 요청에 따라 시스템에 손을 대는 순간 일관되게 서비스를 개발하느 것이 어려워진다. 마치 과거 SI에 기반한 솔루션 구축 사업과 별 차이가 없어진다.
현재 SaaS에서는 이러한 고객 요구 사항을 수용할 방법으로 사용자가 원하는 데이터 필드를 서비스에 추가하여 자신이 원하는 서비스를 구성할 수 있게 해주는 메타 데이터 기술을 제공한다. CRM 업체인 Salesforce와 Netsuite 같은 업체들은 자신의 SaaS 서비스와 데이터를 기반으로 한 개발 플랫폼을 제공하기도 한다.
그러나 이러한 방법은 자신의 플랫폼을 중심으로 애플리케이션을 개발하는 것이지 고객의 SaaS 서비스 자체에 대한 기술적 요구사항을 수용하기 위한 방법은 아니다. 그러나 긍정적인 면에서 이러한 고객의 기술적,기능적 요구 사항을 수용하는 과정은 SaaS 서비스를 강화하는 데 있어 큰 밑거름이 될 것이다.
실제, 이 달 7월 12일 베타 꼬리표를 뗀 구글 앱스는 2년 동안 175만 개의 기업이 사용하는 과정에서 많은 시행착오를 겪었다. 이 과정에서 구글앱스는 중소기업 뿐 만 아니라 대기업에서 구글 앱스를 사용할 때 필요한 기능과 기업이 이미 사용하고 있는 레거시 애플리케이션과의 통합을 위한 기능을 추가했다. 실제 , LDAP 동기화 기능인 구글 앱스 디렉터 싱크 기능을 제공함으로써 기존 익스체인지 서버나 도미노 서버의 사용자 정보를 연동 가능하게 해주었다. 이 기능은 과거 구글이 합병한 이메일 보안 및 아카이빙 전문업체인 포스티니를 통해서 개발한 것이다.
물론 구글 앱스가 기업의 모든 기술적 요구사항을 만족시킨다고 말할 수는 없다. 하지만 기존의 기업 고객이 원하는 것을 미리 파악하고 이 부분을 해결하기 위한 노력이 없다면 결코 고객을 만족시킬 수 없으며 다가갈 수 없다는 것을 잘 보여준다고 할 수 있다. 이러한 측면에서 구글은 아주 영리한 SaaS 공급자이다.
이구동성으로 국내 소프트웨어 업계의 고사위기에 대해 이야기 하고 있다. SaaS야 말로 기존 대형 SI 회사들의 거미줄에 걸려있는 국내 소프트웨어 업체들이 정당한 대가를 받고 자립할 수 있는 대안중 하나이다. 그러나 성공적인 SaaS 서비스를 위해서는 "개방 전략"이 필요하다. 업체간에 연동과 기술 공유, 그리고 기존 레거시 시스템 연동을 위해 플랫폼을 개방(Open)하며 실제 이를 이루기 위해 진정한 위한 오픈 마인드를 가져야 한다.
과거 필자는 국내 그룹웨어 시장의 대부분을 차지하고 있던 업체와 결제 시스템을 연동하기 위한 제휴를 진행한 적이 있었다. 막대한 개발비를 요구하였으며 고압적인 자세때문에 협상에 애를 먹었었다. 결론적으로 울며 겨자먹기 식으로 상당한 금액을 주고 SDK를 받아 연동을 했었다. 얼마 후 반대의 상황이 발생했었다.
필자가 경영하던 회사의 제품을 사용하던 고객이 해당 그룹웨어를 도입했는데 이 때는 반대로 해당 그룹웨어를 필자의 제품에 연동을 해야 했었다. 마치 복수하듯이 기존에 요청했던 금액보다 휠씬 많은 금액을 요구했었다. 실제 곰곰히 생각해 보면 어느 누구도 얻은 것 없었다. 물론, 대형 SI 회사는 여전히 수익을 챙겼었지만.
만약 서로 간에 합리적인 제휴를 통해 솔루션을 연계하고 이를 바탕으로 고객에게 보다 질 높은 솔루션을 제공했다면 분명 더 많은 것을 얻었을 것이다. 마찬가지로 지금 태동하는 SaaS도 무엇보다도 앞서 언급한 것들이 요구된다 할 수 있다. 분명 SaaS의 미래는 밝으나 그 아침은 그냥 오는 것은 아니다.
*본 칼럼 내용은 본지 편집방향과 다를 수 있습니다.
