"우리 시스템 클라우드로 옮기자"는 한 문장이지만, 실제로는 시스템마다 옮기는 방식이 다릅니다. 오래된 그룹웨어와 새로 만든 결제 API를 같은 방식으로 옮길 수는 없습니다. 6R은 AWS가 정리해 널리 쓰이는, 애플리케이션별로 "어떻게 옮길지"를 6가지로 나눈 의사결정 프레임입니다. 마이그레이션 계획의 출발점은 전체 일정이 아니라, 시스템마다 이 6R 중 하나를 고르는 일입니다.
6R 비교
| 전략 | 한 줄 의미 | 변경량 | 대표 상황 |
|---|---|---|---|
| Rehost | 그대로 들어 올림(lift & shift) | 거의 없음 | 빨리 데이터센터 탈출, IDC 계약 만료 |
| Replatform | 약간 손봐서 옮김 | 적음 | DB를 관리형(RDS)으로 바꿔 운영 부담↓ |
| Repurchase | SaaS로 갈아탐 | 교체 | 자체 메일·CRM → SaaS 구독 |
| Refactor | 구조를 다시 설계 | 큼 | 모놀리식 → 마이크로서비스/서버리스 |
| Retire | 폐기 | — | 아무도 안 쓰는 레거시 정리 |
| Retain | 그대로 유지 | — | 규제·종속성으로 아직 못 옮김 |
어떻게 고르나
먼저 자산 목록을 만들어 시스템별로 트래픽, 의존성, 규제 여부를 적습니다. 그다음 두 축으로 판단합니다. "지금 비즈니스 가치가 큰가"와 "옮기는 난이도가 큰가".
- 가치 낮고 안 쓰면 → Retire.
- 가치 낮고 그냥 굴러가면 → Rehost로 빠르게.
- 가치 높고 운영이 아프면 → Replatform(예: DB만 RDS로).
- 가치 높고 확장이 절실하면 → Refactor(투자 대비 가장 큰 효과, 가장 큰 비용).
- 시장에 더 나은 제품이 있으면 → Repurchase.
대부분의 조직은 Rehost로 먼저 옮겨 데이터센터를 닫고, 이후 중요한 시스템부터 차근차근 Replatform·Refactor로 고도화하는 2단계 접근을 씁니다.
흔한 함정
- 전부 Refactor하려다 멈춘다 — 가장 비싸고 오래 걸립니다. 처음부터 모든 걸 재설계하면 일정이 무너집니다.
- 비용 산정에서 데이터 전송·이중 운영을 빼먹는다 — 마이그레이션 기간엔 온프레미스와 클라우드를 동시에 굴립니다(이중 비용).
- Retire·Retain을 안 따진다 — 옮길 필요 없는 걸 옮기는 게 가장 아까운 비용입니다.
요점 정리
- 6R = Rehost·Replatform·Repurchase·Refactor·Retire·Retain.
- 시스템별 가치와 난이도로 전략을 고르고, 보통 Rehost 후 점진 고도화.
- Refactor 올인·이중 비용 누락·불필요한 이전이 3대 함정.
VPC·관리형 DB·서버리스 등 6R 전략을 실제로 구현하는 데 필요한 클라우드 기본기는 클라우드 트랙에서 회원가입 없이 무료로 익힐 수 있습니다.