Cloud Migration
온프레미스에서 클라우드로, 혹은 클라우드에서 클라우드로. 6R 전략부터 마이그레이션 프로세스, AWS MGN·DMS까지.
| Category | Level | Reads | Status |
|---|---|---|---|
| Cloud Computing · Migration | 중급 | 약 15분 | VERIFIED |
마이그레이션이란?
마이그레이션은 애플리케이션과 데이터를 한 환경에서 다른 환경으로 옮기는 작업이다. 대부분은 온프레미스(직접 운영하는 서버)에서 클라우드로, 혹은 한 클라우드에서 다른 클라우드로 옮기는 것을 뜻한다.
이사에 비유하면 딱 맞다. 짐을 그대로 트럭에 실어 나를지, 이참에 정리하며 옮길지, 아니면 낡은 가구는 버리고 새로 살지 — 마이그레이션도 똑같은 선택의 문제다. 그리고 이사가 그렇듯, 계획 없이 시작하면 며칠이면 끝날 일이 몇 달씩 걸리고 만다.
왜 마이그레이션 하는가
온프레미스는 서버를 직접 사서, 직접 설치하고, 직접 유지보수해야 한다. 트래픽이 늘면 서버를 새로 주문하고 배송받는 데만 몇 주가 걸리고, 반대로 트래픽이 줄어도 이미 산 서버 비용은 그대로 나간다.
클라우드로 옮기면 확장성, 관리 부담 감소, 사용한 만큼만 내는 비용 구조를 얻는다. 하지만 마이그레이션 자체는 비용과 위험이 큰 프로젝트라, 어떻게 옮길지에 대한 전략이 반드시 필요하다.
마이그레이션 6대 전략 (6 R's)
AWS가 정리한 프레임워크로, 무엇을 얼마나 바꿔서 옮길지에 따라 6가지로 나뉜다. 아래로 갈수록 손이 많이 가지만 장기적 이득도 커진다.
코드 변경 없이 그대로 클라우드 서버로 옮긴다. "Lift and Shift"라고도 부른다. 가장 빠르고 쉽다.
큰 구조는 유지하되, DB를 관리형 서비스로 바꾸는 등 일부만 최적화해서 옮긴다.
기존 솔루션을 버리고 SaaS 같은 새 제품으로 갈아탄다. 예: 자체 구축 CRM → Salesforce.
클라우드 네이티브 구조(서버리스, MSA 등)로 아예 다시 설계한다. 가장 오래 걸리지만 이점도 가장 크다.
더는 필요 없는 애플리케이션은 그냥 없앤다. 옮길 필요 자체가 없다.
당장은 그대로 온프레미스에 남겨둔다. 규제, 의존성 등의 이유로 나중으로 미룬다.
Rehost 전략을 부르는 다른 이름. 코드를 거의 건드리지 않고 인프라만 통째로 들어서 옮긴다는 의미다.
전략별 비교
| 전략 | 속도 | 초기 비용 | 장기적 이득 |
|---|---|---|---|
| Rehost | 빠름 | 낮음 | 낮음 |
| Replatform | 중간 | 중간 | 중간 |
| Repurchase | 중간 | 중간 | 중간~높음 |
| Refactor | 느림 | 높음 | 높음 |
실무에서는 하나의 전략만 쓰기보다, 애플리케이션마다 다른 전략을 섞어서 적용하는 경우가 대부분이다. 급한 건 Rehost로 빠르게 옮기고, 핵심 서비스는 시간을 들여 Refactor하는 식이다.
마이그레이션 프로세스
서버 구입비뿐 아니라 전력, 유지보수, 인건비까지 포함한 총 소유 비용. 마이그레이션 평가 단계에서 온프레미스 TCO와 클라우드 예상 비용을 비교하는 게 첫 걸음이다.
마이그레이션의 장단점
- 확장성 확보 — 트래픽에 따라 자유롭게 자원 조절 가능
- 관리 부담 감소 — 하드웨어 유지보수를 클라우드에 위임
- 글로벌 인프라 활용 — 여러 리전에 손쉽게 서비스 배포
- 마이그레이션 자체에 상당한 시간·비용이 듦
- 다운타임·데이터 정합성 문제가 발생할 수 있음
- 클라우드 벤더 종속(Lock-in) 위험
- 기존 인력의 클라우드 역량 재교육이 필요함
AWS 마이그레이션 서비스
Application Migration Service. 서버를 통째로 복제해 클라우드로 옮기는 Rehost 전문 도구. 지속적으로 데이터를 복제하다가 실제 전환(Cutover) 순간 최소 다운타임으로 넘어간다.
Database Migration Service. 이기종 DB 간 마이그레이션도 지원하며, 서비스 중단 없이 데이터를 실시간 동기화하는 CDC 방식을 지원한다.
여러 도구로 진행 중인 마이그레이션 작업들의 진행 상황을 한곳에서 추적·관리하는 대시보드.
페타바이트급 대용량 데이터는 네트워크로 옮기기 비효율적이라, 물리 장비를 직접 배송받아 데이터를 담아 보내는 방식.
원본 DB에서 변경되는 데이터를 실시간으로 감지해 대상 DB에 계속 반영하는 기법. 마이그레이션 도중에도 서비스를 멈추지 않고 최신 데이터를 유지할 수 있게 해준다.
실무 적용 방식 — 다운타임 최소화
가장 흔한 실무 패턴은 단계적 마이그레이션이다. 위험이 적은 서비스 하나로 파일럿을 진행해 경험을 쌓고, 점차 범위를 넓혀간다.
다운타임을 최소화하려면 앞서 CI/CD 글에서 다룬 Blue/Green 개념이 여기서도 그대로 쓰인다 — 새 클라우드 환경(Green)을 완전히 준비해두고 CDC로 데이터를 실시간 동기화하다가, 준비가 끝나면 트래픽을 한 번에 전환(Cutover)하는 방식이다. 문제가 생기면 기존 환경(Blue)으로 즉시 되돌릴 수 있다.
어떤 전략을 언제 쓸까
일정이 촉박하거나, 레거시 시스템이라 손대기 부담스러운 경우. 일단 옮기고 최적화는 나중에.
핵심 비즈니스 서비스라 장기적으로 확장성·비용 효율이 중요한 경우. 시간을 들일 가치가 있다.