빌드 시간은 줄지 않는데 캐시 저장 공간과 네트워크 비용만 늘고 있습니까? 가장 빠른 해법은 전면 도입이 아니라 고정된 맥 노드에서 읽기 전용 시범 운영을 먼저 하고, 적중과 대기열 자료로 캐시 확대 또는 맥 증설을 결정하는 것입니다.
이 글은 대형 iOS 프로젝트를 Bazel로 빌드하는 연구 효율 책임자, 기업 IT 및 재무 담당자, 플랫폼과 보안 엔지니어를 위한 판단 문서입니다. 이미 Bazel을 사용하고 있으며 반복 컴파일을 줄이려는 팀에 적합합니다. 단순한 설치 명령이 아니라 투자 기준과 운영 경계를 다룹니다.
마지막 업데이트: 2026년 9월 1일. Bazel 원격 캐시 문서, Bazel 9.1.0 릴리스 기록, rules_apple 및 rules_swift 공식 저장소, Apple Xcode 시스템 요구 사항을 기준으로 확인했습니다.
첫 판단: 캐시를 켤지 맥을 늘릴지
원격 캐시는 Bazel 동작의 결과물을 여러 빌드에서 재사용합니다. 따라서 다른 장비가 Xcode, 시뮬레이터 또는 서명 작업을 대신 실행하는 기능이 아닙니다. 이 차이를 놓치면 캐시를 구축한 뒤에도 실제 맥 대기열이 줄지 않을 수 있습니다.
| 관찰된 조건 | 우선 선택 | 판단 이유 |
|---|---|---|
| 같은 입력을 쓰는 반복 동작이 많고 도구 체인이 고정됨 | 읽기 전용 원격 캐시 시범 운영 | 재사용 가능성을 먼저 검증할 수 있습니다 |
| 캐시 적중은 있으나 서명과 아카이브 대기열이 계속됨 | 맥 빌드 노드 우선 확장 | 캐시가 처리하지 않는 작업이 병목입니다 |
| 노드마다 Xcode, SDK, 환경 변수와 경로가 다름 | 전면 도입 보류 | 재현성이 낮아 잘못된 재사용 위험이 있습니다 |
| 다운로드 실패와 긴 네트워크 지연이 반복됨 | 캐시 구성 수정 또는 맥 확장 | 전송 비용이 재사용 이익을 상쇄할 수 있습니다 |
| 민감한 서명 대상과 일반 컴파일 대상이 섞임 | 대상별 캐시 제외와 권한 분리 | 모든 결과물을 공유하면 보안 경계가 흐려집니다 |
기준선: 네 가지 선택지를 분리하기
기업 iOS CI에서 자주 혼동되는 선택지는 서로 대체 관계가 아닙니다.
| 선택지 | 줄이는 대상 | 남는 맥 작업 | 주요 위험 |
|---|---|---|---|
| Bazel 원격 캐시 | 이미 계산된 Bazel 동작의 재실행 | Xcode 실행, 서명, 아카이브, 시뮬레이터 | 잘못된 입력으로 인한 오염 |
| 원격 실행 | 일부 동작의 실행 위치 | 실행 불가 도구와 Apple 전용 작업 | 도구 체인과 실행 환경 의존 |
| Xcode 네이티브 빌드 캐시 | Xcode 내부의 일부 반복 처리 | 프로젝트 설정과 Apple 도구 체인 | Bazel 캐시와 효과가 다름 |
| 맥 빌드 노드 증설 | 병렬 실행 대기열 | 모든 허용된 맥 작업 | 장비, 유지 관리, 용량 비용 |
현재 노드가 부족한 팀은 기업 iOS CI용 맥 빌드 노드 용량 계획을 먼저 확인하는 편이 좋습니다. 캐시가 성공해도 캐시가 적용되지 않는 작업의 동시 실행 수는 그대로 남기 때문입니다.
재현성: 적중률보다 먼저 확인할 항목
원격 캐시의 핵심 조건은 같은 입력에 같은 결과가 나오는 것입니다. 소스가 같다는 사실만으로 충분하지 않습니다. Bazel의 동작 입력에 환경 변수, 실행 경로, 도구 파일, SDK, 외부 프로그램과 생성 파일이 포함될 수 있기 때문입니다.
다음 항목이 하나라도 노드별로 다르면 캐시 미적중이나 부적절한 재사용이 발생할 수 있습니다.
- Xcode와 SDK 조합
- Bazel 9의 정확한 릴리스와 시작 옵션
- rules_apple, rules_swift의 버전과 저장소 상태
- 절대 경로와 작업 공간 위치
- 환경 변수와 비밀값의 주입 방식
- 외부 도구의 위치와 실행 파일 버전
- 생성 파일의 시간, 순서, 지역 설정
- 서명 인증서와 프로비저닝 관련 입력
| 조합 상태 | 운영 분류 | 필요한 조치 |
|---|---|---|
| 공식 릴리스 기록과 저장소에서 지원 범위가 확인됨 | 공식 확인 | 고정된 맥 구성으로 별도 검증 |
| 팀의 같은 프로젝트와 같은 노드에서 반복 검증됨 | 팀 검증 | 로그와 산출물 해시를 보관 |
| 개발 브랜치, 미리 보기 기능 또는 미병합 수정에 의존함 | 격리 시험 | 생산 캐시와 분리하고 실패 시 자동 중단 |
| Xcode 또는 SDK가 노드마다 다름 | 보류 | 기준 이미지를 고정한 뒤 재시험 |
측정: 빌드 시간 하나로 결론 내리지 않기
시범 운영은 같은 커밋, 같은 작업 순서, 같은 맥 구성으로 진행해야 합니다. 비교군은 캐시 없음, 읽기 전용 캐시, 통제된 읽기와 쓰기 캐시로 나눕니다. 한 번의 빠른 실행보다 반복 실행에서 같은 결과가 나오는지가 중요합니다.
기록할 지표는 다음과 같습니다.
- 원격 캐시 적중과 미적중의 건수 및 원인
- 객체 다운로드와 업로드에 걸린 시간
- 전송 실패와 재시도 횟수
- 캐시 객체 증가량과 오래된 객체의 비율
- 깨끗한 빌드와 증분 빌드의 차이
- 맥 노드 대기 시간과 실제 실행 시간
- 캐시가 꺼졌을 때의 복구 시간
- 산출물 해시, 테스트 결과와 서명 검증 결과
네트워크 위치도 분리해서 기록해야 합니다. 캐시와 맥 노드가 같은 지역에 있을 때, 서로 다른 지역에 있을 때, 원격 팀이 접속할 때의 결과가 다를 수 있습니다. 큰 객체를 반복해서 내려받으면 저장 비용뿐 아니라 전송 지연과 실패 복구 시간이 누적됩니다. 반대로 작은 동작을 많이 재사용하면 네트워크 요청 자체가 병목이 될 수 있습니다.
권한과 안전: 쓰기 대상을 최소화하기
공유 캐시는 모든 개발자가 결과를 쓰는 저장소가 아닙니다. 입력이 완전히 통제되지 않은 노드가 쓰기 권한을 가지면 잘못된 도구 체인이나 변조된 결과가 다른 빌드에 전달될 수 있습니다.
| 노드 유형 | 실행 범위 | 캐시 권한 | 감사 자료 | 이상 발생 시 조치 |
|---|---|---|---|---|
| 기준 맥 빌드 노드 | 일반 컴파일과 검증 | 제한적 읽기와 쓰기 | 커밋, 도구 체인, 실행자 기록 | 쓰기 중단 후 객체 격리 |
| 개발자 작업 노드 | 개발 빌드 | 읽기 전용 또는 제외 | 사용자와 요청 기록 | 인증 정보 폐기와 접근 검토 |
| 서명 전용 노드 | 서명과 아카이브 | 캐시 제외 또는 읽기 전용 | 서명 로그와 산출물 해시 | 즉시 네트워크와 권한 분리 |
| 실험 노드 | 미리 보기 도구 체인 | 별도 시험 저장소 | 실험 버전과 결과 기록 | 생산 저장소 접근 차단 |
서명 대상, 배포용 아카이브, 비밀값이 입력으로 들어가는 동작은 일반 컴파일 캐시와 같은 정책으로 다루지 않는 것이 안전합니다. 캐시를 쓴다는 이유로 인증서나 프로비저닝 정보를 여러 노드와 공유해서는 안 됩니다.
비용: 캐시와 맥 용량을 같은 식으로 계산하기
Bazel 9 원격 캐시의 투자 판단은 저장 공간 가격만으로 끝나지 않습니다. 다음 변수를 같은 기간에 놓고 계산해야 합니다.
총비용 = 캐시 구축 및 운영비 + 네트워크 전송비 + 저장 공간비 + 운영 인력 시간비 + 캐시 미적중으로 남은 맥 대기 손실
여기에 맥 노드 증설안을 별도로 계산합니다.
맥 증설 비용 = 장비 또는 원격 맥 이용료 + 운영 시간비 + 보안 관리비 + 유휴 용량 비용
| 시나리오 | 캐시 투자 | 맥 용량 | 적합한 조건 | 중단 신호 |
|---|---|---|---|---|
| 캐시 우선 | 저장과 전송 자원 중심 | 기존 풀 유지 | 반복 동작과 노드 간 중복이 높음 | 전송 시간이 재실행보다 길어짐 |
| 맥 우선 | 캐시 최소화 | 대기열 처리에 필요한 노드 확보 | 서명, 테스트, 아카이브가 병목 | 유휴 노드가 계속 늘어남 |
| 혼합 운영 | 기준 캐시와 탄력 맥 풀 | 피크 작업만 추가 | 캐시 적용 작업과 비적용 작업이 공존 | 권한과 결과 추적이 어려워짐 |
반대로 맥 노드만 늘리면 같은 입력을 여러 번 계산하는 비용이 남습니다. 반복률이 높은 대형 프로젝트라면 읽기 전용 캐시가 맥 확장 전에 검증할 후보가 됩니다. 단, 그 결론은 실제 로그의 적중, 전송, 대기 자료로만 내려야 합니다.
원격 맥을 기준 노드나 피크 용량으로 검토할 때는 서울 지역 맥 이용 선택지처럼 실제 접근 지역과 전달 방식을 확인해야 합니다. 팀의 네트워크 경로가 다른 경우에는 지역과 전달 방식을 먼저 비교하고, 캐시 성능을 제품 설명만으로 추정하지 말고 같은 시험을 반복해야 합니다.
실행 기준: 조건에 따라 투자 방향 정하기
다음 조건 목록을 시범 운영 승인 회의의 결정표로 사용하면 됩니다.
- 반복 동작과 노드 간 중복이 로그로 확인되고 도구 체인이 고정되어 있으면, 읽기 전용 캐시 시범 운영을 선택합니다.
- 적중은 발생하지만 서명, 아카이브, 시뮬레이터 테스트의 대기열이 줄지 않으면, 캐시 확대보다 맥 용량 검토를 선택합니다.
- 노드마다 Xcode, SDK, 경로 또는 외부 도구가 다르면, 캐시 쓰기를 막고 기준 환경 통일부터 진행합니다.
- 전송 실패와 다운로드 지연이 반복되면, 캐시 위치와 네트워크를 고친 뒤 재시험하고, 개선되지 않으면 맥 증설로 회귀합니다.
- 민감한 Target이 일반 컴파일과 섞여 있으면, 서명과 배포 동작을 캐시에서 제외하고 권한 매트릭스를 먼저 확정합니다.
- 산출물 해시나 테스트 결과가 달라지면, 해당 캐시 객체와 쓰기 노드를 격리하고 원인 조사 전에는 생산 사용을 중단합니다.
- 캐시가 꺼져도 정해진 복구 절차로 빌드가 끝나지 않으면, 캐시를 가용성 전제로 삼지 말고 독립적인 맥 실행 경로를 유지합니다.
현재 방식이 개발자마다 다른 맥에서 직접 빌드하는 구조라면 환경 차이, 장비 유휴 시간, 인증 정보 분산이라는 세 가지 문제가 남습니다. 자체 장비 구매는 장기 안정 부하에는 적합할 수 있지만 초기 자본 지출과 교체, 장애 대응 부담을 함께 떠안아야 합니다. 반면 짧은 검증 기간이나 피크 대기열에는 MACGPU 원격 맥 환경을 기준 노드 또는 탄력 빌드 풀로 비교해 볼 수 있습니다. 캐시와 맥 용량을 분리해 측정하면 필요한 기간만 원격 맥을 쓰는 선택도 가능합니다.
자주 묻는 판단
FAQ는 위의 운영 원칙을 구매와 보안 검토 문맥에서 다시 확인하기 위한 것입니다. Bazel 9 원격 캐시는 더 많은 맥을 자동으로 만들어 주지 않으며, 시범 자료가 없을 때 비용 절감 결론을 대신 내려 주지도 않습니다.
캐시가 맥 빌드 노드를 완전히 대체할 수 있습니까?
대체할 수 없습니다. 캐시는 재사용 가능한 Bazel 동작 결과를 제공할 뿐이며 Xcode 실행, 시뮬레이터 테스트, 서명, 아카이브와 캐시에서 제외한 작업은 실제 맥에서 실행해야 합니다. 피크 시간의 대기열과 캐시 미적중 작업을 따로 집계한 뒤 필요한 맥 용량을 계산해야 합니다.
여러 지역에 캐시를 두면 항상 더 빠릅니까?
항상 그렇지는 않습니다. 캐시와 맥 노드의 위치, 객체 크기, 요청 수, 네트워크 실패 복구 방식에 따라 결과가 달라집니다. 지역을 추가하기 전에 같은 커밋으로 지역별 다운로드 시간과 실패 기록을 비교해야 합니다. 전송 비용과 운영 복잡성이 재실행 비용보다 커지면 단일 기준 지역이 더 적합합니다.
rules_apple을 올리면 기존 캐시를 바로 지워야 합니까?
무조건 지우는 것이 아니라 입력과 도구 체인 변경 범위를 먼저 확인해야 합니다. 다만 rules_apple, rules_swift, Xcode, SDK 또는 생성 규칙이 결과에 영향을 주었다면 이전 객체와 새 객체가 섞이지 않도록 별도 키나 저장 영역을 검토해야 합니다. 공식 변경 기록을 확인하고 동일 산출물 검증을 통과한 뒤 생산 캐시를 전환해야 합니다.
서명 파이프라인에도 읽기 전용 캐시를 적용할 수 있습니까?
민감한 서명 대상은 일반 컴파일 대상과 분리해서 판단해야 합니다. 읽기 전용이라도 캐시 산출물이 실제 서명 입력과 일치하는지, 인증 정보가 로그나 객체에 노출되지 않는지 확인해야 합니다. 검증 자료가 부족하면 서명과 배포 동작은 캐시에서 제외하고, 독립된 맥 노드에서 재현하는 편이 안전합니다.
캐시 시험이 실패하면 바로 맥을 추가해야 합니까?
실패 원인이 재현성인지 네트워크인지 보안 정책인지 먼저 분리해야 합니다. 도구 체인과 경로 차이로 적중하지 않았다면 환경을 고친 뒤 재시험할 수 있습니다. 그러나 캐시를 꺼도 대기열이 길고 서명이나 시뮬레이터 작업이 병목으로 남는다면, 추가 캐시보다 맥 노드 용량을 늘리는 결정이 더 직접적인 해결책입니다.