203. 클라우드 마이그레이션 6R (Cloud Migration 6R Strategy)

핵심 인사이트

본질: 클라우드 마이그레이션 6R은 기존 IT 워크로드를 클라우드로 이전하는 방식을 Rehost·Replatform·Refactor·Repurchase·Retire·Retain 6가지로 분류하여, 각 애플리케이션에 최적화된 마이그레이션 경로를 선택하는 의사결정 프레임워크다.

가치: 대규모 클라우드 마이그레이션 프로젝트에서 모든 애플리케이션에 동일한 전략을 적용하면 비용 낭비와 기술 부채가 누적된다. 6R 프레임워크는 비즈니스 가치, 기술 복잡성, 비용·위험 균형을 기준으로 최적 경로를 선택하게 해준다.

판단 포인트: 기술사 시험에서는 6가지 전략의 정의·장단점, 적합한 워크로드 유형, 그리고 실제 마이그레이션 웨이브(Wave) 계획과의 연계 방법을 논리적으로 서술해야 한다.

Ⅰ. 개요 및 필요성

기업이 수백~수천 개의 레거시 애플리케이션을 보유하고 있을 때, 무조건 "전부 클라우드 네이티브로 재개발"하는 전략은 시간과 비용 측면에서 현실적이지 않다. Gartner와 AWS가 정의한 6R 프레임워크는 애플리케이션별로 비즈니스 가치, 기술 복잡도, 마이그레이션 비용·위험을 분석하여 가장 효율적인 이전 경로를 선택하는 체계적 방법론이다.

마이그레이션의 궁극적 목표는 단순히 데이터센터를 클라우드로 옮기는 것이 아니라, 클라우드의 탄력성·자동화·비용 효율성을 실질적으로 활용하여 비즈니스 민첩성을 높이는 것이다. 6R은 이 목표를 위한 출발점이자 로드맵 수립 도구다.

📢 섹션 요약 비유: 6R은 이사할 때의 짐 분류법이다. 그냥 옮길 것(Rehost), 분해해서 맞출 것(Replatform), 완전히 새로 만들 것(Refactor), 새 제품으로 교체할 것(Repurchase), 버릴 것(Retire), 지금은 안 옮길 것(Retain). 짐마다 다른 결정이 최적 이사를 만든다.

Ⅱ. 아키텍처 및 핵심 원리

2-1. 6R 전략 전체 구조

┌─────────────────────────────────────────────────────────────────────┐
│             클라우드 마이그레이션 6R 전략 프레임워크                  │
├─────────────┬────────────────────────────────────────────────────── ┤
│  전략       │  설명                     │  클라우드 가치 실현 수준   │
├─────────────┼───────────────────────────┼───────────────────────────┤
│  Rehost     │  리프트앤시프트: 변경 없이│  낮음 (인프라 비용만 절감) │
│ (리호스트)  │  그대로 클라우드로 이전   │                            │
├─────────────┼───────────────────────────┼───────────────────────────┤
│  Replatform │  OS·DB 등 일부 최적화 후  │  중간 (관리형 서비스 활용) │
│ (리플랫폼)  │  클라우드로 이전          │                            │
├─────────────┼───────────────────────────┼───────────────────────────┤
│  Refactor   │  클라우드 네이티브로 재설│  높음 (완전한 탄력성 확보) │
│ (리팩터)    │  계·재개발                │                            │
├─────────────┼───────────────────────────┼───────────────────────────┤
│  Repurchase │  SaaS로 교체 (예: CRM →   │  중간 (기능 표준화)        │
│ (리퍼체이스)│  Salesforce)              │                            │
├─────────────┼───────────────────────────┼───────────────────────────┤
│  Retire     │  불필요한 시스템 폐기     │  비용 절감                 │
│ (리타이어)  │                           │                            │
├─────────────┼───────────────────────────┼───────────────────────────┤
│  Retain     │  현재 유지 (향후 마이그레 │  없음 (위험·비용 큰 경우) │
│ (리테인)    │  이션 또는 폐기 예정)     │                            │
└─────────────┴───────────────────────────┴───────────────────────────┘

2-2. 6R 전략별 상세 비교

전략	별칭	변경 범위	마이그레이션 기간	위험도	비용 절감
Rehost	Lift-and-Shift	변경 없음	빠름	낮음	낮음~중간
Replatform	Lift-and-Optimize	미들웨어·DB 최적화	중간	중간	중간
Refactor	Re-architect	전체 재설계 (MSA 등)	느림	높음	높음
Repurchase	Drop-and-Shop	SaaS 교체	중간	중간	중간~높음
Retire	폐기	—	즉시	없음	즉시 절감
Retain	현상 유지	변경 없음	무기한	낮음	없음

📢 섹션 요약 비유: Rehost는 집 전체를 크레인으로 들어 옮기는 것, Replatform은 이사 전에 낡은 배관만 교체하는 것, Refactor는 집을 허물고 새 집을 짓는 것이다. 비용과 시간, 효과가 모두 다르다.

Ⅲ. 비교 및 연결

3-1. 워크로드 유형별 최적 전략

워크로드 유형	권장 전략	이유
표준 3-tier 웹 앱	Rehost → Replatform	빠른 이전 후 점진적 최적화
이메일·그룹웨어	Repurchase	Exchange → Office 365, SaaS로 교체
고객 관리 시스템(CRM)	Repurchase	Salesforce 등 SaaS CRM으로 표준화
핵심 비즈니스 로직	Refactor	MSA (Microservices Architecture) 전환으로 민첩성 확보
감사·법적 보존 시스템	Retain	규제 요건, 마이그레이션 위험 높음
중복·거의 미사용 시스템	Retire	즉시 비용 절감

3-2. 마이그레이션 웨이브 (Migration Wave) 계획

6R 분석 결과를 기반으로 마이그레이션 Wave를 설계한다. Wave 1은 Rehost 대상(위험 낮음, 빠른 성과), Wave 2는 Replatform, Wave 3은 Refactor·Repurchase 순으로 진행하여 점진적으로 클라우드 네이티브 전환을 완성한다.

Wave	전략	기간	목표
Wave 1	Rehost (30~40%)	3~6개월	빠른 데이터센터 풋프린트 감소
Wave 2	Replatform (30%)	6~12개월	관리형 서비스 전환, 비용 최적화
Wave 3	Refactor + Repurchase (20%)	12~24개월	클라우드 네이티브 전환
즉시	Retire (10~20%)	즉시	즉각적 비용 절감

📢 섹션 요약 비유: 마이그레이션 Wave는 이사할 때 짐을 한꺼번에 옮기지 않고, 먼저 쉬운 것부터 옮기고, 복잡한 것은 나중에 천천히 준비해서 옮기는 것이다. 한꺼번에 다 옮기려다 파손되는 것보다 훨씬 안전하다.

Ⅳ. 실무 적용 및 기술사 판단

4-1. 애플리케이션 포트폴리오 분석 (Application Portfolio Analysis)

마이그레이션 전 7R (Retire 포함) 분류를 위해 애플리케이션별로 다음 항목을 조사한다:

비즈니스 가치 점수 (낮음/중간/높음)
기술 부채 수준 (코드 품질, 의존성 복잡도)
운영 비용 (서버 수, 라이선스 비용)
규제·컴플라이언스 요건
클라우드 친화성 (Cloud Readiness Score)

이 분석 결과를 2×2 매트릭스(비즈니스 가치 × 기술 부채)에 배치하여 마이그레이션 우선순위를 시각화한다.

4-2. 총 소유 비용(TCO) 분석

항목	온프레미스	Rehost	Refactor
초기 투자(CapEx)	높음	낮음	중간
운영 비용(OpEx)	높음	중간	낮음
마이그레이션 비용	—	낮음	높음
장기 클라우드 가치 실현	없음	낮음	높음

4-3. 위험 관리

Refactor는 클라우드 가치 실현이 가장 높지만, 재설계 중 비즈니스 연속성 위험이 크다. 이를 위해 Strangler Fig Pattern (스트랭글러 패턴)을 활용하여 모놀리식 애플리케이션을 점진적으로 MSA로 전환하는 방식이 권장된다.

📢 섹션 요약 비유: TCO 분석은 이사 비용 계산서다. 단순히 이사비만 보면 Rehost가 싸 보이지만, 5년치 유지비까지 포함하면 Refactor가 더 경제적일 수 있다. 단기 비용만 보는 함정을 피해야 한다.

Ⅴ. 기대효과 및 결론

6R 프레임워크를 적용한 마이그레이션 전략은 불필요한 비용 낭비를 줄이고, 클라우드 전환 효과를 극대화하는 체계적 접근을 제공한다. Retire와 Retain의 조기 분류만으로도 전체 마이그레이션 비용의 10~20%를 절감할 수 있으며, Rehost의 빠른 성과(Quick Win)는 경영진의 클라우드 신뢰도를 높여 이후 대규모 Refactor 프로젝트의 승인을 용이하게 한다.

기술사 시험에서는 6R의 각 전략 정의와 장단점을 간결히 정리하고, 실제 마이그레이션 프로젝트에서 애플리케이션 포트폴리오 분석 → Wave 계획 → TCO 분석 → 위험 관리의 연계 방안을 서술하는 것이 고득점 전략이다.

📢 섹션 요약 비유: 6R은 대규모 이사를 체계적으로 완성하는 분류 시스템이다. 짐마다 "그냥 옮기기, 조금 고치고 옮기기, 새로 사기, 버리기, 나중에 결정"을 정해두면, 이사 당일의 혼란이 사라지고 새 집에서 더 빨리 정상 생활을 시작할 수 있다.

📌 관련 개념 맵

개념	설명	연관 키워드
Rehost	Lift-and-Shift, 변경 없이 클라우드 이전	VMware, AWS Migration Hub
Replatform	일부 최적화 후 이전 (Lift-and-Optimize)	RDS, 관리형 서비스
Refactor	클라우드 네이티브로 전면 재설계	MSA, 12-Factor App
Repurchase	SaaS 제품으로 교체	Office 365, Salesforce
Retire	불필요 시스템 폐기	즉시 비용 절감
Retain	현상 유지 (이전 보류)	규제, 의존성 복잡성
Migration Wave	단계적 마이그레이션 계획	Quick Win, 위험 분산
TCO	Total Cost of Ownership, 총 소유 비용	CapEx vs. OpEx
Strangler Fig	점진적 MSA 전환 패턴	모놀리스, 마이크로서비스

👶 어린이를 위한 3줄 비유 설명

6R은 이사할 때 짐을 어떻게 옮길지 결정하는 6가지 방법이야. 그냥 들고 가는 것(Rehost), 고쳐서 가는 것(Replatform), 새로 만드는 것(Refactor), 새 제품 사는 것(Repurchase), 버리는 것(Retire), 안 가져가는 것(Retain).
제일 빠른 방법(Rehost)은 당장 이사는 되지만, 새 집에서 불편할 수 있어. 제일 좋은 방법(Refactor)은 새 집에 딱 맞게 만들지만 시간이 오래 걸려.
똑똑한 이사는 먼저 쉬운 짐부터 옮기고(Wave 1), 복잡한 짐은 천천히 준비해서 옮기는 거야(Wave 2, 3). 한꺼번에 다 옮기려다 아무것도 못 옮길 수 있거든.