공용 작업 브랜치를 dev로 통일해 온보딩 비용을 줄인 이야기

"어디서 작업해야 하지?" 새로운 팀원이 묻던 질문이 반복되기 시작했다. 브랜치 규칙이 명시되지 않아서였다. 개발자들은 각자 편한 이름의 브랜치에서 작업했고, 통합은 누군가의 관습에 맡겨졌다. 이번에 결정했다: 모든 공용 작업 브랜치를 dev로 통일하기. PROGRESS.md에 규칙을 명문화했다.

분산된 브랜칭이 남긴 작은 피로들

처음엔 "뭐 이 정도야" 싶을 수 있다. 각자 브랜치를 자유롭게 쓰고 있었으니까. 하지만 팀이 성장하면서 작은 불편함들이 쌓였다.

첫째, 통합 지점이 모호했다. PR을 올릴 때 base 브랜치가 뭐였지? 메인? 아니면 누가 미리 작업해둔 다른 브랜치? 새로운 팀원이 온보드될 때면 "어디서부터 풀하지?"라는 질문이 반복됐다. 명문화된 규칙이 없으니 각자 "관습"에 의존할 수밖에 없었다.

둘째, CI/CD 파이프라인이 증가했다. 누가 feature 브랜치에서, 누가 다른 이름의 작업 브랜치에서 작업하면 통합 테스트는 어디서 돌리나? 결국 하나의 메인으로 모으려면 여러 경로의 PR과 merge가 필요했다. 불필요한 CI 실행이 늘어났고, 어느 브랜치를 모니터링해야 하는지도 불명확했다.

셋째, 온보딩 비용이 커진다. 신규 팀원이 입사해서 첫 작업을 하려면 누군가가 "우리는 이렇게 하는데..."이라고 설명해야 한다. 이건 암묵적 지식이 아니라 명시적 규칙으로 있어야 한다.

dev로 통일하면 바뀌는 것

모든 개발자가 공용 브랜치를 dev로 정하는 것만으로 꽤 많이 바뀐다:

• 일관된 merge base: 모든 작업이 dev에서 나가고 dev로 돌아온다. 누구든 "어디로 PR을 올려야 하지?"라는 질문 없이 dev로 통일할 수 있다.
• 온보딩 단순화: 신규 팀원에게 git checkout dev → git pull → git checkout -b feature/xxx 한 문장으로 끝난다. 관습 설명은 없다.
• CI/CD 선형화: 모든 변경이 dev를 거쳐가므로, dev에 대한 CI 파이프라인 하나로 충분하다. 어느 브랜치를 모니터링할지 고민할 필요가 없다.
• Git graph 가독성: 여러 병렬 작업 브랜치가 있어도 모두 dev로 수렴하므로 통합 지점이 명확하다.

물론 이건 규칙일 뿐, 규칙을 지키지 않으면 소용없다. 그래서 PROGRESS.md에 명시했다. "공용 작업 브랜치 = dev. 모든 팀원이 dev에서 작업한다."

다른 선택지: 왜 dev 통일을 선택했나

이 결정을 내리기 전에, 브랜칭 전략을 비교했다.

우리가 선택한 "dev 통일"은 Git Flow보다 단순하고, Trunk-Based보다는 개발 안정성을 확보할 수 있는 중간 지점이었다. 팀 규모와 릴리스 빈도를 고려하면 충분하다.

배운 점: 규칙은 명시적으로

이 커밋은 코드 한 줄을 수정하지 않았다. 대신 문서에 규칙을 기록했다. 총괄 팀장으로서 느낀 점은, 팀이 커질수록 "관습"만으로는 부족하다는 것이다.

신규 팀원이 들어올 때 물어봐야 하는 질문이 줄어든다. 코드 리뷰 때 "왜 이 브랜치에서 작업했어?"라는 불필요한 피드백이 없어진다. 누구든 일관되게 dev로 작업한다.

작은 규칙이지만, 팀의 운영 효율이 올라간다. 다음은 커밋 메시지 규칙, 코드 리뷰 체크리스트, 릴리스 절차 같은 다른 명시적 규칙들을 문서화할 차례다.

🛒 이 글과 어울리는 추천 상품

• 사무의자 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.