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