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