온프레미스에서 Azure로 옮기는 프로젝트가 실패하는 방식은 대체로 비슷합니다. 기술적으로 안 되는 경우는 드물고, 대개 예상보다 오래 걸리거나 비용이 예상의 몇 배가 되거나 성능이 떨어져서 되돌립니다.
이 글은 마이그레이션 도구 사용법이 아니라, 그 세 가지를 미리 막기 위해 각 단계에서 확인해야 할 것들입니다. 순서대로 밟으면 대부분의 놀랄 일이 사전에 드러납니다.
1단계 — 인벤토리와 의존성 파악
가장 먼저, 그리고 가장 자주 부실하게 하는 단계입니다. “서버 몇 대”만 세고 넘어가면 이후 모든 계획이 어긋납니다.
Azure Migrate의 어플라이언스를 온프레미스에 배포하면 자동으로 수집됩니다. 여기서 반드시 켜야 할 것이 의존성 분석입니다.
- 서버 스펙과 실제 사용률 — 할당된 CPU가 아니라 실제로 쓰는 양
- 서버 간 통신 관계 — 어떤 서버가 어떤 서버의 몇 번 포트로 통신하는지
- 외부 의존성 — 라이선스 서버, 인증 서버, 외부 API
- 디스크 IOPS 실측치 — 용량보다 중요합니다
두 번째가 특히 중요합니다. 의존성 지도가 없으면 마이그레이션 그룹을 잘못 나눕니다. A 서버만 옮겼는데 온프레미스의 B 서버와 초당 수천 번 통신하고 있었다면, 그 통신이 전부 인터넷이나 VPN을 타면서 지연과 비용이 폭증합니다.
함께 통신하는 서버들은 함께 옮겨야 합니다. 이걸 “마이그레이션 웨이브”로 묶는 작업이 1단계의 실질적 산출물입니다.
2단계 — 비용을 실제 사용률로 산정
여기서 대부분의 비용 초과가 예방됩니다. 핵심은 현재 스펙 그대로 옮기지 않는 것입니다.
온프레미스 서버는 대개 과대 프로비저닝되어 있습니다. 5년 쓸 것을 감안해 넉넉히 샀고, 한 번 사면 줄일 수 없었기 때문입니다. 그 스펙을 그대로 클라우드로 옮기면 매달 그 낭비를 지불하게 됩니다.
| 산정 방식 | 기준 | 결과 |
|---|---|---|
| 온프레미스 스펙 기준 | 할당된 vCPU·메모리 | 과다 산정. 실제의 2~3배 |
| 성능 기반 산정 | 실측 p95 사용률 | 현실적 |
Azure Migrate에서 “성능 기반” 크기 조정 옵션을 선택하면 실측 데이터로 VM 크기를 추천합니다. 이때 수집 기간을 최소 2주 이상 두세요. 월말 배치나 주간 피크가 포함되어야 합니다.
그리고 비용 산정에 반드시 반영해야 할 항목들이 있습니다. 빠뜨리면 견적이 실제보다 크게 낮아집니다.
- 송신 트래픽(Egress) — 온프레미스로 나가는 데이터, 사용자에게 나가는 데이터. 온프레미스에서는 무료였던 항목입니다
- 백업 스토리지 — 보호된 인스턴스 요금 + 용량. GRS면 2배
- Log Analytics 수집 — 모니터링을 붙이면 발생. 의외로 큽니다
- Azure Firewall·App Gateway — 배포만 해도 시간당 고정 요금
- 비운영 환경 — 개발·테스트도 함께 옮긴다면 별도 계산
반대로 절감 요인도 반영하세요. Azure Hybrid Benefit(보유 Windows Server·SQL 라이선스), 예약 인스턴스, 개발 환경 자동 종료가 대표적입니다. 이 셋을 반영하면 견적이 크게 달라집니다. 자세한 판단 기준은 Reserved·Savings Plan·Spot 선택 기준에 정리했습니다.
3단계 — 마이그레이션 방식 결정 (6R)
모든 서버를 같은 방식으로 옮길 필요가 없습니다. 워크로드별로 다르게 판단합니다.
| 방식 | 내용 | 적합한 경우 | 난이도 |
|---|---|---|---|
| Rehost (리프트앤시프트) | VM 그대로 이전 | 기한이 촉박, 변경 위험 회피 | 낮음 |
| Replatform | PaaS로 일부 전환 | SQL Server → Azure SQL MI 등 | 중간 |
| Refactor | 구조 개편 | 컨테이너·서버리스 전환 | 높음 |
| Repurchase | SaaS로 교체 | 메일·그룹웨어 등 | 중간 |
| Retire | 폐기 | 아무도 안 쓰는 서버 | — |
| Retain | 온프레미스 유지 | 규제·하드웨어 의존 | — |
Retire를 먼저 검토하세요. 1단계 인벤토리를 해보면 아무도 접속하지 않는 서버, 몇 년째 로그만 쌓는 서버가 반드시 나옵니다. 옮기지 않는 게 가장 싼 마이그레이션입니다. 의존성 분석에서 인바운드 연결이 0인 서버가 후보입니다.
실무적으로는 Rehost로 먼저 옮기고, 안정화 후 Replatform하는 2단계 접근이 안전합니다. 이전과 현대화를 동시에 하면 문제가 생겼을 때 원인이 이전 때문인지 구조 변경 때문인지 구분이 안 됩니다.
4단계 — 네트워크와 ID를 먼저 준비
서버를 옮기기 전에 받을 준비가 되어 있어야 합니다. 이 순서를 지키지 않으면 옮긴 서버가 아무것도 못 합니다.
- 주소 대역 설계 — 온프레미스와 겹치지 않게. 겹치면 VPN 연결 자체가 안 됩니다
- 하이브리드 연결 — VPN 게이트웨이 또는 ExpressRoute. 대역폭이 마이그레이션 속도를 좌우합니다
- DNS 통합 — Azure에서 온프레미스 이름을, 온프레미스에서 Azure 이름을 해석할 수 있어야 합니다
- ID 통합 — AD 도메인 컨트롤러를 Azure에 두거나 사이트 간 인증 경로 확보
# 온프레미스 대역과 겹치지 않게 설계 (예)
온프레미스: 192.168.0.0/16
Azure 운영: 10.10.0.0/16
Azure 비운영: 10.20.0.0/16
# VNet 생성
az network vnet create \
--name vnet-prod-krc-01 -g rg-prod-network \
--address-prefix 10.10.0.0/16 \
--subnet-name snet-app --subnet-prefix 10.10.1.0/24
# 연결 후 대역 중복 여부 확인
az network vnet list --query "[].{name:name, prefixes:addressSpace.addressPrefixes}" -o table3번 DNS를 간과하는 경우가 많습니다. Azure로 옮긴 애플리케이션이 온프레미스 DB를 이름으로 참조하고 있었다면, 이름 해석이 안 되어 연결이 실패합니다. IP로 바꾸는 건 임시방편일 뿐입니다.
구독·리소스 그룹 구조도 이 시점에 정해야 합니다. 나중에 바꾸기 어려운 결정들입니다. 미니멀 Azure 랜딩 존에 최소 구조를 정리해두었습니다.
5단계 — 파일럿 웨이브로 검증
전체를 한 번에 옮기지 않습니다. 중요도가 낮으면서 대표성이 있는 워크로드를 먼저 옮겨 계획을 검증합니다.
파일럿에서 반드시 측정할 것들입니다.
- 실제 복제 소요 시간 — 전체 일정 산출의 근거가 됩니다. 대역폭 제약이 여기서 드러납니다
- 전환(cutover) 소요 시간 — 서비스 중단 창을 얼마나 잡아야 하는지
- 성능 비교 — 특히 디스크 IOPS와 애플리케이션 응답 시간
- 실제 청구 금액 — 견적과 얼마나 차이 나는지
세 번째가 자주 문제가 됩니다. 온프레미스의 로컬 SSD에서 돌던 DB를 Azure의 표준 디스크로 옮기면 체감할 정도로 느려집니다. VM 크기 자체에도 IOPS 상한이 있으므로, 디스크만 좋은 걸 붙인다고 해결되지 않습니다. VM 시리즈 선택 가이드의 IOPS 상한 부분을 참고하세요.
데이터 이전: 대역폭이 일정을 결정한다
계획에서 가장 자주 틀리는 숫자가 데이터를 옮기는 데 걸리는 시간입니다. 산술적으로 먼저 계산해보면 현실이 보입니다.
| 데이터 양 | 100 Mbps | 500 Mbps | 1 Gbps |
|---|---|---|---|
| 1 TB | 약 23시간 | 약 5시간 | 약 2.3시간 |
| 10 TB | 약 10일 | 약 2일 | 약 1일 |
| 50 TB | 약 48일 | 약 10일 | 약 5일 |
| 100 TB | 약 96일 | 약 19일 | 약 10일 |
이 표는 회선을 100% 점유했을 때의 이론값입니다. 실제로는 업무 트래픽과 공유하므로 더 걸립니다. 낮에는 대역폭을 제한하고 야간에만 전속력으로 돌리는 구성이 일반적인데, 그러면 시간이 배로 늘어납니다.
계산해보고 일정이 안 나오면 선택지는 셋입니다.
- 회선 증설 — ExpressRoute 등. 리드타임이 몇 주 걸립니다
- Azure Data Box — 물리 장비에 데이터를 담아 배송. 수십~수백 TB에는 이쪽이 현실적입니다
- 데이터 정리 — 안 쓰는 데이터를 안 옮기는 것. 의외로 효과가 큽니다
세 번째를 먼저 하세요. 파일 서버를 열어보면 몇 년째 접근 기록이 없는 데이터가 상당 비중인 경우가 많습니다. 그걸 옮기지 않거나, 옮기더라도 Archive 티어로 바로 보내면 이전 시간과 이후 비용이 모두 줄어듭니다.
라이선스와 지원 종료를 함께 점검
기술 외적인 항목인데 프로젝트 후반에 문제가 되는 경우가 많습니다.
- Windows Server·SQL Server 라이선스 — Software Assurance가 있으면 Azure Hybrid Benefit으로 가져갈 수 있습니다. 없으면 클라우드 요금에 라이선스 비용이 포함되어 견적이 크게 달라집니다
- 서드파티 소프트웨어 — 물리 코어 기준 라이선스가 클라우드에서 어떻게 계산되는지 벤더에 확인이 필요합니다. MAC 주소나 하드웨어 ID에 묶인 라이선스는 이전 시 재발급을 받아야 합니다
- OS 지원 종료 — 지원이 끝난 OS를 그대로 옮기는 건 위험합니다. 다만 Azure에서는 일부 구버전에 확장 보안 업데이트가 제공되므로, 이전과 OS 업그레이드를 분리해서 진행할 여지가 있습니다
두 번째 항목은 반드시 계약 시작 전에 확인하세요. 마이그레이션이 절반쯤 진행된 상태에서 “이 소프트웨어는 클라우드에서 라이선스가 안 된다”는 답을 받으면 계획 전체가 흔들립니다.
6단계 — 전환과 롤백 계획
전환 당일에 필요한 것은 절차서와 되돌아갈 방법입니다. 롤백 계획 없이 전환하면, 문제가 생겼을 때 앞으로 나갈 수밖에 없어집니다.
- 전환 전 온프레미스 원본을 정지만 하고 삭제하지 않는다 (최소 2주)
- DNS TTL을 전환 며칠 전부터 짧게 줄여둔다 (예: 300초). 이게 롤백 속도를 결정합니다
- 전환 후 검증 체크리스트를 미리 만들어 순서대로 확인
- 롤백 판단 기준과 기한을 미리 정한다 (“3시간 내 미해결 시 롤백”)
- 롤백 시 그 사이 쌓인 데이터를 어떻게 할지 정해둔다
2번을 놓치면 롤백을 결정해도 DNS가 전파될 때까지 몇 시간을 더 기다립니다. TTL은 전환 최소 3일 전에 줄여두세요.
5번이 가장 어려운 부분입니다. 전환 후 몇 시간 동안 Azure에서 처리된 트랜잭션이 있다면, 롤백 시 그 데이터를 온프레미스로 되돌려야 합니다. 이 절차가 없으면 사실상 롤백이 불가능합니다. 그래서 전환 창을 짧게 잡고, 그 시간 동안은 쓰기를 막는 방식을 쓰기도 합니다.
조직 준비: 기술만큼 자주 문제가 되는 부분
마이그레이션 후 운영이 흔들리는 이유가 기술적 결함이 아닌 경우가 많습니다. 운영 방식이 달라졌는데 조직은 그대로이기 때문입니다.
- 비용 책임자가 없다 — 온프레미스는 한 번 사면 끝이었지만 클라우드는 매달 청구됩니다. 매달 청구서를 보고 판단할 사람이 정해져 있어야 합니다
- 변경 절차가 안 맞는다 — 서버 증설에 2주 걸리던 절차가 클라우드에서는 5분입니다. 절차를 그대로 두면 클라우드의 이점이 사라지고, 아예 없애면 통제가 사라집니다
- 모니터링 도구가 이중화된다 — 기존 온프레미스 모니터링과 Azure Monitor를 둘 다 쓰면 알림이 두 곳에서 옵니다. 어디를 봐야 하는지 정해야 합니다
- 권한 모델이 다르다 — 서버 관리자 계정 대신 RBAC 역할입니다. 누가 무엇을 할 수 있는지 다시 설계해야 합니다
첫 번째가 가장 큽니다. “클라우드 비용은 누구 예산인가”가 정해지지 않으면 아무도 최적화에 관심을 갖지 않습니다. 태그로 비용을 부서별로 나눠 보이게 하는 것이 그래서 중요합니다. 설정 방법은 태그·Policy 거버넌스에 정리했습니다.
흔한 실패 패턴 3가지
패턴 A — 이전과 현대화를 동시에
“어차피 옮기는 김에 컨테이너로 바꾸자”가 시작입니다. 문제가 생겼을 때 이전 때문인지 구조 변경 때문인지 구분이 안 되고, 일정이 두 배 이상 늘어납니다.
Rehost로 먼저 옮겨 안정화한 뒤 Replatform하는 2단계 접근을 권합니다. 옮기고 나면 클라우드에서 실제로 무엇이 병목인지 데이터가 쌓이므로, 현대화 대상을 더 정확히 고를 수 있다는 부수 효과도 있습니다.
패턴 B — 온프레미스 원본을 너무 빨리 지움
전환이 성공한 것처럼 보여서 원본을 정리했는데, 며칠 뒤에 월말 배치나 분기 정산처럼 주기가 긴 작업에서 문제가 드러나는 경우입니다. 그때는 되돌릴 방법이 없습니다.
최소 한 번의 월말 마감을 무사히 넘긴 뒤 원본을 정리하세요. 그동안 온프레미스 서버는 정지 상태로만 두면 됩니다.
패턴 C — 성능 기준선을 안 재둠
이전 후 “느려졌다”는 이야기가 나왔을 때, 비교할 숫자가 없으면 반박도 개선도 불가능합니다. 체감은 사람마다 다르고, 대개 새 환경이 더 느리게 느껴집니다.
이전 전에 온프레미스에서 아래 항목을 측정해두세요.
- 주요 화면·API의 응답 시간 p50·p95
- 대표 배치 작업의 총 소요 시간
- DB 주요 쿼리의 실행 시간
- 디스크 IOPS와 지연 시간
이 숫자가 있으면 이전 후 비교가 명확해집니다. 실제로 느려진 항목만 골라 대응할 수 있고, 대개는 디스크 계층 조정이나 VM 시리즈 변경으로 해결됩니다.
전환 직후 첫 주에 할 일
- 예산 알림 설정 — 실제 80% + 예측 100%. 신규 구독 첫 주 점검 참고
- 백업 정책 적용 및 복구 테스트 — 옮기자마자 백업 전략을 세웁니다
- 모니터링·알림 구성 — Monitor 알림 설계
- 공용 IP·관리 포트 정리 — 마이그레이션 중 임시로 연 것들을 닫습니다. Bastion 전환
- 2주 뒤 크기 재조정 — 실측 p95로 다시 맞춥니다. 이때 약정을 검토합니다
마지막 항목의 순서가 중요합니다. 크기를 줄인 다음에 약정해야 낭비를 3년간 확정하지 않습니다.
정리
- 의존성 분석을 켜고 함께 통신하는 서버를 웨이브로 묶는다
- 비용은 온프레미스 스펙이 아니라 실측 p95로 산정한다
- 송신 트래픽·백업·로그 수집을 견적에 반드시 포함한다
- Retire부터 검토한다 — 안 옮기는 게 가장 싸다
- 네트워크 대역·DNS·ID를 서버보다 먼저 준비한다
- 파일럿으로 복제 시간·전환 시간·성능·실제 청구액을 측정한다
- DNS TTL을 미리 줄이고 롤백 기준과 기한을 정해둔다
마이그레이션은 기술 문제보다 측정과 순서의 문제인 경우가 많습니다. 1·2단계에 시간을 충분히 쓰면 뒤가 편해집니다.