[컴퓨터월드] 비즈니스 목표에 맞춰 클라우드 전략(클라우드 컴퓨팅에 대한 간결한 관점)을 수립한 기업은 그렇지 않은 기업에 비해 보다 나은 성과를 달성할 가능성이 높다. 이들 기업은 클라우드 사용에 대해 보다 일관된 접근 방식을 가지고 있으며 클라우드 사용의 이점과 단점을 예상, 단점을 최소화하면서 이점을 활용하려 한다.

엔터프라이즈 아키텍처(Enterprise Architecture, 이하 EA) 또는 기술 혁신(Technology Innovation, 이하 TI) 리더들은 우선순위를 이끌어내고 협의할 수 있는 공통 전략을 갖추고 있어야 조직의 요구사항을 충족시킬 수 있다. 이는 여타 IT 관련 분야에 있는 사람들에게도 동일하게 적용된다.

클라우드 컴퓨팅에 대한 질문은 대부분 클라우드 전략을 중심에 두고 이루어진다.

“클라우드 전략이란 무엇이며 왜 필요한가?”에서 “종합적인 클라우드 전략을 마련하려면 어떻게 해야 하는가?”에 이르기까지 다양하며 이들 질문은 원칙과 우선순위에 대한 다른 질문으로 이어진다.

클라우드 전략은 데이터센터, 보안 및 아키텍처 전략과 같은 다른 전략들과 연계돼야 한다. 그리고 디지털 혁신 이니셔티브를 지원해야 한다.

클라우드 컴퓨팅을 채택하기 전에 클라우드 전략을 먼저 수립하는 것이 가장 좋겠지만, 그런 경우는 매우 드물다. 대부분의 기업은 클라우드에 대한 경험을 쌓은 후 클라우드 전략을 수립한다. 그러나 클라우드 전략을 빨리 수립할수록 더 많은 문제를 피할 수 있다. 아직 클라우드 전략이 없다면, 바로 지금이 적기다.

클라우드 전략 수립의 템플릿으로 활용하라

여기서 소개할 전략은 수백 명의 가트너 고객들과 논의하고 함께 검토한 전략으로, 좋은 가상의 템플릿이 될 것이다. ‘개요’에는 주요 섹션에 대한 대략적인 요약 및 기준, 가장 중요한 요소, 원칙, 현재 위치 평가가 포함돼 있다. 순서대로 작성할 필요는 없다. 오히려 다른 섹션을 작성한 후 개요를 작성하는 것이 좋다.

개요

먼저 고위 경영진과 소통할 기회를 잡아야 한다. 클라우드 위원회에 참여한 사람들을 대상으로 클라우드 전략이 단순히 IT 문서가 아니라는 것을 보여줄 수 있도록 해야 한다. 개요는 전체의 노력을 정리하는 것이므로 마지막에 작성하는 것이 좋다.

기준선

클라우드 컴퓨팅이 목표로 하는 비즈니스 성과에 대한 기준을 만드는 것을 시작으로 클라우드 전략을 수립하라.

클라우드 컴퓨팅 기준과 용어

단순함이 핵심이다. 클라우드 컴퓨팅에 대해 정의하고 이를 일관되게 사용함으로써 혼란을 제거하면 된다(미국 국립표준기술연구소와 가트너에서 일련의 정의를 만든 바 있다).

클라우드 네이티브, 멀티 클라우드, 분산 클라우드 등 클라우드 컴퓨팅과 관련한 새로운 용어가 많지만 이 용어들의 의미가 잘 정립돼있는 것은 아니다. 이러한 용어를 사용하는 경우 의미가 명확해야 한다. ‘순수 클라우드’, ‘클라우드로부터 영감을 받은’ 등과 같은 표현을 활용하는 것을 고려할 수 있다. 용어를 새로 만들기 보다는 기존 용어를 사용하는 것이 좋다.

비즈니스 기준 및 목표

이 섹션에서는 비즈니스 혁신 이니셔티브뿐만 아니라 최상위 레벨의 비즈니스 전략과 원하는 비즈니스 결과를 요약한다. 연례 보고서, 고위 경영진의 연설 및 비즈니스 리더와의 대화를 소스로 사용할 수 있다.

다음으로 잠재적인 이점과 위험을 살핀다. 이것들은 대부분 일반적이며 바이모달(Bimodal) IT 원칙과 일치한다. 비용 절감 또는 민첩성 중 목표가 무엇인지 파악하고 클라우드 컴퓨팅이 목표를 달성하는 데 도움이 될 방법을 평가한다.

바이모달 IT 원칙이 지원하는 우선순위 지정은 비즈니스 결과를 처리하는 데 핵심적이다. 잠재적인 클라우드 이점은 비용과 효율성 중심의 전통적 그룹과 혁신, 속도, 시장 출시와 같은 민첩성 등 총 2가지로 그룹화된다. 우선순위를 정하는 데는 클라우드로 이동 시 워크로드가 아니라 이점들을 고려해야 한다.

이러한 과정을 모두 거쳤다면, 해당 기업에서 겪고 있는 이슈를 검토한다. 특정 산업 및 지역에서 비즈니스를 통해 성취하고자 하는 것, 데이터 센터 전략과 일치시켜야 하는지 여부, 정상 참작 사유 여부, 코로나19 팬데믹 등 광범위한 영향을 미치는 불확실한 사건에 대한 대응 등이 여기에 해당된다.

이 섹션에서는 비즈니스 목표를 클라우드 컴퓨팅의 잠재적 이점에 매핑하고 문제를 극복하는 방법을 설명한다. 기업이 클라우드에 관심을 갖는 이유를 알아야 하고 바이모달 원칙을 활용해 우선순위를 정하고 목표에 집중해야 한다.

브레인스토밍

유동적이며 많은 논의 사항을 수용하는 단계다. 주요 원칙을 브레인스토밍 할 때 서비스 전략과 재정적 고려 사항이 중요하다. 원칙과 활용에 대한 이해를 높이기 위해 문서화하기를 추천한다.

서비스 전략

퍼블릭 클라우드 공급업체의 클라우드 서비스를 언제 사용할 것인지, 또한 온프레미스(On-premises) 또는 다른 환경에서 기능을 구축하거나 최소한 계속 유지 관리를 해야할지 결정해 서비스 전략을 정해야 한다. 서비스형 인프라(IaaS), 서비스형 플랫폼(PaaS) 및 서비스형 소프트웨어(SaaS)의 용례는 구분돼야 한다.

클라우드 서비스를 구축하는 결정은 쉬운 문제가 아니다. 대부분의 조직이 온프레미스 기능을 일부 유지하고 있는 상황에서 하이퍼스케일 클라우드 공급업체의 기능을 복제하려 해서는 안 된다. 클라우드 컴퓨팅에서 소비자, 공급자, 그리고 브로커까지 모든 잠재적 역할의 적용성을 검토해야 한다.

재정적 고려 사항

클라우드 컴퓨팅에 대한 재정적 문제를 매우 중요하다. 비용 투명성, 가시성, 예산 및 예측 가능성과 같은 문제를 심도있게 검토해야 한다. 기업은 클라우드 컴퓨팅에 대한 지출은 일반적으로 자본 지출(Capex)이 아닌 운영 지출(Opex)에 해당한다.

그러나 반드시 그런 것은 아니다. 모든 것을 운영 비용으로 전환하면 기업의 재무 프로필이 변할 수 있다. 따라서 기업 재무 모델 변경의 의미를 충분히 이해하고 있는 재무 전문가를 참여시키는 것이 좋다.

가격 책정 모델 동향을 파악하는 것도 중요하다. 예를 들어 laaS는 주로 하드웨어(HW) 비용에 따라 가격이 천천히 내려가는 경향이 있고 선불방식(Pay-As-You-Go)일 수 있다.

SaaS 계약은 주로 3년 단위로 지속되며 사용자당, 월 단위로 요금이 청구된다. 그리고 가격이 올라가는 경향이 있다. 무엇보다, 클라우드로의 이동이 항상 비용을 절감을 의미하지는 않는다는 것을 명심해야 한다.

원칙 및 인벤토리

원칙

클라우드 전략에 반영될 원칙이 무엇인지 정한다. 일부는 타협불가한 것일 수 있다. 예를 들어 클라우드 전략을 워크로드별 또는 애플리케이션별 실행이라고 정했다고 가정해보자. 이 경우 “퍼블릭 클라우드로의 리프트 앤 시프트(lift-and-shift) 마이그레이션은 최후의 수단이어야 한다”와 같이 명시적으로 언급하는 것이 좋다.

리프트 앤 시프트 마이그레이션을 통해 얻을 수 있는 이점은 많지 않다. 그러나 때로는 그것이 적절한 경우도 있다. 한 예로 데이터센터 폐쇄가 전략일 경우, 이에 맞춰 보관 장소를 찾아야 할 것이다. 애플리케이션을 변경하고 싶지 않거나 애플리케이션을 클라우드로 이전한 데이터 혹은 애플리케이션과 함께 배치해야 하는 경우 마이그레이션이 필요하기도 하다. 그러나 타당한 이유 없이 리프트 앤 시프트를 사용하는 건 현명하지 않다. 현 상황이 매우 비효율적이지 않은 한 막대한 비용 절감이나 민첩성 이점 또한 기대할 수 없다.

더불어 긍정적인 관계나 기술에 대한 투자 등 공급업체 중심의 고려 사항을 문서화하기를 권장한다. 클라우드 퍼스트·변형(예 클라우드 스마트), 구축 전 구매, 최고 품종, 멀티 클라우드 등을 포함한 일반적인 원칙들을 고려해야 한다. 이 중 일부는 클라우드 네이티브 혹은 멀티클라우드와 같은 아키텍처 원칙일 수 있다. 출구 전략 수립 등의 상황에서 다시 부상할 가능성이 높다.

클라우드 퍼스트는 클라우드 전략 및 도입 결정에 가이드가 되는 공통 원칙이다. 혹자는 슬로건 정도로 치부하지만 그 이상이며 전체 전략은 아니다. 클라우드 퍼스트가 모든 것을 클라우드로 전환한다는 의미라는 오해를 종종 받기도 한다. 그러나 이는 사실이 아니고 클라우드 퍼스트는 투자를 요청할 때 퍼블릭 클라우드를 기본 접근 방식으로 사용한다는 의미다. 새로운 기술이나 비즈니스 이니셔티브에 대한 첫번째 옵션으로 클라우드를 고려해야 한다는 의미기도 하다.

인벤토리(현재 위치 평가)

클라우드 전략은 워크로드에 따라 다르므로 해당 워크로드의 인벤토리를 구성해야 하며, 각 워크로드에 대한 일련의 정보를 손쉽게 파악할 수 있어야 한다.

인벤토리는 상당한 작업을 요구할 수 있으며 별도의 프로젝트나 채택의 일부로 분리되는 경우가 많다. 전략 단계에서 가장 중요한 것은 각 워크로드에 대해 어떤 정보를 수집해야 하는지 구체적으로 명시하는 것으로 그 범위를 결정한 뒤 작업을 시작할 수 있다.

인벤토리 정보에는 이름, 소유자, 작성자, 공급업체(해당되는 경우) 및 공급업체 관련 정보, 가상화 여부, 보안 및 데이터 요구사항, 통합, 워크로드 목표 (효율성 또는 민첩성) 등이 포함된다.

클라우드에 적합한 후보가 있는지를 결정할 때는 성능 특성을 분석할 수 있다. 스펙트럼을 사용하면 도움이 될 것이다.

● 스펙트럼의 한쪽 끝에는 예측 불가능한 워크로드가 있다. 이로한 워크로드는 웹사이트, 모바일 앱 또는 API 게이트웨이와 같이 외부에 노출되어 있고 수요 예측이 어렵거나 불가능하다. 일반적으로 퍼블릭 클라우드에 적합한 후보다.

● 스펙트럼의 다른 쪽 끝에는 잘 작동하는 애플리케이션이 있다. 이미 가상화돼 데이터센터에서 효율적으로 실행되고 있는 일반적인 엔터프라이즈 애플리케이션이 이에 해당한다. 이러한 애플리케이션은 워크로드의 변화가 크지 않고 피크 워크로드가 없는 안정된 상태의 애플리케이션이다. 이렇게 예측 가능한 워크로드는 일반적으로 클라우드의 이점을 누리지 못하며 가장 먼저 이전해야 할 대상도 아니다.

● 스펙트럼의 중간 부분은 상황이 명확하지 않다. 오버프로비저닝된(Overprovision) 전형적인 워크로드가 있을 수 있는데 여기에는 오버프로비저닝해야 할 피크가 있을 수 있다. 클라우드버스팅(Cloudbursting)은 클라우드 컴퓨팅의 오랜 목표로 언급되어 왔지만 그 적용 가능성은 제한적이다.

클라우드 전략을 다른 전략 및 지원 요소와 일치시키기

클라우드 컴퓨팅이나 클라우드 전략은 진공 상태에 존재하는 것이 아니다. 클라우드 전략이 보안, 데이터센터, 에지 컴퓨팅, 개발 및 아키텍처의 기존 전략과 일치하도록 해야 한다. 이를 재창조하거나 반박해서는 안 되며 다른 그룹과 소통하고 협상해 성공적인 전략을 수립해야 한다.

보안

보안은 매우 중요해 별도의 섹션이 요구된다. 거버넌스, 규정 준수 및 개인정보 보호를 포함하는 보안과 기타 모든 지원 요소(기술 아키텍처, 인프라, 인력 배치 및 조달 등)가 서로 조화를 이루도록 접근해야 한다. 클라우드 전략에 보안에 관한 내용이 포함되어 있다면 이를 보안 전략에도 포함해야 하며, 반대의 경우도 똑같이 적용된다.

보안은 공동의 책임이다. 클라우드를 안전하게 사용하려면 보안의 다양한 역할과 책임을 이해해야 한다. 공급자 계층화와 같은 개념을 사용하여 높은 기준으로 보안에 접근하기를 권한다. 누구나 클라우드 공급업체라고 주장할 수 있고 업체는 매우 낮은 수준의 보안 기능을 갖추고 있을 수 있다.

일반적으로 최상위 클라우드 공급업체는 그들이 제공하는 서비스에 대한 보호는 탁월하지만 사용자가 호스팅하는 애플리케이션이나 데이터는 보호하지 않는다. 클라우드에 저장한 데이터를 적절하게 보호해야 하고, 이를 보호받지 않은 상태로 둔 경우 이는 공급업체의 책임이 아니다.

조직 및 인력 문제와 같은 지원 요소

클라우드 보안 문제를 전체 보안 전략에 맞추는 것처럼 클라우드 인력 문제도 전반적인 인력 배치 전략에 맞게 조정해야 한다. 클라우드 컴퓨팅은 채택하는 클라우드 서비스의 수준에 따라 인력 요건에 변화를 줄 필요가 있다. 서버를 직접 관리하는 인력은 적게 필요한 반면 통합, 네트워크 엔지니어링, 비즈니스 분석, 공급업체 관리 및 보안과 같은 작업을 수행하는 인력은 더 많이 필요하다. 일부에게는 성장의 기회가 존재할 것이며 적절한 인력을 참여시키는 게 중요하다. 그렇기에 이 작업에 HR이 반드시 포함돼야 한다.

조직의 관점에서 클라우드 전략 위원회 및 클라우드 혁신 센터(CCoE, Cloud Center of Excellence) 구성에 대해 논의할 필요도 있다.

출구 전략

클라우드 회귀는 드문 일이다. 하지만 이를 사용하지 않더라도 종속성과 선택 사항을 설명하는 출구 전략을 수립하는 것은 중요하다. 가능성을 인식하고 이에 대한 계획을 세우는 것은 전략적 계획의 중요한 한 부분이다. 현재 EU를 중심으로 금융 서비스와 관련한 여러 규제당국은 출구 전략을 의무화하고 있다.

출구 전략을 검토하는 조직은 대부분 약관과 서비스 수준 협약(SLA)과 같은 계약에 초점을 맞춘다. 계약이 그마큼 중요하다는 얘기다. 그러나 출구 전략에 있어 계약은 시작에 불과하다. 데이터 소유권, 백업, 데이터 복구, 이동성 등의 문제를 검토해야 한다.

출구 전략에는 기술적인 요소, 비즈니스 요소가 모두 포함돼야 하고 네트워킹, 관리 도구, 통합, 및 타사 서비스 등 클라우드 서비스를 지원하는 모든 인프라를 포함해야 한다.

출구 전략에서 가장 많이 논의되어야 할 이슈는 락인(Lock-in)이다. 락인은 데이터 수준, 애플리케이션 수준, 아키텍처 수준, 스킬 수준 등 여러 방향에서 발생할 수 있다.

그리고 이로 인해 멀티 클라우드와 클라우드 네이티브 문제를 검토해야 할 수도 있다. 많은 기업들이 멀티 클라우드 접근 방식을 따르고 싶다고 하면서 클라우드 전략 문서에는 이와 동시에 클라우드 네이티브이기를 원한다고 명시하곤 한다.

이러한 개념들이 논리적 극단으로 향하면 충돌하게 된다. 멀티 클라우드 접근 방식을 따르면서도 공급업체에 의존적이지 않으려면 공급업체에서 제공하는 네이티브 기능 사용 시 주의해야 한다. 또한 이러한 문제들을 클라우드 전략을 통해 해결할 수 있어야 한다.

클라우드 전략 실행

클라우드 위원회를 구성하고 클라우드 전략을 수립했고 원칙을 정했고 인벤토리를 최소한 만들기 시작했다면 이제 전략을 실행해야 한다.

예를 들어 클라우드 퍼스트 원칙을 준수하기로 한 경우, 애플리케이션 개선 요청이 들어올 때 인벤토리를 참조해 해당 원칙을 적용할 것이다. 2년 내에 데이터센터를 폐쇄하는 것이 데이터센터 전략이라면 상황이 복잡하다. 이 경우에는 모든 것에 거처를 찾아주는 클라우드 마이그레이션 계획도 수립해야 한다. 그러나 이에 관한 계획이 없다면 모든 애플리케이션을 검토해 이전하는 것은 좋지 않다.

이 지점에서 데이터센터 전략과 연계가 시작되고 비로소 전략이 실행으로 옮겨진다. 데이터 센터 및 I&O 중심 문제는 정상 참작이 가능한 상황을 유발하는 경우가 많다. 그러나 애플리케이션 현대화, 인수 합병, 신제품 개발, 비즈니스 탄력성 및 기타 전략과 같은 다른 고려 사항이 대량 마이그레이션을 유발할 수 있다.

인벤토리에 원칙을 적용하는 프로세스에 따라 워크로드에 대해 수행할 작업을 결정하면 된다. <그림 1>은 워크로드에 대해 내릴 수 있는 다양한 결정을 보여주는데, 가트너에서는 이를 ‘Rs(Retain, Rehost, Revise, Rearchitect, Rebuild, Replace, Retire)’라고 부른다.

일련의 과정을 거쳐 살아있는 문서로 기능하는 클라우드 전략은 다음 단계의 구현(채택 또는 마이그레이션이라고도 할 수 있다)을 지원한다. 전략과 구현은 계속해서 함께 진행되어야 한다.