Kotlin Coroutines 가이드

Coroutine: 실행을 일시 중단(suspend)했다가 재개(resume)할 수 있는 작업의 단위

동작 원리

• 코루틴이 suspend되면 해당 스레드는 해제되어 다른 작업에 사용 가능
• 이후 코루틴이 resume되면 중단된 지점부터 이어서 실행
• 최소한의 오버헤드로 수천 개의 태스크를 동시에 실행 가능

코루틴 빌더

• launch — Job 반환, 결과가 필요 없는 태스크용
• async — Deferred<T> 반환, await()로 결과 획득

fun main() = runBlocking {
    launch {
        delay(1000L)
        println("Hello from Coroutine!")
    }
    println("Hello from Main!")
}

핵심 용어

한 줄 정의

Continuation은 "중단된 지점 이후의 나머지 실행"을 캡슐화한 객체입니다. 코루틴이 suspend되면, "다음에 무엇을 할 것인가"를 Continuation 객체에 담아두고, 나중에 이 객체를 통해 실행을 이어갑니다.

Continuation 인터페이스

interface Continuation<in T> {
    val context: CoroutineContext  // 어떤 스레드에서 실행할지 등의 정보
    fun resumeWith(result: Result<T>)  // 결과를 받아 실행을 재개
}

일상 비유: 북마크가 꽂힌 책

Kotlin 컴파일러는 모든 suspend 함수를 CPS(Continuation-Passing Style)로 변환합니다. 핵심은 간단합니다: 마지막 파라미터로 Continuation 객체가 추가됩니다.

변환 예시 1: 단순한 suspend 함수

// 우리가 작성한 코드
suspend fun fetchData(): String {
    delay(1000L)
    return "Data fetched"
}

// 컴파일러가 변환한 결과 (개념적)
fun fetchData(continuation: Continuation<String>): Object {
    // suspend 키워드 사라짐
    // 반환 타입이 Object로 변경 (SUSPENDED 마커도 반환할 수 있어야 하므로)
    // Continuation 파라미터 추가
}

변환 예시 2: 파라미터가 있는 경우

// 변환 전
suspend fun fetchUser(id: String): User
suspend fun saveData(key: String, value: Int): Boolean

// 변환 후 — 기존 파라미터 뒤에 Continuation이 추가됨
fun fetchUser(id: String, cont: Continuation<User>): Object
fun saveData(key: String, value: Int, cont: Continuation<Boolean>): Object

시그니처 변환은 첫 단계일 뿐입니다. 진짜 핵심은 함수 본문이 상태 머신으로 변환되는 것입니다.

Step 1: 원본 코드 — 우리가 작성한 3줄

suspend fun fetchUser(id: String): User {
    val profile = fetchProfile(id)   // ← suspend 지점 ①
    val friends = fetchFriends(id)   // ← suspend 지점 ②
    return User(profile, friends)    // ← 최종 결과
}

suspend 지점이 2개이므로, 함수는 3개의 토막(label 0, 1, 2)으로 나뉩니다.

Step 2: 컴파일러가 만드는 상태 머신 객체

// 컴파일러가 자동 생성하는 내부 클래스
class FetchUserStateMachine(
    val completion: Continuation<User>  // 최종 결과를 받을 곳
) : ContinuationImpl {
    var label = 0       // 북마크: 어디까지 실행했는지
    var result: Any? = null  // 이전 단계의 결과
    var id: String? = null   // 지역 변수 보관
    var profile: Profile? = null // 중간 결과 보관
}

Step 3: 변환된 함수 본문 — 3개의 토막

// 컴파일러가 변환한 fetchUser 내부 (개념적)
fun fetchUser(id: String, cont: Continuation): Object {
    // 상태 머신을 가져오거나 새로 생성
    val sm = cont as? FetchUserStateMachine
        ?: FetchUserStateMachine(cont)

    when (sm.label) {

        // ═══ 토막 ①: 함수 시작 ~ fetchProfile 호출 ═══
        0 -> {
            sm.id = id           // 지역 변수를 힙에 저장
            sm.label = 1         // 북마크를 "다음은 1번" 으로 설정
            val result = fetchProfile(id, sm)  // sm 자신을 전달!
            if (result == COROUTINE_SUSPENDED)
                return COROUTINE_SUSPENDED   // 함수 탈출, 스레드 해제
            sm.result = result
        }

        // ═══ 토막 ②: fetchProfile 완료 → fetchFriends 호출 ═══
        1 -> {
            val profile = sm.result as Profile  // 이전 결과 꺼냄
            sm.profile = profile                // 중간 결과 보관
            sm.label = 2                        // 북마크를 "다음은 2번"
            val result = fetchFriends(sm.id, sm)
            if (result == COROUTINE_SUSPENDED)
                return COROUTINE_SUSPENDED   // 또 탈출!
            sm.result = result
        }

        // ═══ 토막 ③: 모든 데이터 준비됨 → 최종 결과 반환 ═══
        2 -> {
            val friends = sm.result as List<User>
            return User(sm.profile, friends)  // 완료!
        }
    }
}

위 코드가 실제로 어떻게 실행되는지 시간 순서대로 따라가 봅시다.

suspend 함수 A가 suspend 함수 B를 호출하면, A의 상태 머신을 B에게 Continuation으로 전달합니다. B가 완료되면 A의 resumeWith가 호출되어 A가 이어서 실행됩니다.

실제 예시: delay()는 어떻게 재개되는가

// delay의 내부 동작 (단순화)
suspend fun delay(timeMillis: Long) {
    // 현재 Continuation을 가져옴
    suspendCancellableCoroutine { cont ->
        // 타이머를 등록하고, 시간이 지나면 재개
        scheduler.schedule(timeMillis) {
            cont.resume(Unit)  // 시간 후 resumeWith 호출!
        }
        // 여기서 SUSPENDED 반환 → 스레드 해제
    }
}

Continuation을 직접 다루는 가장 흔한 사례는 콜백 기반 API를 suspend 함수로 변환하는 것입니다.

변환 전: 콜백 지옥

// 콜백 기반 — 중첩이 깊어짐
fun loadUser(id: String, callback: (User) -> Unit) {
    api.getUser(id) { user ->
        api.getFriends(user.id) { friends ->
            api.getPhotos(user.id) { photos ->
                callback(user.copy(friends = friends, photos = photos))
            }
        }
    }
}

변환 후: suspendCoroutine 사용

// 콜백 API를 suspend 함수로 래핑
suspend fun getUser(id: String): User =
    suspendCoroutine { cont ->     // cont = Continuation 객체
        api.getUser(id) { user ->
            cont.resume(user)          // 성공: 결과를 전달하며 재개
        }
    }

suspend fun getFriends(id: String): List<User> =
    suspendCoroutine { cont ->
        api.getFriends(id,
            onSuccess = { friends -> cont.resume(friends) },
            onError = { error -> cont.resumeWithException(error) }  // 실패 처리
        )
    }

// 이제 순차적으로 작성 가능!
suspend fun loadUser(id: String): User {
    val user = getUser(id)           // 내부적으로 suspend → resume
    val friends = getFriends(user.id) // 내부적으로 suspend → resume
    val photos = getPhotos(user.id)   // 내부적으로 suspend → resume
    return user.copy(friends = friends, photos = photos)
}

// 100,000 coroutines - OK
repeat(100_000) {
    launch { delay(1000L); println("Coroutine $it") }
}

// 100,000 threads - OutOfMemoryError!
repeat(100_000) {
    Thread { Thread.sleep(1000L); println("Thread $it") }.start()
}

코루틴 빌더란?

코루틴 빌더는 코루틴을 생성하고 시작하는 함수입니다. 일반 함수에서는 suspend 함수를 직접 호출할 수 없기 때문에, 코루틴 세계로 진입하는 입구(bridge) 역할을 합니다.

// 일반 함수에서 suspend 함수를 바로 호출할 수 없음
fun main() {
    fetchData()  // ❌ 컴파일 에러! suspend 함수는 코루틴 안에서만 호출 가능
}

// 코루틴 빌더가 코루틴 세계로의 입구를 열어줌
fun main() {
    runBlocking {      // ← 코루틴 빌더가 코루틴을 생성
        fetchData()   // ✅ 이제 suspend 함수 호출 가능!
    }
}

빌더 비교

launch 내부 흐름

launch vs async 핵심 차이

// launch - 결과 불필요한 실행
val job: Job = launch {
    delay(1000L)
    println("Done")
}
job.cancel()

// async - 결과 반환
val deferred: Deferred<String> = async {
    delay(1000L)
    "Result"
}
val result = deferred.await() // suspends until result

CoroutineContext란?

코루틴이 "어디서, 어떻게, 누구 밑에서" 실행될지를 정의하는 설정 묶음입니다.

핵심 특성 3가지

1) Key-Value 구조 — 각 Element는 고유한 Key로 식별

val ctx = Dispatchers.IO + CoroutineName("MyWork")
ctx[ContinuationInterceptor]  // → Dispatchers.IO
ctx[CoroutineName]            // → CoroutineName("MyWork")
ctx[Job]                      // → null (없음)

2) 불변(Immutable) — +로 결합하면 기존 객체는 변하지 않고 새 객체가 반환됨

3) 상속 — 자식 코루틴은 부모의 Context를 물려받고, 명시적으로 전달한 Element가 상속값을 덮어씀

val scope = CoroutineScope(Dispatchers.Main + CoroutineName("Parent"))

scope.launch {
    // Dispatcher = Main (부모에게 상속)
    // Name = "Parent" (부모에게 상속)
    // Job = 새로 생성된 자식 Job (부모 Job의 자식으로 등록)

    launch(Dispatchers.IO) {
        // Dispatcher = IO (명시적으로 덮어씀)
        // Name = "Parent" (여전히 상속)
        // Job = 또 다른 새 자식 Job
    }
}

Element의 설계: Composite Pattern

CoroutineContext의 핵심 설계 트릭: Element가 CoroutineContext를 상속합니다.

public interface Element : CoroutineContext {  // ← 핵심!
    public val key: Key<*>
}

즉, Element 하나가 그 자체로 Context입니다. 이 덕분에:

// Element 하나도 CoroutineContext 타입
val ctx: CoroutineContext = Dispatchers.IO  // OK!

// Element끼리 + 연산이 바로 가능
val combined = Dispatchers.IO + Job() + CoroutineName("X")
//              Element      Element   Element
//              ↑ 각각이 이미 CoroutineContext이므로 plus() 사용 가능

Key가 companion object인 이유

public interface Job : CoroutineContext.Element {
    companion object Key : CoroutineContext.Key<Job>  // Key가 companion object!
}

// 그래서 클래스 이름 자체를 Key처럼 쓸 수 있음
context[Job]          // Job이라는 이름이 곧 Job.Key를 가리킴
context[Job.Key]      // 같은 의미

Element의 기본 구현이 영리한 점

Element는 "요소가 1개인 Context"이므로, 모든 연산이 자기 자신만 보면 됩니다:

public interface Element : CoroutineContext {
    // "나한테 이 key 있어?" → 내 key면 나를, 아니면 null
    override fun get(key: Key): E? =
        if (this.key == key) this as E else null

    // "모든 요소 순회해" → 나 하나뿐이니 한 번만 실행
    override fun fold(initial: R, operation: (R, Element) -> R): R =
        operation(initial, this)

    // "이 key 빼줘" → 내 key면 빈 Context, 아니면 나 자신
    override fun minusKey(key: Key): CoroutineContext =
        if (this.key == key) EmptyCoroutineContext else this
}

Context 연산

// 예시 1: Key가 모두 다름 → 충돌 없이 3개 모두 포함
val ctx = Dispatchers.IO + CoroutineName("MyCoroutine") + myJob
// 결과: { IO(Dispatcher), "MyCoroutine"(Name), myJob(Job) }

// 예시 2: 같은 Key 충돌 → 오른쪽이 우선
val left  = JobA + DispatcherA       // { JobA, DispatcherA }
val right = JobB + NameB             // { JobB, NameB }
val result = left + right
// Step 1: JobB 합침 → JobA와 같은 Key(Job) → JobA 제거, JobB 추가
// Step 2: NameB 합침 → 새 Key → 그냥 추가
// 결과: { DispatcherA, JobB, NameB }

Job = "누구 밑에서" 실행되는가

코루틴을 launch하면, 컨텍스트에서 부모의 Job을 찾아 자기를 자식으로 등록합니다. 이 부모-자식 관계가 구조화된 동시성의 기반입니다.

val scope = CoroutineScope(Dispatchers.Main + parentJob)

scope.launch {          // 이 순간 내부에서 일어나는 일:
    // ...              //   1. parentJob을 컨텍스트에서 꺼냄
}                       //   2. 새 자식 Job 생성
                        //   3. parentJob.attachChild(childJob) 호출
                        //   → 부모-자식 관계 형성!

// 기본: parentJob의 자식으로 등록됨
scope.launch { /* 부모 = parentJob */ }

// Job()을 직접 전달: 부모가 바뀜 → 구조화된 동시성 깨짐!
scope.launch(Job()) { /* 부모 = 새 Job (parentJob과 무관) */ }
// → parentJob이 취소돼도 이 코루틴은 안 죽음
// → Activity가 파괴됐는데 코루틴은 계속 실행 → 메모리 누수!

Job 생명주기 상태

구조화된 동시성 규칙

1. 하향 취소: 부모 취소 → 모든 자식 자동 취소
2. 상향 실패 전파: 자식 실패 → 부모 취소 → 형제도 취소
3. 완료 대기: 부모는 모든 자식 완료 전까지 Completed로 전이하지 않음

SupervisorJob

// SupervisorJob 내부 - 딱 한 줄 차이!
private class SupervisorJobImpl(parent: Job?) : JobImpl(parent) {
    override fun childCancelled(cause: Throwable): Boolean = false
}

// viewModelScope는 내부적으로 SupervisorJob 사용
return CloseableCoroutineScope(dispatcher + SupervisorJob())

SupervisorJob은 구조화된 동시성에 반하는가?

부모-자식 관계가 유지되고, 생명주기가 계층적으로 관리됩니다. "자식이 실패해도 형제를 살려두겠다"는 정책 선택일 뿐입니다.

진짜 구조화된 동시성을 깨는 것

디스패처란?

디스패처는 스레드 풀을 관리하며, 코루틴에 스레드를 배정/회수하는 관리자입니다.

Main vs Main.immediate — 왜 구분하는가?

// Dispatchers.Main — 항상 큐에 넣고 나중에 실행
launch(Dispatchers.Main) {
    println("B")  // 큐에 넣어짐 → 현재 작업 끝난 후 실행
}
println("A")      // 먼저 실행
// 출력: A → B

// Dispatchers.Main.immediate — 이미 Main이면 즉시 실행
launch(Dispatchers.Main.immediate) {
    println("B")  // 이미 Main 스레드 → 큐에 안 넣고 바로 실행!
}
println("A")      // B 다음에 실행
// 출력: B → A

Android 전용 스코프

coroutineScope vs supervisorScope

// withContext - 같은 코루틴 내에서 디스패처 전환
suspend fun fetchData(): Data {
    return withContext(Dispatchers.IO) {
        api.getData() // IO 스레드에서 실행
    } // 원래 디스패처로 복귀
}

// repeatOnLifecycle - STARTED 상태에서만 수집
lifecycleScope.launch {
    repeatOnLifecycle(Lifecycle.State.STARTED) {
        viewModel.uiState.collect { state ->
            updateUI(state)
        }
    }
}

세 가지 전략

CoroutineExceptionHandler 규칙

• 루트 코루틴에서만 동작 (부모가 없거나, 부모가 SupervisorJob인 경우)
• 코루틴이 이미 종료된 후 호출 - 복구 불가능
• async에서는 동작하지 않음 (예외가 Deferred에 저장되므로)
• 용도: 로깅, 사용자 알림, 앱 재시작 트리거

CancellationException - 핵심 규칙

// 올바른 패턴
suspend fun fetchData(): Result<Data> {
    return try {
        Result.success(api.getData())
    } catch (e: CancellationException) {
        throw e  // MUST rethrow!
    } catch (e: Exception) {
        Result.failure(e)
    }
}

// 위험 - suspend 함수와 함께 사용 금지!
suspend fun fetchUser(): Result<User> = runCatching {
    api.getUser() // CancellationException gets swallowed!
}

// 안전한 대안
suspend inline fun <R> runSuspendCatching(block: () -> R): Result<R> {
    return try {
        Result.success(block())
    } catch (c: CancellationException) {
        throw c
    } catch (e: Throwable) {
        Result.failure(e)
    }
}

async 예외 주의점

// 해결: supervisorScope 사용
runBlocking {
    supervisorScope {
        val deferred = async { throw RuntimeException("error") }
        try {
            deferred.await()
        } catch (e: Exception) {
            println("Safely caught: $e")
        }
    }
}

Cold Flow vs Hot Flow

Flow 내부 아키텍처

• flow { } 빌더는 SafeFlow를 생성 → AbstractFlow를 확장
• AbstractFlow는 collector를 SafeCollector로 래핑해 컨텍스트 보존을 강제
• flow { } 내부에서 컨텍스트를 변경하면 IllegalStateException 발생 → flowOn() 사용

flowOn vs buffer

FusibleFlow 최적화

// 컨텍스트 보존 규칙
flow {
    emit(1)
    withContext(Dispatchers.IO) {
        emit(2) // IllegalStateException!
    }
}

// 올바른 방법: flowOn 사용
flow { emit(heavyComputation()) }
    .flowOn(Dispatchers.Default) // upstream runs on Default
    .collect { updateUI(it) }  // downstream runs on caller's context

채널 유형

flatMap 변형

callbackFlow vs channelFlow

// callbackFlow - 콜백 API를 Flow로 변환
fun locationFlow(): Flow<Location> = callbackFlow {
    val listener = LocationListener { location ->
        trySend(location)
    }
    locationManager.requestUpdates(listener)
    awaitClose {  // MUST have this!
        locationManager.removeUpdates(listener)
    }
}

// channelFlow - 여러 소스 병합
val combined = channelFlow {
    launch { sourceA.collect { send(it) } }
    launch { sourceB.collect { send(it) } }
}

join() vs yield()

각 질문을 클릭하면 답변이 펼쳐집니다.

면접 준비에서 가장 흔한 실수는 모든 걸 동일한 깊이로 파는 것입니다. 아래 가이드로 에너지를 효율적으로 배분하세요.

1. 코루틴 기본 개념

2. Continuation & 내부 동작

3. 스레드 vs 코루틴

4. CoroutineContext & Job

5. Scope & Dispatcher

6. 예외 처리

7. Flow

8. 채널 & 기타 연산자

주니어 (0~2년) — "사용법을 정확히"

• viewModelScope에서 launch/async로 네트워크 호출하기
• withContext(Dispatchers.IO)로 스레드 전환하기
• StateFlow + repeatOnLifecycle로 UI 상태 수집하기
• try-catch로 예외 처리, CancellationException 재전파 규칙

미드레벨 (2~5년) — "왜 그렇게 동작하는지"

• 구조화된 동시성의 3규칙과 SupervisorJob이 필요한 이유
• CoroutineExceptionHandler가 루트에서만 동작하는 이유
• Cold vs Hot Flow 선택 기준, callbackFlow 사용 시점
• CPS 변환과 상태 머신의 기본 원리 설명 가능

시니어 (5년+) — "내부를 꿰뚫고 있는가"

• 코루틴 기반의 앱 아키텍처 설계 (Repository → UseCase → ViewModel 전체 흐름)
• Flow의 컨텍스트 보존 규칙, buffer/flowOn의 내부 채널 동작
• JobSupport의 상태 전이, childCancelled 전파 경로
• 테스트에서 Dispatchers.Main 교체, TestCoroutineDispatcher 활용

아래 질문에 30초 이내로 답할 수 있다면 준비 완료입니다.

Lv.1 — 이것만은 꼭 (답 못하면 감점)

Lv.2 — 알면 좋은 인상 (설명하면 플러스)

Lv.3 — 시니어 차별화 (깊이를 증명)