SaaS의 미래 , 장미빛만은 아니다.


SaaS(Software As A Service)는 오프라인을 통해 라이센스 단위로 거래되던 기존의 소프트웨어 비지니스 모델과 달리 온라인을 통해 소프트웨어를 이용하고 사용한 만큼 비용을 지불(Pay as you go)하는 소프트웨어 비지니스 모델이다.

사용자 삽입 이미지


이용자 들 입장에서 SaaS는 인트라넷과 IT 시스템을 구축하는 데서 발생하는 위험을 줄일 수 있다. 또한 관리 걱정 없이 언제, 어디서나 해당 서비스에 접속하여 업무를 수행할 수 도 있다. 이렇게 함으로써 고객은 다른 걱정없이 자신의 핵심 사업과 업무에 만 집중하면 된다. 또한 초기 투자 비용을 줄일 수 있으며 사용한 만큼 지불하면 되기 때문에 투자 대비 효과(ROI, Return Of Investment)도 높다.

고객 입장 뿐만 아니라 업체 입장에서도 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는 고객에게 에이전트 S/W를 제공한다. 이 에이전트 S/W는 고객의 방화벽 내에 위치하면 리거시 시스템으로 부터  고객 정보와 고객의 사용 정보 등을 안전하게 빌링 서비스에 제공하여 빌링 요청을 처리한다. 이처럼 기존의 리거시 어플리케이션을 효율적으로 통합할 창의적인 방법을 제공해야 한다.

SaaS 입장에서 고객의 기술적 요구를 만족시키지 못한다는 것은 동전의 양면일 수 밖에 없다. SaaS는 규모의 경제가 달성됐을 때 성공한다. 다시 말해, 고객이 어느 정도 수준에 도달했을 때 수익을 내며 그 임계치를 넘는 순간 수익율은 가파르게 증가한다.  그러나 증가하는 고객에 비례해서 증가하는 고객의 기술적 요구 사항에 따라 시스템에 손을 댈 수 도 없다. 개별 요청에 따라 시스템에 손을 대는 순간 일관되게 서비스를 개발하느 것이 어려워진다. 마치 과거 SI에 기반한 솔루션 구축 사업과 별 차이가 없어진다.

현재 SaaS에서는 이러한 고객 요구 사항을 수용할 방법으로 사용자가 원하는 데이타 필드를 서비스에 추가하여 자신이 원하는 서비스를 구성할 수 있게 해주는 메타 데이타 기술을 제공한다. 또한 CRM 업체인 Salesforce와 Netsuite 같은 업체들은 자신의 SaaS 서비스와 데이타를 기반으로 한 개발 플랫폼을 제공하기도 한다. 그러나 이러한 방법은 자신의 플랫폼을 중심으로 애플리케이션을 개발하는 것이지 고객의 SaaS 서비스 자체에 대한 기술적 요구사항을 수용하기 위한 방법은 아니다.  그러나 긍정적인 면에서 이러한 고객의 기술적,기능적 요구 사항을 수용하는 과정은 SaaS 서비스를 강화하는 데 있어 큰 밑거름이 될 것이다.

실제, 이 달 7월 12일 베타 꼬리표를 뗀 구글 앱스는 2년 동안 175만 개의 기업이 사용하는 과정에서 많은 시행착오를 겪었다. 이 과정에서 구글앱스는 중소기업 뿐 만 아니라 대기업에서 구글 앱스를 사용할 때 필요한 기능과 기업이 이미 사용하고 있는 리거시 애플리케이션과의 통합을 위한 기능을 추가했다. 실제 , LDAP 동기화 기능인 구글 앱스 디렉터 싱크 기능을 제공함으로써 기존 익스체인지 서버나 도미노 서버의 사용자 정보를 연동 가능하게 해주었다. 이 기능은 과거 구글이 합병한 이메일 보안 및 아카이빙 전문업체인 포스티니를 통해서 개발한 것이다.

물론 구글 앱스가 기업의 모든 기술적 요구사항을 만족시킨다고 말할 수는 없다. 하지만 기존의 기업 고객이 원하는 것을 미리 파악하고 이 부분을 해결하기 위한 노력이 없다면 결코 고객을 만족시킬 수 없으며 다가갈 수 없다는 것을 잘 보여준다고 할 수 있다.  이러한 측면에서 구글은 아주 영리한 SaaS 공급자이다.

이 구동성으로 국내 소프트웨어 업계의 고사위기에 대해 이야기 하고 있다.  SaaS야 말로 기존 대형 SI 회사들의 거미줄에 걸려있는 국내 소프트웨어 업체들이 정당한 대가를 받고 자립할 수 있는 대안중 하나이다. 그러나 성공적인 SaaS 서비스를 위해서는 "개방 전략"이 필요하다.  업체간에 연동과 기술 공유, 그리고 기존 리거시 시스템 연동을 위해 플랫폼을 개방(Open)하며 실제 이를 이루기 위해 진정한 위한 오픈 마인드를 가져야 한다.

과거 필자는 국내 그룹웨어 시장의 대부분을 차지하고 있던 업체와 결제 시스템을 연동하기 위한 제휴를 진행한 적이 있었다. 막대한 개발비를 요구하였으며 고압적인 자세때문에 협상에 애를 먹었었다. 결론적으로 울며 겨자먹기 식으로 상당한 금액을 주고 SDK를 받아 연동을 했었다. 얼마 후 반대의 상황이 발생했었다. 필자가 경영하던 회사의 제품을 사용하던 고객이 해당 그룹웨어를 도입했는데 이 때는 반대로 해당 그룹웨어를 필자의 제품에 연동을 해야 했었다. 마치 복수하듯이 기존에 요청했던 금액보다 휠씬 많은 금액을 요구했었다. 실제 곰곰히 생각해 보면 어느 누구도 얻은 것 없었다. 물론, 대형 SI 회사는 여전히 수익을 챙겼었지만.

만약 서로 간에 합리적인 제휴를 통해 솔루션을 연계하고 이를 바탕으로 고객에게 보다 질 높은 솔루션을 제공했다면 분명 더 많은 것을 얻었을 것이다. 마찬가지로 지금 태동하는 SaaS도 무엇보다도 앞서 언급한 것들이 요구된다 할 수 있다. 분명 SaaS의 미래는 밝으나 그 아침은 그냥 오는 것은 아니다.

본 고는 ZDnet 컬럼에 기고한 글입니다.

Posted by 박재현
,

스마트폰을 통한 모바일 환경이 일상화 되면서 웹 클라우드와 모바일 디바이스간의 동기화는 아주 중요한 기본 서비스로 자리잡고 있습니다. 가령, RIM의 블랙베리는 Push Mail을 앞세워 비지니스 맨들의 문화를 바꾸면서 이 분야의 강자로 자리잡았습니다. 이러한 Push Mail의 구현 방법중 하나가 바로 씽크 기술을 이용하는 것 입니다. 간략히 모바일 클라우드와 동기화 서비스의 현황에 대해 정리해 봅니다. ( 참고로 아래 그림들은 테크런치에 올라온 싱크 솔루션에 대한 비교 자료에서 발췌한 것 입니다. 해당 자료는 실제 오픈소스  씽크 솔루션과 플랫폼 제공업체인 Funambol에서 작성한 자료입니다. )


1. 동기화 대상

아래 그림은 모바일 클라우드와 모바일 디바이스간의 동기화 대상을 정리한 것 입니다. 전체적으로는 사진과 주소록, 전자우편,소셜 네트웍,일정 데이타가 현재 주요한 동기화 대상임을 알 수 있습니다. Apple MobileMe와 Funambol, MS Myphone,Nokia OVI,Plam Synergy 에서 이들 데이타를 동기화해주고 있습니다. 아마 다른 서비스들도 조만간 이들 데이타의 동기화를 모두 제공할 것입니다.
 
사용자 삽입 이미지

개인적으로는 앞선 데이타 타입들 외에 사용자 정의 데이타(User defined data type)에 대한 동기화의 지원 여부가 중요한 경쟁요소가 될 것이로 보입니다. 현재 모바일 플랫폼의 개발 환경이 개방화되면서 개발자들이 자발적으로 많은 어플리케이션을 개발하고 있습니다. 또한 핸드폰 뿐만 아니라 디자탈 액자, TV 등 다양한 디바이스간 동기화가 필요하기 때문에 보다 어플리케이션에서 사용자가 정의한 데이타에 대한 동기화 지원이 아주 중요해 질 것으로 보입니다.

사용자 정의 데이타외에 또 하나 중요한 동기화 대상은 외부 서비스 데이타(External service data type)에 대한 동기화입니다. 다음은 현재 각 동기화 서비스서 지원하는 외부 쇼셜 서비스의 대상이다. 현재 플리커와 페이스북에 대한 동기화를 주로 지원하고 있습니다. 그러나 현재 이들 서비스외에 Twitter나 Friendfeed같은 실시간 마이크로블러깅 등 모바일 분야의 Killer Application 들에 대한 지원이 주요한 경쟁력으로 부각되고 있습니다.

사용자 삽입 이미지

2. 비용

대부분의 서비스가 무상으로 제공되고 있음을 알 수 있습니다.  아마 기본 서비스는 무상으로 제공되겠지만 백업이나 기타 다른 디바이스로의 Restore 등 기타 부가 기능을 제공한 프리미엄 버전이 동시에 제공될 것입니다.

사용자 삽입 이미지

3. 동기화 방법

단순히 모바이 디바이스상의 데이타를 웹상의 모바일 클라우드로 백업을 하는 개념의 동기화하면 그 구현은 단순할 것입니다. 그러나 양방향으로 실시간에 이들 데이타를 동기화하기 위해서는 많은 고민이 필요합니다. 특히, 모바일 디바이스는 장비 특징상 대기 시간이 길수록 밧데리가 빨리 소모하며, 고정 IP가 아니라 수시로 IP가 변경되는  특징들 때문에 보다 스마트한 구조를 필요로 합니다. 일반적으로는 기존의 SyncML을 사용하거나 블렉베리 처럼 자체 개발한 표준 방법을 사용하여 개발합니다.

사용자 삽입 이미지

- 자체 개발한 미들웨어와 프로토콜 사용
현재  Push Mail을 가장 먼저 서비스한 RIM의 블랙베리는 기존의 메일 서버와 블랙베리 디바이스 간에 자체 개발한 미들웨어와 프로토콜을 사용하여 기존 메일 서버를 모니터링한 후 새로운 메일을 가져와서 블랙베리 디바이스에 Push를 합니다. 이 때 사용하는 프로토콜은 자체 개발한 것 입니다.  
 
- 기존 표준 방법의 확장 모델
기존의 대표적인 디바이스상의 동기화 방법은 SyncML을 이용하는 것입니다. 따라서 많은 동기화 서비스들은 HTTP(S) 프로토콜과 SyncML에 기반하여 개발합니다. 메일의 경우에는 IMAP IDLE(RFC2177) 커멘트를 사용하여 동기화를 하기도 합니다. IMAP IDLE 커멘트는 디바이스가 메일을 받을 수 있는 상태라는 것을 알려주는 커맨트입니다.

아래 그림은 MS에서 구현한 Direct Push 란 Push mail 모델입니다. Exchange server 2007에 구현되어 있는 이 방법은 Device가 Long-standing https로 동기화를 요청하면 이에 따라 사용자의 메일 박스의 상태를 점검하여 새로운 메일을 Device에 HTTP 프로토콜을 통해 SyncML로 Push를 해 줍니다.

사용자 삽입 이미지

모바일 디바이스를 이용하다 보면 간혹 디바이스를 잃어버리거나 다른 디바이스로 변경을 할 경우가 종종 발생합니다. 이 때, 가장 필요했으면 하는 기능이 바로 기존의 정보를 백업하거나 해당 정보를 다른 디바이스로 쉽게 옮기는 것입니다. 이처럼 모바일 환경이 일반화되면서 모바일 디바이스와 웹 클라우즈, 모바일 디바이스간 동기화는 아주 중요한 기본 서비스로 자리 잡을 것 입니다. 또한 외부 쇼셜 서비스를 비롯하여 새롭게 개발되는 모바일 웹 어플리케이션에서 동기화 기능은 필수적인 기능이 될 것 입니다. 


Posted by 박재현
,

최근에 애플은 아이폰 SDK 3.0을 소개를 했습니다. 각각의 기능들을 다른 SDK들과 비교한 자료가 눈에 띠어 공유해 봅니다. - http://i.gizmodo.com/5173865/giz-explains-what-makes-the-five-smartphone-platforms-different. 표를 통해 각 SDK간의 주요 차이를 일목요연하게 정리해 볼 수 있을 것 같습니다.

사용자 삽입 이미지

기능 위주의 비교와 더불어 현재 각 SDK들은 놀라운 속도로 기능과 성능을 업그레이드하고 있습니다. 가히 전쟁이라 할 수 있습니다. 아래 일정은 최근 심비안에서 발표한 2009년 이후의 Release 일정입니다.

사용자 삽입 이미지

2010년까지 3번의 Major Release가 잡혀있는 걸 보면 상당한 변환가 기대됩니다. 또한 기존 심비안 개발자에게 안정적인 일정을 미리 제공함으로써 커뮤니티 개발자의 동요를 막는 효과가 있을 것 입니다. 이처럼 현재 모바일 SDK는 전쟁에 있어 기능의 차별화 더불어 속도는 가장 중요한 경쟁력인 것 같습니다. 이런 걸 디지탈 사시미전략이라고 하죠...^-^  - 디지탈 사시미 전략과 소프트웨어 개발


Posted by 박재현
,

OpenAPI를 사용하여 개발을 하다 보면 가장 필요한 것이 바로 원하는 OpenAPI를 찾고 해당 API가 원하는 결과를 만들어 내는 지 확인하는 과정일 것 입니다. 일반적으로 가장 쉬운 방법이 직접 해당 OpenAPI로 샘플 코드를 작성하고 해당 코드를 수행해 보는 것 입니다. 사실 아주 번거로운 방법입니다.

개발자에게 이러한 번거로운 과정을 덜어주기 위해서는 일련의 테스트 베드 환경을 제공해야 합니다. 개인적으로도 최근 진행하는 업무 중 이러한 환경을 제공하는 것이 있습니다. 실제 곰곰히 고민해 보면 이것저것 해야 할 것들이 많습니다. 더미 코드를 만들어야 하고 실 서버의 성능상에 영향을 주지 않는 구조를 고민해야 하구요..

최근에는 구글이 Ajax APIs Playgrodund 라는 OpenAPI의 테스트베트 환경을 제공해 주기 시작했습니다. 요즘같이 어려운 상황에서 카탈로그 검색, Dodgeball, Jaiku, Mashup Editor 등의 서비스를 내리기로 했던  구글 입장에서 보면 Ajax APIs Playgrodund의 중요성을 짐작할 수 있습니다.

구글 Ajax APIs Playgrodund는 다음과 같은 OpenAPI를 제공하고 있습니다.

실제 화면으로 보면 개발자는 원하는 OpenAPI를 검색하며 선택하면 이에 해당하는 자바 스크립트 코드가 제공되며 하단에 해당 코드를 실제 수행하여 결과를 확인해 볼 수 있다. 해당 결과가 원하는 결과라면 실제 자바 스크립트 코드를 복사하여 개발을 수행할 수 있습니다. 아래 화면은 Earth API에서 maps API에 Geocoding을 넣어서 결과를 얻는 화면입니다.

사용자 삽입 이미지

과거에 비해 개발 과정에서 많은 생산성 향상이 있습니다. 실제 구글에서는 25% 이상의 효과가 있다고 합니다. 구글과 마찬가지로 MS에서도 이와 유사한 테스트베트를 제공합니다. MS Mesh 개발 툴중에 LiveFx Resource Browser라는 OpenAPI 테스트 베드를 제공하고 있습니다.

사용자 삽입 이미지

LiveFXResourceBrowser는 MS의 LiveFX 프레임웍에서 제공하는 OpenAPI를 브라우징하면서 원하는 결과 타입(ATOM,Json,POX,RSS)을 실시간에 변경하여 확인할 수 있다.

'SaaS-Cloud' 카테고리의 다른 글

Above the Cloud  (0) 2009.05.06
클라우드 기반의 서비스 개발 환경 - Aptana on the DaaS  (2) 2009.05.01
Context Cloud Computing  (1) 2009.04.13
Adsense for image  (1) 2009.04.09
Amazon S3 현황  (2) 2009.03.31
SaaS(Cloud) Directory  (0) 2008.12.25
OpenID와 SaaS 서비스  (0) 2008.12.25
SaaS 기술 동향 - 2008년 10월  (0) 2008.10.28
구글 G메일 다운과 SaaS  (0) 2008.10.18
SaaS Taxanomy  (0) 2008.10.08

Posted by 박재현
,

독일에 출장을 왔습니다. 잠자리가 바뀌면 잠을 잘 못자는 스타일에 첫날 시차 적응에 완전히 실패하여 독일의 밤을 하얗게 새우고 있습니다. 항상 브라우져 툴바를 통해 구글 메일을 체크하다가 직접 구글 메일의 URL을 입력하였더니 아래와 같은 메세지가 나오네요.. http://gmail.com

사용자 삽입 이미지

그래서 확인차 http://gmail.de 이라고 입력했더니 독일에서 Gmail은 구글 메일이 아니라 독일업체에서 운영하는 메일 서비스였습니다.

사용자 삽입 이미지

Gmail의 브랜딩을 할 때 글로벌 브랜딩을 고려했을 텐데 독일에서 사용을 못한다는 게 의외네요. 독일 지역내에 있는 사용자들에게 gmail 이란 이름으로 메일 서비스를 못하는 것을 알고 한건지 아니면 모르고 한건지....정말 글로벌 서비스는 기술적인 측면외에 다른 부분으로도 점점 더 어려워 지는 것 같습니다. 변호사들도 제대로 모르고 있으니.. 누가 이런 분야에 법률자문하면 앞으로 대박나지 않을까 싶습니다.^-^

Posted by 박재현
,