2026년 국경 간 팀 Trunk·Merge Queue와 다중 리전 물리 Mac: 오케스트레이션 꼬리·락 폭풍을 어떻게 납작하게 할까—대기열 깊이, 라벨 라우팅·아티팩트 친화 임계값 의사결정 매트릭스(복사 가능 GitHub Actions merge-group + FAQ)

의사결정 매트릭스 3종: 대기열 깊이, 라벨 라우팅, 아티팩트 친화

매트릭스 A: Merge Queue·동시성 그룹을 언제 조일까

매트릭스 B: 라벨 라우팅(다중 리전 물리 Mac)

매트릭스 C: 아티팩트 친화(임계값)

셋을 함께 씁니다: 대기열 깊이는 누가 먼저 도는지, 라벨은 어디서 도는지, 친화는 무엇이 그 전에 움직이는지—한 모서리라도 빼면 「머지는 초록인데 배포는 느리다」가 남습니다.

7단계 런북

1. 기준선 고정: PR 체크, merge_group, 기본 브랜치 푸시의 소요를 분리 측정하고, 리전별 Runner 대기 깊이·재시도율을 추적합니다.
2. merge_group SLA: 「머지까지 대기」 비즈니스 상한 안에 들어오게 하고, 아티팩트 다운로드 비중을 별도로 드러냅니다.
3. 동시성 조이기: 공유 가변 리소스는 concurrency 또는 「Runner당 무거운 job 1개」로 위음성을 먼저 제거합니다.
4. 리전 라벨 추가: 기본 브랜치 검증을 산출물·미러 리전에 맞추고, 국경은 읽기 전용 가속 위주로 둡니다.
5. 아티팩트 경로 보정: 대형 중간 산출물은 동일 리전 생성–참조–다이제스트 검증, merge_group 안에서 전량 재업로드를 반복하지 않습니다.
6. 게임데이: 한 리전을 비우거나 스로틀을 넣었을 때 큐 폴백이 서명 관할을 깨지 않는지 확인하고, 권위 리전을 못 쓸 때 RTO를 문서화합니다.
7. 임계값 기록: 대기열 깊이·RTT·아티팩트 크기를 ADR에 남겨 스케일링 때 비공식 규칙이 사라지지 않게 합니다.

인용 가능한 임계값(ADR 친화)

• Merge Queue 대기 P95 > ~2× 단일 merge_group 검증 시간 → 하드웨어 전에 동시성·job 분할을 조정합니다.
• 국경 아티팩트 pull RTT P95 > ~80–120ms이고 단일 다운로드 > ~5GB → 기본은 동일 리전 빌드+검증 정렬입니다.
• 셀프호스티드 물리 Mac에서는 동시성 그룹 안에서 무거운 UI job 1개/Runner로 시뮬레이터 경합을 피합니다.
• 단기 큐 재편 실패율 > ~5% → 재시도 상향 전에 브랜치 보호·드리프트를 봅니다.

복사 가능 GitHub Actions merge_group 스니펫

최소한의 merge_group 트리거와 pull_request, 그리고 셀프호스티드 Runner에서 락 폭풍을 줄이기 위한 동시성 키입니다. runs-on 라벨과 리전 이름은 플릿에 맞게 바꿉니다.

name: ci

on:
  pull_request:
  merge_group:

concurrency:
  group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.run_id }}
  cancel-in-progress: true

jobs:
  validate:
    if: github.event_name == 'merge_group' || github.event_name == 'pull_request'
    runs-on: [self-hosted, macOS, region-apac]
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.merge_group.head_sha || github.event.pull_request.head.sha }}
      - name: Build and test (merge queue aware)
        run: |
          echo "Running on ${{ github.event_name }} @ ${{ github.sha }}"
          # xcodebuild / swift test / merge 검증 명령

참고: merge_group는 큐의 임시 머지 커밋과 같은 ref를 체크아웃해야 합니다. 동시성 키는 PR 실행과 큐 실행이 서로 잘못 취소하지 않게 조정하거나 워크플로를 나눕니다. GitHub의 merge_group 의미는 변할 수 있으니 프로덕션 전에 샌드박스 저장소에서 끝까지 검증하세요.

FAQ

merge_group와 pull_request가 한 job 정의를 공유해도 되나요?

스텝은 공유 가능하지만 if·ref 처리를 명시하세요. 큐 재편에서 잘못된 SHA는 「무작위 빨강」을 만듭니다.

물리 Mac 풀과 GitHub 호스티드 Runner를 섞어도 되나요?

가능하지만 라벨은 상호 배타적으로 문서화하고, 아티팩트·캐시 경로 계약을 통일하세요. 파일시스템 레이아웃이 다른 러너 클래스에 동시성 그룹이 걸치면 안 됩니다.

락 폭풍: 큐를 비우는 게 먼저인가요, job을 죽이는 게 먼저인가요?

병렬도를 줄이고 락 입자를 쪼개는 것이 먼저입니다. 큐 전체 드레인은 순서 있는 머지 의도를 버리므로 통상 제어 평면 사고에만 씁니다.

Mac mini에서 대기열을 안정적으로

Trunk와 Merge Queue는 머지 정합성을 CI로 밀어 넣고, 물리 Mac Runner는 실제 Xcode·시뮬레이터 부하를 집니다. 둘이 만나면 안정성과 IO 일관성이 피크 클럭보다 중요합니다. Apple Silicon Mac mini는 통합 메모리 대역과 대략 유휴 ~4W 수준의 전력으로 리전 Runner를 밤새 웜 상태로 두기에 적합해, 많은 x86 타워에서 오는 열·쿨링 스윙으로 락 TTL을 계속 다시 맞추는 일을 줄여 줍니다.

macOS는 노트북과 같은 뿌리를 공유해 「로컬에선 되는데 CI만 튄다」 간극을 줄이고, Gatekeeper·SIP·FileVault는 감사하에 세션·디스크 상태를 설명하기 쉽게 합니다. 산출물·미러와 Runner를 친화시키고 라벨과 동시성으로 락 경계를 강제한 뒤, 조용하고 예측 가능한 하드웨어에서 merge_group를 돌리고 싶다면 Mac mini M4는 여전히 강한 가격 대 성능 출발점입니다.

「merge_group가 가끔 돈다」에서 「대기열 깊이와 친화 임계값을 신뢰한다」로 옮기려면, 지금 Mac mini로 이 매트릭스를 실제 실리콘에서 검증해 보세요.