클라우드 마이그레이션 전략 (6R) - 엔터프라이즈 인프라 대이동

핵심 인사이트 (3줄 요약)

본질: 클라우드 마이그레이션(Cloud Migration) 6R 전략은 사내 전산실(On-Premise)에 박혀있는 수백 대의 낡은 서버와 먼지 쌓인 코드를 아마존(AWS)이나 구글(GCP)로 이사 보낼 때, "짐을 그대로 쌀 것인가(Rehost), 껍데기만 바꿀 것인가(Replatform), 아니면 아예 뼈를 깎아 새로 지을 것인가(Refactor)"를 6가지 기법으로 분류한 마이그레이션의 바이블이다.

가치: 이 6R(Rehost, Replatform, Repurchase, Refactor, Retire, Retain) 전략표가 없으면, 대기업 임원들은 무지성으로 "모든 서버 클라우드로 당장 옮겨!"라고 지시하다가, 오히려 클라우드 요금 폭탄을 맞고 1년 뒤 온프레미스로 야반도주(Repatriation)하는 끔찍한 재앙을 겪게 된다.

융합: 초반에는 시간과 돈이 없어 가장 쉬운 '단순 복사(Lift and Shift, 리호스트)'로 도망치지만, 결국 클라우드의 무한 탄력성(Auto-scaling)과 비용 절감(FinOps)이라는 진정한 꿀을 빨기 위해서는 최종 보스인 **마이크로서비스(MSA)와 컨테이너(Docker) 기반의 '리팩터(Refactor, 클라우드 네이티브)'**로 모든 코드가 융합 진화하는 숙명을 띠고 있다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: 클라우드 마이그레이션 전략(6R)은 기업의 기존 IT 포트폴리오(애플리케이션, 데이터, 인프라)를 평가하여, 각 워크로드의 특성, 수명, 기술적 부채, 비즈니스 가치에 따라 클라우드 환경으로 이전하는 최적의 방법론 6가지를 정의한 아마존(AWS)과 가트너(Gartner)의 프레임워크다.
필요성: 수만 명의 직원이 쓰는 대기업의 ERP, 결제망, 메일 서버를 클라우드로 한 방에 옮기는 것은 날아가는 비행기 엔진을 갈아 끼우는 짓이다. 개발팀은 "옛날 윈도우 서버 코드는 클라우드에서 안 도니까, 소스 코드를 바닥부터 다시 짜자(리팩터링)"고 한다. 하지만 3년이 걸린다. 사장님은 "이번 달에 우리 전산실 건물 임대 계약이 끝나니까, 무조건 1주일 안에 아마존 클라우드 빈 서버에 파일 통째로 쑤셔 넣어(리호스트)!"라고 소리친다. 또 어떤 시스템은 너무 오래돼서 만든 사람도 퇴사했고, 건드리면 무조건 폭발하는 시한폭탄이다(유지/Retain). 이처럼 시스템마다 처한 기술적 빚(Debt)과 비즈니스 타임라인이 극단적으로 다르기 때문에, "어떤 놈은 살리고, 어떤 놈은 버리고, 어떤 놈은 고쳐 쓸 것인가"를 냉혹하게 분류하는 **'마이그레이션 수술대(Triage)'**가 절대적으로 필요해진 것이다.
등장 배경 및 기술적 패러다임 전환: 초기 클라우드 전환은 무식했다. 100% Lift and Shift (들어 올려서 그대로 옮기기 = Rehost) 방식뿐이었다. 사내에 있던 물리 서버를 똑같은 사양의 AWS EC2 가상 머신으로 통째로 밀어 넣었다. 클라우드 도입은 1달 만에 끝났지만, 온프레미스 때보다 매달 청구되는 서버비가 3배로 뛰었다. 클라우드의 핵심인 '오토스케일링(켰다 끄기)'을 지원하지 않는 뚱뚱한 코드였기 때문이다. 이를 처절하게 깨달은 아키텍트들은 깨달았다. "진짜 클라우드는 코드를 클라우드 원주민(Native)처럼 완전히 뜯어고쳤을 때만 돈이 된다." 그래서 6R이라는 스펙트럼이 등장했다. 단순 이사(Rehost)부터, DB만 클라우드 전용(RDS)으로 슬쩍 바꾸는 중간 타협(Replatform), 그리고 코드를 도커(Docker) 컨테이너와 서버리스(Lambda)로 갈기갈기 찢어버리는 환골탈태(Refactor)까지 아키텍처의 패러다임이 점진적 진화 곡선을 그리게 된 것이다.

이 다이어그램은 낡은 온프레미스 앱이 클라우드의 어떤 목적지로 떨어질지 6갈래로 쪼개지는 잔인한 분배 과정을 명쾌하게 보여준다.

  ┌───────────────────────────────────────────────────────────────┐
  │         클라우드 마이그레이션 6R 전략 라우팅(Routing) 파이프라인 │
  ├───────────────────────────────────────────────────────────────┤
  │                                                               │
  │   [ 🏚️ 레거시 온프레미스 전산실 ] ──▶ (마이그레이션 팩토리 컨베이어 벨트) │
  │                                                               │
  │      ┌──────────────────┐                                     │
  │      │ 1. 윈도우 구형 앱  │ ── (코드 수정 불가, 당장 이사) ────┐    │
  │      └──────────────────┘                                 ▼    │
  │                                   [ 🚚 Rehost (Lift & Shift) ] │
  │      ┌──────────────────┐           ➔ AWS EC2 깡통 서버에 그대로 박음!│
  │      │ 2. 자체 운영 DB   │ ── (서버 관리는 귀찮음) ──────────┐    │
  │      └──────────────────┘                                 ▼    │
  │                                   [ 🛠️ Replatform (Tinker) ]   │
  │      ┌──────────────────┐           ➔ AWS RDS (관리형 DB)로 살짝 업글!│
  │      │ 3. 핵심 쇼핑몰 앱  │ ── (무한 확장 필수, 돈 벌어옴) ───┐    │
  │      └──────────────────┘                                 ▼    │
  │                                   [ 🚀 Refactor (Cloud Native) ] │
  │      ┌──────────────────┐           ➔ 도커 + K8s로 코드를 완벽히 찢음!│
  │      │ 4. 사내 낡은 메일  │ ── (우리가 굳이 만들 필요 있나?) ──┐    │
  │      └──────────────────┘                                 ▼    │
  │                                   [ 🛒 Repurchase (SaaS) ]       │
  │      ┌──────────────────┐           ➔ 앱 폐기하고 '구글 워크스페이스' 구독!│
  │      │ 5. 공장 핵심 제어  │ ── (보안/지연 때문에 외부 반출 불가)─┐    │
  │      └──────────────────┘                                 ▼    │
  │                                   [ 🛑 Retain (Stay) ]           │
  │      ┌──────────────────┐           ➔ 사내망에 영원히 방치 (마이그레이션 X)│
  │      │ 6. 안 쓰는 테스트기 │ ── (서버만 켜져 있고 좀비 상태) ───┐    │
  │      └──────────────────┘                                 ▼    │
  │                                   [ 🗑️ Retire (Kill) ]           │
  │   ★ 요약: 모든 앱이 클라우드로 가는 건 미친 짓이다. ➔ 플러그 뽑고 영구 폐기!  │
  └───────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 파이프라인의 핵심은 **'가치(Value)와 노력(Effort)의 등가교환'**이다. 가장 밑바닥의 **Retire(폐기)**와 **Retain(유지)**은 클라우드로 가지 않는 놈들이다. 쓸모없는 좀비 서버는 전기 코드를 뽑고, 망분리 법적 규제에 묶인 공장망은 그대로 둔다. 클라우드로 가는 놈들 중 가장 싸고 빠른 건 Repurchase(재구매) 다. 사내 구형 ERP나 메일 서버를 AWS로 굳이 낑낑대며 옮길 필요가 없다. 그냥 슬랙(Slack), 세일즈포스(SaaS)에 카드 긁고 갈아타는 것이 1,000배 싸고 현명하다. 진짜 개발자들의 피가 튀기는 전장은 Rehost, Replatform, Refactor의 3파전이다. 당장 내일 전산실 방을 빼야 한다면 짐만 트럭에 싣고 달리는 **Rehost (Lift and Shift)**가 유일한 답이다. 시간이 조금 있다면 OS나 DB 껍데기만 살짝 최신으로 바꾸는 Replatform으로 타협한다. 하지만 회사의 10년 뒤 명운이 걸린 핵심 쇼핑몰 엔진이라면? 과거의 코드를 다 불태우고 수십억 원의 개발비를 부어 뼈대부터 MSA 컨테이너(Docker)로 다시 짓는 Refactor (리팩토링) 수술대에 기꺼이 올라가야 한다.

📢 섹션 요약 비유: 이사를 할 때 6가지 방법이 있습니다.
1. Rehost: 헌 소파를 그대로 트럭에 싣고 새집에 쑤셔 넣기. 2) Replatform: 헌 소파의 천갈이만 살짝 해서 새집에 넣기. 3) Refactor: 헌 소파를 톱으로 다 분해해서 새집 거실 모양에 딱 맞는 최신식 트랜스포머 침대로 아예 새로 조립하기. 4) Repurchase: 헌 소파 버리고 이케아에서 새 소파 사기. 5) Retire: 안 쓰는 쓰레기는 이사 가기 전에 쿨하게 버리기. 6) Retain: 할머니 유품이라 도저히 못 버리고 옛날 집에 그냥 놔두기. 이 중 어느 것을 고를지는 돈과 시간에 달렸습니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

마이그레이션 3대 핵심 전술 심층 해부 (Rehost, Replatform, Refactor)

면접과 실무에서 가장 치열하게 싸우는 기술적 트레이드오프(Trade-off) 구간이다.

전략 (R)	이명 (Alias)	기술적 작업 및 목표	치명적 장단점
Rehost (리호스트)	Lift and Shift (들어서 옮기기)	온프레미스의 VM이나 물리 서버의 OS 이미지를 그대로 복사(Copy)하여 AWS EC2(IaaS) 가상 머신에 1:1로 띄워버림. 소스 코드 수정 0%.	[장점] 며칠 만에 수백 대 이사 끝. 위험도 가장 낮음. [단점] 클라우드 네이티브 혜택(오토스케일링) 거의 못 봄. 클라우드 요금 폭탄(Cloud Tax) 확정.
Replatform (리플랫폼)	Lift, Tinker and Shift (살짝 고쳐 옮기기)	앱 핵심 코드는 그대로 두되, OS를 윈도우에서 리눅스로 바꾸거나, 내가 깔던 MySQL을 AWS RDS(관리형 DB PaaS)로 갈아 끼우는 등 주변 인프라만 업글.	[장점] 코딩 없이 백업/복구 자동화(PaaS)의 꿀을 빪. [단점] 어설프게 OS를 바꾸다 호환성 에러 터져서 디버깅 늪에 빠질 확률 존재.
Refactor (리팩터)	Cloud Native (완전 재설계)	기존 통짜(Monolithic) 앱을 완전히 부수고, 12-Factor App 사상에 맞춰 도커 컨테이너, 서버리스(Lambda), 마이크로서비스(MSA)로 바닥부터 코드를 새로 짬.	[장점] 무한 확장성, 요금 90% 삭감, 1초 컷 배포 등 궁극의 신세계 진입. [단점] 수억 원의 개발 인건비와 1~2년의 전환 기간 뼈를 깎는 고통 동반.

딥다이브: Refactor (리팩터링)의 절대 헌법, 스트랭글러 피그 패턴 (Strangler Fig Pattern)

"좋아! 우리 회사도 무거운 통짜(Monolithic) 시스템 다 버리고 마이크로서비스(MSA/Refactor)로 새로 짜자! 기존 시스템 확 꺼버리고 오늘부터 새 시스템만 연다!!" ➔ 100% 파산하는 빅뱅(Big Bang) 마이그레이션의 재앙이다. 은행이나 쇼핑몰은 1초라도 멈추면 안 된다. 그래서 마틴 파울러(Martin Fowler)가 고안한 천재적 교체 전술이 **'스트랭글러 피그 패턴(교살자 무화과나무 패턴)'**이다.

공존 (Coexist): 낡은 거대 나무(레거시 온프레미스 통짜 서버)는 100% 쌩쌩하게 돌아가도록 냅둔다.
덩굴 싹틔우기 (Intercept): 나무 바로 옆에 AWS 클라우드로 '결제' 기능 딱 1개만 MSA 컨테이너(Refactor)로 작게 새로 짠다.
목 조르기 (Strangulate): 사용자 트래픽이 들어올 때, 앞단의 라우터(API Gateway)가 '결제' 트래픽만 슬쩍 잘라내어 새 클라우드(MSA)로 보내고, 나머지는 다 낡은 나무(레거시)로 보낸다.
나무의 죽음 (Kill): 다음 달엔 '장바구니'를 떼어내고, 내년엔 '회원가입'을 떼어내어 K8s 클라우드로 옮긴다. 2년 뒤, 낡은 나무(레거시)로 가는 트래픽은 0%가 되고 나무는 말라 죽는다(Retire). 이 과정에서 사용자는 시스템이 뜯어고쳐지는 2년 동안 단 1번의 멈춤(Downtime)도 겪지 않는다. 이 점진적인 암살(Migration) 전략만이 리팩터(Refactor)의 살인적인 난이도와 리스크를 완벽하게 통제할 수 있는 구원의 동아줄이다.

📢 섹션 요약 비유: 빅뱅(Big Bang) 마이그레이션은 비행기가 날아가고 있는데 공중에서 옛날 엔진을 확 뜯어내고 새 엔진을 통째로 끼워 넣는 짓(추락 확률 99%)입니다. **스트랭글러 패턴(점진적 리팩터링)**은 낡은 엔진은 놔둔 채 겉에 새 엔진을 하나씩 하나씩 달아서 같이 돌리다가, 새 엔진이 완벽히 작동하면 그제야 낡은 엔진의 나사를 하나씩 풀어서 버리는(추락 확률 0%) 엄청나게 우아하고 안전한 비행 중 수술법입니다.

Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)

마이그레이션 전략 TCO (총소유비용) 십자포화 분석

재무팀(FinOps)과 개발팀(Dev)이 멱살을 잡는 마이그레이션의 영원한 딜레마.

전략 (6R)	단기 TCO (초기 구축 비용)	장기 TCO (운영 및 인프라 유지비)	비즈니스 민첩성 (Agility)
Rehost (Lift & Shift)	가장 쌈 (그냥 복사만 하니까 인건비 0)	가장 비쌈 (클라우드 깡통 서버를 24시간 안 끄고 풀가동해야 하니 요금 폭탄)	최악 (옛날 통짜 코드라 배포하다 에러 나고 렉 걸림)
Refactor (Cloud Native)	미친 듯이 비쌈 (개발자 수십 명 갈아 넣어서 1년 동안 코드 뜯어고침)	가장 쌈 (스팟 인스턴스, 서버리스 람다로 쪼개서 새벽에 다 꺼버리니 요금 0원 수렴)	우주 최강 (하루에 100번씩 무중단 배포, K8s 오토스케일링 폭발)
Repurchase (SaaS 전환)	매우 쌈 (그냥 신용카드 긁으면 내일 아침 도입)	중간 (인원수대로 매월 월정액 나감)	매우 빠름 (내가 코딩 안 해도 최신 기능 자동 업데이트)

[안티패턴: Rehost의 늪에 빠져 죽다] 대기업 임원들의 가장 큰 착각은 "일단 Rehost(리프트 앤 시프트)로 빨리 짐을 다 옮겨놓고, 내년부터 차근차근 컨테이너(Refactor)로 뜯어고치자!"는 달콤한 마스터플랜이다. 이는 100% 거짓말이다. 일단 Rehost로 클라우드 가상 머신(EC2)에 짐을 풀어놓고 서비스가 돌아가기 시작하면, 개발자들은 밀려오는 신규 비즈니스 피처(Feature)를 찍어내느라 바빠서 영원히 리팩터링을 할 시간을 내지 못한다. 결국 낡은 코드는 AWS 위에서 엄청난 IaaS 서버 요금을 태우며 3년 내내 방치되다가, 결국 클라우드 유지비에 목이 졸려 사내망(온프레미스)으로 야반도주(Repatriation, U턴)하는 참혹한 결말을 맺게 된다.

컨테이너(Docker)와 클라우드 마이그레이션의 파괴적 시너지

코드를 뜯어고치는 Refactor는 너무 비싸고, 짐만 옮기는 Rehost는 요금이 비싸다. 이 중간 어딘가의 환상적인 구원투수로 등판한 것이 **컨테이너(Docker)**다.

기존의 통짜(Monolithic) 자바 코드를 마이크로서비스로 다 쪼개지 않는다(시간 부족).
대신 그 무거운 통짜 코드를 '거대한 도커 컨테이너(Docker Container)' 하나로 그냥 냅다 말아버린다 (이른바 Replatform 타협).
그리고 아마존 클라우드(ECS, EKS) 빈 깡통 위에 이 거대한 깡통을 띄운다. 이 꼼수(Lift and Shift to Container)를 쓰면, 코드는 낡은 쓰레기여도 껍데기가 '컨테이너'가 되었기 때문에 쿠버네티스의 혜택(죽으면 1초 만에 자동 부활, 오토스케일링 복제)을 절반 정도는 날로 먹을 수 있다. 이것이 돈 없는 엔터프라이즈들이 클라우드 네이티브로 넘어가는 현실적이고 가성비 넘치는 최강의 과도기적(Transitional) 징검다리 아키텍처다.

📢 섹션 요약 비유: Rehost(단순 이사)는 월세가 엄청 비싼 강남 아파트(클라우드)로 이사를 갔는데, 옛날 시골집에서 쓰던 녹슨 에어컨과 전구(레거시 코드)를 그대로 달고 24시간 틀어놔서 전기세(서버 요금)로 파산하는 꼴입니다. Refactor(리팩터)는 강남 아파트로 이사 가기 전에 수천만 원을 들여서 사람이 없을 땐 자동으로 1초 만에 꺼지고 켜지는 **최첨단 스마트 AI 전구와 인버터 에어컨(클라우드 네이티브, 12-Factor)**으로 집 안의 모든 전자 기기를 싹 뜯어고친 겁니다. 공사비(초기 개발비)는 피눈물 나지만, 앞으로 10년간 전기세는 거의 0원에 수렴하는 궁극의 재테크입니다.

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

실무 시나리오 및 설계 안티패턴

시나리오 — 데이터베이스(DB) 마이그레이션의 Replatform(리플랫폼) 꼼수: 온프레미스에서 무거운 오라클(Oracle) DB를 돌리던 회사가 클라우드로 이사를 간다. EC2(IaaS) 깡통 서버를 빌려서 오라클을 수동으로 깔면 백업 스크립트도 직접 짜야 하고 생고생이다(Rehost의 비극).
- 의사결정: 아키텍트는 오라클 DB 자체를 포기하지 않되, 껍데기를 **AWS RDS(완전 관리형 PaaS)**로 살짝 바꿔 치는 Replatform(리플랫폼) 전략을 구사한다. 코드 수정 없이 데이터만 AWS RDS Oracle로 마이그레이션 툴(DMS)을 써서 쏙 밀어 넣는다. 백업(Snapshot), 이중화(Multi-AZ), 스토리지 오토스케일링 같은 인프라 관리의 지옥을 아마존이 100% 알아서 자동화해 준다. 코딩 공수 0원으로 DBA 10명의 인건비를 증발시켜 버린 완벽한 타협 전술이다.
안티패턴 — 보안망(Compliance)에 묶인 코어 시스템 강제 클라우드 이행 (Blind Migration): 금융 공기업이 위에서 "클라우드 100% 전환율 맞춰라!"라는 지시를 받고, 내부망에 꽁꽁 숨어있어야 할 고객 신용정보 DB까지 모조리 AWS 퍼블릭 클라우드(VPC)로 들어 올려서(Rehost) 옮겼다.
- 결과: 클라우드는 본질적으로 인터넷과 연결된 남의 땅(Multi-tenant)이다. 망분리법 규제 감사가 뜨자, 신용정보가 퍼블릭망과 접점이 있다는 이유로 회사에 영업 정지 철퇴가 떨어졌다. 클라우드에 올려놨던 코어 DB를 울면서 다시 사내 전산실 지하(On-Premise) 물리 서버로 내리는 야반도주(Repatriation) 대참사가 발생하며 수십억 원이 허공으로 증발했다.
- 해결책: 마이그레이션 6R 중 가장 용기 있는 결단은 **Retain(유지)**이다. 극강의 지연 시간(1ms 이하)이 필요한 공장 기계 제어망(MEC)이나, 타협 불가능한 국가 보안망에 묶인 데이터는 억지로 클라우드에 밀어 넣지 말고 쿨하게 온프레미스에 사수(Retain)해야 한다. 껍데기 웹서버만 퍼블릭으로 빼고 코어망은 사내에 두는 하이브리드 클라우드(188번 문서) 아키텍처만이 이 무지성 폭주를 막을 수 있는 유일한 방파제다.

엔터프라이즈 클라우드 마이그레이션 (6R) 의사결정 트리

수천 대의 서버 앞단에서 아키텍트가 내리는 생사의 갈림길이다.

  ┌───────────────────────────────────────────────────────────────────┐
  │           클라우드 마이그레이션 전략 (6R) 워크로드 분배 의사결정 트리         │
  ├───────────────────────────────────────────────────────────────────┤
  │                                                                   │
  │   [사내망(온프레미스) 서버 100대를 클라우드로 이관하라는 이사회 특명 발생]       │
  │                │                                                  │
  │                ▼                                                  │
  │      이 서버가 돌아가는 시스템이 1년 동안 아무도 안 쓴 낡은 테스트기이거나,       │
  │      통합되어 더 이상 쓸모가 없는 유령(Zombie) 시스템인가?                 │
  │          ├─ 예 ──▶ [ 🗑️ Retire (폐기) 전격 발동! ]                   │
  │          │         - 클라우드로 가져가 봐야 전기세만 나감. 전원 뽑고 영원히 매장. │
  │          │                                                        │
  │          └─ 아니오 (여전히 회사의 돈을 벌어다 주는 라이브 서비스임)             │
  │                │                                                  │
  │                ▼                                                  │
  │      그 앱이 사내 메일(Exchange), 사내 메신저, 구형 회계 프로그램 같은         │
  │      우리가 굳이 개발자 갈아 넣어서 '자체 코딩'을 유지할 필요가 없는 범용 툴인가?│
  │          ├─ 예 ──▶ [ 🛒 Repurchase (재구매 / SaaS 전환) ]             │
  │          │         - 낡은 서버 버리고, 내일부터 Google Workspace, Slack 결제해서 씀.│
  │          │                                                        │
  │          └─ 아니오 (우리 회사의 밥줄인 핵심 쇼핑몰 엔진, 결제 로직 등 자체 코드임)│
  │                │                                                  │
  │                ▼                                                  │
  │      당장 다음 달에 전산실 방 빼야 해서, 코드를 고칠(리팩토링) 시간이 아예 없는가? │
  │          ├─ 예 ──▶ [ 🚚 Rehost (리프트 앤 시프트) 임시 타협 ]             │
  │          │         - 울며 겨자 먹기로 AWS 빈 깡통 서버(EC2)에 그대로 통째로 밀어 넣음.│
  │          │         - 1차 방어선. 추후 반드시 리팩터링 2차 수술을 해야 파산 안 함. │
  │          │                                                        │
  │          └─ 아니오 (시간과 돈이 있고, 이참에 클라우드의 무한 확장 꿀을 빨고 싶다)│
  │                │                                                  │
  │                ▼                                                  │
  │     [ 🚀 Refactor (리팩터 / 클라우드 네이티브) 마스터플랜 전격 가동! ]        │
  │       - 거대한 통짜 자바 코드를 산산조각 내어 마이크로서비스(MSA)로 찢어발김.      │
  │       - 10MB짜리 가벼운 도커 컨테이너로 감싸 쿠버네티스(K8s) 위에 무한 오토스케일링 런칭!│
  │                                                                   │
  │   판단 포인트: "클라우드 마이그레이션의 90%는 이사가 아니라 '버리기(Retire, SaaS)'다. │
  │                끝까지 남은 10%의 핵심 코드에만 네이티브(Refactor) 영혼을 갈아 넣어라."│
  └───────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 트리는 클라우드 전환을 빙자해 외주(SI) 업체가 돈을 빨아먹는 짓을 쳐내는 C 레벨의 검(Sword)이다. 어떤 업체는 사내 이메일 서버를 AWS에 구축(Rehost)하겠다고 1억 원을 달라고 한다. 아키텍트는 이를 잘라내고 구글 메일(SaaS/Repurchase)을 월 1만 원에 구독시킨다. 또 어떤 업체는 망분리된 사내 인사 시스템을 무리하게 클라우드로 밀어 넣다(Rehost) 에러를 뿜는다. 아키텍트는 이를 사내망에 쿨하게 놔둔다(Retain). 오직 우리 회사의 차별화된 심장(예: 쿠팡의 로켓 배송 알고리즘) 단 하나에만 돈과 개발자를 폭격하여 **Refactor(도커+쿠버네티스 MSA화)**로 깎아내는 것, 이것이 방만한 인프라 덩치를 1/10로 압축시키고 극한의 날카로운 칼끝(민첩성)을 쥐는 6R 전략의 절대적 본질이다.

📢 섹션 요약 비유: 클라우드 마이그레이션(6R)은 오래된 낡은 아파트에서 **'초호화 스마트 홈'**으로 이사 가는 겁니다. 고장 난 선풍기(Retire)는 쿨하게 버립니다. 옛날 똥컴(Repurchase)은 버리고 최신 아이패드(SaaS)를 삽니다. 냉장고(Replatform)는 똑같은 엘지 건데 최신 모델로 슬쩍 바꿔서 들여놓죠. 하지만 어머니가 주신 낡은 옷장(Retain)은 이삿짐에 안 싣고 시골 본가에 놔둡니다. 마지막으로 남은 아끼는 소파(Refactor)는 아예 뼈대부터 다 뜯어서 스마트 홈 거실 사이즈에 딱 맞게 최고급 가죽 침대로 완벽히 새로 개조해서 들여놓는, 눈물겹고 철저한 살림살이 필터링 작전입니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	레거시 단순 유지 (Do Nothing)	마이그레이션 6R 전략 분배 적용 시	개선 효과
정량 (인프라 자산)	고장 난 서버와 미사용 좀비 앱에 전기세 누수	Retire 및 Repurchase 분배로 잉여 자산 파괴	IT 인프라 유지 보수 비용 (TCO) 30% 이상 영구 삭감
정량 (확장 리드타임)	연말 이벤트 트래픽 폭주 시 서버 다운 확정	핵심 앱만 Refactor(K8s)로 빼서 오토스케일링 획득	무한 스케일 아웃 확보로 가용성 99.99% 달성 및 다운타임 제로화
정성 (기술 부채)	개발자 퇴사로 블랙박스화 된 낡은 덩어리 코드 유지	모놀리식 $\rightarrow$ MSA 찢기로 코드베이스 경량화 완수	클라우드 네이티브 환경에 맞는 애자일(Agile) 조직 문화/배포 구조 정착

미래 전망

마이그레이션 자동화 팩토리 (Migration Factory)의 도래: 옛날에는 서버 100대를 옮기려면 엔지니어 10명이 디스크 이미지를 뜨며 밤을 새웠다. 지금은 AWS Application Migration Service (MGN) 같은 블록 레벨 복제 로봇이 등장했다. 소스 서버의 디스크를 실시간으로 1바이트 오차 없이 클라우드에 동기화하다가, 스위치를 딱 켜면 1분 만에 클라우드 서버가 짜잔! 하고 켜진다. 이 무중단 마이그레이션 툴 덕분에 Rehost(리프트 앤 시프트) 작업은 사실상 인건비가 0원에 수렴하는 무인 공장화(Factory)가 완료되었다.
스트랭글러 패턴(Strangler Fig)의 진화와 서비스 메시(Service Mesh): 코드를 찢는 Refactor를 할 때, 옛날 서버와 새 K8s 서버 사이에서 트래픽을 정교하게 10%씩 넘겨주는 작업은 지옥이었다. 최근 **Istio(서비스 메시, 208번)**가 등장하며 이 판도를 바꿨다. 아키텍트는 낡은 서버 옆에 이스티오 프록시(Envoy)를 달아놓고, 명령어 한 줄로 "로그인 트래픽 중 딱 5%만 클라우드 새 서버로 몰래 흘려보내!"라고 지시한다. 마이그레이션 과정 자체가 거대한 A/B 테스트이자 카나리 배포(Canary)로 융합되며 실패(에러 폭발) 리스크가 수학적으로 0에 수렴하는 시대를 맞이했다.

참고 표준

AWS 6R Framework (가트너 5R 확장): 가트너가 정의한 5R에 아마존이 Retain(남겨두기)을 추가하여 전 세계 엔터프라이즈의 클라우드 전환 컨설팅 바이블로 못 박아버린 6가지 디시전 트리 표준 방법론.
12-Factor App (200번 문서): Refactor(클라우드 네이티브로 재설계)를 선택한 용자(개발자)들이, 코드를 찢을 때 반드시 지켜야 하는 "무상태(Stateless), 환경변수 분리" 등의 12가지 황금 코딩 헌법.

"클라우드로 가는 티켓을 끊었다고 모두가 하늘을 나는 것은 아니다. 무거운 납덩이를 메고 뛰어내린 자는 요금 폭탄에 맞아 추락할 뿐이다." 클라우드 마이그레이션 6R 전략은 클라우드가 만능 요술 램프라는 멍청한 환상을 깨부수는 차가운 진단서다. 사내 전산실에 굴러다니는 수백 개의 서버들은 저마다 안고 있는 빚(기술 부채)과 수명이 다르다. 어떤 놈은 쿨하게 쓰레기통에 처넣고(Retire), 어떤 놈은 남의 서비스를 돈 주고 빌려 쓰며(Repurchase), 당장 방을 빼야 하는 놈은 짐만 대충 싸서 임시 피난을 보낸다(Rehost). 그리고 우리의 심장인 핵심 코어 서비스 단 하나에만 수십억의 수술비를 태워 뼈를 깎는 네이티브로 재탄생(Refactor)시킨다. 클라우드 아키텍트의 진정한 실력은 리눅스 커널을 다루는 기술이 아니라, 이 6개의 가혹한 수술용 칼(6R)을 들고 비즈니스 밸류(돈)가 없는 레거시의 숨통을 정확히 끊어버리는 냉혹한 결정력(Triage)에 있는 것이다.

📢 섹션 요약 비유: 클라우드 마이그레이션은 엄청나게 비싸고 예민한 100만 명의 시민(데이터와 코드)을 데리고 화성(클라우드)으로 이주하는 **'우주 대항해 엑소더스'**입니다. 늙고 병든 시스템(Retire)은 우주선에 태우지 않습니다. 지구의 무거운 흙과 바위(온프레미스 인프라)를 굳이 우주선에 싣고 가는 멍청이(Rehost)는 연료비(클라우드 요금 폭탄)로 우주에서 파산합니다. 짐을 다 버리고, 우주 환경에 완벽히 적응할 수 있는 투명하고 가벼운 우주복(도커 컨테이너)으로 완전히 갈아입힌(Refactor) 소수 정예만이 이 지옥의 우주 항해를 뚫고 신인류(클라우드 네이티브)로 영생할 수 있습니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
클라우드 네이티브 (199번 문서)	6R 전략 중 끝판왕인 Refactor(리팩터)의 최종 목적지. 낡은 코드를 버리고 처음부터 K8s와 MSA 룰에 맞춰 새판을 짜는 극한의 재탄생 아키텍처.
IaaS (183번) / PaaS (184번)	Rehost(리프트 앤 시프트)는 IaaS 빈 깡통 서버로 그대로 복사하는 짓이고, Replatform은 OS를 버리고 벤더가 세팅한 쾌적한 PaaS(RDS 등)로 살짝 껍데기를 바꾸는 전략.
FinOps (비용 최적화, 210번)	6R 판단을 잘못해서 Rehost로 덩치 큰 앱을 클라우드에 24시간 켜두면 요금 폭탄을 맞는다. 이때 FinOps 팀이 몽둥이를 들고 찾아와 "당장 Refactor(스팟/서버리스)로 고쳐!"라고 멱살을 잡는다.
마이크로서비스 아키텍처 (MSA)	통짜로 얽힌 거대한 레거시 코드를 100개로 찢는 철학. Refactor(리팩터) 수술대 위에서 낡은 암 덩어리를 잘라낼 때 쓰는 가장 예리한 수술용 칼이다.
서비스 디스커버리 (208번 문서)	스트랭글러 패턴(점진적 리팩터링)을 쓸 때, 옛날 서버와 새 클라우드 컨테이너 사이에서 1초마다 바뀌는 IP 주소를 찰떡같이 이어주어 이사 도중 서비스가 끊기지 않게 지탱하는 동적 내비게이션.

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

낡고 좁은 옛날 집에서 최첨단 으리으리한 스마트 아파트(클라우드)로 이사를 가야 해요! 짐이 너무 많아서 6가지 방법(6R)으로 짐을 싸기로 했어요.
고장 난 장난감은 쿨하게 버리고(Retire), 옛날 오락기는 놔두고(Retain), 무거운 소파는 억지로 트럭에 싣고(Rehost), 구식 TV는 버리고 최신 태블릿을 새로 사요(Repurchase).
가장 아끼는 레고 성은 아예 바닥부터 다 부순 다음에, 새 아파트 모양에 완벽하게 딱 맞고 더 크고 멋지게 완전히 새로 조립(Refactor)하는 아주 똑똑한 이사 대작전이랍니다!