클라우드 여정 살펴보기

애플리케이션 마이그레이션을 포함하는 모든 클라우드 혁신 프로세스는 복잡합니다. 하지만 이러한 복잡성에도 불구하고 클라우드로 전환하는 과정에서 달성해야 할 몇 가지 명확한 목표가 있습니다. 한 가지 중요한 목표는 대상 애플리케이션에서 얼마나 "클라우드를 대비"해야 하는지 결정하는 것입니다. 원하는 기간에 클라우드로 이동하기 위해서는 클라우드를 위해 애플리케이션이 얼마나 대비되어 있어야 할까요? 이 백서에서는 몇 가지 주요 목표를 보여주고 경험을 통해 얻은 모범 사례와 교훈을 자세히 설명합니다. 성공을 위해서는 마이그레이션 목표를 처음부터 명확하게 정의하고 달성 방법에 대해 최적의 결정을 내릴 수 있도록 해야 합니다. 마이그레이션 중에는 여러 가지 가능한 접근 방식을 만나게 됩니다. 개발자, 제공 팀, 경영진은 이러한 옵션을 평가하고 그 과정에서 중요한 결정을 내려야 합니다.

비즈니스 목표를 달성하는 방법을 결정할 때는 다음과 같은 기술 및 비즈니스 요소에 중점을 두는 것이 좋습니다.

확장성

클라우드 서비스는 기존의 관리형 인프라를 훨씬 뛰어넘는 방대한 컴퓨팅 성능을 제공하므로 비즈니스를 확장하고 시장 기회를 포착할 수 있습니다. ISV는 클라우드 기반 IaaS(Infrastructure as a Service) 및 PaaS(Platform as-a-Service)를 통해 최신 구성요소를 활용하여 확장 가능한 아키텍처를 구축하는 데 집중할 수 있습니다. 클라우드로 마이그레이션할 때의 또 다른 이점은 내부 팀이 IT 운영 관리 및 확장을 수행하지 않아도 되므로 성능 향상과 최적화에 집중할 수 있다는 점입니다.

현대화

툴세트, 서비스 및 아키텍처를 현대화하면 다양한 구성요소를 더 쉽게 통합할 수 있으므로 애플리케이션에서 클라우드에서 제공되는 툴 및 기술의 이점을 충분히 누릴 수 있습니다. 이러한 툴에는 애플리케이션 성능을 향상시켜주는 인프라 업그레이드, 자동 배포 파이프라인, 통합 머신 러닝 모델이 포함됩니다. 현대화는 경쟁력을 유지하기 위해 애플리케이션을 유연하게 조정해야 하는 빠르게 변화하는 시장에서 특히 중요합니다. 경우에 따라 최신 기술을 사용하여 서비스를 완전히 재구성하고 브랜드를 변경하여 비용을 절감하거나 서비스 옵션을 간소화할 수 있습니다. 이러한 변화는 구식 제품을 활성화하고 기존 라이선스 제품이 일반적인 기성 시장을 뒤흔들 수 있습니다. 다른 경우에는 새로운 방법으로 제품을 업데이트하여 브랜드 인지도와 고객 충성도를 유지하면서 서비스를 향상시킬 수 있습니다. 그렇다고 해서 항상 제품군을 완전히 개편할 필요는 없습니다.

클라우드로 이동은 전사적인 현대화 노력을 촉발합니다. 클라우드 액세스를 통해 팀은 이전에는 제공되지 않았던 서비스, 기술 및 전문 지식을 활용하여 새로운 목표를 달성하고 새로운 기능을 제공할 수 있습니다. 팀은 특정 고객 배포를 위한 맞춤형 코드를 작성하는 대신 새롭고 일반적인 제품 기능을 개발하는 데 집중할 수 있습니다. 서비스 제공, 제품 업데이트 및 고객 지원이 빨라지면 새로운 기능을 개발하는 데 리소스를 다시 집중할 수 있습니다. 이러한 방식으로 클라우드 마이그레이션은 제품 업그레이드 실행 방식부터 고객 서비스 품질까지 모든 것을 변화시키며 광범위한 현대화를 위한 길을 열어줍니다.

---

"2세대 클라우드로 전환하면서 Oracle은 강력한 DevSecOps 모델을 통해 서비스를 성공적으로 제공하고 고객의 비즈니스 혁신을 지원할 수 있게 되었습니다. 이제 매일 소프트웨어를 릴리스하고 프로비저닝 시간을 98% 이상 단축했습니다." — Karthic Murali, Senior Principal Product Strategy Manager, Oracle Global Business Units

---

표준화

IaaS와 PaaS를 표준화하면 오버헤드를 줄이고 팀의 유연성과 상호 호환성을 높일 수 있습니다. 조직이 확장됨에 따라 팀은 다양한 성숙도의 툴을 사용하게 됩니다. 이러한 툴세트를 클라우드 서비스에 통합하면 IT 계층을 관리하는 복잡성을 상당 부분 줄일 수 있습니다. 포트폴리오 전반에 걸쳐 매핑할 수 있는 작업에 대한 표준 운영 관행을 개발하고 사용할 수 있습니다. 또한 표준화를 통해 일상적인 작업을 더 쉽고 예측 가능하게 만들어 기본 활동에 필요한 노력을 줄일 수 있습니다. 이전에 여러 애플리케이션에서 호환되지 않는 다양한 프로세스를 관리하는 데 사용하던 리소스를 이제는 고객을 위한 차세대 제품 및 서비스 개발과 같은 보다 중요한 문제에 집중할 수 있습니다.

또한 표준화를 통해 보안, 위험 관리, 규정 준수 및 기타 운영 활동에 대한 글로벌 정책과 관행을 더 쉽게 구현할 수 있으며, 이를 통해 팀이 기존 제품과 새로운 제품 모두에 쉽게 적용할 수 있습니다. 실제로 공인된 규정 준수 인증과 같은 IaaS 플랫폼의 많은 내장 기능을 애플리케이션에 상속할 수 있습니다.

수익 최적화

수익 최적화는 크게 두 가지 방법으로 달성할 수 있습니다. 첫째, 가장 확실한 것은 비용을 절감하는 것입니다. 데이터 센터에서 벗어나 IaaS를 사용함으로써 재무 모델이 CapEx에서 OpEx로 전환될 뿐만 아니라 일반적으로 TCO를 크게 절감할 수 있습니다. 비용 절감 기회는 클라우드로 마이그레이션된 다양한 애플리케이션에서 사용되는 기술 스택을 간소화하는 것으로부터 비롯됩니다. 공통 툴세트를 사용하면 제도적 지식을 구축하는 데 도움이 되며 표준화되지 않은 툴에 대한 고비용 임시 교육이 필요하지 않습니다. 이러한 맥락에서 인프라를 코드로 취급하는 일반적인 툴세트는 자동화를 제공하여 시간과 인력 비용을 모두 절약할 수 있습니다. 마지막으로 보안과 같이 포트폴리오 전반에 걸쳐서 기본 영역에 대한 전문 지식을 갖춘 팀은 각 개별 제품 팀 내에 전문가를 생성할 필요가 없습니다.

또한 클라우드로 전환하면 일반적으로 애플리케이션이 클라우드 지원 또는 클라우드 네이티브가 되었을 때 제품 개발 일정이 단축되므로 출시 기간을 단축하여 수익을 최적화할 수 있습니다. 시장 출시가 빨라지면 수익 창출이 빨라집니다. 애플리케이션을 클라우드로 준비하면 몇 분 안에 전 세계에 어디에나 배치할 수 있습니다.

위에서 언급한 원칙은 표준화된 제품 및 서비스 아키텍처와 향상된 배치 속도 및 품질로 이어져야 합니다. 반복되는 패턴으로 확장성을 설계하면 수익 최적화, 가치 창출 시간 단축, 고객 서비스 품질 및 고객 만족도 향상에 리소스를 다시 집중할 수 있습니다.

---

WorkForce Software는 인력 관리 솔루션을 Oracle Cloud Infrastructure로 전환하여 성능을 30% 향상시켰습니다.

"처음부터 CapEx 지출을 30~35% 절약할 수 있는 재무 개선이 이뤄졌습니다. OCI의 뛰어난 성과로 인해 제품군의 ROI가 계속 개선되고 있습니다." —WorkForce Software, CEO, Mike Morini

자세히 알아보기

---

클라우드를 통한 가치 창출 경로

클라우드 컴퓨팅은 베어메탈 인스턴스부터 컨테이너형 환경, 완전히 통합된 서비스 스택에 이르기까지 다양한 IaaS 및 PaaS 리소스와 다양한 소프트웨어 배치 모델을 포함할 수 있습니다. 클라우드 컴퓨팅의 핵심에는 물리적 인프라 구성요소를 필수 IaaS 리소스로 대체하는 것이 포함됩니다.

그러나 대부분의 엔터프라이즈 애플리케이션은 원래부터 클라우드에서 실행되도록 설계된 것이 아닙니다. 많은 애플리케이션에서 클라우드 패턴에 적응하는 데 시간이 많이 걸리고 어려울 수 있습니다. 플랫폼 변환은 시간과 노력 모두 비용이 많이 들 수 있으므로 처음부터 클라우드 네이티브 원칙에 따라 애플리케이션을 설계하는 것이 더 쉬운 경우가 많습니다. 이를 염두에 두고 기업은 일반적으로 클라우드 마이그레이션을 계획할 때 세 가지 주요 시나리오 중 하나에 직면하게 됩니다.

• 기존 데이터 센터 운영 종료: 데이터 센터 운영은 비용이 많이 듭니다. 건물, 직원, 전기, 냉각, 유지보수 및 업그레이드는 일상 업무를 위한 책임 중 일부에 불과합니다. 데이터 센터에 대한 의존성을 줄이거나 없애기 위해 많은 기업들이 애플리케이션 포트폴리오를 검토하고 외부 호스팅으로 이동할 수 있는 애플리케이션을 찾고 있습니다. 목표는 공동 할당, 관리 호스팅 또는 온프레미스 데이터 센터 외부로 애플리케이션을 이동하여 자본 지출을 줄이거나 없애는 것입니다. 종종 기업들은 애플리케이션을 수정하지 않고 클라우드 기반 베어메탈 서버 또는 가상 머신으로 직접 마이그레이션하는 리프트 앤 시프트 방식을 사용합니다.
• 기술 스택 강화: 이 접근 방식의 경우 기업은 시간이 지남에 따라 애플리케이션을 소규모로 업그레이드합니다. 이러한 업그레이드에는 추가 투자가 필요하지만 장기적으로 더 큰 가치를 제공할 것으로 예상됩니다. 예를 들어 기업은 애플리케이션을 대대적으로 변경하는 대신 온프레미스 버전의 Oracle Database를 클라우드 기반의 Oracle Autonomous Database로 대체할 수 있습니다. 이 방법은 종종 이동 및 개선 전략이라고 불립니다.
• 클라우드 네이티브 기술 완전 채택: 클라우드 환경에서 원활하게 작동하도록 애플리케이션을 처음부터 재구성하는 것은 이전에 언급한 여러 시나리오 중 하나를 구현하면서 덜 발전된 애플리케이션을 그대로 유지하는 것보다 더 많은 이점을 제공할 수 있습니다. 클라우드 네이티브 애플리케이션은 본질적으로 분산되도록 설계되었습니다. 클라우드 네이티브 애플리케이션은 종종 12가지 원칙을 따르며, 이는 이러한 애플리케이션을 기본 아키텍처와 독립적으로 만드는 데 도움이 됩니다. 따라서 인프라에 장애가 발생하더라도 계속 실행되도록 보장합니다. 요약하자면, 이러한 방식이 대상 애플리케이션에 적합한 선택인지 평가하는 것이 중요합니다. 클라우드로의 이동이 기본 인프라와 긴밀하게 결합된 애플리케이션을 이동하는 것보다 확실히 더 쉽기 때문입니다.

클라우드 네이티브 애플리케이션에 대한 Oracle의 정의, 그 기원 및 모범 사례에 대한 자세한 내용은 이 eBook을 참조하십시오.

---

이 eBook에서는 Oracle Cloud Infrastructure로 이동하는 동안 엔터프라이즈 애플리케이션을 클라우드 네이티브 아키텍처로 전환하기 위한 다양한 접근 방식을 살펴봅니다. 아래 그림 1을 참조하십시오.

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

그림 1의 왼쪽은 변화가 가장 적고, 초기 투자가 가장 적으며 가치 제공 시간이 가장 짧은 옵션을 보여줍니다. 일반적으로 오른쪽으로 이동할수록 변화, 투자, 소요 시간의 수준이 증가하지만 잠재 가치도 증가합니다. 이 모델은 마이그레이션 단계에서 어떤 종류의 투자가 필요한지 추정하는 데 도움이 됩니다. 애플리케이션은 다양한 방식으로 구축되므로 시나리오가 완전히 분리된 것은 아니며 겹칠 수 있다는 점에 주의하십시오.

앞서 설명한 시나리오는 애플리케이션의 현재 성숙도 수준과 클라우드 전환 목표를 평가하는 데 참조 포인트가 될 수 있습니다. 현재 상태와 목표 상태의 차이를 통해 클라우드 전환에 필요한 기술적, 절차적 변경사항을 대략적으로 파악할 수 있습니다. 이상적으로는 모든 애플리케이션이 결국 클라우드 네이티브 제공 방식으로 전환되는 모델을 채택하는 것이 좋습니다. 하지만 제한된 시간과 리소스로 인해 대부분의 조직은 전체 포트폴리오를 클라우드 네이티브 모델로 한 번에 이동하기 어렵습니다. 플랫폼 변환과 같은 단순한 마이그레이션 노력도 기존 시스템 기능을 대체하는 데만 상당한 리소스와 투자가 필요할 수 있습니다.

클라우드 전환을 위해서는 이상적인 클라우드 성숙도 수준(위의 클라우드 호스팅에서 클라우드 네이티브 스펙트럼에 표시된 애플리케이션 수준)에 도달하는 것과 애플리케이션 및 관련 비즈니스 프로세스를 재설계하는 데 필요한 엔지니어링 투자 사이의 절충점을 평가해야 합니다. 이 단계에서 핵심은 각 애플리케이션의 현재 및 목표 성숙도 수준과 격차 해소에 필요한 개발 투자 추정치를 결정하는 데 있습니다.

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

 

클라우드를 위한 기술적 준비 상태 평가

특히 여러 SaaS 기반 애플리케이션을 제공하는 기업의 경우 대상 애플리케이션 또는 전체 애플리케이션 포트폴리오에 대한 명확한 기술적 이해가 필수적입니다. 이러한 지식은 마이그레이션에 필요한 요구사항과 종속성을 식별하는 데 매우 중요합니다. 이 단계에서는 애플리케이션에 필요한 기능과 애플리케이션이 종속성과 어떻게 연결되는지 파악하는 데 중점을 두어야 합니다. 이렇게 하면 마이그레이션 작업의 상대적 타이밍을 확인하고 주의가 필요한 주요 영역을 식별할 수 있습니다. 평가는 세 가지 중요한 측면을 포함해야 합니다.

1. 인프라 요구사항: 클라우드는 실행 중인 하드웨어 또는 운영체제로부터 소프트웨어를 분리합니다. 성숙도가 높은 애플리케이션은 환경과 거의 무관하며, 클라우드에서 쉽게 확장할 수 있는 CPU 또는 Kubernetes 클러스터와 같은 기본 인프라 리소스만 있으면 됩니다. 반면에 성숙도가 낮은 애플리케이션은 관리 인프라 또는 전용 시스템과 같은 특정 하드웨어, 구성요소 또는 환경에 의존합니다. 먼저 애플리케이션이 클라우드의 특정 인프라 구성요소 및 구성에 대해 갖는 강력한 의존성을 문서로 기술하고, 최종적으로 이러한 의존성을 제거해야 합니다. 기본 인프라와 밀접하게 연결되어 있고 귀사 또는 귀사의 고객이 만든 사용자정의 설정을 찾는 것이 일반적입니다.
2. 서비스 구성요소: 클라우드는 애플리케이션과 별도로 운영 및 제공되는 독립적인 서비스로서 지원 기능을 제공합니다. 성숙도가 높은 애플리케이션은 종속성이 최소화된 별개의 구성요소로 설계되어 목표 변경, 업그레이드, 가동 시간 극대화가 가능합니다. 성숙도가 낮은 애플리케이션은 긴밀하게 통합된 대규모 구성요소로 설계되어 있어 서로에 대한 의존도가 높으며 단일 엔터티로 관리해야 합니다. 이러한 서비스 관계는 각 애플리케이션에 대해 문서로 기술되어야 합니다.
3. 운영 준비 상태: 클라우드로 전환하면 기술 아키텍처뿐만 아니라 작업 프로세스, 기술 세트, 사용 가능한 툴 및 운영 모델도 변경됩니다. 성숙도가 높은 애플리케이션은 이미 클라우드에 적합한 프로세스, 표준 및 툴세트를 사용하여 클라우드 애플리케이션처럼 작동합니다. 성숙도가 낮은 애플리케이션에는 필요한 클라우드 지원 서비스가 부족하거나, 클라우드 작업에 적합하지 않은 기술을 가진 팀이 있거나, 마이그레이션 중에 중단되는 프로세스에 의존할 수 있습니다.

마이그레이션 전에 이러한 영역에서 애플리케이션의 성숙도를 평가하면 지연, 비용 증가, 목표 누락을 방지하면서 더 나은 계획을 세울 수 있습니다. 현재 프로덕션 환경, 지원 서비스 모음, 대상 클라우드 환경이 모두 프로세스 중에 진화하기 때문에 클라우드로의 마이그레이션은 매우 복잡합니다. 서비스와 애플리케이션 간의 연결 관계를 식별하면 처음부터 더 나은 계획을 세울 수 있으며 마이그레이션 중 불가피하게 발생하는 변경사항에 유연하게 대응하는 데 도움이 됩니다. 이 평가가 문서로 잘 기술되어 있으면 마이그레이션에 대한 명확한 실행 계획을 수립할 수 있습니다. 이를 통해 예상 마이그레이션 일정은 지속적으로 변경되는 로드맵에 맞춰 조정됩니다.

---

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

"최근 저희 비즈니스는 역대 가장 큰 폭의 성장을 경험하면서 서비스 용량을 크게 늘릴 필요가 있었습니다. 이에 따라, 여러 플랫폼을 살펴보았지만 그 중에서도 Oracle Cloud Infrastructure가 새로운 사용자 요구를 신속하게 확장하고 충족하는 데 도움이 되었습니다." — Eric S. Yuan, Zoom CEO

자세히 알아보기

---

재무 목표

다른 IT 이니셔티브와 마찬가지로 클라우드로 전환하려면 특히 원래 온프레미스 호스팅 모델용으로 설계된 애플리케이션의 경우 클라우드 이점을 완전히 실현하기 위한 일련의 투자가 필요합니다. 클라우드로 이동하도록 선택된 애플리케이션은 결국 클라우드 네이티브로 전환되거나 폐기될 것입니다. 하지만 초기 목표는 일반적으로 애플리케이션을 클라우드에 배포할 수 있는 클라우드 릴리스 상태로 전환하는 것입니다.

현재 상태에서 클라우드 릴리스 상태로 전환하기 위해서는 일련의 결정과 초기 투자가 필요합니다. 비용 대부분이 클라우드 인프라에서 발생하는 단순한 리프트 앤 시프트 전략에 따라 애플리케이션을 베어메탈 서버로 직접 이전할 계획이십니까? 아니면 마이그레이션 전에 클라우드 사용을 위해 애플리케이션을 준비하고 계십니까? 그런 경우 애플리케이션의 일부를 클라우드 기반 모델로 옮기기 위한 투자가 필요합니다. 예를 들어 데이터베이스를 온프레미스에서 DBaaS나 Oracle Autonomous Database로 옮기는 것입니다. 특정 고객 요구사항에 맞게 하드 코딩된 사용자정의 기능이 애플리케이션에 포함된 경우 플랫폼 구성요소가 제품화된 기능에 따라 API를 통해 캡슐화되고 제공되는 새로운 모델로 재설계해야 합니다. 클라우드에서 고도로 분산된 애플리케이션을 확장하려면 특정 하드웨어 또는 플랫폼에 대한 종속성을 제거해야 합니다. 클라우드로 이동과 관련된 재정적 목표를 계획하고 달성하기 위해서는 이러한 투자를 이해하는 것이 매우 중요합니다.

초기 투자에는 앞에서 설명한 마이그레이션 단계와 연관된 제품 변경에 필요한 개발 시간과 노력이 필요합니다. 하지만 추가 비용도 고려해야 합니다. 조직은 전환 과정에서 다음과 같은 광범위한 비용에 직면할 가능성이 높습니다.

• 개발 투자: 제품을 재설계하거나 데이터베이스 마이그레이션 및 애플리케이션 프로비저닝 지원을 위한 자동화와 같이 마이그레이션 속도를 높이는 툴을 생성하기 위해 개발 노력과 시간이 필요합니다.
• 마이그레이션 실행: 새로운 자산을 프로비저닝하고, 기존 환경 및 데이터를 마이그레이션하고, 오래된 시스템을 폐기하기 위한 인력이 필요합니다.
• 인프라 활용: IaaS 전환 중에 발생하는 구독 비용은 결국 안정화되지만 마이그레이션 기간 동안 인상됩니다.
• 고립된 인프라: 마이그레이션 중 오래된 데이터 센터와 CapEx 감가상각 비용은 완전히 상각될 때까지 계속됩니다.
• 인력 전환: 기존 팀을 훈련, 교육 또는 재구성하거나 필요한 클라우드 기술을 갖춘 신규 직원을 고용하는 데 비용이 발생합니다.
• 고객 전환: 새로운 기능 개발, 인센티브, 계약 재협상 또는 고객 이탈 처리를 포함하여 새로운 모델에서 지원할 수 없는 환경 기능 또는 서비스 조건의 변화와 관련된 비용이 발생합니다.

언급한 모든 비용은 정도의 차이는 있지만 IaaS로 전환하는 데 필수적인 구성요소입니다. 각 비용은 고유한 방식으로 전체 비용에 영향을 미칩니다. 예를 들어 개발 투자 및 마이그레이션 실행 비용은 고정된 리소스가 필요할 수 있지만 일반적으로 일회성 비용에 해당합니다. 새로운 인프라를 도입하면 기존 인프라 비용이 단계적으로 폐지될 때까지 일정 기간 동안 비용이 증가합니다. 교육 또는 마이그레이션 인센티브와 같은 일부 인력 및 고객 전환 비용은 일회성 비용입니다. 인력 확충이나 고객 계약 변경과 같은 다른 요인으로 인해 새로운 지속적인 비용이 발생할 수 있습니다.

조직이 클라우드 전환에 대한 기대치를 적절하게 준비하고 설정하기 위해서는 이러한 요소가 시간이 지남에 따라 어떻게 변화할지 이해하는 것이 중요합니다. 조직에서 클라우드의 극적인 이점만 생각하고 전환 위험에 대한 명확한 이해가 부족한 경우에는 특히 마이그레이션, 중복 인프라 및 전환 비용으로 인한 초기 비용 증가에 충격을 받을 수 있습니다. 올바른 기대치를 설정하고 전환 과정에서 이뤄지는 점진적인 발전을 추적하여 조직 내부 상황과 규율을 일관되게 유지하는 것이 중요합니다.

클라우드 마이그레이션 인벤토리

클라우드로 이동하려면 클라우드 마이그레이션 인벤토리가 필수적입니다. 클라우드 마이그레이션 인벤토리란 무엇인가요? 간단히 말해, 각 자산을 설명하는 중요한 데이터 요소와 함께 플리트의 모든 자산 목록을 의미합니다. 여기에는 이동하려는 애플리케이션 및 관련된 모든 종속성이 포함됩니다. 이 데이터를 수집하는 데 사용되는 방법은 중요하지 않으며, 데이터는 회사 내 여러 부서에서 제공되는 경우가 많기 때문에 여러 툴을 사용하는 것이 일반적입니다. 필요한 정보는 일반적으로 다양한 프로덕션, 판매, 운영 데이터베이스에 분산되어 있습니다. 예를 들어 구성 관리 데이터베이스는 물리적 서버 및 랙 위치까지 기술적 종속성과 자산 위치를 자세히 추적할 수 있습니다. 하지만 전환에 대해 언제 어떻게 알려야 하는지 결정하는 데 필요한 비즈니스 및 고객 고려사항은 포함되지 않습니다. 이러한 정보는 운영 및 지원 팀을 위해 설계된 저장소에 포함되는 경우가 많습니다. 또한 인수, 특수 사용 사례, 제품 사일로 등으로 인해 정보가 여러 저장소에 분산될 수 있습니다.

마이그레이션 인벤토리의 주요 목표는 클라우드로 전환을 관리하는 데 필요한 모든 요소를 통합된 뷰로 제공하는 것입니다. 예: 자산은 무엇입니까? 자산은 어디에 있습니까? 어떤 제품을 지원합니까? 어떤 역할을 수행합니까? 어떤 고객을 지원합니까?

처음부터 청사진은 상황에 따라 변화하는 살아 있는 문서라는 점을 깨닫는 것이 중요합니다. 특히 여러 개의 애플리케이션 또는 다양한 버전의 애플리케이션을 보유한 기업의 경우 시간 경과에 따라 발전할 수 있는 유연성이 필요합니다. 인벤토리는 새로운 문제가 발생하고 새로운 요구사항이 식별됨에 따라 진화합니다. 기본 클라우드 인프라 자체도 마이그레이션 중에 변경될 수 있으므로 인벤토리에 대한 추가 업데이트가 필요합니다. 마이그레이션 인벤토리는 가능한 한 많은 정보를 수집하여 초기 계획을 시작한 후 전환 중 새로운 요구사항이 드러남에 따라 더 많은 세부정보를 추가해야 합니다.

마이그레이션 인벤토리 관리는 세부 데이터의 필요성과 수집에 필요한 노력 사이의 균형을 찾아야 하는 팀 작업입니다. 또한 세부적인 기술 사양, 아키텍처 접근 방식, 고객 요구사항, 데이터 전송 경로 등 마이그레이션 시기와 속도에 영향을 미치는 종속성, 제약조건, 리소스를 식별하는 요소도 포함됩니다. 정보가 충분하지 않으면 인벤토리가 도움이 되지 않습니다. 정보가 너무 많으면 관리가 어렵고 빠르게 구식이 되어 더 이상 유용하지 않을 수 있습니다.

다음과 같은 마이그레이션 인벤토리 프레임워크를 클라우드 마이그레이션의 시작점으로 사용하는 것이 좋습니다.

마이그레이션 인벤토리에서 운영 인벤토리로 전환

지금까지는 마이그레이션 인벤토리에 중점을 두었지만 클라우드 전환에는 궁극적으로 두 가지 주요 과제가 있습니다. 첫째, 마이그레이션 활동을 신중하게 계획하고, 우선순위를 지정하고, 추적해야 합니다. 하지만 마이그레이션 자체로 인해 일일 운영 추적에 필요한 데이터 변경이 강제됩니다. 예를 들어 마이그레이션 후에는 물리적 서버 및 랙에 대한 세부정보가 더 이상 필요하지 않으며, 개발 인스턴스에 대한 정보조차도 덜 중요해집니다. 동시에, 조직이 셀프 서비스 모델을 채택함에 따라 전반적인 사용량 및 데이터 송신과 같은 측정항목이 더욱 중요해질 수 있습니다.

마이그레이션 인벤토리를 생성하면 클라우드 중심의 데이터 체계와 프로세스로의 전환이 시작됩니다. 인벤토리 생성과 애플리케이션 마이그레이션이라는 두 가지 과제는 별개의 프로젝트이지만 어느 하나만 단독으로 추진해서는 안됩니다. 마이그레이션 프로세스는 선행되어야 할 과제이며 조직이 자산에 대해 상세하고 통합된 뷰를 생성하는 첫번째 시간일 수 있습니다. 이는 마이그레이션 후 새로운 인벤토리 뷰에 대한 템플리트가 될 수 있는 중요한 전환 시점입니다. 앞에서 언급한 것처럼 마이그레이션 인벤토리는 유연성과 적응성이 뛰어나야 합니다. 마이그레이션 인벤토리를 적절하게 관리하면 마이그레이션 이후 인벤토리를 관리하는 데 유용한 툴이 될 수 있습니다.

파일럿 프로젝트를 통한 클라우드 전환

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

SaaS 기반 애플리케이션을 제공하는 ISV의 경우, 서비스를 호스팅하고 각 고객을 개별적으로 관리하기 위해서는 안전하고 확장 가능한 엔터프라이즈급 인프라가 필요합니다. 아래 그림 3에 표시된 참조 아키텍처는 모범 사례를 따르는 검증된 프레임워크를 제공하므로 Oracle Cloud Infrastructure에서 SaaS 애플리케이션을 호스팅할 수 있습니다.

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

동일한 코드 기반으로 모든 테넌트 애플리케이션 인스턴스를 구축하거나 각 테넌트에 사용자정의된 애플리케이션 버전을 제공할 수 있습니다. 이 패턴은 애플리케이션 환경을 완전히 분리해야 하는 SaaS 고객에게 이상적입니다.

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

위에서 언급한 참조 아키텍처에 대한 자세한 내용은 Oracle Architecture Center를 참조하십시오. 또한 단계별 가이드와 함께 4개 테넌트를 위해 아키텍처 배치를 지원하는 Terraform 기반 툴이 개발되었습니다. 마지막으로 보안, 규정 준수, 안정성 및 복원력, 성능 및 비용 최적화, 운영 효율성의 4가지 주요 비즈니스 목표를 다루는 Oracle Cloud Infrastructure 모범 사례 가이드를 참조하는 것이 좋습니다.

아키텍처 변경사항과 함께 클라우드에서 서비스 스택의 변경 방법도 고려해야 합니다. 온프레미스 아키텍처를 위해 개발된 레거시 환경에 배치된 모니터링, 네트워크 관리 또는 보안에 사용되는 핵심 툴세트는 클라우드를 위해 진화해야 합니다. 클라우드로 이동하면 이러한 툴로 해결할 수 있는 범위를 확대할 수 있습니다. 클라우드 기반 툴은 주로 엔드포인트를 모니터링하는 대신 전체 서비스 스택을 모니터링할 수 있습니다. 일부 클라우드 서비스 제공업체는 핵심 기능을 기반으로 클라우드 또는 하이브리드 기반 모니터링 툴을 제공합니다. Oracle Cloud Infrastructure의 경우 네이티브 모니터링, 태그 지정 및 감사 기능의 조합을 통해 전체 서비스 스택을 모니터링하고 지정된 기준을 벗어난 모든 비정상 문제를 자동으로 수정할 수 있는 기능을 제공합니다. 현재 온프레미스에서 타사 모니터링 툴을 사용하는 경우 이러한 공급업체는 하이브리드 또는 클라우드 기반 툴도 제공할 수 있습니다.

---

예를 들어 Cisco Tetration은 핵심 애플리케이션을 Oracle Cloud Infrastructure로 이동하여 성능이 60배 향상되었습니다.

"Oracle과의 파트너십은 환상적이었습니다. Cisco Tetration에서 일어나는 모든 마법 같은 효과들이 바로 이것 때문입니다." — Navindra Yadav, Founder, Cisco Tetration

---

파일럿 프로그램 준비

모든 엔지니어링 노력과 마찬가지로 소규모 파일럿 프로그램이나 프로토타입으로 시작하면 파일럿 팀과 조직이 무엇을 수행할 수 있고 어떻게 진행할 수 있는지 파악하여 성공 확률을 극대화할 수 있습니다. 파일럿 및 개념 증명 프로그램은 조직 전체의 대규모 변화에 대한 시간 및 재정적 압박 없이도 문제를 식별하고 해결하는 데 도움이 됩니다. 파일럿 프로그램은 느린 속도로 움직이고 새로운 운영 환경에 익숙해짐으로써 변화의 속도를 관리하는 데 도움이 됩니다.

핵심 개발자 그룹과 운영 직원들은 파일럿 프로그램을 통해 대상 클라우드 환경을 탐색하고, 아키텍처, 서비스, 운영 모델을 학습할 수 있습니다. 해당 팀은 자신감과 전문 지식, 경험은 물론 실용 지식을 얻고, 유용한 툴을 개발하고, 모범 사례를 작성할 수 있습니다. 또한 파일럿 기간 동안 클라우드 기반 환경에서 다른 팀과 협력하기 위한 새로운 규칙을 개발하고 지식을 쌓을 수 있습니다. 클라우드 마이그레이션을 위해서는 애플리케이션 팀이 직접적인 리소스 관리자에서 다른 팀이 제공하는 서비스의 소비자로 변화해야 합니다. 애플리케이션 팀은 파일럿을 통해 이러한 서비스 경계의 변화 방식을 이해하고, 자신이 사용할 서비스를 제공하는 운영 팀과의 관계를 구축하며, 요구사항을 운영 팀에 효과적으로 전달하는 방법을 배울 수 있습니다.

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

• 파일럿을 통해 기술이 항상 동일한 환경에서 실행되어 온 경우 새로운 환경에서 기술이 작동할 수 있는지 검증 또는 테스트할 수 있습니다. 이는 팀이 마이그레이션 준비 상태를 파악하고 필요한 변경사항을 식별하는 데 도움이 됩니다.
• 또한 애플리케이션과 데이터베이스가 대상 환경의 서비스와 통합할 준비가 되었는지 확인할 수 있는 기회를 제공합니다. 이를 통해 팀은 어떤 변경사항이 필요한지, 마이그레이션 수행을 위해 애플리케이션과 대상 서비스 환경이 언제 준비될 수 있는지 알 수 있습니다.
• 파일럿은 대상 환경에서 기반을 마련하여 나머지 포트폴리오를 새로운 서비스 및 새로운 환경으로 이동하기 위한 시작점 역할을 수행합니다. 이를 통해 팀은 포트폴리오에 대한 전략적 목표를 설정할 수 있습니다.

---

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

"앱과 데이터베이스 계층 모두에서 Oracle Cloud의 다양성과 유연성 덕분에 이전 클라우드 솔루션에 비해 인프라 비용을 약 50%의 비용을 절감할 수 있었습니다." — Jeff Demenkow, Vice President, Manhattan Associates

---

파일럿 프로그램 관리

파일럿은 기술 및 운영 팀은 물론 경영진과 관리 팀도 과정을 통해 배울 수 있는 기회입니다. 경영진과 관리 팀은 파일럿 팀과 긴밀히 소통하여 조직의 장벽을 없애고, 성공, 실패, 모범 사례, 학습한 교훈, 식별된 표준 패턴 또는 안티 패턴과 같은 파일럿 프로젝트로부터 얻은 교훈을 극대화할 수 있도록 해야 합니다. 이러한 귀중한 정보는 포착 후 조직 내 다른 팀과 공유함으로써 향후 클라우드 프로젝트를 개선하고 효율화하는 데 도움이 됩니다. 관리 팀은 파일럿을 통해 계획을 구축하는 데 사용된 초기 가정을 테스트하고 불확실성을 해결할 수 있습니다. 조직마다 사용되는 가정은 다르지만 파일럿은 마이그레이션 중에 흔히 발생하는 주요 문제를 드러내는 경우가 많습니다.

• 학습: 조직은 파일럿을 통해 기존 기술을 테스트하여 기술 마이그레이션 작업을 수행하기 위해 얼마나 준비되었는지 파악할 수 있습니다. 관리 팀은 파일럿을 통해 기술 역량을 평가하고, 학습해야 할 가장 중요한 툴과 기술을 파악하고, 직원을 신속하게 교육하거나 새로운 인재를 채용하는 방법을 계획할 수 있습니다.
• 협업: 파일럿은 개발, 운영, 지원 팀이 새로운 방식으로 어떻게 협업해야 하는지 보여줍니다. 관리 팀은 파일럿 기간 동안 이러한 팀들이 서로 협력하여 새로운 요구사항을 발견하고 새로운 환경에서 운영하는 방법에 대한 명확한 이해를 구축하도록 해야 합니다.
• 변화 욕구: 파일럿은 대규모 마이그레이션에 영향을 미칠 수 있는 문화적 장애 요소를 발견하는 데 도움을 줍니다. 파일럿 중 문제가 있는 그룹은 실제 마이그레이션 중에도 동일한 문제에 직면할 가능성이 높습니다. 관리 팀은 파일럿을 통해 특정 조직의 현실을 고려해서 문제를 식별하고, 교육을 제공하고, 계획을 조정할 수 있습니다.

원활한 마이그레이션은 강력한 기반을 바탕으로 시작됩니다. 마이그레이션의 첫 단계에서는 필수 서비스와 플랫폼 개발로 시작되며, 마이그레이션 진행에 따라 점차적으로 범위가 확장됩니다. 결국 이러한 핵심 기능은 전체 마이그레이션 포트폴리오를 지원할 수 있도록 확장되어야 합니다. 이러한 이유로 초기 클라우드 릴리스가 성공적이어야 할 뿐만 아니라 이후 릴리스 및 업그레이드를 위한 기반을 마련해야 합니다.

조직 변화에 적응

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

조직의 제공 모델과 고객 관계의 변화로 인해 새로운 기술, 지식, 비즈니스 프로세스 및 사고방식이 필요할 수 있습니다. 이러한 변화는 조직 전체에 영향을 미칠 수 있습니다. 이러한 이유로 문화적 변화는 클라우드로 전환하는 데 있어서 가장 어려운 부분으로 간주되는 경우가 많습니다.

단순히 이러한 변화 규모만 보면 클라우드 전환을 위해 모든 것을 대규모로 재구성하고 클라우드 경험과 전문 지식이 있는 인력으로 교체해야 할 것처럼 보일 수 있습니다. 클라우드 기술을 갖춘 직원을 고용하고 내부 역할을 조정하는 것도 클라우드 전환의 중요한 구성요소이지만, 지금까지 조직의 성공을 이끈 기존 프로세스, 역동성 및 주요 기여자를 유지하는 것도 매우 중요합니다. 진행 중인 비즈니스에 방해가 되거나 고객 경험에 부정적인 영향을 미치지 않도록 조직 변화 속도를 신중하게 관리해야 합니다. 이를 위해서는 기존 직원들이 기술을 성장시키고 새로운 운영 모델에 적응할 수 있도록 구조적 변화를 조정해야 합니다.

오래된 기존 소프트웨어 비즈니스에서 클라우드 제공 모델로 전환하기 위해서는 여러 핵심 비즈니스 영역에 걸쳐서 가정, 기술 노하우, 표준 운영 프로세스를 대폭 전환해야 합니다. 필요한 변화의 양이 압도적으로 보일 수 있지만 저희의 경험에 따르면 일반적으로 완전히 새로운 클라우드 전문가 그룹을 영입하는 것보다 기존 팀을 유지하고 투자하는 것이 더 낫습니다. 이와 비슷한 전환을 계획하는 조직은 각 팀이 자체 마이그레이션 인벤토리와 서비스 스택 로드맵을 작성할 수 있도록 GBU 조직이 탈중앙화된 상향식으로 변경 요구사항에 대한 평가를 어떻게 시작했고, 해당 관심 영역 내에서 필요한 단계를 어떻게 식별했는지 살펴봐야 합니다. 이러한 접근 방식을 통해 팀은 필요한 요소에 대한 대략적인 가정을 피하면서 실질적인 변화 동력에 맞게 프로그램을 조정할 수 있었습니다.

---

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

"오늘날 세계에서 화상 회의가 필수적인 요소가 되면서 저희 사용자 수가 크게 증가했습니다. 이러한 기하급수적인 성장을 돕기 위해 여러 플랫폼을 살펴봤으며, 강력한 보안과 뛰어난 가격 대비 성능비, 성장하는 사용자 기반의 요구를 충족할 수 있도록 세계 최고 수준의 지원을 제공하는 Oracle의 Gen 2 Cloud 인프라를 선택했습니다." — Vik Verma, CEO, 8x8

동영상 보기

---

비즈니스 영향

클라우드로의 성공적인 전환과 조직 전체의 변화는 상호 의존적 관계에 있습니다. 전반적인 호스팅 또는 온프레미스 포트폴리오에서 클라우드 기반 비즈니스로 이동하기 위해서는 조직이 고객과 협력하는 방식에 큰 변화가 필요합니다. 그러나 기존의 비즈니스 관행과 가정이 변화하는 정도는 클라우드 전환 과정에서 수행되는 제품 변경의 범위에 따라 크게 좌우될 것입니다.

변화가 최소화된 시나리오에서도 IaaS로 전환할 때는 비즈니스 프로세스에 변화가 발생합니다. GBU는 전환 과정에서 변화를 위한 두 가지 주요 기회를 확인했습니다.

1. 물리적 인프라 관리로 인한 막대한 CapEx 지출 필요성을 단기 변동과 장기적인 기대치를 고려한 OpEx 기반의 예측 모델로 대체합니다.
2. 보안 및 규정 준수 팀을 혁신하여 기존 책임을 벗어나 서비스 구성요소 제공에 집중할 수 있도록 지원합니다.

애플리케이션의 기술적 변화와 함께 이러한 변화에 대응하는 조직은 클라우드 마이그레이션의 잠재력을 최대한 실현할 수 있는 유리한 위치에 서게 됩니다.

고객 연계

'축소 포장된' 제품을 제공하거나 호스팅된 제품에서 실제 클라우드 서비스로 전환하는 것은 고객과 함께 진행하는 여정입니다. 실제로 이러한 서비스형 모델로의 변화는 클라우드를 이전의 모든 호스팅 방식과 차별화하는 점입니다. 확장성, 가동 시간 또는 복원력에 관한 클라우드 서비스의 모든 변화는 고객 경험에 영향을 미칩니다. 일부 경우에는 고객이 새로운 제공 모델로의 변화를 요청하거나 주장할 수도 있습니다. 다른 경우에는 클라우드 기반 제공을 통해서만 지원될 수 있는 방식으로 특성, 기능 및 비용에 대한 기대치가 진화할 수 있습니다.

클라우드 전략에 대한 고객 참여를 시작할 때 새로운 로드맵을 환영하는 고객과 기존의 친숙한 환경을 고수하길 원하는 고객의 엇갈린 반응에 대비해야 합니다. 두 가지 반응에 모두 대응하기 위해서는 너무 세부적인 기술적 문제나 장애 요소를 강조하지 않으면서도 나아갈 방향을 확실하게 제시하는 명확하고 침착한 소통이 필요합니다. 지금이 바로 조직의 현재 노력, 비즈니스 투자, 그리고 제품과 서비스의 기대 결과를 이해할 수 있도록 조직 내에서 고객 대면 팀을 참여시키기 좋은 시기입니다. 이렇게 하면 고객 대면 팀이 서비스에 대한 고객 신뢰를 강화하는 방식으로 변화를 해석하는 데 도움이 될 수 있습니다.

클라우드 서비스를 사용하는 고객의 경우 시나리오가 조금 더 복잡해질 수 있습니다. 일부 고객 세그먼트는 클라우드 서비스를 요구하면서 효율성과 유연성 측면에서 클라우드 SaaS가 제공하는 이점을 이해합니다. 하지만 클라우드 및 SaaS 옵션이 표준화됨에 따라 이제는 클라우드 자체의 일반적인 이점보다 공급업체 서비스를 차별화하는 기능 및 서비스 수준 계약과 같은 요소를 고객들에게 알려야 합니다.

하지만 모든 고객이 클라우드 서비스로 전환을 열망하는 것은 아닙니다. 호스팅 또는 관리형 서비스 모델의 기존 고객은 특히 클라우드 제공과 일치하지 않는 맞춤형 서비스 구성요소 또는 비표준 환경이 제공되지 않을 경우 현재 상태에 만족하지 못할 수 있습니다. 클라우드 서비스로 전환의 이점을 알고 있는 고객조차도 제공 방식의 변화 또는 환경을 마이그레이션할 때 필요한 서비스 중단으로 인해 불만을 가질 수 있습니다.

고객을 안심시키려면 마케팅, 영업, 지원 및 고객 성공 팀 간의 조율과 일관된 커뮤니케이션이 필요합니다. 이상적으로는 고객이 워크로드가 마이그레이션되었다는 사실을 전혀 눈치채지 못하다가 어느 날 성능 개선이 이루어진 것을 알게 되는 것이 가장 좋습니다. 그러나 현실적으로는 서비스를 클라우드로 마이그레이션하기 위해 업그레이드와 다운타임 기간, 때로는 서비스 약관이나 사용 가능한 기능의 변경이 수반되는 경우가 많습니다. 전반적인 전환 일정을 파악하면서 고객이 이러한 단계를 진행하도록 안내하는 것은 어려운 일이며, 변화로 인한 이점을 설명하는 것 이상의 노력이 필요합니다. 발생할 변경사항에 대한 고객 동의를 얻고 고객 비즈니스에 영향을 미칠 수 있는 마이그레이션 단계를 조정해야 합니다.

---

CMIC는 기업용 건설 소프트웨어를 Oracle Cloud Infrastructure로 마이그레이션하여 10배 빠른 배포 성능을 달성했습니다.

"OCI을 사용하면 다른 클라우드 제공업체의 솔루션보다 비용을 절감할 수 있을 뿐만 아니라 더 많은 민첩성을 누릴 수 있습니다. OCI에 힘입어 새로운 수준의 기술적 유연성을 얻을 수 있었습니다. Oracle Container Services 및 Oracle Autonomous Database와 같은 기술을 통해 미래를 준비함으로써 계속해서 최고의 건설 ERP 소프트웨어를 제공하는 데 집중할 수 있게 되었습니다." — Vince Di Piazza, Director of IT and Cloud Infrastructure, CMIC

동영상 보기

---

고객이 클라우드 전환에 따른 이점과 변화에 동의한 후 귀하의 조직이 수행해야 하는 마지막 단계는 고객 워크로드를 실제로 새로운 환경으로 이동하는 것입니다. 여기에는 마이그레이션에 가장 적합한 시기 결정과 새로운 환경의 검증을 위한 테스트 수행 과제가 포함됩니다. 고객이 일정 기간의 다운타임 발생을 이해하더라도 해당 다운타임이 발생하는 시기에 대해서는 고객의 요구가 여전히 높을 수 있습니다.

고객의 선호도를 고려하는 것도 중요하지만 함께 고려해야 할 요소가 산적해 있습니다. 마이그레이션을 계획하려면 제품 또는 서비스의 기술적 특성, 모든 고객의 선호도 조정, 내부 리소스 제한사항, 기존 레거시 데이터 센터의 통합/폐쇄 또는 오래된 제품 라인의 종료와 같은 비즈니스 목표 달성 등 여러 요소의 균형을 맞춰야 합니다. 이러한 상충되는 우선순위를 균형적으로 조정하기 위해서는 고객 대면 팀을 마이그레이션 계획 활동에 포함하는 것이 중요하며, 이는 고객 대면 팀이 시장 기대치를 대변하기 때문입니다.

조직이 클라우드 제공 모델의 지속적인 기술 및 비즈니스 프로세스 변화와 함께 투자 및 마이그레이션 프로세스 자체에 대비해야 하는 것처럼, 마이그레이션 중에 고객을 참여시키고 마이그레이션 후 고객과의 새로운 관계에 적응하는 방법에 대해서도 준비해야 합니다.

Oracle GBU는 기술적, 운영적 측면과 전달 약속에 초점을 두고 클라우드 전환이 고객에 어떤 영향을 미칠지 평가하는 것을 시작으로 이러한 요구에 대응했으며, 고객과의 상업적 관계에 대한 특별한 관심, 더 깊은 참여, 잠재적 변화가 필요한 분야가 무엇인지 파악했습니다. 고객 대면 팀을 준비하기 위한 노력에는 제품, 운영, 전략, 기타 팀의 협업이 포함된 비슷한 접근 방식이 사용되었으며, 이를 통해 일반적인 클라우드 지식을 제공하는 동시에 특정 제품 및 고객 관련 변화를 해결하는 데 도움이 되었습니다.

목표는 단순히 고객 대면 팀이 고객 참여를 이끌도록 준비하는 것만이 아니었습니다. 고객 대면 팀을 통해 다양한 기능의 주요 리더들을 한 곳에 모아 고객 참여 방식을 조율하고자 했습니다. 이러한 협업을 통해 이전에는 기술적 측면에 중점을 두었던 프로그램을 솔루션의 핵심 가치를 재평가하고, 시장에서 제품의 차별화 요소를 명확히 하고, 앞으로 그 가치를 유지하고 높일 수 있는 방법을 계획하는 광범위한 이니셔티브로 확장할 수 있는 귀중한 기회를 얻을 수 있었습니다.

사전 준비

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

이 플레이북에서는 수천 개의 인스턴스에서 호스팅된 60개 이상의 여러 GBU 애플리케이션을 마이그레이션한 경험을 바탕으로 모범 사례 조언을 제공했습니다. 아래에서는 마이그레이션 과정에서 직면한 5가지 주요 과제를 요약해서 보여줍니다. 이러한 과제는 애플리케이션을 클라우드로 마이그레이션하는 모든 조직과 관련이 있습니다.

1. 사전 마이그레이션 개발 노력 결정
   클라우드 릴리스를 위해 기존 애플리케이션을 준비하려면 특히 제품을 클라우드 네이티브 상태로 전환하기 위해 상당한 투자가 필요할 수 있습니다. 클라우드 네이티브 애플리케이션 원칙에 투자하면 클라우드에서 가장 큰 이점을 얻을 수 있지만 이러한 최종 상태에 도달하기 위해 상당한 시간과 개발 리소스를 소비해야 하는 과제가 따릅니다. 클라우드를 위해 제품을 준비하는 데 시간이 오래 걸릴수록 클라우드 이전에 따른 고유하고 점진적인 이점을 얻는 시간이 지연되고 일반적으로 레거시 환경과 관련된 위험에 노출되는 시간이 길어질 수 있습니다. 동시에, 라이프사이클 단계와 고객 상황에 따라 모든 제품이 동등한 이점을 얻는 것은 아닙니다. 성공적인 전환을 위해서는 마이그레이션 전에 필요한 개발 작업을 완전히 이해하고 문서화하는 것이 중요합니다.
   
   GBU 애플리케이션 플리트는 클라우드 성숙도와 라이프사이클 단계의 모든 수준에 있는 제품을 포함하여 다양합니다. 모든 애플리케이션을 클라우드로 마이그레이션해야 하지만 클라우드 릴리스 전 얼마나 많은 제품 변경을 거쳐야 하는지 결정하는 것이 과제였습니다. 이 조직은 올바른 균형을 찾기 위해 각 제품의 라이프사이클 단계, 성장 잠재력, 클라우드 마이그레이션에 필요한 노력을 평가해야 했습니다. 이러한 종합적 평가를 바탕으로 GBU는 각 제품에 할당할 우선순위와 비용 수준을 결정했습니다.
2. 균형적인 개발 노력 결정
   GBU는 클라우드 투자 준비에 사용할 엔지니어링 수준과 시장 수요에 맞는 새로운 기능 개발 사이에서 균형을 잡는 것이 어려운 과제였습니다.
   
   GBU는 클라우드 전환의 우선순위를 적절하게 조정할 수 있었지만 제품 팀은 클라우드 기능에 투자하는 데 얼마나 많은 노력을 기울여야 할지 결정하는 데 어려움을 겪었습니다. 이러한 기능은 성능과 고객 경험을 개선하지만 고객이 요구하는 기능을 대체하지는 못했습니다. 클라우드 개발에 투자하려면 운영 기능 개선에 집중해야 하므로 새로운 기능에 대한 고객 요구에 대응할 수 있는 조직 역량이 떨어질 수 있습니다. 이러한 장단점이 있어서 클라우드를 준비하는 것과 제품 개선 이니셔티브 사이의 시간적 균형을 맞추기 어렵습니다.
   
   이 문제를 해결하기 위해 GBU는 제1장에서 언급한 클라우드 성숙도 프레임워크를 사용하여 각 전환 경로에 필요한 상대적인 개발 투자의 양을 평가했습니다. 그런 후 클라우드 전환 단계별 ROI를 조사하고 이를 새로운 기능 개발로 얻을 수 있는 잠재적 예상 수익과 비교했습니다. 그 결과 올바른 통합 노력 수준을 결정하는 데 사용할 수 있는 일반적인 평가 프레임워크를 확보함으로써 대상 비즈니스 목표를 가시적으로 드러낼 수 있었습니다.

   ---

   Altair는 Oracle Cloud Infrastructure 기반의 고성능 컴퓨팅을 선택하여 가격 대비 성능을 20% 향상시킬 수 있었습니다.

   "모든 클라우드 공급업체를 비교해본 결과 Oracle이 HPC에 집중하고 있는 것을 확인할 수 있었습니다. 업계 최초로 생각되는 Oracle의 베어메탈 서버와 속도가 빠르고 지연 시간이 짧은 네트워킹은 특히 우리 회사의 요구사항에 매우 중요했습니다." — Piush Patel, Senior VP of Strategic Relations, Altair

   ---

3. 플리트 이해
   회사에서 단일 애플리케이션을 사용하거나 대규모 포트폴리오를 사용하거나 클라우드 마이그레이션 중에는 많은 요소를 추적하고 관리해야 할 필요가 있습니다. 변경이 필요한 항목을 완전히 이해하기 위해서는 기존 애플리케이션 저장소의 현재 인벤토리와 클라우드에서 사용할 항목을 명확하게 이해해야 합니다. 이동할 애플리케이션이 많은 경우 기존 인벤토리가 없거나 특정 애플리케이션 상태와 관련해서 문서화되지 않은 지식에 의존해야 할 수 있습니다. 회사에 고객 대면 애플리케이션이 하나만 있더라도 전체 애플리케이션 스택을 평가하여 클라우드로 전환 시 변경이 필요한 부분을 결정해야 합니다. 전환에 필요한 작업을 문서화하기 위해서는 클라우드에서 어떤 요구사항이 변경될지 그리고 어떤 설계가 필요한지 이해하는 것이 필수적입니다.
   
   인스턴스 특성(버전, 하드웨어/플랫폼 종속성, 사용자정의, 고객 액세스 모델 등)에 따라 애플리케이션 인스턴스마다 다양한 유형과 작업량이 필요합니다. 또한 애플리케이션 데이터가 여러 기록 시스템에 분산되어 있을 수 있습니다.
   
   Oracle GBU는 30개 이상의 인수 통합으로 구성되며, 80개의 데이터 센터와 12,000개 이상의 애플리케이션 인스턴스에 걸친 대규모 애플리케이션 플리트를 갖추고 있습니다. 이러한 인스턴스와 관련된 핵심 데이터는 매우 단편화되었으며 다양한 구성요소 제품 팀에서 일관된 방식으로 관리되지 않았습니다. 이러한 정보가 없었다면 GBU가 마이그레이션 작업을 효과적으로 계획하고 조직할 수 없었을 것입니다. 마이그레이션이 필요한 대상을 명확하게 파악하기 위해 GBU는 데이터를 수집하고 통합하는 집중 작업을 시작해야 했습니다.

   ---

   "Oracle GBU 팀은 OCI로 마이그레이션하여 자본 비용을 80% 절감하고 인프라 비용을 64% 절감하는 성과를 거두었습니다." — Mike Prindle, VP, GBU Cloud Architecture
   

   ---

4. 마이그레이션 노력의 우선순위 지정 및 조직화
   워크로드를 실제로 이동하려면 기존 VM 이미지를 복사하거나 새 인스턴스를 설치하고 데이터를 복제하는 등 다양한 방법이 필요합니다. 각 방법을 실행하려면 일정 수준의 기술 투자 또는 인력 투입이 필요합니다. 조직 플리트에서 각 제품 환경에 적용할 경우 마이그레이션 프로세스에 관련된 작업의 다양성과 규모로 인해 상당한 리소스가 필요할 수 있습니다. 또한 마이그레이션을 완료하는 데 사용할 수 있는 리소스가 유한하고 일상 작업을 관리하는 데 사용되는 경우가 많습니다.

   ---

   OceanX는 비즈니스 인텔리전스 시스템을 Amazon Web Services(AWS)에서 Oracle Cloud Infrastructure로 이동하여 3배 더 나은 성능을 달성했습니다.

   "저희는 낮은 비용으로 높은 성능을 제공하고 확장할 수 있는 데이터 플랫폼이 필요했습니다. 데이터 플랫폼을 AWS에서 Oracle로 마이그레이션한 것은 OceanX에서 가장 성공한 프로젝트 중 하나였습니다. 마이그레이션을 통해 훨씬 더 나은 성능과 더 낮은 비용으로 전체 프로그램에서 큰 성과를 낼 수 있었습니다. 그 결과 더 나은 정보에 입각해서 더 빠르게 의사 결정을 내릴 수 있는 플랫폼을 고객들에게 제공할 수 있었습니다." — Vijay Manickam, Vice President of Data and Analytics, OceanX

   ---

   GBU 클라우드 전환에는 3,000개 이상의 개별 마이그레이션 프로젝트가 필요했습니다. 처음에는 고객 선호도(예: 통합 고객 피드백 기반의 마이그레이션 시간 예약) 또는 특정 환경의 마이그레이션 준비 상태에 따라 프로젝트의 우선순위가 결정되었습니다. 그러나 이러한 접근 방식은 마이그레이션 과정에서 꾸준한 비즈니스 이점을 제공하지 못했습니다. 공통 우선순위 지정 또는 조정 프레임워크가 없어서 GBU에서 마이그레이션 작업 볼륨이 고르지 못했습니다. 그 결과 마이그레이션을 담당하는 팀들에서 리소스 경합이 높은 시기와 리소스 가용성이 낭비되는 시기가 번갈아 발생하는 부담이 가중되었습니다.
   
   이러한 과제를 해결하기 위해 GBU는 마이그레이션을 전담하는 중앙 프로그램 관리 사무소와 임원 감독 위원회를 설치했습니다. 이 위원회는 비즈니스 목표에 따라 마이그레이션 우선순위를 정하고 필요에 따라 조정 기회를 식별했습니다.
5. 조직 변화 관리
   클라우드 전환에 포함된 변화를 위해서는 새로운 지식, 기술, 프로세스는 물론 기업 문화의 변화에 대한 필요성도 수반됩니다. 이러한 인적 자원 과제를 관리하는 것은 클라우드 전환의 기술적 구성요소를 처리하는 것보다 더 어려운 경우가 많습니다. 이 문제를 해결하기 위해 Oracle GBU는 기존 팀이 클라우드 팀으로 전환할 수 있도록 지원하는 교육에 집중했습니다. 새로운 인재를 채용할 때와 조직 발전을 위한 메커니즘을 추구해야 할 때를 신중하게 고려해야 했습니다. 이를 위해 GBU는 주요 기능 영역과 제품 그룹에 대해 팀의 기술을 평가하고 각 사용 사례에서 해당 영역을 개선하기 위한 구체적인 이니셔티브를 개발했습니다. 회사에서 여러 애플리케이션을 마이그레이션하는 경우에는 보안 및 일반 IaaS와 같은 모든 제품에 적용되는 기본적인 클라우드 지식을 생성할 수 있는 위치를 고려하십시오.

결과 축하

이 플레이북은 60개 이상의 SaaS 기반 애플리케이션을 Oracle Cloud Infrastructure로 마이그레이션하면서 Oracle GBU가 축적한 지식을 기반으로 합니다. 이러한 애플리케이션은 8개 산업 분야와 전 세계 199,000개 이상의 고객 환경에서 핵심 엔터프라이즈 기능을 지원하고 있습니다. 철저하고 신중하게 계획되고 잘 실행된 마이그레이션은 상당한 이점을 가져다 주었습니다.

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

이 ISV 플레이북은 GBU 팀이 얻은 교훈을 바탕으로 작성되었지만, 이러한 노력은 Oracle Cloud Infrastructure로 진행된 여러 대규모 마이그레이션 중 하나에 불과합니다. 모든 SaaS 애플리케이션의 매출과 고객 수를 고려할 때 Oracle은 세계에서 가장 큰 ISV 중 하나로 볼 수 있으며, 마이그레이션 프로세스에 대해 깊은 이해를 가지고 있습니다. Oracle은 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이라고 부르는 광범위한 혁신 이니셔티브의 일부입니다. 이 프로젝트는 수십 개의 데이터 센터에 분산된 수만 개의 애플리케이션이 참여한 다년간의 프로젝트였습니다.

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

• 인프라 – 애플리케이션 포트폴리오 전체에서 99.99%의 가용성을 달성하여 30%의 비용 절감 효과와 2~10배의 성능 향상 효과를 얻었습니다.
• 재무 – 10일 이내에 장부를 마감하고 수익을 보고할 수 있는 기능을 확보했습니다.
• HR – 직원 평가 주기 시간을 70% 단축했습니다.
• 공급망 – 공급망 계획 주기를 1주일에서 48시간으로 단축하여 71% 개선 효과를 얻었습니다.
• CX – 캠페인 리드 타임을 4주에서 5일로 단축하여 82% 개선 효과를 얻었습니다.
• 지속 가능성 – FY19에 Oracle에서 수집한 폐기된 장비의 99.4%를 재사용 또는 재활용했습니다.

Oracle과의 파트너십

Oracle은 ISV가 시장 범위를 확장하고 매출 성장 잠재력을 높일 수 있도록 돕고 있습니다. 자세히 알아보려면 oraclecloud-isv_ww@oracle.com으로 이메일을 보내주십시오.

ISV가 Oracle Cloud를 선택해야 하는 이유를 자세히 알아보려면 다음 리소스를 참조하십시오.

• isv.oracle.com
• ISV를 위한 Oracle@Oracle 프로그램
• 클라우드 호스팅 고려사항과 패턴 마이크로사이트 살펴보기

---

Körber는 창고 관리 시스템을 Oracle Cloud Infrastructure로 통합하여 40% 더 빠르게 실행할 수 있게 되었습니다.

"저희가 여러 가지 의사결정 요인을 평가했을 때 OCI는 GTM(Go-To-Market) 전략에 따라 수행하려는 목표의 측면에서 핵심적인 전략 요소였습니다." — Rick Schrader, Senior Vice President of North America Sales and Alliances, Körberö

동영상 보기

---