34 · Foundation과 Objective-C 상호운용

Swift 앱은 순수 Swift로 보이지만 그 아래 상당 부분이 Objective-C 유산 위에 서 있다. Foundation, UIKit, 그리고 KVO 같은 메커니즘이 그렇다.

이 챕터는 그 경계에서 실제로 무슨 일이 일어나는지를 다룬다. 캐스팅 하나가 언제 공짜이고 언제 비싼지, 에러가 어떻게 두 세계를 오가는지, 관찰이 왜 @objc만으로는 동작하지 않는지.

동시에 이 경계는 지금 이동 중이다. Foundation의 내부 구현이 Objective-C에서 Swift로 재작성되고 있고, KVO는 Observation으로 대체되고 있다. 그래서 무엇이 이미 바뀌었고 무엇이 남았는지를 아는 것 자체가 실무 지식이다.

Q1. Foundation은 지금 무엇으로 만들어져 있는가?

CS 원리

이것은 인터페이스를 유지한 채 구현을 교체하는 대규모 사례다. P0 17장의 정보 은닉이 실제로 값을 하는 순간이다 — API가 구현 세부를 감추고 있었기 때문에 내부를 통째로 갈아끼울 수 있었다.

재작성의 동기는 계층 제거다. 기존 Foundation은 Objective-C로 작성돼 있어, Swift에서 쓸 때마다 브리징 계층을 통과했다. 값 타입을 참조 타입으로 감싸고, 참조 카운팅과 메시지 디스패치를 거치고, 다시 값으로 돌아왔다.

31장 Q6에서 본 JSON 디코딩 개선의 원인이 정확히 이것이다 — 리플렉션이 아니라 JSONSerialization이 만드는 Objective-C 객체 그래프와의 브리징(swift_dynamicCast) 제거가 개선을 만들었다.

또 다른 동기는 이식성이다. Objective-C 런타임은 Apple 플랫폼에 묶여 있어, Linux·Windows에서는 별도 구현(swift-corelibs-foundation)이 필요했다. 순수 Swift로 재작성하면 하나의 구현으로 통합된다.

여기서 실무적으로 중요한 것은 수치를 정확히 인용하는 태도다. "Foundation이 전반적으로 빨라졌다"는 검증할 수 없는 서술이고, 공개된 것은 특정 영역의 특정 수치 넷이다.

iOS에서는

실무에 미치는 영향은 세 갈래다.

(1) 성능이 조용히 좋아졌다. 코드를 안 바꿔도 OS를 올리면 개선된다. 다만 최소 지원 버전에 따라 사용자마다 다르다.

// 같은 코드가 iOS 18+ 에서 더 빠르게 돈다
let items = try JSONDecoder().decode([Item].self, from: data)
//   구현이 바뀐 것이지 우리 코드가 바뀐 게 아니다

(2) 미묘한 동작 차이가 있을 수 있다. 재작성은 동작 호환을 목표로 하지만, 경계 사례에서 차이가 드러날 수 있다.

// 검증할 가치가 있는 영역
// - URL 파싱: RFC 3986 파서로 통일되며 동작이 바뀐 사례가 있다 (27장 Q6)
// - Calendar 경계: DST·윤년 계산 (29장)
// - 날짜 파싱 관용도: 소수 초 처리 등 (29장 Q5 꼬리질문)

(3) 서버 사이드·크로스 플랫폼이 쉬워진다. Linux·Windows에서 같은 구현이 돌므로 플랫폼별 차이가 줄어든다 — 29장 Q5에서 본 DateFormatter의 Linux 스레드 안전성 이슈 같은 것들이 여기 해당한다.

// 새 API 는 순수 Swift 로 설계돼 있어 크로스 플랫폼이 자연스럽다
import FoundationEssentials       // Foundation 의 코어만 — 더 가볍다
//   서버 사이드에서는 전체 Foundation 대신 이쪽을 import 할 수 있다

실험 · 도구

어느 구현이 도는지 확인하는 방법이다.

# 앱이 링크한 Foundation 을 확인한다
otool -L YourApp.app/YourApp | grep -i foundation

# 런타임에 실제 클래스를 확인 (브리징된 타입의 정체)

import Foundation

// 브리징된 객체의 실제 클래스를 본다 — Q5 에서 다시 쓰는 기법이다
let s = "hello"
print(object_getClass(s as NSString) ?? "nil")
//   _NSCFString · NSTaggedPointerString 등 구현체 이름이 드러난다

let d = Data([1,2,3])
print(object_getClass(d as NSData) ?? "nil")

성능 변화를 확인하려면 OS 버전별로 재야 한다.

// 같은 벤치를 여러 시뮬레이터에서 돌려 비교한다
let clock = ContinuousClock()
let t = clock.measure {
    for _ in 0..<1000 { _ = try? JSONDecoder().decode([Item].self, from: sample) }
}
print("\(ProcessInfo.processInfo.operatingSystemVersionString): \(t)")

# 여러 OS 버전 시뮬레이터에서 같은 테스트를 돌린다
for os in "17.5" "18.0"; do
  xcodebuild test -scheme Bench \
    -destination "platform=iOS Simulator,name=iPhone 15,OS=$os" 2>&1 | grep "operatingSystem"
done

프로젝트 적용

1. 성능 개선을 우리 공로로 기록하지 않는다. OS 업데이트로 지표가 좋아졌으면 그렇게 기록해야 다음 판단이 정확해진다(P1 21장 Q5의 릴리스 태깅).
2. 최소 지원 버전을 올릴 때 이 개선을 근거로 쓸 수 있다. 다만 수치는 공개된 넷만 인용한다.
3. 경계 동작을 회귀 테스트로 고정한다. URL 파싱·날짜 파싱은 구현 교체의 영향을 받는 영역이다.
4. 서버 사이드에서는 FoundationEssentials를 검토한다. 전체 Foundation보다 가볍다.
5. "Foundation은 느리다"는 오래된 인식을 갱신한다. 특히 JSON 디코딩은 크게 달라졌다.

꼬리 질문

// 성능 이벤트에 OS 버전을 항상 붙인다
span.setTag("os_version", ProcessInfo.processInfo.operatingSystemVersionString)
span.setTag("app_version", BuildInfo.release)      // P1 21장 Q5

#if canImport(FoundationEssentials)
import FoundationEssentials
#else
import Foundation
#endif
//   크로스 플랫폼 패키지에서 흔히 쓰는 패턴이다

// ❌ 출력을 그대로 고정 — 구현 교체로 깨질 수 있다
#expect(date.formatted() == "2026. 8. 15.")

// ✅ 성질을 검사
#expect(date.formatted(.iso8601) == "2026-08-15T00:00:00Z")   // 이건 규격이 고정이다
#expect(Calendar(identifier: .gregorian).component(.year, from: date) == 2026)

Q2. Toll-Free Bridging의 실제 비용은 얼마인가?

CS 원리

두 계층을 구분하는 것이 이 문항의 전부다.

첫 번째가 공짜인 이유는 같은 객체이기 때문이다. Apple이 CoreFoundation과 Foundation을 설계할 때 메모리 레이아웃을 일치시켜, 같은 메모리를 두 타입 시스템에서 다르게 볼 수 있게 했다.

두 번째는 근본적으로 다른 문제다. Swift의 Array<Int>는 연속된 정수 버퍼이고 NSArray는 객체 포인터 배열이다. 표현이 다르므로 변환이 필요하다.

여기서 지연(lazy) 전략이 나온다. 캐스트 시점에 전부 변환하면 비싸므로, 래퍼만 만들어 두고 실제 원소를 꺼낼 때 변환한다. 그래서 비용이 캐스트가 아니라 소비 시점으로 미뤄진다.

이것은 측정을 오도하기 쉬운 구조다. 캐스트만 재면 "공짜"라는 결론이 나오는데, 실제 사용 경로 전체를 재야 진짜 비용이 보인다.

iOS에서는

실무에서 이 비용이 드러나는 자리는 ObjC API 경계다.

import Foundation

let numbers = Array(0..<100_000)

// 캐스트 자체는 거의 공짜다 — 지연 래퍼만 만든다
let ns = numbers as NSArray                    // 약 0.0055ms

// 실제 비용은 순회할 때 발생한다
for case let n as Int in ns { _ = n }          // 약 16ms — NSNumber 박싱

// 27장 Q4 꼬리질문에서 본 원칙이 여기도 적용된다
// ❌ 루프 안에서 매번 브리징
for i in 0..<1000 { _ = (text as NSString).substring(to: 5) }

// ✅ 한 번만 변환해 재사용
let nsText = text as NSString
for i in 0..<1000 { _ = nsText.substring(to: 5) }

어떤 타입이 어느 계층인지 알아 두면 판단이 빨라진다.

• 진짜 공짜 — CFString↔NSString, CFArray↔NSArray, CFDictionary↔NSDictionary 등 CF/NS 쌍.
• 거의 공짜 — Data↔NSData(Q3), Date↔NSDate. 값 타입이지만 표현이 단순하다.
• 비쌀 수 있음 — Array·Dictionary·Set의 원소가 값 타입일 때. 박싱이 필요하다.
• 중간 — String↔NSString. 짧으면 싸고, UTF-16 접근이 오면 변환이 생길 수 있다(27장 Q4 꼬리질문).

가장 확실한 대응은 브리징 자체를 줄이는 것이다.

// ObjC API 를 쓰더라도 경계를 좁게 유지한다
func processImages(_ urls: [URL]) -> [Result] {
    // 내부는 전부 Swift 타입으로
    urls.compactMap { url in
        // 경계에서만 최소한으로 변환
        guard let cg = CGImageSourceCreateWithURL(url as CFURL, nil) else { return nil }
        …
    }
}

실험 · 도구

비용이 어디서 발생하는지 나눠 재면 분명해진다.

import Foundation

let numbers = Array(0..<100_000)
let clock = ContinuousClock()

// (1) 캐스트만
let castTime = clock.measure { _ = numbers as NSArray }

// (2) 캐스트 + 순회
let fullTime = clock.measure {
    let ns = numbers as NSArray
    for case let n as Int in ns { _ = n }
}

// (3) 비교군 — Swift 배열 순회
let nativeTime = clock.measure { for n in numbers { _ = n } }

print("캐스트만:   \(castTime)")      // 약 0.0055ms
print("캐스트+순회: \(fullTime)")     // 약 16ms
print("네이티브:   \(nativeTime)")    // 훨씬 빠르다

// 지연 래퍼의 정체를 확인한다
print(object_getClass(numbers as NSArray) ?? "nil")
//   __SwiftDeferredNSArray — 아직 변환하지 않았다는 뜻이다

코드베이스에서 브리징이 뜨거운 경로에 있는지 찾는다.

# 루프 안 브리징 — 반복 변환 후보
grep -rn -B3 "as NSString\|as NSArray\|as NSDictionary" --include=*.swift . \
  | grep -E "for |while |\.map|\.forEach" | head -20

# CF 타입 캐스트 — 이쪽은 대체로 공짜다
grep -rn "as CF[A-Z]" --include=*.swift . | head

실제 병목인지는 Time Profiler에서 bridge·NSNumber 관련 프레임이 보이는지로 확인한다(P0 15장 Q6).

프로젝트 적용

1. 루프 안에서 브리징하지 않는다. 한 번 변환해 재사용한다 — 가장 효과가 큰 조치다.
2. ObjC API 경계를 좁게 유지한다. 내부 로직은 Swift 타입으로 다루고 경계에서만 변환한다.
3. 컬렉션 브리징을 특히 주의한다. 원소가 값 타입이면 개수에 비례하는 박싱이 일어난다.
4. "toll-free"라는 말에 속지 않는다. 두 계층 중 어느 쪽인지 확인한다.
5. 측정은 사용 경로 전체로 한다. 캐스트만 재면 비용을 놓친다.

꼬리 질문

// ❌ NSString 관용구
let ext = (path as NSString).pathExtension
let joined = (base as NSString).appendingPathComponent(name)

// ✅ Swift 대안
let ext = URL(filePath: path).pathExtension
let joined = URL(filePath: base).appending(path: name).path()

// ❌ NSRegularExpression + NSRange
// ✅ Swift Regex (27장 Q7)

enum LegacyText {
    /// ObjC 라이브러리 경계 — 여기서만 변환한다
    static func highlight(_ text: String, pattern: String) -> [Range<String.Index>] {
        let ns = text as NSString          // 한 번만
        let re = try? NSRegularExpression(pattern: pattern)
        let all = re?.matches(in: text, range: NSRange(location: 0, length: ns.length)) ?? []
        return all.compactMap { Range($0.range, in: text) }   // Swift 범위로 돌려준다
    }
}

let dict = Dictionary(uniqueKeysWithValues: (0..<10_000).map { ("key\($0)", $0) })
let clock = ContinuousClock()

let castOnly = clock.measure { _ = dict as NSDictionary }
let withLookup = clock.measure {
    let ns = dict as NSDictionary
    _ = ns["key5000"]                      // 조회 한 번이 변환을 유발할 수 있다
}
print("캐스트: \(castOnly)\n조회 포함: \(withLookup)")

Q3. Data는 무엇을 감추고 있는가?

CS 원리

이것은 태그된 표현(tagged representation)의 사례다. 하나의 타입이 여러 내부 표현을 가지고, 값 안의 태그로 어느 것인지 구분한다.

27장 Q4의 스몰 스트링 최적화와 같은 발상이다 — 작은 값은 인라인으로, 큰 값은 힙 참조로. Data는 여기에 매핑된 파일이라는 표현을 하나 더 갖는다.

마지막이 중요하다. Data(contentsOf:options: .mappedIfSafe)로 읽으면 파일이 가상 메모리에 매핑되어, 실제 바이트는 접근할 때 페이지 폴트로 올라온다(P0 01장 Q7). 그래서 10GB 파일도 Data로 열 수 있지만, 전부 순회하면 그만큼 읽는다.

여러 표현을 담으려면 값이 커진다. 16바이트인 이유가 이것이고, 이는 표현력과 크기의 트레이드오프다.

또 하나 알아 둘 것은 연속성이다. DataProtocol은 여러 조각으로 나뉜(discontiguous) 데이터를 허용하지만, 실측으로 Data는 400MB 파일에 append를 반복해도 항상 연속 버퍼로 정리됐다(regions.count == 1). 진짜 discontiguous 사례는 DispatchData에서만 나왔다.

iOS에서는

메모리 매핑이 큰 파일 처리의 열쇠다.

import Foundation

// ❌ 전체를 RAM 으로 읽는다 — 400MB 파일이면 400MB 를 쓴다 (P0 10장 Q2)
let all = try Data(contentsOf: bigFileURL)

// ✅ 매핑 — 가상 주소만 잡고 실제 페이지는 접근 시 올라온다
let mapped = try Data(contentsOf: bigFileURL, options: .mappedIfSafe)
let header = mapped.prefix(1024)              // 앞 1KB 만 실제로 읽힌다

다만 매핑에도 대가가 있다.

• 전부 순회하면 결국 다 읽는다 — 페이지 폴트가 반복된다.
• 파일이 바뀌거나 삭제되면 동작이 정의되지 않을 수 있어 .mappedIfSafe가 안전 판단을 한다.
• 메모리 압박 시 깨끗한 페이지는 버려졌다 다시 읽히므로, Jetsam 관점에서는 유리하다(P0 01장 Q8).

CoW 성질도 실무에 영향을 준다.

var a = Data(repeating: 0, count: 10_000_000)
var b = a                    // 복사가 아니다 — 버퍼를 공유한다
b[0] = 1                     // 여기서 실제 복사가 일어난다 (10MB)

// 27장 Q5 의 슬라이스 문제도 그대로 적용된다
let slice = a[0..<10]        // 원본 버퍼를 붙잡는다
let detached = Data(a[0..<10])   // ✅ 떼어낸다

브리징은 상대적으로 싸다 — NSData와 표현이 가까워 컬렉션 브리징(Q2) 같은 박싱이 없다.

실험 · 도구

표현 차이를 직접 관찰해 보자.

import Foundation

print(MemoryLayout<Data>.size)        // 16
print(MemoryLayout<[UInt8]>.size)     // 8

// 매핑 여부에 따라 메모리 사용이 다르다
func rssMB() -> Double { /* 27장 Q5 의 rssMB 사용 */ 0 }

print("시작: \(rssMB())")
let full = try Data(contentsOf: bigURL)                       // 전체 로드
print("전체 로드: \(rssMB())")

let mapped = try Data(contentsOf: bigURL, options: .mappedIfSafe)
print("매핑: \(rssMB())")                                      // 거의 안 는다
_ = mapped.reduce(0, &+)                                       // 전부 순회하면
print("순회 후: \(rssMB())")                                    // 여기서 는다

연속성도 확인할 수 있다.

var d = Data()
for _ in 0..<1000 { d.append(Data(repeating: 0, count: 400_000)) }
print(d.regions.count)        // 1 — 항상 연속 버퍼로 정리된다

import Dispatch
var dd = DispatchData.empty
for _ in 0..<3 { dd.append(DispatchData(bytes: UnsafeRawBufferPointer(start: nil, count: 0))) }
//   DispatchData 는 여러 조각을 유지할 수 있다

# 프로세스의 매핑 상태를 본다 (macOS)
vmmap $(pgrep MyApp) | grep -i "mapped file" | head

# 큰 파일을 전체 로드하는 코드 찾기 — 매핑 후보
grep -rn "Data(contentsOf:" --include=*.swift . | grep -v "mapped"

프로젝트 적용

1. 큰 파일은 .mappedIfSafe로 연다. 헤더만 보거나 일부만 쓰는 경우 메모리를 크게 아낀다.
2. 전부 순회할 거면 매핑 이득이 없다. 스트리밍 처리로 바꾸는 편이 낫다.
3. Data 슬라이스를 오래 보관하지 않는다. 27장 Q5와 같은 문제다 — Data(slice)로 떼어낸다.
4. Data를 로그에 찍지 않는다. 바이너리가 그대로 남고 PII가 섞일 수 있다(P1 23장).
5. 메모리 지표를 볼 때 매핑을 구분한다. 매핑된 페이지는 깨끗한 페이지라 압박 시 버려질 수 있어, dirty 메모리와 성격이 다르다(P0 01장).

꼬리 질문

// 스트리밍 — 메모리를 일정하게 유지한다
let handle = try FileHandle(forReadingFrom: url)
defer { try? handle.close() }                     // 32장 Q7 의 defer 용법

while let chunk = try handle.read(upToCount: 1 << 20), !chunk.isEmpty {
    process(chunk)                                 // 1MB 씩
}

// ❌ 실패를 무시한다
let s = String(data: data, encoding: .utf8) ?? ""    // 빈 문자열이 되어 원인을 잃는다

// ✅ 실패를 구분한다
guard let s = String(data: data, encoding: .utf8) else {
    logger.error("UTF-8 디코딩 실패 — \(data.count) 바이트, 앞 16바이트: \(data.prefix(16).map { String(format: "%02X", $0) }.joined(separator: " "), privacy: .public)")
    throw DecodeError.invalidEncoding
}

// 청크 경계 문제 — 누적 버퍼를 두고 완전한 부분만 디코딩한다
var pending = Data()
func feed(_ chunk: Data) {
    pending.append(chunk)
    // UTF-8 은 자기 동기화 가능하므로 마지막 불완전 시퀀스를 남긴다
    while let (text, consumed) = decodeLongestValidPrefix(pending) {
        emit(text); pending.removeFirst(consumed)
    }
}

let original = try Data(contentsOf: url)      // 100MB
var copy = original                            // 아직 100MB (공유)
copy[0] = 0                                    // 여기서 +100MB — 순간 200MB

// ✅ 원본이 더 필요 없으면 명시적으로 놓아준다
var buffer = try Data(contentsOf: url)
process(&buffer)                    // inout 으로 넘기면 불필요한 복사가 줄어든다

// ✅ 새 버퍼를 만들 거면 예약해 재할당을 줄인다
var out = Data(); out.reserveCapacity(expectedSize)

// ✅ 수정이 잦으면 [UInt8] 이 나을 수 있다 — 표현이 단순하다

Q4. NSError 브리징에서는 무엇이 오가는가?

CS 원리

두 에러 모델은 구조가 다르다.

브리징은 이 구조 차이를 메우는 사상이다. Swift 타입에는 domain·code가 없으므로 기본값을 만들어 낸다 — 타입 이름과 케이스 순번이다.

여기서 취약점이 하나 생긴다. 케이스 순번이 코드가 되므로, 케이스 순서를 바꾸면 코드가 바뀐다. 저장되거나 전송된 에러 코드가 있다면 의미가 달라진다 — 31장 Q7의 의미 변경과 같은 종류의 위험이다.

그래서 안정적인 코드가 필요하면 CustomNSError로 명시해야 한다. 이는 암묵적 기본값에 의존하지 말라는 이 티어의 반복 주제와 같다.

역방향 변환이 검증을 거치는 것도 중요하다. 아무 NSError나 Swift 타입으로 바뀌면 거짓 매칭이 생기므로, domain과 code가 맞을 때만 변환된다.

iOS에서는

기본 브리징은 아무 설정 없이 동작한다.

import Foundation

enum AppError: Error {
    case notFound        // code 0
    case timeout         // code 1
    case invalid(String) // code 2
}

let ns = AppError.timeout as NSError
ns.domain              // "MyApp.AppError" 형태의 mangled name
ns.code                // 1 — 선언 순번
//   ⚠️ 케이스 순서를 바꾸면 code 가 바뀐다

안정적인 코드가 필요하면 명시한다.

enum PaymentError: Error {
    case declined, insufficientFunds, networkFailure
}

extension PaymentError: CustomNSError {
    static var errorDomain: String { "com.example.payment" }   // ✅ static var

    var errorCode: Int {
        switch self {
        case .declined:          return 1001    // 명시적 — 순서를 바꿔도 안전하다
        case .insufficientFunds: return 1002
        case .networkFailure:    return 1003
        }
    }

    var errorUserInfo: [String: Any] {
        ["retryable": self == .networkFailure]
    }
}

extension PaymentError: LocalizedError {
    var errorDescription: String? {
        switch self {
        case .declined:          return String(localized: "결제가 거절되었습니다")
        case .insufficientFunds: return String(localized: "잔액이 부족합니다")
        case .networkFailure:    return String(localized: "네트워크 오류가 발생했습니다")
        }
    }
}
//   두 프로토콜은 관심사가 다르므로 함께 준수하는 것이 자연스럽다

localizedDescription이 어디서 오는지 이해하면 혼란이 줄어든다.

let e: Error = PaymentError.declined
e.localizedDescription        // LocalizedError.errorDescription 이 채운 값

let e2: Error = AppError.notFound
e2.localizedDescription       // LocalizedError 미준수 — 일반적인 기본 문구가 나온다
//   "The operation couldn't be completed. (MyApp.AppError error 0.)"

이 기본 문구가 사용자에게 그대로 노출되는 것이 흔한 사고다 — 31장 Q4의 원칙대로 사용자 메시지는 따로 만들어야 한다.

실험 · 도구

기본값이 어떻게 만들어지는지 확인해 보자.

import Foundation

enum E1: Error { case a, b, c }

for e in [E1.a, E1.b, E1.c] {
    let ns = e as NSError
    print("\(e) → domain=\(ns.domain) code=\(ns.code)")
}
// a → domain=main.E1 code=0
// b → domain=main.E1 code=1
// c → domain=main.E1 code=2

// 케이스 순서를 바꾸면 code 가 바뀐다 — 저장·전송된 코드가 있으면 위험하다
enum E2: Error { case c, a, b }
print((E2.a as NSError).code)     // 1 — E1 에서는 0 이었다

역방향 검증도 확인된다.

let real = PaymentError.declined as NSError
let fake = NSError(domain: "com.example.payment", code: 9999)

real as? PaymentError            // ✅ 매핑된다
fake as? PaymentError            // nil — code 가 맞지 않는다
//   domain/code 검증을 거치므로 아무 NSError 나 변환되지 않는다

# 에러 코드를 저장·전송하는 곳 — CustomNSError 로 고정할 후보
grep -rn "\.code\b" --include=*.swift . | grep -iE "save|store|send|log|analytics" | head

# LocalizedError 미준수인데 localizedDescription 을 사용자에게 보여주는 곳
grep -rn "localizedDescription" --include=*.swift . | grep -iE "alert|label|message" | head

프로젝트 적용

1. 저장·전송되는 에러 코드는 CustomNSError로 고정한다. 기본값은 케이스 순서에 묶여 있어 리팩터링에 취약하다.
2. 사용자에게 보일 문구는 LocalizedError로 명시한다. 안 하면 영문 기본 문구가 노출된다.
3. 두 프로토콜을 함께 쓴다. 관심사가 다르므로 충돌하지 않는다.
4. errorDomain이 static var임을 기억한다. 인스턴스 프로퍼티로 착각하면 컴파일이 안 된다.
5. ObjC 라이브러리 에러를 Swift 타입으로 매핑할 때 domain/code를 확인한다. 자동 변환은 검증을 거치므로 우리 타입으로는 안 바뀐다.

꼬리 질문

enum NetworkError: Error {
    case offline
    case timeout
    case other(underlying: NSError)     // ✅ 원본을 보관한다

    init(_ ns: NSError) {
        switch (ns.domain, ns.code) {
        case (NSURLErrorDomain, NSURLErrorNotConnectedToInternet): self = .offline
        case (NSURLErrorDomain, NSURLErrorTimedOut):               self = .timeout
        default:                                                    self = .other(underlying: ns)
        }
    }
}

// 로깅할 때 userInfo 를 함께 남긴다 (PII 주의 — P1 23장)
if case .other(let ns) = error {
    logger.error("네트워크 실패: \(ns.domain, privacy: .public)/\(ns.code) \(ns.localizedDescription, privacy: .public)")
    if let url = ns.userInfo[NSURLErrorFailingURLStringErrorKey] as? String {
        logger.error("실패 URL: \(URL(string: url)?.observabilitySafe.absoluteString ?? "-", privacy: .public)")
    }
}

struct ErrorReport: Encodable {
    let domain: String
    let code: Int
    let screen: String
    let appVersion: String
    let osVersion: String
    let retryable: Bool
    // localizedDescription 은 넣지 않는다 — 로케일마다 달라 그룹핑이 쪼개진다
}

@objc final class Service: NSObject {
    @objc func load() throws -> Data { … }
}
// ObjC 에서는 이렇게 보인다:
//   - (nullable NSData *)loadAndReturnError:(NSError **)error;
//   Swift 에러가 자동으로 NSError 로 브리징돼 out 파라미터에 채워진다

Q5. KVO는 어떻게 구현되며 왜 @objc만으로는 부족한가?

CS 원리

KVO는 런타임 가로채기(interception)의 전형이다. 원본 코드를 고치지 않고 동작 사이에 끼어드는 기법이고, P1 22장 Q5의 자동 계측(메서드 스위즐링)과 같은 계열이다.

가로채기가 성립하려면 호출이 반드시 지나는 지점이 있어야 한다. Objective-C에서 그 지점이 objc_msgSend다 — 모든 메서드 호출이 런타임 조회를 거치므로, 조회 결과를 바꾸면 다른 구현이 실행된다.

KVO의 구현은 이렇다.

1. 관찰 시작 시 원본 클래스의 동적 서브클래스를 만든다.
2. 서브클래스에서 setter를 오버라이드해 변경 통지를 넣는다.
3. 그 인스턴스의 isa 포인터를 서브클래스로 바꾼다.
4. 서브클래스가 -class도 오버라이드해 원래 클래스 이름을 반환한다.

4번이 흥미롭다 — 가로채기 사실을 숨기는 것이 설계에 포함돼 있다. 그래서 type(of:)는 원래 클래스를 보여주고, object_getClass만 isa를 직접 읽어 진짜를 드러낸다.

Swift에서 문제가 되는 지점은 Swift가 기본적으로 정적 디스패치를 쓴다는 것이다(33장 Q3). @objc는 런타임 테이블에 노출할 뿐이고, 호출이 objc_msgSend를 거치게 만드는 것은 dynamic이다. 노출됐지만 거치지 않으면 가로채기가 무력화된다.

그래서 "isa는 바뀌었는데 통지는 안 온다"는 상태가 만들어진다 — 가로채기 장치는 설치됐지만 아무도 그 문을 지나가지 않는 것이다.

iOS에서는

재현이 간단하고, 결과가 인상적이다.

import Foundation

final class Cat: NSObject {
    @objc var nameA = ""            // dynamic 없음
    @objc dynamic var nameB = ""    // dynamic 있음
}

let cat = Cat()
print(type(of: cat))                // Cat
print(object_getClass(cat)!)        // Cat

let obs = cat.observe(\.nameB) { _, _ in print("nameB 변경 감지") }

print(type(of: cat))                // Cat            ← 거짓말
print(object_getClass(cat)!)        // NSKVONotifying_Cat  ← 진짜

cat.nameB = "나비"                   // "nameB 변경 감지" 출력
cat.nameA = "야옹"                   // 아무 출력 없음 — dynamic 이 없어 우회했다

Swift 네이티브 KVO API를 쓰면 그나마 안전하다 — key path 기반이라 오타는 컴파일 타임에 잡힌다(32장 Q3).

// ✅ 타입 안전한 방식
let token = object.observe(\.property, options: [.new, .old]) { obj, change in
    print(change.oldValue, change.newValue)
}
//   token 이 살아 있는 동안만 관찰된다 — 해제를 잊어도 크래시하지 않는다

// ⚠️ 문자열 기반 구식 API — 오타가 런타임에야 드러나고 해제도 수동이다
object.addObserver(self, forKeyPath: "propety", options: [], context: nil)   // 오타!

값 타입에는 쓸 수 없다는 근본 제약도 있다. KVO는 NSObject 런타임에 의존하므로 struct·enum에는 적용되지 않는다. 이것이 Observation이 필요한 이유이기도 하다(Q6).

실험 · 도구

type(of:)가 어떻게 속이는지 직접 확인해 보자.

import Foundation

final class Probe: NSObject { @objc dynamic var value = 0 }

let p = Probe()
func report(_ label: String) {
    print("\(label): type(of:)=\(type(of: p))  object_getClass=\(object_getClass(p)!)")
}

report("관찰 전")
let t = p.observe(\.value) { _, _ in }
report("관찰 중")        // type(of:) 는 그대로, object_getClass 만 바뀐다
t.invalidate()
report("해제 후")

// 동적 서브클래스의 메서드 목록을 들여다본다
if let cls = object_getClass(p) {
    var count: UInt32 = 0
    if let methods = class_copyMethodList(cls, &count) {
        for i in 0..<Int(count) {
            print(NSStringFromSelector(method_getName(methods[i])))
        }
        free(methods)
    }
}
//   setValue: · class · dealloc · _isKVOA 등이 보인다

코드베이스에서 위험한 선언을 찾는다.

# @objc 만 있고 dynamic 이 없는 프로퍼티 — KVO 대상이면 동작하지 않는다
grep -rnE "@objc +var " --include=*.swift . | grep -v dynamic

# 문자열 기반 KVO — key path 로 옮길 후보
grep -rn "addObserver(.*forKeyPath:" --include=*.swift .

# 관찰 토큰을 보관하지 않는 곳 — 즉시 해제되어 동작하지 않는다
grep -rn "\.observe(" --include=*.swift . | grep -v "let \|var \|= "

프로젝트 적용

1. KVO 대상 프로퍼티에는 @objc dynamic을 함께 붙인다. @objc만으로는 조용히 동작하지 않는다.
2. key path 기반 API를 쓴다. 문자열 경로는 오타가 런타임에야 드러난다.
3. 관찰 토큰을 반드시 보관한다. 반환값을 버리면 즉시 해제되어 콜백이 오지 않는다.
4. 새 코드에는 Observation을 쓴다. KVO는 레거시·시스템 프레임워크 관찰에만 남긴다(Q6).
5. type(of:)로 진단하지 않는다. 런타임 상태를 확인하려면 object_getClass를 쓴다.

꼬리 질문

@objc dynamic var value = 0     // 둘 다 필요하다

// ❌ 반환값을 버린다 — 즉시 해제되어 콜백이 안 온다
_ = object.observe(\.value) { _, _ in }

// ✅ 보관한다
private var token: NSKeyValueObservation?
token = object.observe(\.value) { _, _ in }

willChangeValue(for: \.value)
_value = newValue
didChangeValue(for: \.value)

// key path 기반이라 타입 안전하다
private var progressToken: NSKeyValueObservation?

progressToken = webView.observe(\.estimatedProgress, options: [.new]) { [weak self] _, change in
    guard let v = change.newValue else { return }
    Task { @MainActor in self?.progressBar.progress = Float(v) }
}
//   콜백이 어느 스레드에서 오는지 보장이 약하므로 UI 갱신은 메인으로 옮긴다

Q6. Observation은 KVO를 어떻게 대체하는가?

CS 원리

관찰 시스템의 근본 문제는 "누가 무엇에 의존하는가"를 어떻게 아는가다. 방식이 둘 있다.

접근 추적의 핵심 통찰은 "의존은 이미 코드에 있다"는 것이다. body에서 model.name을 읽었다면 그것이 곧 의존이고, 따로 선언할 필요가 없다.

32장 Q3 꼬리질문에서 본 대로 이 설계는 빠뜨릴 수 없다 — 새 프로퍼티를 읽기 시작하면 자동으로 관찰 대상이 된다. 31장 Q2의 CodingKeys 갱신 누락과 정반대의 설계다.

구현은 매크로가 담당한다. @Observable이 각 프로퍼티의 get·set에 추적 훅을 삽입하고, withObservationTracking이 읽힌 프로퍼티 집합을 수집한다. Objective-C 런타임에 의존하지 않으므로 순수 Swift 타입에서 동작한다.

같은 값 재대입에서 차이가 나는 이유는 통지 시점이다. objectWillChange는 대입 자체에 반응하지만, Observation은 실제 변화를 본다.

iOS에서는

선언이 단순해지는 것이 첫인상이다.

import Observation

// 이전
final class OldModel: ObservableObject {
    @Published var name = ""
    @Published var count = 0
    var internalCache: [String] = []      // @Published 를 빠뜨리면 갱신이 안 온다
}

// 지금
@Observable final class NewModel {
    var name = ""
    var count = 0
    var internalCache: [String] = []      // 별도 표시가 필요 없다
    @ObservationIgnored var scratch = 0   // 추적에서 빼고 싶을 때만 명시
}

세분성 차이가 성능으로 나타난다.

struct CountView: View {
    let model: NewModel
    var body: some View {
        Text("\(model.count)")            // count 만 읽는다
    }
}
//   model.name 이 바뀌어도 이 뷰는 재평가되지 않는다.
//   ObservableObject 였다면 name 변경에도 재평가됐다.

같은 값 재대입이 통지를 만들지 않는 것도 실무에서 유용하다 — 서버에서 받은 데이터를 통째로 대입하는 패턴에서 불필요한 재렌더가 사라진다.

// 목록을 새로고침할 때마다 전부 대입해도
model.items = fetched
//   실제로 바뀐 것이 없으면 통지가 없다 (@Published 였다면 무조건 발동)

SwiftUI 밖에서도 쓸 수 있다.

withObservationTracking {
    _ = model.count                       // 이 읽기가 의존으로 등록된다
} onChange: {
    print("count 가 곧 바뀐다")
    // 주의: onChange 는 한 번만 불린다 — 계속 관찰하려면 다시 등록해야 한다
}

주의할 점이 있다. onChange는 1회성이고, 변경 직전에 불린다. 지속 관찰이 필요하면 재등록하거나 AsyncSequence 형태의 상위 API를 쓴다.

실험 · 도구

통지 횟수 차이를 직접 재현해 보자.

import Observation
import Combine

final class Pub: ObservableObject { @Published var v = 0 }
@Observable final class Obs { var v = 0 }

// @Published — 같은 값을 넣어도 발동한다
let p = Pub()
var pubCount = 0
let c = p.objectWillChange.sink { _ in pubCount += 1 }
p.v = 0; p.v = 0
print("@Published 통지: \(pubCount)회")      // 2회

// @Observable — 실제 변화가 없으면 발동하지 않는다
let o = Obs()
var obsCount = 0
func track() {
    withObservationTracking { _ = o.v } onChange: { obsCount += 1; track() }
}
track()
o.v = 0; o.v = 0
print("@Observable 통지: \(obsCount)회")     // 0회

SwiftUI에서 재평가 횟수를 확인하는 방법이다.

struct DebugView: View {
    let model: NewModel
    var body: some View {
        let _ = Self._printChanges()      // 무엇 때문에 재평가됐는지 콘솔에 찍힌다
        Text("\(model.count)")
    }
}

# 아직 ObservableObject 를 쓰는 곳 — 이전 후보
grep -rn "ObservableObject\|@Published" --include=*.swift . | wc -l

# @ObservationIgnored 가 필요한 곳 — 추적하면 안 되는 캐시·스크래치
grep -rn -A2 "@Observable" --include=*.swift . | grep -iE "cache|scratch|temp" | head

프로젝트 적용

1. 새 모델은 @Observable로 만든다. 선언이 단순하고 빠뜨릴 수 없다.
2. 기존 ObservableObject는 점진적으로 옮긴다. 화면 단위로 바꾸면 회귀 범위가 좁다.
3. 재평가 범위가 줄어드는 것을 측정한다. Self._printChanges()로 확인하면 개선이 눈에 보인다.
4. 추적하면 안 되는 프로퍼티에 @ObservationIgnored를 붙인다. 내부 캐시가 대표적이다.
5. 시스템 객체 관찰에는 여전히 KVO가 필요하다. 둘이 공존하는 것이 정상이다(Q5 꼬리질문).

꼬리 질문

// 이전
@ObservedObject var model: OldModel
TextField("이름", text: $model.name)

// 지금 — @Bindable 을 쓴다
@Bindable var model: NewModel
TextField("이름", text: $model.name)

// 계산된 값을 뷰 밖에서 만들어 넘기면 의존이 추적되지 않는다
struct Parent: View {
    let model: NewModel
    var body: some View {
        Child(text: computeText())      // ⚠️ 여기서 읽어야 추적된다
    }
    func computeText() -> String { model.name.uppercased() }   // body 안에서 불리므로 OK
}

// ❌ 여러 스레드에서 접근하면 데이터 경쟁이다
@Observable final class Model { var count = 0 }
DispatchQueue.concurrentPerform(iterations: 1000) { _ in model.count += 1 }

// ✅ 메인 액터에 가둔다 — UI 모델은 대개 이것이 맞다
@MainActor @Observable final class UIModel { var count = 0 }

// ✅ 또는 액터로 감싸고 UI 상태만 메인으로 옮긴다
actor DataStore { … }

// ❌ 한 뷰가 전부 읽는다
struct Big: View {
    let m: Model
    var body: some View {
        VStack { Text(m.title); Text("\(m.tick)") }    // tick 이 바뀌면 title 도 재평가
    }
}

// ✅ 자주 바뀌는 부분을 분리
struct Big2: View {
    let m: Model
    var body: some View { VStack { Text(m.title); TickView(m: m) } }
}
struct TickView: View { let m: Model; var body: some View { Text("\(m.tick)") } }

출처 · 참고자료