많은 기업들에게 클라우드에서 성공한다는 것은 여전히 쉽지 않은 일입니다. 조직들은 보통 혜택에 대해서는 지나치게 높은 기대치를 정하고 필요한 작업량은 과소평가합니다. 이로 인해 최악의 경우, 서로를 탓하고, 손가락질하며, 성공으로 간주할 수 있는 작은 무언가라도 붙잡으려고 안간힘을 쓰는 악순환의 고리가 생겨납니다.
그 무언가를 발견하면, 조직은 이제 충분하다고 생각하며 클라우드의 완전한 혜택을 누리게 되기도 전에 마이그레이션 과정을 중단합니다. 실질적인 개혁을 미루면 처음에 클라우드 마이그레이션 프로젝트를 추진하게 만들었던 혁신과 비용 혜택을 실현할 수 없습니다. 마이그레이션 비용이 풍선처럼 부풀어 오르고 기대했던 기능과 애플리케이션이 현실화되지 않으면, 기업들은 클라우드를 그냥 값비싼 헛짓거리 정도로 여기게 되고 맙니다.
무슨 일이 일어난 걸까요?
많은 경우, 가장 큰 실수는 클라우드를 잘못된 방식으로 생각한데서 기인합니다. 대부분의 사람들은 클라우드 마이그레이션을 그냥 모든 것을 완전히 들어다 클라우드로 옮겨 놓는 작업이라고 생각합니다. 자사의 데이터센터에서 실행 중인 애플리케이션들을 클라우드로 그냥 이동하는 것 말입니다.
그러나 대규모로 클라우드에서 성공하려면 전면적인 이동 그 이상이 요구됩니다. 동적인 클라우드의 세상을 성공적으로 항해할 필요가 있습니다.
동적인 클라우드는 애플리케이션의 확장을 촉진해줄 뿐만 아니라 그 과정을 더 빠르고 더 쉽게 만들어줍니다. 또한 개발 팀이 변화에 빠르게 대응하고 변경된 사항을 보다 신속하게 구현할 수 있도록 해줍니다. 이는 사치가 아니라, 필수입니다. 기대하지 못했던 폭증 등으로 고도로 동적인 확장이 요구될 때 애플리케이션의 가용성을 보장하려면 동적인 클라우드가 반드시 필요합니다.
동적인 클라우드에서 성공하려면 전면적인 이동보다 더 높은 수준의 헌신이 요구됩니다. 팀들은 통제된 방식으로 이동하고 그 과정에서 일어난 실수로부터 교훈을 얻어야 합니다. 그리고 무엇보다 마이그레이션 도중에 모든 것을 측정해야 합니다.
마이그레이션 후에는 애플리케이션과 인프라 가시성의 유형이 바뀌기 때문입니다. 많은 리소스들이 동적이 되어 어떤 목적에 어떤 리소스가 중요한지 추적하는 것 자체가 동적이 됩니다. 이외에도, 이제 애플리케이션이 팀의 직접적인 통제 밖에 있는 인프라에서 운영됩니다. 애플리케이션과 클라우드를 주의 깊게 모니터링하지 않으면, 발생된 문제가 애플리케이션과 관련된 것인지 아니면 클라우드 서비스와 관련된 것인지를 밝혀내는 것이 불가능해질 수 있습니다.
다행인 것은, 동적인 클라우드에서 충분한 역량을 갖추는 것은 위험한 일도 아니고 걱정할 필요도 없다는 것입니다. 클라우드 도입은 안전하고 효과적으로 수행될 수 있지만 지속적으로 배워가는, 일종의 학습 경험이라고 할 수 있습니다. 기업은 클라우드가 제공할 수 있는 현실에 자사의 니즈 및 기대를 매치시킬 수 있도록 학습하고 클라우드 서비스를 조정해 나갈 의지가 있어야 합니다.
클라우드 성숙의 6단계실질적으로, 모든 것을 한번에 이룰 수 있을 것이라고 기대하면 안됩니다. 조직이 클라우드 도입 과정에서 거치게 되는 6가지 성숙의 단계가 존재합니다.
- 실험: 클라우드란 무엇인가?
- 클라우드 보안: 클라우드를 신뢰할 수 있는가?
- 서버리스 및 SaaS 활성화: 전면적 이동 및 클라우드가 제대로 작동하는지에 대한 확인
- 가치를 더해주는 서비스 활성화: 동적 클라우드의 관행화
- 고유한 서비스 활성화: 문화에 깊게 뿌리 내리는 동적 클라우드
- 클라우드 사용 의무화: 자체적인 데이터센터가 왜 필요한가?
클라우드로 성공적으로 이동하려면, 이러한 연속적인 클라우드 성숙 주기가 존재한다는 사실을 깨닫고 그것이 조직의 조치와 절차에 미치는 영향을 이해하는 것이 중요합니다. 하나의 성숙 단계에서 다른 단계로 이동하는 것은 항상 쉽지도, 또 빠르지도 않으며 세부적인 사항은 조직마다 차이가 있습니다. 핵심 요소인 애플리케이션과 인프라에 대한 가시성이 클라우드 성숙 전략에서 누락되는 경우가 많습니다. 이는 클라우드 도입의 성공적인 진행을 제한하고 가로막습니다.
마지막으로, 조직들은 때로 자사의 문화와 환경에 맞는 클라우드 성숙 단계에 안주합니다. 최고의 성숙 단계에 도달하지 못해도 괜찮습니다.
1단계: 클라우드 실험
첫 번째 단계에서는 비즈니스에 덜 핵심적인 애플리케이션과 애플리케이션의 일부에만 간단하게 적용될 수 있는 안전한 기술에 의존합니다.
1단계는 클라우드 서비스가 어떻게 작동하는지 테스트하기위해 단일한 애플리케이션을 클라우드에서 사용해봅니다. 보통 사용되는 첫 번째 서비스는Amazon Simple Storage Service(S3)같은 스토리지 솔루션입니다. 클라우드에는 무언가를 저장하기가 쉽고 애플리케이션이 의존하는 복잡한 과정과 서버 문제를 회피할 수 있기 때문입니다.
이 단계는 보통 1~2개 팀이 독립적인 마이그레이션을 수행하는 1회성 실험으로 시작됩니다. 이 시점에서는 클라우드 정책이 생성되지 않으며, 클라우드가 정확히 무엇인지 파악하는 것이 목표입니다.
2단계: 클라우드 확보
이 단계에서는 조직의 클라우드 문화가 중요한 진화를 겪습니다. 법무, 재무, 보안 등 기업 전반의 부서들이 관여하기 시작하기 때문입니다.
기업 내에서 클라우드가 어떻게 사용되어야 할지에 대한 정책이 수립되는 것도 바로 이 단계에서입니다. 공식적인 정책에서 즉각적인 ‘기업 문화’에 대한 이해까지, 지침들이 얼마나 세부적인지는 크게 문제가 되지 않습니다. 중요한 것은 기업 전체가 참여하고 모든 이해관계자의 의견이 수렴되어야 한다는 것입니다.
또한 애플리케이션에 대한 가시성 및 모니터링 전략이 이 단계에서 수립됩니다. 목표는 다음의 질문에 대한 답을 찾는 것입니다.
- 클라우드로 이동되는 기본적인 애플리케이션들을 어떻게 모니터링할 것인가?
- 모니터링 전략이 미래의 클라우드 성숙 단계에서 발생하는 동적 변화를 감당할 수 있는가?
- 새로운 클라우드 인프라가 어떻게 기능을 하는지에 대한 올바른 가시성을 보유하고 있는가?
이 시점을 통과하지 못하는 기업들은 클라우드에서 완전한 성공을 거두기 어렵습니다.
3단계: 클라우드에서의 서버와 애플리케이션 사용
클라우드 성숙의 세 번째 단계는 조직이 온프레미스 서버와 다른 백엔드 리소스를 교체하기 시작할 때 시작됩니다. ‘클라우드로 그냥 먼저 이동을 하고, 어떻게 되는지 두고 보자’는 생각으로 단순히 들어다 이동한 애플리케이션들이 여전히 존재합니다.
이 단계의 목표는 클라우드가 전체 애플리케이션의 관점에서 어떻게 작동하는지를 이해하는 것입니다. 중요한 것은, 조직이 클라우드로부터 실질적인 혜택(비용 절감, 유연성 향상 등)을 누리기 시작하는 것이 바로 이 시점이라는 것입니다.
3단계에서는 또한 데이터센터에서 사용되고 있는 애플리케이션에 대한 가시성과 모니터링 전략이 클라우드로 확장됩니다. 이러한 모니터링 및 가시성 전략은 애플리케이션 마이그레이션을 성공적으로 만드는데 핵심적인 요소가 됩니다.
그러나 3단계는 위험이 존재한다는 점을 기억해야 합니다. 이 단계에서 조직이 클라우드에서 애플리케이션을 운영해서 얻는 가치를 평가하면, 누리는 혜택이 클라우드 비용에 상응하지 못한다는 사실을 발견할 수도 있습니다.이로 인해 기업이 전체 클라우드 노력을 실패로 간주하고 시도를 중단해버리는 경우가 생길 수 있습니다.
4단계: 가치를 더해주는 매니지드 서비스 활성화
물론, 클라우드는 기업 데이터센터 외부의 서버에서 애플리케이션을 호스트하는 장소 그 이상의 역할을 합니다. 4단계에서 조직은 가치를 더해주는 일부 클라우드 서비스들을 활용하기 시작합니다.
4단계에서 일반적으로 이뤄지는 대화는 “가만있자, 클라우드에 데이터베이스가 있는데 아직도 우리가 관리를 해야하네. AWS와 Microsoft Azure 모두 데이터베이스를 관리해주는데, 우리도 데이터베이스 관리를 맡기는 게 어떨까?”가 될 것입니다.
이 시점에서 조직이Amazon Relational Database Service(RDS)와Amazon Aurora 등의 매니지스 서비스를 활용합니다.Amazon Elastic Beanstalk이나Amazon Elasticsearch Service처럼 애플리케이션에 더 높은 가치를 제공하는 서비스들을 검토할 수도 있습니다.
동적 클라우드의 효과가 나타나기 시작하면, 클라우드의 최대 혜택들이 나타나기 시작합니다. 이 단계에서 기업들이 클라우드를 적어도 일부 전략적 애플리케이션과 서비스에 사용하겠다는 결심을 하게 됩니다.
5단계: 고유한 클라우드 서비스 활성화
기업이 클라우드 기반이 되면, 고가치의 클라우드 전용 서비스에 눈을 돌릴 수 있습니다. 클라우드 기반의 환경에만 존재하는 이러한 서비스들은 동적 클라우드를 위해 설계되며, 서버리스 컴퓨팅(예:AWS Lambda), 고도로 확장 가능한 스키마리스 데이터베이스(예: Amazon DynamoDB), 데이터 웨어하우징(Amazon Redshift), 또는 큐잉(Amazon Simple Queue Service, or SQS), 공지(Amazon Simple Notification Service, SNS) 서비스 등이 보편적입니다.
5단계에서는 동적 클라우드의 개념이 조직의 애플리케이션 개발과 관리 절차에 통합됩니다. 이 시점에서 모니터링 전략이 고도로 동적인 애플리케이션들에 대한 가시성을 제공하도록 만드는 것이 중요합니다.
이 서비스들은 또한 특정 클라우드 제공업체에 종속되어 있습니다. 많은 클라우드 제공업체가 서버리스 역량을 제공하지만, 그 방식은 약간씩 차이가 있습니다. 조직이 더 높은 가치의 클라우드 서비스를 사용하기 시작하면, 클라우드뿐만 아니라 특정 클라우드 제공업체에 매이게 됩니다.
6단계: 클라우드 의무화
이 단계는 클라우드 도입의 마지막 성숙 단계입니다. 조직이 6단계에 도달하면, 클라우드는 데이터센터의 모든 니즈는 아니더라도 거의 모든 니즈를 충족해주고 추가적으로 가치를 더해주는 서비스를 제공합니다. 이제 많은 기업들은 “자체 데이터센터가 왜 필요한가?”“데이터센터를 지속적으로 운영할 필요가 있나?”라는 당연한 질문을 하게 됩니다.
6단계에서는 최소한 새로운 애플리케이션들은 기본적으로 데이터센터가 아니라 클라우드에서 운영되며, 조직은 데이터센터가 왜 필요한가를 정당화시켜야 합니다. 그러나 최종적인 목표는 모든 애플리케이션을 클라우드로 이동하여 조직이 데이터센터를 아예 사용하지 않게 되는 것입니다.
이는 클라우드 네이티브 기업에게 특히 보편적인 일로, 시장에서 이미 자리를 잡은 기업들은 레거시 데이터센터를 적어도 당분간만이라도 유지하는 편을 선택할 수 있습니다. 그럼에도 불구하고, 데이터센터 관리 사업을 포기하고 클라우드를 전격 도입하는 전통적인 기업들이 늘고 있습니다.
최고 효율점
클라우드 컴퓨팅 성숙의 6단계는 개별적인 애플리케이션, 조직 또는 전체 기업에 적용됩니다. 그러나 특정 애플리케이션의 클라우드 성숙 단계는 조직 전체의 단계보다 더 높거나 낮을 수 있습니다.
예를 들어, 클라우드 마이그레이션의 초기 대상에는 내부 애플리케이션이 포함됩니다. 고객이나 비즈니스 자체에 부정적인 영향을 미칠 위험이 적기 때문입니다. 실제로, 내부 애플리케이션은 6단계로 점프하지만 전체 기업은 1단계에 머물러 있는 경우도 있습니다.
일부의 경우, 애플리케이션과 기업의 클라우드 성숙 간의 상호작용으로 클라우드 도입의 최고 효율점이 생겨날 수 있습니다.이는 클라우드가 성숙하는 과정에서 많은 기업과 애플리케이션이 향하는 지점입니다. 기업과 각 애플리케이션은 이 최고 효율점으로 신속하게 이동하는 경향이 있지만 이 지점에 도달한 후에는 마이그레이션 과정이 느려집니다.
이러한 지점에 도달하는 것은 반드시 좋거나 나쁘다고 말할 수는 없습니다. 이는 클라우드 도입의 초기 단계에서 최고 투자수익률을 달성할 수도 있다는 사실을 보여줄 뿐입니다. 애플리케이션의 필요성, 기업 문화, 비즈니스 절차 및 비즈니스 니즈에 따라, 이 지점을 초월해 이동하는 것이 합리적일 수도 그렇지 않을 수도 있습니다.
이 블로그에 표현된 견해는 저자의 견해이며 반드시 New Relic의 견해를 반영하는 것은 아닙니다. 저자가 제공하는 모든 솔루션은 환경에 따라 다르며 New Relic에서 제공하는 상용 솔루션이나 지원의 일부가 아닙니다. 이 블로그 게시물과 관련된 질문 및 지원이 필요한 경우 Explorers Hub(discuss.newrelic.com)에서만 참여하십시오. 이 블로그에는 타사 사이트의 콘텐츠에 대한 링크가 포함될 수 있습니다. 이러한 링크를 제공함으로써 New Relic은 해당 사이트에서 사용할 수 있는 정보, 보기 또는 제품을 채택, 보증, 승인 또는 보증하지 않습니다.