컨텐츠 바로가기

03.29 (금)

IDG 블로그 | 새로운 최적화 렌즈로 보는 클라우드 아키텍처

댓글 첫 댓글을 작성해보세요
주소복사가 완료되었습니다
이제 클라우드 컴퓨팅 아키텍처의 성공을 정의하는 방법도 한층 성숙해져야 한다. 클라우드 아키텍처에는 걸려있는 것이 너무 많다. 제대로 최적화되지 않고 비용이 많이 드는 클라우드 아키텍처는 동작하기는 하겠지만, 기업은 매주 수백만 달러의 손해를 볼 수도 있다. 12가지 기술이면 더 잘 동작할 수 있는데, 30가지 기술이 사용되고, 변화를 염두에 두지 않은 설계로 비즈니스 민첩성이 손상된다.
ITWorld

ⓒ Free-Photos (CC0)

<이미지를 클릭하시면 크게 보실 수 있습니다>



클라우드 아키텍처가 좀처럼 최적화되지 않는 이유는 무엇일까? 클라우드 아키텍트가 계획과 설계 단계에서 클라우드 아키텍처 교육 과정에서 배운 대로 하거나 다수의 레퍼런스에서 읽은 것을 적용한다. 이전 클라우드 아키텍처 프로젝트나 선임자에게 배운 팁을 적용하기도 한다. 이 모든 가이드는 아키텍트를 일련의 범용적인 레퍼런스 모델과 프로세스, 기술 스택 등으로 이끄는데, 이들은 모두 기업의 특정 비즈니스 요구사항을 해결할 수 있도록 수정해야만 한다. 이런 접근법이 필요 이상의 비용을 지출하도록 하는 최적화되지 않은 아키텍처를 낳는 것이다. 왜 이렇게 된 것일까?

이 질문에 답하기 위해 우리 자신을 되돌아볼 필요가 있다. 최적화된 클라우드 아키텍처는 실제로 어떤 의미일까? 필자는 ‘IDG 블로그 | 클라우드 아키텍처 최적화 쉽게 이해하기’란 글을 통해 클라우드 아키텍처 최적화 프로세스를 정의한 바 있다. 그리고 이용하기 좋은 높은 수준의 모델도 제시했다. 필자의 클라우드 아키텍처 교육 과정도 이런 개념을 포함하도록 보강했다.

다음으로는 과거에는 모든 요소가 함께 동작하는 데 중점을 두었다는 것을 알아야 한다. 당시에는 얼마나 잘 동작하고 솔루션이 얼마나 복잡해지는가에는 큰 비중을 두지 않았다. 성공의 척도는 “동작하는가?”였지 “얼마나 잘 동작하는가?”는 아니었다.

개발 과정에서 클라우드팀은 클라우드 아키텍처와 마이그레이션, 새로운 개발에 대한 접근법에 온전히 집중했다. 메타 클라우드 아키텍처 같은 넓은 관점과 마이크로 클라우드 아키텍처 같은 좁은 관점 모두에 집중했다. 이제 클라우드 마이그레이션과 새로운 클라우드 네이티브 개발을 어떻게 설계하고 배치하느냐, 또는 컨테이너와 서버리스, 기타 크고 작은 클라우드 솔루션을 어떻게 활용하느냐는 크게 중요하지 않다. 그보다는 해당 솔루션의 목적을 어떻게 정의하느냐가 더욱 중요하다.

IT와 기업 경영진은 솔루션이 그저 동작하거나 혁신적인 것처럼 보이는 것만으로는 예상보다 훨씬 많은 운영 비용의 이유가 되지 못한다는 사실을 알 만큼 현명해졌다. 오늘날 우리는 클라우드 솔루션의 최종 상태를 감사하고 평가해 성공의 명확한 기준을 제공하는지 확인해야 한다. 클라우드 배치의 계획과 개발 단계는 이런 감사와 평가 프로시저를 계획하고 구축하기에 좋은 단계로, 개발 이후 프로젝트의 전반적인 ROI를 측정할 수 있다.

이런 식으로 결과물에서 시작점까지 살펴보는 관점은 클라우드와 클라우드 관련 솔루션을 구축하고 배치하는 전문가의 앞을 가로막을 수 있다. 대부분 클라우드 전문가는 자신의 설계와 구축이 첨단이고, 해당 시점에서 이용할 수 있는 최상의 솔루션으로 구축했다고 믿는다. 자신의 디자인이 최대한 최적화되었다고 생각한다. 하지만 대부분 경우, 이들이 틀렸다.

지난 10년간 구현된 클라우드 솔루션 대부분은 심하게 덜 최적화되었다. 그 정도가 얼마나 심한지, 만약 배치됐어야 하는 것과 실제 배치된 것에 대해 면밀하게 감사를 한다면, 제대로 최적화된 클라우드 솔루션은 전혀 다른 그림이라는 것을 알게 될 것이다. 아마도 컨테이너를 너무 많이 사용했거나 충분히 사용하지 못했을 것이다. 클라우드 네이티브 리팩터링을 강화하는 것에 실패했을 수도 있고, 리팩터링의 이점을 제대로 고려하지 않았을 수도 있다. 최근에는 멀티클라우드를 필요 이상으로 복잡하게 만들어 보안이나 운영 같은 공통 서비스를 정의하지 못한 경우도 많다. 보편적이지 않은 상황에 너무 많은 공통 서비스를 사용하는 경우도 있다.

전체적으로 보면, 클라우드 아키텍트는 책이나 비디오, 기사, 심지어 전문가들이 말하는 원론에서 배운 것으로 적용한다. 아키텍트는 비즈니스 요구사항이 무엇인지 정의하고, 이들 요구사항을 가장 최적화된 솔루션과 연결한다. 좋은 접근법이다.

하지만 생각해 보자. 솔루션 업체 A는 재무 운영에 가장 좋은 네이티브 앱이 있고, 솔루션 업체 B는 최고의 CRM 앱을, 솔루션 업체 C는 최고의 재고관리용 앱이 있다. 이런 식으로 보안이나 스토리지, 네트워킹까지 동종 최고의 서비스만으로 구성된 멀티클라우드는 기업에 최대의 이점을 가져다주지 못할 것이다. 각각의 선택은 또 하나의 복잡성 계층을 더하고, 비용은 추가 이점보다 빠르게 증가할 것이다.

클라우드 솔루션을 구축하는 데 사용하는 기술을 최대한 저렴하게 구성하자는 말이 아니다. 가장 최적화된 아키텍처란 과학보다는 예술에 가깝다는 것을 알아야 한다. 경우에 따라 더 많은 기술에 투자할 수도 있고 더 적은 기술에 투자할 수도 있다. 중요한 것은 무엇이 가장 최적화된 것인지를 정의하는 것이다.

오늘날 클라우드 최적화는 현재의 클라우드 솔루션을 감사하고 재평가해야 하며, 그리고는 측정 기준이 어떻게 높아지고 있는지를 살펴야 한다는 의미이다. 쉽지 않은 일이지만, 기업이 얻을 수 있는 잠재 가치를 생각해야 한다. 어떤 경우에는 클라우드 최적화가 기업을 살릴 수도 있다.

클라우드 솔루션을 구축해 동작하고 있을 때, “충분히 좋네”라고 말하는 팀은 지혜의 원숭이가 되는 경향이 있다. 배치되어 운영하고 있는 클라우드 솔루션에 대해서는 그 어떤 나쁜 것도 듣지도 보지도 말하지도 않는 것이다. 이와 반대로 누군가 “잠깐만, 비용이 왜 이렇지?”라고 말하는 팀이 있다. 그냥 두면 클라우드 솔루션이 기업의 자원을 필요 이상으로 소진할 것이라는 사실을 안 것이다. 이런 팀은 감사를 제안하거나 고집할 것이다.

자신이 속한 팀은 어떤 팀인지 생각해 보기 바란다. editor@itworld.co.kr

David Linthicum editor@itworld.co.kr
저작권자 한국IDG & ITWorld, 무단 전재 및 재배포 금지
기사가 속한 카테고리는 언론사가 분류합니다.
언론사는 한 기사를 두 개 이상의 카테고리로 분류할 수 있습니다.