동기화 안 되는 main-develop, PR Cherry-pick 전략으로 배포 프로세스 개선해보기

 

 

 

 

1. 깃허브 배포 전략 및 문제를 파악하다.

사내에서 담당하게 된 프로젝트의 Git 브랜치 구조를 처음 봤을 때, 바로 개선이 필요하다고 생각했습니다.

 

처음 본 문제

1. main (운영 서버) / develop (개발 서버) 브랜치만 존재했습니다.
2. main과 develop이 동기화되지 않은 부분이 있었습니다.
3. 전달받은 main 배포 방식은.. develop 작업 파일 수동 복붙이었습니다.

 

왜 이런 상황이 됐을까?

더 파보니 이전 작업자분들도 나름의 이유가 있었습니다.

• 로컬에서 CRUD 테스트가 불가능 (보안 제약으로 조회만 가능) 
  • 즉, 기능 검증을 위해서는 무조건 develop에 올려야만 했습니다.
  • feature 브랜치 없이 모두가 develop에 직접 push 했음.
  • 배포 제외 기능도 develop에 계속 쌓임.
• 담당자도 자주 바뀌어, 체계적인 시스템이 없어 어려웠다고 했습니다. 

 

무튼 결과적으로 맞닥뜨린 상황은

develop 브랜치는 보류 기능 + 테스트 코드 + 실제 필요 코드가 전부 섞여있는 상태가 되었습니다.

즉, 배포 할 때 develop → main merge는 불가하고요, 그렇다고 수동 복붙을 계속할 수도 없는 딜레마였습니다.

 

 

2. 몇가지 전략을 생각하다.

 

흠... 운영 배포를 준비하면서 저는 여러 가지 방법을 고민했습니다.

 

무조건 develop을 한번 타야 테스트 및 공유가 되니,,

develop 브랜치에서 main으로 넘어가는 효율적인 방법을 고민해야 했습니다.

 

1. 복붙 전략 (기존)
   • 작업한 코드만 develop에서 main으로 수동 복사
   • 작업량이 많고, 사람 손 타는 순간 오류 발생 가능성이 매우 높았습니다. (시간도 오래걸림)
2. 강제 동기화 전략
   • 동기화를 위해 main을 develop에 덮어씌워 일단 싱크를 맞추기
   • 하지만 develop에 있던 차후 배포에 포함될 수 있는 기능까지 전부 날아가 버립니다.
3. release 브랜치 전략
   • 배포 가능한 기능만 추려 별도 release 브랜치 생성
   • 하지만 이전 develop 커밋들을 정리하기에는 난이도가 너무 높았습니다.

이 모든 방법에는 단점이 있었습니다.
단순히 이전 작업 따라서 땜빵치기는 싫고,, 한가지 키워드를 보고 이거다! 싶었습니다.

 

바로바로 그 키워드는... 🍒

 

 

3. 최종 해결책: PR 단위 Cherry-pick 전략

 

고민 끝에 제가 내린 해결책은 PR 단위 cherry-pick전략이었습니다.

• develop에 merge된 Pull Request(PR) 단위를 기준으로 cherry-pick을 진행합니다.
• 즉, 배포할 기능만 main에 안전하게 반영할 수 있는 구조입니다.
• 추가적으로 PR number 기준으로 Git 히스토리 관리도 할 수 있죠.

 

제가 만든 작업 흐름은 다음과 같습니다. 

1. 모든 작업은 반드시 신규 브랜치에서 시작합니다.
   • ex. feature/JIRA-TICKET-ID-search-filter
2. 작업이 완료되면 → develop에 PR 생성 후 Merge 시점에서 PR 번호(ex. #9)가 작업 마무리의 증거가 됩니다.
   • ex. Merge pull request #9 from feature/JIRA-TICKET-ID-search-filter
3. 운영 반영 시에는 main에서 해당 PR 커밋만 cherry-pick 합니다.→ main git log에도 “Merge pull request #9 …” 기록이 남습니다.
   • ex. git checkout main git cherry-pick <commit-hash-of-PR-#9>

 

이제 운영 브랜치에는 작업한 PR 단위로만 코드가 반영되고, 다른 부분에 대한 걱정을 하지 않게 되었습니다!

 

+) PR number 외 Jira 컨벤션으로 업무 추적까지 (더보기)

저희 회사는 Jira를 사용해서, ticket ID 기반으로 컨벤션도 세웠습니다.

• 브랜치명: feature/JIRA-TICKET-ID-search-filter
• 커밋 메시지: feat: JIRA-TICKET-ID 검색 필터 기능 추가
• PR 제목: JIRA-TICKET-ID 검색 필터 기능 추가

이를 통해 어떤 업무인지 추적도 쉬워졌죠!

 

 

4. 선택적 배포도 이제 유연하게!

 

PR 단위 cherry-pick 전략 덕분에 배포 범위 조절도 편리하게 할 수 있게 되었습니다.

 

특정 Jira 업무가 이번 배포에 포함되지 않는다면, 해당 PR은 cherry-pick 대상에서 단순히 제외시킬 수 있게 되었습니다.

추후 필요할 때는 기록을 추적해 해당 PR만 cherry-pick 하여 운영에 반영할 수 있게 되었죠!

 

 

5. Before vs After

 

Before

로컬
  ↓
develop (CRUD 테스트 위해 무작위 push, 테스트용 + 보류 기능 + 실제 필요 기능 뒤섞임)
  ↓
main (운영, merge 불가능 - 수동 복붙)

 

Git 그래프:

develop: A---B---C---D---E (보류 기능 + 테스트용 작업 혼재)
main:    1---2---3 (수동 복붙으로 관리)

 

After

Jira Issue
  ↓
feature/Jira Issue-작업
  ↓
(PR) develop (test 전용)
  ↓
(PR 단위 cherry-pick) main (운영 안정 반영)

 

Git 그래프:

develop:  A---B---[PR#9(실제 필요한 기능)]---C(테스트코드)---[PR#11(실제 필요한 기능)]---D(보류기능)
                     ↓                                   ↓
main:     1---2---[PR#9]----------------------------- [PR#11]

 

 

 

6. 회고

 

세운 전략으로 배포를 마무리하니, 수작업 복붙의 공포와 불편성에서는 확실히 벗어났습니다.

 

- Before: 불안 및 불편 지수 ████████░░ 80%

- After: 불안 및 불편 지수 ███░░░░░░░ 30%

 

통계적으로 유의미한 개선이었습니다. 물론 표본은 접니다.

 

추가로 나름 깨달은 점도 있습니다.

개발자에게 꼭 필요한 사고방식이 있죠.

 

"문제가 뭘까? 어떻게 편한 시스템을 만들까?"

이게 사용자를 위한 서비스 개발에만 적용되는 게 아니라, 나 스스로를 위한 운영 환경 개선에도 똑같이 적용되더라구요.

 

물론 이게 근본적인 해결책은 아니고, Best Practice도 아닐 수 있습니다.

하지만 현 상황에서는 최대한 안전하고 편하게 배포해야 하니까요. (배포 얘기를 하니까 뭔가 다음주에도 배포가 있을 것 같은 느낌이 드네요 🦖)

 

무튼 마무리 하자면-

이 글을 읽는 선배님들 중 더 나은 방법이 생각나시는 분이 계시다면 제발 댓글로 남겨주세요..

 

 

아주 긴 글 읽어주셔서 감사합니다!