빌드 대기열이 피크 시간마다 길어지고 릴리스 작업이 합류를 기다린다면, 개발자 수만으로 맥 미니 M4 빌드 머신 수를 정해서는 안 됩니다.
가장 빠른 해법은 피크 작업 도착량, 작업별 P95 실행 시간, 목표 대기 시간, 허용 중단 범위를 먼저 수집하고, 같은 환경에서 측정한 한 노드의 유효 처리량과 장애 예비 용량을 넣어 계산하는 것입니다.
이 글은 다음 담당자를 위한 내용입니다.
신규 아이오에스 팀의 빌드 자원을 예산화하는 IT 책임자에게 적합합니다.
이미 합류나 릴리스가 대기열의 영향을 받는 연구 개발 효율 책임자, 고정 구매와 원격 맥 및 혼합 구성을 비교하는 기술 총괄도 대상입니다.
[ SECTION_01 ] 맥 미니 M4 빌드 머신 용량 계획에 필요한 네 가지 입력
| 입력 지표 | 수집할 값 | 계산에서의 역할 | 증거가 부족할 때 |
|---|---|---|---|
| 피크 작업 도착량 | 시간대별 작업 수와 유형 | 동시에 들어오는 총 작업량 | 월간 평균 대신 가장 바쁜 구간의 로그 사용 |
| 작업별 P95 시간 | 검사, 테스트, 보관, 배포별 실행 시간 | 실제 처리해야 할 작업량 | 작업 유형을 섞은 평균값 사용 금지 |
| 목표 대기 시간 | 합류 검증과 릴리스별 허용 대기 | 필요한 여유 처리량 결정 | 서비스 목표를 먼저 문서화 |
| 허용 중단 범위 | 유지 보수와 노드 장애 때 허용할 감소량 | 독립 예비 용량 결정 | 예비 노드를 일상 용량에 포함하지 않음 |
이 네 값 중 하나라도 없으면 “몇 대가 필요한가”라는 질문에 신뢰할 만한 답을 내기 어렵습니다. 평균 이용률만 보면 짧은 릴리스 집중이나 합류 직후의 동시 검증을 놓칠 수 있습니다.
따라서 첫 판단은 증설이 아닙니다. 먼저 의존성 오류, 불필요한 빌드 단계, 캐시 오작동, 외부 의존성 지연을 분리합니다. 구성 문제를 장비 문제로 계산하면 필요 노드 수가 부풀려집니다.
[ SECTION_02 ] 첫 단계: 작업 강도를 유형별로 분리합니다
아이오에스 CI/CD 작업은 하나의 평균 빌드 시간으로 묶으면 안 됩니다. 코드 검사와 단위 테스트는 짧아도 빈번할 수 있습니다. 사용자 인터페이스 테스트는 시뮬레이터와 외부 리소스를 점유할 수 있습니다. 보관과 서명 배포는 실행 빈도가 낮아도 릴리스 대기와 직접 연결됩니다.
CI 로그에서 다음 항목을 별도로 추출합니다.
- 합류 요청에서 발생한 코드 검사와 단위 테스트
- 사용자 인터페이스 테스트와 시뮬레이터 점유 시간
- 예약 작업과 야간 전체 빌드
- 보관, 서명, 배포 작업
- 피크 구간의 도착 시각과 대기 시작 시각
- 캐시 적중 여부와 의존성 다운로드 상태
피크 작업량은 다음처럼 표현할 수 있습니다.
피크 작업량 = Σ(작업 유형별 도착 수 × 해당 유형의 P95 실행 시간)
예약 작업, 합류 검증, 릴리스 작업이 같은 시간대에 겹치면 각각의 작업량을 합산합니다. 개발자 수는 이 식의 입력이 아닙니다. 같은 인원의 팀이라도 자동화 정책과 릴리스 집중도에 따라 결과가 크게 달라집니다.
[ SECTION_03 ] 두 번째 단계: 한 노드의 유효 처리량을 직접 측정합니다
맥 미니 M4와 M4 프로의 공식 사양은 선택 가능한 하드웨어의 경계를 보여줍니다. 그러나 특정 프로젝트가 한 시간에 처리할 수 있는 보관 작업 수를 공식 칩 사양에서 바로 도출할 수는 없습니다. 애플의 맥 미니 기술 사양은 장비 비교의 출발점으로만 사용해야 합니다.
기준 작업은 다음 조건을 고정해 실행합니다.
- 동일한 코드 커밋을 사용합니다.
- 동일한 엑스코드 버전과 SDK를 고정합니다.
- 의존성 저장소와 네트워크 경로를 통일합니다.
- 냉각 상태와 캐시 상태를 구분합니다.
- 냉간 빌드, 증분 빌드, 테스트, 보관을 각각 기록합니다.
- 단일 작업부터 동시 작업까지 단계적으로 부하를 높입니다.
- 실행 시간, 대기 시간, 실패 원인과 자원 경쟁을 함께 저장합니다.
엑스코드의 빌드 시간 요약은 파일과 작업별 소요 시간을 확인하는 데 활용할 수 있습니다. 증분 빌드 속도 개선을 위한 애플 문서는 측정 절차와 빌드 시간 요약의 활용 방법을 설명합니다.
또한 빌드 단계 구성에 관한 애플 문서를 이용해 스크립트, 복사 작업, 생성 단계가 실제 병목인지 확인합니다. 직렬 스크립트가 긴데 장비만 교체하면 비용은 늘고 대기열은 거의 줄지 않을 수 있습니다.
[ SECTION_04 ] 세 번째 단계: 기본 노드 수와 대기 목표를 계산합니다
한 노드의 유효 처리량을 노드 처리량이라고 하면 기본 노드 수는 다음과 같이 계산합니다.
기본 노드 수 = 올림(피크 작업량 ÷ 한 노드의 유효 처리량)
여기서 유효 처리량은 광고된 코어 수가 아닙니다. 기업의 기준 작업을 실제로 실행하고, 캐시와 동시 작업 경쟁 및 실패 재시도를 반영한 값입니다.
그 다음 목표 대기 시간에 맞는 버퍼를 추가합니다. 야간 전체 빌드는 대기 목표가 비교적 느슨할 수 있습니다. 일상 합류 검증은 짧은 대기를 요구할 수 있습니다. 릴리스 창은 실패 재시도와 서명 작업까지 고려해야 하므로 별도의 여유가 필요합니다.
실무에서는 다음 조건을 분리해 기록합니다.
- 야간 작업이 다음 업무 시작 전 끝나면 되는지
- 합류 검증이 일정 대기 시간을 넘으면 안 되는지
- 릴리스 작업이 특정 시간 창 안에 완료되어야 하는지
- 유지 보수 중에도 핵심 배포를 계속해야 하는지
대기 목표를 넘긴 기록이 반복될 때 증설을 검토합니다. 특정 순간의 CPU 최고치만으로 노드를 늘리지는 않습니다.
[ SECTION_05 ] 네 번째 단계: 동시 실행의 실제 손실을 측정합니다
한 대의 맥에서 여러 작업을 동시에 실행하면 종이상 슬롯 수는 늘어납니다. 하지만 유효 처리량이 같은 비율로 늘어난다는 뜻은 아닙니다.
특히 다음 자원이 충돌하기 쉽습니다.
DerivedData를 공유하는 작업- 시뮬레이터와 테스트 데이터
- 키체인과 서명 인증서
- 같은 작업 공간과 임시 파일
- 의존성 다운로드와 디스크 입출력
- 환경 정리 전 새 작업이 시작되는 경우
단일 맥 다중 작업은 장비 수를 줄일 수 있습니다. 반면 한 장비의 장애가 여러 작업에 영향을 줍니다. 작업별 노드를 사용하면 격리는 쉬워지지만 고정 비용과 유휴 시간이 늘어날 수 있습니다.
동시성 상한은 일반적인 숫자로 정하면 안 됩니다. 단일 작업을 기준으로 동시 작업을 하나씩 늘리면서 다음 변화를 확인해야 합니다.
- 각 작업의 P95 실행 시간
- 대기 시간 증가
- 서명 또는 키체인 오류
- 시뮬레이터 충돌
- 캐시 오염과 작업 후 정리 실패
- 노드 장애 시 영향을 받는 작업 수
엑스코드 대상 의존성과 병렬 빌드 설명을 기준으로 병렬화 가능한 작업과 직렬로 묶인 작업을 구분합니다. CI를 자체 실행기로 운영한다면 실행기 라벨과 그룹을 관리하는 공식 문서도 함께 확인해야 합니다.
[ SECTION_06 ] 다섯 번째 단계: 증설 여부를 체크리스트로 결정합니다
아래 항목은 “장비를 더 살 것인가”보다 먼저 확인할 운영 조건입니다.
- [ ] 피크 시간대의 작업 도착량을 합류, 테스트, 보관, 배포로 분리했습니다.
- [ ] 각 작업 유형의 P95 실행 시간을 동일한 코드 기준으로 수집했습니다.
- [ ] 냉간 빌드와 증분 빌드를 별도로 기록했습니다.
- [ ] 엑스코드 빌드 시간 요약으로 직렬 스크립트와 목표 의존성을 확인했습니다.
- [ ] 한 노드의 동시 작업 수를 단계별 압력 테스트로 검증했습니다.
- [ ] 공유
DerivedData, 시뮬레이터, 키체인과 작업 공간의 격리 방식을 정했습니다. - [ ] 목표 대기 시간이 반복해서 초과되는지 확인했습니다.
- [ ] 계획 유지 보수와 노드 장애에 필요한 독립 예비 용량을 따로 계산했습니다.
- [ ] 고정 노드 비용, 탄력 용량 비용, 대기로 인한 연구 개발 시간 손실을 비교했습니다.
- [ ] 새 노드가 문제를 해결하지 못할 수 있는 의존성 및 네트워크 병목을 제거했습니다.
체크되지 않은 항목이 남아 있다면 구매 수량을 확정하지 않는 편이 안전합니다. 특히 측정 없이 동시 슬롯만 늘리는 결정은 대기열과 실패 재시도를 동시에 키울 수 있습니다.
[ SECTION_07 ] 고정 노드, 단일 노드, 원격 맥을 나누는 기준
비용은 장비 가격만으로 비교하지 않습니다. 고정 노드의 총비용에는 하드웨어 감가, 보관 공간, 전원, 교체 장비, 운영 인력, 장애 복구 시간이 들어갑니다. 탄력 용량에는 사용 기간, 연결 방식, 접근 제어, 데이터 이동과 환경 초기화 비용이 포함됩니다.
대기로 발생하는 연구 개발 시간 손실도 별도 항목으로 둡니다. 빌드가 기다리는 동안 발생하는 비용은 회계 장부의 서버 비용에는 보이지 않지만, 릴리스 지연과 합류 지연으로 나타납니다.
| 운영 조건 | 적합한 구성 | 결정 기준 | 주요 위험 |
|---|---|---|---|
| 비핵심 시험 단계 | 단일 검증 노드 | 기준 작업과 처리량을 아직 측정하는 단계 | 장애와 대기열이 모두 집중됨 |
| 안정적인 일상 CI | 고정 노드 풀 | 피크 작업량과 대기 목표가 반복적으로 확인됨 | 평상시 유휴 용량과 유지 비용 |
| 릴리스가 집중되는 팀 | 고정 기준 노드와 탄력 원격 맥 | 일상량과 릴리스 피크의 차이가 큼 | 접근 제어와 환경 동기화 필요 |
| 서명과 보안 격리가 중요한 팀 | 분리된 전용 노드 | 키체인, 인증서, 작업 공간을 공유하지 않아야 함 | 노드 수와 관리 복잡도 증가 |
고정 노드 총비용이 낮더라도 피크를 감당하지 못하면 서비스 목표를 충족하지 못합니다. 반대로 피크가 드물고 평상시 작업량이 작다면 모든 용량을 상시 구매하는 방식이 비효율적일 수 있습니다.
[ SECTION_08 ] 자주 묻는 운영 판단
FAQ에서는 팀 인원, 동시 실행 수, 이용률만으로 용량을 확정할 수 없다는 점을 구분해야 합니다. 실제 결정에는 작업 로그와 기준 테스트가 필요합니다.
결론을 적용하는 순서
첫째, 기존 파이프라인의 불필요한 작업과 의존성 병목을 제거합니다. 둘째, 같은 조건의 기준 작업으로 한 노드의 유효 처리량을 구합니다. 셋째, 피크 작업량을 나누고 목표 대기 시간과 예비 용량을 더합니다. 넷째, 결과를 올림한 뒤 실제 대기열로 다시 검증합니다.
맥 미니 M4가 충분한지 M4 프로가 필요한지도 같은 방식으로 판단합니다. 작업이 독립적으로 많이 쌓이는 구조라면 노드 수가 더 직접적인 해법입니다. 특정 작업이 디스크, 메모리, 직렬 스크립트에 막힌다면 고성능 장비나 파이프라인 수정이 먼저일 수 있습니다.
[ SECTION_09 ] 현재 방식과 원격 맥을 함께 비교해야 하는 시점
자체 구매한 맥 미니만 사용하는 방식은 피크를 위해 장비를 상시 보유해야 하고, 고장과 운영체제 또는 엑스코드 갱신 때 예비 장비가 필요합니다. 한 대에 여러 작업을 몰아넣으면 작업 격리와 서명 자격 증명 관리가 어려워집니다. 반대로 고정 노드를 과도하게 늘리면 평상시 유휴 용량과 관리 비용이 남습니다.
이때 NOVAKVM의 원격 맥에서 동일한 코드, 엑스코드, 캐시 조건으로 기준 작업을 실행하면 구매 전에 실제 처리량을 확보할 수 있습니다. 피크와 평상시 수요의 차이가 크다면 고정 기준 노드와 필요 시 추가하는 원격 맥을 비교하는 편이 합리적입니다. 맥 미니 M4 대여 비용과 조건을 확인한 뒤, 먼저 측정값을 만들고 그 결과를 용량 공식에 대입해야 합니다.
장기적으로 변하지 않는 고강도 작업, 물리 장비 연결, 현장 전용 보안 통제가 필수라면 직접 구매가 더 적합할 수 있습니다. 반대로 일시적인 릴리스 집중, 신규 팀 검증, 지역별 탄력 용량이 필요하다면 NOVAKVM의 원격 맥 환경으로 한 노드 기준 테스트를 진행하는 것이 더 안전한 출발점입니다. 기준 작업과 대기열 기록을 확보한 뒤에야 고정 노드 수와 혼합 구성을 제대로 비교할 수 있습니다.