대규모 프로젝트에서의 Git 구성 전략

200명 이상의 개발자가 투입되는 대규모 프로젝트에서 형상관리도구로 Git을 사용함에 있어서 주의할점과 구성 전략에 대한 포스트를 작성해 본다. 저보다 훨씬 더 경험이 많은 시니어 개발자나 SWA 분들께서 Git 전략에 대한 노하우가 있다면 공유되기를 바라는 마음에 어설프고 재주가 없지만 포스팅을 하려한다.

투입되는 개발자의 git 숙달 수준

프로젝트 기간이 길면 이 조건은 큰 상관이 없을 것 같다. 하지만 우리나라 SI 프로젝트 현실상 매우 짧은 납기로 인해 개발자들이 어떤 도구를 학습하면 프로젝트를 진행하기란 쉽지 않다. 그런한 기간 까지도 금액으로 산정이 되니까.

git에 익숙한 인원의 규모가 30% 미만이라면 git을 형상 관리 도구로 사용함에 있어 진중히 다시 고민 해보아야 한다. 소규모 프로젝트라면 의쌰의쌰 해가면서 의사소통을 해가면서 어떻게든 꾸려갈수 있으리라 예상된다만 대규모 프로젝트는 상황이 다르다. 수백명의 개발자가 서로의 소스를 git branch를 관리하지 못해 발생하는 문제와 싸우다보면 진짜 중요한 Task를 진행해야 할 시기에 형상관리도구와 싸우고 있게 될 것이다.

git에 익숙한 인원의 규모가 50% 미만이라면 어느 정도 프로젝트를 이행해 나갈 수 있을 것이다. 간소화된 브랜치 전략으로 개발자의 혼선을 막고 과거에 많이 사용하던 svn이나 cvs 같은 방식을 유사하게 구성해주는 것이 포인트다. 이정도 규모가 되면 key developer가 두각을 드러내며 주위에 전파 교육이 충분히 가능하다.

git에 익숙한 인원의 규모가 50% 이상만 되면, 이제 구글링해서 나오는 git-flow나 브랜치 전략 등에 관한 글의 내용을 적용해 볼 수 있겠다. 이러한 글들은 다분히 이상적이고 국내 SI 프로젝트와는 괴리감이 있다고 생각된다. 어느 부분이 괴리감이 느껴지는지 배포 및 브랜치 관리에서 구체적으로 설명할 예정이다. 그래도 feature 단위의 branch 생성과 branch들에 대한 merge 등을 해 볼 수 있겠다.

Git-Flow

git-flow를 검색하면 아래와 같은 유명한 그림이 있다. git-flow를 설명하는데 이해하기 아주 쉬운 그림이라는데 이견이 없다.

이 git-flow를 대형 SI 프로젝트에 적용하였을 때 문제를 공유하고자 한다. 위 그림에서 빨간색 네모 표시한 곳을 주목하자. 개발 브랜치를 릴리즈 브랜치로 바로 merge 한다. 이것은 개발브랜치의 모든 내용이 릴리즈브랜치에 반영된다. 이 이야기는 모든 개발중인 feature는 완료가 되어야 릴리즈 브랜치로 merge 할수 있다는 이야기다. 개발중인 기능을 릴리즈 할 수는 없지 않은가? 결국 하나의 기능만 개발하여 완료하고 릴리즈 칠 수 없는 구조다. 개발과 릴리즈 브랜치 사이에 테스트/QA 등의 브랜치가 추가 되어도 상황은 마찬가지이다. 개발 브랜치가 merge 되는 순간 개발중이던 미완성의 기능이 테스트/QA/릴리즈 브랜치 모두 전파된다. 이를 해결하기 위해 아래에서 설명할 릴리즈 브랜치의 완벽한 격리 또는 릴리즈 브랜치로 부터 파생시킨 feature 브랜치를 철저히 관리하는 방법이 있다. 후자의 경우 개발자의 feature branch 관리능력이 상당히 요구된다.

위 그림과 같이 feature는 development에서 파생시키는 것이 아닌 테스트/AQ에서 파생시킨다. development 브랜치에 merge를 시켜서 개발서버에서 테스트 해볼 수 있다. 그리고 이상없이 개발이 완료되면 해당 feature 브랜치를 테스트/QA 브랜치에 merge 한다. 릴리즈 브랜치에는 검증이 완료되면 해당 feature 브랜치를 merge 함으로써 배포 시키는 방법 또는 해당 feature가 포함된 테스트/QA 브랜치를 merge 함으로써 배포 할 수 있겠다. 이러한 방식이 항상 옳다는 건 아니다. 국내 SI 프로젝트의 개발 프로세스를 따라가려고 하면 이와 같은 구조가 필요하다는 것을 말하고 싶다.

배포 방식 합의

국내 대규모 SI 프로젝트에서 MSA가 아닌 아키텍처에서 CI/CD를 구성해서 사용하는 사례가 있는지 모르겠다. 개발서버까지는 자동배포가 되며 테스트서버부터는 통제를 하기를 원한다. 배포가 되는 대상(파일)을 배포 요청을 하고 배포 시스템에서는 배포 프로세스를 모두 준수하였는지 검사하고(정적분석, 테스트커버리지, 보안점검 등) 이상이 없으면 승인자에 의해 배포되는 형식이다. 이러한 파일단위의 배포 형식이 git으로 구현하기가 만만치 않다. 일단 개발자들이 친숙한 GUI 도구에서 파일단위로 제어를 하기가 쉽지 않다. SVN 등에서 사용했던 파일 단위의 리비전 관리나 라벨 등록등이 git에서 직관적으로 구현하기가 적어도 내가 아는 선에선 어렵다.

따라서, 프로젝트 초기부터 배포 방식을 어떻게 가져갈 것인가를 확실히 정하고 그것에 따라 git 도입 여부의 중요한 조건이 될 수 있다. 그러한 배포 방식 때문에 git이 전혀 어울리지 않는 형상도구일 수도 있다.