‘서비스형 기업이 살아남는다’ SaaS화를 위한 아키텍처를 구축하는 법

모든 것을 SaaS화하지 않으면 살아남기 힘든 시대가 점점 다가오고 있다. 이런 시대를 맞을 준비가 되었는가? 
 

기업들의 ‘SaaS 대전환’을 견인하는 두 가지 요인이 있다. 비즈니스 관점에서 소프트웨어 제공업체는 먼저 연구개발에 투자 비용을 퍼붓고 개발이 다 끝난 후 구매를 기다리는 대신 반복 매출을 얻고자 한다. 

기술 관점에서 기업 고객은 분산 데이터베이스와 같이 복잡한 소프트웨어 제품을 실행하는 데 필요한 인프라를 유지관리할 전문 지식이나 자원이 없는 경우가 많다. 제공업체에 반복 매출을 내는 대가로 소프트웨어를 유지하고 관리해야 할 부담을 떠넘기는 셈이다. 

분산형 데이터베이스 소프트웨어 제공업체라면 의심할 여지도 없이 SaaS가 적합하다. 하지만 제공하는 서비스가 소프트웨어가 아니라면 어떨까? 제조, 물류, 보험 등 다른 서비스라고 해도 SaaS로 전환하는 게 이득일까? 

그렇다. SaaS 전환은 소프트웨어 제공업체가 아닌 기업에게도 여전히 유용하다. 정확히 말하면 SaaS화를 하는 것이 거의 모든 현대 기업에게 유용하다. 

소프트웨어와 비즈니스 서비스 사이의 경계는 모호해진 지 오래다. 시장에서 우버, 그럽허브(Grubhub), 아마존과 같은 회사들은 기술 회사로 여겨진다. 한편 옐로우 캡(Yellow Cab), 도미노 및 월마트 같은 회사는 기술 회사로 여겨지지 않는다. 앞선 회사들과 비슷한 유형의 서비스를 제공하며 웹사이트와 앱을 운영하는데도 말이다. 비즈니스 서비스를 제공하는 회사 대부분이 소프트웨어를 통해 서비스를 제공하더라도 기술 회사로 여겨지지 않는다. 

기존 회사는 보통 서비스의 소비자 혹은 제공자, 둘 중 하나로 구분된다. 하지만 오늘날 회사는 둘 다가 될 수도 있다. 이 새로운 패러다임에 대해 많은 분석과 연구가 나왔으나 아직 자리를 잡아가는 중이다. 기업이 IT 서비스 (AWS Marketplace) 외에 다른 서비스를 자유자재로 보고 고를 수 있는 시장이 아직 없는 상태다. 따라서 앞서갈 기회가 얼마든지 열려있다.

기업이 전문성을 서비스 형태로 다른 기업에 판매하고 싶은 마음이 없더라도 SaaS화는 여전히 유용하다. 우버와 그럽허브 같은 빨리 성장하는 회사가 되고 싶다면 재빠르게 새로운 아이디어를 시도하고, 새로운 서비스를 시작하고, 실패하는 법을 배워야 한다. SaaS화는 비즈니스 프로세스 자동화와 데브옵스 모델을 기반으로 비즈니스 기능을 확장 가능한 클라우드 네이티브 형식으로 패키징하기 때문에 빨리 시도하고 실패하는 문화에 딱 들어맞는다. 
 

안팎으로 SaaS화 

기업은 고객을 위한 서비스가 아닐지라도 사내 시스템을 서비스형으로 만드는 것을 고려할 수 있다. 이렇게 리팩토링을 해놓으면 내부 서비스를 나중에라도 외부에 판매하거나 타사 서비스로 대체할 수 있다. 

서비스형 방식의 장점을 극대화하려면 기업은 기존 프로세스 관리에서 비즈니스 프로세스 자동화로 전환해야 한다. 시스템 차원의 특정 기준을 기반으로 모든 사용자가 일관되고, 반복 가능하며, 문서화된 형식으로 일하는 것이다. 

기존 프로세스 관리가 비즈니스 프로세스 자동화와 다른 점은 일반 택시 회사가 우버와 다른 점과 유사하다. 택시 회사에서 운전자에게 누구를 어디서 언제 태워야 하는지 알려주는 건 배차원이다. 반면 우버에서는 소프트웨어가 배차원 역할을 맡는다. 

진정으로 SaaS화된 비즈니스는 기술적 성과라기보다는 자동화의 마법에 가깝다. 인간 배차원이나 관리자가 일상 작업에 관여하지 않아도 되며, 알고리즘 기반의 비즈니스 프로세스가 알아서 일을 처리하는 시스템이 이상적이다. 물론 자동화했다고 해서 인간의 개입이 전혀 필요하지 않은 것은 아니다. 

즉 SaaS화란 정책과 관행을 비즈니스 프로세스로 변환해 폐쇄 루프 시스템(closed-loop system)을 만드는 일이다. 여기에 인간이 관여하는 데이터 기반 의사결정 시스템과 상황 인지 시스템이 내장되어야 한다. 

SaaS 전환에 성공하는 기업은 결국 훨씬 더 가치 있는 기업이 된다. 이론적으로 기업 가치는 인수나 주식 합병에서 매겨지는 가격이라고 볼 수 있는 데, 대부분 인수합병은 실패로 끝난다. 하버드 비즈니스 리뷰에 따르면 인수합병의 70~90%가 예정대로 진행되지 못한다. 기업 시스템과 경영 방식의 투명성이 높을수록, 그리고 통합 경로가 명확할수록 인수 가치는 올라간다. 따라서 느슨하게 결합된 마이크로서비스와 비즈니스 프로세스 알고리즘을 중심으로 운영되는 회사는 본질적으로 합병하기 더 쉬우며 더 높은 가치평가를 받는다. 

이 외에도 SaaS화된 기업은 시장 상황에 더 쉽게 적응할 수 있다. 내부 서비스가 기대만큼, 혹은 경쟁업체만큼 잘 운영되지 않는다고 가정해보자. 이런 경우 해당 서비스를 최적화하거나, 없애거나, 제3자가 제공하는 더 나은 서비스로 대체하기도 쉽다. 반대로 예컨대 물류용 내부 서비스 서비스가 기대치를 초과할 만큼 성공적이라면 API 형태로 타사에게 서비스를 제공할 수도 있다. 
 

SaaS화가 IT에게 미치는 영향

SaaS화는 IT 조직에게 새로운 과제를 부여한다. 서비스를 운영하려면 기존의 IT 관리 및 게이트키핑과 다른 형태의 사고방식이 필요하다. 서비스는 변동성이 큰 수요에 대비해야 하며 예기치 못한 변수가 생겨도 안정성을 유지해야 한다. 

이러한 전환을 위해서는 일단 서비스가 명확히 분별 돼야 한다. 각 서비스는 처리량과 신뢰성을 기준으로 분명한 서비스 품질 수준에 따라 실행되어야 하며, 수요와 요구에 따라 확장 가능해야 한다. 여기에는 클라우드뿐만 아니라 인증 서비스에서 데이터베이스에 이르기까지 모든 새로운 기술이 필요하다. 

보통 IT 부서는 액티브 디렉터리(Active Directory, AD) 서버와 일련의 스토브파이프(stovepipe) 애플리케이션에 데이터를 제공하는 수많은 오라클, 마이SQL(MySQL), 마리아DB(MariaDB) 및 SQL 인스탄스를 사용한다. 이런 애플리케이션은 클라이언트 서버 소프트웨어에 의존해 확장과 리던던시에 한계가 있다.

어떤 SQL 데이터베이스를 쓰느냐에 따라호환되는 다른 분산 SQL 데이터베이스로 이전하거나, 마이크로소프트가 권장하는 것처럼 애저 AD(Azure AD)로 이전할 수도 있겠지만 이는 말처럼 쉬운 일이 아니다. 

동시에 이러한 이전 작업은 중복 서비스를 제거하고 결합할 기회이기도 하다. 여러 개의 AD 인스턴스를 운영하는 것보다 관련 데이터와 시스템을 통합하는 것이 더 나을 수 있다. 예컨대 인벤토리는 오라클 데이터베이스에, 가격 책정 및 카탈로그 서비스는 마리아DB에 있다고 해보자. 서쪽과 동쪽에 AD 인스턴스가 따로 있을 수 있다. 서비스형으로 이전하면 이렇게 인스턴스를 구분할 필요가 없다. 관리, 유지 및 보호해야 할 시스템과 데이터의 수를 최대한 줄이는 것이 좋다. 

로드 테스팅을 할 때는 현재와 미래 요건을 충족하는 서비스는 더 이상 충분하지 않다. 서비스 규모에 따라 달라지는 패턴에 대응할 수 있어야 한다. 최대한 선형적으로 확장 가능해야 하며, 수요가 줄어들 때는 그에 따라 축소돼야 한다. 축소될 때는 용량과 비용 모두가 줄어들어야 한다. 이렇게 유연하게 반응할 수 있어야 서비스가 비즈니스가 함께 발전할 수 있으며, 고객과 비즈니스에 적재적소의 새로운 서비스를 제공할 수 있다. 

마지막으로 서비스는 전 세계적으로 지역을 넘나들 수 있어야 한다. 서비스와 데이터가 여러 지역에 걸쳐 있어야 한다는 뜻이다. 지역 간 복제만으로도 영역을 확장할 수 있다. 하지만 글로벌 기업이 지역을 넘나들려면 결국 클라우드 독립을 이뤄야 한다. 세계 모든 지역에 걸쳐 최적화된 클라우드 제공업체는 없기 때문이다. 
 

기술은 이미 다 마련돼있다 

이 모든 것을 구현하기 위한 기술은 이미 마련돼있다. 컨테이너, 쿠버네티스, 클라우드 컴퓨팅 및 분산 데이터베이스를 사용하면 안 될 게 없다. 다만 사고방식과 문화를 바꾸는 일이 더 어렵고 중요하다. 

클라우드 기반 서비스 아키텍처는 IT가 개발하는 관리하는 모든 시스템의 기본이 되어야 한다. 확장, 축소, 글로벌 가용성 등 SaaS화에 필요한 기준을 충족해야 하며, 유지보수가 더 쉬워지도록 핵심 서비스(보안 및 데이터베이스)를 결합하고 통합해야 한다. 

더 중요한 것은 기업이 기술 계층보다는 서비스와 프로세스 관점에서 생각해야 한다는 점이다. 서비스화는 단순히 IT 부서의 일이 아니라 비즈니스를 구성하는 방식이다. IT 및 비즈니스 전문가들은 모든 것을 클라우드 네이티브 SaaS로 모듈화해야 한다. 산업별 서비스부터 수평적 참여 시스템, 기록 시스템, 데이터베이스 및 보안까지 모두 다 말이다. 

이렇듯 SaaS화는 지난 몇 년간의 기술 혁신을 도입하는 일이기도 하지만 결국 핵심은 새로운 사고방식을 받아들이는 일이다. ciokr@idg.co.kr