마이그레이션 전 현실 점검
온프레미스 그대로 리프트앤시프트하면 오히려 비용이 늘어날 수 있습니다. 성공적인 마이그레이션은 치밀한 준비에서 시작합니다.
6R 마이그레이션 전략
| 전략 | 설명 | 적합한 경우 |
|---|---|---|
| Rehost (Lift & Shift) | VM 그대로 이전 | 빠른 이전 필요 |
| Replatform | 최소 수정으로 최적화 | DB → 관리형 전환 |
| Repurchase | SaaS로 교체 | ERP, CRM |
| Refactor | 클라우드 네이티브 재설계 | 성능 개선 필요 |
| Retire | 폐기 | 사용 안 하는 시스템 |
| Retain | 온프레미스 유지 | 규정, 레이턴시 |
TCO 비교 예시
온프레미스 연간 비용: 11,200만 원
- 서버 하드웨어 감가상각: 3,000만 원
- 데이터센터 임대/전력: 1,200만 원
- 운영 인력: 5,000만 원
- SW 라이선스: 2,000만 원
클라우드 예상: 5,400만 원 (52% 절감)단계별 로드맵
1단계: 현황 분석 (1~2개월)
# AWS Application Discovery Service
# 에이전트로 30일 데이터 수집
# - CPU/메모리 사용률
# - 네트워크 트래픽 패턴
# - 서비스 의존성 맵2단계: 파일럿 마이그레이션 (1개월)
중요도 낮은 시스템 1~2개 먼저 이전. 프로세스 검증이 목적.
3단계: 웨이브 마이그레이션 (3~6개월)
Wave 1: 독립형 웹 서버 (의존성 없음)
Wave 2: 애플리케이션 서버 + DB
Wave 3: 핵심 업무 시스템
Wave 4: 레거시/통합 시스템데이터베이스 마이그레이션 (AWS DMS)
# 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배 비용 발생
# 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. 비용이 오히려 늘었습니다. 왜죠? 온프레미스 스펙 그대로 옮기면(과대 프로비저닝) 비싸집니다. 실제 사용량 기반 다운사이징, 약정 할인, 관리형 서비스 전환을 적용해야 절감이 실현됩니다.
AI 도구는 자료 조사와 초안 작성의 보조 수단으로 사용될 수 있습니다. Nodelog는 공개 전 내용과 출처를 검토하고, 환경(OS·버전)에 따라 결과가 달라질 수 있는 기술 정보는 공식 문서를 함께 확인하도록 안내합니다. 오류를 발견하시면 이메일로 제보해 주세요 — 확인 후 신속히 정정합니다.
댓글
첫 번째 댓글을 남겨보세요.