기고 | 클라우드로 이전하지 말아야 할 것들

Network World
* 벤더가 작성한 본 기고문은 네트워크 월드에 의해 일부 편집됐다. 그러나 벤더의 시각과 견해가 남아있을 수 있다.

클라우드는 많은 장점을 갖고 있다. 무제한의 용량, 사용한만큼 비용을 내는 가격 체계, 99.99%의 동작 보증, 지정된 인력의 인프라 관리 등을 예로 들 수 있다. 심지어는 보안과 컴플라이언스 관련 문제들도 해결이 가능하다. 그렇다면 모든 것을 클라우드로 이전하지 못할 이유가 있을까?

애석하게도 그렇다. 이런 '마술 같은 클라우드'로 모든 문제를 해결할 수 있는 것은 아니다. 고려해야 할 부분이 많다. 어떤 앱은 프라이빗 클라우드가 더 적합하다. 종종 퍼블릭 클라우드 자체가 맞지 않을 수도 있다. 반면 어떤 앱은 퍼블릭 클라우드가 더 잘 어울린다. 이는 '그렇다면 무엇을 클라우드로 이전해야 할까?'라는 질문을 제기한다. 대답하기 까다로운 질문이다.

클라우드의 성공을 좌우하는 것은 전략이다. 팀원 전원이 IT 예산 삭감을 걱정하고 이것이 유일한 성공 지표라면, 클라우드가 맞지 않을 수 있다. 하지만 IT 인프라 관리 비용 일체를 줄이는 전략을 추진하고 사고방식을 바꿔 문제를 해결하려고 노력한다면, 클라우드는 좋은 선택이 될 수 있다.

클라우드와 기존 기반을 조화시키는 방법에 대한 전략은 물론 평가 대상인 워크로드나 각 애플리케이션에 대한 전략도 필요하다. 클라우드의 장점을 최대화하는 가장 보편적인 전략은 특정 워크로드와 애플리케이션을 조사하고, 어떻게 배치를 해야 특정 시기에 가장 높은 ROI를 달성하는데 도움이 되는지를 판단하는 것이다.

클라우드 애플리케이션의 수명주기
애플리케이션의 수명주기는 가변적이다. 애플리케이션이 새로 등장하고 덜 알려진 초기에는 많은 정보를 가지고 필요한 대역의 종류, 스토리지 메모리, 연산 능력을 예측할 수 있다. 그러나 워크로드가 폭주하면서 예기치 않은 동작이 발생할 수 있다. 클라우드는 새로운 애플리케이션에 완벽하게 어울린다. 위험이 낮기 때문이다. 일단은 필요하다고 판단하는 자원보다 더 적은 자원을 배치한 후, 점차 더 많은 자원을 할당하고 행위를 관찰할 수 있다. 이런 새로운 애플리케이션은 테스트/개발 관련 애플리케이션에서 기업 활동에 아주 중요한 애플리케이션까지 다양하다.

애플리케이션들이 안정화될수록 더 예측 가능해지고 성숙해진다. 애플리케이션에 필요한 자원을 더 정확히 예측할 필요가 있다면, 퍼블릭 클라우드에서 더 안정적인 시간 책정이 가능한 내부 환경으로 이전을 하는 게 이익이 될 수 있다. 안정적이고 성숙한 앱 구현을 위해 민첩성과 확장성이 가져다 주는 비용 효익을 포기할 수 있는 것이다.  

레거시 애플리케이션이라면 고민해 해결해야 할 문제가 더 많다. 이미 성숙기를 지난, 자원 사용이 매달 줄어드는 앱들이다. 이들 앱은 내부 환경의 공간, 소중한 시간과 IT 인력을 잡아먹을 수 있다. 그러나 그냥 없애버리기는 힘들다.

클라우드는 이러한 애플리케이션의 퇴역을 위한 장소가 되어가고 있는 추세다. 애플리케이션에 드는 실제 비용을 판단해, 이 비용을 해당 앱의 소유주에게 전가할 수 있다는 것이 가장 큰 장점이다. 어쩌면 애플리케이션의 효용성이 제값을 못한다는 사실을 밝혀, 폐기에 박차를 가할 수도 있다. 이렇게 한 후에야 비용을 없앨 수 있는 것이다.

장점이 없는 경우
우리가 관찰한 패턴에 따르면, 퍼블릭 클라우드로 이전할지 여부를 결정할 때 조심해야 하는 애플리케이션 유형이 있다. 퍼블릭 클라우드로 이전하면 프라이빗 클라우드나 다른 내부 환경보다 ROI가 떨어질 수 있는 애플리케이션들이다. 그러나 애플리케이션은 가변적이기 때문에, 이런 규칙에는 항상 예외가 있다는 점을 감안해야 한다.

규칙: 성숙하고 안정적인 기업활동에 없어서는 앱들은 퍼블릭 클라우드로 이전하지 않는다. 앞서 수명주기와 관련된 내용에서 설명했듯, 안정적이고 자원 등에 있어 시간 예측이 가능한 앱들은 클라우드로 이전해도 장점이 없다. 이런 안정적인 앱보다는 자원이 폭주하거나 증감하는 앱들이 퍼블릭 클라우드에서 더 많은 효익과 더 높은 ROI를 창출한다. 즉 안정적인 앱들은 프라이빗 클라우드 환경에 상주시키는 게 더 낫다.

예외: SaaS 관련 중요 애플리케이션들은 종종 퍼블릭 클라우드에 더 적합하다. 기업활동에 중요한 SaaS(software-as-a-service) 애플리케이션의 경우 전체 수명주기 동안 퍼블릭 클라우드를 이용하는 것이 큰 도움이 되는 때가 많다.

여기에는 중요한 근거가 있다. 대부분 클라우드가 그린필드에 해당하고, 사용 패턴이 변하면서 환경에 부합해 지속적으로 성장을 하기 위해 IaaS의 탄력적 성격에 계속 의지해야 하기 때문이다. 또 SaaS 앱은 통상 PAYG(Pay As You Go) 방식이 맞는다. 매출 대비 기반 비용에 있어 가장 비용 효과적인 방식이기 때문이다.


규칙: 고도로 통합된 중요 앱은 기존 환경을 유지해야 한다. ERP나 금융 애플리케이션 같이 고도로 통합된 비즈니스 앱은 기존 환경을 유지해야 한다. 함부로 이전을 하면 기업 활동을 중단시키기도 하는 문제들을 초래할 수 있기 때문이다. ERP는 세부계획을 위한 시스템이다. 이보다 더 통합된 환경이 필요한 앱이 없다. 이전에 따라 업무가 중단될 수 있는 앱은 이전을 해서는 안 된다.

예외: 예외가 많지 않다. 단 ERP 솔루션을 아직 보유하고 있지 않은 상태에서 도입을 고려하는 경우가 유일한 예외 상황이 될 수 있다. 아직 기업 활동에 통합이 되지 않은 상태라면 클라우드에서 이런 앱을 도입할 수 있다. 그렇다면 도입 시기부터 혜택을 누릴 수 있고, 추후 이전을 걱정할 필요가 없다. 통합 솔루션을 찾는 젊은 회사라면 SaaS 솔루션이 좋은 선택이 될 수 있다. 여기서 반드시 물어야 할 질문은 '이미 통합을 했는가?'이다. 여기에 대한 대답이 '아니오'라면 클라우드 기반의 SaaS가 장기적으로 나을 수 있다.

규칙: 퍼블릭 클라우드에서의 버스팅(Bursting)은 효과를 보지 못할 수 있다. 내부 환경에서 애플리케이션을 유지하다, 더 많은 공간이 필요할 때 추가 자원을 퍼블릭 클라우드로 '버스팅'하면 된다고 생각들을 한다. 클라우드에 자원을 임대해, 클라우드와 소유 기반 사이에서 버스팅을 한다는 생각이다. 그러나 아직까지는 널리 활용되고 있지는 못하다. 성공 사례가 없기 때문이다. 아직까지는 긍정적인 효율성을 성취할 만큼 기술이 발전하지 못했다.

예외: 현재 퍼블릭 클라우드에서 이익을 창출할 수 있어 널리 활용되고 있는 클라우드버스팅에는 두 종류가 있다. 수평 버스트와 수직 버스트이다. 수직 클라우드버스팅은 인트라클라우드(Intracloud) 애플리케이션 버스트이다. 충분한 공간과 자원을 보유하고 있는 클라우에 애플리케이션을 상주시키면서 특정 비율로 버스팅을 하는 경우이다.  인트라클라우드(intracloud) 버스트라고 부르는 이유는 상주하는 동일 클라우드에서 버스팅을 하기 때문이다.

수평버스트는 인터클라우드(intercloud) 버스트라고 불리운다. 현재 가장 효과가 높은 클라우드간 버스팅이다. 그러나 통상의 '버스팅' 개념과는 다른 개념을 갖고 있다. 이보다는 더 적은 애플리케이션을 퍼블릭 클라우드로 옮기는 개념이다. 프라이빗 클라우드에 상주하는 애플리케이션이 용량 한계에 직면하지 않고 프라이빗 클라우드 내부에서 버스트를 하도록 공간과 자원을 확보하는 방식이다. 어쩌면 프라이빗 클라우드 애플리케이션이 버스트를 할 수 있도록 공간을 확보하는 방식과 비교해, 적은 양의 안정적인 워크로드를 퍼블릭 클라우드로 이전하는 방식에 큰 혜택이 없을 수도 있다.
 
기업용 애플리케이션을 클라우드에서 실행시켰을 때 특징과 수명주기를 판단해 효과가 있는 방식이 무엇인지 가장 먼저 생각해야 한다. 모든 앱을 퍼블릭 클라우드로 옮기는 전략을 고려해서는 안 된다. 경제성과 효율성이 기대만큼 좋지 않을 수 있기 때문이다.

또 가장 골칫거리이고, 가장 많은 자원과 대부분의 데이터를 잡아먹는 애플리케이션을 무턱대고 서둘러 골라서도 안 된다. 물론 다른 앱과 고도로 통합되어 있는 중요 앱을 클라우드로 이전할 필요가 있을 수 도 있다. 클라우드는 '만병통치약'이 아니다. 어떤 애플리케이션을 어떤 환경에 배치할지 전략을 신중히 고려해야 한다. 각 애플리케이션별로 클라우드 스토리지 전략을 수립해 이행해야 성공을 거둘 수 있다.

* Jake Robinson은 블루록(Bluelock)의 솔루션 아키텍트다. ciokr@idg.co.kr