서버와 대상 환경을 나열하면 마이그레이션 제안서가 완성된 것처럼 보일 수 있습니다. 하지만 더 어려운 질문은 그 서버가 지원하는 업무에 관한 것입니다. 직원이 주문 처리를 계속할 수 있을까요? 예약된 내보내기는 언제 실행되나요? 이전한 뒤 누가 기록을 확인하나요? 클라우드 마이그레이션 계획은 인프라에 관한 결정을 이런 일상 업무와 연결해야 합니다. 다음 순서를 활용해 포괄적인 이전 계획을 검토 가능한 구체적인 작업으로 바꿔보세요.
이 페이지의 내용
운영상 개선할 점을 정의하세요
‘클라우드로 이전한다’는 목표를 평가 가능한 이유로 바꾸세요. 배포가 수동으로 설정한 서버 한 대에 의존하거나, 업무가 몰리는 시기에 현재 환경이 제공하지 못하는 용량이 필요할 수 있습니다. 미래 환경을 정의하기 전에 현재 동작을 기록하세요. 이 기준이 없으면 이전이 원래 문제를 해결했는지, 단지 문제가 발생하는 장소만 바꿨는지 판단하기 어렵습니다.
- 영향을 받는 업무 흐름과 담당자를 명시하세요.
- 반복 가능한 배포 절차처럼 확인할 수 있는 개선을 설명하세요.
- 이전 과정에서 지켜야 할 제약 조건을 나열하세요.
워크로드별 연결 관계를 정리하세요
각 애플리케이션의 데이터베이스, 파일 저장소, 예약 작업, 외부 서비스, 접근 요구사항을 목록으로 만드세요. 실제 운영 담당자에게 이 관계도를 검토해 달라고 요청하세요. 야간 보고서나 공급업체 연결은 서버 목록만으로는 놓치기 쉽습니다. 함께 이전해야 하는 의존 요소와 단계적 전환 중 그대로 유지할 수 있는 연결을 표시하세요.
애플리케이션별 이전 방식을 선택하세요
의사결정 예시: 고객 포털이 지원 중인 런타임을 사용하지만 오래된 회계 애플리케이션과 데이터베이스를 공유한다고 가정해 보겠습니다. 남아 있는 데이터베이스 연결이 합의된 접근 및 성능 요구사항을 충족할 때에만 포털부터 이전하는 것이 합리적일 수 있습니다. 그렇지 않다면 연결된 워크로드를 함께 옮기거나 의존 관계를 먼저 해결해야 합니다. 해당 애플리케이션의 필요에 맞춰 직접 이전, 특정 부분 수정, 재개발을 비교하세요. 전체 시스템에 한 가지 방식만 적용할 필요는 없습니다.
새 환경의 운영 방식을 설계하세요
접근 권한, 배포, 알림, 백업, 비용 검토의 책임자를 정하세요. 확보된 사용 정보를 바탕으로 수요를 추정하되, 한산한 기간과 피크 시간대를 모두 고려하세요. 저장 용량이 늘거나 서비스 간에 데이터가 이동하면 추정치가 어떻게 달라지는지도 살펴보세요. 유용한 비용 논의는 최초 추정치를 고정 운영 요금으로 간주하는 대신, 추정의 가정과 출시 후 모니터링할 대상을 설명합니다.
- 누가 운영 환경 설정을 변경할 수 있나요?
- 작업이 실패하면 누가 대응하나요?
- 백업 복원을 어떻게 검증하나요?
전환 전에 롤백 판단 기준을 정하세요
예시의 포털이라면 새 환경을 개방하기 전에 로그인, 주문 제출, 기록 수를 어떻게 검증할지 합의하세요. 어떤 실패가 전환 중단 사유인지, 누가 그 결정을 내리는지도 정해야 합니다. 전환 후 사용자가 새 기록을 만들 수 있다면 트래픽을 이전 서버로 돌리는 것만으로는 충분하지 않습니다. 새 기록을 처리할 합의된 계획이 필요합니다. 롤백에 추가 데이터 작업이 필요해지는 시점까지 포함해 전체 절차를 사전 연습하세요.
운영 점검으로 마이그레이션을 마무리하세요
이전 후에는 업무 흐름, 예약 작업, 알림, 사용 패턴을 합의된 기준과 비교하세요. 미해결 문제마다 담당자를 지정하세요. 팀이 전환 점검을 마치고 보존해야 할 데이터와 설정을 결정한 뒤에만 이전 환경을 폐기하세요. 서비스를 유지보수할 사람이 애플리케이션 관계도와 복구 지침을 확인할 수 있도록 해두세요.