브랜치 전략과 배포

마이크로 프론트엔드 모노레포에서 마이크로 앱별 브랜치 관리와 변경 감지 기반 배포 전략을 정리한다.

학습 목표

1. 모노레포 워크스페이스 구조에서 각 영역의 변경 속도 차이를 이해한다.
2. 마이크로 앱별 브랜치 전략과 통합 브랜치 전략의 차이를 비교할 수 있다.
3. 변경 감지 기반 배포의 원리와 한계를 설명할 수 있다.
4. trunk-based development가 마이크로 프론트엔드에 적합한 이유를 제시할 수 있다.

---

1. 모노레포 워크스페이스의 변경 속도

마이크로 프론트엔드 모노레포에는 변경 속도가 서로 다른 영역이 공존한다. 이 차이를 무시하면 배포 전략이 실패한다.

영역	변경 속도	영향 범위	배포 주의도
인프라 패키지	느림 (보수적)	전체 코드베이스	매우 높음
프래그먼트	중간	여러 마이크로 앱	높음
마이크로 앱	빠름 (활발)	해당 앱 영역만	상대적으로 낮음

인프라 레벨 패키지는 모든 마이크로 앱에 영향을 미치므로 신중하게 변경해야 한다. 반면 마이크로 앱은 자신의 영역 안에서 활발하게 개발과 실험을 진행한다.

---

2. 마이크로 앱별 브랜치 vs 통합 브랜치

방식 1: 마이크로 앱별 브랜치 전략

각 마이크로 앱 팀이 자신의 작업 주기가 시작되면 별도의 마이크로 앱 브랜치를 생성하고, 그 브랜치를 기준으로 피처 브랜치를 만들어 개발한다.

main
├── app/auth-sprint-42
│   ├── feature/auth-social-login
│   └── feature/auth-mfa
├── app/dashboard-sprint-42
│   ├── feature/dashboard-chart-redesign
│   └── feature/dashboard-export
└── app/payment-sprint-42
    └── feature/payment-subscription

장점: 각 팀이 독립적으로 병합과 배포 시점을 결정할 수 있다.

단점: 마이크로 앱 브랜치를 main으로 병합할 때 인프라 변경과의 충돌을 관리해야 한다.

방식 2: 통합 브랜치 전략

모든 팀이 하나의 develop 브랜치에서 피처 브랜치를 만들고 병합한다.

main
└── develop
    ├── feature/auth-social-login
    ├── feature/dashboard-chart-redesign
    └── feature/payment-subscription

장점: 브랜치 관리가 단순하고 충돌을 빨리 발견한다.

단점: 한 팀의 불안정한 코드가 다른 팀에 영향을 줄 수 있다.

방식 3: Trunk-Based Development (권장)

main (항상 배포 가능한 상태)
├── feature/auth-social-login      (수명: 1-2일)
├── feature/dashboard-chart        (수명: 1-2일)
└── feature/payment-sub            (수명: 1-2일)

핵심 원칙:

• main 브랜치는 항상 배포 가능한 상태를 유지한다.
• 피처 브랜치의 수명을 최대 1-2일로 제한한다.
• 기능 플래그(Feature Flag)를 활용하여 미완성 기능을 숨긴다.
• 작은 단위로 자주 병합하여 충돌을 최소화한다.

마이크로 프론트엔드에서 trunk-based development가 권장되는 이유는 각 마이크로 앱이 독립적으로 배포 가능해야 한다는 목표와 가장 잘 맞기 때문이다.

---

3. 인프라 변경 시 배포 협의

인프라 레벨 패키지가 변경되면 모든 마이크로 앱에 영향을 미칠 수 있다. 이때의 프로세스가 일반 마이크로 앱 배포와 다르다.

인프라 변경 배포 규칙

1. 코드 리뷰 필수: 인프라 패키지 변경 PR은 모든 마이크로 앱 오너의 리뷰를 받아야 한다.
2. 영향도 분석: 변경이 각 마이크로 앱에 미치는 영향을 명확히 파악한다.
3. 스코프 배포: 영향이 없으면 해당 패키지만 배포한다.
4. 순차 배포: 영향이 있으면 배포 순서를 정하여 서로 겹치지 않게 배포한다.
5. 롤백 계획: 문제 발생 시 즉시 이전 버전으로 되돌릴 수 있는 계획을 준비한다.

---

4. 변경 감지 기반 배포

원리

대규모 모노레포에서 모든 패키지를 매번 빌드하고 배포하는 것은 비효율적이다. 변경 감지 기반 배포는 실제로 변경된 패키지와 그에 의존하는 패키지만 빌드하고 배포한다.

도구 비교

도구	변경 감지	캐시	병렬 빌드	특징
Turborepo	파일 해시 기반	원격 캐시 지원	지원	설정이 간단하고 빌드 캐시가 강력
Nx	의존 그래프 기반	원격 캐시 지원	지원	영향 분석이 정교하고 플러그인 풍부
Lerna	패키지 단위	제한적	제한적	npm 워크스페이스와 잘 통합
changesets	수동 변경 기록	미지원	미지원	버전 관리와 체인지로그에 특화

변경 감지 배포의 한계

1. 복잡한 의존 관계: 인프라 패키지 변경 시 변경 감지가 모든 앱을 재빌드 대상으로 판단하여 효율이 떨어질 수 있다.
2. 너무 잦은 배포: 작은 변경마다 자동 배포가 트리거되면 오히려 불안정해질 수 있다.
3. 패키지 간 암묵적 의존: 코드 레벨이 아닌 런타임 통합(Module Federation)의 의존성은 도구가 감지하지 못할 수 있다.
4. 사람의 판단 필요: 변경만으로 배포 여부를 결정할 수 없는 경우가 있다. 마이크로 앱 오너들 간의 상의가 여전히 필요하다.

---

5. 실무 배포 워크플로우 예시

# .github/workflows/deploy.yml (간소화 예시)
name: 변경 감지 기반 배포

on:
  push:
    branches: [main]

jobs:
  detect-changes:
    runs-on: ubuntu-latest
    outputs:
      auth: ${{ steps.filter.outputs.auth }}
      dashboard: ${{ steps.filter.outputs.dashboard }}
      payment: ${{ steps.filter.outputs.payment }}
      infra: ${{ steps.filter.outputs.infra }}
    steps:
      - uses: actions/checkout@v4
      - uses: dorny/paths-filter@v3
        id: filter
        with:
          filters: |
            auth:
              - 'apps/auth/**'
            dashboard:
              - 'apps/dashboard/**'
            payment:
              - 'apps/payment/**'
            infra:
              - 'packages/**'

  deploy-auth:
    needs: detect-changes
    if: needs.detect-changes.outputs.auth == 'true'
        || needs.detect-changes.outputs.infra == 'true'
    runs-on: ubuntu-latest
    steps:
      - run: echo "인증 앱 빌드 및 배포"

  deploy-dashboard:
    needs: detect-changes
    if: needs.detect-changes.outputs.dashboard == 'true'
        || needs.detect-changes.outputs.infra == 'true'
    runs-on: ubuntu-latest
    steps:
      - run: echo "대시보드 앱 빌드 및 배포"

---

6. 배포 전략 비교 정리

전략	적합한 상황	장점	단점
마이크로 앱별 브랜치	팀별 배포 주기가 크게 다른 경우	팀 독립성 극대화	브랜치 관리 복잡
통합 브랜치	소규모 조직, 배포 주기 동일	단순한 관리	팀 간 간섭 위험
Trunk-based	마이크로 프론트엔드 권장	작은 단위 배포, 충돌 최소	기능 플래그 인프라 필요
변경 감지 자동 배포	대규모 모노레포	불필요한 빌드 제거	암묵적 의존성 감지 한계

---

핵심 정리

• 마이크로 프론트엔드 모노레포에서는 인프라 패키지(느린 변경)와 마이크로 앱(빠른 변경)의 속도 차이를 인식하고 배포 전략을 분리해야 한다.
• Trunk-based development가 마이크로 프론트엔드와 가장 잘 맞는다. 작은 단위로 자주 병합하고 기능 플래그로 미완성 기능을 관리한다.
• 인프라 패키지 변경 시에는 모든 마이크로 앱 오너의 코드 리뷰와 배포 순서 협의가 필수적이다.
• 변경 감지 기반 배포는 효율적이지만, 사람의 판단이 필요한 경우를 대체할 수는 없다.
• 마이크로 프론트엔드의 궁극적 목표는 단일 장애 지점 회피이므로, 배포 전략도 이 목표에 부합해야 한다.

---

다음 단계

배포 전략이 정해졌다면, 개발자가 일상적으로 작업하는 로컬 개발 환경의 구성이 필요하다. 다음 장에서는 전체 실행, 개별 실행, 하이브리드 세 가지 로컬 개발 환경 접근법을 비교한다.

다음 문서: 04-로컬-개발-환경.md