Swift의 새로운 기능 (2026): WWDC26 업데이트

Apple은 한 번의 WWDC 사이클에서 두 개의 Swift 릴리스를 출시했습니다. 6.3과 6.4가 함께 등장했고, “What’s new in Swift” 세션은 둘을 하나의 작업 흐름으로 다뤘습니다¹. 이 구분이 중요한 이유는, 변경 사항이 두 부류의 사용자로 깔끔하게 나뉘기 때문입니다. 대부분의 개발자는 더 작은, 일상적으로 쓰이는 편의 기능을 얻습니다(any 옵셔널 주위의 괄호를 없애고, 십수 개의 @available 플랫폼 이름을 하나의 anyAppleOS로 합치고, 정확히 한 선언에서만 deprecation 경고를 잠재우는 것 같은). 성능에 민감한 코드를 작성하는 더 작은 그룹은 수년에 걸쳐 준비된 결실을 얻습니다. 이제 소유권 시스템이 for 루프, 계산 프로퍼티, 그리고 표준 라이브러리 자체에까지 닿습니다.

2026년의 Swift는 또한 눈에 띄게 크로스 플랫폼, 크로스 언어 프로젝트입니다. Apple은 swift.org를 통해 배포되는 공식 Android용 Swift SDK⁶, WebAssembly를 통한 더 빠른 JavaScript 브리징, 새로운 @C 속성으로 Swift 함수를 다시 C로 내보내는 기능, 그리고 이제 기본적으로 Swift Package Manager를 구동하는 Swift Build 백엔드를 발표했습니다¹. 이 글은 2026년 Swift 이야기를 규정하는 네 개의 세션을 따라갑니다. 언어 및 라이브러리 업데이트(262), Swift Testing 마이그레이션 경로(267), gRPC를 활용한 실시간 서비스(265), 그리고 MLX Swift를 활용한 수치 컴퓨팅(328)입니다.

TL;DR

• Swift 6.3과 6.4가 WWDC26에서 함께 출시되었습니다. 일상적인 편의 기능: 괄호 없는 옵셔널 any/some, anyAppleOS 가용성, 선언별 경고 제어를 위한 @diagnose 속성, 그리고 이름 충돌을 위한 모듈 선택자(::)¹.
• 소유권 시스템이 일반 코드에 닿았습니다. 새로운 Iterable 프로토콜은 for 루프가 요소를 복사하는 대신 빌릴(borrow) 수 있게 하며, borrow/mutate 접근자가 get/set을 대체해 계산 프로퍼티에서 큰 값의 복사를 피합니다¹.
• 새로운 표준 라이브러리 타입들은 기존 안전하지 않은 패턴의 안전한 버전을 제공합니다. UniqueArray, UniqueBox, 단일 재개 Continuation, 그리고 빌림이나 변경을 변수에 담는 Ref/MutableRef입니다¹.
• 이제 Swift Testing은 양방향으로 XCTest와 상호 운용되며, 네 가지 모드(limited, complete, strict, none)를 갖습니다. Xcode 27은 기본적으로 상호 운용성을 활성화합니다². @Test, @Suite, #expect, #require 표면은 Apple의 Swift Testing 레퍼런스에 문서화되어 있습니다⁵.
• gRPC Swift는 .proto 파일로부터 타입이 지정된 클라이언트를 생성하고 단방향(unary)과 양방향 스트리밍 RPC를 얻으며, 클라우드의 Linux 컨테이너에 배포할 수 있는 지점에 이르렀습니다³.
• MLX Swift는 NumPy 스타일의 배열 컴퓨팅을 Swift에 가져오며, 자동 GPU 실행과 grad 자동 미분을 제공하고, Swift, Python, C++, C 프런트엔드 전반에서 하나의 엔진을 공유합니다⁴.

언어 편의성: 짜증나는 것들이 사라집니다

세션은 “작은 짜증거리들이 사라지는 정도로만 겨우 알아챌 수 있는” 변경 사항들로 시작합니다¹. 이들은 언어의 10년 동안 쌓여온 마찰을 제거하기에 짚어볼 만합니다.

Swift 팀의 Becca와 Evan이 Swift 6.3과 6.4를 안내합니다. 언어 섹션은 0:45 무렵부터 시작됩니다.

이제 괄호로 감싸지 않고 any P?를 작성할 수 있습니다. Swift Concurrency 태스크가 던져진 오류를 조용히 누락시키면 경고가 표시되어, 태스크 안에서 처리하거나 태스크를 저장해 나중에 확인하도록 유도합니다. defer 블록에서 async 함수를 호출할 수 없었던 기존 제약이 사라져, 비동기 정리(cleanup)가 지연된 동기 정리가 늘 그래왔던 것과 동일한 방식으로 실행됩니다(SE-0493, Swift 6.4)⁷. weak var 프로퍼티 때문에 @unchecked Sendable만 필요했던 클래스는 그 프로퍼티를 weak let으로 바꿔 제대로 된 Sendable 검사를 받을 자격을 얻을 수 있습니다. Sendable이 되어서는 안 되는 타입은 새로운 ~Sendable 구문으로 명시적으로 그렇게 선언할 수 있으며, 이것이 하위 클래스가 Sendable이 되는 것을 막지는 않습니다¹.

확실히 눈에 띌 두 가지 변경 사항이 있습니다. 첫 번째는 가용성입니다. Apple은 작년에 OS 버전 번호를 정렬했고, Swift는 이를 한 단계 더 밀고 나가 모든 플랫폼 이름을 하나, 즉 anyAppleOS로 압축할 수 있게 합니다. 관심 있는 플랫폼 전반에서 가용성이 일치하면 한 번에 모두를 지정하고, 예외 항목이 있으면 anyAppleOS를 기본값으로 설정한 뒤 예외에 대해 플랫폼별 속성을 추가합니다. 같은 이름이 #if os(...) 조건에서도 동작합니다¹.

두 번째는 단일 선언 내부에서 특정 경고의 동작을 변경하는 @diagnose 속성입니다. 새 API로 마이그레이션하는 동안 프로젝트 전체에서 잠재우지 않고 한 함수에서만 deprecated declaration 경고 그룹을 무시하도록 Swift에 지시할 수 있습니다. 반대 방향으로도 실행할 수 있습니다. 보안에 중요한 함수 내부에서 엄격한 메모리 안전성을 켜거나, 미래의 오류 경고를 지금 당장 오류로 승격시킬 수 있습니다¹. Swift 팀의 엔지니어링 매니저 Holly Borla는 WWDC26을 마무리하며 이를 자신의 손꼽는 기능으로 지목했습니다. “제가 가장 좋아하는 새 기능 중 하나는 @Diagnose 속성입니다. 코드에서 경고의 동작을 제어할 수 있게 해주는데, deprecation을 억제하는 것 같은 일도 할 수 있지만, 엄격한 메모리 안전성이나 엄격한 동시성 진단을 더 세밀한 단위로 선택적으로 적용하는 것도 가능합니다. 예를 들어 Swift 6 언어 모드로의 마이그레이션에 도움이 됩니다.”⁸ 그녀는 6.4 릴리스 전체를 같은 방식으로 규정했습니다. 이 업데이트들은 개발자가 자신의 아이디어를 명확하고 아름다운 코드로 표현하는 데 집중할 수 있도록 “마찰 지점이 되는 것들을 제거하는” 것이라고요⁸.

그다음으로 모듈 선택자가 있습니다. 두 개의 import된 모듈이 모두 View라는 이름의 타입을 선언할 때, 기존 해결책은 점 구문(Rocket.SaturnV)이었는데, 이는 Rocket이라는 모듈이 Rocket이라는 타입도 포함하면 망가집니다. Swift가 타입을 우선시한 다음 멤버를 찾지 못하기 때문입니다. Swift 6.3은 ::를 도입하는데, 왼쪽의 이름은 항상 모듈 이름이므로 Rocket::SaturnV는 곧바로 모듈로 향합니다. 선택자는 메서드와 프로퍼티 이름에도 동작합니다. Apple의 지침은 분명합니다. 통제할 수 없는 모듈 간의 충돌에, 그리고 매크로가 생성한 코드에서 방어적으로 사용하되, 의도적으로 충돌하도록 API를 설계한 다음 모호성 해소를 위해 선택자에 의존하지는 말라는 것입니다¹.

표준 라이브러리와 Foundation

표준 라이브러리는 표적화된 추가 기능을 갖췄습니다. 태스크 취소 보호막(withTaskCancellationShield, SE-0504, Swift 6.4)은 취소 검사가 항상 false를 반환하는 짧은 영역을 실행하므로, 디스크 쓰기 완료 같은 비동기 정리가 둘러싼 태스크가 취소된 뒤에도 여전히 실행됩니다⁷. mapKeyedValues는 키와 기존 값을 모두 매핑 클로저에 전달하여, 키가 필요할 때 mapValues가 강요했던 수동 딕셔너리 재구성을 대체합니다. Swift System에서 온 타입을 기반으로 한 새로운 파일 경로 타입은 경로 표현의 플랫폼별 차이를 처리합니다¹.

Foundation은 Objective-C에서 벗어나 Swift로 향하는 다년간의 마이그레이션을 이어갔습니다. Apple은 Data의 더 많은 부분을 현대화했고(더 빠른 span 접근, 동등성 검사, 반복, 변경), NSURL과 CFURL을 더 빠르게 실행되고 메모리를 덜 사용하는 단일 Swift 구현으로 통합했습니다. ProgressManager는 async/await를 위해 만들어진 새로운 진행 상황 보고 타입이며, Subprocess 패키지는 단순화된 실행 타입, AsyncBufferSequence로 스트리밍되는 출력, 그리고 grapheme 클러스터 경계를 존중하면서 출력을 한 줄씩 읽는 strings() 메서드와 함께 1.0에 도달했습니다¹.

소유권이 일반 코드에 닿습니다

성능 이야기야말로 면밀히 읽어볼 부분인데, 다년간의 컴파일러 프로젝트가 일상적인 타입에서 쓸 수 있는 무언가가 되는 순간을 보여주기 때문입니다. 핵심 문제는 복사입니다. 한 곳에 데이터가 있고, 다른 곳에서 필요하므로 프로그램이 그것을 복사합니다. 저장 공간이 계속 할당된 채로 유지되고 양쪽이 모두 Swift의 배타성 규칙을 따른다면, 그 복사는 불필요합니다. 빌림(borrow)은 복사 없이 기존 저장 공간에 대한 읽기 접근을 부여하고, 변경(mutate)은 배타적 쓰기 접근을 부여합니다. 컴파일러가 둘 다 컴파일 타임에 검증하며, 이것이 원시 UnsafePointer로는 안전하지 않았던 곳에서 이 기법을 안전하게 만드는 요소입니다¹.

소유권 및 성능 튜닝 섹션은 19:55 무렵에 시작하며, 인라이닝 제어, 특수화, 그리고 새로운 접근자를 다룹니다.

이제 여러 프로토콜이 복사 없이 동작합니다. Equatable, Comparable, Hashable은 noncopyable 타입에서 사용할 수 있고, Equatable과 Comparable은 non-escapable 타입으로 확장됩니다. 이제 연관 타입(associated type)도 noncopyable이거나 non-escapable일 수 있는데, 이것이 대표 기능을 가능하게 합니다. 바로 for 루프가 직접 지원하는 새로운 Iterable 프로토콜입니다¹.

모두가 아는 Sequence 프로토콜은 반복하면서 요소를 복사해 꺼냅니다. Iterable은 루프가 대신 요소를 빌리게 하며, 이는 noncopyable 요소와 함께 동작하고 객체 및 copy-on-write 타입에 대한 참조 카운팅을 건너뛴다는 뜻입니다. AsyncSequence가 그러하듯 반복 도중 오류를 던질 수 있습니다. 빌림은 변경을 금지하므로, 배타성 검사가 루프를 도는 동안 컬렉션을 변경하지 못하도록 막습니다(Sequence에서 흔한 성능 함정입니다). for 루프는 가능할 때 Sequence를 선호하고 Iterable로 폴백하며, Iterable 이터레이터는 요소를 한 번에 하나씩이 아니라 span의 배치(batch) 단위로 반환하는데, 이는 모든 것을 하나의 span으로 돌려줄 수 있는 타입에서 루프를 측정 가능할 정도로 더 효율적으로 만듭니다¹.

접근자도 같은 처리를 받았습니다. Apple의 예시는 256개의 Int로 이루어진 InlineArray를 담은 UniqueBox로, 64비트 기기에서 2킬로바이트짜리 구조체입니다. get/set을 쓰면 요소 하나를 바꿀 때 전체 배열을 꺼냈다가 다시 복사해 넣습니다. 계산 프로퍼티를 borrow 접근자(복사 없는 읽기 전용 접근)와 mutate 접근자(배타적 제자리 수정)로 전환하면 Swift가 요소 하나를 제자리에서 바꿀 수 있고, 타입이 noncopyable 값을 담을 수 있게 됩니다¹.

여러 새로운 표준 라이브러리 타입은 이전에 안전하지 않은 코드를 요구했던 패턴의 안전한 대체물을 제공합니다.

• UniqueArray는 Array처럼 동작하지만 noncopyable이라서, noncopyable 요소를 저장하고 고정 크기를 강제하지 않으면서 참조 카운팅 오버헤드를 피합니다.
• UniqueBox는 새로운 접근자를 사용하는 실제 표준 라이브러리 타입입니다.
• Continuation은 정확히 한 번만 재개하는지를 컴파일 타임에 검사하여, CheckedContinuation보다 안전하면서도 UnsafeContinuation만큼 효율적입니다.
• Ref와 MutableRef는 단일 값에 대한 Span처럼 작동합니다. 변수에 저장하고, 전달하고, 반환하고, 제네릭 타입에서 사용할 수 있는 빌림이나 변경의 컨테이너입니다. 접두사 &를 붙인 쓰기 접근으로 MutableRef를 만들며, ref는 non-escapable이므로 변수가 스코프를 벗어날 때 Swift는 접근이 끝났음을 압니다¹.

UniqueArray와 고정 용량의 RigidArray는 새로운 Containers 모듈에 들어 있으며(SE-0527, 원칙적으로 승인됨), 표준 라이브러리에 자리 잡기 전에 swift-collections 1.3을 통해 오늘 둘 다 사용할 수 있습니다⁷.

옵티마이저 제어를 위해, Swift 6.4는 오랫동안 있어온 @inline(never)에 짝을 맞추는 @inline(always)를 추가하고(클래스 메서드에서는 final과 함께 쓰세요. 오버라이드 가능한 메서드는 여전히 인라인되지 않을 수 있기 때문입니다), Swift 6.3은 @specialized를 추가하는데, 여기서 where 절은 가장 많이 쓰는 구체 타입에 대해 제네릭 함수의 특수화된 버전을 미리 생성하도록 컴파일러에 알려줍니다¹. 이것들이 필요한 경우는 드뭅니다. 필요할 때는, 세션의 표현을 빌리자면, “그것들이 있어서 다행이라고 느끼게 될 것”입니다¹.

Swift Testing: 이제 마이그레이션은 양방향입니다

Swift Testing은 현대적이고, 매크로 기반이며, 기본적으로 병렬인 테스트 라이브러리로 Xcode 16에서 출시되었습니다². 2026년의 이야기는 마이그레이션이며, 핵심 추가 기능은 테스트 프레임워크 상호 운용성, 즉 한 프레임워크의 API를 다른 프레임워크의 테스트 본문 내부에서 양방향으로 호출하는 능력입니다².

Swift Testing 팀의 Jerry가 Swift Testing 테스트에서 XCTest 헬퍼를 호출하는 것을 시연합니다. 상호 운용성 안내는 5:48 무렵부터 시작됩니다.

Apple이 권장하는 마이그레이션 전략은 바뀌지 않았습니다. 대부분의 XCTest는 그대로 두고, 새 테스트는 Swift Testing으로 작성하며, 가장 자주 손대는 것들을 마이그레이션하세요. 두 프레임워크는 이미 하나의 타깃에서 공존합니다. 새로운 점은 XCTest 위에 구축한 헬퍼 코드를 재사용할 수 있다는 것입니다. Swift Testing 테스트가 XCTFail을 감싼 assertUnique 헬퍼를 호출하면 프레임워크 간 이슈(cross-framework issue)가 발생하며, 이제 Xcode는 이를 네 가지 모드로 처리합니다².

• Limited: XCTest에서 발생한 프레임워크 간 이슈는 경고입니다. Xcode 27 이전에 만들어진 테스트 플랜은 이 모드를 상속하며, swift-tools-version: 6.3인 Swift 패키지는 기본적으로 이 모드를 따릅니다.
• Complete: 동일한 이슈들이 오류로 유지됩니다. Xcode 27은 새 프로젝트에 complete 모드를 사용하며, Swift 패키지는 swift-tools-version: 6.4 이상으로 올려서 이를 선택할 수 있습니다.
• Strict: XCTest에서 발생한 프레임워크 간 이슈가 치명적 오류로 테스트를 중단시키며, XCTest API를 교체할 모든 지점을 가리킵니다.
• None: 완전히 비활성화합니다(그 이슈들이 실제 버그를 표시할 수 있으므로 일시적으로만 사용하세요).

Swift Testing에서 발생한 프레임워크 간 이슈는 모든 모드에서 오류로 유지되므로, XCTestCase 내부에서 #expect와 #require를 안전하게 호출할 수 있습니다. 패키지에서는 SWIFT_TESTING_XCTEST_INTEROP_MODE 환경 변수(모드 이름은 소문자)로 기본값을 재정의합니다². XCTest 세션 262는 표준 라이브러리 쪽의 대응을 확인해 줍니다. 이제 Swift Testing에서 호출될 때 XCTest 단언(assertion) 실패가 테스트 이슈로 표면화되므로, 커버리지를 조용히 잃지 않으면서 마이그레이션합니다¹.

마이그레이션 쿡북은 흔한 패턴들을 다룹니다. XCTSkip은 Test.cancel이 됩니다(또는, 더 나은 방법으로, 활성화 로직을 테스트 본문 밖으로 옮기는 .enabled/.disabled 트레이트가 됩니다). continueAfterFailure = false는 실패 시 던지고 테스트를 멈추는 #require가 되어, 어떤 실패가 실행을 중단시킬지를 expectation별로 선택할 수 있게 합니다². 상호 운용성은 제한적이지만 실용적인 API 집합을 지원합니다. 모든 XCTest 단언, 두 expectation 매크로(#expect와 #require), XCTest 실패를 known으로 표시하는 known-issue API, 그리고 XCTest 케이스를 건너뛰는 Test.cancel입니다².

API 표면 자체(매크로, 트레이트 어휘, XCTest에 남는 것)에 대해서는, 컴패니언 글 Swift Testing vs. XCTest가 사고 모델을 다룹니다. 거기서 두 가지를 함께 짚고 갑니다. UI 자동화와 성능 테스트는 XCTest 전용으로 남고, Objective-C 예외를 던지는 코드는 Objective-C로 작성된 XCTest에 남아야 하는데, Swift 코드가 그런 예외를 안전하게 처리할 수 없기 때문입니다². 일단 마이그레이션하면, 매개변수화된 테스트(각 인자가 별도의 케이스이며, 모두 병렬로 실행됨)와, 종료를 검증하기 위해 자식 프로세스에서 크래시가 예상되는 코드를 실행하는 종료 테스트(exit test)를 얻으며, 이는 macOS, Linux, FreeBSD, Windows에서 사용할 수 있습니다².

gRPC Swift: 타입이 지정된 실시간 서비스

서버 이야기는 Swift가 이제 하나의 언어로 클라이언트와 백엔드를 아우른다는 점을 가장 명확하게 보여주는 사례입니다. gRPC 세션은 .proto 명세에서 완전히 생성된, Swift 서버와 통신하는 iOS 앱을 만듭니다³.

Swift Server 팀의 George가 네 가지 RPC 타입을 설명합니다. 양방향 스트리밍을 포함한 스트리밍 섹션은 11:06 무렵부터 시작됩니다.

gRPC는 Cloud Native Computing Foundation 프로젝트로, API를 HTTP 엔드포인트가 아니라 타입이 지정된 입력과 출력을 갖는 함수로 정의하고, 명세로부터 클라이언트 코드를 생성합니다³. 작업 흐름은 이렇습니다. .proto 파일에 서비스를 정의하고, grpc-swift-nio-transport(SwiftNIO 기반 네트워킹)와 grpc-swift-protobuf(빌드 플러그인)를 패키지 의존성으로 추가하고, GRPCProtobufGenerator run-build-tool 플러그인을 연결한 뒤, 다시 컴파일하여 타입이 지정된 클라이언트를 생성합니다.

ListRaces 같은 단방향 RPC는 요청 하나를 보내고 응답 하나를 받습니다. 세션의 고카트 데모는 이를 withGRPCClient로 SwiftUI 뷰에 연결한 다음, SwiftUI 환경을 통해 단일 클라이언트를 공유하도록 리팩터링하여 뷰가 연결을 재사용하게 하고, 씬이 백그라운드로 들어가면 연결을 끊습니다³. Protobuf는 메시지를 필드 이름이 아니라 필드 번호로 키가 지정된 바이너리로 직렬화하는데, 이는 메시지를 “동등한 JSON 메시지의 대략 절반 크기”로 만들며³, 열악한 모바일 네트워크에서 실질적인 이득입니다. Apple은 동일한 효율성이 자사 인프라를 구동한다고 언급합니다. gRPC Swift는 오픈 소스 Containerization 프레임워크에서 프로세스 간 통신을 구동하고, Private Cloud Compute, iCloud 키체인 및 사진, SharePlay 파일 공유를 떠받칩니다³.

스트리밍 지원이 실시간을 가능하게 하는 요소입니다. 단방향 RPC를 넘어, 클라이언트 스트리밍(여러 요청, 응답 하나), 서버 스트리밍(요청 하나, 여러 응답, 라이브 해설 피드 같은), 그리고 양방향 스트리밍이 있습니다. 데모는 라이브 레이스 업데이트에 양방향 스트리밍을 사용합니다. 클라이언트는 원하는 이벤트 타입을 스트리밍하고, 서버는 일치하는 이벤트를 스트리밍합니다. 서버 측에서 이는 요청 매개변수가 메시지의 AsyncSequence이고 응답 매개변수가 writer인 async 함수가 되며, 태스크 그룹과 뮤텍스로 보호된 구독 이벤트 타입 집합으로 처리됩니다³. 배포는 다단계 Containerfile입니다(swift:latest로 빌드하고, 릴리스 바이너리를 swift:slim으로 복사). HTTP/2로 Google Cloud Run에서 실행한 다음, 클라이언트가 전송 보안을 평문에서 TLS로 전환합니다³.

MLX Swift: 수학처럼 읽히는 수치 컴퓨팅

MLX 세션은 완전히 다른 개발자를 대상으로 합니다. 시뮬레이션, 신호 처리, 렌더링, 또는 모델 훈련을 작성하는 모든 사람입니다. MLX Swift는 NumPy가 그러하듯 n차원 배열을 중심 추상화로 사용하므로, “대부분의 NumPy 코드는 최소한의 변경으로 MLX Swift로 번역할 수 있습니다”⁴.

David Koski가 Mandelbrot 예제를 안내합니다. 일반 Swift와의 배열 컴퓨팅 비교는 4:28 무렵부터 시작됩니다.

MLX는 기존 Apple 수치 스택을 대체하기보다는 그 옆에 자리합니다. 손으로 튜닝한 CPU 벡터 프리미티브를 위한 Accelerate, 신경망 빌딩 블록을 위한 BNNS, 직접적인 GPU 커널을 위한 Metal Performance Shaders, 그리고 Complex 타입을 위한 Swift Numerics입니다. 목표가 “성능을 염두에 두고 수학적인 코드를 작성하는 것”이고 코드가 수학처럼 보이기를 원할 때 MLX Swift를 찾게 됩니다⁴.

두 가지 기능이 이를 가능하게 합니다. 지연 평가(lazy evaluation)는 배열 연산을 작성하는 동안 계산 그래프를 만들고, eval을 호출하거나 값을 읽기 전까지는 아무것도 실행하지 않습니다. 이것이 그래프를 작게 유지하기 위해 루프가 매 단계마다 eval을 호출하는 이유입니다. 지연 평가는 또한 grad 함수 변환을 통한 자동 GPU 실행과 자동 미분(automatic differentiation)을 구동합니다⁴. Mandelbrot 예제는 픽셀별 스칼라 루프를 두 줄로 압축하고(전체 그리드에 적용된 z = z * z + c, 그다음 경계 내 반복 횟수의 카운트), 기본적으로 GPU에서 실행되며, 세션은 “10배 더 빠른 것도 분명히 가능하다”고 언급합니다⁴. 열 분포 솔버는 Jacobi 반복을 단일 conv2d 호출로 표현합니다. 곡선 적합 예제는 grad를 사용해 손으로 작성한 도함수 없이 정확한 그래디언트를 계산하는데, 이는 모든 ML 모델을 훈련시키는 바로 그 아이디어입니다⁴.

MLX Swift는 MIT 라이선스 하의 오픈 소스이며, Swift Package Manager를 통해 설치할 수 있고, 동일한 연산과 지연 평가 모델을 공유하는 네 개(Swift, Python, C++, C) 중 하나의 프런트엔드이므로, “Python으로 프로토타이핑하고 Swift로 출시”할 수 있습니다⁴. 생태계에는 mlx-swift(핵심 프레임워크), mlx-swift-lm(언어 모델 구현), 그리고 mlx-swift-examples(실행 가능한 LLM, 디퓨전, 훈련 샘플)가 포함됩니다⁴. 그 주변의 온디바이스 ML 맥락에 대해서는 MLX on-device ML on Apple Silicon을 참고하세요.

무엇을 먼저 도입할 것인가

당신이 누구인지에 따라 작업의 순서를 정하세요.

앱을 출시하고 컴파일러의 성능 조정 손잡이를 거의 건드리지 않는다면, 지금 편의 기능을 도입하고 소유권 시스템은 무시하세요. 플랫폼이 일치하는 곳에서 쌓인 @available 줄을 anyAppleOS로 교체하고, 마이그레이션 도중인 정확히 그 지점에서 deprecation 경고를 잠재우는 데 @diagnose를 사용하며, 다음번에 의존성이 View 같은 이름으로 SwiftUI와 충돌할 때 모듈 선택자(::)를 꺼내세요¹.

대규모 XCTest 스위트를 유지보수한다면, 상호 운용성을 켜고 오늘부터 새 테스트를 Swift Testing으로 작성하기 시작하세요. 기존 테스트 플랜을 complete 모드로 옮겨 프레임워크 간 이슈가 놓칠 수 없는 오류가 되게 하고, XCTest 헬퍼를 미리 다시 작성하기보다 상호 운용성을 통해 재사용하며, 가장 자주 손대는 파일들을 마이그레이션하세요. UI 자동화, 성능 테스트, Objective-C 예외 테스트는 XCTest에 두세요¹².

성능에 민감한 코드를 작성한다면, 소유권 추가 기능이 핵심입니다. 큰 값을 담는 뜨거운 계산 프로퍼티를 점검하고 get/set에서 borrow/mutate로 전환하세요. 이전에 UnsafePointer로 내려갔던 곳에서는 Ref/MutableRef, UniqueArray, 그리고 단일 재개 Continuation을 살펴보세요. @inline(always)나 @specialized를 꺼내기 전에 측정하세요. 옵티마이저가 대개 옳으며, 강제하면 바이너리가 더 커지고 느려질 수 있기 때문입니다¹.

작업이 서버 측이거나 수치 관련이라면, 새로운 패키지들이 프로덕션에 바로 쓸 수 있는 진입점입니다. gRPC Swift는 .proto 파일로부터 타입이 지정된 클라이언트와 양방향 스트리밍을 제공하고, MLX Swift는 GPU 가속 배열 컴퓨팅과 수학처럼 읽히는 자동 미분을 제공합니다³⁴.

FAQ

Swift 6.3과 Swift 6.4의 차이는 무엇인가요?

Apple은 둘을 같은 WWDC26 사이클에서 개발하고 출시했으며 함께 발표했습니다. 대략적으로, Swift 6.3은 모듈 선택자(::)와 @specialized 속성을 도입했고, 첫 공식 Android용 Swift SDK를 제공했습니다. Swift 6.4는 anyAppleOS 가용성, 괄호 없는 옵셔널 any/some, for 루프를 위한 Iterable 프로토콜, borrow/mutate 접근자, @inline(always), Swift 함수를 C로 내보내는 @C 속성, 그리고 임베디드 Swift 디버깅 개선을 추가했습니다. 세션은 이 둘을 하나의 연속된 작업 본체로 다룹니다¹.

XCTest에서 Swift Testing으로 꼭 마이그레이션해야 하나요?

아니요. XCTest는 여전히 출시되고 여전히 동작하며, Apple의 권장 사항은 점진적입니다. 새 테스트는 Swift Testing으로 작성하고, 손댈 때 기존 것을 마이그레이션하세요. 테스트 프레임워크 상호 운용성은 둘이 하나의 타깃에서 공존하며 서로의 API를 호출할 수 있게 하므로, Swift Testing 테스트에서 XCTest 헬퍼를 재사용할 수 있습니다. UI 자동화, 성능 테스트, Objective-C 예외를 던지는 코드는 XCTest에 남습니다¹².

새로운 Iterable 프로토콜은 Sequence가 하지 못하는 무엇을 하나요?

Sequence는 반복하면서 요소를 복사해 꺼냅니다. Iterable은 for 루프가 대신 요소를 빌리게(borrow) 하므로, noncopyable 요소와 함께 동작하고 객체 및 copy-on-write 타입에 대한 참조 카운팅을 건너뜁니다. 한 번에 하나씩이 아니라 span의 배치 단위로 요소를 반환하여 더 효율적이며, 반복 도중 오류를 던질 수 있습니다. 빌림은 변경을 금지하므로, 루프를 도는 동안 컬렉션을 변경할 수 없습니다. for 루프는 가능할 때 Sequence를 선호하고 Iterable로 폴백합니다¹.

Accelerate나 Metal Performance Shaders 대신 MLX Swift는 언제 써야 하나요?

주된 목표가 성능을 염두에 두고 수학적인 코드를 작성하는 것이고 코드가 수학처럼 읽히기를 원하며, grad를 통한 자동 GPU 실행과 자동 미분을 원할 때 MLX Swift를 사용하세요. Accelerate는 손으로 튜닝한 CPU 벡터 프리미티브의 선택지로, BNNS는 신경망 빌딩 블록의 선택지로, Metal Performance Shaders는 직접적인 GPU 커널 접근의 선택지로 남습니다. MLX는 이들을 대체하기보다는 그 옆에 자리합니다⁴.

gRPC Swift는 백엔드 서비스 전용인가요?

아니요. WWDC 세션은 iOS 앱을 gRPC 클라이언트로 만들고, .proto 파일에서 타입이 지정된 클라이언트를 생성하며, 라이브 UI 업데이트를 구동하는 단방향과 양방향 스트리밍 RPC를 보여줍니다. Protobuf의 바이너리 인코딩은 동등한 JSON의 대략 절반 크기의 메시지를 만들어내며, 이는 열악한 모바일 네트워크에서 도움이 됩니다. Apple 또한 프로세스 간 통신과 Private Cloud Compute, iCloud 키체인 및 사진, SharePlay 파일 공유를 포함한 서비스에서 gRPC Swift를 사용합니다³.

Apple Ecosystem 클러스터

Swift의 2026년 업데이트는 Apple Ecosystem 시리즈의 나머지를 관통합니다. 테스트 모델을 분석한 Swift Testing vs. XCTest, 동시성 변경이 닿는 Observable internals in SwiftUI, 프레임워크 수준에서 what SwiftUI is made of, 그리고 수치 컴퓨팅 맥락을 위한 MLX on-device ML on Apple Silicon입니다. 이 모든 것의 허브는 Apple Ecosystem Series입니다. AI 에이전트를 루프에 두고 iOS 앱을 만드는 것에 대해서는 iOS Agent Development guide를 참고하세요.

References