경영진이 "올해 안에 데이터센터 비우고 전부 클라우드로"라고 선언합니다. 팀은 200개 시스템을 똑같이 클라우드 VM으로 복사(lift-and-shift)했습니다. 1년 뒤, 청구서는 온프레보다 컸고, 정작 절반은 아무도 안 쓰는 시스템이었습니다. 마이그레이션은 '전부 그대로 옮기기'가 아니라, 시스템마다 옮길지·바꿀지·버릴지를 가르는 결정입니다. 그 결정 프레임이 6R입니다.
- 16R 전략(rehost·replatform·repurchase·refactor·retain·retire)을 구분할 수 있다
- 2rehost(lift-and-shift)의 장점과 함정을 안다
- 3replatform과 refactor의 비용·효과 트레이드오프를 판단할 수 있다
- 4'안 옮기거나 없애는' 결정(retain/retire)도 전략임을 이해한다
- 5워크로드 우선순위로 단계적 이전을 설계할 수 있다
시스템마다 다르게 — 6R 프레임
6R — 옮길 것과 바꿀 것, 그리고 안 건드릴 것
모든 시스템을 같은 방식으로 옮기면 망합니다. 6R은 시스템별로 결정합니다:
- Rehost(lift-and-shift): 거의 그대로 VM으로 옮김 — 가장 빠름·위험 작음
- Replatform(lift-tinker-shift): 일부를 관리형으로 교체(자체 DB→RDS) — 적은 변경, 운영 부담↓
- Repurchase: 자체 운영을 SaaS로 교체(메일·CRM 등) — 직접 운영 종료
- Refactor(re-architect): 클라우드 네이티브로 재설계(서버리스·MSA) — 효과 크지만 비용·위험·기간↑
- Retain: 지금은 온프레에 둠(규제·종속성·낮은 우선순위)
- Retire: 안 쓰는 시스템 폐기 — 이전 비용 0 + 운영비 절감
위 그림처럼 마이그레이션은 발견 → 계획 → 전환 → 최적화의 단계를 거칩니다. 가장 단순한 서비스로 파일럿을 먼저 진행해 팀 역량을 키웁니다.
위 그림처럼 기능 단위로 새 서비스로 이전하면서, 파사드(API 게이트웨이)가 요청을 새 서비스 또는 레거시로 라우팅합니다. 서비스 중단 없이 단계적으로 전환할 수 있습니다.
lift-and-shift는 시작이지 끝이 아니다
Rehost는 대규모 이전의 합리적 1단계입니다 — 빠르게 데이터센터를 비우고 위험을 줄입니다. 하지만 그대로 두면 온프레 비효율(과대 사양·상시 가동·자체 운영)이 따라와 클라우드에서 더 비싸집니다(왜 클라우드인가의 lift-and-shift 함정).
그래서 rehost 후 점진적 최적화가 따라붙습니다: rightsizing(가상 서버(EC2)) → 관리형 전환(관리형 데이터베이스(RDS)) → 예약/스팟·오토스케일(클라우드 비용 최적화·오토스케일링 + 로드밸런서). 비용은 '옮긴 직후'가 아니라 '최적화 후'에 평가합니다.
안 옮기는 것도 결정이다 — Retain과 Retire
자산을 실제로 조사하면 의외로 많은 시스템이 아무도 안 씁니다(Retire 대상). 폐기하면 이전 비용 0 + 운영비 절감 — 가장 저렴한 '마이그레이션'입니다.
Retain은 규제로 데이터를 특정 시설에 둬야 하거나(IaaS·PaaS·SaaS와 리전·AZ의 데이터 주권), 강한 종속성·낮은 우선순위로 당분간 온프레에 두는 결정입니다. "전부 옮긴다"는 구호보다, 시스템별 가치·위험·비용으로 판단하는 것이 성숙한 전략입니다.
6R 판단의 출발점은 정확한 자산 목록과 실제 사용량입니다. 안 쓰는 것(Retire)·의존성(Retain)을 먼저 가립니다.
# 예: 온프레 서버의 최근 접속/트래픽으로 '실사용' 판별
ss -tnp | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head
# 30일간 트래픽 0인 서비스 → Retire 후보, 강결합 서비스 → 함께 이전(이전 그룹)
1240 10.0.0.21 # 활발 — 우선 이전
0 10.0.0.88 # 30일 트래픽 0 — Retire 후보
(자산 조사)rehost 직후 비용으로 성패를 판단하지 말고, 최적화 사이클을 돌린 뒤 추세로 봅니다(클라우드 비용 최적화).
aws ce get-cost-and-usage --time-period Start=2026-05-01,End=2026-06-01 \
--granularity MONTHLY --metrics UnblendedCost \
--query "ResultsByTime[0].Total.UnblendedCost"
{ "Amount": "18420.55", "Unit": "USD" }
aws ce get-cost-and-usage- 30일+ 트래픽/접속 0인 시스템 — Retire 후보. 폐기가 가장 저렴한 이전. 의존성만 재확인 후 정리
- rehost 후 CPU/메모리 사용률이 한 자릿수인 인스턴스 — 온프레 사양 그대로 옮긴 과대 프로비저닝. rightsizing 대상(가상 서버(EC2))
- 강하게 결합된(서로 동기 호출·공유 DB) 시스템들 — 따로 옮기면 지연·장애. 이전 그룹(wave)으로 묶어 함께 이전
- 규제 대상 데이터(개인정보·금융) — 허용 리전·온프레 유지 여부 확인. Retain 판단의 핵심(IaaS·PaaS·SaaS와 리전·AZ)
상황: 의존성을 무시한 부분 이전으로 하이브리드 구간에서 성능·안정성 저하.
원인: 서로 자주 동기 호출하거나 같은 DB를 공유하는 시스템을 분리하면, 온프레↔클라우드 왕복 지연이 매 호출에 더해지고 한쪽 장애가 전파됩니다(Networking의 지연·라우팅).
진단: 시스템 간 호출 빈도·지연 측정 → 어떤 시스템들이 강결합인지 의존성 맵 작성 → 이전 그룹(wave) 경계가 결합을 가로지르는지 확인.
해결: 강결합 시스템은 함께(같은 wave) 이전하거나, 이전 전에 결합을 느슨하게(비동기 큐 메시지 큐와 이벤트, API 경계화). 불가피한 하이브리드 구간은 전용 회선·캐시로 왕복을 줄이고 기간을 짧게. '하나씩 옮기기'의 단위는 시스템이 아니라 결합 단위입니다.
PM·아키텍트에게 마이그레이션은 단골 의사결정입니다. "클라우드로 다 옮기죠"라는 구호에 6R로 답할 수 있어야 합니다 — "핵심 결제는 refactor로 네이티브화, 표준 웹앱은 rehost 후 최적화, 메일·CRM은 SaaS로 repurchase, 규제 데이터는 retain, 안 쓰는 50개는 retire"처럼 시스템별 전략을 제시하는 것이 성숙한 답입니다.
실무 함정: ① 인벤토리·의존성 조사 없이 시작해 강결합을 쪼개다 사고, ② lift-and-shift 후 최적화를 안 해 비용 폭증, ③ Retire 대상을 안 가려 안 쓰는 것까지 옮김. 마이그레이션은 기술 작업이기 전에 자산·가치·위험을 가르는 포트폴리오 결정입니다. 옮긴 뒤에는 이 트랙 전체(VPC와 서브넷·IaC와 Terraform·관측과 거버넌스)가 운영의 기반이 됩니다.
이로써 '왜 클라우드인가'(왜 클라우드인가)에서 시작해 '어떻게 옮기는가'까지 이어졌습니다. 옮긴 인프라를 코드로 선언·운영하는 IaC와 Terraform, 비용을 최적화하는 클라우드 비용 최적화가 마이그레이션 후속의 핵심입니다.