깃 플로우, code convention, 애자일, 데브옵스... 세상엔 협업을 위한 수많은 워크가이드가 존재한다. 이들을 개인 프로젝트나 소규모 토이 프로젝트에서 접하게 되면 드는 생각이 있다.
왜 굳이...?
한번이라도 보면 생각보다 복잡하며 개발 전 정해야 하는 사항이 엄청나게 많고 설정하고 구축해야 하는 시스템이 차라리 빨리 개발에 들어가는게 낫지 않나라고 생각이 들곤한다. 이는 반은 맞고 반은 틀리다. 한번 데브옵스와 같은것들이 왜 생겨났는지 알아보고 우리의 프로젝트에 어떤식으로 적용할지에 대해 알아보자.
데브옵스(DevOps, 신경덕)는 소프트웨어의 개발(Development)과 운영(Operations)의 합성어로서, 소프트웨어 개발자와 정보기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 환경이나 문화를 말한다. 데브옵스는 소프트웨어 개발조직과 운영조직간의 상호 의존적 대응이며 조직이 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것을 목적으로 한다 (wiki - devops)
...저게 뭔 소리인가 싶다. 그래서인지 처음 데브옵스를 접하고 적용하려는 학생은 첫 시작이 비슷하다. "Devops툴을 사서 적용하자."
단적으로 말하는데 절대 낭비다. 데브옵스 툴이란 것은 우리가 데브옵스를 워크플로우에 녹이기 위해서 보조를 해주는 툴이지, 데브옵스를 만들어주는 것이 아니다. 데브옵스와 같은 워크가이드가 왜 필요했으며 우리 프로젝트엔 어떻게 적용할지를 정하는 과정이 필요한 것이다.
일단 데브옵스까지 워크플로우가 생긴 과정을 살펴보자.
옛날 옛날, 전통적인 개발방식은 지금의 대학생의 팀플과 똑같았다. 교수(관리직)가 과제(결과물)를 데드라인과 함께 주고 팀장 주도하에 각각의 업무를 나누고 할당하고 보고하고 종합하고...
이 과정에서 단점들은 크게 4가지로 나타났다.