Xcode 27 iOS 빌드 서버 업그레이드

Xcode 27을 실행할 수 있는지, 프로젝트가 iOS 27 SDK를 필요로 하는지, 앱스토어 등록에 Xcode 27이 강제되는지는 서로 다른 문제입니다.

애플의 Xcode 27 베타 출시 문서에는 Xcode 27이 Apple silicon 맥에서만 설치되고 실행된다고 명시되어 있습니다. 동시에 같은 문서에는 로제타를 지원하는 맥 운영체제에서 인텔 개발이 계속 가능하다는 설명도 있습니다. 즉 인텔 맥에서 기존 프로젝트를 계속 빌드하는 것과 Xcode 27을 설치하는 것은 별도로 판단해야 합니다. Xcode 27 베타 출시 문서와 애플의 시스템 요구 사항을 기준으로 확인해야 합니다.

현재 앱스토어 등록 기준도 Xcode 27과 동일하지 않습니다. 애플은 2026년 4월 28일부터 앱스토어에 올리는 앱이 Xcode 26 이상과 iOS 26 SDK 이상으로 빌드되어야 한다고 안내합니다. 따라서 2026년 8월 11일 기준으로는 Xcode 27이 베타라는 이유만으로 모든 정식 등록 서버를 즉시 바꿔야 한다고 말할 수 없습니다. 앱스토어 등록 요구 사항과 예정 요구 사항 안내를 함께 확인해야 합니다.

정식 유지보수 앱

업데이트 빈도가 낮고 최근에 새 SDK를 호출하지 않는 앱이라면 인텔 맥을 당장 바꿀 필요는 없습니다. 이미 성공한 Xcode 26 보관과 서명, 업로드 과정을 고정하고, 환경 변경을 줄이는 편이 낫습니다.

다만 인텔 장비에 추가 비용을 쓰거나 운영 범위를 넓히는 것은 피해야 합니다. Xcode 27 베타를 설치할 수 없으므로 새 SDK 동작과 최신 시뮬레이터를 같은 서버에서 검증할 수 없습니다. 인텔 맥은 임시 안정 노드로 남기고, 다음 기능 개발부터 Apple silicon 노드를 추가하는 방식이 적절합니다.

iOS 27 기능 개발

iOS 27 SDK를 사용하거나 새 운영체제 동작을 확인해야 한다면 Apple silicon 맥이 선택 사항이 아닙니다. 애플의 시스템 요구 사항 표에는 Xcode 27 베타 4가 macOS Tahoe 26.4 이상에서 iOS 27 SDK를 제공한다고 나옵니다. 공식 시스템 요구 사항 표에서 베타 번호와 운영체제 조건을 확인할 수 있습니다.

이때 베타 환경을 정식 배포 환경과 분리해야 합니다. Xcode 위치, 패키지 캐시, 인증서, 보관 파일, 자동화 로그를 나누지 않으면 베타 도구가 안정 빌드에 섞일 수 있습니다. 새 SDK를 시험하는 노드와 실제 고객에게 배포하는 노드를 같은 기본값으로 두지 않는 것이 좋습니다.

플러터와 리액트 네이티브 프로젝트

플러터나 리액트 네이티브를 사용해도 최종 iOS 보관 과정에서는 macOS와 Xcode가 필요합니다. 프레임워크가 인텔 맥의 Xcode 27 제한을 우회해 주지는 않습니다.

이전 과정에서는 다음 항목을 따로 기록해야 합니다.

• 플러그인과 네이티브 라이브러리 설치 결과
• 코코아팟 또는 스위프트 패키지 의존성 해결 결과
• 명령줄 도구가 선택한 Xcode 경로
• 패스트레인 인증과 프로비저닝 프로필 동작
• 화면 없는 보관, 서명, 내보내기, 업로드 결과
• Apple silicon 구조 때문에 달라진 스크립트와 바이너리

문제가 발생하면 Xcode 27 문제인지, Apple silicon 구조 문제인지, 외부 의존성 문제인지 구분해야 합니다. 이 구분 없이 한 번에 장비를 교체하면 재현과 되돌리기가 어려워집니다.

Xcode 26과 Xcode 27은 같은 프로젝트에서 병렬로 사용할 수 있지만, 기본 개발 도구와 산출물 경로를 명시해야 합니다. 하나의 맥에 여러 버전을 설치하는 것보다 정식 노드와 베타 노드를 분리하는 편이 운영 위험이 낮습니다.

고빈도 배포 팀은 유일한 인텔 서버를 바로 교체하지 않는 편이 낫습니다. 먼저 자동화 작업을 복제하고, 새 노드에서 보관과 서명, 업로드를 확인한 뒤 기본 빌드 노드를 바꿔야 합니다. 마지막으로 일정 기간 실패 작업과 롤백 기록을 확인하고 인텔 서버의 퇴역 시점을 정합니다.

주의: Xcode 27 베타의 지원 범위와 앱스토어 등록 기준은 서로 다른 일정으로 바뀔 수 있습니다. 정식 버전 출시일이나 향후 Xcode 27 강제 등록 기한은 애플이 공식 발표하기 전까지 확정된 사실로 기록하지 않는 것이 안전합니다.

정식 배포가 우선인 독립 개발자

1. 현재 인텔 맥에서 Xcode 버전과 명령줄 도구 경로를 기록합니다.
2. 최근 성공한 보관 파일과 업로드 로그를 보관합니다.
3. 인증서와 프로비저닝 프로필의 갱신 절차를 문서화합니다.
4. Apple silicon 환경을 별도 노드로 만들고 Xcode 27 베타를 설치합니다.
5. 같은 프로젝트를 베타 노드에서 복제하고 의존성을 다시 설치합니다.
6. 정식 노드는 Xcode 26으로 유지합니다.
7. 다음 앱 업데이트 전까지 두 노드의 결과를 비교합니다.

현재 환경을 바로 폐기하기보다 iOS 빌드 서버 이전 점검 기준을 참고해 기존 산출물과 인증 정보를 먼저 정리하는 편이 좋습니다.

새 SDK를 바로 시험해야 하는 팀

1. Apple silicon 맥에 베타 전용 계정을 준비합니다.
2. Xcode 27과 iOS 27 SDK의 정확한 빌드 정보를 기록합니다.
3. 저장소를 새 작업 공간으로 복제합니다.
4. 패키지 관리자와 외부 플러그인을 처음부터 설치합니다.
5. 단위 테스트와 사용자 인터페이스 테스트를 실행합니다.
6. 화면 없는 보관을 수행합니다.
7. 서명과 내보내기를 확인합니다.
8. 테스트 업로드와 앱스토어 등록용 업로드를 구분합니다.
9. 실패 시 Xcode 버전, 구조, 의존성별 로그를 나눠 보관합니다.

앱스토어 등록 화면에서 빌드가 처리되고 선택되는 과정은 애플의 앱 제출 도움말과 같이 확인해야 합니다. 업로드가 끝났다는 사실만으로 심사 제출 준비가 완료된 것은 아닙니다.

패스트레인과 사용자 정의 스크립트 운영자

자동화에서는 Xcode 선택값을 암묵적으로 두지 않아야 합니다. 작업마다 개발 도구 경로, 보관 경로, 내보내기 옵션, 서명 이름, 업로드 대상 앱을 명시합니다.

검증 기준은 다음과 같습니다.

• 프로젝트가 오류 없이 컴파일됩니다.
• 테스트 명령이 같은 결과를 냅니다.
• 보관 파일이 생성됩니다.
• 서명 인증서와 프로비저닝 프로필이 정확히 선택됩니다.
• 내보낸 파일이 설치 가능한 형식입니다.
• 앱스토어 등록 또는 테스트 배포 업로드가 성공합니다.
• 같은 명령을 다시 실행해도 결과 경로와 로그가 예측 가능합니다.
• 이전 노드에서 즉시 되돌릴 수 있습니다.

패스트레인 자동화를 원격 환경으로 옮길 때는 저장소 비밀값과 인증서가 원격 작업 로그에 노출되지 않는지 먼저 확인해야 합니다. 셸 환경 변수, 키체인 접근 권한, 임시 보관 파일의 삭제 정책도 함께 기록해야 합니다.

아래 조건에서 하나라도 왼쪽 항목에 해당하면 해당 행의 행동을 우선 적용합니다.

독립 개발자가 반드시 즉시 교체해야 하는 것은 아닙니다. 그러나 Xcode 27을 실제로 실행하거나 iOS 27 동작을 확인해야 하는 순간에는 더 이상 인텔 맥만으로 계획을 세울 수 없습니다.

• [ ] Xcode 26 정식 배포 작업이 기존 노드에서 성공합니다.
• [ ] Xcode 27 베타 전용 Apple silicon 노드가 준비됐습니다.
• [ ] 프로젝트가 새 노드에서 컴파일됩니다.
• [ ] 테스트가 실행됩니다.
• [ ] 보관 파일이 생성됩니다.
• [ ] 서명 정체성이 예상한 값과 일치합니다.
• [ ] 내보내기 결과를 설치할 수 있습니다.
• [ ] 앱스토어 또는 테스트 배포 업로드가 성공합니다.
• [ ] 패스트레인과 사용자 정의 스크립트가 반복 실행됩니다.
• [ ] 베타 실패 시 Xcode 26 노드로 되돌리는 절차가 있습니다.
• [ ] 인증서와 비밀값의 접근 권한을 다시 확인했습니다.
• [ ] 다음 검토 날짜와 인텔 노드 퇴역 조건을 기록했습니다.

애플은 2026년 6월 23일부터 Xcode 27 베타 2와 iOS 27 베타 2로 만든 빌드를 테스트플라이트에 올릴 수 있다고 안내했고, 이후 버전별 지원 범위도 별도 공지로 갱신했습니다. 베타 테스트와 정식 앱스토어 배포를 같은 정책으로 취급하지 말아야 하는 이유입니다. 앱스토어 연결 변경 기록에서 버전별 허용 범위를 확인할 수 있습니다.

원격 Apple silicon 맥은 Xcode 27 검증용 서버로 사용할 수 있습니다. 다만 원격 환경을 선택할 때는 단순히 Xcode가 설치되는지만 보면 안 됩니다. 저장소 접근, 인증서 보관, 화면 없는 보관, 서명, 내보내기, 업로드까지 한 번에 재현되어야 합니다.

특히 다음 조건을 계약 또는 운영 문서에서 확인해야 합니다.

• 실제 Apple silicon 하드웨어인지
• Xcode 27 베타 설치가 가능한 macOS인지
• 원격 화면 접속과 셸 접속이 모두 가능한지
• 장시간 작업 중 연결이 끊겨도 빌드가 종료되지 않는지
• 작업 후 로그와 산출물을 회수할 수 있는지
• 필요한 기간만 사용하고 환경을 폐기할 수 있는지

장기간 매일 높은 부하로 빌드하고 물리 장치 연결이 필요하다면 자체 장비가 더 적합할 수 있습니다. 반대로 베타 SDK 검증이나 이전 기간의 보조 노드가 필요하다면 새 맥을 바로 구매하는 것보다 원격 맥으로 격리 환경을 먼저 만드는 편이 비용과 회수 위험을 낮출 수 있습니다. 맥 미니 대여 가격 기준과 한국 사용자를 위한 대여 조건을 확인한 뒤, 필요한 기간만 계산하는 방식이 현실적입니다.

현재 인텔 맥만 사용하는 방식은 Xcode 27 설치가 막히고, iOS 27 SDK 검증을 별도 환경에서 해야 하며, 오래된 단일 서버에 서명과 업로드가 집중되는 단점이 있습니다. 반대로 새 장비를 곧바로 구매하면 베타 검증이 끝난 뒤 사용률이 낮아질 수 있습니다. 이런 상황에서는 Apple silicon 원격 맥을 먼저 임대해 Xcode 27 격리 환경을 만들고, 정식 배포 체인은 유지하는 구성이 더 유연합니다.

이번 주에는 인텔 맥을 끄는 대신 현재 Xcode 26 배포 체인을 동결하고, Apple silicon 환경에서 Xcode 27과 프로젝트 보관, 서명, 업로드를 순서대로 검증하는 것이 좋습니다. 그 결과에 따라 즉시 이전, 이중 운영, 업그레이드 보류 중 하나를 선택하면 됩니다.