Trunk-based Development 이해하기

개발자 A: feature-payment 브랜치에서 2주간 작업
개발자 B: feature-auth 브랜치에서 3주간 작업
개발자 C: feature-ui 브랜치에서 1주간 작업

→ 3개 브랜치가 각각 다른 시점의 main을 기반으로 함
→ 동시에 merge 시도 시 대규모 충돌 발생
→ 충돌 해결에 수일 소요, 버그 발생 위험 증가

master    ●─────●─────────●─────●
          │     │         │     │
release   │     ●──●──●───●     │
          │     │              │
develop   ●──●──●──●──●──●──●──●──●
          │  │     │  │  │     │
feature/A ●──●─────●  │  │     │
          │           │  │     │
feature/B ●───────────●──●─────●

# 기능 브랜치 생성
git checkout -b feature/user-dashboard
 
# 2-4주간 작업...
git add .
git commit -m "Add user dashboard"
 
# 완료 후 merge (이때 이미 main과 크게 달라짐)
git checkout main
git merge feature/user-dashboard  # 충돌 발생 가능성 높음

trunk     ●──●──●──●──●──●──●──●──●
          │  │  │  │  │  │  │  │
          └──┘  └──┘  └──┘  └─┘
          짧은 피처 브랜치들 (수시간~1일)

하루 동안의 작업 흐름:

09:00 - trunk에서 pull
10:00 - 작은 변경 commit & push
12:00 - 다른 기능 commit & push
15:00 - 버그 수정 commit & push
17:00 - 테스트 추가 commit & push

# ❌ 나쁜 예: 장기 브랜치
git checkout -b feature/complete-payment-system
# 2주간 작업...
# 수백 개의 파일 변경
# merge 시 큰 충돌 발생

# ✅ 좋은 예: 작은 단위로 분할
git checkout -b feature/add-payment-button
# 2-3시간 작업
git commit -m "Add payment button UI"
git push && create PR
 
git checkout -b feature/payment-api-integration
# 4시간 작업
git commit -m "Integrate payment API"
git push && create PR
 
git checkout -b feature/payment-error-handling
# 3시간 작업
git commit -m "Add payment error handling"
git push && create PR

// Feature Flag를 사용한 점진적 개발
function PaymentPage() {
  const { isEnabled } = useFeatureFlag('new-payment-flow');
 
  if (isEnabled) {
    // 🚧 개발 중인 새로운 결제 플로우
    return <NewPaymentFlow />;
  }
 
  // ✅ 기존의 안정적인 결제 플로우
  return <LegacyPaymentFlow />;
}

# 1. 최신 코드 가져오기
git checkout main
git pull origin main
 
# 2. 직접 main에서 작업
# (매우 작은 변경만)
git add src/components/Button.tsx
git commit -m "Fix: Button hover color"
git push origin main
 
# 3. CI가 자동으로 테스트 & 배포

# 1. 최신 trunk 가져오기
git checkout main
git pull origin main
 
# 2. 짧은 피처 브랜치 생성
git checkout -b fix/login-validation
 
# 3. 작은 단위로 작업 (2-4시간)
# src/auth/validation.ts 파일만 수정
git add src/auth/validation.ts
git commit -m "Add email format validation"
 
# 4. PR 생성 및 즉시 리뷰 요청
git push origin fix/login-validation
# GitHub에서 PR 생성
 
# 5. CI 자동 실행
# - 유닛 테스트
# - 통합 테스트
# - 린트 & 포맷 체크
# - 빌드 검증
 
# 6. 리뷰 후 즉시 merge (1-2시간 내)
# Auto-merge 또는 수동 merge
 
# 7. 브랜치 삭제
git branch -d fix/login-validation

[GitFlow - 복잡함]
master    ●─────────────●─────────────●
          │             │             │
release   │    ●────●───●             │
          │    │                      │
develop   ●────●────●────●────●───────●
          │    │    │    │    │
feature/A ●────●────●    │    │
          │              │    │
feature/B ●──────────────●────●


[Trunk-based - 단순함]
main      ●─●─●─●─●─●─●─●─●─●─●─●
          │ │ │ │ │ │ │ │ │ │ │
          └─┘ └─┘ └─┘ └─┘ └─┘ └─┘
          (짧은 브랜치들, 당일 merge)

// 코드는 이미 프로덕션에 배포됨
// 하지만 사용자에게는 보이지 않음
function Dashboard() {
  const flags = useFeatureFlags();
 
  return (
    <div>
      <h1>Dashboard</h1>
 
      {/* 기존 기능 */}
      <UserStats />
 
      {/* 새 기능 - Flag로 제어 */}
      {flags.aiRecommendations && (
        <AIRecommendations />
      )}
    </div>
  );
}

// 설정 파일 또는 Feature Flag 서비스
{
  "aiRecommendations": {
    "enabled": true,
    "rollout": {
      "percentage": 10,  // 10% 사용자에게만 활성화
      "userGroups": ["beta-testers", "internal"]
    }
  }
}

// 문제 발생 시 즉시 Flag를 끔
// 코드 재배포 불필요!
await featureFlagService.disable('aiRecommendations');

// feature-flags.ts
import { useFlags } from 'launchdarkly-react-client-sdk';
 
export function useNewCheckoutFlow() {
  const flags = useFlags();
  return flags.newCheckoutFlow ?? false;
}
 
// CheckoutPage.tsx
function CheckoutPage() {
  const isNewFlowEnabled = useNewCheckoutFlow();
 
  if (isNewFlowEnabled) {
    return <NewCheckoutFlow />;
  }
 
  return <LegacyCheckoutFlow />;
}
 
// 테스트 코드
describe('CheckoutPage', () => {
  it('shows new flow when flag is enabled', () => {
    const { render } = setupWithFlags({ newCheckoutFlow: true });
    expect(screen.getByText('New Checkout')).toBeInTheDocument();
  });
 
  it('shows legacy flow when flag is disabled', () => {
    const { render } = setupWithFlags({ newCheckoutFlow: false });
    expect(screen.getByText('Legacy Checkout')).toBeInTheDocument();
  });
});

// ✅ 좋은 예: 명확한 네이밍과 만료 날짜
const FLAGS = {
  NEW_DASHBOARD: {
    key: 'new-dashboard',
    description: '새로운 대시보드 UI',
    createdAt: '2025-01-01',
    removeAfter: '2025-03-01',  // 2개월 후 제거 예정
    owner: 'frontend-team'
  }
};
 
// ❌ 나쁜 예: 모호한 이름, 관리 정보 없음
const FLAGS = {
  FLAG_1: 'f1',
  NEW_FEATURE: 'nf'
};

# Flag 정리 예시
# 1. 100% 롤아웃 완료 → Flag 제거
- if (flags.newDashboard) {
-   return <NewDashboard />;
- }
- return <OldDashboard />;
+ return <NewDashboard />;
 
# 2. 더 이상 사용하지 않는 Flag → 코드 및 설정 제거

# .github/workflows/ci.yml
name: Continuous Integration
 
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
 
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
 
      # 1. 의존성 설치
      - name: Install dependencies
        run: npm ci
 
      # 2. 린트 & 타입 체크 (빠른 피드백)
      - name: Lint
        run: npm run lint
 
      - name: Type check
        run: npm run type-check
 
      # 3. 유닛 테스트 (빠름, 5-10분)
      - name: Unit tests
        run: npm run test:unit
 
      # 4. 통합 테스트 (중간, 10-20분)
      - name: Integration tests
        run: npm run test:integration
 
      # 5. E2E 테스트 (느림, 20-40분)
      - name: E2E tests
        run: npm run test:e2e
 
      # 6. 빌드 검증
      - name: Build
        run: npm run build
 
      # 7. 모든 테스트 통과 시 자동 배포
      - name: Deploy to staging
        if: github.ref == 'refs/heads/main'
        run: npm run deploy:staging

[피라미드 구조]

           /\      E2E Tests (10%)
          /  \     - 주요 사용자 시나리오
         /    \    - 느리지만 실제 환경 검증
        /------\
       /        \  Integration Tests (30%)
      /          \ - API 통합
     /            \- 데이터베이스 연동
    /--------------\
   /                \ Unit Tests (60%)
  /                  \- 빠른 피드백
 /--------------------\- 높은 커버리지

// ✅ 좋은 예: 빠른 유닛 테스트
describe('calculateDiscount', () => {
  it('applies 10% discount for orders over $100', () => {
    const result = calculateDiscount({ total: 150 });
    expect(result).toBe(135);
  });
 
  it('applies no discount for orders under $100', () => {
    const result = calculateDiscount({ total: 50 });
    expect(result).toBe(50);
  });
});
 
// 통합 테스트
describe('PaymentAPI', () => {
  it('processes payment successfully', async () => {
    const payment = await paymentAPI.process({
      amount: 100,
      currency: 'USD'
    });
 
    expect(payment.status).toBe('completed');
  });
});
 
// E2E 테스트
describe('Checkout Flow', () => {
  it('completes full checkout process', async () => {
    await page.goto('/products/1');
    await page.click('button:has-text("Add to Cart")');
    await page.click('a:has-text("Checkout")');
    await page.fill('[name="email"]', 'test@example.com');
    await page.click('button:has-text("Pay")');
 
    await expect(page.locator('.success-message')).toBeVisible();
  });
});

[대형 배치 - 위험함]
┌────────────────────────────────────┐
│  2주간 작업한 대형 PR               │
│  - 50개 파일 변경                   │
│  - 2,000줄 추가/수정                │
│  - 리뷰 시간: 4-6시간               │
│  - 버그 위험: 높음                  │
│  - 롤백 시 큰 영향                  │
└────────────────────────────────────┘

[소형 배치 - 안전함]
┌──────────┐ ┌──────────┐ ┌──────────┐
│ PR #1    │ │ PR #2    │ │ PR #3    │
│ 3개 파일 │ │ 2개 파일 │ │ 4개 파일 │
│ 80줄     │ │ 50줄     │ │ 120줄    │
│ 리뷰: 15분│ │ 리뷰: 10분│ │ 리뷰: 20분│
└──────────┘ └──────────┘ └──────────┘

[❌ 잘못된 방식]
feature/complete-user-management
- 사용자 CRUD API
- 사용자 목록 UI
- 사용자 상세 페이지
- 권한 관리 시스템
- 감사 로그
총 작업 시간: 2주


[✅ 올바른 방식]
1. feature/user-api-create (4시간)
   - POST /api/users API 추가
   - 단위 테스트 작성

2. feature/user-list-ui (3시간)
   - 사용자 목록 컴포넌트
   - Feature Flag로 숨김

3. feature/user-detail-page (4시간)
   - 사용자 상세 페이지
   - 기존 목록과 연결

4. feature/user-permissions (6시간)
   - 권한 체크 로직
   - 미들웨어 추가

5. feature/audit-logging (3시간)
   - 감사 로그 기록
   - 로그 조회 API

하나의 거대한 trunk
├── google3/
│   ├── ads/
│   ├── search/
│   ├── maps/
│   ├── youtube/
│   └── cloud/
└── 모든 프로젝트가 동일한 trunk에서 작업

// Feature Flag 시스템: Gatekeeper
function NewsFeed() {
  const showNewAlgorithm = useGatekeeper('news_feed_v2');
 
  if (showNewAlgorithm) {
    return <NewsFeedV2 />;
  }
 
  return <NewsFeedV1 />;
}
 
// 점진적 롤아웃
// 1% → 10% → 50% → 100%

# Spinnaker 배포 파이프라인
stages:
  - name: Canary Deploy (5%)
    duration: 1h
    metrics:
      - errorRate < 0.1%
      - latency < 100ms
 
  - name: Gradual Rollout (50%)
    duration: 2h
 
  - name: Full Deploy (100%)
    condition: all_metrics_pass

// A/B 테스트
public Recommendation getRecommendation(User user) {
    if (featureFlag.isEnabled("new_recommendation_algo", user)) {
        return newAlgorithm.recommend(user);
    }
    return legacyAlgorithm.recommend(user);
}

# 매우 단순한 워크플로우
git pull origin main
# 기능 개발 (2-3시간)
git add .
git commit -m "Add user profile page"
git push origin main
# CI가 자동으로 테스트 & 배포

Release Cycle: 분기별 (3개월)
Branches: 50+ 장기 피처 브랜치
Integration: 릴리스 1개월 전 시작
Bugs: 통합 단계에서 대량 발견

Release Cycle: 주간 (1주)
Branches: 10-15개 단기 브랜치 (동시)
Integration: 매일
Bugs: 즉시 발견 및 수정

[장기 브랜치]
Main:    A─────────────B
         │             │
Feature: A──●──●──●──●──C (큰 충돌 가능성)

[Trunk-based]
Main:    A─●─●─●─●─●─●─B
         │ │ │ │ │ │ │
         └─┘ └─┘ └─┘ └─┘ (작은 충돌만 발생)

[전통적 방식]
코드 작성 → 2주 대기 → 리뷰 → 1주 수정 → 통합 → 버그 발견
총 소요: 4주

[Trunk-based]
코드 작성 → 30분 대기 → 리뷰 → 1시간 수정 → 통합 → 즉시 피드백
총 소요: 2-3시간

// 매일 통합하므로 자연스럽게 작은 단위로 개발
// ❌ 나쁜 예
function implementPaymentSystem() {
  // 2주간 작업...
  // 1,000줄의 코드
}
 
// ✅ 좋은 예
function addPaymentButton() {
  // 2시간 작업, 50줄
}
function connectPaymentAPI() {
  // 3시간 작업, 80줄
}
function handlePaymentErrors() {
  // 2시간 작업, 60줄
}

[전통적 방식]
개발자 A: feature/payment에서 작업 (2주)
개발자 B: feature/auth에서 작업 (3주)
→ 서로의 작업을 모름
→ 통합 시점에 충돌 발견

[Trunk-based]
개발자 A: 매일 main에 commit
개발자 B: 매일 main을 pull하여 A의 변경사항 확인
→ 지속적 의사소통
→ 충돌을 미리 발견하고 조율

# 최소 요구사항
CI/CD:
  - 자동 테스트: 유닛, 통합, E2E
  - 자동 배포: Staging, Production
  - 자동 롤백: 문제 감지 시
 
Monitoring:
  - 에러 추적
  - 성능 모니터링
  - 사용자 행동 분석
 
Feature Flags:
  - Flag 관리 시스템
  - 점진적 롤아웃
  - 긴급 차단 기능

[실패 사례]
❌ 개발자가 큰 변경을 한꺼번에 commit
❌ 리뷰가 지연되어 브랜치가 장기화
❌ 테스트 없이 commit하여 빌드 실패
❌ Feature Flag를 제거하지 않아 기술 부채 누적

// ❌ Flag 지옥 (Feature Flag Hell)
function Component() {
  const flags = useFeatureFlags();
 
  if (flags.newUI && flags.experimentalFeature) {
    if (flags.betaMode || flags.premiumUser) {
      return <VersionA />;
    }
    return <VersionB />;
  } else if (flags.newUI) {
    return <VersionC />;
  }
  return <VersionD />;
}
 
// 테스트 조합이 기하급수적으로 증가
// 2^n개의 경우의 수

Linux Kernel:
v6.1 LTS (2024년까지 지원)
v6.6 LTS (2026년까지 지원)
v6.7 (현재 개발)

→ 각 버전별로 독립적인 브랜치 필요
→ Trunk-based는 부적합

의료 소프트웨어, 금융 시스템:
- 모든 변경에 대한 승인 필요
- 변경 이력의 명확한 분리
- 감사 추적 (Audit Trail)

→ GitFlow가 더 적합할 수 있음

주니어 개발자 위주의 팀:
- 작은 단위로 나누기 어려움
- 테스트 작성 경험 부족
- CI/CD 이해도 낮음

→ 단계적 전환 필요 (GitFlow → GitHub Flow → TBD)

Trunk-based를 선택하세요:
✅ CI/CD를 구축할 의지와 자원이 있음
✅ 팀이 작은 단위로 작업할 수 있음
✅ 빠른 배포가 중요함
✅ 단일 프로덕션 버전 유지

GitFlow를 선택하세요:
✅ 여러 버전을 동시에 유지해야 함
✅ 릴리스 일정이 미리 정해짐 (분기별 등)
✅ 엄격한 승인 프로세스가 필요함
✅ 팀의 기술적 성숙도가 낮음

# 1. main에서 브랜치 생성
git checkout -b feature/add-user-search
 
# 2. 작업 및 commit (며칠~1주)
git commit -m "Add search functionality"
 
# 3. PR 생성 및 리뷰
 
# 4. main에 merge 후 즉시 배포
git checkout main
git merge feature/add-user-search
# 자동 배포
 
# 5. 브랜치 삭제
git branch -d feature/add-user-search

GitHub Flow:
- 피처 브랜치: 며칠~1주
- PR 리뷰 필수
- merge 후 배포

Trunk-based (소규모):
- 피처 브랜치: 수시간~1일
- PR 옵션 (직접 commit도 가능)
- 매일 여러 번 배포

main ──────●──────●──────●
           │      │      │
staging    ●──────●──────●
           │      │
production ●──────●

# 1. feature 개발
git checkout -b feature/new-api
git commit -m "Add new API endpoint"
 
# 2. main으로 merge
git checkout main
git merge feature/new-api
 
# 3. staging 배포
git checkout staging
git merge main
# 배포 to staging
 
# 4. 검증 후 production 배포
git checkout production
git merge staging
# 배포 to production

master      ●─────────●─────────●
            │         │         │
release     │    ●────●─────────●
            │    │
develop     ●────●────●────●────●
            │    │    │    │
feature/A   ●────●────●    │
            │              │
feature/B   ●──────────────●

[Phase 1: GitFlow → GitHub Flow]
- develop 브랜치 제거
- main만 사용
- 피처 브랜치 수명 단축 (2주 → 1주)

[Phase 2: GitHub Flow → Trunk-based]
- 피처 브랜치 더 짧게 (1주 → 1-2일)
- Feature Flag 도입
- CI/CD 자동화 강화

[Phase 3: Pure Trunk-based]
- 작은 팀은 직접 main에 commit
- Feature Flag로 모든 미완성 기능 제어

// Step 1: 추상화 계층 추가
interface PaymentGateway {
  processPayment(amount: number): Promise<Result>;
}
 
// Step 2: 구현체 전환 (Feature Flag로 제어)
const gateway: PaymentGateway = flags.newGateway
  ? new StripeGateway()
  : new LegacyGateway();
 
// Step 3: 점진적으로 새 구현으로 전환
// Step 4: 레거시 제거

# CD 파이프라인 예시
on:
  push:
    branches: [main]
 
jobs:
  deploy:
    steps:
      - run: npm test
      - run: npm run build
      - run: deploy to production
      - run: smoke tests
      - if: failure()
        run: automatic rollback