DevOps를 하려면 무엇부터 해야 할까?
2020-09-05‘데브옵스(DevOps)를 도입한 조직은 개발과 운영 업무를 통합하여 개발 주기를 앞당기고, 고객 서비스의 품질을 높인다’는 이야기를 어디서 한 번쯤 들어보았을 것이다. 이름만 대면 아는 외국 기업들은 이런 데브옵스 문화와 시스템을 잘 정착시켰다고 하는데, 먼 나라 이야기 같기만 하다.
개발팀과 운영팀의 업무를 어떻게 나눌 것인가?
아마 데브옵스를 도입하려고 생각해 보았다면, ‘좋은 건 알겠는데 개발팀과 운영팀의 업무를 어떻게 나누고, 그 업무를 잘 나누도록 결정하는 사람은 누가될 것인가?’라는 근본적인 질문에 답을 내리지 못했을 수도 있다. 데브옵스의 핵심이자 가장 어려운 부분이다.
언제든 원하는 기능을 제품에 반영할 의사가 있는 개발팀과 이미 잘 동작하는 시스템을 바꾸고 싶지 않은 운영팀을 과연 하나의 팀으로 만들 수 있을까?
답을 먼저 내리자면, 팀을 만들자는 것이 아니다.
기업의 임원은 ‘개발과 운영을 결합하여 비용을 절감할 수 있으리라’는 희망을 품을 수도 있다. 그러나 데브옵스 팀은 1인 2역을 담당하는 사람들의 모임이 아니다. 운영팀과 개발팀은 같은 제품에 관여하지만, 입장과 역할이 다르다. 데브옵스는 이들의 일을 합해서 한 부서에 몰아주는 것이 아니라, 각자의 역할에 집중하도록 만드는 일에 가깝다.
소통과 협업을 통해 각자의 업무에 집중할 수 있게 하는 것
이것이 아마 위의 질문에 대한 대답이 될 수 있겠다.
제품을 개발하는 과정에는 반드시 해야 하지만 개발자와 운영자 중 누가 할 일인지 명확하지 않은 일이 존재한다. 예를 들어, 개발 환경을 구축하는 것, 서비스가 잘 동작하는지 모니터링 하는 것, 또는 개발한 기능을 제품에 반영하는 일 등이 있다. 제품에 대한 권한이나 조직의 규모에 따라 다르지만 이런 모호한 영역은 보통 개발자의 몫이 되고, 결국 그들은 더 중요한 일에 집중하지 못한다.
조직 내 데브옵스를 구축하는 것은 개발자와 운영자 중간에 존재하는 모호한 업무 영역을 어떻게 관리할지 정하는 일이다. 소통과 협업을 통해 그리고 투명하고 솔직한 문화를 통해, 개발하는 사람은 개발에만 집중할 수 있고 운영하는 사람은 운영에만 집중할 수 있는 환경을 만들어야 한다.
개발에 필요한 환경(스토리지, 네트워크, 리소스 등)을 몇 분 안에 직접 구축할 수 있는 환경이 만들어지면, 개발자는 실험적인 기능을
추가하거나 다양한 시나리오를 실행하여 창의적이고 혁신적인 시도를 할 수 있다.
개발팀과 운영팀의 협업 환경, 무엇부터 시작해야 할까?
데브옵스는 사고방식을 바꾸고 문화를 바꾸는 것이다. 어쩌면 가장 어려운 일일 수도 있다. 하지만 추가 인프라를 갖추거나 새로운 사람을 뽑지 않아도 되기 때문에, 개발팀과 운영팀원들의 생각만 바꾸면 되는 가장 쉬운 일이 될 수도 있다.
생각을 바꾸기 위한 첫걸음, 무엇일까?
문화를 바꿔보자
그런데 ‘문화’라는 것은 무엇일까?
적어도 수동적인 것은 아닌 것 같다. 문화는 보이지 않는 것이며, 문화를 둘러싼 사람들이 동의하고 기여해야 한다. 마찬가지로 데브옵스 문화는 개발하는 서비스, 회사 규모, 조직 구성원에 따라 다를 수 있다. 따라서 완벽한 데브옵스의 기준도 명확히 정의할 수 없으며, 서비스 개발에 관여한 모두가 데브옵스 문화에 기여해야 한다.
언제나 그렇듯, 모두의 생각이 한 번에 바뀔 것이라고 기대하면 안 된다. 여러 번 시행착오도 겪어야 하고, 다시 원점으로 돌아가기도 하면서 끝내는 화려해 보이는 (그 외국계 기업에서 한다는) DevOps가 마침내 우리 회사에도 정착하는 것이다.
이 문화를 만들기 위한 방법론으로 1)애자일 방식을 차용하고, 지속적 배포를 위한 2)파이프라인을 구축하고, 3)자동화 도구를 조직에 도입한다. 개발과 운영 과정을 모두가 공유함으로써 개발자는 자신의 코드가 어떻게 테스트 되고, 검증되고, 운영되고 있는지 투명하게 알 수 있으며, 운영자는 개발 일정과 과정을 파악할 수 있다.
데브옵스 문화가 잘 정착된 조직에서 개발자는 작은 단위로 쪼개진 기능에 대한 코드를 작성하고, 미리 약속한 파이프라인에 따라 제품에 반영한다. 이로써 개발 사이클이 빨라지고 운영 효율이 높아진다.
개발 사이클이 빨라진다는 것을 ‘데브옵스를 하기만 하면 기존에 석 달 걸려 출시하던 제품을 한 달 만에 출시할 수 있다’는 뜻으로 착각하면 안 된다.
<그림 1> 소프트웨어 개발 과정 (출처 : Richard’s guide to Software development)
1) 애자일 방법론
애자일 방법론은 무엇이고 폭포수 방법론은 무엇일까?
기존 개발 방법(폭포수 모델)이 요구사항 분석, 설계, 구현, 시험, 통합의 흐름을 긴 주기를 가지고 모든 기능을 한 번의 배포에 담는 방식이라면, 데브옵스는 최소 기능 제품(MVP, Minimum Viable Product)을 먼저 개발하고 점차 개선해 나가는 방식이다.
<그림2> 폭포수 방법론과 애자일 방법론
(출처 : https://www.safaribooksonline.com/library/view/user-story-mapping/9781491904893/ch04.html)
폭포수 모델
: 요구사항, 분석, 설계, 구현, 시험, 통합의 흐름이 마치 폭포수처럼 아래로만 향하는 순차적 방식이다. 전 단계가 완료되기 전에는 다음 단계로 진행할 수 없도록 제한한다. 고객들은 동작하는 프로토타입을 보지 않고는 요구사항을 정확히 정의할 수 없다. 또한, 다음 단계에 대한 이해나 경험 없이 각 단계를 완벽히 마무리하는 것이 불가능할 수도 있다. 이런 상황에서 폭포수 모델을 사용하면 새로운 요구 사항을 반영할 수 없고 일정을 정확히 예측할 수 없기 때문에 개발자들의 야근과 스트레스를 유발한다. 폭포수 방법론의 문제점을 바탕으로 애자일 방식이 대두되었다.
애자일 방법론
: 능동적인 변화 대응을 핵심으로 두고 업무를 작게 쪼개서 더 중요한 일부터 하되, 계속 반복해서 개선하는 것을 원칙으로 한다. 일정한 주기를 가지고 끊임없이 프로토타입을 만들어내며, 그때그때 필요한 요구를 더하고 수정하여 하나의 커다란 소프트웨어를 개발해 나가는 방법이다. 어느 특정 개발 방법론을 가리키기 보다는 애자일(Agile : 기민한) 개발을 가능하게 하는 다양한 방법론 전체를 말한다.
2) 파이프라인 구축
파이프라인은 개발자가 그들이 만든 코드를 컴파일(Compile), 빌드(Build) 그리고 배포(Deploy)하게 해주는 자동화된 프로세스들의 묶음이다. 파이프라인을 구축하는데 명확한 기준은 없지만, 일반적인 구성은 빌드 자동화, 지속적 통합, 배포 자동화, 테스트 자동화가 있다.
이런 파이프라인을 만들기 위해 사용할 수 있는 다양한 자동화 도구들이 있다.
3) 자동화 도구
도구를 도입하여 파이프라인을 구성하면, 작성한 코드를 자동으로 빌드하고 배포하는 환경을 구성할 수 있다. 이렇게 되면 배포 주기가 빨라지고, 계획을 얼마든지 중간에 바꿀 수 있는 환경이 만들어진다. 앞서 설명한 폭포수 개발 방법론에서 애자일 방법론으로 갈 수 있는 기반이 생기는 것이다. 각 기능을 구현하기 위해 사용할 수 있는 도구가 많지만, 어떤 도구가 우리 조직과 서비스에 맞는지는 부딪혀봐야 안다.
Azure DevOps를 이용하면 여러 도구의 학습에 대한 부담 없이 파이프라인을 손쉽게 구성할 수 있고 관리 포인트를 줄일 수 있다.
문화만 만든다고 될 일인가?
당연히 아니다. 문화와 사고방식의 변화는 데브옵스를 적용하기 위한 가장 기본적인 조건이다. 모두 한마음 한뜻으로 데브옵스를 적용하기로 마음먹었다면, 이제부터 끝없는 협의와 조율의 시간이 시작될 것이다. (내로라하는 개발자들이 다니는 기업들도 그 문화를 만드는데 1년이 넘는 시간이 들었다고 한다) 협의를 통해 어떤 부분을 자동화할 것인지, 어떤 도구를 사용했을 때 가장 효율적으로 협업할 수 있는지 검토해야 한다.
데브옵스를 위한 완벽한 시나리오
데브옵스를 위한 완벽한 시나리오는 없다. 도구나 플로우는 데브옵스라는 문화를 만들기 위한 수단일 뿐이다. 그러나 개발과 운영 과정을 투명하게 관리하려면 중요한 것이 있다. 제품 개발 과정을 한 대시보드에서 관리하는 것이다.
여러 도구를 쓰다 보면 소통이 분산되고, 결국 개발과 운영이 함께 사용하는 하나의 도구로 통합할 때가 온다. 이와 관련하여 제품 개발 파이프라인을 구성할 수 있는 통합 협업 도구 Azure DevOps를 사용해본 개발자의 글을 소개하고자 한다.
