Git 형상 관리 및 배포 전략 어떻게 하면 좋을까?

🛠️ 운영 1차 배포는 문제 없었지만, 2차 개발에서 꼬이기 시작했다 – 실전 사례로 본 Git 브랜치 전략

🤷‍♂️ "개발은 잘 됐는데, 운영 배포 이후가 문제였다" – 실전에서 겪은 혼란

실제로 있었던 상황

• 1차 배포(운영): 개발 브랜치에서 기능 구현 → 슬슬 release 서버가 필요함을 어필하지만 초기 리드 시 어필 부족으로 인한 설득 실패 → 개발에서 테스트 후 운영(main) 배포, 문제 없이 성공!
• 2차 개발: 신규 요구사항이 생겨 다시 개발 시작.
  • 이때부터 꼬이기 시작했다.

    PO: “자~ 2차 개발 들어가죠 슛!”
    2차 개발 한참 진행 중 프로덕션 오류 발생…
    PO: “고객사에서 오류가 생겼어요! 빨리 수정해 주세요.”
    FE: "엇… 저번에 release 서버 말씀 드렸을 때 이런 문제가 발생 한다고.… develop에서 작업했는데, main에 머지하면 지금 안돼요…. 화면 노출이…."
    BE: "우리는 FE에서 호출만 안하면 상관 없지 않나요? release 브랜치가 뭔지 몰라서 바로 main에 올렸어요."

이런 얘기를 들으면 한숨이 절로 나오지만 실제 제가 겪은 사례 입니다.

“Git 전략 없이, 대형 사고는 시간 문제다!” 비용적인 측면도 있지만 인지 혹은 미리 준비를 하자!

🚦 이 문제, 왜 반복이 될까?

(1) 운영/개발/QA 환경이 모두 하나로 섞여 있었기 때문

• 운영과 개발 사이에 중간 검증(릴리즈) 환경/브랜치가 없으니, 운영에 바로 머지하거나, 개발 서버에서 QA를 하면서 운영 이슈까지 처리하게 됨.
• 2차 이상 대규모/장기 개발에선 서버가 꼬이고, “이게 운영 코드야? 개발 코드야?” 헷갈리기 시작!

💡 해결법: release 브랜치와 별도의 QA(릴리즈) 서버 도입

(1) Release 브랜치/서버의 역할

• 운영(main)에 바로 반영하지 않고, “운영 후보” 코드를 미리 QA하고, 안정화하는 공간
• 2차/3차 개발 등 장기 기능 개발을 진행할 때, 운영은 그대로 두고 release에서만 QA 가능
• 긴급 운영 이슈(hot-fix)는 별도 브랜치에서 처리 후, 운영/릴리즈/개발 모두에 머지

1. 브랜치 구조 및 용도

2. 브랜치 전략 시나리오

💡 전체 플로우

1. feat/ 브랜치에서 기능 단위로 개발
2. 기능 개발 완료 후 development 브랜치로 병합 (Merge)
3. 여러 기능이 모이면 release 브랜치 생성 → QA 및 배포 준비
4. release 브랜치가 안정화되면 main 브랜치로 Merge (운영 배포)
5. 운영 중 긴급 이슈 발생 시 hot-fix 브랜치 생성 → 수정 후 main 병합 및 development 브랜치는 체리픽
6. 다음 사이클 반복

🔀 브랜치 적용 예시

3. 왜 Tag를 꼼꼼하게 남겨야 할까? – “배포 롤백”이 필요한 순간

운영 배포가 끝나고, 며칠 뒤 갑자기 “운영에서 장애가 발생했다!” 빠른 복구(rollback)가 필요한데, 명확한 Tag 관리가 없다면 다음과 같은 문제가 생긴다.

실제 사례를 통해 확인해보시죠!

FE(속마음): “운영하면서 오류 사항을 그때 그때 대응하고 있는데 어떤 코드가 올라갔는지, 정확히 확인이 안 된다.
관리가 안되네.. 큰일 났다. 어떻게 해결하지?”
PO/PM: “저번주에 나간게 고객사에서 문제가 발생했네? 일단 저번주 기능 걷어내고 원복 시켜주세요.”

FE: “rollback 하고 싶어도, 어디로 돌아가야 하는지 알 수 없다… 수동으로 commit 해시 찾아서 reset 하다가, 아예 코드가 꼬였다…”

PO/PM: “언제 롤백 되나요? 금방 해결되는거 아니였어요?”

FE/BE: “잠… 잠시만요……………….”

혹시 경험해보시지 않으셨나요? 그렇다면 훌륭한 대응 전략을 가지고 있으시군요!

저는 초기 팀 빌딩시에 위와 같은 문제를 실제로 겪어보았으며 그에 따른 전략 또한 잘 준비되어야 한다고 생각합니다.

🚦 이 문제, 왜 반복이 될까?

(1) 배포 이력 관리가 안됨

• 태그 전략이 없으니, “운영에 어떤 코드가 반영되어 있는지” “이 기능이 QA가 된 건지, 미완성인지” 확인이 어렵다.

💡 해결법: Release Note 작성 및 Tag 전략 도입

(1) Release Note 작성

• 운영 배포 시, 버그 혹은 어떤 신규 기능들이 추가가 되었는지 해당 티켓 혹은 관리 시스템으로 추적을 할 수 있도록 기입을 합니다.
• Release Note 작성에는 여러가지 방법들과 유연한 방법이 있지만 배포 시간 및 대응 전략 또한 기입을 하는 것 또한 권장을 합니다.

(2) Tag 전략

• 실제 배포 버전에 따른 roles 를 정해서 버전 관리를 합니다.

3. Tag 시나리오

🎯 Tag 명명 규칙

• 운영 배포: [major].[minor].[patch] 예: 1.1.0
  • major : 대규모의 신규 기능 추가가 이루어진 경우 버전을 올릴 수 있도록 합니다.
  • minor : 부분적 기능 추가에 따른 짧은 단위의 스프린트 기능을 통해 버전을 올릴 수 있도록 합니다.
  • patch : 크리티컬 하지 않는 버전의 버그 수정이 일어날 경우 버전을 올립니다.
    • patch-r[number] : 긴급하게 수정된 버전의 경우 사용 할 수 있도록 합니다.
      • 예시:
        • Production 브랜치: prd-1.1.0
        • Hotfix 브랜치: hotfix-[issue/날짜] 예: hotfix-[티켓]-20240522
        • Production 브랜치: prd-1.1.0-r1

🔖 Tag 적용 예시

• 흐름

• Protected Tags
  • 실제 배포되거나 관리가 필요한 항목은 Protected 기능을 통해 엄격하게 관리도 가능합니다.

4. 브랜치 & 태그 관리 주의점

• Merge 순서와 대상
  • hot-fix → main → development 순으로 병합하여 이슈 누락 방지
  • release 완료 후 main과 development 모두 병합
• Tag는 운영(main) 배포 이력을 명확히 남기기 위해 반드시 main 브랜치에 부여
• 모든 브랜치는 Pull Request(PR) 기반으로 Merge 관리
• 개발 중 브랜치 이름 및 Tag 규칙은 팀 내에서 반드시 일관성 있게 유지