베스핀글로벌 / 윤영기
1부에서는 SaaS 개발을 위한 비즈니스적 고려사항으로, 고객을 정의하고 과금모델과 요금책정을 하는 것에 대해서 다뤘다. .
2부에서는 기술적 측면의 고려사항을 다루고자 한다.
2. 기술적 측면의 고려사항
2-1. 그룹 및 역할 기능
직원 수가 많고 부서가 세분화되어 있는 기업고객의 경우, 각 부서별로 작업 내역을 독립적으로 소유하길 원하고, 관리부서에서는 각 부서들의 사용 현황이나 비용을 통제하고자 할 것이다.
이를 위해 그룹, 프로젝트, 역할, 그리고 권한 등의 기능을 제공해야 한다.
그룹은 같은 목적을 가진 사용자들의 모임을 의미하며 부서나 팀이 이에 해당된다. 프로젝트는 그룹 내에서 발생하는 다양한 업무단위를 의미한다. 그리고 역할은 그룹이나 프로젝트 단위로 사용자에게 주어지는 권한을 의미한다.
[그림5. 그룹, 프로젝트, 역할 관계 예]
그룹 및 역할 기능을 구현하기 위해서는 다양한 요소를 고려해야 한다. 효율적인 기능 구현을 위해서는 서비스의 특성과 대상 고객의 요구 사항을 고려하는 것이 필요하며, 이를 위해서는 기획자나 제품 관리자(Product Manager)와 긴밀히 협력하는 것이 중요하다.
[그림6. Jira software 프로젝트와 역할 관계 (출처 : atlassian.com)]
2-2. 멀티 테넌시
멀티테넌시란 여러 고객이 애플리케이션이나 컴퓨팅 리소스를 공유하는 아키텍처를 의미한다.
멀티테넌시의 첫 번째 장점은 비용 절감이다.
개별적으로 리소스를 할당하는 것보다 경제적이며, 사용자 수요에 맞게 리소스를 할당하는 것이 용이하기 때문이다.
두 번째 장점은 운영의 효율성이다.
고객별로 인프라와 소프트웨어를 개별적으로 관리하고 업데이트하는 작업은 번거롭고 반복적인 작업일 것이다. 멀티 테넌시는 소프트웨어와 하드웨어를 통합 관리함으로써 운영 효율성을 높여준다.
멀티테넌시의 구현 방법은 다양하며, 애플리케이션과 데이터베이스를 모두 공유하는 방식, 애플리케이션은 공유하지만 데이터베이스를 분리하는 방식, 애플리케이션을 분리하고 데이터베이스를 공유하는 방식 등을 예로 들 수 있다.
[그림7. JMulti Tenancy Architecture Models (출처:networkinginterview.com)]
또한, 최근에는 SaaS 적용 기술의 다양화로 인해 리소스를 전혀 공유하지 않는 아키텍처도 SaaS 모델로 볼 수 있다는 견해도 있다.
아래 그림은 하드웨어와 애플리케이션은 공유하지 않고 DevOps, 미터링, 모니터링, 빌링 등 관리 요소만 공유하는 모델을 나타내고 있다.
[그림8. 리소스를 전혀 공유하지 않는 SaaS모델 예 (출처 : AWS)]
이러한 테넌트는 사일로화된 인프라에서 운영되지만 여전히 공동으로 관리 및 운영되고 있습니다. 이들은 하나의 통합된 온보딩, ID, 지표, 청구 및 운영 경험을 공유합니다.
또한 새 버전이 출시되면 모든 테넌트에 배포됩니다.
이 기능이 제대로 작동하려면 개별 테넌트에 대한 일회성 사용자 지정을 허용할 수 없습니다.
이 극단적인 예는 멀티테넌트 SaaS의 개념을 테스트하기 위한 좋은 모델을 제공합니다. 공유 인프라의 효율성을 모두 실현하지는 못하더라도 완전히 유효한 멀티테넌트 SaaS 환경입니다.
일부 고객의 경우 도메인에 따라 일부 또는 전체 고객이 이 모델에서 실행되도록 지정할 수 있습니다. 그렇다고 SaaS가 아니라는 의미는 아닙니다.
이러한 공유 서비스를 사용하고 모든 테넌트가 동일한 버전을 실행하는 경우에도 이는 여전히 SaaS의 기본 원칙을 준수합니다. (출처 : AWS)
2-3. 인증/보안/미터링
SaaS는 서로 다른 조직의 여러 사용자가 함께 사용하는 서비스 형태이기 때문에 인증과 보안이 무엇보다 중요하다.
인증 및 인가 :
사용자를 인증하는 방법은 쿠키인증, 세션인증, 토큰인증 등이 있으며, 최근 MSA(Microsevice Architecture)에서 JWT(Json Web Token)을 이용한 토큰인증 방법이 많이 사용되는 추세이다.
[표3]
보안 :
클라우드 도입의 확대로 인해 보안에 대한 중요성이 더욱 높아지고 있다.
이에 따라 최근에는 제로트러스트(Zero Trust)라는 개념이 주목을 받고 있다.
제로트러스트는 아무것도 신뢰할 수 없다는 가정하에 네트워크, 애플리케이션, 데이터, 기기 등 모든 영역에 보안을 적용하는 방법론이다.
과거에는 방화벽과 같이 외부에서의 접근을 막는 것에 주력했지만, 제로트러스트는 시스템 내부에서도 보안을 세밀하게 통제하고 관리해야 한다는 개념을 강조한다.
이를 위해 신뢰할 수 있는 사용자와 기기를 인증하고 검증함으로써, 모든 데이터와 액세스에 대해 신뢰도를 최소한으로 가정하고 보안을 강화한다.
이는 사용자 인증, 암호화, 액세스 제어 등 다양한 보안 기술을 활용하여 구현될 수 있다.
제로트러스트는 클라우드 환경에서의 보안의 중요성을 강조하는 것뿐 아니라, 기업 내부에서도 보안을 강화하기 위한 새로운 방향을 제시한다.
이를 통해 데이터 유출과 같은 보안 위협으로부터 기업을 보호할 수 있게 된다.
[그림9. 제로트러스트 (출처:logrhythm)]
미터링 및 청구 :
고객을 정의하고 과금모델을 정한 후에는 해당 모델에 적합한 미터링 체계가 필요하다.
특히, 사용량 기반의 과금모델을 도입했다면 사용량을 추적하는 기능이 필수적이다. 또한, 사전에 계약된 패키지를 초과하지 않도록 사용량을 적절하게 통제할 수 있는 기능도 필요하다.
이와 함께, 비용 청구 및 결제 기능의 추가도 고려할 만하다. 이를 통해 고객은 편리하게 비용을 청구하고 결제할 수 있게 될 것이다.
이러한 미터링 및 청구 기능은 고객에게 투명한 요금체계를 제공하고, 사용량을 통제함으로써 예산을 관리할 수 있도록 도와준다.
이처럼 미터링 및 청구 기능은 고객과의 관계를 원활하게 유지하는 데 중요한 요소이다.
2-4. 인증/보안/미터링
클라우드 네이티브 애플리케이션은 개발과 배포를 효율적으로 하고, 비즈니스 요구에 빠르게 대응하기 위해 개발되어진 소프트웨어를 말한다. 다양한 고객의 요구사항을 빠르게 반영해야 하는 SaaS의 특성상 클라우드 네이티브 애플리케이션은 필수로 적용되어야 하는 개발 방식이다.
클라우드 네이티브 애플리케이션은 다음과 같은 특징을 갖는다.
- 유연한 확장성 : 애플리케이션은 클라우드 인프라가 수평확장(scale-out)되었을 때 자동으로 확장될 수 있어야 한다. 트래픽 증가나 부하에 유연하게 대응할 수 있는 능력을 가지고 있어야 한다.
- 장애나 지연에 대한 내성 : 특정 기능의 오류나 시스템 장애가 발생했을 때 애플리케이션 전체 장애로 확산되지 않고, 빠르게 복구되어 가용성을 유지해야 한다.
- 분산 구조와 느슨한 결합 : 애플리케이션은 작은 단위로 나뉘어져 독립적으로 분리되어야 하며, 이들 단위는 서로 API 기반의 통신을 통해 느슨하게 결합되어야 한다. 이를 통해 애플리케이션은 확장성과 유연성을 갖추게 된다
클라우드 네이티브 애플리케이션 개발방법으로는 12 Factor APP과 Microservice를 들 수 있다.
12 Factor App :
12 Factor App은 SaaS 개발을 위한 가이드라인으로, 어떤 프로그래밍 언어로 작성된 애플리케이션에도 적용할 수 있으며, 백엔드 서비스를 포함한 다양한 조합으로 사용할 수 있어 이식성과 확장성을 높이는 것을 목적으로 한다.
12 Factor App은 애플리케이션의 개발, 배포 및 운영에 일관성을 부여하여 애플리케이션을 클라우드 환경에서 쉽게 관리할 수 있도록 도와준다. 이를 위해 12 가지의 원칙이 제시되며, 각 원칙은 애플리케이션의 구성, 환경 변수, 로그 처리, 스케일링 등 다양한 측면을 다룬다.
Microservice :
Microservice 역시 클라우드 네이티브 애플리케이션 개발을 위한 중요한 개념이다. Microservice 접근 방식은 애플리케이션을 여러 개의 작은 서비스로 분할하여, 각 서비스를 독립적인 컨테이너에 배포하고 API를 기반으로 통신하도록 하여 상호 느슨한 연결구조를 유지함으로써 애플리케이션의 유연성, 확장성 및 회복력을 향상시키며, 빠른 개발과 배포가 가능하게 한다.
필자는 앞에서 SaaS를 위한 클라우드 네이티브 애플리케이션 개발 방법의 중요성을 강조했다. 그러나 12 Factor APP의 12가지 방법론을 모두 준수하거나 마이크로서비스 개발이 반드시 필요한 것은 아니라는 점을 이해하는 것이 중요하다. 가장 중요한 것은 조직의 기술적 성숙도를 고려하면서 기능적, 비기능적 목표 측면에서 달성하려는 특정 목표에 부합하는 방식으로 서비스를 개발하는 것이다.
더욱이 12 Factor APP과 마이크로서비스 개발 방법은 상충되는 접근 방식보다는 보완적인 접근 방식으로 보는 것이 더 적절하다. 그 이유는 느슨한 결합, 배포 자동화 및 수평 확장성에 대해 공통적으로 강조하고 있기 때문이다.
3. 맺음말
1부와 2부를 통해 SaaS 개발 및 전환을 위한 비즈니스적 측면과 기술적 측면의 고려사항들을 살펴보았다.
이 외에도 제품 기획, 마케팅, 고객지원체계, 지속적인 개선을 위한 DevOps, 모니터링, 성능관리 등 다양한 고려사항이 있겠으나 지면 관계상 여기서는 다루지 않았다.
SaaS전환은 한 번의 노력으로 종결되는 것이 아니라, 지속적인 관리와 개선을 위한 노력이 필요하다. 끊임없이 발전하고 변화하는 시장에 뒤쳐지지 않기 위해서는 조직에 맞는 SaaS비즈니스를 위한 고민과 열정이 필요할 것이다.
참 고 문 헌
- https://12factor.net/ko/
- https://microservices.io/
- https://docs.aws.amazon.com/ko_kr/whitepapers/latest/saas-architecture-fundamentals/re-defining-multi-tenancy.html
- https://www.getcheddar.com/blog/cost-plus-pricing-for-saas/
저작권 정책
K-ICT 클라우드혁신센터의 저작물인 『SaaS 개발 및 전환 고려사항』은 K-ICT 클라우드혁신센터에서 베스핀글로벌 윤영기님에게 집필 자문을 받아 발행한 전문정보 브리프로, K-ICT 클라우드혁신센터의 저작권정책에 따라 이용할 수 있습니다.
다만 사진, 이미지, 인용자료 등 제3자에게 저작권이 있는 경우 원저작권자가 정한 바에 따릅니다.