온프레미스 클라우드 마이그레이션 하는 법, 6단계 정리
- 온프레미스 클라우드 마이그레이션은 평가·전략선택·설계·파일럿·본이전·안정화 6단계로 진행합니다.
- AWS가 정리한 6R 전략(리호스트·리플랫폼·리팩터 등) 중 워크로드 특성에 맞는 방식을 골라야 합니다.
- 다운타임과 비용 초과는 사전 의존성 분석과 파일럿 이전 생략이 주요 원인입니다.
- 이전 후에도 최소 1~2주 병행 운영하며 롤백 기준을 미리 정해두는 것이 안전합니다.
온프레미스 클라우드 마이그레이션, 핵심만 먼저 답하면
온프레미스(on-premise, 자체 데이터센터나 사무실 서버실에 직접 서버를 두고 운영하는 방식)에서 클라우드로 옮기는 작업은 크게 워크로드 평가 → 전략(6R) 선택 → 아키텍처 설계 → 파일럿 이전 → 본 이전 → 검증·안정화의 6단계로 진행됩니다. 순서를 건너뛰고 바로 서버를 복사해 옮기면 다운타임(서비스 중단 시간)이 늘어나거나 클라우드 요금이 예상보다 크게 나오는 경우가 많습니다. 아래 순서대로 진행하면 큰 사고 없이 이전을 마칠 수 있습니다.
- 워크로드 인벤토리 작성과 의존성 분석
- 6R 전략(리호스트·리플랫폼·리팩터·리퍼처스·리타이어·리테인) 중 시스템별 방식 결정
- 네트워크·보안·계정 구조 설계
- 영향이 적은 시스템부터 파일럿 이전 및 검증
- 본 시스템 이전과 데이터 동기화
- 성능·비용 검증 및 최적화, 온프레미스 자원 정리
1~3단계: 준비부터 설계까지
1단계. 워크로드 평가와 의존성 분석
가장 먼저 옮길 대상을 목록화해야 합니다. 서버 수, CPU·메모리·스토리지 사용량, 트래픽 패턴, 그리고 시스템 간 연동 관계(DB 접속 정보, 방화벽 규칙, 배치 작업 순서 등)를 정리합니다. 이 단계에서 TCO(총소유비용, Total Cost of Ownership — 서버 구매·전기료·유지보수 인건비 등을 합산한 비용)를 현재 온프레미스 운영비와 클라우드 예상 비용으로 각각 계산해 비교하면 경영진 설득 자료로도 활용할 수 있습니다. 의존성 분석을 생략하면 A 시스템만 옮겼는데 A가 참조하던 B 시스템이 온프레미스에 남아 있어 연동이 끊기는 사고가 흔하게 발생합니다.
2단계. 6R 전략 중 시스템별 방식 결정
모든 시스템을 같은 방식으로 옮길 필요는 없습니다. AWS가 정리한 마이그레이션 전략 중 시스템의 중요도와 노후도에 맞춰 6가지 방식(6R)을 선택합니다. 이 6R 프레임워크는 가트너가 2011년 제시한 5R(리호스트·리팩터·리바이즈·리빌드·리플레이스) 개념을 AWS가 확장해 만든 것입니다.
- 리호스트(Rehost): 코드 변경 없이 서버 이미지를 그대로 클라우드 가상머신으로 옮기는 방식, 흔히 ‘리프트 앤 시프트’라고 부릅니다.
- 리플랫폼(Replatform): 애플리케이션 구조는 유지하되 DB를 관리형 서비스로 바꾸는 등 일부만 최적화하는 방식입니다.
- 리팩터(Refactor): 클라우드 네이티브 구조(컨테이너, 마이크로서비스 등)로 다시 설계하는 방식입니다.
- 리퍼처스(Repurchase): 자체 구축 시스템을 SaaS(구독형 소프트웨어)로 대체하는 방식입니다.
- 리타이어(Retire): 더 이상 쓰지 않는 시스템은 이전 대상에서 제외하고 폐기합니다.
- 리테인(Retain): 법규나 보안 요건상 당장 옮기기 어려운 시스템은 온프레미스에 남깁니다.
실무에서는 오래된 레거시 시스템의 70~80%가 리호스트나 리플랫폼으로 처리되고, 신규 개발 예정이거나 트래픽 변동이 큰 서비스만 리팩터 대상으로 남겨두는 경우가 많습니다. 리팩터링을 택한다면 컨테이너 오케스트레이션 도구 도입이 뒤따르는데, 쿠버네티스 클러스터 구축하는 법을 함께 참고하면 설계 단계에서 시행착오를 줄일 수 있습니다.
3단계. 네트워크·보안·계정 구조 설계
이전 전 클라우드 계정(테넌트) 구조, VPC(가상 사설 클라우드, 클라우드 안에 격리된 나만의 네트워크 공간)와 서브넷 분리, IAM(자격 증명 및 접근 관리 — 누가 어떤 자원에 접근할 수 있는지 정하는 권한 체계) 정책을 먼저 설계해야 합니다. 이 단계를 생략하고 임시 계정으로 급히 옮기면 나중에 권한 재정비에 훨씬 많은 시간이 듭니다. 온프레미스와 클라우드를 병행 운영하는 기간에는 VPN이나 전용선으로 두 네트워크를 안전하게 연결하는 하이브리드 구간도 함께 설계합니다. 이 시기에 마이그레이션 전 백업 체계도 반드시 재점검해야 하며, 복구 시나리오를 미리 마련해두면 이전 도중 데이터 손상이 발생해도 대응이 훨씬 빠릅니다.
4~6단계: 파일럿부터 안정화까지
4단계. 영향이 적은 시스템부터 파일럿 이전
내부 관리 도구나 사용자가 적은 서비스처럼 문제가 생겨도 영향이 제한적인 시스템을 골라 먼저 옮겨봅니다. 파일럿 단계에서 실제 마이그레이션 도구(서버 이미지 변환, 데이터 전송 속도, 네트워크 지연 등)의 동작을 확인하고, 예상 소요 시간과 실제 소요 시간의 차이를 기록해두면 이후 본 이전 일정을 훨씬 정확하게 잡을 수 있습니다.
파일럿 이전을 건너뛰고 곧바로 핵심 시스템부터 옮기는 것이 마이그레이션 실패의 가장 흔한 원인입니다. 규모가 작더라도 반드시 파일럿을 먼저 진행하세요.
5단계. 본 시스템 이전과 데이터 동기화
본 이전은 보통 트래픽이 적은 새벽 시간대에 진행하고, 데이터베이스는 사전 동기화(초기 대량 복사) 후 전환 시점에만 차등 동기화(변경분만 복사)하는 방식으로 다운타임을 줄입니다. DNS 전환은 TTL(도메인 정보 캐시 유지 시간)을 미리 짧게 낮춰두면 트래픽 전환이 지연되는 문제를 줄일 수 있습니다.
6단계. 검증·최적화·안정화
이전 직후에는 성능 지표(응답 속도, 오류율), 로그, 비용을 매일 확인합니다. 클라우드는 종량제 요금이라 설계 단계에서 산정한 인스턴스 사양이 실제 트래픽과 맞지 않으면 비용이 예상보다 크게 나올 수 있습니다. 안정화가 확인될 때까지 온프레미스 자원은 즉시 폐기하지 말고 최소 1~2주 정도 대기 상태로 유지하며 롤백 가능성을 열어두는 것이 안전합니다.
마이그레이션 방식별 비교
| 전략 | 다운타임 | 초기 비용/난이도 | 적합한 경우 |
|---|---|---|---|
| 리호스트(리프트 앤 시프트) | 짧음 | 낮음 | 일정이 급하거나 코드 변경이 어려운 레거시 시스템 |
| 리플랫폼 | 중간 | 중간 | DB만 관리형으로 바꿔 운영 부담을 줄이고 싶은 경우 |
| 리팩터 | 계획된 전환 가능 | 높음 | 트래픽 변동이 크거나 장기적으로 확장할 서비스 |
흔한 실수와 체크리스트
- 의존성 분석 없이 시스템 단위로만 이전 계획을 세우는 것
- 파일럿 없이 핵심 업무 시스템부터 이전을 시작하는 것
- 클라우드 요금 체계(인스턴스 유형, 데이터 전송 비용, 스토리지 클래스)를 사전에 검토하지 않는 것
- IAM 권한을 임시로 넓게 부여한 뒤 이전 후 정리하지 않는 것
- 롤백 기준과 담당자를 사전에 정해두지 않는 것
이전 후 비용 관리 방법
클라우드는 사용한 만큼 비용이 청구되므로, 이전 직후에는 반드시 예산 알림(비용이 특정 금액을 넘으면 알려주는 기능)을 설정하고 리소스 사용량을 모니터링해야 합니다. 아래는 이전 후 자주 챙겨야 할 비용 최적화 항목입니다.
- 사용률이 낮은 인스턴스는 사양을 낮추거나 자동 확장(오토스케일링) 설정으로 전환
- 자주 사용하지 않는 데이터는 저비용 스토리지 등급으로 이동
- 장기 운영이 확정된 자원은 예약형 요금제로 전환해 비용 절감
- 불필요하게 남아 있는 테스트 자원, 스냅샷, 로그 정리
자주 묻는 질문
Q. 온프레미스 마이그레이션에 걸리는 기간은 보통 얼마나 되나요?
시스템 규모와 복잡도에 따라 다르지만, 워크로드 평가부터 안정화까지 소규모 시스템은 수 주, 다수의 레거시 시스템이 얽힌 대규모 환경은 수개월 이상 걸릴 수 있습니다. 파일럿 단계에서 측정한 소요 시간을 기준으로 전체 일정을 역산하는 것이 가장 현실적입니다.
Q. 모든 시스템을 클라우드 네이티브 구조로 바꿔야 하나요?
그렇지 않습니다. 6R 전략처럼 시스템별로 다른 방식을 적용하는 것이 일반적이며, 당장 재설계가 어렵거나 사용 빈도가 낮은 시스템은 리호스트나 리테인으로 두고 이후 단계적으로 리팩터링해도 됩니다.
Q. 다운타임 없이 마이그레이션이 가능한가요?
완전한 무중단 전환은 어렵지만, 데이터베이스 차등 동기화와 DNS 전환 준비, 트래픽이 적은 시간대 작업을 결합하면 다운타임을 수 분 이내로 크게 줄일 수 있습니다. 서비스 특성상 다운타임이 전혀 허용되지 않는다면 사전에 블루-그린 배포(신구 환경을 동시에 띄워두고 트래픽만 전환하는 방식) 같은 무중단 전환 방식을 별도로 설계해야 합니다.
Q. 클라우드로 옮긴 뒤 비용이 오히려 늘어날 수도 있나요?
네, 인스턴스 사양을 실제 트래픽보다 크게 잡거나 데이터 전송·저장 비용을 사전에 계산하지 않으면 온프레미스보다 비용이 늘어날 수 있습니다. 이전 전 TCO 비교와 이전 후 지속적인 비용 모니터링이 필요한 이유입니다.
Q. 마이그레이션 전문 인력이 없어도 진행할 수 있나요?
소규모 시스템이라면 클라우드 제공업체의 공식 마이그레이션 가이드와 도구를 활용해 자체적으로 진행할 수 있지만, 시스템 수가 많거나 법적 규제가 있는 데이터를 다룬다면 클라우드 마이그레이션 경험이 있는 파트너사나 컨설팅의 검토를 받는 것이 안전합니다.
