42. Rehost (리호스트 / Lift and Shift) - 온프레미스 VM/애플리케이션을 변경 없이 클라우드 IaaS로 그대로 이관 (가장 빠름, 클라우드 이점 부족)

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

본질: 마이그레이션 6R 전략 중 하나인 Rehost (리호스트, 일명 Lift and Shift)는 기존 사내 데이터센터(On-Premise)에서 돌고 있던 서버의 운영체제, 애플리케이션, 데이터베이스를 단 한 글자의 코드나 아키텍처 변경 없이 그대로 떠서(Lift) 클라우드 가상 머신(IaaS, 예: AWS EC2) 위로 안착(Shift)시키는 가장 원시적이고 단순한 마이그레이션 기법이다.

가치: 복잡한 재개발이나 재테스트 과정이 생략되므로 수백 대의 서버를 단 몇 주 만에 초고속으로 클라우드에 쏟아부을 수 있어, 데이터센터 임대 계약 만료 등 당장 급한 불을 꺼야 하는 타임 투 마켓(Time-to-Market) 상황에서 압도적인 가성비와 무사고(Risk Zero) 전환을 보장한다.

융합: 비록 오토 스케일링(탄력성)이나 관리형 서비스(PaaS) 혜택을 전혀 누릴 수 없는 "무늬만 클라우드"라는 오명을 쓰지만, 실제 엔터프라이즈 환경에서는 일단 1단계로 Rehost를 통해 빠르게 클라우드로 피난을 온 직후, 안락한 클라우드 환경 위에서 시간을 두고 천천히 마이크로서비스(MSA)로 리팩터링(Refactor)해 나가는 2-Step 융합 아키텍처의 필수적인 징검다리로 쓰인다.

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

개념: 'Lift and Shift'라는 별명 그대로 지게차로 짐을 떠서(Lift) 트럭에 싣고 새 집에 내려놓는(Shift) 방식이다. 온프레미스 서버의 디스크를 통째로 이미지(Image) 파일로 구운 다음, 클라우드 컴퓨팅 환경에서 그 이미지를 부팅시키면 끝난다. 윈도우(Windows)나 리눅스(Linux) 환경, IP 설정까지 기존 그대로 복사된다.
필요성: 한 은행이 클라우드로 이사 가기로 했다. 코드 수백만 줄을 클라우드 네이티브(MSA)로 멋지게 다시 짜려니 개발 기간이 3년이 걸린다고 한다. 그런데 기존 물리 서버실의 임대 계약은 당장 3달 뒤에 만료되어 쫓겨날 판이다. 회사가 파산할 위기다. 이때 필요한 것이 바로 Rehost다. 묻지도 따지지도 않고 AWS Server Migration Service (SMS) 같은 복사기 툴을 돌려서, 밤새 100대의 서버를 AWS EC2로 싹 긁어다 띄워버리면 한 달 만에 기적처럼 이사가 끝난다.
💡 비유: Rehost는 낡은 시골집에 있던 뚱뚱한 브라운관 TV와 낡은 장롱을, 이삿짐센터 아저씨들이 포장 뽁뽁이도 안 뜯고 그대로 들어서 최첨단 강남 타워팰리스(클라우드) 거실 한가운데 떡하니 던져놓고 가는 것이다. 타워팰리스의 스마트홈 기능(클라우드 네이티브 이점)은 하나도 못 쓰지만, 어쨌든 쫓겨나지 않고 새집에서 당장 밤에 TV를 보며 잘 수 있다는 완벽한 해결책이다.
📢 섹션 요약 비유: 이사 갈 때, 낡은 가구를 부수고 방 구조에 맞게 새로 맞춤형 가구를 짜 넣는 짓(리팩터링)은 나중에 하고, 일단 비가 오니 박스째로 거실에 다 밀어 넣고(리호스트) 비부터 피하는 가장 똑똑하고 현실적인 생존 본능입니다.

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

Rehost 파이프라인의 P2V / V2V 아키텍처

리호스트는 사람이 손으로 코드를 옮기는 것이 아니라, 무식하고 강력한 블록 스토리지 동기화 툴(마이그레이션 팩토리)이 백그라운드에서 기계적으로 디스크를 긁어간다.

  ┌───────────────────────────────────────────────────────────────────┐
  │                 Rehost (Lift and Shift) 초고속 이관 파이프라인         │
  ├───────────────────────────────────────────────────────────────────┤
  │                                                                   │
  │    [ 1. 기존 데이터센터 (On-Premise) ]                             │
  │                                                                   │
  │     물리 서버 (Bare Metal) ── (P2V: Physical to Virtual) ──┐        │
  │     또는 VMware VM ──────── (V2V: Virtual to Virtual) ──┼──┐      │
  │     (소스 OS, 애플리케이션, 낡은 DB 모두 혼재된 덩어리)              │  │
  │                                                            │  │
  │  ===============================================================  │
  │                                                            │  │
  │    [ 2. 마이그레이션 도구 (Migration Service / 툴) ] ◀ 자동화 구간 │  │
  │      - AWS MGN, Azure Migrate 등 벤더사 전용 툴 설치            │  │
  │      - 새벽에 서비스 안 멈추고(Live) 디스크 블록 단위로 좍좍 긁어 복제 ──┘  │
  │                                                                   │
  │  ===============================================================  │
  │                                                                   │
  │    [ 3. 퍼블릭 클라우드 (Target Cloud Environment) ]               │
  │                                                                   │
  │               (복사된 디스크 이미지 / AMI)                           │
  │                         │ (Booting!)                              │
  │                         ▼                                         │
  │       ┌─────────────────────────────────────┐               │
  │       │  AWS EC2 인스턴스 (IaaS 클라우드 가상 서버) │               │
  │       │    - OS, 앱, DB 구조 과거와 100% 동일    │               │
  │       └─────────────────────────────────────┘               │
  │  ▶ 결론: 소스코드는 단 1바이트도 수정되지 않았다. 돌아가는 땅바닥만 바뀌었음!│
  └───────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 리호스트의 최대 강점은 '비침투성(Non-intrusiveness)'이다. 수십 년 된 시스템 중에는 그 코드를 짠 개발자가 이미 퇴사하고 소스 코드가 유실되어(블랙박스), 코드 한 줄 고치면 시스템 전체가 폭파되는 시한폭탄 같은 시스템이 널려있다. 이런 시스템은 재개발(Refactor) 자체가 물리적으로 불가능하다. 하지만 Rehost는 이 폭탄을 해체하지 않고 "폭탄 상자(VM 디스크) 전체"를 통째로 얼려서 클라우드로 텔레포트시켜 버린다. OS 커널과 메모리 상태까지 통째로 가상화(P2V/V2V)하기 때문에 호환성(버그) 문제가 터질 확률이 압도적으로 적다.

Rehost의 치명적 함정: 클라우드 빌 쇼크 (Cloud Bill Shock)

이 방식의 가장 큰 부작용은 엄청난 돈 먹는 하마가 된다는 점이다.

온프레미스 서버는 처음 살 때 크게 사놓고 1년 내내 켜두는 구조다(Over-provisioning). 이 "무식하게 거대한 세팅"을 클라우드로 그대로 Lift & Shift 해버리면? 클라우드는 켜둔 시간과 서버 크기에 비례해 초당 과금이 돌아간다.
심지어 밤 12시에는 손님이 없어도 서버를 줄이는 기능(Auto-scaling)을 사용할 수 없다(코드를 클라우드에 맞게 고치지 않았으므로).
결국 이사 오기 전보다 오히려 한 달 클라우드 요금이 3~4배가 넘게 폭증하는 이른바 클라우드 빌 쇼크(요금 폭탄) 사태가 발생하여 윗분들이 대노하게 된다.
📢 섹션 요약 비유: 이삿짐센터가 시골집 창고에 처박혀 있던 '안 쓰는 고장 난 냉장고(쓰레기 자원)'까지 모조리 새집 강남 타워팰리스로 옮겨놓은 꼴입니다. 타워팰리스는 짐칸 평수(서버 크기)마다 매달 비싼 월세(클라우드 비용)를 내야 하므로, 안 쓰는 쓰레기까지 끌고 온 대가를 엄청난 월세 폭탄으로 치르게 됩니다.

Ⅲ. 융합 비교 및 다각도 분석

6R 전략 내에서의 난이도 vs 가치 타협 (Rehost vs Replatform vs Refactor)

클라우드 이사는 돈과 속도의 극한의 눈치싸움이다.

전환 전략	난이도 및 이관 속도	클라우드 최적화 혜택 (유연성, 자동화)	리스크 (장애 발생 확률)	실무적 평가
Rehost (단순 복붙)	극도로 낮음 (제일 빠름)	거의 없음 (비싼 월세의 뚱뚱한 서버 잔존)	낮음 (코드를 안 건드림)	쫓기듯 이사 갈 때 쓰는 최후의 방패, "무늬만 클라우드"
Replatform (껍데기 교체)	중간 (수개월 소요)	중간 (관리형 DB(PaaS) 사용으로 백업/패치 자동화)	중간 (DB 연동 에러 가능성)	가장 이상적이고 많이 쓰이는 가성비 타협점의 표준
Refactor (전면 재개발)	극악 (수년 소요, 인건비 폭발)	100% 완전 누림 (컨테이너/서버리스로 극강 가성비)	매우 높음 (새로운 버그 창궐)	장기적 생존을 위한 최종 궁극의 목적지 (클라우드 네이티브)

대부분의 엔터프라이즈는 처음부터 무식하게 Refactor를 들이밀지 않는다. 전체 서버 1,000대 중 중요도 낮은 500대는 무지성으로 Rehost 해서 치워버리고, 쓸만한 300대는 Replatform (AWS RDS 등)으로 올리고, 핵심 결제망 200대만 비싼 돈을 주고 Refactor (MSA)로 갈아엎는 식으로 하이브리드 포트폴리오를 구성하는 것이 진짜 아키텍트의 실력이다.

📢 섹션 요약 비유: 회사 전체를 실리콘밸리(클라우드)로 이사시킬 때, 천재 개발자(핵심 코어)는 비행기 1등석(Refactor)에 태우고, 단순 서류 더미(구형 앱)는 제일 싼 화물선(Rehost)에 컨테이너째로 던져 넣어 보내야 회사의 예산이 거덜 나지 않습니다.

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

실무 시나리오

시나리오 — 데이터센터 임대 만료에 쫓기는 타임 투 마켓(TTM) 방어: 모 그룹사가 데이터센터 화재 사고 이후 클라우드 전면 전환을 지시했다. 주어진 시간은 단 3개월뿐인데, 500대의 사내 서버 중 절반이 10년 넘은 윈도우 서버 2008 기반의 낡은 C# 레거시다. 소스코드를 만질 수 있는 사람도 없다.
- 기술사적 판단: 이 상황에서 "클라우드 네이티브 최적화"를 운운하며 소스 코드를 열어 구조를 뜯어고치려(Refactor) 시도하는 것은 재앙을 부르는 오버 엔지니어링이다. 아키텍트는 즉시 500대 전량에 대해 AWS Application Migration Service (MGN) 같은 블록 단위 복제 에이전트를 깔아 Rehost (Lift and Shift) 전략을 강제해야 한다. 블랙박스화 된 레거시 앱은 건드리지 않고, 이미지(AMI) 덤프를 떠서 그대로 AWS의 EC2에 100% 물리적 복제본을 띄우는 것이 유일한 기한 내 완수 방법이며, 운영의 무중단 컷오버(Cut-over)를 가능케 하는 생존 전술이다.
시나리오 — Rehost 이후 폭증하는 비용 최적화 (Post-Migration FinOps): 성공적으로 Rehost를 마친 1년 후, 클라우드 운영 요금이 온프레미스 대비 200% 폭등했다. 128GB RAM짜리 서버 10대가 밤새도록 트래픽 0% 상태로 돌아가며 미터기 요금을 갉아먹고 있었다.
- 기술사적 판단: Rehost는 이사의 "끝"이 아니라 "시작"이다. 리호스트 이후의 과금 폭탄을 잡기 위해 아키텍트는 '우아한 축소 (Right-Sizing)'와 '스케줄링 (Scheduling)' 이라는 클라우드 재무 공학(FinOps) 튜닝에 착수해야 한다. CPU 사용률 추이를 분석해 128GB 인스턴스를 16GB 인스턴스(T3 타입 등 저비용 칩셋)로 찌그러뜨리고, 주말과 밤에는 사내 그룹웨어 서버가 자동으로 Stop 되도록 AWS Lambda 람다 스케줄러를 걸어 낭비되는 클라우드 과금을 강제로 틀어막는 후처리 공사(Post-optimization)가 수반되어야 한다.

Rehost 실행 전 아키텍트 체크리스트

종속성 늪 (Dependency Hell): A 서버를 복사해서 클라우드에 띄웠는데, 알고 보니 땅바닥(사내망)에 남겨둔 B 스토리지의 IP 주소를 하드코딩해서 바라보고 있어 클라우드에 뜨자마자 타임아웃으로 죽어버리지 않는가? (이사 가기 전 전체 서버 간의 네트워크 거미줄을 매핑 툴로 100% 스캔해야 한다.)
라이선스 제약 (Bring Your Own License, BYOL): 온프레미스에서 비싸게 산 MS-SQL이나 오라클 영구 라이선스를 쇳덩이째로 퍼블릭 클라우드에 들고 가면, 벤더사 정책에 의해 클라우드에서는 라이선스 무효화 처리를 맞고 수십억 벌금을 내야 할 수도 있다. (이때는 Rehost를 포기하고 Amazon Aurora 같은 오픈소스 관리형으로 Replatform 해야 한다.)
📢 섹션 요약 비유: 이삿짐센터를 부르면 집의 물건을 박스에 담아 새집에 딱 부려주기만(Rehost) 합니다. 박스에서 물건을 꺼내 새집 서랍장 크기에 맞게 구겨 넣고, 안 쓰는 옛날 옷을 버리는(비용 최적화 튜닝) 지루한 뒷정리는 결국 새집에 이사 온 우리(아키텍트)가 직접 해야 할 영원한 숙제입니다.

Ⅴ. 기대효과 및 결론

기대효과

무사고 초고속 피난 (Fastest Route to Cloud): 코드를 재작성하거나 DB 쿼리를 수정하는 리스크(버그 폭발) 없이, 현재 완벽히 돌아가는 "서버의 뇌 상태 100%"를 그대로 얼려서 전송하므로 안정성(Safety)과 속도 면에서 타의 추종을 불허한다.
클라우드 인프라 친숙화의 전초 기지: 온프레미스 쇳덩이만 만지던 사내 전산 직원들이, 일단 Rehost된 친숙한 구형 시스템을 AWS 환경 위에서 만져보며 클라우드의 보안, 네트워크(VPC) 기초를 훈련할 수 있는 소프트 랜딩(Soft Landing)을 돕는다.

미래 전망 (AI 기반 지능형 리호스트 마이그레이션)

과거 리호스트는 사람이 직접 서버에 들어가 에이전트를 깔고 밤새워 상태 창을 보며 디스크를 복제하는 수작업 노가다였다. 현대의 마이그레이션은 AI 옵스(AIOps)로 진화 중이다. 마이그레이션 봇(Bot)이 한 달간 온프레미스 망을 스캐닝하여 서버 1,000대 간의 종속성을 AI로 파악하고, "1그룹 50대는 오늘 밤 12시에 한꺼번에 복사하고, 이 녀석들 사이즈는 클라우드에서 절반 크기로 줄여서(Right-Sizing) 띄워라"라며 마이그레이션 웨이브(Wave) 계획표를 자동으로 짜고 버튼 클릭 하나로 텔레포트를 실행하는 무인 자동화 시대로 접어들었다.

결론

Rehost (Lift and Shift)는 클라우드 순수주의자(Cloud Purist)들에게는 "가짜 클라우드 전환"이라며 조롱받는 전략이다. 그들은 "컨테이너와 MSA로 모든 걸 갈아엎는 Refactor만이 진짜"라고 외친다. 하지만 1분 1초의 비즈니스 단절이 수십억 원의 손실을 낳고, 언제 터질지 모르는 블랙박스 코드를 안고 덜덜 떠는 엔터프라이즈의 현실 최전선에서, 수년간의 삽질과 재개발 지옥을 무시하고 일단 "적의 사거리 밖(안전한 클라우드 요새)으로 모든 아군을 하룻밤 새 대피"시키는 가장 폭력적이고 확실한 구명보트는 결국 Rehost뿐이다. 훌륭한 아키텍트는 이상에 취해 뜬구름을 잡지 않고, 때로는 이 투박하고 거친 지게차(Lift)를 몰고 가장 빠르게 회사의 인프라를 들어 올리는 용기를 가져야 한다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
마이그레이션 6R	클라우드 전환 시 시스템의 성격에 따라 Rehost, Replatform, Refactor 등 6가지 옵션 중 가장 효율적인 카드를 뽑아 드는 의사결정 프레임워크 뼈대다.
IaaS (Infrastructure as a Service)	Rehost 전략의 무조건적인 종착지로, 서버의 OS 껍데기부터 그 안의 낡은 먼지까지 고객이 직접 통제하는 순수한 "남의 컴퓨터 하드웨어 대여" 서비스다.
Replatform (리플랫폼)	Rehost의 무식함을 약간 튜닝한 것으로, 코드는 안 고치되 밑바닥 DB 껍데기만 AWS RDS 같은 관리형 서비스로 갈아 끼워 유지보수의 귀찮음을 반쯤 날려버리는 전략이다.
Refactor (리팩터 / 클라우드 네이티브)	Rehost의 정반대 대척점에 있는 이상향으로, 앱을 잘게 쪼개 MSA와 서버리스로 뼈대부터 재설계하여 클라우드의 오토 스케일링을 극한으로 빼먹는 궁극의 진화다.
Right-Sizing (자원 최적화 / FinOps)	Rehost로 무식하게 크게 떠온 서버들을, 클라우드 안착 후 트래픽 패턴을 분석해 CPU 반 토막짜리 싼 서버로 찌그러뜨려 클라우드 요금 폭탄을 방어하는 필수 심폐소생술이다.

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

리호스트(Rehost)는 낡고 허름한 시골집 방에 있던 '내 책상과 장난감 더미'를 박스에 막 쓸어 담아서, 으리으리한 새 아파트 거실에 똑같이 확 엎어놓고 이사를 끝내는 가장 빠른 이사 방법이에요.
새 아파트의 엄청난 최신식 자동 옷장(클라우드 혜택)은 하나도 못 쓰고 예전처럼 방바닥이 지저분하겠지만, 어쨌든 며칠 만에 골치 아픈 이사를 끝내버릴 수 있죠!
시간이 없고 급할 땐, 새집에 맞게 가구를 새로 예쁘게 짜 맞추는 짓(리팩터)은 나중에 천천히 하고, 일단 짐부터 트럭으로 퍼다 나르는(리호스트) 것이 제일 똑똑한 이사 작전이랍니다.