클라우드로 데이터를 올리는 일은 대개 무료이거나 저렴하지만, 다시 꺼내는 순간 요금이 붙는 경우가 많습니다. 이 비대칭 하나만 봐도 이전 비용을 서비스 단가만으로 계산하면 안 되는 이유를 알 수 있습니다. 이 글에서는 마이그레이션 서비스를 검토할 때 실제로 예산을 흔드는 요소를 순서대로 짚어 봅니다.
클라우드 마이그레이션 전략 6R과 일곱 번째 선택지
이전 방식은 크게 일곱 가지로 나뉘고, 방식마다 비용과 위험이 다릅니다. 처음에는 6R이라고 불렀던 분류에 나중에 하나가 더해져 지금은 7R로 설명하는 경우가 많습니다. 각각을 간단히 풀어 보면 다음과 같습니다.
리호스팅은 서버를 거의 그대로 옮기는 방식입니다. 리플랫폼은 핵심 구조는 두고 데이터베이스만 관리형 서비스로 바꾸는 식의 부분 최적화입니다. 리팩터링은 클라우드에 맞게 애플리케이션을 다시 설계하는 가장 무거운 선택입니다. 리퍼처스는 기존 소프트웨어를 SaaS 같은 상용 서비스로 교체하는 방식이고, 리로케이트는 가상화 환경을 큰 변경 없이 통째로 옮기는 방식입니다. 마지막 두 가지는 아예 옮기지 않는 것입니다. 리테인은 당장 두기로 한 시스템을 그대로 유지하고, 리타이어는 쓸모가 낮은 시스템을 폐기합니다.
많은 조직이 리타이어를 가장 늦게 검토하지만 효과는 의외로 큽니다. 운영 목록을 훑어보면 사용자가 거의 없거나 중복된 애플리케이션이 나오곤 합니다. 이런 시스템을 이전 대상에서 빼면 옮길 대상이 줄고 절차도 단순해지며, 이전 후 청구서에 올라갈 항목도 함께 줄어듭니다. 전략을 고르는 일은 시스템을 한 덩어리로 보지 않고 하나씩 분류하는 작업에서 시작합니다.
리호스팅과 VMware 클라우드 전환의 장단점
리호스팅, 흔히 리프트 앤 시프트라고 부르는 방식은 가장 빠릅니다. 코드를 건드리지 않으니 일정 예측이 쉽고, 데이터센터 계약 종료일이 정해져 있을 때 특히 현실적인 선택입니다. 문제는 기존 환경의 비효율까지 그대로 가져간다는 점입니다. 온프레미스에서는 여유 있게 잡아 둔 서버 사양이 큰 문제가 아니었지만, 사용한 만큼 내는 과금 체계에서는 과도한 사양이 곧 매달 나가는 비용이 됩니다. 빠르게 옮긴 대가로 장기 운영비가 오르는 일이 흔합니다.
VMware 가상화 환경을 쓰는 조직이라면 vmware 클라우드 전환이 현실적인 출발점이 되기도 합니다. 기존 가상머신과 운영 도구를 크게 바꾸지 않고 옮길 수 있어 전환 부담이 낮습니다. 다만 이 경로도 리호스팅의 성격을 띠므로 이전 직후가 끝이 아닙니다. 옮긴 뒤에 사양을 줄이고 구조를 손보는 두 번째 단계를 계획에 넣어야 비용 이점이 유지됩니다. 또한 라이선스 조건은 시기와 계약에 따라 달라질 수 있으니 이전 전에 공급사 조건을 직접 확인해야 합니다.
온프레미스 클라우드 전환 비용에서 데이터 이동이 차지하는 몫
클라우드 사업자는 데이터를 들여오는 인그레스에는 요금을 받지 않는 경우가 많습니다. 반면 데이터를 내보내는 이그레스에는 상당한 요금이 붙을 수 있습니다. 그래서 이전할 때는 부담이 작아 보여도, 나중에 다른 사업자로 옮기거나 백업을 외부로 가져가려 할 때 예상 밖의 비용이 생깁니다. 온프레미스 클라우드 전환 비용을 계산할 때 들어오는 길만 보지 말고 나가는 길의 요금표도 함께 읽어야 합니다.
대용량 데이터는 시간이 곧 비용입니다
데이터가 클수록 네트워크 대역폭이 병목이 됩니다. 인터넷 회선으로 며칠에서 몇 주가 걸리는 일도 생기고, 그동안 원본 시스템은 계속 변경됩니다. 그래서 초기 복제 후 변경분을 따라잡는 동기화 단계를 설계해야 합니다. 더 어려운 부분은 되돌리기입니다. 전환 후 문제가 발견되어 원래 환경으로 돌아가려면 데이터를 다시 맞추고 검증해야 하므로 복잡하고 오래 걸립니다. 롤백 시나리오는 이전 계획의 부록이 아니라 본문에 들어가야 합니다.
이중 운영 기간과 AWS 마이그레이션 비용
이전이 예정보다 길어지면 기존 인프라와 새 클라우드 자원을 동시에 유지하게 됩니다. 서버 유지보수비, 전력, 소프트웨어 라이선스가 계속 나가는 상태에서 클라우드 요금까지 붙으니 가장 아픈 구간입니다. 이중 라이선스가 생기거나 부서가 임의로 만든 비공식 클라우드 계정, 즉 섀도 IT 비용이 숨어 들어오기도 합니다.
aws 마이그레이션 비용을 가늠할 때도 이 점이 핵심입니다. 비용은 인스턴스 요금 하나로 정해지지 않고 이전 도구, 네트워크 전송, 이전 기간의 이중 운영, 이전 후 안정화 작업이 합쳐져 결정됩니다. 구체적인 금액은 사용량과 계약 조건에 따라 크게 달라지므로, 사업자가 제공하는 계산 도구와 최신 요금표로 직접 확인하는 것이 안전합니다. 일정을 현실적으로 잡고 단계별로 끊어서 옮기면 이중 운영 기간을 줄일 수 있습니다.
좀비 리소스를 잡아야 클라우드 이전 비용 절감이 유지됩니다
클라우드의 숨은 비용 중 가장 조용한 것이 좀비 리소스입니다. 테스트가 끝났는데 남아 있는 가상머신, 연결 대상이 없는 스토리지 볼륨, 아무도 접속하지 않는 데이터베이스가 대표적입니다. 이런 자원은 하루 24시간 요금을 발생시키고, 개별 금액이 작아 눈에 띄지 않다가 합치면 상당한 규모가 됩니다.
클라우드 이전 비용 절감은 이전 단계의 협상만으로 끝나지 않고 운영 단계의 습관에서 완성됩니다. 자원마다 담당자와 용도를 태그로 남기고, 일정 기간 사용이 없는 자원을 정기적으로 점검하며, 개발 환경은 업무 시간 외에 자동으로 끄는 규칙을 두는 방식이 흔히 쓰입니다. 사용량에 맞춰 사양을 조정하는 라이트사이징과 예약 약정 같은 할인 제도도 함께 검토할 만합니다. 이런 관리 체계를 흔히 FinOps라고 부릅니다.
사람에 드는 비용: 교육과 채용
도구와 인프라 못지않게 예산에서 빠지기 쉬운 항목이 인력입니다. 기존 운영팀은 서버와 네트워크에는 익숙해도 사업자별 서비스, 코드로 인프라를 관리하는 방식, DevOps 문화, 비용 관리 체계에는 새로 배울 것이 많습니다. 교육 비용과 학습 기간 동안 생기는 생산성 저하를 계획에 넣어야 합니다.
내부 역량만으로 부족하면 클라우드 전문 인력 채용이나 외부 서비스 활용도 예산에 포함해야 합니다. 이때 이전 프로젝트가 끝난 뒤 누가 운영을 맡을지도 함께 정해 두는 편이 좋습니다. 이전만 도와주고 떠나는 구조라면 운영 단계에서 다시 공백이 생길 수 있기 때문입니다.
공공 부문이라면: 네이버 공공 클라우드와 ISMS 인증 현황
공공기관이나 규제 산업은 비용보다 먼저 보안과 인증 요건을 확인해야 합니다. 공공기관은 민간 클라우드를 쓸 때 보안인증을 받은 서비스를 이용하는 것이 기본 원칙이고, 국내 사업자들이 이 요건에 맞춘 공공 전용 서비스를 운영합니다. 네이버 공공 클라우드도 그런 선택지 가운데 하나로 거론되며, 국내 데이터 거주와 기관 요건을 중시하는 조직이 비교 대상에 올립니다.
정보보호 관리체계인 ISMS와 개인정보까지 포함한 ISMS-P는 서비스 사업자와 이용 조직 모두에게 관련이 있습니다. isms 인증 현황은 인증기관이 공개하는 자료로 확인할 수 있으며, 어떤 서비스 범위가 인증 대상인지까지 봐야 합니다. 사업자가 인증을 받았더라도 내가 쓸 서비스가 그 범위에 들어가는지는 별개의 문제이기 때문입니다. 또 인증은 사업자가 지는 책임의 일부일 뿐이고, 계정 권한 관리나 설정 같은 이용자 몫의 보안 책임은 그대로 남습니다.
클라우드 마이그레이션 견적을 읽는 방법
견적서를 받으면 총액보다 구성을 먼저 봅니다. 이전 대상 시스템의 범위, 전략별 작업 구분, 데이터 전송 방식, 이전 후 안정화 지원 기간, 클라우드 사용료가 견적에 포함되는지 여부가 확인 대상입니다. 클라우드 마이그레이션 견적은 사전 진단 결과에 따라 달라지므로, 진단 없이 나온 숫자는 범위가 바뀌면 쉽게 달라질 수 있습니다.
항목이 빠져 있는지도 봅니다. 이그레스 요금, 이중 운영 기간, 교육, 롤백 대응이 견적에 없다면 나중에 추가 비용으로 돌아올 수 있습니다. 여러 업체의 견적을 비교할 때는 같은 범위와 가정 위에서 맞춰 보아야 비교가 의미를 갖습니다. 구체적인 금액과 조건은 업체마다 다르므로 각 제공자의 최신 정보를 직접 확인하는 것이 원칙입니다.
흔한 오해 바로잡기
첫 번째 오해는 클라우드로 옮기면 곧바로 비용이 줄어든다는 생각입니다. 사용 패턴이 변동적인 시스템에서는 이점이 크지만, 항상 같은 부하로 돌아가는 시스템은 오히려 온프레미스가 저렴할 수도 있습니다. 두 번째 오해는 모든 시스템을 옮겨야 한다는 생각입니다. 리테인과 리타이어도 정식 전략이며, 옮기지 않는 판단이 비용을 줄이는 경우가 많습니다.
세 번째 오해는 이전이 끝나면 프로젝트도 끝난다는 생각입니다. 실제로는 사양 조정, 미사용 자원 정리, 비용 모니터링이 이어지는 운영 과제가 시작됩니다. 네 번째로, 인증을 받은 사업자를 쓰면 보안이 자동으로 해결된다고 믿는 경우가 있습니다. 앞서 언급했듯 이용 조직의 설정과 권한 관리 책임은 별도로 남습니다.
이전을 시작하기 전 점검 요약
정리하면 순서는 이렇습니다. 먼저 시스템 목록을 만들고 옮길 것, 둘 것, 없앨 것으로 나눕니다. 다음으로 시스템별로 7R 중 맞는 전략을 고르고, 리호스팅을 택한다면 이전 후 최적화 단계를 일정에 넣습니다. 데이터 양에 맞는 전송 방식과 롤백 계획을 세우고, 이그레스 요금과 이중 운영 기간을 비용표에 반영합니다.
이전 후에는 좀비 리소스를 점검하는 주기와 비용을 책임질 담당자를 정합니다. 교육과 채용 계획도 예산에 넣고, 공공 부문이나 규제 산업이라면 인증 요건과 서비스 범위를 먼저 확인합니다. 이 점검 항목을 하나씩 채우면 견적서의 숫자가 무엇을 뜻하는지 읽을 수 있고, 예상과 실제 비용의 차이도 줄어듭니다.
