Apple 개발자 릴리스 페이지에는 Xcode 27.1 RC가 2026년 10월 5일 공개된 것으로 표시되어 있습니다. 릴리스 페이지의 공개 날짜는 후보 버전과 정식 버전을 구분해야 한다는 점을 보여 줍니다. 새 SDK나 서로 다른 도구 체인이 필요하면 Xcode 27과 Xcode 26을 함께 설치하고, 단일 프로젝트에 이전 빌드 요구가 없다면 하나만 유지하세요. 함께 설치한 뒤에는 빌드마다 사용할 버전을 명시해야 합니다.
이 글은 새 SDK 도입과 기존 앱 유지보수를 함께 맡은 독립 개발자를 위한 안내입니다.
이전 빌드를 되살려야 하는 팀은 명령줄 도구가 어느 Xcode를 가리키는지 확인할 수 있습니다.
원격 맥 환경을 준비 중이라면 필요한 macOS와 Xcode 조합부터 점검하세요.
마지막 업데이트: 2026년 10월 15일. Xcode 릴리스 상태와 요구 사항은 Apple 개발자 릴리스 페이지, Xcode 27.1 RC 릴리스 노트, 시스템 요구 사항을 기준으로 확인했습니다. 정식 버전 공개나 제출 규칙 변경이 있으면 다시 확인해야 합니다.
Xcode 27과 Xcode 26 함께 설치 판단
두 버전은 같은 맥에 별도 앱으로 둘 수 있습니다. 단, 설치 가능 여부만으로 병행 설치의 이점이 결정되지는 않습니다. 프로젝트가 요구하는 SDK와 빌드를 재현할 필요가 있는지부터 살펴야 합니다.
Xcode 27과 Xcode 26을 한 맥에서 쓸 수 있나요?
가능합니다. 각 앱의 이름과 위치를 구분해 보관하고, 프로젝트를 빌드할 때 GUI와 명령줄이 의도한 버전을 사용하는지 확인하면 됩니다. 설치본이 여러 개라는 사실만으로 프로젝트마다 자동으로 올바른 버전이 선택되지는 않습니다.
기존 iOS 프로젝트를 유지하려면 Xcode 26을 남겨야 하나요?
기존 프로젝트를 현재 도구 체인으로 빌드하고 배포할 수 있고 이전 결과를 다시 만들 필요도 없다면 꼭 남길 이유는 없습니다. 반대로 Xcode 27에서 달라진 SDK나 빌드 도구 때문에 결과가 달라지는지 확인해야 한다면, 이전 버전을 보존해 비교할 수 있습니다. 프로젝트가 Xcode 26을 반드시 요구한다고 미리 단정하지 말고 실제 빌드 설정과 의존성을 확인하세요.
Apple의 Xcode 27 릴리스 노트에는 해당 버전의 SDK와 변경 사항이 안내됩니다. 이전 도구 체인을 비교할 때는 Xcode 26.6 릴리스 노트도 확인하세요. 배포 목표 버전, 프로젝트에 포함된 SDK, Xcode 버전은 서로 다른 판단 기준입니다. 배포 목표가 낮다는 이유만으로 새 Xcode의 모든 변경 사항을 무시할 수 있는 것은 아닙니다.
결정 기준별 설치 선택
| 선택지 | 적합한 상황 | 장점 | 주의할 점 |
|---|---|---|---|
| Xcode 27과 Xcode 26 병행 | 새 SDK 테스트와 기존 빌드 재현을 모두 해야 하는 프로젝트 | 버전을 덮어쓰지 않고 결과를 비교할 수 있습니다 | 저장 공간과 버전 관리 부담이 늘고, 명령줄 선택을 확인해야 합니다 |
| Xcode 27만 유지 | 새 SDK를 쓰며 이전 빌드 재현이 필요하지 않은 프로젝트 | 관리할 도구 체인이 단순해집니다 | 이전 Xcode에서만 발생하는 문제를 같은 환경에서 재현하기 어렵습니다 |
| Xcode 26만 유지 | 새 SDK가 필요하지 않고 현재 배포 작업이 안정적으로 진행되는 프로젝트 | 기존 작업 흐름을 유지할 수 있습니다 | 새 SDK 검증이 필요해지면 별도 환경을 준비해야 합니다 |
다음 사례처럼 요구가 분명하면 선택이 쉬워집니다. 새 iOS SDK를 시험하면서 이미 출시한 앱의 수정 빌드도 유지해야 하는 개발자는 두 버전을 나란히 보관하는 편이 안전합니다. 반면 한 프로젝트만 관리하며 새 SDK 검증이나 과거 빌드 재현 요청이 없는 개발자는 단일 버전으로 시작하고, 실제 요구가 생길 때 추가 설치를 검토할 수 있습니다.
병행 설치의 이점은 버전 간 비교와 재현성입니다. 단점은 디스크 사용량 증가, 앱 이름과 경로 관리, 명령줄 도구의 선택 오류입니다. Xcode 앱만 보지 말고 프로젝트에서 사용하는 시뮬레이터 런타임과 빌드 산출물도 확인하세요. 설치본을 남길지 결정할 때는 실제 프로젝트 수와 다시 빌드할 가능성을 기준으로 삼고, 단지 새 버전이 나왔다는 이유만으로 모든 버전을 계속 보관하지 않아도 됩니다.
정식 배포와 후보 버전 구분
Xcode 27.1 RC는 Apple이 공개한 후보 버전입니다. 후보 버전은 테스트에 활용할 수 있지만 정식 배포 환경과 같다고 간주해서는 안 됩니다. Xcode 27.1 RC 릴리스 노트에서 포함된 SDK와 시스템 요구 사항을 확인하고, 프로젝트에서 필요한 기능과 빌드 결과를 따로 검증하세요.
릴리스 버전은 목적에 따라 구분합니다.
- 일상 개발: 팀이 합의한 안정 버전을 기본으로 사용합니다.
- 새 SDK 검증: RC나 베타가 포함된 도구 체인은 기존 배포 환경과 분리해 테스트합니다.
- 이전 빌드 재현: 해당 빌드를 만들었던 Xcode와 프로젝트 설정을 함께 기록합니다.
- 앱 제출: 제출 시점에 Apple이 공지한 현재 요구 사항을 확인합니다.
App Store Connect의 제출 조건은 고정된 규칙이라고 가정하지 마세요. 실제 제출 전에 App Store Connect 릴리스 안내를 확인해야 합니다. 과거에 통과한 Xcode 버전이나 SDK가 이후에도 계속 허용된다고 단정하지 않는 편이 안전합니다.
명령줄 버전 선택과 프로젝트별 고정
프로젝트마다 지정한 Xcode를 사용하려면 어떻게 하나요?
각 프로젝트의 빌드 절차에 사용할 개발자 디렉터리를 명시하고, 실행 후 실제 경로를 점검하세요. 그래픽 앱에서 선택한 버전과 터미널이 참조하는 활성 개발자 디렉터리는 별도로 확인해야 합니다.
Apple의 명령줄 도구 설정 안내는 활성 개발자 디렉터리를 확인하고 바꾸는 방법을 설명합니다. 다음 절차를 프로젝트 문서나 팀 빌드 절차에 반영하세요.
- 설치한 Xcode 앱의 이름을 구분합니다. 예를 들어 앱을
Xcode_27.app과Xcode_26.app으로 관리할 수 있습니다. 실제 앱 이름과 경로는 해당 맥의 설치 상태에 맞춰 확인합니다. - 현재 터미널이 참조하는 개발자 디렉터리를
xcode-select -p로 확인합니다. 기대한 경로와 다르면 기본 선택이 다른 설치본을 가리키는지 살펴봅니다. - 기본 버전을 바꿔야 한다면
sudo xcode-select --switch뒤에 사용할 Xcode의Contents/Developer경로를 지정합니다. 권한이 필요한 변경이므로 팀의 기본 설정을 바꾸기 전에 영향 범위를 확인하세요. - 특정 빌드 한 번에만 다른 설치본을 쓰려면
DEVELOPER_DIR환경 변수를 해당 명령에 적용합니다. 예를 들면DEVELOPER_DIR="/Applications/Xcode_27.app/Contents/Developer" xcodebuild -version처럼 실행할 수 있습니다. 앱 이름이 다르면 경로도 바꿔야 합니다. - 빌드 로그와 재현 문서에 Xcode 버전, 개발자 디렉터리, SDK 선택을 기록합니다. CI나 팀원이 같은 결과를 얻지 못하면 먼저 이 값들이 일치하는지 비교합니다.
xcode-select로 기본 경로를 바꾸는 방식은 이후 명령에도 영향을 줄 수 있습니다. 반면 DEVELOPER_DIR은 해당 명령에 사용할 경로를 지정하는 방식으로 활용할 수 있습니다. 여러 프로젝트를 한 맥에서 번갈아 빌드한다면 전역 기본값에만 의존하지 말고, 프로젝트별 스크립트와 기록에 버전 선택을 드러내세요. 그래야 어느 날 다른 프로젝트의 설정을 바꾼 뒤 원인을 모른 채 빌드 결과가 달라지는 일을 줄일 수 있습니다.
설치 후 재현성 확인
Xcode를 나란히 설치했다면 설치 완료만 확인하고 끝내지 마세요. 다음 항목을 각각 점검합니다.
- macOS 호환성: Apple의 시스템 요구 사항에서 설치하려는 Xcode와 현재 macOS의 조합을 확인합니다.
- SDK 요구: 릴리스 노트에서 각 Xcode에 포함된 SDK를 대조하고, 프로젝트가 실제로 쓰는 기능과 맞는지 확인합니다.
- 앱 경로: 설치한 앱의 이름과 경로를 기록해 전환 명령이 올바른 개발자 디렉터리를 가리키도록 합니다.
- 빌드 재현: 프로젝트 설정과 의존성을 고정하고, 팀원이 같은 도구 체인으로 빌드할 수 있는지 시험합니다.
- 저장 공간: Xcode뿐 아니라 필요한 런타임과 빌드 산출물을 함께 고려합니다. 여유 공간이 부족하면 사용하지 않는 설치본과 런타임을 정리하되, 과거 빌드 재현에 필요한 환경은 먼저 기록합니다.
여러 프로젝트가 같은 맥을 공유한다면 빌드 절차에 사용 버전과 경로를 넣고, 새 팀원이 그대로 따라 했을 때 결과가 재현되는지도 확인하세요. 이 과정이 어렵다면 원격 맥 접속 방식과 맥 환경 선택 기준을 살펴보며 필요한 관리 방식부터 정리할 수 있습니다.
한 대의 로컬 맥에 모든 버전을 계속 설치하는 방법은 디스크 공간을 차지하고, 사용자별 기본 경로가 달라지며, 기기 교체나 공유 시 환경을 다시 맞춰야 하는 부담이 있습니다. 반대로 여러 버전을 쓸 때마다 덮어 설치하면 이전 빌드 재현이 번거롭습니다. 단기 테스트나 프로젝트별 분리 환경이 필요한 경우에는 맥을 새로 구매하기 전에 xcodenode의 원격 맥 대여를 검토할 수 있습니다. 장기간 같은 환경에서 무거운 작업을 계속하거나 물리 장치 연결이 필요한 경우에는 로컬 맥이 더 적합할 수 있으므로, 먼저 필요한 macOS와 Xcode 조합 및 접속 방식을 확인한 뒤 선택하세요.
여러 개발 도구 환경을 직접 시험해 보세요
xcodenode의 원격 맥을 대여해 필요한 개발 환경과 빌드 흐름을 실제 장비에서 확인할 수 있습니다.