Oracle SaaS 마이그레이션
ISV용 가이드

지난 몇 년 동안 우리는 60개 이상의 SaaS 기반 애플리케이션을 Oracle Cloud Infrastructure로 마이그레이션했습니다. 이러한 애플리케이션은 8개 업종의 핵심 엔터프라이즈 기능과 전 세계 199,000명 이상의 고객을 지원합니다.

이 가이드에서는 클라우드로의 여정에서 직접 경험한 주요 과제, 교훈, 모범 사례 및 이점을 공유할 예정입니다. 클라우드 전환에 대한 통찰력을 비즈니스에 적용해 보십시오.

공들이고 계획적이며 신중하게 실행된 클라우드 마이그레이션은 상당한 이점을 가져올 수 있습니다. 다음은 마이그레이션의 주요 내용입니다.

 
통합 데이터 센터
80 ~ 11개
 
절감된 CapEx
80%
 
절감된 인프라 비용
64%
 
절감된 소프트웨어 비용
42%
 
감소된 소프트웨어 공급업체
28 ~ 10개
 
단축된 프로비저닝 시간
98%

요약

자체 데이터 센터와 호스팅 환경을 운영하는 경우 클라우드로 전환하는 것이 큰 변화입니다. 클라우드는 향상된 복원력, 확장성 및 인프라 서비스 범위를 제공하지만, 이 여정을 완료하려면 기술, 조직 구조 및 비즈니스 관행을 재검토하고 조정해야 합니다. 이는 장기적인 제품 로드맵에서 계획된 기술 투자에 이르기까지 광범위한 변수 매트릭스에 영향을 미칩니다.

전환 과정에서 고유한 과제를 해결하고, 근본적인 질문에 답하고, 광범위한 기회를 포착해야 합니다. 클라우드로 가는 길은 명확하게 포장되어 있지 않습니다. 단일 접근 방식, 아키텍처 또는 서비스 집합이 모든 클라우드 애플리케이션에 유용하지는 않습니다.

ISV(Independent Software Vendor)를 위한 이 SaaS(Software-as-a-Service) 마이그레이션 가이드는 60개 이상의 SaaS 기반 애플리케이션을 OCI(Oracle Cloud Infrastructure)로 마이그레이션하는 과정에서 축적된 지식을 기반으로 합니다. 이러한 애플리케이션은 8개 업종의 핵심 엔터프라이즈 기능과 전 세계 199,000명 이상의 고객을 지원합니다. 우리 팀이 탐색한 많은 과제와 구현한 솔루션은 클라우드 모델로 마이그레이션할 때 직면할 수 있는 것과 동일합니다. 이 가이드는 전환의 모든 단계에 걸쳐 우리의 경험을 설명하고 고객의 여정을 지원하는 강력한 통찰력과 관찰을 제공합니다. 또한 Oracle@Oracle 웹 사이트를 방문하여 클라우드 전환 여정에 대해 논의하고 그 과정에서 학습한 모범 사례, 과제 및 교훈을 공유하는 12개 이상의 백서와 블로그를 참조할 수 있습니다.

우리는 내부 또는 외부 대상 SaaS 기반 애플리케이션을 제공하는 모든 ISV 또는 엔터프라이즈 제품도 클라우드로 전환하여 비슷한 이점을 누릴 수 있다고 믿습니다.

1장: 전환의 동인

클라우드 여정 탐색

애플리케이션 마이그레이션을 포함하는 모든 클라우드 전환 프로세스는 복잡합니다. 그러나 이러한 복잡성 중에는 클라우드로의 여정에서 명확하게 정의된 몇 가지 대상이 있습니다. 이러한 대상 중 하나는 "클라우드를 통해" 대상 애플리케이션을 구축하는 방법과 관련이 있습니다. 원하는 시간에 클라우드로 이동하기 위해 애플리케이션을 얼마나 클라우드 기반 환경으로 전환하기를 원하십니까? 이 백서 전체에서 이러한 대상의 개요를 설명하고 우리의 여정을 토대로 학습한 모범 사례와 교훈을 강조합니다. 성공의 열쇠는 마이그레이션 목표를 사전에 명확하게 정의하여 이를 달성하는 방법에 대한 최적의 결정을 내리는 것입니다. 여러분은 많은 잠재적 경로에 직면하게 될 것입니다. 마이그레이션 과정에서 개발자, 제공 팀 및 경영진은 진행 방법을 평가하고 여러 가지 선택을 해야 합니다.

비즈니스 목표를 달성하기 위해 결정해야 할 사항을 구성하기 위해 다음 기술 및 비즈니스 동인에 초점을 맞추는 것이 좋습니다.

확장성

클라우드 서비스는 관리형 인프라에 가능한 것보다 훨씬 더 큰 규모의 컴퓨팅 성능을 제공하여 비즈니스가 시장 기회에 맞게 성장할 수 있도록 지원합니다. ISV는 클라우드 기반 IaaS(Infrastructure as a Service) 및 PaaS(platform-as-a-service)를 통해 최신 구성 요소를 활용하여 확장 가능한 아키텍처를 구축하는 데 주력할 수 있습니다. 마이그레이션의 또 다른 이점은 내부 개발 팀이 IT 운영을 관리 및 확장하는 데 관여할 필요가 없기 때문에 성능을 조정하고 최적화하는 데 집중할 수 있다는 점입니다.

현대화

툴 세트, 서비스 및 아키텍처를 현대화하면 구성 요소 간의 통합이 용이해져 애플리케이션이 클라우드에서 사용할 수 있는 툴과 기술의 모든 가치를 실현할 수 있습니다. 이러한 툴은 인프라 업그레이드부터 자동화된 배포 파이프라인, 애플리케이션 성능을 향상시키는 통합 머신 러닝 모델에 이르기까지 다양합니다. 시장 변화에 발맞추기 위해서는 애플리케이션이 역동적이어야 하기 때문에 시장이 빠르고 일관된 변화를 겪고 있는 경우에 현대화는 가장 중요합니다. 경우에 따라 최신 기술 스택을 활용하여 서비스를 완전히 다시 작성하고 리브랜딩하여 비용을 절감하거나 보다 간소화된 서비스 옵션을 제공할 수 있습니다. 이러한 변경은 오래된 제품을 업데이트하고 라이센스가 부여된 오퍼링이 일반적인 기존 시장을 방해할 수 있습니다. 다른 경우에는 새로운 접근 방식으로 제품을 정비하여 브랜드 인지도와 고객 충성도를 유지하면서 서비스를 개선할 수 있습니다. 따라서 제품군을 완전히 변경할 필요는 없습니다.

클라우드로의 전환은 광범위한 현대화 추진의 계기가 됩니다. 클라우드를 통해 귀사와 귀사의 팀은 이전에는 불가능했던 서비스, 기술 및 전문 지식을 이용할 수 있게 됨에 따라 새로운 목표를 달성하고 새로운 기능을 제공할 수 있습니다. 귀사의 팀은 “스택을 한 단계 끌어올려” 개별 고객의 특정 구현에 연결된 사용자 지정 코드보다는 일반적으로 적용 가능한 새로운 제품 기능에 집중할 수 있습니다. 서비스 프로비저닝, 제품 업데이트 및 고객 지원이 그 어느 때보다 빠르게 수행됨에 따라 새로운 기능을 개발하는 데 리소스를 다시 집중할 수 있습니다. 이러한 방식으로 클라우드 마이그레이션은 제품 업그레이드 실행에서 고객 서비스 품질에 이르는 모든 것을 전환하면서 광범위한 현대화 활동의 장을 마련합니다.


"Oracle은 Gen2 클라우드로 마이그레이션함으로써 강력한 DevSecOps 모델을 통해 서비스를 성공적으로 제공할 수 있었으며 고객의 비즈니스 혁신을 지원할 수 있었습니다. 이제 매일 소프트웨어를 출시하고 프로비저닝 시간을 98% 이상 단축했습니다." — Karthic Murali, 선임 수석 제품 전략 관리자, Oracle Global Business Units

oracle@oracle


표준화

IaaS 및 PaaS 전반에 걸친 표준화를 통해 오버헤드를 줄이고 팀의 유연성과 대체성을 높일 수 있습니다. 조직이 성장함에 따라 귀사의 팀은 다양한 성숙도 수준의 툴을 채택하게 됩니다. 이러한 툴 세트를 클라우드 서비스 내에 통합하면 이 IT 관리 계층과 관련된 복잡성의 상당 부분이 추상화됩니다. 포트폴리오 전체에 매핑할 수 있는 작업에 대한 표준 운영 사례를 개발하고 사용할 수 있습니다. 또한 표준화를 통해 일상적인 작업을 보다 단순하고 예측 가능하게 함으로써 기본 작업에 대한 인력 수요를 줄일 수 있습니다. 이전에 애플리케이션 간에 호환되지 않을 수 있는 다양한 프로세스를 탐색하는 데 묶여 있던 리소스는 고객을 위한 차세대 제품 및 서비스 개발을 비롯한 보다 중요한 문제에 자유롭게 집중할 수 있습니다.

특히 표준화를 통해 팀이 기존 제품과 신제품에 손쉽게 적용할 수 있는 보안, 위험, 규정 준수 및 기타 운영 활동에 대한 글로벌 정책 및 관행을 간편하게 적용할 수 있습니다. 실제로 인증된 규정 준수 인증과 같은 IaaS 플랫폼의 많은 고유 기능은 애플리케이션에서 상속될 수 있습니다.

수익 최적화

수익 최적화는 두 가지 기본 방법으로 달성할 수 있습니다. 첫째, 가장 분명한 것은 비용 절감입니다. IaaS를 활용하여 데이터 센터를 제거하면 재무 모델이 CapEx에서 OpEx로 전환될 뿐만 아니라 일반적으로 상당한 TCO 절감 효과도 얻을 수 있습니다. 클라우드로 마이그레이션된 애플리케이션 포트폴리오에서 사용되는 기술 스택을 합리화함으로써 얻을 수 있는 비용 절감 효과는 명확하지 않을 수 있습니다. 공통 툴 세트는 기관의 전문 지식을 창출하고 표준화되지 않은 툴에 대한 임시 교육과 관련된 비용을 절감합니다. 이러한 라인에 따라 인프라를 코드로 취급하는 공통 툴 세트는 궁극적으로 시간과 인건비를 절약하는 자동화를 제공합니다. 마지막으로, 보안과 같이 포트폴리오 전반에 적용되는 기본 영역에 전문화된 팀은 각 개별 제품 팀 내에서 전문가를 구성할 필요가 없습니다.

둘째, 클라우드 환경으로 전환하면 일반적으로 애플리케이션이 클라우드 지원 또는 클라우드 네이티브가 되면 제품 개발 기간이 단축되므로 궁극적으로 시장 출시 기간을 단축할 수 있으므로 매출을 최적화할 수 있습니다. 시장 출시 시간을 단축하면 수익 실현 시간이 단축됩니다. 애플리케이션이 클라우드 지원 상태가 되면 몇 분 만에 전 세계 어디에나 배포할 수 있습니다.

위에서 논의한 원칙을 결합하면 표준화된 제품 및 서비스 아키텍처와 배포 속도 및 품질을 개선할 수 있습니다. 반복적인 패턴에 대한 설계 결과를 확장하면 수익 최적화, 가치 창출 시간 단축, 고객의 서비스 품질 및 무결성 향상에 리소스를 재집중할 수 있습니다.


WorkForce Software는 직원 관리 솔루션을 Oracle Cloud Infrastructure로 마이그레이션하고 30% 성능 향상을 실현합니다.

Workforce"즉, 재무 성과를 통해 CapEx 지출을 30-35% 절감할 수 있었고 OCI의 뛰어난 성능을 통해 제품군과 함께 제공되는 ROI는 계속해서 향상되었습니다." —Mike Morini, 최고 경영자, WorkForce Software

자세한 내용


클라우드에서 가치를 창출하는 경로

클라우드 컴퓨팅에는 일련의 IaaS 및 PaaS 리소스는 물론 베어 메탈 인스턴스에 대한 액세스부타 통합 컨테이너형 환경, 완전한 기능을 갖춘 서비스 스택에 이르기까지 다양한 소프트웨어 배포 모델이 포함될 수 있습니다. 가장 기본적인 수준에서 클라우드 컴퓨팅은 물리적 인프라 구성 요소를 핵심 IaaS 리소스로 교체하는 것을 의미합니다.

대부분의 엔터프라이즈 애플리케이션은 원래 클라우드용으로 구축되지 않았습니다. 많은 애플리케이션에서 클라우드 패턴을 변환하거나 준수하는 것은 시간이 많이 걸리고 어렵습니다. 플랫폼 재구축은 시간과 인건비 면에서 비용이 많이 들 수 있으므로 클라우드 네이티브 주체를 위해 처음부터 설계하는 것이 더 쉬울 수 있습니다. 이러한 점을 고려할 때 기업은 일반적으로 클라우드 마이그레이션을 고려할 때 세 가지 주요 시나리오 중 하나를 발견하게 됩니다.

  • 레거시 데이터 센터 종료: 데이터 센터를 운영하는 것은 비용이 많이 듭니다. 건물, 인력, 전력, 냉각, 유지 보수 및 업그레이드는 일상 업무 중 일부에 불과합니다. 많은 기업이 후보자들이 외부로 이동할 수 있도록 애플리케이션 포트폴리오를 평가함으로써 데이터 센터의 의존성을 줄이거나 제거하기 위해 적극적으로 노력하고 있습니다. 우선 순위는 자본 비용을 줄이거나 제거하기 위해 애플리케이션을 코로케이션, 관리 호스팅 또는 온프레미스 데이터 센터 외부로 이동하는 것입니다. 클라우드 내 베어 메탈 서버 또는 가상 머신으로 애플리케이션을 마이그레이션하는 리프트 앤 시프트 전략이 사용되는 경우가 많습니다.
  • 기술 스택 진화: 이 경우 기업은 추가 투자가 필요하지만 시간이 지남에 따라 더 많은 가치를 창출할 것으로 예상되는 애플리케이션으로 점진적으로 변경하기 시작합니다. 애플리케이션 자체를 크게 변경하지 않고 온프레미스 버전의 Oracle Database를 클라우드 기반 Oracle Autonomous Database로 교체하는 경우를 예로 들 수 있습니다. 이를 이동 및 개선 전략이라고도 합니다.
  • 클라우드 네이티브에 올인: 애플리케이션을 처음부터 클라우드 기반 환경으로 다시 설계할 경우 위에서 언급한 시나리오 중 하나를 구현하는 동시에 성숙도가 낮은 애플리케이션을 그대로 유지하는 데 드는 비용보다 더 큰 이점이 있을 수 있습니다. 클라우드 네이티브 애플리케이션은 기본적으로 고도로 분산되어 있으며(대개 12개 요소 원칙을 활용하여 구성됨), 따라서 기본 아키텍처와 독립되도록 설계되어 있습니다. 즉, 기본 인프라가 중단되더라도 애플리케이션이 계속 실행됩니다. 간단히 말해, 클라우드로의 이동이 기본 인프라와 긴밀하게 연결된 애플리케이션을 이동하는 것보다 훨씬 쉽기 때문에 이 경로가 대상 애플리케이션에 적합한지 평가할 가치가 있습니다.
클라우드 네이티브 패턴 eBook
오라클에서 클라우드의 네이티브, 클라우드 네이티브 애플리케이션의 출처 및 애플리케이션을 구성할 때 따라야 할 모범 사례에 대한 자세한 내용은 이 eBook을 읽어보십시오.

이러한 시나리오를 구상하는 또 다른 방법은 엔터프라이즈 애플리케이션을 클라우드 네이티브 아키텍처로 전환하는 동시에 애플리케이션을 오라클 클라우드 인프라스트럭쳐(OCI)로 이동하기 위해 취할 수 있는 다양한 조치를 살펴보는 것입니다. 아래 그림 1을 참조하십시오.


그림 1: 클라우드 마이그레이션 변경 및 투자 수준

그림 1의 왼쪽은 최소한의 변화량, 가장 짧은 가치 창출 시간, 가장 낮은 초기 투자를 나타냅니다. 일반적으로 오른쪽으로 이동함에 따라 변화, 투자 및 시간의 수준이 증가하지만 실현된 가치도 커집니다. 이 모델을 사용하면 이동 단계에서 어떤 종류의 투자를 고려해야 할지 예측할 수 있습니다. 애플리케이션이 무수히 많은 방식으로 구축되므로 시나리오가 반드시 개별적인 것은 아니며 약간 중복된다는 점에 유의하십시오.

위에서 설명한 시나리오는 기존 성숙도 수준 및 클라우드 전환 목표를 평가하기 위한 주요 기준점이 됩니다. 현재 상태와 목표 상태 간의 차이를 통해 클라우드 전환에 필요한 기술 및 프로세스 변경 범위를 대략적으로 예측할 수 있습니다. 완벽한 환경에서 클라우드로 전환하면 모든 애플리케이션이 클라우드 네이티브 제공 모델로 전환됩니다. 그러나 리소스와 시간의 제약으로 인해 단일 프로세스로 전체 포트폴리오를 클라우드 네이티브 모델로 전환할 수 있는 조직은 거의 없습니다. 단순한 플랫폼 재배치 작업도 리소스를 많이 소모할 수 있으며 레거시 기능을 복제하는 데만 상당한 투자가 필요합니다.

따라서 클라우드 전환은 최적의 클라우드 성숙도 수준(위에 표시된 클라우드 호스팅에서 클라우드 네이티브 연속체에 이르는 애플리케이션)과 제품 및 관련 비즈니스 프로세스를 재설계하는 데 필요한 엔지니어링 투자 간의 균형을 파악하는 것이 문제입니다. 이 단계에서는 격차를 해소하는 데 필요한 개발 투자의 대략적인 추정치를 통해 각 애플리케이션의 현재 및 목표 성숙도를 파악하는 것이 핵심 단계입니다.

마이그레이션 중에 성숙도 수준을 변경하는 애플리케이션도 운영 패턴과 기대치를 변경해야 합니다. 성숙도 수준의 변경은 서비스를 지원하는 팀, 프로세스 및 정책에 영향을 미칩니다.

 

2장: 준비 및 투자 목표

클라우드에 대한 기술적 준비 상태 평가

마이그레이션 요구 사항 및 종속성을 이해하려면 대상 애플리케이션 또는 여러 SaaS 기반 애플리케이션을 제공하는 회사용 전체 애플리케이션 포트폴리오에 대한 기술적 이해가 필수적입니다. 이 단계에서 집중해야 할 영역은 애플리케이션에 필요한 기능 및 이러한 기능이 이러한 의존성과 어떻게 관련되는지 식별하는 것입니다. 이는 마이그레이션 활동의 상대적인 시기를 앞당기고 주요 중점 영역을 파악하는 데 도움이 됩니다. 평가는 세 가지 중요한 차원을 다루어야 합니다.

  1. 인프라 요구 사항: 클라우드는 소프트웨어를 기반 하드웨어 또는 운영 환경에서 분리합니다. 성숙도가 높은 애플리케이션은 클라우드에서 쉽게 확장할 수 있는 CPU 또는 Kubernetes 클러스터와 같은 일반적인 인프라 리소스만 사용하므로 기본적으로 환경에 독립적입니다. 성숙도가 낮은 애플리케이션은 특정 장비, 구성 요소 또는 관리형 인프라나 기타 전용 시스템 같이 제공되는 환경에 따라 달라집니다. 애플리케이션이 클라우드 내 인프라 구성 요소 및 구성에 대한 엄격한 종속성을 갖는 정도를 먼저 기록한 후 최종적으로 제거해야 합니다. 기본 인프라에 연결되거나 결합된 사용자 지정(귀사 또는 귀사의 고객)을 찾는 것은 드문 일이 아닙니다.
  2. 서비스 구성 요소: 클라우드는 애플리케이션과 독립적으로 운영 및 제공되는 독립형 서비스로서의 지원 기능을 제공합니다. 성숙도가 높은 애플리케이션은 스택 전반에서 최소한의 종속성으로 개별 구성 요소를 중심으로 설계되므로 목표 변경 및 업그레이드를 지원하고 가동 시간을 극대화할 수 있습니다. 성숙도가 낮은 애플리케이션은 긴밀하게 결합된 대규모 구성 요소로 설계되어 상호 의존성이 매우 높아지므로 단일 엔터티로 관리해야 합니다. 이러한 서비스 관계는 각 애플리케이션에 대해 문서화해야 합니다.
  3. 운영 준비: 클라우드는 기술 아키텍처뿐만 아니라 작업 프로세스, 기술력, 사용 가능한 툴 및 운영 모델을 변경합니다. 성숙도가 높은 애플리케이션은 이미 클라우드 애플리케이션처럼 실행되며 클라우드에서 잘 작동하는 프로세스, 표준 및 툴 세트를 사용합니다. 성숙도가 낮은 애플리케이션은 클라우드에서 중요한 지원 서비스가 누락된 것을 발견하거나, 클라우드 작업에 적합하지 않은 기술력을 갖춘 팀을 두거나, 클라우드로의 전환으로 인해 중단되는 프로세스를 사용합니다.

이러한 요소와 관련하여 애플리케이션의 성숙도를 평가하여 마이그레이션을 시작하면 적절한 계획을 수립하고 다운스트림에서 지연을 유발하고 비용을 증가시키며 목표를 달성하지 못하도록 하는 예기치 않은 상황을 방지할 수 있습니다. 현재 프로덕션 환경, 지원 서비스 제품군 및 대상 클라우드 환경은 프로세스 전반에 걸쳐 계속 발전하기 때문에 마이그레이션의 복잡성은 간과하기 어렵습니다. 서비스와 애플리케이션 간의 연결을 확인하면 지능적인 계획을 미리 수립할 수 있을 뿐만 아니라 마이그레이션 중에 불가피하게 발생할 변화에 유연하게 대응할 수 있습니다. 이 평가를 효과적으로 문서화하면 마이그레이션 프로세스에 대한 명확한 할 일 목록이 생성됩니다. 이를 통해 계속 변화하는 로드맵에 맞춰 예측된 마이그레이션 일정을 조정할 수 있습니다.


Zoom은 Oracle Cloud Infrastructure에서 수백만 개의 동시 회의를 빠르게 확장하고 활성화합니다.

Zoom"우리는 최근 서비스 용량을 대폭 늘려야 하는 가장 큰 폭의 성장을 경험했습니다. 우리는 여러 플랫폼을 탐색했으며 Oracle Cloud Infrastructure는 용량을 신속하게 확장하고 새로운 사용자의 요구를 충족하는 데 중요한 역할을 했습니다." — Eric S. Yuan, CEO, Zoom

자세한 내용


재정 목표

다른 IT 이니셔티브와 마찬가지로 클라우드 전환을 위해서는 특히 대상 애플리케이션이 온프레미스 호스팅 모델에 맞게 구축된 경우 최고의 가치를 달성하기 위해 일련의 투자가 필요합니다. 클라우드로 전환할 가치가 있다고 여겨지는 애플리케이션은 시간이 지남에 따라 결국 클라우드 기반이 되거나 중단될 것입니다. 그러나 초기 목표는 대개 애플리케이션을 클라우드 릴리스 상태로 전환하는 것입니다.

애플리케이션을 현재 상태에서 클라우드 릴리스 상태로 전환하려면 일련의 의사 결정과 초기 투자가 필요합니다. 애플리케이션을 베어 메탈 서버(대부분의 투자가 클라우드 인프라에 있는 경우)로 단순히 이동 및 배포할 계획입니까? 아니면 이동하기 전에 애플리케이션을 클라우드 기반으로 만들 계획이십니까? 이 경우 애플리케이션 스택의 일부를 클라우드 기반 모델로 이동(데이터베이스를 온프레미스에서 DBaaS 또는 Oracle Autonomous Database로 이동)하기 위해 일부 투자가 필요합니다. 고객별 기능을 활성화하기 위해 하드 코딩된 사용자 지정을 생성한 경우 플랫폼 구성 요소를 캡슐화하고 API를 통해 제품화된 기능으로 제공하는 모델에 맞게 리팩터링해야 합니다. 클라우드에서 고도로 분산된 애플리케이션을 확장하려면 하드웨어 또는 플랫폼 종속성을 제거해야 합니다. 이러한 투자를 이해하는 것은 클라우드로의 전환과 관련된 재무 목표를 계획하고 달성하는 데 있어 매우 중요한 요소입니다.

초기 투자에는 방금 설명한 클라우드 마이그레이션 단계와 관련하여 필요한 제품 변경 작업을 수행하는 데 필요한 개발 시간과 인력이 포함됩니다. 그러나 추가적인 비용도 고려해야 합니다. 조직 전환 과정에서 발생할 수 있는 광범위한 비용은 다음과 같습니다.

  • 개발 투자: 데이터베이스 마이그레이션 및 애플리케이션 프로비저닝과 같은 활동을 지원하기 위한 자동화를 포함하여 제품을 다시 설계하거나 마이그레이션 작업을 가속화하는 데 필요한 개발 인력
  • 마이그레이션 실행: 새 자산을 프로비저닝하고, 기존 환경과 데이터를 마이그레이션하고, 레거시 재고를 폐기하는 데 필요한 인건비
  • 인프라 활용: IaaS 램프를 통해 발생하는 구독료는 안정적인 상태로 전환되지만 마이그레이션 기간 동안 새로운 증가분을 나타냅니다.
  • 고립된 인프라: 마이그레이션 작업을 통해 제거하거나 탕감할 수 있을 때까지 지속되는 데이터 센터 및 CapEx 감가 상각 비용
  • 인력 전환: 기존 팀의 훈련, 교육 또는 구조 조정과 관련된 비용 또는 필요한 클라우드 기술력을 갖춘 신규 리소스 채용 비용
  • 고객 전환: 새로운 모델에서는 지원할 수 없는 환경 기능 또는 서비스 조건의 변경과 관련된 비용(신규 개발, 인센티브, 계약 항목의 재협상 또는 고객 이탈 포함)

크든 작든, 이러한 각 비용은 IaaS로의 전환에 필요한 구성 요소입니다. 각각 다른 방식으로 비용 프로파일에 영향을 미칩니다. 예를 들어 개발 투자 및 마이그레이션 실행 비용은 이 작업과 관련된 리소스를 수정할 수 있더라도 일회성 버킷에 포함될 수 있습니다. 새로운 인프라를 도입하면 고립된 인프라 비용을 제거할 때까지 일정 기간 동안 비용이 순증가 됩니다. 교육 또는 마이그레이션 인센티브와 같은 일부 인력 및 고객 전환 비용은 일회성 비용에 해당됩니다. 인력 확충이나 고객 계약 변경과 같은 기타 항목은 잠재적으로 새로운 지속적 비용을 발생시킬 수 있습니다.

클라우드 전환에 대한 준비를 하고 기대치를 설정하는 데 조직에서는 시간이 지남에 따라 이러한 역학 관계가 어떻게 전개될지 이해하는 것이 중요합니다. 클라우드의 극적인 이점에 관심이 있지만 전환 위험을 명확히 이해하지 못한다면 초기 단계의 비용 증가, 특히 마이그레이션, 중복 인프라 및 전환 비용을 미리 흡수하는 과정에서 발생하는 비용에 놀랄 것입니다. 올바른 기대치를 설정하고 점진적인 진행 상황을 가시적으로 유지하는 것은 조직이 전환 과정을 진행하는 동안 정렬과 규율을 유지하는 데 필수적인 요소입니다.

클라우드 마이그레이션 재고

클라우드 마이그레이션 재고는 클라우드로 이동하는 데 필수적입니다. 클라우드 마이그레이션 재고란 무엇입니까? 요컨대, 집합의 모든 자산 목록과 각 자산을 설명하는 관련된 중요한 데이터 요소입니다. 이는 전환 대상 애플리케이션 및 모든 종속성입니다. 이러한 데이터를 캡처하는 데 사용되는 미디어는 관련이 없으며, 데이터가 회사 내의 여러 부서에 걸쳐 있기 때문에 여러 툴을 활용하는 것은 드문 일이 아닙니다. 일반적으로 필요한 정보는 생산, 영업 및 운영 데이터베이스 전반에 걸쳐 분산되어 있습니다. 예를 들어 구성 관리 데이터베이스는 기술 종속성 및 자산 위치를 실제 서버 및 랙 위치까지 상세하게 추적할 수 있습니다. 그러나 고객에게 전환 사실을 알리는 시기와 방법을 결정하는 데 필수적인 비즈니스 및 고객 고려 사항은 포함되지 않습니다. 이러한 정보는 종종 운영 및 지원 이해 관계자를 위해 설계된 저장소에 포함됩니다. 또한 인수, 특수 사용 사례 및 제품 사일로로 인해 정보가 여러 저장소에 걸쳐 더욱 단편화될 수 있습니다.

마이그레이션 재고의 주요 목적은 클라우드로의 전환을 관리하는 데 필요한 요소를 중앙 집중식으로 보여주는 것입니다. 예: 자산이란 무엇입니까? 자산은 어디에 있습니까? 어떤 제품을 지원합니까? 기능은 무엇입니까? 어떤 고객을 지원합니까?

처음부터 청사진이 살아있는 문서라는 것을 깨닫는 것이 중요합니다. 특히 여러 애플리케이션 또는 여러 버전의 애플리케이션을 사용하는 회사에서는 시간이 지남에 따라 발전하므로 유연해야 합니다. 새로운 문제가 표면화되고 새로운 요구가 발견됨에 따라 재고는 진화할 것입니다. 마이그레이션 과정에서 기본 클라우드 인프라도 변경되어 재고가 다시 진화할 수 있습니다. 마이그레이션 재고는 가능한 많은 가용 데이터를 캡처하여 초기 계획을 시작한 다음 전환 과정에서 새로운 요구 사항이 드러나면 세부 계층을 추가해야 합니다.

마이그레이션 재고를 관리하는 것은 세부 데이터의 필요성과 수집 작업의 균형을 맞춰야 하는 교차 기능 프로젝트입니다. 또한 세부 기술 사양, 아키텍처 접근 방식, 고객 요구 사항 및 데이터 전송 경로와 같이 타이밍과 속도에 영향을 미치는 종속성, 제약 조건 및 리소스를 식별하는 요소도 포함됩니다. 정보가 너무 적고 재고가 유용하지 않습니다. 너무 많으면 유지하기가 부담스러우며, 이는 빠르게 시대에 뒤떨어져 구식이 될 수 있습니다.

클라우드 마이그레이션의 시작점으로 다음 마이그레이션 재고 프레임워크를 사용하는 것이 좋습니다.

재고를 운영 재고로 마이그레이션

마이그레이션 재고에 초점을 맞추고 있지만 클라우드 전환은 궁극적으로 두 가지 과제를 제시합니다. 가장 직접적으로 마이그레이션 활동을 계획하고, 우선 순위를 지정하고, 추적할 필요가 생깁니다. 그러나 마이그레이션 자체는 일상적인 운영 추적에 필요한 데이터를 강제로 변경합니다. 예를 들어 물리적 서버 및 랙에 대한 마이그레이션 후 구성 세부 정보는 중요하지 않고 개별 인스턴스에 대한 정보조차 중요하지 않게 됩니다. 동시에 특히 조직이 셀프 서비스 모델을 채택함에 따라 전체 사용량 및 데이터 송신과 같은 메트릭스가 중요해질 수 있습니다.

마이그레이션 재고를 생성하면 이러한 새로운 클라우드 중심 데이터 스키마 및 프로세스로 전환이 시작됩니다. 재고 생성 및 애플리케이션 마이그레이션과 관련된 두 가지 당면 과제는 별개의 프로젝트이지만, 이러한 과제를 단독으로 추진해서는 안 됩니다. 마이그레이션 작업은 주도적인 작업이며, 조직이 자산에 대한 상세하고 통합된 보기를 만든 것은 이번이 처음일 수 있습니다. 이는 새로운 마이그레이션 후 재고 보기의 템플릿을 형성해야 하는 전환의 순간입니다. 위에서 설명한 것처럼 마이그레이션 재고는 유연하고 적응력이 있어야 합니다. 올바르게 관리되면 마이그레이션 재고는 중요한 마이그레이션 후 재고 관리 툴로 발전할 것입니다.

3장: 클라우드 여정 시작

클라우드로의 전환 시범 운영

SaaS 애플리케이션 호스팅을 위한 인프라 설계

SaaS 기반 애플리케이션을 제공하는 ISV는 서비스를 호스팅하고 고객을 격리된 방식으로 관리할 수 있는 안전하고 확장 가능한 엔터프라이즈급 인프라가 필요합니다. 아래 그림 3에 표시된 참조 아키텍처는 모범 사례를 통합하는 검증된 프레임워크를 제공하여 Oracle Cloud Infrastructure에서 SaaS 애플리케이션을 호스팅할 수 있도록 지원합니다.

이 참조 아키텍처에서는 격리된 여러 애플리케이션 인스턴스를 배포하고 관리합니다. 각 배포는 특정 테넌트에 대한 것이며 이러한 개별 테넌트 애플리케이션 인스턴스는 공통 관리 계층을 통해 관리됩니다.

모든 테넌트 애플리케이션 인스턴스를 단일 코드 기반으로 구축하거나 사용자 지정된 버전의 애플리케이션을 각 테넌트에 제공하도록 선택할 수 있습니다. 이 패턴은 애플리케이션 환경의 완벽한 분리가 필요한 SaaS 고객에게 적합합니다.

그림 3: OCI의 SaaS 애플리케이션을 위한 모범 사례 참조 아키텍처

위의 참조 아키텍처에 대한 자세한 내용은 오라클 아키텍처 센터를 방문하십시오. 또한 4개의 테넌트를 위한 아키텍처를 구축하는 데 도움이 되는 Terraform 기반 툴을 단계별 가이드와 함께 개발했습니다. 마지막으로, 항상 Oracle Cloud Infrastructure 모범 사례 가이드를 따르는 것이 좋습니다. 이 가이드는 보안 및 규정 준수, 신뢰성 및 복원력, 성능 및 비용 최적화, 운영 효율성 같은 4가지 일반적인 비즈니스 목표에 대한 지침을 제공합니다.

아키텍처 변경 외에도 클라우드에서 서비스 스택이 어떻게 변화할 것인지 고려해야 합니다. 온프레미스 아키텍처용으로 개발된 레거시 환경에 구현된 모니터링, 네트워크 관리 또는 보안에 사용되는 핵심 툴 세트는 클라우드를 위해 발전할 것입니다. 클라우드로 전환하면 이러한 툴에서 다루는 범위를 확장할 수 있습니다. 클라우드 기반 툴은 주로 엔드포인트를 모니터링하는 대신 스택 전체에 대한 모니터링을 제공합니다. 때때로 클라우드 서비스 공급자는 핵심 기능을 기반으로 클라우드 또는 하이브리드 기반 모니터링 툴을 제공합니다. Oracle Cloud Infrastructure의 경우 기본 모니터링, 태깅 및 감사 기능을 함께 사용하면 전체 서비스 스택을 모니터링하고 지정된 규범 이외의 이상 징후를 자동으로 해결할 수 있습니다. 현재 온프레미스에서 타사 모니터링 툴을 사용하는 경우 이러한 공급업체는 하이브리드 또는 클라우드 기반 툴도 제공할 수 있습니다.


Cisco Tetration은 핵심 애플리케이션을 Oracle Cloud Infrastructure로 전환하고 성능이 60배 향상되었습니다.

Cisco Tetration"Oracle과의 파트너십은 환상적이었습니다. 이것이 바로 Cisco Tetration과 관련된 모든 마법이 일어나는 이유입니다." — Navindra Yadav, 설립자, Cisco Tetration


파일럿 프로그램 시작

다른 엔지니어링 작업과 마찬가지로 소규모 파일럿 프로그램이나 프로토타입부터 시작하여 파일럿 팀과 귀사에 수행 가능한 작업과 진행 방법에 대한 감각을 제공함으로써 성공 가능성을 극대화합니다. 파일럿 및 개념 증명 프로그램은 전면적이면서 전사적인 변화에 따른 시간 및 재정적 부담 없이 문제를 식별하고 해결합니다. 파일럿 프로그램은 느리게 이동하고 새로운 운영 환경에 익숙해짐으로써 변경 속도를 관리하는 데 도움이 될 수 있습니다.

파일럿은 핵심 개발자 및 운영 직원 그룹이 대상 클라우드 환경을 탐색하고 아키텍처, 서비스 및 운영 모델을 학습할 수 있는 기회입니다. 이 팀은 실무 지식, 유용한 도구 및 모범 사례뿐만 아니라 자신감, 전문 지식 및 경험의 씨앗을 구축합니다. 귀사는 이러한 지식을 쌓는 동시에 클라우드 기반 환경에서 팀 간 협업을 위한 규칙을 발전시키고 있습니다. 클라우드를 마이그레이션하려면 애플리케이션 팀이 직접 리소스 관리자에서 다른 팀에서 제공하는 서비스의 소비자로 발전해야 합니다. 파일럿을 통해 애플리케이션 팀은 서비스 경계가 어떻게 변하는지 이해하고, 사용할 서비스를 제공하는 운영 팀과의 관계를 구축하고, 이러한 운영 팀과 함께 자신의 요구를 옹호하는 방법을 배울 수 있습니다.

파일럿은 다음과 같은 이점을 제공합니다.

  • 특히 기술이 항상 동일한 환경에서 실행되는 경우 기술의 이동성에 대한 가정을 검증(또는 도전)하는 컨텍스트입니다. 이를 통해 팀은 마이그레이션할 준비가 되었는지 여부를 파악하고 이를 위해 변경해야 할 사항을 식별할 수 있습니다.
  • 애플리케이션/데이터베이스가 대상 환경의 서비스와 통합될 준비가 되었는지 확인할 수 있는 기회입니다. 이를 통해 필요한 변경 사항과 애플리케이션 및 대상 서비스 환경을 모두 마이그레이션할 준비가 된 시기를 알 수 있습니다.
  • 발판을 마련하여 대상 환경을 위한 구축 능력을 갖추면 새로운 서비스 및 환경으로 이동함에 따라 나머지 포트폴리오를 위한 출발점이 됩니다. 이는 팀에게 포트폴리오에 대한 전략적 목표를 제공합니다.

Manhattan Associates는 공급망 솔루션을 Oracle Cloud Infrastructure로 마이그레이션하고 이전 클라우드 솔루션에 비해 비용을 50% 절감합니다.

Manhattan Associates"애플리케이션과 데이터베이스 계층 모두에서 오라클 클라우드의 다양성과 유연성으로 인해 인프라 측면에서 이전 클라우드 솔루션보다 약 50%의 비용이 절감되었습니다." — Jeff Demenkow, 부사장, Manhattan Associates


파일럿 프로그램 관리

파일럿은 기술 및 운영 직원은 물론 경영진 및 관리 팀을 위한 학습 경험입니다. 경영진 및 관리 팀은 조직의 장애물을 제거하고 파일럿 프로젝트에서 학습한 내용(즉, 무엇이 성공했는지, 무엇이 실패했는지, 모범 사례, 학습한 내용, 표준 패턴 또는 반대 패턴)을 최대한 활용할 수 있도록 파일럿 팀과 지속적으로 커뮤니케이션해야 합니다. 이러한 중요한 정보를 캡처한 다음 나머지 조직과 공유할 수 있으므로 후속 클라우드 프로젝트를 보다 효과적이고 효율적으로 수행하는 것이 이상적입니다. 파일럿을 통해 경영진이 계획을 세우고 불확실한 영역을 정리하는 데 사용한 가정을 테스트할 수 있습니다. 이러한 가정은 조직마다 다르지만 파일럿은 모든 마이그레이션에서 몇 가지 주요 과제를 제시합니다.

  • 교육 파일럿은 기존 기술을 테스트하여 조직이 기술 마이그레이션 작업에 얼마나 준비가 되어 있는지 보여줍니다. 경영진은 파일럿을 사용하여 기술 숙련도를 평가하고, 어떤 도구와 기능을 배우는 것이 가장 중요한지 이해하고, 이러한 핵심 영역에서 기술을 신속하게 구축(또는 채용)하는 방법을 계획해야 합니다.
  • 협업: 파일럿은 개발, 운영 및 지원 팀이 서로 어떻게 다르게 협력할 것인지를 보여줍니다. 경영진은 이러한 팀이 파일럿 기간 동안 실제로 협력하고, 새로운 요구 사항을 제시하고, 새로운 환경에서 운영 방법을 이해하도록 해야 합니다.
  • 변화에 대한 욕구: 파일럿은 광범위한 마이그레이션에 영향을 미칠 문화적 장벽을 찾을 수 있는 기회입니다. 파일럿에서 문제가 있는 그룹은 규모에 따라 동일한 반응을 보입니다. 파일럿은 경영진이 문제를 식별하고, 교육을 배포하고, 특정 조직의 현실을 고려하여 계획을 조정할 수 있는 기회입니다.

원활한 마이그레이션을 위해서는 견고한 기반을 구축하는 것이 중요합니다. 마이그레이션의 첫 번째 단계는 핵심 서비스 및 플랫폼 개발을 주도하며 마이그레이션이 진행됨에 따라 점차 확장될 것입니다. 결국 이러한 핵심 기능은 전체 마이그레이션 포트폴리오를 지원하도록 확장해야 합니다. 따라서 초기 클라우드 릴리즈는 성공적이어야 할 뿐만 아니라 다음의 모든 릴리즈 및 업그레이드에 대한 런웨이를 생성하는 것이 중요합니다.

4장: 클라우드 기반 조직 결과

조직 변화에 적응

SaaS 애플리케이션 호스팅을 위한 인프라 설계

조직의 제공 모델 및 고객 관계를 변경하려면 새로운 기술, 지식, 비즈니스 프로세스 및 사고 방식이 필요할 수 있습니다. 이러한 변화는 조직 전반에 걸쳐 광범위한 영향을 미칠 수 있으며, 클라우드 전환에서 문화적 변화가 가장 어려운 측면이라고 자주 언급되는 이유가 이 때문입니다.

이러한 변화의 범위로 볼 때 클라우드 전환을 위해 대규모로 재구성하고 클라우드 경험과 전문 지식을 갖춘 인력 교체를 도입해야 한다는 인상을 줄 수 있습니다. 내부 기능 전문화의 변화와 클라우드 기술력에 초점을 맞춘 신규 채용이 클라우드 전환의 주요 구성 요소이기는 하지만, 지금까지 귀사의 성공에 핵심적인 확립된 프로세스, 동적 요소 및 기여 요소를 잃을 수는 없습니다. 조직 변경 속도를 비즈니스 및 고객 환경의 잠재적 중단과 균형 있게 유지하는 것이 중요합니다. 이러한 균형을 유지하려면 기존 직원이 새로운 운영 모델로 전환할 수 있도록 경력 개발 역량에 대한 구조적 변경을 재조정해야 합니다.

오래된 소프트웨어 비즈니스를 클라우드 제공 모델로 전환하려면 여러 주요 비즈니스 영역에서 가정, 기술 노하우 및 표준 운영 프로세스를 대폭 변경해야 합니다. 필요한 변화의 양은 감당하기 어려울 수 있지만, 경험에 따르면 일반적으로 클라우드 전문가를 완전히 정비하는 것보다 기존 팀을 유지하고 투자하는 것이 더 낫습니다. 유사한 전환을 계획 중인 조직은 각 팀이 각자의 마이그레이션 인벤토리 및 서비스 스택 로드맵을 작성할 수 있도록 변화 요구에 대한 분산형 상향식 평가를 통해 GBU 조직이 어떻게 시작했는지 살펴봐야 합니다. 따라서 각 제어 영역 내에서 필요한 단계를 파악해야 합니다. 이러한 접근 방식을 통해 팀은 실질적인 변화 동인에 맞춰 프로그램을 조정하면서 필요한 것이 무엇인지에 대한 개괄적인 가정을 피할 수 있었습니다.


8x8은 Oracle Cloud Infrastructure로 전환하여 전 세계를 연결하고, 비용을 80% 절감하고, 서비스를 개선합니다.

8x8"화상 회의가 오늘날의 새로운 세계의 연결 조직이 되면서 사용자 수가 급증했습니다. 이러한 폭발적인 성장을 지원하기 위해 몇 가지 플랫폼을 검토하고 강력한 보안, 탁월한 가격 대비 성능 및 세계적 수준의 지원을 제공하는 Oracle의 Gen 2 Cloud 인프라를 선택했습니다." — Vik Verma, CEO, 8x8

동영상 보기


비즈니스 영향:

클라우드로의 성공적인 중심화는 조직 전체의 변화를 통해 가능해집니다. 주로 호스팅되는 포트폴리오 또는 사내 포트폴리오에서 클라우드 기반 비즈니스로 전환하려면 고객과의 관계를 근본적으로 변경해야 합니다. 그러나 확립된 비즈니스 관행과 가정이 변경되는 정도는 클라우드 전환 시 수행되는 제품 변경 범위에 따라 크게 달라집니다.

변경이 적은 시나리오에서도 IaaS로 전환하면 비즈니스 프로세스의 변화가 일어납니다. GBU는 이러한 맥락에서 변화를 위한 두 가지 주요 기회를 확인했습니다.

  1. CapEx 집약적인 물리적 인프라 관리를 단기 변동과 장기적인 기대치를 고려한 OpEx 중심의 예측 모델로 대체
  2. 기존 책임에서 벗어나 서비스 구성 요소 제공에 주력한 보안 및 규정 준수 팀을 혁신

—애플리케이션의 기술적 변화와 함께— 이러한 변화를 해결하는 조직은 클라우드 마이그레이션의 잠재력을 최대한 실현할 수 있는 더 나은 위치에 있습니다.

고객 조정

"쉬링크 랩(shrink-wrap)" 제품 또는 호스팅된 제품에서 실제 클라우드 서비스로 전환하는 것은 여러분과 고객이 함께 수행해야 할 여정입니다. 실제로 클라우드를 이전의 모든 호스팅 모델과 차별화하는 서비스형(aaS, as-a-service) 모델로의 변화입니다. 클라우드 서비스에 대한 모든 변화는 확장성, 가동 시간, 복원력 등 고객의 경험에 영향을 미칩니다. 경우에 따라 고객이 새로운 제공 모델로의 변경을 —요구하는 경우도— 있을 수 있습니다. 다른 경우에는 클라우드 기반 제공을 통해서만 지원할 수 있는 방식으로 특징, 기능 및 비용에 대한 기대치가 진화하고 있을 수 있습니다.

클라우드 전략에 고객을 참여시키기 시작하면 두 가지 관점, 즉 로드맵에 대한 기대감과 익숙한 것을 떠나지 않으려는 두 가지 관점을 모두 준비해야 합니다. 이러한 관점에 대응하려면 기술적 세부 사항을 잃거나 위험 신호 발생 없이 노력이 어디로 향할 것인지를 나타내는 명확하고 측정된 커뮤니케이션이 필요합니다. 이는 조직 내부의 고객 대면 팀을 참여시켜 진행 중인 노력, 비즈니스에서 수행하는 투자, 제품 및 제공에 대한 예상 결과를 이해하도록 보장하는 중요한 순간입니다. 이를 위해서는 고객 대면 팀이 참여하여 이러한 변경 사항을 서비스에 대한 고객의 신뢰를 강화할 수 있는 조건으로 변환해야 합니다.

클라우드 서비스를 사용하게 될 고객의 경우 시나리오가 좀 더 복잡해질 수 있습니다. 클라우드 서비스를 요구하는 고객 세그먼트가 있습니다. 이들은 SaaS가 효율성과 민첩성 측면에서 제공하는 이점을 이해하고 있습니다. 그러나 클라우드 또는 SaaS 옵션이 중요한 요소가 됨에 따라 고객은 클라우드 자체의 가치보다는 공급업체의 서비스를 차별화하는 기능 및 서비스 수준 계약에 대해 교육을 받아야 합니다.

하지만 모든 고객이 클라우드 서비스를 원하지는 않습니다. 특히, 호스팅되거나 관리되는 서비스 모델의 기존 고객은 현재 상태에 만족할 수 있으며, 특히 맞춤형 서비스 구성 요소 또는 비표준 환경 및 클라우드 제공과 일치하지 않는 액세스 모델이 있는 경우 더욱 그렇습니다. 클라우드 서비스로 전환하면 이점을 누리는 고객도 환경을 마이그레이션하는 데 필요한 제공 조건이 변경되거나 서비스가 중단되는 불편함을 느낄 수 있습니다.

고객을 안심시키려면 마케팅, 영업, 지원 및 고객 성공 팀 간의 조정과 일관된 커뮤니케이션이 필요합니다. 이상적인 환경에서는 고객이 워크로드가 마이그레이션되었다는 사실을 전혀 인식하지 못하고 변경 사항을 인식하지 못한 채 성능 향상을 경험하게 될 것입니다. 실제로 클라우드로 서비스를 마이그레이션하려면 업그레이드와 다운타임이 필요한 경우가 많으며, 서비스 조건 또는 사용 가능한 기능이 변경될 수 있습니다. 이러한 이벤트를 통해 고객을 안내하는 동시에 전체 전환 일정에 대한 조정을 유지하는 것은 복잡한 작업이며 변경의 이점을 이해하는 것 이상이 필요합니다. 따라서 변경 사항을 확인하고 고객의 비즈니스에 영향을 미칠 수 있는 마이그레이션 단계를 조정해야 합니다.


CMIC는 건설 엔터프라이즈 소프트웨어를 Oracle Cloud Infrastructure로 마이그레이션하고 배포 시간을 10배 단축합니다.

CMIC"다른 클라우드 제공업체에 비해 OCI가 제공하는 비용 이점 외에도, 이제는 민첩성이 향상되었습니다. OCI는 우리에게 새로운 수준의 기술 유연성을 제공했습니다. 최고의 건설 ERP 소프트웨어를 제공하는 데 지속적으로 집중할 수 있도록 Oracle Container Services 및 Oracle Autonomous Database와 같은 기술을 통해 미래로 나아갈 것입니다." — Vince Di Piazza, IT 및 클라우드 인프라 책임자, CMIC

동영상 보기


고객이 클라우드 전환에 따른 이점과 변화를 지원하고 나면 조직이 직면하는 마지막 단계는 실제로 고객의 워크로드를 새로운 환경으로 이동하는 것입니다. 이는 새로운 환경의 마이그레이션 및 인증 테스트를 위한 최적의 시간을 결정하는 데 어려움이 있습니다. 다운타임이 발생할 수 있다는 사실을 받아들이는 고객은 다운타임이 언제 발생해야 하는지에 대해 여전히 강한 의견을 가지고 있는 경우가 많습니다.

고객 선호도가 중요하겠지만, 다른 여러 가지 우려 사항도 균형 있게 다뤄야 합니다. 마이그레이션 계획에는 제품 또는 서비스의 기술적 속성, 모든 고객의 선호도 조정, 내부 리소스 제한, 기존 데이터 센터의 통합/제거 또는 더 이상 사용되지 않는 제품군 종료와 같은 비즈니스 목표 등 다양한 요인의 절충이 포함됩니다. 이러한 상충되는 우선 순위의 균형을 유지하려면 고객 대면 팀을 마이그레이션 계획 활동에 포함시키십시오. 이러한 팀은 시장 기대치를 대변하는 데 핵심적인 역할을 할 것입니다.

조직이 클라우드 제공 모델의 지속적인 기술 및 비즈니스 프로세스 변경뿐만 아니라 투자 및 마이그레이션 기간 모두에 대비해야 하는 것처럼 마이그레이션과 관련한 고객 참여 방식과 제품 및 고객 관계에서 새로운 현상 유지에도 대비해야 합니다.

당사의 GBU는 먼저 이러한 요구 사항에 대응하여 이러한 전환이 기술적, 운영적 및 제공 약속 측면에서 고객에게 어떤 영향을 미치는지 검토하고, 특별한 주의, 참여 및 상업적 관계에 대한 잠재적 변화가 필요한 항목을 격리했습니다. 고객 대면 팀을 준비하기 위한 노력은 제품, 운영, 전략 및 기타 팀 간의 협력을 포함하는 유사한 관점에서 구축되어 일반적인 클라우드 사용 능력을 제공하는 동시에 특정 제품과 고객 변화를 해결합니다.

이 노력은 단순히 고객을 참여시키기 위해 고객 대면 팀을 준비하는 것 이상이었습니다. 고객 참여에 맞춰 핵심적인 부서 간 리더십을 결집함으로써 기술적으로 크게 주도되었던 프로그램을 솔루션의 핵심 가치를 재검토하고, 제품을 차별화하며, 시장 내에서의 가치를 가장 잘 보존하고 성장시키는 방법을 계획하는 데 있어 보다 광범위한 이니셔티브로 확장할 수 있는 귀중한 기회도 창출되었습니다.

5장: 5대 과제

사전 준비

SaaS 애플리케이션 호스팅을 위한 인프라 설계

이 가이드에서는 수천 개의 인스턴스에서 호스팅되는 60개 이상의 GBU 애플리케이션을 마이그레이션하면서 얻은 교훈을 기반으로 모범 사례 지침을 제공했습니다. 다음은 애플리케이션을 클라우드로 마이그레이션하는 모든 조직에 적용할 수 있는 5가지 주요 과제를 정리한 것입니다.

  1. 마이그레이션 전 개발 노력 결정
    클라우드 릴리스를 위해 확립된 애플리케이션을 준비하려면 대규모 투자가 필요하며, 특히 클라우드 기본 상태로 제품을 전환하는 데 많은 투자가 필요할 수 있습니다. 클라우드 기본 애플리케이션 원칙에 대한 투자는 최종 상태를 충족하기 위해 많은 시간과 개발 리소스를 소모하면서 클라우드에서 얻을 수 있는 최고의 이점을 제공합니다. 제품을 클라우드 환경으로 전환하는 데 시간이 오래 걸릴수록 클라우드로의 전환에 따른 고유한 점진적 이점에 대한 액세스가 지연되고 일반적으로 레거시 환경과 관련된 위험에 대한 노출이 연장될 수 있습니다. 이와 동시에 모든 제품의 라이프사이클 단계와 고객 태세에 따라 혜택이 동일한 것은 아닙니다. 성공적인 전환을 위해서는 마이그레이션 전에 수행해야 할 개발 작업의 양을 완벽하게 파악하고 문서화하는 것이 중요합니다.

    GBU 애플리케이션 집합은 클라우드 성숙도 및 라이프사이클 단계의 모든 제품 등 다양합니다. 모든 애플리케이션을 클라우드로 마이그레이션해야 했지만, 클라우드 릴리스 전에 얼마나 많은 제품을 변경해야 하는지 고민했습니다. 조직은 올바른 균형을 찾기 위해 각 제품의 라이프사이클 단계, 성장 가능성 및 제품을 클라우드로 전환하는 데 필요한 노력을 평가해야 했습니다. GBU는 이러한 결합된 평가를 바탕으로 각 제품에 부여될 우선 순위와 비용 수준을 결정했습니다.
  2. 개발 조합 결정
    클라우드 투자 준비에 얼마나 많은 엔지니어링 대역폭을 제공해야 하는가와 시장의 수요에 대응하여 새로운 기능을 개발하는가 하는 것은 GBU가 균형을 맞추기 어려운 일이었습니다.

    GBU는 클라우드 전환의 우선 순위에 대한 조정이 부족하지 않았지만, 제품 팀은 고객 경험과 성능을 개선하는 클라우드 기능에 얼마나 많은 작업을 제공해야 하는지를 이해하느라 고심했지만, 고객이 요구하는 기능을 대체하지는 못했습니다. 클라우드 개발에는 새로운 기능에 대한 고객의 요구에 대응하는 조직의 능력에 방해가 될 수 있는 기본 운영 기능에 대한 투자가 필요합니다. 이러한 절충으로 인해 클라우드 준비 상태와 제품 향상 이니셔티브 간에 시간을 분배하는 방법을 찾기 어렵습니다.

    이러한 과제에 대응하기 위해 GBU는 각 경로에 필요한 상대적 개발 투자에 대한 통찰력을 제공하기 위해 1장에서 논의한 클라우드 성숙도 프레임워크에 의존했습니다. 그런 다음 각 잠재적 클라우드 전환 단계의 ROI를 조사하여 새로운 기능 개발로 예상되는 잠재적 수익 기여와 비교했습니다. 이를 통해 목표 비즈니스 결과에 대한 가시성을 유지하면서 올바른 작업 조합을 결정하는 데 사용할 수 있는 공통 평가 프레임워크를 제공했습니다.
    Altair는 Oracle Cloud Infrastructure에서 고성능 컴퓨팅을 선택하고 가격 대비 성능을 20% 향상시킵니다.

    Altair"모든 클라우드 벤더를 살펴본 결과 Oracle은 HPC에 매우 집중하고 있다는 것을 알게 되었습니다. 업계 최초의 베어 메탈 제품이며 짧은 지연 시간 네트워킹을 갖추고 있어 우리에게 매우 중요합니다." — Piush Patel, 전략 관계 담당 수석 부사장, Altair


  3. 플리트 이해
    회사에 단일 애플리케이션을 사용하든 대규모 포트폴리오를 사용하든 클라우드 마이그레이션 중에 추적하고 인벤토리를 구성해야 하는 여러 가지 요소가 있습니다. 변경해야 할 사항을 완전히 이해하려면 기존 애플리케이션 리포지토리 전체의 현재 인벤토리와 클라우드에서 활용될 예정인 항목을 완전히 이해해야 합니다. 이동할 애플리케이션이 많은 경우 기존 인벤토리가 존재하지 않거나 특정 애플리케이션의 상태에 대한 부분별 지식에 의존할 수 있습니다. 단일 고객 대면 애플리케이션을 보유한 기업도 전체 애플리케이션 스택의 인벤토리를 수집하여 클라우드로 전환할 때 어떤 측면을 변경해야 하는지 결정해야 합니다. 클라우드에서 어떤 요구 사항이 변경되고 설계가 어떤 모습이어야 하는지를 이해하는 것은 전환에 필요한 작업을 문서화하는 데 있어 매우 중요한 부분입니다.

    인스턴스의 특성(버전, 하드웨어/플랫폼 종속성, 사용자 지정, 고객 액세스 모델 등)에 따라 각 애플리케이션 인스턴스에 대해 다양한 유형과 작업량이 필요합니다. 또한, 애플리케이션 데이터는 여러 기록 시스템에 분산될 수 있습니다.

    Oracle GBU는 30개 이상의 인수를 통합하여 80개 데이터 센터와 12,000개 이상의 애플리케이션 인스턴스를 확장했습니다. 이러한 인스턴스와 관련된 중요 데이터는 매우 단편화되어 있어서 여러 구성 요소 제품 팀 간에 일관된 방식으로 관리되지 않을 수도 있습니다. 이 정보 없이는 마이그레이션 작업을 효과적으로 조직하고 계획할 수 없었습니다. 마이그레이션해야 할 대상을 명확히 파악하기 위해 GBU는 전용 데이터 수집 및 통합 작업을 시작해야 했습니다.

    "Oracle GBU 팀은 OCI로 마이그레이션하여 자본 비용을 80% 절감하고 인프라 비용을 64% 절감할 수 있었습니다." — Mike Prindle, VP, GBU 클라우드 아키텍처
    Oracle@Oracle


  4. 마이그레이션 작업의 우선 순위 지정 및 구성
    실제로 워크로드를 이동하려면 기존 VM의 이미지를 복사부터 새 인스턴스를 설치하고 데이터를 복제하는 등 여러 가지 경로가 필요할 수 있습니다. 하지만 이 모든 작업을 완료하려면 어느 정도의 기술 투자나 노동력이 필요합니다. 조직 플리트 내의 각 제품 환경이 증가하면 마이그레이션에 수반되는 노동력의 양과 유형이 압도적으로 커질 수 있습니다. 이를 완료하는 데 사용할 수 있는 리소스는 한정되어 있으며 일상적인 운영 관리 업무를 담당하기도 합니다.
    OceanX는 비즈니스 인텔리전스 시스템을 AWS(Amazon Web Services)에서 Oracle Cloud Infrastructure로 전환하고 성능을 3배 향상했습니다.

    OceanX"우리는 더 낮은 비용으로 고성능을 제공하고 확장할 수 있는 데이터 플랫폼이 필요했습니다. AWS에서 Oracle로 데이터 플랫폼을 마이그레이션한 것은 OceanX에서 가장 성공적인 마이그레이션 중 하나였으며, 상당한 성능 향상과 상당한 비용 절감 효과를 함께 제공하면서 전체 프로그램이 엄청난 성과를 거두었습니다. 이를 통해 궁극적으로 고객에게 보다 정확한 정보를 바탕으로 의사 결정을 내릴 수 있는 플랫폼을 신속하게 제공할 수 있습니다." — Vijay Manickam, 데이터 및 분석 담당 부사장, OceanX


    GBU 클라우드 전환에는 3,000개 이상의 개별 마이그레이션 프로젝트가 필요했습니다. 이러한 프로젝트는 원래 고객의 선호도(예: 통합된 고객 의견을 기반으로 마이그레이션 시간 우선 순위 지정) 또는 특정 환경의 마이그레이션 준비 상태에 따라 우선 순위가 지정되었습니다. 결국, 이러한 접근 방식은 마이그레이션 과정에서 점진적인 비즈니스 이점을 실현하는 데 도움이 되지 못했습니다. 공통 우선 순위 지정 또는 조정 프레임워크가 없었던 GBU는 일관성없는 마이그레이션 활동량을 발견했습니다. 이로 인해 리소스 경합이 격화되고 리소스 가용성이 낭비되는 상황에서 마이그레이션 작업을 완료해야 하는 팀에 부담이 가중되었습니다.

    이러한 과제를 해결하기 위해 GBU는 마이그레이션 전담 중앙 프로그램 관리 사무소와 경영진 감독 위원회를 만들어 목표 비즈니스 결과에 대한 마이그레이션 우선 순위를 정하고 중심화 기회를 파악합니다.
  5. 조직 변화 관리
    클라우드 전환과 관련된 변화에는 새로운 지식, 기술, 프로세스의 영역뿐만 아니라 다른 문화적 변화 영역이 필요합니다. 이러한 인적 자원 관련 과제를 관리하는 것은 클라우드 전환의 기술적 구성 요소보다 더 어려울 수 있습니다. 이를 해결하기 위해 Oracle GBU는 교육에 집중함으로써 기존 팀이 클라우드 팀으로 전환하도록 지원했습니다. 새로운 인재를 언제 데려올 것인가와 조직을 발전시킬 메커니즘을 언제 찾을 것인가에 대한 질문을 관리하려면 GBU가 주요 기능 영역과 제품 그룹을 대상으로 인력 평가를 수행한 다음 각 사용 사례에 대해 적절한 개선 이니셔티브를 매핑해야 했습니다. 회사에서 이동해야 할 애플리케이션이 여러 개 있는 경우 보안 및 일반 IaaS와 같이 모든 제품에 적용되는 기본 클라우드 지식을 생성할 수 있는 위치를 고려하십시오.

6장: 결과 및 시작하기

결과 축하

이 가이드는 60개 이상의 SaaS 기반 애플리케이션을 Oracle Cloud Infrastructure로 마이그레이션하는 데 축적된 오라클 GBU 팀의 지식을 기반으로 합니다. 이러한 애플리케이션은 8개 업종의 핵심 엔터프라이즈 기능과 전 세계 199,000명 이상의 고객을 지원합니다. 부지런하고 계획적이며 잘 실행된 마이그레이션은 상당한 이점을 가져왔습니다.

  • 80개의 데이터 센터를 11개로 통합
  • CapEx 80% 절감
  • 인프라 비용 64% 절감
  • 28개에서 10개로 소프트웨어 공급업체 감소
  • 소프트웨어 비용 42% 감소
  • 소프트웨어의 일일 릴리스로 이동
  • 프로비저닝 시간 98% 이상 단축
  • 계획된 다운타임 98% 이상 감소

이 ISV 가이드는 GBU 팀이 학습한 내용을 기반으로 했지만, Oracle Cloud Infrastructure로의 대규모 마이그레이션은 몇 가지 중 하나에 불과했습니다. 오라클은 모든 SaaS 애플리케이션의 매출과 고객 수를 고려할 때 전 세계에서 가장 큰 ISV 중 하나로 간주할 수 있으며 마이그레이션 프로세스에 대해 잘 알고 있습니다. 실제로 Oracle Fusion Cloud ERP, Oracle Fusion Cloud EPM, Oracle Fusion Cloud HCM, Oracle Advertising and CX 및 Oracle Fusion Cloud SCM을 비롯한 전체 제품 포트폴리오를 Oracle Cloud Infrastructure로 이동했습니다. 이러한 마이그레이션은 Oracle@Oracle이라고 하는 혁신 이니셔티브의 일부입니다. 수십 개의 데이터 센터에 분산된 수만 개의 애플리케이션이 포함된 다년간의 프로젝트였습니다.

이러한 노력의 결과로 얻은 몇 가지 이점은 다음과 같습니다.

  • 인프라 – 30%의 비용 절감 및 2배-10배 향상된 성능으로 전체 애플리케이션 포트폴리오에서 99.99%의 가용성 달성
  • 재무 – 장부를 마감하고 10일 이내에 수입을 보고할 수 있는 기능 확보
  • 인적 자원 – 인재 검토 주기 70% 단축
  • 공급망 – 공급망 계획 주기를 1주에서 48시간으로 단축하여 71% 향상
  • CX – 캠페인 리드 타임을 4주에서 5일로 단축하여 82% 향상
  • 지속 가능성 – FY19에 Oracle에서 수집한 폐기된 장비의 99.4% 재사용 또는 재활용

Oracle과의 파트너 관계

우리는 ISV가 주요 매출 성장 잠재력을 높이는 동시에 해결 가능한 시장을 확장할 수 있도록 지원하고 있습니다. 자세한 내용을 알아보려면 oraclecloud-isv_ww@oracle.com으로 이메일을 보내주십시오.

ISV가 오라클 클라우드를 선택하는 이유에 대해 자세히 알아보려면 다음 리소스를 참조하십시오.


Körber는 창고 관리 시스템을 오라클 클라우드 인프라스트럭쳐(OCI)로 통합하고 40% 더 빠르게 실행합니다.

Korber"다양한 의사 결정 지점을 평가했을 때 OCI는 시장 진출 전략 측면에서 우리가 하고자 하는 일에 매우 전략적이었습니다." — Rick Schrader, 북미 영업 및 제휴 담당 수석 부사장, Körberö

동영상 보기