dev 브랜치 PR 정책을 문서화해 팀 협업 신뢰도를 높였다

PROGRESS.md를 수정해서 브랜치 흐름을 정정했다. "slecs 작업도 dev에 직접 커밋하면 안 되고, dev PR을 통해야 한다"는 룰을 명시한 것인데, 사실 이건 이미 어느 정도 지켜지고 있던 관행을 문서로 명확히 한 거다.

왜 이제서야 명문화했나

팀이 작을 때는 "뭐, 알아서 다들 하겠지" 했는데, 팀원이 늘고 일하는 방식이 다양해지니까 문제가 생겼다. 누군가는 "dev에 직접 푸시해도 되겠지?" 했고, 누군가는 "항상 PR이 필수인 줄 알았는데" 했다. 특히 내부 작업이라고 생각되는 "slecs 작업" 같은 경우, 그냥 dev에 바로 집어넣어도 되지 않을까 라는 생각을 하는 사람들이 있었다.

하지만 "슬렉스 작업이니까 좀 더 편하게" 하려다 보면, 어느 순간 누가 뭘 왜 고쳤는지 추적하기 어려워진다. 리뷰 없이 들어온 코드들이 섞이면서, 나중에 버그가 터졌을 때 원인 파악이 지연된다. 또 dev 브랜치에 직접 커밋이 쌓이면, 다음 리리즈 준비할 때 "이 커밋들이 정말 test된 건가?" 하는 의심이 생긴다.

프로세스는 느리지만, 신뢰는 올라간다

결국 이 정책은 "속도 vs 신뢰성" 트레이드오프에서 신뢰성을 선택한 거다. PR을 거친다는 건:

• 최소한의 눈 2개: 작성자 + 리뷰어가 코드를 본다
• 의도 기록: PR 제목, 설명, 댓글에 "왜 이렇게 했는지"가 남는다
• CI 재확인: PR마다 자동 테스트/린트가 다시 한 번 돈다
• 협업의 증거: git history에 approve 마크가 남는다

내가 리더로서 느낀 게, 작은 fixes나 typo 수정도 PR을 거치면, 팀원들이 "어라, 이건 이렇게 하는 거구나" 배우게 된다. 심지어 내 코드에 대한 리뷰 받으면서도 "아, 내가 놓친 부분이 있네" 하는 경험을 자주 한다.

문서화의 역할

이 정정 커밋의 핵심은 사실 "새로운 규칙"이 아니라, 모호했던 규칙을 명확히 한 것이다. PROGRESS.md 같은 곳에 "slecs 작업도 dev PR을 통해야 한다"고 쓰는 순간, 새로운 팀원이 들어와도 온보딩이 쉬워진다. Slack 메시지나 구두로 "원래는…" 설명할 필요가 없다.

실제로 문서가 없으면:
- 팀원A: "slecs는 내부 작업이니까 가볍게 가자"
- 팀원B: "아뇨, 저는 항상 PR 올렸는데?"
- 나: "앗, 우리가 규칙을 명시하지 않았네…"

요 상황이 반복된다.

회고: 프로세스는 팀 크기에 따라 진화한다

처음에 2-3명일 때는 git 규칙이 필요 없었다. 하지만 팀이 5명, 10명으로 커지면서, 각자의 "좋은 의도"가 충돌하기 시작한다. 누군가는 "속도가 최우선"이고, 누군가는 "품질이 최우선"이다. 그럼 프로세스가 그 중간을 찾아줘야 한다.

내 배운 점은: 프로세스는 제약이 아니라, 신뢰를 위한 공동 언어라는 것. PR 문화가 정착되면, 팀원들이 "미안해, 내가 실수했어" 보다 "이 방향 어때? 리뷰 부탁해"라고 말한다. 그게 건강한 협업의 시작이다.

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

• 사무의자 쿠팡에서 보기 →
• 모니터암 쿠팡에서 보기 →
• 커피머신 쿠팡에서 보기 →

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