온프레미스→클라우드 마이그레이션: 단계별 로드맵

마이그레이션 전 현실 점검

온프레미스 그대로 리프트앤시프트하면 오히려 비용이 늘어날 수 있습니다. 성공적인 마이그레이션은 치밀한 준비에서 시작합니다.

6R 마이그레이션 전략

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 Capture

4단계: 최적화 (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"}}'

클라우드 마이그레이션은 기술 프로젝트이기 전에 비즈니스 변화 관리 프로젝트입니다.

마이그레이션 자동화 도구

수작업 이전은 실수와 다운타임의 원인입니다. 워크로드별 전용 도구를 활용하세요.

한국 환경 특수 고려사항

• 망분리·CSAP: 공공/금융은 인증된 리전·서비스만 사용 가능. 사전 확인 필수.
• 데이터 주권: 개인정보 국외 이전 시 동의·고지 요건. 국내 리전 우선 검토.
• 회선·이그레스: 대용량 초기 이전은 전용선(Direct Connect/ExpressRoute)이나 물리 전송(Snowball)이 인터넷 전송보다 빠르고 쌀 수 있음.

마이그레이션은 결국 사람 문제

기술 이전보다 어려운 건 운영 조직의 변화입니다. 온프레미스 운영팀의 역할을 클라우드 운영(FinOps·SRE)으로 재정의하고, 교육·권한 체계를 함께 옮겨야 "이전은 했는데 아무도 운영 못 하는" 상황을 피합니다.

컷오버 직후 성능 저하: 원인·검증·되돌리기

마이그레이션은 컷오버 당일보다 직후 며칠의 성능 저하에서 문제가 드러나는 경우가 많습니다.

원인

• 온프레미스에서는 같은 랙 안이던 앱과 DB가 서로 다른 AZ나 온프레미스-클라우드 구간으로 갈라져 왕복 지연이 늘어남
• DNS TTL이 길어 일부 클라이언트가 계속 구 서버로 접속
• 인스턴스 크기를 CPU 코어 수만 보고 맞춰, 디스크 IOPS·네트워크 대역폭 한도에 걸림

검증 명령

# 앱 서버에서 DB까지 왕복 지연
ping -c 20 db.internal
mtr -rwc 50 db.internal
# DNS 전환 상태와 남은 TTL
dig +noall +answer app.example.com
# 디스크 대기와 IOPS (EBS 한도 근접 여부)
iostat -x 1 10

클라우드 콘솔에서는 EBS 볼륨의 대기열 길이와 버스트 잔고, 인스턴스의 네트워크 처리량 지표를 함께 확인합니다.

해결

• 서로 호출이 잦은 서비스는 같은 웨이브에 묶어 함께 옮기고, 가능하면 같은 AZ에 배치합니다.
• 컷오버 12일 전에 DNS TTL을 60300초로 낮춰 두고, 전환 후 안정되면 원래 값으로 올립니다.
• 스토리지는 필요한 IOPS를 기준으로 볼륨 유형(gp3의 프로비저닝 IOPS 등)을 다시 선택합니다.

되돌리기 기준

• 컷오버 전에 "오류율 X% 초과 또는 p95 지연 Y ms 초과가 Z분 지속되면 롤백" 같은 조건과 담당자를 정해 둡니다. 롤백 시 데이터 역동기화 방법(DMS 역방향 작업 등)도 사전에 리허설합니다.

자주 묻는 질문 (FAQ)

Q. 리프트앤시프트부터 하면 안 되나요? 빠른 이전엔 유효하지만, 그 상태로 두면 클라우드 비용 이점을 못 누립니다. 이전 후 6R의 Replatform/Refactor로 단계적으로 최적화하는 계획을 함께 세우세요.

Q. 비용이 오히려 늘었습니다. 왜죠? 온프레미스 스펙 그대로 옮기면(과대 프로비저닝) 비싸집니다. 실제 사용량 기반 다운사이징, 약정 할인, 관리형 서비스 전환을 적용해야 절감이 실현됩니다.

이동 전략 매트릭스

컷오버 체크

[ ] DNS TTL 사전 하향
[ ] 데이터 최종 동기화 창 확정
[ ] 롤백 IP/스냅샷 준비
[ ] 합성 모니터링(핵심 URL) 통과
[ ] 온콜 배치·전쟁룸 채널

참고 자료

• AWS Migration Hub
• Google Migration Center

자주 묻는 질문 (FAQ) — 보강

Q. 빅뱅 컷오버 vs 병행 운영?
핵심 거래 시스템은 병행(스트랭글러) 권장. 내부 툴은 빅뱅도 가능.

검증 환경·편집자 주

• 검증 시점: 2026-09 (문서·CLI 플래그는 벤더 업데이트에 따라 달라질 수 있음)
• 명령어는 읽기 전용 조회 위주이며, 프로덕션 적용 전 스테이징에서 plan/dry-run을 권장합니다.
• 본문은 공식 문서 링크와 운영에서 반복되는 실패 패턴을 기준으로 편집 검토했습니다.

실무 적용 순서 (요약)

1. 현재 상태 측정(메트릭·비용·오류율) 없이 도구부터 바꾸지 말 것
2. 가장 작은 범위에서 변경 → 롤백 조건 명시
3. 체크리스트를 런북/티켓 템플릿에 옮겨 팀 공유
4. 한 달 뒤 지표로 효과 재평가 후 확대