팀 iOS CI/CD에서 맥 빌드 머신은 몇 대가 필요할까? 2026 용량 계획

적합: 팀 iOS CI/CD 용량을 계획하거나 대기열 문제를 해결하려면 개발자 수로 맥 빌드 머신 수량을 환산하지 말고, 작업 도착 흐름·실행 시간·동시 실행 수·허용 대기 시간을 먼저 측정해야 합니다. 지속적으로 발생하는 부하는 고정 용량으로, 짧은 피크는 탄력 확장이나 필요할 때 추가하는 방안으로 나누어 검증하세요.

이 글은 iOS 빌드 용량을 처음 계획하는 기술 책임자와 CI 대기열이 반복되는 IT 관리자에게 적합합니다.
고정 구매와 탄력 용량을 비교해야 하는 담당자는 실제 사용량과 견적을 채울 기준을 얻을 수 있습니다.

먼저 CI 기록으로 현재 부하를 그립니다

맥 빌드 서버를 몇 대 둘지 정하기 전, CI 기록에서 작업이 언제 들어오고 언제 끝나는지 확인하세요. 개발자 수는 실제 작업량을 직접 보여주지 않습니다. 빌드가 드물어도 여러 저장소의 작업이 동시에 몰리면 대기열이 길어질 수 있고, 반대로 개발자가 많아도 작업이 시간대별로 분산되면 기존 용량으로 충분할 수 있습니다.

기록에는 저장소와 작업 종류, 트리거 시각, 실행 시작과 종료 시각, 대기 시간, 재시도 여부를 포함하세요. PR 검사, 주 브랜치 빌드, 테스트, 배포용 아카이브를 구분하면 어떤 작업이 대기열을 점유하는지 파악하기 쉽습니다. Xcode CI 흐름은 작업마다 수행 단계가 다릅니다. Xcode 작업 설정 안내는 빌드, 테스트, 분석, 아카이브 같은 작업 구성을 설명합니다. Xcode Cloud 작업 흐름 참고 문서도 작업 흐름과 실행 환경을 확인할 때 참고할 수 있습니다. CI에서 Swift 패키지와 앱을 빌드하는 문서는 CI 작업에서 패키지와 앱을 다루는 방법을 안내합니다.

과거 CI 기록으로 필요한 용량을 어떻게 추정하나요?
각 작업의 대기 시간과 실행 시간을 함께 살펴보세요. 실행 시간만 모으면 작업이 얼마나 오래 머신을 점유했는지는 알 수 있지만, 실제로 개발자가 기다린 시간은 놓칠 수 있습니다. 작업이 몰린 시간대도 따로 표시해 평균값이 피크를 가리지 않도록 하세요.

기록이 충분하지 않다면 먼저 수집을 시작하고, 기록이 쌓이기 전에는 확정 대수를 정하지 마세요. 작업 유형과 시간대를 나눠 보는 일은 용량 부족과 느린 작업 자체의 문제를 구별하는 출발점입니다.

팀 iOS CI/CD 맥 빌드 머신 수량은 피크와 대기 목표로 정합니다

다음으로 일상 시간대, 업무일의 바쁜 시간대, 배포가 몰리는 기간을 나누어 봅니다. 각 구간에서 동시에 실행 중인 작업 수, 실행 시간이 긴 작업의 비중, 대기 시간이 얼마나 이어지는지를 확인하세요. 모두에게 적용되는 고정 동시 실행 수나 보편적인 증설 기준은 없습니다. 허용 대기 시간은 팀이 정하고, 실제 기록으로 그 목표를 충족하는지 판단해야 합니다.

개발자 수와 빌드 동시 실행 수 중 무엇을 기준으로 삼아야 하나요?
개발자 수는 참고 정보로만 두고, 용량 산정은 동시 실행 수와 대기열을 중심으로 하세요. 개발자 수가 같더라도 저장소 수, 테스트 구성, PR 생성 시점에 따라 작업 부하는 다르게 나타납니다.

또한 작업을 모두 같은 종류로 취급하지 마세요. PR 검사에서 빠른 피드백이 중요하다면 긴 아카이브 작업과 자원을 나누는 방법을 검토할 수 있습니다. 반대로 긴 테스트 작업이 용량을 지속해서 점유한다면, 해당 작업의 실행 환경과 일정부터 살펴야 합니다. 실행이 느린 원인을 그대로 둔 채 머신만 추가하면 대기열 외의 비용이 늘 수 있습니다.

대기 시간만 보고 증설을 결정하지 마세요. 특정 테스트나 재시도가 반복적으로 오래 걸리는지 먼저 분리해야 합니다. 작업 자체의 지연이라면 용량 추가보다 작업 구성과 실패 원인 점검이 우선일 수 있습니다.

측정한 동시 실행 수를 runner 설정과 맞춥니다

필요한 병렬 작업 수를 추정한 뒤에는 실제로 CI 플랫폼이 그만큼의 작업을 배정할 수 있는지 확인합니다. runner 수만 늘려도 플랫폼의 동시 실행 제한, runner 그룹, 라벨 선택, 저장소 접근 권한이 맞지 않으면 작업은 계속 대기할 수 있습니다.

자체 호스팅 runner 관리 문서는 runner를 등록하고 그룹과 접근 범위를 관리하는 방법을 설명합니다. 또 워크플로 구문 문서에는 동시 실행 관련 설정이 포함되어 있습니다. 이는 해당 플랫폼의 설정 사례입니다. 다른 CI 플랫폼도 똑같이 동작한다고 가정하지 말고, 사용 중인 플랫폼의 문서와 실제 스케줄링 결과를 확인하세요.

실행 전에는 다음 항목을 순서대로 점검합니다.

• runner가 필요한 맥 환경에 등록되어 있고 온라인 상태인지 확인합니다.
• 작업이 요청하는 라벨과 runner 라벨이 일치하는지 살펴봅니다.
• 그룹이나 저장소 접근 설정이 해당 작업을 허용하는지 확인합니다.
• 플랫폼의 동시 실행 한도와 대기 중인 작업의 상태를 확인합니다.
• 작업 유형별로 예상한 runner에 배정되는지 실제 실행 기록으로 검증합니다.

팀 공유 환경이라면 권한과 환경 분리도 함께 살펴야 합니다. 빌드 자격 증명과 접근 권한을 runner 수량 결정과 별개로 점검하려면 원격 맥의 데이터 보호 안내를 참고하세요.

CI 빌드가 얼마나 기다리면 runner를 추가해야 하나요?
대기 시간이 팀이 정한 피드백 목표를 반복해서 넘고, 설정 오류나 특정 작업 지연이 주원인이 아니라는 점까지 확인되면 용량 추가를 시험하세요. 한 번의 피크만으로 상시 용량을 늘리기보다는 비슷한 조건에서 문제가 재현되는지 확인하는 편이 안전합니다.

대표 작업을 돌려 용량 가정을 확인합니다

기록을 바탕으로 한 예상은 실제 부하 테스트로 확인해야 합니다. 모든 작업을 한꺼번에 옮기지 말고, PR 검사와 테스트, 아카이브처럼 팀의 부하를 대표하는 작업을 골라 검증하세요. 작업 유형별 실행 시간, 대기 시간, 실패와 재시도, 자원 경합을 기록하고 미리 정한 서비스 목표와 비교합니다.

검증 결과는 안정적인 기본 부하와 짧은 피크로 나누어 해석하세요. 평소에도 대기 목표를 넘으면 고정 runner 용량이나 작업 분할을 검토합니다. 평소에는 목표를 만족하지만 배포 시점에만 밀리면, 상시 머신을 늘리는 대신 탄력 보충이 가능한지 시험할 수 있습니다. 실행 시간이 크게 흔들리거나 실패가 늘었다면 먼저 작업 환경과 자원 경합을 조사하세요.

비용 입력과 운영 조건을 함께 비교합니다

아래 표는 특정 가격이나 성능을 대신 산정하지 않습니다. 실제 견적과 CI 기록을 각 항목에 넣어 비교하는 결정 도구입니다. 적합도는 조건에 따른 정성 평가이며, 팀의 사용량을 대입해 확정해야 합니다.

비용 비교에는 장비나 서비스의 청구 금액만 넣지 마세요. 유휴 용량, 환경 유지, 업데이트, 운영 담당자의 관리 시간, 확장 요청부터 사용 가능해질 때까지의 지연도 팀의 실제 비용과 운영 부담에 영향을 줍니다. 각 항목은 현재 견적과 내부 기록으로 채우고, 근거가 없는 금액이나 절감률은 계산 결과처럼 제시하지 마세요.

이 표를 채운 뒤 사용 가능한 맥 구성과 이용 조건을 실제 작업 요구와 대조하세요. 구성을 확인하기 전에는 특정 작업이 지원된다고 단정하지 말고, 사용하는 Xcode 작업과 환경 조건에 맞는지 먼저 확인해야 합니다.

기록을 주기적으로 다시 보고 증설을 결정합니다

한 번 맞춘 용량을 고정된 정답으로 취급하지 마세요. Xcode 버전 변경, 테스트 행렬 확대, 저장소 추가, 배포 방식 변경은 실행 시간과 피크 패턴을 바꿀 수 있습니다. 정기적으로 최근 CI 기록을 다시 분류하고, 대기 시간과 실행 시간의 변화, 실패 재시도, runner 설정 변경을 함께 확인하세요. 목표를 벗어난 구간이 생기면 원인 작업을 먼저 좁힌 뒤 증설 여부를 다시 평가합니다.

고정 구매 장비는 장기간의 안정적인 부하와 자체 관리 여건이 있을 때 검토할 수 있습니다. 반면 배포 때만 생기는 피크에 맞춰 장비를 보유하면 유휴 시간과 유지 관리가 부담이 될 수 있습니다. 다른 운영 방식에 대한 조건을 비교하고 싶다면 서비스 안정성 안내도 검토 자료로 활용할 수 있습니다.

기존 장비만으로 모든 피크를 감당하면 작업 대기와 운영 관리가 부담이 되고, 일반적인 비맥 runner는 Xcode 기반 작업 환경을 그대로 대신하지 못합니다. 그렇다고 필요한 대수를 확인하지 않은 채 장비를 구매하면 유휴 용량과 유지 부담이 남을 수 있습니다. 따라서 CI 기록과 대표 작업 검증으로 상시 부하와 피크를 구분한 뒤, 부족한 피크만 보충할 선택지가 필요할 때 SDKMac의 원격 맥 구성을 확인해 보세요. 실제 작업 요건과 이용 기간이 맞는지 먼저 대조하고, 적합할 때만 탄력 용량으로 추가하는 편이 합리적입니다.