SaaS 마이그레이션
SaaS를 채택한 많은 제공업체는 이전에 설명한 기존 설치 소프트웨어 모델에서 SaaS로 마이그레이션합니다. 이러한 제공업체의 경우 SaaS의 핵심 원칙을 잘 준수하는 것이 특히 중요합니다.
여기서도 SaaS 모델로 마이그레이션한다는 것이 무엇을 의미하는지에 대해 혼란이 있을 수 있습니다. 예를 들어 클라우드로의 이동을 SaaS로 마이그레이션하는 것으로 보는 사람도 있습니다. 설치 및 프로비저닝 프로세스에 자동화를 추가하는 것을 마이그레이션을 달성하는 것으로 보는 사람도 있습니다.
조직마다 출발점이 다르고, 기존 고려 사항이 다르며, 시장 및 경쟁 압력에 직면할 가능성이 높다고 해도 과언이 아닙니다. 즉, 모든 마이그레이션은 다르게 보일 것입니다.
모든 경로는 다르지만 마이그레이션 전략을 형성하는 핵심 원칙과 관련해서는 단절된 부분이 있는 부분도 있습니다. 개념과 원칙을 잘 조정하면 SaaS 마이그레이션의 전반적인 성공에 상당한 영향을 미칠 수 있습니다.
앞서 설명한 개념을 바탕으로 SaaS로의 전환은 비즈니스 전략과 목표에서 시작된다는 점을 분명히 해야 합니다. 가능한 한 빨리 SaaS로 전환해야 한다는 압박이 있는 마이그레이션 환경에서는 이 점을 놓칠 수 있습니다.
이 모드에서, 조직에서는 마이그레이션을 주로 기술적 절차로 간주하는 경우가 많습니다. 실제로 모든 SaaS 마이그레이션은 대상 고객, 서비스 경험, 운영 목표 등을 명확하게 파악하는 것에서 시작해야 합니다. SaaS 비즈니스에 필요한 모습에 더 명확하게 초점을 맞추면 솔루션을 SaaS로 마이그레이션하기 위해 취하는 형태, 우선 순위 및 경로에 큰 영향을 미칩니다.
마이그레이션 초기부터 이러한 명확한 비전을 갖추면 SaaS로의 전환의 일환으로 기술과 비즈니스를 모두 마이그레이션하는 방법의 토대를 마련할 수 있습니다. 이 길을 걷기 시작하면서 향하고 있는 방향에 대해 가장 잘 알려줄 수 있는 질문에 집중하세요.
다음 표는 기술 및 비즈니스 마이그레이션 사고방식의 대조적인 특성을 보여줍니다.
표 1 — 기술 우선 마이그레이션과 비즈니스 우선 마이그레이션 비교
기술 우선 사고방식 | 비즈니스 우선 사고방식 |
---|---|
테넌트 데이터를 분리하려면 어떻게 해야 할까요? | SaaS는 비즈니스 성장에 어떻게 도움이 될까요? |
사용자를 테넌트와 연결하려면 어떻게 해야 할까요? | 어떤 세그먼트를 타겟팅하고 있나요? |
시끄러운 이웃 상황을 피하려면 어떻게 해야 할까요? | 이 세그먼트의 크기와 프로필은 어떤가요? |
A/B 테스트는 어떻게 하나요? | 어떤 등급을 지원해야 할까요? |
테넌트 부하를 기반으로 규모를 조정하려면 어떻게 해야 할까요? | 어떤 서비스 경험을 목표로 하고 있나요? |
어떤 청구 제공업체를 이용해야 하나요? | 가격 책정 및 패키지 전략은 무엇인가요? |
왼쪽은 기술 우선 마이그레이션 사고방식입니다. 엔지니어링 팀은 모든 SaaS 아키텍처에서 확실히 중요한 클래식 멀티테넌트 주제를 추구하는 데 집중하고 있습니다.
문제는 왼쪽에 있는 많은 질문에 대한 답변이 오른쪽 질문에 대한 답변의 직접적인 영향을 받는 경우가 많다는 것입니다. 마이그레이션을 고려하는 사람에게는 이 점이 생소할 것 같지 않습니다. 그러나 실제로 많은 조직은 비즈니스 부분이 저절로 해결될 것이라고 가정하고 운영 및 비용 효율성을 첫 단계로 추구하는 것으로 시작합니다.
이 마이그레이션 전략 내에서는 레거시 환경을 SaaS 모델에 맞게 어떻게 발전시킬지에 대한 혼란도 있을 수 있습니다. 이 분야에서도 SaaS로 마이그레이션할 수 있는 다양한 옵션이 있습니다. 하지만 모든 마이그레이션에 대해 일반적으로 권장하는 공통 가치 체계가 있습니다.
SaaS 원칙에 대한 이전 논의에서 SaaS 환경을 설명하는 데 사용되는 다양한 패턴과 용어에 대해 설명했습니다. 이러한 모든 솔루션을 포괄하는 공통된 주제 중 하나는 애플리케이션을 둘러싸고 서비스를 공유하자는 아이디어입니다. 자격 증명, 온보딩, 지표, 청구 등은 모두 SaaS 환경의 핵심인 공통 요소로 불립니다.
이제 마이그레이션을 살펴보면 동일한 공유 서비스가 모든 마이그레이션 사례에서 핵심적인 역할을 한다는 것을 알 수 있습니다. 다음 다이어그램은 마이그레이션 환경에 대한 개념적 관점을 제공합니다.

SaaS로 마이그레이션
이 다이어그램은 모든 마이그레이션 경로의 대상 경험을 나타냅니다. 여기에는 앞서 설명한 것과 동일한 공유 서비스가 모두 포함됩니다. 가운데에는 애플리케이션의 자리 표시자가 있습니다.
핵심 아이디어는 이러한 환경 한가운데에 원하는 수의 애플리케이션 모델을 도입할 수 있다는 것입니다. 마이그레이션의 첫 번째 단계에서는 각 테넌트가 자체 사일로에서 실행되도록 할 수 있습니다. 또는 요소가 사일로화되고 일부 기능은 현대화된 마이크로서비스 모음을 통해 처리되는 하이브리드 아키텍처를 사용할 수도 있습니다.
처음에 애플리케이션을 현대화하는 정도는 레거시 환경의 특성, 시장 요구 사항, 비용 고려 사항 등에 따라 달라집니다. 변하지 않는 것은 이러한 공유 서비스의 도입입니다.
모든 SaaS 마이그레이션은 기업이 SaaS 모델에서 운영할 수 있도록 이러한 기본 공유 서비스를 지원해야 합니다. 예를 들어, 애플리케이션 아키텍처의 모든 변형에는 SaaS 자격 증명이 필요합니다. SaaS 솔루션을 관리하고 모니터링하려면 테넌트 인식 운영이 필요합니다.
마이그레이션 초기에 이러한 공유 서비스를 도입하면 기본 애플리케이션이 여전히 각 테넌트의 전체 스택 사일로에서 실행되고 있더라도 고객에게 SaaS 경험을 제공할 수 있습니다.
일반적인 목표는 SaaS 모델에서 애플리케이션을 실행하는 것입니다. 그런 다음 애플리케이션의 추가 현대화 및 개선에 관심을 돌릴 수 있습니다. 또한 이 접근 방식을 통해 비즈니스의 다른 부분(마케팅, 영업, 지원 등)을 더 빠른 속도로 이전할 수 있습니다. 더 중요한 것은 이를 통해 고객 참여를 시작하고 고객 피드백을 수집하여 환경을 지속적으로 현대화하는 데 사용할 수 있다는 것입니다.
사용하는 공유 서비스에는 궁극적으로 필요한 모든 기능이나 메커니즘이 포함되어 있지 않을 수 있다는 점에 유의해야 합니다. 주요 목표는 마이그레이션 초기에 필요한 공유 메커니즘을 만드는 것입니다. 이를 통해 애플리케이션 아키텍처의 발전과 운영 발전에 필수적인 시스템 요소에 집중할 수 있습니다.