Xcode 27 컴파일 느려짐: 2026 원격 Mac 점검 가이드

Xcode 27 컴파일 느려짐이 보이면 전체 캐시를 지우거나 하드웨어를 바로 바꾸지 말고, 냉간 빌드와 증분 빌드의 Build Timing Summary를 먼저 기록해야 합니다. 같은 프로젝트와 같은 노드에서 캐시, 의존성 스크립트, 색인, 디스크와 메모리를 차례로 분리하면 수정할 문제인지 도구를 되돌릴 문제인지 판단할 수 있습니다.

이 글은 Xcode 27로 바꾼 뒤 로컬 또는 원격 빌드 시간이 달라진 애플 플랫폼 개발자를 위한 내용입니다. 장시간 켜 둔 원격 Mac을 관리하거나, 베타 도구 체인을 생산 환경에 넣을지 결정해야 하는 데브옵스와 릴리스 담당자도 대상입니다.

마지막 업데이트: 2026년 8월 24일. Xcode 27의 베타 상태와 알려진 문제는 공식 Xcode 출시 기록에서 확인한 내용을 기준으로 했습니다. 베타가 이후 후보 버전이나 정식 버전으로 바뀌면 같은 절차로 다시 검증해야 합니다.

먼저 빌드 타이밍에서 느린 구간을 분리합니다

“빌드가 느리다”는 말만으로는 원인을 찾을 수 없습니다. 처음 실행하는 냉간 빌드, 코드를 조금 고친 뒤의 증분 빌드, 보관 빌드, 테스트, 편집기 색인은 서로 다른 작업입니다. 각각의 결과를 한데 섞으면 캐시 문제를 노드 성능 문제로 잘못 판단하게 됩니다.

Xcode의 빌드 메뉴에서 타이밍 요약을 켜거나, 명령줄에서 xcodebuild -showBuildTimingSummary를 사용해 단계별 시간을 남기십시오. Apple은 증분 빌드 속도를 확인할 때 작업별 측정값을 비교하도록 안내합니다. 자세한 측정 방식은 증분 빌드 시간 측정 공식 안내에서 확인할 수 있습니다.

프로젝트 커밋, 구성, 대상 플랫폼, 스킴을 고정한 뒤 안정 버전 도구 체인의 기준값과 비교하십시오. 한 번의 결과보다 같은 조건의 반복 결과가 중요합니다. Xcode 27 베타에서만 재현된다면 생산 노드의 안정 버전을 유지하고 별도 검증 노드에서 확인하는 편이 안전합니다.

왜 수정할 때마다 전체 컴파일처럼 보일까요?

Xcode 27 컴파일 느려짐이 코드 수정 직후마다 나타난다면 증분 빌드의 입력이 계속 바뀌거나, 의존성 그래프가 매번 다시 계산되는지부터 확인해야 합니다. DerivedData 폴더의 크기만 보고 판단하지 말고 실제 로그에서 수정하지 않은 대상이 다시 컴파일되는지 확인하십시오.

다음 항목을 순서대로 점검하십시오.

• 타깃 의존성에 불필요한 연결이 생겼는지 확인합니다.
• 조건부 설정이 구성마다 다른 입력을 만들고 있는지 비교합니다.
• 빌드 스크립트가 생성 파일을 입력 또는 출력으로 선언했는지 확인합니다.
• DerivedData 경로가 여러 작업에서 공유되어 서로 덮어쓰는지 살핍니다.
• 명시적 모듈 의존성이 필요한 프로젝트인지 진단합니다. 관련 기준은 빌드 시스템과 타깃 의존성 공식 문서와 명시적 모듈 의존성 진단 안내에 정리되어 있습니다.

DerivedData를 지우면 해결될까요?

캐시 손상이 로그와 재현 결과로 확인된 경우에만 해당 프로젝트의 DerivedData를 백업한 뒤 지우십시오. 삭제 후 첫 빌드는 새 모듈과 중간 파일을 다시 만들기 때문에 더 느릴 수 있습니다. 따라서 삭제 직후 한 번의 결과만 보고 개선됐다고 결론 내리면 안 됩니다.

캐시를 정리한 뒤에는 같은 커밋으로 냉간 빌드를 기록하고, 이어서 변경 폭이 작은 증분 빌드를 연속 실행하십시오. 증분 빌드가 다시 전체 컴파일처럼 동작한다면 캐시 삭제가 아니라 입력 파일, 의존성 또는 스크립트 설정이 원인일 가능성이 큽니다.

의존성과 스크립트가 기다림을 만들고 있나요?

Swift Package나 다른 의존성이 빌드마다 다시 해석되거나 내려받아지는지 확인하십시오. 원격 Mac에서는 코드 저장소나 산출물 저장소와의 네트워크 대기도 컴파일 시간처럼 보일 수 있습니다. 처음 실행한 로그와 후속 실행 로그에서 의존성 준비 단계가 반복되는지 비교해야 합니다.

Run Script Phase가 입력과 출력 없이 등록되어 있으면 변경 사항이 없어도 매번 실행될 수 있습니다. 스크립트가 만드는 파일을 출력으로 선언하고, 읽는 파일을 입력으로 선언한 뒤 연속 증분 빌드에서 실제로 건너뛰는지 검증하십시오. Apple의 빌드 중 사용자 지정 스크립트 설정 안내는 이 입력과 출력 구성을 설명합니다.

의존성 캐시를 모든 작업이 공유하도록 만드는 것도 조심해야 합니다. 서로 다른 커밋이나 도구 버전이 같은 경로를 사용하면 재사용보다 재생성이 늘어날 수 있습니다. 지속적 통합 환경의 패키지 처리 기준은 Swift Package와 지속적 통합 공식 안내에서 확인할 수 있습니다.

색인과 노드 자원이 빌드를 방해하는지 어떻게 구분할까요?

원격 Mac에서 색인이 끝나지 않는다면 컴파일 시스템의 결함으로 단정하지 마십시오. Xcode 색인, 소스 분석, 미리보기, 시뮬레이터가 동시에 실행되면 같은 CPU와 메모리, 디스크 입출력을 공유합니다. 그래픽 세션에서만 느리고 순수 명령줄 빌드는 정상이라면 프로젝트 빌드보다 편집기 부하를 먼저 의심할 수 있습니다.

다음처럼 두 번 나누어 재현하십시오.

1. 그래픽 세션에서 색인과 미리보기를 실행하지 않은 상태로 빌드합니다.
2. 같은 커밋과 구성으로 명령줄 빌드를 실행합니다.
3. 두 결과의 타이밍 요약과 자원 상태를 나란히 기록합니다.
4. 색인 작업이 필요한 경우, 빌드가 끝난 뒤 다시 켜고 디스크 입출력 변화를 관찰합니다.
5. 코드 탐색과 자동 완성이 실제로 필요한지 확인한 뒤 불필요한 미리보기와 시뮬레이터만 격리합니다.

색인을 장기간 꺼서 문제를 숨기는 방식은 권하지 않습니다. 코드 탐색이 망가진 채로 개발이 진행되고, 다음 도구 버전에서 같은 문제가 다시 나타날 수 있기 때문입니다.

원격 Mac 설정 부족인지 프로젝트 문제인지 판단하는 기준

단일 작업과 동시 작업의 결과를 비교하면 노드 병목을 구분하기 쉽습니다. 프로젝트를 바꾸지 않았는데 동시 작업에서만 메모리 압력과 디스크 대기가 커지면 자원 경쟁 가능성이 높습니다. 반대로 한 작업만 실행해도 특정 스크립트나 대상을 반복해서 처리한다면 프로젝트 구성을 먼저 수정해야 합니다.

활동 모니터에서는 메모리 압력과 교환 활동을 함께 보십시오. 메모리 압력과 교환 활동을 확인하는 공식 안내는 두 지표를 통해 메모리 부족 여부를 판단하는 방법을 설명합니다. 단순히 여유 저장 공간이 적다는 이유만으로 메모리 부족이라고 결론 내리면 안 됩니다.

단계별 복구와 재검증 순서

아래 목록은 캐시 삭제나 노드 확장을 가장 뒤로 미루는 순서입니다.

• [ ] 같은 커밋, 스킴, 대상 플랫폼, 구성으로 냉간 빌드와 증분 빌드를 따로 기록합니다.
• [ ] Build Timing Summary에서 컴파일, 링크, 의존성 준비, 스크립트 단계를 분리합니다.
• [ ] 수정하지 않은 대상이 다시 빌드되는지 로그에서 확인합니다.
• [ ] 반복 실행되는 의존성 해석과 다운로드가 있는지 첫 실행과 후속 실행을 비교합니다.
• [ ] Run Script Phase에 입력과 출력 파일이 정확히 선언되어 있는지 확인합니다.
• [ ] 그래픽 세션의 색인, 미리보기, 시뮬레이터를 격리한 뒤 명령줄 빌드와 비교합니다.
• [ ] 메모리 압력, 교환 활동, 디스크 입출력, 작업 디렉터리 공유 상태를 기록합니다.
• [ ] 캐시 손상이 확인된 프로젝트만 선택적으로 정리하고 냉간 및 증분 빌드를 다시 측정합니다.
• [ ] 단일 작업과 동시 작업을 비교해 노드 확장이 필요한지 확인합니다.
• [ ] Xcode 27 베타에서만 문제가 반복되면 안정 버전 생산 노드와 검증 노드를 분리합니다.
• [ ] 재시작 뒤에도 같은 조건으로 반복해 일시적인 자원 누적과 지속적인 회귀를 구분합니다.

판정은 다음처럼 단순화할 수 있습니다. 특정 프로젝트 단계가 원인이면 프로젝트를 고칩니다. Xcode 27 베타에서만 같은 프로젝트가 악화되면 생산 환경은 Xcode 26.6으로 유지하고 격리 검증을 계속합니다. 빌드 단계는 정상인데 노드에서 지속적으로 메모리 압력이나 디스크 포화가 재현되면 그때 원격 Mac 확장을 검토합니다.

현재 사용 중인 방식이 개인 장비 한 대라면 도구 버전 두 개를 격리하기 어렵고, 장시간 CI 작업이 개발 세션과 자원을 나눠 쓰며, 재현용 로그와 깨끗한 기준 환경을 유지하기도 어렵습니다. 반대로 여러 클라우드 서버를 조합하면 macOS 전용 도구 체인을 직접 관리하기 어렵고, 네트워크 대기와 접근 권한 관리가 추가됩니다. 이런 조건에서 생산 버전과 Xcode 27 검증 버전을 분리해야 한다면, KVMFLUX 원격 Mac 사용 사례를 참고해 독립 환경에서 기준 빌드를 복제하는 편이 더 명확합니다.

장기적으로 항상 같은 무거운 작업을 실행하거나 물리 장치 연결이 필수라면 실물 Mac을 직접 보유하는 편이 맞을 수 있습니다. 그러나 일정 기간만 베타 검증을 진행하거나, 기존 노드와 별도로 재현 환경을 마련해야 한다면 KVMFLUX 요금과 이용 방식을 비교해 볼 만합니다. 먼저 같은 프로젝트의 타이밍 요약과 자원 기록을 확보한 뒤, 임시 원격 Mac이 실제 병목을 분리해 주는지 확인하고 선택하십시오.

더 읽어보기

• 원격 맥에서 엑스코드 시아이 환경을 구성하고 캐시와 동시성을 조정하는 방법
• 엑스코드 이십칠의 설치와 개발 도구 경로를 점검해 빌드 환경을 검증하는 절차