류프리

클라우드 컴퓨팅 도입은 오늘날 비즈니스의 주요 원동력으로 빠르게 자리잡아가고 있다. 비용을 절감하고 애질리티를 증대시키기 위해 애플리케이션들이 온-프레미스 데이터 센터를 벗어나고 있기 때문이다.

Credit:GettyImages

아마존 웹 서비스(AWS), 마이크로소프트 애저(Azure), 그리고 구글 클라우드 플랫폼 등 주요 클라우드 업체 셋은 보안과 데이터 주권에 대한 초기 우려들을 각자 나름의 방식으로 해결하려 했다. 그리고 매우 규제가 엄격한 기업을 제외한 거의 모든 기업이 이들의 솔루션을 도입했다.

이러한 변화는 IaaS 시장을 포화 상태로 만들었고, 2016년 기준 IaaS 시장 규모는 무려 250억 달러에 이르렀다고 가트너는 최근 통계를 통해 밝혔다. 가트너는 IaaS 시장 규모가 내년이면 450억 달러 수준으로 성장할 것으로 예측했다.

IaaS는 써드파티 제공자가 하드웨어, 소프트웨어, 서버, 스토리지 등 핵심 인프라를 고객을 대신하여 호스팅 및 관리해주는 서비스 모델이다. 주로 고도의 확장적 환경에서 애플리케이션을 호스팅하고, 고객들은 실제 사용하는 인프라에 대해서만 요금을 지불하는 형식으로 이루어지고 있다.

AWS는 2006년 클라우드 서비스 공급을 시작한 이후 줄곧 시장에서 지배적 위치를 점해 왔다. 2017년 2월 시너지 리서치(Synergy Research) 보고서에 따르면 AWS의 시장 점유율은 40%에 육박하는데 MS, 구글, IBM의 점유율을 모두 합한 것이 23% 정도인 것을 고려하면 AWS의 시장 지배력을 짐작할 수 있다.

그러나 AWS의 이런 우위에도 불구하고, 마이크로소프트는 ‘클라우드 우선’ 정책을 적극적으로 펼친 CEO 사티아 나델라의 리더십 하에 빠르게 글로벌 클라우드 네트워크를 구축하며 IaaS 시장에서의 입지를 굳혀 나갔다. 또한 인터넷 거인 구글 역시 구글 클라우드 플랫폼(GCP) 하에 퍼블릭 클라우드 서비스 및 IaaS 비즈니스를 구축해 나갔다.

그렇다면 이들 세 기업의 클라우드 서비스는 어떤 차이가 있을까? 그리고 어떤 IaaS 플랫폼이 우리 기업에 가장 적합한지를 어떻게 판단할 수 있을까?

기능 및 서비스
클라우드 선택은 결국 개별 고객의 요구, 워크로드 등에 의해 좌우된다. 사실 많은 기관에서는 비즈니스 오퍼레이션별로, 혹은 사용례 별로 각기 다른 서비스를 이용하는 멀티 클라우드 방식을 채택하고 있다.

그렇지만 이러한 기업들의 클라우드 솔루션 도입 방식에도 각각 차이점이 있으며, 이런 차이점을 만드는 요소들을 이해한다면 엔드 유저 입장에서도 어떤 방식이 가장 적합한지를 판단하기 쉬워질 것이다.

AWS, 마이크로소프트 애저, 그리고 구글 클라우드 플랫폼은 유동적인 컴퓨트, 스토리지, 네트워킹과 관련해서는 대체로 유사한 기능을 보인다. 세 서비스 모두 공용 클라우드의 공통적 요소들을 지니고 있다. 셀프서비스와 인스턴트 프로비저닝(instant provisioning), 오토스케일링(autoscaling), 그리고 여기에 덧붙여 보안, 컴플라이언스, 신원 관리 기능 등이 그것이다.

세 기업 모두 클라우드 서비스에 투자를 아끼지 않는 기업들이며 이를 지원할 수 있는 든든한 모기업을 지니고 있다. 덕분에 이들 기업은 좀 더 정교하고 성숙한 애널리틱스 서비스를 제공할 수 있게 되었다. 예를 들어 AWS(엘라스틱 맵 리듀스), 애저(HD인사이트), 구글(Dataproc) 모두 하둡 클러스터를 지원한다.

컴퓨트, 스토리지, 데이터베이스뿐 아니라 애널리틱스, 네트워킹, 모바일, 개발자 툴, 매니지먼트 툴, IoT, 보안, 그리고 기업 애플리케이션에 이르기까지, AWS는 100여 개 분야를 아우르는 가장 폭넓은 서비스를 제공하는 기업이다. 하지만 이는 어느 정도는 AWS가 가장 오래된 시장 참여자이기 때문이기도 하다.

세 업체 모두 머신러닝 툴은 물론 사물 인터넷, 서버리스 컴퓨팅(AWS의 람다(Lambda), 애저 및 구글의 펑션(Functions) 등)과 같은 첨단 기술을 겨냥한 기능들을 추가했다. 고객들은 자신의 요구에 맞는 클라우드를 선택해 모바일 앱을 만들거나, 고기능 컴퓨팅 환경을 조성할 수 있게 됐다.

세 업체 모두 고유의 인터넷 전문성에 기반을 둔 강력한 머신러닝 기능을 제공함은 물론이다.

AWS는 2015년 4월 아마존 머신러닝(Amazon Machine Learning) 서비스를 출시해 개발자들의 머신러닝 모델 생성에 도움을 주었다. 그리고 지난 2016년에는 이미지 인식이 가능한 새로운 머신러닝 서비스(AWS 레코그니션)와 텍스트를 음성으로 변환하는 학습 모델(폴리), 그리고 알렉사를 구동하는 엔진(렉스)을 발표하기에 이르렀다.

구글은 오픈소스 텐서플로(TensorFlow) 딥러닝 라이브러리에 기반하여 머신러닝 모델을 제작할 수 있도록 지원하는 클라우드 머신러닝 엔진(Cloud Machine Learning Engine)을 제공한다. 또한 구글은 자연어 처리, 번역 및 컴퓨터 비전 등의 작업을 위해 규격 API 서비스를 제공하기도 한다.

마이크로소프트의 애저 머신 러닝 스튜디오(Azure Machine Learning Studio)는 알고리즘 작성, 테스트 및 설치를 위한 전문 개발자용 솔루션이자 규격 API를 위한 시장이기도 하다.

요즘 트렌드라 할 수 있는 컨테이너의 인기를 반영하여 세 업체 모두 도커(Docker) 서비스를 지원하고 있다.

세 기업 모두 파트너십을 수용하는 자세를 보이고 이로 인해 고객들 역시 다양한 앱 및 서비스를 자신의 클라우드 환경에서 시험해 볼 수 있다.

구글을 예로 들면 SAP, 피보탈, 랙스페이스와 같은 탄탄한 업체들과의 제휴를 수차례 발표하기도 했다.

컴퓨트, 스토리지, 데이터베이스, 그리고 네트워킹
컴퓨트에서 AWS의 메인 옵션은 EC2 인스턴스다. EC2 인스턴스의 장점은 다양한 옵션을 맞춤 개발할 수 있다는 것이다. 또한 앱 설치를 위한 엘라스틱 빈스톡(Elastic Beanstalk)이나 EC2 컨테이너 서비스, AWS 람다 및 오토스케일링 같은 서비스도 제공한다.

한편 애저의 컴퓨트 옵션은 보다 가상 머신(VM)에 치중해 있으며 클라우드 서비스 및 리소스 매니저 등 클라우드에 애플리케이션을 설치하기 위한 다른 툴도 함께 제공한다.

구글의 확장적 컴퓨트 엔진(Compute Engine)은 구글 데이터 센터의 VM을 제공한다. 빠른 부팅과 지속적인 디스크 스토리지, 그리고 일관된 성능을 보장하며 고객의 요구에 맞춰 유연하게 커스터마이징 할 수 있다.

세 업체 모두 관계형 데이터베이스를 지원하는 것도 공통점이다. 애저의 SQL 데이터베이스, 아마존의 릴레이셔널 데이터베이스 서비스(Relational Database Service), 레드시프트(Redshift)와 구글 클라우드 SQL, 그리고 NoSQL 데이터베이스 및 애저 도큐먼트DB, 아마존 다이나모DB(DynamoDB), 구글 빅테이블(Bigtable) 등이 그것이다.

AWS 스토리지에는 심플 스토리지(Simple Storage, S3), 엘라스틱 블록 스토리지(EBS), 엘라스틱 파일 시스템(EFS), 임포트/엑스포트(Import/Export) 대용량 데이터 전송 서비스, 글레시어(Glacier) 아카이브 백업 및 온-프레미스 환경과 통합되는 스토리지 게이트웨이(Storage Gateway) 등이 포함된다.

마이크로소프트의 서비스에는 핵심 애저 스토리지 서비스, 애저 블롭(Blob) 블락 스토리지, 테이블(Table), 큐(Queue), 파일 스토리지 등이 포함된다. MS 사는 또한 사이트 리커버리(Site Recovery), 임포트/엑스포트(Import/Export), 애저 백업(Azure Backup) 등도 제공한다.

세 기업 모두 전반적으로 훌륭한 네트워킹 기능을 보장하며 자동화된 서버 로드 밸런싱과 온-프레미스 시스템에 대한 연결성을 약속한다.

원문보기: 
http://www.ciokorea.com/news/35680#csidx86dbcd8322f14c39a50155fab59a92c 

서비스 형태의 플랫폼(Platform-as-a-service, PaaS)은 서비스 제공업체가 고객에게 플랫폼을 제공함으로써 고객이 일반적으로 소프트웨어 개발 프로세스에 필요한 인프라를 구축하고 유지할 필요 없이 비즈니스 애플리케이션을 개발, 실행, 관리할 수 있도록 하는 클라우드 컴퓨팅 유형이다.

서비스 형태의 인프라(IaaS), 서비스 형태의 소프트웨어(SaaS)와 같은 다른 클라우드 서비스와 마찬가지로 PaaS는 클라우드 서비스 제공업체의 호스팅 인프라를 통해 제공된다. 사용자는 일반적으로 웹 브라우저를 사용해 PaaS에 접속한다.

Getty Images Bank

PaaS가 제공되는 경로에는 퍼블릭, 프라이빗 또는 하이브리드 클라우드가 있다. 퍼블릭 클라우드 PaaS의 경우 클라우드 제공업체가 서버, 스토리지 시스템, 네트워크, 운영 체제, 데이터베이스 등 애플리케이션을 호스팅하는 데 필요한 모든 주요 IT 구성 요소를 제공하며, 고객은 소프트웨어 개발을 관리한다.

프라이빗 클라우드에서 PaaS는 고객 방화벽 내, 일반적으로 구내 데이터 센터에 소프트웨어 또는 어플라이언스 형태로 제공된다. 하이브리드 클라우드 PaaS는 위 두 가지 유형의 클라우드 서비스를 혼합해 제공한다.

PaaS는 소프트웨어 개발을 위한 조직의 IT 인프라 전체를 대체하는 것이 아니라 애플리케이션 호스팅 또는 자바 개발과 같은 핵심 서비스를 제공한다. 일부 PaaS에는 애플리케이션 설계, 개발, 테스트 및 배포까지 포함되기도 한다. 또한 웹 서비스 통합, 개발 팀 협업, 데이터베이스 통합 및 정보 보안도 PaaS 서비스에 포함될 수 있다.

다른 유형의 클라우드 서비스와 마찬가지로 PaaS 고객은 사용량에 따라 비용을 지불하지만 일부 제공업체는 월 정액 요금제로 플랫폼 및 플랫폼에 호스팅되는 애플리케이션 접근 기능을 제공한다.

PaaS의 비즈니스 혜택과 동력
PaaS의 가장 큰 장점 가운데 하나는 서버와 데이터베이스가 포함된 인프라를 구축하고 유지하느라 시간과 비용을 투자할 필요 없이 새로운 애플리케이션을 만들고 배포하기 위한 환경을 확보할 수 있다는 것이다.

따라서 애플리케이션 개발 및 전달 속도를 높일 수 있고, 이는 경쟁 우위를 얻을 방법을 물색하거나 신속하게 제품을 출시해야 하는 기업에게 큰 이점이 된다.

또한 PaaS는 새 언어와 운영 체제, 데이터베이스 및 기타 개발 기술 사용을 신속하게 테스트할 수 있다. 이를 위한 지원 인프라를 마련할 필요가 없기 때문이다. 아울러 PaaS는 툴을 더 쉽고 빠르게 업그레이드할 수 있게 해준다.

PaaS를 사용하면 엔터프라이즈 소프트웨어 개발자는 애플리케이션에서 클라우드 기술을 사용할 수밖에 없으므로 현대적인 원칙을 받아들이고 클라우드 인프라(IaaS) 플랫폼을 더 잘 활용하게 된다.

PaaS를 사용하는 조직은 애플리케이션 및 데이터를 직접 관리할 수 있으므로 클라우드 인프라 또는 애플리케이션을 사용할 때 자주 거론되는 통제력 상실은 큰 문제가 되지 않는다.

일반적인 PaaS 응용 사례
애플리케이션 개발과 테스트를 위한 호스팅 환경을 제공하는 것은 PaaS의 가장 일반적인
용도 가운데 하나다. 그러나 그 외에도 엔터프라이즈에서 PaaS를 사용하는 이유는 많다.
시장조사 업체 가트너는 다음을 포함한 다양한 PaaS 사용 사례를 언급했다.

API 개발 및 관리 : 기업은 PaaS를 사용해서 애플리케이션 프로그래밍 인터페이스와 마이크로서비스를 개발, 실행, 관리, 보호할 수 있다. 여기에는 새 API 및 기존 API를 위한 새 인터페이스 만들기, 종단간 API 관리가 포함된다.

비즈니스 분석/인텔리전스 : 기업은 PaaS를 통해 제공되는 툴을 사용, 데이터를 분석해서
비즈니스 통찰력과 행동 패턴을 찾아 더 현명한 의사 결정을 내리고 제품의 시장 수요와 같은 미래를 더 정확히 예측할 수 있다.

비즈니스 프로세스 관리(BPM) : 조직은 PaaS를 사용해 다른 클라우드 요소와 마찬가지로 서비스로 제공되는 BPM에 접근할 수 있다. BPM에는 데이터, 비즈니스 규칙 및 서비스 수준 협약을 포함한 프로세스 관리를 위해 필요한 IT 구성 요소가 통합되어 있다.

통신 : PaaS는 통신 플랫폼을 위한 전달 메커니즘 역할도 할 수 있다. 이를 통해 개발자는 음성, 비디오, 메시징과 같은 통신 기능을 애플리케이션에 추가할 수 있다.

데이터베이스 : PaaS 제공업체는 조직 데이터베이스 구축 및 유지와 같은 서비스를 제공할 수 있다. 시장조사 업체 포레스터 리서치는 데이터베이스 PaaS를 “데이터베이스 프로비저닝과 관리를 자동화하고 개발자와 비기술 인력이 사용할 수 있는 안전하고 확장 가능한 주문형 셀프 서비스 데이터베이스 플랫폼”으로 정의한다.

사물인터넷 : IoT는 향후 PaaS 사용에서 큰 부분을 차지할 것으로 전망된다. 다양한 IoT 배포에서 사용될 광범위한 애플리케이션 환경과 프로그래밍 언어 및 툴을 지원하게 된다.

마스터 데이터 관리 : 기업이 소유한 핵심 비즈니스 데이터를 관리하는 프로세스, 거버넌스, 정책, 표준 및 툴을 포괄하며 데이터를 위한 단일 참조 지점(single point of reference)을 제공한다. 이러한 데이터에는 고객 거래에 관한 정보 등의 참조 데이터, 의사 결정을 지원하기 위한 분석 데이터가 포함될 수 있다.

PaaS 기술과 제공업체
PaaS에는 서버, 네트워킹 장비, 운영 체제, 스토리지, 미들웨어, 데이터베이스 등 여러 기본 클라우드 인프라 구성 요소가 포함된다. 이러한 모든 요소는 서비스 제공업체가 소유 및 운영한다.

PaaS에는 개발 툴, 프로그래밍 언어, 라이브러리, 데이터베이스 관리 시스템 및 제공업체의 기타 툴과 같은 리소스도 포함된다.

주요 PaaS 벤더로는 아마존 웹 서비스, 마이크로소프트, 구글, IBM, 세일즈포스닷컴, 레드헷, 멘딕스(Mendix), 허로쿠(Heroku)가 있다. 일반적으로 사용되는 언어, 라이브러리, 컨테이너 및 관련 툴은 대부분 모든 주요 PaaS 제공업체 클라우드에서 사용 가능하다.

이러한 업체들 중 소프트웨어 개발 툴 분야의 선두 제공업체가 여럿 있는 것은 우연이 아니다. 가트너는 현재 약 200개의 PaaS 제공업체가 있는 것으로 추산한다.

PaaS 위험
PaaS는 클라우드 기반 서비스인 만큼 따르는 위험도 다른 유형의 클라우드와 대체로 비슷하다. 정보 보안이 대표적인 예다. PaaS는 네트워크 및 서버와 같은 공유 리소스 사용 개념을 기반으로 한다. 따라서 이 환경에 데이터를 보관하다가 무단 접근 또는 해커 등의 공격으로 인해 이 데이터가 누출될 수 있다는 보안 측면의 위험이 있다.

그러나 다른 한편으로 주요 클라우드 제공업체들은 일반적인 기업 데이터 센터에 비해 이와 같은 유출을 더 효과적으로 차단해왔으며 초기에 많은 IT 전문가들이 우려했던 것과 같은 정보 보안 위험은 발생하지 않았다.

PaaS를 이용하면 기업은 인프라와 운영에 적절한 접근 제어를 비롯해 기타 보안 프로비전 및 정책을 마련하는 작업을 서비스 제공업체에 맡기게 된다. 애플리케이션을 위한 자체 보호 기능을 제공하는 것은 기업의 책임이다.

조직은 특정 서비스 제공업체의 인프라 및 소프트웨어에 의존하므로 PaaS 환경에서는 잠재적인 벤더 종속 문제가 있다. 따라서 IT 부서는 선택하고자 하는 PaaS가 현재와 미래의 IaaS 및 SaaS 환경과 호환되는지 여부를 따져봐야 한다.

PaaS의 또 다른 위험은 서비스 제공업체의 인프라 환경이 어떤 이유로 다운되어 서비스에
영향을 미칠 수 있다는 점이다. 또한 제공업체가 개발 전략, 프로그래밍 언어 또는 기타 영역을 변경할 경우 어떻게 될지도 생각해야 한다.

이러한 장애물로 인해 PaaS 도입이 계속 막히는 것은 아니다. 기업이 프로그래밍에 전념하는 동안 벤더는 플랫폼을 담당하므로 PaaS는 더 높은 유연성을 제공한다. editor@itworld.co.kr

원문보기: 
http://www.itworld.co.kr/news/106437#csidxecb1ddfcd657380a773e1e25abf882a 

잘 정립된 클라우드 컴퓨팅 전략으로 새 시스템을 신속하게 적용하고, 혁신적인 디지털 변혁 전략을 가속화 한 좋은 사례는 많다.



그러나 이러한 성과를 누리려고 시도하기 전에 명심해야 할 명확한 진실 한 가지가 있다. 클라우드 전략을 최대한 효과적으로 활용할 수 있게 만들어지지 않았고, 이런 준비가 돼 있지 않은 워크로드나 인적 자원이 있다는 점이다.

따라서 무턱대고 클라우드라는 소용돌이에 뛰어들면 곤란하다. 그러나 쉬운 일이 아니다. 클라우드는 수많은 장점과 비용 효과성을 약속한다. 이런 장점을 무시하기란 쉽지 않다.

또한 전문 공급업체와 대형 공급업체가 더 우수하고, 빠르며, 저렴한 컴퓨팅을 제공하고 있는데, 굳이 온프레미스로 고성능 애플리케이션을 구현해 유지할 이유가 없다. 아주 간단한 경제적 논리다. 그렇지 않은가?

클라우드 네이티브 애플리케이션은 처음부터 자동 확장성(오토스케일링), 데브옵스, CD(컨티뉴어스 딜리버리) 같은 ‘쿨’한 기능을 십분 활용할 수 있도록 설계되어 있다. 이는 확실히 사실일지 모른다.

많은 기업과 기관이 입을 모아 동의하겠지만, 클라우드 서비스를 이용해 수십 년 동안 축적된 기존 기술에서 초래되는 문제를 신속히 해결할 수 있을지 모른다. 이 또한 크게 구미가 당기는 부분이다. 특히 획일적 애플리케이션 ‘뼈대들’은 다른 사람이 소유한 장소에 놓아두고 싶을 것이다.

그러나 클라우드를 추진하는 의도와 상관 없이, 미흡한 계획과 확실한 정보에 근거를 두지 않은 전략은 비즈니스에 비참한 결과를 초래할 수 있다. 아이러니하게도, 클라우드 모델은 그 특성상 클라우드가 특정 워크로드와 사용 사례에 적합한지 주의를 기울여 판단하지 않을 때 가장 큰 피해를 초래한다.

구입 후 ‘스티커 쇼크(예상보다 비싼 가격으로 인한 충격)’를 경계
거대한 분석 애플리케이션을 퍼블릭 클라우드로 마이그레이션 한다고 가정하자. 이 경우 금전적인 비용 충격에 대비해야 한다. 분석 애플리케이션 같은 메모리 집약적 애플리케이션들은 상당한 메모리 ‘성능’을 요구한다. 기업과 기관이 가장 크고, 값이 비싼 가상 인스턴스를 운영하는 결과가 초래될 수 있다는 의미다.

이런 경우에는 온프레미스 시스템을 조달해 유지하는 것이 더 경제적일 수 있다. 단 향후 퍼블릭 클라우드에 ‘금전적 스위트 스폿’이 생길 수 있다는 점을 유념한다(특히 가격이 계속 하락하고 있기 때문에).

다시 말해 ‘일회성’ 노력이 아니다. 현명한 조직은 클라우드 모델이 목적에 부합하는지 판단하는 동시에, 지속해서 여러 공급업체 전반에 걸쳐 발생하는 금전적 기회를 탐구해야 한다. 이때 중개 모델을 이용해야 할 수도 있다.

방치는 금물!
모든 시스템을 클라우드로 이전하면 응답 시간이 1초 미만이 될 것으로 생각한다면, 다시 생각하기 바란다. 애플리케이션 성능 문제는 짧은 지연 시간과 처리량을 요구하는 서비스를 중심으로 많은 클라우드 서비스의 ‘종말을 알리는 조종’이 될 수 있다.

신뢰도가 높지만 오래된 SQL 데이터베이스와 트랜잭션 워크로드를 새로운 클라우드 기반 컨테이너에 위치시키는 것이 좋은 생각처럼 들릴지 모르겠지만, 클라우드에서 제멋대로 날뛸 수 있다. 특히 지리적 위치나 네트워크 연결이 성능에 미치는 영향을 세밀히 고려하지 않았다면 아주 큰 문제가 될 수도 있다.

또 명심해야 할 부분이 있다. 획일적 애플리케이션은 중복성과 페일오버를 특히 신경 써야 한다. 비용과 복잡성, 관리 부담이 가중될 수 있다는 의미다.

아키텍처 ‘슬럼’을 예방
의심의 여지 없이, 클라우드 기반 애플리케이션 아키텍처는 현대 디지털 비즈니스의 필수 구성 요소다. 그러나 새로운 덮개로 오랜 문제를 가리는 것은 좋지 않다.

도시 계획과 관련된 과거 실수에 비유할 수 있다. 많은 조직이 모든 구형 애플리케이션의 문제들을 클라우드로 그대로 옮기면서 도시 계획처럼 ‘슬럼’을 만드는 실수를 범하고 있다. 일부는 모든 것을 가상화, 컨테이너화한다. 심지어 서버리스 아키텍처를 적용한다. 그러나 이는 문제를 악화시킬 뿐이다.

자동 확장성과 컨테이너 불역성을 십분 활용하기 위해 구형 시스템을 대대적으로 업그레이드하고, 서비스를 분리해야 할 수 있다. 또한 런타임 분리로 문제가 있는 시스템, 즉 오래전에 정리했어야 할 애플리케이션 슬럼의 수명이 연장될 수도 있다.
 
실패문제에 대비한 디자인
클라우드는 확장성과 탄력성이 장점이다. 여기에는 의심의 여지가 없다. 그러나 때론 문제가 발생한다. 2015년 호주 아마존 웹 서비스의 가동이 중단된 사고가 있었다.

시드니를 덮친 폭우가 아마존 웹 서비스의 가용성 존(Availability Zone)을 무너뜨렸다. 여기에 API 호출 문제까지 겹쳐 페일오버에 문제가 발생했다. 이로 인해 일부 기업이 피해를 보았다. 그러나 이런 위기를 극복한 기업도 있었다.

여러 가용성 존의 문제에 대처할 수 있도록 시스템을 디자인하고, 하이브리드 클라우드를 효과적으로 사용한 기업들이다. 이는 잘 정립된 클라우드 아키텍처와 엔지니어링의 중요성을 알려주는 사례이다. 많은 기업이 제대로 인식하지 못하고 있는 부분이다.

클라우드는 비즈니스의 ‘근육’을 키운다. 그러나 꾸준히 힘든 운동을 해야 근육을 유지할 수 있다.

클라우드 전략을 수립하면서 반드시 개선해야 할 부분을 고려해야 한다. 이는 저렴하지 않을 수도, 힘들 수도 있는 부분들이다. 자동화 관련 변경, 관리 측면의 변경, 클라우드 서비스 상호운영 문제, 새로운 툴 요건, 인적자원의 역량 등을 예로 들 수 있다.

클라우드가 열풍이다. 이런 이유로 먼저 발부터 내딛기 쉽다. 그러나 주의를 기울여야 한다. 클라우드 투자는 ‘All or nothing’이 될 수 없다. 현명한 기업과 기관은 주도면밀하게 계획을 세워 접근해야 클라우드가 전달하는 혜택을 실현할 수 있다는 점을 안다. 비즈니스 목표와 성과를 기준으로 다양한 클라우드 모델을 도입하고, 조정하고, 조율하는 기업과 기관이 성과를 일궈낼 것이다.

*Miriam Waterhouse는 호주 연방 정부에서 최고 혁신 책임자 그룹의 전략 부분을 총괄하고 있다. ciokr@idg.co.kr

원문보기: 
http://www.ciokorea.com/news/35569#csidx2c0de5ea391c50ba8c640c97fbaa9cf