CI/CD 스터디 01: 소스 저장소와 브랜치 전략

CI/CD의 입력이 되는 Git 저장소, commit, branch, PR/MR, tag, CODEOWNERS를 기준으로 브랜치 전략과 릴리스 추적 방식을 정리합니다.

CI/CD의 시작점은 빌드 도구가 아니라 소스 저장소입니다. 어떤 변경을 언제 파이프라인으로 올릴지 결정하는 규칙이 흔들리면 뒤의 빌드, 테스트, 배포도 같이 흔들립니다.

컴포넌트 역할

소스 저장소는 애플리케이션 코드, 인프라 코드, 파이프라인 정의, 릴리스 노트를 함께 보관하는 기준점입니다. CI/CD에서 저장소가 하는 일은 단순 보관이 아니라 변경 이력, 리뷰 경계, 릴리스 기준, 재현 가능한 빌드 입력을 고정하는 것입니다.

  • commit: 변경 단위와 감사 단위입니다. 하나의 commit은 나중에 빌드 산출물, 이미지 태그, 배포 이력과 연결됩니다.
  • branch: 아직 운영에 올릴 준비가 되지 않은 변경을 격리합니다.
  • pull request / merge request: 리뷰, 테스트, 승인, squash/merge 정책이 모이는 게이트입니다.
  • tag: 배포 가능한 소스 스냅샷을 사람이 읽을 수 있는 버전으로 고정합니다.
  • CODEOWNERS: 특정 경로의 승인 책임자를 정해서 파이프라인 변경, 보안 정책, 운영 매니페스트가 무심코 바뀌지 않게 합니다.

브랜치 모델 선택

작은 팀은 긴 Git Flow보다 trunk-based에 가까운 방식이 운영하기 쉽습니다. 핵심은 main 브랜치를 항상 배포 가능한 상태로 유지하고, 기능 브랜치는 짧게 가져가는 것입니다. 운영 환경이 여러 개인 경우에도 브랜치를 환경 이름으로 늘리는 것보다, main 또는 release tag를 기준으로 배포 입력을 분리하는 편이 추적이 쉽습니다.

모델장점주의점
trunk-based변경이 작고 통합이 빠릅니다.자동 테스트와 리뷰 게이트가 약하면 main 품질이 바로 떨어집니다.
release branch운영 패치와 다음 개발을 분리하기 좋습니다.장기 브랜치가 많아지면 cherry-pick 지옥이 생깁니다.
Git Flow릴리스 절차가 무거운 조직에서 역할이 명확합니다.작은 서비스에는 브랜치 관리 비용이 큽니다.

저장소 점검 명령

파이프라인을 붙이기 전에 저장소의 기준 브랜치, 최근 tag, 원격 상태를 먼저 확인합니다.

git remote -v
git branch --show-current
git status --short
git log --oneline --decorate --graph -n 20
git tag --sort=-creatordate | head -n 20
git ls-remote --heads origin
git ls-remote --tags origin | tail -n 20

릴리스 tag 규칙

CI/CD에서 tag는 배포 입력으로 쓰이기 때문에 사람이 직접 만든 임의 문자열보다 일관된 규칙이 낫습니다. 애플리케이션은 SemVer를 쓰고, 운영 매니페스트만 바뀌는 경우에는 날짜 기반 tag를 병행할 수 있습니다.

# 애플리케이션 릴리스
git tag -a v1.4.0 -m "release v1.4.0"
git push origin v1.4.0

# 운영 매니페스트 변경만 묶는 경우
git tag -a deploy-20260624-01 -m "deploy manifest update 20260624-01"
git push origin deploy-20260624-01

파이프라인 변경 보호

파이프라인 파일은 운영 권한과 거의 같습니다. YAML 한 줄로 배포 대상, 이미지 registry, artifact 공개 범위가 바뀔 수 있기 때문입니다. 따라서 애플리케이션 코드보다 더 엄격하게 리뷰해야 합니다.

권장 보호 대상
- .github/workflows/**
- .gitlab-ci.yml
- Jenkinsfile
- build.gradle, pom.xml, package-lock.json 같은 빌드 입력 파일
- Dockerfile, compose.yml, helm/, kustomize/, manifests/
- scripts/deploy*, scripts/release*, scripts/migrate*

실무 체크리스트

  1. main 브랜치 직접 push를 막고 PR/MR만 허용합니다.
  2. 파이프라인 파일과 배포 매니페스트는 CODEOWNERS 또는 필수 리뷰어를 둡니다.
  3. release tag는 재사용하지 않습니다. 같은 버전 재배포가 필요하면 build metadata 또는 revision tag를 추가합니다.
  4. commit SHA, tag, 이미지 digest, 배포 revision을 하나의 릴리스 기록에 남깁니다.
  5. 브랜치 이름을 환경 상태의 source of truth로 쓰지 않습니다. 환경 상태는 deployment record, GitOps repo, release ledger에 남깁니다.

참고 문서

BGM EVER