2026년 9월 8일 Tuist 변경 기록에는 Xcode Cache의 전송 과정에서 청크 재사용을 다루는 변경이 기록되어 있습니다. 해당 변경 기록은 전송 작업을 줄이는 방식은 설명하지만, 모든 프로젝트의 전체 빌드 시간이 같은 비율로 줄어든다고 보장하지는 않습니다.
반복 컴파일이 가장 큰 비용이면 Tuist Xcode Cache를 먼저 시험합니다.
원격 맥 대기열, 시뮬레이터, 서명이 병목이면 캐시보다 노드 분리 또는 증설을 먼저 진행합니다. 두 문제가 함께 있으면 두 경로를 병행합니다.
이 글은 큰 iOS·macOS 프로젝트를 반복 빌드하는 개발자, 자체 맥 CI를 운영하는 데브옵스 엔지니어, 빌드 인프라의 구매·임대·최적화를 결정하는 플랫폼 담당자를 위한 글입니다. 단순히 캐시를 켜는 방법이 아니라, 어떤 시간을 줄여야 하는지 증거로 구분하는 데 초점을 둡니다.
SECTION 01먼저 분리해야 하는 다섯 가지 시간
Xcode 빌드가 느리다는 말만으로는 해결책을 고를 수 없습니다. 최소한 다음 시간을 별도로 기록해야 합니다.
- 실제 소스와 의존성을 컴파일하는 시간
- 캐시를 조회하고 결과물을 업로드하거나 다운로드하는 시간
- 실행 가능한 원격 맥을 기다리는 시간
- 시뮬레이터와 UI 테스트가 실행되는 시간
- 테스트 결과나 아카이브를 받아 배포 가능한 상태가 될 때까지의 시간
Apple은 증분 빌드 속도 개선 문서에서 Xcode의 빌드 타이밍 정보를 사용해 느린 작업을 찾도록 안내합니다. 먼저 Xcode의 Build Timing Summary를 켜고, 같은 커밋을 깨끗한 환경과 반복 환경에서 각각 실행합니다.
여기서 차가운 빌드와 증분 빌드를 섞으면 안 됩니다. 의존성 해결이나 셸 스크립트가 오래 걸리는 프로젝트라면 컴파일 캐시를 켜도 총시간이 크게 바뀌지 않을 수 있습니다.
Tuist Xcode Cache는 어떤 빌드에 효과가 있나요?
주된 대상은 다시 생성할 수 있는 Xcode 컴파일 산출물입니다. 같은 소스, 컴파일 옵션, 대상 아키텍처, 도구 체인과 같은 입력이 유지될 때 이전 결과를 재사용할 여지가 생깁니다. 반대로 프로젝트 파일이나 빌드 설정이 자주 바뀌거나, 실행 환경의 경로와 아키텍처가 달라지면 캐시 입력이 달라질 수 있습니다.
따라서 다음 조건이면 캐시 시험으로 들어갈 수 있습니다.
- 같은 의존성과 소스를 반복해서 빌드합니다.
- Build Timing Summary에서 컴파일 작업이 큰 비중을 차지합니다.
- 개발자와 CI의 도구 체인 및 대상 아키텍처를 일정하게 유지할 수 있습니다.
- 캐시 적중과 실패 상태를 로그에서 구분할 수 있습니다.
이 조건이 충족되지 않으면 캐시 설정부터 늘리기보다 프로젝트 설정, 스크립트, 의존성 해결 단계를 먼저 고쳐야 합니다.
SECTION 02적중하지 않는 캐시의 원인
Tuist 공식 Xcode Cache 안내서는 환경 요구 사항, CI 설정, 업로드 전략과 캐시 상태 확인 방법을 설명합니다. 여기서 중요한 점은 캐시를 활성화한 설정과 실제로 캐시를 사용한 빌드를 같은 것으로 보면 안 된다는 사실입니다.
다음 순서로 확인합니다.
- 같은 커밋을 깨끗한 CI 작업 공간에서 실행합니다.
- 첫 실행에서 생성된 결과물이 업로드 대상에 포함되는지 확인합니다.
- 동일한 도구 체인과 아키텍처로 두 번째 실행을 합니다.
- 로그에서 로컬 적중, 원격 적중, 미적중을 구분합니다.
- 적중 뒤에도 컴파일 시간이 줄었는지 Build Timing Summary로 대조합니다.
- 캐시 조회 시간과 다운로드 시간을 별도로 기록합니다.
캐시 적중률이 높지 않다고 해서 즉시 폐기할 필요는 없습니다. 먼저 적중이 실패하는 입력을 찾아야 합니다. 브랜치마다 다른 컴파일 플래그를 사용하거나, CI마다 SDK·아키텍처·환경 경로가 다르면 캐시 키가 달라질 수 있습니다.
캐시 적중률이 낮으면 계속 써야 하나요?
적중률 하나만으로 결정하지 않습니다. 적중된 작업에서 절약된 컴파일 시간과 캐시 조회·전송에 걸린 시간을 비교합니다. 적중이 적더라도 큰 모듈이 안정적으로 재사용되고 전체 전달 시간이 짧아지면 유지할 수 있습니다. 반대로 적중은 발생하지만 작은 산출물만 재사용되고 전송 비용이 반복되면 업로드 범위를 줄이거나 캐시를 중단하는 편이 낫습니다.
주의: 일반적으로 통용되는 캐시 적중률 기준을 이 프로젝트에 그대로 적용하면 안 됩니다. Tuist 공식 문서가 설명하는 상태와 당신의 동일 커밋 측정 결과를 함께 봐야 합니다.
SECTION 03전송 비용과 네트워크 경로
캐시를 사용하면 CPU 컴파일이 줄어들 수 있지만, 작업이 조회·업로드·다운로드로 이동할 수 있습니다. 캐시 서비스와 원격 맥의 지역이 멀거나, 결과물이 크거나, 여러 작업이 동시에 업로드되면 실제 전달 시간은 늘어날 수 있습니다.
Tuist의 청크 재사용 변경 기록은 이전에 전송한 일부 조각을 다시 활용하는 동작을 설명합니다. 이는 매번 같은 데이터를 전부 보내야 하는 작업을 줄이는 방향이지만, 프로젝트의 결과물 크기와 변경 범위가 다르면 효과도 달라집니다.
다음 증거를 모읍니다.
- 캐시 조회 시작부터 결과 수신까지 걸린 시간
- 업로드와 다운로드가 각각 차지하는 시간
- 전체 산출물 크기와 재사용된 조각의 비중
- 원격 맥과 캐시 서비스 사이의 네트워크 경로
- 캐시를 끈 동일 커밋의 컴파일 시간
판단 기준은 단순합니다. 캐시를 켠 뒤 컴파일 시간은 줄었지만 전송 시간이 같은 폭으로 늘었다면 업로드 범위를 제한하거나 더 가까운 위치의 실행·캐시 구성을 검토합니다. 두 시간의 합이 계속 줄고 로그의 적중 상태가 안정적이면 캐시를 유지합니다. 전송이 불규칙하고 실패 복구까지 길어지면 캐시를 기본 경로에서 제외하고 별도 시험 경로로 내립니다.
SECTION 04원격 맥 대기열과 실행 환경
원격 맥 CI의 대기와 컴파일 지연은 어떻게 구분하나요?
CI 작업의 시작 시각, 실행 노드 배정 시각, 실제 빌드 시작 시각을 나눠 기록합니다. 작업 생성부터 노드 배정 전까지가 길면 대기열 문제입니다. 노드를 받은 뒤 컴파일 단계가 길면 실행 환경이나 프로젝트 문제가 될 가능성이 큽니다.
자체 호스티드 러너의 동작 규칙은 작업과 호환되는 라벨을 가진 온라인 러너가 필요하다는 점을 설명합니다. 즉, 캐시는 사용 중인 러너를 새 작업에 동시에 배정하지 않습니다. 캐시가 컴파일 일부를 줄여도, 모든 러너가 점유된 상태라면 새 작업의 대기 자체는 사라지지 않습니다.
이때 작업을 다음처럼 분리하면 원인이 선명해집니다.
- 풀 리퀘스트 빌드: 빠른 피드백과 짧은 대기 우선
- 정기 작업: 긴 테스트와 의존성 검증을 별도 큐로 분리
- 배포 작업: 서명과 아카이브를 안정적인 전용 환경에서 실행
대기 시간이 반복되고 온라인 러너가 부족하다면 캐시 최적화보다 원격 맥 노드 추가가 먼저입니다. 반대로 대기열은 짧고 한 노드 안의 컴파일만 길다면 기존 노드에서 캐시를 검증하는 편이 비용과 변경 범위가 작습니다.
SECTION 05UI 테스트와 서명 작업의 경계
Tuist Cache가 빌드 산출물을 재사용한다고 해도 앱을 실제로 실행해야 하는 단계까지 자동으로 빨라지는 것은 아닙니다. Apple의 시뮬레이터 및 실제 기기 실행 안내는 앱 실행에 별도의 시뮬레이터 또는 기기 환경이 필요함을 보여줍니다.
UI 테스트는 다음 환경을 실제로 사용합니다.
- 지정된 시뮬레이터 런타임
- 그래픽 세션과 앱 실행 권한
- 테스트 데이터 및 네트워크 상태
- 테스트 대상과 호환되는 아키텍처
아카이브와 서명도 별도 문제입니다. 인증서, 프로비저닝 프로파일, 키체인 접근 권한이 맞지 않으면 컴파일 산출물이 재사용되어도 배포 작업은 실패할 수 있습니다. Apple의 아카이브 문제 해결 안내는 이 경계를 확인할 때 참고할 수 있습니다.
Tuist Cache가 UI 테스트와 서명 작업도 빠르게 하나요?
직접적인 대체 수단으로 보기는 어렵습니다. 캐시는 재사용 가능한 컴파일 결과를 줄이는 도구이고, UI 테스트 실행과 코드 서명은 실제 실행 환경과 민감한 자격 증명을 요구합니다. 따라서 빌드 풀, 테스트 풀, 배포 풀을 분리하고 각 풀에서 캐시 효과를 따로 측정해야 합니다.
운영 경험: 캐시를 켠 뒤에도 긴 작업이 계속되면 캐시 설정을 반복해서 바꾸기보다, 그 작업이 컴파일인지 시뮬레이터 실행인지 서명인지 먼저 분류해야 합니다.
SECTION 06대조 실행과 중단 조건
아래 절차는 캐시, 원격 맥 증설, 이중 운영을 비교하기 위한 최소 실행 순서입니다.
- 비교할 커밋을 하나 고정합니다.
- Xcode 버전, SDK, 대상 아키텍처, 의존성 상태를 동일하게 맞춥니다.
- 캐시를 끈 깨끗한 실행에서 컴파일·전송·대기·테스트 시간을 기록합니다.
- 같은 조건에서 Tuist Xcode Cache를 켜고 원격 적중과 미적중 상태를 기록합니다.
- 동일한 작업을 다른 시간대에도 반복해 대기열 변동을 분리합니다.
- UI 테스트와 아카이브·서명 작업은 컴파일 결과와 별도 구간으로 기록합니다.
- 결과를 기준으로 유지, 확장, 중단 중 하나를 선택하고 되돌릴 설정과 로그 위치를 남깁니다.
선택 기준
- 캐시 유지
- [ ] 반복 컴파일이 전체 시간의 주요 원인으로 확인되었습니다.
- [ ] 동일한 입력에서 원격 적중이 재현됩니다.
- [ ] 전송 시간을 포함해 유효 전달 시간이 줄었습니다.
-
[ ] 대기열이 현재 팀의 피드백 요구를 넘지 않습니다.
-
원격 맥 노드 추가 또는 풀 분리
- [ ] 노드 배정 전 대기 시간이 반복됩니다.
- [ ] UI 테스트나 아카이브가 컴파일보다 오래 걸립니다.
- [ ] 서명 자격 증명이나 그래픽 세션을 전용 환경에서 관리해야 합니다.
-
[ ] 기존 러너가 작업 중일 때 새 작업이 계속 대기합니다.
-
캐시와 증설의 이중 운영
- [ ] 반복 컴파일과 노드 대기가 모두 확인되었습니다.
- [ ] 캐시를 적용해도 테스트·배포 큐가 남습니다.
- [ ] 풀 리퀘스트와 배포 작업을 서로 다른 노드 풀로 보낼 수 있습니다.
- [ ] 캐시 실패 시 캐시를 끄고 기존 빌드로 돌아갈 수 있습니다.
캐시 입력이 계속 흔들리면 우선 프로젝트 재현성을 고칩니다. 대조 실행에서 유효 전달 시간이 줄지 않으면 캐시를 기본 경로에서 제거합니다. 반대로 캐시 효과는 확인됐지만 대기열이 길다면 캐시를 버리지 말고 원격 맥 노드를 추가하는 방식이 안전합니다.
SECTION 07원격 맥을 선택할 때의 운영 판단
현재 구성이 개인 맥이나 공유 러너 한 대에 의존한다면, 대기열과 재시작 복구가 취약점이 됩니다. 물리 장비를 직접 구매하면 장기적으로 안정적인 전용 환경을 만들 수 있지만, 초기 구매 비용과 유지보수, 장애 시 교체 시간을 함께 부담해야 합니다. 리눅스 클라우드만으로 대체하는 방식은 macOS 전용 Xcode 도구 체인, 시뮬레이터, 서명 환경을 해결하지 못합니다.
반면 MACNOX의 원격 맥은 실제 macOS 환경에 SSH, VNC 또는 웹 제어 방식으로 접근하는 선택지입니다. 임시 빌드 풀이나 테스트 분리 노드가 필요하다면 MACNOX의 원격 맥 구성을 확인한 뒤, 당신의 도구 체인과 서명 요구 사항을 먼저 검증해야 합니다. 비용을 비교할 때는 장비 가격만 보지 말고 대기 시간, 장애 대응, 온라인 유지, 노드 분리 가능성까지 포함해야 합니다.
장기간 일정한 부하가 계속되고 물리 장치나 전용 보안 경계가 필요하다면 직접 보유한 Mac이 더 적합할 수 있습니다. 반대로 릴리스 기간의 임시 확장, 프로젝트별 격리, 추가 Mac CI 노드가 필요하다면 MACNOX의 이용 조건과 요금을 확인하면서 먼저 짧은 대조 실행을 진행하는 편이 합리적입니다.
결국 Tuist Xcode Cache는 긴 컴파일을 줄이는 도구이고, 원격 맥 증설은 실행 가능 노드와 대기열을 해결하는 방법입니다. 둘을 같은 문제의 해법으로 취급하지 말고, 먼저 시간 구간을 분리해 측정하십시오. 결과가 대기·시뮬레이터·배포 작업에 치우친다면 MACNOX에서 원격 맥 노드 구성을 검토하고, 캐시를 유지할지 추가 노드를 둘지 중단 조건과 함께 결정하면 됩니다.