기업에서 빅데이타의 성공을 위한 고민


필자는 아주 오래전 데이타웨어 하우스 구축팀에서 DW 구축 및 관련 솔루션을 개발한 경험이 있다. 모 백화점과 자동차 그리고 보험사의 고객 데이타를  DW로 구축 후 교차 분석하여 각각의 제품 판매를 촉진하는 방법을 도모하는 것이었다.  온갖 고생을 하여 데이타를 정제하고 DW 모델링을 하고 OLAP 을 하는 등 많은 데이처 처리를 하였다. 



공교롭게 빅데이타가 유행하고 있는 지금 ,  (물론 하둡같은 새로운 기술이 나왔지만) 데이타를 처리하고 분석하는 기본 과정에는 큰 변함이 없다. 또한  같은 질문이 나온다. 


과거 CRM 처럼 빅데이타도 유행아니냐? CRM과 마찬가지로 빅데이타 

또한 실패할 것이다. 


라는 것이었다. 맞는 말이기도 하고 틀린 말이기도 할 것이다.


잠시 현재 빅데이타 처럼 유행했던 CRM이 실패한 이유가 무엇인지 살펴보자.


1) 최대우 한국외대 교수(통계학)는 현업 사용자의 외면에서 그 답을 찾는다. 


△실무자들이 사용하기 어려운 시스템 △시스템 사용을 강제하지 않는 기업 문화와 업무 프로세스 △데이터 ‘분석’이 아닌 집계에 불과했다는 점 등이 실무자들의 데이터 분석 회의론 등 총체적인 난국을 만들어냈다는 것이다.

 

데이터 분석은 데이터로부터 비즈니스 의미와 가치를 도출해야 한다. 그러나 데이터는 ‘분석’되지 않고 ‘집계’되었으며 집계 수준의 보고서는 실무자들의 실망을 낳았다. 나아가 데이터 분석 회의론, 무용론 등 데이터 분석에 대한 불신으로까지 이어졌다 (2013년 전자 신문 기사에서).



2) 다음은 가트너에서 정리한  기업들이 CRM을 도입하면서 실패한 7가지 이유이다. 


△ 내부 데이타에 대한 무시  전사 적용이 아니라 일부에 만 적용  기술 조직과 업무 조직간의 협업 부족  장기 전략 부재 △ 문제 있는 내부 프로세스의 개선 부재  고객 중심이 아니라 기업 중심의 서비스  직원들의 기술 숙련도 부족.


3) 구글링을 해보면 수없이 많은 CRM 실패 사례와 이유들이 나온다.  


빅데이타가 이런 전철을 밟지 않으려면 어떻게 해야 할 까? 정답은 아무도 모르지만 필자의 생각은 빅데이타를 스마트 데이타로 만들어야 할 것이다. 


구슬이 서말이라도 꿰어야 보배


아무리 많은 데이타를 모아 빅데티타를 만들어도  이 빅데이타를 꿰어야 보배가 된다. 


구글은 인터넷상의 모든 데이타를 수집하고 이 데이타를 검색이라는 손쉬운 꿰는 방법을 통해 사용자들이 본인들이 원하는 보배를 얻도록 해 주었다. 특히, 랭킹 이라는 방법을 통해 보배를 아주 쉽게 고를 수 있도록 해주었다. 더 나아가 이제는 구글 나우라는 컨텍스트 기반의 검색/추론 방법을 사용하여 사용자의 상황에 맞는 정보를 스스로 제공해주는 서비스로 발전하고 있다. 마찬가지로 페이스북은 수십억 사용자의 쇼셜 데이타를 모으로 이를 분석한 후 ,  쇼셜 그라프를 통해 페이스북 플랫폼의 고객인 개발자들에게  보배를 만들 기회를 준다.      


현재 빅데이타를 생각해 보자.  


현재 기업들에서 구축,활용하고 있는 대부분의 빅데이타는 분석을 통해 통계 정보를 제공한다. 이러한 통계 정보는 이해하기 어렵고 , 활용하기는 더더욱 어렵다. 더구나 이 통계 정보를 스스로 찾고 만들어 활용하는 더더더욱 어렵다.  이러한 활용 환경으로는 보배를 절대 꿰어낼 수 없다.


구글의 검색 엔진이나 구글 나우 같은 추천 기능 등 기업내 구성원들이 이를 손쉽게 활용하기 위한 방법을 고민해야 한다. 


기업들은 내부 생산성을 높이고 지식을 공유하기 위한 방법으로 기업 내부의 모든 기간 시스템과 컨텐트 및 지식, 업무 프로세스를 하나의 시스템 접접인 기업 지식 포탈에 모으는 작업을 하였다. 모든 기업 구성원은 이 기업 포탈을 통해 회사의 모든 프로세스와 지식에 접근하고 활용한다. 


기업내 빅데이타가 성공하기 위해서는 이러한 기업 포탈의 접점에서 사용자 관점에서 수집된 내.외부 데이타를 손쉽게 검색하여 활용하고 이를 공유하는 환경을 만들어야 한다. 그래야 빅데이타를 통해 기업 구성원들이 보배를 만들어 낼 수 있다.


Posted by 박재현
,

빅데이타 성공 요인 ,  人 人 人.



2001년 가트너에서 발표한 7 key reasons for CRM failures” 이란 보고서에는 CRM을 기업들이 도입하면서 실패한 7가지 이유를 다음과 같이 설명하고 있다. 


1) 내부 데이타에 대한 무시 , 2)전사 적용이 아니라 일부에 만 적용 , 3) 기술 조직과 업무 조직간의 협업 부족 , 4) 장기 전략 부재 , 5) 문제 있는 내부 프로세스의 개선 부재 , 6) 고객 중심이 아니라 기업 중심의 서비스 , 7) 직원들의 기술 숙련도 부족. 


위의 가트너에서 설명하고 있는 7가지 원인들의 근본 원인은 바로 CRM을 추진하는 조직과 인력, 즉 사람이 문제라 할 수 있다. 최근 많은 양의 다양한 데이타가 엄청난 속도로 발생하고 있는 현실에서 이들 빅데이타를 효율적으로 활용하여 기업의 경쟁 우위와 새로운 비지니스 기회를 만들려는 노력이 다양한 분야에서 진행되고 있다. 


이들 분야에서 진행중인 빅데이타 과제가 성공하기 위해서는 첫째도 사람, 둘째도 사람 그리고 세째도 사람이라는 생각을 갖고 장기적인 관점에서 진행을 해야 한다.  왜냐하면 , 유행하는 빅데이타 솔루션을 사용하여 데이타를 모으고 이를 분석 툴로 분석한다고 해서 원하는 것을 얻을 수 있는 것이 아니기 때문이다. 빅데이타를 통해서 경쟁우위의 인사이트를 얻기 위해서는 빅데이타라는 도구를 능숙히 사용하여 가치있는 것을 찾아 내고 이를 적용할 수 있는 사람과 조직이 중요하기 때문이다. 



먼저, 실무 현업 전문가와 이들로 부터 현장의 문제를 수집하고 ,  이를 해결하기 위한 방안을 모델링 하는 데이타 분석가가 필요하다. 또한 기술적으로 데이타 분석가가 모델링한 방법을 구현할 전문 개발자와  대용량 빅데이타 인프라를 안정적으로 운영하기 위한 인프라 담당가가 필요하다.  그리고 무엇보다도 이들 인력들간의 원활한 소통과 정확한 업무 판단과 결과를 책임질 빅데이타 과제를 이끌어 나갈 빅데이터 코디네이터가 필요하다.  



이들 각각의 기대되는 역할은 다음과 같다. 



1) 기획 중심

  • 현장 전문가  -  해당 분야의 고객 요구 사항을 잘 이해하고 있고 , 고객의 입장에서 실제 업무를 수행한다.
  • 데이타 분석가 - 현장 전문가로 부터 요구사항을 수집하고 이들로 부터 분석 요건을 도출하며 이를 바탕으로 테스트 데이타와 개발을 위한 상세 설계를 수행한다. 또한 데이타이 보안과 관리를 위한 거버넌스 정책을 수립하고 이를 강제화한다.

2) 개발 중심
  • 개발자 - 데이타 분석가로 부터 전달받은 설계 문서에 기반하여 분석 시스템을 구현한다. 이 때, 다양한 솔루션과 방법이 필요하며 이중 가장 적합한 것을 빅데이터 코디네이터와 함께 선정하고 이를 적용한다.
  • 인프라 담당 - 데이타 분석가와 개발자가 필요로 하는 분석용 데이타를 준비하여 제공하고 이를 위한 대용량 빅데이타 인프라를 운영한다.

3) 개발 및 기획 중심
  • 빅데이타 코디네이터 - 관련 인력들간의 커뮤니케이션을 조율하며 , 설계된 문서의 다양한 기술중 최적화된 기술 방안을 찾으며 원하는 결과가 도출되고 인사이트를 찾을 수 있도록 전략을 수립하고 이를 실천해 나간다.  기획과 기술을 모두 겸비해여 원활히 해당 업무를 수행할 수 있다. 


결국 人 이 가장 중요하고 , 이들 을 이끌고 명확한 결과를 도출해 나갈 리더(人), 이들이 원활하게 업무를 수행할 수 있는 조직 구성이 빅데이타를 성공하기 위해서 반드시 필요하다. 이를 간과할 경우 우리는 아마도 몇 년 후  7 key reasons for BigData failures라는 글을 다시 보게 될 지도 모른다. 


 



     


Posted by 박재현
,

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 박재현
,