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