2026년 국경 간 팀 「대화형 개발」과 「셀프호스티드 macOS Runner」 동일 리전 공유 풀: 다중 리전 물리 Mac에서 큐 배고픔·자원 경합을 어떻게 피할까?——지역 노드 선택과 세션／CI 파티션 임계값 의사결정 매트릭스(복사 가능 파라미터·FAQ)

1. 세 가지 핵심 통증: 배고픔은 흔히 「맥이 부족」이 아니다

1. 오케스트레이션과 Runner 두 층 대기열. GitHub Actions 등에서는 워크플로가 「동시성 슬롯 대기」 또는 「라벨에 맞는 온라인 Runner 대기」에 걸립니다. 셀프호스티드 Runner가 오프라인이거나 라벨이 어긋나거나 runs-on이 틀리면 용량이 있는 것처럼 보이면서도 잡이 안 들어가는 가짜 배고픔이 생깁니다.
2. 대화형과 CI가 같은 캐시를 뺏는다. 원격 IDE 인덱스·시뮬레이터와 xcodebuild가 Derived Data에 동시에 쓰면 NVMe 지연이 치솟아 CI 벽시계와 SSH 반응성을 함께 망칩니다.
3. 다중 시간대 공정성 착시. 리전·팀 범위 concurrency와 무거운 잡의 시간 창이 없으면 한 지역의 푸시 폭풍이 전역 슬롯을 잡아먹고, 다른 리전은 낮에도 줄을 섭니다. 이는 조직 스케줄 문제이지 GHz 문제가 아닙니다.

2. 매트릭스 A: 부하 유형 × 풀 전략

어떤 부하는 물리 머신을 공유할 수 있는지, 어떤 것은 풀·호스트를 나눠야 하는지 먼저 고릅니다.

3. 매트릭스 B: 다중 리전 친화·노드 선택

「Git과 맞춘다」와 「개발자와 맞춘다」는 자주 충돌합니다. 아래를 1차 규칙으로 쓰세요.

실무 규칙: 지리마다 최소 zone:<region> 라벨을 노출하고, 전역 무거운 잡(nightly·전체 스위트)은 pool:heavy와 별도 concurrency 그룹으로 라우팅해 PR 풀을 잡아먹지 않게 합니다.

4. 매트릭스 C: 세션／CI 파티션 임계값(시작값, 부하 테스트로 조정)

5. 복사 가능 파라미터(Runner 라벨 + 워크플로 뼈대)

예시는 GitHub Actions 이름을 따릅니다. 다른 CI도 동일하게 「라벨 + 동시성 그룹 + 셀프호스티드 Runner 설정」에 매핑하면 됩니다.

5.1 Runner 등록 시 권장 라벨(값은 실제 리전·풀명으로 바꿉니다):

zone:apac
pool:ci-standard
os:macos
arch:arm64
capacity:shared

5.2 워크플로: 풀 선택 + 동시성(발췌)

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

jobs:
  build:
    runs-on: [self-hosted, macOS, ARM64, zone-apac, pool-ci-standard]
    timeout-minutes: 60
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

5.3 환경 변수(동작 제어, 비밀 아님)

# CI에서 인덱서 부담 완화 예시
export COMPILER_INDEX_STORE_ENABLE=NO

# Derived Data를 CI 전용 볼륨으로
export DERIVED_DATA_PATH=/Volumes/ci-derived/PR-${{ github.run_id }}

서명 비밀은 공용 풀 기본 env에 두지 말고 스코프된 환경·릴리스 전용 Runner를 쓰세요.

6. 7단계 런북

1. 부하 히트맵: 저장소·브랜치별 일일 잡 수·피크 시간·평균 길이를 집계합니다.
2. 라벨 문법 고정: zone / pool / capacity를 RFC에 적고 사설 별칭을 금지합니다.
3. interactive와 CI 분리: 최소 별도 볼륨·대화형 노드는 CI 라벨을 빼거나 제한합니다.
4. 동시성 그룹·타임아웃: PR과 기본 브랜치를 다른 group으로·긴 잡은 전용 워크플로와 더 긴 timeout-minutes를 둡니다.
5. 4주 관측: 대기 P95·Runner 오프라인율·잡 실패율·엔지니어 RTT를 알림으로 연결합니다.
6. 분기 확장 검토: 한 대 스펙 업보다 같은 리전에 슬롯을 더하는 쪽을 우선합니다.
7. 롤백 문서화: 라벨 되돌리기·워크플로 비상 중지·「릴리스 전용 기계 긴급 점유」 연락망을 적습니다.

7. 인용용 수치·체크리스트(SLO·구매 요청용)

• 시작 동시성: 운영 풀은 호스트당 CI 잡 1개로 시작해 일주일 본 뒤 2를 검토합니다.
• 대기 알림: 동일 리전에서 대기 P95 > 15분이 3회 연속이면 용량 검토를 트리거합니다.
• 대화형 RTT: 주 Remote SSH 경로는 편도 < 120ms를 목표로(팀 허용치에 맞게 조정)·그 이상이면 먼저 가까운 샌드박스를 늘립니다.
• 분기 감사: 살아 있는 머신 ↔ 라벨 목록을 맞춰 폐기 호스트가 워크플로에 남지 않게 합니다.

8. FAQ

「큰 메모리 한 대」로 다중 호스트 파티션을 대신할 수 있나요?

메모리는 일부를 완화하지만 디스크 쓰기 경합과 시뮬레이터 플레이크는 여전히 대화형과 CI를 한 장애 도메인에 묶습니다. 수평으로 Mac을 늘리고 라벨을 엄격히 하는 편이 종종 더 낫습니다.

셀프호스티드 Runner가 들쭉날쭉하면 가짜 배고픔을 어떻게 막나요?

프로세스 감독·자동 재시작·하트비트 모니터링·중요 풀은 N+1 여유를 둡니다. 잡은 대기인데 Runner가 없으면 동시성을 올리기 전에 가용성부터 고칩니다.

머지 큐·트렁크 압력과는 어떻게 맞추나요?

머지 큐는 기본 브랜치 부하를 몰아넣으므로 merge group 전용 풀이나 시간 창을 두고, 기존 Trunk／Merge Queue 동시성 정책과 맞춰 PR 풀을 굶기지 않게 합니다.