Cherry-pick 지옥에서 탈출하기: 주니어 개발자들의 PR 단위 코드리뷰와 Git Flow 도입기
들어가며
안녕하세요. 이 글에서는 Pull Request(PR)이 없던 회사의 혼돈의 로컬 개발 환경에서, PR 단위 코드리뷰와 Git Flow를 도입했던 경험을 풀어보려고 합니다.
당시 저희 팀은 각자 로컬에서 Merge하고 Push하는 방식으로 작업했고, 모든 개발이 단일 브랜치(dev)에서 이루어졌기에 Cherry-pick 남발과 그로 인한 conflict가 반복되고 있었습니다.
이를 해결하기 위해 주니어 개발자인 저와 동료들의 변화가 만들어낸 이야기를 전해드리려 합니다.
❔ 왜 도입을 결심하게 되었나?
기존의 작업 방식
도입 전 우리 팀의 브랜치 구조와 git 전략은 아래와 같았습니다.
- prod(main): 운영 환경에 반영되는 브랜치
- staging: 운영과 동일한 환경에서 테스트를 진행하는 브랜치
- dev: 모든 개발자가 작업하고 커밋하는 브랜치 이 구조는 GitLab Flow 방식으로 장단점이 있었지만, 저희의 작업 방식에 문제가 있었습니다.
-
로컬 중심의 Merge
각자 자신의 로컬에서 Merge하고 Push하다 보니, 충돌 발생 시 해결은 전적으로 개인 몫이었습니다.
개발자마다 로컬 상태가 다르다 보니, 누군가는 커밋을 뒤늦게 가져오면서 충돌을 마주하기도 했습니다. -
단일 dev 브랜치에 모든 작업이 몰림
기능 개발, 버그 수정, 핫픽스 등 모든 작업이 dev 브랜치 하나에 몰려 관리가 어려웠습니다.
어떤 기능이 완료되었고, 어떤 기능이 아직 미완성인지 구분이 어려웠습니다. -
긴급 배포의 어려움
특정 기능이나 긴급한 버그만 배포해야 할 때, Cherry-pick으로 staging에 특정 커밋만 가져와 반영했습니다.
이후 dev 브랜치를 다시 staging으로 병합할 때, 이미 Cherry-pick으로 들어간 커밋과 dev의 동일한 커밋이 충돌을 일으켰습니다.
이 충돌을 매번 해결해야 했고, 점점 더 복잡해졌습니다.
Cherry-pick 지옥
문제는 특히 dev 브랜치에서 작업하던 코드 중, 특정 커밋만 운영 환경(prod)에 먼저 반영해야 할 때 발생했습니다. 긴급한 버그 수정이나 특정 기능이 필요할 때 Cherry-pick을 사용했지만, 이는 반복적인 충돌 지옥을 유발했습니다.
왜 Cherry-pick이 문제였을까?
-
불완전한 반영 흐름:
dev에 커밋된 코드 중 일부만 Cherry-pick으로 staging에 반영하고, staging을 다시 prod로 Merge했을 때 dev와 staging 간 병합 이력이 맞지 않으면서 충돌이 발생했습니다. -
반복적인 충돌:
이후 dev 브랜치를 staging으로 Merge하려 할 때, 이미 Cherry-pick으로 staging에 반영된 커밋과 dev의 동일한 커밋이 충돌을 일으켰습니다. -
작업 중단:
이러한 충돌을 해결하는 과정에서 다른 작업이 중단되었고, 결과적으로 staging → prod로 이어지는 작업 흐름이 계속해서 방해받았습니다. -
관리 복잡성 증가:
dev, staging, prod 간 병합 히스토리가 불일치하면서, 이후 작업 시 추가적인 충돌이 발생하는 악순환이 이어졌습니다.
설득의 시작: Cherry-pick 문제를 중심으로
설득의 어려움
저와 동료는 이러한 문제를 해결하기 위해 PR 기반 코드리뷰와 Git Flow 도입을 제안했습니다. 하지만 처음부터 모두가 이 방식을 환영했던 것은 아니었습니다.
-
팀원들:
"해본적이 없어서 어려워 보인다."
"PR 같은 걸 하면 더 오래 걸릴 것 같은데?"
"지금도 충분히 잘 되고 있는 거 아닌가?" -
관리자:
"시간 낭비처럼 보인다."
이런 반응 속에서 Cherry-pick 문제를 중심으로 동료들과 관리자를 설득하기 시작했습니다.
Git Flow 전략의 대안 제시
저는 과거 Cherry-pick 문제로 인해 발생했던 충돌 사례를 기반으로 설득을 진행했습니다.
-
충돌 사례 재현:
이전에 발생했던 Cherry-pick 충돌 상황을 재현해 보여주며, dev → staging → prod 간 작업 흐름이 얼마나 쉽게 꼬이는지를 시각적으로 설명했습니다. -
Git Flow 전략의 대안 제시:
Git Flow 전략을 사용하면, 브랜치 관리가 체계적으로 이루어져 Cherry-pick 없이도 특정 작업을 staging에 반영할 수 있습니다. 또한, 병합 전 리뷰와 테스트를 통해 충돌 가능성을 사전에 제거할 수 있음을 강조했습니다. -
시간 절약 효과:
Git Flow와 PR 도입이 초기에는 익숙하지 않을 수 있지만, 장기적으로 충돌 해결에 드는 시간을 줄이고 작업 흐름을 개선할 수 있음을 어필했습니다.
작은 시작: 테스트 MR
설득만으로는 부족했기에, 저는 테스트 MR을 만들어 팀원들이 변화를 직접 체감할 수 있도록 했습니다.
-
테스트 환경 구성:
간단한 기능을 dev 브랜치에서 작업한 뒤, 해당 기능을 PR 단위로 staging과 prod로 Merge하는 시뮬레이션을 진행했습니다. -
기존 방식과 비교:
Cherry-pick 방식과 PR 방식을 비교하며, PR 방식을 통해 충돌이 발생하지 않고 작업 흐름이 매끄럽게 진행되는 모습을 보여줬습니다. -
참여 독려:
팀원들이 직접 PR을 작성하고 리뷰를 요청해 볼 수 있도록 유도해, PR 작성과 리뷰가 복잡하지 않다는 점을 체감하게 만들었습니다.
(당시 설득을 위한 Test MR)
🌱 PR 기반 코드리뷰와 Git Flow의 실제 도입
Git Flow 도입
Git Flow는 dev, staging, prod 간의 혼란을 정리하는 데 중요한 역할을 했습니다.
- main (prod): 운영 환경
- staging: 운영과 동일한 조건의 테스트 환경
- dev: 개발 통합 브랜치
- feature/*: 기능 단위의 작업 브랜치
- hotfix/*: 긴급 수정 사항 처리 브랜치 - 효과:
- 기능 개발과 병합 단계가 명확히 분리되면서 Cherry-pick 없이도 특정 작업만 staging에 반영 가능.
- Merge 전 리뷰와 테스트가 진행되면서 충돌 가능성이 대폭 감소.
- 작업 이력이 명확히 관리되어, 누가 무엇을 했는지 쉽게 파악 가능.
PR 코드리뷰: 최소 강제, 최대 자율
코드리뷰를 강제적으로 도입하지 않고, 팀원들이 부담 없이 적응할 수 있도록 설계했습니다.
-
리뷰어 지정 방식:
리뷰 요청자가 스스로 리뷰어를 지정할 수 있도록 해 강제성을 줄였습니다. -
Pn룰 도입:
Pn룰을 추가해 리뷰 강도 조절를 조절할 수 있게 하여 리뷰 과정을 협업과 학습의 장으로 만들었습니다.
P1: 꼭 반영해주세요 (Request changes)
P2: 적극적으로 고려해주세요 (Request changes)
P3: 웬만하면 반영해 주세요 (Comment)
P4: 반영해도 좋고 넘어가도 좋습니다 (Approve)
P5: 그냥 사소한 의견입니다 (Approve)저희는 다음과 같은 리뷰들이 주로 생기게 됐습니다.
물어보기
칭찬하기
놓친부분 있는지 확인해주기
도입 후 변화와 느낀 점
도입 후 성과
-
충돌 문제 감소:
PR 단위로 작업하면서 Cherry-pick이 필요 없어졌고, dev → staging → prod 병합 과정에서 충돌이 거의 발생하지 않았습니다. -
작업 흐름의 투명성:
Git Flow와 PR을 통해 작업 이력과 변경 사항이 명확히 기록되면서 관리 효율이 증가했습니다. -
협업 문화 정착:
코드리뷰는 단순한 오류 검출이 아니라, 협업과 학습의 장이 되었습니다.
작업자와 리뷰어가 소통하며 더 나은 코드에 대해 토론했고, 팀의 코드 품질이 전반적으로 향상되었습니다.
✨ 마무리하며
PR 기반 코드리뷰와 Git Flow는 단순히 도구를 도입하는 것이 아니라, 팀 전체의 협업 문화를 바꾸는 여정이었습니다.
새로운 시도를 한다는 건 언제나 쉽지 않습니다. 하지만 저희 팀원들은 작은 변화에서 시작하여 이제는 없으면 안되는 회사의 개발 문화를 만들게 됐습니다.
이 경험이 비슷한 상황을 고민하고 계신 분들께 작은 힌트가 되었으면 좋겠습니다. 😊
