사우디 기업을 위한 클라우드 마이그레이션 체크리스트 (2026년 가이드)

사우디 기업을 위한 실용적인 단계별 클라우드 마이그레이션 체크리스트입니다. 현황 파악, 데이터 거주성 및 PDPL 준수, DNS와 이메일 전환, 테스트, 롤백까지 — 직접 실행할 수 있는 실제 명령어와 함께 다룹니다.

1. 현황 파악: 실제로 운영 중인 것을 목록화하라

측정하지 않은 것은 마이그레이션할 수 없습니다. 무엇이든 손대기 전에, 하나의 인벤토리 시트를 작성하십시오.

• 도메인 및 DNS 레코드 — 모든 A, AAAA, CNAME, MX, TXT(SPF/DKIM/DMARC), SRV 레코드를 나열합니다.
• 워크로드 — 사이트, 데이터베이스, 메일박스, cron 작업, 백그라운드 워커.
• 데이터 용량 — 대상 환경의 크기를 정확히 산정할 수 있도록 각 데이터베이스와 문서 저장소의 크기를 기록합니다.
• 종속성 — 서드파티 API, 결제 게이트웨이, 그리고 하드코딩된 모든 IP 허용 목록.

명령줄에서 DNS를 빠르게 가져올 수 있습니다:

dig alskyline.com ANY +noall +answer
dig MX alskyline.com +short
dig TXT alskyline.com +short

2. 데이터 거주성 및 규정 준수

사우디 기업에게 데이터가 어디에 있는가는 부차적인 고려사항이 아니라 최우선 요구사항입니다. SDAIA가 집행하는 사우디아라비아 개인정보보호법(PDPL)은 개인정보의 국경 간 이전을 제한하며, 국가사이버보안청(NCA)의 핵심 사이버보안 통제(Essential Cybersecurity Controls)는 민감한 워크로드가 적절한 보호장치와 함께 호스팅될 것을 요구합니다.

왕국 내(in-Kingdom) 인프라에 호스팅하면 이 논의에서 가장 까다로운 부분이 해소됩니다. Skyline Cloud는 기본적으로 데이터를 왕국 내에 유지하므로, PDPL 데이터 이전 평가가 단순해지고 사우디 사용자에 대한 지연 시간도 낮게 유지됩니다. 각 워크로드별로 다음 사항을 문서화하십시오:

• 데이터 분류(공개, 내부, 기밀, 개인정보).
• 호스팅 리전 및 처리자(귀하의 호스팅 계약에 명시됨).
• 보존 기간 및 백업 위치.

클라우드 호스팅 서비스 개요를 검토하여 각 워크로드를 적절한 제품 등급에 매핑하십시오.

3. 대상 아키텍처 선택

각 워크로드를 가장 적합한 가장 단순한 제품에 매칭하십시오:

과도하게 프로비저닝하기보다 적정 규모로 산정하십시오. VPS는 나중에 수직 확장이 쉬우므로, 현황 파악에서 나온 수치가 정당화하는 규모에서 시작하십시오.

4. 프로비저닝 및 스테이징 — 전환 이전에

대상 환경을 생성하고, 기존 시스템이 가동된 상태에서 데이터를 마이그레이션하십시오. 이 스테이징 단계가 마이그레이션을 되돌릴 수 있게(reversible) 만드는 핵심입니다.

전형적인 사이트 + 데이터베이스를 VPS로 이전하는 경우:

# On the source: export the database
mysqldump -u dbuser -p --single-transaction --quick mydb > mydb.sql

# Copy database and files to the new server
scp mydb.sql user@new-server-ip:/tmp/
rsync -avz --progress /var/www/mysite/ user@new-server-ip:/var/www/mysite/

# On the target: import
mysql -u dbuser -p mydb < /tmp/mydb.sql

그런 다음 테스트용 호스트명 또는 로컬 hosts 파일이 새 서버의 IP를 가리키도록 설정하고, 애플리케이션이 정상적으로 로드되고 로그인되며 데이터베이스에 올바르게 기록되는지 확인하십시오 — 이 모든 것을 공개 DNS를 변경하기 전에 수행합니다.

5. 전환에 앞서 DNS TTL을 낮춰라

DNS 변경은 TTL(time to live)에 따라 전파됩니다. 변경할 레코드의 TTL을 계획된 전환 시점 최소 24~48시간 이전에 **300초(5분)**로 낮추십시오. 그러면 기존 리졸버들이 전환 시 오래된 응답을 빠르게 잊어버립니다.

# Verify the current TTL on your A record
dig A www.alskyline.com +nocomments +ttlid

이러한 변경은 Skyline 매니지드 DNS로 깔끔하게 관리하여, 낮춘 TTL과 전환이 하나의 콘솔에서 이루어지도록 하십시오.

6. 이메일을 신중하게 마이그레이션하라

이메일은 서두를 경우 가장 고통스럽게 망가지는 워크로드입니다. 먼저 대상 환경에 메일박스를 프로비저닝한 다음, imapsync로 기존 메일을 동기화하여 아무것도 유실되지 않도록 하십시오:

imapsync \
  --host1 old-mail.example.com --user1 ahmed@alskyline.com --password1 'OLD' \
  --host2 mail.alskyline.com   --user2 ahmed@alskyline.com --password2 'NEW' \
  --ssl1 --ssl2

전환 기간 동안 기존 서버가 계속 메일을 수신하도록 유지하십시오. MX 레코드를 옮길 때는 발신 메일이 인증을 계속 통과하도록 SPF, DKIM, DMARC도 함께 업데이트하십시오. 게시해야 할 정확한 레코드는 비즈니스 이메일 호스팅 안내를 참조하십시오.

7. 전환 및 검증

전환일에는 순서대로 작업하십시오. 먼저 데이터와 메일의 최종 델타 동기화를 수행한 다음, DNS 레코드를 업데이트합니다(A/AAAA 먼저, MX 마지막). TTL이 낮으므로 전파가 빠릅니다. 즉시 검증하십시오:

# Confirm the new IP is being served
dig A www.alskyline.com +short
curl -sI https://www.alskyline.com | head -n 1

# Confirm mail is routing to the new host
dig MX alskyline.com +short

전체 체크리스트를 따라가십시오: 유효한 인증서로 HTTPS를 통해 사이트가 로드되고, 로그인이 작동하며, 테스트 거래가 완료되고, 예약된 작업이 실행되며, 테스트 이메일이 양방향으로 송수신되는지 확인합니다.

8. 폐기 — 단, 롤백 경로는 열어두어라

기존 환경을 즉시 삭제하지 마십시오. 최소 1~2주 동안 동결(frozen)된 상태로 계속 가동하십시오. 무언가 문제가 생기면, 기존 서버의 레코드를 다시 올리는 것(TTL이 여전히 낮음)이 즉각적인 롤백 수단이 됩니다. 깨끗한 모니터링 기간을 거친 후에만 기존 시스템의 최종 백업을 받고 폐기하십시오.

빠른 참조 체크리스트

• [ ] 도메인, 워크로드, 데이터 크기, 종속성의 전체 인벤토리
• [ ] PDPL/NCA를 위한 데이터 분류 + 거주성 문서화
• [ ] 실제 수치로 산정한 대상 아키텍처
• [ ] 대상 환경에서 스테이징 및 테스트된 데이터와 메일
• [ ] 24~48시간 전에 DNS TTL을 300초로 낮춤
• [ ] 이메일 동기화 완료; SPF/DKIM/DMARC 업데이트
• [ ] 전환을 종단 간(end to end) 검증
• [ ] 기존 환경을 롤백용으로 동결한 뒤 폐기

이런 방식으로 진행하는 마이그레이션에는 무서운 "빅뱅"이 없습니다 — 모든 단계가 테스트 가능하고 되돌릴 수 있으며, 데이터는 결코 왕국을 벗어나지 않습니다.

시작할 준비가 되셨나요? 오늘 Skyline Cloud 계정을 생성하고 대상 환경을 프로비저닝하십시오 — 첫날부터 왕국 내 데이터 거주성과 현지 아랍어 지원을 함께 제공합니다.