Xcode 27과 Xcode 26은 어떻게 공존할까? 2026년 원격 Mac CI 구성

애플은 Xcode 27 Beta의 호스트 조건과 지원 범위를 별도로 안내하고 있습니다. 애플의 Xcode 시스템 요구 사항을 먼저 확인해야 합니다.

증상: 파이프라인은 Xcode 26을 사용한다고 선언했지만 로그에는 Xcode 27 SDK가 표시됩니다.
가장 빠른 해결: 호환되는 Apple silicon Mac에 두 버전을 서로 다른 앱 경로로 설치하고, 모든 작업에서 DEVELOPER_DIR을 명시합니다.

Xcode 27과 Xcode 26 공존은 가능합니다. 다만 운영 CI에서 전역 xcode-select을 반복해서 바꾸는 방식은 피해야 합니다. 각 작업이 실제로 사용한 Xcode 버전, 빌드 번호, SDK, 개발자 디렉터리를 기록해야 결과를 설명할 수 있습니다.

이 글은 Xcode 26으로 정식 배포를 계속하면서 Xcode 27 Beta를 검증하는 모바일 개발팀을 위한 안내입니다. 저장소나 브랜치별로 도구 체인을 라우팅하는 DevOps 담당자, 원격 Mac 노드의 업그레이드와 복구를 관리하는 운영자에게도 해당합니다.

마지막 업데이트: 2026년 9월 1일. Xcode 27 Release Notes, 시스템 요구 사항, 명령 줄 도구 설정, 추가 구성 요소 문서를 기준으로 확인했습니다. 베타 기간에는 지원 범위와 구성 요소 동작이 바뀔 수 있으므로 배포 전 다시 확인해야 합니다.

전역 선택보다 작업별 도구 체인 고정이 안전합니다

실패 사례: 선언은 Xcode 26, 실제 SDK는 Xcode 27

예를 들어 release-ios 작업이 Xcode 26을 사용하도록 설정되어도, 노드의 전역 선택이 Xcode 27로 바뀌어 있으면 하위 셸과 일부 자식 프로세스가 다른 도구 체인을 볼 수 있습니다. 병렬 작업이 동시에 전역 선택을 변경하면 어떤 작업이 어떤 버전을 호출했는지 복원하기도 어렵습니다.

빌드 전에 다음 정보를 읽기 전용으로 기록합니다.

export DEVELOPER_DIR="/Applications/Xcode-26-release.app/Contents/Developer"

xcode-select -p
xcodebuild -version
xcrun --find xcodebuild
xcrun --sdk iphoneos --show-sdk-path
swiftc --version

실제 경로와 버전은 예시입니다. Xcode-26-release.app은 네 환경의 설치 이름으로 바꿔야 합니다. xcodebuild, xcrun, SDK 경로, Swift 컴파일러가 모두 지정한 개발자 디렉터리에서 나오는지 확인합니다. 명령 줄 도구 설정의 적용 범위는 애플의 명령 줄 도구 구성 문서에서 확인할 수 있습니다.

전역 xcode-select은 한 가지 공식 빌드만 수행하는 전용 노드의 기본값을 정할 때 적합합니다. 공유 노드에서 저장소나 브랜치마다 버전이 다르면 DEVELOPER_DIR이 더 안전합니다.

• 노드가 Xcode 26만 사용하면 전역 기본값을 유지할 수 있습니다.
• Xcode 26과 Xcode 27을 함께 사용하면 작업별 환경 변수를 적용합니다.
• 병렬 작업이 있으면 전역 선택을 변경하지 않습니다.
• 사전 점검이 실패하면 빌드와 아카이브를 즉시 중단합니다.

설치 경로와 호스트 조건을 먼저 분리합니다

Xcode 27 Beta와 Xcode 26을 같은 이름의 앱으로 설치하거나 기존 앱 위에 덮어쓰면 업데이트 시점에 경로가 바뀔 수 있습니다. 다음처럼 목적이 드러나는 이름을 사용합니다.

/Applications/Xcode-26-release.app
/Applications/Xcode-27-beta.app

설치 전에는 원격 Mac의 칩 구조와 macOS 지원 범위를 두 버전에 대해 각각 대조합니다. Xcode 27 Beta의 조건은 공식 Xcode 27 Release Notes, Xcode 26의 변경 사항은 공식 Xcode 26 Release Notes를 기준으로 확인합니다.

설치 파일의 출처와 빌드 번호도 기록합니다. 자동 업데이트는 베타 경로를 예상하지 못한 시점에 바꿀 수 있으므로 공유 노드에서는 자동 업데이트를 통제해야 합니다.

호환되지 않는 호스트를 억지로 사용하지 않습니다

한 버전이 요구하는 macOS 범위를 호스트가 충족하지 못하면 앱 패키지를 수정하거나 비공식 우회 방법으로 배포하지 않습니다. 처음 실행되더라도 SDK, 시뮬레이터, 서명 단계에서 재현성 없는 오류가 발생할 수 있습니다.

원격 Mac을 선택할 때는 앱이 열리는지만 보지 않습니다. 두 Xcode의 지원 조건, Apple silicon 여부, 저장 공간, 노드 재부팅 권한을 함께 확인해야 합니다. 필요하다면 원격 Mac 콘솔에서 실제 접근 방식과 관리 기능을 먼저 확인합니다.

구성 요소와 시뮬레이터는 별도로 검증합니다

Xcode 앱이 열린다는 사실만으로 CI 준비가 끝난 것은 아닙니다. 플랫폼 구성 요소, 시뮬레이터 런타임, 최초 실행 초기화가 버전별로 완료되어야 합니다.

첫 번째 단계: 각 Xcode를 한 번씩 초기화합니다

sudo xcode-select -s "/Applications/Xcode-26-release.app/Contents/Developer"
/Applications/Xcode-26-release.app/Contents/MacOS/Xcode -runFirstLaunch

sudo xcode-select -s "/Applications/Xcode-27-beta.app/Contents/Developer"
/Applications/Xcode-27-beta.app/Contents/MacOS/Xcode -runFirstLaunch

공유 노드에서는 이 초기화 작업을 CI 실행 중에 하지 않습니다. 관리자 작업으로 수행하고 완료 로그를 보관합니다. 초기화가 끝난 뒤에는 작업 환경에서 DEVELOPER_DIR을 다시 지정합니다.

두 번째 단계: 필요한 구성 요소만 설치합니다

아카이브와 단위 테스트만 수행하는 노드라면 UI 테스트용 런타임을 무조건 추가하지 않습니다. 시뮬레이터가 필요한 작업이라면 프로젝트의 대상 플랫폼과 런타임을 먼저 확인합니다. 구성 요소 설치 방법은 애플의 추가 Xcode 구성 요소 문서를 따릅니다.

시뮬레이터를 추가할 때도 현재 선택된 Xcode가 무엇인지 확인해야 합니다. 다른 버전의 앱에 런타임을 설치하면 CI가 기대한 목록을 보지 못할 수 있습니다. 추가 시뮬레이터 절차는 애플의 시뮬레이터 안내를 기준으로 점검합니다.

캐시와 서명 상태는 버전별로 격리합니다

여러 Xcode가 같은 DerivedData를 사용하면 이전 컴파일 결과가 새 도구 체인의 문제를 가릴 수 있습니다. 패키지 의존성 캐시, 아카이브, 테스트 결과, 로그도 같은 기준으로 나눕니다.

export CI_ROOT="$HOME/ci/work/project-a"
export DERIVED_DATA="$CI_ROOT/derived-data/xcode-26"
export ARCHIVE_PATH="$CI_ROOT/archives/xcode-26"

xcodebuild \
  -project "ExampleApp.xcodeproj" \
  -scheme "ReleaseScheme" \
  -derivedDataPath "$DERIVED_DATA" \
  -archivePath "$ARCHIVE_PATH/ExampleApp.xcarchive" \
  archive

Xcode 27 작업은 경로의 버전 부분만 바꿉니다. 프로젝트의 빌드 설정은 애플의 Build Settings Reference와 함께 확인합니다.

서명 자산은 버전마다 여러 벌을 복사하지 않습니다. 동일한 통제된 키체인과 접근 권한 경계에서 두 도구 체인이 필요한 작업을 수행하는지 확인합니다. 로그에는 인증서 이름과 프로비저닝 프로파일의 식별 정보만 남깁니다. 비밀번호, 토큰, 개인 키는 출력하지 않습니다.

검증은 두 종류로 나눕니다.

• 깨끗한 빌드: 새 DerivedData에서 도구 체인 자체의 호환성을 확인합니다.
• 반복 빌드: 캐시를 유지한 상태에서 동일한 커밋의 결과와 로그가 안정적인지 확인합니다.

컴파일 시간이나 복구 시간은 프로젝트, 캐시, 네트워크, 노드 상태에 따라 달라집니다. 실제 측정값이 없으면 성능 판단 근거로 사용하지 않습니다.

공존 여부를 결정하는 조건별 점검 목록

다음 항목은 설치 성공 여부가 아니라 운영 가능한지 판단하기 위한 목록입니다. 각 작업이 끝날 때 체크 표시와 로그 위치를 함께 남깁니다.

• [ ] Xcode 26 앱과 Xcode 27 Beta 앱이 서로 다른 고정 경로에 있습니다.
• [ ] 원격 Mac의 Apple silicon 구조와 macOS 지원 조건을 두 버전 모두 확인했습니다.
• [ ] 각 앱의 출처와 빌드 번호를 기록했습니다.
• [ ] 정식 작업에 Xcode 26용 DEVELOPER_DIR을 주입했습니다.
• [ ] 검증 작업에 Xcode 27용 DEVELOPER_DIR을 주입했습니다.
• [ ] xcodebuild, xcrun, SDK, Swift 컴파일러의 실제 경로를 로그에 남겼습니다.
• [ ] 두 버전의 최초 실행 초기화가 관리자 작업으로 끝났습니다.
• [ ] 프로젝트가 요구하는 플랫폼 구성 요소와 시뮬레이터만 설치했습니다.
• [ ] DerivedData, 의존성 캐시, 아카이브, 테스트 결과를 버전별로 분리했습니다.
• [ ] 깨끗한 빌드와 반복 빌드를 각각 통과했습니다.
• [ ] 두 버전이 같은 통제된 서명 권한 경계에서 작업을 완료했습니다.
• [ ] 재부팅 뒤에도 경로, 구성 요소, 작업별 라우팅이 유지됩니다.

판단은 다음 조건으로 나눕니다.

• 모든 항목이 통과하면 같은 노드에서 제한적으로 공존시킵니다.
• 정식 작업은 통과하지만 베타 작업의 시뮬레이터나 서명이 불안정하면 Xcode 27 전용 원격 노드로 분리합니다.
• 병렬 작업에서 전역 선택 충돌이 발생하면 즉시 DEVELOPER_DIR 방식으로 전환합니다.
• 재부팅 뒤 경로와 구성 요소를 복구하지 못하면 공용 노드 확대를 보류합니다.
• 호스트 조건을 만족하지 못하면 설치를 중단하고 호환되는 Apple silicon Mac을 준비합니다.

재부팅과 베타 업데이트 뒤에도 세 경로를 다시 실행합니다

공존 환경은 설치 직후보다 재부팅 뒤에 더 자주 무너집니다. 다음 세 경로를 모두 실행해야 합니다.

• 정식 경로: Xcode 26을 지정하고 테스트, 아카이브, 서명을 수행합니다.
• 검증 경로: Xcode 27 Beta를 지정하고 별도 캐시로 동일한 작업을 수행합니다.
• 복구 경로: 노드를 재부팅한 뒤 두 경로를 다시 실행하고 앱 경로와 구성 요소 목록이 유지되는지 확인합니다.

각 작업은 다음 증거를 남깁니다.

commit: <placeholder-commit>
developer_directory: <placeholder-path>
xcode_version: <placeholder-version>
build_number: <placeholder-build>
sdk_path: <placeholder-sdk-path>
scheme: <placeholder-scheme>
archive_result: pass-or-fail
signing_result: pass-or-fail

Xcode 27 Beta를 업데이트한 뒤에는 기존 검증 결과를 그대로 재사용하지 않습니다. 새 빌드 번호로 깨끗한 빌드와 반복 빌드를 다시 수행합니다. 구성 요소가 사라졌거나 서명 결과가 달라지면 확대 배포를 멈추고 이전 앱 경로로 되돌립니다.

원격 Mac CI 운영에서 접속과 작업을 분리합니다

원격 환경에서는 로컬 화면에서 놓치기 쉬운 권한과 접속 상태도 점검해야 합니다. SSH 세션이 끊겨도 작업이 계속되도록 작업 실행기와 로그 보관 위치를 분리합니다. VNC는 최초 승인이나 시뮬레이터 확인에 사용하고, 반복 빌드는 SSH 기반으로 제한하는 편이 관리하기 쉽습니다.

원격 Mac 도움말에서 접속 방식과 관리 조건을 확인한 뒤 다음 절차를 운영 규칙에 넣습니다.

1. 노드가 올바른 Apple silicon 호스트인지 확인합니다.
2. 두 앱의 설치 경로와 출처를 기록합니다.
3. 각 파이프라인에 DEVELOPER_DIR을 주입합니다.
4. 실제 도구와 SDK 경로를 로그로 남깁니다.
5. 구성 요소와 시뮬레이터를 실제 프로젝트로 시험합니다.
6. 버전별 캐시와 아카이브를 분리합니다.
7. 정식·검증·복구 경로를 재부팅 뒤 다시 실행합니다.

현재 Windows나 Linux 서버를 중심으로 운영하면 macOS 전용 Xcode 도구 체인을 직접 제공하기 어렵습니다. 별도 Mac을 붙이면 장비 구매, 초기 설정, 상시 전원, 고장 대응이 추가됩니다. 가상 환경은 호스트 조건과 그래픽, 시뮬레이터 동작을 따로 검증해야 합니다.

따라서 Xcode 27 Beta 검증처럼 기간과 목적이 정해진 작업에는 기존 정식 노드를 건드리지 않고 MacHTML의 원격 Mac을 별도 노드로 임대하는 편이 맞을 수 있습니다. 반대로 장기간의 안정적인 고정 부하, 물리 장비 연결, 사내 키 관리가 필수라면 직접 소유한 전용 Mac이 더 적합할 수 있습니다. 원격 Mac 요금과 기간을 확인해 필요한 기간과 접속 방식을 비교해 보시기 바랍니다.

최종 판단은 설치 여부가 아니라 증거에 달려 있습니다. Xcode 26 정식 경로가 계속 재현되고 Xcode 27 Beta 검증 경로가 독립적으로 복구된다면 한 노드 공존을 유지할 수 있습니다. 병렬 충돌이나 재부팅 복구 실패가 남아 있다면 Xcode 27 전용 원격 Mac을 준비하고 정식 배포 노드는 그대로 보존하는 것이 안전합니다.

더 읽기: 여러 엑스코드 버전을 검증할 원격 맥의 씨아이 환경을 고를 때 참고할 성능 안내 원격 맥에 접속하고 시뮬레이터와 개발 도구를 함께 운용하는 기본 설정 살펴보기