Xcode 27, 오래된 배포 타겟을 빌드 에러로 만들다. 기준선은 여기다.

수년간 문제없이 빌드되던 Mac 앱 프로젝트를 열고, Xcode 27 베타로 전환한 뒤 빌드 버튼을 누르면 거기서 멈춥니다.

The macOS deployment target 'MACOSX_DEPLOYMENT_TARGET' is set to 10.13, but the range of supported deployment target versions is 12.0 to 27.0.99.

Xcode 26에서 이 문장은 그냥 넘겨도 되는 노란색 경고였습니다. Xcode 27에서는 빨간색 에러이며 빌드가 진행되지 않습니다. 변화는 이게 전부지만, 보이는 것보다 작기도 하고 크기도 합니다. 작은 이유는 Apple 문서가 수년간 macOS 11과 iOS 15를 최저 기준으로 명시해 왔기 때문이고, 큰 이유는 Xcode가 그것을 한 번도 강제하지 않았으며 상당수의 배포된 앱이 조용히 그 허점에 의존해 왔기 때문입니다.

이 글에서는 Xcode 27이 실제로 무엇을 강제하는지(Apple 자체 표와 릴리스 노트 기준), Xcode 26이 실제로 무엇을 허용했는지(우리 디스크에 있는 SDK 기준), 누가 영향을 받는지, 에러를 다시 경고로 되돌리는 비공식 설정, 그리고 정말 중요한 마감일이 Xcode 27의 출시일이 아니라 내년 봄 App Store의 SDK 요구 사항인 이유를 정리합니다.

핵심 요약

• Xcode 27이 지원하는 배포 타겟은 macOS 12–27, iOS/iPadOS/tvOS 15–27, watchOS 9–27, visionOS 1–27, DriverKit 21–27입니다. Apple의 베타 6용 Xcode 지원 페이지 기준이며, 이보다 낮으면 빌드가 실패합니다.
• Xcode 26은 문서상으로는 macOS 11을 최저 기준으로 명시했지만, 실제로는 10.13까지 받아들였습니다. macOS 26.0 SDK의 설정 파일을 직접 확인한 결과 유효한 배포 타겟이 34개였고, 그 시작점은 10.13이었습니다. Xcode 27은 문서화된 범위를 실제로 강제되는 범위로 만들어 이 간극을 없앱니다.
• macOS 최저 기준은 베타 기간 중에 바뀌었습니다. 6월에 Apple의 노트는 Universal 백 디플로이먼트가 "macOS 27을 포함해 그 이하까지" 가능하다고 적었고, 개발자들은 이를 Big Sur로 해석했습니다. 베타 6의 노트는 "macOS 12 이상"이라고 명시합니다. Big Sur가 아니라 Monterey를 기준으로 계획하세요.
• 비공식 우회 설정도 존재합니다. __DIAGNOSE_INVALID_DEPLOYMENT_TARGET_AS_ERROR = NO를 설정하면 에러가 다시 경고로 바뀐다는 보고가 있습니다. 다만 이는 공식적으로 지원되지 않고 언제든 사라질 수 있으며, Apple이 해당 타겟을 테스트하지 않는다는 사실 자체를 바꾸지는 않습니다.
• 진짜 마감일은 App Store의 SDK 요구 사항입니다. Xcode 26의 SDK는 2026년 4월 28일부로 앱 제출에 필수가 되었습니다. Apple이 같은 패턴을 반복한다면 Xcode 27의 SDK는 2027년 4월경 필수가 될 것이고, 그 시점부터는 App Store 앱에서 macOS 11이나 iOS 14를 지원하는 것이 정상적인 경로로는 불가능해집니다.

공식 수치

Apple의 Xcode 지원 페이지에는 각 Xcode 버전이 무엇을 빌드할 수 있는지 정리한 표가 있습니다. 중요한 비교는 다음과 같습니다.

플랫폼	Xcode 26.6	Xcode 27 beta 6
macOS	11 – 26.5	12 – 27
iOS / iPadOS	15 – 26.5	15 – 27
tvOS	15 – 26.5	15 – 27
watchOS	8 – 26.5	9 – 27
visionOS	1 – 26.5	1 – 27
DriverKit	20 – 25.5	21 – 27

표를 꼼꼼히 보세요. "Xcode 27이 최소 버전을 올린다"는 헤드라인은 절반만 맞습니다. iOS는 Xcode 26 내내 문서상 최저 기준이 15였고 Xcode 27에서도 그대로 15입니다. macOS는 11에서 12로 한 버전만 올라갑니다. watchOS는 8에서 9로 올라갑니다. 문서상으로는 소폭 강화일 뿐입니다.

문서에 나오지 않는 사실은, Xcode 26의 수치가 한 번도 실제로 강제된 적이 없었다는 것입니다.

Xcode 26이 실제로 허용했던 것

Xcode에 들어 있는 모든 SDK는 유효한 배포 타겟을 선언하는 설정 파일을 가지고 있습니다. 저희 기기에 설치된 Xcode 26.0.1(17A400) 기준으로 그 파일의 경로는 다음과 같습니다.

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/SDKSettings.json

이를 읽어보는 데는 명령어 하나면 충분합니다.

python3 -c '
import json
d = json.load(open("/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/SDKSettings.json"))
t = d["SupportedTargets"]["macosx"]
print(t["MinimumDeploymentTarget"], "->", t["MaximumDeploymentTarget"])
print(len(t["ValidDeploymentTargets"]), "valid:", t["ValidDeploymentTargets"][:6], "...")
'

Xcode 26.0.1에서의 출력 결과는 다음과 같습니다.

10.13 -> 26.0.99
34 valid: ['10.13', '10.14', '10.15', '11.0', '11.1', '11.2'] ...

즉 Apple의 표는 "macOS 11"이라고 말했지만, SDK는 "10.13"이라고 말했고, Xcode는 배포 타겟 필드에 10.13을 입력하도록 내버려 둔 채 경고만 띄우고 빌드를 진행했습니다. Michael Tsai는 이 관행을 명확히 설명합니다. 개발자들은 "더 오래된 타겟을 수동으로 입력할 수 있었고", 상당수의 독립 Mac 소프트웨어가 실제로 그렇게 해서 High Sierra, Mojave, Catalina 사용자들을 최신 빌드에 남겨두었습니다.

Xcode 27 베타가 설치되어 있다면 같은 명령어를 그 SDK에 대해 실행해 보세요(Xcode-beta.app으로 경로를 바꾸면 됩니다). 새로운 최저 기준을 확인할 수 있을 겁니다. 저희는 이 기기에 베타가 설치되어 있지 않아서, 12.0이라는 수치는 파일을 직접 읽은 것이 아니라 Apple의 표와 개발자들의 보고에 의존한 것입니다.

경고에서 에러로

이 진단 메시지 자체는 새로운 것이 아닙니다. Apple의 빌드 시스템은 수년간 "지원되는 배포 타겟 버전의 범위는 X에서 Y까지입니다"라는 메시지를 경고로 출력해 왔습니다. Xcode 27에서 바뀐 것은 그 심각도입니다.

bleepingswift.com의 글은 Xcode 27에서 나타나는 iOS 버전의 메시지를 다음과 같이 인용합니다.

The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to xx.x, but the range of supported deployment targets versions is 15.0 to 27.0.x

macOS 버전도 동일한 메시지이며, MACOSX_DEPLOYMENT_TARGET와 12.0에서 27.0.99까지의 범위로 나타납니다. 이 메시지는 타겟별로 발생하므로, 익스텐션과 위젯, 테스트 번들이 모두 오래된 타겟을 상속받은 앱이라면 네 번 나타날 수 있고, 메인 앱만 고쳐서는 빌드가 정상화되지 않습니다.

Vienna RSS의 관리자들은 베타 출시 이틀 뒤인 6월 10일에 이 문제를 겪었습니다. 그들의 타겟은 10.13이었고, Xcode 26에서는 경고도 에러도 없이 빌드되었지만, Xcode 27에서는 "필수 요구 사항(빌드 에러)"이 되었습니다. 이어지는 그들의 우려는 이런 상황에 놓인 모든 Mac 개발자가 공유하는 것입니다. Xcode 26은 macOS 27에서 지원될 것으로 예상되지 않으므로, "예전 Xcode를 계속 쓰면 된다"는 대안에는 유효 기한이 있습니다.

6월과 베타 6 사이에 무엇이 바뀌었나

macOS 최저 기준은 베타 기간 내내 안정적이지 않았습니다. 자신이 어느 시점의 정보를 읽었는지 아는 것이 중요합니다.

6월에 Intel 관련 릴리스 노트는 Apple 개발자 포럼에 인용된 대로 다음과 같이 적혀 있었습니다.

Xcode 27 will only install and run on Apple silicon Macs. The macOS SDK is still Universal for back deployment up to and including macOS 27. Intel development is still possible with macOS versions that support Rosetta like macOS 27. (162138432)

이 문장은 최저 기준에 대해 아무것도 말하지 않습니다. Tsai의 출시 첫날 요약은 상황을 "이제 타겟으로 삼을 수 있는 최저 버전은 Big Sur(Apple Silicon Mac이라면 Monterey)"라고 해석했고, ViennaRSS 이슈는 아예 macOS 12라고 단정했습니다. 현재의 베타 6 릴리스 노트는 이를 다음과 같이 정리합니다.

Xcode 27 will only install and run on Apple silicon Macs. The macOS 27 SDK supports back deploying Universal (Intel and Apple Silicon) apps to macOS 12 and later. Intel development is still possible with macOS versions that support Rosetta like macOS 27. (162138432)

이슈 번호는 동일하고, macOS 12를 명시하도록 문구만 바뀌었습니다. Tsai의 9월 업데이트도 같은 내용을 언급합니다. "Xcode 27 베타 6은 이제 macOS 12.0을 최소 배포 타겟으로 문서화하고 있다." 마이그레이션 계획을 Big Sur 기준으로 세웠다면 Monterey로 수정하세요.

실제로 영향을 받는 사람들

영향이 큰 순서대로 세 그룹이 있습니다.

High Sierra부터 Big Sur까지 여전히 지원하는 Mac 앱

Tsai의 글이 다루는 대상이 바로 이 그룹이며, 플랫폼 쪽에서 가장 동정을 덜 받는 그룹이기도 합니다. Eternal Storms의 Matthias Gansrigler-Hrad는 Mastodon에서 이렇게 직설적으로 말했습니다.

I don't appreciate being forced by Xcode 27 to drop support for macOS 10.13-11.0. It's my decision

이런 개발자들에게 Xcode 27은 강요된 선택입니다. 최저 기준을 올려 2017~2020년 시스템 사용자를 끊어내거나, Xcode 26에 머물러 macOS 27 SDK와 그에 딸린 모든 것을 포기하거나 둘 중 하나입니다.

iOS 앱, 특히 15 미만인 iOS 라이브러리

iOS에 대한 Apple의 최저 기준은 Xcode 26부터 계속 15였으므로, 이미 15를 타겟으로 하는 앱이라면 아무 영향이 없습니다. 하지만 생태계에는 더 낮은 최소 버전을 선언한 라이브러리가 가득했고, 이제 그런 라이브러리를 임포트하는 모든 프로젝트에서 이 진단 메시지가 발생합니다. 6월 첫째 주에 GitHub 이슈 트래커에는 "Xcode 27 지원: 최소 iOS 배포 타겟을 15로 올려 달라"는 거의 동일한 요청이 쏟아졌습니다. Package.swift에서 .iOS(.v12)를 선언했던 Facebook iOS SDK를 비롯해 Adjust, DataDog, SDWebImage 등이 대상이었습니다. 관리자가 응답하지 않는 패키지에 의존하고 있다면, 응답이 오거나 직접 포크할 때까지 발이 묶입니다.

의존성 안에 오래된 타겟이 묻혀 있는 경우

가장 눈에 띄지 않는 경우입니다. 앱의 타겟은 15인데, 전이 의존성으로 딸려온 Swift 패키지의 타겟은 13이라고 해봅시다. Xcode 27은 여러분의 툴체인으로 그 패키지를 빌드하다가 13을 발견하고 빌드를 실패시킵니다. Swift Package Manager에는 사용하는 쪽에서 이를 덮어쓸 방법이 없습니다. bleepingswift의 결론도 저희와 같습니다. "platforms 선언에서 더 낮은 최소 버전을 선언한 패키지는 더 새로운 버전으로 업그레이드하거나, 직접 포크해서 요구 사항을 수정해야 한다."

숨겨진 우회 설정

실제로 존재하며, 알아두되 신중하게 다뤄야 합니다.

Tsai가 인용한 글에서, Ighor July는 7월 24일 자 글에서 Xcode 27 베타에 대해 "숨겨진 설정 하나가 그 에러들을 다시 경고로 바꿔주었고, 컴파일러는 테스트한 더 오래된 타겟들을 여전히 만들어냈다"고 보고합니다. 그는 이 설정을 "문서화되어 있지 않고, 일반 Xcode 인터페이스에는 없으며, 현재는 베타 툴체인에서만 테스트되고 있는" 설정이라고 설명합니다. Tsai의 글에 달린 독자 Harald Striepe가 이 설정의 이름을 밝혔습니다.

__DIAGNOSE_INVALID_DEPLOYMENT_TARGET_AS_ERROR = NO

이것은 빌드 설정이므로 빌드 설정이 들어가는 곳, 즉 구성에 연결된 .xcconfig 파일이나 타겟의 Build Settings 패널 맨 아래에 추가하는 User-Defined 설정에 넣으면 됩니다. 이를 설정하면 배포 타겟 검사가 Xcode 26의 동작으로 되돌아갑니다.

이제 단서 조항을 살펴봐야 하는데, 결코 사소하지 않습니다.

공식적으로 지원되지 않습니다. 언더스코어 두 개로 시작하는 것은 Apple이 내부 설정에 사용하는 관례입니다. 여러분이 이 설정에 의존하기 시작한 바로 다음 베타를 포함해, 어느 베타에서든 이름이 바뀌거나 제거될 수 있습니다.

경고만 되살아날 뿐, 테스트가 되살아나는 것은 아닙니다. 이 변화 전체에 대한 Tsai의 평가는 그대로 인용할 가치가 있습니다. 가장 정직한 관점이기 때문입니다.

I'm frustrated, too, but it's more honest than the recent releases that claimed to support deployment on older macOS versions when Apple clearly hadn't tested that it actually worked.

에러를 끄는 것은 결국 Apple이 예전에도 테스트하지 않았고 이제는 명시적으로 지원하지 않는다고 밝힌 타겟을 위해 빌드하는 상태로 돌아가는 것일 뿐입니다. Xcode 26에서 Catalina에서 망가졌던 것은 여전히 망가진 채로 남습니다.

App Store 문제는 해결되지 않습니다. 그래서 진짜 중요한 마감일 이야기로 넘어갈 차례입니다.

진짜 마감일은 2027년 4월입니다

Xcode 27이 출시된다고 해서 누구에게도 그것을 쓰라고 강제하지는 않습니다. 강제하는 것은 App Store의 SDK 요구 사항입니다.

Apple의 향후 요구 사항 페이지에는 2026년 4월 28일부터 App Store Connect에 업로드되는 앱이 Xcode 26과 26 SDK로 빌드되어야 한다고 기록되어 있습니다. Apple은 수년간 매년 봄마다 새로운 SDK에 이 규칙을 똑같이 적용해 왔습니다. 출시 후 약 7개월이 지난 4월에 현재 SDK가 필수가 되는 식입니다.

이 패턴이 유지된다면(Apple이 2027년 날짜를 발표한 것은 아니므로 이는 사실이 아니라 패턴에 기반한 예측입니다), 2027년 4월경부터는 모든 App Store 제출물이 Xcode 27 SDK로 빌드되어야 합니다. 그 시점이 오면 다음과 같은 일이 벌어집니다.

• Mac App Store 앱은 배포 타겟이 12.0 미만으로는 업데이트될 수 없습니다. 스토어가 받아들이는 유일한 툴체인이 빌드를 거부하기 때문입니다.
• 같은 이유로, iOS App Store 앱은 15.0 미만으로는 업데이트될 수 없습니다.
• 우회 설정이 App Store 검증을 통과할지는 알 수 없습니다. 이를 테스트해봤다고 보고한 사람은 아직 없으며, 저희라면 이 설정에 사업을 걸지 않을 것입니다.

App Store 바깥, 즉 Developer ID를 통한 직접 배포라면 이 중 어느 것도 적용되지 않습니다. 여러분이 소유한 Mac에서 Xcode 26이 실행되는 한 계속 그것으로 빌드할 수 있습니다. 다만 그것이 바로 다음 문제입니다.

Xcode 26을 계속 쓰는 방법과 그것이 통하지 않게 되는 이유

가장 뻔한 대응책은 둘 다 설치해두는 것입니다. xcodes 같은 도구를 쓰면 Xcode 26.6을 27 베타와 나란히 두고 xcode-select로 전환하기가 쉽습니다. 올해 안에 10.13 타겟 프로젝트를 여전히 출시해야 한다면 이것이 올바른 선택입니다.

다만 여기에는 유효 기한이 있습니다. Apple의 지원 표에는 Xcode 26.6이 "macOS Tahoe 26.2 – macOS Tahoe 26.x"를 요구한다고 되어 있습니다. macOS 27에서 실행된다는 말은 어디에도 없고, Tsai의 해석은 "구버전 Xcode를 쓰는 것은 좋은 해법이 아니다. Golden Gate에서는 지원되지 않기 때문이다"라는 것입니다. 실행이 될 수는 있지만, 안 된다 해도 Apple이 고쳐주지는 않을 것입니다. 그리고 그는 더 미묘한 대가도 덧붙입니다.

Swift also makes it more difficult to call newer APIs when using an older SDK.

Xcode 26에 머문다는 것은 macOS 26 SDK에 머문다는 뜻이고, 그러면 macOS 27의 API는 동적 조회를 통해서만 접근하거나 아예 접근할 수 없게 됩니다. 유지보수 모드인 앱이라면 괜찮습니다. 하지만 적극적으로 개발 중인 앱이라면 서서히 목이 조여드는 셈입니다.

Xcode 27 자체는 Apple Silicon 전용입니다

이것은 같은 릴리스에 함께 들어온 별개의 변화이며, 배포 타겟 이야기와 뒤섞이기 쉬우므로 무엇이 무엇인지 분명히 짚고 넘어가겠습니다.

릴리스 노트는 분명합니다. "Xcode 27은 Apple Silicon Mac에서만 설치되고 실행됩니다." 바이너리는 arm64 전용이며, 한 Intel MacBook Pro 사용자가 포럼에서 이를 확인했습니다. 그는 노트에 적힌 "macOS Tahoe 26.4 이상 필요"라는 문구를 보고 다른 기대를 했다가 그렇지 않다는 것을 확인한 경우였습니다. Tahoe는 일부 Intel Mac에서도 실행되지만, Xcode 27은 그렇지 않습니다.

SDK는 여전히 Universal입니다. Xcode 27에서도 x86_64 슬라이스와 Universal 바이너리를 빌드할 수 있으며, 다만 그 작업을 Apple Silicon에서 해야 할 뿐입니다. 이는 앱 배포에 대한 제약이 아니라 개발자에게 요구되는 하드웨어 조건입니다.

또 다른 Intel 관련 변화: 27.0에서는 Universal이 더 이상 기본값이 아닙니다

베타 6 노트에는 "Intel Deprecation" 항목 아래 Intel 관련 사항이 하나 더 있는데, 대부분의 기사들이 이를 놓쳤습니다.

Build targets with a min deployment target set to macOS 27.0 or DriverKit 27.0 will not build Universal by default. The ARCHS_STANDARD build setting will no longer include x86_64 when MACOSX_DEPLOYMENT_TARGET or DRIVERKIT_DEPLOYMENT_TARGET >= 27.0. The x86_64 architecture can be added to the ARCHS build setting if this is needed. (161837535)

이는 논리적입니다. macOS 27은 어떤 Intel Mac에서도 실행되지 않으므로, 27.0 전용 타겟이 실행될 Intel 기기 자체가 없기 때문입니다. 다만 부작용이 있습니다. Rosetta는 macOS 27에도 여전히 존재하며, Apple의 9월 1일 자 개발자 노트는 27이 Rosetta의 마지막 릴리스임을 다시 확인했습니다. 기본값으로 x86_64를 빼버린 27.0 전용 앱은 Apple Silicon 위에서 Rosetta로도 실행할 수 없게 되는데, 이는 Intel 전용 플러그인 호스트 같은 것을 배포하고 있었던 경우에만 문제가 됩니다. 필요하다면 ARCHS에 x86_64를 명시적으로 추가하세요.

아무도 언급하지 않는 세 번째 최저 기준: libc++는 11.0

같은 Deprecations 목록에 묻혀 있는 항목입니다. "macOS에서 C++ 표준 라이브러리가 지원하는 최소 배포 타겟이 11.0으로 상향되었다." 이는 12.0이라는 빌드 시스템의 최저 기준과는 다른, 그보다 낮은 기준이며, 여러분이 선언하는 배포 타겟이 아니라 링크하는 C++ 런타임에 적용됩니다. 실제로는 숨겨진 설정 등을 이용해 빌드 시스템 검사를 우회한 상태에서 여전히 10.15 이하를 타겟으로 C++ 코드를 작성하고 있을 때만 드러납니다. 그러면 이번에는 libc++ 자체가 여러분을 막아서는 다음 관문이 됩니다.

해결하기: 의존성

자신의 타겟이라면 해결책은 텍스트 필드에 숫자 하나를 바꾸는 것으로 끝납니다. 의존성이라면 이야기가 다릅니다.

CocoaPods. 모든 pod 타겟의 배포 타겟을 최저 기준으로 다시 쓰는 post_install 훅을 추가한 뒤 pod install을 실행하고 빌드 폴더를 정리하세요. bleepingswift가 제시한 훅 형태가 표준적인 형태입니다. 핵심은 오늘 에러를 내는 타겟만이 아니라 모든 pod 타겟에 적용해야 한다는 점입니다.

Swift Package Manager. 덮어쓸 방법이 존재하지 않습니다. 선택지는 다음과 같습니다. platforms를 올린 버전으로 업데이트하거나, 이슈를 새로 열거나 추천을 누르거나, 직접 포크해서 Package.swift를 수정한 뒤 upstream이 따라올 때까지 자신의 프로젝트가 그 포크를 바라보게 하는 것입니다. 먼저 이슈 트래커를 확인하세요. 주요 SDK라면 대개 6월 첫째 주에 누군가 이미 요청을 올려두었고 보통 풀 리퀘스트도 함께 달려 있습니다.

벤더 프레임워크와 XCFramework. 이들은 자체 Info.plist와 Mach-O 로드 커맨드에 자신만의 최소 버전을 담고 있습니다. Xcode 27은 오래된 바이너리 프레임워크를 링크하는 것 자체는 거부하지 않지만, 링커가 버전 불일치에 대해 경고를 띄우며, 오래된 타겟에서의 동작은 정확히 테스트된 만큼만 보장됩니다. 즉 사실상 테스트되지 않았다는 뜻입니다.

여기서 "정직하다"는 것의 의미

Tsai의 관점을 잠시 곱씹어볼 가치가 있습니다. 무엇에 화를 내야 할지가 달라지기 때문입니다.

Xcode 26은 macOS 10.13을 지원한 적이 없습니다. 그저 10.13을 입력하도록 허용했고 코드를 생성했을 뿐이며, Apple은 26 SDK 안의 프레임워크가 2017년형 OS에서 제대로 동작하는지 테스트하지 않았습니다. 그런 빌드를 출시한 개발자들은 사실상 Apple이 버린 OS를 대상으로 자체적으로 QA를 해온 셈이고, 프레임워크가 설계상 하위 호환되기 때문에 대체로 잘 작동했습니다. 하지만 그 문장에서 "대체로"라는 말이 실제로 많은 일을 떠맡고 있었고, SDK와 타겟 사이의 간극은 해마다 벌어졌습니다.

Xcode 27은 문서화된 범위를 실제 범위로 만듭니다. 이는 오래된 Mac 사용자들과 그들을 지원해 온 개발자들에게는 손실입니다. 하지만 Apple이 애초에 약속했던 무언가를 잃는 것은 아닙니다.

규제 측면의 변수

한 가지 이야기가 더 있습니다. 8월 26일 Tsai는 EU 사이버 회복력법(Cyber Resilience Act)에 관한 의견들을 정리했습니다. 이 법의 주요 의무 조항은 2027년 12월 11일부터 발효되며 최소 5년간의 보안 업데이트를 요구합니다. Frederik이라고 밝힌 한 독자는 App Store와의 상호작용 문제를 제기했습니다.

Once you update the minimum supported OS version of your app (which you might be forced to by newer Xcode versions… you can no longer provide updates for your older app versions on the App Store.

이것이 바로 이 글에서 설명한 메커니즘 그 자체입니다. App Store는 앱마다 현재 버전을 하나만 유지합니다. Xcode 27의 SDK가 필수가 되고 여러분의 최저 기준이 macOS 12로 올라가면, macOS 11 사용자는 마지막으로 받은 빌드를 영원히 그대로 쓰게 되고 보안 업데이트도 받지 못합니다. CRA가 이를 개발자의 의무로 볼지, Apple의 의무로 볼지, 아니면 누구의 의무도 아니라고 볼지는 법률가들의 몫입니다. 다만 기술적 사실은 Apple의 배포 모델에 브랜치 메커니즘이 없다는 것이고, Xcode 27은 이 사실을 훨씬 더 많은 개발자에게 드러내려 하고 있습니다.

마이그레이션 체크리스트

오래된 타겟을 가진 Mac 앱이라면, 다음 순서를 따르세요.

1. 실제 사용자 현황을 파악하세요. 분석 데이터상 macOS 12 미만 사용자가 아무도 없다면, 한 줄만 바꾸고 릴리스 노트만 남기면 끝입니다. 대부분의 앱이 여기에 해당합니다.
2. 모든 타겟의 배포 타겟을 12.0(macOS) 또는 15.0(iOS)으로 설정하세요. 익스텐션, 헬퍼, 테스트까지 빠짐없이 포함해야 합니다. Xcode 27 베타로 빌드해서 진단 메시지를 모두 없애세요.
3. 의존성을 점검하세요. 최저 기준보다 낮은 platforms 선언과 podspec을 찾아내고, 필요하면 직접 포크하세요.
4. 뒤처지는 사용자들을 어떻게 할지 결정하세요. 10.13~11.0 사용자에게 정말로 계속 배포해야 한다면, 2027년 4월 이전에 Xcode 26으로 마지막 빌드를 계획하고, App Store 바깥에서 배포하거나 고정된 레거시 버전으로 제공하고, 이를 공개적으로 알리세요.
5. 숨겨진 설정을 프로덕션에 배포하지 마세요. 직접 예전 OS에서 결과를 테스트했고, 이 설정이 다음 베타에서 사라질 수도 있음을 감수할 수 있는 경우가 아니라면요.
6. 27.0만을 타겟으로 한다면 ARCHS를 확인하세요. 자신도 모르게 x86_64를 빼버렸을 수 있습니다.

자주 겪는 문제 해결하기

앱의 타겟을 올렸는데도 에러가 계속 나타나요

프로젝트 안의 다른 타겟이 여전히 예전 값을 가지고 있는 것입니다. 내비게이터에서 (타겟이 아니라) 프로젝트를 선택해 프로젝트 수준의 배포 타겟을 확인한 다음, 각 타겟과 각 테스트 번들을 하나씩 확인하세요. 위젯과 앱 익스텐션이 대개 범인입니다.

직접 의존하지 않는 패키지 이름이 에러에 나와요

전이 의존성 때문입니다. swift package show-dependencies(또는 Xcode의 패키지 그래프)를 사용해 누가 그 패키지를 끌어오는지 찾은 다음, 중간 패키지를 업데이트하거나 최종 패키지를 포크하세요.

커맨드 라인의 xcodebuild는 실패하는데 Xcode GUI는 빌드돼요

커맨드 라인이 어떤 툴체인을 쓰고 있는지 xcode-select -p로 확인하세요. GUI는 26을, 커맨드 라인은 27을 쓰고 있거나 그 반대일 수 있습니다.

숨겨진 플래그를 설정했는데 아무 차이가 없어요

이 플래그는 검사가 실행되는 수준에서 빌드 시스템에 보여야 합니다. 프로젝트 수준의 xcconfig가 가장 안전한 위치입니다. 하나의 타겟에만 설정했다면 다른 타겟들은 여전히 에러가 납니다. 그래도 아무 효과가 없다면, 사용 중인 베타에서 이 플래그가 이미 제거되었을 수 있습니다.

CI 러너가 Intel이에요

Xcode 27은 그런 러너에 설치되지 않습니다. 이는 설정 문제가 아니라 하드웨어 마이그레이션 문제입니다. 호스팅형 제공업체들은 이미 오래전에 Apple Silicon 러너로 전환했습니다. 자체 호스팅하는 Intel Mac mini는 이제 현재 툴체인으로는 빌드할 수 없는 단종 상태입니다.

자주 묻는 질문

Xcode 27은 iOS 최저 버전을 올리나요?

문서상으로는 아닙니다. Apple의 표는 Xcode 26부터 계속 iOS 15라고 말해왔습니다. 바뀌는 것은 강제 여부입니다. Xcode 26에서는 경고만 뜨고 빌드되던, 15 미만의 타겟이 Xcode 27에서는 실패합니다.

Xcode 27의 macOS 최저 버전은 무엇인가요?

Apple의 Xcode 지원 페이지와 베타 6 릴리스 노트 기준으로 macOS 12 Monterey입니다. 베타 초기에는 이 노트가 Big Sur로 해석되었지만, 그 해석은 이제 지나간 것입니다.

여전히 Universal(Intel + Apple Silicon) 앱을 빌드할 수 있나요?

네, Apple Silicon Mac에서라면 가능합니다. macOS 27 SDK는 macOS 12 이상으로의 Universal 백 디플로이먼트를 지원합니다. x86_64가 기본값에서 빠지는 유일한 경우는 타겟이 27.0 이상으로 설정된 경우뿐입니다.

언제까지 Xcode 27로 옮겨야 하나요?

직접 배포라면 옮길 필요가 전혀 없습니다. Xcode 26이 실행되는 Mac을 가지고 있는 한은요. App Store라면 Apple이 27 SDK를 필수로 만드는 시점이며, 지금까지의 패턴대로라면 2027년 4월경이 될 것입니다. 다만 Apple은 아직 그 날짜를 발표하지 않았습니다.

숨겨진 설정을 App Store 빌드에 써도 안전한가요?

알 수 없습니다. 이를 사용해 제출했다고 보고한 사례는 아직 없고, 이는 문서화되지 않은 내부 플래그입니다. 릴리스 파이프라인이 아니라 로컬 빌드와 레거시 브랜치용 도구로만 취급하세요.

결론

Xcode 27의 배포 타겟 변화는 작은 수정이지만 여파는 깁니다. Apple은 최저 기준을 크게 올리지 않았습니다. macOS에서 한 버전, iOS에서는 아예 올리지 않았습니다. 하지만 그 기준이 선택 사항인 척하는 것을 멈췄고, 지난 10년간 수많은 독립 Mac 소프트웨어는 바로 그 겉치레 위에 세워져 있었습니다. 오늘 마주친 빌드 에러는 사용자가 최신 시스템을 쓰고 있다면 고치기 쉽고, 그렇지 않다면 제대로 고칠 방법이 없습니다.

자신이 어느 쪽인지부터 알아두세요. 여전히 macOS 11 이하로 배포하고 있다면, 남은 창구는 Xcode 26이 돌아가는 Mac뿐이고, App Store 앱 기준으로는 약 7개월 후면 닫힙니다. 그렇지 않다면 숫자를 올리고, 의존성을 고치고, 27 전용이라면 ARCHS를 확인한 뒤 넘어가면 됩니다. Apple은 어차피 하려던 일을 마침내 문서화했을 뿐입니다.

관련 글: Rosetta 종료 전에 Intel 앱을 점검하세요, macOS 27의 Intel 호환성 마감, macOS Tahoe 개발 환경 문제 해결하기, 올해 최고의 Mac 개발자 도구.