33 · Swift 6.3 델타

Part C의 마지막 챕터다. Swift 6.3은 2026년 3월 24일에 릴리스됐고, 이 강의의 나머지가 기준으로 삼은 6.2.1보다 한 세대 위다. 그래서 이 챕터의 목적은 둘이다 — ① 6.3이 실제로 무엇을 바꿨는지 제안 단위로 빠짐없이 정리하고, ② 그중 무엇이 이 강의의 다른 챕터를 갱신해야 하는지 짚는 것이다. 후자가 특히 중요하다 — 새 기능 목록은 릴리스 노트에도 있지만, "내가 알고 있던 것 중 무엇이 낡았는가"는 아무도 알려주지 않는다.

Q1. Swift 6.3은 무엇을 바꿨는가? — 언어 제안 9개 전수

원리

Swift의 릴리스는 제안(Swift Evolution proposal) 단위로 추적할 수 있다. 각 제안 문서의 머리에 Status: 필드가 있고, 구현되면 어느 버전에 들어갔는지가 그 자리에 기록된다. 그래서 "이 릴리스가 무엇을 바꿨나"를 정확히 알고 싶으면 릴리스 노트가 아니라 제안 저장소를 세는 것이 낫다 — 릴리스 노트는 편집자가 고른 하이라이트라 빠지는 항목이 있다.

$ gh api repos/swiftlang/swift-evolution/tarball/main > se.tar.gz
$ tar xzf se.tar.gz && cd swiftlang-swift-evolution-*/proposals
$ ls *.md | wc -l
546

$ grep -l "Implemented (Swift 6.3)" *.md

내부 동작

9개를 성격별로 묶고, 각각이 이 강의의 어느 챕터와 연결되는지 함께 표시한다.

세 항목이 "직접 갱신 대상"으로 표시됐다. 이는 이 강의의 해당 문항이 6.2.1 기준으로 설명한 제약이 6.3에서 사라졌다는 뜻이며, Q4에서 하나씩 다룬다.

실험 · 도구

이 챕터에서 측정할 수 있는 것은 "6.2.1이 이 기능들을 거부한다"다. 각 기능을 6.2.1에서 컴파일하면 어떤 진단이 나오는지 실측했다 — 이것이 곧 "이 기능이 6.3에 들어왔다"는 간접 증거다.

① weak let (SE-0481)
   class Holder { weak let ref: Node? }
   → error: 'weak' must be a mutable variable, because it may change at runtime

② @c (SE-0495)
   @c func myFunc(_ x: Int32) -> Int32 { x * 2 }
   → error: unknown attribute 'c'

③ @specialized (SE-0460)
   @specialized(where T == Int) func f<T: Numeric>(_ x: T) -> T { x + x }
   → error: unknown attribute 'specialized'

④ @inline(always) (SE-0496)
   @inline(always) func g(_ x: Int) -> Int { x + 1 }
   → error: unknown option 'always' for attribute 'inline'

⑤ @section / @used (SE-0492)
   @section("__DATA,mysection") @used let marker: Int = 42
   → error: unknown attribute 'section'
   → error: unknown attribute 'used'

⑥ 모듈 셀렉터 (SE-0491)
   let x = Swift::print
   → error: consecutive statements on a line must be separated by ';'
   → error: expected expression

①의 진단문이 특히 정보량이 많다. 'weak' must be a mutable variable, because it may change at runtime — SE-0481이 없앤 제약의 원래 이유가 에러 메시지에 그대로 적혀 있다. Q4에서 이 이유가 왜 더 이상 유효하지 않은지 다룬다.

⑥의 진단이 "unknown attribute"가 아니라 구문 에러인 것도 의미가 있다. ::는 애트리뷰트가 아니라 문법(grammar) 확장이므로, 옛 컴파일러는 그것을 두 개의 별개 문장으로 해석하려 한다.

프로젝트 적용

① 업그레이드 판단은 "이 9개 중 내가 지금 아픈 것이 있는가"로 한다. 팀별로 답이 갈린다.

② 6.3은 언어 기능 외에도 도구 쪽이 넓게 움직였다. 릴리스 노트가 언급하는 것 중 실무에 닿는 항목은 이렇다 — Swift Testing의 새 기능(경고 수준 이슈 severity: .warning, Test.cancel(), 이미지 첨부), 공식 Android SDK, Embedded Swift용 EmbeddedRestrictions 진단 그룹, DocC의 마크다운 출력, SwiftPM의 swift package show-traits. 언어 제안 9개보다 이쪽이 팀에 더 큰 변화일 수 있다.

③ 업그레이드 절차는 이 강의의 다른 챕터와 같은 규율을 따른다 — 30장 Q4에서 본 것처럼 툴체인 버전과 배포 타깃을 분리해 확인하고, 29장 Q5처럼 새 진단은 모듈 단위로 점진 도입한다.

꼬리 질문

Q2. @c(SE-0495)와 모듈 셀렉터(SE-0491)는 각각 무슨 문제를 푸는가?

원리

두 제안의 공통점은 "이미 하고 있던 일을 정식 문법으로 승격"이다. @_cdecl은 밑줄 접두사가 붙은 비공식 애트리뷰트였지만 널리 쓰여 왔다 — 제안서 자체가 "실험 상태였지만 광범위하게 사용되어 왔으므로 명확성을 위해 이 문서에서 언급한다"고 밝힌다. 이름 충돌 회피 역시 그동안 typealias를 두거나 한쪽 모듈만 import하는 우회로 해결해 왔다.

비공식 상태의 대가는 13장에서 본 문제 그대로다 — 밑줄 애트리뷰트는 언제든 바뀌거나 사라질 수 있고, 동작이 문서화되지 않아 코너 케이스가 불명확하다. 정식화는 그 동작을 계약으로 고정하는 작업이다.

내부 동작

@c가 하는 일은 세 갈래다.

방향을 헷갈리지 않는 것이 중요하다. 16장이 다룬 것은 Swift가 ObjC/C를 부르는 방향이었고, @c는 C가 Swift를 부르는 반대 방향이다.

모듈 셀렉터는 훨씬 단순하다. 제안서의 표현대로 "선언을 참조하기 위해 식별자가 쓰이는 모든 자리"에서 ModuleName:: 접두사를 허용한다.

import LibraryA      // Widget 을 노출한다
import LibraryB      // Widget 을 노출한다

// 6.2 이전: 모호해서 컴파일 에러 → typealias 나 한쪽만 import 로 우회
// let w = Widget()

// 6.3: 어느 모듈의 것인지 못 박는다
let a = LibraryA::Widget()
let b = LibraryB::Widget()

실험 · 도구

6.2.1에서 두 기능이 어떻게 거부되는지가 이 절의 유일한 실측이다.

$ cat z.swift
@c func myFunc(_ x: Int32) -> Int32 { x * 2 }

$ swiftc -O -c z.swift
z.swift:1:2: error: unknown attribute 'c'

$ cat ms.swift
import Foundation
let x = Swift::print

$ swiftc -O -c ms.swift
ms.swift:2:14: error: consecutive statements on a line must be separated by ';'
ms.swift:2:14: error: expected expression

6.2.1에서 같은 목적을 달성하려면 지금도 @_cdecl을 쓸 수 있다. 다만 밑줄 애트리뷰트이므로 13장의 경고가 적용된다 — 공식 지원 대상이 아니다.

@_cdecl("my_func")
func myFunc(_ x: Int32) -> Int32 { x * 2 }
// C 쪽: int32_t my_func(int32_t);  ← 헤더를 손으로 선언해야 했다

프로젝트 적용

① @c가 실질적으로 바꾸는 것은 헤더 관리다. @_cdecl 시절에는 C 쪽 선언을 손으로 유지해야 했고, 시그니처가 어긋나면 컴파일은 통과하고 실행 중에 깨졌다 — 29장의 언어로 말하면 "조용한 실패"다. @c는 선언을 생성된 헤더에 넣어주므로 그 불일치가 구조적으로 사라진다.

// Swift 쪽
@c func compute_checksum(_ bytes: UnsafePointer<UInt8>, _ count: Int32) -> UInt8 {
    var x: UInt8 = 0
    for i in 0..<Int(count) { x ^= bytes[i] }
    return x
}

// C 쪽 — 생성된 호환성 헤더를 include 한다 (손으로 선언하지 않는다)
// #include "MyModule-Swift.h"
// uint8_t r = compute_checksum(buf, len);

다만 위 시그니처는 29장의 계약을 그대로 짊어진다 — UnsafePointer를 받으므로 C 쪽이 유효한 수명의 포인터를 넘길 책임이 있고, Swift 쪽은 그 포인터를 함수 밖으로 내보내면 안 된다. @c 경계는 Span(30장)이 통하지 않는 자리이므로 -strict-memory-safety로 그 지점을 표시해두는 편이 좋다.

② 모듈 셀렉터는 "쓸 일이 없기를 바라는" 기능이다. 이름 충돌은 대개 설계 신호다 — 두 모듈이 같은 이름을 노출한다면 그중 하나를 감싸거나 이름을 바꾸는 것이 근본 해결이다. 셀렉터가 값을 만드는 자리는 내가 고칠 수 없는 의존성 두 개가 충돌할 때다(서드파티 SDK 두 개, 또는 모듈 이름과 타입 이름이 같은 경우).

// ✅ 고칠 수 없는 서드파티 두 개가 충돌
let client = VendorA::HTTPClient()

// ✅ 모듈 이름과 타입 이름이 같아 생기는 고전적 모호성
let v = MyLib::MyLib()

// ❌ 내 모듈끼리 충돌한다면 셀렉터가 아니라 이름을 고친다
// let x = MyFeature::Model()   → Model 을 UserModel 로 개명하는 것이 낫다

③ 도입 순서는 @c가 먼저다. @_cdecl을 쓰고 있는 코드가 있다면 6.3 업그레이드와 함께 @c로 옮기는 것이 기술 부채 정리에 해당한다 — 비공식 애트리뷰트 의존을 하나 없애고, 헤더 수동 관리도 함께 없앤다.

꼬리 질문

Q3. 성능 제어 3종 — @specialized · @inline(always) · 정의 가시성은 무엇이 다른가?

원리

왜 세 개가 필요한가. 최적화가 일어나려면 세 조건이 각각 성립해야 하고, 그동안 그 조건들을 개별적으로 제어할 방법이 없었다.

첫 줄이 나머지의 전제다. 제안서 SE-0497의 설명이 이 구조를 정확히 짚는다 — 호출자가 정의를 볼 수 있으면 특수화·인라이닝뿐 아니라 분석도 가능해진다. 예로 "객체를 함수에 넘기는데 그 함수가 객체를 공유하지도 파괴하지도 않는다"는 것을 알면 호출자가 그 객체를 힙 대신 스택에 할당할 수 있다.

내부 동작

SE-0497이 이 강의의 기존 설명을 어떻게 정밀화하는지가 이 절의 핵심이다. 13장 Q2는 @inlinable·@usableFromInline·@frozen과 라이브러리 진화의 관계를 다뤘다. 6.3의 제안서는 그 개념을 두 축으로 분해한다.

@specialized는 다른 문제를 푼다. Part A 08장 Q5는 특수화의 조건을 이렇게 정리했다 — "컴파일러가 함수 본문과 호출부의 구체 타입을 동시에 볼 수 있을 때만" 일어나고, 그래서 모듈 경계를 넘으면 @inlinable로 본문을 노출해야 크로스모듈 특수화가 가능해진다. 여기서 본문 가시성이 조건에 이미 들어 있다는 점이 SE-0497과 곧바로 이어진다. 그런데 그 조건을 만족시킬 수 없는 경우가 실무에 남는다 — 본문을 공개하고 싶지 않거나(ABI 자유를 지키려고), 실존 타입(any)을 거쳐 호출되는 경우다. @specialized는 그때를 위해 함수 작성자가 미리 특정 타입용 버전을 만들어두게 한다.

@specialized(where T == Int)
@specialized(where T == Double)
public func process<T: Numeric>(_ values: [T]) -> T {
    values.reduce(0, +)
}
// 호출 지점에서 T 를 못 봐도, 런타임에 T == Int 면 사전 특수화 버전으로 재디스패치된다

실험 · 도구

$ swiftc -O -c z.swift
z.swift:1:2: error: unknown attribute 'specialized'
z.swift:1:2: error: unknown option 'always' for attribute 'inline'
z.swift:1:31: error: unknown attribute 'used'
z.swift:1:2: error: unknown attribute 'section'

④의 진단이 특히 정확하다. @inline은 6.2.1에도 이미 존재하는 애트리뷰트다 — @inline(never)와 @inline(__always)(밑줄 두 개)가 있었다. SE-0496이 한 일은 밑줄 없는 정식 옵션 always를 추가한 것이며, 그래서 에러가 "unknown attribute"가 아니라 unknown option 'always' for attribute 'inline'이다.

@inline(never)     func a(_ x: Int) -> Int { x + 1 }   // 정식 — 6.2.1 OK
@inline(__always)  func b(_ x: Int) -> Int { x + 1 }   // 비공식 — 6.2.1 OK
@inline(always)    func c(_ x: Int) -> Int { x + 1 }   // 6.3부터

프로젝트 적용

① 세 애트리뷰트 모두 "측정 후에" 쓴다. 이 강의가 반복해온 규율이며, 특히 여기서 중요하다 — 세 개 다 코드 크기와 빌드 시간을 대가로 하기 때문이다.

② 순서가 있다. 정의 가시성이 최적화의 전제이므로, "왜 특수화가 안 되지?"라는 질문의 답은 대개 "호출자가 정의를 못 본다"다. 그러니 @specialized·@inline(always)를 뿌리기 전에 모듈 구조와 가시성을 먼저 본다 — 08장 Q5·13장 Q2가 그 배경이다.

# 1) 특수화가 실제로 일어나는지 SIL 에서 확인한다
swiftc -O -emit-sil file.swift | grep -E "^sil .*specialized|function_ref.*specialized"

# 2) 같은 모듈로 옮기거나 WMO 를 켜서 해결되는지 본다 (07장 Q3)
swiftc -O -whole-module-optimization *.swift

# 3) 그래도 안 되면 @specialized / SE-0497 을 검토한다

③ 라이브러리 저자에게는 SE-0497이 세 개 중 가장 중요하다. @inlinable을 "성능을 위해 붙이는 것"으로 이해하고 공개 API에 넓게 붙였다면, 그것은 되돌릴 수 없는 ABI 약속을 광범위하게 한 것이다. 6.3의 분리된 제어는 그 결정을 함수 단위로 다시 저울질할 기회를 준다 — 다만 이미 배포된 @inlinable은 되돌릴 수 없으므로, 이 이야기는 앞으로 추가할 API에 적용된다.

꼬리 질문

Q4. 6.3은 이 강의의 어느 문항을 갱신하는가?

원리

weak let이 왜 금지됐었는지가 이 절의 출발점이다. 06장 Q5에서 본 대로 weak 참조는 대상 객체가 해제되면 자동으로 nil이 된다. 즉 내가 대입하지 않아도 값이 바뀌는 것처럼 보인다. Swift는 그것을 이유로 weak에 var를 요구해 왔고, 6.2.1의 진단문이 그 이유를 그대로 말한다.

$ cat z.swift
class Node {}
class Holder { weak let ref: Node?; init(_ n: Node) { ref = n } }

$ swiftc -O -c z.swift
z.swift:2:25: error: 'weak' must be a mutable variable,
              because it may change at runtime

그런데 SE-0481은 이 규칙이 다른 곳에서 대가를 만들었다고 지적한다 — 제안서의 표현대로, weak가 반드시 가변이어야 하므로 그런 참조를 가진 클래스와 클로저는 동시성 문맥 사이에 공유하기 안전하지 않았다. Sendable 검사(17장)는 가변 저장 프로퍼티를 위험으로 보기 때문이다. 즉 "런타임에 nil이 될 수 있다"는 성질 때문에 붙인 문법 제약이, Swift 6 동시성에서 훨씬 큰 마찰로 자라난 것이다.

내부 동작

여기서 개념 구분이 하나 필요하다. weak 참조가 nil이 되는 것은 런타임 시스템이 하는 일이고, let/var는 내 코드가 대입할 수 있는가에 관한 것이다. 두 가지가 원래 별개였는데 그동안 묶여 있었다.

final class Coordinator: Sendable {
    // 6.3: 재대입 불가 + 런타임 nil 은 그대로 → Sendable 검사가 통과하기 쉬워진다
    weak let parent: Node?
    init(parent: Node?) { self.parent = parent }
}

// 6.2.1 에서 같은 코드는:
// error: 'weak' must be a mutable variable, because it may change at runtime

실험 · 도구

두 번째 갱신 대상인 Codable 에러 출력(SE-0489)은 6.2.1의 현재 상태를 측정해 두는 것이 유용하다. 제안서는 기본 설명이 "유용한 정보를 읽기 어려운 형식에 묻어둔다"고 지적하는데, 내 툴체인에서 실제로 어떤지 확인해 보면 이렇다.

import Foundation
struct S: Decodable { let a: Int }
do { _ = try JSONDecoder().decode(S.self, from: Data("{}".utf8)) }
catch {
    print(String(describing: error))
    print(error.localizedDescription)
    print(error is CustomDebugStringConvertible)
}

DecodingError.keyNotFound: Key 'a' not found in keyed decoding container.
Debug description: No value associated with key
CodingKeys(stringValue: "a", intValue: nil) ("a").

The data couldn’t be read because it is missing.

true

프로젝트 적용

① weak let은 Swift 6 마이그레이션 중이라면 즉시 값을 만든다. 특히 델리게이트·부모 참조를 가진 타입을 Sendable로 만들려다 막혔던 자리가 대상이다.

// ① @unchecked Sendable — 17장 Q2 의 경고가 적용된다 (상속 계층에서 위험)
final class A: @unchecked Sendable { weak var parent: Node? }

// ② 약한 참조를 actor 안으로 옮긴다
actor B { weak var parent: Node? }

// ③ 참조를 아예 들지 않고 필요할 때 조회한다 (가장 안전하지만 구조 변경)
final class C: Sendable { let parentID: UUID }

// 6.3: weak let 으로 ①의 @unchecked 없이 해결되는 경우가 생긴다

② 갱신 지도를 표로 남겨둔다. 이 강의를 읽는 순서와 무관하게, 6.3 이상 툴체인을 쓰는 독자가 어디를 고쳐 읽어야 하는지가 이 표다.

③ 이 표를 만드는 습관 자체가 이 절의 진짜 교훈이다. 릴리스마다 "새 기능"은 널리 소개되지만 "내가 알던 것 중 무엇이 낡았는가"는 스스로 대조해야 한다. 방법은 Q1의 절차 그대로다 — 제안 목록을 뽑고, 내 코드베이스·내 지식에서 그것이 닿는 지점을 표로 만든다.

꼬리 질문

Q5. Swift 6.4는 무엇을 준비하고 있는가?

원리

제안의 Status가 Implemented (Swift 6.4)라는 것은 "main 브랜치에 구현이 들어갔고 다음 릴리스에 실릴 예정"이라는 뜻이다. 릴리스가 확정된 것이 아니므로 두 가지 유보가 붙는다 — 릴리스 시점에 빠질 수 있고, 세부 문법이 다듬어질 수 있다. 30장 Q5에서 실측한 @lifetime → @_lifetime, LifetimeDependence → Lifetimes 이름 변경이 그 실제 사례다.

내부 동작

24개 중 이 강의에 닿는 것을 골라 챕터와 연결한다.

흐름이 하나 보인다. Part C가 다룬 문제들의 후속이 6.4에 몰려 있다 — Span 계열의 안전한 API(SE-0525), ~Copyable 원소를 담는 컨테이너와 표준 프로토콜의 화해(SE-0499), _read/_modify의 정식화(SE-0507). 30장 Q5에서 "수명 의존성이 정식화되면 지금 클로저로 짜야 하는 API가 자연스러워진다"고 했던 방향이 실제로 진행되고 있다.

실험 · 도구

이 목록은 지금 재현 가능하다. 제안 저장소만 있으면 된다.

$ gh api repos/swiftlang/swift-evolution/tarball/main > se.tar.gz
$ tar xzf se.tar.gz && cd swiftlang-swift-evolution-*/proposals

# 다음 릴리스 예정
$ grep -l "Implemented (Swift 6.4)" *.md | wc -l
24

# 심사 중인 것 — 그다음 릴리스의 후보
$ grep -l "Active Review" *.md

# 특정 주제의 진행 상황
$ grep -l "Span\|Escapable" *.md | xargs grep -H "^\* Status" | sort -t: -k3

이 절차를 분기마다 한 번 돌리는 것이 이 강의가 권하는 습관이다. Q4 ③에서 말한 "갱신 지도를 스스로 만드는 것"의 앞단이다.

프로젝트 적용

① 프리릴리스 목록으로 코드를 쓰지 않는다. 쓸 곳은 설계 판단이다 — 지금 우회로를 만들지, 아니면 곧 오는 정식 기능을 기다릴지 결정할 때 근거가 된다.

② "곧 온다"가 기다림의 이유가 되지 않게 한다. 프리릴리스 항목은 빠질 수 있고, 나온다 해도 30장 Q4대로 배포 타깃이 올라가야 쓸 수 있는 경우가 있다. 그래서 실무 원칙은 "지금 되는 방법으로 만들고, 교체 지점을 표시해 둔다"다 — 29장 Q5의 unsafe 표기가 정확히 그 표시 역할을 한다.

③ 이 강의를 계속 쓸모 있게 유지하는 방법으로 이 챕터를 닫는다. 33개 챕터의 대부분은 릴리스와 무관하게 유효하지만(Q4 꼬리 질문), 이 챕터만은 주기적으로 다시 써야 하는 챕터다. 절차는 세 줄이다 — ① 제안 저장소에서 새 릴리스의 목록을 센다 ② 각 항목이 이 강의의 어느 문항에 닿는지 표로 만든다 ③ 그 문항에 보충을 넣고, 실측이 필요한 것은 해당 툴체인에서 다시 측정한다.

꼬리 질문

출처 · 참고자료