Xcode 27 다중 버전 공존: 2026 원격 맥에서 전환하는 방법

승자는 안정 버전을 기본으로 유지하고 Xcode 27 베타는 격리된 Apple Silicon 원격 맥에서 작업별로 선택하는 방식입니다. 운영 빌드가 있는 노드라면 베타로 덮어쓰지 말고, 구성·테스트·서명·아카이브·복구가 모두 확인된 뒤에만 사용 범위를 넓혀야 합니다.

이 글은 같은 원격 맥에서 Xcode 26과 Xcode 27 베타를 함께 관리해야 하는 iOS·macOS 개발자, 공유 빌드 노드를 운영하는 DevOps 엔지니어, 베타 도입을 검증하는 릴리스 담당자를 위한 내용입니다.

마지막 업데이트: 2026년 8월 22일. Xcode 시스템 요구 사항과 Xcode 27 베타 5 릴리스 노트를 기준으로 확인했습니다. Xcode 27의 정식 출시일과 최종 요구 사항은 아직 확정된 것으로 취급하지 않습니다.

설치 전 분리 기준

현재 생산 도구 체인이 안정적으로 동작한다면 직접 업그레이드하지 않는 편이 안전합니다. Xcode 27 베타는 별도 응용 프로그램으로 설치하고, 안정 버전은 기존 경로에 남겨 두는 구성이 적합합니다.

Apple의 시스템 요구 사항 페이지에는 2026년 8월 22일 기준으로 Xcode 27 베타 5가 기재되어 있습니다. 지원되는 macOS와 Apple Silicon 조건은 베타 번호에 따라 달라질 수 있으므로, 설치 직전에 Apple의 Xcode 시스템 요구 사항을 다시 확인해야 합니다. 베타 5의 변경점과 알려진 문제는 Xcode 27 베타 5 릴리스 노트에서 확인합니다.

설치 전에 다음 항목을 기록합니다.

• 원격 맥의 칩 구조와 macOS 버전
• 현재 안정 버전의 응용 프로그램 경로
• 프로젝트가 요구하는 SDK와 배포 대상
• 인증서, 프로비저닝 프로파일, 키체인 접근 방식
• 기존 CI 작업이 참조하는 개발자 디렉터리
• 베타에서 필요한 시뮬레이터 런타임과 추가 구성 요소

Xcode 26과 Xcode 27을 함께 설치하는 것은 응용 프로그램 경로와 작업 선택을 분리하면 가능합니다. 다만 공존 자체가 호환성을 보장하지는 않습니다. 프로젝트 파일, 패키지 플러그인, 시뮬레이터 런타임, 서명 도구가 각각 다른 문제를 일으킬 수 있습니다.

원격 화면과 기본 도구 체인

VNC나 웹 원격 화면으로 개발하는 경우에는 응용 프로그램 이름만 보고 판단하지 않아야 합니다. 예시처럼 명확한 이름과 경로를 먼저 확인합니다.

ls -ld /Applications/Xcode*.app
xcode-select -p
xcodebuild -version
xcrun --sdk iphoneos --show-sdk-path

예상 출력은 다음과 같은 형태입니다.

/Applications/Xcode-26.app
/Applications/Xcode-27-beta.app
/Library/Developer/CommandLineTools
Xcode 26.x
Build version ...

위 버전과 빌드 문자열은 노드에 실제 설치된 결과로 대체됩니다. 문서에 적힌 예상값을 성공 증거로 사용하면 안 됩니다.

전체 노드의 기본 개발자 디렉터리를 바꾸려면 xcode-select를 사용합니다.

sudo xcode-select --switch /Applications/Xcode-26.app/Contents/Developer
xcode-select -p
xcodebuild -version

이 설정은 해당 노드의 다른 셸과 작업에도 영향을 줄 수 있습니다. Apple의 Command Line Tools 설정 문서처럼 Xcode 응용 프로그램 내부의 설정과 명령줄 도구의 활성 경로는 별개의 관리 지점입니다.

따라서 화면에서 Xcode 27을 열었다고 해서 터미널의 xcodebuild도 자동으로 Xcode 27을 사용한다고 단정하면 안 됩니다. Xcode 설정 화면에서 선택한 도구 체인, xcode-select가 가리키는 경로, 실제 빌드 프로세스의 SDK 경로를 각각 확인해야 합니다.

SSH 단일 작업과 선택 범위

공유 원격 맥에서 한 번의 빌드만 베타로 실행한다면 전역 설정을 바꾸지 않는 편이 낫습니다. 이때 DEVELOPER_DIR을 현재 명령이나 프로세스에만 지정합니다.

DEVELOPER_DIR=/Applications/Xcode-27-beta.app/Contents/Developer \
xcodebuild \
  -workspace /Users/<사용자>/src/<프로젝트>.xcworkspace \
  -scheme <구성표> \
  -destination 'platform=iOS Simulator,name=<시뮬레이터>' \
  clean test

xcodebuild, xcrun, fastlane 같은 하위 프로세스가 같은 환경을 상속하므로 단일 SSH 세션이나 CI 단계의 도구 체인을 고정하기 쉽습니다.

export DEVELOPER_DIR=/Applications/Xcode-26.app/Contents/Developer
xcodebuild -version
xcrun --find clang
xcrun --sdk iphoneos --show-sdk-version

xcode-select와 DEVELOPER_DIR은 어떻게 나누어 사용해야 합니까?

xcode-select는 노드의 기본 경로를 바꾸는 전역 선택입니다. 관리자가 유지 보수 시간에 기본 버전을 정할 때 적합합니다. DEVELOPER_DIR은 현재 명령 또는 프로세스에만 적용되는 선택입니다. 생산 작업과 베타 검증이 함께 실행되는 공유 노드에서는 후자를 우선해야 충돌 범위를 줄일 수 있습니다.

버전 문자열 하나만 기록하지 말고 다음 결과를 CI 로그에 남깁니다.

printf '%s\n' "$DEVELOPER_DIR"
xcodebuild -version
xcrun --sdk iphoneos --show-sdk-version
xcrun --find xcodebuild

이 기록은 화면에서 선택한 Xcode가 아니라 실제 호출된 실행 파일과 SDK를 확인하는 증거가 됩니다.

작업별 경로와 CI 라우팅

병렬 CI에서는 “노드에 Xcode가 설치되어 있다”는 사실보다 “작업이 어느 Xcode를 호출했는가”가 중요합니다. 안정 릴리스, 베타 호환성 검사, 야간 회귀를 서로 다른 작업 유형으로 분리합니다.

예시 환경 변수는 저장소 설정에 직접 하드코딩하지 않고 CI 비밀 변수나 작업 정의에서 관리합니다.

case "$CI_XCODE_CHANNEL" in
  stable)
    export DEVELOPER_DIR="/Applications/Xcode-26.app/Contents/Developer"
    ;;
  beta)
    export DEVELOPER_DIR="/Applications/Xcode-27-beta.app/Contents/Developer"
    ;;
  *)
    echo "지원하지 않는 Xcode 선택값입니다."
    exit 2
    ;;
esac

xcodebuild -version
xcrun --sdk macosx --show-sdk-path

각 작업은 최소한 Xcode 빌드 문자열, SDK, 실행 대상, 커밋 식별자, 서명 방식, DerivedData 경로를 남겨야 합니다. 작업 결과만 성공으로 표시하고 이 정보를 남기지 않으면, 잘못된 SDK로 우연히 통과한 빌드를 발견하기 어렵습니다.

원격 빌드 노드 자체를 준비하는 과정은 원격 맥의 CI Runner 구성 방법과 함께 검토할 수 있습니다. 다만 이 글의 핵심은 Runner 설치가 아니라 작업별 Xcode 선택과 격리입니다.

구성 요소와 캐시 분리

Xcode 버전이 달라지면 시뮬레이터 런타임과 추가 구성 요소의 상태도 달라질 수 있습니다. 필요한 런타임은 Apple의 추가 Xcode 구성 요소 설치 안내를 기준으로 확인합니다.

프로젝트별로 다음 경로를 분리하면 캐시가 다른 도구 체인의 결과를 재사용하는 위험을 줄일 수 있습니다.

export DERIVED_DATA="/Users/<사용자>/Library/Developer/Xcode/DerivedData/<프로젝트>-$CI_XCODE_CHANNEL"
xcodebuild \
  -derivedDataPath "$DERIVED_DATA" \
  -workspace /Users/<사용자>/src/<프로젝트>.xcworkspace \
  -scheme <구성표> \
  build

Xcode를 바꾼 뒤 시뮬레이터나 서명이 실패하면 무엇부터 확인해야 합니까?

첫 단계는 전체 노드를 무조건 삭제하는 것이 아닙니다. 실제 개발자 디렉터리, SDK 경로, 대상 런타임, 프로젝트별 DerivedData를 순서대로 확인합니다. 베타 릴리스 노트에 해당 런타임이나 빌드 문제에 관한 알려진 항목이 있으면 재현 조건을 기록합니다.

시뮬레이터가 없거나 부팅되지 않는 경우에는 해당 Xcode의 구성 요소 설치 상태를 확인합니다. 캐시 충돌이 의심되면 프로젝트의 DerivedData만 새 경로로 바꿉니다. 계정 권한이나 키체인 세션이 원인이라면 서명 자산을 다시 가져오기 전에 접근 권한과 실행 사용자부터 확인해야 합니다.

서명과 아카이브는 단순한 Debug 빌드 성공과 별개입니다. Mac 배포 서명은 Apple의 배포용 서명 코드 안내를 따르고, 인증서와 프로비저닝 프로파일의 매핑을 별도로 검증합니다. 서명 검증의 기본 원리는 Apple의 코드 서명 및 검증 문서에서도 확인할 수 있습니다.

전환과 복구 판단

운영 노드에 적용하기 전에는 최소한 다음 순서로 검증합니다.

1. 두 응용 프로그램의 경로와 접근 권한을 확인합니다.
2. 안정 버전으로 현재 프로젝트를 빌드하고 테스트합니다.
3. DEVELOPER_DIR로 Xcode 27을 선택해 같은 프로젝트를 별도 작업 폴더에서 실행합니다.
4. 시뮬레이터 테스트와 실제 장치 대상의 빌드 결과를 분리해 기록합니다.
5. 아카이브를 생성하고 서명, 내보내기, 검증 결과를 확인합니다.
6. 안정 버전으로 되돌린 뒤 동일한 생산 작업을 다시 실행합니다.
7. 원격 맥을 재시작하고 기본 경로와 CI 환경 변수가 의도대로 복원되는지 확인합니다.

아카이브와 릴리스 검증에 관한 Apple 문서도 함께 확인하는 것이 좋습니다. 한 번의 Debug 빌드가 성공했다고 해서 배포 가능한 도구 체인으로 판정해서는 안 됩니다.

조건별 선택 기준

• 안정 릴리스가 매일 실행되면 안정 버전을 기본값으로 유지하고, 베타 작업에만 DEVELOPER_DIR을 지정합니다.
• 여러 CI 작업이 동시에 실행되면 작업 라벨, 환경 변수, 체크아웃 경로, DerivedData를 모두 분리합니다.
• Xcode 27에서 테스트만 통과하고 아카이브나 서명이 실패하면 베타 범위를 넓히지 않습니다.
• 재시작 후에도 기본 경로와 서명 세션이 복원되면 제한된 호환성 작업부터 허용합니다.
• 베타의 요구 사항이 현재 macOS 또는 칩 조건과 맞지 않으면 설치를 중단하고 별도 Apple Silicon 원격 맥으로 되돌립니다.

기존 생산 맥을 베타 검증에 함께 쓰면 전역 도구 체인 변경, 캐시 오염, 시뮬레이터 구성 차이, 서명 세션 충돌이 한 노드에서 겹칠 수 있습니다. 장기간 고정된 고부하 작업이 필요하거나 물리 장치 연결이 필수라면 전용 장비 구매가 더 적합할 수 있습니다.

반대로 짧은 기간에 Xcode 27을 검증하고, 기존 노드의 안정성을 보존해야 한다면 맥 미니 렌탈 가격과 기간을 비교해 별도 원격 맥을 마련하는 편이 합리적입니다. 기존 방식은 베타 설치를 위해 생산 장비를 중단해야 하고, 작업별 버전 분리가 어렵고, 복구 때마다 개발자 디렉터리와 캐시를 다시 점검해야 하는 단점이 있습니다. SFTPMAC의 원격 맥은 이런 검증을 독립된 root 권한 환경에서 진행하려는 경우에 적합하며, 실제 프로젝트의 빌드·서명·재시작 복구를 확인한 뒤 생산 노드 변경 여부를 판단할 수 있습니다.

단순한 임시 테스트라면 SFTPMAC의 원격 맥 환경을 먼저 확인하고, 장기 고정 빌드나 물리 장치 연동이 필요하면 자체 장비와 조건을 비교해야 합니다.