.NET 개발자로서의 협업 - 1

닷넷이라는 플랫폼을 처음 접한게 2005년이니까 벌써 만 10년이 넘게 닷넷 플랫폼으로 밥을 벌어먹고 살고 있다. 그동안 진행했던 프로젝트들도 수십건이 넘고, 그때마다 독고 솔로 개발을 하는게 아니다보니, 팀 단위의 협업을 하게되는데 그동안 협업을 하면서 느꼈던 점들, 그리고 현재 나는 그때와 어떻게 달라졌는지에 대한 잡설을 조금 풀어보고자 한다.

• 형상관리

취미로 PHP 나 ASP 를 깔짝이던 시절에는 혼자서 북치고 장구치는 독고다보니 형상관리라는 개념자체도 없었고, 필요성도 전혀 느낄수가 없었다. 혹여 백업이 필요하면 일자별로 폴더를 만들어서 백업할 소스들을 보관하는 식이었는데, 혼자 작업을 하다 보니, 백업할 소스들만 선택해서 백업을 하기가 귀찮아서 그냥 프로젝트 폴더 전체를 백업하곤 했었다. 이런 단순한 노동(이라고 읽고 노가다라고 쓴다)이 귀찮고 번거로왔지, 혹여 소스가 롤백된다거나 어딘가에서 소스가 누락되거나 더미가 남아서 고생했던 기억은 없다. 너무나 당연하게도 혼자서 하는 작업이 주다보니, 소스라인을 줄줄 꿰며 어느 라인에 어느 코드가 있다는 수준까진 아니었지만, 소스의 무결성에 대한 걱정 혹은 이슈는 없었던 것 같다.

취미로 하던 개발이 취업을 하게되면서 일이 되고,  첫회사에서 닷넷이라는 플랫폼. 비주얼 스튜디오라는 IDE, NT 서버를 접하게 되었다. 그리고, 이미 그 시절에도 슬슬 퇴물이 되어가는 VSS라는 SCM을 처음 사용하게 되었는데, 난생 처음으로 팀단위의 프로젝트를 하게된 나에게는 신기방기하고도 안전하고 편리한 툴이었던 것으로 기억 된다. 중앙집중식에 파일단위의 락. 그야말로 강려크한! SCM이었지만, 아이러니하게도 그 강려크함이 팀작업에서는 이루말 할 수 없는 불편함들이 되는 경험을 한적이 많았다. 커밋이라는 개념자체가 없었고 당연히 병합(Merge)이라는 개념도 없는...순수한 파일락 방식의 SCM은 누군가에겐 마음의 안정을 가져오게 하는 툴이었지만, 나와같은 누군가에게는 복창터지는 답답함을 안겨주기에 충분했다. 그마저도 제대로 이해하고 있는 사람이 없었서 각종 참조 라이브러리와 바이너리 폴더(+파일)들까지 체크인하는 통에 이미 VSS는 소스를 관리하는 툴로써의 기능(협업을 위한 도구로써의 기능)은 상실한 상태였다. 심지어 신규 입사자가 VSS 서버에서 소스를 내려받고 빌드 가능한 상태까지 만드는데까지(혹은 팀의 개발 싱크를 맞추기 위한 시간까지) 며칠씩 걸리기도 일쑤 였다.  MS 개발자(특히 닷넷 플랫폼)들은 셋트 아이템이라도 맞춘냥 형상관리를 거지같은 VSS로 끼워 맞추는 기현상을 몇번의 이직을 거친 2014년도까지 접할 수 있게 되었다.

그러다가 접하게 된 SVN은 처음 VSS를 마주했을때 만큼은 아니었지만 그야말로 신선한 충격이었다. 하나의 무결성 소스로 서로의 작업(진정한 의미의 협업)을 하고, 서버로의 반영도 파일락이 아닌 커밋 단위로 서버에 반영하며, 작업한 각각의 분량은 병합을 하는 방식. 이제야 제대로 협업을 한다는 느낌을 받았었다. 하지만, 주위에는 여전히 SCM 따위 먹는건가요? 를 시전하는 사람들이 많았고, 여전히 각종 참조 바이너리와 빌드 후 생성되는 바이너리들을 신주단지 모시듯, 불필요한 파일까지 커밋하는 혼돈의 카오스 상황이었다. SVN 은 VSS에 비하면 신세경급의 SCM이었지만, 브랜치 관리가 여전히 부실해 보였다. 다른 팀원의 작업물을 내 로컬로 업데이트라도 할때면, 개발자들이 만들어 놓은 브랜치들이 중구난방으로 내 PC로 쏟아져 들어오는 왔다. 제법 큰 대형 솔루션에 브랜치가 2-3개라도 만들어져 있으면, 내 컴퓨터의 모든 자원이 서버로부터 싱크하느라 사용될 지경(PC 가 구렸을까? 아님 TortoiseSVN이 문제였을까? 아직 미스테리)이었으니...어느 순간부터는 소스 업데이트하기가 무서워(?)졌다. 중앙집중식으로 자원관리를 하는 다른 SCM도 도낀개낀이라 그러려니 해야지 별수있나?

여하튼, 2년전쯤부터는 Git 을 사용하고 있는데, 기본적으로 분산 버전 관리 시스템 기반이다보니, 실제 프로젝트를 운영함에 있어서 이와 같은 방식이 개발/운영 플로우를 좀더 유연하게 대처할 수 있다는 점이 가장 좋았다. Git Flow 라 불리는 도구가 좋다고 하지만, 사내에서의 브랜치 관리를 그 정도로 세분화 필요는 없어서, 현재는 Git Flow 에서 일부 차용해서 브랜치를 운영하고 있다. 사실 Flow 라 할것도 없는 가장 베이직의 형태로 운영중이다.

1. 라이브 배포버전의 master 브랜치
2. 개발/스테이지 배포버전의 develop 브랜치

각종 feature 나 hotfix 등은 개발자 로컬에서 브랜칭한뒤, develop 브랜치로 각자 Push 하는 베이직한 방식이다. 라이브 배포버전은 반드시 master 브랜치로만 하고, 이 master 브랜치는 일반 개발자들에게 Protected 격리수준으로 설정하여 안전하게 보호하고 있다. develop 브랜치를 master 병합할 땐 반드시 GitLab 의 Merge Request (Github의 PullReqeust)하며, 반드시 관리자가 코드리뷰를 하고 병합하도록 하고 있다. 단, 다수의 기능 추가가 동시다발적으로 이뤄지고 있고, 각각의 기능에 대한 검수가 많아지면 develop2, develop3 와 같은 별도의 디벨롭 브랜치를 추가로 운영하여, 개발/스테이지 서버로의 배포를 좀 더 유연하게 하도록 하여, 기획부서와의 업무를 조율하고 있다.

여기서 Gitlab 얘기를 안할 수 없다. 이미 소셜 코딩이 대세라고들 하여, Github이라는 훌륭한 서비스가 존재하며 많은 기업들이 Github을 이용해서 형상관리를 하고 있는 것으로 알고 있다.  (오픈소스 진영에서는 이제 Github 없이 개발하는 거 자체가 불가능할 정도) 하지만, Github을 돈주고 쓰기엔 부담스럽거나, 혹은 소스가 외부에 노출되는게 꺼려지는 사람들도 있을 것이다. Github 엔터프라이즈를 구매하여 Private한 Giuhub을 구축하는 방법도 있겠지만, 예산이 풍족하지 않은 기업이나 단체에서라면 Github 과 같은 웹 UI를 제공하며, 그에 준하는 여타의 솔루션도 함께 제공하는 Gitlab을 꼭 써보길 바란다. Commuity Edition 은 무료이면서, 리파지터리의 갯수를 제한하는 등의 꼼수가 없다. 부가적으로 위키 및 이슈 트래커, Code Snippet도 제공하니 Git 도입을 하고자 한다면, GitLab 도 함께 도입하길 강력히 추천한다. 이전 6.x 버전은 설치하기가 굉장히 까다로왔는데 최근 버전은 설치과정이 굉장히 심플해져서 원스톱으로 설치되니까, 리눅스를 잘 모르는 사람들도 쉽게 설치하고 사용할 수 있어서 편리하다. 내 경우 코드리뷰시 Merge Request를 활용하고 있는데 변경 로그확인이 깔끔하고 한눈에 들어오며, 변경된 코드나 특정 소스영역에 코멘트를 달아서, 코드 리뷰를 하거나 요구사항을 전달할 수 있어서 좋다. 최근에는 CI 지 통합되었는데 뭐 Unix 계열 플랫폼의 개발자자면 모를까 일반적인 닷넷 개발자들에게는 필요가 없기 때문에 안쓴다. -_- (사실, 아직은 젠킨스등에 비하면 갈 길이 멀어보인다.) 그외에도 각종 서비스들과의 통합도 가능해서 Slack 등을 통해서 Commit/Push/Issue/Milestone 등에 대한 알림을 받을 수도 있고, 반대로 젠킨스 등에서도 변경 로그는 GitLab으로 링크를 해주는 기능이 있어서, 다른 서비스들과의 케미도 좋은 편이다. 그러니, Git은 도입했는데, 팀원들이 여전히 힘들어하고, 관리 포인트를 어떻게 잡아야 할지 고민되는 분들이 계시다면, 꼭한번 써보라고 추천해주고 싶다.

어영부영 글을 쓰다보니, 두서없는 글이된 것 같아서 협업에 대한 첫번째 얘기는 여기까지 하기로 해야겠다. (사실, 월급 루팡이 되는것 같아서...크큭)