"서버를 클라우드로 옮기자"는 결정이 내려진 뒤 실무자가 가장 먼저 부딪히는 벽은 기술이 아닙니다. 무엇을, 어떤 순서로, 얼마나 멈추고, 얼마의 비용으로 옮길 것인가를 정하는 일입니다. 이 글은 특정 하이퍼바이저나 도구에 묶이지 않는 온프레미스 → AWS 이전의 공통 절차를 다룹니다. VMware 환경에서 AWS Transform을 사용하는 구체적인 화면 순서는 온프레미스 VMware를 AWS로 옮기는 단계별 가이드에서 따로 다뤘습니다.
전체 흐름 한눈에 보기
AWS의 마이그레이션 방법론(MRA/MRP)은 크게 세 국면으로 나뉩니다. 아래 흐름이 이 글의 목차이기도 합니다.
[1] 평가 (Assess) 현황 진단 · TCO 산정 · 이전 타당성 판단
│ → 산출물: 인벤토리, 비용 비교, 전환 로드맵
[2] 준비 (Mobilize) 랜딩 존 · 네트워크 · 보안 기준선 · 파일럿 이전
│ → 산출물: AWS 기반 환경, 웨이브 계획, 런북
[3] 이전 (Migrate) 웨이브별 복제 → 테스트 → 컷오버 → 안정화
│
[4] 최적화 (Optimize) 사이징 조정 · 요금제 최적화 · 운영 자동화 · 현대화STEP 1. 인벤토리 — 옮길 대상을 확정한다
마이그레이션 실패의 가장 흔한 원인은 기술적 난관이 아니라 대상 목록이 틀린 것입니다. 착수 시점에 "우리 서버가 몇 대인지" 정확히 아는 조직은 생각보다 드뭅니다.
수집해야 하는 최소 항목
| 분류 | 수집 항목 | 왜 필요한가 |
|---|---|---|
| 하드웨어 | vCPU, 메모리, 디스크 용량·유형, 실제 사용률 | EC2 인스턴스 타입·EBS 볼륨 사이징의 근거 |
| 소프트웨어 | OS 버전, 미들웨어, DB 엔진·버전, 라이선스 형태 | MGN 지원 여부, BYOL 가능 여부, 라이선스 비용 |
| 네트워크 | IP, 포트, 방화벽 정책, 서버 간 통신 관계 | 보안 그룹 설계와 웨이브 그룹핑의 근거 |
| 운영 | 서비스 담당자, 허용 중단 시간, 백업·DR 요건 | 컷오버 일정과 롤백 기준 수립 |
| 의존성 | 배치 연동, 외부 연계, 하드코딩된 IP·호스트명 | 같은 웨이브로 묶어야 할 서버 판별 |
수집 방법 선택
- AWS Application Discovery Service — 에이전트 또는 Agentless Collector(OVA)를 설치해 성능·의존성 데이터를 자동 수집합니다. 가장 정확하지만 배포 승인이 필요합니다.
- RVTools 익스포트 — vSphere 환경이라면 가장 빠른 출발점입니다. 구성 정보는 충분하나 시계열 성능 데이터가 없다는 한계가 있습니다.
- CMDB·자산관리 대장 — 있다면 활용하되, 반드시 실측 데이터와 대조하세요. 현장에서 대장과 실제가 일치하는 경우는 많지 않습니다.
STEP 2. 7R — 서버마다 전략을 정한다
모든 서버를 같은 방식으로 옮기지 않습니다. 인벤토리의 각 항목에 아래 7가지 중 하나를 배정하는 것이 계획 수립의 핵심 작업입니다.
| 전략 | 내용 | 이럴 때 선택 | 난이도 |
|---|---|---|---|
| Retire (폐기) | 옮기지 않고 종료 | 사용자가 없거나 기능이 중복되는 시스템 | - |
| Retain (유지) | 온프레미스에 존치 | 규제상 이전 불가, EOL 임박, 이전 ROI 없음 | - |
| Relocate (재배치) | 하이퍼바이저 단위로 이전 | VMware Cloud 계열로 그대로 옮길 때 | 낮음 |
| Rehost (리호스팅) | 수정 없이 EC2로 이전 (Lift & Shift) | 대다수 서버의 기본 선택 | 낮음 |
| Repurchase (재구매) | SaaS로 대체 | 그룹웨어·ITSM·메일 등 상용 대체재가 있을 때 | 중간 |
| Replatform (재플랫폼) | 일부만 관리형 서비스로 교체 | DB를 RDS로, 웹 서버를 ALB+ASG로 | 중간 |
| Refactor (재설계) | 클라우드 네이티브로 재구축 | 확장성·배포 속도가 사업 병목일 때 | 높음 |
현실적인 배분은 Rehost 중심 + 선별적 Replatform입니다. 처음부터 Refactor를 목표로 잡으면 데이터센터 계약 만료 같은 기한을 맞추지 못합니다. 일단 옮기고, 안정화 후 현대화하는 2단계 접근이 대부분의 조직에 맞습니다.
STEP 3. 사이징과 비용 — 옮기기 전에 계산한다
인스턴스 사이징 원칙
- 실사용률 기준으로 산정합니다. CPU 최대 사용률이 20%인 16 vCPU 서버는 4~8 vCPU면 충분한 경우가 많습니다.
- 최신 세대와 Graviton을 검토합니다. 동일 성능에서 비용이 낮습니다. 단, Graviton(ARM)은 애플리케이션 재컴파일·호환성 검증이 필요하므로 Java·Python·컨테이너 워크로드부터 접근하세요.
- EBS는 gp3를 기본으로 합니다. IOPS·처리량을 용량과 분리해 지정할 수 있어 gp2보다 비용 효율이 좋습니다.
- 이전 직후는 여유 있게, 2주 후 조정합니다. 컷오버 당일에 사이징 논쟁을 하지 않는 것이 중요합니다.
비용 산정에서 빠뜨리기 쉬운 항목
| 항목 | 주의점 |
|---|---|
| 데이터 전송(아웃바운드) | 대외 서비스 트래픽이 많으면 서버 비용보다 커질 수 있습니다. CloudFront 적용으로 상당 부분 절감됩니다. |
| NAT Gateway | 시간당 요금 + 처리 데이터 요금이 동시에 부과됩니다. AZ마다 두면 그만큼 늘어납니다. |
| 백업·스냅샷 | EBS 스냅샷 보관 정책이 없으면 조용히 누적됩니다. |
| Windows·상용 DB 라이선스 | BYOL 가능 여부와 라이선스 이동 조건을 사전에 확인해야 합니다. |
| 이전 기간 중 이중 비용 | 온프레미스와 AWS를 병행 운영하는 기간의 비용을 예산에 반영하세요. |
| Direct Connect | 회선 신청부터 개통까지 수 주~수 개월이 걸립니다. 일정의 임계 경로가 되기 쉽습니다. |
안정화 이후에는 Savings Plans·Reserved Instance로 상시 가동 워크로드의 비용을 크게 낮출 수 있습니다. 다만 이전 직후 사이징이 확정되지 않은 상태에서 장기 약정을 걸면 오히려 손해입니다. 최소 1~2개월 실사용 데이터를 본 뒤 약정하세요.
STEP 4. 랜딩 존과 네트워크 설계
서버를 옮기기 전에 받을 그릇을 먼저 만듭니다. 여기서의 설계 실수는 나중에 되돌리기가 가장 비쌉니다.
① IP 대역 설계 — 가장 먼저 확정
VPC CIDR을 온프레미스 대역과 겹치지 않게 잡아야 합니다. 겹치면 VPN·Direct Connect 라우팅이 성립하지 않고, 뒤늦게 발견되면 재구축 외에 답이 없습니다. 향후 확장·피어링·타 기관 연계까지 고려해 여유 있게 할당하세요.
② 서브넷 구조
퍼블릭/프라이빗 서브넷을 최소 2개 AZ에 걸쳐 구성하는 것이 기본입니다. 온프레미스에서 옮겨오는 서버 대부분은 프라이빗 서브넷에 두고, 인터넷 노출은 ALB·NAT Gateway를 통해서만 이루어지도록 합니다. 구체적인 설계는 AWS 퍼블릭·프라이빗 서브넷 구성을 참고하세요.
③ 온프레미스 연결
| 방식 | 대역폭·지연 | 준비 기간 | 용도 |
|---|---|---|---|
| Site-to-Site VPN | 인터넷 경유, 변동적 | 수 시간 | 파일럿, 소규모 이전, DX 백업 경로 |
| Direct Connect | 전용 회선, 안정적 | 수 주~수 개월 | 대용량 복제, 하이브리드 상시 운영 |
| 공인 인터넷(직접) | 가장 단순 | 즉시 | 에이전트가 공인망으로 직접 복제 가능한 경우 |
복제 트래픽이 큰 프로젝트라면 Direct Connect 신청을 프로젝트 첫날에 넣으세요. 나머지 준비가 끝나도 회선이 없으면 아무것도 진행되지 않습니다.
④ 보안 기준선
서버가 들어오기 전에 계정 수준의 보안 설정을 먼저 켭니다 — CloudTrail 전 리전 활성화, GuardDuty, Security Hub, 루트 계정 MFA, IAM 최소 권한, S3 퍼블릭 액세스 차단. 이전이 끝난 뒤 소급 적용하는 것보다 훨씬 저렴합니다. AWS와 고객의 책임 경계는 AWS 공동 책임 모델에서 정리했습니다.
STEP 5. 이전 도구 선택 — 데이터 종류별로 다르다
"마이그레이션 도구 하나"로 전부 옮기는 것이 아닙니다. 대상별로 도구가 다릅니다.
| 대상 | 도구 | 특징 |
|---|---|---|
| 서버 전체(OS 포함) | AWS Application Migration Service (MGN) | 블록 레벨 연속 복제. 에이전트 설치 후 백그라운드 복제, 짧은 컷오버. 서버당 90일간 무료 사용. |
| 동종 DB (Oracle→Oracle 등) | AWS DMS | 전체 적재 후 CDC로 변경분 추적 → 중단 시간 최소화 |
| 이기종 DB (Oracle→PostgreSQL) | DMS + 스키마 변환 | 스토어드 프로시저·트리거 변환에 별도 공수 필요. 별개 프로젝트로 취급하세요. |
| 파일 서버·NAS | AWS DataSync | NFS·SMB를 S3·EFS·FSx로 전송. 증분 동기화 지원 |
| 대용량(수십 TB~PB) | AWS Snow Family | 물리 장비로 오프라인 전송. 회선 대역폭이 부족할 때 |
| 백업 데이터 | Storage Gateway / S3 | 기존 백업 소프트웨어의 타깃을 클라우드로 전환 |
MGN 기반 리호스팅의 실제 흐름
1. 스테이징 서브넷 준비 복제 서버가 뜰 프라이빗 서브넷
2. 소스 서버에 에이전트 설치 Linux/Windows 각각의 설치 스크립트
3. 초기 복제 (Initial Sync) 전체 디스크 1회 전송 — 가장 오래 걸림
4. 지속 복제 (Continuous) 변경 블록만 실시간 전송
5. 테스트 인스턴스 기동 운영 무중단 상태로 검증
6. 컷오버 소스 정지 → 최종 동기화 → 인스턴스 기동
7. 정리 (Finalize) 스테이징 리소스 정리방화벽에서 열어야 하는 대표 포트는 소스 서버 → 스테이징 복제 서버 TCP 1500, 소스 서버 → MGN 엔드포인트 TCP 443입니다. 초기 복제 소요 시간은 단순 계산으로 추정할 수 있습니다 — 10TB를 100Mbps로 보내면 산술적으로 9일 이상입니다. 웨이브 일정의 현실성은 결국 대역폭이 결정합니다.
STEP 6. 웨이브 계획 — 무엇을 언제 옮길지
수백 대를 한 번에 옮기지 않습니다. 의존 관계로 묶인 단위(웨이브)로 나누어 순차 이전합니다.
- 웨이브 1은 반드시 저위험 시스템으로 — 내부 테스트·개발 서버, 사용자 수가 적은 시스템. 팀이 절차를 몸에 익히는 것이 목적입니다.
- 서로 통신하는 서버는 같은 웨이브로 묶습니다. 애플리케이션 서버만 옮기고 DB를 남기면 지연 시간 때문에 성능이 무너집니다.
- 웨이브 간 안정화 기간을 최소 1주 확보합니다. 문제 발생 시 다음 웨이브를 미룰 수 있는 여유가 필요합니다.
- 결산·정산 등 업무 피크 시기는 비웁니다. 기술 일정이 아니라 업무 일정이 웨이브 순서를 결정합니다.
STEP 7. 컷오버 플레이북
컷오버는 즉흥적으로 하는 작업이 아닙니다. 아래 항목이 문서로 준비되어 있어야 합니다.
D-7 ~ D-1
- DNS TTL을 300초 이하로 단축 (전환 당일 반영 속도를 좌우합니다)
- 테스트 인스턴스로 기능·성능·연계 검증 완료
- Service Quotas(vCPU·EBS·EIP) 사전 증설 신청
- 업무 중단 공지 발송, 담당자별 대기 체계 확정
- 롤백 기준과 결정권자를 명문화 — "몇 시까지 무엇이 안 되면 되돌린다"
컷오버 당일
1. 서비스 중단 공지 게시
2. 소스 서버 애플리케이션 정지 (쓰기 차단)
3. 최종 동기화 완료 확인 (Lag = 0)
4. 타깃 인스턴스 기동
5. 스모크 테스트 — 로그인 / 핵심 트랜잭션 / 연계 배치 / 백업
6. DNS 전환 (또는 로드밸런서 타깃 변경)
7. 모니터링 집중 관찰 (최소 24시간)
8. 판정: 정상 → 안정화 / 이상 → 롤백STEP 8. 이전 후 — 여기서 끝나지 않는다
- 사이징 재조정 — 2주간 CloudWatch 지표를 보고 과다·과소 산정을 바로잡습니다. Compute Optimizer의 권장 사항이 출발점입니다.
- 요금제 최적화 — 사용량이 안정되면 Savings Plans를 적용합니다. 개발·테스트 서버는 야간·주말 자동 정지만으로도 큰 폭의 절감이 가능합니다.
- 운영 자동화 — 백업(AWS Backup), 패치(Systems Manager), 로그 수집·대시보드를 표준화합니다. CloudWatch 대시보드 구성이 참고가 됩니다.
- 보안 점검 — 이전 과정에서 임시로 열어둔 보안 그룹·IAM 권한을 회수합니다. 공공기관이라면 CSAP·ISMS-P 요건과의 정합성을 확인하세요.
- 현대화 착수 — 이제 Replatform·Refactor를 논의할 시점입니다. DB의 RDS 전환, 컨테이너화, 서버리스 전환을 우선순위에 따라 진행합니다.
- 온프레미스 정리 — 자산 폐기, 회선 해지, 데이터센터 계약 종료. 이 단계를 잊으면 이전의 비용 효과가 사라집니다.
자주 부딪히는 문제와 대응
| 증상 | 원인 | 대응 |
|---|---|---|
| 복제가 시작되지 않음 / Stalled | TCP 1500 또는 443 차단 | 방화벽·보안 그룹·NACL에서 소스 → 스테이징 경로 점검 |
| 초기 복제가 계획보다 오래 걸림 | 대역폭 부족, 불필요한 볼륨 포함 | 복제 제외 디스크 조정, 스로틀 설정 검토, 웨이브 재분할 |
| 이전 후 애플리케이션 기동 실패 | 하드코딩된 IP·호스트명 | 설정 파일·hosts 점검, 필요 시 온프레미스 IP 대역 유지 설계 |
| 이전 후 응답 속도 저하 | 앱과 DB가 서로 다른 환경에 분리됨 | 연동 구간을 같은 웨이브로 묶어 재이전 |
| 구형 OS 에이전트 설치 실패 | MGN 미지원 OS·커널 | OS 업그레이드 또는 재구축(Replatform) 전환 |
| 컷오버 시 인스턴스 기동 실패 | vCPU·EBS 쿼터 초과 | 웨이브 실행 전 Service Quotas 증설 신청 |
| DNS 전환 후 일부 사용자만 구 서버 접속 | TTL 미단축, 클라이언트 캐시 | 사전 TTL 단축, 구 서버에서 신 서버로 임시 리다이렉트 |
| 이전 후 비용이 예상보다 큼 | 1:1 스펙 매핑, NAT·전송 비용 누락 | Compute Optimizer 기반 재사이징, 아키텍처 조정 |
진행 체크리스트
- ☐ 전체 서버 인벤토리 확보 (성능 데이터 2주 이상 포함)
- ☐ 서버별 7R 전략 배정, Retire 대상 선별 완료
- ☐ TCO 비교 및 이전 기간 이중 비용 예산 반영
- ☐ VPC CIDR이 온프레미스 대역과 중복되지 않음
- ☐ 온프레미스 ↔ AWS 연결 방식 확정 및 회선 신청 완료
- ☐ 복제 포트(TCP 1500 / 443) 개방
- ☐ 대역폭 기준 초기 복제 소요 시간 산정
- ☐ 계정 보안 기준선(CloudTrail·GuardDuty·MFA·IAM) 선적용
- ☐ 대상 OS·DB의 도구 지원 여부 확인
- ☐ 웨이브 계획 수립 (웨이브 1 = 저위험)
- ☐ Service Quotas 사전 증설
- ☐ DNS TTL 사전 단축
- ☐ 웨이브별 롤백 기준·결정권자 문서화
- ☐ 컷오버 스모크 테스트 시나리오 작성
- ☐ 소스 서버 보존 기간 정의
- ☐ 이전 후 재사이징·요금제 최적화 일정 확보
- ☐ 온프레미스 자산·회선 정리 계획
맺음말
온프레미스 서버를 AWS로 옮기는 일에서 기술적으로 어려운 부분은 사실 많지 않습니다. MGN은 에이전트를 설치하면 알아서 복제하고, DMS는 CDC로 중단 시간을 줄여 줍니다. 프로젝트의 성패를 가르는 것은 대상 목록의 정확성, 대역폭에 근거한 일정, 웨이브 순서 판단, 그리고 롤백 기준입니다. 도구가 실행을 맡고 사람이 판단을 맡는 구조로 설계하면, 데이터센터 계약 만료 같은 확정된 기한 안에서도 예측 가능한 이전이 가능합니다.
JC Cloud는 Cloud Readiness Assessment부터 마이그레이션 전략 수립(MRA/MRP)과 실행, 이전 후 운영·보안 관제까지 전 과정을 지원합니다. 현황 진단이 필요하시면 문의해 주세요.
참고 자료
- AWS Prescriptive Guidance — Large migration guide
- AWS Prescriptive Guidance — Migration portfolio assessment
- AWS Application Migration Service 사용자 가이드
- AWS MGN — 지원 운영체제
- AWS MGN — 네트워크 요구사항 (포트 1500·443)
- AWS Database Migration Service 사용자 가이드
- AWS DataSync 사용자 가이드
- AWS Snowball Edge 개발자 가이드
- AWS Compute Optimizer 사용자 가이드
- AWS Compute Savings Plans