Xcode 27, Intel 지원 종료: 무엇이 멈추고 무엇은 그대로 출시되는가

Apple은 이미 출시 중인 바이너리를 바꿔놓을 가능성이 가장 큰 Intel 관련 변경을 Deprecations(지원 중단)가 아니라 New Features(새 기능) 항목으로 올려두었습니다. Xcode 27 릴리스 노트의 Intel Deprecation 섹션에는 항목이 정확히 두 개 있는데, macOS 앱이 기본값으로 Universal 빌드를 만들지 못하게 하는 쪽은 New Features 편에 놓여 있습니다.¹²

핵심 요약

• 하나의 헤드라인 뒤에 서로 다른 변경 세 가지가 숨어 있고, Apple 자신의 문장은 그 셋을 분명히 구분합니다. Xcode 27은 Apple silicon Mac에서만 설치되고 실행됩니다.² macOS 27 SDK는 여전히 Universal 앱을 macOS 12 이상으로 하위 배포(back deploy)할 수 있게 해줍니다.² 그리고 타깃의 macOS 또는 DriverKit 배포 타깃이 27.0에 도달하면 ARCHS_STANDARD에서 x86_64가 빠집니다.¹
• 실제로 출시물의 내용을 바꾸는 것은 세 번째뿐이고, 그 변경은 아무런 진단 메시지 없이 일어납니다. Apple은 같은 항목에서 해결책까지 밝혀둡니다. 필요하다면 ARCHS 빌드 설정에 x86_64를 추가하면 된다는 것입니다. “The x86_64 architecture can be added to the ARCHS build setting if this is needed.”¹
• Xcode 26.6으로는 새 동작을 미리 확인할 수 없습니다. macOS 전용 프로젝트에 MACOSX_DEPLOYMENT_TARGET=27.0을 강제로 넣어봤지만 ARCHS_STANDARD는 여전히 arm64 x86_64로 해석됐습니다.¹³
• 점검 습관 두 가지가 틀린 답을 만들어냅니다. -sdk macosx를 넘겼더니 iOS 전용 프로젝트가 SUPPORTED_PLATFORMS = macosx와 ARCHS_STANDARD = arm64 x86_64를 보고했고, 프로젝트 수준에서 설정을 해석했더니 기본 타깃이 iOS인 프로젝트 안에 있던 macOS 타깃 두 개가 가려졌습니다.¹⁴
• 제 Xcode 프로젝트 11개, 타깃 44개를 훑어본 결과 21개 타깃이 macOS용으로 빌드되고, 그중 가장 높은 macOS 배포 타깃은 26.5이며, ARCHS나 EXCLUDED_ARCHS를 설정한 타깃은 하나도 없었습니다.¹⁴ 디스크에 있는 macOS 아카이브 51개는 전부 x86_64 arm64입니다.¹⁴
• Intel 소프트웨어의 끝은 Xcode 27이 아니라 macOS 28에 놓여 있고, Apple의 문장에는 읽어둘 만한 예외 조항이 붙어 있습니다. 레거시 게임은 그 대상에서 빠진다는 단서입니다. “All Intel-based software will no longer be compatible with macOS 28.0, excluding legacy games.”¹⁰

위 내용은 모두 Apple이 베타 문서로 공개한 것이며, Xcode 27 beta 4 릴리스 노트와 macOS 27 beta 4 릴리스 노트에 실려 있습니다.³⁶

문장 셋, 서로 다른 변경 셋

Apple의 Intel Deprecation 섹션에는 항목이 두 개 있습니다. 이 둘을 하나의 주장으로 뭉뚱그려 읽으면 양쪽 방향 모두에서 잘못된 결정이 나옵니다.

지원 중단 항목은 책상 위의 기계에 관한 이야기이고, 여기에는 빠져나갈 여지가 없습니다. Xcode 27은 Apple silicon Mac에서만 설치되고 실행됩니다. “Xcode 27 will only install and run on Apple silicon Macs.”² 어떤 빌드 설정으로도 이 사실은 바꿀 수 없습니다. Intel Mac은 현행 Xcode를 돌리는 기계에서 제외되며, Apple의 호환성 표는 하드웨어 요구 사항 위에 소프트웨어 하한선까지 얹어 Xcode 27 beta 4의 요구 사항으로 macOS Tahoe 26.4 이상을 명시합니다.⁴

같은 항목은 이어서 결과물을 보호합니다. macOS 27 SDK는 Universal(Intel과 Apple Silicon) 앱을 macOS 12 이상으로 하위 배포하는 것을 지원한다는 것입니다. “The macOS 27 SDK supports back deploying Universal (Intel and Apple Silicon) apps to macOS 12 and later.”² Apple의 호환성 표도 같은 이야기를 하는데, Xcode 27 beta 4의 macOS 배포 범위를 12부터 27까지로, Xcode 26.6은 11부터 26.5까지로 보여줍니다.⁴ 하한선이 딱 한 릴리스만큼 올라간 셈입니다. Universal 바이너리는 살아남습니다.

그리고 이 항목은 작업 방식 자체를 보존하는 문장으로 마무리됩니다. Rosetta를 지원하는 macOS 버전, 예컨대 macOS 27에서는 Intel 개발이 여전히 가능하다는 것입니다. “Intel development is still possible with macOS versions that support Rosetta like macOS 27.”²

이제 New Features 항목을 봅시다. 이미 출시 중인 제품을 바꿔놓을 수 있는 쪽은 이쪽입니다.

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.¹

여기서 네 가지를 갈라서 읽어야 합니다. Apple은 설정 두 개만 지목했고 그 밖의 것은 언급하지 않았으므로, IPHONEOS_DEPLOYMENT_TARGET과 그 형제들은 이 규칙 바깥입니다. Apple은 툴체인 버전이 아니라 임계값을 지목했으므로, 방아쇠는 여러분 자신의 배포 타깃이 27.0을 넘어서는 순간입니다. Apple은 기본값으로는 Universal 빌드를 만들지 않는다(“will not build Universal by default”)고 썼는데, 이는 기본값을 설명한 것이지 금지가 아닙니다. 그리고 Apple은 같은 호흡에서 빠져나갈 길까지 제시하며, x86_64를 되돌려 넣을 자리로 ARCHS를 지목합니다.

오류 없이 바뀌는 기본값

작동 원리는 평범하고, 바로 그 평범함이 이 변경을 조용하게 만듭니다. Apple의 빌드 설정 레퍼런스는 ARCHS를 이렇게 설명합니다. “A list of the architectures for which the product will be built. This is usually set to a predefined build setting provided by the platform. If more than one architecture is specified, a universal binary will be produced.”⁵ 여기서 말하는 미리 정의된 설정이 ARCHS_STANDARD이고, Apple은 같은 레퍼런스의 다른 곳에서도 이 의존 관계를 확인해줍니다. 포인터 인증 항목에는 “Has no effect if ARCHS has been overridden to not be based on ARCHS_STANDARD.”라고 적혀 있습니다.⁵

즉 ARCHS를 한 번도 언급하지 않은 타깃은 플랫폼이 건네주는 값을 그대로 물려받습니다. 플랫폼이 건네주는 값이 바뀌면, 버전 관리 아래의 어떤 파일도 수정하지 않은 채로 제품의 모양이 바뀝니다.

이 변경 어디에서도 실패는 발생하지 않습니다. 컴파일러가 돌고, 링커가 돌고, 아카이브 검증도 통과합니다. 툴체인의 어느 부분도 arm64 단일 슬라이스 macOS 빌드를 오류로 취급하지 않는데, 실제로 오류가 아니기 때문입니다. 결과물은 슬라이스 두 개를 담던 자리에 하나만 담은, 올바르게 서명된 macOS 앱입니다. 이제 Xcode 27 개발자라면 요구 사항상 누구나 쓰게 될 Apple silicon Mac에서는 arm64 전용 빌드도 똑같이 실행되고 똑같이 동작합니다. 달라진 결과는 이제 사무실에 남아 있지 않은 하드웨어에서 드러납니다.

이 실패 양상을 “조용하다”고 표현한 것은 Apple이 아니라 제 해석입니다. Apple은 기본값을 설명하고 거기서 멈춥니다. Apple이 실제로 말한 것은 수정 방법이 무언가를 덧붙이는 방식이라는 점이고, 그 표현은 계획을 세울 때 중요합니다. x86_64는 필요하다면 ARCHS 빌드 설정에 추가할 수 있습니다(“can be added to the ARCHS build setting if this is needed”).¹ 필요한지 아닌지에 대한 판단은 Apple이 여러분에게 맡겨둔 몫입니다.

Xcode 26.6이 알려주는 것과 알려주지 않는 것

제 기계는 macOS 26.5.2 위에서 Xcode 26.6(빌드 17F113)을 돌리고 있으므로, 이 글 어디에도 Xcode 27의 동작은 등장하지 않습니다.¹³ 이전 툴체인이 답해줄 수 있는 유용한 질문은 “이미 새 방식대로 동작하고 있는가”입니다. 답은 아니오입니다.

macOS 전용 프로젝트에 xcodebuild를 겨누고 Apple이 지목한 임계값 너머로 배포 타깃을 덮어써도 아키텍처 목록은 그대로입니다.¹³

xcodebuild -showBuildSettings -project Cels.xcodeproj \
  -configuration Release -sdk macosx \
  MACOSX_DEPLOYMENT_TARGET=27.0 2>/dev/null \
  | grep -E "^ +(ARCHS|ARCHS_STANDARD|MACOSX_DEPLOYMENT_TARGET) ="

    MACOSX_DEPLOYMENT_TARGET = 27.0
    ARCHS = arm64 x86_64
    ARCHS_STANDARD = arm64 x86_64
    MACOSX_DEPLOYMENT_TARGET = 27.0

첫 줄은 xcodebuild가 덮어쓴 값을 그대로 되돌려주는 것이고, 나머지는 해석된 값입니다. 같은 명령을 26.0으로 실행해도 아키텍처 줄은 동일하게 나옵니다.¹³ Xcode 26.6은 이 임계값을 구현하지 않았으므로, 현행 툴체인에서 이 변경을 미리 연습해볼 방법은 없습니다. 전후 비교는 Apple silicon Mac에 Xcode 27이 올라간 다음에야 가능합니다.

플랫폼 범위 제한은 지금도 재현됩니다. 같은 프로젝트를 iOS SDK 기준으로 해석하면 ARCHS_STANDARD = arm64가 나와 잃을 x86_64 자체가 없고, macOS SDK 기준으로는 arm64 x86_64가 나옵니다.¹³ Apple의 항목은 macOS와 DriverKit 배포 타깃만 지목하므로, 멀티플랫폼 프로젝트의 iOS 쪽에는 걸린 것이 없습니다.

없는 영향까지 지어내지 않고 내 프로젝트를 점검하는 법

확신에 찬 오답을 만들어내는 습관이 두 가지 있습니다. 저는 둘 다 밟았습니다.

첫째는 프로젝트가 macOS용으로 빌드되는지 알아보려고 -sdk macosx를 넘기는 것입니다. 이 플래그는 프로젝트 자신의 SDK를 덮어쓰므로, Xcode는 프로젝트가 아니라 플래그에 관한 질문에 답하게 됩니다. 덮어쓰기 없이 물으면 제 iOS 전용 브라우저 프로젝트는 실제 플랫폼을 보고하지만, -sdk macosx를 붙여 물으면 같은 프로젝트가 SUPPORTED_PLATFORMS = macosx와 ARCHS_STANDARD = arm64 x86_64를 보고하는데, 이건 플래그가 만들어낸 허상일 뿐입니다.¹⁴ -sdk를 아예 빼고 시작하세요.

xcodebuild -showBuildSettings -project YourApp.xcodeproj \
  -configuration Release 2>/dev/null \
  | grep -E "^ +(SUPPORTED_PLATFORMS|SDKROOT) ="

제 유일한 macOS 전용 앱에 실행하면 두 줄이 돌아옵니다.¹⁴

    SDKROOT = /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX26.5.sdk
    SUPPORTED_PLATFORMS = macosx

한 줄만 보지 말고 두 줄을 함께 읽어야 합니다. 저 프로젝트는 SDKROOT = macosx만 선언하고 SUPPORTED_PLATFORMS 줄은 아예 없기 때문에, 프로젝트 파일을 SUPPORTED_PLATFORMS로 텍스트 검색하면 점수가 0으로 잡혀 제가 가진 유일한 macOS 전용 앱을 건너뛰게 됩니다.¹⁴ 해석된 설정은 SDK에서 그 빈자리를 채워주지만, grep은 그러지 못합니다. 이 단계에서 MACOSX_DEPLOYMENT_TARGET은 무시하세요. Xcode가 어차피 값을 하나 넣어주기 때문입니다. 제 iOS 전용 프로젝트 세 개도 여전히 macOS 배포 타깃을 보고하는데, 둘은 26.5, 하나는 26.2입니다.¹⁴

둘째 습관은 프로젝트 수준에서 설정을 해석하는 것입니다. -target 없이 실행한 xcodebuild -showBuildSettings는 타깃 하나에 대해서만 답하고, 성격이 뒤섞인 프로젝트에서는 나머지가 파묻힙니다. 제 Safari 확장 프로젝트는 SUPPORTED_PLATFORMS = iphoneos iphonesimulator와 ARCHS_STANDARD = arm64로 해석되는데, 이건 Intel과는 아무 상관이 없는 iOS 전용 프로젝트처럼 읽힙니다. 타깃을 열거해보니 네 개가 있었고, 그중 둘이 macOS였으며, 둘 다 arm64 x86_64로 해석됐습니다.¹⁴

xcodebuild -list -project YourApp.xcodeproj
for t in TargetA TargetB; do
  xcodebuild -showBuildSettings -project YourApp.xcodeproj \
    -target "$t" -configuration Release 2>/dev/null \
    | grep -E "^ +(SUPPORTED_PLATFORMS|MACOSX_DEPLOYMENT_TARGET|ARCHS_STANDARD) ="
done

미리 알아둘 특이 동작이 하나 있습니다. SDKROOT = auto를 달고 있는 타깃은 SDK를 지정하기 전까지 ARCHS_STANDARD를 해석하지 않으므로, 제 macOS 타깃 21개 중 15개는 명령에 -sdk macosx를 붙이기 전까지 그 줄에 아무것도 출력하지 않다가, 붙이고 나면 해당 프로젝트들이 arm64 x86_64로 해석됩니다.¹⁴ 빈칸은 비어 있다는 뜻이 아니라 아직 해석되지 않았다는 뜻입니다.

그다음에는 설정을 믿지 말고 바이너리를 읽으세요. 빌드 설정은 의도를 서술하지만, lipo는 실제로 출시한 산출물을 서술합니다.

lipo -archs YourApp.xcarchive/Products/Applications/YourApp.app/Contents/MacOS/YourApp

x86_64 arm64

아카이브 자체의 메타데이터보다 lipo를 우선하세요. 제 아카이브 두 개는 Info.plist에 ApplicationProperties 아키텍처 목록이 아예 없어서, 아카이브를 대상으로 한 plutil 조회는 아무것도 반환하지 않는 반면 그 안의 바이너리에 lipo를 걸면 x86_64 arm64가 나옵니다.¹⁴ 메타데이터에 없다는 것은 아카이브가 다른 방식으로 기록됐다는 뜻이지, 앱이 슬라이스를 잃었다는 뜻이 아닙니다.

프로젝트 11개에 실제로 들어 있는 것

Xcode 프로젝트 11개, 타깃 44개를 대상으로 점검을 돌렸습니다. 여덟 개 프로젝트가 macOS 타깃을 최소 하나 갖고 있고, 21개 타깃이 macOS용으로 빌드되며, 새 기본값의 영향을 받는 타깃은 오늘 기준 하나도 없습니다.¹⁴

전체를 통틀어 가장 높은 macOS 배포 타깃은 26.5이고, 가장 낮은 것은 한동안 아무도 손대지 않은 Safari 확장의 13.0입니다. 27.0을 넘는 타깃은 하나도 없으므로, 누군가 손으로 숫자를 올리기 전까지는 어떤 타깃도 기본값이 바뀌는 영역에 들어가지 않습니다. ARCHS를 설정한 타깃은 0개, EXCLUDED_ARCHS를 설정한 타깃도 0개이며, 전체에 .xcconfig 파일은 단 하나도 없습니다. 즉 44개 타깃의 모든 아키텍처 결정이 ARCHS_STANDARD에서 나옵니다.¹⁴

아카이브 증거가 설정 증거보다 강합니다. 아카이브는 실제로 출시된 것을 기록하기 때문입니다. 제 기계에는 2026년 4월부터 7월 사이에 빌드된 아카이브 79개가 있습니다. 서로 다른 일곱 개 제품에 걸친 macOS 아카이브 51개 전부가 x86_64 arm64를 보고합니다. iOS 계열 아카이브 28개는 전부 arm64를 보고합니다.¹⁴ 이 프로젝트들 중 어디에서도 누군가 Universal을 고른 적이 없습니다. 기본값이 매번 그렇게 만들어냈을 뿐입니다. 바로 이 집단이 Apple의 변경이 작용하는 대상이고, 아무도 알아차리지 못할 이유이기도 합니다.

솔직하게 남는 한 가지 공백이 있습니다. 배포 타깃을 27.0으로 올리는 것은 의도적인 행위이고, 제 프로젝트 중에는 아직 그럴 이유가 있는 것이 없습니다. 이 깨끗한 결과는 정책이 아니라 한 시점을 측정한 것입니다.

Intel 소프트웨어가 실제로 끝나는 지점

Xcode의 변경은 빌드 안의 아키텍처에 관한 것입니다. 하나의 범주로서 Intel 소프트웨어가 끝나는 지점은 macOS 28이며, Apple은 이를 Rosetta 문서와 macOS 27 릴리스 노트에 나눠 적어두었고 두 문서는 서로 일치합니다.

Apple의 Rosetta 문서는 시한을 직접 못 박습니다. Rosetta는 Intel 앱을 위한 범용 도구로서 macOS 27까지 제공된다고 적혀 있습니다. “was designed to make the transition to Apple silicon easier, and will be available through macOS 27” 그리고 그 이후로는 Intel 기반 프레임워크에 의존하는, 관리가 끊긴 옛 게임을 지원하기 위한 일부 기능만 남긴다고 덧붙입니다. “Beyond this timeframe, we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks.”⁷ macOS 27 릴리스 노트는 같은 예외 조항을 달아 그 결과를 서술합니다. 레거시 게임을 제외한 모든 Intel 기반 소프트웨어가 macOS 28.0과 호환되지 않는다는 것입니다. “All Intel-based software will no longer be compatible with macOS 28.0, excluding legacy games.”¹⁰ 같은 노트의 다른 곳에 있는 베타 전용 명령 하나가 그 예외의 실체를 보여줍니다. sudo game-test-tool enable은 레거시 Intel 게임 지원을 켜는데, Apple은 레거시 게임 지원을 켜면 Rosetta가 꺼진다고 경고합니다(“enabling legacy game support disables Rosetta”).¹⁵

macOS 27은 그 사이 기간을 살아남지 못할 것들을 지목하는 데 씁니다. Apple의 Deprecation Information 섹션은 macOS 28.0에서 더는 실행되지 않을 Intel 기반 애플리케이션에 이제 정보 가져오기(Get Info) 창에서 별도 표시가 붙는다고 알립니다. “Intel-based applications that will no longer run in macOS 28.0 now display a treatment in Get Info.” 별도 항목은 설정 > 일반에 macOS 28.0과 호환되지 않을 Intel 기반 앱이 목록으로 표시된다고 덧붙입니다. “Settings > General now lists Intel-based apps that will be incompatible with macOS 28.0.” 그 목록에는 시스템에서 발견된, 사용하지 않는 Intel 기반 소프트웨어(“unused Intel-based software discovered on the system”)까지 들어갑니다.⁸⁹

Mac 제품을 출시하는 사람에게는 더 조용한 항목 세 가지가 오히려 더 중요합니다.

Rosetta 자체가 더는 눌러앉지 않습니다. 이전에 Rosetta를 설치했더라도 macOS 27.0으로 업그레이드한 뒤에는 자동으로 복원되지 않습니다. “If Rosetta was previously installed, it is not automatically restored after upgrading to macOS 27.0.”¹¹ Apple 문서가 그 맥락을 채워주는데, macOS 27은 ARM 가상 머신 안의 Intel Linux 바이너리와 Intel Linux 컨테이너를 지원하기 위해 Rosetta를 설치하지 않고도 Intel 바이너리 변환을 시스템에 직접 통합한다고 밝힙니다. “directly integrates support for Intel binary translation, without needing to install Rosetta.”⁷ 사용자가 고정해둔 앱도 달라집니다. 이전에 “Open using Rosetta”로 설정해둔 애플리케이션은 이제 네이티브로 실행되며(“have the application launch natively”), Apple은 과거에 Rosetta가 필요했던 호환성 문제라면 macOS 27에서 다시 점검해보라고 권고합니다. “Any compatibility issues requiring Rosetta from the past should be re-assessed on macOS 27.”¹²

설치 프로그램은 기본값이 바뀝니다. hostArchitecture를 지정하지 않은 설치 패키지는 이제 arm64를 기본값으로 삼습니다. “Installer packages which specify no hostArchitecture will now default to arm64.” 그리고 Apple은 설치 전후 스크립트가 arm64에서도 의도대로 동작하는지 확인하라고 요청합니다. “Ensure any pre and post install scripts behave as intended under arm64.”¹¹ App Store 밖에서 배포되는 Mac 제품이라면 앱이 Universal이든 아니든 이 변경을 그대로 물려받습니다.

가장 날이 선 부분은 플러그인을 호스팅하는 쪽입니다. Apple은 Intel 기반 플러그인과 로더가 설정에 나타나지 않거나 비호환 알림을 띄우지 않을 수 있다고 경고하면서(“Intel-based plugins and loaders may not appear in Settings or trigger notifications of their incompatibility.”), 손으로 직접 확인할 디렉터리들을 짚어주는데, 여기에는 ~/Library/Audio/Plug-Ins/, ~/Library/Printers/, ~/Library/ColorPickers/가 포함됩니다.¹⁰ 플러그인 하나가 멀쩡한 네이티브 앱의 발목을 잡을 수 있는 이유는 Apple의 Rosetta 문서에 나옵니다. 시스템은 한 프로세스 안에서 arm64 코드와 x86_64 코드를 섞는 것을 막고, Rosetta 변환은 프로세스가 동적으로 로드하는 모든 코드 모듈을 포함해 프로세스 전체에 적용됩니다. “The system prevents you from mixing arm64 code and x86_64 code in the same process. Rosetta translation applies to an entire process, including all code modules that the process loads dynamically.”⁷ 따라서 Intel 플러그인 하나가 호스트 전체를 변환 실행으로 끌어내리고, 관리가 끊긴 부품 하나를 Apple이 축소 일정을 잡아둔 기능에 대한 앱 전체의 의존으로 바꿔놓습니다.

Universal이 존재하는 이유는 macOS 12부터 27까지를 돌리는 Intel Mac에 닿기 위해서이고, 그 범위는 Apple이 Xcode 27용으로 공개한 호환성 표에 그대로 나와 있습니다.⁴ Apple은 Intel 소프트웨어의 종료 시점을 macOS 28로 못 박았고 배포 범위는 건드리지 않았으므로, macOS 팀이 실제로 던져야 할 질문은 “우리 사용자 중 아직 그 슬라이스가 필요한 Mac을 쓰는 사람이 얼마나 되는가”입니다.

확인했지만 찾지 못한 것이 두 가지 있습니다. Xcode 27 릴리스 노트도 macOS 27 릴리스 노트도 Mac App Store의 Universal Purchase 요건 변경에 관해서는 아무 말이 없고, 어느 쪽도 macOS 28의 날짜를 못 박지 않았습니다.³⁶ 어디선가 날짜를 봤다면 그것은 추론으로 취급하세요.

FAQ

Xcode 27을 쓰면 Intel 앱을 출시할 수 없나요?

아닙니다. Apple은 Intel Mac을 개발 기계에서 지원 중단 대상으로 올린 바로 그 항목에서 정반대를 말합니다. macOS 27 SDK는 Universal(Intel과 Apple Silicon) 앱을 macOS 12 이상으로 하위 배포하는 것을 지원한다는 것입니다. “The macOS 27 SDK supports back deploying Universal (Intel and Apple Silicon) apps to macOS 12 and later.”² Apple의 호환성 표도 그 범위를 확인해주며, Xcode 27 beta 4의 배포 타깃으로 macOS 12부터 27까지를 명시합니다.⁴ 바뀌는 것은 기본값입니다. macOS 배포 타깃이 27.0에 도달한 타깃은 ARCHS_STANDARD에서 x86_64를 더는 받지 못하며, Apple이 밝힌 해결책은 ARCHS에 x86_64를 직접 추가하는 것입니다.¹ Intel 출시는 물려받는 것이 아니라 선언하는 선택이 됩니다.

ARCHS_STANDARD에서 x86_64가 빠지면 빌드가 실패하나요?

Apple의 항목 어디에도 오류나 경고, 어떤 종류의 진단도 언급되어 있지 않습니다. Apple이 서술하는 것은 기본값의 변경입니다. macOS 또는 DriverKit 27.0 이상의 타깃은 기본값으로는 Universal 빌드를 만들지 않습니다. “will not build Universal by default.”¹ 슬라이스 두 개 대신 하나로 컴파일되고 링크되고 서명되는 빌드도 유효한 빌드이며, Xcode 27이 사용을 요구하는 Apple silicon Mac에서는 그 차이가 런타임에 보이지 않습니다.² Apple은 기본값만 말하고 그 결과는 적지 않았으므로, “조용하다”는 표현은 Apple이 아니라 제 것입니다. 빌드 로그가 이 주제를 꺼내주기를 기다리지 말고, 아카이브된 바이너리에 lipo -archs를 걸어 확인하세요.

Xcode 26에서 새 동작을 테스트할 수 있나요?

없습니다. Xcode 26.6(빌드 17F113)에서 직접 확인했습니다. macOS 전용 프로젝트에서 MACOSX_DEPLOYMENT_TARGET을 27.0으로 덮어써도 ARCHS_STANDARD = arm64 x86_64로 해석되며, 이는 같은 명령을 26.0으로 실행했을 때와 동일합니다.¹³ 이전 툴체인은 이 임계값을 구현하지 않았으므로, Xcode 26에서 빌드 설정을 아무리 실험해도 이 변경을 미리 볼 수는 없습니다. Xcode 26.6이 재현해주는 것은 범위 제한 쪽입니다. 같은 프로젝트가 iOS SDK 기준으로는 ARCHS_STANDARD = arm64, macOS SDK 기준으로는 arm64 x86_64로 해석되는데, 이는 macOS와 DriverKit 배포 타깃만 지목하고 그 밖에는 아무것도 언급하지 않은 항목과 맞아떨어집니다.¹¹³

이제 Apple silicon Mac이 꼭 필요한가요?

Xcode 27을 실행하려면 그렇습니다. 단서는 없습니다. Xcode 27은 Apple silicon Mac에서만 설치되고 실행됩니다. “Xcode 27 will only install and run on Apple silicon Macs.”² Apple은 하드웨어 요구 사항 위에 소프트웨어 하한선까지 얹어 Xcode 27 beta 4에 macOS Tahoe 26.4 이상을 요구합니다.⁴ Intel 개발은 이전 툴체인에서 살아남으며, Apple도 그렇게 설명합니다. Rosetta를 지원하는 macOS 버전, 예컨대 macOS 27에서는 Intel 개발이 여전히 가능하다는 것입니다. “Intel development is still possible with macOS versions that support Rosetta like macOS 27.”² Apple의 Rosetta 문서는 그 경로에 경계를 그어, Rosetta가 범용 도구로서는 macOS 27까지 제공되고(“will be available through macOS 27”) 이후에는 관리가 끊긴 옛 게임을 겨냥한 축소된 일부만 남는다고 밝힙니다.⁷

핵심 정리

macOS 앱 개발자라면: - 먼저 -sdk 플래그 없이 점검하고, SUPPORTED_PLATFORMS와 SDKROOT를 함께 읽으며, 타깃이 애초에 macOS용으로 빌드되는지 물을 때는 MACOSX_DEPLOYMENT_TARGET을 무시하세요. Xcode는 iOS 전용 프로젝트에도 macOS 배포 타깃을 써넣습니다. 제 프로젝트 중 셋이 Mac용으로는 전혀 빌드하지 않으면서도 값을 하나씩(26.5, 26.5, 26.2) 보고합니다.¹⁴ - 설정을 해석하기 전에 xcodebuild -list로 타깃을 열거하세요. 제 Safari 확장에 프로젝트 수준 조회를 걸었더니 iOS 전용 프로젝트라고 보고하면서 macOS 타깃 두 개를 감췄습니다.¹⁴

사용자 중에 Intel Mac 사용자가 있는 팀이라면: - x86_64를 물려받지 말고 명시적으로 결정하세요. macOS 배포 타깃을 27.0으로 올릴 때는 ARCHS를 설정하세요. Apple의 항목이 제시하는 해결책이 정확히 그것이고, 건너뛰어도 경고는 없습니다.¹ - 확인은 빌드 설정도, 아카이브의 Info.plist도 아닌 아카이브된 바이너리에 lipo -archs를 걸어서 하세요. 제 아카이브 두 개는 아키텍처 메타데이터가 아예 없으면서도 바이너리는 Universal입니다.¹⁴

릴리스 담당자라면: - 하드웨어 마감과 출시 마감을 분리하세요. Xcode 27은 첫날부터 Apple silicon Mac을 요구하지만, Universal 산출물은 macOS 12 이상까지 살아남고, Apple은 macOS 28의 날짜를 아직 공개하지 않았습니다.²⁴ - 앱만이 아니라 Intel 플러그인과 설치 패키지까지 목록으로 만드세요. Apple은 Intel 플러그인이 설정에 나타나지 않을 수 있다(“may not appear in Settings”)고 경고하고, Intel 플러그인 하나가 호스트 프로세스 전체를 변환 실행으로 끌어내립니다.⁷¹⁰

27 사이클은 눈에 띄지 않는 자리에 결과가 큰 변경을 계속 숨겨두고 있습니다. 링커 제거와 모듈 이름 규칙은 툴체인을 올리는 순간 빌드를 아예 깨뜨리고, @State 매크로는 소스 수준에서 빌드를 깨뜨리며, 실행 화면 키는 제출을 막습니다. Intel 기본값 변경은 아무것도 깨뜨리지 않으면서 제품을 바꿔놓기 때문에, 업그레이드한 뒤가 아니라 업그레이드하기 전에 점검할 가치가 있습니다. 시리즈 전체 허브는 Apple 생태계 시리즈입니다.

참고 자료