신현묵 오픈헬스데이터 이사가 블로그에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.
엄청난 효율과 고속의 처리를 만들어 낸 것은 어떤 이유 때문에 가능한 것이었을까? 그리고, 이러한 DevOps의 성과물들은 일반적인 IT기업에서도 얻을 수 있는 환경일까? 가장 먼저 DevOps의 장점을 몇 가지 정리하고 넘어가자.
DevOps의 장점을 서술한다면 다음의 3가지로 선언할 수 있다.
1. 최소 인원으로의 개발과 운영이 가능한 환경을 지향한다.
2. 서비스의 배포와 운영이 자유롭고, 서비스가 매우 신속하고 빠르게 운영된다.
3. 개발의 배포가 자동화되며, 그에 따라 고품질 서비스를 지향한다.
자, 그렇다면. 가장 중요한 것은 이러한 DevOps는 내가 속한 조직에서 만들 수 있는 문화와 개발형태인가? 대부분의 개발 조직에서는 이러한 것에 대해서 가장 궁금할 것이다. 결론부터 이야기하자면 DevOps가 가동되고, 개발 조직의 문화가 되려면 다음의 두 가지가 필수이다.
1. 소프트웨어를 잘 만들어내는 개발자
2. 잘 동작하도록 운영하는 운영자
그리고, 이러한 두 가지의 조건을 만족시키기 위한 기본적인 환경적인 구성이 필요하다. 그것은 가장 먼저 소프트웨어 품질을 관리하는 제대로 된 품질관리 조직이 있어야 하며, 개발 조직이 빠르게 소프트웨어를 개발, 빌드, 테스트, 배포, 운영하게 할 수 있는 사이클을 신속하게 진행할 수 있는 개발환경을 갖추고 있어야 한다. 또한 업무 프로세스를 정의하고, 각 조직 간의 역할을 조율하는 프로세스들이 매우 자연스럽게 자동화되고 효율적으로 운영되고 있어야 한다. 그래야, ‘소프트웨어를 잘 만들어내는 개발자’와 ‘잘 동작하도록 운영하는 운용자’가 만들어지게 되고, 그 역할과 방법론이 효율적으로 가동되는 DevOps는 가동된다.
DevOps의 원칙
그렇다면, 이러한 DevOps을 세팅하고 구입하기 위해서 조직이 필요로 하는 비용적인 측면은 어떤 것들이 있을 것인지 가볍게 살펴보자. DevOps는 매우 큰 비용을 요구하는 것은 아니다. 다만, 그 비용이라는 것이 전반적으로 투자된 비용을 의미하는 것이지, 단기간에 투입되어 얻어지는 효과는 아니라는 점에 주목해야 한다.
가장 먼저, ‘개발자들은 기능 개발과 결함의 수정 등의 변화를 얼마나 자주 일으키고 있는지 체크하고 이를 관리하거나, 관리할 수 있는 포인트를 개발자들에게 제공하고 있는가?’하는 측면이 가장 먼저라고 할 수 있다.
두 번째는 운영자가 실제 서비스의 안전성과 성능 향상을 위하여 취해지는 시스템 아키텍처 적인 변화에 대해서 얼마나 두려워하고 있으며, 이를 얼마나 수치화하여 관리하고있는지, 그리고 그 선택을 할 수 있는지가 DevOps에 가장 중요한 측면이기도 하다.
세 번째는 이러한 개발집단과 운영 집단에서 선택과 운영, 개발의 우선 순위 등을 고르고 선택할 수 있는 ‘권한과 책임’이 주어지고 있느냐 하는 점이다.
네 번째는 큰 조직, 큰 기업, 큰 프로세스의 운영 시에는 이러한 DevOps와 같은 콘셉트는 운영하기 매우 어렵다. 그러므로, 개발과 운영 환경의 구분과 절차. 권한과 릴리즈 절차와 규칙 등에 대해서 얼마나 세분화하고 있는지, 그리고 일에 대해서 얼마나 작은 규모로 산정하고 산출하고 있는지에 대해서도 정의되어야 한다.
아쉽게도 DevOps를 구현하고 싶지만, 착각하고 있는 개발자 조직의 경우의 사례를 살펴보면 다음과 같은 일들이 실제로 벌어진다고 볼 수 있다.
1. 사용하지도 않는 기능을 도출하고, 이를 위하여 시간과 비용을 낭비하고 있는 경우
2. 개발 후 버그를 찾기 위해서 테스트를 하고 있다고 프로세스를 정형화하는 일이다. 실제 DevOps를 지향하는 개발 조직의 경우에는 내부적으로 개발 단계에서 충분하게 품질을 고려하여 디자인되고 개발을 진행하려 노력한다.
3. ‘예측을 위한 투자를 많이 하고 있는가?’라는 질문에 소극적인 경우이다. 그나마 대부분은 사건 발생 시에 빠르게 대처할 수 있는 환경이라고, 가능한 구축하라고 권하는 경우가 태반이다.
4. 소프트웨어 공학을 잘 못 받아들여 정말 중요한 지표에 집중해야 하는데, 너무 많은 지표를 도출하기 위하여 삽질을 하는 경우가 대표적인 착각되어진 개발 조직의 경우라고 볼 수 있다.
DevOps을 좁게 보는 진정한 장점
DevOps는 ‘잦은 배포’를 수행하면서, 잦은 릴리즈를 수행하고, 잦은 릴리즈를 통해서 위험을 하향 균등화 시키는 것이 주목적이라고 작게 정의할 수 있기도 하다. 그래서, 애자일과도 아주 잘 맞는다. TimeBox를 2주로 맞추거나 1.5주로 맞추고 배포를 진행하는 경우도 빈번하게 필자는 상황을 참조한다.
하지만, 이러한 DevOps를 구현하는 데 있어서 다음과 같은 최소한의 필요충분요건이 필요하다.
1. 잦은 개발과 버그 픽스가 가능한 개발자 환경을 구현하라
2. 공유 소스 코드 버전 관리시스템도 없다면, 이러한 환경을 구성하는 것은 거의 불가능하지 않겠는가?
3. 빌드, 테스트, 배포 단계를 자동화하기 위하여 얼마나 노력하고 있는가?
4. 수작업의 실수와 반복을 어떻게 최소화하기 위해서 노력하는가?
5. 개발 조직과 운영조직의 협업을 위하여 빈번한 커뮤니케이션 소통 비용을 지불하고 있는가?
이러한 최소한의 필요충분조건을 만족한다면, 개발 조직은 다음과 같은 최소한의 목표를 이루기 위해서 준비를 한다고 볼 수 있다.
1. 개발과 품질관리, 운영을 교집합적으로 운영하기 위한 방법을 터득했고, 그것을 개발 조직에 내재화하기 위하여 노력 중이다.
2. 신뢰성, 보안성, 개발과 배포 사이클을 보다 더 빠르게 개선하기 위해서 배포, 테스트, 세부 기능 개발, 릴리즈 관리를 목표로 조직이 운영 중이다.
3. 툴이 아니라, 문화와 일하는 방법에 대한 경험을 더 우선적으로 하고 있다.
DevOps의 가장 중요한 원칙
위에서 이야기한 필요조건과 환경에 대한 것이 준비가 된다면, 다음과 같은 DevOps의 원칙을 실현할 준비가 된 것이다. 그 원칙을 살펴보자
1. 주요 기능에 집중하고 있는가?
2. 품질을 내재화하기 위하여 노력하고 있는가?
3. 개발에 필요한 지식을 창출하기 위해서 과학적으로 접근하고 있는가?
4. 완벽한 명세서를 만들기 위한 비용보다, 명쾌한 협업을 중시하여 커뮤니케이션 비용을 지출하고 있는가?
5. 가능한 한 빨리 개발하기 위해서 시도하고 있는가?
6. 사람을 존중하는 개발자 문화를 만들고 있는가?
7. 최적화를 위한 방안을 고안하는데 회의나 토론을 아까워하지 않고 있으며, 그것에 대해서 투자를 아낌없이 하고 있는가?
이러한 과정은 DevOps에 대해서 실현하기 위해서 노력하는 행위와 절차라고 볼 수 있다. 가능하다면 DevOps의 성숙도 모델에 대한 설명과 실제 우리가 그러한 모델을 통해서 개발 조직에 DevOps의 사상을 표현할 수 있는지에 대해서 설명할 기회가 곧 다가올 것으로 기대해본다.
물론, 기술적 부채에 대해서도 한 번 거론한 다음에 그 이야기를 이야기하도록 하겠다.
DevOps는 애자일과 마찬가지로 선언이고 문화에 해당한다. 즐거운 개발을 지향하고 있다면 소프트웨어 품질은 매우 당연하게 좋아진다. 행복한 개발자가 훌륭한 소프트웨어를 만든다는 것을 잊지 말자. 그것이 DevOps의 시작이며, 출발이다.
