.jpg)
클라우드 이전의 네 가지 옵션 : 리호스트, 리인스톨, 리플랫폼, 리팩터
앱의 전략적인 가치와 가격 효율 측면 고려하면서 자산 평가해야
[보안뉴스 문가용 기자] 클라우드로 이전하고자 하는 기업들에게는 수많은 질문들이 있다. 그 중 가장 흔한 건 아마 “어디서부터 시작해야 할까?”나 “어떤 식으로 플랫폼을 재구성 해야 하는가?”, “코드를 다시 작성해야 하는가?”일 것이다. 하지만 여기에 단 하나의 정답이 존재하는 건 아니다. 여러 개의 답들이 있고, 각각의 장점과 단점이 존재한다. 그러므로 쉬운 답을 하나 배우는 게 아니라, 고민을 통해 가장 나은 것을 선택해야 한다.
대부분의 기업들에게 있어 다음 네 가지 옵션이 존재한다.
1) 리호스트(rehost) : 리프트 앤 쉬프트(lift-and-shift)라고도 불리는 전략으로, 기업 내 사용되던 모든 애플리케이션들을 클라우드로 들어서 옮기는 것을 말한다. 이 때 코드를 조정하는 일은 없다. 그러므로 리호스트의 가장 큰 장점은 속도다. 자원이 비교적 적은 조직이 취하기에 알맞은 방법이다. 하지만 애플리케이션을 클라우드에서 운영했을 때의 비용이 더 높아질 수 있다.
2) 리인스톨(reinstall) : 리호스트와 비슷한데, 클라우드 내에서 생성되는 가상 기기를 새롭게 만들고, 거기다가 소프트웨어들을 새롭게 설치하는 과정을 필요로 한다. 이 때 설정 조정 등을 하지 않는다. 그러므로 리호스트보다 조금 더 수고가 필요하다. 하지만 인프라가 재설치를 통해 깔끔하게 재정비 된다는 장점이 있다. 불필요한 파일까지 복사 과정을 통해 옮겨오는 일이 없어진다.
3) 리플랫폼(replatform) : 리플랫폼은 콘테이너와 가상 기기들을 활용한 이주 방법인데 자산을 클라우드로 옮기며 약간의 버전 변화를 가미한다. 예를 들어 아마존의 엘라스티캐시(Elasticache)나 고급 아마존 EC2 서비스인 엘라스틱 로드 밸런서(Elastic Load Balancer) 등을 사용하는 것인데, 이를 위해서는 애플리케이션 코드 변화가 어느 정도는 필요하다. 즉 온프레미스에서 사용하던 자산들을 클라우드에 맞게 하나하나 변경시켜가며 이주하는 것을 말한다. 느리지만 비용 최적화를 꾀하기에 알맞다.
4) 리팩터(refactor) : 조금은 더 발전된 아키텍처 변경 방법으로, 현재 애플리케이션들의 상당 부분을 다시 코딩해서 ‘클라우드 전용’으로 바꾸는 걸 필요로 한다. 주로 미들웨어와 애플리케이션 요소들의 변경이 자주 발생하는데, 이 과정을 잘 지나고 나면 마이크로서비스나 서버레스와 같은 보다 발전된 클라우드의 특성들을 잘 활용할 수 있게 된다. 이 과정에서 버리고 갈 앱과 디지털 자산을 과감히 버리는 결정도 내릴 수 있다.
그렇다면 이 중에 어떤 걸 선택해야 할까? 이 결정을 하기 위해서는 실행 가능성과 가격 효율을 분석해야 한다. 이를 조금 세세하게 나눠보면 다음과 같다.
1) 이 애플리케이션은 사업의 전략적 측면에 있어서 어느 정도 비중을 차지하는가? 수익 창출에 필요한 앱이며 투자의 가치가 있는가? 아니면 운영과 행정에 필요한 앱이며, 그러므로 TCO를 최대한 낮게 유지해도 되는가? 예를 들어 쇼핑몰 웹사이트의 경우 쇼핑 카트 앱 등에는 투자가 이뤄져야 하고, 직원들의 연차 수를 기록하는 앱은 유지하는 것이 더 효율적이다.
2) 현상 유지 혹은 최저의 비용을 필요로 하는 애플리케이션의 경우 이를 클라우드에서 리호스트 하는 게 가능한가? 그렇지 않다면 비슷한 기능의 SaaS 애플리케이션을 알아보는 것도 좋은 방법이다. 그래서 대체 가능성을 타진했다면 여태까지 써온 앱이라고 하더라도 과감히 버릴 수 있다. 대체 가능한 앱이 없다면 클라우드로 가져가야 한다.
3) 좀 더 과감한 투자가 필요한 앱의 경우 ‘어느 정도 돈을 써야 하는가?’에 대한 분석이 필요하다. 특히 재코딩이나 개발에 드는 비용과, 이 과정에서 사업 운영이 어느 정도나 영향을 받는지도 계산해야 한다. 예를 들어 사업에 전략적으로 필요한 앱이 서버레스 컴퓨팅에도 잘 어울린다는 판단이 섰다면, 개발 팀이 실제 업무를 진행해야 하는데 이에 필요한 인원이나 자원이 있는지를 파악한다. 그래서 추가 투자 비용이 그리 크지 않고 돌아올 것들에 대한 기대치가 높다면 리팩터가 최적의 옵션이다. 보통 자산의 10% 정도는 리팩터를 한다.
4) 리팩터가 불가능하다면 리플랫폼을 다음으로 고려한다. 보통 기업들은 25~30% 정도의 자산을 리플랫폼 처리한다. 이 경우 데브옵스 팀에서 애플리케이션의 조정과 변경을 맡아야 하는데 대대적인 재코딩이 필요한 건 아니다.
클라우드로의 이전 문제에는 쉬운 답이 없다. 철저히 전략적으로 고민하고 평가해야 한다. 그래서 버릴 건 과감히 버리고 살릴 건 어떻게 해서든 살려서 사업을 이어나가야 한다. 클라우드로 간다고 다 잘 되고, 온프레미스에 있다고 다 쇠퇴하는 건 아니다. 클라우드로의 이전은 현재 기업이 가지고 있는 자산과 전략에 대한 재평가 및 중간 점검의 기회이기도 하다.
3줄 요약
1. 클라우드 이전 시 고려해야 할 4가지 방법 : 리호스트, 리인스톨, 리플랫폼, 리팩터.
2. 단순하게 들어서 올리는 리호스트부터, 애플리케이션 재코딩을 필요로 하는 리팩터까지 특장점 다양해 냉정한 고민 필요함.
3. 고민의 중심은 “실행 가능성”과 “비용의 효율.”
글 : 아터 슐만(Aater Suleman), Flux7
[국제부 문가용 기자(globoan@boannews.com)]
앱의 전략적인 가치와 가격 효율 측면 고려하면서 자산 평가해야
[보안뉴스 문가용 기자] 클라우드로 이전하고자 하는 기업들에게는 수많은 질문들이 있다. 그 중 가장 흔한 건 아마 “어디서부터 시작해야 할까?”나 “어떤 식으로 플랫폼을 재구성 해야 하는가?”, “코드를 다시 작성해야 하는가?”일 것이다. 하지만 여기에 단 하나의 정답이 존재하는 건 아니다. 여러 개의 답들이 있고, 각각의 장점과 단점이 존재한다. 그러므로 쉬운 답을 하나 배우는 게 아니라, 고민을 통해 가장 나은 것을 선택해야 한다.
[이미지 = iclickart]
대부분의 기업들에게 있어 다음 네 가지 옵션이 존재한다.
1) 리호스트(rehost) : 리프트 앤 쉬프트(lift-and-shift)라고도 불리는 전략으로, 기업 내 사용되던 모든 애플리케이션들을 클라우드로 들어서 옮기는 것을 말한다. 이 때 코드를 조정하는 일은 없다. 그러므로 리호스트의 가장 큰 장점은 속도다. 자원이 비교적 적은 조직이 취하기에 알맞은 방법이다. 하지만 애플리케이션을 클라우드에서 운영했을 때의 비용이 더 높아질 수 있다.
2) 리인스톨(reinstall) : 리호스트와 비슷한데, 클라우드 내에서 생성되는 가상 기기를 새롭게 만들고, 거기다가 소프트웨어들을 새롭게 설치하는 과정을 필요로 한다. 이 때 설정 조정 등을 하지 않는다. 그러므로 리호스트보다 조금 더 수고가 필요하다. 하지만 인프라가 재설치를 통해 깔끔하게 재정비 된다는 장점이 있다. 불필요한 파일까지 복사 과정을 통해 옮겨오는 일이 없어진다.
3) 리플랫폼(replatform) : 리플랫폼은 콘테이너와 가상 기기들을 활용한 이주 방법인데 자산을 클라우드로 옮기며 약간의 버전 변화를 가미한다. 예를 들어 아마존의 엘라스티캐시(Elasticache)나 고급 아마존 EC2 서비스인 엘라스틱 로드 밸런서(Elastic Load Balancer) 등을 사용하는 것인데, 이를 위해서는 애플리케이션 코드 변화가 어느 정도는 필요하다. 즉 온프레미스에서 사용하던 자산들을 클라우드에 맞게 하나하나 변경시켜가며 이주하는 것을 말한다. 느리지만 비용 최적화를 꾀하기에 알맞다.
4) 리팩터(refactor) : 조금은 더 발전된 아키텍처 변경 방법으로, 현재 애플리케이션들의 상당 부분을 다시 코딩해서 ‘클라우드 전용’으로 바꾸는 걸 필요로 한다. 주로 미들웨어와 애플리케이션 요소들의 변경이 자주 발생하는데, 이 과정을 잘 지나고 나면 마이크로서비스나 서버레스와 같은 보다 발전된 클라우드의 특성들을 잘 활용할 수 있게 된다. 이 과정에서 버리고 갈 앱과 디지털 자산을 과감히 버리는 결정도 내릴 수 있다.
그렇다면 이 중에 어떤 걸 선택해야 할까? 이 결정을 하기 위해서는 실행 가능성과 가격 효율을 분석해야 한다. 이를 조금 세세하게 나눠보면 다음과 같다.
1) 이 애플리케이션은 사업의 전략적 측면에 있어서 어느 정도 비중을 차지하는가? 수익 창출에 필요한 앱이며 투자의 가치가 있는가? 아니면 운영과 행정에 필요한 앱이며, 그러므로 TCO를 최대한 낮게 유지해도 되는가? 예를 들어 쇼핑몰 웹사이트의 경우 쇼핑 카트 앱 등에는 투자가 이뤄져야 하고, 직원들의 연차 수를 기록하는 앱은 유지하는 것이 더 효율적이다.
2) 현상 유지 혹은 최저의 비용을 필요로 하는 애플리케이션의 경우 이를 클라우드에서 리호스트 하는 게 가능한가? 그렇지 않다면 비슷한 기능의 SaaS 애플리케이션을 알아보는 것도 좋은 방법이다. 그래서 대체 가능성을 타진했다면 여태까지 써온 앱이라고 하더라도 과감히 버릴 수 있다. 대체 가능한 앱이 없다면 클라우드로 가져가야 한다.
3) 좀 더 과감한 투자가 필요한 앱의 경우 ‘어느 정도 돈을 써야 하는가?’에 대한 분석이 필요하다. 특히 재코딩이나 개발에 드는 비용과, 이 과정에서 사업 운영이 어느 정도나 영향을 받는지도 계산해야 한다. 예를 들어 사업에 전략적으로 필요한 앱이 서버레스 컴퓨팅에도 잘 어울린다는 판단이 섰다면, 개발 팀이 실제 업무를 진행해야 하는데 이에 필요한 인원이나 자원이 있는지를 파악한다. 그래서 추가 투자 비용이 그리 크지 않고 돌아올 것들에 대한 기대치가 높다면 리팩터가 최적의 옵션이다. 보통 자산의 10% 정도는 리팩터를 한다.
4) 리팩터가 불가능하다면 리플랫폼을 다음으로 고려한다. 보통 기업들은 25~30% 정도의 자산을 리플랫폼 처리한다. 이 경우 데브옵스 팀에서 애플리케이션의 조정과 변경을 맡아야 하는데 대대적인 재코딩이 필요한 건 아니다.
클라우드로의 이전 문제에는 쉬운 답이 없다. 철저히 전략적으로 고민하고 평가해야 한다. 그래서 버릴 건 과감히 버리고 살릴 건 어떻게 해서든 살려서 사업을 이어나가야 한다. 클라우드로 간다고 다 잘 되고, 온프레미스에 있다고 다 쇠퇴하는 건 아니다. 클라우드로의 이전은 현재 기업이 가지고 있는 자산과 전략에 대한 재평가 및 중간 점검의 기회이기도 하다.
3줄 요약
1. 클라우드 이전 시 고려해야 할 4가지 방법 : 리호스트, 리인스톨, 리플랫폼, 리팩터.
2. 단순하게 들어서 올리는 리호스트부터, 애플리케이션 재코딩을 필요로 하는 리팩터까지 특장점 다양해 냉정한 고민 필요함.
3. 고민의 중심은 “실행 가능성”과 “비용의 효율.”
글 : 아터 슐만(Aater Suleman), Flux7
[국제부 문가용 기자(globoan@boannews.com)]
Copyrighted 2015. UBM-Tech. 117153:0515BC
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-11-22] 
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
