VM 마이그레이션 그 이상의 가치: 리프트 앤 시프트(lift-and-shift) 이후의 단계

저는 인프라 팀들과 이런 대화를 수없이 많이 나눴습니다. 그들은 구형 하이퍼바이저에서 VM(가상 머신)을 마이그레이션하는 작업을 막 끝냈거나 한창 진행 중인 상태였죠. 다들 어려운 고비는 거의 넘겼다고 생각합니다. 아니, 적어도 그렇다고 믿습니다.

하지만 대부분의 사람들이 이야기하지 않는 핵심이 있습니다. 마이그레이션 그 자체는 사실 쉬운 단계라는 점입니다. 단지 전술적인 작업일 뿐이며 시작, 과정, 끝이 명확합니다. 진짜 중요한 작업, 그리고 솔직히 가장 큰 가치가 창출되는 지점은 그 이후에 찾아오는 인프라 운영 방식의 실질적인 현대화입니다.

이러한 마이그레이션을 주도하는 업계의 변화는 현대적인 인프라를 구축할 수 있는 전략적 기회입니다. 라이선스 효율성, 비용 최적화, 벤더 유연성 문제를 해결하기 위해 많은 기업이 전례 없는 속도로 Red Hat OpenShift Virtualization을 선택하고 있습니다. 실제로 2024년 초부터 고객 채택률이 178% 급증했습니다. 많은 논의가 마이그레이션 자체에만 집중되어 있지만, 진정한 가치는 마이그레이션 이후에 일어나는 혁신에 있습니다.

미래 지향적인 조직은 마이그레이션을 최종 목표가 아닌 새로운 도약을 위한 발판으로 삼습니다. 이러한 전환은 단순히 과거의 과제를 해결하는 데 그치지 않습니다. 미래에 대비할 수 있는 현대적인 통합 애플리케이션 플랫폼의 기능을 십분 활용할 수 있도록 탄탄한 기반을 구축하는 과정입니다.

보다 광범위한 로드맵의 실제 실행 모습은 다음과 같습니다.

1단계: Linux 환경 정비하기

마이그레이션을 마친 후에는 무분별하게 확산된 OS 환경을 평가해 보아야 합니다. 대부분의 조직은 의도적인 선택보다는 수년간 자연스럽게 늘어난 다양한 배포판, 버전, 지원 계약이 혼재된 환경을 유지하고 있습니다. 오해 없으시길 바랍니다. 오픈소스 기업으로서 Red Hat이 단일 환경만이 항상 정답이라고 주장하는 것은 아닙니다. 이기종 환경은 분명한 이점이 있습니다. 공통 장애 모드를 줄이고 단일 결함 유형으로 인한 영향 범위를 제한할 수 있기 때문입니다. 이러한 다양성 중 일부는 의도된 것이며 타당한 이유가 있습니다.

하지만 대기업의 경우, 그렇지 않은 경우가 상당히 많습니다. 그것은 바로 기술 부채입니다. 2019년에 누군가 프로젝트용으로 잠깐 만들었던 Ubuntu 인스턴스가 현재 중요한 시스템을 구동하고 있는 식이죠. 지원 종료(EOL) 발표 이후 아무도 패치하지 않은 채 방치된 CentOS 서버도 있습니다. 정확히 어떤 역할을 하는지 아무도 모르지만, 중단되면 큰 문제가 생기는 Windows XP 같은 경우도 해당됩니다.

하이퍼바이저 계층을 표준화했다면, 다음 단계로 게스트 OS 환경을 살펴보는 것이 자연스러운 수순입니다. Red Hat OpenShift와 함께 Red Hat Enterprise Linux(RHEL)를 실행하면 더욱 일관된 운영 모델을 확보할 수 있습니다. 통합 패치 관리, 일관된 기술 지원 경로, 그리고 전체 환경에 실질적으로 적용되는 정책 실행이 가능해집니다. 2024 Red Hat 글로벌 기술 트렌드 설문조사에 따르면, 기업의 45%가 애플리케이션 스택 현대화를 최우선 과제로 삼고 있습니다. 실제로 성과를 거둔 현대화 작업에는 공통된 원칙이 있습니다. 불필요한 OS 다양성은 제거하되, 비즈니스 측면에서 타당한 근거가 있는 경우에만 다양성을 유지하는 것입니다.

2단계: 새로운 플랫폼에 기존 방식을 고수하지 않기

이것이 바로 가장 흔하게 발생하는 실수입니다. 많은 팀이 마이그레이션을 완료한 후에도 이전의 방식을 그대로 답습하여 새로운 환경을 관리하곤 합니다. 과거와 다름없는 수동 프로세스, 여전히 티켓 기반으로 돌아가는 패치 주기, 그리고 콘솔을 통한 임시(ad-hoc) 변경 방식까지 그대로 유지하는 것이죠.

마이그레이션이 완료된 환경은 새로운 시작을 위한 백지 상태와 같습니다. 지금이 바로 자동화 체계를 제대로 구축할 수 있는 절호의 기회입니다.

Red Hat Ansible Automation Platform을 활용하면 몇 주가 소요되던 수동 롤아웃 작업을 단 몇 시간 만에 끝낼 수 있습니다. 플레이북이 마련되면 프로비저닝, 패치, 컴플라이언스 작업이 자동으로 실행됩니다.

팀에서 이미 GitOps를 활용하고 있다면, Red Hat Advanced Cluster Management for Kubernetes를 통해 가상화 환경에도 동일한 운영 원칙을 적용할 수 있습니다. 정책은 코드로 변환되어 Git에 저장됩니다. 이제 콘솔 조작으로 인한 구성 드리프트(drift)를 걱정할 필요가 없습니다. 이는 더욱 강력한 드리프트 제어, 신속한 롤아웃, 그리고 예측 가능한 Day 2 운영을 의미합니다.

실질적인 진실은 이렇습니다. 자동화는 현대화 과정에서 '있으면 좋은' 선택 사항이 아닙니다. 자동화야말로 이후의 모든 단계를 가능하게 만드는 핵심 기반입니다.

3단계: 워크로드에 가장 적합한 환경에서 실행하기

모든 워크로드를 영구적으로 가상 머신(VM) 형태로 유지할 필요는 없습니다. 일부 워크로드는 컨테이너화하는 것이 훨씬 더 효율적입니다. 하지만 모든 것을 컨테이너화하는 것이 정답은 아닙니다. 핵심 목표는 각 워크로드를 가장 적합한 위치에서 실행하는 데 있습니다.

Red Hat OpenShift를 사용하면 동일한 플랫폼에서 VM과 컨테이너를 모두 관리할 수 있습니다. 따라서 '모든 것을 리프트 앤 시프트(lift-and-shift)'할지, 아니면 '모든 것을 클라우드 네이티브로 재작성'할지 고민할 필요가 없습니다. 이러한 이분법적인 사고로 인해 업계 전반에서 엄청난 시간과 비용이 낭비되어 왔습니다. PNC Bank는 이러한 방식을 실용적으로 도입한 좋은 사례입니다. 이들은 새로운 표준을 도입하여 기존에 8주가 소요되던 배포 시간을 10일로 단축한다는 목표를 달성했습니다.

많은 팀이 바로 이 단계에서 난관에 부딪히곤 합니다. 기술 자체는 크게 어렵지 않습니다. 진정으로 어려운 것은 어떤 워크로드를 언제, 어떤 순서로 이동시킬지 결정하는 것입니다. 경험이 풍부한 전문가의 도움을 받느냐에 따라 현대화 주기를 13개월에서 6개월로 단축하는 큰 차이를 만들 수 있습니다. Forrester의 연구 결과가 이를 뒷받침합니다. 한 복합 조직은 전문가의 지침을 통해 Red Hat OpenShift 배포 및 VM 마이그레이션 기간을 13개월에서 7개월로 단축했습니다.

4단계: 필요하기 전에 미리 AI 전략 구상하기

AI 도입에 관해 명심해야 할 점이 있습니다. 이미 엉망인 인프라 위에 AI를 억지로 끼워 맞추어 성공한 사례는 없다는 것입니다. Gartner®는 2026년 전 세계 AI 지출 규모가 총 2조 5,000억 달러에 달할 것으로 예측합니다.

마이그레이션이 끝나기도 전에 AI 계획부터 세우라는 뜻은 아닙니다. 하지만 제가 본 성공적인 팀들은 공통적으로 탄탄한 기반을 갖추고 있었습니다. 바로 잘 정돈되고 자동화된 인프라입니다. AI 워크로드는 컴퓨팅, 스토리지, 관측성(observability) 요구 사항이 매우 까다롭습니다. 수년간 무분별하게 확장되어 얽힌 문제를 풀기보다는, 표준화된 쿠버네티스 네이티브 플랫폼에서 이를 해결하는 것이 훨씬 효율적입니다.

마이그레이션은 벗어남을, 현대화는 혁신을 의미

마이그레이션은 더 이상 머무르고 싶지 않은 플랫폼에서 벗어나게 해줍니다. 현대화는 여러분에게 실제로 필요한 플랫폼을 구축하는 과정입니다. 이 둘은 근본적으로 다르며, 그 차이 속에 진정한 노력과 가치가 숨어 있습니다.

Gartner 보도 자료, Gartner, 2026년 전 세계 AI 지출 규모 2조 5,000억 달러에 달할 것으로 전망, 2026년 1월 15일

GARTNER는 Gartner, Inc. 그리고/또는 그 계열사의 상표입니다.