1. Issue

Harpy chat 서비스는 Git Flow 전략을 따르고 있었다.

그런데, 하나의 Feature 개발을 위해 여러 브랜치를 생성해야 될 때가 있다.

작업들이 톱니바퀴 맞물리듯 깔끔하게 나누어 떨어지고, 하나의 브랜치 작업이 끝난 이후 다시 그 브랜치에 추가적으로 작업을 해야할 일이 없다면 정말 좋겠지만 현실은 그렇지 않다.

기획이나 디자인이 변경되는 것은 항상 있는 일이고, 때로는 작업자체가 깔끔하게 떨어지지 않는 경우도 많다.

이런 경우 이른바 Merge hell(수 많은 브랜치마다 conflict를 수동으로 merge해야하는 상황)이 발생하곤 한다.

이렇게 기존 Git flow 한계점을 느끼게 되어, git flow 및 다른 버전 관리 전략에 대해 생각해볼 필요성을 느끼게 되었다.

2. 버전 관리 전략에 대한 이해

1) Git flow

Git Flow는 Vincent Driessen이 2010년에 제시한 Git 브랜치 전략이다.

git flow의 핵심은 main, develop을 따로 두고 운영하는 데에 있다.

이렇게 함으로써, 프로덕션(main) 브랜치를 보다 안정적으로 관리할 수 있다.

이외에 hotfix, release, feature 브랜치를 통해 새로운 기능을 추가할 수 있다.

한계

Merge hell

이런 git flow를 경험하며 체감한 가장 큰 단점은 merge hell이다.

서로 다른 두개의 브랜치에서 같은 파일을 작업하게 되면, merge conflict가 자주 발생한다.

이러한 conflict는 반드시 수동으로 merge 해줘야 하는데, 이는 휴먼에러를 유발하고 개발생산성을 크게 저해한다.

Code reivew

Git Flow에서 각 브랜치에 대해 PR(Pull Request)을 올리고 코드 리뷰를 진행하는 과정에서, 브랜치가 많아질수록 리뷰어의 부담이 커진다. 특히, 각 브랜치가 오래 지속되면 변경사항이 많아져 코드 리뷰의 품질이 떨어질 수 있다.

복잡성 증가

또한 여러 개의 브랜치를 관리해야 하므로 프로젝트의 복잡성이 증가한다. 특히, 릴리즈 주기가 길어질수록 브랜치 간의 차이가 커져 통합 시 많은 문제가 발생할 수 있다.

2) TBD(Trunk-based-development)

TBD의 핵심은 팀원이 공유하는 무한수명 브랜치가 단 하나라는 점이다.

main 브랜치 안정화를 위해 develop 등의 브랜치를 따로 두지 않고, 있더라도 short-loved 한다.

특징

• 잦은 빈도의 통합: 모든 변경 사항을 가능한 한 빨리 trunk에 병합한다.
• 짧은 피드백 루프: 작은 단위의 변경 사항에 대해 빠르게 피드백을 받는다.
• 강력한 자동화 테스트: 자동화된 테스트를 통해 코드의 안정성을 보장한다.

요구 사항

• TBD에 대한 이해와 컨벤션 합의 : 작은 단위의 커밋을 통해 merge conflicts를 최소화할 수 있다.
• 코드리뷰!! : 코드리뷰가 모든 작업의 최우선 과제.
• 필수적인 강력한 자동화된 테스트: 어떤 커밋이 빌드 및 기능에 에러를 유발하는지 자동화된 테스트를 통해 감지해야 한다.
• 지속적 통합: 지속적 통합(CI) 시스템을 통해 자동으로 테스트하고 배포하는 프로세스를 구축해야 한다.

장점

• 빠른 피드백: 작은 단위의 변경 사항에 대해 즉각적인 피드백을 받을 수 있으며, 기능을 더 빠르게 릴리즈할 수 있어 고객에게 가치를 더 빨리 전달할 수 있다.
• 애자일: 더 빠르고 유연하게 작업할 수 있다.

한계

• 작은 단위 커밋 필요: 개발자가 작은 단위로 자주 커밋해야 하므로 초기 적응이 필요하다.
• 자동화된 테스트 인프라 필요: 강력한 테스트 자동화 시스템이 필요하다.

3. Git Flow vs TBD

merge hell에 관련해 대안 전략인 TBD에 대해 알아보았다.

Git flow는 Main branch의 안정성을 최우선에 두고 있고,
TBD는 빠른고 지속적인 릴리즈를 최우선 가치로 두고 있다는 데서 큰 차이점이 있었다.

그렇다면 어떤 기준을 통해 버전 관리 전략을 선택해야 할까?
정리해본 주요 기준은 다음과 같다.

릴리즈 빈도

지속적이고 신속한 릴리즈가 필요하다면 TBD가 적절하다. 작은 단위의 커밋과 빠른 통합을 통해 지속적인 배포를 가능하게 한다.

서비스 규모

기본적으로 프로젝트나 서비스의 규모가 크다면 Git Flow, 그렇지 않다면 TBD가 좀 더 적절하다. 대규모 프로젝트에서는 Git Flow가 더 구조적이고 안정적으로 관리할 수 있는 반면, 소규모 프로젝트에서는 TBD가 더 민첩하고 효율적일 수 있다.

팀의 성숙도와 문화

팀이 얼마나 자동화된 테스트와 지속적 통합(CI)에 익숙한지, 그리고 작은 단위의 커밋을 자주 할 수 있는 문화를 가지고 있는지도 중요한 고려 사항이다. TBD는 높은 수준의 자동화와 테스트 인프라가 필요하지만, 이러한 환경이 갖추어져 있다면 더 빠르고 안정적인 개발을 가능하게 한다.

복잡한 기능 개발

복잡한 기능을 개발할 때는 Git Flow가 더 유리할 수 있다. 여러 브랜치를 통해 기능을 나누고, 충분히 테스트한 후 통합할 수 있기 때문이다. 반면, 단순하고 자주 변하는 기능 개발에는 TBD가 더 적합하다.

4. STBD(scaled TBD)?

TBD는 앞서 말하였듯, 주로 작은 규모의 프로젝트와 애자일한 문화를 가진 스타트업 프로젝트에서 사용될 수 있다.

하지만 오직 하나의 trunk만을 유지하는 TBD는 때로는 이상적이지 않다.

STBD(Scaled TBD)는 이론적인 TBD와는 조금 벗어나지만, 새로운 feature branch를 활용해 협업 및 CI/CD에 활용하고, Feature Flagging을 통해 새로운 feature를 활성-비활성화 하거나, 페어 프로그래밍을 통해 코드리뷰를 활성화 하는게 그것이다.

따라서, 필요하다면 STBD를 통해 TBD의 간소하고 빠른 개발 접근 방식을 유지하면서도, 대규모 프로젝트에서 협업과 안정성도 확보할 수 있다.

5.결론

Harpy chat 서비스의 현재 상황을 고려할 때, 잦은 merge hell과 같은 문제를 해결하기 위해서는 버전 관리 전략의 변경이 필요할 수 있다.

TBD는 작은 단위의 커밋과 강력한 자동화된 테스트를 통해 merge conflicts를 최소화하고, 지속적이고 신속한 릴리즈를 가능하게 한다.

TBD로 전환한다면, 팀은 자동화된 테스트와 CI 시스템을 강화하고, 즉각적인 코드리뷰를 활성화해야하며, 작은 단위로 자주 커밋하는 문화를 정착시켜야 한다.

이를 통해 개발 속도를 높이고, 안정성을 유지하며, 고객에게 더 빠르게 가치를 제공할 수 있을 것이다.

또한 이후 프로젝트 규모가 커진다고 하더라 Scaling을 통해 STBD로 전환할 수도 있다.

물론, Git Flow의 구조적 안정성이 필요하다면, 각 브랜치의 역할을 명확히 하고, 코드 리뷰 프로세스를 강화하여 merge hell을 최소화하는 방향으로 개선할 수도 있을 것이다.