[Swift] Swift Concurrency 완전 정복

 

---

async/await부터 actor까지, 동시성의 진짜 동작 원리

Swift 5.5 이후 등장한 Concurrency(동시성)는 iOS 개발의 패러다임을 완전히 바꿔놓았다.
이전에는 콜백, completion handler, GCD(DispatchQueue)로 비동기 처리를 제어했지만,
이제는 언어 수준에서 안전하고 간결하게 비동기를 표현할 수 있다.
이번 글에서는 async/await, Task, actor를 중심으로
"Swift 동시성이 실제로 어떻게 작동하는가"를 실무 개발자 관점에서 정리하려고 한다.
 

왜 Concurrency인가?

기존 GCD 기반 코드의 문제점은 명확하다.

DispatchQueue.global().async {
    let data = fetchData()
    DispatchQueue.main.async {
        self.label.text = data.title
    }
}

- 콜백 중첩으로 인한 가독성 저하
- 스레드 안전성 보장 부재
- 코드 흐름이 "순차적"이지 않아 디버깅 어려움
Swift Concurrency는 이를 컴파일러 수준에서 안전하게 제어할 수 있도록 설계되었다.
비동기 함수 간의 호출 관계를 명시적으로 표현하며, 데이터 경쟁(Data Race)을 언어 차원에서 방지한다.
 

async/await 기본 구조

func fetchUser() async throws -> User {
    try await NetworkManager.shared.loadUser()
}

- async: 함수가 비동기로 동작할 수 있음을 명시
- await: 호출 시점에서 일시 중지(suspend) 가능성을 나타냄

즉, await는 잠깐 멈췄다가 결과가 준비되면서 다시 이어지는 것이다.
Swift는 이 중단 지점을 자동 관리하므로 개발자가 콜백을 직접 다룰 필요가 없다.
 

Task와 Structured Concurrency

Swift의 Task는 비동기 작업의 기본 단위이다.

Task {
    let data = try await fetchData()
    print(data)
}

여기서 중요한 개념은 Structured Concurrency이다.
부모 Task가 취소되면 하위 Task들도 자동으로 취소되며, 누수 없는 구조가 된다.

[예시] - 여러 작업 병렬 실행

await withTaskGroup(of: Int.self) { group in
    for i in 1...5 {
        group.addTask {
            return await heavyJob(i)
        }
    }
    let total = await group.reduce(0, +)
    print("Total:", total)
}

TaskGroup은 자식 작업들을 묶어 병렬 실행하며, 내부적으로 suspend/resume를 통해 자동 스케줄링 된다.
 

actor로 데이터 경쟁 방지하기

클래스는 여러 스레드에서 동시에 접근하면 위험하지만,
actor는 내부 상태에 대한 접근을 직렬화(serialize)한다.

actor Counter {
    private var value = 0
    
    func increment() { value += 1 }
    func getValue() -> Int { value }
}

- actor 내부의 value는 오직 하나의 Task만 접근 가능
- 외부에서 접근할 때는 항상 await 필요

let counter = Counter()
await counter.increment()
print(await counter.getValue())

즉, actor는 "비동기 안전 클래스"라고 볼 수 있다.
 

@MainActor로 UI 안전하게 업데이트

UI는 항상 메인 스레드에서만 변경해야 한다.
@MainActor를 사용하면 해당 함수나 프로퍼티가 항상 메인 스레드에서 실행됨을 컴파일러가 보장한다.

@MainActor
func updateUI() {
    label.text = "업데이트 완료"
}

예전에는 DispatchQueue.main.async로 감쌌던 부분을 
@MainActor로 선언만 해도 동일한 효과를 얻을 수 있다.
 

실무에서 자주 쓰이는 패턴: Task 취소

API 요청이 연속적으로 들어올 때, 이전 요청을 취소하고 새로운 요청만 유지해야 할 때가 많다.

var currentTask: Task<Void, Never>?

func loadData() {
    currentTask?.cancel()
    currentTask = Task {
        do {
            let data = try await fetchData()
            await updateUI(with: data)
        } catch {
            if Task.isCancelled { return }
        }
    }
}

이런 방식으로 이전 비동기 작업의 취소를 명시적으로 처리할 수 있다.
Task 취소는 Swift Concurrency의 구조적 특성 덕분에 간단하게 제어된다.
 

---

 

Swift의 Concurrency는 단순히 문법이 아니라, 안전한 동시성 모델이다.
이제는 비동기를 "스레드 단위"가 아닌 "작업(Task) 단위"로 다루는 시대이며,
컴파일러가 데이터 경쟁을 사전에 막아주는 역할을 한다.
실무에서는 이 패턴들을 조합해서 아래와 같이 확장할 수 있다.
- API 연속 호출 관리
- ViewModel의 async 처리
- actor 기반 상태 저장소 구성

Swift에서 동시성은 더 이상 선택이 아닌 기본기가 된 것 같다.
기존에 GCD나 OperationQueue 기반 코드를 유지하는 대신,
이제는 async/await와 actor로 구조를 설계하는 것이 유지보수와 안전성 측면에서 훨씬 효율적이라고 생각한다.
새로운 코드를 작성할 때마다 "이 작업은 어떤 Task로, 어떤 Actor안에서 안전하게 처리될까?"를 생각하는 습관이 Swift Concurrency를 제대로 이해하고 활용하는 첫 걸음이라고 생각한다.

이전에는 escaping 클로저와 completion handler로 비동기를 처리하면서 복잡한 콜백 체인은 감수해야했었다.
그 이유는 당시엔 Swift Concurreny가 낯설었고, 배워야 할 개념이 너무 많아 쉽게 다가서지 못했다.
'async/await가 뭔데? 어렵다. 그냥 아는 방식으로 개발하자'라는 생각이 솔직한 마음이었다.

하지만 실제로 적용해보니, 복잡했던 비동기 흐름이 놀라울 정도로 단순해지고 코드의 의도가 명확해졌다.
지금 돌이켜보면, Swift Concurrency를 이해하려는 과정이 단순한 문법 학습이 아니라
비동기라는 개념 자체를 새롭게 받아들이는 경험이었던 것 같다.

복잡한 코드를 줄이는 데서 그치지 않고, '어떻게 더 안전한 구조를 만들 것인가'를 생각하게 되면서
앱의 전체 구조를 다시 바라보게 되었던 것 같다.
이후에 블로그에서 이 구조를 ViewModel과 네트워크 계층에 어떻게 적용할 수 있을지 작성해보려고 한다.
(다음 글은 아님. 아무튼 쓸 예정.)
 

---