빌어먹게 쉬운
Swift 동시성

이해해야 할 단 하나의 것

**격리(Isolation)**가 모든 것의 핵심입니다. 이것은 Swift가 다음 질문에 대한 답입니다: 지금 이 데이터를 누가 만질 수 있나?

왜 스레드만으로는 안 되나요?

수십 년 동안 우리는 스레드를 생각하면서 동시성 코드를 작성했습니다. 문제는? 스레드는 여러분이 자기 발등을 찍는 것을 막아주지 않습니다. 두 개의 스레드가 동시에 같은 데이터에 접근할 수 있어서, 데이터 레이스(data race)를 일으킵니다 - 무작위로 크래시되고 재현이 거의 불가능한 버그입니다.

휴대폰에서는 괜찮을 수도 있습니다. 하지만 수천 개의 동시 요청을 처리하는 서버에서는 데이터 레이스가 확실하게 발생합니다 - 보통 프로덕션에서, 금요일에요. Swift가 서버나 다른 고도로 동시적인 환경으로 확장되면서, "최선을 바라는 것"은 통하지 않습니다.

예전 방식은 방어적이었습니다: 락을 사용하고, 디스패치 큐를 사용하고, 빠뜨린 곳이 없기를 바라는 것이었습니다.

Swift의 접근 방식은 다릅니다: 컴파일 타임에 데이터 레이스를 불가능하게 만듭니다. "이것이 어느 스레드에 있나?"를 묻는 대신, Swift는 "지금 누가 이 데이터를 만질 수 있나?"를 묻습니다. 그것이 격리입니다.

다른 언어들은 어떻게 처리하나요?

Swift와 Rust는 컴파일 타임에 데이터 레이스를 잡아내는 유일한 주류 언어입니다. 트레이드오프는? 처음에는 학습 곡선이 가파릅니다. 하지만 모델을 이해하고 나면, 컴파일러가 여러분을 지원합니다.

Sendable과 액터 격리에 대한 성가신 에러들? 그것들은 이전에는 조용한 크래시였을 버그들을 잡아내고 있습니다.

격리 도메인

이제 격리(프라이빗 사무실)를 이해했으니, Swift 빌딩의 다양한 유형의 사무실을 살펴보겠습니다.

MainActor: 안내 데스크

MainActor는 메인 스레드에서 실행되는 특별한 격리 도메인입니다. 모든 UI 작업이 여기서 일어납니다.

@MainActor
@Observable
class ViewModel {
    var items: [Item] = []  // UI 상태가 여기 있습니다

    func refresh() async {
        let newItems = await fetchItems()
        self.items = newItems  // 안전합니다 - MainActor에 있습니다
    }
}

Actors: 부서 사무실

actor는 부서 사무실과 같습니다 - 자체 데이터를 보호하고 한 번에 한 방문자만 허용합니다.

actor BankAccount {
    var balance: Double = 0

    func deposit(_ amount: Double) {
        balance += amount  // 안전합니다! 한 번에 한 호출자만
    }
}

액터가 없으면, 두 스레드가 balance = 100을 읽고, 둘 다 50을 더하고, 둘 다 150을 씁니다 - $50를 잃었습니다. 액터를 사용하면, Swift가 자동으로 접근을 큐에 넣고 두 입금이 모두 올바르게 완료됩니다.

Nonisolated: 복도

nonisolated로 마킹된 코드는 복도와 같습니다 - 어떤 사무실에도 속하지 않고 어디서나 접근할 수 있습니다.

actor UserSession {
    let userId: String          // 불변 - 어디서나 읽기 안전
    var lastActivity: Date      // 가변 - 액터 보호 필요

    nonisolated var displayId: String {
        "User: \(userId)"       // 불변 데이터만 읽습니다
    }
}

// 사용법 - nonisolated에는 await가 필요 없습니다
let session = UserSession(userId: "123")
print(session.displayId)  // 동기적으로 작동합니다!

불변 데이터만 읽는 계산 속성에 nonisolated를 사용하세요.

격리가 전파되는 방법

타입을 액터 격리로 마킹하면, 그 메서드에는 무슨 일이 일어날까요? 클로저는요? 격리가 어떻게 퍼지는지 이해하는 것이 놀라움을 피하는 열쇠입니다.

클래스는 격리를 상속합니다

@MainActor
class ViewModel {
    var count = 0           // MainActor 격리

    func increment() {      // 역시 MainActor 격리
        count += 1
    }
}

클래스 안의 모든 것이 @MainActor를 상속합니다. 각 메서드를 마킹할 필요가 없습니다.

Task는 컨텍스트를 상속합니다 (보통)

@MainActor
class ViewModel {
    func doWork() {
        Task {
            // 이것은 MainActor를 상속합니다!
            self.updateUI()  // 안전합니다, await가 필요 없습니다
        }
    }
}

@MainActor 컨텍스트에서 생성된 Task { }는 MainActor에 머뭅니다. 이것이 보통 원하는 것입니다.

Task.detached는 상속을 끊습니다

@MainActor
class ViewModel {
    func doWork() {
        Task.detached {
            // 더 이상 MainActor에 있지 않습니다!
            await self.updateUI()  // 이제 await가 필요합니다
        }
    }
}

경계를 넘을 수 있는 것

이제 격리 도메인(사무실)과 그것들이 어떻게 전파되는지 알았으니, 다음 질문은: 무엇을 그것들 사이에서 전달할 수 있나요?

Sendable: 공유하기 안전

이러한 타입들은 격리 경계를 안전하게 넘을 수 있습니다:

// 불변 데이터를 가진 구조체 - 사본처럼
struct User: Sendable {
    let id: Int
    let name: String
}

// 액터는 스스로를 보호합니다 - 자체 방문자를 처리합니다
actor BankAccount { }  // 자동으로 Sendable

자동으로 Sendable:

• Sendable 속성을 가진 값 타입 (struct, enum)
• 액터 (스스로를 보호합니다)
• 불변 클래스 (let 속성만 있는 final class)

Non-Sendable: 그 자리에 머물러야 함

이러한 타입들은 안전하게 경계를 넘을 수 없습니다:

// 가변 상태를 가진 클래스 - 원본 문서처럼
class Counter {
    var count = 0  // 두 사무실이 이것을 수정하면 = 재앙
}

이것이 핵심 구분인 이유는? 여러분이 마주칠 모든 컴파일러 에러는 다음으로 귀결되기 때문입니다: "Sendable이 아닌 타입을 격리 경계를 넘어 보내려고 합니다."

컴파일러가 불평할 때

Swift가 무언가가 Sendable이 아니라고 말하면, 선택지가 있습니다:

1. 값 타입으로 만들기 - class 대신 struct 사용
2. 격리하기 - @MainActor에 두어서 넘을 필요가 없게 하기
3. non-Sendable로 유지 - 사무실 간에 전달하지 않기
4. 최후의 수단: @unchecked Sendable - 안전하다고 약속하기 (조심하세요)

경계를 넘는 방법

격리 도메인을 이해했고, 무엇이 그것들을 넘을 수 있는지 알았습니다. 이제: 실제로 사무실 간에 어떻게 소통하나요?

await 키워드

다른 액터의 함수를 호출할 때, await가 필요합니다:

actor DataStore {
    var items: [Item] = []

    func add(_ item: Item) {
        items.append(item)
    }
}

@MainActor
class ViewModel {
    let store = DataStore()

    func addItem(_ item: Item) async {
        await store.add(item)  // 다른 사무실로 요청
        updateUI()             // 우리 사무실로 돌아옴
    }
}

await는 의미합니다: "이 요청을 보내고 완료될 때까지 일시 중지합니다. 기다리는 동안 다른 작업을 할 수도 있습니다."

정지, 차단이 아님

핵심 통찰은 **차단(blocking)**과 **정지(suspension)**의 차이입니다:

• 차단: 대기실에 앉아서 벽을 바라봅니다. 다른 일은 일어나지 않습니다.
• 정지: 전화번호를 남기고 심부름을 합니다. 준비되면 전화할 것입니다.

// 스레드가 유휴 상태로, 5초 동안 아무것도 하지 않습니다
Thread.sleep(forTimeInterval: 5)

// 스레드가 해제되어 기다리는 동안 다른 작업을 합니다
try await Task.sleep(for: .seconds(5))

동기 코드에서 비동기 작업 시작하기

때때로 동기 코드에 있는데 비동기를 호출해야 합니다. Task를 사용하세요:

@MainActor
class ViewModel {
    func buttonTapped() {  // 동기 함수
        Task {
            await loadData()  // 이제 await를 사용할 수 있습니다
        }
    }
}

작동하는 패턴

네트워크 요청 패턴

@MainActor
@Observable
class ViewModel {
    var users: [User] = []
    var isLoading = false

    func fetchUsers() async {
        isLoading = true

        // 이것은 정지됩니다 - 스레드가 다른 작업을 자유롭게 할 수 있습니다
        let users = await networkService.getUsers()

        // 자동으로 MainActor로 돌아옵니다
        self.users = users
        isLoading = false
    }
}

DispatchQueue.main.async가 없습니다. @MainActor 속성이 처리합니다.

async let으로 병렬 작업

func loadProfile() async -> Profile {
    async let avatar = loadImage("avatar.jpg")
    async let banner = loadImage("banner.jpg")
    async let details = loadUserDetails()

    // 세 가지 모두 병렬로 실행됩니다!
    return Profile(
        avatar: await avatar,
        banner: await banner,
        details: await details
    )
}

더블탭 방지

이 패턴은 상태가 있는 시스템에 대한 Matt Massicotte의 가이드에서 나온 것입니다:

@MainActor
class ButtonViewModel {
    private var isLoading = false

    func buttonTapped() {
        // 모든 비동기 작업 전에 동기적으로 가드합니다
        guard !isLoading else { return }
        isLoading = true

        Task {
            await doExpensiveWork()
            isLoading = false
        }
    }
}

피해야 할 흔한 실수

이것들은 경험 많은 개발자들도 하는 흔한 실수들입니다:

async = 백그라운드라고 생각하기

// 이것은 여전히 메인 스레드를 차단합니다!
@MainActor
func slowFunction() async {
    let result = expensiveCalculation()  // 동기 = 차단
    data = result
}

다른 사무실에서 작업이 완료되어야 한다면, 명시적으로 거기로 보내세요:

func slowFunction() async {
    let result = await Task.detached {
        expensiveCalculation()  // 이제 다른 사무실에서
    }.value
    await MainActor.run { data = result }
}

너무 많은 액터 만들기

// 과도하게 엔지니어링됨 - 모든 호출이 사무실 간 이동을 요구합니다
actor NetworkManager { }
actor CacheManager { }
actor DataManager { }

// 더 나음 - 대부분은 안내 데스크에 있을 수 있습니다
@MainActor
class AppState { }

어디서나 MainActor.run 사용하기

// 이렇게 하지 마세요 - 계속 안내 데스크로 걸어감
await MainActor.run { doMainActorStuff() }

// 이렇게 하세요 - 안내 데스크에서 일하세요
@MainActor func doMainActorStuff() { }

모든 것을 Sendable로 만들기

모든 것이 Sendable일 필요는 없습니다. 어디서나 @unchecked Sendable을 추가하고 있다면, 사무실을 떠날 필요가 없는 것들의 사본을 만들고 있는 것입니다.

컴파일러 경고 무시하기

Sendable에 대한 모든 컴파일러 경고는 보안 요원이 무언가가 사무실 간에 운반하기에 안전하지 않다고 말하는 것입니다. 무시하지 마세요 - 이해하세요.

흔한 컴파일러 에러

이것들은 여러분이 볼 실제 에러 메시지입니다. 각각은 컴파일러가 데이터 레이스로부터 여러분을 보호하고 있는 것입니다.

"Sending 'self.foo' risks causing data races"

수정 1: class 대신 struct 사용

수정 2: 하나의 액터에 두기:

@MainActor
class MyClass {
    var foo: SomeType  // 안내 데스크에 머뭅니다
}

"Non-sendable type cannot cross actor boundary"

수정 1: struct로 만들기:

// 이전: class (non-Sendable)
class User { var name: String }

// 이후: struct (Sendable)
struct User: Sendable { let name: String }

수정 2: 하나의 액터에 격리하기:

@MainActor
class User { var name: String }

"Actor-isolated property cannot be referenced"

수정: await 사용:

// 틀림 - 직접 손을 뻗음
let value = myActor.balance

// 맞음 - 적절한 요청
let value = await myActor.balance

"Call to main actor-isolated method in synchronous context"

수정 1: 호출자를 @MainActor로 만들기:

@MainActor
func doSomething() {
    updateUI()  // 같은 격리, await 필요 없음
}

수정 2: await 사용:

func doSomething() async {
    await updateUI()
}

Swift 동시성의 세 단계

모든 것을 한 번에 배울 필요는 없습니다. 이 단계들을 진행하세요:

이 단계들은 엄격한 경계가 아닙니다 - 앱의 다른 부분들은 다른 단계가 필요할 수 있습니다. 대부분 레벨 1인 앱이 레벨 2 패턴이 필요한 하나의 기능을 가질 수 있습니다. 괜찮습니다. 각 부분에 적합한 가장 간단한 접근 방식을 사용하세요.

레벨 1: 스타트업

모두가 안내 데스크에서 일합니다. 간단하고, 직접적이고, 관료주의가 없습니다.

• 네트워크 호출에 async/await 사용
• UI 클래스를 @MainActor로 마킹
• SwiftUI의 .task 모디파이어 사용

이것이 앱의 80%를 처리합니다. Things, Bear, Flighty, 또는 Day One과 같은 앱들이 이 범주에 속할 것입니다 - 주로 데이터를 가져와서 표시하는 앱들입니다.

레벨 2: 성장하는 회사

한 번에 여러 가지를 처리해야 합니다. 병렬 프로젝트와 팀 조정의 시간입니다.

• 병렬 작업에 async let 사용
• 동적 병렬성에 TaskGroup 사용
• 태스크 취소 이해하기

Ivory/Ice Cubes (여러 타임라인과 스트리밍 업데이트를 관리하는 마스토돈 클라이언트), Overcast (다운로드, 재생, 백그라운드 동기화 조정), 또는 Slack (여러 채널에 걸친 실시간 메시징)과 같은 앱들이 특정 기능에 이러한 패턴을 사용할 수 있습니다.

레벨 3: 기업

자체 정책을 가진 전용 부서들. 복잡한 사무실 간 소통.

• 공유 상태를 위한 커스텀 액터 생성
• Sendable에 대한 깊은 이해
• 커스텀 익스큐터

Xcode, Final Cut Pro, 또는 Vapor와 Hummingbird같은 서버 사이드 Swift 프레임워크가 이러한 패턴을 필요로 할 것입니다 - 복잡한 공유 상태, 수천 개의 동시 연결, 또는 다른 사람들이 위에 구축하는 프레임워크 수준 코드입니다.

용어집: 만나게 될 더 많은 키워드

핵심 개념을 넘어서, 실제로 볼 다른 Swift 동시성 키워드들이 있습니다:

각각을 사용할 때

nonisolated - 계산 속성 읽기

기본적으로, 액터 안의 모든 것은 격리되어 있습니다 - 접근하려면 await가 필요합니다. 하지만 때때로 본질적으로 읽기 안전한 속성이 있습니다: 불변 let 상수, 또는 다른 안전한 데이터에서만 값을 도출하는 계산 속성. 이것들을 nonisolated로 마킹하면 호출자가 동기적으로 접근할 수 있어, 불필요한 비동기 오버헤드를 피합니다.

actor UserSession {
    let userId: String  // 불변, 읽기 안전
    var lastActivity: Date  // 가변, 보호 필요

    // 이것은 await 없이 호출될 수 있습니다
    nonisolated var displayId: String {
        "User: \(userId)"  // 불변 데이터만 읽습니다
    }
}

// 사용법
let session = UserSession(userId: "123")
print(session.displayId)  // await 필요 없습니다!

@Sendable - 경계를 넘는 클로저

클로저가 나중에 또는 다른 격리 도메인에서 실행되기 위해 이스케이프할 때, Swift는 데이터 레이스를 일으키지 않는다는 것을 보장해야 합니다. @Sendable 속성은 경계를 넘어 전달하기에 안전한 클로저를 마킹합니다 - 안전하지 않게 가변 상태를 캡처할 수 없습니다. Swift는 종종 이것을 자동으로 추론합니다 (Task.detached처럼), 하지만 때때로 클로저를 받는 API를 설계할 때 명시적으로 선언해야 합니다.

@MainActor
class ViewModel {
    var items: [Item] = []

    func processInBackground() {
        Task.detached {
            // 이 클로저는 분리된 태스크에서 MainActor로 넘어갑니다
            // @Sendable이어야 합니다 (Swift가 이것을 추론합니다)
            let processed = await self.heavyProcessing()
            await MainActor.run {
                self.items = processed
            }
        }
    }
}

// 필요할 때 명시적인 @Sendable
func runLater(_ work: @Sendable @escaping () -> Void) {
    DispatchQueue.global().asyncAfter(deadline: .now() + 1) {
        work()
    }
}

withCheckedContinuation - 오래된 API 연결하기

많은 오래된 API들은 async/await 대신 완료 핸들러를 사용합니다. 완전히 다시 작성하는 대신, withCheckedContinuation을 사용해서 감쌀 수 있습니다. 이 함수는 현재 태스크를 일시 중지하고, continuation 객체를 제공하고, continuation.resume()을 호출할 때 재개합니다. "checked" 변형은 두 번 재개하거나 전혀 재개하지 않는 것과 같은 프로그래밍 에러를 잡아냅니다.

// 오래된 콜백 기반 API
func fetchUser(id: String, completion: @escaping (User?) -> Void) {
    // ... 콜백이 있는 네트워크 호출
}

// async로 감싸기
func fetchUser(id: String) async -> User? {
    await withCheckedContinuation { continuation in
        fetchUser(id: id) { user in
            continuation.resume(returning: user)  // 다시 연결합니다!
        }
    }
}

던지는 함수의 경우, withCheckedThrowingContinuation을 사용하세요:

func fetchUserThrowing(id: String) async throws -> User {
    try await withCheckedThrowingContinuation { continuation in
        fetchUser(id: id) { result in
            switch result {
            case .success(let user):
                continuation.resume(returning: user)
            case .failure(let error):
                continuation.resume(throwing: error)
            }
        }
    }
}

AsyncStream - 이벤트 소스 연결하기

withCheckedContinuation은 한 번의 콜백을 처리하는 반면, 많은 API들은 시간이 지남에 따라 여러 값을 전달합니다 - delegate 메서드, NotificationCenter, 또는 커스텀 이벤트 시스템. AsyncStream은 이것들을 Swift의 AsyncSequence로 연결하여, for await 루프를 사용할 수 있게 합니다. 스트림을 생성하고, continuation을 저장하고, 새 값이 도착할 때마다 yield()를 호출합니다.

class LocationTracker: NSObject, CLLocationManagerDelegate {
    private var continuation: AsyncStream<CLLocation>.Continuation?

    var locations: AsyncStream<CLLocation> {
        AsyncStream { continuation in
            self.continuation = continuation
        }
    }

    func locationManager(_ manager: CLLocationManager,
                        didUpdateLocations locations: [CLLocation]) {
        for location in locations {
            continuation?.yield(location)
        }
    }
}

// 사용법
let tracker = LocationTracker()
for await location in tracker.locations {
    print("새 위치: \(location)")
}

Task.isCancelled - 협력적 취소

Swift는 협력적 취소를 사용합니다 - 태스크가 취소될 때, 즉시 중단되지 않습니다. 대신, 플래그가 설정되고, 주기적으로 확인하는 것이 여러분의 책임입니다. 이것은 정리와 부분 결과에 대한 제어를 제공합니다. Task.checkCancellation()을 사용하여 즉시 던지거나, 취소를 우아하게 처리하고 싶을 때 (부분 결과 반환과 같이) Task.isCancelled를 확인하세요.

func processLargeDataset(_ items: [Item]) async throws -> [Result] {
    var results: [Result] = []

    for item in items {
        // 각 비용이 많이 드는 작업 전에 확인합니다
        try Task.checkCancellation()  // 취소되면 던집니다

        // 또는 던지지 않고 확인합니다
        if Task.isCancelled {
            return results  // 부분 결과를 반환합니다
        }

        let result = await process(item)
        results.append(result)
    }

    return results
}

Task.detached - 현재 컨텍스트 벗어나기

일반 Task { }는 현재 액터 컨텍스트를 상속합니다 - @MainActor에 있으면, 태스크는 @MainActor에서 실행됩니다. 때때로 그것이 원하는 것이 아닙니다, 특히 UI를 차단할 CPU 집약적인 작업에서요. Task.detached는 상속된 컨텍스트가 없는 태스크를 생성하여, 백그라운드 익스큐터에서 실행됩니다. 하지만 드물게 사용하세요 - 대부분의 경우, 적절한 await 포인트를 가진 일반 Task가 충분하고 추론하기 더 쉽습니다.

@MainActor
class ImageProcessor {
    func processImage(_ image: UIImage) {
        // 하지 마세요: 여전히 MainActor 컨텍스트를 상속합니다
        Task {
            let filtered = applyFilters(image)  // 메인을 차단합니다!
        }

        // 하세요: 분리된 태스크는 독립적으로 실행됩니다
        Task.detached(priority: .userInitiated) {
            let filtered = await self.applyFilters(image)
            await MainActor.run {
                self.displayImage(filtered)
            }
        }
    }
}

@preconcurrency - 레거시 코드와 함께 살기

아직 동시성을 위해 업데이트되지 않은 모듈을 임포트할 때 경고를 억제합니다:

// 이 임포트에서 경고 억제
@preconcurrency import OldFramework

// 또는 프로토콜 준수에서
class MyDelegate: @preconcurrency SomeOldDelegate {
    // non-Sendable 요구사항에 대해 경고하지 않습니다
}

더 읽을 거리

이 가이드는 Swift 동시성에 대한 최고의 리소스를 정리합니다.