보안

글로벌 칼럼 | XaaS에 대한 오해 뒤짚기

Bob Lewis | CIO 2022.08.02
‘Everything as a service’는 IT 부문이 제공하는 모든 서비스를 아우르지 않는다. IT 외부에서 제공하는 서비스도 당연히 포함하지 않는다. 이를 이해할 때 좀더 중요한 논의를 진행할 수 있다.
 
ⓒ Getty Images Bank

클라우드 서비스의 확산과 더불어 각종 ‘aaS’가 범람하고 있다. ‘Everything as a service’라는 의미를 담은 XaaS도 그 중 하나다. 이는 대개 ‘인터넷을 통해 제공되며 선불 구매나 라이선스가 아닌 유연한 소비 모델 방식에 따라 비용을 지불하는 모든 컴퓨팅 서비스’로 정의된다.

XaaS를 조금만 구글링해보면 반복해서 쏟아지는 결과를 발견할 수 있다. 이들을 살펴보면 XaaS가 실은 클라우드 기반의 컴퓨팅과 비용 분담 정책의 교차점에 불과한 것으로 보이기도 한다. 실제로 업계 전문가들 사이에서 나타나는 논쟁이기도 하다.

애석하게도 필자가 보기에는 이와 관련된 담론에서, XaaS가 한편으로는 ‘서비스 지향 아키텍처(SOA)’의 논리적인 결과라는 사실은 간과되고 있는 듯하다. 또한 IT가 제공하는 중요한 서비스가 ‘XaaS’에서 제외되는 다소 해괴한 현상도 나타났다. 즉, 비즈니스 분석가, IT 사내 컨설턴트 그리고 애플리케이션 개발자 및 보조 인력들이 수행하는 여러 ‘모든 서비스’는 XaaS 범위에 포함되지 않는 것이다. 

필자 생각에는 ‘서비스로서의 모든’이 실제로 의미하는 건 ‘서비스로서 몇 가지(A Few Things as a Service; AFTaaS)’나 ‘서비스로서 수고스러운 일은 제외한 모든 일 (Everything Except Effort as a Service)’인 듯하다.
 

XaaS의 진짜 의미 

XaaS는 기업에서 이루어지는 거의 모든 일들에 대한 SOA 원칙의 논리적인 적용이어야 한다. 예를 들어, 비즈니스 프로세스 아웃소싱(BPO)이라 부르는 서비스가 포함되어야 한다. 또한 ‘비즈니스 프로세스 인소싱’이라 부를 수도 있지만 일반적으로 ‘셰어드 서비스’로 부르는 서비스도 포함해야 한다.

말하자면 XaaS는 기술 자체뿐만 아니라 그 기술이 지원하는 비즈니스 결과도 포함해야 한다. 그러나 누가 지불하고, 어떻게 진행하는지에 대한 이야기여서는 안 된다. 이 시스템의 구성은 솔루션들에 대한 자금 조달이 아니라 솔루션을 구성하는 방법에 관한 것이다.
 

‘서비스로서의 업무’ : 시스템 구성으로서의 셰어드 서비스 

앞서 언급한 복잡한 이야기의 요점은 다음과 같다. 비즈니스 프로세스 아웃소싱(BPO)는 새로운 존재가 아니다. 이는 등장 이래 업무에 대한 사용량 기반 가격 책정 모델을 적용해왔다. 그리고 IT가 현업 사용자들에게 퍼블릭 클라우드나 사내에 제공된 애플리케이션을 통해 SaaS를 제공할 수 있는 것처럼, 여러 비즈니스 부서들은 사내에 셰어드 서비스를 조직하거나, BPO 공급업체의 사용을 통해 해당 서비스를 나머지 비즈니스에서 사용할 수 있다.

그러나 셰어드 서비스 그룹은 사내에서 적용되는 BPO와는 다르다. 둘은 어떠한 차이가 있을까? BPO 공급자와 계약하는 건 아키텍처상의 결정을 의미하지 않는다. 그러나 사내 셰어드 서비스를 구성하는 건 분명히 아키텍처상의 결정을 의미한다. 대부분의 다른 아웃소싱과 마찬가지로, BPO 공급자를 고용하는 결정은 통상적으로 관리의 실패를 인정하는 것과 관련을 가진다. 내부 관리자가 제대로 감독할 수 없는 업무 기능에 대한 책임을 계약에 전가하는 것이다.

단 공유 서비스의 집합을 조직화하는 것이 항상 올바른 선택이라고 할 수는 없다. 단점들은 다음과 같다. 

BPO와 달리 사내 셰어드 서비스 비즈니스 아키텍처는 논리적인 결론에 도달했을 때 다른 모든 사업 부문에 제공하는 서비스에 대해 각 부문에 요금을 부과하는 부조리한 결과를 초래한다. 예를 들어, IT부서는 HR부서에 월별 HRIS 사용료를 청구하며, HR부서는 채용, 복리후생 관리 및 급여서비스들을 IT부서에 청구하여 서로 주고받을 수 있다. 유비쿼터스 셰어드 서비스는 기업을 거대한 금융 우로보로스(ouroboros ; 자신의 꼬리를 물어서 원형을 만드는 뱀이나 용. 그리스어에 유래했다)로 만들 수 있다.
 

비즈니스 서비스 지향 아키텍처 : 획일적 적용이 해법일 수 없다

BPO와 XaaS는 일부 상황에서 이익이 될 수 있기는 하지만, 대부분의 경우 혜택이 제한적이다. 즉, 상품화의 필요성이 있을 때에만 유효하다. 또한, 이 요구사항은 IT의 단순화에 대한 선호도 문제가 아니다. 오히려 프로세스와 관행을 전반적으로 표준화하려는 비즈니스 아키텍처 의사결정자들의 취향에 기인하는 경우가 많다.

단순화를 위한 선택일 수 있지만 오히려 번거로울 수 있다. 또 특정하거나 고유한 요구사항에 상관없이 모든 사용자에게 동일한 방식으로 운영하는 서비스를 제공하는 것은 즉각적인 비용 절감이 가능하지만, 장기적으로는 치명적인 문제가 될 수 있다.

예를 들어, 인사 관리 부서가 비즈니스 서비스 지향 아키텍처 접근방식을 적용하여 내부 고객들에게 서비스로서의 인사관리(Human Resources as a Service; Haas)를 제공한다고 상상해보자. HRaaS의 일환으로 서비스로서의 채용(Recruiting as a Service)을 제공할 수도 있을 것이다. 

블랙 프라이데이부터 박싱 데이까지 매장 직원을 늘려야 하는 계절성이 매우 높은 소매업체의 매장 운영을 책임지고 있다고 상상해보자. 또한, DBA를 채용해야 하는 IT 부서라고 상상해보자. 수백명이나 되는 매장 직원의 채용과 단 한명의 고도로 전문화된 기술 전문가 채용에는 동일한 프로세스가 적용되지 않을 것이 분명하다.

‘표준화’는 말하기에는 쉽지만 제대로 구현하기는 어렵다. 즉, 비즈니스 서비스 지향 아키텍처라고 부를 수 있는 것은, 애플리케이션 아키텍처에 마이크로서비스와 함께, 미세한 서비스들을 포함하는 SOA를 도입하는 것과 다르지 않다. 두 경우 모두 단일 유형에 대해 표준화를 시도하려는 행보는, 누구에게도 들어맞지 않는(one-size-fits-no-one) 방법일 수 있다. 

* Bob Lewis는 IT 비즈니스 전략 및 통합 분야를 전문으로 하는 IT 컨설턴트다. ciokr@idg.co.kr

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.