Xcode 26 빌드가 너무 느릴 때: 2026년 원격 맥으로 어떻게 빨라지게 할까?

Xcode 26 빌드가 너무 느릴 때: 2026년 원격 맥으로 어떻게 빨라지게 할까?

빌드 버튼을 누른 뒤 진행 표시가 오래 멈추고, 같은 코드 수정에도 Xcode 26의 결과가 매번 달라집니다.

가장 빠른 해결 순서는 빌드 기록으로 병목을 측정하고, 프로젝트의 반복 작업을 고친 뒤, 처리 장치·메모리·저장 장치가 계속 막힐 때만 원격 맥을 확장하는 것입니다.

이 글은 매일 증분 빌드를 실행하는 독립 개발자, 원격 맥에서 보관 빌드와 자동 테스트를 운영하는 유지 관리자, 장비 확장을 검토 중인 소규모 팀을 위한 글입니다. 단순히 캐시를 삭제하거나 사양표만 비교하지 않고 실제 작업 종류별로 판단합니다.

같은 “느린 빌드”를 먼저 네 가지 작업으로 나누기

Xcode 26 빌드가 너무 느릴 때 가장 먼저 할 일은 총 소요 시간 하나를 기록하는 것이 아닙니다. 다음 작업을 같은 코드 제출물과 같은 구성으로 따로 실행해야 합니다.

  • 첫 빌드: 의존성 준비와 초기 컴파일이 포함됩니다.
  • 증분 빌드: 작은 소스 변경 뒤 다시 실행합니다.
  • 보관 빌드: 배포용 구성에서 컴파일, 링크, 서명, 스크립트를 확인합니다.
  • 테스트: 앱 컴파일, 시뮬레이터 시작, 테스트 실행을 분리합니다.

빌드가 끝난 뒤 보고서에서 빌드 타이밍 요약을 확인합니다. 오래 걸린 소스 파일, 사용자 스크립트, 링크 작업을 찾아야 합니다. 자동화 환경에서는 프로젝트와 계획 이름을 자리표시자로 남겨 기록을 재현합니다.

xcodebuild \
  -workspace "<WORKSPACE_PATH>" \
  -scheme "<SCHEME_NAME>" \
  -configuration "<BUILD_CONFIGURATION>" \
  build \
  -showBuildTimingSummary

출력에는 작업별 실행 항목이 표시됩니다. 이 기능의 사용 목적은 특정 장비의 평균 성능을 단정하는 것이 아니라, 같은 입력에서 어느 작업이 반복되는지 확인하는 데 있습니다. 증분 빌드 속도 개선 문서도 먼저 측정하고 변경 사항을 비교하는 흐름을 안내합니다.

첫 번째 단계: 증분 개발에서는 프로젝트 반복 작업부터 줄이기

코드 한 줄을 바꿨는데 관련 없는 대상까지 다시 빌드된다면 하드웨어보다 대상 관계가 먼저 의심됩니다. 새 대상이 불필요한 모듈을 참조하거나, 공통 코드를 지나치게 넓게 노출하면 작은 변경의 영향 범위가 커질 수 있습니다. 대상 구성 문서를 기준으로 대상과 의존성 관계를 다시 확인합니다.

다음 항목을 빌드 타이밍 요약과 함께 점검합니다.

  • 변경하지 않은 대상이 매번 빌드되는지 확인합니다.
  • 큰 Swift 파일 하나가 여러 모듈에 공개된 선언을 과도하게 포함하는지 살핍니다.
  • 코드 생성, 리소스 변환, 린트 스크립트가 입력 파일과 무관하게 반복되는지 확인합니다.
  • 사용자 스크립트의 입력과 출력 경로가 정확히 선언되어 있는지 검토합니다.
  • 변경 전후에 같은 증분 작업을 실행해 결과를 비교합니다.

코드 구조 자체가 컴파일 시간을 늘리는 경우에는 코드 작성 방식으로 빌드 효율을 높이는 공식 안내를 참고할 수 있습니다. 중요한 점은 수정 직후 체감만 보지 않는 것입니다. 같은 제출물에서 같은 작업을 다시 실행해야 합니다.

DerivedData는 고장 난 캐시를 고칠 때만 사용하기

DerivedData는 증분 결과와 중간 산출물이 저장되는 공간입니다. 캐시가 손상되었거나 오래된 상태가 의심될 때 정리할 수 있습니다. 그러나 매번 삭제하면 다음 작업이 초기 빌드처럼 진행될 수 있습니다.

rm -rf "<DERIVED_DATA_PATH>"

이 명령은 고정된 가속 절차가 아닙니다. 삭제 전후의 첫 빌드와 증분 빌드를 따로 기록해야 합니다. 삭제 후 첫 결과만 보고 “빨라졌다”고 판단하면 기존 캐시 손실을 개선으로 착각할 수 있습니다.

주의: DerivedData 삭제는 캐시 이상을 확인하는 진단 단계입니다. 증분 빌드가 계속 느리다면 대상 관계, Swift 파일 구조, 사용자 스크립트부터 고쳐야 합니다.

두 번째 단계: 보관 빌드는 컴파일과 배포 작업을 따로 보기

디버그 실행은 빠른데 보관 빌드만 오래 걸리는 경우가 있습니다. 이때 전체 보관 시간만 기록하면 원인을 찾기 어렵습니다. 다음 작업을 별도로 나눕니다.

확인 구간 기록할 내용 잘못된 판단
의존성 준비 잠금 파일 복원, 패키지와 이진 의존성 다운로드 네트워크 지연을 컴파일 지연으로 기록
소스 컴파일 릴리스 구성의 소스 작업 디버그 결과로 릴리스 속도를 추정
링크와 기호 처리 링크, 기호 파일, 추가 대상 큰 제품을 칩 성능 하나로만 설명
배포 작업 리소스 처리, 서명, 사용자 스크립트 스크립트 반복을 하드웨어 문제로 오인

보관 빌드에는 추가 대상, 최적화 설정, 기호 처리, 서명, 업로드 전 스크립트가 들어갈 수 있습니다. 배포용 흐름은 베타와 정식 배포 안내처럼 단계별로 확인해야 합니다.

xcodebuild archive \
  -workspace "<WORKSPACE_PATH>" \
  -scheme "<SCHEME_NAME>" \
  -configuration "<RELEASE_CONFIGURATION>" \
  -archivePath "<ARCHIVE_PATH>" \
  -showBuildTimingSummary

디버그는 빠르고 릴리스만 느리다면 먼저 반복되는 스크립트와 추가 대상을 줄입니다. 그 뒤에도 처리 장치가 계속 포화되거나 메모리 압박이 나타날 때 원격 맥 구성을 검토합니다.

세 번째 단계: 새 환경에서는 의존성 복원과 컴파일을 분리하기

원격 맥, 지속적 통합 서버, 새 임대 환경의 첫 실행은 저장소 동기화와 Swift Package 다운로드를 함께 수행합니다. 이 시간은 소스 컴파일 시간과 다릅니다. 저장소에 의존성 잠금 파일이 있는지 확인하고, 실행 환경에서 동일한 파일이 사용되는지 검증합니다.

git checkout "<COMMIT_OR_BRANCH>"
xcodebuild \
  -workspace "<WORKSPACE_PATH>" \
  -scheme "<SCHEME_NAME>" \
  -resolvePackageDependencies

다음 결과를 서로 다른 문제로 기록합니다.

  • 의존성 해석 실패: 버전 조건이나 잠금 파일 문제입니다.
  • 다운로드 지연: 저장소 접근, 인증, 네트워크 문제입니다.
  • 소스 컴파일 지연: 프로젝트와 빌드 자원 문제입니다.
  • 비공개 패키지 실패: 접근 토큰과 저장소 권한을 별도로 확인해야 합니다.

지속적 통합에서 패키지를 빌드하는 방식은 Swift Package 지속적 통합 문서의 원칙과 맞춰야 합니다. 캐시는 잠금 파일과 키가 일치할 때만 복원합니다. 오래된 캐시로 현재 의존성 문제를 숨기지 않습니다.

네 번째 단계: 테스트는 병렬도보다 실패 비용까지 비교하기

테스트가 느리다고 해서 모두 Xcode 컴파일 문제는 아닙니다. 앱 빌드, 시뮬레이터 부팅, 테스트 데이터 준비, UI 테스트 실행이 서로 다른 시간을 차지할 수 있습니다. 시뮬레이터와 실제 기기 실행 안내를 기준으로 실행 대상을 고정합니다.

병렬 테스트는 동시에 사용하는 시뮬레이터와 자원을 늘립니다. 따라서 병렬 수준을 높인 결과가 항상 전체 완료 시간 단축으로 이어지지는 않습니다. 빠른 피드백용 소규모 테스트와 보관 전 전체 테스트를 분리하고, 실패 재실행 시간을 포함해 비교합니다. 테스트 구성은 피드백을 개선하는 테스트 구성 문서와 함께 점검하는 편이 안전합니다.

원격 맥 확장 여부를 가르는 기록표

원격 맥이 필요한지 판단할 때는 “컴파일이 느리다”는 느낌 대신 아래 네 가지 상태를 기록합니다.

관찰 결과 우선 조치 원격 맥 확장 판단
특정 소스와 스크립트만 반복적으로 오래 걸림 코드 구조와 입력·출력 관계 수정 확장하지 않음
의존성 다운로드와 인증에서 지연 잠금 파일, 접근 권한, 캐시 정책 수정 네트워크 경로를 먼저 검토
처리 장치가 계속 포화됨 작업 분리와 병렬도 조정 더 빠른 구성 검토
메모리 압박과 저장 장치 대기가 반복됨 동시 작업 수와 캐시 공간 점검 메모리 여유와 저장 공간을 함께 검토

원격 맥은 상시 보관 빌드나 자동 테스트를 분리할 때 의미가 있습니다. 반대로 물리 기기 연결, 특수 주변 장치, 장기간의 지속적인 고부하가 필수라면 직접 구매한 장비가 더 적합할 수 있습니다. 현재 환경을 유지하면서 임시 빌드 서버가 필요한 경우에는 원격 맥 환경 선택 안내를 먼저 확인할 수 있습니다.

원격 맥 빌드 가속 검수 체크리스트

같은 프로젝트로 다음 항목을 모두 확인한 뒤에만 구성을 바꿉니다.

  • [ ] 같은 코드 제출물, 계획, 구성, 실행 대상을 고정했습니다.
  • [ ] 첫 빌드와 증분 빌드를 별도 기록했습니다.
  • [ ] 보관 빌드에서 컴파일, 링크, 서명, 스크립트를 나눴습니다.
  • [ ] Package.resolved 복원과 의존성 다운로드를 컴파일과 분리했습니다.
  • [ ] 비공개 패키지 인증과 저장소 접근을 확인했습니다.
  • [ ] 병렬 테스트 수준을 단계별로 바꾸고 실패 재실행을 기록했습니다.
  • [ ] 처리 장치 포화, 메모리 압박, 저장 장치 대기 여부를 함께 관찰했습니다.
  • [ ] 최적화 전후의 증분 빌드, 깨끗한 보관 빌드, 테스트를 같은 조건에서 비교했습니다.
  • [ ] 프로젝트 수정으로 해결할 문제와 구성 확장이 필요한 문제를 구분했습니다.

현재 장비가 매번 빌드와 테스트에 묶여 작업 피드백을 막는다면, 맥 미니 렌탈 요금과 기간 비교에서 주 단위 또는 월 단위 환경을 검토할 수 있습니다. 구성 확장은 측정 뒤에 해야 합니다.

자주 확인하는 세부 문제

빌드 타이밍 요약에서 긴 작업을 찾는 방법

먼저 동일한 증분 빌드를 두 번 실행합니다. 첫 실행에서 의존성이나 초기 산출물이 포함되었다면 두 번째 결과와 분리합니다. 이후 특정 Swift 파일, 사용자 스크립트, 링크 작업이 반복되는지 확인합니다. 기록이 매번 달라진다면 코드 변경뿐 아니라 저장소 상태와 백그라운드 작업도 함께 고정해야 합니다.

칩과 메모리 중 무엇을 먼저 검토할지

처리 장치가 계속 포화되고 작업 대기열이 쌓이면 칩 확장을 검토합니다. 여러 대상과 테스트를 동시에 실행할 때 메모리 압박이 반복되면 메모리 여유가 더 중요할 수 있습니다. 단, 패키지 다운로드와 인증 지연은 두 자원 모두로 해결되지 않습니다. 관찰된 병목과 확장 항목이 일치해야 합니다.

깨끗한 보관 빌드가 필요한 경우

캐시가 의심스럽거나 배포 결과를 독립적으로 검증해야 할 때 깨끗한 보관 빌드를 실행합니다. 그러나 일상적인 증분 개발마다 캐시를 삭제하면 실제 개발 흐름과 다른 조건이 됩니다. 깨끗한 보관 빌드는 검수용 기준으로 보관하고, 반복 개발 속도는 증분 빌드 기록으로 판단해야 합니다.

Xcode 26 빌드가 너무 느린 원인이 프로젝트 내부의 반복 작업이라면 원격 맥으로 옮겨도 같은 지연이 남습니다. 반대로 현재 장비가 보관 빌드와 테스트를 동시에 처리하면서 처리 장치 포화, 메모리 압박, 저장 장치 대기를 반복한다면 로컬 장비 업그레이드는 비용이 크고 작업 중단도 발생합니다. 이 경우 SFTPMAC의 원격 맥을 이용해 같은 프로젝트로 증분 빌드, 보관 빌드, 테스트를 먼저 검수하면 구매 전에 실제 적합성을 판단할 수 있습니다. 단기 검증이나 지속적 통합 서버가 필요한 경우에는 주 단위 또는 월 단위 임대가 더 유연하지만, 장기간 안정적인 고부하 작업이나 물리 기기 연결이 핵심이면 직접 보유한 맥이 더 알맞습니다.