[데이터넷] 많은 기업들이 경쟁력 확보를 위해 클라우드 도입을 추진하고 있지만, 변화 관리에 신경을 쓰지 못해 불필요한 비용 낭비와 조직적인 저항에 직면하기도 한다. 클라우드 도입은 단순히 IT 환경의 변화만을 의미하는 것이기에 비용 관리·보안·운영 등 여러 체계가 바뀌어야 하며, 이러한 준비를 위해서는 전문 파트너사의 도움이 필요하다. 클라우드 마이그레이션을 위해 준비해야 할 사항들을 알아본다. <편집자>

우리나라에서 클라우드가 기술 트렌드로 본격 자리를 잡기 시작한 것은 2016년 아마존웹서비스(AWS)가 한국에 서울 리전을 만들면서부터다. 그 전에는 글로벌 서비스를 제공하거나 세계 각지에 지사를 가지고 있는 일부 엔터프라이즈들을 중심으로 사용되고 있었는데, AWS 서울 리전은 클라우드 사용 확산의 도화선이 됐다.

2016년에는 AWS뿐만 아니라 애저(Azure)도 한국 리전을 오픈했다. 이후 IBM 소프트레이어(Softlayer)도 한국에 센터를 오픈하며 한국 진출을 가속화한다. 이렇듯 2016년은 대한민국 클라우드 역사의 시작을 알리는 해였다고 해도 과언이 아니다.

클라우드의 확산은 그동안 한정적인 인프라 자원 환경에서 가능하지 않았던 대규모 분석 플랫폼 구축, 머신러닝을 활용한 기술 혁신, 사물인터넷(IoT) 등 수많은 기술 혁신을 가능하게 하고 있다. 이런 기술 혁신은 디지털 트랜스포메이션으로 정의되는 기업의 근본적인 체질 개선의 원동력이 됐으며, 그동안 클라우드를 관망하던 대다수의 기업들을 클라우드로 끌어들이는 계기가 됐다.

2016년 이후 불과 4년 만에 클라우드는 대한민국에서 거의 모든 기업의 핵심 키워드가 됐으며, 대부분의 기업들이 클라우드 도입(Cloud Adoption)을 얘기하고 있다. 클라우드의 도움 없이는 다른 기업에게 뒤쳐질 수밖에 없기 때문이다.

IT 둘러싼 모든 환경 변화 요구
클라우드의 도입은 클라우드 마이그레이션(Cloud Migration), 즉 기존 레거시 시스템을 클라우드로 어떤 형태로든 옮겨가는 것으로부터 시작된다. 온프레미스로 표현되는 기존의 IDC 환경에서 구동되던 기업의 IT 서비스를 클라우드에서 동작하게 만드는 과정이 마이그레이션이다.

그동안 선구적으로 클라우드 마이그레이션을 진행했던 기업들은 대부분 공통적인 오류를 겪었다. IDC에서 IDC로의 전산 시스템 이전, 혹은 베어메탈에서 기동되던 전산 시스템을 가상화된 환경으로 변경하는 정도의 단순 IT 기술 변화로 생각하고 변화 관리에 신경 쓰지 못했기 때문이다. 그 결과 많은 시행착오를 겪을 수밖에 없었고, 불필요한 비용 낭비와 조직적인 저항에 직면한다.

2016년 클라우드가 본격적으로 대한민국에 뿌리내리기 시작한 이후 5년 동안 선구적으로 클라우드를 도입한 선도 기업들의 경험을 통해 우리는 클라우드 마이그레이션은 대단히 많은 준비 과정과 변화 과정이 필요함을 배우고 익힐 수 있었다.

클라우드의 도입은 단순히 IT의 변화만을 의미하는 것이 아니며 조직, 문화, 기술, 거버넌스 등 IT를 둘러싸고 있는 거의 모든 환경의 변화를 필요로 한다. 비용 관리 체계가 바뀌어야 하고, 보안 체계와 운영 체계도 바뀌어야 한다. 그러기 위해서는 기술 변화와 경영진의 마인드 변화가 필요하다. 이러한 준비가 선행돼야 클라우드 도입에 따른 혼란과 혼선을 피할 수 있다.

상태 점검부터 표준 수립까지
마이그레이션은 그 행위 자체뿐만 아니라 마이그레이션 수행 전에 필요한 준비 과정에 공을 들여야 하며, 크게 세 가지로 요약할 수 있다.

첫 번째 과정은 기업의 클라우드 도입 준비 상태를 점검하는 단계다. 기업의 현재 상태를 점검해서 클라우드 도입을 위해 보완이 필요한 영역을 식별하고 가이드를 제공한다. 이 과정을 통해 기업은 베스트 프랙티스와 현재 기업의 AS-IS 상태가 어느 정도 차이(gap)가 나는지, 그리고 어떤 준비가 필요한지 확인할 수 있다.

기업의 AS-IS 분석에 사용되는 것이 CAF(Cloud Adoption Framework)다. CAF는 IT 기술뿐만 아니라 비즈니스 환경, 구성원들의 상태, 운영 및 보안 상황, IT 거버넌스 등의 전반적인 분야에 대해서 클라우드 적합도를 평가 분석하는 도구다. AWS나 애저, 구글 클라우드 플랫폼(GCP) 등 클라우드 벤더마다 약간씩 다른 형태를 띠고 있지만 조직의 클라우드 성숙도를 평가하는 프레임워크라는 공통점을 갖고 있다.

두 번째 과정은 클라우드 마이그레이션의 대상을 선별(Scoping)하고, 마이그레이션 방법을 결정(Strategy)하며, 대체적인 마이그레이션 절차를 조율(Stepping)하는 단계이다. 모두가 ‘S’로 시작한다고 해서 ‘3S’라는 표현을 사용한다.

이 단계에서는 기업의 AS-IS 운영 시스템을 면밀히 분석해서 클라우드로 마이그레이션하는 것이 적당한 워크로드를 구분하는 것이 핵심이다. 구분이 끝나면 이른바 6R로 표현되는 리호스트(Rehost), 리플랫폼(Replatform), 리팩터(Refactor) 등의 방법 중에 어떤 방법이 해당 워크로드를 마이그레이션하는데 가장 적합한 방법인지 전략을 수립한다. 마이그레이션에 주어진 시간 및 자원, 그리고 조직의 기술 수준 등이 복합적으로 작용해 전략 수립에 사용된다.

조율은 클라우드 이전 대상의 이전 절차를 조율하는 단계를 의미한다. 마이그레이션 수량이 많지 않다면 한 번에 마이그레이션하는 것도 가능하겠지만, 대부분의 경우 수백 대에서 수천 대 이상의 시스템을 클라우드로 마이그레이션하게 된다. 이렇게 수량이 많은 경우에는 순서를 정해서 절차대로 마이그레이션을 진행해야 서비스 품질을 유지하면서 투입되는 리소스를 최적화하는 것이 가능하다.

세 번째 과정은 클라우드 채택을 위한 표준을 수립하는 단계다. 클라우드 리소스 관리에 대한 표준을 수립하고, 운영 방법과 보안 설정 방법 등을 거버넌스화한다. 클라우드 운영 관리를 위한 표준 기술 세트(Set)를 정의하고 기존 IT 인력들이 클라우드 기술을 체득하기 위한 절차 및 방법을 가이드한다. 그리고 클라우드 도입을 주도적으로 진행할 조직 체계를 컨설팅하게 된다.

클라우드 도입의 초기 성공 여부는 CCoE(Cloud Center of Excellence)로 표현되는 주도 조직의 굳건함에 달려있다고 해도 과언이 아니다. 표준 수립 과정의 핵심은 이른바 랜딩 존(Landing Zone)으로 불리는 가상의 데이터센터 환경을 설정하는 부분이다. 랜딩 존에 운영 모델과 보안 모델이 자연스럽게 스며들어야 한다.

더불어 기업의 AS-IS 서비스들이 무리 없이 클라우드 연착륙할 수 있는 환경이 제공돼야 한다. 그래서 표준 수립에서 가장 중요한 영역은 CCoE와 함께 랜딩 존을 꼽을 수 있다.

전문 지식·경험·노하우 필요
표준 수립 단계에서 빼놓을 수 없는 것이 마이그레이션 프로젝트에 대한 계획이다. 어느 부서가 마이그레이션을 주도할 것이며, 어떤 파트너와 프로젝트를 진행할 것인지, 그리고 마이그레이션에 허용된 시간과 마이그레이션 수량을 고려한 리소스 확보, 그에 따른 예산 수립 등이 프로젝트 실행을 위해 계획 단계에서 고민돼야 하는 사항이다.

클라우드 마이그레이션은 인프라(Infra) 마이그레이션이 중요한 것이 아니라 서비스를 구성하는 애플리케이션과 데이터가 이전되는 것이 핵심이기 때문에, 애플리케이션 소유자가 마이그레이션 프로젝트에 깊숙이 참여하는 것이 반드시 필요하다. 따라서 마이그레이션 프로젝트의 구성원은 비즈니스 소유자와 애플리케이션 소유자, 인프라 소유자 등이 한 팀으로 구성돼야 변화 관리가 용이하다.

이상 세 가지 과정이 완료되면 이제 마이그레이션을 시작할 준비가 완료된 것이다. 앞에서 생성한 랜딩 존에 6R 전략을 사용해서 조율한 단계에 맞춰 마이그레이션을 진행한다. 이 과정은 대단히 일상적인 작업이기에 마이그레이션 팩토리(Migration Factory)라는 용어를 사용해서 마이그레이션 전 과정을 표현한다.

이는 요즘 유행하고 있는 애자일(agile) 방법을 활용해서 스프린트(Sprint) 단위로 진행하는 것이 일반적이다. 스프린트를 반복하다 보면 마이그레이션 대상 서버를 모두 클라우드로 이전할 수 있다.

일상적인 작업이라고 표현했으나 이 단계 역시 고도의 전문성이 필요한 것이 사실이다. AS-IS 시스템 환경을 정확하게 분석해서 클라우드로의 이전에 장애물이 될 수 있는 부분을 사전에 식별하고 적절히 대응함으로써 클라우드로 이전하고 난 후에도 정상적으로 서비스가 제공될 수 있도록 하는 것이 핵심이다. 이를 위해서는 전문적인 지식과 경험, 노하우가 반드시 필요하며, 믿을 수 있는 파트너가 필요하다.

앱 소유자도 프로젝트에 참여
클라우드 마이그레이션이 쉽지 않은 이유는 애플리케이션 단의 변경이 필요하기 때문이다. 클라우드로 애플리케이션이 마이그레이션되면 애플리케이션을 구성하는 호스트의 IP가 바뀌는 것이 일반적이다. 호스트의 IP가 바뀐다는 것은 어쩔 수 없이 애플리케이션 단의 변경이 필요함을 의미한다. 개발 조직의 성숙도에 따라 애플리케이션 변경의 범위가 달라지지만, 최악의 경우 애플리케이션 코드를 한 줄씩(line by line)으로 읽어서 하드 코딩된 IP를 찾아야 할 수도 있다.

앞서 마이그레이션 프로젝트 팀에 애플리케이션 소유자가 반드시 포함돼야 한다고 이야기했던 이유가 바로 여기에 있다. 만약 애플리케이션 수정에 제3자를 동원할 경우, 현행 개발 방법론에 대한 분석과 AS-IS 소스코드에 대한 분석에 불필요한 리소스가 낭비될 수 있으며, 이러한 낭비는 곧 프로젝트 기간 지연 및 비용 상승을 초래한다. 따라서 불가피한 경우가 아니라면 애플리케이션을 개발했거나 운영 중인 개발자를 활용하는 것이 위험을 줄이면서 효과적으로 프로젝트를 수행할 수 있는 방법이다.

앞서 6R은 모두 ‘R’로 시작하는 마이그레이션 패턴이라고 밝힌 바 있다. 마이그레이션 패턴에 대한 정의는 클라우드 벤더별로 조금 상이하다. 그러나 의미하는 바는 비슷하다. 이번 글에서는 주로 AWS의 관점에서 마이그레이션 패턴을 얘기하고자 한다.

마이그레이션 패턴은 AS-IS 형상을 거의 변경 없이 옮기는 패턴과 AS-IS 형상의 OS나 웹(WEB), WAS, DB 등을 변경해서 옮기는 패턴, AS-IS 형상에 대해서 전면적인 재개발을 진행하는 패턴 등이 있을 수 있다. 변경 없이 옮기는 패턴을 ‘리프트 앤 시프트(Lift & Shift)’, ‘리호스트’라 칭하고, 일부 수정해서 옮기는 패턴을 ‘리프트 & 셰이프(Lift & Shape)’, ‘리플랫폼’이라 칭한다. 애저의 경우에는 리플랫폼이라는 용어 대신에 ‘리팩터’ 혹은 ‘리아키텍트’라는 용어를 사용한다.

전면적인 재개발은 AWS의 경우 리팩터라는 용어를 사용하고 애저의 경우에는 리빌드(rebuild)라는 용어를 사용한다. 전면적인 재개발에는 클라우드 네이티브(Cloud Native) 기술을 적용하는 것이 일반적이다.

리프트 & 시프트라는 표현 때문에 리호스트라는 마이그레이션 패턴을 사용할 경우 애플리케이션 수정이 필요 없는 것으로 착각할 수 있다. 물론 수정 없이 마이그레이션하는 것도 불가능하지는 않다. 그러나 항상 가능한 것은 아니기 때문에 리호스트의 경우에도 애플리케이션 소스코드 혹은 애플리케이션 구성 정보가 변경되는 것이 일반적이다. 따라서 마이그레이션 패턴 전 과정에 애플리케이션 소유자의 개입은 필수적이다.

기능·성능 점검 필수
거의 모든 엔터프라이즈 기업들은 x86 이외의 호스트 머신을 보유하고 있고, 마이그레이션 대상으로 해당 머신들도 포함되는 것이 일반적이다. 그런 머신들은 대부분 AIX나 HPUX 등의 유닉스(Unix) 장비들이 대부분이다.

유닉스 장비들을 마이그레이션하기 위해서는 U2L(Unix-to-Linux) 과정을 거치게 된다. 스크립트 언어를 사용해서 애플리케이션을 구성했다면 U2L의 난이도가 그렇게 높지 않다. 그러나 컴파일 언어로 구성된 애플리케이션은 사정이 조금 다르다. U2L 과정에서 소스코드에 대해 컴파일을 새로 해야 하고, 그 과정에서 발생하는 컴파일 에러를 잡아야 한다. 컴파일 에러를 다 잡았다고 해서 애플리케이션이 정상적으로 작동할 것으로 100% 확신할 수는 없다. 언제든지 런타임 에러가 발생할 수 있기 때문이다.

제3의 업체를 동원해서 이러한 과정을 진행할 수 있지만 이 과정이 원활히 진행되기 위해서는 애플리케이션 소유자의 통찰력과 적극적인 협조가 반드시 필요하다.

인프라 및 애플리케이션, 데이터에 대한 마이그레이션이 완료된 후 반드시 진행해야 하는 것이 애플리케이션 기능 점검과 성능 점검이다.

변경 사항이 거의 없이 이관되는 리호스트의 경우에는 AS-IS 환경의 서버 스펙을 고려해서 TO-BE 환경을 설계하기 때문에 기술적으로 성능 점검이 필요하지 않을 수 있다. 그러나 리플랫폼이나 리팩터 형태의 부분 변경 혹은 전반적인 변경은 반드시 성능 점검을 통해 TO-BE 애플리케이션의 성능 및 가용성을 확인할 필요가 있다.

특히 U2L의 형태로 진행된 마이그레이션에 대해서는 반드시 성능 테스트가 진행돼야 한다.

클라우드 벤더 인증 파트너 도움 받아야
여기까지 마이그레이션을 위한 준비 과정과 마이그레이션 과정, 마이그레이션 이후 필요한 과정까지를 대략적으로 살펴봤다. 애플리케이션을 옮기는 것이 핵심이라고 언급했기 때문에 마치 애플리케이션 개발자들만 있으면 마이그레이션이 원활히 진행된다고 오해할 수도 있겠지만, 대규모로 진행되는 마이그레이션은 기술적인 위험과 절차적인 위험이 예측 불가능한 곳에 산재해 있는 쉽지 않은 작업이다. 이러한 위험을 회피하거나 극복하기 위해서는 클라우드에 대한 깊이 있는 지식과 다양한 환경에 대한 마이그레이션 경험이 있어야 한다.

기업이 이러한 기술과 경험을 내재화하는 것은 쉬운 일이 아니기 때문에 마이그레이션은 숙련된 클라우드 마이그레이션 파트너와 함께 진행하는 것이 좋다. 마이그레이션 파트너를 선정할 때 첫 번째로 고려할 부분은 해당 파트너가 스타트업부터 엔터프라이즈 기업에 이르기까지 다양한 마이그레이션 경험을 보유하고 있느냐는 것이다. 수십 대를 대상으로 하는 마이그레이션과 수천 대를 대상으로 하는 마이그레이션은 계획과 수행 절차 면에서 많이 다르기 때문이다.

더불어 해당 파트너가 내부적으로 표준화된 마이그레이션 프레임워크와 노하우를 갖추고 있는 전문 인력을 확보하고 있느냐도 고려사항이다. 마이그레이션 프로젝트는 결국 사람과 사람이 한 팀으로 어우러져 진행되는 인간 중심적 프로젝트이기 때문이다.

AWS를 포함한 클라우드 벤더들은 기업 고객들의 클라우드 파트너 선정에 대한 고민을 해소하기 위한 차원으로 파트너 인증 제도를 운영하고 있다. 고객들은 클라우드 벤더가 인증한 파트너를 선택함으로써 필요한 기술과 경험을 갖추고 있는 파트너를 쉽게 찾을 수 있다.

AWS는 마이그레이션 컴피턴시(Migration Competency)라는 마이그레이션 파트너 인증 체계를 가지고 있다. 인증된 마이그레이션 파트너는 ‘AWS 파트너 네트워크’ 사이트를 통해 검색 가능하다.