33 · 런타임과 ABI

32장이 타입 시스템이 무엇을 보장하는가였다면, 이 챕터는 그 아래층 — 컴파일러가 실제로 무엇을 생성하고 런타임이 무엇을 보장하는가다.

여기서 다루는 것들은 대부분 평소에는 안 보이다가 특정 조건에서 갑자기 문제가 된다. 프레임워크로 분리하는 순간 성능이 떨어지고, 프로토콜 타입으로 호출하는 순간 다른 구현이 돌고, 동시에 접근하는 순간 초기화가 여러 번 일어난다.

P0 14장에서 컴파일·링크·dyld 로드의 흐름을, P0 05장에서 Swift 런타임의 값·참조 표현을 봤다. 이 챕터는 그 둘이 만나는 자리 — ABI 경계를 다룬다.

Q1. 라이브러리 진화는 무엇을 고정하고 무엇을 대가로 치르는가?

CS 원리

ABI 안정성은 "컴파일 시점에 알던 것"과 "실행 시점에 실제인 것"이 달라질 수 있음을 전제로 한다.

일반적인 컴파일에서는 이 둘이 같다. 컴파일러가 struct Point { var x, y: Int }를 보면 x는 오프셋 0, y는 오프셋 8이라고 확정하고, 그 숫자를 기계어에 박는다.

그런데 프레임워크가 나중에 교체될 수 있다면 그 가정이 깨진다. 새 버전이 필드를 추가하거나 순서를 바꾸면 박아 둔 오프셋이 틀린 곳을 가리킨다. 그래서 라이브러리 진화 모드는 오프셋을 박지 않고 물어보게 만든다.

이것이 추상화의 대가다 — 유연성을 얻는 대신 간접 계층이 생긴다. 31장 Q7·32장 Q2에서 본 "이미 배포된 소비자가 제약을 만든다"는 원리가 여기서는 기계어 수준으로 나타난다.

탈출구가 명시적 약속이다.

• @frozen — "레이아웃이 앞으로도 절대 안 바뀐다"는 약속. 직접 필드 접근을 되찾는 대신 이후 저장 프로퍼티 추가·삭제·재배치가 전부 ABI 파괴가 된다.
• @inlinable — 함수 구현부 자체를 공개 인터페이스로 노출해 클라이언트가 인라인·특수화할 수 있게 한다. 그 본문이 참조하는 internal 심볼에는 @usableFromInline이 필요하다.

둘 다 구현 세부를 계약으로 승격시키는 행위다. 성능을 얻는 대신 바꿀 자유를 판다.

iOS에서는

대부분의 앱 개발자에게 이 설정은 꺼져 있다. 문제가 되는 것은 프레임워크를 만들 때다.

// 프레임워크 안 — 라이브러리 진화가 켜져 있다면
public struct Point {
    public var x: Int
    public var y: Int
}
//   클라이언트에서 p.x 는 게터 호출이 된다

@frozen public struct FastPoint {
    public var x: Int
    public var y: Int
}
//   직접 필드 접근으로 돌아온다. 대신 이후 필드 추가가 ABI 파괴다.

@inlinable은 본문을 공개하므로 참조 대상도 함께 공개돼야 한다.

@inlinable
public func scaled(_ p: Point, by f: Int) -> Point {
    Point(x: p.x * f, y: p.y * f)
}

// 본문이 internal 심볼을 참조하면 @usableFromInline 이 필요하다
@usableFromInline
internal func clamp(_ v: Int) -> Int { max(0, v) }

@inlinable
public func safeScaled(_ p: Point, by f: Int) -> Point {
    Point(x: clamp(p.x * f), y: clamp(p.y * f))   // clamp 가 인라인 본문에 등장한다
}

언제 켜지는지를 알아야 판단할 수 있다.

• 일반 앱 타깃 — 꺼짐. 이 챕터의 구분이 무의미하다.
• SPM 로컬 패키지 — 기본적으로 꺼짐. 소스에서 함께 빌드된다.
• XCFramework로 배포하는 바이너리 프레임워크 — 켜야 한다(BUILD_LIBRARY_FOR_DISTRIBUTION = YES).
• Apple 시스템 프레임워크 — 켜져 있다. 그래서 32장 Q7의 @unknown default 규칙이 적용된다.

실험 · 도구

SIL로 직접 비교하면 차이가 눈에 보인다.

cat > /tmp/lib.swift <<'SWIFT'
public struct Point { public var x: Int; public var y: Int }
@frozen public struct FastPoint { public var x: Int; public var y: Int }
public func readA(_ p: Point) -> Int { p.x }
public func readB(_ p: FastPoint) -> Int { p.x }
SWIFT

# 라이브러리 진화 켜고 SIL 확인
swiftc -emit-sil -enable-library-evolution /tmp/lib.swift 2>/dev/null \
  | grep -A6 "sil.*readA\|sil.*readB"
#   readA — function_ref @…Point.x.getter 와 apply 가 보인다
#   readB — struct_extract %0 : $FastPoint, #FastPoint.x 한 줄

# 끄고 비교하면 둘 다 struct_extract 다
swiftc -emit-sil /tmp/lib.swift 2>/dev/null | grep -A4 "sil.*readA"

@inlinable의 효과도 확인할 수 있다.

# -O 에서 인라인되면 function_ref 가 사라지고 연산이 직접 박힌다
swiftc -O -emit-sil /tmp/inline.swift 2>/dev/null | grep -c "function_ref.*scaled"
#   0 이면 인라인된 것이다

프로젝트 설정을 확인한다.

# 라이브러리 진화가 켜진 타깃 찾기
grep -rn "BUILD_LIBRARY_FOR_DISTRIBUTION" *.xcodeproj/project.pbxproj

# 이미 @frozen·@inlinable 을 쓰는 곳 — ABI 계약을 진 자리
grep -rn "@frozen\|@inlinable\|@usableFromInline" --include=*.swift .

프로젝트 적용

1. 앱 타깃에서는 신경 쓰지 않는다. 이 설정이 꺼져 있으면 @frozen·@inlinable은 의미가 없다.
2. 바이너리 프레임워크를 배포한다면 성능 영향을 측정한다. 뜨거운 경로의 struct 접근이 게터 호출이 된다.
3. @frozen은 정말 안 바뀔 타입에만 붙인다. 좌표·색상처럼 수학적으로 확정된 구조가 후보다.
4. @inlinable은 작고 안정적인 함수에만 붙인다. 본문이 영원히 계약이 되므로 버그 수정도 어려워진다.
5. SPM 소스 배포를 우선 고려한다. 소스로 배포하면 이 문제 자체가 없다 — P1 26장 Q3의 동적 프레임워크 비용과 함께 저울질한다.

꼬리 질문

// 표준 라이브러리의 핵심 타입들은 대부분 @frozen 이다
// Int, Double, Bool, Optional, Array 의 표현 등
//   그래서 앱 코드에서 이들을 다룰 때 게터 호출이 끼지 않는다

Q2. throws는 정말 공짜인가?

CS 원리

에러 전파를 구현하는 방식은 크게 둘이다.

C++ 방식은 "예외는 예외적이다"라는 전제 위에 있다 — 정상 경로를 최대한 빠르게 하고 에러 경로의 비용은 감수한다. 대신 에러가 자주 나면 급격히 느려지고, 실시간 시스템처럼 최악 실행 시간이 중요한 곳에서는 쓰기 어렵다.

Swift는 반대를 골랐다 — 정상 경로에 작은 고정 비용을 두고 에러 경로를 평범한 분기로 만든다. 그래서 예측 가능하고, 에러를 제어 흐름의 일부로 써도 성능이 무너지지 않는다.

구현의 핵심은 숨겨진 반환 채널이다. 함수는 값과 에러를 동시에 돌려줄 수 있어야 하는데, 반환값 자리는 하나다. 그래서 레지스터 하나를 예약해 두 번째 채널로 쓴다. callee-saved로 지정한 이유는 중간 함수들이 값을 보존해야 하기 때문이다.

다만 throw 자체는 힙 할당을 한다(swift_allocError). 그래서 에러를 초당 수만 번 던지는 설계는 여전히 비싸다 — 32장 Q2의 Typed Throws가 실존 박싱을 피하는 것과는 별개 문제다.

iOS에서는

실무 판단은 "에러가 예외적인가, 흔한가"다.

// ✅ 에러가 예외적 — throws 가 적합하다
func loadConfig() throws -> Config { … }        // 실패는 드물다

// ⚠️ 에러가 흔한 흐름 — 반환 타입으로 표현하는 편이 나을 수 있다
func parseInt(_ s: String) throws -> Int { … }   // 실패가 자주 일어난다면?
func parseInt2(_ s: String) -> Int? { Int(s) }   // 옵셔널이 더 자연스럽다

옵셔널과 throws의 선택 기준이 여기서 나온다.

• 실패 이유가 하나뿐이고 자명하면 — 옵셔널. Int("abc")가 nil인 이유는 명백하다.
• 실패 이유를 알려야 하면 — throws. 호출자가 왜 실패했는지에 따라 다르게 행동한다.
• 실패가 매우 잦고 뜨거운 경로면 — 옵셔널이 유리하다. 힙 할당이 없다.

에러 타입의 크기도 영향을 준다.

// 연관값이 큰 에러는 할당 비용이 는다
enum HeavyError: Error {
    case failed(request: URLRequest, response: HTTPURLResponse, body: Data)   // 크다
}

// 진단 정보가 필요하면 참조로 감싸거나 지연 생성한다
enum LeanError: Error {
    case failed(context: () -> String)      // 필요할 때만 문자열을 만든다
}

다만 대부분의 앱에서 이 수준은 최적화 대상이 아니다. P0 12장의 원칙대로 측정 후 판단한다.

실험 · 도구

어셈블리로 직접 확인할 수 있다.

cat > /tmp/err.swift <<'SWIFT'
enum E: Error { case bad }
@inline(never) func mayFail(_ x: Int) throws -> Int {
    if x < 0 { throw E.bad }
    return x * 2
}
@inline(never) func caller(_ x: Int) -> Int {
    (try? mayFail(x)) ?? -1
}
SWIFT

# arm64 어셈블리에서 에러 레지스터 사용을 확인한다
swiftc -O -emit-assembly -target arm64-apple-macos13 /tmp/err.swift 2>/dev/null \
  | grep -E "x21|cbz|swift_allocError" | head -20
#   mov x21, #0      ← 호출 전 초기화
#   cbz x21, …       ← 호출 후 검사
#   bl _swift_allocError  ← throw 경로의 힙 할당

비용을 재 보고 싶다면 정상 경로와 에러 경로를 나눠 측정한다.

import Foundation

let clock = ContinuousClock()
let n = 1_000_000

// 정상 경로 — 초기화 + 분기만 남는다
let ok = clock.measure { for i in 0..<n { _ = try? mayFail(i) } }

// 에러 경로 — 매번 swift_allocError
let fail = clock.measure { for i in 0..<n { _ = try? mayFail(-i) } }

// 비교군 — 옵셔널 반환
let opt = clock.measure { for i in 0..<n { _ = i < 0 ? nil : i * 2 } }

print("정상: \(ok)\n에러: \(fail)\n옵셔널: \(opt)")
//   에러 경로가 눈에 띄게 느리면 그 경로가 뜨거운지 검토한다

프로젝트 적용

1. 에러가 예외적이면 throws를 그대로 쓴다. 대부분의 경우가 여기 해당한다.
2. 실패가 흔하고 이유가 자명하면 옵셔널을 고려한다. Int(_:)·Dictionary 조회가 옵셔널인 이유다.
3. 뜨거운 루프에서 에러를 던지지 않는다. swift_allocError가 반복된다 — 루프 밖에서 검증하거나 옵셔널로 바꾼다.
4. "throws가 느리다"는 이유로 피하지 않는다. 정상 경로 비용은 명령 두 개 수준이다.
5. 에러 연관값을 가볍게 유지한다. 큰 데이터를 담으면 할당 비용이 는다 — 필요하면 지연 생성한다.

꼬리 질문

// 호출부가 이유를 안 쓴다면 throws 가 과하다
guard let v = try? parse(s) else { return defaultValue }

// 이유에 따라 다르게 행동한다면 throws 가 맞다
do { try submit(order) }
catch NetworkError.offline { showOfflineBanner() }
catch NetworkError.server { scheduleRetry() }
catch { showGenericError() }

extension Sequence {
    func myMap<T>(_ transform: (Element) throws -> T) rethrows -> [T] { … }
}

let a = [1, 2].myMap { $0 * 2 }              // ✅ try 불필요 — 클로저가 안 던진다
let b = try [1, 2].myMap { try risky($0) }   // try 필요 — 클로저가 던진다

// Typed Throws 를 쓰면 에러 타입까지 전파된다
func measured<T, E: Error>(_ body: () throws(E) -> T) throws(E) -> T { try body() }
//   rethrows 보다 정밀하다 — 어떤 에러인지도 유지된다

// 부수적 실패 — 던지지 않고 기록한다
func trackEvent(_ e: Event) {
    do { try analytics.send(e) }
    catch {
        logger.notice("분석 전송 실패: \(error.localizedDescription, privacy: .public)")
        metrics.increment("analytics.send_failure")     // 지표로 추세를 본다
    }
}
//   호출자가 할 수 있는 일이 없으므로 던지지 않는다.
//   대신 30장 Q5 꼬리질문처럼 빈도를 관측한다.

Q3. 비가상화는 언제 일어나는가?

CS 원리

동적 디스패치는 "어느 구현을 부를지 실행 시점에 정한다"는 것이고, 그 대가로 간접 호출 + 인라인 불가가 따라온다. 인라인이 막히는 것이 더 큰 손실인 경우가 많다 — 인라인은 다른 최적화의 관문이기 때문이다.

비가상화는 정적 분석으로 동적 성질을 제거하는 최적화다. 핵심은 증명 가능성이고, 그것은 컴파일러가 얼마나 넓게 볼 수 있는가에 달렸다.

여기서 모듈 경계가 결정적이다. public·open 클래스는 모듈 밖에서 서브클래싱될 수 있으므로 WMO만으로는 비가상화를 기대할 수 없다. Q1에서 본 ABI 경계가 최적화에도 같은 방식으로 작용한다.

dynamic은 이 모든 것을 무효화한다 — 런타임 교체 가능성을 명시적으로 요구하므로 컴파일러가 증명을 포기한다. 메서드 스위즐링이나 KVO를 쓰려면 필요하지만(34장), 성능은 확실히 포기하는 선택이다.

iOS에서는

SIL에서 class_method가 function_ref로 바뀌는지로 확인한다.

class Base { func work() -> Int { 1 } }
final class Sealed { func work() -> Int { 2 } }

func callBase(_ b: Base) -> Int { b.work() }       // 모듈 내부라면 WMO 로 비가상화 가능
func callSealed(_ s: Sealed) -> Int { s.work() }   // final — 항상 직접 호출

open class Exposed { open func work() -> Int { 3 } }
public func callExposed(_ e: Exposed) -> Int { e.work() }
//   모듈 밖에서 서브클래싱될 수 있어 비가상화되지 않는다

실무에서 효과가 큰 조치는 순서가 있다.

1. WMO가 켜져 있는지 확인한다. 릴리스 빌드의 기본값이지만 설정이 바뀌어 있을 수 있다.
2. 모듈 밖에 공개할 이유가 없는 클래스를 internal로 둔다. public이 기본값처럼 붙어 있으면 최적화 기회가 사라진다.
3. 확장 가능성이 없는 클래스에 final을 붙인다. 의도도 드러나고 최적화도 확실해진다.

// 기본값을 final 로 두고 필요할 때만 연다
final class ViewModel { … }          // ✅ 상속 계획이 없으면
class BaseCoordinator { … }          // 상속이 설계의 일부일 때만

// 모듈 경계도 좁힌다
internal final class Cache { … }     // ✅ 밖에 낼 이유가 없다
public final class PublicAPI { … }   // public 이어도 final 이면 비가상화된다

dynamic이 필요한 경우는 제한적이다 — KVO, 메서드 스위즐링, 일부 테스트 대역. 이들은 성능을 포기하는 대가로 런타임 유연성을 산다(34장).

실험 · 도구

SIL로 비가상화 여부를 직접 확인한다.

cat > /tmp/dv.swift <<'SWIFT'
class Base { func work() -> Int { 1 } }
final class Sealed { func work() -> Int { 2 } }
public func a(_ b: Base) -> Int { b.work() }
public func b(_ s: Sealed) -> Int { s.work() }
SWIFT

# WMO + 최적화로 SIL 확인
swiftc -O -wmo -emit-sil /tmp/dv.swift 2>/dev/null | grep -E "class_method|function_ref.*work"
#   class_method 가 남아 있으면 가상 호출, function_ref 면 비가상화됐다

# WMO 를 끄면 결과가 달라지는지 비교
swiftc -O -emit-sil /tmp/dv.swift 2>/dev/null | grep -c "class_method"

빌드 설정을 확인한다.

# WMO 설정 확인 — 릴리스에서 wholemodule 이어야 한다
xcodebuild -showBuildSettings -configuration Release \
  | grep -E "SWIFT_COMPILATION_MODE|SWIFT_OPTIMIZATION_LEVEL"
#   SWIFT_COMPILATION_MODE = wholemodule
#   SWIFT_OPTIMIZATION_LEVEL = -O

# final 이 아닌 internal 클래스 — final 후보
grep -rnE "^ *(internal )?class [A-Z]" --include=*.swift . | grep -v final | head -20

# dynamic 사용처 — 성능을 포기한 자리
grep -rn "dynamic func\|@objc dynamic" --include=*.swift .

실제 효과는 Time Profiler로 확인한다 — 디스패치 자체보다 인라인이 막혀 생기는 손실이 크므로, 스택에서 작은 함수가 반복 등장하면 신호다(P0 15장 Q6).

프로젝트 적용

1. 릴리스 빌드의 WMO를 확인한다. 꺼져 있으면 가장 큰 최적화를 놓치고 있다.
2. final을 기본으로 삼는다. 상속이 설계의 일부일 때만 열어 둔다. 의도가 드러나는 부수 효과도 크다.
3. 접근 수준을 필요 이상으로 넓히지 않는다. public이 습관적으로 붙어 있으면 최적화가 막힌다(Q5의 package가 대안이다).
4. dynamic은 정말 필요할 때만 쓴다. KVO·스위즐링이 아니면 대개 불필요하다.
5. 측정 없이 final을 남발하지 않는다. 성능보다 설계 의도 표현이 주된 이유여야 한다.

꼬리 질문

protocol Shape { func area() -> Double }
struct Circle: Shape { let r: Double; func area() -> Double { .pi * r * r } }

func totalGeneric<S: Shape>(_ items: [S]) -> Double { items.reduce(0) { $0 + $1.area() } }
//   Circle 로 특수화되면 area() 가 인라인될 수 있다

func totalExistential(_ items: [any Shape]) -> Double { items.reduce(0) { $0 + $1.area() } }
//   원소마다 타입이 다를 수 있어 witness table 을 탄다

# ARC 트래픽 확인 — retain/release 가 뜨거운 경로에 있는지
swiftc -O -emit-sil MyFile.swift | grep -c "strong_retain\|strong_release"

# 할당 확인
swiftc -O -emit-sil MyFile.swift | grep -c "alloc_ref\|alloc_box"

Q4. 프로토콜 확장의 디스패치 함정은 무엇인가?

CS 원리

이 함정의 뿌리는 "오버라이드처럼 보이지만 오버라이드가 아니다"라는 데 있다.

클래스 상속에서 메서드를 재정의하면 vtable 슬롯이 교체된다. 그래서 부모 타입 변수로 불러도 자식 구현이 돈다. 이것이 다형성이다.

프로토콜에서는 요구사항일 때만 같은 일이 일어난다. 요구사항은 witness table에 슬롯을 만들고, conforming 타입이 그 슬롯을 채운다. 슬롯이 있으므로 실행 시점에 어느 구현인지 조회할 수 있다.

확장 전용 메서드는 다르다. 슬롯이 없으므로 조회할 것이 없다. 컴파일러는 호출부에서 보이는 정적 타입으로 어느 함수를 부를지 정하고 그것을 박는다. conforming 타입이 같은 이름의 메서드를 정의해도, 그것은 오버라이드가 아니라 이름이 같은 별개의 정적 함수를 하나 더 만든 것에 가깝다.

중요한 점은 제네릭 안에서도 똑같이 재현된다는 것이다. <T: P>에서 T가 무엇으로 특수화되든, 확장 전용 메서드 호출은 제약 타입(P)의 정적 타입으로 결정된다.

iOS에서는

재현이 간단하다.

protocol Greeter {
    func required() -> String        // 요구사항
}

extension Greeter {
    func required() -> String { "기본 required" }
    func extensionOnly() -> String { "기본 extensionOnly" }   // 요구사항이 아니다
}

struct Korean: Greeter {
    func required() -> String { "한국어 required" }
    func extensionOnly() -> String { "한국어 extensionOnly" }
}

let k = Korean()
let g: Greeter = k                    // 같은 값, 다른 정적 타입

k.required()          // "한국어 required"
g.required()          // "한국어 required"        ✅ 일관적

k.extensionOnly()     // "한국어 extensionOnly"
g.extensionOnly()     // "기본 extensionOnly"     ❌ 불일치

제네릭에서도 같다.

func callAll<T: Greeter>(_ v: T) {
    print(v.required())        // "한국어 required"
    print(v.extensionOnly())   // "기본 extensionOnly"  ← T 가 Korean 이어도 그렇다
}
callAll(Korean())

해법은 요구사항으로 올리는 것 하나뿐이다.

protocol Greeter2 {
    func required() -> String
    func wasExtensionOnly() -> String     // ✅ 요구사항으로 선언
}

extension Greeter2 {
    func wasExtensionOnly() -> String { "기본" }   // 기본 구현은 확장에 그대로 둔다
}
//   이제 conforming 타입이 재정의하면 프로토콜 타입으로 불러도 그 구현이 돈다

실무에서 이 함정이 드러나는 자리는 이렇다.

• 테스트 대역 — 프로토콜 타입으로 주입했는데 기본 구현이 돌아 대역이 무시된다.
• 기본 구현이 있는 프로토콜을 확장할 때 — 커스터마이징한 줄 알았는데 반영되지 않는다.
• 라이브러리 프로토콜 — 요구사항인지 확장인지 문서만 봐서는 모른다.

실험 · 도구

어느 쪽인지 확인하는 방법이 있다.

// (1) 프로토콜 선언을 직접 확인한다 — 요구사항 목록에 있는가
//     라이브러리라면 인터페이스 파일을 본다

# 모듈 인터페이스에서 프로토콜 요구사항 목록 확인
swiftc -emit-module-interface -enable-library-evolution MyLib.swift
grep -A20 "protocol Greeter" MyLib.swiftinterface
#   protocol 블록 안에 있으면 요구사항, extension 블록 안이면 확장 전용이다

# SIL 로 witness table 슬롯을 확인한다
swiftc -emit-sil /tmp/proto.swift 2>/dev/null | grep -A10 "sil_witness_table"
#   요구사항만 슬롯으로 나타난다

불일치를 테스트로 잡을 수도 있다.

import Testing

@Test func 프로토콜_타입으로_불러도_같은_구현이_돈다() {
    let concrete = Korean()
    let asProtocol: Greeter = concrete

    #expect(concrete.extensionOnly() == asProtocol.extensionOnly(),
            "확장 전용 메서드라 정적 바인딩됐다 — 요구사항으로 올려야 한다")
}
//   이 테스트가 실패하면 그 메서드는 요구사항이 아니다

프로젝트 적용

1. 재정의될 가능성이 있으면 요구사항으로 선언한다. "기본 구현만 쓸 것"이라고 확신할 때만 확장 전용으로 둔다.
2. 테스트 대역을 쓰는 프로토콜은 특히 확인한다. 대역이 무시되는 버그는 테스트가 통과하는데 프로덕션이 다르게 동작하는 형태로 나타난다.
3. 확장 전용 메서드는 이름을 구별한다. 요구사항과 같은 이름을 피하면 착각 자체가 줄어든다.
4. 라이브러리 프로토콜을 커스터마이징할 때 인터페이스를 확인한다. 요구사항이 아니면 재정의해도 반영되지 않는다.
5. 불일치 테스트를 핵심 프로토콜에 둔다. 리팩터링 중 요구사항이 확장으로 밀려나는 것을 잡는다.

꼬리 질문

final class SpyLoader: Loader {
    private(set) var loadCallCount = 0
    func load() -> Data { loadCallCount += 1; return Data() }
}

@Test func 대역이_실제로_호출된다() {
    let spy = SpyLoader()
    let sut = Service(loader: spy)
    _ = sut.run()
    #expect(spy.loadCallCount == 1, "대역이 호출되지 않았다 — 확장 전용 메서드일 수 있다")
}

protocol Cache {
    func get(_ key: String) -> Data?
    func clear()                        // ✅ 요구사항
}

extension Cache {
    func clear() { /* 아무것도 안 함 */ }   // 기본 구현
}
//   요구사항이므로 witness table 슬롯이 생기고,
//   재정의하면 프로토콜 타입으로 불러도 그 구현이 돈다

Q5. package 접근 수준은 무엇을 푸는가?

CS 원리

접근 제어의 목적은 변경 가능한 표면적을 줄이는 것이다. 공개된 것은 바꾸면 남이 깨지므로 사실상 계약이 된다 — 31장 Q7·32장 Q2·33장 Q1에서 반복된 원리다.

문제는 모듈 분할이 접근 제어의 단위와 어긋난다는 데 있다. 하나의 논리적 제품이 여러 모듈로 나뉘면, 제품 내부인데 모듈은 다른 상황이 생긴다.

package의 값어치는 SemVer 부담이 없다는 점이다. 모듈 밖 어디에도 노출되지 않으므로 시그니처를 자유롭게 바꿀 수 있다. public으로 뚫으면 그 순간부터 남이 쓸 수 있고, 바꾸면 깨진다.

부수 효과로 최적화 여지도 지킨다 — Q3에서 본 대로 public 클래스는 모듈 밖 서브클래싱 가능성 때문에 비가상화가 막힌다. package는 패키지 밖으로 나가지 않으므로 그 제약이 덜하다.

재미있는 점은 접근 제어가 컴파일러에게는 가시성 문제이지 권한 검사가 아니라는 것이다. 접근 불가 시 에러가 "권한 없음"이 아니라 "스코프에 없음"으로 뜬다.

iOS에서는

선언은 다른 접근 수준과 같은 방식이다.

// CoreKit 모듈
package struct InternalConfig {          // 패키지 안에서만 보인다
    package let endpoint: URL
    package init(endpoint: URL) { self.endpoint = endpoint }
}

package func makeClient(_ c: InternalConfig) -> Client { … }

// FeatureA 모듈 — 같은 패키지라 보인다
import CoreKit
let client = makeClient(InternalConfig(endpoint: url))   // ✅

// 외부 앱 — 안 보인다
import CoreKit
// makeClient(...)      // ❌ cannot find 'makeClient' in scope

SwiftPM에서는 자동으로 동작한다.

// Package.swift — name 이 곧 package-name 이 된다
let package = Package(
    name: "MyApp",                    // ← 이 이름이 모든 타깃에 -package-name 으로 주입된다
    targets: [
        .target(name: "CoreKit"),
        .target(name: "FeatureA", dependencies: ["CoreKit"]),
    ]
)

수동 빌드에서는 플래그를 직접 맞춰야 한다.

# 같은 -package-name 이면 package 심볼이 보인다
swiftc -emit-module -module-name CoreKit -package-name MyApp CoreKit.swift
swiftc -emit-module -module-name FeatureA -package-name MyApp -I . FeatureA.swift   # ✅

# 다르면 "cannot find in scope" 로 실패한다
swiftc -emit-module -module-name FeatureB -package-name Other -I . FeatureB.swift   # ❌

Swift 6.0의 SE-0409는 import 선언에도 접근 수준을 붙일 수 있게 해 의존성 자체가 새는 것도 막는다.

package import CoreKit      // CoreKit 의존이 이 모듈 밖으로 전파되지 않는다
internal import Logging     // 이 모듈 내부에서만 쓴다
//   공개 API 시그니처에 그 타입이 등장하면 컴파일 에러로 막힌다

실험 · 도구

판정 기준이 정말 플래그인지 직접 확인할 수 있다.

mkdir -p /tmp/pkg && cd /tmp/pkg

cat > Core.swift <<'SWIFT'
package func secret() -> Int { 42 }
SWIFT

cat > User.swift <<'SWIFT'
import Core
public func use() -> Int { secret() }
SWIFT

# 같은 package-name — 성공
swiftc -emit-module -module-name Core -package-name MyPkg Core.swift
swiftc -typecheck -module-name User -package-name MyPkg -I . User.swift && echo "✅ 같은 패키지"

# 다른 package-name — 실패
swiftc -typecheck -module-name User -package-name Other -I . User.swift \
  || echo "❌ 다른 패키지 — cannot find 'secret' in scope"

기존 코드에서 public을 package로 내릴 후보를 찾는다.

# public 인데 외부에서 안 쓰이는 심볼 찾기 (근사)
grep -rhoE "public (func|struct|class|enum|var|let) +[A-Za-z_]+" \
     --include=*.swift Sources/ | awk '{print $3}' | sort -u > /tmp/publics.txt

# 앱 타깃에서 실제로 참조되는지 대조
while read sym; do
  n=$(grep -rc "\b$sym\b" App/ 2>/dev/null | awk -F: '{s+=$2} END {print s+0}')
  [ "$n" = "0" ] && echo "package 후보: $sym"
done < /tmp/publics.txt | head -20

프로젝트 적용

1. 모듈 간 통로를 package로 내린다. public으로 뚫린 내부 API가 가장 흔한 개선 대상이다.
2. public은 진짜 외부 계약에만 남긴다. 그래야 SemVer 관리 범위가 명확해진다.
3. package import로 의존 전파를 막는다. 내부 로깅 라이브러리가 외부까지 노출되는 문제를 끊는다.
4. 수동 빌드 시스템을 쓴다면 -package-name을 통일한다. 디렉터리 구조가 아니라 플래그가 기준이다.
5. 내리는 작업은 점진적으로 한다. public → package는 외부 사용처가 없을 때만 안전하다.

꼬리 질문

# 모든 타깃을 한 번에 빌드해 확인
xcodebuild build -scheme AppAllTargets -destination 'generic/platform=iOS'
swift build --build-tests

import Logging          // 일반 import

public struct Service {
    public func run(logger: Logger) { … }    // ⚠️ Logger 가 공개 API 에 노출된다
}
//   우리 모듈을 쓰는 쪽이 Logging 을 import 해야 한다 — 의존이 전파됐다

internal import Logging      // ✅ 이 모듈 내부에서만 쓴다

public struct Service {
    private let logger: Logger           // ✅ 내부 사용은 문제없다
    public func run() { logger.info("…") }
    // public func run(logger: Logger)   // ❌ 컴파일 에러 — 공개 API 에 못 쓴다
}

Q6. 전역 초기화는 언제 일어나며 무엇을 보장하는가?

CS 원리

지연 초기화는 "필요할 때 한 번만"이라는 요구를 푸는 것이고, 동시성이 들어오면 "한 번만"이 어려워진다.

순진한 구현은 이렇다 — "값이 없으면 만들고 저장한다". 그런데 두 스레드가 동시에 "없다"고 판단하면 둘 다 만든다. 전형적인 check-then-act 경쟁이다(P0 02장 Q3).

이를 막으려면 검사와 생성이 원자적이어야 한다. swift_once는 이 계약을 제공한다 — 여러 스레드가 진입해도 초기화 블록은 정확히 한 번 실행되고, 나머지는 완료를 기다렸다가 같은 값을 본다.

여기서 세 가지가 서로 다른 개념임을 구분해야 한다.

이 구분이 실무에서 자주 뭉개진다. static var count를 만들고 count += 1을 여러 스레드에서 하면, 초기화는 안전하지만 증가는 안전하지 않다. 실측으로 10,000번 동시 실행하면 기대값 10000 대신 2607·2551·2492 같은 값이 나온다.

lazy var가 보장을 주지 않는 이유는 인스턴스 프로퍼티이기 때문이다. 전역과 달리 인스턴스마다 존재하므로, 모든 인스턴스에 once 토큰을 두면 비용이 크다. Swift는 성능을 택하고 보장을 포기했고, TSPL도 이를 명시적으로 경고한다.

iOS에서는

싱글턴 패턴이 안전한 이유가 swift_once다.

final class Analytics {
    static let shared = Analytics()      // ✅ 정확히 한 번 초기화된다
    private init() { /* 무거운 준비 작업 */ }
}
//   여러 스레드가 동시에 Analytics.shared 를 처음 만져도 init 은 한 번만 돈다

lazy var는 다르다.

final class ViewModel {
    lazy var formatter = makeExpensiveFormatter()   // ⚠️ 동시 접근 시 여러 번 실행될 수 있다
}

// 안전하게 하려면 액터에 가두거나
actor SafeModel {
    lazy var formatter = makeExpensiveFormatter()   // 액터 격리로 직렬화된다
}

// 메인 액터에 두거나
@MainActor final class UIModel {
    lazy var formatter = makeExpensiveFormatter()   // 메인에서만 접근되므로 안전
}

static var의 함정은 더 자주 사고를 낸다.

// ❌ 초기화만 안전하고 변경은 경쟁한다
enum Counter { static var count = 0 }
// 여러 스레드에서 Counter.count += 1 → 값이 유실된다

// ✅ 동기화를 명시한다
import Synchronization
enum SafeCounter {
    static let value = Atomic<Int>(0)          // Swift 6 Synchronization (35장)
}
SafeCounter.value.add(1, ordering: .relaxed)

// ✅ 또는 액터로 감싼다
actor CounterActor { private(set) var count = 0; func inc() { count += 1 } }

Swift 6의 엄격 동시성은 이 문제를 컴파일 타임에 잡는다 — 전역 가변 상태에 대해 동시성 안전을 증명하라고 요구한다(35장).

실험 · 도구

보장 차이를 직접 재현해 보자.

import Foundation

final class LazyBox {
    var initCount = 0
    lazy var value: Int = { initCount += 1; Thread.sleep(forTimeInterval: 0.001); return 42 }()
}

// lazy var — 동시 접근 시 여러 번 실행된다
for trial in 1...3 {
    let box = LazyBox()
    DispatchQueue.concurrentPerform(iterations: 50) { _ in _ = box.value }
    print("lazy var 시도 \(trial): 초기화 \(box.initCount)회")
}
// lazy var 시도 1: 초기화 14회
// lazy var 시도 2: 초기화 11회
// lazy var 시도 3: 초기화 11회

// static let — 항상 1회
enum OnceBox {
    nonisolated(unsafe) static var initCount = 0
    static let value: Int = { initCount += 1; return 42 }()
}
DispatchQueue.concurrentPerform(iterations: 50) { _ in _ = OnceBox.value }
print("static let: 초기화 \(OnceBox.initCount)회")     // 항상 1회

static var의 원자성 부재도 확인된다.

enum Racy { nonisolated(unsafe) static var count = 0 }
DispatchQueue.concurrentPerform(iterations: 10_000) { _ in Racy.count += 1 }
print(Racy.count)      // 10000 이 아니다 — 2607 / 2551 / 2492 같은 값

# SIL 에서 once 호출을 확인한다
swiftc -emit-sil /tmp/once.swift 2>/dev/null | grep -B2 -A2 'builtin "once"'

# Thread Sanitizer 로 실제 경쟁을 잡는다 (P0 15장 Q6)
xcodebuild test -scheme App -enableThreadSanitizer YES

프로젝트 적용

1. 지연 초기화가 필요하면 static let을 쓴다. lazy var는 단일 스레드 접근이 확실할 때만.
2. lazy var를 쓸 거면 격리를 명시한다. @MainActor나 액터 안에 두면 안전해진다.
3. static var를 전역 가변 상태로 쓰지 않는다. 초기화만 안전할 뿐 변경은 무방비다.
4. Swift 6 엄격 동시성을 켠다. 이 문제군을 컴파일 타임에 잡아 준다(35장).
5. Thread Sanitizer를 CI에 넣는다. 이 계열 경쟁은 재현이 드물어 수동 테스트로는 안 잡힌다.

꼬리 질문

// ⚠️ 시작 직후 전부 만지면 지연의 이점이 사라진다
func application(_ app: UIApplication, didFinishLaunchingWithOptions o: [...]) -> Bool {
    _ = Analytics.shared
    _ = Database.shared
    _ = ImageCache.shared      // 전부 여기서 초기화된다
    return true
}

// ✅ 정말 필요한 것만 시작 시에, 나머지는 첫 사용 시점에
func application(...) -> Bool {
    Analytics.shared.start()   // 크래시 수집은 이른 시점이 맞다 (P1 18장)
    return true
}

enum Config { static let apiBase = URL(string: "https://api.example.com")! }   // ✅

@MainActor final class AppState { static let shared = AppState(); var count = 0 }
//   메인 액터 격리로 동시 접근이 막힌다

import Synchronization
enum Metrics {
    static let counter = Atomic<Int>(0)
}
Metrics.counter.add(1, ordering: .relaxed)     // ✅ 원자적

@MainActor final class ViewModel {
    lazy var formatter = makeFormatter()      // 메인에서만 접근되므로 안전
}

// 인스턴스마다 필요 없으면 static let 이 낫다
enum Formatters { static let iso = ISO8601DateFormatter() }

// 직접 관리할 거면 lazy 를 쓰지 않는다
private var _cache: Formatter?
private let lock = NSLock()
var formatter: Formatter {
    lock.lock(); defer { lock.unlock() }
    if let c = _cache { return c }
    let f = makeFormatter(); _cache = f; return f
}
//   동작하지만, 대개는 @MainActor 나 static let 이 더 낫다

출처 · 참고자료