클라우드 도입에 성공한 조직이 전하는 팁 5가지

많은 기업이 클라우드 활용 방안을 재검토하고 있다. 필자가 접한 자료와 직접 들은 이야기 모두 같은 흐름을 보여준다. 왜일까? 예상보다 높은 비용 때문이다. 일부는 비용이 지나치게 올라 클라우드에서 운영하던 애플리케이션을 다시 데이터센터로 옮겨야 했다. 하지만 필자와 대화를 나눈 기업 중 약 10%는 처음부터 전략을 제대로 세워 성공을 거뒀다고 밝혔다. 클라우드의 장단점을 누구보다 잘 아는 이들이 전하는 조언은 무엇이며, 이들로부터 배울 수 있는 점은 무엇일까?

첫 번째 팁은 클라우드 전략을 수정할 필요가 없었다고 밝힌 모든 기업이 공통적으로 언급한 조언이다. 초기 설계 단계에서 불가능한 경우가 아닌 한 애플리케이션은 기본 서비스만을 기반으로 구축하라는 것이다. 가능한 경우 컨테이너 대신 IaaS/가상 머신(VM)을 사용하고, 서버리스보다는 컨테이너를 선택하며, 사용량 기반 과금 모델보다 전용 설비를 활용하라는 것이다. 또한 클라우드 서비스 업체의 웹 서비스 대신 자체 미들웨어를 가져와 배포하는 방식을 권장했다. 성공 사례 대부분이 처음부터 이런 접근을 취했으며, 약 10%의 기업은 클라우드 트렌드에 편승했다가 빠르게 오류를 깨닫고 전략을 수정했다.

기업들은 클라우드 서비스 업체의 부가 기능 대부분이 개발 단계에서는 가치를 더하지만, 이후에는 예산을 지속적으로 소모하는 구조라고 지적했다. 한 기업은 IaaS/VM에서 호스팅하기 위해 미들웨어 기능을 라이선스했을 때에도 연간 비용이 업체 도구 사용료의 절반 수준이었다고 밝혔다. 오픈소스 소프트웨어를 직접 사용할 수 있다면 비용은 더 낮아질 수 있다. 다만 이를 위해서는 필요한 인재를 확보해야 한다는 점에 유의해야 한다.

이 팁은 다시 말해 ‘새로운 클라우드 기능을 쫓거나 작동 중인 애플리케이션을 불필요하게 변경하지 말라’는 것이다. 기업들은 몇몇 새로운 클라우드 기능이 경험 품질(QoE)이나 가용성을 개선하지 못한 채 지속적으로 서비스 비용만 늘린다고 분석했다. 이 원칙을 따르지 않은 한 기업은 “2년 동안 한 애플리케이션을 2번 재구현했는데, 매번 연간 클라우드 비용이 증가했다. 사용자가 변화를 체감한 곳마다 반응이 부정적이었다”라고 말했다. 이는 수십 년 전 한 CIO가 필자에게 한 말과도 맞닿아 있다. 그는 “시스템 이전 프로젝트가 최악의 프로젝트라고 생각한다. 비용만 들고 얻는 건 없다. 최선은 뭔가를 했다는 사실을 아무도 모르는 것”이라고 말했다.

워크로드 변동성, 최종 사용자 위치, 접속 요구사항을 고려하라

2번째 팁은 클라우드 경험이 풍부한 기업 80% 이상이 공통적으로 언급한 조언으로, 어떤 애플리케이션을 클라우드로 이전할지 선정하는 기준과 관련이 있다. 핵심은 워크로드 변동성이 큰 애플리케이션을 찾는 것이다. VM 기준으로 동일한 워크로드를 가정했을 때, 데이터센터 운영 비용이 클라우드 대비 25~40% 저렴하다는 것이 기업 다수의 경험이다. 하지만 피크 시점과 평균 리소스 수요의 비율이 약 2:1이라면, 데이터센터의 리소스가 평균적으로 일부 낭비되기 때문에 비용이 비슷해진다. 그리고 그 비율이 2.5:1이 되면, 클라우드가 CIO의 투자 대비 수익(ROI) 기준을 충족할 만큼 충분히 경제성이 높아진다.

이런 조언을 제시한 그룹은 클라우드를 ‘규모의 경제 게임’이라고 표현했다. 자체 데이터센터에서는 규모의 경제를 구현하기 어려운 영역, 즉 부하 변동성이 큰 환경에서 클라우드의 가치가 극대화된다는 것이다. 클라우드에서는 한 사용자의 피크 시점을 다른 사용자의 저부하 구간과 연동해 전체 작업량의 균형을 이룬다. 이로써 리소스 풀의 효율이 높아지고, 자체 데이터센터보다 더 경쟁력 있는 가격에 서비스를 제공할 수 있게 된다.

약 3분의 2 기업은 3번째 팁으로 사용자가 광범위하게 분산된 애플리케이션에 주목할 것을 권장했다. 여기서 ‘광범위’란 단순히 다른 도시나 지역이 아니라 대륙 단위의 분산을 의미한다. 이유는 간단하다. 작업 처리를 위해 데이터가 여러 네트워크를 거쳐야 하면 QoE와 가용성이 저하되어 사용자 불만으로 이어질 수 있다. 그러면 사용자의 물리적 위치에 더 가까운 곳에 리소스를 배치하는 것이 유일한 해법일 수 있다. 하지만 기업이 각 사용자 밀집 지역에 자체 데이터센터를 보유하고 있지 않다면, 새로 호스팅 거점을 직접 구축하더라도 설비 투자, 전력 및 냉각 비용, 운영 비용 측면에서 합리적인 규모의 경제를 달성하기 어렵다. 이 경우 클라우드를 활용하는 편이 더 저렴하다.

다만 중요한 점은, 애플리케이션 사용자의 분산이 실제로 어느 정도의 영향을 미치는지 신중히 평가해야 한다는 점이다. 경우에 따라서는 QoE나 가용성 차이가 미미해 굳이 호스팅 거점을 분산할 필요가 없을 수 있다. 때로는 애플리케이션의 호스팅 위치가 문제의 원인이 아닐 수 있다. 한 기업은 “클라우드는 쉬운 해결책처럼 보일 수 있지만, 반드시 경제적인 해법은 아니다”라고 말했다. 클라우드의 분산 호스팅으로 문제를 해결하기 전에 QoE 저하 원인이 실제로 어디에 있는지를 먼저 파악해야 한다.

4번째 팁은 사용자와 애플리케이션의 상호작용 모델을 면밀히 분석해, 그 안에 데이터 변경이 수반되지 않는(non-transactional) 작업이 얼마나 있는지 파악하는 것이다. 미션 크리티컬한 비즈니스 시스템과 핵심 데이터베이스는 대부분 데이터센터에 위치하며, 이를 변경하는 작업은 새로운 기록 추가, 수정, 삭제 같은 트랜잭션이다. 만약 사용자 상호작용이 트랜잭션 생성과 밀접하게 연결돼 있다면, 해당 애플리케이션의 처리는 데이터센터 자원에 종속된다. 이런 경우에는 사용자 인터페이스(UI) 부분을 클라우드로 옮겨도 비용 절감 효과를 얻기 어렵다. 반면 사용자와의 상호작용 중 상당 부분이 데이터 변경과 관련이 없다면, UI나 프론트엔드는 클라우드에서 합리적인 비용으로 호스팅할 수 있을 가능성이 높다.

이를 판단하는 방법은 트랜잭션 전 단계에서 사용자에게 실제로 어떤 데이터가 제공되는지를 살펴보는 것이다. 만약 데이터의 대부분이 핵심 데이터베이스에서 가져와야 한다면, 검토 목적으로 클라우드로 전송하는 과정에서 데이터 전송 비용이 급증하고 변동 폭이 커질 수 있다. 요약본 데이터나 별도의 데이터베이스를 클라우드에 두고 제공할 수 있다면 비용을 예측하고 통제할 수 있다.

애플리케이션을 신중하게 선택하라

마지막 팁은 단순하지만 가장 중요할 수 있다. 다른 이유로 변경이 필요한 애플리케이션에 집중하는 것이 바람직하다는 조언이다. 어떤 기업은 이미 변경이 예정된 애플리케이션만을 대상으로 하라고 조언하지만, 또 다른 기업은 그 범위를 더 넓게 잡아야 한다고 말한다. 애플리케이션을 재구축했을 때 절감할 수 있는 금액은 현재 비용과 예상 비용을 얼마나 정확히 파악하고 있는지, 변경 및 중단으로 인한 리스크가 어느 정도인지에 달려있다. 대부분의 경우 현재 비용은 비교적 정확히 산출할 수 있지만, 향후 비용은 그렇지 않다. 따라서 현재 비용을 산정할 때 합리적인 성장 추세를 반영하고, 클라우드 비용도 동일하게 계산해야 한다. 그러나 비용 비교 결과가 어떻든, 중요한 애플리케이션을 변경하는 일에는 항상 위험이 따른다. 기업들은 특히 클라우드로 이전하거나 반대로 되돌리는 일이 매우 큰 변화라는 점을 강조했다.

성공한 기업들이 내린 결론은 명확하다. 클라우드는 데이터센터와 매우 다르다는 점에서 가치가 있지만, 바로 그 차이 때문에 위험하기도 하다는 것이다. 한쪽에서 잘 작동하는 방식이 다른 쪽에서도 똑같이 작동한다고 가정해서는 안 된다. 좋은 방법은 처음부터 올바르게 설계하는 것이지만, 기업들은 클라우드 이전과 관련한 비용·수익 예측을 파일럿 테스트로 확인하는 것만으로도 예산과 프로젝트를 조기에 구할 ‘탈출구’를 마련할 수 있다고 입을 모았다. 이들은 “모든 업무가 클라우드로 이전되는 것은 아니다. 클라우드가 항상 최적의 해법은 아니기 때문”이라고 강조하면서, 클라우드 회의를 예약할 때마다 화이트보드에 이 내용을 적어두고 클라우드에 집중해야 할 때인지 스스로 점검해야 한다고 조언했다.
dl-ciokorea@foundryco.com