35 · 동시성 안전성 심화

P0 02·09장에서 액터와 Sendable을, 10장에서 락과 우선순위 역전을 다뤘다. 거기까지가 "동시성의 도구를 아는" 단계였다.

이 챕터는 그다음이다. 컴파일러가 어떻게 안전을 증명하는가, 그 증명이 어디서 실패하고 왜 실패하는가, 그리고 언어가 어느 방향으로 움직이고 있는가.

이 장의 주장은 대부분 실제 컴파일과 실행으로 확인했다(Swift 6.2.1, arm64-apple-macos). 진단 메시지와 수치는 재현한 결과 그대로다.

Q1. 컴파일러는 "이 값은 넘겨도 안전하다"를 어떻게 아는가?

CS 원리

문제는 이렇게 요약된다. "이 값을 다른 실행 도메인에 넘겨도 되는가?"

가장 단순한 답은 타입으로 판정하는 것이다 — Sendable이면 되고 아니면 안 된다. 이 방식은 건전(sound)하지만 지나치게 보수적이다. 방금 만들어서 아무도 안 보고 있는 객체까지 막기 때문이다.

Region-Based Isolation은 타입 대신 흐름을 본다. 이것은 컴파일러 이론의 포인터 별칭 분석(alias analysis)과 선형 타입(linear types) 계열 아이디어다.

핵심 개념이 둘이다.

• Region — 서로 참조로 도달 가능한 값들의 묶음. let a = Box(); let b = [a]이면 a와 b는 같은 region이다.
• Disconnected — 어떤 액터에도, 어떤 태스크에도 아직 묶이지 않은 region. 이 상태의 region만 넘길 수 있다.

넘기는 순간 그 region은 consumed로 표시된다. 이후 원래 쪽에서 그 region의 어떤 값이든 접근하면 에러다 — 넘긴 변수 자체가 아니어도 잡힌다.

이 분석이 왜 SIL 단계에서 도는가가 실무적으로 중요하다. 타입 검사는 선언만 보지만, region 분석은 제어 흐름과 값의 이동을 봐야 한다. 그 정보는 SIL로 낮춘 뒤에야 있다. 33장 Q1에서 SIL을 읽어 struct_extract와 apply를 구분했던 것과 같은 층위다.

결과는 개발 경험에 직접 영향을 준다. 에디터의 실시간 진단(타입 체크 기반)에는 안 보이다가 빌드해야 나타나는 에러가 존재한다.

iOS에서는

가장 흔한 이득은 "만들어서 넘기는" 패턴이 그냥 통과한다는 것이다.

final class ImageBuffer { var pixels: [UInt8] = [] }   // Sendable 아님

actor Cache {
    var stored: [ImageBuffer] = []
    func store(_ b: ImageBuffer) { stored.append(b) }
}

func load(_ cache: Cache) async {
    let buf = ImageBuffer()      // 여기서 만들고
    buf.pixels = decode()        // 여기서만 채우고
    await cache.store(buf)       // 넘긴다 — 이후 안 쓴다
}
//   Sendable 이 아닌데도 통과한다. region 이 disconnected 이기 때문이다.

실패하는 형태는 넘긴 뒤에 계속 쓰는 코드다.

func loadBad(_ cache: Cache) async -> Int {
    let buf = ImageBuffer()
    await cache.store(buf)
    return buf.pixels.count      // ❌ 넘긴 뒤 접근
}
// error: sending 'buf' risks causing data races
//   note: sending 'buf' to actor-isolated instance method 'store' risks causing
//         data races between actor-isolated and local nonisolated uses
//   note: access can happen concurrently

별칭도 같은 region으로 추적된다는 것이 중요하다. "변수 이름만 다르면 되겠지"는 통하지 않는다.

let buf = ImageBuffer()
let sameThing = buf              // 이름만 다르지 같은 객체 = 같은 region
await cache.store(buf)
sameThing.pixels = []            // ❌ 역시 잡힌다

고치는 방향은 셋이다. (1) 넘긴 뒤 안 쓰도록 순서를 바꾼다. (2) 필요한 값을 넘기기 전에 꺼내 둔다. (3) 타입을 진짜 Sendable로 만든다.

// (2) 넘기기 전에 꺼낸다 — 가장 간단한 해법인 경우가 많다
let count = buf.pixels.count
await cache.store(buf)
return count

실험 · 도구

타입 체크와 실제 빌드가 다르다는 것을 직접 확인해 보자. 이것을 모르면 CI에서만 깨지는 이유를 못 찾는다.

// region.swift
final class Box { var v = 0 }
actor Store { var boxes: [Box] = []; func take(_ b: Box) { boxes.append(b) } }

func caseB(_ s: Store) async {
    let b = Box()
    await s.take(b)
    b.v = 99                     // 넘긴 뒤 사용
}

$ swiftc -swift-version 6 -typecheck region.swift ; echo "EXIT=$?"
EXIT=0                          # 통과한다

$ swiftc -swift-version 6 -c region.swift -o /dev/null
region.swift:6:13: error: sending 'b' risks causing data races
  |- error: sending 'b' risks causing data races [#SendingRisksDataRace]
  `- note: sending 'b' to actor-isolated instance method 'take' risks causing
           data races between actor-isolated and local nonisolated uses
       b.v = 99
           `- note: access can happen concurrently

진단 코드 [#SendingRisksDataRace]가 붙어 있어 문서로 바로 갈 수 있다. Swift 6는 진단마다 이런 식별자를 준다.

# 프로젝트에서 이 계열 에러만 뽑아 본다
xcodebuild build 2>&1 | grep -E "SendingRisksDataRace|risks causing data races"

# 어떤 진단이 활성인지 확인 — 언어 모드와 업커밍 기능
swiftc -swift-version 6 -Xfrontend -debug-diagnostic-names -typecheck file.swift 2>&1 | head

프로젝트 적용

1. "만들고 → 채우고 → 넘긴다" 순서로 쓴다. region 분석이 가장 잘 통과하는 형태다.
2. 넘긴 뒤 필요한 값은 미리 꺼낸다. Sendable을 억지로 붙이는 것보다 안전하다.
3. 에디터 진단만 믿지 않는다. 이 계열 에러는 실제 빌드에서만 나온다.
4. @unchecked Sendable로 도망가지 않는다. P0 17장에서 본 대로 그것은 검사를 끄는 것이지 안전을 만드는 것이 아니다.
5. 별칭을 만들어 우회하려 하지 않는다. 같은 region으로 추적되므로 통하지 않고, 통했다면 그건 진짜 경쟁이다.

꼬리 질문

func handoff(_ b: sending Box, to s: Store) async { await s.take(b) }

let b = Box()
Task { b.v = 1 }                 // 클로저가 b 를 캡처 → b 의 region 이 이 태스크에 묶인다
b.v = 2                          // ❌ 바깥에서 또 쓴다

@MainActor func f() {
    let b = Box()
    Task { b.v = 1 }             // MainActor 를 물려받는다 — 같은 도메인
    Task.detached { b.v = 2 }    // 물려받지 않는다 — 경계를 넘는다
}

Q2. sending은 무엇을 약속하는가?

CS 원리

정적 분석에는 범위의 벽이 있다. Q1의 region 분석은 함수 하나의 본문을 본다. 그런데 함수는 인자가 어디서 왔는지 모르고, 호출자는 함수가 인자로 뭘 할지 모른다.

해결책은 시그니처를 계약으로 쓰는 것이다. 이것이 모듈러 검증(modular verification)의 표준 기법이다 — 각자 자기 몫만 검사하고, 경계에서는 선언된 계약을 믿는다.

sending이 만드는 계약은 양방향이다.

이 구조는 33장 Q1의 Library Evolution과 같은 발상이다 — 경계에 무엇을 적어 두느냐로 양쪽이 독립적으로 컴파일된다.

기본값은 보수적인 쪽이다. sending을 안 붙이면 "호출자가 계속 쓸 수 있다"고 가정하므로 넘기지 못한다. 이것이 건전성 우선 설계다.

SE-0461(Swift 6.2)은 다른 각도의 해법이다. nonisolated async 함수가 기본적으로 호출자의 실행자에서 돌게 바꾸면(nonisolated(nonsending)), 애초에 격리 경계를 넘지 않으므로 전달 검사가 필요 없어진다. 확인해 보면 같은 코드가 이 기능을 켜는 것만으로 에러에서 통과로 바뀐다.

iOS에서는

확인한 대비가 그대로 실무 규칙이 된다.

final class Box { var v = 0 }
actor Store { var boxes: [Box] = []; func take(_ b: Box) { boxes.append(b) } }

// ❌ 같은 본문인데 에러가 난다
func plain(_ b: Box, to s: Store) async { await s.take(b) }
// error: sending 'b' risks causing data races
//   note: sending task-isolated 'b' to actor-isolated instance method 'take'
//         risks causing data races between actor-isolated and task-isolated uses

// ✅ sending 을 붙이면 통과
func withSending(_ b: sending Box, to s: Store) async { await s.take(b) }

반환값에도 쓴다. 팩토리 함수가 대표적이다.

// "만들어 주지만 나는 안 갖고 있는다" — 호출자가 어디로든 보낼 수 있다
func makeBuffer() -> sending ImageBuffer {
    ImageBuffer()
}

let b = makeBuffer()
await cache.store(b)             // 통과한다

sending을 붙이면 함수 안에서의 제약도 생긴다. 인자를 전역이나 프로퍼티에 저장해 두면 약속을 어기는 것이라 막힌다.

var kept: Box?
func bad(_ b: sending Box) {
    kept = b                     // 밖으로 새어 나간다 — 계약 위반
}

SE-0461은 프로젝트 단위 스위치다. 켜면 nonisolated async 함수의 의미가 바뀐다.

@MainActor func caller() async {
    let b = makeOnMain()
    await work(b)                // work 는 nonisolated async
    print(b.v)
}
//   기본(6.2):  error: sending 'b' risks causing data races
//   -enable-upcoming-feature NonisolatedNonsendingByDefault → 통과

실험 · 도구

두 시그니처의 차이를 한 파일에서 재현한다.

// sending.swift
final class Box { var v = 0 }
actor Store { var boxes: [Box] = []; func take(_ b: Box) { boxes.append(b) } }

func plain(_ b: Box, to s: Store) async { await s.take(b) }
func withSending(_ b: sending Box, to s: Store) async { await s.take(b) }

$ swiftc -swift-version 6 -c sending.swift -o /dev/null
sending.swift:5:51: error: sending 'b' risks causing data races
  `- note: sending task-isolated 'b' to actor-isolated instance method 'take'
           risks causing data races between actor-isolated and task-isolated uses
#  6번 줄(withSending)에 대한 에러는 없다 — 통과했다는 뜻이다

SE-0461 스위치의 효과를 확인한다.

# 끈 상태 — 에러
$ swiftc -swift-version 6 -c iso.swift -o /dev/null
iso.swift:10:11: error: sending 'b' risks causing data races

# 켠 상태 — 조용하다
$ swiftc -swift-version 6 \
    -enable-upcoming-feature NonisolatedNonsendingByDefault \
    -c iso.swift -o /dev/null
$ echo $?
0

# 프로젝트에서 sending 사용 현황
grep -rn ": sending \|-> sending " --include=*.swift . | wc -l

# 아직 @unchecked Sendable 로 우회 중인 곳 — sending 으로 옮길 후보
grep -rn "@unchecked Sendable" --include=*.swift .

프로젝트 적용

1. "넘겨받아 어딘가로 보내는" 함수에 sending을 붙인다. 큐잉·캐시 저장·태스크 시작이 전형이다.
2. 팩토리 반환에 sending을 쓴다. 호출자가 자유롭게 쓸 수 있게 된다.
3. @unchecked Sendable을 sending으로 대체할 수 있는지 먼저 본다. 검사를 끄는 대신 계약을 적는 쪽이다.
4. SE-0461은 모듈 단위로 켠다. 의미가 바뀌므로 한 모듈씩 적용하고 회귀를 확인한다.
5. 진단의 note를 끝까지 읽는다. task-isolated인지 local nonisolated인지에 따라 고치는 방법이 다르다.

꼬리 질문

actor Keeper { var kept: Box? }

extension Keeper {
    // ✅ 액터 안에 저장하는 것은 괜찮다 — 격리 도메인 안이다
    func keep(_ b: sending Box) { kept = b }
}

// ❌ 격리 없는 전역에 저장하면 어디서든 접근 가능해진다
nonisolated(unsafe) var leaked: Box?
func bad(_ b: sending Box) { leaked = b }

// caseB — 함수 안에서 만든 값
// note: sending 'b' … between actor-isolated and local nonisolated uses
//   → 순서를 바꾸면 해결된다

// plain — 인자로 받은 값
// note: sending task-isolated 'b' … between actor-isolated and task-isolated uses
//   → sending 을 붙여야 해결된다

// 무거운 작업은 명시적으로 밖으로 보낸다
nonisolated func heavy() async -> Data {
    await Task.detached(priority: .utility) { expensiveWork() }.value
}
//   또는 전용 액터/실행자에 격리시킨다

Q3. 격리를 값으로 다루면 무엇이 가능해지는가?

CS 원리

여기서 다루는 것은 일급 값(first-class value)이라는 개념이다. 어떤 것이 변수에 담기고, 인자로 넘어가고, 검사될 수 있으면 일급이다.

동시성에서 격리(isolation)는 오랫동안 타입 시스템에만 존재했다. @MainActor는 컴파일러가 검사하는 표시였고, 실행 중에 물어볼 수는 없었다.

문제는 스케줄링을 직접 구현할 때 드러난다. 작업을 받아 나중에 실행하는 코드는 이런 딜레마에 빠진다.

• 작업이 어느 액터에 속하는지 모르면, 일단 아무 데서나 시작한 뒤 await로 넘어가야 한다 → 불필요한 전환 한 번.
• 더 나쁘게는 순서 보장이 깨진다 — 같은 액터로 갈 작업 둘이 중간에서 뒤바뀔 수 있다.

@isolated(any)는 격리를 값으로 승격해 이 문제를 푼다. 스케줄러가 .isolation을 읽어 처음부터 올바른 실행자에서 시작할 수 있다.

이것은 33장 Q5의 package와 비슷한 성격의 변화다 — 컴파일러만 알던 정보를 프로그램이 쓸 수 있게 만든 것이다. 다만 결과는 훨씬 크다. Task.init·TaskGroup.addTask가 이 기능 위에 재구현되어, 표준 라이브러리 자체가 전환을 줄인다.

글로벌 액터도 같은 맥락이다. @globalActor는 프로그램 전체에서 유일한 액터 인스턴스를 만드는 장치이고, @MainActor는 그중 하나일 뿐이다. 직접 만들면 메인이 아닌 전용 도메인을 가질 수 있다.

iOS에서는

직접 만드는 전용 글로벌 액터부터 보자. 메인이 아닌 단일 도메인이 필요할 때 쓴다.

@globalActor
actor DatabaseActor {
    static let shared = DatabaseActor()
}

@DatabaseActor
final class LocalStore {                  // 이 타입 전체가 DatabaseActor 격리
    private var cache: [String: Data] = []
    func read(_ k: String) -> Data? { cache[k] }
    func write(_ k: String, _ v: Data) { cache[k] = v }
}
//   DB 접근이 한 도메인에서 직렬화된다 — 락 없이도 순서가 보장된다(P0 10장 대비)

@isolated(any)는 스케줄러·큐를 직접 만들 때 쓴다.

func schedule(_ op: @isolated(any) @Sendable () async -> Void) async {
    print("이 작업의 격리 대상:", op.isolation as Any)
    await op()                            // 올바른 실행자에서 바로 시작된다
}

await schedule { }                        // isolation = nil
await schedule { @MainActor in }          // isolation = Optional(Swift.MainActor)
await schedule { @DatabaseActor in }      // isolation = Optional(DatabaseActor)

실무에서 더 자주 쓰는 것은 isolated 파라미터다. 함수를 호출자의 액터에 격리시킨다.

// 어느 액터에서 불리든 그 액터 안에서 실행된다 — await 가 필요 없다
func inspect(_ store: isolated LocalStore) {
    print(store.read("key") as Any)       // await 없이 접근 가능
}

주의할 것이 있다. @Sendable 클로저는 주변 액터 격리를 물려받지 않는다. 액터 메서드 안에서 @Sendable 클로저를 만들어 self의 격리 상태를 쓰려 하면 막힌다.

actor Worker {
    func ping() { }
    func run(_ f: @isolated(any) @Sendable () async -> Void) async { await f() }

    func broken() async {
        await run { self.ping() }
        // error: actor-isolated instance method 'ping()' cannot be called
        //        from outside of the actor
    }
}
//   @Sendable 클로저는 격리 밖이다 — 명시적으로 @DataActor in 같은 표시를 하거나
//   isolated 파라미터를 쓴다

실험 · 도구

격리 값이 실제로 어떻게 찍히는지 직접 확인한다.

// iso.swift
@globalActor actor DataActor { static let shared = DataActor() }

func schedule(_ op: @isolated(any) @Sendable () async -> Void) async {
    print("  isolation =", op.isolation as Any)
    await op()
}

@main struct M {
    static func main() async {
        print("1) 격리 없는 클로저");  await schedule { }
        print("2) @MainActor 클로저"); await schedule { @MainActor in }
        print("3) @DataActor 클로저"); await schedule { @DataActor in }
    }
}

$ swiftc -swift-version 6 -parse-as-library iso.swift -o iso && ./iso
1) 격리 없는 클로저
  isolation = nil
2) @MainActor 클로저
  isolation = Optional(Swift.MainActor)
3) @DataActor 클로저
  isolation = Optional(iso.DataActor)

3번이 iso.DataActor로 모듈명이 붙어 찍히는 것에 주목하자 — 33장 Q1에서 본 맹글링된 이름이 그대로 드러난다.

# 프로젝트의 글로벌 액터 목록
grep -rn "@globalActor" --include=*.swift .

# MainActor 남용 점검 — 배경에서 돌아도 되는데 메인에 묶은 곳
grep -rn "@MainActor" --include=*.swift . | grep -iE "repository|store|service|manager"

# isolated 파라미터 사용처
grep -rn ": isolated \|isolated(any)" --include=*.swift .

프로젝트 적용

1. 메인이 아닌 직렬 도메인이 필요하면 글로벌 액터를 만든다. DB·파일·로그가 대표적이다.
2. 모든 것을 @MainActor로 밀지 않는다. 편하지만 메인 스레드 점유가 늘어난다(P1 25장).
3. @isolated(any)는 스케줄러를 직접 만들 때만 쓴다. 앱 코드에서 직접 쓸 일은 드물다.
4. 호출자 액터에서 실행하고 싶으면 isolated 파라미터를 쓴다. await가 사라져 코드가 단순해진다.
5. @Sendable 클로저가 격리를 안 물려받는다는 것을 기억한다. 액터 안에서 만든 클로저라도 밖이다.

꼬리 질문

// 글로벌 액터 — 파일 시스템 접근을 앱 전체에서 직렬화
@globalActor actor FileActor { static let shared = FileActor() }

// 액터 인스턴스 — 문서마다 독립적으로 직렬화
actor Document { private var text = "" }
let a = Document(), b = Document()      // 서로 간섭하지 않는다

actor Ledger {
    var entries: [Entry] = []
    var balance: Int = 0
}

// ❌ 밖으로 빼면 await 마다 틈이 생긴다
func auditBad(_ l: Ledger) async {
    let e = await l.entries          // ← 여기서 중단
    let b = await l.balance          // ← 그 사이 값이 바뀔 수 있다
    check(e, b)                      // 일관되지 않은 조합일 수 있다
}

// ✅ isolated 파라미터 — 액터 안에서 통째로 실행된다
func audit(_ l: isolated Ledger) {
    check(l.entries, l.balance)      // 중단 지점이 없다 = 원자적으로 본다
}

func helper(isolation: isolated (any Actor)? = #isolation) async { … }

final class QueueExecutor: SerialExecutor {
    let queue = DispatchQueue(label: "db")
    func enqueue(_ job: consuming ExecutorJob) {
        let j = UnownedJob(job)
        queue.async { j.runSynchronously(on: self.asUnownedSerialExecutor()) }
    }
    func asUnownedSerialExecutor() -> UnownedSerialExecutor {
        UnownedSerialExecutor(ordinary: self)
    }
}

actor DBActor {
    private let exec = QueueExecutor()
    nonisolated var unownedExecutor: UnownedSerialExecutor { exec.asUnownedSerialExecutor() }
}

Q4. AsyncStream에서 요소는 어디로 사라지는가?

CS 원리

AsyncSequence는 비동기 반복자 프로토콜이다. 동기 Sequence가 next() -> Element?를 주듯, AsyncIteratorProtocol은 next() async throws -> Element?를 준다.

여기서 생산자와 소비자의 속도 차라는 고전적 문제가 등장한다. 생산자가 빠르면 어딘가에 쌓여야 하고, 쌓을 곳은 유한하다. 선택지는 셋뿐이다.

AsyncStream은 앞의 두 가지만 제공한다. yield가 async가 아니어서 생산자를 멈출 수단이 없기 때문이다 — 이것이 설계상의 한계이지 버그가 아니다.

그리고 기본값이 .unbounded라는 것이 중요하다. 아무 생각 없이 쓰면 무제한 버퍼가 된다. P1 19장 Q5의 메모리 증가 진단에서 이런 스트림이 원인인 경우가 있다.

소비자 쪽 성질은 더 자주 오해된다. AsyncStream은 단일 소비자(unicast) 설계다. 요소는 먼저 next()를 부른 쪽이 가져간다 — Combine의 Publisher가 브로드캐스트(multicast)인 것과 정반대다.

이 차이를 모르면 "화면 두 곳에서 같은 스트림을 구독"했다가 각자 절반씩만 받는 버그를 만든다. 그리고 비율이 매번 달라서 재현이 어렵다.

iOS에서는

버퍼 정책은 데이터의 성격으로 정한다.

// 센서 값 — 최신만 의미 있다. 밀린 값은 버린다.
let sensor = AsyncStream<Reading>(bufferingPolicy: .bufferingNewest(1)) { c in
    manager.onUpdate = { c.yield($0) }
}

// 사용자 이벤트 — 하나도 놓치면 안 된다. 대신 상한을 둔다.
let taps = AsyncStream<Tap>(bufferingPolicy: .bufferingOldest(256)) { c in … }

// ⚠️ 기본값은 .unbounded — 명시하지 않으면 무제한으로 쌓인다
let risky = AsyncStream<Log> { c in … }

여러 곳에서 봐야 하면 스트림을 나눠 만든다. 하나를 공유하면 나뉘어 버린다.

// ❌ 하나를 둘이 본다 — 각자 절반씩만 받는다
for await v in shared { updateChart(v) }        // 화면 A
for await v in shared { updateList(v) }         // 화면 B

// ✅ 소비자마다 별도 스트림을 만들어 준다
actor Broadcaster {
    private var conts: [UUID: AsyncStream<Value>.Continuation] = [:]

    func subscribe() -> AsyncStream<Value> {
        let id = UUID()
        return AsyncStream(bufferingPolicy: .bufferingNewest(64)) { c in
            conts[id] = c
            c.onTermination = { _ in Task { await self.remove(id) } }
        }
    }
    func send(_ v: Value) { for c in conts.values { c.yield(v) } }
    private func remove(_ id: UUID) { conts[id] = nil }
}

onTermination을 반드시 설정한다. 소비자가 사라졌는데 생산자가 계속 밀어 넣으면 자원이 새어 나간다.

let s = AsyncStream<Data> { c in
    let token = start()
    c.onTermination = { reason in
        stop(token)                  // .cancelled / .finished 둘 다 여기로 온다
    }
}

취소 전파도 확인해야 한다. for await를 도는 Task가 취소되면 순회가 끝나고 onTermination이 .cancelled로 불린다.

실험 · 도구

버퍼 정책별 유실을 직접 센다.

func drain(_ policy: AsyncStream<Int>.Continuation.BufferingPolicy, _ name: String) async {
    let s = AsyncStream<Int>(bufferingPolicy: policy) { c in
        for i in 1...1000 { c.yield(i) }      // 소비 전에 한꺼번에 밀어넣는다
        c.finish()
    }
    var got = 0, first = 0, last = 0
    for await v in s { if got == 0 { first = v }; last = v; got += 1 }
    print("\(name): 1000개 중 \(got)개 도착 (첫 \(first), 끝 \(last))")
}

$ ./buffer
.unbounded          : 1000개 중 1000개 도착 (첫 1, 끝 1000)
.bufferingNewest(1) : 1000개 중 1개 도착 (첫 1000, 끝 1000)
.bufferingOldest(1) : 1000개 중 1개 도착 (첫 1, 끝 1)
.bufferingNewest(10): 1000개 중 10개 도착 (첫 991, 끝 1000)

소비자 분배도 세어 본다. 세 번 돌려 보는 것이 중요하다 — 한 번만 보면 우연으로 착각한다.

let (s, c) = AsyncStream<Int>.makeStream()
Task.detached { for i in 1...100 { c.yield(i) }; c.finish() }
async let a: Int = { var n = 0; for await _ in s { n += 1 }; return n }()
async let b: Int = { var n = 0; for await _ in s { n += 1 }; return n }()
let (x, y) = await (a, b)
print("소비자A \(x)개, 소비자B \(y)개, 합계 \(x+y)")

$ ./split; ./split; ./split
소비자A 52개, 소비자B 48개, 합계 100  (보낸 건 100개)
소비자A 58개, 소비자B 42개, 합계 100  (보낸 건 100개)
소비자A 51개, 소비자B 49개, 합계 100  (보낸 건 100개)

# 버퍼 정책을 지정하지 않은 스트림 — 전부 무제한이다
grep -rn "AsyncStream" --include=*.swift . | grep -v "bufferingPolicy"

# onTermination 없는 스트림 — 자원 누수 후보
grep -rn -A5 "AsyncStream" --include=*.swift . | grep -c "onTermination"

프로젝트 적용

1. 버퍼 정책을 항상 명시한다. 기본값 .unbounded는 선택이 아니라 방치다.
2. 최신만 의미 있으면 .bufferingNewest(1), 하나도 놓치면 안 되면 상한 있는 .bufferingOldest(N)를 쓴다.
3. 여러 소비자가 필요하면 소비자마다 스트림을 만든다. 하나를 공유하면 나뉜다.
4. onTermination을 반드시 설정한다. 생산 자원 정리가 여기 있다.
5. 메모리가 계속 느는 화면에서 스트림을 의심한다. P1 19장 Q5의 phys_footprint 증가 진단과 함께 본다.

꼬리 질문

actor BoundedQueue<T: Sendable> {
    private var items: [T] = []
    private var waiters: [CheckedContinuation<Void, Never>] = []
    private let limit: Int

    init(limit: Int) { self.limit = limit }

    func push(_ v: T) async {
        while items.count >= limit {           // 가득 차면 생산자가 기다린다
            await withCheckedContinuation { waiters.append($0) }
        }
        items.append(v)
    }
    func pop() -> T? {
        guard !items.isEmpty else { return nil }
        let v = items.removeFirst()
        if let w = waiters.popLast() { w.resume() }   // 자리가 나면 깨운다
        return v
    }
}

struct Ticker: AsyncSequence {
    typealias Element = Int
    let count: Int

    struct Iterator: AsyncIteratorProtocol {
        var remaining: Int
        mutating func next() async throws -> Int? {
            guard remaining > 0 else { return nil }
            try Task.checkCancellation()          // ← 취소를 확인한다
            try await Task.sleep(for: .milliseconds(100))
            remaining -= 1
            return remaining
        }
    }
    func makeAsyncIterator() -> Iterator { Iterator(remaining: count) }
}

// 던지지 않음이 타입에 드러난다 — for await 에 try 가 필요 없다
extension Ticker: AsyncSequence where Element: Sendable {
    typealias Failure = Never
}

// 오류가 나도 계속 받고 싶으면 Result 로 감싼다
let safe = AsyncStream<Result<Value, Error>> { c in … }

for await v in publisher.values { … }     // Combine → async 다리

Q5. 프로퍼티가 async·throws가 되면 무엇을 잃는가?

CS 원리

프로그래밍 언어에는 "이건 값이다"라는 암묵적 계약이 있다. 프로퍼티를 읽는 것은 싸고, 실패하지 않고, 여러 번 읽어도 같고, 순서에 무관하다고 가정된다.

async·throws를 붙이는 순간 그 계약이 깨진다.

이것이 추상화의 누수(leaky abstraction)의 교과서적 사례다. 문법적으로는 여전히 obj.value지만, 의미론적으로는 함수 호출이다.

왜 key path가 불가능한가? KeyPath는 "값에 이르는 순수한 경로"라는 전제 위에 서 있다. 32장 Q3에서 본 대로 KeyPath는 합성 가능하고 저장 가능해야 하는데, async throws인 접근을 경로로 표현할 수단이 없다 — 그 경로를 "따라가는" 것 자체가 중단·실패할 수 있는 연산이기 때문이다.

프로토콜 준수도 같은 이유다. var v: Int { get }은 "동기적으로 읽힌다"는 계약이고, get async는 그것을 제공하지 못한다. 반대 방향(동기 구현이 async 요구사항 충족)은 가능하다 — 더 강한 보장이 약한 요구를 만족시키기 때문이다.

이 비대칭이 부분 순서(subtyping)의 전형이다. 33장 Q6의 static let vs lazy var에서 본 것처럼, 보장이 강한 쪽이 약한 쪽 자리에 들어갈 수 있다.

iOS에서는

가장 흔한 형태는 액터의 프로퍼티다. 이건 자동으로 effectful이다.

actor Session {
    var token: String = ""
}

let s = Session()
let t = await s.token           // 액터 프로퍼티 읽기는 이미 async 다
// let kp = \Session.token      // ❌ key path 를 만들 수 없다

직접 선언하는 경우는 비싼 계산이나 I/O를 프로퍼티로 감쌀 때다.

struct RemoteConfig {
    var flags: [String: Bool] {
        get async throws {
            let (d, _) = try await URLSession.shared.data(from: url)
            return try JSONDecoder().decode([String: Bool].self, from: d)
        }
    }
}

let cfg = try await config.flags     // 프로퍼티처럼 보이지만 네트워크가 돈다

이 설계를 권장하지 않는 이유가 여기 드러난다. 읽는 쪽이 비용을 못 본다. 반복문 안에 들어가면 매번 네트워크다.

for key in keys {
    if try await config.flags[key] == true { … }   // ⚠️ 매 반복마다 요청
}

메서드로 만드는 편이 정직하다. 괄호가 "이건 연산이다"를 알려 준다.

func fetchFlags() async throws -> [String: Bool] { … }   // ✅ 비용이 보인다

실제로 Apple 자신도 이 기준을 따른다. Data의 count는 프로퍼티지만 네트워크 조회는 data(from:) 메서드다.

@Observable과의 관계도 확인해야 한다. 34장 Q6의 접근 추적은 동기 읽기를 가로채므로, get async 프로퍼티는 추적 대상이 되지 않는다. 화면 갱신을 기대하면 안 된다.

실험 · 도구

두 제약을 한 파일로 확인한다.

// effectful.swift
protocol Sync { var v: Int { get } }

struct A {
    var v: Int { get async { 1 } }
}
let kp = \A.v                    // key path 를 만들어 본다
extension A: Sync {}             // 동기 요구사항을 만족시켜 본다

$ swiftc -swift-version 6 -c effectful.swift -o /dev/null
effectful.swift:6:13: error: cannot form key path to property with 'throws' or 'async'
effectful.swift:7:1: error: type 'A' does not conform to protocol 'Sync'

반대 방향(동기 구현이 async 요구를 만족)은 통과한다.

protocol Loose { var v: Int { get async throws } }
struct B { var v: Int { 1 } }    // 그냥 동기 프로퍼티
extension B: Loose {}            // ✅ 통과 — 더 강한 보장이므로

# effectful 프로퍼티 선언 찾기 — 메서드로 바꿀 후보
grep -rnE "\{ *get (async|throws|async throws)" --include=*.swift .

# @Observable 타입 안의 async 프로퍼티 — 추적되지 않으므로 위험
grep -rn -A15 "@Observable" --include=*.swift . | grep "get async"

프로젝트 적용

1. I/O나 비싼 계산은 메서드로 만든다. 괄호가 비용을 알리는 신호다.
2. effectful 프로퍼티는 액터 상태 노출에 한정한다. 그건 언어가 강제하는 것이라 선택의 여지가 없다.
3. KeyPath 기반 설계와 섞지 않는다. 32장 Q3의 패턴들이 전부 막힌다.
4. @Observable 타입에 get async를 넣지 않는다. 추적되지 않아 화면이 안 갱신된다.
5. 반복문 안의 effectful 접근을 의심한다. 프로퍼티처럼 보여서 리뷰에서 놓치기 쉽다.

꼬리 질문

actor DataStore {
    private var items: [Item] = []
    func load() async -> [Item] { items }
}

@MainActor @Observable
final class ItemsViewModel {
    private(set) var items: [Item] = []     // 화면이 읽는 것은 이쪽
    private let store: DataStore

    init(store: DataStore) { self.store = store }

    func refresh() async {
        items = await store.load()          // 액터에서 가져와 메인에 반영
    }
}

actor ConfigCache {
    private var cached: [String: Bool]?
    private var inFlight: Task<[String: Bool], Error>?

    var flags: [String: Bool] {
        get async throws {
            if let c = cached { return c }
            if let t = inFlight { return try await t.value }   // ← 중복 요청 방지
            let t = Task { try await fetch() }
            inFlight = t
            defer { inFlight = nil }
            let v = try await t.value
            cached = v
            return v
        }
    }
}

// ⚠️ 읽을 때마다 실패할 수 있는 프로퍼티
struct Doc {
    var parsed: AST { get throws { try parse(raw) } }
}

// ✅ 결과를 저장해 두는 편이 낫다 — 실패는 만들 때 한 번만
struct Doc2 {
    let parsed: Result<AST, ParseError>
}

// ✅ 또는 실패 가능한 초기화 — 유효하지 않은 값이 존재하지 않게 한다
struct Doc3 {
    let parsed: AST
    init(raw: String) throws { parsed = try parse(raw) }
}

Q6. 액터 모델을 네트워크로 늘리면 무엇이 달라지는가?

CS 원리

액터 모델(Hewitt, 1973)은 원래부터 분산을 염두에 둔 모델이다. 핵심 규칙이 셋뿐이다 — 액터는 메시지를 받아 (1) 상태를 바꾸고 (2) 다른 액터에 메시지를 보내고 (3) 새 액터를 만든다.

이 규칙에는 "같은 메모리 공간"이라는 전제가 없다. 그래서 네트워크로 늘리는 것이 자연스럽다.

하지만 공짜는 아니다. P0 16장에서 다룬 분산 시스템의 근본 문제가 그대로 들어온다.

마지막 줄이 가장 중요하다. "요청이 도착했지만 응답이 유실"된 경우, 호출자는 구분할 수 없다. 그래서 P0 16장의 멱등성이 필수가 된다 — 재시도해도 결과가 같아야 한다.

Swift의 설계 선택이 흥미롭다. 투명한 원격 호출(transparent RPC)을 하지 않는다. distributed 키워드를 명시적으로 요구해서, 어떤 호출이 네트워크를 탈 수 있는지가 코드에 드러난다.

이것은 1980년대 분산 객체(CORBA, Java RMI)의 실패에서 배운 것이다. 원격 호출을 로컬처럼 보이게 만들면, 개발자가 지연과 실패를 잊는다. Waldo 등의 "A Note on Distributed Computing"(1994)이 지적한 바로 그 문제다.

iOS에서는

표준 라이브러리가 테스트용 액터 시스템을 제공해 개념을 바로 확인할 수 있다.

import Distributed

typealias DefaultDistributedActorSystem = LocalTestingDistributedActorSystem

distributed actor Counter {
    private var n = 0
    distributed func bump() -> Int { n += 1; return n }
    func localOnly() -> Int { n }          // distributed 아님
}

let sys = LocalTestingDistributedActorSystem()
let c = Counter(actorSystem: sys)
print("id:", c.id)                          // LocalTestingActorID(id: "1")
print("bump:", try await c.bump(), try await c.bump())   // 1 2

let remote = try Counter.resolve(id: c.id, using: sys)   // id 로 참조 복원
print("resolve 후 bump:", try await remote.bump())        // 3 — 상태가 이어진다

제약이 컴파일 타임에 걸린다.

final class NotCodable {}

distributed actor Counter {
    distributed func bad() -> NotCodable { NotCodable() }
    // error: result type 'NotCodable' of distributed instance method 'bad'
    //        does not conform to serialization requirement 'Codable'
}

func use(_ c: Counter) async throws {
    _ = try await c.bump()
    _ = c.localOnly()
    // error: only 'distributed' instance methods can be called on a
    //        potentially remote distributed actor
}

iOS 앱에서 실제로 쓸 일이 있는가? 솔직히 드물다. 서버 사이드 Swift와 클러스터 구성이 주 무대다(swift-distributed-actors 패키지).

다만 개념은 앱에도 적용된다. 앱 확장·XPC 서비스·워치 통신은 같은 문제 구조를 갖는다 — 별도 프로세스, 직렬화, 부분 실패. P1 24장의 앱 확장 통신이 그 예다.

실험 · 도구

위 코드를 그대로 돌려 세 가지 성질을 확인한다.

$ swiftc -swift-version 6 -parse-as-library dist.swift -o dist && ./dist
id: LocalTestingActorID(id: "1")
bump: 1 2
resolve 후 bump: 3

제약이 실제로 막히는지 확인한다.

$ swiftc -swift-version 6 -c bad.swift -o /dev/null
bad.swift:10:22: error: result type 'NotCodable' of distributed instance method 'bad'
                        does not conform to serialization requirement 'Codable'
bad.swift:15:11: error: only 'distributed' instance methods can be called on a
                        potentially remote distributed actor
  `- note: distributed actor-isolated instance method 'localOnly()' declared here

액터 시스템을 직접 만들 때 구현해야 하는 것들을 확인하려면 프로토콜을 보면 된다.

# DistributedActorSystem 요구사항 — 무엇을 구현해야 하는지가 다 보인다
swift -e 'import Distributed' 2>/dev/null
grep -rn "func remoteCall\|func resolve\|func assignID\|func actorReady" \
     $(xcrun --show-sdk-path)/usr/lib/swift/Distributed 2>/dev/null | head

프로젝트 적용

1. 일반 iOS 앱에는 도입하지 않는다. 서버·클러스터가 주 용도다.
2. 개념은 프로세스 경계에 그대로 적용한다. 앱 확장·XPC도 직렬화와 부분 실패가 있다(P1 23장).
3. 재시도가 필요한 곳에 멱등성을 설계한다. P0 16장의 요청 키·중복 제거를 그대로 쓴다.
4. 경계를 코드에 드러낸다. 원격 호출을 로컬처럼 감추지 않는 것이 이 설계의 요지다.
5. Codable 경계를 얇게 유지한다. 31장 Q7의 확장-축소 스키마 진화가 여기서도 필요하다.

꼬리 질문

distributed func transfer(_ req: TransferRequest) throws -> Receipt {
    if let done = processed[req.idempotencyKey] { return done }   // 이미 했으면 그 결과
    let r = perform(req)
    processed[req.idempotencyKey] = r
    return r
}

// 확장에서 본체로 결과를 넘길 때 — 중단을 전제로 설계한다
func handle(_ req: Request) async {
    let key = req.idempotencyKey
    if await store.contains(key) { return }          // 이미 처리됨
    let result = try? await process(req)
    await store.commit(key, result)                  // 원자적으로 기록
}

func resolve<Act>(id: ActorID, as type: Act.Type) throws -> Act?
    where Act: DistributedActor {
    if let local = registry[id] { return local as? Act }
    return nil                     // nil → 원격 프록시를 만든다
}

Q7. 데이터 경쟁 안전성이라는 목표는 어디까지 왔는가?

CS 원리

데이터 경쟁 안전성은 안전 속성(safety property)이다 — "나쁜 일이 절대 일어나지 않는다"는 형태의 보장. 메모리 안전성과 같은 부류다.

정적 검사로 이런 보장을 만들 때 피할 수 없는 삼각형이 있다.

라이스 정리(Rice's theorem)에 따라 셋 다 가질 수는 없다. Swift는 건전성과 결정 가능성을 지키고 완전성을 포기했다 — 안전한 코드도 막힐 수 있다.

초기 Swift 6 전환의 고통이 여기서 나왔다. 막히는 코드가 너무 많았다. 대응 방향이 둘로 갈린다.

• 분석을 정교하게 — Region-Based Isolation(Q1)이 이 방향이다. 거짓 양성을 줄인다.
• 기본값을 바꾼다 — SE-0461·SE-0466이 이 방향이다. 애초에 경계를 안 만든다.

두 번째가 더 근본적이다. 대부분의 앱 코드는 사실 동시성이 필요 없다 — 화면과 그 모델은 메인에서 순차적으로 돌아도 된다. 그런데 기본값이 "격리 없음(nonisolated)"이라, 실제로는 메인에서만 도는 코드까지 동시성 검사를 다 받았다.

-default-isolation MainActor는 이 기본값을 뒤집는다. 명시하지 않은 것은 메인 액터 격리다. 동시성이 필요한 곳만 nonisolated·actor로 표시한다.

철학적으로 이것은 "안전한 기본값(secure by default)"의 적용이다 — P1 23장의 최소 권한 원칙과 같은 발상이다. 기본이 안전하고, 위험한 것을 명시한다.

iOS에서는

전환 경로는 사다리를 하나씩 올라가는 것이다. 한 번에 Swift 6로 넘어가지 않는다.

// Package.swift — 모듈 단위로 단계를 올린다
.target(
    name: "Core",
    swiftSettings: [
        .swiftLanguageMode(.v6),                      // 3단계: 에러
        .defaultIsolation(MainActor.self),            // 4단계: 기본을 메인으로
    ]
)
.target(
    name: "Legacy",
    swiftSettings: [
        .enableExperimentalFeature("StrictConcurrency")   // 2단계: 경고만
    ]
)

-default-isolation MainActor를 켠 뒤에는 표시가 뒤집힌다.

// 기본 격리가 MainActor 이므로 — 이건 자동으로 메인이다
final class ViewModel {
    var items: [Item] = []
}

// 배경에서 돌아야 하는 것만 명시한다
nonisolated func parse(_ d: Data) throws -> [Item] { … }

actor ImageCache {                        // 별도 도메인이 필요한 것도 명시
    private var store: [URL: Data] = [:]
}

주의할 점은 Q2 꼬리질문과 같다 — 무거운 작업이 메인에 남지 않는지 확인해야 한다.

// ⚠️ 기본이 MainActor 이므로 이 함수도 메인에서 돈다
func decodeAll(_ items: [Data]) -> [Item] { items.map(decode) }

// ✅ 무거운 것은 명시적으로 뺀다
nonisolated func decodeAll(_ items: [Data]) -> [Item] { items.map(decode) }

SwiftUI 앱은 이 기본값이 특히 잘 맞는다. 뷰·뷰모델·상태가 대부분 메인이고, 네트워크·디코딩만 밖으로 나가면 된다.

실험 · 도구

사다리를 직접 올라가 본다. 파일 하나면 된다.

// ladder.swift
var counter = 0
func bump() { counter += 1 }

$ run(){ echo "=== $* ==="; swiftc "$@" -parse-as-library -c ladder.swift \
         -o /dev/null 2>&1 | grep -E "error:|warning:" | head -2; }

$ run -swift-version 5
=== -swift-version 5 ===
                                        # 아무 말이 없다

$ run -swift-version 5 -strict-concurrency=complete
=== -swift-version 5 -strict-concurrency=complete ===
warning: var 'counter' is not concurrency-safe because it is nonisolated
         global shared mutable state; this is an error in the Swift 6 language mode

$ run -swift-version 6
=== -swift-version 6 ===
error: var 'counter' is not concurrency-safe because it is nonisolated
       global shared mutable state [#MutableGlobalVariable]

$ run -swift-version 6 -default-isolation MainActor
=== -swift-version 6 -default-isolation MainActor ===
                                        # 다시 조용하다 — 코드는 그대로다

프로젝트 현황을 파악하는 명령들이다.

# 현재 언어 모드와 동시성 진단 수 세기
xcodebuild build 2>&1 | grep -cE "concurrency-safe|data races|Sendable"

# 가장 많이 나오는 진단 유형 순위 — 어디부터 손댈지 정한다
xcodebuild build 2>&1 | grep -oE "\[#[A-Za-z]+\]" | sort | uniq -c | sort -rn | head

# 아직 검사를 끄고 있는 곳
grep -rn "@unchecked Sendable\|nonisolated(unsafe)" --include=*.swift .

두 번째 명령이 유용하다 — 진단 코드별 빈도를 보면 한 가지 패턴이 대부분인 경우가 많고, 그걸 고치면 수백 개가 한 번에 사라진다.

프로젝트 적용

1. 사다리를 한 칸씩 올린다. 경고 → 에러 → 기본값 변경. 한 번에 안 한다.
2. 모듈 단위로 적용한다. 의존이 적은 말단부터 시작한다.
3. 진단 빈도를 세어 우선순위를 정한다. 한 패턴이 대부분인 경우가 흔하다.
4. -default-isolation MainActor를 검토한다. UI 중심 모듈에서 진단이 급감한다.
5. 켠 뒤에는 메인 스레드 점유를 측정한다. P1 25장의 hitch 측정을 반드시 함께 한다.
6. @unchecked Sendable·nonisolated(unsafe) 목록을 관리한다. 기술 부채로 추적하고 줄여 나간다.

꼬리 질문

/// 모든 접근이 `lock` 으로 보호된다. `value` 는 lock 없이 절대 접근하지 않는다.
final class Counter: @unchecked Sendable {
    private let lock = NSLock()
    private var value = 0                 // ← lock 이 보호

    func increment() { lock.lock(); defer { lock.unlock() }; value += 1 }
    func get() -> Int { lock.lock(); defer { lock.unlock() }; return value }
}

# SPM 프로젝트라면
swift package show-dependencies --format tree

# Xcode 프로젝트의 타깃 의존 관계
xcodebuild -list -project App.xcodeproj

출처 · 참고자료