VM을 AWS로 마이그레이션할 때 실제로 고민해야 하는 것들

안녕하세요 클래스메소드의 이수재입니다.

이전 글에서는 Oracle VirtualBox에서 실행 중인 Ubuntu VM을 AWS Transform MGN으로 복제하고, EC2 Test instance에서 Nginx가 동작하는 것까지 확인했습니다.

실습만 놓고 보면 원본 서버를 복제하고 EC2에서 애플리케이션이 실행되는 것을 확인한 뒤 Cutover하면 마이그레이션이 끝나는 것처럼 보일 수 있습니다. 그러나 실제 환경에서 옮겨야 하는 대상은 VM 한 대가 아니라, 그 VM을 포함해 동작하고 있던 서비스 전체입니다.

이번 글에서는 Cutover의 콘솔 절차보다 범위를 넓혀, 기존 VM 환경을 AWS로 이행할 때 어떤 내용을 사전에 조사하고 준비해야 하는지 카테고리별로 정리해보겠습니다.

MGN이 담당하는 범위

서버 복제와 서비스 이행의 차이

AWS Transform MGN은 물리 서버나 가상 서버의 데이터를 지속적으로 블록 단위로 복제하고, 복제된 서버를 AWS에서 Test instance 또는 Cutover instance로 실행할 수 있도록 지원합니다.

쉽게 이해하면 MGN이 담당하는 핵심은 원본 서버를 EC2에서 실행할 수 있는 상태로 옮기는 것입니다.

반면 어떤 서버를 함께 옮겨야 하는지 판단하고, AWS에서 사용할 네트워크와 권한을 준비하고, 외부 데이터와 접속 경로를 전환하는 작업은 별도로 진행해야 합니다. 모니터링과 백업, 장애 대응 같은 운영 방식도 자동으로 AWS에 맞춰지는 것은 아닙니다.

이행의 전체 흐름

실제 이행 흐름을 크게 나누면 다음과 같습니다.

현행 환경과 의존 관계 조사
→ AWS 기반과 목표 구성 준비
→ MGN 복제 및 Test instance 검증
→ 데이터와 서비스 전환 준비
→ Cutover 및 트래픽 전환
→ 안정화와 운영 인계
→ 원본 환경 정리

Cutover는 이 흐름의 중심에 있지만, 전체 이행 중 한 단계에 해당합니다.

현행 환경과 이행 범위

서비스 구성과 의존 관계

실제 이행에서는 먼저 서버 목록보다 서비스의 동작 범위를 확인해야 합니다.

예를 들어 웹 서버 한 대를 옮기더라도 뒤에서 사용하는 데이터베이스와 캐시, 공유 파일 서버, 메시지 큐가 별도로 존재할 수 있습니다. Active Directory나 사내 DNS를 참조하거나, 다른 업무 시스템이 해당 서버의 IP를 직접 호출하는 경우도 있습니다.

반대 방향의 연결도 확인해야 합니다. 애플리케이션이 결제, 메일 또는 협력사 API를 호출하고 상대 시스템에서 기존 출발지 IP만 허용하고 있다면, 서버가 AWS에서 정상적으로 실행되어도 실제 기능은 실패할 수 있습니다.

백업, 모니터링, 패치, 백신과 EDR 같은 운영 도구도 의존 관계에 포함됩니다. 평소에는 눈에 띄지 않지만 특정 시간에만 실행되는 배치나 월말 작업도 조사 대상입니다.

중단 시간과 데이터 손실 범위

서비스 담당자와 함께 허용 가능한 중단 시간과 데이터 손실 범위를 정합니다. 일반적으로 RTO는 서비스가 중단된 뒤 복구될 때까지 허용할 수 있는 시간이며, RPO는 복구 시점에서 허용할 수 있는 데이터 손실 범위를 의미합니다.

이 목표는 Cutover 시간을 정하는 데도 영향을 줍니다. 짧은 중단 시간과 거의 없는 데이터 손실이 필요하다면 MGN의 서버 복제 상태만 보는 것이 아니라, 외부 데이터베이스와 파일 스토리지의 마지막 동기화 방법도 함께 준비해야 합니다.

Dependency group과 Migration wave

의존 관계를 확인한 뒤 어떤 서버와 데이터를 같은 시점에 옮길지 결정합니다. 애플리케이션 서버와 데이터베이스 사이의 지연 시간에 민감하거나 여러 시스템이 같은 데이터베이스를 공유한다면, 서버 한 대만 먼저 옮기는 방식이 적합하지 않을 수 있습니다.

AWS에서는 이처럼 함께 이동해야 하는 대상을 Dependency group으로 묶고, 하나 이상의 그룹을 Migration wave로 구성하는 방식을 안내합니다. 기술적인 의존 관계뿐 아니라 업무 일정과 담당자의 참여 가능 시간도 이행 순서에 영향을 줍니다.

관련 자료: AWS 마이그레이션의 Wave planning, 중단 시간과 데이터 손실에 대한 RTO·RPO 정의, Application portfolio 평가 전략

AWS 기반 환경

리전과 계정

실제 환경에서는 먼저 대상 AWS 리전과 계정을 정합니다. 이번 VirtualBox 실습은 도쿄 리전(ap-northeast-1)을 사용했지만, 운영 환경에서는 사용자와 데이터의 위치, 지연 시간, 필요한 AWS 서비스의 제공 여부, 규제와 데이터 보관 요구 사항을 함께 검토합니다.

여러 계정을 사용하는 환경이라면 어느 계정에 서버를 배치할지, 중앙 로그와 관리 계정에서 어떻게 확인할지도 정합니다. 계정 구조와 IAM 권한이 준비되지 않은 상태에서 서버부터 옮기면 운영 담당자의 접속과 변경 관리가 어려워질 수 있습니다.

VPC와 리소스 준비

VPC와 서브넷뿐 아니라 온프레미스와 겹치지 않는 CIDR, 필요한 IP 주소 수, 퍼블릭·프라이빗 서브넷의 구분과 라우팅을 검토합니다. 많은 서버를 동시에 옮긴다면 EC2, EBS와 네트워크 관련 서비스 할당량이 충분한지도 확인해야 합니다.

EC2 Launch Template에는 대상 서브넷과 보안 그룹, 인스턴스 유형, EBS 설정, IAM instance profile을 반영합니다. 원본 VM의 CPU와 메모리 크기를 그대로 따라가기보다 실제 사용량을 기준으로 초기 인스턴스 유형을 정하고, Test 결과에 따라 조정합니다.

보안과 암호화

대상 환경의 IAM 권한과 보안 그룹뿐 아니라 저장 데이터와 통신 구간의 암호화도 정합니다.

EBS 볼륨과 스냅샷을 암호화할 때는 사용할 KMS 키와 키 정책을 확인합니다. MGN과 EC2가 볼륨을 생성하고 운영 담당자가 백업과 복원을 수행할 때 필요한 역할이 해당 키를 사용할 수 있어야 합니다.

애플리케이션 통신에는 TLS를 적용하고, 비밀 정보는 파일에 그대로 두기보다 Secrets Manager나 Parameter Store처럼 운영 환경에서 정한 방법으로 관리할 수 있습니다. 로그의 보관 위치와 접근 권한, 보안 이벤트를 확인할 방법도 이행 전에 준비합니다.

목표 구성과 가용성

목표 구성을 기존 VM과 완전히 같게 유지할지도 결정합니다. 빠른 Rehost가 목적이라면 먼저 EC2로 옮긴 뒤 안정화하고, 데이터베이스나 파일 서버의 관리형 서비스 전환은 후속 작업으로 분리할 수 있습니다.

반대로 이행과 동시에 구조를 크게 바꾸면 한 번에 검증해야 할 범위가 늘어납니다. 개인적으로는 일정이 제한된 이행에서는 서버 이동과 애플리케이션 현대화의 범위를 구분해두는 편이 문제 발생 시 원인을 찾기 쉽다고 생각합니다.

기존 환경이 단일 VM이었다면 EC2 한 대가 실행되는 것만으로 가용성이 높아지지는 않습니다. 다중 AZ, Application Load Balancer, Auto Scaling 또는 별도 재해 복구가 필요한지는 서비스가 요구하는 복구 시간과 장애 허용 범위에 따라 별도로 설계해야 합니다.

관련 자료: 대규모 마이그레이션의 Landing zone 고려 사항

네트워크

인바운드 경로

사용자가 서비스에 들어오는 경로는 DNS, 로드 밸런서와 방화벽을 중심으로 확인합니다.

새 Application Load Balancer를 사용하는 경우에는 Cutover instance를 대상 그룹에 등록하고, Route 53 레코드를 새 로드 밸런서로 변경할 수 있습니다. 기존 로드 밸런서를 계속 사용한다면 DNS는 그대로 두고 리스너 규칙이나 대상 그룹만 바꾸는 방법도 있습니다.

HTTPS를 사용한다면 도메인과 일치하는 인증서와 로드 밸런서 리스너가 필요합니다. MGN이 원본 디스크를 복제하더라도 별도 AWS 리소스인 로드 밸런서, AWS Certificate Manager 인증서와 WAF 설정까지 만들어주지는 않습니다.

사내망과 사설 DNS

사내 사용자가 접근하는 서비스라면 인터넷 경로보다 VPN, Direct Connect 또는 Transit Gateway와 사내 라우팅이 중요할 수 있습니다.

Route 53 Private Hosted Zone이나 사내 DNS가 새 사설 주소를 반환하도록 설정했더라도 클라이언트 네트워크에 해당 주소로 가는 경로가 없으면 접속할 수 없습니다. 이름 해석과 실제 네트워크 경로를 함께 확인해야 합니다.

아웃바운드 경로

애플리케이션이 밖으로 나가는 경로도 확인합니다. 프라이빗 서브넷의 Cutover instance가 NAT Gateway를 통해 외부 API를 호출하면 상대 시스템이 보는 출발지 IP가 기존 환경과 달라집니다.

협력사 방화벽과 허용 목록, 프록시 설정을 미리 바꿔야 하는 이유입니다. 반대로 외부 시스템이 기존 VM의 IP를 직접 호출하고 있다면 상대 시스템의 목적지도 변경해야 할 수 있습니다.

DNS 전환

DNS를 변경할 예정이라면 현재 레코드의 TTL을 확인합니다. TTL을 직접 조정할 수 있는 레코드는 기존 캐시가 만료될 시간을 고려해 이행 전에 값을 낮춰둘 수 있습니다.

변경 직전에 TTL을 낮춰도 이미 저장된 응답의 유효 시간은 줄어들지 않습니다. Cutover와 롤백 모두 DNS 캐시의 영향을 받을 수 있다는 점을 Runbook에 반영합니다.

관련 자료: Route 53에서 ELB로 트래픽 라우팅하기, Route 53 DNS 모범 사례와 TTL, NAT Gateway 기본 사항

데이터와 애플리케이션

별도로 이행할 데이터

MGN은 Source server의 디스크를 복제합니다. 따라서 해당 서버 밖에 있는 데이터와 AWS에서 새로 만들어야 하는 리소스는 각각 다른 방법으로 준비해야 합니다.

외부 데이터베이스는 백업과 복원 또는 변경 데이터 캡처 방식으로 별도 이행할 수 있습니다. 공유 파일은 DataSync를 사용하거나 S3를 중간 저장소로 사용하는 등 데이터량과 허용 중단 시간에 맞는 방식을 선택합니다.

파일 시스템을 EFS나 FSx로 변경한다면 권한, 파일 잠금, 마운트 방식과 성능도 다시 확인해야 합니다.

애플리케이션 설정과 비밀 정보

환경 변수와 비밀 정보, 데이터베이스 엔드포인트, OAuth callback URL, Webhook과 CORS 설정은 환경에 따라 변경됩니다.

EC2 IAM 역할을 사용하도록 바꾼다면 기존 Access Key가 남아 있지 않은지도 확인합니다. 원본 VM의 설정 파일을 그대로 복제하는 것만으로 새 운영 환경의 권한 체계가 완성되는 것은 아닙니다.

메시지와 실행 상태

메시지 큐가 있다면 원본 생산자를 언제 멈추고 잔여 메시지를 어디에서 처리할지 정합니다. 사용자 세션과 캐시를 두 환경이 공유할 수 없다면, 단계적으로 트래픽을 나누는 방식보다 한 번에 전환하는 방식이 더 단순할 수 있습니다.

배치와 스케줄러도 전환 대상입니다. 원본과 Cutover instance에서 같은 작업이 동시에 실행되면 중복 처리가 발생할 수 있으므로, 중지와 재개 시점을 Runbook에 포함합니다.

관련 자료: AWS DMS 개요, AWS DataSync로 데이터 전송하기, AWS DataSync의 데이터 무결성 검증

OS와 라이선스

MGN 지원 조건

AWS Replication Agent를 설치하기 전에 OS 버전과 아키텍처, 커널이 MGN의 지원 범위에 포함되는지 확인합니다. 지원 범위와 종료 예정 버전은 바뀔 수 있으므로 이행 시점의 공식 문서를 기준으로 판단합니다.

Linux에서는 실행 중인 커널과 일치하는 헤더, 부트 로더와 파티션 구성, /·/tmp·/boot의 여유 공간 같은 설치 조건도 확인해야 합니다. Windows도 지원 버전과 업데이트, 설치 디스크의 여유 공간 등 별도 조건이 있습니다.

OS 설정과 운영 에이전트

EC2에서 디스크가 의도한 위치에 마운트되는지, 필요한 서비스가 재부팅 후 자동으로 시작되는지 확인합니다. 호스트 이름, 시간 동기화, DNS와 패키지 저장소도 새로운 환경에 맞게 점검합니다.

기존 가상화 환경의 도구와 백신, EDR, 모니터링 에이전트가 EC2에서도 지원되는지도 살펴봅니다.

MGN의 Post-launch actions를 사용하면 SSM Agent 설치와 연결 확인, 볼륨 무결성 검사, 프로세스 확인, CloudWatch Agent 설치, 시간 동기화와 Directory Service 가입 같은 작업 중 일부를 자동화할 수 있습니다. 필요한 설정이 없다면 Systems Manager 문서를 이용한 사용자 지정 작업도 검토할 수 있습니다.

라이선스

라이선스는 디스크와 함께 복제되었다는 이유만으로 AWS에서 그대로 사용할 수 있다고 판단해서는 안 됩니다.

OS와 상용 소프트웨어의 계약 조건, BYOL 또는 License Included 사용 여부, 전용 호스트 요구 사항을 확인합니다. CPU나 MAC 주소처럼 하드웨어 정보에 연결된 라이선스라면 공급사에 클라우드 환경에서의 재발급이나 이전 방법도 확인해야 합니다.

관련 자료: MGN에서 지원하는 운영 체제, AWS Replication Agent 설치 요구 사항, MGN Post-launch actions, MGN 운영 체제 라이선스 설정

Test instance 검증

OS와 EC2 기본 동작

이번 VirtualBox 실습에서는 SSH 접속, Nginx 상태와 웹 페이지의 변경 내용을 확인했습니다. 이는 복제된 Ubuntu가 EC2에서 기동하고 디스크 변경분이 반영되었다는 것을 확인하는 데는 충분합니다.

실제 환경에서는 모든 EBS 볼륨이 의도한 크기와 장치로 연결되었는지, 파일 시스템이 정상적으로 마운트되는지, 재부팅 후 필요한 서비스가 자동으로 시작되는지 확인합니다. SSM 접속과 IAM 권한, 시간 동기화, 로그 수집, 백업과 보안 에이전트도 실제 운영 설정으로 시험합니다.

애플리케이션과 연동

애플리케이션의 로그인과 조회, 등록과 수정 같은 주요 기능을 실행합니다. 데이터베이스와 파일 스토리지, 외부 API, 메일과 배치까지 연결해봐야 서버 내부의 curl만으로 발견하기 어려운 문제를 찾을 수 있습니다.

기능 확인은 서버 관리자만 수행하기보다 실제 업무를 아는 애플리케이션 담당자와 함께 완료 조건을 정하는 편이 좋습니다.

성능과 용량

이행 전의 응답 시간과 CPU, 메모리, 디스크 처리량을 기준값으로 남겨두고 Test instance에서 같은 작업을 수행합니다.

기능은 정상이어도 온프레미스에 남은 데이터베이스와의 지연 시간이나 EBS 설정 차이 때문에 성능이 달라질 수 있습니다. 예상 사용자 수와 배치 처리량을 감당할 수 있는지도 확인합니다.

Test 수정 사항의 재현

Test instance에서만 직접 수정한 내용은 이후 새로 실행하는 Cutover instance에 그대로 이어지지 않습니다.

Test에서 발견한 수정 사항은 원본 서버에 반영하거나, Launch Template과 Post-launch actions 또는 별도 배포 자동화로 다시 적용할 수 있어야 합니다. Cutover 전에 같은 절차로 새로운 Test instance를 실행해 수정 사항이 재현되는지도 확인합니다.

관련 자료: MGN Test instance 실행하기, MGN Post-launch template, Cutover 이전 테스트 계획

Cutover와 롤백

Runbook과 판단 기준

Runbook은 실제 작업자가 정해진 순서대로 작업을 수행하고 진행 상황을 공유할 수 있도록 만든 실행 절차서입니다. 단순히 해야 할 일을 나열하는 데서 끝나지 않고, 각 작업의 담당자와 예정 시간, 시작 조건, 확인 방법, 정상 결과와 실패 시 대응을 함께 기록합니다.

Cutover에서는 여러 팀이 제한된 시간 안에 작업하므로, 다음과 같이 작업 순서와 완료 조건을 연결한 Runbook을 준비합니다.

사용자 쓰기 중지
→ 원본 최종 백업
→ 마지막 데이터 동기화 확인
→ Cutover instance 실행
→ 인스턴스와 애플리케이션 확인
→ DNS·로드 밸런서·라우팅 전환
→ 업무 기능과 모니터링 확인
→ Go 또는 롤백 결정
→ Finalize

작업 중에는 완료 여부와 실제 소요 시간을 Runbook에 기록해 다음 단계로 진행할 수 있는지 공유합니다. 헬스 체크 실패, 주요 기능 오류, 허용 범위를 넘는 응답 시간처럼 작업을 중단하고 롤백할 기준도 미리 정합니다.

마지막 동기화와 트래픽 전환

사용자 요청을 점검 페이지로 보내거나 애플리케이션을 읽기 전용으로 바꾼 뒤, 진행 중인 데이터베이스 트랜잭션과 메시지를 정리합니다. MGN Migration dashboard에서는 Data replication status와 함께 Lag와 Backlog가 남아 있지 않은지 확인합니다.

MGN에서 Source server를 Ready for cutover로 전환하고 Cutover instance를 실행합니다. 이미 실행된 Cutover instance에 원본의 이후 변경이 계속 적용되는 것은 아니므로, 어느 시점부터 원본 쓰기를 막을지 명확해야 합니다.

Cutover instance의 기본 동작을 확인한 뒤 로드 밸런서의 대상이나 DNS를 전환합니다. 일부 사용자부터 옮기는 단계적 전환도 가능하지만, 두 환경이 같은 데이터와 세션을 안전하게 공유할 수 있을 때에만 사용할 수 있습니다.

롤백과 Finalize

트래픽을 전환하기 전에 문제가 발견되었다면 원본 서비스를 그대로 유지하면서 Cutover instance를 다시 준비할 수 있습니다.

트래픽을 옮긴 뒤에도 새 환경에서 쓰기가 발생하지 않았다면 DNS나 로드 밸런서의 대상을 원본으로 되돌리는 방식으로 비교적 단순하게 롤백할 수 있습니다. 다만 DNS 캐시가 남아 있으면 모든 사용자가 즉시 원본으로 돌아오지는 않을 수 있습니다.

새 환경에 새로운 데이터가 기록되었다면 원본은 이미 오래된 상태입니다. 새 데이터를 어떻게 병합할지, 또는 AWS 환경에서 문제를 수정해 운영을 계속할지 판단해야 합니다.

MGN의 Revert to "ready for cutover"는 Migration lifecycle을 되돌려 새로운 Cutover instance를 준비할 수 있게 하는 기능입니다. DNS와 로드 밸런서 설정을 원래대로 바꾸거나 Cutover instance의 데이터를 원본으로 역복제하는 기능은 아닙니다.

새 환경을 운영 대상으로 확정한 뒤 Finalize cutover를 실행합니다. Finalize하면 복제가 중지되고 스테이징 영역의 복제 데이터와 관련 리소스가 정리되지만, Cutover instance 자체는 종료되지 않습니다.

관련 자료: Cutover 계획과 Runbook 준비하기, Cutover 단계의 일반적인 흐름과 Rollback, MGN Cutover instance 실행과 Finalize

운영 인계와 정리

Hypercare와 모니터링

서비스가 AWS에서 동작하기 시작해도 바로 이행이 끝난 것은 아닙니다. 일정 기간은 오류율과 응답 시간, CPU와 메모리, EBS와 네트워크 사용량, 애플리케이션 로그를 평소보다 자세히 확인합니다.

이 기간에는 마이그레이션 담당자와 운영 담당자가 함께 문제를 처리할 수 있도록 담당자와 연락 방법을 정해둡니다.

백업과 장애 대응

CloudWatch 경보와 백업 정책이 실제로 동작하는지 확인하고, 백업은 생성 여부뿐 아니라 복원 가능성도 시험합니다.

패치와 취약점 관리, 장애 대응 Runbook, 재해 복구 방식도 새로운 AWS 리소스를 기준으로 갱신합니다.

비용과 Right sizing

Test나 Replication 과정에서 만든 리소스가 남아 있지 않은지 살펴보고, 실제 사용량에 비해 큰 EC2와 EBS는 Right sizing을 검토합니다.

NAT Gateway, 로드 밸런서, 스냅샷과 로그 보관처럼 기존 VM 환경에서는 구분하기 어려웠던 비용도 함께 확인합니다.

원본 환경 정리

원본 VM은 정해둔 롤백 기간과 데이터 보존 정책이 지난 뒤 종료합니다. 임시 AWS 자격 증명과 방화벽 규칙, 협력사 허용 목록, 기존 백업 작업과 사용하지 않는 라이선스도 함께 정리합니다.

CMDB와 운영 문서의 서버 정보도 새 EC2를 기준으로 갱신합니다. MGN Source server를 Mark as archived로 표시하는 것과 원본 VM이나 EC2를 실제로 종료하는 것은 서로 다른 작업이므로 각각 확인해야 합니다.

관련 자료: Wave planning의 Hypercare와 운영 인계, AWS Backup Restore testing, AWS Compute Optimizer의 Right-sizing 설정

실제 이행에서 확인할 체크리스트

앞에서 설명한 내용을 실제 이행에 적용할 때는 다음과 같이 분류해볼 수 있습니다. 모든 환경에 그대로 적용되는 목록은 아니며, 서비스 구성에 맞게 항목을 추가하거나 제외합니다.

실제 Runbook으로 사용할 때는 각 항목에 담당자, 확인 방법, 예상 결과와 실패 시 되돌리는 방법을 함께 기록하는 편이 좋습니다.

관련 자료: AWS 마이그레이션의 Wave planning, 대규모 마이그레이션의 Landing zone 고려 사항, Cutover 이전 계획과 Runbook

이번 VirtualBox 실습으로 확인한 범위

직접 확인한 내용

앞선 VirtualBox 실습에서 실제로 확인한 범위는 AWS Replication Agent 설치와 초기 복제, Test instance 실행, 원본 파일 변경분이 복제되는 흐름까지입니다.

실습에 포함하지 않은 내용

Cutover instance 실행과 로드 밸런서·DNS 전환은 해당 실습에서 직접 수행하지 않았습니다. 이 글의 Cutover 이후 내용은 AWS 공식 문서와 실제 환경에서 고려할 수 있는 구성을 바탕으로 정리한 참고 흐름입니다.

단일 Ubuntu VM과 Nginx 페이지에는 실제 사용자의 쓰기, 외부 데이터베이스, 공유 스토리지, 사내 네트워크와 업무 시스템 의존 관계가 없습니다. 따라서 이 실습의 성공이 실제 서비스 이행에 필요한 데이터 정합성이나 성능, 고가용성과 운영 준비까지 증명하는 것은 아닙니다.

실습은 MGN이 서버를 어떻게 옮기는지 이해하는 출발점으로 보고, 실제 이행에서는 서비스에 연결된 요소를 하나씩 추가해 Test와 Runbook의 범위를 넓혀야 합니다.

관련 자료: MGN Source server와 Replication Agent, MGN에서 지원하는 운영 체제

마무리

AWS Transform MGN을 사용하면 기존 VM을 EC2로 옮기는 작업은 비교적 단순하게 시작할 수 있습니다. 하지만 VM이 부팅되는 것과 서비스가 AWS에서 운영 가능한 상태가 되는 것은 다른 문제입니다.

어떤 시스템을 함께 옮길지 파악하고, AWS 기반과 네트워크를 준비하고, MGN이 복제하지 않는 데이터와 설정을 별도로 전환해야 합니다. Cutover 이후의 모니터링과 백업, 비용 관리와 원본 환경 정리까지 이어져야 실제 이행이 마무리됩니다.

MGN을 이용한 서버 이행을 준비하고 계신 분들께 도움이 되었으면 합니다.

긴 글 읽어주셔서 감사합니다.