금요일 오후 5시, 머지 컨플릭트의 악몽을 겪어보셨나요?
솔직히 고백할게요. 저도 주니어 시절에는 Git이 그냥 '저장 버튼'의 고급 버전인 줄 알았습니다. 그냥 코드 짜고, 커밋하고, 푸시하면 끝인 줄 알았죠. 그런데 팀 규모가 커지고, 동료가 3명, 5명, 10명으로 늘어나면서 지옥이 시작되었습니다. 특히 금요일 퇴근 직전에 "자, 이제 배포합시다!" 하고 각자 작업한 코드를 합치려는데 터지는 붉은색 충돌(Conflict) 메시지... 혹시 이 기분 아시나요? 식은땀이 흐르고, 누가 어느 파일을 건드렸는지 히스토리를 뒤지다가 결국 야근을 하게 되는 그 상황 말입니다. 😅
개발자 생활 10년 차가 된 지금, 저는 후배들에게 항상 이렇게 말합니다. "코드를 잘 짜는 것도 중요하지만, 코드를 잘 관리하는 건 생존의 문제다."라고요. 오늘은 단순히 Git 명령어 몇 개를 외우는 게 아니라, 실제 현업에서 우리가 어떻게 '우아하게' 협업하는지, 그리고 프로젝트 성격에 따라 어떤 브랜치 전략을 가져가야 팀원들의 정신 건강을 지킬 수 있는지에 대해 아주 솔직하고 깊이 있게 이야기해 보려고 합니다. 교과서적인 내용보다는 제가 수많은 삽질 끝에 얻은 인사이트를 중심으로 풀어볼게요. 커피 한 잔 타 오세요. 꽤 긴 이야기가 될 테니까요. ☕
도대체 왜 '브랜치 전략'이라는 거창한 게 필요할까요?
처음 스타트업에서 일할 때는 브랜치 전략이랄 게 없었습니다. 그냥 `master` (요즘은 `main`이라고 하죠) 브랜치 하나에 다 같이 푸시했습니다. "야, 나 지금 `UserAuth.java` 건드린다! 너 건드리지 마!" 하고 소리치면서 개발했죠. 이게 2~3명일 때는 의외로 잘 돌아갑니다. 속도도 빠르고요. 하지만 이 방식은 시한폭탄과 같습니다.
1. 배포의 불안정성 해결
가장 큰 문제는 '배포 가능한 상태'를 유지하기 힘들다는 점입니다. 예를 들어, A 개발자는 로그인 기능을 고치고 있고, B 개발자는 결제 모듈을 붙이고 있다고 칩시다. A의 코드는 완성됐는데 B의 코드가 에러를 뿜고 있다면? 우리는 영원히 배포를 못 하거나, B의 코드를 억지로 주석 처리하고 배포해야 합니다. 브랜치 전략은 기본적으로 "언제든지 배포 가능한 상태"와 "현재 개발 중인 불안정한 상태"를 격리(Isolation)하는 것에서 출발합니다. 이것만 잘 지켜도 배포 날 심장이 쫄깃해지는 경험을 절반으로 줄일 수 있습니다.
2. 코드 리뷰 문화의 정착
브랜치를 나눈다는 것은 곧 'Pull Request(PR)' 혹은 'Merge Request(MR)' 단계를 거친다는 뜻입니다. 제가 시니어로서 가장 중요하게 생각하는 포인트가 바로 여기입니다. 단순히 코드를 합치는 게 목적이 아니라, 합치기 전에 동료의 눈을 거치게 만드는 강제성을 부여하는 것이죠. "이 변수명은 좀 헷갈리는데?", "이 로직은 예외 처리가 빠졌어." 같은 피드백이 오고 가는 과정 자체가 팀의 기술력을 상향 평준화시킵니다. 브랜치 전략 없이 메인 브랜치에 직행하는 건, 마치 원고 교정 없이 바로 책을 출판하는 것과 같습니다. 오타가 그대로 세상에 나가버리겠죠. 😱
💡 경험담: 예전에 급하다고 메인 브랜치에 바로 핫픽스를 올렸다가, 전체 서버를 다운시킨 적이 있습니다. 알고 보니 콤마(,) 하나를 빠뜨렸더군요. 그 이후로 저는 제 자신을 믿지 않습니다. 오직 CI(지속적 통합) 도구와 동료의 리뷰만 믿습니다.
Git Flow: 클래식은 영원하다? (하지만 무겁다)
아마 Git을 처음 공부할 때 Vincent Driessen이 제안한 그 유명한 지하철 노선도 같은 그래프를 보셨을 겁니다. 바로 `Git Flow`입니다. 저도 5년 전쯤 대규모 금융 프로젝트를 할 때 이 전략을 썼습니다. 결론부터 말하자면, "복잡하지만 안전하다"입니다.
어떻게 작동하나요?
Git Flow는 역할이 아주 명확한 5가지 브랜치를 사용합니다.
- Master(Main): 언제나 제품으로 출시될 수 있는 가장 순수한 상태. 여기에 있는 코드는 무조건 버그가 없어야 합니다.
- Develop: 다음 버전을 위한 개발 코드가 모이는 곳입니다. 개발자들은 여기를 기준으로 작업합니다.
- Feature: Develop에서 가지를 쳐서 개별 기능을 만드는 곳입니다. (예: `feature/login-page`)
- Release: Develop에서 기능 개발이 얼추 끝나면, 배포 전 최종 점검을 위해 따는 브랜치입니다. 여기서는 버그 수정만 하고 새 기능은 추가하지 않습니다.
- Hotfix: 배포된 Master 버전에서 긴급 버그가 터졌을 때 수정하는 브랜치입니다.
왜, 그리고 언제 써야 할까요?
🔎 관련 상품 추천
아래 링크를 통해 구매 시 운영자에게 일정 수수료가 발생할 수 있습니다.
* (이유: 개발/협업 도구인 Git 관련 주제로, 도커나 클라우드 서버와는 다른 '소스 코드 관리' 영역입니다.)
'* (이유: 개발/협업 도구인 Git 관련 주제로, 도커나 클라우드 서버와는 다른 '소스 코드 관리' 영역입니다.)' 관련 상품을 쿠팡에서 확인해 보세요.
상품 보러가기 →
댓글
댓글 쓰기