프로젝트 성격에 맞는 버전 관리 전략 채택, 그리고 그에 맞는 git 사용 방법 정리하기
IT 프로젝트를 수행하는데 있어 선택할 수 있는 전략이나 스택은 다양하고, 매 순간 순간이 선택과 결정의 연속이다.
최근에는 그 동안 쿠버네티스에 배포해놓은 애플리케이션을 관리하기 위해 IaC로써 Pulumi를 사용했는데, MLOps 뿐만 아니라 우리 팀이 소속되어 있는 인프라팀의 모든 애플리케이션을 이 pulumi로 통합 배포를 하기 위해 리팩토링하는 기간을 가지게 되었다.
그 동안은 팀원 개개인이 개별적으로 작업하고 배포했다면, 이제는 늘어나는 애플리케이션 및 코딩 컨벤션의 통합 관리의 필요성이 팀 내에서 제기 되었고, 이에 맞춰 팀에서 원활한 작업을 위해 몇 가지 전략을 합의하게 되었다.
1. git flow
팀원 개별적으로 Pulumi로 코드를 통합하기에 앞서, 각자 작업한 사항들을 관리하는 방법에 대한 논의가 이뤄졌고, git flow와 github flow에 대해 얘기가 나오게 되었다.
두 전략은 이미 개발자들에게 충분히 잘 알려져 있기 때문에 필요한 부분만 요약하자면,
git flow는 브랜치를 크게 4가지로 나누어 개발하는 전략으로
- Main, develop, Feature, Release, Hotfix
위와 같은 branch로 나눠 관리할 수 있다.
여기서 중심이 되는 branch는 master와 develop이고, merge된 feature, release, hotfix branch는 삭제할 수 있게 관리한다.
Git-flow 전략은 일정 주기를 갖고 서비스를 배포를 해야하는 프로젝트에는 적합한 전략으로 취급될 수 있다.
우아한 형제들에서 이미 너무나 잘 알려진 블로그 글에서 해당 사항에 대해 잘 설명하고 있기 때문에 더 자세한 내용을 알고 싶은 사람들은 이 글을 참조해 보는 것을 추천한다.
이와 같은 브랜치 전략은 직접적으로 github에 들어가면 다음과 같은 형태로 branch가 관리되고 있는 것을 확인할 수 있다.
2. github flow
git flow와 비교의 대상이 되는 것은 github flow다.
github에서 제안하는 협업 방식으로, git flow에 비해 상대적으로 branch를 관리하기 편리하고 hotfix & feature branch를 구분하지 않고 Pull Request를 사용하여 코드 리뷰를 통해 merge하는 것을 권장하고 있다.
또한 배포가 잦은 프로젝트의 경우, 아래 이미지처럼 배포 버전 태그를 함께 적용해서 배포하는 것이 가능하며, flow 내부에 자동화 개념이 포함되어 있어 CI와 배포가 자동화되어있는 프로젝트에 유용하다.
3. 어떤 flow 전략을 선택할 것인가?
전략을 선택하기 위해서는 팀에서 현재 가용 중인 자원들이 어떻게 운영되고 있는지에 대해 명확한 분석이 필요했다.
- 몇 몇 애플리케이션의 경우, 일정 주기를 갖고 배포하기보다 수시로 배포하는 작업이 진행되고 있다 (jupyterhub, flyte)
- github action으로 main으로 merge 될 때마다 pulumi 배포 코드가 실행된다.
- 작업물을 관리할 때, Jira Ticket으로 branch가 생성되어 관리가 이뤄지고 있다. (즉, develop, hotfix, feature등 branch 가 필요로 해보이지 않는다)
- 리팩토링 작업물을 수합하여 하나의 pulumi 통합 배포 프로젝트를 구성하는 과정이기 때문에 꼼꼼한 코드 리뷰가 작업 관리 과정에서 포함되어야 한다. (즉, PR로 코드 리뷰 과정이 flow에 포함되어야함)
다음 사항들을 꼼꼼히 따지다 보니, github flow로 작업을 관리하자는 의견으로 결정이 되었고, 본격적인 작업을 수행할 수 있게 되었다.
위의 팀 내 고려 사항들 중에서 가장 크게 고려했던 것은, 몇 몇 애플리케이션의 수시 배포 문제였고, 그 덕분에 github flow가 선택의 우선 요소로 결정되었다.
우아한 형제들을 통해 git-flow가 잘 알려지게 되면서, 나도 개발자 취업 전에는 지속적으로 git flow에 대해서만 알고 있었기 때문에 팀과 프로젝트에 적합한 flow를 선택하는 과정을 생각해 본 적이 없었다.
이 글에서는 언급되지 않았지만, gitlab flow라는 것도 있기 때문에 개발을 하는 것에 있어 단순히 코드를 작성하는 것보다 상황에 맞는 다양한 관리 전략을 취하는 것은 프로젝트에서 대단히 중요한 요소라고 생각된다.
(한 번 선택한 기술 스택이나 전략은 이후에 변경하기 무척 어렵고, 우리는 이것을 기술 부채라고 부른다)
4. 정리 ( + 최근 회고)
요즘 들어 개발하는 과정이 부쩍 Problem-Solving 과정 그 자체라는 생각을 하게 된다.
취업 준비할 땐, 취업 포트폴리오 준비하랴, 코딩 테스트 준비하랴, 면접 준비하랴 정신이 없어서 코드 짜고, 준비한 프로젝트에 대한 설계 과정 작성하랴 정신 없었는데, 막상 취업하고 보니 주어진 문제를 무엇을 통해 얼마나 적절하게 해결했는지가 프로세스의 거의 대다수를 차지하고 있다.
코드를 작성하는 것은 이 문제를 해결하는 여러 수단 중 하나다.
최근에 AI 관련 프로젝트 경험을 더 깊이 있게 참여하고 싶어, 현대 자동차 연구 개발본부 AI 경진대회 최종 합격 통보를 받았다 (아래 예비 합격 대상자 연락 이후, 최종 합격 연락이 왔다.)
반차 내고 꽤 어려웠던 알고리즘 테스트 보고 합격한 거라 매우 뿌듯했지만, 결국 회사 업무 일정하고 경진대회 일정이 안 맞아 (현대차에서 멘토를 붙여주는데, 낮 시간대만 일정 진행이 가능하다고 한다) 결국 대회 진행에 참여는 못했다.
대회 참여가 어려울 것 같다는 답변을 하고 나서, 현타가 조금 쎄게 왔다가 최근 회사 업무 전략을 세우는 것과 함께 차분히 생각해보니, 이런 기업 과제 없이 내 스스로 문제를 인식하고 해결책을 제시하는 프로젝트를 수행해야겠다는 생각이 들었다.
이런 경진대회는 내가 풀고자하는 문제가 아니라, 남이 풀고자하는 문제다.
학교 다니면서 이런 저런 경진대회들을 많이 참여했지만, 내가 풀고자하는 문제에 대해 곰곰히 생각해보고 기간을 할애하여 해결해 나가는 능동적인 프로세스를 정립해보자.
Ryan
