GitOps - 브랜치 전략과 폴더 구조, 개발의 상식이 운영의 안티패턴이 되는 이유

개요

이전 ArgoCD 시리즈에서는 구축(Helm 기반 설치), Application CR, ApplicationSet까지 "ArgoCD를 어떻게 구성하고 자동화할 것인가"를 정리했습니다.

 

이번 글에서는 한 단계 앞으로 돌아가, GitOps를 운영할 때 Git 레포지토리의 브랜치 전략과 폴더 구조를 어떻게 잡아야 하는가를 정리합니다.

 

ArgoCD를 실무에 도입하면서 처음에는 개발에서 사용하던 브랜치 전략을 그대로 가져왔습니다. dev, staging, prod 브랜치를 나누고, 각 브랜치 안에서 Kustomize의 overlay 폴더 구조를 유지하는 방식이었습니다. 개발에서 익숙한 방식이었고, 당연히 운영에서도 통할 것이라고 생각했습니다.

 

그러나 이 구조를 팀원에게 공유하고, 실제로 운영하는 과정에서 여러 문제를 겪었습니다. 브랜치도 나뉘고 폴더도 나뉜 구조를 도식화하여 설명하는 것부터 쉽지 않았고, 이 어려움이 단순히 이해의 문제가 아니라 구조 자체에 기인한다는 점을 점차 체감하게 되었습니다.

 

이 글에서는 개발에서 통용되는 브랜치 전략이 GitOps 운영 환경에서 왜 적합하지 않은지를 분석하고, Kustomize의 overlay 구조에서 착안한 폴더 기반 환경 분리가 운영에서 어떤 이점을 가지는지를 정리합니다.

"개발에서 당연한 것이 운영에서는 안티패턴이 될 수 있다"

 

이 글이 배포와 인프라를 관리하는 운영 관점에서, 브랜치와 폴더 구조를 설계할 때 참고할 수 있는 내용이 되었으면 합니다.

---

개발에서의 브랜치 전략

 

GitOps에서의 브랜치를 논하기 전에, 개발에서 통용되는 브랜치 전략을 짚고 넘어가겠습니다. 이 글에서 다루는 "개발의 상식"이 무엇인지를 정의해 두기 위함입니다.

 

소프트웨어 개발에서 널리 사용되는 브랜치 전략은 크게 세 가지입니다.

GitFlow

master와 develop 두 개의 영구 브랜치를 중심으로, feature, release, hotfix 브랜치를 운영하는 구조화된 모델입니다. 계획된 릴리스 주기와 여러 버전의 동시 유지에 적합합니다.

master ─────────────────────────── (프로덕션)
  │              ↑           ↑
  └── develop ───┼───────────┤ (개발 통합)
        │        │           │
        ├─ feature/login ────┘
        ├─ feature/payment ──┘
        └─ release/1.2.0 ───────→ master (태그)

GitHub Flow

영구 브랜치는 main 하나뿐이고, 모든 변경은 feature 브랜치에서 Pull Request를 통해 병합하는 경량 모델입니다. 지속적 배포 환경에 적합합니다.

main ─── [커밋] ─── [커밋] ─── [커밋] ─── (항상 배포 가능)
           ↑           ↑           ↑
     feature/A    bugfix/B    feature/C

Trunk-Based Development

모든 개발자가 하나의 trunk에 빈번하게 커밋하며, feature 브랜치를 사용하더라도 1~2일 이내로 유지하는 모델입니다. Google, Facebook 등 대규모 조직에서 검증된 방식입니다.

trunk ─── [커밋] ─── [커밋] ─── [커밋] ─── [커밋] ─── (매일 통합)
            ↑                     ↑
      feature(1일)          feature(1일)

 

세 전략은 브랜치 수와 수명, 배포 주기에서 차이가 있지만, 공통적으로 소프트웨어 개발의 빌드-테스트-배포 파이프라인을 전제로 설계되었습니다.

코드 변경 → 브랜치에서 격리 → 병합 → 빌드 → 테스트 → 배포

개발에서 브랜치의 핵심 역할은 "코드를 격리하고 병합하는 것"입니다. 동시에 여러 기능을 작업하고, 안정된 코드와 불안정한 코드를 분리하기 위해 브랜치를 나눕니다.

 

이것이 개발에서의 상식이며, 대부분의 개발자가 자연스럽게 체득하는 사고방식입니다.

이 상식이 문제가 되는 지점은, 같은 사고를 운영 환경의 Git 레포지토리에도 적용할 때 발생합니다.

---

개발의 브랜치를 운영에 가져오면

개발에서 환경별로 브랜치를 나누는 것은 자연스러운 발상입니다. dev 브랜치에서 개발하고, staging으로 병합해서 검증하고, 최종적으로 prod에 병합하여 배포한다. 코드의 흐름과 배포의 흐름이 일치하기 때문에 개발에서는 합리적인 구조입니다.

 

GitOps 환경에서도 같은 방식을 적용했습니다. dev, staging, prod 브랜치를 나누고, 각 브랜치 안에서 Kustomize의 base/overlay 폴더 구조를 유지하는 방식이었습니다. 지금에 와서는 둘 다 나눌 필요가 없었지만, 개발을 하다 보니 무감각하게 브랜치 분리와 폴더 분리를 혼용했던 것 같습니다.

 

이 구조에서 겪은 문제는 크게 세 가지였습니다.

설명할 수 없는 구조

이 구조를 팀원에게 공유할 때 가장 먼저 부딪힌 문제는 도식화가 어렵다는 점이었습니다.

[dev 브랜치]                    [prod 브랜치]
├── base/                       ├── base/
│   ├── deployment.yaml         │   ├── deployment.yaml
│   └── service.yaml            │   └── service.yaml
├── overlays/                   ├── overlays/
│   ├── dev/                    │   ├── dev/      ← ?
│   ├── staging/                │   ├── staging/  ← ?
│   └── prod/                   │   └── prod/

 

"브랜치도 나뉘고 폴더도 나뉩니다"를 설명해야 하는데, 청자 입장에서는 "왜 둘 다 나뉘어야 하는가?"라는 질문이 자연스럽게 나옵니다. dev 브랜치에 prod 폴더가 존재하고, prod 브랜치에 dev 폴더가 존재하는 상황은 직관적으로 납득이 되지 않습니다.

 

남에게 설명하기 어려운 구조는 운영하기도 어렵습니다. 이 구조를 처음 접하는 사람에게 배포 흐름을 한 장의 그림으로 설명할 수 없다면, 그것은 이해력의 문제가 아니라 구조의 문제입니다.

2차원 탐색의 비용

유지보수 과정에서 환경 간 상태를 비교해야 하는 상황은 빈번하게 발생합니다. dev 환경의 설정이 어떻게 되어있는지 확인하고, prod와 비교해야 할 때 이 구조에서는 다음과 같은 과정을 거치게 됩니다.

dev 상태 확인:    dev 브랜치 checkout  → overlays/dev/ 확인
prod 상태 확인:   prod 브랜치 checkout → overlays/prod/ 확인
비교:            두 브랜치를 오가며 diff

 

브랜치 축과 폴더 축, 두 개의 차원을 넘나들어야 비로소 하나의 환경 상태를 파악할 수 있습니다.

 

개발에서는 동일한 소스코드의 서로 다른 버전을 브랜치로 관리하기 때문에 브랜치 간 이동이 자연스럽지만, 운영에서는 각 환경의 상태가 서로 다른 의도를 가지고 있습니다. 비교 대상이 "버전"이 아니라 "환경"인 상황에서, 브랜치를 오가는 것은 불필요한 비용입니다.

Merge Flow의 복잡성

dev에서 변경한 내용을 prod에 반영해야 할 때, 단순히 브랜치를 병합하면 되지 않습니다. 환경별로 다른 설정이 overlay 폴더에 존재하기 때문에, dev 브랜치의 변경을 prod 브랜치로 merge 할 때 prod overlay 폴더의 값은 별도로 수정해야 합니다.

1. dev 브랜치에서 base/ 수정
2. dev 브랜치에서 overlays/dev/ 수정
3. prod 브랜치로 merge
4. 그런데 overlays/prod/는 dev 브랜치에서 수정한 게 아니므로 별도 수정 필요
5. prod 브랜치의 overlays/prod/를 직접 수정
6. 만약 staging도 있다면 같은 과정 반복

 

"dev에서 수정해서 prod로 merge하면 되는 거 아닌가요?" — 이 질문에 대한 답이 간단하지 않다는 것 자체가 이 구조의 한계를 보여줍니다.

구조적으로 발생하는 문제

위의 경험적 문제들은 개인의 미숙함이 아니라, 환경별 브랜치 전략이 가진 구조적 문제에서 비롯됩니다.

Cherry-pick과 Merge Conflict의 누적

환경별 브랜치를 유지하면, 하나의 변경사항을 여러 브랜치에 반영해야 합니다.

 

prod에 긴급 패치를 적용한 뒤 dev에도 같은 패치를 반영하려면 cherry-pick이 필요하고, 브랜치 간 이미 갈라진 히스토리 위에서 cherry-pick은 conflict를 유발합니다. 환경이 N개면 잠재적 conflict 경로는 N²에 비례하여 증가합니다.

Configuration Drift

브랜치가 분리된 시점부터 각 브랜치는 독립적으로 진화합니다.

 

Codefresh의 GitOps 가이드에서는 이 drift를 "환경별 브랜치에서 가장 심각한 문제"로 지목하고 있습니다. 그 근거는 다음과 같습니다.

• 환경별 브랜치가 각각 독립된 히스토리를 가지기 때문에, 시간이 지날수록 브랜치 간 차이가 누적된다
• 이 차이가 의도된 환경별 설정 차이인지, 관리 누락으로 인한 불일치인지를 구분할 수 없게 된다
• 브랜치 간 단순 diff로는 의도된 차이와 drift를 분리해 낼 수 없다

이 불투명함이 운영 신뢰도를 떨어뜨리고 이 구조를 운영하면서 drift가 가장 뚜렷하게 드러난 지점은 overlay 폴더입니다.

 

prod 브랜치에서 작업하는 사람은 실제로 배포가 이루어지는 overlays/prod/에 집중하게 되고, 같은 브랜치에 존재하는 overlays/dev/나 overlays/staging/은 배포 대상이 아니기 때문에 관리 우선순위에서 밀립니다. 반대로 dev 브랜치에서도 마찬가지입니다.

[dev 브랜치]                         [prod 브랜치]
├── overlays/                        ├── overlays/
│   ├── dev/   ← 실제 배포 대상       │   ├── dev/   ← 구조 맞추기용
│   ├── staging/ ← 구조 맞추기용      │   ├── staging/ ← 구조 맞추기용
│   └── prod/  ← 구조 맞추기용        │   └── prod/  ← 실제 배포 대상

 

실제 배포에 사용되지 않는 폴더는 구조적 일관성을 위해 존재할 뿐이고, 이런 폴더는 언제나 관리에서 후순위가 됩니다.

 

결과적으로 dev 브랜치의 overlays/prod/와 prod 브랜치의 overlays/prod/가 미세하게 달라지기 시작합니다. 이 차이는 처음에는 사소하지만, 축적되면 환경 간 비교 자체를 신뢰할 수 없게 만듭니다.

Single Source of Truth의 상실

GitOps의 핵심 원칙은 Git이 인프라의 단일 진실 공급원(Single Source of Truth)이 되는 것입니다.

 

환경별 브랜치 구조에서 prod 환경의 실제 상태는 prod 브랜치의 overlays/prod/에, dev 환경은 dev 브랜치의 overlays/dev/에 있습니다. 이 구조를 설계한 사람은 이 경로를 알고 있습니다. 그러나 같은 팀원이 "지금 prod에 배포된 상태를 확인하려면 어디를 봐야 하는가?"라는 질문을 받았을 때, 어떤 브랜치의 어떤 폴더까지 찾아가야 실제 상태인지 바로 답하기 어렵습니다.

 

ArgoCD나 GitOps의 구조에 익숙하지 않은 팀원이라면 이 혼동은 더 깊어집니다.

 

그리고 이것은 개인의 이해도 문제가 아니라, 구조 자체가 만들어낸 진입 장벽입니다. "어떤 브랜치의 어떤 폴더가 진짜 상태인가?"라는 질문에 팀 전체가 확신 있게 답할 수 없다면, Git은 이미 진실 공급원의 역할을 하지 못하고 있습니다. GitOps를 도입한 근본적인 이유가 훼손됩니다.

---

운영에서 Git의 역할은 다르다

앞서 다룬 문제들은 운영 미숙이나 관리 소홀의 문제가 아닙니다. 브랜치를 나누고 폴더를 나누는 것이 왜 이렇게까지 복잡해지는지를 파고들면, 개발과 운영에서 Git이 담당하는 역할 자체가 다르다는 지점에 도달하게 됩니다.

개발에서 Git은 소스코드 저장소다

개발에서 Git 레포지토리에 저장되는 것은 소스코드입니다. 이 코드는 그 자체로는 동작하지 않습니다. 빌드 과정을 거쳐 아티팩트(바이너리, 컨테이너 이미지 등)가 생성되고, 이 아티팩트가 환경에 배포되어 비로소 동작합니다.

[개발]
소스코드 → 빌드 → 아티팩트 → 배포 → 동작
  (Git)                              (환경)

 

Git에 저장된 코드와 실제 환경에서 동작하는 것 사이에는 빌드라는 변환 과정이 존재합니다. 브랜치는 이 변환 이전 단계에서 코드를 격리하고 병합하는 도구이며, 같은 코드의 서로 다른 버전을 관리하는 것이 목적입니다.

운영에서 Git은 선언적 상태 저장소다

GitOps 환경에서 Git 레포지토리에 저장되는 것은 소스코드가 아니라 인프라의 선언적 상태(Desired State)입니다. Kubernetes 매니페스트, Helm values, Kustomize overlay 등으로 정의된 이 상태는 빌드 과정 없이 그대로 클러스터에 적용됩니다.

[운영 - GitOps]
선언적 상태 ──────────────→ 클러스터에 적용 → 동작
   (Git)        (ArgoCD/Flux가 동기화)      (환경)

 

Git에 저장된 상태가 곧 환경의 상태입니다. 중간에 변환 과정이 없기 때문에, Git의 내용과 환경의 상태는 항상 일치해야 합니다. 이것이 GitOps에서 Git을 Single Source of Truth로 부르는 이유입니다.

목적이 다르면 도구의 사용법도 달라야 한다

개발운영 (GitOps)

Git에 저장되는 것	소스코드	선언적 상태 (Desired State)
Git과 환경의 관계	빌드를 거쳐 간접 연결	직접 연결 (Git = 환경)
브랜치의 역할	코드 격리와 병합	—
핵심 관심사	동시 개발, 버전 관리	환경 간 상태 비교와 추적

 

개발에서 브랜치를 나누는 이유는 "같은 코드의 서로 다른 버전을 격리"하기 위함입니다. feature 브랜치에서 작업하는 동안 main의 안정성을 보장하고, 완성되면 병합합니다. 동일한 소스의 여러 버전이 존재하는 것이 자연스럽습니다.

 

운영에서는 이 논리가 성립하지 않습니다. dev 환경과 prod 환경은 "같은 상태의 서로 다른 버전"이 아니라, "서로 다른 의도를 가진 서로 다른 상태"입니다. dev에는 replicas: 1, 낮은 리소스 제한이 있고, prod에는 replicas: 3, HPA, 높은 리소스 제한이 있습니다. 이것은 버전의 차이가 아니라 환경의 차이입니다.

 

버전의 차이를 관리하는 도구(브랜치)로 환경의 차이를 관리하려 하면, 앞서 다룬 문제들이 구조적으로 발생합니다. 브랜치와 폴더라는 두 축이 생기고, 2차원 탐색이 필요해지며, drift가 누적됩니다.

 

운영에서 필요한 것은 격리가 아니라 비교, 추적, 그리고 축적입니다. 환경 간 상태의 차이를 한눈에 파악할 수 있어야 하고, 변경 이력을 추적할 수 있어야 하며, 나날이 쌓이는 운영 데이터가 하나의 히스토리 위에 축적되어야 합니다.

 

그렇다면 브랜치를 나누지 않고 이 요구사항을 충족하는 구조는 어떤 형태가 되어야 할까요.

---

운영에서의 브랜치 전략

 

단일 main 브랜치에서 모든 환경의 상태를 관리하고, 변경은 Pull Request를 통해 병합하는 구조입니다.

main ─── [커밋] ─── [커밋] ─── [커밋] ─── (모든 환경의 상태)
           ↑           ↑           ↑
      PR: dev설정    PR: prod설정   PR: base수정
      변경           변경           변경

 

브랜치는 환경 분리의 도구가 아니라, 변경 사항을 리뷰하기 위한 임시 공간으로만 사용됩니다. feature 브랜치나 fix 브랜치를 생성하고, PR을 통해 리뷰를 거친 뒤 main에 병합하고, 브랜치는 삭제합니다.

왜 단일 브랜치인가

앞서 운영의 핵심 관심사를 비교, 추적, 축적으로 정리했습니다. 단일 브랜치는 이 세 가지를 구조적으로 보장합니다.

비교: 모든 환경의 상태가 같은 브랜치에 존재하므로, 브랜치를 오갈 필요 없이 폴더 간 diff로 즉시 비교할 수 있습니다.

# 환경별 브랜치 구조에서의 비교
git checkout dev && cat overlays/dev/deployment.yaml
git checkout prod && cat overlays/prod/deployment.yaml
# 두 브랜치를 오가며 비교

# 단일 브랜치 구조에서의 비교
diff overlays/dev/deployment.yaml overlays/prod/deployment.yaml
# 한 줄로 비교 완료

 

추적: 모든 변경이 하나의 브랜치 히스토리에 기록되므로, 누가 언제 어떤 환경의 설정을 변경했는지 git log만으로 확인할 수 있습니다.

 

축적: 환경별 브랜치에서는 각 브랜치가 독립된 히스토리를 가지지만, 단일 브랜치에서는 모든 환경의 변경 이력이 하나의 히스토리 위에 축적됩니다. 시간이 지날수록 운영의 맥락이 하나의 타임라인에 쌓입니다.

ArgoCD와의 연결

ArgoCD에서도 이 구조는 자연스럽게 대응됩니다. 환경별 브랜치 구조에서는 Application마다 targetRevision을 dev, prod 등으로 나눠야 했지만, 단일 브랜치에서는 모든 Application이 같은 main 브랜치를 바라보고 path만 다르게 지정하면 됩니다.

---

Kustomize overlay에서 착안한 폴더 구조

Kustomize의 base/overlay 구조를 처음부터 채택한 이유는, 공통 리소스를 한 곳에서 관리하고 환경별 차이만 분리하는 방식이 파일 관리에 효율적이라고 판단했기 때문입니다.

app/
├── base/                    # 공통 리소스
│   ├── deployment.yaml
│   ├── service.yaml
│   └── kustomization.yaml
└── overlays/                # 환경별 차이만
    ├── dev/
    │   └── kustomization.yaml
    ├── staging/
    │   └── kustomization.yaml
    └── prod/
        ├── kustomization.yaml
        └── hpa-patch.yaml

 

base/에는 모든 환경에 공통으로 적용되는 리소스를 정의하고, overlays/에는 각 환경에서 달라지는 부분만 패치 형태로 관리합니다. 환경마다 전체 매니페스트를 복제하지 않기 때문에 중복이 최소화되고, 변경이 필요할 때 base/를 수정하면 모든 환경에 반영됩니다.

이 구조가 운영의 논리와 맞는 이유

앞서 운영의 핵심 관심사를 비교, 추적, 축적으로 정리했습니다. Kustomize의 base/overlay 구조는 이 세 가지와 정확히 대응합니다.

 

비교: 모든 환경이 같은 브랜치의 같은 디렉토리 트리 안에 존재합니다. dev와 prod의 차이를 확인하려면 overlays/ 하위의 두 폴더를 비교하면 됩니다.

diff overlays/dev/kustomization.yaml overlays/prod/kustomization.yaml

 

환경별 브랜치 구조에서 두 브랜치를 오가며 비교해야 했던 것과 대조됩니다. 같은 디렉토리 트리 안에 있기 때문에 1차원 탐색으로 충분합니다.

 

추적: base/의 변경은 모든 환경에 영향을 주는 공통 변경이고, overlays/의 변경은 특정 환경에만 영향을 주는 환경별 변경입니다. 변경의 범위가 폴더 경로만으로 구분됩니다.

git log -- base/          # 공통 변경 이력
git log -- overlays/dev/  # dev 환경 변경 이력
git log -- overlays/prod/ # prod 환경 변경 이력

 

축적: 모든 환경의 변경이 하나의 main 브랜치 위에 축적됩니다. base/를 수정한 커밋, dev overlay를 수정한 커밋, prod overlay를 수정한 커밋이 모두 하나의 타임라인에 기록됩니다. 환경별 브랜치에서는 흩어져 있던 히스토리가, 이 구조에서는 하나로 모입니다.

공통과 차이의 분리

이 구조의 핵심은 "공통은 한 곳에, 차이만 분리"라는 원칙입니다. 이것은 Kustomize에 한정된 이야기가 아니라, 폴더 구조를 설계할 때의 방향성입니다.

 

Kustomize의 base/overlay를 사용한다면 base/에서 Deployment의 기본 구조를 정의하고, overlay에서 환경별로 달라지는 값만 패치하는 형태가 됩니다. Helm을 사용한다면 base/에 공통 values.yaml을 두고, overlays/ 각 환경에 환경별 values.yaml을 두는 형태가 될 수 있습니다.

# Kustomize 방식
app/
├── base/
│   ├── deployment.yaml       # 공통 리소스
│   └── kustomization.yaml
└── overlays/
    ├── dev/
    │   └── kustomization.yaml  # dev 패치
    └── prod/
        └── kustomization.yaml  # prod 패치

# Helm 방식
app/
├── base/
│   ├── Chart.yaml
│   ├── templates/
│   └── values.yaml           # 공통 values
└── overlays/
    ├── dev/
    │   └── values.yaml        # dev values
    └── prod/
        └── values.yaml        # prod values

 

구현 도구가 다르더라도 구조는 동일합니다. 공통 정의가 한 곳에 있고, 환경별 차이만 각 폴더에 존재합니다. Kustomize나 Helm이 아닌 다른 도구를 사용하더라도, 이 방향성을 기준으로 폴더 구조를 잡는 것이 운영에서는 유리합니다.

 

이 방향성이 운영에서 유리한 이유는, "dev와 prod가 정확히 무엇이 다른가?"라는 질문에 overlay 폴더만 보면 답할 수 있기 때문입니다. 환경마다 전체 매니페스트를 복제하는 방식에서는 두 파일 전체를 diff 해야 하고, 변경점이 아닌 전체를 비교해야 하므로 의도된 차이와 실수로 생긴 차이를 구분하기 어렵습니다.

폴더 구조의 선택지

이 원칙 위에서 폴더 구조를 잡을 때 크게 두 가지 방식이 있습니다.

 

앱별 > 환경별

apps/
├── app-a/
│   ├── base/
│   └── overlays/
│       ├── dev/
│       ├── staging/
│       └── prod/
└── app-b/
    ├── base/
    └── overlays/

 

애플리케이션 단위로 base/overlay가 독립적으로 존재합니다. 팀별로 담당 앱의 폴더만 관리하면 되기 때문에 책임 범위가 명확합니다.

 

환경별 > 앱별

environments/
├── dev/
│   ├── app-a/
│   └── app-b/
├── staging/
└── prod/

 

환경 단위로 묶이기 때문에 특정 환경의 전체 상태를 한눈에 파악할 수 있습니다. 환경별 정책 관리나 접근 제어가 필요한 경우에 적합합니다.

 

어떤 방식을 선택하든, 그리고 어떤 도구를 사용하든, 단일 브랜치 위에서 폴더로 환경을 분리하고, 공통과 차이를 구조적으로 나눈다는 원칙은 동일합니다.

---

정리/회고

이 글은 GitOps에서 브랜치와 폴더 구조를 어떻게 잡아야 하는가라는 질문에서 출발했습니다.

 

개발에서 익숙한 방식대로 환경별 브랜치를 나누고 Kustomize overlay를 유지했을 때, 설명하기 어렵고 유지보수하기 어려운 구조가 만들어졌습니다. 그 원인을 파고들면, 개발에서 Git은 코드를 격리하고 병합하는 도구이지만 운영에서 Git은 선언적 상태를 비교하고 추적하고 축적하는 도구라는 근본적인 차이에 도달합니다.

 

단일 브랜치 위에서 폴더로 환경을 분리하고, 공통과 차이를 구조적으로 나누는 방향이 운영의 논리에 맞는 이유를 정리했습니다.

이 내용을 정리하면서 느낀 것은, 이것이 GitOps에만 해당하는 이야기가 아니라는 점입니다.

 

배포하고, 관리하고, 유지보수하는 운영의 관점에서는 개발에서 당연하게 사용하던 패턴이 오히려 복잡성을 만들어내는 경우가 있습니다. 개발에서의 브랜치 전략이 그랬고, 환경 분리 방식이 그랬습니다. 개발의 상식으로 운영 구조를 설계하면, 의도와 달리 운영에서의 안티패턴이 될 수 있습니다.

 

GitOps를 구현하고 운영하면서 여러 어려움을 겪었고, 그 과정에서 개선하게 된 내용을 정리한 글입니다. 운영 환경에서 브랜치와 폴더 구조를 설계할 때, 개발의 관성으로 접근하기보다 운영이 요구하는 비교, 추적, 축적의 관점에서 한 번 더 검토해 볼 필요가 있지 않을까 생각합니다.

 

이 글이 비슷한 고민을 하고 있는 분들에게 참고가 되었으면 합니다.

---

참고

• Codefresh - Stop Using Branches for Deploying to Different GitOps Environments
• Codefresh - Top 30 Argo CD Anti-Patterns to Avoid When Adopting GitOps
• Red Hat Developer - Git Best Practices: Workflows for GitOps Deployments
• ArgoCD - Best Practices
• Kubernetes - Declarative Management of Kubernetes Objects Using Kustomize
• Vincent Driessen - A Successful Git Branching Model
• GitHub Docs - GitHub Flow
• Atlassian - Trunk-Based Development