긍적적인 사고, 음식의 절제, 규칙적인 운동

[칼럼]SaaS, 대세론이 되기위한 조건
박재현 IT칼럼니스트 jaehyunpark.kr@gmail.com
2009.07.15 / PM 02:57SaaS, 클라우드 컴퓨팅

[지디넷코리아]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의 미래는 밝으나 그 아침은 그냥 오는 것은 아니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 홍반장

[칼럼]사용자 통지를 사소하게 다루는 IT조직들-1
최영석BSI코리아 심사위원 YoungSug.Choi@bsigroup.com
2009.07.17 / AM 09:38최영석

[지디넷코리아]국내 IT조직들을 관찰하면서 꼭 다루고 싶었던 문제점들 중에 하나가 ‘사용자 통지’에 대한 것들이다. 사용자 통지를 단순히 IT조직의 ‘친절함’을 사용자들에게 과시하는 정도로만 이해하고 있는 IT조직들이 아직도 많다.



통지를 제때 받지 못하거나, 전달에 실패하는 경우, 사용자들은 IT를 이용해서 본인의 업무를 처리하는 데 큰 불편을 겪거나, 불필요한 시간을 허비하게 된다. IT를 비즈니스와 연결시키는 큰 그림도 중요하지만, 실제 비즈니스 활동을 수행하는 사용자들이 IT를 사용함에 있어 겪는 불편함을 최소화하는 것도 중요하다는 것을 강조하고 싶다.



통지 시점, 통지 내용, 통지 대상자 및 통지 방법 등의 통지 활동 전반에 산재해 있는 문제들로 인해 사용자들을 지속적으로 소외(?)시키거나, 불만을 제기하게 만들고 있는 일부 IT조직에 대해 알아보자.
지면상 2회로 나누어서 다루어 보겠다.



■통지란 무엇인가?



통지(Notification)는 필요한 사람들에게 적절한 시기에 약속된 방법으로 정보를 알려주는 활동이다.



서비스 분야에서는 주로 접수 여부와 처리 결과를 알려주는 활동을 얘기하지만, IT분야에서는 장애와 변경과 같은 사건들이 발생하는 경우에도 통지가 일어나게 되므로, 일반적인 서비스 분야보다는 좀더 넓고 복잡하다고 할 수 있다.



통지는 발생하는 동기에 따라서 수동적인(Reactive) 통지와 적극적인(Proactive) 통지로 나누어 볼 수 있다.
수동적인 통지는 사용자의 요청이나 장애가 발생한 이후에 확인(confirmation)이나 정보공유의 목적으로 정보를 사용자에게 전달하는 것을 의미한다. 적극적인 통지는 사용자의 요청이나 장애가 발생하지 않았더라도, 사용자에 영향을 주는 사건이 발생했거나 발생할 것으로 예측되는 경우, 사용자들에게 미리 정보를 알려주는 적극적인 활동이다.



IT를 둘러싸고 발생하는 ‘사건’에 따라서는 ‘사용자 요청’에 대한 통지와 ‘변경 및 장애’에 대한 통지로도 나누어 볼 수 있다. ‘사용자 요청’에 대한 통지는 사용자에게 접수 확인, 진행 상태 및 이슈사항에 관련된 정보를 전달하는 것을 의미한다.



‘변경 및 장애’에 대한 통지의 경우는 사용자들에게 변경과 장애의 발생 사실, 진행 상태 및 이슈사항에 관련된 정보를 전달하는 활동으로 볼 수 있겠다.



■‘확인’ 통지가 부실한 경우



수동적인 통지이면서 사용자 요청에 관련된 ‘확인(confirmation)’ 통지는 가장 기본적인 통지 활동이라고 볼 수 있다. 패밀리레스토랑에 가서 주문을 할 때, 또는 계산할 때 우리는 ‘확인’ 통지를 경험한다. 주문한 내용을 접수하는 종업원이 주문내용을 ‘다시 한번’ 불러주거나, 계산 시 현금을 받은 경우 얼마를 받았다라고 굳이(!) 알려준다.



이렇게 귀찮을 정도로 확인을 해주는 이유는 무엇일까?



‘확인’ 통지는 요청자가 본인이 요청한 내용이 접수되었는지를 확신하게 해주는 좋은 실행사례 중의 하나다. 식당에서 추가적인 주문을 했을 때 종업원의 ‘확인’ 통지가 없는 경우, 계속 기다려야 하는 지 아니면, 다시 한번 외쳐야(!)하는지 고민한 경험을 떠올려 보면 이해를 할 수 있다.



‘확인’ 통지와 관련하여 국내IT조직의 현실을 살펴보자. 우선 사용자 요청을 전문적으로 처리하는 ‘서비스데스크(Service desk)’의 유무에 따라 ‘확인’ 통지의 적용 여부가 극명하게 갈린다.



서비스데스크가 없는 IT조직의 경우, 통지 활동 전반이 불규칙적이다. 이들 조직은 사용자의 요청을 접수하는 IT담당자가 ‘개발자’나 ‘운영자’와 같은 엔지니어인 경우가 대부분이고, 사용자 요청을 접수하고 통지하는 활동들을 대부분 ‘구두’로 처리하고 있다.



국내정서로 볼 때, IT엔지니어가 사용자 요청에 대해 친절하게 확인을 해주는 모습은 여전히 어색하며, 구두로 처리되는 접수 및 통지 활동은 IT담당자의 기억력이나 꼼꼼함에 의존할 수 밖에 없다.



서비스데스크가 있는 IT조직도 ‘확인’ 통지가 원활하지 않는 경우가 있다. 이들 조직의 대부분은 사용자 요청의 전 과정을 IT시스템으로 관리하고 있다. 하지만 일부 IT조직들은 IT시스템에는 ‘확인’ 통지 기능이 없거나, 있어도 사용하지 않고 있다는 사실을 발견하게 된다. 그 이유를 살펴보면, ‘확인’ 통지의 필요성을 이해하지 못하거나, ‘그런 것까지, 왜?’라는 다소 시니컬한 인식이 깔려있다는 것을 느끼게 한다.



■사용자 문의와 통지 관련 사례

사용자 문의에 대한 IT조직의 ‘통지’ 활동이 실제 어떻게 일어나고 있고 문제점이 무엇인지를 간단한 사례를 통해 알아보자. 한 사용자가 IT조직으로 전화를 했다. 본인이 사용하는 응용시스템에서 특정 값을 입력하면 에러가 발생한다고 한다. 입력기능이 처리가 되어야만 자신의 업무가 종료된다는 말을 덧붙였다.



접수한 IT직원은 사용자에게 접수내역에 대한 ‘확인’통지를 하고 IT조직의 내부의 개발자에게 문의한 결과 임시로 처리할 수 있는 방법을 알아냈으며, 이 문제를 근본적으로 해결하기 위해서는 응용시스템의 수정이 필요하다는 것을 확인했다.



IT직원은 임시로 처리할 수 있는 방법과 향후 응용시스템에 대한 수정될 것이라는 사실을 사용자에게 통지한 후, 요청 건을 종료 처리하였다.



1주일 후 동일한 사용자로부터 또 전화가 왔다. 언제까지 임시 처리 방법으로 사용해야 하는 지를 문의하였다. 상담원은 다시 개발자에게 확인하였고, 이미 응용시스템의 수정이 이틀 전에 완료되었다는 사실을 알게 되었고 정상적인 방법으로 응용시스템을 사용하면 된다는 내용으로 사용자에게 ‘통지’하였다.



■통지의 ‘연속성’ 문제



위의 사례에서, IT직원은 기본적인 ‘확인’ 통지와 ‘임시 처리 방법’에 대한 통지를 정상적으로 수행했다. 하지만 사용자가 임시 처리 방법을 언제까지 사용할 것인지, 즉 IT내부적으로 응용시스템의 수정이 완료되는 시점에 대해서는 미리 ‘통지’하지 않았다.



여기에서 통지의 ‘연속성’문제가 발생한다. 통지의 ‘연속성’은 ‘사용자 입장’에서의 궁금함과 불편함이 완전히 종료될 때까지, 필요한 정보를 적절한 시점에 사용자에게 전달하는 것을 의미한다.



위의 사례의 경우, 통지의 연속성을 보장하기 위해서는 ‘확인’통지-> ‘임시처리방법’통지->’문제완전해결’통지까지를 연속적으로 사용자에게 제공하여야 한다. 이 사용자는 언제까지 임시처리방법의 불편함을 감수해야 하는지가 궁금했으나, 이에 대한 IT조직의 통지가 없어서 이틀간의 업무 손해(?)를 떠안은 후에 결국 전화를 하게 된 사례다.



이처럼 사용자입장에서 연속적이지 않는 통지는, 또 다른 불만을 야기하거나, 기존 통지를 위한 IT조직의 ‘노력’을 평가절하시킬 수 있다.



■통지의 연속성을 어떻게 보장할 것인가?



IT내부의 프로세스를 잘 이해하고 있는 사람은 눈치챘겠지만, 위와 같은 통지의 연속성 문제를 해결하기 위해서는, IT 내부적으로 두 가지 문제를 해결해야 한다.



첫째는, 위와 같은 사용자 문의 건은 ‘문제완전해결’통지 전까지는 IT직원이 해당 요청 건을 종료하지 않아야 한다. 접수한 IT직원과 상위 관리자는 항상 ‘열려’있는 상태의 요청 건에 대해서만 관심을 가지고 처리하기 때문이다. 사용자 통지가 원시(!)적인 IT조직의 경우는 ‘확인’통지 이후 사용자 문의 건을 종료시키기도 한다.



둘째는, 사용자 문의 건을 해결하기 위해 응용시스템 수정이 완료되었다는 사실이, 접수한 IT직원에게 적절한 시기와 방법으로 ‘통지’되어야 한다. 이것은 IT조직내의 ‘사용자 요청 프로세스’와 ‘변경 프로세스’간의 인터페이스가 긴밀해야만 가능하다. IT직원을 통해 사용자 요청이 변경프로세스로 전달되고, 사용자 요청을 해결하기 위한 변경이 진행되며, 이 과정에서 변경의 ‘상태’를 포함한 정보가 다시 사용자 요청 프로세스를 거쳐, 최초 접수한 IT직원에게 전달되는 흐름이 일관성 있게 유지되어야 한다.



언급한 사례 이외에도 다양한 통지의 연속성 문제들을 만나게 된다. 이들 사례들을 근본적으로 해결하기 위해서는 IT내부 프로세스를 긴밀하게 가져갈 수 밖에는 없다는 사실을 알아야 한다. 다음 칼럼에서는 ‘통지로부터 ‘소외’되는 사용자’에 대한 이야기를 해 보겠다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 홍반장