I. 개요
클라우드 마이그레이션 6R이란 온프레미스 애플리케이션을 클라우드로 전환할 때 적용하는 6가지 전략 유형으로, Gartner가 최초 5R을 제시하고 AWS가 6번째 전략(Retain)을 추가하여 완성하였다. 애플리케이션별 비즈니스 가치, 기술적 복잡도, 마이그레이션 비용·위험을 종합 평가하여 최적 전략을 선택한다.
II. 6R 전략 상세 비교
| 전략 | 별칭 | 정의 | 노력 | 클라우드 최적화 | 적합 대상 |
|---|---|---|---|---|---|
| Rehost | Lift & Shift | 코드 변경 없이 VM 이미지 그대로 이전 | 낮음 | 낮음 | 단기 마이그레이션 필요, 레거시 OS 의존 |
| Replatform | Lift, Tinker & Shift | 핵심 코드 유지, 관리형 서비스 일부 활용 | 중간 | 중간 | DB → RDS 전환, WAS → PaaS 이전 |
| Repurchase | Drop & Shop | 기존 솔루션을 SaaS 제품으로 교체 | 낮음 | 높음 | CRM→Salesforce, 그룹웨어→M365 |
| Refactor | Re-architect | 클라우드 네이티브 재설계(MSA·컨테이너·서버리스) | 높음 | 최대 | 핵심 비즈니스 차별화 시스템 |
| Retire | 폐기 | 불필요 애플리케이션 폐기 | 없음 | – | 중복·미사용 시스템(전체 포트폴리오의 10~20%) |
| Retain | 유지 | 온프레미스 유지 (재검토 예정) | 없음 | – | 규제·보안·연동 제약으로 이전 불가 |
III. 전략 선택 프레임워크
애플리케이션 포트폴리오 합리화(APR) 분석 시 비즈니스 가치 × 기술 복잡도 매트릭스로 우선순위를 결정한다. 비즈니스 가치가 높고 복잡도가 낮으면 Rehost → Refactor 경로를, 가치가 낮으면 Retire 또는 Repurchase를 우선 검토한다. 일반적으로 대형 포트폴리오 기준: Rehost 35%, Replatform 25%, Repurchase 10%, Refactor 15%, Retire 10%, Retain 5% 분포를 보인다.
IV. 결론 및 기술사 관점
6R은 단순 기술 결정이 아닌 비즈니스 전략·TCO·마이그레이션 위험·규제 요건을 종합한 포트폴리오 결정이다. Rehost로 빠른 이전 후 Replatform·Refactor로 단계적 현대화하는 Wave 방식 마이그레이션이 현실적이며, 클라우드 비용 최적화(FinOps) 관점에서 Retire 대상 사전 식별이 ROI 극대화의 핵심이다.
6R 전략을 워크로드에 적용하는 판단 흐름
클라우드 마이그레이션의 6R은 Rehost(리호스트), Replatform(리플랫폼), Repurchase(리퍼처스), Refactor(리팩터), Retire(폐기), Retain(유지)입니다. 이는 기술 이름이 아니라 워크로드별 의사결정 선택지입니다.
실무에서는 애플리케이션을 전수 조사해 사용 빈도, 비즈니스 가치, 기술 부채, 의존 관계, 규제 제약으로 점수화한 뒤 전략을 배정합니다. 사용이 거의 없는 시스템은 먼저 폐기를 검토하고, 이전 일정이 급하면 리호스트로 빠르게 옮긴 뒤 단계적으로 최적화하는 경우가 많습니다.
- Rehost: 변경 없이 이전. 빠르지만 클라우드 이점이 제한적.
- Replatform: 관리형 DB로 교체하는 정도의 최소 수정.
- Refactor: 클라우드 네이티브로 재설계. 비용과 기간이 가장 큼.
- Repurchase: SaaS로 대체(예: 자체 메일 서버를 SaaS로).
- Retire·Retain: 불필요한 시스템 폐기, 규제·지연 때문에 온프레미스 유지.
- 고려 요소: 데이터 이동 비용, 라이선스, 보안 규정, 전환 중 이중 운영 기간.
6R을 나열하는 데서 그치지 말고 평가 기준과 적용 순서를 제시하면 서술형 점수가 올라갑니다.
※ 이 글은 학습·참고용 정리입니다. 제품 사양과 표준 개정 사항은 공식 문서에서 최신 내용을 확인하세요.