15 · 모듈 분할과 크로스플랫폼

앞 장에서는 Foundation이 무엇이고 어디서 왔는지, 왜 통째로 다시 쓰였는지를 다뤘다. 이 장은 그 재작성이 남긴 경계선 — FoundationEssentials, FoundationInternationalization, Foundation이라는 세 모듈이 실제로 어디서 갈라지는지 — 를 파고든다. 문항은 네 개뿐이지만 두 번째 질문이 이 챕터의 핵심이다. "FoundationEssentials를 쓰면 iOS 앱이 가벼워진다"는 말은 플랫폼을 명시하지 않으면 거의 항상 틀린 말이 되고, 그 이유를 이 장에서 직접 컴파일해 확인한다.

Q1. FoundationEssentials / FoundationInternationalization / Foundation은 각각 무엇을 담고 언제 import하는가?

원리

ICU(International Components for Unicode)는 로케일별 달력 규칙, 날짜·숫자 포맷, 정렬 규칙 같은 국제화 데이터를 담은 라이브러리로, 데이터 세트만 수 메가바이트에 달한다. Apple 플랫폼에서는 OS가 이 데이터를 이미 갖고 있어 신경 쓸 일이 없지만, 서버 컨테이너나 임베디드 기기처럼 OS가 그런 걸 보장하지 않는 환경에서는 이 데이터가 고스란히 배포물 크기에 더해진다. "The Future of Foundation"이 재작성 동기 중 하나로 명시한 게 정확히 이 지점이다 — Swift 6 발표 블로그는 "바이너리 크기에 민감한 앱은 ICU 데이터를 생략한 FoundationEssentials 라이브러리를 import할 수 있다"고 못박는다.

내부 동작

세 모듈의 관계를 표로 정리하면 다음과 같다.

즉 Foundation은 별도 구현이 아니라 FoundationEssentials + FoundationInternationalization을 그대로 다시 내보내는(re-export) 계층이고, Darwin에서는 여기에 NSObject 기반 레거시 클래스와 Objective-C 브리징 표면이 더 붙는다(16장에서 다룬다). FoundationEssentials만 import해도 Calendar·Locale 타입 자체는 여전히 쓸 수 있지만, 로케일에 따라 실제로 달라지는 동작(요일 이름, 통화 기호, 복수형 규칙)은 FoundationInternationalization 없이는 온전히 동작하지 않는다.

실험 · 도구

Xcode 15+ SDK가 설치된 환경에서는 다음처럼 좁은 모듈만 단독 import해 컴파일해볼 수 있다.

swift -e 'import FoundationEssentials
let u = URL(string: "https://swift.org")!
print(u.host!)'

이 챕터를 쓴 환경(Xcode.app 없이 커맨드라인 툴즈 SDK만 있는 macOS)에서는 위 명령이 error: no such module 'FoundationEssentials'로 실패했다 — FoundationEssentials가 Darwin에서 아무 데서나 바로 손에 잡히는 모듈이 아니라는 걸 직접 겪은 사례다(Q2에서 이 실패를 더 파고든다). SPM 패키지 안에서 swift-foundation을 명시적으로 의존성에 걸면 이 문제 없이 빌드된다.

프로젝트 적용

① 멀티플랫폼 패키지의 핵심 로직 타깃은 FoundationEssentials만 의존하도록 쪼갠다. 로케일 포매팅이 필요한 코드는 별도 타깃으로 분리한다.

let package = Package(
    name: "MyKit",
    targets: [
        // 서버·CLI에서도 그대로 쓸 핵심 로직 — ICU 없이 컴파일된다
        .target(
            name: "MyKitCore",
            dependencies: []   // FoundationEssentials는 툴체인이 암시적으로 제공
        ),
        // 사람이 읽는 포매팅이 필요한 코드만 따로
        .target(
            name: "MyKitFormatting",
            dependencies: ["MyKitCore"]
        ),
    ]
)

② 소스 파일 안에서는 필요한 만큼만 좁게 import한다. Foundation 전체를 습관적으로 쓰면 로케일 포매팅을 전혀 안 쓰는 파일에서도 ICU 경로가 딸려온다는 신호를 놓치기 쉽다.

// MyKitCore/Parser.swift — 로케일 포매팅이 전혀 필요 없는 순수 파싱 로직
import FoundationEssentials   // Data, URL, JSONDecoder만 있으면 충분

struct Parser {
    func parse(_ data: Data) throws -> [String: Any] {
        try JSONSerialization.jsonObject(with: data) as? [String: Any] ?? [:]
    }
}

꼬리 질문

Q2. "FoundationEssentials를 쓰면 iOS 앱이 가벼워진다"가 대체로 틀린 이유는?

원리

동적 링크(dynamic linking)는 실행 파일이 라이브러리 코드를 자기 안에 복사해 넣지 않고, 실행 시점에 이미 메모리에 있는(혹은 로드될) 공유 라이브러리를 가리키는 참조만 담는 방식이다. 정적 링크(static linking)는 반대로 라이브러리 코드 자체가 실행 파일 안에 그대로 복사돼 들어간다. 어느 쪽이든 "코드가 존재한다"는 사실은 같지만, 그 코드가 내 산출물의 크기에 더해지는지는 완전히 다르다.

내부 동작

Apple 플랫폼은 시스템 프레임워크·라이브러리를 하나의 거대한 파일로 미리 링크해 부팅 시 메모리에 매핑해두는 dyld 공유 캐시를 쓴다. Foundation.framework는 이 캐시 안에 있고, 기기의 모든 프로세스가 이 캐시를 공유해서 읽는다. 앱을 빌드하면 Foundation 심볼에 대한 참조만 앱 바이너리에 남고, 실제 구현 코드는 앱 번들 안 어디에도 없다 — 그래서 import Foundation이든 import FoundationEssentials든, Darwin에서는 최종적으로 같은 공유 캐시 안의 같은 프레임워크를 가리키게 된다.

Linux나 Windows에는 이런 시스템 전역 공유 캐시가 없다. Swift 툴체인이 제공하는 FoundationEssentials/FoundationInternationalization 라이브러리는 빌드 산출물에 직접 링크되며, FoundationInternationalization을 아예 빼고 FoundationEssentials만 쓰면 ICU 데이터를 포함한 그만큼의 코드·데이터가 산출물에서 빠진다. Swift Forums의 "FoundationEssentials on Darwin?" 스레드는 이 지점을 정확히 짚는다 — Apple 플랫폼에서 Foundation은 OS와 함께 배포되고 런치 시점에 동적 링크되므로 앱 바이너리 자체를 부풀리지 않는다는 것, 그리고 macOS에서는 Foundation에만 있고 FoundationEssentials엔 없는 심볼이 실제로 존재해 크로스플랫폼 패키지가 플랫폼별로 다르게 컴파일 에러를 내는 문제가 보고됐다는 것. Apple 엔지니어 Tony Parker는 이 스레드에서 "이해한다, 다만 단기적 해법은 없고 계속 고민 중"이라고 답했다 — 2026년 현재도 미해결 과제로 남아 있다.

실험 · 도구

Darwin에서는 otool -L로 직접 확인할 수 있다. import Foundation만 쓰는 최소 실행 파일을 만들어 링크 테이블을 찍어보면 된다.

// full_test.swift
import Foundation
let u = URL(string: "https://example.com")!
print(u.absoluteString)

$ swiftc -O full_test.swift -o full_test
$ ls -l full_test
-rwxr-xr-x  1 user  wheel  52248  7 27 18:24 full_test

$ otool -L full_test
full_test:
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, ...)
	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, ...)
	/usr/lib/swift/libswiftCore.dylib (...)
	/usr/lib/swift/libswiftCoreFoundation.dylib (..., weak)
	...

바이너리는 52,248바이트뿐이고, otool -L은 Foundation.framework가 참조로만 걸려 있음을 그대로 보여준다 — 실제 Foundation 구현 코드는 이 52KB 안 어디에도 없다. 같은 환경에서 import FoundationEssentials만 쓰는 버전을 별도로 컴파일해 비교하려 했으나, 이 머신(Xcode.app 없이 커맨드라인 툴즈 SDK만 설치됨)에서는 error: no such module 'FoundationEssentials'로 실패했다 — 위 포럼 스레드가 지적하는 "FoundationEssentials가 Darwin에서 아직 매끄러운 1급 시민이 아니다"는 문제를 그대로 겪은 것이다. Xcode 15+ 전체 SDK가 있는 환경이라면 같은 비교를 swiftc -O ess_test.swift -o ess_test로 직접 재현하고, 두 바이너리의 ls -l 크기 차이가 (있다면) 몇 바이트 수준에 그치는지 확인해보길 권한다.

프로젝트 적용

① iOS 앱에서 FoundationEssentials로 바꾸는 실익은 "IPA 용량 절감"이 아니라 "레거시 NS* API 표면을 실수로 안 쓰게 강제하는 것", "크로스플랫폼 타깃과 소스를 공유할 때 컴파일이 걸러주는 것" 정도로 기대치를 낮춰야 한다.

// Shared/UserProfile.swift — iOS 앱과 서버 타깃이 공유하는 순수 모델 파일
// 여기서 FoundationEssentials만 쓰면 "실수로 UIKit·NSObject 브리징에 기대는 코드"를
// 컴파일 단계에서 걸러낼 수 있다 — iOS 바이너리 크기와는 무관한 이득이다
import FoundationEssentials

struct UserProfile: Codable, Sendable {
    let id: UUID
    let name: String
    let joinedAt: Date
}

② 진짜 크기 이득이 필요한 곳은 Linux 서버 타깃이다. Package.swift에서 그 타깃만 FoundationInternationalization을 빼면 ICU 데이터가 산출물에서 실제로 빠진다.

.executableTarget(
    name: "APIServer",
    dependencies: ["MyKitCore"]
    // FoundationEssentials까지만 — FoundationInternationalization은 안 걸었다
    // 로그·API 응답은 ISO 8601 같은 고정 포맷만 쓰고, 사람이 읽는 로케일 포맷은 안 쓴다는 전제
)

꼬리 질문

Q3. 2026년 현재 Linux·Windows의 Foundation은 어디까지 왔는가? Windows Workgroup은 왜 생겼나?

원리

swift-foundation 재작성이 Darwin·Linux·Windows가 같은 핵심 로직을 공유하게 만든 건 맞지만, "같은 로직"과 "같은 완성도"는 다른 이야기다. 파일 시스템 경로 구분자, 프로세스·권한 모델, 네트워킹 스택처럼 OS마다 근본적으로 다른 부분은 아무리 코어를 공유해도 플랫폼별 어댑터 코드가 따로 필요하고, 그 어댑터의 성숙도가 플랫폼마다 다르게 진행된다.

내부 동작

Windows Workgroup 신설 발표는 이 개선이 아직 끝나지 않았다는 것 자체를 공식적으로 인정하는 문서다 — 별도 워크그룹을 만들 필요가 있었다는 사실이, "이미 다 됐다"가 아니라 "구조적으로 더 손볼 게 남아 있다"는 신호다. Foundation 자체의 거버넌스는 2026년 기준 Foundation Workgroup(의장 Tina Liu, 투표권자 9인+의장 1인, 분기별 회의)이 맡아 커뮤니티 API 제안 리뷰와 프로젝트 방향을 정한다.

실험 · 도구

이 챕터는 Docker·리눅스 컨테이너를 직접 띄우지 않고 썼다 — 로컬에서 검증 가능한 범위를 넘어서는 주장이라, 위 표는 swift.org 공식 발표문과 GitHub 레포 자체를 1차 출처로 삼았다. 리눅스 환경이 있다면 다음처럼 직접 재현해볼 수 있다.

docker run --rm swift:6.2 swift -e '
import FoundationEssentials
print(URL(string: "https://swift.org")!.host!)
'
// macOS에서 같은 코드를 돌려 두 결과가 바이트 단위로 같은지 비교하면
// "통합 구현"이 실제로 같은 로직을 공유한다는 걸 체감할 수 있다

프로젝트 적용

① Linux 서버 타깃을 채택할 때는 "Foundation이 Swift라 이제 다 된다"고 가정하지 말고, 실제로 쓸 API(특히 파일 시스템·프로세스·네트워킹 경계)가 그 플랫폼에서 되는지 먼저 확인한다.

#if os(Linux)
// Linux 전용 경로 확인이 필요한 API는 여기서 미리 검증하고 주석으로 남긴다
// 예: 특정 FileManager 리소스 값이 Linux에서 아직 nil을 돌려주는 경우가 있다
#endif

② Windows 타깃을 고려 중이라면 2026년 현재도 "진행 중"이라는 전제 위에서, 필요한 API를 미니 스모크 테스트로 먼저 그 플랫폼에서 직접 빌드해 확인하기 전까지는 완전성을 가정하지 않는다.

// 이 함수만 별도 실행 파일로 만들어 실제 타깃 플랫폼(Windows)에서 빌드해본다
import Foundation

func smokeTest() {
    let path = FileManager.default.currentDirectoryPath
    print("현재 경로:", path)
    // 이 한 줄이 실패 없이 도는지가, 문서보다 훨씬 믿을 만한 확인 방법이다
}
smokeTest()

꼬리 질문

Q4. 크로스플랫폼 Swift 코드에서 Foundation 의존을 어떻게 다뤄야 하는가?

원리

Q1~Q3에서 본 모듈 분할·플랫폼 성숙도 차이는 결국 "코드를 어떻게 짜야 여러 플랫폼에서 실제로 컴파일·동작하는가"라는 실무 문제로 수렴한다. 원칙은 단순하다 — 필요한 것만 좁게 의존하고, 그 의존이 모든 타깃에서 실제로 만족되는지 컴파일 타임과 CI 양쪽에서 확인한다.

내부 동작

canImport()는 컴파일 타임에 특정 모듈을 import할 수 있는지 검사하는 조건부 컴파일 지시문이다. 최신 SDK가 있는 Darwin 환경과 FoundationEssentials를 직접 제공하는 리눅스 툴체인에서는 참이 되고, 그렇지 않은 환경(가령 이 챕터를 쓴 커맨드라인 툴즈뿐인 macOS)에서는 거짓이 되어 Foundation 쪽으로 떨어진다.

#if canImport(FoundationEssentials)
import FoundationEssentials
#else
import Foundation
#endif

// 이 아래 코드는 두 모듈 모두에 있는 API로만 작성해야
// 어느 브랜치로 컴파일되든 동작이 같다는 걸 보장할 수 있다
struct RequestID: Codable, Sendable {
    let value: UUID
}

타깃 구성 원칙을 표로 정리하면 다음과 같다.

실험 · 도구

지금 작성 중인 소스가 실제로 어느 모듈에 의존하는지는 swiftc -typecheck를 여러 -D 조합으로 돌려 확인할 수 있고, 패키지 전체는 각 플랫폼용 툴체인으로 swift build를 실제로 돌리는 것만이 확실하다. 이 챕터의 검증 범위(Docker 금지)에서는 아래 스켈레톤을 직접 실행하지는 않았다 — 리눅스 CI가 있다면 그대로 파이프라인에 넣어볼 수 있다.

# GitHub Actions 예 — 개념만
# jobs:
#   test-darwin:
#     runs-on: macos-latest
#   test-linux:
#     runs-on: ubuntu-latest
#     container: swift:6.2
# 두 잡이 모두 통과해야 "크로스플랫폼"이라 말할 수 있다

프로젝트 적용

① Package.swift에서 타깃을 처음부터 분리해, 공유 로직 타깃이 Darwin 전용 API에 접근할 길 자체를 없앤다.

let package = Package(
    name: "SharedKit",
    platforms: [.iOS(.v17), .macOS(.v14)],
    targets: [
        // 서버·클라이언트가 공유 — Darwin 전용 API를 쓰면 Linux 빌드에서 즉시 에러가 난다
        .target(name: "SharedKitCore"),
        // iOS 앱에서만 링크 — 여기서는 Foundation·UIKit을 자유롭게 쓴다
        .target(name: "SharedKitUIKit", dependencies: ["SharedKitCore"]),
    ]
)

② "일단 import Foundation을 써두고 안 쓰는 심볼은 링커가 알아서 뺄 것"이라는 가정에 기대지 않는다. Swift 정적 링커가 상당 부분의 미사용 코드를 제거하긴 하지만, import Foundation 자체가 FoundationInternationalization(그리고 ICU)까지 끌어오는 경로를 여는 것이므로, 처음부터 좁게 import하는 편이 그 경로를 아예 안 여는 확실한 방법이다.

// ❌ 나쁜 예 — 습관적으로 전체를 끌어온다, Linux 산출물에 ICU까지 딸려올 수 있다
import Foundation

// ✅ 좋은 예 — 이 파일이 실제로 쓰는 것만 좁게 선언
#if canImport(FoundationEssentials)
import FoundationEssentials
#else
import Foundation
#endif

func normalizedID(_ raw: String) -> UUID? {
    UUID(uuidString: raw)
}

꼬리 질문

출처 · 참고자료