클라우드 기반 앱과 데이터를 송환하지 말아야 할 이유 3가지

구체적인 비즈니스 요구사항을 철저하게 점검해 보면 그대로 클라우드에 두는 것이 대부분 애플리케이션과 워크로드에 최선의 선택이라는 것이 드러날지 모른다.

최근 몇몇 애플리케이션과 데이터가 원래 환경으로 돌아오면서 클라우드 워크로드의 온프레미스 송환이 요즘 주목을 받고 있는 것 같다. 필자는 지난 글에서 일부 워크로드의 경우, 송환하는 것을 지지한다고 말하기도 했다.
 

글로벌 칼럼 | 2023년, 퍼블릭 클라우드 송환의 원년으로 삼아야

다시 한번 말하지만, 최종 목표는 비즈니스를 지원하는 최적의 아키텍처를 찾는 것이다. 그것이 때로는 퍼블릭 클라우드이고, 때로는 그렇지 않다. 아니면 아직 찾지 못했을 수도 있다.

기술은 진화한다는 것을 잊지 말자. 그리고 다른 기술 대신 특정 기술을 선택하는 사용 가치는 시간이 지나면서 크게 바뀐다. 필자는 오래전에 어떤 기술이나 플랫폼과도 사랑에 빠지지 않는 법을 배웠다. 필자가 클라우드 전문가로 경력을 쌓아왔지만, 클라우드 컴퓨팅이라도 마찬가지다.

그렇다면 가장 최적화된 기술은 어떻게 찾을 수 있을까? 비즈니스 요구사항을 플랫폼에 적용하는 것 외에 다른 방법은 없다. 실제로 송환된 애플리케이션과 데이터 세트 대부분은 처음에는 퍼블릭 클라우드에 있지 않았다. 클라우드 이전하겠다는 결정은 현실성보다는 욕심에 가까웠다.

따라서 지금은 애플리케이션과 데이터를 퍼블릭 클라우드 플랫폼에서 전통적인 시스템으로 되돌리고 싶지 않은 이유를 찾아보기 좋은 시점이다. 이 글이 조금은 논의의 균형을 맞추는 데 도움이 되기를 바란다. 이전 글을 보고 누군가는 필자를 “메인프레임 지지자”라고 할지도 모른다. 그러니 어느 쪽도 믿을 필요는 없다.

이제 애플리케이션과 데이터 세트를 퍼블릭 클라우드에서 전통적인 시스템으로 송환해서는 안되는 3가지 이유를 알아보자.
 

아키텍처 변경은 비싸다

애플리케이션을 클라우드에서 온프레미스 데이터센터로 송환하는 것은 복잡한 과정이 될 수 있다. 애플리케이션의 아키텍처를 다시 잡고 재구성하는 데는 상당한 시간과 자원이 필요하며, 이 때문에 그만한 가치가 있는지 의문이 생길 수도 있다. 게다가 아키텍처를 바꾸기 위해서는 보통 애플리케이션이나 데이터가 ‘거의 최적화된’ 방식으로 동작한다. 다시 말해 완전히 최적화되지 않은 방식으로 기능하는 것도 허용해야 한다. 이런 비용이 때로는 너무 커서 송환으로 얻을 수 있는 비즈니스 가치를 정당화하지 못하기도 한다.

물론, 이런 애플리케이션을 퍼블릭 클라우드로 이전해도 될 만큼 충분히 리팩터링하지 못한 경우가 대부분이다. 많은 경우, 이들 애플리케이션은 퍼블릭 클라우드에 두기에는 엉성하게 설계되었으며, 온프레미스 시스템 내에서도 마찬가지로 설계가 엉성하다.

하지만 이런 애플리케이션은 전통적인 플랫폼보다 퍼블릭 클라우드 상에서 최적화하고 리팩터링 하기가 더 쉽다. 요즘은 이런 워크로드를 재설계할 수 있는 툴이 퍼블릭 클라우드에 훨씬 풍부하다. 따라서 애플리케이션을 엉성하게 설계했다면, 보통은 송환하지 않고 퍼블릭 클라우드에서 문제를 해결하는 것이 낫다. 송환에 드는 비용과 수고가 훨씬 더 크기 때문이다.
 

퍼블릭 클라우드가 더 민첩하다

민첩성은 퍼블릭 클라우드에 남아 있어야 할 핵심 비즈니스 가치이다. 애플리케이션 송환에는 비용과 민첩성 간의 상쇄가 관련되는 경우가 많다. 온프레미스 데이터센터로 되돌리면 유연성이 떨어지고 타임 투 마켓도 늦어진다. 이는 민첩성이 중요한 산업군의 기업에는 치명적일 수 있다.

민첩성은 간과되는 경우가 많다. 송환 옵션을 고려할 때 눈에 보이는 비용 절감에 중점을 두고 민첩성이나 확장성, 유연성 같은 드러나지 않는 이점은 생각하지 않는 경우가 많다. 하지만 이들 이점은 전략적인 비용 절감보다 더 많은 가치를 제공한다. 예를 들어, 온프레미스 하드디스크 스토리지 비용과 클라우드 서비스 업체의 스토리지 서비스 비용을 직접 비교하는 것보다는 덜 분명하지만 영향은 더 큰 비즈니스 가치를 고려해야 한다.
 

물리 인프라와 구식 기술에 얽매인다

온프레미스 데이터센터는 물리 인프라를 기반으로 한다. 서비스 중단이나 유지보수 문제, 기타 장애가 발생할 확률이 높다. 이런 점은 퍼블릭 클라우드 플랫폼의 높은 가용성이나 확장성과 비교해 생산성 손실이나 안정성 저하로 이어질 수 있다.

드물게 발생하는 클라우드 서비스 중단 사고를 애플리케이션과 데이터를 온프레미스로 되가져와야 할 근거로 보는 경우가 있다. 하지만 솔직해지자. 과거의 온프레미스 환경에서 서비스 중단은 최근의 퍼블릭 클라우드와 비교도 안될 만큼 잦았다.

또한 지난 몇 년 동안 전통 플랫폼의 인력을 찾는 것이 힘들어졌다는 점도 기억해야 한다. 실력있는 엔지니어들이 클라우드 컴퓨팅으로 대거 옮겨갔기 때문이다. 실력 검증이 덜 된 인력으로 온프레미스 시스템을 유지하면 기억하는 것보다 훨씬 많은 문제에 직면할 수 있다. 클라우드 시절이 갑자기 “좋았던 시절”이 될 것이다.

모든 것이 그렇듯, 장단점은 있다. “해야 하는가?”와 “할 수 있는가?”란 두 가지 질문을 해야 한다. 이 근본적인 질문에 답하려면, 송환을 고려하는 각 워크로드와 데이터에 관해 비즈니스와 기술, 비용 상쇄를 살펴봐야 한다.

여기서부터 시작해 모두가 동의할 수 있는 결론을 내려야 한다. 모든 것을 고려사항에 포함하고 비즈니스 가치를 최고의 목적으로 설정해야 한다. 필자는 어떤 기술이나 플랫폼이 검증됐다는 이유로 무작정 사랑에 빠지지 않는다.