본문 바로가기

Collaboration/HCS

[연재] HCS의 이해 - 1. HCS는 라이센스 정책이다

글 싣는 순서

1. HCS는 라이센스 정책이다

2. HCS는 비지니스 모델이다

3. HCS의 데이타센터 아키택쳐이다 



시작하며
HCS는 전세계적으로 성공한 클라우드 서비스이자만, 한국에서는 시작도 못하고 있습니다. 한국에서 시스코 협업 솔루션 사용자가 계속 증가하고 있는 만큼 HCS가 안착될 수 있도록 HCS에 대해 정확히 알아볼 필요가 있습니다.  


이번 연재는 HCS를 정확하게 이해하기 위해 다양한 각도에서 HCS를 조망해 보겠습니다. 



HCS의 개요
HCS는 Hosted Collaboration Solution의 약어로 클라우드 기반으로 시스코 Collaboration 솔루션을 서비스 하거나 또는 서비스 받을 수 있는 솔루션입니다. 시스코 콜라보레이션 솔루션은 크게 통합 커뮤니케이션, 고객센터, 영상회의, 애플리케이션으로 나뉘며, 대부분의 시스코 협업 솔루션을 HCS 서비스가 가능합니다. 






일반적인 소프트웨어 라이센스 체계
HCS를 이해하기 위해 라이센스 체계라는 관점에서 먼저 접근해 보겠습니다. 소프트웨어 라이센싱 기법의 창시자는 마이크로소프트의 창업자인 빌게이츠입니다. 현존의 대부분의 상용 소프트웨어의 라이센싱 정책은 마이크로소프트에서 시작했을 것입니다. 소프트웨어의 라이센싱 정책을 쉽게 이해하기 위해 마이크로소프트의 라이센스 체계를 큰 틀에서 살펴보겠습니다. 


서버쟁이들에게는 당연한 이야기이지만 네트워크나 UC 엔지니어들에게는 생소한 이야기입니다. 마이크로소프트의 소프트웨어 라이센스는 크게 두 가지로 나눌 수 있습니다.

  • EULA (율라, End User License Agreement) : 최종 사용자 라이센스 계약
    소프트웨어를 구매하는 사용자가 소프트웨어에 대한 사용 권한을 가지며, 제조사가 제시하는 계약 조건을 준수하도록 합니다. 

  • SPLA (스플라, Service Provider License Agreement) : 서비스 공급자 라이센스 계약
    마이크로소프트의 소프트웨어를 이용하여 추가적인 수익을 얻기 위한 임대업이나 영리 사업을 하는 사업자에게 사용 권한이 주어지며, 직접적인 최종 사용자에게 라이센스를 부과하지 않는 방식입니다. 일반적으로 데이터센터의 서버에 설치되면서 일반 사용자들을 대상으로 하는 웹서버 등이 해당합니다. 

소프트웨어 라이센스에서 EULA에 대해 좀 더 알아 보겠습니다. 전화기와 같은 순수 하드웨어만을 판매하는 제조사는 장비 자체에 사용 권한이 귀속됩니다. 갑순이가 사용하여도 을순이에게 양도할 경우 별로 문제가 발생하지 않으며 서비스에도 문제가 없습니다. 소프트웨어는 최종 사용자에게 사용 권한이 귀속되므로 갑순이가 가진 소프트웨에 라이센스를 을순이에게 양도할 경우 법적 문제가 발생합니다. 갑순이와 을순이는 각각의 라이센스를 구매해야 합니다. 만일 소프트웨어에 대한 EULA가 없다면, 갑순이가 하나를 구매하여 전세계 모든 사용자에게 양도해도 법적 문제가 발생하지 않습니다. 따라서, 소프트웨어에서는 EULA 가 중요합니다. B2B 비지니스에서 EULA는 A기업에서 구매한 소프트웨어를 B 기업에서 사용할 수 없도록 하는 법적 장치입니다. 


시스코 Collaboration 소프트웨어 EULA 라이센스 체계
시스코의 Collaboration 라이센스 체계는 UCL / CUWL 이라는 사용자 기반 라이센스 체계이며, EULA에 의해 최종 사용자인 기업에 귀속됩니다. 이는 소프트웨어 설치간의 간단한 체크로 계약이 이루어지거나 A4지 종이 한장으로 계약이 성립됩니다. 이것의 의미를 이해하기 위해 예를 들어 보겠습니다. 

만일 하나의 서비스프로바이더나 게이트컴퍼니와 같은 회사가 1000개의 라이센스가 필요한 A 기업, 2000개의 라이센스가 필요한 B 기업과 3000개의 라이센스가 필요한 C 기업에게 시스코 UC솔루션을 하나의 클러스터로 만들어서 서비스할 계획입니다. 시스코 파트너사인 서비스 프로바이더는 각각의 기업을 위한 라이센스를 A기업용 1000개, B 기업용 2000개, C 기업용 3000개를 각각 주문하여 하나의 클러스터에 입력하여 서비스를 합니다. 시스코 협업 솔루션의 최종 사용자인 각 기업으로 이름으로 라이센스가 구매되었으르므로 시스코 EULA 계약에 위배되지 않습니다.

몇 년이 지나서 A 기업이 망하거나 서비스를 종료하였을 경우 라이센스에 문제가 발생합니다. 서비스 프로바이더는 계약을 종료하고 남은 1000개의 라이센스를 새로 유치한 D 기업에게 사용하고자 하지만, 라이센스 위배에 걸립니다. 시스코의 EULA 계약 주체는 서비스 프로바이더가 아니라 A 기업, B 기업, C 기업, D 기업이기 때문입니다. 이에 대한 근거는 아래 사이트를 참조하시기 바랍니다. 



만일 A기업이 라이센스를 리호스팅하려고 한다면 시스코는 재발급을 해야 할수도 있습니다.  서비스 프로바이더는 기존의 라이센스를 재사용할 수도 다른 기업에 양도할 수도 없습니다. 결국 서비스프로바이더가 SPLA처럼 직접 소프트웨어 라이센스를 구매하여 불특정 다수에게 서비스를 할 수 있도록 하는 별도의 라이센스 체계가 필요해집니다.     


HCS는 라이센스 모델이다
시스코 HCS 솔루션은 시스코 Collaboration 솔루션을 클라우드로 서비스하려는 서비스 프로바이더나 게이트 컴퍼니를 위한 라이센스 체계입니다. 서비스 프로바이더 이름으로 소프트웨어 라이센스를 구매하고 불특정 다수에게 서비스를 제공할 수 있도록 합니다. 
이것이 라이센스 관점에서 HCS가 반드시 필요한 이유입니다. 

한국에서 HCS가 아직 도입되지 않은 이유는 시스코 협업 솔루션을 판매하거나 도입하면서 HCS와 같은 라이센스 체계가 반드시 필요한 상황이 아직 오지 않앗기 때문일수도 있습니다. 위의 예처럼 라이센스 위배로 인해 재사용할 수 없는 라이센스가 쌓이게 되면 당연히 HCS로 전환하려는 요구가 크게 증가할 것입니다. 


마치며
HCS를 좀 더 명확하게 이해하기 위해 각각의 특징을 분리해서 접근해보려고 하는 시도가 자칫 장님 코끼리만지는 꼴이 될지도 모르겠습니다. ㅋㅋ 



라인하
트 유씨누스(UCnus) (CCIEV #18487)
  --------------------------------------
ucwana@gmail.com (라인하트의 구글 이메일) 
http://twitter.com/nexpertnet (넥스퍼트 블로그의 트위터, 최신 업데이트 정보 및 공지 사항) 
http://groups.google.com/group/cciev (시스코 UC를 공부하는 사람들이 모인 구글 구룹스) 
http://groups.google.com/group/ucforum (UC를 공부하는 사람들이 모인 구글 구룹스) 
세상을 이롭게 하는 기술을 지향합니다. ________________________________________________________