우리 팀이 Git 대충 쓰기에서 협업 시스템으로 넘어간 방법

2026. 2. 8. · 5분 읽기

Git을 쓰는데도 협업이 안 되는 순간들

개발자가 Git을 사용할 때는 생각보다 자주 같은 문제를 겪는다.

브랜치 전략 수립
merge 충돌 해결
commit 메시지 기준 부재로 인한 히스토리 혼란
PR 리뷰 참여 저조
히스토리 관리 실패(되돌리기 어려움, 의사결정 과정 소실)
권한/정책 운영 문제(force push, approve 기준 등)
신규 인원 온보딩 실패(적응 어려움)

우리 팀도 한동안은 이 문제들을 각자 알아서 버티는 방식으로 넘기고 있었다. 당장 기능 개발은 굴러가니까 지금은 바쁘니까 나중에 정하자로 미뤄지기 쉬웠고, 그 사이 규칙은 더 느슨해졌다. 그러다 협업이 본격적으로 필요해지는 순간, 작은 불편이 한꺼번에 터지면서 커뮤니케이션 비용이 급격히 늘어났다.

규칙이 증발한 팀에서 생긴 일

지난 몇 년 동안 팀에서 인원에 비해 많은 과제를 수행하다 보니 1인 1과제로 흘러간 기간이 길었다. 그 결과 팀에서 이슈 관리, 코드 관리 규칙이 자연스럽게 사라졌고, 각자 편한 방식으로 일하는 “사일로”가 생겼다.

문제는 다시 협업이 필요해졌을 때였다.

규칙을 새로 도입하려면 설계하는 데 시간이 들고
규칙을 지키는 과정이 오히려 생산성을 깎는 느낌이 들었다
게다가 옆자리에서 바로 물어보는 습관이 생겨서, 그때그때 구두로 문제를 해결해버리곤 했다

근데 이 방식은 오래 가지 못했다. 실시간 소통이 계속되면 집중 시간이 줄어들고, 말로만 전달하면 기록이 남지 않아 기억에 의존하다가 증발해버리고 말았다.

그래서 결론적으로, 우리 팀 상황에 맞는 Git 협업 전략을 진짜로 만들기로 했다.

Git 협업 성숙도 4단계

나는 Git을 사용하는 과정을 다음 4단계로 본다.

1단계: Git이 무섭다

commit, push는 하지만, 브랜치를 만들고 merge하다가 충돌 나는 상황이 두렵다. 다만, 요즘은 AI 도구 덕분에 충돌 해결 자체는 쉬워졌고, 그래서 기능을 외우기보다는 개념을 이해하는 쪽이 더 중요해졌다.

2단계: 코드는 합쳐지는데 히스토리는 망한다

사람마다 브랜치 만들고, PR 올리고, merge하는 기준이 달라서 충돌은 안 나는데 히스토리가 전혀 관리되지 않는 상태가 된다.

3단계: 규칙은 있는데 너무 무겁다

규칙대로 굴러가긴 하는데 지키느라 오버헤드가 크다. 특히 PR에서 시간을 많이 뺏기면 규칙이 생산성을 떨어뜨린다는 인식이 강해진다.

4단계: 규칙이 익숙해져서 생산성이 오른다

규칙이 자연스러워지고, PR을 통해 서로의 코드 이해도가 올라가면서 결과적으로 개발 속도, 품질, 리뷰 속도가 같이 개선된다.

이 글에서는 2단계에 머물던 팀이 4단계로 올라가게 만든 방식을 정리하려고 한다.

거버넌스: 완벽한 정답은 없고 팀에 맞는 답이 있다

처음에 제일 고민했던 건 거버넌스를 어떻게 세울까였고, 그 결론은 완벽한 거버넌스는 없고, 팀에 맞는 거버넌스만 있다는 것이다. 팀의 업무 흐름(티켓 단위, 배포 주기, 리뷰 문화)이나 인력 구성(신규 인원 비중, 협업 빈도)이 다르면 같은 전략도 결과가 완전히 달라진다. 그래서 좋아 보이는 방식이 아니라, 지금 팀이 겪는 병목을 줄이는 방향으로 후보를 비교했다.

대표적으로 이런 선택지들이 있다.

메인라인 개발(Mainline development)
기능별 브랜치(Branch-per-feature)
상태 브랜치(State branching)
예정된 배포(Scheduled deployment)

우리 팀은 기능별 브랜치 + 상태 브랜치를 선택했다. 기능 단위로 티켓을 쪼개서 히스토리를 깔끔하게 만들고, 상태 브랜치로 배포,안정화 흐름을 분리하는 게 현재 팀 상황에 제일 잘 맞았다. 중요한 건 유행하는 전략을 그대로 사용하는 것보다, 팀 상황을 기준으로 선택하는 거였다.

규칙을 문서화하는 방식: Cookbook으로 만들기

우리는 Jira와 Bitbucket을 쓰고 있었고, 이 화면에서 이렇게 하면 된다를 그대로 따라할 수 있는 cookbook 형식 가이드를 작성해서 공유했다.

형식을 이렇게 잡은 이유는 원칙만 적으면 해석이 사람마다 달라지고, 결국 또 각자 방식으로 흩어지기 때문이다. 반대로 화면 단위로 “어디를 눌러서 무엇을 해야 하는지”가 정리되어 있으면, 신규 인원도 시행착오 없이 그대로 따라할 수 있었다. 그래서 가이드는 브랜치 생성 → PR 생성 → 리뷰 요청 → merge까지를 한 흐름으로 묶고, 예외 케이스(급한 hotfix, 롤백, 충돌 처리)도 최소한으로 포함했다.

가이드를 운영하면서 “수정이 필요한 부분”은 팀원이 직접 보완해주게 만들어서 문서를 지침이 아니라 하나의 살아있는 팀 규칙으로 만들었다. 문서가 팀의 합의로 계속 업데이트되니까, 규칙이 누가 시켜서 하는 것이 아니라 우리 방식으로 굳어지기 시작했다.

핵심 규칙: 변경이 둘 이상이면 티켓도 브랜치도 분리

우리 팀이 가장 중요하게 둔 규칙은 이거였다.

변경사항 2개 이상 시 Jira 티켓 분리
티켓 분리 시 브랜치 분리
(버그 픽스 제외) 규칙 준수 원칙
main 브랜치 직접 push 금지
PR approve 이후 merge 허용(Bitbucket 권한/정책으로 제한)

이 규칙 하나가 히스토리 관리 실패와 리뷰가 안 달리는 문제를 동시에 줄였다. 리뷰어 입장에선 변경 범위가 작아지니까 리뷰가 쉬워지고, 작성자 입장에선 흐름이 깔끔해졌다.

운영 루틴: 주간회의 → 티켓 → 브랜치 → commit → PR → 리뷰 → merge

우리는 다음 루틴을 팀의 기본 리듬으로 잡았다.

주 1회 주간회의: 주간 이슈 정리 및 담당 배정
개인 티켓 생성(회의 내용 기반)
티켓 기반 브랜치 생성
작업 commit 및 PR 요청
approve 후 merge
반복

이 구조의 장점은, 이슈 관리 시스템만 봐도 누가 뭘 하고 있는지가 보인다는 것이다. 그래서 다음 주간회의 전까지 상황에 따라 티켓을 유동적으로 재분배할 수도 있었다.

주의한 점: 티켓에 너무 힘주지 않기

티켓 자체를 완벽하게 쓰려다 보면 시간이 오래 걸릴 수 있다. 대신 우리는 이쪽에 힘을 줬다.

commit 메시지에 맥락을 남기기
PR 요청 설명에 의사결정의 이유를 남기기

그래야 PR이 빨라지고, 기록이 남아서, 말로만 소통하다 증발하는 문제도 줄었다.

피어리뷰 운영: 고쳐주기보다 성장시키기

피어리뷰는 보통 3종류로 나뉜다.

안 돌아가는 코드(버그/치명적 문제)
모범사례 미준수(컨벤션, 중복 구현 등)
리뷰어의 개인 선호(취향, 스타일)

이때 리뷰 방식은 크게 두 가지가 있다.

리뷰어가 직접 수정 commit을 한다
리뷰 코멘트로 방향을 준다

우리는 가능한 빨리 리뷰를 달아주는 방식을 택했고, 직접 수정 commit은 되도록 지양했다.

우리의 목표는 “빨리 합치기”가 아니라 “리뷰를 통해 성장하기”였기 때문이다. 리뷰어가 잘못된 점과 수정 방향을 남기면, 커미터가 자신의 결정 이유와 비교하면서 스스로 납득 가능한 해답을 다시 만들었다.

초반에는 리뷰 시간이 오래 걸렸지만, 코드베이스 이해가 올라가고 서로의 개발 스타일/철학을 알게 되면서 결과적으로 개발 속도, 품질, 리뷰 속도가 같이 올라갔다.

AI 시대에도 Git 협업 문화는 더 중요해진다

AI 때문에 사람이 코드를 직접 작성할 이유는 점점 줄어들 수 있다. 그런데 아이러니하게도, AI가 만든 코드일수록 오너십은 더 강하게 필요하다.

PR에 “부끄럽지 않은 코드”를 올리려고 사람이 한 번 더 검수해야 하고
팀은 PR 리뷰로 2차 검수를 하면서
AI로 인한 무분별한 코드 생성과 기술부채 누적을 막아야 한다

그래서 나는 오히려 앞으로는

Jira 같은 티켓 시스템으로 태스크를 더 작게 쪼개고
작은 단위로 commit/PR을 만들고
AI로 빠르게 구현하되 사람이 책임지고 검수하는 흐름

이런 방식이 생산성을 더 끌어올릴 거라고 생각한다. 그리고 그 바탕에 Git 협업 문화가 있다.

마무리

이 글은 “나 혼자 편하게”가 아니라, 팀이 함께 좋은 문화를 만들고 공유하면서 생산성을 올리는 과정에 대한 기록이다.

완벽한 규칙은 없지만, 우리 팀에 맞는 규칙을 만들고 계속 조정하면서 2단계에서 4단계로 올라가는 건 충분히 가능했다. 결국 핵심은 거창한 방법론이 아니라, 작게 시작해서 팀이 실제로 지킬 수 있는 형태로 굳히는 것이었다.