29 · 배타적 접근과 Unsafe 메모리

여기서부터 Part C다. Part A가 언어의 의미론, Part B가 Foundation의 API였다면, Part C는 그 아래 — 메모리를 직접 만지는 층과 최근 두 릴리스가 새로 얹은 도구들이다. 이 챕터는 그중 가장 오래된 규칙에서 시작한다. Swift에는 Array도 class도 아닌, 언어 전체를 관통하는 메모리 규칙이 하나 있다. 어떤 메모리를 수정하는 동안에는 아무도 그 메모리에 접근할 수 없다는 것. 이 규칙(law of exclusivity)은 Swift 4부터 있었지만, 대부분의 개발자는 Simultaneous accesses to 0x... 크래시를 처음 만나는 날에야 그 존재를 알게 된다.

이 챕터의 결론을 먼저 말하면 이렇다. 같은 위반이 어디서 걸리느냐에 따라 위험도가 완전히 다르다. 컴파일 타임에 걸리면 가장 안전하고, 런타임에 SIGABRT로 죽으면 그다음이고, 아무 일도 없이 exit 0으로 통과하는 게 가장 위험하다. 이 세 가지를 실제로 재현해 종료 코드까지 비교한다.

Q1. 메모리 배타적 접근(law of exclusivity)이란 무엇이며, 컴파일러는 언제 정적으로 잡고 언제 런타임으로 미루는가?

원리

We propose that Swift should instead enforce a general rule that
potential modifications of variables must be exclusive with
any other access to that variable.

문장에서 배타성을 요구하는 주체가 modifications임에 주목한다. "모든 접근이 배타적"이 아니라 "수정은 다른 어떤 접근과도 겹칠 수 없다"이므로, 읽기끼리는 겹쳐도 된다. 실측으로도 같은 변수를 두 인자로 읽기만 하는 호출은 정상 컴파일·실행된다 — 이 규칙의 정확한 이름은 "배타적 수정"에 가깝다.

왜 이런 규칙이 필요한가. inout은 겉보기엔 "참조로 넘긴다"처럼 보이지만 Swift의 공식 모델은 copy-in / copy-out, 정확히는 빌림(borrow)이다. 함수가 inout 인자를 들고 있는 동안 그 변수는 "함수에게 대여 중"이며, 대여 기간에 원래 자리로 다른 경로가 끼어들면 두 개의 수정이 서로를 덮어쓴다. SE-0176은 이 상태를 언어 차원에서 금지해, 값 타입이 값처럼 동작한다는 약속을 지킨다.

이 규칙은 성능 보장이기도 하다. 배타성이 보장되면 컴파일러는 "이 함수가 도는 동안 이 메모리는 아무도 안 건드린다"고 가정할 수 있어, 값을 레지스터에 올려두고 매번 다시 읽지 않아도 된다. 배타적 접근은 안전성 규칙이면서 최적화의 전제다. 이것이 Part A 13장에서 본 borrowing/consuming(SE-0377)이 서 있는 토대이기도 하다.

내부 동작

접근에는 기간(duration)이 있다. 순간적으로 읽고 끝나는 접근(instantaneous)과, 함수 호출이 끝날 때까지 이어지는 접근(long-term)이 다르다. inout 인자와 mutating 메서드의 self가 후자다. 컴파일러는 이 기간을 "접근 범위(access scope)"로 표현하고, 범위가 겹치는지 검사한다.

동적 검사는 공짜가 아니다. 접근 시작 시 swift_beginAccess가 스레드별 접근 집합(AccessSet)에 이 접근을 등록하고, 끝날 때 swift_endAccess가 제거한다. 등록하는 순간 이미 겹치는 접근이 있으면 그 자리에서 진단 메시지를 찍고 중단한다. 그래서 크래시 로그에 swift::runtime::AccessSet::insert가 등장한다 — 뒤의 Q2에서 실제 로그로 확인한다.

실험 · 도구

먼저 정적으로 걸리는 쪽. 같은 변수를 두 inout 인자로 넘기면 컴파일러가 두 개의 서로 다른 진단을 낸다.

func swapTwo(_ a: inout Int, _ b: inout Int) { let t = a; a = b; b = t }
var x = 1
swapTwo(&x, &x)   // 같은 변수를 두 inout 인자로

ex1.swift:3:13: error: inout arguments are not allowed to alias each other
ex1.swift:3:9: error: overlapping accesses to 'x', but modification requires
               exclusive access; consider copying to a local variable

두 진단이 함께 나오는 게 포인트다. 앞의 것은 "inout 인자끼리 같은 메모리를 가리키면 안 된다"는 좁은 규칙이고, 뒤의 것이 배타적 접근이라는 일반 규칙이다. 뒤쪽 문구에 해결책까지 붙어 있다 — consider copying to a local variable.

프로젝트 적용

① 정적 위반은 대부분 "지역 복사본을 만들라"로 해결된다. 진단문이 시키는 그대로다.

var x = 1
var tmp = x        // 지역 복사본 — 접근 범위가 분리된다
swapTwo(&x, &tmp)
x = tmp            // 필요하면 되돌려 쓴다

② 더 흔한 실무 형태는 같은 배열의 두 원소를 동시에 inout으로 넘기는 경우다. 여기서 이 규칙의 가장 중요한 성질이 드러난다 — 배타성은 원소 단위가 아니라 프로퍼티(저장 위치) 단위로 강제된다. 인덱스가 서로 달라도 두 접근이 모두 같은 cells 프로퍼티를 통과하므로 범위가 겹친다.

func modify(_ a: inout [Int], at i: Int) { a[i] += 1 }
func two(_ a: inout Int, _ b: inout Int) { a += b }

struct S {
    var cells = [1, 2, 3]
    var n = 0

    mutating func caseA() { modify(&cells, at: cells.count - 1) }  // ✅ 합법
    mutating func caseB() { two(&n, &n) }                          // ❌ 에러
    mutating func caseC() { two(&n, &cells[0]) }                   // ✅ 합법
    mutating func caseD() { two(&cells[0], &cells[1]) }            // ❌ 에러
}

cases.swift:9:33: error: overlapping accesses to 'self.n', but modification
                  requires exclusive access; consider copying to a local variable
cases.swift:11:33: error: overlapping accesses to 'self.cells', but modification
                   requires exclusive access; consider copying to a local variable

네 경우의 차이가 규칙의 경계를 정확히 그려준다.

마지막 줄이 실무에서 사람을 놀라게 하는 대목이다. "0번과 1번은 다른 원소인데 왜?"라는 질문의 답은, 컴파일러가 보는 단위가 cells[0]이 아니라 cells라는 것이다. 배열 첨자에 대한 inout 접근은 Array의 _modify 접근자(Part A 05장)를 통과하며, 그 접근자는 버퍼 전체를 대여한다. 그래서 원소 두 개를 맞바꾸려면 swapAt(_:_:)처럼 한 번의 접근 안에서 처리하는 API를 써야 한다.

func two(_ a: inout Int, _ b: inout Int) { a += b }

// ❌ 두 대여가 같은 cells 프로퍼티에서 겹친다 — 컴파일 에러
// var x = [1, 2, 3]; two(&x[0], &x[1])

// ✅ 해법 1 — 교환이 목적이면 한 번의 접근으로 끝내는 표준 API를 쓴다
var p = [1, 2, 3]
p.swapAt(0, 1)
print("swapAt:", p)          // [2, 1, 3]

// ✅ 해법 2 — 임의의 inout 함수를 써야 하면 지역 값으로 꺼낸다
var q = [1, 2, 3]
var a = q[0], b = q[1]       // 읽기 접근이 여기서 끝난다
two(&a, &b)                  // 지역 변수끼리는 겹치지 않는다
q[0] = a; q[1] = b           // 쓰기 접근을 각각 따로 시작한다
print("지역 분리:", q)        // [3, 2, 3]  — a = 1 + 2 = 3

실무에서 이 규칙을 가장 자주 위반하는 자리는 셋이다 — 전역 캐시·싱글턴을 inout으로 넘기는 코드, static var 카운터를 여러 경로에서 갱신하는 코드, 그리고 클로저가 캡처한 변수를 캡처 밖에서도 수정하는 코드다. 앞의 둘은 런타임 검사로 넘어가므로 테스트에서 안 걸리고 프로덕션에서 터질 수 있다.

꼬리 질문

Q2. 릴리스(-O) 빌드에서도 배타적 접근 검사가 살아 있는가? 왜 어떤 위반은 조용히 통과하는가?

원리

Swift 컴파일러에는 -enforce-exclusivity=<enforcement> 옵션이 있다(swiftc -h에 Enforce law of exclusivity로 문서화돼 있다). 기본값은 checked — 정적으로 증명 못 한 접근에 런타임 검사를 삽입한다. 실측으로 확인한 것은 이것이다 — 이 툴체인(6.2.1)에서 -Onone과 -O 양쪽 모두 검사가 삽입되고 위반 시 중단한다(아래 실험). 즉 "릴리스니까 검사가 빠진다"는 가정은 성립하지 않으며, 이것이 배타적 접근 위반이 프로덕션 크래시로 보고되는 이유다.

내부 동작

런타임 검사의 실체는 스레드 로컬 접근 집합이다. swift_beginAccess(주소, 버퍼, 플래그, PC)가 호출되면 그 스레드의 AccessSet에 {주소, 종류}를 삽입하고, 삽입하려는 접근이 기존 항목과 충돌하면(둘 중 하나라도 modification이면) 진단을 찍고 중단한다. 그래서 로그의 스택 트레이스 최상단이 항상 AccessSet::insert → swift_beginAccess 순서다.

핵심은 검사는 "삽입되는 접근"이 있어야 존재한다는 것이다. 최적화기가 접근을 지우면 검사도 함께 사라진다. 아래 실험에서 이 차이가 그대로 드러난다.

실험 · 도구

먼저 통과하는 버전. inout 인자 a를 함수 본문에서 한 번도 쓰지 않는다.

var arr = [1, 2, 3]
func mutate(_ a: inout [Int]) { arr.append(99) }   // a 를 쓰지 않는다
mutate(&arr)
print(arr)

[1, 2, 3, 99]
exit code = 0

이제 단 한 줄을 더한다. a를 실제로 사용해, 접근이 제거되지 않게 만든다.

var arr = [1, 2, 3]
func mutate(_ a: inout [Int]) {
    arr.append(99)          // 빌린 대상을 전역 경로로 또 건드린다
    print("inside, a =", a) // a 를 실제로 써서 접근이 지워지지 않게 한다
}
mutate(&arr)
print("after:", arr)

Simultaneous accesses to 0x1003d8018, but modification requires exclusive access.
Previous access (a modification) started at ex4_O`main + 56 (0x1003d0700).
Current access (a modification) started at:
0    libswiftCore.dylib   0x...  swift::runtime::AccessSet::insert(swift::runtime::Access*,
                                 void*, void*, swift::ExclusivityFlags) + 476
1    libswiftCore.dylib   0x...  swift_beginAccess + 84
2    ex4_O                0x...  mutate(_:) + 56
3    ex4_O                0x...  main + 64
4    dyld                 0x...  start + 6992

exit code = 134        # 128 + 6 (SIGABRT)

-Onone으로 빌드해도 같은 메시지와 같은 스택 모양이 나온다. 검사가 최적화 수준과 무관하게 살아 있다는 직접 증거다. 이 예제는 스레드를 하나도 만들지 않는다 — 배타적 접근이 동시성 문제가 아니라는 Q1의 주장을 그대로 증명한다.

프로젝트 적용

① 진단문을 읽는 법이 실무에서 가장 쓸모 있다. 로그의 세 줄이 각각 다른 정보를 준다.

② 앞의 두 버전을 비교하면 실무 규칙이 하나 나온다. "릴리스에서 안 죽으니 괜찮다"는 결론을 내리면 안 된다. 통과 여부가 최적화기의 판단에 달려 있으므로, 코드를 한 줄 고치거나 툴체인을 올리는 것만으로 조용했던 위반이 크래시로 바뀔 수 있다.

// ❌ 전역을 직접 빌려주고, 그 안에서 전역을 또 만진다
var cache: [String: Int] = [:]
func risky(_ c: inout [String: Int]) { cache["extra"] = 1; c["x"] = 2 }

// ✅ 지역으로 꺼내 작업하고, 마지막에 한 번만 되돌려 쓴다
func safe() {
    var local = cache      // 읽기 접근이 여기서 끝난다
    local["x"] = 2
    local["extra"] = 1
    cache = local          // 쓰기 접근이 여기서 시작하고 끝난다
}

③ -enforce-exclusivity를 끄는 선택은 사실상 없다. 성능 때문에 끄고 싶어지는 자리라면, 그 자리는 애초에 inout 대여를 반복하는 설계이거나 Q4의 withUnsafeTemporaryAllocation·30장의 Span으로 다시 써야 하는 자리다.

꼬리 질문

Q3. withUnsafeBufferPointer의 포인터를 클로저 밖으로 빼면 정확히 무엇이 깨지는가?

원리

withUnsafeBufferPointer(_:)의 계약은 "이 메서드는 배열의 연속 저장 공간에 대한 포인터를 클로저에 넘긴다. 이 포인터는 클로저 실행 범위를 벗어나면 유효하지 않다"는 것이다. 이 계약이 필요한 이유는 배열의 버퍼가 언제든 이동하거나 해제될 수 있기 때문이다. Part A 01장에서 본 CoW가 새 버퍼로 갈아타면 원래 주소는 남의 땅이 되고, 배열 자체의 수명이 끝나면 그 힙 블록은 해제되어 다른 할당에 재사용된다.

여기서 중요한 것은 UB는 "크래시한다"가 아니라 "어떤 일이 일어날지 언어가 아무 약속도 하지 않는다"라는 점이다. 운이 좋으면(=해제된 페이지가 아직 반환되지 않았고 내용이 남아 있으면) 원래 값이 그대로 읽힌다. 그래서 UB는 테스트를 통과한다.

내부 동작

왜 컴파일러가 막지 못하는가. UnsafePointer<T>는 그냥 정수 주소를 감싼 값 타입이고, 타입 시스템에 "이 주소가 누구의 수명에 묶여 있는지"를 표현할 자리가 없다. 그래서 클로저 밖의 변수에 대입하는 것이 문법적으로 완전히 합법이다. 컴파일러가 아는 것은 "UnsafePointer<Int> 값을 UnsafePointer<Int>? 변수에 넣는다"뿐이다.

실험 · 도구

var leaked: UnsafePointer<Int>? = nil
do {
    let a = [1, 2, 3]
    a.withUnsafeBufferPointer { buf in
        leaked = buf.baseAddress          // 클로저 밖으로 탈출 — 컴파일 통과
    }
}
// 원본 배열의 수명이 끝난 뒤 접근
print("탈출한 포인터로 읽기:", leaked!.pointee)   // 정의되지 않은 동작

컴파일 경고/에러: 없음
탈출한 포인터로 읽기: 1
exit code = 0

정답처럼 보이는 1이 나왔다. 이 값이 맞은 것은 순전히 해제된 메모리가 아직 덮어써지지 않았기 때문이며, 배열 크기·최적화 수준·주변 할당이 조금만 달라지면 쓰레기 값이나 크래시로 바뀐다. 같은 코드가 어떤 빌드에서는 통과하고 어떤 빌드에서는 실패하는 종류의 버그다.

그럼 무엇이 이걸 잡아주는가. 세 가지 도구가 각각 다른 층에서 잡는다.

프로젝트 적용

① 규칙은 단순하다. withUnsafe* 클로저 안에서 시작한 일은 그 안에서 끝낸다. 포인터를 내보내는 대신, 필요한 결과를 계산해서 내보낸다.

let a = [1, 2, 3]

// ❌ 포인터를 내보낸다
var p: UnsafePointer<Int>?
a.withUnsafeBufferPointer { p = $0.baseAddress }

// ✅ 값을 내보낸다 — 클로저는 값을 반환할 수 있다
let total = a.withUnsafeBufferPointer { buf -> Int in
    var t = 0
    for i in 0..<buf.count { t += buf[i] }
    return t
}
print(total)   // 6

② 반환값으로도 새어나갈 수 있다는 점을 놓치기 쉽다. 클로저가 포인터를 return하면 대입과 똑같이 탈출한다. 그래서 "포인터 타입을 반환하지 않는다"를 코드 리뷰 규칙으로 두는 편이 실전에서 잘 통한다.

// ❌ 반환 타입이 포인터면 그것도 탈출이다
func badBase(_ a: [Int]) -> UnsafePointer<Int> {
    a.withUnsafeBufferPointer { $0.baseAddress! }   // 반환되는 순간 무효
}

// ✅ C API에 넘겨야 한다면 호출까지 클로저 안에서 끝낸다
func callCAPI(_ a: [Int]) -> Int32 {
    a.withUnsafeBufferPointer { buf in
        c_process(buf.baseAddress, Int32(buf.count))   // 여기서 다 끝낸다
    }
}

③ C 라이브러리와 붙이는 코드가 이 함정의 주 무대다. C 함수가 포인터를 보관하는 API라면(콜백 등록, 비동기 처리) 클로저 안에서 호출하는 것만으로는 부족하다. 그때는 직접 힙에 할당해 수명을 명시적으로 관리해야 한다 — UnsafeMutablePointer.allocate(capacity:)와 deallocate() 쌍, 혹은 그 데이터를 소유하는 Data/Array를 C 호출이 끝날 때까지 살려두는 구조다.

꼬리 질문

Q4. withUnsafeTemporaryAllocation은 무슨 문제를 푸는가?

원리

표준 라이브러리의 실제 선언은 SDK에 동봉된 .swiftinterface에서 직접 확인할 수 있다. 내부 구현은 Builtin.RawPointer를 다루는 _withUnsafeTemporaryAllocation으로 내려가고, @_alwaysEmitIntoClient @_transparent가 붙어 있다.

@_alwaysEmitIntoClient @_transparent
internal func _withUnsafeTemporaryAllocation<T, R>(
    of type: T.Type, capacity: Swift.Int, alignment: Swift.Int,
    _ body: (Builtin.RawPointer) throws -> R
) rethrows -> R where T : ~Copyable, R : ~Copyable

@_transparent가 붙은 이유가 이 API의 핵심이다. 스택 할당은 호출한 함수의 프레임에 공간을 잡아야 하므로, 이 함수가 별도 프레임을 만드는 진짜 호출로 남아 있으면 성립하지 않는다. 그래서 항상 호출 지점으로 인라인되어 사라진다. T : ~Copyable과 R : ~Copyable은 Part A 13장의 noncopyable 타입도 이 버퍼에 담고 결과로 돌려줄 수 있다는 뜻이다.

내부 동작

"작으면 스택"의 판단 기준은 API 계약에 명시되지 않았다. 문서가 보장하는 것은 "충분히 작으면 스택에 할당될 수 있다"는 가능성이며, 크기 임계값이나 판단 규칙은 구현 세부사항이다. 따라서 "이 API를 쓰면 힙 할당이 없다"고 가정한 코드를 써서는 안 된다 — 성능이 중요하면 실제로 프로파일링해 확인해야 한다. 이것은 Part B 28장에서 본 NSCache.countLimit이 "엄격한 제한이 아니다"와 같은 종류의 계약이다.

버퍼가 초기화되지 않은 채 온다는 점도 중요하다. 넘어오는 것은 UnsafeMutableBufferPointer<T>이지만, 그 안의 메모리에는 아무 유효한 T 값도 없다. 그래서 buf[i] = x처럼 대입하면 안 되고(대입은 "기존 값을 해제하고 새 값을 쓴다"는 의미다) initializeElement(at:to:)로 처음 값을 심어야 한다. 참조 카운트가 있는 타입이라면 이 구분이 곧바로 메모리 오류로 이어진다.

실험 · 도구

let n = 4
withUnsafeTemporaryAllocation(of: Int.self, capacity: n) { buf in
    for i in 0..<n { buf.initializeElement(at: i, to: i * i) }
    print("temp buf:", Array(buf[0..<n]), "| baseAddress non-nil:", buf.baseAddress != nil)
    buf.deinitialize()
}

temp buf: [0, 1, 4, 9] | baseAddress non-nil: true

Int는 BitwiseCopyable이라 deinitialize()가 실질적으로 아무 일도 하지 않지만, 그래도 넣어두는 게 좋다. 나중에 원소 타입이 참조를 품은 타입으로 바뀌면 그 순간부터 deinitialize()가 반드시 필요해지는데, 처음부터 있으면 그 변경이 안전해진다.

프로젝트 적용

① 쓸 자리는 크기를 실행 시점에만 아는 짧은 작업 버퍼다. 대표적으로 인코딩 변환, 정렬용 임시 배열, C API가 요구하는 출력 버퍼다.

func readInto(count: Int) -> [UInt8] {
    withUnsafeTemporaryAllocation(of: UInt8.self, capacity: count) { buf in
        for i in 0..<count { buf.initializeElement(at: i, to: 0) }
        let written = c_fill(buf.baseAddress, Int32(count))   // 클로저 안에서 호출
        defer { buf.deinitialize() }
        return Array(buf[0..<Int(written)])                   // 값으로 복사해 내보낸다
    }
}

② 쓰지 말아야 할 자리가 더 중요하다. capacity를 사용자 입력이나 네트워크 응답에서 그대로 받으면 안 된다. 큰 값이 오면 스택을 넘겨 스택 오버플로로 죽을 수 있고, 이건 크래시 리포트에서 원인을 찾기 어렵다. 상한을 두고 그 위는 Array나 Data로 처리한다.

let maxTemp = 1024   // 프로젝트가 정한 상한

func process(count: Int) -> Int {
    if count <= maxTemp {
        return withUnsafeTemporaryAllocation(of: Int.self, capacity: count) { buf in
            for i in 0..<count { buf.initializeElement(at: i, to: i) }
            defer { buf.deinitialize() }
            return buf[0..<count].reduce(0, +)
        }
    } else {
        let heap = Array(0..<count)      // 큰 건 힙으로
        return heap.reduce(0, +)
    }
}

③ 대안과의 관계를 정리하면 선택이 쉬워진다. 안전한 코드를 먼저 쓰고, 프로파일링이 지목한 자리만 아래로 내려간다.

꼬리 질문

Q5. -strict-memory-safety(SE-0458)는 무엇을 강제하며 unsafe는 어떻게 쓰는가?

원리

Swift는 처음부터 "기본적으로 안전하되 필요하면 내려갈 수 있는" 언어를 지향했다. 문제는 내려간 지점이 표시되지 않는다는 것이었다. UnsafePointer라는 타입 이름에 unsafe가 들어 있어도, 그것을 쓰는 표현식은 평범해 보인다. Q3의 leaked = buf.baseAddress가 그 예다 — 이 한 줄만 보면 위험 신호가 없다.

SE-0458의 접근은 Swift 6 동시성 검사와 같은 모양이다. 옵트인 모드를 켜면 컴파일러가 위험 지점을 전부 지적하고, 개발자는 각 지점을 명시적으로 승인한다. 승인 표시가 곧 문서가 되고, 코드 리뷰의 단위가 된다.

내부 동작

진단 그룹 이름이 StrictMemorySafety다. 경고는 표현식 단위로 발생하며, 어떤 부분이 왜 unsafe한지 note로 지목한다. 실측 출력을 보면 컴파일러가 "이 인자의 타입이 unsafe하다"는 수준까지 짚어준다.

import Foundation
func f(_ p: UnsafePointer<Int>) -> Int { p.pointee }
let a = [1, 2, 3]
print(a.withUnsafeBufferPointer { f($0.baseAddress!) })

sms.swift:4:1: warning: expression uses unsafe constructs but is not marked
               with 'unsafe' [#StrictMemorySafety]
  note: argument #0 in call to instance method 'withUnsafeBufferPointer'
        has unsafe type '(UnsafeBufferPointer<Int>) -> Int'

sms.swift:4:35: warning: expression uses unsafe constructs but is not marked
                with 'unsafe' [#StrictMemorySafety]
  note: argument #0 in call to global function 'f'
        has unsafe type 'UnsafePointer<Int>'

경고가 두 개 나온 것에 주의한다. 한 줄 안에 unsafe한 지점이 두 곳(클로저 전달, f 호출)이라 각각 별도로 지적된다. 이제 각 지점에 unsafe를 붙인다.

func f(_ p: UnsafePointer<Int>) -> Int { unsafe p.pointee }
let a = [1, 2, 3]
let r = unsafe a.withUnsafeBufferPointer { unsafe f($0.baseAddress!) }
print("r =", r)

(컴파일 출력 없음)
r = 1

unsafe는 표현식 앞에 붙는 키워드다. try/await와 같은 자리에 오며, 실행 의미는 전혀 바꾸지 않는다. 반대 방향의 애트리뷰트도 있다 — 30장에서 볼 Span의 선언에 붙은 @safe가 그것으로, "포인터를 내부에 품고 있지만 이 타입의 공개 API는 안전하다"를 선언한다.

실험 · 도구

기존 코드베이스에 켤 때는 migrate 변형이 있다. swiftc -h에 두 형태가 함께 문서화돼 있다.

-strict-memory-safety:migrate
-strict-memory-safety   Enable strict memory safety checking
-enforce-exclusivity=<enforcement>
                        Enforce law of exclusivity

Q3의 탈출 예제에 이 플래그를 걸어보면, 아무 신호도 주지 않았던 그 코드가 컴파일 타임에 지적된다. Q3 표에서 "잡는다"로 표시한 근거가 이것이다.

프로젝트 적용

① 도입 전략은 Swift 6 동시성 마이그레이션과 같다. 전체를 한 번에 켜지 말고, 모듈 단위로 켠다. Foundation·C 래핑이 몰려 있는 하위 모듈은 뒤로 미루고, 순수 로직 모듈부터 켜면 경고 수가 감당 가능하다.

.target(
    name: "AppLogic",                        // 순수 로직 — 먼저 켠다
    swiftSettings: [.unsafeFlags(["-strict-memory-safety"])]
),
.target(
    name: "CBridge",                         // C 래핑 — 나중에
    dependencies: []
)

② unsafe를 붙이는 것은 "이 코드가 안전하다"는 선언이 아니라 "내가 이 지점의 계약을 확인했다"는 서명이다. 그래서 붙일 때 계약을 주석으로 남기는 규율이 실전에서 값을 만든다. 무엇이 그 포인터의 수명을 보장하는지가 리뷰의 대상이 되어야 한다.

// 수명 근거: buf 는 withUnsafeBufferPointer 클로저 안에서만 쓰이고,
//            c_process 는 포인터를 보관하지 않는다(문서 확인: 동기 API).
let n = unsafe a.withUnsafeBufferPointer { buf in
    unsafe c_process(buf.baseAddress, Int32(buf.count))
}

③ 가장 큰 실무 효과는 검색 가능성이다. unsafe가 붙은 지점을 세는 것만으로 코드베이스의 위험 표면을 정량화할 수 있고, 30장의 Span·InlineArray로 옮길 우선순위를 그 수치로 정할 수 있다. Part C의 다음 챕터가 정확히 그 이야기다.

grep -rn '\bunsafe\b' Sources/ --include='*.swift' | wc -l
grep -rn 'Unsafe[A-Za-z]*Pointer' Sources/ --include='*.swift' | cut -d: -f1 | sort | uniq -c | sort -rn

꼬리 질문

출처 · 참고자료