16 · ObjC 브리징과 NSObject

Swift가 macOS/iOS에서 지금도 Objective-C 런타임 위에 서 있다는 사실은 평소엔 잘 보이지 않는다. 이 챕터는 그 접점이 실제로 코드에 어떻게 드러나는지 — String이 NSString으로 캐스팅되는 순간 진짜로 무슨 클래스가 나오는지, KVO가 관찰을 시작하자마자 몰래 서브클래스를 심는지 — 를 object_getClass로 직접 찍어서 확인한다. "브리징은 공짜다"와 "브리징은 원소마다 다시 만든다"는 말이 각각 어느 계층에서만 맞는지, 그리고 2026년에도 NSObject를 상속해야 하는 몇 안 되는 자리가 어디인지가 핵심이다.

Q1. Toll-free bridging이란 무엇이고 비용은 정확히 어디서 발생하는가?

원리

CoreFoundation은 Objective-C 런타임 없이도 모든 Darwin 플랫폼에서 쓸 수 있는 순수 C API로 설계됐고, Foundation은 애초에 그 CF 타입들 위에 얇게 씌운 Objective-C 래퍼로 시작했다(Apple 개념 문서). 이 이중 구조 자체가 toll-free bridging의 근거다 — CFStringRef와 NSString은 설계 단계부터 같은 메모리 레이아웃을 공유하는 하나의 타입으로 만들어졌다. 반면 Swift String/Array/Dictionary/Set은 CF/NS 클러스터와 무관하게 설계된 진짜 Swift 값 타입이고, ObjC와의 상호운용은 나중에 _ObjectiveCBridgeable 프로토콜로 얹은 것이다(Q2에서 다룬다).

내부 동작

CFStringRef와 NSString 사이의 캐스트는 새 객체를 전혀 만들지 않는다 — 실행 시점에 변환 코드가 도는 게 아니라, 컴파일러가 같은 비트 패턴을 다른 타입으로 다시 본다. 반면 [Int]를 NSArray로 캐스팅했을 때 실제로 무슨 일이 일어나는지 실측해보면 흥미롭다. 10만 개짜리 [Int]를 as NSArray로 캐스팅하는 데는 0.0055ms밖에 걸리지 않는다 — 10만 개의 NSNumber를 그 자리에서 박싱하기엔 터무니없이 짧다. type(of:)로 실제 타입을 찍어보면 결과는 평범한 NSArray 서브클래스가 아니라 __SwiftDeferredNSArray라는 지연 래퍼다. 진짜 박싱 비용은 캐스트 시점이 아니라, ObjC 쪽이 그 배열의 원소를 실제로 하나씩 꺼내 읽는 순간에 나눠서 발생한다 — 같은 10만 개 배열을 처음부터 끝까지 순회하며 각 원소를 NSNumber로 꺼내 보면 그제서야 16ms가 걸린다(측정치, Swift 6.2.1 / macOS 26 / Apple Silicon). 즉 비용이 "브리징하는 시점"이 아니라 "실제로 소비하는 시점"으로 미뤄진다 — Q2에서 볼 String 브리징의 지연 전략과 같은 사상이다.

실험 · 도구

아래 코드를 파일로 저장해 swift 파일명.swift로 돌리면 캐스트가 지연 래퍼를 만든다는 것과, 실제 소비 시점에만 비용이 붙는다는 것을 직접 확인할 수 있다.

import Foundation

let ints: [Int] = Array(0..<100_000)
let t0 = DispatchTime.now()
let nsArr = ints as NSArray
let t1 = DispatchTime.now()

print(type(of: nsArr))   // __SwiftDeferredNSArray — 아직 박싱하지 않은 지연 래퍼

var acc = 0
for i in 0..<nsArr.count {
    let obj = nsArr[i]                    // 여기서 비로소 Int -> NSNumber 박싱이 일어난다
    if let n = obj as? NSNumber { acc += n.intValue > 0 ? 1 : 0 }
}
let t2 = DispatchTime.now()

print("캐스트:", Double(t1.uptimeNanoseconds - t0.uptimeNanoseconds) / 1_000_000, "ms")
print("순회 접근:", Double(t2.uptimeNanoseconds - t1.uptimeNanoseconds) / 1_000_000, "ms")

LLDB에서는 po type(of: someBridgedValue)로 캐스트 직후의 실제 런타임 클래스를 바로 확인할 수 있다.

프로젝트 적용

① ObjC 델리게이트 API에 Swift 배열을 그대로 넘기는 건 걱정할 정도로 비싸지 않다 — 캐스트 자체는 지연 래퍼를 만들 뿐이다.

func exposeToObjC(_ ids: [Int]) -> NSArray {
    ids as NSArray   // __SwiftDeferredNSArray로 감쌀 뿐, 이 시점엔 원소를 박싱하지 않는다
}

② 다만 그 결과를 스크롤·레이아웃처럼 자주 도는 루프 안에서 반복해 접근하면, 지연됐던 박싱 비용이 접근할 때마다 조금씩 청구된다. 뜨거운 경로에선 한 번만 순회해서 필요한 형태로 확정해두는 편이 낫다.

// ❌ 매 프레임 콜백마다 NSArray 원소를 다시 언박싱
func tableView(_ tv: UITableView, cellForRowAt ip: IndexPath) -> UITableViewCell {
    let n = legacyNSArray[ip.row] as! NSNumber   // 호출될 때마다 박싱 비용
    // ...
}

// ✅ 화면에 쓰기 전에 한 번만 Swift 네이티브 타입으로 확정
let ids: [Int] = legacyNSArray.compactMap { ($0 as? NSNumber)?.intValue }

꼬리 질문

Q2. _ObjectiveCBridgeable은 무슨 일을 하는가? "String은 그냥 NSString"이 왜 부정확한가?

원리

SE-0069가 지적하듯 표준 라이브러리는 거의 전부 값 타입인데(Swift 2.2 기준 struct 109개 vs class 6개) Foundation 클러스터만 참조 타입이던 부조화를 없애려고 String/Array/Dictionary/Set은 진짜 값 타입으로 재설계됐다. 그러면서도 방대한 ObjC API 표면과 상호운용해야 하니, 컴파일러와 런타임이 _ObjectiveCBridgeable을 통해 "이 값 타입을 이렇게 ObjC 객체로 내보내고, 이렇게 되돌린다"는 규약을 표준 라이브러리 소스에 심어뒀다. 이 프로토콜은 공개 문서화된 API가 아니라 컴파일러가 as 캐스팅 문법 뒤에서 호출하는 내부 구현이다.

내부 동작

말로 설명하기보다 직접 object_getClass를 찍어보면 뉘앙스가 바로 드러난다(Swift 6.2.1 / macOS 26 실측). 짧은 리터럴 "hi"는 NSTaggedPointerString으로 나온다 — 힙에 아무것도 할당하지 않고 문자 데이터를 포인터 비트 안에 직접 욱여넣은 "즉시값"이다. 75자짜리 컴파일타임 상수 리터럴은 NSIndirectTaggedPointerString으로 나온다 — 이 역시 malloc을 부르지 않고, 컴파일된 바이너리 안의 상수 문자열 테이블을 가리키기만 한다. NSString(string:)으로 만든 뒤 다시 as String으로 되돌린 값도 같은 NSIndirectTaggedPointerString이었는데, 이건 애초에 그 리터럴 자체가 컴파일타임 상수였기 때문이다. 반면 반복문으로 런타임에 조립한 80바이트짜리 문자열(컴파일타임 상수가 아님)은 Swift.__StringStorage로 나왔다 — Swift 고유의 네이티브 문자열 버퍼 클래스가 복사 없이 그 자체로 NSString 행세를 한 것이다. 5바이트짜리 짧은 런타임 문자열은 출처와 무관하게 다시 NSTaggedPointerString이었다. 다섯 케이스 중 어느 것도 "새 NSString 버퍼를 할당해 데이터를 복사"하지 않았다 — 전부 즉시값이거나 기존 Swift 버퍼의 재사용이었다.

실험 · 도구

아래 코드를 그대로 저장해 swift 파일명.swift로 실행하면 위 표의 다섯 줄을 직접 재현할 수 있다.

import Foundation

func className(_ s: String) -> String {
    NSStringFromClass(object_getClass(s as AnyObject)!)
}

let short: String = "hi"
let long: String = "this is a much longer string literal that exceeds the small string buffer"
let fromNS: String = NSString(string: "bridged-from-nsstring") as String

var built = ""
for i in 0..<30 { built += "x\(i)" }          // 컴파일타임 상수가 아니게 만든다
let shortBuilt = String(repeating: "a", count: 5)

print("짧은 리터럴:", className(short))
print("긴 리터럴:", className(long))
print("NSString에서 브리지:", className(fromNS))
print("런타임 조립(80B):", className(built))
print("런타임 조립(짧음):", className(shortBuilt))

프로젝트 적용

① ObjC 프레임워크로 문자열을 자주 넘기는 코드에서 "브리징 = 항상 복사"라고 가정하고 미리 캐싱 같은 걸 만들 필요는 없다 — 실측상 대부분의 경로가 이미 무할당이거나 버퍼를 재사용한다.

@objc protocol LegacyDelegate {
    func didReceive(text: String)
}
// 매 호출마다 새 NSString 버퍼를 만든다고 걱정해 별도 캐싱 계층을 두는 건
// 대부분의 경우 불필요한 조기 최적화다

② 반대로 "String은 사실 NSString이니 NSString API로 캐스팅 없이 막 써도 된다"는 식으로 타입을 흐리게 쓰면, UTF-16 기반인 NSString의 인덱스 체계가 Swift의 grapheme 기반 String.Index와 어긋나는 버그를 만든다(자세한 내용은 12장). 브리징이 저렴하다는 것과 두 타입의 의미론이 같다는 것은 별개다.

let emoji = "👨‍👩‍👧‍👦"
print(emoji.count)                  // 1 — Swift grapheme 기준
print((emoji as NSString).length)   // 훨씬 큰 값 — UTF-16 code unit 기준

꼬리 질문

Q3. 오늘날 NSObject를 상속해야만 하는 경우는 언제인가?

원리

NSObject는 ObjC 런타임과의 접점 — isKindOfClass:, respondsToSelector:, perform(_:with:), KVC/KVO, 동적 메시지 디스패치 — 을 제공하는 루트 클래스다. Swift 순수 class는 이 런타임 인프라를 자동으로 상속하지 않는다. 다만 @objc/dynamic 멤버를 개별적으로 붙이면 그 멤버는 ObjC 런타임에 노출될 수 있는데, 이게 "NSObject가 제공하는 API 전체를 쓸 수 있다"는 뜻은 아니다 — 아래 실측이 그 간극을 정확히 보여준다.

내부 동작

NSObject를 상속하지 않은 순수 Swift 클래스에 @objc dynamic var value: Int = 0을 붙이면 컴파일이 그대로 통과한다. 그 인스턴스를 is NSObject로 검사하면 false가 나오지만, is NSObjectProtocol로 검사하면 true가 나온다 — ObjC 런타임이 이 클래스를 최소한의 수준으로는 인식한다는 뜻이다. 그런데도 그 인스턴스에 .observe(\.value, options: [.new]) { ... }를 호출하면 "value of type 'PlainA' has no member 'observe'"라는 진짜 컴파일 에러가 난다(Swift 6.2.1 / macOS 26 실측). 이유는 observe(_:options:changeHandler:)가 NSObjectProtocol이 아니라 구체적으로 NSObject 클래스에 붙은 확장 메서드이기 때문이다. 즉 "이 클래스의 멤버 하나하나를 ObjC 런타임에 노출한다"는 것과 "이 클래스가 NSObject가 제공하는 KVO observer API 전체를 쓸 수 있다"는 건 완전히 다른 문제다 — 실무에서 NSObject를 상속해야 하는 이유는 정확히 이 간극 때문이다.

실험 · 도구

아래 두 파일을 각각 swiftc -typecheck와 swift로 돌리면 위에서 말한 간극을 그대로 재현할 수 있다.

import Foundation

class PlainA {
    @objc dynamic var value: Int = 0   // 컴파일 성공
}

let a = PlainA()
print(a is NSObject)          // false
print(a is NSObjectProtocol)  // true — 최소한의 런타임 인식은 됨

// let token = a.observe(\.value) { _, _ in }
// ❌ error: value of type 'PlainA' has no member 'observe'

같은 프로퍼티를 NSObject를 상속한 클래스에 옮기면 observe가 바로 나타난다 — Q4에서 이 API를 실제로 써서 isa-swizzling까지 확인한다.

프로젝트 적용

① 순수하게 "값이 바뀌면 알림받고 싶다"는 요구뿐이라면 NSObject + KVO로 무겁게 갈 필요가 없다. Swift 네이티브 @Observable(27장)이 ObjC 런타임·isa-swizzling 없이 같은 문제를 푼다.

// ❌ 관찰만 하면 되는데 NSObject 상속과 @objc dynamic까지 끌고 온다
final class LegacySettings: NSObject {
    @objc dynamic var isDarkMode: Bool = false
}

// ✅ Swift 네이티브 관찰 — ObjC 런타임도, isa-swizzling도 필요 없다
@Observable
final class Settings {
    var isDarkMode: Bool = false
}

② 반대로 UITableViewDataSource처럼 이미 NSObjectProtocol을 요구하는 시스템 API를 구현할 땐 NSObject를 피할 방법이 없다 — 그 자리에서 억지로 순수 Swift 타입을 쓰려 하지 않는다.

final class ProductListDataSource: NSObject, UITableViewDataSource {
    func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
        products.count
    }
    func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
        // ...
        UITableViewCell()
    }
    private let products: [String] = []
}

꼬리 질문

Q4. @objc와 dynamic은 각각 무엇을 하며, KVO에는 왜 둘 다 필요한가?

vtable/witness table/objc_msgSend 세 디스패치 방식 자체의 기초는 이미 7장에서 다뤘다. 여기서는 그 지식을 KVO의 isa-swizzling에 실제로 적용해 무엇이 가로채지고 무엇이 안 가로채지는지 직접 확인한다.

원리

Swift 컴파일러는 호출부의 정적 타입을 알고 있으면 그 정보를 최대한 활용해 빠른 디스패치(직접 호출 또는 vtable)를 쓰려 한다. @objc는 "이 멤버를 ObjC 런타임이 찾을 수 있게 만든다"는 선언일 뿐, "이 멤버의 모든 호출을 ObjC 런타임을 거치게 강제한다"는 뜻이 아니다. dynamic이 그 강제를 담당한다 — 이 멤버에 대해서는 Swift가 정적 최적화를 포기하고 항상 objc_msgSend를 부르도록 만든다. 메서드 스위즐링(다른 구현으로 selector를 바꿔치기하는 기법)이나 KVO의 isa-swizzling처럼 "런타임에 호출을 가로챈다"는 기법은 전부 이 동적 디스패치가 실제로 매번 일어난다는 전제 위에 서 있다.

내부 동작

@objc dynamic var name: String을 가진 NSObject 서브클래스에서 관찰을 시작하기 전후로 object_getClass를 찍어보면 다음과 같다(Swift 6.2.1 / macOS 26 실측).

관찰 전 object_getClass: main.Dog
관찰 전 type(of:):        main.Dog

관찰 후 object_getClass: ..NSKVONotifying_main.Dog
관찰 후 type(of:):        main.Dog   ← 그대로!

관찰을 시작하자마자 object_getClass가 가리키는 실제 클래스가 NSKVONotifying_Dog로 바뀐다 — 런타임이 Dog의 동적 서브클래스를 새로 만들어(objc_registerClassPair 계열 API로) name의 setter를 오버라이드한 뒤, 그 인스턴스의 isa 포인터를 이 새 클래스로 바꿔치기(swizzling)한 것이다. 흥미로운 건 type(of:)는 여전히 원래 클래스 Dog를 보여준다는 점이다 — KVO가 심는 서브클래스는 -class(Swift에서 type(of:)가 최종적으로 의존하는 경로)를 오버라이드해서 원래 클래스 이름을 거짓으로 돌려주도록 만들어져 있다. 그래서 isa 포인터를 직접 읽는 object_getClass만 진짜 클래스를 드러내고, "정상적인" 클래스 조회 경로는 이 스위즐링을 숨긴다.

이 가로채기가 dynamic 없이도 성립하는지 직접 확인해볼 수 있다. @objc만 붙이고 dynamic은 뺀 프로퍼티로 같은 실험을 하면, Swift 컴파일러가 실제로 경고를 낸다.

final class Cat: NSObject {
    @objc var name: String = "Nabi"   // dynamic 없음
}
let cat = Cat()
let token = cat.observe(\.name) { _, change in print("콜백:", change.newValue ?? "?") }
cat.name = "Yaong"

// 실제 컴파일러 경고:
// warning: passing reference to non-'@objc dynamic' property 'name' to KVO method
// 'observe(_:options:changeHandler:)' may lead to unexpected behavior or runtime trap

실제로 돌려보면 object_getClass는 이번에도 NSKVONotifying_Cat으로 바뀐다 — @objc만으로도 런타임이 서브클래스를 만드는 것 자체는 시도한다. 하지만 cat.name = "Yaong"이 콜백을 발동시키지 않는다. name이 dynamic이 아니므로, cat.name = ...이라는 대입은 Swift 컴파일러가 정적 타입 Cat을 알고 있는 그 자리에서 곧장 저장소에 쓰는 코드로 컴파일돼버려서, 애초에 objc_msgSend를 거치지 않고 스위즐링된 서브클래스의 오버라이드된 setter를 우회한다. isa는 바뀌었는데 그 바뀐 isa를 실제로 거쳐 가는 호출이 하나도 없는 셈이다.

실험 · 도구

아래 코드를 그대로 저장해 swift 파일명.swift로 실행하면 위 실측 출력을 그대로 재현할 수 있다.

import Foundation

final class Dog: NSObject {
    @objc dynamic var name: String = "Rex"
}

let dog = Dog()
print("관찰 전:", NSStringFromClass(object_getClass(dog)!))
let obs = dog.observe(\.name) { _, _ in }
print("관찰 후:", NSStringFromClass(object_getClass(dog)!))
obs.invalidate()

LLDB에서는 관찰 중인 인스턴스에 po object_getClass(dog)를 직접 쳐서 같은 걸 확인할 수 있다.

프로젝트 적용

① Interface Builder나 KVO로 관찰될 프로퍼티는 반드시 @objc dynamic 둘 다 붙인다 — 하나라도 빠지면 컴파일은 되지만 콜백이 조용히 발동하지 않는, 발견하기 아주 까다로운 버그가 된다.

final class PlayerState: NSObject {
    @objc dynamic var score: Int = 0   // @objc만 있고 dynamic이 빠지면 관찰이 조용히 실패한다
}

② 크래시 로그나 디버거에서 NSKVONotifying_YourClass라는 낯선 클래스 이름을 보게 되면 당황하지 말고 "누군가 이 인스턴스를 KVO로 관찰 중"이라는 신호로 읽는다. 버그가 아니라 정상적인 isa-swizzling의 흔적이다.

// 크래시 로그에 NSKVONotifying_PlayerState 가 보이면
// "PlayerState의 어떤 인스턴스를 누가 관찰하고 있다"는 뜻이다.
// observationInfo를 찍어보면 어떤 키패스를 관찰 중인지 힌트를 얻을 수 있다.
print(dog.observationInfo as Any)

꼬리 질문

Q5. NSSecureCoding은 무엇으로부터 안전한가? Codable로 대체할 수 없는 것은?

원리

고전적인 NSCoding 디코딩은 아카이브 안에 적힌 클래스 이름을 NSClassFromString 계열로 찾아 그 클래스의 init(coder:)를 호출하는 방식이었다 — 아카이브 바이트를 공격자가 통제할 수 있는 상황(네트워크로 받은 데이터, 캐시 파일, 붙여넣기 등)이라면, 이건 Java의 ObjectInputStream이나 Python의 pickle과 같은 계열의 고전적인 "역직렬화 취약점" 표면이다. NSSecureCoding은 여기에 딱 하나를 더한다 — 디코딩하는 쪽이 "이 키에서는 정확히 이 클래스(들)만 나와야 한다"를 미리 선언하게 만들고, 실제 아카이브의 클래스가 그 화이트리스트에 없으면 인스턴스를 만들지 않는다.

내부 동작

직접 실험한 결과가 이 방어를 그대로 보여준다. NSAttributedString은 NSSecureCoding과 NSCoding은 채택하지만 Decodable은 채택하지 않는다(실측: NSAttributedString.self is Decodable.Type은 false). requiringSecureCoding: true로 아카이빙하면 378바이트짜리 데이터가 나오고, decodeObject(of: NSAttributedString.self, forKey:)에 해당하는 unarchivedObject(ofClass:from:)로 정확한 클래스를 지정해 복원하면 "hello"가 그대로 돌아온다. 그런데 같은 데이터를 일부러 잘못된 클래스(NSString.self)로 복원을 시도하면, 크래시도 오류도 없이 nil이 돌아온다 — 이게 바로 화이트리스트 검사가 실제로 작동하는 순간이다. 아카이브에 무슨 클래스 이름이 적혀 있든, 호출부가 기대한 클래스와 다르면 그 자리에서 조용히 실패로 처리된다.

실험 · 도구

아래 코드가 위 표와 다이어그램의 실측 결과를 그대로 만든다.

import Foundation

print(NSAttributedString.self is Decodable.Type)   // false — Codable 미채택

let attr = NSAttributedString(string: "hello")
let data = try! NSKeyedArchiver.archivedData(withRootObject: attr, requiringSecureCoding: true)
print(data.count)   // 378

// 올바른 클래스로 복원 — 성공
let back = try? NSKeyedUnarchiver.unarchivedObject(ofClass: NSAttributedString.self, from: data)
print(back?.string ?? "nil")   // "hello"

// 일부러 다른 클래스를 기대하며 복원 — 화이트리스트 불일치로 nil
let wrong = try? NSKeyedUnarchiver.unarchivedObject(ofClass: NSString.self, from: data)
print(wrong as Any)   // nil

프로젝트 적용

① UIImage처럼 Codable을 채택하지 않고 NSSecureCoding만 지원하는 UIKit 타입을 Codable 구조체 안에 담아야 한다면, NSKeyedArchiver로 만든 Data를 그 구조체의 프로퍼티로 감싸는 계층적 합성이 실무 해법이다.

struct ProfileImageWrapper: Codable {
    let imageData: Data

    init(image: UIImage) {
        // requiringSecureCoding: true로 화이트리스트 검증 경로를 강제한다
        imageData = try! NSKeyedArchiver.archivedData(withRootObject: image, requiringSecureCoding: true)
    }

    var image: UIImage? {
        try? NSKeyedUnarchiver.unarchivedObject(ofClass: UIImage.self, from: imageData)
    }
}

② NSSecureCoding을 직접 구현할 때는 반드시 클래스를 구체적으로 지정하는 decodeObject(of:forKey:)를 쓴다 — deprecated된 decodeObject(forKey:)는 화이트리스트 검사 자체가 없어 이 챕터에서 다룬 방어를 무력화한다.

final class Config: NSObject, NSSecureCoding {
    static var supportsSecureCoding: Bool { true }
    let name: String

    init(name: String) { self.name = name }

    required init?(coder: NSCoder) {
        // ✅ 클래스를 명시 — 다른 클래스가 오면 nil
        guard let name = coder.decodeObject(of: NSString.self, forKey: "name") as String? else { return nil }
        self.name = name
    }
    func encode(with coder: NSCoder) {
        coder.encode(name, forKey: "name")
    }
}

꼬리 질문

출처 · 참고자료