클라우드 전환 · 마이그레이션

클라우드 전환이란?

전환이 끝나고 실제로 달라지는 것은 서버가 놓인 위치가 아니라 결재선입니다. 예전에는 장비 도입 품의를 한 번 올려 승인받고 3~5년을 쓰는 구조였다면, 이제는 매달 청구서가 날아오기 때문에 돈을 쓰는 주체가 현업 개발팀으로 내려옵니다. 구매팀이 연 단위로 통제하던 지출이 일 단위로 흩어지므로, 누가 자원을 켤 수 있고 그 금액은 누가 책임지는지를 조직도 위에 다시 그려야 합니다.

여섯 가지 방식 중 실제 목록을 뽑아 보면 대다수는 리호스트와 리테인으로 몰립니다. 단종된 벤더 패키지, 소스가 남아 있지 않은 사내 개발 시스템, 특정 설비에 묶인 연동 서버처럼 손댈 수 없는 것들이 전체의 3분의 1씩 나오기 때문입니다. 리팩터는 트래픽 변동이 크고 앞으로 3년 이상 기능을 계속 붙일 시스템에만 배정하는 편이 안전합니다. 여기서 클라우드 전환과 클라우드 네이티브 전환은 서로 다른 사업입니다. 앞은 인프라를 옮기는 일이고 뒤는 애플리케이션 구조와 배포 방식을 바꾸는 일이라, 예산과 기간을 따로 잡아야 합니다.

돈이 가장 많이 새는 구간은 전환 중간입니다. 사내 장비를 끄지 못한 채 클라우드 자원을 띄워 두는 병행 운영 기간에는 비용이 양쪽으로 나가고, 전용선 증설과 데이터 반출 요금까지 얹힙니다. 병행 기간을 시스템당 3개월 안쪽으로 못 박고, 기한이 지나면 옛 장비 전원을 내린다는 합의를 경영진에게 미리 받아 둬야 합니다. 끄는 날짜가 없는 전환 계획은 비용 계획이 아닙니다.

흔한 오해는 클라우드로 가면 관리 인력이 줄어든다는 기대입니다. 장비를 만지던 손은 줄지만 권한·네트워크·요금을 설계하는 사람이 새로 필요하고, 이 역할이 비면 개발팀이 편한 대로 자원을 만들다가 보안 그룹이 열린 채 몇 달씩 방치됩니다. 월 요금이 예상의 두세 배로 뛰는 사고는 대개 성능이 모자라서가 아니라 테스트용 인스턴스가 꺼지지 않아 생깁니다. 옮기면 빨라진다는 기대도 자주 어긋납니다. 사내망에서 밀리초 단위로 붙던 시스템이 인터넷을 거치며 오히려 느려지므로, 연동이 촘촘한 시스템은 묶어서 같이 옮겨야 합니다.