코드 리뷰 문화 살리기! Dev와 Base의 역할 분리 전략

개요

현재 속한 개발팀에서는 아래 그림처럼 dev 브랜치를 기준으로 feature 브랜치를 작성해서 개발 환경에서 테스트를 진행하는 환경이었습니다.

 

개발에 대해서 주어진 시간적 자원의 제약으로 프론트 개발자와의 연동 과정으로 feature 브랜치에서 작업한 내용들이 PR 생성 후 바로 Merge 되는 현상이 반복되었습니다.

 

개발자들과 이야기를 하다보면 "코드 리뷰를 했으면 좋겠다." 반복적으로 표현되지만 실질적으로 현재 PR이 남겨져 있는 것이 없어서 코드 리뷰 문화를 도입한 환경조차 구성되어 있지 않다고 판단하였습니다.

 

제안한 방법.

1. 정기적 코드 리뷰 날짜를 정해서 각 인원들이 코드를 보여주고 리뷰하자!

2. 현재 상황에서 feature 브랜치의 PR을 최대한 유지하자!

3. PR을 유지할 수 있는 브랜치 전략을 구성하여 자유롭게 PR에 리뷰를 진행하자!(채택)

 

의견.

1. 정기적 코드 리뷰 날짜를 정해서 각 인원들이 코드를 보여주고 리뷰하자!(X)

- 리뷰에 참가하는 사람들의 일정을 조율해야 하기 때문에 수동적이다.

- 개발자마다 시간이 남는 시간이 다르기 때문에 정상적으로 유지되기 어려울 것이다.

 

2. 현재 상황에서 feature 브랜치의 PR을 최대한 유지하자!(X)

- 지금도 일정을 맞추기 위해서 merge을 반복하는데 PR을 유지하라는 것은 개발을 더 빨리 하라는 이야기이다.😡

 

3. PR을 유지할 수 있는 브랜치 전략을 구성하여 자유롭게 PR에 리뷰를 진행하자!(O)

- 개발 환경을 재구축하고 있는 현재 브랜치 전략을 재정비해도 괜찮을 것 같다.

- 능동적으로 시간이 남아있을 때 올려져있는 PR을 확인하는 것이 좋을 것 같다.

- PR을 유지하는 환경이면 자연스럽게 참여할 수 있을 것 같다.

- 기존처럼 기능 확인을 위해 빠르게 적용하고 따로 PR을 유지할 수 있으면 좋을 것 같다.

---

브랜치 전략(Dev와 Base 브랜치의 역할 분리)

요구사항.

- 기존처럼 기능 확인을 위해 빠르게 개발 환경에 적용하여 프론트 개발자와 협업하는 것을 유지하고 싶다.

- PR을 유지시켜서 자연스럽게 코드 리뷰에 참여할 수 있도록 한다.

- 리뷰 문화를 도입하기 위한 정책도 필요하다.

 

접근 방법.

dev 브랜치 상위의 base 브랜치를 두어서 거기에 PR을 유지시켜야 하는 방법은 어떨까?

 

dev에서 master으로 Merge PR을 진행할 때 다른 사람의 작업도 모두 보여지는게 아닌가?

= PR을 유지시키려는 것은 각 개발자 단위로 개발한 내용에 대해서 리뷰를 하고 싶은 것인데 모두 보여지면 변경 이력에 대해서 코드 리뷰하기에는 너무 힘들 것이다.

 

dev와 base 브랜치의 연결관계를 끊고 base 중심으로 관리를 하면 되지 않을까?

 

 

모든 기능 개발은 base 브랜치에서 feature 브랜치로 시작하고, dev 브랜치는 기능 개발을 자유롭게 확인하는 플레이 그라운드로 역할을 수행하고 base는 검증된 코드만 관리하는 공간으로 인식하게 하는 것이었습니다.

개발 프로세스

1. 기능 요구사항에 대한 base 브랜치 기준 feature 브랜치를 생성합니다.

2. feature 브랜치에서 개발을 수행한 뒤 dev 브랜치로 PR Merge을 자유롭게 진행하여 검증을 진행합니다.

3. 개발 환경에서 검증이 완료되었다면, 작업한 feature 브랜치를 base으로 PR을 생성합니다.

4. 유지된 PR을 다른 개발자들이 리뷰를 진행하고, Approve가 확인되면 해당 PR을 Merge를 진행합니다.

 

 

브랜치 역할.

base : 개발 환경 기능 검증 및 리뷰를 받은 개발 내용들을 모아놓은 공간

 

dev : 개발한 내용을 확인하는 공간(개발 환경)

 

이점.

- 기존처럼 개발 환경에서 개발한 기능에 대해서 즉각적으로 확인할 수 있다.

- PR을 유지함으로써 PR을 확인하는 것으로 각자 개발한 기능 리뷰 및 추적이 가능해졌습니다.

- base 브랜치에서는 검증된 개발 내역만 들어오기 때문에 전체적인 코드 품질이 향상되었습니다.

 

문제점.

- dev에서 개발하고 검증한 내용이 base에 PR에 대해서 오래 유지되면 충돌이 발생할 확률이 올라간다.

- 휴먼 이슈로 dev 브랜치를 pull 받거나 충돌을 해결하여서 dev와 base 브랜치가 틀어지는 현상이 발생한다.

- dev에만 반영된 기능이 기획적으로 취소되어서 변경 사항이 base에 올라가지 않는 현상이 발생한다.

 

개선 방향.

- dev와 base가 틀어짐이 발생하였을 때 상황을 유지시키는 것이 아닌 주기적으로 dev 브랜치를 base브랜치로 초기화를 진행합니다.

   ▶︎ 현재 저희 팀에서는 3주 간격으로 초기화를 진행하고 있습니다.

- 충돌이 발생할 가능성이 높은 공통 모듈의 파일인 경우에는 브랜치를 나누고 작은 단위로 커밋 및 PR을 유지한다.

- 충돌이 발생하면 dev 브랜치에서 해결하지 않고 관련 개발자와 협의하에 해결한다.

 

---

적용 후기

현재 Base와 Dev 브랜치를 분리하는 전략을 개발팀에 도입하여 운영하고 있습니다.

 

도입 초기에는 Dev와 Base 간 충돌이 빈번하게 발생했고, 두 브랜치가 불일치하는 상황이 자주 일어났습니다. 이를 해결하기 위해 Dev 브랜치를 Base로 초기화하는 작업을 반복해야 했습니다.

 

시간이 지나면서 팀원들이 새로운 워크플로우에 적응했고, 충돌 발생 빈도는 현저히 감소하게 되었습니다.가장 큰 성과는 PR 프로세스가 정상적으로 유지되기 시작했다는 점입니다. 

 

아직 모든 팀원이 적극적으로 리뷰에 참여하는 것은 아니지만, 점진적으로 참여 빈도가 높아지고 있습니다.PR과 코드 리뷰가 자리 잡으면서 JavDoc, Swagger 문서화, 중복 로직 제거 및 공통 Util 활용, 코드 컨벤션 통일 등의 개선이 이루어졌습니다.

 

과거 각자의 방식으로 작성되던 코드들이 이제는 하나의 유기체처럼 일관성 있게 발전하고 있습니다.코드 품질이 높아지면서 개발 환경에서 발견되는 문제도 줄어들었습니다. 누락됐던 유효성 검사나 잘못된 비즈니스 로직이 배포 전에 걸러지는 경우가 많아졌습니다.

 

브랜치 전략에 정답은 없다고 생각합니다. 각 전략마다 장단점이 있고, 중요한 것은 현재 팀의 상황과 목표에 맞는 전략을 선택하는 것입니다.이번에 도입한 Base/Dev 분리 전략은 개발팀이 원했던 PR 유지를 통한 코드 리뷰 문화 활성화와 코드 품질 향상이라는 목표를 달성해 나가고 있다는 점에서 긍정적으로 평가하고 있습니다.

 

---

 

추가적으로 해당 브랜치 전략에 대해서 개선할 점이 있으시면 댓글로 공유해주시면 감사하겠습니다.