Mac CI 서비스 SLA는 어떻게 검수할까? 2026 기업 구매 체크리스트

공개 SRE 안내서는 SLI·SLO·SLA를 서로 다른 세 가지 서비스 수준 개념으로 구분합니다. 따라서 Mac CI 서비스 SLA 검수에서는 호스트 가동률만 보지 말고, 합의한 CI 작업이 시작되고 끝나는지, 장애 시간을 어떻게 계산하는지, 누가 복구를 책임지는지 확인해야 합니다. 목표값은 팀의 업무 요건과 실제 계약을 바탕으로 정해야 합니다.

이 글은 Mac CI 서비스를 구매하는 기업 IT 담당자와 조달 책임자를 위한 기준입니다.
플랫폼 엔지니어는 서비스 상태와 실제 빌드 성공이 일치하는지 확인할 수 있습니다.
기술 총괄과 개발 효율 책임자는 복구 책임과 출시 위험을 검토할 수 있습니다.

Mac CI 서비스 SLA 검수는 호스트 가동률과 작업 성공률을 나눕니다

SSH 접속이나 웹 콘솔 연결은 호스트에 접근할 수 있다는 뜻입니다. Runner가 작업을 받는지, Xcode 빌드가 완료되는지, 결과물이 전달되는지는 별도로 확인해야 합니다. SLA의 측정값은 사용자가 실제로 기대하는 결과와 연결해야 한다는 원칙은 서비스 목표를 사용자 경험에 맞추는 SRE 지침에서도 설명합니다.

맥 CI 가동률은 호스트와 빌드 작업 중 무엇을 기준으로 해야 하나요?

구매 전에 대표 CI 작업을 정하고, 시작·완료 상태를 측정 대상으로 계약서에 적어야 합니다. 예를 들어 작업 접수, Xcode 빌드, 테스트, 산출물 저장을 한 흐름으로 합의할 수 있습니다. 실패했을 때 서비스 장애인지, 저장소·테스트 코드·서명 설정 문제인지 구분할 책임도 정해야 합니다.

Xcode 명령줄 도구 안내는 xcodebuild를 빌드와 테스트에 활용하는 명령줄 도구로 설명합니다. 따라서 접속 확인만으로는 CI 작업을 검수할 수 없습니다. 승인할 빌드 명령과 입력 조건을 고정하고, 워크플로 로그에서 작업별 결과를 확인하는 방법처럼 실행 단계별 기록을 남겨야 합니다.

xcodebuild -scheme "$SCHEME" -destination "$DESTINATION" test

로그 예시:

runner_state: accepted
build_state: completed
test_state: passed
artifact_state: stored

이 표기는 기록 항목의 예시이며, 특정 서비스에서 확인된 실제 결과나 성능을 뜻하지 않습니다. 팀은 사용할 Runner와 산출물 저장 위치, 실패 판정 기준을 계약에 맞춰 정해야 합니다.

분모와 장애 시각은 계약 문구만으로 끝내지 않습니다

맥 빌드 서버 장애 시간은 어느 시점부터 계산해야 하나요?

계약에는 통계 대상과 기간, 장애 시작·종료 판정 기준이 있어야 합니다. “가동률”만 있고 계산 방식이 없다면 같은 장애를 두고도 산정 결과가 달라질 수 있습니다. 작업을 제출한 시점, Runner가 받지 못한 시점, 빌드가 중단된 시점 중 무엇을 시작점으로 볼지 합의해야 합니다.

실무에서는 CI 실행 기록, 서비스 상태 기록, 양측이 인정하는 시각을 함께 보존합니다. 자체 관리 Runner의 상태 확인과 문제 진단 문서는 Runner 관련 점검에 참고할 수 있지만, 다른 환경의 문서가 해당 서비스 계약을 대신하지는 않습니다.

응답과 복구는 서로 다른 책임으로 적습니다

사건 접수 확인은 빌드 복구와 다릅니다. 계약과 운영 절차에는 사건 확인, 조치 시작, 원격 접근 복구, 빌드 가능 상태 복원, 배포 검증을 나누어 적어야 합니다. 각 상태의 담당자와 다음 단계로 넘기는 조건도 정합니다.

SRE 사건 관리 안내는 사건 대응에서 역할과 인수인계를 명확히 하는 접근을 다룹니다. 구매자는 이를 바탕으로 통지 채널, 사건 등급, 담당자 부재 시의 상향 경로를 확인할 수 있습니다.

접수 확인 시각을 업무 복구 시각으로 간주하면 안 됩니다. 계약에 상태별 책임과 완료 조건이 없다면 추가 조항을 요청해야 합니다.

첫 번째 단계: 실제 복구 판정에 필요한 기록을 정합니다

작업 식별자, 실행 결과, 실패 원인 분류, 상태 변경 시각, 산출물 확인 여부를 기록 항목으로 정합니다. 값이 비어 있거나 출처가 불분명한 기록은 분쟁 때 재검증하기 어렵습니다. 사건 대응 준비와 협업 지침을 참고해 연락 담당자와 역할 인계 절차도 문서화할 수 있습니다.

유지보수 예외는 공지와 검증 책임까지 확인합니다

계획 유지보수와 macOS 업데이트도 정지 시간에 포함해야 하나요?

일괄적으로 포함하거나 제외하기보다, 예외가 적용되는 범위와 사전 통지, 기록 방식, 작업 완료 후 검증 책임을 계약에서 확인해야 합니다. 시스템 업데이트나 재시작, Xcode 환경 변경이 예정돼 있다면 CI 작업에 미치는 영향과 되돌리기 조건도 정해야 합니다.

유지보수 예외가 포괄적으로 쓰여 있으면 실제 장애와 예정 작업을 구분하기 어렵습니다. 공지 시점, 변경 대상, 빌드 확인 방법, 문제가 생겼을 때의 원복 책임이 빠져 있다면 구매 전에 보완을 요청합니다.

맥 CI 서비스 구매 때 어떤 장애·복구 증거를 받아야 하나요?

서명 전 증거 자료는 실제 운영 기록으로 재검증할 수 있어야 합니다. 워크플로 산출물 안내는 작업 산출물을 저장하고 공유하는 기능을 설명합니다. 이를 계약상 증거와 혼동하지 말고, 산출물 보존 위치와 접근 권한, 로그 보존 범위를 별도로 확인해야 합니다.

보상 조항과 운영 복원력은 따로 검토합니다

서비스 크레딧이나 기타 보상은 적용 조건, 신청 절차, 증빙 기준이 계약에 명시돼야 합니다. 다만 비용 보상이 있다고 해서 출시 일정이 지켜지거나 CI가 자동 복구되는 것은 아닙니다. 백업 빌드 경로, 배포 일정 보호, 팀의 복구 연습은 별도 운영 통제로 준비해야 합니다.

다음 조건으로 구매 판단을 내릴 수 있습니다.

• 작업 시작과 성공을 측정할 수 있고, 실패 귀속 기준까지 정해졌다면 해당 지표를 계약 검토 대상으로 삼습니다. 아니라면 가동률 수치만으로 승인하지 않습니다.
• 장애 시각과 통계 분모, 유지보수 예외가 검증 가능한 기록과 연결된다면 서명 자료에 포함합니다. 기준이 모호하면 계산 방법을 보완합니다.
• 접수·조치·접근 복구·빌드 복구의 책임자가 지정됐다면 사건 대응 절차를 대조합니다. 책임 인계가 비어 있다면 승인 전에 담당자를 지정합니다.
• 보상 조건이 명확하고 별도의 대체 빌드 경로도 준비돼 있다면 운영 위험을 함께 평가합니다. 보상만 있고 복구 계획이 없다면 출시 위험은 해결되지 않은 것으로 봅니다.

아래 조건에 따라 계약을 승인할지, 보완할지, 보류할지 결정합니다.

Mac CI 서비스 SLA는 한 줄의 가동률보다 측정 가능한 작업 결과와 책임 경계가 중요합니다. 먼저 이 기준표를 현재 계약에 대조하고, 원격 맥이 팀의 빌드·출시 부하에 적합한지도 따로 평가해야 합니다. 기존 장비 구매는 초기 투자와 유휴 용량, 교체·유지 관리가 부담이 될 수 있고, 일반 클라우드 빌드 환경만으로는 macOS 기반 작업을 그대로 대체하기 어렵습니다. 반대로 부하가 꾸준히 크거나 물리 장비 연결이 필요하다면 자체 장비가 더 적합할 수 있습니다. 사용량이 변하거나 검증용 환경이 필요한 팀이라면 SFTPMAC 원격 맥 서비스 범위와 맥 미니 대여 가격 안내를 확인한 뒤, 약정 조건과 실제 업무 요건을 함께 비교하는 편이 안전합니다.