클라우드 마이그레이션, 5가지 성공법과 5가지 실패 공식

대부분의 기업에 클라우드로의 마이그레이션은 더 이상 할 것인가 말 것인가의 문제가 아니라 ‘언제’ 할 것인가의 문제다. 클라우드로 애플리케이션을 옮기면 보안, 데이터 액세스, 확장성, IT 유연성을 개선할 수 있고 비용도 절감된다.
 
그러나 주의할 점도 있다. 모든 클라우드 배포가 매끄럽게 진행되지는 않는다. 마이그레이션에 예상보다 많은 시간이 걸리거나 마이그레이션이 완전히 실패해서 시간과 비용의 낭비로 이어지는 경우도 많다. 앱을 클라우드로 옮긴 후에 이전만큼 잘 작동하지 않는 경우도 드물지 않게 발생한다.
 
그 결과 다시 데이터센터로 되돌리는, 또 다른 마이그레이션이 발생하기도 한다.
 
보안 업체 포티넷(Fortinet)이 후원하고 공급망 전문 기업 IHS 마킷(IHS Markit)이 실시한 최근 연구 결과를 보면 설문 대상 기업의 74%는 기대한 혜택을 달성하지 못한 후 클라우드 기반 앱을 온프레미스로 되돌렸다.
 
이와 같은 문제가 새로운 것은 아니다. 구글에서 클라우드 마이그레이션 실패를 검색하면 몇 년 전부터 실패 사례를 찾아볼 수 있다. 문제는 기술의 실패가 아니라 리더십의 실패다.
 
클라우드 마이그레이션 실패의 5가지 주요 이유, 그리고 성공하기 위해서 할 수 있는 일을 살펴보자.
 

클라우드 마이그레이션 실패 #1: 유능한 파트너의 부재

첫 단계는 혼자서 할 수 없음을 인정하는 것이다. 특히 시작하는 단계에서는 더욱 그렇다. 액센추어와 같은 글로벌 전문 서비스 기업이든 지역 컨설팅 기업이든 파트너가 필요하다. 파트너를 결정할 때는 신중을 기해야 하며 외부의 의견도 구해야 한다. 적절한 컨설턴트를 선택하는 데 도움을 줄 수 있는 동종 업계와 지역의 인맥을 활용하는 것이 가장 좋다.
 
엔터프라이즈 애플리케이션 컨설팅(Enterprise Application Consulting)의 회장인 조슈아 그린바움은 “파트너를 신중하게 선택해야 한다. 기술적 역량뿐만 아니라 변화 관리 역량도 갖추고 프로세스를 안내할 수 있는, 레퍼런스가 풍부한 파트너가 필요하다”고 말했다.
 
유능한 클라우드 마이그레이션 전문가는 이전에 가장 적합한 애플리케이션을 파악하고 레거시 시스템과 클라우드 서비스를 통합할 방법을 결정하고 마이그레이션을 계획, 실행하는 데 도움을 줄 수 있다. 또한 좋은 파트너는 효과적인 하이브리드 또는 멀티 클라우드 전략을 수립하는 데도 도움이 된다.
 

클라우드 마이그레이션 실패 #2: 클라우드 적응 실패

기업이 가장 흔히 저지르는 실수 중 하나는 온프레미스에서 하던 방식 그대로 클라우드에서 앱을 실행하는 것이다. CIO 컨설팅 업체인 아보아(Avoa)의 회장 팀 크로포드는 “심각하고 흔한 실수”라고 말했다.
 
크로포드는 “온프레미스 앱은 리소스를 최대치로 소비하는 데 익숙하다”면서 “클라우드는 필요할 때 리소스를 사용하고 필요 없을 때 다시 돌려주도록 설계됐다. 그러나 전통적인 앱은 클라우드를 활용하기 위한 수준의 자율성과 오케스트레이션을 갖추지 못했다”고 말했다.
 
기업은 퍼블릭 클라우드에서는 비트 하나 단위까지 계측되어 비용이 청구된다는 사실을 망각하는 경우가 많다. 그래서 클라우드에 맞게 수정되지 않은 앱을 그대로 실행해 컴퓨팅 사이클을 소비하도록 하고, 다음 달에 청구서를 받아보고 나서야 상황을 파악한다. 단순히 앱을 들어내 클라우드로 가져다 놓기만 해서는 최소한 청구서 충격을 피할 수 없고, 최악의 경우 온프레미스로 되돌아가게 된다.
 

클라우드 마이그레이션 실패 #3: 적절한 내부 스킬의 부재

구식 스킬과 접근 방법(ITIL 프레임워크, 폭포수 프로세스, 모놀리식 애플리케이션, 운영 사일로 등)으로 퍼블릭 클라우드, 나아가 하이브리드 클라우드까지 관리할 수 있다고 생각한다면 단단한 오산이다.
 
동적 인프라, 컨테이너, 자동화, 마이크로서비스 등을 관리하기 위한 스킬이 필요하다. 문제는 다른 모든 기업도 마찬가지라는 것이다! 새로운 기술이 도움이 되지만 숙련된 인력의 채용과 교육, 재교육은 여전히 중요하다.
 
분석 업체 스플렁크(Splunk)의 최고 기술 고문인 앤디 맨은 “클라우드 운영 모델은 독립형 온프레미스 레거시 툴과 제품군을 사용하는 전통적이고 정적인 모놀리식 소프트웨어 관리에서, 일반적으로 여러 클라우드 기반 포인트 솔루션을 통해 관리되는 고도로 분산되고 동적이고 세분화되고 추상화된 서비스로 IT 환경을 바꾼다”면서 “IT는 클라우드 플랫폼과 컨테이너, 마이크로서비스, API, SaaS 시스템 등을 스스로 관리하기 위한 새로운 스킬을 갖춰야 한다”고 말했다.
 

클라우드 마이그레이션 실패 #4: 이해당사자 배제

프로젝트에는 철저한 거버넌스가 필요하다. 이 말은 클라우드로의 전환에 따라 영향을 받는 모든 사람이 관여해야 함을 의미한다. 그러나 IT 부서가 프로젝트를 이끌고 프로젝트가 끝난 뒤에 그 영향을 받는 사람에게 이야기하는 경우가 많다.
 
그린바움은 “이런 경우가 보통 생각하는 것보다 훨씬 더 흔하다. 대부분은 기본적인 프로젝트 관리에 해당된다. 즉, 적절한 사람이 운영 위원회에 참여하고 적절한 정보를 받도록 하는 것이다. 그러나 해당 직원을 뒤늦게 불러들이는 경우가 많다”고 말했다.
 
그린바움이 최근 경험한 사례는 클라우드로의 전환 과정에서 고객이 접하는 환경을 대폭 변경한 한 기업이다. 이 기업은 변화가 공급망에 미치는 영향을 고려하지 않은 탓에 공급망 부서를 과정에서 배제했다. 공급망 그룹은 마이그레이션이 완료된 뒤에야 무슨 일이 일어났는지 알게 됐고 개편에 따른 새로운 요구사항을 충족할 수 없었다.
 

클라우드 마이그레이션 실패 #5: 비현실적인 기대

클라우드로의 이전은 속도, 민첩성, 비용 절감, 전략적 집중, 확장성, 도달 범위 등 여러 가지 측면에서 큰 혜택을 줄 수 있지만 그에 따르는 위험도 있다. 클라우드에서 최대한의 이득을 얻기 위해서는 우선 과장된 이야기에 현혹되지 말고 달성할 수 있는 부분과 잠재적인 새로운 위험, 두 가지 모두에 대해 현실적인 기대치를 설정해야 한다.
 
경영진은 클라우드를 통한 비용 절감을 기대하지만 그 기대대로 되지 않는 경우도 있다. 특히 이 목록의 #2 실패에 해당하면서 애플리케이션을 재설계하지 않는 경우 비용 절감 효과를 얻기 어렵다. 또한 클라우드 도입 기업은 인접 영역에서의 작업이 훨씬 더 줄어들 것이라고 기대하는 경우가 많지만 클라우드 인프라는 IT 인력이 아니라 서버를 대체할 뿐이다.
 
클라우드로 전환하면 모든 DBA, 보안 운영자, 서비스 데스크 엔지니어, 기타 소프트웨어 전문가가 모두 필요 없게 될 것이라고 기대하면 안 된다. 또한 대다수 엔터프라이즈가 그렇듯이 하이브리드 클라우드를 운영한다면 계속 보유할 물리적 자산에 대한 하드웨어 지원도 여전히 필요하다.
 

클라우드 마이그레이션 성공을 위한 단계 #1: A 팀을 투입하고 파트너에게도 A팀을 요구하라

클라우드 서비스에 대한 수요는 공급을 앞질러 가고, 숙련된 적격 인력은 부족하다. 그린바움은 인력 부족으로 인해 프로젝트가 제대로 진행되지 않는 경우를 많이 봤다고 말했다.
 
그린바움은 “프로젝트가 성공하는 경우를 보면 고객 스스로 A팀을 투입하고, 시스템 통합업체에도 똑같이 A팀을 투입할 것을 요구한다”면서 “최고 인력을 투입하지 않으면 결과의 품질도 뒤떨어질 가능성이 높다”고 말했다.
 

클라우드 마이그레이션 성공을 위한 단계 #2: 클라우드로 이전할 대상을 까다롭게 선정

기업이 지금도 흔히 저지르는 실수는 클라우드에 적합하지 않은 부분까지 모든 것을 클라우드로 옮기는 것이다. 크로포드는 가장 표준적인 비즈니스 앱은 클라우드에 두고 고유한 코드는 내부에 두라고 말했다.
 
크로포드는 “이메일, 일정 관리, ERP, HCM 등 비즈니스를 차별화하는 요소가 아니라면 클라우드로 옮기는 것이 좋다. 핵심 백 오피스 기능은 중요하고 필요하지만, 그것이 경쟁사와 차별화된 지적 재산인가 묻는다면 답은 아니다. 이런 요소는 클라우드로 옮기는 편이 유리하다”고 말했다.
 

클라우드 마이그레이션 성공을 위한 단계 #3: 혁신과 차별화

어떤 경우든 클라우드에 맞게 앱을 리팩터링해야 하므로 이를 새로운 방법론과 설계를 포용할 기회로 여겨야 한다. 최대한 많은 온프레미스 앱의 아키텍처를 필요에 따라 탄력적으로 확장/축소되는 클라우드 네이티브 설계로 재편하라. 앱을 컨테이너화해서 도커에서 실행되고 쿠버네티스로 관리되도록 하라. 모든 주요 클라우드 업체는 온프레미스와 클라우드에서 모두 쿠버네티스와 관련된 부분을 지원하는 서비스를 제공한다.
 
맨은 “내가 아는 가장 성공적인 조직은 단순하 복제에 그치지 않고, 근본적으로 다른 클라우드의 속성을 사용해서 혁신하면서 이전에는 하지 못했던 새로운 프로토타입을 제공하고 고객의 기대를 뛰어넘는 수준의 서비스를 제공하고 새로운 시장을 위해 새로운 방식으로 새로운 애플리케이션에 접근하는 조직”이라고 말했다.
 

클라우드 마이그레이션 성공을 위한 단계 #4: 응집력 있는 전략 마련

전략적으로 클라우드에 접근한다는 말은 예산, 조직, 프로세스, 스킬, 보안, 데이터 통합 등을 재고한다는 의미다. 기술은 전체 그림에서 작은 부분이지만 응집력 있는 전략이 빠르게 흐트러질 수 있는 영역이다. 성공적인 마이그레이션을 위해서는 무엇을 온프레미스에 남겨두고 무엇을 옮길 것인지, 어떤 플랫폼을 유지하고 버릴 것인지, 클라우드의 혜택을 이용하기 위해 어떻게 애플리케이션을 리팩터링할 것인지에 관한 현명한 의사 결정이 필요하다. 공통 컴퓨팅, 스토리지, 데이터베이스 플랫폼을 기반으로 표준화함으로써 관리 및 운영의 복잡성과 비용을 낮출 수 있다.
 
간소함을 유지한다는 것은 지나치게 복잡한 마이그레이션, 능력을 넘어서는 과욕을 방지한다는 것도 의미한다. 프로젝트의 범위가 지나치게 넓거나 시간 또는 예산이 너무 부족한 경우 문제가 발생한다. 한꺼번에 모두 하면 안 된다. 프로젝트를 여러 단계로 분할하고 한 번에 하나씩 진행해야 한다. 반복적인 데브옵스 스타일의 접근 방식을 도입하라. 한 부분을 실행해서 작동하는지 확인한 후 프로젝트의 다음 부분에 착수해야 한다.
 

클라우드 마이그레이션 성공을 위한 단계 #5: 새로운 데이터 모델 고려

클라우드로의 마이그레이션은 완전히 새로운 데이터 모델에 대한 기회를 의미한다. 데이터를 클라우드에 두면 훨씬 더 범위가 넓은 데이터 모델로 확장할 기회가 생긴다. 예를 들어 더 고객 중심의 모델로 전환한다는 것은 곧 많은 다양한 소스에서 더 많은 데이터를 가져온다는 의미다.
 
오래된 온프레미스 데이터의 고객 정보는 이름, 주소와 같은 단순한 정보인 경우가 많지만 새로운 클라우드 데이터는 소셜 미디어, IoT 디바이스를 비롯한 여러 소스에서 정보를 가져올 수 있다. 또는 완전히 다른 데이터 분석 플랫폼으로 마이그레이션할 수도 있다. 아마존 레드시프트(Redshift)는 포스트그레SQL과 호환되지만 구글 빅쿼리(BigQuery)는 일반적인 SQL이나 포스트그레SQL과는 다른 형식을 사용한다. 또한 스노우플레이크(Snowflake)는 반구조적 데이터를 위한 다양한 형식을 지원한다.
 
그린바움은 “원칙적으로 비즈니스 방식을 바꾸는 것이므로 데이터에서 필요한 것도 다르다. 데이터 품질의 변화는 다른 무엇보다 정치적인 의사 결정이다. 단순히 데이터를 클라우드에 둔다는 단순한 문제가 아니라, 진정한 변화 관리 문제가 된다”고 말했다. editor@itworld.co.kr