2026 소규모 팀 공유 원격 Mac: GitHub merge queue, Runner 라벨 라우팅, 동시성 락·timeout 파라미터
운영자 머릿속에는 두 종류의 대기열이 겹칩니다. 하나는 GitHub merge queue(프리머지·트렁크 정합), 다른 하나는 셀프 호스트 Runner 뒤에 쌓이는 머신형 대기입니다. 이 글은 관심사를 나누고 결정 매트릭스와 파라미터 표(큐 깊이, runner label, concurrency, flock/timeout, 선점)를 한 장으로 묶었습니다. 본문 핵심 서술은 약 800–1500자 분량입니다.
① 두 큐, 한 대 Mac
Merge queue는 “다음에 어떤 PR이 기본 브랜치에 올라갈 자격이 있으며, 최신 트렁크 위에서 다시 통과했는가”를 정합니다. Runner 라벨은 “이 잡을 어떤 원격 Mac이 실행할 수 있는가”만 고릅니다. 라벨만으로 저장소 간 공정성이 생기지는 않습니다. 둘 다 켜 두면 체감 지연은 대개 Xcode·시뮬레이터·디스크 경합 쪽, 즉 Runner 풀에서 옵니다. merge queue 깊이는 얕은데 Actions에서 오래 Queued가 보이면 라벨 슬라이스가 좁거나 필수 검사가 잘못 붙은 경우가 많습니다.
같은 용량 이야기를 사람과 CI가 나눠 쓰므로, 다중 노드 Mac 메시 협업·Codespaces SSH 전달 vs 직접 노드처럼 협업 경로를 문서에 같이 적어 두면 온콜이 한 장을 보며 판단합니다. 라벨 층위의 기준선은 GHA Runner 라우팅·큐 매트릭스 글과 맞추면 됩니다.
② 결정 매트릭스: merge queue vs 라벨 우선
아래는 주된 조절 축을 고르는 표입니다. 주간 릴리스 이상으로 속도가 나면 보통 merge queue(트렁크)와 라벨 라우팅(빌더)을 함께 쓰는 행이 기본 추천입니다.
| 접근 | 잘 맞는 경우 | 주 리스크 | 공유 Mac에서 완화 |
|---|---|---|---|
| merge queue 우선 | 머지 빈도 높음, 기본 브랜치 무결성 엄격, 기여자 다수. | 큐 항목마다 CI 재실행·이중 대기 체감. | 큐 병렬 상한을 보수적으로 두고, 필수 검사를 정렬한 뒤 큐 워크플로를 ci-merge 등 전용 라벨 호스트로 라우팅. |
| 라벨 라우팅 우선 | 머지는 드물고 Xcode/SDK 핀이 여러 갈래. | 논리 충돌로 트렁크가 깨질 수 있음(merge queue가 잡는 유형). | 기본 브랜치엔 merge queue 도입, 라벨은 툴체인 격리 유지. |
| 둘 다(스케일에서 권장) | PR·트렁크 검사를 같은 원격 Mac 풀이 받고 릴리스 슬롯도 필요. | 정책 난립: 서로 다른 timeout·중복 concurrency 키. | concurrency: 네이밍·선점 규칙을 위키에 고정하고 아래 파라미터 표와 동기화. |
| flock만으로 규율 | 서명 등 단일 호스트 뮤텍스가 압도적. | GitHub 쪽 병렬성이 가려지고 락이 걸리면 무관 워크플로까지 정지. | 벽시계 timeout·알림을 짝으로 두고, 노드 분리 전에 임계를 문서화. flock 빌드 큐 FAQ 참고. |
③ 파라미터 표(출발값)
숫자는 기준선입니다. p95 대기·디스크·서명 제약에 맞춰 조정하고, 소유 팀·대시보드 필드를 남기세요. 락 패턴 확장은 큐·락 FAQ와 함께 읽으면 좋습니다.
| 항목 | 출발값 | 메모 |
|---|---|---|
| merge queue 깊이/병렬 | 무거운 Xcode 풀당 동시 1–2, 디스크·CPU 여유 확인 후 최대 3 | 깊은 병렬은 전체 리빌드 배수를 만듭니다. 항목당 비용을 감사 로그와 연계해 보세요. |
| 라벨 세트별 대기 알림 | 대기 잡 약 15–25건 경고, 약 40건 이상 페이지 | 라벨은 공정 큐가 아닙니다. 생성→할당 대기 시간 p95를 레인별로 봅니다. |
| Runner label 예시 | self-hosted, macOS, arm64, xcode-16-2, ci-pr / ci-merge / ci-release |
ci-merge를 선택 검사·실험 잡과 분리해 merge queue가 PR 잡에 가려지지 않게 합니다. |
워크플로 concurrency |
PR: group: ${{ github.workflow }}-${{ github.ref }}, cancel-in-progress: true / 릴리스: false |
동일 자원을 여러 워크플로가 건드리면 조직/저장소 단위 공유 그룹 키를 추가합니다. |
flock 임계 구간 |
키체인당 서명·노터라이즈 1레인, 락 파일은 문서화된 CI 볼륨 또는 /var/tmp |
점유자 ID를 로그에 남기고 아래 timeout과 세트로 씁니다. |
잡 timeout-minutes |
PR 컴파일 30–60, 아카이브/보내기 90–120, merge-group 재검증은 PR과 동급(차이가 작으면 동일) | 최선이 아니라 p95 기준으로 짧게 가져가 stuck Runner를 회수합니다. |
쉘 timeout |
네트워크 호출 120–300s, 업로드 단계 300–600s | 멈춘 curl이 잡 전체 타임아웃까지 점유하는 것을 막습니다. |
| 선점 규칙(우선순위) | PR < 야간 옵션 < merge queue < 릴리스; 서명 락 보유 잡은 선점하지 않음 | 라벨·concurrency로 우선순위를 인코딩하고, 정치화되면 부하 분산·페일오버로 용량을 나눕니다. |
④ 정책 조합
관측 신호부터 맞춥니다. merge queue 대기는 짧은데 Actions 대기가 길면 라벨·노드를 먼저 늘리고, Runner가 놀고 merge queue만 길면 필수 검사 라우팅·merge-group·조직 concurrency 상한을 의심합니다. 풀마다 라벨 다이어그램, 큐 이름, concurrency 키, flock 경로, timeout 표를 한 페이지로 묶으세요. Meshmac 홈의 팀·다중 노드 안내와 연결하면 시차 팀도 같은 용량 스토리를 공유합니다.
⑤ FAQ
- merge queue 잡과 PR 잡에 같은 라벨을 써도 되나요?
- 툴체인 라벨(
xcode-16-2등)은 공유해도 되지만, 용량·소음이 큰 선택 검사와 용량 라벨은 분리하세요.ci-merge·ci-release접미사로 라우팅을 명시하는 편이 안전합니다. - 저장소 두 개가 한 Mac에서 싸울 때 첫 손잡이는?
- 저장소 패밀리·SKU별로 Runner를 쪼갠 뒤
concurrency를 조입니다. 라우팅이 솔직해진 다음에야 merge queue 병렬을 만지는 것이, 리뷰 사이클에 하드웨어 경합만 되돌리지 않습니다.
⑥ 확장·구매
큐 깊이가 트렁크를 해치기 전에 풀을 키우세요. 홈, 블로그, 구매·플랜, 가격은 로그인 없이 열람할 수 있습니다. 라벨이 정직한데도 대기가 높으면 Meshmac 노드를 추가하거나 팀 패키지를 상향해 ci-merge·ci-release 레인에 CPU·디스크를 독립 배분하세요. 실험 워크플로 잔여분에 머지 검증을 맡기지 마세요.
노드·패키지로 merge 레인을 확보하기
공개 플랜을 비교한 뒤, 머지 큐와 릴리스에 전용 빌더를 붙이세요. 도움말에서 SSH/VNC 접속 패턴을 확인할 수 있습니다.