32 · 타입 시스템과 API 설계

여기서부터 P2의 후반부다. 27~31장이 조용히 틀리는 값을 다뤘다면, 32~35장은 언어와 런타임이 보장하는 것의 경계를 다룬다.

이 챕터의 주제는 타입 시스템으로 무엇을 살 수 있고 무엇을 지불하는가다. 컴파일 타임 검증은 공짜가 아니다 — 표현력, API 진화 유연성, 학습 비용을 대가로 낸다. 그리고 기능이 주는 보장의 범위를 오해하면, 있지도 않은 안전을 믿게 된다.

P0 05장에서 struct/class·제네릭·any/some을 메모리와 런타임 관점에서 봤고, P0 17장에서 추상화의 비용을 다뤘다. 이 챕터는 그 위에서 API를 설계할 때 실제로 고르게 되는 선택지들을 하나씩 판정한다.

Q1. 오류를 값으로 다루는 것과 던지는 것은 어떻게 다른가?

CS 원리

에러 처리 방식은 제어 흐름에 얹느냐, 데이터에 담느냐로 나뉜다.

throws의 값어치는 전파가 자동이고 호출부에 표시된다는 점이다. try가 코드에 보이므로 실패할 수 있는 지점을 읽으면서 안다. 대신 에러를 값으로 다룰 수 없어 나중에 처리하거나 여러 개를 모을 수 없다.

Result의 값어치는 1급 값이라는 점이다. 배열에 담고, 프로퍼티에 저장하고, 다른 스레드로 넘기고, 나중에 switch로 꺼낸다.

여기서 선택 기준이 나온다 — "이 에러를 지금 이 자리에서 처리할 것인가"다. 그렇다면 throws, 아니면 Result다. 그리고 async/await가 콜백을 대체하면서 Result가 필요한 자리가 크게 줄었다.

iOS에서는

변환이 양방향이라 경계에서 갈아탈 수 있다.

// throws → Result : 값으로 담아야 할 때
let r = Result { try loadConfig() }        // Result<Config, Error>

// Result → throws : 즉시 처리로 돌아갈 때
let config = try r.get()

// 여러 결과를 모아 나중에 집계 — Result 가 아니면 불가능하다
let results = urls.map { url in Result { try load(url) } }
let failures = results.compactMap { if case .failure(let e) = $0 { return e } else { return nil } }
logger.notice("실패 \(failures.count)/\(results.count)")

동기 API에서는 throws가 간결하다.

// ✅ throws — 읽기 쉽다
func parse(_ data: Data) throws -> Config { … }
let config = try parse(data)

// ❌ 같은 것을 Result 로 — 호출부가 매번 케이스를 꺼내야 한다
func parse2(_ data: Data) -> Result<Config, ParseError> { … }
switch parse2(data) {
case .success(let c): use(c)
case .failure(let e): handle(e)
}

Result가 여전히 유용한 자리는 이렇다.

// (1) 레거시 컴플리션 핸들러 경계
func fetch(completion: @escaping (Result<Data, NetworkError>) -> Void)

// (2) 상태로 보관 — 화면이 마지막 결과를 기억해야 할 때
@Observable final class ViewModel {
    var lastResult: Result<[Item], Error>?
}

// (3) 병렬 작업의 부분 실패 수집 (35장)
await withTaskGroup(of: Result<Item, Error>.self) { group in … }

Failure가 Error를 준수해야 한다는 제약이 제네릭 파라미터 순서 오타를 컴파일 에러로 잡아 준다 — Result<NetworkError, Data>처럼 뒤바꿔 쓰면 Data가 Error가 아니므로 막힌다.

실험 · 도구

두 방식의 호출부 모양을 나란히 보면 선택이 쉬워진다.

import Foundation

enum LoadError: Error { case notFound, corrupted }

func loadThrowing(_ id: Int) throws -> String {
    guard id > 0 else { throw LoadError.notFound }
    return "item-\(id)"
}

// 여러 개를 처리하며 실패를 모아야 하는 경우 — Result 가 자연스럽다
let ids = [1, -2, 3, -4]
let results = ids.map { Result { try loadThrowing($0) } }

let ok = results.compactMap { try? $0.get() }
let bad = results.compactMap { r -> Error? in
    if case .failure(let e) = r { return e } else { return nil }
}
print("성공 \(ok.count)건, 실패 \(bad.count)건")     // 성공 2건, 실패 2건

// 하나만 즉시 처리하는 경우 — throws 가 간결하다
do { print(try loadThrowing(1)) }
catch { print("실패: \(error)") }

기존 코드에서 불필요한 Result를 찾는다.

# 동기 함수가 Result 를 반환하는 곳 — throws 로 단순화 후보
grep -rnE "func [a-zA-Z]+\([^)]*\) -> Result<" --include=*.swift . | grep -v async

# 컴플리션 핸들러 — async/await 로 옮기면 Result 가 사라진다
grep -rn "completion: @escaping (Result" --include=*.swift .

프로젝트 적용

1. 동기 함수의 기본은 throws다. 호출부가 간결하고 try가 실패 가능성을 드러낸다.
2. 저장·수집·지연이 필요하면 Result를 쓴다. 이 셋이 아니면 대개 throws가 맞다.
3. 컴플리션 핸들러는 async/await로 옮긴다. Result가 필요한 가장 흔한 이유가 사라진다.
4. 경계에서 변환한다. 내부는 throws로 쓰고 외부 API만 Result로 감싸는 식이 읽기 좋다.
5. Result를 반환하는 함수의 결과를 무시하지 않게 한다. throws와 달리 버려도 컴파일된다 — @discardableResult가 없는지 확인한다.

꼬리 질문

enum LoadOutcome<T> {
    case complete([T])
    case partial(loaded: [T], failed: [Error])
    case failed(Error)

    init(_ results: [Result<T, Error>]) {
        let ok = results.compactMap { try? $0.get() }
        let bad = results.compactMap { r -> Error? in
            if case .failure(let e) = r { return e } else { return nil } }
        switch (ok.isEmpty, bad.isEmpty) {
        case (false, true):  self = .complete(ok)
        case (false, false): self = .partial(loaded: ok, failed: bad)
        default:             self = .failed(bad.first ?? LoadError.notFound)
        }
    }
}

// ❌ 과도한 분류 — 호출자는 전부 똑같이 처리한다
enum Bad: Error {
    case timeout, dnsFailure, tlsHandshake, connectionReset, hostUnreachable
}

// ✅ 처리 방식으로 나눈다
enum NetworkError: Error {
    case offline                       // → "네트워크 확인" 안내
    case retryable(underlying: Error)  // → 재시도 버튼
    case client(status: Int)           // → 요청 자체가 잘못됨, 재시도 무의미
    case server(status: Int)           // → 잠시 후 재시도
}

// Failure 를 구체 타입으로 두면 실존 박싱을 피한다
let r: Result<Config, ParseError> = Result { try parse(data) }   // ❌ 추론은 Error
func parseResult(_ d: Data) -> Result<Config, ParseError> {       // ✅ 명시
    do { return .success(try parse(d)) }
    catch let e as ParseError { return .failure(e) }
    catch { return .failure(.unknown) }
}

Q2. Typed Throws는 무엇을 사고 무엇을 잃는가?

CS 원리

이것은 타입 정밀도와 진화 가능성의 트레이드오프다. 같은 긴장이 여러 곳에서 반복된다.

넓히는 방향이 깨지는 이유는 호출자가 망라성에 의존하기 때문이다. throws(NetworkError)를 catch하면서 모든 케이스를 switch로 처리한 코드는, 에러 타입이 any Error로 넓어지는 순간 default가 없어 컴파일되지 않는다.

반대로 좁히는 방향은 대체로 안전하다 — any Error를 기대하던 호출자는 구체 타입도 받을 수 있다. Never가 모든 에러 타입의 서브타입이라는 사실이 이 관계를 형식화한다.

일반 원리로 하면 "공개 API의 타입은 좁힐 수는 있어도 넓힐 수 없다"이다. 이는 31장 Q7의 스키마 진화 규칙 — 추가는 자유, 변경은 금지 — 와 같은 구조다. 어느 쪽이든 이미 배포된 소비자가 제약을 만든다.

iOS에서는

catch에서 타입이 바로 좁혀지는 것이 가장 눈에 띄는 변화다.

enum ParseError: Error { case empty, badFormat(line: Int) }

func parse(_ s: String) throws(ParseError) -> [Int] {
    guard !s.isEmpty else { throw .empty }        // 타입이 정해져 있어 .empty 로 줄여 쓴다
    …
}

do {
    let v = try parse(input)
} catch {
    // error 가 any Error 가 아니라 ParseError 로 추론된다
    switch error {
    case .empty:            showEmptyState()
    case .badFormat(let l): showError("\(l)행 형식 오류")
    }
    // default 가 필요 없다 — 망라성이 성립한다
}

제네릭 전파에서도 유용하다. 래퍼가 에러 타입을 그대로 통과시킬 수 있다.

func measured<T, E: Error>(_ label: String,
                           _ body: () throws(E) -> T) throws(E) -> T {
    let clock = ContinuousClock()
    let start = clock.now
    defer { logger.debug("\(label): \(clock.now - start)") }
    return try body()
}
//   에러 타입이 any Error 로 뭉개지지 않고 호출자까지 전달된다

공개 API에서는 신중해야 한다.

// ⚠️ public API 에 구체 타입을 박으면 나중에 넓힐 수 없다
public func load() throws(NetworkError) -> Data

// 나중에 디스크 에러도 던지고 싶어지면?
//   throws(any Error) 로 넓히는 순간 switch 로 망라 처리하던 호출자가 깨진다
//   → 처음부터 넓게 두거나, 에러 타입에 케이스를 추가하는 방향으로 진화시킨다

2026년 현재도 남아 있는 제약이 있다 — 클로저 본문 구조로부터의 타입 추론, Task·AsyncSequence 통합, throws(some Error)는 여전히 Future Directions다. 그래서 비동기 코드에서는 아직 활용 범위가 좁다.

실험 · 도구

망라성이 실제로 성립하는지 확인해 보자.

import Foundation

enum E1: Error { case a, b }

func typed() throws(E1) { throw .a }
func untyped() throws { throw E1.a }

do { try typed() } catch {
    switch error { case .a: print("a"); case .b: print("b") }   // ✅ default 불필요
}

do { try untyped() } catch {
    // error 는 any Error — 캐스팅이 필요하고 망라성이 없다
    if let e = error as? E1 { print("E1: \(e)") } else { print("기타") }
}

넓히면 깨진다는 것도 재현된다.

// 라이브러리 v1
public func work() throws(E1) { }

// 호출자
do { try work() } catch { switch error { case .a: …; case .b: … } }

// 라이브러리 v2 에서 throws(any Error) 로 넓히면
//   ❌ 호출자에서 "switch must be exhaustive" — default 가 없어 컴파일 실패
//   반대로 v1 이 any Error 였다가 E1 으로 좁아지는 것은 대체로 안전하다

도입 후보를 찾는 방법이다.

# 내부(non-public) 함수 중 에러 종류가 하나뿐인 것 — 안전한 도입 후보
grep -rn "func .*throws" --include=*.swift Sources/ | grep -v "public\|open"

# public API 에 throws 가 있는 곳 — 신중하게 판단할 대상
grep -rn "public func .*throws" --include=*.swift Sources/

프로젝트 적용

1. 내부 코드부터 도입한다. 모듈 내부 함수는 호출자를 우리가 통제하므로 넓혀도 같이 고치면 된다.
2. 공개 API에는 신중하게 쓴다. 에러 종류가 확실히 고정됐다고 판단될 때만. 애매하면 기존 throws가 안전하다.
3. 넓히는 대신 케이스를 추가한다. 에러 타입에 새 케이스를 넣는 것은 @unknown default 대비가 있으면 견딜 수 있다(Q7).
4. 제네릭 유틸리티에서 에러 타입을 전파시킨다. 래퍼가 any Error로 뭉개던 것을 정확히 넘길 수 있다.
5. 비동기 코드에서는 아직 기대를 낮춘다. Task·AsyncSequence 통합이 미완이다.

꼬리 질문

// 케이스가 늘어날 수 있음을 명시 — 호출자가 대비하게 한다
public enum NetworkError: Error {
    case offline
    case server(status: Int)
    case unknown(underlying: Error)      // 확장 지점을 미리 열어 둔다
}
//   새 상황이 생겨도 unknown 으로 흡수되므로 케이스 추가 자체가 줄어든다

// 내부는 정밀하게
private func decode(_ d: Data) throws(ParseError) -> Model { … }
private func validate(_ m: Model) throws(ValidationError) -> Model { … }

// 경계에서는 넓게 — 여러 에러 타입이 합류하는 지점
public func load(_ d: Data) throws -> Model {
    let m = try decode(d)
    return try validate(m)
}
//   두 에러 타입이 만나므로 여기서는 any Error 가 자연스럽다

Q3. KeyPath는 무엇을 가능하게 하며 어디까지 쓸 수 있는가?

CS 원리

KeyPath는 접근 경로의 물화(reification)다. 보통 user.address.zip은 코드로만 존재하는데, 이것을 값으로 만들어 저장·전달·재사용할 수 있게 한 것이다.

이 아이디어의 값어치는 "무엇을 접근할지"와 "언제 접근할지"를 분리하는 데 있다. 정렬 기준, 관찰 대상, 매핑 규칙을 미리 정해 두고 나중에 적용할 수 있다.

비슷한 목적의 오래된 기법이 문자열 키("address.zip")인데, 결정적 차이가 있다.

계층 구조는 능력에 따른 서브타입 관계다. 아래로 갈수록 할 수 있는 일이 늘고, 상위 타입 자리에 하위를 넣을 수 있다. ReferenceWritableKeyPath가 WritableKeyPath의 서브타입인 이유도 이것이다.

쓰기 가능성이 갈리는 지점은 값 의미론에서 온다. 값 타입은 프로퍼티를 바꾸려면 루트 자체가 변경 가능해야 하지만, 클래스는 참조가 상수여도 내부는 바꿀 수 있다. 이 차이가 타입 두 개로 나타난다. 다만 대상 프로퍼티 자체가 let이면 루트가 무엇이든 쓰기 불가다.

iOS에서는

가장 흔한 용도가 함수 자리에 쓰는 것이다(SE-0249).

struct User { let name: String; var age: Int }
let users = [User(name: "김", age: 30), User(name: "이", age: 25)]

users.map(\.name)                       // ["김", "이"]  ← 클로저 대신 key path
users.sorted { $0.age < $1.age }
users.max(by: { $0.age < $1.age })

중요한 제약이 있다 — 이 변환은 리터럴에만 적용된다.

// ✅ 리터럴 — (Root) -> Value 로 변환된다
users.map(\.name)

// ⚠️ 변수에 담긴 KeyPath — 같은 변환이 보장되지 않는다
let kp: KeyPath<User, String> = \.name
// users.map(kp)                        ← 컴파일되지 않을 수 있다
users.map { $0[keyPath: kp] }           // ✅ subscript 로 명시 적용

쓰기 가능성은 선언에 따라 갈린다.

struct S { let a: Int; var b: Int }
final class C { let x = S(a: 1, b: 2); var y = 0 }

\S.a          // KeyPath — a 가 let 이라 쓰기 불가
\S.b          // WritableKeyPath — 루트가 var 여야 쓸 수 있다
\C.y          // ReferenceWritableKeyPath — c 가 let 이어도 쓸 수 있다

var s = S(a: 1, b: 2)
s[keyPath: \.b] = 9                     // ✅

let c = C()
c[keyPath: \.y] = 9                     // ✅ 참조가 let 인데도 쓸 수 있다

제네릭 유틸리티에서 특히 유용하다 — 정렬·그룹핑 규칙을 값으로 받는다.

extension Sequence {
    func sorted<V: Comparable>(by kp: KeyPath<Element, V>) -> [Element] {
        sorted { $0[keyPath: kp] < $1[keyPath: kp] }
    }
    func grouped<K: Hashable>(by kp: KeyPath<Element, K>) -> [K: [Element]] {
        Dictionary(grouping: self) { $0[keyPath: kp] }
    }
}

users.sorted(by: \.age)
users.grouped(by: \.name)

실험 · 도구

계층과 쓰기 가능성을 직접 확인해 보자.

import Foundation

struct Point { var x: Int; let y: Int }
final class Box { var value = 0 }

// 타입이 무엇으로 추론되는지 확인한다
let kx = \Point.x            // WritableKeyPath<Point, Int>
let ky = \Point.y            // KeyPath<Point, Int>        ← let 이라 쓰기 불가
let kv = \Box.value          // ReferenceWritableKeyPath<Box, Int>

print(type(of: kx))
print(type(of: ky))
print(type(of: kv))

// 서브타입 관계 확인 — 상위 자리에 하위를 넣을 수 있다
let any: AnyKeyPath = kv
let partial: PartialKeyPath<Box> = kv
let readonly: KeyPath<Box, Int> = kv     // ✅ 업캐스트된다

리터럴 제약도 재현된다.

let names = [User(name: "김", age: 30)]

names.map(\.name)                         // ✅ 리터럴

let kp = \User.name
// names.map(kp)                           // ⚠️ 리터럴이 아니라 보장되지 않는다
names.map { $0[keyPath: kp] }             // ✅ 항상 동작한다

코드베이스에서 문자열 키를 KeyPath로 바꿀 후보를 찾는다.

# 문자열 기반 KVO·정렬 — KeyPath 로 옮길 후보
grep -rn "NSSortDescriptor(key:\|addObserver(.*forKeyPath: \"" --include=*.swift .

# value(forKey:) — 타입 안전하지 않은 접근
grep -rn "value(forKey:\|setValue(.*forKey:" --include=*.swift .

프로젝트 적용

1. 문자열 키를 KeyPath로 바꾼다. NSSortDescriptor·KVO의 문자열 경로는 오타가 런타임에야 드러난다.
2. 제네릭 유틸리티의 인자로 활용한다. 정렬·그룹핑·매핑 규칙을 값으로 받으면 재사용성이 크게 오른다.
3. 변수에 담아 쓸 때는 subscript(keyPath:)를 명시한다. 함수 자동 변환은 리터럴 전용이다.
4. 쓰기가 필요하면 타입을 정확히 선언한다. KeyPath로 받으면 쓰기가 안 되고, 이는 컴파일 타임에 드러난다.
5. KeyPath를 리플렉션 대용으로 오해하지 않는다. 미리 아는 경로를 값으로 다루는 것이지, 임의 탐색이 아니다.

꼬리 질문

// 타입이 다르므로 그대로는 배열에 못 담는다
// let options: [KeyPath<User, ???>] = [\.name, \.age]

// ✅ 비교 함수를 미리 만들어 담는다 — 타입 소거를 우리가 통제한다
struct SortOption {
    let title: String
    let compare: (User, User) -> Bool

    static func by<V: Comparable>(_ title: String, _ kp: KeyPath<User, V>) -> SortOption {
        SortOption(title: title) { $0[keyPath: kp] < $1[keyPath: kp] }
    }
}

let options: [SortOption] = [.by("이름순", \.name), .by("나이순", \.age)]
let sorted = users.sorted(by: options[selected].compare)

// 대량 정렬에서 신경 쓰인다면 비교 클로저를 직접 쓴다
users.sorted { $0.age < $1.age }         // 직접 접근
users.sorted(by: \.age)                  // key path — 읽기 좋지만 간접

// 28장 Q2 꼬리질문의 decorate-sort-undecorate 처럼
// 키를 먼저 뽑아 두면 비교 횟수만큼 반복되지 않는다

@Observable final class Model { var count = 0; var name = "" }

// 어떤 프로퍼티를 읽었는지 런타임이 추적한다 — KeyPath 를 우리가 적지 않는다
withObservationTracking {
    _ = model.count          // count 를 읽었으므로 count 변경만 감지된다
} onChange: {
    print("변경됨")
}

Q4. 프로퍼티 래퍼는 무엇으로 풀리며 어떤 비용이 있는가?

CS 원리

프로퍼티 래퍼는 접근 로직의 추출이다. 저장·검증·변환·관찰 같은 반복되는 프로퍼티 동작을 타입으로 뽑아 재사용한다.

이 아이디어의 핵심은 선언 지점에서 동작을 붙인다는 것이다. 호출부는 평범한 프로퍼티처럼 쓰지만, 실제로는 래퍼의 get·set이 개입한다. 이는 관점 지향(aspect-oriented)의 언어 수준 구현에 가깝다.

대가는 암묵성이다. user.name = "김"이라는 코드만 보고는 검증이 도는지, 디스크에 쓰는지, 알림이 가는지 알 수 없다. P0 17장에서 본 추상화가 비용을 숨긴다는 문제가 여기서도 나타난다.

합성이 비교환적인 것도 중요하다. 두 래퍼를 쌓으면 바깥 래퍼가 안쪽 래퍼 인스턴스를 감싸므로, 순서가 곧 중첩 구조다. 그래서 @A @B var x와 @B @A var x는 다른 타입, 다른 동작이 된다.

SE-0293이 이 메커니즘을 함수·클로저 파라미터로 확장했는데, 여기서 주의할 점은 겉보기와 실제가 다르다는 것이다 — 값을 넘기는 것처럼 보여도 실제 파라미터 타입과 ABI까지 바뀐다.

iOS에서는

직접 만들어 보면 desugar 결과가 분명해진다.

@propertyWrapper
struct Clamped<V: Comparable> {
    private var value: V
    private let range: ClosedRange<V>

    init(wrappedValue: V, _ range: ClosedRange<V>) {
        self.range = range
        self.value = min(max(wrappedValue, range.lowerBound), range.upperBound)
    }

    var wrappedValue: V {
        get { value }
        set { value = min(max(newValue, range.lowerBound), range.upperBound) }
    }

    var projectedValue: ClosedRange<V> { range }     // $volume 이 범위를 준다
}

struct Player {
    @Clamped(0...100) var volume = 50
}

var p = Player()
p.volume = 500
p.volume        // 100   ← setter 가 잘라 냈다
p.$volume       // 0...100  ← projectedValue 의 타입이다. Binding 이 아니다.

$가 Binding인 것은 @State의 특수 사례다.

@State private var text = ""      // $text 는 Binding<String>
@Clamped(0...100) var volume = 50 // $volume 은 ClosedRange<Int>
//   $ 의 타입은 각 래퍼가 정의한 projectedValue 가 정한다

합성 순서가 결과를 바꾸는 것도 확인된다.

// 바깥 래퍼는 제네릭이어야 안쪽 래퍼 타입을 담을 수 있다
@propertyWrapper struct Logged<T> {
    private var inner: T
    init(wrappedValue: T) { inner = wrappedValue }
    var wrappedValue: T {
        get { inner }
        set { logger.debug("변경"); inner = newValue }   // 안쪽 래퍼 인스턴스를 받는다
    }
}

struct A { @Logged @Clamped(0...10) var v = 5 }
//   Logged 가 바깥이므로 Logged<Clamped<Int>> 구조가 된다
//   순서를 바꾸면 Clamped 가 Logged 를 감싸려 하는데, Clamped 는 제네릭 제약이 달라 합성이 달라진다

비용은 세 가지다 — 추가 저장소(래퍼 인스턴스가 프로퍼티마다 존재), 간접 접근(계산 프로퍼티를 거친다), 암묵적 동작(호출부가 모른다). 앞의 둘은 대개 무시할 만하고, 세 번째가 진짜 비용이다.

실험 · 도구

desugar 결과를 직접 확인할 수 있다.

// 백킹 저장소 이름을 직접 써 보면 존재가 확인된다 (타입 내부에서만)
struct Demo {
    @Clamped(0...10) var v = 5
    func inspect() {
        print(type(of: _v))      // Clamped<Int>
        print(_v.wrappedValue)   // 5
    }
}
Demo().inspect()

// 타입 외부에서는 접근할 수 없다
// Demo()._v                     // ❌ '_v' is inaccessible due to 'private' protection level

컴파일러가 생성한 코드를 보고 싶으면 SIL을 확인한다.

# 프로퍼티 래퍼가 어떻게 풀리는지 확인한다
swiftc -emit-sil Demo.swift | grep -A5 "_v\|wrappedValue" | head -40

# 인터페이스 수준에서 보고 싶다면
swiftc -emit-module-interface -enable-library-evolution Demo.swift
#   생성된 .swiftinterface 에 백킹 저장소가 어떻게 노출되는지 드러난다

남용 여부를 점검한다.

# 프로젝트에 정의된 프로퍼티 래퍼 목록
grep -rn "@propertyWrapper" --include=*.swift .

# 래퍼를 쌓아 쓰는 곳 — 순서 의존이 있는지 확인할 대상
grep -rnE "@[A-Z][A-Za-z]+ +@[A-Z][A-Za-z]+ +(var|let)" --include=*.swift .

프로젝트 적용

1. 동작이 이름에서 드러나게 짓는다. @Clamped·@Trimmed처럼 무엇을 하는지가 보이면 암묵성 비용이 줄어든다.
2. 부수 효과가 큰 래퍼는 피한다. 프로퍼티 대입이 네트워크 요청을 일으키면 호출부가 비용을 예측할 수 없다(P1 20장 Q5).
3. 쌓아 쓰기 전에 순서를 문서화한다. 비교환적이므로 왜 이 순서인지가 코드에 남아야 한다.
4. projectedValue의 타입을 명확히 한다. $가 무엇을 주는지는 래퍼마다 다르다.
5. SwiftUI 전용 기능으로 오해하지 않는다. SE-0258은 일반 언어 기능이고, 검증·정규화·스레드 확인 같은 데 유용하다.

꼬리 질문

MemoryLayout<Int>.size                  // 8
MemoryLayout<Clamped<Int>>.size         // 8 + 범위(16) = 24
//   프로퍼티 하나당 세 배가 된다 — 대량 인스턴스에서는 확인할 가치가 있다

// ❌ 루프마다 UserDefaults 쓰기가 일어난다
for item in items { settings.lastSeen = item.id }

// ✅ 마지막에 한 번
settings.lastSeen = items.last?.id ?? settings.lastSeen

@propertyWrapper struct Trimmed {
    private var v: String
    init(wrappedValue: String) { v = wrappedValue.trimmingCharacters(in: .whitespaces) }
    var wrappedValue: String { get { v } set { v = newValue.trimmingCharacters(in: .whitespaces) } }
}

func register(@Trimmed name: String) { print("[\(name)]") }

register(name: "  김  ")      // [김]   ← 호출부는 String 을 넘긴 것처럼 보인다
//   그러나 실제 함수는 Trimmed 를 만들어 받는 형태로 변환된다

Q5. Primary Associated Type은 성능을 바꾸는가?

CS 원리

이 기능이 푸는 문제는 표기의 비대칭이다. 제네릭 타입은 Array<Int>처럼 파라미터를 자연스럽게 적는데, 프로토콜의 associated type은 where 절이라는 다른 문법을 써야 했다.

// 같은 뜻인데 표기가 전혀 다르다
func f<C: Collection>(_ c: C) where C.Element == Int
func f(_ c: some Collection<Int>)

특히 실존 타입에서 문제가 컸다. any Collection은 쓸 수 있지만 원소 타입을 제약할 방법이 없어 실용성이 떨어졌다. any Collection<Int>는 실존 타입이면서 원소 타입 안전성을 동시에 얻는 조합이라 실무에서 유용하다.

중요한 것은 이것이 표기만의 변화라는 점이다. SIL·ABI·실존 레이아웃 어느 것도 바뀌지 않는다. 그래서 "이 문법이 성능을 개선한다"는 기대는 틀렸다.

primary로 선언한 것만 대상이라는 제약도 설계 의도가 있다. 모든 associated type을 꺾쇠에 넣으면 순서에 의미가 생겨 프로토콜 진화가 어려워진다. 그래서 가장 중요한 것 몇 개만 노출하도록 제한했다.

iOS에서는

실존 타입에서 가장 유용하다.

// 이전 — 원소 타입을 제약할 수 없어 실용성이 낮았다
func render(_ items: any Collection) { … }        // Element 를 알 수 없다

// 지금 — 실존이면서 원소 타입이 확정된다
func render(_ items: any Collection<String>) {
    for s in items { print(s.uppercased()) }      // String 임을 안다
}

// 프로퍼티에도 쓸 수 있다 — some 으로는 표현이 까다롭던 자리
final class Store {
    var items: any Collection<Item> = []
}

some과 any의 선택은 여전히 P0 05장 Q8의 기준을 따른다 — 구체 타입이 하나로 고정되면 some, 런타임에 바뀔 수 있으면 any.

// some — 반환 타입이 하나로 정해진다. 실존 박싱 없음.
func makeIDs() -> some Collection<Int> { [1, 2, 3] }

// any — 여러 구체 타입이 들어올 수 있다. 실존 컨테이너 사용.
var current: any Collection<Int> = [1, 2, 3]
current = Set([4, 5])                              // 타입을 바꿀 수 있다

제외된 프로토콜이 있다는 점을 알아 둬야 한다. SE-0358이 Sequence<Element>·Collection<Element>·Identifiable<ID> 등에 부여했지만, AsyncSequence·LazySequenceProtocol·OptionSet 등은 향후 호환성 우려로 의도적으로 제외됐다.

// ❌ AsyncSequence 는 primary associated type 이 없어 이 문법을 못 쓴다
// func consume(_ s: any AsyncSequence<Int>) { }

// ✅ where 절을 쓴다
func consume<S: AsyncSequence>(_ s: S) async throws where S.Element == Int { … }

실험 · 도구

두 표기가 같은 것으로 풀리는지 SIL로 확인할 수 있다.

# 두 함수를 각각 다른 표기로 쓰고 SIL 시그니처를 비교한다
cat > /tmp/pat.swift <<'SWIFT'
func newStyle(_ c: some Collection<Int>) -> Int { c.count }
func oldStyle<C: Collection>(_ c: C) -> Int where C.Element == Int { c.count }
SWIFT

swiftc -emit-sil /tmp/pat.swift 2>/dev/null | grep -E "^sil hidden.*Style"
#   제네릭 시그니처가 나란히 출력된다 — 이름만 다르고 제약 구조는 같다

어떤 프로토콜이 이 문법을 지원하는지 확인하는 법이다.

// 지원하면 컴파일된다
let a: any Collection<Int> = [1, 2]
let b: any Sequence<String> = ["a"]

// 지원하지 않으면 컴파일 에러 — 그 자체가 확인 수단이다
// let c: any AsyncSequence<Int>      // ❌

# 표준 라이브러리 인터페이스에서 primary associated type 선언을 찾는다
xcrun swift-api-digester --dump-sdk --module Swift 2>/dev/null | grep -i "primary" | head
# 또는 프로토콜 선언을 직접 본다
echo 'protocol P<T> { associatedtype T }' | swiftc -emit-sil - 2>&1 | head -5

프로젝트 적용

1. 실존 타입이 필요한 자리에서 적극 쓴다. any Collection<Item>은 실존 + 타입 안전을 동시에 준다.
2. 성능을 이유로 도입하지 않는다. 표기만 바뀐다 — 성능이 목적이면 some·제네릭으로 실존 자체를 피하는 것이 답이다.
3. 우리 프로토콜에도 primary를 선언한다. 가장 중요한 associated type 한두 개만 노출하면 호출부가 크게 읽기 쉬워진다.
4. 지원하지 않는 프로토콜을 확인해 둔다. AsyncSequence 등은 여전히 where 절이 필요하다.
5. 기존 where 절 코드를 무리하게 바꾸지 않는다. 동작이 같으므로 가독성이 개선되는 자리에서만 바꾼다.

꼬리 질문

// 이전 — 호출부가 where 절을 반복해야 한다
protocol Repository {
    associatedtype Item
    associatedtype Query
    func fetch(_ q: Query) async throws -> [Item]
}
func show<R: Repository>(_ r: R) where R.Item == User { … }

// ✅ 가장 자주 제약하는 Item 만 primary 로
protocol Repository<Item> {
    associatedtype Item
    associatedtype Query
    func fetch(_ q: Query) async throws -> [Item]
}
func show(_ r: some Repository<User>) { … }
func store(_ r: any Repository<User>) { … }        // 실존으로도 쓸 수 있다

# 오래 걸리는 함수를 찾는다 (100ms 넘는 것만 경고)
swiftc -Xfrontend -warn-long-function-bodies=100 \
       -Xfrontend -warn-long-expression-type-checking=100 *.swift

# 파일별 컴파일 시간 집계
xcodebuild -showBuildTimingSummary ...

// ❌ 타입 검사가 오래 걸린다
let v = items.map { $0.a }.filter { $0 > 0 }.reduce(0, +) / Double(items.count)

// ✅ 중간 타입을 명시해 탐색을 끊는다
let values: [Double] = items.map(\.a)
let positive: [Double] = values.filter { $0 > 0 }
let v = positive.reduce(0, +) / Double(items.count)

Q6. 소급 준수는 왜 위험한가?

CS 원리

이것은 전역 유일성 제약(global uniqueness)의 문제다. Swift 런타임은 "타입 T가 프로토콜 P를 준수한다"는 사실을 프로세스 전체에서 하나로 관리한다 — 그래야 as? 캐스팅과 witness table 조회가 일관되게 동작한다.

문제는 선언 위치가 제한되지 않는다는 점이다. Swift는 어느 모듈에서나 준수를 추가할 수 있게 허용하는데, 이 유연성이 유일성과 충돌한다.

마지막 조합만 위험한 이유는 둘 다 남의 것이라서다. 원 저자가 나중에 그 준수를 직접 추가할 수도 있고, 다른 라이브러리가 동시에 추가할 수도 있다. 그러면 같은 준수가 두 벌 존재한다.

여기서 중요한 것은 도구가 이를 검증할 수 없다는 점이다. 컴파일 시점에는 어떤 모듈이 링크될지 모르고, 링크 시점에는 준수 선언이 심볼 충돌로 잡히지 않는다. 그래서 SE-0364가 할 수 있는 최선이 "위험하다는 표시를 남기게 하는 것"이었다.

iOS에서는

경고가 뜨는 자리와 안 뜨는 자리가 명확히 갈린다.

import Foundation

// ⚠️ 외부 타입(Foundation) × 외부 프로토콜(Swift) — 경고
extension Date: Identifiable {
    public var id: TimeInterval { timeIntervalSince1970 }
}
//   warning: extension declares a conformance of imported type 'Date'
//            to imported protocol 'Identifiable'

// ✅ 의도적임을 표시하면 경고가 사라진다 — 다만 위험은 그대로다
extension Date: @retroactive Identifiable {
    public var id: TimeInterval { timeIntervalSince1970 }
}

// ✅ 내 프로토콜이면 경고 자체가 없다 — 내가 전적으로 통제하므로
protocol Displayable { var label: String { get } }
extension Date: Displayable { var label: String { formatted() } }

실무에서 안전한 대안은 준수 대신 래퍼 타입을 쓰는 것이다.

// ❌ 소급 준수 — 충돌 위험
extension URL: @retroactive Identifiable { public var id: String { absoluteString } }

// ✅ 래퍼 — 우리가 소유한 타입이므로 충돌이 없다
struct IdentifiedURL: Identifiable {
    let value: URL
    var id: String { value.absoluteString }
}

// ✅ 또는 우리 프로토콜로 감싼다
protocol AppIdentifiable { var appID: String { get } }
extension URL: AppIdentifiable { var appID: String { absoluteString } }

조건부 준수는 별개 문제다. SE-0143의 extension Array: Equatable where Element: Equatable 같은 것은 컴파일 타임 표현력 문제를 푸는 기능인데, 겹치는 준수는 서로소로 보여도 전면 금지라는 별도 제약이 있다.

// ❌ 겹치는 조건부 준수는 서로소처럼 보여도 금지된다
// extension MyBox: Codable where T: Codable { }
// extension MyBox: Codable where T: NSCoding { }
//   error: conflicting conformance of 'MyBox<T>' to protocol 'Codable'

실험 · 도구

경고가 어느 조합에서 뜨는지 직접 확인해 보자.

import Foundation

// (1) 외부 × 외부 — 경고
extension UUID: Identifiable { public var id: String { uuidString } }

// (2) 외부 × 내 프로토콜 — 경고 없음
protocol Mine { var mine: Int { get } }
extension UUID: Mine { var mine: Int { 1 } }

// (3) 내 타입 × 외부 프로토콜 — 경고 없음
struct MyType {}
extension MyType: Identifiable { var id: Int { 1 } }

# 프로젝트에서 소급 준수를 전부 찾는다
grep -rnE "extension +(Date|URL|UUID|String|Int|Array|Data|NS[A-Z][A-Za-z]+) *:" \
     --include=*.swift . | grep -v "@retroactive"

# 이미 표시된 것 — 의도를 검토할 대상
grep -rn "@retroactive" --include=*.swift .

# 경고를 에러로 승격해 새로 들어오는 것을 막는다
# Build Settings › Other Swift Flags 에 -warnings-as-errors 를 넣거나
# 특정 진단만 승격하는 방식을 검토한다

실제 충돌이 일어났는지는 런타임에 확인해야 한다 — 그것이 이 문제의 핵심 어려움이다.

// 준수가 실제로 어느 구현으로 해석되는지 확인
let d = Date()
if let identified = d as? any Identifiable {
    print(type(of: identified.id))    // 어느 구현이 이겼는지 간접적으로 드러난다
}
//   두 벌이 존재해도 크래시가 나지 않고 "둘 중 하나"가 선택되므로
//   테스트에서 우연히 통과할 수 있다 — 이것이 위험한 이유다

프로젝트 적용

1. 소급 준수 대신 래퍼 타입이나 우리 프로토콜을 쓴다. 대부분의 경우 이것으로 충분하고 위험이 없다.
2. 불가피하면 @retroactive를 붙이고 주석에 근거를 남긴다. 표시는 해결이 아니라 문서화다.
3. 라이브러리에서는 절대 하지 않는다. 앱은 최종 소비자라 그나마 통제되지만, 라이브러리가 하면 사용자에게 충돌을 강요한다.
4. 의존성이 늘어날 때 검토한다. 새 라이브러리가 같은 준수를 선언했을 수 있다.
5. 경고를 끄지 않는다. @retroactive 없이 경고만 무시하면 다음 사람이 위험을 모른다.

꼬리 질문

# 의존성이 어떤 소급 준수를 하는지 확인 (소스가 있는 경우)
grep -rn "@retroactive\|extension .*: *\(Identifiable\|Hashable\|Codable\)" \
     .build/checkouts/*/Sources/ 2>/dev/null | head -20

// ✅ 안전 — 메서드·계산 프로퍼티 추가는 준수가 아니다
extension String {
    var trimmed: String { trimmingCharacters(in: .whitespacesAndNewlines) }
    func chunked(into size: Int) -> [Substring] { … }
}

extension Collection {
    subscript(safe index: Index) -> Element? {
        indices.contains(index) ? self[index] : nil
    }
}

// ⚠️ 위험 — 프로토콜 준수 추가
// extension String: @retroactive Identifiable { }

Q7. 망라성 검사와 defer는 무엇을 지켜 주는가?

CS 원리

두 장치는 서로 다른 종류의 빠뜨림을 막는다.

• 망라성 — 경우의 빠뜨림. "이 상황도 처리했는가"를 컴파일러가 증명한다.
• defer — 정리의 빠뜨림. "나가는 모든 경로에서 정리했는가"를 런타임이 보장한다.

망라성 증명이 성립하려면 case 목록이 확정적이어야 한다. 자기 모듈 enum이나 library evolution 없이 컴파일된 일반 의존성의 enum은 클라이언트가 항상 그 정확한 정의로 재컴파일되므로 목록이 확정된다.

문제는 -enable-library-evolution으로 빌드된 non-frozen enum이다 — Apple 시스템 프레임워크가 대표적이다. 클라이언트를 재컴파일하지 않아도 나중 OS 버전에서 새 case가 조용히 추가될 수 있으므로, 컴파일 타임의 목록이 런타임의 목록과 다를 수 있다.

그래서 규칙이 적용되는 대상은 "내 모듈 밖"이 아니라 "재컴파일 없이 새 버전으로 바뀔 수 있는 ABI 경계 너머"다. 이 구분이 실무 판단을 바꾼다.

defer의 원리는 스코프 종료 시점의 후처리다. C++의 소멸자나 try-finally와 같은 목적인데, LIFO인 이유는 획득의 역순으로 해제하는 것이 자원 관리의 자연스러운 순서이기 때문이다.

iOS에서는

망라성 규칙이 어디서 적용되는지가 실무 판단을 가른다.

// 내 모듈 enum — @unknown default 불필요
enum MyState { case idle, loading, done }
switch state {
case .idle: …
case .loading: …
case .done: …
}                                   // ✅ 망라적

// 시스템 프레임워크의 non-frozen enum — 필요하다
switch UIDevice.current.userInterfaceIdiom {
case .phone: …
case .pad: …
@unknown default: …                 // ✅ 새 기기 종류가 추가될 수 있다
}

// library evolution 없이 빌드된 SPM 의존성 — 경고조차 없다
switch someLibraryEnum {
case .a: …
case .b: …
}                                   // ✅ 클라이언트가 항상 재컴파일되므로

우리가 라이브러리를 만든다면 @frozen으로 목록을 고정할 수 있다.

// case 목록을 ABI 계약으로 영구 고정 — 이후 추가 불가
@frozen public enum Direction { case up, down }
//   클라이언트가 @unknown default 없이 switch 할 수 있게 된다.
//   대신 케이스를 영원히 못 늘린다 — 신중한 결정이다.

defer는 스코프 단위라는 점이 자주 오해된다.

// 루프 몸체 안의 defer 는 매 반복마다 실행된다
for i in 0..<3 {
    defer { print("정리 \(i)") }
    print("작업 \(i)")
}
// 작업 0 / 정리 0 / 작업 1 / 정리 1 / 작업 2 / 정리 2

// LIFO — 나중에 쓴 것이 먼저
func f() {
    defer { print("A") }
    defer { print("B") }
    print("본문")
}
// 본문 / B / A

변수 캡처도 주의할 점이다 — 등록 시점이 아니라 실행 시점의 값을 읽는다.

func g() {
    var count = 0
    defer { print("최종 count: \(count)") }
    count = 1
    count = 2
}
// 최종 count: 2      ← 등록 시점의 0 이 아니다

그리고 실행되지 않는 경우가 둘 있다 — 스코프에 진입조차 안 했을 때와 fatalError 같은 트랩을 지날 때다. 트랩은 return이 아니라 프로세스 종료이기 때문이다(P1 19장).

실험 · 도구

망라성 규칙이 대상에 따라 다르게 적용되는 것을 확인해 보자.

import UIKit

// (1) 시스템 프레임워크 enum — @unknown default 없이 switch
func check(_ idiom: UIUserInterfaceIdiom) -> String {
    switch idiom {
    case .phone: return "phone"
    case .pad:   return "pad"
    default:     return "기타"     // default 는 경고를 막지만 새 case 를 알려주지 않는다
    }
}
//   @unknown default 를 쓰면 새 case 가 추가됐을 때 경고로 알려준다 — 이쪽이 낫다

# Swift 6 언어 모드로 빌드해 이 규칙이 에러가 되는지 확인한다
swiftc -swift-version 6 MyFile.swift

# 프로젝트에서 default 를 @unknown default 로 바꿀 후보를 찾는다
grep -rn -B5 "^\s*default:" --include=*.swift . | grep -i "switch.*UI\|switch.*NS" | head

# 의존성이 library evolution 으로 빌드됐는지 확인
grep -rn "enable-library-evolution\|BUILD_LIBRARY_FOR_DISTRIBUTION" \
     --include=*.swift --include=*.pbxproj --include=Package.swift .

defer의 동작도 재현해 본다.

func demo() throws {
    defer { print("1) 마지막에 실행") }
    defer { print("2) 먼저 실행") }

    if Bool.random() {
        defer { print("3) if 스코프 끝에서 즉시") }
        print("if 안")
    }                                  // ← 여기서 3) 이 실행된다

    throw MyError.oops                 // throw 경로에서도 1) 2) 는 실행된다
}
// if 안 / 3) / 2) / 1)

프로젝트 적용

1. default 대신 @unknown default를 쓴다. 새 case가 추가되면 경고로 알려 주므로 대응할 기회가 생긴다.
2. Swift 6 언어 모드를 켠다. 이 규칙이 에러가 되어 놓칠 수 없게 된다.
3. 우리 공개 enum에 @frozen을 붙일지 신중히 판단한다. 붙이면 영원히 케이스를 못 늘린다.
4. defer를 자원 해제에 쓴다. 파일 핸들·락·측정 종료처럼 모든 경로에서 반드시 해야 하는 일.
5. defer가 트랩에서 실행되지 않는다는 것을 안다. fatalError 뒤의 정리는 일어나지 않는다.

꼬리 질문

switch status {
case .active:   showActive()
case .expired:  showExpired()
@unknown default:
    // ① 기록한다 — 새 case 가 실제로 오고 있는지 지표로 확인한다
    logger.notice("알 수 없는 status: \(String(describing: status), privacy: .public)")
    metrics.increment("enum.unknown", tags: ["type": "Status"])
    // ② 가장 안전한 동작으로 폴백한다
    showGenericState()
}

// ❌ defer 안에서 await 불가
// defer { await connection.close() }

// ✅ 명시적으로 감싼다
func withConnection<T>(_ body: (Connection) async throws -> T) async throws -> T {
    let c = try await Connection.open()
    do {
        let r = try await body(c)
        await c.close()
        return r
    } catch {
        await c.close()
        throw error
    }
}

// 상태 플래그를 defer 에서 읽는 방식도 있지만 읽기 어렵다
var committed = false
defer { if !committed { rollback() } }
…
committed = true
//   동작은 하지만, 흐름이 흩어져 추적이 어렵다

# Swift 6 모드로 시험 빌드해 개수를 센다
xcodebuild -scheme App SWIFT_VERSION=6 2>&1 \
  | grep -c "must be exhaustive\|@unknown default"

# 어떤 파일인지 목록으로
xcodebuild -scheme App SWIFT_VERSION=6 2>&1 \
  | grep -B1 "must be exhaustive" | grep "\.swift" | sort -u

출처 · 참고자료