Category: Enterprise Strategy*


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의 엔터프라이즈 클라우드 여정 시리즈 입니다. 더 자세한 것은 전체 목록을 참고하시기 바랍니다.

Stephen Orban – 엔터프라이즈 DevOps: DevOps를 수행할 때 기대할 수 있는 것들

“경험은 창조할 수 없으며 다만 겪어야 한다.” – Albert Camus

 

저는 여러분이 속한 조직이 DevOps를 경험한 후 기대할 수 있는 바를 다룬 한 편의 글을 통해 제가 집필한 엔터프라이즈에서의 DevOps 시리즈의 내용을 간략히 정리하고자 합니다. 여기서 소개하는 사례들은 자동화고객 서비스 지향적 IT ‘자산 개발 및 운영(run what you build)’ 정신을 수용하는 조직에서 제가 경험했거나 목격한 것 중 일부에 불과합니다.

DevOps 사례가 서서히 늘어날 것을 기대하라

가치 있는 대부분의 일과 마찬가지로, DevOps의 문화를 구현하는 데는 시간이 걸립니다. 저는 이러한 과정을 거치는 모든 이들에게 처음에는 작은 규모로 신중하게 시작할 것을 권합니다. 여러분이 조직에 가져온 변화를 평가하여 효과가 있는 것은 수용하고, 효과가 없는 것으로부터 얻은 교훈은 다른 구성원들에게 널리 알리십시오. 이렇게 하면 조직이 지속적인 개선 문화를 지향하면서 성장하는 데 도움이 됩니다. 전체 프로세스 중에서 가장 까다로운 부분이 시작되고 있습니다. DevOps 문화가 점점 더 편해질수록 여러분이 속한 조직이 직면하는 고유한 과제들은 분명해져야 하며 그러한 과제들에 대한 해결책은 그리 멀리 있지는 않을 것입니다.

Dow Jones에서 DevOps를 구현할 당시에 우리는 불과 4명의 인원으로 시작했지만 이후에는 매월 다른 IT 분야에 종사한 한두 명의 인원들을 팀원으로 영입하여 팀을 서서히 성장시켰습니다. 이를 통해 우리는 몇 가지 경험과 모범 사례들을 구축하고 DevOps를 적용한 프로젝트의 수만큼 성장할 수 있었습니다. 저는 이보다 훨씬 더 빨리 성장하기 위해 노력하라고 권하고 싶은 생각은 없습니다. 느리지만 견고한 성장을 통해 여러분은 각자가 속한 팀을 포함한 기업의 이해관계자들과 함께 변화의 속도에 대한 현실적인 기대치를 설정할 수 있습니다. 또한 전반적인 비즈니스 이익에 비례하여 자원을 소비할 수도 있는데, 이는 자원 할당을 둘러싼 불필요한 이해관계를 탐색하는 데 도움이 될 수 있습니다.

여정을 시작한 지 대략 18개월이 지났을 때 모범 사례, 자동화 및 거버넌스 모델을 충분히 구축했다고 판단한 후, 우리는 인프라 자원의 대부분을 DevOps 팀으로 무사히 옮겼습니다. 이러한 변화를 통해 우리는 그동안 DevOps 팀이 축적한 경험들을 기반으로 구성원들이 기존에 수행했던 역할을 DevOps 정신에 맞게 조정하도록 유도하는 데 목적을 두었습니다. 사람들은 일하는 방식을 하루 아침에 대대적으로 바꾸지 않았습니다. 하지만 그들은 기업의 모든 시스템을 관리하는 방식을 조금씩 바꾸기 시작했습니다.

DevOps 적용 영역과 방식에 대해 열린 마음을 가져라

DevOps를 구현하고 그 경험을 얻는 데 있어 하나의 정답이란 없습니다. 모든 조직은 저마다 고유하기 때문에 모든 것을 바꿀 필요도, 그럴 이유도 없습니다. 효과가 있는 것과 그렇지 않은 것을 평가할 준비를 하십시오. 여러분의 DevOps 정신 및/또는 팀을 IT의 모든 비즈니스 이익에 연계시킬 방법을 찾으십시오. 업계에서는 DevOps와 혁신의 문화를 제품 개발에 적용하는 방법을 자주 강조하지만, 저는 이러한 사례들을 단지 백오피스, 최종 사용자 컴퓨팅 및 기타 IT 부문에 적용할 수 있는 것으로 간주해 왔습니다. 여러분이 참여하는 프로젝트의 유형에 대해 열린 태도를 취한다면 DevOps팀을 육성하면서 이 팀이 최선의 성과를 낼 수 있는 방법을 이해하는 데 계속 집중할 수 있을 것입니다.

 

© Andrew Hurley https://www.flickr.com/photos/15717926@N04/6254409229/

DevOps의 문화가 성숙하면서 조직에게 가져다주는 이점들을 일부 열거하면 다음과 같습니다.

지속적인 릴리스. DevOps 문화는 비교적 작은 변화들이 더 자주 발생하는 데 도움이 되어야 합니다. 저는 자산 개발 및 운영에 관한 게시물에서 이 점에 대해 거론하고 있는데, 여기서 제가 열거한 몇 가지 이점들은 효율성 증진, 비즈니스 요구에 맞게 조정된 더 많은 리소스 , 운영 우수성 향상 등으로 요약할 수 있습니다. 이 모든 이점들은 결국 여러분의 (내부 및 외부) 고객에게 더 나은 경험을 제공하는 셈이 됩니다. 이러한 일이 발생할 때 비즈니스 이해관계자들이 가진 기대치를 관리할 준비를 해야 하며, 다만 그들보다 너무 앞서 가지는 마십시오. 이해관계자들은 끊임없이 변화하는 제품이나 환경을 하나의 위험으로 간주할 수 있다는 사실에 유의해야 합니다. 여러분이 이러한 일을 책임감 있게 수행하기 위해 필요한 메커니즘들을 구축하고 검증하려면 그만큼의 시간과 성숙이 요구됩니다. 신뢰를 쌓는 것은 필수이며, 뭔가 새로운 일을 수행하기 위해 신뢰를 쌓기까지는 시간이 걸리기 마련입니다. 결승선을 혼자만 통과하는 것은 영예로운 일이 아닙니다.

전 세계적으로 분산된 앱. 표준 시간대별로 비즈니스를 수행함에 따라 전 세계 여러 지역에서 하나의 애플리케이션이 확대 및 축소되는 것을 지켜보는 일은 IT 임원으로서 제가 경험한 가장 보람 있는 경험들 중 하나에 속합니다. 여러분의 DevOps 팀은 여러 지역에 걸쳐 자원 집합을 자동화하고 관리하는 방법을 잘 알고 있기 때문에 기업의 애플리케이션을 전 세계에 배포하는 일은 더욱 수월해질 것입니다. 고객에게 좀 더 밀착된 서비스를 제공한다면 지연 시간을 줄이고 시스템의 효율성과 비용 대비 효과를 증진하는 것은 물론, 고객의 만족도를 높이게 될 것입니다. 여러분의 DevOps 숙련도가 향상될수록 전 세계에 기업의 애플리케이션을 배포하는 일은 점점 더 쉬워질 것입니다.

데이터 센터 마이그레이션. IT 부서가 하는 모든 일은 비즈니스 중심으로 진행되어야 합니다. IT임원이 기존IT계획을 실제 비스니스 사례로 전환할 수 있을 때 단순한 IT 임원이 아닌 IT 비즈니스를 감독하는 임원으로 자리매김하게 됩니다. 자동화 및 전 세계에 걸쳐 분산된 애플리케이션들의 인벤토리를 사용하면 기업의 데이터 센터를 일부분 또는 전부 클라우드로 마이그레이션할 강력한 비즈니스 사례를 개발할 수 있습니다. 저는 지난 한 해 동안 이러한 현상이 점점 더 자주 발생하는 것을 목격하고 있습니다.

저는 Dow Jones에서 DevOps 팀을 운영한 지 약 10개월 만에 이러한 현상을 경험했습니다. 우리는 불과 몇 개월 후면 폐쇄될 예정인 홍콩의 한 데이터 센터를 임대하고 있었습니다. 따라서 우리가 보유한 인프라를 호스팅할 또 다른 장소를 급히 찾아야 했습니다. 우리가 축적한 DevOps 사례와 클라우드 전문 지식을 통해 충분히 강력한 추진력을 갖고 있었다고 판단했기에 여기서 일보 후퇴하여 또 다른 데이터 센터 계약에 종속된다면 오히려 부끄러운 일이 될 것으로 생각했습니다.

초기에 약간의 반발이 있긴 했지만 담당 팀은 감지된 모든 장애물을 우회하여 설계할 수 있는 방법을 찾아냈으며 전체 데이터 센터를 AWS로 마이그레이션하는 작업을 6주 만에 완료했습니다. 이 특정 배포는 마이그레이션을 완료한 당시에 비해 지금은 외견상 많이 달라졌지만 시간이 경과함에 따라 전문 지식을 구축하고 기대치를 관리하는 과정에서 발생하는 일들을 보여주는 훌륭한 증거라고 생각합니다. 마이그레이션에 도달하는 과정에서 축적한 경험이 없었다면 마이그레이션을 구현할만한 방법도 없는 셈이 됩니다.

함께 나누고 싶은 여러분만의 사례들이 있습니까? 여러분의 사례들을 꼭 듣고 싶습니다.

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

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

Stephen Orban – 엔터프라이즈 DevOps: DevOps를운영해야 하는 이유

“직접 만들고 실행하라.” -Werner Vogels

 

다음 예시는 아주 흔한 시나리오입니다.. 가족과 시간을 보내고 있는데 갑자기 전화가 울려 정신이 팔립니다. 걱정되었던 SEV1 오류가 결국 발생했다는 연락입니다. 당신의 애플리케이션은 재시작을 할때  작동을 “수정”하는 메모리 누수가 주기적으로 발생하는데, 이제는 몇 분 내에 온라인 서버 리소스가 고갈됩니다. 그래서 애플리케이션을 사실상 사용할 수 없게 됩니다. 운영 팀은 다시 시작하거나 롤백하는 것 외에는 방법이 별로 없고 가장 최신 백업본은 몇 달 전의 것입니다. 그 이후에는 무엇이 바뀌었는지 아무도 모릅니다. 누수 문제를 해결해야 하는데 사무실과 컴퓨터는 몇 마일 떨어진 곳에 있습니다.

이와 같은 상황은 기존 엔터프라이즈 IT 모델에는 너무나 일반적인 문제입니다. 이 모델에서는 개발과 운영을 따로 하게 됩니다.. 하지만 이제 그렇지 않아도 됩니다. DevOps는 스타트업에만 적용되는 것이 아닙니다. 엔터프라이즈에서도 사용할 수 있습니다. 자동화고객 서비스와 마찬가지로 “어플리케이션 개발 및 운영”이 DevOps 모델을 통한 엔터프라이즈 IT 발전을 위한 효율적인 원칙이 될 수 있습니다.

기존 모델은 개발자가 솔루션을 설계하여 운영팀에 인계합니다. 가끔 프로덕션 문제를 처리하는 방법에 대한 몇 가지 지침을 제공하기도 하지만 운영팀은 해당 프로덕션 환경 운영에 대한 지식이 없는 경우가 대부분입니다. 이렇게 2개의 분리된 팀을 유지하면 각 팀은 서로 작업하는 방식과 요구사항에 대한 정보가 거의 없게 됩니다. 많은 경우, 운영 팀에는 상세 실행서, 표준 운영 절차(SOP) 또는 몇 가지 다른 프로덕션 문제 처리 메커니즘이 있기는 합니다. 빠른 해결책이 필요한 경우에는 상당히 효율적이지만, 근본적인 원인을 확인하고 처리하지 않으면 껌으로 배의 구멍을 막는 것과 마찬가지입니다. 결국 배가 가라앉는 것이죠.

© Richie Diesterheft https://www.flickr.com/photos/puroticorico/534078144/

 

DevOps가 더 나은 솔루션을 제공합니다.
클라우드는 이러한 벽을 허무는 데 도움이 되었습니다. 클라우드를 통해 인프라를 소프트웨어와 비슷하게 만들 수 있기 때문입니다. 개별자라면 누구나 이해하겠지만, API 중심 업무의 특징을 통해 인프라를 코드와 비슷하게 취급할 수 있습니다. 모두가 인프라에 훨씬 가깝게 접근할 수 있기 때문에 운영 자체가 자연스럽게 핵심 요구 사항이 될 것입니다.

한편 소프트웨어가 서비스로 판매되면서 고객은 당연히 지속적인 개선을 요구하게 됩니다. 여기저기에서 나타나는 실수는 용인할 수 있지만 그러한 실수를 즉시 처리하고 계속 발생하는 일이 없도록 해야 합니다. 이러한 변화에 발을 맞추려면 고객이 분명하게 전달하지 않았더라도 실마리와 통찰력을 얻기 위해 노력해야 합니다. 고객도 우리처럼 다른 일로 바쁘기 때문에 우리에게 피드백을 주기 위해 연락했을 때는 좋은 내용이 아닐 가능성이 높습니다. 모든 고객과의 상호 작용은 새로운 것을 배울 기회가 되지만, 여러분은 자신의 방법으로 진행하는 것이 더 나을 수 있습니다. 그러나 개발과 운영 사이에 벽이 있다면 이러한 통찰력을 얻기 훨씬 더 어렵습니다. 운영 팀은 신속한 수정을 통해 문제를 감추려할 수 있고, 개발자는 안전망을 과도하게 가지고 있다면 운영 효율성에 대한 기준치를 낮출 것입니다.

이 모든 것은 기존 IT 모델을 벗어나 개발과 운영이 하나의 팀으로 협력하는 DevOps 문화를 지향해야 할 충분한 이유가 됩니다. 저는 임원들이 DevOps 중심의 조직에서 “자산 개발 및 운영”을 중요한 원칙으로 삼을 것을 권장하고자 합니다. 경험상 조직들은 다음과 같은 몇 가지 이점과 행동을 발견하게 됩니다.

·         프로덕션의 설계. DevOps를 사용하면 개발 팀이 소프트웨어를 설계함과 동시에 프로덕션에서 어떻게 실행될 것인지 생각하게 됩니다. 이를 통해 팀은 프로덕션 환경에 적용하는 데에 있어서, 데드라인을 맞추기 위해 발생하는 마지막 혼란을 피할 수 있습니다. 이런 일로 인해 실제로 품질에 악영향을 준 경우를 저는 수도 없이 봐왔습니다. 배포 시점에 프로덕션과 개발의 차이를 처리하기 위해 급하게 뭔가를 바꾸고 배포 전 베타 테스트를 실행했는데 급하게 수정한 것으로 인해 시스템의 다른 부분에 버그가 생긴 것을 발견하기도 합니다.

·         직원 자율성 향상. 자산 개발 및 운영이라는 정신은 주인 의식과 책임을 장려합니다. 경험에 비추어 보면 이 두 가지가 있을 때 직원은 더욱 독립적으로 일하고 책임감을 느끼게 되며 조직에서 균등하게 경력 성장을 할 수 있게 됩니다. 이에 대한 내용은 이전 게시물에서 볼 수 있습니다.

·         투명성 향상. 개인의 시간을 방해받고 싶은 사람은 없습니다. 고객에게서 문제가 생겼다는 전화를 받는 사람은 애초에 이런 문제가 발생하지 않도록 최선을 다할 것입니다. 팀은 당연히 환경의 투명성을 높히고 사전 모니터링을 구현하여 이를 통해 문제와 오류 패턴이 널리 퍼지기 전에 확인하고자 할 것입니다. 문제가 발생하기 전에 철저히 관리하는 것 외에도, 환경의 투명성을 확보한다면 잘 해결되지 않는 문제의 근본 원인을 더 쉽게 확인할 수 있습니다.

·         자동화 향상. 개발자들은 수작업을 반복하는 것을 싫어하기 때문에, 프로덕션에서 문제 해결을 위해 수동 작업을 발견하게 되면 근본적 원인을 찾아내고 그 과정에서 자동화하게 될 것입니다.

·         운영 품질 향상. 투명성 및 자동화는 팀의 효율성을 높여주고 운영 우수성을 계속 개선시킬 것입니다.

·         고객 만족도 개선. 자산 개발 및 운영을 통해 IT 팀은 고객을 더 잘 이해할 수 있습니다. 그러한 지식은 더 이상 제품이나 영업 팀으로 국한되지 않을 것이고, 이러한 통찰력이  피드백으로 사용될 경우, 지속적인 제품 개선을 위해 유용하게 사용됩니다.

다른 이점이 있다면 알려주세요. 여러분의 생각을 들어보고 싶습니다. 꼭 보내주세요!

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

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

Stephen Orban – 고객 서비스가 엔터프라이즈 DevOps의 핵심인 두 가지 이유

“고객은 그들을 향한 우리의 관심이 느껴질 때 우리의 지식에 관심을 갖게 된다.” -Damon Richards

 

고객 서비스는 DevOps 시리즈 소개에서 간략히 언급한 것처럼, DevOps 문화를 구현할 때 조직에게권하는 세 가지 원칙 중 하나입니다.

오늘날의 세상은 기술 솔루션으로 가득하고, 어떠한 요구에도 대응가능한 다양한 옵션들이 마련되어 있습니다.기술 솔루션을 제공하는 사람으로서 비즈니스 성공이란 훌륭한 제품을 제공하는 것뿐만 아니라 뛰어난 고객 서비스를 제공하는 것을 의미합니다. 고객 서비스가 좋을수록 고객이 경쟁업체의 솔루션을 찾게 될 가능성이 줄어들게 될 것입니다.

기존의 전통적인 사고방식에서 고객이란 Amazon.com의 구매자나 AWS를 사용하는 기업들 같이 여러분의 제품과 서비스를 구매하는 사람들을 의미했습니다.

그러나 엔터프라이즈 IT에서 고객이란 협력하는 사람을 의미하는 경우가 많습니다. 다양한 기술을 통해 자신의 업무를 처리해내는 사람이라면 누구나 내부 이해관계자가 될 수 있습니다. 다른 부서(마케팅, 영업 등)나 때로는 다른 기술자가 여기에 해당될 수 있습니다.

내부 DevOps 조직의 제품 및 서비스를 소비하는 사람은 누구일까요? 물론 이 질문에 대한 대답은 때에 따라 다를 수 있지만 많은 경우 애플리케이션 개발자 및 회사 내에 있는 타 기술 팀을 의미합니다. 왜냐하면 중앙 집중식 DevOps를 도입하게 되는 큰 이유중 하나가 제품 개발 시간을 단축할 수 있다는 것이기 때문입니다. 여러 부서 간에 공동 작업을 수행하고 의견을 공유하는 중앙 집중식 팀은 독자적으로 과제에 대해 고민하는 팀보다는 훨씬 요구 사항을 잘 예측하고 더 나은 고객 서비스를 제공할 수 있을 것입니다.

고객 서비스를 조직의 최우선으로 두어야 할 두 가지 이유는 다음과 같습니다.

1. 고객 서비스 중심 방침은 IT 브랜드를 발전시킨다

20년 전에는 엔터프라이즈 기술 요구 사항에 대해 IT를 통해서만 서비스를 제공했습니다. 기술은 복잡한 것으로 인식되어 기술을 잘 사용하려면 엄청난 전문 지식이 필요한 것이라고 생각하기도 했습니다. 팀 전체가 구축한 것을 직접 실행할 수 있는 DevOps와는 달리, 기존의 조직은 IT를 구매하고 배포하는 방법을 이해하는 소수의 사람들에게 이를 집중해야 한다는 편견을 가지고 있었습니다. 이로 인해 IT의 고객들, 즉 조직의 나머지 팀들은 IT 관련 요구 사항을 충족할 수 있는 방법이 제한되었습니다.

하지만 지금은 고객의 문제를 해결해주는 제품과 솔루션이 너무나 많습니다. 그리고 기술은 지속적으로  상용화되고 있습니다. 이전에 비해 컴퓨터, 스마트폰, 웹 사이트, 앱을 사용하는 사람들이 늘어났고 가정과 직장에서 누리는 선택의 폭이 넓어졌습니다. 이러한 추세로 인해 기술 선도업체들이 고객 서비스를 바라보는 방식, 특히 조직 내부에서 보는 방식이 바뀌고 있습니다.

경험상 누구나 작업을 실행하는 더 쉬운 방법을 찾게 되면 그 방법을 사용할 가능성이 높습니다. 만약 IT에서 필요한 서비스를 얻지 못하면 다른 곳에서 그 서비스를 찾으려고 할 것입니다. IT가 자체 버전을 원하는 만큼 빠르게 제공하지 않거나 못하면 뉴스룸에서는 편집 소프트웨어를 스스로 다운로드할지 모릅니다. HR에서는 내부 캘린더 시스템 외에 다른 스케줄링 툴을 찾아다닐지 모릅니다. 마케팅은 타사에서 브랜드 웹 사이트를 다시 제작할 수도 있습니다. 업계는 이것을 “Shadow IT”라고 합니다. 이 때문에 대규모 IT 환경을 효율적으로 관리하고 안정적으로 운영하기가 훨씬 어려워질 수 있습니다. 현실에서는 내부 이해관계자가 IT를 통해 원하는 것을 얻는 방법을 모르거나 전달받는 사항에 만족하지 못하기 때문에 “Shadow IT”가 존재합니다.

고객 서비스 중심 방침을 유지하는 중앙 집중식 DevOps 조직은 이러한 시나리오를 피할 수 있을 가능성이 높습니다. 처음부터 고객을 염두에 둔다면 고객의 요구 사항과 우려 사항에 공감하고 요구 사항에 대한 솔루션이 회사 전체에 얼마나 잘 부합하는지 확인할 수 있을 것입니다. “그걸 작업에 쓰면 안 됩니다”라고 말하는 대신 “어떤일을 하려고 하고 어떻게 하면 제가 효율적으로 도와드릴 수 있을까요? ” 라고 질문하는 것이 좋습니다. 애플리케이션 팀이 DevOps 팀이 제공할 수 없는 것에 대한 차선책을 구현할 때마다 조직은 그런 일이 발생한 경위와 원인을 알아내고 앞으로 어떻게 개선할 것인지 결정할 기회가 생기는 것입니다. 앞으로 차선책을 덜 필요로 하게 만드는 방법이 있을까요? 아마도 그 답은 “없다”일 것입니다. 많은 경우 차선책을 받아들여도 괜찮지만 조직에게 문제에 의도적으로 접근해볼것을 권합니다. 이를 통해 IT는 마찰이 아닌조력자로 작용할수 있습니다. 이것이 고객을 여러분과 함께 협력하게 만드는 유도책이 될것입니다.

2. 고객 서비스 중심 방침은 경력에도 도움이 된다

애플리케이션 팀이 구축한 것을 직접 실행하는 DevOps 모델에서는 오너십과 고객 서비스가 연장선상에  있습니다. 제가 그동안 근무했던 모든 회사에서는 오너십을 핵심 성능 지표로 사용했었습니다. 오너십은  Bloomberg의 핵심 가치 중 하나였고, Dow Jones의 IT의 핵심 가치였으며 Amazon의 리더십 원칙 중 하나입니다.

오너십이란 모든 제품 또는 서비스 담당자는 제품이나 서비스를 자신의 비즈니스처럼 다루어야 한다는 것을 의미합니다. 제품과 서비스는 웹 사이트, 모바일 애플리케이션, 회사 이메일 서비스, 데스크톱 지원, 보안 도구, CMS 또는 고객에게 제공하는 그 무엇이 될 수 있고, 다양한 형태를 취할 수 있습니다.

오너십은 제품을 감독하는 담당자에게 직접 책임과 평판을 부여하기 때문에 고객 서비스를 개선하게 됩니다. 그러면 이 담당자는 다른 사람의 의견을 듣고, 고객의 대안을 파악하고 제품의 성능에 대해 지속적으로 관심을 가질 동기가 생기게 됩니다. 제품 책임자는 문제가 발생할 때 그저 “책임을 전가”할 수 없기 때문입니다. 이들은 결단력을 통해 문제를 식별하고 필요할 때 도움을 받을 책임이 있습니다.

이 부분에서 개인의 경력에도 도움을 받게 됩니다. 제품에 대해 적극적으로 주인 의식을 가지고 고객과 건전한 관계를 쌓는 사람은 회사와 관련하여 안정성과 신뢰성이라는 평판을 얻게 됩니다.

지금까지 말씀드린 내용은 고객 서비스가 매우 중요한 크고 복잡한 조직 내부에서, 특히 DevOps를 고려할 때 고객 서비스가 중요한 이유 중 두 가지일 뿐입니다.여러분이 다른 이유들을 알게된다면 들려주십시오.

-Stephen
@stephenorban
http://aws.amazon.com/enterprise/

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

Stephen Orban – 엔터프라이즈의 DevOps 문화

“개발은 점진적 개선을 수반하는 인내심 훈련이다.”
-Sri Mulyani Indrawati

 

DevOps는 오랜 시간 회자되고 있는 그 개념에 비해 비교적 최근에 새롭게 만들어진 용어입니다. 현재 일부에서는, 이전에 사일로 현상을 겪었던 팀들의 융합 지점이 되어 더욱 빈번하게 신속하고 안정적인 결과를 도출할 수 있는 기업문화로 받아들여지고 있습니다.

이 용어가 대세가 되기 전부터DevOps 문화 속에서 일을 시작할 수 있었던 것은 저에게 큰 행운이었습니다. 2001년 Bloomberg에서 개발자로 첫 발을 내디뎠을 때 이 회사는 이미 출시 시간을 앞당기기 위한 부단한 노력과 반복적 개발 주기, 그리고 자신이 개발한 시스템의 지속적인 운영까지 책임지는 개발자들로 잘 알려져 있었습니다. 그래서 새로운 개발자들이 새벽 4시(런던 증권 거래소 개장 시간)에 시스템 문제를 해결하는 것이 어떠한 일인지 배우는 데 오랜 시간이 걸리지 않았습니다. 저는 밤늦게 작업하는 이러한 경험이 시스템을 더욱 견고하게 개발해야 한다는 강력한 동기로 작용한다는 것을 깨달았습니다..

DevOps는 소규모 기업일수록 비교적 쉽게 접근할 수 있기 때문에 직관적으로 스타트업에게 명백해 보일 수 있습니다. 하지만 조직 규모가 커질수록 상당한 기술 부채와 모놀리식 아키텍처, 그리고 위험을 기피하는 비즈니스 관행으로 인해 이러한 업무는 감히 엄두도 내기 어렵습니다.

© Will Fisher https://www.flickr.com/photos/fireatwillrva/6541738007/

하지만 이제 그럴 필요가 없습니다. 앞으로 몇 주간 엔터프라이즈 의 DevOps 구현을 위한 구체적인 영역 및 전략에 대해서 이야기하려고 합니다. DevOps 문화로 전환하고 싶은 기업이 있다면 저는 작은 프로젝트부터 시작하여 반복, 학습 및 개선을 이루어가는 DevOps 방식으로 시작해보라고 이야기합니다. 다시 말해, 먼저 기업 전체에서 공통적으로 허용되는 업무 전략의 구현 방안에 대해서 고찰한 후 이러한 업무가 자동화되고 나면 운영 업무가 탈중앙화되고 여러 부서들이 자신이 구축한 시스템을 스스로 운영할 수 있다는 생각을 포용하도록 장려합니다.

Dow Jones에서 CIO로 재직할 당시에는 소규모 팀을 중심으로 DevOps 업무를 처리하였습니다. 4~5명의 인원으로도 몇 가지 프로젝트를 충분히 처리할 수 있었으니까요. 또한 우리의 목표는 새로운 팀을 구성하는 것이 아니라 회사의 문화를 바꾸는 데 일조하는 것이었습니다. DevOps는 프레임워크, 모범 사례 및 통합 관리를 구현 및 창안하고, 이 모든 것을 자동화함으로써 앞으로의 혁신을 견인하고 제품 개발을 가속화하는 주요 수단이 되었습니다. 우리는 작은 프로젝트부터 시작하였고, 그 결과를 통해 동일한 모델로도 점차 늘어나는 프로젝트들을 얼마나 성공적으로 실행할 수 있는지 보여주었습니다. 느리지만 확실하게, 우리는 더욱 다양한 기능을 개발하기 시작했고,제품 출시 기간을 앞당겼습니다. 이전에는 화요일과 목요일 야간에 제품을 출시하면서 종종 일이 잘못되는 경우도 있었지만 이제는 개발자들이 매주 수십 가지의 변경 사항을 발표하기에 이르렀습니다.

DevOps를 고려하는 동시에 기술 부채까지 처리해야 하는 기업이라면 다음과 같이 세 가지 원칙부터 시작하는 것이 좋습니다.

1. 전사적인 수준에서 고객 서비스에 중점을 두십시오. 오늘날 기업들은 내부 관계자들까지 고객으로 생각해야 합니다. 마케팅 부서 직원, 제품 관리자 또는 개발자 등 어느 누구든지 고객이 될 수 있습니다. 개인이나 그룹 모두 기술 없이는 자신의 업무를 처리하기 어렵습니다. 이러한 기술적 요건을 최우선으로 생각하는 팀들은 고객이 다른 솔루션(섀도우 IT)을 찾아 헤매지 않도록 지원하여 더 나은 결과를 더욱 신속하고 저렴한 비용으로 제공할 뿐만 아니라 고객 만족도까지 높일 수 있습니다. 우수한 서비스의 부재는 고객이 기업과 함께 하기 보다는 오히려 피하게 만들 뿐입니다.

2. 모든 것을 자동화하십시오. 오늘날 클라우드를 최대한 활용하기 위해서는 코드를 사용해 시스템을 안정적으로 복제할 수 있어야 한다고 널리 알려져 있습니다. 특히 Auto Scaling(탄력성)에서는 더욱 그렇습니다. 그 밖에도, 자동화는기업이 변화를 추구하는 데 더욱 적극적인 움직임을 취할 수 있도록 도와줍니다. 예를 들어, 혹시 실수가 있더라도 신속히 예전 상태로 돌아갈 수 있습니다. 그 외에도 효율성, 보안 및 감사 능력의 향상 역시 빼놓을 수 없는 이점입니다. (자세한 내용은 자동화에 대한 이전 게시물을 참조하십시오.)

3. 개발한 자산을 직접 운영하십시오. 이 문제와 관련하여 기존 IT 부서들이 고민하는 모습을 종종 보게 됩니다. 기존 IT 모델에서는 자산 개발에 참여하지 않은 사람들이 애플리케이션 또는 서비스를 관리하는 경우가 종종 있습니다. 과거에는 저렴한 인력 비용, 전문 기술의 중앙화 등 많은 이유가 있었지만 현 시점에서 이러한 이유들은 사라지고 있습니다. 이제 클라우드 기술이 IT 운영에서 발생하는 대부분의 어려운 일들을 처리할 뿐만 아니라, 소프트웨어를 사용해 대부분 작업을 자동화할 수 있기 때문입니다. 개발자들은 소프트웨어에 매우 익숙하고, 따라서 굳이 운영 업무를 따로 분리할 이유가 없습니다. 결국 DevOps라는 용어도 바로 여기에서 시작되는 셈입니다. 개발자들은 시스템의 미묘한 차이를 가장 정확하게 알 수 있는 사람들이기 때문에, 문제를 해결하는 속도도 가장 빠를 가능성이 높습니다. 또한 자동화를 통해, 변경 사항을 체계적으로 전파하거나 변경 이전으로 되돌리는 것이 쉬울 뿐만 아니라 고객에게 영향을 미치기 전에 문제를 해결할 수 있습니다. 중앙 집중된 DevOps팀들은 각 개발 팀이 점차적으로 독립성을 키울 수 있도록 지원하고, 지속적인 운영/출시 업무에서 DevOps팀이 주요 경로(critical path)가 되지 않도록 해야합니다.

조금이라도 관심이 있는 기업이라면 지금이야 말로 좋은 타이밍입니다. 작게 시작하여 점차 개선되는 모습에 만족감을 느껴보세요. 문화적 변화는 하루 아침에 일어나지 않습니다. 서서히 포트폴리오에 이러한 개념을 적용하기 시작하면 새로운 업무 방식과 이전 업무 방식 모두 개선될 수 있을 것입니다. 경험이 쌓여갈수록 학습한 내용을 다음 학습에 활용하고,  점차 늘어나는 자동화 인벤토리를 이용함으로써 더 나은 결과를 보게 될 것입니다.

다음 게시물에서는 고객 서비스 중심의 IT 조직이란 무엇을 의미하는지 자세하게 알아보겠습니다.

여러분의 DevOps 경험은 무엇입니까? 있다면 꼭 듣고 싶습니다!

-Stephen
@stephenorban
http://aws.amazon.com/enterprise/

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

Stephen Orban – 클라우드 관리형 서비스의 미래

“어제의 방법으로 오늘의 업무를 하면서 내일의 비즈니스를 꿈꿀 수 없다.” -George W Bush

 

지난 2월, 저는 클라우드를 통한 기업의 비즈니스 전환을 돕는 데 파트너 생태계의 역할이 어떻게 진화하고 있는지에 대해 논의를 시작하였습니다. 지난 글에서 설명한 바와 같이, 클라우드를 둘러싼 생태계는 빠르게 성장 및 변화하고 있으며, 저와 대화를 나누는 대부분의 임원들은 기술이 기업에 가져오는 가치를 가속화하기 위해 누구와 무엇을 위해 파트너십을 맺을 지 (재)고려중이었습니다.

IT관리형 서비스는 클라우드 서비스의 인기가 높아짐에 따라 지난 몇 년간 상당한 변화를 겪은 분야 중 하나입니다. 이 분야는 관리형 서비스 제공업체 (Managed Service Provider – MSPs)라 불리는 업체들에 의해 서비스 되며, 이러한 MSP들의 역할과 사업 모델은 빠른 속도로 진화하고 있습니다. 본 글은 이러한 변화를 감안하여 고려해 볼만한 것들을 탐색합니다.

“일 떠넘기기”만으로는 충분하지 않다

전통적으로, MSP는 안정화 상태의 IT운영 업무를 더 저렴한 가격에 아웃소싱 하려는 기업들에게 매력적인 대안입니다. 비용을 절감하려는 기업들에게 그저 “일을 떠넘기는” 것은 그것대로 가치가 있을 수 있지만, MSP의 운영방식이 기업의 IT전략은 물론 시장의 방향성과도 일치하는지 주의해야 합니다.

MSP는 일반 기업과 같은 이유로 클라우드 서비스에 매력을 느낍니다. 클라우드 서비스를 통해 MSP는 일반적으로 데이터 센터 운영과 보편적인 IT서비스 운영이 수반되는, 차별화되지도 않고 귀찮기만 한 일을 하는 대신에 그들의 자원을 고객(여러분)에게 더욱 집중할 수 있도록 해 줍니다. 이를 알아차린 몇 MSP들은 – 예를 들어 Logicworks, Cloudreach, Accenture, 2nd Watch, REAN Cloud, Cascadeo, Mobiquity 같은 기업들 – 그들의 운영 방식을 간소화하고, 부가가치 서비스에 좀 더 집중하고, 그들 스스로의 원가구조를 최적화 할 수 있습니다. 이는 결과적으로 차세대 MSP에게는 유리한 판매수익을, 고객에게는 저렴한 비용을 가져다 줍니다.

MSP들에게서 발견한 또 하나의 트렌드는, 클라우드 마이그레이션에 대한 그들의 전문성을 클라우드 혜택을 얻는 기업들이 친숙한 “as-a-service (서비스로서의)” 모델과 결합하는 것입니다.

이 새로운 방식에 따르면, MSP는 기업의 기존 시스템을 클라우드로 이전하는 것에 합의하고 시스템 관리에 대한 모든 소유권을 가지며 서비스로서의 (as-a-service) 업무 기능을 다시 여러분(고객)에게 판매합니다. 인프라를 관리하지 않고도 ERP시스템에 대한 업무 절차를 유지하고, 업무 절차 변경에 대한 예측 가능한 비용 모델을 갖는 것을 상상해 보십시오. 이 새로운 모델은 변경관리를 위해 정교한 ITSM (IT Service Management) 절차를 만들 필요성이나 이런 절차에 필요한 (때때로 놀라울 정도의) 가격 요율표를 없애줍니다. 저는 과거에 확실히 MSP가 저렴하다고 생각했지만, 최근에 한 임원에게서 MSP가 AWS 환경에 VPC를 구축하는 데 – 몇 분 만에 가능하고 비용도 거의 제로에 가까운 절차임에도 – $10,000 을 청구하려 했다는 이야기를 들었습니다. 저는 이렇게 새로운 가치제안을 전달하는 방법을 AWS and Accenture 파트너십팀을 통해 구축하려 했으며, 앞으로 몇 달 간 해당 방법에 대해 여러분에게 소개하고자 합니다.

데브옵스(DevOps)로서의 MSP 역할

지난 글에서 저는 많은 기업이 기업 문화를 발달시키는 데 도움을 줄 파트너를 찾고 있다고 말했습니다. 저는 또한 데브옵스(DevOps) 시리즈를 통해 왜 기업들이 점점 더 데브옵스(DevOps)에 끌리는지, 이를 수용하기 위해 조직의 구조적 변화에 대한 방향성을 어떻게 정해야 하는지 설명했습니다. 몇몇 MSP는 이 의견들을 종합해서 기업의 안정화 단계의 시스템 운영을 돕는 것과 동시에 데브옵스를 활용해서 실험문화를 조성하는 데 도움을 주고 있습니다.

AWS는 MSP에게 대규모 클라우드 운영 모범 사례들을 여러 개 제공하고, 이를 구축하려는 MSP에 대해 주기적으로 제3자 감사를 진행하는 AWS and Accenture 파트너십을 구축하였습니다. AWS 관리형 서비스 프로그램 감사를 통과한 파트너들을 찾아보면, 적절한 클라우드 전문성을 갖고 여러분만의 클라우드 운영 모델을 개발하는 데 도움을 줄 수 있는 파트너를 만났다는 확신을 얻을 수 있을 것입니다.

AWS 관리형 서비스 프로그램과 더불어, AWS 데브옵스 컴피턴시(DevOps Competency)를 달성한 파트너와 협업한다면 AWS가 제공하는 지속적인 통합, 자동화 및 데브옵스 중심의 도구를 어떻게 실행해야 하는지 아는 파트너를 만났다는 확신을 얻을 수 있을 것입니다.

이러한 핵심능력의 결합이 여러분의 조직에 필요하다면, 양 쪽 능력을 두루 갖춘 MSP 리스트를 참고하십시오. 2nd Watch, Cascadeo, Cloudreach, REAN Cloud, Smartronix, Rackspace, Logicworks 입니다.

둘 중 어떤 역량도 가지고 있지 않은 파트너와 협업 중이지만 이러한 역량이 필요하다고 생각하신다면, 파트너사가 이러한 프로그램을 고려해 볼 수 있도록 권고하십시오. 그리고 저에게도 알려주십시오. 또한, 앞으로 몇 년 간 MSP가 어떤 방향으로 변화해야 할 지, 혹은 어떻게 변화할 지에 대한 여러분의 예상이나 기대도 꼭 듣고 싶습니다!

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

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

Stephen Orban – 엔터프라이즈의 클라우드 전환

“이론적으로는 이론과 실제 사이에 차이가 없다고 하지만, 실제로는 있다.” – Yogi Berra

 

© Les Chatfield https://www.flickr.com/photos/elsie

이전 게시물에서 클라우드 혁신 센터(CCoE)를 소개했을 때 저는 CCoE가 클라우드 여정에서 기타 모든 모범 사례들을 엮은 결과물이 되어야 한다고 언급했습니다. CCoE 시리즈의 마무리를 지을 이 글에서 저는  CCoE가 클라우드 여정을 통해 어떤 혜택을 누리고 있는지 혹은 그러한 여정에서 그 밖의 모범 사례들을 어떻게 추진하는지에 대한 몇 가지 견해들을 제시하고자 합니다.

경영 지원

강력한 리더십을 통해 추진하지 않는 한, CCoE가 성공하기는 어렵습니다. 임원들과 CCoE 설립에 관하여 이야기할 때마다 저는 그들에게 적극적 실천을 권합니다. 그 실천이란 팀에 가장 적합한 사람들을 구분하고, 그들을 대체할 인력 없이 다른 업무로 전환시키고, 업무 책임을 CCoE에 맡김에 따라 공석이 문제가 되지 않도록 하는 것입니다.

반면, 보고 라인은 중요합니다. CCoE를 인프라 중심 조직에 배치하는 것은 좋지만 클라우드가 내포할 수 있는 의미에 대해 해당 조직의 리더들이 염려하지 않도록 주의해야 합니다. 클라우드 기능을 확장하고 클라우드 기반 솔루션으로 전환할 수록 CCoE가 인프라 팀의 지배적인 부분이 될 가능성이 높습니다다. 이를 위해서는 강력한 리더십과 전폭적인 지원은 물론, 반복적인 학습을 통해 자원을 해당 팀으로 실어주는 의지가 필요합니다.

직원 교육

CCoE는 해당 조직에게 클라우드 사용 방법에 관한 교육을 이끌어 나가야 하며 비즈니스를 지원하기 위해 사용되는 모범 사례, 거버넌스 및 프레임워크를 전파하는 역할도 담당해야 합니다.  여러분은 클라우드를 사용하여 성공하는 데 필요한 인력을 이미 보유하고 있으며 CCoE가 그들의 결정적인 서포터가 되어야 합니다. CCoE가 AWS 교육 및 자격증을 최대한 활용하고 이를 조직별 콘텐츠에 녹여 교육 제공의 범위를 조직의 나머지 구성원들에게까지 확대할 수 있는 방법을 고려해보십시오. 제가 Dow Jones에서 일하던 시절에 회사의 DevOps 팀은 더 많은 것을 배우고 싶어하는 모든 직원을 대상으로 매년 “DevOps 데이(DevOps Days)” 행사를 여러 번 열었습니다. 업계의 다른 업체들도 이러한 행사를 열고 있습니다. Capital One의 클라우드 엔지니어링 기술 이사인 Drew Firment는 Capital One의 모든 조직에 걸쳐 클라우드 전문 지식을 전파하는 놀라운 CCoE 교육 프로그램을 추진하고 있습니다. 자세한 내용은 Drew Firment의 블로그를 참조하십시오.

실험

CCoE는 조직의 나머지 구성원들이 신속하게 실험하면서 조직의 보안 태세를 강화할 수 있도록 가드 레일을 제공합니다. 공통적인 애플리케이션 패턴에 대한 참조 아키텍처를 구현하고 하나 이상의 연속적인 통합 플랫폼을 개발함으로써 CCoE는 종속적인 사업 부문들이 일관되고 호환 가능한 방식으로 실험을 진행할 수 있도록 도움을 주고 있으며, 이를 통해 조직은 개발한 자산을 직접 운영하고 빠른 실패와 학습을 함과 동시에 이전보다 더 빨리 비즈니스 가치를 실현할 수 있습니다.

파트너

제가 앞서 언급했듯이, 파트너들은  클라우드 전략을 가속화하기 위해 존재하며  CCoE는 파트너 전략을 더 신속하게 실행하는 데 도움을 줄 수 있습니다. CCoE를 사용하면 진화하는 파트너 생태계를 지속적으로 관찰하면서 새로운 도구들을 평가하고, 차세대 클라우드 도구들과 컨설턴트가 복잡한 엔터프라이즈 환경에 통합되는 방식을 보여주는 모범 사례들을 관리할 수도 있습니다. CCoE는 법무, 조달, 보안 및 기타 비즈니스 이해관계자들과의 논의를 이끌어내야 하며, 클라우드에 대한 접근 방식과 파트너에게 기대하는 역할을 이해할 수 있도록 도움을 주어야 합니다. 많은 조직이 도구를 도입하는 것에 대해 체계화된 접근 방식을 적용하고 있기 때문에 각 사업 부문은 다양한 도구들을 유연하게 선택할 수 있는 반면, 기타 조직들은 단일 표준을 추구합니다. 무엇을 선호하든 간에 CCoE를 활용하여 접근 방식과 템플릿을 주도하십시오.

하이브리드

클라우드는 양자택일의 가치 제안이 아니며, 상당 기간 동안 IT를 운영해 온 엔터프라이즈라면 일종의 하이브리드 아키텍처를 운영할 것입니다. CCoE는 기업의 하이브리드 전략을 주도해야 하며, 클라우드와 자체구축 애플리케이션이 서로 상응하고 시간이 지남에 따라 클라우드로 이전할 수 있는 방법에 대한 표준 및 참조 아키텍처를 개발해야 합니다. 제가 Dow Jones에 있었을 때 우리 회사의 첫 하이브리드 “문제 해결”의 순간은, 자체 운영중이던 자격증명 관리 시스템을 회사가 개발한 네이티브 클라우드 애플리케이션에서 호출했을 때였습니다. 우리 회사의 DevOps 팀은 Amazon Virtual Private Cloud(VPC)가 수시간 동안 어떻게 작동하는지를 연구하고 보안 그룹과 내부 방화벽의 연동 방식을 원하는 대로 매핑했으며, 클라우드 애플리케이션이 자체 자산과 통신할 수 있도록 안전한 하이브리드 아키텍처를 구현했습니다. 이 모든 과정은 몇 시간 동안 진행되었습니다. 우리는 이를 즉시 자동화된 참조 아키텍처로 전환했으며 비슷한 과정에서 반복하여 사용했습니다. 다음 포스팅에서 해당 모범사례를 소개하겠습니다.

클라우드 우선

어떤 시점에서 CCoE는 몇 사업 부문 (그리고 궁극적으로는 전체)에게, 프로젝트에서 클라우드를 사용해야 하는 이유보다 사용해선 안 되는 이유를 스스로에게 질문하는 것이 더 낫다는 것을 증명할 것입니다. 기존 및/또는 호환 가능한 애플리케이션에 대해 자동화를 사용하고 참조 아키텍처를 구축하면 시장 출시 시간이 단축되고, 각 사업 부문이 CCoE와 억지로가 아니라 자발적으로 협력할것입니다. 이는 전통적인 인프라와 애플리케이션 팀의 영향으로부터 벗어남을 의미하며, 신중히 결정된 클라우드 우선 전략이 임원진에서부터 실무진까지 수용되고 인정받을 수 있습니다.

CCoE로 인한 그 밖의 모범 사례로는 무엇이 있습니까? 있다면 꼭 듣고 싶습니다!

-Stephen
@stephenorban
http://aws.amazon.com/enterprise/

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

 

 

Stephen Orban – 클라우드 혁신 센터를 위한 공동 책임

“옳은 일과 어려운 일은 대개 동일하다.” ― Steve Maraboli

 

저는 최근에 클라우드 혁신 센터(CCoE)라는 주제를 소개하였습니다. 클라우드 혁신 센터란 클라우드 모범 사례, 통합 관리 및 프레임워크를 개발함으로써 클라우드를 통해다른 직원들의 비즈니스 혁신을 지원하는 부서를 말합니다. CCoE의 설립은 엔터프라이즈 클라우드 여정 시리즈에 설명한 7가지 모범 사례 중 다섯 번째입니다.

기업의 CCoE는 처음에는 작게 시작하지만 비즈니스 가치가 더해지면서 점차 확장해야 합니다. 여기에 능숙한 기업들은 CCoE 지표 또는 KPI를 설정 및 비교하면서 진행 상황을 측정합니다. 이러한 지표들은 IT 리소스 사용량부터 대응 능력의 향상을 나타내는 매일/매주/매월 제품 출시 수, 그리고 CCoE가 영향을 미치는 프로젝트 수에 이르기까지 다양합니다. 이러한 지표들을 고객 서비스 중심의 접근 방식(원문)과 결합하면 다른 사업 부서들도 CCoE가 제공하는 가치와 협업의 즐거움을 깨닫고 CCoE와 함께 협업하는 데 관심을 보일 것입니다.

마지막 게시물에서 알아볼 내용은 CCoE의 인력 배치 방법입니다. 여기에서는 CCoE 확장에 성공한 기업들로부터 공통적으로 발견한 몇 가지 사항에 대해서 살펴보겠습니다. 이 게시물은 최종적인 목록이라기보다는 CCoE에게 맡길 수 있는 적절한 업무에 대해 생각해보는 기회로 활용해야 하며, 추가로 활용할 수 있는 몇 가지 자원에 대한 결론으로 끝을 맺습니다. 처음에는 작게 시작하는 것을 잊지 마십시오. 쓸데없는 데 시간을 낭비하지 말고 현재 프로젝트에서 당면한 문제를 해결하는 데만 집중하십시오. 문제를 해결하면서 실험과 측정을 통해 학습할 수 있습니다.

자격 증명 관리: 클라우드 환경에서 맡게 되는 역할과 권한을 이미 기업 내에서 맡고 있는 역할과 의무에 연계하려면 어떻게 해야 할까요? 어떤 환경에서 어떤 서비스와 기능을 이용하는 것이 편리할까요? Active Directory 및/또는 SSO(Single Sign On) 플랫폼과 통합하려면 어떻게 해야 할까요? 예를 들어 AWS의 IAM 플랫폼은 AWS 서비스마다 접근 수준을 세분화하여 제공합니다. 이러한 접근 수준의 세분화는 수많은 엔터프라이즈에게 새로운 경험이자, 기업 내에서 어떤 역할이 어떤 환경의 어떤 자원 및 서비스에 접근해야 할지 고민해볼 수 있는 기회가 될 것입니다.

계정 및 비용 관리: IT 서비스를 논리적으로 분리하거나 사업 부서별 비용을 파악할 수 있도록 계정을 각 사업 부서와 비용 센터로 연계하고 싶으신가요? 사업 부서별로 각자 소비 비용에 대해 책임을 지는 방법도 있지만 자원 포트폴리오의 규모가 커질수록 비용 최적화를 중앙에서 관리하는 것이 더욱 용이합니다. 이때 CCoE는 비즈니스에 따라 유연함을 유지할 수 있도록 시간차를 두고 RI를 구매하는 방법에 대해서 진지하게 생각하는 동시에 도움이 될 수 있는 몇 가지 도구(CloudHealthCloudability 등)를 살펴보아야 합니다.

자산 관리/태그 지정: 제공하는 자원마다 어떤 유형의 정보를 추적하시겠습니까? 제가 경험한 몇 가지 예로는 예산 코드/비용 센터, 사업 부서, 환경(테스트, 스테이징, 프로덕션 등), 담당자 등이 있습니다. Dow Jones에 재직할 당시 가장 먼저 직면한 성장통 중 하나는 실험에 참여하는 개발자들이 늘어나면서점차 불어나는 비용이었습니다. 하지만 개발 VPC에서 시작한 인스턴스마다 태그를 지정하고 야간이나 주말에는 해당 인스턴스를 멈추도록 스크립트를 작성함으로써 단 몇 시간 만에 이 문제를 해결하였습니다. 이때부터 처음으로 매우 정교한 태그 지정과 자동화 라이브러리를 구현하여 확장과 동시에 환경을 관리할 수 있게 되었습니다. 저는 다른  수많은 고객들도 고가용성 아키텍처와 “재해 무관심(disaster indifference)“의 수준에 점차 다가갈수록 프로덕션 환경에서 태그를 기준으로 작업을 진행하는 모습을 보았습니다. (재해 무관심이라는 표현은 Nike의 Wilf Russell에게서 차용함)

참조 아키텍처: 처음부터 보안 및 통합 관리 시스템을 환경에 구축하고 자동화를 통해 최신 상태를 유지하려면 어떻게 해야 할까요? 애플리케이션에서 사용하는 도구와 접근방식의 공통점을 찾아 정의할 수만 있다면 애플리케이션의 설치부터 패치 및 통합 관리까지 자동화할 수 있습니다. 이때는 전체 엔터프라이즈에서 각 사업 부서마다 자동화가 필요한 프로세스를 유연하게 추가할 수 있는 참조 아키텍처가 하나 필요합니다. 또는, 애플리케이션 클래스이나계층마다 다수의 참조 아키텍처가 필요할 수도 있습니다. 이 두 가지 사이에서 결정될 가능성이 가장 높지만, 이유야 어떻든, 시간이 지날수록 더 많은 프로세스를 자동화 할 수 있는 방법을 고민하여 각 사업 부서가 인프라에 대한 고민은 줄이고 자신의 애플리케이션에 대해 더 많이 생각할 수 있도록하십시오.

시간이 지나면서 CCoE의 학습 효과가 높아지면 더욱 규범적으로 대처할 수 있는 사업 부서가 늘어나 일관성은 그대로 유지하면서 혁신의 자유는 모든 부서가 동일하게 누릴 수 있습니다. 여기에서 다루지는 않았지만 그 밖에도 자동화 전략의 정의, 하이브리드 아키텍처에 대한 탐구, 각 사업 부서가 신속한 움직임으로 개발한 자산을 직접 운영할 수 있는 연속 전달(continuous delivery) 기능 지원, 데이터 통합 관리의 정의, 그리고 비즈니스에 중요한 지표/KPI에 대한 투명성을 보장하는 대시보드 구현 등이 고려해야 할 사항입니다.

AWS 클라우드 도입 프레임워크에는 지금까지 얘기한 모범 사례를 비롯한 여러 가지에 대해 고찰할 수 있는 규범적 지침에 관한 견해가 다수 포함되어 있습니다. 또한 AWS Trusted Advisor를 이용하면 비용, 성능, 보안 및 내결함성 최적화를 사전에 살펴볼 수 있습니다. 마지막으로, AWS Well-Architected Framework를 통해 CCoE의 업무를 지금까지 AWS 고객에게서 알아본 모범 사례와 비교하여 벤치마킹하는 것도 가능합니다.

그 밖에 중요한 문제에 집중할 수 있도록 CCoE가 기여한 점이 있다면 무엇이 있을까요? 있다면 꼭 듣고 싶습니다!

 

-Stephen
@stephenorban
http://aws.amazon.com/enterprise/

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

Stephen Orban – 엔터프라이즈 클라우드 혁신 센터(CCoE)의 인력 구성

“미래는 지식이 아닌 태도, 적성 그리고 감사에 의해 좌우된다.” – Debasish Mridha M.D.

 

여러분이 습득한 것들을 기반으로 작게 시작하고 반복하여 성장하는 것은 성공적인 엔터프라이즈 클라우드 여정에서 계속 되풀이되는 주제에 속합니다. 저는 제 게시물에서 이 주제를 자주 거론하고 있으며, 이와 동일한 반복적 사고를 여러분이 속한 조직의 클라우드 혁신 센터(CCoE)를 이끌어 갈 하나의 팀을 구성할 때 적용할 것을 권합니다.

여러분은 클라우드가 조직에 어떤 영향을 미칠 수 있는지에 대해 기꺼이 배우고 싶어 하며 흥미를 느끼는 소수의 미래 지향적인 사람들을 모집하는 일부터 시작하게 될 것입니다. 3~5명의 팀원만 있어도 눈에 띄는 차이가 즉시 생길 수 있습니다. 그럼 이제 매월 CCoE가 조직에 미치는 영향을 평가하고, 필요한 조정을 하고, 그러한 조정이 영향을 미치는 프로젝트의 수효와 규모가 증가할수록 팀을 확장해 보십시오.

해당 업무의 적임자를 찾았다는 것은 어떻게 알 수 있을까요?

임원들은 찾아야 할 인재의 유형과 그러한 인재들을 채용할 수 있는 장소/방법을 제게 물을 때가 많습니다. 저는 대체로 태도가 적성만큼이나 중요하다는 사실을 발견했습니다. 이는 어떤 대규모 조직이든 클라우드를 활용하는 데 필요한 인력을 이미 보유하고 있음을 의미합니다. 새로운 것을 배우는 것에 대해 진정한 열정과 흥미를 가진 인재들을 찾아보십시오. 담당 프로젝트에서 클라우드를 사용하는 데 열성적인 직원들은 여러분이 속한 조직 내에 많이 있을 것이며 그러한 직원들을 찾는 일은 결코 어렵지 않을 것입니다. 시장에서 채용된 인재로 팀을 증원하는 것은 좋은 일입니다. 다만 그런 생각을 실행에 옮기기까지 시간을 지체하지는 마십시오. 만약 모든 조직이 신입 팀원의 채용을 기다리기만 한다면 그러한 인재를 내부에서 직접 쉽게 발굴할 수 있는 경우에도 외부의 새로운 인재를 찾느라 업무상 불필요한 차질을 빚게 될 것입니다.

CCoE 팀의 구성원들은 다양한 역할과 배경을 가진 사람들로 구성하는 것이 가장 이상적입니다. 이러한 팀의 구성원으로는 애플리케이션 개발자, 시스템 관리자, 네트워크 엔지니어, 보안 실무자, IT 운영자 및 데이터베이스 관리자를 예로 들 수 있습니다. (다만 이에 국한할 필요는 없습니다.) 다양한 전문 기술 그룹을 하나로 모으면 다양한 시각을 가진 팀을 얻게 될 것이며 보다 완벽한 플랫폼을 구축하는 결과로 이어질 수 있습니다. 기업의 기존 제품 및 프로세스에 대한 팀의 조직적 지식은 여러분의 조직에 가장 적합한 클라우드 모범 사례를 만들고 관리하는 방법에 관한 의사 결정을 안내하는 데 도움이 될 것입니다.

대부분의 클라우드 서비스가 제공하는 “서비스화(as-a-service)” 모델 역시 교차 기능적 관점에 아주 적합합니다. 예를 들면, 많은 서버 및 데이터베이스 관리 업무들은 현재 자동으로 실행되며 소프트웨어를 통해 제어 가능합니다.서버 및 데이터베이스에서 애플리케이션을 최적화하는 방법을 아는 직원들이 여전히 필요하지만, 이러한 작업에는 자동화 코드를 작성하는 방법을 아는 사람이 도움이 될 것입니다.

이처럼 다양한 분야의 융합은 DevOps가 증가하게 된 배후 요인 중 하나이며, CCoE가 일반적으로 DevOps로 명명되고 DevOps 엔지니어와 같은 역할들이 CCoE를 담당하는 이유 중 하나이기도 합니다. “DevOps”와 “DevOps 엔지니어”는 매우 새로운 기술 용어에 속하지만 개념 자체는 지난 수십 년 동안 존재해왔다고 생각합니다. 오늘날 이러한 역할들을 맡는 사람들은 대부분 다양한 분야 및/또는 전문 분야에서 배출되고 있으며, 각자의 지평을 넓히고 더욱 다양한 가치를 그들이 소속된 조직에 전달하고자 합니다.

물론 모든 기업에서는 클라우드 챔피언들은 물론 변화를 싫어하는 집단도 함께 존재하게 될 것입니다. 주저하는 직원들을 더 많이 설득하기 위해서는 올바른 방향으로 움직이기만 하면 됩니다. 저는 CCoE 에 한두 명의 회의론자를 배치하여 이러한 시도를 한 일부 기업과 대화를 나눈 적이 있습니다. 많은 영향력을 행사하며 클라우드 전환 방향으로 이끌어가는 리더들이 여러분의 조직 내에 있다면, 그들을 CCoE 내부 또는 그 주변에 배치하여 클라우드 내에서의 빠른 가치 창출을그들의 성공과 연계시키는 방안도 고려해볼 수 있을 것입니다. 이러한 방법은 신중하게 관리할 필요가 있으며, 다만 저는 그것이 문화적 변화를 위한 능력을 배가시키는 요인으로 작용한다고 생각합니다. 회의론자들이 클라우드가 기업의 비즈니스와 자신의 경력에 어떤 도움을 줄 수 있는지에 대해 더 많이 알면 알수록, 조직이 나아갈 방향을 지키면서 조직 내 다른 구성원들로 하여금 이를 따르도록 독려할 가능성도 그만큼 높아집니다.

다음에 게시글에서는CCoE를 통해 모든 모범 사례들을 집중시킬 방법에 관하여 기업의 조직 내에서 CCoE가 보고할 부문은 어디인지를 다룰것입니다. 현재로서는 CCoE가 보고를 하는 부문이 CCoE가 받는 경영 지원보다 덜 중요하다는 점만언급할 것입니다. 기업의 CCoE는 영향력이 강한 변화를 일으킬 수 있도록 조직의 권력 구조 내에서 충분히 높은 위치에 있어야 합니다.

CCoE 인력을 배치한 경험은 어땠습니까? 팀을 돋보이게 하며 성공적으로 운영하기 위한 다른 전략이 있습니까? 있다면 꼭 들어보고 싶습니다.

 

-Stephen
@stephenorban
http://aws.amazon.com/enterprise/

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

Stephen Orban – 엔터프라이즈 클라우드 혁신 센터(CCoE)를 설립하는 방법

“내게 충분히 긴 지렛대와 지렛대를 놓을 받침점을 달라. 그러면 세상을 움직이겠다.” -Archimedes

 

지금까지 엔터프라이즈 클라우드 여정 시리즈에서는 임원의 역할 직원 교육실험 시간 부여, 그리고 파트너 참여 방법을 (다시) 고려하는 것이 얼마나 중요한 지 살펴봤습니다. 이 게시물에서는 그 다음 모범 사례로 구현 자체는 아마 가장 힘들지만 조직에서의 변화 창출에 관해서는 가장 효과가 큰 클라우드 혁신 센터(CCoE – Cloud Center of Excellence) 설립에 대해 소개합니다.

2012년, 저는 운 좋게도 Dow Jones의 CIO로 임명되었습니다. 당시 Dow Jones는 유서 깊은 123년 역사의 조직으로 강력한 브랜드, 풍부한 콘텐츠, 충성도 높은 고객 기반을 가지고 있었습니다. 제 일은 갈수록 경쟁이 치열해지는 환경에서 살아남고 운영 효율성을 개선하며 비용을 절감하기 위해 기술 조직의 업무 초점을 기술 개발로 전환하는 것이었습니다.

이런 목표를 달성하기 위해 끊임없이 전략을 개발하는 과정에서 우리는 비즈니스에 집중할 수 있도록 사내 인재 확충, 오픈 소스 활용, 클라우드 서비스 도입 등 여러 가지 지렛대를 활용했습니다. 하지만 우리가 내린 최고의 결정은 아마도 조직 전체에 클라우드 전략을 어떻게 구축하고 실행할지 규범화하기 위해 우리가 DevOps라고 불렀던 CCoE를 창설한 것이었습니다. 저는 일하는 동안 변화 관리 프로그램의 성공과 실패를 지켜보면서 조직에서 가장 중요한 프로그램에 대해 단일 소유권을 지닌 전담 팀을 두는 것이 빠르게 결과를 얻고 변화에 영향을 미치는 효과적 방법 중 하나라는 것을 알고 있었습니다. 제 엔터프라이즈 DevOps 시리즈에서는 이런 경험 몇 가지를 더 자세히 다루고 있습니다.

 

© Les Chatfield https://www.flickr.com/photos/elsie/

그 이후로 제가 만나 본 기업 중 여정에서 유의미한 발전을 이뤄낸 기업들은 하나같이 모범 사례, 프레임워크, 진화하는 기술 운영 거버넌스의 창출, 전파, 제도화를 전담하는 팀을 두고 있었으며, 이러한 구현에서 클라우드의 활용은 점점 늘어나고 있습니다. 이 CCoE 팀은 소규모 조직으로 시작하여 기업의 규모에 맞게 클라우드 기술을 구현할 방법에 대한 관점을 개발하며, 제대로 구현될 경우, 기술이 비즈니스에 기여하는 방식을 혁신하는 지렛대 받침점이 될 수 있습니다.

다음 몇몇 게시물에서는 엔터프라이즈가 다음 요소를 통해 이를 수행하는 방법을 살펴보겠습니다.

팀 구축

다양한 직업적 배경을 가진 3명에서 5명 정도의 팀을 꾸리는 것이 좋습니다. 개발자, 시스템 관리자, 네트워크 엔지니어, IT 운영 및 데이터베이스 관리자를 찾으십시오. 원칙적으로 이들은 생각이 열려 있고 현대 기술과 클라우드 서비스를 활용하여 일하는 방식을 바꾸고 조직을 미래로 이끌 방법을 고민하는 사람들이어야 합니다. 경험이 일천한 직원을 합류시키는 것을 꺼리지 마십시오. 태도가 능력만큼 중요할 수 있으며, 필요한 인재는 이미 조직에 있을 수 있습니다.

팀의 책임 범위 설정(및 확장)

CCoE는 조직의 나머지 부분이 클라우드에 시스템을 구현할 때 (또는 시스템을 이전할 때) 활용하는 모범 사례, 거버넌스, 프레임워크 구축을 책임져야 합니다. 역할과 권한, 비용 거버넌스, 모니터링, 사고 관리, 하이브리드 아키텍처, 보안 모델 등 기본부터 시작하십시오.

시간이 지나면서 이러한 책임은 복수계정 관리, “골든” 이미지 관리, 자산 관리, 사업 단위 요금상환, 재사용 가능한 참조 아키텍처 등을 망라하는 수준까지 발전할 것입니다. 분석 불능 상태에 빠지지 않도록 하십시오. 실무 경험이 쌓이면서 역량은 자연스럽게 발전시킬 수 있습니다.

팀을 다른 모범 사례에 연계

제가 글에 썼던 모든 모범 사례는 상호 의존적입니다. CCoE가 성공하기 위해서는 경영진의 파격적 지원을 확보하고, CCoE 방법에 대해 조직을 교육하며, 경쟁력을 유지하기 위해 실험을 받아들이고, 환경에 가장 좋은 도구와 파트너를 늘 파악하며, 조직의 하이브리드 아키텍처를 소유하고, 클라우드 우선 전략에서 핵심 플레이어가 되어야 합니다.

이 각각의 주제는 앞으로 몇 주에 걸쳐 자세히 살펴볼 계획입니다. 공유하고 싶은 경험이 있거나 시리즈에서 앞으로 다루기를 바라는 분야가 있다면 알려 주십시오!

 

-Stephen
@stephenorban
http://aws.amazon.com/enterprise/

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