Xcode 26 Compilation Caching을 켤 가치가 있을까? 2026 CI 판단

Xcode 26 Compilation Caching은 먼저 캐시 적중을 확인한 뒤, 지속형 원격 맥 노드에서만 단계적으로 켜는 편이 안전합니다. 입력이 반복되고 클린 빌드가 잦으면 테스트 가치가 높지만, 매번 폐기되는 러너나 빌드 인자가 자주 바뀌는 환경에서는 적용을 미루는 것이 맞습니다.

이 글은 다음 독자를 위한 판단용 runbook입니다.

• 브랜치를 자주 바꾸거나 Clean Build를 반복하는 Apple 플랫폼 개발자
• 자체 호스팅 원격 맥 러너의 빌드 시간과 저장 공간을 관리하는 데브옵스 엔지니어
• 공유 CI 노드의 재현성, 배포 위험, 용량 계획을 책임지는 플랫폼 담당자

마지막 업데이트: 2026년 9월 3일. Xcode 26 Release Notes, 공식 시스템 요구 사항, Build Settings Reference를 기준으로 내용을 다시 확인했습니다.

Xcode 26 Compilation Caching과 일반 캐시는 같은 기능이 아닙니다

Xcode 26에는 선택적으로 사용할 수 있는 Compilation Caching이 추가되었습니다. 이는 컴파일 결과를 다시 활용하는 기능이지, 모든 빌드 단계를 자동으로 줄이는 통합 캐시가 아닙니다. Xcode 26 Release Notes의 관련 변경 사항과 공식 빌드 설정 문서를 기준으로 설정과 진단 항목을 확인해야 합니다.

다음 메커니즘은 서로 분리해서 기록해야 합니다.

• Compilation Caching: 컴파일 결과 재사용을 판단하는 기능입니다.
• DerivedData: 프로젝트 중간 산출물과 인덱스가 저장되는 작업 영역입니다.
• 의존성 다운로드 캐시: 패키지나 외부 의존성을 다시 받지 않도록 보관합니다.
• 증분 빌드: 변경되지 않은 입력을 바탕으로 일부 작업을 생략합니다.

따라서 전체 파이프라인이 빨라졌다는 사실만으로 Compilation Caching이 적중했다고 결론 내리면 안 됩니다. 의존성 다운로드가 줄었거나 DerivedData가 남아 있었을 가능성도 있습니다.

작업 부하별 초기 판단

브랜치마다 소스와 컴파일러 입력이 크게 달라지면 이전 결과를 재사용하기 어렵습니다. 반대로 같은 프로젝트를 반복 빌드하고, 입력과 빌드 인자가 일정하며, 노드의 작업 영역을 유지할 수 있다면 검증 우선순위가 올라갑니다.

여기서 “가치가 있다”는 말은 캐시 디렉터리가 생긴다는 뜻이 아닙니다. 성공한 빌드 하나를 끝내는 데 걸린 시간과 캐시를 유지하는 운영 비용을 함께 봐야 합니다.

xcodebuild 로그로 적중 여부를 분리해서 확인합니다

xcodebuild를 사용한 CI에서 컴파일 캐시 적중은 어떻게 확인합니까?

파이프라인의 총 소요 시간만 보지 말고, 진단 설정과 빌드 로그에서 컴파일 단계의 재사용 흔적을 확인해야 합니다. 먼저 동일한 커밋, 동일한 Scheme, 동일한 빌드 인자, 동일한 노드 조건으로 기준 빌드를 남깁니다. 그다음 같은 입력으로 다시 실행하고, 마지막으로 과거 브랜치로 돌아가 반복합니다.

세 결과는 서로 다른 질문에 답합니다.

• 첫 빌드: 캐시가 없는 상태의 기준선입니다.
• 같은 입력의 재실행: 동일한 컴파일 입력에서 재사용이 발생하는지 확인합니다.
• 과거 브랜치 재실행: 공통 입력과 브랜치별 입력이 어떻게 달라지는지 살핍니다.

Apple은 증분 빌드 속도를 분석할 때 빌드 타이밍과 단계별 로그를 분리해 보도록 안내합니다. 증분 빌드 시간 분석 문서를 참고해 Build Timing Summary를 수집하십시오.

Build Timing Summary는 전체 파이프라인 시간과 같은 지표입니까?

아닙니다. Build Timing Summary는 빌드 내부 단계의 시간을 보는 자료입니다. 서명, 테스트 실행, 의존성 다운로드, 스크립트, 아카이브 업로드가 오래 걸리면 컴파일 단계가 줄어도 전체 작업 시간은 거의 그대로일 수 있습니다.

다음 항목을 같은 형식으로 저장하면 비교가 쉬워집니다.

• 커밋 식별자와 브랜치
• Scheme과 빌드 구성
• SDK 및 Xcode 실행 환경
• 컴파일 단계 시간
• 링크, 서명, 테스트, 스크립트 시간
• 캐시 관련 진단 메시지
• 작업 전후 저장 공간

진단 메시지가 없거나 실행마다 입력 조건이 다르면 “미적중”이라고 단정하지 말고 재현 조건부터 고정해야 합니다. 기능과 설정의 세부 사항은 Build Settings Reference에서 현재 문서와 대조하십시오.

Clean Build와 반복 빌드의 효과를 따로 측정합니다

Xcode 26 Compilation Caching은 Clean Build에도 유용합니까?

가능성은 있지만 항상 그렇지는 않습니다. Clean Build가 로컬 중간 산출물을 지우더라도 Compilation Caching이 별도로 보존되고 입력이 변하지 않았다면 재사용 여지가 있습니다. 그러나 작업 영역 전체를 초기화하거나 러너를 폐기하면 캐시도 함께 사라질 수 있습니다.

Clean Build 비교에서는 다음 결과를 따로 기록하십시오.

• 캐시를 켠 상태의 최초 Clean Build
• 같은 프로젝트와 입력으로 반복한 Clean Build
• 캐시를 끈 상태의 Clean Build
• 작업 영역을 완전히 초기화한 뒤의 빌드

캐시를 켠 결과만 빠르게 나왔다면 충분하지 않습니다. 캐시를 끈 기준선과 같은 노드에서 비교해야 하며, 테스트와 아카이브까지 포함할지 여부도 사전에 고정해야 합니다. Apple의 성능 테스트 안내처럼 조건을 통제하고 결과를 기록하는 방식이 필요합니다. Apple 성능 테스트 작성 안내도 함께 확인하십시오.

다중 브랜치 iOS 프로젝트는 바로 캐시를 켜도 됩니까?

공통 모듈과 생성 입력이 반복되고 노드가 작업 영역을 유지한다면 제한된 브랜치에서 먼저 시험할 수 있습니다. 반대로 브랜치마다 설정 파일, 생성 코드, 패키지 버전, 빌드 플래그가 크게 다르면 적중률보다 오염 가능성을 먼저 점검해야 합니다.

다음 조건을 모두 만족할 때만 적용 범위를 넓히십시오.

• 동일한 커밋의 반복 실행에서 컴파일 단계가 일관되게 줄어듭니다.
• 캐시를 끈 기준선보다 전체 작업 시간이 실제로 개선됩니다.
• 완전한 새 복제본에서도 빌드가 성공합니다.
• 캐시를 삭제한 상태의 빌드와 배포 결과가 일치합니다.
• 특정 브랜치의 산출물이 다른 브랜치에 영향을 주지 않습니다.

저장 공간과 러너 수명은 캐시의 손익을 바꿉니다

자체 호스팅 맥 러너를 재시작하면 컴파일 캐시가 남습니까?

재시작만으로 남는다고 단정할 수 없습니다. 캐시가 어느 경로에 저장되는지, 재시작 과정에서 작업 영역을 지우는지, 노드가 임시 디스크를 사용하는지에 따라 결과가 달라집니다. 운영팀은 “재시작 전후 캐시 상태”를 별도 시험으로 확인해야 합니다.

지속형 원격 맥은 캐시를 보존할 기회가 있지만, 다음 비용이 따라옵니다.

• 캐시 증가에 따른 디스크 압박
• 여러 팀이 공유할 때의 계정과 작업 영역 분리
• 오래된 브랜치와 실패 작업의 잔여 파일
• 정리 뒤 재빌드해야 하는 시간
• 디스크 부족으로 인한 예기치 않은 작업 실패

반대로 매번 새로 만드는 러너는 오염 위험이 작습니다. 대신 캐시가 매번 사라지므로 Compilation Caching의 지속 효과를 기대하기 어렵습니다. 즉, 저장 공간이 넉넉한지보다 캐시를 보존하는 비용이 빌드 절감 시간보다 낮은지가 핵심입니다.

Compilation Caching이 디스크를 차지하면 어떻게 정리합니까?

먼저 작업을 중지하고, 현재 캐시 경로와 DerivedData 경로를 구분해 기록하십시오. 그 후 보존 기간, 마지막 사용 시각, 브랜치 또는 계정별 소유권을 기준으로 오래된 항목부터 지우는 정책을 정합니다. 무조건 전체 삭제하면 다음 빌드가 기준선으로 돌아가므로, 정리 전후의 Build Timing Summary를 남겨야 합니다.

경고: Compilation Caching, DerivedData, 의존성 캐시를 한 번에 삭제하면 무엇이 성능에 기여했는지 판별할 수 없습니다. 한 번에 하나의 저장 영역만 정리하고 동일한 커밋으로 다시 측정하십시오.

시간 절감보다 재현성과 배포 안전성을 먼저 봅니다

개발 브랜치의 반복 빌드가 빨라져도 릴리스 아카이브를 같은 방식으로 운영해야 한다는 뜻은 아닙니다. 캐시가 숨겨진 파일 의존성, 잘못된 생성 스크립트, 작업 영역에만 존재하는 설정을 가릴 수 있기 때문입니다.

회색 배포에는 다음 검증을 포함하십시오.

• 새 복제본에서 캐시 없이 빌드
• 기존 작업 영역에서 캐시를 켠 빌드
• 캐시와 작업 영역을 지운 뒤의 재빌드
• 릴리스 구성의 아카이브
• 테스트 및 서명 단계
• 실패 시 캐시를 끄고 다시 실행하는 경로

릴리스 작업에는 독립적인 기준선을 남기는 편이 안전합니다. 개발 브랜치에서 얻은 개선만으로 배포 파이프라인 전체를 전환하지 마십시오. Xcode 26.6은 공식 시스템 요구 사항 페이지에 안정 버전으로 표시되어 있지만, Xcode 27 beta 4는 테스트 버전으로 구분되어 있습니다. 현재 Xcode 시스템 요구 사항을 확인하고, 테스트 버전의 동작을 Xcode 26의 결론에 섞지 마십시오.

운영 전환 여부를 체크리스트로 결정합니다

다음 항목은 설정을 켜는 순서가 아니라, 운영 판단을 위한 증거 수집 목록입니다.

• [ ] 동일한 커밋, Scheme, 빌드 인자, SDK, 노드 조건을 고정했습니다.
• [ ] 캐시를 끈 기준 빌드와 최초 빌드를 모두 기록했습니다.
• [ ] 같은 입력을 반복한 뒤 진단 정보에서 캐시 참여 여부를 확인했습니다.
• [ ] Build Timing Summary에서 컴파일 단계와 나머지 단계를 분리했습니다.
• [ ] Clean Build와 일반 반복 빌드를 별도로 비교했습니다.
• [ ] 러너 재시작 후 캐시 보존 여부를 확인했습니다.
• [ ] 캐시, DerivedData, 의존성 다운로드 캐시를 구분해 정리했습니다.
• [ ] 디스크 압박과 계정별 작업 영역 격리 정책을 문서화했습니다.
• [ ] 새 복제본, 무캐시 빌드, 릴리스 아카이브를 통과시켰습니다.
• [ ] 실패 시 캐시를 끄고 재검증하는 중단 경로를 마련했습니다.

판정은 세 가지로 나누면 됩니다. 반복 입력과 안정적인 적중 증거가 있고 저장 공간 정책도 있으면 지속형 원격 맥 노드에서 회색 운영을 시작하십시오. 적중은 보이지만 전체 시간이 줄지 않거나 러너 수명이 짧으면 테스트 범위를 유지하십시오. 증거가 없거나 재현성 문제가 있으면 Compilation Caching을 끄고 기준선을 보존하십시오.

현재 매번 폐기되는 CI 러너를 사용한다면 캐시가 사라질 때마다 다시 컴파일해야 하고, 저장 공간과 작업 영역을 통제하기도 어렵습니다. 반대로 장비를 직접 운영하면 초기 구매비, 유지보수, 원격 접속 구성, 고장 시 대체 노드 확보가 모두 당신의 책임이 됩니다. 이 경우 맥 미니 렌탈과 요금 판단 기준과 실제 맥과 가상화 환경 비교를 먼저 검토하면 지속형 노드가 필요한지 판단하기 쉽습니다.

캐시를 오래 유지해야 하는데 현재 러너가 작업 영역을 매번 지우는 구조라면, 기존 환경을 억지로 튜닝하기보다 지속형 원격 맥을 별도 회색 노드로 두고 같은 프로젝트를 다시 측정하는 편이 낫습니다. 다만 물리 포트가 필요하거나 장기간 고정 부하를 계속 처리해야 한다면 직접 구매가 더 적합할 수 있습니다. 임시 테스트, 특정 기간의 빌드 용량 확보, 원격 접속이 필요한 검증 작업이라면 MacDate의 원격 맥 환경을 후보에 넣고 캐시 보존과 재시작 정책을 먼저 확인하십시오. MacDate의 한국어 맥 환경 안내에서 현재 제공 조건을 확인한 뒤, 위 체크리스트의 기준선과 비교해 결정하면 됩니다.