클라우드 마이그레이션 전략 (6R 전략)과 포트폴리오 평가

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

  1. 본질: 클라우드 마이그레이션 6R 전략(Rehost, Replatform, Refactor, Repurchase, Retire, Retain)은 기업이 사내 전산실(온프레미스)에서 돌아가고 있는 수백 개의 레거시(Legacy) 애플리케이션들을 클라우드로 이사(Migration)시킬 때, 시스템의 가치와 난이도에 따라 가장 최적화된 이전 방식을 6가지로 세분화하여 결정하는 의사결정 프레임워크다.
  2. 가치: "무조건 최신 기술(MSA)로 뜯어고친다"는 이상주의나 "무조건 서버만 통째로 떠서 복사한다"는 안일함에서 벗어나, 시스템의 비즈니스 중요도(ROI), 마이그레이션 예산, 시간의 제약을 저울질하여 선택과 집중을 가능하게 하는 현실적인 로드맵을 제시한다.
  3. 융합: 이 6R 전략은 단순히 인프라 엔지니어의 서버 복사 기술이 아니다. 기업의 디지털 전환(DX)을 리딩하는 엔터프라이즈 아키텍트(EA)와 클라우드 관리 서비스 기업(MSP)이 융합하여 전체 IT 포트폴리오를 평가(Assessment)하고, 향후 FinOps(비용 최적화)와 현대화(Modernization)의 밑그림을 그리는 전략적 나침반 역할을 한다.

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

  • 개념: 6R은 아마존웹서비스(AWS)의 클라우드 도입 프레임워크(CAF)에서 처음 제시되어 사실상 전 세계 클라우드 전환 컨설팅의 디팩토 표준(De facto standard)이 된 용어다. 6개의 영어 단어 첫 글자 R을 땄다. 시스템을 ①그대로 들어다 옮기거나(Rehost), ②조금만 바꾸거나(Replatform), ③완전히 새로 짜거나(Refactor), ④클라우드 기성품을 사 쓰거나(Repurchase), ⑤버리거나(Retire), ⑥그냥 내버려 두는(Retain) 6개의 객관관식 답안지다.

  • 필요성: 기업에 서버가 1,000대, 앱이 200개 있다고 치자. 사장님이 "올해 말까지 전부 클라우드로 넘겨!"라고 지시했다. 개발자들은 당장 모든 코드를 버리고 쿠버네티스(K8s)와 서버리스로 예쁘게 새로 짜고(Refactor) 싶어 하지만, 돈과 시간이 10배 넘게 든다. 반대로 인프라 팀은 그냥 서버 1,000대를 복사-붙여넣기(Rehost)해서 클라우드에 밀어 넣자고 하지만, 이러면 요금 폭탄을 맞고 성능 향상은 0이다. 결국, "사내 게시판은 SaaS를 사서 쓰고(Repurchase), 핵심 결제 엔진은 새로 짜고(Refactor), 오래된 통계 툴은 그냥 복붙하자(Rehost)"라는 기준점과 합의체가 절대적으로 필요해졌다.

  • 💡 비유: 우리가 10년 산 낡은 집에서 새 아파트로 이사(마이그레이션)를 갈 때를 상상해 보세요.

    • Rehost (리호스트): 낡은 침대와 냉장고를 이삿짐센터 트럭에 그대로 싣고 새집에 내려놓는 것 (가장 빠름).
    • Refactor (리팩터): 낡은 가구를 다 버리고, 새집 구조에 맞춰 목수와 디자이너를 불러서 가구를 백지부터 새로 짜맞춰 넣는 것 (가장 비싸고 오래 걸리지만 만족도 최고).
    • Repurchase (리퍼처스): 요리하기 귀찮으니 가스레인지를 버리고, 매일 아침 배달 도시락(SaaS 구독)을 정기 결제하는 것.
    • Retire (리타이어): 5년 동안 안 입은 옷은 이참에 미련 없이 쓰레기장에 버리는 것.

  • 등장 배경 및 발전 과정:

    1. 초기 (Lift & Shift 만능주의): 클라우드 초창기에는 벤더들이 무조건 서버를 복사(Rehost)해주는 툴(VM Import)만 만들어 마이그레이션 실적을 올리는 데 급급했다. 그 결과 엄청난 비용 낭비 역풍을 맞았다.
    2. 가트너의 5R / AWS의 6R 정립: 전체 IT 자산을 쪼개어 접근해야 한다는 평가 컨설팅(Assessment) 방법론이 발전하며 6R 모델이 정립되었다.
    3. 현대화 (Modernization / 7R, 8R로의 확장): 최근에는 Relocate(리전 이동), Re-architect 등 단어가 추가되며 계속 진화하고 있지만, 본질적으로 "속도냐 vs 아키텍처 혁신이냐"를 저울질하는 6R의 철학은 변함없이 통용된다.

  • 📢 섹션 요약 비유: 병원에서 수백 명의 환자(레거시 앱)가 응급실에 밀려왔을 때, 감기 환자는 약만 주고(Rehost), 중환자는 즉시 수술을 시키고(Refactor), 가망이 없는 환자는 포기하는(Retire) 등 환자의 상태와 병원의 자원을 냉정하게 계산해 처방을 내리는 의사(아키텍트)의 트리아지(Triage, 환자 분류) 시스템과 같습니다.

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

6R 전략의 세부 정의 및 스펙트럼

마이그레이션 난이도, 시간, 비용이 낮은 것부터 높은 것 순으로 정렬해보면 6R의 특성이 한눈에 들어온다.

전략 (R)개념 (비유적 표현)아키텍처적 행위 및 장단점최적의 적용 대상 (Use Case)
1. Retain (유지)아무것도 안 함클라우드로 안 옮기고 온프레미스에 그냥 놔둠.
(보안/규제가 빡세거나, 곧 사라질 시스템)		망분리 규제 적용된 핵심 고객 DB, 구형 메인프레임
2. Retire (폐기)쓰레기통 직행클라우드로 안 옮기고 시스템 자체를 영구 종료(Shutdown).
(비용 절감 효과 즉시 발생)		3년간 트래픽 0인 사내 구형 통계 서버
3. Repurchase
(재구매 / Drop & Shop)		남의 집 월세 살기기존 커스텀 앱을 버리고, 동일한 기능의 SaaS 플랫폼(Salesforce, Workday)을 돈 주고 구독함.자체 개발한 사내 이메일, CRM, 그룹웨어, HR 시스템
4. Rehost
(리호스트 / Lift & Shift)		복사 & 붙여넣기코드나 DB 수정 없이, 가상 머신(VM) 이미지나 디스크를 떠서 클라우드 IaaS(EC2) 위로 그대로 복사함.
(가장 빠름, 하지만 클라우드 이점 못 살림)		촉박한 데이터센터 방 빼기 일정, 단순 게시판, 마이그레이션 예산 부족 시
5. Replatform
(리플랫폼 / Lift, Tinker & Shift)		뼈대만 살짝 바꾸기핵심 소스 코드는 안 고치고, OS나 WAS만 업그레이드하거나 DB만 클라우드 관리형(RDS)으로 갈아타는 얌체 튜닝.구형 MySQL 5.5 ─▶ AWS RDS Aurora MySQL 8.0 으로 이동
6. Refactor
(리팩터 / Re-architect)		영혼까지 뜯어고치기모놀리식 코드를 박살 내고, 마이크로서비스(MSA), 컨테이너(Docker), 서버리스(Lambda)로 완전히 백지부터 재설계함.
(가장 비싸고 오래 걸리지만, 완벽한 클라우드 네이티브 달성)		회사의 메인 캐시카우 서비스 (쇼핑몰 결제 엔진 등 트래픽 폭주 시스템)

마이그레이션 난이도와 클라우드 네이티브 가치의 트레이드오프 곡선

  ┌───────────────────────────────────────────────────────────────┐
  │       마이그레이션 전략의 트레이드오프 (Effort vs Business Value)      │
  ├───────────────────────────────────────────────────────────────┤
  │                                                               │
  │   클라우드의 장점 (민첩성, 오토스케일링, 혁신 가치)                    │
  │     ▲                                                         │
  │     │                                                 ⭐ Refactor │
  │     │                                               (Cloud Native)│
  │     │                                                /        │
  │     │                                               /         │
  │     │                                     🟡 Replatform       │
  │     │                                      (Managed Service)  │
  │     │                                     /                   │
  │     │                                    /                    │
  │     │                           🔵 Repurchase (SaaS)          │
  │     │                           /                             │
  │     │  🔴 Rehost               /                              │
  │     │  (Lift&Shift)           /                               │
  │     │                        /                                │
  │     ├───────────────────────────────────────────────────────▶ │
  │        비용(Cost), 걸리는 시간(Time), 실패 리스크(Risk), 요구 스킬셋    │
  │                                                               │
  │  ▶ 핵심 통찰: Rehost는 빠르고 싸게 이사 갈 수 있지만 혁신이 '0'이다.       │
  │            Refactor는 돈과 피눈물이 들지만 완벽한 오토스케일링 보상을 준다. │
  └───────────────────────────────────────────────────────────────┘

[다이어그램 해설] 클라우드로의 이사는 결코 "공짜 점심"이 아니다. Rehost (Lift & Shift)는 당장 내일 서버를 클라우드로 올릴 수 있지만, 클라우드 환경에 최적화되지 않은 낡은 코드가 자원을 과도하게 점유하여 요금 폭탄을 부른다. 반면 우상단의 Refactor는 기존 코드를 서버리스나 컨테이너로 모두 뜯어고쳐야 하므로 1~2년의 개발 기간이 걸리지만, 완성되고 나면 인프라 비용이 획기적으로 줄고 트래픽 스파이크에 수초 만에 대응하는 궁극의 클라우드 마법을 누릴 수 있다. 아키텍트는 200개의 앱 중 어떤 앱을 Rehost하고 어떤 앱을 Refactor할지 황금 비율을 섞는 포트폴리오 기획자가 되어야 한다.

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

실무 시나리오

  1. 시나리오 — 데이터센터 임대 종료 시한의 압박 (Time Constraint): 회사 전산실 건물 계약이 3개월 뒤 만료되어 당장 서버 500대를 방 빼야 하는 초비상 상황. 신임 CTO가 "이참에 모든 레거시 코드를 버리고 쿠버네티스(MSA)로 100% 멋지게 전환(Refactor)해서 클라우드로 가자!"라고 선언했다.

    • 판단: 클라우드 마이그레이션 프로젝트가 실패하는 전형적인 "현실 무시 아키텍트의 과욕"이다. 500대 서버의 코드를 3개월 안에 K8s로 뜯어고치는 것은 구글 엔지니어 1,000명이 와도 불가능하다.
    • 해결책: 투-스텝 마이그레이션(Two-step Migration) 전략을 취해야 한다. 일단 3개월 안에 AWS Application Migration Service 등을 통해 서버 이미지를 통째로 찍어서 **Rehost(Lift & Shift)**로 클라우드(EC2)에 우겨 넣고 급한 불(방 빼기)을 끈다. 그 후 클라우드 안에서 1~2년의 장기 계획을 세워 핵심 서비스부터 천천히 Refactor (컨테이너화/서버리스화) 해나가는 점진적 스트랭글러 피그(Strangler Fig) 패턴을 도입하는 것이 현실적이고 성숙한 전략이다.

  2. 시나리오 — 라이선스 지옥과 Replatforming의 마법: 10년간 운영한 사내 인사(HR) 시스템 서버. 오라클(Oracle) DB를 쓰고 있는데, 클라우드로 그대로 서버 이미지를 떴더니(Rehost), 오라클 측에서 클라우드 환경에서는 CPU 코어 계산법이 다르다며 매년 20억 원의 추가 라이선스 폭탄을 청구했다.

    • 판단: 상용 DB(오라클, MS SQL)가 깔린 레거시를 그대로 Rehost하는 것은 벤더사의 라이선스 과금 함정에 스스로 걸어 들어가는 자살 행위다.
    • 해결책: Replatform(리플랫폼) 전략을 강력히 발동한다. 인사 시스템의 애플리케이션 코드는 건드리지 않되, 백엔드의 오라클 DB만 AWS SCT(Schema Conversion Tool) 등을 활용하여 오픈소스인 PostgreSQL (또는 AWS Aurora) 관리형 DB로 변환하여 엎어버리는(Drop and Replace) 결단을 내려야 한다. 약간의 쿼리 수정(Tinker) 공수는 들겠지만, 수십억 원의 상용 라이선스 비용 족쇄를 영원히 끊어낼 수 있다.

도입 체크리스트

  • 비즈니스적 자산 평가 (Discovery Phase): 마이그레이션 전에 사내 수백 개의 시스템을 엑셀에 올려놓고, "최근 1달간 한 번이라도 접속 로그가 있는가?"를 검사했는가? (놀랍게도 대기업 레거시의 약 10~20%는 아무도 안 쓰는 '좀비 서버'다. 무조건 올릴 것이 아니라 과감하게 Retire(폐기) 도장을 찍는 것이 가장 훌륭한 클라우드 요금 최적화(FinOps)의 첫걸음이다.)

Ⅳ. 기대효과 및 결론

정량/정성 기대효과

마이그레이션 전략 비율예상 결과 (100개 앱 기준)비즈니스 영향 (Business Impact)
100% Rehost (단순 복붙)마이그레이션 3개월 내 완료 / 운영비 폭증인프라 구조만 바뀌고 비즈니스 혁신/민첩성 0%
100% Refactor (전면 개조)마이그레이션 3년 지연 / 개발팀 번아웃예산 초과 및 프로젝트 좌초(실패) 리스크 90%
최적의 6R 믹스 (황금 비율)Retire 20% / Rehost 40% / Refactor 20% 등비용, 속도, 혁신을 모두 챙기는 성공적인 디지털 전환(DX) 안착

"클라우드로 가는 단 하나의 정답은 없다." 6R 전략은 IT 기술자들에게 비즈니스 마인드를 심어주는 훌륭한 계산기다. 기술사는 무작정 쿠버네티스(K8s)와 마이크로서비스(MSA)를 맹신하는 개발자들을 진정시키고, 가치가 낮은 게시판은 SaaS(Repurchase)로 사서 쓰고, 죽어가는 통계망은 버리고(Retire), 회사를 먹여 살리는 엔진 1~2개에만 전 개발자의 피와 땀(Refactor)을 갈아 넣도록 전체 전장(Battlefield)을 조율하는 사령관(Architect)이 되어야 한다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭관계 및 시너지 설명
스트랭글러 피그 (Strangler Fig) 패턴Refactor(전면 개조) 전략을 수행할 때 한 번에 시스템을 바꾸다 터지는 빅뱅 방식 대신, 덩굴식물처럼 기존 레거시 옆에 클라우드 네이티브 모듈을 조금씩 키워서 결국 기존 시스템을 말라 죽게(대체하게) 만드는 가장 이상적인 아키텍처 이전 패턴이다.
Lift and Shift (리프트 앤 시프트)6R 중 Rehost를 지칭하는 가장 유명한 은어. 지게차(Lift)로 떠서 그대로 클라우드로 밀어 넣는(Shift) 무지성 이동 방식이다.
Cloud-Native (클라우드 네이티브)6R 중 Refactor의 궁극적인 목표 지점. 애플리케이션을 컨테이너, 서버리스, MSA 기반으로 처음부터 클라우드 생태계에 딱 맞게 진화시킨 구조다.
클라우드 벤더 락인 (Lock-in)Refactor를 위해 AWS Lambda 같은 특정 벤더 전용 기술에 깊숙이 코드를 맞출 경우, 성능은 극대화되지만 나중에 다른 클라우드로 도망칠 수 없게 되는 족쇄 현상이다.
FinOps (클라우드 재무 운영)마이그레이션 과정에서 서버 사양을 무작정 1:1로 옮기면 요금 폭탄을 맞으므로, 옮기기 전/후로 서버 스펙을 다이어트(Right-Sizing)하고 Retire 시키는 돈 관리를 클라우드 아키텍처와 결합한 사상이다.

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

  1. 낡고 좁은 헌 집에서 최신식 새 아파트(클라우드)로 이사를 가기로 했어요! 내 방에 있는 수백 개의 장난감과 가구들을 어떻게 옮길지 고민이 생겼죠.
  2. 헌 침대는 짐꾼 아저씨를 불러 그대로 트럭에 실어 새집에 놓고요(Rehost/복붙). 10년 된 고장 난 로봇은 이참에 그냥 쓰레기통에 버려요(Retire/폐기).
  3. 하지만 내 공부방 책상만큼은 아빠한테 돈을 달라고 해서, 새집 크기에 딱 맞고 불도 번쩍거리는 최고급 맞춤형 새 책상으로 완전히 새로 짜맞춰 넣을 거예요(Refactor/전면 개조). 이렇게 물건마다 다르게 이사하는 지혜로운 작전을 '6R 마이그레이션'이라고 해요!