클라우드 혁신 센터를 위한 공동 책임
“옳은 일과 어려운 일은 대개 동일하다.” ― 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를 구매하는 방법에 대해서 진지하게 생각하는 동시에 도움이 될 수 있는 몇 가지 도구(CloudHealth, Cloudability 등)를 살펴보아야 합니다.
자산 관리/태그 지정: 제공하는 자원마다 어떤 유형의 정보를 추적하시겠습니까? 제가 경험한 몇 가지 예로는 예산 코드/비용 센터, 사업 부서, 환경(테스트, 스테이징, 프로덕션 등), 담당자 등이 있습니다. 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의 엔터프라이즈 클라우드 여정 시리즈 입니다. 더 자세한 것은 전체 목록을 참고하시기 바랍니다.
Source: 클라우드 혁신 센터를 위한 공동 책임
