마침내 실행
클라우드 마이그레이션 A to Z
지난 화에서 우리는 실패 없는 전환을 위한 ‘전략’이라는 청사진을 손에 넣었습니다. 하지만 아무리 훌륭한 설계도라도, 실제로 집을 짓는 과정은 전혀 다른 차원의 이야기입니다. 이번 화에서는 그 설계도를 현실로 만드는 ‘실행’의 세계로 떠나보려 합니다.
클라우드 마이그레이션은 단순한 시스템 구축이 아니라, 수십에서 수백 개의 시스템을 제한된 시간과 자원 안에 이전하는 종합적 프로젝트입니다. 따라서 명확한 책임 구조, 세분화된 일정, 그리고 예외 상황에 대한 대응 체계가 반드시 필요합니다.
1. 프로젝트팀 꾸리기: 누가 무엇을 할 것인가?
성공적인 마이그레이션은 체계적인 역할 분담에서 시작되며, 일반적으로 프로젝트는 세 그룹으로 구성됩니다: - PMO (Project Management Office): 전체 일정 수립, 이슈 대응, 변화관리, 경영진 보고, 품질 검수 등 프로젝트의 총사령탑 역할을 합니다.- 클라우드 수행 조직: 내부 IT 조직과 외부 MSP(Managed Service Provider)로 구성되며, 실제 마이그레이션을 손으로 실행하는 핵심 인력입니다.- CSP/MSP(SI): 클라우드 플랫폼 사업자 또는 시스템 통합 파트너로서, 기술 지원과 솔루션 연계를 담당합니다.
2. 본격적인 이사 전, 짐 정리하기: 기술적 전처리
본격적인 전환 실행에 앞서, 기존 시스템의 구조를 미리 표준화하는 작업이 반드시 필요합니다. 이는 클라우드라는 새로운 집에 짐을 들이기 전, 규격에 맞게 포장하고 정리하는 것과 같습니다.
특히 물리 서버를 가상 환경으로 이전(P2V), 레거시 VM 간 변환(V2V), Unix에서 Linux로의 OS 전환(U2L) 등은 일반적인 사전 작업 항목입니다. 이 중 U2L은 커널 호환성 문제와 미들웨어 재설정이 동반되어 마이그레이션의 큰 장애 요인이 될 수 있습니다. 이처럼 시스템 구조를 미리 표준화하고 OS, 미들웨어, DB의 버전 및 호환성을 점검하는 과정은 전환 실행 직전까지도 반복적으로 확인하고 조정해야 합니다.
3. 리스크 관리를 위한 분할 정복: 마이그레이션 웨이브(Wave) 전략
모든 시스템을 한 번에 옮기는 것은 거대한 도박과 같습니다. 성공적인 전환은 전체 시스템을 여러 그룹, 즉 ‘웨이브(Wave)’로 나누어 순차적으로 진행하는 데서 시작됩니다. 이는 기술적 난이도, 비즈니스 영향도, 시스템 간 연관성 등을 종합적으로 고려하여 전환의 우선순위를 정하는 전략입니다. 보통 위험이 낮고 전환이 쉬운 시스템부터 시작해 경험을 쌓고, 점차 핵심 시스템으로 나아가며 전체적인 안정성을 확보하는 방식입니다. 그 첫 번째 웨이브가 바로 파일럿 프로젝트, 즉 ‘Wave 0’입니다.
4. 작은 방부터 옮겨보기: 파일럿(Wave 0)의 중요성
전체 이사를 시작하기 전에 작은 방 하나를 먼저 옮겨보는 것처럼, 파일럿 프로젝트는 우리가 세운 전략과 구조가 실제 환경에서 잘 작동하는지 검증하는 과정입니다. 보통 중요도가 낮고 구조가 단순한 시스템을 대상으로 진행하며, 이 과정을 통해 발견된 문제점을 보완하여 본격적인 마이그레이션의 리스크를 줄일 수 있습니다.
[파일럿에서 확인해야 할 주요 항목] - 데이터 이전 속도 및 신뢰도: 계획한 네트워크 대역폭으로 실제 데이터를 이전하는 데 걸리는 시간을 측정하고, 데이터 유실이나 깨짐은 없는지 검증합니다. 이는 본 마이그레이션의 다운타임을 예측하는 중요한 근거가 됩니다.
- 테스트 환경과 운영 환경 간 차이점: 눈에 보이지 않던 설정 차이(OS 패치 버전, 라이브러리 등)가 마이그레이션 실패의 원인이 될 수 있습니다. 파일럿을 통해 이런 미세한 차이점을 미리 발견하고 해결해야 합니다.
- IAM(계정 및 권한) 연동 및 보안 정책 작동 여부: 설계한 대로 권한이 부여되고 접근이 통제되는지, 기존 인증 시스템(SSO, AD)과 충돌은 없는지 등을 확인하여 보안 공백이 없도록 검증합니다.
- 운영 및 자동화 도구의 정상 작동 여부: 전환 이후 사용할 모니터링, 로그 수집, 백업 도구들이 파일럿 시스템과 정상적으로 연동되어 데이터를 수집하고 있는지 확인합니다.
5. 가장 어렵고 복잡한 단계: 실제 마이그레이션과 Cutover
파일럿 검증이 끝나면 마침내 프로젝트의 심장부인 실제 마이그레이션 단계에 들어섭니다. 이 단계는 이론과 계획이 현실의 복잡성과 만나는, 가장 어렵고 압박감이 큰 과정입니다. 시스템의 특성에 맞춰 서비스 중단(Cutover) 전략을 세심하게 수립해야 합니다.
[Info Box] 무중단 전환을 위한 2가지 핵심 전략
24/7 운영 시스템의 전환에는 보통 다음 두 가지 전략이 활용됩니다:
- 이중 운영 (Double Run): 기존 환경과 클라우드 환경에서 동일한 시스템을 동시에 운영하며 데이터를 동기화하고, 테스트를 거쳐 점진적으로 전환합니다. 정합성 검증과 성능 비교가 가능하다는 장점이 있습니다.
- 블루-그린 배포 (Blue-Green Deployment): 기존 환경(블루)과 새로운 환경(그린)을 동시에 구성한 뒤, 전환 시점에 트래픽을 한 번에 그린으로 돌립니다. 문제가 발생하면 즉시 블루 환경으로 롤백이 가능해 안정적입니다.
Cutover 전략뿐만 아니라, '무엇을 어떻게' 옮길 것인지에 따라서도 마이그레이션의 복잡성은 크게 달라집니다.
- Replatform: 핵심 부품만 클라우드 친화적으로 교체하기 Replatform은 자동차의 엔진이나 타이어를 고성능 부품으로 교체하는 것과 같습니다. 차량의 기본 골격과 같은 애플리케이션의 코어 아키텍처는 그대로 유지하되, DB, 미들웨어 같은 핵심 구성 요소만 클라우드 환경에 더 유리한 기술로 변경하여 성능과 효율을 높이는 전략입니다. 이는 단순히 관리형 서비스(Managed Service)로 전환하는 것만을 의미하지 않으며, 다음과 같은 다양한 경우를 포함합니다.
- 관리형 서비스(PaaS)로 전환: 온프레미스 VM 위에서 직접 운영하던 데이터베이스를 AWS RDS나 Azure SQL Database 같은 관리형 서비스로 전환하는 경우입니다. 이를 통해 DB 패치, 백업, 고가용성 구성과 같은 복잡한 운영 업무를 CSP에게 위임할 수 있습니다.
- 솔루션 엔진 변경: 클라우드 VM 위에서 운영하는 것은 동일하지만, 라이선스 비용이 비싼 상용 소프트웨어를 오픈소스 솔루션으로 교체하는 경우입니다. 예를 들어, VM 위에서 운영하던 Oracle 데이터베이스를 PostgreSQL로 전환하여 라이선스 비용을 절감하고 벤더 종속성을 낮출 수 있습니다. - 미들웨어 업그레이드 및 변경: 기존에 사용하던 오래된 버전의 미들웨어(WAS 등)를 성능과 보안이 향상된 최신 버전으로 업그레이드하거나, 더 가볍고 유연한 다른 솔루션으로 교체하는 작업도 Replatform에 해당합니다.
- Refactor/Rearchitect: 클라우드 네이티브로 재탄생하기 Refactor는 낡은 주택을 리모델링하는 수준을 넘어, 아예 허물고 새로운 설계로 다시 짓는 것에 가깝습니다. 기존 애플리케이션을 클라우드 환경의 장점(탄력성, 분산 처리, 회복성)을 극대화할 수 있는 클라우드 네이티브 아키텍처로 완전히 재설계하는 가장 적극적인 전환 방식입니다. 시간과 비용이 가장 많이 들지만, 장기적인 민첩성과 확장성 측면에서 가장 큰 효과를 볼 수 있습니다.
이러한 복잡한 전환 과정에서는 보이지 않는 기술적 허들이 많습니다.
예를 들어, 데이터베이스 이전 시에는 데이터 포맷, 인코딩, 대용량 BLOB, 트리거, 인덱스, 시퀀스 재정의 등 수많은 변수를 고려해야 합니다.
IAM(계정) 연동 역시 단순 사용자 이관을 넘어 SSO, AD 연동, 역할 기반 접근 제어(RBAC, Role Base Access Control) 등과 맞물려 정교하게 설계되지 않으면 대규모 장애로 이어질 수 있습니다.
6. 사람의 변화를 이끄는 힘: PMO 중심의 변화관리
마이그레이션은 기술적 전환 이전에 ‘업무 방식의 변화’입니다. 그리고 이 중요한 ‘사람의 변화’를 책임지고 이끄는 주체가 바로 PMO(Project Management Office)입니다. PMO의 역할은 단순히 일정과 기술적 리스크를 관리하는 데 그치지 않습니다. 전환 프로젝트의 성공을 위해 가장 중요한 축 중 하나인 변화관리를 총괄하며, 기술의 변화가 조직에 연착륙할 수 있도록 조율하는 핵심적인 임무를 수행해야 합니다.
전환 기간 동안 PMO가 주도하는 변화관리 활동은 다음과 같은 구체적인 내용을 포함해야 합니다:
- 지속적인 커뮤니케이션: 전환 이후 바뀔 시스템 구조, 사용 방식, 접속 정책 등에 대해 내부 사용자들에게 투명하게 공유합니다.- 사전 인지 및 대응 체계 공유: 서비스 중단(Cutover) 시점에 예상되는 이슈와 대응 방안을 미리 알려 사용자의 불안감을 해소하고 협조를 이끌어냅니다.- 사용자 관점의 시뮬레이션: 새로운 시스템이 실제 업무에 어떻게 영향을 미치는지 사용자 관점에서 시뮬레이션하고 변화에 미리 대비하게 합니다.- 정보 공유 채널 확보: IT 부서와 현업 부서 간에 공식적인 정보 공유 채널을 만들어 오해와 소통 부재를 방지합니다.
마이그레이션 실행은 이처럼 체계적인 프로젝트 관리, 기술적 검증, 그리고 사람에 대한 이해가 모두 필요한 복합적인 과정입니다.
이제 성공적으로 이사를 마쳤으니, 다음 화에서는 새로운 집에서 살림을 안정시키고, 장기적인 발전의 토대를 닦는 ‘안정화와 운영’ 단계에 대해 이야기해 보겠습니다.
