실패 없는 클라우드 전환 전략
클라우드 전략 수립의 필요성과 방법
“우리는 비용을 절감하기 위해 클라우드로 이전하는 것이 아닙니다. 비즈니스를 재창조하기 위해 이전하는 것입니다.”
- 다이앤 그린, 전 구글 클라우드 CEO
클라우드를 도입했다는 이유로 혁신이 완성됐다고 생각해서는 안 됩니다. 오히려 클라우드는 도입이 끝이 아니라 시작이며, 새로운 게임의 출발점입니다. 기업은 클라우드를 통해 디지털 및 AI 역량을 높이지만, 동시에 그만큼 더 복잡한 전략을 수립하고 수많은 질문에 끊임없이 답해야 하는 위치에 놓이게 됩니다.
클라우드 여정의 3단계: 전환, 운영, 그리고 고도화
클라우드라는 새로운 게임은 크게 세 가지 단계로 이루어집니다.
- 전환 (Migration): 기존 시스템을 클라우드로 옮기는 과정입니다. 성공적인 전환 전략, 신뢰할 수 있는 파트너, 그리고 우리 회사에 맞는 이전 방식(6R)을 선택하는 것이 핵심입니다.
- 운영 (Operation): 전환 이후, 클라우드 시스템을 안정적으로 운영하기 위한 체계를 수립하고 실제 적용하는 단계입니다. 안정적인 클라우드 운영을 위해 CSP가 제공하는 도구를 활용하고, 보안·계정·모니터링 구조를 설계하며 비용을 관리하는 것이 주요 과제입니다.
- 고도화 (Modernization): 운영을 넘어 클라우드를 기업의 ‘전략적 자산’으로 만드는 단계입니다. FinOps, DevOps 체계를 정립하고 IaC 기반 자동화를 이루는 것은 물론, 궁극적으로 AI 및 빅데이터 기반 구조로 전환하는 것을 포함합니다. 오늘날 많은 기업에게 클라우드 고도화의 최종 목적지는 AI라고 해도 과언이 아닙니다. AI를 비즈니스에 도입하고 활용하기 위해서는 그 데이터를 처리하고 모델을 실행할 클라우드라는 기반이 필수적이기 때문입니다.
이 거대한 여정의 성패는 첫걸음, 즉 ‘전환 전략’을 어떻게 수립하느냐에 달려 있습니다. 이번 화에서는 그 첫 단추를 실패 없이 끼우는 방법에 대해 집중적으로 살펴보겠습니다.
전략, 기술이 아닌 비즈니스 설계에서 시작됩니다
클라우드 전환을 단순히 서버를 옮기는 기술적 작업으로 생각한다면 큰 오산입니다. 성공적인 클라우드 전환은 마치 ‘이사’나 ‘이민’과 같습니다. 단순히 짐을 옮기는 것이 아니라, 어떤 짐은 버려야 하고, 새로운 집에 맞춰 동선과 배치를 완전히 재설계해야 합니다. 마찬가지로 클라우드 전환은 시스템과 조직이 새로운 환경에서 제대로 작동하도록 전체 구조를 점검하고 재정렬하는, 기업 전체의 비즈니스 전환 프로젝트입니다.
현실적으로 대부분의 기업은 현재 IT 환경을 정확히 진단하고, 기술 전환이 비즈니스에 미칠 영향을 계량적으로 설명하기 어렵습니다. 따라서 클라우드 전환은 반드시 외부 전문가(CSP, MSP, 컨설팅 파트너)와의 협업을 통해 전략을 ‘공동으로’ 수립하는 방식에서 시작해야 합니다.
성공적인 전략 수립을 위한 5단계 접근법
클라우드 전환 전략은 통상 다음의 다섯 단계로 구성됩니다. 이 과정은 단순한 문서 작업이 아니라, 내부 이해관계자와 외부 파트너가 함께 ‘실행 가능한 전략’을 만들어가는 과정입니다.
사전 진단(Assessment): 현재 애플리케이션 구조, 인프라 배치, 연동 방식, 데이터 위치, 보안 조건 등을 종합적으로 파악하는 단계입니다. 많은 기업이 이 단계를 통해 처음으로 자신들의 시스템 현황을 명확하게 시각화하게 됩니다.
워크로드 복잡도 평가: 서버 수나 트래픽 양뿐만 아니라, 시스템 연계성, 운영 장애 이력, 기술 부채 등을 분석하여 각 시스템의 전환 난이도를 평가합니다.
마이그레이션 방식(6R) 정의: 평가 결과를 바탕으로 각 시스템을 어떻게 이전할지 구체적인 방법을 결정합니다.
우선순위 및 전환 일정 정의: 기술적 요인과 비즈니스 영향도를 종합적으로 고려하여 전환 순서와 일정을 설계합니다. 이때 기술 논리가 아닌 경영 전략과 맞물려 판단해야 합니다.
변화관리 계획 수립: 전환 이후 바뀔 운영 조직, 보안 정책, 교육 계획 등을 전략 수립 단계부터 설계에 반영해야 합니다.
어떻게 옮길 것인가? 6R 마이그레이션 프레임워크
전환 방식을 결정할 때 가장 널리 쓰이는 기준은 AWS가 제안한 ‘6R 프레임워크’입니다. 이 6R을 통해 기존 인프라를 어떤 방식으로 클라우드로 전환할 것인가를 정의합니다. 향후 전환 작업의 가장 중요한 기반 작업이 됩니다.
Rehost (리호스트): 기존 환경을 코드 수정 없이 그대로 옮기는 방식(Lift & Shift)입니다.
Replatform (리플랫폼): 핵심 구조는 유지하되 DB, 미들웨어 등 일부 구성요소만 클라우드에 맞게 수정하는 방식입니다.
Repurchase (재구매): 기존 온프레미스 제품을 SaaS로 전환하는 것입니다.
Refactor/Re-architect (리팩터/재설계): 애플리케이션 구조를 클라우드 방식으로 완전히 재설계합니다
Retire (폐기): 더 이상 필요 없는 시스템은 사용을 중단하고 제거합니다.
Retain (유지): 전략적, 기술적 이유로 온프레미스에 그대로 유지하는 방식입니다.
[Info Box] Lift & Shift를 넘어서: Lift, Fix & Shift 클라우드 전문가 데이비드 린시컴(David Linthicum)은 단순한 이전(Lift & Shift)을 넘어, 이전 전에 반드시 시스템 구조와 데이터를 정비하는 ‘Fix’ 단계를 포함하는 ‘Lift, Fix & Shift’를 제안합니다. 그의 지적처럼, 클라우드 전환은 단순 이동이 아니라 재설계와 최적화의 연속 과정입니다.
보이지 않는 암초: 특수 시스템 전환 계획하기
모든 시스템이 클라우드로 순탄하게 이사할 수 있는 것은 아닙니다. 어떤 시스템들은 클라우드 환경과 구조적으로 맞지 않아, 전환 과정 전체를 지연시키거나 실패하게 만드는 ‘보이지 않는 암초’가 될 수 있습니다. 전략 수립 단계에서 이러한 시스템을 미리 식별하고 대응 계획을 세우는 것이 매우 중요합니다.
1. P2V (Physical to Virtual): 물리 서버를 클라우드가 이해하는 '소프트웨어'로 변환하기
상세 설명: P2V의 핵심은 이름 그대로 물리 서버(Physical)를 통째로 하나의 가상 머신(Virtual) 이미지 파일로 변환하는 것입니다. 클라우드 환경은 물리적인 하드웨어가 아닌, 가상화된 소프트웨어(VM)를 실행하는 거대한 플랫폼이기 때문에, 물리 서버를 클라우드에 올리려면 먼저 이 '가상화' 과정이 반드시 필요합니다. 하지만 문제는 물리 서버가 저마다 다른 부품과 설정으로 구성된 ‘수제 컴퓨터’와 같다는 점입니다. 특정 네트워크 카드 드라이버, 하드웨어에 맞게 미세 조정된 OS 설정 등은 물리 장비에 강하게 종속되어 있습니다. 이 종속성을 해결하지 않고 그대로 가상화(이미지 변환)를 진행하면, 클라우드라는 표준화된 환경에서 부팅조차 되지 않는 '벽돌 VM'이 만들어질 수 있습니다.
그래서 어떻게 계획해야 할까요? 성공적인 P2V 전환 계획은 두 단계로 이루어집니다. 1단계는 '사전 정제(Cleaning)' 작업입니다. 클라우드 환경에 불필요한 하드웨어 드라이버나 에이전트를 제거하고, OS 설정을 최대한 표준에 가깝게 정리하는 과정입니다. 2단계는 이 정제된 상태를 기준으로 '가상화 이미지 생성'을 진행하는 것입니다. 이렇게 만들어진 깨끗한 VM 이미지가 바로 클라우드로 성공적으로 이관(Rehost)될 수 있는 '입장권'이 됩니다.
2. U2L (Unix to Linux): 유닉스 시스템을 리눅스로 전환
상세 설명: 이는 단순한 OS 변경이 아닙니다. 과거 대기업의 핵심 시스템이었던 상용 유닉스(Solaris, AIX 등)는 대부분 독자적인 CPU 아키텍처(SPARC, POWER 등) 위에서 동작했습니다. 반면, 모든 퍼블릭 클라우드는 x86 아키텍처 기반의 리눅스를 표준으로 삼습니다. CPU 아키텍처가 다르다는 것은 애플 iOS용으로 만든 앱이 안드로이드폰에서 실행되지 않는 것과 같은 원리입니다. 따라서 U2L 전환은 기존 애플리케이션의 단순 이전이 불가능하며, 코드 재작성(Re-write)이나 재설계(Re-architect)가 필요한 매우 복잡하고 어려운 프로젝트입니다.
그래서 어떻게 계획해야 할까요? U2L은 단순 마이그레이션이 아닌, 별도의 '리플랫포밍(Re-platforming)' 또는 '재설계(Re-architect)' 프로젝트로 접근해야 합니다. 기존 애플리케이션의 단순 이전은 불가능하므로, 리눅스 환경에 맞게 코드를 수정하거나 다시 개발하는 과정이 필수적입니다. 따라서 전환 전략 수립 시, U2L 대상 시스템은 일반 전환 프로젝트와 분리하여 별도의 예산, 기간, 인력을 산정하고 상세한 영향도 분석을 반드시 선행해야 합니다.
3. DB 전환 (예: Oracle → PostgreSQL)
상세 설명: 라이선스 비용 절감을 위해 상용 DB를 오픈소스 DB로 전환하는 것은 매력적이지만, 마치 외국어를 번역하는 것만큼이나 섬세한 작업이 필요합니다. 각 DB는 데이터를 저장하는 형식(Data Type), 내장 함수, SQL 문법, 성능 최적화 방식이 모두 다릅니다. 예를 들어, 오라클의 PL/SQL로 작성된 프로시저는 PostgreSQL에서 호환되지 않아 전부 새로 개발해야 합니다. 이런 차이를 무시하고 데이터만 옮기면, 데이터가 깨지거나 애플리케이션에서 심각한 성능 저하가 발생할 수 있습니다.
그래서 어떻게 계획해야 할까요? 핵심은 '사전 영향도 분석과 철저한 검증'입니다. 데이터만 옮기면 된다는 생각은 금물입니다. 전환 계획에는 반드시 ①스키마 구조 변환, ②애플리케이션의 모든 SQL 쿼리 호환성 검증, ③전환 전후 성능 벤치마크 테스트(BMT)가 포함되어야 합니다. 이 검증 과정을 통해 기술적 리스크와 필요한 공수를 사전에 파악하고, 이를 바탕으로 현실적인 전환 일정을 수립해야 합니다. 이 역시 6R 전략 중 리플랫폼(Re-platform)에 해당하는 복잡한 과제입니다.
4. 레거시 OS 환경 (예: Windows Server 2003)
상세 설명: 지원이 종료된(End-of-Life) 구형 OS를 클라우드로 옮기는 것은 매우 위험한 결정입니다. 첫째, 최신 클라우드 가상화 기술이 구형 OS를 지원하지 않을 가능성이 높습니다. 둘째, 더 심각한 문제로, 제조사가 더 이상 보안 업데이트를 제공하지 않기 때문에 치명적인 보안 공백이 생깁니다. 이런 시스템을 인터넷과 연결된 클라우드 환경에 노출하는 것은 해커에게 대문을 열어주는 것과 같습니다. 이는 기술적 문제를 넘어, 기업의 보안 및 컴플라이언스에 중대한 위반이 될 수 있습니다.
그래서 어떻게 계획해야 할까요? 클라우드로 옮기기 전, '업그레이드할 것인가, 새로 구축할 것인가, 아니면 폐기할 것인가'를 먼저 결정해야 합니다. 해당 시스템을 계속 사용해야 한다면, 온프레미스 환경에서 최신 OS로 업그레이드하거나 클라우드 위에 새로운 OS로 시스템을 재구축(Refactor)하는 계획을 먼저 수립해야 합니다. 더 이상 필요 없다면 과감히 폐기(Retire)하는 것이 가장 현명한 전략입니다. '있는 그대로 옮긴다'는 선택지는 처음부터 배제해야 합니다.
5. Non-x86 아키텍처 (예: Power, SPARC)
상세 설명: U2L 전환과 마찬가지로, 근본적인 CPU 아키텍처 불일치가 가장 큰 장벽입니다. 대부분의 퍼블릭 클라우드 인프라는 x86 CPU를 기반으로 합니다. Non-x86 환경에서 개발된 애플리케이션은 x86 환경에서 코드를 처음부터 다시 컴파일하거나 재작성하지 않는 한 실행 자체가 불가능합니다.
그래서 어떻게 계획해야 할까요? 이 경우 기술적 해결책은 거의 없습니다. 대신 '비즈니스적 결단'이 필요합니다. 전환 계획은 기존 시스템을 폐기(Retire)하고, 유사한 기능을 제공하는 최신 SaaS를 새로 구독(Repurchase)하는 방향으로 수립하는 것이 가장 현실적입니다. 만약 해당 애플리케이션이 비즈니스에 필수적이라면, 클라우드 네이티브 환경에 맞춰 완전히 새로 개발(Refactor)하는 장기적인 프로젝트로 전환해야 합니다.
전략 수립은 여정의 시작일 뿐
지금까지 살펴본 전략 수립 과정은 클라우드 전환의 끝이 아니라 시작입니다. 이렇게 만들어진 전략 문서는 이후 CSP 및 MSP 선정, 실행계획 수립, 운영체계 설계의 튼튼한 기초가 됩니다.
이제 탄탄한 전략이라는 지도를 손에 쥐었으니, 다음 화에서는 실제 마이그레이션을 수행하고 안정화하는 ‘실행’의 세계로 떠나보겠습니다.
브런치북의 글쓰기 에디터의 기능적인 한계로 (아니면 제가 쓰는 방법을 모르던가) 말로 길게 설명할 수밖에 없어 죄송합니다. 긴 글 읽으시느라 고생하셨습니다.
