정리만으로 충분한가요?

Webhook으로 투입 중지를 보완해야 합니다.

클러스터 오병합?

헤더 3종과 병기하고 원시 로그로 RCA합니다.

2026 Mac 클라우드 iOS CI 관측 가능성: 대기열 깊이, 실패 클러스터, 디스크 Webhook 임계값

Xcode 26 파이프라인을 SSH Mac 클라우드에 올린 뒤에도 꼬리 로그만으로는 오후 지연과 재실행 그린을 설명하기 어렵습니다. 이 글은 대기·실행·실패 서명·디스크/동시성 스냅샷이라는 네 신호, 로그·메트릭·Webhook 판단표, 7단계 구현, SLO 협상용 임계값, 그리고 DerivedData·대기열 운영 글과의 역할 분담 FAQ를 담습니다.

1. 꼬리 로그만으로 부족한 이유

Linux Runner 문화는 마지막 200줄에 의존하기 쉽지만, Apple 실리콘 Mac 클라우드에서는 통합 메모리·링커 임시 파일·비대한 DerivedData가 겹쳐 스택이 서명이나 CDN 문제로 위장합니다. 설계 전에 아래 세 가지 실패 모드를 Runbook에 적어 두세요.

대기열 깊이가 벽시계에 묻힌다: GitLab Runner나 Jenkins가 Mac 라벨에서 막히면 xcodebuild 시간만으로는 대기 비용을 과소평가하고 비즈니스가 느끼는 오후 지연을 설명하지 못합니다.
실패 클러스터 필드가 없으면 비영 종료가 균질해 보인다: 코드서명, 프로비저닝, 디스크 풀, SwiftPM, 락 경합은 비슷한 종료 코드를 낼 수 있습니다. failure_cluster와 노드 ID, 스킴 이름을 맞추지 않으면 브리지가 수작업으로 남습니다.
디스크·동시성 연동 경보 없이 Webhook은 역효과: DerivedData 분리와 12% 미만 fail-fast를 하지 않으면 자동 재시도·병렬 증폭이 IO 폭풍을 키우고 분당 과금 러너 예산을 태웁니다.

2026년 최소 관측 집합은 대기·실행·실패 서명·디스크/동시성 스냅샷 네 덩어리입니다. 다음 표는 로그만으로 충분한 규모와 Prometheus류·Webhook이 필요한 규모를 가릅니다.

2. 로그·메트릭·Webhook 표

숫자는 출발점입니다. p95 대기, 가장 빠른 테스트 잡의 중앙값, Xcode 마이너 업그레이드 후 디스크 감쇠를 분기마다 재계산하세요.

단계	Mac 대수	베이스라인	Webhook 용도	빠지면 생기는 일
소규모	1~2	구조화 로그, 헤더 3종, df 샘플	여유 12% 미만이면 신규 archive 중단	디스크를 네트워크로 오인
성장	3~8	대기 깊이·대기 시간·성공률을 노드별	동일 클러스터 3회/10분이면 재시도 억제	알람 피로와 과금 폭증
플랫폼	8+	스케줄러에서 아티팩트 저장소까지 추적 ID	Webhook은 병렬 축소·점검 창만	자동화가 설정 드리프트를 가림

라벨 표준화는 API 연결 가이드와 함께 SKU·마운트·풀 이름을 모든 빌드 이벤트에 실습니다.

3. 7단계: 헤더 3종부터 침묵 창까지

Jenkins 공유 라이브러리나 GitLab 템플릿에 순서대로 넣습니다. 실패마다 어떤 머신에서 얼마나 기다렸는지, 디스크 몇 퍼센트였는지, 어떤 클러스터인지 반환해야 합니다.

sw_vers, xcodebuild -version, xcode-select -p를 고정 헤더로: 주간 비교와 Xcode 드리프트 탐지에 필요합니다.
queue_wait_ms 기록: 셸 시작과 큐 진입 시각 차이로 근사합니다.
failure_cluster를 안정 키워드로: Code Sign, No space left 등, 전문 해시는 피합니다.
빌드 전후 df -g /와 DerivedData 루트 du -sh: 대기열 글의 12% 정책과 맞춥니다.
Webhook JSON 최소 집합: node_id, job_url, failure_cluster, disk_avail_pct, queue_depth, queue_wait_ms.
침묵·백오프: 동일 클러스터는 10분에 한 번만 병렬 축소, 디스크 10% 미만 연속 두 번만 자동 중지.
자동 조치 감사 로그: 주체·이유·롤백 URL을 남겨 수동 핫픽스와 충돌하지 않게 합니다.

{
  "event": "ios_build_failed",
  "node_id": "mac-m4-03",
  "queue_depth": 7,
  "queue_wait_ms": 420000,
  "failure_cluster": "codesign_identity_mismatch",
  "disk_avail_pct": 11,
  "derived_data_gb": 186,
  "job_url": "https://ci.example/job/8842"
}

                주의: DERIVED_DATA_PATH 잡 분리가 끝나기 전에는 파괴적 Webhook을 켜지 마세요. 병렬 archive가 참조 중인 디렉터리를 지우면 드문 락 오류가 늘어납니다.
            

4. 리뷰에 붙일 임계값

재무·프로덕트와 SLO를 잡는 앵커입니다.①병렬 슬롯의 4배를 30분 넘게 유지하는 대기열 깊이는 용량 사고로 보고 탄력 Mac 클라우드 확장이나 머지 제한을 고릅니다.②여유 약 12% 미만이면 신규 archive를 막고 가벼운 테스트만 허용해 APFS 한 자릿대 긴 꼬리 IO를 피합니다.③동일 failure_cluster가 1시간에 다섯 번 이상이면 최근 세 번 헤더 차이를 첨부해 xcode-select 드리프트를 의심합니다.④queue_wait_ms p95가 가장 빠른 테스트 중앙값의 세 배를 넘기면 라벨 고갈이나 archive 독점을 먼저 봅니다.⑤Webhook 병렬 축소는 한 슬롯씩, 20분 디스크 회복 곡선을 본 뒤 다음 결정을 내립니다. 추가로 derived_data_gb 히스토그램을 잡 유형별로 익명화하고, Webhook을 멱등으로 만들 dedup 키(node_id+분 버킷)를 문서화합니다. 사람 확인 없이 전 병렬을 되돌리는 정책은 프로비저닝 버그를 숨기므로 금지 목록에 넣습니다.

5. FAQ

DerivedData 자동 정리만으로 Webhook이 필요할까요?

필요합니다. 정리는 공간을 만들고, Webhook은 악화 중 신규 잡 투입을 멈춥니다.

클러스터가 잘못 합쳐질 수 있나요?

예. 헤더 3종과 함께 두고, 사람 RCA는 원시 로그로 돌아갑니다.

멀티 Xcode 글과 차이는?

멀티 Xcode는 DEVELOPER_DIR 선택, 이 글은 대기열·디스크 임계값입니다. 업그레이드 창에는 둘 다 봅니다.

6. 설명 가능한 Mac CI로

노트북이나 작은 Mac에 무리하게 큐를 얹으면 관측 필드 없이 인맥에 의존하고, 디스크·동시성 문제가 Apple 탓으로 보이며, 분당 과금과 무침묵 재시도로 예산을 태웁니다. 비싼 APM만으로는 당시 몇 GB가 남았는지 답하지 못합니다.디스크와 메모리가 읽기 쉽고 SSH·API로 늘리는 Mac 클라우드에 관측을 얹으면 Linux 빌드 팜과 같은 사전으로 iOS를 운영할 수 있습니다. 설명 책임과 Webhook 일시 중지를 함께 가져가려면 VPSMAC 전용 Mac 클라우드가 현실적입니다. 기준이 분명하면 대기 중지가 개발자 노트북이 아니라 프로덕션 러너에만 걸립니다.