마이그레이션 전 현실 점검
온프레미스 그대로 리프트앤시프트하면 오히려 비용이 늘어날 수 있습니다. 성공적인 마이그레이션은 치밀한 준비에서 시작합니다.
6R 마이그레이션 전략
| 전략 | 설명 | 적합한 경우 |
|---|---|---|
| Rehost (Lift & Shift) | VM 그대로 이전 | 빠른 이전 필요 |
| Replatform | 최소 수정으로 최적화 | DB → 관리형 전환 |
| Repurchase | SaaS로 교체 | ERP, CRM |
| Refactor | 클라우드 네이티브 재설계 | 성능 개선 필요 |
| Retire | 폐기 | 사용 안 하는 시스템 |
| Retain | 온프레미스 유지 | 규정, 레이턴시 |
TCO 비교 예시
CODE
온프레미스 연간 비용: 11,200만 원
- 서버 하드웨어 감가상각: 3,000만 원
- 데이터센터 임대/전력: 1,200만 원
- 운영 인력: 5,000만 원
- SW 라이선스: 2,000만 원
클라우드 예상: 5,400만 원 (52% 절감)단계별 로드맵
1단계: 현황 분석 (1~2개월)
Bash
# AWS Application Discovery Service
# 에이전트로 30일 데이터 수집
# - CPU/메모리 사용률
# - 네트워크 트래픽 패턴
# - 서비스 의존성 맵2단계: 파일럿 마이그레이션 (1개월)
중요도 낮은 시스템 1~2개 먼저 이전. 프로세스 검증이 목적.
3단계: 웨이브 마이그레이션 (3~6개월)
CODE
Wave 1: 독립형 웹 서버 (의존성 없음)
Wave 2: 애플리케이션 서버 + DB
Wave 3: 핵심 업무 시스템
Wave 4: 레거시/통합 시스템데이터베이스 마이그레이션 (AWS DMS)
Bash
# Oracle → Aurora PostgreSQL
aws dms create-replication-task \
--replication-task-identifier oracle-to-aurora \
--source-endpoint-arn arn:aws:... \
--target-endpoint-arn arn:aws:... \
--migration-type cdc # Change Data Capture4단계: 최적화 (3개월 후)
- 다운사이징: 실제 사용량 기반 인스턴스 타입 조정
- Reserved Instance 구매 (1년 패턴 확인 후)
- 관리형 서비스 전환 (자체 DB → RDS)
실패하는 패턴
- 빅뱅 마이그레이션: 모든 시스템 동시 이전 → 실패 시 전체 마비
- 네트워크 설계 무시: VPC CIDR과 온프레미스 IP 대역 충돌
- 비용 모니터링 부재: 예상보다 3배 비용 발생
Bash
# AWS Budgets 알람 설정 (예산 80% 초과 시 알림)
aws budgets create-budget \
--account-id 123456789 \
--budget '{"BudgetName":"Monthly","BudgetLimit":{"Amount":"5000000","Unit":"KRW"}}'클라우드 마이그레이션은 기술 프로젝트이기 전에 비즈니스 변화 관리 프로젝트입니다.
마이그레이션 자동화 도구
수작업 이전은 실수와 다운타임의 원인입니다. 워크로드별 전용 도구를 활용하세요.
| 도구 | 용도 |
|---|---|
| AWS MGN (Application Migration Service) | 서버 블록 단위 복제·리프트앤시프트 |
| AWS DMS | DB 이전(CDC로 무중단 동기화) |
| Azure Migrate | 평가·종속성 매핑·이전 통합 |
| Google Migrate to Containers | VM → 컨테이너 현대화 |
한국 환경 특수 고려사항
- 망분리·CSAP: 공공/금융은 인증된 리전·서비스만 사용 가능. 사전 확인 필수.
- 데이터 주권: 개인정보 국외 이전 시 동의·고지 요건. 국내 리전 우선 검토.
- 회선·이그레스: 대용량 초기 이전은 전용선(Direct Connect/ExpressRoute)이나 물리 전송(Snowball)이 인터넷 전송보다 빠르고 쌀 수 있음.
마이그레이션은 결국 사람 문제
기술 이전보다 어려운 건 운영 조직의 변화입니다. 온프레미스 운영팀의 역할을 클라우드 운영(FinOps·SRE)으로 재정의하고, 교육·권한 체계를 함께 옮겨야 "이전은 했는데 아무도 운영 못 하는" 상황을 피합니다.
자주 묻는 질문 (FAQ)
Q. 리프트앤시프트부터 하면 안 되나요? 빠른 이전엔 유효하지만, 그 상태로 두면 클라우드 비용 이점을 못 누립니다. 이전 후 6R의 Replatform/Refactor로 단계적으로 최적화하는 계획을 함께 세우세요.
Q. 비용이 오히려 늘었습니다. 왜죠? 온프레미스 스펙 그대로 옮기면(과대 프로비저닝) 비싸집니다. 실제 사용량 기반 다운사이징, 약정 할인, 관리형 서비스 전환을 적용해야 절감이 실현됩니다.
✦ ✦ ✦
편집 검토 · Editorial Review
이 글은 AI 에이전트가 자료 조사와 1차 초안 작성을 담당하고, 사람 편집자가 사실관계·출처·톤과 맥락을 검토한 뒤 발행했습니다. 환경(OS·버전)에 따라 결과가 다를 수 있으니 적용 전 공식 문서를 함께 확인하세요. 오류를 발견하시면 이메일로 제보해 주세요 — 확인 후 신속히 정정합니다.
관련 공식 문서AWS 공식 문서 ↗
이 글이 도움이 되었나요?
댓글
첫 번째 댓글을 남겨보세요.