iOS Concurrency & Actors Physics

1. Overview

iOS 동시성 및 액터 물리(iOS Concurrency & Actors Physics)는 스마트폰의 제한된 코어(CPU)를 수백 개의 작업(Task)이 찢어서 나눠 쓸 때 발생하는 병목과 충돌을 제어하는 다중 스레드(Multithreading) 역학을 다룹니다.

UI를 그리는 메인 스레드(Main Thread)가 무거운 다운로드 작업에 묶이면 화면이 완전히 멈춰버립니다. 과거에는 이를 피하기 위해 GCD(Grand Central Dispatch)라는 대기열(Queue)에 콜백 지옥(Callback Hell)을 엮어 사용했으나, 현대 Swift는 async/await라는 구조적 동시성(Structured Concurrency)을 통해 비동기 흐름을 동기 코드처럼 직관적으로 풀어냅니다. 나아가 여러 스레드가 동시에 하나의 데이터를 수정하다 메모리가 오염되는 '데이터 레이스(Data Race)'를 물리적으로 차단하기 위해, 데이터를 안전한 독방에 가두는 액터(Actor) 모델의 고립화(Isolation) 역학을 배웁니다.

2. Scope & Boundaries

In-Scope

• Grand Central Dispatch (GCD): Serial/Concurrent Queue, Sync/Async 실행, DispatchQueue 물리학.
• Swift Concurrency: async/await, Task 계층 구조, 협력적 스레드 풀(Cooperative Thread Pool).
• 데이터 경쟁 방어 (Data Safety): Actor 모델, @MainActor, Sendable 프로토콜 기반 스레드 안전성 보장.
• 교착 상태와 성능: 데드락(Deadlock) 탐지, 컨텍스트 스위칭(Context Switching) 오버헤드 통제.

Out-of-Scope

• 네트워크 프로토콜 TCP/IP 통신: 다운로드를 받는 HTTP 통신 규약 자체 $ightarrow$ 08-03. Application Layer Protocol 영역으로 위임.
• 하위 운영체제 커널의 스레드 스케줄링: Mach 커널이 인터럽트를 처리하고 물리적 CPU 레지스터를 백업하는 과정 $ightarrow$ 03-02. Concurrency & Scheduling Mechanics 영역으로 위임.

Boundaries

• iOS vs OS Kernel (03-02): OS Kernel(03-02)은 CPU 코어가 스레드를 멈출 때 레지스터를 백업하는 하드웨어적 관점이라면, iOS Concurrency(13-01-03)는 그 위에서 "어떻게 화면을 얼리지 않고 백그라운드로 사진을 다운받아 UI에 예쁘게 그릴까?"를 고민하는 애플리케이션 프레임워크 관점입니다.

3. Counterexample

• 메인 스레드 블로킹 (Main Thread Blocking): 용량이 50MB인 이미지를 다운로드하는 코드를 UI를 그리는 메인 스레드(Main Thread)에 직렬(Sync)로 밀어넣는 행위. 다운로드가 끝날 때까지 10초 동안 스크롤도, 버튼 클릭도 먹히지 않는 '앱 멈춤(Freezing)' 현상이 발생하여 사용자 경험이 완전히 박살납니다. 무거운 작업은 백그라운드 스레드(Concurrent Queue)로 반드시 넘겨야 합니다.
• 무분별한 동시성 생성 (Thread Explosion Fallacy): 작업을 빨리 끝내겠다며 GCD로 백그라운드 스레드를 1,000개 한꺼번에 생성하는 무지. 스레드를 교체하는 컨텍스트 스위칭(Context Switching) 비용이 연산 시간보다 커져 기기 배터리가 녹아내리고 성능은 오히려 1/10로 추락합니다. Swift Concurrency의 '협력적 스레드 풀'은 CPU 코어 개수만큼만 스레드를 유지하여 물리적 병목을 해결합니다.

4. Prerequisites

• 운영체제 스케줄링 (Basic): 스레드(Thread)가 무엇인지, 데드락(Deadlock)이 왜 발생하는지 알아야 iOS의 큐(Queue) 역학을 이해할 수 있습니다. (03-02. OS Mechanics)
• ARC 메모리 관리 (Recommended): 비동기 작업(Task) 안에서 뷰 객체를 잘못 참조할 때 메모리 누수(Retain Cycle)가 어떻게 일어나는지 방어해야 합니다. (13-01-01. Swift Runtime)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 메인 스레드와 GCD 큐(Queue) 역학

• Why to Learn: 화면이 얼어붙는 프리징(Freezing) 현상을 막고 작업을 쾌적하게 찢어 돌리기 위함입니다.
• What to Learn: Main Thread의 역할, GCD(Grand Central Dispatch), DispatchQueue (Serial vs Concurrent), Sync vs Async.
• How to Learn: 버튼을 누르면 5초짜리 계산을 도는 코드를 짰을 때 버튼이 눌린 채로 멈춰있는 현상을 경험하고, 이를 DispatchQueue.global().async로 감싸 백그라운드로 밀어넣는 순간 메인 스레드가 해방되어 화면이 부드럽게 움직이는 물리적 분리를 증명합니다.
• Implement: 네트워크에서 고해상도 이미지를 3장 병렬로 다운로드(백그라운드 큐)한 후, 렌더링 직전에 다시 메인 큐(DispatchQueue.main.async)로 건너와 ImageView에 그리는 전통적 흐름 제어 작성.

Core Topic 02: 구조적 동시성과 async/await

• Why to Learn: { result in { data in { ... } } } 형태의 콜백 지옥 늪에서 벗어나, 사람이 읽을 수 있는 위에서 아래로 흐르는 비동기 코드를 짜기 위함입니다.
• What to Learn: async/await 문법, Task, 협력적 스레드 풀(Cooperative Thread Pool), Suspensions/Resumption.
• How to Learn: 스레드를 아예 통째로 멈추는(Block) 구형 방식과 달리, await를 만나는 순간 스레드 제어권을 잠시 반환하고 다른 작업을 하다가 데이터가 오면 다시 낚아채서 실행하는 Continuation(중단/재개) 물리학을 그림으로 그려봅니다.
• Implement: 3개의 API를 순차적으로 호출하여 결과를 취합해야 하는 로직을 async/await를 사용하여 단 3줄의 코드로 압축하는 비동기 함수 설계.

Recommended

Core Topic 03: 데이터 레이스 방어와 Actor 모델

• Why to Learn: 100개의 비동기 작업이 은행 잔고(변수) 1개에 동시에 쓰기(Write) 연산을 할 때 돈이 증발하거나 복사되는 '충돌'을 막기 위해서입니다.
• What to Learn: 데이터 레이스(Data Race), Thread-Safety, actor 키워드, @MainActor, Sendable 프로토콜.
• How to Learn: 클래스(Class) 변수를 100개의 스레드가 동시에 +1을 시켰을 때 최종 결과가 100이 안 나오고 83쯤에서 크래시가 나는 데이터 붕괴 현상을 목격한 뒤, 이를 actor로 바꾸면 무조건 한 번에 한 스레드만 접근하게 강제되어 안전하게 100이 도출되는 동기화 고립(Isolation)을 실습합니다.
• Implement: 백그라운드 데이터베이스 쓰기 작업을 담당하는 전담 객체를 actor로 선언하고, @MainActor가 붙은 UI 뷰에서 비동기로 그 actor에 접근해 데이터를 가져와 화면을 갱신하는 100% 스레드 세이프(Thread-safe) 아키텍처 구현.

7. Terminology

8. References

Primary References

• [CS2023: Parallel and Distributed Computing] — 동시성 스케줄링, 데이터 경합(Data Race) 방어 및 동기화 기법.
• [SWEBOK v3: Software Construction] — 런타임 비동기 실행 제어 및 멀티스레딩 아키텍처 내구성 한계.

Secondary References

• [Swift Programming Language: Concurrency] — 협력적 스레드 풀(Cooperative Thread Pool), Task 계층 구조(Structured Concurrency) 및 Sendable 제약.
• [Concurrent Programming in Mac OS X and iOS (Vandad Nahavandipoor)] — GCD 역학, Serial/Concurrent 큐의 블로킹 물리학.

Industry References

• [Apple WWDC: Explore structured concurrency in Swift] — async/await를 통한 컨텍스트 스위칭 오버헤드 감소 및 콜백 지옥 타파.
• [Apple WWDC: Protect mutable state with Swift actors] — 데이터 레이스(Race Condition)를 메모리 격리(Isolation)로 컴파일 타임에 막아내는 메커니즘.

9. Final Checklist

Primary Checklist

• 무거운 파일 다운로드나 압축 해제 같은 작업을 절대 메인 스레드(Main Thread)에 동기(Sync)로 올려 UI 프리징(Jank/Freezing)을 유발하지 않는가?
• 다수의 스레드가 하나의 참조 객체를 동시에 수정할 때 발생하는 데이터 레이스(Data Race)를 Actor 모델이나 락(Lock)을 통해 물리적으로 차단했는가?

Secondary Checklist

• 수많은 비동기 작업을 제어할 때 깊은 콜백 클로저(Callback Hell) 대신 async/await 문법을 도입하여 코드의 실행 순서와 예외 처리(try/catch) 가독성을 확보했는가?
• 백그라운드 큐(Global Queue)에서 연산을 마친 결과를 화면에 업데이트할 때 반드시 메인 큐(DispatchQueue.main 또는 @MainActor)로 안전하게 점프하여 넘겨주는가?

Industry Checklist

• 불필요하게 1,000개 이상의 스레드를 띄워 컨텍스트 스위칭(Context Switching) 부하로 배터리를 고갈시키는 스레드 폭발(Thread Explosion) 현상을 Swift Concurrency의 제한된 스레드 풀로 방어했는가?
• 비동기 네트워크 통신이나 타이머 작업이 진행 중일 때, 유저가 뒤로가기 버튼을 누르면 해당 Task(작업 묶음)에 즉각적인 취소(Cancellation) 신호를 전파하여 CPU 자원 낭비를 멈추는가?