개발 환경, 운영 환경 브랜치 전략

이주호·2025년 3월 8일

개발 환경과 운영 환경에서 어떻게 브랜치를 관리해야 할까?
브랜치는 개발자들이 병렬로 개발하고 실제 운영되는 서비스와 분리하여 개발/테스트 하기 위해 사용된다.

기본 개념

컴파일 : 개발자가 만든 코드를 컴퓨터가 이해할 수 있는 언어로 바꾸는 작업

빌드 : 컴파일된 코드를 실제 동작도록 만드는 과정. 소스코드를 변환하는 것 뿐만 아니라 리소스 포함, 의존성 관리, 패키징도 포함한다. (컴파일을 포함해 jar,war 파일을 만드는 작업을 빌드라고 하기도 함)

배포 : 빌드된 애플리케이션을 특정 환경(개발, 스테이징, 운영)에 배치하여 실행할 수 있도록 하는 과정.

스테이징 환경(Staging) : 운영환경과 거의 유사한 환경. 운영 환경으로 넘어가기 전 최종 점검하는 테스트환경이다.

운영 환경(Production) : 실제 사용자들이 서비스를 이용하는 환경으로 운영 환경으로 넘어가기 전 스테이징 환경에서 최종적으로 모든 테스트를 마쳐야 한다. 장애 발생시 롤백 가능하도록 설정하는 것이 중요하다.

개발 환경 브랜치 전략

1. Git Flow 전략

배포 주기가 긴 대규모 프로젝트에 적합한 브랜치 전략.
주요 브랜치로 main , develop 브랜치를 가지고 보조 브랜치로 feature, release, hoxfix 브랜치가 있다.

main

  • 항상 안정적인 상태의 코드만 포함. 프로덕션에 최종적으로 배포되는 코드가 저장되는 브랜치

develop

  • 기능 개발의 기본 브랜치로 모든 새로운 기능 브랜치들이 병합되고 테스트 되는 브랜치. 기능 개발이 완료되면 main 브랜치로 병합하여 배포할 준비를 한다.

feature

  • 신기능을 개발하는 브랜치. develop 브랜치에서 분기하며 개발 완료시 develop 브랜치로 병합한다.

release

  • 배포 전에 테스트하고 버그를 수정하는 브랜치. develop에서 분기되며, 배포 준비가 완료되면 main과 develop에 병합된다.

hotfix

  • 프로덕션에서 발생한 긴급한 버그를 수정하기 위한 브랜치. main 브랜치에서 분기되며, 수정 후 main과 develop 브랜치에 병합된다.

Git Flow 예제 CLI

git branch develop
git checkout develop
git branch feature/a
git checkout feature/a
git commit - m 'service a'
git commit - m 'service a2'
git checkout master
git branch hotfix
git checkout hotfix
git commit -m 'bug fix'
git checkout master
git merge hotfix
git checkout develop
git merge hotfix

git merge feature/a -m 'merge feature/a into develop'
git branch release
git checkout release
// 테스트 완료 커밋 추가
git commit -m 'relaese: finish test'

git checkout develop
git merge release -m 'merge relase into develop'

git checkout main
git merge release -m 'merge release into main'

위의 그림을 보면 알겠지만 브랜치가 너무 많아 복잡하다. 체계적인 브랜치 관리가 가능하고 여러 기능을 병렬적으로 개발할 수 있다는 장점이 있지만 브랜치가 많아 관리가 복잡하다는 단점이 있다. CI/CD 환경이 발전하면서 GitHub Flow나 Trunk-Based Development(TBD) 같은 단순한 전략이 더 선호된다. 간소화된 전략중 하나인 GitLab Flow를 알아보자.

GitLab Flow

GitLab Flow는 Git Flow보다 단순하면서도 CI/CD에 최적화된 브랜치 전략.
Git Flow는 develop, feature, release, hotfix 등 다양한 브랜치를 사용하지만,
GitLab Flow는 보다 간단한 브랜치 구조로 유지보수와 배포를 쉽게 만들었다.

GitLab Flow 기본 개념

GitLab Flow의 3가지 모델
1. Production Branch Model (기본적인 GitLab Flow)
2. Environment Branch Model (운영 환경별 브랜치 전략)
3. Release Branch Model (버전 릴리스 전략)

1. 기본 GitLab Flow (Production Branch Model)

✔ 브랜치 구조:

main  -----> (프로덕션 배포)
  |
  |-- feature/*  -----> (기능 개발 후 main으로 Merge Request)

동작 방식:

  • main 브랜치는 항상 운영 환경(Production) 코드를 유지.

  • 새 기능은 feature 브랜치에서 개발 후, Merge Request(MR, PR)를 생성.

  • 코드 리뷰 후 main에 병합되면 자동으로 배포(CI/CD 활용).

    차이점:

  • Git Flow처럼 develop, release 브랜치 없이 직접 main으로 병합!

  • 빠른 배포(Continuous Deployment, CD)를 목표로 함.

  • feature 브랜치에서 충분히 테스트한 후 main으로 병합해야 함.

✔ 사용 예시:
스타트업, 빠르게 배포하는 SaaS 서비스, 지속적 배포가 필요한 프로젝트.

2. 환경 기반 브랜치 전략 (Environment Branch Model)

✔ 브랜치 구조:

main       -----> (프로덕션 배포)
  |
  |-- staging  -----> (사전 테스트 환경)
  |     |
  |     |-- feature/*  -----> (기능 개발 후 staging으로 MR)

동작 방식:

  • feature 브랜치에서 개발 후 staging 브랜치로 병합 (테스트 환경)
  • staging에서 QA 테스트 후, 이상 없으면 main으로 병합하여 프로덕션 배포

차이점:

  • 프로덕션(main)에 직접 병합하기 전에 staging을 거쳐 안정성을 확보.
  • 테스트를 철저히 해야 하는 서비스(ex. 금융, 의료, 대기업 프로젝트)에 적합.

✔ 사용 예시:
금융 서비스, 의료 시스템, 보안이 중요한 프로젝트.

3. 릴리스 브랜치 전략 (Release Branch Model)

✔ 브랜치 구조:

main         -----> (최신 안정 릴리스)
  |
  |-- release/2.0  -----> (v2.0 릴리스 준비)
  |      |
  |      |-- hotfix/2.0.1  -----> (긴급 수정 후 release 브랜치에 반영)

동작 방식:

  • 특정 버전을 릴리스할 때, release/* 브랜치를 생성해 안정화.
  • 버그 수정이 필요하면 hotfix/* 브랜치를 만들어 수정 후 release/*에 병합.
  • 안정화된 버전이 되면 main에 병합 후 배포.

차이점:

  • Git Flow와 비슷하지만 release 브랜치만 사용해 복잡도를 줄임.
  • 특정 버전 릴리스 후 유지보수가 필요할 때 유용.

✔ 사용 예시:
소프트웨어 버전 관리가 중요한 프로젝트 (ex. 대형 애플리케이션, 패키지 소프트웨어, 게임 개발).

GitLab Flow vs Git Flow 차이점

GitLab FlowGit Flow
브랜치 개수적음 (단순)많음 (복잡)
배포 방식지속적 배포 (CI/CD 중심)릴리스 중심
테스트 환경staging 브랜치 사용 가능develop, release 브랜치 사용
사용 사례빠른 배포가 필요한 서비스전통적인 소프트웨어 개발

GitLab Flow는 배포를 빠르게 하고, 브랜치 관리를 단순하게 하는 데 초점을 맞춘다!
Git Flow는 여러 브랜치를 활용해 명확한 배포 프로세스를 유지하는 데 중점을 둔다!

정리

개발 환경에서는 GitLab Flow의 (환경 기반 브랜치) 전략이 유효해 보이고, 운영 환경에서는 Git Flow나 GitLab Flow (릴리스 브랜치 전략)이 유효해보인다.

개발환경에서는 GitLab Flow (환경 기반 브랜치 전략)

GitLab Flow (환경 기반 브랜치 전략)은 개발, 테스트, 운영 등 환경별로 브랜치를 나누는 방식으로 개발환경에서 다음과 같은 이점이 있다.

1) 환경별 배포 안정성 유지

  • 개발 환경에서는 지속적인 기능 개발과 통합 테스트가 이루어지므로,
    develop 같은 중앙 브랜치 없이 환경별 브랜치를 두면 각 환경에서 안정성을 유지할 수 있음.
  • 예시:
    main        (운영 환경 - 프로덕션 배포)
  |
  |--- staging   (테스트 환경 - QA)
  |--- develop   (개발 환경 - 내부 테스트)
  |--- feature/* (기능 개발 브랜치)
  • 이런 구조를 사용하면, 각 환경에서 독립적으로 테스트하고 안정성을 확보한 후, 상위 환경으로 배포할 수 있음.

2) CI/CD 자동 배포와 궁합이 좋음

  • GitLab Flow에서는 환경별 브랜치를 CI/CD 파이프라인과 연결해서 자동 배포를 설정할 수 있음.
    (GitLab Flow의 환경 기반 브랜치 전략을 적용하면 각 브랜치가 특정 서버(환경)와 연결됨.
    즉, 코드가 특정 브랜치에 병합되면 자동으로 해당 환경으로 배포할 수 있음)
  • 예시:
    CI/CD 자동 배포 예제
    - feature/* → 코드 검토 후 develop에 병합 → 개발 서버 자동 배포
    - develop → 테스트 후 staging에 병합 → QA 환경 자동 배포
    - staging → 운영 준비 완료 후 main에 병합 → 프로덕션 자동 배포

따라서 각 브랜치가 특정 환경과 연결되어 있어, 배포 자동화에 적합함.

3) 빠른 피드백 루프 가능

  • 개발 환경에서는 기능 개발 후 바로 통합 테스트가 필요함.
  • GitLab Flow를 사용하면, feature/* 브랜치를 develop에 병합하면서 바로 테스트 가능.
  • 기능을 개발하면서 테스트를 빠르게 진행하고, 환경별 안정성을 확보할 수 있음.

결론:
-> 환경 기반 브랜치 전략을 사용하면 환경별 배포 안정성을 유지하면서도, CI/CD와 연계하여 자동 배포 및 빠른 피드백이 가능하기 때문에 개발 환경에서 유효함.

운영 환경에서는 "Git Flow" 또는 "GitLab Flow (릴리스 브랜치 전략)"

운영 환경에서는 안정성과 긴급 대응이 중요하기 때문에, Git Flow 또는 GitLab Flow의 릴리스 브랜치 전략이 적합하다.

1) 운영 환경에서는 "안정적인 코드만 배포"가 핵심

  • 운영 시스템은 레거시 코드와 신규 코드가 공존하는 경우가 많고, 즉시 배포가 어렵기 때문에, 철저한 테스트 후 배포해야 함.
  • 운영 환경에서는 release/* 브랜치를 사용하면, 운영 배포 전 충분한 QA 및 승인 프로세스를 거칠 수 있음.
  • 예시:
    main        (운영 환경 - 최종 안정 코드)
  |
  |--- release/v1.2   (릴리스 브랜치 - 운영 전 최종 검증)
  |--- hotfix/*       (긴급 수정 브랜치 - 운영 이슈 대응)
  • 운영 환경에서는 기능 개발 속도보다는 "안정성"이 중요하기 때문에, Git Flow의 release 브랜치를 활용하면 안정적인 배포가 가능.

2) "긴급 패치 대응 (Hotfix)"를 고려해야 함

  • 병원 시스템 같은 운영 환경에서는 긴급한 버그 수정(Hotfix)이 필요할 가능성이 높음.
  • Git Flow에서는 hotfix/* 브랜치를 사용하여, 운영 브랜치(main)에서 바로 긴급 패치를 적용하고, 이후 develop에도 반영.
  • 예시:
    git checkout -b hotfix/urgent-bugfix main
# 버그 수정 후 main에 반영
git checkout main
git merge hotfix/urgent-bugfix
git push origin main
# 이후 develop에도 반영
git checkout develop
git merge hotfix/urgent-bugfix
git push origin develop

3) 릴리스 브랜치를 사용하면 "운영 승인 및 테스트 프로세스"를 강화할 수 있음

  • 운영 환경에서는 단순히 코드가 통합되었다고 바로 배포하는 것이 아니라, 배포 전 검증 과정이 필요함.
  • GitLab Flow의 릴리스 브랜치를 사용하면, 운영 환경에 맞춰 최종 QA 테스트, 문서 작업, 승인 절차를 진행할 수 있음.

결론:
운영 환경에서는 안정적인 배포와 긴급 패치 대응이 중요하기 때문에, Git Flow의 release/* & hotfix/* 브랜치를 활용하면 운영 환경에서 유효함.
GitLab Flow의 릴리스 브랜치를 사용하면, 운영 환경에서 배포 안정성을 더욱 강화할 수 있음.

최종 정리

환경유효한 브랜치 전략이유
개발 환경GitLab Flow (환경 기반 브랜치 전략)환경별 브랜치를 두고, CI/CD 자동 배포 및 빠른 피드백 가능
운영 환경Git Flow 또는 GitLab Flow (릴리스 브랜치 전략)운영 배포 안정성 확보, release/* 브랜치로 검증 후 배포, hotfix/*로 긴급 대응 가능

✔ 개발 환경에서는 GitLab Flow의 환경 기반 브랜치 전략이 CI/CD와 잘 맞기 때문에 유용함
✔ 운영 환경에서는 안정성과 긴급 대응이 중요하기 때문에 Git Flow 또는 GitLab Flow (릴리스 브랜치 전략)이 적합함

[참고]

profile
이주호
코드 위에서 춤추고 싶어요
이전 포스트

가상화 기술 (feat. 도커, 쿠버네티스)

다음 포스트

HTTP 학습 - 인터넷 네트워크 (IP, TCP/UDP, PORT, DNS)

0개의 댓글