기업 Mac CI 모니터링 지표 설정은? 2026 검수 체크리스트

Mac 호스트가 켜져 있는 상태, Runner가 GitHub에 연결된 상태, 작업이 성공한 상태, 앱 배포가 완료된 상태는 서로 다른 신호입니다. 이를 하나의 “정상” 표시로 합치면 호스트는 살아 있지만 작업은 대기 중인 상황이나, 빌드는 끝났지만 결과 증거가 누락된 상황을 놓칠 수 있습니다.

검수 기준은 실제 iOS 파이프라인으로 잡으세요. 코드 변경에서 시작해 빌드와 테스트를 거쳐 결과물을 만드는 흐름을 하나 골라, 각 신호가 동일한 노드와 작업 기록을 가리키는지 확인합니다. 배포까지 검수 범위에 포함한다면 배포 승인과 결과 확인은 빌드 성공과 별도 상태로 기록해야 합니다.

GitHub의 Runner 정보에는 온라인 여부와 작업 중 여부가 구분되어 있습니다. 따라서 온라인 상태는 연결 확인에 쓰고, 작업이 실제로 배정되고 실행됐는지는 워크플로와 작업 기록에서 별도로 확인하세요. GitHub Runner 모니터링 및 문제 해결 안내와 Runner API 필드 설명을 기준으로 화면 또는 API 응답을 대조할 수 있습니다.

레이블과 작업 라우팅도 점검 항목입니다. 워크플로가 요청하는 레이블과 실제 Runner에 붙은 레이블이 맞지 않으면, 호스트와 Runner가 온라인이어도 해당 작업이 배정되지 않을 수 있습니다. Runner 상태만 확인하고 종료하지 말고 워크플로 실행 API와 작업 API에서 실행 및 작업 상태를 확인하세요.

첫 단계: 실제 작업 하나로 상태를 연결합니다

다음 항목을 테스트 파이프라인에서 확인하세요.

• [ ] 실행 기록에서 해당 작업의 상태와 결과를 찾을 수 있습니다.
• [ ] 작업이 어느 Runner와 노드에서 처리됐는지 확인할 수 있습니다.
• [ ] 워크플로가 요청한 레이블과 대상 Runner의 레이블을 대조할 수 있습니다.
• [ ] 작업이 대기하거나 배정되지 않을 때 연결 문제와 라우팅 문제를 구분할 수 있습니다.

작업이 성공했는지 실패했는지만 수집하면 원인 분석에 필요한 정보가 부족합니다. 대기, 시작, 완료, 실패, 취소 상태를 기록하고, 같은 실행의 단계별 로그까지 따라갈 수 있어야 합니다. GitHub는 워크플로 실행 및 작업 정보와 로그를 확인하는 방법을 안내합니다. 워크플로 실행 로그 안내를 참고해 보존과 접근 경로를 검수하세요.

실패율과 실행 시간은 보편적인 임계값을 그대로 적용하지 마세요. 팀의 저장소, 테스트 범위, 빌드 변경에 따라 평소 값이 달라집니다. 먼저 팀이 정상이라고 판단하는 기준선을 정하고, 그 기준에서 벗어난 기록을 실제 원인과 비교한 뒤 경보 조건을 조정하세요.

CPU와 메모리, 디스크 여유 공간, 네트워크 도달성은 기본 후보입니다. 여기에 Xcode 설치 상태와 필요한 도구의 버전 또는 실행 가능 여부를 기록하세요. 지표 수집 자체를 목표로 삼지 말고, 특정 빌드의 지연이나 실패를 설명할 수 있는지 확인하는 것이 중요합니다.

메모리 압력과 사용량을 같은 의미로 다루지 마세요. macOS에서 메모리 상태를 확인하는 기준은 Apple의 활동 모니터 메모리 안내에서 확인할 수 있습니다. 팀은 지속적인 빌드 기록과 과거 장애 사례를 대조해 경보 기준을 조정해야 합니다. 출처가 없는 일반 수치를 생산 임계값으로 복사하지 마세요.

주의: CPU나 메모리 사용량이 높다는 사실만으로 빌드 실패의 원인을 확정할 수는 없습니다. 해당 시점의 작업 기록과 단계 로그를 함께 보관하고, 재현 가능한 사례로 연관성을 확인하세요.

Mac CI 관측성은 대시보드에 값이 보이는 것으로 끝나지 않습니다. Runner 진단 정보, 작업 로그, Xcode 테스트 결과를 보관하고, 실행이나 작업을 기준으로 검색할 수 있어야 합니다. Runner 진단 안내는 Runner와 작업 로그의 진단 경로를 설명합니다.

테스트 파이프라인에서는 결과 번들이 남는지도 확인하세요. Apple은 테스트 실행 및 결과 해석 안내에서 테스트 결과를 살펴보는 방법을 설명하고, Xcode 명령줄 도구 참고 자료에서 명령줄 도구를 안내합니다. Xcode 테스트 실행 시 결과 번들을 만들고, 해당 파일이 작업 기록과 함께 회수되는지 확인하세요.

Runner는 온라인인데 작업이 시작되지 않습니다

온라인 표시는 연결 확인일 뿐 작업 실행 보장은 아닙니다. Runner의 작업 중 여부와 레이블, 워크플로가 요구하는 라우팅 조건을 확인하세요. 이어서 실행 기록과 작업 상태를 같은 실행 기준으로 대조하면 배정 전 대기인지, Runner 연결 이후의 실행 문제인지 구분할 수 있습니다.

Mac CI에서 호스트와 파이프라인의 무엇을 관측해야 하나요?

Runner 연결 및 작업 상태, 워크플로와 작업 결과, 단계별 로그를 먼저 묶으세요. CPU, 메모리, 디스크, 네트워크와 Xcode 환경은 실패나 지연을 설명하는 범위에서 추가합니다. 모든 지표에 일률적인 경보 기준을 적용하지 말고, 정상 빌드 기록과 장애 사례를 비교해 팀 기준선을 정하세요.

Xcode 빌드 실패와 결과 기록은 어떻게 연결하나요?

실패한 워크플로 실행과 작업의 기록을 보존하고, 해당 작업의 단계별 로그를 열 수 있는지 확인하세요. 테스트를 수행한다면 Xcode 결과 번들도 함께 보관해 빌드 시도와 연결합니다. 성공 작업과 실패 작업을 각각 추적해 작업 식별 정보, 로그, 결과가 한 흐름으로 이어지는지 검수하세요.

알림이 실제로 장애 대응에 도움이 되는지 어떻게 확인하나요?

Runner 오프라인, 작업 실패, 디스크 부족, 결과 번들 누락과 같은 상황을 시험하고, 알림을 받은 담당자가 관련 노드와 작업을 찾아 원인 증거를 확보할 수 있는지 확인하세요. 조치 뒤에는 복구를 입증하는 기록도 남겨야 합니다. 알림만 전달되고 진단 경로가 끊기면 운영 승인 전에 보완하세요.

다음 항목을 팀의 당직 담당자와 함께 확인하세요.

• [ ] Runner 오프라인 알림이 올바른 담당자에게 전달됩니다.
• [ ] 실패한 작업에서 노드, 단계 로그, 워크플로 결과를 찾아볼 수 있습니다.
• [ ] 디스크 관련 경보가 발생하면 영향을 받은 노드와 작업을 식별할 수 있습니다.
• [ ] 테스트 결과가 빠졌을 때 누락 사실을 알아차리고 해당 작업으로 되돌아갈 수 있습니다.
• [ ] 조치 이후 Runner 연결과 새 시험 작업 결과로 복구를 확인할 수 있습니다.

위 항목을 통과하면 검수 기록과 기준선을 남기고 생산 투입을 승인할 수 있습니다. 추적은 가능하지만 담당자나 복구 증거가 불명확하다면 기한을 정해 보완하세요. 작업과 로그를 연결하지 못하거나 필요한 결과를 회수하지 못한다면 생산 확대를 보류하세요. 모니터링은 백업, 장애 복구 계획, 배포 승인을 대신하지 않습니다.

Mac CI 노드를 직접 구매해 운영하면 장비 조달과 교체, 현장 유지보수, 환경 관리가 따라옵니다. 반대로 원격 임대는 물리 장비에 직접 연결해야 하는 작업이나 장기간 일정한 고부하를 유지하는 환경에 적합하지 않을 수 있습니다. 새 노드의 실제 운영 수요를 확인하려는 단계라면 이 차이를 먼저 따져 보세요. CALMVPS 요금 안내를 기준으로 필요한 기간과 운영 조건을 검토하고, 임시 검증 환경을 마련할 때는 한국 주문 안내에서 선택 가능한 방식을 확인할 수 있습니다.