스타트업 개발문화 도입기 -상-
CTO로 스타트업에서 살아남기 2편
스타트업의 개발문화란?
회사를 처음 창업했을 때 CTO로서 무엇을 해야하는지 알지 못했다. 단순히 서비스 잘 만들고 새로 들어온 개발자들을 잘 키우면 된다고 생각했다. 사실 회사를 다녀본적없는 나에게는 개발문화란 말도 들어보지 못했다..?? 그래도 다행인지 아닌지 회사라면 무릇 인트라넷을 가져야한다는 생각은 가지고 있었다. 연구실 서랍에서 먼지만 쌓여가던 나스를 발견해 설치하고 나름 인트라넷이라는 이름의 사내 서버를 하나 구축했다. (물론 이게 인트라넷을 아니지만 비스무리한거라 생각했다.)
그렇게 나스를 이용해 공용 클라우드를 구축했고 사장님과 나, 재무담당자분의 권한을 나누어 비밀 문서함도 만들었다. 놀라운건 나스에 깃서버와 SVN서버를 제공했는데 SVN서버를 선택하여 설치했다. 기존 연구실 인력과 새로온 친구들에게 모두 해당 SVN에 코드를 업로드하자고 약속했지만 당연하게도 아무도 지키지 않았다. 모두 자신이 직접 코드를 관리했고 나 또한 강력하게 푸시하지 않았다.
이때 난 두 가지 실수를 했는데, 단순히 SVN을 이용하라고만 한점, 버전관리의 중요성을 그냥 이야기로만 알고 있었다는 점이었다.
갑자기 내용이 다른 방향으로 흘렀지만 스타트업에서 개발문화는 매우 중요한 부분이다. 자본이 충분하지 않기때문에 훌륭한 개발자와 함께 일하기 위해 필수적인 요소라 생각한다. 주관적인 생각이지만 개발자가 스타트업을 선택할 때 첫째로 개발문화를 둘째로 연봉을 보고 선택했으면 좋겠다고 생각한다. 이런 이유는 개발문화 자체가 개발자 모두의 성장을 도모하며 서비스의 완성도와 밀접하게 이어지기 때문이다.
그럼 이제부터 본격적으로 내가 구축해 나간 개발 문화에 대해 이야기 해보겠다.
버전관리와 Git Lab 도입
개발문화에 대한 고민을 하기 시작할 때 쯤, 가장 처음 해야겠다 맘먹었던 일은 git을 이용한 버전관리를 전사적으로 도입하는 일이었다. 물론 전사적이라고 말해봤자 많지는 않았지만 연구실에서 수행하는 과제와 회사에서 진행하는 프로젝트 모두 적용하는 것을 1차적인 목표로 삼았다.
연구실에서 오래전에 사용하다 방치되어있던 PC한대를 이용하여 리눅스 서버를 구축했다. github를 이용하고 싶었지만 온프레미스형식으로 제공하는 서비스가 없어 gitlab을 사용하기로 결정하고 서버 어플리케이션을 설치했다. (나름 기술 연구를 수행하는 회사로서 보안을 위한 내부망에 설치하고자 이런 방법을 선택했지만 지금은 서버관리와 몇가지 리스크를 줄이기위해 github로 이전하여 사용하고 있다.)
물론 git의 도입과 개발문화가 무슨 연관이있지? 라고 생각할 수 있다. git은 개발문화를 만들어가는 가장 기초적이고 필수적인 요소라고 생각했다. 물론 git이 없다고 해서 좋은 개발문화를 만들 수 없다고 말할 수는 없지만 좋은 개발문화를 쉽게 만들어줄 수 있는 기본 요소라고 생각한다.
gitlab을 도입하고 git-flow라는 브랜치 관리 전략을 선택했다. git flow에 대해서는 설명하자면 길지만 git과 git-flow를 도입하면서 그래도 개발팀이 조금은 체계적이 되었다, 라 느낄 수 있었다.
애자일이라 쓰고 지라라 읽는다.
최근에는 간간히 "애자일은 허상이야!" 이라고 말하는 사람들이 보인다. 물론 그들의 의견에 어느정도 동조하는 부분도 있다. 하지만 우리는 애자일을 충실히 수행하고자 도입했다. 애자일 프레임워크중 스크럼을 도입했고 우리만의 방식으로 해석하여 사용하고 있다. 스크럼 프레임워크를 가장 잘 표현해준 협업툴인 지라를 이 때 같이 도입했다. 지라를 도입하고 정해진 스프린트 기간내에 목표를 달성하기 위해 퍼포먼스를 보이고, 목표를 해결했을 때의 쾌감이 마치 게임의 퀘스트를 깨는것 같았다.
아, 다양한 툴이 있는데 그 중 내가 지라를 도입한 이유는 매우 강력하고 원하는 기능을 내포하고 있었기 때문이다. 칸반과 함께 스프린트 설정, 담당자, 버전설정등 다양하게 설정하고 업무의 스펙을 전달해 줄 수 있었다. 이런 스프린트 기간에 보고서를 제공해주는 기능 또한 매력적이었다.
애자일을 도입하고 지라를 사용하면서 보다 명확한 업무 프로세스를 만들어야겠다 생각했다. 그래서 4단계의 업무 프로세스를 구성했다.
1. 할일 : 프로덕트 오너 또는 팀장이 각각 개발자에게 할 일을 할당 (보통 스프린트를 시작할때 한번에 할당해준다.)
2. 수행 : 실제 할당받은 기능을 구현하거나 버그를 수정한다.
3. 리뷰 : 완료한 기능에 대한 PR을 날리고 리뷰를 받는다. (해당 영역이 개발문화의 꽃 중 하나!!)
4. 완료 : PR이 머지되고 업무는 완료된다.
위의 4단계의 프로세스를 도입하면서 보다 체계적이고 시스템을 갖춰졌다는 생각이 들었다. 물론 나만의 생각일 수도....있겠지만, 누가 어떤일을 하고 어느정도 수행했으며 함께 목표를 향해 달려간다는 팀 스피릿을 심어주기 충분했다 생각한다.
사실 개발문화에 대한 내용을 한편에 정리하려 했지만 역시나 분량에 실패하고 말았다.. 최대한 상, 하편으로 나누겠지만 또 분량에 실패한다면 상중하로 나눌 수 있도록 해야겠다. 그럼 이번편은 여기서 마무리.
