Stephen Orban – 클라우드 기반 하이브리드 아키텍처에 대한 세 가지 오해

“인생에서 가장 배우기 어려운  것은건너야 하는 다리와 버려야 하는 다리를 구별하는 것이다.” –David Russell

저는 CIO로서 클라우드 서비스 외에 몇 가지 비즈니스 솔루션 개발을 진두지휘하면서 하이브리드 아키텍처에 대한 견해를 쌓기 시작했습니다. 운이 좋게도, 지난 5개월간 대기업의 CIO를 비롯한 CTO들을 만나 10여 차례 대화를 나누면서 하이브리드 아키텍처에 대한 사고를 더욱 구체화할 수 있었습니다. 그 밖에도 하이브리드 아키텍처에 관한 글이나 블로그들을 많이 읽었지만 클라우드 기반 하이브리드 아키텍처에 대한 업계의 공통된 이해에 석연치 않은 부분들이 있다고 생각합니다.

기업들이 클라우드 기술을 필요로하는 이유는 매우 다양합니다.그 예시로, 클라우드를 도입한 기업들은 대응 능력 강화, 비용 절감 및 글로벌 확장이라는 이점을 경험했습니다.실제로도 다수의 CIO들과 대화를 해보면 대부분 비즈니스 수익성이 없는 일로부터수익성이 있는 일로소중한 자원을 투입할 수 있게 된 것에 대한 얘기로 귀결됩니다.인프라 관리로 인해 겪게 되는 과중한 업무나 브랜드를 대표하는 제품 및 서비스 개발 활동 등이 여기에 해당합니다.

대부분 엔터프라이즈 IT 조직은 오늘날 운영 중인 인프라 및 통합 관리를 오랜 기간 사용해왔습니다. 이러한 인프라를 최대한 빠르게 클라우드로 이전하려고 하는 CIO들과 여러 차례 얘기해 보았는데, 클라우드 도입 여정이 유의미해지려면 오랜 시간이 필요하다는 것을 깨닫게 됩니다. 이러한 여정을 따라 기업은 자사 시스템을 그대로 운영하면서 기존 투자 자산을 최대한 이용할 수 있는 방법을 찾게 됩니다. 저는 엔터프라이즈 클라우드 여정에 관한 게시물에서 기업이 AWS Virtual Private Cloud(VPC) 및 Direct Connect를 사용하여 자체구축 인프라를 AWS까지 확장함으로써 하이브리드 아키텍처를 구현하는 방법에 대해서 얘기하였습니다. 위의 게시물에 언급한 하이브리드 아키텍처가 가장 의미있는 형태라고 생각할 뿐만 아니라 클라우드의 이점을 극대화하기때문에 이러한 단계를 따르고 있는 기업들이 많다고 생각합니다.

하지만 하이브리드에 대해 왜곡된 이야기들이 있습니다. 이 이야기들을 들어보면 처음에는 그럴 듯해 보이지만 자세히 알고나면 더 이상 동의하기 어려운 세 가지 속설이 존재합니다. 이러한 세 가지 오해는 다음과 같습니다.

오해 1: 하이브리드가 마지막 목적지(permanent destination)이다. 마지막(permanenet)이라는 단어는 이 관점을 설명하기에는 지나치게 거창한 단어입니다. 기간계 시스템을 충분히 보유하고 있는 대기업들은 보통은 연 단위로 일정 시간 하이브리드 클라우드 아키텍처를 운영할것입니다. 기업마다 클라우드 여정에 약간씩 차이가 있을것이고 누구나 자신에게 편안한 속도로 진행하려고 할것입니다. 그렇다고 해도 저는 미래에도 여전히 기업들이 자사 데이터 센터를 운영할 것이라 상상하기 어렵습니다. 아마도 3년 뒤에는 그렇겠지만 15년까지는 걸리지 않을 거라 확신합니다. 이렇게 전환 속도가 점차 빨라지는 요인은 다음과 같이 4가지 정도가 있습니다.
1. 클라우드 공급자가 원하는 규모의 경제가 클라우드 도입과 함께 계속해서 성장하고 있습니다. 이러한 이점은 어떤 식으로든 클라우드 소비자들에게도 긍정적인 영향을 미치기 마련입니다.
2. 클라우드 기술에서 비롯되는 혁신의 속도가 유례를 찾아보기 어려울 정도로 빠릅니다. AWS는 2014년에 515건이 넘는 기술 혁신을 선보임으로써 지난 3년간 매년 이룬 혁신의 속도를 거의 2배나 뛰어넘었습니다.
3. 기업이 비즈니스 운영을 위해 의존하는 기술(이메일, 생산성, HR, CRM 등)이 점차 클라우드를 기반으로 개발되고 있습니다.
4. 기업의 클라우드 마이그레이션을 지원하기 위해 존재하는 기술이나 비즈니스의 수가 빠른 속도로 증가하고 있습니다. 자세한 내용은 AWS Marketplace 및 AWS 파트너 네트워크를 참조하십시오.

오해 2: 하이브리드 아키텍처에서는 자체구축 인프라와 클라우드 사이에 애플리케이션을 원활하게 이전할 수 있다. 얼핏 들으면 매력적으로 들릴 수 있지만 이러한 전제에는 근본적으로 결함이 있습니다. 클라우드와 자체구축 인프라가 동일한 기능을 한다는 가정을 전제로 하기 때문입니다. 저는 많은 기업들이 자사의 인프라를 관리할 준비가 잘 되어 있는지 알고 있습니다. 동시에 기업들은 진정한 의미의 탄력성, 보안 강화, 종량 요금제, 끊임없는 혁신 등 데이터 센터에서 지원하지 않는 특징과 기능 때문에 클라우드로 이동하고 있습니다. 하지만 애플리케이션이 데이터 센터와 클라우드 모두에서 원활하게 실행되도록 설계하려면 최소 공통 분모의 기능으로 제한될 수 밖에 없습니다.

오해 3: 하이브리드 아키텍처에서는 다수의 클라우드 공급자 사이에 애플리케이션을 중개할 수 있다. 이 속설에는 사실과 미묘한 차이가 있습니다. 기업들은 자사의 비즈니스 요건에 따라 다양한 클라우드 솔루션을 사용하고 있습니다. 여기에는 일반적으로 서로 혼합된 인프라 서비스를 비롯해 기업의 데이터 센터가 아닌 다른 곳(대부분 AWS 기반)에서 실행되는 패키지 솔루션도 포함됩니다. IT 임원들은 해결하려고 하는 문제를 살펴본 후 제약 조건을 감안하여 가장 적합한 도구를 선택해야 하기 때문입니다.

제가 두려운 것은 바로 기업이 단일 애플리케이션을 다수의 클라우드 공급자 사이에 설계하려는 함정에 빠질 때입니다. 저는 엔지니어들이 이러한 유혹에 빠지는 이유를 잘 알고 있습니다. 그 이유는 바로 서로 다른 클라우드 솔루션이 연동하도록 설계하는 것이 엄청난 업적이기 때문입니다. 아쉽지만 이러한 노력은 기업이클라우드로 전환에 생기는 생산성의 이점을 잠식하고 맙니다. 원점으로 돌아가게되는것이죠. 이제는 기업이 자사의 인프라를 관리하지 않는 대신 여러 공급자 간 미묘한 차이를 관리합니다. 그러다 보니 속설 2와 마찬가지로 기능을 최소 공통 분모로 제한하게 됩니다.

저는 기업이 위와 같은 과정을 따라 가면 클라우드 공급자들이 솔직함을 유지할 뿐만 아니라 단일 공급자에게 종속되는 것을 피할 수 있다고 믿고 있습니다. 한편으로는 중요한 클라우드 공급자 중 한 곳을 잃을 수도 있다는 위험성에 대해서 곰곰이 생각해봤지만 앞으로 클라우드 컴퓨팅 업계의 향방이 가혹한 비즈니스 전술이 될 가능성은 없어 보입니다. 다른 한편으로는 이러한 우려를 완화할 수 있는 좋은 방법이 있다고 생각합니다. 알려진 자동화 기법을 사용해 애플리케이션을 설계하는 기업들은 자사의 환경을 안정적으로 복제할 수 있습니다. 기업이 클라우드의 탄력적 속성을 이용할 수 있는 이유도 이러한 모범 사례에서 찾아볼 수 있으며, 이를 통해 애플리케이션이 인프라에서 분리됩니다.어쩔 수 없이 클라우드 공급자를 바꿔야 하는 경우에도 부담이 줄어듭니다.

기술 선택은 언제나 쉬운 일이 아니며, 종종 실수가 나오기도 합니다. 하지만 하이브리드 아키텍처를 구현할 때는 그럴 필요가 없습니다. 여러분의 생각을 듣고 싶습니다.

– Stephen;
@stephenorban
http://aws.amazon.com/enterprise/

본 블로그 글은 Stephen Orban의 엔터프라이즈 클라우드 여정 시리즈 입니다. 더 자세한 것은 전체 목록을 참고하시기 바랍니다.