서론
깃 플로우, code convention, 애자일, 데브옵스... 세상엔 협업을 위한 수많은 워크가이드가 존재한다. 이들을 개인 프로젝트나 소규모 토이 프로젝트에서 접하게 되면 드는 생각이 있다.
왜 굳이...?
한번이라도 보면 생각보다 복잡하며 개발 전 정해야 하는 사항이 엄청나게 많고 설정하고 구축해야 하는 시스템이 차라리 빨리 개발에 들어가는게 낫지 않나라고 생각이 들곤한다. 이는 반은 맞고 반은 틀리다. 한번 데브옵스와 같은것들이 왜 생겨났는지 알아보고 우리의 프로젝트에 어떤식으로 적용할지에 대해 알아보자.
협업 워크플로우의 탄생 과정
서론
데브옵스(DevOps, 신경덕)는 소프트웨어의 개발(Development)과 운영(Operations)의 합성어로서, 소프트웨어 개발자와 정보기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 환경이나 문화를 말한다. 데브옵스는 소프트웨어 개발조직과 운영조직간의 상호 의존적 대응이며 조직이 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것을 목적으로 한다 (wiki - devops)
...저게 뭔 소리인가 싶다. 그래서인지 처음 데브옵스를 접하고 적용하려는 학생은 첫 시작이 비슷하다. "Devops툴을 사서 적용하자."
단적으로 말하는데 절대 낭비다. 데브옵스 툴이란 것은 우리가 데브옵스를 워크플로우에 녹이기 위해서 보조를 해주는 툴이지, 데브옵스를 만들어주는 것이 아니다. 데브옵스와 같은 워크가이드가 왜 필요했으며 우리 프로젝트엔 어떻게 적용할지를 정하는 과정이 필요한 것이다.
일단 데브옵스까지 워크플로우가 생긴 과정을 살펴보자.
과거의 개발
옛날 옛날, 전통적인 개발방식은 지금의 대학생의 팀플과 똑같았다. 교수(관리직)가 과제(결과물)를 데드라인과 함께 주고 팀장 주도하에 각각의 업무를 나누고 할당하고 보고하고 종합하고...
이 과정에서 단점들은 크게 4가지로 나타났다.
1.
문서(보고와 책임소지를 위한)를 중시함
2.
갑, 을 문화가 강하다.
3.
실패를 통제의 문제로 치부한다.
4.
변경사항의 적용에 취약하다
복잡하게 써 두었지만 결국 뭐가 문제였냐면 일이 잘못되었을 때의 책임소지를 명확히 하기 위해서 비효율적인 프로세스가 많았고 이는 작업의 딜레이, 저녁이 없는 개발자를 만들었다.
애자일
위와 같은 문제를 해결해보고자 애자일이 2001년에 선언되었다. 애자일이 뭐고 뭐고 하는 것은 블로그나 책에 많이 정리되어있으니 그걸 참고하면 된다. 결국 애자일이란것이 뭐냐면 모든 팀의 작업이 한 곳을 바라보고 협력(cooperation)이 아닌 협업(collaboration)하기 위한 방법론이다. 이에 따라 생긴 애자일의 가장 중요한 핵심은 스프린트(sprint)와 스크럼(scrum)이다.
정해진 스프린트동안 모든 팀(개발 뿐만 아닌 모든 부서가)이 하나의 결과물을 위해 작업을 할당하여 진행한다. 이를 위해서 작업을 분배하고 사항을 공유하는 시간이 요구되는데 그게 스크럼이다. 원칙적으로 스크럼은 10 ~ 15분 내외의 짧은 시간동안 이루어져야 하는데 불필요 프로세스를 줄이고 작업을 진행하기 위함이다.
애자일은 상당히 효율적인 프로세스지만 몇개의 문제가 발생한다.
1.
책임 소지가 불명확하다. 즉 모든 팀이 책임을 동시에 지고 간다.
2.
개발자 위주의 방식이다 보니 호흡이 빨라 다른 팀에 부하가 걸린다
3.
짧은 회의에서 오는 팀간 소통이 생각보다 잘 이루어지지 않는다
Devops
이러한 과제들은 기존의 전통방식의 도입과 프로세스의 자동화를 요구 하였고 데브옵스가 등장하였다. 기존의 프로세스에 커뮤니케이션시스템과 자동화를 도입하면서 운영(ops)과 개발(dev)를 합친 것이다. 애자일과 마찬가지로 데브옵스의 내용이 궁금하다면 블로그나 책을 찾아보자
작은 프로젝트에서
서론
결국 데브옵스는 뭐냐면 협업하다가 안되는게 너무 많아서 이것 저것 정해보다보니 만들어진 지금 상황에서 가장 괜찮는 협업 방법론인 것이다. 사실 데브옵스의 수많은 원칙과 툴들은 엔터프라이즈급을 위한 전략이다. 그래서 토이급 작은 프로젝트에선 오버스펙인 경우가 대부분이다. 따라서 우리는 데브옵스가 만들어진 과정을 거치면서 뭐가 필요한지 느껴보고 직접 만들어보는 것이 중요하다.
1단계 필요성 느끼기
그래서 이런 방법론의 필요성을 느끼기 위한 가장 좋은방법은 협업을 맨땅에서 부딪혀보는 것이다. 그러면 대학생때 협업과 다를게 없어질 수 도 있다. 그래서 딱 3개만 첨가하면 된다.
1.
git branch 전략 사용하기
2.
issue로 대화하고 pr로 리뷰하기
3.
프론트, 백을 완전히 분리하기
그리고 이왕이면 팀원이 부서당 4명 이상인게 좋다. 그래야 소통이 안되는 걸 느끼기 좋다. 만약 처음할 때 이 상황에서 소통이 잘되고 있다고 느낀다면 둘 중 하나이다. 대부분의 사항을 카톡으로 대화하고 있거나 작업이 너무 간단해서 착각하고 있거나. 물론 팀원들이 다 너무 잘 맞아서 잘 될 수도 있지만 만약 그렇다면 다같이 손잡고 프리랜서 개발 회사를 만들면된다. 여하간 이런 경험을 거쳐보는것이 가장 확실한 방법이라 생각한다.
2단계 워크 가이드 문서 작성하기
프로젝트에서 생기는 문제점들을 정의하고 해당 문제를 해결하기 위한 가이드 문서를 작성해 보자. 회의록 작성 요령이 될 수 도 있고, 이슈 발급 가이드가 될 수도 있다. 이런 문서를 적어서 팀에 적용해보자. 그럼 해당 내용이 어느정도 해소되고 새로운 문제들이 보이기 시작할 것이다. 그럼 그 문제를 해결할 방법을 또 문서화하고 팀에 적용한다. 이런 작업을 통해 일종의 데브옵스를 직접 만들어보는 것이다.
3단계 새 프로젝트에 해당 방식을 처음부터 적용하기
이제는 새 프로젝트를 시작할 때 앞선 프로젝트에서 미리 적용되었으면 좋았을 것들을 미리미리 적용해보는 것이다. 그러면 좀 더 나은 적용과 또 다른 문제점들이 보일것이다. 사실 적은 것처럼 문제는 아무리 가이드를 잘 작성해도 발생한다. 어떤 상황에선 해결법이었던 가이드가 반대로 문제가 되는 상황도 있다. 완벽한 가이드 문서란 존재할 수 없지만 해결 하는 과정에서 좀 더 나은 프로젝트를 위한 방법론을 고민하게 될 것이다.
아래 문서들은 내가 작성한 가이드나 개발 환경 셋팅 관련 문서이다. Jira링크는 접속할 수 없음에 유의하자.
