14 · Foundation이란 무엇인가

13장까지는 Swift 언어 자체의 규칙 — 값 의미론, 에러 처리, 제네릭, 접근 제어와 ABI — 을 다뤘다. 여기서부터는 그 언어가 40년 가까이 물려받았고, 지금 이 순간에도 발밑에서 다시 쓰이고 있는 프레임워크로 넘어간다. import Foundation 한 줄로 딸려오는 이 라이브러리는 NeXTSTEP 시절 Objective-C로 태어났지만, 2023년부터 시작된 재작성으로 그 내부 구현의 상당 부분이 Swift 네이티브 코드로 교체되는 중이다. 이 챕터는 Foundation이 플랫폼 스택에서 정확히 어디에 있는지, NS 접두사가 왜 어떤 타입엔 남고 어떤 타입엔 없는지, 리눅스용 재구현이 왜 별도 프로젝트로 시작됐다가 다시 통합됐는지, 그리고 2022~2026년의 재작성이 실제로 무엇을 바꿨는지를 다룬다. 다른 어떤 챕터보다도 "그럴듯하게 아는 것"과 "정확히 아는 것"의 격차가 큰 주제라, 성능 수치와 연도는 전부 swift.org·swift-evolution 1차 출처를 확인해 인라인으로 달았다.

Q1. Foundation은 iOS 소프트웨어 계층에서 어디에 있고 무슨 역할을 하는가?

원리

Apple의 Cocoa Fundamentals Guide는 이 계층을 하위 계층 위에 상위 계층이 쌓이는 구조로 설명한다. CoreFoundation은 순수 C API라 Objective-C 런타임이 없는 환경에서도 링크할 수 있고, Foundation은 그 위에서 NSObject라는 런타임 접점(isKindOfClass:, respondsToSelector:, perform(_:with:), KVC/KVO, 메시지 디스패치)을 도입한다. Swift의 순수 class는 이 인프라를 자동으로 상속하지 않는다 — NSObject를 직접 상속해야만 그 계약 안으로 들어간다.

내부 동작

이 계층을 눈으로 확인하는 가장 빠른 방법은, 아주 작은 바이너리를 링크해보는 것이다. import Foundation만 있는 파일을 컴파일해 otool -L을 찍으면 실제 의존 관계가 드러난다.

$ cat stack.swift
import Foundation
print("hello")

$ swiftc stack.swift -o stack && otool -L stack
stack:
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1356.0.0)
	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 4109.1.255, weak)
	/usr/lib/swift/libswiftCore.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/swift/libswiftCoreFoundation.dylib (compatibility version 1.0.0, current version 120.100.0, weak)
	/usr/lib/swift/libswiftDispatch.dylib (compatibility version 1.0.0, current version 56.0.0, weak)
	...

Foundation.framework가 직접 걸려 있고, 그 옆에 libswiftCoreFoundation.dylib이 별도로 보인다 — Swift 쪽에서 CoreFoundation 타입을 다루는 브리지 계층이다. CoreFoundation.framework 자체는 이 목록에 별도 줄로 나타나지 않는데, 이건 CoreFoundation이 사라졌다는 뜻이 아니라 요즘 macOS의 시스템 프레임워크 다수가 디스크 위 개별 파일이 아니라 dyld 공유 캐시 안에 있어서, 이 작은 바이너리 하나의 직접 링크 목록만으로는 전체 전이(transitive) 의존성이 다 드러나지 않기 때문이다. CoreFoundation이 Foundation과 별도 계층이라는 사실 자체는 Apple의 아키텍처 문서 쪽에서 확인해야 한다.

실험 · 도구

위 otool -L은 프로젝트 아무 파일이나 컴파일해서 바로 재현할 수 있다. Xcode로 만든 실제 앱 바이너리에도 같은 명령을 써보면(otool -L YourApp.app/YourApp | grep Foundation) Foundation이 앱 번들 안이 아니라 시스템 프레임워크로 동적 링크된다는 걸 확인할 수 있다 — 이 사실은 15장에서 "FoundationEssentials를 써도 iOS 앱이 가벼워지지 않는다"는 이야기의 근거가 된다.

프로젝트 적용

① Foundation을 습관적으로 import하기 전에, 그 코드가 정말 이 계층까지 필요한지 한 번 따져보는 습관은 실무에서 은근히 유용하다. 표준 라이브러리만으로 되는 일에 Foundation을 얹으면 그만큼 무거운 의존성(그리고 15장에서 다룰 크로스플랫폼 제약)이 딸려온다.

import Foundation   // ❌ 습관적으로 추가 — 이 함수엔 전혀 필요 없다

func isBlank(_ s: String) -> Bool {
    s.trimmingCharacters(in: .whitespacesAndNewlines).isEmpty
}

// ✅ 순수 Swift 표준 라이브러리만으로 충분 — Foundation 의존 자체가 없다
func isBlankPure(_ s: String) -> Bool {
    s.allSatisfy { $0.isWhitespace || $0.isNewline }
}

② 반대로 Foundation의 런타임 접점(NSObject 계층)이 실제로 필요한 순간도 있다. dynamic 키워드는 Objective-C 클래스 멤버에만 붙일 수 있어서, 순수 Swift class에는 컴파일 에러가 난다 — 이 계층 개념이 실제 컴파일러 에러로 드러나는 지점이다.

// ❌ 순수 Swift class는 Foundation/ObjC 런타임 계약에 들어가 있지 않다
final class Counter {
    dynamic var value = 0   // 컴파일 에러: 'dynamic' only works with members of an Objective-C class
}

// ✅ NSObject를 상속해야 그 계약(런타임 인프라) 안으로 들어간다
final class ObservableCounter: NSObject {
    @objc dynamic var value = 0   // Foundation/ObjC 런타임 접점을 통해 KVO 등이 가능해진다
}

꼬리 질문

Q2. `NS` 접두사는 어디서 왔고, SE-0086은 무슨 기준으로 떼고 남겼는가?

원리

SE-0086은 접두사를 뗄지 말지를 가르는 규칙을 이렇게 정의한다(원문 그대로).

내부 동작

"이름만 바뀌었다"는 말을 가장 직접적으로 확인할 수 있는 지점은 런타임 클래스 이름이다. NSStringFromClass는 Swift 쪽 타입 이름이 아니라 Objective-C 런타임이 실제로 아는 이름을 돌려준다.

import Foundation

print(NSStringFromClass(Process.self))       // NSTask
print(NSStringFromClass(FileManager.self))   // NSFileManager

// "값 타입 대응물이 이미 있다" 규칙으로 접두사가 남은 타입들
print(NSStringFromClass(NSCache<NSString, NSObject>.self))  // NSCache
print(NSStringFromClass(NSRegularExpression.self))            // NSRegularExpression

Process라는 Swift 이름 뒤에서 실제로 도는 Objective-C 클래스는 여전히 NSTask다. SE-0086 원문이 못 박은 그대로다 — "제안된 모든 변경은 Swift에만 해당하며, Objective-C는 바뀌지 않는다." 즉 SE-0086은 새 클래스를 만든 게 아니라, Swift 쪽에서 기존 Objective-C 클래스를 가리키는 이름표를 바꿔 단 것이다.

실험 · 도구

위 코드는 swift 파일명.swift로 바로 재현된다. 크래시 리포트나 디버거 콘솔에서 NSTask, NSFileManager 같은 옛 이름이 튀어나와도 당황할 필요 없다 — Swift 코드에서는 Process/FileManager로 부르는 바로 그 타입이다.

프로젝트 적용

① 이런 이름 불일치를 디버깅 편의 함수로 미리 흡수해두면, 크래시 로그와 코드 사이를 오갈 때 헷갈리지 않는다.

func debugDescribe(_ obj: AnyObject) -> String {
    let runtimeName = NSStringFromClass(object_getClass(obj)!)
    return "\(type(of: obj)) (런타임 클래스: \(runtimeName))"
}

print(debugDescribe(Process()))       // Process (런타임 클래스: NSTask)
print(debugDescribe(FileManager()))   // FileManager (런타임 클래스: NSFileManager)

② NSCache, NSRegularExpression처럼 접두사가 남아 있는 타입을 보고 "왜 아직도 레거시를 써야 하지"라고 걱정할 필요는 없다 — SE-0086이 의도적으로 남긴, 지금도 정식 API다.

// 스레드 세이프 + 메모리 압박 시 자동 축출 — Dictionary로는 못 하는 일 (28장 참고)
let cache = NSCache<NSString, NSData>()
cache.countLimit = 100
cache.setObject(Data("thumbnail".utf8) as NSData, forKey: "key-42")

꼬리 질문

Q3. swift-corelibs-foundation은 왜 만들어졌고 어떤 구조적 문제를 낳았는가?

원리

divergence(동작 발산) 문제는 이렇게 요약된다 — API 시그니처가 같아도 내부 구현이 다르면, 한쪽 플랫폼에서만 재현되는 버그가 생기고, 그 버그를 고치려면 두 코드베이스를 각각 수정해야 한다. swift-corelibs-foundation README 자체도 "API 변경이 불가피한 영역이 있다"고 인정한다 — 대표적으로 AutoreleasingUnsafeMutablePointer처럼 Objective-C 런타임의 오토릴리즈 인프라에 기대는 몇몇 "funnel method"는 Linux에 대응물이 없어 시그니처 자체가 갈렸다.

내부 동작

이 구조가 실제로 어떻게 뒤집혔는지는 소스에서 바로 확인할 수 있다. swift-corelibs-foundation의 Foundation 타깃은 이제 Essentials.swift 파일 두 줄로 시작한다.

$ curl -s https://raw.githubusercontent.com/swiftlang/swift-corelibs-foundation/main/Sources/Foundation/Essentials.swift

// Re-export FoundationEssentials and Internationalization
@_exported import FoundationEssentials
@_exported import FoundationInternationalization

즉 오늘날의 Foundation(Linux)은 독자 재구현이 아니라, swift-foundation 두 모듈을 @_exported로 그대로 재노출한 뒤 레거시 NS* 클래스 표면(DateFormatter.swift, FileManager.swift 등)만 얇게 얹은 껍데기다. "이중 구현으로 인한 divergence"라는 근본 문제가 아키텍처 레벨에서 없어진 셈이다.

실험 · 도구

위 curl 명령은 누구나 그대로 실행해 재현할 수 있다. Sources/Foundation/ 디렉터리의 다른 파일들(DateFormatter.swift, FileManager+POSIX.swift 등)을 열어보면, 대부분 레거시 NS* API·포매터·플랫폼별 POSIX 처리만 담고 있고 URL/Data/JSONDecoder 같은 핵심 로직은 더 이상 여기 없다는 것도 직접 확인 가능하다.

프로젝트 적용

① 서버사이드 Swift(Vapor 등)나 크로스플랫폼 패키지를 짤 때, 오늘날은 "Darwin과 Linux가 같은 swift-foundation 코어로 동작한다"는 전제를 갖고 작성해도 대체로 안전하다.

import Foundation

struct Ping: Codable { let ok: Bool }

func decodePing(_ raw: String) throws -> Ping {
    try JSONDecoder().decode(Ping.self, from: Data(raw.utf8))
}

② 다만 divergence가 완전히 사라진 건 아니다. ObjC 런타임 인프라에 기대는 소수 API는 여전히 플랫폼별로 갈릴 수 있어서, 그런 경로엔 조건부 컴파일로 안전망을 두고 CI에서 실제로 Linux 빌드를 돌려 확인해야 한다 — Darwin 통과가 Linux 동작을 보장하지 않는다.

#if canImport(Glibc)
// Linux엔 ObjC 런타임의 오토릴리즈 포인터 인프라가 없다 —
// 그 인프라에 기대는 소수 API는 여전히 플랫폼별로 시그니처가 갈릴 수 있다
import Glibc
#endif

꼬리 질문

Q4. swift-foundation 재작성은 무엇을 어떻게 바꿨는가? — 타임라인과 공개된 성능 수치

원리

swift.org의 "The Future of Foundation"은 재작성 이유를 세 가지로 든다. 첫째 성능 — "Swift 네이티브 구현은 더 이상 C와 Swift 사이 변환 비용을 치르지 않는다." 둘째 기여 접근성 — C 코드를 감싸는 대신 Swift로 짜여 있어 개발자가 직접 읽고 기여하기 쉽다. 셋째, 그리고 가장 근본적인 이유 — "어떤 API든 구현이 여러 개 있으면 플랫폼을 넘나들 때 동작 발산(divergent behavior)과 결국 버그로 이어진다"는 것. 이 세 번째가 Q3의 divergence 문제를 정면으로 겨냥한 진술이다.

내부 동작

2023년 4월 26일 프리뷰 발표가 처음 공개한 네 가지 성능 수치는 다음과 같다 — 이 챕터에서 인용 가능한 수치는 이 넷뿐이다.

그로부터 1년 뒤, Swift 6 발표 블로그는 "JSONDecoder, URL, Calendar, FileManager, ProcessInfo 등 핵심 타입이 Swift로 완전히 재구현됐다"며 "이 타입들은 macOS 15 / iOS 18과 구현을 공유한다"고 명시한다. 즉 2023년 발표는 계획과 신규 API 공개였고, 기존 핵심 타입의 실제 교체는 정확히 한 사이클 뒤인 2024년 가을에 일어났다 — 이 시차를 뭉개고 "2023년에 다 바뀌었다"고 말하면 부정확하다.

실험 · 도구

지금 설치된 Swift/Foundation이 실제로 이 재작성된 구현을 쓰고 있는지는 NSFoundationVersionNumber로 대략 가늠할 수 있고, JSONDecoder의 체감 처리량은 직접 벤치마크해볼 수 있다.

import Foundation

struct Item: Codable { let id: Int; let name: String; let price: Double; let inStock: Bool }

let items = (0..<5000).map { Item(id: $0, name: "product-\($0)", price: Double($0) * 1.5, inStock: $0 % 2 == 0) }
let data = try! JSONEncoder().encode(items)
print("payload bytes:", data.count)                    // 314540

let decoder = JSONDecoder()
let start = Date()
for _ in 0..<200 { _ = try! decoder.decode([Item].self, from: data) }
let elapsed = Date().timeIntervalSince(start)
print(elapsed, elapsed / 200 * 1000)                    // 1.0089...초 / 1회 평균 5.04ms

이 머신에서는 약 307KB(314,540바이트) payload를 200회 디코딩하는 데 총 1.01초, 1회 평균 약 5.0ms가 걸렸다. 다만 이건 "재작성 전 대비 몇 % 개선"을 재현하는 벤치마크가 아니다 — 지금 이 자리에서 실행되는 게 이미 swift-foundation 구현이라, 비교할 "이전" 버전이 이 머신엔 없다. 공식 개선폭(200~500%)을 직접 검증하려면 구형 corelibs-foundation 툴체인이 남아있는 예전 Swift 버전과 나란히 돌려야 하는데, 그 비교는 20장에서 다시 다룬다.

프로젝트 적용

① 2023년 가을에 새로 생긴 API(Predicate, FormatStyle 등)는 그만큼의 최소 배포 타깃을 요구한다는 걸 @available로 명시해야 한다.

import Foundation

@available(iOS 17, macOS 14, *)
func formattedShort(_ date: Date) -> String {
    date.formatted(.dateTime.year().month(.abbreviated).day())
}

② 반대로 기존 핵심 타입(JSONDecoder 등)은 코드를 한 줄도 안 바꿔도, 앱의 배포 최소 버전을 iOS 18/macOS 15 이상으로 올리는 것만으로 재작성의 성능 이득을 그대로 받는다 — 이건 실무에서 배포 타깃 상향을 검토할 실질적인 이유가 된다.

// Package.swift
let package = Package(
    name: "MyApp",
    platforms: [.iOS(.v18), .macOS(.v15)],
    targets: [.target(name: "MyApp")]
)

꼬리 질문

Q5. `URL`과 `NSURL`은 같은 타입인가? SE-0069의 값 타입화가 바꾼 것은?

원리

SE-0069의 동기는 이렇게 요약된다 — "Swift 표준 라이브러리의 공개 API는 거의 전부 값 타입으로 구성돼 있다(Swift 2.2 기준 struct 109개, class 6개)"인데, Foundation은 반대로 참조 타입 일색이라 let/var 구분이 무의미해지는 부조화가 있었다. 이 제안으로 AffineTransform, CharacterSet, Date, DateComponents, Data, IndexSet, IndexPath, Notification, PersonNameComponents, URL, URLComponents, URLQueryItem, UUID 13개 타입이 새 struct로 도입됐고, 각각 기존 NSURL/NSDate/NSData 등과 브리징 관계를 맺었다.

내부 동작

"같은 타입인가"를 코드로 직접 물어보면 답이 바로 나온다.

import Foundation

let url = URL(string: "https://swift.org")!
print(type(of: url))            // URL

let nsurl = url as NSURL
print(type(of: nsurl))          // NSURL
print(NSStringFromClass(object_getClass(nsurl)!))   // NSURL

// URL은 struct — 재할당해도 서로 영향 없음
var a = url
var b = a
b = URL(string: "https://apple.com")!
print(a.absoluteString, b.absoluteString)   // https://swift.org https://apple.com

// NSURL은 class — 두 변수가 같은 인스턴스를 계속 공유
let nsA: NSURL = nsurl
let nsB: NSURL = nsA
print(nsA === nsB)               // true

// 왕복 캐스팅은 값 동등성을 보존한다
print(url == (nsurl as URL))     // true
print(MemoryLayout<URL>.size, MemoryLayout<URL>.stride)   // 16 16

type(of:)가 URL과 NSURL을 각각 다른 타입으로 돌려준다는 것부터가 이 둘이 별개 타입이라는 직접 증거다. as NSURL 캐스팅은 as?/as!가 필요 없는, 성공이 보장된 브리징이지만 — 이 보장은 "같은 타입"이라서가 아니라 _ObjectiveCBridgeable이 값을 새 NSURL 인스턴스로 포장해주기 때문에 성립한다.

실험 · 도구

위 코드는 swift 파일명.swift로 그대로 재현된다. MemoryLayout<URL>.size가 16인 것도 직접 확인할 수 있다 — struct 내부에 문자열 저장소를 가리키는 포인터류 필드 2개(값 자체 또는 CoW 버퍼 참조) 정도로 구성된 작은 값 타입이라는 뜻이다.

프로젝트 적용

① 대부분의 Swift/최신 Foundation API는 URL만으로 충분하다. 옛 Objective-C 스타일 API(델리게이트, NSItemProvider 등)와 맞물릴 때만 NSURL로 브리징한다.

import Foundation

func loadConfig(from url: URL) throws -> Data {
    try Data(contentsOf: url)
}

// 옛 Objective-C 스타일 API와 맞물릴 때만 필요 — 항상 성공하는 브리징 캐스트
func legacyHandOff(_ url: URL) -> NSURL {
    url as NSURL
}

② URL이 struct라는 사실은 실무에서 실수를 줄여준다. 여러 곳에 넘겨도 각자 독립적으로 복사되므로, NSURL 참조를 여기저기 공유하던 시절처럼 "누가 이 URL을 몰래 바꿨지" 하는 버그가 구조적으로 생기지 않는다.

struct DownloadTask {
    let source: URL
    var destination: URL
}

func renamed(_ task: DownloadTask) -> DownloadTask {
    var copy = task
    copy.destination = copy.destination.appendingPathComponent("renamed")
    return copy   // task.destination은 전혀 영향받지 않는다
}

꼬리 질문

출처 · 참고자료