13 · 접근제어·ABI·매크로

이 챕터는 "코드를 얼마나 넓게 노출할 것인가"라는 질문을 세 층위에서 다룬다. 소스 레벨에서는 접근 제어자(private~open)가 누가 무엇을 볼 수 있는지를 정하고, 바이너리 레벨에서는 라이브러리 진화(library evolution, 컴파일된 프레임워크가 소스 재컴파일 없이도 버전을 올릴 수 있게 하는 체계)가 그 경계를 ABI(Application Binary Interface, 컴파일된 바이너리끼리 맞춰야 하는 규약) 안정성으로 확장하며, 컴파일 타임 레벨에서는 매크로가 반복 코드를 자동 생성한다. 마지막 두 문항(borrowing/consuming, ~Copyable)은 "복사"라는 개념 자체를 API 계약에 끌어들인 가장 최근의 언어 확장이다. Part A(Swift 언어 자체를 다루는 구간)의 마지막 장이며, 다음 장부터는 이 위에서 동작하는 Foundation으로 넘어간다.

Q1. package(SE-0386)는 왜 필요했는가? internal/public 조합으로는 왜 부족했나?

원리

swift-book AccessControl이 정의하는 접근 수준은 제약이 강한 순서로 6단계다: private(선언 자체와 같은 파일의 확장까지) → fileprivate(같은 소스 파일) → internal(같은 모듈, 기본값) → package(같은 패키지) → public(모듈 밖 어디서나, 단 상속·오버라이드는 불가) → open(모듈 밖 + 상속·오버라이드까지 허용). 지도 원칙은 하나다 — "더 제약이 강한 것으로 정의된 개체를 그보다 넓은 것에 노출할 수 없다"(public 함수가 internal 타입을 반환 타입으로 쓸 수 없는 이유). Swift 6.0의 SE-0409는 import 선언에도 접근 수준을 붙여(package import 등) 의존성 자체가 실수로 밖에 노출되는 것까지 막았다.

내부 동작

컴파일러가 "같은 패키지"를 판정하는 기준은 디렉터리 구조나 git 저장소가 아니라 딱 하나 — 두 모듈이 같은 -package-name 문자열로 컴파일됐는가다. SwiftPM을 쓰면 이 플래그를 직접 넘길 필요가 없다. 하나의 Package.swift 매니페스트 안의 모든 타겟에는 그 패키지의 name이 자동으로 -package-name으로 주입된다. 실제로 두 개의 로컬 타겟(Core, Feature)을 가진 패키지를 swift build -v로 빌드해 보면 두 타겟 모두 -package-name pkgtest가 컴파일 커맨드에 박혀 나온다 — 패키지 이름 하나가 그 안의 모든 타겟을 하나의 접근 영역으로 묶는 것이다. 반대로 별도의 Package.swift를 가진 다른 패키지(예: 사내 분석 SDK)가 로컬 경로로 CoreKit을 의존성에 추가해도, 그 패키지는 자기 자신의 이름으로 -package-name을 받기 때문에 CoreKit의 package 심볼은 여전히 안 보인다.

실험 · 도구

SwiftPM 없이 swiftc만으로도 직접 재현할 수 있다.

// CoreLib.swift
package func packageOnly() -> String { "core internals" }
public func publicAPI() -> String { packageOnly() }

// 1) CoreLib을 패키지 이름 appPkg로 빌드
swiftc -emit-module -module-name CoreLib -package-name appPkg \
  -emit-module-path /tmp/CoreLib.swiftmodule \
  -emit-library -o /tmp/libCoreLib.dylib CoreLib.swift

// 2) Client.swift(import CoreLib; packageOnly() 호출)를 같은 이름으로 타입체크 → 통과
swiftc -I /tmp -module-name Client -package-name appPkg -typecheck Client.swift
// EXIT=0

// 3) 패키지 이름만 다르게(otherPkg) 주고 다시 타입체크 → 실패
swiftc -I /tmp -module-name Client -package-name otherPkg -typecheck Client.swift
// error: cannot find 'packageOnly' in scope

실제로 위 3번 커맨드를 실행하면 컴파일러는 packageOnly라는 이름을 아예 모르는 것처럼 취급한다 — "접근 불가"가 아니라 "스코프에 없음" 에러라는 점이 흥미롭다. package 심볼은 다른 패키지 입장에서는 애초에 존재하지 않는 것과 동일하게 보인다.

프로젝트 적용

① CoreKit(공용 코어) + FeatureA/FeatureB(기능 모듈) 구조에서, CoreKit이 앱 안의 다른 모듈에게만 내주고 싶은 내부 유틸(재시도 정책, 내부 DTO 변환기)을 package로 선언한다. public이 아니므로 시그니처를 자유롭게 바꿔도 외부 소비자를 깨뜨릴 걱정이 없다.

// Sources/Core/Core.swift
package struct InternalConfig {
    package var flag: Bool
    package init(flag: Bool) { self.flag = flag }
}

package func internalHelper() -> Int { 42 }

// 진짜 외부에 내줄 것만 public
public struct PublicAPI {
    public init() {}
    public func run() -> Int {
        internalHelper() // 같은 패키지 안에서만 통하는 내부 경로
    }
}

// Sources/Feature/Feature.swift
import Core

func useConfig() -> InternalConfig {
    InternalConfig(flag: internalHelper() > 0) // 같은 패키지 → 컴파일 성공
}

② 사내 분석 SDK처럼 진짜 외부 패키지가 같은 심볼을 쓰려 하면 그 자리에서 막힌다 — public으로 새 게이트웨이 함수를 열어주지 않는 한 우회할 방법이 없다는 게 요점이다.

// 별도 패키지의 Consumer.swift
import Core

func tryUse() -> Int {
    internalHelper() // 다른 -package-name으로 빌드된 패키지에서 호출
}
// error: cannot find 'internalHelper' in scope
// → public API(PublicAPI.run())를 거치라는 신호

꼬리 질문

Q2. @inlinable / @usableFromInline / @frozen과 라이브러리 진화(resilience)의 관계는?

원리

swift.org의 Library Evolution 블로그가 정리하듯, 라이브러리 진화 모드가 켜진 라이브러리는 ABI를 깨지 않고도 struct에 필드를 추가·삭제·재배치하거나 enum에 새 케이스를 추가할 수 있다 — 대신 클라이언트는 그 타입을 간접적으로(비인라인 함수 호출을 통해) 다뤄야 한다. TSPL Attributes에 따르면 @inlinable은 "함수·메서드·연산 프로퍼티·서브스크립트·convenience init·deinit 선언에 붙여 그 구현을 모듈의 공개 인터페이스 일부로 노출"하는 어트리뷰트이고, @usableFromInline은 internal 선언을 "ABI상으로는 public이지만 소스 언어상으로는 public이 아닌" 상태로 만들어 같은 모듈의 @inlinable 코드 안에서만 참조 가능하게 한다.

내부 동작

직접 두 개의 struct를 라이브러리 진화 모드로 빌드해서 클라이언트 쪽 SIL을 뽑아보면 차이가 명확하다. @frozen이 없는 ResilientPoint의 필드를 읽는 클라이언트 함수는 SIL에서 function_ref ResilientPoint.x.getter를 만들어 apply로 호출한다 — 진짜 함수 호출이다. 반면 @frozen이 붙은 FrozenPoint를 읽는 함수는 struct_extract %0, #FrozenPoint.x 한 줄로 끝난다 — 필드를 메모리에서 바로 뽑아내는 명령이지 호출이 아니다. 파라미터 전달 방식도 다르다: 크기가 바뀔 수 있는 ResilientPoint는 @in_guaranteed ResilientPoint(주소로 간접 전달)를 쓰고, 레이아웃이 고정된 FrozenPoint는 그냥 $FrozenPoint(값으로 직접 전달)를 쓴다. @inlinable도 같은 방식으로 확인 가능하다 — 라이브러리의 @inlinable public func inlinableDouble과 일반 public func opaqueDouble을 각각 호출하는 클라이언트를 -O로 빌드하면, opaqueDouble 호출은 여전히 function_ref+apply로 남지만 inlinableDouble 호출은 아예 사라지고 그 자리에 곱셈 연산(smul_with_overflow)이 직접 박혀 있다 — 컴파일러가 본문을 그대로 가져와 인라인한 것이다. 덧붙여, @frozen struct와 그렇지 않은 struct를 라이브러리 진화 모드로 만든 .swiftinterface를 비교하면, 동일하게 Double 두 개짜리 필드 구성이라도 @frozen 쪽에만 Swift.Sendable·Swift.BitwiseCopyable 자동 준수가 붙는다 — 레이아웃이 고정되어야만 컴파일러가 "이 타입은 바이트 단위로 안전하게 복사 가능하다"는 성질을 확정할 수 있기 때문으로 보인다.

실험 · 도구

아래 커맨드로 위 SIL 차이를 그대로 재현할 수 있다.

// lib.swift
public struct ResilientPoint {
    public var x: Double, y: Double
    public init(x: Double, y: Double) { self.x = x; self.y = y }
}
@frozen
public struct FrozenPoint {
    public var x: Double, y: Double
    public init(x: Double, y: Double) { self.x = x; self.y = y }
}

swiftc -emit-module -enable-library-evolution -module-name Lib \
  -emit-module-interface-path /tmp/Lib.swiftinterface \
  -o /tmp/Lib.swiftmodule lib.swift

// client.swift
import Lib
func readR(_ p: ResilientPoint) -> Double { p.x }
func readF(_ p: FrozenPoint) -> Double { p.x }

swiftc -emit-sil -I /tmp client.swift -o client.sil
grep -A6 "func readR\|func readF" client.sil
// readR → function_ref ...Point.x.getter / apply
// readF → struct_extract %0, #FrozenPoint.x

@inlinable이 private 심볼을 참조하면 무슨 일이 나는지도 직접 볼 수 있다: @inlinable public func f() { privateHelper() }를 -enable-library-evolution으로 컴파일하면 error: global function 'privateHelper()' is private and cannot be referenced from an '@inlinable' function이 그대로 뜨고, 함께 딸려오는 note는 is not '@usableFromInline' or public이라고 정확히 원인을 짚어준다. private을 @usableFromInline internal로 바꾸면 즉시 컴파일이 통과한다.

프로젝트 적용

① 일반 앱 타겟이라면 이 셋을 신경 쓸 필요가 거의 없다 — -enable-library-evolution이 꺼져 있으면 @frozen은 관찰 가능한 효과가 없다. 이 어트리뷰트들은 바이너리로 배포하는 프레임워크(사내 XCFramework, 오픈소스 바이너리 배포판)를 만들 때만 실질적인 선택이 된다.

// 앱 타겟, 라이브러리 진화 모드가 아님
public struct UserProfile {   // @frozen 없이도 필드는 항상 직접 오프셋 접근
    public var name: String
    public var age: Int
}
// -enable-library-evolution이 꺼져 있으면 컴파일러가 모듈 전체를
// 한 번에 보고 최적화하므로, 이 챕터의 구분 자체가 무의미해진다.

② 사내 XCFramework를 만들 때는 트레이드오프를 명시적으로 골라라. "이 타입은 영원히 지금 필드 그대로 갈 것"이라 확신할 수 있는 값 타입(좌표, 색상 등)만 @frozen을 붙이고, 앞으로 필드를 늘릴 여지가 있는 타입은 resilient 상태(기본값)로 남겨 성능보다 유연성을 택한다.

// ✅ 좌표는 앞으로도 (x, y) 두 필드 이상 늘어날 일이 거의 없다
@frozen
public struct Point2D {
    public var x: Double
    public var y: Double
}

// ⚠️ 설정 struct는 다음 버전에 필드가 늘어날 가능성이 높다 — frozen 금지
public struct NetworkConfig {
    public var timeout: TimeInterval
    public var retryCount: Int
    // 다음 버전에 필드를 추가해도 ABI가 안 깨진다(resilient라서)
}

// 자주 호출되는 유틸 함수의 본문을 클라이언트에 노출해 인라인시키고 싶다면
@usableFromInline
internal func clampInternal(_ v: Double) -> Double { min(max(v, 0), 1) }

@inlinable
public func clamp01(_ v: Double) -> Double { clampInternal(v) }

꼬리 질문

Q3. 매크로(SE-0382/0389)는 컴파일 타임에 무엇을 하는가? 확장 결과는 어떻게 확인하는가?

원리

SE-0382는 매크로의 존재 이유를 "일반 표현식은 #file, #line 같은 몇몇 하드코딩된 예외를 빼면 자기 자신의 소스 코드를 조작할 수 없다"는 한계로 설명한다. 매크로는 이 한계를 깨되, AST(추상 구문 트리, 컴파일러 내부 구조)가 아니라 Swift 소스 코드로 확장 결과를 표현하는 설계를 택했다 — "Swift 프로그래머는 Swift 소스 코드를 이해하니, 매크로가 자기 소스에 적용된 결과도 추론할 수 있어야 한다"는 원칙이다. SE-0389는 attached 매크로의 5개 역할을 정의한다: peer(원래 선언 옆에 형제 선언 추가), member(타입 내부에 새 멤버 추가), accessor(프로퍼티에 getter/setter 추가), memberAttribute(기존 멤버들에 어트리뷰트 부착), conformance(프로토콜 준수 추가).

내부 동작

직접 swift package init --type macro로 매크로 패키지를 만들어 확인해보면, Package.swift의 .macro(name: "MacroDemoMacros", ...) 타겟이 @main struct ... CompilerPlugin을 구현하는 실행 파일로 빌드된다 — swift build 로그를 보면 이 타겟이 MacroDemoMacros-tool이라는 별도 실행 파일로 링크되는 것이 그대로 보인다. 클라이언트가 #stringify(a + b)를 쓰면, 컴파일러는 이 별도 프로세스를 호출해 구문 트리를 넘기고 (a + b, "a + b")라는 확장된 소스를 돌려받는다. -Xfrontend -dump-macro-expansions로 빌드하면 컴파일러가 실제로 만든 숨김 파일 이름까지 볼 수 있다 — @__swiftmacro_..._9stringifyfMf_.swift 같은 이름의 파일 안에 정확히 (a + b, "a + b")가 들어있다. 이 파일은 디스크에 남는 실제 소스이고, 그 다음 단계에서 다시 정상적으로 타입 체크된다 — SE-0382가 말한 "2단계 확장"(먼저 인자를 타입체크 → 매크로가 트리를 변환 → 결과를 다시 타입체크)이 그대로 관찰된다.

실험 · 도구

실제로 매크로 패키지를 만들어 확장 결과를 눈으로 확인할 수 있다.

swift package init --type macro --name MacroDemo
cd MacroDemo
swift run MacroDemoClient
// 출력: The value 42 was produced by the code "a + b"

// 확장된 실제 소스를 텍스트로 덤프
swift build --target MacroDemoClient \
  -Xswiftc -Xfrontend -Xswiftc -dump-macro-expansions
// @__swiftmacro_...stringifyfMf_.swift
// ------------------------------
// (a + b, "a + b")
// ------------------------------

Xcode에서는 더 간단하다 — 매크로 호출부(#stringify(...)나 @Observable 같은 것)를 우클릭 → "Expand Macro"를 선택하면 확장된 실제 소스가 인라인으로 펼쳐져 보인다(WWDC23 "Expand on Swift macros" 세션에서 시연). 매크로 구현 자체도 일반 Swift 코드이므로 SwiftSyntaxMacrosTestSupport로 유닛 테스트할 수 있다.

프로젝트 적용

① @Observable(Q3와 별개로 27장에서 다시 다룬다), #Predicate 같은 표준 매크로를 쓸 때도 "이게 뭘 생성했는지" 궁금하면 주저 말고 Expand Macro를 눌러라 — 디버깅 시간을 크게 줄여준다.

import SwiftCompilerPlugin
import SwiftSyntax
import SwiftSyntaxMacros

// #stringify(x + y) → (x + y, "x + y")
public struct StringifyMacro: ExpressionMacro {
    public static func expansion(
        of node: some FreestandingMacroExpansionSyntax,
        in context: some MacroExpansionContext
    ) -> ExprSyntax {
        guard let argument = node.arguments.first?.expression else {
            fatalError("컴파일러 버그: 인자가 없다")
        }
        return "(\(argument), \(literal: argument.description))"
    }
}

@main
struct MacroDemoPlugin: CompilerPlugin {
    let providingMacros: [Macro.Type] = [StringifyMacro.self]
}

② 매크로를 직접 도입할지 말지는 빌드 시간 대비 반복 코드 절감 효과로 저울질하라. 이 데모처럼 아주 작은 매크로 하나는 사전 빌드된 swift-syntax 지원 바이너리 덕에 swift build가 5초 안에 끝났지만(툴체인 버전이 정확히 맞을 때 얘기다), 프로젝트가 커지고 매크로 타겟이 여러 개로 늘어나거나 툴체인 버전이 어긋나 swift-syntax를 소스부터 새로 빌드해야 하는 상황에서는 빌드 시간이 눈에 띄게 늘어난다.

// ❌ 한두 곳뿐인 반복이면 매크로 도입 비용이 더 크다
struct Point { var x: Double; var y: Double } // 그냥 손으로 써도 충분

// ✅ 수십 개 타입에 걸쳐 같은 패턴(예: 로깅 코드 자동 삽입, Observable화)이
//    반복될 때 매크로가 빌드 시간 이상의 유지보수 이득을 준다
@Observable
final class ViewModel {
    var items: [String] = []   // 매크로가 추적 코드를 자동으로 덧붙인다
}

꼬리 질문

Q4. borrowing / consuming(SE-0377)은 무엇을 바꾸는가? 언제 명시해야 하는가?

원리

SE-0377 이전에는 컴파일러가 암묵적으로 컨벤션을 골랐다(예: 이니셜라이저나 세터는 보통 파라미터를 소비하는 편이 유리). borrowing/consuming 파라미터 안에서는 값이 암묵적으로 복사되지 않는다 — 복사가 필요하면 copy x 연산자로 명시해야 한다. 이 제안은 리뷰 과정에서 이름이 몇 차례 바뀌었다(borrow/take → consume/borrow → 최종 동명사형 borrowing/consuming) — 이는 이 기능이 "명령"이 아니라 "그 함수가 파라미터와 맺는 관계"를 서술한다는 설계 의도를 반영한다.

내부 동작

직접 세 함수 — 수식어 없는 기본, borrowing, consuming — 를 클래스 파라미터로 만들어 -emit-sil로 비교하면, 흥미로운 결과가 나온다. -Onone(최적화 없이)에서조차 수식어 없는 기본 함수와 명시적 borrowing 함수의 SIL 시그니처가 완전히 동일하다 — 둘 다 @convention(thin) (@guaranteed Box) -> Int다. @guaranteed는 "이 파라미터의 생존을 호출자가 보장하니 콜리는 retain/release를 안 해도 된다"는 뜻으로, 정확히 borrowing이 의미하는 바다. 즉 클래스를 단순히 읽기만 하는 파라미터는 수식어를 안 붙여도 이미 borrowing과 동일하게 컴파일된다 — 연구 노트가 말한 "기본값이 이미 대부분의 파라미터에서 borrowing"이라는 설명이 SIL 레벨에서 그대로 확인된다. 반면 consuming 함수는 @convention(thin) (@owned Box) -> Int로, @owned(호출자가 소유권을 완전히 넘긴다)를 쓰며 SIL 어트리뷰트에 copy/destroy 효과가 명시된다 — 실제로 해제 책임이 콜리로 넘어갔다는 뜻이다.

실험 · 도구

직접 SIL을 뽑아 세 시그니처를 비교해보라.

// borrow_test.swift
final class Box { var v: Int = 0 }
func useDefault(_ b: Box) -> Int { b.v }
func useBorrowing(_ b: borrowing Box) -> Int { b.v }
func useConsuming(_ c: consuming Box) -> Int { c.v }

swiftc -emit-sil -Onone borrow_test.swift | grep "sil hidden.*use"
// useDefault   : (@guaranteed Box) -> Int
// useBorrowing : (@guaranteed Box) -> Int   ← 기본과 동일
// useConsuming : (@owned Box) -> Int         ← 소유권 이동

noncopyable 타입에서는 이 구분이 컴파일 에러로 강제된다는 것을 Q5의 실험에서 바로 확인할 수 있다.

프로젝트 적용

① 대부분의 앱 코드는 이 수식어를 안 붙이는 게 맞다. 컴파일러가 이미 대부분의 읽기 전용 파라미터를 borrowing처럼 최적화하므로, 수식어를 뿌리는 것은 가독성만 떨어뜨리고 실이익은 미미하다.

// ❌ 과잉 최적화 — 이미 컴파일러가 알아서 처리한다
func process(_ items: borrowing [Item]) -> Int { items.count }

// ✅ 그냥 쓴다. 컴파일러가 읽기 전용 사용 패턴을 보고 스스로 골라준다
func process(_ items: [Item]) -> Int { items.count }

② 예외는 두 가지다 — noncopyable 타입을 다루는 API를 설계할 때(Q5), 그리고 대량의 대형 값 타입을 반복적으로 넘기는 뜨거운 경로에서 프로파일링으로 ARC 트래픽이 실제 병목임을 확인했을 때다. "확인 없이 미리 붙이지 말라"가 원칙이다.

struct FileHandle: ~Copyable {
    private let fd: Int32
    // consuming: 이 함수가 값을 소비(해제)한다는 걸 시그니처로 드러낸다
    consuming func close() { /* ... */ }
    // borrowing: 값을 읽기만 하고 계속 살려둔다는 걸 드러낸다
    borrowing func isValid() -> Bool { fd >= 0 }
}

꼬리 질문

Q5. ~Copyable(SE-0390/0427)은 어떤 문제를 푸는가? class는 왜 noncopyable이 될 수 없는가?

원리

SE-0390은 문제를 이렇게 정의한다 — "지금까지 Swift의 모든 타입은 copyable하다, 즉 어떤 값이든 동일하고 상호교환 가능한 여러 표현을 만들 수 있다"는 전제가 있었다. 이 전제가 항상 맞는 건 아니다: 파일 핸들을 복사해서 두 곳에서 각각 close()를 부르면 이중 해제가 되고, 락을 복사하면 상호 배제가 깨진다. noncopyable 타입은 유일 소유권(unique ownership)을 표현해 이런 자원을 타입 시스템이 직접 지킨다. noncopyable 타입은 deinit을 가질 수 있고, consuming 메서드 안에서 discard self를 쓰면 그 인스턴스의 deinit 실행 자체를 억제할 수 있다(예: "닫는" 메서드가 스스로 정리를 다 했으니 자동 정리는 필요 없다고 선언). SE-0427은 최초 SE-0390의 강한 제약(제네릭 타입 인자 불가, Optional/Array/튜플에 못 담음)을 풀어, 표준 라이브러리에 Copyable 프로토콜을 실재하는 것으로 도입했다 — 이제 <T>는 사실 <T: Copyable>과 같고, noncopyable 타입을 받으려면 <T: ~Copyable>로 명시해야 한다.

내부 동작

noncopyable 위반을 잡는 검사는 타입 체크가 아니라 SIL 단계에서 일어난다는 게 직접 실험에서 드러나는 흥미로운 지점이다. let a = FileDescriptor(fd: 3); let b = a; _ = a 같은 코드를 swiftc -typecheck로만 돌리면 에러가 안 난다. 하지만 swiftc -emit-sil로 실제 컴파일을 진행하면 error: 'a' used after consume가 뜬다 — note: consumed here가 let b = a 줄을, note: used here가 그 다음 _ = a 줄을 정확히 가리킨다. 이는 이동/소비 추적이 SSA 형태의 SIL 위에서 도는 소유권 검사기(ownership checker)의 일이기 때문이다. consuming func close()를 discard self 없이 정의하고 직접 실행해보면, close()가 끝나자마자 deinit이 자동으로 한 번 더 실행되는 것이 출력 순서로 보인다 — consuming이라는 것만으로는 자동 정리를 막지 못하고, discard self를 추가해야 비로소 deinit이 억제된다는 것을 직접 실행 결과로 확인할 수 있다.

실험 · 도구

직접 컴파일해보면 타입 체크와 SIL 단계의 차이, 그리고 discard self의 효과까지 눈으로 확인할 수 있다.

struct FileDescriptor: ~Copyable {
    private let fd: Int32
    init(fd: Int32) { self.fd = fd }
    deinit { print("closing fd \(fd)") }
    consuming func close() { print("explicit close \(fd)") }
}
func test() {
    let a = FileDescriptor(fd: 3)
    let b = a   // 이동
    _ = a       // 이미 이동한 값을 다시 사용
    _ = b
}

swiftc -typecheck test.swift   // EXIT=0 — 여기선 안 잡힌다
swiftc -emit-sil test.swift -o /dev/null
// error: 'a' used after consume
//   note: consumed here      (let b = a)
//   note: used here          (_ = a)

struct FileDescriptor: ~Copyable {
    private let fd: Int32
    init(fd: Int32) { self.fd = fd; print("open fd \(fd)") }
    deinit { print("deinit: closing fd \(fd) (자동)") }
    consuming func close() {
        print("explicit close fd \(fd)")
        // discard self 없음
    }
}
let f = FileDescriptor(fd: 7)
f.close()
// 실행 결과:
// open fd 7
// explicit close fd 7
// deinit: closing fd 7 (자동)   ← discard self가 없으면 close() 직후 deinit이 또 돈다!

// discard self를 추가하면:
// open fd 7
// explicit close fd 7
// (deinit 로그가 안 찍힌다 — discard self가 억제했다)

프로젝트 적용

① 유일해야 하는 시스템 자원(파일 핸들, 소켓, 락)을 감싸는 래퍼 타입에 ~Copyable을 써서 "실수로 복사해 이중 해제하는 버그"를 컴파일 타임에 원천 차단한다.

struct FileDescriptor: ~Copyable {
    private let raw: Int32
    init(raw: Int32) { self.raw = raw }

    deinit {
        // close(raw) 같은 실제 시스템 콜 — 아무도 안 닫으면 여기서 정리
    }

    consuming func close() {
        // 명시적으로 닫는다 — 자동 정리가 또 도는 걸 막는다
        discard self
        // 실제로는 여기서 close(raw) 시스템 콜을 호출
    }

    borrowing func read(into buffer: inout [UInt8]) -> Int {
        // 소유권은 안 가져가고 읽기만
        0 // 실제로는 read(raw, ...) 호출
    }
}

func handleUpload(_ file: consuming FileDescriptor) {
    // ...
    file.close() // 여기서 소유권이 소비된다
    // file.close() 를 한 번 더 부르면 컴파일 에러 — 'consumed more than once'
}

② class는 이 용도로 쓸 수 없다는 걸 명확히 하라 — "참조 하나만 갖고 있으면 안전하겠지"라는 생각으로 class를 쓰면, 누군가 그 참조를 배열에 저장하거나 클로저로 캡처하는 순간 "유일해야 한다"는 불변식이 조용히 깨진다. noncopyable struct는 애초에 그런 복사 자체를 언어가 막아준다.

// ❌ class NotAllowed: ~Copyable { var x = 1 }
// error: classes cannot be '~Copyable'
//   → 참조(포인터) 자체는 항상 복사 가능하고, ARC 전체가
//     "참조를 복사하고 retain count를 올린다"는 전제 위에 서 있기 때문

// class로 '유일함'을 흉내내면 컴파일러가 못 막아준다
final class FileHandleBox {
    let raw: Int32
    init(raw: Int32) { self.raw = raw }
}
let box1 = FileHandleBox(raw: 3)
let box2 = box1          // 참조 복사 — 컴파일러가 막을 방법이 없다
// box1.raw와 box2.raw가 같은 fd를 가리키는 걸 아무도 못 막는다

꼬리 질문

여기까지가 Swift 언어 자체의 마지막 장이다. 다음 장(14 · Foundation이란 무엇인가)부터는 이 접근 제어·ABI 규칙 위에서 실제로 배포되는 Foundation 프레임워크로 넘어간다 — NS 접두사의 기원부터 swift-foundation 재작성까지, 우리가 매일 import하는 그 라이브러리의 정체를 다룬다.

출처 · 참고자료